ObDebian

Remove dpkg-sig signatures from .deb files by opening it in vim, deleting everything starting from _gpgbuilder (or what you've signed it with), optionally ":set noeol bin", save it, and update the md5sum and filesize in the .changes file. Done so with xblast and xmms-sid because the update was fixing rather important problems which couldn't wait for the archive patch that will allow dpkg-sig signatures again.

ObNonDebian

Winderschlapfn and Corry got released. Get your copies now!

ObConcert

Die Krupps are on tour again! Going to visit them on thursay! Yeah!!

ObFTWCA

For Those Who Care About Multiple Signatures: The second signature on Joey's d-d-a mail was not broken, the inner signature was mine. It was a statement that we both are to blame for it.

ObXMas

Late, but still worth it: Grow Ornament (requires flash)

ObListening

Wir sind Helden on my:

ObMyMiniDj

Am in contact with a person who managed to reverse engineer the database format used by My Mini DJ. He's working on a patch for amarok to update the database, and I hope he'll share the format soonish so I can do a curses app for managing it.

ObCinema

"Organize isler" in turkish with subtitles. Maybe a bit brutal partly, but great and funny story. Definitely worth watching.

ObICQ

No, I'm not interested in random chats by bored horny people!

ObWork

The transition from bind9 (no debpkg link; not because it's not working currently, but because it was running on FreeBSD) to pdns is underway.

ObNonWork

Planeshift: I'm planing on fixing #284398. Might need something free like re-flex for its datafiles to be able to go to main, though.

ObBlog

I hope to blog more regularly.... *sighs*

Had a busy couple of weekends with Rick visiting and us doing much sightseeing. I've been too busy to blog. The weekend before the one just gone was a long one on account of Martin Luther King Day on the Monday. We spent Saturday in San Francisco, Rick and I at Camp Sysadmin, as previously mentioned, and Sarah pottered around on her own (photos here). On Sunday, Rick and I went for a reasonable (28 kilometre) bike ride around the part of the bay accessible from the Stevens Creek Trail in the morning, and in the afternoon we all drove into the hills to check out the Lick Observatory. You can see the observatory as a little bump on the top of the mountains on a clear day, but it's deceptively further away than you think, because it's actually on top of the second line of mountains, not the first. We didn't expect to find ice and snow or for it to be zero degrees (Celsius) at the summit. We made it up just before 5pm, which was closing time, so we'll have to go again earlier in the day (and more appropriately attired) to check it out more thoroughly. Some photos here. On the Monday, we did a bit of a group outing with a few other people from work, including Tanya, who is visiting from the Dublin office and also in extreme tourist mode. We took a Caltrain in to Millbrae, and then switched to the BART for the remainder of the journey. Finally, we took a cable car from Powell station over to Fishermen's Wharf, where we wandered about for a bit, and then had a nice $11 cruise on the bay for an hour and a half, which went around Alcatraz and under the Gold Gate bridge. After that we caught another cable car back downtown, wandered around for a bit, and then met up with a few more people from work for a beer, and then had dinner at a nice Irish pub that we found. Photos from that outing here. On the Saturday of the weekend just gone, we drove to Monterey, mainly with the aim to hire Segways and fang around on them. Mission accomplished, and it was very affordable too. I think we'll definitely do that again. We also need to visit the aquarium. I really liked Monterey. It reminded me a lot of Berry, on the New South Wales south coast. Photos here. Finally, on Sunday (i.e. yesterday), we drove back to San Francisco, where Sarah, Rick and Tanya did the Alcatraz cruise/tour thing, and I spent most of the time riding the cable cars and street cars. The $10 day pass purchased on the cable cars is great value, as it seems to be valid on all of the San Francisco Municipal Railway (affectionately known as the "muni"). In the afternoon, we all went on a bus tour of San Francisco (the same one Michael and I did in July, but with a different driver, and slightly different route). Finally, we had a really nice dinner at an Afghani restaurant a few doors down from the backpacker's hostel that Tanya was staying in. Photos from the day here. Rick flew out tonight, and hopefully had a good time while he was here. We're certainly feeling a bit weary from all the sightseeing, but having visitors is always a good excuse to get out and do it. Next weekend, our friend Brett is visiting from Canada. No rest, I tell ya...

Sorry. Couldn't resist. Following on from my previous look at XTech proposals, I wanted to comment on one of the hot topics contributed to the Applications track. While this track will push all the buttons (we've got Rails, RSS, web services, content management and more) one of the really striking things was the number of proposals on the topic of DITA. If you're not a regular in the tech docs world, then DITA is probably at best just another acronym you've seen whizzing by. DITA stands for the Darwin Information Typing Architecture, and it's a new document format making waves in the world of technical documentation. From a casual documenter's point of view, the obvious question is probably "what does this mean for DocBook?" Does the mass of enthusiasm mean DocBook's on its way out? In short, no. DocBook and DITA compared  DITA and DocBook are actually rather different beasts. DocBook is a sound DTD for writing technical books and articles, with the structure that such forms imply. DITA is focused on creating modular technical documents, with the intent for easy reuse across varied delivery methods. It's intended for topic-oriented documentation, which may be chopped about and rearranged within a variety of contexts and for a variety of display devices. DITA is a DTD and a set of rules for writing online contextual documentation such as software help files. There's a lot more to it than I'll write here, but here a few more differences between DocBook and DITA:

• DocBook is hierarchical, DITA separates content from context allowing multiple architectures of information
• DocBook is a fixed element and attribute set, DITA is extensible, allowing the definition of custom information types
• DocBook is much more mature than DITA, with a variety of solid tool support options. DITA's the new kid on the block.
• DocBook is well documented, DITA's documentation is still in the early stages.

There's a real need for something like DITA, which addresses concerns that didn't really exist in the same way when DocBook first emerged at O'Reilly in the early 1990s. DITA and open source projects I'm looking forward to learning more about DITA, but one thing that immediately strikes me about it is its relevance to some of the documentation problems faced by open source projects. DocBook has never quite clicked as a documentation format for some collaboratively maintained projects, probably because the inevitable book-like nature of the result necessitates sole or restricted authorship, and heavy editing. Instead one of the increasingly popular ways for providing documentation has been the wiki. You guessed it, a topic-based architecture. What wikis seem to lack, however, is any way of providing a thought-out progression through the content. In essence, the information architecture side of things. Had I been able to attend every session from XTech last year, I'd have heard Paul Prescod talk about what DITA and wikis have in common.
There may be a downside, however. DITA looks impressively engineered, but it may be too industrial-strength for many. My initial investigations suggests that while there's emergent commercial tool support, there's not much going on in the open source field (although there is the DITA Open Toolkit, which looks to have been produced in close association with OASIS technical committee now in charge of DITA.)
As DocBook guru Norm Walsh observes, DocBook can play in this space too. With additions such as those Norm proposes, DocBook could play host to DITA's major features. (Norm writes "With a couple of hours of hacking, I've implemented on top of DocBook the four key features of DITA that I could identify.") Though these possibilities are intriguing, I think that, for open source projects, things need to get simpler rather than harder. More reading:

• DITA--Getting Started (XTech 2005 proceedings)
• To DITA or not to DITA? (Palimpsest blog)
• Cover Pages: Darwin Information Typing Architecture (Robin Cover)
• DITA FAQ (OASIS)
• Going DITA (O'Reilly weblogs)

pacta en la m s absoluta clandestinidad. Tal es la obscuridad y el secretismo, que ni su socio en la Generalidad catalana (ERC) sabe a n lo que se ha pactado con CiU, el partido que all est en la oposici n. Tras la bajada de pantalones que supuso el traslado de los archivos de Salamanca y que se realiz con total nocturnidad, ahora pactamos un estauto para la Comunidad Aut noma de Catalu a inconstitucional y de espaldas al resto de Espa a. Eso s , que sepa el presidente que una vez m s, como en los ltimos 25 a os, cada vez que se le concede algo a los nacionalistas, estos ya no est n de acuerdo y no les parece suficiente. Como perla, las palabras de Arturo Mas:

"Es un salto adelante, que no renunciamos a completar en a os futuros"

Lamentable.

For the record: this card has a ACX111 chip, supported by the ACX100/111 driver. I managed to make it work under Debian yesterday. It seems that this card is very sensible about the PCI slot you put it in. At least, putting it in another PCI slot than the last one of my Asus P4P800, makes it act weirdly: PCI id not the same, error writing the firmware, and so on.

Sometimes, coding for the web is like having a co-worker with a body odor problem. Everyone's far too polite to say anything, so you all put up with it and nobody tells the poor smelly soul. Meanwhile, they sense something's wrong but don't know what. Web browsers are so insanely great at making sense of tag soup, that if you code only for the end-result--a reasonable strategy, adopted by most when starting out--you can get into all sorts of tangles. Misery ensues: you're stuck with days of fiddling in the dark. You know something's up, but it's hard to see what's going wrong. In that sense, browsers are lousy at one half of Postel's law. They get the "liberal in what you accept" bit right, but they don't help the developer one bit in implementing "be conservative in what you do." Using three or four different validators for HTML, CSS, etc. often helps a lot, but the state of the browser as an integrated development platform leaves something to be desired. Firebug is a Firefox extension that goes a long way to providing integrated web application debugging. It is a full-featured error console that shows your errors in Javascript, CSS (a godsend!) and XML. Not only that, but it does full logging for XMLHttpRequest calls, so it's a powerful tool for debugging AJAX applications as well. Firebug also manages to bundle in a DOM inspector, and a command line for evaluating Javascript. With these features, Firebug should let me throw out about four separate extensions I already had installed that do a similar thing. The final star turn in Firebug's act is a Javascript call to log information to its console, the equivalent of the all important debugging printf() call in C. I hope this means this will make it easier to deploy things such as unit test frameworks for AJAX applications. Although its author Joe Hewitt cautions us to remember that Firebug is still an alpha release, I'd still recommend rushing to install it. If you're developing anything for the web browser this year, it's the most important tool you'll find. While it won't rid you of the problems of cross-browser compatibility, Firebug will speed you in uncovering the smelly bits of your web application.

Pacquiao Gains Revenge with Electrifying 10th Stoppage of Morales W00T!!! Let the beer flood!!! (and forget about LiveJournal flodding I would have posted a pic here for everyone to see what I mean, but I fear would-be lawyers coming at my door and shouting “him, him, that’s the man!!! Anyhow, salamat at congrats ulit, Manny, sa iyong pagkapanalo!

I few months ago I decided to add support to Oracle database to dbconfig-common frontend. At that moment, I began learning how to install it and how to manage it.

My work:
1.- Download Software. My first surprise: Oracle -> 685M, Postgres -> 15,8M
2.- Read Manuals: A lot of them, with a high quality but... I can't find how to install in Debian. Google solves it: Desktop Survival Guide. Tricky but works!
3.- Manual database create/remove/test/dump...:
* create/dump: dbca is a graphical frontend than help to it; the --silent parameter let it works without graphical frontend.
* dump: exp works nice. The first test: to dump a complete void database (1 user, 1 table), takes 9 minutes and 12Mb!!!; Postgres -> 9 sec. and 200k for 100 tables/triggers.

I always hear than Oracle is the best database, but now I'm not to sure.

- The installation is too tricky.
- Create databases is slow (minutes)
- 9 minutes and 12mb to dump a complete void database? Slow!!!!!
- To work correctly you need to manually define 7 environment variables. No comments.
- It needs a big server. 500Mb Ram, 1Gb Swap, minimum.
- It's not possible to create a database remotely because it's necessary to create manually directories locally.

I was thinking about create debian packages for the new Oracle Database 10g Express Edition Beta Release , but It will be a lot of work. Maybe an alioth project?

About dbconfig-common... It will be probably finished this week, but it will need a lot of test/verify before release it.

My work in Debian was being hard, working on a lot of sides, translations to catalan, maintaining packages, working with new packages and working with dbconfig-common and dl10n alioth projects.

A few months ago Aurelien began to sponsor me and then I inscribed me to the New Maintainer application list. I was reading each they the movements on the application list, and today It has changed. Marc 'HE' Brockschmidt has been assigned as my Application Manager.

I was waiting for this moment, but now, I'm very nervous.

I've discovered myDMS, an interesting Document Management System, I've installed on my system and tried it. It works so fine I've begun to use on my own documents.
I've decided tu package it to Debian.
I don't know why, but php packages seems not to be a good option in Debian. But I think this package is a very good option in Debian, I've looked for another DMS in Debian and there are not another good option.
I think I could find an sponsor for this package.

Fred Wilson: “I will not buy music that I cannot remove the DRM from.” I agree wholeheartedly, though the strategy I use is the one Fred dismisses in the first paragraph, namely burning the music to CD and ripping it back, sans DRM, to MP3 format. Yes, it’s a pain, but it beats having to jump through all the digital hoops at some indeterminate point in the future when all I want to do is queue up a song I’ve legitimately purchased and have probably forgotten where I bought the thing, let alone what magic pixie dust I need to decode it. Sure, the MP3 format has issues too, but at least I know my music will play anywhere. (Since I’m on the subject, I’m looking for some sort of a virtual CD burner, which the operating system thinks is a CD burner but which is actually a piece of software that converts the tracks it “burns” to MP3 format. Anyone know if such a beast exists? That would certainly do wonders to curtail my contribution to the world’s coaster supply.) In practice, DRM isn’t as much as a problem for me as it seems to be for other people. Personally speaking, I don’t want to be in the music storage business—I’d much rather stream music on demand from some digital jukebox in the sky, which is why I’ve been a Rhapsody customer since 2003. (Greg Papadopoulos sums up my thinking pretty well exactly here: “I’ll bet that we will look back of this era of quasi-networking and wince, ‘How did we ever live that way?’ And the idea of wanting to carry all of your content with you will seem both old-fashioned and rather ridiculous.”) In my case, DRM is normally a non-issue—I simply route around it. Rhapsody has come a long way since I first started using it in 2003: They added a Rhapsody To Go service, which more or less solves the “disconnected operation” problem (though I still tangle with DRM issues from time to time if I go for too many days untethered), and they finally embraced the web, though the current web offering leaves much to be desired—the Linux plugin still doesn’t support Firefox 1.5 nearly two months after its release, the web interface has huge gaps compared to the jukebox software (you can’t access your music library on the web, among other things?!), and they don’t seem to be taking advantage of the new web platform at all (where, oh where, are the RSS feeds of my favorites, recommendations, etc, so I can mash them up with other stuff?). At the end of the day, I suspect the “economic boycott” James Governor calls for is the right way to fix the DRM problem. For my part, I’m voting with my wallet by supporting the model I want to win out in the end (that your music library will live on the web, not on your PC or in your pocket) and by buying music, in those rare cases when I do want to manage my own music library rather than letting someone else do it for me, from legitimate music services but opting out of the silos the platform providers are trying to build around me as a byproduct. Above all, I resist the temptation to climb into the big, beautiful lockbox Apple is building for us. As Clayton Christensen recently told BusinessWeek, I’m firmly convinced open standards will win out in the end:

Look at any industry — not just computers and MP3 players. You also see it in aircrafts and software, and medical devices, and over and over. During the early stages of an industry, when the functionality and reliability of a product isn’t yet adequate to meet customer’s needs, a proprietary solution is almost always the right solution — because it allows you to knit all the pieces together in an optimized way. But once the technology matures and becomes good enough, industry standards emerge. That leads to the standardization of interfaces, which lets companies specialize on pieces of the overall system, and the product becomes modular. At that point, the competitive advantage of the early leader dissipates, and the ability to make money migrates to whoever controls the performance-defining subsystem.

I don’t know about the rest of you, but that day can’t arrive soon enough for me.

When I moved this blog from being Zope-backed to using Rails several people got in touch to ask why. This is a brief explanation of why I've moved.Firstly I should point out I've had a long and mostly happy experience with Zope. I got into Zope originally because I'd spent some time in constructing web frameworks from scratch (we're talking 1995-1999 here) and found that not only does a framework need good templating, it needs reusable components within that.Zope seemed like a good fit, so I spent some time getting up to speed and was happy there. However, there were some things that didn't make me feel completely comfortable. Zope offered a very stark choice between developing through the web based interface (DTML methods, etc.) and writing raw Python. To do really useful stuff, you had to get into the Python side of things, but also learn a lot about Zope guts that wasn't really well documented.I spent more time than I probably should have had to reading Zope's own source code in order to figure out how things worked. Fine, for my own silly little projects, but not practical in general. It was hard to get the overall view of a project, and hard to test. The learning curve was a little too steep, I suppose.
So, once I'd got to a certain point I stopped, and looked around for a platform that gave me more code visibility and testability. Loyal readers will know I've looked at ASP.NET and Python, Quixote and Cheetah. ASP.NET I rejected because I didn't view Mono's web application server as mature enough at the time, and I also had reservations about ASP.NET's non-free baggage. Python, Quixote and Cheetah looked a lot more friendly.What I wrote about Quixote and Cheetah at the time was "this combination isn't adequately presented and described anywhere." These were good technologies, but not integrated as a framework. I started work on integrating them, and made some interesting progress. I was correct that Python lacked a solid modern framework, and the time was certainly right for it, as we can now see by the emergence of Django and TurboGears.
However, at the same time I started looking at Rails and found out that it did pretty much what I wanted. To be honest, I'd avoided it for a while as a friend once did me the disservice of calling Ruby a cross between Python and Perl. "Why ruin Python?", I thought. And it takes me a while to get over the hype barrier before I conclude that there's a "there" there.
Now I've been using Rails for a while, I find its attractions have changed for me. The thrill of not having to write basic functionality over and over again has given way to more select pleasures. Writing in Ruby itself is a rewarding experience, as its idioms become plainer over time.Sure, you can write Java or Perl in any language, and that's where I started off. But the subtle elegance of the Ruby idiom is a slowly appreciated and highly satisfying flavour. For developers who consider themselves as poets and artists too, I can't think of a better language.

I was recently reading a report written in 2004 on the safety of Dutch flood defenses. One of the more interesting sections was a comparison of Dutch flood defense policy with that of other countries, including the United States.

In the Netherlands large sums of money are spent maintaining the dikes. It is not possible to achieve perfect safety; however, it is possible to estimate risks. In the Netherlands it is reasoned that it is justifiable to spend additional money increasing the effective height of dikes up to the point where it costs more to add the next centimeter than that centimeter will "save", where the calculated saving is equal to the reduced economic losses due to flooding. Because the cost of flooding Holland would be large, the policy that emerges from this analysis is that the dikes protecting Holland should be built to withstand water levels that occur once per 125,000 years on average.

In the United States the corresponding figure is typically once per 100 years. That is, the government chooses to accept a frequency of flooding that is one thousand times as high as that considered acceptable for Holland. (The dikes around New Orleans are built to an even lower standard.)[0] This is a deliberate policy which is paired with the view that citizens should be free to make their own choices: someone can build in an area vulnerable to flooding, but then he probably won't be able to get flood insurance and therefore won't be able to get a mortgage.

Recent events have to be considered in this light.

[0]UPDATE: I have discovered that the exact figure for New Orleans is 200 years. That is, once the current programme of levee upgrades is complete, the New Orleans levee system should fail with an annual probability of 0.5%. As yet I have found no hard figures for the failure probability of New Orleans levee system prior to the completion of the upgrade programme.

The project we're talking about here that has failed is an element of the Lake Pontchartrain project, and in its early design stages it was meant to provide protection from a two- or three-hundred-year event that might strike the city; so we were looking at a very low-probability event and we designed with that in mind. -- Lieutenant General Carl A. Strock, Chief of Engineers, U.S. Army Corps of Engineers, at a news conference on 1 September 2005

The point stands that Dutch policy makers have a very different idea of "low probability" when it comes to floods. Dutch water defenses are built to have an annual failure probability of 0.0008%.

Clint, this is the cactus that brought so much singing and happiness into my life today, for just 5 .

...are there mosquitoes in Panama?

Note to sheba_finesse and self: Clean fish tanks weekly! They somehow manage to get really dirty if you don't.

I should also actually add pH neutraliser and water conditioner to the tank after doing a water change. I have managed to lose 3 guppies, 2 platties and a Clown Loach in the last 3 days. Expensive lesson. However, now I get to pick new fish, so I bought 5 Black Skirt Tetras.

Now that's over with, I can move onto other stuff.

Jean and I have bought a new bed, a new washing machine, a new dryer and a new fridge. Now we just need to wait for Radio Rentals to pick up the old stuff, and I'll be happier.

Techy stuff:
I finally gave in to Jordi and agreed to move Debian ALSA stuff into SVN. I'm seeing if subversion can act like less of a bitch than the last time I used it, in which case, I may actually re-evaluate my opion of it.

My Sparc has been deciding to run out of of memory. Then I discovered that spamassassin 3.0 is a dirty memory whore, and was chewing up 90Mb of RAM. I have moved spamd to a machine to more memory (the Sparc has an extremly small swap partition due to stupidity on my part), and not installed 3.0, and purged my Bayes database, so spamd should be quick and not suck ~ 100Mb of memory. As an aside, does anyone know how to stop spamassassin doing Bayes?

Ed Felten at Freedom to Tinker makes an excellent observation while discussing Google’s video service digital rights management scheme: “Privacy is for Google what security is for Microsoft.”