I think I should follow up on Victor's lament. Yes, we have a Rails application which works fine most of the time... But quite often, throws out a segmentation fault I just have been unable to pin-point. It might be related to rmagick, the only non-pure-Ruby component I am using (and I'm tempted to try minimagick instead, even if I prefer in-memory operations than on-disk, piping an image and slurping it again).
Victor came up with an easy script to check the server - but to reduce the impact it has (I was running a single Mongrel instance, which meant, whenever it dies the whole system becomes inaccessible for everybody; I replaced it with a mongrel_cluster of five processes, plus pound as a easy-to-use balancer which looks quite nice), the very simplistic and to-the-point script did no longer work.
Anyway... Ruby rocks ;-) I'm sharing this with you mostly because I am sure some readers will find more than one useful construct, not because it is precisely beautiful code. And besides, we should work on fixing the cause, not the consequence, of the bug! :)

Works out of the box for any Debian-packaged mongrel-cluster. Sadly, mongrel-cluster does not provide a way to restart individual servers - Of course, I could (should, even) work it out to build the specific command-line... but at least, it works for now.
Uh-oh... Does that mean it's permanent?

You know you have reached email zen when your domain is down for a week, maybe because your dns is down, you don t give a flying fuck, and are in no hurry to fix it. Bonus points if you don t get automatically unsubscribed from any mailing lists.

Check out this new website the Museum of Intellectual Property, which provides some nice case studies and visuals for the study/critique of IP law. It also bears a slightly different IP notice, the Konomark, which is not a license, but as its web page explains, a signal.

I've been getting a lot of blog spam lately; it appears that Akismet is slipping. Fortunately, there's a new Akismet-compatible alternative at TypePad AntiSpam which I read about from Justin Mason's post. And it being perl, I decided to try it out here on my blog (never mind it being Blosxom, as long as it uses Frank Hecker's feedback plugin that in turn uses Net::Akismet. But alas, the current version of Net::Akismet doesn't support user-supplied REST endpoints, so I added it, and promptly filed a report on the CPAN. Hopefully it gets included in the next release very soon. As for the Blosxom feedback plugin, tweaking it to use the new feature in Net::Akismet was a cinch, so only the real test (of incoming spam filtered by TypePad) remains. Hopefully it does work. [PS: Looks like the first line in blosxom posts don't like package-like names such as Net::Akismet (during editing my blog title disappeared on the render!) Needs to be looked at later...]

I am off to Brazil tonight, first to the city where some locals like to dress their dogs up on Sunday and take them to the park (Porto Alegre and I will be there until June 15th) and then I will be in S o Paulo (from June 15-20th). I would love to get together with the Debian/Free Software folks while there so drop me a line so that we can arrange something. In a day or two I will also post some more details about my trip.

The serial port is still the way to access network components out of band. It is slow, but reliable, and remarkably well standardized. It does not have technical whiz-bangs that can fail when one needs things to just work. That makes it the natural way to access critical infrastructure and still being sure that this access vector still works when most other things are down. Every communication link has two sides, so there is a market for devices with a network link and a bigger number of serial ports to connect the actual devices to. Commercial vendors have a broad choice of serial console servers. Most of them, especially the small products with five to ten ports, are quite expensive, so I have been investigating how do build a serial console server with el cheapo hardware. USB comes to mind here, of course. The hardware side is actually quite easy: A seven-port USB hub, and seven USB-to-serial adaptors (using the widely-deployed Prolific PL2303) are easily purchased for well below a hundred Euros, and naively connected. In my test setup, connected to the hp compaq nc8000 that my blog readers should know only too well by now, the hub does not even need to have its power supply connected. The notebook can power the hub and the seven adaptors just fine. When the UMTS card is plugged in, the ttyUSBx device nodes appear in the order of plugging in the devices. When the system is booted, the order is not very predictable, so one needs - again - udev to give predictable device node names. udevinfo is an important tool to obtain the data set of an USB device which is available to match a device and to act appropriately when it is connected. udevinfo sorts the devices into a tree and shows the relationship of the devices, which device is “behind” which other device from the system’s point of view. udevinfo’s output starts at the leaf of the device tree and shows the information for each node up the tree until its root is reached. One pitfall is that one can only match against the leaf and _one_ other node more up the tree. So you cannot do matches like “the pl2303-based device connected to port 3 on hub 2-3 will be designated USBserial3”. If you try this, your rule will silently be ignored. This is a major turn-off in udev’s implementation. I didn’t try it on sid, but etch definetely shows this behavior. So one can only match like “the tty on the USB subsystem connected to port 3 on hub 2-3 will be designated USBserial3”, but that’s probably as good as it’ll get. The cause for my hub having only seven ports clearly shows itself when one looks at the udevinfo outputs of the fully equipped USB hub: The adapters are connected to ports 1, 2, 3, 4.1, 4.2, 4.3 and 4.4. The seven-port hub is actually two four-port hubs in a single case, with the second one connected to the first one’s port 4. This reflects itself, of course, in the udev rules necessary to address the adapters by the hub port they’re plugged in:

