A new service manager for Linux distributions | Hacker News Reader

A new service manager for Linux distributions

skarnet.com

20 pointscloseneough8 comments

> lightweight: No. systemd uses way too many resources for system infrastructure software.

I'd love to see some numbers for this point. I'm also curious what's the threshold for too many resources for the author.

The goals distinguishing from other init systems seem to be:

- musl support

- guaranteed bootability

It's not easy to extract this from the post, since it's hidden between value statements like "flexible", "small", "fast", "unpredictable", which aren't defined anywhere, nor supported with external statements.

Since those aren't defined, it's also not clear why the author didn't decide to contribute support for the two defined criteria to systemd.

> it's also not clear why the author didn't decide to contribute support for the two defined criteria to systemd.

Because the first one means working against two projects - one which wants to keep its surface lean and one which says "glibc is de-facto standard, deal with it".

https://github.com/systemd/systemd/issues/10130#issuecomment...

That comment suggests that patches will be accepted to support musl, and it links to a merged PR where the commit message is quite literally "fix compile errors on musl"

Some patches yes, but it also says that systemd will not carry shims for the missing glibc APIs.

Why would they? That wouldn't really help anybody, it would make the most sense to put those shims in a separate library, so any glibc consumer can use them. I'd expect the shim would also be useful to getting glibc consumers running on BSD and other libcs too.

It really depends what your expectations about the environment are. Systemd is a large user of very specific functionality that they have good reasons not to replace with something else. Since it keeps running into those issues, it may be more beneficial for wider community if systemd included the missing shims conditionally. They'd be able to put it in CI and treat musl as first class platform so people don't have to report back with similar issues after the release. Not exactly like, but similar to how openbsd has openssh and everyone else has the official openssh-portable.

Their stance is not wrong, but it's probably not what many people would like to see.

Follow up: It looks like musl has been willing to carry those shims https://www.openwall.com/lists/musl/2019/08/08/4

Reply on news.ycombinator.com