1. Almost everywhere in GNU/Linux that I dare to look into, I see complex kludges layered upon complex kludges. The Gnome ethos of “either you're one of us (developers), or you're an idiot user” is day by day more predominant everywhere down to the system software. Linux is becoming an idiot box; a nanny operating system. The complexity and the idiot box ideals are killing the power user, and the spare time developer. It is becoming impossible to do anything in Linux, unless you're willing to succumb into being an idiot user with no sense of usability, or you're a member of the elite that is turning it into an unusable idiot box, and share their goals and ideals – that it should be a idiot box running weakly interacting massive programs, WIMPs.

Well, I have no ties to those engineers of gnomification – the McDonaldisation of the user interface – and if succumbing into being an idiot user is what's in store, there are better options than Linux. I rather use a well-polished albeit non-free idiot box, than the DIY idiot box – a contradiction in terms – that Linux is becoming: nothing works well enough to use as an idiot box, and yet it's becoming increasingly more difficult to use it in any other way either. Even a moment's reflection on where Linux is heading, and the thought of joining all the Windows gamerz and lamerz, or even the iSmug Mac users, no longer sounds that bad. I just can't take any more open sores. Indeed, I've already given up in the browser department (although, ironically, Firefox does suck slightly less under Windows than Gnomenix). Most of the rest of the few good specimens of free software being available on other operating systems as well, the only umbilical cord to I have left to the “free” (as in developer, not as in power user) *nixes is Ion – a shining beacon of usability, all alone in the night.

2. Let us take a look at the kernel. The megatonne monolith is impossible to compile these days: the task of compiling a kernel has become serious Work, as opposed to play. There are far too many options, and you are bound to miss many important ones. The typical kernel configuration process these days takes a week or more: one day trying make oldconfig, to notice that it doesn't work. Then another day writing a configuration from scratch, followed by countless fix-and-reboot cycles, lasting from a few days up to a month, until you give up. After that you still have to spend a few days restoring the system to its old state.

You want an example? I had been using 2.6.19.3 for a few weeks, after numerous fix-and-reboot cycles in the first days after the initial compilation. Then one day a few weeks ago, I noticed someone constantly banging my SSH port: apparently iptables were missing. Recompilation and reboot it was then: apparently the crappy kernel can't even load that module unless it has been compiled with the support in the first place. A few days later, I then wanted to mount my MP3 player. Guess what? The NLS tables were missing, broken, or something, and it couldn't do that. That was when I switched back to 2.6.14 (that has other problems that I'd been trying to fix by an upgrade – with no luck). It's just impossible to compile a working kernel these days anymore: there are too many options that are so easy to miss; and if you try to use your old configuration, the system automatically misses them.

The distributions have stock kernels, you say? Yeah, they do. And you know what? They suck. They try to load every single module at boot in random order. That takes literally ages, and the drivers and devices end up in the wrong order. For making the boot process faster, they want you to build a new initial ramdisk with tools that demand udev. What happened to a simple file listing the modules that the kernel should load? What happened to $pkgtool install kernel-module-drivername? I neither want nor need idiot box plug&pray systems. I just want to list the modules I need in some simple file on the boot file system, not build new initrds. I want to install and load the modules as needed, not load a huge monolith with shoddy autodetection. But no, they can not provide a simple way to configure anything: they want to provide a DIY idiot box, that sort of works without configuration, if your standards are very low. DOS had something almost right: configuring IRQs and DMAs, and loading drivers into high memory, was nothing compared to the task of compiling a Linux kernel, and fighting with shoddy automation.

And as for correct device naming – you guessed it – they again want you to use udev – iDev they should've called, for iDiot. But that is yet another piece of idiot box kludgeware: it also takes a lot of time at boot, and it's impossible to configure your symlinks and permissions in a nice and simple manner – through the file system – and you either have to spend time studying the awful mess of configuration files randomly overwritten or obsoleted by the distribution, or succumb into using the distribution's idiot box defaults.

Unfortunately, *BSDs aren't much better than Linux. While they do avoid the udev crud, they still suffer from the same crappy userland.

3. As for the userland, much I have already covered in other postings. So let us not dwell on Gnome and other user interface issues. I have also voiced my disapproval of XFuglyType (Xft) and fontconfig, but let us still return to them for a short relevant note. You see, fontconfig has a similar mess of configuration files as udev. This time, instead of a proprietary syntax, you have a complex unmanageable mess of XML files – the format itself an all-too-common idiot box virus – that have to be patched all over the place to get rid of these anti-aliasing fundamentalists' blocks. Some distributions have fonts.d sort of directories, but you still need to rewrite your own versions of a lot of these files, to get rid of these blocks without breaking everything else. Such rewritten configuration is a lot of work to maintain, not to even mention the work of compiling your own version of Xft on distributions that disable the bytecode interpreter, that is needed for fonts that one can tolerate staring at.

4. Everywhere, complex layers upon complex layers are being added. It's laboursome to even compile a lot of software, because they use flaky unfixable and unmaintainable autoconf cryptoware as their build systems. Once again, simple easily configurable Makefiles would be far better than shoddy automation that the clueless geek masses have been taught to uncritically demand, and that is very laboursome for the spare time programmer to provide. Indeed, even in general, things are becoming very painful for the small developer with little time in his hands. Especially this is the case, if you're not writing idiot box software, or something very basic, that does very little to interact with the system. Simpler old protocols and libraries are being obsoleted, primarily for reasons of idiocy and the NIH syndrome, and replaced with more complex and more specific ones. It is becoming a chore to be compatible with everything that the cult of the idiot box comes up with.

FDO provides an excellent example of spewing out ultra-complex wheel-reinventing specifications with the goal of turning X into a WIMP idiot box. Nobody working an alternatives to the standard WIMP crap has the time to support their complex¹ over-designs. Being largely specific to the unusable WIMP desktop model, it's often even impossible. With software conforming to the FDO idiocies drifting away from the older simpler and more abstract protocols, the case will therefore likely soon be that there are two totally incompatible systems: the WIMP idiot box of their wet dreams (with blurry fonts, only), and the old software (mostly text mode software running within Xterm) used by the few remaining members of the dying breed of power users.

5. This would not have to be so: things could be done better. It is true that some of the old protocols and libraries do need to be updated. The problem is how it is being done. Firstly, there are things like udev, that is really an adhoc kludge on top of an old system, and should never have become “production” software. Adding layers of kludges upon layers of kludges does not work for long: every now and then you simply have to knock over the anthill, and redesign.

Unfortunately, a redesign isn't always a path to a good design, especially if it's done on NIH grounds by people with a tunnel vision; people who think that their size and their fonts fit all. As examples we have stuff like what the desktop projects spew out: protocols, libraries, et cetera that end up being worse than what they intended to replace. People with a tunnel vision of a WIMP idiot box, should not be let meddle with essential system software and protocols.

Finally, people who were born with silver bullets up their asses, cause a lot of grief: we see them using XML for everything, thinking that UTF-8 is the final encoding, so that abstraction is unnecessary, and so on.

Good designs are simple. Idiot boxes are complex. Abstract tends to be simple. Specific tends to be complex. Keep it simple.

---

¹ For example, XEmbed, used by the FDO system tray protocol instead of standard window management protocols, was designed by illiterates suffering from the NIH syndrome, who probably never bothered even browsing the X manual, and certainly stopped before XGrabKey, WM_TAKE_FOCUS, and the ICCCM.