My experience with LapStore's used-ThinkPad warranty repair service My ThinkPad T40 arrived back from warranty repair today (well, actually yesterday, but I had to run off to the Gnome-2.26 release get-together in Munich so I did not have time to open the box then). I bought it used roughly two years ago at LapStore when my R51 had died. I had bought the R51 new with a one year IBM warranty but unfortunately within two years the graphics chip with got damaged and would freeze the notebook after a couple of minutes. I then decided that I do not really need a new notebook anymore, and opted for a used T4x series (there were no used X40s available at that time). I chose LapStore because they offered a one-year "Garantie" (guarantee? warranty?), which was rather unusual for used notebooks - at best, you would get a one-year "Gewaehrleistung" which is the promise to fix things which were supposedly broken already by delivery. Even better, one could optionally extend the warranty to two years, which I did. The notebook they sent was in pretty good condition (apparently a business out-of-warranty return) and I put in my R51's hard disk, the ipw2100 WLAN card and the RAM (unfortunately, I realized too late that the keyboard and the CDRW/DVD drive do not fit). I was pretty happy with it (and LapStore in general, I recommended it to a couple of friends since, and e.g. my current flatmate bought a T42 there a while ago as well) until the fan started dropping out and making weird noises by the end of 2008. So just before the end of warranty, I sent it (after removing hard disk, optical drive and battery) in to LapStore to see how their service is. I also mentioned a clear bright spot on the display (apparently some fatigue, you see it often mentioned in ThinkPad eBay descriptions) and a crack in the palmrest between the cursor-right key and the hard disk slot. When they sent a mail that the ThinkPad had arrived at their site, I also followed-up via mail that the "indestructible" keyboard caps stickers they used to mod a Scandinavian(?) keyboard into a German one were pretty much destroyed by now and would also need servicing. I assumed that they would service the fan (which looked like a clear-cut warranty issue to me) without arguing, but probably not the display and palmrest (and did not know whether they got the mail about the keyboard stickers), so when they sent another mail two days ago that they sent the notebook back without asking further questions, I became worried about what happened at all. So, long story short, I was totally positively surprised when I opened the box today and read: "Aktion: L fter, Display, Palmrest und Tastatur getauscht" (action: fan, display, palmrest and keyboard replaced) The replacements are still used parts (and the keyboard is still not a real German one, but one with new stickers on it), but they basically changed my almost-totally-broken-will-fall-apart T40 back into a almost-as-good-as-new T40. (not sure whether that is positive or negative, but they also forgot to remove the service-hard disk they put in to test things, I guess I will send it back to them) So all in all, I am very much impressed by their service. I would have expected this kind of service from IBM/Lenovo if I had a manufacturer warranty, but not from some random sell-used-ThinkPads shops on the net. I can now even more strongly recommend LapStore as the place to buy good notebooks. Certainly you can get cheaper prices at some eBay stores, but you do not get real warranty then and what about the service? I recommend geting a T42 - I believe the T43 is inferior to it and the T40s and T41s don't have "LapStore Garantie" anymore. You can get them without operating system and can customize the hard disk, memory and optical drives - unfortunately you cannot downgrade those, which is my only gripe with them.

I have a long list (it exists only in my head unfortunately) of various ethnographic projects I would like to conduct. I might start the real list soon but in the meantime, I will just through the half-baked ideas here and perhaps it will inspire others to take it on. I am currently reading a fantastic book, The Case Against Perfection, and am on a section on hyperparenting and well, while I think at a common sense level we know what psychological havoc such controlled parenting can cause, I think an ethnography of some of the practices and institutions of hyperparenting would, nonetheless, make for a fascinating read. If anyone knows of anything that even resembles this, do drop me a line. Update: Not exactly an ethnography but certainly fun to read.

I have a long list (it exists only in my head unfortunately) of various ethnographic projects I would like to conduct. I might start the real list soon but in the meantime, I will just through the half-baked ideas here and perhaps it will inspire others to take it on. I am currently reading a fantastic book, The Case Against Perfection, and am on a section on hyperparenting and well, while I think at a common sense level we know what psychological havoc such controlled parenting can cause, I think an ethnography of some of the practices and institutions of hyperparenting would, nonetheless, make for a fascinating read. If anyone knows of anything that even resembles this, do drop me a line. Update: Not exactly an ethnography but certainly fun to read.

