Lennart Poettering Takes To Battling Systemd Myths

[peppepz]

To be perfectly honest, while I understand why you want to build just udev, I'm not very sympathetic to the way you are framing it as an important issue. Let me make an analogy to illustrate how I see your plight:

While I disagree with the larger part of your previous message, I only respond to the fragments that relate to me.
There are two things wrong with your analogy:

1) it puts words in my mouth that I have never uttered, that make me appear as a moron. "panic attack"? I've expressed my current problems and my future concerns in a precise and documented way. "hate"? I don't know what it means.
2) it assumes that systemd is the only "modern" init suite, by depicting other solutions as old-fashioned or unreasonable, as "riding boots". This is not the case, as you certainly know. Moreover, people still ride horses, it's an activity that many people love. It's much more healthy than playing with xboxes.

Ah, a misunderstanding: Linux is a kernel, on top of which you can put several different collections of user-space applications. Some of them include and rely upon udev, others do not.

Did you really believe that my interest in Linux was limited to seeing the kernel boot without running applications afterwards, hence you told me that I don't need udev? No, I also like to run applications and these need udev; X, for instance.

So you seriously worry about a day will come where all major player have agreed that systemd is the way to go, it serves all their usecases from servers, via desktops, tablets and smartphones to embedded.

I don't worry at all about the future, Linux always fixes itself in the long run. I do worry about the teething pain.

so you are desperately in need of some guy to fork udev?

The day udev stops working for me, should that day ever come, I'll write a replacement myself. I have to study its source package every time a new udev release is out anyway, in order to find out about all the undocumented incompatible changes. I don't want anybody to do any work for me.

[tomegun]

I've just installed udev from systemd-197. Thanks for at least having made Python optional on the target, this helps when bootstrapping a cross-compiled image. However, now libudev links with libsystemd-daemon, so the integration between systemd and udev apparently went a step further and now there's another piece of systemd I need to have on my system only to run udev. Ressured by you, I shut up and install the library, knowing that it won't harm me.

Yeah, libsystemd-daemon is made so that when used on a non-systemd system its functions will be noops. Moreover, it comes with the sd_booted() function which is used like this in one place in udev:

        /* don't muck around with ACLs when the system is not running systemd */
        if (!sd_booted())
                return 0;

I guess this illustrates how udev development is done: when using systemd you might get a few extra neat features (which were not possible before), but when you don't we bail out and things behave as they used to do.

It makes sense for udev users to build only udev. You say that it does not make sense upstream, so apparently there's some thing that you call "upstream" whose interests are in conflict with a portion of the downstream udev users, namely all those who use udev but not systemd. Which is what I've been ranting about all the time, with people telling me that it was not true.

I think you are creating a conflict where there is none (at least nothing serious). The point is that udev is just another part of the systemd repos, and is not really 'special'. The systemd repos also have a lot of other pieces like udev which can be used without systemd (in Arch we shipped lots and lots of the systemd binaries in a package called systemd-tools which was used by our initscripts (which I maintained) before we switched to systemd).

