Hacker News Reader

Comment by surajrmal | Hacker News Reader

Lennart pointed out the fact you can see readable messages via strace to be a benefit of json. If their average message size is small and they don't expect to ever need high volume or large messages, then it's not really likely to be a problem in practice. He also pointed out that they waste far more cycles today on context switches (he suggested something on the order of 6 per IPC message).

Even if they eventually come to the conclusion they need something more performant in the future, it's probably still a net win to make the switch today. It's also possible it turns out fine for their use case.

I personally would think they would want to benefit from an IPC system that includes provisions for sending file descriptors.

View on HN

> Lennart pointed out the fact you can see readable messages via strace to be a benefit of json.

from the guy who brought you binary logfiles!

One can view the binary log files using journalctl.

Per https://systemd.io/JOURNAL_FILE_FORMAT/, the benefits of the binary format are:

The systemd journal stores log data in a binary format with several features:

Fully indexed by all fields

Can store binary data, up to 2^64-1 in size

Seekable

Primarily append-based, hence robust to corruption

Support for in-line compression

Support for in-line Forward Secure Sealing

As a user system-administrator, I see the cryptographic checksum as a benefit of being able to show tampering evidence of on-system log files.

> Primarily append-based, hence robust to corruption

It's so robust, it doesn't even let you modify the journal if you want to (e.g. https://github.com/systemd/systemd/issues/20673).

> Support for in-line compression

Mind that journald only supports compressing single lines, but not the whole journal (https://github.com/systemd/systemd/issues/31358), which is pretty limiting.

Modifying the existing journal really sounds like the wrong solution. Just "journalctl --rotate" the file and throw out the one with accidental PII. Journal files are not great for long-term storage or search. You can export the old file and filter out manually if you really want to preserve that one https://www.freedesktop.org/wiki/Software/systemd/export/

In what situations is it a harder problem than this?

In sicily we'd call this "vuliri a vutti china e a mugghieri 'mbriaca".

It's a tradeoff, if you do full compression clearly it won't be fast.

You're free to compress it again before archiving it.

> Primarily append-based > Seekable

Text logs are append-based and seekable as well.

> Support for in-line Forward Secure Sealing

I once typed an SSH password in the username field, and the only way to erase that was to erase all the logs. So this has some significant downsides.

Also, I am tired of waiting minutes for a journalctl query to load.

> I once typed an SSH password in the username field, and the only way to erase that was to erase all the logs. So this has some significant downsides.

I hope this was a personal system. Changing logs in this manner would have almost certainly led to your dismissal anywhere I ever worked. This anecdote just re-enforces the need for Forward Secure Sealing.

No, I just left it there.

Can't win huh

Reply on news.ycombinator.com