Thomas Paulsen writes: I think that this discussion is like bell-bottoms, it comes around every few years. Like Clem, I prefer concise man pages and longer, separate documents for those programs where it makes sense. I consider man pages to be quick references. But my real issue with texinfo wouldn't get solved with html pages many of which already exist. The problem is that the ecosystem has been fragmented by people doing their "documentation" in their preferred formats instead of in a common (man) format. This makes the experience one of "is there any documentation?" followed by "what's the incantation to get it?" When you're looking for the documentation for pdf2svg, for example, and there is no man page, how long does it take to figure out that there is no documentation at all? Jon

reasonable. I write all my quick references in plain nroff since many years. There are gui editors, gui viewers, and lots of cgi search engines && web viewers even with hyperlinks. Even under good ole emacs techinfo is redundant, as 'woman' can do hyperlinks, which were the only advantage of techinfo in a remote past, however time goes on. Today we have help2man, hence the lazy ones can do man pages too. 'The problem is that the ecosystem has been fragmented by people doing their "documentation" in their preferred formats instead of in a common (man) format. This makes the experience one of "is there any documentation?" followed by "what's the incantation to get it?" When you're looking for the documentation for pdf2svg, for example, and there is no man page, how long does it take to figure out that there is no documentation at all? ' that's true. In the early 90ths they forced us writing quick references with .html. Big confusion. Soon later I found myself converting .html back into nroff because that's the UNIX style. I know some of us don't like to hear that, but with regards to the gnu tool chain, Richard did a lot of good things, however the politics of replacing man by techinfo definitely wasn't.

On Mon, 17 Feb 2020 16:22:32 -0700 Warner Losh <imp(a)bsdimp.com> wrote: If some of us undertake to write a few man pages and review a few written by others, over time we can make a sizable dent in the problem. Something worth considering for FreeBSD ports? Of course, not as much fun as complaining and a lot more work :-)

Brian?

Richard Salz writes: The relevant TUHS part of it that maybe some folks here can speak to is how did UNIX remain so cohesive for so long? How were decisions made? Of course, this started to fall apart with System III and such as things got more clunky. I've probably said this before, but today I see way too much "string theory programming". What I mean by that is the "I have an idea so I'll just start my own universe that doesn't play well with others rather than extending the existing ecosystem" model. That's my beef with texinfo; there was already an existing functional system and rather than making some improvements a new incompatible universe was created. Noel Chiappa writes: I think that this is part of the problem, have you looked at the source for any modern package? It's pretty impenetrable. I see a lot of overly complex, poorly written code with no documentation. That makes it really difficult for someone to extend or otherwise modify it. It's probably easier to create a new universe than understand an existing one. Jon

On Mon, 17 Feb 2020 16:17:18 -0800 Jon Steinhart <jon(a)fourwinds.com> wrote: Agree. I don't mind additional documentation but a man page is strongly preferred. There is just so much more code now and the S/N ratio is definitely worse but there is more good stuff as well. My problems with using the source as documentation: a) there is usually no or insufficient documentation about even what it is implementing let alone *how* it should be used, b) you don't know if some behavior is an accident of the way the code behaves or actually part of some required (but unwritten) specification. c) even if there some function header comments often there is no top level comment tying together eveyrthing. d) harder to see missing functionality. e) impossible to grok large programs.

"Greg A. Woods" <woods(a)robohack.ca> wrote: Well said. The markup language was clearly inspired by Scribe, which was quite popular in Academia (at least) at the time. As a *markup language*, I personally find it superior to anything else currently in use, but that's a whole different discussion that on TUHS inevitably degenerates into the current spate of ranting, so I won't start on it. Wow. Is that still maintained? Arnold

