Uselessd: A Stripped Down Version Of Systemd

[pininety]

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

And was that systemds fault? No, it was the upstream projects who decided they did not want to use manpower to do somethign someone else had already done for them so they could still support BSD. That is like saying "The linux kernel is bad for BSD because they have a new interface x which we do not have and upstream started using it. How dare the linux kernel make something new!"

[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),

For linux, true, but only because the systemd guys think that getting systemd to run under anything else when linux would mean they would have to rewrite basically everything. And if this is the case, why not just start a new project bsdsystemd which does exactly that? If you have no or nearly no overlapp, there is no point in putting the code into the same file riddling it with IFDEFs. Have two separate projects, share what you can and every one can be happy. problem is, nobody wants to put manpower into this. They want the systemd guys to do it for them (or at elast they did, they now started doing it themselves)

For glibc, this is not true. The systemd devs have stated that they except patches which will help to make systemd run with something else besides glibc but they will not work around known bugs in other libs because they think this bugs should be fixed in the lib, not in the applications using them.

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.

I haven't even said anything about uselessd up to now. I responding to comments explaining what systemd is and what not.
In fact, I really like the idea of uselessd. I think the name was chosen poorly (do not poison the well you might want to drink out again) and I am pretty sure I will never use it myself but if it helps the bsd guys, more power to them.

For the rest of your post, I pretty much feel the same (even if it seems I could not convey that properly up to this point). As I said, the name is in my eyes pretty stupid (why not call it lessd? But well, not my decision) but besides that -> if it helps people, more power to them.

[inhuman4]

The problem I have with SystemD is there is probably a bunch of crap in it I don't need. I would rather have it broken down into it's constituant components that can be enabled or disabled as needed.
Hell keep all the components under the same banner idfc, but make it modular.

That is how it works. 'systemd the project' compiles into something like 70 binaries and includes things like journald, logind, etc. that can be turned on and off like any other service. Only 'systemd the process' runs as PID1.

[schmalzler]

That is how it works. 'systemd the project' compiles into something like 70 binaries and includes things like journald, logind, etc. that can be turned on and off like any other service. Only 'systemd the process' runs as PID1.

No, that's not true, at least for journald. You can't turn it off. AFAIR you even couldn't in the past. Journald only passed logs over to your system logger. But journald always had to run. That's nothing you call "opt in" but "forced".

[carewolf]

Reminds me off when I wanted to replace pulse (maybe call if flatline), with something that wasn't a sound daemon but did the rest (control ALSA-channels, mange bluetooth headsets, etc). I would call it flatlined. The more I thought about it I reliased it would have to be something kind of system daemon, and the best design would be to make it handle all similar issues with services and devices, and thus making it a central part of the init process. so I gave up. I discovered a year later a new project call systemd that sounded awefull, until I realized Lennart the bastard had stolen my idea by reading my mind, and actually done the work to make it work.

[pininety]

No, that's not true, at least for journald. You can't turn it off. AFAIR you even couldn't in the past. Journald only passed logs over to your system logger. But journald always had to run. That's nothing you call "opt in" but "forced".

That is true. journald is a exception but it is still its very own process (so crashing journald will not crash your init process and therefore not your PC) and you can remove nearly all functionality from it.

[NotMine999]

And All The Comments Here...

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

...remind me of the old days when people argued about "Windows versus Apple Whatever".

With all the mis-spellings, senseless rants, sockpuppetry, "confusing the issues with somewhat off-the-mark quotes", and so on...

Those of us that lived through the "OS battles" have "grown up", "had kids", and "figured out there were more important things to waste our time arguing about".

Here's to hoping this new generation, whatever they are called, follows the same path as us oldsters....

[interested]

No, that's not true, at least for journald. You can't turn it off. AFAIR you even couldn't in the past. Journald only passed logs over to your system logger. But journald always had to run. That's nothing you call "opt in" but "forced".

Well, it has always been supported to use systemd without journald, it just isn't a compile time configure switch, but only meant for embedded developers who knows what they are doing.

Remember, that by making journald a core part of systemd (like udev) that is meant to run on all general purpose platforms, it is possible to support the old syslog daemons without any modifications, and still get the benefits of early boot and late shutdown logging.

Doing it any other way than the present way, would mean sacrificing features or backward compatibility.

As it is now, journald enhances the old syslog daemons for those who have special user cases for needing them, while still improving tremendously on how logging is done on Linux.
So the systemd way of doing things, is always a better solution than what was before.

[BwackNinja]

And was that systemds fault? No, it was the upstream projects who decided they did not want to use manpower to do somethign someone else had already done for them so they could still support BSD. That is like saying "The linux kernel is bad for BSD because they have a new interface x which we do not have and upstream started using it. How dare the linux kernel make something new!"

There's a large difference between what's low-level and what's high-level. A new init system isn't a problem for anyone in any situation. Problems only arose when systemd was a lot more than an init system - when there were these interfaces that high-level rather than just low-level projects had to deal with. That's not to say that the systemd folks did anything bad, ConsoleKit has been dead and doesn't handle multi-seat, and those other interfaces are useful - hence why there are used. However, the addition certainly altered the course of development. As projects like Gnome move from being a Unix system to a Linux system without even dealing with a direct kernel dependency, no matter how legitimate the reasons are for the changes, people will feel marginalized because they're been explicitly left behind and told they don't matter. The more legitimate those reasons sound, the more that it stops being the higher level projects blamed, but rather the lower-level changes that they are now depending on.

