1. How are you supposed to mount removable devices such as USB memory sticks, cameras, and so on, on Linux? I didn't know. So I went to look for a solution.

Assuming for the moment, that we deal with just a few rather static devices, such as USB hard drives, we first have the problem that instead of sane device names, they're mapped to random SCSI device nodes /dev/sd*. So you have no guarantees of their location. You need crap like udev for semi-stable symlinks in /dev/disk/by-id/ to enter in /etc/fstab. But it gets them wrong half of the time. Must be one of the gazillion race conditions that can be expected in kludges like that.

Even if the udev worked – which is doubtful, being molded with human waste as the role model – you still have a problem dealing with an arbitrary number of removable devices. They have different IDs – in the ideal situation, that any are discovered at all. So you'd need an fstab line for all of them. This is totally impractical. So is including fstab lines for all the /dev/sds – some of them might be non-removable devices, and generally it's better to choose the mount point by the physical device, instead of the random device node.

The mount command supports users mounting arbitrary devices, if your user ID owns the device. But that's trouble on several levels again. I think it's dangerous, and users shouldn't need to own a device to mount it, and have write permissions to it as a raw device. But even if you took that as an acceptable risk… how do you set the permissions? When /dev/sd* could be your SATA drivers and anything. Ha! The crap known as udev again, which is not meant for mere power users to customise.

Well, a better solution than dealing with udev is to write a custom sudo hack for mounting. But you still need to find out what devices are attached to the system and where. Well, time for another script.

Or maybe not.

SysFS is unbelievable crap! For most devices, it doesn't appear to contain any useful information, such as device models, vendors, serial numbers, etc. that could be used to identify the devices. That information is for usb devices in /proc/bus/usb/. But there does not seem to be any simple link between the files in /sys/ and /proc/, all the USB numbering being different and so on. You need complex hacks to even find all that information.

2. How does the “desktop distro” crap deal with all this shit? I guessed they use some sort of automounter. I didn't want an automounter, I wanted wanted to type mount myself. But after some detective work with a live image of fedora core in a virtual machine, I discovered that it uses HAL. And with some further detective work along those lines, I discovered pmount, which is basically the kind of hack I thought of writing myself, that allows users to mount removable devices under certain conditions.

But, pmount still doesn't actually list the devices you have attached to system, with reasonable names. Such as vendor, model, and serial number information. And that information doesn't appear to be easily available, as discussed above. Well, it turns out that HAL is exactly the piece that provides that information. It fuses the information from many sources and presents it as a hierarchy.

This sounds familiar. This sounds like SDL wrapping svgalib wrapping X wrapping whatever graphics libraries they had back then. Like pulseaudio wrapping alsa providing alsa providing OSS. Like, instead of improving existing solutions, somebody writing kludges on top of them because they weren't quite good or complete enough to begin with.¹ And then somebody repeating that on top of the previous kludge.

While udev is crap, it turns out that the rot runs much much deeper, down to the core. And I even once entertained the idea of finding the time to write a very simple FUSE-based udev replacement. Not anymore. Heck, not even inotify works in /sys/ (for the files of interest), so you need additional complexity and special-purpose hacks (uevents/netlink sockets) to listen to device attachment. And yet more hacks to find useful information for stable device names.

What do we have sysfs for at all? Wouldn't it be neat if all that information was available through it? And inotify to monitor changes? A neat file system based design following one of the core tenets of unix?²

But no, instead of simple solutions, multiple layers of kludges are added. Finally with pmount and some custom kludge, you can mount removable devices sanely. But to get to that point, to perform a simple mounting task, a daunting pile of kludges and complexity have been required: procfs, sysfs, tmpfs, uevent, udev, inotify (used by udev to monitor rule source code changes), hal, pmount, etc. Complexity upon complexity.

Linux is unbelievable crap, a totally unmanageable pile of shit. There's no simple consistent approach to anything, just special purpose hacks upon special purpose hacks.

3. I tried to find out whether FreeBSD (7.0, that I've installed in a virtual machine) is any better. Well, slightly. Once you plug in an USB1 device, camcontrol devlist lists some devices, but not all, with some identification info. Not all USB2 devices seem to work. They're seen, but do not appear as drives. And once you unplug the device… it panics!

So much for that.

In Windows all just works.

But while they're trying to make all just work in Linux, they're turning its innards so disgusting and so complex, that there's little reason to choose Linux over Windows. It's not a nice simple OS to mold to fit your tastes anymore. It's a complex corporate beast. A poor attempt at writing an OS for the average joe, supported by nerds who have nothing more worthwhile to do than brag about mastering overcomplexity of their own doing, and subjecting others to it.

There's the saying “Linux is for those who hate Windows. BSD is for those who love unix.” Unfortunately *BSD also can't avoid the crud that comes with the World Domination -infected X-based userland. They also suffer from the distro-centric software distribution model. And, yes b-tards, your ports collections are distros.

---

¹ Another example of not improving basically good but incomplete designs is the replacement of the locale system with an UTF-8 monoculture.

² Like Plan9, which unfortunately isn't a practical everyday operating system, and they're totally lost wrt. user interface ideas. Actually, they plan on using Linux as a driver due to their poor hardware support. Well, when it comes time to upgrade or switch computer, my current plan is on using Windows as the platform for GUI apps – ah, the bliss of not having to touch Gnome/Gtk+ Filechooser and all that crap – and the driver for some old version of Linux or *BSD in a virtual machine (running only ion, xterms, and text mode prorgrams for occasional hacking). Even new versions of these operating systems still do not offer such a fundamental feature as working hibernate or other form of session saving, and thus contribute to global warming.