udevd is dead, long live mdevd – libudev-zero shines bright

Getting close to our 4year birthday here and what more reason to celebrate than cutting one more tie to the IBM’s monolithic bloatware that is shoved down our throats by agents of dependence and control.

Thanks to the revamping of Kiss and its new commitment to independence, to offer a way to such independence, we noticed a tragic neglect of reality.  We started talking about independence from systemd, and all we thought it was necessary was to substitute pid1 for an alternative.  100 distros later, and many forks, seem to be systemd-free.  Some solutions pre-existed and worked, some fresher were hardly tried. Then came the substitution to systemd’s logind by consolekit2.

Then came the realization that not using systemd init, but using dbus and elogind, was the next worst thing to be doing, and while more and more non-systemd distros (on our long list) didn’t use systemd, they used – or later adopted elogind (void, slackware, and our beloved adelie, even antiX is using it here and there).  So beyond pid1 those systems were business as usual.  We then focused on the next best alternative, consolekit2 (which is recently receiving fresh attention) or not using it and dbus at all, which is fine for most of us wm, teminal, consoles users.

Now, as Kiss points out, udev is another piece that behaves as an IBM monolith in linux and it is our task to evade its dependence.  Maybe then we can set ourselves free, not so fast slick you will trip on your own myth here!  Most X-server subsystems depend indirectly to what udev provides, and IN THE WAY UDEV provides it.

Can we live without udevd?

Let’s recapitulate how wide this struggle has been, to not depend on IBM for your open and free software to work.

On the logind front, consolekit2 is not dead, this is old propaganda, especially with all its development from its BSD fork, consolekit2 is alive and well. But you can live well and prosper (as Spok the dialectical materialist said and Data agreed) without any logind.  I have for quite a while. Then there was the silly myth that wayland can not work without systemd/elogind.  How does a protocol not work, things work based on a protocol, the protocol itself is not made for work.  Wlroots may have to make it work. Myth busted, the guy that made seatd broke that myth right in the myth manufacturer’s face (blood squirting out of the ears and all that nasty business, not a pretty site), and once people started considering using wayland without elogind, they also found out it works perfectly fine even without seatd (if compiled as such with some “features” disabled for security’s sake). That deep of a myth. It is like saying you need a fishing pole to go on a date…. folklore!  From the … if you are not going to engage in any … business, might as well go fishing.  Also you don’t need X for wayland/wlroots/sway … it works. I still don’t like it, but whether it works is a different story.  Like shampoo flavors, some like them some just use olive oil green bars of soap made in their kitchen.

And dbus, that decorative snitch, monitoring and communicating your every click and keystroke? It even monitors and snitches on root’s activities. So to whom is this piece of crap in service of? I’ve lived without it for years now. So more folklore spread around by the IBM parakeets.  If Skarnet’s Bercot had some time and money to lay off his labor sale, he might have gotten a way to finish this skabus project of his.

But we are stuck with a big IBM chunk, we are not out of the hole yet, we love what IBM does for us (like junkies love the pusher) from the second we hit enter on the bootloader screen. udev hooks running and rerunning and eternally running till everything is shutdown and gone to sleep.

IS (not are) there an alternative?

Years ago somebody decided they’ve had enough with udev and wrote smdev. As simple and lean as it can possibly be, with the ability to be enriched by hw modules for anyone that desired more than a simple x86 machine booting, having classic input/output abilities, reading/mounting disks, and a few simple additional hw. It worked, it is simple (suckless) and the great story is that it runs once and ends, doesn’t need to be daemonized, which is a good thing as it takes a few seconds to execute on a fast machine. But as hardware get more fancy and multiple in necessity, it wasn’t enough for people to adopt. So it remained as it was written, simple and functional.  Its goals were met, it wasn’t abandoned.  What it intended to do it does wonderfully.  But you couldn’t run or compile X to run with it and provide basic keyboard/mouse utility.  So what good is it?  For those not using a graphic environment, it is all they need.

Then comes this other solution, an intermediary, which can utilize any mdev provider, simulate the ability to be triggered by a change in hw, run the mdev (of choice!), and provide new definitions for hw added/removed. This project was called nldev, a middle man.  And it serves many purposes similar to udevd but lean and light.

Then skarnet’s Laurent Bercot begins work, not yet finished, to provide a true and complete udev alternative, still less than 1/3 of the code of (udev/eudev/libeudev), and it does work if you study the subject in depth and can configure it right. A nice template of a .conf file to un-comment all its abilities that are utilized, would have been nice, but skarnet wants you to do your own research and make your own choices, just like s6 s6-rc, etc. No ground food and chewed ready for swallowing from skarnet, they like to see you in tears before you make their sw work. Their server has been running for a ?decade? or more, with it, with reboots only taking place in leap years, and if there is no pandemic, and when electric current becomes available yet again.

BUT!!!

