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?
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?
It’s mostly opinionated. systemd is written in C, uses a consistent config, is documented well, has a lot of good developers behind it, is very fast and light, and does what it’s doing very well. Since systemd also is split up into multiple parts, it still follows the “do one thing, do it right” philosophy.
There are some people that believe that systemd “took over” the init systems and configuration demons of their distro, and does “too much.” It really does quite a lot: it can replace GRUB (by choice), handle networking config, all the init stuff of course, and much more.
However, I have lived through the fragmented and one-off scripts that glued distros together. Some distros used completely custom scripts for init and networking, so you had to learn “the distro” instead of “learn Linux.” They were often slower, had worse error handling, had their own bugs, were written in various scripting languages like tcl, Perl, Bash, POSIX shell, etc. It was a mess.
The somewhat common agreed-upon init system was System V, which is ancient. It used runlevels, nested configuration (remember /etc/rc.d?), and generally, it was mostly used because it was battle tested and did the job. However, it is arguably esoteric by modern standards, and the init philosophy was revised to more modern needs with systemd.
You can probably tell my bias, here. If you have to ask, then you probably don’t have a “stance” on systemd, and in my opinion, I would stick with systemd. There were dozens of custom scripts running everywhere and constantly changing, and systemd is such an excellent purpose-built replacement. There’s a reason why a lot of distros switched to it!
If you want to experience what other init systems were like, I encourage you to experiment with distros like the one you mentioned. You might even play with virtual machines of old Linux versions to see how we did things a while back. Of course, you probably wouldn’t want to run an old version of Linux for daily use.
It should also be mentioned that init systems are fairly integral to distros. For example, if you install Apache httpd, you might get a few systemd .service files. Most distros won’t include init files for various init systems. You can write them yourself, but that’s quite a lot of work, and lots of packages need specific options when starting them as a service. For this reason, if you decide you want to use a different init system, a distro like the one you mentioned would be the best route.
Great question, and good luck! 👍
I liked runlevels. 🤷
Targets are just a more flexible, granular run level. Plus it can actually handle dependencies.
I was reading about Slackware today and it seems their init system still uses system V and lots of scripts.
So I’d definitely recommend that OS to anyone curious about the old style of init system.
I never really noticed init scripts differing much between distros, but I also didn’t play around with many. If the systemD scripts are the same across every system, then this is the first positive thing that I’ve heard about systemD, so thanks for that.
Init scripts were different, I can confirm. And it was pretty bad if you were doing your job and had to change something on a Debian
massivemachine, then moved to a red hat one.Ah ok, most of my experience has been on debian or derivations in the past decade. It seems weird that the init scripts would need to be different on various systems, I thought they had been pretty well standardized, with variables in the /etc/default/ entries pointing to specific folders or startup options. Ah well.
Great answer. I do use systemd boot on one of my systems as well. It isn’t exactly systemd itself is it? Simply a boot loader packaged as part of the general systemd boot suite, right?
Systemd-the-init does depend on some core services and thise need to be used together: Init, logging and IPC. Anything running systemd-init will have journald for logging and IIRC DBus for communication. That’s because you need to control a system managing services, so you need to communicate with it and you need to document whatbthe managed services do, so you need logging. And you do want tested and stable code here (reusing something that was widely used in Linux before systemd started) and you do not want that code in the init process either. So systemd-the-init has very simple code tomlog and journald then has thencode needed to stream logs out to disk or to interact with other logging systems.
Everything else is optional and in separate binaries written in a layered architecuture: Each layer uses services provided by the lower layer and offers services to layers higher up in the stack. So lots of services depend on systemd-the-init to start other processes instead of reimplementing that over and over again (thus gaining unified config files for everything that gets started and all the bells and whistles systemd-the-init has already or will pick up later).
Or if you prefer a more negative spin: “Systemd is on huge entangled mess of interdependent binaries” :-)
Yeah exactly. It does have some features that require integration with the init system, which systemd obviously supports, but it could be used independently of systemd quite happily, and other init systems could easily support those integrations.
I am fan of principles like KISS and “Do one thing and do it right”. From this point of view is systemd disaster because it is almost everywhere in the system - boot, network, logs, dns, user/home management… It’s always surprise for me if nothing breaks when I do upgrades.
I understand why systemd is here but I’m not at all happy to use it.
That’s almost like complaining that GNU coreutils is a disaster from KISS point of view because it includes too many things in a single project - cat, grep, dd, chown, touch, sync, base64, date, env… Not quite, because coreutils is actually a single package unlike systemd.
The core systemd is big (IMHO it needs to be in order to provide good service management, and service management is a reasonable thing to include in systemd), but everything you listed are optional components. If your distro bundles them into one package, that’s on them.
Systemd includes many complex things, coreutils includes many simple things. And coreutils are ported to many different OS’es, systemd is linux only. Ask why?
Lets imagine, my linux distro runs with openrc/upstart and I like systemd-journal features. Am I able to run system-journal without any other systemd components running?
It is well known that systemd’s service management is built around cgroups, which is a Linux-only concept for now. Other OSs have their own ways to accomplish similar things, but adapting to that would require huge changes in systemd.
No, the only part of systemd project that doesn’t depend on systemd core is systemd-boot. And there’s also elogind, which is an independent project to lift systemd-logind out of systemd.
But honestly, I don’t see the issue here. You can’t use systemd’s components elsewhere, but your previous complaint was the opposite - that systemd is everywhere, as if you were forced to use networkd, resolved (which pretty much no distro uses AFAIK because it’s way worse than other DNS resolvers), homed, timedated etc. when you use systemd as init.
Also, I have a correction for my previous comment: systemd-journald is not an optional dependency, as it’s used as a fallback if the configured log daemon fails. I’ve only learned after writing that comment.