Uselessd: A Stripped Down Version Of Systemd

[jayrulez]

Who are the "we" that the web page refers to? The author/developer claims to be a single person.

[Zan Lynx]

Maybe it is Lennart.

This would be awesome and perfect if true.

Once everyone is using it then he reveals himself. The Xanatos Gambit!

[tomegun]

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.

There is absolutely no reason why others can not also implement a userspace kdbus component. There is work under way to port over libdbus and gdbus, I'm not aware of anyone redoing the userland side of the kdbus equivalent of the "dbus daemon" outside of systemd, but that is relatively speaking much less work than the library itself.

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.

Correct. We merged the ones that makes sense in isolation, but rejected things like reimplementing functions (some of these patches I rejected were just falling back to POSIX-complient functions with a different semantics to the glibc ones, which broke the code or made it insecure). I gave the reasons for the rejections on the ML, but to recap: we will try to make reasonable accomodations, but we will not reimplement library functions, ask your libc to reimplement it (and if there is a good reason why they cannot, then surely the same reason should apply to systemd as it is running on the same system).

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.

As systemd is depending a lot on udev (even before the merge), this was always a non-starter. And once kbus is in, we will surely make a lot of use of that, there are so many thinsg that are done in crappy ways today just becase we don't have a proper IPC mechanism available at all times.

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"?

Hm, I think we are talking past each other. This is my view: we are not interested in restricting ourselves at all in the functionality we use our dependencies, we have chosen these dependencies and now we want to use any useful feature they might have. The cost of this is portability, but we have said up front that that is a explicitly not an aim (and that sacrifice has given us huge benefits). If people want to port systemd, then they should maintain a portable fork, similar to how openssh et al are made portable.

Worth is defined in relation to something else. [...] the systemd folks don't find it worth extending compatibility to those other implementations. Not worth time, not worth effort - simple as that.

Each of the libc's may have their worth, but, to me, trying to support more than one at a time does not. So even if the choice had been arbitrary, I would still prefer to make the choice of _one_ API to code against rather than several (and don't tell me POSIX is that API, we want of course the API closes to fulfilling our requirements).

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.

I would claim that in this case, the bug would be in non-compatible libraries conflicting with eachother...

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.

In the case of gnome and systemd, the case is somewhat simple, as there is no serious alternative provider of the API Gnome wants to use from systemd, so falling back to losing the features seems fair enough.

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.

Hm, systemd and networkd do not talk to each other at all. The only relationship is that networkd runs like a "new-style daemon" in the sense of "man 7 daemon". I.e., it does not double fork, nor sanitize its environment. In short, it takes advantage of the features systemd as PID1 provides.

It is far less of a program in its own right and more of a plugin.

No, not at all. Sorry if I was unclear in my earlier post.

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.

Firstly, it would not be hard for a third-party to reimplement systemd's "new-style" daemon setup (that's probably the reason it was not called "systemd-style", I guess no one anticipated that there would no longer be any other serious init systems around).

As for mixing and matching in any conceivable way, its all a matter of perspective.

Absolutely, and that what I intended to say: I _get_ why people would _want_ to do this (though more in the sense of "oh this would be cool" than "I need this in order to do my job"), but for us it makes no sense, and would seriously hamper our efforts, so we are not going down that road. I mean, as long as everyone can get the features needed to actually get their stuff done, we just have to accept that we cannot fully please everyone's idea of philosophy/style...

[Delgarde]

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).

Which is why, although users like having choices, developers hate giving them. Every bit of unnecessary complexity is another source of problems...

[pal666]

Please, elaborate.
The concept behind Launchd and Systemd is broken, they do not do only one thing.

you do not do only one thing either. you are broken even more.

[nanonyme]

The "do one thing" is about single programs/modules/however functionality makes sense to split for reusability. Claiming a software system should do only one thing is blatantly absurd and downright ignorant.

[BwackNinja]

There is absolutely no reason why others can not also implement a userspace kdbus component. There is work under way to port over libdbus and gdbus, I'm not aware of anyone redoing the userland side of the kdbus equivalent of the "dbus daemon" outside of systemd, but that is relatively speaking much less work than the library itself.

Hm, systemd and networkd do not talk to each other at all. The only relationship is that networkd runs like a "new-style daemon" in the sense of "man 7 daemon". I.e., it does not double fork, nor sanitize its environment. In short, it takes advantage of the features systemd as PID1 provides.

Firstly, it would not be hard for a third-party to reimplement systemd's "new-style" daemon setup (that's probably the reason it was not called "systemd-style", I guess no one anticipated that there would no longer be any other serious init systems around).