Why aren’t users and distro devs running to adopt such solutions? 1 reason! X is having problems with them, in most cases you can’t get the keyboard and mouse to work properly. That’s a big one … for most people, let’s be realistic. “Some” people don’t need X, they do all their work on console, their greps and cuts and sed and vis, is all they need, and lynx for a fancy browser to relax from coding, or seek references and libraries from other coders.  (tangent:  you try a chrome or firefox fork, not the official trojanware they are, and news.google.com only shows 5 headlines if you block gstatic scripts, and none of their links are functional without gstatic [the data miner] redirecting you to the link.  You try the same site with lynx or elinks and you can read news stories fine by accepting a zillion cookies, but no way to have scripts run – weird, a console browser able to get meaningful information when a full blown graphic browser is practically blocked!).

Why is X so peculiar about the specific mdev? Because it was written with that single piece of _t_u_r_d_ available to them and looks for its coding.  If you build an entire vehicle solely by aluminum, magnesium, FRPs, and titanium, why wonder why the magnet doesn’t stick to it?  Seriously, many of the X dependencies, and core packages of any linux system are compiled, build, and packaged on the utility of IBM’s udev.

Pop goes the myth of X would only work with IBM’s udev.

libudev-zero  (probably the big news in this story, as everything else is getting old while people do not know a thing about them)

A very young and promising project, getting about 5-6 upgrades just this past week alone, although it worked 10 days ago when I fist tried it.
On the early trials I replaced libeudev with libudev-zero, booted with eudev, then shut down the daemon, then started X. Cursor, cursor theme, keyboard, all working great. Then tried to substitute eudev with one of the alternatives, I admit I don’t have yet the knowledge and patience to configure mdevd right (Sorry mr.Bercot) but smdev worked, run manually once, and then libudev-zero takes over. As soon as smdev runs and throws 30 pages of nasty looking output on your screen, the screen readjusts (just like in udevd activity), net interfaces become available, and all is well.

Hmm… not so fast slick, how is your kernel image created with smdev?

That begun being tough, mkinitcpio run aground without eudev/udev available, possibly with the libudev-zero in place of libeudev. Here comes the “middleman” that makes any mdev availability work, nldev. You substitute nldev for udev in mkinitcpio.conf and the image is created properly, nldev is configured to run smdev during the boot hooks, and you get a nice console login: with any parts of e/udev removed from the system.
And of course X started normally and my favorite terminal provided a shell.

Not so fast slick! Now that you got linux-lts image booting without udev, what else is there missing?

Ok, Ok, Ok, … (Joe Pesci voice in lethal weapon X) … some things must not work because they were compiled with udev’s existence, which eudev does wonders for substituting because …. IT IS THE SAME CODE!!! Like what, you might ask. lsusb for example, still works but throws some garbage up on top for not being able to get the udev version. The output is still the same as with eudev. /dev/disk/ is empty, but blkid works fine (it doesn’t depend on udev). All mounting/unmounting/ssh/sshfs all work. How about Gparted, does it work? NO! Why? Because it is compiled based on the specific udevd and unless it gets the version number it exits with an error. If you can bypass this, or if you and the coder of libudev-zero figure out a way to fake this functionality, I don’t think there is an issue.

Yet, again, not so fast slick!!! You are tripping over yourself.

libeudev
├─device-mapper
├─eudev
├─libgudev
├─libusb
├─lvm2
├─usbutils
└─util-linux
eudev
├─colord
└─dhcpcd

This is a list of what I have found up to now, that are very base/core parts of almost any linux distro. that depend and ARE built based on udev, and some may work fine, but internally they think that udev is there. So ideally they must be rebuilt with the alternative in presence, in my case smdev, nldev, libudev-zero.  I tried the ones in bold and failed, not trying further till I figure out a way.

This is a little harder to do than I thought, but my abilities are limited. So it is not to say it can’t be done, I’m just passing the torch here for those that understand the importance of doing so and are willing to try it in a test installation.  Be kind and generous and throw a comment or two in what you discover, or place questions in hope another reader can answer.

I can assist with details anyone willing to give it a try, I have a runit script that works with mldev, and a 66/s6 script for not so clear solution for boot@-66, and more.  In the AUR you will find quite a suite of smdev related pkgs, nldev, and libudev-zero.  Someone has done great work for bringing those pkgs to the Arch community.

Just to see the light in the tunnel though, it is rewarding and new land will not be discovered unless we all do a little more pushing of the fence we are trapped by.

Because they want us fenced in and dependent to control us.  It is our single mission in life to bring those fences down, because on our land we can build autonomy, on their land we will always be slaves. We will not make this mistake again, to allow our land to be purchased for individual use. Am I losing it? No, anticapitalista knows what I am talking about.

A las barricadas!

 

References:

linudev-zero https://github.com/illiliti/libudev-zero

smdev https://core.suckless.org/smdev

nldev https://core.suckless.org/nldev

mdevd https://skarnet.org/software/mdevd

skabus https://skarnet.org/software/skabus

consolekit2 https://github.com/ConsoleKit2

KISSlinux https://kisslinux.org

obarun https://obarun.org

antiX https://repo.antixlinux.com

 

PS   All this experimentation was based on Obarun (an archlinux environment) without any logind presence or dbus, or systemd parts, not even consolekit2) and it may be harder or easier in other environments, but this is linux we are talking about, how “Gobo” can it be?