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 9C17020D6C for ; Thu, 30 Jan 2025 10:59:44 +0100 (CET) Received: from fantadrom.bsd.lv (localhost [127.0.0.1]) by mandoc.bsd.lv (OpenSMTPD) with ESMTP id c55222ad for ; Thu, 30 Jan 2025 09:59:44 +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 c8eb0b75 for ; Thu, 30 Jan 2025 09:59:43 +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=Rs4yTsHDqVOpJ/5RGg9XHe12BNSB06dEXfe9W8oziPk=; b=L5XEjp1468Z46GL0i+1n/SvGF5 pwjI6i13DEyIAQJTROIy/Ydwn7TItycbXdQXykZJ61/O/AStpWoHKJX22haZM5QPrOzI5yWDBBm/n aBBLzQbXSLFSjPf2C3+VpQXc2suc6m7BN7/sB/q/en4YIzB9m0ZzigAdpyM89qiNpCwf/pR2Amwst SkA4jddNkD9pNv9bDiURYffHKH02OiT6Jhn7VixJc2xaGw3TR4vZzRFosRN+7pMI+yfPJ/vWngJZM 0ocKXeTStZp0zfCY4WqhVxyGHZZ15QtlsfTaqVIH403P4bngENCyffcADruwu9pyyjqCDP04pSJjx PAejUi5Q==; 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 1tdRKo-00DaNT-23; Thu, 30 Jan 2025 10:59:43 +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 1tdRKn-009Dnh-Qb; Thu, 30 Jan 2025 10:59:41 +0100 Received: from schwarze by login-1.asta.kit.edu with local (Exim 4.94.2) (envelope-from ) id 1tdRKn-005Xbs-BK; Thu, 30 Jan 2025 10:59:41 +0100 Date: Thu, 30 Jan 2025 10:59:41 +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> 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: <87wmeep1wj.fsf@gmail.com> Hello Maxim, thanks for explaining. I see, "Guix System" is also an operating system, which is not immediately obvious from the web page (but only becomes clear after following the "about" link). I now also understand that some steps have been taken to mitigate some of the security implications of the fundamental concept. It all sound extremely complicated, which is usually not very good for security - then again, this is probably the usual tradeoff that every system has to make: OpenBSD leans towards security and simplicity, Guix appears to lean more towards fancy features at the expense of significant complication. Anyway, i have now added Guix here: http://mandoc.bsd.lv/ports.html # three place: overview, packages, maintenance http://mandoc.bsd.lv/porthistory.html # two entries Maxim Cournoyer wrote on Wed, Jan 29, 2025 at 03:30:52PM +0900: > Ingo Schwarze wrote: >> I feel serious tempted to rip out compression support altogether. >> It's just so anachronistic. > It costs relatively little in complexity, As long as only one compression format is required, the complexity is moderate, and that contributed to not being ripped out yet. It gets worse when different systems require different compression. Let's wait for Soeren - if he manages to get the compat lib installed as a shared object, then i can do the zstd thing in the upstream repo as explained earlier, with the (small) additional complexity confined to the configuration system, without invading the code. [...] > That's a 50 MiB space saving, which while not enormous is not nothing > either, especially on a transactional system like Guix where you may be > keeping multiple past versions of things with the space usage adding up. OK, let's assume the worst: every user installs all the packages you have on your system, but in such a way that no two users install the same version of any package. Then it boils down to 50 MiB per user, which i would indeed call "nothing". I mean, a few lines above, you talked about making it easy fur users to compile chromium. Compared to that, 50 MiB is absolutely nothing indeed. I think you can safely assume every user does at least *something* that requires space in amounts typical for the 2020ies, and compared to that, 50 MiB is nothing. Or look at it the other way: how many users do you have on your machine? Two hundred, maybe? In that case, you gain 10 GB. On which modern machine that serves hundreds of users do 10 GB of disk space matter? Yours, Ingo -- To unsubscribe send an email to discuss+unsubscribe@mandoc.bsd.lv