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?
  • Fryboyter@discuss.tchncs.de
    link
    fedilink
    arrow-up
    13
    arrow-down
    2
    ·
    1 year 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
        link
        fedilink
        arrow-up
        5
        ·
        1 year 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.one
        link
        fedilink
        English
        arrow-up
        1
        ·
        1 year 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.