SUBSYSTEM==“tty”, SUBSYSTEMS==“usb”, DRIVERS==“usb”, \
   KERNELS==“*-*.1”, \
   SYMLINK=“USBserial1”
SUBSYSTEM==“tty”, SUBSYSTEMS==“usb”, DRIVERS==“usb”, \
   KERNELS==“*-*.2”, \
   SYMLINK=“USBserial2”
SUBSYSTEM==“tty”, SUBSYSTEMS==“usb”, DRIVERS==“usb”, \
   KERNELS==“*-*.3”, \
   SYMLINK=“USBserial3”
SUBSYSTEM==“tty”, SUBSYSTEMS==“usb”, DRIVERS==“usb”, \
   KERNELS==“*-*.4.1”, \
   SYMLINK=“USBserial4”
SUBSYSTEM==“tty”, SUBSYSTEMS==“usb”, DRIVERS==“usb”, \
   KERNELS==“*-*.4.2”, \
   SYMLINK=“USBserial5”
SUBSYSTEM==“tty”, SUBSYSTEMS==“usb”, DRIVERS==“usb”, \
   KERNELS==“*-*.4.3”, \
   SYMLINK=“USBserial6”
SUBSYSTEM==“tty”, SUBSYSTEMS==“usb”, DRIVERS==“usb”, \
   KERNELS==“*-*.4.4”, \
   SYMLINK=“USBserial7”

These rules will only work for a similary structured hub that is directly connected to the notebook. If there are more hubs in between the “final” hub and the host, the address matched against in the KERNELS matches are going to have a different structure. In the test setup, the first two parts of the address needed to be wildcarded since these addresses keep changing when the host is booted or the hub plugged out and in. So I guess that these udev rules are probably going to fail miserably when more hubs and/or USB-to-serial adaptors are connected. But if one does not do too many changes, things are just fine, and it is possible to put numbers on the USB hub ports and be sure that the USB-to-serial adaptor connected to port 4 is going to be /dev/USBserial4 in the host system. I tried plugging in and out the adaptors in random order, unplugged and plugged the hub itself, booted the host, and the relationship between the port and the device node was stable. In the test environment, I only tested one adapter at a time, but all these tests were successful as well. I guess that many more of these adaptors will eventually need a powered USB hub, but with seven adaptors on a single hub, the power from the USB host is sufficient to live without extra power on the hub. And, I guess, there is some hard limit for the number of USB adapters being used, and some soft limit when managing the ports and adapters is going to get harder. But, I think that a site in need of more than, say, sixteen serial ports on the console server can afford a “real” console server from one of the major vendors, which can be accessed via ethernet, UMTS, ISDN and whatever you can think of. This concludes the hardware part of my serial console server for the poor. Tomorrow, I’ll blog about the software side needed on the host to allow the serial ports to be accessed from the network while still being reasonably secure. The next article will involve ssh, /etc/passwd shells, /etc/shells, a small perl script, ser2net and telnet. And, shell escape is the cue word for grey hairs sprouting on my head.

