Re: Proposal to remove catman(8)
On Nov 10, 1:13, Kamil Rytarowski wrote: } On 10.11.2020 01:05, Paul Goyette wrote: } > On Tue, 10 Nov 2020, Kamil Rytarowski wrote: } > } > } >> } >> It's not a selling point to any regular user, born after A.D. 2000 to } >> optimize reading man pages. } > } > Whoa there.=C2=A0 Don't put down us older folks.=C2=A0 And why would you want } > to characterize "regular user" as being "not yet two decades old" ? } } Please relax. I'm older too. The point is with the target audience, e.g. } our GSoC students (who born around A.D. 2000) might not be attracted by } retro-computing, by things that passed away before their date of birth. Overhauling the system to make it attractive to GSOC students is bizarre to say the least. That is a tiny audience and specifically catering to it at the expense of the main audience is not wise. }-- End of excerpt from Kamil Rytarowski
Re: Proposal to remove catman(8)
On 10.11.2020 01:18, Mouse wrote: >>> [...] >> It's not a selling point to any regular user, born after A.D. 2000 to >> optimize reading man pages. > > (a) So what? Neither, I daresay, is, oh, say, fpr, which is still > present in 9.1 > We might want to see fortran back. I have got no particular opinion on fpr. We still keep some cruft in src/ that predates... section 9 in man-pages and was probably never used ever since NetBSD-0.8 (otherwise it could be adapted). I planned to ask wiz@ to drop that. > (b) Are those the only people NetBSD cares about? Or the only people > you think it should care about, or some such? > Are you a user of NetBSD-current with cat-man? As I read your mail, the answer is NO. Do you plan to use recent NetBSD (10 or newer) on a resource restricted computer? As far as I can read it, the answer is NO. So far no user was witnessed in any target audience and unlikely it will change over time. signature.asc Description: OpenPGP digital signature
Re: Proposal to remove catman(8)
>> [...] > It's not a selling point to any regular user, born after A.D. 2000 to > optimize reading man pages. (a) So what? Neither, I daresay, is, oh, say, fpr, which is still present in 9.1 (b) Are those the only people NetBSD cares about? Or the only people you think it should care about, or some such? /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: Proposal to remove catman(8)
On 10.11.2020 01:05, Paul Goyette wrote: > On Tue, 10 Nov 2020, Kamil Rytarowski wrote: > > >> >> It's not a selling point to any regular user, born after A.D. 2000 to >> optimize reading man pages. > > Whoa there. Don't put down us older folks. And why would you want > to characterize "regular user" as being "not yet two decades old" ? > Please relax. I'm older too. The point is with the target audience, e.g. our GSoC students (who born around A.D. 2000) might not be attracted by retro-computing, by things that passed away before their date of birth. The target audience of people needing cat-pages is getting extinct. signature.asc Description: OpenPGP digital signature
Re: Proposal to remove catman(8)
On Tue, 10 Nov 2020, Kamil Rytarowski wrote: It's not a selling point to any regular user, born after A.D. 2000 to optimize reading man pages. Whoa there. Don't put down us older folks. And why would you want to characterize "regular user" as being "not yet two decades old" ? ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: Proposal to remove catman(8)
On 09.11.2020 21:46, Robert Elz wrote: > Date:Mon, 9 Nov 2020 19:05:23 +0100 > From:Kamil Rytarowski > Message-ID: <04c9e1ad-df4e-1372-74d3-a17fdd5dd...@netbsd.org> > > | I propose to remove catman(8). > > Don't. Do you use it? Do you know anybody who uses it on NetBSD-current? I don't trust that these people are tracking or using -current that used to have broken MKCATPAGES. > > | - cat pages are not generated by default since 2012 and almost nobody > | (except me?) used them in the past few years. > > That's fine, and I have no problem with the removal of MKCATMAN (or > whatever the build.sh/make variable was). That makes one less variation > that needs to be tested, and the need to remember to include the .catN > entries in the sets lists. I'd support removing the generation of > html format as well for exactly the same reasons. In both cases anyone > who finds these formats useful (including the man pages on www.netbsd.org) > can easily still generate them. > html pages are not integrated in man.conf(5) or man(1). cat pages are integrated and preferred over man pages. > I doubt that you really know (or can possibly know) who uses anything though. > Sorry, but MKCATPAGES was constantly broken AFAIR even in releases until I stepped in. > | - This tool was removed from other BSDs by default and catman is not a > | part AFAICT of any Unix specification. > > That's irrelevant. catman isn't the only application we have that > no-one else has. > It's not a selling point to any regular user, born after A.D. 2000 to optimize reading man pages. > | - Passing the documentation through mandoc(1) enables dynamic > | customization, while cat(1) cannot do much or anything as it operates on > | pre-generated .txt files. > > All true, but irrelevant. If someone needs/desires the customisation, > they they run mandoc (or even nroff, or troff) and they can do whatever > they like. People who are happy with pre-formatted man pages can use > them. What's the harm? > Reduce dead cruft. Compatibility with other systems and reduce frustration of users (I've received the complains) who are forced to hack the default install and/or tools to behave like intended. > | Personally. I recall cat-pages to be relevant on Coherent 80286 > | UNIX-like OS, operating in real mode. > > I recall them when they were first introduced - and I can assure you that > attempting to have 20 or more people all attempting to run nroff on a 780 > (simultaneously) is no fun. 20 people running cat is unnoticeable. > OK. I would be happy to know a current vax780 setup used simultaneously by 20 people on NetBSD-current who read use it for reading the man pages. > | Next, I propose to remove cat-man support from man(1) and man,conf(5). > > Please don't, what's the point? > > I really do not understand the desire to race around removing things. > That you don't see any use for them, doesn't mean that someone else > doesn't. Sorry to repeat, but as MKCATPAGES was constantly broken, unless I committed changes in the past ~5 years, nobody used that any more on anything, possibly in more than a decade. > Stuff that is broken, and can't easily be fixed, or which > needs external resources which are no longer available can be removed. cat pages cannot be fixed easily. If someone wants to pass them through mandoc and reformat, I would consider it as a waste of time. > Stuff which simply seems old, and perhaps not used as much as it once > was should just be left alone. > Being old is not the concern, but being non-trivial for reformatting. I prefer to avoid FreeBSD-style hacks that silently disable cat pages behind the scenes. Better option in 2020 is to just forget them entirely. > I suspect that there are much better things that you could be spending > time on than this kind of thing. > Introducing features that utilize mandoc, but the first step is to drop cat-pages put their feet in the door. Preformatting cat pages is a dead concept. > kre > I remind you that we already reduce unused features from our userland. For example patch(1) had removed SCCS support silently, and nobody noticed this until today. I claim that cat-pages are way less useful than SCCS-styled patches. I sense a general difference in the view point. We are apparently trading better performance on a historical computer in possibly non-existent setup anymore in two or more decades + frustrating users vs good user experience on anything modern, customizable and compatible with other OSs. But then, it's possible to keep old catman and catpages for those who want it and defer this to pkgsrc. Do I fulfill the needs of these extinct users by this move? signature.asc Description: OpenPGP digital signature
Re: Proposal to remove catman(8)
On Mon, Nov 09, 2020 at 21:12:10 +0100, Tobias Nygren wrote: > mandoc is used for everything that is in pkgsrc. For example: > $ mandoc /usr/pkg/man/man1/bash.1 | more > > If you want to make the argument that it cannot render certain > third-party manual pages in way that makes the content intelligible you > must back it up with an actual example where the third-party software Well, we don't even have to go to pkgsrc. E.g. groff_char(7) is mangled by mandoc :) But this is actually irrelevant, b/c mandoc(1) is not hardcoded in man(1). The choice of formatter is down to man.conf(5) and people can still configure nroff as their man page formatter. Or is that the next thing you are going to take away? > ships a catpage. There are only 50 or so packages left that even ship > catpages. This is also irrelevant. This doesn't have anything to do with whether packages do and don't ship cat pages. If someone uses cat pages they likely have a catman(8) invocation in their weekly or daily cron job. kre@ has already expressed it better than I could ever hope, so please, can we stop this silly crusade? How does catman(8) gets in the way of someone who does NOT use cat pages? Also, please revert the commit that removed the cat directories from the tree. This is overstepping the limits of the initial MKCATPAGES proposal. -uwe
Re: Proposal to remove catman(8)
>> $ mandoc /usr/pkg/man/man1/bash.1 | more > or even just man /usr/pkg/man/man1/bash.1 > although I'm not sure when this was introduced; I'm pretty sure it > didn't always work. It didn't. Trying it on my machines, it works (well, not with that exact path, but with a different path to a manpage source file) on 5.2 but not on 1.4T. (And 5.2 predates mandoc(1).) /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: Proposal to remove catman(8)
Date:Mon, 9 Nov 2020 19:05:23 +0100 From:Kamil Rytarowski Message-ID: <04c9e1ad-df4e-1372-74d3-a17fdd5dd...@netbsd.org> | I propose to remove catman(8). Don't. | - cat pages are not generated by default since 2012 and almost nobody | (except me?) used them in the past few years. That's fine, and I have no problem with the removal of MKCATMAN (or whatever the build.sh/make variable was). That makes one less variation that needs to be tested, and the need to remember to include the .catN entries in the sets lists. I'd support removing the generation of html format as well for exactly the same reasons. In both cases anyone who finds these formats useful (including the man pages on www.netbsd.org) can easily still generate them. I doubt that you really know (or can possibly know) who uses anything though. | - This tool was removed from other BSDs by default and catman is not a | part AFAICT of any Unix specification. That's irrelevant. catman isn't the only application we have that no-one else has. | - Passing the documentation through mandoc(1) enables dynamic | customization, while cat(1) cannot do much or anything as it operates on | pre-generated .txt files. All true, but irrelevant. If someone needs/desires the customisation, they they run mandoc (or even nroff, or troff) and they can do whatever they like. People who are happy with pre-formatted man pages can use them. What's the harm? | Personally. I recall cat-pages to be relevant on Coherent 80286 | UNIX-like OS, operating in real mode. I recall them when they were first introduced - and I can assure you that attempting to have 20 or more people all attempting to run nroff on a 780 (simultaneously) is no fun. 20 people running cat is unnoticeable. | Next, I propose to remove cat-man support from man(1) and man,conf(5). Please don't, what's the point? I really do not understand the desire to race around removing things. That you don't see any use for them, doesn't mean that someone else doesn't. Stuff that is broken, and can't easily be fixed, or which needs external resources which are no longer available can be removed. Stuff which simply seems old, and perhaps not used as much as it once was should just be left alone. I suspect that there are much better things that you could be spending time on than this kind of thing. kre
Re: Proposal to remove catman(8)
On Mon 09 Nov 2020 at 21:12:10 +0100, Tobias Nygren wrote: > mandoc is used for everything that is in pkgsrc. For example: > $ mandoc /usr/pkg/man/man1/bash.1 | more or even just man /usr/pkg/man/man1/bash.1 although I'm not sure when this was introduced; I'm pretty sure it didn't always work. -Olaf. -- Olaf 'Rhialto' Seibert -- rhialto at falu dot nl ___ Anyone who is capable of getting themselves made President should on \X/ no account be allowed to do the job. --Douglas Adams, "THGTTG" signature.asc Description: PGP signature
Re: Proposal to remove catman(8)
On Mon, 9 Nov 2020 14:12:19 -0500 (EST) Mouse wrote: > As for mandoc(1), I haven't looked at it...but I question how well it > can work. While I don't see them often, I do occasionally see manpages > (for third-party software, to be sure[%]) containing code that looks to > me like small bits of *roff hackery. To make mandoc support such > things properly would have to amount to reimplementing nroff; the > alternative is to "oh, yeah, our man(1) doesn't really understand > nroff, only the markup *our* manpages use, sorry, it won't handle your > manpage that elsewhere, and historically, works just fine". > > [%] Nothing in the OS, of course. And nothing of my own; I don't > really know nroff/troff, so I'm not competent to drop down into it > when writing manpages. mandoc is used for everything that is in pkgsrc. For example: $ mandoc /usr/pkg/man/man1/bash.1 | more If you want to make the argument that it cannot render certain third-party manual pages in way that makes the content intelligible you must back it up with an actual example where the third-party software ships a catpage. There are only 50 or so packages left that even ship catpages. -Tobias
Re: Proposal to remove catman(8)
Please do. Thank you. Le lun. 9 nov. 2020 à 19:09, Kamil Rytarowski a écrit : > > I propose to remove catman(8). > > The removal of all cat-man remnants was already implied during the > proposal of drop MKCATPAGES, but it apparently was not clear enough. > > Rationale: > - cat pages are not generated by default since 2012 and almost nobody > (except me?) used them in the past few years. > - This tool was removed from other BSDs by default and catman is not a > part AFAICT of any Unix specification. > - Passing the documentation through mandoc(1) enables dynamic > customization, while cat(1) cannot do much or anything as it operates on > pre-generated .txt files. > > Personally. I recall cat-pages to be relevant on Coherent 80286 > UNIX-like OS, operating in real mode. > > Next, I propose to remove cat-man support from man(1) and man,conf(5). > > Patch minimum for man(1)/man.conf(5): > > http://netbsd.org/~kamil/patch-00286-stop-using-cat-dirs.txt > > Patch optimum is to remove the support for "_crunch", "_suffix" and > eliminate all cat-man remnants from man.conf and man(1). >
Re: Proposal to remove catman(8)
> I propose to remove catman(8). > [and all other forms of support for preformatted manpages] Personally, I would consider that a mistake. The major use I make of them - besides speed - is reading manpages out of a directory in some unexpected corner of the filesystem. I have found it far easier to "less /some/where/unexpected/program.cat1" than to try to bludgeon man(1) into understanding that there are manpages over in /some/where/unexpected. As for mandoc(1), I haven't looked at it...but I question how well it can work. While I don't see them often, I do occasionally see manpages (for third-party software, to be sure[%]) containing code that looks to me like small bits of *roff hackery. To make mandoc support such things properly would have to amount to reimplementing nroff; the alternative is to "oh, yeah, our man(1) doesn't really understand nroff, only the markup *our* manpages use, sorry, it won't handle your manpage that elsewhere, and historically, works just fine". [%] Nothing in the OS, of course. And nothing of my own; I don't really know nroff/troff, so I'm not competent to drop down into it when writing manpages. > - cat pages are not generated by default since 2012 and almost > nobody (except me?) used them in the past few years. 2012? The only reason I haven't noticed and complained about this is that (a) I don't run anything past 5.2 on my own machines and (b) at work, where we use 8.0 and 9.1, we run them on grossly overmuscled machines where the reformatting penalty is small enough to not be a major problem. I suppose this just means that modern NetBSD is, in yet another way, demonstrating inappropriateness for the kind of tasks I want an OS for. > - This tool was removed from other BSDs by default and catman is not > a part AFAICT of any Unix specification. "All the other kids are doing it" has got to be one of the worst reasons to do anything. IMO the propsal should be considered on its merits, not on its popularity. > - Passing the documentation through mandoc(1) enables dynamic > customization, while cat(1) cannot do much or anything as it > operates on pre-generated .txt files. I don't know what kind of "dynamic customization" you have in mind, but in my limited exposure to other man(1) implementations, my concern with such things has generally been how to turn them off. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Proposal to remove catman(8)
I propose to remove catman(8). The removal of all cat-man remnants was already implied during the proposal of drop MKCATPAGES, but it apparently was not clear enough. Rationale: - cat pages are not generated by default since 2012 and almost nobody (except me?) used them in the past few years. - This tool was removed from other BSDs by default and catman is not a part AFAICT of any Unix specification. - Passing the documentation through mandoc(1) enables dynamic customization, while cat(1) cannot do much or anything as it operates on pre-generated .txt files. Personally. I recall cat-pages to be relevant on Coherent 80286 UNIX-like OS, operating in real mode. Next, I propose to remove cat-man support from man(1) and man,conf(5). Patch minimum for man(1)/man.conf(5): http://netbsd.org/~kamil/patch-00286-stop-using-cat-dirs.txt Patch optimum is to remove the support for "_crunch", "_suffix" and eliminate all cat-man remnants from man.conf and man(1). signature.asc Description: OpenPGP digital signature
Complete removal of support for cat-pages (Was: catman)
On Mon, Nov 09, 2020 at 09:56:33 +0100, Thomas Klausner wrote: > On Mon, Nov 09, 2020 at 04:55:14AM +0300, Valeriy E. Ushakov wrote: > > > Hold your horses! This started with MKCATPAGES which is ability to > > pre-generate cat pages as part of the build. > > > > Now it's suddenly about eliminatiing support for cat pages entirely?! > > > > Like, do you plan to remove support for cat pages from man(1) as well? > > No need for strawmen :) A strawman? See Kamil's reply from a bit later, quoted just below. On Mon, Nov 09, 2020 at 11:33:39 +0100, Kamil Rytarowski wrote: > As stated in the original post, the goal is to remove .cat pages > support entirely and implement MANWIDTH without the complexity of > selecting between man and cat pages. The original post said (emphasis mine): http://mail-index.netbsd.org/tech-userlevel/2020/10/25/msg012618.html | I PROPOSE to drop the support for MKCATPAGES=yes. [...] [...] | If we WOULD want to support MANWIDTH we would need to [...] Thus the original post stated that that goal is to remove MKCATPAGES=yes support, i.e., specifically, pre-building cat pages at the build time and shipping them as part of the official sets. The original post also had some musings about supporting MANWIDTH. I don't see an explicit proposal to remove all support for cat pages from the system. Please, can you guys figure out between yourselves what exactly you are proposing and state that in clear terms? I am not sure if ~anyone in that original thread (even before it devolved into reminiscing about the slowest vax on earth) interpreted the original proposal as "let's completely remove the support for cat pages". -uwe
Re: catman (Was: CVS commit: src/games/fortune/datfiles)
On 09.11.2020 09:56, Thomas Klausner wrote: > On Mon, Nov 09, 2020 at 04:55:14AM +0300, Valeriy E. Ushakov wrote: >> Hold your horses! This started with MKCATPAGES which is ability to >> pre-generate cat pages as part of the build. >> >> Now it's suddenly about eliminatiing support for cat pages entirely?! >> >> Like, do you plan to remove support for cat pages from man(1) as well? > > No need for strawmen :) I have no strong opinion either way. > > I agree that kamil should propose the catman removal separately. > Thomas > As stated in the original post, the goal is to remove .cat pages support entirely and implement MANWIDTH without the complexity of selecting between man and cat pages. signature.asc Description: OpenPGP digital signature
Re: catman (Was: CVS commit: src/games/fortune/datfiles)
On Mon, Nov 09, 2020 at 04:55:14AM +0300, Valeriy E. Ushakov wrote: > Hold your horses! This started with MKCATPAGES which is ability to > pre-generate cat pages as part of the build. > > Now it's suddenly about eliminatiing support for cat pages entirely?! > > Like, do you plan to remove support for cat pages from man(1) as well? No need for strawmen :) I have no strong opinion either way. I agree that kamil should propose the catman removal separately. Thomas
