Raw Matter

Or should I say dear Lucas? Although this is more relevant for the people wanting to talk to Lucas on IRC. I recommend to use the leading edge technology set forth in rfc 2821 and 2822 for this mode of communication. I admit this is extremely experimental technology, but it might be worth looking at nonetheless.

With Hans Reiser convicted for murder, some seem to feel that reiserfs is more or less dead. Jason Perlow writes a very strange article on ZDNet to which I'm replying to it mainly because he alludes that Debian so far has failed to react.

First, default installations of Debian create ext3 and not reiserfs filesystems (Please correct me if I'm wrong. I've just recently installed a fresh etch, but I didn't specifically look at the fs.) And even if it were reiserfs (v3), I don't see why a reaction would be called for now. The stability of reiserfs has come up every once, before the whole murderer story begun, and that the interaction between the reiserfs developers (including, of course, Hans Reiser) and the kernel team were always difficult has also been known for a long time. This is the kind of reason where I think it's appropriate for Debian to take steps (i.e. switching to a different filesystem), not a single event, where it is not even clear yet how the reiserfs (v3 and v4) efforts will move on.

On to the technical stuff: Perlow tries, but doesn't really arrive at understanding the issues he's writing about. Reiser 4 is discounted without a single remark on its technical merits (I can't comment either as I have not looked at it so far.) Why he discounts ext4 is not clear to me (because it is not ripe for production use yet — but that's even more true of ZFS and this Linux-NTFS thingy he rambles about further down...) He discounts JFS2 because it hasn't got a new release for several years (is that bad in a filesystem?) but then touts ZFS as a great idea with minor licensing problems, without speaking of patents which is where the real problems lie (not to mention the fact that the Linux ZFS port probably is much less tested than ext4 or JFS.) And in a final jump into fantasy-land he mentions that NTFS might just be ideal for Linux, and Microsoft is said to have started cooperating nicely with the Free Software world, so all licensing and patent issues are certainly going away Real Soon Now™. At least for Novell, these issues shouldn't be a problem, I guess.

Not mentioned by Jason are btrfs (which has a quite tightly coupled network filesystem brother, crfs and is in a very early state of development), and hammer, which comes from the BSD world and currently lacks a Linux port. Both efforts are probably more likely to replace ext3 or reiser on Linux than both ZFS and NTFS: no patent issues, no license issues, and the development is actually done by a community and not a single company.

Update: Julien Blanche ha a much more succinct response to Jason Perlow. More intersting to read than mine, too.

I picked up Coffee and Cigarettes when I was buying some other movies because I though I'd read about it somewhere. I'm not so sure now. I probably didn't imbibe enough coffeine before watching it, or it's just because I am not a cousin to Mr. Jarmusch, but I suppose the fact that I've watched it to the end can be attributed to the fact that it's just 90min, or perhaps to some morbid curiosity if there's gonna be something more...

That said, I liked the style of the whole thing, with the grainy black and white and the calm camera.

Readin Sam's announcement, I thought “finally!”. I am now, however, deeply disturbed by Joerg's reaction to his delegation. This way, I have a very strange impression on what's happening. Didn't Joerg know that Sam was going to delegate him? Of course, this is not legally relevant, but I do not feel that this is how it should happen. (Mark the difference: this is not about somebody being forced into a team that doesn't necessarily welcome the new member, but about the proposed new member being forced into a decision in this way.)

On balance: please do it. The situation reminds me of the Debian kernel team when it changed from Herbert Xu to group maintainership, which now works quite nicely afaict. But obviously, there is no guarantee that things will work out nicely, and there might be serious friction as well. OTOH the new DPL publicly stating that he supports this decision should be a Good Thing™

These countries together are responsible for almost 90% of the documented deaths by capital punishment (source: Amnesty International.) Note that the self-proclaimed leader in freedom and democracy is in there, together with some of its allies as well as the country entrusted to hold the worlds biggest sports event.

No, the king id not dead. Still, congrats to Steve. And yes, I was wrong in that I expected more people to vote 111- or equivalent (perhaps those people didn't vote at all instead?) About voter turnout: In Switzerland, everybody is really, really happy when 49% of the population does vote. Usually, we have participation between 30 and 40%, sometimes even lower, IIRC in one case it was as low as 26% all issues were so non-controversial (usually, it's referendums (referenda? referendi? referendumthingies) on factual issues and no elections, though, so the comparison might not be entirely fair.)

After my moderately successful attempts at learning git, I have now tackled Mercurial and found it easy to understand and use. I can't quite see where git is better, so I guess I'll stick with hg now.

Output so far is a script I call hgdebuild, which I'll probably package when it's a bit less rough around the edges (yes, I know about hg-buildpackage, but I didn't really like it, and it appears to be orphaned at the moment anyway).

Also, with Mercurial, I very easily could address the main problem I've always had with distributed revision control systems: With Subversion, it's easy to work on different computers, and backing up my home directory has become less critical (an important aspect on my Laptop). Both of these are not true when suddenly .hg in my working dir is the backing store.

$ cat ~/.hgrc
[hooks]
commit.push = [ -f .hg/dopush ] \
    && ping -w 1 -c 2 -q -i .2 mygitserver.example.com >/dev/null 2>/dev/null \
    && hg push \
    || true

(Probably this problem has been solved before. Comments welcome.)

Comments: From the person with madduck in his email address: Bzr checkouts, or a similar Git hook.

Children should be trained at an early age that the only real OS comes from Redmond. Stupid gadgets reinventing the wheel and then using Windows-only drivers for their non-standard interfaces.

Debian's “alternatives” system (/etc/alternatives) system doesn't really like having alternatives set to manual and then the corresponding packages being removed. Time to get rid of all those broken symlinks...

find -L * -type l  | while read i; do update-alternatives --auto "$i"; done

Fundamental fact: non-technical people can't or won't read mail bounces. They (the bounces) are far too technical. Most people, even if they could understand them intellectually, most won't even try to read them. Their input channel gets jammed, their parser shuts down, whatever you want to call it. Obviously, this is extremely frustrating, especially because I take care that my spam filter never drops mail but always rejects it so that the sending mail server can generate a proper bounce.

Proposed solution (and don't tell me this can easily be scripted in mutt. The people I'm talking about wouldn't even recognize mutt as an email program if they'd ever see one): Index all outgoing Message-Id's. When a bounce comes in for a known message, don't display it but display some kind of locally generated, friendly substitute with a direct 'correct address and re-send' button and a clickable link to the original message.

The thing to do: require Microsoft and its cronies to write a strict OOXML document parser/verifier and release it under the BSD license as a starting point for other companies' work with OOXML documents. And require them to offer free support to all companies wishing to publish OOXML compliant documents (without any vendor specific extensions) on how to do that with their M$ Office products.