|
|
|
|
|
by Sanddancer
4574 days ago
|
|
I can, however, again, it's a pretty poor direction that only serves to fragment systems. Many of the complaints that drove the creation of journald could have been better solved through a better default syslogd configuration. Additionally, the journald solution for needs such as remote logging or logging to multiple locations means that you now need to pipe through a process that has a near sole job of piping to another process. It just gives a very bad feeling of hackishness to me. |
|
It's so far been adopted by redhat, suse, arch, coreos and with some consideration by debian. The only big name not thinking about it is Ubuntu.
I don't think that many of the journald drivers could have been solved by better syslogd configuration, for example journald cryptographically signs each log entry. Even if you get root on my box, you can't edit an entry without me knowing. That's not possible in any meaningful way with syslog.
I don't share the view of a hack, the speed improvements of introducing journald have been tremendous and usability is mostly better.
For example, the number 1 thing done with syslog output is probably either grep it, so journald improves on this:
Or tail it The places i don't like the user interface are around starting and stopping services. However the old interfaces work fine for now.