devd and udev are similar in functionality. Other than the fact udev was coded for Linux and devd for BSD, they share somewhat similar functionality, but their code is different on many levels.

devd, for a while, required hald as a step-in to serve as a hardware device manager as well as other functionalities it lacked at the time. However, devd has matured since FreeBSD 11.0 has been worked on, and it's very close to the same functionality as udev, however, it does not have the same interfaces at the API layer which is why desktops like Xfce and such still lack automounting of hotplugged USB drives. udev also provided gudev for gobject-introspection and usage of the Gnome Virtual File System for hotswapped USB drives. This means udisks can not be used to handle automounting and limits some functionality back to standard user based controls.

I figured... But, I am almost willing to try anything since udev is such a piece of crap. I've got a message right now I am trying to fix where the KERNEL consistently names a device and udev changes it, with no directive to do any such thing. Why on earth would anyone ever program a DEFAULT behavior like that? It's just nonsense to change a behavior that's worked for decades with no good reason.

You can try mdev from busybox + devtmpfs. I use it in my system last five years (desktop+notebook). It simple, fast and debug friendly.

Useful links:
http://git.busybox.net/busybox/plain/docs/mdev.txt
https://github.com/slashbeast/mdev-like-a-boss

Mdev was experimented with by a few of us. It is harder to get working though. Mdev-like-a-boss helped greatly. You should try mdev with busybox-init.

Udev isn't totally bad. It works, but it requires a bit of taming.

Vdev is still being worked on and should be nearing its trial stages. When completed it should be able to replace udev outright.

Why?

Mdev requires more configuration and often most devices have to be manually added to the system to work properly. Mdev isn't as automated as udev is.

System (if we talk about LFS) should work properly without mdev or udev. Devtmpfs enough for this. We need mdev only if we want some hotplug reaction.

I'm not saying that Linux plumbing doesn't need work either. I just think a lot of what's being done is of poor design. (Though, I can't speak for the packages you two mentioned.)

SysV is still fine for servers, but something for desktop, particularly mobile, is needed. At the same time the replacement need not be more than a process manager. Personally, with what we know today, I think a completely new way of doing it is in order that doesn't involve consolidation.

At the same time, some of the Unix philosophy guys are going a little too far too. Mainly in the area of interpretation of KISS and the idea that programs should do one thing only. If every program did only one thing, we'd have hundreds of thousands of executables in a single desktop. Which, to me, sounds just as complicated as one program that does two thousand things. Imagine a web browser that required a separate exec for images, sound, forms and double that for two tabs. The kernel does more than one thing, so does the CLI and there are commands that do multiple things that manage to do them all well.

When it comes to KISS, I prefer Einstein's idea, "Everything should be as simple as possible and no simpler." So, I tend to think of such things like a floating point number... How much do I need to carry and how much resolution is enough.

1 members found this post helpful.

You, right - but only if program still do one thing
For example: ffmpeg have many av format, av filters, etc, but it only work with media - it not file manager/database/text editor.
Kernel also work only with hardware.

IMHO we already have good and simple stack for hardware:
kernel - work with hardware
devtmpfs - show devices to userspace software
proc/sysfs - control kernel and hardware
mdev/udev - control hotplug reaction

I see where your coming from... Perhaps my understanding of "one thing" is too sharply focused.

The purpose of writing programs that do one thing and does it well was the issue of quality software over quantity of software. If a program does only the job it's intended to do, fixing problems becomes trivial.

You can run LFS without udev or mdev, if you know how to use kmod's mknod utility proficiently.

BLFS has a section on how to set up device nodes in /dev and use the /etc/sysconfig/modules script to manually load drivers.

You right, but on modern kernel we can just set CONFIG_DEVTMPFS=y CONFIG_DEVTMPFS_MOUNT=y.

Also, it quite easy to configure mdev for loading modules, just one line in mdev.conf:

Not entirely certain, but I'm not certain if we ever crafted an mdev init bootscript that was useable by LFS.

The view of "simple" I mention is apparently based on other people's misunderstanding and misquoting the philosophy. Some people explain the "one thing" as if it means singular in activity. I think that's going too far. One domain, sure... Needing a separate executable for every menial task is too much though.

Mdev-like-a-boss has an mdev bootscript that I modified for LFS. It worked fine. Actually Busybox init and mdev both worked well for LFS. The troubles began with BLFS where packages exist that expect udev to be present. And I had to learn how to write in mdev.conf to get predictable handling of USB devices. Anyway, it all worked and was interesting, but I went back to Eudev (especially since the LFS book returned to it at about that time). I still use Busybox init and my own bootscripts though.