From: Ingo Schwarze <schwarze@usta.de>
To: Maxim Cournoyer <maxim.cournoyer@gmail.com>
Cc: Soeren Tempel <soeren@soeren-tempel.net>, discuss@mandoc.bsd.lv
Subject: Re: zstd compression
Date: Fri, 31 Jan 2025 13:43:23 +0100 [thread overview]
Message-ID: <Z5zFa/xV4GimVs9M@asta-kit.de> (raw)
In-Reply-To: <87v7tvoiqu.fsf@gmail.com>
Hello Maxim,
Maxim Cournoyer wrote on Fri, Jan 31, 2025 at 10:49:13AM +0900:
> I researched the question shortly, and unless I'm missing something, the
> Zstd documentation currently suggests to add the few source files to the
> project
Right. That's an extremely foolish recommendation.
Are they expecting me to perform a complete source code audit
of their files? Not realistic, i would say.
Are they expecting me to include unaudited third-party code
into my repository? Not realistic, either.
What if a vulnerability is found in one of these files?
Suddenly large numbers of completely unrelated projects
that included these files have to make urgent security releases?
That way lies madness, it's completely unsustainable.
> and weave them in the build [0]; the zlibWrapper Makefile also
> doesn't currently have a target to build a shared library. I've created
> a feature request in the Zstd project to see if they'd consider adding a
> proper shared library for zlibWrapper [1].
> [0] https://github.com/facebook/zstd/blob/dev/zlibWrapper/README.md
> [1] https://github.com/facebook/zstd/issues/4277
Thank you for opening the ticket! :-)
I have added a comment to improve the chances that they understand
why this matters.
> it feels like good hygiene to shave a bit of disk space usage
> where possible,
I think here we can happily agree to disagree. I consider it good
hygiene to shave a bit of complexity where possible, and where
adding complexity would not provide any relevant benefit.
> especially if it's transparent to users (which it is).
It is not transparent to users. While i use apropos(1) more frequently
than grep(1) on manual pages, i sometimes do run commands like
# look for mdoc(7) pages with strangely formatted line macro
grep -R '^\. *[A-Z][a-z]' /usr/share/man
# look for man(7) pages with strangely formatted line macro; finds a few
grep -R '^\. *[A-Z][A-Z]' /usr/share/man
# look for a typical typo; needs fulltext search, cannot use semantic search
grep -RF 'the the' /usr/share/man
You could argue that i could use zgrep(1) instead, but that's certainly
and pointlessly complicating the user experience.
Yours,
Ingo
--
To unsubscribe send an email to discuss+unsubscribe@mandoc.bsd.lv
prev parent reply other threads:[~2025-01-31 12:43 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-28 7:10 Sören Tempel
2025-01-28 10:40 ` Ingo Schwarze
2025-01-29 23:36 ` Alexis
[not found] ` <87wmeep1wj.fsf@gmail.com>
2025-01-30 9:59 ` Ingo Schwarze
[not found] ` <87v7tvoiqu.fsf@gmail.com>
2025-01-31 12:43 ` Ingo Schwarze [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Z5zFa/xV4GimVs9M@asta-kit.de \
--to=schwarze@usta.de \
--cc=discuss@mandoc.bsd.lv \
--cc=maxim.cournoyer@gmail.com \
--cc=soeren@soeren-tempel.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).