Bruce Schneier writes about the risks involving children abandoned in cars and cites an article about the tragic deaths of children in hot cars [1]. One unfortunate error that he made was to not cite the following from the end of the last page of the Washington post article he cited [2]:
In hyperthermia cases, he believes, the parents are demonized for much the same reasons. We are vulnerable, but we don t want to be reminded of that. We want to believe that the world is understandable and controllable and unthreatening, that if we follow the rules, we ll be okay. So, when this kind of thing happens to other people, we need to put them in a different category from us. We don t want to resemble them, and the fact that we might is too terrifying to deal with. So, they have to be monsters. I believe that similar thought processes are used in relation to many other situations, and that such thought processes prevent people from taking appropriate actions to minimise the risk. If someone considers that forgetting a child in the back seat to be an accident that could happen to anyone then they would be inclined to take action to minimise the risk (such as spending some money on a sensor). If however they consider such forgetfulness to be proof of being a bad parent , then as they are a good parent they would have to avoid buying a monitor. I m surprised that Bruce didn t draw an analogy between this and the forgetful losses of laptops and guns by people who work for law enforcement agencies (which he has written about before). I wonder how expensive it would be to make a sensor for heart-rate, breathing, and temperature integrated with a GSM modem and a GPS? If it could be small enough to be attached to clothes then the child could wear it at all times. If such a sensor was to detect a sign of a problem it wouldn t matter whether the child was forgotten in a car, at day-care, or even being actively supervised. The data would be sent to the monitoring agency along with GPS data. The monitoring agency could then phone the parents. If the parents don t answer or don t know where the child is then the police could track down the GPS location. Probably most calls would be due to parents leaving a child too close to an air-conditioner or playing outside in the sun in summer which are unlikely to give a fatal result and a phone call would get a quick fix for what would only be a minor health problem. If the device was marketed as monitoring for sleep apnia then parents could buy it without admitting to the possibility that they might do anything wrong. The causes of SIDS are a topic of ongoing research and parents can admit to being worried about their children suffering from it without admitting any possibility that they might make a mistake.

• [1] http://www.schneier.com/blog/archives/2009/03/leaving_infants.html


• [2] http://www.washingtonpost.com/wp-dyn/content/article/2009/02/27/AR2009022701549.html

After reading the comments on my earlier post, Delayed allocation and the zero-length file problem as well as some of the comments on the Slashdot story as well as the Ubuntu bug, it s become very clear to me that there are a lot of myths and misplaced concerns about fsync() and how best to use it. I thought it would be appropriate to correct as many of these misunderstandings about fsync() in one comprehensive blog posting. As the Eat My Data presentation points out very clearly, the only safe way according that POSIX allows for requesting data written to a particular file descriptor be safely stored on stable storage is via the fsync() call. Linux s close(2) man page makes this point very clearly:

A successful close does not guarantee that the data has been successfully saved to disk, as the kernel defers writes. It is not common for a file system to flush the buffers when the stream is closed. If you need to be sure that the data is physically stored use fsync(2).

Why don t application programmers follow these sage words? These three reasons are most often given as excuses:

1. (Perceived) performance problems with fsync()
2. The application only needs atomicity, but not durability
3. The fsync() causing the hard drive to spin up unnecessarily in laptop_mode

