this post was submitted on 04 Oct 2023
727 points (95.3% liked)
linuxmemes
20880 readers
7 users here now
I use Arch btw
Sister communities:
- LemmyMemes: Memes
- LemmyShitpost: Anything and everything goes.
- RISA: Star Trek memes and shitposts
Community rules
- Follow the site-wide rules and code of conduct
- Be civil
- Post Linux-related content
- No recent reposts
Please report posts and comments that break these rules!
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
I find everything so complicated with systemd.
SysV was just intuitive for me and my knowledge. There was just one directory with all the startup scripts in it. And they were run in their alphanumerical ordner. Just that simple. If I wanted to change the order in which the scripts started, I just had to rename the file. You don't want a script to run at all? Just remove it.
I assume, systemd has many advantages for a knowledged user. But for me, it still is just a hassle.
I haven't had to debug a bash script since systemd became a thing, so I have a vastly different experience from you.
Never really, because they don't contain logic. You craft a command line and stuff works.
The problem with sysv was that almost all of the logic lived in the scripts. They all worked slightly different and all the duplication introduced bugs. Systemd has APIs that take over all the duplicated stuff and implement it once. Bugs have to get fixed once only.
And what happened if one of those scripts failed?
How did your express a dependency of a service on data being mounted?
Did you ever have to face debugging failing networking via scripts?
I just debuged it like every other of my scripts that failed. Again, I didn't need any special knowledge of the init process, just general (and for me: very limited) knowledge.
The answer to your other questions: I don't thing I ever did that.
I think the main difference is that one option is easier for the end user to occasionally take a look at what's happening and debug without needing much context or previous knowledge, while the other is much easier for the actual maintainer to actually keep the thing working properly and predictably, as well as supporting every sort of edge case for their users in advance.
An exaggerated stupid analogy: "back in the day we had horse carts and if it wasn't moving we could just look at the tires to check if they were stuck in a hole or blocked by some rock, but now with cars there are so many things going on that the tires depend on some internal parts that are connected to an engine that depend on some fuel and there are so many elements that can go wrong in-between that often if the car is not moving it requires someone with very specific expertise to diagnose"
(analogy is extra stupid because the horse cart is by nature inferior to the car and this is not the case with the init files and systemd, analogy would work better if the cart still had engines and fuel but that operated with the same simplify as the carts tires).