On 2/4/20 8:30 PM, Russ Allbery wrote: > Dmitry Smirnov <only...@debian.org> writes: >> On Saturday, 1 February 2020 2:05:55 PM AEDT Michael Biebl wrote: > >>> Depending on how it goes, I might ask the ftp-masters to lower the >>> priority of rsyslog from important to optional, so it would no longer >>> be installed by default on new bullseye installations. > >> I have a mixed feelings about that. I think that replacing rsyslog with >> journald is two steps back in regards to functionality and flexibility. > >> Rsyslog in unparalleled with its ability to process and filter messages >> (rainerscript), to transform messages (liblognorm), to forward messages >> to Elasticsearch or centralise Rsyslog instance, _reliably_ (relp), to >> buffer message queue on disk in case communication is disrupted, etc. > > I completely agree with this assessment of the quality of rsyslog > features, but I'm not sure that's the right criteria to be considering for > the choice of the *default*. I'm fairly certain that 95% or more of > installed Debian systems never used any of those features, as nice as they > are. > > The goal of the default is not to provide in latent form every excellent > feature that anyone may want to use. It's to provide a hopefully simple, > reliable, functional, and light-weight implementation of a facility that > serves as a reasonable default for most systems. Anyone with other needs > or preferences is very likely to replace or supplement that implementation > with something else, similar to how I replace exim4 with postfix on all of > my systems.
I'm ok with this reasoning, however, rsyslogd is also a reasonable default, and I don't see why it wouldn't be good for the general use also. The main problem with journald is that it can't keep-up with too much syslog traffic and doesn't scale. I'd very much prefer if our default was a solution that works on *all* cases, rather than just the one for a specific target. Cheers, Thomas Goirand (zigo)