Let s examine each of these excuses one at a time, to see how valid they really are. (Perceived) performance problems with fsync() Most of the bad publicity with fsync() originated with the now infamous problem with Firefox 3.0 that showed up about a year ago in May, 2008. What happened with Firefox 3.0 was that the primary user interface thread called the sqllite library each time the user clicked on a link to go to a new page. The sqllite library called fsync(), which in ext3 s data=ordered mode, caused a large, visible latency which was visible to the user if there was a large file copy happening by another process. Nearly all of the reported delays was a few seconds, which would be expected; normally there isn t that much dirty data that needs to be flushed out on a Linux system, even if it is even very busy. For example, consier the example of a laptop downloading an .iso image from a local file server; if the laptop has the exclusive link of a 100 megabit/second ethernet link, and the server has the .iso file in cache, or has a nice fast RAID array so it is not the bottleneck, then in the best case, the laptop will be able to download data at the rate of 10-12 MB/second. Assuming the default 5 second commit interval, that means that in the worst case, there will be at most 60 megabytes which must be written out before the commit can proceed. A reasonably modern 7200 rpm laptop drive can write between 60 and 70 MB/second. (The Seagate Momentus 7200.4 laptop drive is reported to be able to deliver 85-104 MB/second, but I can t find it for sale anywhere for love or money.) In this example, an fsync() will trigger a commit and might need to take a second while the download is going on; perhaps half a second if you have a really fast 7200 rpm drive, and maybe 2-3 seconds if you have a slow 5400 rpm drive. (Jump to Sidebar: What about those 30 second fsync reports?) Obviously, you can create workloads that aren t bottlenecked on the maximum ethernet download speed, or the speed of reading from a local disk drive; for example, dd if=/dev/zero of=big-zero-file will create a very large number of dirty pages that must be written to the hard drive at the next commit or fsync() call. It s important to remember though, fsync() doesn t create any extra I/O (although it may remove some optimization opportunities to avoid double writes); fsync() just pushes around when the I/O gets done, and whether it gets done synchronously or asynchronously. If you create a large number of pages that need to be flushed to disk, sooner or later it will have a significant and unfortunate effect on your system s performance. Fsync() might make things more visible, but if the fsync() is done off the main UI thread, the fact that fsync() triggers a commit won t actually disturb other processes doing normal I/O; in ext3 and ext4, we start a new transaction to take care of new file system operations while the committing transction completes. The final observation I ll make is that part of the problem is that Firefox as an application wants to make a huge number of updates to state files and was concerned about not losing that information even in the face of a crash. Every application writer should be asking themselves whether this sort of thing is really necessary. For example, doing some quick measurements using ext4, I determined that Firefox was responsible for 2.54 megabytes written to the disk for each web page visited by the user (and this doesn t include writes to the Firefox cache; I symlinked the cache directory to a tmpfs directory mounted on /tmp to reduce the write load to my SSD). So these 2.54 megabytes is just for Firefox s cookie cache and Places database to maintain its Awesome bar . Is that really worth it? If you visit 400 web pages in a day, that s 1GB of writes to your SSD, and if you write more than 20GB/day, the Intel SSD will enable its write endurance management feature which slows down the performance of the drive. In light of that, exactly how important is it to update those darned sqllite databases after every web click? What if Firefox saved a list of URL s that has been visited, and only updated every 30 or 60 minutes, instead? Is it really that every last web page that you browse be saved if the system crashes? An fsync() call every 15, 30, or 60 minutes, done by a thread which doesn t block the application s UI, would have never been noticed and would have not started the firestorm on Firefox s bugzilla #421482. Very often, after a little thinking, a small change in the application is all that s necessary for to really optimize the application s fsync() usage. (Skip over the sidebar if you ve already read it). Sidebar: What about those 30 second fsync reports? If you read through the Firefox s bugzilla entry, you ll find reports of fsync delays of 30 seconds or more. That tale has grown in the retelling, and I ve seen some hyperbolic claims of five minute delays. Where did that come from? Well, if you look that those claims, you ll find they were using a very read-heavy workload, and/or they were using the ionice command to set a real-time I/O priority. For example, something like ionice -c 1 -n 0 tar cvf /dev/null big-directory . This will cause some significant delays, first of all because ionice -c 1 causes the process to have a real-time I/O priority, such that any I/O requests issued by that process will be serviced before all others. Secondly, even without the real-time I/O priority, the I/O scheduler naturally prioritizes reads as higher priority than writes because normally processes are waiting for reads to complete, but writes are normally asynchronous. This is not at all realistic workload, and it is even more laughable that some people thought this might be an accurate representation of the I/O workload of a kernel compile. These folks had never tried the experiment, or measured how much I/O goes on during a kernel compile. If you try it, you ll find that a kernel compile sucks up a lot of CPU, and doesn t actually do that much I/O. (In fact, that s why an SSD only speeds up a kernel compile by about 20% or so, and that s in a completely cold cache case. If the commonly used include files are already in the system s page cache, the performance improvement of the SSD is much less.) Jump back to reading Performance problems with fsync. The atomicity not durability argument One argument that has commonly been made on the various comment streams is that when replacing a file by writing a new file and the renaming file.new to file , most applications don t need a guarantee that new contents of the file are committed to stable store at a certain point in time; only that either the new or the old contents of the file will be present on the disk. So the argument is essentially that the sequence:

• fd = open( foo.new , O_WRONLY);
• write(fd, buf, bufsize);
• fsync(fd);
• close(fd);
• rename( foo.new , foo );

