Twice, recently, people have commented on my post titles. I keep a real journal elsewhere where entries are either untitled, or are titled by quotations. In the past I used to keep a running total of who had guessed the source of the quote, but these days that game gets ignored. Titles here used to be song lyrics, but these days they are film quotes. When I started I intended to be a little interesting, and make "happy posts" contain quotes from films I enjoyed watching, and "ironic" or "ranty" posts contain quotes from films I disliked. But that didn't last for long, and I suspect nobody noticed anyway. (Why would they?!) Regardless that's the only explaination I'll give. Once or twice I've had people "complain" :

Your titles have no relationship to your posts. I don't know if your post is a serious one I should read, or a trivial one I should ignore.

To those comments I have several potential response:

• Either I believe the posts are serious, or I believe they are not. My opinion might coincide with yours, but frankly I have no expectation either way.
• Read the body, ignore the title. Consider it an ironic commentry on the importance of fashion, where appearance is more important than content.
• It quickly gets old making titles of the form "Hey, asql released. Again.".
• I find your ideas intruiging and wish to subscribe to your newsletter.

In short, if you (dis)like what I have to say I'm sure that the title of the post you disagree with is the least important part of that. I'm sure I could say more either way, but since the recent reminder I figured I should write something. I've almost done so several times but I find it hard to be specific. Regardless the summary is:

"I'll keep this up, whether you like it or not, until I get bored. Regardless of how much I might respect you, and your opinion."

PS. tscreen released. Again. ObFilm: Star Trek #2 - Wrath of Khan

I’ve read in a couple posts already that these changes to membership in the project would be appropriate to manage with a DEP: I agree. I agree, not because I think the end result should be a DEP (maybe it should be a GR after all), but because of the workflow the DEP procedure proposes. The key, in my opinion, is the driver (or drivers): somebody without an agenda but trusted by the project who should take care of fostering the discussion, summarizing it regularly while keeping all differences of opinion mentioned, helping the discussion get somewhere, and talking with people in the relevant roles if they, by any chance, would not participate in the discussion directly. The result would then be a solution which everybody has had a say on, and a text that can be passed by GR with an overwhelming majority. Or, in the worst case, a GR where most of the points are common between options, but that has a couple choices for the most conflicting points, should that be needed. I would love to see this happen first thing after Lenny: this can be so exciting if done well!

Only one day left for registration ! Register now and win cookies !

So I usually don’t announce my publications on my blog and for various reasons. The main one is that I am more than a little embarrassed that some of them are behind walled gardens (but being I am a junior prof, I am not in a position to negotiate otherwise). Otherwise, some of my pieces are semi-jargony (in the academic sense) and may not be of interest to readers who I think are more geek than academic. Finally, the process of publishing is so slow, so long, and so painful, I try not to think about it, much less write about it, if I can help it. But I decided to announce this
piece , which is on hackers (surprise surprise) as it might be of interest to some readers and because people can download it for free here for the rest of the month (but registration is required ) Co-written with Alex Rex Golub, I am pretty happy to see in print although it is far more academic in its tone, argument, and language than most of everything else I have written. This is in part because the article is more theoretical than ethnographic (hence the journal, Anthropological Theory) and tackles the question of liberalism alongside hacking. It seeks to demonstrate that these can be talked about 1) together and in cultural terms 2) that we we can identify some cohesive elements to hacking and liberalism, in part by placing them in conversation with each other 3) and yet we can also locate plurality and diversity within liberalism and hacking as well. This is a lot to tackle and cover in one piece under 35 pages and I am sure it could have been pulled off better but I think it is is a decent start to thinking about these questions. If you are interested but are allergic to academicalese, sticking to the Introduction, the Hacker Ethical Practice: Three Examples section, and Conclusion, will give you a taste of the arguments while avoiding most of the jargon. The irony of this article is that even if it hits at some pretty theoretical issues, it was provoked by a mundane conversation and disagreement I had with one hacker, Karl Fogel, over another hacker, Kevin Mitnick. After returning from the hacker conference, HOPE, I had dinner with Karl and told him about Kevin Mitnick’s keynote speech, which I found particularity enjoyable and entertaining. After calling Mitnick a hacker, Karl responded with the following: Kevin is not hacker. He is a cracker. Though I think I convinced him that cracker may not be the best word for him (and he convinced me there are differences between hacking, noting perceptively that his primary motivation seemed to be getting access to something he wasn’t allowed to have access to that is, it was more about breaking the rules and the thrill of crossing a social line, than about learning a technical system. ), I decided that I wanted to write a piece that squarely addressed tensions and differences among hackers instead of whitewashing them away as most authors, journalist, and even some hackers do.
Although most of the time, it seems like it is the Karl-type hackers who accuse the Mitnick-type hackers of not being true and authentic, recently I have been in a few situations where the tables were turned. For example, last year I was having coffee with a 2600-type who insisted that hacking on Linux was not hacking at all (not innovative enough, according to his world view). Another example I came across was in a recent Phrack issue where the prophiled hacker, the Unix Terrorist, takes a swipe at (well honestly at everyone and everythin) but when he is talking trash about who is and who is not a hacker, he singles out F/OSS developers:

Linus Torvalds isn’t a hacker! Richard Stallman isn’t a hacker! Niels Provos
isn’t a hacker! Fat/ugly, maybe! Hackers, no! And what is up with
the use of the term “cracker”? As far as I’m concerned, that term
applies to people that bypass copyright protection mechanisms.
Vladimir Levin? HACKER. phiber optik? HACKER. Kevin Mitnick? OK,
maybe a gay/bad one, but still WAS a “hacker.” Hope that’s clear.

Of course, one can play the game of defining the authentic hacking (and it makes sense for many to do this!) but my interest as an anthropologist has never been to draw a bright and clear boundary between good hackers and bad hackers. or “real and fake hackers,” but instead to describe and grapple with the tension points and internal ambiguities among hackers (my whole course is designed around this theme, in fact). This is not to say that anything goes in the world of hacking (that is, I don’t consider any computer break in a hack; I often just call it a crime) but if there is a group of people calling themselves hackers and thinking to some degree of the ethical implications of their actions, as an anthropologist, this is enough “social evidence” to start asking some questions about the political and cultural significance of their actions.

Cooperatives South West is working in partnership with the Regional Infrastructure for Social Enterprise (RISE) to hold a Trade Fair with support from CDA (BRAVE Ltd.), Social Enterprise Works, Co-opportunity and Watershed Media Centre. It will be held on Monday 1 December at the Watershed in Bristol. Due to the size of the venue, the number of exhibitors and delegates is limited, so complete the booking form as soon as possible. There is no charge for cooperatives to attend or to exhibit (but there will be a charge to cover catering and venue costs if you book but don’t attend or cancel). The Social Enterprise Photography Competition is now launched across England. Regional winning photographs of the competition will be featured at the Trade Fair and the winners will be presented with their awards by a special guest. Please encourage all your friends and colleagues to submit photos of social enterprises. (Thanks to Viv at Cooperatives-SW for the above information.)

Here are some tricks that you can use to ensure that your announcement to debian-devel-announce has maximal negative utility. hide who's talking Make sure that your announcement does not start off by making clear who's speaking. The announcement will have a From line with your name on it, and that's good enough. Everyone knows who you are, what groups you're a member of, and can guess what group you're speaking for ... or whether you're just speaking for yourself. Throughout the annoucement, be use to use terms like "We plan", "let us describe", "we are considering", "This is where our proposal comes in.", etc. Maybe in a footnote include a clue such as a mention of "the NM-Committee", but be sure to not sign the announcement with the name of any group or team or set of people, so that the reader is left guessing about who this "we" is all the way to the end and beyond. (And hey, "cabal" is a fun word.) weasel words Scatter throughout the announcement some vaguely worded digs at things you disagree with. The key here is to make clear what you really mean, while providing enough plausible deniability that you can deny having said it later. So you might say ...

Some time ago a few Developers thus went and pushed forward the "Debian Maintainer" status.

