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
Hi Ingo,
On Nov 29 21:14:24, schwarze@usta.de wrote:
> 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.
would you please kindly consider removing the gz support from mandoc?
The linking is messy, the code needed to support *.gz files is rather
ugly and error-prone, and the (un)compression is unrelated to the
purpose of mandoc in the first place.
Jan
--
To unsubscribe send an email to discuss+unsubscribe@mandoc.bsd.lv
On 11/29/20 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. HAHA!! This is exactly what I expected, down to the T :D And I am not saying this maliciously AT ALL, this is what I my feelings were, albeit on the fence. Just wanted to ask in the off chance that somehow, magically, this was a sane option (its not) :P > >> 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. > These are all perfectly valid reasons and I agree. I agree with not needing this and am totally fine without it :) Thanks a lot! Aisha PS: Would it be possible to get a minor(or whatever) release to address the bug fixes (iirc html fixes were some) and building with gcc-10 ? > Yours, > Ingo > -- To unsubscribe send an email to discuss+unsubscribe@mandoc.bsd.lv
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