I've produced a 2.6.26 based kernel with the DMA engine patches from Intel which I intend to support throughout the lifetime of Debian lenny. The Thecus N2100 has considerably better hard drive performance with this kernel. However, the patches are experimental and not in the mainline kernel (some background on this issue). I haven't seen any data corruption with the current version of the patches, but please watch out for problems if you decide to install this kernel. Detailed instructions are available.

Debian Developer Peter De Schrijver dropped by tonight and left with the Atari stuff, but there's still more stuff left.

As the title of this blog post indicates, I've got some hardware to sell.

Having recently demoted my old ThinkPad 240x to Debian/Testing testbed, I wanted to re-install Debian from scratch on it, to make sure that I would have a clean reference system to work with. However, this being a very old ThinkPad model, there is no CD-ROM drive to speak of. The only external means of booting is with an optional floppy disk drive. Sure enough, there exists a nice helper called SBM (included in the utility folder on all Debian CDs since several releases) that adds CD-ROM boot support to any BIOS. Instead, My idea would be to perform the reinstall using the USB stick version of Debian-Installer, bootstrapped by SBM on the floppy disk. Does anybody know of an SBM release that adds USB boot support? If not, is there any other tool that performs a similar trick?

I've just started a new job, so I decided to take a few days holiday in between and work on something that's been on my todo list for way too long now -- making the debian-installer work on the D-Link DNS-323. After a couple of days of work, I've just finished off the install of Debian on my DNS-323, which I initiated by loading a firmware image into the web interface of the stock firmware, and then SSHing into the machine at the appropriate moment. What this means is that anyone with a DNS-323 can install Debian on it. I think that's worthy of a small, quiet "woo hoo!"... Looking back now, it seems to have been a fairly simple and straightforward operation, but I can remember that it didn't look so simple when I started a week ago. So, in the interests of perhaps short-cutting someone else's adventure into the world of d-i hacking, I'm writing everything up while it's fresh in my mind (the benefits of being on holidays -- plenty of time to write long blog posts). Alternately, if anyone has a random device they'd like to see d-i on but doesn't have the inclination to do it themselves, feel free to send me one and I'll do it for you. Before I begin, I've got a few "shout outs" (I think that's what the cool kids are calling it these days) to people who've helped me along the way. First off, Martin Michlmayr has answered innumerable dumb questions from me, and I think wrote most of the parts of d-i that I've extended -- it's fair to say that I'd have had no hope of doing this without him. Thanks also to the people in #debian-boot and #debian-arm for answering questions and putting up with my frequent bouts of self-congratulation whenever I passed the most miniscule milestone. Finally, everyone who has put work into d-i has my thanks, too -- it's not perfect, but it's a damn sight better (both to use and also to hack on) than any other installer I've ever met. So, without further ado, off we go... Work out how to get a console Unless you are a guru of unbelievable skill, you will undoubtedly not do everything quite perfectly the first time, and you'll want to see the kernel/init boot messages, and maybe in some cases try some investigation and diagnostic work. For that, you're going to have to have some sort of console access. If the device doesn't have a full screen/keyboard thing going on, the chances are you'll almost certainly end up with a serial console. A few devices have a network management thingo that will give you a console, usually over VNC or some sort of horrid Java applet, but I've only ever encountered that in rackmount servers, which have a keyboard/video interface anyway... In theory, I suppose, the kernel could provide a network console, but I've never heard of such a thing being attempted, and Google is not helping me out. I might add that to the todo list as a future hacking project... On the DNS-323, it was a serial console that was needed. Like a lot of the embedded devices I've seen, it didn't quite talk RS-232, so I needed an adapter (I got a TTL-232R-3V3 USB-to-3.3v-serial adapter from a local electronics supply place, which worked perfectly with Linux as soon as I plugged it in). I needed to solder a few wires to a connecter inside, and connect that up to the USB doohickey, but it all came good in the end. The chances are someone's done a similar job for your device of choice, so a search for things like "devicename serial console" will almost certainly pay off. Work out how to load and boot a kernel/initrd Your development work will involve booting weird kernels and initial ramdisks to make everything work; you need some way of stuffing those into the device and booting from them. Everything has a boot loader of one sort or another; working out what you've got and how to make it sing and dance is the ultimate quest here. How this is done will vary greatly from device to device; the WRT-54GL, for example, waits for a tftp connection for a couple of seconds on startup, which you can use to send a new firmware; many other devices have a boot loader that you have to explicitly control (via the console), but it will make a tftp connection out to another machine if you ask it to. Some devices you just need to load the data in via serial cable (at 115200bps it's bearable; at the 9600bps I've heard some devices work at, it would be tres painful). The DNS-323 runs uBoot as the boot loader, which will do a tftp request by default. However, D-link, or Marvell, or someone in the decision-making chain for this thing decided to knobble it and removed most of the useful commands, so sending the thing via serial port is the only option. Since writing to flash takes a pile of extra time, I found (eventually) that you can just load the data into RAM somewhere and boot from there, without needing to write it to flash (also handy to avoid wasting precious write cycles), since you can tell uBoot to boot a kernel located anywhere in the address space. Obviously you need to reload the kernel/initrd on every boot if you don't write it to flash, so if you've got a "stable" kernel or initrd that you think you'll be using for a while (when you're testing the other item) you should flash it then. One note on uBoot, that took me far too long to work out -- you can't just stuff a kernel fresh off the Makefile in and assume it'll work -- uBoot needs a special header prepended that tells it all about what you're loading (architecture, file type, compression method, etc). You "wrap" a file in this uBoot header with the "mkimage" command (in the uboot-mkimage package in Debian). Incidentally, if you need to remove the uBoot bits from a file, just strip the first 64 bytes off -- that's all the uBoot header is, so something like this will do nicely:

 dd if=file.uboot of=file bs=64 skip=1

