This morning I gave a talk at the Security mini-conf of LCA about the status of SE Linux in Debian. Here is a summary of the issues I covered: General Status In Lenny (the new release of Debian that will come out in a month or two) SE Linux is working well. Considerably better than in Debian/Etch. There is an installation document on my documents blog [1], it s very easy, only two scripts need to be run with no parameters to do most of the work (5 commands in total). There is more detail on installing SE Linux in Lenny (and other issues) in the Debian Wiki [2]. The default configuration of SE Linux is targeted . Previously we had separate policy packages for targeted and strict , now they are configuration options for selinux-policy-default. It is also possible to have some users in the unconfined_t domain (like the targeted policy) and some in confined domains such as user_t. Changing to strict can be done one user at a time, this needs further documentation. Backports I maintain an APT repository of i386 and AMD64 packages for better SE Linux support. This includes libraries built to not need an executable stack (see my previous blog post for details [3]). It also includes i386 libraries that don t need text relocations AKA execmod (see my blog post about why i386 must die for details [4]). My Lenny repository includes policy packages before they appear in Testing as well as the packages that are modified to fix the execmod and executable stacks issues. I plan to maintain this repository for some time, at least as long as I am actively using Lenny, but the content will change. I might back-port the newer upstream policy to Lenny at some later date. If I do this it will be near the time that Lenny+1 is released and I will put it in a different location to my current Lenny repository. I am currently deciding what to do with packages from external repositories such as debian-multimedia (see my previous post for the background) [5]. I may have to create a separate repository for non-standard Debian packages which I then modify to better support SE Linux. I also plan to build packages of Security Enhanced PostgreSQL [7] for Lenny and Lenny+1. After demonstrating it s capabilities I will suggest that it be considered for Lenny+1. Play Machine I have been running a Play Machine (open root machine) [6] for most of the last seven years. In the near future (probably the week after LCA) I will upgrade it to Lenny. One thing that I didn t mention is the fact that I plan to demonstrate other things such as SE-PostgreSQL in Play Machines. Training I have a Xen server that is used for my Play Machine, I will run it as a SE Linux training machine and grant temporary ownership of a DomU to anyone who wants to learn and have a document with a list of tasks to complete to learn about SE Linux. I might be able to get it online this week. If so then I ll make it available first to LCA delegates. I will also set up a Bittorrent server for a Xen image for anyone who wants to go through the same SE Linux training program on their own machine - this will allow them a greater time limit and also avoid contention for my server. Unfortunately I have some problems with BitTorrent, I would appreciate any advice about running a torrent tracker. Post Lenny SE PostgreSQL is an exciting new development that I want to get in Debian. Initially I will create my own APT repository for it and include it in my Lenny repository. Hopefully it will become a standard feature in Lenny+1. Security Enhanced X (the X window access controls) is a significant security feature. I hope to have that in Lenny+1, but it might not be possible.

• [1] http://doc.coker.com.au/computers/installing-se-linux-on-lenny/


• [2] http://wiki.debian.org/SELinux/Setup


• [3] http://etbe.coker.com.au/2008/08/11/executable-stacks-lenny/


• [4] http://etbe.coker.com.au/2008/09/11/execmod-and-se-linux-i386-must-die/


• [5] http://etbe.coker.com.au/2009/01/12/debian-multimedia-and-se-linux/


• [6] http://www.coker.com.au/selinux/play.html


• [7] http://wiki.postgresql.org/wiki/SEPostgreSQL

My son Andrew is now ten weeks old, and already I ve learned so much. For example Being a good parent occasionally means being a proper adversary It s much harder than you might expect, and happens more often than you might expect. A pacifier is an excellent way to calm him down, especially when he has gas pain (and a pacifier can also reduce the risk of SIDS); however, he would let it fall out of his mouth when he wasn t sucking on it. Rather than hold it in, if you tug on the pacifier a little bit, it teaches him how to suck on it so it doesn t fall out. Sometimes what s best is actually not so good Andrew has a food allergy, but we re not exactly sure what he s allergic to. For the last couple weeks, he s been on Nutramigen, a hypoallergenic formula specifically for babies with food allergies, and has been responding really well. Meanwhile, Lisa s been on an elimination diet, eating mainly chicken and rice, trying to get everything he might possibly be allergic to out of her system so she can start nursing again. Recently, Lisa started nursing at an occasional feeding, and he coincidentally seems to have gotten more fussy. He s not screaming in pain like he was before going on the formula, and it s hard to say that it s because of the breast milk. Still, we re thinking about going back to just formula and seeing if he improves again. I read too much When I was a child, and still to this day, I had pretty severe sleep problems. I didn t sleep through the night until I was 18 months old. So before Andrew was born, Lisa and I read a few books about how to establish a healthy sleep pattern. All of them had various theories about why children develop sleep problems, and how to quiet a baby and establish a routine. Now we re so full of conflicting theories about problems that will develop if we do or don t follow some guideline, that it s hard to make a decision about what s best sometimes. It doesn t help that, in part due to his food allergy, he ll sleep through the night one night, and the next night wake up every few hours. Fortunately, only one feeding in the middle of the night has been the norm for quite some time, so it hasn t been too bad.

The U3 software that everybody so loathes is somewhat hacker technology. It's not entirely unlike the Sony rootkit, except it (as far as I know) by default doesn't install persistently.Fortunately, it doesn't work on Linux.What U3 essentially does is the following:

• For security reasons, Windows doesn't do auto-run on USB disks (which is good!)
• To overcome this limitation, U3 emulates a CD drive in addition to the actual USB disk (Hack #1)
• To make this work, U3 reserves part of the Flash disk that you cannot write to (Hack #2)

It probably is just a matter of time until the first viruses find out how to install themselves onto the U3 partition and get auto-run whenever you plug in such a stick.So if you plan to buy a USB pen drive, make sure it doesn't bear the U3 logo. If you end up with such a hack-drive, grab the Uninstall application from U3, which unfortunately is Windows and Mac only. If anyone found a way to erase the U3 partition on Linux, please share. A low-level format on the usb-storage device is not sufficient.

FOSDEM is a 2-day weekend of insanity. 218 talks this year; if you want to understand exactly how insane that is, have a look at the schedule grid. There are 19 rooms where events are held; possibly more, since I understand not every devroom has sent in its schedule yet. Might be hard for people to make a choice that way, I guess. Now there're supposed to be abstracts of each talk on the FOSDEM website, but reading them all can be quite tedius. In an effort to help, at least for the Debian devroom, here's the schedule for our devroom with a bit of explanation of what it's about. Note that this is mainly aimed at people not familiar with Debian; those who are should probably understand it enough by looking at the titles. Saturday: 13:00 - 14:00: 'Outside broadcast on a budget - the DebConf video team and DVswitch'. DVswitch is the software used to create those excellent Debian videos. The best ones yet, IMO, are the ones of Debconf8. Check them out. There's nothing Debian-specific about DVswitch, except that it was written by Debian people. It's a great way to do live Internet .ogg streaming by using nothing more than DV cams, Firewire, and plain old Ethernet. 14:00 - 15:00: 'Ultimate Debian Database: datamining Debian made easy!'. UDD is a SQL database containing a shitload of data related to Debian, and which should allow easy datamining. Hence the title. This probably won't be of any interest to people who are not either a Debian Developer or a statistician, but I might be mistaken. 15:00 - 16:00: 'Introducing DDE, Debian Data Export'. This is a new project Enrico came up with, and which is related to the same subject as the previous talk. I don't know much more beyond what's in the abstract. However, given the fact that Enrico is going to be doing this talk, it can't be bad. Seriously. 16:00 - 17:00: 'The Debian status quo on the Openmoko Neo Freerunner'. Yup, Debian runs on the OpenMoko, and has done so since Debconf8, last august. This talk should give some more insight; if you have an OpenMoko, this definately is for you. 17:00 - 17:30: 'Running Debian on Inexpensive Network Storage Devices'. I've been running Debian on a Thecus N2100 for a few years now, and it's great. There are more options, however, and Martin does most of the hard work related to these devices. He's done a similar talk on the two previous FOSDEMs (go check out the videos), and this one will mainly be an update on what's going to be new in Lenny. 17:30 - 18:15: 'Grid Computing with Debian, Globus and ARC'. These guys are a group of academics from three different universities who've been doing grid computing (i.e., something like 'SETI@Home', but then somewhat different) with Debian and some other technologies. They'll be explaining how, exactly. I don't know much about this talk; it could be great, or it could fail miserably. I guess we'll see. 18:15 - 19:00: 'What does the DPL do?'. This is really firmly targetted at Debian people. If you're not in the least interested in how Debian does things, you'll be bored. Sunday 09:15 - 10:00: 'The state of Virtualization in Debian'. If you're a Debian user interested in virtualization, this talk is for you. Henning will explain what virtualization options exist in the upcoming 'Lenny' release, and how to use them. 10:00 - 11:00: 'TDebs'. This might not be too interesting to you unless you happen to be involved in Debian infrastructure. TDebs don't exist yet, but will sometime soon; Neil will be explaining how, why, and what. 11:00 - 12:00: 'Internationalization in Debian: How to improve further?' If you're interested in i18n, this is probably for you. 12:00 - 13:00: 'The Common Debian Build System (CDBS)'. CDBS is one way to build a Debian package. This is probably only of interest to Debian people. 13:00 - 14:00: 'Release management in Debian - can we do better?'. Frans isn't a member of the release team, but has some criticism on how they function. He intends to present his arguments in order to start a discussion. This is Debian internal kitchery, really. 14:00 - 15:00: 'Lenny - the road to release'. Neil is a member of the release team, and is going to explain how we got to the current state. I hope he'll also explain why we still haven't released. I guess we'll see :-) 15:00 - 16:00: 'The long road to KDE4 in Debian'. Um, yeah. I'm not a KDE guy, but I understand some other people are. In any case, might be an interesting talk even if you don't use Debian, since I understand it will look at some of the new features in KDE (and how they relate to packaging). 16:00 - 17:00: 'Debian and Google Summer of Code 2008: wrap-up and insights'. I guess Leslie will be there. The speaker was a student working on Debian during this year's SoC, and he will present what's been accomplished. There, that's it. Now my only hope is that there'll be many people attending. If previous editions are any indication, however, that won't be a problem.

Continuing with my mission to control the power to some dumb USB-powered lights... Dann Frazier confirmed my theory that a USB hub would indeed do the job. I'd already found the hub-ctrl.c program he mentioned, but couldn't get it to work with my built-in USB ports of my laptop. It seems it all depends on whether the hub will support per-port power switching or not. (lsusb -v will tell you). So off to the mighty institution that is Fry's Electronics I went. The first two attempts failed, as did a borrowed hub. It seems most (at least the cheap one) use a Genesys Logic chipset, which does not support per-port power control. Fortunately I chose products that weren't in blister packs, so I was able to return them to Fry's in as-new condition and try again. Now that I knew USB hubs would do the trick, I did some more targeted searching, and found this thread where someone had been messing around with hubs to do what sounded like what I wanted. (Incidentally, this email in the thread also provided a nice looking Python program. I'm going to look at refitting it to use the "real" Python USB module.) I emailed the poster to ask him what brand of hub he was using. The answer was the Linksys 4-port hub So I managed to track down one of them last night. Yes, it works, but the downside is the hub itself requires external power, which is a bit unfortunate. Not only do I need to use a hub to make these lights software controllable, I have to plug the hub into a power outlet. Bleh.

