Patrick Volkerding is the main author of rc.S, that's written in the script.

He didn't forget to explain anything: the purpose of its comment is to warn the user of the consequences of not making rc.udev executable, no more, no less.

I would have considered it a courtesy at least a slight mentioning of recompilation of some packages. I expect my words will not be taken as a criticism. Nothing farther from my purpose. It's only that the words in rc.S made me feel very comfortable.

ADDENDUM: one of the consecuences you mention, is the need to recompile some packages, provided you want every thing to function flawlessly.

I'm afraid that there are quite a few packages which cannot be (re)compiled without udev, dbus & Co. -particularly KDE/GNOME/XFCE to name a few. And some of those will not run without them being present -although you could probably link udev to /bin/true to ignore it.

If you are willing to mostly sacrifice using one of the 'big' desktops, you shouldn't have many problems. For device nodes, just install/use the old 'devs-*' package and be done with it. 'devfs' is very ancient -the current 'devtmpfs' does a fine job, but you might need to help it with special device nodes(create them in init scripts or add them manually). And for kernel modules, load them from rc.modules or roll yourself a nice monolithic kernel with everything you need built in.

As for there being notes in rc.S about desktop dependencies/compile order -I doubt that they are relevant there.

1 members found this post helpful.

I'm running my system with udev completely removed. With a kernel recompiled without CONFIG_SND_DYNAMIC_MINORS and CONFIG_DEVTMPFS_MOUNT. I've also had to recompile lvm2 and xorg-server.
Unless you know what you're doing you are probably better off with just setting rc.udev non-executable. I would think that both lvm and xorg should work with udev installed but disabled (with AllowEmptyInput set to false in xorg.conf, since otherwise it insists on getting input devices from udev). And a few other programs that link against udev work without modifications as long as libudev.so.0 is available (eg. lsblk from util-linux).
If you are using a (usb) scanner however, you'll probaby run into some problems. Since usbfs was deprecated some time ago, the only way to reliably get non-root access to the scanner seems to be with (udev, or) devtmpfs together with a hotplug script that figures out which usb device the scanner is, and chowns it to :lp (devtmpfs of course, need not be mounted at /dev, if you want to ha a static /dev).
Simply disabling udev shouldn't necessitate a recompile of core packages (except kernel, unless you use something else, e.g. busybox' mdev, to manage permissions of devtmpfs' /dev tree). But I don't know about KDE or other DEs and "desktop applications", I would gess that udisks and NetworkManager couldn't even be compiled without udev support.

2 members found this post helpful.

Ahhh, so the packages that need to be recompiled only affect the GUI behavior, that is, should you not use a GUI at all, the system behavior after the modifications suggested in rc.S would be flawless. And in distribution disk #1://ANNOUNCE.14_0, we read: Many thanks for your remarks about a udev-less system.

Thanks for your remarks, e5150. They are welcome in deed.
So no kernel recompilation? But you later add: Should I take it that setting rc.udev non-executable will necessarily need kernel recompilation?

I said it before at the very thread beginning that I'm running slackware 14.0 (x86_64). I repeat it here to help avoid confusions. This distribution uses kernel 3.2.29.

If you are going for a static /dev you would have to recompile the kernel without DEVTMPFS_MOUNT (which is enabled by default for the stock generic kernel in 14.0), otherwise /dev will be automatically managed by the kernels devtmpfs. So after each reboot you'd have to set all the appropriate permissions on the devices, and maybe create some that devtmpfs doesn't cover (devtmpfs would not detect when I insert an SD-card into my card reader, for example, resulting in a /dev/sdh for the reader, but no sdh1 when there eventually was an actual partition present.)
And you would get problem with your sound unless you disable dynamic minors for sound cards. The help message from kernel configuration states: "If you say Y here, the minor numbers of ALSA device files in /dev/snd/ are allocated dynamically. This allows you to have more than 8 sound cards, but requires a dynamic device file system like udev. If you are unsure about this, say N here."
If you're going to use mdev, or some homebrewn magic script, you might get by, without recompiling the kernel. But for plain old static /dev from the a/devs package, and rc.modules, I'd suggest recomiling without those two setting.

