4 ms·

The problem is when "It just works" doesnt, it's an undebuggable, un-understandable, documentationless kluge with binary logs. I had it silently take over my D

The problem is when "It just works" doesnt, it's an undebuggable, un-understandable, documentationless kluge with binary logs. I had it silently take over my DNS . I even have the 'official' way check-boxed to not override DNS settings in Network Manager. Does so anyway. I even removed the symlink from /etc/resolv.conf and made it root:root . SystemD changed it next reboot.

darkwater 7y ago
Documentionless? https://www.freedesktop.org/software/systemd/man/ https://www.freedesktop.org/software/systemd/man/ and you have it locally and offline too when you need it. Like in the 80s/90s unix way. And it's way more documented that your average init script sourcing distro-specific bash/sh libraries where you have to dig into and read the code just to understand how that thing works
Analemma_ 7y ago
> The problem is when "It just works" doesnt, it's an undebuggable, un-understandable, documentationless kluge with binary logs. Init scripts were undebuggable, un-understanable, documentationless kluge with text logs, and systemd has a perfectly functional format converter. I'm not seeing the regression here.
- dijit 7y ago
  2 things; 1) Init scripts varied by implementation very much, I have managed to successfully debug, make, read and otherwise modify/parse init scripts from basically every _major_ distro including OpenBSD and FreeBSD. I am not particularly intelligent, so if I can do it, you can. 2) There is no reason to assume we go back to bash scripts per-se, there is a huge middle ground between a huge C program which execve()'s programs and watches them live, parses their output, logs it, enables socket activation, keeps an in memory DAG that it determines randomly on boot.... and bash scripts.
  - cwyers 7y ago
    Re 2... there is a lot of middle ground there, but can that middle ground tackle all of the problems systemd is trying to solve without resorting to what they've resorted to?
    - dijit 7y ago
      From the original problem statement[0]? Yeah I think so, Runit solves all of those issues. [0]: http://0pointer.de/blog/projects/systemd.html http://0pointer.de/blog/projects/systemd.html
silon42 7y ago
I like systemd, but agree that binary logs are a horrible idea.
- agumonkey 7y ago
  the initial goals was laudable though, is there a way to have text logs and verifiability
- Redoubts 7y ago
  Binary logs seem great on macOS, why is this bad for Linux?
  - qtplatypus 7y ago
    Because Linux and MacOS targets different roles.
    - Redoubts 7y ago
      Could you elaborate more? My use case is very similar between the two, and I don't mean workstation operation.
      - qtplatypus 7y ago
        I'm thinking that Linux is primarily a server OS and MacOS is primarily a workstation. And yes people do use Linux on the desktop and visa versa.
        Redoubts 7y ago
        > I'm thinking that Linux is primarily a server OS and MacOS is primarily a workstation. Good for you. > And yes people do use Linux on the desktop Good for them. But the fact remains that this post still ignores why binary logs are bad for the server use case. They seem great for me in that role.

darkwater 7y ago

Documentionless? https://www.freedesktop.org/software/systemd/man/ https://www.freedesktop.org/software/systemd/man/ and you have it locally and offline too when you need it. Like in the 80s/90s unix way. And it's way more documented that your average init script sourcing distro-specific bash/sh libraries where you have to dig into and read the code just to understand how that thing works

Analemma_ 7y ago

> The problem is when "It just works" doesnt, it's an undebuggable, un-understandable, documentationless kluge with binary logs. Init scripts were undebuggable, un-understanable, documentationless kluge with text logs, and systemd has a perfectly functional format converter. I'm not seeing the regression here.

dijit 7y ago
2 things; 1) Init scripts varied by implementation very much, I have managed to successfully debug, make, read and otherwise modify/parse init scripts from basically every _major_ distro including OpenBSD and FreeBSD. I am not particularly intelligent, so if I can do it, you can. 2) There is no reason to assume we go back to bash scripts per-se, there is a huge middle ground between a huge C program which execve()'s programs and watches them live, parses their output, logs it, enables socket activation, keeps an in memory DAG that it determines randomly on boot.... and bash scripts.
- cwyers 7y ago
  Re 2... there is a lot of middle ground there, but can that middle ground tackle all of the problems systemd is trying to solve without resorting to what they've resorted to?
  - dijit 7y ago
    From the original problem statement[0]? Yeah I think so, Runit solves all of those issues. [0]: http://0pointer.de/blog/projects/systemd.html http://0pointer.de/blog/projects/systemd.html

silon42 7y ago

I like systemd, but agree that binary logs are a horrible idea.

agumonkey 7y ago
the initial goals was laudable though, is there a way to have text logs and verifiability
Redoubts 7y ago
Binary logs seem great on macOS, why is this bad for Linux?
- qtplatypus 7y ago
  Because Linux and MacOS targets different roles.
  - Redoubts 7y ago
    Could you elaborate more? My use case is very similar between the two, and I don't mean workstation operation.
    - qtplatypus 7y ago
      I'm thinking that Linux is primarily a server OS and MacOS is primarily a workstation. And yes people do use Linux on the desktop and visa versa.
      - Redoubts 7y ago
        > I'm thinking that Linux is primarily a server OS and MacOS is primarily a workstation. Good for you. > And yes people do use Linux on the desktop Good for them. But the fact remains that this post still ignores why binary logs are bad for the server use case. They seem great for me in that role.