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?
Back when systemd was a hot topic I jumped on the bandwagon of using systemd-less distros just because people were telling me how bad it was. To this day I still use openrc but the reality is that systemd works very well and is easy to understand and use. The average user gains no benefit to using another init besides having a better understanding of how the system works.
Well and a faster boot time but it's definitely a learning curve and not really worth it unless you want to try a Distro that ships something else by default (E.g. Alpine).
SystemD replaced a variety of Linux init systems across different distros almost 10 years ago now but it is still resented by a significant and vocal section of the Linux community.
Realistically, at this point, non-SystemD distros are of niche interest. Devuan is one of the distros available in that niche
SystemD replaced a variety of Linux init systems across different distros almost 10 years ago now but it is still resented by a significant and vocal section of the Linux community.
No, it is not. It is always the same few people that repeat the same slogans that failed to convince anyone ten years ago. But that does not really matter: In open source the system that can captures developer mind share wins. Systemd did, nothing else came even close.
what you just wrote doesn't seem to contradict what you quoted in any way. even if there haven't been any people in the past decade who decided they prefer avoiding systemd (unlikely), there's still that vocal minority of linux users that you yourself acknowledge, so idk why you're posturing like you're in a disagreement?
edit: a typo
There is no significant section. It is just a few people telling each other the same old conspiracy stories over and over again.
ooh, conspiracy stories? do tell, if you'd like. i've never seen conspiracy stuff in this debate, but conspiracy theories are a cognitive failure mode that fascinate me.
For average users, it's a matter of preference. Like asking what's the benefit of chocolate over vanilla.
You are curious though, so I'd recommend giving another init system a try. That would give you some perspective on systemd.
Very valid alternatives include:
- s6
- runit
- openrc
- BSD rc.d
And you can find a pretty complete list here.
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.
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, absolutely, and that's very much 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 how 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 disingenuous. 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.
On that, I very much agree. Moving the goal posts doesn't mean "doing the right thing", however, and this fact is a big part of the reason some people complain about it.
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 systemd's aggressive disregard to being compatible with 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 being compatible with literally anything else" reasonably 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, it does not, always, "work well" for everyone and/or in every use case).TL;DR: 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.
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.
I swear I saw one but no idea how to properly search lemmy. Here's todays thread though https://aussie.zone/post/1515282?scrollToComments=true
