discuss@mandoc.bsd.lv
 help / color / mirror / Atom feed
From: Kazuo Kuroi <kazuo@irixnet.org>
To: discuss@mandoc.bsd.lv
Subject: Re: Possible to add optional bzip2 support?
Date: Sun, 29 Nov 2020 17:24:51 -0500
Message-ID: <0eec02d8-a6fd-bf85-8334-e7467c203701@irixnet.org> (raw)
In-Reply-To: <20201129201424.GI58187@athene.usta.de>

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


      parent reply	other threads:[~2020-11-29 22:25 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <d5e55c57-002a-e654-b7c2-dca9fb84863d@aisha.cc>
2020-11-29 20:14 ` Ingo Schwarze
2020-11-29 21:07   ` Jan Stary
2020-11-29 21:41   ` Aisha Tammy
2020-11-29 22:24   ` Kazuo Kuroi [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=0eec02d8-a6fd-bf85-8334-e7467c203701@irixnet.org \
    --to=kazuo@irixnet.org \
    --cc=discuss@mandoc.bsd.lv \
    /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

discuss@mandoc.bsd.lv

This inbox may be cloned and mirrored by anyone:

	git clone --mirror http://inbox.vuxu.org/mandoc-discuss

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 mandoc-discuss mandoc-discuss/ http://inbox.vuxu.org/mandoc-discuss \
		discuss@mandoc.bsd.lv
	public-inbox-index mandoc-discuss

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.mandoc.discuss


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git