Edited to add: Sorry, it turns out that ext4 does now have a heuristic to deal with this case. However, it seems that btrfs doesn't. My point remains, though - designing a filesystem in such a way that a useful behaviour is impossible is unhelpful for the vast majority of application writers, even if it does improve performance in some other use cases.

Further edit: It's mentioned in the comments that btrfs will force a flush of data when a rename is performed as of 2.6.30. That prevents the data loss, but it means that we're still stuck with disk access when we'd be happy with that being batched up for the future. It feels like we're optimising for the wrong case here.

Original text:

There's been a certain amount of discussion about behavioural differences between ext3 and ext4[1], most notably due to ext4's increased window of opportunity for files to end up empty due to both a longer commit window and delayed allocation of blocks in order to obtain a more pleasing on-disk layout. The applications that failed hardest were doing open("foo", O_TRUNC), write(), close() and then being surprised when they got zero length files back after a crash. That's fine. That was always stupid. Asking the filesystem to truncate a file and then writing to it is an invitation to failure - there's clearly no way for it to intuit the correct answer here. In the end this has been avoided by avoiding delayed allocation when writing to a file that's just been truncated, so everything's fine.

However, there's another case that also breaks. A common way of saving files is to open("foo.tmp"), write(), close() and then rename("foo.tmp", "foo"). The mindset here is that a crash will either result in foo.tmp being zero length, foo still being the original file or foo being your new data. The important aspect of this is that the desired behaviour of this code is that foo will contain either the original data or the new data. You may suffer data loss, but you won't suffer complete data loss - the application state will be consistent.

When used with its (default) data=ordered journal option, ext3 provided these semantics. ext4 doesn't. Instead, if you want to ensure that your data doesn't get trampled, it's necessary to fsync() before closing in order to make sure it hits disk. Otherwise the rename can occur before the data is written, and you're back to a zero length file. ext4 doesn't make guarantees about whether data will be flushed before metadata is written.

Now, POSIX says this is fine, so any application that expected this behaviour is already broken by definition. But this is rules lawyering. POSIX says that many things that are not useful are fine, but doesn't exist for the pleasure of sadistic OS implementors. POSIX exists to allow application writers to write useful applications. If you interpret POSIX in such a way that gains you some benefit but shafts a large number of application writers then people are going to be reluctant to use your code. You're no longer a general purpose filesystem - you're a filesystem that's only suitable for people who write code with the expectation that their OS developers are actively trying to fuck them over. I'm sure Oracle deals with this case fine, but I also suspect that most people who work on writing Oracle on a daily basis have very, very unfulfilling lives.

But anyway. We can go and fix every single piece of software that saves files to make sure that it fsync()s, and we can avoid this problem. We can probably even do it fairly quickly, thanks to us having the source code to all of it. A lot of this code lives in libraries and can be fixed up without needing to touch every application. It's not the end of the world.

So why do I still think it's a bad idea?

It's simple. open(),write(),close(),rename() and open(),write(),fsync(),close(),rename(), are not semantically equivalent. One is "give me either the original data or the new data"[2]. The other is "always give me the new data". This is an important distinction. fsync() means that we've sent the data to the disk[3]. And, in general, that means that we've had to spin the disk up.

So, on the one hand, we're trying to use things like relatime to batch data to reduce the amount of time a disk has to be spun up. And on the other hand, we're moving to filesystems that require us to generate more io in order to guarantee that our data hits disk, which is a guarantee we often don't want anyway! Users will be fine with losing their most recent changes to preferences if a machine crashes. They will not be fine with losing the entirity of their preferences. Arguing that applications need to use fsync() and are otherwise broken is ignoring the important difference between these use cases. It's no longer going to be possible to spin down a disk when any software is running at all, since otherwise it's probably going to write something and then have to fsync it out of sheer paranoia that something bad will happen. And then probably fsync the directory as well, because what if someone writes an even more pathological filesystem. And the disks sit there spinning gently and chitter away as they write tiny files[4] and never spin down and the polar bears all drown in the bitter tears of application developers who are forced to drink so much to forget that they all die of acute liver failure by the age of 35 and where are we then oh yes we're screwed.

So. I said we could fix up applications fairly easily. But to do that, we need an interface that lets us do the right thing. The behaviour application writers want is one which ext4 doesn't appear to provide. Can that be fixed, please?

