this post was submitted on 07 Mar 2024
487 points (96.9% liked)
linuxmemes
20880 readers
8 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
init.d wasn't really what you'd call an "init" "system." It was shell + conventions about how to write shell scripts to manage each service. It effectively offloaded most of the work people wanted an init system/service supervisor to do onto developers that just needed to ship a system service. To be honest, it was insane. Templates/patterns/best practices emerged, but at the end of the day, init.d was just shell, and it caused tons of problems.
The extra complexity of systemd is in exchange for dependency management, service supervision, tons of things that are important/desirable for sysadmins/developers today, but are all far outside the scope of init. I'd much rather cope with the extra complexity of systemd in exchange for being able to write an actual service definition file.