A final uBoot warning: it's fairly important to specify a "load address" for the files; if you get them wrong, your kernel and initrd may or may not boot (I never quite got the hang of why some wrong values worked and some didn't). If your device uses uBoot, and you have the ability to extract the uBoot-enabled kernel and initrd from a vendor-provided firmware image, you can use mkimage -l to inspect what all the values need to be for your own kernels and initrds. Just stick with them. Does Debian support your hardware? Obviously, if you want to run Debian on something, Debian has to support that hardware. The easiest way to test this out is to try an install. For this, you'll need to retrieve an appropriate kernel and initrd pair for the installer. Some arches, like i386 and amd64, only have one kernel and initrd for the installer, so you just have to choose if you're going to netboot, or do a full CD install, or whatever. Other arches, though, like arm, have subtly different images for different machines. There are two reasons they vary: firstly, they often need to split into subarches, where they all share a general CPU architecture but there are enough differences in the hardware that they're not all supportable by the same kernel. At a more fine-grained level some different machines of the same sub-architecture need differently formatted firmware images to boot. On ARM, in particular, it's pretty common to need to prepend a "device ID" to the kernel image so that the kernel knows what sort of machine it's booting on, which means that every machine typically needs it's own kernel image, regardless of any other issues with firmware formats. Choosing the sub-architecture should be relatively straightforward, if you know much about the machine you're targetting. Picking a machine type can be a bit harder, but again, if you know what your boot loader needs, it shouldn't be too hard to find a kernel/initrd from the existing machines in your subarch that you can mangle to fit. Load up your kernel/initrd into the device, boot it, and see how far it gets. You might get lucky, and the kernel inits, your hard drives are detected, your NIC is initialised, and you're off and running without further ado. Or you might not be so lucky. The worst case is that the kernel doesn't even get as far as loading the initrd -- it might not print anything at all, or the kernel might hang part way through the boot. This is likely to require a fair amount of debugging fun, as initial boot failures get a bit tricky. A better situation is where the kernel boots OK, and d-i starts, but something in the install process falls over. This can either be a kernel/driver problem, or a d-i problem. Either way, since d-i has started, you're likely to be able to get a shell and do some debugging. In order to make d-i work, you need to have somewhere to install to (disks, usually) and a source of packages to install from (CD/DVD if you're on a suitably large device, or the network otherwise). These are the two key ingredients you need; most everything else is stuff that ranges between "nice to have" and "critical" for operational purposes, but which has absolutely zero impact on your ability to do the install, so we'll ignore it for now. For the DNS-323, I had a few kernel problems (which I'd been warned about by Martin before I started) -- the NIC wasn't initialised with it's MAC address, which meant it was running around my Ethernet screaming "I am 00:00:00:00:00:00! Ph33r m3!", and the SATA controller just didn't seem to exist at all. These were kinda critical to doing an install, so it was time to get hacking to make those work. There were also a couple of parts of d-i that needed tweaking -- the preseeding code didn't support the device, and I needed to package a tool to build a "complete" uploadable firmware image and teach d-i how to use it. Apart from that, though, things were looking pretty good. Make the Debian kernel support your hardware Once you've worked out what hardware you need to make work, you need to dig into the kernel and fix it. Sometimes, if you're really lucky, a kernel version newer than the one currently in Debian has better support for something, and you can backport the fix / feature improvement. Other times, there's something similar already in the kernel for a different device and you can crib off that (I did this extensively for my little fixes). Then there's the "ask an expert" school, where you find someone who knows what they're on about and pick their brain (I did a bit of that, too). Finally, there's plain old "research and development", for which there are piles of documentation already out there. My changes for the DNS-323 came to 121 added lines and 16 deleted lines, most of which was cribbed-and-tweaked from other parts of the kernel. I might have written 10-20 lines of code "from scratch". It's not always scary-hard. Cross-compiling your own kernel One thing that I think needs mentioning in the kernel hacking department is cross-compiling a modified kernel for testing purposes. Chances are your main workstation has a lot more grunt (and build tools) than whatever you're trying to get Debian onto, so cross-compilation is the way to go. You need to first grab a copy of the source you want to build (from apt-get source linux-image-blahdiblah, or a release tarball, or Linus' git repo, it doesn't really matter) and a cross-compilation toolchain. For my cross-compilation toolchain, I just added this to my sources.list:

 deb http://www.emdebian.org/debian/ unstable main

then I ran apt-get update, and installed these packages:

	binutils-arm-linux-gnueabi gcc-4.1-arm-linux-gnueabi
	gcc-4.3-arm-linux-gnueabi-base libc6-dev-armel-cross

Kudos to the emdebian team for making that such an utterly painless exercise, by the way -- the days of needing to faff round with gcc sources to get a cross-compilation toolchain are apparently over. Once you've got a source tree and a cross-compiler available, you can run any of the usual kernel make commands (like make zImage or make oldconfig), as long as you've got a couple of make variables defined. In my case, I used:

 ARCH=arm CROSS_COMPILE=arm-linux-gnueabi-