So if you want it to be possible to build udev separately, and you want the buildsystem to be uniform and 'make sense', you should also allow any of the other parts of the package which does not depend on the systemd binary to be built separately (while making sure that any parts that do depend on systemd pulls it in). Sure, it could be done, but so far the suggestions I have seen have been very invasive, much more so than simply split the package up after building it (and possibly discarding some parts you don't need).

To be perfectly honest, while I understand why you want to build just udev, I'm not very sympathetic to the way you are framing it as an important issue. Let me make an analogy to illustrate how I see your plight:

You are used to Santa Clause delivering your favorite toys on every Christmas morning. Now you are noticing that Santa Claus has included some toys in your gift basket that you don't really want. So you tell him that he needn't bother with those, you don't want them. No big deal. However, Santa tells you that, 'Sorry, in order for the elf factory to produce gift packages efficiently enough we can't make everything optional; the sorting process would simply take too much time. Please just throw away the gifts you don't want'. No big deal, or so one should think. On the contrary, now you panic because you are scared that one year Santa will stop providing your favorite toys and only provide the toys you don't really want. Not to worry, says Santa, 'I'll still keep giving you the toys you want as long as they make sense'. Which induces an even bigger panic attack: 'What do you mean "as long as it makes sense"?! I want it forever and ever! Promise me now! Forever!'. Obviously Santa, having been around for some time, knows that nothing is forever, so he refuses to make such a promise. For instance, a couple of hundred years ago the standard gift basket would contain riding boots. He stopped doing that, as hardly anyone goes horseback riding anymore. Sure, some do, but not enough for the elves to spend resources on that, when there are so many XBoxes to assemble. Santa thinks this is a fair deal, and is a bit confused about all the hatred he is attracting... After all, it is not like he is obliged to provide anyone anything at all...

In your previous message you told me repeatedly that I could use Linux without udev, now at least you're saying that "most clients no longer care about the non-udev usecase". So I can use Linux without udev, I'll just have to do without "most clients". Lucky me *.

Ah, a misunderstanding: Linux is a kernel, on top of which you can put several different collections of user-space applications. Some of them include and rely upon udev, others do not. Whatever way you slice it, there is no dependency chain including udev which forces you to use systemd. Maybe other apps will force you to use systemd (GNOME, NetworkManager, PolKit? Neither do at the moment, but perhaps one day?), but you can't make the claim that it is some sort of power-play by the systemd/udev devs as they have no control over these other projects.

Since you're pointing at LFS, in all honesty, can you find on the whole LFS site another package whose installation requires such a complex and elaborate procedure every time a new release is out? One! Bonus points if it's a system package which is needed by any application to interface itself with the Linux kernel.

I know virtually nothing about LFS, I only noticed their udev package and thought to myself that this is exactly what eudev should have done.

I hope so. I have to live in hope (so much for "nothing will change"). The biggest problem is that he should gather quite a critical mass of users in order for his implementation be tested well-enough to be a viable replacement, but well, that's true for many kinds of project.

So you seriously worry about a day will come where all major player have agreed that systemd is the way to go, it serves all their usecases from servers, via desktops, tablets and smartphones to embedded. Moreover lots of standard user-space applications start hard-depending on systemd as they agree it is the right choice. However, it still does not serve your usecase, so you are desperately in need of some guy to fork udev? Seems more likely to me that if ever the time comes where udev starts depending on systemd it is because there is no longer a reason not to use systemd, and you will already have moved to systemd for other reasons... (unless you have some religious opposition to it, but I would never dream of accusing anyone of being that irrational ;-) ).

Also he'll need quite a dose of endurance to harsh criticism. Let's see what happens with eudev.

Please do not confuse the harsh criticism eudev endured with criticism of the idea of a fork. The criticism was due to technical incompetence and (willful?) ignorance of how the project they were forking works (which they then keep on spreading, despite being informed of their mistakes).

[Vim_User]

Your moms are Monolithic (to BSD users/devs)


Cause systemd is so well designed and simple unlike BSD init. Systemd is simple, small and fast so those guys saying under wise should grow up or get lost.


Bullshit


Good, BSDs hold back open-source projects. They always have to waste effort porting their software to pathetic BSDs. Much better forgetting about them and make software that takes advantage of superior Linux specific features. BSD users should just crawl into a hole and die cause their OS is 20 years behind and they do nothing but hold linux back.


That's irrelavent, systemd was made for linux and LINUX ONLY. If BSD don't like it, they can go screw themselves. Just ask GNOME, XFCE and KDE devs about how annoying the existence of BSD is. They'll tell you that BSD only makes up 0.01% of the users of their software and that they could make their DEs better without BSD to worry about.

So those criticizing systemd shown just STFU

Seriously

Oh come on, your third Phoronix account in this small amount of time and you are still a bad troll. Please, do me a favor, no, better do me two favors:
1. Learn how to do intelligent trolling, Phoronix had already much better trolls than you.
2. If BSD is so pathetic, why don't you just remove all BSD software from your machine. You know, with using it and reporting bugs users are actively supporting the BSD upstream and that can't be what you want, right? Come back and report how well your system works without BSD code and how much the BSD code has held you back..

[peppepz]

The discussion has been had,

Is this the discussion? http://www.mail-archive.com/systemd-.../msg05287.html
I see it boiled down to: "here's a patch to allow me to build udev as I've always done for years". Some of the answers?