Nowadays it seems that most serious mail servers (IE mail servers suitable for running an ISP) use one file per message. In the old days (before about 1996) almost all Internet email was stored in Mbox format [1]. In Mbox you have a large number of messages in a single file, most users would have a single file with all their mail and the advanced users would have multiple files for storing different categories of mail. A significant problem with Mbox is that it was necessary to read the entire file to determine how many messages were stored, as determining the number of messages was the first thing that was done in a POP connection this caused significant performance problems for POP servers. Even more serious problems occurred when messages were deleted as the Mbox file needed to be compacted. Maildir is a mail storage method developed by Dan Bernstein based around the idea of one file per message [2]. It solves the performance problems of Mbox and also solves some reliability issues (file locking is not needed). It was invented in 1996 and has since become widely used in Unix messaging systems. The Cyrus IMAP server [3] uses a format similar to Maildir. The most significant difference is that the Cyrus data is regarded as being private to the Cyrus system (IE you are not supposed to mess with it) while Maildir is designed to be used by any tools that you wish (EG my Maildir-Bulletin project [4]). One down-side to such formats that many people don’t realise (except at the worst time) is the the difficulty in performing backups. As a test I used LVM volume stored on a RAID-1 array of two 20G 7200rpm IDE disks with 343M of data used (according to “df -h” and 39358 inodes in use (as there were 5000 accounts with maildir storage that means 25,000 directories for the home directories and Maildir directories). So there were 14,358 files. To create a tar file of that (written to /dev/null via dd to avoid tar’s optimisation of /dev/null) took 230.6 seconds, 105MB of data was transferred for a transfer rate of 456KB/s. It seems that tar stores the data in a more space efficient manner than the Ext3 filesystem (105MB vs 343MB). For comparison either of the two disks can deliver 40MB/s for the inner tracks. So it seems that unless the amount of used space is less than 1% of the total disk space it will be faster to transfer a filesystem image. If you have disks that are faster than your network (EG old IDE disks can sustain 40MB/s transfer rates on machines with 100baseT networking and RAID arrays can easily sustain hundreds of megabytes a second on machines with gigabit Ethernet networking) then compression has the potential to improve the speed. Of course the fastest way of transferring such data is to connect the disks to the new machine, this is usually possible when using IDE disks but the vast number of combinations of SCSI bus, disk format, and RAID controller makes it almost impossible on systems with hardware RAID. The first test I made of compression was on a 1GHz Athlon system which could compress (via gzip -1) 100M of data with four seconds of CPU time. This means that compression has the potential to reduce the overall transfer time (the machine in question has 100baseT networking and no realistic option of adding Gig-E). The next test I made was on a 3.2GHz Pentium-4 Xeon system. It compressed 1000M of data in 77 seconds (it didn’t have the same data as the Athlon system so it can’t be directly compared), as 1000M would take something like 10 or 12 seconds to transfer at Gig-E speeds that obviously isn’t a viable option. The gzip -1 compression however compressed the data to 57% of it’s original size, the fact that it compresses so well with gzip -1 suggests to me that there might be a compression method that uses less CPU time while still getting a worth-while amount of compression. If anyone can suggest such a compression method then I would be very interested to try it out. The goal would be a program that can compress 1G of data in significantly less than 10 seconds on a 3.2GHz P4. Without compression the time taken to transfer 500G of data at Gig-E speeds will probably approach two hours. Not a good amount of down-time for a service that runs 24*7. Particularly given that some time would be spent in getting the new machine to actually use the data. As for how to design a system to not have these problems, I’ll write a future post with some ideas for how to alleviate that.

• [1] http://en.wikipedia.org/wiki/Mbox


• [2] http://en.wikipedia.org/wiki/Maildir


• [3] http://en.wikipedia.org/wiki/Cyrus_IMAP_server


• [4] http://doc.coker.com.au/projects/maildir-bulletin/

Share This

Of recent simple/guilty pleasures.. Wading in the creek and browsing on blooming watercress.
Emergency repair of my broken sandal.
The most yummy cherries from Ken's tree.
Gogol Bordello - Super Taranta!
Lamb stew with pickled lemon and fresh mint.
Fixing my broken sandal right w/ metal reinforcement.
West 10 LDN.
Homemade mango lassi. (At least it's not bacon.)

I ogled with an ASUS EeePC since it was announced, but didn’t want to order one abroad. So I waited until they became available in Switzerland. Digitec is the official EeePC importer for Switzerland and seeems also to be the moving power for yet to come the Swiss localisation of the EeePC. But initially they only offered imported EeePCs with German keyboard layout, but since I really got used to the US layout, I didn’t want to buy ay new laptops or keyboards with German layout. When asking them about US layouts they told me they won’t import from the US and that their competitor Steg Computer is importing US models. But I wasn’t comfortable with Steg and EeePCs also were more expensive there, so I hesitated ordering at Steg. So it was quite unexpected for me when US models showed up on digitec’s website. (Interestingly I never received any mail from their advertised EeePC newsletter, not even when they added 2G models t their repertoire.) So at the end of March (and therefore later as most other geeks ;-) I ordered an ASUS EeePC at digitec. For me, white laptops look like Macs (and Macs are for sissies or masochists ;-) — so I had no problems to decide that I want a black EeePC with US keyboard layout. 2G was to small for my purposes (and also not that much cheaper) and 8G not available. So I went with the 4G, since Debian doesn’t need so much space if you choose the right packages (i.e. neither or at least not that much of GNOME or KDE ;-). I preferred the 4G over the 4G Surf because of the bigger battery capacity (and not because of the webcam which I consider funny but useless:-). Initially the delivery date was set the 28th of March. Then it was subsequently set to “beginning of April”, “mid of April”, “end of April” and “beginning of May”. It finally arrived on 8th of May. In the meanwhile there were reports that even the 4G has been equipped with the smaller battery of the 4G Surf because of some battery shortage after some battery plant burnt down. But fortunately the delivery problems with black 4G US models doesn’t seem to have its reason there and my 4G has a 5200 mAh battery (at least according to its label and ACPI). I also ordered a 2 GB bar of Corsair ValueSelect RAM so that I can pump up the RAM of my EeePC by factor four (for about 10% of the price of the EeePC itself) resulting in having half as much RAM as disk space. Well, I guess, I won’t do suspend to disk in that configuration… ;-) The original Xandros based Linux only noticed 1 GB of the installed 2 GB as already noted on many other places in the web. But that doesn’t really matter, since it only lasted until I found out how to restore it from DVD in case I want to sell the EeePC later (e.g. for getting the successor). It’s fine for novices, but Linuxes feel strange if you can’t even get a console or a terminal with a command line. ;-) The Debian EeePC installer worked fine except that it argued over a checksum error on our mirror which wasn’t reproducable after the installation anymore. I’ve chosen the EeePC to be my first (nearly) pure Lenny installation — compared to the three machines running Sid (i386, amd64 and kfreebsd-i386). It though has a few packages from experimental (mostly xulrunner-1.9) installed. As window managers I have installed ratpoison, FLWM and FVWM. ratpoison — best described as screen for X (although you can’t detach and reattach) since it’s my personal preferences for being productive without big screen resolutions and flwm for a low-resource window manager which can be used intuitivly by both, geeks and non-geeks (and still doesn’t look like Windows at all ;-). And FVWM is installed because it’s my default window manager on all machines with bigger or multiple screens – to be able to compare it with my usual environment. As web browser I’ve got Opera as primary browser (as everywhere else, too) and Conkeror (the EeePC is the test-case for upcoming Debian package of Conkeror) as well as links2 and lynx on the (nearly) text-only side on it, although I need them seldomly. As office programs (as I would ever need some ;-) I’ve got AbiWord and Gnumeric installed since I already use a few GNOME applications (e.g. Network Manager, Twitux, etc.) and OpenOffice.org would take up 170 MB more disk space (then including OOo Draw and OOo Impress) and Siag Office is no more in Debian since years. (Initially I had OpenOffice.org installed instead of AbiWord and Gnumeric until I noticed that I need some of the GNOME libraries anyway.) I also decided that I will need LaTeX then and when so TeX Live also got its chunk of the 4 GB of disk space. I also have a bunch of games on the EeePC. Unfortunately there are a few games which don’t work well on the EeePC due to it’s resolution being smaller than 800x600, so I deinstalled them already again, e.g. I can’t play Cuyo on the EeePC but flobopuyo. Sauerbraten segfaults, but Doom (prboom with freedoom WADs) works fine. Further non-working games unfortunately include Battle of Wesnoth and XFrisk. Still, although quite some parts of GNOME and GNOME Office, TeX Live, ScummVM with Flight of the Amazon Queen and Beneath a Steel Sky, GNU Emacs 22, Iceweasel 3 (aka Mozilla Firefox 3), Icedove (aka Mozilla Thunderbird) and the Iceowl (aka Mozilla Sunbird) are installed, only 2.3 GB of the available hard disk space are used by the installation (i.e. without my home directory). Oh, and btw: Although except the very compact and a little bit wobbly keyboard the EeePC doesn’t feel really small to me (I’ve got quite small hands), but when I sat down in front of my 14” ThinkPad T61 after a day or two with EeePC, the T61, — especially screen and keyboard — felt huge as if it would be some 17” or even bigger notebook. ;-) OTOH I still think that a 1920×1200 (which means nearly four xterms in a row) resolution on a 14” notebook would be a good idea, especially compared to the 1440×900 (which means nearly three xterms in a row) my T61 has. ;-) Personal Resumée after one month Pro EeePC

