Udev sucks
Udev sucks. Yet again I noticed today that Debian had inconspicuously
installed that over-complicated plague on my system. The /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, which is
an excellent reason to use Windows.) Udev itself is also extremely
slow at boot: intead of having structural configuration files
for its rules, and building a fast hash table or search tree of them, it
appears to do a linear search by executing 10000 lines of shell
scripts1
for each device. Such a design doesn't speak well of its developers'
understanding of the fundamentals of computer science.
I put the package on hold in aptitude, but I'm afraid I will 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 file system can do the job.
Udev is a fragmenting death blow to the simple file system
based unix design. It adds unnecessary complexity, special cases upon
special cases, instead of using the uniform interface, the file system.
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 of
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 secondary2 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.
1 Update: Newer versions are no longer shell scripts, but still use a cryptic proprietary config file format. Better that than XML, though.