From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.4 Received: from mandoc.bsd.lv (bsd.lv [66.111.2.12]) by inbox.vuxu.org (Postfix) with ESMTP id 14D8821803 for ; Fri, 31 Jan 2025 13:43:28 +0100 (CET) Received: from fantadrom.bsd.lv (localhost [127.0.0.1]) by mandoc.bsd.lv (OpenSMTPD) with ESMTP id 2e00e6ce for ; Fri, 31 Jan 2025 12:43:26 +0000 (UTC) Received: from scc-mailout-kit-01.scc.kit.edu (scc-mailout-kit-01.scc.kit.edu [129.13.231.81]) by mandoc.bsd.lv (OpenSMTPD) with ESMTP id 2607c1b2 for ; Fri, 31 Jan 2025 12:43:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=usta.de; s=kit1; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject :Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=iDA59zmFWCnT6BrzR9fNiDubTViJOlwCpAmhf8cKNlc=; b=pcWw+HU8elZd0noy7SHfbfrLtG n1DJc4yE36SjbP/wqJj0zmoooaq+ipbio4FO9m4coRv4SJouqULXsmtia4Fj3vbR+yigOT7SIR+Ih TcVu7F3EmQlTDtCSFQQ2tqe0xRpiDXKqFZFN4toTKmtDmJdoVwITDz+9d1aVmU10n++YPaeC8CVxw kTdJ4RRKu2yKmAmAKShLT7lnVQOdQVjNiqHbHN0QmOtiwKykxas3+e9HqpOvHrFb1eWTdO1qgC5xm AbBQ2eh3L7B2bfpQA7IH/T9eCWW/qLHsVVkPcZEV7pvk4EXSxJcvTeqxX5QBSslnfzJczaVw/SW/t lzAxvorw==; Received: by scc-mailout-kit-01.scc.kit.edu with esmtps (TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (envelope-from ) id 1tdqMn-000IDy-06; Fri, 31 Jan 2025 13:43:25 +0100 Received: from login-1.asta.kit.edu ([2a00:1398:5:f400::72]) by hekate.asta.kit.edu with esmtp (Exim 4.94.2) (envelope-from ) id 1tdqMl-009MKw-TZ; Fri, 31 Jan 2025 13:43:23 +0100 Received: from schwarze by login-1.asta.kit.edu with local (Exim 4.94.2) (envelope-from ) id 1tdqMl-005kYx-Ek; Fri, 31 Jan 2025 13:43:23 +0100 Date: Fri, 31 Jan 2025 13:43:23 +0100 From: Ingo Schwarze To: Maxim Cournoyer Cc: Soeren Tempel , discuss@mandoc.bsd.lv Subject: Re: zstd compression Message-ID: References: <3T0GC5KH2QOJE.3MWZ01GDN6VSI@8pit.net> <87wmeep1wj.fsf@gmail.com> <87v7tvoiqu.fsf@gmail.com> X-Mailinglist: mandoc-discuss Reply-To: discuss@mandoc.bsd.lv MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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