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