Uselessd: A Stripped Down Version Of Systemd

[tomegun]

I think you and a lot of other people should re-read that whole page. That was posted over a year and half ago and systemd's changes as well as the presence of this project has made a lot of things said untrue.

[1] Myth: systemd is monolithic.

It certainly isn't monolithic, but the statement "In fact, many of these binaries are separated out so nicely, that they are very useful outside of systemd, too." contained within the answer to that has become only less and less true. One of the few examples given in the footnote, systemd-udevd, is moving to use communication that requires interfaces only implemented in systemd. The contents of systemd aren't as self-contained as they were a year and a half ago.

udevd _still_ works just fine without systemd, so I don't believe that statement is any less true today than it was when it was written. Maybe one day that will change, but it still does not change the overall point: systemd is not monolithic.

[13] Myth: systemd being Linux-only is not nice to the BSDs.

We now see efforts like the OpenBSD systembsd implementing the interfaces like timedated, hostnamed, and logind because upstream projects depend directly on the interfaces that only systemd implements. "The assumption that they'd adopt our core userspace if we just made it portable, is completely without any foundation." They don't want to use systemd, but they've been forced into a corner where they have to pretend that they're systemd.

You are not really contradicting the statement int he blog post. We always said that it makes perfect sense to reimplement the systemd API's on other platforms. Just not to share the code, in particularly not share the code of PID1. Note that PID1 is not being reimplemented on BSD.

[15] Myth: systemd could be ported to other kernels if its maintainers just wanted to. and [16] Myth: systemd is not portable for no reason.

While systemd has been against supporting anything other than linux, glibc, and the like (which is well within their right to do), uselessd is doing quite the opposite and apparently succeeding at running on FreeBSD, using other libcs such as musl and uclibc, and getting rid of the gnu-isms while still managing to be a systemd-compatible init system. That makes uselessd a viable option for a lot of people where systemd is not - even before you start talking about how they've stripped down systemd.

Making systemd run on non-glibc should not be hard (though it is easy to mess things up too, so one would have to be careful). Making it run on non-linux, with the main features intact (e.g. cgroups), would be a lot harder. Note that the uselessd guys are ripping out the cgroup support, and with it most of the point of systemd (IMHO).

I've been a systemd supporter and loved it while building an LFS system years ago that I still use as my main system. It is the init system that makes the most sense, but what happens when it stops being A building block and starts being THE building block as it refers to itself in [18]? We get things like Void Linux switching away from it, and not because it stopped being a good init system, but because it became a lot of everything else. The increasingly all-incompassing systemd only becomes less and less desirable the further you are to its aims, while the small part that is the init system becomes less and less worth the trouble. The uselessd page involves no attacks on the developers of systemd nor the project. In fact, it's very existence is a clear statement that the core of systemd and its work in the init system space is wonderful and is worth being used and relied upon even if you have disagreements about where the project as a whole is going. That's powerful. That's positive. I hope they achieve enough success and support to continue to exist - not because I hate systemd, but because I like systemd.

Most of the new features (and certainly all the new daemons), can be disabled at compiletime, so you could still get a core systemd which is very similar indeed to what it was a couple of years ago (but hopefully with less bugs).

[gens]

... and if a libc which claims to be compatible with glibc actually
is not, then this should really be fixed in the libc ...

uclibc never claimed to be 100% glibc compatible
it would be more or less glibc if it were, not an embedded subset of it

moreover musl people pointed out quite a few flaws in glibc, out of them most were fixed (and glibc people were not dicks about it)
musl is a better library in many places (glibc in other)

a "libc" is defined in POSIX, not in glibc
good ideas do get into the standard, but faulty or just plain dumb ones don't

[thechef]

good news

