this post was submitted on 07 Mar 2024
485 points (96.5% liked)

linuxmemes

21198 readers
269 users here now

Hint: :q!


Sister communities:


Community rules (click to expand)

1. Follow the site-wide rules

2. Be civil
  • Understand the difference between a joke and an insult.
  • Do not harrass or attack members of the community for any reason.
  • Leave remarks of "peasantry" to the PCMR community. If you dislike an OS/service/application, attack the thing you dislike, not the individuals who use it. Some people may not have a choice.
  • Bigotry will not be tolerated.
  • These rules are somewhat loosened when the subject is a public figure. Still, do not attack their person or incite harrassment.
  • 3. Post Linux-related content
  • Including Unix and BSD.
  • Non-Linux content is acceptable as long as it makes a reference to Linux. For example, the poorly made mockery of sudo in Windows.
  • No porn. Even if you watch it on a Linux machine.
  • 4. No recent reposts
  • Everybody uses Arch btw, can't quit Vim, and wants to interject for a moment. You can stop now.

  • 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
    [–] [email protected] 13 points 8 months ago* (last edited 8 months ago)

    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.