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).
Faster by how much. My PC boots almost instantly now.
I never had a fast NVME SSD so my devices boot significantly slower than yours but unless you are actually at the point of instant booting it’s about half the boot time for me. I only use OpenRC on my Pinephone because it’s the default for PostmarketOS (a Alpine based OS for mobile phones) and never found a good enough reason to use it on my actual computer but it’s quite a bit faster and also quite a bit less convinient so all in all probably not worth it but still impressive to watch!
I am on an NVMe drive, however most of my boot time actually comes from the POST process so even if I were to switch to an OpenRC (or runit / another init system), it wouldn’t really have any meaningful impact on my system’s boot time unfortunately.
❯ systemd-analyze time Startup finished in 17.412s (firmware) + 2.684s (loader) + 3.587s (kernel) + 2.134s (initrd) + 9.244s (userspace) = 35.063s graphical.target reached after 9.208s in userspace.
Short version: some people (I’m one of them) object to systemd on grounds that are 75% philosophical and 25% the kind of tech detail that’s more of a matter of taste than anything else. The older sysV init is a smaller program, which means that it has a smaller absolute number of bugs than systemd but also does less on its own. Some of us regard “does less” as a feature rather than a bug.
If systemd works for you and you don’t know or care about the philosophical side of the argument, there is probably no benefit for you in switching.
If systemd works for you and you don’t know or care about the philosophical side of the argument, there is probably no benefit for you in switching.
Exactly this. There are few techincal problems with systemd, but those are so miniscule. I say this as an OpenRC+openrc-init user.
And the init system systemd replaced was also serial.
Which means that you trade some speed for making it easier to understand what’s going on at any point during init. (Also, OpenRC does have a parallel mode, although it isn’t commonly used.) “Serial” isn’t inherantly evil, it’s just another tradeoff.
I’m more bothered by the very concept of an integrated supervision suite (running as PID 1 and managing services in runtime). And with the feature creep (not-invented-here syndrome despite being mostly worse on all metrics), the following heavy binding of applications to it’s services and that it can’t coexist, because of that, with any other init/service manager in a repo without an uncount number of wrapper scripts (some distros tried).
taking a breath Which is why we must have specialized not-systemd distros instead of Choose-your-iso-with-bootloader-X-and-Desktop-Y distros, like Artix does (a not-systemd distro).
The attitude of the devs to technical issues and even security holes is another issue. Systemd is really bad software in that regard.
I basically lump everything you’ve listed under “philosophy”—poorly chosen design goals and no one at the project doing anything about dev behaviour are not technical flaws per se, as the software is functioning as intended and expected.
systemd and init+OpenRC can exist together in the same repository, though—it just means that the repository also needs to contain both init scripts and service files, both of which are trivially small.
As a Gentoo user since 2005, I’ve been able to watch the entire debacle as it’s progressed, and the various efforts required to keep udev and friends working separately from systemd. (Currently, there are 7 Gentoo packages on the “absolutely requires systemd” list—6 optional daemons that I don’t perceive as being very useful, although maybe it’s just me, and one library that I’ve never heard of in any other context. So what’s being done to keep it from taking over is working.)
Ok, except OpenRC.
- argv_minus_one ( @argv_minus_one@beehaw.org ) 40•10 months ago
None. The opposition to systemd is highly irrational.
That statement is factually false.
Now we have both said almost nothing.
The only valid argument I see is monoculture. If systemd every does fall out of favour, become broken or compromised in some disastrous way it will be a lot of work getting going again.
- argv_minus_one ( @argv_minus_one@beehaw.org ) 3•10 months ago
The same is true of Linux itself.
Anyway, I’m not sure I see how a non-gigantic, slow-moving, pretty-much-finished open-source project like systemd can become broken or compromised in a way that forking it cannot solve. This isn’t Chromium we’re talking about, where it takes an army of world-class developers just to keep it from falling so far behind as to be basically unusable. If systemd were to stop being developed in any way other than security and critical bug fixes, it would still remain useful for many years.
Systemd is huge. It’s a complex project that covers not just the init system, but also process management, networking, mounts, sessions, many other things. Many people think its monolithic design run counter with the Unix philosophy and wish to use distros without systemd.
Just to avoid misunderstandings: it’s not a monotolithic blob, it is thought so because its first project was a system daemon that manages system services. It is described as “a software suite that provides an array of system components for Linux operating systems.”, it is highly modular and offer many optional components that each have their own purpose.
You’re conflating a monorepo and with software monolith.
The development style of systemd is the same as most BSDs, and nobody in their right mind would argue those are counter to the Unix philosophy.
- argv_minus_one ( @argv_minus_one@beehaw.org ) 8•10 months ago
If a collection of programs that each do a specific thing runs counter to the Unix philosophy, then Unix runs counter to the Unix philosophy.
5 minutes of fame when Debian said “if you want other init systems, maintain them”, soon-to-be-Devan folks slammed the door and effectively ruined the chance of multi-init debian by fracturing efforts into their fork instead. But hey, all the news were abuzz about them.
It may speed up your boot time, at least it happened to me on Void (maybe the reason is how minimal this distro is though). I personally prefer runit over systemd in how it handles services, but honestly you most probably won’t notice a much difference - definetely not worth reinstalling whole system.
Not to mention runit is a few thousand lines of code, systemd is 1.5 million plus. From a theoretical standpoint it’s an extra massive attack surface.
That comparison is bad on several levels:
First off, systemd-the-repo does contain way more than an init system. But yes, I am pretty sure systemd-the-init is slightly bigger than runit.
Secondly: Systemd-init does set up some useful linux kernel features for the processes it manages in an easy and consistent way. That’s why other services started to depend on systemd-the-init by the way: Systemd does linux-specific things developers find so useful that they prefer adding a dependency on systemd over not having the functionality.
Runit does not support any linux kernel specific features at all to stay portable to other unixes. Other alternative inits made the same design choice.
Thirdly: The overall attack surface of the system without systemd is bigger than a typical systemd system. That’s because so much code run by the init system is way more locked down as systemd provides easy ways to lock down services in a cross-distribution way. Note that the lockdown functionality is 100% linux kernel features, so it involves little code in the init itself. Users of other inits can of course add the same lockdown features as service-specific startup code into the init scripts. We saw how well that works across distributions with sysv-init…
Finally lots of security features implemented outside systemd-the-init require a systemd system as they need the lockdown features offered by the systemd-init. One example is systemd-logind: That depends on systemd-init to be secure where the pre-systemd attempts all failed to archive that goal. Logind makes sure only the user sitting at a screen/keyboard can actually interact with the device interfaces of the kernel device files managing that hardware, so no other user but you can see ehat you type and take screenshots of your screen. Contrast that to devuans approach: Add all users allowed to start the UI to a group and make the devices controllable by that group. Much simpler, KISS and the Unix way… but it also allowes all users on the system that ssh into the machine somebody sits on can log what other users can type. Apparently that is not a problem, since no system ever will have more than one user in the age of personal laptops and desktops. That seriously isvtheir answer… and they even rejected to maintain the ubuntu-before-systemd logind replacement when canonical asked them, because such functionality is not needed im Devuan.
Runit is brilliantly simple, and as the old granite maul examine text says, “simplicity is the best weapon”.
I’m sorry, you won’t be able to convince me to use it, it doesn’t feel KISS (I left Arch when they swapped). Fuck binary logs too. The only place I use it is on my phone which is SailfishOS.
Void to me is what Arch used to be – I tend to use minimal replacements where I can, e.g. Openntpd as ntp, socklog as logger, seatd as logind, zfsbootmenu instead of systemd-boot, no polkit et cetera.
it’s the closest usable distro for me to cut most of the poetteringware out apart from messing around with Gentoo (which I can’t be arsed with any more). I am not a fan.
Like or dislike systemd, be it convenient or not, you can’t deny it’s a behemoth.
I am not trying to convince you: Use whatever you want.I am trying to explain it, so that people can have a more informed discussion. The web is full of either systemd is the best since sliced bread and systems is horrible. It is neither: It is just a technical system that made technical choices that make certain things easier or even possible and others harder or even impossible.
The sytemd time thingy is actually more minimal than openntpd: It only supports sNTP and not the full NTP protocol and is a client only… Openntpd is a full NTP implementation with both client and server. It also is a great technical choice, so keep using it, especially when you need an NTP daemon.
You behemoth is my plumbing layer:-)
I like the ton of small and simple tools that systems brings along: systemd-nspawn is a really lightweight way to run containers that works basically everywhere, no need to install docker or podman. Disk resizing, sysusers, tmpfiles, boot, Key Management, homed, etc. enables me to build reliable, immutable images for my systems. There is no tooling whatsoever for this outside the systems umbrella.
If you do not try to build a 1980-style UNIX system, then you basically are stuck with systemd. Nobody else is even thinking about how to move forward. If you try to raise the challenges you see outside systemd, you get laughed at and are told that your usecase is obviously stupid. The limitations admins ran into 1980 are gospel now and you may not question any of that.
Fair play, as you say it is a “love it or hate it” affair. I personally really like the simplicity and stability of old school UNIX.
OpenBSD comes to mind as the closest thing in contemporary times and I would use it as a daily driver but I need Linux for a few bits.
Void to me seems like the Linux equivalent. Minimal, stable, no bullshit. Alpine also fits this criteria but is a bit more sparse in some packages that I use. Both great distros.
Systemd is 1.5+ million lines of code! However convenient, it felt forced by Redhat into the Linux world and many of us who do not like it feel bent over backwards to be fucked in the arse by Poettering et al.
As solely an init system, may I suggest a superior alternative, s6?
(I am in hospital on morphine so I may not be making sense).
Fuck binary logs too.
Text logs are binary, too… they just uses a pretty common binary encoding.
Where do you actually use text logs? I did not use text logs outside of hobby machines ever during my career. Logs were either aggregated in databases or at least stored in temper-resistant formats (usually due to legal requirements).
Do you actually use text logs in a professional setting? Just curious.
If binary logs get corrupted they’re kaput; text logs are not (as far as I know?). Also you cannot grep binary logs? I wouldn’t know.
No, I just have used Linux/BSDs for ~15 years in a non-professional setting.
With textlogs you have a hard time noticing a couple of added/removed/changed characters or even entire log entries. Thats exactly why some industries may not use text logs in the first place as permanent records that are at least temper-evident are mandated.
If binary logs go kaputt they tell you exactly which entries were effected and still display every bit of data they contain. Typically you do not grep in binary logs: Grep can not make sense of all the extra data in the logs (way more than in a typical syslog), so grep is just a poor tool for the job. You typically can use grep as binary logs so contain lots of text. This is ignoring compression, encryption and other extras of course.
You should embrace systemd. It’s actually good. Replaces all startup scripts, logs to a common log, even has scheduled systemd jobs just like cron but better, since they can have proper dependencies. Want to run something right after network stack is up and working? Easy with systemd, more difficult with cron and more hacky.
There are some security, privacy and stability advantages of other init systems over systemd. But for most people systemd should be fine.
See here for further info:
https://madaidans-insecurities.github.io/guides/linux-hardening.html#choosing-the-right-distro
https://forums.whonix.org/t/fixing-the-desktop-linux-security-model/9172/2
https://www.unixsheikh.com/articles/systemd-isnt-safe-to-run-anywhere.html
https://unixsheikh.com/articles/the-real-motivation-behind-systemd.html
https://suckless.org/sucks/systemd/
https://without-systemd.org/wiki/index_php/Arguments_against_systemd/
https://nosystemd.org/Also getting encrypted dns to work with systemd is pretty tough and unreliable in my experience (with debian and opensuse). See here https://github.com/DNSCrypt/dnscrypt-proxy/wiki/Installation-linux
SysV init is crap, but so is systemd as init process. One example is that an admin needs to know why the system does not boot properly. In this case the kernel messages help. systemd is not helping here.
I’ve currently one problem that I need to solve, but I need 2 people, one to make a video, the other to press Ctrl+Alt+Del to capture an error message that appears for 0,1s after sending the key sequence, when my PC does not boot. This is crap! Why the hell it does not boot occasionally, I have no idea and I’ve been an Linux/Unix admin for 25 years now. Why I cannot find it? Of course because systemd doesn’t even log it!
This is brand new when systemd appeared. I loved to see the kernel messages to full extent…
My problem with systemd is that since I’m practically forced to use it that it’s flakey in starting services after boot (independent of service and distro). Since systemd I had to install monit to check if all services came up. Didn’t had that problem before. Or I forgot, it’s been a while…
Don’t worry about the downvotes, Lemmy is a systemd sausage fest. If you want negative “karma”, just write “systemd bad” or even “pulseausio bad” anywhere, and wait…
Well yes, if you don’t provide intelligible arguments it doesn’t deserve better. And a lot of the arguments really are like that: “systemd bad” or “is monolithic blob” (which it isn’t).
Lol. Thanks. I really don’t care. I’m running linux servers professionally since the late 90s, which means I have seen one or the other WTF. And systemd had quit some of them, especially flooding log files and race conditions. For example see https://github.com/systemd/systemd/issues/7293. That took more than 2 years to fix. And if people like to downvote my personal experience with it they are welcome to do so. I mean all I did was answering a question why one might use a systemd free distribution. Oh and for the downvoters: SYSTEMD IS MICROSOFTS ATTEMPT TO KILL LINUX! Poettering always was their agent. https://en.m.wikipedia.org/wiki/Lennart_Poettering 😉
- argv_minus_one ( @argv_minus_one@beehaw.org ) 4•10 months ago
Use
systemctl --failedto see which services didn’t come up,systemctl status SERVICENAMEHEREto see some status info about a service, andjournalctl -b -u SERVICENAMEHEREto see all log messages generated by a service since last reboot. systemd does have one problem that also existed before: sometimes services come with buggy unit files (or copy/pasted from something else and modified), similar to how there were all kinds of buggy scripts before. Unit files are much simpler than scripts and it should be easier to get right but when the author sometimes doesn’t consider dependencies or test fail scenarios…
I don’t personally like SystemD, but Devuan sucks. They advertise “init freedom”, but in reality all of the scripts by default are just sysV init scripts that runit and openrc can’t control.
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.
Check out the devuan mailing lists then:-)
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.
runit++
Uhm, it’s Systemd.
I think this guy has a few points.
never seen this before, heard of the others but s6 is new to me. very interesting
Alpine is about to switch to it for a while now. Which is imho the best place for s6*, servers.
Try MX Linux it’s based on Debian. MX23 is based on Debian 12. You can boot with or without systemd as you please. Great distro!