[1] xfs behaves like ext4 in this respect, so the obvious argument is that all our applications have been broken for years and so why are you complaining now. To which the obvious response is "Approximately anyone who ever used xfs expected their data to vanish if their machine crashed so nobody used it by default and seriously who gives a shit". xfs is a wonderful filesystem for all sorts of things, but it's lousy for desktop use for precisely this reason.

[2] Yes, ok, we've just established that it actually isn't that in the same way that GMT isn't UTC and battery refers to a collection of individual cells and so you don't usually put multiple batteries in your bike lights, but the point is that this is, for all practical intents and purposes, an unimportant distinction and not one people should have to care about in their daily lives.

[3] The disk is free to sit there bored for arbitrary periods of time before it does anything, but that's fine, because the OS is behaving correctly. Sigh.

[4] Dear filesystem writers - application developers like writing lots of tiny files, because it makes a large number of things significantly easier. This is fine because sheer filesystem performance is not high on the list of priorities of a typical application developer. The answer is not "Oh, you should all use sqlite". If the only effective way to use your filesystem is to use a database instead, then that indicates that you have not written a filesystem that is useful to typical application developers who enjoy storing things in files rather than binary blobs that end up with an entirely different set of pathological behaviours. If I wanted all my data to be in oracle then I wouldn't need a fucking filesystem in the first place, would I?

Since a recent update of one of my systems, amavisd-new keeps on spamming me. I get mails containing stuff like bayes: synced databases from journal in 0 seconds: 674 unique entries (742 total entries). The reasons seems to be a cronjob from amavisd-new (which can be deactivated via debconf):

grep amavisd-new-cron /etc/cron. d,daily /*
/etc/cron.d/amavisd-new:18 */3  * * *   amavis  test -e /usr/sbin/amavisd-new-cronjob && /usr/sbin/amavisd-new-cronjob sa-sync
/etc/cron.daily/amavisd-new:test -e /usr/sbin/amavisd-new-cronjob && exec /usr/sbin/amavisd-new-cronjob sa-clean

However, the called script contains:

egrep "sa-sync\) sa-clean\)" -A 2 /usr/sbin/amavisd-new-cronjob
        sa-sync)
                do_amavis_cmd "/usr/bin/sa-learn --sync >/dev/null"
                ;;
        sa-clean)
                do_amavis_cmd "/usr/bin/sa-learn --sync --force-expire >/dev/null"
                ;;

Note that output is redirected to /dev/null, so I should only mails if an error occurs, shouldn't I? I'm really baffled... To the best of my knowledge I shouldn't get these mails. Where am I wrong, and how to formulate that in a bug report?

So, Kodak announced the availability of Linux drivers for some of its scanners, together with a frontend application. While the effort is laudable, they re not quite there yet. Let s have a look. First of all, and contrary to what a few people believe after reading the press release, the drivers themselves aren t OpenSource, let alone Free Software. They re all proprietary; read better, the press release clearly mentions that only the frontend application is GPLv2. Now let s look at what Kodak offers in its drivers packages. I ve downloaded LinuxSoftware_i1200_v3.5.tar.gz from the Kodak website, these are the drivers for the Kodak i1200 series. The archive contains a set of RPM packages, one Debian package corresponding to one of the RPM packages, and a setup script. One of the packages contains the OpenUSB library, which is released under the LGPL; sources aren t there, I haven t asked for the sources, don t plan on doing so, and am not implying anything regarding license compliance whatsoever. I ll note that I haven t seen any written offer for the sources, though, be it in the archive (there s not even a README in there) or on the website. So, although Ubuntu is listed as supported, we can say that no Debian packages are provided. The setup script actually relies on alien to convert them if it thinks it s running on a Debian-based system, which is determined by the availability of dpkg in the PATH. Using alien is far from ideal. The packages ship libraries and components under /usr/lib, /usr/local/lib and even /opt, pretty randomly it seems. Let s repeat here that /usr/local and /opt are strictly reserved for the local administrator and packages must not install anything here. There are other oddities in the paths used by the software stack, like /var/kodak. It looks like the SANE backend is only a bridge to Kodak s TWAIN data source, so you d actually need the whole stack to use it. All in all, Kodak does no better, I d even venture to say it does worse, than Epson (Avasys). At least part of Epson s backend is Free Software, even if it relies on proprietary libraries for some scanners, though unfortunately most if not all of the recent ones. I also have to mention that Epson is offering both RPM and Debian packages, and by that I mean proper Debian packages. Kodak are far from that, even the RPM aren t that great (I think the RPM packages even lack dependency information, based on what I ve read in the setup script, though I haven t checked). What Kodak offers here is a GPL frontend for TWAIN that not many people will be using, while keeping the drivers proprietary. Unfortunately their SANE backend isn t a backend so to speak, and even if it was OpenSource it d still rely on the rest of the TWAIN software stack. So, in a nutshell, while I m very happy to see yet another vendor go down the road of Linux support for its products, I am immensely disappointed by the proprietary nature of the drivers and the low quality of the packages. I was, of course, investigating the drivers to possibly package them for Debian; as you ve probably understood, it s not possible, both technically and legally. And I kept a little gem from the setup script for the end:

