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
181 points (96.4% liked)
Linux
48224 readers
596 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'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 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.
Slackware uses the sysvinit program, but doesn't have System V-style scripts. Which is somewhat confusing, but sysvinit is a basic init program that will just do whatever
/etc/inittabtells it, so you can write your startup scripts to work however you want.Slackware uses what people tend to call a BSD-style init, but it's nothing like the modern BSDs, nor the older BSDs, not really. If you use Slackware, you'll learn how Slackware's init system works, but that's about it.
Ah my mistake. I'm just generally curious about what distros use an alternative to systemd (not that I have any issues with systemd myself but I like variety).
So I googled what init system Slackware uses and read this page.
http://slackware.com/config/init.php (no https)
They mention several scripts on that page and that's why I thought they use scripts.
But I haven't actually used the Slackware yet. Suppose I should though since I'm interested.
No, you're right that it has scripts, they're just not the scripts used by SysV-style init systems. They have different names, are in different locations, and are executed differently.
I used Slackware for several years back in the 90s, and from that experience I'd recommend against learning it. I mean, with VMs today it's simple to try new distributions, so go for it, but I'd put it waaaaay down the list of distributions/operating systems to try. If you have anything else you're interested, put it first. Slackware is standard Linux so there's nothing really special you'd find when using it, and it's just a painful experience in general. I think some people will argue that it helps you "really learn Linux", but I don't think so. It just helps you learn Slackware's idiosyncrasies, and learning pretty much any other distribution would be more beneficial than that.
Slackware has advanced from when I used it in the 90s, but only barely (they have a network-based package manager now, I guess, although it proudly avoids dependency resolution!)
Oof that stance on dependency resolution is a big no for me. As much as I hated building gnome from source it was amazing that Gentoo can do that in a single command.