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
157 points (97.0% liked)
Linux
48069 readers
1332 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
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).
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.