I am happy to announce general availability of darcs 2.2.0. Getting the release For this release, we have decided to provide two flavours, depending on the build system used:

1. The source tarball, http://www.darcs.net/darcs-2.2.0.tar.gz, which can be built using the traditional autoconf-based system. This is the fully supported version. After downloading and unpacking, you can issue:

   $ ./configure
   $ make
   

   and possibly

   # make install
   

   More detailed instructions inside the tarball (file README). Please note that we had at least one report of build failure, with quickcheck-related message. The currently best workaround, if this happens to you, is to use the cabal version of the package instead, see below.
2. Cabalised source. You can either download a tarball from http://hackage.haskell.org/packages/archive/darcs/2.2.0/darcs-2.2.0.tar.gz and build manually (see the build instructions in README inside the tarball), or, alternatively, you can use cabal-install to obtain a copy:

   $ cabal update
   $ cabal install darcs
   

   This will give you a darcs binary in ~/.cabal/bin you should probably add that to your PATH.

In addition to source tarballs, we expect binary packages for various UNIX platforms will be available in due time. For Windows users, Salvatore Insalaco has prepared a binary build, available from http://homepage.mac.com/kirby81_it/darcs/darcs-2.2.0-win1.zip. You just need to unpack the directory somewhere and add it to your path (if you like). Moreover, an experimental TortoiseDarcs release for darcs 2 has been made available by Kari Hoijarvi and is looking for home. It can be found at http://datafed.net/darcs (unfortunately, at the time of this writing, the site seemed unreachable If you can help with hosting, please mail Kari.) What s New The summary of changes since version 2.1.2 (released last November) follows:

• In interactive record, it is now possible to get a list of currently selected hunks (command l). (Christian Kellermann)
• It is now possible to specify --in-reply-to when using darcs send, to generate correct references in the mail header. (Pavel Shramov)
• New repositories with --no-pristine-tree can no longer be created. This only has effect on legacy darcs-1 repositories.
• Improvements in Windows support. (Salvatore Insalaco)
• Performance improvements in darcs repair and robustness improvements in darcs check. (Petr Ro kai)
• Extensive manual and online help improvements. (Trent W. Buck)
• Support for GHC 6.10.
• Overhaul of the make-based build system. (Trent W. Buck)
• Cabal is now supported as a build method for darcs. (Duncan Coutts, Petr Ro kai, Gwern Branwen)
• First stab at libdarcs when building through Cabal, all of darcs implementation is now exposed in modules. No API guarantees whatsoever. (Eric Kow)
• Additions to Haddock documentation of the existing darcs modules for improved development experience.
• Improvements in the testing infrastructure. (Christian Kellermann, Gwern Branwen)
• Low-level optimisations in filesystem code. (Ganesh Sittampalam)
• Numerous major and minor bug fixes, refactorings and cleanups by David Roundy, Eric Kow, Jason Dagit, Dmitry Kurochkin, Thorkil Naur, Salvatore Insalaco, Christian Kellerman, Florent Becker, Duncan Coutts, Reinier Lamers, Ganesh Sittampalam, Petr Ro kai.

And a summary of issues that have been fixed in darcs since version 2.1.2 (compiled by Thorkil Naur): 525 amend-record => darcs patches show duplicate additions
971 darcs check fails (case sensitivity on filenames)
1006 darcs check and repair do not look for adds
1043 pull => mergeAfterConflicting failed in geteff (2.0.2+)
1101 darcs send cc recipient not included in success message
1117 Whatsnew should warn on non-recorded files
1144 Add darcs send in-reply-to or header In-Reply-To: x@y.z
1165 get should print last gotten tag
1196 Asking for changes in /. of directory that doesn t exist gives changes in entire repo
1198 Reproducible mergeConflictingNons failed in geteff with ix
1199 Backup files darcs added after external merge
1223 sporadic init.sh test failure (2.1.1rc2+472)
1238 wish: darcs help setpref should list all prefs
1247 make TAGS is broken
1249 2.1.2 (+ 342 patches) local drive detection on Windows error
1272 amend-record not the same as unrecord + record
1273 renameFile: does not exist (No such file or directory)
1223 sporadic init.sh test failure (2.1.1rc2+472) I would like to thank all contributors for making this release possible. Future The next release will be 2.2.1, fixing low-risk issues found in 2.2.0, or those that have been excluded for 2.2.0 due to freeze. This release will appear in two or three weeks time, depending on circumstances. The next major release will be 2.3, due in June or July this year. The focus of this release will be new features and further work on performance. Moreover, we expect that it will use Cabal as its default build system and will make first steps towards sustainable libdarcs API.

