Hi Arsen, At 2025-09-30T21:57:00+0200, Arsen Arsenović wrote: > In the original Unix v1 programmers manual (or, at least, the copy I > could find),
As far as I know all copies of the First Edition manual on the Internet
descend from one scan. They all are missing ascii(VII); presumably some
CSRC person tore that page out and taped it up next to their Teletype.
If someone locates a different scan, especially one with that man page
in it, consider the groff mailing list interested.
> (A funny side note: subconsciously, I chose the name "fildes.7" as to
> not go over eight characters; it came to me naturally after many years
> of working with and on Unix-like systems, this archaic element simply
> lodged itself into my instincts after some time.)
Eight's an odd choice for that, though. As I understand it, the Fortran
linker that Unix originally used (C did not exist yet) had a limit of 6
characters for externally resolvable symbols, because that was all some
IBM operating system could handle. File names (or "path name
components", if one insists) were limited to 14 characters until the
Berkeley "fast" file system. The tuhs at tuhs dot org is a more
reliable resource than I can be here, though.
> Also, in my opinion, it is obvious that the term "file descriptor" is
> a misnomer or misabstraction and that "descriptor" or "handle" - which
> are significantly broader terms - would result in a far clearer
> abstraction (where a file descriptor is one such descriptor or
> handle).
"Handle" _is_ a better term. So let us politely applaud Microsoft
managing to not make the wrong choice at _every_ turn.
Just most.
> In my mind, this basic failure in design was a result of someone
> chanting something like "everything is a file", and hence attaching a
> read and write operation to all OS "objects" instead of understanding
> that the filesystem hierarchy also contained within itself an "object"
> hierarchy. I have no way of knowing if my head-canon is correct,
> though.
I don't either, but my impression is that much documentary work at the
Bell Labs CSRC was the work of exigetes attempting to divine Ken
Thompson's hermetic source code. Thus the value of the Lions book.
> Of course, this is tangental to the manpage discussion; this is caused
> by other forces also, such as the set of concerns usually lumped under
> "operating system" in other communities being broken up between
> occasionally-adverse groups.
...an easier problem to have when said groups share the common notion
that microkernels are stupid.
(The problem with Mach, whose properties big kernel advocates ascribe
it toto to all microkernels past, present, and future, was that its
working set was too large, and created excessive cache pressure. See
Liedtke, J., "On μ-Kernel Construction".[1])
It may also be the case that the path to "world domination" appears
easier with a big kernel than a microkernel.
> I'm not sure why this is relevant - roff is capable of producing
> better documents than manpages (for instance, The C Programming
> Language by Brian Kernighan and Dennis Ritchie, was typeset with roff
> to my awareness, or at least I seem to remember reading that in the
> preface at some point - in any case, it was certainly used in
> well-written publication rather than solely manpages, so the format is
> hardly relevant), so clearly it's not an underlying limitation of the
> format.
That's true. Brian Kernighan uses groff to write his books these
days.[0] Another well known and well received work written using *roff
was _Advanced Programming in the Unix Environment_ by W. Richard
Stevens. I don't know what Rago has used to typeset the second and
third editions of that work.
> And, again, there's a somewhat-better macro package for manpages also.
mdoc has advantages and disadvantages. The groff@gnu list archives
record some friendly sparring between Ingo Schwarze and me on the point.
> IMO, it is clear that developers, especially in the Unix sphere, are
> unwilling to write documentation. Washing machines from '80s tend to
> have more comprehensive documentation than the documentation in Unix
> and Unix-like systems.
I think documentation quality (or existence) has rotted in both the
software and appliance/consumer electronics domains. It used to be de
rigueur to include a complete circuit diagram for anything you could
buy that had a diode in it. Now, almost everything is locked up,
physically and conceptually thanks to trade secrets, with "no
user-serviceable parts inside". We are furthermore blessed with
stalwart opponents of copyleft and right-to-repair laws, doughtily
keeping their employers' 10-Q filings safe.[2]
The great thing about "intellectual property" is how its premier
application is suppressing the exercise of intellect.
Regards,
Branden
[0] I can't find my citation for this, but if I recall correctly, Arnold
Robbins asked Brian Kernighan in email, and shared this fact,
probably on the TUHS list.
[1] https://dl.acm.org/doi/pdf/10.1145/224056.224075
[2] Good news, though--one's firm may soon need only file such
disclosures semi-annually rather than quarterly. Free markets work
better with less information. Didn't Kenneth Arrow teach us that?
https://corpgov.law.harvard.edu/2025/09/27/the-forecast-on-quarterly-reporting/
signature.asc
Description: PGP signature