- no, sorry.
- you have to split it in your distro.
- stay with udev-182, it's the easiest way! [sic!]
- do it yourself for now, eventually your patches will be accepted but not now, [7 months have passed at the time of this writing] and anyway you'd be better off by switching to systemd

If you switch off 'everything' in ./configure, you will basically just have to compile systemd, journald and udevd. From a point of view of compile-time this is not a big issue, the only possible issue is if you for some reason absolutely don't want libdbus as a build-dep. In that case I suggest you look at the Makefile by LFS, they do this nicely.

I've just installed udev from systemd-197. Thanks for at least having made Python optional on the target, this helps when bootstrapping a cross-compiled image. However, now libudev links with libsystemd-daemon, so the integration between systemd and udev apparently went a step further and now there's another piece of systemd I need to have on my system only to run udev. Ressured by you, I shut up and install the library, knowing that it won't harm me.

Since you're pointing at LFS, in all honesty, can you find on the whole LFS site another package whose installation requires such a complex and elaborate procedure every time a new release is out? One! Bonus points if it's a system package which is needed by any application to interface itself with the Linux kernel.

Nah, if that were to happen I'm sure someone who knows what they are doing would step up and make a proper and maintainable fork.

I hope so. I have to live in hope (so much for "nothing will change"). The biggest problem is that he should gather quite a critical mass of users in order for his implementation be tested well-enough to be a viable replacement, but well, that's true for many kinds of project. Also he'll need quite a dose of endurance to harsh criticism. Let's see what happens with eudev.