# We need to create a link for the libdbus-1 requirement for openusb,
# but only on Fedora.
if [ -f /etc/fedora-release ]; then
    ln -s /lib/libdbus-1.so.3 /lib/libdbus-1.so.2 2>> /dev/null
fi

As we all know, sonames and soversions are useless and they just keep getting in the way. Duh.

A recent Ubuntu bug has gotten slashdotted, and has started raising a lot of questions about the safety of using ext4. I ve actually been meaning to blog about this for a week or so, but between a bout of the stomach flu and a huge todo list at work, I simply haven t had the time. The essential problem is that ext4 implements something called delayed allocation. Delayed allocation isn t new to Linux; xfs has had delayed allocation for years. Pretty much all modern file systems have delayed allocation, according to the Wikipedia Allocate-on-flush article, this includes HFS+, Reiser4, and ZFS; btrfs has this property as well. Delayed allocation is a major win for performance, both because it allows writes to be streamed more efficiently to disk, and because it can reduce file fragmentation so that later on they can be read more efficiently from disk. This sounds like a good thing, right? It is, except for badly written applications that don t use fsync() or fdatasync(). Application writers had gotten lazy, because ext3 by default has a commit interval of 5 seconds, and and uses a journalling mode called data=ordered. What does this mean? The journalling mode data=ordered means that before the commit takes place, any data blocks are
associated with inodes that are about to be committed in that transaction will be forced out to disk. This is primarily done for security reasons; if this is not done (which would be the case if the disk is mounted with the mount option data=writeback), then any newly allocated blocks might still contain previous data belonging to some other file or user, and after a crash, accessing that file might result in a user seeing unitialized data that had previously belonged to another user (say, their e-mail or their p0rn), which would be a Bad Thing from a security perspective. However, this had the side effect of essentially guaranteeing that anything that had been written was guaranteed to be on disk after 5 seconds. (This is somewhat modified if you are running on batteries
and have enabled laptop mode, but we ll ignore that for the purposes of this discussion.) Since ext3 became the dominant filesystem for Linux, application writers and users have started depending on this, and so they become shocked and angry when their system locks up and they lose data even though POSIX never really made any such guarantee. This become especially noticeable on Ubuntu, which uses many proprietary, binary-only drivers, which caused some Ubuntu systems to become highly unreliable, especially for Alpha releases of Ubuntu Jaunty, with the net result that some Ubuntu users have become used to their machines regularly crashing. (I use bleeding edge kernels, and I don t see the kind of unreliability that apparently at least some Ubuntu users are seeing, which came as quite a surprise to me.) So what are the solutions to this? One thing is that the applications could simply be rewritten to properly use fsync() and fdatasync(). This is what is required by POSIX, if you want to be sure that data has gotten written to stable storage. Some folks have resisted this suggestions, on two grounds; first, that it s too hard to fix all of the applications out there, and second, that fsync() is too slow. This perception that fsync() is too slow was most recently caused by a problem with Firefox 3.0. As Mike Shaver put it:

On some rather common Linux configurations, especially using the ext3 filesystem in the data=ordered mode, calling fsync doesn t just flush out the data for the file it s called on, but rather on all the buffered data for that filesystem.

