daemontools doesn't run as pid 1 and achieves all of this.
How is adding a line to a run script "duplicating logic badly"?
Coupling is clearly bad, as evidenced by ... 30+ years of software design, but is a necessary evil. I don't see any reason why it's necessary in such a low level system component. "this is not rocket science" you don't impose dependencies on something you want to be reliable.
Daemontools is clearly the most mature solution, from a perspective of stability. It's probably why nobody wants to use it, there's nothing to play with or exploit for profit because it already works.
systemd-journald provides tampering-attestation features that plain-text logs do not, and cannot, provide. It's fundamentally more secure.
Reality: if I owned the user writing logs, I can do anything I want with the logs, no matter how they're stored.
Here is something you cannot do: you cannot alter the logs without anyone noticing, since log entries have a rolling hash.
This prevents an attacker from being able to modify logs without detection, and was implemented in systemd after the postmortem on the kernel.org breakin, i.e., it was developed to counter an actual threat.
I would suggest you read up on what log attestation actually does.
The only truly secure way to record messages up to the point of break-in is a one-way remote log. Any new messages after break-in is subject to falsification.
And if you have this then you don't need a fancy cryptographic syslogd to detect tampering.
Security half-measures do not mean you are secure. If it can be hacked, it will be hacked, and then what was the point of sacrificing your whole system's init system?
(Also you could just replace syslogd with a journaled syslogd, rather than replacing your entire init system... but I guess that's off-topic?)
FAIL. You just wrote outdated software. Under this dumbass idea of journaling, which by defition is there to allow editing.., the best thing you can do is built a rolling function, which basically means coping the data, which basically means increasing your attack surface.
These remote copies of the logs could actually be used to detect log-tampering and 0day exploits.
anything can have any feature, what matters is how it's built.
Assuming nothing has managed to redirect those unlinks for example...
As soon as the attacker manages to extract the state of the key generator from memory at one point of time, the log entries from that and the following sealing periods can be modified and cleanly sealed.
I have written hacks to work around this (I have a gentoo VM that uses supervise as an openRC replacement, and have several hacks to work around this issue). It's a pain in the ass, and one reason why systemd runs in pid 1.
I prefer daemontools, but it's not perfect; it made a different set of tradeoffs.
The comment you're responding to is talking about dependencies in boot services, e.g., sshd depends on having the network interface up. Systemd does a great job of handling this sort of thing, allowing services to start in parallel, but ensuring that things only start after all the pieces they rely on have started. That sort of dependency isn't "bad" -- it just is. You can't remove a dependency like this, it reflects reality.
That said, I really don't care for systemd. I think the complexity it adds more than counteracts the benefits it provides, but I'm old and didn't mind SysV or BSD init.
So many problems come from such a simple dependency.
Designing all services to handle and expect failures and just let init restart regardless of the state is the RIGHT solution.