I've uploaded liblwp-authen-oauth-perl to Debian today, [UPDATE: currently the package is waiting in NEW (please note, that the previous link might not work, in case the package has entered the archive already or the page hasn't been generated yet). and is now in the archive. Thanks a lot to the FTP Masters for the quick processing!] LWP::Authen::OAuth allows to easily integrate OAuth authentication into Perl programs and libraries. Some of you might already guess, why I have an interest in OAuth for Perl: as a user (and maintainer) of Chronicle I'd find it neat, if there could be some Flattr integration (especially a automatic submission of new posts to Flattr). This sent me searching for an Perl implementation of the Flattr API. Unfortunately this turned up nothing, therefore I'm now planning to write some sort of Net::Flattr Perl module, which I can then use in Chronicle for one task or another. Net::Flattr (preliminary name, but probably the final one, as the implementation of the Twitter API is called Net::Twitter) is going to be a library, which should offer the same functionality as Flattr's PHP library. For now there are some scetches to this extent on my hard drive, but nothing showable. I hope I find the time soon to write this but it shouldn't be too difficult. ;-) Apart from my particular use case, you can use LWP::Authen::OAuth for any other OAuth-requiring API. I hope the package helps you to build more cool tools for and on your Debian system!

This is just a diary of a random day sort of post. Nothing all that particularly unusual, but then perhaps if I only blog about the unusual, the typical gets lost. This week started out with temperatures as high at 99F. Today we didn t even reach 60, and tonight will be cold almost to freezing. It s Kansas, so while we remark on the strange weather, we re not particularly surprised by it. This morning, Jacob and Oliver went over to play across the street. Jacob then went with Terah to a birthday party for one of his classmates, while Oliver helped plant some trees with his grandparents. I was at home this morning, which gave me a small but welcome break from the past week: we had something going on 6 out of the last 7 evenings, and little time to do anything else. So I got out the Kindle and read from War and Peace. I started at the kitchen table while eating some granola, and then sat on the couch. The day was cold, windy, and overcast, and I like to use natural light, so there were only a few places to sit with enough light. I sat there reading the account of Napoleon s capture of Moscow in 1812, the characters lives uprooted by those events, and stories of violent mobs forming. And, of course, Tolstoy s essays on the mistake of overstating the importance of famous figures in history were common. I am now about 3/4 through War and Peace, which means I ve read 1,044 pages and have (only) 348 to go. As I got up to try to find slippers or a blanket for my cold feet at one point, I remembered a conversation I had while eating lunch this week. I was reading on the Kindle while reading, and a person I knew happened to walk past. She asked what I was reading. I said simply, War and Peace. There was this stunned silence, so I added, for fun. It s great! Which is true. She said, Oooookay, John, you just enjoy that then and went on her way. This isn t the first time I ve had a conversation like that about this book. It seems to be held up as some example of long, dry, literature that people are made to read but don t want to. I think that only long is accurate here. Anyhow, pretty soon Oliver arrived and, much to my surprise, said Doh! (meaning no ) when I asked him if he was ready for lunch. Instead he stood there looking at me sweetly. Taking a guess, I said, Oliver, would you like to watch train videos? Yeah yeah yeah yeah! So we did. He particularly enjoyed the steam engines today, and eventually was ready for lunch at 12:30. Jacob and Terah got home just as he was finishing. Oliver got his nap, and I played with Jacob for a bit. Ever since he had heard of the British wedding in preschool, he s been interested in weddings, so I showed him pictures from Terah and me at our wedding. This was a big hit. Then he went with Terah to decorate a Sunday School room at church, so I read a bit more Tolstoy. Tolstoy s characters sometimes are prone to not just changes in mood but changes in outlook and worldview changing from cold, logical, and uncaring to warm and loving, or from despair at the vanity and shallowness of humanity to elation at the simple honesty of a peasant and renewed trust in the human spirit. At first I marveled at this tendency in certain characters, but on reflection, and in consideration of the timeline of the novel, which spans several years, it didn t seem quite so strange. Things can happen to change the mood of individuals, or even a country; I can remember the national mood changing after 9/11, and again after Obama s election, for instance. I also felt a contrast with some of the characters who, due to their decisions or circumstances, lost things that mattered while chasing things that weren t as important. I felt fortunate to be at this place, with Jacob, Oliver, and Terah, and decided that we all ought to do something fun in the evening, but hadn t quite figured out what. And about that, the clouds started to break and Oliver woke up from his nap. I went up to his room, and much to his delight, played peekaboo with him for quite awhile. Eventually he was done with that game, but spotted my phone, so I helped guide his finger to launch Youtube and watch a train video over the wifi. This was certainly a Big Deal to him. After Terah and Jacob got back, I figured it was time figure out something fun to do. And what could be more fun, I decided on the spur of the moment, than a drive into town to pick up some cans of Silly String for the boys, neither of which had ever used it before. So we went to a restaurant, then bought the surprise toy (I hadn t told them what it would be beforehand), then went to an ice cream place, and finally back home. Oliver loved it. He needed my help to press the nozzle to make it come out, but still had a great time and shrieked with delight. Jacob then tried out his can, and stood in one place spraying his bright green strings all over the place. Then he took to running around the yard spraying string randomly in every direction until he finally completely emptied out the can. And after that, he gathered up some of the different colors of string and rolled them up into a ball which he was very proud of. A nice day.