• It’s geeky. If you show up with it, people want to lift it to see how much it weights and try the tiny keyboard. They’re surprised that 800x480 aren’t that small and that the performance isn’t that bad.
• Very compact and robust. With the T61 I always fear that its edges are too close to the the outside of my backpack and could be damaged that way.
• The price of course: CHF 499 at digitec (plus CHF 54 for the 2 GB RAM)
• Runs Linux ex factory. So yu don’t have to expect that many driver hassles.
• RAM upgrades are very straight forward and do not void the warranty. (BTW: The sticker over one of the screws which probably should prove the integrity can be removed and placed again easily… :-)
• The weight. 0.92 kg can be easily held wit one hand, also because of less leverage effect as with full-size laptops.
• The SSD despite it’s size. Being such lightweight you accelerate the EeePC unmindfully even when it runs. But it doesn’t matter, at least not to the hard disk. And it boots very fast, especially after the usage of insserv.
• Intergrated Ethernet network interface. (Hey, the MacBook Air hasn’t a builtin one, not even an external shipped with it! ;-)
• Three USB sockets (the MacBook Air has only one which is usually taken for the Ethernet network adaptor — Ok, with the EeePC usually one is taken for the Bluetooth dongle, but then are still two sockets left… ;-)
• Great contrast on the builtin screen.
• External VGA output. You have to configure X.org to make the virtual screen big enough (e.g. 2048×2048 instead of the default 800×800).
• Despite its size quite a lot of space for modifications inside the case. Especially a bluetooth case mode should be no big deal.