ARCH tells the kernel what architecture to build for (useful in all make commands because not all arches have the same config options in make menuconfig, for example) and CROSS_COMPILE tells the build system what to prefix the calls to gcc, ld and such with (if you installed the same cross-compiler packages as I did, you'll find it installs files like /usr/bin/arm-linux-gnueabi-gcc, so you can ls /usr/bin/*gcc to find out what you'll need for the CROSS_COMPILE setting). Hack d-i to make things work In addition to tweaking the kernel, it's quite possible that the internals of d-i might need some tuning. It's possible that d-i might need to be "taught" to recognise the hardware in your device, or you'll need to extend some aspect of the installation process to complete the installation. In order to hack d-i, you need to know a bit about how it works and how it is structured, so let's run through that first. The entireity of d-i is based around udebs, which are packages of the same format as "real" debs, but which have been built differently (against a small libc, for instance) and have had everything that isn't absolutely necessary (docs, non-essential scripts, extra functionality, etc) stripped out of them to create the smallest possible packages. There are a variety of different udebs -- most are derived from otherwise normal, law-abiding citizens of the archive, like busybox (basic unix utilities like cp and ls), the shell that's used in the installer, parted, various libraries, and so on. Others are "special", and have no big brother in the archive. These are mostly "task" udebs, that define what actually happens in the installer. When they're "installed", they have special fields in the package metadata that define where in the install sequence they go, and they end up on the menu you see if your installation goes a bit pear-shaped. The tricky thing about udebs is that, as small as they are, there's too many of them to be able to have them all available when the system first boots, so even the "setup" of the installation gets done in several stages. First, the kernel and initrd boot. The initrd contains just enough stuff to get access to the rest of the udebs, and nothing else. Even this early stage is built from udebs -- there's lists of what goes into the initrd for various architectures and flavours of installer under installer/build/pkg-list in the d-i SVN. If you need an extra udeb in your initrd, that's the place to specify it. Once the initrd has gotten access to a source of packages (off a CD, over the network, telepathy, whatever) it can drag the rest of the packages it needs from there. Space is still an issue at this point, though -- there's no diskspace yet to put anything onto, so everything needs to fit into a ramdisk. Don't go loading anything you don't need. The packages loaded at this stage are what defines most of the steps that will be done for the rest of the install, so once all those extra udebs are loaded, the remainder of the install kicks off and does it's thing. Different architectures and install methods have different requirements, too, which complicates matters. For example, when you're installing on a regular PC with screen/keyboard, you can guide the install using that. However, if you've got no screen, how can you control the install? There's serial consoles, but requiring everyone to void the warranty (more) on their little embedded doodad by installing a serial console cable to install Debian isn't so hot. So, lacking a terminal, how do you control the install? Well, on install flavours for devices that might be in this situation, you can SSH into the installer and complete it that way. That feature is, like everything else, provided in a udeb -- called network-console, as it happens. But what IP address do you connect to, and what network settings does the device use? Again, without a console you can't configure your network, and not everyone has a DHCP server (and even fewer people have a DHCP server that will hand out an address that they'll know in advance, or be able to find out). So, there's a udeb (called oldsys-preseed) that does it's best to configure your network based on the settings already in the nvram for your device. In short, there's a lot of tricky, well-thought-out shit going on inside d-i, and you might have to deal with a little bit of it. The nice thing is that by now I expect most of the really hard problems have been solved, so with a bit of luck you'll only ever have to do minor tweaking. In general, all of the packages that are "d-i specific" live in packages in the d-i SVN. If you need to modify a udeb, you need to rebuild it and put it in installer/build/localudebs/ (creating it first if need be) and every time you change it, you need to delete installer/build/apt.udeb/cache/. To give a concrete example (from the ever-present DNS-323), I had to modify oldsys-preseed so that it would get the details from the nvram that the stock firmware uses to configure itself. This, in turn, required that the minix-modules udeb be included in the initrd, because the DNS-323's nvram is actually a small minix partition stored in flash. Painfully, this required some more hacking, because the armel d-i kernel wasn't configured to generate minix-modules. That might need some explanation... Since building the kernel is a fairly massive undertaking, CPU-wise, instead of building all the udebs from scratch there's a package called kernel-wedge to split a real linux-image package into lots of little udebs. There's a separate source package for each architecture, linux-kernel-di-$ARCH-2.6, that contains the configuration data for kernel-wedge to specify what udebs need to be built, and what goes into each of them. A small tweak to the armel package and voila! I had a minix-modules udeb to include in the initrd. With the config stuff I'd done in the d-i build itself and my changes to oldsys-preseed, we were done with d-i. Tell d-i how to build your bootable artifacts If your device needs a "different" install image from other similar devices, you need to write some makefile rules to build those files. Look under the installer/build/config/$ARCH/ directory to see the various rules files available. I had to package a new tool to create uploadable firmware images for the DNS-323, along with adding a rule to use that tool to build images. None of it was particularly difficult. Polish the diamond Getting d-i working is only part of the battle; it's quite likely that there will be other hardware in the machine that needs to be supported. This could involve kernel-level stuff to interface to the hardware, or userland tools to manage the hardware. There's several bits in the DNS-323 that still need work; I can't control the LEDs on the front panel, nor the fan, and I can't use the on-board temperature sensors yet. But, I do have Debian running on the thing, which is what I was shooting for. Examples If you're interested in exactly what I did, there are a number of bugs in the BTS that contain the patches I made:

• #502821: oldsys-preseed changes to take existing network config from NVRAM;
• #502936: build a minix modules package for the armel d-i kernel;
• #503040: d-i core changes to build firmware images for the DNS-323;
• #503172: kernel patches to support the SATA controller and NIC better.

You know you've got a bunch of Mennonites together when the pastor spontaneously asks the church to sing "Jesus Loves Me" while the children walk up for their children's story. And, without music, everybody spontaneously breaks into beautiful 4-part harmony. It must be genetic or something.

It was a day of beautiful singing of hymns a week ago for Tabor Mennonite Church's centennial. It's hard to write about that weekend, in fact -- it was such a nice experience.

Sunday ended with opening the box sealed in the church's cornerstone back in 1965 when the current building was built. Rudy Schmidt, the person that sealed it up back then, was on hand to open it back up. They took out the stone and removed the box. Before the box was opened, Rudy told a story:

Back in 1965, I was the one to solder this box shut. While I was doing this, all of a sudden I smelled burning from inside. I figured I must have caught something inside on fire. I asked Jake Koehn (another person on the building committee) what to do. Jake said, "Nobody will ever see it again, just put it in." So let's open it!

I think Rudy has been wondering all these years whether he set it on fire or not.

The box was opened, and other than a few scorch marks on an envelope, was completely intact and in good shape. There was a copy of a local newspaper from 1965 with a headline about Goldwater, copies of programs of dedication for the new building and parsonage, a Bible, copies of the church constitution, and all sorts of other interesting things. To that we will add a copy of our centennial book (which I helped develop), CDs with recordings of our centennial activities, programs from the centennial celebration, and photos of the weekend.

