I usually don't blog about uploads to the Debian archive but since I don't know any similar software in Debian I do in this case.
nitrogen is a wallpaper selection and setting tool with both a graphical (with image preview) and text based frontend to set wallpapers and restore them later.
That's nothing special, there are some tools doing that.
But nitrogen also provides great multihead and xinerama support and is the only tool in the archive I know that is able to set different wallpapers to different monitors!

From the description:

nitrogen is a graphical wallpaper utility that can be used in two
modes, browser and recall.
Some of the things to look for in nitrogen are:
.
- Multihead and Xinerama support (setting different wallpapers for each monitor)
- Recall mode to restore wallpapers via startup script
- Uses freedesktop.org standard for thumbnails
- Can set GNOME background
- Command line set modes for script usage
- Inotify monitoring of browsed directories

Check it out

By now, I'm sure you all have read about the OpenSSL bug discovered in Debian.

There's a lot being written about it. There's a lot of misinformation floating about, too. First thing to do is read this post, which should clear up some of that.

Now then, I'd like to think a little about a few things people have been saying.

People shouldn't try to fix bugs they don't understand.

At first, that sounds like a fine guideline. But when I thought about it a bit, I think it's actually more along the lines of useless.

First of all, there is this problem: how do you know whether or not you understand it? Obviously, sometimes you know you don't understand code well. But there are times when you think you do, but don't. Especially when we're talking about C and its associated manual memory management and manual error handling. I'd say that, for a C program of any given size, very few people really understand it. Especially since you may be dealing with functions that call other functions 5 deep, and one of those functions modifies what you thought was an input-only parameter in certain rare cases. Maybe it's documented to do that, maybe not, but of course documentation cannot always be trusted either.

I'd say it's more useful to say that people should get peer review of code whenever possible. Which, by the way, did occur here.

The Debian maintainer of this package is an idiot, should be fired, should be banned

I happen to know that the Debian programmer that made this patch is a very sharp individual. I have worked with him on several occasions and I would say that kicking him out of maintaining OpenSSL would be a quite stupid thing to do.

He is, like the rest of us, human. We might find that other people are considerably less perfect than he.

Nobody that isn't running Debian or Ubuntu has any need to worry. This is all Debian's fault.

I guess you missed the part of the advisory that mentioned that it also fixed an OpenSSL upstream bug (that *everyone* is vulnerable to) that permitted arbitrary code execution in a certain little-used protocol? OpenSSL has a history of security bugs over the years.

Of course, the big keygen bug is a Debian-specific thing.

Debian should send patches upstream

This is general practice in Debian. It happens so often, in fact, that the Debian bug-tracking system has had -- for probably more than a decade -- a feature that lets a Debian developer record that a bug reported to Debian has been forwarded to an upstream developer or bug-tracking system.

It is routine to send both bug reports and patches upstream. Some Debian developers are more closely aligned with upstream than others. In some cases, Debian developers are part of the upstream team. In others, upstream may be friendly and responsive enough that Debian developers run any potential patches to upstream code by them before committing them to Debian. (I tend to do this for Bacula). In some cases, upstream is busy and doesn't respond fast or reliably or helpfully enough to permit Debian to make security updates or other important fixes in a timely manner. And sometimes, upstream is plain AWOL.

Of course, it benefits Debian developers to send patches upstream, because then they have a smaller diff to maintain when each new version comes out.

In this particular case, communication with upstream happened, but the end result just fell through the cracks.

Debian shouldn't patch security-related stuff itself, ever

Well, that's not a very realistic viewpoint. Every Linux distribution does this, for several reasons. First, a given stable release of a distribution may be older than the current state of the art upstream software, and some upstreams are not interested in patching old versions, while the new upstream versions introduce changes too significant to go into a security update. Secondly, some upstreams do not respond in a timely manner, and Debian wants to protect its users ASAP. Finally, some upstreams are simply bad at security, and having smart folks from Debian -- and other distributions -- write security patches is a benefit to the community.

