[dmix]

I appreciate your work on uselessd. Nothing demonstrates a counterpoint quite like written code. The last thing we need is another ranting systemd blog post.

We always need strong alternatives, even if they face the risk of being taken as simply a political statement, the effects of the statement will be seen in the decision-making down the road.

[exDM69]

Yes! What the systemd "discussion" has been missing is viable alternatives that are somewhat comparable in features. Most of the flamewar is focused on people who consider the problems that systemd tries to solve non-issues.

There are some real issues being pointed out (particularly regarding monolithic design) but no-one has attempted to actually fix that in any way (in code, that is).

While it is unlikely that I will end up using uselessd (unless it "wins" in some way, e.g. in embedded space with uclibc and musl), I very much welcome the effort to bring out alternatives that address the same problems as systemd, yet trying to fix some of the issues there are.

[dalias]

There are plenty of viable alternatives: s6, runit, OpenRC, and so on. I'm not really convinced uselessd is a viable alternative - it keeps way too much of the badness of systemd, but I guess that makes it viable if you were willing to consider systemd to begin with.

A much better solution for the problem of user-facing applications (e.g. "desktop environment" software) depending on systemd's public dbus interfaces is to provide a fake service that gives them fake data - the same way you would sandbox Android apps for privacy by giving them a fake Contacts list, etc.

As for the other main "public interface" of systemd that things are starting to depend on, the systemd service file format, it would be easy to add support for this file format to any other process supervision system.

[uselessdguy]

Hey, Rich. First of all, thanks for musl libc.

At the moment, yes. We do keep much of the internal systemd architecture in tact, but we do eventually aim on partially decoupling it, or at the very least expanding the breadth of configure prefixes for tuning its behavior. We are a pretty early stage project, after all.

Indeed, the systembsd and systemd-shim projects are working on the D-Bus interface reimplementation part.

Our goal right now is to be a minimal systemd base that can be plugged in interchangeably and have the vast majority of unit options be respected.

There already are systems that offer primitives to reuse systemd units. nosh is one of them, and there also exist scripts that can convert systemd services to SysV initscripts, and even the opposite (dshimv).