1. 26
  1.  

  2. 5

    Having just done a lot of work with systemd, I’m extremely excited about this project! I don’t know that it will see a lot of use though, reactionary forks like this seem to be ignored much of the time. In any case, this is an interesting development.

    1. 1

      There should be 3 or more systems just like this one. I haven’t followed much of the systemd debate at all, even when the dust settles, I’ll just use what my distro uses and spawn my own code using supervisord and be happy. That said, systemd seems like an amazing troll hack, very un-unix, very surprised. Anyways, long live process spawning diversity! What are Arch and Slackware using?

      1. 3

        Arch uses systemd.

    2. 3

      Seems like quite an impressive achievement already - but the docs leave me wondering: with several narrowly-defined init schemes already out there, what are the parts of systemd that are worth keeping?

      The ‘motivations’ section mentions “socket activation, parallel execution, resource limiting, cgroups, the declarative configuration syntax, etc.” – but that “etc” is precisely the pit that systemd has itself fallen into.

      1. 2

        I don’t understand the systemd hate, it seems to all boil down to Poettering-as-a-person hate. My experience with it has been very positive and it is surely a huge step forward from SysV.

        And ‘it is not UNIX style’ arguments are totally bogus, it’s important to have working software, not UNIX-style software.

        1. 6

          a) it appears to be a design goal of systemd to make Gnome not work on FreeBSD. It was working before. The reasons to hate this are fairly obvious.

          b) last time I installed Pottering software it broke my sound. Once bitten and all that.

          1. 1

            Well the b) happened in 2008, and was largely caused by Ubuntu adopting brand new technology too fast. I don’t use GNOME nor FreeBSD so I can’t comment on a).

            1. 3

              I’ve had to deal with PA on systems other than Ubuntu and long after 2008.

          2. 3

            Candid question (no, really):

            What is Systemd improving over SysV? What is the problem you think it is solving?

            1. 7

              systemd (SystemD if you want to piss off proponents) init specifically offers a bunch of benefits over sysv init, most of which revolve around not writing bourne shell scripts to launch system daemons and providing a framework for managing said daemons (instead of being handled ad hoc with more shell scripts and management functionality built into the daemon itself). This is pretty strictly beneficial.

              The biggest complaints people have are that systemd has started implementing things way beyond init, and tightly coupling them together into a practically monolithic blob of system management code. Many of the non-init components enforce extremely questionable design decisions, and they’re practically impossible to replace because the systemd developers are actively hostile to independent development.

              1. 2

                But SysV was created because of the same reason against older bsd rc.d system. SysV allowed to automatize programmatically and using GUI tools the management of the start up system. Also, it allows to manually customize the generated scripts.It may even allow status or reload commands if needed or possible.

                So, other than because somebody though it was a good idea for a weekend project… why systemd?

                1. 1

                  edit: ignore this, true but not germane.

                  But sysv init scripts aren’t required to be Bourne Shell, they are processes. I have made lots of init scripts in Lua and Python. There just needs to be a clean protocol to denote what you accept and what you produce.

                  1. 3

                    They are still arbitrary scripts, that’s the main problem. systemd (or, I dunno, upstart) provides declarative syntax to define inits. It’s much easier to write and/or generate.

                    1. 5

                      But providing a declarative syntax for init scripts is orthogonal to init system itself. One could simply have

                      #!/usr/bin/initodeclar-script
                      start:
                          # do this on start
                      
                      status:
                          # do this on status
                      

                      etc

                      I don’t really understand why an init system needs to be more than a couple hundred lines of Lua.