• acockworkorange@mander.xyz
        link
        fedilink
        arrow-up
        11
        ·
        edit-2
        2 days ago

        Great talk indeed. And I will quickly acknowledge that something had to be done, and that systemd had the courage to innovate and address the issues. I just wish it did so in a more transparent way to the end user.

        For instance: there’s a whole established system of dealing with logs in place. Why build a separate one just for your init system? Why binary? Why even integrate it with your init? I’m not saying storing everything on /var/log and using logrotate is ideal or even covers all use cases. But a log management system is its own thing.

        That’s just an example of how systemd didn’t jive with every other subsystem in a Unix like OS. It could have been done in a Unix way - small cohesive tools that are good at one job and can be combined to do more together.

        That’s where I think he missed the mark when dismissing the monolithic criticism by saying “it’s not a single binary so it’s not monolithic”. Its philosophy is monolithic.

        That said, I use systemd on my machines because that’s what my do uses and I don’t think it’s a reason to swap distros. For the same reason I use Linux and not a micro kernel. I.e. philosophy is important, but implementation is importanter.

        • BCsven@lemmy.ca
          link
          fedilink
          arrow-up
          5
          ·
          2 days ago

          While monolithic may not be the keep is simple rule aimed for in originally in Unix/Linux, I wonder if it even matters…is there something really gained by init systems that make a difference for the average Linux user?

    • silasmariner@programming.dev
      link
      fedilink
      arrow-up
      5
      ·
      2 days ago

      One task lifecycle management tool to bring them all, one tool to find them. One tool to rule them all and in the darkness bind them.