A patch to JUST build udev is simple. However, for it to make any sense upstream you should not make it a special-case, but allow to also build any other subset of the binaries, which becomes a mess (apparently, I didn't look closely at the patch, except to count the number of lines).

Why are you putting on the same plane the case of udev with that of "any other subset of binaries"? The case of udev is unique and the reasons for needing only it have been documented -- countless times in this thread only.

It makes sense for udev users to build only udev. You say that it does not make sense upstream, so apparently there's some thing that you call "upstream" whose interests are in conflict with a portion of the downstream udev users, namely all those who use udev but not systemd. Which is what I've been ranting about all the time, with people telling me that it was not true.

I see systemd's trajectory something along the lines of udev's: it started out as something people 'would never allow on their systems', before it slowly became a de-facto standard to the point that most clients (e.g. X, or various init systems) now no longer care about the non-udev usecase.

In your previous message you told me repeatedly that I could use Linux without udev, now at least you're saying that "most clients no longer care about the non-udev usecase". So I can use Linux without udev, I'll just have to do without "most clients". Lucky me .

[systemd rulez]

Systemd Is Monolithic

Your moms are Monolithic (to BSD users/devs)

Systemd Is About Speed

Cause systemd is so well designed and simple unlike BSD init. Systemd is simple, small and fast so those guys saying under wise should grow up or get lost.

Systemd Is Complex

Bullshit

Systemd Is Linux-only & Not Nice To BSDs

Good, BSDs hold back open-source projects. They always have to waste effort porting their software to pathetic BSDs. Much better forgetting about them and make software that takes advantage of superior Linux specific features. BSD users should just crawl into a hole and die cause their OS is 20 years behind and they do nothing but hold linux back.

Systemd Is Not Portable For No Reason

That's irrelavent, systemd was made for linux and LINUX ONLY. If BSD don't like it, they can go screw themselves. Just ask GNOME, XFCE and KDE devs about how annoying the existence of BSD is. They'll tell you that BSD only makes up 0.01% of the users of their software and that they could make their DEs better without BSD to worry about.

So those criticizing systemd shown just STFU

Seriously

[Delgarde]

Systemd does not ship any .service files itself. Either the package will ship with one from upstream, or your distro probably does it for you (in Arch we have converted all our rc scripts to .service files, Fedora has done the same, and I'm pretty sure most of Debian has also been converted).

And as distros standardize on systemd, it'll become more and more common for upstream packages to ship their own service files, since they no longer need to worry about maintaining init scripts for a dozen different distros...

[tomegun]

Great news! Then certainly before long all those non-systemd developers that contribute to systemd-udev, and decide and shape its future, will give us a Makefile target for us to build and install udev separately from systemd. I'm looking forward to that moment, I hope it won't take long!

The discussion has been had, and the consensus seems to be that the buildsystem builds systemd. If you switch off 'everything' in ./configure, you will basically just have to compile systemd, journald and udevd. From a point of view of compile-time this is not a big issue, the only possible issue is if you for some reason absolutely don't want libdbus as a build-dep. In that case I suggest you look at the Makefile by LFS, they do this nicely.

And yet currently it's the only alternative I'd have should udev be integrated into systemd when everybody.

Nah, if that were to happen I'm sure someone who knows what they are doing would step up and make a proper and maintainable fork.

I never said that it does not work without systemd. I said that it does not build without systemd, which is a rather big change, while they said there would be no change, and that it changed the way it works in a way that broke my system, for example by changing the name and position of the main udev binary.

This is really not a big problem, just use a custom Makefile.

Are there such switches? The last version I've built, 191, didn't have them, so I had to build the whole systemd and then guess what files I had to take out from it. I'm happy to know that now they're in place, I'll download and install 197 as soon as I have time.

I believe the only things you cannot switch off are systemd, journald and udevd (i.e., systemd and its hard dependencies).

I'm no distribution maintainer. It takes me a lot more than 5 minutes to study, dissect and rebuild a package that is essential to boot and keep my system running, and repeat this operation every time a new systemd release is out. If such a patch would be "extremely trivial", then why a patch that does exactly this was never accepted upstream?

A patch to JUST build udev is simple. However, for it to make any sense upstream you should not make it a special-case, but allow to also build any other subset of the binaries, which becomes a mess (apparently, I didn't look closely at the patch, except to count the number of lines).

You're actually confirming my concerns. Especially with the last sentence, where you go as far as delineating a difference between light and dark.

Sorry, I should remember not to use humor/sarcasm on the internet. Maybe I should have said that we are all looking forward to the day where systemd has become a de-facto standard on linux, so we can focus our energy purely on systemd-systems.

When I said that people are planning "to stop supporting udev without systemd in a somewhat unspecified future", you told me that it was "a gross misrepresentation, and absolutely not true". But to me "as soon as Ubuntu starts shipping systemd by default" is the same as "in a somewhat unspecified future", because I don't work at Ubuntu and have completely no idea about their future plans.

I was merely saying that it would at least not happen as long as Ubuntu does not ship it. Didn't say it would then happen immediately, if at all.

I see systemd's trajectory something along the lines of udev's: it started out as something people 'would never allow on their systems', before it slowly became a de-facto standard to the point that most clients (e.g. X, or various init systems) now no longer care about the non-udev usecase. Once systemd has reached this same status, I suppose it would become relevant to discuss whether or not udev should also drop the non-systemd usecase. I believe this has more to do with what the ecosystem userspace apps does (when they start hard-depending on systemd) and less to do with what default init-systems distros use.

[peppepz]

Android is a good example of a Linux system which does not use udev. Busybox (with mdev) is another (albeit much more minor one), so it is not true that you MUST use udev.

In the world of ideas, it's possible to use Linux without udev. If you're a billionaire company such as Google, you can pay people to develop and maintain a udev replacement, and track the kernel development in order to implement the necessary changes every time they're required.

Or, if you run Linux on an embedded board that is controlled through a serial port, you can be fine with mdev.

But in reality, if what you use is the plain desktop Linux, then you need udev and libudev even for basic tasks such as starting the X server.

It is not true that "udev is constantly changing together with the kernel".

It gets updated when drivers get merged into / updated / removed from the kernel and this reflects into udev rules. Also libudev changes frequently and userspace needs the new APIs.

The concern is understandable. However, you should by now have been told repeatedly that 1) non-systemd support for udev will continue as long as non-systemd uses exist (and they do, Martin Pitt of Canonical/Ubuntu fame has commit access to systemd-ubev for crying out load)

Great news! Then certainly before long all those non-systemd developers that contribute to systemd-udev, and decide and shape its future, will give us a Makefile target for us to build and install udev separately from systemd. I'm looking forward to that moment, I hope it won't take long!

if ever udev becomes dependent on systemd creating a fork would be trivial (don't look to eudev as an example, what they are doing is crazy and creating a lot more trouble/bugs/work for themselves than necessary).

And yet currently it's the only alternative I'd have should udev be integrated into systemd when everybody "sees the light" (besides switching to Android or BusyBox as you've suggested above). So I hope they'll fix the problems they have; I'm certain that systemd-udev developers will help them and encourage them, in the spirit of open source collaboration.

That's news to me. Udev works just fine without systemd. We supported that for some time in Arch Linux without problems and we still support udev without systemd in our initramfs.

I never said that it does not work without systemd. I said that it does not build without systemd, which is a rather big change, while they said there would be no change, and that it changed the way it works in a way that broke my system, for example by changing the name and position of the main udev binary.

You do not have to build all of systemd to build udev. With the correct packaging script building only the necessary is trivial. That said, the simplest approach is probably to just flip the right ./configure switches to avoid building almost all of systemd.

Are there such switches? The last version I've built, 191, didn't have them, so I had to build the whole systemd and then guess what files I had to take out from it. I'm happy to know that now they're in place, I'll download and install 197 as soon as I have time.

If by 'many' you mean 'two', then you are correct: libcap and dbus. python (and everything else) is an optional dependency, which you would obviously disable in your setting.

Python was hardcoded in the makefiles the last time I built udev. I know because I was cross-compiling it, like I had always done when udev was a standalone package, and could no longer do it because of Python. Again, I'm happy to know that this changed, it will save me a lot of time.

It was just a matter of deleting some stuff and moving some stuff, I don't see what the fuss is about. If you prefer to have patch against the Makefile to make this even more trivial, that would be an obvious thing for your distro to carry if they don't wish to use systemd. The patch would be extremely trivial... Only reason I never wrote this (would take 5 minutes) is that my distro uses systemd so there is no point.

I'm no distribution maintainer. It takes me a lot more than 5 minutes to study, dissect and rebuild a package that is essential to boot and keep my system running, and repeat this operation every time a new systemd release is out. If such a patch would be "extremely trivial", then why a patch that does exactly this was never accepted upstream?

You are misreading this statement, and it has been explained repeatedly. They (we) are looking forward to the day when there is no longer a need for non-systemd udev. Meaning the day that everyone has seen the light and switched to systemd.

You're actually confirming my concerns. Especially with the last sentence, where you go as far as delineating a difference between light and dark.

As long as Debian/Ubuntu are not using systemd by default you have nothing to worry about.

When I said that people are planning "to stop supporting udev without systemd in a somewhat unspecified future", you told me that it was "a gross misrepresentation, and absolutely not true". But to me "as soon as Ubuntu starts shipping systemd by default" is the same as "in a somewhat unspecified future", because I don't work at Ubuntu and have completely no idea about their future plans.

[Delgarde]

I think one of the sources of discontent with systemd might be this http://www.pappp.net/?p=969

NOT UNIX way of doing things

Some people get very hung up on the whole "UNIX way of doing things" argument. They need to remember that what they're talking about is nothing more than a traditional set of design principles - not holy law carved into stone tablets. And they're *good* design principles, no question - but they're not the only way of doing things, nor always the right way (as the article you link to notes). E.g storing data is flat text files is nice (and systemd does so for config files), but you'd be crazy to apply that principle to a multi-terabyte relational database. And "portability over efficiency" is only relevant for things where portability is useful, and where the benefits of portability are worth the loss of efficiency - it's a balancing act, not an inviolable mantra.

Most importantly at all, those design principles are something you're supposed to think about, not just follow automatically without appreciation of what you're gaining (and losing) by doing so.

[Delgarde]

Is this supported such as "./configure --only-udev && make && make install"? If not it makes it a huge pain to get just one part.

Not out of the box, unfortunately, but several projects have patched it to obtain a standalone-build. For example, see:

http://www.linuxfromscratch.org/lfs/view/development/chapter06/udev.html

and the Makefile contained in this tarball.

http://anduin.linuxfromscratch.org/sources/other/udev-lfs-197-2.tar.bz2

It would be much more convenient if it supported a --only-udev build, but my understanding from the LFS developers was that a) upstream weren't interested, and b) this standalone Makefile was actually easier than patching the systemd build files. Certainly, udev is one of those packages that doesn't benefit much from using an autotools build, since it's not intended to be portable, nor does it have a set of complex dependencies to check for.