Stefan Monnier wrote: > Makes one wonder why they don't use naive append-only "plain text" logs > (tho with appropriate delimiters (maybe some kind of CSV) to make > searches more reliable than with old-style plain text logs)? > > What are the advantages of journald's representation? > I mean, to justify the slow search and large disk space usage, there is > presumably some upside for some use cases. I can see some weak argument > against Sqlite based on the size of Sqlite, but what are the advantages > of journald's representation compared to a naive one?
systemd's design philosophy, observed from the outside, goes like this: - assume that the machine is a laptop or mobile device that is always changing: moves from network to network, plugs and unplugs devices, goes to sleep and is woken up - disk space is limited, but cpu time is free - the network knows better than local config - all services serve the local user's desktop, primarily - the local user doesn't know anything but can call on a remote sysadmin - systemd is the best at doing anything, so it should do everything. If all of these assumptions match up with your particular use case, systemd is happy. Long-term logs are for servers, so systemd doesn't want them. systemd thinks logs are for finding out what just happened recently. If you wanted long-term logs, obviously you would configure a central repository on some other machine and ship them across the network. I have nothing but praise for the Debian maintainers of rsyslog, who have arranged it so that installing rsyslog immediately does appropriate things to pull data out of systemd. -dsr-
