Head_on_a_Stick wrote: ↑Sun May 12, 2019 5:37 amI would always advise people to only ever trust one person: themselves.
So presumably then you don't run MX Linux or antiX Linux, but rather a custom hand-crafted OS on custom hand-crafted hardware with custom hand-crafted components such as a custom hand-crafted CPU, that you made from beach sand.
Head_on_a_Stick wrote: ↑Sun May 12, 2019 6:03 amThe binary format allows messages from such sources as ATA SMART blobs, SCSI sense data, coredumps & firmware dumps to be included directly (which is not possible with syslogd) and also makes direct export in, for example, JSON format possible.
Although a log is meant to be a diagnostic tool, not
the diagnosis itself. I don't see why a log should be in a binary format unless there's primarily binary data associated with it.
Head_on_a_Stick wrote: ↑Sun May 12, 2019 6:03 amThe journal data is also authenticated, which makes undetected manipulation impossible (unlike with syslogd).
I admit that is a bit of a problem, where processes can claim to be another program. However that doesn't mean the journal is immune, if you're in root you can just write some gibberish to the log file and corrupt it. No different to good ol' syslogd.
Head_on_a_Stick wrote: ↑Sun May 12, 2019 6:03 amIf the journal entry is corrupted then it is rotated out and stored, the functionality of the logging mechanism is not compromised further.
I didn't say logging would be compromised, only it would be harder to get a glimpse of existing log entries. Although having thought about this a bit further I'll gladly retract my statements about the binary logging format, since it is possible to have a binary log format that's quite resistant to corruption (eg. one which is ammend-only and doesn't try to be a database with indices etc), and in fact I can see a benefit to it in some ways.
Head_on_a_Stick wrote: ↑Sun May 12, 2019 6:03 amThe rotation that occurs under syslogd is time-based whereas the systemd journal can be configured to limit disk usage to specific amounts.
It is possible to set this up with a shell script that deletes old archives, although I agree there should be an easier way to do it with logrotate.
Head_on_a_Stick wrote: ↑Sun May 12, 2019 6:03 amThere are many problems with syslogd and the systemd journal was designed to overcome the limitations, here is an explanation for those who are interested:
https://docs.google.com/document/pub?id ... UEHIX3MSTs
And anyway on my Debian systems the journal and syslogd both run together so either can be used.
Fantastic, now there are two entirely different logging systems to look at when something goes wrong. Credit where credit is due though, I can see why they would want to make these design decisions, although it appears overengineered (eg. totally random UUIDs for log entries). They like to throw around the "syslogs are not indexed" argument a bit, but I don't see why this is even necessary. It hasn't been necessary for the last 30 years and is probably not going to be necessary in the future. They are log files, after all, and not databases. If your logs become so large that they can't be managed without the log system doing the indexing, perhaps you should read them.
Head_on_a_Stick wrote: ↑Sun May 12, 2019 6:03 amThere is no "fullstop", the boot continues after a 90 second delay. Nice FUD attempt though, well done.
Which is still a waste of 90 seconds. It's not FUD, it's a genuine issue that a genuine user faced, reported, and got told to get stuffed.
The developers' attitudes are a bit concerning too. Here's an example of where a systemd developer tried to make the developer of tmux add systemd-specific code to their program:
https://github.com/tmux/tmux/issues/428
Artim wrote: ↑Sun May 12, 2019 8:14 am
Yup. First it was PulseAudio foisted on everyone, now systemd. I wonder what's next.
Pardon my ignorance, but what was wrong with PulseAudio? Was there something that was better than PulseAudio that was in use before?