is too expensive, since it provides atomicity and durability , when in fact all the application needed was atomicity (i.e., either the new or the old contents of foo should be present after a crash), but not durability (i.e., the application doesn t need to need the new version of foo now, but rather at some intermediate time in the future when it s convenient for the OS). This argument is flawed for two reasons. First of all, the squence above exactly provides desired atomicity without durability . It doesn t guarantee which version of the file will appear in the event of an unexpected crash; if the application needs a guarantee that the new version of the file will be present after a crash, it s necessary to fsync the containing directory. Secondly, as we discussed above, fsync() really isn t that expensive, even in the case of ext3 and data=ordered; remember, fsync() doesn t create extra I/O s, although it may introduce latency as the application waits for some of the pending I/O s to complete. If the application doesn t care about exactly when the new contents of the file will be committed to stable store, the simplest thing to do is to execute the above sequence (open-write-fsync-close-rename) in a separate, asynchronous thread. And if the complaint is that this is too complicated, it s not hard to put this in a library. For example, there is currently discussion on the gtk-devel-list on adding the fsync() call to g_file_set_contents(). Maybe if someone asks nicely, the glib developers will add an asynchronous version of this function which runs g_file_set_contents() in a separate thread. Voila! Avoiding hard drive spin-ups with laptop_mode Finally, as Nathaniel Smith said in Comment #111 of of my previous post:

The problem is that I don t, really, want to turn off fsync s, because I like my data. What I want to do is to spin up the drive as little as possible while maintaining data consistency. Really what I want is a knob that says I m willing to lose up to minutes of work, but no more . We even have that knob (laptop mode and all that), but it only works in simple cases.

This is a reasonable concern, and the way to fix this is to enhance laptop_mode in the Linux kernel. Bart Samwel, the author and maintainer of laptop_mode, actually discussed this idea with me last month at FOSDEM. Laptop_mode already adjusts /proc/sys/vm/dirty_expire_centisecs and /proc/sys/vm/dirty_writeback_centisecs based on the configuration parameter MAX_LOST_WORK_SECONDS, and it also adjusts the file system commit time (for ext3; it needs to be taught to do the same thing for ext4, which is a simple patch) to MAX_LOST_WORK_SECONDS as well. All that is necessary is a kernel patch to allow laptop_mode to disable fsync() calls, since the kernel knows that it is in laptop_mode, and it notices that the disk has spun up, it will sync out everything to disk, since once the energy has been spent to spin up the hard drive, we might as well write everything in memory that needs to be written out right away. Hence, a patch which allows fsync() calls to be disabled while in laptop_mode should do pretty much everything Nate has asked. I need to check to see if laptop_mode does this already, but if it doesn t force a file system commit when it detects that the hard drive has been spun up, it should obviously do this as well. (In addition to having a way to globally disable fsync() s, it may also be useful to have a way to selectively disable fsync() s on a per-process basis, or on the flip side, exempt some process from a global fsync-disable flag. This may be useful if there are some system daemons that really do want to wake up the hard drive and once the hard drive is spinning, naturally everything else that needs to pushed out to stable store should be immediately written.) With this relatively minor change to the kernel s support of laptop_mode, it should be possible to achieve the result that Nate desires, without needing force applications to worry about this issue; applications should be able to just simply use fsync() without fear. Summary As we ve seen, the reasons most people think fsync() should be avoided really don t hold water. The fsync() call really is your friend, and it s really not the villain that some have made it out to be. If used intelligently, it can provide your application with a portable way of assuring that your data has been safely written to stable store, without causing a user-visible latency in your application. The problem is getting people to not fear fsync(), understand fsync(), and then learning the techniques to use fsync() optimally. So just as there has been a Don t fear the penguin campaign, maybe we also need to have a Don t fear the fsync() campaign. All we need is a friendly mascot and logo for a Don t fear the fsync() campaign. Anybody want to propose an image? We can make some T-shirts, mugs, bumper stickers Related posts (automatically generated):

1. Delayed allocation and the zero-length file problem A recent Ubuntu bug has gotten slashdotted, and has started...

