More seriously, it would be great to have the good parts of systemd (logind, ability to control containers, the runner of unit files) implemented independently and without the "invasive" parts like control of DNS or binary logging.
This is the root cause of the problem. Regular initd + rc scripts are simple enough to be understood by everybody, which systemd is too complex to understand in the limited time we have. There is no "systemd senior developer" or "systemd solutions architect" positions for systemd developers, to adjust investment into systemd ecosystem.
We can easily replace initd by something much more powerful, like perl, javascript, python, java + spring, Emacs, or even Firefox or Eclipse in headless mode. They all are able to read configuration files and launch new processes. But (almost) nobody does so, because they are hard to debug and have very large surface.
On a modern distro, I wouldn't say so, there is so much you would need to add on top of an rc script to get it to work correctly. Once you start trying to make use of the same capabilities it becomes just as complex as systemd, if not moreso. This is beyond just turning it into perl or javascript, I'm talking about OS-level features: for example even a basic Linux feature like mount namespaces is non-trival to do in an rc script and have everything get mounted and cleaned up correctly with all the right settings, whereas this is one or two lines in a systemd unit, and you know it's always going to work. It doesn't help much if you implement it in a shell script or in python versus having it in a systemd unit, this is code someone has to write, and if you say "it's too complex I don't understand it" then that would be limiting you because you're not using the intended security features of the OS. Does that explain it?
I've wanted this for some scenarios where I'm bridging the gap between VM/OVAs and containers, and would like a single rootfs to be able to serve in both capacities. Basically all the current options are not great:
* Make invasive changes to move the container-relevant stuff to another init system.
* Make invasive changes to run a systemd instance in user mode in the container.
* Run the container as privileged.
* Something something podman (not an option for k8s).
It’s also not like journald uses some secret format.
Text logs are easy to get at, I don’t need a special program to read, I just need something to display a raw byte on the screen.
Also, I wonder what the actual performance benefits are. I remember back when most protocols were text and/or binary. Usually binary was slower when messing about with stringy stuff. For example, using memcached to cache strings. Why encode/decode strings in a binary protocol when you can just use strings all the way down? I don’t know if that premise is still true, but for us older people, it makes sense to keep inherently stringy stuff stringy to avoid overhead.
I've seen this type of comment a lot on reddit and I don't understand why people say this. You do not really need a special program to read the systemd logs either, in the event that journalctl doesn't work you can easily use `strings` to read the logs. Feel free to try it right now just for fun, the binary format of journald is actually extremely simple and well-documented and just stores the logs sequentially, it's not "encoding" the strings at all. Why would it need to? It's all fulltext data.
Re performance: Strings are most defintely worse than some fixed size format. It’s not an accident that FPGAs were used to serialize/deserialize XMLs, why Google made a whole new binary protocol, etc. Just think about it, you have to parse a string character by character (yeah some clever vector magic can make some string processing go a few chars at a time), while a binary format with fixed layout will be practically random access. You can query the nth entry, etc.
As I recall, there were two reasons for the binary format - a signing scheme to make it tamper proof and more metadata on each log entry.
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.
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.
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.
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.
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.
For me, it's less that it's binary and more that it's some bespoke format specific to journald instead of, say, an SQLite database or something else similarly widely-used and well-known.
Specify that you only want to last day or so (which is quite likely what you actually want), but I do agree that the default could be something sane like only the last week.