... Thus implying that this was a few malcontents who should be ignored. Sure, the whole project voted for this, and so you should be sure to allude to that vote somewhere else. Maybe in a different paragraph entirely, you could refer to "Debian Maintainers (DM) [GR-DM]". (It would be excessive to have that footnote refer to a bogus url like http://vote.debian.org/something.) the big lie Make sure that your announcement starts off all bright and cheery on the surface, with just a hint of deadly steel jaws underneath. Something like:

If you are an existing Debian Developer or Debian Maintainer, don't be afraid, we are not going to take anything away from you.

Natter on for many, many pages of trivilities, good ideas, bad ideas, half-baked ideas, conflicting acronyms, and useless footnotes. Then spring the trap:

In future this will be a list maintained by the NM-committee. At the time of migrating from the old to the new way, Ftpmaster will convert the existing DM-Upload-Allowed fields into that list, so there should be no interruption in your ability to upload.

And ability to upload is all that matters. Who cares about the regression back to the tyranny of unix permissions? Who cares that DDs won't be able to decide when they trust a DM to upload their package, or that DMs won't be able to sign up quickly and easily, or that DMs will have to petition a disinterested committe to change anything? Nothing will have changed, nothing will be taken away, nothing to see here, move along: The big lie.

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.

One month with Emacs and counting - Part 1 Straight to the point: since mid September I've been using Emacs, trying to evaluate whether I was willing to switch from Vim to it. Yup, that's true, me (user of Vim since the day I've started using GNU/Linux 10 years ago, (not so) active maintainer in Debian of vim and related packages, author of some popular Vim extensions and of vim-addon-manager) it's considering switching to Emacs. What is worse is that I've de facto already switched. May jamessan forgive me. OK, that was the hardest part to write, now ... This choice will have an impact on me: partly because I'm quite sure several fellow DDs will start making fun of this story , and partly because as many geeks I've always had strong opinions on the editor war. Switching side ain't easy. Hence, I've decided to write a small (2-3) series of blog posts on the issue, to future memory. The post you are reading is about why, since a few months ago, I wasn't willing to give Emacs a try, and how I've changed my mind. Why I wasn't willing to give Emacs a try, but then changed my mind I love knowing tools which can improve my workflow, no matter the task. Editors happen to be at the intersection of many tasks, hence knowing well his own editor and feeling satisfied about it is quite important. This is even more so for free software hackers which, for a reason or another, happen to use the very same editor for a lot of different tasks; in my case: programming, conf file hacking (i.e., playing the sysadm role), mail writing, and everything in between. I've started using vi on Solaris around 1998, then switched to Vim starting from version 4.0, and then followed all its releases up to 7.0. I consider my "Vim karma" to be quite hight and I've delivered several talks about using Vim for LUGs and other free software-related events. Still, I've always been hit bit several minor nuisances and glitches of Vim which couldn't be fixed by simple configuration tuning or add-on implementations (more on this in a future post). In the quest for the perfect workflow, those glitches have made me try several times other editors hoping for more satisfying work environments. Of course Emacs was one of them, which I've tried repeatedly during the years; the last time was circa 2006. For one reason or another, after a few days of experiments, I've always decided to give up with it. Why? Various reasons, listed below, together with an explanation of what (I think) has changed since then.

1. Poor Unicode/multibyte support. Support for whatever Unicode encoding was close to null. It was not available in the legacy editor, and you had to use something called MULE, to be specifically enabled. That was so 60's, and rather hard to use. Now (apparently starting from Emacs 22.1, June 2007) finally you have built-in Unicode support and the needed two variables for setting the input encoding and the file encoding, which is basically all you need. Looks easy once you have it ...
2. Lack of "modern" UI toolkit support. Yes, I do live in a console and invoke my editor from it, but nevertheless for long coding sessions I do also love having a nice GTK+ window containing my editor using settings which smoothly integrated with the graphical settings of my desktop environment. Maybe I'm getting old, maybe GNOME has changed my perceptions, but why the heck I had to tolerate different monospace fonts in my gnome-terminal wrt my GUI editor I never understood. Firing up Emacs was like getting back in time of 15 years, and if a geek having a maximized terminal on most of its workspaces had this feeling, then something was really wrong. This has changed: starting again from Emacs 22.1, the editor has frown support for that "bleeding edge" technology called GTK+. Finally you can use Pango font faces and avoid the time travel feeling when switching from a terminal to your GUI.
3. "Dead upstream" syndrome. As we all know by experience, choosing a free software product is not only a matter of evaluating bugs and features, there are other environmental factors. A notable example is how active upstream is. A few of us will use a product affected by the "dead upstream" syndrome. That's exactly what I was feeling about Emacs. The first argument I can offer to back that feeling is again the Emacs release history (noted that "small" hole between 2001 and 2007? Rest In Peace release early, release often ...). The second argument is the bug tracking system: there was none, bug discussions happened only on the development mailing list and the bug tracker was a text file on CVS! (Yes, Vim doesn't have a proper BTS either, but I was looking for reasons to switch from it and hence looking for something better in several respects.) That has changed completely, as I discovered only at this year DebConf thanks to gismo. 2007 has enjoyed 1 Emacs release and 2008 already two. They do have a BTS now and guess what? is dear old debbugs. According to my first experiences as Emacs bug reported the maintainers are very reactive and also friendly in dealing with bug reporters. Finally, also keeping up with snapshot releases in Debian is entirely trivial, thanks to Romain's repository.
4. Poor performances & memory consumption. This goes in the direction of probably the most popular joke used by Vim zealots in the editor war: Emacs is a nice operating system, but lacks a good editor, or something such. In the past I had the impression that starting Emacs was really slow and that generally the memory footprint was too high to be acceptable. You know what: starting a full-blown gvim with a good deals of add-ons (and I used quite a lot of them, that's why vim-addon-manager was born) is not that faster. And on the contrary, firing up an emacsclient is way faster than starting up a new gvim instance. Regarding memory consumption Emacs is still "gaining" the battle. Still, one has to keep in mind the different workflow: with Vim you are encouraged to enter and exit the editor (not without drawbacks, as I'll discuss in a future post), while with Emacs you always use the same one. It turns out that via emacsclient the resulting feeling is the same as having multiple editors (as you can fire them up as separate windows or in separate consoles), still sharing all user memory. A final comment on memory consumption while looking at my top sorted by decreasing RSS memory: the top process is xulrunner (from the browser) with 356Mb, then Xorg (159M), pidgin (128Mb !!!!), trackerd, gnome-terminal, gnome-panel, ..., Emacs shows up with 51 Mb at the 7th position. Yes, it is not the thinnest editor in the world, but on average machine it doesn't really matter at all.

In the next post: how to switch from Vim to Emacs, without loosing your mental sanity. (Whether I did succeed wrt sanity is up to the reader to judge.)

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?

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

At the moment, on my desktop, I have all my regular work, plus I've got a qemu-based ARM system (slowly) building a package I need to test, as well as a kvm-based amd64 system running pretty fast to test a patch to parted. Now, I'm well aware that emulation isn't an alternative to testing on real hardware all the time, but having one real machine on the desk beats having three, for most purposes. So, everyone involved in qemu and kvm the kick-arse programs they are today: thankyou, from one happy hacker.

I am all for models and examples, and well, Nerd Girls, is such a web portal meant to celebrate “smart-girl individuality that???s revolutionizing our future.” And they “want to encourage other girls to change their world through Science, Technology, Engineering and Math, while embracing their feminine power.” That message is all good and fine but the profile page is just a little too homogeneous and “made up” and actually just looks fake as fake can be (and what is UP with those dumb glasses they are all wearing?!). Sorry to say this, but all those “chics” look like they are fake nerds and are really models for Seventeen magazine or soft-porn movies. Is Nerd Girls a joke? Or is it real and just not for Ugly (or regularly looking) Nerd Girls? update
[h0mee] lol
[h0mee] actually what it really reminds me of
[h0mee] are those inspirational posters you see in high school meant to inspire students to study harder
[biella] like this one update again (sorry, the comments on my irc channel are just too good to ignore: [Atala] lol one of my friends just said the site seems like a thought experiment on what would happen if MTV bought Bitch magazine.
[rex] EXACTLY

I am all for models and examples, and well, Nerd Girls, is such a web portal meant to celebrate “smart-girl individuality that s revolutionizing our future.” And they “want to encourage other girls to change their world through Science, Technology, Engineering and Math, while embracing their feminine power.” That message is all good and fine but the profile page is just a little too homogeneous and “made up” and actually just looks fake as fake can be (and what is UP with those dumb glasses they are all wearing?!). Sorry to say this, but all those “chics” look like they are fake nerds and are really models for Seventeen magazine or soft-porn movies. Is Nerd Girls a joke? Or is it real and just not for Ugly (or regularly looking) Nerd Girls? update
[h0mee] lol
[h0mee] actually what it really reminds me of
[h0mee] are those inspirational posters you see in high school meant to inspire students to study harder
[biella] like this one update again (sorry, the comments on my irc channel are just too good to ignore: [Atala] lol one of my friends just said the site seems like a thought experiment on what would happen if MTV bought Bitch magazine.
[rex] EXACTLY

Since most readers of this blog are not fans of the DMCA, I thought you all might appreciate this terse and elegant insight about why the DMCA is such a failed law.

“The existence of the DMCA is an open admission that software has failure modes sufficiently severe that regulation by software alone cannot be trusted. The effectiveness of DRM software as a regulator is therefore dependent on the legal effectiveness of the DMCA … The DMCA creates a category of per se illegal software by outlawing programs that do certain things. But in so doing the DMCA aligns itself squarely against software’s plasticity. In making it illegal to create certain kinds of software, it tries to prevent people from taking full advantage of one of software’s greatest virtues: that software can do almost anything one can imagine.??? James Grimmelmann in Regulation by Software, p. 1756

Since most readers of this blog are not fans of the DMCA, I thought you all might appreciate this terse and elegant insight about why the DMCA is such a failed law.

“The existence of the DMCA is an open admission that software has failure modes sufficiently severe that regulation by software alone cannot be trusted. The effectiveness of DRM software as a regulator is therefore dependent on the legal effectiveness of the DMCA … The DMCA creates a category of per se illegal software by outlawing programs that do certain things. But in so doing the DMCA aligns itself squarely against software’s plasticity. In making it illegal to create certain kinds of software, it tries to prevent people from taking full advantage of one of software’s greatest virtues: that software can do almost anything one can imagine. James Grimmelmann in Regulation by Software, p. 1756

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.

Just received this comment from Jimmy Kaplowitz over in the US: “yuck, your country continues to turn into Big Brother: BBC News: Giant database plan ‘Orwellian’” Hell, yeah. That’s a reason why my support for the party is so weak at the moment. I’ve been working and writing against this since ST@ND and the Regulation of Investigatory Powers Act, which we were told was essential for crime-fighting, but actually helps gov.uk spy on parents making school place applications. Currently, I’m telling people Gov.UK Consults on Forced ISP Snooping: Please Say NO. If anyone has any doubt that the database state will be abused, look at some examples of Labour’s “terrorists” (at least, they had supposedly anti-terror measures used against them) since 2001:-

1. Wolfie, an 82-year-old peace-campaigning heckler at a Labour conference
2. Indymedia
3. a Frenchman in Suffolk who downloaded the Anarchists’ Cookbook
4. an Algerian pilot
5. the country of Iceland

and that’s ignoring gov.uk’s frequent data leaks. Noodles replied: “There’s a quote somewhere that goes along the lines of “If the Tory policy is looking sane compared to what you’re doing, you’re doing it wrong” that’s been applied to the Labour fascist state stuff.” Our terrorism measures are a joke, with loopholes that gov.uk can drive a truck through. They should be repealed and clearly-limited ones enacted, shouldn’t they?

I might regret this later, but until I recant:

• tscreen: Terminal Screen

This features several changes already, and a few more are pending. ObFilm: Aliens