For linux, true, but only because the systemd guys think that getting systemd to run under anything else when linux would mean they would have to rewrite basically everything. And if this is the case, why not just start a new project bsdsystemd which does exactly that? If you have no or nearly no overlapp, there is no point in putting the code into the same file riddling it with IFDEFs. Have two separate projects, share what you can and every one can be happy. problem is, nobody wants to put manpower into this. They want the systemd guys to do it for them (or at elast they did, they now started doing it themselves)

For glibc, this is not true. The systemd devs have stated that they except patches which will help to make systemd run with something else besides glibc but they will not work around known bugs in other libs because they think this bugs should be fixed in the lib, not in the applications using them.

The whole idea to begin with is that they didn't have to rewrite systemd. There is no from-scratch compatible alternative made. This is a modified systemd - only changed in the ways that systemd itself refused to change. That is certainly the healthy way to go about it and it also argues positively about the code quality in the systemd project. As for glibc, the systemd devs have stated that they will not support other libcs nor would accept patches though they were given. It is either implement the non-portable interfaces of glibc or go home.

I haven't even said anything about uselessd up to now. I responding to comments explaining what systemd is and what not.
In fact, I really like the idea of uselessd. I think the name was chosen poorly (do not poison the well you might want to drink out again) and I am pretty sure I will never use it myself but if it helps the bsd guys, more power to them.

For the rest of your post, I pretty much feel the same (even if it seems I could not convey that properly up to this point). As I said, the name is in my eyes pretty stupid (why not call it lessd? But well, not my decision) but besides that -> if it helps people, more power to them.

I have to agree with you about the name, but in part I expect this to be more of an attention-grabbing effort than a serious name. The point however, isn't even primarily to help the BSD guys, it's all about helping those who want to like systemd on Linux and have their various reasons for saying no that don't involve it's performance as an init system. When a lot of Linux portability is handled, BSD suport starts becoming low-hanging fruit.

We'll all see how things go from here, but there's renewed hope for systems being diverse without also being backwards.

[a user]

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.


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


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



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.

QFT

Sorry, but i rarly see such a good post and just wanted to show my agreement to this.

[pininety]

There's a large difference between what's low-level and what's high-level. A new init system isn't a problem for anyone in any situation. Problems only arose when systemd was a lot more than an init system - when there were these interfaces that high-level rather than just low-level projects had to deal with. That's not to say that the systemd folks did anything bad, ConsoleKit has been dead and doesn't handle multi-seat, and those other interfaces are useful - hence why there are used. However, the addition certainly altered the course of development. As projects like Gnome move from being a Unix system to a Linux system without even dealing with a direct kernel dependency, no matter how legitimate the reasons are for the changes, people will feel marginalized because they're been explicitly left behind and told they don't matter. The more legitimate those reasons sound, the more that it stops being the higher level projects blamed, but rather the lower-level changes that they are now depending on.

it would still the Gnomes fault, not systemds. If people do not like it, they should go and complain to Gnome and not, like they do right now, go to systemd and complain there.

The whole idea to begin with is that they didn't have to rewrite systemd. There is no from-scratch compatible alternative made. This is a modified systemd - only changed in the ways that systemd itself refused to change. That is certainly the healthy way to go about it and it also argues positively about the code quality in the systemd project.

Let me rephrase this. If they wanted to have systemd running with all its functions under BSD, they say they would need a rewrite due to heave use of Linux specific components. uselessd basically removed all this functionality as far as I can tell (they removed a tone of unit types-> devices, timers, swaps, mounts and automounts to be precise meaning that all software which is using this will run under systemd but not under uselessd). They apparently want to do just do the starting/stopping part of service management but how they want to do ressourcemanagement (if at all) is a mystery to me.
So yeah, if you just drop all the functions you cannot port over then you clearly can port it over ^^

As for glibc, the systemd devs have stated that they will not support other libcs nor would accept patches though they were given. It is either implement the non-portable interfaces of glibc or go home.

So I went back, searched the mail I meant, and you are nearly right (but way more right then my previous statement so sorry for that)

let me quote part of the mail:

Humm, I know this will disappoint you, but we are not particularly
interested in merging patches supporting other libcs, if those are not
compatible with glibc. We don't want the compatibility kludges in
systemd, and if a libc which claims to be compatible with glibc actually
is not, then this should really be fixed in the libc, not worked around
in systemd.

There are some exceptions to this rule, but very few: if you can argue
that glibc is borked in some area we might be willing to merge a patch
that does it correctly on some other libc, if it is not intrusive. But I
am pretty sure it will be hard to find many places where this
applies. But examples of this could be: on glibc including one .h file
implicitly imports another one whose symbol we use. If your libc does
not implicitly pull it in in the same .h file, then we would accept a
patch that adds an explicit #include for the other file. That way our
stuff would compile on both libcs, and we can argue that the glibc part
is now more descriptive.

(original mail: http://lists.freedesktop.org/archive...ly/002935.html)

So yeah, they are way more restrictive then I remembered, mea culpa.
Thanks for correcting me on the matter.

[EDIT]
Oh, I just saw that uselessd also removes logind. Hopefully we will get a replacement for that as well or we will have the whole "gnome does not run without systemd" all over again.