systemds key design is about the style of how components interact.
Adopting that instead of taking the full bulk, greatly showcases the superior Linux-powered design of systemd.
There will be systemd-compatibles and systrmd-likes. There will be ANSwers from the disliking crowd claiming that they are making a better systemd (Acronym is Not Systemd) and they might do, only this time the reference implentation comes from the side of a former opposition (GNU/Linux) and the opposition has some colors of the former reference (Unix/BSD).
In the end everyone will be talking about systemd just like everyone including Linux people is talking about Unix.

[BwackNinja]

Not quite. Read their FAQ more closely:

That's a *long* way short of "succeeding at running on BSD"... basically, it compiles, but only if you provide stubs for all the Linux-only bits. Not actual working replacements for those bits, just empty function definitions in order to keep the compiler and linker happy. I doubt this will ever actually run successfully on non-Linux...

I can understand that, and my statement that it was "succeeding at running on BSD" is a misleading overstatement of the situation, but the only people who can get something to work are the ones who try. In the worst case scenario, it still won't work, but the developer(s) will have learned something - and I'm glad that sentiment is even explicitly said on the website.

udevd _still_ works just fine without systemd, so I don't believe that statement is any less true today than it was when it was written. Maybe one day that will change, but it still does not change the overall point: systemd is not monolithic.

One should not be so quick to forget this:

http://lists.freedesktop.org/archives/systemd-devel/2014-May/019657.html

Also note that at that point we intend to move udev onto kdbus as transport, and get rid of the userspace-to-userspace netlink-based tranport udev used so far. Unless the systemd-haters prepare another kdbus userspace until then this will effectively also mean that we will not support non-systemd systems with udev anymore starting at that point. Gentoo folks, this is your wakeup call.

I never said that it wasn't still true that udevd works without systemd. I also started with saying that systemd wasn't monolitic and was addressing the content of the answer rather than the title. If we wanted to play the definition game, as far as monoliths go, the features of systemd aren't separable, but would instead involve reimplementation - hence systembsd being interesting on Linux systems at all. The structure of systemd is more of a good coding practice than a purposely flexible program suite. If it isn't a monolith, it certainly holds a lot of xenoliths, and each one crumbles when you remove it from the bigger rock.

You are not really contradicting the statement int he blog post. We always said that it makes perfect sense to reimplement the systemd API's on other platforms. Just not to share the code, in particularly not share the code of PID1. Note that PID1 is not being reimplemented on BSD.

Would you say that if those components of systemd were portable, they would at least be used as a stop-gap before a project like systembsd is finished? The BSD folks don't merely get a free pass not to do any development of their own, but certainly it would've been nicer if they didn't have to choose between using old versions or heavily patching new releases, particularly during a period where they can't be sure if systemd would take off enough to require the development they're doing right now. Systemd being a good init daemon and being PID1 aren't as tightly coupled as one would think. An init daemon doesn't have to be PID1. Even being a good PID1, systemd isn't exciting as such. Starting and supervising services is first and foremost what is wanted from it, and people would still like it if it was a program started by sysvinit. I use it not only as my init daemon, but also to start up all my services as a user and logout with a "systemctl --user exit".

Making systemd run on non-glibc should not be hard (though it is easy to mess things up too, so one would have to be careful). Making it run on non-linux, with the main features intact (e.g. cgroups), would be a lot harder. Note that the uselessd guys are ripping out the cgroup support, and with it most of the point of systemd (IMHO).

And the point is that it doesn't run on non-glibc - on purpose. Patches aren't accepted to allow that with the sentiment that if a libc doesn't emulate glibc, it isn't worth anything, when not being glibc is a lot of the reason for the other libcs to even exist. The uselessd developer may be ripping out cgroup support for BSD, but it's still alive and well on Linux, just not available as a part of unit files. To me, that sounds more like a statement that its good for systemd to use cgroups, but disagreeing with the idea of it owning and controlling them.

Most of the new features (and certainly all the new daemons), can be disabled at compiletime, so you could still get a core systemd which is very similar indeed to what it was a couple of years ago (but hopefully with less bugs).