Someone posted a comment to my previous post on ACLs; and now Andrew blogs about the same question: Why don't I believe in multiple filesystems for a laptop? Andrew's arguments don't really convince me. A filesystem eating itself? That's never happened to me yet. A hard disk dying on me, however, I've had that. Since I first owned a computer with a hard disk, I think there've been 5 of them. There's only one thing you can do against that -- have a proper backup strategy. That not only protects you against losing your data due to the somewhat likely event of a hard disk dying, it also protects you against losing your data due to the somewhat unlikely event of a filesystem eating itself. On the other hand, however, a laptop hard disk is usually slow, small, and painfully so. Partitioning already-small hard disks into even-smaller partitions therefore doesn't sound like a particularly bright idea to me. Losing half a gig on unused space for /, then 400M for /usr, and 600M for /home, and another 2G for /var, or some such, is pretty stupid if you want to store a 3G file that you want to burn to disk; you have the available space, but you don't have it in one partition, so you get to do the cleanup dance. And nobody likes to do that, right? Oh, and don't try to fool me I have yet to see a laptop that's been in use for more than a few months and whose disk is not filled to all but a few gigabytes. Nobody removes files until they're out of space, and then you only remove just as much as you need to be able to do the job at hand... Occasionally, I do install server systems with multiple filesystems, and with LVM. On a server, the inability of a run-away system process (or user) to 'accidentally' fill up the root filesystem with junk is definately a life-saver. But once you have lost data, you need to recover anyway, and having partitions doesn't particularly help you in doing that. Also, servers tend to have multiple huge disks in a RAID array, so loss is less likely, and disk space is plenty; as such, the loss of 10% on the LVM overhead isn't something I care about, which it is on my laptop. But, hey, to each their own preference. I won't look at you funny for preferring multiple partitions on your laptop. Promise!

How not to start your day, from the all-hardware-sucks department. For years, I ve been struggling to keep my machines quiet. I ve miserably failed for years, and pretty much gave up once I realised that the quiet parts I was looking for just did not exist. Last year, I finally found what I was looking for:

• big, heavy, quiet case from Chieftec (with room for 8 HDD and their own dedicated 90mm fans (up to 3) and room for 2 120mm case fans);
• ber-engineered fans from Noctua (finally some guys took a shot at engineering fans, happiness \o/);
• fanless (except for the emergency fan) PSU from Antec (Phantom 500).

I ve been very happy with this hardware for both my workstation and my filer. Well, until today. No need to mention that this hardware is not exactly cheap, but the price is right for the quality. So, wake up today, do random things, grab my TomTom, unplug it from the workstation it s sucking its power from, do things, plug it back in the USB port so it won t draw its battery. This is how it went:

• plug TomTom into USB port;
• notice the LED is blinking, and it should not;
• erupt a mental WTF? and simultaneously hear *clac* *pffzziiouuuu*;
• unplug TomTom;
• replug TomTom, notice the LED is blinking again;
• look at the machine, notice it s gone down;
• check the PSU and erupt a verbal WTF?! noticing the LED on the PSU is not lit.

Check machine temp, PSU temp, attempt to restart PSU, check UPS, check cables, replace power cable and bypass UPS. Admit defeat for this round and accept the PSU as dead. Pull out the machine, rip out the fscking damn PSU. Grab the tools, crack the PSU open. Notice bulging and leaking capacitors. Yes, this PSU is anything but cheap, yet it uses el-cheapo chinese capacitors. Antec, you suck, big time. For the past decade everybody in the industry has known that el-cheapo chinese capacitors manufactured after 1999 are total crap, using an electrolyte that isn t actually one because its formula was stolen by industrial spies who got totally PWNED and ended up stealing a bad formula. (If you need a reference, google for singing capacitors . Note that singing capacitors can also happen with good parts used in a crappy electronic design. Like that 100 Mbps D-Link switch over there, or that Sony-Ericsson mobile phone charger. Hmm. Not everybody can hear it, I do.) A healthy, young capacitor should not bulge nor leak. A capacitor that leaks, bulges or sings is a crappy capacitor and needs to be replaced with a quality part ASAP. I ve been routinely replacing such capacitors on my older motherboards (manufactured between 1999 and 2001) in the past years. I ve not had the problem in ANY of my el-cheapo PSU, and did not replace any capacitor in any of them to date. Fortunately, the machine did not suffer any further damage, nor did the TomTom. Everything is up and running again with a spare PSU. I m now going to replace the fscking capacitors on this PSU, replace the fuse, probably R&R a couple of high-voltage transistors too (they have a tendency to fry before the fuse blows out) and get it back up and running. Then I ll do the same with the other PSU in the filer, because that machine has 8 disks attached, so draws more power and hence is much more vulnerable. Fuck you Antec.

We added Debian support for the HP Media Vault mv2120 this summer and it works very well. While this NAS device is easily available in the US, I have unfortunately not been able to find it in Europe so far, which obviously limits the number of people who will run Debian on it. Yesterday I learnt that the mv2120 is sold in Europe under the name HP Media Vault Pro mv5020 (GX666AA). I found some shops in the UK that sell the mv5020 but I assume it's also available in other parts of Europe.

