On the morning after the final US presidential debate that happened a week ago, I was invited onto the excellent new WNYC morning show The Takeaway -- syndicated by Public Radio International. One of the hosts, John Hockenberry, was in Boston to tape that edition of the show. I was on to talk about Selectricity and some of other ways that we might use election technologies. I was on and off (mostly off) air for the whole second hour (7:00-8:00 AM) of taping and had a bit of a segment just into the second half of the hour. You can check out the website or download the podcast. Although it's definitely not as fun to listen to as my a last gig on public radio, it's certainly more consequential. The role of the techno-pundit was also -- unfortunately? --- easier for me to fill.

The only plausible result from this RNC mailing, I think, is increased fundraising for Obama over the next few days: For the nearsighted, the front of the mailing says “Terrorists Don’t Care Who They Hurt” and inside: “Why Should We Care What They Have to Say? … Barack Obama. Not Who You Think He Is.” I would be surprised if the Obama campaign doesn’t get a measurable bump in donations for every mailing like this. What I really wonder is how intelligent Republican party members tolerate this sort of thing. Aside from Colin Powell, are other high-IQ Republicans voting against their party because of these tactics? Or do they just believe any means justify the ends? My pet theory as to why these attacks are useless (at best) to the GOP is that they don’t resonate with anything the voters are seeing. The GOP implies Obama is a muslim terrorist who is inexperienced and risky and also an extreme liberal/socialist left-winger (I haven’t heard “communist” yet from the mainstream), while what the electorate sees in the debates, ads, and campaign appearances is an uncannily steady, balanced, articulate individual who comes across as a moderate on most issues (note Obama’s theme of returning to Reagan-era taxation levels!) At least with the “flip-flopper” attacks (and maybe even the Swift-Boat attacks) on John Kerry, there was something people could see that somewhat corresponded with the attacks, even if the underlying facts didn’t actually pan out. Here, the chasm between the nature of the attacks and the visible target is so great, they could only help energize those who are already hard-core partisans. The lesson here is that if you want to launch misleading, baseless attacks against your opponent, at least find some kernel of truth to base them on. On a similar note, I agree with Aaron Swartz that ACORN deserves our financial support. Finally, I predict a bunch of astroturf comments to this blog entry. I won’t bother to respond if the comments fail to say anything intelligible. Technorati Tags: Politics, Election, Obama, McCain, Terrorism, ACORN

The only plausible result from this RNC mailing, I think, is increased fundraising for Obama over the next few days: For the nearsighted, the front of the mailing says “Terrorists Don’t Care Who They Hurt” and inside: “Why Should We Care What They Have to Say? … Barack Obama. Not Who You Think He Is.” I would be surprised if the Obama campaign doesn’t get a measurable bump in donations for every mailing like this. What I really wonder is how intelligent Republican party members tolerate this sort of thing. Aside from Colin Powell, are other high-IQ Republicans voting against their party because of these tactics? Or do they just believe any means justify the ends? My pet theory as to why these attacks are useless (at best) to the GOP is that they don’t resonate with anything the voters are seeing. The GOP implies Obama is a muslim terrorist who is inexperienced and risky and also an extreme liberal/socialist left-winger (I haven’t heard “communist” yet from the mainstream), while what the electorate sees in the debates, ads, and campaign appearances is an uncannily steady, balanced, articulate individual who comes across as a moderate on most issues (note Obama’s theme of returning to Reagan-era taxation levels!) At least with the “flip-flopper” attacks (and maybe even the Swift-Boat attacks) on John Kerry, there was something people could see that somewhat corresponded with the attacks, even if the underlying facts didn’t actually pan out. Here, the chasm between the nature of the attacks and the visible target is so great, they could only help energize those who are already hard-core partisans. The lesson here is that if you want to launch misleading, baseless attacks against your opponent, at least find some kernel of truth to base them on. On a similar note, I agree with Aaron Swartz that ACORN deserves our financial support. Finally, I predict a bunch of astroturf comments to this blog entry. I won’t bother to respond if the comments fail to say anything intelligible. Technorati Tags: Politics, Election, Obama, McCain, Terrorism, ACORN

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.