Ahem. Back in the 80's, I used both nroff and troff a fair amount. For example, Vicki Brown and I used nroff, in combination with an IBM I/O Selectric (Datel 30) to print most of her master's thesis. I also used troff to typeset several books for Prime Time Freeware. Mostly, I used pre-existing macro packages, but sometimes I had to dive down to the bare metal. It all worked, and was quite flexible, but I really don't miss it for adding docs to software projects. Lately, I've been using the built-in documentation tools for Elixir, a functional programming language based on the Erlang VM and a lot of Ruby syntax. I'm pleased to say that it's really quite pleasant. I create multi-line "attributes" using macros such as @doc. These are encoded using Markdown, which isn't perfect but seems adequate. The results are converted into both HTML pages and interactive help text, with automagical indexing. I'm able to create "doctests" by embedding IEx (Interactive Elixir) examples, eg: iex> 2 + 2 4 These get tested automagically, providing a modicum of reliability to the documentation. Amusingly, I did something similar years ago, extracting C code from the SYNOPSIS sections of Apple's man pages. This let me find and report a few docubugs... -r

On 18/02/2020 12:28, arnold(a)skeeve.com wrote: What are the issues with how Knuth programs? Honestly I've never heard any criticisms before. This looks _really_ cool. I am looking forward to reading this in detail and hopefully experimenting with it. Really? But then how about this? David R. Hanson, "C Interfaces and Implementations: Techniques for Creating Reusable Software", Addison-Wesley Professional, 1996. Online at https://www.informit.com/store/c-interfaces-and-implementations-techniques-… . It is not only one of the best books about programming I've ever read. It's also one of the finest examples of literate programming I've seen. Andrew -- OpenPGP key: EB28 0338 28B7 19DA DAB0 B193 D21D 996E 883B E5B9

hrrmpt... On Tue, Feb 18, 2020 at 2:40 AM Greg A. Woods &lt;woods(a)robohack.ca&gt; wrote: ditroff was always >>open source<< and any licensee could get it and see it. The problem you are suggesting is that it was not >>free<< i.e. FOSS. AT&T licensed it with a small set of fees. IIRC $1K for the first CPU, an $50 for each and redistribution license was $10K and $5/system. The other issue is you really needed Adobe's transcript package to effectively use it on your Apple Laserwriter and other later PS based printers, as most people lacked actual typesetters. Please remember that >>all<< the Universities with $150 AT&T licensed and a BSD license, had basic troff on their Vaxen with any BSD systems they had. So they all had it for 'free' (and open). I'll accept Larry's previous notes that not all people in those places had access to the sources, but everyone should have had access to the binaries that came with the system. For folks running binary only systems from Masscomp/Sun/DEC/HP/IBM and the like, it is possible it was different. The fact is I know Masscomp supplied ditroff on all systems and just ate the $5 license fee. We also license transcript from Adobe and included that. My memory is that was just a one-time charge and no redistribution. I'm not sure what Sun did, but I think they supplied the BSD troff, vcat and the like (Larry may know for sure). I'm pretty sure HP supplied at least the BSD/vcat family; but they have updated to ditroff. I've forgotten what DEC settled on. By the time of Tru64 it was ditroff on the system, but with Ultrix it may have been you got the troff/vcat off the BSD tape had their was a fee for the ditroff/transcript package. So the basic facts are is that in the Unix ecosystem, the nroff/troff ecosystem was very much around before 1990's groff. Frankly, the biggest thing it did was enabled Linux to have a version of ditroff. I know in my own case, I would (horrors) carry the sources with me for the AT&T package and Transcript for early PC based BSD's. The truth is both packages were (and are) easily findable in dark corners of the Internet. I also request, that we refrain from the seemingly yearly Tex vs. troff war. It's about as productive as the C vs Pascal or C++ vs Java discussions. This thread started as Doug's observation about wanting man pages and issues with Gnu's texinfo scheme. It turns out man was based on the [nr]roff family. The reality is that any document compiler used to create man pages, that would be a different discussion. ... and I like my lawn as it is ... Clem