There were always "serious" init systems around, and the uselessd page mentions that and there certainly was a false tricotomy of systemd, sysvinit, and upstart with occassionally a sprinkle of openrc. If sysvinit was in the running at all, then there's definitely no reason to have completely ignored the existence of others like runit or other daemontools-style init systems. Systemd went the route of having a far tighter coupling of components which is both something that the others tend to explicitly avoid and what pushed it ahead as interesting, worth evaluating, and controversial. That being said, I've taken another look at the source to understand the coupling better because of your continued assertions that it would be relatively easy for another to implement another kdbus userspace and that the coupling between networkd and systemd isn't so tight. I may still need to take a closer look, but it looks like you're mostly right on that point. That however only makes me question your statement "In short, it takes advantage of the features systemd as PID1 provides," because like this we start talking about systemd the consolodated daemon library as separate from systemd the init system or even PID1. I'd ask when sd-event.h would become more than an internal header and be available for external projects to use. I can understand that its interface is still in flux, but are there plans to allow it to be used by external projects? Taking it one step too far, I'd like to see what it would really take to build and run some of these components without at least booting with systemd. I'd have to find the time, but it should prove to be an interesting challenge - worst comes to worst, I learn something.

Hm, I think we are talking past each other. This is my view: we are not interested in restricting ourselves at all in the functionality we use our dependencies, we have chosen these dependencies and now we want to use any useful feature they might have. The cost of this is portability, but we have said up front that that is a explicitly not an aim (and that sacrifice has given us huge benefits). If people want to port systemd, then they should maintain a portable fork, similar to how openssh et al are made portable.

Though also removing a lot, this is what uselessd is doing and even if it doesn't succeed further it tells everyone that it's certainly possible to do. Things are moving forward.

Absolutely, and that what I intended to say: I _get_ why people would _want_ to do this (though more in the sense of "oh this would be cool" than "I need this in order to do my job"), but for us it makes no sense, and would seriously hamper our efforts, so we are not going down that road. I mean, as long as everyone can get the features needed to actually get their stuff done, we just have to accept that we cannot fully please everyone's idea of philosophy/style...

And some people like to fix their own cars. It isn't their job. There's someone else whose job it is to fix it.

The new worst thing about systemd is that I'm learning things through this discussion and its not trivial to verify it all

It looks like by the time I'm done with all of this, I'd be familiar enough with the inner-workings of the code to make competent contributions

[tomegun]

There were always "serious" init systems around

I guess "serious" is not the best term to use. What I meant is that there are currently no actively maintained initsystems around apart from systemd (at least not aimed at the generic distro market). I guess OpenRC is the last one with any sort of activity, but even they had problems with lack of contributions last I heard.

, and the uselessd page mentions that and there certainly was a false tricotomy of systemd, sysvinit, and upstart with occassionally a sprinkle of openrc. If sysvinit was in the running at all, then there's definitely no reason to have completely ignored the existence of others like runit or other daemontools-style init systems.

IM(NS)HO, only Upstart came close to solving the sort of problems that needed solving. And the others were also not really contenders due to being essentially unmaintained (I think the importence of active maintenance is often underestimated, even if a piece of software is perfect today, the world will be a different place tomorrow).

That however only makes me question your statement "In short, it takes advantage of the features systemd as PID1 provides," because like this we start talking about systemd the consolodated daemon library as separate from systemd the init system or even PID1.

My intention was to refer to systemd as PID1, i.e., the ability to start daemons without expecting them to double-fork, and to clean up their environment first, etc. (To be honest, networkd does not rely much on this, so running it outside of systemd should probably not be a problem at all, we do not make any guarantees here though, if systemd (as PID1) provides a feature we can benefit from in networkd, we will use it.

I'd ask when sd-event.h would become more than an internal header and be available for external projects to use. I can understand that its interface is still in flux, but are there plans to allow it to be used by external projects?

All the sd-*.h headers are things that in principle could become public. sd-bus.h og sd-event.h are planned to become public once kdbus has landed in the kernel, the other things may become public one day, but it is still up for discussion.

Taking it one step too far, I'd like to see what it would really take to build and run some of these components without at least booting with systemd. I'd have to find the time, but it should prove to be an interesting challenge - worst comes to worst, I learn something.

My guess is that it is possible to make everything work without systemd as PID1, even though this is not an explicit aim/promise. Feel free to ping me on [email protected] if you are interested in looking into this further, I have some suggestions on how to do it (in particular, check out systemd-activate, though I think we need to extend it a bit to make it truly useful in all cases).

Though also removing a lot, this is what uselessd is doing and even if it doesn't succeed further it tells everyone that it's certainly possible to do. Things are moving forward.

For the record, I think it is cool that people do things like uselessd.

The new worst thing about systemd is that I'm learning things through this discussion and its not trivial to verify it all

It looks like by the time I'm done with all of this, I'd be familiar enough with the inner-workings of the code to make competent contributions

This is always a risk ;-)

[drSeehas]

... And the others were also not really contenders due to being essentially unmaintained (I think the importence of active maintenance is often underestimated, even if a piece of software is perfect today, the world will be a different place tomorrow).

launchd unmaintained?
Does Apple know?

[tomegun]

launchd unmaintained?
Does Apple know?

Touch?. I should have said "unmaintained on Linux"