Ranting, especially on work made by the community* is bad, i know but my frustration comes because it has not be like that. systemd is bloat, madness …

Linux has improved on so many front, is better than ever but this pile of crap is threatening everything.

*systemd is IBM, so not really community, so it’s fine :)

  • mholiv@lemmy.world
    link
    fedilink
    English
    arrow-up
    50
    arrow-down
    1
    ·
    1 year ago

    I disagree. SystemD was and is leagues better than what came before. Now days you just write a simple unit file and your application will startup automatically with systemd managing the start, restarts and stops. It even handles the logs so you can just write out to std and not worry about log rotation and the like.

    Before systemD all applications had to write stupid distro specific SysVInit scripts that handled all of that. People who don’t like SystemD can go back to their slow non parallelized boot times and 500 line distro specific launch scripts but I prefer speedy boot times with 20 line unit files.

    SystemD is a major improvement over what came before.

    • fartsparkles@sh.itjust.works
      link
      fedilink
      arrow-up
      14
      arrow-down
      1
      ·
      edit-2
      1 year ago

      Preach. SystemD and the soft reboot of user space is a game changer for server admins as full reboots are only needed for kernel upgrades.

      I do not miss init one bit!

      Initialisation instructions written in shell script was hell to audit and threat actors’ playground - systemd gave us easy to eyeball configs instead. Awfully written, hundreds of lines long init scripts spread across multiple directories vs simple units with a few lines (most of which are incredibly short and simple). Heaven.

      Got a daemon that takes a long time to spin up? Best go grab a coffee while the server takes 15min to reboot - thanks init. Then systemd comes along and let’s you set a units dependencies so you can ensure the bare minimum needed to be running before your unit can start, simultaneously running other units in parallel… chefkiss.

      • biscuits@lemmy.sdfeu.org
        link
        fedilink
        arrow-up
        4
        arrow-down
        1
        ·
        1 year ago

        It really depends what other init system you mean, but openrc checks all the boxes. It uses shell scripts, but I’ve never seen any that would be 500 lines long (at least in Alpine). Services can have defined dependencies as well can be classified into groups so you don’t need to configure for any specific service, you can just say ‘depend on dns’ and any available will be run. And openrc also supports running services in parallel.

        • fartsparkles@sh.itjust.works
          link
          fedilink
          arrow-up
          5
          arrow-down
          1
          ·
          1 year ago

          Alpine is incredibly minimal given its extensive use for containers so I doubt it’d have many services out of the box.

          When I say init I mean the original init - sysvinit (I’m old so that’s been called init since the dawn of time).

          OpenRC is fine. It still depends on init, parallelism is optional and not standard, and still uses shell scripts (genuinely a bad idea in modern days / I’ve worked incident response and seen how admins never spot a sneaky reverse shell dropped into a init script they don’t understand).

          I happily use OpenRC on a daily basis across loads of Docker containers - it’s a great tool in the right hands and super for minimal environments with a single purpose - but for desktops, workstations, hypervisors, or multi-service servers, SystemD really does solve the huge issue of scripts instead of config, dependency hell, and ultimately the problem of handling a lot of low level stuff which most users aren’t suited to handle, troubleshoot, or investigate, especially when things go wrong or threat actors have compromised the system.

          Another benefit is, with upstream handling unit config, it’s so much easier to hop distro now and have some consistency with services and networking than what it was like when there was a different philosophy from every distro on things like leasing from DHCP… Saves a lot of time during DFIR.

      • Shdwdrgn@mander.xyz
        link
        fedilink
        English
        arrow-up
        3
        arrow-down
        1
        ·
        1 year ago

        SystemD was supposed to improve load times? Hmm. The only time I ever compared it was on a raspberry pi. 15 seconds to boot under sysV. 90 seconds to boot under systemD. I wasn’t impressed. However on my servers… well I honestly don’t see any difference at all in the boot times, so I never understood all the hype.

        • fartsparkles@sh.itjust.works
          link
          fedilink
          arrow-up
          3
          arrow-down
          1
          ·
          1 year ago

          Sounds more likely to be your distro than the init system. You’ve probably got a load of junk units, optional units running for no reason, etc.

          Unless you’re getting your hands dirty configuring each initialisation system by hand, it’s not a fair comparison.

  • _cnt0@lemmy.villa-straylight.social
    link
    fedilink
    arrow-up
    45
    arrow-down
    1
    ·
    1 year ago

    As someone who has used linux for >25 years and has experienced the madness of SysV init scripts for decades (well, only two, but the plural is still technically correct; the best kind of correct), I have a very hard time to take people who make posts like these serious.

    • Papamousse@beehaw.org
      link
      fedilink
      arrow-up
      2
      ·
      1 year ago

      I’m like you, good old init in the 90s on Linux or BSD , we had init, inetd, and like 10 process, no X, it was cool and easy. Init and rc started becoming bloated and complicated sometimes. I don’t hate systemd, it does its thing right, I used Ubuntu for years and systemd without issue. Now I’m using MX that supports both, best of both world.

    • ガブリエル@lemmy.one
      link
      fedilink
      arrow-up
      2
      ·
      1 year ago

      Ok but nowadays there are alternatives to systemd (OpenRC, runit). Not necessarily better, just alternatives. No SysV init involved.

  • donio@lemmy.world
    link
    fedilink
    arrow-up
    15
    ·
    1 year ago

    The post would have been more interesting if you gave some details on what exactly broke, how you fixed it, relevant bugs etc.

  • 20gramsWrench@lemmy.dbzer0.com
    link
    fedilink
    English
    arrow-up
    12
    arrow-down
    1
    ·
    edit-2
    1 year ago

    how dare you criticize smystemD, I spent 20 years having to write startup scripts in assembly with a quill and feather and i can tell you that sistem_d is literally life changing, I stopped drinking an got out of prison ever since arch implemented it

    • Shdwdrgn@mander.xyz
      link
      fedilink
      English
      arrow-up
      4
      arrow-down
      2
      ·
      1 year ago

      Get out of the dark ages, real geeks use mechanical pencils! 😆

      SystemD is life-changing all right, just not in a good way. I keep fighting with it though because I really like Debian.

      • notabot@lemm.ee
        link
        fedilink
        arrow-up
        1
        ·
        1 year ago

        Debian will happily use sysvinit. It’s easiest to just switch to it at install time, but you can do afterwards too: Init

        I’ve veen using it on desktops, laptops and servers without issue.

        The more people who switch, the clearer the message that this choice needs to be maintained.

        • Shdwdrgn@mander.xyz
          link
          fedilink
          English
          arrow-up
          1
          ·
          1 year ago

          I’ve used that before but generally just go with direct installations now instead of fighting it. However I have to wonder, if this is still a thing that actually works correctly in Debian, then why is Devuan a thing? There must be a difference in maintenance between them to justify the labor?

          • notabot@lemm.ee
            link
            fedilink
            arrow-up
            1
            ·
            1 year ago

            I think Devuan split when it was still uncertain whether Debian would have init freedom. I’m running Xfce4, but I believe there were issues with Gnome being tightly tied to SystemD on Debian. It looks like that’s improving, but that Devuan has it all working. I guess the other issue is that Debian still don’t guarantee init freedom, whereas Devuan does.

            • Shdwdrgn@mander.xyz
              link
              fedilink
              English
              arrow-up
              1
              ·
              1 year ago

              It’s such a weird state of things. It seems like if the debian devs weren’t so bone-headed they would just accept that here are some people (some who are previous debian devs themselves) willing to put forth the effort to allow people to have a choice. Debian itself would thrive from the additional choices but instead they seem to want to dictate to everyone else what path is right for them, and that sounds an awful lot like the Ubuntu way.

              • notabot@lemm.ee
                link
                fedilink
                arrow-up
                1
                ·
                1 year ago

                Oh absolutely. I resent SystemD more for the damage it did to the community than the boneheaded design decisions and buggy code.

                The ridiculous part is that the Debian devs are putting in some effort to keep multiple init systems working, they’re just not talking about it. As you say, people knowing about it would help Debian thrive.

                • Shdwdrgn@mander.xyz
                  link
                  fedilink
                  English
                  arrow-up
                  2
                  ·
                  1 year ago

                  At this point I don’t think it really matter who thinks which system is better. The technical aspects are irrelevant as long as they work in a manner that completes the tasks. I certainly find no difference in boot times between systems that were loaded up with older releases pre-systemD, and systems that were freshly installed with systemD as the only init. Oddly I DID find one hell of a difference on a raspberry pi when I installed raspbian with systemD and it took nearly a minute and a half to boot, then I converted it to sysV and it booted in 15 seconds. These days most of the boot times I pay attention to, however, are on bare-metal servers which are now taking five freaking minutes just to get up to grub, so the difference of a minute is OS boot time is now completely meaningless.

  • Quazatron@lemmy.world
    link
    fedilink
    arrow-up
    9
    arrow-down
    1
    ·
    1 year ago

    SystemD is different and it takes a while to get used to. But it is much better than the collection of bash scripts it replaced.

    This is open source, one is at liberty to replace it if one does not like it.

  • BestBouclettes
    link
    fedilink
    arrow-up
    5
    arrow-down
    1
    ·
    edit-2
    1 year ago

    You can criticise SystemD for a bunch of things but that shit fucking works like a charm and removes so much of the pain managing your init system. The journaling, the parallel unit startup, the timers, the unit files are so much easier to manage now that it used to be.

    • notabot@lemm.ee
      link
      fedilink
      arrow-up
      2
      ·
      1 year ago

      I’ve had more problems with SystemD bugs than I’ve ever had with other init systems (and I’ve used a few). The worst part is that it’s such a tangled mess that tries to take over everything whuch makes it difficult to isolate and remove the broken part. That, and so much of the design of it is just ridiculous that making it do what’s needed when you need anything but the most basic setup is painful. I’ve had all sorts of issues, but one of the recent ones that really bit me was the automounter. It turns out that if it hits certain issues it’ll just return the empty mount point, rather than preventing access when the filesystem isn’t there.