BSD wanes

In 1999, I had collected a bunch of Unix architectures from the University of Colorado's hallways. Once every year or two they would toss all their electronic garbage into the hallway on wooden palletes for the Property Disposal department to cart off and auction to scrap metal dealers. From them I got Sun3's, old lunchbox SPARCs, a Mac II. I got an Alpha ``avanti'' from onsale.com, an NCD 15b from Willows Software. I bought a used Sega Dreamcast and ordered an Ethernet card for it from lik-sang.com. I'd used some HP 712's, B-class desktops, and K-class minicomputers working at Evolving Systems. And working at Willows, they had Irix and AIX boxes. It became clear that every architecture had some neat, redeeming quirk, except the PeeCee. And I'd learned at the university that Intel's instruction set, both the current one and their earlier ones, was the most stupidly-designed in the industry. Maybe I can't always pick which computer I use, but out of ten architectures, I ought to be able to pick one and say ``I want nothing further to do with this crap.'' so, I swore in 1999 that I would never buy another i386 system. Since then, what i386 I owned has attritted or been thrown out, and I own no PeeCees whatsoever. (then I gave up and bought an old Thinkpad X40. I'll probably buy more i386 crap soon, but it's still crap.)

The reason I started using NetBSD was that I became intensely frustrated with Linux on the Digital Alpha, in particular with the lack of release engineering: you can't download kernel sources from the usual master sites, because even on the ``stable'' branch, Linus builds it on his PeeCee and releases it. ``Releases'' aren't even tested on anything except Linus's PeeCee. For notPeeCee's, you have to get specific kernel versions and then go hunting for all these ``patch kits''. Even for an XBox, which is only just barely not a PeeCee, you have to do this. RedHat and IBM have employed most of the serious Linux developers for many years, and in many ways this is great. They do so with a level of transparency that gives Sun something to strive towards, and if honestly examined, outs Apple for the double-talking scheming proprietary worms of the OS world that they are. But it also means RedHat and IBM overwhelm the goals of the project with raw productivity. It's a wonderful thing about the open source world that writing working code is mostly enough to give you control over the direction of a project, and I don't wish to change the following fact but: the logical consequence is that every open-source project, like it or not, is nakedly for sale, cheaply, to any corporation that wants to throw developers at it.

RedHat and IBM have bought Linux and defined the Linux culture, which is a bit different from the Unix culture. It's a PeeCee-based culture:

The last one needs more explaining. In Linux, there's only one kernel branch: The Future. RedHat ironically makes money mostly by selling you a fix for the broken culture they nurtured, by getting you closer (maybe not close enough) to the releasing scheme of Solaris, HP-UX, AIX. There are three kinds of change:

With a new Linux kernel, you get a mix not of your choosing of all three. Will there be more bugs or fewer bugs in the new version? Who's to say? One trick is to keep upgrading until you find something that's not broken, then hold onto it as tightly as possible, knowing that eventually security problems or your replacements for broken hardware will force you back to the latest, again broken, system.

RedHat, IBM, other Linux distribution vendors, optimistically, filter these changes out so you can get the first two kinds of changes with less brokenness introduced by the third. But support for new hardware routinely breaks old hardware.

In practice, RedHat and IBM have their business priorities. Their cost-conscious customers are not too interested in support for hardware more than two years old, and definitely not for anything non-i386. They break old hardware all the time, and aren't interested in fixing it. That's what drove me off Linux onto NetBSD.

A side-effect of this voting-with-lines-of-code system is that system integration is supposed to happen magically. Would you like to do something moderately minority? Examples:

In this case, the majority will break your shit faster than you can fix it. You won't spend your time working on the thing that interests you---the different thing you're doing. You'll spend it learning how Gnome works so you can fix some arcane endian bug that shows up on big-endian powerpc machines but not i386, untangling OpenOffice's build system because they've started assuming you have the Gnu version of some Unix tool, forward-porting XBox or SATA patches that no longer apply to the latest kernel. This isn't related to what interests you. It's related to what other people are touching and breaking.

Back then, there actually was a development branch for Linux---when the digits after the first decimal were an odd number, that was a development version. The RedHat guys would actually do all their work on the stable kernel, not even comitting it to the development branch at all, and they had no trouble pushing changes through. Non-RedHat developers had to do the work of forward-porting RedHat additions to Linux 1.2.x into the 1.3.x development branch, so a lot of the time people using development kernels actually lacked features. Now, Linux seems to have given up on development branches entirely---instead, developers work against the stable kernel, and they keep their work inside ``patch files'' that they perfect and push, push, push until someone gobbles them into the so-called stable kernel. My Grub menu says 2.6.15.1+libata1 because I've added Jeff Garzik's SATA pachset.

It was (is) a total disaster, and it was preventing me from getting any work done. All I did was keep trying patches and then rolling them back, hoping I'd find one that actually stayed up more than a day and supported my AIC7xxx SCSI chip. After deciding to use BSD on my Alpha, I used NetBSD because I liked their web page more than OpenBSD's. And it was great.

I think the main reason I kept using NetBSD instead of another BSD is that I have a long-term goal of becoming a good programmer. I admit to not making rapid progress on that, but I think reading NetBSD code and watching NetBSD design decisions helps me more than reading and watching Linux, and I believe also more than FreeBSD or OpenBSD.

However, lately it seems like NetBSD and Unix in general is in a real crisis. Problems that were introduced one or two years ago are not getting fixed---problems like (as of 2005-10-30):

My favorite one is ``well fix it yourself if you want to complain about it so much.'' Fix threads myself? No thanks. And I am goddamn well free to complain about whatever bothers me---don't you fucking DARE try to shove a sock in my mouth like that. You open source people, your thread implementations suck, have always sucked, and have always sucked for a very long time. You can't even keep up with Windows. Yeah, that's right. You heard me. I'm saying your threads suck. The correct response is, ``yes, they do, and it's unfortunate.'' The response, ``you are not allowed to criticize my work without offering to fix it for me,'' is a nice little trick certain people have distilled out of a hazy understanding of the open source ethic, but it isn't a reasonable thing to say.

The crisis isn't so much that these problems exist. It's that they've existed for several years, and they aren't getting fixed. As time passes, BSD and other free Unix accumulate more of these problems, like fish taking on mercury or birds accumulating DDT. The projects are turning into lurching jalopies. I see a future in which these systems all have to develop cross-build architectures because they aren't stable enough to self-host, like Mach/4.4Lites.

For architectures other than i386, that day is basically already here, but I'm saying pretty soon we're going to be cross-building BSD from under Linux or Windows, and running it only inside emulators, using it only in classrooms and computing museums. no decent filesystems, no self-hosting debugging ability, inability to provide the API (threads! Javur!) needed by programs one can't live without like Firefox, Postgres, OpenOffice---how long before our kernel can't even handle running gcc? It's already unable to handle gdb!

But, who knows. Maybe we just need three years to get scheduler activations working instead of two.


rants / map / carton's page / Miles Nordin <carton@Ivy.NET>
Last update (UTC timezone): $Id: netbsd-wanes.html,v 1.20 2008/04/22 23:54:07 carton Exp $