4 ms·

Can you give some examples of implementation that are hard to understand and use?

by akerl_ 2y ago

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.
  - m463 2y ago
    > Unlike dnsmasq or busybox, it is not in cut-down fashion check out for systemd networking, the resolver, timesyncd, etc... for example timesyncd IS cut-down and brute-force: "does not bother with the full NTP complexity, focusing only on querying time from one remote server and synchronizing the local clock to it" ntp is complex, but it does many things in safe and effective ways. etc.
    - vetinari 2y ago
      systemd-network is cut-down I agree. But it does not have an ambition to replace NetworkManager; it is usually installed only in cut-down environments (containers; ubuntu installs it for servers, but not for desktops). Redhat doesn't even have it in repo. systemd-resolved, on other hand, is good. There's no other resolver stub, that has the functionality that resolved has. It is the only one for Linux, that can do per-link, split DNS properly.
- consteval 2y ago
  I disagree with most of this. 1. symlinks: I think the systemd structure is very intuitive and the order of overwriting makes sense. It's new, but it makes sense, and we only have 3 different locations, each with a specific order and precedence. 2. Config files: I think keeping the declarative syntax is the secret sauce of systemd. The whole point is you can orchestrate processes without needing to write code. They're much easier to understand if you assume a knowledge point of 0, and they're much more maintainable (no logic), and they're even more portable. Bonus is they're much faster to execute by the init system. Yes, most of the logic is in systemd now, but you tell it what to do. Reading the documentation goes a long way to making unit files less cryptic. 3. Binary logs: yeah I agree just not a great idea. Always sounds nice on paper because you can do neat things with permissions and can have faster performance, but in reality just not necessary. They got too fancy. 4. Responsibility creep: from where I'm standing, not a problem. systemd isn't a piece of software, it's just a name given to a collection of software, like GNU. systemd-init doesn't have feature creep. Sure, now we have systemd-file-my-taxes, but that's optional and it's a whole different program that just uses the systemd name.

Can you give some examples of implementation that are hard to understand and use?

by 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.
- m463 2y ago
  > Unlike dnsmasq or busybox, it is not in cut-down fashion check out for systemd networking, the resolver, timesyncd, etc... for example timesyncd IS cut-down and brute-force: "does not bother with the full NTP complexity, focusing only on querying time from one remote server and synchronizing the local clock to it" ntp is complex, but it does many things in safe and effective ways. etc.
  - vetinari 2y ago
    systemd-network is cut-down I agree. But it does not have an ambition to replace NetworkManager; it is usually installed only in cut-down environments (containers; ubuntu installs it for servers, but not for desktops). Redhat doesn't even have it in repo. systemd-resolved, on other hand, is good. There's no other resolver stub, that has the functionality that resolved has. It is the only one for Linux, that can do per-link, split DNS properly.
consteval 2y ago
I disagree with most of this. 1. symlinks: I think the systemd structure is very intuitive and the order of overwriting makes sense. It's new, but it makes sense, and we only have 3 different locations, each with a specific order and precedence. 2. Config files: I think keeping the declarative syntax is the secret sauce of systemd. The whole point is you can orchestrate processes without needing to write code. They're much easier to understand if you assume a knowledge point of 0, and they're much more maintainable (no logic), and they're even more portable. Bonus is they're much faster to execute by the init system. Yes, most of the logic is in systemd now, but you tell it what to do. Reading the documentation goes a long way to making unit files less cryptic. 3. Binary logs: yeah I agree just not a great idea. Always sounds nice on paper because you can do neat things with permissions and can have faster performance, but in reality just not necessary. They got too fancy. 4. Responsibility creep: from where I'm standing, not a problem. systemd isn't a piece of software, it's just a name given to a collection of software, like GNU. systemd-init doesn't have feature creep. Sure, now we have systemd-file-my-taxes, but that's optional and it's a whole different program that just uses the systemd name.