Udev sucks. Yet again I noticed today that Debian had installed that over-complicated cryptographic plague on my system inconspicuously. My /dev/dvdrom symlink was missing. My previous experience with udev was when I upgraded from the 2.6.7 kernel to the 2.6.14 kernel, and it suddenly started "working", so to say. Even /dev/null was missing permissions after that. Needless to say, it didn't take even a second for udev to disappear from my system after I noticed it was the culprit. But now it was back again, and gone again in a second after noticing it. Unfortunately, the kludge can't be completely removed without a reboot. And rebooting Linux is painful, as the session management support is poor at best, not to even mention how incomplete the software suspend feature is.

I put the package on hold in aptitude, but I'm afraid I have to keep constantly removing it and rebooting after upgrades, as everything wants to install that crap on my system. I don't want it! I don't want to edit cryptic configuration files when simple ln -s, chmod and chown that are applicable to similar tasks all around the filesystem can do the job. If some utility that automatically creates device nodes is desired, it should have /dev as the UI for the applicable parts, not its own cryptic configuration files. (And in any case it shouldn't allow any modifications to /dev if it does insist on its own configuration files.) It should back up any changes made there by the user to disk immediately, and remember them. Backing up changes at reboot (like devfsd seemed to do once) isn't sufficient.

And as we're talking about /dev here, I want to voice my disapproval for the scsi-mapping insanity. Just when we got rid of the ide-scsi cd-writer insanity, they started mapping USB devices to essentially random scsi device nodes, so that you can't know where they will appear on boot. And that wasn't enough. They're moving SATA devices to scsi nodes as well. I'll have my SATA drive as the predictable /dev/hde, thank you. Of course, something like udev could perhaps be used to create more predictable mappings of these devices to names more indicative of the device if the tool wasn't so crappy as it stands, but I think the whole ancient device numbering scheme should also simply be dropped, never mind minor incompatibilities with some ancient tools. At the kernel level the identifiers could perhaps even be allocated as needed from a counter, it shouldn't matter much if they change, but to the user devices should be primarily identified by an unique identifier (serial number etc.) whenever possible and applicable (which is not necessarily always the case with removable media). A device might then appear as /dev/devicetype-uniqueid (e.g. /dev/hd-st3160023as.abcd1234) initially, but any changes to the name with mv and friends should be remembered. Udev indeed does hide such secondary symlinks somewhere under /dev, but it does not facilitate easy creation of usable aliases, as it insists on using cryptic configuration files, shadows of the real thing frozen in time, instead of reacting to ln, cp and the like.