I am currently working on implementing a cryptographic file system using FUSE. It is different from EncFS and similar in that it just mirrors a normal directory tree, but encrypts the contents of the files as they are read or decrypted as they are written. My use case is backups. I have some machines where I and only I have access, machines which may contain proprietary information, personal emails and so on. Of course, I want backups of those, so when the hard drives stop working, I don't lose any data. The machine(s) I am backing up to, however are not always machines where I trust all the people with physical access to not make a copy of my data. In addition, I don't want broken hard drives returned under warranty to contain unencrypted data. This use case is the reason for why I'm encrypting on read rather than on write. I have chosen to use CTR (counter) mode together with AES which should give acceptable security. One of the requirements CTR needs to work well is a nonce, typically 64 bits (for 128 bit AES) which must not ever be used twice. If you use it twice, you leak information about your plaintext, which is, for obvious reasons, bad. My current design headache is how to choose a good nonce. Ideally, I believe it should be persistent for each version of the file and unique per file. Using the inode number takes up 64 bits (on AMD64 at any take, or when using -D_FILE_OFFSET_BITS=64 on 32 bit platforms). So while this gives me the latter, it doesn't give me the former at all. I am wondering if I should use the inode number modulo 2^32 (effectively choosing the lower 32 bits of the inode number) and then something which is fairly sure to never be the same, such as mtime (or at least the lower 32 bits of it, when time_t becomes 64 bit). The reason for not just choosing a completely random value is I don't want a command like diff file1 file1 to claim there are differences in the file. My hope was I'd get a great idea on how to solve the problem as part of writing it down. Alas, that hasn't happened, so if you happen to come across a great solution (or a reason to avoid a particular choice), feel free to email me

Last weekend was as hectic as my life has been lately: I have been trying to restore sanity into my NSLU2, I went to a lecture from Andrew S. Tanenbaum and I made a 2.5 hours drive to my parents in about 4 hours because of the fog.

First, my slug:

• refuses to recognise the USB NIC I have been using until the latest incidents (it either says 'not accepting address, error -71' or 'device descriptor read/64, error -71')
• sometimes reboots when I insert the USB NIC
• either doesn't boot at all or boots really slowly when the USB NIC is inserted
• (obviously) doesn't show the NIC in lsusb listing when is not recognised

Since the USB NIC works on my laptop, I suspect a hardware problem with the slug. Bummer!

Dear no-so-lazyweb, is there a way to install Debian on an ASUS WL-500G Premium router without loosing wireless ability? Or, is there a way to make use of my USB NIC with the ASUS router?

---

Second, Andrew S. Tanenbaum visited Romania and lectured Friday at the University Politehnica Bucharest.

He presented Minix3's architecture and the advantages it has over monolithic OSes. I attended the lecture (although I am not a student anymore) and found it quite nice and well prepared, but I had the feeling that sometimes he was trying to avoid or to bash topics that were not putting Minix into a good light or challenged its title of being the first open[0] OS based on a micro-kernel architecture[1]. In spite of that, I found him to be a really good speaker and I liked the overall presentation, although, I also expected some on the spot demos or at least some recordings.

The things that I remember:

• 2.4 millions subtle code alterations in drivers with only 80000 driver crashes (of course, no kernel crashes)
• simulation of network driver repeated crashes at different time intervals and how it affects performance - a 30% degradation at crashes that occur once every second and an insignificant degradation at crashes occurring at each 10 seconds
• every driver has a set of rights assigned to it; it was difficult for them to define this - this sounds a lot like SELinux issues
  
• messages have a fixed length
• there is no dynamic memory allocation within the kernel
• the kernel is 5000 lines of code (all drivers are in user space)
• really secure system
• there were performance comparisons with Minix2 and the hit was about 20%; still, is said that L4 has only an approximate 2-5% performance hit because of the micro-kernel architecture
  
• apparently the FreeBSD kernel has only 3 bugs /1000 lines of code
• Minix uses a BSD license
  

I also got a Minix live CD (which is more like the Gentoo Linux install CD - just console in the live system) and made an installation of Minix in a qemu machine[2]. Unfortunately, I don't think I'll have the time to dwell into the source.

