this post was submitted on 27 Aug 2023
150 points (96.3% liked)

Linux

48182 readers
2057 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

Related Communities

Community icon by Alpár-Etele Méder, licensed under CC BY 3.0

founded 5 years ago
MODERATORS
 

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?

you are viewing a single comment's thread
view the rest of the comments
[–] hunger@programming.dev 1 points 1 year ago (1 children)

None of these even want to include support for features found in the Linux kernel, so that they work can work on all Unix systems out there. Thatbis a design decision eachnofnthese made.

So none offers similar features to lock down services out of the box, as those rely on Linux specific kernel features. Of course you can hack that into the init scripts somehow. Sysv-init has shown how well that worked cross-distribution.

Systemd moved the goal posts for what a Linux init system needs to do. I doubt any generic Unix init system can compete.

[–] 7heo@lemmy.ml 2 points 1 year ago* (last edited 1 year ago) (1 children)

None of these even want to include support for features found in the Linux kernel, so that they work can work on all Unix systems out there.

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.

So none offers similar features to lock down services out of the box, as those rely on Linux specific kernel features.

If using Linux specific features was the only approach to security, I wonder why OpenBSD exists.

Of course you can hack that into the init scripts somehow. Sysv-init has shown how well that worked cross-distribution.

That's a bit disingenous. SysV Init has long term glaring, unrelated issues. It is really showing its age.

Systemd moved the goal posts for what a Linux init system needs to do. I doubt any generic Unix init system can compete.

Systemd moved the goal posts for what a Linux init system needs to do.

On that, I very much agree. Moving the goal posts doesn't mean "doing the right thing", however.

I doubt any generic Unix init system can compete.

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.

[–] hunger@programming.dev -1 points 1 year ago

Portability matters.

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.

If using Linux specific features was the only approach to security, I wonder how OpenBSD exists.

It is the best approach we have on anything running a Linux kernel.

systemd cannot compete with their simplicity, maintainability, smaller attack surface, and the list goes on and on and on.

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.

systemd de-facto causing other projects to put in (sometimes radically) more work than they should have to, is not okay;

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.