Contra EeePC

• The keyboard: keys smaller than usually (ok, wouldn’t work otherwise ;-), very wobbly, no precise contact depth (pressing Shift and Fn with one finger often doesn’t press Fn right), not all keys on the same plane, unusual offsets between the key rows (the number row has about half a key width offset to the left) or position of keys (I often hit Ins when I want Home, Del when I want Backspace or Fn when I want Ctrl, the ~ key is between Esc and F1, Up is between Slash and Right Shift, etc.)
• The position of the power button: It’s exactly where I want to put thumb when holding the EeePC solely with the right hand. And yes, I already accidentially switch it off several times because of that. For luck the button doesn’t work at all when the lid is closed, because you still can reach it easily while it’s closed.
• The mouse button(s): It only has two buttons which are one part you can press more to the left and more to the right side. And if you press it in the middle you randomly get either a left or a right click. You have to press it very hard to get both clicks at the same time. (e.g. to emulate a third middle button). Three separated mouse buttons would have been way better.
• It has (only) a touchpad. I definitely prefer thumbsticks as the ThinkPads have, but got used to it, though. I have seen worse touchpads, too.
• The noisy and not very precisely beared fan, which seems to strife its environment when the EeePC is being accelerated. Whih happens quite often because of its size and weight and because the SSD doesn’t mind acceleration. The fan does mind – and you hear it. :-(
• Some programs need minimum 800x600 resolution to work well.

Pro ThinkPad (in direct comparision)

• Thumbstick.
• One of the best laptop keyboards around.
• Three easy to distinguish mouse buttons.
• Even ressource-hungry programs like Liferea work fine.
• Quite big screen resolution (1440×900).
• Bigger battery, space for additional batteries.
• Could be a workstation replacement.

Pro Lenny on the EeePC

• The installer image of the Debian EeePC Project works out of the box. All necessary drivers are available, if you include the non-free repositories and the eeepc.debian.net repositories.
• Stable enough for daily use. (IMHO Debian Testing – and even Debian Unstable – is more stable as many other distribution’s stable releases, e.g. those from SuSE.)

Con Lenny on the EeePC

• My favourite feed reader Liferea has changed its cache format since the version in Debian Etch, so I can’t sync Liferea caches between my Debian Etch running T61 and the Testing running EeePC. Well, fortunately the version of Liferea in Debian Etch still works on Debian Lenny, so I just downgraded the package to the version from Etch and set it on hold. I don’t use it on the EeePC though since it needs way too long to start (about 10 to 15 minutes compared to 1 to 3 minutes on the T61)

Summary I’m very happy with the EeePC and I didn’t expect that it would replace my 14” ThinkPad in so many (but still not all) situations. :-)

