Uselessd: A Stripped Down Version Of Systemd

[plonoma]

I agree with this wholeheartedly.

And I'm saying that as someone who actually likes systemd. If it doesn't work for you, make an alternative instead of just bitching (like most of the community is doing).

+1
This, if the people who say systemd is to bloated, have them come up and show their own alternative.

If only they had chosen a better name.
Maybe usefuld or something else.

[Brane215]

The concept behind Launchd and Systemd is broken, they do not do only one thing. They try to do multiple things and become a single point of failure.

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 ?

With systemd, they import things that they intent to use, so if dhcp implementation starts acting flakey, they are more likely to see the problem first and then do something about it.

There's even more, although you can use traditional syslog it defaults to a binary logging system depending on Systemd.
They're monopolizing the boot sequence of the OS

How so ? By pushing crappy, fragmented implementations aside ?

And, as new implementations are showing now, everyone can work on alternative.

[FishB8]

The concept behind Launchd and Systemd is broken, they do not do only one thing. They try to do multiple things and become a single point of failure. There's even more, although you can use traditional syslog it defaults to a binary logging system depending on Systemd.
They're monopolizing the boot sequence of the OS.

Leveraging PID1 was the goal of systemd from the very beginning. It was rather bluntly stated when systemd was first introduced. All these boogy man scenarios about PID1 is the same sort of arguments the miro-kernel proponents use. Yes a single point of failure can happen. Moreover it will happen now and then, and when it does you fix it. But it will ultimately it will win out, because like the macro-kernel, the advantages gained are always present while the disadvantages are only present when there are bugs. And I've had several kernel crashes in the last year, and no PID1crashes.

And for the record I find uselessd interesting. A striped down systemd compatible init with ulibc support would fit very nicely in OpenWRT.

[pininety]

Please, elaborate.

- Deadlocks by using the "and" and "or" operator as seen in https://bugs.launchpad.net/upstart/+bug/447654
- Cannot even handle mounting the file system but has to do it outside its own rule system (see existence of mountall and this https://plus.google.com/+LennartPoet...ts/ip8e1DqJdxT)

I already know.

If you already know that, why did you bring up System V scripts at all?

The concept behind Launchd and Systemd is broken, they do not do only one thing. They try to do multiple things and become a single point of failure.

First of all, you confuse the init system systemd with the user space setup system systemd. Unfortunately, the same name is used for both due to historic reasons but they should really make it easier to distinguish both.
As you brought up Launchd I will assume you are speaking about the init system systemd.
Systemd does exactly one thing. Managing services. That includes taking care that they are started, taking care that they are running when they are supposed to run as well as stopping them if they are supposed to be stopped. Thats it. There is no difference between a service started on demand, on boot or by a timer. It is all the same. It is always about starting, stopping and taking care of the service in between.

There's even more, although you can use traditional syslog it defaults to a binary logging system depending on Systemd.

The problem is that your oh so great traditional syslog is broken. You have no way to tell if someone tempered with your logs, if the logs were even given by the correct application and you get a ton of problems once you throw in multiple languages. Thought you can just grap for an error?
Well guess what, it will be a different error if the language used is English or German or Chinese. have fun with that.

They're monopolizing the boot sequence of the OS.

They are unifying the linux user space. Is there a CLA so only Red Hat can work on systemd? Nope. Are only Red Hat employees allowed to commit to the systemd git? Nope. Even some of the upstart devs have commit rights to the systemd repo. So how are they monopolizing the boot sequence?

[grndzro]

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.

[pininety]

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.

Systemd IS modular. Read http://0pointer.de/blog/projects/the-biggest-myths.html, first Myth.
But most distros just do not bother with this because most elements are very handy for them.

[schmidtbag]

It seems uselessd is a little TOO stripped down, but assuming it retains backward compatibility with systemd I think its a great idea. If commands like systemctl remain in-tact then this could really act as a drop-in replacement and not affect many users who are already using systemd. However, if this completely separates its functionality from systemd, I feel like they might as well just not even try. The goal of this SHOULD be to just "be what systemd should have been", and should not be "here's something based on systemd but otherwise has no resemblance".

If they do manage to make this backward compatible with systemd (to the best of their ability), I think it'd be cool if what they manage to fix gets ported over to systemd too. The nice thing about a project like this is we've got picky users who pay close attention to the little details and can really refine the software. The important issues could be fixed through uselessd whereas systemd devs can focus on fixing things that uselessd doesn't include. Makes for a much more efficient workflow.

[Mat2]

Systemd provided a very strict design discipline and I am afraid that this will be gone now.

I would miss especially:
- the read-only /etc dir (which was a really sensible idea, configuration should not be changed by automatic tools)
- that removing /etc and /var made a fresh system.

I am quite concerned that the developer behind uselessd is anonymous.

[BwackNinja]

Systemd IS modular. Read http://0pointer.de/blog/projects/the-biggest-myths.html, first Myth.
But most distros just do not bother with this because most elements are very handy for them.

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.

[LightBit]

I am quite concerned that the developer behind uselessd is anonymous.

Maybe it is Lennart.