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

- systemd is the best at doing anything, so it should do

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.


Reply via email to