But they are still inextriably tied to systemd. After a certain point, that's akin to downloading Ubuntu because I wanted a text editor. Few people claim that there is anything wrong with those extra programs and extra features. Instead, they find issue with the fact that they are tied to a single entity. Strong divides are created where only weak ones existed. No longer can people fight about something so trivial as setting the machine's hostname. Instead, they have to look at the components below them and say "I'm using x, so I can only do it way a" while another says "I'm using y, so I can do it b, c, or d but I think c is the best". The reality is that I'm not going to claim it's better that way or that systemd and it's many daemons and features aren't doing things right or that it's not suitable for the masses. I'm going to say that I personally don't like it that way, despite how it pains me that I won't be using fun systemd things like the new networkd. You gain perspective from the discussions. You understand how your system works from the discussions. I'm going to selfishly express my opinion while others selfishly express their differing ones. People may seem angry, and some may actually lose their temper, but they keep coming back because they enjoy it. Systemd itself wasn't created in a vacuum and was designed based on seeing what was already there and how it was flawed. It's all a non-issue for most people how their system boots as long as it does it well, but it's still important to me. Supporting compiling systemd with an ever-growing number of disable options (or just building everything instead) rather than supporting uselessd would be going against the same ideals that got me to the point of being able to competently discuss this matter in the first place.

[bison]

Phoronix: Uselessd: A Stripped Down Version Of Systemd

The boycotting of systemd has led to the creation of uselessd, a new init daemon based off systemd that tries to strip out the "unnecessary" features...

http://www.phoronix.com/vr.php?view=MTc5MzA

This could be really good. One of the best ways of improving software is by removing seldom-used features. I wish them success.

[Chousuke]

So does kernel, so what ?
And BTW, I don't see the logic behibd that "single point of failure" argument.

If you have e.g. separate e/udev and it croaks, how does that help you exactly ? Or if your dhcp client fails to run and you end up without working network ?

Those aren't even good examples. udevd, journald, logind etc. and dhcp clients are separate processes in systemd world as well. Guess what happens when you kill either? absolutely nothing.

Killing PID 1 would of course cause a kernel panic, and killing dbus or some of the user session systemd instances might log me out of X.

Where exactly is the single point of failure here, again?

[tomegun]

I never said that it wasn't still true that udevd works without systemd.

I took issue with your implication that there has already been a change to make systemd more monolithic. I do not contest that the future plan of libudev is to use kdbus internally. Note that this does not necessarily tie it to systemd, but only to kdbus. Another initdaemon which has kdbus support should work just as well (it is not much systemd has to do to set up kdbus at boot, so doing that from elsewhere would also not be much work).

Would you say that if those components of systemd were portable, they would at least be used as a stop-gap before a project like systembsd is finished? The BSD folks don't merely get a free pass not to do any development of their own, but certainly it would've been nicer if they didn't have to choose between using old versions or heavily patching new releases, particularly during a period where they can't be sure if systemd would take off enough to require the development they're doing right now.

I don't think it makes any sense from systemd's point of view to try to make some parts of it portable. It could be done, for sure, but it would be at a considerable development cost (just to have to keep track of what shared functionality can and can not be unportable), for functionality that would never be tested upstream, and for which upstream has no interest.

Systemd being a good init daemon and being PID1 aren't as tightly coupled as one would think. An init daemon doesn't have to be PID1. Even being a good PID1, systemd isn't exciting as such.

I conflated init daemon and PID1 in my previous answer. The point was that making systemd, the init daemon, portable would be really intrusive (due to especially cgroups).

And the point is that it doesn't run on non-glibc - on purpose. Patches aren't accepted to allow that with the sentiment that if a libc doesn't emulate glibc, it isn't worth anything, when not being glibc is a lot of the reason for the other libcs to even exist.

