4 ms·

As a previous user/exploiter of SysV init, I really like systemd. -I can spawn/respawn daemons as someone other than root. SysV inittab runlevels are root-only

by chasil 2y ago

As a previous user/exploiter of SysV init, I really like systemd. -I can spawn/respawn daemons as someone other than root. SysV inittab runlevels are root-only. -I used runlevel 4 for all my magic. Now I can have so much more magic. -nspawn has let me craft containers from day 1. -Path units are so much better than inotifywait (and somewhat better than incron). -Do I prefer socket units to inetd? Mostly. -Free automounter! Yes, crazy syntax, but gratis! Do I wish it worked on BSD? Yes.

m463 2y ago
I think there are two parts of systemd - the functionality and the implementation. It IS functional - it does things that are helpful and important. But the implementation is hard to swallow. It is just so far away from elegant, understandable and usable.
- akerl_ 2y ago
  Can you give some examples of implementation that are hard to understand and use?
  - m463 2y ago
    - symlinks - systemd took the "accepted" idea of symlinks from /etc/init.d -> /etc/rc*.d and put symlinks all over the filesystem for all kinds of units. It is less understandable and manageable. - mediocre config files - they decided that config files are declarative, which could be good, but it pushed simple (and visible) logic in /etc/init.d/* files into more complicated logic encoded in binaries. The simplistic config files seem to be more simple for systemd to implement, but harder to understand, maintain and use. - binary log files. everything has to go through systemd to access them. - responsibility creep - systemd started taking over more functions, and it doesn't seem to stop. Will systemd turn into busybox, with simpler poorer implementations of every single thing in the system? dnsmasq is similar. The thing is, busybox and dnsmasq are cut down implementations for smaller system that are alternatives to their full-featured brethren. systemd takes over the core of a system.
    - akerl_ 2y ago
      I think it's possible that you just hold a non-majority opinion about what good usability looks like. That's fine, and I'm OK with a world where we disagree about how usable systemd is, but I interact with the systemd config files and symlinks and logs pretty frequently, and have found them to be orders of magnitude more usable and understandable than /etc/rc#.d and /etc/init.d and "I wonder if this system puts sshd logs in /var/log/auth.log or /var/log/secure or somewhere else". Notably, I interact with a mix of Arch and Ubuntu and RHEL systems over the course of a week, and systemd means I can engage with all of the above using the same methodology. In terms of creep... busybox is noteworthy for packing all of a system into a single binary. systemd doesn't do this. Their resolver and time daemon and networking and all the other bits and bobs are their own separate binary, and you aren't required to use them.
      - m463 2y ago
        It is possible I haven't communicated the gist of the idea. systemd is functional. It does the things you say. It unifies things, including config files and log files. It works for you. I just don't think the way it did this is that elegant. My busybox analogy should be more viewed as: what if arch/ubuntu/rh decided that busybox would replace all coreutils, etc on their systems today? All the same commands. Still usable. But something is missing...
        _nalply 2y ago
        What is missing? I have the feeling that you are mourning the old, bad days?
    - vetinari 2y ago
      > put symlinks all over the filesystem for all kinds of units. It is less understandable and manageable. It is actually way better understandable and manageable: /usr/lib/systemd is for distro-supplied and packaged units. /etc/systemd is for your local overrides, /run/systemd is for units created at runtime by various generators. (Then there are $XDG_(RUNTIME|CONFIG)_DIR/systemd for user units, for consistency). So no more diffing config files at update time: the distro provided ones are always updated, your overrides are always preserved, cleanly. > - binary log files. everything has to go through systemd to access them. So send them to external syslog, that saves them as you wish. There is a point in indexing them (and being able to have a newline in the log message). - responsibility creep This is a matter of perspective. If you take it as "init system at boot", then yes, it might looks so. If you take as an service manager that runs/stops/reloads/monitors units, based on different events (startup, dbus activation, socket activation, timer, etc): what's the difference in the bulk of action, except for the event that caused that action? The service handling, unit definition, etc. are all the same, just the initiation event is different. In this light, it doesn't take over functions; it consolidates and unifies them. Unlike dnsmasq or busybox, it is not in cut-down fashion, but exactly opposite. It replaces rag-tag of tools with one with more complete and tested implementation.

by chasil 2y ago

m463 2y ago

I think there are two parts of systemd - the functionality and the implementation. It IS functional - it does things that are helpful and important. But the implementation is hard to swallow. It is just so far away from elegant, understandable and usable.

akerl_ 2y ago
Can you give some examples of implementation that are hard to understand and use?
- m463 2y ago
  - symlinks - systemd took the "accepted" idea of symlinks from /etc/init.d -> /etc/rc*.d and put symlinks all over the filesystem for all kinds of units. It is less understandable and manageable. - mediocre config files - they decided that config files are declarative, which could be good, but it pushed simple (and visible) logic in /etc/init.d/* files into more complicated logic encoded in binaries. The simplistic config files seem to be more simple for systemd to implement, but harder to understand, maintain and use. - binary log files. everything has to go through systemd to access them. - responsibility creep - systemd started taking over more functions, and it doesn't seem to stop. Will systemd turn into busybox, with simpler poorer implementations of every single thing in the system? dnsmasq is similar. The thing is, busybox and dnsmasq are cut down implementations for smaller system that are alternatives to their full-featured brethren. systemd takes over the core of a system.
  - akerl_ 2y ago
    I think it's possible that you just hold a non-majority opinion about what good usability looks like. That's fine, and I'm OK with a world where we disagree about how usable systemd is, but I interact with the systemd config files and symlinks and logs pretty frequently, and have found them to be orders of magnitude more usable and understandable than /etc/rc#.d and /etc/init.d and "I wonder if this system puts sshd logs in /var/log/auth.log or /var/log/secure or somewhere else". Notably, I interact with a mix of Arch and Ubuntu and RHEL systems over the course of a week, and systemd means I can engage with all of the above using the same methodology. In terms of creep... busybox is noteworthy for packing all of a system into a single binary. systemd doesn't do this. Their resolver and time daemon and networking and all the other bits and bobs are their own separate binary, and you aren't required to use them.
    - m463 2y ago
      It is possible I haven't communicated the gist of the idea. systemd is functional. It does the things you say. It unifies things, including config files and log files. It works for you. I just don't think the way it did this is that elegant. My busybox analogy should be more viewed as: what if arch/ubuntu/rh decided that busybox would replace all coreutils, etc on their systems today? All the same commands. Still usable. But something is missing...
      - _nalply 2y ago
        What is missing? I have the feeling that you are mourning the old, bad days?
  - vetinari 2y ago
    > put symlinks all over the filesystem for all kinds of units. It is less understandable and manageable. It is actually way better understandable and manageable: /usr/lib/systemd is for distro-supplied and packaged units. /etc/systemd is for your local overrides, /run/systemd is for units created at runtime by various generators. (Then there are $XDG_(RUNTIME|CONFIG)_DIR/systemd for user units, for consistency). So no more diffing config files at update time: the distro provided ones are always updated, your overrides are always preserved, cleanly. > - binary log files. everything has to go through systemd to access them. So send them to external syslog, that saves them as you wish. There is a point in indexing them (and being able to have a newline in the log message). - responsibility creep This is a matter of perspective. If you take it as "init system at boot", then yes, it might looks so. If you take as an service manager that runs/stops/reloads/monitors units, based on different events (startup, dbus activation, socket activation, timer, etc): what's the difference in the bulk of action, except for the event that caused that action? The service handling, unit definition, etc. are all the same, just the initiation event is different. In this light, it doesn't take over functions; it consolidates and unifies them. Unlike dnsmasq or busybox, it is not in cut-down fashion, but exactly opposite. It replaces rag-tag of tools with one with more complete and tested implementation.