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?
  • 0x0@programming.devEnglish
    1·
    1 year ago

    The traditional init systems suited me just fine, i saw no need to change them. If they were so bad, then they could’ve been fixed or replaced.

    The migration to systemd felt forced. Debian surprised everyone with the change. Also systemd’s development is/was backed by corporate Red Hat, their lead developer wasn’t exactly loved either and is now working for Microsoft. Of course Canonical’s Ubuntu adopted it as well. Overall feels like Windows’ svchost.exe, hence people accusing it of vendor lock-in.

    It’s not just an init system, it’s way waaay more. It’s supposed to be modular, but good luck keeping only its PID1 in a distro that supports systemd. It breaks the “do one thing right” approach and, in practice, does take away choice which pisses me off.

    I had been using Debian since Woody, but that make me change to Gentoo on my desktop which, to me, took the best path: they default to OpenRC but you’re free to use systemd if you want to. That’s choice. For servers i now prefer Slackware and the laptop runs Devuan whenever i boot it up.

    To be fair systemd hasn’t shown its ugly face in the Ubuntu VMs i’m forced to use at work.

    YMMV. If you’re happy with it, fine. This, of course, is only my opinion.

  • monobot@lemmy.ml
    1·
    1 year ago

    Keep in mind that it all started 20 years ago with Pulseaudio. Pottering was not really a nice guy (on mailing lists ofc, I don’t know him personally) whose software I wanted on my machine.

    Problem was never speed or even technical, problem was trust on original author and single-mindedness that they were promoting. Acting like it is the only way forward, so anyone believing in freedom part of free software was against it. Additionally, it was looking like tactics used by proprietary software companies to diminish competition.

    It looked scary to some of us, and it still does, even worse is that other software started having it as hard dependency.

    All of this looks like it was pushed from one place: Portering and RedHat.

    While after 20 years I might have gotten a bit softer, you can imagine that 15 years ago some agresive and arogant guy who had quite a bad habbit of writing (IMHO) stupid opinions wanted to take over my init system… no, I will not let him, not for technical reasons but for principal.

    I want solutions to come from community and nice people, even if they are inferior, I will not have pottering’s code on my machine so no systemd and no pulseaudio for me, thank you, and for me it is an important choice to have.

  • eleitl@lemmy.ml
    0·
    1 year 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
      0·
      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.

  • nyan@lemmy.cafeEnglish
    0·
    1 year ago

    Speaking as someone who uses OpenRC on all my machines . . . no, systemd is not necessarily slow, and personally I don’t care about the speed of my init system anyway. Thing is, systemd also has nothing that makes it more useful to me than OpenRC, so I have no incentive to change. Plus, I dislike the philosophy behind it, the bloat, and the obnoxious behaviour the project showed when interacting with others in its early days. I’m a splitter, not a lumper, and systemd’s attempts to absorb All The Things strike me as rather . . . Windows-like.

    So, in a technical sense I have no reason to believe that systemd is inferior to OpenRC + sysv, and it may be superior for some use cases which are not mine. I don’t spend a lot of time ranting about it, and I see no point in trying to convince people not to use it if it fits their needs. But I still won’t use it if I have another option.

    • chaorace@lemmy.sdf.orgEnglish
      01·
      1 year ago

      I agree. SystemD is a great service daemon (or, sigh, unit daemon in the stupid parlance). I like unit file syntax and I like the ergonomics of systemctl. It’s solid and I appreciate the feeling of consistency that systemd lends to the otherwise chaotic landscape of Linux distrobutions.

      It’s for this reason that I’m willing to forgive SystemD overstepping the boundaries of services somewhat. System init/mounting? Sure, that’s a blurry line after all. Logging? Okay – it does make sense to provide a single reliable solution if the alternative is dealing with dozens of different implementations. Network resolution & session management? Fine, I’ll begrudgingly accept that it’s convenient to be able to treat logins/networking as psuedo-services for the sake of dependencies.

      If that’s as far as the scope crept, SystemD and I would be cool, but the so-called “component” list just keeps on going. SystemD has no business being a boot manager, nor a credential manager, nor a user manager, nor a container manager, nor an NTP client. I understand why they can’t deprecate most of this junk, but why can’t they just at least make this cruft optional to install?

  • digdilem@feddit.uk
    0·
    1 year ago

    Nah, it’s fine. Boot times are considerably faster than sys.v in most cases, and it has a huge amount of functionality. Most people I work with have adopted it and much prefer it to the old init.d and sys.v systems.

    People’s problem with systemd (and there are fewer people strongly against it than before) seem to break down into two groups:

    1. They were happy with sys.v and didn’t like change. Some were unhappy with how distros adopted it. (The debian wars in particular were really quite vicious)

    2. It does too much. systemd is modular, but even so does break one of the core linux tenets - “do one thing well”. Despite the modularity, it’s easy to see it as monolithic.

    But regardless of feelings, systemd has achieved what it set out to do and is the defacto choice for the vast majority of distros, and they adopted it because it’s better. Nobody really cares if a user tries to make a point by not using it any more, they’re just isolating themselves. The battle was fought and systemd won it.

    • jarfil@lemmy.ml
      1·
      1 year ago

      “do one thing well”

      Arguably, Systemd does exactly that: orchestrate the parallel starting of services, and do it well.

      The problem with init.d and sys.v is they were not designed for multi-core systems where multiple services can start at once, and had no concept of which service depended on which, other than a lineal “this before that”. Over the years, they got extended with very dirty hacks and tons of support functions that were not consistent between distributions, and still barely functional.

      Systemd cleaned all of that up, added parallel starting taking into account service dependencies, which meant adding an enhanced journaling system to pull status responses from multiple services at once, same for pulling device updates, and security and isolation configs.

      It’s really the minimum that can be done (well) for a parallel start system.