And there we have done it - new sections in the archive. Read more about it in my d-d-a post and the whole set of affected packages is also available - and updated slightly, as some small things slipped through. The whole process was less painful than feared. After some discussion, started a few weeks ago we finally went and coordinated the change today. There was no reliable and good way for changes that large, so we had to create our own way. (The last section changes had been done ages ago). Mike provided a little python script which was able to parse our input file with the section matches against our database, so we ended up with a list we could possibly feed back into the database. Except, not really. Thanks to various things the list generated needed some manual work (which I also managed to fuck up a little), but after that was done we were ready to go. And while Mark told the wanna-build admins about the new sections (for some reason our buildd network cares about sections) and prepared a patch for our policy, I prepared the mail for the d-d-a list. Then we all had a break, as a dinstall was still running, and we did not want to break that. The actual changes then took only a few seconds, sending the mail to d-d-a took longer, thankyou gnupg. :) I wonder how much afterwork this will generate. There are at least the policy changes, lintian, the packages control files to adjust. Also some websites, where Frank already changed packages.debian.org to know about the new names. (Before he fixed up me forgetting some PHP packages to move. This way all of the active ftpteam members did something in it :) ).

---

In other news, we are currently stress-testing our ftp-master host a little. Well, not really, it could take more, but right now we are scanning the full archive once, importing all filenames from all our Debian packages. The goal is to get projectb larger. Err, no, actually we do want to get rid of apt-ftparchive, as that is one of the worst tools in our dinstall runs. It is slow as hell in the mode it has to run for us, making up a large part of our runtime. Step 1 to get rid of it is to generate the content files on our own, and before we can do that we have to import them all Which means we have to unpack every binary package once, reading in all filenames to store them in our database. Thats a lot of data. Currently the associations table, which is nothing more than 4 integers per row, takes up 972MB, and import is still running. (The index on the binary pkg id in this table alone has 700MB). And this table does nothing more than linking the binary package to the filename and filepath. Which are two extra tables, with the filenames having only 87MB, the path entries only taking up 30MB. Yes, anyone using databases will tell me thats not much, and it really isn t that much. It s just that the largest table before this import had 120MB in it. And some of the others used more space for their indexes than for the actual data. :) Anyway, this is only step one on our way to get rid of the slowness apt-ftparchive is. When the contents all work as we want them, the next step will be to get rid of it generating Packages/Sources files. Which means we have some more data to store in projectb. And after that - we also intend to do a Contents file for our source. Each and every source file listed. Guess we really will end up with some more large tables. :) The final goal and main reason why we do this is to save us at least 60 minutes runtime per dinstall run. My own guess is that Contents alone will get us about 20 minutes down. No, before someone wants to yell at me - apt-ftparchive can t be changed as much to make this possible and keep using it. Not in the way the generate option works. It has the disadvantage that it scans the files after they are installed in their pool/ location and stores that in its own database . This approach has to negative points:

• first, it is using another database (BerkeleyDB). We do have one database already, projectb, thank you.
• second, and more important, the files only end up in pool/ on dinstall time. Which means the whole scanning is done during dinstall. Which eats time. The new way will surely use the same amount of cpu time in total - but it will spread it over the whole day. 4 runs each hour. Not 4 runs each day. And during dinstall it will boil down to one sql query per installed package moving data from a pending table into the real contents table. Which is a cheap operation.

---

The title says some more, so here is some more: We aren t only working on what I wrote above. There is also work on changing our database access. Historically dak used the pg module to do database work. While the module itself does work, the way its used isn t really the best one. Way too much groundwork everywhere. Not nearly as much of the nice things used people say python could have. So another largish work area is getting rid of pg. Migrating to psycopg2. And putting a proper OO class around it, which in the end hopefully hides those dark details from the application. And to achieve even more sanity, we (well, honestly, Mark) are looking into SQL Alchemy usage. (We also considered storm from Canonical, but that sucks when you take a look at its documentation. (Which documentation?). SQLA won there easily.) While I m ranting: WTF are people neglecting their docs that much? Ever tried looking at the documentation for psycopg2? Forget it. No, a db api compliance test suite is NOT documentation. If there would be any better python module to connect to postgres, I would veto the usage of psycopg2, but there doesn t seem to be one. Sucks.

