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.

A recent post by Ingo Juergensmann lamenting m68k not making the cut in this round of architecture qualifications. While it is a shame I think, I don't think it's necessarily the end of the world and his complaint that developers will now stop fixing bugs is crazy. Just because they're suddenly not release critical doesn't mean (good) maintainers will be unwilling to fix them. Most architecture bugs are toolchain bugs (ie not the package maintainer's fault), general types of architecture bugs (eg endianess, int size) that affect more than one architecture and tend to get fixed quickly and easily and really freaking hard problems that most package maintainers don't have the skill to fix on their own (eg #343687, help!). But if someone submits a bug that's trivial to fix, or gives me a patch, that bug will get fixed. I don't like bugs in my packages and probably most other developers don't either.

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.

I've discovered dbconfig-common project, a very interesting seanius work used to help to create new database based packages. I've joined to it and 've done my first commit to cvs.
Two new packages dbconfig-common based is ready to upload to sid, mydms and bulmacont. When dbconfig-common will be on sid, I've ask aurel32 to upload mydms to unstable.

A few months ago, I opened an ITP to ocrad package, then I tried to find an sponsor and seems to be not possible to find one. I uploaded it to nm.d.o and forgot it. Now, i've received this mail from Ubuntu:

Hello Miguel,

I'm working on the community team that is bringing extra packages into
Ubuntu's Universe component so they are more easily found by Ubuntu
users. We've selected this package that you maintain:

- ocrad

So this will be part of the Ubuntu 5.04 release on April 8th. We may
add more packages after Hoary, for the next release in October,
codenamed Breezy Badger.

We'd like to work with you to make sure that the latest version of your
packages is always in Ubuntu. Feel free to mail me whenever you have new
versions of the packages for testing or commentary. If you'd like to be
able to upload directly to Ubuntu then we can arrange that. We organise
ourselves as an open community project - some details are at
http://wiki.ubuntu.com/MOTU if you'd like to join the ubuntu universe.

Have a nice day,
Daniel Holbach


It seems as Ubuntu is working to add software faster than Debian. I'm thinking my answer.

It seems impossible to release Sarge. I've received in 2 days 800 mails about Vancouver release team meeteing subject.
My opinion:
Abandon an architecture is throw users. Whats happen if we realease by blocks? I could release a block with main architectures (i386,powerpc,ia64,itianium?) and other blocks with the others, releasing them but no necessarily in the same moment. A few of them will disappear if there are not interest on maintaining them because no help to do it, but, if a architecture is out of main block and is enought people interested on it, it will be released at time.
It could be as I'll be trying to be a fork, but is no the idea. The difference could be that we could have more than one package per upstream, with coordination but not blocking themseves on releases.

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.

I've just uploaded sponsored package libpam-encfs. With it it's possible to have encrypted home directory, which will be mounted during login.

I'm working on new fuse (filesystem in userspace) packages and I really wonder if I should simplify their postinstallation procedure as it was mentioned in #337572. That would make my life much easier, cause there's quite many bugreports against undefined behaviour of post-debconf tasks, which are pretty hard to track for me. In fact I suppose that most users simply accept default answers so asking them about anything seems to be overhead.
Let's assume I will remove these superflous questions... now the problem is that if someone answered for them in some previous installation then I could leave unneded group and some config files on their systems. On the other head removing this group could even lead to nonworking system because of one of these bugs: #307624, 307627, 306281.
I'm quite confused what to do now. Both solutions have some advantages and disadvantages. First one at least could lead to less bugs in the future. Hints welcome.

I was going through some old mail/news that I'd saved, and came across this posting, which is pretty funny: http://tinyurl.com/cf5sf

Installed PHP. Will try working with it. Thanks for the input. Raj P.S: Do you have any prior PHP experience??

followed by:

P.S: Do you have any prior PHP experience??

A bit, yes. -Rasmus

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.

So long time I know. For those of you out there who celebrate, Merry Christmas and Happy New Year! I have been busy last month and a half with work. As many know, I work for UPS and mid-Nov. to Dec. get pretty hairy at that place. Back in school this quarter full time. I am determined to get this over with and get into the field most here in cyberspace know I want to be in. Looks like my days of hacking are going to have to wait tho. This week alone I have spent 6 hours a day in the books, 8 hours at work and the remainder in bed or wasting on tv/ps2. Back to college life again. Least I am not eating ramen again. Sunday I will be in Wellington Ohio for a 20 team paintball tournament. I am hoping to get pictures and video of the event and hope to post those somewhere are the net for all to see. It looks as if our local team has a good chance to win $1000 as long as I carry the team ;) At any rate, will be fun and those who know me know paintball is the only stress relief I have left. GO STEELERS!!!

The controversy over Apple's "photocast" extensions, and the strangeness of their iTunes RSS enhancements, is illustrative of the transition that software companies need to make as they become web-enabled. It's no longer enough to make your applications and hardware pretty and functional, but the guts that other people get to see must look good too. This is one reason that people prefer RELAX NG over XML Schema, for instance. Where markup is concerned, it turns out that the excuse "only computers will read it, and we'll provide tools to generate it" doesn't cut it. The web's had a view-source mentality since it started, and the aesthetics of markup matter a great deal. They matter not only because they're nice for geeks to look at, but also because well-structured and standards-compliant markup is simply more interoperable. The end user experience is ultimately improved. Microsoft now gets this, I think. It's not hard--you just need to have your engineers exposed to the web, not hidden in some blinkered bunker. It's a shame that Apple doesn't yet understand that the aesthetics of markup count. Even their new web tool, iWeb, lacks somewhat in this department. Apple do so well in the rest of the computing experience, these poor web efforts really stand out. It was rather sad to read the disappointment OS X-hugging web developers felt with the iPhoto RSS use. Will Apple "get" the web better someday? I hope so, because we'll all benefit.

One thing I just don’t understand about the whole GFDL debacle is why it’s so urgently important to purge all GFDL documents from Debian. For those documents with invariant sections, I can kind of see the point. Invariant sections clearly violate DFSG3, and we’re obligated by the social contract to abide by the DFSG. Granted, we’ve been distributing non-modifiable documents since Debian’s inception, so that’s a rather shocking change in policy. Thanks to some “editorial changes” to the social contract, the Debian distribution has to change in fundamental ways. What’s even more suprising is that the changes in policy are going far beyond the requirements in the DFSG. According to the draft position statement, there are two problems in addition to the invariant sections–the “DRM” restriction and transparent and opaque copies. Note that in the GR proposal, the invariant section problem is explained by quoting DFSG3. However, the other two problems are not given any reference to the DFSG, and for good reason–there is no clear DFSG violation in either one. Sure, they’re icky, worded poorly, and no one particularly likes them. But since when is that grounds for removal from Debian? Even worse, overriding the interpretation that these problems are DFSG violations will require a 3:1 super majority thanks to the secretaries opinion on the matter. Apparently, we are being strong-armed into purging all GFDL documents from Debian, which little chance of reversing this decision. So, what does this accomplish?

• Alienation of our users
Users will have their documentation pulled out from under them, which is acerbated by the installer no longer adding the non-free section to the sources.list by default. To most users, this documentation will simply disappear. That includes documentation for all GNU software and all of KDE, which is some of the most crucial documentation for users.
• Alienation of the FSF
Well, this bridge has probably already been burned, but removing all GFDL documentation from Debian will probably make it even less likely the FSF would take steps to improve the GFDL more to Debian’s liking.
• Heavy maintenance burden on Debian’s developers
All packages in Debian containing GFDL documents will have to be permanently forked from upstream–in other words, they’ll have to be repacked with the documentation removed. Then a new source package will have to be created to contain just the documentation to be uploaded to non-free. And that’s if the maintainer even bothers with the non-free stuff. I suspect most will just drop the documentation on the floor, never to be seen again.
• Far greater reliance on the non-free archive

The only positive benefit I can see is that some people get some warm fuzzies for sticking it to the FSF and interpreting our foundation documents as strictly as possible. Is that really worth it? Instead of crippling Debian, why not work gradually to improve the state of documentation? We could work on gradually convincing upstreams to dual-license documentation, which is particularly desirable given the GPL/GFDL incompatibility. We could setup a project to produce “really free” documentation to replace current GFDL documents. We could try to educate a wider audience on the problems of the GFDL–you do realize that most of the outside free software community views us as wacky license nazis, right? Producing a totally free operating system should be a goal, not an absolute requirement. It’s something we should strive for, but realize we’ll never achieve perfection since there will always be license problems in a set of software the size of Debian. But what are we going to do instead? Just remove the stuff that’s currently irritating us while ignoring the big picture. Good bye users, good bye useful operating system. It was nice knowing you.

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%.

The battery is dead, the TrackPoint is dead and its LCD backlight is starting to become flaky. So I figure it's probably time to think about replacing my ThinkPad 600X with a new machine and to pass the old one on to my mum who will find it much better than her 600E for writing e-mail. Hmm. The 600 series didn't go any further than the 600X so I guess I should consider one of those newfangled ThinkPads with a model number starting with a letter. First I need to check for Linux compatibility, of course, so I browse back... back... waaay back through the archives of the Linux-ThinkPad mailing list until I come to mid-2000 postings about the cool new T21 model. This looks adequate to my needs today and I see some units selling for about 300 on marktplaats.nl.

A recent post by Ingo Juergensmann lamenting m68k not making the cut in this round of architecture qualifications. While it is a shame I think, I don't think it's necessarily the end of the world and his complaint that developers will now stop fixing bugs is crazy. Just because they're suddenly not release critical doesn't mean (good) maintainers will be unwilling to fix them. Most architecture bugs are toolchain bugs (ie not the package maintainer's fault), general types of architecture bugs (eg endianess, int size) that affect more than one architecture and tend to get fixed quickly and easily and really freaking hard problems that most package maintainers don't have the skill to fix on their own (eg #343687, help!). But if someone submits a bug that's trivial to fix, or gives me a patch, that bug will get fixed. I don't like bugs in my packages and probably most other developers don't either.

For the first time in more that 10 days, I slept like a baby last night. It might hurt the xlibs-dev transition, but I hope it actually helps in the long run, I will make less mistakes, bug vorlon and dato a bit less, be more aware and awake. Now I just need to keep a balanced sleeping schedule again. I think have good allies.

I have started a small experiment that is against all rules but might spread some package love. So far, I have been successfully working with Victor Seva, Justin Pryzby, Thomas Viehmann and Nico Golde. Join us if you care about this transition!

On the other hand, I find recent threads in debian-devel, debian-private and several posts in debian-devel-announce very distracting. Although I am strongly opinionated on the subjects being discussed, I'd rather remain semi-silent and work in my "NMU love".