I'd prefer it to be a separate independent component, the way syslogd is. (Yes, I know that in systemd the binary logging can be switched off, or even replaced with a different implementation.)
I care mostly about having an independent implementation with a different internal architecture, narrower scope, and a separate governance.
The reason it is not “independent” is that it logs even during boot.
Something which simply was not solved with the previous generation of init systems and is greatly important. During booting the file system may not even be mounted, it could hardly be done by a separate process.
>I'd prefer it to be a separate independent component [...] with a different internal architecture [...] and a separate governance
Not sure I understand this, do you mean you would use something that had the exact same feature set, if the internal architecture was different and if someone else was maintaining it? What would be the point of that? Are there some performance or security improvements to the architecture that were suggested upstream that they aren't doing?
>narrower scope
Not sure I understand this either, the scope of journald is actually quite small, there are many syslog implementations that are bigger and have a lot more features.
Not necessarily exact same, and maybe not necessarily having the same problems (such as corruption).
There is a reason that certain things have multiple implementations compatible at the level of key interfaces but different inside. Examples: cron and anacron, more, less, and bat, different NTP implementations, different syslogd implementations, to say nothing of the variety of DNS, SMTP, and HTTP servers.
I'm not sure what you mean corruption, journald logs should actually fare better in terms of dealing with corruption and tampering versus text logs, if you use the log sealing feature. You could also already easily plug any of the syslog implementations in.
Perhaps he is talking about modularity - systemd is a bit all or nothing, it is a pluggable system yes but (AFAIK) it is not modular so you can't write arbitrary software and have it adhere to some standard, instead you have to use the systemd libraries and link against systemd calls.
So it is another layer on top of the kernel in that sense.
The old alt was to put the shell in charge and bash or sh talked to a bunch of random programs. Which is in some ways more modular but also a bit of a nightmare...
I'm not certain anything like that exists, you would have to define some data architecture almost, maybe involve hardware like ACPI and UEFI...
But that goes back to nobody basing their career over how a computer boots...overly complex. Maybe better just to improve systemd instead.
I'd prefer it to be a separate independent component, the way syslogd is. (Yes, I know that in systemd the binary logging can be switched off, or even replaced with a different implementation.)
I care mostly about having an independent implementation with a different internal architecture, narrower scope, and a separate governance.