SystemD is blamed for long boot times and being heavy and bloated on resources. I tried OpenRC and Runit on real hardware (Ryzen 5000-series laptop) for week each and saw only 1 second faster boot time.

I’m old enough to remember plymouth.service (graphical image) being the most slowest service on boot in Ubuntu 16.04 and 18.04. But I don’t see that as an issue anymore. I don’t have a graphical systemD boot on my Arch but I installed Fedora Sericea and it actually boots faster than my Arch despite the plymouth (or whatever they call it nowadays).

My 2 questions:

  1. Is the current SystemD rant derived from years ago (while they’ve improved a lot)?
  2. Should Linux community rant about bigger problems such as Wayland related things not ready for current needs of normies?
  • eleitl
    67·
    2 years ago

    The problem of systemd is that it hasn’t been just a replacement of init as they initially claimed, and now deny they ever did. Things like Mono, Gnome and systemd are bad for the ecosystem long term.

    An init done by constructive people wouldn’t be a problem at all.

    • Fryboyter@discuss.tchncs.de
      132·
      2 years ago

      The problem of systemd is that it hasn’t been just a replacement of init as they initially claimed

      Apart from the PID 1 part of systemd, almost all tools are optional.

      Although I have a positive opinion about the systemd project, I used netctl instead of systemd-networkd for a long time without any problems. And even today I don’t use systemd-resolved because I use a combination of unbound and Pi-Hole in my private LAN. And so on.

      So you can’t say that the systemd project has replaced various solutions in such a way that you don’t have a choice anymore.

        • taladar@sh.itjust.works
          5·
          2 years ago

          Honestly, that looks like a fairly short list and half of the tools interact closely with useful functionality that didn’t even exist at all before systemd came around.

        • IDe@lemmy.oneEnglish
          1·
          2 years ago

          That’s not an issue with systemd however? At best it’s an issue with certain other packages depending on systemd. But what software a project depends on is completely at the discretion of said project/devs. They have no obligation to provide loose coupling there if they don’t see it as worth it.