I have access to a server in Germany that was running Debian/Etch i386 but needed to be running Xen with the AMD64 version of Debian/Lenny (well it didn’t really need to be Lenny but we might as well get two upgrades done at the same time). Most people would probably do a complete reinstall, but I knew that I could do the upgrade while the machine is in a server room without any manual intervention. I didn’t achieve all my goals (I wanted to do it without having to boot the recovery system - we ended up having to boot it twice) but no dealings with the ISP staff were required. The first thing to do is to get a 64bit kernel running. Based on past bad experiences I’m not going to use the Debian Xen kernel on a 64bit system (in all my tests it has had kernel panics in the Dom0 when doing any serious disk IO). So I chose the CentOS 5 kernel. To get the kernel running I copied the kernel files (/boot/vmlinuz-2.6.18-92.1.13.el5xen /boot/System.map-2.6.18-92.1.13.el5xen /boot/config-2.6.18-92.1.13.el5xen) and the modules (/lib/modules/2.6.18-92.1.13.el5xen) from a CentOS machine. I just copied a .tgz archive as I didn’t want to bother installing alien or doing anything else that took time. Then I ran the Debian mkinitramfs program to create the initrd (the 32bit tools for creating an initrd work well with a 64bit kernel). Then I created the GRUB configuration entry (just copied the one from the CentOS box and changed the root= kernel parameter and the root GRUB parameter), crossed my fingers and rebooted. I tested this on a machine in my own computer room to make sure it worked before deploying it in Germany, but there was still some risk. After rebooting it the command arch reported x86_64 - so it had a 64bit Xen kernel running correctly. The next thing was to create a 64bit Lenny image. I got the Lenny Beta 2 image and used debootstrap to create the image (I consulted my blog post about creating Xen images for the syntax [1] - one of the benefits of blogging about how you solve technical problems). Then I used scp to copy a .tgz file of that to the server in Germany. Unfortunately the people who had set up that server had used all the disk space in two partitions, one for root and one for swap. While I can use regular files for Xen images (with performance that will probably suck a bit - Ext3 is not a great filesystem for big files) I can’t use them for a new root filesystem. So I formatted the swap space as ext3. Then to get it working I merely had to update the /etc/fstab, /etc/network/interfaces, and /etc/resolv.conf files to make it basically functional. Of course ssh access is necessary to do anything with the server once it boots, so I chrooted into the environment and ran “apt-get update ; apt-get install openssh-server udev ; apt-get dist-upgrade“. I stuffed this up and didn’t allow myself ssh access the first time, so the thing to do is to start sshd in the chroot environment and make sure that you can really login. Without having udev running a ssh login will probably result in the message “stdin: is not a tty“, that is not a problem. Getting that to work by the commands ‘ssh root@server “mkdir /dev/pts”‘ and ‘ssh root@server “mount -t devpts devpts /dev/pts”‘ is not a challenge. But installing udev first is a better idea. Then after that I added a new grub entry as the default which used the CentOS kernel and /dev/sda1 (the device formerly used for swap space) as root. I initially used the CentOS Xen kernel (all Red Hat based distributions bundle the Xen kernel with the Linux kernel - which makes some sense). But the Debian Xen utilities didn’t like that so I changed to the Debian Xen kernel. Once I had this basically working I copied the 64bit installation to the original device and put the 32bit files in a subdirectory named “old” (so configuration can be copied). When I changed the configuration and rebooted it worked until I installed SE Linux. It seems that the Debian init scripts will in many situations quietly work when the root device is incorectly specified in /etc/fstab. This however requires creating a device node somewhere else for fsck and the SE Linux policy version 2:0.0.20080702-12 was not permitting this. I have since uploaded policy 2:0.0.20080702-13 to fix this bug and requested that the release team allow it in Lenny - I think that a bug which can make a server fail to boot is worthy of inclusion! Finally to get the CentOS kernel working with Debian you need to load the following modules in the Dom0 (as discussed in my previous post about kernel issues [2]):
blktap
blkbk
netbk It seems that the Debian Xen kernel has those modules linked in and the Debian Xen utilities expect that. Currently I’m using Debian kernels 2.6.18 and 2.6.26 for the DomUs. I have considered using the CentOS kernel but they decided that /dev/console is not good enough for the console of a DomU and decided to use something else. Gratuitous differences are annoying (every other machine both real and virtual has /dev/console). If I find problems with the Debian kernels in DomUs I will change to the CentOS kernel. Incidentally one problem I have had with a CentOS kernel for a DomU (when running on a CentOS Dom0) was that the CentOS initrd seems to have some strange expectations of the root filesystem, when they are not met things go wrong - a common symptom is that the nash process will go in a loop and use 100% CPU time. One of the problems I had was converting the configuration for the primary network device from eth0 to xenbr0. In my first attempt I had not installed the bridge-utils package and the machine booted up without network access. In future I will setup xenbr1 (a device for private networking that is not connected to an Ethernet device) first and test it, if it works then there’s a good chance that the xenbr0 device (which is connected to the main Ethernet port of the machine) will work. After getting the machine going I found a number of things that needed to be fixed with the Xen SE Linux policy. Hopefully the release team will let me get another version of the policy into Lenny (the current one doesn’t work).

• [1] http://etbe.coker.com.au/2007/01/01/installing-xen-domu-on-debian-etch/


• [2] http://etbe.coker.com.au/2008/10/22/kernel-issues-with-debian-xen-and-centos-kernels/

Share This

I’m not sure which is the second-largest of the projects supported by Software in the Public Interest, but I thought that OpenOffice.org was up there with them. It’s been a bit of a surprise to me that SPI hasn’t done more for them since they joined back in March: only about $1,000 has been donated that way, none spent and I’ve not noticed their liaison being very active yet. Following the release of OpenOffice.org 3.0, I took a bit of a closer look. Stuff Michael Meeks is doing: Measuring the true success of OpenOffice.org suggests that the project is much smaller than I thought:

