1. 20

  2. 5

    Oh boy, Devuan. The gift that keeps on giving. The importance of it is much better summarised here.

    There are many things one can criticize systemd of, but if you assert that a whole bunch of fragile shell scripts were any better, less error prone, or easier to debug, you are so very wrong. There are so many reasons to bash systemd, but saying it is more fragile and harder to debug than the shell scripts is not one of those. If that’s the central part of your rant against systemd, I can’t take it seriously, I’m sorry.

    If you think systemd disabling a service that restarts way too often is bad, you clearly haven’t seen runaway processes that keep crashing, and the constant restarts trashing the system. I had, and I’m glad I have guards that make this easier to avoid.

    1. 4

      I definitely prefer writing unit files than good ol’ sysv init scripts. Openrc init script are slighly better, but still too complex. IMO, systemd took another approach (a declarative one) at writing init script. To me, it just add a new bad solution to the mess init scripts are.

      My issues with systemd is the lockin it brings. Be it on the tools you have to use, the dependencies of your systemd, or even on the actions you can take.

      Yes it’s good to have a service disable itself if it fails to start too often (for example, when httpd fails to bind on an unexisting IP).
      But there is nothing more frustrating than being hopeless trying to start it manually once you’ve fixed the issue.

      Systemd aims to be the smartest init systemd out there, and instead of accomodating itself to different (all being valid!), it enforces its “standard” way.

      For example, I’ve been experimenting with LXC recently. This tech has been there for quite some time now, and even share the same roots (cgroups) as systemd.
      After some testing, and leaving the containers running for a few days, I discovered that the CPU, memory and diskio cgroups for my containers were simply removed, meaning my containers were now running without any limitation in terms of resources! I found out later that systemd “cleans” cgroups that are not created by itself, unless you start your tool as a service file with the “Delegate=yes” attribute (see ControlGroupInterface).

      So the only way to avoid systemd is to use it. Awesome.

      There are many other issues with its model, and I personally think the amount problems it brings outcome its benefits.

    2. 4

      I find the “doord” analogy incorrect. It makes systemd look like it is based on a loosy idea from the start. Openning doors faster in a car is not as important as booting an OS. While I’m not a systemd fan, I find the comparison unfair, which weaken the argument against it. Systemd was based on an important fact: existing init systems were a mess to manage. Sadly, the implementation grew into something that’s even more complex and huge.

      I was expecting more focus on what Devuan is doing for the opensource community like supporting software that do not depend on an init system, or encouraging simple ideas instead of overengineered ones (looking at you systemd-hostnamed…).

      Instead, this article looks just like any other rant against systemd, with the same arguments everyone brings up that all fall in the “bugs” category.

      After all, systemd brings some kind of « stability », as its interface is consistent (even though it has bugs). For many people, the new shinny features of systemd are definitely not worth its complexity, and this is for these people that the work from the Devuan guys is important. By keeping the alternative to systemd alive, they keep the spirit of linux which aim to keep every piece of software running on top of the kernel swappable, instead of relying on a rigid and complex API.

      1. 5

        There’s a really good comment by someone who maintained Arch Linux’s init scripts pre-systemd about why they switched over. I’m as anti-systemd as the next person, but it’s important to understand why it became so successful.

        1. 7

          Having a standard init system is incredibly valuable for package maintenance and having full process control does require having code in init to track children, grandchildren and even detached child processes. You can’t do that without being the init process.

          All that being said, systemd is terrible from a usability standpoint. I honestly haven’t seen all the random/crashing bugs people complain about, but I do think systemctl is a terrible command, the bash completion is terrible slow, you can’t just edit a target file; you have to reload the daemon process for those changes to take effect, you have to call status after a command to see the limited log output, binary logs, etc. etc. etc.

          There have been so many attempts to take the one good thing (standardized init scripts) and make drop in replacements (uselessd and others) and they all hit some pretty hard limits and are eventually abandoned. That’s sad that systemd is so integrated that replacements aren’t even remotely trivial.

          Without systemd, you need one of the udev forks, consolekit and a few other things to make things work. Void Linux, Gentoo and Devuan are pretty critical in keeping this type or architecture viable. Maybe one day someone will come up with an awesome supervisor replacement and get other distributions on-board to have a real alternative.

          1. 5

            Having a standard init system is incredibly valuable for package maintenance

            The problem here is that Systemd can never be a standard init system, because it’s Linux only.

            Maybe one day someone will come up with an awesome supervisor replacement and get other distributions on-board to have a real alternative.

            I’m working on it :) https://github.com/davmac314/dinit

            This has been my pet project for some time, although I’m long due to write a blog post update on progress. (Not a lot of commit recently, I know - that’s because Dinit uses an event loop library, Dasynq, which I’ve been focussing on instead - that should be able to change now, as I’ve just released Dasynq 1.0).

          2. 5

            it was impossible to say when a certain piece of hardware would be available […] this was solved by first triggering uevents, then waiting for udev to “settle” […] Solution: An system that can perform actions based on events - this is one of the major features of systemd

            udev is not a system that can perform actions based on events, like devd does on FreeBSD? What is it then?

            we have daemons with far more complex dependencies

            The question is… WHY?

            Sounds like self-inflicted unnecessary complexity. I believe that services can and should start independently.

            I run several webapps + postgres + nginx + dovecot + opensmtpd + rspamd + syncthing on my server… and they’re all started by runit at the same time, because none of them expect anything to be running before them. nginx doesn’t care if the webapps are up, it connects dynamically. webapps don’t care if postgres is up, they will retry connection as needed. etc. etc.

            Why can’t Linux desktop developers design their programs in the same way?

        2. 1

          servers that don’t boot, that don’t reboot

          My experience is opposite to that. I used to run Arch Linux for a very long time, but while it mostly booted fine (provided you configured the strange daemon configuration right, like don’t start everything async because it will fail), it got stuck shutting down quite often for whatever reason. I get that ACPI is tough and stuff, but since systemd I never had a problem again with figuring out why some weird thing in startup & shutdown didn’t work. I don’t have to concern myself at the order daemons are started and stopped anymore.

          Also, I can now configure these things in exactly the same way I do on my Debian servers. Which is not essential but a nice to have. Maybe in the future we get something which will allow me not to learn a new network config script on each distribution but small steps.

          1. 1

            I was an avid Debian user for many years, but I switched to NixOS before Debian adopted systemd. NixOS uses systemd quite heavily, and I’m not a fan of its scope creep.

            The next time I need to install an OS I’m going to give GuixSD a try; being GNU, FOSS-only and Scheme-based are all major attractions to me; but so is the fact it doesn’t use systemd; it uses dmd/shepherd, which has been around for many years and AFAIK has similar advantages to systemd/uselessd/upstart/s6/etc. but without systemd’s feature creep.