Re: git: 83507f9e6fed - main - newsyslog(8): Disable compression by default in newsyslog.conf.

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