Hi Xin and all, > (snip) > Historically, newsyslog compressed rotated log files to save disk space. > This was helpful when storage was limited. However, with modern files > systems like ZFS providing built-in compression and with larger disks > now common, the benefits of additional log compression have diminished, > especially given the inconvenience of needing to decompress logs when > searching for specific patterns. > (snip)
I remember having rebuked these arguments and most of the other ones presented
in a discussion started by commit 2f036705f337 ("Document the two recent
newsyslog(8) change (-c option and <compress> configuration option).") more
than a year ago. The main point of contention was turning the compression off
by default. Re-reading what I wrote, I still find it as spot on as it seemed
at that time. In a nutshell, I developed ample arguments showing why the
benefits of compression for logs far outweigh the drawbacks. In fact, I could
only find one drawback in a very niche scenario where log files would stay big
(i.e., they are not rotated enough/based on size). All other "drawbacks"
reported by you and those wanting the change were very weak at best, and even
sometimes based on plain wrong assumptions (to stay polite).
In a subsequent private message, I was told there would be some followup to my
last mail wrapping up the discussion (dated 2024/01/10), but unfortunately it
never came. Today, browsing D43169, D43466 or even related D42961, I can see
that there are exactly zero new arguments for the need to disable compression
*by default*.
In absence of more elements, I thus stand by the same conclusion as one year
ago: The sensible default is to enable compression (for files marked as
compressible), and for POLA it is probably to stay with 'legacy', so that
compression letters actually mandate the desired compression format. This is
what seems to benefit most uses and users by far.
In other words, this commit should just be reverted.
Surely some people will find that this is a minor change, that we should not
make a fuss about it and just change our configuration file at next update if
we disagree. That would just be missing the point. We are developing and
shipping to users a highly configurable complex system, with lots of moving
parts, automatic tuning mechanisms, configuration files, and admin-tunable
parameters that more often then not are piling up over time. Expecting that
most of our users will have/take the time to review and tweak even a fraction
of them and correctly for their use case seems a delusion to me. They will
just keep running with with essentially the automatically tuned and default
values with some exceptions. Consequently, we should strive to have sensible
defaults, even on minor stuff, as otherwise we keep adding burden on
administrators with all the bad choices/changes we made they have to correct
(if at all possible), not even speaking about more casual users who at some
point will choose to just give up and choose another system.
I would like to encourage a realization in this matter (or a rebuttal if you do
not agree).
I would also like that, at the very least, people have some consideration when
some others spend non-trivial amounts of time reviewing their work and
endorsing the sometimes not-fun role of seriously challenging them for (what
they think is) the greater good, e.g., by responding to well-argued criticism.
For this precise case, I've read all the above-mentioned material (revisions,
commits) and exchanged mails on src-committers@, and sent all my points to the
latter (in January 2024). I certainly don't intend to participate in a rehash
of what has already been said in these venues, that would just be a waste of
time, thank you. But if there are new elements in favor of this change, or if
some of my understanding or arguments were wrong, I'd be glad to hear about
that.
Thanks and regards.
--
Olivier Certner
signature.asc
Description: This is a digitally signed message part.