Fundamentally, the problem is caused by data=ordered mode. This problem can be avoided by mounting the filesystem using data=writeback or by using a filesystem that supports delayed allocation such as ext4. This is because if you have a small sqllite database which you are fsync(), and in another process you are writing a large 2 megabyte file, the 2 megabyte file won t be be allocated right away, and so the fsync operation will not force the dirty blocks of that 2 megabyte file to disk; since the blocks haven t been allocated yet, there is no security issue to worry about with the previous contents of newly allocated blocks if the system were to crash at that point. Another solution is a set of patches to ext4 that has been queued for 2.6.30 merge window. These three patches (with git id s bf1b69c0, f32b730a, and 8411e347) will cause a file to have any delayed allocation blocks to be allocated immediately when a file is replaced. This gets done for files which were truncated using ftruncate() or opened via O_TRUNC when the file is closed, and when a file is renamed on top of an existing file. This solves the most annoying set of problems where an existing file gets rewritten, and thanks to the delayed allocation semantics, that existing file gets replaced with a zero-length file. However, it will not solve the problem for newly created files, of course, which would have delayed allocation semantics. Yet another solution would be to mount ext4 volumes with the nodelalloc mount option. This will cause a significant performance hit, but apparently some Ubuntu users are happy using proprietary Nvidia drivers, even if it means that when they are done playing World of Goo, quitting the game causes the system to hang and they must hard-reset the system. For those users, it may be that nodelalloc is the right solution for now personally, I would consider that kind of system instability to be completely unacceptable, but I guess gamers have very different priorities than I do. A final solution which might not be that hard to implement would be a new mount option, data=alloc-on-commit. This would work much like data=ordered, with the additional constraint that all blocks that had delayed allocation would be allocated and forced out to disk before a commit takes place. This would probably give slightly better performance compared to mounting with nodelalloc, but it shares many of the disadvantages of nodelalloc, including making fsync() to be potentially very slow because it would force all dirty blocks to be forced out to disk once again. What s the best path forward? For now, what I would recommend to Ubuntu gamers whose systems crash all the time and who want to use ext4, to use the nodelalloc mount option. I haven t quantified what the performance penalty will be for this mode of operation, but the performance will be better than ext3, and at least this way they won t have to worry about files getting lost as a result of delayed allocation. Long term, application writers who are worried about files getting lost on an unclena shutdown really should use fsync. Modern filesystems are all going to be using delayed allocation, because of its inherent performance benefits, and whether you think the future belongs to ZFS, or btrfs, or XFS, or ext4 all of these filesystems used delayed allocation. What do you think? Do you think all of these filesystems have gotten things wrong, and delayed allocation is evil? Should I try to implement a data=alloc-on-commit mount option for ext4? Should we try to fix applications to properly use fsync() and fdatasync()? Related posts (automatically generated):

1. Don t fear the fsync! After reading the comments on my earlier post, Delayed allocation...
2. SSD s, Journaling, and noatime/relatime On occasion, you will see the advice that the ext3...
3. Ext4 is now the primary filesystem on my laptop Over the weekend, I converted my laptop to use the...

If you code for long enough on x86-64, you'll eventually hit an error such as: Here's a little example that might help you figure out what you've done wrong. Consider the following code: In case it's not clear, that would look something like: Let's build that code, and see what it looks like We can see that the mov instruction has only allocated 4 bytes (00 00 00 00) for the linker to put in the address of foovar. If we check the relocations: The R_X86_64_32S relocation is indeed only a 32-bit relocation. Now we can tickle this error. Consider the following linker script, which puts the foo section about 5 gigabytes away from the code. This now means that we can not fit the address of foovar inside the space allocated by the relocation. When we try it: What this means is that the full 64-bit address of foovar, which now lives somewhere above 5 gigabytes, can't be represented within the 32-bit space allocated for it. For code optimisation purposes, the default immediate size to the mov instructions is a 32-bit value. This makes sense because, for the most part, programs can happily live within a 32-bit address space, and people don't do things like keep their data so far away from their code it requires more than a 32-bit address to represent it. Defaulting to using 32-bit immediates therefore cuts the code size considerably, because you don't have to make room for a possible 64-bit immediate for every mov. So, if you want to really move a full 64-bit immediate into a register, you want the movabs instruction. Try it out with the code above - with movabs you should get a R_X86_64_64 relocation and 64-bits worth of room to patch up the address, too. If you're seeing this and you're not hand-coding, you probably want to check out the -mmodel argument to gcc.

I've just uploaded Policy 3.8.1.0 with the first batch of post-lenny changes. There isn't anything that earth-shattering in this set, but I'm hoping that we'll be able to get a lot more done during the squeeze release cycle. Policy has well over a hundred open bugs, quite a few of which we should be able to resolve. I also uploaded Lintian 2.2.8, which is synchronized against Policy 3.8.1 and also reverts some changes around install-menu due to a reverted change in debhelper 7.2.5, and fixes diagnosis of diversions. The last few versions of Lintian have all been a little bit buggy due mostly to the current pace of change. Hopefully this version will have fewer unexpected problems. Here is the summary of normative Policy changes, taken from upgrading-checklist.txt.gz in the debian-policy package.