Dear Lazyweb, I m looking for recommendations for Open Source backup solutions which track incremental backups using a database, and which do not use hard link directories. Someone gave me a suggested OSS backup program at UDS, but it s slipped my memory; so I m fairly sure that at least one or more such OSS backup solutions exist, but don t know their names. Can some folks give me some suggestions? Thanks!

There are a number of very popular Open Source backup solutions that use a very clever hack of using hard link trees to maintain incremental backups. The advantage of such schemes is that they are very easy to code up, and it allows you to easily browse incremental backups by simply using cd and ls . The disadvantage of such schemes is that it creates very large number of directories blocks which must be validated by an fsck operation. As I ve discussed previously, this causes e2fsck to consume a vast amount of memory; sometimes more than can be supported by 32-bit systems. Another problem which has recently been brought home to me, is how much time it can take to fsck such file systems. This shouldn t have come as a surprise. Replicating the directory hierarchy for each incremental backup is perhaps the most inefficient way you could come up with for storing information for an incremental backup. The filenames are replicated in each directory hierarchy, and even if an entire subtree hasn t changed, the directories associated with that subtree must be replicated for each snapshot. As a result, each incremental snapshot results in a large number of additional directory blocks which must be tracked by the filesystem and checked by fsck. For example, in one very extreme case, a user reported to me that their backup filesystem contained 88 million inodes, of which 77 million of them were directories. Even if we assume that every directory was only a single block long, that still means that during e2fsck s pass 2 processing, 77 million times 4k, or 308 gigabytes, worth of directory blocks must be read into memory by e2fsck s pass 2. Worse yet, these 308 GB of directory blocks are scattered all across the filesystem, which means the time to simply read all of the directory blocks so they can be validated will take a very, very, long time indeed. The real right way to do implement tracking incremental backups is to use a database, since it can much more efficiently store and organize the information of what file is located where, for each incremental snapshot. If the user wants to browse an incremental snapshot via cd and ls , this could be done via a synthetic FUSE filesysem. There s a reason why all of the industrial-strength, enterprise-class backup systems use real databases; it s the same reason why enterprise class databases use their own data files, and not try to store relational tables in a filesystem, even if the filesystem supports b-tree directories and efficient storage of small files. Purpose written-and-opimzied solutions can be far more efficient than general purpose tools. So, can anyone recommend OSS backup solutions which track incremental backups using some kind of database? It doesn t really matter whether it s MySQL, Postgresql, SQLite, so long as it s not using/abusing a file systems hard links to create directory trees for each snapshot. For bonus points, there would be a way to browse a particular incremental snapshot via a FUSE interface. What suggestions can you give me, so I can pass it on to ext3/4 users who are running into problems with backup solutions such as Amanda, Backup-PC, dirvish, etc.? Update: A feature which a number of these hard-link tools do right is that they do de-duplication; that is, they will create hard links between multiple files that have the same contents, even if they are located in different directories with different names (or they have been renamed or their directory structure reorganized since they were originally backed up) and even if the two files are from different clients. This basically means the database needs to include a checksum of the file, and a way to look up to see if the contents of that file have already been backed up, perhaps with a different name. Unfortunately, it looks like many of the tape-based tools, such as Bacula, assume that tape is cheap, so they don t have these sorts of de-duplication features. Does anyone know of non-hard-link backup tools that do de-dup and which are also Open Source?

There's a lot of folklore in the Debian community about how apt works. Unfortunately, a lot of it is also just plain wrong. For instance, I often hear people confidently say things like aptitude is a frontend to apt-get (it isn't). These misconceptions are understandable -- all the programs that use apt perform the same tasks, many of them imitate each other's interfaces, and they all share common code. It's easy to assume that they must all be invoking apt-get under the hood. In the interest of clearing up some of this confusion, I've created some simple diagrams of what uses what in the apt system. apt is large and complicated, so these diagrams can't be complete, but I hope they at least clear up the basic relationships between the different pieces of software. This diagram shows how apt, dpkg, and some popular frontends are related to one another (also available as a pdf). In order to keep things simple, the above diagram is limited to a very cursory description of how the system components are bound together. The other diagram I've built shows a few more technical details about the structure of libraries, programs that invoke one another, etc (also available as a pdf). In order to make these diagrams manageable, I had to throw out a great deal of information. If you have a question that these don't answer and if I have time, I'd be happy to take a stab at diagramming some other aspects of apt. [EDIT]: I've updated the diagram in response to a request to indicate where packagekit will reside, when and if it is completed. My understanding is that they are basically writing yet another apt frontend, but there's an intermediate library that translates to some least-common-denominator API so the frontend can be identical on all package systems.

Lessons learned: using the phrase third, final, and slightly desperate is an excellent way to motivate people into reacting to your Call for Talks. I've even had to reject some people now, unfortunately. Maybe next year, I'll use that phrase in my first call for talks. Then again, maybe not. Anyway, of course that does mean that there are no slots available anymore. If you wanted to hold a talk in the Debian devroom, you've had plenty of opportunity and will now have to wait until next year. There are still some minor loose ends that need to be filled in (of course there are always people who will wait until the very last moment to send mails they need to send... including me), but once that's done, I'll announce the schedule on the -events-eu mailinglist, and probably here too. And if you're worried that the word 'desperate' perhaps got us some boring talks in the end, don't be; the talks that are on the schedule are, I hope, all very interesting. Watch this space! So, things left to do, in no particular order:

• Do a schedule for talk announcers. There's enough volunteers now, I only need to assign slots.
• Come up with something cool for the booth. There's going to be T-shirts, as always, but more things are always welcome.
• Booth volunteers. Since I haven't been at the booth much during these past few FOSDEMs, and since two years ago it turned out that my 'great idea' about organising that wasn't such a great idea after all, I did the right thing and decided to delegate organising the volunteers to someone else. That someone else is Nattie; so if you want to help out at the booth, be sure to contact her.

That's it for now, I guess. Back to your regularly-scheduled flamewar.

I have never felt inclined to create content for Youtube due to the low resolution of the display and the fact that only one format is supported (Flash which is totally non-free). The existence of blip.tv has inspired my interest in creating videos for distribution on the net. blip.tv has higher resolution than Youtube and supports multiple formats. Currently the multiple format support is limited to allowing users to upload whatever they want and then Flash (FLV) will be provided for download in addition to the original file(s). So for example I could upload MPEG4 and Quicktime movie files for the same content which would result in three download options (MPG, MOV, and FLV). It would be nice if they could support more formats as the default (maybe support transcoding to OGG), but it s certainly a lot better than Youtube. So the question then is how to create content. One option that I plan to use is Istanbul - the GNOME desktop session recorder [1]. It will record everything that happens on the desktop (or a section of the desktop) to an OGG file while also optionally recording audio input. This allows the creation of tutorials for performing various tasks on the computer. Another option is to do animation, either completely computer generated or by combining a set of JPEG files into an animation file. This doesn t interest me to the degree necessary to make me invest the necessary time. But the most common way of producing video content is via a camera. So the question becomes what camera to get. My current camera is a Sony Cyber-shot DSC-T5 [2]. It is a 5.1 mega-pixel camera with 3* optical zoom and supports 640*480 resolution movies at up to 30 fps. The quality of photos and video that it produces seems to be quite good, I don t have any particular problem with the camera that I want to address by purchasing a new one, so a major aim of buying a new camera was the fact that it s a few years old and something better must be available at a low price! I asked for advice about this on my local LUG mailing list. One piece of advice that was offered by several people was to use a Digital Video camera with Firewire output to record quality video. They spoke about common digital cameras as point and shoot with the acronym P&S - which seems to be used as a term of abuse by people who are really into cameras. If using a DV camera with Firewire support (which is apparently a really important feature) then apparently Kino [4] is the program to use to capture the raw video data. While the advice in regard to a digital video camera sounds good I m not going to take it. Such DV cameras start at about $300 and appear to be physically larger. While a larger camera (with a larger lens) will give better quality pictures and higher frame rates with lower levels of ambient light I am planning to do my serious video recording in a controlled environment with reasonable lighting. Really I m not THAT serious about video recording, so I don t plan to spend $300 or more - I ll accept the lower quality as a trade-off for lower price and greater convenience. I have seen an advert for a camera described as a DC-777 at a good price from DirectBuy.com.au [3]. The camera in question is one that has no reviews anywhere on the net and seems to be a re-badged version of someone else s camera. It initially sounded quite good with 11mega-pixel resolution, but the fine print shows that it has a 7MP CCD and uses interpolation to get a higher resolution. Also the movie capability is 640*480 at 30fps (the same as my Sony). So the benefit of using the DC-777 would be the rotating display which can face the same direction as the lens thus allowing someone who is making a video of themself to see what they are creating. This doesn t seem to be $200 worth of benefit, but the camera might be a reasonable deal for someone who doesn t already have a decent P&S digital camera. Another interesting piece of advice I received from my local LUG was that the amount of time taken to get a good image (which determines the shutter speed on a good camera or the maximum frame rate for video) is determined in part by the size of the elements in the CCD. So with all other things being equal a camera that supports higher resolution will require longer exposure. For my use the benefit of higher resolution photos is often for the purpose of cropping pictures of objects that were too far away to allow completely zooming in. 3* optical zoom (as implemented in my current camera) is a limit when photographing objects that are far away in good light conditions (in poor light it s often a factor of the lens size). In the past when looking at digital cameras I would make the resolution of the picture the prime criteria - with the idea that bigger is better. But now it seems that the smart thing to do is to make optical zoom the prime criteria for general purpose camera use. Also having a larger lens is a significant benefit, but as the overall volume of the camera is going to be roughly proportional to the radius of the lens cubed it can t get that big without some serious compromises on portability. Obviously an SLR [5] offers significant quality benefits. But if you are unwilling to spend so much money a good result can be obtained by what are sometimes called Big Zoom Digital cameras. These are cameras with a body shape that resembles a SLR, they vary in size between the P&S cameras and SLRs, and have fixed lenses that are significantly larger than those of P&S cameras. I gave such a camera to a relative for Christmas and I was very impressed by the quality of pictures and movies that it produced. I chose a Kodak camera with 12* optical zoom which was quite impressive (unfortunately the 15* model had sold out). One of the benefits of a Big Zoom Digital camera over a DSLR is that as there is no option to replace the lens there is also no possibility to get dust inside the camera (which is apparently a problem with SLR cameras). For my own use I plan to stick with my Sony Cybershot. I can t get anything significantly better for an amount of money that I am prepared to spend, and I also don t really want a larger camera. So I think I ll buy a tripod (or maybe two tripods of different sizes), that should deliver a real benefit for my photography without costing much. Update: One thing I forgot to mention is the film speed rating (AKA the ISO number) [6]. A higher ISO number means that the camera can take faster pictures in less light. The Wikipedia page reports that camera manufacturers are permitted to interpret the ISO scheme in several different ways, so they can essentially just make stuff up. Probably the best that can be said for the ISO number is that any camera which advertises it is aimed at more serious users and is therefore likely to be of higher quality. I m sure that if I was to spend $700 or more then I would get a camera with an advertised ISO number that actually means something, but I don t have any plans to ever do that. Matt made a good comment that the quality of the glass matters. For an SLR you can consider the lens quality independently of the quality of the rest of the camera. But for cheap cameras it s just a matter of the entire package.