On Tue, Feb 18, 2020 at 08:28:50AM -0700, arnold(a)skeeve.com wrote: Yeah, Clem sort of has a blind spot on licensing. It's weird because I agree with him on almost everything, it's sort of spooky how much we agree. My guess is that Clem was always at a University or a job where the fees were mouse nuts and so it appeared to him that things just worked. If you were a grad student like me, who wanted roff on a PC, it was very different. And I suspect Clem has always been seen as one of the chosen few who get logins on the machines with source. I was a nobody and had to fight hard to get a login, I got it, but not until I was a junior.

Yes and the term "open" was coined by the marketing folks in uniforum to describe the open interfaces and ability to see the sources (you might have pay a license fee). Or it was not free. Other people came later and missinterpreded the term. Clem On Tue, Feb 18, 2020 at 10:43 AM Steve Nickolas &lt;usotsuki(a)buric.co&gt; wrote: -- Sent from a handheld expect more typos than usual

On Tue, 18 Feb 2020, Theodore Y. Ts'o wrote: I always understood "open source" to mean this: you have access to the code, you can share it, you can modify it, and any combination of the above (including commercial exploitation; basically a restatement of Stallman's freedoms in simpler words). As any phrase gets skewed to mean something other than it was intended, when most people say "open source", they seem to only mean what I call "source-available" - i.e., that there is *some* means by which a mere mortal can gain access to the source, but there is no guarantee that they can actually DO anything with the source without getting sued into oblivion. I usually say if the code doesn't offer the necessary freedom to make use of it. it's not "open source", it's just source. (For the record: I shifted from the GNU side to the BSD side of the debate about 20 years ago. But I hold no ill will toward people on the GNU side.) -uso.

IIRC, there was a meeting of various (FOSS) luminaries in the early or mid-90s discussing rebranding Free Software (as in the FSF definition) as it was far too easily misinterpreted as meaning non-/anti-commercial. "Open Systems" had been around forever as a description of how the Unix "ecosystem" worked - you had a common set of APIs based on an originally common source base, and a common set of communication protocols, that worked on a wide array of computer systems, from real-time to supercomputers to mainframes and beyond. With all due respect to Clem Cole, I don't recall ever seeing "open source" used as a description of the Unix "ecosystem" during the 90s. It was in the air with the (minimal) charges Prentice-Hall charged for the Minix 0.x and 1.x disks and source; not dissimilar in that sense to the charges the FSF were charging for their tapes at the time. But all the Unix-y ads I can recall from the 90s talked about Open Systems, and never Open Source. That came in following Linux and *BSD radiation. But this is probably COFF's Harbour stuff ... Wesley Parish On 2/19/20, Steve Nickolas &lt;usotsuki(a)buric.co&gt; wrote:

The term OSS to mean free as in beer is just not correct. The sources were always free a as in available to be read but just like today they are licensed. Ad for Universities. The point is if you had a vax you had troff as a miniimun an $50 for ditroff was not a hardship. If you had a binary workstation from DEC or Sun you got troff on the system and if you got a masscomp you got ditroff. The point is people had access to a working binary without spending any we real extra money - which was Jons point. The ecosystem under Unix was fine until the real a FOSS world which was when groff appears. On Tue, Feb 18, 2020 at 10:28 AM &lt;arnold(a)skeeve.com&gt; wrote: -- Sent from a handheld expect more typos than usual

But that is how it was formed by the original commercial unix folks (which I was one). We talked about the open systems community. Look at some of the uniforum docs in the archives from the mid 1980s if you don't believe me. That is what was meant because we could not say Unix and at the term in the commercial community it was Unix vs proprietary systems aka VMS, MPE, Kronos et al. The context of the day that was exactly what we meant. That said, I'll grant you you words change meaning over time, but I was and do use the term in context of the original open systems community - which I was a founder. If you mean FOSS then say that, if you mean an open system with published interfaces and available sources, that by definition open source software. So please don't try tell me what we meant. Eric Raymond is probably the person where I started to see the warp of its meaning. That's why I always say FOSS when I mean free in the context of RMS. Also remember most of the current FOSS movement the code is very restrictioned in it's license. The difference is if you have to pay a fee for it and what you can do with the derivative works Fyi if you want to discuss free or not that discussion needs to move to COFF. This is certain a discussion from an old f*RTS perspective. On Tue, Feb 18, 2020 at 11:02 AM Chet Ramey &lt;chet.ramey(a)case.edu&gt; wrote: -- Sent from a handheld expect more typos than usual