• Care should be taken when adding functionality to essential and such additions create an obligation to support that functionality in essential forever unless significant work is done.
• Changelog files must be encoded in UTF-8.
• Tighten some format requirements for changelog files from a should to a must.
• Remove alternative changelog formats. Debian only supports one changelog format for the Debian Archive.
• New nocheck option for DEB_BUILD_OPTIONS indicating any build-time test suite provided by the package should not be run.
• All control files must be encoded in UTF-8.
• debian/control allows comment lines starting with # with no preceding whitespace.
• Init scripts ending in .sh are not handled specially. They are not sourced and are not guaranteed to be run by /bin/sh regardless of the #! line. This brings Policy in line with the long-standing behavior of the init system in Debian.
• The start action of an init script must exit successfully and not start the daemon again if it's already running.
• /var/run and /var/lock may be mounted as temporary filesystems, and init scripts must therefore create any necessary subdirectories dynamically.
• /bin/sh scripts may assume that local can take multiple variable arguments and supports assignment.
• User mailboxes may be mode 600 and owned by the user rather than mode 660, owned by user, and group mail.

Things are feeling unstable around here. That's mostly a good thing, but ... Switching to ext4 seemed like a good idea since I was resizing my file server's filesystem anyway. And I'd used ext4 on my laptop for a while, with no problems. But, I ran into a bug that causes ext4 to hang. So I'm left with my main server at home piling up hundreds of processes in uninterruptible sleep when this breaks. And, eventually running out of memory and dying. There's a fix, in newer -pre kernels, but so far I have not had luck getting those kernels to work with my Thecus. There's a regression in those kernels that breaks the NIC, and my attempt at backing that changeset out still left it unable to get on the net. Did I mention that I don't even have a serial console on this machine? That natively building a kernel on armel takes about 12 hours? Makes this sort of thing much fun. Need to find the right header and spend some time with a soldering iron one day. Converting back to ext3 would mean resizing a 2 TB array, which ran resize2fs out of memory when I tried it. It looks like I will have to leave /home unmounted while I'm on my trip, to keep the rest of the server up. When I get back, I've ordered a third terabyte drive, and will use it to switch back to ext3. Having these silly amounts of storage is fun, until you have to admin it. The other fun I've run into is that a new version of mpd has horrible performance on arm. Max Kellermann was very helpful in tracking down the issues involved, and helping me get a version that has at least reasonable performance again. Oh, and if someone could tell me why gnome terminal 2.24.3 can't open links anymore, I'd appreaciate it.

With Debconf9 being on the european mainland this year, a plane flight isn't necessary. Since flying in cattle class isn't my idea of 'fun', I had been planning to take the train to Caceres this year. So, with the public announcement of debconf registration being open, I thought I'd look at train options. Short version: I think I'll be going to the train station and ask them there, rather than looking something up on the NMBS website. Long version:

Trajectory	Date	Departure	Arrival	Train
Mechelen -> Brussels North	2009-07-13	07:02	07:18	IR 3128
Brussels North ->K ln Hbf	2009-07-13	07:27	09:15	ICE 11
K ln Hbf ->Mannheim Hbf	2009-07-13	09:54	11:24	ICE 515
Mannheim Hbf ->Basel SBB	2009-07-13	11:36	13:47	ICE 375
Basel SBB ->Arth-Goldau	2009-07-13	14:03	15:45	IR 2177
Arth-Goldau -> Milano Centrale	2009-07-13	15:50	18:50	CIS 21
Milano Centrale ->Barcelone Estacion de Franca	2009-07-13/14	19:40	09:43	EN 11274
Barcelona Estacion de Franca -> Barcelona Sants	2009-07-14	09:43	10:28	Transfer
Barcelona Sants -> Madrid-Puerta de Atocha	2009-07-14	12:00	15:23	AVE 3122
Madrid-Puerta de Atocha	2009-07-14	16:40	20:02	TLG 194

