This is only a tiny piece of the experience though. What about journalctl? systemctl? etc? That stuff is alien vs tail -f or ./just/run/some.sh which works with everything _except_ systemd.
> You can google how to do the equivalent to `tail -f /var/log/foo.log` in a minute.
Doesn't the fact that I have to google an alternative workflow for something that behaves consistently across pretty much all other software make its UI worse, at least in that regard? I get that maybe it's a justified trade-off, but that doesn't make the UI any better.
> What do you mean by ./just/run/some.sh?
I suppose just dumping an exec command into an executable file and call it a service.
You can use syslog in conjunction with the systemd journal. Some distributions come set up that way by default, and for the others you can just `apt-get install rsyslog` or whatever. When you have a syslog daemon installed, `tail -f` and everything else you're used to works exactly the same as before, you can pretend the journal doesn't even exist if you want. And if you don't have a syslog daemon installed... well, i don't know if that's really journalctl's fault, is it?
Sure, just throw in several extra steps, huge numbers of syscalls and make any admin add complexity to their systems. For a busy service, this is a performance issue that the systemd devs simply reject out of hand as "doing it wrong".
That doesn't seem like an especially compelling argument. There are components of every ready-made operating system that you 'don't need or want'. I don't need or want an IPv6 stack, or debugfs, or half of the other features that come with most distributions' Linux kernels, and i don't need or want legacy bull shit like (d)ash and cpio and Python 2. But there they always are anyway, and i don't lose much sleep over that fact.
journald by default doesn't keep logs from the previous boot, which is extremely annoying. What's the point of having a logging system where you have to keep the old one around to read old logs? I've also had it seemingly not have any loglines for queried units when it should have; not sure what happened there.
In one configuration, journald logs to an in-memory filesystem; in another, it logs to an on-disc filesystem; in a third, it tries on-disc and falls back to in-memory; in a fourth it does not save the log either in memory or on disc. Different distributions configure this differently.
