On Fri, Feb 23, 2024 at 10:17 PM The Wanderer <wande...@fastmail.fm> wrote: > > On 2024-02-23 at 15:35, Stefan Monnier wrote: > > >>> but what are the advantages of journald's representation compared > >>> to a naive one? > >> > >> in short: querability without text parsing. That's about it. > > > > They have to parse the binary format, so that's not in and of itself > > an upside compared to parsing CSV. > > > > I've made my share of bad design decisions that don't pan out. But > > there's always an upside to my decision (even when it turns out it > > speeds up only those cases which can never occur, because of some > > other aspect of the system). > > > > AFAICT the format is *not* just a plain sequence of log entries, so > > there's some additional structure which is intended to speed up some > > operations. > > > > IOW, even if contrived, there should be *some* use case where it > > does better than CSV, no? > > I can think of two possibilities, just offhand, in no particular order: > > * No need to parse the timestamps, et cetera, and take the risk that > someone put in one that's in a format you don't expect; the times are > stored internally in a consistent guaranteed format, so you can just use > internal reader functions (paired with, and updated alongside, the > internal writer functions) and be done with it. > > * No need to worry about handling log entries that *contain* commas, or > whatever other element was chosen as the separator.
Systemd also provides tamper-resistant logs. The property is often desirable in the enterprise. See Forward Secure Sealing, <https://lwn.net/Articles/512895/>. Jeff