I was thinking, would it worth the effort to try to make a GNU/Hurd/Minix system (i.e. replace Mach with Minix's micro-kernel)? BTW, is Debian GNU/Hurd now based on L4 or does it still uses Mach?


Note: Some of my work colleagues suggested that the presentation was the same as one he made at linux.conf.au last year, but I can't confirm/infirm that since I didn't saw the recording.

---

I won't write about the "fog drive", but I'll just say it wasn't pleasant at all, and I felt I was in driving in The Twilight Zone for the whole Friday evening.

---

[0] he gave credit to QNX
[1] For instance, I tried to ask him twice if he felt that GNU Hurd was violating the micro-kernel paradigm or if he can compare it to Minix' architecture. I had the impression that both times he avoided to answer and started the usual Hurd bashing, "they have been developing it for 20+ years, but got nothing working", meanwhile "Minix is here". After the lecture/presentation somebody told me that AST shortly said that they "were similar, but different". I didn't catch that line.
[2] thanks to qemu-launcher it is trivial to create and manage multiple qemu virtual machines

While stuff is upgrading I can update on a previous entry. In Delft Hieke and I had an excellent dinner in restaurant l'Escalier, who specially prepared a vegetarian menu for us. The establishment was fully booked yet not very noisy, with very personal and friendly service with a good wine selection. The next day was the big day of Rudy's defense. We (Rudy, David and I) started at 8 in the morning to put on our costumes, after which we went to prepare the defense. From my point of view it all went quite smoothly. David and me could even be of useful assistance by reading out some of the propositions during the ceremony. It turned out that Rudy's research into Multi-Agent Model Predictive Control was convincing enough for the committee to hand him his PhD degree (see below). After which there was the appropriate celebration in the form of a good dinner and some welcome beverages after a very long day.

[ Apologies for Debian planet readers expecting something pithy and Debian related. This isn't. But then pkg-xfce packaging just continues. We get more bugs, we fix some of them (if you have a dual-headed setup and want to help us fix or reproduce more we'd love to hear from you). Corsac became a DD at last and has made me more or less redundant in a good way. I should probably investigate libburnia again and prod George Danchev about #450873 since basically it seems to just need the ubuntu packaging brought across into Debian to replace libburn etc. But anyway, on with the irrelevant stuff... ] Books part 1 was back in April and I've since found myself with some time on my hands before I get a new job so here we go again.

Making Money - Terry Pratchett

This was a Christmas present and I quite enjoyed it and enjoyed the character but didn't really think it lived up to the laugh a minute Pratchett books that I remembered from the good old days.

The Lovely Bones - Alice Seebold

This is quite a weird concept for a book given that it's from the point of view of a dead girl in heaven but it seems to work. It's very well done and I enjoyed it.

Alex Rider series - Anthony Horowitz

I had seen Stormbreaker and wanted to read some more of these as light holiday reading. They work well for that. There's enough plot to keep me interested but not enough to make them at all hard to read. I read a couple of them in French when I was in France (in between traipsing between different bits of Paris since the m tro workers were on strike). I wish they'd been around when I was younger.

My Sister's Keeper - Jodi Picoult

Ooh this is a really, really good book. I loved it except perhaps for the very end but I can forgive it that. The idea is that she's suing her parents for the rights to her own body because she was conceived as a donor for her sister to fight off her sister's leukaemia. It's a very thought provoking read with several interesting characters with their own stories woven together.

The Language Instinct - Steven Pinker

This book is fascinating to me. It takes ideas mainly from linguistics, evolution and psychology and explains a theory that seems to hold together and is well illustrated and explained. The central point is that we all are born with the ability to develop a universal grammar from an early age which can be adapted to any human language and which sticks around in the young child and then disappears. If you have any interest in language at all read this book.

A Spot of Bother - Mark Haddon

I found this a bit hard to get into as essentially it's about the normal lives of a family (albeit quite a special family). It doesn't really grab you. Towards the end though I was interested to find out how it would all unravel and was pleased with it.

The Mephisto Club - Tess Gerritsen

This is a nice, honest thriller that does what you expect. It keeps you flicking the pages wanting to know what happens next.

The God Delusion - Richard Dawkins

I quite enjoyed this and did find new arguments against religion but I don't think he's going to convert anyone with this book. Of course I'd recommend anyone read it because it raises lots of interesting points but it's polemic essentially.

The Blind Watchmaker - Richard Dawkins

I enjoyed this though it builds on previous work I'd read. I guess if you're just interested in evolution then read this and not the God Delusion.

The Raw Shark Texts - Steven Hall

I was recommended this by a friend. It's very surreal possibly a bit too surreal for me but I enjoyed it nonetheless.

Do Androids Dream of Electric Sheep? - Philip K Dick

I hadn't read the book and saw it at a friend's and borrowed it. You probably all know what it's like. I'm glad I read it because of the references to it but it's not my normal reading material.

Harry Potter and the Deathly Hallows - J K Rowling

I had to read this of course to finish off the series but I thought it was a lot better than some of the others. I think I enjoyed the first, the one with the tri-wizarding championship and this one the most.

Love in Idleness - Charlotte Mendelson

This is well written and you really get into the character that's painted for you. I really liked some of the descriptions of justifying things to yourself and coping with boredom.

Blood, Sweat & Tea - Tom Reynolds

This was an interesting look at the life of a paramedic and if you don't already read Random acts of reality then read the book first and start reading the blog.

Telling Lies - Paul Ekman

This came from my Blink/Tipping Point reading and I found it hard going. It was interesting but quite detailed and not really a book for late night reading. The theories in it are very interesting though and explain why you probably aren't as good at detecting things as you think you might be and how to look for factors that will help you.

The Man Who Mistook His Wife for a Hat - Oliver Sacks

I read this ages ago and it was fascinating. It's about a number of different cases of problems with the brain. Often physical defects in various areas of the brain that cause odd problems and how it sheds light on how things relate. I really enjoyed it.

As always, do please punt your own recommendations at me.

A few years back I asked Branden Robinson for access to the X Strike Force SVN repository in order to improve the X server's autodetection, with the goal of stealing what I could from knoppix. At the time, users were constantly wandering in to #debian saying that they had used knoppix to create an XF86Config-4 and then they used that file on their Debian installations. They were also constantly whining about how Debian wasn't doing as good a job. So I decided to do something about it, and took a look at what knoppix was actually doing so much better than us, and I was surprised to find that they pretty much just wrote a skeleton configuration file and let the X server fill in the details. I had no idea the server was capable of such things. So Branden graciously gave me SVN access and I began comparing the knoppix method to the script called by "dpkg-reconfigure xserver-xfree86" and realized that we probably couldn't adopt the same method because we had tons of checks for portability. So I put the problem on the backburner for few weeks and worked on something else for a while.

Well, somewhere in between then and now I got sucked in to transitioning Debian to X.org (using the aforementioned SVN access) and then working on all the things that went along with maintaining X in Debian, some well and others less so. Between transitioning to Xorg, and then transitioning to a modular Xorg, even with the ability to steal Ubuntu's packages it still took about two full years with me being a rookie and all that. There were tons of people who worked on this with me, but it was just a damn big job. Eventually though, etch released with modular X packages, and we were running at a pretty good pace with upstream, so it was time to revisit the problem of configuration again after the two year detour.

The problem of configuration had been reframed for me by having looked at what knoppix was doing and discussions with upstream. Upstream was starting to come to the conclusion that we shouldn't have a config file at all, and that the server should be smart enough to do everything by itself. It was already partially there, it just needed a push in the right direction. This was a major shift in how I thought of it. Coming from a Debian background, where the answer is to always just regenerate or edit your config file, having the server work things out for you was a totally alien idea. But I have my deepest roots in the Macintosh world, so immediately fell in love with it. The problem was that the server had a whole body of code to use if you had no config file at all, and another, with far less automagic goodness, if you had a config file, even if it was a 0 byte file. The goal became to have the server work really well with a minimal config file, so you could override what you don't like in the defaults and let the server figure things out for itself at boot. The way forward was to translate as much of the logic in our configure script in to the X server itself as possible.

Ubuntu had put in a lot of work in to the configuration setup that we automatically benefitted from, so given that most users were happy with things as they were, I was able to carve away at the problem without disrupting anything. And there was a lot to carve out, as the script that runs the config is an absolute mess that was slated by Branden for a rewrite all those years ago. Early on I picked off the low hanging fruits like the font path and modules. Similarly, Redhat's Adam Jackson had also been working on this problem, and he killed off the ServerLayout section as well as putting in lots of critical fixes all over the place elsewhere. More recently, I've gone and cut explicit modesetting out of the configure script. Hardcoding this information is generally a bad idea in the randr 1.2 world, and most of the drivers will do as good or better job of figuring out the modes than our config script would. This let us jettison using the xresprobe program to ask the monitor for the settings to use. This cut out a lot of the code that we had to deal with, simplifying the configure script and letting us all benefit from upstream's work. This leaves a big gaping hole in user configuration, which is something I'm looking to address in a few weeks, but for now there are workarounds like editing your xorg.conf manually to make things work.

Finally, yesterday I was able to upload a version of the script that no longer uses the discover program to figure out what driver to load. I've patched the server to do this at runtime. If there's no driver listed it simply scans the PCI bus, picks out your primary video card, and loads the first driver that claims to support that PCI ID. This let us jettison the last external dependency that the configure script had, so now we have a relatively small chunk of shell script with no external C code and a simplified setup. At this point we're now shipping a more skeletal config file than knoppix ever did simply because it wasn't possible to ship something like this before and have the server work at all. This is a huge milestone for me because finally, after over three years, the problem I originally set out to work on with X is done. There's still bugs to uncover and fix with all of this, but I'm convinced that what we have now is superior to our old method. Eventually, with any luck, xorg.conf will just fade away for most people. There's a lot to work on before that happens though, but I'm happy to have finally gotten here.

Sarah slept better overnight, but still not great. She was certainly more lively this morning when I got in, than yesterday. She's resigned to the fact that you don't come to a hospital to get rest, which is kind of ironic. She did need to get put back on the oxygen overnight because her O₂ saturation dropped. She was off it again by the time I got in. Today's big achievement was getting the external pacing wires removed. They were put in during the procedure as a precaution, I think because if her heart played up, they didn't want to have to use defibrillator paddles, and because they'd cracked her chest open, manual CPR wasn't an option. The wires could be attached to an external pacemaker if necessary (but it never was). I watched the removal quite closely, as I was pretty curious. Basically the physician's assistant just came in and yanked them out. Judging from the look on Sarah's face, it was an interesting sensation. We were both amazed at how long the wires were. There was probably 30 centimetres of wire under the skin. The last bit was loosely spiralled. I was just really surprised, because the PA's hand started off at Sarah's chest, and ended up at the PA's shoulder. It was just a lot longer than we both expected. All the extra length was because the wires wrap around the heart. The wires came out at about 2:30pm. Sarah had another chest x-ray and a CT scan today. The CT scan looked good. The x-ray showed some fluid in her lungs, and her lung capacity is still sub-par. It seems when she's fully horizontal, her breathing isn't so crash hot, but it's fine when she's sitting up or walking around. All Sarah's got left is one peripheral line now. There was some talk of her possibly going home on Wednesday. She has an echocardiogram tomorrow, and I guess it'll all hinge on how her lungs are going.

Since September 19th I have been mostly offline and unreachable. This was due to having started a new job in a wonderful new project: soitu.es, an online newspaper with a strong focus on Citizen Journalism: citizens playing an active role in the process of collecting, reporting, analyzing and disseminating news and information, I must mention the master mind behind this all: Gumersindo Lafuente, one very well known journalist in Spain. On the other hand, working with Ra l Rivero, not the Cuban poet but the technical soul of the project, is something I would pay for, and I get actually paid to learn from him! Too bad he doesn t digg Debian :)