"How I coined the term 'open source'", by Christine Peterson https://opensource.com/article/18/2/coining-term-open-source-software -r

At Tue, 18 Feb 2020 10:11:45 -0500, Clem Cole &lt;clemc(a)ccc.com&gt; wrote: Subject: Re: [TUHS] man Macro Package and pdfmark Indeed. I was going to use the word "freeware", but it seems to have gone out of common use in favour of the now more common "open-source", as in https://opensource.org/ At the times I referred to the lack of freely available AT&T source code was extremely limiting in how people viewed the availability of such "add-on" tools for Unix -- including the C compiler! AT&T's break-up of the "Unix" distribution into separately licensed chunks was, from my perspective, one of the main driving forces behind the creation and adoption of so many clones and alternatives -- no matter how far they strayed from the original Unix philosophy. It was _very_ different. If you weren't out in the trenches of end-user Unix-based systems at the time it may not have been as obvious as to just how restrictive it was to have proprietary fee-based licensing of such add-on software. Most end-users couldn't even pay their vendors for ditroff -- their vendors didn't want to have to license it from AT&T, even when they had advocates inside the companies (e.g. I did some work supporting software for a couple such vendors and was never able to convince them). Some, as you mention, were all-in, but it wasn't until UNIX System V Release 4 became more widely available that systems based on it were more likely to have ditroff, and sometimes (though much more rarely) the "new" dpost post-processor was also included. I don't know if there were different licensing terms for SysVr4 or not. Don't get me started on how hard it also was to get some end users to buy a C compiler too. For the entire decade of the 1990s I was still one of the only people I knew (outside of those I knew in AT&T Canada and their customers) who owned a system that included ditroff and dpost and could print directly to a PostScript laser printer -- and that's despite living in the same city where SoftQuad was re-licensing ditroff and their variant of dpost to quite a wide variety of users. This was my situation because I had chosen to buy a used AT&T 3B2. Without that I'd have been without ditroff -- I would have been very lucky if I had v7 troff binaries so that I could use Chris' PSroff. These days of course there's the full ditroff source release in the Heirloom Documentation Tools collection. I'd like to see it used to replace Groff in some places, but so far I've been less than successful -- that cart seems to have rolled off the road into the ditch, hopefully without losing the horse though. -- Greg A. Woods &lt;gwoods(a)acm.org&gt; Kelowna, BC +1 250 762-7675 RoboHack &lt;woods(a)robohack.ca&gt; Planix, Inc. &lt;woods(a)planix.com&gt; Avoncote Farms &lt;woods(a)avoncote.ca&gt;

