A new service manager for Linux distributions
1–9 of 9 posts
Re: A new service manager for Linux distributions
#2> 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.
Re: A new service manager for Linux distributions
#3The 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.
Re: A new service manager for Linux distributions
#4The 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 tw…
> 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...
Re: A new service manager for Linux distributions
#5The 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 tw…
> 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"
Re: A new service manager for Linux distributions
#6Earlier quoted context omitted.
> 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.
Re: A new service manager for Linux distributions
#7Earlier quoted context omitted.
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.
Re: A new service manager for Linux distributions
#8Earlier quoted context omitted.
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.
Follow up: It looks like musl has been willing to carry those shims https://www.openwall.com/lists/musl/2019/08/08/4
Re: A new service manager for Linux distributions
#9Earlier quoted context omitted.
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.