The site was finally launched during Xmas, and we are all less busy, so despite having what I call the weekend flu (that only affects me during the weekends, but I never feel so bad that I need to miss work during the week), I am back to normal, If you thought I was quite MIA, keep in mind I was not one of busiest ones at work! Launching such a project takes a toll on everyone, though. I set up a Flick set for my new workplace: Amayita s Soitu.es Flickr photo Set, in case you are curious. There is also an official Soitu.es Flickr Photo Pool.

Today is a holiday in Spain, due to D a de Reyes, when kids usually get their Xmas presents here. As I am fully recovered from this weekend s flu (today is Monday after all), I had some spare time and my cats got a nice present too: A DIY scratching post. There is a WTF column in the effing middle of my kitchen, so after some cardboard, a wall stapler, sisal rope and a bit of round and round the column... This pic shows the result:



I couldn t resist filming a video, available on YouTube: This scratching post is now mine! - No! Mine! - I ll get you!

I had been eyeing an inexpensive network-storage device -- for the non-geeks: think of a hard disk with an ethernet port and some controlling software -- for some time. I was aware of some of the hacking efforts around a few of these but somehow nothing really appealed. I was sort-of looking for nslu2-with-a-disk, and preferably not too expensive. Lo and behold, that's what I saw today in my techbargains feed: a Buffalo LinkStation Live which contains a 500gb SATA for $199 after rebates. Some quick googling lead to these wiki pages which looked promising: anything from enhancing the stock Linux setup by enabling a few more services to a custom Linux distro (similar to my wrt54 router running linux) to reportedly some work-in-progress for a native Debian installation. Nice! So off I went, ordered the thingie for local pickup for an additional 5% off and picked it up a little later at the local Circuit City (where visits are seemingly a recurring event these days). The documentation is very brief and insist that you install something on Windows -- just to find that the little box autoconfigures itself just fine. Presumably some network discovery is going to find the assigned dhcp address which is needed for the web interface. A few minutes later, a new (fixed) IP address was assigned, ntp was enabled and that was about that. After dinner, I quickly followed this tutorial to get the box a bit more Unixy without going too far (yet) from the default: start up telnet via a simple Java command-line tool, login, then enable ssh, set it up in /etc/init.d, add some extra binaries. All very quick and simple [ with the caveat that the addons.tar didn't want to get there via the Java tool, so manual scp once 'inside' did the trick ]. NFS, which I like for shuffling files around, appears to be little trickier for this ARM-based LinkStation Live. So at least for now I am content with simple rsync'ing of my backup directories on the few machines here. Much better than the current setup with mutual backups between workstations and semi-permanently being out of space. All in all a rather pleasant gadget and recommended at the price. The extra $100 in rebates are valid from today to the 12th.