• [1] http://live.gnome.org/Istanbul


• [2] http://www.dcresource.com/reviews/sony/dsc_t5-review/


• [3] http://www.directbuy.com.au/moreinfo.php?txt_itemcode=DC-777&txt_searchstring=DC-777&txt_from=3&catcode=45


• [4] http://www.kinodv.org/


• [5] http://en.wikipedia.org/wiki/Single-lens_reflex_camera


• [6] http://en.wikipedia.org/wiki/Film_speed

Okay, so I had a simple job to be done. I have two mail accounts: A private mail account and a company mail account, which has two folders containing private mails. I want to synchronize these folders to my private account. Which is the right tool to choose? I thought that one way would be to fire up a graphical mail user agent, like lets say Thunderbird, setup the accounts and simply move the mails between them. But this has some implications, like:

• I don't use such a MUA (instead I use mutt), which makes it unneccessary hard, because I really need to setup the accounts
• Most graphical MUAs I know are bad at working with a great number of mails. At least Thunderbird does not even properly show what he is doing and how long he is supposed to doing it

So I decided that I needed some small tool, that UN*X admins are used to have. After a small apt-cache search, I found two tools:

• imapcopy
• imapsync

I installed both and looked at them. For the impatient, a spoiler: I decided to use imapsync.
I had a quick look at imapcopy and it did not have a proper manpage.
Instead it refers to the built-in help (imapcopy -h) which is not useful either and to examples in /usr/share/doc.
After that I had look at imapsync. It comes with a pretty good manpage and a pretty good built-in usage information. Appearently I rate it very important that either the manpage or the built-in help are good enough to get started with a tool. Certainly I know that tools exist where a manpage is simply not enough, but I guess a tool to sync imap folders is not one of them.

After studying the manpage for about 2 minutes I was ready to construct a command line and give it a --dry try. This parameter lets me see what the tool would do if I would ommit it. That one looked good and so I gave it a shot. It then started to work. It has two flaws.

1. Unfortunately it does not indicate its progress and the normal messages are not a good help either, because they contain numbers that actually do not refer to mails in one of the mailboxes (they are soon literally higher as the number of mails in both mailboxes) and I do understand what it is referring to.
   
2. It sometimes crashed at random locations with random messages. I didn't look deeper into it, because restarting the script helped and therefore I cannot speak of a easy reproducible problem. In 3000 mails it happened about 1-2 times, so not a great deal but still annoying.

Anyway, it did the job, which took some time, because of my bandwith.

Sarah came up a great idea for us to do over the long, long weekend after New Years. She wanted to go to the Grand Canyon, and hike in it. I, also enjoying hiking trips, went along.

We organized the trip rather late, I think on the 27th of Dec from my parents house (I think my mom enjoys being around for trip planning since it reminds her of the trips she should plan). Given our late planning we could only get a reservation at Phantom Ranch for the night of the 1st. So the trip plan was get back to SF on 30 Dec 2008. Take bart from the airport, sleep/pack (in either order), then drive to Williams, AZ on the 31st. Take a bus the to Grand Canyon on the 1st, hike down to Phantom Ranch, sleep, hike back up to the top, see the Grand Canyon from the top. Take a bus back to Williams and drive somewhere near the Hoover Dam. Sleep. Drive, see the Hoover Dam, get to Las Vegas, and see the Cirque du Soleil show Ka. Sleep. Drive home.

So that was the plan, now for the execution. We got back to SF on time and picked up our bags from the baggage claim without any issue. The next morning we got up and moving. The optimistic hope was that we would be on the road by 8am to Williams, then stop in Fresno for gear and food. It turns out we weren't ready to go until 10, so we got hiking poles and fake crampons at the REI in SF. We also did our grocery shopping in SF. We were on the road to Williams by noon. We shared the driving Sarah took the parts with traffic, I took the 4 and two lane highways. The fortunate part about this is that I drove through the San Joaquin. One the way there, it was basically IFR conditions (I had no instruments), so I was driving through a cloud (some call it fog) and I couldn't see anything that wasn't on the road. It was really pretty but not the best for a road with lots of ups, downs and turns. I felt like a race car driver. The other interesting part (at least while I was driving) was going through the Mojave desert at sundown. I don't think Sarah has any pictures, but it was very pretty.

Finally we arrived in Williams, AZ and got to the Grand Canyon Railway Hotel, at 2345hrs, (for those counting that means we were on the road for 10h 45m). We checked in by 2358hrs on 31 Dec 2008. So we stood by the fire for two minutes, counted down, and kissed for New Years.

In the morning, things went as expected, we backed our bags to hike 10 miles, and put the rest of the stuff in the car. We got in a van that took us to the Grand Canyon. Our driver up to the Grand Canyon was very nice and showed us the sites along the way. We also met two Japanese exchange students on their way to see the Grand Canyon.