What was more frustrating to Sun users was that there WAS a compiler included in Sun OS, but it went away with Solaris. I saw a noticeable change in code available in binary form only after that. At least until the GNU stuff got stable enough to use... (I was a customer of MIke's when he first start Cygnus for support of the GNU compilers... I was working in a secured facility and multiple times I spoke with him on the phone typing in patches by hand -- as he relayed them -- because of the time and hassle it took to get a tape in with the patch...) Earl On Tue, Feb 18, 2020 at 11:45 PM Larry McVoy &lt;lm(a)mcvoy.com&gt; wrote:

I've only tried it in virtual machines. It feels slower and more sluggish than OpenIndiana (which is based on Illumos, which is the post-Oracle open solaris) -but I don't use OI a whole lot either. Since there's an opening I'm curious about something mentioned earlier in the thread, so I'll ask. It was said earlier that SunOS included a compiler, but it was dropped in Solaris. Was it possible for people to carry over the old SunOS compiler and use it on Solaris? Did people do that, or did they just have their companies spring for the actual Solaris compiler? On 2/19/2020 9:12 AM, Emile Bye wrote:

On Wed, 19 Feb 2020 at 15:20, Michael Huff &lt;mphuff(a)gmail.com&gt; wrote: In short: no. SunOS binaries would usually run on Solaris if you had all of the right libraries, etc. but the compilers created totally different code. SunOS was a.out and Solaris was ELF; SunOS was BSD and Solaris was SYSV. Solaris was a huge shift away from SunOS; they were effectively entirely different operating systems for the same hardware. I don't know if there was some sort of trade-in discount for the old compiler when you upgraded to Solaris, there might have been. SunOS continued to be patched and supported long after Solaris was released. There were many reasons for this, but the short summary is that many people didn't want to have to move to an entirely new OS, or for some reason couldn't. The analogy that comes to mind is the shift from the classic Mac OS to OS X: your old programs would probably run if they weren't too concerned about the internals of the OS, but it was a big upheaval and most everything had to be rewritten to some degree. -Henry

I looked at Solaris very briefly and decided that it wasn't my idea of a proper (read, BSD) Unix system. So, I kept my Sun running SunOS until I finally replaced it with a FreeBSD box. -r

On Thu, Feb 20, 2020 at 12:27:15AM -0700, arnold(a)skeeve.com wrote: I really fault Sun for that one. There was a time when every open source package "just worked (TM)" if you built it on a Sun. All the other platforms were fiddly (leading to that monstrosity called autoconf), Sun just worked. So developers fought hard to get a Sun over the other platforms. When you have that lead and you screw over the people who gave you that lead, yeah, shame on you, Sun. Early Solaris was awful, just awful. They pulled out sockets and replaced them with Lachman's STREAMS based TCP/IP stack (really convergent's stack, I believe Lachman bought it from them). Performance was horrible, they brought in Mentat's stack and had to work on that, and eventually they brought back sockets. I dunno if there is any STREAMS stuff left, that was a horrible idea. Another idea, not sure if this shipped or not, was to use a thread for each 8K block headed to disk. The kernel stack was 24K (which is nuts but that's another story). So think about what a dd if=/dev/zero of=XXX does to your system. Each I/O costs you 8K (data) + 24K (stack) not to mention the other overhead for a thread. It means you only get to use 25% of ram for dirty pages. Bat shit crazy, right? I pointed all that out to the VM / FS people and they did it anyway, they were in love with threads. It was just as awful as I predicted and they ripped it all out and started over. To this day, I'm baffled that I could see that that was a horrible idea and really smart people did not. Lots of those people were smarter than me. It speaks to why you shouldn't push your shiny new feature too hard. And it lead to these in http://www.mcvoy.com/lm/quotes.html Think of it this way: threads are like salt, not like pasta. You like salt, I like salt, we all like salt. But we eat more pasta. --me A computer is a state machine. Threads are for people who can't program state machines. --Alan Cox Both very on point for the Sun people.

On 2/20/20 8:23 AM, Larry McVoy wrote: And now the world runs on threads and (current fashonable OOPL) It makes my brain hurt.

FWIW, I've been enjoying Elixir a lot for the past few years. It's an Actor-based, dynamically typed, FP language that runs on the Erlang VM. It has Rubyish syntax, pattern matching, syntactic macros, lightweight processes, a message-passing framework, supervision trees, and other cool stuff. I will note, however, that Elixir programming tends to be rather different from the stuff I've been doing for the past 50 years. For example, processing pipelines tend to replace sets of nested loops... -r

True, but after the fact everyone decided that Erlang was really doing Actors. FWIW, here's an interesting session on that sort of thing: https://www.youtube.com/watch?v=37wFVVVZlVU Let's #TalkConcurrency Panel Discussion with Sir Tony Hoare, Joe Armstrong, and Carl Hewitt with host Francesco Cesarini. When considering the panel to discuss concurrency, you’d be pushed to find a higher calibre than Sir Tony Hoare, Joe Armstrong, and Carl Hewitt. All greats within the industry and beyond, they give an amazing insight into the lifeline of concurrency and actor models over the past few decades, their bountiful experiences within the concurrency field, and where they see concurrency heading in the future. -r