Slow day today. I slept at home, and got in at around 9:40am. Sarah didn't sleep well again overnight, her O₂ saturation levels kept dropping below 90% because she wasn't breathing deeply enough in her sleep, and that causes an alarm to go off. So she was pretty flat when I first got in, but she picked up as the day went along, and was fairly chirpy by around 11am. The doctor came by and explained the photos that we've been given, so I'll have to try and regurgitate all of it and update the captions. Her lungs are still looking a bit suboptimal. The third lobe on the right lung isn't inflating well apparently. They said something about there being some fluid as well, although the nurse said she can't hear anything. All that said, she spent a lot of time in a chair today, and her O₂ saturation levels have been the best they've been since she was in the ICU. So good, that they're trialing having her off oxygen while she attempts to take a nap as I write. Her blood sugar levels are settling down. I think they're still slightly elevated, but not to the point that insulin is required. She only needed insulin with lunch yesterday, so it definitely looks like it's improving. She's already been on her three walks today, by 4pm. An occupational therapist came by, and went through the sternal precautions again, and showed us how to get in and out of bed without putting undue pressure on the sternum, and Sarah's been getting out of bed unassisted from horizontal since. Her pain has been quite manageable. So while today started out looking like it was going to be a small backward step, I think it's still a good move forward. Sarah's continuing her breathing exercises, so I'm sure her lungs will sort themselves out in the next day or two. I guess they'll take another chest x-ray this afternoon, although it's getting a bit late in the day. Sarah's starting to get a bit of cabin fever, but I think today's been pretty slow, in part because we deferred having visitors on account of her being not up to it in the morning.

I want to echo what Brice has said so well already. X is full of interesting problems and important things to work on. When you consider the free software that's out there, very little of it comes close to the importance of X in your day to day life. When we've done our job well, you don't even think about it because it just works, but when X fails it's like a minor catastrophe. Working on the kernel is largely considered to be something glorious and grand, but people tend to ignore X even though it plays very much in the same domain as the kernel. So working on X you not only get to play with interesting problems that are similar to the ones that the kernel folks get to play with, but you also get to work on software that's critically important and makes a significant difference in people's day to day lives.

