The system V init approach did the job fine for a couple of decades—even if the actual service definitions were a glorified shell switch statement as you insinuate.
Canonical did their upstart thing for a couple of years that wasn’t too bad to use, personally I’m glad they ended up switching to systemd though.
All of them are worse in my experience. In a embedded context I use busybox init and if I need something more I used systemd. Systemd actually has a fairly small footprint. A few years ago I ran it on a system with 32mb of ram.
If you’re writing bash scripts you’re basically replicating a lot of the functionality of systemd
You have that backwards
If you’re writing Systemd profile profile profiles you’re replicating shell scripts but with a lot of spongey unknown “come on, pumpkin” cancer code that you’re only sure will do what you think because you don’t know what suddenly capriciously changed in enterfuckingprize code and boy is your remote server screwed. Fuck me if I need to actually rely on something starting.
No one said sysV is awesome. It’s built to best practice and it does what it does really well, but that’s not a lot. But it does it well. Oh, the days Systemd has ruined trying to work half as well as ; well fuck, every alternative.
The days Systemd doesn’t ruin, it’s the other cancer, network manager and ‘consistent’ naming. And devices that don’t come up. And devices that don’t actually assign a fucking static goddamned address. #youHadOneJob
Spot the parts of enterprise Linux that runs like shit and barely does the same thing twice on two identical adjacent boxes, and I’ll show you some whiz kid who shat out some cancer and went to go work at Microsoft.
So. Anyway, because the reliable stuff came before Systemd’s change-for-lulz setup, you had them in the wrong order unless you have a time machine.
Maybe the arguments against systemd are issues of the past. I see people, hating systemd, bringing the same arguments of it being unstable, or constantly breaking, again and again.
However, I don’t remember actually coming across any of those problems, or discussions about them, for the past 5+ years that I have been using Linux both for my computers and servers.
I have used Ubuntu, Debian, Fedora, Arch, Proxmox, NixOS. All of them use systemd.
They only problem I remember facing with systemd, which is actually never mentioned by anti-systemd people, is about its containers system, nspawn, which enables some security features by default. Those break things that tend to work with LXC without much tweaking. Docker, for example, may face issues running inside nspawn.
Systemd is actually way more reliable than other solutions. Forget things like cron and startup scripts. Systemd can monitor and automatically try to restart software.
I still don’t know what people use to create services other than systemd
If you’re writing bash scripts you’re basically replicating a lot of the functionality of systemd but with larger foot guns
The system V init approach did the job fine for a couple of decades—even if the actual service definitions were a glorified shell switch statement as you insinuate.
Canonical did their upstart thing for a couple of years that wasn’t too bad to use, personally I’m glad they ended up switching to systemd though.
Abaci and mechanical differentiators did the job just fine for a couple centuries.
s6, dinit, openrc, BSD rc, are all alternative init systems with their own method of doing thing
Guix_SD has its own init system, Gnu shepherd
All of them are worse in my experience. In a embedded context I use busybox init and if I need something more I used systemd. Systemd actually has a fairly small footprint. A few years ago I ran it on a system with 32mb of ram.
You have that backwards
If you’re writing Systemd profile profile profiles you’re replicating shell scripts but with a lot of spongey unknown “come on, pumpkin” cancer code that you’re only sure will do what you think because you don’t know what suddenly capriciously changed in enterfuckingprize code and boy is your remote server screwed. Fuck me if I need to actually rely on something starting.
No one said sysV is awesome. It’s built to best practice and it does what it does really well, but that’s not a lot. But it does it well. Oh, the days Systemd has ruined trying to work half as well as ; well fuck, every alternative.
The days Systemd doesn’t ruin, it’s the other cancer, network manager and ‘consistent’ naming. And devices that don’t come up. And devices that don’t actually assign a fucking static goddamned address. #youHadOneJob
Spot the parts of enterprise Linux that runs like shit and barely does the same thing twice on two identical adjacent boxes, and I’ll show you some whiz kid who shat out some cancer and went to go work at Microsoft.
So. Anyway, because the reliable stuff came before Systemd’s change-for-lulz setup, you had them in the wrong order unless you have a time machine.
Very much this, why is systemd entangling itself in every part of the linux kernel, I ripped that mfer network-manager and installed iwd
I’m on guix-sd and don’t have to suffer systemd
Maybe the arguments against systemd are issues of the past. I see people, hating systemd, bringing the same arguments of it being unstable, or constantly breaking, again and again.
However, I don’t remember actually coming across any of those problems, or discussions about them, for the past 5+ years that I have been using Linux both for my computers and servers.
I have used Ubuntu, Debian, Fedora, Arch, Proxmox, NixOS. All of them use systemd.
They only problem I remember facing with systemd, which is actually never mentioned by anti-systemd people, is about its containers system, nspawn, which enables some security features by default. Those break things that tend to work with LXC without much tweaking. Docker, for example, may face issues running inside nspawn.
Systemd is actually way more reliable than other solutions. Forget things like cron and startup scripts. Systemd can monitor and automatically try to restart software.
Systemd hate mostly boils down to hating change
Amen.