And that's after asking to arrive 'around' noon on the 15th. Although I'd love to combine ICE ('Intercity Express', German high-speed trains), CIS ('Cisalpino', Italian high-speed trains), EN ('EuroNight', pretty much what the name says), and AVE ('Alta Velocidad Espa a', Spanish high-speed trains) in a single trip, I think I'll pass for this particular suggestion. And that's ignoring the fact that 5 minutes for a transfer in Arth-Goldau (a place I've never heard of before, let alone been in that train station) is rather tight, and that I don't know whether I'll be able to make it in 45 minutes from one train station to another in Barcelona without actually knowing the city. More soon.

Samba.grep.be, my main server (which occasionally also hosts a domU for p2) was upgraded to lenny this monday evening. I wish I could say there were no issues, but unfortunately that's not true. At first, everything seemed to run smoothly; of course I did have to recompile a few locally written programs to run against some SONAME changes (programs that are too trivial to package, really, and too ugly too), but other than that, everything was fine. It went wrong sometime during the night. Apparently something didn't like the new kernel or the new xen, because everything started to lock up. Since I only noticed this when I was at a customer the next day, I couldn't fix it until I got home again in the evening (meaning, downtime for a full day); and unfortunately, the exact failure mode meant that not much was written to the log -- certainly not enough to figure out what went wrong:

Mar 10 04:04:41 samba kernel: [ 7033.011523] INFO: task cron:21006 blocked for more than 120 seconds.
Mar 10 06:43:46 samba kernel: [ 7033.011614] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Mar 10 17:35:04 samba kernel: [ 7033.011701] cron          D 7fffffffffffffff     0 21006   4147

After that, nothing before the reboot, which happened at around 21:00. Take good note of the timings on those messages, and the apparent discrepancies between the syslog timestamp and the kernel timestamp. 7033 seconds after boot was around 3:30 AM... When I arrived at the physical server, this kind of message was rolling over the console several times a second, with just the name and PID of the blocking process changed. And with several more lines following the message, of course. As a result, the system was not responsive at all. I didn't file a bug since, frankly, there's so little information that I wouldn't even know what to file a bug against (the kernel? Xen? Some rogue process that runs as root and changes settings which cause a driver to block? I wouldn't know). Instead, all I could do was to reboot the server and hope for the best. Not that I like that kind of situation. Fortunately, the problem didn't reproduce itself today; here's for hoping that it never will.

Many people answered to my previous rant stating that it is upstream's prerogative to refuse integration of external patches. I agree and I never said they must integrate patches if they open their source.

What I find unacceptable, and the only reason for the rant, is the fact that upstream deleted my posts from the forum when it was clear that none of the fake reasons that were given was the real reason, since I answered to all of them with sane, logic and reasonable arguments.


I find acceptable to refuse external patches, although undesirable.

Still, I find it unacceptable to try to erase all tracks of a conversation from which it is clear that you were wrong, and try to keep face by erasing traces.

I would have found it hard to deal with, but still acceptable, if upstream would have said simply "please don't try to make patches for glest with the purpose of integrating them later on, we don't want any patches from outsiders". That would have been a decent thing to do.

Last week I was confronted head on with an uber cheerful person and he was clearly not undergoing this fine new treatment.

Last week I was confronted head on with an uber cheerful person and he was clearly not undergoing this fine new treatment.

I wasn t sure to really understand this project of law until I read a lot about it during the past days. As some of you might already know, this law, called Internet et Cr ation , but mainly referred as HADOPI law ¹, is a Three Strikes scheme to fight against illegal downloads proposed before the last summer by the French government, and then voted in the Autumn by the S nat (the first of the two French houses of Parliament). Not that I am in favor of illegal downloads of movies and music, but the way this law plans to fight against them is a real threat for French free software developers and users. I won t explain here all the details of this law, but to sum up, it plans to suspend the Internet access to people downloading illegal files from the peer-to-peer network, after 2 notices. Here are the problems I have noticed, as far as I am personally concerned, besides more general aspects this law implies (user freedom etc.):

• Some private actors, indirectly working for French leisure and cultural companies, will be in charge of controlling the French Internet. They will only base their accusations on the IP addresses, which I do not think to be a proof alone.
• An Internet user, accused to have illegally downloaded movies or music will have to prove by his own means he has not done it - ie. his Internet connection could have been hacked, but he needs to prove it! This is totally contrary to the way justice normally works in France, where you are supposed to be innocent until the contrary is proved. A large majority of French Internet users do not have the necessary technical skills to secure their wireless network and hence their Internet connection. And even with good skills, all of them do not own a wireless router supporting eg. WPA2, which creates a real discrimination towards French Internet users.
• A chapter of the project of law plans the possibility to set up a kind of firewall on the computers connected to the Internet - they will allow Internet users to prove their sincerity. This causes however a big issue for free software users: I doubt such a piece of software will be available for free operating systems (such as GNU/Linux, FreeBSD etc.). Even if it is, it won t be opensource - if it was, anybody could amend it and/or disable it, hence no real possibility for the user to prove it was running when the illegal download was noticed.
• This law doesn t take into account the fact that an increasing part of the peer-to-peer exchanges are encrypted, or run anonymously. More over, other technical ways of downloading are not considered (streaming, direct downloads especially when the websites are hosted abroad).