Furthermore, X.org is a great organization to work in. The number of core contributers is very few (maybe 20 all told) so everyone knows who everyone else is and people are willing to help others out by answering questions about how things work. Reflecting this, the XSF has turned in to a fantastic team over the past few years, and it's one I couldn't be prouder to be a part of. Julien and Brice are doing insanely fantastic work, and we're constantly pushing to do a better job at just about everything, from collaborating with Ubuntu to using the best cutting edge tools out there for our work.

Despite all this though, as Brice said, we're overwhelmed by everything. We're still carrying hundreds of bugs in the Debian BTS alone, most of which we'll never have a chance to look at again. As mentioned elsewhere on planet upstream is totally swamped as well. There's just too many critical projects that need doing (new drivers, fixed drivers, adding capabilities to the server, and that's ignoring day to day needs like documentation and patch review) and too few people to do them effectively. We have a wonderful set of things to do and a great group of people to mentor motivated people to do them, and yet we're still lacking contributers to this critically important set of software.

So as Brice said, if you want to get involved in something that's essentially important to Linux and Free Software, if you want to get involved in something with great problems and really fantastic opportunities to make a difference, you can't do much better than getting involved in X. Brice's method of getting involved in processing bug reports is a perfect way to start. Another is to write much needed documentation. Another is to simply help the XSF maintain some small piece of the Xorg stack, be it a driver for some hardware that you own (the XSF only really runs two or three video drivers collectively so we badly need driver maintainers), or just start poking at something you're curious but mystified about like how mesa or the X server work. There's no magic to any of it, and while it can get complicated I promise that you will become a better coder or maintainer by working on something as challenging as X. You don't have to understand it all from the start, just picking a small thing to work on will be greatly appreciated. So drop us a note on the debian-x list or drop in to #debian-x on oftc and we'll help you get going.

There have been several long-term wishlist bugs on Mutt to include the (in?)famous "sidebar" patch. It adds a panel on the left side of the screen to list mailboxes with message counts. We do ship several patches with Debian's Mutt package that are not considered for inclusion by the upstream authors, but this one is different. It touches the core of the UI renderer and adds extensive counting of messages. There's been quite a hype about the patch, it was even included in the (now discontinued [1]) mutt-ng fork. Unfortunately, the patch was technically questionable, it was written for the Mutt tarballs and didn't easily apply to CVS, and most versions floating around contained lots of cruft like backup files and temporary editor files. Furthermore, it is far from bug-free and even segfaults occasionally. Some months ago we decided we would build a second binary package to put the patch in so we don't destabilize the standard package. Thanks Dann Frazier, we got a clean patch, Adeodato had the right idea on how to build two binaries from the same, differently-patched source (make install would run havoc, the trick was to build the patched version before the regular one), and I resolved some more involved conflicts with the maildir-mtime patch. So, finally, there it is: mutt-patched. Disclaimer: As said, there are bugs. YMMV. On related news, there's now also a -dbg package now for the victims of the IMAP and header cache segfaults that we still see sometimes. Update: The sidebar patch was not the reason for the creation of mutt-ng, but many mutt-ng users were using it because of this patch. Update 2008-01-08: [1] mutt-ng used to be a Mutt fork. It is now maintained as a patch collection for Mutt.

This week-end, among other things, I played a little to get the number of bugs reported overs years in the Debian BTS. Here are the results:

2007: 53337
2006: 59665
2005: 57436
2004: 62327
2003: 50836
2002: 47618
2001: 46289
2000: 27181
1999: 22448
1998: 15002
1997:  9987
1996:  4205
1995: 2158
First bug for each year:
2008: 458489 Petter Reinholdtsen -> sysqrd Closed (in unstable)
2007: 405152 Martin-Eric Racine -> myspell-lv Closed
2006: 345487 Erich Schubert -> lintian Opened
2005: 288051 Nick Sillik -> gstreamer-misc Closed
2004: 225724 Peter van Rossum -> mldonkey-server Closed
2003: 174888 Chris Garguzi -> hotkeys Closed
2002: 127270 root@ttimo.net ->libapache-mod-auth-pam Closed
2001: 80981  William Steve Applegate -> php4 Closed
2000: 53800  Hamish Moffatt -> sattrack Closed
1999: 31352  Richard Stallman -> dselect Opened LOOK THIS ONE
1998: 16350  Joey Hess -> xbase-clients Closed
1997:  6363  Andreas Jellinghaus -> mgetty-fax Closed
1996:  2158  Ian Jackson -> ncurses3.0 Closed
1995:   563  Ian Jackson -> tar Closed

A few interesting things there:

• apparently the rate is now staging between 50,000 and 60,000 per year
• stats are less precise for the early years as many bugs are no more in the BTS (apparently that stops in 1999)
• I can't find the date where the Debian BTS was launched (-devel archives go back to July 1995 only)
• It bringed me the silly idea to check what are the oldest still opened bugs...next stupid blog entry, then !

Anyone feeling like doing the same for Launchpad? And, for those who wonder, I of course did all this by hand. No fancy automated script, just my hands and some (little) hammering of the BTS.

Sometime in the last few weeks Flickr started offering RSS feeds of favorites; as far as I can tell they didn't announce it anywhere. This was my #1 feature request. Yay!

One year ago, I started triaging the X.org BTS (by replying to #163057 iirc). I closed almost 1600 bugs since then, bringing the remaining ones to about 900 today. I am kind of proud of Ender's graph (when the URL works...). Even if the actual BTS triaging is done now, I still try to take care of X.org bugs. And it's not that easy unfortunately... Almost 650 new bugs were opened this year against X.org packages. 250 of them are already fixed, more than one hundred have been forwarded upstream. It doesn't mean that 300 bugs still apply to our packaging. Most of our X packages are simple (apart from the xserver-xorg postinst mess that David is cleaning). But, there are lots of problems that we have no clue about, or that miss some info because people can't upgrade to unstable, ... I am sometimes tired of getting so many bugs without being able to do much about them. Maybe because upstream doesn't care enough about some problems (lots of drivers are unmaintained and get broken more and more when new features are added for a couple more important drivers). So, I sometimes tend to concentrate my work on what I like and trust. Some people noticed that xserver-xorg-video-ati get very often updated these days (6 uploads in the last 20 days). Of course, the reason is that I own a r300 board :) But also because its upstream devs are very good, it's very nice and easy to work with them. Of course, we have a lot of work and few people to do it. That's kind of sad since playing with X is very interesting. Most users are very happy when discovering things like RandR 1.2 or Compiz. Getting a chance to test them early and understand their internals is very cool. But, as said in some other posts, hacking on X.org doesn't seem to look fun. If you're interested anyway, taking care of the bugs is a very easy way to learn a lot. I had no clue about X one year ago and I learned a lot by taking care of the BTS. I would be glad to get some help now :)

At the end of the month we are having linux.conf.au (one of the best Linux conferences in the world) in Melbourne. Here is some quick advice for people who are attending: If you have not yet booked a hotel then www.wotif.com is a good option to try, it’s a hotel booking web site that is aimed at last-minute bookings and offers significant discounts over the list price. A quick search on WotIf reveals that there are currently 5 hotels that are available for $140 per night or less for the time period of LCA. The rate listed is an approximation as the hotel may offer several rates for different types of rooms (it’s usually one of the cheapest options available from the hotel). I believe that some hotels don’t offer their rooms on WotIf until close to the day in question, so some more rooms may become available between now and the start of the conference. However the Australian Open [1] Tennis tournament ends on the 27th of January, if you plan to attend the LCA mini-confs then you will want to arrive on the 27th, so booking a hotel for that night at the last minute would be a risky strategy. If you want to stay somewhere that is comfortable but not overly expensive then you might want to read my post about hotel apartments [2]. My post about public transport in Melbourne [3] has some information that can save you some money. One possibility to consider is that if you use 10 * 2 hour tickets and don’t completely use them up then you could sell them to locals. I would be happy to buy some partially used tickets for the full value of the unused part on the last day of the conference to save people wasting the unused value. Note that my documents blog contains posts that will be updated whenever I have more information and the time to write it down (this blog is generally write-once). I will be updating the post about public transport significantly in future.

• [1] http://www.australianopen.com/


• [2] http://doc.coker.com.au/travel/hotel-vs-apartment/


• [3] http://doc.coker.com.au/melbourne/public-transport-melbourne/

Share This

Chris, buildd hosts keep those time and space usage statistics in a database, which can be queried...

Script started on Sat Jan  5 19:54:15 2008
wouter@country:~$ ssh kiivi.cyber.ee
Linux kiivi 2.6.18-4-mac #1 Fri Mar 30 23:05:11 CEST 2007 m68k
No mail.
Last login: Sat Jan  5 20:41:16 2008 from d51532c45.access.telenet.be
wouter@kiivi:~$ avg-pkg-build-time -s -t   head -n 20
boost:			2015312k (2015312k lastest)
iceweasel:		1846628k (1846628k lastest)
iceape:			1674172k (1674416k lastest)
icedove:		1624848k (1624848k lastest)
xulrunner:		1611880k (1611880k lastest)
mesa:			1230432k (1230432k lastest)
koffice:		1208062k (2115156k lastest)
gcc-snapshot:		1191866k (1207164k lastest)
gcc-4.1:		1185620k (1185620k lastest)
gtk+2.0:		1148634k (1208684k lastest)
k3d:			1145580k (1145580k lastest)
ardour:			1077800k (1077800k lastest)
lyx:			924876k (924876k lastest)
gcc-4.2:		909488k (909488k lastest)
gcc-3.4:		892015k (571084k lastest)
glibc:			891408k (891408k lastest)
linux-2.6:		725961k (744700k lastest)
kdebase:		720618k (1106804k lastest)
kdelibs:		716376k (1150372k lastest)
kdepim:			711858k (784356k lastest)
wouter@kiivi:~$ avg-pkg-build-time -t   head -n 20
gcc-snapshot:		220:52:14 (2 entries, sigma 27:38:21)
axiom:			216:27:57 (1 entry, sigma 00:00:00)
gcc-4.1:		193:47:30 (1 entry, sigma 00:00:00)
k3d:			177:22:10 (1 entry, sigma 00:00:00)
gcc-3.4:		171:40:28 (4 entries, sigma 25:10:55)
boost:			141:13:38 (1 entry, sigma 00:00:00)
koffice:		140:40:23 (2 entries, sigma 53:48:58)
ace:			130:04:14 (1 entry, sigma 00:00:00)
linux-2.6:		129:36:19 (3 entries, sigma 10:12:24)
qt-x11-free:		105:00:32 (1 entry, sigma 00:00:00)
xulrunner:		97:03:38 (1 entry, sigma 00:00:00)
iceape:			96:23:13 (2 entries, sigma 03:12:58)
kdepim:			96:06:54 (2 entries, sigma 19:09:39)
icedove:		94:35:48 (1 entry, sigma 00:00:00)
iceweasel:		93:56:26 (1 entry, sigma 00:00:00)
gcc-4.2:		91:08:32 (1 entry, sigma 00:00:00)
glibc:			91:01:58 (1 entry, sigma 00:00:00)
kdevelop3:		84:27:21 (2 entries, sigma 02:47:35)
kdeedu:			82:09:55 (3 entries, sigma 10:59:18)
vtk:			81:44:20 (3 entries, sigma 00:46:32)
wouter@kiivi:~$ logout
Connection to kiivi.cyber.ee closed.
wouter@country:~$ ssh arrakis
Linux arrakis 2.6.12-1-amiga #1 Sat Aug 13 22:59:59 CEST 2005 m68k
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Please read "links2 http://nefud/info.txt"
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
No mail.
Last login: Sat Jan  5 18:48:58 2008 from hahn.os.localnet on pts/5
wouter@arrakis:~$ avg-pkg-build-time -s -t   head -n 20
wxwidgets2.6:		1648020k (1648020k lastest)
qt4-x11:		1601086k (1753532k lastest)
gcj-4.1:		1135772k (1135772k lastest)
k3d:			1094345k (1159204k lastest)
kdebase:		1087375k (1087368k lastest)
python-kde3:		1018144k (1018144k lastest)
ghc6:			991524k (991524k lastest)
gcc-3.3:		988690k (990244k lastest)
glibc:			814536k (855720k lastest)
lyx:			804672k (804672k lastest)
bouml:			729888k (729888k lastest)
kdelibs:		685565k (1142304k lastest)
freedroidrpg:		673988k (673988k lastest)
mozilla:		663066k (636896k lastest)
ardour:			647580k (691128k lastest)
mozilla-thunderbird:	591384k (591384k lastest)
omniorb4:		576288k (576288k lastest)
subversion:		568764k (624768k lastest)
xorg-server:		527520k (527520k lastest)
mozilla-firebird:	498896k (502692k lastest)
wouter@arrakis:~$ avg-pkg-build-time -t   head -n 20
enlightenment:		198842:37:14 (3 entries, sigma 344403:17:35)
axiom:			164:43:54 (1 entry, sigma 00:00:00)
ghc6:			159:20:15 (1 entry, sigma 00:00:00)
k3d:			145:18:35 (3 entries, sigma 57:08:46)
python-kde3:		126:39:34 (1 entry, sigma 00:00:00)
qt4-x11:		121:26:11 (2 entries, sigma 03:07:35)
gcj-4.1:		116:05:34 (1 entry, sigma 00:00:00)
gcc-3.3:		108:45:19 (3 entries, sigma 02:01:50)
qt-x11-free:		99:12:17 (4 entries, sigma 14:12:32)
wxwindows2.4:		90:26:51 (1 entry, sigma 00:00:00)
openscenegraph:		74:37:21 (1 entry, sigma 00:00:00)
ardour:			63:44:55 (2 entries, sigma 07:23:05)
bouml:			62:01:16 (1 entry, sigma 00:00:00)
gcc-snapshot:		61:10:07 (1 entry, sigma 00:00:00)
mozilla-thunderbird:	60:47:29 (1 entry, sigma 00:00:00)
mico:			60:15:15 (1 entry, sigma 00:00:00)
kdebase:		58:41:04 (5 entries, sigma 08:00:17)
glibc:			58:04:26 (6 entries, sigma 40:01:12)
mozilla-firebird:	52:47:13 (2 entries, sigma 11:31:07)
zeroc-ice:		52:34:03 (2 entries, sigma 28:12:19)
wouter@arrakis:~$ logout
Connection to fremen-os.dyndns.org closed.
wouter@country:~$ exit
Script done on Sat Jan  5 22:28:46 2008

"avg-pkg-build-time" is a script that queries the statistics database. It's quite CPU-intensive, so I don't like to run it too often (certainly not from cron); but, hey, here you go. In case you didn't know, "arrakis" and "kiivi" are both official m68k/unstable buildd hosts, and especially arrakis has been for quite a long time, although it's been reinstalled once or twice since. Oh, and yes, it does appear as though some bits of the data are invalid, but most of the idea should be alright. (oh, and before you ask, no, it didn't take two and a half hours to run those commands -- I just needed to go while the last one was running, and had only come back several hours later)

The general idea on the 25th was to relax, watch some , and generally do not care too much about anything. Right, only after 13 episodes of ("Crest of the Stars") hunger set in, and it being late at night on a holiday, we scrounged the kitchen for things that might fit together. Idea 1: Let's make Spaghetti Alio e Olio. — Well, no Spaghetti in the house. So replace them with Farfalle. Idea 2: We could also add some onion. — Splendid. Idea 3: We could add sugar to the onion. — Yay, caramel. Unforeseen Circumstance 1: Whoops, not that much sugar. Idea 4: It being Christmas, and the food being awfully sweet now anyway, let's add apples and cinnamon. So, I present the ultimate Christmas dinner, featuring:

• as much garlic as you like
• an onion
• sugar
• an apple
• noodles

And it tasted quite good, actually. I shall remember to buy more food before the holidays next year though.

Anthony Towns wrote about user configuration (i.e. ~/.foo) and the XDG spec/proposal versus his own (and according to him) simpler version. The main goal of all this is to get rid of all the ~/.foo directories and files in a users home directory. Apart from technically minor differences, I don’t see why AJs proposal would be simpler than the XDG approach. All it does is hardcoding the values which are adjustable in XDG via XDG_*_DIRS. There is one notable difference though: AJ proposes fallback values which are compatible with existing application paths (i.e. HOME_ETC/XDG_CONFIG_HOME should default to ~/ - resulting in ~/.foo files/dirs). This is a good proposal in a way: If you patch an existing application to strictly follow the proposal made by AJ, it still finds its old configuration (and other files) if the new environment variables are not set. No need to move anything around. However, I think the XDG approach is better since it makes sure that compliant applications don’t clutter ~/ anymore. They do need some mechanism to move existing configurations and data around though if the XDG-compliant stuff isn’t already there, but an old style config exists. All in all, I think it is worth following the XDG spec, even if it is slightly more complex than AJs proposal. For one, it already exists for a while and I think that some applications already started following that spec. It also makes slightly more sense to me to have the system fully configurable as to where the apps store data as opposed to the hardcoded fallback/default values AJ proposes (even if we would change AJs proposal to use “$HOME-cleaning” default values).

Inspired mostly by Joey’s nonchalant way of dealing with the death of his laptop…

This seems less of a disaster than other times a laptop’s disk has died on me. When did it start to become routine? […] My mr and etckeeper setup made it easy to check everything back out from revision control. […]

…I’ve been looking at getting all my stuff version controlled too. I’ve just gotten round to checking all my dotfiles into git, and it crossed my mind that it’d be nice if I could just set an environment variable to tell apps to create their random new dot-files directly in my “.etc-garbage” repo. I figured using “$USER_ETC/foo” instead of “$HOME/.foo” would be pretty easy, and might be a fun release goal that other Debian folks might be interested in, so I did a quick google to see if something similar had already been suggested. The first thing I stumbled upon was a mail from the PLD Linux folks who apparently were using $HOME_ETC at one time which sounded pretty good, though it doesn’t seem to have gotten anywhere. That thread included a pointer to the system that has gotten somewhere which is the XDG spec. It’s actually pretty good, if you don’t mind it being ugly as all hell. They define three classes of directory – configuration stuff, non-essential/cached data, and other data. That more or less matches the /etc, /var/cache and /var/lib directories for the system-wide equivalents, though if the “other data” is stuff that can be distributed by the OS vendor it might go in /usr/lib or /usr/share (or the /usr/local/ equivalents) too. Which is all well and good. Where it gets ugly is the naming. For the “/etc” configuration stuff, we have the environment variable $XDG_CONFIG_HOME, which defaults to ~/.config, and has a backup path defined by $XDG_CONFIG_DIRS, which defaults to /etc/xdg. For the “/var/lib” other data stuff, we have the environment variable $XDG_DATA_HOME, which defaults to ~/.local/share, and has a backup path defined by $XDG_DATA_DIRS, which defaults to /usr/local/share:/usr/share. (Though if you’re using gdm, it’ll get set for you to also include /usr/share/gdm) And for the “/var/cache” stuff, we have the environment variable $XDG_CACHE_HOME, which defaults to ~/.cache. That seems to me like exactly the right idea, with way too much crap on it. If you simplify it obsessively – using existing names, dropping the desktop-centrism, you end up with: Put configuration files in $HOME_ETC/foo or $HOME/.foo. For shared/fallback configuration, search $PATH_ETC if it’s set, or just /etc if it’s not. Put data files in $HOME_LIB/foo or $HOME/.foo. For shared data, search $PATH_LIB if it’s set, or look through /var/lib, /usr/local/ lib,share and /usr/ lib,share if it’s not. Put caches in $HOME_CACHE/foo or $HOME/.foo. For shared caches, search $PATH_CACHE if it’s set, or just look in /var/cache if it’s not. That seems much simpler to me to the point of being self-explanatory, and much more in keeping with traditional Unix style. It’s also backwards compatabile if you use both old and new versions of a program with the same home directory (or you happen to like dotfiles). And having the XDG variables set based on the above seems pretty easy too. I wonder what other people think – does HOME,PATH _ ETC,LIB,CACHE seem sensible, or is XDG_ CONFIG,DATA,CACHE _ HOME,DIRS already entrenched enough that it’s best just to accept what’s fated?