Ive been runing Debian 12 (kde) since bookworm was released and am loving it.
I have recently discovered Devuan which seems to be Debian without systemd - what is the benefit of removing this init system?
this post was submitted on 27 Aug 2023
150 points (96.3% liked)
Linux
48182 readers
2111 users here now
From Wikipedia, the free encyclopedia
Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).
Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.
Rules
- Posts must be relevant to operating systems running the Linux kernel. GNU/Linux or otherwise.
- No misinformation
- No NSFW content
- No hate speech, bigotry, etc
Related Communities
Community icon by Alpár-Etele Méder, licensed under CC BY 3.0
founded 5 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
I'm assuming you meant to say that "none of these are sacrificing portability for features"? If so, yes, that's a feature, not a bug. Portability matters.
If using Linux specific features was the only approach to security, I wonder why OpenBSD exists.
That's a bit disingenous. SysV Init has long term glaring, unrelated issues. It is really showing its age.
On that, I very much agree. Moving the goal posts doesn't mean "doing the right thing", however.
With the feature set? Absolutely not, you are correct. But the same way, systemd cannot compete with their simplicity, maintainability, smaller attack surface, and the list goes on and on and on.
So in the end, it is down to your personal preferences.
Which is theoretically all fine; but practically, it stops being "all fine", for some people, when you consider its aggressive disregard to being compatible to literally anything else.
The systemd project is the software embodiment of the "this works and it works well, so why would you ever need anything else?!" mentality.
People take issue with the facts that "aggressive disregard to literally anything else" often translates to "having absolutely zero room for mistakes" (which, to be clear, systemd failed to honor multiple times: it isn't perfect, which would be fine, in a vacuum, but not with this mentality) and that "works well" varies drastically from case to case, and from expectation to expectation.
In short, systemd existing is totally fine, systemd being used by the majority is totally fine. systemd de-facto causing other projects to put in (sometimes radically) more work than they should have to, is not okay; and systemd de-facto making itself irreplaceable on the grounds that "it's fine, don't worry about it", is not okay.
In general: Yes. In the specific case of an init system for a specific OS: Not so much.
This is nicely demonstrated by none of the non-Linux OSes embracing any of the options you listed. They all want something that plays to the strength of their specific systems over some generic Unix thing.
It is the best approach we have on anything running a Linux kernel.
It is also easy to have really simple code that does nothing interesting whatsoever. And for something that does not do much at all, the fork-dance that e.g. s6 does is pretty complex.
Maintainability also does not seem to be a big issue for systemd at this point in time either.
The smaller attack surface is relative as well: systemd-the-init is a bit bigger than the ones you list. But the difference is not as big as you make it sound and an init system does not do many interesting things that can get attacked by either.
On the other hand systemd can seriously lock down any service it starts (and does so out of the box for anything from the systemd project and many upstream projects that ship locked down systemd unit files). The init systems you listed do can not do that directly and either need helpers (which increases their attack surface again) or just do not bother. Considering that a init system starts way more lines of code that do more security critical things than an init system: I think this lockdown does lead to a smaller attack surface of the system overall.
Somebody has to invest work to make things convenient and easy to use. You either run with what everybody else uses and share the effort or you do not and do the work all by yourself.
This is in no way systemd specific.