I received a SheevaPlug this week, an intriguing device that packs incredible power and functionality into a tiny package. As many of you know, I've been doing a lot of work on Debian for the Linksys NSLU2 in the last few years. The NSLU2 is a key reason why ARM has become the third most popular architecture in Debian (after 32 and 64 bit x86), and I believe a main reason is that the NSLU2 is so incredibly cheap. At a price under $100, most people don't think too long and simply buy a device and do something cool with it. The SheevaPlug is being offered at the same price range but offers considerably more. Riku Voipio asked the right question: "What would you do with something approximately 10x more powerful with same prize/size range?" I believe the SheevaPlug is a killer replacement for the NSLU2 and here's why:

• Marvell Kirkwood 6281 CPU at 1.2 GHz with 256 KB L2 cache (compared to a 266 MHz CPU)
• 512 MB RAM (compared to lousy 32 MB)
• 512 MB flash, enough for a basic Debian installation (compared to 8 MB)
• Gigabit Ethernet (compared to 100 Mb) and no proprietary microcode required
• 1x USB and 1x SD (compared to 2x USB: the only advantage the NSLU2 has)
• ... and finally: mini-USB with serial console and JTAG: while Debian on the NSLU2 works well and is stable, we regularly had users whose system would no longer boot and there was no good way to figure out why. The serial console on the SheevaPlug actually allows users to figure out what's going on.

I'm incredibly excited about the SheevaPlug and the first thing I did was to take the device apart and look at the inside. The results can be found in the SheevaPlug image gallery. My next project will be slightly more productive: porting Debian. As I see it, we should support the following three installation variants for the SheevaPlug:

• To an external USB drive or stick.
• To an SD card.
• To the 512 MB flash memory on the device.

The first two should be relatively straight forward, but of course installing to the internal flash memory is particularly interesting given that 512 MB (plus compression) is enough for a basic installation of Debian. Unfortunately, installations to MTD flash are currently not supported in the Debian installer but I hope we can find a volunteer who wants to implement this functionality. My next steps are to put a kernel for the SheevaPlug into the archive and to get a basic installation going. From there we can look at more sophisticated installation options and other functionality.

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

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

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

Yesterday was my birthday, and it was full of cookies, pies, magical pixie dust and things made entirely of sugar and spice! The remainder of the day was spent re-installing Debian Lenny upon my EEE PC - Somehow I managed to completely screw the system. Because the EEE PC is one of those ultra-portable machines I mostly used it when I was travelling, or outdoors. That mean I was generally receiving poor connectivity and the system packages weren't up to date. While I was in bed I figured I'd dist-upgrade it to the recently released Lenny. Unfortunately I started the dist-upgrade inside X.org, once I realised this I figured I'd cancel the operation via Ctrl-c. Bad news everbody: I think I was unlucky enough to interrupt an upgrade of libc, or something equally critical. Every single application gave segfaults afterward. I had two open root terminals and I could navigate around via cd .., and "echo *", but all other commands such as sudo, dpkg, strace just gave segfaults. (Even static commands gave errors - so it might have been the dynamic loader that was borked, I admit I didn't look too closely.) I figured reinstalling would be a good solution since the machine has a 4Gb root partition and /home was stored on a separate 16Gb volume. Unfortunately I managed to misjudge the installer's partitioning step and nuke the partition table on the external volume so I ended up losing the whole system. Happily reinstallation was a breeze as my home network is setup to allow installation via PXE network booting (at some point I should document NFS-root PXE-booting). It took me longer to fiddle with the BIOS on the EEE PC to allow network booting than it did to complete a minimal install. Which I guess is good. I still need to restore my backup of /home/, but that can wait a few days. Right now I'm loathe to touch the machine at all - although I did distract myself by getting KVM to PXE boot:

# create 4gb disk image
dd if=/dev/zero of=/tmp/img.img bs=1024 count=4096k
# launch KVM
sudo kvm -no-acpi
  -boot n -tftp /var/lib/tftpboot/ -bootp /pxelinux.0
  -hda /tmp/img.img
  -net nic,macaddr=00:0E:35:be:de:ad  -net user

It seems that KVM wants to have access to the local TFTP root directory so I just pointed it at that. Since my desktop machine is also my TFTP + DHCP host that works out nicely. (A quick scan of the manual suggests that QEMU/KVM has funky built-in TFTP code, so it doesn't actually forward TFTP requests over the network.) DHCP requests were certainly passed around as expected though and were answered via my local dnsmasq installation. I did see errors at every DHCP request in syslog, but they seemed harmleess enough:

gold dnsmasq[29241]: no address range available for DHCP request via qemu0

*shrugs* ObFilm: Never Been Kissed.