So I don't think systemd's dependency on glibc (or the Linux kernel) is a value judgment about their competitors "worth", just that these are the dependencies we chose, as they fit our needs the best. I think it is important to distinguish between depnedencies and reverse dependencies. I.e., it makes (IMHO) a lot of sense to pick _one_ kernel, _one_ libc, etc and build on that (no matter which ones one happens to chose). But it would be very bad indeed if systemd somehow made assumptions about things above it in the stack, say only allowing Apache, GNOME and MySQL to run (but not Nginx, KDE and Postgresql). In the same way it may be reasonable for Gnome to depend on systemd, but not for GNOME to only allow Firefox to be used as the webbrowser.

Of course, if alternative implementation appear for some dependency, we should make it possible when reasonable to use that instead (we do merge some reasonable patches for non-glibc compatibility, though probably not enough to make it actually work out-of-the-box), but these alternatives should then be true alternatives striving to implement the same API, otherwise I don't think it makes sense for us to code against several API's (or worse still, restrict ourselves to the lowest common denominator).

But they are still inextriably tied to systemd. After a certain point, that's akin to downloading Ubuntu because I wanted a text editor. Few people claim that there is anything wrong with those extra programs and extra features. Instead, they find issue with the fact that they are tied to a single entity.

I guess the same arguemnt goes for networkd, logind, etc as for systemd itself: we don't see it as a problem to pick one API (systemd) to code against, rather than coding against (the lowest common denominator of) systemd, Upstrart, OpenRC, sysvinit,... I can see why someone wolud like to mix and match in any conceivable way, but from the point of view of actually building something, it makes life a lot harder for very little gain (at least from the POV of the developers involved).

[Chousuke]

I can see why someone wolud like to mix and match in any conceivable way, but from the point of view of actually building something, it makes life a lot harder for very little gain (at least from the POV of the developers involved).

I don't think people appreciate the truth of this enough.

The systemd toolset, with all the things it implements, is one set to test. that is an enormous benefit.

Now imagine if you could mix and match freely between, say, udev, eudev, systemd, upstart, journald, syslogd, logind and consolekit? I don't even know how to calculate that off-hand taking redundancy into account, but it's definitely more than is ever feasible to test in practice.

[Nobu]

Now imagine if you could mix and match freely between, say, udev, eudev, systemd, upstart, journald, syslogd, logind and consolekit? I don't even know how to calculate that off-hand taking redundancy into account, but it's definitely more than is ever feasible to test in practice.

Well, if we're talking about numbers, something like this: s * s * s * s * s * s * (i * i) = (s^6)*(i^2) (because, generally, you wouldn't use systemd and upstart together, but you would still have to test the other software against both init systems...or at least one, if it's the distribution that's testing compatibility, so is^6, or such).

[BwackNinja]

I took issue with your implication that there has already been a change to make systemd more monolithic. I do not contest that the future plan of libudev is to use kdbus internally. Note that this does not necessarily tie it to systemd, but only to kdbus. Another initdaemon which has kdbus support should work just as well (it is not much systemd has to do to set up kdbus at boot, so doing that from elsewhere would also not be much work).

Saying that "this does not necessarily tie it to systemd, but only to kdbus" is more transparently said as "this does not tie it to systemd, but only to a subset of systemd". While kdbus itself resides in the kernel, the userspace bits as shown by the file list here http://cgit.freedesktop.org/systemd/...systemd/sd-bus doesn't seem to support the idea that it wouldn't be much work to have kdbus available for another init system. The only difference between this situation and saying "nm-applet isn't necessecarily tied to NetworkManager" is that we're talking about a something that's identifiable as a section rather than a whole.

I don't think it makes any sense from systemd's point of view to try to make some parts of it portable. It could be done, for sure, but it would be at a considerable development cost (just to have to keep track of what shared functionality can and can not be unportable), for functionality that would never be tested upstream, and for which upstream has no interest.