On the way was slow since we took a lot of pictures (Sarah has them all since I lots my 1GB SD card before it made its way into my camera). Unfortunatly, Sarah got tired on the way down, and also hurt her ankle. So we stumbled our way to Phantom Ranch around 1600. From the time we got to the ranch until supper at 1830, we laid back and relaxed, we needed it, our feed were sore and Sarah iced her ankle. The food at Phantom Ranch was good, not great, and there was enough of it after being on our feet all day. At end end of the day, we slept, as planned. In the morning we got up for the early breakfast. Again, it was decently, but not great, but there was enough food. Unfortunatly, Sarah was sick (She'd figured out how to deal with her ankle though) (Oh, and she isn't pregnant). So we harrassed the rangers, got some imodium, and started on our way back up the Bright Angel Trail, we took the Bright Angel Trail down and were planning on the South Kaibab trail up but the Bright Angel Trail has places to stop the South kaibab trail doesn't. Again were were planning on an early 630hrs start, but started a little later at 745hrs. We used our poles with gusto on the way back up and made it up by 1345, 6hrs on the way back up, the same time it took us to get down. The rest of the daylight hours was spent taking the village bus around the Grand Canyon village and seeing the sights from the top.

After the Grand Canyon, we drove to Kingman, stayed there, then continued on, saw the Hoover Dam, it is like Itaipu, but less political and taller, then went on to vegas. In Vegas we saw the inside of a couple hotels, I spent $1 on a slot machine, then we say Ka. Ka is an amazing show, I don't think it really suck in until after the show was over all the things the performers pulled off. That said, the stage itself was an engineering marvel that I watched almost as much as the performers.

After Vegas, the drive back was mostly uneventful, the fog in San Joaquin was a little lighter, but still heavy, Mojave is prettier at sunset and it is still good to sleep in my own bed.

Yesterday evening I received a quite nice mail - the people behind Linux New Media and the LNM Award asked me if I want to participate in the Jury for the 2009 edition of it. Sure I want. :) The process seems to be a very simple one (good), the Jury members make nominations for the various categories and then later on vote on them. Now, while I already thought about it and know candidates I will nominate, what about you? I list the categories for this years edition below. Do you think something/someone/whatever should be nominated in those categories? Why? Note that only products/projects/people/organizations/whatever that have been very significant in 2008 should be nominated. This editions categories are - Outstanding Contribution to Open Source / Linux / Free Software

• Most Linux / Open Source-Friendly Hardware Vendor
• Most Innovative Open Source Project
• Best Open Source Contribution for Mobile Devices
• Best Open Source Programming Language
• Most Significant Contribution for Security in Open Source

If you want, feel free to tell me what you think should go in those categories. Leave a comment here or send me email. If you also add a little reasoning why, even better.

Today I got my Acer One AOA150, is a really nice device, Unfortunately this model did not come with GNU/Linux, so I sadly have to still pay the microsoft tax But the good point is that the Debian installation was a breeze, really simple, almost all hardware just works out of the box, BTW thanks to the guys who wrote http://wiki.debian.org/DebianAcerOne my goal is to get used to this laptop and made it my main work laptop, I ve always be a big fan of smalls laptops so this is a kind of a really nice device for me I guess. I also always note that a lot of people complain about the small keyboards on the mini-laptops , but I did not find such a pain, there is still a need to get used to it, but with a couple of hours using it, seeings comfortable enough for me.

I'm going to re-do my blog sometime soon.The host my current blog is running on is going to retire "anytime soonish" (I happen to be responsible for that, so I will know when). So I will need to move my blog someplace else (I want to merge it into my regular web page, too). Right now, it's based on an ancient version of Pyblosxom with a couple of custom hacks, and is pretty much unmaintainable.So I'm also looking for an appropriate blog software, but I'm not yet sure about my requirements, so I don't have a clear software favorite yet. I don't need a browser based editor, and I'm not interested in interactive features such as comments or trackbacks.Mnemosyne is one of my favourites, because it's a rather low-level, bare-bones approach. Its templating is XML-based (KID) and it's Python.Ikiwiki actually calls itself a "wiki compiler", but I know that some people use it for their blogs. It also does valid XHTML, although its templating isn't designed for XML safety.Features that I would like to have:

• XHTML output, ensuring valid XML, and appropriate templating
• File-based data storage, no MySQL
• Python preferred, but pretty much 'Anything but PHP'
• Static rendering / caching
• Tag based organization
• Search engine optimization (static pages, sensible URIs)
• Atom and RSS 2.0 output, ensuring valid XML

I guess I'll just end up writing a blog software for myself. The current text files are an odd mixture of HTML and plain text anyway, so I'll need to write an importer for the old data myself anyway (plus then I can also do some URI mapping to redirect old links). My current web pages are generated via an XSLT transformation, so I maybe just re-use that for templating.The thing which probably gives the largest issues is pagination of list views. (Especially when you want the pagination to be stable even when new entries are added while a user is browsing the pages, which is nice to have because of search engines and links). I don't think a fully static rendering will work here.[Update: Sean pointed out that by using title-only in archive pages I can avoid having to paginate. Thanks! I also received TONS of software recommendations. Ranging from PHP over bash (URGH, I want valid XHTML) to mod_lisp based (no special Apache modules, please. Should run everywhere.)]