ADDENDUM: What I ment by "just" setting rc.udev non-executable, was, making it non-executable, as opposed to flat out uninstalling udev, which would require recompilation of stuff like xorg-server and lvm. Kernel recompilation is advisable regardless of the method by which you stop using udev.

1 members found this post helpful.

So, if I recompile without [CONFIG_]DEVTMPFS_MOUNT and without CONFIG_SND_DYNAMIC_MINORS, the scenario would likely be this: And I should respond saying N to the help message from the kernel configuration script (the ALSA thing). I'm writing under the assumption that I will use "plain old static /dev from the a/devs package, and rc.modules", to quote your words.

Your words cannot be clearer. May you have a fine week-end.

If you compile without DEVTMPFS_MOUNT you'll be able to use your static /dev, where you can mknod, chmod and chown as you feel is appropriate (if the defaults from the devs package doesn't suffice). And the changes will be persistent, so you wouldn't need to make changes after each reboot.
Note however, that you can still have devtmpfs enables. It's just that the kernel automounting that gets you into trouble, since devtmpfs creates only the device files that the kernel thinks are needed (similar to what udev does), but (unlike udev) everything is owned by root:root. So with devtmpfs mounted at /dev, you would have to use something like an rc.local that chowns and chmods everything that user needs access to. Creating a /dev/devtmpfs and mounting (by way of fstab) devtmpfs there for reference, might be a good idea.

(It might be possible to unmount an automounted devtmpfs, (maybe `umount -f /dev`?). But you would still be stuck with dynamic minor device numbers for sound cards. So, recompilation is probably your best bet.)

(There is also CONFIG_DVB_DYNAMIC_MINORS and CONFIG_USB_DYNAMIC_MINORS, which requires udev, but they aren't enabled by the stock kernel, so you shouldn't have to take care of those, unless you've explicitly enabled them yourself.)

1 members found this post helpful.

Well, I think after studying this thread and following the advices contained in here, I will be able to enjoy a fully udev-less system (please forgive my clumsiness in understanding your previous post). What good or evil can come out of it is a thing to be seen a posteriori. Plus I see I'm not the only linux user who made up his mind to settle things that way. By the way, may I ask you which is the operating system where you have "completely removed udev"? I mean what linux distrubution and version.

Well, I think it started with slackware 11, when I first ran into a problem where the "proper" solution was to (re)write a udev rule. And it just seemed simpler to uninstall udev. Since then I've run through all slackware(-64) versions, without using udev (I went from 14.0 to current shortly after it was anounced as beta).
(But about once a year I seem to forget what I dislike about udev, and try it out for a few days, but in the end udev always tries to outsmart me (by deciding that my midi-controller should be the primary "sound card", resetting my carefully set permissions, or taking forever to load firmware during boot...), so then I go back to the sanity of the good old days.)

1 members found this post helpful.

Yes, forgetting things like that can be not an uncommon occurrence for people like me, I can tell you. In many systems, I have always asked for minimum automation. When the system is very complex, some things one is forced to let them be automatic. But I prefer manual control over automation and, because of this, little and simple systems over large complex ones. Another reason for this preference is that little systems are easier to understand whereas with larger systems, the number of things one must resign to understand is too great for my taste.

The old days were certainly good and certainly sane. I could, for instance, play with disk direct access, reading/writing whichever physical sector I wanted, or write a program to put the machine into protected mode and go back to real address mode (80x86 processors) after having done some fun things. I could not even dream with doing that with present day operating systems, whereas in those days, a couple of weeks reading the 80286 programmer's reference manual was enough to understand protected mode, and another couple reading its numeric suplement, enabled you to play with the floating-point processor (NPX).

I don't think you did experience the good "old" days. Otherwise, you would not have been unaware what "devfs" meant and wanted to use it.

The "good old days" were not exclusive to Unix, though it was one of the oldest OSs. Anyways, perhaps I should restrict my use of those words to the time from the launching of the first desktop computers --there were quite a few of them before the IBM PC-- until some given date.

That's also why we had HAL and Hotplug which managed devices and auto-mounted drives. It wasn't perfect but it was a lot more sane than udev's rule-kit which still just barely works as well as DeviceKit's less than stellar track record.