Hi, Ingo! At 2021-08-04T14:46:18+0200, Ingo Schwarze wrote: > G. Branden Robinson wrote on Wed, Aug 04, 2021 at 02:06:09PM +1000: > > > I owe Doug McIlroy an apology for, some months ago on this list, > > significantly understating his diligence as editor of Volume 1 of > > the Version 7 Unix manual (1979). A meticulously numerical > > accounting of just one aspect of that effort follows in this > > (lengthy) email. > > Interesting. So v7 actually used I(R) outside and R(R) inside SEE > ALSO, almost consistently. Which means you do have tradition on > your side.
It's a strange sort of vindication for an iconoclast by temperament, but I'll take it. > Ah yes, the usual problem that the roff pipeline discards all the > semantic structure right at the beginning and that the output devices > no longer have access to information contained in the source document, > in this case "this was a manual page cross reference". > > My point is -O man= / \*(MB is a job for the output device. It is > totally different for HTML or terminal or PDF output. The HTML > output device wants to build URIs and hence likely needs a base URI, > but that's completely useless for the other devices. So logically, > making it an option to the output device/postprocessor (like grohtml) > would seem adequate. But that doesn't work with roff pipelines already > having discarded all the required information... :-( > > So maybe some layering violating contortions invading the macro > package files like the ones you mentioned are needed. Not sure, > it still feels disgusting to me, but if no better idea can be found... I think the problem is analogous to that which has led to ever-more expressive debugging info formats for code that compiles to native machine language. One of the reasons it took so long to get really helpful error messages from C compilers was that so much information about the source text got discarded by the time the actual translation process was taking place. What gets us the little under-squiggles and carets and spelling-correction suggestions now are...layering-violating contortions. Questions of traceability and auditability, among more prosaic concerns like figuring out what the heck the compiler is actually complaining about, to me, reveal the Unix filter model to be less a cost-free stroke of unalloyed genius and more of an engineering trade-off. It made things possible on 16-bit machines with 16- (or, effectively, 17-) bit address spaces that would not have otherwise been, and that's a win for economics. And indeed Unix was a win, especially for its time--but people who loved their top-to-bottom integrated Smalltalk or LISP environments (to the extent that I can imagine their daily experience), weren't crazy. They saw valuable things there. As I see it, Rob Pike and others tried to capture some of that consistency with Plan 9 (and Rio, and a major rethink of terminal management). But people hate learning new things--they are aggressive adherents to the sunk cost fallacy. AT&T's attitude to licensing was probably sufficient to kill Plan 9 as a popular solution all by itself, but even if it hadn't, I think it still would have failed, because "worse is better". There were a lot of people out there who thought SunOS 4 was the peak of OS design. (Similarly, people believe that Mach proved once and for all that microkernels were inefficient and would forever be so. Or they're simply hooting fanboys of Linus Torvalds's [erstwhile?] approach to technical critique and hopped on his bandwagon without understanding what the argument was. You can put Jochen Liedtke's empirical measurements[1] in front of people all day long and they won't change their minds. [Spoiler alert: Mach wasn't a very "micro" microkernel. Its working set was too big for the machines it was deployed on. Mach was, at that time and in that form, probably doomed anyway. To slim down it would have had to look less like Unix, and even it that meant pushing some fundamental Unix concepts into userspace it still would have been too discomfiting to ever win among Unix fanatics.) (Did I digress some?) At any rate, I don't think an MB string is too offensive, because almost no one will need to know about it. man(1) implementors, and us, are about it. At present man-db man(1) and Brouwer/Lucifredi man(1) [does anyone still ship that?] don't, I think, permit the user to specify *roff string or register definitions at the command line, so assuming MB gets out the door before Colin Watson acts on my request to add such a feature (to tune page rendering options), users won't even be able to meddle with it without editing man.local. Regards, Branden [1] https://www.cs.fsu.edu/~awang/courses/cop5611_s2004/microkernel.pdf
signature.asc
Description: PGP signature
