From mboxrd@z Thu Jan 1 00:00:00 1970 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, NICE_REPLY_A autolearn=no autolearn_force=no version=3.4.4 Received: (qmail 32703 invoked from network); 29 Nov 2020 22:25:10 -0000 Received: from bsd.lv (HELO mandoc.bsd.lv) (66.111.2.12) by inbox.vuxu.org with ESMTPUTF8; 29 Nov 2020 22:25:10 -0000 Received: from fantadrom.bsd.lv (localhost [127.0.0.1]) by mandoc.bsd.lv (OpenSMTPD) with ESMTP id daa87263 for ; Sun, 29 Nov 2020 17:25:00 -0500 (EST) Received: from sender4-of-o52.zoho.com (sender4-of-o52.zoho.com [136.143.188.52]) by mandoc.bsd.lv (OpenSMTPD) with ESMTP id 1cf2344a for ; Sun, 29 Nov 2020 17:25:00 -0500 (EST) ARC-Seal: i=1; a=rsa-sha256; t=1606688697; cv=none; d=zohomail.com; s=zohoarc; b=b6jz5+qQAl7Rbkg7Mi+uOvXGEnxfgyKIIZ8qURAGfq8OQBoDxARskYdCk+Ev0glldZ3TP05BnhyWLig6CMtE4sevH7b/orhNDXf9TrID472FYXA6/ghPm6ZOVo6FnzfBiBRdGC7ZN8PhHRrYUYBZDARIqOJ0vW8mIvtv3NlB7sc= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1606688697; h=Content-Type:Content-Transfer-Encoding:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To; bh=xXC+siVcTlk6ISfNswtVNAw+A7EMNB/eutNf+vSV+MY=; b=TVF6cQcyktTNUgusaqVmUTC2rKeHbgb8VwYS6wFm5sE29nrQEZW78jgAaKR711X6zJtx2oZg5QMxu8X4LctJ0gjDex3kpTH7Np8drVk9VJcIg/Kn6BGl9L/arzIccGmkqhgr/UBFJ5YiV8eSyG4IMpzUE6yOjHuI6I0pqPQIhhc= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass header.i=irixnet.org; spf=pass smtp.mailfrom=kazuo@irixnet.org; dmarc=pass header.from= header.from= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1606688697; s=default; d=irixnet.org; i=kazuo@irixnet.org; h=Subject:To:References:From:Message-ID:Date:MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding; bh=xXC+siVcTlk6ISfNswtVNAw+A7EMNB/eutNf+vSV+MY=; b=DU8WIBz5zEqsdfv1SGBNs/E8vDDyW0pmPXqvAZFGBWfGPUK/oM+rCtskG55z3RHQ DKpReJaU7BbO+qJ9gRub8J0UdTR5Q9J3I/IPRJDrRHY77GlafvuC/eNFm7n5iZnkzro MdenhHKjqkYzOcLseacHCTyI0qcV6GMevCAhJ8UQ= Received: from [192.168.1.103] (d-209-42-150-19.md.cpe.atlanticbb.net [209.42.150.19]) by mx.zohomail.com with SMTPS id 1606688694770132.86010768777987; Sun, 29 Nov 2020 14:24:54 -0800 (PST) Subject: Re: Possible to add optional bzip2 support? To: discuss@mandoc.bsd.lv References: <20201129201424.GI58187@athene.usta.de> From: Kazuo Kuroi Message-ID: <0eec02d8-a6fd-bf85-8334-e7467c203701@irixnet.org> Date: Sun, 29 Nov 2020 17:24:51 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 X-Mailinglist: mandoc-discuss Reply-To: discuss@mandoc.bsd.lv MIME-Version: 1.0 In-Reply-To: <20201129201424.GI58187@athene.usta.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-ZohoMailClient: External I'm not party to this discussion directly, but if we're discussing compression methods, maybe a completely different (simple, clean to implement) compression method is called for to replace both bzip and gzip in this capacity? I dunno. That's just my POV from the outside in. LZ4 perhaps? That's OpenBSD-compatible license-wise, though I know Theo is very much a bit of a curmudgeon on things like this. Shrug. I hope a compromise can be achieved. On 11/29/2020 3:14 PM, Ingo Schwarze wrote: > Hi Aisha, > > Aisha Tammy wrote on Sun, Nov 29, 2020 at 10:37:44AM -0500: > >> I'm trying to get Gentoo to add mandoc as an alternative man provider >> as an optional replacement for the current man-db. Currently, we only allow >> man-db as the man provider. I've successfully managed to get the changes >> and have already made the PR (hopefully, barring anything extra ordinary, it >> should go through). > Nice, thanks. > >> Currently, we compress all our man pages with bzip2 by default > Why? > > Compressing manual pages makes absolutely no sense to me in 2020. > > This is on one of my desktop machines where i have large amounts of > cruft installed for testing: > > $ du -sh /usr/share/man /usr/X11R6/man /usr/local/man > 41.8M /usr/share/man > 9.0M /usr/X11R6/man > 69.9M /usr/local/man > > Here are a few other directories for comparison: > > 88.3M /usr/local/share/emacs > 71.2M /usr/local/share/gtk-doc > 209M /usr/local/share/doc > 273M /usr/local/share/locale > 209M /usr/local/lib/firefox > 218M /usr/local/lib/thunderbird > 609M /usr/local/lib/libreoffice > > So all the manual pages on a system, even if they are uncompressed > and even if a lot of stuff is installed, typically need a small > fraction of the space needed by a single modern application program. > > Asked the other way around, who cares, in 2020, about 0.05 GB of disk > space on the /usr/ partition? Or even, when installing insane amounts > of optional software, about maybe 0.2 or so GB? > > How are such totally negligible gains worth any kind of trouble? > > Sometimes, people told me "but we want to install unchanged on > embedded systems and there 50 MB are a big deal". I have a hard > time believing that. If a given embedded system really has trouble > with disk space for 50 MB of manual pages, then it is virtually > certain that you cannot install a modern general-purpose operating > system to it without changes in the first place. And it almost > certainly isn't a system where users want to log in interactively > and read manual pages. > >> and none of them are usable with mandoc, a small amount of scripting >> is needed to recompress all man pages and this also messes up the >> package manager and over all is a bit ugly. I am unsure how bad/hard >> it is to add bzip2 support but is there any hope of it being >> added as an option? even if it is not available by default? > It would be easier to convince me to delete *.gz support than to > add *.bz2 support. Either is unrelated to the purpose of mandoc > and linking to zlib is ugly and messy, i'd love to get rid of the > dependency and of the rather ugly and error-prone code needed to > support *.gz files. > > Regarding *.bz2 in particular, i see very little chance to get > /usr/lib/libbz2.so.*.* added to the OpenBSD base system. > > Regarding options, i think options are evil in general. If you > want an option, you need very good arguments why the feature is > useful to such an ususual degree that it justifies an option. > Here, i don't see any benefit at all to offset the cost in > dependencies, complexity, and maintenance. > > Yours, > Ingo > -- > To unsubscribe send an email to discuss+unsubscribe@mandoc.bsd.lv > -- To unsubscribe send an email to discuss+unsubscribe@mandoc.bsd.lv