Hi am noob why systemd bad? I use Debian, is fucked?
Honestly I’ve been hearing about this for a while now but never bothered to check, I’m too lazy for that.
It’s not inherently bad, it “fails” the Unix Philosophy of “Do one thing and do it well” but since Linux’s kernel is:
- Unix-like, not Unix
- Fails this philosophy, as it does more than one thing but does all of it pretty well
- systemd is just a bundle of tools that do one thing and do it well under one package, like Linux’s kernel
It used to be a mess, but that’s solved. The biggest reason to avoid systemd is mainly user preference, not anything malicious. 90% of current distros use systemd as its easier for the maintainers and package programmers to build for the general than each package and each distro having their own methods of how to do an init system and other tasks.
How Debian and Arch and Gentoo and Slackware and other big distros worked was different, and the maintainers of those packages had to know “Debian’s way” and not a general way that most places accept. Systemd actually solved the Too Many Standards! issue.
I’ve never really seen a big argument against systemd, but maybe I’ve just not heard it.
back when you had an init system and you got it just the way you wanted it, you would be pissed that you had to move to systemd
now its there when you install and it is stable so it isn’t a big deal. But old beards hate change.
I’ve been a Unix admin for almost 30 years.
Systemd really is shitty, and Poettering is a serious asshole; but that ship has sailed. It’s time to accept that computers only get worse, and move on.
Person: Systemd bad
Me: why
Them: IDK
The argument is basically that it does too much and as the motto of Unix was basically “make it do 1 thing and that very well”, systemd goes against that idea.
You might think it is silly because what is the issue with it doing many things. Arguably, it harms customization and adaptability, as you can’t run only 2/3 of systemd with 1/3 being replaced with that super specific optimisation for your specific use case. Additional, again arguably, it apparently makes it harder to make it secure as it has a bigger attack surface.
I mean I’ve briefly tried some of the modern distros that go without systemd recently, and honestly they just felt like I went back in time except they weren’t even the same as then so I had no idea what I was doing without reading documentation that is imo much worse than the arch wiki.
And as a bonus fuck man pages as I can’t in a pleasant way put them into my 1000s of categorized browser tabs for research and topic switching while being able to return without starting over.
What else besides running services can system.d do?
TL;DR init system, services, sockets, slices, logs, boots, VM’s, containers… and that’s fantastic, for monolithic systems. journalctl go brrrr
Strap in, folks. Old timer with a gavel to slam.
When systemd is unfolded in full, people are sort of apt when they jokingly say “-Linux, or what I’d like to call gnu/systemd/Linux”. Some scream at the top of their lungs, yearning back to rc.0 days, “when everything was much simpler”… this is where the gavel comes down. There are so many improvements they are hard to list and if you asked me if I could go back, only with modern software, I would say nay… and here’s why:
Running services is a whole mess more than just running background apps, and it’s intrinsically intertwined with what is known as the init system - no matter what some people may think. Init is the process of initializing (or bootstrapping) an operating system, and services are background services, but both are about managing the processes within the Linux stack - or the thread. Some say that systemd is doing more than it should, but systemd is not “crossing streams” when both init processes and services need to be managed in concert depending upon the way a system inits - because there’s more than one way to init.
systemd manages init through scopes, slices and services, which combined create the hierarchy of processes used to bootstrap a system, get things up and running, with their relative permissions, in a given state, to facilitate a running and functioning system. Socket units handle socket files or destinations, and timer units handle event driven processes.
It all comes together into a dependency chain that defines your running system, which is testable and manageable from a set of tools. systemctl is used to manage a running system, and I think it does a great job of it. Imagine fail testing a bunch of non-standardised, random rc bash script files that aren’t distro agnostic, along with whatever daemon runner you were using. It was a mess, and systemd sought to fix that - which imho it has. We view a booted Linux system and it’s process tree much differently through the systemd lens, which gives us a newfound focus that helps us better manage a running system.
Also, logs are binary now… you’re all so spoiled and you don’t even know it. Do you remember 20GB txt files you absolutely had to open? Pepperidge farm remembers. Which brings us journalctl, which is just so good. It’s the swizz army knife of Linux logs. You can point it at anything. Specify -k for dmesg, a service using --unit, point to a binary in /usr/bin, select previous boot with -b -1, -f for follow, -e take me to the end of a log. If you haven’t learned how to use this tool, you are running blind. It whips every dang logging system out there. Going from systemd to windows events feels like going from a soft mattress to the inside of an iron maiden.
systemd-boot is blazing fast. Don’t get me wrong, Grub2 is still fantastic as well (Apple seems to think so at least), but considering ease of us - as I often do - I’m inclined to prefer systemd-boot because of bootctl, because like journalctl, it’s a wonderful piece of kit for managing, analyzing and failtesting boot images, provides UEFI functionality and being a sort of one-stop shop for the boot process.
Now we we’re seeing systemd managing VM’s (machinectl) and containers (containerctl), and honestly I’m all for it. Make my life easier. Please. Standardise that mess. And since it is standard, everyone supplies systemd units and because of the nature of systemd and it’s designs, it’s all fail-safed to hell and back. This is good. We want this. At least on the desktop, workstation, even some servers. For containers, embedded, not so much, as they aren’t monolithic systems. That being said, NixOS has proven that systemd isn’t a barrier to entry for new system paradigms either, so I feel those fears were unfounded.
You get the theme here. Systemd is a system management suite, and not just a service runner or init system. It seems to grow and grow out of proportion, but at the end of the day, it’s about getting the system(s) and software up and running, as well as managing those processes and figuring out where problems lie. That’s what systemd does. It’s become part and parcel of a fully monolithic Linux stack, and in my opinion it’s a great project that makes our lives much easier.
To me systemd is zen. It’s the cup of tea Linux always needed, and I’m not ashamed to say so.