The law should be discussed at the Assembl e Nationale from today (the second house of Parliament), I hence contacted my local representative last week in order to propose a meeting allowing me to expose my concerns. Until now, I have received no answer, despite the fact he accepted to commit in favor of free software when running for being re-elected in june 2007 (he signed the Pacte des logiciels libres from the APRIL association). I guess I will receive an answer once the law is voted!

If you are managing a Free Software project, you may eventually be confronted with a security vulnerability. Normally bugs in the Open Source world are discussed in a transparent way on public forums. In the case of security bugs however, there are benefits to temporarily withholding these details from the public.

Some people describe this approach as responsible disclosure. It boils down to this:

if the vulnerability is not publicly known, warn the vendors first and give them some time to fix it before making the details public.

If the vulnerability is already public knowledge, then you can focus on fixing it as soon as possible and maybe let reporters know about a better way to report their findings.
Sample Security PolicyHere's the procedure we now follow in the Mahara project for security bugs we found ourselves or which have been privately disclosed to us through security@mahara.org:

1. Figure out the extent of the problem: which versions of Mahara are affected by this problem?
2. Fix the problem on all supported branches of the project in a private source control repository.
3. Share the vulnerability information with vendor-sec and request a CVE identifier.
   
4. Prepare release tarballs and packages.
5. Draft a security advisory for the Security forum.
6. Wait until the embargo date to push the release out.
   

Emails to vendor-sec should include:

• a description of the problem
• any proof of concept code demonstrating the vulnerability
  
• the list of affected versions
• any patches you have prepared
• a proposed embargo date

Benefits of properly handling security bugs
First and foremost, it protects end-users by giving them a chance to download and install fixed versions of your software before widespread exploitation of the security flaws.

Secondly, it may increase your project credibility. While you are admitting that your software has flaws, you are also demonstrating that your project is committed to dealing with the most serious ones promptly and in a responsible manner.

Finally, sharing security flaws and having your fixes reviewed by a select group of experts may reveal extra vulnerabilities you missed while preparing your patches. This gives you an opportunity to improve your fixes before they are released and to avoid having to issue yet another security advisory a few days later.

Big thanks to Steffen Joeris for his help in shaping the Mahara policy!

Fred von Lohmman gave a lively talk tonight about public interest law (and I hope he inspired at least some NYUlawites to follow in that path) with a focus on Youtube s content ID system now being used by Warner Music to automatically delete/censor videos, such as this one from Youtube. Go Google. Go Youtube. Go Warner Music.

Fred von Lohmman gave a lively talk tonight about public interest law (and I hope he inspired at least some NYUlawites to follow in that path) with a focus on Youtube s content ID system now being used by Warner Music to automatically delete/censor videos, such as this one from Youtube. Go Google. Go Youtube. Go Warner Music.

I finally took some days off. Those are most needed, since I spent carnival on call at the hospital (argh!)... So Brenda and I decided to spend those days at Maceio, capital of Alagoas state, and a very anticipated vacation. They have a lot of sun and beautiful beaches, enough to fill our week (and get some tan also). This picture was taken at Praia do Gunga (Gunga s Beach), a charming place with a calm shore, almost like a pool, protected by natural reefs. As you can see, I am having a bad time right now :-) Food is excellent, so are the people. But there are some inconveniences (as always). Beaches around downtown are not proper for bathing They re fighting a long fight against pollution (and loosing, if you ask me)... Also, Alagoas is a poor state Our guide said alphabetization covers less than 70% of the people Also, network connection is expensive in hotels. Ours charges BRL 1,00 every 5 minutes! And the speed is not the best. They have one of those systems requiring a web authentication before you go. I ve seem people complaining about this kind of system in Planet Debian before (reference please!) and suggesting Tunneling over DNS as a fix . I ve noticed it would work in our hotel, but I decided to try another approach I ve already written about: just a quick tunnel over an ssh connection. I know I told you I needed an authentication before, but that is for the first connection! Yes, once the connection is established, I could just log out (thus stop the charging). No new connections could be made, but the tunnel was already up, so just put everything through the tunnel and I should be fine right? Wrong. I got bitten by a drawback of the technique already pointed in a comment when I first wrote about it: in an error-prone network, TCP-in-TCP slowly dies of attempting to correct itself over and over and I was using a poorly connected wi-fi (loosing almost 30% of the packets!). So, I was left with the set-up of a not foreseen tunnel using DNS as the only option This would take time (and money)... So I decided for a simpler approach: SOCKS proxy. Yes, everything I would do could be done through a SOCKS! So a simple:

bash$ ssh -D 8888 my.remote.location

was all that I needed. That and setting my Firefox to use a SOCKS proxy on localhost:8888 and all went fine. I paid to set-up the tunnel then, once established, I logged out and kept using my tunnel all this time. Simple and effective, and I got some time left to blog about it. :-)

I am working on a system where a front-end mail server sends mail to what it considers to be a LDA (Local Delivery Agent) which actually sends mail to a back-end server via LMTP. I can t remove that fake LDA from the design because it does a bunch of business specific processing along the way. I am working on changing the back-end from Cyrus to Dovecot. Currently the mail goes from the fake LDA to the Cyrus LMTP server. What I would like to do is to have an LMTP server run on the back-end machine that launches the Dovecot deliver program immediately and then returns an appropriate code. So far I have been experimenting with having Postfix run on the back-end to use deliver as the real LDA. The first problem with this is that the mail will be written to the Postfix queue and then written to the mail store. Doubling the number of writes is a real problem for a system that is going to be write-bottlenecked - it would significantly increase the hardware costs. The second problem is that when an account goes over quota the back-end server would be generating a bounce message. I would prefer the front-end server to generate the bounce on an un-munged message. Basically all I need is a simple daemon (which could even be launched from inetd) that talks LMTP (a very simple cut-down version of SMTP) and executes a single command to receive the data. It might be necessary to serialise running the delivery process, in which case the mail data would have to be stored in memory and there would need to be a semaphore around executing the delivery program. Does anyone know of such a program? If not then I ll have to write it myself (which shouldn t be difficult) and GPL it. If I have to do that then I need a suitable name for it. Any suggestions would be appreciated.

Yesterday, the choir of which I've been a member for these past few years went to the provincial tournament for the first time in its existence. For those of you unaware with what this is: the "provincial tournament" isn't a tournament in the traditional sense (which would have a winner etc); instead, you get to sing in front of an expert jury which will classify you in one of six categories; the category you're in then determines government subsidy your group gets. This is done for all nonprofessional music groups, and makes for a pretty fair way of deciding who gets what, IMO. Apart from that, it's of course also fun. Anyway, as said this was the first time our choir went to such a "tournament", but of course we weren't alone; apart from us, there were six other choirs, two of which were also part of the Ekerse C-koren: Cantando (the semi-professional choir of our group) and Cantilene (for those between the ages of 18 and 25 (or 16 and 25 for boys). And we did well. Cantilene (who did very well in the most recent edition of the 'Koor van het Jaar' contest) was categorized in the 'superieure afdeling' ('superior category'), with 75% in that category. Cantando did even better than that; they achieved a score of 93%, also in the superieure afdeling. This is the highest category in the whole system, so it deserves some special praise. Caljent , our choir, didn't quite reach that level yet; considering the fact that we've only existed about three years, however, that isn't very surprising. Yet, we did quite well; we were categorized in the 'Uitmuntendheid' category, with a score of 75% in that category. Uitmuntendheid (which would translate to something like 'greatness') is the third possible category, which puts us in the top half of the choirs of the province of Antwerp. Quite an achievement for what is, after all, a fairly new choir. Of course we're all very happy with that especially so our conductor, who was rather surprised when she heard the outcome... For those interested, one of the choir members had a camera with him, and he put the four pieces we sang up on youtube: Credo, Dostoyno Yest, Wals van kwart voor middernacht, and Hodie Christus Natus Est. There're also films of the other choirse, but you'll have to look for those yourself ;-P

So, I just checked in for attending Bossa Conference. If you want to talk about Debian, WebKit, WebKitGTK+, Gksu-PolicyKit, I ll be quite interested =).