17 ms·

For me, the difference is simple. Systemd is great when it works. But, part of the value of the Unix philosophy is resiliency in the face of errors. When my vo

For me, the difference is simple. Systemd is great when it works. But, part of the value of the Unix philosophy is resiliency in the face of errors. When my void Linux / alpine Linux systems have internal failures, I can troubleshoot and solve them because the system is composed of minimal abstractions tied together - I can feasibly deduce the root of the problem, and fix it, even if half the OS is missing. With systemd, it's one big mess. Problems are far more opaque, and the pieces are far more interdependent: it's easier to wipe and start over, thereby treating the os as a black box, than to dig in and find the problem. I avoid systemd systems wherever I need to do anything with the os itself that isn't extremely ordinary.

viraptor 6y ago
Are you sure it's not just familiarity with old tools? Systemd works pretty hard to put logs in one place (journald) - even ones from service start-ups. And any dbus interaction can be traced by listening to the system bus. Is that a mess compared to the old bunch of separate log files and errors lost if they don't activate their logging interface early enough?
- generalizations 6y ago
  I'm not talking about reading logs. (Which, by the way, is a lot easier to do in a dead system when they're text and not binary. It's hard to mess up cat, grep, and notepad.) I'm talking about being able to rule out causes because the primary components of the system are independent of each other.
  - viraptor 6y ago
    > is a lot easier to do in a dead system when they're text and not binary The binary format doesn't matter for browsing logs. Replace `cat /your/custom/service/file.log | grep ...` with `journalctl -u service | grep ...` (or just `-a` for everything) I'd actually argue it's easier not to mess up with journal with simple tools, because you don't have to special-case `service`, `service.1`, `service.2.gz` files.
    - Nursie 6y ago
      For a dead system with it's main disk mounted on a living one, on which the service is not registered, is it that easy? I've never tried. I like service files, but the rest not so much.
      - Macha 6y ago
        journalctl -D /mnt/othersystemroot/var/log/journal <...>

viraptor 6y ago

Are you sure it's not just familiarity with old tools? Systemd works pretty hard to put logs in one place (journald) - even ones from service start-ups. And any dbus interaction can be traced by listening to the system bus. Is that a mess compared to the old bunch of separate log files and errors lost if they don't activate their logging interface early enough?

generalizations 6y ago
I'm not talking about reading logs. (Which, by the way, is a lot easier to do in a dead system when they're text and not binary. It's hard to mess up cat, grep, and notepad.) I'm talking about being able to rule out causes because the primary components of the system are independent of each other.
- viraptor 6y ago
  > is a lot easier to do in a dead system when they're text and not binary The binary format doesn't matter for browsing logs. Replace `cat /your/custom/service/file.log | grep ...` with `journalctl -u service | grep ...` (or just `-a` for everything) I'd actually argue it's easier not to mess up with journal with simple tools, because you don't have to special-case `service`, `service.1`, `service.2.gz` files.
  - Nursie 6y ago
    For a dead system with it's main disk mounted on a living one, on which the service is not registered, is it that easy? I've never tried. I like service files, but the rest not so much.
    - Macha 6y ago
      journalctl -D /mnt/othersystemroot/var/log/journal <...>