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?
  • addie@feddit.uk
    link
    fedilink
    arrow-up
    17
    ·
    1 year ago

    It’s a massive question, and I think quite a lot of the argument comes from the fact that it depends what direction you’re answering it from.

    As a user, do I like being able to just systemctl enable --now whatever.service , and have a nice overview of ‘how’s my computer’ in systemctl status ? Yes, that’s a big step up from symlinking run levels and other nonsense, much easier.

    As an administrator, do I like having services, mounts and timers all managed in one way? Yes, that is very nice - can do more with less, and have to spend less time hunting for where things are configured. Do I think that the configuration files for these are a fucking mess of ‘just keep adding new features in’ and the override system is lunacy? Also yes.

    As a developer trying to do post-mortem debugging, who just wants all the logs in front of him for some server that’s gone wrong somehow, which I often have to request via an insane daisy-chain of emails and ‘Salesforce nonsense that our tech support use’ from our often fairly non-technical end users, on some server that I’ve no other access to? No, I do not find having logs spread between /var/log and journalctl (and various CloudFormation logs in a web console) makes my life easier. I would be pleased if that got sorted out.

    tl:dr; mostly an improvement, some caveats.

    • nottheengineer@feddit.de
      link
      fedilink
      arrow-up
      4
      ·
      edit-2
      1 year ago

      As someone who recently started learning linux properly by setting up arch, systemd is nice. It does a lot of things that make life easier for me and it never gets in the way.

      Edit: Please disregard, this should be a top level comment.

        • nottheengineer@feddit.de
          link
          fedilink
          arrow-up
          1
          ·
          1 year ago

          Because it was intended to be a top level comment and I only noticed that I wasn’t commenting on top level after posting it.

          Did the deletion of this one not get through to your instance yet?

          • Vilian@lemmy.ca
            link
            fedilink
            arrow-up
            1
            ·
            1 year ago

            oh, lol, it’s fine

            Did the deletion of this one not get through to your instance yet?

            probably

            • nottheengineer@feddit.de
              link
              fedilink
              arrow-up
              1
              ·
              1 year ago

              Alright, I thought I was quick enough but deletion seems to work differently in the federation. I restored the comment and added an edit, that should avoid confusion once everything is synced properly.

    • NuuskisOP
      link
      fedilink
      arrow-up
      2
      ·
      1 year ago

      I didn’t know that logging question is related to SystemD, so thanks for telling it! As an non-top class desktop user the same thing frustrates especially because the solution is often simpler and not found from those logs.

    • jarfil@lemmy.ml
      link
      fedilink
      arrow-up
      1
      ·
      1 year ago

      What do you see wrong with the config override system? I find it an improvement over having to diff between new and current config files, then having to figure out which part of which to keep.