In reference to: https://lemmy.world/post/23862757
I use Void btw
Image text:
Most people rejected his message.
“Systemd is Satan’s creation! Pure Evil!”
They hated Talking Pig because He told them the truth.
In reference to: https://lemmy.world/post/23862757
I use Void btw
Image text:
Most people rejected his message.
“Systemd is Satan’s creation! Pure Evil!”
They hated Talking Pig because He told them the truth.
It’s because you now need to do
systemctl restart sshd
instead of/etc/init.d/sshd restart
, I see no other reason than having to learn new syntax.Arguably, init.d scripts were easier to understand, and systemd is a bit of a black box, it somehow works, but who knows where it writes logs or saves the process pid (it’s all in the documentation somewhere), with init.d script you can just open the script itself and look.
I think it’s okay to not 100% know every little detail of how a system works, as long as it’s possible to find out what you need when you need it.
This post was sponsord by the Backdoor Buddies
I prefer the ini files systemd uses to bash scripts
Systemd syntax is not that hard if you read the manual. I think every hardcode Linux user hates systemd because it automatically does the thinkering for you and you can control your processes with simple commands
Yeah, the manpages for systemd are large but also informative. Most of us only use a small subset of the features—much like we never explored everything possible with separate init programs.
Having used Linux on the desktop for some two decades and worked as a Linux sysadmin for a good while I don’t miss the init scripts. My impression is more that a certain cohort wants to pretend that service management is easy by ignoring large amounts of it. It’s easy to write a bad init script that breaks when you really need it, or be out of your depth with more complex cases.
Not to mention the whole conformity by convention thing. Systemd unit files are descriptive and predictable by their nature. So-called init scripts didn’t really have to be scripts, they just usually were, and their arguments and output and behaviour was also unenforced—there’s nothing really stopping you from writing a compiled program that self-daemonizes and place the binary with the init scripts rather than in /bin. Ultimately people who make programs also have to be good at writing init programs with that setup.
So we’d have people doing dumb shit themselves and getting angry at others doing dumb shit. PHP was also pretty popular and full of dumb shit. Lots of “worse is better” to go around.
Ultimately it’s more of the stuff covered in Bryan Cantrill’s Platform as a reflection of values. Some of us value predictability and correctness, others feel it’s a straitjacket. There’s no way of pleasing everyone with the same platform.
And currently the people who want to distribute their own riced-out init programs in bash, perl, php, node.js and so on are SOL. (They can still use them on their own machines.)
The more I actually learn about systemd, the cooler it is.
For example, you can automatically mount SMB shares using systemd, with automatic remount on failures. It’s far superior to using fstab once you know how.
https://anteru.net/blog/2019/automatic-mounts-using-systemd/
Don’t minimize those strengths. Init.d scripts are something you can figure out just knowing a bit of shell script, or historical knowledge from before there was an internet. For something I rarely use, why do I need to learn something more complex to do the same thing - I either haven’t been sold on all the new functionality they piled in or do not need it. After all these years crowing about the Unix/linux way being many independent flexible tools that can work together, why do we now have this all-in-one monstrosity that might as well have come directly from Microsoft?