Libc portability wasn't welcome, even as a non-intrusive patches accepted and the users have to fix libc-specific bugs situation. That's knowing that anyone using an alternative libc is going to be a good deal more savvy than those not even knowing what that means. As for kernel portability, the regular BSDs probably wouldn't care until the point we're at right now where they most certainly do care. However, this would've sped up Debians largely inevitable decision. I won't push this point because I know that it would be rather difficult to have that portability in the core, and even laughable to start trying after udev was merged.

So I don't think systemd's dependency on glibc (or the Linux kernel) is a value judgment about their competitors "worth", just that these are the dependencies we chose, as they fit our needs the best. I think it is important to distinguish between depnedencies and reverse dependencies. I.e., it makes (IMHO) a lot of sense to pick _one_ kernel, _one_ libc, etc and build on that (no matter which ones one happens to chose). But it would be very bad indeed if systemd somehow made assumptions about things above it in the stack, say only allowing Apache, GNOME and MySQL to run (but not Nginx, KDE and Postgresql). In the same way it may be reasonable for Gnome to depend on systemd, but not for GNOME to only allow Firefox to be used as the webbrowser.

Of course, if alternative implementation appear for some dependency, we should make it possible when reasonable to use that instead (we do merge some reasonable patches for non-glibc compatibility, though probably not enough to make it actually work out-of-the-box), but these alternatives should then be true alternatives striving to implement the same API, otherwise I don't think it makes sense for us to code against several API's (or worse still, restrict ourselves to the lowest common denominator).

The requirement of cgroups support, as an example of kernel dependency, was part of the core of what systemd aimed to be and even controversial on Linux let alone talks about portablity. I understand that. It would've been like writing wayland against BSD at the time instead of Linux. However, you're still saying that the libc basically has to be glibc, not merely a complete and conformant C library. If it isn't enough to be a conformant C library, where do you draw the line that isn't looked down upon as "the lowest common denominator"? Worth is defined in relation to something else. No matter how well coded or how beautiful and intuitive of a gui that a mushroom classification application has, I don't need one on my system - it isn't worth anything to me. If, however, I had users who would find that useful, I would include it and it would have worth to me through the fact that my users are worth something to me. This isn't a new issue, and the fact that you can only say "though probably not enough to make it actually work out-of-the-box" means that the systemd folks don't find it worth extending compatibility to those other implementations. Not worth time, not worth effort - simple as that. As far as dependencies and reverse dependencies go, any system that you look at will be using an assortment of different crypto and ssl libraries. If these somehow conflicted, then running one program would mean being unable to run another, or even stopping one from having some other library available. With Gnome depending on systemd, that means that not running systemd means you can't run Gnome (you can, but you miss out on certain basic capabilities). That's not just a non-conflicting library you can simply add, and that's why that assessment doesn't work here.

I guess the same arguemnt goes for networkd, logind, etc as for systemd itself: we don't see it as a problem to pick one API (systemd) to code against, rather than coding against (the lowest common denominator of) systemd, Upstrart, OpenRC, sysvinit,... I can see why someone wolud like to mix and match in any conceivable way, but from the point of view of actually building something, it makes life a lot harder for very little gain (at least from the POV of the developers involved).

Your current model sounds like you're doing things a little backwards from what's expected and that's what makes it so easy for you and others to talk past each other without understanding what the other is saying. You have everything constructed in such a way that something like networkd talks to systemd rather than the other way around. It is far less of a program in its own right and more of a plugin. That's one way to do things for sure, and not objectionable on technical grounds, but it isn't the way that gets any use as pieces or can genuinely tout that these entities are separate. It's fine if people accept systemd as "the system" but of those to whom this discussion has any relevance, a nontrivial portion find that a little hasty.

As for mixing and matching in any conceivable way, its all a matter of perspective. The businessman and the scholar will have actions that will largely overlap, but what defines them is which compromises they make. I have explicity refrained from calling the way systemd does things "bad" (and I don't even believe that) and have instead called it unappealing and in conflict to me and the way I operate because I make some compromises that may not even be an option for you.