So Blogger had a hiccough, and I've seen people in blogs I read being confused about why their posts and comments to posts seemed to vanish. I wish that people had more autonomy over their data and didn't just feel it could vanish like that when someone messes up. Giving nontechnical people that autonomy is hard, things have to be made quite simple, and they have to be educated to want it. Liw and I are trying to take preservation of user data beyond backups at Branchable. Coincidentially[1], while Blogger was down I was working on automating_git_pushes_from_Branchable. So every change made to a site is committed to git and pushed right offsite to GitHub or Gitorious, or a personal server. The only hard part of this for the user is the ssh key distribution, which is currently a cut and paste affair. Monkeysphere, I've got my eye on you.. By the way, I was stunned to see that GitHub does not support automatic git pushes out of GitHub. Although it can notify a million CIA-type services, the actual data is thus very subtly encouraged to be siloed. This feature seems to have been requested since at least 2009. Can't be that hard can it? (I didn't see a way to make Gitorious do it either.)

---

[1] Actually, this was the last feature I needed to move Ikiwiki's own wiki over to Branchable, so I plan to do that soon and retire its current server.

There is actually some buzz around Gnome 3 and the new release of Ubuntu switching to Unity. I thought this was a good occasion to make this small post to tell that I still uses FVWM whose latest version was released a month ago. FVWM is a very old window manager. So old that nobody really knows what the F stands for. It comes with a ugly configuration by default and can be configured to look even uglier. However, FVWM is powerful and highly configurable. Moreover, it is pretty lightweight.

My FVWM configuration My configuration of FVWM is available on GitHub. It requires the use of fvwm-crystal. If you are running Debian or Ubuntu, there is a package for this. This is a set of powerful configuration files for FVWM which add a lot of goodies and themes. Unfortunately, the project site seems to have disappared. You can still grab the sources from your nearest Debian mirror. While those configuration files were great, I did not like to have such a complex desktop with all those icons and menus. However, what is great with fvwm-crystal is you can overlay your own configuration. If a file is present in your home directory, it will take precedence over the one installed on the system. So, I just wrote a new recipe. What you may want to steal from my configuration is the ability to alter the configuration depending on the fact that you are using one or two screens. With one screen, you get:

• an application panel (a launcher bar) on the upper left corner,
• an icon manager (which will contained iconified windows) on the upper right corner,
• a systray on the left of the icon manager
• a pager (which shows various desktops) just below it,
• two icon managers (which act as a taskbar) on the bottom, one for regular applications and the other one for terminal windows.

With two screens, the organization is different. The two icon managers at the bottom are on their own screens. The pager is between the two screens and the other elements are on the upper left of the right screen. If I am using a single screen and I plug another one, I do something like this to get my setup updated:

1 2	$ xrandr --output VGA-1 --auto --output DVI-I-1 --auto --right-of VGA-1 $ killall trayer ; FvwmCommand Restart

I also uses conky, a light-weight system monitor. It is started in my .xsession, not through FVWM.

Building wallpapers for dual-screen One difficulty with a multi-head setup is how to get the background set properly? . I have made a small script for generating one. Use it like this:

1	$ ./build-wallpaper.py -d ~/.fvwm/wallpapers -c -t ~/tmp/mywallpaper.png

It will randomly select two wallpapers and put them together to look nice on your dual-screen setup. It will also correct the aspect ratio, either by cropping the image or centering the image. You need the following dependencies to make script work: python-xpyb and python-imaging. UPDATE: Thomas Adam pointed to Nitrogen, a graphical wallpaper utility supporting multi-head setups. It is a great tool if you want to set manually your wallpaper but it does not allow to select a random one. Nowadays, I grab most of my wallpapers from InterfaceLIFT.

You know, GNOME Shell and I are not really strangers to each other for a long time now. I have been using it almost daily as my main desktop since late 2009, when I started shipping it to Debian experimental. That means that I had ample opportunity to both get used to it and witness the huge improvements it had with every new release. My general feeling towards GNOME 3 is this: . Yes, I love it! I love the new themes, I love the window borders, I love the top panel, the overview, the dynamic workspaces, I love the Me menu, I love the clock and the calendar, the system indicators with the beautiful symbolic icons, being able to search for applications in such a nice way, the window animations, the multi-screen support, the new nautilus, the dash, looking glass. It s hard for me to even express how thankful I am and how much admiration I have for the awesome folks who helped bring this to life. Thanks so much! After all this time, there are only two things I can say I dislike about GNOME3, apart from some minor wishlists: the alt-tab behaviour and the message tray. Let me expand on those. Message Tray Of the very few things I dislike, there is only 1 I hate and cannot see myself living with: the accordion animation in the message tray. No, really, it s such a terrible, terrible idea. Every single time I try to use that thing I overshoot while moving the mouse to the left, then overshoot again moving the mouse to the right because the frigging icon has moved. It s no good knowing that I can click in the text or in the empty area to its right, it feels wrong. It s terrible that my actual target is moving at all. Every single time I use it is a small frustration for me it s as if the message tray was playing games with me, laughing at me for not having good enough mouse pointer driving skills even more than the infamous sub-menus used to. And I had to go through that penance whenever I wanted to find the person I was chating with to resume the conversation. I wrote an extension that disables the accordion animation by simply not showing the title at all when you hover the icon, and I patched GNOME Shell s CSS to make the icons a bit bigger, so that it s easier for me to hit them with the mouse. It s clearly not ideal, and you still have to click the various people icons to figure out which of your friends who were lazy enough to not add a picture to their IM profiles is that one, but it s still much better than chasing the (smaller) ones around to figure that out. Perhaps we should have the icons be bigger and always have the title bellow them? I don t know, I trust the awesome designers who designed the awesomess that s everywhere else will come up with a great idea. Alt Tab The number 1 feature of workspaces for me has always been locality being able to not see all of the other applications and windows that are open elsewhere. This lowers the amount of noise when I m trying to find something. The overview is very nice in this matter only windows in the current workspace are shown, and even when you have an extra screen, the windows in there appear in that screen. The alt-tab behaviour, on the other hand, of showing all windows and apps, even with the separator, bothers me. It s really useful to have when you want to go to a specific window no matter where it is (I usually use the dash for that, though), but it adds noise when you want to go to a specific window _in this_ workspace, which is the most common use case for my usage. So I copied the alt-tab code over to an extension and modified it so that only windows in the current workspace would be considered. In addition to that, with the windows in the extra screen always being there no matter what workspace you re in (which I think is an awesome idea), they are effectively in all workspaces, so they add constant noise even with my extension. It s also weird to have to look at the main screen to switch to a window in the extra screen. There s a huge discontinuity. What I would prefer is having alt-tab to follow the mouse regarding screens only show windows in the extra screen if you hit alt-tab in there, making sure the selector thing appears in there as well.

Just a short announcement for the impatient: Wine 1.3.20 packages are available. As of this writing it's only the source package, the binaries follow as soon as they're built. As a small side note: this is, as far as I can remember, my quickest upload of a Wine version (only about 15 minutes after the release was tagged upstream).

While swearing at my bank's automated phone attention system, I was thinking that taking advantage in the fact they already usually say that "the call will be recorded to improve service quality" call center operators/programmers should record all user activity and, just for laughs, play back the grumbles angry users shout at the system. Of course, at random intervals, on loudspeakers, over the crowded call centers. Oh, they do it already?

I got recruited into the movie business via Soile, and the teaser for the movie is now out: http://www.edinburghdigest.com/. I did two evenings as a "Digital Imaging Technician", as you can see from the credits. In other words, I copied files from camera memory cards to hard disks with a laptop. While everyone else were out in the cold, I sat in a pub. Soile is in the credits too. She actually did moviestuff, I just did computer geek stuff.

This new release features /run usage and xz support. For the details see the release announcement of latest initramfs-tools. The upload itself fixes 18 (19) bugs in the Debian BTS and has also a cute lilo support patch hiding under "initramfs-tools: Fix handling of numeric root= arguments to be udev-friendly" coming from Ubuntu. (; Ben Hutchings revamped the bootloader linux-2.6 hooks in order that update-initramfs no longer calls any bootloader by itself. Thank you for all the contributions. The development docs got nicely refreshed too.

From the java point of view Recently I had to get some Scala Tool working correctly. Unfortunately there are basically no packages in the Debian Archive at all so I had to use maven to install these (or download + install manually). Being a highly paranoid person downloading and executing code from the internet without any cryptographic verification at all one after the other practically drove me nuts. Looking a bit deeper I noticed that some of the software in maven's repository have some signatures next to them -- signed by the author or release manager of this specific project. Why secure sources matters With my experience in mind I got some Input from other people. One of the things I was told is that some scala tools just aren't security critical -- they're only installed and used as the current user. In my opinion this is, for my desktop system, totally wrong. The important things on my private Computers are my GPG and SSH keys as well as my private data. For messing with these no super user access is needed at all. Comparing to the Common Lisp situation Being a Common Lisp fan of course I noticed basically the same problem for installing Common Lisp libraries. Here the situation in Debian is quite a bit better -- and I'm working in the pkg-common-lisp Team to improve this even more. Common Lisp has some maven-alike tool for downloading and installing dependency trees called quicklisp -- without any cryptographic verification as well. However there's light at the end of this tunnel: There are plans to add GPG verification of the package lists really soon. Comparing the maven and the quicklisp model So there are basically two different approaches to be seen here. In maven the software author confirms with his signature the integrity of his software while in quicklisp the distributor confirms all users get the same software that he downloaded. Now the quicklisp author can't and won't check all the software that is downloadable using quicklisp. This won't be doable anyway as there's way to much software or a single person to check. Now in some kind of perfect World the maven way would be vastly superior as there's a End-To-End verification and verification of the full way the software takes. However there's a big problem: I don't know any of these Authors personally and there's no reason I should just trust any of them. Now comparing this to the Distribution / quicklisp model. Here I would just have to trust one person or group -- here the quicklisp team -- to benefit from the crypto which might be possible based on karma inside the using community. However here I don't gain the possibility that the software is integer. However idealized if some of these pieces of software was forged between upstream and the quicklisp team and attacker would also intercept me downloading the software from the same address so I get the source from upstream matching the checksum from quicklisp -- assuming the quicklisp team does indeed know the correct website. Additionally I get the confirmation that all other quicklisp users get the same source (if the quicklisp guys are fine of course) so no-one inside the community complaining is a good indication the software is fine. For this to work there's of course a relevant user-base of the distributor (quicklisp) necessary. Relevance for Debian So how do conventional Linux Distributions like Debian fit in here. Ideally we would have maintainers understanding and checking the software and confirming the integrity using their private key or at least know their upstreams and having at least a secured way getting the software from upstream and a trust relationship with them. Of course that's just illusionary thinking of complex and important software (think libreoffice, gcc or firefox for example). Maintainers won't fully understand a lot simpler pieces of software. And loads of upstream projects don't provide a verified way of getting the correct source code though that's a bit better on the real high-impact projects where checksums signed by the Release Manager are more common than in small projects. A misguided thought at the end As I'm a heavy emacs user I like to have snapshots from current emacs development available. Fortunately binary packages with this are available from a Debian guy I tend to trust who is also involved upstream so adding the key from his repository to the keyring apt trusts. Now my first thoughts were along the lines "It would be really nice if I could pin that key to only the emacs snapshot packages" so this guy can't just put libc packages in his repository and my apt would trust them. Now thinking of it again a bogus upload of the emacs snapshot package could just as well put some binary or library on the system at some place in front of the real on in the system path which would be rather similar bad. b

Some months ago I wished for a tool to create virtual disk images, something similar to debootstrap except it would create a disk image instead of a directory. It would be used like this:

sudo ./vmdebootstrap --image test.img --size 1G \
--log test.log --mirror http://mirror.lan/debian/

debootstrap is wonderful for creating a basic Debian system for use with chroot. In the modern world, something similar but for virtual machines (such as KVM) would be nice to have, I thought. Particularly if it is something that is not tied to a particular virtualization technology, and does not require running in an actual virtual machine (for speed and simplicity). I could imagine using a tool like this for automatically building appliance-like system images, for example for FreedomBox. Being able to do that in a fully automatic manner would make development simpler and more easy for others to reproduce, and would allow for things like automatic integration testing: build image, boot it in a virtual machine, run automatic tests, report results. There are a bunch of tools that almost do this, but not quite. For example, live-build builds a disk image, but it's one that is aimed for live CDs and such. This brings in some limitations. By default, the image is not persistent. You can make a persistent image, but that requires you to provide a second partition (or disk) that holds the modified parts, using copy-on-write. It also means that if the bootloader or initramfs needs to be updated, then the read-only image needs to be updated. That's fine for live CDs, but not so good if you want a real installed system that you can upgrade to all future releases of Debian. (Ben Armstrong kindly helped me use live-build the right way. Thanks!) There's also grml-debootstrap which seems to work on a real system, but not installing onto a virtual disk image (and the difference is crucial to me). Based on feedback I received back then, and some experimentation I've done the past couple of days, I wrote a very rudimentary version of the tool I want. The code is on gitorius. (You need my cliapp library to run it.) Be warned: it really is a very rudimentary version. For example, it provides not flexibility in choice of partitioning, filesystem type, what packages get installed, etc. It does not configure networking, and the root password is disabled. Some of that flexibility would be quite easy to add. It also uses extlinux as the bootloader, since I utterly failed to get grub2 to install onto the virtual disk. (I did, however, manage to overwrite my develpment machine's bootloader.) The command above works, and results in a RAW format disk image that boots under KVM. It might boot off a hard disk or USB flashdrive too, but I haven't tried that. I now have several questions:

• Does something like this already exist?
• Does anyone else find this useful?
• Is another approach better? Perhaps running a fully preseeded debian-installer in a virtual machine might be better.
• If no other tool exists for the same job, what should I do next with vmdebootstrap?

After a bit of work, today I decided to start using mpm, the mancoosi package manager, to upgrade my laptop. My first use of it on a production system - until now I run all my experiments in throw-away virtual machines - and it works ! Not rocket science here. During the last month David Kalnischkies (of APT fame) visited our offices in Paris and together with zack worked out a communication protocol between apt-get and the mancoosi cudf solvers (EDSP). I guess somebody is going to announce all details about this endeavor soon. This cooperation enabled us to advance in the integration of apt-get and the mancoosi technology. Reusing the same protocol and backend I developed to translate the apt problem to cudf (and to call a suitable solver), I've re-wrote large part of mpm and added the possibility to generate the installation plan before calling dpkg and really installing the selected packages. Below notice the intermediate calls as Inject Model , Simulate, Compare Models . These are at the moment stubs that are going to call the simulation framework developed at mancoosi. The food : Reg the installation plan, this is an xml file that will be passed to a simulator developed by the university of L'Aquila to make sure that the installation script (well, a model of them), will not cause any problem during the installation. The format is a very simple xml file as follows : Soon APT will ship a patch to use the very same infrastructure of mpm (yeii !!!). This will on one hand make mpm useless as package manager on its own. It is a simple hack in python and I never tough to compete with its big brothers. On the other hand I think it will stand as a nice workbench to experiment with new ideas, to prototype new features and to make it easier for poeple that are not c++ experts to play with the APT library (thanks to python-apt) in a semi structured environment. The code is in the mancoosi svn if you want to have a look.

After a bit of work, today I decided to start using mpm, the mancoosi package manager, to upgrade my laptop. My first use of it on a production system - until now I run all my experiments in throw-away virtual machines - and it works ! Not rocket science here. During the last month David Kalnischkies (of APT fame) visited our offices in Paris and together with zack worked out a communication protocol between apt-get and the mancoosi cudf solvers (EDSP). I guess somebody is going to announce all details about this endeavor soon. This cooperation enabled us to advance in the integration of apt-get and the mancoosi technology. Reusing the same protocol, and backend I developed to translate the apt problem to cudf (and to call a suitable solver), I've re-wrote large part of mpm and added the possibility to generate the installation plan before calling dpkg and really installing the selected packages. Below notice the intermediate calls as Inject Model , Simulate, Compare Models . These are at the moment stubs that are going to call the simulation framework developed at mancoosi. The food : Reg the installation plan, this is an xml file that will be passed to a simulator developed by the university of L'Aquila to make sure that the installation script (well, a model of them), will not cause any problem during the installation. The format is a very simple xml file as follows : Soon APT will ship a patch to use the very same infrastructure of mpm (yeii !!!). This will on one hand make mpm useless as package manager on its own. It is a simple hack in python and I never tough to compete with its big brothers. On the other hand I think it will stand as a nice workbench to experiment with new ideas, to prototype new features and to make it easier for poeple that are not c++ experts to play with the APT library (thanks to python-apt) in a semi structured environment. The code is in the mancoosi svn if you want to have a look.

Executive summary: Don t use btrfs on Debian Squeeze.
Longer summary: Don t use btrfs RAID with the kernel Debian Squeeze comes with. About six months ago, I set up a new server to handle this web site, mail, and various other things. The system and most services (including web and mail) was set to use an MD RAID 1 array across two small partitions on two separate disks, and the remaining space was setup in three different btrfs file systems:

• One btrfs RAID 0 for shared data I wouldn t mind having offline while fixing issues on one disk
• One btrfs RAID 1 for shared data I would mind having offline while fixing issues on one disk
• One last btrfs RAID 0 for entirely throwable things such as build chroots

Three days ago, this happened:

May 10 10:18:04 goemon kernel: [3545898.548311] ata4: hard resetting link
May 10 10:18:04 goemon kernel: [3545898.867556] ata4: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
May 10 10:18:04 goemon kernel: [3545898.874973] ata4.00: configured for UDMA/33

followed by other ATA related messages, then, garbage such as:

May 10 10:18:07 goemon kernel: [3545901.28123] sd3000 d]SneKy:AotdCmad[urn][ecitr
May 10 10:18:07 goemon kernel: 4[550.821 ecio es aawt es ecitr i e)
May 10 10:18:07 goemon kernel: 6[550.824     20 00 00 00 00 00 00 00 <>3491225     16 44 <>3491216]s ::::[d]Ad es:N diinlsneifrain<>3491216]s ::::[d]C:Ra(0:2 00 03 80 06 0
3491217]edrqet / ro,dvsb etr2272
May 10 10:18:07 goemon kernel: 3[550.837 ad:sb:rshdln etr2252
May 10 10:18:07 goemon kernel: 6[551214]s ::::[d]Rsl:hsbt=I_Kdiebt=RVRSNE<>3491215]s ::::[d]SneKy:AotdCmad[urn][ecitr
May 10 10:18:07 goemon kernel: 4[550.833 ecitrsnedt ihsnedsrpos(nhx:<>3491216]    7 b0 00 00 c0 a8 00 00 0

Then later on:

May 10 12:01:18 goemon kernel: [3552089.226147] lost page write due to I/O error on sdb4
May 10 12:01:18 goemon kernel: [3552089.226312] lost page write due to I/O error on sdb4
May 10 12:10:14 goemon kernel: [3552624.625669] btrfs no csum found for inode 23642 start 0
May 10 12:10:14 goemon kernel: [3552624.625783] btrfs no csum found for inode 23642 start 4096
May 10 12:10:14 goemon kernel: [3552624.625884] btrfs no csum found for inode 23642 start 8192

etc. and more garbage. At that point, I wanted to shutdown the server, check the hardware, and reboot. Shutdown didn t want to proceed completely. Btrfs just froze on the sync happening during the shutdown phase, so I had to power off violently. Nothing seemed really problematic on the hardware end, and after a reboot, both disks were properly working. The MD RAID would resynchronize, and the btrfs filesystems would be automatically mounted. It would work for a while, until such things could be seen in the logs, with more garbage as above in between:

May 10 14:41:18 goemon kernel: [ 1253.455545] __ratelimit: 35363 callbacks suppressed
May 10 14:45:04 goemon kernel: [ 1478.717749] parent transid verify failed on 358190825472 wanted 42547 found 42525
May 10 14:45:04 goemon kernel: [ 1478.717936] parent transid verify failed on 358316642304 wanted 42547 found 42515
May 10 14:45:04 goemon kernel: [ 1478.717939] parent transid verify failed on 358190825472 wanted 42547 found 42525
May 10 14:45:04 goemon kernel: [ 1478.718128] parent transid verify failed on 358316642304 wanted 42547 found 42515
May 10 14:45:04 goemon kernel: [ 1478.718131] parent transid verify failed on 358190825472 wanted 42547 found 42525

Then there would be kernel btrfs processes going on and on sucking CPU and I/O, doing whatever it was doing. At such moment, most file reading off one of the btrfs volumes would either take very long or freeze, and un-mounting would only freeze. At that point, considering the advantages of btrfs (in my case, mostly, snapshots) were outweighed by such issues (this wasn t my first btrfs fuck up, but by large, the most dreadful) and the fact that btrfs is just so slow compared to other filesystems, I decided I didn t want to care trying to save these filesystems from their agonizing death, and that I d just go with ext4 on MD RAID instead. Also, I didn t want to just try (with the possibility of going through similar pain) again with a more recent kernel. Fortunately, I had backups of most of the data (only problem being the time required to restore that amount of data), but for the few remaining things which, by force of bad timing, I didn t have a backup of, I needed to somehow get them back from these btrfs volumes. So I created new file systems to replace the btrfs volumes I could directly throw away and started recovering data from backups. I also, at the same time, tried to copy a big disk image from the remaining btrfs volume. Somehow, this worked, with the system load varying between 20 and 60 (with a lot of garbage in the logs and other services deeply impacted as well) But when trying to copy the remaining files I wanted to recover, things got worse, so I had to initiate a shutdown, and power cycle again. Since apparently the kernel wasn t going to be very helpful, the next step was to just get other things working, and get the data back some other way. What I did was to use a virtual machine to get the data off the remaining btrfs volume. The kernel could become unusable all it wanted to, I could just hard reboot without impacting the other services. In the virtual machine, things got interesting . I did try various things I ve seen on the linux-btrfs list, but nothing really did anything at all except spew some more parent transid messages. I should mention that the remaining btrfs volume was a RAID 0. To mount those, you d mount one of the constituting disks like this:

$ mount /dev/sdb /mnt

Except that it would complain that it can t find a valid whatever (I don t remember the exact term, and I threw the VM away already) so it wouldn t mount the volume. But when mounting the other constituting disk, it would just work. Well, that s kind of understandable, but what is not is that on the next boot (I had to reboot a lot, see below), it would error out on the disk that worked previously, and work on the disk that was failing before. So, here is how things went:

• I would boot the VM and mount the volume,
• launch an rsync of the data to recover, which I d send onto the host system,
• observe, from the host system, what was going on I/O wise,
• at some point (usually after something like 10 to 50 files rsync ed), after throwing a bunch of parent transid error messages, the VM would just stop doing any kind of I/O (even if left alone for several minutes), at which point I d hard shutdown the VM and start over.

Ain t that fun? The good thing is that in the end, despite the pain, I recovered all that needed to be recovered. I m in the process of recreating my build chroots from scratch, but that s not exactly difficult. It would just have taken a lot more time to recover them the same way, 50 files at a time. Side note: yes, I did try newer versions of btrfsck ; yes I did try newer kernels. No, nothing worked to make these btrfs volumes viable. No, I don t have an image of these completely fucked up volumes.

Today was Bike to Work Day, and I biked to work, just like I do most other days. I missed out on it last year because I was still out on paternity leave at the time. That means I've almost been back at work a year. Since we only have one car, and when Zoe was little and sleeping a lot, it made most sense for me to start biking to work again. I'm really glad I did, because not only is it faster compared to the round trip time that Sarah would need to take to drop me off and pick me up, it's a lot easier on her and Zoe. It used to be a challenge for Sarah to get from home to work and back in the mornings without Zoe falling asleep in the car. The only times I've needed a lift have been in wet weather during winter, and when I've been sick. Now that we're out of winter, we should have endless sunshine for months, and it's starting to warm up, which makes biking so much more pleasant. It takes about 10-12 minutes door to door, which is short and sweet, and most of that is on the lovely Stevens Creek Trail. I'm glad I've been able to stick at it for the whole year. I see no reason to stop any time soon.

LightDM's a from-scratch implementation of an X display manager, ie the piece of software that handles remote X connections, starts any local X servers, provides a login screen and kicks off the initial user session. It's split into a nominally desktop-agnostic core (built directly on xcb and glib) and greeters, the idea being that it's straightforward to implement an environment-specific greeter that integrates nicely with your desktop session. It's about 6500 lines of code in the core, 3500 lines of code in the gtk bindings to the core and about 1000 in the sample gtk greeter, for a total of about 11,000 lines of code for a full implementation. This compares to getting on for 60,000 in gdm. Ubuntu plan to switch to LightDM in their next release (11.10).

This is a ridiculous idea.

To a first approximation, when someone says "Lightweight" what they mean is "I don't understand the problems that the alternative solves". People see gtk and think "Gosh, that's kind of big for a toolkit library. I'll write my own". And at some point they have to write a file dialog. And then they need to implement support for handling remote filesystems. And then they need to know whether the system has a functioning network connection or not, and so they end up querying state from Network Manager. And then they suddenly have a library that's getting on for the size of gtk, has about the same level of complexity and has had much less testing because why would you want to use a lightweight toolkit that either does nothing or is 90% of the size of the alternative and crashes all the time.

Adding functionality means that code gets larger. Given two codebases that are of significantly different sizes, the two possible conclusions are either that (a) the smaller one is massively more competently written than the larger one, or (b) the smaller one does less. The gdm authors have never struck me as incompetent, even if some people may disagree with some of their design decisions, and the LightDM authors don't seem to have argued on that basis either. So the obvious conclusion is that LightDM does less.

And, indeed, LightDM does less. Part of this is by design - as the proposal to the Gnome development list shows, one of the key advantages of LightDM is claimed as it not starting a Gnome session. And from that statement alone, we can already see that there's been a massive failure of understanding the complexity of the problem.

Let's go back to the comparisons of code size. LightDM's simple GTK greeter is about 1000 lines of code. gdm's greeter is almost 20,000. Some of this is arbitrary shiny stuff like the slidy effects that occur, but a lot of it is additional functionality. For example, some of it is devoted to handling the interface with AccountsService so gdm can automatically update when users are created or deleted. Some of it is providing UI for accessibility functionality. Some of it is drawing a clock, which I'll admit may be a touch gratuitous.

But if your argument is that your software is better because it's doing less, you should be able to ensure that you can demonstrate that the differences aren't important. And the differences here are important. For example, one of the reasons gdm starts a local gnome session is that it wants gnome-power-manager to be there to handle power policy. Closing the lid of my laptop should suspend the system regardless of whether it's logged in or not. LightDM takes a different approach. Because there's no session, it has to take care of this kind of thing itself. So the backend daemon code speaks to upower directly, and the greeters ask the daemon to implement their policy decisions.

This is pretty obviously miserable. Now you've got two sets of policy - one at the login screen, and one in your session. How do I ensure they're consistent? The only sane solution is to ignore the functionality the backend provides and have my greeter run gnome-power-manager. And now how about accessibility preferences? Again, if I want to have the same selection of policy, I need to run the same code. So you end up with a greeter that's about as complex and large as the gdm one, and unused functionality in the backend. Lighter weight through code duplication. We have always been at war with Eurasia.

The entirety of LightDM's design is based on a false premise - that you can move a large set of common greeter functionality into a daemon and just leave UI presentation up to the greeter code. And if you believe that, then yes, you can absolutely implement a greeter in 1000 lines of code. It'll behave differently to your desktop - the range of policy you can implement will be limited to what the daemon provides, even if your desktop environment has a different range of features. It'll have worse accessibility for much the same reason. And eventually you'll end up with a daemon that's absolutely huge in order to attempt to provide the superset of functionality that each different desktop makes use of.

The only real problem LightDM solves is that it makes it easier to write custom greeters, and if you're really seeking to differentiate your project based on your login screen then maybe your priorities are a little out of line. I'm sure that Ubuntu will release with a beautiful 3D greeter that has a wonderful transition to the desktop. It's just a shame that it won't do any of the useful things that the existing implementations already do.

And if you think that when LightDM finally has the full feature set of gdm, kdm and lxdm it'll still be fewer lines of code and take less memory - I hear the BSD kernel is lighter weight than Linux. Have fun with it.

I've installed Debian sid in a FreeBSD 8.2 jail and I'm seeing this weird effect:

root@debian:~# aptitude upgrade
No packages will be installed, upgraded, or removed.
0 packages upgraded, 0 newly installed, 0 to remove and 1 not upgraded.
Need to get 0 B of archives. After unpacking 0 B will be used.
                                         
User defined signal 1
root@debian:~#

This will randomly kill the normal aptitude gui, while other things like vim or dpkg-reconfigure using the 'dialog' gui will work normally.

Google is useless. strace doesn't work. ktrace gives
21131 100410 aptitude-curses CALL stat(0x9ef968,0x7fffffffe810)
21131 100410 aptitude-curses NAMI "/tmp/aptitude-root.21131:mvkyG0"
21131 100410 aptitude-curses STRU invalid record
21131 100410 aptitude-curses RET stat 0
21131 100410 aptitude-curses CALL open(0x9ef968,O_NONBLOCK,<unused>0)
21131 100410 aptitude-curses NAMI "/tmp/aptitude-root.21131:mvkyG0"
21131 100410 aptitude-curses RET open 3
21131 100410 aptitude-curses CALL fstat(0x3,0x7fffffffe810)
21131 100410 aptitude-curses STRU invalid record
21131 100410 aptitude-curses RET fstat 0
21131 100410 aptitude-curses CALL fcntl(0x3,<invalid=2>,FD_CLOEXEC)
21131 100410 aptitude-curses RET fcntl 0
21131 100410 aptitude-curses CALL getdents(0x3,0x1b9e630,0x20000)
21131 100410 aptitude-curses RET getdents 24/0x18
21131 100410 aptitude-curses CALL getdents(0x3,0x1b9e630,0x20000)
21131 100410 aptitude-curses RET getdents 0
21131 100410 aptitude-curses CALL close(0x3)
21131 100410 aptitude-curses RET close 0
21131 100410 aptitude-curses CALL rmdir(0x9ef968)
21131 100410 aptitude-curses NAMI "/tmp/aptitude-root.21131:mvkyG0"
21131 100410 aptitude-curses RET rmdir 0
21131 100410 aptitude-curses CALL write(0x28,0x7fffffffeb20,0x38)
21131 100410 aptitude-curses GIO fd 40 wrote 56 bytes
0x0000 4026 a000 0800 0000 0200 0000 0800 0000 0000 0000 0800 0000 0000 0000 0000 0000 2818 0803 0800 0000 a0f9 9d00 0000 0000 0100 0000 @&..............................(...................
0x0034 0000 0000 ....

21131 100410 aptitude-curses RET write 56/0x38
21131 100410 aptitude-curses CALL sigprocmask(SIG_SETMASK,0,0x7fffffffeaf0)
21131 100410 aptitude-curses RET sigprocmask 0
21131 100410 aptitude-curses PSIG SIGUSR1 SIG_DFL


Anybody has an idea?

root@debian:~# uname -a
GNU/kFreeBSD debian.home 8.2-RELEASE FreeBSD 8.2-RELEASE #1: Wed Apr 6 09:52:09 CEST 2011 root@frost.local:/usr/obj/usr/src/sys/PEVANEYN x86_64 amd64 Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz GNU/kFreeBSD

This entry was originally posted at http://pvaneynd.dreamwidth.org/140395.html. Please comment there using OpenID.

1. Find a shift where the meal break is later than average. These are especially common in the afternoon, where there's a lot of trains to drive during the peak to get everyone home. Make sure to execute your fiendish plan on the last run before the meal break.
2. Buy a big helping of hot chips, making sure to load up on the delicious condiments like malt vinegar.
3. Sit right behind the driver's cab with your deep fried basket of deliciousness. With a battery operated fan, you can increase deliciousness penetration considerably, but it's something of a "nuclear option".
4. Put your ear to the cab door to hear the loud growling sounds coming from the driver's stomach.
5. ...
6. PROFIT!
The only thing saving me from bursting out the cab door screaming "The chips! I wants them!" was the fact I had a nut bar in my bag. They were particularly delicious smelling chips.

Is there something a little odd about the Deaf Society of NSW having a website with a frontpage, and other rather crucial bits like course information lookup forms, that are built entirely using flash. Given that, as far as I know, screen reading software and flash aren't best of friends? I guess they figure that as long as people are catering to their disability, everyone else can fend for themselves. A slightly more charitable interpretation might be that blind people aren't going to be real keen to learn sign language, but I would have thought that a bit of consideration might be shown, for the purposes of solidarity or something.