Earlier on Sunday, we had a long but good worship service with sermons from two former pastors. The choir sang, including a song commissioned for the occasion by Larry Nickel. We got applause after that one (which happens occasionally, but not regularly, in our church). All the living former pastors, and the widow of one of them, served communion as well.

The service ended with the congregation singing the "Mennonite Anthem". I think it was the most beautiful singing of that song I've ever heard. We had 352 people in church that day, and it seemed that not one person was going to let the moment go by without singing.

Saturday had started off with outdoor activities in the church park. There was old-fashioned soap making, remembering how church members used to store fat all year, then get together to make soap for use in their homes and to donate to the needy. There was rope making, wool spinning, and rides for the children. Under the tent, we had some great music the local Greenhorns band, and the former pastors all shared some memories and stories about their time here.

On Saturday evening, we had a meal and a drama -- and managed to somehow fit 321 people into the church basement for the meal. We think that's a record! The drama was written for the occasion by one of our members. John Gaeddert, a pastor here in the early 1970s, has become an expert wood carver in his spare time. He had carved a piece for us to celebrate the occasion, and presented it during the drama. That fit right in, because the drama was called "Bring Your Own Hedgepost" -- back in the early days of the church, each member was supposed to do just that so they would have a place to tie their horses.

Friday night was a lecture by James Juhnke about our first paster, P. H. Richert, who was pastor for nearly 40 years. Quite entertaining and interesting.

I think the highlight of the weekend for me was getting to talk to some of the former pastors I never knew well. I had a few minutes to chat with John Gaeddert. I introduced myself, and he said, "Oh! I don't think I've met you, but I've heard your name a few times this weekend. You're on the centennial committee, right?" Yes indeed. I was born after he left this church, but he knew my grandparents -- which means he also knows exactly where we live. John and his wife Mary are both such warm and friendly people that it feels like I've known them much longer than a few days!

I got to chat with Jim Schrag too. He was pastor at Tabor until I was about 5 or 6. He didn't remember me specifically, but he was also interesting to talk with. He was one of the people that worked on a detailed history book in 1983 for the church's 75th anniversary. He told me that he processed most of the black and white photos for that book in a darkroom in his basement. I hadn't known that -- and mentioned I had found all those photos in the church archives and had scanned them all in. Jim requested a copy.

Terah found Lenore Waltner, wife of former pastor James Waltner, who passed away about a year ago. James had started his career as a pastor at Tabor, and ended it at College Mennonite Church in Goshen, IN, where Terah grew up. So she knew him, but I didn't. Terah introduced herself to Lenore, who seemed quite excited to make this sort of family connection!

And Brenda Martin Hurst, another former pastor, found Terah and introduced herself. Terah said that Brenda said something like, "Hi, I'm Brenda, and I don't think I know you!" These pastors all want to get to know everybody, I think!

I attended Openmind last week, an interesting conference organized by the Finnish Centre for Open Source Solutions (COSS) to bring together open source professionals, community members and academics in Finland. In the session about business aspects of open source, in which I gave a talk about FOSS Governance, Nina Helander and Mikko R nkk presented the preliminary results of the National Software Industry Survey 2008. I found the results incredibly interesting. In particular, they found that 75% of responding firms use open source software in some way. This figure is up from approximately 13% in the year 2000, which is a major increase in just a few years. The study also found that that there was no statistically significant difference of company size when it came to the use of open source. Finally, companies that have open source components in their offering rate themselves as more innovative. Roberto Galoppini, who moderated the session, commented that Finland is where Gartner predicted that companies would be in 3 years. Indeed, I think everyone in the room was pleasantly surprised by the amazing numbers from the survey. We should not forget that the study was with software companies and that the use of open source will certainly be lower in other industries, but nevertheless the study shows that Finland is a leading country when it comes to the adoption of FOSS. (Originally published on FOSSBazaar)

I mostly stayed under a rock during the last weeks: exams season, some assingments plus one week of much needed [VAC]; ironically in the DebConf 8 secondary hotel. I'm in a very interesting course on operating systems' programming, it's a new optative course, and has generated a lot of expectatives: most of the systems-oriented undergrads in the computer science career are attending. The downside is that it's *intensive*: we're expected to build from scratch a minimal operating system, starting from the bootloader. So far my group has already done a bootloader that understands FAT, and the entry point for the OS, in which the basic stuff is setup: gate A20, interruptions, protected mode, GDT, etc. Also, each group is required to do a presentation of some systems research topic, and we choose Plan 9 from Bell Labs, that mostly unknown OS that was meant to be a better UNIX, but never gained popularity. So I spent many days playing with it, trying to grok quickly what it was about, and creating a small network of virtual hosts (in Qemu) that could show how it all fit togheter. Plan 9 has all the credentials: created in the same lab as UNIX, designed by the same people, which already learned from past mistakes. It was started in the late eighties, and it really feels like what the future was meant to be. Sadly, we're just starting to see a few of it's revolutionary ideas being applied to other systems: UTF-8, /proc, unionfs, fuse, clone(2), separate namespaces; all of these follow concepts first created in Plan 9, UTF-8 was designed by Ken Thompson "in front of my eyes, on a placemat in a New Jersey diner one night in September or so 1992", in Rob Pike's words. Not happy enough with reworking all the core concepts, they also recreated the visual environment. I have to admit, the user-facing ideas are so foreign that I still don't feel very comfortable using it. Surprisingly, the desktop is very mice-centric, it cannot be used at all without the mouse, and it's bothersome with less than three buttons. Anyway, the underlying workings are so attractive, that I cannot stop from wondering if a hybrid system could be built (Debian/kPlan9 anyone?). To illustrate, I'll reproduce here the same example that I showed yesterday and left some jaws hanging. I had booted a CPU server and a diskless terminal, called cpu-0 and term-0 respectively. This is a screenshot taken in the terminal, which is basically a telnet to my Debian box:
Nothing spectacular here, except for the weird syntax, it was seen like this in the Debian box:

martin@abraxas:~$ netstat -nt   grep :22
tcp        0      0 10.0.2.1:22             10.0.2.30:39879         ESTABLISHED

But here comes the fun, I ran an import command, which is more or less a remote filesystem mount, with which I mount the remote machine's /net in the local namespace. It has to be noted that the /net path is by convention the entry point to anything network related, including all the networking API.
And the wornderful thing is that this works as it should (note the remote address):

martin@abraxas:~$ netstat -nt   grep :22
tcp        0      0 10.0.2.1:22             10.0.2.10:38158         ESTABLISHED

So, what happened? telnet wanted to create a TCP connection, and that is accomplished opening /net/tcp/clone, but then it found the imported filesystem. The open(2) request was then transferred to the remote machine, and there the networking code did the actual TCP/IP dance. Things like this make you realise that maybe the BSD sockets API is not that nice an abstraction; in Plan 9 there are no BSD sockets, it's only implemented in the POSIX compatibility libraries, which aren't used by any of the core tools. Neither there exists any threads support, you just call rfork(2) setting the appropiate flags, exactly what glibc does under the covers nowadays. They also decided to live without select(2) or poll(2), there are no non-blocking calls. If you want non-blocking, you rfork(). The only syncronisation primitive is rendezvous(2), and everything else is built on that. At this point, it should not surprise you that to kill a process you can type echo kill > /proc/$pid/ctl; and that there's no need for an equivalent to Xnest, as rio (the graphical interface) provides a modified /dev, you just type rio inside a window and there you go. Yes, I'm hooked. If you're interested, I compiled many links here (some Spanish there, but all the content is in English), as one of the weakest points in Plan 9 is the unorganised and missing documentation. Tags: Plan9, Planet Lugfi, Planet Debian, Facu

I haven’t been blogging this election at all recently — there are enough folks out there saying just about everything that should be said (and lots that shouldn’t), but I couldn’t let this little tidbit slip by without mention.Via the TaxProf blog:

• Politico and Bloomberg report that the State of Ohio has a $1,182.92 tax lien against Joe the Plumber for back income taxes.
• The Associated Press reports that Joe the Plumber lacks a plumbing license.

Also, the Trademark Blog notes the flurry of related domain name registrations. Technorati Tags: Joe the Plumber, Obama, McCain, Politics, Election

Christmas came early for me this year: after receiving a Conceptronic CH3SNAS yesterday, a QNAP TS-409U showed up today. QNAP sent it to me a week ago to ensure that Debian works on it but it was stuck in customs for a few days. The QNAP TS-409U is similar to the TS-409 but comes in a rack case (and with more RAM). It seems that QNAP have also changed the layout of the mainboard but essentially it's still a TS-409. This means that the installer works just fine. Another difference to the TS-409 is that the TS-409U has two fans but qcontrol works without any problems on both machines.

We re all aware of the financial crisis due to credit default swaps shaking up the markets, media, politics, and what not. Some of us are feeling the pain, most of us aren t yet. A few days ago, politicians of the big, capitalist nations convened to agree on a way forward to stablise the financial market and set an end to the crisis. They are planning on doing this by throwing hundreds of billions at the market, buying all the subprime loan packages with the intention to create a new market for them, thus taking the weight off the shoulders of the countless barely-surviving banks and investors, who have written off billions in losses without an end in sight. Where does this money come from? Taxes and newly printed money. You may not yet feel the effects of this, but you will: taxes will rise, and inflation soar to even higher levels. Today is Blog Action Day with poverty as the focus, and it s a good occasion for me to state what s long been on my mind. The strategy by our political leaders to combat the credit crunch is short-sighted, and it fights symptoms, not causes. In fact, it s Robin Hood played in reverse: tax increases and inflation will hurt those most who cannot do anything against it: the poor. On the other side of things, those active in the financial markets will have their damages limited, and new CDS markets might even create more opportunities for those who can. I strongly oppose the way our politicians are handling the issue, even though I do have small amounts of funds invested in financial products myself, and have already seen the positive effects of their actions. Rather than throwing money at the markets, we really ought to put those away who have caused all this, those ruthless, greedy ones who have speculated way over their heads, underestimated the risks, and caused this crisis that killed many businesses, threatens to endanger entire countries, and hurts individuals who hardly ever had a choice. Think of it as a driver s licence, and that should be revoked for those who screwed up so royally bad and got us into this situation in the first place. Don t let them speculate again! Update: Andreas Metzeler notes that he is (rightfully) missing a what is to be done instead section in my blog post. I don t have anything to offer on that front, sadly. I also realise I should have phrased my opposition differently. Reading this interesting interview with Deutsche Bank ex-CEO Hilmar Kopper (German only) (thanks, Andreas!) helped me understand more that the politicians aren t saving banks, they are saving the system, and that they have little other choice. Another aspect I haven t previously seen as clearly as now is that the governments are purchasing (and willing to carry) risk for others, to relieve the markets. Risk by itself doesn t cost anything, so it might turn out that the billions they made available won t actually be spent though I always new that the governments might well come out of this with a profit even. The whole affair still stinks, and what I truly miss are the actions to prevent those responsible for getting us into this mess in the first place from doing so again. NP: This Will Destroy You: Young Mountain

I decided to get an electic bike when my car died. Couldn't quite stomach buying a new gasoline vehicle at this point in time, didn't really feel like another used car, and the available electic cars are still too new/expensive/hard to find. While there are some neat NEVs that are not too expensive, they're too limited to be worth my money, and electic bikes fit into the same general niche. (So do electic scooters, but I didn't want to spend that much money on an experiment..) My first try was a disaster. I was thinking that a large cargo capacity would be a good thing, so I gravitated toward trikes. However, the one I tried turned out to be a lemon in several ways, and suffered a catastropic and dangerous controller burnout. So I learned that this electic bike industry is pretty rough and ready with a lot of junk to avoid. I also learned that I don't enjoy riding trikes. The second try was a R Martin LX1, which my dad had researched. I got it yesterday, and have ridden it some now, and I agree that it's a good one. As a bike, it's well built, has a good back disc brake and decent front brake (will be better once I bring it to a bike shop to adjust it better), has a good derailer, and rides well. I'm no expert but it seems about as good as the bike I used to commute with, though the frame is a bit heavier. (IIRC, it was also at least $200 cheaper than that bike!) On the electic side, it has a relatively small and light lithium ion battery; the motor is mounted in the hub. It's strong enough to go up hills on its own if you really want it to, but you will end up pedaling to assist, which is good. I'm undecided whether the six gears are enough ... Seems like I might want a faster gear, to be able to assist the motor more at high speed. I haven't wanted a lower gear yet, but I've not tried to do any hills without the motor's help. The electic controls are ok, but not perfect. I worry about accidentially twisting the throttle, although it has to be turned quite far to engage the motor. Ideally, the pedal assist would turn the motor on exactly when you pedal, and porportionally to how hard. Instead, there'a a lag, and doesn't care how hard you pedal. This can present problems coming up to an intersection or other hazard, where pedal assist kicking in can unexpectedly be more speed than is needed. Seems a waste to have to brake to cut the assist off. The motor is audible when accellerating, and especially complains when trying to get me up a hill on its own. At speed, or if given a human power assist, it's quieter than the chain, if not silent. So there's room for improvement (and this would be a fun thing to do some hacking on to improve its response), but it's still a lot of fun. I'd forgotten how much I enjoy riding a bike and getting a nice workout. And it's especially nice to go up a hill pedaling only as hard as you like, to be able to accellerate quickly without standing on the pedals, and to be able to "coast" a long, long, way.

Conceptronic kindly sent me a CH3SNAS for my Debian porting efforts. The Conceptronic CH3SNAS is reported to be basically the same hardware as the D-Link DNS-323 but it costs slightly less. There were some reports that the CH3SNAS uses a 88F5182 chip whereas the D-Link DNS-323 uses a 88F5181 but nobody was able to confirm this for sure. As it turns out, there are two revisions of the DNS-323. Revision A1 uses a 88F5181 chip along with a separate SATA chip. Revision B2 on the other hand uses a 88F5182 which integrates SATA into the SoC itself. The CH3SNAS is equivalent to a D-Link DNS-323 revision B1. In fact, the mainboard of the CH3SNAS even says DNS-323 rev B1. The Linux kernel from mainline only works on the DNS-323 revision A1 at the moment. Adding support for revision B1 should be trivial since you basically just need to initialize the SATA chip on the SoC and possibly adapt some other values. Unfortunately, the DNS-323 uses a very small serial connector so none of my serial cables work. If I can find someone who will make a serial cable for me, I'll fix up the kernel.

Some brief highlights of the last three months of Debian Eee PC development. Thermal and ACPI breakage resolved in 2.6.26-7 We’re pleased to see that in the upload to Sid of linux-image-2.6.26-1-686 version 2.6.26-7, the pair of 2.6.26 bugs we’ve been tracking that have made it difficult for Eee users to upgrade their systems have been resolved. Since then 2.6.26-8 has been uploaded and is expected to enter Lenny this week due to a freeze exception. Once the new kernel has migrated we will move quickly to build and release a new installer that includes it. Ath5k wifi works on Eee PC in Linux 2.6.27 Jean-Christophe reports that ath5k works in Linux 2.6.27 on the Eee PC 701, and just needs a small patch to work with our eeepc-acpi-scripts package. This is good news for those of us with models 701, 900, 900A and 1000HD who have been wanting to get off of the non-free Madwifi drivers and onto DFSG free drivers. New Eee PC model 701SD wifi support in the works Users of the new Eee PC Model 701SD have just started showing up looking for support in mainstream Linux distros. Martin Filtenborg confirmed using our Eee PC Live image with the GPL’d rtl8187se driver from Realtek that we can at least use it to connect to an unencrypted AP, get an IP address and ping other hosts. Of course, it is one thing to have a working vendor-supplied driver and quite another to have mainstream support. We’ll make do with what we have now, but will be seeking a mainstream solution as soon as possible. We’re seeking more testers and developers to work on this. To date, an ITP has not been filed, as it is not yet clear who is going to carry this work forward. Chasing the 5 second boot An interesting discussion on Arjan van de Ven and Auke Kok’s work to get an Eee 901 to boot in 5 seconds took place this month. While the Debian Eee PC team is not making work on this a priority, we’ll keep an eye on it to see if Debian can incorporate some or all of the techniques they used so that our users can benefit without making radical changes to their systems. Working towards mainstream support for rt2860 Our filing of an ITP for rt2860 (the wifi driver for models 901, 1000 and 1000H) was followed by discussion about how to separate out the GPL’d driver from the embedded non-free firmware so that it can at least go into contrib. Glenn Saberton has been working on rewriting the build system around kbuild and separating out the firmware. Numerous improvements to ACPI scripts Since my last progress report, there have been numerous improvements to the eeepc-acpi-scripts package to deal with all of the various models we now support and make the scripts more robust and flexible. Check out the changelog for details.

A comment on Facebook yesterday got me thinking what American "traditional values" are all about. We hear it a lot, and I suspect it means something different to different people.

Here's what it means to me.

It starts with an ethic fundamentally informed by the central tenets of Christianity -- which are also excellent standards of decency by secular standards. We are called to have a relentless drive to care for the repressed, poor, downtrodden. As Jesus said, "whatever you do to the least of these, so you do to me." It means extending the hand of friendship and compassion to all, in our own neighborhood and around the world. It means taking good care of the resources we have, acting responsibly, and affirming and supporting others so they can do the same. It means that, as our founding fathers emphasized, remembering that all people are created equal, are equally deserving of a good life, and deserve liberty and freedom. Finally, it means a constant realization that we are creating a human institution, and will always have an imperfect answer to these ideals, but that we can -- and must -- recognize our faults and strive to make things better.

How do these apply to our time?

We must start with the poor, the repressed, and habitually think of their situation in everything we do. That means remembering that when we drop a bomb in Afghanistan to kill a terrorist, we also usually kill 50 innocent bystanders, and devastate their families. It means remembering that illegal immigrants from Mexico come here because all they want is refuge from drug wars, food on the table, and a roof over their head. It means showing compassion in deportation proceedings: when illegal immigrant parents have a child born in the United States, the child is an American citizen and can't be deported, but deporting the parents will create an orphan. It means actively helping the repressed people of the world, whether they be in Sudan, Georgia, or AIDS victims in Africa, Muslims in New York. It means reducing taxes on the poor, giving them the skills and tools they need to make their way in life. It means caring for those with alcohol drug addictions, helping them to summon the strength to get past those problems, rather than locking them up or throwing them out on the street. In days past, this might have meant sharing firewood with the family down the road that was at risk of freezing in winter. Today it might mean assistance with winter heating bills.

Remembering that all people are created equal means that we must provide good education for everyone, whether they live in suburban California, inner city Detroit, or rural Appalachia. We owe quality health care to everyone; those without means to pay for health care, or to pay for a car to get to a clinic, should be treated with dignity and respect, and have equal access to medicine.

Remembering that all people are created equal also means that we must provide equal justice under law, and give everyone a fair trail. We must abandon the death penalty, because we have a shocking number of people on death row -- hugely disproportionately black and poor -- that have been shown innocent of their crimes thanks to advances in DNA testing. We must maintain the integrity of checks and balances in government, and support judicial oversight over search and seizure. We must avoid warrantless wiretapping because it subverts judicial oversight and corrupts our justice system by making the exercise of power secret. We must denounce torture, and refuse to employ it, because no human, being created equal, deserves to be treated in such a way -- and we have been applying it to innocent humans.

We owe the opportunity to grow up in a loving family, in a safe community, to every child. We must make sure that gangs no longer have the run of our streets, that drugs aren't displacing hard work as the currency of the community, and that adoption is inexpensive and practical for more families, rather than costing thousands of dollars. Doing so will help every child grow up knowing that they are valued, are important, rather than being unwanted and therefore abused or neglected.

Extending the hand of friendship and compassion to all starts with being a good example -- that shining city on a hill that Reagan talked about. We have to run an open, just, and fair society ourselves. We must not fear those that are different than us, just because they're different. We have to recognize that citizens of Iran, Russia, North Korea, Palestine, and the United States fundamentally are humans, created equal, seeking the same thing: a safe and secure future for themselves and their families. Being able to coexist peacefully means starting from that point, and being willing to talk to them, and yes, even their leaders, regardless of how distasteful they may be.

Acting responsibly with our resources starts at home -- things like not driving up credit card debt, not living outside our means. The same applies to government: massive deficits each year are exceptionally irresponsible and place us at great risk both at the present and in the future. We also have a duty to care for the planet and the environment in which we live, which means actively working to curb the things we do to harm the planet and cause global warming.

What about recognizing our faults? Perhaps the most patriotic duty asked of Americans is dissent. It is never easy, but is essential to keeping our democracy functioning. This country has a long history of successes, and also a long history of failures. We failed so many by keeping slavery legal for so long, and discrimination and lynching legal for even longer. We failed that Native Americans by forcing them from their lands and treating them with brutality. We have, to some extent, risen above these failures thanks to the ability to recognize them and try, to the best of our ability, to fix them. This is what the civil rights movement was about, and why we have a holiday for Martin Luther King, Jr. He spoke out against a society that said some couldn't eat in a restaurant because of the color of their skin, or who were repressed because of their economic status. He recognized that problem in America, and by speaking out against it, helped to change this country for the better.

Today we have to recognize the things we are doing wrong, and try to change them. We are torturing potentially innocent people. We are discriminating against Muslims and homosexuals in our midst. We are giving extraordinary power to big media companies through changes in copyright law, to big communications companies through failure to enact network neutrality laws. And we are labeling people that disagree with war as unpatriotic.

Notice some things I didn't mention, such as abortion. It's not really relevant, and the lines we are fed by both sides present us with this false pro choice vs. pro life debate. In reality, it seems to me that both sides want the best for the children: for every child to grow up in a loving family, where he or she is wanted. We all know from research that laws banning abortion do not actually reduce it. So we ought all to come together and try to make it more rare by providing more support to single parents, by making it easier to adopt children, by trying to make the perceived need for an abortion to go away.

So, in this election, I look at the candidates and it seems pretty clear which one is promoting traditional values and which one isn't. Obama is actively trying to reach across the aisle and find common ground. Even in his convention speech, he suggested ways to work together on abortion like I just mentioned. In the debate, he listened carefully to his opponent and acknowledged when he thought McCain was right. This is a necessary first step in working together to move forward. McCain subsequently released an ad mocking Obama for this.

What about caring for the poor? Again, Obama's tax policies, education policies, and health care policies take care of them far better than McCain's. About responsibility? McCain supported these deficit-busting budgets of the last 6 years, supported the oil-centric energy policies, and has been only lukewarm towards dealing with global warming. McCain and Palin mock Obama for trying to help poor Chicago neighborhoods 20 years ago, for being willing to just talk to our supposed enemies, for actually reaching across the aisle.

So yes, I am a values voter, and that's why I can't possibly do anything but vote for Obama.