There has been some hype around samba this week. On May 21st, the Samba Team released Samba 3.0.29, an update from their stable branch. The Debian package maintainers quickly built and uploaded a package for unstable/lenny the very same day. Then, on 27th, we got notified of CVE 2008-1005, which affects both etch, lenny and unstable (not the 3.2 versions we have in experimental). I contacted the security team and, after some brief discussions, I uploaded with their blessing, a fixed package to stable-security (3.0.24-6etch10). Then, I immediately uploaded samba 3.0.30 to unstable (1:3.0.30-1), that version being the Samba Team response to the security issue. All this lead to DSA 1590. Up to now, everything perfect. In the meantime, Karolin, the Samba Team's release manager announced the Releace Candidate 1 of Samba 3.2.0. So, yesterday (Saturday), I started building it....which succeeded. Then I started to screw up..:) Instead of uploading that version to experimental, as planned, I uploaded 1:3.2.0~rc1-1 to unstable. Yes, AGAIN (I already did that in April). There's no excuse for that, except distraction and failure to use our tools properly ("dch -r"). Thankfully, I noticed that nearly immediately, but not immediately enough. So, I had to re-upload 3.0.30 to unstable (which is urgent: that's a security fix) and increase the epoch (we already had one as this is the second identical screwage): 2:3.0.30-2. Sorry, autobuilders... Yesterday evening, I uploaded 3.2.0-rc1 again to experimental (2:3.2.0~rc1-2). Then, finally, I went on the last bit of remaining work: spend some time on Jelmer Vernooij's samba4 packages. Jelmer is one of the two lead developers of Samba 4, a huge masterpiece still under heavy delveopment. To give it more exposure, it is planned to upload it a few times in experimental, then move it to unstable, block it so that it does not enter testing, and make some noise about this. I finally uploaded samba4 this morning (triple checking that I was uploading to experimental!) and samba4 4.0.0~alpha4~20080522-1 is now waiting for NEW processing (which might take time: this is a big piece of new stuff). I'm sad for the screwage because, apart from it, that was nearly a perfect process. But, anyway, I'm still proud of the result: 4 successful uploads for samba in a little more than a week (which included 4 day away). It could even have been 5 as the samba version in sarge is affected by the security issue, but we don't support sarge anymore.

I’ve spent more or less the last few days of spare time trying to figure out why gcc-4.3 built kernels were so unhappy on parisc. Basically the symptom was that any IPv4 networking operation would only complete once and a while, for example, ping would drop 90% of packets. This turned out to be a really troublesome bug to track down, and the fix was only 7 characters long. gcc-4.2 wasn’t problematic, so that provided an interesting base. A bit of thinking ruled out some obvious parts of the kernel that would likely not be an issue. For instance, ARP appeared to be fine, so it likely wasn’t an issue at the network driver level. So rebuilding net/built-in.o on gcc-4.2, copying it to the gcc-4.3 tree, and rebuilding the tree using it resulted in a working kernel. Ok, excellent, we know it’s likely an issue in net/, what else can we rule out, and what do we know? ICMP is affected, so it’s probably not a TCP problem… Rebuilding the kernel with IPv6 enabled, and testing ping6? Ok, works. So it looks like an IPv4 issue. Test that assertion… yup, net/ipv4/built-in.o compiled with gcc-4.2 works. Ok, peachy. What now? Bisecting the contents of the directory results in ip_output.c being the problematic file… Not all that helpfully, the differences between the code generated by 4.2 and 4.3 are extensive. Well, ok, let’s try turning off a variety of the added compiler options… nope, no luck, but the file works when compiled at -O0. Next, I bisected the file until I found the problematic function (unfortunately for me starting in the middle, it ended up being the first function in the file.) Which was in a chain of inline functions, eventually calling some architecture specific inline assembly for ip_fast_csum. Ok, that looks like our canary in the coal mine… Look it up… SIGH. The routine touches memory, but didn’t have “memory” in the list of clobbers. Adding the clobber and everything magically works again. Wasn’t that a party? [ Of course, this makes things sound almost easy, except that at around 10 minutes to boot a test kernel, reboot, and boot a working kernel, this gets extremely tedious. I also didn't bother to talk about how many hours I probably wasted twiddling compiler flags trying to figure out which optimization pass might be broken... ]

Busy times, despite being on holiday. Mostly this has been doing "business" work, and fiddling with self-promotion. But despite this I managed to find time to write some extremely useful new Lisp:

• Sensible (new) window placement for GNU Emacs

Anyway very little time over the coming week will be spent online. All being well. Still enjoying playing with my (loaned) Nokia 770 - maybe I'll get another one of my own eventually. ObQuote: 30 Days Of Night

OK, so I've spent my last money on the One Mini A110 subnotebook recently. Yep, yet another ASUS Eee PC clone, but this one has the great benefit of costing only 199.- Euros and has similar specs as the Eee PC 2G Surf (700), I think. This is really a great little machine as far as I can tell. It's a VIA C7-M ULV 1GHz with 512MB DDR2 RAM and a 2 GB Solid-State-Disk (SSD), 7" screen at supposedly 800x480, VGA out, card reader slot for SD/MMC/MS, 2x USB, wireless, modem, audio. No webcam, no bluetooth. Yesterday I created a wiki at a110wiki.de (for the A110, but also the A120 from the same vendor, which has a 4 GB SSD), where A110 users can collect information, HOWTOs, photos, etc. There's already quite some content there, especially some early tutorials and photos on the inner workings of the A110. Today I've installed a stock Debian unstable distro on the SSD with 2.6.25 kernel, and I'm currently checking which parts of the hardware work out of the box, and which need further fixing. There's a a bunch of source code tarballs and patches on the vendor website, but most of it seems to be meant for 2.6.22, we'll see if and/or how much work it'll take to merge all this upstream (if it's not already done)... My Debian Installation HOWTO is also available from the wiki, of course; I'll add more info and photos during the day. Now for all interested parties: The vendor of the A110 has (again) announced a special weekend offer (valid until Sunday, June 1, 2008, i.e. tomorrow) where they'll sell the A110 for 199,- Euros again, the regular price will be 229,- Euros after that. So if you're thinking about buying one, now is probably the right time. Check the wiki for issues which are important to you, some quirks remain at this point (but will probably mostly be figured out sooner or later), e.g. the wifi seems to have issues (the vendor said they'll send a driver update to all affected customers), the RAM is builtin and can't be upgraded, and some other, more or less important issues, depending on what you expect from the laptop. For real-time communication there's also the #a110 IRC channel on Freenode.

One of the downsides of writing my thesis last year was that focusing on a technical subject for approximately 16 hours a day left me almost entirely unable to relate to people. The irony in this is that losing the ability to socially relate tends to result in you assuming that you're fine and everyone else is just behaving bizarrely, which makes rectifying the situation rather difficult. In an attempt to avoid this I have written some software, because dealing with the symptoms of a problem is always better than dealing with the root cause and technology is always the appropriate solution to social issues.

The aim was to send myself an email once a week that I'd actually have to read. This is achieved by running the script with the generate argument. This sends an email with an appropriate reminder message (something along the lines of "Are you sucking? Really? Are you sure? Is everyone around you suddenly getting annoyed at you for no obvious reason?", and so on) and a bunch of embedded characters randomly spread throughout it. Running the script with the check argument will send the email again if a valid response hasn't been received. Those can be stuck in cron. The final part is to add a procmail or whatever rule that passes replies back to the script with the validate argument. These replies should include a line containing all the embedded characters (order doesn't matter, but if there are multiple occurances of a character than the reply must include that number of occurances). If a valid reply is received then no further emails will be sent until the script is run with the generate argument again.

Also: My perl sucks.

I have long wanted a pet pig but there was always the size and space problem. But now this problem has been solved. In fact, they are so small, you can probably get 2 at once.

Really, who cares? 1. How much petrol do people actually use, anyway? People whinge and bitch and moan about petrol going up a few cents, and queue up for ages to try to buy petrol at the low point of the weekly price cycle - and for what? A tank will hold less than 100 litres. Typically around 50, but let’s say it’s 100 litres. That means that a price difference of 1 cent is worth a whole $1.00. A price difference of 5 cents is a measly $5.00, less than the price of a cheap bought lunch. For the average driver, they’ll buy 100 litres once or maybe twice per week. Who gives a damn? If $1.00 or even $5.00 makes such a difference to someone’s budget then they’re in serious financial trouble anyway - so much trouble that they shouldn’t even think about having a car, because they can’t afford it. Here’s a novel thought: they could drive less, make their kids walk to school, catch public transport, ride a bike, walk to the milkbar rather than drive, make sandwiches to take to work/school, and so on. They could also buy less of the worthless crap they buy (like biscuits and cakes and bottles of coke and other rubbish). There are thousands of things people could do so that they don’t have to give a damn about a few cents per litre. Even better, if people reduce demand enough, they can seriously hurt the speculator bastards who have driven oil prices up so much in recent months….at least a quarter of the current price per barrel of oil is due to commodity speculators driving the price up. Hit the bastards where it hurts, drop demand so much that they lose serious money. If the price of petrol bothers you, don’t whinge, get revenge. Actually, I’m entirely unconvinced that the general public actually care all that much about petrol prices anyway. It looks and feels much more like an astro-turfing campaign by the oil companies and petrol distributors - especially the recent crap about reducing the excise by 5c/litre, anyone can see that if the government does that the petrol companies will, within weeks, increase prices so that THEY get the 5c/litre rather than the government, resulting in yet another transfer of wealth from the public purse to private corporations. Same for all the bullshit about the fuel price watch program - it’s obvious that the opposition to that comes directly from the petrol companies who don’t want buyers to have good information to base their purchasing decisions on. It’s also a useful distraction and pretend-debate for the government and the opposition - they can rant and rave and score points over a trivial, bullshit non-issue like this, and nobody will notice that nothing of any real substance or worth ever gets debated in parliament…and the media are either colluding in this or are too stupid to avoid getting sucked in. 2. We have the fourth-cheapest petrol in the world. So all this moaning is not about petrol being more expensive than it should be, it’s about not being quite as unreasonably privileged as we were in the past. 3. Oil prices are *inevitably* going up, they’re *never* coming back down. Get used to it, it’s only going to get worse from here - much worse. Instead of endlessly whining about the inevitable, focus on alternatives - like *DEMANDING* that the government start paying more than just empty tokenistic lip-service to the idea of alternative/renewable energy sources. 4. IMO, the sooner petrol hits $5.00 per litre or more, the better. By then we’ll really have to have functional alternative energy sources in place. Because if we don’t, we’re completely screwed. Syndicated from Craig Sanders' Errata: Tech Notes and Miscellaneous Thoughts I’m sick of all the whinging about petrol prices

I knew better when I neither advertised nor used my IITG Alumni forwarding email address, and I suppose I'll not do that, ever.

For one, the ID given was ridiculous, connected to my name in a rather weird fashion with a number thrown into it and nobody bothered to reply when I asked if I could change it. And now the domain-name part of the email ID has been changed forcing people to tell all their contacts about the change, but this takes the cake -- the service has been moved to Hotmail with 2GB free space.

Huh! Thanks but no thanks.

I really disapprove of such widespread services (which should really not have a commercial angle to them) being taken over by the Googles, Ciscos and the Microsofts of the world.

Several stories on NPR today have featured interviews with Democratic voters in Florida and Michigan. Many of them were mad about the situation, but mad at their state democratic parties. Many of them did not vote because they were told their vote would not count, so now they are upset at these efforts to count the vote from these states.

Meanwhile, there is a very interesting post about how Hillary may want these delegates to remain unavailable to her, as a way to continue pressing her case all the way to the convention. Sigh.

While I have your Attention, one of the most interesting ARM projects at the moment: beagleboard . There is _huge_ variety of ARM developer boards available, but this one has a couple of really interesting bits

• Powered by OMAP 3530, a 600MHz ARM Cortex A8 + kitchen sink chip. Most boards are either expensive or have a "bottom-of-line" cpu.
  
• Didn't I complain that TI isn't open enough? Well, since then TI now has released thousands of pages documentation for OMAP3, made omap 35xx available or purchase for anyone, and is even working to get DSP and 3D bits of OMAP3 available. And they go further - beagleboard documentation (link at bottom of elinux wikipage for boeagleboard) has everything including schematics.