“In a healthy project we would expect to see a large number of volunteer developers involved, in addition - we would expect to see a large number of peer companies contributing to the common code pool; we do not see this in OpenOffice.org. Indeed, quite the opposite we appear to have the lowest number of active developers on OO.o since records began: 24, this contrasts negatively with Linux’s recent low of 160+. Even spun in the most positive way, OO.o is at best stagnating from a development perspective. “

OpenOffice.org is a project that produces something I don’t use much, but I recognise the significance of it. I’ve looked at contributing a couple of times in the past (nothing major, just bug reports and offers of help), but got utterly lost in the maze of websites and copious verbose descriptions written in management buzzspeak. (I spotted a “Report a Bug” link taking me to a page titled “Submit an Issue” for example.) Looking again now, OOo doesn’t seem much easier to navigate. I did find that SPI doesn’t appear to be listed on their donation page yet, which probably explains the low donation amount. Another confusing thing: they don’t use bugzilla, but a less accessible fork called Issue Tracker. Even simple contributions seemed to want multiple registrations to websites, mailing lists and whatnot - that seemed to contradict a claim that “Joining OpenOffice.org is purely optional” - and a confused email question to an address listed on the website got a rejection/error in reply. I’m sorry to say that I got confused, discouraged and moved onto other, easier things that I’d use more. Anyone else looked at contributing? How did it go for you? Anyone understand how this associated project works?