As noted in the comments here, one reason to forcibly slow down the CPU on a system (and waste power in the long run) is to deal with cases where failing to do so can result in the machine overheating. Part of the problem is that Linux still tends to be less power efficient than Windows, and so various components will be generating more heat than when the machine was tested. The ACPI spec includes support for passive cooling of processors, which allows the system to reduce heat generation by slowing the CPU down. The problem is that not all vendors include a passive trip point in their firmware, and in the absence of one Linux will happily let the temperature rise until it hits a critical level and the machine shuts down.

I've written a patch that generates a passive cooling trip point if your firmware doesn't provide one. Since there won't be a firmware event when the temperature crosses the trip point, it also forcibly enables polling (the spec actually requires this, so I've no idea why Linux doesn't do it anyway). The default polling interval is quite long - you can adjust it in /proc/acpi/thermal_zone/*/polling by just echoing in a value in seconds. I've gone for a long delay in order to reduce any possible power consumption issues caused by this, but in the long run I'd like it to reduce the polling interval if the temperature trend is upwards and increase it again if the trend is downwards.

The patch makes the assumption that you're never going to get within 5 degrees of the critical temperature in normal use, which I think is pretty reasonable. The probability that the machine will reach equilibrium at that point is fairly small, so if you get that close you'll almost certainly end up with a powered down machine unless we do something about it (like forcibly downclocking your CPU). I don't have any affected machines, so I've only been able to test it by artificially lowering the trip point - if people find that it still lets the processor get over temperature without attempting to slow it down first, then I'll probably need to implement the more advanced polling policy.

In any case, I'm interested in feedback.

Ok, shit sometimes also happens to Debian users. Now I read a lot of FUD, flames, arrogant claims and much more bad things, including blaming of downstream in general. Well, Debian maintainers are NOT upstream authors. Maintainers often care about a lot more than just 1 package. Now I wonder if one can really expect, that maintainers know the source code of their packages as good as upstream authors do? Is this, what the user or the Debian project expects from a package maintainer? I agree, that this would be the ideal situation. But how realistic is it, if one maintains 10, 20 or more packages? Normally users report us issues. We take a look at the source, try to catch the issue, track it down and fix it. And IMHO in almost all cases this is enough and it lets us handle several packages. And maybe this is also, what happened here. The maintainer got a report, tracked it down and tried to fix it. It seems, he posted it to the openssl-dev list, which is to my reading considered for such questions, and got a positive response. And with fixing it, he made a horrible mistake. But apparently it also seems, that the question had been discussed earlier more than just once (I wish, the OpenSSL guys would have created the FAQ entry earlier). I don’t want to blame the maintainer for doing this mistake. We are humans. But do we need another instance, that (periodically) checks (probably only Debian-specific) patches/changes to security relevent software or do we need different requirements for maintainers of such software [1] or should we simply archive this under “Shit sometimes happens … even to Debian users”? [1] Consider gnupg which is currently almost unmaintained. It also has Debian specific patches applied and I wonder, which skills the new maintainer should or must(?) have (IIRC this question was raised in the linked threads too)?

See this article, Baby boom link to rise in child-welfare cases at The Age web site. What a great legacy for John Howard - his “baby bonus”, a grubby and cynical vote-buying exercise for the 2004 Federal Election has resulted in a mini- baby-boom. It has also resulted in a more than 66% increase in interventions by the Child Protection Agency (from 600 in 2000-2001 to over 1000 last financial year). And that’s just from the first few batches of baby-bonus babies. Perhaps the people who think a $3000 “bonus” (as introduced in 2004, now increased to $5000) is a good reason to have a baby are precisely the kind of people who shouldn’t be having babies. “Cool, $5000 if i have a baby”. or worse, “Cool, $5000 if i make my girlfriend have a baby”. Great reasons to have a baby. Thank you, Mr Howard. At least we now all know the answer to the question “How many abused and neglected babies is a vote worth”? Syndicated from Craig Sanders' Errata: Tech Notes and Miscellaneous Thoughts Howard’s Child Protection Babies

How to generate bootable USB keys with simple-cdd simple-cdd is a lovely piece of software that builds a custom D-I image with the package selection and preseeding of your choice. Today I was asked to build a bootable USB key with the simple-cdd image. Here is how; the general case is described in the d-i manual: General USB key preparation:

1. download vmlinuz and initrd.img from hd-media
2. apt-get install syslinux mtools mbr
3. Partition the USB key as needed (from now on, I'll assume the usb key is in the device /dev/sdb1)
4. Format it as FAT: mkdosfs /dev/sdb1
5. Put the boot loader in it: syslinux /dev/sdb1
6. Put the MBR in it: install-mbr /dev/sdb
7. Mount it: mount /dev/sdb1 /mnt
8. Copy kernel and initrd: cp vmlinuz initrd.img /mnt/

simple-cdd specific part:

1. Run build-simple-cdd as usual
2. Copy the ISO file generated by build-simple-cdd in the USB key. Any name will do, as long as it ends in .iso the installer will find it
3. Configure the boot loader, fetching the kernel command line out of the cdrom boot loader generated by simple-cdd:
   • echo default vmlinuz > /mnt/syslinux.cfg
   • grep append tmp/cd-build/etch/boot1/isolinux/isolinux.cfg head -1 sed -e 's/^\t//' -e 's/ initrd=[^ ]*/ initrd=initrd.gz/' >> /mnt/syslinux.cfg

This is it, it works nicely, perfectly scriptable, tested today.

DSA-1571 is totally embarrassing. But I disagree with Julien BLACHE: we don’t need a new openssl maintainer. Mistakes sometimes happen to people who do things. That sucks, but it’s unavoidable, no matter how many levels of checking you add. Kurt has done a lot of excellent work on Debian in the past years, and I’m sure he will continue. Of course, it’s a lot easier and less risky to write tons of stupid blog posts. By the way, Julien, there’s an RFH bug for openssl open for more than 2 years. What about getting involved and helping Kurt yourself? On a more constructive side: it’s not the first time that a Debian-specific change broke something (I can think of a recent grep change …). It might be useful to provide a simpler way to review those changes (reading the diff.gz files is not really user-friendly). We could have something like http://patches.ubuntu.com/ (or even something nicer :-).

Just the other day I was wondering about what release of Debian a specific version of a package was in, and I knew it was older than oldstable. But searching the Packages files of archive.debian.org was tedious and I thought that there has to be better way. So I quickly set up a packages.debian.org instance for archive.debian.org at archive.debian.net I guess this isn't really interesting for the day-to-day use, but maybe someone can ocassionally profit from it. Caveats:

• There are no binary files on archive.d.o for rex and buzz, so currently no information is available about them.
• There are no Sources files available for rex, buzz and bo, only Packages, so no information about the source packages can be presented.
• The two above point of course mean together that there is no usable information at all about rex and buzz. If someone would create the missing indices and convince the ftp-masters to put them on archive.debian.org, I will gladly configure archive.debian.net to use them.
• Changelogs and copyright files are currently only available for pool-using releases, since the extraction script has some assumptions that depend on that. On archive.debian.org, the only release that uses pool/ is woody.

Feel free to help me improve that site, preferably by sending patches against the archive-master branch of git://git.debian.org/git/webwml/packages.git.

A little off-topic exercise conducted in the "eye of the storm", when Ilenia and Helen were still in the hospital: A post on Seth Robert's blog brings up the idea that many Chinese restaurants were opened as a way to go into business without competing with native male workers. The post made the rounds of several other online journals. That was the push I needed to get up and go collect a few statistics of my own, regarding an idea I've been kicking around for a while. My theory is that the number of restaurants of a given type, divided by the number of immigrants from that country might be an interesting way of guaging the popularity of the cuisine in question. In order to simplify things just a bit, I actually used data from Italy, for the following reasons:

• Most immigration to Italy is pretty recent, so it's not necessary to account for the length of time different immigrant groups have been present, and the effects that may have had on the diffusion of a given cuisine.
• Immigration statistics were readily available: http://demo.istat.it/str2006/index.html
• Italian the language almost completely corresponds to Italy the country (outside of a chunk of Switzerland, San Marino, and the Vatican), something that makes things that much easier.
• I speak Italian, so it was easy to find out all the information I needed

Unfortunately, finding out the number of restaurants of various types is far from an exact measurement, and since this is a quick fun project, I just went for Yahoo search (they deserve credit for keeping their search API open when Google's was closed) results on terms like "Ristorante Turco" (Turkish), "Ristorante Messicano" (Mexican), and so on. This was the most expedient means of gathering information quickly, but this approach does present a number of obvious problems, listed here in the hope that someone without diapers to change and a business to run might come up with some good answers:

• Some hits likely come from people talking about a restaurant that happens to be in a country, like "ristorante americano". "Nel tipico ristorante americano, ...." or in other words, "In a typical American restaurant", rather than an American-style restaurant in Italy, which is what we were looking for in the first place. This is probably also true of countries close to Italy, where people go on vacation and thus have occasion to write about their experiences in a "ristorante tedesco" (German), rather than going to eat in a German restaurant in Italy. Perhaps the search query could be improved in an attempt to eliminate this sort of false positive.
• Some restaurants probably are not known as, nor brand themselves with a country name, but instead utilize titles like "Middle Eastern", "Arab", "South American", "African", or others that do not correspond with any one country in particular. It would be possible to group countries together with other adjectives, and get statistics for these clusters as well.
• Measuring hits is measuring what people are talking about, rather than simply restaurants that exist, so if restaurants from a certain country are more talked about than others, that would muddy the statistics a bit. However, it seems reasonable that people would mostly talk about restaurants in proportion to their popularity, and I don't see a particular reason why there would be more talk of Vietnamese restaurants, say, than Thai restaurants, compared to the actual numbers.

That said, for a quick project, this approach seemed to work out ok, and the results appear credible. Obviously, the results also reflect people discussing certain cuisines, rather than an actual number of restaurants, but since it does reflect interest, we'll use the number in any case. Since the number of restaurants/interest in a type of restaurant was clearly not correlated directly with the number of immigrants, other factors must come into play. For instance, "ristorante giapponese" turns up 125,000 hits, but the stats say only 6873 Japanese nationals live in Italy. As above, hits don't mean actual restaurants, but clearly Japanese cuisine is not being popularized through immigration. Here's my guess: these statistics show, to some degree, what people in the host country actually like to eat. Food that tastes good means more restaurants. Things that aren't that popular mean few restaurants, even if there are many immigrants. To pick on one country, there are many Philippino immigrants in Italy, but very few search hits - and anecdotally, I've never seen a Philippino restaurant in Italy either, whereas even smaller towns like Padova have Chinese, Mexican (well, it's called that, even if it's a shadow of the real thing), Japanese, various Arab and middle eastern restaurants, and even a few less common things like Eritrean. And I know that many native and foreign restaurants employ Philippino cooks. Below is the chart I whipped up showing the number of Yahoo hits per immigrant. The Italian names shouldn't be too hard to figure out. A few tricky ones: Giordano-Jordanian, Giamaicano-Jamaican, Spagnolo-Spanish. If you're interested in numbers or source code, contact me.

We've had two serious bugs on the NSLU2 recently that both caused the system not too boot anymore. The first one was related to initramfs-tools. Kevin Price reported that after upgrading to initramfs-tools 0.92 the system would hang during boot waiting for the root filesystem. When I booted my NSLU2 and looked at the output, I noticed that no root device was set. When I mentioned this to maks, the maintainer of the initramfs-tools package, he immediately knew what was wrong and uploaded a fix. On the NSLU2, the boot loader doesn't pass a root device to the kernel so we set one in the initramfs itself. The code that loads this config variable is not used by many devices so nobody noticed that this got broken in 0.92 until the package moved to testing. The second problem, reported on Saturday by Paul Collins and diagnosed today with some help from Kevin Price is also related to the strange way the NSLU2 boots. The NSLU2 has 6 MB available for the ramdisk but due to a bug in APEX (the second stage loader used on the NSLU2 by Debian) only 4 MB are actually used. When you write a ramdisk that is larger than 4 MB but smaller than 6 MB, flash-kernel will happily write the full image, but APEX will only tell the kernel about the first 4 MB. As it turns out, everything works fine on arm with 2.6.25, but on armel some additional SCSI modules are enabled that result in the ramdisk becoming too large. The short term solution is to disable these modules, but really APEX should finally be fixed (patches have been available for quite a while thanks to Gordon Farquharson). Fortunately 2.6.25 hasn't moved to testing yet and this problem only occurs on armel, so few people were impacted. The nice thing about the NSLU2 is that you can write a new flash image via the network, so you can flash a good image in case your machine no longer boots. Nevertheless, we have to make sure such serious bugs don't occur in the future or that they are at least caught very early. Special thanks go to testers like Kevin Price.

I'm just back from a trip to Cuba. Sorry for the abrupt disconnect. I expected to have limited connectivity there, whereas I actually had none at all except for 23 minutes! I hope the other members of the cooperative and the editorial team stepped in suitably well. I'll check in with them now and then start on the emails, but I wanted to put this broadcast out first for those who are watching closely and wondering...

You might have already heard of it — the new Nine Inch Nails album "The Slip" has been released by them under the Creative Commons BY-NC-SA 3.0 US license. Yep, that's right, it's totally legal to download it from the web — and use it for any non-commercial purposes! It's a bit annoying that they want your email address, though. Nothing that bugmenot.com (or similar) cannot fix, but still. Luckily, the files are now also available from archive.org! This, and the fact that the music is CC-licensed allowed me to "play" one of the songs in my Creative Commons music podcast (RSS), and more will likely follow.

Something I never really mentioned was the purchase of the foldable bike: a Dahon with a reasonably lightweight aluminum frame, a seven-speed hub and high-pressure tires. It's great fun in the city for the rides to and from the commuter train, or across downtown for occasional errrands after work. I have had this foldable bike for nearly two years, and used it almost (work-)daily, even in the Chicago winters. 'Almost' because I did suffer from broken parts on a few occassions: a pedal broke (easy replacement), the axis in the front wheel broke (a good week for a new and inexpensive wheel) but the bummer was that a part of the frame-folding mechanism broke last fall. Given that the bike, which I bought used via craigslist, is a few years old, the part was no longer standard and so we waited for it to be shipped from the manufacturer. And waited and waited some more until Dan's decided to give me a matching part from a bike in their inventory. But apart from that episode, and the occassional problem with conductors on the Metra commuter trains, it has been a smooth ride. Highly recommended, and I do see a few more foldable bikes downtown. But what is new now is that I finally gave in and bought a road bike, once again off craigslist. My daily commute is about ten miles one-way, which works out to about 35 to 40 minutes of cycling, plus a few minutes of locking/un-locking, changing, etc. I had used my trusted (yet heavier) touring bike with its steel frame a number of times, but felt that a road bike may make for a faster ride. While it saves a few minutes, it is not really a time saver as the bike-train-bike commute also takes around 40 to 50 minutes. That said, riding is simply a nice way to clear the head before or after work. I am back on the schedule I tried for a few weeks last summer / fall: running on Tuesday and Thursday leaves Monday, Wednesday and Friday for the bike commute. So far, I am 8 for 9 over the last three weeks. On the downside: one rather wet ride home, and already to minor flats that (luckily) still allowed riding home. The hardest part is meeting up with some other riders at 6:00am meaning that I am now getting up at 5:00am whether I am running or not. But all told a nice way to get some exercise in outside of running.

Modern CPUs are great. They have all sorts of advanced power saving features, which is one of those nice cases where everyone can save money, gain performance and claim environmental credentials at the same time. Everyone's a winner.

Well. Everyone's a winner as long as your software doesn't suck.

I've talked about the benefits of the tickless kernels and reducing wakeups and spending longer in deep C states before, so if you don't know about them then go and read that first. This time I'm going to focus on a different level of hardware, and a different level of suck.

For a long time, laptops supported changing the speed of processors when switching between AC and battery. CPU power consumption is proportional to frequency, so dropping the frequency meant a longer battery life. Of course, it also meant that it took longer to get anything done - the reason this was still a win was because CPUs in those days consumed just as much power when idle as when running. Transmeta introduced a technology called Longrun with their Crusoe processors, bringing the ability to drop both the frequency and the voltage of the CPU simultaneously. With power consumption being proportional to the square of the voltage, even a small drop resulted in worthwhile power savings. As the only really worthwhile thing Transmeta brought to the x86 world[1], this was unsurprisingly ripped off by everyone else. Intel introduced their Enhanced Speedstep, AMD gave people PowerNow and VIA have Longhaul.

Obviously, reducing the frequency of the CPU increased battery life. Everyone's happy?

No[2].

The problem is that nowadays, processors don't consume as much energy when they're idle as when they're running. The aforementioned C states mean that an idle processor consumes a tiny percentage of a loaded one - an ultra-low voltage Intel part will draw on the order of a watt. Executing code, even at the lowest voltage and frequency, will draw far more power. Obviously, we want to keep the processor idle for as long as possible. The easiest way to do this would be to never run anything, but that's not a real option. The alternative is to run when we have to, but make sure that we get it over with as quickly as possible so we can return to the idle state. Counterintuitively, that means switching to the highest voltage and frequency, executing the code and then dropping back into the idle state. By going faster, we save power[3].

In summary, the only sensible way to use a CPU is to run it as fast as possible in order to let it idle as much as possible, and drop the frequency and voltage when it's not doing anything. The. Only. Sensible. Way.

Some people write software that lets you choose different power profiles depending on whether you're on AC or battery. Typically, one of the choices lets you reduce the speed of your processor when you're on battery. This is bad. It is wrong. The people who implement these programs are dangerous. Do not listen to them. Do not endorse their product and/or newsletter. Do not allow your eldest child to engage in conjugal acts with them. Doing this will reduce your battery life. It will heat up your home. It will kill baby seals. The sea will rise and your car will float away. If you are already running it, make sure that it always sets your cpufreq governor to ondemand and does not limit the frequencies in use. Failure to do so will result in me setting you on fire[4].

The only legitimate reasons for limiting the speed of your CPU are to avoid overheating (which should be fixed in the kernel, really - having userspace in charge of ensuring the continued functioning of the machine is madness) or to make the machine quieter. And if you want your machine to be quieter, there should be a tickbox marked "Reduce performance in order to reduce noise" or something, which would take into account all the sources of heat in your machine rather than just your CPU. Encouraging the managing of acoustic levels by asking users to restrict the functionality of their CPU is just another way of saying "Look! We suck!". Letting the user choose a specific CPU governor or a specific frequency is not a useful thing to do. Don't do it unless you want to see dead kittens. Delivered by UPS.

[1] And, presumably, whatever else Intel and everyone else ended up licensing off them which resulted in their reinvention as an IP company rather than a CPU one, but that's just not interesting to me.

[2] Even ignoring the people that are unhappy for entirely unrelated reasons, such as injured toenails or the brutal murder of their family

[3] There's a corner case here, which is a system that is always entirely CPU bound. Say we halve the CPU's speed. Along with the voltage drop, that gets us down to about 20% of the original power consumption. Of course, it now takes twice as long to do anything and your screen, RAM, hard drive, chipset and so on are still drawing power, so will end up costing you twice as much power as they would have done if you'd run at full speed. If you do the maths, it works out that you save power if your processor's full-speed power consumption is more than 1.7 times that of the rest of the platform. In the real world, things are made more complicated by the rest of your platform consuming more power if you're working over a longer period of time - your hard drive is going to end up spending more time spun up, your memory bus is going to be active for longer and so on. You're basically not going to hit this case.

[4] While the burning of your body will result in carbon emissions, the reduction in power usage should offset this in the long run

Some more stats: $VCS distribution for Debian packaging I've set up yet another stat page, this time it's about the distribution of $VCS for Debian packaging. It's as trivial as you can imagine: it gets all the Vcs-XXX fields out of unstable Sources and plot how many packages are using a given $VCS. I've got no surprises in the relative popularity of $VCS: subversion is clearly the most widespread (with about 2700 packages on a total of about 13000) and git is growing (700 packages); with the exception of bzr (90 packages), all the other are used by less then 50 packages. Thanks to Lucas I've also included graphs in the page, as I think it would be interesting to monitor the evolution. (Probably as everybody) I'm confident to see an increasing trend for git balanced by a decrease of subversion, we'll see. The total number of packages using some $VCS is encouraging, we are at about 29% of the archive (you know that if your package is not declearing some Vcs- headers in its source stanza I'm not counting it, right? Go add the headers!). Interesting side effect: as I'm now maintaining a handful of these stat pages, I was pondering hey, we should create a wiki page with pointers to all the stat pages about Debian we have . Well, in fact it already exists: Statistics on wiki.d.o.

Some of you might have noticed that in the recent weeks I wasn't active at all online. This was because I was on a vacation in Italy. On the way back I was eager to write about my experiences, but after entering Romania, I found out that may parents had been involved in a motorcycle accident due to a careless driver.

The accident took place on the second day of the Orthodox Easter (on the 28th of April)[1] while my parents were coming back from my sister's, just 20 km away from my home town, Caracal, in a village called Z noaga. There, a Daewoo Cielo was parked on the left side of the road[2], facing the direction towards Caracal. The driver decided that it was a good idea to turn his vehicle and, according to his declaration, instead of looking himself if there was anything comming, he asked a passenger if there were any cars comming.

Since a motorcycle is not a car, I guess the passenger thought it was OK to answer "no".

So the driver simply started his maneuver and managed to occupy the entire right lane, according to the accident schematics (I saw the official police schematics of the accident site with my own eyes). There were only 30 cm from the front most point of the car to the ditch on the right side of road, while the rear wheels were on the mark indicating the axis of the road. That left only 2 meters free on the opposite lane out of the 6.60 meters wide road, so there was no way for my father (driving the motorcycle) to avoid the collision, in spite of the fact he was travelling at about 40-50 km/h[3], within the legal speed limit (50 km/h).

My father barely had enough time to avoid the central pillar and aim for the rear right door of the car, obviously, a safer place to hit. Still, this wasn't enough to keep my mother on the motorcycle, a safer place for her than anywhere on the road.

My mother was projected over my father and over the car, and, luckily, landed on the side of the road, between the asphalt and the ditch, on an area covered with grass. She landed straight onto her head (the helmet protected her really well), and the shock of the landing propagated along the spine, resulting in the fracture of the L1 vertebra. She also got a fissure in the right clavicula, but that should already be OK now.

My father managed to remain on the motorcycle, but the impact was violent enough that he managed to bend the gas tank and has two huge bruises on the inside of his thighs (one for each leg). He also accuses pains in his shoulders and the lower end of the spine (unfortunately he "managed" not to do the medical investigations after the accident), but I hope all of these will pass soon and will have no ill effects. Also, out of sheer luck, at that time, my father was wearing a full-face helmet, contrary to his habit of earing an open-face helmet; due to this, his face was protected and suffered no harm, while the chin of the helmet broke after the impact with the motorcycle windshield. Also some deep scratches starting from the half of the helmet windshield up to the top of the helmet were the signs of a (probably second) violent impact with the motorcycle windshield.



So, the next time you are on the wheel, please look out for motorcycles, too. Motorcycles do exist on the road!

Also, I advice anyone driving a motorcycle to wear good protection equipment like a full-face helmet, jacket, pants, boots, gloves, etc. These helped a lot my parents, and will help you too, if, God forbid, you are involved in an accident.


My mother is in a cast that covers her from hips to shoulders to help with the fracture recovery and also wears a collar (just for safety reasons since she is suffering of spondyloses).
My father is able to walk (with some pain) and seems not to have any injures (I will take him for a close investigation some time soon in spite of his stubbornness).



[1] worrying for us (me and my future spouse), my parents didn't told us and waited for us to return to Romania
[2] in Romania the vehicles travel on the right side of the road, so the driver also drove on opposite lane, a fact which, according to the law, is punished with the suspension of the driving license
[3] he speed was confirmed by the measurements done by the police

A survey has shown that 16% of youth doesn't know why we're celebrating the 5th of May. According to quality news show Editie NL, this is a worrying fact. Well, is it? I find it rather reassuring that appearently 84% of the younger generation do know that 5 May is about the libration from German occupation (I remember now that I forgot to thank the Canadiens when I was there two weeks ago). 16% is not much: if you get a 16% discount you're usually not making a great deal. Actually, I would be very surprised of a survey that would show that less than 16% of people are completely ignorant of the world around them. These same people probably would't know the connection between the colour of the national team's shirts and the royal house, or be able to tell whether St Nicolaas is a protestant or catholic. Or the ones that claim money because -6 is larger than -5. Every country has its fair share of "challenged" people. Also in recent news is that Barack Obama is losing votes because he admitted to eating rucola (arugula) from time to time. Voter's "reasoning" boils down to "if I don't know what that is, then a president that eats it can't be trusted". It gets even more sad when you realise that these people probably do know it, but don't realise they call it rocket. Great way to lose votes.

A survey has shown that 16% of youth doesn't know why we're celebrating the 5th of May. According to quality news show Editie NL, this is a worrying fact. Well, is it? I find it rather reassuring that appearently 84% of the younger generation do know that 5 May is about the libration from German occupation (I remember now that I forgot to thank the Canadiens when I was there two weeks ago). 16% is not much: if you get a 16% discount you're usually not making a great deal. Actually, I would be very surprised of a survey that would show that less than 16% of people are completely ignorant of the world around them. These same people probably would't know the connection between the colour of the national team's shirts and the royal house, or be able to tell whether St Nicolaas is a protestant or catholic. Or the ones that claim money because -6 is larger than -5. Every country has its fair share of "challenged" people. Also in recent news is that Barack Obama is losing votes because he admitted to eating rucola (arugula) from time to time. Voter's "reasoning" boils down to "if I don't know what that is, then a president that eats it can't be trusted". It gets even more sad when you realise that these people probably do know it, but don't realise they call it rocket. Great way to lose votes.

A common rant against Launchpad is that it s closed: the code is proprietary, and Canonical doesn t give raw access to the data they collect via the interface. Anyway, other people have taken up this issue, and it s not the point of this post to do so. I ve heard two argument why Launchpad is closed: first, it s a test bed for a product, which Canonical hopes to market to commercial entities to manage their own release cycles. And second: it s purposely cross-project and tries to integrate and link between them. Thus, lots of instances of Launchpad would defeat the point. I ll address these points in turn, starting from the back: While I won t deny a pre-trend towards (back to) mainframe-like computing, with Google, Amazon, and others providing rent-a-computer-cycle services. In addition, environmental concerns cast clouds over the 400W heating appliance under your desk, which happens to run your word processor and browser when it doesn t lose track of its countless spare cycles. Yet, I maintain that centralised services, such as Launchpad are a thing of the past. If you ask me, Launchpad got it wrong, even though it s light years further than its predecessors. It features pleasant graphics and obviously has had lots of smart thinking and experience shoved into it, but it s still centralised. It might be a business case, but it s not what the world needs. We ve seen massive growth of decentralised approaches to classic services, from file sharing to version control, from number crunching to simple web browsing, and yet, there s Launchpad, single point of entry (and failure) to the world of data surrounding Free software (at least if you follow their vision). What we need is something as slick as Launchpad, and thousands of instances thereof, which all peer with each other, automatically. The information would automatically be mirrored wherever it s referenced, so the entire cloud would be highly-available and failure-proof. Obviously, this wouldn t render itself well to the (traditional) software business model Canonical seems to strive for, so they re unlikely to go down this route. But we could. It would be a non-competitor. Update: thanks for the copious feedback I ve received. Among them was a comment by [Elliot Murphy]](http://launchpad.net/~statik), who speaks of us and thus leads me to believe that he s part of the Launchpad team:

We re definitely listening, and we still have lots more improvements we want to make. Our goal is collaboration, not centralization: thats why we build bazaar, are working busily on doing two-way integration with other bug tracker systems, and are building the best API we can. Our goal in the team is to make it trivially easy for you to get all the data that you put into launchpad back out through the API, data portability is very important. There is no big evil business model, but it would be socially irresponsible if we did not work toward making launchpad self-sustaining. It has been a long road, but the launchpad team is steadily working toward a distributed model, one step at a time.

While it s definitely nice to hear that data portability is a concern to them, I don t see Debian using Launchpad without the ability to run it on our own servers. I m definitely curious to hear more about the distributed model the team is pursuing. I certainly don t have a problem with self-sustainability, but in the Free software world, I do wonder what that is supposed to achieve. Release early, release often, anyone? Update: Philip Newborough took up the issue and has received a number of noteworthy replies. It made me very happy that he sees my post as a rant about Launchpad which is not lambasting Canonical for their proprietary Launchpad software; I wasn t aiming for any lambasting. NP: Nine Inch Nails: Further Down the Spiral