On Thu, Feb 20, 2020 at 11:48:03AM -0500, Nemo wrote: I was the lead guy on Sun's first cluster product, I developed it on SunOS 4.x but Scott wouldn't let me ship that, it had to be Solaris. Which screwed performance, it was an NFS server so all that traffic was going through STREAMS, it was awful. I gave a pitch for that product at the Moscone center and had to endure heckle after heckle about 5.x vs 4.x. I toed the party line for as long as I could and finally I had enough and said something like "I know. 5.x sucks, it just does, but that's what I have to ship with." It was taped. Ken Okin, my boss and senior VP of all server hardware, heard the tape, came to me and said "Find and destroy all copies of that tape. Now!" It was not a fun time.

On Wed, Feb 19, 2020 at 11:18:53AM -0900, Michael Huff wrote: SunOS's compiler that shipped with it wasn't that usable. It didn't fully support the C standards at the time. It was used primarily for two things. *) To compile the few kernel objects that were shipped as source & to link in all the binary objects into one new kernel for patching/tuning. *) To bootstrap GCC so one had a usable compiler to build packages. GCC had special code used for the bootstrap process specificly at the time on SunOS, written in a level that the SunOS compiler could deal with. Otherwise, it could only be used for simple projects. As others stated, the output of the compiler would have been a.out, and not ELF like Solaris 2.x would have needed. Some people equate SunOS from a time when all Unices still had (usable) compilers, but that was actually an earlier time frame. Sun was selling its standards compliant compilers for SunOS before Solaris 2.x was around.

On 02/20/20 19:18, Warner Losh wrote: For what it's worth, HP-UX (for PA-RISC, at least) shipped with a free K&R compiler that compiled a kernel specific to the box. However, I seem to recall that it could not compile GCC so no bootstrapping there. N.

so this can only be true for later not to say final days of sun-o2, as gcc wasn't available before. Was it Stephen's pcc or Dennis CC?

On Fri, Feb 21, 2020, 11:35 AM Heinz Lycklama &lt;heinz(a)osta.com&gt; wrote: The Auug newsletters talk a lot about miniunix, fixes to miniunix, etc. People offered copies to any Unix licensees. Most of these were universities. Warner I do not believe that WE ever considered licensing a binary

It was /etc/update. I used one of these in the Psych department at UCSD. When it started going weird I shut it down and removed the floppy. As you mentioned, the tracks at the start of the disk were worn smooth. David

On 2/21/20 10:34 AM, Heinz Lycklama wrote: tape image at http://bitsavers.org/bits/ATT/mini-unix_120679.zip

This should be covered by the ancient Unix license since it is derived from V6. Warner On Sat, Feb 22, 2020, 4:02 AM Ed Bradford &lt;egbegb2(a)gmail.com&gt; wrote:

On Sat, Feb 22, 2020 at 11:11:28AM -0700, arnold(a)skeeve.com wrote: Already there in https://www.tuhs.org/Archive/Distributions/USDL/Mini-Unix/Kossow/ Thanks for the heads-up, though! Cheers, Warren

On Sat, Feb 22, 2020, 4:08 AM Ed Bradford &lt;egbegb2(a)gmail.com&gt; wrote: The file name suggests Dec 6, 1979, though that's us centric and it could be June 12, 79 as well... Warner Ed

OK, that does look like the official Mini-UNIX release from Bell Labs in 1979. I'd have to look at the files in the .tap file to verify this. Note the name Mini-UNIX was also used by Andrew Tanenbaum for the system he developed at Vrije Universiteit in Amsterdam much later in 1987 independent of the Mini-UNIX that I developed at Bell Labs in the mid 1970's. See here: https://en.wikipedia.org/wiki/MINIX Heinz On 2/22/2020 8:46 AM, Clem Cole wrote: