Cleanup, Kernels, and Macs

This weekend, during my cleanup of old hardware,¹ I decided to take another shot at getting hel working. If you ever want to see slow then I suggest you try installing linux on a 68k Macintosh. Even a 68040 powered one. (Example: One pass of badblocks doing the read-only test took longer than 3 passes of the write test on skoll.)

Either way, after a while I finally got a basic install done. Due to the severe lack of memory I decided to grab the 2.4.21 kernel source and compile a very stripped down, machine specific kernel. Only, as I found out after the machine had spent several hours compiling, you can't. It seems that up until at least 2.4.21 the kernel had what was described in the 2.4.22 changelog as an "adbhid m68k screwup." Essentially what happened was that the kernel made reference to an undefined symbol called ADBREQ_RAW. So, if you wanted to compile a kernel on a 68k based Macintosh for the past 2 and a half years you've either had to use a 2.2 kernel or do without ADB support. I mean, it's not like anything important hooks up to the Apple Desktop Bus, just the keyboard.

It appears that 2.4.22 fixes this (not that the changelog entry is very definite about what got fixed), but given my habit of running a kernel that's one version behind the current stable one, I was unaware of this. (Compiling 2.4.22 right now and hoping it works.) To make matters worse, this apparently worked in the 2.2 series, but at some point during the transition to 2.4 it got broken and never was fixed until now.

However, this problem made me think of something again; when it comes time to look back at past linux kernels I don't think 2.4.x will be looked on favourably from a development viewpoint.

Let's consider the points, shall we? For starters, the kernel was late. I don't mean just a little late, I mean scoring #4 on Wired's top 10 vaporware of 2000 late.

But it finally got here, and after a few issues things became fairly decent for a while (or at least it's damn hard to search for stories about issues from that far back.) There was at least one serious bug, but that affected every kernel from 2.2.0 onwards.

Then, we hit 2.4.11.  A kernel that corrupted symlinks when you unmounted a drive and which forced the release of 2.4.12 just 2 days later. Ok, so that's one bad release, we'll allow that. After all, 2.2.9 was released just two days after 2.2.8.

Then, we have the VM management system swapped out in favour of another one.² Wait a minute, wasn't this the stable branch? That sounds more like something you'd do in the development branch instead of the production one.

So, one major issue and a rather questionable decision regarding the internals. Got all that? Because now we get into the teens.

• 2.4.13: Parallel port driver doesn't work. (It might not have even compiled, can't find out for sure.)
• 2.4.15 (aka greased-turkey): Corrupted the file system on unmount. Required the release of 2.4.16 4 days later.
• 2.4.18: rc3 gets released instead of rc4, breaking compilation on a variety of architectures. Gets fixed in 2.4.19-pre1 within a few hours, but doesn't get fixed in a production release for another 6 months.

Ok, so things have calmed down since then. The only major issue being a data corrupting bug in 2.4.20. I'll also give it that I really prefer 2.4 to 2.2 (if only because of iptables), but any kernel where you're better off waiting several months on the final stable release and picking and choosing the past releases doesn't say much for the development process.

Here's hoping 2.6 is better.

¹ I'll post pics of the massive pile of hardware that got thrown out once I get the film developed.
² I can't find when exactly this happened. It was sometime between 2.4.8 and 2.4.14 if I remember correctly.