4 ms·

The unit and service file formats are honestly fine, it should be possible to have a second implementation. We have several varieties of SysV init already.

• bandrami 3y ago
  The unit file format is what I don't like about it. A giant spaghetti code mess where dependencies can be literally anywhere and the final imperative result is completely opaque. An init system, ultimately, does a bunch of one time actions to bring the system up; it really does just work better as an imperative script.
  • esarbe 3y ago
    How are Systemd's unit files any worse than unconstrained init scripts written in a Turing complete language with even basic stuff - like PID files - managed manually?
    • bandrami 3y ago
      Because they are opaquely translated into an imperative sequence but you never get to see it. Also who are these people who have complicated sysv scripts? I've heard this for years and never really understood it. One script per service with a stop and start command (and maybe a status if you want to get fancy) and runlevel definitions that start and stop them. It's not rocket surgery, and it's a hell or a lot easier to debug than a declarative system definition.
      • kaba0 3y ago
        > Because they are opaquely translated into an imperative sequence but you never get to see it Into correct imperative sequence. That’s the whole point of declarative things. You can’t feasibly write it correctly otherwise. You are writing programming languages over assembly for largely this same reason.
      • pjmlp 3y ago
        Ah, the wonders of sysv scripts in commercial UNIX systems doing all kinds of interesting stuff from corporate IT.
        • JdeBP 3y ago
          The reality is that it wasn't corporate scripts hidden away from the public eye. There were some nightmare van Smoorenberg rc scripts in the likes of Debian. FreeBSD has Mewburn rc not van Smoorenberg rc and was thus inherently better in this regard until the middle of 2014 (https://unix.stackexchange.com/a/480897/5132 https://unix.stackexchange.com/a/480897/5132). But even FreeBSD has some large rc scripts, particularly in the networking and the HID parts such as Bluetooth and configuring all attached keyboards; albeit that the FreeBSD style guidelines mean that they are more legible than the nightmare Debian (et al.) ones.
  • kaba0 3y ago
    An init system is for all practical purposes a build system - a very complex problem where literally every sane solution is declarative. Especially when you take into account error handling (that HDD is not yet available, will you imperatively wait for it to come up and pause everything else? Do parallel work in the meantime in fking bash? Or what exactly?)
    • bandrami 3y ago
      I mean, yes? Start one service at a time, in the order specified? There's not some reason that magically stopped working in 2010.
      • orra 3y ago
        Sequential start-up is unnecessarily slow. Startup is ultimately a complex problem. There is no magic, just race conditions which maybe became more apparent. LVM may or may not be used, and takes time to start up. Do you wait for it? Ditto wireless networks. And how do you handle devices being hotplugged? Setups vary widely, and can be dynamic.
        • hulitu 3y ago
          > Startup is ultimately a complex problem ?? Mount filesystem, start networking, start networking daemons, update crappy gtk stuff, run rc.local. What is so complex ?
          • JdeBP 3y ago
            Apparently, for starters, knowing when rc.local is to be run. It was run in the middle of rc, not at the end; as pointed out in the OpenBSD manual.
    • orra 3y ago
      This is a very interesting analogy, which I haven't seen before. Thanks.