There's a lot of debate these days about the impact of the increasing number of paid developers in FOSS communities that started as volunteer efforts and still have significant numbers of volunteers. Evangelia Berdou's PhD thesis "Managing the Bazaar: Commercialization and peripheral participation in mature, community-led Free/Open source software projects" contains a contains a wealth of information and insights about this topic. Berdou conducted interviews with members of the GNOME and KDE projects. She found that paid developers are often identified with the core developer group which is responsible for key infrastructure and often make a large number of commits. Furthermore, she suggested that the groups may have different priorities: "whereas [paid] developers focus on technical excellence, peripheral contributors are more interested in access and practical use". Based on these interviews, she formulated the following hypotheses which she subsequently analyzed in more detail:

1. Paid developers are more likely to contribute to critical parts of the code base.
2. Paid developers are more likely to maintain critical parts of the code base.
3. Volunteer contributors are more likely to participate in aspects of the project that are geared towards the end-user.
4. Programmers and peripheral contributors are not likely to participate equally in major community events.

Berdou found all hypotheses to be true for GNOME but only hypothesis two and four were confirmed for KDE. In the case of GNOME, Berdou found that hired developers contribute to the most critical parts of the project, that they maintained most modules in core areas and that they maintained a larger number modules than volunteers. Two important differences were found in KDE: paid developers attend more conferences and they maintain more modules. Berdou's research contains a number of important insights:

• Corporate contributions are important because paid developers contribute a lot of changes, and they maintain core modules and code.
• While it's clear that the involvement of paid contributors is influenced by the strategy of their company, Berdou wonders whether another reason why they often contribute to core code is because they "develop their technical skills and their understanding of the code base to a greater extent than volunteers who usually contribute in their free time". It's therefore important that projects provide good documentation and other help so volunteers can get up to speed quickly.
• Since many volunteers cannot afford to attend community events, projects should provide travel funds. This is something I see more and more: for example, Debian funds some developers to attend Debian conference and the Linux Foundation has a grant program to allow developers to attend events.
• Paid developers often maintain modules they are not paid to directly contribute to. A reason for this is that they continue to maintain modules in their spare time when their company tells them to work on other parts of the code.

Personally, I'm also wondering why there are some significant differences between GNOME and KDE. For example, about 67% of contributors where paid to work on GNOME whereas only 38% were paid to work on KDE. Why do some projects attract more commercial involvement whereas other projects continue to be mostly volunteer based? (Originally published on FOSSBazaar)

I ve previously ranted about the Lufthansa website. Trying to help out a blind friend obtain some assistance from Miles & More, the Lufthansa frequent flyer programme, I can confidently say that the two companies have a common origin and probably read the same customer service guidelines, which must be somewhat along the following lines:

• require your customers to fill out a web form by not providing any alternate contact information;
• make your website inaccessible to screen readers, so that visually disabled people cannot get in touch with you;
• require full contact data to be filled in before the contact form can be submitted, even if the customer is logged in and the system thus has access to all the data;
• auto-reply to ever form submitted with a mail that assigns a case number to your request, but provide no information on how to use that number: no link where I can inquire about the status of a case, and no means to post follow-up information;
• send this email from do-not-reply@miles-and-more.com to emphasise how customer-oriented your company is and how well you have understood the potential of email;
• when (if) you eventually send a real reply, send it from service@miles-and-more.com, which gives the impression of a real email address, and quote the case number in the subject, along with the first line of the customer s original request, like this: Re: To Whom It May Concern (#17 (#1729700) / (#M1449889) . For extra bonus points, use non-matching parentheses;
• try to ensure not to take into account any of the data provided with the original request and prefer stock replies to useful content;
• do not give the name of a person, but sign the email with something like Miles & More Service Team ;
• refuse all mails sent to service@miles-and-more.com with a note telling people to use the web form to provide feedback (with a cryptic link) and that your email is not being forwarded or read;
• when the customer uses the cryptic link to provide follow-up to the open case, possibly under the impression that the reply will be associated with the original case, assign a new case number and ensure that another team member answers the email with pretty much exactly the same information as the last reply you sent. Under no circumstances assume that the customer has already asked a given question before and couldn t make sense of or wasn t satisfied with the answer provided in the last round.
• should a customer enquire about alternative means of contact, tell them they can send regular mail via the post office, and that you are sorry that at the moment , you cannot reach the company by email.

If you follow the above guidelines carefully and possibly add a twist here or there, you can rest assured that you ll fit in quite perfectly with most of your competitors and companies in many other fields. You ll understand that the customer is evil and you have to protect your company and your customer service staff from them, by making it extraordinarily difficult and inconvenient to reach them, and ensuring that they won t get any further than the computerised guard at the front door. It s not like they are your most important asset. Interestingly, neither Swiss, SAS, nor Thai have read these guidelines. I hope they will never find them. NP: Porcupine Tree: The Sky Moves Sideways

When the Debian installer starts, it will normally ask you what language you want to install in and gives you a really long list of languages to choose from. Unfortunately, that's not how it works when you install on a headless NAS device. The reason for this is that installations on NAS devices are done via SSH and the installer normally brings the network up after asking the user for their language. So we'd simply skip the language question and go with English. When Timo Jyrinki recently mentioned that he couldn't install in Finnish, Frans Pop pointed out that localechooser has changed a lot since etch and that it should now be possible to have the language question after setting up the network. This turned out to be correct and I managed to choose a different language but the installer still showed everything in English. Frans reminded me that the installer drops all translations that are not necessary but unfortunately this happens too early in our case. He pointed me to a variable that determines whether translations will be dropped. So in lenny translations will not be dropped on NAS devices that have enough RAM and users will be asked when they connect to the installer via SSH what language they'd like to install in.

OpenExpo ended last night with a lovely dinner at Roter Turm, and I ought to thank Matthias St rmer and his team for their efforts. I especially would like to thank Myriam Schweingruber of the Ubuntu team! Debian.ch could not assemble enough manpower for a booth, and so Myriam took care of selling our new t-shirts at the Ubuntu booth 29 of them. That s Ubuntu giving back to Debian! NP: AC/DC: Stiff Upper Lip