While it's a protocol we all love to hate, and wish it would go away and die a quiet death, sometimes someone has a good reason for supporting FTP. (In my case, it's usually because that reason has a lot of money to provide to my employer). But what if you want your FTP servers load balanced (because downtime is for suckers)? Obviously, you need to have some sort of shared filesystem behind all your load balanced FTP servers, but that's a rant for another day (but let me just say: if you're running GFS, especially on a busy site, may $DEITY have mercy on your soul). Because of the silly random port games that FTP likes to play, it's not a trivial job to load balance an FTP service amongst multiple hosts. You can't just throw a round-robin on port 21 and hope to get anything useful going. Ironically, while "active" FTP is a pain in the arse for most people, it's a lot easier to load balance, because the initial connection comes in on a well-known port which can be load-balanced, while all the other "random" connections are server-initiated and your standard routing/NATing/whatever you're doing for outgoing connectivity should be able to handle it. However, passive FTP is a bigger pain. The problem is pretty simple to understand -- the FTP client will want to connect to a high port on the "virtual" (load-balanced) IP, and without serious traffic sniffing, your load balancer won't be able to map that incoming connection on port 54321 to the real server that actually wanted the connection. The solution, thankfully, is fairly straightforward. You allocate a range of high ports (maybe a thousand or so) to each real server, with a different port range for each real server. You then tell the load balancer to send all traffic for each range of ports to the corresponding real server, and then configure that real server to put all it's passive connections into that port range (I'm fairly sure most FTP servers can support that bit of config). So, unfortunately, you can no longer disallow FTP support on the basis that you can't load balance it. No shortage of other reasons, though.

Last time I tried using a Debian 64bit Xen kernel for Dom0 I was unable to get it to work correctly, it continually gave kernel panics when doing any serious disk IO. I’ve just tried to reproduce that problem on a test machine with a single SATA disk and it seems to be working correctly so I guess that it might be related to using software RAID and LVM (LVM is really needed for Xen and RAID is necessary for every serious server IMHO). To solve this I am now experimenting with using a CentOS kernel on Debian systems. There are some differences between the kernels that are relevant, the most significant one is the choice of which modules are linked in to the kernel and which ones have to be loaded with modprobe. The Debian choice is to have the drivers blktap blkbk and netbk linked in while the Red Hat / CentOS choice was to have them as modules. Therefore the Debian Xen utilities don’t try and load those modules and therefore when you use the CentOS kernel without them loaded Xen simply doesn’t work. Error: Device 0 (vif) could not be connected. Hotplug scripts not working. You will get the above error (after a significant delay) from the command “xm create -c name” if you try and start a DomU that has networking when the driver netbk is not loaded. XENBUS: Timeout connecting to device: device/vbd/768 (state 3) You will get the above error (or something similar with a different device number) for every block device from the kernel of the DomU if using one of the Debian 2.6.18 kernels, if using a 2.6.26 kernel then you get “XENBUS: Waiting for devices to initialise“. Also one issue to note is that when you use a file: block device (IE a regular file) then Xen will use a loopback device (internally it seems to only like block devices). If you are having this problem and you destroy the DomU (or have it abort after trying for 300 seconds) then it will leave the loopback device enabled (it seems that the code for freeing resources in the error path is buggy). I have filed Debian bug report #503044 [1] requesting that the Xen packages change the kernel configuration to allow more loopback devices and Debian bug report #503046 [2] requesting that the resources be freed correctly. Finally the following messages appear in /var/log/daemon.log if you don’t have the driver blktap installed:
BLKTAPCTRL[2150]: couldn’t find device number for ‘blktap0′
BLKTAPCTRL[2150]: Unable to start blktapctrl It doesn’t seem to cause a problem (in my tests I can’t find something I want to do with Xen that required blktap), but I have loaded the driver - even removing error messages is enough of a benefit. Another issue is that the CentOS kernel packages include a copy of the Xen kernel, so you have a Linux kernel matching the Xen kernel. So of course it is tempting to try and run that CentOS Xen kernel on a Debian system. Unfortunately the Xen utilities in Debian/Lenny don’t match the Xen kernel used for CentOS 5 and you get messages such as the following in /var/log/xen/xend-debug.log: sysctl operation failed — need to rebuild the user-space tool set?
Exception starting xend: (13, ‘Permission denied’) Update: Added a reference to another Debian bug report.

• [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=503044


• [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=503046

Share This

I just wanted to fix some RC bugs till I'll go home, so I looked at the list of open ones and randomly chosen two bugs about roxen fonts which looked like low hanging fruits. Both were in fact same issue, just copied to two packages. I worked on the fix, creating some intermediate version and then I finally wanted to upload the package. Unfortunately in this step I somehow managed to use the intermediate version, which did not really fix the issue. As packages were already uploaded, there was not much I could do except yet another NMU, now with full set of changes. Just as accepted emails arrived I also noticed that I messed up bug numbers in changelog - I used same bug number in both changelogs. Okay, manually closing the bug worked around this. But now I'm afraid what else did I mess up. Probably it's time to go for a dinner and stop working on computer for now :-).

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!

Sometimes, I m becoming really pestered by the number of issues, especially hardware issues, that remain prominent in the Linux system after so many years. And I m convinced that one of the root causes is the kernel development model. While far to be the only one, you understand a lot when you have a look at it. The stable API nonsense To explain the development model, the kernel documentation contains a document written by Greg Kroah-Hartman called stable_api_nonsense.txt. I think this document gets one thing very right: advertising it is complete nonsense. Many things in this document can get you a good laugh if you are used to software development, unfortunately they are not funny given how much they affect us as users and developers. Let s start with the executive summary:

You think you want a stable kernel interface, but you really do not, and you don't even know it. What you want is a stable running driver, and you get that only if your driver is in the main kernel tree. You also get lots of other good benefits if your driver is in the main kernel tree, all of which has made Linux into such a strong, stable, and mature operating system which is the reason you are using it in the first place.

What it should say instead is:

You know you want a stable kernel interface, but you don't have it, and we will never provide it. You want stable interfaces to focus on fixing bugs in your driver instead of updating it for interface changes, and to make integration of your driver in the main kernel tree easy. You would get a lot of good benefits if your driver was in the main kernel tree, but it won't make it unless you adapt to our bizarre processes, all of which have made the Linux kernel into a constantly moving target which is the reason many hardware vendors don't want to support it in the first place.

Our compiler does not have the same ABI as yours This is what happens when the only thing that interests people in charge is to code. Writing this means that these developers have no interest in making the system usable. This becomes more unbearable when such technically sharp people make up false technical arguments:

Depending on the version of the C compiler you use, different kernel data structures will contain different alignment of structures, and possibly include different functions in different ways (putting functions inline or not.)

Really, I wonder how the Microsoft developers, the GNOME guys, the glibc guys, and basically all library developers who know what they are talking about, manage to have stable ABIs despite the compiler changing all the time. One of the incredibly complicated techniques they use is to only rely on guaranteed functionality of the C specification, instead of doing many clever and funky hacks. For things more related to development itself, there are also incredibly complicated techniques like opaque structures, which save a lot of ABI breakage. Actually the only thing you need, if you design your ABI properly, is to be rigorous.

Depending on what kernel build options you select, a wide range of different things can be assumed by the kernel

This statement of a problem also contains the solution: stop making available build options no one cares about (remember, people install binary packages from their distributions) to guarantee stability instead. Instead of implementing the solution, kernel developers deliberately choose to deal with this insanity in the worst possible way: by encouraging it. Only lame developers need stable APIs But the nonsense doesn't stop to the ABI, which after all is merely a problem for distributors. To be more annoying to developers themselves, let s make up reasons to break the API all the time:

Linux kernel development is continuous and at a rapid pace, never stopping to slow down. As such, the kernel developers find bugs in current interfaces, or figure out a better way to do things.

Explained this way, it looks like a good thing. If you've done serious development or integration, you know that actually it is a problem. If you never slow down to look at what you've done, you're only going to add new bugs while you're trying to fix the others.

When they do so, function names may change, structures may grow or shrink, and function parameters may be reworked. If this happens, all of the instances of where this interface is used within the kernel are fixed up at the same time, ensuring that everything continues to work properly.

Everything is said. In the Linux kernel, changes are not done in a continuous way. Every non-minor change is going to have an impact on hundreds of different modules. The amount of work needed to accomplish these changes is absolutely insane. When a project like GNOME decides to phase-out an API, it takes several years before being actually replaced. In the kernel, it can simply happen between two minor releases, together with a rewrite of the whole ATA stack. The lolution Of course, Greg KH has a simple solution for you, in the What to do section.

So, if you have a Linux kernel driver that is not in the main kernel tree, what are you, a developer, supposed to do? Releasing a binary driver for every different kernel version for every distribution is a nightmare, and trying to keep up with an ever changing kernel interface is also a rough job.

No shit !

Simple, get your kernel driver into the main kernel tree.

Simple, isn't it? Unfortunately this is not going to happen while you are too busy adapting it for the constantly moving interfaces. This is quite feasible if you are writing a driver for an Ethernet network adapter, but for a video card this is another story, and for a virtualization layer? Well, the Xen developers have been struggling for years to integrate their technology in the kernel, and it is still far from done. No wonder why you get good drivers only for ethernet cards and not for 3D cards or even wifi chips. This doesn t go without other, worse consequences for users and distributors. Not everyone can afford to run Ubuntu, Debian unstable or Fedora, especially if they have simple requirements like not changing the whole system every 6 months. Corporate users using Debian stable, RHEL, SLES or Ubuntu LTS need a stable kernel that doesn t move, and that doesn t break everything when upgraded. The introduction of projects like DKMS to distribute drivers in a sourceful way while keeping them easily installable is a step in the good direction, despite being a workaround for a broken situation underneath. However these efforts are ruined by the constantly changing APIs that will go on requiring changes to the sources as well as the binaries. Why it can still work In fact, with such processes, you can wonder how it is possible that the system is actually usable. The answer is simple: while being smaller than many other projects, the Linux kernel has much, much more developers. A rough estimation shows that Linux has 2000 developers, many of which are paid full-time to work on it, to work on a 15 Mloc codebase. You can compare it with X.org, which has a few dozens of developers for 3 Mloc. Or with GNOME, 400 developers for 20 Mloc. With OOo, 150 developers for 10 Mloc. Yes, you need 10 times as many people to maintain the kernel code than for another comparable project. That's of course what happens when you keep them busy with a permanent refactoring of the code. This development method, while certainly having the advantage of bringing lots of innovation and fast integration of new features, is also driving away a very large portion of the open source community to work on rewriting Firewire stacks every 6 months. And as long as they are busy with this, they are not writing correct X drivers nor fixing bugs in the applications.

Until very recently I thought that it would be almost impossible to get someone worse than George W Bush as the leader of any significant country. Unfortunately it seems that I was wrong and John McCain and Sarah Palin promise more of the economic, regulatory, and military disasters that are the trademarks of the US Republican party (or at least the dominant Neo-Con branch). Here are some links about John McCain: Here’s a good summary of the racial issues in the current US presidential campaign (This is Your Nation on White Privilege) [1]. The Obama campaign is highlighting the connection between John McCain and Charles Keating [2]. McCain was one of the senators helping Keating while his bank (the Lincoln Savings and Loan Association) was going under. In the end 20,000 people lost their savings and the US taxpayers ended up losing $120,000,000,000. Frank Rich has written an article for the New York Times about the racist attacks on Barack Obama [5]. The current actions of the McCain campaign only barely stop short of calling for an assassination. The South Florida Times has an interesting article about the McCain family’s history of slave ownership [7]. Now John McCain is not responsible for the actions of his great-great-grandfather in owning slaves, and there’s nothing wrong with having black relatives who are the descendants of some of those slaves (even though there is doubt about whether the female slaves were legally adults or even consented to the sex acts in question). But he should be honest about it. Denying having non-white relatives in the face of the facts seems to be strong evidence of racism. It is however understandable that John doesn’t want to discuss the fact that some of his relatives have announced plans to vote against him. Rolling Stone magazine published an interesting article about John McCain’s history as a spoiled brat in the navy [10]. It seems that if your father is an admiral you can ignore orders, crash planes, and basically do whatever you like. It also reveals that John was broken by the Viet Cong torturers and provided the name of his ship, the number of raids he had flown, his squadron number and the target of his final raid. I’m not going to criticise John for breaking under torture - I think that the assessment of wing commander John Dramesi (who was tortured by the same Viet Cong torturers but didn’t break) should be accepted. John Dramesi says that McCain “wasn’t exceptional one way or the other” while in captivity. However McCain’s use of his former POW status in propaganda is quite dishonest. John McCain is also documented as having described his wife as a “cunt” and a “trollop“. Here are some links about Sarah Palin: Former US Army Brigadier General (retired) Janis L. Karpinski writes about Sarah Palin [3], it’s interesting to hear what an intelligent female soldier has to say about her. One thing that I found noteworthy was the repeated references to “murdering” wild animals, shooting at a defenseless animal is of course quite different from shooting at a person who can shoot back (and different again from commanding an army). Janis also makes reference to Sarah setting the feminist cause back decades - I think that is what Sarah desires though. Also Janis points out the emotional problems for which pit bull terriers are known. There are many claims that Sarah is a “Maverick” and has a record of opposing corruption. This article in the Village Voice documents some of her corrupt activities - including having her home built for free in exchange for assigning the contract to build the Wasilia ice-hocky rink [4]. Thomas L. Friedman has written an article about Palin’s Kind of Patriotism [6]. According to Sarah it’s not patriotic to pay taxes, it seems to me that encouraging citizens to disobey the law should disqualify her from being elected without all the other issues. Thomas notes that Sarah is promoting the interests of Saudi Arabia by prolonging the US dependence on oil imports. The Huffington Post has an interesting article about Sarah Palin’s church [8]. It’s strange how little notice has been taken of Sarah’s former pastor who stated that people who didn’t vote for Bush were likely to go to hell. The Times has an article about “Troopergate”, some of Sarah Palin’s other corrupt practices, and the role of her husband as a shadow governor [9]. Update: Corrected URL [6].

• [1] http://www.opednews.com/articles/This-is-Your-Nation-on-Whi-by-Tim-Wise-080916-307.html


• [2] http://www.keatingeconomics.com/


• [3] http://www.truthout.org/article/palin-can-launch-us-back-time


• [4] http://www.villagevoice.com/2008-10-08/news/the-book-of-sarah/


• [5] http://www.nytimes.com/2008/10/12/opinion/12rich.html?ex=1239681600&en=b38b2d4387d4e3c4&ei=5087&excamp=NYT-E-I-NYT-E-AT-1015-L1&WT.mc_ev=click&WT.mc_id=NYT-E-I-NYT-E-AT-1015-L1


• [6] http://www.nytimes.com/2008/10/08/opinion/08friedman.html?_r=1&scp=1&sq=palin%20patriotism&st=cse&oref=slogin


• [7] http://www.sfltimes.com/index.php?option=com_content&task=view&id=2024&Itemid=1


• [8] http://www.huffingtonpost.com/2008/09/02/palins-church-may-have-sh_n_123205.html


• [9] http://www.timesonline.co.uk/tol/news/world/us_and_americas/us_elections/article4692408.ece


• [10] http://www.rollingstone.com/news/story/23316912/makebelieve_maverick/print

Share This

I finally catched up with Gammu backlog from holidays and now it is time to move it a bit further. Automatic testing During this week I set up CDash instance for acquiring results of automatic nightly checks of Gammu. Each night Gammu is build on several hosts (currently Debian x86_64, Debian x86, SUSE x86_64 and crosscompilation for Windows on Debian) and results are posted to the dashboard. If you have some other architecture which could participate in testing, you are welcome to contribute! It is simple - just checkout svn, create build directory and configure there Gammu using cmake. You can enable coverage tests (-DCOVERAGE=ON). Then just run every night make Nightly for regular testing or make NightlyMemoryCheck to do dynamic allocation analysis. There is more detailed documentation in sources (INSTALL file). Thanks to this, I can hopefully sooner spot regressions and possible problems on different architectures. Roadmap With upgrade of Mantis, new feature called roadmaps arrived. I started to use it for planning features in future Gammu releases, so you can see what bugs should be fixed in future releases in Gammu roadmap. Currently there are not much things planned, because till now I had to focus only on bug fixing, but I think with 1.21.0 we have reached much better quality than in past releases and now is time to do some important changes in the core. Nokia phone required As you can already see in roadmap, I plan some bigger changes to Gammu core. I currently have on Sony-Ericsson phone and I would not be able to properly test how these changes will affect Nokia drivers. So for start I will need at least Nokia Series 40 3rd edition phone. Nokia 6233 (or 6234) currently looks as a reasonable choice, but if you have any hints for cheaper one with similar features, just drop me an email. Perfect would be if somebody would have half broken phone (I do not intend to use it for anything else than Gammu development, so broken camera, speaker, microphone or display does not really matter) and will be willing to donate it to me. If this will not work out, I'll have to buy used one and I will try to collect funds for this. If you want to contribute, check my donations page for possibilities.

One of the many interesting ideas in Peter F. Hamilton’s Night’s Dawn series [1] is that of Combat Wasps. These are robots used in space combat which may be armed with some combination of projectile weapons, MASERs, thermo-nuclear and anti-matter weapons. In a lot of science fiction the space combat is limited to capital ships, a large source of this problem is technological issues such as the Star Trek process of making models of ships - it’s too expensive and time consuming to make lots of small models. Shows such as Babylon 5 [2] have fighters which make more sense. Sustaining life in space is difficult at the best of times and it seems likely for battles in space to have few if any survivors. So sending out fighters allows the capital ships to have a chance to survive. I suspect that a major motivating factor in the space battles in Babylon 5 was making it fit on a TV screen. Dramatic TV portrayal of small groups of fighters engaging in a battle is an art that has been perfected over the course of 80+ years. It’s about individuals being shown, whether it’s riders on horseback, pilots of biplanes, or space pilots, it’s much the same. But a reasonable analysis of the facts suggests that without some strange religious motive adopted by all parties in a war (as used in Dune [3]) the trend in warfare is to ever greater mechanisation. So while a medium size starship might be able to carry dozens or even hundreds of fighter craft, if using small robotic craft then thousands of fighters could be carried. So the issue is how to effectively use such robots. It seems likely that an effective strategy would involve large numbers of robots performing different tasks, some would detonate thermo-nuclear weapons to remove enemies from an area while others would prepare to advance into the breach. The result would be a battle lasting seconds that involves large numbers of robots (too many to focus on in a group) while each robot matters to little that there’s no interest in following one. Therefore it just wouldn’t work on TV and in a book it’s given a couple of sentences to describe what would have been an epic battle if humans had done anything other than press the launch buttons. One of the many things I would do if I had a lot more spare time would be to write a Combat Wasp simulator. There are already quite a number of computer games based on the idea of writing a program to control a robot and then having the robots do battle. This would be another variation on the theme but based in space. In a comment on my previous post about programming and games for children [4], Don Marti suggests that a RTS game could allow programming the units. It seems to me that the current common settings for controlling units in RTS games (attack particular enemies, attach whichever enemies get in range, patrol, move to location, retreat, and defend other units or strategic positions) are about as complex as you can get without getting to the full programming language stage. Then of course if you have any real programming language for a unit then changing it takes more time than an RTS game allows, and if the programming is good then there won’t be much for a human to do during the game anyway. So I can’t imagine much potential for anything between RTS and fully programmed games. There is some interesting research being conducted by the US military in simulating large numbers of people in combat situations. I think that the techniques in question could be more productively used in determining which of the various science fiction ideas for space combat could be most effectively implemented.

• [1] http://en.wikipedia.org/wiki/Night’s_dawn


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


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


• [4] http://etbe.coker.com.au/2008/10/16/programming-games-children/

Share This

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.

Gathering
I spent this weekend at a Skolelinux/Debian-edu gathering in Oslo. 8.5 hours by bus each way. I got to meet some of the people shipping a customized Debian for schools. As it was a gathering related to educational software, looking at the KDE4 kdeedu packages seemed most appropriate. I’ve tested step packaging and hopefully it is going to end up on your local debian archive one day, along with some fixes to where kvtml files are packaged, much awaited by Annma and others. Apparantly, in Brazil, they have their own debian based kde distribution and 130 GB of free as in public domain free educational movies. Some people discussed an application to view, tag and search the movies. I quickly thought of a mixup of nepomuk and phonon in a nice userinterface. So if anyone feels like implementing that, you are more than welcome. Gnash
The gathering was together with a Gnash hackathon, and apart from gnash getting more and more usable, the gnash people are also thinking about integration with the desktop environments. For KDE 4 they have plans of a KPart easy embeddable anywhere, including in KHTML. (Maybe another use of the KPartLoader dfaure wrote recently). The gnash team are unfortunately quite short on KDE knowledge and they asked for help. I’m probably not myself the right one to help here, but maybe some of you out there feel like helping. There is already a patch set around that some people claims works, but others haven’t figured out to make it work. Feel free to comment here and I will forward to the Gnash people - or just contact them directly on the gnash-dev@gnu.org maillist. Trolls
I left the gathering a bit early to get to a Troll picnic in a Oslo park and got stuffed with p lse and lompar. (sausages and pancake like bread) I was by bus all night back home and then a shower and straight to work. After work, I slept for 14 hours or so.

One massive annoyance with last week’s trip to the L2SE conference was the terrible state of WiFi access in London. I’d actually paid a little extra for first class on the home trip because it gives access to Paddington’s Victorian Lounge which says “It also has workstations with access to the Internet”. What it doesn’t say is that the workstations are desks not computers, there’s no wired ethernet and the wifi is Extortionate ISP The Cloud at the cost of 4.50 an hour. Alternatively, you can pay through Orange at 6/hour or more reasonably through O2 at 7.50/month. I was carrying two mobile phones, but not an O2. Why is Paddington so backwards? Bristol Temple Meads has U2com free wifi access through Dashi sushi bar (note it’s not National Rail or First Great Western) and fon which was about 3/day last time I used it. 4.50/hour seems a really terrible deal to me - I’ve used cheaper internet cafes than that and they have to maintain actual hardware. If that fee really reflects their costs, The Cloud must be a pretty wasteful operator. So I finally got GPRS working on my phone. Essentially, it was the same as described on Dave Stevens site and davesource, with the exception that the k608i already knows the connection settings, so the AT+CGDCONT line can be removed completely, as mentioned on Of Linux, GPRS Phones, Serial Cable, Irda, Bluetooth and USB, by Mikko Rapeli - otherwise the phone replies ERROR and the connection fails. It also needs the guest * guest line in the pap-secrets file and a matching user guest in the gprs options file. Another TTLLP member tells me that later phones offer NAP service and that pand is much simpler than pppd/gprs. I’ll find that out when I get a newer phone, I guess. Someone else suggested ip-over-dns to punish The Cloud for their silly fees, but is that legal?

Last Thursday, I was at a conference called Listening to the Social Entrepreneur. Here are some short notes about the plenary session, which were written at the time, along with thoughts on the workshops that I’ve just written up. HCT Group - credit crunch opportunity - business with ethics - transport - dislike 3rd sector term - difference between social enterprise and charity - optimism. Haley House - ex-soup kitchen staffed by ex-homeless, bakery, bank donated equipment, financial picture - catering grew 36% cafe grew 21% september, cooking classes; recipe for success: collaborate with experienced partner, secure enough capital or equivalent, align venture with mission; plan for sustainability; future… Roskilde university - relevance of academic research - why references for things I know - hard to have your feelings discussed. (meeting last Monday?) - don’t care what it’s called - too much jargon - several ways of learning, conceptual doesn’t seem useful but will later. CICs. Four flags of SEs - eship, er, e, econ. Bikeworks - practitioner and academic. Formation, setup, establishment, sustain. SE changes; viewpoint: academic, researchers, help us. Useless website. Then came three workshops of varying usefulness: Procurement Versus Marketplace was an interesting idea and reminded me why I avoided public-sector projects for years: I’m better at negotiated than at rules-based selling. I also was told (with a straight face) by a development trust worker that cooperatives are simply profit-sharing schemes, which was very disappointing. Social verses Business Goals seemed pretty ill-conceived. The reason why many people work in social enterprises is because we don’t believe we should choose between them. It’s an integrated, multi-faceted approach. Born or Made? was an interesting examination of the people powering social enterprises. Food for thought, but I’m not sure it really produced much. But I’m not that sure whether any of the workshops had much of a productive purpose. The final plenary session was confusing. I was sat further back, the sound system was intermittent and echoy and the talks seemed truncated and still, but maybe I was just tired. A lot of people had left by this point. I stayed on for the networking reception and met a few interesting people, but left earlyish to meet another TTLLP member on the light railway. The venue was OK (I think the main hall problems were more sound system and operation than the hall itself) and coffee, lunch and reception were well-catered. In conclusion, it was an interesting conference, but I don’t feel that we got much out of it, apart from some thoughts from a workshop session. I suspect it was more useful for the researchers than for the entrepreneurs. There weren’t many opportunities for professional development or sales or even putting things into consultations or . I’m not sure I’d spend best part of two days work (attending plus travel plus costs) on another similar event.

My parents found it strange that I spend considerable time in the night doing "some Linux thing", so the other day I explained to them what Free software is and we talked about copyright and licensing. I was very happy that they were able to appreciate it. I also gave a Debian Installer demo. While there are a bunch of Indian languages supported in the Debian Installer, (Telugu) isn't one of them. They noticed it and motivated me to work on te_IN translation for d-i and promised to help me. So the three of us have been discussing translation strings. I have been committing changes slowly and intend to complete this activity in a few months. Lack of interest in translation meant that I never gave much thought to it but I see that translating software is rather difficult and it is an activity that would benefit a lot from two or three people doing it together. I found a glossary at swecha.org but there are a bunch of problems

• Computing terminology is context sensitive and one word doesn't fit all uses.
• A lot of words in the glossary are rather contrived.
• Most words can be understood only by the elite of the Telugu speaking world.

I am using these simple guidelines for translation:

• Use language that is used in the newspapers today. Most people who can read would be used to this and understand it best. e.g password would be rather than .
• Do not invent words. If a certain computing term or a word doesn't have an equivalent colloquial Telugu word, use the English word written in Telugu script. Include the English word in paranthesis next to it. e.g. Registering modules... would be (modules) ...
• If a translated Telugu word sounds complex or ambiguous in the translation context, include the corresponding English word in Telugu as well as English in parentheses next to it. e.g Partitioning scheme: would be ( [partitioning]) :

A few resources that I have been using:

• lekhini - a browser based tool for transliteration based on RTS.
• en2te and uchicago.edu's Charles Philip Brown Telugu to English dictionaries.
• J. P. L. Gwynn's Telugu to English dictionary hosted by uchicago.edu

I will have to find a good quality comprehensive Telugu general knowledge book or an official A.P. govt. document to translate ISO 3166 codes etc. The Manorama yearbook would've been great, unfortunately Telugu is not one of the few languages it is published in. I will also bring my copy of Sankaranarayan's dictionary from my next month Hyderabad visit. If you have suggestions on any of these (pointers to guidelines, resources that are DFSG free and I could copy from etc.) that would make doing this easy for me, please do let me know. Naidu does good one-off Telugu string translations in Launchpad (so does praveenkumarg, btw), and Naidu has promised to do some of the work as well as review. If all goes well, I will try and create a debian-10n-telugu sometime in the future.