Documentionless? 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

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

Binary logs seem great on macOS, why is this bad for Linux?

Because Linux and MacOS targets different roles.

Could you elaborate more? My use case is very similar between the two, and I don't mean workstation operation.

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.

> 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.

the initial goals was laudable though, is there a way to have text logs and verifiability

> 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.

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.

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?

From the original problem statement[0]? Yeah I think so, Runit solves all of those issues.

[0]: http://0pointer.de/blog/projects/systemd.html