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?
  • nitrolife@rekabu.ru
    link
    fedilink
    arrow-up
    1
    ·
    edit-2
    1 year ago

    I don’t deny that systemd is easier than SysV. I say that on complex configurations it is not slightly simpler. Moreover, what I could do just in the sysV script, I now have to divide by tmpfiles.d and systemd. And sometimes even include processing both there and there, because depending on the version systemd has different behavior with parameters LogsDirectory= and RuntimeDirectory=. As a result, the dependence on the system has not completely disappeared for the package maintainer. Although of course there are a little less problems with systemd.

    On other side as a user, I don’t really like to guess exactly how a folder was created in /run, via tmpfiles or via systemd.

    UPD: On SysV I have one complex, heavy script. Now I have the systemd service, the tmpfiles configuration, the /etc/conf parameters file.d and there is still a shell script to run. But if user wants reconfig something he need look 4 files instead one.