• YaBoyMax@programming.devEnglish
    21·
    1 day ago

    This is by far the most nuanced critique of systemd I’ve ever seen. I don’t fully agree with its conclusions personally, but I think it makes a lot of good and valid points about its architecture and its flaws. It feels like such a breath for fresh air in comparison to the most vocal anti-systemd types who vaguely and angrily gesture at “scope creep” and refuse to elaborate further.

    • atzanteol@sh.itjust.worksEnglish
      91·
      1 day ago

      This is by far the most nuanced critique of systemd I’ve ever seen.

      It’s the same bullshit everyone has always bitched about.

      • YaBoyMax@programming.devEnglish
        4·
        1 day ago

        Loosely yes, but I rarely see anyone expound on it beyond “It’s bloated and therefore bad”. I also rarely see specific criticisms outside of that like journalctl being slow or using a binary format for log files.

        • atzanteol@sh.itjust.worksEnglish
          115·
          1 day ago

          90% of his argument is just “UnIx PhIlOsOpHy” though. Or arguments (term used loosely) that are based on that. He keeps chanting “But systemd Is MoNoLiThIc” over and over as if that ended the discussion while handwaving away the same argument against Linux or Wayland. But somehow systemd is different. Systemd needs to be crap for some reason.

          It turns out that system boot benefits from tightly integrated steps. Filesystem mounting can depend on network availability for example. Logging depends on filesystems to be mounted. The sub-systems are naturally inter-dependent. And service management and execution needs to know about all those things. Some services need networking, some need file systems, etc.

          You match the design to the problem. You don’t pretend like the Unix Philosophy is some gold standard that everything must adhere to.

          • Ferk@lemmy.ml
            3·
            7 hours ago

            handwaving away the same argument against Linux or Wayland

            Honestly, I would be happy if there was a mature implementation that was practical to use and was more modular for these too. I’d argue Wayland is much better than X11 in this respect, since the Wayland protocol is much more minimalistic in its design, so I think a big reason why X was superseded was the need for removing things that had been needlessly integrated in the X server and added technical debt.

            If there had been usable and working alternatives that were less monolithic at the time those were launched, and people were actually using them but had to switch due to the pressure of other bigger projects… then I’m sure there would have been criticisms too.

            Imagine if someone came and proposed “graphicd”, a service that combines not just compositor & display manager but also management of priviledges (like polkit), GUI toolkit (like a Gtk/Qt replacement), password manager, terminal emulator, filebrowser, web-browser and any program that might benefit from tight integration with the GUI environment. And it used protocols and methods that are entirely incompatible with Gnome, KDE or other more modular desktop environments, but the API/ABI is so big and fast moving that it’s very hard for alternative apps to integrate well with the core of graphicd (the external API on the components is stable, but not the API between the components and the core). Then it started becoming the default everywhere, with some programs adding its specific components (and along with them, the graphicd core) as a dependency.

            Filesystem mounting can depend on network availability for example

            This is one of my pet peeves with systemd… I’ve multiple times tried to use mount units (the “systemd-native” way) but I often have always ended up just relying on either the older /etc/fstab configuration conventions or layers like gvfs and custom scripts (through the init.d-like rc.local compatibility service…) because when writting systemd units to mount conditionally remote drives that might or might not be available they sometimes (not even reproducibly) led to problems in one way or another (like sometimes slowing down my boot or even my shutdown).

            The issue is that systemd is considerably more opaque and complex… so it’s hard to tell whether something is a bug in the software, an intentional behavior / quirk, something specific to particular circumstances/cases or an issue in your configuration.

            And I’m not saying all of what systemd did is bad, it has advantages… but acting as if it doesn’t have problems that could be smoothed out with a different approach would not be right either… it’s not like it’s impossible to do what you are stating in a modular way, for a long time before systemd was a thing we had syslog implementations (like rsyslog) that handled structured, secure remote logging across networks without needing a monolithic init system to dictate how logging architecture should work.