From steffen at sdaoden.eu  Sun Sep  1 01:14:10 2019
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Sat, 31 Aug 2019 17:14:10 +0200
Subject: [TUHS] If not Linux, then what?
In-Reply-To: <alpine.BSF.2.21.9999.1908311134050.37360@aneurin.horsfall.org>
References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net>
 <CAFNqd5VpUE9OsKqfHDW8-76S46PYtnTJWDWAs0FU6o+73B4ZfQ@mail.gmail.com>
 <20190828231952.GA536@mit.edu>
 <CAFCBnZs5e3XLUtJVwpSDYZ4LApubKhejG71cRpEoSON6OYUD8w@mail.gmail.com>
 <3173aba3-b6c3-43db-6374-b600f3217f13@kilonet.net>
 <004ec49789583b190ca7c302db9fbb31@firemail.de>
 <20190829191943.BfJ86%steffen@sdaoden.eu>
 <alpine.BSF.2.21.9999.1908311134050.37360@aneurin.horsfall.org>
Message-ID: <20190831151410.uywnr%steffen@sdaoden.eu>

Hello.

Dave Horsfall wrote in <alpine.BSF.2.21.9999.1908311134050.37360 at aneurin\
.horsfall.org>:
 |On Thu, 29 Aug 2019, Steffen Nurpmeso wrote:
 |>|Today however not in the 80ths. Inn those days all 4 cars were Richie \
 |>|Rich cars.
 |>
 |> And only the Mazda had that wonderful smooth engine which replaces
 |> pounding pistons with nice chuckling triangles.
 |
 |[ Getting OT... ]

Yes, sorry for that.

 |Too bad about the seals, though...  They had this habit of wearing out.

I do not think this is actually true.  I think it was "not false"
for the first series of the NSU Ro80 at the beginning of the 70s,
but materials engineering is what made such unbelievable progress
ever since, it always leaves me just speechless.

"Not false" in that it likely was dependent on the way of driving
even back then.  I definitely have heard stories of people still
driving Ro80 first series, original.

And for later ones, say Mazda RX-8, i think it is a problem of the
past, anyway.  I just looked, and Mazda finally gave 100000 Miles
guarantee for the seals.
I mean, in the end these are industry products which compete in
a surrounding market, and i do not mean this positively.  For
example, the Lenovo laptop i bought this year grants itself a four
year lifetime (states the manual for the Russian market, for which
such statements seem to be required).

The problem of the Wankelmotor is the form of the combustion
chamber, which is even worse than for the Otto (or Diesel) piston
engine, even less spherical.  Modern injection systems and
electronical management can overcome this a bit.  You know, i will
never forget the IAA (car exhibition in Frankfurt/Main Germany)
either at the end of the 80s or the beginning of the 90s, where
Toyota shewed high-speed videos of the combustion process.  It was
rather trial-and-error before, with a lot of things tried (piston
forms, multiple spark plugs, electronical spark control), but
Toyota came up with diet mix engines at that time, and started to
use direct injection (iirc).  This is not new, i think we had that
already for fighter plane engines in WWII, but it was trial and
error.  With those videos and better gauges the combustion process
was better understood, and resulted in improved efficiency and
exhaustion behaviour.

I was surprised that the Atkinson engine which drives at least the
Honda and Toyota Hybrid cars does not use direct injection, but
rather the suction line one again, but it is the end of decades of
science and exploration, right.  Some Atkinson engines use a mixed
injection that also includes direct injection it seems (Lexus?).

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

From clemc at ccc.com  Sun Sep  1 01:41:40 2019
From: clemc at ccc.com (Clem Cole)
Date: Sat, 31 Aug 2019 11:41:40 -0400
Subject: [TUHS] dmr streams & networking [was: Re: If not Linux,
 then what?]
In-Reply-To: <CAMYpm86xi5ztkXMpbvtbymn+t4RwtVPzHepgo5+K67VL2U7uNA@mail.gmail.com>
References: <CAMYpm86xi5ztkXMpbvtbymn+t4RwtVPzHepgo5+K67VL2U7uNA@mail.gmail.com>
Message-ID: <CAC20D2MJPFoU6r73U9GDaqG+Q7vpH3T7CiDNjgN3D2uyuAJgLQ@mail.gmail.com>

It's the Mentant implementation that HP originally bought.  At LCC we had
to hacked on it a bit when we put Transparent Network Computing (TNC) stuff
in HP-UX  [we had full process migration working BTW -- A real shame that
never shipped].

On Sat, Aug 31, 2019 at 5:44 AM Rudi Blom <rudi.j.blom at gmail.com> wrote:

> Whenever I hear UNIX, networking and streams I have to think about this
> scheme.
>
> Still using this, even on HP-UX 11.31 on Itanium rx-servers
>
> Cheers,
> uncle rubl
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190831/01a82489/attachment.html>

From rminnich at gmail.com  Sun Sep  1 02:00:24 2019
From: rminnich at gmail.com (ron minnich)
Date: Sat, 31 Aug 2019 09:00:24 -0700
Subject: [TUHS] early vm systems
In-Reply-To: <fb109b53aa00decf12498b41755d9090@firemail.de>
References: <FBE13D27-3C8B-4169-868D-72C06A2C15D4@quintile.net>
 <fb109b53aa00decf12498b41755d9090@firemail.de>
Message-ID: <CAP6exYLkincvSN0CAqajQmv21EjwWC8=wXqSnVJMQ3gGip8keA@mail.gmail.com>

On Sat, Aug 31, 2019 at 5:05 AM Thomas Paulsen
<thomas.paulsen at firemail.de> wrote:
>
>
> --- Ursprüngliche Nachricht ---
> Von: Steve Simon <steve at quintile.net>
> Datum: 31.08.2019 11:44:22
> An: tuhs at minnie.tuhs.org
> Betreff: [TUHS] early vm systems
>
> > hi
> >
> > the other early vm system not mentioned yet is the one Charles Forsyth wrote
> > at the university of york for sunos. i never used it as i was learning v7
> > on an interdata 30 miles away at the time but i read his excellent paper
> > on it.
> did you mean: https://www.researchgate.net/publication/2411547_The_Mether_System_Distributed_Shared_Memory_for_SunOS_40


no, that was me :-)

charles' excellent paper,
"More Taste: Less Greed?
or
Sending UNIX to the Fat Farm", http://www.terzarima.net/doc/taste.pdf

is a good read, as is everything he writes.

From cbbrowne at gmail.com  Sun Sep  1 02:58:00 2019
From: cbbrowne at gmail.com (Christopher Browne)
Date: Sat, 31 Aug 2019 12:58:00 -0400
Subject: [TUHS] If not Linux, then what?
In-Reply-To: <20190828231952.GA536@mit.edu>
References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net>
 <CAFNqd5VpUE9OsKqfHDW8-76S46PYtnTJWDWAs0FU6o+73B4ZfQ@mail.gmail.com>
 <20190828231952.GA536@mit.edu>
Message-ID: <CAFNqd5Ub6Xs2emHZpTeOi0Wd=R+ou0u4bUHs19Wyzr1ASn9GNg@mail.gmail.com>

On Wed, 28 Aug 2019 at 19:19, Theodore Y. Ts'o <tytso at mit.edu> wrote:

> On Wed, Aug 28, 2019 at 04:07:39PM -0400, Christopher Browne wrote:
> >
> > - Hurd was imagined to be the next thing...
> >
> > To borrow from my cookie file...
> >
> > "I am aware of the benefits  of a micro kernel approach.  However, the
> > fact remains  that Linux is  here, and GNU  isn't --- and  people have
> > been working on Hurd for a lot longer than Linus has been working on
> > Linux." -- Ted T'so, 1992.
>
> That's "Ts'o" :-), and that quote wasn't my arguing that Hurd would be
> the next thing.  It was people had been working on the Hurd for
> *years* (starting 1984) and it still wasn't real.  If it wasn't going
> to be real after eight years, another eighty probably wouldn't have
> helped.
>

Thanks, patched!  :-)  And yes, I agree that you weren't arguing for the
impending relevance of Hurd.  Nevertheless, at the time, there were
people making the argument that Hurd would Real Soon Now make
Linux irrelevant.


> And a lot of this was because was because RMS was hard to work with,
> and he was a purist.  Pretty much very *definition* of the perfect
> should always be the enemy of the "good enough".
>
> In fact, at one point Thomas Bushnell, one of the senior Hurd
> developers pushed to have the Hurd switch to using BSD 4.4-Lite, and
> Stallman refused[1].
>
>    “RMS was a very strong believer, wrongly, I think, in a very greedy
>    algorithm approach to code reuse issues,” Thomas Bushnell later
>    remembered.
>
>    “My first choice was to take the BSD 4.4-Lite release and make a
>    kernel. I knew the code, I knew how to do it. It is now perfectly
>    obvious to me that this would have succeeded splendidly and the
>    world would be a very different place today. RMS wanted to work

   together with people from Berkeley on such an effort. Some of them
>    were interested, but some seem to have been deliberately dragging
>    their feet: and the reason now seems to be that they had the goal
>    of spinning off BSDI. A GNU based on 4.4-Lite would undercut BSDI.”
>
>    As Bushnell describes it, Stallman came to the conclusion that
>    “Mach is a working kernel. 4.4-Lite is only partial. We will go
>    with Mach.”
>
> [1]
> https://web.archive.org/web/20121228225905/http://www.linuxuser.co.uk/features/whatever-happened-to-the-hurd-the-story-of-the-gnu-os


I haven't seen reference to Bushnell in a long time; looks like he has
shifted to ecclesiastical matters.  He was up to some interesting
software things, once upon a time.

The tales of Stallman being stubborn are not rare.

It's interesting that perhaps BSDI was a reason for GNU avoiding 4.4-Lite.
That points to why the "what might have been" is very troublesome to track
down.  Alternatives always interact with one another...


> That's probably one of the other things that may have hampered BSD.
> The BSD license made it easier (or at least made easier business
> models) for monetizing BSD, and some of the most talented people went
> off to make a buck off of BSD.  BSDI, Sun, NetApp, Wasabi Systems, etc.
>
> Nothing wrong with that of course, and if people like Bill Joy were
> able to make bank based on BSD, more power to them.  But it probably
> removed from the leadership pool people who might have had better
> leadership, and technical architect skills who might have led one of
> the *BSD's to greater success.
>
> The GPL makes it harder to monetize Linux --- although, as we've seen,
> certainly not impossible --- and if you take a look at the most of the
> senior technical people at Linux, none of us have made off as well as,
> say, Bill Joy.  I'm still a working stiff, and don't have enough to
> retire.  (That's OK; I'm perfectly happy being part of the 99%.  :-)
>
> > Anyway, Hurd *might* have been a "next thing," and I don't think the
> > popularity of Linux was enough to have completely taken wind out of its
> > sails, given that there's the dozens of "Unix homages" out there.
>
> Given who called the shots (and it wasn't the key people actually
> doing most of the technical work, such as Bushnell) I actually think
> it's not very likely Hurd could have succeeded.  RMS actually tried to
> recruit me to work on the Hurd as well, and I refused, because of
> project leadership concerns.  (Again, feel free to hate on Linus's
> management style, but there were far worse ones in the open source OS
> world at the time.)
>
>                                         - Ted
>

Yeah, there's dysfunction everywhere :-).

Over the years, I have heard BSD folk blasting Linux over Linus' occasional
lack of tact; that is very much a road MORE travelled by a great many
projects.  Hurd's challenges starved it of staff, definitely unhelpful.
BSD had both amicable as well as ridiculously non-amicable forks.

It's not at trivial to get the right balance and plenty easy for missteps
to lead to disaster.

As vast overgeneralizations of the extremes, pure diplomats don't get
anything done, whilst jerks don't get enough help to support upgrading to
the next generation of motherboards/disk drives/graphics cards.  Successful
systems fall somewhere in between.
-- 
When confronted by a difficult problem, solve it by reducing it to the
question, "How would the Lone Ranger handle this?"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190831/98e667e6/attachment.html>

From imp at bsdimp.com  Sun Sep  1 04:27:33 2019
From: imp at bsdimp.com (Warner Losh)
Date: Sat, 31 Aug 2019 12:27:33 -0600
Subject: [TUHS] early vm systems
In-Reply-To: <CAP6exYLkincvSN0CAqajQmv21EjwWC8=wXqSnVJMQ3gGip8keA@mail.gmail.com>
References: <FBE13D27-3C8B-4169-868D-72C06A2C15D4@quintile.net>
 <fb109b53aa00decf12498b41755d9090@firemail.de>
 <CAP6exYLkincvSN0CAqajQmv21EjwWC8=wXqSnVJMQ3gGip8keA@mail.gmail.com>
Message-ID: <CANCZdfqye6JLVZPCb4ywgzzJkw59fLNZKRoKfDUP6xd8NJvNAA@mail.gmail.com>

On Sat, Aug 31, 2019 at 10:01 AM ron minnich <rminnich at gmail.com> wrote:

> On Sat, Aug 31, 2019 at 5:05 AM Thomas Paulsen
> <thomas.paulsen at firemail.de> wrote:
> >
> >
> > --- Ursprüngliche Nachricht ---
> > Von: Steve Simon <steve at quintile.net>
> > Datum: 31.08.2019 11:44:22
> > An: tuhs at minnie.tuhs.org
> > Betreff: [TUHS] early vm systems
> >
> > > hi
> > >
> > > the other early vm system not mentioned yet is the one Charles Forsyth
> wrote
> > > at the university of york for sunos. i never used it as i was learning
> v7
> > > on an interdata 30 miles away at the time but i read his excellent
> paper
> > > on it.
> > did you mean:
> https://www.researchgate.net/publication/2411547_The_Mether_System_Distributed_Shared_Memory_for_SunOS_40
>
>
> no, that was me :-)
>
> charles' excellent paper,
> "More Taste: Less Greed?
> or
> Sending UNIX to the Fat Farm", http://www.terzarima.net/doc/taste.pdf
>
> is a good read, as is everything he writes.
>

It is a good read... Is Charles Forsyth's code available?

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190831/b5911fb4/attachment-0001.html>

From clemc at ccc.com  Sun Sep  1 05:03:46 2019
From: clemc at ccc.com (Clem Cole)
Date: Sat, 31 Aug 2019 15:03:46 -0400
Subject: [TUHS] dmr streams & networking [was: Re: If not Linux,
 then what?]
In-Reply-To: <alpine.BSF.2.21.9999.1908311531460.37360@aneurin.horsfall.org>
References: <1567196510.21824.for-standards-violators@oclsc.org>
 <CAC20D2OJ=uNZ0yMwpL13TPPW_q9tJeY6559gwsDGUYVkUin+TA@mail.gmail.com>
 <20190830215202.GA974@mcvoy.com>
 <CAC20D2Pp5hpZraaANsXg0Sgc-sU3fJ4=_N17ogQii3=p-H4Oeg@mail.gmail.com>
 <20190831011359.E9F491570CE9@mail.bitblocks.com>
 <88242A0D-D08E-47EB-84DC-A7205780A417@ccc.com>
 <E829BD14-88B7-4469-A1A4-7849BC87CB67@ccc.com>
 <alpine.BSF.2.21.9999.1908311531460.37360@aneurin.horsfall.org>
Message-ID: <CAC20D2MdDGGZ9Ex1k8vTifZUEKxk+dt+NcUeYm8HkPQMKpnAvA@mail.gmail.com>

On Sat, Aug 31, 2019 at 1:38 AM Dave Horsfall <dave at horsfall.org> wrote:

> Yep, that certainly rings a bell.  ISTR that Sun had a board with the two
> CPUs, one keeping an eye on the other.

Interesting, I was under the belief that Sun never even tried the trick (at
least as a product).  The original Stanford University Network (SUN) CPU
was built for an Intel Multibus (electrically and mechanically) but using a
single 68000 instead of an Intel processor.  The 'SUN' was designed by one
of Forest's graduate students (Andy Bechtolsheim
<https://en.wikipedia.org/wiki/Andy_Bechtolsheim>); and the University licensed
the design extremely cheaply throughout the valley (VLSI Tech, *a.k.a.* Sun
Microsystems, was only one of the licensees.  But for instance the original
Cisco AGS and the Imagen Laser printers both used CPU's licensed from the
Unversity).

FWIW: I knew Andy at CMU previously, he had designed a similar board for
the CMU front-end as I was leaving for Tektronix - when I was there we used
LSI-11s and Andy replaced that with an 8085 (then 8086) based Multibus
[IIRC, Phil Karn may have mixed up in all that too - he was hacking on what
would become KA9Q TCP on his Z80 and then the 8085.   We had all taken the
graduate realtime course from Steely Dan as lab partners and our big
project was based on hacks to that hardware].

That said, it was Forest that proposed the executor/fixer trick (as I say
he gave a paper at an Asilomar Microprocessor Conference which I have sadly
misplaced).   It is certainly possible that Andy tried building it, but the
only two firms that I know of that built processors using the idea were
Apollo and Masscomp (neither who used or licensed the SUN CPU design from
Stanford) although all of them used a flavor of the Multibus as their first
bus.

I don't know what Apollo did. The multibus mechanically had two connectors,
but the Intel-defined I/O bus was on the lower (larger connector).   At,
Masscomp the MC-500 a private (synchronous) memory bus, that was very
similar to the BI in its protocol (because Dave designed both of course).
It was built on the unused/undefined header and ran much faster than the
I/O bus since memory fetches occurred.  Also, the Masscomp >>card cage<<
was larger than Multibus (I think Apollo was also).   The shorter boards
fit into the backplane, the larger size allowed for more 'chips to fit.'
IIRC, with the original memory chips being used at the time, one reason why
the Masscomp was so much faster than the Sun-1 (and 2) was it had larger
memory capacity on its boards and the memory transaction were quicker.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190831/5c086792/attachment.html>

From tytso at mit.edu  Sun Sep  1 07:20:31 2019
From: tytso at mit.edu (Theodore Y. Ts'o)
Date: Sat, 31 Aug 2019 17:20:31 -0400
Subject: [TUHS] If not Linux, then what?
In-Reply-To: <CAFNqd5Ub6Xs2emHZpTeOi0Wd=R+ou0u4bUHs19Wyzr1ASn9GNg@mail.gmail.com>
References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net>
 <CAFNqd5VpUE9OsKqfHDW8-76S46PYtnTJWDWAs0FU6o+73B4ZfQ@mail.gmail.com>
 <20190828231952.GA536@mit.edu>
 <CAFNqd5Ub6Xs2emHZpTeOi0Wd=R+ou0u4bUHs19Wyzr1ASn9GNg@mail.gmail.com>
Message-ID: <20190831212031.GB3367@mit.edu>

On Sat, Aug 31, 2019 at 12:58:00PM -0400, Christopher Browne wrote:
> 
> I haven't seen reference to Bushnell in a long time; looks like he has
> shifted to ecclesiastical matters.  He was up to some interesting
> software things, once upon a time.

Thomas has been working for Google for a number of years.  (Brothers
of Saint Gregory are expected to support themselves, and so they tend
to have lay jobs in addition to their eccleiastical service.)

Thomas was working on supporting the Linux desktop for Google
engineers[1][2].  (At the time, Google was using Ubuntu LTS; these
days, Google desktops are using Debian testing[3].)

[1] https://www.youtube.com/watch?v=oGUzhiJu_Jg
[2] https://events.static.linuxfound.org/images/stories/pdf/lcna_co2012_bushnell.pdf
[3] https://www.ghacks.net/2018/01/24/google-switches-from-ubuntu-to-debian-as-base-for-their-in-house-os/

						- Ted


From gtaylor at tnetconsulting.net  Sun Sep  1 09:38:41 2019
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Sat, 31 Aug 2019 17:38:41 -0600
Subject: [TUHS] ISO, OSI, and DECnet (was Re: If not Linux, then what?)
In-Reply-To: <1d3d8c9a-7006-4666-b32e-8fa4fc5e9f7c@PU1APC01FT039.eop-APC01.prod.protection.outlook.com>
References: <CABH=_VTKJQ-+0h-PwbNta1CAgtO=8quGV9RonWDP64MoteeG9Q@mail.gmail.com>
 <20190828172451.GX13570@mcvoy.com> <20190828181727.GA82704@wopr>
 <CACytpF-E3C+VrFSXat+jKWiCOToyoDB4b5n9Jj723H=qSgxDXg@mail.gmail.com>
 <1d3d8c9a-7006-4666-b32e-8fa4fc5e9f7c@PU1APC01FT039.eop-APC01.prod.protection.outlook.com>
Message-ID: <118e62ef-db53-29e4-aa1b-72f8f8126f9e@spamtrap.tnetconsulting.net>

On 8/29/19 8:54 AM, Jason Stevens wrote:
> Although I never have seen OSI in the wild, it was the one great thing 
> about ‘Winsock’ is that it worked over TCP/IP , IPX/SPX, AppletTalk and 
> Decnet.  It was fun to convert a BBS from being telnet to some ‘telnet 
> over decnet’ monster I built.

TUHS might not be the place, perhaps COFF is, but I'd be curious to hear 
more about your monster.



-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4008 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190831/0ed7664e/attachment.bin>

From rudi.j.blom at gmail.com  Sun Sep  1 12:16:39 2019
From: rudi.j.blom at gmail.com (Rudi Blom)
Date: Sun, 1 Sep 2019 09:16:39 +0700
Subject: [TUHS] dmr streams & networking [was: Re: If not Linux,
 then what?]
Message-ID: <CAMYpm86_x+Z0ZuvKqRx6RN3T-n9iHwRz-8uor6OzmHUzjGkojw@mail.gmail.com>

I don't remember from where I got the scheme, so it might be general,
DigitalUnix, or HP-UX related. Checking the "HP 9000 networking XTI
programmer's guide" from 1995 there's no diagram.

The application which was initially developed on a SystemV derived
UNIX the Computer division of Philips Electronics had bought, used
TLI. Taken over by DEC we moved to SCO UNIX still using TLI, moving to
XLI on Alpha/Digital Unix.

The nice thing of TLI/XLI is the poll(). A multi-client server can
check a list of file descriptors AND indicate a timeout value for the
poll(). Like in
   	ret_cd = poll(tep->CEPlist, tep->CEPnumb, timeout);

BTW putting in a bit of OSI, on SCO UNIX I use a DEC package which
offers a TLI interface to an OSI TP4/IP stack. Even worked using X.25
as WAN. OSI TP4 and NetBIOS originally bought from Retix.

>Date: Sat, 31 Aug 2019 11:41:40 -0400
>From: Clem Cole <clemc at ccc.com>
>To: Rudi Blom <rudi.j.blom at gmail.com>
>Cc: tuhs <tuhs at minnie.tuhs.org>
>Subject: Re: [TUHS] dmr streams & networking [was: Re: If not Linux,then what?]
>Message-ID:
>        <CAC20D2MJPFoU6r73U9GDaqG+Q7vpH3T7CiDNjgN3D2uyuAJgLQ at mail.gmail.com>
>Content-Type: text/plain; charset="utf-8"
>
>It's the Mentant implementation that HP originally bought.  At LCC we had
>to hacked on it a bit when we put Transparent Network Computing (TNC) stuff
>in HP-UX  [we had full process migration working BTW -- A real shame that
>never shipped].

>On Sat, Aug 31, 2019 at 5:44 AM Rudi Blom <rudi.j.blom at gmail.com> wrote:

>> Whenever I hear UNIX, networking and streams I have to think about this
>> scheme.
>>
>> Still using this, even on HP-UX 11.31 on Itanium rx-servers
>>
>> Cheers,
>> uncle rubl

From rudi.j.blom at gmail.com  Sun Sep  1 12:36:33 2019
From: rudi.j.blom at gmail.com (Rudi Blom)
Date: Sun, 1 Sep 2019 09:36:33 +0700
Subject: [TUHS] dmr streams & networking [was: Re: If not Linux,
 then what?
Message-ID: <CAMYpm87rZYuba5w534ze_uG4U65h2z6zdX+GnMR6TS78Umkgew@mail.gmail.com>

Just to be precise and because I dislike loose ends :-)

Found the XTI to TCP/IP diagram. It's even online!
  https://www.cs.auckland.ac.nz/references/unix/digital/APS2WDTE/TITLE.HTM

Network Programmer's Guide
© Digital Equipment Corporation 1994, 1995, 1996
All Rights Reserved.
Product Version:  Digital UNIX Version 4.0 or higher
March 1996

From ggm at algebras.org  Mon Sep  2 10:13:54 2019
From: ggm at algebras.org (George Michaelson)
Date: Mon, 2 Sep 2019 10:13:54 +1000
Subject: [TUHS] systime
In-Reply-To: <20190830125739.9891418C0D3@mercury.lcs.mit.edu>
References: <20190830125739.9891418C0D3@mercury.lcs.mit.edu>
Message-ID: <CAKr6gn0Ji8wH9yeVtHmA+XAYnXk5Es17KDWW_XNFCcCU6W0qxA@mail.gmail.com>

Best works canteen *ever* . steak and chips for nothing. Also,
magstripes on the floor for "robot" porters to carry stuff around the
office.

John Bondi ran the research lab. He was the son of Hermann Bondi. He,
and Fred Hoyle promoted the "steady state" theory of the universe.
Nice guy. put up with me, anyway.

-G

On Fri, Aug 30, 2019 at 10:58 PM Noel Chiappa <jnc at mercury.lcs.mit.edu> wrote:
>
>     > From: Steve Simon
>
>     > i went for a student placement there but didnt get it - i guess my long
>     > hair (then) didn't fit as the interview seemed good.
>
> Maybe you seemed too honest! :-)
>
>       Noel

From peter at rulingia.com  Mon Sep  2 18:28:28 2019
From: peter at rulingia.com (Peter Jeremy)
Date: Mon, 2 Sep 2019 18:28:28 +1000
Subject: [TUHS] dmr streams & networking [was: Re: If not Linux,
 then what?]
In-Reply-To: <alpine.BSF.2.21.9999.1908311531460.37360@aneurin.horsfall.org>
References: <1567196510.21824.for-standards-violators@oclsc.org>
 <CAC20D2OJ=uNZ0yMwpL13TPPW_q9tJeY6559gwsDGUYVkUin+TA@mail.gmail.com>
 <20190830215202.GA974@mcvoy.com>
 <CAC20D2Pp5hpZraaANsXg0Sgc-sU3fJ4=_N17ogQii3=p-H4Oeg@mail.gmail.com>
 <20190831011359.E9F491570CE9@mail.bitblocks.com>
 <88242A0D-D08E-47EB-84DC-A7205780A417@ccc.com>
 <E829BD14-88B7-4469-A1A4-7849BC87CB67@ccc.com>
 <alpine.BSF.2.21.9999.1908311531460.37360@aneurin.horsfall.org>
Message-ID: <20190902082828.GL75146@server.rulingia.com>

On 2019-Aug-31 15:37:32 +1000, Dave Horsfall <dave at horsfall.org> wrote:
>Ah, those were the days :-)  Now, we just have to put up with Intel, 
>although I believe the ARM is much better.

Well, https://www.youtube.com/watch?v=_6sh097Dk5k paints a less rosy
picture of ARM.  Maybe RISC-V will succeed.

It's a bit dated and very off topic but http://www.cpushack.com/CPU/cpu.html
makes interesting reading.

-- 
Peter Jeremy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190902/5607b31f/attachment.sig>

From dave at horsfall.org  Tue Sep  3 09:26:29 2019
From: dave at horsfall.org (Dave Horsfall)
Date: Tue, 3 Sep 2019 09:26:29 +1000 (EST)
Subject: [TUHS] dmr streams & networking [was: Re: If not Linux,
 then what?]
In-Reply-To: <20190902082828.GL75146@server.rulingia.com>
References: <1567196510.21824.for-standards-violators@oclsc.org>
 <CAC20D2OJ=uNZ0yMwpL13TPPW_q9tJeY6559gwsDGUYVkUin+TA@mail.gmail.com>
 <20190830215202.GA974@mcvoy.com>
 <CAC20D2Pp5hpZraaANsXg0Sgc-sU3fJ4=_N17ogQii3=p-H4Oeg@mail.gmail.com>
 <20190831011359.E9F491570CE9@mail.bitblocks.com>
 <88242A0D-D08E-47EB-84DC-A7205780A417@ccc.com>
 <E829BD14-88B7-4469-A1A4-7849BC87CB67@ccc.com>
 <alpine.BSF.2.21.9999.1908311531460.37360@aneurin.horsfall.org>
 <20190902082828.GL75146@server.rulingia.com>
Message-ID: <alpine.BSF.2.21.9999.1909030925230.54037@aneurin.horsfall.org>

On Mon, 2 Sep 2019, Peter Jeremy wrote:

> Well, https://www.youtube.com/watch?v=_6sh097Dk5k paints a less rosy
> picture of ARM.  Maybe RISC-V will succeed.
>
> It's a bit dated and very off topic but http://www.cpushack.com/CPU/cpu.html
> makes interesting reading.

Most interesting; thanks.

-- Dave

From aek at bitsavers.org  Thu Sep  5 15:11:34 2019
From: aek at bitsavers.org (Al Kossow)
Date: Wed, 4 Sep 2019 22:11:34 -0700
Subject: [TUHS] dmr streams & networking [was: Re: If not Linux,
 then what?]
In-Reply-To: <CAC20D2MdDGGZ9Ex1k8vTifZUEKxk+dt+NcUeYm8HkPQMKpnAvA@mail.gmail.com>
References: <1567196510.21824.for-standards-violators@oclsc.org>
 <CAC20D2OJ=uNZ0yMwpL13TPPW_q9tJeY6559gwsDGUYVkUin+TA@mail.gmail.com>
 <20190830215202.GA974@mcvoy.com>
 <CAC20D2Pp5hpZraaANsXg0Sgc-sU3fJ4=_N17ogQii3=p-H4Oeg@mail.gmail.com>
 <20190831011359.E9F491570CE9@mail.bitblocks.com>
 <88242A0D-D08E-47EB-84DC-A7205780A417@ccc.com>
 <E829BD14-88B7-4469-A1A4-7849BC87CB67@ccc.com>
 <alpine.BSF.2.21.9999.1908311531460.37360@aneurin.horsfall.org>
 <CAC20D2MdDGGZ9Ex1k8vTifZUEKxk+dt+NcUeYm8HkPQMKpnAvA@mail.gmail.com>
Message-ID: <5ee4518e-7e37-2896-3b25-f0a77c34e67b@bitsavers.org>

On 8/31/19 12:03 PM, Clem Cole wrote:
>
>
> I was under the belief that Sun never even tried the trick

Correct.

The original pre-BSD Sun-1 used the Stanford CPU,
ran Unisoft and used the stack probe hack in the compiler.

SunOS 1 required a 68010 'brain transplant'





From imp at bsdimp.com  Mon Sep  9 16:25:05 2019
From: imp at bsdimp.com (Warner Losh)
Date: Mon, 9 Sep 2019 00:25:05 -0600
Subject: [TUHS] PWB vs Unix/TS
Message-ID: <CANCZdfpEu6OxvmhDGSa3Cw4TSpfcbBOFbJjU7nZU-C_JFGFdRA@mail.gmail.com>

OK. I'm totally confused, and I see contradictory information around. So I
thought I'd ask here.

PWB was started to support unix time sharing at bell labs in 1973 (around
V4 time).
PWB 1.0 was released just after V6 "based on" it. PWB 2.0 was released just
after V7, also "based on it". Later Unix TS 3.0 would become System III. We
know there was no System I or System II. But was there a Unix TS 1.0 and
2.0? And were they the same thing as PWB 1.0 and 2.0, or somehow just
closely related? And I've seen both Unix/TS and Unix TS. Is there a
preferred spelling?

Thanks for all your help with this topic and sorting things out. It's been
quite helpful for my talk in a few weeks.

Warner

P.S. Would it be inappropriate to solicit feedback on an early version of
my talk from this group? I'm sure they would be rather keener on catching
errors in my understanding of Unix history than just about any other
forum...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190909/317d352d/attachment.html>

From arnold at skeeve.com  Mon Sep  9 16:36:19 2019
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Mon, 09 Sep 2019 00:36:19 -0600
Subject: [TUHS] PWB vs Unix/TS
In-Reply-To: <CANCZdfpEu6OxvmhDGSa3Cw4TSpfcbBOFbJjU7nZU-C_JFGFdRA@mail.gmail.com>
References: <CANCZdfpEu6OxvmhDGSa3Cw4TSpfcbBOFbJjU7nZU-C_JFGFdRA@mail.gmail.com>
Message-ID: <201909090636.x896aK1A001747@freefriends.org>

I can't answer your question, but I can tell you that there was
a UNIX 4.0 inside the Bell System.  The policy at the time (1983) was to
release externally one release behind the current internal release.
That changed with UNIX 5.0 which was released internally and externally
at the same time, becoming System V.

Then the marketing people got involved, and didn't want System VI as
the next release, so they went to System V Release 2, 3, and 4.

As to previewing your talk, why not?

Arnold

Warner Losh <imp at bsdimp.com> wrote:

> OK. I'm totally confused, and I see contradictory information around. So I
> thought I'd ask here.
>
> PWB was started to support unix time sharing at bell labs in 1973 (around
> V4 time).
> PWB 1.0 was released just after V6 "based on" it. PWB 2.0 was released just
> after V7, also "based on it". Later Unix TS 3.0 would become System III. We
> know there was no System I or System II. But was there a Unix TS 1.0 and
> 2.0? And were they the same thing as PWB 1.0 and 2.0, or somehow just
> closely related? And I've seen both Unix/TS and Unix TS. Is there a
> preferred spelling?
>
> Thanks for all your help with this topic and sorting things out. It's been
> quite helpful for my talk in a few weeks.
>
> Warner
>
> P.S. Would it be inappropriate to solicit feedback on an early version of
> my talk from this group? I'm sure they would be rather keener on catching
> errors in my understanding of Unix history than just about any other
> forum...

From clemc at ccc.com  Wed Sep 11 01:16:34 2019
From: clemc at ccc.com (Clem Cole)
Date: Tue, 10 Sep 2019 11:16:34 -0400
Subject: [TUHS] PWB vs Unix/TS
In-Reply-To: <CANCZdfpEu6OxvmhDGSa3Cw4TSpfcbBOFbJjU7nZU-C_JFGFdRA@mail.gmail.com>
References: <CANCZdfpEu6OxvmhDGSa3Cw4TSpfcbBOFbJjU7nZU-C_JFGFdRA@mail.gmail.com>
Message-ID: <CAC20D2Pz+gwyeuVYcHFbJaimHtrt+sKSvCFp=hMZNoAWr4G09Q@mail.gmail.com>

Below ... from memory - Someone like APS was a little closer to some of
this than I was, so I might have a few things wrong.  I don't think so, but
it's been quite a few beers

On Mon, Sep 9, 2019 at 2:26 AM Warner Losh <imp at bsdimp.com> wrote:

> OK. I'm totally confused, and I see contradictory information around. So I
> thought I'd ask here.
>
> PWB was started to support unix time sharing at bell labs in 1973 (around
> V4 time).
>
No...  that is not quite right.  PWB was Mashey's project to build an RJE
system to front end SW development for the IBM systems, which AT&T had a
number [IIRC Call Accounting and lot of the 'business' part of the Bell
System was mainframe based].  I think Dick Haight was also involved.  I've
forgotten the site there were at.  It might have been Holmdel or Whippany.
But it was not MH or Summit.



> PWB 1.0 was released just after V6 "based on" it.
>
Well not so much "right after", but it was based on V6.  There are
differences.  IIRC this was the first attempt at redoing how groups
worked.  The biggest additions were an IBM RJE support, SCCS and a
different set of backup utilities; including some disk to disk (volcpy) and
the original binary formatted program for 9-tracks (cpio) to replace
Ken's assembler
based tp.

SCCS was important and the RJE support was important because that was the
system being used and it made a huge impression on AT&T staff.   A terminal
to a UNIX box was way cheaper and to the IBM and people were so much more
productive.

Also remember, that tp(1) was written in assembler had been originally
targeted to DECtape in a very early version of Research UNIX.  The DECtape
nature is why the directory was on the front of the tape.  Ken moved it
9-track but used the same tape format.   I don't remember who wrote stp
(super-tp - in C), [?? Harvard ?? it's on the Harvard tape and is how I got
it].   But better peripheral support was really important in Mashey's
setting.  In that world, the production computer system was being put in
the raised floor computer rooms next to a mainframe and they had
'operators' so John and team started to think more about what was needed to
admin the system.   IMHO: this was the first heavy use of shell scripts,
while I saw them in MH, it was Mashey's guys that cause me personally to
have an ah-ha moment about them.

Interestingly enough, and I have talked to Bourne and Mashey about it,
John's use of the V6 was definitely one of the groups that were asking for
a new shell, which Bourne set out to solve; but that is not yet available.

At some point (and here is where we need Steve Johnson, aps, and I wish the
late Ted Kowalski) to fill in details I can not.  USG/Summit was chartered
to "support UNIX for the Bell System."   As I understand it, the genesis
for their system was a kernel from MH that was moving towards V7s but not
there yet, the 'Typesetter C' and a bunch of other utilities that Summit
had collected/developed, but which I do not know.  I think fsdb was around
by that time. The new Bourne Shell and adb were being developed although
how complete I'm not sure.

But accept for the new shell and updated compiler, I remember the system
'felt' like V6 (Thompson shell) and thinking how much 'better' different v7
(Bourne Shell was) when we finally got it. This earlier system is the one
Ted brought to CMU in the fall 1977 (I think that is the right date) to
update the V6 system were then running.  Anyway, Ted always referred to
this as a UNIX/TS kernel.

Another thing we did not have SCCS or the RJE stuff.  What I'm not sure of
is if there was a formally release of what ted had.  So it may have been
that TS had them and sent the release to Mashey, although I don't think
there were such releases originally in TS.  FWIW: I believe that in our
(CMU) case,Ted would just grab things as they appeared that he thought we
needed at CMU and he pushed things back (like CMU's fsck as he found things
we had that he thought we would like).  Interestingly enough, RJE and SCCS
was needed for the IBM support and while Ted (and his undergrad roommate,
Bill Joy) had worked on the MTS system on the IBM's at UMich, I always felt
like Ted looked down on the mainframes (which was were I had also emerged
but from CMU's TSS team).

Also, Ted was a die-hard original cpio user and I liked the user interface
to stp, which I remember was a difference/source of argument.   Tar did not
yet exist. TS had some of the PWB tools like volcpy; but we were using DOS-11's
similar but different backup scheme (I've forgotten the name of the format;
but the tapes were boot-able, which volcpy tapes were not).

FWIW:  cu(1) did not yet exist.  I wrote a program (that I tended to prefer
in some ways for many years) called connect(1cmu) that did the same thing.
We used it to download images to the Microprocessors like the KIM-1.   It
was originally written with the v6 portable C library, which is also what
the original fsck used (it's what we had on v6).   Ted introduced me to
what would become stdio and one of my first tasks was using it with
connect(1cmu).  The other thing I remember about that program is it was the
first time I wrote something that used two separate processes on a UNIX
system that cooperated with each other and found it so much easier than on
the PDP-10.

Also, Dennis' stand-alone system for V7 was not yet available BTW.   If I
think of anything else about that system I can remember, I'll send an update

PWB 2.0 was released just after V7, also "based on it".
>
I think the confusion is that TS and V7 were done sort of at the same time
and while the folks working on them talked to each other, it has never been
clear to me who was behind TS. For instance, I would learn that Bourne was
the 'project leader' for Seventh, in that he was the person that collected
everything for it.  I never heard of someone having the same role for TS,
which is why I sometimes think it was a name inside of Summit, but never
actually saw the light of day as a formal release.   I really am not sure
and would love to learn more details (I wish Ted were still alive to fill
us in).

As for V7 itself, Ken wrote tar(1) in response to cpio (preferring an ASCII
based header, but 'threading' it like cpio did, but keeping the user
interface that tp/stp had).  As I understand it, Dennis built up did the
standalone toolkit stuff.  Ken changed groups and messed with the file system
in the kernel.  Lots of new peripheral support, which is why he also added
lseek() as disks overflowed a 16-bit integer for the seek position.  Plus
there were a number of other small changes between v6 and v7.  Some of this
stuff from PWB and Summit went back to MH (fsck as an example), but not
everything (like cpio/volcpy/SCCS).  I kind of think of the kernel and
Typesetter C going from MH to Summit and the PWB teams.

@Steve Johnson, I need your help here.... at some point PCC was created in
MH (along with lint).  Didn't that start on V6 but was not complete until
V7? And when did you move to Summit to lead the compiler effort there?  My
impressions that was yet to happen, but I'm fuzzy on dates.

Remember, there are a number of teams at BTL hacking on UNIX by then.
Dale's team in Columbus, the crew in Indiana Hill,  folks at Western
Electric (the Teletype folks ported the Ritchie C to the Z80 at some point
for instance), *etc.*

Again, I don't remember the politics but like any big company, you can
imagine it was not all that clean and crisp.   PWB 2.0 & 3.0 definitely
picked up features from other UNIX systems.  As I remember, Dale's shared
memory hacks would beget System V Shared Mem, Semaphores and IPC (they are
different, but they started in Columbus).

The other thing I'm not clear on is when the PWB team was folded into USG (Unix
Support Group) in Summit.  *I believe* that was after PWB 2.0 was
released.  But at some point, Mashey's team and the USG got interwoven.  I
really don't know/remember many of those details as I watched them from the
outside and only knew the results.  The key point is the PWB 2.0 would
eventually be released as the internal, but official UNIX for the Bell
System.   It was supposed to bring together the needed from the different
labs; but it was not >>officially<< released *outside of the Bell System*
(it was an internal product, remember at this point, AT&T is not allowed to
have computer products, etc...)

So PWB 2.0 is basically internal, and a melding of V7, TS, PWB 1.0 and
starting to take things from different labs with in BTL -- different from
all of them but mostly a superset.




> Later Unix TS 3.0 would become System III.
>
No --I do not think this is a true statement... not sure where you got
that, more in a minute

We know there was no System I or System II.
>
Correct.

But was there a Unix TS 1.0 and 2.0?
>
This is where it gets sticky.  I don't think so.   TS was the original work
by USG.   What I do not know is if it ever was 'packaged' as PWB had been. *I
do not believe it was*.   I think a little like the way Research 'bled' out
a little a time, pieces of TS made their way to MIT, CMU, *etc*. but never
as a formal release.


> And were they the same thing as PWB 1.0 and 2.0, or somehow just closely
> related?
>
See above... I'll explain how PWB 3.0 became System III in a minute.


> And I've seen both Unix/TS and Unix TS. Is there a preferred spelling?
>
Don't know.  I remember Ted always called it UNIX/TS all caps.

The thing you left out is how PWB 3.0 became System III.

Two important issues.  First with V7, AT&T (Al Arms) wrote the first binary
system redistribution license.  The commercial folks were happy to have a
redistribution license, but the terms were not what they really needed.
Much of the issue was that AT&T was not the computer hardware or software
business and really did not understand the issues that the vendors had.
Professor Dennis Allison of Stanford, was consulting for almost all of us
in the computer industry at the time (for those that don't know Dennis,
around the same time he founded what is now called the Asilomar
Microprocessor Workshop (check out:
https://www.computerhistory.org/atchm/the-asilomar-microcomputer-workshop-and-the-billion-dollar-toilet-seat/
).

Dennis arranged for a big meeting at Ricki's Hyatt in Palo Alto and invited
Al Arms and team, plus a representatives from his clients. I was the techie
with a lawyer from Tektronix in the room (as I have said in other emails
this it is only time I have been in a meeting with Bill Gates).  The folks
I remember who were there: was Bill Munson and team from DEC; Fred Clegg
and Team from HP; Bob MetCalfe from 3Com; Gates and the MSFT crew; folks
from SCO and DG.   There were some others, about 10 firms in total;
although I think if remember correctly, IBM was not among them [This is the
meeting where Gates famously exclaimed: "*You guys don't get it.  The only
thing that matters in the software industry is volume*."].

BTW: The bits we were discussing was the upcoming release from USG, to be
called PWB 3.0 and they were for the PDP-11 only (which was fine, that was
what we all had been licensing already.  We could still use things from
other places, because that is what those other places were all licensed to
have -- all was good in UNIX-land).

Thus began a series of negotiations for a new license agreement that would
allow the HW vendors to better ship UNIX as a binary product:  FWIW: Gates
wanted to pay $25/copy.   The DEC, HP and DG folks laughed.  $1K/copy was
fine by them, since their HW was typically $50-150K/system.

Either shortly after or maybe during the negotiations time, Judge Green
ruled and AT&T got broken up.   One of the things that occured is that AT&T
was now allowed to sell SW and more importantly their new 3B20 as a product
(against IBM and DEC).  From a SW standpoint, AT&T Marketing did not like
the 'Programmers' moniker, feeling that it would limit who they could sell
too.  So they rebranded the new software product 'System III.'

Note the printing of the manuals had already begun, which is why the cover
of the manuals say System III, but the title pages say PWB 3.0.

As other have said a few years later, another PWB release came out for the
Bell System, *a.k.a.* PWB 4.0; but this was not licensed outside.

At some point later, negotiations had restarted on yet another license with
the System III licensees and AT&T.   By the time that completed, yet
another release had been finished by USG.  The biggest change was the
addition support for HW besides the PDP-11. In particular, the official USG
support for the VAX and the 3B20.  What I forget, but I think in that
license you had to declare a system type and most licensees picked the VAX.

By the time of release and finalization of the license, AT&T Marketing
which had already started the '*Consider it Standard*' campaign, called the
new release "System V."

AT&T Marketing would stay with System V moniker from then on and we know
have SVR2, SVR3, SVR4, SVR5 in later years.


> Thanks for all your help with this topic and sorting things out. It's been
> quite helpful for my talk in a few weeks.
>
> Warner
>
> P.S. Would it be inappropriate to solicit feedback on an early version of
> my talk from this group?
>
I would suggest sending a pointer to this group to the slides and ask for
people to send you comments privately.



> I'm sure they would be rather keener on catching errors in my
> understanding of Unix history than just about any other forum...
>
Indeed - happy to help.
Clem
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190910/949df373/attachment.html>

From scj at yaccman.com  Wed Sep 11 10:28:41 2019
From: scj at yaccman.com (Steve Johnson)
Date: Tue, 10 Sep 2019 17:28:41 -0700
Subject: [TUHS] PWB vs Unix/TS
In-Reply-To: <CAC20D2Pz+gwyeuVYcHFbJaimHtrt+sKSvCFp=hMZNoAWr4G09Q@mail.gmail.com>
Message-ID: <99b89a5f55b82dcf67f7bebe92b752a5b0e0a72d@webmail.yaccman.com>

Well, I can share a bit of the piece of the elephant(s) I saw.

While most of the Unix folks were PDP-11 only (after MULTICS), I had
spent a couple of years helping to run the MH comp center.   The
system for the IBM 7094 was among the best anywhere -- card decks were
staged to tape and the overhead of changing from one job to the next
was minimized.  Most modest-sized job submissions were finished in
roughly an hour.   When MULTICS started, the 7094 went away and it
was a huge jolt.  There were some amazing programs (e.g., a LISP
compiler written in MACRO FAP that would go 250 levels deep to produce
good code).  There were acoustic simulation programs that were way
ahead of their time.  And they were all lost.

With MULTICS still way in the future and no more 7094, a software
package was put together to allow the MULTICS machines to run the
commercial GCOS system (the software was called the K package, K
standing for kluge.  It was well named...)   Anyhow, they needed
help, and asked me to help, and I did so for a couple of years,
largely supporting FORTRAN.   Meanwhile, Dennis was inventing B, and
there was a limping version for the GE.  He may have actually used it
as part of a bootstrap of the language -- I'm not sure.  So I
discovered it, and started to use it to write some system admin
programs.  I soon ran into some limitations, and started to lobby
Dennis for some changes.  He listened politely, and then said "Why
don't you fix it.  The compiler is just a program, after all..."  
So I put some things into B, including support for the GE native 6-bit
character set.  This eventually found its way into C and CPP. 
Decades later, if you wrote `abc` in the DEC C compiler, it produced
GE strings...   I also made it possible to call FORTRAN from C (the
other way was a bit harder...).

Eventually they set up an organization to formally own running the
comp center, and I was invited to return to Research and I did.  
But I had gained a lot of sensitivity to the needs of Engineers and
Scientists just wanting to get their work done. 

Years later, when I was asked to come over to Summit and head the
System V language department, V7 was behind us, and the Interdata port
had taught us a lot about portability.  PCC had proved itself on a
half dozen machines and had been well received.  But most of the Bell
System was using 16-bit DEC machines and Dennis' compiler.  C++ was
under develpment and looked like a clear winner, but it needed a lot
of work.  The debugging of C++ was horrible -- a program, Cfront,
converted C++ to C, but in the process screwed up the line numbers and
names so that using a debugger was almost impossible.   My three
goals in going to Summit were to make C++ commercially available, to
provide a debugging technology that could handle not just C++ and C
but FORTRAN and ADA and PASCAL, and to base the code generation on the
PCC2 model to gain portability.  Although AT&T's computer business
was pretty much a disaster, I felt that I had met these goals  -- Elf
and Dwarf, C++ debugging, and the first commercial C++ product
happened on my watch.  I also had a lot of fun working with a bright
and diverse group of talented people.

Sadly, as the AT&T computer business collapsed, I realized that I
loved doing advanced development, but not at ATT.  My final straw was
when an excellent QA team leader at another location was fired for
telling the truth about how lousy one of the machines performed.  So
it was off to Silicon Valley for me.

Steve

----- Original Message -----
From:
 "Clem Cole" <clemc at ccc.com>

To:
"Warner Losh" <imp at bsdimp.com>
Cc:
"The Eunuchs Hysterical Society" <tuhs at tuhs.org>
Sent:
Tue, 10 Sep 2019 11:16:34 -0400
Subject:
Re: [TUHS] PWB vs Unix/TS

Below ... from memory - Someone like APS was a little closer to some
of this than I was, so I might have a few things wrong.  I don't
think so, but it's been quite a few beers

On Mon, Sep 9, 2019 at 2:26 AM Warner Losh <imp at bsdimp.com [1]> wrote:

OK. I'm totally confused, and I see contradictory information around.
So I thought I'd ask here.

PWB was started to support unix time sharing at bell labs in 1973
(around V4 time).

No...  that is not quite right.  PWB was Mashey's project to build
an RJE system to front end SW development for the IBM systems, which
AT&T had a number [IIRC Call Accounting and lot of the 'business' part
of the Bell System was mainframe based].  I think Dick Haight was
also involved.  I've forgotten the site there were at.  It might
have been Holmdel or Whippany. But it was not MH or Summit.

 

PWB 1.0 was released just after V6 "based on" it.

Well not so much "right after", but it was based on V6.  There are
differences.  IIRC this was the first attempt at redoing how groups
worked.  The biggest 

additions were

 an IBM RJE support, 
SCCS and a different set of backup utilities; 
including some disk to disk (volcpy) 
and the original binary formatted program for 9-tracks (
cpio)
 to replace Ken's assembler based 
tp.

SCCS was important and the RJE support was important because that was
the system being used and it made a huge impression on AT&T staff. 
 A terminal to a UNIX box was way cheaper and to the IBM and people
were so much more productive.

Also remember, that tp(1) was written in assembler had been originally
targeted to DECtape in a very early version of Research UNIX.  The
DECtape nature is why the directory was on the front of the tape. 
Ken moved it 9-track but used the same tape format.   I don't
remember who

 wrote stp (super-tp - in C), [?? Harvard ?? it's on the Harvard tape
and is how I got it].
   But better peripheral support was really important in Mashey's
setting.  In that world, the production computer system was being put
in the raised floor computer rooms next to a mainframe and they had
'operators' so John and team started to think more about what was
needed to admin the system.   IMHO: this was the first heavy use of
shell scripts, while I saw them in MH, it was Mashey's guys that cause
me personally to have an ah-ha moment about them.

Interestingly enough, and I have talked to Bourne and Mashey about it,
John's use of the V6 was definitely one of the groups that were asking
for a new shell, which Bourne set out to solve; but that is not yet
available.

At some point (and here is where we need Steve Johnson, aps, and I
wish the late Ted Kowalski) to fill in details I can not.  USG/Summit
was chartered to "support UNIX for the Bell System."   As I
understand it, the genesis for their system was a kernel from MH that
was moving towards V7s but not there yet, the 'Typesetter C' and a
bunch of other utilities that Summit had collected/developed, but
which I do not know.  I think fsdb was around by that time. The new
Bourne Shell and adb were being developed although how complete I'm
not sure.

But accept for the new shell and updated compiler, I remember the
system 'felt' like V6 (Thompson shell) and thinking how much 'better'
different v7 (Bourne Shell was) when we finally got it. This earlier
system is the one Ted brought to CMU in the fall 1977 (I think that is
the right date) to update the V6 system were then running.  Anyway,
Ted always referred to this as a UNIX/TS kernel.

Another thing we did not have SCCS or the RJE stuff.  

What I'm not sure of is if there was a formally release of what ted
had
.  So it may have been that TS had them and sent the release to
Mashey, although I don't think there were such releases originally in
TS.  FWIW:
 I believe that in our (CMU) case,
Ted
 would just grab things as they appeared that he thought 
we needed at CMU 
and he pushed things back (like CMU's 
fsck as he found things we had that he thought we would like). 
Interestingly enough, RJE and SCCS was needed for the IBM support and
while Ted (and his undergrad roommate, Bill Joy) had worked on the MTS
system on the IBM's at UMich, I always felt like Ted looked down on
the mainframes (which was were I had also emerged but from CMU's TSS
team).

Also,
 Ted was a die-hard original 
cpio user and I liked the user interface to stp, which I remember was
a difference/source of argument
.   Tar did not yet exist. TS had some of the PWB tools like volcpy;
but we were using DOS-
11's similar but different backup 
scheme (I've forgotten the name of the format; but the tapes were
boot-able, which volcpy tapes were not).

FWIW:  cu(1) did not yet exist.  I wrote a program (that I tended to
prefer in some ways for many years) called connect(1cmu) that did the
same thing.  We used it to download images to the Microprocessors
like the KIM-1.   It was originally written with the v6 portable C
library, which is also what the original fsck used (it's what we had
on v6).   Ted introduced me to what would become stdio and one of my
first tasks was using it with connect(1cmu).  The other thing I
remember about that program is it was the first time I wrote something
that used two separate processes on a UNIX system that cooperated with
each other and found it so much easier than on the PDP-10.

Also, Dennis' stand-alone system for V7 was not yet available BTW. 
 If I think of anything else about that system I can remember, I'll
send an update

PWB 2.0 was released just after V7, also "based on it".

I think the confusion is that TS and V7 were done sort of at the same
time and while the folks working on them talked to each other, it has
never been clear to me who was behind TS. For instance, I would learn
that Bourne was the 'project leader' for Seventh, in that he was the
person that collected everything for it.  I never heard of someone
having the same role for TS, which is why I sometimes think it was a
name inside of Summit, but never actually saw the light of day as a
formal release.   I really am not sure and would love to learn more
details (I wish Ted were still alive to fill us in).

As for V7 itself, Ken wrote tar(1)
 in response to cpio (preferring an ASCII based header, but
'threading' it like cpio did, but keeping the user interface that
tp/stp had).  As I understand it, Dennis built up did the standalone
toolkit stuff.  Ken changed groups and messed with the file 
system 
in 
the kernel.  Lo

ts of new peripheral support, which is why he also added lseek() as
disks overflowed a 16-bit integer for the seek position
.  Plus there were a number of other small changes between v6 and
v7.  Some of this stuff from PWB and Summit went back to MH (fsck as
an example), but not everything (like cpio/volcpy/SCCS).  I kind of
think of the kernel and Typesetter C going from MH to Summit and the
PWB teams.

@Steve Johnson, I need your help here.... at some point PCC was
created in MH (along with lint).  Didn't that start on V6 but was not
complete until V7? And when did you move to Summit to lead the
compiler effort there?  My impressions that was yet to happen, but
I'm fuzzy on dates.

Remember, there are a number of teams at BTL hacking on UNIX by
then.  Dale's team in Columbus, the crew in Indiana Hill,  folks at
Western Electric (the Teletype folks ported the Ritchie C to the Z80
at some point for instance), _etc._

Again, I don't remember the politics but like any big company, you can
imagine it was not all that clean and crisp.   PWB 2.0 & 3.0
definitely picked up features from other UNIX systems.  As I
remember, Dale's shared memory hacks would beget System V Shared Mem,
Semaphores and IPC (they are different, but they started in Columbus).

The other thing I'm not clear on is when the PWB team was folded into
USG (

Unix Support Group)
 in Summit.  
_I believe_ that was after PWB 2.0 was released.  
But at some point, Mashey's team and the USG got interwoven.  I
really don't know/remember many of those details as I watched them
from the outside and only knew the results.  The key point is the PWB
2.0 would eventually be released as the internal, but 
official
 UNIX for the Bell System.   It was supposed to bring together the
needed from the different labs; but it was not >>
officially
<< released _outside of the Bell System_ (it was an internal product,
remember at this point, AT&T is not allowed
 to have computer products, etc...) 

So PWB 2.0 is basically internal, and a melding of V7, TS, PWB 1.0 and
starting to take things from different labs with in BTL -- different
from all of them but mostly a superset.

 
 Later Unix TS 3.0 would become System III.

No --I do not think this is a true statement... not sure where you got
that, m
ore in a minute

We know there was no System I or System II. 

Correct.  

But was there a Unix TS 1.0 and 2.0? 

This is where it gets sticky.  I don't think so.   TS was the
original work by USG.   What I do not know is if it ever was
'packaged' as PWB had been. _I do not believe it was_.   I think a
little like the way Research 'bled' out a little a time, pieces of TS
made their way to MIT, CMU, _etc_. but never as a formal release.

 
And were they the same thing as PWB 1.0 and 2.0, or somehow just
closely related? 

See above... I'll explain how PWB 3.0 became System III in a minute.

 

And I've seen both Unix/TS and Unix TS. Is there a preferred spelling?

Don't know.  I remember Ted always called it UNIX/TS all caps.

The thing you left out is how PWB 3.0 became System III.

Two important issues.  First with V7, AT&T (Al Arms) wrote the first
binary system redistribution license.  The commercial folks were
happy to have a redistribution license, but the terms were not what
they really needed.  Much of the issue was that AT&T was not the
computer hardware or software business and really did not understand
the issues that the vendors had.  Professor Dennis Allison of
Stanford, was consulting for almost all of us in the computer
industry at the time (for those that don't know Dennis, around the
same time he founded what is now called the Asilomar Microprocessor
Workshop (check out: 
https://www.computerhistory.org/atchm/the-asilomar-microcomputer-workshop-and-the-billion-dollar-toilet-seat/
[2]).

Dennis arranged for a big meeting at Ricki's Hyatt in Palo Alto and
invited Al Arms and team, plus a representatives from his clients. I
was the techie with a lawyer from Tektronix in the room (as I have
said in other emails this it is only time I have been in a meeting
with Bill Gates).  The folks I remember who were there: was Bill
Munson and team from DEC; Fred Clegg and Team from HP; Bob MetCalfe
from 3Com; Gates and the MSFT crew; folks from SCO and DG.   There
were some others, about 10 firms in total; although I think if
remember correctly, IBM was not among them [This is the meeting where
Gates famously exclaimed: "_You guys don't get it.  The only thing
that matters in the software industry is volume_."].

BTW: The bits we were discussing was the upcoming release from USG, to
be called PWB 3.0 and they were for the PDP-11 only (which was fine,
that was what we all had been licensing already.  We could still use
things from other places, because that is what those other places were
all licensed to have -- all was good in UNIX-land).

Thus began a series of negotiations for a new license agreement that
would allow the HW vendors to better ship UNIX as a binary product: 
FWIW: Gates wanted to pay $25/copy.   The DEC, HP and DG folks
laughed.  $1K/copy was fine by them, since their HW was typically
$50-150K/system.

Either shortly after or maybe during the negotiations time, Judge
Green ruled and AT&T got broken up.   One of the things that occured
is that AT&T was now allowed to sell SW and more importantly their new
3B20 as a product (against IBM and DEC).  From a SW standpoint, AT&T
Marketing did not like the 'Programmers' moniker, feeling that it
would limit who they could sell too.  So they rebranded the new
software product 'System III.'

Note the printing of the manuals had already begun, which is why the
cover of the manuals say System III, but the title pages say PWB 3.0.

As other have said a few years later, another PWB release came out for
the Bell System, _a.k.a._ PWB 4.0; but this was not licensed outside.

At some point later, negotiations had restarted on yet another
license with the System III licensees and AT&T.   By the time that
completed, yet another release had been finished by USG.  The biggest
change was the addition support for HW besides the PDP-11. In
particular, the official USG support for the VAX and the 3B20.  What
I forget, but I think in that license you had to declare a system type
and most licensees picked the VAX.

By the time of release and finalization of the license, AT&T Marketing
which had already started the '_Consider it Standard_' campaign,
called the new release "System V."

AT&T Marketing would stay with System V moniker from then on and we
know have SVR2, SVR3, SVR4, SVR5 in later years.

Thanks for all your help with this topic and sorting things out. It's
been quite helpful for my talk in a few weeks.

Warner

P.S. Would it be inappropriate to solicit feedback on an early version
of my talk from this group?

I would suggest sending a pointer to this group to the slides and ask
for people to send you comments privately.

 
 I'm sure they would be rather keener on catching errors in my
understanding of Unix history than just about any other forum...

Indeed - happy to help.

Clem
 

 

Links:
------
[1] mailto:imp at bsdimp.com
[2]
https://www.computerhistory.org/atchm/the-asilomar-microcomputer-workshop-and-the-billion-dollar-toilet-seat/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190910/9995f04d/attachment-0001.html>

From imp at bsdimp.com  Wed Sep 11 13:53:19 2019
From: imp at bsdimp.com (Warner Losh)
Date: Tue, 10 Sep 2019 21:53:19 -0600
Subject: [TUHS] PWB vs Unix/TS
In-Reply-To: <CAC20D2Pz+gwyeuVYcHFbJaimHtrt+sKSvCFp=hMZNoAWr4G09Q@mail.gmail.com>
References: <CANCZdfpEu6OxvmhDGSa3Cw4TSpfcbBOFbJjU7nZU-C_JFGFdRA@mail.gmail.com>
 <CAC20D2Pz+gwyeuVYcHFbJaimHtrt+sKSvCFp=hMZNoAWr4G09Q@mail.gmail.com>
Message-ID: <CANCZdfpsXnbaQJo54qw689-unmVb35114PrOuNXHrcyp2Cng5g@mail.gmail.com>

On Tue, Sep 10, 2019 at 9:17 AM Clem Cole <clemc at ccc.com> wrote:

> Below ... from memory - Someone like APS was a little closer to some of
> this than I was, so I might have a few things wrong.  I don't think so, but
> it's been quite a few beers
>
> On Mon, Sep 9, 2019 at 2:26 AM Warner Losh <imp at bsdimp.com> wrote:
>
>> OK. I'm totally confused, and I see contradictory information around. So
>> I thought I'd ask here.
>>
>> PWB was started to support unix time sharing at bell labs in 1973 (around
>> V4 time).
>>
> No...  that is not quite right.  PWB was Mashey's project to build an RJE
> system to front end SW development for the IBM systems, which AT&T had a
> number [IIRC Call Accounting and lot of the 'business' part of the Bell
> System was mainframe based].  I think Dick Haight was also involved.  I've
> forgotten the site there were at.  It might have been Holmdel or Whippany.
> But it was not MH or Summit.
>

"The Programmer's Workbench was started in 1973,[2]
<https://en.wikipedia.org/wiki/PWB/UNIX#cite_note-Mashey-2> by Evan Ivie
and Rudd Canaday to support a computer center for a 1000-employee Bell Labs
division" is what wikipedia says, though that reference is in a acm queue
article by Mashey...

PWB 1.0 was released just after V6 "based on" it.
>>
> Well not so much "right after", but it was based on V6.  There are
> differences.  IIRC this was the first attempt at redoing how groups
> worked.  The biggest additions were an IBM RJE support, SCCS and a
> different set of backup utilities; including some disk to disk (volcpy) and
> the original binary formatted program for 9-tracks (cpio) to replace
> Ken's assembler based tp.
>

Yes. PWB had their own collection of add-ons. I believe, but can't find the
reference, that there were frequent imports of Research Unix into PWB as I
saw references to UNIX/TS and CB-UNIX never getting too far away from
Research Unix, so that's kinda speculative...  I imagine that SCCS was a
boon for keeping it all straight, but I've never actually used SCCS.


> SCCS was important and the RJE support was important because that was the
> system being used and it made a huge impression on AT&T staff.   A terminal
> to a UNIX box was way cheaper and to the IBM and people were so much more
> productive.
>
> Also remember, that tp(1) was written in assembler had been originally
> targeted to DECtape in a very early version of Research UNIX.  The DECtape
> nature is why the directory was on the front of the tape.  Ken moved it
> 9-track but used the same tape format.   I don't remember who wrote stp
> (super-tp - in C), [?? Harvard ?? it's on the Harvard tape and is how I got
> it].   But better peripheral support was really important in Mashey's
> setting.  In that world, the production computer system was being put in
> the raised floor computer rooms next to a mainframe and they had
> 'operators' so John and team started to think more about what was needed to
> admin the system.   IMHO: this was the first heavy use of shell scripts,
> while I saw them in MH, it was Mashey's guys that cause me personally to
> have an ah-ha moment about them.
>
> Interestingly enough, and I have talked to Bourne and Mashey about it,
> John's use of the V6 was definitely one of the groups that were asking for
> a new shell, which Bourne set out to solve; but that is not yet available.
>
> At some point (and here is where we need Steve Johnson, aps, and I wish
> the late Ted Kowalski) to fill in details I can not.  USG/Summit was
> chartered to "support UNIX for the Bell System."   As I understand it, the
> genesis for their system was a kernel from MH that was moving towards V7s
> but not there yet, the 'Typesetter C' and a bunch of other utilities that
> Summit had collected/developed, but which I do not know.  I think fsdb was
> around by that time. The new Bourne Shell and adb were being developed
> although how complete I'm not sure.
>
> But accept for the new shell and updated compiler, I remember the system
> 'felt' like V6 (Thompson shell) and thinking how much 'better' different v7
> (Bourne Shell was) when we finally got it. This earlier system is the one
> Ted brought to CMU in the fall 1977 (I think that is the right date) to
> update the V6 system were then running.  Anyway, Ted always referred to
> this as a UNIX/TS kernel.
>
> Another thing we did not have SCCS or the RJE stuff.  What I'm not sure
> of is if there was a formally release of what ted had.  So it may have
> been that TS had them and sent the release to Mashey, although I don't
> think there were such releases originally in TS.  FWIW: I believe that in
> our (CMU) case,Ted would just grab things as they appeared that he
> thought we needed at CMU and he pushed things back (like CMU's fsck as he
> found things we had that he thought we would like).  Interestingly
> enough, RJE and SCCS was needed for the IBM support and while Ted (and his
> undergrad roommate, Bill Joy) had worked on the MTS system on the IBM's at
> UMich, I always felt like Ted looked down on the mainframes (which was were
> I had also emerged but from CMU's TSS team).
>
> Also, Ted was a die-hard original cpio user and I liked the user
> interface to stp, which I remember was a difference/source of argument.
>  Tar did not yet exist. TS had some of the PWB tools like volcpy; but we
> were using DOS-11's similar but different backup scheme (I've forgotten
> the name of the format; but the tapes were boot-able, which volcpy tapes
> were not).
>
> FWIW:  cu(1) did not yet exist.  I wrote a program (that I tended to
> prefer in some ways for many years) called connect(1cmu) that did the same
> thing.  We used it to download images to the Microprocessors like the
> KIM-1.   It was originally written with the v6 portable C library, which is
> also what the original fsck used (it's what we had on v6).   Ted introduced
> me to what would become stdio and one of my first tasks was using it with
> connect(1cmu).  The other thing I remember about that program is it was the
> first time I wrote something that used two separate processes on a UNIX
> system that cooperated with each other and found it so much easier than on
> the PDP-10.
>
> Also, Dennis' stand-alone system for V7 was not yet available BTW.   If I
> think of anything else about that system I can remember, I'll send an update
>
> PWB 2.0 was released just after V7, also "based on it".
>>
> I think the confusion is that TS and V7 were done sort of at the same time
> and while the folks working on them talked to each other, it has never been
> clear to me who was behind TS. For instance, I would learn that Bourne was
> the 'project leader' for Seventh, in that he was the person that collected
> everything for it.  I never heard of someone having the same role for TS,
> which is why I sometimes think it was a name inside of Summit, but never
> actually saw the light of day as a formal release.   I really am not sure
> and would love to learn more details (I wish Ted were still alive to fill
> us in).
>

Several timelines have, without references, Unix/TS or some variant of that
going back to the V4 time frame. It's at best murky. There's some
references in https://wiki.tuhs.org/doku.php?id=misc:snippets:mert1 including
the post by Dan DeJegar which I had trouble parsing the ins and outs of.


> As for V7 itself, Ken wrote tar(1) in response to cpio (preferring an
> ASCII based header, but 'threading' it like cpio did, but keeping the user
> interface that tp/stp had).  As I understand it, Dennis built up did the
> standalone toolkit stuff.  Ken changed groups and messed with the file system
> in the kernel.  Lots of new peripheral support, which is why he also
> added lseek() as disks overflowed a 16-bit integer for the seek position.
> Plus there were a number of other small changes between v6 and v7.  Some of
> this stuff from PWB and Summit went back to MH (fsck as an example), but
> not everything (like cpio/volcpy/SCCS).  I kind of think of the kernel and
> Typesetter C going from MH to Summit and the PWB teams.
>
> @Steve Johnson, I need your help here.... at some point PCC was created in
> MH (along with lint).  Didn't that start on V6 but was not complete until
> V7? And when did you move to Summit to lead the compiler effort there?  My
> impressions that was yet to happen, but I'm fuzzy on dates.
>
> Remember, there are a number of teams at BTL hacking on UNIX by then.
> Dale's team in Columbus, the crew in Indiana Hill,  folks at Western
> Electric (the Teletype folks ported the Ritchie C to the Z80 at some point
> for instance), *etc.*
>

Yea, the Columbus crew added a lot to the different versions, and merged
from them, according to the above link and a few other sources.


> Again, I don't remember the politics but like any big company, you can
> imagine it was not all that clean and crisp.   PWB 2.0 & 3.0 definitely
> picked up features from other UNIX systems.  As I remember, Dale's shared
> memory hacks would beget System V Shared Mem, Semaphores and IPC (they are
> different, but they started in Columbus).
>

This jives with other information that says the basis of system V share
memory, semaphores and ipc were derived from CB-Unix...


> The other thing I'm not clear on is when the PWB team was folded into USG (Unix
> Support Group) in Summit.  *I believe* that was after PWB 2.0 was
> released.  But at some point, Mashey's team and the USG got interwoven.
> I really don't know/remember many of those details as I watched them from
> the outside and only knew the results.  The key point is the PWB 2.0 would
> eventually be released as the internal, but official UNIX for the Bell
> System.   It was supposed to bring together the needed from the different
> labs; but it was not >>officially<< released *outside of the Bell System*
> (it was an internal product, remember at this point, AT&T is not allowed to
> have computer products, etc...)
>

Yes. There's some confusion as PWB and UNIX/TS become a USG thing that
turns into System III and then the influx of CB-UNIX that's added before
System V. How all that relates to USG, I'm quite unclear on still...


> So PWB 2.0 is basically internal, and a melding of V7, TS, PWB 1.0 and
> starting to take things from different labs with in BTL -- different from
> all of them but mostly a superset.
>
>
>
>
>> Later Unix TS 3.0 would become System III.
>>
> No --I do not think this is a true statement... not sure where you got
> that, more in a minute
>

>From the above recollection of Dan DeJAger...


> We know there was no System I or System II.
>>
> Correct.
>
> But was there a Unix TS 1.0 and 2.0?
>>
> This is where it gets sticky.  I don't think so.   TS was the original
> work by USG.   What I do not know is if it ever was 'packaged' as PWB had
> been. *I do not believe it was*.   I think a little like the way Research
> 'bled' out a little a time, pieces of TS made their way to MIT, CMU, *etc*.
> but never as a formal release.
>

I've seen lots of references to UNIX/TS, but no versions, so this makes
some sense... And it appears they go back further than V6...


> And were they the same thing as PWB 1.0 and 2.0, or somehow just closely
>> related?
>>
> See above... I'll explain how PWB 3.0 became System III in a minute.
>
>
>> And I've seen both Unix/TS and Unix TS. Is there a preferred spelling?
>>
> Don't know.  I remember Ted always called it UNIX/TS all caps.
>
> The thing you left out is how PWB 3.0 became System III.
>
> Two important issues.  First with V7, AT&T (Al Arms) wrote the first
> binary system redistribution license.  The commercial folks were happy to
> have a redistribution license, but the terms were not what they really
> needed.  Much of the issue was that AT&T was not the computer hardware or
> software business and really did not understand the issues that the vendors
> had.  Professor Dennis Allison of Stanford, was consulting for almost all
> of us in the computer industry at the time (for those that don't know
> Dennis, around the same time he founded what is now called the Asilomar
> Microprocessor Workshop (check out:
> https://www.computerhistory.org/atchm/the-asilomar-microcomputer-workshop-and-the-billion-dollar-toilet-seat/
> ).
>
> Dennis arranged for a big meeting at Ricki's Hyatt in Palo Alto and
> invited Al Arms and team, plus a representatives from his clients. I was
> the techie with a lawyer from Tektronix in the room (as I have said in
> other emails this it is only time I have been in a meeting with Bill
> Gates).  The folks I remember who were there: was Bill Munson and team from
> DEC; Fred Clegg and Team from HP; Bob MetCalfe from 3Com; Gates and the
> MSFT crew; folks from SCO and DG.   There were some others, about 10 firms
> in total; although I think if remember correctly, IBM was not among them
> [This is the meeting where Gates famously exclaimed: "*You guys don't get
> it.  The only thing that matters in the software industry is volume*."].
>
> BTW: The bits we were discussing was the upcoming release from USG, to be
> called PWB 3.0 and they were for the PDP-11 only (which was fine, that was
> what we all had been licensing already.  We could still use things from
> other places, because that is what those other places were all licensed to
> have -- all was good in UNIX-land).
>
> Thus began a series of negotiations for a new license agreement that would
> allow the HW vendors to better ship UNIX as a binary product:  FWIW: Gates
> wanted to pay $25/copy.   The DEC, HP and DG folks laughed.  $1K/copy was
> fine by them, since their HW was typically $50-150K/system.
>
> Either shortly after or maybe during the negotiations time, Judge Green
> ruled and AT&T got broken up.   One of the things that occured is that AT&T
> was now allowed to sell SW and more importantly their new 3B20 as a product
> (against IBM and DEC).  From a SW standpoint, AT&T Marketing did not like
> the 'Programmers' moniker, feeling that it would limit who they could sell
> too.  So they rebranded the new software product 'System III.'
>
> Note the printing of the manuals had already begun, which is why the cover
> of the manuals say System III, but the title pages say PWB 3.0.
>
> As other have said a few years later, another PWB release came out for the
> Bell System, *a.k.a.* PWB 4.0; but this was not licensed outside.
>
> At some point later, negotiations had restarted on yet another license
> with the System III licensees and AT&T.   By the time that completed, yet
> another release had been finished by USG.  The biggest change was the
> addition support for HW besides the PDP-11. In particular, the official USG
> support for the VAX and the 3B20.  What I forget, but I think in that
> license you had to declare a system type and most licensees picked the VAX.
>
> By the time of release and finalization of the license, AT&T Marketing
> which had already started the '*Consider it Standard*' campaign, called
> the new release "System V."
>
> AT&T Marketing would stay with System V moniker from then on and we know
> have SVR2, SVR3, SVR4, SVR5 in later years.
>

Yea, the detailed part of my history ends with the progeny of V7 (and I
only have room for some, I've found maybe 3 dozen different systems that
started out with V7 and then merge in System III or System V code for later
versions or some variation on this theme).


>
>> Thanks for all your help with this topic and sorting things out. It's
>> been quite helpful for my talk in a few weeks.
>>
>> Warner
>>
>> P.S. Would it be inappropriate to solicit feedback on an early version of
>> my talk from this group?
>>
> I would suggest sending a pointer to this group to the slides and ask for
> people to send you comments privately.
>

Works for me. Let me update based on this and Steve's email.


>
>
>> I'm sure they would be rather keener on catching errors in my
>> understanding of Unix history than just about any other forum...
>>
> Indeed - happy to help.
>

I am so very grateful for the help.


> Clem
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190910/585ed33a/attachment.html>

From clemc at ccc.com  Thu Sep 12 01:36:32 2019
From: clemc at ccc.com (Clem Cole)
Date: Wed, 11 Sep 2019 11:36:32 -0400
Subject: [TUHS] PWB vs Unix/TS
In-Reply-To: <CANCZdfpsXnbaQJo54qw689-unmVb35114PrOuNXHrcyp2Cng5g@mail.gmail.com>
References: <CANCZdfpEu6OxvmhDGSa3Cw4TSpfcbBOFbJjU7nZU-C_JFGFdRA@mail.gmail.com>
 <CAC20D2Pz+gwyeuVYcHFbJaimHtrt+sKSvCFp=hMZNoAWr4G09Q@mail.gmail.com>
 <CANCZdfpsXnbaQJo54qw689-unmVb35114PrOuNXHrcyp2Cng5g@mail.gmail.com>
Message-ID: <CAC20D2MuABFQw_R2HyUFsg8Dpum+LNn6ixneO2C7Te8ECtZ3PA@mail.gmail.com>

below...

On Tue, Sep 10, 2019 at 11:53 PM Warner Losh <imp at bsdimp.com> wrote:

>
> "The Programmer's Workbench was started in 1973,[2]
> <https://en.wikipedia.org/wiki/PWB/UNIX#cite_note-Mashey-2> by Evan Ivie
> and Rudd Canaday to support a computer center for a 1000-employee Bell Labs
> division" is what wikipedia says, though that reference is in a acm queue
> article by Mashey...
>
That syncs and if Mash wrote the dates, I believe them  I thought it was a
year or two later by the time they were done.  But it is what I said.  PWB
was done to support the mainframe shops.



> but I've never actually used SCCS.
>
That's a shame - I still use it for simple things.  Lots less overhead than
things like git.   Somebody rewrote it in C++ and you can google it.
Larry's been trying to get me to switch to bitkeeper and I probably should,
but I admit SCCS has been good enough for a long time and the commands are
screwed in the roms in my fingers.




>
> Several timelines have, without references, Unix/TS or some variant of
> that going back to the V4 time frame. It's at best murky. There's some
> references in https://wiki.tuhs.org/doku.php?id=misc:snippets:mert1 including
> the post by Dan DeJegar which I had trouble parsing the ins and outs of.
>
As I said, aps or Ted are more likely to be the sources.  They were part of
the original USG team.   Steve just said he did not go over there until
System V time (which was what I was afraid).

And thanks for refreshing the bits in my brain... Dan DeJagar not Dale....
  I'll look at this and see if I can parse it for you in any way.



> Yea, the Columbus crew added a lot to the different versions, and merged
> from them, according to the above link and a few other sources.
>
Yeah, Phil Karn and Mary Ann both talked about that -- Mary Ann is on this
list she may be able to add some of the missing details.

I was never 100% sure where Columbus fit into the puzzle, but that team did
a lot of cool stuff.  Real-Time was their thing. The Indiana Hill crew (Tom
Bishop) did the 3B4000 and all of the SSI work linked to the support the
ESS development.



> Yes. There's some confusion as PWB and UNIX/TS become a USG thing that
> turns into System III and then the influx of CB-UNIX that's added before
> System V. How all that relates to USG, I'm quite unclear on still...
>
As I said, aps or Ted lived it from the USG side. I'll try to dig up
Armando and see what he can tell you,



>
> From the above recollection of Dan DeJAger...
>
Interesting...   as I said, let me look at what he says and see what I can
add.


>  I've seen lots of references to UNIX/TS, but no versions, so this makes
> some sense... And it appears they go back further than V6...
>
It's possible, the first I saw any of the results was on top of V6, when
Ted brought some of it to CMU.


>  Yea, the detailed part of my history ends with the progeny of V7 (and I
> only have room for some, I've found maybe 3 dozen different systems that
> started out with V7 and then merge in System III or System V code for later
> versions or some variation on this theme).
>
That's because that was what the external (commercial) licenses allowed.
Each license subsumed the previous one. So if you had started a product
based on V7 (like DEC, HP, and Microsoft) you could ship with the System
III license (I remember that was >>huge<< issue with the vendors, which
AT&T was not super happy to accept - again this is the start of the
'consider it standard' stuff and they wanted everyone to use the bits from
Summit as the basis of their products, which was a problem because each
vendor had its own value add.

Later when OSF was created, this is part of the genesis of the 'Stable
License Terms' in OSF's founding principles.

So if you were a new company (say Masscomp or Stellar) from a legal
standpoint you started with the latest release (System III for the former,
SVR2 the later).  BTW, Sun is an interesting case, which I get too in a
minute.

DEC/HP/MSFT had started their engineering development for
Ultrix/HP-UX/Xenix on the original V7 license, so by the time of the System
III negotiation complete that had already been shipping some amount of
systems using V7 and their original licenses.  What the System III license
did was change the terms in some ways to help them.  But since the
engineering was solidly underweight for Ultrix, DEC kept their V7/BSD
kernel, MSFT switched Xenix to System III based (and then sold the whole
mess to SCO).  HP kept the V7/BSD kernel, but added all the System III
differences so it looked like System III the running program and used the
System III command system for a user.

At Masscomp, since we need to be on a 68K, we started with a V7/BSD kernel
from MIT's RTS labs, called NU (which TI and Apple both used also BTW).
 The command system was originally basically System III based but added BSD
commands as needed.  I joined to start the VM work and we folded the RTU
(real-time) stuff we had worked on with NU into 4.1 then 4.1C to be the
kernel, added MP support and we shipped (and it is what Larry originally
used).   The company quickly got sucked in the AT&T vs BSD fight, since the
AT&T and UCB command system were similar but different and about 1/3 of our
customers were University (BSD) types and the other 1/2 US
Gov/Commercial (att) and rest did not care.

Like HP, at first we tried add switches and create a super set of commands
(RTU 1.x).   This was a losing battle for a small company so, we gave up,
and our solution was "universes".  I created something I called
'conditionally dependant symbolic links' (CDSL - which I would resurrect in
Tru64 for the Cluster work) and we added the 'att' and 'ucb' commands to
set a variable in the kernel.  We then had two sets of commands  (/usr/att
and /usr/ucb).  Of course, this caused a new set of problems of trying to
do bug fixes in the two command streams [BTW: Pyramid would try the
Universe trick also as did a couple of other folks; but I don't know how
they implemented it - as I say, I did it with CDSL].

A couple of years later at Stellar we took a different tact.   We started
with the licensed kernel (SVR2) and hacked in what it was missing (SMP
support, sockets, a new/parallel FS) and added any BSD commands that were
not there, but left it as an otherwise System V system.

As I say, Sun was interesting.   They started as a firm after Masscomp, but
shipped their first systems (Stanford Sun Terminal boards running UNIX)
using Asa Romberger's V7 license (Unisoft).  When they got their own UNIX
license, it would have been a System III license like Masscomp the other
folks at that point.   From a technical stand point, they of course had
BSD; but I think they also had some of the MIT/NU stuff (like Jack Test's C
compiler and Tom Teixeria's 68k assembler).  So SunOS was based on BSD
while they shipped off an AT&T System III license (which was an anathema to
AT&T marketing, although it was allowed in that license).    Larry can tell
us how much pressure they felt with the V7/BSD command systems in the
market; but certainly since they originally sold to the Vax replacement
market - it did not seem like it mattered (until later).

When the SVR3 License came out, that was the 'best' from the licensee's
standpoint.  AT&T had finally backed off some of the more onerous terms,
but if you were not grandfathered into with an original V7 license, you had
to officially use their code -- although how strict and how/if they tried
to enforce I don't know.   (HP-UX was and still is a 'BSD' kernel from a
structural standpoint, but the user would never know.  I know IBM switch to
the SVr3 license (in fact bought it out) and I believe both HP and DEC
switched to using it to ship also (DEC was grandfathered to V7, so it was
terms switch for them.   I think at some point HP also bought out it
licenses, although I do not believe DEC ever did, Sun was another story
altogether).

OSF would eventually use the IBM SVR3 license as its base [which makes me
believe IBM must have had a V7 redistribution license too.  Somebody like
Charlie Saurer might know].  Anyway, IBM, DEC and HP all shipped OSF
'licensed' systems although only DEC would switch to an OSF/1 based kernel.

The quick story on Sun is that as Larry has pointed out there was a deal at
the CEO level that brought SunOS and SVR4 together to create what would
eventually would become Solaris 2.0 (I'll let Larry can fill in those
details, as it was not truly SVR4 nor SunOS when it was done).  AT&T, ney
Novell, ney SCO would eventually create SVR5 which was different yet.
Chorus was working on what was to be SVR6 to compete with the OSF RI's
Mach4 based system, but I don't think that ever shipped.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190911/a39b854d/attachment.html>

From paul.winalski at gmail.com  Thu Sep 12 02:05:37 2019
From: paul.winalski at gmail.com (Paul Winalski)
Date: Wed, 11 Sep 2019 12:05:37 -0400
Subject: [TUHS] PWB vs Unix/TS
In-Reply-To: <CAC20D2Pz+gwyeuVYcHFbJaimHtrt+sKSvCFp=hMZNoAWr4G09Q@mail.gmail.com>
References: <CANCZdfpEu6OxvmhDGSa3Cw4TSpfcbBOFbJjU7nZU-C_JFGFdRA@mail.gmail.com>
 <CAC20D2Pz+gwyeuVYcHFbJaimHtrt+sKSvCFp=hMZNoAWr4G09Q@mail.gmail.com>
Message-ID: <CABH=_VSOgxNfn5gEGN26vyj7U9cmnwqtRzNso4wbdJ0qpdz_SA@mail.gmail.com>

>On 9/10/19, Clem Cole <clemc at ccc.com> wrote:
>
> SCCS was important and the RJE support was important because that was the
> system being used and it made a huge impression on AT&T staff.   A terminal
> to a UNIX box was way cheaper and to the IBM and people were so much more
> productive.

IBM RJE stations were card-based, with a card reader, card punch, and
line printer.  Communication with the mainframe was via half-duplex
bisync.  Certainly editing programs on a UNIX terminal would be WAY
more productive than punch cards!

-Paul W.

From sauer at technologists.com  Thu Sep 12 02:55:00 2019
From: sauer at technologists.com (Charles H Sauer)
Date: Wed, 11 Sep 2019 11:55:00 -0500
Subject: [TUHS] IBM Unix source licenses [was Re:  PWB vs Unix/TS
In-Reply-To: <CAC20D2MuABFQw_R2HyUFsg8Dpum+LNn6ixneO2C7Te8ECtZ3PA@mail.gmail.com>
References: <CANCZdfpEu6OxvmhDGSa3Cw4TSpfcbBOFbJjU7nZU-C_JFGFdRA@mail.gmail.com>
 <CAC20D2Pz+gwyeuVYcHFbJaimHtrt+sKSvCFp=hMZNoAWr4G09Q@mail.gmail.com>
 <CANCZdfpsXnbaQJo54qw689-unmVb35114PrOuNXHrcyp2Cng5g@mail.gmail.com>
 <CAC20D2MuABFQw_R2HyUFsg8Dpum+LNn6ixneO2C7Te8ECtZ3PA@mail.gmail.com>
Message-ID: <c704d50c-dc9b-c703-a18c-86c411ae5d3f@technologists.com>

On 9/11/2019 10:36 AM, Clem Cole wrote:
...
> OSF would eventually use the IBM SVR3 license as its base [which 
> makes me believe IBM must have had a V7 redistribution license too.  
> Somebody like Charlie Saurer might know].  Anyway, IBM, DEC and HP all 
> shipped OSF 'licensed' systems although only DEC would switch to an 
> OSF/1 based kernel.

"Sauer"

idk. As far as I know, IBM Austin did not get source licenses until 
System V. Before Clay Cipione became the AIX development manager in the 
AFWS -> RT transition, Austin did not have source licenses, as far as I 
know. Clay insisted that we have source.

It is plausible that Don Rozenberg had V7 license at Yorktown and/or 
ACIS had V7 license for BSD stuff.

I'm blind copying Clay and another AIX alumnus that might know for sure.

Charlie
-- 
voice: +1.512.784.7526       e-mail: sauer at technologists.com
fax: +1.512.346.5240         Web: https://technologists.com/sauer/
Facebook/Google/Skype/Twitter: CharlesHSauer

From ron at ronnatalie.com  Thu Sep 12 03:14:42 2019
From: ron at ronnatalie.com (ron at ronnatalie.com)
Date: Wed, 11 Sep 2019 13:14:42 -0400
Subject: [TUHS] PWB vs Unix/TS
In-Reply-To: <CABH=_VSOgxNfn5gEGN26vyj7U9cmnwqtRzNso4wbdJ0qpdz_SA@mail.gmail.com>
References: <CANCZdfpEu6OxvmhDGSa3Cw4TSpfcbBOFbJjU7nZU-C_JFGFdRA@mail.gmail.com>
 <CAC20D2Pz+gwyeuVYcHFbJaimHtrt+sKSvCFp=hMZNoAWr4G09Q@mail.gmail.com>
 <CABH=_VSOgxNfn5gEGN26vyj7U9cmnwqtRzNso4wbdJ0qpdz_SA@mail.gmail.com>
Message-ID: <009801d568c4$6ad6abf0$408403d0$@ronnatalie.com>

And SCCS was way easier than anything you could do with cards.
My first experience with PWB was maintaining the source code and QA for a project that was targeted at RSX-11M.

Amusingly, it as my job twice at different facilities (BRL and Rutgers) to get rid of all the card processing equipment.

I finally offered to move the Cyber RJE station and its accompanying keypunch machine into the office of the last person using it.   He finally decided he'd make the jump to timesharing.
Amusingly, nobody figured out how to make CyberRJE work from a PDP-11.   The labs had purchased a half dozen PDP-11/34s with a optical card reader, line printer, and graphical display (Vector General) and a DQ-11 and 56K (them was fast in those days) short haul modem.

Of course, in Mike Muuss's typical style, he said we could use them.    They all got recycled into graphics workstations.   Mike wrote a driver for the Vector General and the first ersatz "BRL CAD" package.    We still used the card reader to read in old "COMGEO" graphic model decks which CAD could edit.

UNIX for the 11/34 (a hybrid V6 kernel), we installed overlays.    When TCP/IP came around which needed another segment register for mbufs, we just couldn't make it work anymore on a non-split-I/D machine.    The VGs got moved over to the 11/70's and I recycled the 34's into internet routers.    We actually used the DQ's and modems for internal communciations for a while until we subsequently bought IMPs and later Proteon rings.



From rich.salz at gmail.com  Thu Sep 12 03:49:27 2019
From: rich.salz at gmail.com (Richard Salz)
Date: Wed, 11 Sep 2019 13:49:27 -0400
Subject: [TUHS] PWB vs Unix/TS
In-Reply-To: <CAC20D2MuABFQw_R2HyUFsg8Dpum+LNn6ixneO2C7Te8ECtZ3PA@mail.gmail.com>
References: <CANCZdfpEu6OxvmhDGSa3Cw4TSpfcbBOFbJjU7nZU-C_JFGFdRA@mail.gmail.com>
 <CAC20D2Pz+gwyeuVYcHFbJaimHtrt+sKSvCFp=hMZNoAWr4G09Q@mail.gmail.com>
 <CANCZdfpsXnbaQJo54qw689-unmVb35114PrOuNXHrcyp2Cng5g@mail.gmail.com>
 <CAC20D2MuABFQw_R2HyUFsg8Dpum+LNn6ixneO2C7Te8ECtZ3PA@mail.gmail.com>
Message-ID: <CAFH29tqpO_BScoaQ528aw-J4dp2JgDwOJvkccK24qTrFLmkHYw@mail.gmail.com>

> course, this caused a new set of problems of trying to do bug fixes in
the two command streams [BTW: Pyramid would try the Universe trick also as
did a couple of other folks; but I don't know how they implemented it - as
I say, I did it with CDSL].

Yes, /bin was a CDSL to /.attbin or /.ucbbin depending on a flag in the
proc structure.  The "universe" command queried/set the bit.  The Pyramid
kernel was a BSD kernel with the missing ATT syscalls added.  The boot
mechanism, at least at first, was BSD. I did things like "rm -rf" /.attbin,
/usr/.attinclude, etc., and the system was fine. :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190911/aec1eaf9/attachment.html>

From ron at ronnatalie.com  Thu Sep 12 03:52:28 2019
From: ron at ronnatalie.com (ron at ronnatalie.com)
Date: Wed, 11 Sep 2019 13:52:28 -0400
Subject: [TUHS] PWB vs Unix/TS
In-Reply-To: <CAFH29tqpO_BScoaQ528aw-J4dp2JgDwOJvkccK24qTrFLmkHYw@mail.gmail.com>
References: <CANCZdfpEu6OxvmhDGSa3Cw4TSpfcbBOFbJjU7nZU-C_JFGFdRA@mail.gmail.com>
 <CAC20D2Pz+gwyeuVYcHFbJaimHtrt+sKSvCFp=hMZNoAWr4G09Q@mail.gmail.com>
 <CANCZdfpsXnbaQJo54qw689-unmVb35114PrOuNXHrcyp2Cng5g@mail.gmail.com>
 <CAC20D2MuABFQw_R2HyUFsg8Dpum+LNn6ixneO2C7Te8ECtZ3PA@mail.gmail.com>
 <CAFH29tqpO_BScoaQ528aw-J4dp2JgDwOJvkccK24qTrFLmkHYw@mail.gmail.com>
Message-ID: <009e01d568c9$afd2ca40$0f785ec0$@ronnatalie.com>

The Pyramid OS used “conditional symlinks” if I recalled to implement switching the bin directories.

The UCLA LOCUS/IBM Transparent Computing Facility switched versions of executables by using a “magic” directory that was conditional on the cpu type.

 

From: TUHS <tuhs-bounces at minnie.tuhs.org> On Behalf Of Richard Salz
Sent: Wednesday, September 11, 2019 1:49 PM
To: Clem Cole <clemc at ccc.com>
Cc: The Eunuchs Hysterical Society <tuhs at tuhs.org>
Subject: Re: [TUHS] PWB vs Unix/TS

 

> course, this caused a new set of problems of trying to do bug fixes in the two command streams [BTW: Pyramid would try the Universe trick also as did a couple of other folks; but I don't know how they implemented it - as I say, I did it with CDSL].

 

Yes, /bin was a CDSL to /.attbin or /.ucbbin depending on a flag in the proc structure.  The "universe" command queried/set the bit.  The Pyramid kernel was a BSD kernel with the missing ATT syscalls added.  The boot mechanism, at least at first, was BSD. I did things like "rm -rf" /.attbin, /usr/.attinclude, etc., and the system was fine. :)

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190911/7b998c1d/attachment-0001.html>

From lm at mcvoy.com  Thu Sep 12 04:11:01 2019
From: lm at mcvoy.com (Larry McVoy)
Date: Wed, 11 Sep 2019 11:11:01 -0700
Subject: [TUHS] PWB vs Unix/TS
In-Reply-To: <CAC20D2MuABFQw_R2HyUFsg8Dpum+LNn6ixneO2C7Te8ECtZ3PA@mail.gmail.com>
References: <CANCZdfpEu6OxvmhDGSa3Cw4TSpfcbBOFbJjU7nZU-C_JFGFdRA@mail.gmail.com>
 <CAC20D2Pz+gwyeuVYcHFbJaimHtrt+sKSvCFp=hMZNoAWr4G09Q@mail.gmail.com>
 <CANCZdfpsXnbaQJo54qw689-unmVb35114PrOuNXHrcyp2Cng5g@mail.gmail.com>
 <CAC20D2MuABFQw_R2HyUFsg8Dpum+LNn6ixneO2C7Te8ECtZ3PA@mail.gmail.com>
Message-ID: <20190911181101.GF3143@mcvoy.com>

On Wed, Sep 11, 2019 at 11:36:32AM -0400, Clem Cole wrote:
> > but I've never actually used SCCS.
> >
> That's a shame - I still use it for simple things.  Lots less overhead than
> things like git.   Somebody rewrote it in C++ and you can google it.
> Larry's been trying to get me to switch to bitkeeper and I probably should,
> but I admit SCCS has been good enough for a long time and the commands are
> screwed in the roms in my fingers.

SCCS is awesome, I'll post why in a different thread.  It is light years
better than RCS, Tichy lied.

> As I say, Sun was interesting.   They started as a firm after Masscomp, but
> shipped their first systems (Stanford Sun Terminal boards running UNIX)
> using Asa Romberger's V7 license (Unisoft).  When they got their own UNIX
> license, it would have been a System III license like Masscomp the other
> folks at that point.   From a technical stand point, they of course had
> BSD; but I think they also had some of the MIT/NU stuff (like Jack Test's C
> compiler and Tom Teixeria's 68k assembler).  So SunOS was based on BSD
> while they shipped off an AT&T System III license (which was an anathema to
> AT&T marketing, although it was allowed in that license).    Larry can tell
> us how much pressure they felt with the V7/BSD command systems in the
> market; but certainly since they originally sold to the Vax replacement
> market - it did not seem like it mattered (until later).

So I'm not sure that I can add that much.  I never used SunOS 1.x, the
first version I used was SunOS 2.x and that was brief.  SunOS 3.x was
much better, it was the one where people started calling SunOS "a bug
fixed BSD" I believe.

I always talk up the glory days of Sun but one thing they got wrong, in
my opinion, was this incessant desire to not ship X11 as the windowing
system.  In those days you ran sunview, which was a decent enough window
system but it wasn't X11.  Like pretty much everyone else, I got the
X10 and later X11 sources and did a "make world".  Because I wasn't just
running on Suns, there were the IBM RTs, there were microvaxes, there were
Masscomps, etc.  You wanted to be able to have the same startup files on
all of the machines and that meant X windows.

Building X was a lesson in reality.  The graphics drivers were never as
good as the ones that Sun shipped, the code didn't always build so you
got a lesson in #ifdef DOESNT_WORK_SUNOS_35, you learned that you should
just try stuff and see if the code that didn't compile was even used,
mostly it wasn't.

I didn't get to Sun until 4.0 had come out, that was the release that
had the new VM system, vnodes, vfs layer, etc.  Vnodes might have been
in the 3.x tree, not sure.

> The quick story on Sun is that as Larry has pointed out there was a deal at
> the CEO level that brought SunOS and SVR4 together to create what would
> eventually would become Solaris 2.0 (I'll let Larry can fill in those
> details, as it was not truly SVR4 nor SunOS when it was done).  

Yeah, that happened about 5 years after I got there.  The terms of the
deal were very hush hush, my boss was the VP in charge of all server
hardware and he paid me for 6 months to go argue with Scooter, Raduchel,
basically everyone in the top floor of PAL-1, all the execs.  So even
he didn't know.

The problem was that Sun was in financial hot water and AT&T wanted SVR4
to be the industry standard.  At the time, there was no question that
SunOS 4.x was the industry standard.  Pretty much anything you found
on comp.sources or elsewhere, just compiled on SunOS.  AT&T didn't
like that, thought they were going to get rich from SVR4, so they cut
a deal with Sun.  They bought $200M of Sun stock at 35% above market
and in return Sun agreed to dump SunOS and go with SVR4.  Which was,
in my opinion, the beginning of the end for Sun.  It's close to 30
years later and I'm still butthurt over that.  It would have been
much better if Sun had licensed their source base to AT&T and then
AT&T could have leveraged the industry standard.  Shoulda, coulda,
woulda.

From rich.salz at gmail.com  Thu Sep 12 04:18:08 2019
From: rich.salz at gmail.com (Richard Salz)
Date: Wed, 11 Sep 2019 14:18:08 -0400
Subject: [TUHS] PWB vs Unix/TS
In-Reply-To: <20190911181101.GF3143@mcvoy.com>
References: <CANCZdfpEu6OxvmhDGSa3Cw4TSpfcbBOFbJjU7nZU-C_JFGFdRA@mail.gmail.com>
 <CAC20D2Pz+gwyeuVYcHFbJaimHtrt+sKSvCFp=hMZNoAWr4G09Q@mail.gmail.com>
 <CANCZdfpsXnbaQJo54qw689-unmVb35114PrOuNXHrcyp2Cng5g@mail.gmail.com>
 <CAC20D2MuABFQw_R2HyUFsg8Dpum+LNn6ixneO2C7Te8ECtZ3PA@mail.gmail.com>
 <20190911181101.GF3143@mcvoy.com>
Message-ID: <CAFH29troduX1uctdjZMmfaKwn5aEJeMAp4aoYhvYhVLQdWiqGQ@mail.gmail.com>

>
>   It would have been
> much better if Sun had licensed their source base to AT&T and then
> AT&T could have leveraged the industry standard.


Interesting to speculate if that would have sped up the creation of OSF or
delayed/prevented it.  I think the former.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190911/e10ea1f8/attachment.html>

From lm at mcvoy.com  Thu Sep 12 04:54:18 2019
From: lm at mcvoy.com (Larry McVoy)
Date: Wed, 11 Sep 2019 11:54:18 -0700
Subject: [TUHS] PWB vs Unix/TS
In-Reply-To: <CAFH29troduX1uctdjZMmfaKwn5aEJeMAp4aoYhvYhVLQdWiqGQ@mail.gmail.com>
References: <CANCZdfpEu6OxvmhDGSa3Cw4TSpfcbBOFbJjU7nZU-C_JFGFdRA@mail.gmail.com>
 <CAC20D2Pz+gwyeuVYcHFbJaimHtrt+sKSvCFp=hMZNoAWr4G09Q@mail.gmail.com>
 <CANCZdfpsXnbaQJo54qw689-unmVb35114PrOuNXHrcyp2Cng5g@mail.gmail.com>
 <CAC20D2MuABFQw_R2HyUFsg8Dpum+LNn6ixneO2C7Te8ECtZ3PA@mail.gmail.com>
 <20190911181101.GF3143@mcvoy.com>
 <CAFH29troduX1uctdjZMmfaKwn5aEJeMAp4aoYhvYhVLQdWiqGQ@mail.gmail.com>
Message-ID: <20190911185418.GA2046@mcvoy.com>

On Wed, Sep 11, 2019 at 02:18:08PM -0400, Richard Salz wrote:
> >
> >   It would have been
> > much better if Sun had licensed their source base to AT&T and then
> > AT&T could have leveraged the industry standard.
> 
> 
> Interesting to speculate if that would have sped up the creation of OSF or
> delayed/prevented it.  I think the former.

You're probably right but it wouldn't have mattered. SunOS was very popular
and had a good VM system with a working mmap.  Once it became official
AT&T source everyone would have moved to it over time.

Sort of obvious in retrospect.  Nobody, that I know of, considered it at
the time.  I proposed open sourcing it.

From scj at yaccman.com  Thu Sep 12 07:05:34 2019
From: scj at yaccman.com (Steve Johnson)
Date: Wed, 11 Sep 2019 14:05:34 -0700
Subject: [TUHS] PWB vs Unix/TS
In-Reply-To: <20190911185418.GA2046@mcvoy.com>
Message-ID: <a970b6f0c9f2083f35ebff8a21fd1b1019cbc3ac@webmail.yaccman.com>


I tried very hard to get the front end of pcc released to open source
(we didn't call it then) because after K&R was printed, everyone and
their cat started writing C compilers based on the appendix.  I had
strong management support for this move, but the lawyers were still in
their "lets study this for 10 years and then it will be clear what we
should have done" mode.  So we ended up with far pointers and ten
years of standards committee agony.  It's so obvious to me now, as
then, that such specs should be executable (although not necessarily
product-quality in speed or things like error messages).  But it's
also obvious that the desire to compete by adding glitter and icing
runs strong nontheless.

Steve

----- Original Message -----
From: "Larry McVoy" <lm at mcvoy.com>
To:"Richard Salz" <rich.salz at gmail.com>
Cc:"The Eunuchs Hysterical Society" <tuhs at tuhs.org>
Sent:Wed, 11 Sep 2019 11:54:18 -0700
Subject:Re: [TUHS] PWB vs Unix/TS

 On Wed, Sep 11, 2019 at 02:18:08PM -0400, Richard Salz wrote:
 > >
 > > It would have been
 > > much better if Sun had licensed their source base to AT&T and
then
 > > AT&T could have leveraged the industry standard.
 > 
 > 
 > Interesting to speculate if that would have sped up the creation of
OSF or
 > delayed/prevented it. I think the former.

 You're probably right but it wouldn't have mattered. SunOS was very
popular
 and had a good VM system with a working mmap. Once it became official
 AT&T source everyone would have moved to it over time.

 Sort of obvious in retrospect. Nobody, that I know of, considered it
at
 the time. I proposed open sourcing it.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190911/b17910df/attachment.html>

From scj at yaccman.com  Thu Sep 12 07:34:46 2019
From: scj at yaccman.com (Steve Johnson)
Date: Wed, 11 Sep 2019 14:34:46 -0700
Subject: [TUHS] PWB vs Unix/TS
In-Reply-To: <20190911185418.GA2046@mcvoy.com>
Message-ID: <04b40f1648473af7350ff61e45aacecba6eba49d@webmail.yaccman.com>


One of my co-workers, Serge Vakulenko,  just gave me a small gift --
a 1 x 2 inch computer chip that runs a version of BSD Unix, complete
with compilers and editors.  It's powered by the USB port and you
connect with it at 115200 baud (10,000 x faster than a model 33
TTY!).  It has a surprisingly big file system and 128K of RAM, half
of which is given to the system.  There are lots of BSD games,
including a game of Go Fish that I wrote for my son over 50 years
ago.   It was interesting to me to look at that early C code.  I
was surprised at the nonzero number of gotos (5).

The source is on
https://github.com/RetroBSD/retrobsd/blob/master/src/games/fish.c if
you are interested...

For extra credit, see if you can find the bug that Serge found in this
50-year-old code, and figure out how the program seems to work OK
anyway  (Hint: type mismatch).  There clearly was a good reason to
invent Lint and declarations and header files...

Steve

PS: if you'd like a look at the chip, google PIC32-RETROBSD.  The CPU
is a MIPS microcontroller.

----- Original Message -----
From: "Larry McVoy" <lm at mcvoy.com>
To:"Richard Salz" <rich.salz at gmail.com>
Cc:"The Eunuchs Hysterical Society" <tuhs at tuhs.org>
Sent:Wed, 11 Sep 2019 11:54:18 -0700
Subject:Re: [TUHS] PWB vs Unix/TS

 On Wed, Sep 11, 2019 at 02:18:08PM -0400, Richard Salz wrote:
 > >
 > > It would have been
 > > much better if Sun had licensed their source base to AT&T and
then
 > > AT&T could have leveraged the industry standard.
 > 
 > 
 > Interesting to speculate if that would have sped up the creation of
OSF or
 > delayed/prevented it. I think the former.

 You're probably right but it wouldn't have mattered. SunOS was very
popular
 and had a good VM system with a working mmap. Once it became official
 AT&T source everyone would have moved to it over time.

 Sort of obvious in retrospect. Nobody, that I know of, considered it
at
 the time. I proposed open sourcing it.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190911/4062cd5a/attachment.html>

From clemc at ccc.com  Thu Sep 12 07:44:15 2019
From: clemc at ccc.com (Clem Cole)
Date: Wed, 11 Sep 2019 17:44:15 -0400
Subject: [TUHS] PWB vs Unix/TS
In-Reply-To: <009e01d568c9$afd2ca40$0f785ec0$@ronnatalie.com>
References: <CANCZdfpEu6OxvmhDGSa3Cw4TSpfcbBOFbJjU7nZU-C_JFGFdRA@mail.gmail.com>
 <CAC20D2Pz+gwyeuVYcHFbJaimHtrt+sKSvCFp=hMZNoAWr4G09Q@mail.gmail.com>
 <CANCZdfpsXnbaQJo54qw689-unmVb35114PrOuNXHrcyp2Cng5g@mail.gmail.com>
 <CAC20D2MuABFQw_R2HyUFsg8Dpum+LNn6ixneO2C7Te8ECtZ3PA@mail.gmail.com>
 <CAFH29tqpO_BScoaQ528aw-J4dp2JgDwOJvkccK24qTrFLmkHYw@mail.gmail.com>
 <009e01d568c9$afd2ca40$0f785ec0$@ronnatalie.com>
Message-ID: <CAC20D2PVrve7gYVy-ZY1rcbM3RbV4qgjU15+VY4p4ZxWcvtbnQ@mail.gmail.com>

On Wed, Sep 11, 2019 at 1:52 PM <ron at ronnatalie.com> wrote:

> The Pyramid OS used “conditional symlinks” if I recalled to implement
> switching the bin directories.
>
> The UCLA LOCUS/IBM Transparent Computing Facility switched versions of
> executables by using a “magic” directory that was conditional on the cpu
> type.
>
Right, TCF did that (Bruce built them IIRC).

As I said, I resurrected CSDL's from Masscomp at Locus for TNC which was
more general and lost less intrusive (which is how they landed in Tru64
when we sold the TNC to DEC to become TruClusters and I would join them).
As for CDSL, I had generalized it for LCC from what I did at Masscomp years
before.

FWIW: I still think they are a cute idea and solve a number of problems,
but alas they are no longer ;-)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190911/b29c5247/attachment.html>

From clemc at ccc.com  Thu Sep 12 07:50:59 2019
From: clemc at ccc.com (Clem Cole)
Date: Wed, 11 Sep 2019 17:50:59 -0400
Subject: [TUHS] PWB vs Unix/TS
In-Reply-To: <20190911181101.GF3143@mcvoy.com>
References: <CANCZdfpEu6OxvmhDGSa3Cw4TSpfcbBOFbJjU7nZU-C_JFGFdRA@mail.gmail.com>
 <CAC20D2Pz+gwyeuVYcHFbJaimHtrt+sKSvCFp=hMZNoAWr4G09Q@mail.gmail.com>
 <CANCZdfpsXnbaQJo54qw689-unmVb35114PrOuNXHrcyp2Cng5g@mail.gmail.com>
 <CAC20D2MuABFQw_R2HyUFsg8Dpum+LNn6ixneO2C7Te8ECtZ3PA@mail.gmail.com>
 <20190911181101.GF3143@mcvoy.com>
Message-ID: <CAC20D2MA3Ssd6QpuTv6uqZoWAQzE3H7wB5b7pLh=qTdnvRMK7Q@mail.gmail.com>

On Wed, Sep 11, 2019 at 2:11 PM Larry McVoy <lm at mcvoy.com> wrote:

> The problem was that Sun was in financial hot water and AT&T wanted SVR4
> to be the industry standard. ...  It would have been
> much better if Sun had licensed their source base to AT&T and then
> AT&T could have leveraged the industry standard.

I think those two statements say everything.  Sun was not in a position to
negotiate and AT&T desperately wanted SVR4 to be the standard - I think it
was corporate pride. (which I also think was mixed up the BSDi/UCB case too
- if they had let it go it would have been a darned site smarter).

If AT&T could have swallowed and excepted somebody other than them having
the 'high order bit' it might have worked.  As you say, leveraged the
industry standard.  Instead is just added to the fighting.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190911/79221fed/attachment.html>

From clemc at ccc.com  Thu Sep 12 07:57:51 2019
From: clemc at ccc.com (Clem Cole)
Date: Wed, 11 Sep 2019 17:57:51 -0400
Subject: [TUHS] PWB vs Unix/TS
In-Reply-To: <20190911185418.GA2046@mcvoy.com>
References: <CANCZdfpEu6OxvmhDGSa3Cw4TSpfcbBOFbJjU7nZU-C_JFGFdRA@mail.gmail.com>
 <CAC20D2Pz+gwyeuVYcHFbJaimHtrt+sKSvCFp=hMZNoAWr4G09Q@mail.gmail.com>
 <CANCZdfpsXnbaQJo54qw689-unmVb35114PrOuNXHrcyp2Cng5g@mail.gmail.com>
 <CAC20D2MuABFQw_R2HyUFsg8Dpum+LNn6ixneO2C7Te8ECtZ3PA@mail.gmail.com>
 <20190911181101.GF3143@mcvoy.com>
 <CAFH29troduX1uctdjZMmfaKwn5aEJeMAp4aoYhvYhVLQdWiqGQ@mail.gmail.com>
 <20190911185418.GA2046@mcvoy.com>
Message-ID: <CAC20D2PV5Ma=pHWd5YdpAf57iw+DnbPsu5cz1XwoQzZ1mCCN6Q@mail.gmail.com>

On Wed, Sep 11, 2019 at 2:54 PM Larry McVoy <lm at mcvoy.com> wrote:

> You're probably right but it wouldn't have mattered. SunOS was very popular
> and had a good VM system with a working mmap.  Once it became official
> AT&T source everyone would have moved to it over time.
>
But Sun would have to accept the economics of Intel processor sooner.
Which is funny because RoadRunner was a pretty neat machine.  They had
Solaris/386 but was way too little too late.   Sparc was a blind spot I
fear.



>
> Sort of obvious in retrospect.  Nobody, that I know of, considered it at the
> time.

Maybe -- as I said, i386 would have been the key.



> I proposed open sourcing it.

I agree, that might have worked.  And then if they wanted to be in the HW
biz, let the FOSS world deal with Intel.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190911/a27193c5/attachment.html>

From clemc at ccc.com  Thu Sep 12 07:59:55 2019
From: clemc at ccc.com (Clem Cole)
Date: Wed, 11 Sep 2019 17:59:55 -0400
Subject: [TUHS] PWB vs Unix/TS
In-Reply-To: <CAFH29troduX1uctdjZMmfaKwn5aEJeMAp4aoYhvYhVLQdWiqGQ@mail.gmail.com>
References: <CANCZdfpEu6OxvmhDGSa3Cw4TSpfcbBOFbJjU7nZU-C_JFGFdRA@mail.gmail.com>
 <CAC20D2Pz+gwyeuVYcHFbJaimHtrt+sKSvCFp=hMZNoAWr4G09Q@mail.gmail.com>
 <CANCZdfpsXnbaQJo54qw689-unmVb35114PrOuNXHrcyp2Cng5g@mail.gmail.com>
 <CAC20D2MuABFQw_R2HyUFsg8Dpum+LNn6ixneO2C7Te8ECtZ3PA@mail.gmail.com>
 <20190911181101.GF3143@mcvoy.com>
 <CAFH29troduX1uctdjZMmfaKwn5aEJeMAp4aoYhvYhVLQdWiqGQ@mail.gmail.com>
Message-ID: <CAC20D2MHfrvsAa2TX8oTUuBUG1M1z80hPSSN0On8mmG4f9H9EA@mail.gmail.com>

On Wed, Sep 11, 2019 at 2:18 PM Richard Salz <rich.salz at gmail.com> wrote:

> Interesting to speculate if that would have sped up the creation of OSF or
> delayed/prevented it.  I think the former.
>
It would have been created either way. The codebase was not the issue.  The
license terms and how the industry was going to play out (*i.e.* the
economics) is what created OSF.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190911/25313c84/attachment.html>

From dave at horsfall.org  Thu Sep 12 08:49:35 2019
From: dave at horsfall.org (Dave Horsfall)
Date: Thu, 12 Sep 2019 08:49:35 +1000 (EST)
Subject: [TUHS] PWB vs Unix/TS
In-Reply-To: <20190911181101.GF3143@mcvoy.com>
References: <CANCZdfpEu6OxvmhDGSa3Cw4TSpfcbBOFbJjU7nZU-C_JFGFdRA@mail.gmail.com>
 <CAC20D2Pz+gwyeuVYcHFbJaimHtrt+sKSvCFp=hMZNoAWr4G09Q@mail.gmail.com>
 <CANCZdfpsXnbaQJo54qw689-unmVb35114PrOuNXHrcyp2Cng5g@mail.gmail.com>
 <CAC20D2MuABFQw_R2HyUFsg8Dpum+LNn6ixneO2C7Te8ECtZ3PA@mail.gmail.com>
 <20190911181101.GF3143@mcvoy.com>
Message-ID: <alpine.BSF.2.21.9999.1909120846160.18105@aneurin.horsfall.org>

On Wed, 11 Sep 2019, Larry McVoy wrote:

> SCCS is awesome, I'll post why in a different thread.  It is light years
> better than RCS, Tichy lied.

Agreed; I used it for years, then was forced to use RCS in my next job :-(

-- Dave

From krewat at kilonet.net  Thu Sep 12 08:50:42 2019
From: krewat at kilonet.net (Arthur Krewat)
Date: Wed, 11 Sep 2019 18:50:42 -0400
Subject: [TUHS] PWB vs Unix/TS
In-Reply-To: <CAC20D2PV5Ma=pHWd5YdpAf57iw+DnbPsu5cz1XwoQzZ1mCCN6Q@mail.gmail.com>
References: <CANCZdfpEu6OxvmhDGSa3Cw4TSpfcbBOFbJjU7nZU-C_JFGFdRA@mail.gmail.com>
 <CAC20D2Pz+gwyeuVYcHFbJaimHtrt+sKSvCFp=hMZNoAWr4G09Q@mail.gmail.com>
 <CANCZdfpsXnbaQJo54qw689-unmVb35114PrOuNXHrcyp2Cng5g@mail.gmail.com>
 <CAC20D2MuABFQw_R2HyUFsg8Dpum+LNn6ixneO2C7Te8ECtZ3PA@mail.gmail.com>
 <20190911181101.GF3143@mcvoy.com>
 <CAFH29troduX1uctdjZMmfaKwn5aEJeMAp4aoYhvYhVLQdWiqGQ@mail.gmail.com>
 <20190911185418.GA2046@mcvoy.com>
 <CAC20D2PV5Ma=pHWd5YdpAf57iw+DnbPsu5cz1XwoQzZ1mCCN6Q@mail.gmail.com>
Message-ID: <d9c42dd2-0f24-1577-0d15-91623ac47896@kilonet.net>

On 9/11/2019 5:57 PM, Clem Cole wrote:
>
>
> On Wed, Sep 11, 2019 at 2:54 PM Larry McVoy <lm at mcvoy.com 
> <mailto:lm at mcvoy.com>> wrote:
>
>     You're probably right but it wouldn't have mattered. SunOS was
>     very popular
>     and had a good VM system with a working mmap.  Once it became official
>     AT&T source everyone would have moved to it over time.
>
> But Sun would have to accept the economics of Intel processor sooner.  
> Which is funny because RoadRunner was a pretty neat machine.  They had 
> Solaris/386 but was way too little too late.   Sparc was a blind spot 
> I fear.
>

One of the reasons I went into Solaris whole-hog during the 
SunOS->Solaris thing was the availability of a version that ran on 
Intel. I ran an Intel SVR4.2 (Consensys) BBS in the early 90's, with 
USENET/NEWS, using a SunOS IPX as a back-end file server.

Of course, a few of my customers who did CAD were using Sun 
workstations, and everything moved to Solaris, so there was also that.

Once Solaris X86 came out, I jumped at the chance. I'm still 
administering PeopleSoft and Oracle on Solaris 11 X86. But sadly, time 
to move on.

Although, Oracle says Solaris support is continuing out until 2031, with 
extended support to 2034, with Solaris Cluster 4.x following suit. But 
at $1000/socket for support just for the OS, that pricing is a hard to 
take when it comes to CentOS/Redhat/Oracle Linux.

ak
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190911/7e7c9e08/attachment.html>

From lm at mcvoy.com  Thu Sep 12 13:43:46 2019
From: lm at mcvoy.com (Larry McVoy)
Date: Wed, 11 Sep 2019 20:43:46 -0700
Subject: [TUHS] SCCS
In-Reply-To: <alpine.BSF.2.21.9999.1909120846160.18105@aneurin.horsfall.org>
References: <CANCZdfpEu6OxvmhDGSa3Cw4TSpfcbBOFbJjU7nZU-C_JFGFdRA@mail.gmail.com>
 <CAC20D2Pz+gwyeuVYcHFbJaimHtrt+sKSvCFp=hMZNoAWr4G09Q@mail.gmail.com>
 <CANCZdfpsXnbaQJo54qw689-unmVb35114PrOuNXHrcyp2Cng5g@mail.gmail.com>
 <CAC20D2MuABFQw_R2HyUFsg8Dpum+LNn6ixneO2C7Te8ECtZ3PA@mail.gmail.com>
 <20190911181101.GF3143@mcvoy.com>
 <alpine.BSF.2.21.9999.1909120846160.18105@aneurin.horsfall.org>
Message-ID: <20190912034346.GJ2046@mcvoy.com>

On Thu, Sep 12, 2019 at 08:49:35AM +1000, Dave Horsfall wrote:
> On Wed, 11 Sep 2019, Larry McVoy wrote:
> 
> >SCCS is awesome, I'll post why in a different thread.  It is light years
> >better than RCS, Tichy lied.
> 
> Agreed; I used it for years, then was forced to use RCS in my next job :-(

Marc Rochkind is on the list, I believe I invited him, but he can spell
check what I'm about to say.

SCCS is awesome.  People have no idea how good it is as a version control
system because Walter Tichy got his PhD for writing RCS and claiming it 
was better (don't get me started on how wrong that was).

Let me start with how RCS works.  You all know about diff and patch,
someone does a diff, produces a patch, and Larry Wall wrote patch(1)
that takes the patch and file and applies it.  In a straight line 
history here is how RCS works.  The most recent version of the file
is stored in whole, the delta behind that is a reverse patch to get 
to that, same for the next delta behind that and so on.

Branches in RCS are forward patches.  Sort of.  You start with the
whole file that is the most recent version, reverse patch your way
back to the branch point, and then forward patch your way down to 
the most recent version on the branch.  

Yeah, branches in RCS suck, very expensive.  

So why is SCCS awesome?  It is an entirely different approach.
SCCS is a set based system, for any version, there is a set
of deltas that are in that version and you apply them to the 
file part of the data.  

Huh?  What does that mean?  OK, you've all seen SCCS revisions, 1.1,
1.2, 1.3, 1.3.1.1, etc.  Yeah, that's for humans (and truth be told those
revs are not that great).  For SCCS internally there are serial numbers.
All those are are a monotonically increasing number, doesn't matter
if you are on the trunk or on a branch, each time you add a delta the
internal number, or serial, is the last serial plus 1.

When you go to check out a version of the file, that's the set.
It's the set of serials that make up that file.  If you wanted
1.3 and there are no branches, the set is the serial of 1.3 (3)
and the parent of 1.3 which is 1.2 (2) and 1.1 (1).  So your set
is 1,2,3.

Here is the awesome part.  The way the data is stored in SCCS
is nothing like patches, it's what we call a weave.  All versions
of the file are woven together in the following way.  There are
3 operators:

insert: ^AI <serial>
delete: ^AD <serial>
end: ^AE <serial>

So if you checked in a file that looked like

I
love
TUHS

The weave would be

^AI 1
I
love
TUHS
^AE 1

Lets say that Clem changed that to

I
really
love
TUHS

The new weave would look like:

^AI 1
I
^AI 2
really
^AE 2
love
TUHS
^AE 1

and if I changed it to

I
*really*
love
TUHS

the weave looks like

^AI 1
I
^AD 3
^AI 2
really
^AE 2
^AE 3
^AI 3
*really*
^AE 3
love
TUHS
^AE 1

So a checkout is 2 things, build up the set of serials that need to be
active for this checkout, and walk the weave.  For each serial you see
you are either in this set and I need to do what it says, or this is
not in my set and I need to do the opposite of what it says.

So that is really really fast compared to RCS.  RCS reads the whole
file and has to do compute, SCCS reads the whole file and does a
very tiny fraction of that compute, so tiny that you can't measure
it compared to reading the file.  

But wait, it gets better, much better.  Lets talk about branches
and merges.  RCS is copy by value across a merge, SCCS is copy by
reference.  Marc thought about the set stuff enough to realize
wouldn't be cool if you could manipulate the set.  He added include
and exclude operators.

Imagine if you and I were having an argument about some video being
checked in.  You checked it in, I deleted it, you checked it in, I deleted
it.  Suppose that was a 1GB video.  In RCS, each time we argued that is
another GB, we did that 4 times, there 4GB of diffs in the history.

In SCCS, you could do that with includes and excludes, those 4 times
would be about 30 bytes because all they are doing is saying "In the
set", "Not in the set".

Cool I guess but what is the real life win?  Merges.  In a weave based
system like SCCS you can add 1GB on a branch and I can merge that onto
the trunk and all I did was say "include your serials".  I didn't copy
your work, I referenced it.  Tiny meta data to do so.

That has more implications than you might think.  Think annotations.
git blame, know that?  It shows who did what?  Yeah, well git is 
copy by value just like RCS.  It's not just about the space used,
it is also about who did what.  If bwk did one thing and dmr did 
another thing and little old lm merged dmr's stuff into the bwk 
trunk, in a copy by value system, all of dmr's work will look like
I wrote it in bwk's trunk.

SCCS avoids that.  If I merged dmr's work into bwk's tree, if it 
all automerged, annotations would show it all as dmr's work, yeah,
I did the merge but I didn't do anything so I don't show up in
annotations.  If there was a conflict and I had to resolve that
conflict, then that, and that alone, would show up as my work.

For Marc, I worked with Rick Smith, he found me after I had done a
reimplentation of SCCS.  He has forgotten more about weaves than I will
ever know.  But he was really impressed with my code (which you can
go see at bitkeeper.org, and it is not my code, it is my teams code,
Rick bugfixed all my mistakes) because I embraced the set thing and the
way I wrote the code you could have N of my data structures and pulled
out N versions of the file in one pass.  He had not seen that before,
to me it just seemed the most natural way to do it.

SCCS is awesome, Marc should be held up as a hero for that.  Most people
have no idea how much better it is as a format, to this day people still
do it wrong.  The hg people at facebook sort of got it, they did an
import of SCCS (it was BitKeeper which is SCCS on super steriods).
But it is rare that someone gets it.  I wanted Marc to know we got it.

--lm

From ggm at algebras.org  Thu Sep 12 14:20:08 2019
From: ggm at algebras.org (George Michaelson)
Date: Thu, 12 Sep 2019 11:20:08 +0700
Subject: [TUHS] SCCS
In-Reply-To: <20190912034346.GJ2046@mcvoy.com>
References: <CANCZdfpEu6OxvmhDGSa3Cw4TSpfcbBOFbJjU7nZU-C_JFGFdRA@mail.gmail.com>
 <CAC20D2Pz+gwyeuVYcHFbJaimHtrt+sKSvCFp=hMZNoAWr4G09Q@mail.gmail.com>
 <CANCZdfpsXnbaQJo54qw689-unmVb35114PrOuNXHrcyp2Cng5g@mail.gmail.com>
 <CAC20D2MuABFQw_R2HyUFsg8Dpum+LNn6ixneO2C7Te8ECtZ3PA@mail.gmail.com>
 <20190911181101.GF3143@mcvoy.com>
 <alpine.BSF.2.21.9999.1909120846160.18105@aneurin.horsfall.org>
 <20190912034346.GJ2046@mcvoy.com>
Message-ID: <CAKr6gn39D_XrOHXr22EUsEWhCUcFJw2n6C8iQ_ntXGkbO33irw@mail.gmail.com>

If you want to be trendy, call this an event stream, and say its
eventually consistent.

What Larry and the other RCS haters forget is that back in the day,
when we all had more hair, RCS was --->FAST<--- and SCCS was S.L.O.W.

because running forward edits on a base state of 1000 edits is slow.
Since the majority action is increment +1 on the head state the RCS
model, whilst broken in many ways
was FAST

-G

On Thu, Sep 12, 2019 at 10:44 AM Larry McVoy <lm at mcvoy.com> wrote:
>
> On Thu, Sep 12, 2019 at 08:49:35AM +1000, Dave Horsfall wrote:
> > On Wed, 11 Sep 2019, Larry McVoy wrote:
> >
> > >SCCS is awesome, I'll post why in a different thread.  It is light years
> > >better than RCS, Tichy lied.
> >
> > Agreed; I used it for years, then was forced to use RCS in my next job :-(
>
> Marc Rochkind is on the list, I believe I invited him, but he can spell
> check what I'm about to say.
>
> SCCS is awesome.  People have no idea how good it is as a version control
> system because Walter Tichy got his PhD for writing RCS and claiming it
> was better (don't get me started on how wrong that was).
>
> Let me start with how RCS works.  You all know about diff and patch,
> someone does a diff, produces a patch, and Larry Wall wrote patch(1)
> that takes the patch and file and applies it.  In a straight line
> history here is how RCS works.  The most recent version of the file
> is stored in whole, the delta behind that is a reverse patch to get
> to that, same for the next delta behind that and so on.
>
> Branches in RCS are forward patches.  Sort of.  You start with the
> whole file that is the most recent version, reverse patch your way
> back to the branch point, and then forward patch your way down to
> the most recent version on the branch.
>
> Yeah, branches in RCS suck, very expensive.
>
> So why is SCCS awesome?  It is an entirely different approach.
> SCCS is a set based system, for any version, there is a set
> of deltas that are in that version and you apply them to the
> file part of the data.
>
> Huh?  What does that mean?  OK, you've all seen SCCS revisions, 1.1,
> 1.2, 1.3, 1.3.1.1, etc.  Yeah, that's for humans (and truth be told those
> revs are not that great).  For SCCS internally there are serial numbers.
> All those are are a monotonically increasing number, doesn't matter
> if you are on the trunk or on a branch, each time you add a delta the
> internal number, or serial, is the last serial plus 1.
>
> When you go to check out a version of the file, that's the set.
> It's the set of serials that make up that file.  If you wanted
> 1.3 and there are no branches, the set is the serial of 1.3 (3)
> and the parent of 1.3 which is 1.2 (2) and 1.1 (1).  So your set
> is 1,2,3.
>
> Here is the awesome part.  The way the data is stored in SCCS
> is nothing like patches, it's what we call a weave.  All versions
> of the file are woven together in the following way.  There are
> 3 operators:
>
> insert: ^AI <serial>
> delete: ^AD <serial>
> end: ^AE <serial>
>
> So if you checked in a file that looked like
>
> I
> love
> TUHS
>
> The weave would be
>
> ^AI 1
> I
> love
> TUHS
> ^AE 1
>
> Lets say that Clem changed that to
>
> I
> really
> love
> TUHS
>
> The new weave would look like:
>
> ^AI 1
> I
> ^AI 2
> really
> ^AE 2
> love
> TUHS
> ^AE 1
>
> and if I changed it to
>
> I
> *really*
> love
> TUHS
>
> the weave looks like
>
> ^AI 1
> I
> ^AD 3
> ^AI 2
> really
> ^AE 2
> ^AE 3
> ^AI 3
> *really*
> ^AE 3
> love
> TUHS
> ^AE 1
>
> So a checkout is 2 things, build up the set of serials that need to be
> active for this checkout, and walk the weave.  For each serial you see
> you are either in this set and I need to do what it says, or this is
> not in my set and I need to do the opposite of what it says.
>
> So that is really really fast compared to RCS.  RCS reads the whole
> file and has to do compute, SCCS reads the whole file and does a
> very tiny fraction of that compute, so tiny that you can't measure
> it compared to reading the file.
>
> But wait, it gets better, much better.  Lets talk about branches
> and merges.  RCS is copy by value across a merge, SCCS is copy by
> reference.  Marc thought about the set stuff enough to realize
> wouldn't be cool if you could manipulate the set.  He added include
> and exclude operators.
>
> Imagine if you and I were having an argument about some video being
> checked in.  You checked it in, I deleted it, you checked it in, I deleted
> it.  Suppose that was a 1GB video.  In RCS, each time we argued that is
> another GB, we did that 4 times, there 4GB of diffs in the history.
>
> In SCCS, you could do that with includes and excludes, those 4 times
> would be about 30 bytes because all they are doing is saying "In the
> set", "Not in the set".
>
> Cool I guess but what is the real life win?  Merges.  In a weave based
> system like SCCS you can add 1GB on a branch and I can merge that onto
> the trunk and all I did was say "include your serials".  I didn't copy
> your work, I referenced it.  Tiny meta data to do so.
>
> That has more implications than you might think.  Think annotations.
> git blame, know that?  It shows who did what?  Yeah, well git is
> copy by value just like RCS.  It's not just about the space used,
> it is also about who did what.  If bwk did one thing and dmr did
> another thing and little old lm merged dmr's stuff into the bwk
> trunk, in a copy by value system, all of dmr's work will look like
> I wrote it in bwk's trunk.
>
> SCCS avoids that.  If I merged dmr's work into bwk's tree, if it
> all automerged, annotations would show it all as dmr's work, yeah,
> I did the merge but I didn't do anything so I don't show up in
> annotations.  If there was a conflict and I had to resolve that
> conflict, then that, and that alone, would show up as my work.
>
> For Marc, I worked with Rick Smith, he found me after I had done a
> reimplentation of SCCS.  He has forgotten more about weaves than I will
> ever know.  But he was really impressed with my code (which you can
> go see at bitkeeper.org, and it is not my code, it is my teams code,
> Rick bugfixed all my mistakes) because I embraced the set thing and the
> way I wrote the code you could have N of my data structures and pulled
> out N versions of the file in one pass.  He had not seen that before,
> to me it just seemed the most natural way to do it.
>
> SCCS is awesome, Marc should be held up as a hero for that.  Most people
> have no idea how much better it is as a format, to this day people still
> do it wrong.  The hg people at facebook sort of got it, they did an
> import of SCCS (it was BitKeeper which is SCCS on super steriods).
> But it is rare that someone gets it.  I wanted Marc to know we got it.
>
> --lm

From nobozo at gmail.com  Thu Sep 12 14:28:25 2019
From: nobozo at gmail.com (Jon Forrest)
Date: Wed, 11 Sep 2019 21:28:25 -0700
Subject: [TUHS] SCCS
In-Reply-To: <20190912034346.GJ2046@mcvoy.com>
References: <CANCZdfpEu6OxvmhDGSa3Cw4TSpfcbBOFbJjU7nZU-C_JFGFdRA@mail.gmail.com>
 <CAC20D2Pz+gwyeuVYcHFbJaimHtrt+sKSvCFp=hMZNoAWr4G09Q@mail.gmail.com>
 <CANCZdfpsXnbaQJo54qw689-unmVb35114PrOuNXHrcyp2Cng5g@mail.gmail.com>
 <CAC20D2MuABFQw_R2HyUFsg8Dpum+LNn6ixneO2C7Te8ECtZ3PA@mail.gmail.com>
 <20190911181101.GF3143@mcvoy.com>
 <alpine.BSF.2.21.9999.1909120846160.18105@aneurin.horsfall.org>
 <20190912034346.GJ2046@mcvoy.com>
Message-ID: <a0231faa-8ad9-fa51-4b24-9854beb21210@gmail.com>



I used both RCS and SCCS in the early days (e.g. 1985 - 1991). RCS was
what we used at Britton-Lee in the group that Eric Allman was part of.
SCCS is what we used at Sybase as it was gaining popularity. This was
so long ago that I don't remember all the details but I found that
RCS was much easier to use, especially in an environment that didn't
do much merging. Instead we used labels (or tags, I forget what they
were called) to mark which files were part of which release. Doing
this was much harder in SCCS, which contributed to the mess that
was Sybase software engineering.

Of course, all this could be explained by Eric's deep knowledge
of RCS, and the lack of somebody with Eric's knowledge at Sybase.
But, to me, an early adopter of source code control who wasn't
overly interested in speed, RCS was much easier to use.

Jon

From lm at mcvoy.com  Thu Sep 12 14:31:45 2019
From: lm at mcvoy.com (Larry McVoy)
Date: Wed, 11 Sep 2019 21:31:45 -0700
Subject: [TUHS] [SPAM] Re:  SCCS
In-Reply-To: <CAKr6gn39D_XrOHXr22EUsEWhCUcFJw2n6C8iQ_ntXGkbO33irw@mail.gmail.com>
References: <CANCZdfpEu6OxvmhDGSa3Cw4TSpfcbBOFbJjU7nZU-C_JFGFdRA@mail.gmail.com>
 <CAC20D2Pz+gwyeuVYcHFbJaimHtrt+sKSvCFp=hMZNoAWr4G09Q@mail.gmail.com>
 <CANCZdfpsXnbaQJo54qw689-unmVb35114PrOuNXHrcyp2Cng5g@mail.gmail.com>
 <CAC20D2MuABFQw_R2HyUFsg8Dpum+LNn6ixneO2C7Te8ECtZ3PA@mail.gmail.com>
 <20190911181101.GF3143@mcvoy.com>
 <alpine.BSF.2.21.9999.1909120846160.18105@aneurin.horsfall.org>
 <20190912034346.GJ2046@mcvoy.com>
 <CAKr6gn39D_XrOHXr22EUsEWhCUcFJw2n6C8iQ_ntXGkbO33irw@mail.gmail.com>
Message-ID: <20190912043145.GA12480@mcvoy.com>

If you have actual data that shows RCS to be faster I would like to
see that.  RCS read the whole file.  It could have been faster, it could
have put the offset into the file where the most recent version begain.
But it didn't.  It read the entire file.

RCS was not faster and I am happy to go get the code and prove that.

"because running forward edits on a base state of 1000 edits is slow."

means you don't get how SCCS works.  

On Thu, Sep 12, 2019 at 11:20:08AM +0700, George Michaelson wrote:
> If you want to be trendy, call this an event stream, and say its
> eventually consistent.
> 
> What Larry and the other RCS haters forget is that back in the day,
> when we all had more hair, RCS was --->FAST<--- and SCCS was S.L.O.W.
> 
> because running forward edits on a base state of 1000 edits is slow.
> Since the majority action is increment +1 on the head state the RCS
> model, whilst broken in many ways
> was FAST
> 
> -G
> 
> On Thu, Sep 12, 2019 at 10:44 AM Larry McVoy <lm at mcvoy.com> wrote:
> >
> > On Thu, Sep 12, 2019 at 08:49:35AM +1000, Dave Horsfall wrote:
> > > On Wed, 11 Sep 2019, Larry McVoy wrote:
> > >
> > > >SCCS is awesome, I'll post why in a different thread.  It is light years
> > > >better than RCS, Tichy lied.
> > >
> > > Agreed; I used it for years, then was forced to use RCS in my next job :-(
> >
> > Marc Rochkind is on the list, I believe I invited him, but he can spell
> > check what I'm about to say.
> >
> > SCCS is awesome.  People have no idea how good it is as a version control
> > system because Walter Tichy got his PhD for writing RCS and claiming it
> > was better (don't get me started on how wrong that was).
> >
> > Let me start with how RCS works.  You all know about diff and patch,
> > someone does a diff, produces a patch, and Larry Wall wrote patch(1)
> > that takes the patch and file and applies it.  In a straight line
> > history here is how RCS works.  The most recent version of the file
> > is stored in whole, the delta behind that is a reverse patch to get
> > to that, same for the next delta behind that and so on.
> >
> > Branches in RCS are forward patches.  Sort of.  You start with the
> > whole file that is the most recent version, reverse patch your way
> > back to the branch point, and then forward patch your way down to
> > the most recent version on the branch.
> >
> > Yeah, branches in RCS suck, very expensive.
> >
> > So why is SCCS awesome?  It is an entirely different approach.
> > SCCS is a set based system, for any version, there is a set
> > of deltas that are in that version and you apply them to the
> > file part of the data.
> >
> > Huh?  What does that mean?  OK, you've all seen SCCS revisions, 1.1,
> > 1.2, 1.3, 1.3.1.1, etc.  Yeah, that's for humans (and truth be told those
> > revs are not that great).  For SCCS internally there are serial numbers.
> > All those are are a monotonically increasing number, doesn't matter
> > if you are on the trunk or on a branch, each time you add a delta the
> > internal number, or serial, is the last serial plus 1.
> >
> > When you go to check out a version of the file, that's the set.
> > It's the set of serials that make up that file.  If you wanted
> > 1.3 and there are no branches, the set is the serial of 1.3 (3)
> > and the parent of 1.3 which is 1.2 (2) and 1.1 (1).  So your set
> > is 1,2,3.
> >
> > Here is the awesome part.  The way the data is stored in SCCS
> > is nothing like patches, it's what we call a weave.  All versions
> > of the file are woven together in the following way.  There are
> > 3 operators:
> >
> > insert: ^AI <serial>
> > delete: ^AD <serial>
> > end: ^AE <serial>
> >
> > So if you checked in a file that looked like
> >
> > I
> > love
> > TUHS
> >
> > The weave would be
> >
> > ^AI 1
> > I
> > love
> > TUHS
> > ^AE 1
> >
> > Lets say that Clem changed that to
> >
> > I
> > really
> > love
> > TUHS
> >
> > The new weave would look like:
> >
> > ^AI 1
> > I
> > ^AI 2
> > really
> > ^AE 2
> > love
> > TUHS
> > ^AE 1
> >
> > and if I changed it to
> >
> > I
> > *really*
> > love
> > TUHS
> >
> > the weave looks like
> >
> > ^AI 1
> > I
> > ^AD 3
> > ^AI 2
> > really
> > ^AE 2
> > ^AE 3
> > ^AI 3
> > *really*
> > ^AE 3
> > love
> > TUHS
> > ^AE 1
> >
> > So a checkout is 2 things, build up the set of serials that need to be
> > active for this checkout, and walk the weave.  For each serial you see
> > you are either in this set and I need to do what it says, or this is
> > not in my set and I need to do the opposite of what it says.
> >
> > So that is really really fast compared to RCS.  RCS reads the whole
> > file and has to do compute, SCCS reads the whole file and does a
> > very tiny fraction of that compute, so tiny that you can't measure
> > it compared to reading the file.
> >
> > But wait, it gets better, much better.  Lets talk about branches
> > and merges.  RCS is copy by value across a merge, SCCS is copy by
> > reference.  Marc thought about the set stuff enough to realize
> > wouldn't be cool if you could manipulate the set.  He added include
> > and exclude operators.
> >
> > Imagine if you and I were having an argument about some video being
> > checked in.  You checked it in, I deleted it, you checked it in, I deleted
> > it.  Suppose that was a 1GB video.  In RCS, each time we argued that is
> > another GB, we did that 4 times, there 4GB of diffs in the history.
> >
> > In SCCS, you could do that with includes and excludes, those 4 times
> > would be about 30 bytes because all they are doing is saying "In the
> > set", "Not in the set".
> >
> > Cool I guess but what is the real life win?  Merges.  In a weave based
> > system like SCCS you can add 1GB on a branch and I can merge that onto
> > the trunk and all I did was say "include your serials".  I didn't copy
> > your work, I referenced it.  Tiny meta data to do so.
> >
> > That has more implications than you might think.  Think annotations.
> > git blame, know that?  It shows who did what?  Yeah, well git is
> > copy by value just like RCS.  It's not just about the space used,
> > it is also about who did what.  If bwk did one thing and dmr did
> > another thing and little old lm merged dmr's stuff into the bwk
> > trunk, in a copy by value system, all of dmr's work will look like
> > I wrote it in bwk's trunk.
> >
> > SCCS avoids that.  If I merged dmr's work into bwk's tree, if it
> > all automerged, annotations would show it all as dmr's work, yeah,
> > I did the merge but I didn't do anything so I don't show up in
> > annotations.  If there was a conflict and I had to resolve that
> > conflict, then that, and that alone, would show up as my work.
> >
> > For Marc, I worked with Rick Smith, he found me after I had done a
> > reimplentation of SCCS.  He has forgotten more about weaves than I will
> > ever know.  But he was really impressed with my code (which you can
> > go see at bitkeeper.org, and it is not my code, it is my teams code,
> > Rick bugfixed all my mistakes) because I embraced the set thing and the
> > way I wrote the code you could have N of my data structures and pulled
> > out N versions of the file in one pass.  He had not seen that before,
> > to me it just seemed the most natural way to do it.
> >
> > SCCS is awesome, Marc should be held up as a hero for that.  Most people
> > have no idea how much better it is as a format, to this day people still
> > do it wrong.  The hg people at facebook sort of got it, they did an
> > import of SCCS (it was BitKeeper which is SCCS on super steriods).
> > But it is rare that someone gets it.  I wanted Marc to know we got it.
> >
> > --lm

-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 

From lm at mcvoy.com  Thu Sep 12 14:33:08 2019
From: lm at mcvoy.com (Larry McVoy)
Date: Wed, 11 Sep 2019 21:33:08 -0700
Subject: [TUHS] SCCS
In-Reply-To: <a0231faa-8ad9-fa51-4b24-9854beb21210@gmail.com>
References: <CANCZdfpEu6OxvmhDGSa3Cw4TSpfcbBOFbJjU7nZU-C_JFGFdRA@mail.gmail.com>
 <CAC20D2Pz+gwyeuVYcHFbJaimHtrt+sKSvCFp=hMZNoAWr4G09Q@mail.gmail.com>
 <CANCZdfpsXnbaQJo54qw689-unmVb35114PrOuNXHrcyp2Cng5g@mail.gmail.com>
 <CAC20D2MuABFQw_R2HyUFsg8Dpum+LNn6ixneO2C7Te8ECtZ3PA@mail.gmail.com>
 <20190911181101.GF3143@mcvoy.com>
 <alpine.BSF.2.21.9999.1909120846160.18105@aneurin.horsfall.org>
 <20190912034346.GJ2046@mcvoy.com>
 <a0231faa-8ad9-fa51-4b24-9854beb21210@gmail.com>
Message-ID: <20190912043308.GL2046@mcvoy.com>

Yeah, this was one of things that BitKeeper addressed.  It was easier
to use and every commit was a tag.

On Wed, Sep 11, 2019 at 09:28:25PM -0700, Jon Forrest wrote:
> 
> 
> I used both RCS and SCCS in the early days (e.g. 1985 - 1991). RCS was
> what we used at Britton-Lee in the group that Eric Allman was part of.
> SCCS is what we used at Sybase as it was gaining popularity. This was
> so long ago that I don't remember all the details but I found that
> RCS was much easier to use, especially in an environment that didn't
> do much merging. Instead we used labels (or tags, I forget what they
> were called) to mark which files were part of which release. Doing
> this was much harder in SCCS, which contributed to the mess that
> was Sybase software engineering.
> 
> Of course, all this could be explained by Eric's deep knowledge
> of RCS, and the lack of somebody with Eric's knowledge at Sybase.
> But, to me, an early adopter of source code control who wasn't
> overly interested in speed, RCS was much easier to use.
> 
> Jon

-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 

From jon at fourwinds.com  Thu Sep 12 14:25:04 2019
From: jon at fourwinds.com (Jon Steinhart)
Date: Wed, 11 Sep 2019 21:25:04 -0700
Subject: [TUHS] SCCS
Message-ID: <201909120425.x8C4P4e2009186@darkstar.fourwinds.com>

George Michaelson writes:
> What Larry and the other RCS haters forget is that back in the day,
> when we all had more hair, RCS was --->FAST<--- and SCCS was S.L.O.W.
>
> because running forward edits on a base state of 1000 edits is slow.
> Since the majority action is increment +1 on the head state the RCS
> model, whilst broken in many ways
> was FAST
>
> -G

And also that RCS had a much friendlier interface.

From wlc at jctaylor.com  Thu Sep 12 16:12:10 2019
From: wlc at jctaylor.com (William Corcoran)
Date: Thu, 12 Sep 2019 06:12:10 +0000
Subject: [TUHS] SCCS
In-Reply-To: <20190912043308.GL2046@mcvoy.com>
References: <CANCZdfpEu6OxvmhDGSa3Cw4TSpfcbBOFbJjU7nZU-C_JFGFdRA@mail.gmail.com>
 <CAC20D2Pz+gwyeuVYcHFbJaimHtrt+sKSvCFp=hMZNoAWr4G09Q@mail.gmail.com>
 <CANCZdfpsXnbaQJo54qw689-unmVb35114PrOuNXHrcyp2Cng5g@mail.gmail.com>
 <CAC20D2MuABFQw_R2HyUFsg8Dpum+LNn6ixneO2C7Te8ECtZ3PA@mail.gmail.com>
 <20190911181101.GF3143@mcvoy.com>
 <alpine.BSF.2.21.9999.1909120846160.18105@aneurin.horsfall.org>
 <20190912034346.GJ2046@mcvoy.com>
 <a0231faa-8ad9-fa51-4b24-9854beb21210@gmail.com>,
 <20190912043308.GL2046@mcvoy.com>
Message-ID: <03956472-B6A1-4E83-B2F1-0FE855C75C15@jctaylor.com>

Okay, while on the subject of SCCS and UNIX:

Is there a UNIX (post SCCS) like System III or System V that still has all of the original SCCS entries intact?  

Would only production ready code be entered as an SCCS delta? 

Or, would SCCS be used as a checkpoint tool to store unofficial versions (even broken versions) of the UNIX codebase as development progressed on the system as a whole?

I would love to see all of the prs for the kernel and commands.  

Truly,

Bill Corcoran

> On Sep 12, 2019, at 12:33 AM, Larry McVoy <lm at mcvoy.com> wrote:
> 
> Yeah, this was one of things that BitKeeper addressed.  It was easier
> to use and every commit was a tag.
> 
>> On Wed, Sep 11, 2019 at 09:28:25PM -0700, Jon Forrest wrote:
>> 
>> 
>> I used both RCS and SCCS in the early days (e.g. 1985 - 1991). RCS was
>> what we used at Britton-Lee in the group that Eric Allman was part of.
>> SCCS is what we used at Sybase as it was gaining popularity. This was
>> so long ago that I don't remember all the details but I found that
>> RCS was much easier to use, especially in an environment that didn't
>> do much merging. Instead we used labels (or tags, I forget what they
>> were called) to mark which files were part of which release. Doing
>> this was much harder in SCCS, which contributed to the mess that
>> was Sybase software engineering.
>> 
>> Of course, all this could be explained by Eric's deep knowledge
>> of RCS, and the lack of somebody with Eric's knowledge at Sybase.
>> But, to me, an early adopter of source code control who wasn't
>> overly interested in speed, RCS was much easier to use.
>> 
>> Jon
> 
> -- 
> ---
> Larry McVoy                     lm at mcvoy.com             http://www.mcvoy.com/lm 

From dot at dotat.at  Thu Sep 12 23:44:45 2019
From: dot at dotat.at (Tony Finch)
Date: Thu, 12 Sep 2019 14:44:45 +0100
Subject: [TUHS] [SPAM] Re:  SCCS
In-Reply-To: <20190912043145.GA12480@mcvoy.com>
References: <CANCZdfpEu6OxvmhDGSa3Cw4TSpfcbBOFbJjU7nZU-C_JFGFdRA@mail.gmail.com>
 <CAC20D2Pz+gwyeuVYcHFbJaimHtrt+sKSvCFp=hMZNoAWr4G09Q@mail.gmail.com>
 <CANCZdfpsXnbaQJo54qw689-unmVb35114PrOuNXHrcyp2Cng5g@mail.gmail.com>
 <CAC20D2MuABFQw_R2HyUFsg8Dpum+LNn6ixneO2C7Te8ECtZ3PA@mail.gmail.com>
 <20190911181101.GF3143@mcvoy.com>
 <alpine.BSF.2.21.9999.1909120846160.18105@aneurin.horsfall.org>
 <20190912034346.GJ2046@mcvoy.com>
 <CAKr6gn39D_XrOHXr22EUsEWhCUcFJw2n6C8iQ_ntXGkbO33irw@mail.gmail.com>
 <20190912043145.GA12480@mcvoy.com>
Message-ID: <alpine.DEB.2.20.1909121417040.5352@grey.csi.cam.ac.uk>

Larry McVoy <lm at mcvoy.com> wrote:

> If you have actual data that shows RCS to be faster I would like to
> see that.  RCS read the whole file.  It could have been faster, it could
> have put the offset into the file where the most recent version begain.
> But it didn't.  It read the entire file.

In RCS the most recent version of the file is near the start of the ,v
file after a list of revisions, so it doesn't have to read the deltas for
the common case of checking out the current version of a file. I think
there must be a similar optimization to copy the deltas without processing
them when committing a new revision. But yes, as soon as you get away from
working on the latest revision of the main branch, RCS becomes
quadratically slow.

A few years ago I converted a decades-old SCCS working tree to git.
Because there are very good tools for converting from CVS to git, I
decided to convert SCCS to RCS (which is mostly a trivial file-at-a-time
format conversion, in the absence of branches and tags) to CVS (which is
just moving the RCS files to the right place) to git.

The most annoying part of this was the accidentally quadratic process of
dealing with all the old revisions in RCS files. I could mostly avoid
slowness if I arranged never to check out old revisions, aiming to treat
RCS as append-only until the final cvs-fast-export stage. This kept things
acceptably fast (closer to linear in the size of the file rather than
quadratic) even for that one very large frequently updated file.

Detailed write-up at https://fanf.dreamwidth.org/105694.html
(I subsequently re-used a lot of the machinery for converting another
much smaller SCCS repository. It was a lot easier the second time!)

[ PS. https://accidentallyquadratic.tumblr.com is great ]

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
Lough Foyle to Carlingford Lough: Southwesterly at first in southeast,
otherwise westerly or northwesterly 4 or 5, occasionally 6 at first. Moderate
or rough in north, otherwise slight or moderate, becoming smooth or slight in
east. Rain at first. Moderate or poor, becoming good.

From clemc at ccc.com  Fri Sep 13 00:35:32 2019
From: clemc at ccc.com (Clem Cole)
Date: Thu, 12 Sep 2019 10:35:32 -0400
Subject: [TUHS] SCCS
In-Reply-To: <03956472-B6A1-4E83-B2F1-0FE855C75C15@jctaylor.com>
References: <CANCZdfpEu6OxvmhDGSa3Cw4TSpfcbBOFbJjU7nZU-C_JFGFdRA@mail.gmail.com>
 <CAC20D2Pz+gwyeuVYcHFbJaimHtrt+sKSvCFp=hMZNoAWr4G09Q@mail.gmail.com>
 <CANCZdfpsXnbaQJo54qw689-unmVb35114PrOuNXHrcyp2Cng5g@mail.gmail.com>
 <CAC20D2MuABFQw_R2HyUFsg8Dpum+LNn6ixneO2C7Te8ECtZ3PA@mail.gmail.com>
 <20190911181101.GF3143@mcvoy.com>
 <alpine.BSF.2.21.9999.1909120846160.18105@aneurin.horsfall.org>
 <20190912034346.GJ2046@mcvoy.com>
 <a0231faa-8ad9-fa51-4b24-9854beb21210@gmail.com>
 <20190912043308.GL2046@mcvoy.com>
 <03956472-B6A1-4E83-B2F1-0FE855C75C15@jctaylor.com>
Message-ID: <CAC20D2Pk2F-pb5_0kxT-5TNeZk--d27wHE_-AR09dXcPZbHyTA@mail.gmail.com>

Like most things in life, what you value tends to make one thing more
important than another when you consider any object.  This is why programs
like editors; programming languages; and in this case, file revision
management software, gets such visceral responses from so many of us.   And
like many programs and subsystems, as deficiencies become more
obvious/acute with a program, when and how they are addressed also play
into that value.

Thus, I think it comes back to *use case* for everyone.  What am I
protecting with this subsystem and how does it affect me?

Frankly, the high order bit for me, is usually protection from my own
silliness (most important), how easy/natural it is to use/fit into my
workflow(next in importance); followed by accidental/on-purpose changes
happening by my friends/coworkers 'behind my back'(important); how merges
are handled when I'm in a group setting; and IF AND ONLY IF I'm using the
tool kit to protect IP for a 'product', how easy it is to support
'releases' past/current/in-development at the same time.

The truth is, when I'm leading product development, that last one moves up
a few places, although I know that if the 'fit' or ease of using the tool
is not nearly #1, some members of the team will not use said tool in the
planned and expected manner - so I think I will tend to value 'ease of use'
as the most important attribute for me.

Truth is SCCS and from what I know of BitKeeper, has always met my
criteria, certainly for simple programs and even for documents like papers
and books. As I said, its what I use day to day (thank you Marc and team).
While I learned the direct get/admin/delta/prs commands, calling them via
Eric's "sccs(ucb)" front-end 'fixed' the harder to use part of things.
Frankly, I have aliases 'get' to be 'sccs get' and the like.


I was at Tektronix and like many when Tichey released RCS by itself, Eric's
sccs(ucb) command was not available to me, so it seemed simpler and I was
attracted to it.  But I quickly went to UCB and was re-introduced to SCCS
using Eric's front-end and I found the difference was a nit.   SCCS was
what we used, so that became my go-to and has been for a long time.

SCCS was our systems at Masscomp, Stellar and later DEC (although DEC for
OSF/1 switched to another system whose name I forget which came from OSF).
 At LCC, we used what the customer used, so we got to see a lot of them ;-)

That said, when Thinking Machines released CVS-II (on top of RCS) it did
seem like the cvs merge management and production tags tended to be the
easier/a good thing.   When we used that system for an HP project at LCC, I
will say, the Thinking Machine crew had fixed the two issues I had
struggles with SCCS**.   I used cvs again for a few other projects
including two start-ups later.

Since that time, I have been given Mercurial, SVN, and git. I'll ignore the
first two as they seem to have fallen from grace. I personally, find git
extremely heavyweight and only deal with it because I have too thanks so
linux pushing it into so many FOSS projects.  I can and do have to use it,
but my experience is that we fight the tool constantly and I wonder if we
are ahead or behind.  The git system supposed to be great for merges and
so-called 'pull requests' and I can see if what you value is being able to
grab something from someone else - *i.e.* what Linus does daily (merge lots
of peoples 'suggestions') and it probably does make it easier for Linus.
But .... I can say in a product setting, I have observed it is messy to
keep track of specific versions of things that make up a 'product.  For
instance, I would like to be able to query, get me all the sources that
make of the 'Intel Parallel Studio, Cluster Edition'  (I don't think it can
be done!!

At least at DEC, when we released Ultrix, we put a tag into the DB and keep
a DB around for every file we used for the build.  There was a script that
could be run, that get do an 'sccs get' against every file and we could
rebuild everything (VAX or PMAX) and it even included some of the 'layered
products' that the OS team controlled.

So, my observation at Intel, is we have more people wasting backed time on
'maintaining our common pools' here than we ever did at DEC or at any of
start-ups.   As a sr person, I must say hmmmmm

Anyway - that's my 2 cents.


** Although, I'll believe Larry when he says he fixed said SCCS
deficiencies in Bitkeeper.  I will say after a quick examination of doc and
his emails, it does sound like he picked up some of the good ideas from
other systems, but I can not say I have tried it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190912/160dc92a/attachment.html>

From tuhs at eric.allman.name  Fri Sep 13 02:45:30 2019
From: tuhs at eric.allman.name (Eric Allman)
Date: Thu, 12 Sep 2019 09:45:30 -0700
Subject: [TUHS] SCCS
In-Reply-To: <a0231faa-8ad9-fa51-4b24-9854beb21210@gmail.com>
References: <CANCZdfpEu6OxvmhDGSa3Cw4TSpfcbBOFbJjU7nZU-C_JFGFdRA@mail.gmail.com>
 <CAC20D2Pz+gwyeuVYcHFbJaimHtrt+sKSvCFp=hMZNoAWr4G09Q@mail.gmail.com>
 <CANCZdfpsXnbaQJo54qw689-unmVb35114PrOuNXHrcyp2Cng5g@mail.gmail.com>
 <CAC20D2MuABFQw_R2HyUFsg8Dpum+LNn6ixneO2C7Te8ECtZ3PA@mail.gmail.com>
 <20190911181101.GF3143@mcvoy.com>
 <alpine.BSF.2.21.9999.1909120846160.18105@aneurin.horsfall.org>
 <20190912034346.GJ2046@mcvoy.com>
 <a0231faa-8ad9-fa51-4b24-9854beb21210@gmail.com>
Message-ID: <1457a2d6-2f17-482d-e4f7-ace439d34ca8@neophilic.com>

Actually I preferred SCCS for all the reasons that Larry has described.
 But SCCS was encumbered --- usable at the university, but not in a
commercial environment --- so it wasn't available at Britton-Lee at a
price we could afford, and RCS was pretty much the only other game in town.

Tichy was comparing against SCCS version 1, as described in the paper
"The source code control system" (Marc Rochkind, IEEE Transactions on
Software Engineering 1, 4, December 1975), which used forward deltas ---
very slow as your history got big.  I spent considerable time trying to
convince him that the version of SCCS in current production was as Larry
described, where any version could be read in linear time, but he wasn't
hearing anything that went against his beliefs.  So far as I know, he
never even looked at or measured the system he was comparing RCS to.

Today I probably wouldn't use SCCS, mostly because of the atomic update
problem (which was still broken in RCS, but fixed in CVS).  At this
point I'm using git because, well, all the cool kids are doing it, and
since I work at the university I have to go with the flow sometimes.
And git has some nice properties.  On the other hand, I have shot myself
in the foot with git more times than the sum of all other screwups with
all other source management systems combined.

eric


On 2019-09-11 21:28, Jon Forrest wrote:
> 
> 
> I used both RCS and SCCS in the early days (e.g. 1985 - 1991). RCS was
> what we used at Britton-Lee in the group that Eric Allman was part of.
> SCCS is what we used at Sybase as it was gaining popularity. This was
> so long ago that I don't remember all the details but I found that
> RCS was much easier to use, especially in an environment that didn't
> do much merging. Instead we used labels (or tags, I forget what they
> were called) to mark which files were part of which release. Doing
> this was much harder in SCCS, which contributed to the mess that
> was Sybase software engineering.
> 
> Of course, all this could be explained by Eric's deep knowledge
> of RCS, and the lack of somebody with Eric's knowledge at Sybase.
> But, to me, an early adopter of source code control who wasn't
> overly interested in speed, RCS was much easier to use.
> 
> Jon

From clemc at ccc.com  Fri Sep 13 03:29:27 2019
From: clemc at ccc.com (Clem Cole)
Date: Thu, 12 Sep 2019 13:29:27 -0400
Subject: [TUHS] SCCS
In-Reply-To: <1457a2d6-2f17-482d-e4f7-ace439d34ca8@neophilic.com>
References: <CANCZdfpEu6OxvmhDGSa3Cw4TSpfcbBOFbJjU7nZU-C_JFGFdRA@mail.gmail.com>
 <CAC20D2Pz+gwyeuVYcHFbJaimHtrt+sKSvCFp=hMZNoAWr4G09Q@mail.gmail.com>
 <CANCZdfpsXnbaQJo54qw689-unmVb35114PrOuNXHrcyp2Cng5g@mail.gmail.com>
 <CAC20D2MuABFQw_R2HyUFsg8Dpum+LNn6ixneO2C7Te8ECtZ3PA@mail.gmail.com>
 <20190911181101.GF3143@mcvoy.com>
 <alpine.BSF.2.21.9999.1909120846160.18105@aneurin.horsfall.org>
 <20190912034346.GJ2046@mcvoy.com>
 <a0231faa-8ad9-fa51-4b24-9854beb21210@gmail.com>
 <1457a2d6-2f17-482d-e4f7-ace439d34ca8@neophilic.com>
Message-ID: <CAC20D2OZpnma4EX+PqgqfA7zNM7sofuDQ4zCURnLF7-G4TCKhQ@mail.gmail.com>

On Thu, Sep 12, 2019 at 1:16 PM Eric Allman <tuhs at eric.allman.name> wrote:

>  At this point I'm using git because, well, all the cool kids are doing
> it, and
> since I work at the university I have to go with the flow sometimes.
> And git has some nice properties.  On the other hand, I have shot myself
> in the foot with git more times than the sum of all other screwups with
> all other source management systems combined.
>
> eric

+1
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190912/3fff477b/attachment.html>

From imp at bsdimp.com  Fri Sep 13 03:47:36 2019
From: imp at bsdimp.com (Warner Losh)
Date: Thu, 12 Sep 2019 11:47:36 -0600
Subject: [TUHS] SCCS
In-Reply-To: <CAC20D2OZpnma4EX+PqgqfA7zNM7sofuDQ4zCURnLF7-G4TCKhQ@mail.gmail.com>
References: <CANCZdfpEu6OxvmhDGSa3Cw4TSpfcbBOFbJjU7nZU-C_JFGFdRA@mail.gmail.com>
 <CAC20D2Pz+gwyeuVYcHFbJaimHtrt+sKSvCFp=hMZNoAWr4G09Q@mail.gmail.com>
 <CANCZdfpsXnbaQJo54qw689-unmVb35114PrOuNXHrcyp2Cng5g@mail.gmail.com>
 <CAC20D2MuABFQw_R2HyUFsg8Dpum+LNn6ixneO2C7Te8ECtZ3PA@mail.gmail.com>
 <20190911181101.GF3143@mcvoy.com>
 <alpine.BSF.2.21.9999.1909120846160.18105@aneurin.horsfall.org>
 <20190912034346.GJ2046@mcvoy.com>
 <a0231faa-8ad9-fa51-4b24-9854beb21210@gmail.com>
 <1457a2d6-2f17-482d-e4f7-ace439d34ca8@neophilic.com>
 <CAC20D2OZpnma4EX+PqgqfA7zNM7sofuDQ4zCURnLF7-G4TCKhQ@mail.gmail.com>
Message-ID: <CANCZdfqtqb6WtGP=CuzMwAGdY_FrdjSFEV3Apkf-LgCOb-Nngg@mail.gmail.com>

On Thu, Sep 12, 2019, 11:30 AM Clem Cole <clemc at ccc.com> wrote:

>
>
> On Thu, Sep 12, 2019 at 1:16 PM Eric Allman <tuhs at eric.allman.name> wrote:
>
>>  At this point I'm using git because, well, all the cool kids are doing
>> it, and
>> since I work at the university I have to go with the flow sometimes.
>> And git has some nice properties.  On the other hand, I have shot myself
>> in the foot with git more times than the sum of all other screwups with
>> all other source management systems combined.
>>
>> eric
>
> +1
>

Mercurial still holds that honor for me. I've screwed up so bad I had to
reclone and lost work. Dozens of times. :(.

Git is just as easy to screw up. And were it not for the extensive "hole in
foot first aid" feature git has, I'd be there too... I hate the cli because
it seems overtly hostile to orthogonality, consistency and logic. But learn
the warts and it gets the job done.

Warner

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190912/bd47fb00/attachment.html>

From arnold at skeeve.com  Fri Sep 13 04:16:57 2019
From: arnold at skeeve.com (Arnold Robbins)
Date: Thu, 12 Sep 2019 21:16:57 +0300
Subject: [TUHS] Livermore software tools dist
Message-ID: <201909121816.x8CIGvKY006528@skeeve.com>

See https://drive.google.com/file/d/0ByJs3HoO8aRVd1JlOGJWRlJhTDg/view
which seems to be stuff from 1984 and 1988.

I have no idea where it came from or anything else; I stumbled across
it while looking for some other things.

Thanks,

Arnold

From kevin.bowling at kev009.com  Fri Sep 13 05:31:13 2019
From: kevin.bowling at kev009.com (Kevin Bowling)
Date: Thu, 12 Sep 2019 12:31:13 -0700
Subject: [TUHS] IBM Unix source licenses [was Re: PWB vs Unix/TS
In-Reply-To: <c704d50c-dc9b-c703-a18c-86c411ae5d3f@technologists.com>
References: <CANCZdfpEu6OxvmhDGSa3Cw4TSpfcbBOFbJjU7nZU-C_JFGFdRA@mail.gmail.com>
 <CAC20D2Pz+gwyeuVYcHFbJaimHtrt+sKSvCFp=hMZNoAWr4G09Q@mail.gmail.com>
 <CANCZdfpsXnbaQJo54qw689-unmVb35114PrOuNXHrcyp2Cng5g@mail.gmail.com>
 <CAC20D2MuABFQw_R2HyUFsg8Dpum+LNn6ixneO2C7Te8ECtZ3PA@mail.gmail.com>
 <c704d50c-dc9b-c703-a18c-86c411ae5d3f@technologists.com>
Message-ID: <CAK7dMtDKRe99jY4iN8zkHo=evMYDOrmF8X1zLAf+sRxR3d7CmQ@mail.gmail.com>

Charlie, there is some interesting history of the pre-RS/6000 AIX
stuff here (you give a quote :)).  Particularly page 41 gives a
chronology of UNIX at IBM:
https://amaus.net/static/S100/IBM/RTPC/AIX%20Family%20Definition%201989.pdf

Prior to AIX the Series/1 had a UNIX port in the early '80s.  I think
that work happened in Boca Raton.

There are some bizarre anecdotes from Craig Newmark on the above
https://craigconnects.org/2014/12/29/knowing-when-to-keep-your-mouth-shut/.
The S/1 was a PDP competitor (or at least very squarely in the PLC,
interfacing and real time worlds) and IBM was driving much more
successful product lines, especially the PC, and later AT and RT, that
were better suited for competing in the UNIX space.

I don't remember where I read this, but I recently came across someone
claiming that AT&T tried to sell UNIX to IBM outright in the early
1980s.  I'm guessing '81-'82 because the '83 divestment opened up the
direct commercialization by AT&T as System III/V.

Regards,
Kevin

On Wed, Sep 11, 2019 at 9:55 AM Charles H Sauer <sauer at technologists.com> wrote:
>
> On 9/11/2019 10:36 AM, Clem Cole wrote:
> ...
> > OSF would eventually use the IBM SVR3 license as its base [which
> > makes me believe IBM must have had a V7 redistribution license too.
> > Somebody like Charlie Saurer might know].  Anyway, IBM, DEC and HP all
> > shipped OSF 'licensed' systems although only DEC would switch to an
> > OSF/1 based kernel.
>
> "Sauer"
>
> idk. As far as I know, IBM Austin did not get source licenses until
> System V. Before Clay Cipione became the AIX development manager in the
> AFWS -> RT transition, Austin did not have source licenses, as far as I
> know. Clay insisted that we have source.
>
> It is plausible that Don Rozenberg had V7 license at Yorktown and/or
> ACIS had V7 license for BSD stuff.
>
> I'm blind copying Clay and another AIX alumnus that might know for sure.
>
> Charlie
> --
> voice: +1.512.784.7526       e-mail: sauer at technologists.com
> fax: +1.512.346.5240         Web: https://technologists.com/sauer/
> Facebook/Google/Skype/Twitter: CharlesHSauer

From cym224 at gmail.com  Fri Sep 13 06:07:39 2019
From: cym224 at gmail.com (Nemo)
Date: Thu, 12 Sep 2019 16:07:39 -0400
Subject: [TUHS] SCCS
In-Reply-To: <20190912034346.GJ2046@mcvoy.com>
References: <CANCZdfpEu6OxvmhDGSa3Cw4TSpfcbBOFbJjU7nZU-C_JFGFdRA@mail.gmail.com>
 <CAC20D2Pz+gwyeuVYcHFbJaimHtrt+sKSvCFp=hMZNoAWr4G09Q@mail.gmail.com>
 <CANCZdfpsXnbaQJo54qw689-unmVb35114PrOuNXHrcyp2Cng5g@mail.gmail.com>
 <CAC20D2MuABFQw_R2HyUFsg8Dpum+LNn6ixneO2C7Te8ECtZ3PA@mail.gmail.com>
 <20190911181101.GF3143@mcvoy.com>
 <alpine.BSF.2.21.9999.1909120846160.18105@aneurin.horsfall.org>
 <20190912034346.GJ2046@mcvoy.com>
Message-ID: <CAJfiPzxXhf-byyzW_Z=XJbirbaaGJRWrw4E7N=b7Eu4qXdek+g@mail.gmail.com>

On 11/09/2019, Larry McVoy <lm at mcvoy.com> wrote:
> On Thu, Sep 12, 2019 at 08:49:35AM +1000, Dave Horsfall wrote:
>> On Wed, 11 Sep 2019, Larry McVoy wrote:
>>
>> >SCCS is awesome, I'll post why in a different thread.  It is light years
>> >better than RCS, Tichy lied.
>>
>> Agreed; I used it for years, then was forced to use RCS in my next job
>> :-(
>
> Marc Rochkind is on the list, I believe I invited him, but he can spell
> check what I'm about to say.
>
> SCCS is awesome.

I just learnt that Schily maintains source at http://sccs.sourceforge.net/
(Of course, I have it on my Solaris boxen and may now try it on others.)

N.

From clemc at ccc.com  Fri Sep 13 06:59:48 2019
From: clemc at ccc.com (Clem Cole)
Date: Thu, 12 Sep 2019 16:59:48 -0400
Subject: [TUHS] IBM Unix source licenses [was Re: PWB vs Unix/TS
In-Reply-To: <CAK7dMtDKRe99jY4iN8zkHo=evMYDOrmF8X1zLAf+sRxR3d7CmQ@mail.gmail.com>
References: <CANCZdfpEu6OxvmhDGSa3Cw4TSpfcbBOFbJjU7nZU-C_JFGFdRA@mail.gmail.com>
 <CAC20D2Pz+gwyeuVYcHFbJaimHtrt+sKSvCFp=hMZNoAWr4G09Q@mail.gmail.com>
 <CANCZdfpsXnbaQJo54qw689-unmVb35114PrOuNXHrcyp2Cng5g@mail.gmail.com>
 <CAC20D2MuABFQw_R2HyUFsg8Dpum+LNn6ixneO2C7Te8ECtZ3PA@mail.gmail.com>
 <c704d50c-dc9b-c703-a18c-86c411ae5d3f@technologists.com>
 <CAK7dMtDKRe99jY4iN8zkHo=evMYDOrmF8X1zLAf+sRxR3d7CmQ@mail.gmail.com>
Message-ID: <CAC20D2MnW8yr+D-L7hV5XYNtVAmjT9z5vY41CCYYuxUvVJ51Sw@mail.gmail.com>

Kevin/Charlie:

On Thu, Sep 12, 2019 at 3:31 PM Kevin Bowling <kevin.bowling at kev009.com>
wrote:

> Charlie, there is some interesting history of the pre-RS/6000 AIX
> stuff here (you give a quote :)).  Particularly page 41 gives a
> chronology of UNIX at IBM:
> https://amaus.net/static/S100/IBM/RTPC/AIX%20Family%20Definition%201989.pdf

Awesome - thank you,



>
>
> Prior to AIX the Series/1 had a UNIX port in the early '80s.  I think
> that work happened in Boca Raton.
>
FYI: the original S/1 port was done at Cleveland State with the Seventh
Edition - the name of the Prof that led it I can not say I remember nor his
HW configuration, but I do remember his presentation.  It is where the term
'NUXI' was coined.  I want to say in 1979 or 1980, they gave a wonderful
talk about it.   They had some help from folks at Case as they did not have
a PDP-11 of their own and never seen UNIX before (*i.e.* they arranged to
borrowed time on a PDP-11 at the EE Dept at Case.  They wrote a new back
end for the Ritchie C compiler, and recompiled everything, wrote new
drivers for the S/1 HW and rewrote m40.s as needed.  Then they wrote the
disks, then drove the packs back to Cleveland State.  IIRC it took a summer
of work to complete).

FWIW: The PDP-11 has an interesting way it does byte-swapping and when they
first booted the system, the first message was NUXI which was how the S/1
saw the strings.  The term was used from then on in the community to
describe byte-swapping issues.

I remember all of us in the audience howling with laughter when they
described their work.    Unfortunately, this was before USENIX kept
conference proceedings so I'm not sure if the talk and paper were archived.

And the truth is, I wish we had that port in the TUHS archives.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190912/807969fb/attachment-0001.html>

From ron at ronnatalie.com  Fri Sep 13 07:09:35 2019
From: ron at ronnatalie.com (Ronald Natalie)
Date: Thu, 12 Sep 2019 17:09:35 -0400
Subject: [TUHS] IBM Unix source licenses - Series/1 NUXI
In-Reply-To: <CAC20D2MnW8yr+D-L7hV5XYNtVAmjT9z5vY41CCYYuxUvVJ51Sw@mail.gmail.com>
References: <CANCZdfpEu6OxvmhDGSa3Cw4TSpfcbBOFbJjU7nZU-C_JFGFdRA@mail.gmail.com>
 <CAC20D2Pz+gwyeuVYcHFbJaimHtrt+sKSvCFp=hMZNoAWr4G09Q@mail.gmail.com>
 <CANCZdfpsXnbaQJo54qw689-unmVb35114PrOuNXHrcyp2Cng5g@mail.gmail.com>
 <CAC20D2MuABFQw_R2HyUFsg8Dpum+LNn6ixneO2C7Te8ECtZ3PA@mail.gmail.com>
 <c704d50c-dc9b-c703-a18c-86c411ae5d3f@technologists.com>
 <CAK7dMtDKRe99jY4iN8zkHo=evMYDOrmF8X1zLAf+sRxR3d7CmQ@mail.gmail.com>
 <CAC20D2MnW8yr+D-L7hV5XYNtVAmjT9z5vY41CCYYuxUvVJ51Sw@mail.gmail.com>
Message-ID: <0342AEA8-FAEA-47C4-A518-CC33C5BA1D6A@ronnatalie.com>

Indeed, I remember this.  It was either at the UDEL or UToronto meeting if I recall

I also remember a talk from a fledgling Microsoft group (when all Microsoft was known for at the time was BASIC).

It was also at the UDel conference where MIke Muuss got booed for announcing he was from the Army’s lead laboratory in Vulnerability and Lethality analysis.

I also remember this guy getting booed off the stage for making a commercial sales pitch.    Years later I’m having dinner with Mark Krieger (then of UniPress) and it dawned on me:
You were the one who got booed at UDel.   He said he had been half of Whitesmiths.   I laughed.    I recounted when I saw their VMS C compiler came with a license “stamp” you were supposed to stick on your machine.
I wanted to know if that was so when the Whitesmith’s police came by they’d know we were licensed.  He said he was gone by that point and that was how he knew Plauger had gone over the edge.

I was working at Rutgers at the time and on a visit to a site on the Newark canvas I found someone actually stuck one of these stamps on the CPU there.   I carefully peeled it off and gave it to Mark for sentimental reasons.

> On Sep 12, 2019, at 4:59 PM, Clem Cole <clemc at ccc.com> wrote:
> 
> Kevin/Charlie:
> 
> On Thu, Sep 12, 2019 at 3:31 PM Kevin Bowling <kevin.bowling at kev009.com <mailto:kevin.bowling at kev009.com>> wrote:
> Charlie, there is some interesting history of the pre-RS/6000 AIX
> stuff here (you give a quote :)).  Particularly page 41 gives a
> chronology of UNIX at IBM:
> https://amaus.net/static/S100/IBM/RTPC/AIX%20Family%20Definition%201989.pdf <https://amaus.net/static/S100/IBM/RTPC/AIX%20Family%20Definition%201989.pdf>
> Awesome - thank you,
> 
>  
> 
> 
> Prior to AIX the Series/1 had a UNIX port in the early '80s.  I think
> that work happened in Boca Raton.
> FYI: the original S/1 port was done at Cleveland State with the Seventh Edition - the name of the Prof that led it I can not say I remember nor his HW configuration, but I do remember his presentation.  It is where the term 'NUXI' was coined.  I want to say in 1979 or 1980, they gave a wonderful talk about it.   They had some help from folks at Case as they did not have a PDP-11 of their own and never seen UNIX before (i.e. they arranged to borrowed time on a PDP-11 at the EE Dept at Case.  They wrote a new back end for the Ritchie C compiler, and recompiled everything, wrote new drivers for the S/1 HW and rewrote m40.s as needed.  Then they wrote the disks, then drove the packs back to Cleveland State.  IIRC it took a summer of work to complete).  
> 
> FWIW: The PDP-11 has an interesting way it does byte-swapping and when they first booted the system, the first message was NUXI which was how the S/1 saw the strings.  The term was used from then on in the community to describe byte-swapping issues.
> 
> I remember all of us in the audience howling with laughter when they described their work.    Unfortunately, this was before USENIX kept conference proceedings so I'm not sure if the talk and paper were archived.
> 
> And the truth is, I wish we had that port in the TUHS archives. 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190912/515886d5/attachment.html>

From sauer at technologists.com  Fri Sep 13 07:29:34 2019
From: sauer at technologists.com (Charles H Sauer)
Date: Thu, 12 Sep 2019 16:29:34 -0500
Subject: [TUHS] IBM Unix source licenses [was Re: PWB vs Unix/TS
In-Reply-To: <CAK7dMtDKRe99jY4iN8zkHo=evMYDOrmF8X1zLAf+sRxR3d7CmQ@mail.gmail.com>
References: <CANCZdfpEu6OxvmhDGSa3Cw4TSpfcbBOFbJjU7nZU-C_JFGFdRA@mail.gmail.com>
 <CAC20D2Pz+gwyeuVYcHFbJaimHtrt+sKSvCFp=hMZNoAWr4G09Q@mail.gmail.com>
 <CANCZdfpsXnbaQJo54qw689-unmVb35114PrOuNXHrcyp2Cng5g@mail.gmail.com>
 <CAC20D2MuABFQw_R2HyUFsg8Dpum+LNn6ixneO2C7Te8ECtZ3PA@mail.gmail.com>
 <c704d50c-dc9b-c703-a18c-86c411ae5d3f@technologists.com>
 <CAK7dMtDKRe99jY4iN8zkHo=evMYDOrmF8X1zLAf+sRxR3d7CmQ@mail.gmail.com>
Message-ID: <8f2cc8f5-3a1d-335a-e6f4-70dfe366f5ca@technologists.com>



On 9/12/2019 2:31 PM, Kevin Bowling wrote:
> Charlie, there is some interesting history of the pre-RS/6000 AIX
> stuff here (you give a quote :)).  Particularly page 41 gives a
> chronology of UNIX at IBM:
> https://amaus.net/static/S100/IBM/RTPC/AIX%20Family%20Definition%201989.pdf

I wasn't aware of this doc or this site. Thanks.

Just glancing at the doc, I find lots of things to question, but won't 
do so, at least not now.

They're quoting Larry Loucks, while attributing the VRM to him and me, 
which was revisionist at the time vs. all the others deserving of that 
attribution. I'm surprised I was referenced at all in a 1989 publication 
-- I was mostly purged from AIX literature in process after I left for 
Dell 5/2/89. Also ironic that they emphasized Larry. He deserved the 
credit, but had been coerced to leave AIX to work on OS/2.

CHS
-- 
voice: +1.512.784.7526       e-mail: sauer at technologists.com
fax: +1.512.346.5240         Web: https://technologists.com/sauer/
Facebook/Google/Skype/Twitter: CharlesHSauer

From imp at bsdimp.com  Fri Sep 13 07:31:08 2019
From: imp at bsdimp.com (Warner Losh)
Date: Thu, 12 Sep 2019 15:31:08 -0600
Subject: [TUHS] IBM Unix source licenses [was Re: PWB vs Unix/TS
In-Reply-To: <CAC20D2MnW8yr+D-L7hV5XYNtVAmjT9z5vY41CCYYuxUvVJ51Sw@mail.gmail.com>
References: <CANCZdfpEu6OxvmhDGSa3Cw4TSpfcbBOFbJjU7nZU-C_JFGFdRA@mail.gmail.com>
 <CAC20D2Pz+gwyeuVYcHFbJaimHtrt+sKSvCFp=hMZNoAWr4G09Q@mail.gmail.com>
 <CANCZdfpsXnbaQJo54qw689-unmVb35114PrOuNXHrcyp2Cng5g@mail.gmail.com>
 <CAC20D2MuABFQw_R2HyUFsg8Dpum+LNn6ixneO2C7Te8ECtZ3PA@mail.gmail.com>
 <c704d50c-dc9b-c703-a18c-86c411ae5d3f@technologists.com>
 <CAK7dMtDKRe99jY4iN8zkHo=evMYDOrmF8X1zLAf+sRxR3d7CmQ@mail.gmail.com>
 <CAC20D2MnW8yr+D-L7hV5XYNtVAmjT9z5vY41CCYYuxUvVJ51Sw@mail.gmail.com>
Message-ID: <CANCZdfq4WvaraYMt2Ff9Xgdnv_X5fLAifveQThZr2RZ7gdq=Xg@mail.gmail.com>

On Thu, Sep 12, 2019 at 3:01 PM Clem Cole <clemc at ccc.com> wrote:

> Kevin/Charlie:
>
> On Thu, Sep 12, 2019 at 3:31 PM Kevin Bowling <kevin.bowling at kev009.com>
> wrote:
>
>> Charlie, there is some interesting history of the pre-RS/6000 AIX
>> stuff here (you give a quote :)).  Particularly page 41 gives a
>> chronology of UNIX at IBM:
>>
>> https://amaus.net/static/S100/IBM/RTPC/AIX%20Family%20Definition%201989.pdf
>
> Awesome - thank you,
>
>
>
>>
>>
>> Prior to AIX the Series/1 had a UNIX port in the early '80s.  I think
>> that work happened in Boca Raton.
>>
> FYI: the original S/1 port was done at Cleveland State with the Seventh
> Edition - the name of the Prof that led it I can not say I remember nor his
> HW configuration, but I do remember his presentation.  It is where the term
> 'NUXI' was coined.  I want to say in 1979 or 1980, they gave a wonderful
> talk about it.   They had some help from folks at Case as they did not have
> a PDP-11 of their own and never seen UNIX before (*i.e.* they arranged to
> borrowed time on a PDP-11 at the EE Dept at Case.  They wrote a new back
> end for the Ritchie C compiler, and recompiled everything, wrote new
> drivers for the S/1 HW and rewrote m40.s as needed.  Then they wrote the
> disks, then drove the packs back to Cleveland State.  IIRC it took a summer
> of work to complete).
>
> FWIW: The PDP-11 has an interesting way it does byte-swapping and when
> they first booted the system, the first message was NUXI which was how the
> S/1 saw the strings.  The term was used from then on in the community to
> describe byte-swapping issues.
>
> I remember all of us in the audience howling with laughter when they
> described their work.    Unfortunately, this was before USENIX kept
> conference proceedings so I'm not sure if the talk and paper were archived.
>
> And the truth is, I wish we had that port in the TUHS archives.
>

Me too. This is a port I had no clue about.... I'll have to put it in my
slides as "S/1 NUXI" :)

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190912/bf1222c5/attachment.html>

From lists at irreal.org  Fri Sep 13 08:30:52 2019
From: lists at irreal.org (jcs)
Date: Thu, 12 Sep 2019 18:30:52 -0400
Subject: [TUHS] IBM Unix source licenses [was Re: PWB vs Unix/TS
In-Reply-To: <CAC20D2MnW8yr+D-L7hV5XYNtVAmjT9z5vY41CCYYuxUvVJ51Sw@mail.gmail.com>
References: <CANCZdfpEu6OxvmhDGSa3Cw4TSpfcbBOFbJjU7nZU-C_JFGFdRA@mail.gmail.com>
 <CAC20D2Pz+gwyeuVYcHFbJaimHtrt+sKSvCFp=hMZNoAWr4G09Q@mail.gmail.com>
 <CANCZdfpsXnbaQJo54qw689-unmVb35114PrOuNXHrcyp2Cng5g@mail.gmail.com>
 <CAC20D2MuABFQw_R2HyUFsg8Dpum+LNn6ixneO2C7Te8ECtZ3PA@mail.gmail.com>
 <c704d50c-dc9b-c703-a18c-86c411ae5d3f@technologists.com>
 <CAK7dMtDKRe99jY4iN8zkHo=evMYDOrmF8X1zLAf+sRxR3d7CmQ@mail.gmail.com>
 <CAC20D2MnW8yr+D-L7hV5XYNtVAmjT9z5vY41CCYYuxUvVJ51Sw@mail.gmail.com>
Message-ID: <m27e6d2llv.fsf@irreal.org>


Clem Cole <clemc at ccc.com> writes:

> FYI: the original S/1 port was done at Cleveland State with the 
> Seventh
> Edition - the name of the Prof that led it I can not say I 
> remember nor his
> HW configuration...

http://delivery.acm.org/10.1145/360000/358504/p1066-jalics.pdf

From reed at reedmedia.net  Fri Sep 13 09:12:24 2019
From: reed at reedmedia.net (reed at reedmedia.net)
Date: Thu, 12 Sep 2019 18:12:24 -0500 (CDT)
Subject: [TUHS] IBM Unix source licenses [was Re: PWB vs Unix/TS
In-Reply-To: <m27e6d2llv.fsf@irreal.org>
References: <CANCZdfpEu6OxvmhDGSa3Cw4TSpfcbBOFbJjU7nZU-C_JFGFdRA@mail.gmail.com>
 <CAC20D2Pz+gwyeuVYcHFbJaimHtrt+sKSvCFp=hMZNoAWr4G09Q@mail.gmail.com>
 <CANCZdfpsXnbaQJo54qw689-unmVb35114PrOuNXHrcyp2Cng5g@mail.gmail.com>
 <CAC20D2MuABFQw_R2HyUFsg8Dpum+LNn6ixneO2C7Te8ECtZ3PA@mail.gmail.com>
 <c704d50c-dc9b-c703-a18c-86c411ae5d3f@technologists.com>
 <CAK7dMtDKRe99jY4iN8zkHo=evMYDOrmF8X1zLAf+sRxR3d7CmQ@mail.gmail.com>
 <CAC20D2MnW8yr+D-L7hV5XYNtVAmjT9z5vY41CCYYuxUvVJ51Sw@mail.gmail.com>
 <m27e6d2llv.fsf@irreal.org>
Message-ID: <alpine.NEB.2.21.1909121811410.18938@t1.m.reedmedia.net>

On Thu, 12 Sep 2019, jcs wrote:

> 
> Clem Cole <clemc at ccc.com> writes:
> 
> > FYI: the original S/1 port was done at Cleveland State with the Seventh
> > Edition - the name of the Prof that led it I can not say I remember nor his
> > HW configuration...
> 
> http://delivery.acm.org/10.1145/360000/358504/p1066-jalics.pdf

Can you share an abstract or summary for that?

(I get an error I assume because I don't have a login.)

From wkt at tuhs.org  Fri Sep 13 09:29:09 2019
From: wkt at tuhs.org (Warren Toomey)
Date: Fri, 13 Sep 2019 09:29:09 +1000
Subject: [TUHS] IBM Unix source licenses
In-Reply-To: <m27e6d2llv.fsf@irreal.org>
References: <CANCZdfpEu6OxvmhDGSa3Cw4TSpfcbBOFbJjU7nZU-C_JFGFdRA@mail.gmail.com>
 <CAC20D2Pz+gwyeuVYcHFbJaimHtrt+sKSvCFp=hMZNoAWr4G09Q@mail.gmail.com>
 <CANCZdfpsXnbaQJo54qw689-unmVb35114PrOuNXHrcyp2Cng5g@mail.gmail.com>
 <CAC20D2MuABFQw_R2HyUFsg8Dpum+LNn6ixneO2C7Te8ECtZ3PA@mail.gmail.com>
 <c704d50c-dc9b-c703-a18c-86c411ae5d3f@technologists.com>
 <CAK7dMtDKRe99jY4iN8zkHo=evMYDOrmF8X1zLAf+sRxR3d7CmQ@mail.gmail.com>
 <CAC20D2MnW8yr+D-L7hV5XYNtVAmjT9z5vY41CCYYuxUvVJ51Sw@mail.gmail.com>
 <m27e6d2llv.fsf@irreal.org>
Message-ID: <20190912232909.GA15734@minnie.tuhs.org>

Clem Cole <clemc at ccc.com> writes:
> 
> > FYI: the original S/1 port was done at Cleveland State with the Seventh
> > Edition - the name of the Prof that led it I can not say I remember nor
> > his
> > HW configuration...
 
On Thu, Sep 12, 2019 at 06:30:52PM -0400, jcs wrote:
> http://delivery.acm.org/10.1145/360000/358504/p1066-jalics.pdf

Also available at:
https://zero.sci-hub.se/3252/016657c71a46a2d7110d87b4f720847e/jalics1983.pdf

	Warren

From lists at irreal.org  Fri Sep 13 09:22:56 2019
From: lists at irreal.org (jcs)
Date: Thu, 12 Sep 2019 19:22:56 -0400
Subject: [TUHS] IBM Unix source licenses [was Re: PWB vs Unix/TS
In-Reply-To: <alpine.NEB.2.21.1909121811410.18938@t1.m.reedmedia.net>
References: <CANCZdfpEu6OxvmhDGSa3Cw4TSpfcbBOFbJjU7nZU-C_JFGFdRA@mail.gmail.com>
 <CAC20D2Pz+gwyeuVYcHFbJaimHtrt+sKSvCFp=hMZNoAWr4G09Q@mail.gmail.com>
 <CANCZdfpsXnbaQJo54qw689-unmVb35114PrOuNXHrcyp2Cng5g@mail.gmail.com>
 <CAC20D2MuABFQw_R2HyUFsg8Dpum+LNn6ixneO2C7Te8ECtZ3PA@mail.gmail.com>
 <c704d50c-dc9b-c703-a18c-86c411ae5d3f@technologists.com>
 <CAK7dMtDKRe99jY4iN8zkHo=evMYDOrmF8X1zLAf+sRxR3d7CmQ@mail.gmail.com>
 <CAC20D2MnW8yr+D-L7hV5XYNtVAmjT9z5vY41CCYYuxUvVJ51Sw@mail.gmail.com>
 <m27e6d2llv.fsf@irreal.org>
 <alpine.NEB.2.21.1909121811410.18938@t1.m.reedmedia.net>
Message-ID: <m25zlx2j73.fsf@irreal.org>


reed at reedmedia.net writes:

> On Thu, 12 Sep 2019, jcs wrote:
>
>> 
>> Clem Cole <clemc at ccc.com> writes:
>> 
>> > FYI: the original S/1 port was done at Cleveland State with 
>> > the Seventh
>> > Edition - the name of the Prof that led it I can not say I 
>> > remember nor his
>> > HW configuration...
>> 
>> http://delivery.acm.org/10.1145/360000/358504/p1066-jalics.pdf
>
> Can you share an abstract or summary for that?
>
> (I get an error I assume because I don't have a login.)

Oops, sorry. Here's the metadata:
https://dl.acm.org/citation.cfm?doid=358476.358504

The paper, _Transporting a portable operating system: UNIX to an 
IBM minicomputer_, is also available from Sci-Hub if you don't 
mind that.

From imp at bsdimp.com  Fri Sep 13 13:20:20 2019
From: imp at bsdimp.com (Warner Losh)
Date: Thu, 12 Sep 2019 21:20:20 -0600
Subject: [TUHS] My EuroBSDcon talk (preview for commentary)
Message-ID: <CANCZdfrK4iFQCWOFP4MoUggpfJVmoJ0dnSg6H0cCi4dop7sVXw@mail.gmail.com>

OK. I've shared my slides for the talk.

Some of the family trees are simplified (V7 doesn't have room for all its
ports, for example)
Some of it is a little cheeseball since I'm also trying to be witty and
entertaining (we'll see how that goes).
Please don't share them around until after my talk on the September 20th

I'd like feedback on the bits I got wrong. Or left out. Or if you're in
this and don't want to be, etc.

All the slides after the Questions slide won't be presented and will likely
be deleted.

https://docs.google.com/presentation/d/177KxOif5oHARyIdZHDq-OO67_GVtMkzIAlDX-cHxgb4/edit?usp=sharing

Please be kind (but if it sucks, please do tell). I've turned on commenting
on the slides. Probably best if you comment there.

I have a video of me giving this talk, but it's too rough to share...

Thanks for any help you can give me.

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190912/06123dc6/attachment.html>

From lm at mcvoy.com  Fri Sep 13 14:11:17 2019
From: lm at mcvoy.com (Larry McVoy)
Date: Thu, 12 Sep 2019 21:11:17 -0700
Subject: [TUHS] [SPAM] Re:  SCCS
In-Reply-To: <alpine.DEB.2.20.1909121417040.5352@grey.csi.cam.ac.uk>
References: <CANCZdfpEu6OxvmhDGSa3Cw4TSpfcbBOFbJjU7nZU-C_JFGFdRA@mail.gmail.com>
 <CAC20D2Pz+gwyeuVYcHFbJaimHtrt+sKSvCFp=hMZNoAWr4G09Q@mail.gmail.com>
 <CANCZdfpsXnbaQJo54qw689-unmVb35114PrOuNXHrcyp2Cng5g@mail.gmail.com>
 <CAC20D2MuABFQw_R2HyUFsg8Dpum+LNn6ixneO2C7Te8ECtZ3PA@mail.gmail.com>
 <20190911181101.GF3143@mcvoy.com>
 <alpine.BSF.2.21.9999.1909120846160.18105@aneurin.horsfall.org>
 <20190912034346.GJ2046@mcvoy.com>
 <CAKr6gn39D_XrOHXr22EUsEWhCUcFJw2n6C8iQ_ntXGkbO33irw@mail.gmail.com>
 <20190912043145.GA12480@mcvoy.com>
 <alpine.DEB.2.20.1909121417040.5352@grey.csi.cam.ac.uk>
Message-ID: <20190913041117.GR2046@mcvoy.com>

On Thu, Sep 12, 2019 at 02:44:45PM +0100, Tony Finch wrote:
> Larry McVoy <lm at mcvoy.com> wrote:
> 
> > If you have actual data that shows RCS to be faster I would like to
> > see that.  RCS read the whole file.  It could have been faster, it could
> > have put the offset into the file where the most recent version begain.
> > But it didn't.  It read the entire file.
> 
> In RCS the most recent version of the file is near the start of the ,v
> file after a list of revisions, so it doesn't have to read the deltas for
> the common case of checking out the current version of a file. I think
> there must be a similar optimization to copy the deltas without processing
> them when committing a new revision. But yes, as soon as you get away from
> working on the latest revision of the main branch, RCS becomes
> quadratically slow.

Yeah, you are right. The most recent version should be fast.  SCCS reads
the whole file and RCS does not in the common case.

But here is an SCCS win.  SCCS has a 16 bit ignore the carry bit checksum
over the whole file.  RCS has none of that.

You can argue that a 16 bit checksum is not good enough in this day of
md5sums, sha1 hashes, crcs, etc.

There are two places where it is great.

A) Memory errors.  Memory chips errors are none, parity, or ECC.
Parity has gone the way of the doodoo bird so we have none or ECC.  I can
pretty much promise you that the machine you are reading this on has no
error detection or correction.  Only high end servers have ECC.

That SCCS checksum is awesome because we can print out what the checksum
should be and what we got.  If it differs in a power of two then it is
a single bit error and that is your memory sucks.  I can't tell you how
many times customers said something was wrong and I made them run a 
memory check and it was their memory.  100's is too small, 1000's 
at least.

B) NFS errors.  So all NFS implementations, Suns included, had a bad
habit of returning a block of nulls.  I dunno why but that is a thing.
The SCCS checksum would detect that.  RCS and CVS did not have a checksum
so when NFS returned garbage, they were happy to return that to you.

It's really surprising how well the SCCS checksum has worked.  When we
went to a binary format we did CRC on each block and XOR so we could
put stuff back together.  I still have a lot of respect for that little
checksum.  It served us well.

--lm

From dave at horsfall.org  Fri Sep 13 15:22:58 2019
From: dave at horsfall.org (Dave Horsfall)
Date: Fri, 13 Sep 2019 15:22:58 +1000 (EST)
Subject: [TUHS] SCCS
In-Reply-To: <20190912043308.GL2046@mcvoy.com>
References: <CANCZdfpEu6OxvmhDGSa3Cw4TSpfcbBOFbJjU7nZU-C_JFGFdRA@mail.gmail.com>
 <CAC20D2Pz+gwyeuVYcHFbJaimHtrt+sKSvCFp=hMZNoAWr4G09Q@mail.gmail.com>
 <CANCZdfpsXnbaQJo54qw689-unmVb35114PrOuNXHrcyp2Cng5g@mail.gmail.com>
 <CAC20D2MuABFQw_R2HyUFsg8Dpum+LNn6ixneO2C7Te8ECtZ3PA@mail.gmail.com>
 <20190911181101.GF3143@mcvoy.com>
 <alpine.BSF.2.21.9999.1909120846160.18105@aneurin.horsfall.org>
 <20190912034346.GJ2046@mcvoy.com>
 <a0231faa-8ad9-fa51-4b24-9854beb21210@gmail.com>
 <20190912043308.GL2046@mcvoy.com>
Message-ID: <alpine.BSF.2.21.9999.1909131514360.18105@aneurin.horsfall.org>

On Wed, 11 Sep 2019, Larry McVoy wrote:

> Yeah, this was one of things that BitKeeper addressed.  It was easier to 
> use and every commit was a tag.

That reminds me: I really must take another look at BK for my stuff.

At the moment I'm using say "fred.c-" for the previous version etc (and 
"fred.c+" for something finished but not quite ready to install).

I've also renamed entire directory trees to sub-tree under "OLD" etc :-)

SCCS/RCS are history as far as I'm concerned; I never quite got the hang 
of CVS (which OpenLDAP uses); and I've heard all sorts of horror stories 
about GIT to keep me away from it...

-- Dave

From bakul at bitblocks.com  Fri Sep 13 15:50:12 2019
From: bakul at bitblocks.com (Bakul Shah)
Date: Thu, 12 Sep 2019 22:50:12 -0700
Subject: [TUHS] SCCS
In-Reply-To: Your message of "Fri, 13 Sep 2019 15:22:58 +1000."
 <alpine.BSF.2.21.9999.1909131514360.18105@aneurin.horsfall.org>
References: <CANCZdfpEu6OxvmhDGSa3Cw4TSpfcbBOFbJjU7nZU-C_JFGFdRA@mail.gmail.com>
 <CAC20D2Pz+gwyeuVYcHFbJaimHtrt+sKSvCFp=hMZNoAWr4G09Q@mail.gmail.com>
 <CANCZdfpsXnbaQJo54qw689-unmVb35114PrOuNXHrcyp2Cng5g@mail.gmail.com>
 <CAC20D2MuABFQw_R2HyUFsg8Dpum+LNn6ixneO2C7Te8ECtZ3PA@mail.gmail.com>
 <20190911181101.GF3143@mcvoy.com>
 <alpine.BSF.2.21.9999.1909120846160.18105@aneurin.horsfall.org>
 <20190912034346.GJ2046@mcvoy.com>
 <a0231faa-8ad9-fa51-4b24-9854beb21210@gmail.com>
 <20190912043308.GL2046@mcvoy.com>
 <alpine.BSF.2.21.9999.1909131514360.18105@aneurin.horsfall.org>
Message-ID: <20190913055019.B92151570CE9@mail.bitblocks.com>

On Fri, 13 Sep 2019 15:22:58 +1000 Dave Horsfall <dave at horsfall.org> wrote:
> On Wed, 11 Sep 2019, Larry McVoy wrote:
>
> > Yeah, this was one of things that BitKeeper addressed.  It was easier to 
> > use and every commit was a tag.
>
> That reminds me: I really must take another look at BK for my stuff.
>
> At the moment I'm using say "fred.c-" for the previous version etc (and 
> "fred.c+" for something finished but not quite ready to install).
>
> I've also renamed entire directory trees to sub-tree under "OLD" etc :-)
>
> SCCS/RCS are history as far as I'm concerned; I never quite got the hang 
> of CVS (which OpenLDAP uses); and I've heard all sorts of horror stories 
> about GIT to keep me away from it...

I used to know CVS quite well.  Then I switched to mercurial
(for my own projects).  Then to git.  git has its problems but
it has worked well enough.  With just a few commands you can
get a lot done with it.  If you rely on/ contribute to any
open source projects, you pretty much have to know it these
days.

From dave at horsfall.org  Fri Sep 13 15:54:32 2019
From: dave at horsfall.org (Dave Horsfall)
Date: Fri, 13 Sep 2019 15:54:32 +1000 (EST)
Subject: [TUHS] [SPAM] Re:  SCCS
In-Reply-To: <20190913041117.GR2046@mcvoy.com>
References: <CANCZdfpEu6OxvmhDGSa3Cw4TSpfcbBOFbJjU7nZU-C_JFGFdRA@mail.gmail.com>
 <CAC20D2Pz+gwyeuVYcHFbJaimHtrt+sKSvCFp=hMZNoAWr4G09Q@mail.gmail.com>
 <CANCZdfpsXnbaQJo54qw689-unmVb35114PrOuNXHrcyp2Cng5g@mail.gmail.com>
 <CAC20D2MuABFQw_R2HyUFsg8Dpum+LNn6ixneO2C7Te8ECtZ3PA@mail.gmail.com>
 <20190911181101.GF3143@mcvoy.com>
 <alpine.BSF.2.21.9999.1909120846160.18105@aneurin.horsfall.org>
 <20190912034346.GJ2046@mcvoy.com>
 <CAKr6gn39D_XrOHXr22EUsEWhCUcFJw2n6C8iQ_ntXGkbO33irw@mail.gmail.com>
 <20190912043145.GA12480@mcvoy.com>
 <alpine.DEB.2.20.1909121417040.5352@grey.csi.cam.ac.uk>
 <20190913041117.GR2046@mcvoy.com>
Message-ID: <alpine.BSF.2.21.9999.1909131551110.18105@aneurin.horsfall.org>

On Thu, 12 Sep 2019, Larry McVoy wrote:

> But here is an SCCS win.  SCCS has a 16 bit ignore the carry bit 
> checksum over the whole file.  RCS has none of that.

Giggle...  I found I could actually *edit* an SCCS file, provided I reset 
the checksum to zero (it was then recalculated).

> B) NFS errors.  So all NFS implementations, Suns included, had a bad 
> habit of returning a block of nulls.  I dunno why but that is a thing. 
> The SCCS checksum would detect that.  RCS and CVS did not have a 
> checksum so when NFS returned garbage, they were happy to return that to 
> you.

I believe that NFS is much more reliable now (yes, it used to be awful).

-- Dave

From arnold at skeeve.com  Fri Sep 13 17:06:50 2019
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Fri, 13 Sep 2019 01:06:50 -0600
Subject: [TUHS] IBM Unix source licenses
In-Reply-To: <20190912232909.GA15734@minnie.tuhs.org>
References: <CANCZdfpEu6OxvmhDGSa3Cw4TSpfcbBOFbJjU7nZU-C_JFGFdRA@mail.gmail.com>
 <CAC20D2Pz+gwyeuVYcHFbJaimHtrt+sKSvCFp=hMZNoAWr4G09Q@mail.gmail.com>
 <CANCZdfpsXnbaQJo54qw689-unmVb35114PrOuNXHrcyp2Cng5g@mail.gmail.com>
 <CAC20D2MuABFQw_R2HyUFsg8Dpum+LNn6ixneO2C7Te8ECtZ3PA@mail.gmail.com>
 <c704d50c-dc9b-c703-a18c-86c411ae5d3f@technologists.com>
 <CAK7dMtDKRe99jY4iN8zkHo=evMYDOrmF8X1zLAf+sRxR3d7CmQ@mail.gmail.com>
 <CAC20D2MnW8yr+D-L7hV5XYNtVAmjT9z5vY41CCYYuxUvVJ51Sw@mail.gmail.com>
 <m27e6d2llv.fsf@irreal.org> <20190912232909.GA15734@minnie.tuhs.org>
Message-ID: <201909130706.x8D76o74010750@freefriends.org>

Warren Toomey <wkt at tuhs.org> wrote:

> Clem Cole <clemc at ccc.com> writes:
> > 
> > > FYI: the original S/1 port was done at Cleveland State with the Seventh
> > > Edition - the name of the Prof that led it I can not say I remember nor
> > > his
> > > HW configuration...
>  
> On Thu, Sep 12, 2019 at 06:30:52PM -0400, jcs wrote:
> > http://delivery.acm.org/10.1145/360000/358504/p1066-jalics.pdf
>
> Also available at:
> https://zero.sci-hub.se/3252/016657c71a46a2d7110d87b4f720847e/jalics1983.pdf
>
> 	Warren

Awesome, thanks for the link. I'd heard about that port (we had a
few Series/1s at GT, but not much was done with them) but didn't know
much about it otherwise.

Arnold

From peter at rulingia.com  Fri Sep 13 18:00:09 2019
From: peter at rulingia.com (Peter Jeremy)
Date: Fri, 13 Sep 2019 18:00:09 +1000
Subject: [TUHS] [SPAM] Re:  SCCS
In-Reply-To: <alpine.BSF.2.21.9999.1909131551110.18105@aneurin.horsfall.org>
References: <CANCZdfpsXnbaQJo54qw689-unmVb35114PrOuNXHrcyp2Cng5g@mail.gmail.com>
 <CAC20D2MuABFQw_R2HyUFsg8Dpum+LNn6ixneO2C7Te8ECtZ3PA@mail.gmail.com>
 <20190911181101.GF3143@mcvoy.com>
 <alpine.BSF.2.21.9999.1909120846160.18105@aneurin.horsfall.org>
 <20190912034346.GJ2046@mcvoy.com>
 <CAKr6gn39D_XrOHXr22EUsEWhCUcFJw2n6C8iQ_ntXGkbO33irw@mail.gmail.com>
 <20190912043145.GA12480@mcvoy.com>
 <alpine.DEB.2.20.1909121417040.5352@grey.csi.cam.ac.uk>
 <20190913041117.GR2046@mcvoy.com>
 <alpine.BSF.2.21.9999.1909131551110.18105@aneurin.horsfall.org>
Message-ID: <20190913080009.GG88690@server.rulingia.com>

On 2019-Sep-13 15:54:32 +1000, Dave Horsfall <dave at horsfall.org> wrote:
>On Thu, 12 Sep 2019, Larry McVoy wrote:
>> But here is an SCCS win.  SCCS has a 16 bit ignore the carry bit 
>> checksum over the whole file.  RCS has none of that.
>
>Giggle...  I found I could actually *edit* an SCCS file, provided I reset 
>the checksum to zero (it was then recalculated).

I think that was deliberate.  ISTR editing SCCS files and repairing the
checksum as well, though I don't recally exactly how.

>> B) NFS errors.  So all NFS implementations, Suns included, had a bad 
>> habit of returning a block of nulls.  I dunno why but that is a thing. 
>> The SCCS checksum would detect that.  RCS and CVS did not have a 
>> checksum so when NFS returned garbage, they were happy to return that to 
>> you.
>
>I believe that NFS is much more reliable now (yes, it used to be awful).

NFS ran much faster when you turned off the UDP checksums as well.
(Though there was still the Ethernet CRC32).

-- 
Peter Jeremy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190913/a5e03bd7/attachment.sig>

From spedraja at gmail.com  Fri Sep 13 18:30:17 2019
From: spedraja at gmail.com (SPC)
Date: Fri, 13 Sep 2019 10:30:17 +0200
Subject: [TUHS] IBM Unix source licenses
In-Reply-To: <20190912232909.GA15734@minnie.tuhs.org>
References: <CANCZdfpEu6OxvmhDGSa3Cw4TSpfcbBOFbJjU7nZU-C_JFGFdRA@mail.gmail.com>
 <CAC20D2Pz+gwyeuVYcHFbJaimHtrt+sKSvCFp=hMZNoAWr4G09Q@mail.gmail.com>
 <CANCZdfpsXnbaQJo54qw689-unmVb35114PrOuNXHrcyp2Cng5g@mail.gmail.com>
 <CAC20D2MuABFQw_R2HyUFsg8Dpum+LNn6ixneO2C7Te8ECtZ3PA@mail.gmail.com>
 <c704d50c-dc9b-c703-a18c-86c411ae5d3f@technologists.com>
 <CAK7dMtDKRe99jY4iN8zkHo=evMYDOrmF8X1zLAf+sRxR3d7CmQ@mail.gmail.com>
 <CAC20D2MnW8yr+D-L7hV5XYNtVAmjT9z5vY41CCYYuxUvVJ51Sw@mail.gmail.com>
 <m27e6d2llv.fsf@irreal.org> <20190912232909.GA15734@minnie.tuhs.org>
Message-ID: <CACytpF80owxCFjj7DvL1wR0DkTwEvH=fZB-pa_V=prERBg0XxA@mail.gmail.com>

El vie., 13 sept. 2019 a las 1:29, Warren Toomey (<wkt at tuhs.org>) escribió:

> Clem Cole <clemc at ccc.com> writes:
> >
> > > FYI: the original S/1 port was done at Cleveland State with the Seventh
> > > Edition
>

Very interesting. We got one Series/1 in our work involved in one
electronic speech project which sadly died soon.

On the other hand... Was this other portability project succesfully
finished? The Jalics paper don't make it all clear.

 Also available at:

>
> https://zero.sci-hub.se/3252/016657c71a46a2d7110d87b4f720847e/jalics1983.pdf
>
>         Warren
>

Gracias | Regards - Saludos | Greetings | Freundliche Grüße | Salutations
-- 
*Sergio Pedraja*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190913/453a06ab/attachment.html>

From emu at e-bbes.com  Fri Sep 13 18:12:39 2019
From: emu at e-bbes.com (emanuel stiebler)
Date: Fri, 13 Sep 2019 10:12:39 +0200
Subject: [TUHS] SCCS
In-Reply-To: <CAC20D2OZpnma4EX+PqgqfA7zNM7sofuDQ4zCURnLF7-G4TCKhQ@mail.gmail.com>
References: <CANCZdfpEu6OxvmhDGSa3Cw4TSpfcbBOFbJjU7nZU-C_JFGFdRA@mail.gmail.com>
 <CAC20D2Pz+gwyeuVYcHFbJaimHtrt+sKSvCFp=hMZNoAWr4G09Q@mail.gmail.com>
 <CANCZdfpsXnbaQJo54qw689-unmVb35114PrOuNXHrcyp2Cng5g@mail.gmail.com>
 <CAC20D2MuABFQw_R2HyUFsg8Dpum+LNn6ixneO2C7Te8ECtZ3PA@mail.gmail.com>
 <20190911181101.GF3143@mcvoy.com>
 <alpine.BSF.2.21.9999.1909120846160.18105@aneurin.horsfall.org>
 <20190912034346.GJ2046@mcvoy.com>
 <a0231faa-8ad9-fa51-4b24-9854beb21210@gmail.com>
 <1457a2d6-2f17-482d-e4f7-ace439d34ca8@neophilic.com>
 <CAC20D2OZpnma4EX+PqgqfA7zNM7sofuDQ4zCURnLF7-G4TCKhQ@mail.gmail.com>
Message-ID: <8db2e89c-ce50-a453-e38a-ecdfe69a746c@e-bbes.com>

On 2019-09-12 19:29, Clem Cole wrote:
> 
> 
> On Thu, Sep 12, 2019 at 1:16 PM Eric Allman <tuhs at eric.allman.name
> <mailto:tuhs at eric.allman.name>> wrote:
> 
>      At thispoint I'm using git because, well, all the cool kids are
>     doing it, and
>     since I work at the university I have to go with the flow sometimes.
>     And git has some nice properties.  On the other hand, I have shot myself
>     in the foot with git more times than the sum of all other screwups with
>     all other source management systems combined.
> 
>     eric
> 
> +1 

I have this one on the waqll in the office:
https://xkcd.com/1597/

From g.branden.robinson at gmail.com  Fri Sep 13 19:03:01 2019
From: g.branden.robinson at gmail.com (Branden Robinson)
Date: Fri, 13 Sep 2019 19:03:01 +1000
Subject: [TUHS] My EuroBSDcon talk (preview for commentary)
In-Reply-To: <CANCZdfrK4iFQCWOFP4MoUggpfJVmoJ0dnSg6H0cCi4dop7sVXw@mail.gmail.com>
References: <CANCZdfrK4iFQCWOFP4MoUggpfJVmoJ0dnSg6H0cCi4dop7sVXw@mail.gmail.com>
Message-ID: <CAN4uE+rxqMFZt4w8-QfQ7Vg58ynUYiXTM02-mOZ+aL-cT0fJsQ@mail.gmail.com>

Hi Warner,

Just a few minor corrections.

1. slide 21: s/Murrey Hill/Murray Hill/
2. slide 18: s/IOCC/&C/
3. slide 28: s/strippe down/stripped down/; s/IOCC/&C/

Now I know why the domain name is ioccc.org and not iocc.org.  Well-crafted
obfuscated C is nothing if not...unorthodox.

I hadn't even heard of VENIX before--great archeology!  As you lusted for
that OS back in the '80s, I lusted after the Rainbow 100 itself, and found
it cool for the same reasons you did.  The flexibility of the system was
appealing, keeping a bridge to my Z80 origins and the x86 juggernaut.  As
it happened I wound up with a 6809 machine running OS/9, and got Unix-like
exposure without even knowing it (the text editor, T/S Edit, was a vi
clone, and the "word processor", T/S Word, a *roff clone).  And best of
all, that machine taught me how to store multibyte integers correctly.

x86's worst-ever implementation of memory segmentation put me off of
assembly programming for years.  When I finally saw sensible segmentation
combined with hardware memory protection, the universe made sense again.

You have a wealth of great material here and I think you will surprise some
people.

Regards,
Branden

On Fri, Sep 13, 2019 at 1:21 PM Warner Losh <imp at bsdimp.com> wrote:

> OK. I've shared my slides for the talk.
>
> Some of the family trees are simplified (V7 doesn't have room for all its
> ports, for example)
> Some of it is a little cheeseball since I'm also trying to be witty and
> entertaining (we'll see how that goes).
> Please don't share them around until after my talk on the September 20th
>
> I'd like feedback on the bits I got wrong. Or left out. Or if you're in
> this and don't want to be, etc.
>
> All the slides after the Questions slide won't be presented and will
> likely be deleted.
>
>
> https://docs.google.com/presentation/d/177KxOif5oHARyIdZHDq-OO67_GVtMkzIAlDX-cHxgb4/edit?usp=sharing
>
> Please be kind (but if it sucks, please do tell). I've turned on
> commenting on the slides. Probably best if you comment there.
>
> I have a video of me giving this talk, but it's too rough to share...
>
> Thanks for any help you can give me.
>
> Warner
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190913/5a683974/attachment.html>

From lm at mcvoy.com  Sat Sep 14 01:23:45 2019
From: lm at mcvoy.com (Larry McVoy)
Date: Fri, 13 Sep 2019 08:23:45 -0700
Subject: [TUHS] [SPAM] Re:  SCCS
In-Reply-To: <20190913080009.GG88690@server.rulingia.com>
References: <CAC20D2MuABFQw_R2HyUFsg8Dpum+LNn6ixneO2C7Te8ECtZ3PA@mail.gmail.com>
 <20190911181101.GF3143@mcvoy.com>
 <alpine.BSF.2.21.9999.1909120846160.18105@aneurin.horsfall.org>
 <20190912034346.GJ2046@mcvoy.com>
 <CAKr6gn39D_XrOHXr22EUsEWhCUcFJw2n6C8iQ_ntXGkbO33irw@mail.gmail.com>
 <20190912043145.GA12480@mcvoy.com>
 <alpine.DEB.2.20.1909121417040.5352@grey.csi.cam.ac.uk>
 <20190913041117.GR2046@mcvoy.com>
 <alpine.BSF.2.21.9999.1909131551110.18105@aneurin.horsfall.org>
 <20190913080009.GG88690@server.rulingia.com>
Message-ID: <20190913152344.GW2046@mcvoy.com>

On Fri, Sep 13, 2019 at 06:00:09PM +1000, Peter Jeremy wrote:
> On 2019-Sep-13 15:54:32 +1000, Dave Horsfall <dave at horsfall.org> wrote:
> >On Thu, 12 Sep 2019, Larry McVoy wrote:
> >> But here is an SCCS win.  SCCS has a 16 bit ignore the carry bit 
> >> checksum over the whole file.  RCS has none of that.
> >
> >Giggle...  I found I could actually *edit* an SCCS file, provided I reset 
> >the checksum to zero (it was then recalculated).
> 
> I think that was deliberate.  ISTR editing SCCS files and repairing the
> checksum as well, though I don't recally exactly how.

bk admin -z file.c

and I'm pretty sure that is sccs compat.

> >> B) NFS errors.  So all NFS implementations, Suns included, had a bad 
> >> habit of returning a block of nulls.  I dunno why but that is a thing. 
> >> The SCCS checksum would detect that.  RCS and CVS did not have a 
> >> checksum so when NFS returned garbage, they were happy to return that to 
> >> you.
> >
> >I believe that NFS is much more reliable now (yes, it used to be awful).
> 
> NFS ran much faster when you turned off the UDP checksums as well.
> (Though there was still the Ethernet CRC32).

Living dangerously.

From clemc at ccc.com  Sat Sep 14 05:47:08 2019
From: clemc at ccc.com (Clem Cole)
Date: Fri, 13 Sep 2019 15:47:08 -0400
Subject: [TUHS] My EuroBSDcon talk (preview for commentary)
In-Reply-To: <CANCZdfrK4iFQCWOFP4MoUggpfJVmoJ0dnSg6H0cCi4dop7sVXw@mail.gmail.com>
References: <CANCZdfrK4iFQCWOFP4MoUggpfJVmoJ0dnSg6H0cCi4dop7sVXw@mail.gmail.com>
Message-ID: <CAC20D2NmXGzN7imTKy-RRWRZ2ewWMEmUV9oDuP3-e3a4R+ynpA@mail.gmail.com>

slide 4 --  All of HP-UX, Ultrix and Digital UNIX/Tru64 are BSD kernels.
HP-UP and Tru64 support System V calls.

BTW:  DG-UX and Stratus built their own kernels, but used System V command
systems and System Call definitions - which are not listed.

Slide 6 - if you want it I have another picture of the GE system from some
of their literature has a view of all of the components.   Send me email if
you want it.

Slide 8 - Sets out to write version of Fortran came up with B.  Uses B to
write Assembler

Slide 9 - Wrong DEC logo.  Should be the Blue one.  The maroon version does
not show up until the 1990s with Bob Palmer (and has bad memories for some
of us).

Slide 17 - Ken write PDP-11 assembler on PDP-7 in B. , Dennis starts to
rewrite B compiler to output PDP-11 code.

Slide 18 - B begins to become different enough that Dennis starts to call
it nb [new B], eventually deviates enough to become new language

Slide 19 - 4th Edition release outside of the BTL.  Lou Katz becomes 'user
zero'

Slide 20 -- We need to get you the site and group name from Mash.  It was
not in Summit, it was not USG - but was in NJ.  I thought it was Homdel but
I that is purely speculation.
                  Also the role of Columbus team needs to be defined.   Ask
Mary Ann.

Slide 21 -- I'm not going to argue - but I would ask you to add a
disclaimer.   This is what you could reconstruct, but there is some
question of some of the arrows.   Heinz might be able to help, but as
Stienhart and I have said, its believed to be in LA; but no one has tracked
him down as he has been pursuing non-computer interests.

Slide 22 --4th Edition went to Katz that this is wrong, who sometimes reads
this mailing list.  If not, send me a note, I'll reintroduce you.  He might
be able to give you a data.  Check with Warren, my >>memory<< is that some
of userland is still in C although a lot assembler is still there.

Slide 23 -- ??widespread??   -- I'm not sure I would use that. Not even 100
sites yet.     Also there were not "commercial version" this was the first
"commercial license" -- big difference [contact me if you want
explanation].  IIRC fee was 15K per CPU.  Commercial redistribution doesn't
occur until after 7th is released and was a separate license.   I would
add, Mike Lesk's portable C library is starting to be used, but most C
program do their own I/O with read/write

          First real install man page and Dennis build tape installation
system.   Earlier version released as RK05 disk copies.
           Also numerous new peripherals. IIRC Support for the 11/40 starts
here, 4th & 5th needed a 45 class, and earlier used the 20 with the CSS MMU.

Slide 24 -- CMU uses it to teaches OS class.  makes student in class sign a
sub-license.

Slide 25 - missing the first USENIX tapes. which include Harvard and the
like.  Warren and I can probably help a little here.

Slide 26 - new licenses.  Commercial license fees change to 20K for 1st
CPU/5K for each CPU afterward.  CMU buys first commercial license to use
UNIX to make money [after Cole and Klein go on strike].  Case Western
follows suit 6month later.   AT&T agrees for the Universities that they
only had to declare one CPU as commercial and could intermix otherwise and
notifies all the universities that if they were using it for commercial
purposes, then needed a license.

AT&T creates first redistribution license.  Needed at least one $20K
commercial CPU and then $150k for the rights to redistribute.   Originally
$1K per binary CPU.

Slide 27 -- missing Purdue Dual Vax and CMU Mach

Slide 28 - APS had NH which was the model the DEC plate you show.   Maddog
has it now on his Jeep when aps moved to CA (he also has the NH Linux plate
but I don't remember the car -- you can ask him).   I have had the
Massachusetts UNIX plate since 1983 (it's on my model S of course).   ghg
has indiana from around the same time (I think on a pickup).  wnj had the
CA vmunix on his Ferrari, but I don't know if he still has it or what its
on.

Slide 29 - Look in HenrySpencer-TUHS.org -- you'll find tail but not head.

Slide 31 - Job Control can from Europe via MIT.  Jim Kulp wrote it.   Noel
and I can give you the story if you want it.  It was on the PDP-11 there.
 Joy modified csh and added it to 4.1

Slide 32 -- JC was not from UCB.   Joy got it from MIT   -- Dennis create
ENV and it was first distributed in V7.

Slide 33 -- No Bourne supported ENV in the new shell -- see me earlier
email for how all this went down or ask Steve yourself.

Slide 34 -- PCC was included, but the Ritchie Compiler (a.k.a. Typesetter
C) was the default compiler.  You are missing a step BTW -- typesetter C
was released between V6 and V7.   As is the first draft of the White Book.
The new compiler had stdio but targets V6.
Also mpx was part of DataKit support.

Slide 35 --   Not sure that is true.   I thought Microsoft's Xenix ships
before Venix.    Particularly since you made the comment about System III
The original 8086 Xenix was a pure V7 port, with a few additions Gordon
brought with him from Purdue (i.e. ghg hacks).

Slide 52/53/54/55 -- wrong logo (see above)










On Thu, Sep 12, 2019 at 11:21 PM Warner Losh <imp at bsdimp.com> wrote:

> OK. I've shared my slides for the talk.
>
> Some of the family trees are simplified (V7 doesn't have room for all its
> ports, for example)
> Some of it is a little cheeseball since I'm also trying to be witty and
> entertaining (we'll see how that goes).
> Please don't share them around until after my talk on the September 20th
>
> I'd like feedback on the bits I got wrong. Or left out. Or if you're in
> this and don't want to be, etc.
>
> All the slides after the Questions slide won't be presented and will
> likely be deleted.
>
>
> https://docs.google.com/presentation/d/177KxOif5oHARyIdZHDq-OO67_GVtMkzIAlDX-cHxgb4/edit?usp=sharing
>
> Please be kind (but if it sucks, please do tell). I've turned on
> commenting on the slides. Probably best if you comment there.
>
> I have a video of me giving this talk, but it's too rough to share...
>
> Thanks for any help you can give me.
>
> Warner
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190913/06a40e64/attachment.html>

From clemc at ccc.com  Sat Sep 14 06:02:30 2019
From: clemc at ccc.com (Clem Cole)
Date: Fri, 13 Sep 2019 16:02:30 -0400
Subject: [TUHS] My EuroBSDcon talk (preview for commentary)
In-Reply-To: <CAC20D2NmXGzN7imTKy-RRWRZ2ewWMEmUV9oDuP3-e3a4R+ynpA@mail.gmail.com>
References: <CANCZdfrK4iFQCWOFP4MoUggpfJVmoJ0dnSg6H0cCi4dop7sVXw@mail.gmail.com>
 <CAC20D2NmXGzN7imTKy-RRWRZ2ewWMEmUV9oDuP3-e3a4R+ynpA@mail.gmail.com>
Message-ID: <CAC20D2PXYWpv-8BQNKvUjgT=2W81GgzaOLyZiQ5=sM9+LXCWnw@mail.gmail.com>

BTW:  I just thought of something else....  one of the b*tched about the
commercial redistribution license from V7 in 1979, that was not fixed until
the SVR3 licensing the mid-late 1980s  was AT&T's source policy.   As I
said, a commercial source license was $20K for the first CPU and 5K for
each additional one.   Later (System V) it went to $50K for the first and
$10K for each additional.   But what really ticked off the vendors like
DEC, Masscomp, Sun et al, was that each system that sources on was supposed
to one of the 'second CPU licenses' - the binary license was not good
enough.

What most of us did, was make sure any system that was a 'source control'
or 'master' system at any 'site' had a full source license, but we were all
in violation of the source agreement on our personal workstations.  The
argument was the sources on people's machines was ephemeral and not
'stored' there.   But it was definitely contentious.



On Fri, Sep 13, 2019 at 3:47 PM Clem Cole <clemc at ccc.com> wrote:

> slide 4 --  All of HP-UX, Ultrix and Digital UNIX/Tru64 are BSD kernels.
> HP-UP and Tru64 support System V calls.
>
> BTW:  DG-UX and Stratus built their own kernels, but used System V command
> systems and System Call definitions - which are not listed.
>
> Slide 6 - if you want it I have another picture of the GE system from some
> of their literature has a view of all of the components.   Send me email if
> you want it.
>
> Slide 8 - Sets out to write version of Fortran came up with B.  Uses B to
> write Assembler
>
> Slide 9 - Wrong DEC logo.  Should be the Blue one.  The maroon version
> does not show up until the 1990s with Bob Palmer (and has bad memories for
> some of us).
>
> Slide 17 - Ken write PDP-11 assembler on PDP-7 in B. , Dennis starts to
> rewrite B compiler to output PDP-11 code.
>
> Slide 18 - B begins to become different enough that Dennis starts to call
> it nb [new B], eventually deviates enough to become new language
>
> Slide 19 - 4th Edition release outside of the BTL.  Lou Katz becomes 'user
> zero'
>
> Slide 20 -- We need to get you the site and group name from Mash.  It was
> not in Summit, it was not USG - but was in NJ.  I thought it was Homdel but
> I that is purely speculation.
>                   Also the role of Columbus team needs to be defined.
>  Ask Mary Ann.
>
> Slide 21 -- I'm not going to argue - but I would ask you to add a
> disclaimer.   This is what you could reconstruct, but there is some
> question of some of the arrows.   Heinz might be able to help, but as
> Stienhart and I have said, its believed to be in LA; but no one has tracked
> him down as he has been pursuing non-computer interests.
>
> Slide 22 --4th Edition went to Katz that this is wrong, who sometimes
> reads this mailing list.  If not, send me a note, I'll reintroduce you.  He
> might be able to give you a data.  Check with Warren, my >>memory<< is that
> some of userland is still in C although a lot assembler is still there.
>
> Slide 23 -- ??widespread??   -- I'm not sure I would use that. Not even
> 100 sites yet.     Also there were not "commercial version" this was the
> first "commercial license" -- big difference [contact me if you want
> explanation].  IIRC fee was 15K per CPU.  Commercial redistribution doesn't
> occur until after 7th is released and was a separate license.   I would
> add, Mike Lesk's portable C library is starting to be used, but most C
> program do their own I/O with read/write
>
>           First real install man page and Dennis build tape installation
> system.   Earlier version released as RK05 disk copies.
>            Also numerous new peripherals. IIRC Support for the 11/40
> starts here, 4th & 5th needed a 45 class, and earlier used the 20 with the
> CSS MMU.
>
> Slide 24 -- CMU uses it to teaches OS class.  makes student in class sign
> a sub-license.
>
> Slide 25 - missing the first USENIX tapes. which include Harvard and the
> like.  Warren and I can probably help a little here.
>
> Slide 26 - new licenses.  Commercial license fees change to 20K for 1st
> CPU/5K for each CPU afterward.  CMU buys first commercial license to use
> UNIX to make money [after Cole and Klein go on strike].  Case Western
> follows suit 6month later.   AT&T agrees for the Universities that they
> only had to declare one CPU as commercial and could intermix otherwise and
> notifies all the universities that if they were using it for commercial
> purposes, then needed a license.
>
> AT&T creates first redistribution license.  Needed at least one $20K
> commercial CPU and then $150k for the rights to redistribute.   Originally
> $1K per binary CPU.
>
> Slide 27 -- missing Purdue Dual Vax and CMU Mach
>
> Slide 28 - APS had NH which was the model the DEC plate you show.   Maddog
> has it now on his Jeep when aps moved to CA (he also has the NH Linux plate
> but I don't remember the car -- you can ask him).   I have had the
> Massachusetts UNIX plate since 1983 (it's on my model S of course).   ghg
> has indiana from around the same time (I think on a pickup).  wnj had the
> CA vmunix on his Ferrari, but I don't know if he still has it or what its
> on.
>
> Slide 29 - Look in HenrySpencer-TUHS.org -- you'll find tail but not head.
>
> Slide 31 - Job Control can from Europe via MIT.  Jim Kulp wrote it.   Noel
> and I can give you the story if you want it.  It was on the PDP-11 there.
>  Joy modified csh and added it to 4.1
>
> Slide 32 -- JC was not from UCB.   Joy got it from MIT   -- Dennis create
> ENV and it was first distributed in V7.
>
> Slide 33 -- No Bourne supported ENV in the new shell -- see me earlier
> email for how all this went down or ask Steve yourself.
>
> Slide 34 -- PCC was included, but the Ritchie Compiler (a.k.a. Typesetter
> C) was the default compiler.  You are missing a step BTW -- typesetter C
> was released between V6 and V7.   As is the first draft of the White Book.
> The new compiler had stdio but targets V6.
> Also mpx was part of DataKit support.
>
> Slide 35 --   Not sure that is true.   I thought Microsoft's Xenix ships
> before Venix.    Particularly since you made the comment about System III
> The original 8086 Xenix was a pure V7 port, with a few additions Gordon
> brought with him from Purdue (i.e. ghg hacks).
>
> Slide 52/53/54/55 -- wrong logo (see above)
>
>
>
>
>
>
>
>
>
>
> On Thu, Sep 12, 2019 at 11:21 PM Warner Losh <imp at bsdimp.com> wrote:
>
>> OK. I've shared my slides for the talk.
>>
>> Some of the family trees are simplified (V7 doesn't have room for all its
>> ports, for example)
>> Some of it is a little cheeseball since I'm also trying to be witty and
>> entertaining (we'll see how that goes).
>> Please don't share them around until after my talk on the September 20th
>>
>> I'd like feedback on the bits I got wrong. Or left out. Or if you're in
>> this and don't want to be, etc.
>>
>> All the slides after the Questions slide won't be presented and will
>> likely be deleted.
>>
>>
>> https://docs.google.com/presentation/d/177KxOif5oHARyIdZHDq-OO67_GVtMkzIAlDX-cHxgb4/edit?usp=sharing
>>
>> Please be kind (but if it sucks, please do tell). I've turned on
>> commenting on the slides. Probably best if you comment there.
>>
>> I have a video of me giving this talk, but it's too rough to share...
>>
>> Thanks for any help you can give me.
>>
>> Warner
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190913/2242bf45/attachment-0001.html>

From lm at mcvoy.com  Sat Sep 14 06:06:59 2019
From: lm at mcvoy.com (Larry McVoy)
Date: Fri, 13 Sep 2019 13:06:59 -0700
Subject: [TUHS] My EuroBSDcon talk (preview for commentary)
In-Reply-To: <CAC20D2PXYWpv-8BQNKvUjgT=2W81GgzaOLyZiQ5=sM9+LXCWnw@mail.gmail.com>
References: <CANCZdfrK4iFQCWOFP4MoUggpfJVmoJ0dnSg6H0cCi4dop7sVXw@mail.gmail.com>
 <CAC20D2NmXGzN7imTKy-RRWRZ2ewWMEmUV9oDuP3-e3a4R+ynpA@mail.gmail.com>
 <CAC20D2PXYWpv-8BQNKvUjgT=2W81GgzaOLyZiQ5=sM9+LXCWnw@mail.gmail.com>
Message-ID: <20190913200659.GB2046@mcvoy.com>

Sun had all their sources on one machine.  Spent many a happy hour there
reading.

On Fri, Sep 13, 2019 at 04:02:30PM -0400, Clem Cole wrote:
> BTW:  I just thought of something else....  one of the b*tched about the
> commercial redistribution license from V7 in 1979, that was not fixed until
> the SVR3 licensing the mid-late 1980s  was AT&T's source policy.   As I
> said, a commercial source license was $20K for the first CPU and 5K for
> each additional one.   Later (System V) it went to $50K for the first and
> $10K for each additional.   But what really ticked off the vendors like
> DEC, Masscomp, Sun et al, was that each system that sources on was supposed
> to one of the 'second CPU licenses' - the binary license was not good
> enough.
> 
> What most of us did, was make sure any system that was a 'source control'
> or 'master' system at any 'site' had a full source license, but we were all
> in violation of the source agreement on our personal workstations.  The
> argument was the sources on people's machines was ephemeral and not
> 'stored' there.   But it was definitely contentious.
> 
> 
> 
> On Fri, Sep 13, 2019 at 3:47 PM Clem Cole <clemc at ccc.com> wrote:
> 
> > slide 4 --  All of HP-UX, Ultrix and Digital UNIX/Tru64 are BSD kernels.
> > HP-UP and Tru64 support System V calls.
> >
> > BTW:  DG-UX and Stratus built their own kernels, but used System V command
> > systems and System Call definitions - which are not listed.
> >
> > Slide 6 - if you want it I have another picture of the GE system from some
> > of their literature has a view of all of the components.   Send me email if
> > you want it.
> >
> > Slide 8 - Sets out to write version of Fortran came up with B.  Uses B to
> > write Assembler
> >
> > Slide 9 - Wrong DEC logo.  Should be the Blue one.  The maroon version
> > does not show up until the 1990s with Bob Palmer (and has bad memories for
> > some of us).
> >
> > Slide 17 - Ken write PDP-11 assembler on PDP-7 in B. , Dennis starts to
> > rewrite B compiler to output PDP-11 code.
> >
> > Slide 18 - B begins to become different enough that Dennis starts to call
> > it nb [new B], eventually deviates enough to become new language
> >
> > Slide 19 - 4th Edition release outside of the BTL.  Lou Katz becomes 'user
> > zero'
> >
> > Slide 20 -- We need to get you the site and group name from Mash.  It was
> > not in Summit, it was not USG - but was in NJ.  I thought it was Homdel but
> > I that is purely speculation.
> >                   Also the role of Columbus team needs to be defined.
> >  Ask Mary Ann.
> >
> > Slide 21 -- I'm not going to argue - but I would ask you to add a
> > disclaimer.   This is what you could reconstruct, but there is some
> > question of some of the arrows.   Heinz might be able to help, but as
> > Stienhart and I have said, its believed to be in LA; but no one has tracked
> > him down as he has been pursuing non-computer interests.
> >
> > Slide 22 --4th Edition went to Katz that this is wrong, who sometimes
> > reads this mailing list.  If not, send me a note, I'll reintroduce you.  He
> > might be able to give you a data.  Check with Warren, my >>memory<< is that
> > some of userland is still in C although a lot assembler is still there.
> >
> > Slide 23 -- ??widespread??   -- I'm not sure I would use that. Not even
> > 100 sites yet.     Also there were not "commercial version" this was the
> > first "commercial license" -- big difference [contact me if you want
> > explanation].  IIRC fee was 15K per CPU.  Commercial redistribution doesn't
> > occur until after 7th is released and was a separate license.   I would
> > add, Mike Lesk's portable C library is starting to be used, but most C
> > program do their own I/O with read/write
> >
> >           First real install man page and Dennis build tape installation
> > system.   Earlier version released as RK05 disk copies.
> >            Also numerous new peripherals. IIRC Support for the 11/40
> > starts here, 4th & 5th needed a 45 class, and earlier used the 20 with the
> > CSS MMU.
> >
> > Slide 24 -- CMU uses it to teaches OS class.  makes student in class sign
> > a sub-license.
> >
> > Slide 25 - missing the first USENIX tapes. which include Harvard and the
> > like.  Warren and I can probably help a little here.
> >
> > Slide 26 - new licenses.  Commercial license fees change to 20K for 1st
> > CPU/5K for each CPU afterward.  CMU buys first commercial license to use
> > UNIX to make money [after Cole and Klein go on strike].  Case Western
> > follows suit 6month later.   AT&T agrees for the Universities that they
> > only had to declare one CPU as commercial and could intermix otherwise and
> > notifies all the universities that if they were using it for commercial
> > purposes, then needed a license.
> >
> > AT&T creates first redistribution license.  Needed at least one $20K
> > commercial CPU and then $150k for the rights to redistribute.   Originally
> > $1K per binary CPU.
> >
> > Slide 27 -- missing Purdue Dual Vax and CMU Mach
> >
> > Slide 28 - APS had NH which was the model the DEC plate you show.   Maddog
> > has it now on his Jeep when aps moved to CA (he also has the NH Linux plate
> > but I don't remember the car -- you can ask him).   I have had the
> > Massachusetts UNIX plate since 1983 (it's on my model S of course).   ghg
> > has indiana from around the same time (I think on a pickup).  wnj had the
> > CA vmunix on his Ferrari, but I don't know if he still has it or what its
> > on.
> >
> > Slide 29 - Look in HenrySpencer-TUHS.org -- you'll find tail but not head.
> >
> > Slide 31 - Job Control can from Europe via MIT.  Jim Kulp wrote it.   Noel
> > and I can give you the story if you want it.  It was on the PDP-11 there.
> >  Joy modified csh and added it to 4.1
> >
> > Slide 32 -- JC was not from UCB.   Joy got it from MIT   -- Dennis create
> > ENV and it was first distributed in V7.
> >
> > Slide 33 -- No Bourne supported ENV in the new shell -- see me earlier
> > email for how all this went down or ask Steve yourself.
> >
> > Slide 34 -- PCC was included, but the Ritchie Compiler (a.k.a. Typesetter
> > C) was the default compiler.  You are missing a step BTW -- typesetter C
> > was released between V6 and V7.   As is the first draft of the White Book.
> > The new compiler had stdio but targets V6.
> > Also mpx was part of DataKit support.
> >
> > Slide 35 --   Not sure that is true.   I thought Microsoft's Xenix ships
> > before Venix.    Particularly since you made the comment about System III
> > The original 8086 Xenix was a pure V7 port, with a few additions Gordon
> > brought with him from Purdue (i.e. ghg hacks).
> >
> > Slide 52/53/54/55 -- wrong logo (see above)
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > On Thu, Sep 12, 2019 at 11:21 PM Warner Losh <imp at bsdimp.com> wrote:
> >
> >> OK. I've shared my slides for the talk.
> >>
> >> Some of the family trees are simplified (V7 doesn't have room for all its
> >> ports, for example)
> >> Some of it is a little cheeseball since I'm also trying to be witty and
> >> entertaining (we'll see how that goes).
> >> Please don't share them around until after my talk on the September 20th
> >>
> >> I'd like feedback on the bits I got wrong. Or left out. Or if you're in
> >> this and don't want to be, etc.
> >>
> >> All the slides after the Questions slide won't be presented and will
> >> likely be deleted.
> >>
> >>
> >> https://docs.google.com/presentation/d/177KxOif5oHARyIdZHDq-OO67_GVtMkzIAlDX-cHxgb4/edit?usp=sharing
> >>
> >> Please be kind (but if it sucks, please do tell). I've turned on
> >> commenting on the slides. Probably best if you comment there.
> >>
> >> I have a video of me giving this talk, but it's too rough to share...
> >>
> >> Thanks for any help you can give me.
> >>
> >> Warner
> >>
> >

-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 

From clemc at ccc.com  Sat Sep 14 06:06:52 2019
From: clemc at ccc.com (Clem Cole)
Date: Fri, 13 Sep 2019 16:06:52 -0400
Subject: [TUHS] My EuroBSDcon talk (preview for commentary)
In-Reply-To: <CAC20D2PXYWpv-8BQNKvUjgT=2W81GgzaOLyZiQ5=sM9+LXCWnw@mail.gmail.com>
References: <CANCZdfrK4iFQCWOFP4MoUggpfJVmoJ0dnSg6H0cCi4dop7sVXw@mail.gmail.com>
 <CAC20D2NmXGzN7imTKy-RRWRZ2ewWMEmUV9oDuP3-e3a4R+ynpA@mail.gmail.com>
 <CAC20D2PXYWpv-8BQNKvUjgT=2W81GgzaOLyZiQ5=sM9+LXCWnw@mail.gmail.com>
Message-ID: <CAC20D2MDbmoeMZq1esbuQvOCU7to0dUWsFyx98UQDLE3-c4fOA@mail.gmail.com>

Another thought -- the first commercial licensee was Rand.   Hired some
former Harvard students who brought UNIX with them.   You probably need to
add things like Rand Ports (a.k.a. named pipes) which came from there.
Also Chesson and Co did the original ArpaNET NCP at University of Ill
with some help from the Rand folks.   That was done on a V6 system ~ 1978

You also need need Ken's famous V6 'patch' tape -- that 'leaked'


On Fri, Sep 13, 2019 at 4:02 PM Clem Cole <clemc at ccc.com> wrote:

> BTW:  I just thought of something else....  one of the b*tched about the
> commercial redistribution license from V7 in 1979, that was not fixed until
> the SVR3 licensing the mid-late 1980s  was AT&T's source policy.   As I
> said, a commercial source license was $20K for the first CPU and 5K for
> each additional one.   Later (System V) it went to $50K for the first and
> $10K for each additional.   But what really ticked off the vendors like
> DEC, Masscomp, Sun et al, was that each system that sources on was supposed
> to one of the 'second CPU licenses' - the binary license was not good
> enough.
>
> What most of us did, was make sure any system that was a 'source control'
> or 'master' system at any 'site' had a full source license, but we were all
> in violation of the source agreement on our personal workstations.  The
> argument was the sources on people's machines was ephemeral and not
> 'stored' there.   But it was definitely contentious.
>
>
>
> On Fri, Sep 13, 2019 at 3:47 PM Clem Cole <clemc at ccc.com> wrote:
>
>> slide 4 --  All of HP-UX, Ultrix and Digital UNIX/Tru64 are BSD kernels.
>> HP-UP and Tru64 support System V calls.
>>
>> BTW:  DG-UX and Stratus built their own kernels, but used System V
>> command systems and System Call definitions - which are not listed.
>>
>> Slide 6 - if you want it I have another picture of the GE system from
>> some of their literature has a view of all of the components.   Send me
>> email if you want it.
>>
>> Slide 8 - Sets out to write version of Fortran came up with B.  Uses B to
>> write Assembler
>>
>> Slide 9 - Wrong DEC logo.  Should be the Blue one.  The maroon version
>> does not show up until the 1990s with Bob Palmer (and has bad memories for
>> some of us).
>>
>> Slide 17 - Ken write PDP-11 assembler on PDP-7 in B. , Dennis starts to
>> rewrite B compiler to output PDP-11 code.
>>
>> Slide 18 - B begins to become different enough that Dennis starts to call
>> it nb [new B], eventually deviates enough to become new language
>>
>> Slide 19 - 4th Edition release outside of the BTL.  Lou Katz
>> becomes 'user zero'
>>
>> Slide 20 -- We need to get you the site and group name from Mash.  It was
>> not in Summit, it was not USG - but was in NJ.  I thought it was Homdel but
>> I that is purely speculation.
>>                   Also the role of Columbus team needs to be defined.
>>  Ask Mary Ann.
>>
>> Slide 21 -- I'm not going to argue - but I would ask you to add a
>> disclaimer.   This is what you could reconstruct, but there is some
>> question of some of the arrows.   Heinz might be able to help, but as
>> Stienhart and I have said, its believed to be in LA; but no one has tracked
>> him down as he has been pursuing non-computer interests.
>>
>> Slide 22 --4th Edition went to Katz that this is wrong, who sometimes
>> reads this mailing list.  If not, send me a note, I'll reintroduce you.  He
>> might be able to give you a data.  Check with Warren, my >>memory<< is that
>> some of userland is still in C although a lot assembler is still there.
>>
>> Slide 23 -- ??widespread??   -- I'm not sure I would use that. Not even
>> 100 sites yet.     Also there were not "commercial version" this was the
>> first "commercial license" -- big difference [contact me if you want
>> explanation].  IIRC fee was 15K per CPU.  Commercial redistribution doesn't
>> occur until after 7th is released and was a separate license.   I would
>> add, Mike Lesk's portable C library is starting to be used, but most C
>> program do their own I/O with read/write
>>
>>           First real install man page and Dennis build tape installation
>> system.   Earlier version released as RK05 disk copies.
>>            Also numerous new peripherals. IIRC Support for the 11/40
>> starts here, 4th & 5th needed a 45 class, and earlier used the 20 with the
>> CSS MMU.
>>
>> Slide 24 -- CMU uses it to teaches OS class.  makes student in class sign
>> a sub-license.
>>
>> Slide 25 - missing the first USENIX tapes. which include Harvard and the
>> like.  Warren and I can probably help a little here.
>>
>> Slide 26 - new licenses.  Commercial license fees change to 20K for 1st
>> CPU/5K for each CPU afterward.  CMU buys first commercial license to use
>> UNIX to make money [after Cole and Klein go on strike].  Case Western
>> follows suit 6month later.   AT&T agrees for the Universities that they
>> only had to declare one CPU as commercial and could intermix otherwise and
>> notifies all the universities that if they were using it for commercial
>> purposes, then needed a license.
>>
>> AT&T creates first redistribution license.  Needed at least one $20K
>> commercial CPU and then $150k for the rights to redistribute.   Originally
>> $1K per binary CPU.
>>
>> Slide 27 -- missing Purdue Dual Vax and CMU Mach
>>
>> Slide 28 - APS had NH which was the model the DEC plate you show.
>>  Maddog has it now on his Jeep when aps moved to CA (he also has the NH
>> Linux plate but I don't remember the car -- you can ask him).   I have had
>> the Massachusetts UNIX plate since 1983 (it's on my model S of course).
>>  ghg has indiana from around the same time (I think on a pickup).  wnj had
>> the CA vmunix on his Ferrari, but I don't know if he still has it or what
>> its on.
>>
>> Slide 29 - Look in HenrySpencer-TUHS.org -- you'll find tail but not head.
>>
>> Slide 31 - Job Control can from Europe via MIT.  Jim Kulp wrote it.
>>  Noel and I can give you the story if you want it.  It was on the PDP-11
>> there.   Joy modified csh and added it to 4.1
>>
>> Slide 32 -- JC was not from UCB.   Joy got it from MIT   -- Dennis create
>> ENV and it was first distributed in V7.
>>
>> Slide 33 -- No Bourne supported ENV in the new shell -- see me earlier
>> email for how all this went down or ask Steve yourself.
>>
>> Slide 34 -- PCC was included, but the Ritchie Compiler (a.k.a. Typesetter
>> C) was the default compiler.  You are missing a step BTW -- typesetter C
>> was released between V6 and V7.   As is the first draft of the White Book.
>> The new compiler had stdio but targets V6.
>> Also mpx was part of DataKit support.
>>
>> Slide 35 --   Not sure that is true.   I thought Microsoft's Xenix ships
>> before Venix.    Particularly since you made the comment about System III
>> The original 8086 Xenix was a pure V7 port, with a few additions Gordon
>> brought with him from Purdue (i.e. ghg hacks).
>>
>> Slide 52/53/54/55 -- wrong logo (see above)
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Thu, Sep 12, 2019 at 11:21 PM Warner Losh <imp at bsdimp.com> wrote:
>>
>>> OK. I've shared my slides for the talk.
>>>
>>> Some of the family trees are simplified (V7 doesn't have room for all
>>> its ports, for example)
>>> Some of it is a little cheeseball since I'm also trying to be witty and
>>> entertaining (we'll see how that goes).
>>> Please don't share them around until after my talk on the September 20th
>>>
>>> I'd like feedback on the bits I got wrong. Or left out. Or if you're in
>>> this and don't want to be, etc.
>>>
>>> All the slides after the Questions slide won't be presented and will
>>> likely be deleted.
>>>
>>>
>>> https://docs.google.com/presentation/d/177KxOif5oHARyIdZHDq-OO67_GVtMkzIAlDX-cHxgb4/edit?usp=sharing
>>>
>>> Please be kind (but if it sucks, please do tell). I've turned on
>>> commenting on the slides. Probably best if you comment there.
>>>
>>> I have a video of me giving this talk, but it's too rough to share...
>>>
>>> Thanks for any help you can give me.
>>>
>>> Warner
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190913/0c987303/attachment.html>

From jon at fourwinds.com  Sat Sep 14 06:24:37 2019
From: jon at fourwinds.com (Jon Steinhart)
Date: Fri, 13 Sep 2019 13:24:37 -0700
Subject: [TUHS] My EuroBSDcon talk (preview for commentary)
In-Reply-To: <CAC20D2MDbmoeMZq1esbuQvOCU7to0dUWsFyx98UQDLE3-c4fOA@mail.gmail.com>
References: <CANCZdfrK4iFQCWOFP4MoUggpfJVmoJ0dnSg6H0cCi4dop7sVXw@mail.gmail.com>
 <CAC20D2NmXGzN7imTKy-RRWRZ2ewWMEmUV9oDuP3-e3a4R+ynpA@mail.gmail.com>
 <CAC20D2PXYWpv-8BQNKvUjgT=2W81GgzaOLyZiQ5=sM9+LXCWnw@mail.gmail.com>
 <CAC20D2MDbmoeMZq1esbuQvOCU7to0dUWsFyx98UQDLE3-c4fOA@mail.gmail.com>
Message-ID: <201909132024.x8DKObEP013266@darkstar.fourwinds.com>

Not sure about the last bullet on slide 18.  I think that it would be more
correct to say "format" instead of "typeset" since I don't think that the
C/A/T came out until 1972.  I guess it all comes down to whether or not you
consider nroff on an ASR-37 to be typesetting.

Jon

From clemc at ccc.com  Sat Sep 14 06:43:42 2019
From: clemc at ccc.com (Clem Cole)
Date: Fri, 13 Sep 2019 16:43:42 -0400
Subject: [TUHS] My EuroBSDcon talk (preview for commentary)
In-Reply-To: <201909132024.x8DKObEP013266@darkstar.fourwinds.com>
References: <CANCZdfrK4iFQCWOFP4MoUggpfJVmoJ0dnSg6H0cCi4dop7sVXw@mail.gmail.com>
 <CAC20D2NmXGzN7imTKy-RRWRZ2ewWMEmUV9oDuP3-e3a4R+ynpA@mail.gmail.com>
 <CAC20D2PXYWpv-8BQNKvUjgT=2W81GgzaOLyZiQ5=sM9+LXCWnw@mail.gmail.com>
 <CAC20D2MDbmoeMZq1esbuQvOCU7to0dUWsFyx98UQDLE3-c4fOA@mail.gmail.com>
 <201909132024.x8DKObEP013266@darkstar.fourwinds.com>
Message-ID: <CAC20D2PvA26HMoABOcLMoS9Lu8=L3Wtx_8yK83K+vbhoMZt-hQ@mail.gmail.com>

Jon - Good catch and that is a good reminder.
Warner - You need to add troff and the C/A/T to your timeline.  They were
too important.   What I don't remember, although Doug or Steve might, was
the original troff 4th or 5th edition?  bwk did ditroff, later with the
addition of the APS5.

FWIW: It was for 6th edition and post 1BSD that Tom Ferin did the original
vcat(1) work at UCSF's PDP-11.   It would get spread later to the world as
part of one of the BSDs, but the original emulation of a C/A/T4 with a
plotter support came from Tom, his graphics lab and the earlier work with
the Hershey fonts that CMU and Stanford had done to support the XGP for the
PDP-10s.  But that was super important for why people wanted UNIX early on.


On Fri, Sep 13, 2019 at 4:24 PM Jon Steinhart <jon at fourwinds.com> wrote:

> Not sure about the last bullet on slide 18.  I think that it would be more
> correct to say "format" instead of "typeset" since I don't think that the
> C/A/T came out until 1972.  I guess it all comes down to whether or not you
> consider nroff on an ASR-37 to be typesetting.
>
> Jon
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190913/552a639a/attachment.html>

From dds at aueb.gr  Sat Sep 14 06:53:05 2019
From: dds at aueb.gr (Diomidis Spinellis)
Date: Fri, 13 Sep 2019 23:53:05 +0300
Subject: [TUHS] My EuroBSDcon talk (preview for commentary)
In-Reply-To: <CAC20D2PvA26HMoABOcLMoS9Lu8=L3Wtx_8yK83K+vbhoMZt-hQ@mail.gmail.com>
References: <CANCZdfrK4iFQCWOFP4MoUggpfJVmoJ0dnSg6H0cCi4dop7sVXw@mail.gmail.com>
 <CAC20D2NmXGzN7imTKy-RRWRZ2ewWMEmUV9oDuP3-e3a4R+ynpA@mail.gmail.com>
 <CAC20D2PXYWpv-8BQNKvUjgT=2W81GgzaOLyZiQ5=sM9+LXCWnw@mail.gmail.com>
 <CAC20D2MDbmoeMZq1esbuQvOCU7to0dUWsFyx98UQDLE3-c4fOA@mail.gmail.com>
 <201909132024.x8DKObEP013266@darkstar.fourwinds.com>
 <CAC20D2PvA26HMoABOcLMoS9Lu8=L3Wtx_8yK83K+vbhoMZt-hQ@mail.gmail.com>
Message-ID: <463d5cc4-9bef-9ac3-a680-a5161d664dc1@aueb.gr>

The Fourth Edition manual was typeset in troff:
https://dspinellis.github.io/unix-v4man/v4man.pdf
https://github.com/dspinellis/unix-v4man

The Third Edition was nroff:
https://dspinellis.github.io/unix-v3man/v3man.pdf
https://github.com/dspinellis/unix-v3man

On 13-Sep-19 23:43, Clem Cole wrote:
> Jon - Good catch and that is a good reminder.
> Warner - You need to add troff and the C/A/T to your timeline.  They 
> were too important.   What I don't remember, although Doug or Steve 
> might, was the original troff 4th or 5th edition?  bwk did 
> ditroff, later with the addition of the APS5.

From steffen at sdaoden.eu  Sat Sep 14 07:11:04 2019
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Fri, 13 Sep 2019 23:11:04 +0200
Subject: [TUHS] SCCS
In-Reply-To: <8db2e89c-ce50-a453-e38a-ecdfe69a746c@e-bbes.com>
References: <CANCZdfpEu6OxvmhDGSa3Cw4TSpfcbBOFbJjU7nZU-C_JFGFdRA@mail.gmail.com>
 <CAC20D2Pz+gwyeuVYcHFbJaimHtrt+sKSvCFp=hMZNoAWr4G09Q@mail.gmail.com>
 <CANCZdfpsXnbaQJo54qw689-unmVb35114PrOuNXHrcyp2Cng5g@mail.gmail.com>
 <CAC20D2MuABFQw_R2HyUFsg8Dpum+LNn6ixneO2C7Te8ECtZ3PA@mail.gmail.com>
 <20190911181101.GF3143@mcvoy.com>
 <alpine.BSF.2.21.9999.1909120846160.18105@aneurin.horsfall.org>
 <20190912034346.GJ2046@mcvoy.com>
 <a0231faa-8ad9-fa51-4b24-9854beb21210@gmail.com>
 <1457a2d6-2f17-482d-e4f7-ace439d34ca8@neophilic.com>
 <CAC20D2OZpnma4EX+PqgqfA7zNM7sofuDQ4zCURnLF7-G4TCKhQ@mail.gmail.com>
 <8db2e89c-ce50-a453-e38a-ecdfe69a746c@e-bbes.com>
Message-ID: <20190913211104.aMZXy%steffen@sdaoden.eu>

emanuel stiebler wrote in <8db2e89c-ce50-a453-e38a-ecdfe69a746c at e-bbes.com>:
 |On 2019-09-12 19:29, Clem Cole wrote:
 |> On Thu, Sep 12, 2019 at 1:16 PM Eric Allman <tuhs at eric.allman.name
 |> <mailto:tuhs at eric.allman.name>> wrote:
 |> 
 |>      At thispoint I'm using git because, well, all the cool kids are
 |>     doing it, and
 |>     since I work at the university I have to go with the flow sometimes.
 |>     And git has some nice properties.  On the other hand, I have \
 |>     shot myself
 |>     in the foot with git more times than the sum of all other screwups \
 |>     with
 |>     all other source management systems combined.
 |> 
 |>     eric
 |> 
 |> +1 
 |
 |I have this one on the waqll in the office:
 |https://xkcd.com/1597/

I for one am so happy to have git that i cannot tell you how much
that is.  I have used rcs, cvs, subversion, back to cvs,
mercurial over the years,, and for some small things also sccs.
All of it has been a pain here or there.  Yes, the weave.  Schily
wants to provide real changeset support for sccs (tagging is real
problem), i think.  No, stashing, simply commiting something
half-ready, amending, rebasing, and, very important, proper
garbage collection of thrown away or otherwise useless stuff,
i will never miss again.

The only bad aspects is the lack of an automatically expanded,
human readable version number that can be included in files, and
that you cannot simply checkout, say, one directory, but only the
entire repository.  Its capability to work with shallow
repositories has improved over the years, however.  Nonetheless,
i claim that for the maintainer of one or two ports/packages it is
much nicer to use cvs, and only check out what really is of
interest to you; than to checkout thousands of things that is.

A nice weekend from Germany i wish,

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

From lm at mcvoy.com  Sat Sep 14 07:17:51 2019
From: lm at mcvoy.com (Larry McVoy)
Date: Fri, 13 Sep 2019 14:17:51 -0700
Subject: [TUHS] SCCS
In-Reply-To: <20190913211104.aMZXy%steffen@sdaoden.eu>
References: <CANCZdfpsXnbaQJo54qw689-unmVb35114PrOuNXHrcyp2Cng5g@mail.gmail.com>
 <CAC20D2MuABFQw_R2HyUFsg8Dpum+LNn6ixneO2C7Te8ECtZ3PA@mail.gmail.com>
 <20190911181101.GF3143@mcvoy.com>
 <alpine.BSF.2.21.9999.1909120846160.18105@aneurin.horsfall.org>
 <20190912034346.GJ2046@mcvoy.com>
 <a0231faa-8ad9-fa51-4b24-9854beb21210@gmail.com>
 <1457a2d6-2f17-482d-e4f7-ace439d34ca8@neophilic.com>
 <CAC20D2OZpnma4EX+PqgqfA7zNM7sofuDQ4zCURnLF7-G4TCKhQ@mail.gmail.com>
 <8db2e89c-ce50-a453-e38a-ecdfe69a746c@e-bbes.com>
 <20190913211104.aMZXy%steffen@sdaoden.eu>
Message-ID: <20190913211751.GF2046@mcvoy.com>

On Fri, Sep 13, 2019 at 11:11:04PM +0200, Steffen Nurpmeso wrote:
> emanuel stiebler wrote in <8db2e89c-ce50-a453-e38a-ecdfe69a746c at e-bbes.com>:
>  |On 2019-09-12 19:29, Clem Cole wrote:
>  |> On Thu, Sep 12, 2019 at 1:16 PM Eric Allman <tuhs at eric.allman.name
>  |> <mailto:tuhs at eric.allman.name>> wrote:
>  |> 
>  |>     ??At thispoint I'm using git because, well, all the cool kids are
>  |>     doing it, and
>  |>     since I work at the university I have to go with the flow sometimes.
>  |>     And git has some nice properties.?? On the other hand, I have \
>  |>     shot myself
>  |>     in the foot with git more times than the sum of all other screwups \
>  |>     with
>  |>     all other source management systems combined.
>  |> 
>  |>     eric
>  |> 
>  |> +1??
>  |
>  |I have this one on the waqll in the office:
>  |https://xkcd.com/1597/
> 
> I for one am so happy to have git that i cannot tell you how much
> that is.  I have used rcs, cvs, subversion, back to cvs,
> mercurial over the years,, and for some small things also sccs.
> All of it has been a pain here or there.  Yes, the weave.  Schily
> wants to provide real changeset support for sccs (tagging is real
> problem), i think.  

I don't know why, BitKeeper does that and is open source under 
a liberal license (Apache v2).

From clemc at ccc.com  Sat Sep 14 07:31:17 2019
From: clemc at ccc.com (Clem Cole)
Date: Fri, 13 Sep 2019 17:31:17 -0400
Subject: [TUHS] My EuroBSDcon talk (preview for commentary)
In-Reply-To: <CAC20D2MDbmoeMZq1esbuQvOCU7to0dUWsFyx98UQDLE3-c4fOA@mail.gmail.com>
References: <CANCZdfrK4iFQCWOFP4MoUggpfJVmoJ0dnSg6H0cCi4dop7sVXw@mail.gmail.com>
 <CAC20D2NmXGzN7imTKy-RRWRZ2ewWMEmUV9oDuP3-e3a4R+ynpA@mail.gmail.com>
 <CAC20D2PXYWpv-8BQNKvUjgT=2W81GgzaOLyZiQ5=sM9+LXCWnw@mail.gmail.com>
 <CAC20D2MDbmoeMZq1esbuQvOCU7to0dUWsFyx98UQDLE3-c4fOA@mail.gmail.com>
Message-ID: <CAC20D2MKKm735_OR8GPnu_m0gdR4NEGNWin0qZkB0_C5ve_-+w@mail.gmail.com>

BTW: I just found my PWB 1.0 manual.   The date is May 1977, authors are T.
(Ted) Dolotta, R. (Dick) Haight and E. Piskorik
and it lists the site as 'Piscataway' as the site on the
acknowlegements page.

On Fri, Sep 13, 2019 at 4:06 PM Clem Cole <clemc at ccc.com> wrote:

> Another thought -- the first commercial licensee was Rand.   Hired some
> former Harvard students who brought UNIX with them.   You probably need to
> add things like Rand Ports (a.k.a. named pipes) which came from there.
> Also Chesson and Co did the original ArpaNET NCP at University of Ill
> with some help from the Rand folks.   That was done on a V6 system ~ 1978
>
> You also need need Ken's famous V6 'patch' tape -- that 'leaked'
>
>
> On Fri, Sep 13, 2019 at 4:02 PM Clem Cole <clemc at ccc.com> wrote:
>
>> BTW:  I just thought of something else....  one of the b*tched about the
>> commercial redistribution license from V7 in 1979, that was not fixed until
>> the SVR3 licensing the mid-late 1980s  was AT&T's source policy.   As I
>> said, a commercial source license was $20K for the first CPU and 5K for
>> each additional one.   Later (System V) it went to $50K for the first and
>> $10K for each additional.   But what really ticked off the vendors like
>> DEC, Masscomp, Sun et al, was that each system that sources on was supposed
>> to one of the 'second CPU licenses' - the binary license was not good
>> enough.
>>
>> What most of us did, was make sure any system that was a 'source control'
>> or 'master' system at any 'site' had a full source license, but we were all
>> in violation of the source agreement on our personal workstations.  The
>> argument was the sources on people's machines was ephemeral and not
>> 'stored' there.   But it was definitely contentious.
>>
>>
>>
>> On Fri, Sep 13, 2019 at 3:47 PM Clem Cole <clemc at ccc.com> wrote:
>>
>>> slide 4 --  All of HP-UX, Ultrix and Digital UNIX/Tru64 are BSD
>>> kernels.  HP-UP and Tru64 support System V calls.
>>>
>>> BTW:  DG-UX and Stratus built their own kernels, but used System V
>>> command systems and System Call definitions - which are not listed.
>>>
>>> Slide 6 - if you want it I have another picture of the GE system from
>>> some of their literature has a view of all of the components.   Send me
>>> email if you want it.
>>>
>>> Slide 8 - Sets out to write version of Fortran came up with B.  Uses B
>>> to write Assembler
>>>
>>> Slide 9 - Wrong DEC logo.  Should be the Blue one.  The maroon version
>>> does not show up until the 1990s with Bob Palmer (and has bad memories for
>>> some of us).
>>>
>>> Slide 17 - Ken write PDP-11 assembler on PDP-7 in B. , Dennis starts to
>>> rewrite B compiler to output PDP-11 code.
>>>
>>> Slide 18 - B begins to become different enough that Dennis starts to
>>> call it nb [new B], eventually deviates enough to become new language
>>>
>>> Slide 19 - 4th Edition release outside of the BTL.  Lou Katz
>>> becomes 'user zero'
>>>
>>> Slide 20 -- We need to get you the site and group name from Mash.  It
>>> was not in Summit, it was not USG - but was in NJ.  I thought it was Homdel
>>> but I that is purely speculation.
>>>                   Also the role of Columbus team needs to be defined.
>>>  Ask Mary Ann.
>>>
>>> Slide 21 -- I'm not going to argue - but I would ask you to add a
>>> disclaimer.   This is what you could reconstruct, but there is some
>>> question of some of the arrows.   Heinz might be able to help, but as
>>> Stienhart and I have said, its believed to be in LA; but no one has tracked
>>> him down as he has been pursuing non-computer interests.
>>>
>>> Slide 22 --4th Edition went to Katz that this is wrong, who sometimes
>>> reads this mailing list.  If not, send me a note, I'll reintroduce you.  He
>>> might be able to give you a data.  Check with Warren, my >>memory<< is that
>>> some of userland is still in C although a lot assembler is still there.
>>>
>>> Slide 23 -- ??widespread??   -- I'm not sure I would use that. Not even
>>> 100 sites yet.     Also there were not "commercial version" this was the
>>> first "commercial license" -- big difference [contact me if you want
>>> explanation].  IIRC fee was 15K per CPU.  Commercial redistribution doesn't
>>> occur until after 7th is released and was a separate license.   I would
>>> add, Mike Lesk's portable C library is starting to be used, but most C
>>> program do their own I/O with read/write
>>>
>>>           First real install man page and Dennis build tape installation
>>> system.   Earlier version released as RK05 disk copies.
>>>            Also numerous new peripherals. IIRC Support for the 11/40
>>> starts here, 4th & 5th needed a 45 class, and earlier used the 20 with the
>>> CSS MMU.
>>>
>>> Slide 24 -- CMU uses it to teaches OS class.  makes student in class
>>> sign a sub-license.
>>>
>>> Slide 25 - missing the first USENIX tapes. which include Harvard and the
>>> like.  Warren and I can probably help a little here.
>>>
>>> Slide 26 - new licenses.  Commercial license fees change to 20K for 1st
>>> CPU/5K for each CPU afterward.  CMU buys first commercial license to use
>>> UNIX to make money [after Cole and Klein go on strike].  Case Western
>>> follows suit 6month later.   AT&T agrees for the Universities that they
>>> only had to declare one CPU as commercial and could intermix otherwise and
>>> notifies all the universities that if they were using it for commercial
>>> purposes, then needed a license.
>>>
>>> AT&T creates first redistribution license.  Needed at least one $20K
>>> commercial CPU and then $150k for the rights to redistribute.   Originally
>>> $1K per binary CPU.
>>>
>>> Slide 27 -- missing Purdue Dual Vax and CMU Mach
>>>
>>> Slide 28 - APS had NH which was the model the DEC plate you show.
>>>  Maddog has it now on his Jeep when aps moved to CA (he also has the NH
>>> Linux plate but I don't remember the car -- you can ask him).   I have had
>>> the Massachusetts UNIX plate since 1983 (it's on my model S of course).
>>>  ghg has indiana from around the same time (I think on a pickup).  wnj had
>>> the CA vmunix on his Ferrari, but I don't know if he still has it or what
>>> its on.
>>>
>>> Slide 29 - Look in HenrySpencer-TUHS.org -- you'll find tail but not
>>> head.
>>>
>>> Slide 31 - Job Control can from Europe via MIT.  Jim Kulp wrote it.
>>>  Noel and I can give you the story if you want it.  It was on the PDP-11
>>> there.   Joy modified csh and added it to 4.1
>>>
>>> Slide 32 -- JC was not from UCB.   Joy got it from MIT   -- Dennis
>>> create ENV and it was first distributed in V7.
>>>
>>> Slide 33 -- No Bourne supported ENV in the new shell -- see me earlier
>>> email for how all this went down or ask Steve yourself.
>>>
>>> Slide 34 -- PCC was included, but the Ritchie Compiler (a.k.a.
>>> Typesetter C) was the default compiler.  You are missing a step BTW --
>>> typesetter C was released between V6 and V7.   As is the first draft of the
>>> White Book.  The new compiler had stdio but targets V6.
>>> Also mpx was part of DataKit support.
>>>
>>> Slide 35 --   Not sure that is true.   I thought Microsoft's Xenix ships
>>> before Venix.    Particularly since you made the comment about System III
>>> The original 8086 Xenix was a pure V7 port, with a few additions Gordon
>>> brought with him from Purdue (i.e. ghg hacks).
>>>
>>> Slide 52/53/54/55 -- wrong logo (see above)
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Thu, Sep 12, 2019 at 11:21 PM Warner Losh <imp at bsdimp.com> wrote:
>>>
>>>> OK. I've shared my slides for the talk.
>>>>
>>>> Some of the family trees are simplified (V7 doesn't have room for all
>>>> its ports, for example)
>>>> Some of it is a little cheeseball since I'm also trying to be witty and
>>>> entertaining (we'll see how that goes).
>>>> Please don't share them around until after my talk on the September 20th
>>>>
>>>> I'd like feedback on the bits I got wrong. Or left out. Or if you're in
>>>> this and don't want to be, etc.
>>>>
>>>> All the slides after the Questions slide won't be presented and will
>>>> likely be deleted.
>>>>
>>>>
>>>> https://docs.google.com/presentation/d/177KxOif5oHARyIdZHDq-OO67_GVtMkzIAlDX-cHxgb4/edit?usp=sharing
>>>>
>>>> Please be kind (but if it sucks, please do tell). I've turned on
>>>> commenting on the slides. Probably best if you comment there.
>>>>
>>>> I have a video of me giving this talk, but it's too rough to share...
>>>>
>>>> Thanks for any help you can give me.
>>>>
>>>> Warner
>>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190913/cb22bfee/attachment.html>

From dave at horsfall.org  Sat Sep 14 07:36:32 2019
From: dave at horsfall.org (Dave Horsfall)
Date: Sat, 14 Sep 2019 07:36:32 +1000 (EST)
Subject: [TUHS] [SPAM] Re:  SCCS
In-Reply-To: <20190913080009.GG88690@server.rulingia.com>
References: <CANCZdfpsXnbaQJo54qw689-unmVb35114PrOuNXHrcyp2Cng5g@mail.gmail.com>
 <CAC20D2MuABFQw_R2HyUFsg8Dpum+LNn6ixneO2C7Te8ECtZ3PA@mail.gmail.com>
 <20190911181101.GF3143@mcvoy.com>
 <alpine.BSF.2.21.9999.1909120846160.18105@aneurin.horsfall.org>
 <20190912034346.GJ2046@mcvoy.com>
 <CAKr6gn39D_XrOHXr22EUsEWhCUcFJw2n6C8iQ_ntXGkbO33irw@mail.gmail.com>
 <20190912043145.GA12480@mcvoy.com>
 <alpine.DEB.2.20.1909121417040.5352@grey.csi.cam.ac.uk>
 <20190913041117.GR2046@mcvoy.com>
 <alpine.BSF.2.21.9999.1909131551110.18105@aneurin.horsfall.org>
 <20190913080009.GG88690@server.rulingia.com>
Message-ID: <alpine.BSF.2.21.9999.1909140723340.18105@aneurin.horsfall.org>

On Fri, 13 Sep 2019, Peter Jeremy wrote:

>> Giggle...  I found I could actually *edit* an SCCS file, provided I reset
>> the checksum to zero (it was then recalculated).
>
> I think that was deliberate.  ISTR editing SCCS files and repairing the
> checksum as well, though I don't recally exactly how.

I don't recall why I had to edit the SCCS file (this was decades ago) but
it was just a plain ASCII file, with the checksum as a string of digits
up near the front somewhere.

It *may* be because I screwed up an update, and didn't want to own up to
it :-)  I don't recall whether SCCS allowed updates to be backed out.

>> I believe that NFS is much more reliable now (yes, it used to be awful).
>
> NFS ran much faster when you turned off the UDP checksums as well.
> (Though there was still the Ethernet CRC32).

Blerk...  That just tells you that the packet came across the wire more or
less OK.

-- Dave

From norman at oclsc.org  Sat Sep 14 07:37:12 2019
From: norman at oclsc.org (Norman Wilson)
Date: Fri, 13 Sep 2019 17:37:12 -0400
Subject: [TUHS] SCCS
Message-ID: <1568410636.21547.for-standards-violators@oclsc.org>

Well, if we're going to get into editor, erm, version-control wars,
I'll state my unpopular opinion that SCCS and RCS were no good at
all and CVS only pretended to be any good.  Subversion was the first
system I could stand using.

The actual basis for that opinion (and it's just my opinion but it's
not pulled out of hyperspace) is that the older systems think only
about one file at a time, not collections of files.  To me that's
useless for any but the most-trivial programming (and wasn't
non-trivial programming what spurred such systems?).  When I am
working on a non-trivial program, there's almost always more than
one source file, and to keep things clean often means refactoring:
splitting one file into several, merging different files, removing
files that contain no-longer-useful junk, adding files that
implement new things, renaming files.

A revision-control system that thinks only about one file at a
time can't keep track of those changes.  To me that makes it
worse than useless; not only can it not record a single
commit with a single message and version number when files
are split and combined, it requires extra work to keep all
those files under version control at all.

CVS makes an attempt to handle those things, but the effect
is clunky in practice compared to successors like svn.

One shouldn't underestimate the importance of a non-clunky
interface.  In retrospect it seems stupid that we didn't have
some sort of revision control discipline in Research UNIX, but
given the clunkiness of SCCS and RCS and CVS, there's no way
most of us would have put up with it.  Given that we often had
different people playing with the same program concurrently,
it would have taken at least CVS to meet our needs anyway.

Norman `recidivist' Wilson
Toronto ON

From clemc at ccc.com  Sat Sep 14 07:45:51 2019
From: clemc at ccc.com (Clem Cole)
Date: Fri, 13 Sep 2019 17:45:51 -0400
Subject: [TUHS] My EuroBSDcon talk (preview for commentary)
In-Reply-To: <463d5cc4-9bef-9ac3-a680-a5161d664dc1@aueb.gr>
References: <CANCZdfrK4iFQCWOFP4MoUggpfJVmoJ0dnSg6H0cCi4dop7sVXw@mail.gmail.com>
 <CAC20D2NmXGzN7imTKy-RRWRZ2ewWMEmUV9oDuP3-e3a4R+ynpA@mail.gmail.com>
 <CAC20D2PXYWpv-8BQNKvUjgT=2W81GgzaOLyZiQ5=sM9+LXCWnw@mail.gmail.com>
 <CAC20D2MDbmoeMZq1esbuQvOCU7to0dUWsFyx98UQDLE3-c4fOA@mail.gmail.com>
 <201909132024.x8DKObEP013266@darkstar.fourwinds.com>
 <CAC20D2PvA26HMoABOcLMoS9Lu8=L3Wtx_8yK83K+vbhoMZt-hQ@mail.gmail.com>
 <463d5cc4-9bef-9ac3-a680-a5161d664dc1@aueb.gr>
Message-ID: <CAC20D2Nz-ofwD41vULF2-TL8-C33heCiHvoNNbcuj6GGKhtKzQ@mail.gmail.com>

Awesome -- great way to figure it out, although I'm not sure 3rd edition
was nroff, I think it might have been roff.  I think a smart test is to
check to see if those sources used a macro package or not.  If not macro
package, I think that tells us that the likely formatting program was roff.

It does leave us an interesting question, when did the original roff(1)
show up and when did nroff(1).  The original, roff(1), was early, and of
course not until after the original PDP-11/20 port.  But was it as early as
first edition?   roff was the first formatting program.  nroff replaced it
later on, although roff lived through the 6th edition (I do not believe it
is on the v7 tape).

I was under the impression that the order is this ... roff was written for
either v1 or v2 in 1970 or 71; I thought originally by Ken to be similar to
the runoff that ran on the GE systems.   At some point the team recieved
the /C/A/T and Joseph Ossanna wrote a new program to support it,
*a.k.a. *troff,
that was similar to roff but troff was not a superset of the original
program.  nroff was then written after troff came into being to parrot the
behavior of troff using an ASR-37; but I do not know who was the author (it
might have been Ossanna).  But it was a third program, that used the same
macro packages as troff that started to appear for Ossanna's program and
the input language was changed so that a document author could know what
was the output target.

As I said, nroff and roff were in the v6 distribution, although not troff
if I remember it correctly; although troff was part of PWB 1.0.  The
inclusion of both roff and nroff was because some of the Unix
papers/documentation used roff for formatting, not the troff/nroff input
syntax. That said, the PWB man pages have the roff manpage, as well as a
single man page for both nroff and troff with sections later that say
'nroff only' and 'troff only.'

Also I do not remember having any macro packages for roff(1), but their
might have been some, although I just checked the PWB man page and it does
not list a .so command to read in macros, there is no mention of a macro
switch on the command line and in the files section the only external file
it used was the hyphenation tables.

Finally, Ossanna tragically died and some time later the new APS/5 was
obtained. So, bwk wrote a new program yet, that used post processors and
some front end tables, to allow the 'typesetter' portion to work regardless
of the output device (*i.e.* device independent troff or ditroff).   With
the idea only a single program would be needed to be supported.  By this
point nothing in the Research 'releases' required the original roff program
and since it was in assembler, I believe that it was dropped from all
further support.

Clem



On Fri, Sep 13, 2019 at 4:53 PM Diomidis Spinellis <dds at aueb.gr> wrote:

> The Fourth Edition manual was typeset in troff:
> https://dspinellis.github.io/unix-v4man/v4man.pdf
> https://github.com/dspinellis/unix-v4man
>
> The Third Edition was nroff:
> https://dspinellis.github.io/unix-v3man/v3man.pdf
> https://github.com/dspinellis/unix-v3man
>
> On 13-Sep-19 23:43, Clem Cole wrote:
> > Jon - Good catch and that is a good reminder.
> > Warner - You need to add troff and the C/A/T to your timeline.  They
> > were too important.   What I don't remember, although Doug or Steve
> > might, was the original troff 4th or 5th edition?  bwk did
> > ditroff, later with the addition of the APS5.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190913/aa91fcba/attachment-0001.html>

From bakul at bitblocks.com  Sat Sep 14 07:48:58 2019
From: bakul at bitblocks.com (Bakul Shah)
Date: Fri, 13 Sep 2019 14:48:58 -0700
Subject: [TUHS] SCCS
In-Reply-To: Your message of "Fri, 13 Sep 2019 14:17:51 -0700."
 <20190913211751.GF2046@mcvoy.com>
References: <CANCZdfpsXnbaQJo54qw689-unmVb35114PrOuNXHrcyp2Cng5g@mail.gmail.com>
 <CAC20D2MuABFQw_R2HyUFsg8Dpum+LNn6ixneO2C7Te8ECtZ3PA@mail.gmail.com>
 <20190911181101.GF3143@mcvoy.com>
 <alpine.BSF.2.21.9999.1909120846160.18105@aneurin.horsfall.org>
 <20190912034346.GJ2046@mcvoy.com>
 <a0231faa-8ad9-fa51-4b24-9854beb21210@gmail.com>
 <1457a2d6-2f17-482d-e4f7-ace439d34ca8@neophilic.com>
 <CAC20D2OZpnma4EX+PqgqfA7zNM7sofuDQ4zCURnLF7-G4TCKhQ@mail.gmail.com>
 <8db2e89c-ce50-a453-e38a-ecdfe69a746c@e-bbes.com>
 <20190913211104.aMZXy%steffen@sdaoden.eu> <20190913211751.GF2046@mcvoy.com>
Message-ID: <20190913214905.339ED1570CE9@mail.bitblocks.com>

On Fri, 13 Sep 2019 14:17:51 -0700 Larry McVoy <lm at mcvoy.com> wrote:
> On Fri, Sep 13, 2019 at 11:11:04PM +0200, Steffen Nurpmeso wrote:
> > 
> > I for one am so happy to have git that i cannot tell you how much
> > that is.  I have used rcs, cvs, subversion, back to cvs,
> > mercurial over the years,, and for some small things also sccs.
> > All of it has been a pain here or there.  Yes, the weave.  Schily
> > wants to provide real changeset support for sccs (tagging is real
> > problem), i think.  
>
> I don't know why, BitKeeper does that and is open source under 
> a liberal license (Apache v2).

This is because in git the "id" of a changeset is its sha1
checksum.  Given that, you can only reference it in a
subsequent changeset. This is a problem in that there is no
git built-in way to correlate a built binary with a particular
changeset id of its sources but you end up using your own
convention.  E.g.  set env. var VERSION or some such to the id
during the compile step but it is a bother.

From lm at mcvoy.com  Sat Sep 14 07:51:27 2019
From: lm at mcvoy.com (Larry McVoy)
Date: Fri, 13 Sep 2019 14:51:27 -0700
Subject: [TUHS] SCCS
In-Reply-To: <1568410636.21547.for-standards-violators@oclsc.org>
References: <1568410636.21547.for-standards-violators@oclsc.org>
Message-ID: <20190913215127.GG2046@mcvoy.com>

On Fri, Sep 13, 2019 at 05:37:12PM -0400, Norman Wilson wrote:
> The actual basis for that opinion (and it's just my opinion but it's
> not pulled out of hyperspace) is that the older systems think only
> about one file at a time, not collections of files.  

Yep.  That's the problem that BitKeeper solved first, correctly, with
atomic commits, full rename tracking, etc.  If you googled "changeset"
back in 1996 before BitKeeper started happening there were 6 hits
(mostly for a really weird system called Aide De Camp).

If you googled it 5 years later there were millions of hits, almost
100% BitKeeper related.

One of the selling points of BK back in the day was "remember when you
forgot to tag the tree in CVS and you couldn't get back to where you
wanted to be?  Yeah, every commit in BK is a tag, you can roll back
to anywhere."

So I agree with you Norm that exact problem was part of why BitKeeper
was invented.  When I was going on about SCCS, I was admiring the weave,
it's a neat way to do things.  But I wouldn't suggest anyone use just
SCCS today, that's nuts.

From wkt at tuhs.org  Sat Sep 14 08:13:45 2019
From: wkt at tuhs.org (Warren Toomey)
Date: Sat, 14 Sep 2019 08:13:45 +1000
Subject: [TUHS] earliest Unix roff
In-Reply-To: <CAC20D2Nz-ofwD41vULF2-TL8-C33heCiHvoNNbcuj6GGKhtKzQ@mail.gmail.com>
References: <CANCZdfrK4iFQCWOFP4MoUggpfJVmoJ0dnSg6H0cCi4dop7sVXw@mail.gmail.com>
 <CAC20D2NmXGzN7imTKy-RRWRZ2ewWMEmUV9oDuP3-e3a4R+ynpA@mail.gmail.com>
 <CAC20D2PXYWpv-8BQNKvUjgT=2W81GgzaOLyZiQ5=sM9+LXCWnw@mail.gmail.com>
 <CAC20D2MDbmoeMZq1esbuQvOCU7to0dUWsFyx98UQDLE3-c4fOA@mail.gmail.com>
 <201909132024.x8DKObEP013266@darkstar.fourwinds.com>
 <CAC20D2PvA26HMoABOcLMoS9Lu8=L3Wtx_8yK83K+vbhoMZt-hQ@mail.gmail.com>
 <463d5cc4-9bef-9ac3-a680-a5161d664dc1@aueb.gr>
 <CAC20D2Nz-ofwD41vULF2-TL8-C33heCiHvoNNbcuj6GGKhtKzQ@mail.gmail.com>
Message-ID: <20190913221345.GA16129@minnie.tuhs.org>

On Fri, Sep 13, 2019 at 05:45:51PM -0400, Clem Cole wrote:
>    It does leave us an interesting question, when did the original roff(1)
>    show up and when did nroff(1).  The original, roff(1), was early, and
>    of course not until after the original PDP-11/20 port.  But was it as
>    early as first edition?   roff was the first formatting program.  nroff
>    replaced it later on, although roff lived through the 6th edition (I do
>    not believe it is on the v7 tape).

There was a roff on PDP-7 Unix:

    By the spring of 1971, it was generally agreed that no one had the
    slightest interest in scrapping Unix. Therefore, we transliterated
    the roff text formatter into PDP-11 assembler language, starting from
    the PDP-7 version that had been transliterated from McIlroy’s BCPL
    version on Multics, which had in turn been inspired by J. Saltzer’s
    runoff program on CTSS.

>From "The Evolution of the Unix Time-sharing System"

http://www.read.seas.harvard.edu/~kohler/class/aosref/ritchie84evolution.pdf

Cheers, Warren

From norman at oclsc.org  Sat Sep 14 08:01:14 2019
From: norman at oclsc.org (Norman Wilson)
Date: Fri, 13 Sep 2019 18:01:14 -0400
Subject: [TUHS] [SPAM] Re:  SCCS
Message-ID: <1568412078.22454.for-standards-violators@oclsc.org>

Peter Jeremy:

> NFS ran much faster when you turned off the UDP checksums as well.
> (Though there was still the Ethernet CRC32).

Dave Horsfall:

  Blerk...  That just tells you that the packet came across the wire more or
  less OK.

=====

UDP (and TCP) checksums are nearly useless against
the sort of corruption Larry described.  Since they
are a simple addition with carry wraparound, you
can insert or remove any number of word-aligned pairs
of zero octets without the checksum changing.

I discovered this the hard way, while tracking down
a kernel bug that caused exactly that sort of corruption.

Does IPv6 require a meaningful checksum, or just the
useless old ritual one?

Norman Wilson
Toronto ON

From dave at horsfall.org  Sat Sep 14 08:30:42 2019
From: dave at horsfall.org (Dave Horsfall)
Date: Sat, 14 Sep 2019 08:30:42 +1000 (EST)
Subject: [TUHS] [SPAM] Re:  SCCS
In-Reply-To: <1568412078.22454.for-standards-violators@oclsc.org>
References: <1568412078.22454.for-standards-violators@oclsc.org>
Message-ID: <alpine.BSF.2.21.9999.1909140824240.18105@aneurin.horsfall.org>

On Fri, 13 Sep 2019, Norman Wilson wrote:

> UDP (and TCP) checksums are nearly useless against the sort of 
> corruption Larry described.  Since they are a simple addition with carry 
> wraparound, you can insert or remove any number of word-aligned pairs of 
> zero octets without the checksum changing.

I was thinking of an intermediate router (probably one that you never knew 
about) corrupting the checksum-less UDP packet, recalculating the Ethernet 
checksum, and your kernel happily accepting it; you now have an 
application that fails for some unknown reason.

Never seen it in practice, but I've heard of it happening.

-- Dave

From clemc at ccc.com  Sat Sep 14 08:55:24 2019
From: clemc at ccc.com (Clem Cole)
Date: Fri, 13 Sep 2019 18:55:24 -0400
Subject: [TUHS] earliest Unix roff
In-Reply-To: <20190913221345.GA16129@minnie.tuhs.org>
References: <CANCZdfrK4iFQCWOFP4MoUggpfJVmoJ0dnSg6H0cCi4dop7sVXw@mail.gmail.com>
 <CAC20D2NmXGzN7imTKy-RRWRZ2ewWMEmUV9oDuP3-e3a4R+ynpA@mail.gmail.com>
 <CAC20D2PXYWpv-8BQNKvUjgT=2W81GgzaOLyZiQ5=sM9+LXCWnw@mail.gmail.com>
 <CAC20D2MDbmoeMZq1esbuQvOCU7to0dUWsFyx98UQDLE3-c4fOA@mail.gmail.com>
 <201909132024.x8DKObEP013266@darkstar.fourwinds.com>
 <CAC20D2PvA26HMoABOcLMoS9Lu8=L3Wtx_8yK83K+vbhoMZt-hQ@mail.gmail.com>
 <463d5cc4-9bef-9ac3-a680-a5161d664dc1@aueb.gr>
 <CAC20D2Nz-ofwD41vULF2-TL8-C33heCiHvoNNbcuj6GGKhtKzQ@mail.gmail.com>
 <20190913221345.GA16129@minnie.tuhs.org>
Message-ID: <CAC20D2OQD-NJaFsqsLVL_kqmCsSeUOKAr7dm71P4uN9N8m+AbQ@mail.gmail.com>

Thanks.  So we have a date that explains the pdp-11 assembler version - it
was there at v1.

On Fri, Sep 13, 2019 at 6:14 PM Warren Toomey <wkt at tuhs.org> wrote:

> On Fri, Sep 13, 2019 at 05:45:51PM -0400, Clem Cole wrote:
> >    It does leave us an interesting question, when did the original
> roff(1)
> >    show up and when did nroff(1).  The original, roff(1), was early, and
> >    of course not until after the original PDP-11/20 port.  But was it as
> >    early as first edition?   roff was the first formatting program.
> nroff
> >    replaced it later on, although roff lived through the 6th edition (I
> do
> >    not believe it is on the v7 tape).
>
> There was a roff on PDP-7 Unix:
>
>     By the spring of 1971, it was generally agreed that no one had the
>     slightest interest in scrapping Unix. Therefore, we transliterated
>     the roff text formatter into PDP-11 assembler language, starting from
>     the PDP-7 version that had been transliterated from McIlroy’s BCPL
>     version on Multics, which had in turn been inspired by J. Saltzer’s
>     runoff program on CTSS.
>
> From "The Evolution of the Unix Time-sharing System"
>
>
> http://www.read.seas.harvard.edu/~kohler/class/aosref/ritchie84evolution.pdf
>
> Cheers, Warren
>
-- 
Sent from a handheld expect more typos than usual
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190913/073a652d/attachment.html>

From steffen at sdaoden.eu  Sat Sep 14 09:03:12 2019
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Sat, 14 Sep 2019 01:03:12 +0200
Subject: [TUHS] SCCS
In-Reply-To: <20190913211751.GF2046@mcvoy.com>
References: <CANCZdfpsXnbaQJo54qw689-unmVb35114PrOuNXHrcyp2Cng5g@mail.gmail.com>
 <CAC20D2MuABFQw_R2HyUFsg8Dpum+LNn6ixneO2C7Te8ECtZ3PA@mail.gmail.com>
 <20190911181101.GF3143@mcvoy.com>
 <alpine.BSF.2.21.9999.1909120846160.18105@aneurin.horsfall.org>
 <20190912034346.GJ2046@mcvoy.com>
 <a0231faa-8ad9-fa51-4b24-9854beb21210@gmail.com>
 <1457a2d6-2f17-482d-e4f7-ace439d34ca8@neophilic.com>
 <CAC20D2OZpnma4EX+PqgqfA7zNM7sofuDQ4zCURnLF7-G4TCKhQ@mail.gmail.com>
 <8db2e89c-ce50-a453-e38a-ecdfe69a746c@e-bbes.com>
 <20190913211104.aMZXy%steffen@sdaoden.eu> <20190913211751.GF2046@mcvoy.com>
Message-ID: <20190913230312.XaeCQ%steffen@sdaoden.eu>

Larry McVoy wrote in <20190913211751.GF2046 at mcvoy.com>:
 |On Fri, Sep 13, 2019 at 11:11:04PM +0200, Steffen Nurpmeso wrote:
 |> emanuel stiebler wrote in <8db2e89c-ce50-a453-e38a-ecdfe69a746c at e-bbes.c\
 |> om>:
 |>|On 2019-09-12 19:29, Clem Cole wrote:
 |>|> On Thu, Sep 12, 2019 at 1:16 PM Eric Allman <tuhs at eric.allman.name
 |>|> <mailto:tuhs at eric.allman.name>> wrote:
 |>|> 
 |>|>     ??At thispoint I'm using git because, well, all the cool kids are
 |>|>     doing it, and
 |>|>     since I work at the university I have to go with the flow sometimes\
 |>|>     .
 |>|>     And git has some nice properties.?? On the other hand, I have \
 |>|>     shot myself
 |>|>     in the foot with git more times than the sum of all other screwups \
 |>|>     \
 |>|>     with
 |>|>     all other source management systems combined.
 |>|> 
 |>|>     eric
 |>|> 
 |>|> +1??
 |>|
 |>|I have this one on the waqll in the office:
 |>|https://xkcd.com/1597/
 |> 
 |> I for one am so happy to have git that i cannot tell you how much
 |> that is.  I have used rcs, cvs, subversion, back to cvs,
 ...
 |> All of it has been a pain here or there.  Yes, the weave.  Schily
 |> wants to provide real changeset support for sccs (tagging is real
 |> problem), i think.  
 |
 |I don't know why, BitKeeper does that and is open source under 
 |a liberal license (Apache v2).

Diversity is something good i would say.  With the constraint that
it is real diversity, as nature produces, not as in modern times
where the supermarket has two dozen sorts of margarine, and in the
end it comes from Kraft or Nestle, which bought together
a sortiment, and that is basically it, which (i bore you) has to
result in save effects which dilutes recipes or ingredients.  (I
am the happy eater of Alsan-S, and are paying not getting paid for
it.  But that is ok.)  So in fact this diversity rather is
BitKeeper and Sun SCCS only.  Yet two hears are better than one,
sang Frank Sinatra.

He is as convinced from SCCS and its interleaved deltas as you
are, but he works on extending the plain original SCCS, which is
pretty smaller; his presentation from the "Chemnitzer Linux Tage
2012" (linux days of former Karl-Marx-Stadt) [1] talks about this
and also prominently mentions BitKeeper:

  . All modern distributed OSS version control systems base upon
    BitKeeper in the end.
  . BitKeeper bases upon the ideas of TeamWare.
  . TeamWare bases upon the ideas of NSE.
  . NSE is a frontend to SCCS.
  . Therewith all modern systems ultimately base upon SCCS.
  . Distributed operate TeamWare, BitKeeper, git, Mercurial.

This logic convinces me.  First, we take Manhattan, then we take
Berlin.  His SCCS is not a competitor to the BitKeeper suite, of
course.  But it roots in the original Sun code, just as Heirloom
SCCS.

  [1] http://sccs.sourceforge.net/SCCS-Chemnitz-2012.pdf

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

From steffen at sdaoden.eu  Sat Sep 14 09:12:21 2019
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Sat, 14 Sep 2019 01:12:21 +0200
Subject: [TUHS] SCCS
In-Reply-To: <20190913214905.339ED1570CE9@mail.bitblocks.com>
References: <CANCZdfpsXnbaQJo54qw689-unmVb35114PrOuNXHrcyp2Cng5g@mail.gmail.com>
 <CAC20D2MuABFQw_R2HyUFsg8Dpum+LNn6ixneO2C7Te8ECtZ3PA@mail.gmail.com>
 <20190911181101.GF3143@mcvoy.com>
 <alpine.BSF.2.21.9999.1909120846160.18105@aneurin.horsfall.org>
 <20190912034346.GJ2046@mcvoy.com>
 <a0231faa-8ad9-fa51-4b24-9854beb21210@gmail.com>
 <1457a2d6-2f17-482d-e4f7-ace439d34ca8@neophilic.com>
 <CAC20D2OZpnma4EX+PqgqfA7zNM7sofuDQ4zCURnLF7-G4TCKhQ@mail.gmail.com>
 <8db2e89c-ce50-a453-e38a-ecdfe69a746c@e-bbes.com>
 <20190913211104.aMZXy%steffen@sdaoden.eu> <20190913211751.GF2046@mcvoy.com>
 <20190913214905.339ED1570CE9@mail.bitblocks.com>
Message-ID: <20190913231221.-skm3%steffen@sdaoden.eu>

Bakul Shah wrote in <20190913214905.339ED1570CE9 at mail.bitblocks.com>:
 |On Fri, 13 Sep 2019 14:17:51 -0700 Larry McVoy <lm at mcvoy.com> wrote:
 |> On Fri, Sep 13, 2019 at 11:11:04PM +0200, Steffen Nurpmeso wrote:
 |>> 
 |>> I for one am so happy to have git that i cannot tell you how much
 |>> that is.  I have used rcs, cvs, subversion, back to cvs,
 |>> mercurial over the years,, and for some small things also sccs.
 |>> All of it has been a pain here or there.  Yes, the weave.  Schily
 |>> wants to provide real changeset support for sccs (tagging is real
 |>> problem), i think.  
 |>
 |> I don't know why, BitKeeper does that and is open source under 
 |> a liberal license (Apache v2).
 |
 |This is because in git the "id" of a changeset is its sha1
 |checksum.  Given that, you can only reference it in a
 |subsequent changeset. This is a problem in that there is no
 |git built-in way to correlate a built binary with a particular
 |changeset id of its sources but you end up using your own
 |convention.  E.g.  set env. var VERSION or some such to the id
 |during the compile step but it is a bother.

Linus Torvalds wrote an interesting message on that many years
ago, which someone pointed me at ditto.  Do not ask.  git cannot
generate human readable things by design, with branching and
merging, and due to the distributed nature.  I have a little (git
pre-commit) script which keeps my SCCS IDs alive for my web pages,
even after i converted them to git.  But i think for code bases
like NetBSD in particular this is a total show stopper (they
really keep the "original" file preamble alive, do they?), but it
also is for OpenBSD i think, and for FreeBSD i know that having
a human readible sequentially increasing version number was a main
reason to go for subversion.  Even though there seems to be
a growing number of people who want to switch to git, yes i think
Warner Losh just said something like "when we will have switched
to git, that will xy", this week?

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

From reed at reedmedia.net  Sat Sep 14 10:44:25 2019
From: reed at reedmedia.net (reed at reedmedia.net)
Date: Fri, 13 Sep 2019 19:44:25 -0500 (CDT)
Subject: [TUHS] a book (was Re:  PWB vs Unix/TS)
In-Reply-To: <CAC20D2Pz+gwyeuVYcHFbJaimHtrt+sKSvCFp=hMZNoAWr4G09Q@mail.gmail.com>
References: <CANCZdfpEu6OxvmhDGSa3Cw4TSpfcbBOFbJjU7nZU-C_JFGFdRA@mail.gmail.com>
 <CAC20D2Pz+gwyeuVYcHFbJaimHtrt+sKSvCFp=hMZNoAWr4G09Q@mail.gmail.com>
Message-ID: <alpine.NEB.2.21.1909101307530.11702@t1.m.reedmedia.net>

There needs to be a book with stuff like this. There is no Unix history 
book that I have ever seen with the depth of information in threads like 
this and others on TUHS.  It would be a huge project and hard to tell if 
there would me more than just recognition and intrinsic rewards for the 
effort -- but maybe that is enough.

(As an example, I have spent hundreds if not thousands of hours 
researching a small subset: Berkeley Unix history. Attempted to contact 
hundreds of historical participants. Interviewed near 100 people; most 
by email, but some in person or by phone -- even postal mail! Building a 
massive collection of historical data. Read over 30 physical books 
covering very small parts of the story. Watched many videos (and notes). 
Getting documents scanned and sent to me. It is a very detailed effort 
-- such as a single long chapter on the Virtual Vax/UNIX / London/Reiser 
/ Babaoglu story with 168 citations or the single chapters on the 
official unofficial patchkits, lawsuit, etc. -- and there is nothing in 
this field to compare it too. I have over 243 bibtex entries already and 
215 citations left to add to my .bib file. During that time, I have 
published six other books, some written from scratch. Some have 
suggested I use Kickstarter or similar as a financial incentive to 
finish it off.)

Since the Unix story is so huge, a first volume could be up through 
System III, for example, but maybe that is too much.

Anyone know of anyone writing a thorough Unix history book?

Does it make sense to use a kickstarter?

I may bring up in a different thread, but I am presenting about Unix 
history at Dallas Ft. Worth UNIX Users Group soon. They are planning to 
have two meetings (different months) dedicated to the history (50th 
anniversary).

Jeremy C. Reed

p.s. Sorry to mention this, but time is running out:

$ grep -i decease /home/reed/book/bsd-history/PEOPLE | wc -l 
      17

pps. My other chapters:

beginning.tex:\chapter{In the beginning ...}

2bsd.tex:\chapter{Second Berkeley Software Tape}

3bsd.tex:\chapter{Welcome to Virtual Vax/UNIX}

2bsd-part2.tex:\chapter{2BSD becomes an operating system}

4bsd.tex:\chapter{4BSD}

43bsd.tex:\chapter{4.3BSD -- The Internet Server}

2bsd-part3.tex:\chapter{The 16-bit 2BSD continues}

43bsd-part2.tex:\chapter{To open source BSD}

commercial.tex:\chapter{Commercial Unixes using BSD}

44bsd.tex:\chapter{4.4BSD}

bsdi.tex:\chapter{BSDI}

386bsd.tex:\chapter{386BSD Part 1}

lawsuit.tex:\chapter{Lawsuit}

patchkit.tex:\chapter{The official unofficial patchkits}

netbsd.tex:\chapter{NetBSD}

freebsd.tex:\chapter{FreeBSD}

386bsd-part3.tex:\chapter{386BSD Part 2}

bsdi-part2.tex:\chapter{BSDI part 2}

openbsd.tex:\chapter{OpenBSD}

netbsd-part2.tex:\chapter{NetBSD -- Part 2}

dragonfly.tex:\chapter{DragonFly BSD}

3bsd-license.tex:\chapter{3BSD Software Agreement (1979)}

4bsd-license.tex:\chapter{4BSD Software Agreement (1980)}



-----------------------

echo Ohl zl obbx uggc://errqzrqvn.arg/obbxf/csfrafr/ | \
 tr "Onoqrsuvxzabcefghl" "Babdefhikmnoprstuy"

From lm at mcvoy.com  Sat Sep 14 11:55:17 2019
From: lm at mcvoy.com (Larry McVoy)
Date: Fri, 13 Sep 2019 18:55:17 -0700
Subject: [TUHS] [SPAM] Re:  SCCS
In-Reply-To: <20190913230312.XaeCQ%steffen@sdaoden.eu>
References: <20190911181101.GF3143@mcvoy.com>
 <alpine.BSF.2.21.9999.1909120846160.18105@aneurin.horsfall.org>
 <20190912034346.GJ2046@mcvoy.com>
 <a0231faa-8ad9-fa51-4b24-9854beb21210@gmail.com>
 <1457a2d6-2f17-482d-e4f7-ace439d34ca8@neophilic.com>
 <CAC20D2OZpnma4EX+PqgqfA7zNM7sofuDQ4zCURnLF7-G4TCKhQ@mail.gmail.com>
 <8db2e89c-ce50-a453-e38a-ecdfe69a746c@e-bbes.com>
 <20190913211104.aMZXy%steffen@sdaoden.eu>
 <20190913211751.GF2046@mcvoy.com>
 <20190913230312.XaeCQ%steffen@sdaoden.eu>
Message-ID: <20190914015517.GD12480@mcvoy.com>

On Sat, Sep 14, 2019 at 01:03:12AM +0200, Steffen Nurpmeso wrote:
> He is as convinced from SCCS and its interleaved deltas as you
> are, but he works on extending the plain original SCCS, which is
> pretty smaller; his presentation from the "Chemnitzer Linux Tage
> 2012" (linux days of former Karl-Marx-Stadt) [1] talks about this
> and also prominently mentions BitKeeper:
> 
>   . All modern distributed OSS version control systems base upon
>     BitKeeper in the end.

Sort of.  Monotone, Darcs, and one other one I can't remember did not
draw from BitKeeper.  Mercurial, Git, and the Australian one that I
can't remember definitely do.

>   . BitKeeper bases upon the ideas of TeamWare.

Only in that I am the primary author of both.  It does support the idea
that SCCS is the basis for both, though Teamware used the real SCCS and
I rewrote SCCS from scratch and then extended it quite a bit.  BitKeeper's
SCCS tracks a lot more than SCCS does, pathnames, permissions, hostnames,
etc.

>   . TeamWare bases upon the ideas of NSE.

That's absolutely false.  TeamWare, which is the productized version
of NSElite, which I wrote all of, was a reaction to how absolute shiite
NSE was.  I had friends in the Sun kernel group that quit because they
were forced to use NSE.  It was awful.  I got into source management 
because I was well known at Sun as the guy that could fix performance
problems so I was asked to look at NSE.  One look told me that I couldn't
fix NSE but the source management problem space needed some help.

>   . NSE is a frontend to SCCS.

That's true.

>   . Therewith all modern systems ultimately base upon SCCS.

That is a big stretch, it's just not true.  I love the SCCS file 
format but to say all modern systems are based on SCCS is 100%
false.  BitKeeper is.  That's it.

>   . Distributed operate TeamWare, BitKeeper, git, Mercurial.

Git and Mercurial were going for append only data structures. 
That's not SCCS.

All this comes from Jorg, isn't he the guy who has a track record of
being on the outside of Sun and trying to argue with me about what Sun
was doing when I was a well known guy in the most important group at Sun,
the kernel group.  If so, I'd salt his stuff heavily.

I think he means well but is a little out there.  Though some people
might say the same about me.

--lm

From lm at mcvoy.com  Sat Sep 14 12:02:40 2019
From: lm at mcvoy.com (Larry McVoy)
Date: Fri, 13 Sep 2019 19:02:40 -0700
Subject: [TUHS] earliest Unix roff
In-Reply-To: <CAC20D2OQD-NJaFsqsLVL_kqmCsSeUOKAr7dm71P4uN9N8m+AbQ@mail.gmail.com>
References: <CANCZdfrK4iFQCWOFP4MoUggpfJVmoJ0dnSg6H0cCi4dop7sVXw@mail.gmail.com>
 <CAC20D2NmXGzN7imTKy-RRWRZ2ewWMEmUV9oDuP3-e3a4R+ynpA@mail.gmail.com>
 <CAC20D2PXYWpv-8BQNKvUjgT=2W81GgzaOLyZiQ5=sM9+LXCWnw@mail.gmail.com>
 <CAC20D2MDbmoeMZq1esbuQvOCU7to0dUWsFyx98UQDLE3-c4fOA@mail.gmail.com>
 <201909132024.x8DKObEP013266@darkstar.fourwinds.com>
 <CAC20D2PvA26HMoABOcLMoS9Lu8=L3Wtx_8yK83K+vbhoMZt-hQ@mail.gmail.com>
 <463d5cc4-9bef-9ac3-a680-a5161d664dc1@aueb.gr>
 <CAC20D2Nz-ofwD41vULF2-TL8-C33heCiHvoNNbcuj6GGKhtKzQ@mail.gmail.com>
 <20190913221345.GA16129@minnie.tuhs.org>
 <CAC20D2OQD-NJaFsqsLVL_kqmCsSeUOKAr7dm71P4uN9N8m+AbQ@mail.gmail.com>
Message-ID: <20190914020240.GO2046@mcvoy.com>

> >     slightest interest in scrapping Unix. Therefore, we transliterated
> >     the roff text formatter into PDP-11 assembler language, starting from
> >     the PDP-7 version that had been transliterated from McIlroy???s BCPL
> >     version on Multics, which had in turn been inspired by J. Saltzer???s
> >     runoff program on CTSS.

As a *roff guy to the core, to this day, I'd love to see any docs on the 
Multics version and/or the CTSS version.

Roff has some pretty sophisticated stuff (environments come to mind) that
I think 99.9% of the CS world doesn't understand (sort of like my rant
on SCCS, most people didn't look hard enough to get it.  I'm not sure
that I get roff environments to this day but I kinda do).

I'd love to see the docs on that early stuff and see if Joe Ossanna
added in his own magic or was he carrying forward earlier magic.

--lm

P.S.  I love this list for this stuff, I'm an old retired guy that 
wishes he could have helped birth Unix.  Hanging out with the people
who were there is super fun.

From wkt at tuhs.org  Sat Sep 14 12:44:33 2019
From: wkt at tuhs.org (Warren Toomey)
Date: Sat, 14 Sep 2019 12:44:33 +1000
Subject: [TUHS] earliest Unix roff
In-Reply-To: <20190914020240.GO2046@mcvoy.com>
References: <CAC20D2NmXGzN7imTKy-RRWRZ2ewWMEmUV9oDuP3-e3a4R+ynpA@mail.gmail.com>
 <CAC20D2PXYWpv-8BQNKvUjgT=2W81GgzaOLyZiQ5=sM9+LXCWnw@mail.gmail.com>
 <CAC20D2MDbmoeMZq1esbuQvOCU7to0dUWsFyx98UQDLE3-c4fOA@mail.gmail.com>
 <201909132024.x8DKObEP013266@darkstar.fourwinds.com>
 <CAC20D2PvA26HMoABOcLMoS9Lu8=L3Wtx_8yK83K+vbhoMZt-hQ@mail.gmail.com>
 <463d5cc4-9bef-9ac3-a680-a5161d664dc1@aueb.gr>
 <CAC20D2Nz-ofwD41vULF2-TL8-C33heCiHvoNNbcuj6GGKhtKzQ@mail.gmail.com>
 <20190913221345.GA16129@minnie.tuhs.org>
 <CAC20D2OQD-NJaFsqsLVL_kqmCsSeUOKAr7dm71P4uN9N8m+AbQ@mail.gmail.com>
 <20190914020240.GO2046@mcvoy.com>
Message-ID: <20190914024433.GA19193@minnie.tuhs.org>

On Fri, Sep 13, 2019 at 07:02:40PM -0700, Larry McVoy wrote:
> Roff has some pretty sophisticated stuff (environments come to mind) that
> I think 99.9% of the CS world doesn't understand (sort of like my rant
> on SCCS, most people didn't look hard enough to get it.  I'm not sure
> that I get roff environments to this day but I kinda do).
> 
> I'd love to see the docs on that early stuff and see if Joe Ossanna
> added in his own magic or was he carrying forward earlier magic.

Here's a good page on the history:
https://manpages.bsd.lv/history.html
 
> P.S.  I love this list for this stuff, I'm an old retired guy that 
> wishes he could have helped birth Unix.  Hanging out with the people
> who were there is super fun.

Hell yeah to both!

Cheers, Warren

From imp at bsdimp.com  Sat Sep 14 12:53:34 2019
From: imp at bsdimp.com (Warner Losh)
Date: Fri, 13 Sep 2019 20:53:34 -0600
Subject: [TUHS] a book (was Re: PWB vs Unix/TS)
In-Reply-To: <alpine.NEB.2.21.1909101307530.11702@t1.m.reedmedia.net>
References: <CANCZdfpEu6OxvmhDGSa3Cw4TSpfcbBOFbJjU7nZU-C_JFGFdRA@mail.gmail.com>
 <CAC20D2Pz+gwyeuVYcHFbJaimHtrt+sKSvCFp=hMZNoAWr4G09Q@mail.gmail.com>
 <alpine.NEB.2.21.1909101307530.11702@t1.m.reedmedia.net>
Message-ID: <CANCZdfpsE1GnaKknt0zcae5KyaWrS3gw1cCVgf_vjfKH-f0w4g@mail.gmail.com>

On Fri, Sep 13, 2019 at 7:31 PM <reed at reedmedia.net> wrote:

> There needs to be a book with stuff like this. There is no Unix history
> book that I have ever seen with the depth of information in threads like
> this and others on TUHS.  It would be a huge project and hard to tell if
> there would me more than just recognition and intrinsic rewards for the
> effort -- but maybe that is enough.
>

I think it would be cool, but we need better data visualization. There's a
lot of rich history here that people like me try to boil down to a few
ovals and arrows, but the real answer is much more complicated. We need the
equivalent to Mindard's analysis of Napoleon's march to Moscow and back to
show how things like awk entered, and where, and different 'sub editions'
and different lines of code maintained outside the overly simple narrative
of V1 -> V2 ... -> V7 -> 32V -> chaos. :)


> (As an example, I have spent hundreds if not thousands of hours
> researching a small subset: Berkeley Unix history. Attempted to contact
> hundreds of historical participants. Interviewed near 100 people; most
> by email, but some in person or by phone -- even postal mail! Building a
> massive collection of historical data. Read over 30 physical books
> covering very small parts of the story. Watched many videos (and notes).
> Getting documents scanned and sent to me. It is a very detailed effort
> -- such as a single long chapter on the Virtual Vax/UNIX / London/Reiser
> / Babaoglu story with 168 citations or the single chapters on the
> official unofficial patchkits, lawsuit, etc. -- and there is nothing in
> this field to compare it too. I have over 243 bibtex entries already and
> 215 citations left to add to my .bib file. During that time, I have
> published six other books, some written from scratch. Some have
> suggested I use Kickstarter or similar as a financial incentive to
> finish it off.)
>
> Since the Unix story is so huge, a first volume could be up through
> System III, for example, but maybe that is too much.
>
> Anyone know of anyone writing a thorough Unix history book?
>

I'd be keen to write up what I've found.


> Does it make sense to use a kickstarter?
>
> I may bring up in a different thread, but I am presenting about Unix
> history at Dallas Ft. Worth UNIX Users Group soon. They are planning to
> have two meetings (different months) dedicated to the history (50th
> anniversary).
>

If they are large enough, I could be persuaded to reprise my EuroBSDcon
talk at them, assuming people are happy with how it turns out....

Warner


> Jeremy C. Reed
>
> p.s. Sorry to mention this, but time is running out:
>
> $ grep -i decease /home/reed/book/bsd-history/PEOPLE | wc -l
>       17
>
> pps. My other chapters:
>
> beginning.tex:\chapter{In the beginning ...}
>
> 2bsd.tex:\chapter{Second Berkeley Software Tape}
>
> 3bsd.tex:\chapter{Welcome to Virtual Vax/UNIX}
>
> 2bsd-part2.tex:\chapter{2BSD becomes an operating system}
>
> 4bsd.tex:\chapter{4BSD}
>
> 43bsd.tex:\chapter{4.3BSD -- The Internet Server}
>
> 2bsd-part3.tex:\chapter{The 16-bit 2BSD continues}
>
> 43bsd-part2.tex:\chapter{To open source BSD}
>
> commercial.tex:\chapter{Commercial Unixes using BSD}
>
> 44bsd.tex:\chapter{4.4BSD}
>
> bsdi.tex:\chapter{BSDI}
>
> 386bsd.tex:\chapter{386BSD Part 1}
>
> lawsuit.tex:\chapter{Lawsuit}
>
> patchkit.tex:\chapter{The official unofficial patchkits}
>
> netbsd.tex:\chapter{NetBSD}
>
> freebsd.tex:\chapter{FreeBSD}
>
> 386bsd-part3.tex:\chapter{386BSD Part 2}
>
> bsdi-part2.tex:\chapter{BSDI part 2}
>
> openbsd.tex:\chapter{OpenBSD}
>
> netbsd-part2.tex:\chapter{NetBSD -- Part 2}
>
> dragonfly.tex:\chapter{DragonFly BSD}
>
> 3bsd-license.tex:\chapter{3BSD Software Agreement (1979)}
>
> 4bsd-license.tex:\chapter{4BSD Software Agreement (1980)}
>
>
>
> -----------------------
>
> echo Ohl zl obbx uggc://errqzrqvn.arg/obbxf/csfrafr/ | \
>  tr "Onoqrsuvxzabcefghl" "Babdefhikmnoprstuy"
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190913/78b59e7a/attachment.html>

From wobblygong at gmail.com  Sat Sep 14 16:13:28 2019
From: wobblygong at gmail.com (Wesley Parish)
Date: Sat, 14 Sep 2019 18:13:28 +1200
Subject: [TUHS] My EuroBSDcon talk (preview for commentary)
In-Reply-To: <CAC20D2NmXGzN7imTKy-RRWRZ2ewWMEmUV9oDuP3-e3a4R+ynpA@mail.gmail.com>
References: <CANCZdfrK4iFQCWOFP4MoUggpfJVmoJ0dnSg6H0cCi4dop7sVXw@mail.gmail.com>
 <CAC20D2NmXGzN7imTKy-RRWRZ2ewWMEmUV9oDuP3-e3a4R+ynpA@mail.gmail.com>
Message-ID: <CACNPpeaWoi+OwqOT2scVY1OZhSykJuw=s=8uiyDwBOnyR8PcPA@mail.gmail.com>

I had the pleasure to play on both a DEC Rainbow and an early Sony PC
(both running MS DOS 2.x though the Rainbow also ran CP/M) in the
early 90s. They could have been described as being only relatively
"IBM clones", as their BIOS did not fully reimplement the IBM PC BIOS.
That was the Phoenix BIOS's achievement.

Consequently Microsoft's Xenix would have come in several different
flavours, according to who the OEM was. I don't know how long this
state of affairs went on for; I do know several computer books dating
from the late 80s I looked at in the early 90s regarded this a
standard, though regrettable, problem.

Do we have any Microsoft Xenix guys on this list? Anyone who'd be able
to fill in these gaps in our knowledge? Or does anyone know anyone
formerly of Microsoft or the original Santa Cruz Operation who we
could ask?

Wesley Parish

On 9/14/19, Clem Cole <clemc at ccc.com> wrote:
<snip>
>
> Slide 35 --   Not sure that is true.   I thought Microsoft's Xenix ships
> before Venix.    Particularly since you made the comment about System III
> The original 8086 Xenix was a pure V7 port, with a few additions Gordon
> brought with him from Purdue (i.e. ghg hacks).
>

From dds at aueb.gr  Sat Sep 14 17:35:22 2019
From: dds at aueb.gr (Diomidis Spinellis)
Date: Sat, 14 Sep 2019 10:35:22 +0300
Subject: [TUHS] My EuroBSDcon talk (preview for commentary)
In-Reply-To: <CAC20D2Nz-ofwD41vULF2-TL8-C33heCiHvoNNbcuj6GGKhtKzQ@mail.gmail.com>
References: <CANCZdfrK4iFQCWOFP4MoUggpfJVmoJ0dnSg6H0cCi4dop7sVXw@mail.gmail.com>
 <CAC20D2NmXGzN7imTKy-RRWRZ2ewWMEmUV9oDuP3-e3a4R+ynpA@mail.gmail.com>
 <CAC20D2PXYWpv-8BQNKvUjgT=2W81GgzaOLyZiQ5=sM9+LXCWnw@mail.gmail.com>
 <CAC20D2MDbmoeMZq1esbuQvOCU7to0dUWsFyx98UQDLE3-c4fOA@mail.gmail.com>
 <201909132024.x8DKObEP013266@darkstar.fourwinds.com>
 <CAC20D2PvA26HMoABOcLMoS9Lu8=L3Wtx_8yK83K+vbhoMZt-hQ@mail.gmail.com>
 <463d5cc4-9bef-9ac3-a680-a5161d664dc1@aueb.gr>
 <CAC20D2Nz-ofwD41vULF2-TL8-C33heCiHvoNNbcuj6GGKhtKzQ@mail.gmail.com>
Message-ID: <88e1328b-f543-7c36-6a82-13159816b3ad@aueb.gr>

Correct!  I formatted the Third Edition manual with nroff rather than 
troff, but, as you write, it could have been roff.

Only one man page file contains macro definitions:

https://github.com/dspinellis/unix-history-repo/blob/Research-V3/man/manx/asmt.x#L9

and the man source files also contain the formatted output corresponding 
to that file:

https://github.com/dspinellis/unix-history-repo/blob/Research-V3/man/manx/asmt.cat

Furthermore, this file (and the others in the same directory — manx) 
does not appear in the original Third Edition manual.

So most likely the man pages were formatted with roff, although nroff 
existed and was documented at the time.

https://github.com/dspinellis/unix-history-repo/blob/Research-V3/man/man1/nroff.1

http://bitsavers.trailing-edge.com/pdf/att/unix/3rd_Edition/UNIX_Programmers_Manual_Third_Edition_Feb73.pdf#page=98



On 14-Sep-19 0:45, Clem Cole wrote:
> Awesome -- great way to figure it out, although I'm not sure 3rd edition 
> was nroff, I think it might have been roff.  I think a smart test is to 
> check to see if those sources used a macro package or not.  If not macro 
> package, I think that tells us that the likely formatting program was roff.

From imp at bsdimp.com  Sun Sep 15 03:51:09 2019
From: imp at bsdimp.com (Warner Losh)
Date: Sat, 14 Sep 2019 11:51:09 -0600
Subject: [TUHS] CB-UNIX tapes?
Message-ID: <CANCZdfrffqmusyVyK1f-0ABuynqxpd5CZDdjv1SVBZYzKRfiFw@mail.gmail.com>

I found the following in the archive:

To: cbunix23 at yahoo.com
Cc: Warren at plan9.bell-labs.com, Toomey at plan9.bell-labs.com,
        <wkt at tuhs.org>
Subject: Re: cb/unix tapes
From: Dennis Ritchie <dmr at plan9.bell-labs.com>
Date: Tue, 15 Jul 2003 21:23:37 -0400

They've arrived on my doorstep; thanks, Larry.
9-track drives seem thin on the ground, but we'll
see.

        Dennis

Does anybody know what became of those tapes? I know it was 13 years ago,
but it's one of the few sitings of CB-Unix tapes I could find...

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190914/ea784ad2/attachment.html>

From imp at bsdimp.com  Sun Sep 15 04:29:49 2019
From: imp at bsdimp.com (Warner Losh)
Date: Sat, 14 Sep 2019 12:29:49 -0600
Subject: [TUHS] IBM Unix source licenses
In-Reply-To: <CACytpF80owxCFjj7DvL1wR0DkTwEvH=fZB-pa_V=prERBg0XxA@mail.gmail.com>
References: <CANCZdfpEu6OxvmhDGSa3Cw4TSpfcbBOFbJjU7nZU-C_JFGFdRA@mail.gmail.com>
 <CAC20D2Pz+gwyeuVYcHFbJaimHtrt+sKSvCFp=hMZNoAWr4G09Q@mail.gmail.com>
 <CANCZdfpsXnbaQJo54qw689-unmVb35114PrOuNXHrcyp2Cng5g@mail.gmail.com>
 <CAC20D2MuABFQw_R2HyUFsg8Dpum+LNn6ixneO2C7Te8ECtZ3PA@mail.gmail.com>
 <c704d50c-dc9b-c703-a18c-86c411ae5d3f@technologists.com>
 <CAK7dMtDKRe99jY4iN8zkHo=evMYDOrmF8X1zLAf+sRxR3d7CmQ@mail.gmail.com>
 <CAC20D2MnW8yr+D-L7hV5XYNtVAmjT9z5vY41CCYYuxUvVJ51Sw@mail.gmail.com>
 <m27e6d2llv.fsf@irreal.org> <20190912232909.GA15734@minnie.tuhs.org>
 <CACytpF80owxCFjj7DvL1wR0DkTwEvH=fZB-pa_V=prERBg0XxA@mail.gmail.com>
Message-ID: <CANCZdfpCX=nBjKgk+V6GYKqXk+qAAH3SXvWexot2uJm6C-FfnA@mail.gmail.com>

On Fri, Sep 13, 2019, 2:30 AM SPC <spedraja at gmail.com> wrote:

>
> El vie., 13 sept. 2019 a las 1:29, Warren Toomey (<wkt at tuhs.org>)
> escribió:
>
>> Clem Cole <clemc at ccc.com> writes:
>> >
>> > > FYI: the original S/1 port was done at Cleveland State with the
>> Seventh
>> > > Edition
>>
>
> Very interesting. We got one Series/1 in our work involved in one
> electronic speech project which sadly died soon.
>
> On the other hand... Was this other portability project succesfully
> finished? The Jalics paper don't make it all clear.
>


And my perennial question: are the sources extant?

Warnet

 Also available at:
>
>>
>> https://zero.sci-hub.se/3252/016657c71a46a2d7110d87b4f720847e/jalics1983.pdf
>>
>>         Warren
>>
>
> Gracias | Regards - Saludos | Greetings | Freundliche Grüße | Salutations
> --
> *Sergio Pedraja*
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190914/44aa981f/attachment.html>

From clemc at ccc.com  Sun Sep 15 08:46:25 2019
From: clemc at ccc.com (Clem cole)
Date: Sat, 14 Sep 2019 18:46:25 -0400
Subject: [TUHS] a book (was Re:  PWB vs Unix/TS)
In-Reply-To: <alpine.NEB.2.21.1909101307530.11702@t1.m.reedmedia.net>
References: <CANCZdfpEu6OxvmhDGSa3Cw4TSpfcbBOFbJjU7nZU-C_JFGFdRA@mail.gmail.com>
 <CAC20D2Pz+gwyeuVYcHFbJaimHtrt+sKSvCFp=hMZNoAWr4G09Q@mail.gmail.com>
 <alpine.NEB.2.21.1909101307530.11702@t1.m.reedmedia.net>
Message-ID: <B2F032E8-E51B-4E58-AA8F-33BE5B7AD75F@ccc.com>

Peter Salus’s book is pretty good and what he has actuate.  

Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. 

> On Sep 13, 2019, at 8:44 PM, reed at reedmedia.net wrote:
> 
> There needs to be a book with stuff like this. There is no Unix history 
> book that I have ever seen with the depth of information in threads like 
> this and others on TUHS.  It would be a huge project and hard to tell if 
> there would me more than just recognition and intrinsic rewards for the 
> effort -- but maybe that is enough.
> 
> (As an example, I have spent hundreds if not thousands of hours 
> researching a small subset: Berkeley Unix history. Attempted to contact 
> hundreds of historical participants. Interviewed near 100 people; most 
> by email, but some in person or by phone -- even postal mail! Building a 
> massive collection of historical data. Read over 30 physical books 
> covering very small parts of the story. Watched many videos (and notes). 
> Getting documents scanned and sent to me. It is a very detailed effort 
> -- such as a single long chapter on the Virtual Vax/UNIX / London/Reiser 
> / Babaoglu story with 168 citations or the single chapters on the 
> official unofficial patchkits, lawsuit, etc. -- and there is nothing in 
> this field to compare it too. I have over 243 bibtex entries already and 
> 215 citations left to add to my .bib file. During that time, I have 
> published six other books, some written from scratch. Some have 
> suggested I use Kickstarter or similar as a financial incentive to 
> finish it off.)
> 
> Since the Unix story is so huge, a first volume could be up through 
> System III, for example, but maybe that is too much.
> 
> Anyone know of anyone writing a thorough Unix history book?
> 
> Does it make sense to use a kickstarter?
> 
> I may bring up in a different thread, but I am presenting about Unix 
> history at Dallas Ft. Worth UNIX Users Group soon. They are planning to 
> have two meetings (different months) dedicated to the history (50th 
> anniversary).
> 
> Jeremy C. Reed
> 
> p.s. Sorry to mention this, but time is running out:
> 
> $ grep -i decease /home/reed/book/bsd-history/PEOPLE | wc -l 
>      17
> 
> pps. My other chapters:
> 
> beginning.tex:\chapter{In the beginning ...}
> 
> 2bsd.tex:\chapter{Second Berkeley Software Tape}
> 
> 3bsd.tex:\chapter{Welcome to Virtual Vax/UNIX}
> 
> 2bsd-part2.tex:\chapter{2BSD becomes an operating system}
> 
> 4bsd.tex:\chapter{4BSD}
> 
> 43bsd.tex:\chapter{4.3BSD -- The Internet Server}
> 
> 2bsd-part3.tex:\chapter{The 16-bit 2BSD continues}
> 
> 43bsd-part2.tex:\chapter{To open source BSD}
> 
> commercial.tex:\chapter{Commercial Unixes using BSD}
> 
> 44bsd.tex:\chapter{4.4BSD}
> 
> bsdi.tex:\chapter{BSDI}
> 
> 386bsd.tex:\chapter{386BSD Part 1}
> 
> lawsuit.tex:\chapter{Lawsuit}
> 
> patchkit.tex:\chapter{The official unofficial patchkits}
> 
> netbsd.tex:\chapter{NetBSD}
> 
> freebsd.tex:\chapter{FreeBSD}
> 
> 386bsd-part3.tex:\chapter{386BSD Part 2}
> 
> bsdi-part2.tex:\chapter{BSDI part 2}
> 
> openbsd.tex:\chapter{OpenBSD}
> 
> netbsd-part2.tex:\chapter{NetBSD -- Part 2}
> 
> dragonfly.tex:\chapter{DragonFly BSD}
> 
> 3bsd-license.tex:\chapter{3BSD Software Agreement (1979)}
> 
> 4bsd-license.tex:\chapter{4BSD Software Agreement (1980)}
> 
> 
> 
> -----------------------
> 
> echo Ohl zl obbx uggc://errqzrqvn.arg/obbxf/csfrafr/ | \
> tr "Onoqrsuvxzabcefghl" "Babdefhikmnoprstuy"

From athornton at gmail.com  Sun Sep 15 10:58:21 2019
From: athornton at gmail.com (Adam Thornton)
Date: Sat, 14 Sep 2019 17:58:21 -0700
Subject: [TUHS] a book (was Re: PWB vs Unix/TS)
In-Reply-To: <B2F032E8-E51B-4E58-AA8F-33BE5B7AD75F@ccc.com>
References: <CANCZdfpEu6OxvmhDGSa3Cw4TSpfcbBOFbJjU7nZU-C_JFGFdRA@mail.gmail.com>
 <CAC20D2Pz+gwyeuVYcHFbJaimHtrt+sKSvCFp=hMZNoAWr4G09Q@mail.gmail.com>
 <alpine.NEB.2.21.1909101307530.11702@t1.m.reedmedia.net>
 <B2F032E8-E51B-4E58-AA8F-33BE5B7AD75F@ccc.com>
Message-ID: <CAP2nic3L1bVPvgX7yshrHxkhqd24otdUQO8g_ayFRXVbFZJ0Dg@mail.gmail.com>

I...have never been all that impressed with Salus's work.  It's not _bad_
but it's also not terribly insightful.

I'm not volunteering to do better, though.  At least not until after I find
out whose job it is to be the NOAO/NCOA archivist, shout and scream until
that answer is at least "someone," and get people poking and prodding the
first-generation LSST crowd for memoirs and interviews in that golden
period after they retire and no longer have careers to worry about, and
before they die.

Maybe for the seventy-fifth anniversary.

On Sat, Sep 14, 2019 at 3:47 PM Clem cole <clemc at ccc.com> wrote:

> Peter Salus’s book is pretty good and what he has actuate.
>
> Sent from my PDP-7 Running UNIX V0 expect things to be almost but not
> quite.
>
> > On Sep 13, 2019, at 8:44 PM, reed at reedmedia.net wrote:
> >
> > There needs to be a book with stuff like this. There is no Unix history
> > book that I have ever seen with the depth of information in threads like
> > this and others on TUHS.  It would be a huge project and hard to tell if
> > there would me more than just recognition and intrinsic rewards for the
> > effort -- but maybe that is enough.
> >
> > (As an example, I have spent hundreds if not thousands of hours
> > researching a small subset: Berkeley Unix history. Attempted to contact
> > hundreds of historical participants. Interviewed near 100 people; most
> > by email, but some in person or by phone -- even postal mail! Building a
> > massive collection of historical data. Read over 30 physical books
> > covering very small parts of the story. Watched many videos (and notes).
> > Getting documents scanned and sent to me. It is a very detailed effort
> > -- such as a single long chapter on the Virtual Vax/UNIX / London/Reiser
> > / Babaoglu story with 168 citations or the single chapters on the
> > official unofficial patchkits, lawsuit, etc. -- and there is nothing in
> > this field to compare it too. I have over 243 bibtex entries already and
> > 215 citations left to add to my .bib file. During that time, I have
> > published six other books, some written from scratch. Some have
> > suggested I use Kickstarter or similar as a financial incentive to
> > finish it off.)
> >
> > Since the Unix story is so huge, a first volume could be up through
> > System III, for example, but maybe that is too much.
> >
> > Anyone know of anyone writing a thorough Unix history book?
> >
> > Does it make sense to use a kickstarter?
> >
> > I may bring up in a different thread, but I am presenting about Unix
> > history at Dallas Ft. Worth UNIX Users Group soon. They are planning to
> > have two meetings (different months) dedicated to the history (50th
> > anniversary).
> >
> > Jeremy C. Reed
> >
> > p.s. Sorry to mention this, but time is running out:
> >
> > $ grep -i decease /home/reed/book/bsd-history/PEOPLE | wc -l
> >      17
> >
> > pps. My other chapters:
> >
> > beginning.tex:\chapter{In the beginning ...}
> >
> > 2bsd.tex:\chapter{Second Berkeley Software Tape}
> >
> > 3bsd.tex:\chapter{Welcome to Virtual Vax/UNIX}
> >
> > 2bsd-part2.tex:\chapter{2BSD becomes an operating system}
> >
> > 4bsd.tex:\chapter{4BSD}
> >
> > 43bsd.tex:\chapter{4.3BSD -- The Internet Server}
> >
> > 2bsd-part3.tex:\chapter{The 16-bit 2BSD continues}
> >
> > 43bsd-part2.tex:\chapter{To open source BSD}
> >
> > commercial.tex:\chapter{Commercial Unixes using BSD}
> >
> > 44bsd.tex:\chapter{4.4BSD}
> >
> > bsdi.tex:\chapter{BSDI}
> >
> > 386bsd.tex:\chapter{386BSD Part 1}
> >
> > lawsuit.tex:\chapter{Lawsuit}
> >
> > patchkit.tex:\chapter{The official unofficial patchkits}
> >
> > netbsd.tex:\chapter{NetBSD}
> >
> > freebsd.tex:\chapter{FreeBSD}
> >
> > 386bsd-part3.tex:\chapter{386BSD Part 2}
> >
> > bsdi-part2.tex:\chapter{BSDI part 2}
> >
> > openbsd.tex:\chapter{OpenBSD}
> >
> > netbsd-part2.tex:\chapter{NetBSD -- Part 2}
> >
> > dragonfly.tex:\chapter{DragonFly BSD}
> >
> > 3bsd-license.tex:\chapter{3BSD Software Agreement (1979)}
> >
> > 4bsd-license.tex:\chapter{4BSD Software Agreement (1980)}
> >
> >
> >
> > -----------------------
> >
> > echo Ohl zl obbx uggc://errqzrqvn.arg/obbxf/csfrafr/ | \
> > tr "Onoqrsuvxzabcefghl" "Babdefhikmnoprstuy"
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190914/9a31dcaf/attachment.html>

From jon at fourwinds.com  Sun Sep 15 12:18:37 2019
From: jon at fourwinds.com (Jon Steinhart)
Date: Sat, 14 Sep 2019 19:18:37 -0700
Subject: [TUHS] a book (was Re: PWB vs Unix/TS)
In-Reply-To: <CANCZdfpsE1GnaKknt0zcae5KyaWrS3gw1cCVgf_vjfKH-f0w4g@mail.gmail.com>
References: <CANCZdfpEu6OxvmhDGSa3Cw4TSpfcbBOFbJjU7nZU-C_JFGFdRA@mail.gmail.com>
 <CAC20D2Pz+gwyeuVYcHFbJaimHtrt+sKSvCFp=hMZNoAWr4G09Q@mail.gmail.com>
 <alpine.NEB.2.21.1909101307530.11702@t1.m.reedmedia.net>
 <CANCZdfpsE1GnaKknt0zcae5KyaWrS3gw1cCVgf_vjfKH-f0w4g@mail.gmail.com>
Message-ID: <201909150218.x8F2Iba3018530@darkstar.fourwinds.com>

On Fri, Sep 13, 2019 at 7:31 PM <reed at reedmedia.net> wrote:

> There needs to be a book with stuff like this. There is no Unix history
> book that I have ever seen with the depth of information in threads like
> this and others on TUHS.  It would be a huge project and hard to tell if
> there would me more than just recognition and intrinsic rewards for the
> effort -- but maybe that is enough.

So having just finished a book project and therefore having a bit of a clue
as to what it would take, I'd be willing to take a stab at coordinating a
project like this.  But it's not clear to me what the audience should be.
Many of the folks on this list are obsessive with details that matter to,
well, only people on this list.  To make a good book I think that it would
have to trace the major paths, innovations, and people.  In any case, this
would be easy - just write whatever you want and wait for Clem to correct
you and fill in the details :-)

Jon

From clemc at ccc.com  Sun Sep 15 12:39:48 2019
From: clemc at ccc.com (Clem Cole)
Date: Sat, 14 Sep 2019 22:39:48 -0400
Subject: [TUHS] a book (was Re: PWB vs Unix/TS)
In-Reply-To: <201909150218.x8F2Iba3018530@darkstar.fourwinds.com>
References: <CANCZdfpEu6OxvmhDGSa3Cw4TSpfcbBOFbJjU7nZU-C_JFGFdRA@mail.gmail.com>
 <CAC20D2Pz+gwyeuVYcHFbJaimHtrt+sKSvCFp=hMZNoAWr4G09Q@mail.gmail.com>
 <alpine.NEB.2.21.1909101307530.11702@t1.m.reedmedia.net>
 <CANCZdfpsE1GnaKknt0zcae5KyaWrS3gw1cCVgf_vjfKH-f0w4g@mail.gmail.com>
 <201909150218.x8F2Iba3018530@darkstar.fourwinds.com>
Message-ID: <CAC20D2OEYyciW+m-sm1SxjFb-mC-2D6uhGVwtC+KYj78T=ZLxw@mail.gmail.com>

On Sat, Sep 14, 2019 at 10:19 PM Jon Steinhart <jon at fourwinds.com> wrote:

> On Fri, Sep 13, 2019 at 7:31 PM <reed at reedmedia.net> wrote:
>
> > There needs to be a book with stuff like this. There is no Unix history
> > book that I have ever seen with the depth of information in threads like
> > this and others on TUHS.  It would be a huge project and hard to tell if
> > there would me more than just recognition and intrinsic rewards for the
> > effort -- but maybe that is enough.
>
> So having just finished a book project and therefore having a bit of a clue
> as to what it would take, I'd be willing to take a stab at coordinating a
> project like this.  But it's not clear to me what the audience should be.
> Many of the folks on this list are obsessive with details that matter to,
> well, only people on this list.  To make a good book I think that it would
> have to trace the major paths, innovations, and people.  In any case, this
> would be easy - just write whatever you want and wait for Clem to correct
> you and fill in the details :-)
>
> Jon
>
With friends like Jon ...
-- 
Sent from a handheld expect more typos than usual
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190914/e82f04dd/attachment.html>

From doug at cs.dartmouth.edu  Sun Sep 15 12:45:17 2019
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Sat, 14 Sep 2019 22:45:17 -0400
Subject: [TUHS] earliest Unix roff
Message-ID: <201909150245.x8F2jHIp093980@tahoe.cs.Dartmouth.EDU>

> I'd love to see the docs on that early stuff and see if Joe Ossanna
> added in his own magic or was he carrying forward earlier magic.

Here are scans of non-unix roff in 1971: https://www.cs.dartmouth.edu/~doug/roff71/roff71
I also have 1969, but it's bedtime and that will have to wait.

Relative numbers (+n), roman numerals, .ti, top and bottom margin settings,
.po, running titles, tab settings, hyphenation and footnotes were not in
Saltzer's runoff. Most other features were. 

Doug

From doug at cs.dartmouth.edu  Sun Sep 15 12:47:08 2019
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Sat, 14 Sep 2019 22:47:08 -0400
Subject: [TUHS] earliest Unix roff [correction]
Message-ID: <201909150247.x8F2l8Vp094001@tahoe.cs.Dartmouth.EDU>

The URL for roff71 scans is  https://www.cs.dartmouth.edu/~doug/roff71/

From clemc at ccc.com  Sun Sep 15 13:02:29 2019
From: clemc at ccc.com (Clem Cole)
Date: Sat, 14 Sep 2019 23:02:29 -0400
Subject: [TUHS] earliest Unix roff [correction]
In-Reply-To: <201909150247.x8F2l8Vp094001@tahoe.cs.Dartmouth.EDU>
References: <201909150247.x8F2l8Vp094001@tahoe.cs.Dartmouth.EDU>
Message-ID: <CAC20D2NuQr8pTVNeseyzKtY7r7fbu22QujGeHATkMMJJiP4fdw@mail.gmail.com>

Doug

Thank you

On Sat, Sep 14, 2019 at 10:47 PM Doug McIlroy <doug at cs.dartmouth.edu> wrote:

> The URL for roff71 scans is  https://www.cs.dartmouth.edu/~doug/roff71/
>
-- 
Sent from a handheld expect more typos than usual
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190914/556b3877/attachment.html>

From ullbeking at andrewnesbit.org  Sun Sep 15 12:56:54 2019
From: ullbeking at andrewnesbit.org (U'll Be King of the Stars)
Date: Sun, 15 Sep 2019 03:56:54 +0100
Subject: [TUHS] earliest Unix roff
In-Reply-To: <20190914024433.GA19193@minnie.tuhs.org>
References: <CAC20D2NmXGzN7imTKy-RRWRZ2ewWMEmUV9oDuP3-e3a4R+ynpA@mail.gmail.com>
 <CAC20D2PXYWpv-8BQNKvUjgT=2W81GgzaOLyZiQ5=sM9+LXCWnw@mail.gmail.com>
 <CAC20D2MDbmoeMZq1esbuQvOCU7to0dUWsFyx98UQDLE3-c4fOA@mail.gmail.com>
 <201909132024.x8DKObEP013266@darkstar.fourwinds.com>
 <CAC20D2PvA26HMoABOcLMoS9Lu8=L3Wtx_8yK83K+vbhoMZt-hQ@mail.gmail.com>
 <463d5cc4-9bef-9ac3-a680-a5161d664dc1@aueb.gr>
 <CAC20D2Nz-ofwD41vULF2-TL8-C33heCiHvoNNbcuj6GGKhtKzQ@mail.gmail.com>
 <20190913221345.GA16129@minnie.tuhs.org>
 <CAC20D2OQD-NJaFsqsLVL_kqmCsSeUOKAr7dm71P4uN9N8m+AbQ@mail.gmail.com>
 <20190914020240.GO2046@mcvoy.com> <20190914024433.GA19193@minnie.tuhs.org>
Message-ID: <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org>

On 14/09/2019 03:44, Warren Toomey wrote:
> On Fri, Sep 13, 2019 at 07:02:40PM -0700, Larry McVoy wrote:
>> Roff has some pretty sophisticated stuff (environments come to mind) that
>> I think 99.9% of the CS world doesn't understand

This thread about *roff echoes something that I have been thinking about 
recently.

I've been wondering whether it is possible and worthwhile to use *roff 
for complex technical documentation.  I've always loved the aesthetic 
that books produced using *roff have but there are other reasons too.

As far as _markup_ is concerned we have DocBook for example.  I am also 
looking into this.  (Also, I understand it's not a typesetting system.)

Getting back to *roff, does anybody know if there is a (hopefully rich) 
repository of macros, or any other resources, for my use case?  (La)TeX 
has this but I'd like to try something else.  What do people think?

Kind regards,

Andrew
-- 
OpenPGP key: EB28 0338 28B7 19DA DAB0  B193 D21D 996E 883B E5B9

From athornton at gmail.com  Sun Sep 15 13:24:46 2019
From: athornton at gmail.com (Adam Thornton)
Date: Sat, 14 Sep 2019 20:24:46 -0700
Subject: [TUHS] a book (was Re: PWB vs Unix/TS)
In-Reply-To: <201909150218.x8F2Iba3018530@darkstar.fourwinds.com>
References: <CANCZdfpEu6OxvmhDGSa3Cw4TSpfcbBOFbJjU7nZU-C_JFGFdRA@mail.gmail.com>
 <CAC20D2Pz+gwyeuVYcHFbJaimHtrt+sKSvCFp=hMZNoAWr4G09Q@mail.gmail.com>
 <alpine.NEB.2.21.1909101307530.11702@t1.m.reedmedia.net>
 <CANCZdfpsE1GnaKknt0zcae5KyaWrS3gw1cCVgf_vjfKH-f0w4g@mail.gmail.com>
 <201909150218.x8F2Iba3018530@darkstar.fourwinds.com>
Message-ID: <CAP2nic3uAzMvhPu=So-LHaQ50CN59jqXUqgn-RVw79+6XznU_w@mail.gmail.com>

JonSteinhart said:

> just write whatever you want and wait for Clem to correct you and fill in
the details

Thanks for giving away my deepest secret for being a contributor to Open
Source projects.  The trick is, you write _something_ that does what you
need, no matter how horrid, and put it out there, and wait for the screams
to roll in and then someone who knows what they're doing to implement it
correctly.

Works almost every time.

Adam

On Sat, Sep 14, 2019 at 7:19 PM Jon Steinhart <jon at fourwinds.com> wrote:

> On Fri, Sep 13, 2019 at 7:31 PM <reed at reedmedia.net> wrote:
>
> > There needs to be a book with stuff like this. There is no Unix history
> > book that I have ever seen with the depth of information in threads like
> > this and others on TUHS.  It would be a huge project and hard to tell if
> > there would me more than just recognition and intrinsic rewards for the
> > effort -- but maybe that is enough.
>
> So having just finished a book project and therefore having a bit of a clue
> as to what it would take, I'd be willing to take a stab at coordinating a
> project like this.  But it's not clear to me what the audience should be.
> Many of the folks on this list are obsessive with details that matter to,
> well, only people on this list.  To make a good book I think that it would
> have to trace the major paths, innovations, and people.  In any case, this
> would be easy - just write whatever you want and wait for Clem to correct
> you and fill in the details :-)
>
> Jon
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190914/db18c2cc/attachment.html>

From tuhs at eric.allman.name  Sun Sep 15 13:30:38 2019
From: tuhs at eric.allman.name (Eric Allman)
Date: Sat, 14 Sep 2019 20:30:38 -0700
Subject: [TUHS] a book (was Re: PWB vs Unix/TS)
In-Reply-To: <CAP2nic3L1bVPvgX7yshrHxkhqd24otdUQO8g_ayFRXVbFZJ0Dg@mail.gmail.com>
References: <CANCZdfpEu6OxvmhDGSa3Cw4TSpfcbBOFbJjU7nZU-C_JFGFdRA@mail.gmail.com>
 <CAC20D2Pz+gwyeuVYcHFbJaimHtrt+sKSvCFp=hMZNoAWr4G09Q@mail.gmail.com>
 <alpine.NEB.2.21.1909101307530.11702@t1.m.reedmedia.net>
 <B2F032E8-E51B-4E58-AA8F-33BE5B7AD75F@ccc.com>
 <CAP2nic3L1bVPvgX7yshrHxkhqd24otdUQO8g_ayFRXVbFZJ0Dg@mail.gmail.com>
Message-ID: <d7377aaf-9342-9c8f-9ea7-24c11ab3be4e@neophilic.com>

On 2019-09-14 17:58, Adam Thornton wrote:
> I...have never been all that impressed with Salus's work.  It's not _bad_ but it's also not terribly insightful.
I think Peter's work was an amazing effort to collect and disseminate
facts, and despite a few gaps (inevitable) he did a great job.  But
Peter's works were more collections of facts than attempts to interpret,
contextualize, or otherwise put the facts into a larger narrative.

Honest historians can disagree on the role of written histories.  A pure
"just the facts ma'am" history avoids context and interpretation but
tends to be fairly dry.  This was Peter's approach.  But it's impossible
to completely avoid bias because you have to pick and choose the facts
you include.  Contextualizing history inevitably leads to interpretation
which leads to some amount of bias, but interesting or even gripping
histories read like a novel that unfolds before you.

I've believed for a long time that when the definitive history of Unix
is written, Peter's books will be a major (albeit not "primary", in the
technical sense) source material.  I salute him for all his hard (and
early) work.  I hope that someone will step up to do this larger history
(much of which happened after Peter's publication dates) before we all
die off.

And I have to say, It looks like Warner's research (with all the
abundant help from this group) the last week or two is amazing.  I've
learned tons of stuff I didn't know, some of which didn't match my
memory, e.g., about generations of *roff.  As the author of the -me
macro package, I'm probably one of the handful of people in the world
who have ever used every feature in [nt]roff, many of which looked crazy
until I needed them, when they suddenly seemed to be genius.  I deeply
regret that I never had an opportunity to meet Joe Ossanna.

eric

From lm at mcvoy.com  Sun Sep 15 14:21:17 2019
From: lm at mcvoy.com (Larry McVoy)
Date: Sat, 14 Sep 2019 21:21:17 -0700
Subject: [TUHS] a book (was Re: PWB vs Unix/TS)
In-Reply-To: <d7377aaf-9342-9c8f-9ea7-24c11ab3be4e@neophilic.com>
References: <CANCZdfpEu6OxvmhDGSa3Cw4TSpfcbBOFbJjU7nZU-C_JFGFdRA@mail.gmail.com>
 <CAC20D2Pz+gwyeuVYcHFbJaimHtrt+sKSvCFp=hMZNoAWr4G09Q@mail.gmail.com>
 <alpine.NEB.2.21.1909101307530.11702@t1.m.reedmedia.net>
 <B2F032E8-E51B-4E58-AA8F-33BE5B7AD75F@ccc.com>
 <CAP2nic3L1bVPvgX7yshrHxkhqd24otdUQO8g_ayFRXVbFZJ0Dg@mail.gmail.com>
 <d7377aaf-9342-9c8f-9ea7-24c11ab3be4e@neophilic.com>
Message-ID: <20190915042117.GW2046@mcvoy.com>

On Sat, Sep 14, 2019 at 08:30:38PM -0700, Eric Allman wrote:
> I deeply
> regret that I never had an opportunity to meet Joe Ossanna.

As roff guy I couldn't agree more.

From jon at fourwinds.com  Sun Sep 15 15:17:21 2019
From: jon at fourwinds.com (Jon Steinhart)
Date: Sat, 14 Sep 2019 22:17:21 -0700
Subject: [TUHS] a book (was Re: PWB vs Unix/TS)
In-Reply-To: <20190915042117.GW2046@mcvoy.com>
References: <CANCZdfpEu6OxvmhDGSa3Cw4TSpfcbBOFbJjU7nZU-C_JFGFdRA@mail.gmail.com>
 <CAC20D2Pz+gwyeuVYcHFbJaimHtrt+sKSvCFp=hMZNoAWr4G09Q@mail.gmail.com>
 <alpine.NEB.2.21.1909101307530.11702@t1.m.reedmedia.net>
 <B2F032E8-E51B-4E58-AA8F-33BE5B7AD75F@ccc.com>
 <CAP2nic3L1bVPvgX7yshrHxkhqd24otdUQO8g_ayFRXVbFZJ0Dg@mail.gmail.com>
 <d7377aaf-9342-9c8f-9ea7-24c11ab3be4e@neophilic.com>
 <20190915042117.GW2046@mcvoy.com>
Message-ID: <201909150517.x8F5HLfa009023@darkstar.fourwinds.com>

Larry McVoy writes:
> On Sat, Sep 14, 2019 at 08:30:38PM -0700, Eric Allman wrote:
> > I deeply
> > regret that I never had an opportunity to meet Joe Ossanna.
>
> As roff guy I couldn't agree more.

I feel worse.  I probably did meet him but was a kid and didn't
know he would be special.

BTW, I still use troff for lots of stuff.  I know that tex is
more capable, but troff is burned into my dna.  I started with
roff when I wrote my first BTL technical memorandum and later
moved to nroff.  Never actually used the C/A/T at BTL but I
remember the smell of the developer and pages hanging out to
dry.  I find the tex language a bit ugly, but that's just my
taste.  I have piles of crufty packages cobbled together around
it, but they're not really fit for use by others.  

I like to write in troff because it allows me to think about
what I want to say without worrying about how I want it to look
until later.

Probably the ugliest tool is the one that I used to convert my
book from troff into office because my publisher wouldn't take
troff.  Converted everything into openoffice xml format.  Extracted
all of the diagrams and tables, ran them through separately, then
through ps2pdf then pdf2svg, and then inkscape for cropping to
generate svg images for all of the art since they're the only scalable
image format understood by office.

Way back in the 80s when scheduling was new I wrote tools that generated
pert and gantt charts via pic.

The power of little and languages and composability lives on!

Jon

From arnold at skeeve.com  Sun Sep 15 16:54:12 2019
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Sun, 15 Sep 2019 00:54:12 -0600
Subject: [TUHS] earliest Unix roff
In-Reply-To: <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org>
References: <CAC20D2NmXGzN7imTKy-RRWRZ2ewWMEmUV9oDuP3-e3a4R+ynpA@mail.gmail.com>
 <CAC20D2PXYWpv-8BQNKvUjgT=2W81GgzaOLyZiQ5=sM9+LXCWnw@mail.gmail.com>
 <CAC20D2MDbmoeMZq1esbuQvOCU7to0dUWsFyx98UQDLE3-c4fOA@mail.gmail.com>
 <201909132024.x8DKObEP013266@darkstar.fourwinds.com>
 <CAC20D2PvA26HMoABOcLMoS9Lu8=L3Wtx_8yK83K+vbhoMZt-hQ@mail.gmail.com>
 <463d5cc4-9bef-9ac3-a680-a5161d664dc1@aueb.gr>
 <CAC20D2Nz-ofwD41vULF2-TL8-C33heCiHvoNNbcuj6GGKhtKzQ@mail.gmail.com>
 <20190913221345.GA16129@minnie.tuhs.org>
 <CAC20D2OQD-NJaFsqsLVL_kqmCsSeUOKAr7dm71P4uN9N8m+AbQ@mail.gmail.com>
 <20190914020240.GO2046@mcvoy.com>
 <20190914024433.GA19193@minnie.tuhs.org>
 <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org>
Message-ID: <201909150654.x8F6sChG021185@freefriends.org>

"U'll Be King of the Stars" <ullbeking at andrewnesbit.org> wrote:

> On 14/09/2019 03:44, Warren Toomey wrote:
> > On Fri, Sep 13, 2019 at 07:02:40PM -0700, Larry McVoy wrote:
> >> Roff has some pretty sophisticated stuff (environments come to mind) that
> >> I think 99.9% of the CS world doesn't understand
>
> This thread about *roff echoes something that I have been thinking about 
> recently.
>
> I've been wondering whether it is possible and worthwhile to use *roff 
> for complex technical documentation.  I've always loved the aesthetic 
> that books produced using *roff have but there are other reasons too.
>
> As far as _markup_ is concerned we have DocBook for example.  I am also 
> looking into this.  (Also, I understand it's not a typesetting system.)

Unless you use a WYSIWYG tool that generates DocBook, you should avoid it.
Your fingers will kill you.  I have written books in troff, DocBook
and Texinfo.  Texinfo is *by far* the superior markup language.

Using Texinfo can generate DocBook which your publisher can turn into PDF.
(I have done this, three times at least.)  But working directly in
DocBook just plain hurts.

> Getting back to *roff, does anybody know if there is a (hopefully rich) 
> repository of macros, or any other resources, for my use case?  (La)TeX 
> has this but I'd like to try something else.  What do people think?

The MM macros are the most capable of the standard sets that are
out there, although possibly the MOM macros distributed with groff
are even more so; I have not investigated fully.

My own wish for the next genie in a lamp that I come across would be
for a texinfo --> troff translator.

Arnold

From dave at horsfall.org  Sun Sep 15 17:01:15 2019
From: dave at horsfall.org (Dave Horsfall)
Date: Sun, 15 Sep 2019 17:01:15 +1000 (EST)
Subject: [TUHS] earliest Unix roff
In-Reply-To: <201909150654.x8F6sChG021185@freefriends.org>
References: <CAC20D2NmXGzN7imTKy-RRWRZ2ewWMEmUV9oDuP3-e3a4R+ynpA@mail.gmail.com>
 <CAC20D2PXYWpv-8BQNKvUjgT=2W81GgzaOLyZiQ5=sM9+LXCWnw@mail.gmail.com>
 <CAC20D2MDbmoeMZq1esbuQvOCU7to0dUWsFyx98UQDLE3-c4fOA@mail.gmail.com>
 <201909132024.x8DKObEP013266@darkstar.fourwinds.com>
 <CAC20D2PvA26HMoABOcLMoS9Lu8=L3Wtx_8yK83K+vbhoMZt-hQ@mail.gmail.com>
 <463d5cc4-9bef-9ac3-a680-a5161d664dc1@aueb.gr>
 <CAC20D2Nz-ofwD41vULF2-TL8-C33heCiHvoNNbcuj6GGKhtKzQ@mail.gmail.com>
 <20190913221345.GA16129@minnie.tuhs.org>
 <CAC20D2OQD-NJaFsqsLVL_kqmCsSeUOKAr7dm71P4uN9N8m+AbQ@mail.gmail.com>
 <20190914020240.GO2046@mcvoy.com> <20190914024433.GA19193@minnie.tuhs.org>
 <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org>
 <201909150654.x8F6sChG021185@freefriends.org>
Message-ID: <alpine.BSF.2.21.9999.1909151658220.18105@aneurin.horsfall.org>

On Sun, 15 Sep 2019, arnold at skeeve.com wrote:

> The MM macros are the most capable of the standard sets that are out 
> there, although possibly the MOM macros distributed with groff are even 
> more so; I have not investigated fully.

For some reason I prefer the MS macros, probably because I learnt them 
first and I find it difficult to use MM.

-- Dave

From ullbeking at andrewnesbit.org  Sun Sep 15 17:32:25 2019
From: ullbeking at andrewnesbit.org (U'll Be King of the Stars)
Date: Sun, 15 Sep 2019 08:32:25 +0100
Subject: [TUHS] earliest Unix roff
In-Reply-To: <201909150654.x8F6sChG021185@freefriends.org>
References: <CAC20D2NmXGzN7imTKy-RRWRZ2ewWMEmUV9oDuP3-e3a4R+ynpA@mail.gmail.com>
 <CAC20D2PXYWpv-8BQNKvUjgT=2W81GgzaOLyZiQ5=sM9+LXCWnw@mail.gmail.com>
 <CAC20D2MDbmoeMZq1esbuQvOCU7to0dUWsFyx98UQDLE3-c4fOA@mail.gmail.com>
 <201909132024.x8DKObEP013266@darkstar.fourwinds.com>
 <CAC20D2PvA26HMoABOcLMoS9Lu8=L3Wtx_8yK83K+vbhoMZt-hQ@mail.gmail.com>
 <463d5cc4-9bef-9ac3-a680-a5161d664dc1@aueb.gr>
 <CAC20D2Nz-ofwD41vULF2-TL8-C33heCiHvoNNbcuj6GGKhtKzQ@mail.gmail.com>
 <20190913221345.GA16129@minnie.tuhs.org>
 <CAC20D2OQD-NJaFsqsLVL_kqmCsSeUOKAr7dm71P4uN9N8m+AbQ@mail.gmail.com>
 <20190914020240.GO2046@mcvoy.com> <20190914024433.GA19193@minnie.tuhs.org>
 <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org>
 <201909150654.x8F6sChG021185@freefriends.org>
Message-ID: <27f52737-3e3b-1198-7ed4-6b97a5f19938@andrewnesbit.org>

On 15/09/2019 07:54, arnold at skeeve.com wrote:
> "U'll Be King of the Stars" <ullbeking at andrewnesbit.org> wrote:
>> I've been wondering whether it is possible and worthwhile to use *roff
>> for complex technical documentation.  I've always loved the aesthetic
>> that books produced using *roff have but there are other reasons too.
>>
>> As far as _markup_ is concerned we have DocBook for example.  I am also
>> looking into this.  (Also, I understand it's not a typesetting system.)
> 
> Unless you use a WYSIWYG tool that generates DocBook, you should avoid it.
> Your fingers will kill you.

Oh, I'm not looking for WYSIWIG or even really WYSIMIM.  I'm well used 
to writing in structural markup and presentation markup languages, e.g., 
LaTeX (which I think is extremely complicated, and since I left the 
university environment I do not miss it).

AS for authoring DocBook I was depending on GNU Emacs to do a lot of the 
heavy XML stuff for me.  Wishful thinking perhaps.

> I have written books in troff, DocBook
> and Texinfo.  Texinfo is *by far* the superior markup language.

I've had a feeling that Texinfo has been getting brushed to the side.

Are you suggesting that Info is a good as a rendered documentation 
format?  Or just that Texinfo is good for proto-documents that are to be 
authored in a parseable and meaningful format?

I've been a long-time GNU Emacs user so reading Info files is OK for me. 
  But we've never had a _nice_ Info reader, which is why it didn't take 
off I think.  A lot of people REALLY hate the Info UI.

Moreover it was (is?) very difficult to generate good contents and index 
pages with the official tools that I used at the time.  I started 
working on improving this about 20 years ago but back then it felt as 
though the GNU Info and GNU Emacs projects had other things on their minds.

> Using Texinfo can generate DocBook which your publisher can turn into PDF.
> (I have done this, three times at least.)  But working directly in
> DocBook just plain hurts.

OK, so you are suggesting Texinfo as a prototypical markup language, not 
necessarily something that will end up as Info files?

I have read the Texinfo documentation and I agree that it seemed like a 
rich markup language.

>> Getting back to *roff, does anybody know if there is a (hopefully rich)
>> repository of macros, or any other resources, for my use case?  (La)TeX
>> has this but I'd like to try something else.  What do people think?
> 
> The MM macros are the most capable of the standard sets that are
> out there, although possibly the MOM macros distributed with groff
> are even more so; I have not investigated fully.

Thank you for the heads up.  I never heard of MOM but MM is more familiar.

*I haven't really looked at eqn beyond browsing docs and I'm not sure 
how much I should expect from it.*

TeX is (still?) the king of mathematical expression typesetting.

> My own wish for the next genie in a lamp that I come across would be
> for a texinfo --> troff translator.

Have you looked at Pandoc?  I don't know if it will do this but it's 
worth checking out.

Andrew
-- 
OpenPGP key: EB28 0338 28B7 19DA DAB0  B193 D21D 996E 883B E5B9

From akosela at andykosela.com  Sun Sep 15 17:43:16 2019
From: akosela at andykosela.com (Andy Kosela)
Date: Sun, 15 Sep 2019 09:43:16 +0200
Subject: [TUHS] a book (was Re: PWB vs Unix/TS)
In-Reply-To: <alpine.NEB.2.21.1909101307530.11702@t1.m.reedmedia.net>
References: <CANCZdfpEu6OxvmhDGSa3Cw4TSpfcbBOFbJjU7nZU-C_JFGFdRA@mail.gmail.com>
 <CAC20D2Pz+gwyeuVYcHFbJaimHtrt+sKSvCFp=hMZNoAWr4G09Q@mail.gmail.com>
 <alpine.NEB.2.21.1909101307530.11702@t1.m.reedmedia.net>
Message-ID: <CALMnNGh_57ecaWtw=R4odwi9Z=nWeMm-068uMx1AV2-uUbQRxA@mail.gmail.com>

On Saturday, September 14, 2019, <reed at reedmedia.net> wrote:
>
> There needs to be a book with stuff like this.

The book would be great indeed, but what about a documentary with
interviews with the greatest UNIX minds.  I remember two very good
documentaries about Linux from 2001 -- Revolution OS and The Code and
I consider them a definite resource about history of Linux in the late
90s.  A time capsule.  Really fascinating stuff.

Jason Scott's documentaries about BBS culture of the 80s and text
adventure games phenomenon are also of very high quality.

Imagine such documentary about UNIX of the 70s and 80s!

--Andy

From arnold at skeeve.com  Sun Sep 15 17:46:45 2019
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Sun, 15 Sep 2019 01:46:45 -0600
Subject: [TUHS] earliest Unix roff
In-Reply-To: <27f52737-3e3b-1198-7ed4-6b97a5f19938@andrewnesbit.org>
References: <CAC20D2NmXGzN7imTKy-RRWRZ2ewWMEmUV9oDuP3-e3a4R+ynpA@mail.gmail.com>
 <CAC20D2PXYWpv-8BQNKvUjgT=2W81GgzaOLyZiQ5=sM9+LXCWnw@mail.gmail.com>
 <CAC20D2MDbmoeMZq1esbuQvOCU7to0dUWsFyx98UQDLE3-c4fOA@mail.gmail.com>
 <201909132024.x8DKObEP013266@darkstar.fourwinds.com>
 <CAC20D2PvA26HMoABOcLMoS9Lu8=L3Wtx_8yK83K+vbhoMZt-hQ@mail.gmail.com>
 <463d5cc4-9bef-9ac3-a680-a5161d664dc1@aueb.gr>
 <CAC20D2Nz-ofwD41vULF2-TL8-C33heCiHvoNNbcuj6GGKhtKzQ@mail.gmail.com>
 <20190913221345.GA16129@minnie.tuhs.org>
 <CAC20D2OQD-NJaFsqsLVL_kqmCsSeUOKAr7dm71P4uN9N8m+AbQ@mail.gmail.com>
 <20190914020240.GO2046@mcvoy.com>
 <20190914024433.GA19193@minnie.tuhs.org>
 <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org>
 <201909150654.x8F6sChG021185@freefriends.org>
 <27f52737-3e3b-1198-7ed4-6b97a5f19938@andrewnesbit.org>
Message-ID: <201909150746.x8F7kjsq023119@freefriends.org>

Hi.

"U'll Be King of the Stars" <ullbeking at andrewnesbit.org> wrote:

> AS for authoring DocBook I was depending on GNU Emacs to do a lot of the 
> heavy XML stuff for me.  Wishful thinking perhaps.

Possibly. I use gvim. :-)  And, no, I won't start _that_ discussion.
To each his own, live and let live.

> > I have written books in troff, DocBook
> > and Texinfo.  Texinfo is *by far* the superior markup language.
>
> I've had a feeling that Texinfo has been getting brushed to the side.

It is actively maintained and developed.

> Are you suggesting that Info is a good as a rendered documentation 
> format?  Or just that Texinfo is good for proto-documents that are to be 
> authored in a parseable and meaningful format?

The latter.

> Moreover it was (is?) very difficult to generate good contents and index 
> pages with the official tools that I used at the time.

For _printed_ matter, the current texinfo does fine at table of
contents.  The upcoming version of texinfo (in prerelease now) has
new indexing capabilities that bring it on par with what you see
in commercial publishing: multilevel indexing, as well as "see" and
"see also" entries.

I agree that Info isn't lovely; I prefer to read the generated HTML
from makeinfo, or the PDF from texi2pdf.

> I have read the Texinfo documentation and I agree that it seemed like a 
> rich markup language.

Much of the growth in the markup language has been at my urging
over the years. :-)

> *I haven't really looked at eqn beyond browsing docs and I'm not sure 
> how much I should expect from it.*

eqn is the inspiration for math mode in TeX.  That's very clear,
and Knuth was also aware of tbl.

> > My own wish for the next genie in a lamp that I come across would be
> > for a texinfo --> troff translator.
>
> Have you looked at Pandoc?  I don't know if it will do this but it's 
> worth checking out.

Thanks for that pointer. I'll have to take a look at it.

Arnold

From doug at cs.dartmouth.edu  Mon Sep 16 02:17:52 2019
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Sun, 15 Sep 2019 12:17:52 -0400
Subject: [TUHS] user-level v1
Message-ID: <201909151617.x8FGHqGu100607@tahoe.cs.Dartmouth.EDU>

The TUHS archive does not include /usr/src for v1. Does it
exist anywhere?

doug

From jon at fourwinds.com  Mon Sep 16 02:17:56 2019
From: jon at fourwinds.com (Jon Steinhart)
Date: Sun, 15 Sep 2019 09:17:56 -0700
Subject: [TUHS] earliest Unix roff
In-Reply-To: <alpine.BSF.2.21.9999.1909151658220.18105@aneurin.horsfall.org>
References: <CAC20D2NmXGzN7imTKy-RRWRZ2ewWMEmUV9oDuP3-e3a4R+ynpA@mail.gmail.com>
 <CAC20D2PXYWpv-8BQNKvUjgT=2W81GgzaOLyZiQ5=sM9+LXCWnw@mail.gmail.com>
 <CAC20D2MDbmoeMZq1esbuQvOCU7to0dUWsFyx98UQDLE3-c4fOA@mail.gmail.com>
 <201909132024.x8DKObEP013266@darkstar.fourwinds.com>
 <CAC20D2PvA26HMoABOcLMoS9Lu8=L3Wtx_8yK83K+vbhoMZt-hQ@mail.gmail.com>
 <463d5cc4-9bef-9ac3-a680-a5161d664dc1@aueb.gr>
 <CAC20D2Nz-ofwD41vULF2-TL8-C33heCiHvoNNbcuj6GGKhtKzQ@mail.gmail.com>
 <20190913221345.GA16129@minnie.tuhs.org>
 <CAC20D2OQD-NJaFsqsLVL_kqmCsSeUOKAr7dm71P4uN9N8m+AbQ@mail.gmail.com>
 <20190914020240.GO2046@mcvoy.com> <20190914024433.GA19193@minnie.tuhs.org>
 <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org>
 <201909150654.x8F6sChG021185@freefriends.org>
 <alpine.BSF.2.21.9999.1909151658220.18105@aneurin.horsfall.org>
Message-ID: <201909151617.x8FGHusM008290@darkstar.fourwinds.com>

Dave Horsfall writes:
> On Sun, 15 Sep 2019, arnold at skeeve.com wrote:
>
> > The MM macros are the most capable of the standard sets that are out 
> > there, although possibly the MOM macros distributed with groff are even 
> > more so; I have not investigated fully.
>
> For some reason I prefer the MS macros, probably because I learnt them 
> first and I find it difficult to use MM.
>
> -- Dave

I am also a MS fan.  Tektronix did their own version of MS that added a ton
of really nice features.  Would be nice if someone could share that since
Tek is long gone and probably doesn't care.

Jon

From ron at ronnatalie.com  Mon Sep 16 03:23:30 2019
From: ron at ronnatalie.com (Ronald Natalie)
Date: Sun, 15 Sep 2019 13:23:30 -0400
Subject: [TUHS] earliest Unix roff
In-Reply-To: <201909151617.x8FGHusM008290@darkstar.fourwinds.com>
References: <CAC20D2NmXGzN7imTKy-RRWRZ2ewWMEmUV9oDuP3-e3a4R+ynpA@mail.gmail.com>
 <CAC20D2PXYWpv-8BQNKvUjgT=2W81GgzaOLyZiQ5=sM9+LXCWnw@mail.gmail.com>
 <CAC20D2MDbmoeMZq1esbuQvOCU7to0dUWsFyx98UQDLE3-c4fOA@mail.gmail.com>
 <201909132024.x8DKObEP013266@darkstar.fourwinds.com>
 <CAC20D2PvA26HMoABOcLMoS9Lu8=L3Wtx_8yK83K+vbhoMZt-hQ@mail.gmail.com>
 <463d5cc4-9bef-9ac3-a680-a5161d664dc1@aueb.gr>
 <CAC20D2Nz-ofwD41vULF2-TL8-C33heCiHvoNNbcuj6GGKhtKzQ@mail.gmail.com>
 <20190913221345.GA16129@minnie.tuhs.org>
 <CAC20D2OQD-NJaFsqsLVL_kqmCsSeUOKAr7dm71P4uN9N8m+AbQ@mail.gmail.com>
 <20190914020240.GO2046@mcvoy.com> <20190914024433.GA19193@minnie.tuhs.org>
 <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org>
 <201909150654.x8F6sChG021185@freefriends.org>
 <alpine.BSF.2.21.9999.1909151658220.18105@aneurin.horsfall.org>
 <201909151617.x8FGHusM008290@darkstar.fourwinds.com>
Message-ID: <D00518CB-6366-42BB-96C0-9C0A77164449@ronnatalie.com>

ROFF is the simplest of the runoff programs but is utterly frozen.

I started with the -ms macro package so I had fondness for it, but switched to -mm over time.     I had done some work (after not being able to pry a version Dennis Mumaugh had written out of the agency) on putting classification marking and formatting in it.    I had restyled it to make the output look like the standard IBM formatting when we were doing UNIX work under contract for IBM.

At Hopkins, we had a small furor when Mike (Michael John) Muuss wrote his own macro package and installed it as tmac.jm (invoked by the -mjm option).   This led to lots of jokes about renaming programs and options after various users.


From clemc at ccc.com  Mon Sep 16 05:27:10 2019
From: clemc at ccc.com (Clem Cole)
Date: Sun, 15 Sep 2019 15:27:10 -0400
Subject: [TUHS] earliest Unix roff
In-Reply-To: <20190914024433.GA19193@minnie.tuhs.org>
References: <CAC20D2NmXGzN7imTKy-RRWRZ2ewWMEmUV9oDuP3-e3a4R+ynpA@mail.gmail.com>
 <CAC20D2PXYWpv-8BQNKvUjgT=2W81GgzaOLyZiQ5=sM9+LXCWnw@mail.gmail.com>
 <CAC20D2MDbmoeMZq1esbuQvOCU7to0dUWsFyx98UQDLE3-c4fOA@mail.gmail.com>
 <201909132024.x8DKObEP013266@darkstar.fourwinds.com>
 <CAC20D2PvA26HMoABOcLMoS9Lu8=L3Wtx_8yK83K+vbhoMZt-hQ@mail.gmail.com>
 <463d5cc4-9bef-9ac3-a680-a5161d664dc1@aueb.gr>
 <CAC20D2Nz-ofwD41vULF2-TL8-C33heCiHvoNNbcuj6GGKhtKzQ@mail.gmail.com>
 <20190913221345.GA16129@minnie.tuhs.org>
 <CAC20D2OQD-NJaFsqsLVL_kqmCsSeUOKAr7dm71P4uN9N8m+AbQ@mail.gmail.com>
 <20190914020240.GO2046@mcvoy.com> <20190914024433.GA19193@minnie.tuhs.org>
Message-ID: <CAC20D2OrC4sPPhnX2YpGKexRv4zei5WNpknE-KdMJ2TmfrRXQA@mail.gmail.com>

Warren,

On Fri, Sep 13, 2019 at 10:44 PM Warren Toomey <wkt at tuhs.org> wrote:

>
> Here's a good page on the history:
> https://manpages.bsd.lv/history.html

Excellent - thanks for the pointer.   This shows nroff before troff.
 FWIW: I guess I was miss informed, but I had been under the impression
that was the other way around.  i.e. nroff was done to be compliant with
the new troff, replacing roff, although the suggestion here is that he
wrote it add macros to roff.  I'll note that either way, the dates are all
possible of course because the U/L case ASR 37 was introduced 1968 so by
the early 1970's they would have been around the labs.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190915/65f3fc4d/attachment.html>

From jon at fourwinds.com  Mon Sep 16 05:31:53 2019
From: jon at fourwinds.com (Jon Steinhart)
Date: Sun, 15 Sep 2019 12:31:53 -0700
Subject: [TUHS] earliest Unix roff
In-Reply-To: <CAC20D2OrC4sPPhnX2YpGKexRv4zei5WNpknE-KdMJ2TmfrRXQA@mail.gmail.com>
References: <CAC20D2NmXGzN7imTKy-RRWRZ2ewWMEmUV9oDuP3-e3a4R+ynpA@mail.gmail.com>
 <CAC20D2PXYWpv-8BQNKvUjgT=2W81GgzaOLyZiQ5=sM9+LXCWnw@mail.gmail.com>
 <CAC20D2MDbmoeMZq1esbuQvOCU7to0dUWsFyx98UQDLE3-c4fOA@mail.gmail.com>
 <201909132024.x8DKObEP013266@darkstar.fourwinds.com>
 <CAC20D2PvA26HMoABOcLMoS9Lu8=L3Wtx_8yK83K+vbhoMZt-hQ@mail.gmail.com>
 <463d5cc4-9bef-9ac3-a680-a5161d664dc1@aueb.gr>
 <CAC20D2Nz-ofwD41vULF2-TL8-C33heCiHvoNNbcuj6GGKhtKzQ@mail.gmail.com>
 <20190913221345.GA16129@minnie.tuhs.org>
 <CAC20D2OQD-NJaFsqsLVL_kqmCsSeUOKAr7dm71P4uN9N8m+AbQ@mail.gmail.com>
 <20190914020240.GO2046@mcvoy.com> <20190914024433.GA19193@minnie.tuhs.org>
 <CAC20D2OrC4sPPhnX2YpGKexRv4zei5WNpknE-KdMJ2TmfrRXQA@mail.gmail.com>
Message-ID: <201909151931.x8FJVrPH011881@darkstar.fourwinds.com>

Clem Cole writes:
> Excellent - thanks for the pointer.   This shows nroff before troff.
>  FWIW: I guess I was miss informed, but I had been under the impression
> that was the other way around.  i.e. nroff was done to be compliant with
> the new troff, replacing roff, although the suggestion here is that he
> wrote it add macros to roff.  I'll note that either way, the dates are all
> possible of course because the U/L case ASR 37 was introduced 1968 so by
> the early 1970's they would have been around the labs.

Yes, we had ASR 37s, used one myself.  Not only did the do upper and lower
case, but they also did Greek and math characters, had bracket building
characters, and so on.  Biggest problem was line noise since these were
mostly on dial-up.  One could be having a nice day and all of a sudden a
burst of line noise would trigger a shift-out and everything would be
gibberish.

From clemc at ccc.com  Mon Sep 16 05:35:52 2019
From: clemc at ccc.com (Clem Cole)
Date: Sun, 15 Sep 2019 15:35:52 -0400
Subject: [TUHS] earliest Unix roff
In-Reply-To: <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org>
References: <CAC20D2NmXGzN7imTKy-RRWRZ2ewWMEmUV9oDuP3-e3a4R+ynpA@mail.gmail.com>
 <CAC20D2PXYWpv-8BQNKvUjgT=2W81GgzaOLyZiQ5=sM9+LXCWnw@mail.gmail.com>
 <CAC20D2MDbmoeMZq1esbuQvOCU7to0dUWsFyx98UQDLE3-c4fOA@mail.gmail.com>
 <201909132024.x8DKObEP013266@darkstar.fourwinds.com>
 <CAC20D2PvA26HMoABOcLMoS9Lu8=L3Wtx_8yK83K+vbhoMZt-hQ@mail.gmail.com>
 <463d5cc4-9bef-9ac3-a680-a5161d664dc1@aueb.gr>
 <CAC20D2Nz-ofwD41vULF2-TL8-C33heCiHvoNNbcuj6GGKhtKzQ@mail.gmail.com>
 <20190913221345.GA16129@minnie.tuhs.org>
 <CAC20D2OQD-NJaFsqsLVL_kqmCsSeUOKAr7dm71P4uN9N8m+AbQ@mail.gmail.com>
 <20190914020240.GO2046@mcvoy.com> <20190914024433.GA19193@minnie.tuhs.org>
 <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org>
Message-ID: <CAC20D2M5j+pCBpxf4Cy-sK4BfBGj_RMhzSpGaXMZmeEaGV9cDA@mail.gmail.com>

On Sat, Sep 14, 2019 at 11:03 PM U'll Be King of the Stars <
ullbeking at andrewnesbit.org> wrote:

>
> I've been wondering whether it is possible and worthwhile to use *roff
> for complex technical documentation.  I've always loved the aesthetic
> that books produced using *roff have but there are other reasons too.
>
Ditto.  The books that used roff can look clean and within a series are
usually consistent, but what I've like is that they are different.
The Prentiss-Hall series and the ORA books both were produced using troff
and different versions of ms, but the results are different.

One of my complained with LaTex books is they all seem to look the same.


> Getting back to *roff, does anybody know if there is a (hopefully rich)
> repository of macros, or any other resources, for my use case?
>
I've never seen one.   As far as I knew it, publishers sometimes seeded
authors.  ORA used the Masscomp/Tektronix derived version of ms (-mS) that
Steve Talbot created (and Rick LeFaivre originally created from the
original Lesk V7 set).   Rich Steven's has his own additions to the version
of ms that came with groff which I have also seen.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190915/bd08ac26/attachment.html>

From clemc at ccc.com  Mon Sep 16 05:37:39 2019
From: clemc at ccc.com (Clem Cole)
Date: Sun, 15 Sep 2019 15:37:39 -0400
Subject: [TUHS] earliest Unix roff
In-Reply-To: <201909150654.x8F6sChG021185@freefriends.org>
References: <CAC20D2NmXGzN7imTKy-RRWRZ2ewWMEmUV9oDuP3-e3a4R+ynpA@mail.gmail.com>
 <CAC20D2PXYWpv-8BQNKvUjgT=2W81GgzaOLyZiQ5=sM9+LXCWnw@mail.gmail.com>
 <CAC20D2MDbmoeMZq1esbuQvOCU7to0dUWsFyx98UQDLE3-c4fOA@mail.gmail.com>
 <201909132024.x8DKObEP013266@darkstar.fourwinds.com>
 <CAC20D2PvA26HMoABOcLMoS9Lu8=L3Wtx_8yK83K+vbhoMZt-hQ@mail.gmail.com>
 <463d5cc4-9bef-9ac3-a680-a5161d664dc1@aueb.gr>
 <CAC20D2Nz-ofwD41vULF2-TL8-C33heCiHvoNNbcuj6GGKhtKzQ@mail.gmail.com>
 <20190913221345.GA16129@minnie.tuhs.org>
 <CAC20D2OQD-NJaFsqsLVL_kqmCsSeUOKAr7dm71P4uN9N8m+AbQ@mail.gmail.com>
 <20190914020240.GO2046@mcvoy.com> <20190914024433.GA19193@minnie.tuhs.org>
 <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org>
 <201909150654.x8F6sChG021185@freefriends.org>
Message-ID: <CAC20D2PfLq=J5ei+izXb2J7dSvU6=L6-GRd0gKA2ShSNg1=qBg@mail.gmail.com>

On Sun, Sep 15, 2019 at 2:55 AM <arnold at skeeve.com> wrote:

> Texinfo is *by far* the superior markup language.
>
I'll take your work for it, but my complaint is it requires emacs to use as
the pager on my screen.  If you live in emacs, that makes sense; but most
people, even in the GNU/Linux world, don't.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190915/687ac8b3/attachment-0001.html>

From clemc at ccc.com  Mon Sep 16 05:48:05 2019
From: clemc at ccc.com (Clem Cole)
Date: Sun, 15 Sep 2019 15:48:05 -0400
Subject: [TUHS] earliest Unix roff
In-Reply-To: <alpine.BSF.2.21.9999.1909151658220.18105@aneurin.horsfall.org>
References: <CAC20D2NmXGzN7imTKy-RRWRZ2ewWMEmUV9oDuP3-e3a4R+ynpA@mail.gmail.com>
 <CAC20D2PXYWpv-8BQNKvUjgT=2W81GgzaOLyZiQ5=sM9+LXCWnw@mail.gmail.com>
 <CAC20D2MDbmoeMZq1esbuQvOCU7to0dUWsFyx98UQDLE3-c4fOA@mail.gmail.com>
 <201909132024.x8DKObEP013266@darkstar.fourwinds.com>
 <CAC20D2PvA26HMoABOcLMoS9Lu8=L3Wtx_8yK83K+vbhoMZt-hQ@mail.gmail.com>
 <463d5cc4-9bef-9ac3-a680-a5161d664dc1@aueb.gr>
 <CAC20D2Nz-ofwD41vULF2-TL8-C33heCiHvoNNbcuj6GGKhtKzQ@mail.gmail.com>
 <20190913221345.GA16129@minnie.tuhs.org>
 <CAC20D2OQD-NJaFsqsLVL_kqmCsSeUOKAr7dm71P4uN9N8m+AbQ@mail.gmail.com>
 <20190914020240.GO2046@mcvoy.com> <20190914024433.GA19193@minnie.tuhs.org>
 <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org>
 <201909150654.x8F6sChG021185@freefriends.org>
 <alpine.BSF.2.21.9999.1909151658220.18105@aneurin.horsfall.org>
Message-ID: <CAC20D2Nt=h71YJw-tU+OB_tZKzv26+BJYgsKLAJFOLzA4sbPXg@mail.gmail.com>

I learn runoff from the IBM and the TOPS, then PUB then Scribe before I saw
the nroff/troff family.
I have fond memories of using Scribe (which was sort of the model for the
LaTex macros when it got tied up in the legal entanglements of CMU).   So
UNIX was what I had and became adept at it.

Like Larry, it's still my goto today and even prefer to Word for anything
over a single page.

On Sun, Sep 15, 2019 at 3:01 AM Dave Horsfall <dave at horsfall.org> wrote:

> For some reason I prefer the MS macros, probably because I learnt them
> first and I find it difficult to use MM.
>
The order I learned them was -mm {PWB}, -ms {V7}, -man {V7}, -ms {Tek}, -me
{UCB}, -mS {MSCP}, -man {UCB version}.   I feel into -ms with a couple of
macros from -mS (.Li/Le for lists which were similar to MM's) for big
documents, and the UCB -man for really simple things.   It becomes a 'less
is more' sort of thing - -mm and too complicated and I was not writing BTL
tech memos, and after I did not my thesis, I did not need Eric's work
(which was perfect for a UCB thesis).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190915/a280d7f6/attachment.html>

From wkt at tuhs.org  Mon Sep 16 06:11:03 2019
From: wkt at tuhs.org (Warren Toomey)
Date: Mon, 16 Sep 2019 06:11:03 +1000
Subject: [TUHS] user-level v1
In-Reply-To: <201909151617.x8FGHqGu100607@tahoe.cs.Dartmouth.EDU>
References: <201909151617.x8FGHqGu100607@tahoe.cs.Dartmouth.EDU>
Message-ID: <20190915201103.GA25340@minnie.tuhs.org>

On Sun, Sep 15, 2019 at 12:17:52PM -0400, Doug McIlroy wrote:
> The TUHS archive does not include /usr/src for v1. Does it
> exist anywhere?

We've not been able to find it, no :-(

Cheers Doug,
	Warren

From clemc at ccc.com  Mon Sep 16 06:12:17 2019
From: clemc at ccc.com (Clem Cole)
Date: Sun, 15 Sep 2019 16:12:17 -0400
Subject: [TUHS] a book (was Re: PWB vs Unix/TS)
In-Reply-To: <d7377aaf-9342-9c8f-9ea7-24c11ab3be4e@neophilic.com>
References: <CANCZdfpEu6OxvmhDGSa3Cw4TSpfcbBOFbJjU7nZU-C_JFGFdRA@mail.gmail.com>
 <CAC20D2Pz+gwyeuVYcHFbJaimHtrt+sKSvCFp=hMZNoAWr4G09Q@mail.gmail.com>
 <alpine.NEB.2.21.1909101307530.11702@t1.m.reedmedia.net>
 <B2F032E8-E51B-4E58-AA8F-33BE5B7AD75F@ccc.com>
 <CAP2nic3L1bVPvgX7yshrHxkhqd24otdUQO8g_ayFRXVbFZJ0Dg@mail.gmail.com>
 <d7377aaf-9342-9c8f-9ea7-24c11ab3be4e@neophilic.com>
Message-ID: <CAC20D2OgO5WCd-qgvvArbvOCFHsJ-m4o9vQf0hLJzDVKkMJSGg@mail.gmail.com>

On Sun, Sep 15, 2019 at 12:16 AM Eric Allman <tuhs at eric.allman.name> wrote:

> On 2019-09-14 17:58, Adam Thornton wrote:
> > I...have never been all that impressed with Salus's work.  It's not
> _bad_ but it's also not terribly insightful.
> I think Peter's work was an amazing effort to collect and disseminate
> facts, and despite a few gaps (inevitable) he did a great job.  But
> Peter's works were more collections of facts than attempts to interpret,
> contextualize, or otherwise put the facts into a larger narrative.

+1 Amen, bro.
For many of us that lived the time he covered, which was the first 25
years, it's awesome and frankly, I don't look for it for insights, as that
was to me not what he was after doing.  He was trying to create a
narrative that documented what happened.   Yes, he left things out, but
pretty much go it right.

> Honest historians can disagree on the role of written histories.  A pure
> "just the facts ma'am" history avoids context and interpretation but
> tends to be fairly dry.  This was Peter's approach.

I agree.  Moreover, as Jon points out, I'm not sure even if was made widely
available, other than people like those on this list, I'm not sure it will
be really that interesting.



> But it's impossible to completely avoid bias because you have to pick and

choose the facts you include.

And this is the biggest issue.  And I have observed (maybe I'm wrong - but
it seems to me ...) that the people that I know today, that dislike Peter's
work dislike that Linux is not huge part of it.   Or more importantly that
it was the emergence of the *Internet and UNIX that were enablers for Linux*.
 As Jon has suggested, it should not be Gnu/Linux but rather Internet/Linux.

Contextualizing history inevitably leads to interpretation
> which leads to some amount of bias, but interesting or even gripping
> histories read like a novel that unfolds before you.

*i.e.* Peter is not David McCullough and we don't seem to have David coming
to us to write his next book.

I've believed for a long time that when the definitive history of Unix
> is written, Peter's books will be a major (albeit not "primary", in the
> technical sense) source material.

Absolutely.  It needs to be the place where a historian starts.

I salute him for all his hard (and early) work.  I hope that someone will
> step

up to do this larger history (much of which happened after Peter's
> publication

dates) before we all die off.

+1 A louder *amen*....

> And I have to say, It looks like Warner's research (with all the
> abundant help from this group) the last week or two is amazing.

I agree - as much as I offered some additions and corrections it is well
done -- thank you, Warner.



> .... I deeply regret that I never had an opportunity to meet Joe Ossanna.

Indeed.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190915/9a2bfb09/attachment.html>

From clemc at ccc.com  Mon Sep 16 06:14:58 2019
From: clemc at ccc.com (Clem Cole)
Date: Sun, 15 Sep 2019 16:14:58 -0400
Subject: [TUHS] a book (was Re: PWB vs Unix/TS)
In-Reply-To: <201909150517.x8F5HLfa009023@darkstar.fourwinds.com>
References: <CANCZdfpEu6OxvmhDGSa3Cw4TSpfcbBOFbJjU7nZU-C_JFGFdRA@mail.gmail.com>
 <CAC20D2Pz+gwyeuVYcHFbJaimHtrt+sKSvCFp=hMZNoAWr4G09Q@mail.gmail.com>
 <alpine.NEB.2.21.1909101307530.11702@t1.m.reedmedia.net>
 <B2F032E8-E51B-4E58-AA8F-33BE5B7AD75F@ccc.com>
 <CAP2nic3L1bVPvgX7yshrHxkhqd24otdUQO8g_ayFRXVbFZJ0Dg@mail.gmail.com>
 <d7377aaf-9342-9c8f-9ea7-24c11ab3be4e@neophilic.com>
 <20190915042117.GW2046@mcvoy.com>
 <201909150517.x8F5HLfa009023@darkstar.fourwinds.com>
Message-ID: <CAC20D2OQ9+dw6hmwSmYJwz3XBY55WR=U0F+0e+vpXAH2ujp_cw@mail.gmail.com>

On Sun, Sep 15, 2019 at 1:18 AM Jon Steinhart <jon at fourwinds.com> wrote:

> Way back in the 80s when scheduling was new I wrote tools that generated
> pert and gantt charts via pic.
>
We did the same thing at Masscomp.
Then Danny Klein wrote a very cool Mac program that spit out pic (before
xfig existed).



>
> The power of little and languages and composability lives on!

Right...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190915/69e5cd53/attachment.html>

From jon at fourwinds.com  Mon Sep 16 06:21:00 2019
From: jon at fourwinds.com (Jon Steinhart)
Date: Sun, 15 Sep 2019 13:21:00 -0700
Subject: [TUHS] a book (was Re: PWB vs Unix/TS)
In-Reply-To: <CAC20D2OQ9+dw6hmwSmYJwz3XBY55WR=U0F+0e+vpXAH2ujp_cw@mail.gmail.com>
References: <CANCZdfpEu6OxvmhDGSa3Cw4TSpfcbBOFbJjU7nZU-C_JFGFdRA@mail.gmail.com>
 <CAC20D2Pz+gwyeuVYcHFbJaimHtrt+sKSvCFp=hMZNoAWr4G09Q@mail.gmail.com>
 <alpine.NEB.2.21.1909101307530.11702@t1.m.reedmedia.net>
 <B2F032E8-E51B-4E58-AA8F-33BE5B7AD75F@ccc.com>
 <CAP2nic3L1bVPvgX7yshrHxkhqd24otdUQO8g_ayFRXVbFZJ0Dg@mail.gmail.com>
 <d7377aaf-9342-9c8f-9ea7-24c11ab3be4e@neophilic.com>
 <20190915042117.GW2046@mcvoy.com>
 <201909150517.x8F5HLfa009023@darkstar.fourwinds.com>
 <CAC20D2OQ9+dw6hmwSmYJwz3XBY55WR=U0F+0e+vpXAH2ujp_cw@mail.gmail.com>
Message-ID: <201909152021.x8FKL0nM019888@darkstar.fourwinds.com>

Clem Cole writes:
>
> On Sun, Sep 15, 2019 at 1:18 AM Jon Steinhart <jon at fourwinds.com> wrote:
>
> > Way back in the 80s when scheduling was new I wrote tools that generated
> > pert and gantt charts via pic.
> >
> We did the same thing at Masscomp.
> Then Danny Klein wrote a very cool Mac program that spit out pic (before
> xfig existed).

The big problem with xfig (and fig befoe that) is that it didn't utilize
what to me is one of the most important features of pic which is invisible
elements.  When I do a complicated diagram, I start with an invisible box
and hang the diagram on it.  That way, if I run out of space or need to
make other adjustments I can just change the size of that invisible box
scaffold.  Sure beats stuff done in absolute coordinates by (x)fig or even
many other modern drawing programs where everything has to be manually
moved around and scaled.

Jon

From ullbeking at andrewnesbit.org  Mon Sep 16 06:49:37 2019
From: ullbeking at andrewnesbit.org (U'll Be King of the Stars)
Date: Sun, 15 Sep 2019 21:49:37 +0100
Subject: [TUHS] earliest Unix roff
In-Reply-To: <CAC20D2M5j+pCBpxf4Cy-sK4BfBGj_RMhzSpGaXMZmeEaGV9cDA@mail.gmail.com>
References: <CAC20D2NmXGzN7imTKy-RRWRZ2ewWMEmUV9oDuP3-e3a4R+ynpA@mail.gmail.com>
 <CAC20D2PXYWpv-8BQNKvUjgT=2W81GgzaOLyZiQ5=sM9+LXCWnw@mail.gmail.com>
 <CAC20D2MDbmoeMZq1esbuQvOCU7to0dUWsFyx98UQDLE3-c4fOA@mail.gmail.com>
 <201909132024.x8DKObEP013266@darkstar.fourwinds.com>
 <CAC20D2PvA26HMoABOcLMoS9Lu8=L3Wtx_8yK83K+vbhoMZt-hQ@mail.gmail.com>
 <463d5cc4-9bef-9ac3-a680-a5161d664dc1@aueb.gr>
 <CAC20D2Nz-ofwD41vULF2-TL8-C33heCiHvoNNbcuj6GGKhtKzQ@mail.gmail.com>
 <20190913221345.GA16129@minnie.tuhs.org>
 <CAC20D2OQD-NJaFsqsLVL_kqmCsSeUOKAr7dm71P4uN9N8m+AbQ@mail.gmail.com>
 <20190914020240.GO2046@mcvoy.com> <20190914024433.GA19193@minnie.tuhs.org>
 <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org>
 <CAC20D2M5j+pCBpxf4Cy-sK4BfBGj_RMhzSpGaXMZmeEaGV9cDA@mail.gmail.com>
Message-ID: <069494b2-ec5b-91e7-8618-2d111e0e5aa2@andrewnesbit.org>

On 15/09/2019 20:35, Clem Cole wrote:
> 
> 
> On Sat, Sep 14, 2019 at 11:03 PM U'll Be King of the Stars 
> <ullbeking at andrewnesbit.org <mailto:ullbeking at andrewnesbit.org>> wrote:
> 
> 
>     I've been wondering whether it is possible and worthwhile to use *roff
>     for complex technical documentation.  I've always loved the aesthetic
>     that books produced using *roff have but there are other reasons too.
> 
> Ditto.  The books that used roff can look clean and within a series are 
> usually consistent, but what I've like is that they are different.

Yes, they look clean but different to each other.

I'm guessing that the reason might be that it is easier to exercise 
*roff's capabilities than it is to push LaTeX to get good results 
without spending a huge amount of time.

> The Prentiss-Hall series and the ORA books both were produced using 
> troff and different versions of ms, but the results are different.

I wonder if Prentice-Hall and O'Reilly & Associates might be willing to 
share their *roff macro sets in an open source way.

> One of my complained with LaTex books is they all seem to look the same.

Don't they ever?!  It has gotten to the point that Computer Modern 
actually makes me feel *fatigued* when I encounter it when reading, say, 
a mathematics monograph.

On the other hand it's the perfect typeface for résumés and CV's for 
computer scientists.  Like a secret handshake.

Perhaps the reason that the CM typeface is so common is that changing 
typefaces in LaTeX is complicated and difficult so authors leave it 
alone.  At least this has been my experience.

>     Getting back to *roff, does anybody know if there is a (hopefully rich)
>     repository of macros, or any other resources, for my use case?
> 
> I've never seen one.   As far as I knew it, publishers sometimes seeded 
> authors.  ORA used the Masscomp/Tektronix derived version of ms (-mS) 
> that Steve Talbot created (and Rick LeFaivre originally created from the 
> original Lesk V7 set).   Rich Steven's has his own additions to the 
> version of ms that came with groff which I have also seen.

This is fascinating insider information, and it leads me full circle to 
several reasons why I want to try to use *roff in the first place:

1.  Do you think there is any chance of obtaining these macro packages? 
Either from authors who haven't passed away, or from the publishing 
houses themselves?

2.  I get the impression that writing a macro package or editing an 
existing is relatively straightforward.  Would you agree?

     Or, at least, that it makes some kind of sense.  I could never make 
head or tail of LaTeX's macro extensions.  I certainly didn't want to 
spend my life trying to figure it out.

     I still remember the sinking feeling in my stomach when I realized 
that the five (or so) books that make up the de facto canon of LaTeX 
user documentation (published by Addison-Wesley) are thousands of pages 
in total.  I did not want to engage with that.

I have no particular intention to speak ill of LaTeX.  Rather, it is my 
only point of reference for publishing-grade typesetting and 
unfortunately I don't have fond memories of it.

Kind regards,

Andrew
-- 
OpenPGP key: EB28 0338 28B7 19DA DAB0  B193 D21D 996E 883B E5B9

From dave at horsfall.org  Mon Sep 16 07:16:48 2019
From: dave at horsfall.org (Dave Horsfall)
Date: Mon, 16 Sep 2019 07:16:48 +1000 (EST)
Subject: [TUHS] earliest Unix roff
In-Reply-To: <CAC20D2Nt=h71YJw-tU+OB_tZKzv26+BJYgsKLAJFOLzA4sbPXg@mail.gmail.com>
References: <CAC20D2NmXGzN7imTKy-RRWRZ2ewWMEmUV9oDuP3-e3a4R+ynpA@mail.gmail.com>
 <CAC20D2PXYWpv-8BQNKvUjgT=2W81GgzaOLyZiQ5=sM9+LXCWnw@mail.gmail.com>
 <CAC20D2MDbmoeMZq1esbuQvOCU7to0dUWsFyx98UQDLE3-c4fOA@mail.gmail.com>
 <201909132024.x8DKObEP013266@darkstar.fourwinds.com>
 <CAC20D2PvA26HMoABOcLMoS9Lu8=L3Wtx_8yK83K+vbhoMZt-hQ@mail.gmail.com>
 <463d5cc4-9bef-9ac3-a680-a5161d664dc1@aueb.gr>
 <CAC20D2Nz-ofwD41vULF2-TL8-C33heCiHvoNNbcuj6GGKhtKzQ@mail.gmail.com>
 <20190913221345.GA16129@minnie.tuhs.org>
 <CAC20D2OQD-NJaFsqsLVL_kqmCsSeUOKAr7dm71P4uN9N8m+AbQ@mail.gmail.com>
 <20190914020240.GO2046@mcvoy.com> <20190914024433.GA19193@minnie.tuhs.org>
 <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org>
 <201909150654.x8F6sChG021185@freefriends.org>
 <alpine.BSF.2.21.9999.1909151658220.18105@aneurin.horsfall.org>
 <CAC20D2Nt=h71YJw-tU+OB_tZKzv26+BJYgsKLAJFOLzA4sbPXg@mail.gmail.com>
Message-ID: <alpine.BSF.2.21.9999.1909160711540.18105@aneurin.horsfall.org>

On Sun, 15 Sep 2019, Clem Cole wrote:

> The order I learned them was -mm {PWB}, -ms {V7}, -man {V7}, -ms {Tek}, 
> -me {UCB}, -mS {MSCP}, -man {UCB version}.   I feel into -ms with a 
> couple of macros from -mS (.Li/Le for lists which were similar to MM's) 
> for big documents, and the UCB -man for really simple things.   It 
> becomes a 'less is more' sort of thing - -mm and too complicated and I 
> was not writing BTL tech memos, and after I did not my thesis, I did not 
> need Eric's work (which was perfect for a UCB thesis).

For me it was ROFF (V5), -man (V6), -ms (V6).  These days I don't need 
markup any more; the most complicated things I write are letters using 
TextEdit on the Mac, and C/Perl/etc with VI :-)

Actually on the odd occasion I need markup it's "groff -ms -Tps" on
the FreeBSD box.

-- Dave

From dave at horsfall.org  Mon Sep 16 07:28:08 2019
From: dave at horsfall.org (Dave Horsfall)
Date: Mon, 16 Sep 2019 07:28:08 +1000 (EST)
Subject: [TUHS] a book (was Re: PWB vs Unix/TS)
In-Reply-To: <CAC20D2OgO5WCd-qgvvArbvOCFHsJ-m4o9vQf0hLJzDVKkMJSGg@mail.gmail.com>
References: <CANCZdfpEu6OxvmhDGSa3Cw4TSpfcbBOFbJjU7nZU-C_JFGFdRA@mail.gmail.com>
 <CAC20D2Pz+gwyeuVYcHFbJaimHtrt+sKSvCFp=hMZNoAWr4G09Q@mail.gmail.com>
 <alpine.NEB.2.21.1909101307530.11702@t1.m.reedmedia.net>
 <B2F032E8-E51B-4E58-AA8F-33BE5B7AD75F@ccc.com>
 <CAP2nic3L1bVPvgX7yshrHxkhqd24otdUQO8g_ayFRXVbFZJ0Dg@mail.gmail.com>
 <d7377aaf-9342-9c8f-9ea7-24c11ab3be4e@neophilic.com>
 <CAC20D2OgO5WCd-qgvvArbvOCFHsJ-m4o9vQf0hLJzDVKkMJSGg@mail.gmail.com>
Message-ID: <alpine.BSF.2.21.9999.1909160724320.18105@aneurin.horsfall.org>

On Sun, 15 Sep 2019, Clem Cole wrote:

> And this is the biggest issue.  And I have observed (maybe I'm wrong - 
> but it seems to me ...) that the people that I know today, that dislike 
> Peter's work dislike that Linux is not huge part of it.   Or more 
> importantly that it was the emergence of the Internet and UNIX that were 
> enablers for Linux.   As Jon has suggested, it should not be Gnu/Linux 
> but rather Internet/Linux.

Indeed, and not a few Linux users hate it being pointed out that Unix was 
first.  If it was not for Unix, we would not have Linux (because you had
to pay for Unix).

And my pet theory is that if it was not for Unix, we would all be running
some version of Windoze, and loving it...

-- Dave

From clemc at ccc.com  Mon Sep 16 07:46:42 2019
From: clemc at ccc.com (Clem Cole)
Date: Sun, 15 Sep 2019 17:46:42 -0400
Subject: [TUHS] My EuroBSDcon talk (preview for commentary)
In-Reply-To: <CANCZdfrK4iFQCWOFP4MoUggpfJVmoJ0dnSg6H0cCi4dop7sVXw@mail.gmail.com>
References: <CANCZdfrK4iFQCWOFP4MoUggpfJVmoJ0dnSg6H0cCi4dop7sVXw@mail.gmail.com>
Message-ID: <CAC20D2Nq+eTQDdft5nW8kKcWFdt9ZK4-5kJX6OcMcYBffk9HGA@mail.gmail.com>

Funny the things you think about at 3 in the AM.

There are two other things missing from Warner's timeline that I think are
important.  A little about the clones and also about the commercial efforts
(which turns out to be related as one might expect).


The first UNIX clone that I know about was a V6 version by Whitesmiths,
called Idris, I want to say in 1977/78.   I believe that Michel's Gien's
Pascal clone that he talked about a year later started out as V6, but
morphed to V7 before he was done (and then later morphed again to become
Chorus in a C++ rewrote).  Mike Malcolm's Thoth (which "Thucks" by the way,
my wife threw out my tee-shirt years ago;-) was a pseudo V6 clone.   I
don't think he tried to recompile V6 code, like he would with his later QNX
efforts (and he wrote it in B, not C), but the model was V6 and he had seen
and/or run V6 at Waterloo.

By the time of V7, the clones do start showing up. Minux which everyone
agreed was original, as well as Mark William's Coherent, which in the end
AT&T backed off. But as Dennis said at the time something to the effect,
that it was not clear they had directly used AT&T sources to build it, as
much as the authors clearly had *seen/had access to UNIX operating and used
it to build Coherent, plus they probably had seen the UNIX sources* at some
point (this was important later when AT&T would make 'Trade Secret' claims).

Idris is interesting in that when Plauger built it, he did get in trouble
at the UDel USENIX when he tried to 'hawk it' and basically was booed (how
he did was as much of a problem as that fact that he did it).  But by that
point, there was another commercial UNIX available.   What's interesting is
that there was not an official V6 redistribution license like there was for
V7; so I'm not 100% sure I know how it was done and I would love to
enlightened.

I know this much of the story.

As I mentioned before the first commercial user of UNIX was Rand
Corporation in LA.  Al Arms of AT&T legal wrote the original $15K/CPU
license for them.   I don't know how many of those licenses were made
available, but I've always been under the impression it was under 10.  Like
a lot of people at the time, this was when the 'glass tty' was just showing
up in force and Rand updated/wrote a version of ed(1) called the rand(1)
editor [IIRC, its still available as the 'grand editor' from Dave Yost].

Shortly thereafter, Peter Weiner and Heinz would create a company in Santa
Monica called, Interactive Systems Corp (ISC) and they provided v6 and copy
of the Rand editor for some commercial folks (FYI - ISC would later do the
original 386/UNIX port for AT&T, IBM and Intel but that's a different
story, and eventually Sun would buy them years later).   In fact, one of
the things the folks at ISC did at the beginning was that they had worked
with Perkin-Elmer and created a version of PE's 'Fox' terminal with
modified ROMs that ran part of the Rand Editor in it [the Fox has a
Motorola 6800 processor in it.  CMU had a lot of the standard ones because
they were $750 in 1978 which was very inexpensive].   Anyway, what would
eventually become the 68000 development team in Austin (Les Crudele, Nick
Trudenick, Tom Grunner et al) used the ISC system and those modified Foxes
as their development system.

What I don't know is how that license worked.   I think what happened was
ISC was selling 'support.'   Motorola (or one of their customers) got a
commercial license from AT&T and then got a support license from ISC with
their additions.  But frankly, I don't know.

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190915/46a94fcb/attachment.html>

From doug at cs.dartmouth.edu  Mon Sep 16 08:07:11 2019
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Sun, 15 Sep 2019 18:07:11 -0400
Subject: [TUHS] earliest Unix roff
Message-ID: <201909152207.x8FM7BiA017274@tahoe.cs.Dartmouth.EDU>

> Excellent - thanks for the pointer.   This shows nroff before troff.
>  FWIW: I guess I was miss informed, but I had been under the impression
> that was the other way around.  i.e. nroff was done to be compliant with
> the new troff, replacing roff, although the suggestion here is that he
> wrote it add macros to roff.  I'll note that either way, the dates are all
> possible of course because the U/L case ASR 37 was introduced 1968 so by
> the early 1970's they would have been around the labs.

nroff was in v2; troff appeared in v4, which incidentally was
typeset in troff.

Because of Joe Ossanna's role in designing the model 37, we
had 37's in the Labs and even in our homes right from the
start of production. But when they went obsolete, they were
a chore to get rid of. As Labs property, they had to be
returned; and picking them up was nobody's priority.
Andy Hall had one on his back porch for a year.

Doug

From dave at horsfall.org  Mon Sep 16 08:09:03 2019
From: dave at horsfall.org (Dave Horsfall)
Date: Mon, 16 Sep 2019 08:09:03 +1000 (EST)
Subject: [TUHS] user-level v1
In-Reply-To: <20190915201103.GA25340@minnie.tuhs.org>
References: <201909151617.x8FGHqGu100607@tahoe.cs.Dartmouth.EDU>
 <20190915201103.GA25340@minnie.tuhs.org>
Message-ID: <alpine.BSF.2.21.9999.1909160802290.18105@aneurin.horsfall.org>

On Mon, 16 Sep 2019, Warren Toomey wrote:

>> The TUHS archive does not include /usr/src for v1. Does it exist 
>> anywhere?
>
> We've not been able to find it, no :-(

Speaking of which, I heard that the curses library was simply ripped out 
of VI and made stand-alone; a rumour goes that the best test suite for 
curses was the game "rogue" :-)  I still play it from time to time, but 
cannot get rog-o-matic to compile on the Mac.

-- Dave

From clemc at ccc.com  Mon Sep 16 09:15:51 2019
From: clemc at ccc.com (Clem cole)
Date: Sun, 15 Sep 2019 19:15:51 -0400
Subject: [TUHS] user-level v1
In-Reply-To: <alpine.BSF.2.21.9999.1909160802290.18105@aneurin.horsfall.org>
References: <201909151617.x8FGHqGu100607@tahoe.cs.Dartmouth.EDU>
 <20190915201103.GA25340@minnie.tuhs.org>
 <alpine.BSF.2.21.9999.1909160802290.18105@aneurin.horsfall.org>
Message-ID: <AFC45890-C786-444F-9635-AD79D03E3228@ccc.com>

Yes, Ken Arnold did both

Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. 

> On Sep 15, 2019, at 6:09 PM, Dave Horsfall <dave at horsfall.org> wrote:
> 
> On Mon, 16 Sep 2019, Warren Toomey wrote:
> 
>>> The TUHS archive does not include /usr/src for v1. Does it exist anywhere?
>> 
>> We've not been able to find it, no :-(
> 
> Speaking of which, I heard that the curses library was simply ripped out of VI and made stand-alone; a rumour goes that the best test suite for curses was the game "rogue" :-)  I still play it from time to time, but cannot get rog-o-matic to compile on the Mac.
> 
> -- Dave

From bakul at bitblocks.com  Mon Sep 16 09:25:17 2019
From: bakul at bitblocks.com (Bakul Shah)
Date: Sun, 15 Sep 2019 16:25:17 -0700
Subject: [TUHS] My EuroBSDcon talk (preview for commentary)
In-Reply-To: Your message of "Sun, 15 Sep 2019 17:46:42 -0400."
 <CAC20D2Nq+eTQDdft5nW8kKcWFdt9ZK4-5kJX6OcMcYBffk9HGA@mail.gmail.com>
References: <CANCZdfrK4iFQCWOFP4MoUggpfJVmoJ0dnSg6H0cCi4dop7sVXw@mail.gmail.com>
 <CAC20D2Nq+eTQDdft5nW8kKcWFdt9ZK4-5kJX6OcMcYBffk9HGA@mail.gmail.com>
Message-ID: <20190915232524.9A5491570CE9@mail.bitblocks.com>

On Sun, 15 Sep 2019 17:46:42 -0400 Clem Cole <clemc at ccc.com> wrote:
>
> The first UNIX clone that I know about was a V6 version by Whitesmiths,
> called Idris, I want to say in 1977/78.   I believe that Michel's Gien's
> Pascal clone that he talked about a year later started out as V6, but
> morphed to V7 before he was done (and then later morphed again to become
> Chorus in a C++ rewrote).  Mike Malcolm's Thoth (which "Thucks" by the way,
> my wife threw out my tee-shirt years ago;-) was a pseudo V6 clone.   I

Acc. to a paper[1] by Cheriton, Malcom and Melen did the
original small run time executive called Thoth. Cheriton
rewrote it to form the kernel of the system described in the
Feb 1979 CACM article. It used memory mapping, swapping. etc.
They also added a filesystem.

Thoth could not have been a clone of v6.  It used message
passing. More RPC than pipes. And it had "teams", where a
"team" is roughly the same as a Unix process (separate address
space) and a Thoth "process" was a thread in that address
space.  root was "*" (instead of "/") and current dir was "@"
(instead ".").  A bigger difference was that it had *nodes* or
files and any file can have sub nodes.  There was no
separation between files and directories.

It was an interesting system and a lot of different things
were tried in it. In 1980-81 timeframe AMD forked off a
separate company called AMC to build microcomputers. They
chose Thoth.  I almost worked there but in the end decided I'd
rather do unix and joined Fortune and soon after AMD came to
its senses and shut AMC down.

[1] https://cs.uwaterloo.ca/research/tr/1979/CS-79-19.pdf

> As I mentioned before the first commercial user of UNIX was Rand
> Corporation in LA.  Al Arms of AT&T legal wrote the original $15K/CPU
> license for them.   I don't know how many of those licenses were made
> available, but I've always been under the impression it was under 10.  Like
> a lot of people at the time, this was when the 'glass tty' was just showing
> up in force and Rand updated/wrote a version of ed(1) called the rand(1)
> editor [IIRC, its still available as the 'grand editor' from Dave Yost].

The Rand editor e had nothing in common with ed(1).  e
descended from NED, a 2D editor, invented by Ned Irons in 1967
and described in "A CRT editing system" CACM Jan 1972.

The "Grand editor", derived from e19 is long gone. Even Dave
gave up on it long ago.  Though you can find a separate
version on the 'Net, also derived from e19.  e with its
multiple windows was a joy to use on a 60 line Ann Arbor
Ambassador terminal. I use acme because it too is a tiling
editor like e. It has some goodies not in e but overall e
was a better experience.

http://www.bitsavers.org/pdf/rand/R-2176-ARPA_The_CRT_Text_Editor_NED_Dec77.pdf

From clemc at ccc.com  Mon Sep 16 09:27:57 2019
From: clemc at ccc.com (Clem cole)
Date: Sun, 15 Sep 2019 19:27:57 -0400
Subject: [TUHS] a book (was Re: PWB vs Unix/TS)
In-Reply-To: <alpine.BSF.2.21.9999.1909160724320.18105@aneurin.horsfall.org>
References: <CANCZdfpEu6OxvmhDGSa3Cw4TSpfcbBOFbJjU7nZU-C_JFGFdRA@mail.gmail.com>
 <CAC20D2Pz+gwyeuVYcHFbJaimHtrt+sKSvCFp=hMZNoAWr4G09Q@mail.gmail.com>
 <alpine.NEB.2.21.1909101307530.11702@t1.m.reedmedia.net>
 <B2F032E8-E51B-4E58-AA8F-33BE5B7AD75F@ccc.com>
 <CAP2nic3L1bVPvgX7yshrHxkhqd24otdUQO8g_ayFRXVbFZJ0Dg@mail.gmail.com>
 <d7377aaf-9342-9c8f-9ea7-24c11ab3be4e@neophilic.com>
 <CAC20D2OgO5WCd-qgvvArbvOCFHsJ-m4o9vQf0hLJzDVKkMJSGg@mail.gmail.com>
 <alpine.BSF.2.21.9999.1909160724320.18105@aneurin.horsfall.org>
Message-ID: <D3DF8E2D-8FD0-46FF-B15A-6B4E874A2776@ccc.com>

Actually the thing that some (maybe many) of the folks you mentioned seem to have the hardest time accepting the Linux is just the modern implementation of Unix.  which i think is sad.  I think Linux is a wonderful piece of work but the developers do need to recognize we’re it came. 

There is a famous line which I wish I knew who said that to paraphrase becomes: “In science we stand on the shoulders of the great people that came before us, but in computer science we try to step on their toes.”

Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. 

> On Sep 15, 2019, at 5:28 PM, Dave Horsfall <dave at horsfall.org> wrote:
> 
>> On Sun, 15 Sep 2019, Clem Cole wrote:
>> 
>> And this is the biggest issue.  And I have observed (maybe I'm wrong - but it seems to me ...) that the people that I know today, that dislike Peter's work dislike that Linux is not huge part of it.   Or more importantly that it was the emergence of the Internet and UNIX that were enablers for Linux.   As Jon has suggested, it should not be Gnu/Linux but rather Internet/Linux.
> 
> Indeed, and not a few Linux users hate it being pointed out that Unix was first.  If it was not for Unix, we would not have Linux (because you had
> to pay for Unix).
> 
> And my pet theory is that if it was not for Unix, we would all be running
> some version of Windoze, and loving it...
> 
> -- Dave

From clemc at ccc.com  Mon Sep 16 09:35:06 2019
From: clemc at ccc.com (Clem cole)
Date: Sun, 15 Sep 2019 19:35:06 -0400
Subject: [TUHS] My EuroBSDcon talk (preview for commentary)
In-Reply-To: <20190915232524.9A5491570CE9@mail.bitblocks.com>
References: <CANCZdfrK4iFQCWOFP4MoUggpfJVmoJ0dnSg6H0cCi4dop7sVXw@mail.gmail.com>
 <CAC20D2Nq+eTQDdft5nW8kKcWFdt9ZK4-5kJX6OcMcYBffk9HGA@mail.gmail.com>
 <20190915232524.9A5491570CE9@mail.bitblocks.com>
Message-ID: <CADA034B-DFEB-4A1B-A7E4-6188A002C02C@ccc.com>

I’m very aware it was message passing.  I’ve run it.  I’ve spoken to mike about it.  They definitely had seen v6.  But as I said I’m not so sure it was a clone.  Again they used B which was popular at Waterloo at the time.


Thanks for the update on the relationship between Ned and rand’s e.  I had thought they used Ed as part of it.   I saw Dave earlier this summer btw and he said he still gets asked about it.  Although he’s working a new hw architecture to fill his days. 

Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. 

> On Sep 15, 2019, at 7:25 PM, Bakul Shah <bakul at bitblocks.com> wrote:
> 
>> On Sun, 15 Sep 2019 17:46:42 -0400 Clem Cole <clemc at ccc.com> wrote:
>> 
>> The first UNIX clone that I know about was a V6 version by Whitesmiths,
>> called Idris, I want to say in 1977/78.   I believe that Michel's Gien's
>> Pascal clone that he talked about a year later started out as V6, but
>> morphed to V7 before he was done (and then later morphed again to become
>> Chorus in a C++ rewrote).  Mike Malcolm's Thoth (which "Thucks" by the way,
>> my wife threw out my tee-shirt years ago;-) was a pseudo V6 clone.   I
> 
> Acc. to a paper[1] by Cheriton, Malcom and Melen did the
> original small run time executive called Thoth. Cheriton
> rewrote it to form the kernel of the system described in the
> Feb 1979 CACM article. It used memory mapping, swapping. etc.
> They also added a filesystem.
> 
> Thoth could not have been a clone of v6.  It used message
> passing. More RPC than pipes. And it had "teams", where a
> "team" is roughly the same as a Unix process (separate address
> space) and a Thoth "process" was a thread in that address
> space.  root was "*" (instead of "/") and current dir was "@"
> (instead ".").  A bigger difference was that it had *nodes* or
> files and any file can have sub nodes.  There was no
> separation between files and directories.
> 
> It was an interesting system and a lot of different things
> were tried in it. In 1980-81 timeframe AMD forked off a
> separate company called AMC to build microcomputers. They
> chose Thoth.  I almost worked there but in the end decided I'd
> rather do unix and joined Fortune and soon after AMD came to
> its senses and shut AMC down.
> 
> [1] https://cs.uwaterloo.ca/research/tr/1979/CS-79-19.pdf
> 
>> As I mentioned before the first commercial user of UNIX was Rand
>> Corporation in LA.  Al Arms of AT&T legal wrote the original $15K/CPU
>> license for them.   I don't know how many of those licenses were made
>> available, but I've always been under the impression it was under 10.  Like
>> a lot of people at the time, this was when the 'glass tty' was just showing
>> up in force and Rand updated/wrote a version of ed(1) called the rand(1)
>> editor [IIRC, its still available as the 'grand editor' from Dave Yost].
> 
> The Rand editor e had nothing in common with ed(1).  e
> descended from NED, a 2D editor, invented by Ned Irons in 1967
> and described in "A CRT editing system" CACM Jan 1972.
> 
> The "Grand editor", derived from e19 is long gone. Even Dave
> gave up on it long ago.  Though you can find a separate
> version on the 'Net, also derived from e19.  e with its
> multiple windows was a joy to use on a 60 line Ann Arbor
> Ambassador terminal. I use acme because it too is a tiling
> editor like e. It has some goodies not in e but overall e
> was a better experience.
> 
> http://www.bitsavers.org/pdf/rand/R-2176-ARPA_The_CRT_Text_Editor_NED_Dec77.pdf

From rich.salz at gmail.com  Mon Sep 16 09:45:01 2019
From: rich.salz at gmail.com (Richard Salz)
Date: Sun, 15 Sep 2019 19:45:01 -0400
Subject: [TUHS] a book (was Re: PWB vs Unix/TS)
In-Reply-To: <D3DF8E2D-8FD0-46FF-B15A-6B4E874A2776@ccc.com>
References: <CANCZdfpEu6OxvmhDGSa3Cw4TSpfcbBOFbJjU7nZU-C_JFGFdRA@mail.gmail.com>
 <CAC20D2Pz+gwyeuVYcHFbJaimHtrt+sKSvCFp=hMZNoAWr4G09Q@mail.gmail.com>
 <alpine.NEB.2.21.1909101307530.11702@t1.m.reedmedia.net>
 <B2F032E8-E51B-4E58-AA8F-33BE5B7AD75F@ccc.com>
 <CAP2nic3L1bVPvgX7yshrHxkhqd24otdUQO8g_ayFRXVbFZJ0Dg@mail.gmail.com>
 <d7377aaf-9342-9c8f-9ea7-24c11ab3be4e@neophilic.com>
 <CAC20D2OgO5WCd-qgvvArbvOCFHsJ-m4o9vQf0hLJzDVKkMJSGg@mail.gmail.com>
 <alpine.BSF.2.21.9999.1909160724320.18105@aneurin.horsfall.org>
 <D3DF8E2D-8FD0-46FF-B15A-6B4E874A2776@ccc.com>
Message-ID: <CAFH29toa7OGuVFeTacAeN2SRFnRyMyJJzw8V4ybNDfjdkpMtmA@mail.gmail.com>

> There is a famous line which I wish I knew who said that to paraphrase
> becomes: “In science we stand on the shoulders of the great people that
> came before us, but in computer science we try to step on their toes.”
>

Brian Reid's gloss on Isaac Newton:
http://www.anvari.org/fortune/Miscellaneous_Collections/131870_in-computer-science-we-stand-on-each-others-feet-brian-k.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190915/edd3d80c/attachment.html>

From pechter at gmail.com  Mon Sep 16 11:31:28 2019
From: pechter at gmail.com (William Pechter)
Date: Sun, 15 Sep 2019 21:31:28 -0400
Subject: [TUHS] My EuroBSDcon talk (preview for commentary)
In-Reply-To: <CAC20D2Nq+eTQDdft5nW8kKcWFdt9ZK4-5kJX6OcMcYBffk9HGA@mail.gmail.com>
References: <CANCZdfrK4iFQCWOFP4MoUggpfJVmoJ0dnSg6H0cCi4dop7sVXw@mail.gmail.com>
 <CAC20D2Nq+eTQDdft5nW8kKcWFdt9ZK4-5kJX6OcMcYBffk9HGA@mail.gmail.com>
Message-ID: <71a17612-a62f-66a6-4799-9a3cc0cdd8c5@gmail.com>


On 9/15/19 5:46 PM, Clem Cole wrote:
> Funny the things you think about at 3 in the AM.
>
> Idris is interesting in that when Plauger built it, he did get in 
> trouble at the UDel USENIX when he tried to 'hawk it' and basically 
> was booed (how he did was as much of a problem as that fact that he 
> did it).  But by that point, there was another commercial UNIX 
> available.   What's interesting is that there was not an official V6 
> redistribution license like there was for V7; so I'm not 100% sure I 
> know how it was done and I would love to enlightened.
>
Interesting... I was at Concurrent messing around with a couple of 
truckloads of 7350 boxes they were trashing.  They were still being 
built (or supported) by Concurrent in 87 or so (I think that's when the 
Masscomp merger happened)... They were an 8mhz 68000 running either 
Uniplus+ (Sys III) or Idris (IIRC) or MicroXelos System V (which I think 
is a rebadged Uniplus SysV renamed to match the Concurrent 3200 Xelos 
systems).

They used them internal around '83 when they went to a Rand Editor and  
some *Roff based formatting for their office automation.  The motto for 
the IT move to desktop Unix was "Paper Free in '83."

Soon PC's and laser printers killed any hope of "paper free" as the 
staff spent way too much time chosing fonts for BS memos.

Here's some info on the very slow 68k I ran a newsfeed on: 
http://www.1000bit.it/ad/bro/perkin/PerkinElmer7350.pdf

> I know this much of the story.
>
> As I mentioned before the first commercial user of UNIX was Rand 
> Corporation in LA.  Al Arms of AT&T legal wrote the original $15K/CPU 
> license for them.   I don't know how many of those licenses were made 
> available, but I've always been under the impression it was under 10.  
> Like a lot of people at the time, this was when the 'glass tty' was 
> just showing up in force and Rand updated/wrote a version of ed(1) 
> called the rand(1) editor [IIRC, its still available as the 'grand 
> editor' from Dave Yost].
>
Perkin-Elmer had a port of the Rand Editor "E" which worked on both the 
block mode and text terminals and they were using this for their office 
automation stuff internal on the desktops until they went Windows and 
Microsoft around 86 or so.

I rescued a bunch of the trash bound 7350's and set up a small Cnews 
relay around Monmouth and Ocean counties in NJ.  For a while I upgraded 
to an AT&T6300 with Xenix-86 on it which outran the 6 or 8 mhz 68k in 
the Perkin-Elmer box.

Cheap RLL disks and higher speed serial ports were to obsolete 
everything below a 386 for the news feed so I upgraded it.

One of the great things about the editor on the box was the Rand Editor 
version allowed block copy of column data -- which I could only do on my 
CP/M box under Wordstar.

I kept the boxes around until a Trenton Computer Festival.  When I 
couldn't unload them in the 90-91 time frame I used the free dumpsters 
there to finish the destruction that Concurrent had planned.

I wiped and reused the ton of Uniplus disks I had at the time as scratch 
floppies.  I wish I had a copy left for historical reasons.  I kept the 
full manual set until I had a full *BSD 4.2,4.3 set and a full SysV set 
so I dumped the Idris and SysIII stuff.

My original degree was history and I never found an old computer or doc 
I didn't try to save.


Bill



-- 
Digital had it then.  Don't you wish you could buy it now!
pechter-at-gmail.com  http://xkcd.com/705/


From imp at bsdimp.com  Mon Sep 16 11:42:23 2019
From: imp at bsdimp.com (Warner Losh)
Date: Mon, 16 Sep 2019 02:42:23 +0100
Subject: [TUHS] My EuroBSDcon talk (preview for commentary)
In-Reply-To: <20190915232524.9A5491570CE9@mail.bitblocks.com>
References: <CANCZdfrK4iFQCWOFP4MoUggpfJVmoJ0dnSg6H0cCi4dop7sVXw@mail.gmail.com>
 <CAC20D2Nq+eTQDdft5nW8kKcWFdt9ZK4-5kJX6OcMcYBffk9HGA@mail.gmail.com>
 <20190915232524.9A5491570CE9@mail.bitblocks.com>
Message-ID: <CANCZdfr83yx7eUu-t+j-D8z9TMSkuAvPpb81hJdk95070gmZcA@mail.gmail.com>

On Mon, Sep 16, 2019, 12:25 AM Bakul Shah <bakul at bitblocks.com> wrote:

> On Sun, 15 Sep 2019 17:46:42 -0400 Clem Cole <clemc at ccc.com> wrote:
> >
> > The first UNIX clone that I know about was a V6 version by Whitesmiths,
> > called Idris, I want to say in 1977/78.   I believe that Michel's Gien's
> > Pascal clone that he talked about a year later started out as V6, but
> > morphed to V7 before he was done (and then later morphed again to become
> > Chorus in a C++ rewrote).  Mike Malcolm's Thoth (which "Thucks" by the
> way,
> > my wife threw out my tee-shirt years ago;-) was a pseudo V6 clone.   I
>
> Acc. to a paper[1] by Cheriton, Malcom and Melen did the
> original small run time executive called Thoth. Cheriton
> rewrote it to form the kernel of the system described in the
> Feb 1979 CACM article. It used memory mapping, swapping. etc.
> They also added a filesystem.
>


Cataloguing all the clones was out of scope for my talk... there are a huge
number that are known, and many more that aren't...

I likely could do a whole talk on just that...

Warner


Thoth could not have been a clone of v6.  It used message
> passing. More RPC than pipes. And it had "teams", where a
> "team" is roughly the same as a Unix process (separate address
> space) and a Thoth "process" was a thread in that address
> space.  root was "*" (instead of "/") and current dir was "@"
> (instead ".").  A bigger difference was that it had *nodes* or
> files and any file can have sub nodes.  There was no
> separation between files and directories.
>
> It was an interesting system and a lot of different things
> were tried in it. In 1980-81 timeframe AMD forked off a
> separate company called AMC to build microcomputers. They
> chose Thoth.  I almost worked there but in the end decided I'd
> rather do unix and joined Fortune and soon after AMD came to
> its senses and shut AMC down.
>
> [1] https://cs.uwaterloo.ca/research/tr/1979/CS-79-19.pdf
>
> > As I mentioned before the first commercial user of UNIX was Rand
> > Corporation in LA.  Al Arms of AT&T legal wrote the original $15K/CPU
> > license for them.   I don't know how many of those licenses were made
> > available, but I've always been under the impression it was under 10.
> Like
> > a lot of people at the time, this was when the 'glass tty' was just
> showing
> > up in force and Rand updated/wrote a version of ed(1) called the rand(1)
> > editor [IIRC, its still available as the 'grand editor' from Dave Yost].
>
> The Rand editor e had nothing in common with ed(1).  e
> descended from NED, a 2D editor, invented by Ned Irons in 1967
> and described in "A CRT editing system" CACM Jan 1972.
>
> The "Grand editor", derived from e19 is long gone. Even Dave
> gave up on it long ago.  Though you can find a separate
> version on the 'Net, also derived from e19.  e with its
> multiple windows was a joy to use on a 60 line Ann Arbor
> Ambassador terminal. I use acme because it too is a tiling
> editor like e. It has some goodies not in e but overall e
> was a better experience.
>
>
> http://www.bitsavers.org/pdf/rand/R-2176-ARPA_The_CRT_Text_Editor_NED_Dec77.pdf
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190916/06b1e712/attachment.html>

From clemc at ccc.com  Mon Sep 16 11:48:57 2019
From: clemc at ccc.com (Clem cole)
Date: Sun, 15 Sep 2019 21:48:57 -0400
Subject: [TUHS] My EuroBSDcon talk (preview for commentary)
In-Reply-To: <71a17612-a62f-66a6-4799-9a3cc0cdd8c5@gmail.com>
References: <CANCZdfrK4iFQCWOFP4MoUggpfJVmoJ0dnSg6H0cCi4dop7sVXw@mail.gmail.com>
 <CAC20D2Nq+eTQDdft5nW8kKcWFdt9ZK4-5kJX6OcMcYBffk9HGA@mail.gmail.com>
 <71a17612-a62f-66a6-4799-9a3cc0cdd8c5@gmail.com>
Message-ID: <ED018883-3817-4F6F-A93A-20E866E45561@ccc.com>

Becareful.  The Idris name was also used later by someone else for a 68000 system a few years after the Whitesmiths demise and they had stopped trying to sell there clone.   I do not believe the two products were in any way related.  

Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. 

> On Sep 15, 2019, at 9:31 PM, William Pechter <pechter at gmail.com> wrote:
> 
> 
>> On 9/15/19 5:46 PM, Clem Cole wrote:
>> Funny the things you think about at 3 in the AM.
>> 
>> Idris is interesting in that when Plauger built it, he did get in trouble at the UDel USENIX when he tried to 'hawk it' and basically was booed (how he did was as much of a problem as that fact that he did it).  But by that point, there was another commercial UNIX available.   What's interesting is that there was not an official V6 redistribution license like there was for V7; so I'm not 100% sure I know how it was done and I would love to enlightened.
>> 
> Interesting... I was at Concurrent messing around with a couple of truckloads of 7350 boxes they were trashing.  They were still being built (or supported) by Concurrent in 87 or so (I think that's when the Masscomp merger happened)... They were an 8mhz 68000 running either Uniplus+ (Sys III) or Idris (IIRC) or MicroXelos System V (which I think is a rebadged Uniplus SysV renamed to match the Concurrent 3200 Xelos systems).
> 
> They used them internal around '83 when they went to a Rand Editor and  some *Roff based formatting for their office automation.  The motto for the IT move to desktop Unix was "Paper Free in '83."
> 
> Soon PC's and laser printers killed any hope of "paper free" as the staff spent way too much time chosing fonts for BS memos.
> 
> Here's some info on the very slow 68k I ran a newsfeed on: http://www.1000bit.it/ad/bro/perkin/PerkinElmer7350.pdf
> 
>> I know this much of the story.
>> 
>> As I mentioned before the first commercial user of UNIX was Rand Corporation in LA.  Al Arms of AT&T legal wrote the original $15K/CPU license for them.   I don't know how many of those licenses were made available, but I've always been under the impression it was under 10.  Like a lot of people at the time, this was when the 'glass tty' was just showing up in force and Rand updated/wrote a version of ed(1) called the rand(1) editor [IIRC, its still available as the 'grand editor' from Dave Yost].
>> 
> Perkin-Elmer had a port of the Rand Editor "E" which worked on both the block mode and text terminals and they were using this for their office automation stuff internal on the desktops until they went Windows and Microsoft around 86 or so.
> 
> I rescued a bunch of the trash bound 7350's and set up a small Cnews relay around Monmouth and Ocean counties in NJ.  For a while I upgraded to an AT&T6300 with Xenix-86 on it which outran the 6 or 8 mhz 68k in the Perkin-Elmer box.
> 
> Cheap RLL disks and higher speed serial ports were to obsolete everything below a 386 for the news feed so I upgraded it.
> 
> One of the great things about the editor on the box was the Rand Editor version allowed block copy of column data -- which I could only do on my CP/M box under Wordstar.
> 
> I kept the boxes around until a Trenton Computer Festival.  When I couldn't unload them in the 90-91 time frame I used the free dumpsters there to finish the destruction that Concurrent had planned.
> 
> I wiped and reused the ton of Uniplus disks I had at the time as scratch floppies.  I wish I had a copy left for historical reasons.  I kept the full manual set until I had a full *BSD 4.2,4.3 set and a full SysV set so I dumped the Idris and SysIII stuff.
> 
> My original degree was history and I never found an old computer or doc I didn't try to save.
> 
> 
> Bill
> 
> 
> 
> -- 
> Digital had it then.  Don't you wish you could buy it now!
> pechter-at-gmail.com  http://xkcd.com/705/
> 

From clemc at ccc.com  Mon Sep 16 11:52:33 2019
From: clemc at ccc.com (Clem cole)
Date: Sun, 15 Sep 2019 21:52:33 -0400
Subject: [TUHS] My EuroBSDcon talk (preview for commentary)
In-Reply-To: <CANCZdfr83yx7eUu-t+j-D8z9TMSkuAvPpb81hJdk95070gmZcA@mail.gmail.com>
References: <CANCZdfrK4iFQCWOFP4MoUggpfJVmoJ0dnSg6H0cCi4dop7sVXw@mail.gmail.com>
 <CAC20D2Nq+eTQDdft5nW8kKcWFdt9ZK4-5kJX6OcMcYBffk9HGA@mail.gmail.com>
 <20190915232524.9A5491570CE9@mail.bitblocks.com>
 <CANCZdfr83yx7eUu-t+j-D8z9TMSkuAvPpb81hJdk95070gmZcA@mail.gmail.com>
Message-ID: <7F62BF6B-8FEA-4C43-9E35-05BDE9BF04EA@ccc.com>

Fair enough.  But the original v6 Whitesmiths Idris was important and should be part of your v6 slide.    It establishes that some people were beginning to take a commercial version of Unix seriously even if AT&T was not allowed too.  

Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. 

> On Sep 15, 2019, at 9:42 PM, Warner Losh <imp at bsdimp.com> wrote:
> 
> 
> 
>> On Mon, Sep 16, 2019, 12:25 AM Bakul Shah <bakul at bitblocks.com> wrote:
>> On Sun, 15 Sep 2019 17:46:42 -0400 Clem Cole <clemc at ccc.com> wrote:
>> >
>> > The first UNIX clone that I know about was a V6 version by Whitesmiths,
>> > called Idris, I want to say in 1977/78.   I believe that Michel's Gien's
>> > Pascal clone that he talked about a year later started out as V6, but
>> > morphed to V7 before he was done (and then later morphed again to become
>> > Chorus in a C++ rewrote).  Mike Malcolm's Thoth (which "Thucks" by the way,
>> > my wife threw out my tee-shirt years ago;-) was a pseudo V6 clone.   I
>> 
>> Acc. to a paper[1] by Cheriton, Malcom and Melen did the
>> original small run time executive called Thoth. Cheriton
>> rewrote it to form the kernel of the system described in the
>> Feb 1979 CACM article. It used memory mapping, swapping. etc.
>> They also added a filesystem.
> 
> 
> 
> Cataloguing all the clones was out of scope for my talk... there are a huge number that are known, and many more that aren't...
> 
> I likely could do a whole talk on just that...
> 
> Warner 
> 
> 
>> Thoth could not have been a clone of v6.  It used message
>> passing. More RPC than pipes. And it had "teams", where a
>> "team" is roughly the same as a Unix process (separate address
>> space) and a Thoth "process" was a thread in that address
>> space.  root was "*" (instead of "/") and current dir was "@"
>> (instead ".").  A bigger difference was that it had *nodes* or
>> files and any file can have sub nodes.  There was no
>> separation between files and directories.
>> 
>> It was an interesting system and a lot of different things
>> were tried in it. In 1980-81 timeframe AMD forked off a
>> separate company called AMC to build microcomputers. They
>> chose Thoth.  I almost worked there but in the end decided I'd
>> rather do unix and joined Fortune and soon after AMD came to
>> its senses and shut AMC down.
>> 
>> [1] https://cs.uwaterloo.ca/research/tr/1979/CS-79-19.pdf
>> 
>> > As I mentioned before the first commercial user of UNIX was Rand
>> > Corporation in LA.  Al Arms of AT&T legal wrote the original $15K/CPU
>> > license for them.   I don't know how many of those licenses were made
>> > available, but I've always been under the impression it was under 10.  Like
>> > a lot of people at the time, this was when the 'glass tty' was just showing
>> > up in force and Rand updated/wrote a version of ed(1) called the rand(1)
>> > editor [IIRC, its still available as the 'grand editor' from Dave Yost].
>> 
>> The Rand editor e had nothing in common with ed(1).  e
>> descended from NED, a 2D editor, invented by Ned Irons in 1967
>> and described in "A CRT editing system" CACM Jan 1972.
>> 
>> The "Grand editor", derived from e19 is long gone. Even Dave
>> gave up on it long ago.  Though you can find a separate
>> version on the 'Net, also derived from e19.  e with its
>> multiple windows was a joy to use on a 60 line Ann Arbor
>> Ambassador terminal. I use acme because it too is a tiling
>> editor like e. It has some goodies not in e but overall e
>> was a better experience.
>> 
>> http://www.bitsavers.org/pdf/rand/R-2176-ARPA_The_CRT_Text_Editor_NED_Dec77.pdf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190915/eb933bf0/attachment.html>

From ggm at algebras.org  Mon Sep 16 12:05:24 2019
From: ggm at algebras.org (George Michaelson)
Date: Mon, 16 Sep 2019 12:05:24 +1000
Subject: [TUHS] My EuroBSDcon talk (preview for commentary)
In-Reply-To: <7F62BF6B-8FEA-4C43-9E35-05BDE9BF04EA@ccc.com>
References: <CANCZdfrK4iFQCWOFP4MoUggpfJVmoJ0dnSg6H0cCi4dop7sVXw@mail.gmail.com>
 <CAC20D2Nq+eTQDdft5nW8kKcWFdt9ZK4-5kJX6OcMcYBffk9HGA@mail.gmail.com>
 <20190915232524.9A5491570CE9@mail.bitblocks.com>
 <CANCZdfr83yx7eUu-t+j-D8z9TMSkuAvPpb81hJdk95070gmZcA@mail.gmail.com>
 <7F62BF6B-8FEA-4C43-9E35-05BDE9BF04EA@ccc.com>
Message-ID: <CAKr6gn3dKiFCr3D4sYv1+xJbD4cHq5X6AFEtz8MF7NtKdnY6dw@mail.gmail.com>

The "block copy in an editor" thing is something which has intrigued
me for years. poor old ed/ex/vi just couldn't do it, and for the life
of me, I could not understand why this was "deprecated" by the people
writing that family of editors. I seem to recall the various
lightweight emacs which proceeded GNU had it, in some cases, and GNU
had it. (Goslings emacs?)

It was pretty much "you could do this with awk or sed" or "I wrote a
SPITBAL program to do that" for most things. -As if columnar state, or
a region of a screen was not something it even made sense to pick up
into a buffer and put down somewhere else.

Later on I theorised that the internal edit sequence log structure
might make this quite hard to conceptualise and implement. But, I
think its also possible the editor authors in question just didn't see
a use value for this up-front.

I think anyone who used WordStar or a half-duplex terminal saw a
potential use for this almost immediately. And, the people using the
early newspaper edit terminals almost certainly had a use for it
because even at low-charcount they routinely seemed to work in
newspaper columns, and so a "story" was about columnar paragraph
structured data.

Similarly the 'repeat this sequence of commands' thing which emacs
had, as a "start keystroke" <do things> "end keystroke" and then @run
that thing. Yes you could @run VI buffers, but you had to program them
into a state, you couldn't tell the editor to "watch what you did, and
re-do it on successive lines"

I also suspect, that "do the thing you just did" and "block copy" were
a bit low: people who did these kind of things were not clever. Clever
people held the state of the lines in their head, and were mentally
writing the ed/ex/vi or Teco sequences to change the letters in a
line. Dumb people like me were thinking of editing as "cut the words
out with rounded -end scissors and ask mummy for the clag gluepaste"

Many fine hours were spent doing rote edits to fix post-formatted
NROFF and RUNOFF text by me. Dumb, but doable.

(runoff on the Dec-10 was good. I am glad I'd done it, it made the
transition to nroff far easier. I didn't realize it was a cross-port
from CTSS)

-G

On Mon, Sep 16, 2019 at 11:52 AM Clem cole <clemc at ccc.com> wrote:
>
> Fair enough.  But the original v6 Whitesmiths Idris was important and should be part of your v6 slide.    It establishes that some people were beginning to take a commercial version of Unix seriously even if AT&T was not allowed too.
>
> Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite.
>
> On Sep 15, 2019, at 9:42 PM, Warner Losh <imp at bsdimp.com> wrote:
>
>
>
> On Mon, Sep 16, 2019, 12:25 AM Bakul Shah <bakul at bitblocks.com> wrote:
>>
>> On Sun, 15 Sep 2019 17:46:42 -0400 Clem Cole <clemc at ccc.com> wrote:
>> >
>> > The first UNIX clone that I know about was a V6 version by Whitesmiths,
>> > called Idris, I want to say in 1977/78.   I believe that Michel's Gien's
>> > Pascal clone that he talked about a year later started out as V6, but
>> > morphed to V7 before he was done (and then later morphed again to become
>> > Chorus in a C++ rewrote).  Mike Malcolm's Thoth (which "Thucks" by the way,
>> > my wife threw out my tee-shirt years ago;-) was a pseudo V6 clone.   I
>>
>> Acc. to a paper[1] by Cheriton, Malcom and Melen did the
>> original small run time executive called Thoth. Cheriton
>> rewrote it to form the kernel of the system described in the
>> Feb 1979 CACM article. It used memory mapping, swapping. etc.
>> They also added a filesystem.
>
>
>
> Cataloguing all the clones was out of scope for my talk... there are a huge number that are known, and many more that aren't...
>
> I likely could do a whole talk on just that...
>
> Warner
>
>
>> Thoth could not have been a clone of v6.  It used message
>> passing. More RPC than pipes. And it had "teams", where a
>> "team" is roughly the same as a Unix process (separate address
>> space) and a Thoth "process" was a thread in that address
>> space.  root was "*" (instead of "/") and current dir was "@"
>> (instead ".").  A bigger difference was that it had *nodes* or
>> files and any file can have sub nodes.  There was no
>> separation between files and directories.
>>
>> It was an interesting system and a lot of different things
>> were tried in it. In 1980-81 timeframe AMD forked off a
>> separate company called AMC to build microcomputers. They
>> chose Thoth.  I almost worked there but in the end decided I'd
>> rather do unix and joined Fortune and soon after AMD came to
>> its senses and shut AMC down.
>>
>> [1] https://cs.uwaterloo.ca/research/tr/1979/CS-79-19.pdf
>>
>> > As I mentioned before the first commercial user of UNIX was Rand
>> > Corporation in LA.  Al Arms of AT&T legal wrote the original $15K/CPU
>> > license for them.   I don't know how many of those licenses were made
>> > available, but I've always been under the impression it was under 10.  Like
>> > a lot of people at the time, this was when the 'glass tty' was just showing
>> > up in force and Rand updated/wrote a version of ed(1) called the rand(1)
>> > editor [IIRC, its still available as the 'grand editor' from Dave Yost].
>>
>> The Rand editor e had nothing in common with ed(1).  e
>> descended from NED, a 2D editor, invented by Ned Irons in 1967
>> and described in "A CRT editing system" CACM Jan 1972.
>>
>> The "Grand editor", derived from e19 is long gone. Even Dave
>> gave up on it long ago.  Though you can find a separate
>> version on the 'Net, also derived from e19.  e with its
>> multiple windows was a joy to use on a 60 line Ann Arbor
>> Ambassador terminal. I use acme because it too is a tiling
>> editor like e. It has some goodies not in e but overall e
>> was a better experience.
>>
>> http://www.bitsavers.org/pdf/rand/R-2176-ARPA_The_CRT_Text_Editor_NED_Dec77.pdf

From dave at horsfall.org  Mon Sep 16 12:24:13 2019
From: dave at horsfall.org (Dave Horsfall)
Date: Mon, 16 Sep 2019 12:24:13 +1000 (EST)
Subject: [TUHS] My EuroBSDcon talk (preview for commentary)
In-Reply-To: <71a17612-a62f-66a6-4799-9a3cc0cdd8c5@gmail.com>
References: <CANCZdfrK4iFQCWOFP4MoUggpfJVmoJ0dnSg6H0cCi4dop7sVXw@mail.gmail.com>
 <CAC20D2Nq+eTQDdft5nW8kKcWFdt9ZK4-5kJX6OcMcYBffk9HGA@mail.gmail.com>
 <71a17612-a62f-66a6-4799-9a3cc0cdd8c5@gmail.com>
Message-ID: <alpine.BSF.2.21.9999.1909161220490.18105@aneurin.horsfall.org>

On Sun, 15 Sep 2019, William Pechter wrote:

> They used them internal around '83 when they went to a Rand Editor and  
> some *Roff based formatting for their office automation.  The motto for 
> the IT move to desktop Unix was "Paper Free in '83."
>
> Soon PC's and laser printers killed any hope of "paper free" as the 
> staff spent way too much time chosing fonts for BS memos.

There was a saying many years ago, from someone whom I've long forgotten: 
"I'll believe in the paper-less office when I see the paper-less toilet".

-- Dave

From bakul at bitblocks.com  Mon Sep 16 12:37:31 2019
From: bakul at bitblocks.com (Bakul Shah)
Date: Sun, 15 Sep 2019 19:37:31 -0700
Subject: [TUHS] My EuroBSDcon talk (preview for commentary)
In-Reply-To: Your message of "Mon, 16 Sep 2019 12:05:24 +1000."
 <CAKr6gn3dKiFCr3D4sYv1+xJbD4cHq5X6AFEtz8MF7NtKdnY6dw@mail.gmail.com>
References: <CANCZdfrK4iFQCWOFP4MoUggpfJVmoJ0dnSg6H0cCi4dop7sVXw@mail.gmail.com>
 <CAC20D2Nq+eTQDdft5nW8kKcWFdt9ZK4-5kJX6OcMcYBffk9HGA@mail.gmail.com>
 <20190915232524.9A5491570CE9@mail.bitblocks.com>
 <CANCZdfr83yx7eUu-t+j-D8z9TMSkuAvPpb81hJdk95070gmZcA@mail.gmail.com>
 <7F62BF6B-8FEA-4C43-9E35-05BDE9BF04EA@ccc.com>
 <CAKr6gn3dKiFCr3D4sYv1+xJbD4cHq5X6AFEtz8MF7NtKdnY6dw@mail.gmail.com>
Message-ID: <20190916023738.F34E81570CE9@mail.bitblocks.com>

On Mon, 16 Sep 2019 12:05:24 +1000 George Michaelson <ggm at algebras.org> wrote:
> The "block copy in an editor" thing is something which has intrigued
> me for years. poor old ed/ex/vi just couldn't do it, and for the life
> of me, I could not understand why this was "deprecated" by the people
> writing that family of editors. I seem to recall the various
> lightweight emacs which proceeded GNU had it, in some cases, and GNU
> had it. (Goslings emacs?)

I think this is because vi grew out of ex which grew out of
ed, all of which were "line" editors, while the Rand Editor
(and the original NED) assumed a quarter plane model. e had
commands such as box (to draw a box), blank (or was it cut?)
to wipe out all nonblank chars from a rectangle, replace,
overlay (nonblank chars from the copy buffer overwrote data),
underlay (nonblank chars from the copy buffer didn't overwrite
nonblank chars) and so on. It even had justfy, fill and center
commands. It was basically an editor for producing documents
in monspaced fonts!

From toby at telegraphics.com.au  Mon Sep 16 12:31:48 2019
From: toby at telegraphics.com.au (Toby Thain)
Date: Sun, 15 Sep 2019 22:31:48 -0400
Subject: [TUHS] My EuroBSDcon talk (preview for commentary)
In-Reply-To: <alpine.BSF.2.21.9999.1909161220490.18105@aneurin.horsfall.org>
References: <CANCZdfrK4iFQCWOFP4MoUggpfJVmoJ0dnSg6H0cCi4dop7sVXw@mail.gmail.com>
 <CAC20D2Nq+eTQDdft5nW8kKcWFdt9ZK4-5kJX6OcMcYBffk9HGA@mail.gmail.com>
 <71a17612-a62f-66a6-4799-9a3cc0cdd8c5@gmail.com>
 <alpine.BSF.2.21.9999.1909161220490.18105@aneurin.horsfall.org>
Message-ID: <7100ae29-9a00-d73d-b677-623341175d2b@telegraphics.com.au>

On 2019-09-15 10:24 p.m., Dave Horsfall wrote:
> On Sun, 15 Sep 2019, William Pechter wrote:
> 
>> They used them internal around '83 when they went to a Rand Editor
>> and  some *Roff based formatting for their office automation.  The
>> motto for the IT move to desktop Unix was "Paper Free in '83."
>>
>> Soon PC's and laser printers killed any hope of "paper free" as the
>> staff spent way too much time chosing fonts for BS memos.
> 
> There was a saying many years ago, from someone whom I've long
> forgotten: "I'll believe in the paper-less office when I see the
> paper-less toilet".

I am forced to observe that not only are paperless toilets quite common
outside North America, they're also more hygienic...

--Toby


> 
> -- Dave


From sauer at technologists.com  Mon Sep 16 13:29:02 2019
From: sauer at technologists.com (Charles H. Sauer)
Date: Sun, 15 Sep 2019 22:29:02 -0500
Subject: [TUHS] INed/Rand Editor/Ned [was Re: My EuroBSDcon talk (preview
 for commentary)
In-Reply-To: <20190916023738.F34E81570CE9@mail.bitblocks.com>
References: <CANCZdfrK4iFQCWOFP4MoUggpfJVmoJ0dnSg6H0cCi4dop7sVXw@mail.gmail.com>
 <CAC20D2Nq+eTQDdft5nW8kKcWFdt9ZK4-5kJX6OcMcYBffk9HGA@mail.gmail.com>
 <20190915232524.9A5491570CE9@mail.bitblocks.com>
 <CANCZdfr83yx7eUu-t+j-D8z9TMSkuAvPpb81hJdk95070gmZcA@mail.gmail.com>
 <7F62BF6B-8FEA-4C43-9E35-05BDE9BF04EA@ccc.com>
 <CAKr6gn3dKiFCr3D4sYv1+xJbD4cHq5X6AFEtz8MF7NtKdnY6dw@mail.gmail.com>
 <20190916023738.F34E81570CE9@mail.bitblocks.com>
Message-ID: <B2C11377-D557-4542-94D9-31E3D9C789D6@technologists.com>

The first Unix I used was PC/ix on an XT. I don’t know it even had vi, but it had INed, which I assume was the ISC evolution of NED & Rand Editor. (I think I first started using vi on Xenix on an AT before I got my own RT??)

Anyway, I had been very productive with half-duplex editing on 3270 on CMS up to that point, and INed seemed very natural to me.

Totally unrelated to Unix, when I came to IBM Austin from Yorktown, real 3270s were scarce/shared. I got a DisplayWriter with a 3270 card and emulator in my office. That was better than a real 3270 to my tastes, even with the 8” diskettes. 3270 emulation on PC was ok, but not as good as the real thing, certainly not as good as the DW emulation. 

> On Sep 15, 2019, at 9:37 PM, Bakul Shah <bakul at bitblocks.com> wrote:
> 
> On Mon, 16 Sep 2019 12:05:24 +1000 George Michaelson <ggm at algebras.org> wrote:
>> The "block copy in an editor" thing is something which has intrigued
>> me for years. poor old ed/ex/vi just couldn't do it, and for the life
>> of me, I could not understand why this was "deprecated" by the people
>> writing that family of editors. I seem to recall the various
>> lightweight emacs which proceeded GNU had it, in some cases, and GNU
>> had it. (Goslings emacs?)
> 
> I think this is because vi grew out of ex which grew out of
> ed, all of which were "line" editors, while the Rand Editor
> (and the original NED) assumed a quarter plane model. e had
> commands such as box (to draw a box), blank (or was it cut?)
> to wipe out all nonblank chars from a rectangle, replace,
> overlay (nonblank chars from the copy buffer overwrote data),
> underlay (nonblank chars from the copy buffer didn't overwrite
> nonblank chars) and so on. It even had justfy, fill and center
> commands. It was basically an editor for producing documents
> in monspaced fonts!

--
voice: +1.512.784.7526       e-mail: sauer at technologists.com <mailto:sauer at technologists.com>           
fax: +1.512.346.5240         web: https://technologists.com/sauer/ <http://technologists.com/sauer/>
Facebook/Google/Skype/Twitter: CharlesHSauer

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190915/44b6e739/attachment.html>

From tytso at mit.edu  Mon Sep 16 13:36:18 2019
From: tytso at mit.edu (Theodore Y. Ts'o)
Date: Sun, 15 Sep 2019 23:36:18 -0400
Subject: [TUHS] My EuroBSDcon talk (preview for commentary)
In-Reply-To: <CAC20D2Nq+eTQDdft5nW8kKcWFdt9ZK4-5kJX6OcMcYBffk9HGA@mail.gmail.com>
References: <CANCZdfrK4iFQCWOFP4MoUggpfJVmoJ0dnSg6H0cCi4dop7sVXw@mail.gmail.com>
 <CAC20D2Nq+eTQDdft5nW8kKcWFdt9ZK4-5kJX6OcMcYBffk9HGA@mail.gmail.com>
Message-ID: <20190916033618.GC22035@mit.edu>

On Sun, Sep 15, 2019 at 05:46:42PM -0400, Clem Cole wrote:
> By the time of V7, the clones do start showing up. Minux which everyone
> agreed was original, as well as Mark William's Coherent, which in the end
> AT&T backed off. But as Dennis said at the time something to the effect,
> that it was not clear they had directly used AT&T sources to build it, as
> much as the authors clearly had *seen/had access to UNIX operating and used
> it to build Coherent, plus they probably had seen the UNIX sources* at some
> point (this was important later when AT&T would make 'Trade Secret' claims).

One really interesting anecdote about the "Trade Secret" claims, is
that the MIT Unix license never had the "methods and concepts" clause
in it.  The MIT Administration/Lawyers considered in unconscionable
the brains of MIT students might get encumbered by AT&T, and outright
rejected that clause.  Apparently MIT had a lot more clout (and
probably alumni in high places at AT&T), so MIT was able to make the
"no methods and concepts" clause stick.  For each new version of Unix
from AT&T, this issue would come up, and eventually, the Unix license
would get included in Grant contracts where AT&T really, really wanted
MIT to do research in some area, and apparently MIT had enough
leverage to get successive Unix license updates, all without the
infamous "methods and concepts" clause.

At one point, even though MIT had the necessary licenses so it could
be allowed to receive Ultrix or OSF/1 sources, AT&T's licensing
division refused to confirm (or deny) whether or not MIT had a valid
Unix source license, and so this caused problems for MIT to be able to
get an official version of Ultrix or OSF/1 sources.  No matter, MIT
had even more alumni and connections which Digital, so when a tape was
eventually installed in Project Athena's AFS cell, it was apparently
an active source tree from some engineering directory, completely with
core dumps and editor backup files....

So while I have looked at BSD 4.3 sources when I was a student systems
programmer, I have it on good authority from people who were staff
members on Project Athena at the time, that my brain was not owned by
AT&T due to that nasty "methods and concepts" clause --- because the
MIT Unix source license didn't have that nonsense.

    	 		       	    	 - Ted

From arnold at skeeve.com  Mon Sep 16 15:52:11 2019
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Sun, 15 Sep 2019 23:52:11 -0600
Subject: [TUHS] earliest Unix roff
In-Reply-To: <CAC20D2PfLq=J5ei+izXb2J7dSvU6=L6-GRd0gKA2ShSNg1=qBg@mail.gmail.com>
References: <CAC20D2NmXGzN7imTKy-RRWRZ2ewWMEmUV9oDuP3-e3a4R+ynpA@mail.gmail.com>
 <CAC20D2PXYWpv-8BQNKvUjgT=2W81GgzaOLyZiQ5=sM9+LXCWnw@mail.gmail.com>
 <CAC20D2MDbmoeMZq1esbuQvOCU7to0dUWsFyx98UQDLE3-c4fOA@mail.gmail.com>
 <201909132024.x8DKObEP013266@darkstar.fourwinds.com>
 <CAC20D2PvA26HMoABOcLMoS9Lu8=L3Wtx_8yK83K+vbhoMZt-hQ@mail.gmail.com>
 <463d5cc4-9bef-9ac3-a680-a5161d664dc1@aueb.gr>
 <CAC20D2Nz-ofwD41vULF2-TL8-C33heCiHvoNNbcuj6GGKhtKzQ@mail.gmail.com>
 <20190913221345.GA16129@minnie.tuhs.org>
 <CAC20D2OQD-NJaFsqsLVL_kqmCsSeUOKAr7dm71P4uN9N8m+AbQ@mail.gmail.com>
 <20190914020240.GO2046@mcvoy.com>
 <20190914024433.GA19193@minnie.tuhs.org>
 <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org>
 <201909150654.x8F6sChG021185@freefriends.org>
 <CAC20D2PfLq=J5ei+izXb2J7dSvU6=L6-GRd0gKA2ShSNg1=qBg@mail.gmail.com>
Message-ID: <201909160552.x8G5qBYK025195@freefriends.org>

Clem Cole <clemc at ccc.com> wrote:

> On Sun, Sep 15, 2019 at 2:55 AM <arnold at skeeve.com> wrote:
>
> > Texinfo is *by far* the superior markup language.
> >
> I'll take your work for it, but my complaint is it requires emacs to use as
> the pager on my screen.  If you live in emacs, that makes sense; but most
> people, even in the GNU/Linux world, don't.

Not true at all.  I don't use Emacs, never have, and likely never will.

I use the standalone Info reader (named info) if I want to look at the
Info output.  But as I mentioned already, I usually look at the Texinfo
documentation I'm working on via PDF or HTML.

And gvim has very nice syntax highlighting for Texinfo input files.

Arnold

From arnold at skeeve.com  Mon Sep 16 16:03:07 2019
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Mon, 16 Sep 2019 00:03:07 -0600
Subject: [TUHS] user-level v1
In-Reply-To: <AFC45890-C786-444F-9635-AD79D03E3228@ccc.com>
References: <201909151617.x8FGHqGu100607@tahoe.cs.Dartmouth.EDU>
 <20190915201103.GA25340@minnie.tuhs.org>
 <alpine.BSF.2.21.9999.1909160802290.18105@aneurin.horsfall.org>
 <AFC45890-C786-444F-9635-AD79D03E3228@ccc.com>
Message-ID: <201909160603.x8G637QQ026140@freefriends.org>

No, Bill Joy did vi.  Ken Arnold did curses.  The vi code did all it's
stuff directly with the termlib library calls. (Use The Source, Luke!)
Curses provided a library explicitly for screen oriented stuff that worked
at a higher level.

Mary Anne can and should tell the story of the progression of curses
to System V and terminfo.

Arnold

Clem cole <clemc at ccc.com> wrote:

> Yes, Ken Arnold did both
>
> Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. 
>
> > On Sep 15, 2019, at 6:09 PM, Dave Horsfall <dave at horsfall.org> wrote:
> > 
> > On Mon, 16 Sep 2019, Warren Toomey wrote:
> > 
> >>> The TUHS archive does not include /usr/src for v1. Does it exist anywhere?
> >> 
> >> We've not been able to find it, no :-(
> > 
> > Speaking of which, I heard that the curses library was simply ripped out of VI and made stand-alone; a rumour goes that the best test suite for curses was the game "rogue" :-)  I still play it from time to time, but cannot get rog-o-matic to compile on the Mac.
> > 
> > -- Dave

From arnold at skeeve.com  Mon Sep 16 16:20:46 2019
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Mon, 16 Sep 2019 00:20:46 -0600
Subject: [TUHS] earliest Unix roff
In-Reply-To: <069494b2-ec5b-91e7-8618-2d111e0e5aa2@andrewnesbit.org>
References: <CAC20D2NmXGzN7imTKy-RRWRZ2ewWMEmUV9oDuP3-e3a4R+ynpA@mail.gmail.com>
 <CAC20D2PXYWpv-8BQNKvUjgT=2W81GgzaOLyZiQ5=sM9+LXCWnw@mail.gmail.com>
 <CAC20D2MDbmoeMZq1esbuQvOCU7to0dUWsFyx98UQDLE3-c4fOA@mail.gmail.com>
 <201909132024.x8DKObEP013266@darkstar.fourwinds.com>
 <CAC20D2PvA26HMoABOcLMoS9Lu8=L3Wtx_8yK83K+vbhoMZt-hQ@mail.gmail.com>
 <463d5cc4-9bef-9ac3-a680-a5161d664dc1@aueb.gr>
 <CAC20D2Nz-ofwD41vULF2-TL8-C33heCiHvoNNbcuj6GGKhtKzQ@mail.gmail.com>
 <20190913221345.GA16129@minnie.tuhs.org>
 <CAC20D2OQD-NJaFsqsLVL_kqmCsSeUOKAr7dm71P4uN9N8m+AbQ@mail.gmail.com>
 <20190914020240.GO2046@mcvoy.com>
 <20190914024433.GA19193@minnie.tuhs.org>
 <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org>
 <CAC20D2M5j+pCBpxf4Cy-sK4BfBGj_RMhzSpGaXMZmeEaGV9cDA@mail.gmail.com>
 <069494b2-ec5b-91e7-8618-2d111e0e5aa2@andrewnesbit.org>
Message-ID: <201909160620.x8G6KkJq026850@freefriends.org>

"U'll Be King of the Stars" <ullbeking at andrewnesbit.org> wrote:

> This is fascinating insider information, and it leads me full circle to 
> several reasons why I want to try to use *roff in the first place:
>
> 1.  Do you think there is any chance of obtaining these macro packages? 
> Either from authors who haven't passed away, or from the publishing 
> houses themselves?

O'Reilly probably would. I can ask someone there, if there's serious
interest here.  They haven't used troff for book production for well
over a decade.

I'm not sure that Prentice-Hall had its own macros. Rather, the
books from Bell Labs were all set on the same research Unix systems.

> 2.  I get the impression that writing a macro package or editing an 
> existing is relatively straightforward.  Would you agree?

Possibly straightforward, but very much like working in assembly
language.  The commands and escape sequences (in standard troff) are
all very short, and thus cryptic, and the extra levels of backslashes
needed inside macro bodies don't help.

GNU troff has additional features that probably help a lot; my experience
has been in grunging around in traditional packages.

My two cents,

Arnodl

From dot at dotat.at  Mon Sep 16 20:59:35 2019
From: dot at dotat.at (Tony Finch)
Date: Mon, 16 Sep 2019 11:59:35 +0100
Subject: [TUHS] [SPAM] Re:  SCCS
In-Reply-To: <alpine.BSF.2.21.9999.1909140824240.18105@aneurin.horsfall.org>
References: <1568412078.22454.for-standards-violators@oclsc.org>
 <alpine.BSF.2.21.9999.1909140824240.18105@aneurin.horsfall.org>
Message-ID: <alpine.DEB.2.20.1909161157330.5352@grey.csi.cam.ac.uk>

Dave Horsfall <dave at horsfall.org> wrote:
>
> I was thinking of an intermediate router (probably one that you never knew
> about) corrupting the checksum-less UDP packet, recalculating the Ethernet
> checksum, and your kernel happily accepting it; you now have an application
> that fails for some unknown reason.
>
> Never seen it in practice, but I've heard of it happening.

This paper has some examples:

http://conferences.sigcomm.org/sigcomm/2000/conf/paper/sigcomm2000-9-1.pdf

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
Forth, Tyne, West Dogger: Westerly 3 to 5 veering northwesterly 4 to 6. Slight
or moderate, becoming moderate or rough except in west Forth. Mainly fair.
Good.

From clemc at ccc.com  Mon Sep 16 22:10:48 2019
From: clemc at ccc.com (Clem Cole)
Date: Mon, 16 Sep 2019 08:10:48 -0400
Subject: [TUHS] earliest Unix roff
In-Reply-To: <201909160552.x8G5qBYK025195@freefriends.org>
References: <CAC20D2NmXGzN7imTKy-RRWRZ2ewWMEmUV9oDuP3-e3a4R+ynpA@mail.gmail.com>
 <CAC20D2PXYWpv-8BQNKvUjgT=2W81GgzaOLyZiQ5=sM9+LXCWnw@mail.gmail.com>
 <CAC20D2MDbmoeMZq1esbuQvOCU7to0dUWsFyx98UQDLE3-c4fOA@mail.gmail.com>
 <201909132024.x8DKObEP013266@darkstar.fourwinds.com>
 <CAC20D2PvA26HMoABOcLMoS9Lu8=L3Wtx_8yK83K+vbhoMZt-hQ@mail.gmail.com>
 <463d5cc4-9bef-9ac3-a680-a5161d664dc1@aueb.gr>
 <CAC20D2Nz-ofwD41vULF2-TL8-C33heCiHvoNNbcuj6GGKhtKzQ@mail.gmail.com>
 <20190913221345.GA16129@minnie.tuhs.org>
 <CAC20D2OQD-NJaFsqsLVL_kqmCsSeUOKAr7dm71P4uN9N8m+AbQ@mail.gmail.com>
 <20190914020240.GO2046@mcvoy.com> <20190914024433.GA19193@minnie.tuhs.org>
 <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org>
 <201909150654.x8F6sChG021185@freefriends.org>
 <CAC20D2PfLq=J5ei+izXb2J7dSvU6=L6-GRd0gKA2ShSNg1=qBg@mail.gmail.com>
 <201909160552.x8G5qBYK025195@freefriends.org>
Message-ID: <CAC20D2N89jOBK+T9EPn8JKNaSOUx=yDr9t4=CcyHM+3qnB2bEg@mail.gmail.com>

On Mon, Sep 16, 2019 at 1:52 AM <arnold at skeeve.com> wrote:

> I use the standalone Info reader (named info) if I want to look at the
> Info output.
>
Fair enough, but be careful, while I admit I have not looked in a while,
info(gnu) relies on emacs keybindings and a number of very emacs'ish things.
Every time I have tried to deal with it, I have unprogram my fingers and
reset them to emacs.

If it would have used more(1) [or even less(1)] then I would not be as
annoyed.
Unix had fine tools [man(1), more(1), et al] and rms and friends felt the
need to replace them with ITS-like programs.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190916/30b622e0/attachment.html>

From leah at vuxu.org  Mon Sep 16 22:11:32 2019
From: leah at vuxu.org (Leah Neukirchen)
Date: Mon, 16 Sep 2019 14:11:32 +0200
Subject: [TUHS] [SPAM] Re:  SCCS
In-Reply-To: <1568412078.22454.for-standards-violators@oclsc.org> (Norman
 Wilson's message of "Fri, 13 Sep 2019 18:01:14 -0400")
References: <1568412078.22454.for-standards-violators@oclsc.org>
Message-ID: <878sqosaob.fsf@vuxu.org>

Norman Wilson <norman at oclsc.org> writes:

> Does IPv6 require a meaningful checksum, or just the
> useless old ritual one?

IPv6 has no checksum at all (for the header), and TCPv6 uses the same
checksum algorithm.

-- 
Leah Neukirchen  <leah at vuxu.org>  https://leahneukirchen.org/

From clemc at ccc.com  Mon Sep 16 22:13:55 2019
From: clemc at ccc.com (Clem Cole)
Date: Mon, 16 Sep 2019 08:13:55 -0400
Subject: [TUHS] earliest Unix roff
In-Reply-To: <201909160620.x8G6KkJq026850@freefriends.org>
References: <CAC20D2NmXGzN7imTKy-RRWRZ2ewWMEmUV9oDuP3-e3a4R+ynpA@mail.gmail.com>
 <CAC20D2PXYWpv-8BQNKvUjgT=2W81GgzaOLyZiQ5=sM9+LXCWnw@mail.gmail.com>
 <CAC20D2MDbmoeMZq1esbuQvOCU7to0dUWsFyx98UQDLE3-c4fOA@mail.gmail.com>
 <201909132024.x8DKObEP013266@darkstar.fourwinds.com>
 <CAC20D2PvA26HMoABOcLMoS9Lu8=L3Wtx_8yK83K+vbhoMZt-hQ@mail.gmail.com>
 <463d5cc4-9bef-9ac3-a680-a5161d664dc1@aueb.gr>
 <CAC20D2Nz-ofwD41vULF2-TL8-C33heCiHvoNNbcuj6GGKhtKzQ@mail.gmail.com>
 <20190913221345.GA16129@minnie.tuhs.org>
 <CAC20D2OQD-NJaFsqsLVL_kqmCsSeUOKAr7dm71P4uN9N8m+AbQ@mail.gmail.com>
 <20190914020240.GO2046@mcvoy.com> <20190914024433.GA19193@minnie.tuhs.org>
 <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org>
 <CAC20D2M5j+pCBpxf4Cy-sK4BfBGj_RMhzSpGaXMZmeEaGV9cDA@mail.gmail.com>
 <069494b2-ec5b-91e7-8618-2d111e0e5aa2@andrewnesbit.org>
 <201909160620.x8G6KkJq026850@freefriends.org>
Message-ID: <CAC20D2NcnG8743kcWdx88x_u=h8aXBy-sHKn12jJVL2+GZTF1g@mail.gmail.com>

On Mon, Sep 16, 2019 at 2:21 AM <arnold at skeeve.com> wrote:

> I'm not sure that Prentice-Hall had its own macros. Rather, the
> books from Bell Labs were all set on the same research Unix systems.
>
That's might be true for bwk's and Pike's stuff, but not Rich Steven's or
Comer's books.   I know for fact that Rich had a set of macro's (based
originally on -ms) and a set of integrated makefiles to build his texts.  I
was under the impression he passed them to a number of people, not just
people like me.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190916/340d82c5/attachment.html>

From arnold at skeeve.com  Mon Sep 16 22:34:04 2019
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Mon, 16 Sep 2019 06:34:04 -0600
Subject: [TUHS] earliest Unix roff
In-Reply-To: <CAC20D2NcnG8743kcWdx88x_u=h8aXBy-sHKn12jJVL2+GZTF1g@mail.gmail.com>
References: <CAC20D2NmXGzN7imTKy-RRWRZ2ewWMEmUV9oDuP3-e3a4R+ynpA@mail.gmail.com>
 <CAC20D2PXYWpv-8BQNKvUjgT=2W81GgzaOLyZiQ5=sM9+LXCWnw@mail.gmail.com>
 <CAC20D2MDbmoeMZq1esbuQvOCU7to0dUWsFyx98UQDLE3-c4fOA@mail.gmail.com>
 <201909132024.x8DKObEP013266@darkstar.fourwinds.com>
 <CAC20D2PvA26HMoABOcLMoS9Lu8=L3Wtx_8yK83K+vbhoMZt-hQ@mail.gmail.com>
 <463d5cc4-9bef-9ac3-a680-a5161d664dc1@aueb.gr>
 <CAC20D2Nz-ofwD41vULF2-TL8-C33heCiHvoNNbcuj6GGKhtKzQ@mail.gmail.com>
 <20190913221345.GA16129@minnie.tuhs.org>
 <CAC20D2OQD-NJaFsqsLVL_kqmCsSeUOKAr7dm71P4uN9N8m+AbQ@mail.gmail.com>
 <20190914020240.GO2046@mcvoy.com>
 <20190914024433.GA19193@minnie.tuhs.org>
 <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org>
 <CAC20D2M5j+pCBpxf4Cy-sK4BfBGj_RMhzSpGaXMZmeEaGV9cDA@mail.gmail.com>
 <069494b2-ec5b-91e7-8618-2d111e0e5aa2@andrewnesbit.org>
 <201909160620.x8G6KkJq026850@freefriends.org>
 <CAC20D2NcnG8743kcWdx88x_u=h8aXBy-sHKn12jJVL2+GZTF1g@mail.gmail.com>
Message-ID: <201909161234.x8GCY40W005833@freefriends.org>

Clem Cole <clemc at ccc.com> wrote:

> On Mon, Sep 16, 2019 at 2:21 AM <arnold at skeeve.com> wrote:
>
> > I'm not sure that Prentice-Hall had its own macros. Rather, the
> > books from Bell Labs were all set on the same research Unix systems.
> >
> That's might be true for bwk's and Pike's stuff, but not Rich Steven's or
> Comer's books.   I know for fact that Rich had a set of macro's (based
> originally on -ms) and a set of integrated makefiles to build his texts.  I
> was under the impression he passed them to a number of people, not just
> people like me.

Don't know, but you could try http://www.unixnetworkprogramming.com/contact.html
for the Unix Network Programming book which was updated after Richard
Stevens passed away.

Arnold

From lars at nocrew.org  Mon Sep 16 22:26:31 2019
From: lars at nocrew.org (Lars Brinkhoff)
Date: Mon, 16 Sep 2019 12:26:31 +0000
Subject: [TUHS] earliest Unix roff
In-Reply-To: <CAC20D2N89jOBK+T9EPn8JKNaSOUx=yDr9t4=CcyHM+3qnB2bEg@mail.gmail.com>
 (Clem Cole's message of "Mon, 16 Sep 2019 08:10:48 -0400")
References: <CAC20D2NmXGzN7imTKy-RRWRZ2ewWMEmUV9oDuP3-e3a4R+ynpA@mail.gmail.com>
 <CAC20D2PXYWpv-8BQNKvUjgT=2W81GgzaOLyZiQ5=sM9+LXCWnw@mail.gmail.com>
 <CAC20D2MDbmoeMZq1esbuQvOCU7to0dUWsFyx98UQDLE3-c4fOA@mail.gmail.com>
 <201909132024.x8DKObEP013266@darkstar.fourwinds.com>
 <CAC20D2PvA26HMoABOcLMoS9Lu8=L3Wtx_8yK83K+vbhoMZt-hQ@mail.gmail.com>
 <463d5cc4-9bef-9ac3-a680-a5161d664dc1@aueb.gr>
 <CAC20D2Nz-ofwD41vULF2-TL8-C33heCiHvoNNbcuj6GGKhtKzQ@mail.gmail.com>
 <20190913221345.GA16129@minnie.tuhs.org>
 <CAC20D2OQD-NJaFsqsLVL_kqmCsSeUOKAr7dm71P4uN9N8m+AbQ@mail.gmail.com>
 <20190914020240.GO2046@mcvoy.com>
 <20190914024433.GA19193@minnie.tuhs.org>
 <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org>
 <201909150654.x8F6sChG021185@freefriends.org>
 <CAC20D2PfLq=J5ei+izXb2J7dSvU6=L6-GRd0gKA2ShSNg1=qBg@mail.gmail.com>
 <201909160552.x8G5qBYK025195@freefriends.org>
 <CAC20D2N89jOBK+T9EPn8JKNaSOUx=yDr9t4=CcyHM+3qnB2bEg@mail.gmail.com>
Message-ID: <7wd0g0o2a0.fsf@junk.nocrew.org>

Clem Cole wrote:
> Unix had fine tools [man(1), more(1), et al] and rms and friends felt
> the need to replace them with ITS-like programs.

Emacs and Info are rather blatantly are not anywhere near the Unix
philosophy.  (Maybe they can be useful anyway.)

However, please note that more(1) also was inspired by, almost copied
from, ITS.  Certainly the prompt --More-- is.

From chet.ramey at case.edu  Mon Sep 16 23:13:23 2019
From: chet.ramey at case.edu (Chet Ramey)
Date: Mon, 16 Sep 2019 09:13:23 -0400
Subject: [TUHS] earliest Unix roff
In-Reply-To: <CAC20D2N89jOBK+T9EPn8JKNaSOUx=yDr9t4=CcyHM+3qnB2bEg@mail.gmail.com>
References: <CAC20D2NmXGzN7imTKy-RRWRZ2ewWMEmUV9oDuP3-e3a4R+ynpA@mail.gmail.com>
 <CAC20D2PXYWpv-8BQNKvUjgT=2W81GgzaOLyZiQ5=sM9+LXCWnw@mail.gmail.com>
 <CAC20D2MDbmoeMZq1esbuQvOCU7to0dUWsFyx98UQDLE3-c4fOA@mail.gmail.com>
 <201909132024.x8DKObEP013266@darkstar.fourwinds.com>
 <CAC20D2PvA26HMoABOcLMoS9Lu8=L3Wtx_8yK83K+vbhoMZt-hQ@mail.gmail.com>
 <463d5cc4-9bef-9ac3-a680-a5161d664dc1@aueb.gr>
 <CAC20D2Nz-ofwD41vULF2-TL8-C33heCiHvoNNbcuj6GGKhtKzQ@mail.gmail.com>
 <20190913221345.GA16129@minnie.tuhs.org>
 <CAC20D2OQD-NJaFsqsLVL_kqmCsSeUOKAr7dm71P4uN9N8m+AbQ@mail.gmail.com>
 <20190914020240.GO2046@mcvoy.com> <20190914024433.GA19193@minnie.tuhs.org>
 <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org>
 <201909150654.x8F6sChG021185@freefriends.org>
 <CAC20D2PfLq=J5ei+izXb2J7dSvU6=L6-GRd0gKA2ShSNg1=qBg@mail.gmail.com>
 <201909160552.x8G5qBYK025195@freefriends.org>
 <CAC20D2N89jOBK+T9EPn8JKNaSOUx=yDr9t4=CcyHM+3qnB2bEg@mail.gmail.com>
Message-ID: <95916cf9-9aa1-f949-0f37-0ae466e38aa2@case.edu>

On 9/16/19 8:10 AM, Clem Cole wrote:

>     I use the standalone Info reader (named info) if I want to look at the
>     Info output. 
> 
> Fair enough, but be careful, while I admit I have not looked in a while,
> info(gnu) relies on emacs keybindings and a number of very emacs'ish things.
> Every time I have tried to deal with it, I have unprogram my fingers and
> reset them to emacs.
> 
> If it would have used more(1) [or even less(1)] then I would not be as annoyed.

It seems to me that the strength of info (the file format and program) is
the navigation of a menu-driven hierarchical document containing what are
essentially selectable links between sections. Something like more or less
is poorly suited to take advantage of those features.

You need a way to position the cursor with more flexibility than more gives
you.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet at case.edu    http://tiswww.cwru.edu/~chet/

From clemc at ccc.com  Mon Sep 16 23:42:56 2019
From: clemc at ccc.com (Clem Cole)
Date: Mon, 16 Sep 2019 09:42:56 -0400
Subject: [TUHS] earliest Unix roff
In-Reply-To: <7wd0g0o2a0.fsf@junk.nocrew.org>
References: <CAC20D2NmXGzN7imTKy-RRWRZ2ewWMEmUV9oDuP3-e3a4R+ynpA@mail.gmail.com>
 <CAC20D2PXYWpv-8BQNKvUjgT=2W81GgzaOLyZiQ5=sM9+LXCWnw@mail.gmail.com>
 <CAC20D2MDbmoeMZq1esbuQvOCU7to0dUWsFyx98UQDLE3-c4fOA@mail.gmail.com>
 <201909132024.x8DKObEP013266@darkstar.fourwinds.com>
 <CAC20D2PvA26HMoABOcLMoS9Lu8=L3Wtx_8yK83K+vbhoMZt-hQ@mail.gmail.com>
 <463d5cc4-9bef-9ac3-a680-a5161d664dc1@aueb.gr>
 <CAC20D2Nz-ofwD41vULF2-TL8-C33heCiHvoNNbcuj6GGKhtKzQ@mail.gmail.com>
 <20190913221345.GA16129@minnie.tuhs.org>
 <CAC20D2OQD-NJaFsqsLVL_kqmCsSeUOKAr7dm71P4uN9N8m+AbQ@mail.gmail.com>
 <20190914020240.GO2046@mcvoy.com> <20190914024433.GA19193@minnie.tuhs.org>
 <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org>
 <201909150654.x8F6sChG021185@freefriends.org>
 <CAC20D2PfLq=J5ei+izXb2J7dSvU6=L6-GRd0gKA2ShSNg1=qBg@mail.gmail.com>
 <201909160552.x8G5qBYK025195@freefriends.org>
 <CAC20D2N89jOBK+T9EPn8JKNaSOUx=yDr9t4=CcyHM+3qnB2bEg@mail.gmail.com>
 <7wd0g0o2a0.fsf@junk.nocrew.org>
Message-ID: <CAC20D2MBHSddOkjPUvat3GeF14-+oa2rMoppgFChzqOX+eUYpQ@mail.gmail.com>

On Mon, Sep 16, 2019 at 8:26 AM Lars Brinkhoff <lars at nocrew.org> wrote:

> However, please note that more(1) also was inspired by, almost copied
> from, ITS.  Certainly the prompt --More-- is.
>

Absolutely.  A friend of mine/fellow UCB grad student, Eric Shienbrood,
wrote it.  He was a MIT undergrad. And Eric happily said it was modeled
from ITS.
And before, Eric wrote it, UNIX lacked anything like it.   Which to me is
fine, t*aking an idea from another system to add a new feature that is
lacking.*

What irks me is the blatant force-feeding of any system to the users, be it
ITS, UNIX or Windows into another.   It's ok to offer an alternative
interface, but when the system has a mechanism, your tools need to be *socially
compliant* with it, not try to make 'those users become like me.'
 Frankly, that is a pretty arrogant behavior. Yes, I know the argument is
two fold.  GNU is not UNIX and we wrote it (he who has the gold, gets to
rule).

BTW:  If it makes you feel better, I've been fighting this attitude at a
number of places, particularly Intel, for years.   For instance, our dev
tools folks wrote their own Installer 'because it was easier for them and
they could use it everywhere').   That's a no-no.  If you have Windows
product, you must use Microsoft's installer, if you have a Mac, you use
what Apple gives you, if you have VMS, you used the (wretched) setld, or in
this case, for Linux its rpm/yum et al.; etc.     But they had their own
'installer group' and it was easier for >>them<< than for the users.

I think the rule of 'least astonishment' is what needs to be the high order
bit when building tools for people.   Again, offering emacs (or any other
ITS tool) is fine, but when the new tool is installed on Windows/UNIX/Mac
et.. it needs to behave itself with the rest of the system, particularly if
there is already a mechanism in place to do a support function.

Simply, I would not mind info(gnu) and texinfo(gnu) if there was a way to
created man pages (or Windows / Mac help).  But having a man page that
basically says, see figure one
<https://www.dourish.com/goodies/see-figure-1.html> is not cool.

my 2 cents from a grumpy old guy....
Clem
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190916/0e49df79/attachment.html>

From clemc at ccc.com  Tue Sep 17 00:40:09 2019
From: clemc at ccc.com (Clem Cole)
Date: Mon, 16 Sep 2019 10:40:09 -0400
Subject: [TUHS] user-level v1
In-Reply-To: <201909160603.x8G637QQ026140@freefriends.org>
References: <201909151617.x8FGHqGu100607@tahoe.cs.Dartmouth.EDU>
 <20190915201103.GA25340@minnie.tuhs.org>
 <alpine.BSF.2.21.9999.1909160802290.18105@aneurin.horsfall.org>
 <AFC45890-C786-444F-9635-AD79D03E3228@ccc.com>
 <201909160603.x8G637QQ026140@freefriends.org>
Message-ID: <CAC20D2NK4YVZG3tLt=8TM=6F73YSAisjPYnrUz6jb+uSTbQC=A@mail.gmail.com>

On Mon, Sep 16, 2019 at 2:03 AM <arnold at skeeve.com> wrote:

> No, Bill Joy did vi.  Ken Arnold did curses.  The vi code did all it's
> stuff directly with the termlib library calls.
>
Both of those statements are true.  But the other truth is that Ken took
the code from vi to create the original curses library.

You are correct, vi did not use curses as a library.  It was hard coded.

Similarly, termcap started out the same way.   In fact, I know Cornell's
fred and I thought a number of other early Unix screen editors like the
original Rand e, were hardcoded for specific terminals (I personally put
the code for the Lsi and Fox into Fred which was what we mostly had at
CMU).   As UCB got more and more different displays, the routines for
terminal control also got pulled out and put into a separate library.  Mary
Ann eventually became the main person behind it and I'll let her add the
details of who did what (I'm under the impression, wnj did the first cut of
termlib and then Mary Ann overhauled it).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190916/6ce8a31b/attachment.html>

From lm at mcvoy.com  Tue Sep 17 00:51:22 2019
From: lm at mcvoy.com (Larry McVoy)
Date: Mon, 16 Sep 2019 07:51:22 -0700
Subject: [TUHS] earliest Unix roff
In-Reply-To: <CAC20D2N89jOBK+T9EPn8JKNaSOUx=yDr9t4=CcyHM+3qnB2bEg@mail.gmail.com>
References: <CAC20D2Nz-ofwD41vULF2-TL8-C33heCiHvoNNbcuj6GGKhtKzQ@mail.gmail.com>
 <20190913221345.GA16129@minnie.tuhs.org>
 <CAC20D2OQD-NJaFsqsLVL_kqmCsSeUOKAr7dm71P4uN9N8m+AbQ@mail.gmail.com>
 <20190914020240.GO2046@mcvoy.com>
 <20190914024433.GA19193@minnie.tuhs.org>
 <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org>
 <201909150654.x8F6sChG021185@freefriends.org>
 <CAC20D2PfLq=J5ei+izXb2J7dSvU6=L6-GRd0gKA2ShSNg1=qBg@mail.gmail.com>
 <201909160552.x8G5qBYK025195@freefriends.org>
 <CAC20D2N89jOBK+T9EPn8JKNaSOUx=yDr9t4=CcyHM+3qnB2bEg@mail.gmail.com>
Message-ID: <20190916145122.GH2046@mcvoy.com>

On Mon, Sep 16, 2019 at 08:10:48AM -0400, Clem Cole wrote:
> On Mon, Sep 16, 2019 at 1:52 AM <arnold at skeeve.com> wrote:
> 
> > I use the standalone Info reader (named info) if I want to look at the
> > Info output.
> >
> Fair enough, but be careful, while I admit I have not looked in a while,
> info(gnu) relies on emacs keybindings and a number of very emacs'ish things.
> Every time I have tried to deal with it, I have unprogram my fingers and
> reset them to emacs.
> 
> If it would have used more(1) [or even less(1)] then I would not be as
> annoyed.
> Unix had fine tools [man(1), more(1), et al] and rms and friends felt the
> need to replace them with ITS-like programs.

I hate texinfo and friends.  I get why it is better than man, but man was
good enough, more than good enough, and the GNU project took everything
it could find and destroyed the man pages.

If you have something like perl that needs a zillion sub pages, info
makes sense.  For just a man page, info is horrible.

From lm at mcvoy.com  Tue Sep 17 00:52:12 2019
From: lm at mcvoy.com (Larry McVoy)
Date: Mon, 16 Sep 2019 07:52:12 -0700
Subject: [TUHS] earliest Unix roff
In-Reply-To: <CAC20D2NcnG8743kcWdx88x_u=h8aXBy-sHKn12jJVL2+GZTF1g@mail.gmail.com>
References: <CAC20D2Nz-ofwD41vULF2-TL8-C33heCiHvoNNbcuj6GGKhtKzQ@mail.gmail.com>
 <20190913221345.GA16129@minnie.tuhs.org>
 <CAC20D2OQD-NJaFsqsLVL_kqmCsSeUOKAr7dm71P4uN9N8m+AbQ@mail.gmail.com>
 <20190914020240.GO2046@mcvoy.com>
 <20190914024433.GA19193@minnie.tuhs.org>
 <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org>
 <CAC20D2M5j+pCBpxf4Cy-sK4BfBGj_RMhzSpGaXMZmeEaGV9cDA@mail.gmail.com>
 <069494b2-ec5b-91e7-8618-2d111e0e5aa2@andrewnesbit.org>
 <201909160620.x8G6KkJq026850@freefriends.org>
 <CAC20D2NcnG8743kcWdx88x_u=h8aXBy-sHKn12jJVL2+GZTF1g@mail.gmail.com>
Message-ID: <20190916145212.GI2046@mcvoy.com>

On Mon, Sep 16, 2019 at 08:13:55AM -0400, Clem Cole wrote:
> On Mon, Sep 16, 2019 at 2:21 AM <arnold at skeeve.com> wrote:
> 
> > I'm not sure that Prentice-Hall had its own macros. Rather, the
> > books from Bell Labs were all set on the same research Unix systems.
> >
> That's might be true for bwk's and Pike's stuff, but not Rich Steven's or
> Comer's books.   I know for fact that Rich had a set of macro's (based
> originally on -ms) and a set of integrated makefiles to build his texts.  I
> was under the impression he passed them to a number of people, not just
> people like me.

I don't have them but he and I had many discussions about troff, tbl,
pic, etc.  We had a shared love for pic.

From clemc at ccc.com  Tue Sep 17 00:53:09 2019
From: clemc at ccc.com (Clem Cole)
Date: Mon, 16 Sep 2019 10:53:09 -0400
Subject: [TUHS] INed/Rand Editor/Ned [was Re: My EuroBSDcon talk
 (preview for commentary)
In-Reply-To: <B2C11377-D557-4542-94D9-31E3D9C789D6@technologists.com>
References: <CANCZdfrK4iFQCWOFP4MoUggpfJVmoJ0dnSg6H0cCi4dop7sVXw@mail.gmail.com>
 <CAC20D2Nq+eTQDdft5nW8kKcWFdt9ZK4-5kJX6OcMcYBffk9HGA@mail.gmail.com>
 <20190915232524.9A5491570CE9@mail.bitblocks.com>
 <CANCZdfr83yx7eUu-t+j-D8z9TMSkuAvPpb81hJdk95070gmZcA@mail.gmail.com>
 <7F62BF6B-8FEA-4C43-9E35-05BDE9BF04EA@ccc.com>
 <CAKr6gn3dKiFCr3D4sYv1+xJbD4cHq5X6AFEtz8MF7NtKdnY6dw@mail.gmail.com>
 <20190916023738.F34E81570CE9@mail.bitblocks.com>
 <B2C11377-D557-4542-94D9-31E3D9C789D6@technologists.com>
Message-ID: <CAC20D2MfPCf7Dqke_U=Bod+WeZnvpszrgo7TwpeJB5G3CsG+oA@mail.gmail.com>

On Sun, Sep 15, 2019 at 11:37 PM Charles H. Sauer <sauer at technologists.com>
wrote:

> The first Unix I used was PC/ix on an XT. I don’t know it even had vi, but
> it had INed, which I assume was the ISC evolution of NED & Rand Editor.
>
Yes, that is correct.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190916/b6def258/attachment.html>

From lm at mcvoy.com  Tue Sep 17 00:54:28 2019
From: lm at mcvoy.com (Larry McVoy)
Date: Mon, 16 Sep 2019 07:54:28 -0700
Subject: [TUHS] earliest Unix roff
In-Reply-To: <CAC20D2MBHSddOkjPUvat3GeF14-+oa2rMoppgFChzqOX+eUYpQ@mail.gmail.com>
References: <CAC20D2OQD-NJaFsqsLVL_kqmCsSeUOKAr7dm71P4uN9N8m+AbQ@mail.gmail.com>
 <20190914020240.GO2046@mcvoy.com>
 <20190914024433.GA19193@minnie.tuhs.org>
 <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org>
 <201909150654.x8F6sChG021185@freefriends.org>
 <CAC20D2PfLq=J5ei+izXb2J7dSvU6=L6-GRd0gKA2ShSNg1=qBg@mail.gmail.com>
 <201909160552.x8G5qBYK025195@freefriends.org>
 <CAC20D2N89jOBK+T9EPn8JKNaSOUx=yDr9t4=CcyHM+3qnB2bEg@mail.gmail.com>
 <7wd0g0o2a0.fsf@junk.nocrew.org>
 <CAC20D2MBHSddOkjPUvat3GeF14-+oa2rMoppgFChzqOX+eUYpQ@mail.gmail.com>
Message-ID: <20190916145428.GJ2046@mcvoy.com>

Holy smokes, Clem, you are me and I am you.  I couldn't agree more with 
this post, especially 'least astonishment'.

On Mon, Sep 16, 2019 at 09:42:56AM -0400, Clem Cole wrote:
> What irks me is the blatant force-feeding of any system to the users, be it
> ITS, UNIX or Windows into another.   It's ok to offer an alternative
> interface, but when the system has a mechanism, your tools need to be *socially
> compliant* with it, not try to make 'those users become like me.'
>  Frankly, that is a pretty arrogant behavior. Yes, I know the argument is
> two fold.  GNU is not UNIX and we wrote it (he who has the gold, gets to
> rule).
> 
> BTW:  If it makes you feel better, I've been fighting this attitude at a
> number of places, particularly Intel, for years.   For instance, our dev
> tools folks wrote their own Installer 'because it was easier for them and
> they could use it everywhere').   That's a no-no.  If you have Windows
> product, you must use Microsoft's installer, if you have a Mac, you use
> what Apple gives you, if you have VMS, you used the (wretched) setld, or in
> this case, for Linux its rpm/yum et al.; etc.     But they had their own
> 'installer group' and it was easier for >>them<< than for the users.
> 
> I think the rule of 'least astonishment' is what needs to be the high order
> bit when building tools for people.   Again, offering emacs (or any other
> ITS tool) is fine, but when the new tool is installed on Windows/UNIX/Mac
> et.. it needs to behave itself with the rest of the system, particularly if
> there is already a mechanism in place to do a support function.
> 
> Simply, I would not mind info(gnu) and texinfo(gnu) if there was a way to
> created man pages (or Windows / Mac help).  But having a man page that
> basically says, see figure one
> <https://www.dourish.com/goodies/see-figure-1.html> is not cool.
> 
> my 2 cents from a grumpy old guy....
> Clem

-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 

From clemc at ccc.com  Tue Sep 17 00:57:43 2019
From: clemc at ccc.com (Clem Cole)
Date: Mon, 16 Sep 2019 10:57:43 -0400
Subject: [TUHS] earliest Unix roff
In-Reply-To: <20190916145122.GH2046@mcvoy.com>
References: <CAC20D2Nz-ofwD41vULF2-TL8-C33heCiHvoNNbcuj6GGKhtKzQ@mail.gmail.com>
 <20190913221345.GA16129@minnie.tuhs.org>
 <CAC20D2OQD-NJaFsqsLVL_kqmCsSeUOKAr7dm71P4uN9N8m+AbQ@mail.gmail.com>
 <20190914020240.GO2046@mcvoy.com> <20190914024433.GA19193@minnie.tuhs.org>
 <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org>
 <201909150654.x8F6sChG021185@freefriends.org>
 <CAC20D2PfLq=J5ei+izXb2J7dSvU6=L6-GRd0gKA2ShSNg1=qBg@mail.gmail.com>
 <201909160552.x8G5qBYK025195@freefriends.org>
 <CAC20D2N89jOBK+T9EPn8JKNaSOUx=yDr9t4=CcyHM+3qnB2bEg@mail.gmail.com>
 <20190916145122.GH2046@mcvoy.com>
Message-ID: <CAC20D2Nwe=AycD+QywLPaRC8HCT5_U09KBeoV3+G6d9+Avidmw@mail.gmail.com>

On Mon, Sep 16, 2019 at 10:51 AM Larry McVoy <lm at mcvoy.com> wrote:

> I hate texinfo and friends.  I get why it is better than man, but man was
> good enough, more than good enough, and the GNU project took everything
> it could find and destroyed the man pages.
>
Amen, bro.   As I said, it was not 'social compliant' which was really a
not very nice thing to do.   It's arrogant to say in effect "your way is
wrong, I'm going to try to kill it off."


>
> If you have something like perl that needs a zillion sub pages, info
> makes sense.  For just a man page, info is horrible.

I'm not even sure, I like that, to be honest. I'm 'old school' enough to
rather use a book from ORA or the like.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190916/562968c6/attachment.html>

From rich.salz at gmail.com  Tue Sep 17 01:14:25 2019
From: rich.salz at gmail.com (Richard Salz)
Date: Mon, 16 Sep 2019 11:14:25 -0400
Subject: [TUHS] earliest Unix roff
In-Reply-To: <CAC20D2Nwe=AycD+QywLPaRC8HCT5_U09KBeoV3+G6d9+Avidmw@mail.gmail.com>
References: <CAC20D2Nz-ofwD41vULF2-TL8-C33heCiHvoNNbcuj6GGKhtKzQ@mail.gmail.com>
 <20190913221345.GA16129@minnie.tuhs.org>
 <CAC20D2OQD-NJaFsqsLVL_kqmCsSeUOKAr7dm71P4uN9N8m+AbQ@mail.gmail.com>
 <20190914020240.GO2046@mcvoy.com> <20190914024433.GA19193@minnie.tuhs.org>
 <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org>
 <201909150654.x8F6sChG021185@freefriends.org>
 <CAC20D2PfLq=J5ei+izXb2J7dSvU6=L6-GRd0gKA2ShSNg1=qBg@mail.gmail.com>
 <201909160552.x8G5qBYK025195@freefriends.org>
 <CAC20D2N89jOBK+T9EPn8JKNaSOUx=yDr9t4=CcyHM+3qnB2bEg@mail.gmail.com>
 <20190916145122.GH2046@mcvoy.com>
 <CAC20D2Nwe=AycD+QywLPaRC8HCT5_U09KBeoV3+G6d9+Avidmw@mail.gmail.com>
Message-ID: <CAFH29tpP6joyHDAQTKj41bwAscqa0HO8g7EKwxXv3Vbscqc58A@mail.gmail.com>

Is it any surprise that the early GNU effort was really trying to recreate
ITS?  Can you really blame them?  I'm grateful that they made `info` be a
standalone program.  Putting the concept of "cursor position" into the
existing pagers (more/less/etc) and doing jump/xref/back would be more than
a stretch, IMO.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190916/b41cf616/attachment.html>

From ron at ronnatalie.com  Tue Sep 17 01:48:34 2019
From: ron at ronnatalie.com (Ronald Natalie)
Date: Mon, 16 Sep 2019 11:48:34 -0400
Subject: [TUHS] earliest Unix roff
In-Reply-To: <CAFH29tpP6joyHDAQTKj41bwAscqa0HO8g7EKwxXv3Vbscqc58A@mail.gmail.com>
References: <CAC20D2Nz-ofwD41vULF2-TL8-C33heCiHvoNNbcuj6GGKhtKzQ@mail.gmail.com>
 <20190913221345.GA16129@minnie.tuhs.org>
 <CAC20D2OQD-NJaFsqsLVL_kqmCsSeUOKAr7dm71P4uN9N8m+AbQ@mail.gmail.com>
 <20190914020240.GO2046@mcvoy.com> <20190914024433.GA19193@minnie.tuhs.org>
 <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org>
 <201909150654.x8F6sChG021185@freefriends.org>
 <CAC20D2PfLq=J5ei+izXb2J7dSvU6=L6-GRd0gKA2ShSNg1=qBg@mail.gmail.com>
 <201909160552.x8G5qBYK025195@freefriends.org>
 <CAC20D2N89jOBK+T9EPn8JKNaSOUx=yDr9t4=CcyHM+3qnB2bEg@mail.gmail.com>
 <20190916145122.GH2046@mcvoy.com>
 <CAC20D2Nwe=AycD+QywLPaRC8HCT5_U09KBeoV3+G6d9+Avidmw@mail.gmail.com>
 <CAFH29tpP6joyHDAQTKj41bwAscqa0HO8g7EKwxXv3Vbscqc58A@mail.gmail.com>
Message-ID: <C35AC261-CC3C-4EB2-9ADF-F8D57C4EC5FF@ronnatalie.com>



> On Sep 16, 2019, at 11:14 AM, Richard Salz <rich.salz at gmail.com> wrote:
> 
> Is it any surprise that the early GNU effort was really trying to recreate ITS?  Can you really blame them?  I'm grateful that they made `info` be a standalone program.  Putting the concept of "cursor position" into the existing pagers (more/less/etc) and doing jump/xref/back would be more than a stretch, IMO.
> 

Having been an early UNIX Emacs adoptee (I never really learned VI, if there was no emacs, I just used ed.    A tendency that my employees always found amusing), I could never tolerate INFO in any of its forms (either ITS or on UNIX).
It was far too cumbersome for the features it claimed to add to the mix.

As for formatters, my biggest gripe with many of them is that I should not be able to tell what the formatter is by looking at the output.   This is where Tex fails.    It’s ugly style always seems to telegraph through.   The only thing that is worse is those odd little bumps on the top of pic-framed tbl output.   

From paul.winalski at gmail.com  Tue Sep 17 02:09:35 2019
From: paul.winalski at gmail.com (Paul Winalski)
Date: Mon, 16 Sep 2019 12:09:35 -0400
Subject: [TUHS] earliest Unix roff
In-Reply-To: <CAC20D2MBHSddOkjPUvat3GeF14-+oa2rMoppgFChzqOX+eUYpQ@mail.gmail.com>
References: <CAC20D2NmXGzN7imTKy-RRWRZ2ewWMEmUV9oDuP3-e3a4R+ynpA@mail.gmail.com>
 <CAC20D2PXYWpv-8BQNKvUjgT=2W81GgzaOLyZiQ5=sM9+LXCWnw@mail.gmail.com>
 <CAC20D2MDbmoeMZq1esbuQvOCU7to0dUWsFyx98UQDLE3-c4fOA@mail.gmail.com>
 <201909132024.x8DKObEP013266@darkstar.fourwinds.com>
 <CAC20D2PvA26HMoABOcLMoS9Lu8=L3Wtx_8yK83K+vbhoMZt-hQ@mail.gmail.com>
 <463d5cc4-9bef-9ac3-a680-a5161d664dc1@aueb.gr>
 <CAC20D2Nz-ofwD41vULF2-TL8-C33heCiHvoNNbcuj6GGKhtKzQ@mail.gmail.com>
 <20190913221345.GA16129@minnie.tuhs.org>
 <CAC20D2OQD-NJaFsqsLVL_kqmCsSeUOKAr7dm71P4uN9N8m+AbQ@mail.gmail.com>
 <20190914020240.GO2046@mcvoy.com> <20190914024433.GA19193@minnie.tuhs.org>
 <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org>
 <201909150654.x8F6sChG021185@freefriends.org>
 <CAC20D2PfLq=J5ei+izXb2J7dSvU6=L6-GRd0gKA2ShSNg1=qBg@mail.gmail.com>
 <201909160552.x8G5qBYK025195@freefriends.org>
 <CAC20D2N89jOBK+T9EPn8JKNaSOUx=yDr9t4=CcyHM+3qnB2bEg@mail.gmail.com>
 <7wd0g0o2a0.fsf@junk.nocrew.org>
 <CAC20D2MBHSddOkjPUvat3GeF14-+oa2rMoppgFChzqOX+eUYpQ@mail.gmail.com>
Message-ID: <CABH=_VQe2NmosDkh8uu1eh0-D6siRs7EdDs0-g1Nya-j9Z8HZA@mail.gmail.com>

On 9/16/19, Clem Cole <clemc at ccc.com> wrote:
> On Mon, Sep 16, 2019 at 8:26 AM Lars Brinkhoff <lars at nocrew.org> wrote:
>
> What irks me is the blatant force-feeding of any system to the users, be it
> ITS, UNIX or Windows into another.   It's ok to offer an alternative
> interface, but when the system has a mechanism, your tools need to be
> *socially
> compliant* with it, not try to make 'those users become like me.'
>  Frankly, that is a pretty arrogant behavior. Yes, I know the argument is
> two fold.  GNU is not UNIX and we wrote it (he who has the gold, gets to
> rule).

Amen to that!  As the old saying goes, "when in Rome, do as the Romans
do".  On UNIX, tools are expected to send output to stdout.  On
Windows, users expect text selection and ^C/^V copy-and-paste to work.
On VMS, you use the CLI interface to parse the command line.  And so
on.  The principle of least astonishment should always be foremost in
user interaction design.

> BTW:  If it makes you feel better, I've been fighting this attitude at a
> number of places, particularly Intel, for years.   For instance, our dev
> tools folks wrote their own Installer 'because it was easier for them and
> they could use it everywhere').   That's a no-no.  If you have Windows
> product, you must use Microsoft's installer, if you have a Mac, you use
> what Apple gives you, if you have VMS, you used the (wretched) setld, or in
> this case, for Linux its rpm/yum et al.; etc.     But they had their own
> 'installer group' and it was easier for >>them<< than for the users.

I used to work in that organization.  The installer situation is one
of the worst cases of not-invented-here syndrome that I've ever seen.
Or maybe it was just empire building by some ambitious manager.  The
"it's easier for us and we can use it everywhere" argument is pure BS.
Any savings that they got from having the a common code base for the
installer was wiped out by all the extra development effort needed to
track the release-to-release changes that the various platforms made
to their software deployment setup.  Their installer was always a step
or two behind the curve, late in supporting new platform features, and
full of subtle bugs and mis-implemented edge conditions.  It wasn't
really "easier for them" in the long run after all.  It was a
maintenance nightmare.

-Paul W.

From lm at mcvoy.com  Tue Sep 17 02:10:40 2019
From: lm at mcvoy.com (Larry McVoy)
Date: Mon, 16 Sep 2019 09:10:40 -0700
Subject: [TUHS] earliest Unix roff
In-Reply-To: <CAFH29tpP6joyHDAQTKj41bwAscqa0HO8g7EKwxXv3Vbscqc58A@mail.gmail.com>
References: <20190914020240.GO2046@mcvoy.com>
 <20190914024433.GA19193@minnie.tuhs.org>
 <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org>
 <201909150654.x8F6sChG021185@freefriends.org>
 <CAC20D2PfLq=J5ei+izXb2J7dSvU6=L6-GRd0gKA2ShSNg1=qBg@mail.gmail.com>
 <201909160552.x8G5qBYK025195@freefriends.org>
 <CAC20D2N89jOBK+T9EPn8JKNaSOUx=yDr9t4=CcyHM+3qnB2bEg@mail.gmail.com>
 <20190916145122.GH2046@mcvoy.com>
 <CAC20D2Nwe=AycD+QywLPaRC8HCT5_U09KBeoV3+G6d9+Avidmw@mail.gmail.com>
 <CAFH29tpP6joyHDAQTKj41bwAscqa0HO8g7EKwxXv3Vbscqc58A@mail.gmail.com>
Message-ID: <20190916161040.GM2046@mcvoy.com>

On Mon, Sep 16, 2019 at 11:14:25AM -0400, Richard Salz wrote:
> Is it any surprise that the early GNU effort was really trying to recreate
> ITS?  Can you really blame them?  I'm grateful that they made `info` be a
> standalone program.  Putting the concept of "cursor position" into the
> existing pagers (more/less/etc) and doing jump/xref/back would be more than
> a stretch, IMO.

It's what Clem said.  You should acclimate yourself to your environment.
Pushing info into man environment is a lot like being an immigrant and
wanting to bring your laws into your new homeland.  That isn't a thing
and shouldn't be a thing.  Doesn't matter that people think ITS is better,
they are in Unix.  If you think ITS is better, go live there.

When in Rome....

From jon at fourwinds.com  Tue Sep 17 02:16:03 2019
From: jon at fourwinds.com (Jon Steinhart)
Date: Mon, 16 Sep 2019 09:16:03 -0700
Subject: [TUHS] earliest Unix roff
In-Reply-To: <20190916161040.GM2046@mcvoy.com>
References: <20190914020240.GO2046@mcvoy.com>
 <20190914024433.GA19193@minnie.tuhs.org>
 <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org>
 <201909150654.x8F6sChG021185@freefriends.org>
 <CAC20D2PfLq=J5ei+izXb2J7dSvU6=L6-GRd0gKA2ShSNg1=qBg@mail.gmail.com>
 <201909160552.x8G5qBYK025195@freefriends.org>
 <CAC20D2N89jOBK+T9EPn8JKNaSOUx=yDr9t4=CcyHM+3qnB2bEg@mail.gmail.com>
 <20190916145122.GH2046@mcvoy.com>
 <CAC20D2Nwe=AycD+QywLPaRC8HCT5_U09KBeoV3+G6d9+Avidmw@mail.gmail.com>
 <CAFH29tpP6joyHDAQTKj41bwAscqa0HO8g7EKwxXv3Vbscqc58A@mail.gmail.com>
 <20190916161040.GM2046@mcvoy.com>
Message-ID: <201909161616.x8GGG4Fb020760@darkstar.fourwinds.com>

Larry McVoy writes:
> On Mon, Sep 16, 2019 at 11:14:25AM -0400, Richard Salz wrote:
> > Is it any surprise that the early GNU effort was really trying to recreate
> > ITS?  Can you really blame them?  I'm grateful that they made `info` be a
> > standalone program.  Putting the concept of "cursor position" into the
> > existing pagers (more/less/etc) and doing jump/xref/back would be more than
> > a stretch, IMO.
>
> It's what Clem said.  You should acclimate yourself to your environment.
> Pushing info into man environment is a lot like being an immigrant and
> wanting to bring your laws into your new homeland.  That isn't a thing
> and shouldn't be a thing.  Doesn't matter that people think ITS is better,
> they are in Unix.  If you think ITS is better, go live there.
>
> When in Rome....

Well, in the shameless department, I can quote from my book:

	Mucking up the ecosystem into which you release code does not
	add value. Many developers behave as if they’re stereotypical
	Americans vacationing in another country, or for that matter my
	father-in-law visiting — the “I just came to your place, so do
	things my way” attitude.

	For example, UNIX systems have a command that displays manual pages
	for programs. You can type man foo and it’ll show you the page
	for the foo command. There’s also a convention that really complex
	commands, such as yacc , have both a manual page and a longer, more
	in-depth document that describes the program in more detail. When
	the GNU project (which I’ll discuss shortly) added commands to
	UNIX, it used its own texinfo system for manuals, which wasn’t
	compatible with the man system. The result was that users would have
	to try both the man and info commands to find documentation. Even
	if, as some believe, the GNU approach was superior, any possible
	benefits were outweighed by the UNIX community’s huge loss of
	productivity that resulted from the fragmented ecosystem.

From imp at bsdimp.com  Tue Sep 17 02:16:12 2019
From: imp at bsdimp.com (Warner Losh)
Date: Mon, 16 Sep 2019 17:16:12 +0100
Subject: [TUHS] INed/Rand Editor/Ned [was Re: My EuroBSDcon talk
 (preview for commentary)
In-Reply-To: <CAC20D2MfPCf7Dqke_U=Bod+WeZnvpszrgo7TwpeJB5G3CsG+oA@mail.gmail.com>
References: <CANCZdfrK4iFQCWOFP4MoUggpfJVmoJ0dnSg6H0cCi4dop7sVXw@mail.gmail.com>
 <CAC20D2Nq+eTQDdft5nW8kKcWFdt9ZK4-5kJX6OcMcYBffk9HGA@mail.gmail.com>
 <20190915232524.9A5491570CE9@mail.bitblocks.com>
 <CANCZdfr83yx7eUu-t+j-D8z9TMSkuAvPpb81hJdk95070gmZcA@mail.gmail.com>
 <7F62BF6B-8FEA-4C43-9E35-05BDE9BF04EA@ccc.com>
 <CAKr6gn3dKiFCr3D4sYv1+xJbD4cHq5X6AFEtz8MF7NtKdnY6dw@mail.gmail.com>
 <20190916023738.F34E81570CE9@mail.bitblocks.com>
 <B2C11377-D557-4542-94D9-31E3D9C789D6@technologists.com>
 <CAC20D2MfPCf7Dqke_U=Bod+WeZnvpszrgo7TwpeJB5G3CsG+oA@mail.gmail.com>
Message-ID: <CANCZdfoL2JGwhE1kn3sckUrREKq=v9+6oLm1H8gAf446y87SQg@mail.gmail.com>

On Mon, Sep 16, 2019, 3:53 PM Clem Cole <clemc at ccc.com> wrote:

>
>
> On Sun, Sep 15, 2019 at 11:37 PM Charles H. Sauer <sauer at technologists.com>
> wrote:
>
>> The first Unix I used was PC/ix on an XT. I don’t know it even had vi,
>> but it had INed, which I assume was the ISC evolution of NED & Rand Editor.
>>
> Yes, that is correct.
>

Venix had vi. At least 2.0 pulled that in from Berkeley...

I got to look at the source to a few other editors of the era. All has the
terminal codes hard coded into them... it was common to do that before
things like termcap...

Warner

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190916/feb6c4ce/attachment.html>

From lm at mcvoy.com  Tue Sep 17 02:26:14 2019
From: lm at mcvoy.com (Larry McVoy)
Date: Mon, 16 Sep 2019 09:26:14 -0700
Subject: [TUHS] earliest Unix roff
In-Reply-To: <201909161616.x8GGG4Fb020760@darkstar.fourwinds.com>
References: <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org>
 <201909150654.x8F6sChG021185@freefriends.org>
 <CAC20D2PfLq=J5ei+izXb2J7dSvU6=L6-GRd0gKA2ShSNg1=qBg@mail.gmail.com>
 <201909160552.x8G5qBYK025195@freefriends.org>
 <CAC20D2N89jOBK+T9EPn8JKNaSOUx=yDr9t4=CcyHM+3qnB2bEg@mail.gmail.com>
 <20190916145122.GH2046@mcvoy.com>
 <CAC20D2Nwe=AycD+QywLPaRC8HCT5_U09KBeoV3+G6d9+Avidmw@mail.gmail.com>
 <CAFH29tpP6joyHDAQTKj41bwAscqa0HO8g7EKwxXv3Vbscqc58A@mail.gmail.com>
 <20190916161040.GM2046@mcvoy.com>
 <201909161616.x8GGG4Fb020760@darkstar.fourwinds.com>
Message-ID: <20190916162614.GO2046@mcvoy.com>

+1

On Mon, Sep 16, 2019 at 09:16:03AM -0700, Jon Steinhart wrote:
> Larry McVoy writes:
> > On Mon, Sep 16, 2019 at 11:14:25AM -0400, Richard Salz wrote:
> > > Is it any surprise that the early GNU effort was really trying to recreate
> > > ITS?  Can you really blame them?  I'm grateful that they made `info` be a
> > > standalone program.  Putting the concept of "cursor position" into the
> > > existing pagers (more/less/etc) and doing jump/xref/back would be more than
> > > a stretch, IMO.
> >
> > It's what Clem said.  You should acclimate yourself to your environment.
> > Pushing info into man environment is a lot like being an immigrant and
> > wanting to bring your laws into your new homeland.  That isn't a thing
> > and shouldn't be a thing.  Doesn't matter that people think ITS is better,
> > they are in Unix.  If you think ITS is better, go live there.
> >
> > When in Rome....
> 
> Well, in the shameless department, I can quote from my book:
> 
> 	Mucking up the ecosystem into which you release code does not
> 	add value. Many developers behave as if they???re stereotypical
> 	Americans vacationing in another country, or for that matter my
> 	father-in-law visiting ??? the ???I just came to your place, so do
> 	things my way??? attitude.
> 
> 	For example, UNIX systems have a command that displays manual pages
> 	for programs. You can type man foo and it???ll show you the page
> 	for the foo command. There???s also a convention that really complex
> 	commands, such as yacc , have both a manual page and a longer, more
> 	in-depth document that describes the program in more detail. When
> 	the GNU project (which I???ll discuss shortly) added commands to
> 	UNIX, it used its own texinfo system for manuals, which wasn???t
> 	compatible with the man system. The result was that users would have
> 	to try both the man and info commands to find documentation. Even
> 	if, as some believe, the GNU approach was superior, any possible
> 	benefits were outweighed by the UNIX community???s huge loss of
> 	productivity that resulted from the fragmented ecosystem.

-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 

From rich.salz at gmail.com  Tue Sep 17 02:31:13 2019
From: rich.salz at gmail.com (Richard Salz)
Date: Mon, 16 Sep 2019 12:31:13 -0400
Subject: [TUHS] earliest Unix roff
In-Reply-To: <20190916162614.GO2046@mcvoy.com>
References: <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org>
 <201909150654.x8F6sChG021185@freefriends.org>
 <CAC20D2PfLq=J5ei+izXb2J7dSvU6=L6-GRd0gKA2ShSNg1=qBg@mail.gmail.com>
 <201909160552.x8G5qBYK025195@freefriends.org>
 <CAC20D2N89jOBK+T9EPn8JKNaSOUx=yDr9t4=CcyHM+3qnB2bEg@mail.gmail.com>
 <20190916145122.GH2046@mcvoy.com>
 <CAC20D2Nwe=AycD+QywLPaRC8HCT5_U09KBeoV3+G6d9+Avidmw@mail.gmail.com>
 <CAFH29tpP6joyHDAQTKj41bwAscqa0HO8g7EKwxXv3Vbscqc58A@mail.gmail.com>
 <20190916161040.GM2046@mcvoy.com>
 <201909161616.x8GGG4Fb020760@darkstar.fourwinds.com>
 <20190916162614.GO2046@mcvoy.com>
Message-ID: <CAFH29toVUNEn7qNak3BeRhXhBYtx2OA0JpTGXBB3rnUyFhtU4w@mail.gmail.com>

I don't think it's totally GNU's fault that it became Linux.  They weren't
trying to be tourists in Rome, they were trying to create a new city of
their own.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190916/df126e9c/attachment.html>

From lm at mcvoy.com  Tue Sep 17 02:45:02 2019
From: lm at mcvoy.com (Larry McVoy)
Date: Mon, 16 Sep 2019 09:45:02 -0700
Subject: [TUHS] earliest Unix roff
In-Reply-To: <CAFH29toVUNEn7qNak3BeRhXhBYtx2OA0JpTGXBB3rnUyFhtU4w@mail.gmail.com>
References: <CAC20D2PfLq=J5ei+izXb2J7dSvU6=L6-GRd0gKA2ShSNg1=qBg@mail.gmail.com>
 <201909160552.x8G5qBYK025195@freefriends.org>
 <CAC20D2N89jOBK+T9EPn8JKNaSOUx=yDr9t4=CcyHM+3qnB2bEg@mail.gmail.com>
 <20190916145122.GH2046@mcvoy.com>
 <CAC20D2Nwe=AycD+QywLPaRC8HCT5_U09KBeoV3+G6d9+Avidmw@mail.gmail.com>
 <CAFH29tpP6joyHDAQTKj41bwAscqa0HO8g7EKwxXv3Vbscqc58A@mail.gmail.com>
 <20190916161040.GM2046@mcvoy.com>
 <201909161616.x8GGG4Fb020760@darkstar.fourwinds.com>
 <20190916162614.GO2046@mcvoy.com>
 <CAFH29toVUNEn7qNak3BeRhXhBYtx2OA0JpTGXBB3rnUyFhtU4w@mail.gmail.com>
Message-ID: <20190916164502.GQ2046@mcvoy.com>

On Mon, Sep 16, 2019 at 12:31:13PM -0400, Richard Salz wrote:
> I don't think it's totally GNU's fault that it became Linux.  They weren't
> trying to be tourists in Rome, they were trying to create a new city of
> their own.

Yeah, except they didn't create their own city, they pooped all over a
different one.  There is no defense for what they did.  If they did the
right thing they would have created a markup language that could have
produced info files and man files.

It's not that hard, I wrote something called webroff that took -ms
format input and produced a website complete with the navigation tree,
it defaulted to showing you a page (each .NH) at time but it also had
a site map where you could see the entire document as a single page,
or each major section (.NH 1) as a page.

For more than a decade this was BitMover's home page.  I can't tell
you how many sales calls I've been on and I've seen the entire web
site printed out on the manager's desk.

The reality is there was absolutely no need for a new format for
info files, they could have parsed man input and produced info 
files and that's what they should have done.

Those who defend the choice of info over man just aren't real Unix
people.  And that's fine, Unix isn't the only choice, they can go
run some other OS and be happy.  But it's just rude to thrust info
into a Unix system.  And lame because they could have parsed man
pages into info docs and then they are adopting the Unix way of
doing things and actually adding value.

From clemc at ccc.com  Tue Sep 17 03:00:24 2019
From: clemc at ccc.com (Clem Cole)
Date: Mon, 16 Sep 2019 13:00:24 -0400
Subject: [TUHS] earliest Unix roff
In-Reply-To: <CAFH29toVUNEn7qNak3BeRhXhBYtx2OA0JpTGXBB3rnUyFhtU4w@mail.gmail.com>
References: <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org>
 <201909150654.x8F6sChG021185@freefriends.org>
 <CAC20D2PfLq=J5ei+izXb2J7dSvU6=L6-GRd0gKA2ShSNg1=qBg@mail.gmail.com>
 <201909160552.x8G5qBYK025195@freefriends.org>
 <CAC20D2N89jOBK+T9EPn8JKNaSOUx=yDr9t4=CcyHM+3qnB2bEg@mail.gmail.com>
 <20190916145122.GH2046@mcvoy.com>
 <CAC20D2Nwe=AycD+QywLPaRC8HCT5_U09KBeoV3+G6d9+Avidmw@mail.gmail.com>
 <CAFH29tpP6joyHDAQTKj41bwAscqa0HO8g7EKwxXv3Vbscqc58A@mail.gmail.com>
 <20190916161040.GM2046@mcvoy.com>
 <201909161616.x8GGG4Fb020760@darkstar.fourwinds.com>
 <20190916162614.GO2046@mcvoy.com>
 <CAFH29toVUNEn7qNak3BeRhXhBYtx2OA0JpTGXBB3rnUyFhtU4w@mail.gmail.com>
Message-ID: <CAC20D2MXJHWNBs7Yc-Mnw1n4Qsf-cOzKshziG5-G0h-fHt9Kbg@mail.gmail.com>

I note that it wasn't "GNI" it was GNU or he would have started with LISP.

The fact is rms started by wanting to hack/rewrite Gosling EMACS as it had
been released and some of the other C versions were at the same time a
little less open to him as a starting point.  Since it was not in LISP, he
needed to write a C Compiler (which I still think is the #1 positive thing
from the Gnu project and in the end, I believe that it was others that
really made the compiler the success, not rms other than he tirelessly
championed it).  The reality is that the Gnu team quick set out  to rewrite
the UNIX tools and used Trix (a UNIX clone) as the original OS. Hurd did
not come until later and in the Linux became the kernel it lived upon (as
Jon says, it's Internet/Linux not Gnu/Linux).

Sorry, IMO, rms tried to 'pee on Unix to make it smell like ITS' - not
surprising as you say.  But pretty darned arrogant none-the less. The
results makes using many of the tools "astonishing" to everyone else.

+1 to Jon's comments.

"Even if, as some believe, the GNU approach was superior, any possible benefits
were outweighed by the UNIX community’s huge loss of productivity that
resulted from the fragmented ecosystem."

Amen brother Jon, and this week's free will offering will be sponsoring ....

On Mon, Sep 16, 2019 at 12:31 PM Richard Salz <rich.salz at gmail.com> wrote:

> I don't think it's totally GNU's fault that it became Linux.  They weren't
> trying to be tourists in Rome, they were trying to create a new city of
> their own.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190916/ee55ec32/attachment.html>

From steffen at sdaoden.eu  Tue Sep 17 03:23:00 2019
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Mon, 16 Sep 2019 19:23:00 +0200
Subject: [TUHS] SCCS
In-Reply-To: <20190914015517.GD12480@mcvoy.com>
References: <20190911181101.GF3143@mcvoy.com>
 <alpine.BSF.2.21.9999.1909120846160.18105@aneurin.horsfall.org>
 <20190912034346.GJ2046@mcvoy.com>
 <a0231faa-8ad9-fa51-4b24-9854beb21210@gmail.com>
 <1457a2d6-2f17-482d-e4f7-ace439d34ca8@neophilic.com>
 <CAC20D2OZpnma4EX+PqgqfA7zNM7sofuDQ4zCURnLF7-G4TCKhQ@mail.gmail.com>
 <8db2e89c-ce50-a453-e38a-ecdfe69a746c@e-bbes.com>
 <20190913211104.aMZXy%steffen@sdaoden.eu> <20190913211751.GF2046@mcvoy.com>
 <20190913230312.XaeCQ%steffen@sdaoden.eu> <20190914015517.GD12480@mcvoy.com>
Message-ID: <20190916172300.cjlkf%steffen@sdaoden.eu>

Hello.

Please excuse the late reply, your message (and many more) landed
in the spam folder, i have adjusted the subject again.

Larry McVoy wrote in <20190914015517.GD12480 at mcvoy.com>:
 |On Sat, Sep 14, 2019 at 01:03:12AM +0200, Steffen Nurpmeso wrote:
 |> He is as convinced from SCCS and its interleaved deltas as you
 |> are, but he works on extending the plain original SCCS, which is
 |> pretty smaller; his presentation from the "Chemnitzer Linux Tage
 |> 2012" (linux days of former Karl-Marx-Stadt) [1] talks about this
 |> and also prominently mentions BitKeeper:
 |> 
 |>   . All modern distributed OSS version control systems base upon
 |>     BitKeeper in the end.
 |
 |Sort of.  Monotone, Darcs, and one other one I can't remember did not
 |draw from BitKeeper.  Mercurial, Git, and the Australian one that I
 |can't remember definitely do.
 |
 |>   . BitKeeper bases upon the ideas of TeamWare.
 |
 |Only in that I am the primary author of both.  It does support the idea
 |that SCCS is the basis for both, though Teamware used the real SCCS and
 |I rewrote SCCS from scratch and then extended it quite a bit.  BitKeeper's
 |SCCS tracks a lot more than SCCS does, pathnames, permissions, hostnames,
 |etc.

Regarding the technical background Jörg mentions US Patent 5481722
on merging deltas of source code control for computer software
development that Glenn Skinner of Sun holds.

 |>   . TeamWare bases upon the ideas of NSE.
 |
 |That's absolutely false.  TeamWare, which is the productized version
 |of NSElite, which I wrote all of, was a reaction to how absolute shiite
 |NSE was.  I had friends in the Sun kernel group that quit because they
 |were forced to use NSE.  It was awful.  I got into source management 
 |because I was well known at Sun as the guy that could fix performance
 |problems so I was asked to look at NSE.  One look told me that I couldn't
 |fix NSE but the source management problem space needed some help.
 |
 |>   . NSE is a frontend to SCCS.
 |
 |That's true.
 |
 |>   . Therewith all modern systems ultimately base upon SCCS.
 |
 |That is a big stretch, it's just not true.  I love the SCCS file 
 |format but to say all modern systems are based on SCCS is 100%
 |false.  BitKeeper is.  That's it.
 |
 |>   . Distributed operate TeamWare, BitKeeper, git, Mercurial.
 |
 |Git and Mercurial were going for append only data structures. 
 |That's not SCCS.
 |
 |All this comes from Jorg, isn't he the guy who has a track record of
 |being on the outside of Sun and trying to argue with me about what Sun
 |was doing when I was a well known guy in the most important group at Sun,
 |the kernel group.  If so, I'd salt his stuff heavily.

This is the Jörg Schilling with whom you have had a dispute on
this list, yes.  But i do not share this track record of yours.
To me he is a person who distributed parts of my free software
infrastructure when that was much smaller than today, and enabled
me to burn CDs, which was a thing in the ninetees.  And to the
best of my knowledge he was an actor behind the berliOS open
source hub, which lost its financial support alongside other
German software projects (afaik) in the second half of the 2000's,
and therefore rebased its users to Sourceforge.  And more.

I do not know about Sun let alone its internals, but i know for
sure he worked with Sun code already in the 80s, and it seems he
worked for a company who was working with Sun code very tightly.
Since he is from Berlin where all the friendly communicative
people come from it seems not unlikely that he got good hooks here
and there, so why not.

One thing he says, and which is an interesting part of this
thread, is

  Die Behauptung von Eric Allman Tichy hätte SCCS Version
  1 verwendet kann ich nicht glauben, denn die Veröffentlichungen
  von Tichy sind von 1982 und SCCS war seit Februar 1977 auf der
  Version 4. SCCS Version 3 hatte übrigens noch ein binäres
  Historyformat.

  The statement of Eric Allman that Tichy used SCCS version
  1 i cannot believe, because Tichy's releases are from 1982, and
  SCCS version 4 was released as earyl as February 1977.  SCCS
  version 3 used a binary history format, by the way.

That should have addressed Eric Allman, but the longer i use email
in the public space the more i like that pub-like feeling.  (And
not going to add that it reminds me of my childhood, where i was
a boy under elder seasoned men _also_.)

 |I think he means well but is a little out there.  Though some people
 |might say the same about me.

I also think he means well.  The rest i do not know about,
Larry McVoy.  I am a Buddhist also, and the Austrian Emperor even
wanted to pardon also a woman who i think tortured and killed her
own child, and the death penalty came back only due to massive
pressure from the population.  Jörg in turn says, i cite (and
translate a bit loose), "Larry is good, but regarding himself
a little bit too offensive".  Without meaning any harm i think
this can well be said, and is a key for making it in New York,
without ever having been there.  Bob Dylan even went electric!

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

From lm at mcvoy.com  Tue Sep 17 03:24:22 2019
From: lm at mcvoy.com (Larry McVoy)
Date: Mon, 16 Sep 2019 10:24:22 -0700
Subject: [TUHS] earliest Unix roff
In-Reply-To: <20190916171905.piituc2qdh46kejt@unixfarts.net>
References: <CAC20D2N89jOBK+T9EPn8JKNaSOUx=yDr9t4=CcyHM+3qnB2bEg@mail.gmail.com>
 <20190916145122.GH2046@mcvoy.com>
 <CAC20D2Nwe=AycD+QywLPaRC8HCT5_U09KBeoV3+G6d9+Avidmw@mail.gmail.com>
 <CAFH29tpP6joyHDAQTKj41bwAscqa0HO8g7EKwxXv3Vbscqc58A@mail.gmail.com>
 <20190916161040.GM2046@mcvoy.com>
 <201909161616.x8GGG4Fb020760@darkstar.fourwinds.com>
 <20190916162614.GO2046@mcvoy.com>
 <CAFH29toVUNEn7qNak3BeRhXhBYtx2OA0JpTGXBB3rnUyFhtU4w@mail.gmail.com>
 <20190916164502.GQ2046@mcvoy.com>
 <20190916171905.piituc2qdh46kejt@unixfarts.net>
Message-ID: <20190916172422.GS2046@mcvoy.com>

On Mon, Sep 16, 2019 at 07:19:05PM +0200, KatolaZ wrote:
> On Mon, Sep 16, 2019 at 09:45:02AM -0700, Larry McVoy wrote:
> 
> [cut]
> 
> > 
> > Those who defend the choice of info over man just aren't real Unix
> > people.  And that's fine, Unix isn't the only choice, they can go
> > run some other OS and be happy.  But it's just rude to thrust info
> > into a Unix system.  And lame because they could have parsed man
> > pages into info docs and then they are adopting the Unix way of
> > doing things and actually adding value.
> 
> Sorry, but I totally don't see the point here. 

Jon put it well, the point is people expect to be able to say 

	man foo

and have that work.  Until GNU came along, that's the way it was.
GNU pushed a different system into the mix.

The secondary point is they could have *added* to Unix by making a
man2info command, I know they could have because I've done something
similar, parsing man or -ms pages is trivial.

GNU choose not to do that and I can't begin to express how wrong 
that was.  GNU is not Unix for sure.

From clemc at ccc.com  Tue Sep 17 03:24:23 2019
From: clemc at ccc.com (Clem Cole)
Date: Mon, 16 Sep 2019 13:24:23 -0400
Subject: [TUHS] earliest Unix roff
In-Reply-To: <20190916164502.GQ2046@mcvoy.com>
References: <CAC20D2PfLq=J5ei+izXb2J7dSvU6=L6-GRd0gKA2ShSNg1=qBg@mail.gmail.com>
 <201909160552.x8G5qBYK025195@freefriends.org>
 <CAC20D2N89jOBK+T9EPn8JKNaSOUx=yDr9t4=CcyHM+3qnB2bEg@mail.gmail.com>
 <20190916145122.GH2046@mcvoy.com>
 <CAC20D2Nwe=AycD+QywLPaRC8HCT5_U09KBeoV3+G6d9+Avidmw@mail.gmail.com>
 <CAFH29tpP6joyHDAQTKj41bwAscqa0HO8g7EKwxXv3Vbscqc58A@mail.gmail.com>
 <20190916161040.GM2046@mcvoy.com>
 <201909161616.x8GGG4Fb020760@darkstar.fourwinds.com>
 <20190916162614.GO2046@mcvoy.com>
 <CAFH29toVUNEn7qNak3BeRhXhBYtx2OA0JpTGXBB3rnUyFhtU4w@mail.gmail.com>
 <20190916164502.GQ2046@mcvoy.com>
Message-ID: <CAC20D2P18CLbHVVJ_1R15puBfetBgqjtRijwbk82tf=12e-uhQ@mail.gmail.com>

On Mon, Sep 16, 2019 at 12:45 PM Larry McVoy <lm at mcvoy.com> wrote:

> Yeah, except they didn't create their own city, they pooped all over a
> different one.

peed *vs.* pooped -  one is marking territory while the other is destroying
it.
It is interesting that both analogs work here, however.

There is no defense for what they did.  If they did the
> right thing they would have created a markup language that could have
> produced info files and man files.
>
+1 and that's why it is even more difficult to understand.   Being polite
and 'fitting in' would really not been any harder than being like Jon's
father-in-law.


> ....
> Those who defend the choice of info over man just aren't real Unix people.

I'd maybe say it as they don't want to be real Unix people and fit it with
the rest.



> And that's fine, Unix isn't the only choice, they can go
> run some other OS and be happy.

Frankly, trying to turn a Lisp Machine into a "Unix box" would have been as
much of sin, in my eyes. Hey, I'm thrilled to see rms and his friends can
build and purchase as many LMI box as he would like (But I do observe, the
'technically superior system,' in the end, wasn't very economical).   I
really don't mind bringing things over (like more, or job control, or
command/filename completion that all came from other systems).  That is
really adding value to the new system (UNIX in this case).


But it's just rude to thrust info
> into a Unix system.  And lame because they could have parsed man
> pages into info docs and then they are adopting the Unix way of
> doing things and actually adding value.

touché

As Larry and Jon have said better than I, it was the seemly effect of trying
to replace man with info that I just don't understand.     As Larry has
said if they had made a way go from texinfo to man, even if it had been a
little rough on the edges, I might have grumbled, but I would have tried to
use it.  The truth is today, like many other Unix hacker I know, if I am
offered a new tool but using it means that I am being led down a path to use
info/texinfo, I rethink if I want to use that new tool or not.   It's a big
turn off for me to want to learn to use such a tool since I know the
authors have made no attempt to integrate it into a traditional UNIX
workflow if they have not built proper man pages, much less written
traditional docs.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190916/84f32d4e/attachment.html>

From katolaz at freaknet.org  Tue Sep 17 03:19:05 2019
From: katolaz at freaknet.org (KatolaZ)
Date: Mon, 16 Sep 2019 19:19:05 +0200
Subject: [TUHS] earliest Unix roff
In-Reply-To: <20190916164502.GQ2046@mcvoy.com>
References: <201909160552.x8G5qBYK025195@freefriends.org>
 <CAC20D2N89jOBK+T9EPn8JKNaSOUx=yDr9t4=CcyHM+3qnB2bEg@mail.gmail.com>
 <20190916145122.GH2046@mcvoy.com>
 <CAC20D2Nwe=AycD+QywLPaRC8HCT5_U09KBeoV3+G6d9+Avidmw@mail.gmail.com>
 <CAFH29tpP6joyHDAQTKj41bwAscqa0HO8g7EKwxXv3Vbscqc58A@mail.gmail.com>
 <20190916161040.GM2046@mcvoy.com>
 <201909161616.x8GGG4Fb020760@darkstar.fourwinds.com>
 <20190916162614.GO2046@mcvoy.com>
 <CAFH29toVUNEn7qNak3BeRhXhBYtx2OA0JpTGXBB3rnUyFhtU4w@mail.gmail.com>
 <20190916164502.GQ2046@mcvoy.com>
Message-ID: <20190916171905.piituc2qdh46kejt@unixfarts.net>

On Mon, Sep 16, 2019 at 09:45:02AM -0700, Larry McVoy wrote:

[cut]

> 
> Those who defend the choice of info over man just aren't real Unix
> people.  And that's fine, Unix isn't the only choice, they can go
> run some other OS and be happy.  But it's just rude to thrust info
> into a Unix system.  And lame because they could have parsed man
> pages into info docs and then they are adopting the Unix way of
> doing things and actually adding value.

Sorry, but I totally don't see the point here. The problem is not the
technology, but the adopters. I personally don't like info at all, and
still swear whenever a software comes without a proper manpage, but
info has not been shovelled down your throat (or anybody else's, for
that matter). The adopters have decided that info was fine for their
use case. They could have written manpages and send patches over, and
in many cases they didn't.

There is plenty of software coming from the GNU project that has
comprehensive and clear manpages (just to cite a single example,
bash(1) comes with manpages, and no info doc). At the same time, there
is tons of "Unix" software around that comes without any documentation
*at all*, or with scant text files covering the bare basics.

Unfortunately this trend is only getting worse, and we have far too
many notaable examples here, not all of them coming from the GNU
project, or from the "ITS tradition", whatever it means for you.

I agree that whoever does not produce a readily usable documentaion
for their software has not really understood much of the Unix
philosophy. But that's not at all a matter of formats, rather of
culture.

Then, if you just want to vomit on info, or you prefer to use info as
another excuse to vomit on the GNU project, well go ahead. But the
actual issue is elsewhere (the lack of respect for the users, and the
tendency to hide stuff under the carpet), and has not been introduced
by the GNU project, at all.

My2Cents

Enzo Nicosia
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190916/8778ec70/attachment.sig>

From jon at fourwinds.com  Tue Sep 17 03:32:15 2019
From: jon at fourwinds.com (Jon Steinhart)
Date: Mon, 16 Sep 2019 10:32:15 -0700
Subject: [TUHS] earliest Unix roff
In-Reply-To: <20190916172422.GS2046@mcvoy.com>
References: <CAC20D2N89jOBK+T9EPn8JKNaSOUx=yDr9t4=CcyHM+3qnB2bEg@mail.gmail.com>
 <20190916145122.GH2046@mcvoy.com>
 <CAC20D2Nwe=AycD+QywLPaRC8HCT5_U09KBeoV3+G6d9+Avidmw@mail.gmail.com>
 <CAFH29tpP6joyHDAQTKj41bwAscqa0HO8g7EKwxXv3Vbscqc58A@mail.gmail.com>
 <20190916161040.GM2046@mcvoy.com>
 <201909161616.x8GGG4Fb020760@darkstar.fourwinds.com>
 <20190916162614.GO2046@mcvoy.com>
 <CAFH29toVUNEn7qNak3BeRhXhBYtx2OA0JpTGXBB3rnUyFhtU4w@mail.gmail.com>
 <20190916164502.GQ2046@mcvoy.com>
 <20190916171905.piituc2qdh46kejt@unixfarts.net>
 <20190916172422.GS2046@mcvoy.com>
Message-ID: <201909161732.x8GHWFjS007598@darkstar.fourwinds.com>

Larry McVoy writes:
> On Mon, Sep 16, 2019 at 07:19:05PM +0200, KatolaZ wrote:
> > On Mon, Sep 16, 2019 at 09:45:02AM -0700, Larry McVoy wrote:
> > 
> > [cut]
> > 
> > > 
> > > Those who defend the choice of info over man just aren't real Unix
> > > people.  And that's fine, Unix isn't the only choice, they can go
> > > run some other OS and be happy.  But it's just rude to thrust info
> > > into a Unix system.  And lame because they could have parsed man
> > > pages into info docs and then they are adopting the Unix way of
> > > doing things and actually adding value.
> > 
> > Sorry, but I totally don't see the point here. 
>
> Jon put it well, the point is people expect to be able to say 
>
> 	man foo
>
> and have that work.  Until GNU came along, that's the way it was.
> GNU pushed a different system into the mix.
>
> The secondary point is they could have *added* to Unix by making a
> man2info command, I know they could have because I've done something
> similar, parsing man or -ms pages is trivial.
>
> GNU choose not to do that and I can't begin to express how wrong 
> that was.  GNU is not Unix for sure.

So I'm not really trying to be all that shameless, it's just that I've already
written down my opinions on this sort of stuff and don't need to retype it all.
>From a section entitled "The Value Proposition":

	There's an overarching question that you should keep in mind when
	working on a project: "Am I adding value?" I'm not talking about
	the intrinsic value of accomplishing some task here; I'm talking
	about increasing productivity.

	If you're programming for a living, you need to meet whatever goals
	your employer has set. But, of course, there's more than one way
	to meet those goals. You could just do what you need to do to get
	by. Or, you could put a little thought into things that might not
	have occurred to management.  For example, you might realize that
	your code would be useful in another project and structure it so
	it's easily reusable. Or, you might sense that you were tasked to
	implement a special case of a more general problem and solve that
	general problem instead, paving the way for future enhancements.
	Of course, you should talk about this with management so that
	they're not surprised.

	You can add value to yourself by making sure that you're proficient
	in a variety of technologies. Side projects are a common way to
	get experience; it's equivalent to doing homework but more fun.

	One classic way in which people attempt to add value is by
	creating tools. This is trickier than it seems because sometimes
	adding value for yourself reduces value for others. People often
	create new tools because some feature that they think they need
	is missing from existing ones. A good example is the make utility
	(invented by Stuart Feldman at Bell Labs in 1976), which is used to
	build large software packages. As time went on, new features were
	needed. Some of these were added to make, but in many other cases,
	people created well-intentioned but incompatible new utilities
	that performed similar functions. (For example, I consulted for
	a company once that wrote their own solely because they didn't
	bother to completely read the make documentation and were unaware
	that it would do exactly what they needed.) Now there's make,
	cmake, dmake, imake, pick-a-letter-make, and other programs that
	all do similar things in incompatible ways. The result is that
	practitioners like you need to learn multiple tools in each category.
	It makes everyone's life harder, not easier. It doesn't add
	value—it detracts. Figure 15-1 sums up the situation nicely.
	[ Figure 15-1 is the xkcd how standards proliferate cartoon ]

From clemc at ccc.com  Tue Sep 17 03:35:36 2019
From: clemc at ccc.com (Clem Cole)
Date: Mon, 16 Sep 2019 13:35:36 -0400
Subject: [TUHS] earliest Unix roff
In-Reply-To: <20190916172422.GS2046@mcvoy.com>
References: <CAC20D2N89jOBK+T9EPn8JKNaSOUx=yDr9t4=CcyHM+3qnB2bEg@mail.gmail.com>
 <20190916145122.GH2046@mcvoy.com>
 <CAC20D2Nwe=AycD+QywLPaRC8HCT5_U09KBeoV3+G6d9+Avidmw@mail.gmail.com>
 <CAFH29tpP6joyHDAQTKj41bwAscqa0HO8g7EKwxXv3Vbscqc58A@mail.gmail.com>
 <20190916161040.GM2046@mcvoy.com>
 <201909161616.x8GGG4Fb020760@darkstar.fourwinds.com>
 <20190916162614.GO2046@mcvoy.com>
 <CAFH29toVUNEn7qNak3BeRhXhBYtx2OA0JpTGXBB3rnUyFhtU4w@mail.gmail.com>
 <20190916164502.GQ2046@mcvoy.com>
 <20190916171905.piituc2qdh46kejt@unixfarts.net>
 <20190916172422.GS2046@mcvoy.com>
Message-ID: <CAC20D2OPzkChp1Afjam4maGwCkj7+kCt-P=FxkZ2+LYEwVoHFA@mail.gmail.com>

On Mon, Sep 16, 2019 at 1:24 PM Larry McVoy <lm at mcvoy.com> wrote:

> The secondary point is they could have *added* to Unix by making a
> man2info command
>

Exactly!!!!   That's what Eric did when he wrote more(ucb) -  he *added to
Unix*.   The funny part was that USG thought more(ucb) was a good idea and
then wrote their own, pg(att); which was just as arrogant as the info
behavior from the Gnu folks!!!   Later, Less(internet) replaced more, but
only as a superset, building on the foundation and eventually USB chose to
ship more also as so many people wanted it.

As I said yesterday, standing on the shoulders, not on their toes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190916/cf4880f6/attachment.html>

From jon at fourwinds.com  Tue Sep 17 03:37:03 2019
From: jon at fourwinds.com (Jon Steinhart)
Date: Mon, 16 Sep 2019 10:37:03 -0700
Subject: [TUHS] earliest Unix roff
In-Reply-To: <20190916171905.piituc2qdh46kejt@unixfarts.net>
References: <201909160552.x8G5qBYK025195@freefriends.org>
 <CAC20D2N89jOBK+T9EPn8JKNaSOUx=yDr9t4=CcyHM+3qnB2bEg@mail.gmail.com>
 <20190916145122.GH2046@mcvoy.com>
 <CAC20D2Nwe=AycD+QywLPaRC8HCT5_U09KBeoV3+G6d9+Avidmw@mail.gmail.com>
 <CAFH29tpP6joyHDAQTKj41bwAscqa0HO8g7EKwxXv3Vbscqc58A@mail.gmail.com>
 <20190916161040.GM2046@mcvoy.com>
 <201909161616.x8GGG4Fb020760@darkstar.fourwinds.com>
 <20190916162614.GO2046@mcvoy.com>
 <CAFH29toVUNEn7qNak3BeRhXhBYtx2OA0JpTGXBB3rnUyFhtU4w@mail.gmail.com>
 <20190916164502.GQ2046@mcvoy.com>
 <20190916171905.piituc2qdh46kejt@unixfarts.net>
Message-ID: <201909161737.x8GHb3SG008244@darkstar.fourwinds.com>

KatolaZ writes:
> Sorry, but I totally don't see the point here. The problem is not the
> technology, but the adopters. I personally don't like info at all, and
> still swear whenever a software comes without a proper manpage, but
> info has not been shovelled down your throat (or anybody else's, for
> that matter). The adopters have decided that info was fine for their
> use case. They could have written manpages and send patches over, and
> in many cases they didn't.
>
> There is plenty of software coming from the GNU project that has
> comprehensive and clear manpages (just to cite a single example,
> bash(1) comes with manpages, and no info doc). At the same time, there
> is tons of "Unix" software around that comes without any documentation
> *at all*, or with scant text files covering the bare basics.
>
> Unfortunately this trend is only getting worse, and we have far too
> many notaable examples here, not all of them coming from the GNU
> project, or from the "ITS tradition", whatever it means for you.
>
> I agree that whoever does not produce a readily usable documentaion
> for their software has not really understood much of the Unix
> philosophy. But that's not at all a matter of formats, rather of
> culture.
>
> Then, if you just want to vomit on info, or you prefer to use info as
> another excuse to vomit on the GNU project, well go ahead. But the
> actual issue is elsewhere (the lack of respect for the users, and the
> tendency to hide stuff under the carpet), and has not been introduced
> by the GNU project, at all.
>
> My2Cents
>
> Enzo Nicosia

It seems to me that you're missing the point here.  It's not a question of
whether or not GNU programs have good documentation.  It's the fact that
GNU made it hard to find documentation because they took one pile and split
it into two with no guide to what was in each pile.  It's not that their
documentation was good or bad, it's that they made it hard to find any
documentation.

Maybe it's because I'm a child of the 60s, but I'm with Arlo Guthrie on this
one (from Alice's Restaurant): "And we decided that one big pile is better
than two little piles, and rather than bring that one up we decided to throw
ours down."

Jon

From chet.ramey at case.edu  Tue Sep 17 04:04:00 2019
From: chet.ramey at case.edu (Chet Ramey)
Date: Mon, 16 Sep 2019 14:04:00 -0400
Subject: [TUHS] earliest Unix roff
In-Reply-To: <20190916171905.piituc2qdh46kejt@unixfarts.net>
References: <201909160552.x8G5qBYK025195@freefriends.org>
 <CAC20D2N89jOBK+T9EPn8JKNaSOUx=yDr9t4=CcyHM+3qnB2bEg@mail.gmail.com>
 <20190916145122.GH2046@mcvoy.com>
 <CAC20D2Nwe=AycD+QywLPaRC8HCT5_U09KBeoV3+G6d9+Avidmw@mail.gmail.com>
 <CAFH29tpP6joyHDAQTKj41bwAscqa0HO8g7EKwxXv3Vbscqc58A@mail.gmail.com>
 <20190916161040.GM2046@mcvoy.com>
 <201909161616.x8GGG4Fb020760@darkstar.fourwinds.com>
 <20190916162614.GO2046@mcvoy.com>
 <CAFH29toVUNEn7qNak3BeRhXhBYtx2OA0JpTGXBB3rnUyFhtU4w@mail.gmail.com>
 <20190916164502.GQ2046@mcvoy.com>
 <20190916171905.piituc2qdh46kejt@unixfarts.net>
Message-ID: <2d65ed3d-87a6-e3f4-7917-9611b631a100@case.edu>

On 9/16/19 1:19 PM, KatolaZ wrote:

> There is plenty of software coming from the GNU project that has
> comprehensive and clear manpages (just to cite a single example,
> bash(1) comes with manpages, and no info doc). 

Bash comes with both a large man page and an extensive info doc.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet at case.edu    http://tiswww.cwru.edu/~chet/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190916/75ec5756/attachment.sig>

From katolaz at freaknet.org  Tue Sep 17 04:09:43 2019
From: katolaz at freaknet.org (KatolaZ)
Date: Mon, 16 Sep 2019 20:09:43 +0200
Subject: [TUHS] [OT] Re:  earliest Unix roff
In-Reply-To: <201909161737.x8GHb3SG008244@darkstar.fourwinds.com>
References: <20190916145122.GH2046@mcvoy.com>
 <CAC20D2Nwe=AycD+QywLPaRC8HCT5_U09KBeoV3+G6d9+Avidmw@mail.gmail.com>
 <CAFH29tpP6joyHDAQTKj41bwAscqa0HO8g7EKwxXv3Vbscqc58A@mail.gmail.com>
 <20190916161040.GM2046@mcvoy.com>
 <201909161616.x8GGG4Fb020760@darkstar.fourwinds.com>
 <20190916162614.GO2046@mcvoy.com>
 <CAFH29toVUNEn7qNak3BeRhXhBYtx2OA0JpTGXBB3rnUyFhtU4w@mail.gmail.com>
 <20190916164502.GQ2046@mcvoy.com>
 <20190916171905.piituc2qdh46kejt@unixfarts.net>
 <201909161737.x8GHb3SG008244@darkstar.fourwinds.com>
Message-ID: <20190916180942.qlipaxn4hq7of3kd@unixfarts.net>

On Mon, Sep 16, 2019 at 10:37:03AM -0700, Jon Steinhart wrote:

[cut]

> 
> It seems to me that you're missing the point here.  It's not a question of
> whether or not GNU programs have good documentation.  It's the fact that
> GNU made it hard to find documentation because they took one pile and split
> it into two with no guide to what was in each pile.  It's not that their
> documentation was good or bad, it's that they made it hard to find any
> documentation.
> 
> Maybe it's because I'm a child of the 60s, but I'm with Arlo Guthrie on this
> one (from Alice's Restaurant): "And we decided that one big pile is better
> than two little piles, and rather than bring that one up we decided to throw
> ours down."
>

Dear Jon, I am a child of the 70s, so I know the drill ;)

What I am saying is that the vast majority of the software from the
GNU project actually has a good-quality manpage acoompanying it. And
it also has the same documentation in info format. Hence I see no
point in vomiting on info (which I mostly dislike anyway, as I said),
as on any other document format, as long as the same information is
made available via manpages as well, as it is the case for most of the
software present in current Unix systems, wherever it comes from. The
split caused by the introduction of info has mainly been cured by the
community, maybe too late, but still.

We can discuss whether the split was necessary or "right" in the first
instance, as we could discuss whether it was good or not for cat(1) to
leave Murray Hill in 1979 with no options and come back from Berkley
with a source code doubled in size and 9 options in 1982. We could do
that, but perhaps we shouldn't get too partisan, since the history of
Unix is not a simple single-threaded and linear one, as the many
insightful contributions posted in this ML show. It's a continuum,
where it is difficult to find any single element which is totally
right or totally wrong.

I honestly see more danger in the recent trend that avoids
documentation altogether, except for a scant README.md file at the top
of the sources. There is an entire generation of developers who see
little value in producing (and using) online documentation, where by
online I mean manpage-like or info-like docs. For the simple reason
that the main way in which documentation is produced and distributed
has changed a lot in the last 25 years. Now it's all about googling
the right words, unfortunately.

We can keep blaming RMS, info, or the GNU project, but indeed blaming
them for the Web would be a bit too much ;)

And this is perhaps becoming OT anyway.

HND

Enzo Nicosia


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190916/7bd8f337/attachment.sig>

From jon at fourwinds.com  Tue Sep 17 04:19:09 2019
From: jon at fourwinds.com (Jon Steinhart)
Date: Mon, 16 Sep 2019 11:19:09 -0700
Subject: [TUHS] [OT] Re:  earliest Unix roff
In-Reply-To: <20190916180942.qlipaxn4hq7of3kd@unixfarts.net>
References: <20190916145122.GH2046@mcvoy.com>
 <CAC20D2Nwe=AycD+QywLPaRC8HCT5_U09KBeoV3+G6d9+Avidmw@mail.gmail.com>
 <CAFH29tpP6joyHDAQTKj41bwAscqa0HO8g7EKwxXv3Vbscqc58A@mail.gmail.com>
 <20190916161040.GM2046@mcvoy.com>
 <201909161616.x8GGG4Fb020760@darkstar.fourwinds.com>
 <20190916162614.GO2046@mcvoy.com>
 <CAFH29toVUNEn7qNak3BeRhXhBYtx2OA0JpTGXBB3rnUyFhtU4w@mail.gmail.com>
 <20190916164502.GQ2046@mcvoy.com>
 <20190916171905.piituc2qdh46kejt@unixfarts.net>
 <201909161737.x8GHb3SG008244@darkstar.fourwinds.com>
 <20190916180942.qlipaxn4hq7of3kd@unixfarts.net>
Message-ID: <201909161819.x8GIJ9Om014429@darkstar.fourwinds.com>

KatolaZ writes:
> Dear Jon, I am a child of the 70s, so I know the drill ;)
>
> What I am saying is that the vast majority of the software from the
> GNU project actually has a good-quality manpage acoompanying it. And
> it also has the same documentation in info format. Hence I see no
> point in vomiting on info (which I mostly dislike anyway, as I said),
> as on any other document format, as long as the same information is
> made available via manpages as well, as it is the case for most of the
> software present in current Unix systems, wherever it comes from. The
> split caused by the introduction of info has mainly been cured by the
> community, maybe too late, but still.
>
> We can discuss whether the split was necessary or "right" in the first
> instance, as we could discuss whether it was good or not for cat(1) to
> leave Murray Hill in 1979 with no options and come back from Berkley
> with a source code doubled in size and 9 options in 1982. We could do
> that, but perhaps we shouldn't get too partisan, since the history of
> Unix is not a simple single-threaded and linear one, as the many
> insightful contributions posted in this ML show. It's a continuum,
> where it is difficult to find any single element which is totally
> right or totally wrong.
>
> I honestly see more danger in the recent trend that avoids
> documentation altogether, except for a scant README.md file at the top
> of the sources. There is an entire generation of developers who see
> little value in producing (and using) online documentation, where by
> online I mean manpage-like or info-like docs. For the simple reason
> that the main way in which documentation is produced and distributed
> has changed a lot in the last 25 years. Now it's all about googling
> the right words, unfortunately.
>
> We can keep blaming RMS, info, or the GNU project, but indeed blaming
> them for the Web would be a bit too much ;)
>
> And this is perhaps becoming OT anyway.
>
> HND
>
> Enzo Nicosia

Well, maybe we're just violently agreeing.  Again, while I think that
info is klunky-feeling, my issue is the ecosystem fragmentation.

I think that it's not our place to discuss cat as Rob is on the list
and he owns that :-)

I do agree that the utter lack of any documentation is a bigger problem.
Or worse, the document that says how to download, build, and install a
package without ever saying what it does or how to use it.

I'm not blaming RMS or GNU, I'm just using them as examples of a way of
doing things that I don't like.  I certainly don't blame them for the web.
Please let's not get started on that!

Jon

From katolaz at freaknet.org  Tue Sep 17 04:19:50 2019
From: katolaz at freaknet.org (KatolaZ)
Date: Mon, 16 Sep 2019 20:19:50 +0200
Subject: [TUHS] earliest Unix roff
In-Reply-To: <2d65ed3d-87a6-e3f4-7917-9611b631a100@case.edu>
References: <20190916145122.GH2046@mcvoy.com>
 <CAC20D2Nwe=AycD+QywLPaRC8HCT5_U09KBeoV3+G6d9+Avidmw@mail.gmail.com>
 <CAFH29tpP6joyHDAQTKj41bwAscqa0HO8g7EKwxXv3Vbscqc58A@mail.gmail.com>
 <20190916161040.GM2046@mcvoy.com>
 <201909161616.x8GGG4Fb020760@darkstar.fourwinds.com>
 <20190916162614.GO2046@mcvoy.com>
 <CAFH29toVUNEn7qNak3BeRhXhBYtx2OA0JpTGXBB3rnUyFhtU4w@mail.gmail.com>
 <20190916164502.GQ2046@mcvoy.com>
 <20190916171905.piituc2qdh46kejt@unixfarts.net>
 <2d65ed3d-87a6-e3f4-7917-9611b631a100@case.edu>
Message-ID: <20190916181949.uhzg2gipcqfinhol@unixfarts.net>

On Mon, Sep 16, 2019 at 02:04:00PM -0400, Chet Ramey wrote:
> On 9/16/19 1:19 PM, KatolaZ wrote:
> 
> > There is plenty of software coming from the GNU project that has
> > comprehensive and clear manpages (just to cite a single example,
> > bash(1) comes with manpages, and no info doc). 
> 
> Bash comes with both a large man page and an extensive info doc.
> 

Yep, sorry! I meant "and not only an info doc". And they are both of
very good quality, IMHO.

HND

Enzo Nicosia
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190916/11287e9c/attachment.sig>

From steffen at sdaoden.eu  Tue Sep 17 05:13:44 2019
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Mon, 16 Sep 2019 21:13:44 +0200
Subject: [TUHS] earliest Unix roff
In-Reply-To: <CAFH29tpP6joyHDAQTKj41bwAscqa0HO8g7EKwxXv3Vbscqc58A@mail.gmail.com>
References: <CAC20D2Nz-ofwD41vULF2-TL8-C33heCiHvoNNbcuj6GGKhtKzQ@mail.gmail.com>
 <20190913221345.GA16129@minnie.tuhs.org>
 <CAC20D2OQD-NJaFsqsLVL_kqmCsSeUOKAr7dm71P4uN9N8m+AbQ@mail.gmail.com>
 <20190914020240.GO2046@mcvoy.com> <20190914024433.GA19193@minnie.tuhs.org>
 <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org>
 <201909150654.x8F6sChG021185@freefriends.org>
 <CAC20D2PfLq=J5ei+izXb2J7dSvU6=L6-GRd0gKA2ShSNg1=qBg@mail.gmail.com>
 <201909160552.x8G5qBYK025195@freefriends.org>
 <CAC20D2N89jOBK+T9EPn8JKNaSOUx=yDr9t4=CcyHM+3qnB2bEg@mail.gmail.com>
 <20190916145122.GH2046@mcvoy.com>
 <CAC20D2Nwe=AycD+QywLPaRC8HCT5_U09KBeoV3+G6d9+Avidmw@mail.gmail.com>
 <CAFH29tpP6joyHDAQTKj41bwAscqa0HO8g7EKwxXv3Vbscqc58A@mail.gmail.com>
Message-ID: <20190916191344.yjsVn%steffen@sdaoden.eu>

Richard Salz wrote in <CAFH29tpP6joyHDAQTKj41bwAscqa0HO8g7EKwxXv3Vbscqc5\
8A at mail.gmail.com>:
 |Is it any surprise that the early GNU effort was really trying to recreate \
 |ITS?  Can you really blame them?  I'm grateful that they made `info` \
 |be a standalone program.  Putting the concept of "cursor 
 |position" into the existing pagers (more/less/etc) and doing jump/xref/b\
 |ack would be more than a stretch, IMO.

So that is actually not true, really.

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

From bakul at bitblocks.com  Tue Sep 17 05:31:30 2019
From: bakul at bitblocks.com (Bakul Shah)
Date: Mon, 16 Sep 2019 12:31:30 -0700
Subject: [TUHS] earliest Unix roff
In-Reply-To: <CAFH29tpP6joyHDAQTKj41bwAscqa0HO8g7EKwxXv3Vbscqc58A@mail.gmail.com>
References: <CAC20D2Nz-ofwD41vULF2-TL8-C33heCiHvoNNbcuj6GGKhtKzQ@mail.gmail.com>
 <20190913221345.GA16129@minnie.tuhs.org>
 <CAC20D2OQD-NJaFsqsLVL_kqmCsSeUOKAr7dm71P4uN9N8m+AbQ@mail.gmail.com>
 <20190914020240.GO2046@mcvoy.com> <20190914024433.GA19193@minnie.tuhs.org>
 <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org>
 <201909150654.x8F6sChG021185@freefriends.org>
 <CAC20D2PfLq=J5ei+izXb2J7dSvU6=L6-GRd0gKA2ShSNg1=qBg@mail.gmail.com>
 <201909160552.x8G5qBYK025195@freefriends.org>
 <CAC20D2N89jOBK+T9EPn8JKNaSOUx=yDr9t4=CcyHM+3qnB2bEg@mail.gmail.com>
 <20190916145122.GH2046@mcvoy.com>
 <CAC20D2Nwe=AycD+QywLPaRC8HCT5_U09KBeoV3+G6d9+Avidmw@mail.gmail.com>
 <CAFH29tpP6joyHDAQTKj41bwAscqa0HO8g7EKwxXv3Vbscqc58A@mail.gmail.com>
Message-ID: <28BD5CAE-F826-4A38-8587-A90C0235A484@bitblocks.com>

The way Rob solved the problem in acme(1) is much nicer.
Right click on |open(2)| and its man page opens up in a
new window. You can do the same on any manpage mentioned
in the SEE ALSO section or anywhere else and you can see
their man page without any side-effect on the original
window. He didn't throw out any old documentation but
added a a new tool to make navigation easier (and it is
more general in that you can define right click actions).

There was already cursor positioning available in vi. It
would not have been a real stretch to hack in acme like
support in less or vi (clumsier without a mouse but still).
In fact tag support in vi already did something like it
with ^] and ^^ for jump/back.


> On Sep 16, 2019, at 8:14 AM, Richard Salz <rich.salz at gmail.com> wrote:
> 
> Is it any surprise that the early GNU effort was really trying to recreate ITS?  Can you really blame them?  I'm grateful that they made `info` be a standalone program.  Putting the concept of "cursor position" into the existing pagers (more/less/etc) and doing jump/xref/back would be more than a stretch, IMO.
> 


From steffen at sdaoden.eu  Tue Sep 17 05:32:29 2019
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Mon, 16 Sep 2019 21:32:29 +0200
Subject: [TUHS] earliest Unix roff [correction]
In-Reply-To: <201909150247.x8F2l8Vp094001@tahoe.cs.Dartmouth.EDU>
References: <201909150247.x8F2l8Vp094001@tahoe.cs.Dartmouth.EDU>
Message-ID: <20190916193229.zaC9X%steffen@sdaoden.eu>

Doug McIlroy wrote in <201909150247.x8F2l8Vp094001 at tahoe.cs.Dartmouth.EDU>:
 |The URL for roff71 scans is  https://www.cs.dartmouth.edu/~doug/roff71/

Thank you very much.
Also for "Happy Roffing" in general, Mr. McIlroy!

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

From steffen at sdaoden.eu  Tue Sep 17 05:56:18 2019
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Mon, 16 Sep 2019 21:56:18 +0200
Subject: [TUHS] Fwd: Re:  earliest Unix roff
Message-ID: <20190916195618.06nlI%steffen@sdaoden.eu>

Sorry, i said "yes" to the false question.

--- Forwarded from Steffen Nurpmeso <steffen at sdaoden.eu> ---
Date: Mon, 16 Sep 2019 21:12:28 +0200
From: Steffen Nurpmeso <steffen at sdaoden.eu>
To: chet.ramey at case.edu
Subject: Re: [TUHS] earliest Unix roff
Message-ID: <20190916191228.1YQHs%steffen at sdaoden.eu>
OpenPGP: id=EE19E1C1F2F7054F8D3954D8308964B51883A0DD; url=https://ftp.sdaoden.eu/steffen.asc; preference=signencrypt

Chet Ramey wrote in <95916cf9-9aa1-f949-0f37-0ae466e38aa2 at case.edu>:
 |On 9/16/19 8:10 AM, Clem Cole wrote:
 |>     I use the standalone Info reader (named info) if I want to look \
 |>     at the
 |>     Info output. 
 |> 
 |> Fair enough, but be careful, while I admit I have not looked in a while,
 |> info(gnu) relies on emacs keybindings and a number of very emacs'ish th\
 |> ings.
 |> Every time I have tried to deal with it, I have unprogram my fingers and
 |> reset them to emacs.
 |> 
 |> If it would have used more(1) [or even less(1)] then I would not \
 |> be as annoyed.
 |
 |It seems to me that the strength of info (the file format and program) is
 |the navigation of a menu-driven hierarchical document containing what are
 |essentially selectable links between sections. Something like more or less
 |is poorly suited to take advantage of those features.

But you can do that in man macros with a normal pager like
less(1), too.  I mean, i may bore people, but yes i have written
a macro extension for the mdoc macros which can be used to
generate a TOC, and which generates document local as well as
links to external manual pages.  This works for all output
formats, but particularly well for those which support links
themselves, HTML, PDF as well as grotty, the TTY output device of
groff.  There was a feature request, but it has not been included
yet.  (My own port of roff where it will ship out of the box i just
do not find time for, but i said to myself that after having
banged my head a thousand times against the wall of a totally
f....d up software code base, if i maintain yet another free
software project then this time i do not release anything until
i can say i am ready.)

You can see the manual page online if you want to, it is at [1]
(and itself the HTML output of a manual which uses the macro).
Nothing magic, it is just that the grotty device then uses
backspace escape sequences not only to embolden or otherwise
format text, but also to invisibly embed content information.
And a patched less(1) can search for these specially crafted
backspace sequences easily, in fact i use that each and every time
when i look at the manual page of the MUA i maintain, which is
even longer than the bash manual.  The patch for less is pretty
small, even though it cares for less conventions:

  #?0|kent:less.tar_bomb_git$ git diff master..mdocmx|wc -l
  413

  [1] https://www.sdaoden.eu/code-mdocmx.html

It has the deficite of not being able to dig macros as part of
headers, e.g. "HISTORY ON less(1)" where less(1) would be an
external link, this cannot work out the way the mdoc macros are
implemented in groff.  They would need to become rewritten, but no
time for that yet.  Other than that it works just fine for half
a decade, for development i have


  mdoc() (
    MDOCMX_ENABLE=1
    \export MDOCMX_ENABLE
    \: ${MDOCMXFLAGS:=-dmx-toc-force=tree}
    \mdocmx.sh "${1}" |
      \s-roff -Tutf8 -mdoc ${MDOCMXFLAGS} |
      LESS= \s-less --RAW-CONTROL-CHARS --ignore-case --no-init
  )

where s-roff and s-less are the patched version.  This is the
development version, the nice property of mdocmx is that the
preprocessing step can be shipped, in fact it is for half
a decade, too.  For such manuals you only need grotty/less to be
patched.  So then in in less i hit ^A and will be asked

  [anchor]:

then i enter the number and it scrolls into view.  And ' will
scroll back to where you have been before following the internal
link.  Likewise, if the entered number links an external manual
page you first see

  Read external manual: !man 1 sh

and if you hit return, you go there, temporarily suspending the
current less.  (This external thing is actually a compile time
option.)  So this is all i need, and it would be very nice to have
this possibility much more often.

Well.  The mandoc project has an option to generate links for
manual pages on best guess, too.  This works surprisingly well,
and does not need a patch for less as it generates the usual tag
files that you all know about.  It cannot support exact anchor
support, of course, and TOC generation it does not have too,
i think.

But anyway: it is possible.

 |You need a way to position the cursor with more flexibility than more gives
 |you.

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

 -- End forward <20190916191228.1YQHs%steffen at sdaoden.eu>

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

From g.branden.robinson at gmail.com  Tue Sep 17 06:21:56 2019
From: g.branden.robinson at gmail.com (G. Branden Robinson)
Date: Tue, 17 Sep 2019 06:21:56 +1000
Subject: [TUHS] INed/Rand Editor/Ned [was Re: My EuroBSDcon talk
 (preview for commentary)
In-Reply-To: <CANCZdfoL2JGwhE1kn3sckUrREKq=v9+6oLm1H8gAf446y87SQg@mail.gmail.com>
References: <CANCZdfrK4iFQCWOFP4MoUggpfJVmoJ0dnSg6H0cCi4dop7sVXw@mail.gmail.com>
 <CAC20D2Nq+eTQDdft5nW8kKcWFdt9ZK4-5kJX6OcMcYBffk9HGA@mail.gmail.com>
 <20190915232524.9A5491570CE9@mail.bitblocks.com>
 <CANCZdfr83yx7eUu-t+j-D8z9TMSkuAvPpb81hJdk95070gmZcA@mail.gmail.com>
 <7F62BF6B-8FEA-4C43-9E35-05BDE9BF04EA@ccc.com>
 <CAKr6gn3dKiFCr3D4sYv1+xJbD4cHq5X6AFEtz8MF7NtKdnY6dw@mail.gmail.com>
 <20190916023738.F34E81570CE9@mail.bitblocks.com>
 <B2C11377-D557-4542-94D9-31E3D9C789D6@technologists.com>
 <CAC20D2MfPCf7Dqke_U=Bod+WeZnvpszrgo7TwpeJB5G3CsG+oA@mail.gmail.com>
 <CANCZdfoL2JGwhE1kn3sckUrREKq=v9+6oLm1H8gAf446y87SQg@mail.gmail.com>
Message-ID: <20190916202153.wbpzx3jn3a7rs6kb@localhost.localdomain>

At 2019-09-16T17:16:12+0100, Warner Losh wrote:
> I got to look at the source to a few other editors of the era. All has
> the terminal codes hard coded into them... it was common to do that
> before things like termcap...

It's still common today.  Everything the developer cares to think about,
let alone test on, interprets EMCA-48 SGR escape sequences.  My favorite
recent example is "spectre-meltdown-checker", which has such edifying
lines as:

        _info_nol "> \033[46m\033[30mSTATUS:\033[0m "

Why write something portable when you can be "close to the metal"?  :-/

I gently steer people to better ways when the occasion presents itself.

Regards,
Branden
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190917/ad54e61d/attachment.sig>

From lm at mcvoy.com  Tue Sep 17 06:31:52 2019
From: lm at mcvoy.com (Larry McVoy)
Date: Mon, 16 Sep 2019 13:31:52 -0700
Subject: [TUHS] SCCS
In-Reply-To: <20190916172300.cjlkf%steffen@sdaoden.eu>
References: <20190912034346.GJ2046@mcvoy.com>
 <a0231faa-8ad9-fa51-4b24-9854beb21210@gmail.com>
 <1457a2d6-2f17-482d-e4f7-ace439d34ca8@neophilic.com>
 <CAC20D2OZpnma4EX+PqgqfA7zNM7sofuDQ4zCURnLF7-G4TCKhQ@mail.gmail.com>
 <8db2e89c-ce50-a453-e38a-ecdfe69a746c@e-bbes.com>
 <20190913211104.aMZXy%steffen@sdaoden.eu>
 <20190913211751.GF2046@mcvoy.com>
 <20190913230312.XaeCQ%steffen@sdaoden.eu>
 <20190914015517.GD12480@mcvoy.com>
 <20190916172300.cjlkf%steffen@sdaoden.eu>
Message-ID: <20190916203152.GB9704@mcvoy.com>

On Mon, Sep 16, 2019 at 07:23:00PM +0200, Steffen Nurpmeso wrote:
> Larry McVoy wrote in <20190914015517.GD12480 at mcvoy.com>:
>  |On Sat, Sep 14, 2019 at 01:03:12AM +0200, Steffen Nurpmeso wrote:
>  |> He is as convinced from SCCS and its interleaved deltas as you
>  |> are, but he works on extending the plain original SCCS, which is
>  |> pretty smaller; his presentation from the "Chemnitzer Linux Tage
>  |> 2012" (linux days of former Karl-Marx-Stadt) [1] talks about this
>  |> and also prominently mentions BitKeeper:
>  |> 
>  |>   . All modern distributed OSS version control systems base upon
>  |>     BitKeeper in the end.
>  |
>  |Sort of.  Monotone, Darcs, and one other one I can't remember did not
>  |draw from BitKeeper.  Mercurial, Git, and the Australian one that I
>  |can't remember definitely do.
>  |
>  |>   . BitKeeper bases upon the ideas of TeamWare.
>  |
>  |Only in that I am the primary author of both.  It does support the idea
>  |that SCCS is the basis for both, though Teamware used the real SCCS and
>  |I rewrote SCCS from scratch and then extended it quite a bit.  BitKeeper's
>  |SCCS tracks a lot more than SCCS does, pathnames, permissions, hostnames,
>  |etc.
> 
> Regarding the technical background J??rg mentions US Patent 5481722
> on merging deltas of source code control for computer software
> development that Glenn Skinner of Sun holds.

Yeah, it's nuts that Glenn got that patent.  It's true it was his idea
to do the graph that way, and he had an implementation that created
the graph through multiple calls to stripdel, get, and delta.  It was
excruciatingly slow.

100% of the code that implemented the one pass "zipper"-ing of 2 
diverged SCCS files was designed and written by me.  At the very
least, I should have been coauthor of the patent but Sun politics
got in the way [1].  

>  |>   . TeamWare bases upon the ideas of NSE.
>  |
>  |That's absolutely false.  TeamWare, which is the productized version
>  |of NSElite, which I wrote all of, was a reaction to how absolute shiite
>  |NSE was.  I had friends in the Sun kernel group that quit because they
>  |were forced to use NSE.  It was awful.  I got into source management 
>  |because I was well known at Sun as the guy that could fix performance
>  |problems so I was asked to look at NSE.  One look told me that I couldn't
>  |fix NSE but the source management problem space needed some help.

[1] The politics had to do with Teamware.  I wrote all the code in
NSElite, including smoosh(1) which was what the patent covered (though
the patent happened later).  Everyone in the kernel group were using
NSElite because NSE sucked so hard.  But it wasn't sanctioned code,
it was a Larry project.  Bill Shannon would walk around and tell people
that they couldn't use NSElite but they ignored him because it worked
and it was light years faster than NSE.

They couldn't kill NSElite so they decided to toss it to an 8 person
team in the tools group.  They told me if I wanted to work on tools I
had to go join the tools group.  Yeah, right, I'm in the kernel group
and I'm going to take the 3 step downgrade to tools?  I don't think so.

I just kept on supporting and developing NSElite, which was 90% perl4
and a xview graphical program to view history and smoosh (both C).
Because I was coding most of the stuff in (very stylized perl, I rewrote
it 3 times until I had code I could have a hope of maintaining), I was
much faster at rolling out new stuff.  In fact, the 8 people choose to
rewrite everything in C++ which meant I was coding circles around them.
Hence the politics, one guy, in his spare time, while doing a full time
job hacking the kernel, was making 8 guys look like idiots.  Evan later
wrote a paper about what a bad choice C++ was.

Something had to give and Jon Kannegaard, who was the VP of the tools
group, walked into my office and said "I've got Scott's (McNealy, CEO)
approval on this.  If you make one more release of NSElite you are 
fired."  Nice, eh?  Not everything was perfect at Sun.

So I stopped, I left the kernel group and went over and did SPARC Clusters
for Ken Okin.  Glenn filed the patent after I left.

It was a shame because NSElite didn't have changesets, it wasn't really
a distributed system (relied on NFS to get at remote repos), if I had
kept going it would have evolved into what BitKeeper bacame.

Oh, yeah, the politics were so bad that when Evan took smoosh.c he
didn't take any of the SCCS history, he checked it in so it looked like
he wrote it.  Even Shannon called that dirty pool.

>  |>   . NSE is a frontend to SCCS.
>  |
>  |That's true.
>  |
>  |>   . Therewith all modern systems ultimately base upon SCCS.
>  |
>  |That is a big stretch, it's just not true.  I love the SCCS file 
>  |format but to say all modern systems are based on SCCS is 100%
>  |false.  BitKeeper is.  That's it.
>  |
>  |>   . Distributed operate TeamWare, BitKeeper, git, Mercurial.
>  |
>  |Git and Mercurial were going for append only data structures. 
>  |That's not SCCS.
>  |
>  |All this comes from Jorg, isn't he the guy who has a track record of
>  |being on the outside of Sun and trying to argue with me about what Sun
>  |was doing when I was a well known guy in the most important group at Sun,
>  |the kernel group.  If so, I'd salt his stuff heavily.
> 
> This is the J??rg Schilling with whom you have had a dispute on
> this list, yes.  But i do not share this track record of yours.

OK, I'm happy you like him, I liked him just fine until he started 
making statements that aren't true.  Statements that were about 
what Sun was doing and why they were doing it.  Statements about
the content and direction of the kernel development, that I knew
to be false because I was in the Sun kernel group during the time
he was referencing.  Kinda hard to be any closer to it than I was
so unless I've gone completely senile in my old age, I'm probably
more likely to be right about that information than he is.  I was
there, he was not.

> One thing he says, and which is an interesting part of this
> thread, is
> 
>   Die Behauptung von Eric Allman Tichy h??tte SCCS Version
>   1 verwendet kann ich nicht glauben, denn die Ver??ffentlichungen
>   von Tichy sind von 1982 und SCCS war seit Februar 1977 auf der
>   Version 4. SCCS Version 3 hatte ??brigens noch ein bin??res
>   Historyformat.
> 
>   The statement of Eric Allman that Tichy used SCCS version
>   1 i cannot believe, because Tichy's releases are from 1982, and
>   SCCS version 4 was released as earyl as February 1977.  SCCS
>   version 3 used a binary history format, by the way.

Before my time so I don't know.  I was an undergrad Art History major
at that time :)

--lm

From jon at fourwinds.com  Tue Sep 17 06:47:27 2019
From: jon at fourwinds.com (Jon Steinhart)
Date: Mon, 16 Sep 2019 13:47:27 -0700
Subject: [TUHS] INed/Rand Editor/Ned [was Re: My EuroBSDcon talk
 (preview for commentary)
In-Reply-To: <20190916202153.wbpzx3jn3a7rs6kb@localhost.localdomain>
References: <CANCZdfrK4iFQCWOFP4MoUggpfJVmoJ0dnSg6H0cCi4dop7sVXw@mail.gmail.com>
 <CAC20D2Nq+eTQDdft5nW8kKcWFdt9ZK4-5kJX6OcMcYBffk9HGA@mail.gmail.com>
 <20190915232524.9A5491570CE9@mail.bitblocks.com>
 <CANCZdfr83yx7eUu-t+j-D8z9TMSkuAvPpb81hJdk95070gmZcA@mail.gmail.com>
 <7F62BF6B-8FEA-4C43-9E35-05BDE9BF04EA@ccc.com>
 <CAKr6gn3dKiFCr3D4sYv1+xJbD4cHq5X6AFEtz8MF7NtKdnY6dw@mail.gmail.com>
 <20190916023738.F34E81570CE9@mail.bitblocks.com>
 <B2C11377-D557-4542-94D9-31E3D9C789D6@technologists.com>
 <CAC20D2MfPCf7Dqke_U=Bod+WeZnvpszrgo7TwpeJB5G3CsG+oA@mail.gmail.com>
 <CANCZdfoL2JGwhE1kn3sckUrREKq=v9+6oLm1H8gAf446y87SQg@mail.gmail.com>
 <20190916202153.wbpzx3jn3a7rs6kb@localhost.localdomain>
Message-ID: <201909162047.x8GKlSbX001635@darkstar.fourwinds.com>

G. Branden Robinson writes:
>
> At 2019-09-16T17:16:12+0100, Warner Losh wrote:
> > I got to look at the source to a few other editors of the era. All has
> > the terminal codes hard coded into them... it was common to do that
> > before things like termcap...
>
> It's still common today.  Everything the developer cares to think about,
> let alone test on, interprets EMCA-48 SGR escape sequences.  My favorite
> recent example is "spectre-meltdown-checker", which has such edifying
> lines as:
>
>         _info_nol "> \033[46m\033[30mSTATUS:\033[0m "
>
> Why write something portable when you can be "close to the metal"?  :-/
>
> I gently steer people to better ways when the occasion presents itself.
>
> Regards,
> Branden

We can have an interesting discussion of the definition of "better ways".
I see termcap as a great solution for the days in which there was little
standardization.  But it's probably pretty hard to find a non-conforming
terminal nowadays so I think that it's better to avoid obfuscation.  Were
it me I would have a comment that referenced the page and section number
in the standard.

Since we like debating the merits of old technology, somebody can kick off
a termcap versus terminfo discussion :-)

Jon

From dave at horsfall.org  Tue Sep 17 07:42:28 2019
From: dave at horsfall.org (Dave Horsfall)
Date: Tue, 17 Sep 2019 07:42:28 +1000 (EST)
Subject: [TUHS] earliest Unix roff
In-Reply-To: <CAC20D2N89jOBK+T9EPn8JKNaSOUx=yDr9t4=CcyHM+3qnB2bEg@mail.gmail.com>
References: <CAC20D2NmXGzN7imTKy-RRWRZ2ewWMEmUV9oDuP3-e3a4R+ynpA@mail.gmail.com>
 <CAC20D2PXYWpv-8BQNKvUjgT=2W81GgzaOLyZiQ5=sM9+LXCWnw@mail.gmail.com>
 <CAC20D2MDbmoeMZq1esbuQvOCU7to0dUWsFyx98UQDLE3-c4fOA@mail.gmail.com>
 <201909132024.x8DKObEP013266@darkstar.fourwinds.com>
 <CAC20D2PvA26HMoABOcLMoS9Lu8=L3Wtx_8yK83K+vbhoMZt-hQ@mail.gmail.com>
 <463d5cc4-9bef-9ac3-a680-a5161d664dc1@aueb.gr>
 <CAC20D2Nz-ofwD41vULF2-TL8-C33heCiHvoNNbcuj6GGKhtKzQ@mail.gmail.com>
 <20190913221345.GA16129@minnie.tuhs.org>
 <CAC20D2OQD-NJaFsqsLVL_kqmCsSeUOKAr7dm71P4uN9N8m+AbQ@mail.gmail.com>
 <20190914020240.GO2046@mcvoy.com> <20190914024433.GA19193@minnie.tuhs.org>
 <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org>
 <201909150654.x8F6sChG021185@freefriends.org>
 <CAC20D2PfLq=J5ei+izXb2J7dSvU6=L6-GRd0gKA2ShSNg1=qBg@mail.gmail.com>
 <201909160552.x8G5qBYK025195@freefriends.org>
 <CAC20D2N89jOBK+T9EPn8JKNaSOUx=yDr9t4=CcyHM+3qnB2bEg@mail.gmail.com>
Message-ID: <alpine.BSF.2.21.9999.1909170739260.18105@aneurin.horsfall.org>

On Mon, 16 Sep 2019, Clem Cole wrote:

> Fair enough, but be careful, while I admit I have not looked in a while, 
> info(gnu) relies on emacs keybindings and a number of very 
> emacs'ish things. Every time I have tried to deal with it, I have 
> unprogram my fingers and reset them to emacs.

Yep, which is why I like "info" as much as I like EMACS i.e. not at all.

What exactly is wrong with the manpage format?  It tells you everything 
you need to know, and tells you where to find further information.

-- Dave

From dave at horsfall.org  Tue Sep 17 07:45:51 2019
From: dave at horsfall.org (Dave Horsfall)
Date: Tue, 17 Sep 2019 07:45:51 +1000 (EST)
Subject: [TUHS] [SPAM] Re:  SCCS
In-Reply-To: <878sqosaob.fsf@vuxu.org>
References: <1568412078.22454.for-standards-violators@oclsc.org>
 <878sqosaob.fsf@vuxu.org>
Message-ID: <alpine.BSF.2.21.9999.1909170743310.18105@aneurin.horsfall.org>

On Mon, 16 Sep 2019, Leah Neukirchen wrote:

> IPv6 has no checksum at all (for the header), and TCPv6 uses the same 
> checksum algorithm.

Every time I've tried to read the IPv6 spec my eyes glazed over; it was 
plainly designed by a committee i.e. everybody wanted their mark on it.

-- Dave

From lm at mcvoy.com  Tue Sep 17 07:48:32 2019
From: lm at mcvoy.com (Larry McVoy)
Date: Mon, 16 Sep 2019 14:48:32 -0700
Subject: [TUHS] earliest Unix roff
In-Reply-To: <alpine.BSF.2.21.9999.1909170739260.18105@aneurin.horsfall.org>
References: <20190913221345.GA16129@minnie.tuhs.org>
 <CAC20D2OQD-NJaFsqsLVL_kqmCsSeUOKAr7dm71P4uN9N8m+AbQ@mail.gmail.com>
 <20190914020240.GO2046@mcvoy.com>
 <20190914024433.GA19193@minnie.tuhs.org>
 <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org>
 <201909150654.x8F6sChG021185@freefriends.org>
 <CAC20D2PfLq=J5ei+izXb2J7dSvU6=L6-GRd0gKA2ShSNg1=qBg@mail.gmail.com>
 <201909160552.x8G5qBYK025195@freefriends.org>
 <CAC20D2N89jOBK+T9EPn8JKNaSOUx=yDr9t4=CcyHM+3qnB2bEg@mail.gmail.com>
 <alpine.BSF.2.21.9999.1909170739260.18105@aneurin.horsfall.org>
Message-ID: <20190916214832.GW2046@mcvoy.com>

On Tue, Sep 17, 2019 at 07:42:28AM +1000, Dave Horsfall wrote:
> On Mon, 16 Sep 2019, Clem Cole wrote:
> 
> >Fair enough, but be careful, while I admit I have not looked in a while,
> >info(gnu) relies on emacs keybindings and a number of very
> >emacs'ish??things. Every time I have tried to deal with it, I have
> >unprogram my fingers and reset them to emacs.
> 
> Yep, which is why I like "info" as much as I like EMACS i.e. not at all.
> 
> What exactly is wrong with the manpage format?  It tells you everything you
> need to know, and tells you where to find further information.

I think, someone correct me if I'm wrong, the info stuff was designed
to handle larger, more complex stuff, with a table of contents, etc.
Something like perl could fit in one info doc but the perl man page is
not a thing, it's just a series of pointers to more man pages.

From jon at fourwinds.com  Tue Sep 17 07:54:49 2019
From: jon at fourwinds.com (Jon Steinhart)
Date: Mon, 16 Sep 2019 14:54:49 -0700
Subject: [TUHS] earliest Unix roff
In-Reply-To: <20190916214832.GW2046@mcvoy.com>
References: <20190913221345.GA16129@minnie.tuhs.org>
 <CAC20D2OQD-NJaFsqsLVL_kqmCsSeUOKAr7dm71P4uN9N8m+AbQ@mail.gmail.com>
 <20190914020240.GO2046@mcvoy.com> <20190914024433.GA19193@minnie.tuhs.org>
 <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org>
 <201909150654.x8F6sChG021185@freefriends.org>
 <CAC20D2PfLq=J5ei+izXb2J7dSvU6=L6-GRd0gKA2ShSNg1=qBg@mail.gmail.com>
 <201909160552.x8G5qBYK025195@freefriends.org>
 <CAC20D2N89jOBK+T9EPn8JKNaSOUx=yDr9t4=CcyHM+3qnB2bEg@mail.gmail.com>
 <alpine.BSF.2.21.9999.1909170739260.18105@aneurin.horsfall.org>
 <20190916214832.GW2046@mcvoy.com>
Message-ID: <201909162154.x8GLsnOs011718@darkstar.fourwinds.com>

Larry McVoy writes:
>
> I think, someone correct me if I'm wrong, the info stuff was designed
> to handle larger, more complex stuff, with a table of contents, etc.
> Something like perl could fit in one info doc but the perl man page is
> not a thing, it's just a series of pointers to more man pages.

Can't answer you directly on this one, but I prefer the old system of
having man pages and separate documents for longer things.  I still
have old notebooks full of papers on lex, yacc, and so on.

One of the problems with using info for something like perl is that it
doesn't have a useful organization.  There's a difference to me between
a reference manual and a user's guide.  Most of the stuff referenced by
the main perl page is user's guide stuff to me, it's not a reference.

Probably someone knows more than me about all this.  I have always been
under the impression that one read the user's guide to learn about
complicated stuff.  The manual pages were there so that you could find
the right options when you forgot.  Putting every detail about a complex
program into a manual page doesn't feel right to me.

Jon

From beebe at math.utah.edu  Tue Sep 17 07:48:36 2019
From: beebe at math.utah.edu (Nelson H. F. Beebe)
Date: Mon, 16 Sep 2019 15:48:36 -0600
Subject: [TUHS] [tuhs] Computer history preservation
Message-ID: <CMM.0.95.0.1568670516.beebe@gamma.math.utah.edu>

A major topic on this list has been the preservation of computer
history, through museums that collect and operate old hardware,
software emulation of past hardware and software systems, and data
recovery from newly discovered, but previously thought to be lost,
archives.

I came across an article today about another major industry that has
been exceedingly careless about preserving its history:

        Wipe Out: When the BBC Kept Erasing Its Own History
        https://getpocket.com/explore/item/wipe-out-when-the-bbc-kept-erasing-its-own-history

It is a must-read for Dr Who fans on this list.

-------------------------------------------------------------------------------
- Nelson H. F. Beebe                    Tel: +1 801 581 5254                  -
- University of Utah                    FAX: +1 801 581 4148                  -
- Department of Mathematics, 110 LCB    Internet e-mail: beebe at math.utah.edu  -
- 155 S 1400 E RM 233                       beebe at acm.org  beebe at computer.org -
- Salt Lake City, UT 84112-0090, USA    URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------

From lm at mcvoy.com  Tue Sep 17 07:59:17 2019
From: lm at mcvoy.com (Larry McVoy)
Date: Mon, 16 Sep 2019 14:59:17 -0700
Subject: [TUHS] earliest Unix roff
In-Reply-To: <201909162154.x8GLsnOs011718@darkstar.fourwinds.com>
References: <20190914020240.GO2046@mcvoy.com>
 <20190914024433.GA19193@minnie.tuhs.org>
 <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org>
 <201909150654.x8F6sChG021185@freefriends.org>
 <CAC20D2PfLq=J5ei+izXb2J7dSvU6=L6-GRd0gKA2ShSNg1=qBg@mail.gmail.com>
 <201909160552.x8G5qBYK025195@freefriends.org>
 <CAC20D2N89jOBK+T9EPn8JKNaSOUx=yDr9t4=CcyHM+3qnB2bEg@mail.gmail.com>
 <alpine.BSF.2.21.9999.1909170739260.18105@aneurin.horsfall.org>
 <20190916214832.GW2046@mcvoy.com>
 <201909162154.x8GLsnOs011718@darkstar.fourwinds.com>
Message-ID: <20190916215917.GX2046@mcvoy.com>

On Mon, Sep 16, 2019 at 02:54:49PM -0700, Jon Steinhart wrote:
> Larry McVoy writes:
> >
> > I think, someone correct me if I'm wrong, the info stuff was designed
> > to handle larger, more complex stuff, with a table of contents, etc.
> > Something like perl could fit in one info doc but the perl man page is
> > not a thing, it's just a series of pointers to more man pages.
> 
> Can't answer you directly on this one, but I prefer the old system of
> having man pages and separate documents for longer things.  I still
> have old notebooks full of papers on lex, yacc, and so on.
> 
> One of the problems with using info for something like perl is that it
> doesn't have a useful organization.  

We are 100% on the same page.  My complaint about wikis is it is impossible
to find anything without a search engine.  I like tables of contents and
indices.

My comment on the info stuff was just my understand of why it came to be.

From dave at horsfall.org  Tue Sep 17 08:05:53 2019
From: dave at horsfall.org (Dave Horsfall)
Date: Tue, 17 Sep 2019 08:05:53 +1000 (EST)
Subject: [TUHS] earliest Unix roff
In-Reply-To: <CAC20D2MBHSddOkjPUvat3GeF14-+oa2rMoppgFChzqOX+eUYpQ@mail.gmail.com>
References: <CAC20D2NmXGzN7imTKy-RRWRZ2ewWMEmUV9oDuP3-e3a4R+ynpA@mail.gmail.com>
 <CAC20D2MDbmoeMZq1esbuQvOCU7to0dUWsFyx98UQDLE3-c4fOA@mail.gmail.com>
 <201909132024.x8DKObEP013266@darkstar.fourwinds.com>
 <CAC20D2PvA26HMoABOcLMoS9Lu8=L3Wtx_8yK83K+vbhoMZt-hQ@mail.gmail.com>
 <463d5cc4-9bef-9ac3-a680-a5161d664dc1@aueb.gr>
 <CAC20D2Nz-ofwD41vULF2-TL8-C33heCiHvoNNbcuj6GGKhtKzQ@mail.gmail.com>
 <20190913221345.GA16129@minnie.tuhs.org>
 <CAC20D2OQD-NJaFsqsLVL_kqmCsSeUOKAr7dm71P4uN9N8m+AbQ@mail.gmail.com>
 <20190914020240.GO2046@mcvoy.com>
 <20190914024433.GA19193@minnie.tuhs.org>
 <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org>
 <201909150654.x8F6sChG021185@freefriends.org>
 <CAC20D2PfLq=J5ei+izXb2J7dSvU6=L6-GRd0gKA2ShSNg1=qBg@mail.gmail.com>
 <201909160552.x8G5qBYK025195@freefriends.org>
 <CAC20D2N89jOBK+T9EPn8JKNaSOUx=yDr9t4=CcyHM+3qnB2bEg@mail.gmail.com>
 <7wd0g0o2a0.fsf@junk.nocrew.org>
 <CAC20D2MBHSddOkjPUvat3GeF14-+oa2rMoppgFChzqOX+eUYpQ@mail.gmail.com>
Message-ID: <alpine.BSF.2.21.9999.1909170804040.18105@aneurin.horsfall.org>

On Mon, 16 Sep 2019, Clem Cole wrote:

> >       However, please note that more(1) also was inspired by, almost 
> >       copied from, ITS.  Certainly the prompt --More-- is.
> 
> Absolutely.  A friend of mine/fellow UCB grad student, Eric Shienbrood, 
> wrote it.  He was a MIT undergrad. And Eric happily said it was modeled 
> from ITS. And before, Eric wrote it, UNIX lacked anything like it.  
>  Which to me is fine, taking an idea from another system to add a new 
> feature that is lacking.

Am I the only one who remembers the old "pg" program?  It seems to have
disappeared.

-- Dave

From bakul at bitblocks.com  Tue Sep 17 08:10:24 2019
From: bakul at bitblocks.com (Bakul Shah)
Date: Mon, 16 Sep 2019 15:10:24 -0700
Subject: [TUHS] earliest Unix roff
In-Reply-To: Your message of "Mon, 16 Sep 2019 14:54:49 -0700."
 <201909162154.x8GLsnOs011718@darkstar.fourwinds.com>
References: <20190913221345.GA16129@minnie.tuhs.org>
 <CAC20D2OQD-NJaFsqsLVL_kqmCsSeUOKAr7dm71P4uN9N8m+AbQ@mail.gmail.com>
 <20190914020240.GO2046@mcvoy.com> <20190914024433.GA19193@minnie.tuhs.org>
 <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org>
 <201909150654.x8F6sChG021185@freefriends.org>
 <CAC20D2PfLq=J5ei+izXb2J7dSvU6=L6-GRd0gKA2ShSNg1=qBg@mail.gmail.com>
 <201909160552.x8G5qBYK025195@freefriends.org>
 <CAC20D2N89jOBK+T9EPn8JKNaSOUx=yDr9t4=CcyHM+3qnB2bEg@mail.gmail.com>
 <alpine.BSF.2.21.9999.1909170739260.18105@aneurin.horsfall.org>
 <20190916214832.GW2046@mcvoy.com>
 <201909162154.x8GLsnOs011718@darkstar.fourwinds.com>
Message-ID: <20190916221031.5E55C1570CE9@mail.bitblocks.com>

On Mon, 16 Sep 2019 14:54:49 -0700 Jon Steinhart <jon at fourwinds.com> wrote:
> Larry McVoy writes:
> >
> > I think, someone correct me if I'm wrong, the info stuff was designed
> > to handle larger, more complex stuff, with a table of contents, etc.
> > Something like perl could fit in one info doc but the perl man page is
> > not a thing, it's just a series of pointers to more man pages.
>
> Can't answer you directly on this one, but I prefer the old system of
> having man pages and separate documents for longer things.  I still
> have old notebooks full of papers on lex, yacc, and so on.
>
> One of the problems with using info for something like perl is that it
> doesn't have a useful organization.  There's a difference to me between
> a reference manual and a user's guide.  Most of the stuff referenced by
> the main perl page is user's guide stuff to me, it's not a reference.
>
> Probably someone knows more than me about all this.  I have always been
> under the impression that one read the user's guide to learn about
> complicated stuff.  The manual pages were there so that you could find
> the right options when you forgot.  Putting every detail about a complex
> program into a manual page doesn't feel right to me.

A typical manpage had just the right length. Reading man pages
and experimenting is how I initially learned all about unix
commands.

Keeping a manpage short also limited what you as the
implementer would be tempted to add to the command. Manpages
work best for programs that follow the unix mantra of do one
thing and do it well. But not for kitchensink programs.  When
you need a multipage reference manual (for *experts*) with a
TOC and program to "navigate", you're much more likely to give
into the temptation of adding more features than partition
functionality into separate programs that work well together.
Not to mention it is harder to get something right that has
many more features.

From ggm at algebras.org  Tue Sep 17 08:21:04 2019
From: ggm at algebras.org (George Michaelson)
Date: Tue, 17 Sep 2019 08:21:04 +1000
Subject: [TUHS] [SPAM] Re: SCCS
In-Reply-To: <alpine.BSF.2.21.9999.1909170743310.18105@aneurin.horsfall.org>
References: <1568412078.22454.for-standards-violators@oclsc.org>
 <878sqosaob.fsf@vuxu.org>
 <alpine.BSF.2.21.9999.1909170743310.18105@aneurin.horsfall.org>
Message-ID: <CAKr6gn1EER3s3sczS_cWj_Z7CrMk9sq54HVv1HUzo8fATo=Y6w@mail.gmail.com>

Third mistake ever was host-only fragmentation and re-assembly. The
lack of pragmatism tells here, because it means intermediate systems
have no choice but to drop.

Second biggest mistake was keeping the order SRC, DST when if the DST
is first you can latch it into a buffer and do forwarding decisions
while the rest of the packet is in processing.

First biggest mistake was ignoring TUBA.

-G

On Tue, Sep 17, 2019 at 7:46 AM Dave Horsfall <dave at horsfall.org> wrote:
>
> On Mon, 16 Sep 2019, Leah Neukirchen wrote:
>
> > IPv6 has no checksum at all (for the header), and TCPv6 uses the same
> > checksum algorithm.
>
> Every time I've tried to read the IPv6 spec my eyes glazed over; it was
> plainly designed by a committee i.e. everybody wanted their mark on it.
>
> -- Dave

From gregg.drwho8 at gmail.com  Tue Sep 17 08:24:39 2019
From: gregg.drwho8 at gmail.com (Gregg Levine)
Date: Mon, 16 Sep 2019 18:24:39 -0400
Subject: [TUHS] [tuhs] Computer history preservation
In-Reply-To: <CMM.0.95.0.1568670516.beebe@gamma.math.utah.edu>
References: <CMM.0.95.0.1568670516.beebe@gamma.math.utah.edu>
Message-ID: <CAC5iaNHFmJYbqUzf+iT3NMvdKK_xGOOV5OPHf=pHzuUnA612Sg@mail.gmail.com>

Hello!
Thank you Nelson. That confirms largely what I've largely already
known from other sources. Suffice to say a lot of the Doctor Who
episodes confirmed are being restored, just not the way we wanted.....
However everything from Third down to the latest is available.
-----
Gregg C Levine gregg.drwho8 at gmail.com
"This signature fought the Time Wars, time and again."

On Mon, Sep 16, 2019 at 5:56 PM Nelson H. F. Beebe <beebe at math.utah.edu> wrote:
>
> A major topic on this list has been the preservation of computer
> history, through museums that collect and operate old hardware,
> software emulation of past hardware and software systems, and data
> recovery from newly discovered, but previously thought to be lost,
> archives.
>
> I came across an article today about another major industry that has
> been exceedingly careless about preserving its history:
>
>         Wipe Out: When the BBC Kept Erasing Its Own History
>         https://getpocket.com/explore/item/wipe-out-when-the-bbc-kept-erasing-its-own-history
>
> It is a must-read for Dr Who fans on this list.
>
> -------------------------------------------------------------------------------
> - Nelson H. F. Beebe                    Tel: +1 801 581 5254                  -
> - University of Utah                    FAX: +1 801 581 4148                  -
> - Department of Mathematics, 110 LCB    Internet e-mail: beebe at math.utah.edu  -
> - 155 S 1400 E RM 233                       beebe at acm.org  beebe at computer.org -
> - Salt Lake City, UT 84112-0090, USA    URL: http://www.math.utah.edu/~beebe/ -
> -------------------------------------------------------------------------------

From ggm at algebras.org  Tue Sep 17 08:33:29 2019
From: ggm at algebras.org (George Michaelson)
Date: Tue, 17 Sep 2019 08:33:29 +1000
Subject: [TUHS] INed/Rand Editor/Ned [was Re: My EuroBSDcon talk
 (preview for commentary)
In-Reply-To: <201909162047.x8GKlSbX001635@darkstar.fourwinds.com>
References: <CANCZdfrK4iFQCWOFP4MoUggpfJVmoJ0dnSg6H0cCi4dop7sVXw@mail.gmail.com>
 <CAC20D2Nq+eTQDdft5nW8kKcWFdt9ZK4-5kJX6OcMcYBffk9HGA@mail.gmail.com>
 <20190915232524.9A5491570CE9@mail.bitblocks.com>
 <CANCZdfr83yx7eUu-t+j-D8z9TMSkuAvPpb81hJdk95070gmZcA@mail.gmail.com>
 <7F62BF6B-8FEA-4C43-9E35-05BDE9BF04EA@ccc.com>
 <CAKr6gn3dKiFCr3D4sYv1+xJbD4cHq5X6AFEtz8MF7NtKdnY6dw@mail.gmail.com>
 <20190916023738.F34E81570CE9@mail.bitblocks.com>
 <B2C11377-D557-4542-94D9-31E3D9C789D6@technologists.com>
 <CAC20D2MfPCf7Dqke_U=Bod+WeZnvpszrgo7TwpeJB5G3CsG+oA@mail.gmail.com>
 <CANCZdfoL2JGwhE1kn3sckUrREKq=v9+6oLm1H8gAf446y87SQg@mail.gmail.com>
 <20190916202153.wbpzx3jn3a7rs6kb@localhost.localdomain>
 <201909162047.x8GKlSbX001635@darkstar.fourwinds.com>
Message-ID: <CAKr6gn2Z-CAJeNhxU-paqjVxrBXHuGNukqWn0OVCK5GyYLFKeA@mail.gmail.com>

On Tue, Sep 17, 2019 at 6:47 AM Jon Steinhart <jon at fourwinds.com> wrote:
>
> Since we like debating the merits of old technology, somebody can kick off
> a termcap versus terminfo discussion :-)
>

Felt like of-its-time NIH. Since the codes to drive an ADM5 were the
same in either source, and since the intent was the same, it was just
a giant *why* for me.

I didn't get why binary file either. If the cost of reading the
termcap DB was a significant hit on your program, I think you just
proved you were a robot and would be defeated by a captcha. Having to
compile things is a drag.

It was probably a side effect of the sequence of universities and
institutions I worked at (York, Leeds, York, UCL, CSIRO, UQ) that they
were almost exclusively v7->32V->BSD->SunOS shops and so the emergence
of SYSV was basically occluded to me, and so SYSV-isms (with the
exception of RFS and the pre-gnu getopt() which leaked into UUCP
newsgroups I read somehow).

Terminfo just didn't feel very *relevant*

From reed at reedmedia.net  Tue Sep 17 08:33:58 2019
From: reed at reedmedia.net (reed at reedmedia.net)
Date: Mon, 16 Sep 2019 17:33:58 -0500 (CDT)
Subject: [TUHS] earliest Unix roff
In-Reply-To: <alpine.BSF.2.21.9999.1909170804040.18105@aneurin.horsfall.org>
References: <CAC20D2NmXGzN7imTKy-RRWRZ2ewWMEmUV9oDuP3-e3a4R+ynpA@mail.gmail.com>
 <201909132024.x8DKObEP013266@darkstar.fourwinds.com>
 <CAC20D2PvA26HMoABOcLMoS9Lu8=L3Wtx_8yK83K+vbhoMZt-hQ@mail.gmail.com>
 <463d5cc4-9bef-9ac3-a680-a5161d664dc1@aueb.gr>
 <CAC20D2Nz-ofwD41vULF2-TL8-C33heCiHvoNNbcuj6GGKhtKzQ@mail.gmail.com>
 <20190913221345.GA16129@minnie.tuhs.org>
 <CAC20D2OQD-NJaFsqsLVL_kqmCsSeUOKAr7dm71P4uN9N8m+AbQ@mail.gmail.com>
 <20190914020240.GO2046@mcvoy.com> <20190914024433.GA19193@minnie.tuhs.org>
 <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org>
 <201909150654.x8F6sChG021185@freefriends.org>
 <CAC20D2PfLq=J5ei+izXb2J7dSvU6=L6-GRd0gKA2ShSNg1=qBg@mail.gmail.com>
 <201909160552.x8G5qBYK025195@freefriends.org>
 <CAC20D2N89jOBK+T9EPn8JKNaSOUx=yDr9t4=CcyHM+3qnB2bEg@mail.gmail.com>
 <7wd0g0o2a0.fsf@junk.nocrew.org>
 <CAC20D2MBHSddOkjPUvat3GeF14-+oa2rMoppgFChzqOX+eUYpQ@mail.gmail.com>
 <alpine.BSF.2.21.9999.1909170804040.18105@aneurin.horsfall.org>
Message-ID: <alpine.NEB.2.21.1909161726410.18938@t1.m.reedmedia.net>

> Am I the only one who remembers the old "pg" program?  It seems to have
> disappeared.

I see two different pg. One in the 32V sources and the other first 
Usenix delaware collection. (Both in TUHS archives)

Another pager "cr3" is in 1BSD collection (which was replaced by 
Halbert's more in 3BSD).

From dave at horsfall.org  Tue Sep 17 08:35:46 2019
From: dave at horsfall.org (Dave Horsfall)
Date: Tue, 17 Sep 2019 08:35:46 +1000 (EST)
Subject: [TUHS] earliest Unix roff
In-Reply-To: <CAC20D2Nwe=AycD+QywLPaRC8HCT5_U09KBeoV3+G6d9+Avidmw@mail.gmail.com>
References: <CAC20D2Nz-ofwD41vULF2-TL8-C33heCiHvoNNbcuj6GGKhtKzQ@mail.gmail.com>
 <20190913221345.GA16129@minnie.tuhs.org>
 <CAC20D2OQD-NJaFsqsLVL_kqmCsSeUOKAr7dm71P4uN9N8m+AbQ@mail.gmail.com>
 <20190914020240.GO2046@mcvoy.com> <20190914024433.GA19193@minnie.tuhs.org>
 <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org>
 <201909150654.x8F6sChG021185@freefriends.org>
 <CAC20D2PfLq=J5ei+izXb2J7dSvU6=L6-GRd0gKA2ShSNg1=qBg@mail.gmail.com>
 <201909160552.x8G5qBYK025195@freefriends.org>
 <CAC20D2N89jOBK+T9EPn8JKNaSOUx=yDr9t4=CcyHM+3qnB2bEg@mail.gmail.com>
 <20190916145122.GH2046@mcvoy.com>
 <CAC20D2Nwe=AycD+QywLPaRC8HCT5_U09KBeoV3+G6d9+Avidmw@mail.gmail.com>
Message-ID: <alpine.BSF.2.21.9999.1909170829300.18105@aneurin.horsfall.org>

On Mon, 16 Sep 2019, Clem Cole wrote:

> >       If you have something like perl that needs a zillion sub pages, 
> >       info makes sense.  For just a man page, info is horrible.
> 
> I'm not even sure, I like that, to be honest. I'm 'old school' enough to 
> rather use a book from ORA or the like. 

Or use www.perltutorial.org which is a good resource; I often get stuck
on the finer points of Perl, such as the OO stuff.

-- Dave

From g.branden.robinson at gmail.com  Tue Sep 17 08:48:28 2019
From: g.branden.robinson at gmail.com (G. Branden Robinson)
Date: Tue, 17 Sep 2019 08:48:28 +1000
Subject: [TUHS] better ways and termcap vs. terminfo for commentary)
In-Reply-To: <201909162047.x8GKlSbX001635@darkstar.fourwinds.com>
References: <20190915232524.9A5491570CE9@mail.bitblocks.com>
 <CANCZdfr83yx7eUu-t+j-D8z9TMSkuAvPpb81hJdk95070gmZcA@mail.gmail.com>
 <7F62BF6B-8FEA-4C43-9E35-05BDE9BF04EA@ccc.com>
 <CAKr6gn3dKiFCr3D4sYv1+xJbD4cHq5X6AFEtz8MF7NtKdnY6dw@mail.gmail.com>
 <20190916023738.F34E81570CE9@mail.bitblocks.com>
 <B2C11377-D557-4542-94D9-31E3D9C789D6@technologists.com>
 <CAC20D2MfPCf7Dqke_U=Bod+WeZnvpszrgo7TwpeJB5G3CsG+oA@mail.gmail.com>
 <CANCZdfoL2JGwhE1kn3sckUrREKq=v9+6oLm1H8gAf446y87SQg@mail.gmail.com>
 <20190916202153.wbpzx3jn3a7rs6kb@localhost.localdomain>
 <201909162047.x8GKlSbX001635@darkstar.fourwinds.com>
Message-ID: <20190916224825.keswxb7sh224tpky@localhost.localdomain>

At 2019-09-16T13:47:27-0700, Jon Steinhart wrote:
> G. Branden Robinson writes:
> >         _info_nol "> \033[46m\033[30mSTATUS:\033[0m "
> >
> > Why write something portable when you can be "close to the metal"?  :-/
> >
> > I gently steer people to better ways when the occasion presents itself.
[...]
> 
> We can have an interesting discussion of the definition of "better ways".

Here I think we have a layering violation.  Why on earth would a CPU
microarchitectural flaw detector need to know or care about the details
terminal control sequences?

_Anything_ that provides an abstraction of the terminal is an
improvement on the above.

> I see termcap as a great solution for the days in which there was
> little standardization.

Setting aside the specificity of "termcap", sure.  Something was needed
to gather up the absurd efflorescence of implementation details among
hardware terminals and present programmers (and users struggling to
interact with the system) something simpler and more intention-oriented.

You want "bold, if the device can do it", not a giant switch statement
encompassing '\033[1m', '\033ya', '\033yA', '\033<', '\2331m', '\033[1m'
with a parameter after it, '\033[7m', \033[=15F', ...

And if the device _can't_ do bold, you want to be able to decide for
yourself whether you don't care if the boldness is left out, or be able
to query that interface layer about it and program your own fallback
(use indentation, full capitalization, an "IMPORTANT:" prefix, etc.) in
the event the capability is absent.

> But it's probably pretty hard to find a non-conforming terminal
> nowadays so I think that it's better to avoid obfuscation.

I've attached an example of the sort of thing I do.  It has a lot of
comments, so is inappropriate for inlining on a list full of Unix
grognards.  ;-)

> Were it me I would have a comment that referenced the page and section
> number in the standard.

This is a good idea, but its benefit can be limited for ISO standards,
which are often paywalled.  In this case the controlling standard is
ISO 6429.  Fortunately it's largely parallel to ECMA-48 which is freely
available.  In this case you want ECMA-48, pp. 61-63[1].

> Since we like debating the merits of old technology, somebody can kick
> off a termcap versus terminfo discussion :-)

terminfo is better than termcap in the same way that Fortran 77 is
better than Microsoft BASIC for 8-bit microcomputers--identifier length.

Fortran 77, 6 characters.
MS BASIC, 2.
termcap, 2.
terminfo, 5.

Of course, that argument could be turned around rather precisely for
those who prize "terseness".

I reckon one of the reasons that function names in the Unix kernel were
allowed to grow as long as they did--while still being limited to 6
characters for linkage reasons--was because the precious space of 1-
and 2-letter external identifiers was held sacrosanct for user programs.

There but for that grace would 'swtch()' have gone as 'sw()', and
'creat()' as 'cr()', perhaps.

No such considerations availed in the namespace for executable programs.
;-)

Regards,
Branden

[1] https://www.ecma-international.org/publications/files/ECMA-ST/Ecma-048.pdf

-------------- next part --------------
A non-text attachment was scrubbed...
Name: example.sh
Type: application/x-sh
Size: 1962 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190917/82eb0f39/attachment.sh>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190917/82eb0f39/attachment.sig>

From g.branden.robinson at gmail.com  Tue Sep 17 09:14:02 2019
From: g.branden.robinson at gmail.com (G. Branden Robinson)
Date: Tue, 17 Sep 2019 09:14:02 +1000
Subject: [TUHS] INed/Rand Editor/Ned [was Re: My EuroBSDcon talk
 (preview for commentary)
In-Reply-To: <CAKr6gn2Z-CAJeNhxU-paqjVxrBXHuGNukqWn0OVCK5GyYLFKeA@mail.gmail.com>
References: <CANCZdfr83yx7eUu-t+j-D8z9TMSkuAvPpb81hJdk95070gmZcA@mail.gmail.com>
 <7F62BF6B-8FEA-4C43-9E35-05BDE9BF04EA@ccc.com>
 <CAKr6gn3dKiFCr3D4sYv1+xJbD4cHq5X6AFEtz8MF7NtKdnY6dw@mail.gmail.com>
 <20190916023738.F34E81570CE9@mail.bitblocks.com>
 <B2C11377-D557-4542-94D9-31E3D9C789D6@technologists.com>
 <CAC20D2MfPCf7Dqke_U=Bod+WeZnvpszrgo7TwpeJB5G3CsG+oA@mail.gmail.com>
 <CANCZdfoL2JGwhE1kn3sckUrREKq=v9+6oLm1H8gAf446y87SQg@mail.gmail.com>
 <20190916202153.wbpzx3jn3a7rs6kb@localhost.localdomain>
 <201909162047.x8GKlSbX001635@darkstar.fourwinds.com>
 <CAKr6gn2Z-CAJeNhxU-paqjVxrBXHuGNukqWn0OVCK5GyYLFKeA@mail.gmail.com>
Message-ID: <20190916231359.bnbefaceyvecglwc@localhost.localdomain>

At 2019-09-17T08:33:29+1000, George Michaelson wrote:
> On Tue, Sep 17, 2019 at 6:47 AM Jon Steinhart <jon at fourwinds.com> wrote:
> >
> > Since we like debating the merits of old technology, somebody can kick off
> > a termcap versus terminfo discussion :-)
> >
> 
> Felt like of-its-time NIH.

I certainly would not defend USG on those grounds.  Many poor decisions
seem to have been taken in the name of attempting to gain a commercial
advantage, or of an effort to present the industry with a fait accompli
that you just HAD to go along with and therefore HAD to fork over a
license fee.

This is only my impression from reading histories and retrospectives; I
came of age just as the Unix wars were winding down and Microsoft showed
that they were the most competitive at being anti-competitive.

> Since the codes to drive an ADM5 were the same in either source, and
> since the intent was the same, it was just a giant *why* for me.

For me, the mnemonic value of the capability names is important, though
terminfo didn't leverage that advantage nearly as much as they could and
should have.  5 characters was better than 2 but still too short.  And
in many cases they just reused the termcap capability names as-is, e.g.,
'am', 'll'.

But one example is enough to point up the advantage.  By what name do
you look up the "bold" capability?  In terminfo, it's called...'bold'.

In termcap, what's your bet?  'bd'?  Nope.  'bo'?  Nope.

'md'.

> I didn't get why binary file either. If the cost of reading the
> termcap DB was a significant hit on your program, I think you just
> proved you were a robot and would be defeated by a captcha. Having to
> compile things is a drag.

This is an implementation detail that _should_ have been transparent to
the user.  No one should have needed to care what the on-disk or
in-memory representation of the terminal capability list was.

But...it was the '80s.  My guess is that encapsulation to that degree
smacked of object-orientation, possibly, and therefore was always going
to be a performance disaster, the same way no one was ever going to need
more than 640KiB or how microkernels were always going to be slow at
context-switching.

Or maybe it just came down to lazy implementation.

> It was probably a side effect of the sequence of universities and
> institutions I worked at (York, Leeds, York, UCL, CSIRO, UQ) that they
> were almost exclusively v7->32V->BSD->SunOS shops and so the emergence
> of SYSV was basically occluded to me, and so SYSV-isms (with the
> exception of RFS and the pre-gnu getopt() which leaked into UUCP
> newsgroups I read somehow).
> 
> Terminfo just didn't feel very *relevant*

Yes--what good ideas AT&T commercial Unix had, they seemed determined to
ensure people never found out about except via capture of standards
bodies followed by mandatory licensing.  To me this would explain the
reasoning behind the Sun/AT&T corrupt bargain that led to Solaris (of
which Larry has written here).  People were enthusiastic about SunOS.
Obviously the thing to do with such an enthusiastic user base is buy
access to it and force them to eat whatever you feed them.  They will
remin your thralls and sing your praises for free, because all
consumer preferences are ultimately mindless questions of fashion.

Worked brilliantly, didn't it?

It can.  If you're Steve Jobs.

Regards,
Branden
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190917/ba76256c/attachment.sig>

From dave at horsfall.org  Tue Sep 17 09:24:40 2019
From: dave at horsfall.org (Dave Horsfall)
Date: Tue, 17 Sep 2019 09:24:40 +1000 (EST)
Subject: [TUHS] earliest Unix roff
In-Reply-To: <2d65ed3d-87a6-e3f4-7917-9611b631a100@case.edu>
References: <201909160552.x8G5qBYK025195@freefriends.org>
 <CAC20D2N89jOBK+T9EPn8JKNaSOUx=yDr9t4=CcyHM+3qnB2bEg@mail.gmail.com>
 <20190916145122.GH2046@mcvoy.com>
 <CAC20D2Nwe=AycD+QywLPaRC8HCT5_U09KBeoV3+G6d9+Avidmw@mail.gmail.com>
 <CAFH29tpP6joyHDAQTKj41bwAscqa0HO8g7EKwxXv3Vbscqc58A@mail.gmail.com>
 <20190916161040.GM2046@mcvoy.com>
 <201909161616.x8GGG4Fb020760@darkstar.fourwinds.com>
 <20190916162614.GO2046@mcvoy.com>
 <CAFH29toVUNEn7qNak3BeRhXhBYtx2OA0JpTGXBB3rnUyFhtU4w@mail.gmail.com>
 <20190916164502.GQ2046@mcvoy.com>
 <20190916171905.piituc2qdh46kejt@unixfarts.net>
 <2d65ed3d-87a6-e3f4-7917-9611b631a100@case.edu>
Message-ID: <alpine.BSF.2.21.9999.1909170920190.18105@aneurin.horsfall.org>

On Mon, 16 Sep 2019, Chet Ramey wrote:

> Bash comes with both a large man page and an extensive info doc.

On my (obsolete) FreeBSD box:

     aneurin% man bash | wc -l
 	5947

Now there's a manpage that should have been split up...

On the same box:

     aneurin% man zsh | wc -l
 	 346

That's because it's got sub-pages, each describing a particular feature
(I've been using ZSH for years).

-- Dave

From dave at horsfall.org  Tue Sep 17 09:44:03 2019
From: dave at horsfall.org (Dave Horsfall)
Date: Tue, 17 Sep 2019 09:44:03 +1000 (EST)
Subject: [TUHS] [tuhs] Computer history preservation
In-Reply-To: <CMM.0.95.0.1568670516.beebe@gamma.math.utah.edu>
References: <CMM.0.95.0.1568670516.beebe@gamma.math.utah.edu>
Message-ID: <alpine.BSF.2.21.9999.1909170942420.18105@aneurin.horsfall.org>

On Mon, 16 Sep 2019, Nelson H. F. Beebe wrote:

[...]

> I came across an article today about another major industry that has 
> been exceedingly careless about preserving its history:
>
>        Wipe Out: When the BBC Kept Erasing Its Own History
>        https://getpocket.com/explore/item/wipe-out-when-the-bbc-kept-erasing-its-own-history
>
> It is a must-read for Dr Who fans on this list.

Indeed; quite shameful, really.

-- Dave

From cym224 at gmail.com  Tue Sep 17 10:02:57 2019
From: cym224 at gmail.com (Nemo Nusquam)
Date: Mon, 16 Sep 2019 20:02:57 -0400
Subject: [TUHS] earliest Unix roff
In-Reply-To: <alpine.BSF.2.21.9999.1909170804040.18105@aneurin.horsfall.org>
References: <CAC20D2NmXGzN7imTKy-RRWRZ2ewWMEmUV9oDuP3-e3a4R+ynpA@mail.gmail.com>
 <201909132024.x8DKObEP013266@darkstar.fourwinds.com>
 <CAC20D2PvA26HMoABOcLMoS9Lu8=L3Wtx_8yK83K+vbhoMZt-hQ@mail.gmail.com>
 <463d5cc4-9bef-9ac3-a680-a5161d664dc1@aueb.gr>
 <CAC20D2Nz-ofwD41vULF2-TL8-C33heCiHvoNNbcuj6GGKhtKzQ@mail.gmail.com>
 <20190913221345.GA16129@minnie.tuhs.org>
 <CAC20D2OQD-NJaFsqsLVL_kqmCsSeUOKAr7dm71P4uN9N8m+AbQ@mail.gmail.com>
 <20190914020240.GO2046@mcvoy.com> <20190914024433.GA19193@minnie.tuhs.org>
 <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org>
 <201909150654.x8F6sChG021185@freefriends.org>
 <CAC20D2PfLq=J5ei+izXb2J7dSvU6=L6-GRd0gKA2ShSNg1=qBg@mail.gmail.com>
 <201909160552.x8G5qBYK025195@freefriends.org>
 <CAC20D2N89jOBK+T9EPn8JKNaSOUx=yDr9t4=CcyHM+3qnB2bEg@mail.gmail.com>
 <7wd0g0o2a0.fsf@junk.nocrew.org>
 <CAC20D2MBHSddOkjPUvat3GeF14-+oa2rMoppgFChzqOX+eUYpQ@mail.gmail.com>
 <alpine.BSF.2.21.9999.1909170804040.18105@aneurin.horsfall.org>
Message-ID: <fb60a87c-a274-104c-38e3-8fcf63f02c12@gmail.com>

On 09/16/19 18:05, Dave Horsfall wrote:
> Am I the only one who remembers the old "pg" program? It seems to have
> disappeared.

Still ships with Solaris (in /usr/bin).

N.

From dave at horsfall.org  Tue Sep 17 10:11:20 2019
From: dave at horsfall.org (Dave Horsfall)
Date: Tue, 17 Sep 2019 10:11:20 +1000 (EST)
Subject: [TUHS] earliest Unix roff
In-Reply-To: <alpine.NEB.2.21.1909161726410.18938@t1.m.reedmedia.net>
References: <CAC20D2NmXGzN7imTKy-RRWRZ2ewWMEmUV9oDuP3-e3a4R+ynpA@mail.gmail.com>
 <CAC20D2PvA26HMoABOcLMoS9Lu8=L3Wtx_8yK83K+vbhoMZt-hQ@mail.gmail.com>
 <463d5cc4-9bef-9ac3-a680-a5161d664dc1@aueb.gr>
 <CAC20D2Nz-ofwD41vULF2-TL8-C33heCiHvoNNbcuj6GGKhtKzQ@mail.gmail.com>
 <20190913221345.GA16129@minnie.tuhs.org>
 <CAC20D2OQD-NJaFsqsLVL_kqmCsSeUOKAr7dm71P4uN9N8m+AbQ@mail.gmail.com>
 <20190914020240.GO2046@mcvoy.com> <20190914024433.GA19193@minnie.tuhs.org>
 <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org>
 <201909150654.x8F6sChG021185@freefriends.org>
 <CAC20D2PfLq=J5ei+izXb2J7dSvU6=L6-GRd0gKA2ShSNg1=qBg@mail.gmail.com>
 <201909160552.x8G5qBYK025195@freefriends.org>
 <CAC20D2N89jOBK+T9EPn8JKNaSOUx=yDr9t4=CcyHM+3qnB2bEg@mail.gmail.com>
 <7wd0g0o2a0.fsf@junk.nocrew.org>
 <CAC20D2MBHSddOkjPUvat3GeF14-+oa2rMoppgFChzqOX+eUYpQ@mail.gmail.com>
 <alpine.BSF.2.21.9999.1909170804040.18105@aneurin.horsfall.org>
 <alpine.NEB.2.21.1909161726410.18938@t1.m.reedmedia.net>
Message-ID: <alpine.BSF.2.21.9999.1909171002590.18105@aneurin.horsfall.org>

On Mon, 16 Sep 2019, reed at reedmedia.net wrote:

>> Am I the only one who remembers the old "pg" program?  It seems to have 
>> disappeared.
>
> I see two different pg. One in the 32V sources and the other first 
> Usenix delaware collection. (Both in TUHS archives)

We never ran 32V; our Vaxen - called "vaxa" and "vaxb" - ran VMS...  I was 
only in charge of the Unix PDP-11/40s sprinkled around the place (and the 
odd /34 and /23).

-- Dave

From grog at lemis.com  Tue Sep 17 10:10:56 2019
From: grog at lemis.com (Greg 'groggy' Lehey)
Date: Tue, 17 Sep 2019 10:10:56 +1000
Subject: [TUHS] O'Reilly groff macros (was:  earliest Unix roff)
In-Reply-To: <201909160620.x8G6KkJq026850@freefriends.org>
References: <463d5cc4-9bef-9ac3-a680-a5161d664dc1@aueb.gr>
 <CAC20D2Nz-ofwD41vULF2-TL8-C33heCiHvoNNbcuj6GGKhtKzQ@mail.gmail.com>
 <20190913221345.GA16129@minnie.tuhs.org>
 <CAC20D2OQD-NJaFsqsLVL_kqmCsSeUOKAr7dm71P4uN9N8m+AbQ@mail.gmail.com>
 <20190914020240.GO2046@mcvoy.com>
 <20190914024433.GA19193@minnie.tuhs.org>
 <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org>
 <CAC20D2M5j+pCBpxf4Cy-sK4BfBGj_RMhzSpGaXMZmeEaGV9cDA@mail.gmail.com>
 <069494b2-ec5b-91e7-8618-2d111e0e5aa2@andrewnesbit.org>
 <201909160620.x8G6KkJq026850@freefriends.org>
Message-ID: <20190917001056.GD31311@eureka.lemis.com>

On Monday, 16 September 2019 at  0:20:46 -0600, arnold at skeeve.com wrote:
>> 1.  Do you think there is any chance of obtaining these macro packages?
>> Either from authors who haven't passed away, or from the publishing
>> houses themselves?
>
> O'Reilly probably would. I can ask someone there, if there's serious
> interest here.  They haven't used troff for book production for well
> over a decade.

The O'Reilly macro package was derived from the macros described in
Dougherty and O'Reilly "UNIX Text Processing" (Hayden 1988).  I
received a copy round 1993 for my book "Porting UNIX Software" (didn't
we shout in those days?), and when we released the book under Creative
Commons in 2005 or so, the macros were released with it.  It's
available online as
http://www.lemis.com/grog/Documentation/PUS/tmac.Gbignuts.G

In passing I should mention that they required me to use those
macros.  At the time I wanted to use TeX, but they were "unwilling".
I used groff, and I've never used TeX since: a dead baby duck.

Greg
--
Sent from my desktop computer.
Finger grog at lemis.com for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 163 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190917/d8a48558/attachment.sig>

From grog at lemis.com  Tue Sep 17 10:16:55 2019
From: grog at lemis.com (Greg 'groggy' Lehey)
Date: Tue, 17 Sep 2019 10:16:55 +1000
Subject: [TUHS] earliest Unix roff
In-Reply-To: <alpine.BSF.2.21.9999.1909170739260.18105@aneurin.horsfall.org>
References: <20190913221345.GA16129@minnie.tuhs.org>
 <CAC20D2OQD-NJaFsqsLVL_kqmCsSeUOKAr7dm71P4uN9N8m+AbQ@mail.gmail.com>
 <20190914020240.GO2046@mcvoy.com>
 <20190914024433.GA19193@minnie.tuhs.org>
 <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org>
 <201909150654.x8F6sChG021185@freefriends.org>
 <CAC20D2PfLq=J5ei+izXb2J7dSvU6=L6-GRd0gKA2ShSNg1=qBg@mail.gmail.com>
 <201909160552.x8G5qBYK025195@freefriends.org>
 <CAC20D2N89jOBK+T9EPn8JKNaSOUx=yDr9t4=CcyHM+3qnB2bEg@mail.gmail.com>
 <alpine.BSF.2.21.9999.1909170739260.18105@aneurin.horsfall.org>
Message-ID: <20190917001655.GE31311@eureka.lemis.com>

On Tuesday, 17 September 2019 at  7:42:28 +1000, Dave Horsfall wrote:
> On Mon, 16 Sep 2019, Clem Cole wrote:
>
>> Fair enough, but be careful, while I admit I have not looked in a while,
>> info(gnu) relies on emacs keybindings and a number of very
>> emacs'ish things. Every time I have tried to deal with it, I have
>> unprogram my fingers and reset them to emacs.
>
> Yep, which is why I like "info" as much as I like EMACS i.e. not at
> all.

Maybe I've missed something, but I'm in the intermediate camp.  Emacs
is in my fingertips, and I wouldn't want to live without it, but I'd
far rather see info go away.  In some ways it anticipated HTML, but I
find navigation particularly painful.

> What exactly is wrong with the manpage format?

It's linear.

> It tells you everything you need to know, and tells you where to
> find further information.

Yes, but you need to follow the link manually.  Theoretically a good
HTML document would be better, but it's nice to have a linear form
that you can search.

For an extreme case of man pages, look at something like mplayer(1) or
mpv(1):

  $ man mplayer|wc -l
     9435
  $ man mpv|wc -l
     13939

That doesn't make them easy to read.

Greg
--
Sent from my desktop computer.
Finger grog at lemis.com for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 163 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190917/9b955fec/attachment.sig>

From doug at cs.dartmouth.edu  Tue Sep 17 10:20:32 2019
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Mon, 16 Sep 2019 20:20:32 -0400
Subject: [TUHS] block operations in editors, was  My EuroBSDcon talk
Message-ID: <201909170020.x8H0KWC6037690@tahoe.cs.Dartmouth.EDU>

> The "block copy in an editor" thing is something which has intrigued
> me for years. poor old ed/ex/vi just couldn't do it, and for the life
> of me, I could not understand why this was "deprecated" by the people
> writing that family of editors.

One might trace it to the founding tenet that a file is a stream of bytes,
reinforced by the absence of multidemensional arrays in C. But it goes
deeper than that.

Ed imposes a structure, making a (finite) file into an array, aka list,
of lines. It's easy to define block moves and copies in a list. But
what are the semantics of a block move, wherein one treats the list
as a ragged-right 2D array? What gets pushed aside? In what direction?
How does a block move into column that not all destination rows
reach? How do you cope when the bottom gets ragged? How about the
top? Can one move blocks of tab-separated fields?

I think everyone has rued the lack of block operations at one time
or another. But implementing them in any degree of generality is a
stumbling block. What should the semantics be?

> Similarly the 'repeat this sequence of commands' thing which emacs had.

Ed's g command does that, except the sequence can't contain another g.
Sam, barely harder than ed to learn, cures that deficiency and generalizes
in other ways, too--but has no block operations.

Doug

From krewat at kilonet.net  Tue Sep 17 10:21:43 2019
From: krewat at kilonet.net (Arthur Krewat)
Date: Mon, 16 Sep 2019 20:21:43 -0400
Subject: [TUHS] earliest Unix roff
In-Reply-To: <fb60a87c-a274-104c-38e3-8fcf63f02c12@gmail.com>
References: <CAC20D2NmXGzN7imTKy-RRWRZ2ewWMEmUV9oDuP3-e3a4R+ynpA@mail.gmail.com>
 <CAC20D2PvA26HMoABOcLMoS9Lu8=L3Wtx_8yK83K+vbhoMZt-hQ@mail.gmail.com>
 <463d5cc4-9bef-9ac3-a680-a5161d664dc1@aueb.gr>
 <CAC20D2Nz-ofwD41vULF2-TL8-C33heCiHvoNNbcuj6GGKhtKzQ@mail.gmail.com>
 <20190913221345.GA16129@minnie.tuhs.org>
 <CAC20D2OQD-NJaFsqsLVL_kqmCsSeUOKAr7dm71P4uN9N8m+AbQ@mail.gmail.com>
 <20190914020240.GO2046@mcvoy.com> <20190914024433.GA19193@minnie.tuhs.org>
 <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org>
 <201909150654.x8F6sChG021185@freefriends.org>
 <CAC20D2PfLq=J5ei+izXb2J7dSvU6=L6-GRd0gKA2ShSNg1=qBg@mail.gmail.com>
 <201909160552.x8G5qBYK025195@freefriends.org>
 <CAC20D2N89jOBK+T9EPn8JKNaSOUx=yDr9t4=CcyHM+3qnB2bEg@mail.gmail.com>
 <7wd0g0o2a0.fsf@junk.nocrew.org>
 <CAC20D2MBHSddOkjPUvat3GeF14-+oa2rMoppgFChzqOX+eUYpQ@mail.gmail.com>
 <alpine.BSF.2.21.9999.1909170804040.18105@aneurin.horsfall.org>
 <fb60a87c-a274-104c-38e3-8fcf63f02c12@gmail.com>
Message-ID: <32b57278-31c8-0dd2-38fb-87d80ee990a2@kilonet.net>

On 9/16/2019 8:02 PM, Nemo Nusquam wrote:
> On 09/16/19 18:05, Dave Horsfall wrote:
>> Am I the only one who remembers the old "pg" program? It seems to have
>> disappeared.
>
> Still ships with Solaris (in /usr/bin).

Now you've gone and said a bad word... ;)

art k.


From peter at rulingia.com  Tue Sep 17 10:28:25 2019
From: peter at rulingia.com (Peter Jeremy)
Date: Tue, 17 Sep 2019 10:28:25 +1000
Subject: [TUHS] [tuhs] Computer history preservation
In-Reply-To: <CMM.0.95.0.1568670516.beebe@gamma.math.utah.edu>
References: <CMM.0.95.0.1568670516.beebe@gamma.math.utah.edu>
Message-ID: <20190917002825.GA15016@server.rulingia.com>

On 2019-Sep-16 15:48:36 -0600, "Nelson H. F. Beebe" <beebe at math.utah.edu> wrote:
>I came across an article today about another major industry that has
>been exceedingly careless about preserving its history:
>
>        Wipe Out: When the BBC Kept Erasing Its Own History
>        https://getpocket.com/explore/item/wipe-out-when-the-bbc-kept-erasing-its-own-history
>
>It is a must-read for Dr Who fans on this list.

It didn't only affect TV, much of The Goons originals were also destroyed (at least
one episode now sold by the BBC is an off-air recording by a fan because that's the
best extant copy).

And NASA destroyed the tapes holding the original Apollo 11 moonwalk 
(https://en.wikipedia.org/wiki/Apollo_11_missing_tapes).

-- 
Peter Jeremy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190917/4160b08c/attachment.sig>

From scj at yaccman.com  Tue Sep 17 10:20:12 2019
From: scj at yaccman.com (Steve Johnson)
Date: Mon, 16 Sep 2019 17:20:12 -0700
Subject: [TUHS] earliest Unix roff
In-Reply-To: <201909152207.x8FM7BiA017274@tahoe.cs.Dartmouth.EDU>
Message-ID: <a29bfbe24692c1908f8a880041b816f6e9262baa@webmail.yaccman.com>


Dennis had a model 37 on his sunporch for years.  The innards were
nearly all mechanical -- cams and levers, etc.  And as the years went
by, wear and tear made the thing shake when it was being used.  
From time to time, it would shake so much that a space would be added
into whatever you were typing.

I think Dennis finally retired it after he typed the command "rm
*.o"  (a common command in those days of small discs), and got the
respnse ".o not found"

The model37 used fan-fold paper, that we got by the box.  It was an
art to arrange the paper flow so that the output didn't pile up inside
the box of blank paper,
but rather ended up in a pile on the floor.

In this era, Unix would, from time to time, crash unexpectedly,
causing you to lose all the edits you hadn't written out yet.  The
drill in that case was to
gather up the paper with all your typing on it, and, with a
highlighter, highlight the stuff you needed to retype when the system
came up.

One day I had been furiously editing a long program file for about an
hour and a half when I was called away to lunch, and, being hungry,
didn't save
my file.  When I got back to the terminal an hour later, I discovered
two things -- the system had crashed, and our cat had decided that the
pile of paper
on the floor made a great litter box.  After a few choice words, I
sighed and picked up my highliter...

Steve

----- Original Message -----
From: "Doug McIlroy" <doug at cs.dartmouth.edu>
To:<tuhs at tuhs.org>
Cc:
Sent:Sun, 15 Sep 2019 18:07:11 -0400
Subject:Re: [TUHS] earliest Unix roff

 > Excellent - thanks for the pointer. This shows nroff before troff.
 > FWIW: I guess I was miss informed, but I had been under the
impression
 > that was the other way around. i.e. nroff was done to be compliant
with
 > the new troff, replacing roff, although the suggestion here is that
he
 > wrote it add macros to roff. I'll note that either way, the dates
are all
 > possible of course because the U/L case ASR 37 was introduced 1968
so by
 > the early 1970's they would have been around the labs.

 nroff was in v2; troff appeared in v4, which incidentally was
 typeset in troff.

 Because of Joe Ossanna's role in designing the model 37, we
 had 37's in the Labs and even in our homes right from the
 start of production. But when they went obsolete, they were
 a chore to get rid of. As Labs property, they had to be
 returned; and picking them up was nobody's priority.
 Andy Hall had one on his back porch for a year.

 Doug


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190916/c3fc4bcd/attachment.html>

From jon at fourwinds.com  Tue Sep 17 10:31:33 2019
From: jon at fourwinds.com (Jon Steinhart)
Date: Mon, 16 Sep 2019 17:31:33 -0700
Subject: [TUHS] earliest Unix roff
In-Reply-To: <20190917001655.GE31311@eureka.lemis.com>
References: <20190913221345.GA16129@minnie.tuhs.org>
 <CAC20D2OQD-NJaFsqsLVL_kqmCsSeUOKAr7dm71P4uN9N8m+AbQ@mail.gmail.com>
 <20190914020240.GO2046@mcvoy.com> <20190914024433.GA19193@minnie.tuhs.org>
 <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org>
 <201909150654.x8F6sChG021185@freefriends.org>
 <CAC20D2PfLq=J5ei+izXb2J7dSvU6=L6-GRd0gKA2ShSNg1=qBg@mail.gmail.com>
 <201909160552.x8G5qBYK025195@freefriends.org>
 <CAC20D2N89jOBK+T9EPn8JKNaSOUx=yDr9t4=CcyHM+3qnB2bEg@mail.gmail.com>
 <alpine.BSF.2.21.9999.1909170739260.18105@aneurin.horsfall.org>
 <20190917001655.GE31311@eureka.lemis.com>
Message-ID: <201909170031.x8H0VcYE032303@darkstar.fourwinds.com>

Greg 'groggy' Lehey writes:
>
> Yes, but you need to follow the link manually.  Theoretically a good
> HTML document would be better, but it's nice to have a linear form
> that you can search.

Isn't "good HTML document" an oxymoron?

From g.branden.robinson at gmail.com  Tue Sep 17 10:42:36 2019
From: g.branden.robinson at gmail.com (G. Branden Robinson)
Date: Tue, 17 Sep 2019 10:42:36 +1000
Subject: [TUHS] block operations in editors, was  My EuroBSDcon talk
In-Reply-To: <201909170020.x8H0KWC6037690@tahoe.cs.Dartmouth.EDU>
References: <201909170020.x8H0KWC6037690@tahoe.cs.Dartmouth.EDU>
Message-ID: <20190917004233.4cgn6vabnmgwl5q5@localhost.localdomain>

At 2019-09-16T20:20:32-0400, Doug McIlroy wrote:
> Ed imposes a structure, making a (finite) file into an array, aka
> list, of lines. It's easy to define block moves and copies in a list.
> But what are the semantics of a block move, wherein one treats the
> list as a ragged-right 2D array? What gets pushed aside? In what
> direction?  How does a block move into column that not all destination
> rows reach? How do you cope when the bottom gets ragged? How about the
> top? Can one move blocks of tab-separated fields?
> 
> I think everyone has rued the lack of block operations at one time or
> another. But implementing them in any degree of generality is a
> stumbling block. What should the semantics be?

Just in case anyone didn't know, Vim has what it calls "visual block"
highlighting and operations.  CTRL-V begins one and you use the usual
movement keys to shape and size it, then an operator like (y)ank or
(d)elete.

It won't always work as one expects because of the very questions that
Doug raises above.

Vim also has characterwise blocks (begin with 'v') and linewise blocks
(begin with 'V').

The last is, more than any other single factor, what pulled me over from
traditional vi (really nvi in my case).  It was a big win over
line-counting with ":.,+n" expressions.  In retrospect I should have
been smarter and just typed ":.,/pattern/", using as /pattern/ some
short string that did not appear in any of the lines I wanted to operate
on.

Though the vi clone with the best name was, indisputably, elvis.

Regards,
Branden
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190917/11cbf6a7/attachment-0001.sig>

From clemc at ccc.com  Tue Sep 17 10:46:20 2019
From: clemc at ccc.com (Clem Cole)
Date: Mon, 16 Sep 2019 20:46:20 -0400
Subject: [TUHS] earliest Unix roff
In-Reply-To: <alpine.BSF.2.21.9999.1909170804040.18105@aneurin.horsfall.org>
References: <CAC20D2NmXGzN7imTKy-RRWRZ2ewWMEmUV9oDuP3-e3a4R+ynpA@mail.gmail.com>
 <CAC20D2MDbmoeMZq1esbuQvOCU7to0dUWsFyx98UQDLE3-c4fOA@mail.gmail.com>
 <201909132024.x8DKObEP013266@darkstar.fourwinds.com>
 <CAC20D2PvA26HMoABOcLMoS9Lu8=L3Wtx_8yK83K+vbhoMZt-hQ@mail.gmail.com>
 <463d5cc4-9bef-9ac3-a680-a5161d664dc1@aueb.gr>
 <CAC20D2Nz-ofwD41vULF2-TL8-C33heCiHvoNNbcuj6GGKhtKzQ@mail.gmail.com>
 <20190913221345.GA16129@minnie.tuhs.org>
 <CAC20D2OQD-NJaFsqsLVL_kqmCsSeUOKAr7dm71P4uN9N8m+AbQ@mail.gmail.com>
 <20190914020240.GO2046@mcvoy.com> <20190914024433.GA19193@minnie.tuhs.org>
 <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org>
 <201909150654.x8F6sChG021185@freefriends.org>
 <CAC20D2PfLq=J5ei+izXb2J7dSvU6=L6-GRd0gKA2ShSNg1=qBg@mail.gmail.com>
 <201909160552.x8G5qBYK025195@freefriends.org>
 <CAC20D2N89jOBK+T9EPn8JKNaSOUx=yDr9t4=CcyHM+3qnB2bEg@mail.gmail.com>
 <7wd0g0o2a0.fsf@junk.nocrew.org>
 <CAC20D2MBHSddOkjPUvat3GeF14-+oa2rMoppgFChzqOX+eUYpQ@mail.gmail.com>
 <alpine.BSF.2.21.9999.1909170804040.18105@aneurin.horsfall.org>
Message-ID: <CAC20D2OLMU3Efs-FDr6sQ431PgomBOZT7KH7eVRp5qtti70JYQ@mail.gmail.com>

The USG pg program was created after UCB released more.  Btw this was
before vi or csh was distributed.  But too many BTL folks had seen BSD
during there OYOC year and either demanded it or had brought what was in
effect 2BSD back with them.

On Mon, Sep 16, 2019 at 6:06 PM Dave Horsfall <dave at horsfall.org> wrote:

> On Mon, 16 Sep 2019, Clem Cole wrote:
>
> > >       However, please note that more(1) also was inspired by, almost
> > >       copied from, ITS.  Certainly the prompt --More-- is.
> >
> > Absolutely.  A friend of mine/fellow UCB grad student, Eric Shienbrood,
> > wrote it.  He was a MIT undergrad. And Eric happily said it was modeled
> > from ITS. And before, Eric wrote it, UNIX lacked anything like it.
> >  Which to me is fine, taking an idea from another system to add a new
> > feature that is lacking.
>
> Am I the only one who remembers the old "pg" program?  It seems to have
> disappeared.
>
> -- Dave

-- 
Sent from a handheld expect more typos than usual
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190916/b15cb661/attachment.html>

From clemc at ccc.com  Tue Sep 17 10:51:54 2019
From: clemc at ccc.com (Clem Cole)
Date: Mon, 16 Sep 2019 20:51:54 -0400
Subject: [TUHS] O'Reilly groff macros (was:  earliest Unix roff)
In-Reply-To: <20190917001056.GD31311@eureka.lemis.com>
References: <463d5cc4-9bef-9ac3-a680-a5161d664dc1@aueb.gr>
 <CAC20D2Nz-ofwD41vULF2-TL8-C33heCiHvoNNbcuj6GGKhtKzQ@mail.gmail.com>
 <20190913221345.GA16129@minnie.tuhs.org>
 <CAC20D2OQD-NJaFsqsLVL_kqmCsSeUOKAr7dm71P4uN9N8m+AbQ@mail.gmail.com>
 <20190914020240.GO2046@mcvoy.com> <20190914024433.GA19193@minnie.tuhs.org>
 <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org>
 <CAC20D2M5j+pCBpxf4Cy-sK4BfBGj_RMhzSpGaXMZmeEaGV9cDA@mail.gmail.com>
 <069494b2-ec5b-91e7-8618-2d111e0e5aa2@andrewnesbit.org>
 <201909160620.x8G6KkJq026850@freefriends.org>
 <20190917001056.GD31311@eureka.lemis.com>
Message-ID: <CAC20D2MNLumDDvQgXZ3nciNeaNaMATu=46AAY8P6zCoQnuhmRA@mail.gmail.com>

FYI Which Dale and Tim used at Masscomp  4 years earlier.  That book was
originally modeled from Janet Eagans style guide which I still have.

On Mon, Sep 16, 2019 at 8:11 PM Greg 'groggy' Lehey <grog at lemis.com> wrote:

> On Monday, 16 September 2019 at  0:20:46 -0600, arnold at skeeve.com wrote:
> >> 1.  Do you think there is any chance of obtaining these macro packages?
> >> Either from authors who haven't passed away, or from the publishing
> >> houses themselves?
> >
> > O'Reilly probably would. I can ask someone there, if there's serious
> > interest here.  They haven't used troff for book production for well
> > over a decade.
>
> The O'Reilly macro package was derived from the macros described in
> Dougherty and O'Reilly "UNIX Text Processing" (Hayden 1988).  I
> received a copy round 1993 for my book "Porting UNIX Software" (didn't
> we shout in those days?), and when we released the book under Creative
> Commons in 2005 or so, the macros were released with it.  It's
> available online as
> http://www.lemis.com/grog/Documentation/PUS/tmac.Gbignuts.G
>
> In passing I should mention that they required me to use those
> macros.  At the time I wanted to use TeX, but they were "unwilling".
> I used groff, and I've never used TeX since: a dead baby duck.
>
> Greg
> --
> Sent from my desktop computer.
> Finger grog at lemis.com for PGP public key.
> See complete headers for address and phone numbers.
> This message is digitally signed.  If your Microsoft mail program
> reports problems, please read http://lemis.com/broken-MUA
>
-- 
Sent from a handheld expect more typos than usual
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190916/97cabfd1/attachment.html>

From ullbeking at andrewnesbit.org  Tue Sep 17 10:54:21 2019
From: ullbeking at andrewnesbit.org (U'll Be King of the Stars)
Date: Tue, 17 Sep 2019 01:54:21 +0100
Subject: [TUHS] O'Reilly groff macros
In-Reply-To: <CAC20D2MNLumDDvQgXZ3nciNeaNaMATu=46AAY8P6zCoQnuhmRA@mail.gmail.com>
References: <463d5cc4-9bef-9ac3-a680-a5161d664dc1@aueb.gr>
 <CAC20D2Nz-ofwD41vULF2-TL8-C33heCiHvoNNbcuj6GGKhtKzQ@mail.gmail.com>
 <20190913221345.GA16129@minnie.tuhs.org>
 <CAC20D2OQD-NJaFsqsLVL_kqmCsSeUOKAr7dm71P4uN9N8m+AbQ@mail.gmail.com>
 <20190914020240.GO2046@mcvoy.com> <20190914024433.GA19193@minnie.tuhs.org>
 <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org>
 <CAC20D2M5j+pCBpxf4Cy-sK4BfBGj_RMhzSpGaXMZmeEaGV9cDA@mail.gmail.com>
 <069494b2-ec5b-91e7-8618-2d111e0e5aa2@andrewnesbit.org>
 <201909160620.x8G6KkJq026850@freefriends.org>
 <20190917001056.GD31311@eureka.lemis.com>
 <CAC20D2MNLumDDvQgXZ3nciNeaNaMATu=46AAY8P6zCoQnuhmRA@mail.gmail.com>
Message-ID: <498796af-156b-65e0-374d-38afd95c0968@andrewnesbit.org>

On 17/09/2019 01:51, Clem Cole wrote:
> FYI Which Dale and Tim used at Masscomp  4 years earlier.  That book was 
> originally modeled from Janet Eagans style guide which I still have.

I LOVE style guides.  I have a bit of a thing for them.

Was the Eagans guide published?  (Andrew shuffles off to Amazon.)

Andrew
-- 
OpenPGP key: EB28 0338 28B7 19DA DAB0  B193 D21D 996E 883B E5B9

From clemc at ccc.com  Tue Sep 17 11:03:40 2019
From: clemc at ccc.com (Clem Cole)
Date: Mon, 16 Sep 2019 21:03:40 -0400
Subject: [TUHS] O'Reilly groff macros
In-Reply-To: <498796af-156b-65e0-374d-38afd95c0968@andrewnesbit.org>
References: <463d5cc4-9bef-9ac3-a680-a5161d664dc1@aueb.gr>
 <CAC20D2Nz-ofwD41vULF2-TL8-C33heCiHvoNNbcuj6GGKhtKzQ@mail.gmail.com>
 <20190913221345.GA16129@minnie.tuhs.org>
 <CAC20D2OQD-NJaFsqsLVL_kqmCsSeUOKAr7dm71P4uN9N8m+AbQ@mail.gmail.com>
 <20190914020240.GO2046@mcvoy.com> <20190914024433.GA19193@minnie.tuhs.org>
 <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org>
 <CAC20D2M5j+pCBpxf4Cy-sK4BfBGj_RMhzSpGaXMZmeEaGV9cDA@mail.gmail.com>
 <069494b2-ec5b-91e7-8618-2d111e0e5aa2@andrewnesbit.org>
 <201909160620.x8G6KkJq026850@freefriends.org>
 <20190917001056.GD31311@eureka.lemis.com>
 <CAC20D2MNLumDDvQgXZ3nciNeaNaMATu=46AAY8P6zCoQnuhmRA@mail.gmail.com>
 <498796af-156b-65e0-374d-38afd95c0968@andrewnesbit.org>
Message-ID: <CAC20D2NpB3D7cgm4owvxBWXqSzvwGpWkqS3zJaF9Te_VR6_cNg@mail.gmail.com>

No. It was given to all the Masscomp writers and of course all of Tims at
the beginning since we were his primary client in those days.  He had not
yet done the X11 books which was what made Tim’s business.

On Mon, Sep 16, 2019 at 8:54 PM U'll Be King of the Stars <
ullbeking at andrewnesbit.org> wrote:

> On 17/09/2019 01:51, Clem Cole wrote:
> > FYI Which Dale and Tim used at Masscomp  4 years earlier.  That book was
> > originally modeled from Janet Eagans style guide which I still have.
>
> I LOVE style guides.  I have a bit of a thing for them.
>
> Was the Eagans guide published?  (Andrew shuffles off to Amazon.)
>
> Andrew
> --
> OpenPGP key: EB28 0338 28B7 19DA DAB0  B193 D21D 996E 883B E5B9
>
-- 
Sent from a handheld expect more typos than usual
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190916/7c4a6f92/attachment.html>

From krewat at kilonet.net  Tue Sep 17 11:11:17 2019
From: krewat at kilonet.net (Arthur Krewat)
Date: Mon, 16 Sep 2019 21:11:17 -0400
Subject: [TUHS] earliest Unix roff
In-Reply-To: <a29bfbe24692c1908f8a880041b816f6e9262baa@webmail.yaccman.com>
References: <a29bfbe24692c1908f8a880041b816f6e9262baa@webmail.yaccman.com>
Message-ID: <0bc0d10f-d17c-24df-2a7f-8f154eefd318@kilonet.net>

On 9/16/2019 8:20 PM, Steve Johnson wrote:
> One day I had been furiously editing a long program file for about an 
> hour and a half when I was called away to lunch, and, being hungry, 
> didn't save
> my file.  When I got back to the terminal an hour later, I discovered 
> two things -- the system had crashed, and our cat had decided that the 
> pile of paper
> on the floor made a great litter box.  After a few choice words, I 
> sighed and picked up my highliter...

This should be engraved on a plaque somewhere. Only because I had almost 
the same thing happen to me, without the cat though. I had a printout of a
"mail" program I had written on TOPS-10 at high school. I had to retype 
the entire thing after the file got corrupted.

Yay MACRO-10

From ron at ronnatalie.com  Tue Sep 17 11:11:59 2019
From: ron at ronnatalie.com (Ronald Natalie)
Date: Mon, 16 Sep 2019 21:11:59 -0400
Subject: [TUHS] Model 37's
In-Reply-To: <a29bfbe24692c1908f8a880041b816f6e9262baa@webmail.yaccman.com>
References: <a29bfbe24692c1908f8a880041b816f6e9262baa@webmail.yaccman.com>
Message-ID: <77060A04-696A-4789-A63A-D7A725B5AA63@ronnatalie.com>

Hopkins had a KSR37 in a small office (or perhaps closet) on the second floor.   It was also fitted with a modem I built (a Pennywhistle, an absolutely abhorrant design).
It had the greek box and we used it for many a nroff term paper or the like.    It was also our way of getting on the Arpanet.    The university had a “tie line” that let us call the DC metro area so we could get into the Pentagon TIP.    However, Mike Muuss also convinced the operator once to place a collect call.    “It’s a computer we are calling,” he told her.   “If it beeps, it accepts the charges.”   (This was perhaps one of the boldest operator hacks until Brian Redman and Peter Langston were screwing around with a phone switch and programmed it to answer the phone:   “Bell Communications Research” (long pause) “Yes, Operator!   I’ll accept the charges.”


After I graduated from JHU, I found an ASR 37 in a surplus sale.    I had it for years in my apartment kitchen.   Not only did it handle all the nroff ESC-8/ESC-9 stuff and the like without need for an output filter, it had a giant NEWLINE key on the right side and was perhaps the only terminal I ever used that didn’t need the unix NL->CRLF mapping turned on.     Amusingly, the thing sat there idle until DSR came up on the modem and then its motors would start.    When CD came on a bright green PROCEED light illuminated on the front of it.    I used it for years until modems got up to the 9600 baud range and decided a CRT would be nicer than the printing terminal.

I gave mine to RS who I think used it to block in someone’s car at one of the nacent long distance data carriers (was either Sprint or MCI).
   
	

From lm at mcvoy.com  Tue Sep 17 11:17:52 2019
From: lm at mcvoy.com (Larry McVoy)
Date: Mon, 16 Sep 2019 18:17:52 -0700
Subject: [TUHS] earliest Unix roff
In-Reply-To: <0bc0d10f-d17c-24df-2a7f-8f154eefd318@kilonet.net>
References: <a29bfbe24692c1908f8a880041b816f6e9262baa@webmail.yaccman.com>
 <0bc0d10f-d17c-24df-2a7f-8f154eefd318@kilonet.net>
Message-ID: <20190917011752.GY2046@mcvoy.com>

On Mon, Sep 16, 2019 at 09:11:17PM -0400, Arthur Krewat wrote:
> On 9/16/2019 8:20 PM, Steve Johnson wrote:
> >One day I had been furiously editing a long program file for about an hour
> >and a half when I was called away to lunch, and, being hungry, didn't save
> >my file.?? When I got back to the terminal an hour later, I discovered two
> >things -- the system had crashed, and our cat had decided that the pile of
> >paper
> >on the floor made a great litter box.?? After a few choice words, I sighed
> >and picked up my highliter...
> 
> This should be engraved on a plaque somewhere. Only because I had almost the
> same thing happen to me, without the cat though. I had a printout of a
> "mail" program I had written on TOPS-10 at high school. I had to retype the
> entire thing after the file got corrupted.

I think we have all been there.  Something always goes wrong.  I wrote 
a paper about how to restore a Masscomp because I did rm -rf . in /.
I believe we had roots home as / because /usr was a different partition.
Clem, did Masscomp make roots home / or was that us?  Anyway, I did a
cd something
and somehow deleted the something and then did rm -rf .
Much fun was had, I was up all night putting things back together.
This was probably around 1984 or 1985, I was pretty green.

From bakul at bitblocks.com  Tue Sep 17 11:19:15 2019
From: bakul at bitblocks.com (Bakul Shah)
Date: Mon, 16 Sep 2019 18:19:15 -0700
Subject: [TUHS] earliest Unix roff
In-Reply-To: <a29bfbe24692c1908f8a880041b816f6e9262baa@webmail.yaccman.com>
References: <a29bfbe24692c1908f8a880041b816f6e9262baa@webmail.yaccman.com>
Message-ID: <9E4D392E-DB0B-45E6-9B97-02469DCCC590@bitblocks.com>

The one time you didn't want any cat output....

> On Sep 16, 2019, at 5:20 PM, Steve Johnson <scj at yaccman.com> wrote:
> 
> One day I had been furiously editing a long program file for about an hour and a half when I was called away to lunch, and, being hungry, didn't save
> my file.  When I got back to the terminal an hour later, I discovered two things -- the system had crashed, and our cat had decided that the pile of paper
> on the floor made a great litter box.  After a few choice words, I sighed and picked up my highliter...
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190916/ed7908db/attachment.html>

From bakul at bitblocks.com  Tue Sep 17 11:25:39 2019
From: bakul at bitblocks.com (Bakul Shah)
Date: Mon, 16 Sep 2019 18:25:39 -0700
Subject: [TUHS] block operations in editors, was My EuroBSDcon talk
In-Reply-To: Your message of "Mon, 16 Sep 2019 20:20:32 -0400."
 <201909170020.x8H0KWC6037690@tahoe.cs.Dartmouth.EDU>
References: <201909170020.x8H0KWC6037690@tahoe.cs.Dartmouth.EDU>
Message-ID: <20190917012546.392E51570CE9@mail.bitblocks.com>

On Mon, 16 Sep 2019 20:20:32 -0400 Doug McIlroy <doug at cs.dartmouth.edu> wrote:
Doug McIlroy writes:
> > The "block copy in an editor" thing is something which has intrigued
> > me for years. poor old ed/ex/vi just couldn't do it, and for the life
> > of me, I could not understand why this was "deprecated" by the people
> > writing that family of editors.
>
> One might trace it to the founding tenet that a file is a stream of bytes,
> reinforced by the absence of multidemensional arrays in C. But it goes
> deeper than that.
>
> Ed imposes a structure, making a (finite) file into an array, aka list,
> of lines. It's easy to define block moves and copies in a list. But
> what are the semantics of a block move, wherein one treats the list
> as a ragged-right 2D array? What gets pushed aside? In what direction?
> How does a block move into column that not all destination rows
> reach? How do you cope when the bottom gets ragged? How about the
> top? Can one move blocks of tab-separated fields?
>
> I think everyone has rued the lack of block operations at one time
> or another. But implementing them in any degree of generality is a
> stumbling block. What should the semantics be?

The Rand editor e handled all this reasonably well.

A file was treated as a virtual quarter plane, with 0,0 as
the start of the file (you could move a cursor anywhere
including a non-existant line or column.  Extra blanks or
lines were added only if you actually typed something there).

In the command line (like vi's exmode) for many commands you
can specify an area of operation which can be n lines, n
paragraphs or a rectangle, starting at the cursor position. Or
you can select a rectangular area with the "mark" command. If
you move the cursor straight down, N lines would be chosen.
To pick nx1 rectangle, you move cursor right one place after
marking.

open would open up a blank area,  pushing text left as
necessary.  close would close up an area, pushing text right
if necessary. erase would blank out an area (erase text but
leave text outside alone). run command replaced the contents
with the output of a shell command. feed was like run except
it kept the original and inserted new data at the cursor.

Tabs were not separators but stood for specific columns.  By
default every 8 columns but you could change them to whatever.
picking a rectangle handled them appropriately.  IIRC.  You
stored non standard tab positions in a separate file.

From clemc at ccc.com  Tue Sep 17 11:26:34 2019
From: clemc at ccc.com (Clem cole)
Date: Mon, 16 Sep 2019 21:26:34 -0400
Subject: [TUHS] earliest Unix roff
In-Reply-To: <20190917011752.GY2046@mcvoy.com>
References: <a29bfbe24692c1908f8a880041b816f6e9262baa@webmail.yaccman.com>
 <0bc0d10f-d17c-24df-2a7f-8f154eefd318@kilonet.net>
 <20190917011752.GY2046@mcvoy.com>
Message-ID: <60761215-5B0E-41E9-A333-8799C6FAADD3@ccc.com>

I’ve forgotten but it could have been early on. Having /root as the super users home directory was on later systems. I thought Masscomp did that but I might be thinking Stellar by then.  

Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. 

> On Sep 16, 2019, at 9:17 PM, Larry McVoy <lm at mcvoy.com> wrote:
> 
>> On Mon, Sep 16, 2019 at 09:11:17PM -0400, Arthur Krewat wrote:
>>> On 9/16/2019 8:20 PM, Steve Johnson wrote:
>>> One day I had been furiously editing a long program file for about an hour
>>> and a half when I was called away to lunch, and, being hungry, didn't save
>>> my file.?? When I got back to the terminal an hour later, I discovered two
>>> things -- the system had crashed, and our cat had decided that the pile of
>>> paper
>>> on the floor made a great litter box.?? After a few choice words, I sighed
>>> and picked up my highliter...
>> 
>> This should be engraved on a plaque somewhere. Only because I had almost the
>> same thing happen to me, without the cat though. I had a printout of a
>> "mail" program I had written on TOPS-10 at high school. I had to retype the
>> entire thing after the file got corrupted.
> 
> I think we have all been there.  Something always goes wrong.  I wrote 
> a paper about how to restore a Masscomp because I did rm -rf . in /.
> I believe we had roots home as / because /usr was a different partition.
> Clem, did Masscomp make roots home / or was that us?  Anyway, I did a
> cd something
> and somehow deleted the something and then did rm -rf .
> Much fun was had, I was up all night putting things back together.
> This was probably around 1984 or 1985, I was pretty green.

From lm at mcvoy.com  Tue Sep 17 11:33:57 2019
From: lm at mcvoy.com (Larry McVoy)
Date: Mon, 16 Sep 2019 18:33:57 -0700
Subject: [TUHS] earliest Unix roff
In-Reply-To: <60761215-5B0E-41E9-A333-8799C6FAADD3@ccc.com>
References: <a29bfbe24692c1908f8a880041b816f6e9262baa@webmail.yaccman.com>
 <0bc0d10f-d17c-24df-2a7f-8f154eefd318@kilonet.net>
 <20190917011752.GY2046@mcvoy.com>
 <60761215-5B0E-41E9-A333-8799C6FAADD3@ccc.com>
Message-ID: <20190917013357.GA2046@mcvoy.com>

In retrospect having / be roots home is a super bad idea but I think it
was fairly common practice, /root became a thing as idiots like me 
messed things up :)

On Mon, Sep 16, 2019 at 09:26:34PM -0400, Clem cole wrote:
> I???ve forgotten but it could have been early on. Having /root as the super users home directory was on later systems. I thought Masscomp did that but I might be thinking Stellar by then.  
> 
> Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. 
> 
> > On Sep 16, 2019, at 9:17 PM, Larry McVoy <lm at mcvoy.com> wrote:
> > 
> >> On Mon, Sep 16, 2019 at 09:11:17PM -0400, Arthur Krewat wrote:
> >>> On 9/16/2019 8:20 PM, Steve Johnson wrote:
> >>> One day I had been furiously editing a long program file for about an hour
> >>> and a half when I was called away to lunch, and, being hungry, didn't save
> >>> my file.?? When I got back to the terminal an hour later, I discovered two
> >>> things -- the system had crashed, and our cat had decided that the pile of
> >>> paper
> >>> on the floor made a great litter box.?? After a few choice words, I sighed
> >>> and picked up my highliter...
> >> 
> >> This should be engraved on a plaque somewhere. Only because I had almost the
> >> same thing happen to me, without the cat though. I had a printout of a
> >> "mail" program I had written on TOPS-10 at high school. I had to retype the
> >> entire thing after the file got corrupted.
> > 
> > I think we have all been there.  Something always goes wrong.  I wrote 
> > a paper about how to restore a Masscomp because I did rm -rf . in /.
> > I believe we had roots home as / because /usr was a different partition.
> > Clem, did Masscomp make roots home / or was that us?  Anyway, I did a
> > cd something
> > and somehow deleted the something and then did rm -rf .
> > Much fun was had, I was up all night putting things back together.
> > This was probably around 1984 or 1985, I was pretty green.

-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 

From clemc at ccc.com  Tue Sep 17 11:36:40 2019
From: clemc at ccc.com (Clem cole)
Date: Mon, 16 Sep 2019 21:36:40 -0400
Subject: [TUHS] wizards test [was roff]
In-Reply-To: <20190917011752.GY2046@mcvoy.com>
References: <a29bfbe24692c1908f8a880041b816f6e9262baa@webmail.yaccman.com>
 <0bc0d10f-d17c-24df-2a7f-8f154eefd318@kilonet.net>
 <20190917011752.GY2046@mcvoy.com>
Message-ID: <1583C418-2F6E-45D8-93C2-B93032E6CFFC@ccc.com>

Btw.  This was some I used as a wizards test. 

You have a working system next to a system that is still running so you have the console and its shell but had the rm -fr / done to it.  You have lost all of bin dev etc and lib by the time he hit ^C.   So you have some of /usr inc but much of /usr/bin is still there.    No compiler or assembler on the broken machine since that was in bin and lib.   

It’s possible to fix it using the other system to help.  Just don’t turn the damaged system off 🍺

Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. 

> On Sep 16, 2019, at 9:17 PM, Larry McVoy <lm at mcvoy.com> wrote:
> 
>> On Mon, Sep 16, 2019 at 09:11:17PM -0400, Arthur Krewat wrote:
>>> On 9/16/2019 8:20 PM, Steve Johnson wrote:
>>> One day I had been furiously editing a long program file for about an hour
>>> and a half when I was called away to lunch, and, being hungry, didn't save
>>> my file.?? When I got back to the terminal an hour later, I discovered two
>>> things -- the system had crashed, and our cat had decided that the pile of
>>> paper
>>> on the floor made a great litter box.?? After a few choice words, I sighed
>>> and picked up my highliter...
>> 
>> This should be engraved on a plaque somewhere. Only because I had almost the
>> same thing happen to me, without the cat though. I had a printout of a
>> "mail" program I had written on TOPS-10 at high school. I had to retype the
>> entire thing after the file got corrupted.
> 
> I think we have all been there.  Something always goes wrong.  I wrote 
> a paper about how to restore a Masscomp because I did rm -rf . in /.
> I believe we had roots home as / because /usr was a different partition.
> Clem, did Masscomp make roots home / or was that us?  Anyway, I did a
> cd something
> and somehow deleted the something and then did rm -rf .
> Much fun was had, I was up all night putting things back together.
> This was probably around 1984 or 1985, I was pretty green.

From rich.salz at gmail.com  Tue Sep 17 11:36:40 2019
From: rich.salz at gmail.com (Richard Salz)
Date: Mon, 16 Sep 2019 21:36:40 -0400
Subject: [TUHS] earliest Unix roff
In-Reply-To: <60761215-5B0E-41E9-A333-8799C6FAADD3@ccc.com>
References: <a29bfbe24692c1908f8a880041b816f6e9262baa@webmail.yaccman.com>
 <0bc0d10f-d17c-24df-2a7f-8f154eefd318@kilonet.net>
 <20190917011752.GY2046@mcvoy.com>
 <60761215-5B0E-41E9-A333-8799C6FAADD3@ccc.com>
Message-ID: <CAFH29tqjHU90bN8K466x6a-j4C=o=j1x783+Sqrfk4KPkQC10A@mail.gmail.com>

We've all been there.  I won a Unix "most egregious use of Unix tools"
award from Usenix for this small script
   trap 'ls | wc' 1 2 3 15
   echo Reflex test. Type control-c
   ls | wc
   rm *

Because I also did "rm * .o"

I still have the ugly little warthog, anatomically correct, on my desk.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190916/0971bd40/attachment.html>

From clemc at ccc.com  Tue Sep 17 11:38:19 2019
From: clemc at ccc.com (Clem cole)
Date: Mon, 16 Sep 2019 21:38:19 -0400
Subject: [TUHS] wizards test [was roff]
In-Reply-To: <1583C418-2F6E-45D8-93C2-B93032E6CFFC@ccc.com>
References: <a29bfbe24692c1908f8a880041b816f6e9262baa@webmail.yaccman.com>
 <0bc0d10f-d17c-24df-2a7f-8f154eefd318@kilonet.net>
 <20190917011752.GY2046@mcvoy.com>
 <1583C418-2F6E-45D8-93C2-B93032E6CFFC@ccc.com>
Message-ID: <FF982C0E-8477-4848-84AE-E140FF17CB43@ccc.com>

I should say you have a root shell on the broken system which why it killed every thing. 

Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. 

> On Sep 16, 2019, at 9:36 PM, Clem cole <clemc at ccc.com> wrote:
> 
> Btw.  This was some I used as a wizards test. 
> 
> You have a working system next to a system that is still running so you have the console and its shell but had the rm -fr / done to it.  You have lost all of bin dev etc and lib by the time he hit ^C.   So you have some of /usr inc but much of /usr/bin is still there.    No compiler or assembler on the broken machine since that was in bin and lib.   
> 
> It’s possible to fix it using the other system to help.  Just don’t turn the damaged system off 🍺
> 
> Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. 
> 
>>> On Sep 16, 2019, at 9:17 PM, Larry McVoy <lm at mcvoy.com> wrote:
>>> 
>>>> On Mon, Sep 16, 2019 at 09:11:17PM -0400, Arthur Krewat wrote:
>>>> On 9/16/2019 8:20 PM, Steve Johnson wrote:
>>>> One day I had been furiously editing a long program file for about an hour
>>>> and a half when I was called away to lunch, and, being hungry, didn't save
>>>> my file.?? When I got back to the terminal an hour later, I discovered two
>>>> things -- the system had crashed, and our cat had decided that the pile of
>>>> paper
>>>> on the floor made a great litter box.?? After a few choice words, I sighed
>>>> and picked up my highliter...
>>> 
>>> This should be engraved on a plaque somewhere. Only because I had almost the
>>> same thing happen to me, without the cat though. I had a printout of a
>>> "mail" program I had written on TOPS-10 at high school. I had to retype the
>>> entire thing after the file got corrupted.
>> 
>> I think we have all been there.  Something always goes wrong.  I wrote 
>> a paper about how to restore a Masscomp because I did rm -rf . in /.
>> I believe we had roots home as / because /usr was a different partition.
>> Clem, did Masscomp make roots home / or was that us?  Anyway, I did a
>> cd something
>> and somehow deleted the something and then did rm -rf .
>> Much fun was had, I was up all night putting things back together.
>> This was probably around 1984 or 1985, I was pretty green.

From grog at lemis.com  Tue Sep 17 11:41:08 2019
From: grog at lemis.com (Greg 'groggy' Lehey)
Date: Tue, 17 Sep 2019 11:41:08 +1000
Subject: [TUHS] O'Reilly groff macros
In-Reply-To: <498796af-156b-65e0-374d-38afd95c0968@andrewnesbit.org>
References: <CAC20D2OQD-NJaFsqsLVL_kqmCsSeUOKAr7dm71P4uN9N8m+AbQ@mail.gmail.com>
 <20190914020240.GO2046@mcvoy.com>
 <20190914024433.GA19193@minnie.tuhs.org>
 <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org>
 <CAC20D2M5j+pCBpxf4Cy-sK4BfBGj_RMhzSpGaXMZmeEaGV9cDA@mail.gmail.com>
 <069494b2-ec5b-91e7-8618-2d111e0e5aa2@andrewnesbit.org>
 <201909160620.x8G6KkJq026850@freefriends.org>
 <20190917001056.GD31311@eureka.lemis.com>
 <CAC20D2MNLumDDvQgXZ3nciNeaNaMATu=46AAY8P6zCoQnuhmRA@mail.gmail.com>
 <498796af-156b-65e0-374d-38afd95c0968@andrewnesbit.org>
Message-ID: <20190917014108.GF31311@eureka.lemis.com>

On Tuesday, 17 September 2019 at  1:54:21 +0100, U'll Be King of the Stars wrote:
> On 17/09/2019 01:51, Clem Cole wrote:
>> FYI Which Dale and Tim used at Masscomp  4 years earlier.  That book was
>> originally modeled from Janet Eagans style guide which I still have.
>
> I LOVE style guides.  I have a bit of a thing for them.
>
> Was the Eagans guide published?  (Andrew shuffles off to Amazon.)

I didn't get it when I signed up with O'Reilly.  Instead they pointed
me at the Chicago Manual of Style, which got me interested in the idea
of style as well.  It's fascinating how much the individual guides
differ.

Greg
--
Sent from my desktop computer.
Finger grog at lemis.com for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 163 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190917/de0ea8bd/attachment.sig>

From bakul at bitblocks.com  Tue Sep 17 11:57:24 2019
From: bakul at bitblocks.com (Bakul Shah)
Date: Mon, 16 Sep 2019 18:57:24 -0700
Subject: [TUHS] earliest Unix roff
In-Reply-To: Your message of "Mon, 16 Sep 2019 18:17:52 -0700."
 <20190917011752.GY2046@mcvoy.com>
References: <a29bfbe24692c1908f8a880041b816f6e9262baa@webmail.yaccman.com>
 <0bc0d10f-d17c-24df-2a7f-8f154eefd318@kilonet.net>
 <20190917011752.GY2046@mcvoy.com>
Message-ID: <20190917015731.7758D1570CE9@mail.bitblocks.com>

On Mon, 16 Sep 2019 18:17:52 -0700 Larry McVoy <lm at mcvoy.com> wrote:
> On Mon, Sep 16, 2019 at 09:11:17PM -0400, Arthur Krewat wrote:
> > On 9/16/2019 8:20 PM, Steve Johnson wrote:
> > >One day I had been furiously editing a long program file for about an hour
> > >and a half when I was called away to lunch, and, being hungry, didn't save
> > >my file.?? When I got back to the terminal an hour later, I discovered two
> > >things -- the system had crashed, and our cat had decided that the pile of
> > >paper
> > >on the floor made a great litter box.?? After a few choice words, I sighed
> > >and picked up my highliter...
> > 
> > This should be engraved on a plaque somewhere. Only because I had almost th
> e
> > same thing happen to me, without the cat though. I had a printout of a
> > "mail" program I had written on TOPS-10 at high school. I had to retype the
> > entire thing after the file got corrupted.
>
> I think we have all been there.  Something always goes wrong.  I wrote 
> a paper about how to restore a Masscomp because I did rm -rf . in /.
> I believe we had roots home as / because /usr was a different partition.
> Clem, did Masscomp make roots home / or was that us?  Anyway, I did a
> cd something
> and somehow deleted the something and then did rm -rf .
> Much fun was had, I was up all night putting things back together.
> This was probably around 1984 or 1985, I was pretty green.

I may have mentioned restoring root directory using peek/poke
commands of a primitive boot loader.  Right before Comdex
(fall 1981) someone accidentally wiped out the root dir.  IIRC
we had just two systems that actually worked. The other person
was copying the floppy to the second system when something
went wrong.  The backup didn't work. And this was a Comdex
special filesystem (with demos for the show painstakingly put
together and no time to recreate it all from scratch). I
happened to remember inode & block numbers of the first few
things so I fixed up the root dir enough for the system to
come up & run fsck. Luckily very little was lost and we were
able to repair the demos and run them at Comdex!

From clemc at ccc.com  Tue Sep 17 11:58:40 2019
From: clemc at ccc.com (Clem cole)
Date: Mon, 16 Sep 2019 21:58:40 -0400
Subject: [TUHS] O'Reilly groff macros
In-Reply-To: <20190917014108.GF31311@eureka.lemis.com>
References: <CAC20D2OQD-NJaFsqsLVL_kqmCsSeUOKAr7dm71P4uN9N8m+AbQ@mail.gmail.com>
 <20190914020240.GO2046@mcvoy.com> <20190914024433.GA19193@minnie.tuhs.org>
 <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org>
 <CAC20D2M5j+pCBpxf4Cy-sK4BfBGj_RMhzSpGaXMZmeEaGV9cDA@mail.gmail.com>
 <069494b2-ec5b-91e7-8618-2d111e0e5aa2@andrewnesbit.org>
 <201909160620.x8G6KkJq026850@freefriends.org>
 <20190917001056.GD31311@eureka.lemis.com>
 <CAC20D2MNLumDDvQgXZ3nciNeaNaMATu=46AAY8P6zCoQnuhmRA@mail.gmail.com>
 <498796af-156b-65e0-374d-38afd95c0968@andrewnesbit.org>
 <20190917014108.GF31311@eureka.lemis.com>
Message-ID: <E1423E0D-DC2D-4229-9925-FE0187998F71@ccc.com>

If I was not clear, Janet’s document was for Masscomp.  But the a number of Ora folks all had it like Talbot, Dale, Tim and Cindy     

After the merger ( I had left by then as had Janet) a large number of Janet’s original team followed Tim and became his original core in Cambridge.  

Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. 

> On Sep 16, 2019, at 9:41 PM, Greg 'groggy' Lehey <grog at lemis.com> wrote:
> 
>> On Tuesday, 17 September 2019 at  1:54:21 +0100, U'll Be King of the Stars wrote:
>>> On 17/09/2019 01:51, Clem Cole wrote:
>>> FYI Which Dale and Tim used at Masscomp  4 years earlier.  That book was
>>> originally modeled from Janet Eagans style guide which I still have.
>> 
>> I LOVE style guides.  I have a bit of a thing for them.
>> 
>> Was the Eagans guide published?  (Andrew shuffles off to Amazon.)
> 
> I didn't get it when I signed up with O'Reilly.  Instead they pointed
> me at the Chicago Manual of Style, which got me interested in the idea
> of style as well.  It's fascinating how much the individual guides
> differ.
> 
> Greg
> --
> Sent from my desktop computer.
> Finger grog at lemis.com for PGP public key.
> See complete headers for address and phone numbers.
> This message is digitally signed.  If your Microsoft mail program
> reports problems, please read http://lemis.com/broken-MUA

From ggm at algebras.org  Tue Sep 17 12:02:49 2019
From: ggm at algebras.org (George Michaelson)
Date: Tue, 17 Sep 2019 12:02:49 +1000
Subject: [TUHS] block operations in editors, was My EuroBSDcon talk
In-Reply-To: <20190917004233.4cgn6vabnmgwl5q5@localhost.localdomain>
References: <201909170020.x8H0KWC6037690@tahoe.cs.Dartmouth.EDU>
 <20190917004233.4cgn6vabnmgwl5q5@localhost.localdomain>
Message-ID: <CAKr6gn36xPJ_XJY_yiJHfLu1L8bK3ozwp5sNnB9QFp+hZosqdw@mail.gmail.com>

I also went vim, wanting nvi to be there but Keith Bostic lost impetus
or motivation. I am not in love with vim, I still feel like its got a
lot of glitter, but with the keystrokes for homekeys burned into my
brain it was the best choice. I use ed periodically to remind myself
what reductionism in editors means. I used atom and visual basic,
they're ok for what they are.

Vim also gave me syntax colouring. again, I was suprised how quickly I
came to use it, having decried it. I guess like food, in matters of
(editor) taste there is no good disputation.

Sam didn't get into my frontal lobes quickly enough. I think if 8th
and plan9 had been only TWO years earlier out the door, a lot of the
world would look different. I look at kubernetes now, I live in it
actually, and I feel like inferno was leading me there but I got there
via very twisty paths.

Really, what I think UNIX missed the most, was the plumber. GTK and
KDE and the like dance around the problem of cut-paste between
processes in ways which I am led to believe the plumber fixed long
ago.  Another thing which had it been only two years earlier, might
have got us to a more cohered space.

"first, kill all the lawyers" is probably the subtitle of a UNIX book.
Counterfactuals.

-G

On Tue, Sep 17, 2019 at 10:42 AM G. Branden Robinson
<g.branden.robinson at gmail.com> wrote:
>
> At 2019-09-16T20:20:32-0400, Doug McIlroy wrote:
> > Ed imposes a structure, making a (finite) file into an array, aka
> > list, of lines. It's easy to define block moves and copies in a list.
> > But what are the semantics of a block move, wherein one treats the
> > list as a ragged-right 2D array? What gets pushed aside? In what
> > direction?  How does a block move into column that not all destination
> > rows reach? How do you cope when the bottom gets ragged? How about the
> > top? Can one move blocks of tab-separated fields?
> >
> > I think everyone has rued the lack of block operations at one time or
> > another. But implementing them in any degree of generality is a
> > stumbling block. What should the semantics be?
>
> Just in case anyone didn't know, Vim has what it calls "visual block"
> highlighting and operations.  CTRL-V begins one and you use the usual
> movement keys to shape and size it, then an operator like (y)ank or
> (d)elete.
>
> It won't always work as one expects because of the very questions that
> Doug raises above.
>
> Vim also has characterwise blocks (begin with 'v') and linewise blocks
> (begin with 'V').
>
> The last is, more than any other single factor, what pulled me over from
> traditional vi (really nvi in my case).  It was a big win over
> line-counting with ":.,+n" expressions.  In retrospect I should have
> been smarter and just typed ":.,/pattern/", using as /pattern/ some
> short string that did not appear in any of the lines I wanted to operate
> on.
>
> Though the vi clone with the best name was, indisputably, elvis.
>
> Regards,
> Branden

From lm at mcvoy.com  Tue Sep 17 12:34:52 2019
From: lm at mcvoy.com (Larry McVoy)
Date: Mon, 16 Sep 2019 19:34:52 -0700
Subject: [TUHS] wizards test [was roff]
In-Reply-To: <1583C418-2F6E-45D8-93C2-B93032E6CFFC@ccc.com>
References: <a29bfbe24692c1908f8a880041b816f6e9262baa@webmail.yaccman.com>
 <0bc0d10f-d17c-24df-2a7f-8f154eefd318@kilonet.net>
 <20190917011752.GY2046@mcvoy.com>
 <1583C418-2F6E-45D8-93C2-B93032E6CFFC@ccc.com>
Message-ID: <20190917023452.GB2046@mcvoy.com>

That was exactly the situation I had and I had a tough time so I wrote a
little paper about it.  Lemme see if I can find it.

Yep, found it.  It was when I was messing with roff -me.

http://mcvoy.com/lm/papers/restor.e
http://mcvoy.com/lm/papers/restor.pdf

I was apparently channeling creat(2) because it was too much work for 
me (or Ken) to add the trailing e.

I'm sort of impressed that I wrote that in 1985 because I got to undergrad
in 1980, I was an accounting major because my coach in high school was
my accounting teacher, you don't disappoint your coach so I did great at
accounting, got to college, no coach and accounting was *not* my thing,
wandered around for a year or so taking STEM classes, took some Art
History and declared that as a major, did that for 2 years (and got
really good at it, as in I have corrected errors in a textbook about
Greek pottery [1]) only to have my advisor tell me there are no jobs,
so I switched to computer science in 1984.  Going from nothing to being
a sys admin that had to do a full restore in a year or so is kinda neat.
But Unix was kinda neat and I was hooked, it's easy to get good when
you really like something (ask me about fly fishing :)

Doug, I still have the nroff/troff/tlb/eqn/pic (sadly no grap but I wrote
my own in pic later) printed out docs that I got from the UW-Madison
Computer Science department.  I used those to write that little memo.

[1] A little rant about art and how hard and how easy it can be.  You
guys know Picasso?  How about Piet Modrian?  Most people know both but
don't know that they know Piet.  They are very similar, Piet painted 
trees, here is one:

http://1.bp.blogspot.com/-KwU6EePgmxk/T8FixzAZxBI/AAAAAAAAB0s/xUKRQc23MNk/s1600/mondrian.jpg

Yep, that's a tree.  WTF you say?  So all great artist start out doing the
simple stuff.  Picasso, if you go back far enough, did still lifes of a
bowl of fruit.  Piet did essentially photographs of trees.  But then they
get weird, they get more abstract.  And more abstract.  To the point that
you look at that link above and you go "how is that a tree?  That's not a
tree".

You need to see their work in chronological order.  You see the stuff
that looks like a photograph and then it is a little different, a little
different, and you get to the end and you go wow, that actually is a tree.
It makes no sense if you just look at one after it gets abstract, it 
makes total sense if you see it order.

I had the good fortune to see an exhibit at New Yorks MOMA of Picasso
in chronological order.  Holy moly did that snap him into focus.

So that's a very long way of saying that it was easy for me to be good
at Greek pottery because I already knew that if you put someones work
in chronological order it would make sense.  The correction I did 
that I'm proud of is to Janson's history of art (which is the benchmark
for art history), there was a Greek artist who did a series of pots
and Janson had two pots backwards, the earlier one was the later one.
Janson was dead but the book carried on and they took my fix.

On Mon, Sep 16, 2019 at 09:36:40PM -0400, Clem cole wrote:
> Btw.  This was some I used as a wizards test. 
> 
> You have a working system next to a system that is still running so you have the console and its shell but had the rm -fr / done to it.  You have lost all of bin dev etc and lib by the time he hit ^C.   So you have some of /usr inc but much of /usr/bin is still there.    No compiler or assembler on the broken machine since that was in bin and lib.   
> 
> It???s possible to fix it using the other system to help.  Just don???t turn the damaged system off ????
> 
> Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. 
> 
> > On Sep 16, 2019, at 9:17 PM, Larry McVoy <lm at mcvoy.com> wrote:
> > 
> >> On Mon, Sep 16, 2019 at 09:11:17PM -0400, Arthur Krewat wrote:
> >>> On 9/16/2019 8:20 PM, Steve Johnson wrote:
> >>> One day I had been furiously editing a long program file for about an hour
> >>> and a half when I was called away to lunch, and, being hungry, didn't save
> >>> my file.?? When I got back to the terminal an hour later, I discovered two
> >>> things -- the system had crashed, and our cat had decided that the pile of
> >>> paper
> >>> on the floor made a great litter box.?? After a few choice words, I sighed
> >>> and picked up my highliter...
> >> 
> >> This should be engraved on a plaque somewhere. Only because I had almost the
> >> same thing happen to me, without the cat though. I had a printout of a
> >> "mail" program I had written on TOPS-10 at high school. I had to retype the
> >> entire thing after the file got corrupted.
> > 
> > I think we have all been there.  Something always goes wrong.  I wrote 
> > a paper about how to restore a Masscomp because I did rm -rf . in /.
> > I believe we had roots home as / because /usr was a different partition.
> > Clem, did Masscomp make roots home / or was that us?  Anyway, I did a
> > cd something
> > and somehow deleted the something and then did rm -rf .
> > Much fun was had, I was up all night putting things back together.
> > This was probably around 1984 or 1985, I was pretty green.

-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 

From athornton at gmail.com  Tue Sep 17 12:51:30 2019
From: athornton at gmail.com (Adam Thornton)
Date: Mon, 16 Sep 2019 19:51:30 -0700
Subject: [TUHS] PiDP-11 in action!
Message-ID: <CAP2nic11x4sXEAdUJDeg_m_qs6bo41vnopgA_yGPkqcvEvSVSw@mail.gmail.com>

https://share.icloud.com/photos/0MKJjk8pRBvkZAEzaobjfOyPQ

I start v7 Unix and play "Hunt The Wumpus".

(I finally got it put together this weekend, and fixed the last couple
dodgy joints tonight).

Adam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190916/6684eaf4/attachment.html>

From lm at mcvoy.com  Tue Sep 17 13:06:36 2019
From: lm at mcvoy.com (Larry McVoy)
Date: Mon, 16 Sep 2019 20:06:36 -0700
Subject: [TUHS] PiDP-11 in action!
In-Reply-To: <CAP2nic11x4sXEAdUJDeg_m_qs6bo41vnopgA_yGPkqcvEvSVSw@mail.gmail.com>
References: <CAP2nic11x4sXEAdUJDeg_m_qs6bo41vnopgA_yGPkqcvEvSVSw@mail.gmail.com>
Message-ID: <20190917030636.GE2046@mcvoy.com>

Go you.  PDP-11 will always be my favorite assembler, there is an octal
dump for a reason and that reason is the PDP-11.  Or maybe PDPs in 
general.  I had a TA in Uni that could read octal like it was PDP
assembler.

On Mon, Sep 16, 2019 at 07:51:30PM -0700, Adam Thornton wrote:
> https://share.icloud.com/photos/0MKJjk8pRBvkZAEzaobjfOyPQ
> 
> I start v7 Unix and play "Hunt The Wumpus".
> 
> (I finally got it put together this weekend, and fixed the last couple
> dodgy joints tonight).
> 
> Adam

-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 

From blstuart at bellsouth.net  Tue Sep 17 13:19:32 2019
From: blstuart at bellsouth.net (Brian L. Stuart)
Date: Tue, 17 Sep 2019 03:19:32 +0000 (UTC)
Subject: [TUHS] PiDP-11 in action!
In-Reply-To: <CAP2nic11x4sXEAdUJDeg_m_qs6bo41vnopgA_yGPkqcvEvSVSw@mail.gmail.com>
References: <CAP2nic11x4sXEAdUJDeg_m_qs6bo41vnopgA_yGPkqcvEvSVSw@mail.gmail.com>
Message-ID: <1847226767.5590783.1568690372673@mail.yahoo.com>

 On Monday, September 16, 2019, 10:51:59 PM EDT, Adam Thornton <athornton at gmail.com> wrote:
> I start v7 Unix and play "Hunt The Wumpus".
>
> (I finally got it put together this weekend, and fixed the last couple dodgy joints tonight).
>
> Adam

Congrats.

Those are so much fun. I had mine running 6th Ed
at the Vintage Computer Festival Southeast last
spring in Atlanta.

A serious blast from the past.
BLS
  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190917/28a21999/attachment.html>

From lars at nocrew.org  Tue Sep 17 15:07:33 2019
From: lars at nocrew.org (Lars Brinkhoff)
Date: Tue, 17 Sep 2019 05:07:33 +0000
Subject: [TUHS] earliest Unix roff
In-Reply-To: <20190916215917.GX2046@mcvoy.com> (Larry McVoy's message of "Mon, 
 16 Sep 2019 14:59:17 -0700")
References: <20190914020240.GO2046@mcvoy.com>
 <20190914024433.GA19193@minnie.tuhs.org>
 <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org>
 <201909150654.x8F6sChG021185@freefriends.org>
 <CAC20D2PfLq=J5ei+izXb2J7dSvU6=L6-GRd0gKA2ShSNg1=qBg@mail.gmail.com>
 <201909160552.x8G5qBYK025195@freefriends.org>
 <CAC20D2N89jOBK+T9EPn8JKNaSOUx=yDr9t4=CcyHM+3qnB2bEg@mail.gmail.com>
 <alpine.BSF.2.21.9999.1909170739260.18105@aneurin.horsfall.org>
 <20190916214832.GW2046@mcvoy.com>
 <201909162154.x8GLsnOs011718@darkstar.fourwinds.com>
 <20190916215917.GX2046@mcvoy.com>
Message-ID: <7wblvjmrxm.fsf@junk.nocrew.org>

Larry McVoy wrote:
> My comment on the info stuff was just my understand of why it came to be.

Probably no one knows any more.

Quick history recap:

- First there was the old plain text INFO which was more like Unix' man.
- Then there was the new hypertext INFO built on EMACS.
- GNU info copied ITS' INFO.

When I ask ITS people about this old plain text INFO, they don't even
remember it.

I think it's reasonable to assume they thought the new hypertext format
with links was more intriguing technology than plain text files.

From lars at nocrew.org  Tue Sep 17 15:21:06 2019
From: lars at nocrew.org (Lars Brinkhoff)
Date: Tue, 17 Sep 2019 05:21:06 +0000
Subject: [TUHS] [tuhs] Computer history preservation
In-Reply-To: <CMM.0.95.0.1568670516.beebe@gamma.math.utah.edu> (Nelson
 H. F. Beebe's message of "Mon, 16 Sep 2019 15:48:36 -0600")
References: <CMM.0.95.0.1568670516.beebe@gamma.math.utah.edu>
Message-ID: <7w7e67mrb1.fsf@junk.nocrew.org>

"Nelson H. F. Beebe" <beebe at math.utah.edu> writes:
> I came across an article today about another major industry that has
> been exceedingly careless about preserving its history

It's an extenssion of the hype cycle.  It starts like this:

1. Technology Trigger
2. Peak of Inflated Expectations
3. Trough of Disillusionment
4. Slope of Enlightenment
5. Plateau of Productivity

What is usually not pictured is the rest of the curve:

6. Dip of Sunset Technology.
7. Valley of Obsolete Stuff.
8. Throwing Away of Old Junk.
9. Resurge of Nostalgia.
10. Frantic Search on Ebay.
11. The Even Higher Peak of Collector's Holy Grail.

From emu at e-bbes.com  Tue Sep 17 16:01:15 2019
From: emu at e-bbes.com (emanuel stiebler)
Date: Tue, 17 Sep 2019 08:01:15 +0200
Subject: [TUHS] PiDP-11 in action!
In-Reply-To: <CAP2nic11x4sXEAdUJDeg_m_qs6bo41vnopgA_yGPkqcvEvSVSw@mail.gmail.com>
References: <CAP2nic11x4sXEAdUJDeg_m_qs6bo41vnopgA_yGPkqcvEvSVSw@mail.gmail.com>
Message-ID: <d7450e08-7897-a614-ce21-73948659a09e@e-bbes.com>

On 2019-09-17 04:51, Adam Thornton wrote:
> https://share.icloud.com/photos/0MKJjk8pRBvkZAEzaobjfOyPQ
> 
> I start v7 Unix and play "Hunt The Wumpus".
> 
> (I finally got it put together this weekend, and fixed the last couple
> dodgy joints tonight).

IBM keyboard on a vt520?

From usotsuki at buric.co  Tue Sep 17 17:46:15 2019
From: usotsuki at buric.co (Steve Nickolas)
Date: Tue, 17 Sep 2019 03:46:15 -0400 (EDT)
Subject: [TUHS] [tuhs] Computer history preservation
In-Reply-To: <20190917002825.GA15016@server.rulingia.com>
References: <CMM.0.95.0.1568670516.beebe@gamma.math.utah.edu>
 <20190917002825.GA15016@server.rulingia.com>
Message-ID: <alpine.BSF.2.02.1909170336190.71302@frieza.hoshinet.org>

On Tue, 17 Sep 2019, Peter Jeremy wrote:

> On 2019-Sep-16 15:48:36 -0600, "Nelson H. F. Beebe" <beebe at math.utah.edu> wrote:
>> I came across an article today about another major industry that has
>> been exceedingly careless about preserving its history:
>>
>>        Wipe Out: When the BBC Kept Erasing Its Own History
>>        https://getpocket.com/explore/item/wipe-out-when-the-bbc-kept-erasing-its-own-history
>>
>> It is a must-read for Dr Who fans on this list.
>
> It didn't only affect TV, much of The Goons originals were also destroyed (at least
> one episode now sold by the BBC is an off-air recording by a fan because that's the
> best extant copy).
>
> And NASA destroyed the tapes holding the original Apollo 11 moonwalk
> (https://en.wikipedia.org/wiki/Apollo_11_missing_tapes).

Toei Animation wiped the audio masters for Dragon Ball and Dragon Ball Z. 
What remains is low-quality optical audio from film prints.  (They did the 
same for Dragon Ball GT but some TV stations managed to preserve the 
audio, so it's not as much of a problem as it is for the previous series.)

-uso.

From arnold at skeeve.com  Tue Sep 17 17:53:07 2019
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Tue, 17 Sep 2019 01:53:07 -0600
Subject: [TUHS] earliest Unix roff
In-Reply-To: <20190916145122.GH2046@mcvoy.com>
References: <CAC20D2Nz-ofwD41vULF2-TL8-C33heCiHvoNNbcuj6GGKhtKzQ@mail.gmail.com>
 <20190913221345.GA16129@minnie.tuhs.org>
 <CAC20D2OQD-NJaFsqsLVL_kqmCsSeUOKAr7dm71P4uN9N8m+AbQ@mail.gmail.com>
 <20190914020240.GO2046@mcvoy.com>
 <20190914024433.GA19193@minnie.tuhs.org>
 <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org>
 <201909150654.x8F6sChG021185@freefriends.org>
 <CAC20D2PfLq=J5ei+izXb2J7dSvU6=L6-GRd0gKA2ShSNg1=qBg@mail.gmail.com>
 <201909160552.x8G5qBYK025195@freefriends.org>
 <CAC20D2N89jOBK+T9EPn8JKNaSOUx=yDr9t4=CcyHM+3qnB2bEg@mail.gmail.com>
 <20190916145122.GH2046@mcvoy.com>
Message-ID: <201909170753.x8H7r8oT004491@freefriends.org>

It is like clockwork.

Whenever I say something about Texinfo *as a markup language* for use
in *writing books*, the discussion inevitably degenerates into a hate
rant against Info and RMS's (failed) attempt to replace man pages.
Totally missing the point too.

This is a trend on TUHS.  The same discussions, the same rants, often
the same misinformation, over and over and over again.

I start to wonder if I should continue to subscribe.

Arnold

Larry McVoy <lm at mcvoy.com> wrote:

> On Mon, Sep 16, 2019 at 08:10:48AM -0400, Clem Cole wrote:
> > On Mon, Sep 16, 2019 at 1:52 AM <arnold at skeeve.com> wrote:
> > 
> > > I use the standalone Info reader (named info) if I want to look at the
> > > Info output.
> > >
> > Fair enough, but be careful, while I admit I have not looked in a while,
> > info(gnu) relies on emacs keybindings and a number of very emacs'ish things.
> > Every time I have tried to deal with it, I have unprogram my fingers and
> > reset them to emacs.
> > 
> > If it would have used more(1) [or even less(1)] then I would not be as
> > annoyed.
> > Unix had fine tools [man(1), more(1), et al] and rms and friends felt the
> > need to replace them with ITS-like programs.
>
> I hate texinfo and friends.  I get why it is better than man, but man was
> good enough, more than good enough, and the GNU project took everything
> it could find and destroyed the man pages.
>
> If you have something like perl that needs a zillion sub pages, info
> makes sense.  For just a man page, info is horrible.

From wkt at tuhs.org  Tue Sep 17 19:54:35 2019
From: wkt at tuhs.org (Warren Toomey)
Date: Tue, 17 Sep 2019 19:54:35 +1000
Subject: [TUHS] A Couple of New Unix Artifacts
Message-ID: <20190917095435.GA16333@minnie.tuhs.org>

I fear we're drifting a bit here and the S/N ratio is dropping a bit w.r.t
the actual history of Unix. Please no more on the relative merits of
version control systems or alternative text processing systems.

So I'll try to distract you by saying this. I'm sitting on two artifacts
that have recently been given to me:

 + by two large organisations
 + of great significance to Unix history
 + who want me to keep "mum" about them
 + as they are going to make announcements about them soon *

and I am going slowly crazy as I wait for them to be offically released.

Now you have a new topic to talk about :-)

Cheers, Warren

* for some definition of "soon"

From spedraja at gmail.com  Tue Sep 17 19:58:51 2019
From: spedraja at gmail.com (SPC)
Date: Tue, 17 Sep 2019 11:58:51 +0200
Subject: [TUHS] A Couple of New Unix Artifacts
In-Reply-To: <20190917095435.GA16333@minnie.tuhs.org>
References: <20190917095435.GA16333@minnie.tuhs.org>
Message-ID: <CACytpF-XQUrDYqcr6MpZqwMjSymNoHPGLvYGOfQ4k66rZkkXzA@mail.gmail.com>

Agreed. And of course you have completely caught my attention about this...
8-)

Cordiales saludos / Kind Regards.

Gracias | Regards - Saludos | Greetings | Freundliche Grüße | Salutations
-- 
*Sergio Pedraja*
-- 
http://www.linkedin.com/in/sergiopedraja
-----


El mar., 17 sept. 2019 a las 11:55, Warren Toomey (<wkt at tuhs.org>) escribió:

> I fear we're drifting a bit here and the S/N ratio is dropping a bit w.r.t
> the actual history of Unix. Please no more on the relative merits of
> version control systems or alternative text processing systems.
>
> So I'll try to distract you by saying this. I'm sitting on two artifacts
> that have recently been given to me:
>
>  + by two large organisations
>  + of great significance to Unix history
>  + who want me to keep "mum" about them
>  + as they are going to make announcements about them soon *
>
> and I am going slowly crazy as I wait for them to be offically released.
>
> Now you have a new topic to talk about :-)
>
> Cheers, Warren
>
> * for some definition of "soon"
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190917/f153979e/attachment.html>

From aap at papnet.eu  Tue Sep 17 20:45:18 2019
From: aap at papnet.eu (Angelo Papenhoff)
Date: Tue, 17 Sep 2019 12:45:18 +0200
Subject: [TUHS] A Couple of New Unix Artifacts
In-Reply-To: <20190917095435.GA16333@minnie.tuhs.org>
References: <20190917095435.GA16333@minnie.tuhs.org>
Message-ID: <20190917104518.GA96058@indra.papnet.eu>

On 17/09/19, Warren Toomey wrote:
> I fear we're drifting a bit here and the S/N ratio is dropping a bit w.r.t
> the actual history of Unix. Please no more on the relative merits of
> version control systems or alternative text processing systems.
> 
> So I'll try to distract you by saying this. I'm sitting on two artifacts
> that have recently been given to me:
> 
>  + by two large organisations
>  + of great significance to Unix history
>  + who want me to keep "mum" about them
>  + as they are going to make announcements about them soon *
> 
> and I am going slowly crazy as I wait for them to be offically released.
> 
> Now you have a new topic to talk about :-)

That sounds exciting!

I wish we had more stuff of the v0-v4 era, but I don't know how
likely that is to even still exist.
Also the things that were documented in the manual but weren't in the
distribution...old troff is something that comes to mind. We still have
the source filenames in deleted directory entries in the v6 distribution.

From thomas.paulsen at firemail.de  Tue Sep 17 21:12:54 2019
From: thomas.paulsen at firemail.de (Thomas Paulsen)
Date: Tue, 17 Sep 2019 13:12:54 +0200
Subject: [TUHS] earliest Unix roff
In-Reply-To: <fb60a87c-a274-104c-38e3-8fcf63f02c12@gmail.com>
References: <20190914024433.GA19193@minnie.tuhs.org>
 <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org>
 <201909150654.x8F6sChG021185@freefriends.org>
 <CAC20D2PfLq=J5ei+izXb2J7dSvU6=L6-GRd0gKA2ShSNg1=qBg@mail.gmail.com>
 <201909160552.x8G5qBYK025195@freefriends.org>
 <CAC20D2N89jOBK+T9EPn8JKNaSOUx=yDr9t4=CcyHM+3qnB2bEg@mail.gmail.com>
 <7wd0g0o2a0.fsf@junk.nocrew.org>
 <CAC20D2MBHSddOkjPUvat3GeF14-+oa2rMoppgFChzqOX+eUYpQ@mail.gmail.com>
 <alpine.BSF.2.21.9999.1909170804040.18105@aneurin.horsfall.org>
 <fb60a87c-a274-104c-38e3-8fcf63f02c12@gmail.com>
Message-ID: <00285de87973bc46c5249bfdedac6bd0@firemail.de>



Nemo Nusquam wrote:
> On 09/16/19 18:05, Dave Horsfall wrote:
> > Am I the only one who remembers the old "pg" program? It seems
> to have disappeared.
>
> Still ships with Solaris (in /usr/bin).
the sources can be found at Jorg Schillings sourceforge site.



From thomas.paulsen at firemail.de  Tue Sep 17 21:20:15 2019
From: thomas.paulsen at firemail.de (Thomas Paulsen)
Date: Tue, 17 Sep 2019 13:20:15 +0200
Subject: [TUHS] earliest Unix roff
In-Reply-To: <20190916161040.GM2046@mcvoy.com>
References: <20190914024433.GA19193@minnie.tuhs.org>
 <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org>
 <201909150654.x8F6sChG021185@freefriends.org>
 <CAC20D2PfLq=J5ei+izXb2J7dSvU6=L6-GRd0gKA2ShSNg1=qBg@mail.gmail.com>
 <201909160552.x8G5qBYK025195@freefriends.org>
 <CAC20D2N89jOBK+T9EPn8JKNaSOUx=yDr9t4=CcyHM+3qnB2bEg@mail.gmail.com>
 <20190916145122.GH2046@mcvoy.com>
 <CAC20D2Nwe=AycD+QywLPaRC8HCT5_U09KBeoV3+G6d9+Avidmw@mail.gmail.com>
 <CAFH29tpP6joyHDAQTKj41bwAscqa0HO8g7EKwxXv3Vbscqc58A@mail.gmail.com>
 <20190916161040.GM2046@mcvoy.com>
Message-ID: <3f48679ee3ee432e47c1fba9d70da37a@firemail.de>


 Larry McVoy <lm at mcvoy.com> wrote:
>
> It's what Clem said.  You should acclimate yourself to your environment.
> Pushing info into man environment is a lot like being an immigrant and
> wanting to bring your laws into your new homeland.  That isn't a thing
> and shouldn't be a thing.  Doesn't matter that people think ITS is better,
> they are in Unix.  If you think ITS is better, go live there.
> When in Rome....
>
info failed (as well as texinfo). Hardly anybody using it, beside notorious emacs maniacs like me.  Rome doesn't like it.



From thomas.paulsen at firemail.de  Tue Sep 17 21:01:47 2019
From: thomas.paulsen at firemail.de (Thomas Paulsen)
Date: Tue, 17 Sep 2019 13:01:47 +0200
Subject: [TUHS] block operations in editors, was  My EuroBSDcon talk
In-Reply-To: <20190917004233.4cgn6vabnmgwl5q5@localhost.localdomain>
References: <201909170020.x8H0KWC6037690@tahoe.cs.Dartmouth.EDU>
 <20190917004233.4cgn6vabnmgwl5q5@localhost.localdomain>
Message-ID: <5eeb9c1609d2324672ecae9538f3f880@firemail.de>


---------------------------------
>
> Though the vi clone with the best name was, indisputably, elvis.
>
unfortunately unmaintained.
elvis has a smaller memory footprint, and a more pleasant (nroff later html) based help support than vim. There are no plugin, vimscript feature sas well as no python/perl support. I'm interested in a vi with syntax coloring and help support, however I don't need scripting features. Therefore I hope someone will take over maintenance, as I'm too old for that.



From thomas.paulsen at firemail.de  Tue Sep 17 21:34:05 2019
From: thomas.paulsen at firemail.de (Thomas Paulsen)
Date: Tue, 17 Sep 2019 13:34:05 +0200
Subject: [TUHS] block operations in editors, was My EuroBSDcon talk
Message-ID: <c5b6170c342996b6161a24a9c95a68b3@firemail.de>

---------------------------------
>
> Though the vi clone with the best name was, indisputably, elvis.
>
unfortunately unmaintained.
elvis has a smaller memory footprint, and a more pleasant (nroff later html) based help support than vim. There are no plugin, vimscript feature sas well as no python/perl support. I'm interested in a vi with syntax coloring and help support, however I don't need scripting features. Therefore I hope someone will take over maintenance, as I'm too old for tha



From tytso at mit.edu  Tue Sep 17 21:46:02 2019
From: tytso at mit.edu (Theodore Y. Ts'o)
Date: Tue, 17 Sep 2019 07:46:02 -0400
Subject: [TUHS] INed/Rand Editor/Ned [was Re: My EuroBSDcon talk
 (preview for commentary)
In-Reply-To: <20190916202153.wbpzx3jn3a7rs6kb@localhost.localdomain>
References: <CAC20D2Nq+eTQDdft5nW8kKcWFdt9ZK4-5kJX6OcMcYBffk9HGA@mail.gmail.com>
 <20190915232524.9A5491570CE9@mail.bitblocks.com>
 <CANCZdfr83yx7eUu-t+j-D8z9TMSkuAvPpb81hJdk95070gmZcA@mail.gmail.com>
 <7F62BF6B-8FEA-4C43-9E35-05BDE9BF04EA@ccc.com>
 <CAKr6gn3dKiFCr3D4sYv1+xJbD4cHq5X6AFEtz8MF7NtKdnY6dw@mail.gmail.com>
 <20190916023738.F34E81570CE9@mail.bitblocks.com>
 <B2C11377-D557-4542-94D9-31E3D9C789D6@technologists.com>
 <CAC20D2MfPCf7Dqke_U=Bod+WeZnvpszrgo7TwpeJB5G3CsG+oA@mail.gmail.com>
 <CANCZdfoL2JGwhE1kn3sckUrREKq=v9+6oLm1H8gAf446y87SQg@mail.gmail.com>
 <20190916202153.wbpzx3jn3a7rs6kb@localhost.localdomain>
Message-ID: <20190917114602.GB6762@mit.edu>

On Tue, Sep 17, 2019 at 06:21:56AM +1000, G. Branden Robinson wrote:
> It's still common today.  Everything the developer cares to think about,
> let alone test on, interprets EMCA-48 SGR escape sequences.  My favorite
> recent example is "spectre-meltdown-checker", which has such edifying
> lines as:
> 
>         _info_nol "> \033[46m\033[30mSTATUS:\033[0m "
> 
> Why write something portable when you can be "close to the metal"?  :-/

To be fair, spectre-multdown-checker is a shell script, and while you
can use tput, that's not super-portable (some versions take termcap
names, some take terminfo names, and the only thing that has been
standardized is "init", "clear", and "reset"), and said script was
designed to work on Linux and *BSD systems.

					- Ted

From david at kdbarto.org  Tue Sep 17 22:20:00 2019
From: david at kdbarto.org (David)
Date: Tue, 17 Sep 2019 05:20:00 -0700
Subject: [TUHS] earliest Unix roff
In-Reply-To: <20190917001655.GE31311@eureka.lemis.com>
References: <20190913221345.GA16129@minnie.tuhs.org>
 <CAC20D2OQD-NJaFsqsLVL_kqmCsSeUOKAr7dm71P4uN9N8m+AbQ@mail.gmail.com>
 <20190914020240.GO2046@mcvoy.com> <20190914024433.GA19193@minnie.tuhs.org>
 <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org>
 <201909150654.x8F6sChG021185@freefriends.org>
 <CAC20D2PfLq=J5ei+izXb2J7dSvU6=L6-GRd0gKA2ShSNg1=qBg@mail.gmail.com>
 <201909160552.x8G5qBYK025195@freefriends.org>
 <CAC20D2N89jOBK+T9EPn8JKNaSOUx=yDr9t4=CcyHM+3qnB2bEg@mail.gmail.com>
 <alpine.BSF.2.21.9999.1909170739260.18105@aneurin.horsfall.org>
 <20190917001655.GE31311@eureka.lemis.com>
Message-ID: <E47B9A8F-D5C2-4C7C-9F52-B445B9C84DDC@kdbarto.org>


> On Sep 16, 2019, at 5:16 PM, Greg 'groggy' Lehey <grog at lemis.com> wrote:
> 
> For an extreme case of man pages, look at something like mplayer(1) or
> mpv(1):
> 
>  $ man mplayer|wc -l
>     9435
>  $ man mpv|wc -l
>     13939
> 
Those aren’t man pages, they are novellas.

	David


From g.branden.robinson at gmail.com  Tue Sep 17 22:52:24 2019
From: g.branden.robinson at gmail.com (G. Branden Robinson)
Date: Tue, 17 Sep 2019 22:52:24 +1000
Subject: [TUHS] INed/Rand Editor/Ned [was Re: My EuroBSDcon talk
 (preview for commentary)
In-Reply-To: <20190917114602.GB6762@mit.edu>
References: <20190915232524.9A5491570CE9@mail.bitblocks.com>
 <CANCZdfr83yx7eUu-t+j-D8z9TMSkuAvPpb81hJdk95070gmZcA@mail.gmail.com>
 <7F62BF6B-8FEA-4C43-9E35-05BDE9BF04EA@ccc.com>
 <CAKr6gn3dKiFCr3D4sYv1+xJbD4cHq5X6AFEtz8MF7NtKdnY6dw@mail.gmail.com>
 <20190916023738.F34E81570CE9@mail.bitblocks.com>
 <B2C11377-D557-4542-94D9-31E3D9C789D6@technologists.com>
 <CAC20D2MfPCf7Dqke_U=Bod+WeZnvpszrgo7TwpeJB5G3CsG+oA@mail.gmail.com>
 <CANCZdfoL2JGwhE1kn3sckUrREKq=v9+6oLm1H8gAf446y87SQg@mail.gmail.com>
 <20190916202153.wbpzx3jn3a7rs6kb@localhost.localdomain>
 <20190917114602.GB6762@mit.edu>
Message-ID: <20190917125222.zpavtknp7f6v2hhx@localhost.localdomain>

At 2019-09-17T07:46:02-0400, Theodore Y. Ts'o wrote:
> To be fair, spectre-multdown-checker is a shell script, and while you
> can use tput, that's not super-portable (some versions take termcap
> names, some take terminfo names, and the only thing that has been
> standardized is "init", "clear", and "reset"),

Now that you mention it I do remember Thomas Dickey saying that at some
point.

> and said script was designed to work on Linux and *BSD systems.

In that case I'd query tput through a function that got defined
differently based on the output of uname, or tput's own version string
output if it could be coaxed into giving me one (Dickey's ncurses tput
supports -V for this purpose; I don't know about the BSDs).

The thrust is to get that egregious noise out of the output strings as
written in the source file so as to preserve their human-readability.

Better this:
	echo "${fg_black}${bg_cyan}STATUS:${normal}"
Than:
	echo "\033[30m\033[43mSTATUS\033[m"

...in which am I more likely to notice typos?  Given an editor that
lexically analyzes your shell script[1], which is more likely to
integrate well with a spell-checker?

Regards,
Branden

[1] Okay, so that turns out to be nearly impossible, at least if you
want to recognize every possible construct[2].

[2] https://hal.archives-ouvertes.fr/hal-01890044/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190917/a3553ca4/attachment.sig>

From clemc at ccc.com  Wed Sep 18 00:21:20 2019
From: clemc at ccc.com (Clem Cole)
Date: Tue, 17 Sep 2019 10:21:20 -0400
Subject: [TUHS] earliest Unix roff
In-Reply-To: <201909170753.x8H7r8oT004491@freefriends.org>
References: <CAC20D2Nz-ofwD41vULF2-TL8-C33heCiHvoNNbcuj6GGKhtKzQ@mail.gmail.com>
 <20190913221345.GA16129@minnie.tuhs.org>
 <CAC20D2OQD-NJaFsqsLVL_kqmCsSeUOKAr7dm71P4uN9N8m+AbQ@mail.gmail.com>
 <20190914020240.GO2046@mcvoy.com> <20190914024433.GA19193@minnie.tuhs.org>
 <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org>
 <201909150654.x8F6sChG021185@freefriends.org>
 <CAC20D2PfLq=J5ei+izXb2J7dSvU6=L6-GRd0gKA2ShSNg1=qBg@mail.gmail.com>
 <201909160552.x8G5qBYK025195@freefriends.org>
 <CAC20D2N89jOBK+T9EPn8JKNaSOUx=yDr9t4=CcyHM+3qnB2bEg@mail.gmail.com>
 <20190916145122.GH2046@mcvoy.com>
 <201909170753.x8H7r8oT004491@freefriends.org>
Message-ID: <CAC20D2MZiv71YBs48bZOdXEiNw35JX36tGc_=ZmR8foNxpmJyQ@mail.gmail.com>

Fair enough.  Mei culpa from one of those that was vocal.  That said, maybe
a trick is to stay away from texinfo/info and the man page discussion on
this list since its a hot button that causes much trama for some with a
more traditional UNIX view.

Please don't leave, your voice is important and I generally agree with you
and always like to hear you out.  But even if I do not agree, I still want
to listen.  You have come to your conclusions in a different manner than
some of us, and where each of us puts the MSB tends to color our views.
Diversity of opinion is a good thing.

Respectfully,
Clem
ᐧ

On Tue, Sep 17, 2019 at 3:53 AM <arnold at skeeve.com> wrote:

> It is like clockwork.
>
> Whenever I say something about Texinfo *as a markup language* for use
> in *writing books*, the discussion inevitably degenerates into a hate
> rant against Info and RMS's (failed) attempt to replace man pages.
> Totally missing the point too.
>
> This is a trend on TUHS.  The same discussions, the same rants, often
> the same misinformation, over and over and over again.
>
> I start to wonder if I should continue to subscribe.
>
> Arnold
>
> Larry McVoy <lm at mcvoy.com> wrote:
>
> > On Mon, Sep 16, 2019 at 08:10:48AM -0400, Clem Cole wrote:
> > > On Mon, Sep 16, 2019 at 1:52 AM <arnold at skeeve.com> wrote:
> > >
> > > > I use the standalone Info reader (named info) if I want to look at
> the
> > > > Info output.
> > > >
> > > Fair enough, but be careful, while I admit I have not looked in a
> while,
> > > info(gnu) relies on emacs keybindings and a number of very emacs'ish
> things.
> > > Every time I have tried to deal with it, I have unprogram my fingers
> and
> > > reset them to emacs.
> > >
> > > If it would have used more(1) [or even less(1)] then I would not be as
> > > annoyed.
> > > Unix had fine tools [man(1), more(1), et al] and rms and friends felt
> the
> > > need to replace them with ITS-like programs.
> >
> > I hate texinfo and friends.  I get why it is better than man, but man was
> > good enough, more than good enough, and the GNU project took everything
> > it could find and destroyed the man pages.
> >
> > If you have something like perl that needs a zillion sub pages, info
> > makes sense.  For just a man page, info is horrible.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190917/4962716b/attachment.html>

From clemc at ccc.com  Wed Sep 18 00:28:20 2019
From: clemc at ccc.com (Clem Cole)
Date: Tue, 17 Sep 2019 10:28:20 -0400
Subject: [TUHS] PiDP-11 in action!
In-Reply-To: <CAP2nic11x4sXEAdUJDeg_m_qs6bo41vnopgA_yGPkqcvEvSVSw@mail.gmail.com>
References: <CAP2nic11x4sXEAdUJDeg_m_qs6bo41vnopgA_yGPkqcvEvSVSw@mail.gmail.com>
Message-ID: <CAC20D2Nzp-JoOC1qEQg4-b-K-uCuNwYKhqyvsAguZ4SQg-fSbg@mail.gmail.com>

+1
ᐧ

On Mon, Sep 16, 2019 at 10:52 PM Adam Thornton <athornton at gmail.com> wrote:

> https://share.icloud.com/photos/0MKJjk8pRBvkZAEzaobjfOyPQ
>
> I start v7 Unix and play "Hunt The Wumpus".
>
> (I finally got it put together this weekend, and fixed the last couple
> dodgy joints tonight).
>
> Adam
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190917/86ae6535/attachment.html>

From arnold at skeeve.com  Wed Sep 18 01:03:41 2019
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Tue, 17 Sep 2019 09:03:41 -0600
Subject: [TUHS] earliest Unix roff
In-Reply-To: <CAC20D2MZiv71YBs48bZOdXEiNw35JX36tGc_=ZmR8foNxpmJyQ@mail.gmail.com>
References: <CAC20D2Nz-ofwD41vULF2-TL8-C33heCiHvoNNbcuj6GGKhtKzQ@mail.gmail.com>
 <20190913221345.GA16129@minnie.tuhs.org>
 <CAC20D2OQD-NJaFsqsLVL_kqmCsSeUOKAr7dm71P4uN9N8m+AbQ@mail.gmail.com>
 <20190914020240.GO2046@mcvoy.com>
 <20190914024433.GA19193@minnie.tuhs.org>
 <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org>
 <201909150654.x8F6sChG021185@freefriends.org>
 <CAC20D2PfLq=J5ei+izXb2J7dSvU6=L6-GRd0gKA2ShSNg1=qBg@mail.gmail.com>
 <201909160552.x8G5qBYK025195@freefriends.org>
 <CAC20D2N89jOBK+T9EPn8JKNaSOUx=yDr9t4=CcyHM+3qnB2bEg@mail.gmail.com>
 <20190916145122.GH2046@mcvoy.com>
 <201909170753.x8H7r8oT004491@freefriends.org>
 <CAC20D2MZiv71YBs48bZOdXEiNw35JX36tGc_=ZmR8foNxpmJyQ@mail.gmail.com>
Message-ID: <201909171503.x8HF3fRX016265@freefriends.org>

Yes, I think the next time anyone says anything about markup languages,
I'll just use private mail.

Thanks,

Arnold

Clem Cole <clemc at ccc.com> wrote:

> Fair enough.  Mei culpa from one of those that was vocal.  That said, maybe
> a trick is to stay away from texinfo/info and the man page discussion on
> this list since its a hot button that causes much trama for some with a
> more traditional UNIX view.
>
> Please don't leave, your voice is important and I generally agree with you
> and always like to hear you out.  But even if I do not agree, I still want
> to listen.  You have come to your conclusions in a different manner than
> some of us, and where each of us puts the MSB tends to color our views.
> Diversity of opinion is a good thing.
>
> Respectfully,
> Clem
> ᐧ
>
> On Tue, Sep 17, 2019 at 3:53 AM <arnold at skeeve.com> wrote:
>
> > It is like clockwork.
> >
> > Whenever I say something about Texinfo *as a markup language* for use
> > in *writing books*, the discussion inevitably degenerates into a hate
> > rant against Info and RMS's (failed) attempt to replace man pages.
> > Totally missing the point too.
> >
> > This is a trend on TUHS.  The same discussions, the same rants, often
> > the same misinformation, over and over and over again.
> >
> > I start to wonder if I should continue to subscribe.
> >
> > Arnold
> >
> > Larry McVoy <lm at mcvoy.com> wrote:
> >
> > > On Mon, Sep 16, 2019 at 08:10:48AM -0400, Clem Cole wrote:
> > > > On Mon, Sep 16, 2019 at 1:52 AM <arnold at skeeve.com> wrote:
> > > >
> > > > > I use the standalone Info reader (named info) if I want to look at
> > the
> > > > > Info output.
> > > > >
> > > > Fair enough, but be careful, while I admit I have not looked in a
> > while,
> > > > info(gnu) relies on emacs keybindings and a number of very emacs'ish
> > things.
> > > > Every time I have tried to deal with it, I have unprogram my fingers
> > and
> > > > reset them to emacs.
> > > >
> > > > If it would have used more(1) [or even less(1)] then I would not be as
> > > > annoyed.
> > > > Unix had fine tools [man(1), more(1), et al] and rms and friends felt
> > the
> > > > need to replace them with ITS-like programs.
> > >
> > > I hate texinfo and friends.  I get why it is better than man, but man was
> > > good enough, more than good enough, and the GNU project took everything
> > > it could find and destroyed the man pages.
> > >
> > > If you have something like perl that needs a zillion sub pages, info
> > > makes sense.  For just a man page, info is horrible.
> >

From clemc at ccc.com  Wed Sep 18 01:33:42 2019
From: clemc at ccc.com (Clem Cole)
Date: Tue, 17 Sep 2019 11:33:42 -0400
Subject: [TUHS] [tuhs] Computer history preservation
In-Reply-To: <7w7e67mrb1.fsf@junk.nocrew.org>
References: <CMM.0.95.0.1568670516.beebe@gamma.math.utah.edu>
 <7w7e67mrb1.fsf@junk.nocrew.org>
Message-ID: <CAC20D2NN65CZ11vw=TAUWsGwfA54VCEiRi0kfzFzKYqfhywJsw@mail.gmail.com>

Lars - I love it.  I've never seen that part of the curve spelled out and
labeled before.
ᐧ

On Tue, Sep 17, 2019 at 1:21 AM Lars Brinkhoff <lars at nocrew.org> wrote:

> "Nelson H. F. Beebe" <beebe at math.utah.edu> writes:
> > I came across an article today about another major industry that has
> > been exceedingly careless about preserving its history
>
> It's an extenssion of the hype cycle.  It starts like this:
>
> 1. Technology Trigger
> 2. Peak of Inflated Expectations
> 3. Trough of Disillusionment
> 4. Slope of Enlightenment
> 5. Plateau of Productivity
>
> What is usually not pictured is the rest of the curve:
>
> 6. Dip of Sunset Technology.
> 7. Valley of Obsolete Stuff.
> 8. Throwing Away of Old Junk.
> 9. Resurge of Nostalgia.
> 10. Frantic Search on Ebay.
> 11. The Even Higher Peak of Collector's Holy Grail.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190917/977f781c/attachment.html>

From jnc at mercury.lcs.mit.edu  Wed Sep 18 01:36:38 2019
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Tue, 17 Sep 2019 11:36:38 -0400 (EDT)
Subject: [TUHS] block operations in editors, was  My EuroBSDcon talk
Message-ID: <20190917153638.79BDC18C098@mercury.lcs.mit.edu>

    > From: Doug McIlroy

    > the absence of multidemensional arrays in C.

?? From the 'C Reference Manual' (no date, but circa 'Typesetter C'), pg. 11:

  "If the unadorned declarator D would specify an n-dimensional array .. then
  the declarator D[in+1] yields an (n+1)-dimensional array"

I'm not sure if I've _ever_ used one, but they are there.

    Noel

From cbbrowne at gmail.com  Wed Sep 18 01:58:20 2019
From: cbbrowne at gmail.com (Christopher Browne)
Date: Tue, 17 Sep 2019 11:58:20 -0400
Subject: [TUHS] earliest Unix roff
In-Reply-To: <201909170753.x8H7r8oT004491@freefriends.org>
References: <CAC20D2Nz-ofwD41vULF2-TL8-C33heCiHvoNNbcuj6GGKhtKzQ@mail.gmail.com>
 <20190913221345.GA16129@minnie.tuhs.org>
 <CAC20D2OQD-NJaFsqsLVL_kqmCsSeUOKAr7dm71P4uN9N8m+AbQ@mail.gmail.com>
 <20190914020240.GO2046@mcvoy.com> <20190914024433.GA19193@minnie.tuhs.org>
 <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org>
 <201909150654.x8F6sChG021185@freefriends.org>
 <CAC20D2PfLq=J5ei+izXb2J7dSvU6=L6-GRd0gKA2ShSNg1=qBg@mail.gmail.com>
 <201909160552.x8G5qBYK025195@freefriends.org>
 <CAC20D2N89jOBK+T9EPn8JKNaSOUx=yDr9t4=CcyHM+3qnB2bEg@mail.gmail.com>
 <20190916145122.GH2046@mcvoy.com>
 <201909170753.x8H7r8oT004491@freefriends.org>
Message-ID: <CAFNqd5XKQu_gLy7BEYMeRY0QkoPXv64Y-1Od-TbbU-RTyHoSUA@mail.gmail.com>

On Tue, Sep 17, 2019, 3:54 AM <arnold at skeeve.com> wrote:

> It is like clockwork.
>
> Whenever I say something about Texinfo *as a markup language* for use
> in *writing books*, the discussion inevitably degenerates into a hate
> rant against Info and RMS's (failed) attempt to replace man pages.
> Totally missing the point too.
>

Yeah, that is a pain in the neck.

I had the other reaction to this...

I have been managing my web presence via DocBook SGML for a goodly long
time.  It is, as mentioned upthread, pretty wordy what with all the verbose
tagging.

It would be worth something to be able to edit it in TeXinfo form, with the
lesser amount of tagging required.  (And I'd kinda like to get off of
DocBook/SGML one of these days as the toolset is clearly mouldering away
pretty badly.)

So my reaction to your comments was to look into the usability of
TeXinfo...  I did a wee experiment yesterday, attempting to use docbook2x
to get to something else.  Alas, it seems to want to use xsltproc on the
XML form, and the transformation to XML is apparently a separate pain in
the neck.  I thought I accomplished it, but the XSLT for generating TeXinfo
throws up on it, so there must be more to the matter.  I'll take a further
poke at it later; thank you for offering a bit of inspiration on possible
approaches to change.

I know I can turn DocBook into s-expressions, and then write some
transformation in CL after that; it would be nice if there were something
already written.

For sophisticated material, TeXinfo is of use, notwithstanding notions to
make everything into brief man pages.

Bashing RMS for wanting things from ITS (and probably Multics too) (as I
see elsewhere in the thread) is unnecessarily unkind.  A dogmatic attitude
of "must be short man pages" shifts us to a different Procrustean bed that
fails in a different set of cases.  I for one was kinda hoping for Project
Xanadu someday, to throw a different perspective on that.

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190917/83c50604/attachment.html>

From crossd at gmail.com  Wed Sep 18 02:29:53 2019
From: crossd at gmail.com (Dan Cross)
Date: Tue, 17 Sep 2019 12:29:53 -0400
Subject: [TUHS] PiDP-11 in action!
In-Reply-To: <d7450e08-7897-a614-ce21-73948659a09e@e-bbes.com>
References: <CAP2nic11x4sXEAdUJDeg_m_qs6bo41vnopgA_yGPkqcvEvSVSw@mail.gmail.com>
 <d7450e08-7897-a614-ce21-73948659a09e@e-bbes.com>
Message-ID: <CAEoi9W5owY85Ta4U-gPa9AZQK_60kngnksBLhvdQave9AkHWYg@mail.gmail.com>

On Tue, Sep 17, 2019 at 2:23 AM emanuel stiebler <emu at e-bbes.com> wrote:

> On 2019-09-17 04:51, Adam Thornton wrote:
> > https://share.icloud.com/photos/0MKJjk8pRBvkZAEzaobjfOyPQ
> >
> > I start v7 Unix and play "Hunt The Wumpus".
> >
> > (I finally got it put together this weekend, and fixed the last couple
> > dodgy joints tonight).
>
> IBM keyboard on a vt520?
>

Huh; apparently the VT520 had (well, has...) a PS/2 compatible 6-pin
mini-DIN connector: http://web.mit.edu/dosathena/doc/www/ek-vt520-rm.pdf

I'm most familiar with the earlier VT models that use MMJ connectors for
the keyboard (and RS-232). That's kinda nifty, though.

        - Dan C.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190917/ea9e187c/attachment.html>

From pechter at gmail.com  Wed Sep 18 02:54:08 2019
From: pechter at gmail.com (William Pechter)
Date: Tue, 17 Sep 2019 12:54:08 -0400
Subject: [TUHS] PiDP-11 in action!
In-Reply-To: <CAEoi9W5owY85Ta4U-gPa9AZQK_60kngnksBLhvdQave9AkHWYg@mail.gmail.com>
References: <CAP2nic11x4sXEAdUJDeg_m_qs6bo41vnopgA_yGPkqcvEvSVSw@mail.gmail.com>
 <d7450e08-7897-a614-ce21-73948659a09e@e-bbes.com>
 <CAEoi9W5owY85Ta4U-gPa9AZQK_60kngnksBLhvdQave9AkHWYg@mail.gmail.com>
Message-ID: <dd067e26-a6de-4fd5-b469-0b1ddc798b4a.maildroid@localhost>

Actually...  IIRC the RJ11 was used on the VT2xx and 3xx series terminals.  The MMJ was only on the RS232 port. 

I would check, but I gave away my last non VT180 DEC terminal. 

Bill

Sent from pechter at gmail.com

-----Original Message-----
From: Dan Cross <crossd at gmail.com>
To: emanuel stiebler <emu at e-bbes.com>
Cc: The Eunuchs Hysterical Society <tuhs at tuhs.org>
Sent: Tue, 17 Sep 2019 12:31
Subject: Re: [TUHS] PiDP-11 in action!

On Tue, Sep 17, 2019 at 2:23 AM emanuel stiebler <emu at e-bbes.com> wrote:

> On 2019-09-17 04:51, Adam Thornton wrote:
> > https://share.icloud.com/photos/0MKJjk8pRBvkZAEzaobjfOyPQ
> >
> > I start v7 Unix and play "Hunt The Wumpus".
> >
> > (I finally got it put together this weekend, and fixed the last couple
> > dodgy joints tonight).
>
> IBM keyboard on a vt520?
>

Huh; apparently the VT520 had (well, has...) a PS/2 compatible 6-pin
mini-DIN connector: http://web.mit.edu/dosathena/doc/www/ek-vt520-rm.pdf

I'm most familiar with the earlier VT models that use MMJ connectors for
the keyboard (and RS-232). That's kinda nifty, though.

        - Dan C.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190917/045d51d7/attachment.html>

From clemc at ccc.com  Wed Sep 18 03:12:37 2019
From: clemc at ccc.com (Clem Cole)
Date: Tue, 17 Sep 2019 13:12:37 -0400
Subject: [TUHS] PiDP-11 in action!
In-Reply-To: <CAEoi9W5owY85Ta4U-gPa9AZQK_60kngnksBLhvdQave9AkHWYg@mail.gmail.com>
References: <CAP2nic11x4sXEAdUJDeg_m_qs6bo41vnopgA_yGPkqcvEvSVSw@mail.gmail.com>
 <d7450e08-7897-a614-ce21-73948659a09e@e-bbes.com>
 <CAEoi9W5owY85Ta4U-gPa9AZQK_60kngnksBLhvdQave9AkHWYg@mail.gmail.com>
Message-ID: <CAC20D2MjXtNu1uZhC2phQ_kR0jxsQwbBaVf4w4kH12NoF2JSHw@mail.gmail.com>

A PITA, but I actually have the block to crimp them and some MMJ stock in
my basement.  Lego Mindstorms use it also as a way to try to keep
people from by options from other folks.  I never thought it was nifty mind
you.
ᐧ

On Tue, Sep 17, 2019 at 12:31 PM Dan Cross <crossd at gmail.com> wrote:

> On Tue, Sep 17, 2019 at 2:23 AM emanuel stiebler <emu at e-bbes.com> wrote:
>
>> On 2019-09-17 04:51, Adam Thornton wrote:
>> > https://share.icloud.com/photos/0MKJjk8pRBvkZAEzaobjfOyPQ
>> >
>> > I start v7 Unix and play "Hunt The Wumpus".
>> >
>> > (I finally got it put together this weekend, and fixed the last couple
>> > dodgy joints tonight).
>>
>> IBM keyboard on a vt520?
>>
>
> Huh; apparently the VT520 had (well, has...) a PS/2 compatible 6-pin
> mini-DIN connector: http://web.mit.edu/dosathena/doc/www/ek-vt520-rm.pdf
>
> I'm most familiar with the earlier VT models that use MMJ connectors for
> the keyboard (and RS-232). That's kinda nifty, though.
>
>         - Dan C.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190917/7d327e85/attachment.html>

From doug at cs.dartmouth.edu  Wed Sep 18 03:31:52 2019
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Tue, 17 Sep 2019 13:31:52 -0400
Subject: [TUHS] block operations in editors, was  My EuroBSDcon talk
Message-ID: <201909171731.x8HHVq2L096688@tahoe.cs.Dartmouth.EDU>

Noel Chiappa wrote:

>    > From: Doug McIlroy
>
>    > the absence of multidemensional arrays in C.
>
>?? From the 'C Reference Manual' (no date, but circa 'Typesetter C'), pg. 11:
>
>  "If the unadorned declarator D would specify an n-dimensional array .. then
>  the declarator D[in+1] yields an (n+1)-dimensional array"
>
>
>I'm not sure if I've _ever_ used one, but they are there.

Yes, C allows arrays of arrays, and I've used them aplenty.
However an "n-dimensional array" has one favored dimension,
out of which you can slice an array of lower dimension. For
example, you can pass a row of a 2D array to a function of a
1D variable, but you can't pass a column. That asymmetry
underlies my assertion. In Python, by contrast, n-dimensional
arrays can be sliced on any dimension.

Doug

From crossd at gmail.com  Wed Sep 18 03:48:12 2019
From: crossd at gmail.com (Dan Cross)
Date: Tue, 17 Sep 2019 13:48:12 -0400
Subject: [TUHS] PiDP-11 in action!
In-Reply-To: <dd067e26-a6de-4fd5-b469-0b1ddc798b4a.maildroid@localhost>
References: <CAP2nic11x4sXEAdUJDeg_m_qs6bo41vnopgA_yGPkqcvEvSVSw@mail.gmail.com>
 <d7450e08-7897-a614-ce21-73948659a09e@e-bbes.com>
 <CAEoi9W5owY85Ta4U-gPa9AZQK_60kngnksBLhvdQave9AkHWYg@mail.gmail.com>
 <dd067e26-a6de-4fd5-b469-0b1ddc798b4a.maildroid@localhost>
Message-ID: <CAEoi9W5-4RA-VWEzOvik_BnJ8_Q4rS7x6Pcps-vzY=pm4i9G-g@mail.gmail.com>

On Tue, Sep 17, 2019 at 12:54 PM William Pechter <pechter at gmail.com> wrote:

> Actually...  IIRC the RJ11 was used on the VT2xx and 3xx series
> terminals.  The MMJ was only on the RS232 port.
>
> I would check, but I gave away my last non VT180 DEC terminal.
>

I stand corrected. I keep a VT420 on my desk with an LK421 (the "Unix"
keyboard), connected to my workstation (now via a USB serial adapter). I
just popped the keyboard and it is, indeed, an RJ11 for the keyboard.
Serial is MMJ, which connects to an MMJ<->DB9 converter which connects to a
mini null-modem to the USB adapter. So simple.

        - Dan C.

-----Original Message-----
> From: Dan Cross <crossd at gmail.com>
> To: emanuel stiebler <emu at e-bbes.com>
> Cc: The Eunuchs Hysterical Society <tuhs at tuhs.org>
> Sent: Tue, 17 Sep 2019 12:31
> Subject: Re: [TUHS] PiDP-11 in action!
>
> On Tue, Sep 17, 2019 at 2:23 AM emanuel stiebler <emu at e-bbes.com> wrote:
>
>> On 2019-09-17 04:51, Adam Thornton wrote:
>> > https://share.icloud.com/photos/0MKJjk8pRBvkZAEzaobjfOyPQ
>> >
>> > I start v7 Unix and play "Hunt The Wumpus".
>> >
>> > (I finally got it put together this weekend, and fixed the last couple
>> > dodgy joints tonight).
>>
>> IBM keyboard on a vt520?
>>
>
> Huh; apparently the VT520 had (well, has...) a PS/2 compatible 6-pin
> mini-DIN connector: http://web.mit.edu/dosathena/doc/www/ek-vt520-rm.pdf
>
> I'm most familiar with the earlier VT models that use MMJ connectors for
> the keyboard (and RS-232). That's kinda nifty, though.
>
>         - Dan C.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190917/6959b4c0/attachment.html>

From steffen at sdaoden.eu  Wed Sep 18 03:57:59 2019
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Tue, 17 Sep 2019 19:57:59 +0200
Subject: [TUHS] SCCS
In-Reply-To: <20190916203152.GB9704@mcvoy.com>
References: <20190912034346.GJ2046@mcvoy.com>
 <a0231faa-8ad9-fa51-4b24-9854beb21210@gmail.com>
 <1457a2d6-2f17-482d-e4f7-ace439d34ca8@neophilic.com>
 <CAC20D2OZpnma4EX+PqgqfA7zNM7sofuDQ4zCURnLF7-G4TCKhQ@mail.gmail.com>
 <8db2e89c-ce50-a453-e38a-ecdfe69a746c@e-bbes.com>
 <20190913211104.aMZXy%steffen@sdaoden.eu> <20190913211751.GF2046@mcvoy.com>
 <20190913230312.XaeCQ%steffen@sdaoden.eu> <20190914015517.GD12480@mcvoy.com>
 <20190916172300.cjlkf%steffen@sdaoden.eu> <20190916203152.GB9704@mcvoy.com>
Message-ID: <20190917175759.bUdCC%steffen@sdaoden.eu>

Larry McVoy wrote in <20190916203152.GB9704 at mcvoy.com>:
 |On Mon, Sep 16, 2019 at 07:23:00PM +0200, Steffen Nurpmeso wrote:
 |> Larry McVoy wrote in <20190914015517.GD12480 at mcvoy.com>:
 |>|On Sat, Sep 14, 2019 at 01:03:12AM +0200, Steffen Nurpmeso wrote:
 |>|> He is as convinced from SCCS and its interleaved deltas as you
 |>|> are, but he works on extending the plain original SCCS, which is
 |>|> pretty smaller; his presentation from the "Chemnitzer Linux Tage
 |>|> 2012" (linux days of former Karl-Marx-Stadt) [1] talks about this
 |>|> and also prominently mentions BitKeeper:
 |>|> 
 |>|>   . All modern distributed OSS version control systems base upon
 |>|>     BitKeeper in the end.
 |>|
 |>|Sort of.  Monotone, Darcs, and one other one I can't remember did not
 |>|draw from BitKeeper.  Mercurial, Git, and the Australian one that I
 |>|can't remember definitely do.
 |>|
 |>|>   . BitKeeper bases upon the ideas of TeamWare.
 |>|
 |>|Only in that I am the primary author of both.  It does support the idea
 |>|that SCCS is the basis for both, though Teamware used the real SCCS and
 |>|I rewrote SCCS from scratch and then extended it quite a bit.  BitKeeper\
 |>|'s
 |>|SCCS tracks a lot more than SCCS does, pathnames, permissions, hostnames,
 |>|etc.
 |> 
 |> Regarding the technical background J??rg mentions US Patent 5481722
 |> on merging deltas of source code control for computer software
 |> development that Glenn Skinner of Sun holds.
 |
 |Yeah, it's nuts that Glenn got that patent.  It's true it was his idea
 |to do the graph that way, and he had an implementation that created
 |the graph through multiple calls to stripdel, get, and delta.  It was
 |excruciatingly slow.
 |
 |100% of the code that implemented the one pass "zipper"-ing of 2 
 |diverged SCCS files was designed and written by me.  At the very
 |least, I should have been coauthor of the patent but Sun politics
 |got in the way [1].  
 |
 |>|>   . TeamWare bases upon the ideas of NSE.
 |>|
 |>|That's absolutely false.  TeamWare, which is the productized version
 |>|of NSElite, which I wrote all of, was a reaction to how absolute shiite
 |>|NSE was.  I had friends in the Sun kernel group that quit because they
 |>|were forced to use NSE.  It was awful.  I got into source management 
 |>|because I was well known at Sun as the guy that could fix performance
 |>|problems so I was asked to look at NSE.  One look told me that I couldn't
 |>|fix NSE but the source management problem space needed some help.
 |
 |[1] The politics had to do with Teamware.  I wrote all the code in
 |NSElite, including smoosh(1) which was what the patent covered (though
 |the patent happened later).  Everyone in the kernel group were using
 |NSElite because NSE sucked so hard.  But it wasn't sanctioned code,
 |it was a Larry project.  Bill Shannon would walk around and tell people
 |that they couldn't use NSElite but they ignored him because it worked
 |and it was light years faster than NSE.
 |
 |They couldn't kill NSElite so they decided to toss it to an 8 person
 |team in the tools group.  They told me if I wanted to work on tools I
 |had to go join the tools group.  Yeah, right, I'm in the kernel group
 |and I'm going to take the 3 step downgrade to tools?  I don't think so.
 |
 |I just kept on supporting and developing NSElite, which was 90% perl4
 |and a xview graphical program to view history and smoosh (both C).
 |Because I was coding most of the stuff in (very stylized perl, I rewrote
 |it 3 times until I had code I could have a hope of maintaining), I was
 |much faster at rolling out new stuff.  In fact, the 8 people choose to
 |rewrite everything in C++ which meant I was coding circles around them.
 |Hence the politics, one guy, in his spare time, while doing a full time
 |job hacking the kernel, was making 8 guys look like idiots.  Evan later
 |wrote a paper about what a bad choice C++ was.
 |
 |Something had to give and Jon Kannegaard, who was the VP of the tools
 |group, walked into my office and said "I've got Scott's (McNealy, CEO)
 |approval on this.  If you make one more release of NSElite you are 
 |fired."  Nice, eh?  Not everything was perfect at Sun.
 |
 |So I stopped, I left the kernel group and went over and did SPARC Clusters
 |for Ken Okin.  Glenn filed the patent after I left.
 |
 |It was a shame because NSElite didn't have changesets, it wasn't really
 |a distributed system (relied on NFS to get at remote repos), if I had
 |kept going it would have evolved into what BitKeeper bacame.
 |
 |Oh, yeah, the politics were so bad that when Evan took smoosh.c he
 |didn't take any of the SCCS history, he checked it in so it looked like
 |he wrote it.  Even Shannon called that dirty pool.

Thank you for this look into the Sun internals, the above sounds
manlike, and that in High-Tech!

 |>|>   . NSE is a frontend to SCCS.
 |>|
 |>|That's true.
 |>|
 |>|>   . Therewith all modern systems ultimately base upon SCCS.
 |>|
 |>|That is a big stretch, it's just not true.  I love the SCCS file 
 |>|format but to say all modern systems are based on SCCS is 100%
 |>|false.  BitKeeper is.  That's it.
 |>|
 |>|>   . Distributed operate TeamWare, BitKeeper, git, Mercurial.
 |>|
 |>|Git and Mercurial were going for append only data structures. 
 |>|That's not SCCS.
 |>|
 |>|All this comes from Jorg, isn't he the guy who has a track record of
 |>|being on the outside of Sun and trying to argue with me about what Sun
 |>|was doing when I was a well known guy in the most important group at Sun,
 |>|the kernel group.  If so, I'd salt his stuff heavily.
 |> 
 |> This is the J??rg Schilling with whom you have had a dispute on
 |> this list, yes.  But i do not share this track record of yours.
 |
 |OK, I'm happy you like him, I liked him just fine until he started 
 |making statements that aren't true.  Statements that were about 
 |what Sun was doing and why they were doing it.  Statements about
 |the content and direction of the kernel development, that I knew
 |to be false because I was in the Sun kernel group during the time
 |he was referencing.  Kinda hard to be any closer to it than I was
 |so unless I've gone completely senile in my old age, I'm probably
 |more likely to be right about that information than he is.  I was
 |there, he was not.

Hm, he started running into this list for sure.  Since you guys
are there for several decades, who can tell in between the line
fluxes, me not.  All i know is that if you interview multiple
people on the same topic, then you will hear multiple stories,
practically always.  Transporting history by hearsay is what made
us great, wa.  I will never forget documentation of some natives
in the Indonesian djungle, the kings envoy only said that he is
exactly that, was scanned by many eyes, .. and accepted.
So even if Jörg has a hearsay account on the Sun internals in
question, i cannot blame him for standing upon that ground.

 |> One thing he says, and which is an interesting part of this
 |> thread, is
 |> 
 |>   Die Behauptung von Eric Allman Tichy h??tte SCCS Version
 |>   1 verwendet kann ich nicht glauben, denn die Ver??ffentlichungen
 |>   von Tichy sind von 1982 und SCCS war seit Februar 1977 auf der
 |>   Version 4. SCCS Version 3 hatte ??brigens noch ein bin??res
 |>   Historyformat.
 |> 
 |>   The statement of Eric Allman that Tichy used SCCS version
 |>   1 i cannot believe, because Tichy's releases are from 1982, and
 |>   SCCS version 4 was released as earyl as February 1977.  SCCS
 |>   version 3 used a binary history format, by the way.
 |
 |Before my time so I don't know.  I was an undergrad Art History major
 |at that time :)
 |
 |--lm
 --End of <20190916203152.GB9704 at mcvoy.com>

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

From arnold at skeeve.com  Wed Sep 18 04:15:40 2019
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Tue, 17 Sep 2019 12:15:40 -0600
Subject: [TUHS] earliest Unix roff
In-Reply-To: <CAFNqd5XKQu_gLy7BEYMeRY0QkoPXv64Y-1Od-TbbU-RTyHoSUA@mail.gmail.com>
References: <CAC20D2Nz-ofwD41vULF2-TL8-C33heCiHvoNNbcuj6GGKhtKzQ@mail.gmail.com>
 <20190913221345.GA16129@minnie.tuhs.org>
 <CAC20D2OQD-NJaFsqsLVL_kqmCsSeUOKAr7dm71P4uN9N8m+AbQ@mail.gmail.com>
 <20190914020240.GO2046@mcvoy.com>
 <20190914024433.GA19193@minnie.tuhs.org>
 <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org>
 <201909150654.x8F6sChG021185@freefriends.org>
 <CAC20D2PfLq=J5ei+izXb2J7dSvU6=L6-GRd0gKA2ShSNg1=qBg@mail.gmail.com>
 <201909160552.x8G5qBYK025195@freefriends.org>
 <CAC20D2N89jOBK+T9EPn8JKNaSOUx=yDr9t4=CcyHM+3qnB2bEg@mail.gmail.com>
 <20190916145122.GH2046@mcvoy.com>
 <201909170753.x8H7r8oT004491@freefriends.org>
 <CAFNqd5XKQu_gLy7BEYMeRY0QkoPXv64Y-1Od-TbbU-RTyHoSUA@mail.gmail.com>
Message-ID: <201909171815.x8HIFfKS022066@freefriends.org>

Hi.

Christopher Browne <cbbrowne at gmail.com> wrote:
> I had the other reaction to this...
>
> I have been managing my web presence via DocBook SGML for a goodly long
> time.  It is, as mentioned upthread, pretty wordy what with all the verbose
> tagging.
>
> It would be worth something to be able to edit it in TeXinfo form, with the
> lesser amount of tagging required.  (And I'd kinda like to get off of
> DocBook/SGML one of these days as the toolset is clearly mouldering away
> pretty badly.)

Looks like pandoc will go from DocBook to Texinfo.

Me, I'd probably write a giant awk script to do the grunt work. :-)

> For sophisticated material, TeXinfo is of use, notwithstanding notions to
> make everything into brief man pages.

As I've been saying, I use it for books.

Good luck,

Arnold

From imp at bsdimp.com  Wed Sep 18 04:32:34 2019
From: imp at bsdimp.com (Warner Losh)
Date: Tue, 17 Sep 2019 12:32:34 -0600
Subject: [TUHS] earliest Unix roff
In-Reply-To: <201909171815.x8HIFfKS022066@freefriends.org>
References: <CAC20D2Nz-ofwD41vULF2-TL8-C33heCiHvoNNbcuj6GGKhtKzQ@mail.gmail.com>
 <20190913221345.GA16129@minnie.tuhs.org>
 <CAC20D2OQD-NJaFsqsLVL_kqmCsSeUOKAr7dm71P4uN9N8m+AbQ@mail.gmail.com>
 <20190914020240.GO2046@mcvoy.com> <20190914024433.GA19193@minnie.tuhs.org>
 <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org>
 <201909150654.x8F6sChG021185@freefriends.org>
 <CAC20D2PfLq=J5ei+izXb2J7dSvU6=L6-GRd0gKA2ShSNg1=qBg@mail.gmail.com>
 <201909160552.x8G5qBYK025195@freefriends.org>
 <CAC20D2N89jOBK+T9EPn8JKNaSOUx=yDr9t4=CcyHM+3qnB2bEg@mail.gmail.com>
 <20190916145122.GH2046@mcvoy.com>
 <201909170753.x8H7r8oT004491@freefriends.org>
 <CAFNqd5XKQu_gLy7BEYMeRY0QkoPXv64Y-1Od-TbbU-RTyHoSUA@mail.gmail.com>
 <201909171815.x8HIFfKS022066@freefriends.org>
Message-ID: <CANCZdfq5CEzDUwbkisMLJP1eHws1EiqF8xj+ZaAeMoewaAqWfw@mail.gmail.com>

On Tue, Sep 17, 2019 at 12:16 PM <arnold at skeeve.com> wrote:

> Hi.
>
> Christopher Browne <cbbrowne at gmail.com> wrote:
> > I had the other reaction to this...
> >
> > I have been managing my web presence via DocBook SGML for a goodly long
> > time.  It is, as mentioned upthread, pretty wordy what with all the
> verbose
> > tagging.
> >
> > It would be worth something to be able to edit it in TeXinfo form, with
> the
> > lesser amount of tagging required.  (And I'd kinda like to get off of
> > DocBook/SGML one of these days as the toolset is clearly mouldering away
> > pretty badly.)
>
> Looks like pandoc will go from DocBook to Texinfo.
>
> Me, I'd probably write a giant awk script to do the grunt work. :-)
>

FreeBSD likely is moving out DocBook stuff to markdown. Docbook is too hard
to find people to work on :(

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190917/9c0e86e8/attachment.html>

From imp at bsdimp.com  Wed Sep 18 05:18:16 2019
From: imp at bsdimp.com (Warner Losh)
Date: Tue, 17 Sep 2019 13:18:16 -0600
Subject: [TUHS] My EuroBSDcon talk (preview for commentary)
In-Reply-To: <CAC20D2MDbmoeMZq1esbuQvOCU7to0dUWsFyx98UQDLE3-c4fOA@mail.gmail.com>
References: <CANCZdfrK4iFQCWOFP4MoUggpfJVmoJ0dnSg6H0cCi4dop7sVXw@mail.gmail.com>
 <CAC20D2NmXGzN7imTKy-RRWRZ2ewWMEmUV9oDuP3-e3a4R+ynpA@mail.gmail.com>
 <CAC20D2PXYWpv-8BQNKvUjgT=2W81GgzaOLyZiQ5=sM9+LXCWnw@mail.gmail.com>
 <CAC20D2MDbmoeMZq1esbuQvOCU7to0dUWsFyx98UQDLE3-c4fOA@mail.gmail.com>
Message-ID: <CANCZdfqB5FaNdxqSXOTx3c0OeYyptnkHqDG2YAAvPiT3gU7NoQ@mail.gmail.com>

On Fri, Sep 13, 2019 at 2:07 PM Clem Cole <clemc at ccc.com> wrote:

> Another thought -- the first commercial licensee was Rand.   Hired some
> former Harvard students who brought UNIX with them.   You probably need to
> add things like Rand Ports (a.k.a. named pipes) which came from there.
> Also Chesson and Co did the original ArpaNET NCP at University of Ill
> with some help from the Rand folks.   That was done on a V6 system ~ 1978
>

When I worked at The Wollongong Group they were quite specific that they
had their license from V6 days, that it was a one-off that has unusually
favorable terms, and that it was the first licensee. But that may be the
first license to redistribute, rather than the first commercial user to be
licensed...  I think for an expanded version of my talk, I'd include the
other details, since there's both the NCP work and some TCP work with v7 in
our archive these days. I'll add a bullet point for these things. V6/V7 is
the time that derivatives and add-ons really start to appear in relative
abundance.

You also need need Ken's famous V6 'patch' tape -- that 'leaked'
>

I'll see if I can work that in.. Is that the famous '50 patches' or is that
something else?

On Fri, Sep 13, 2019 at 4:02 PM Clem Cole <clemc at ccc.com> wrote:
>
>> BTW:  I just thought of something else....  one of the b*tched about the
>> commercial redistribution license from V7 in 1979, that was not fixed until
>> the SVR3 licensing the mid-late 1980s  was AT&T's source policy.   As I
>> said, a commercial source license was $20K for the first CPU and 5K for
>> each additional one.   Later (System V) it went to $50K for the first and
>> $10K for each additional.   But what really ticked off the vendors like
>> DEC, Masscomp, Sun et al, was that each system that sources on was supposed
>> to one of the 'second CPU licenses' - the binary license was not good
>> enough.
>>
>> What most of us did, was make sure any system that was a 'source control'
>> or 'master' system at any 'site' had a full source license, but we were all
>> in violation of the source agreement on our personal workstations.  The
>> argument was the sources on people's machines was ephemeral and not
>> 'stored' there.   But it was definitely contentious.
>>
>
Yea, I think that all these details are (a) interesting but (b) not quite
right for this talk...

Warner


> On Fri, Sep 13, 2019 at 3:47 PM Clem Cole <clemc at ccc.com> wrote:
>>
>>> slide 4 --  All of HP-UX, Ultrix and Digital UNIX/Tru64 are BSD
>>> kernels.  HP-UP and Tru64 support System V calls.
>>>
>>> BTW:  DG-UX and Stratus built their own kernels, but used System V
>>> command systems and System Call definitions - which are not listed.
>>>
>>> Slide 6 - if you want it I have another picture of the GE system from
>>> some of their literature has a view of all of the components.   Send me
>>> email if you want it.
>>>
>>> Slide 8 - Sets out to write version of Fortran came up with B.  Uses B
>>> to write Assembler
>>>
>>> Slide 9 - Wrong DEC logo.  Should be the Blue one.  The maroon version
>>> does not show up until the 1990s with Bob Palmer (and has bad memories for
>>> some of us).
>>>
>>> Slide 17 - Ken write PDP-11 assembler on PDP-7 in B. , Dennis starts to
>>> rewrite B compiler to output PDP-11 code.
>>>
>>> Slide 18 - B begins to become different enough that Dennis starts to
>>> call it nb [new B], eventually deviates enough to become new language
>>>
>>> Slide 19 - 4th Edition release outside of the BTL.  Lou Katz
>>> becomes 'user zero'
>>>
>>> Slide 20 -- We need to get you the site and group name from Mash.  It
>>> was not in Summit, it was not USG - but was in NJ.  I thought it was Homdel
>>> but I that is purely speculation.
>>>                   Also the role of Columbus team needs to be defined.
>>>  Ask Mary Ann.
>>>
>>> Slide 21 -- I'm not going to argue - but I would ask you to add a
>>> disclaimer.   This is what you could reconstruct, but there is some
>>> question of some of the arrows.   Heinz might be able to help, but as
>>> Stienhart and I have said, its believed to be in LA; but no one has tracked
>>> him down as he has been pursuing non-computer interests.
>>>
>>> Slide 22 --4th Edition went to Katz that this is wrong, who sometimes
>>> reads this mailing list.  If not, send me a note, I'll reintroduce you.  He
>>> might be able to give you a data.  Check with Warren, my >>memory<< is that
>>> some of userland is still in C although a lot assembler is still there.
>>>
>>> Slide 23 -- ??widespread??   -- I'm not sure I would use that. Not even
>>> 100 sites yet.     Also there were not "commercial version" this was the
>>> first "commercial license" -- big difference [contact me if you want
>>> explanation].  IIRC fee was 15K per CPU.  Commercial redistribution doesn't
>>> occur until after 7th is released and was a separate license.   I would
>>> add, Mike Lesk's portable C library is starting to be used, but most C
>>> program do their own I/O with read/write
>>>
>>>           First real install man page and Dennis build tape installation
>>> system.   Earlier version released as RK05 disk copies.
>>>            Also numerous new peripherals. IIRC Support for the 11/40
>>> starts here, 4th & 5th needed a 45 class, and earlier used the 20 with the
>>> CSS MMU.
>>>
>>> Slide 24 -- CMU uses it to teaches OS class.  makes student in class
>>> sign a sub-license.
>>>
>>> Slide 25 - missing the first USENIX tapes. which include Harvard and the
>>> like.  Warren and I can probably help a little here.
>>>
>>> Slide 26 - new licenses.  Commercial license fees change to 20K for 1st
>>> CPU/5K for each CPU afterward.  CMU buys first commercial license to use
>>> UNIX to make money [after Cole and Klein go on strike].  Case Western
>>> follows suit 6month later.   AT&T agrees for the Universities that they
>>> only had to declare one CPU as commercial and could intermix otherwise and
>>> notifies all the universities that if they were using it for commercial
>>> purposes, then needed a license.
>>>
>>> AT&T creates first redistribution license.  Needed at least one $20K
>>> commercial CPU and then $150k for the rights to redistribute.   Originally
>>> $1K per binary CPU.
>>>
>>> Slide 27 -- missing Purdue Dual Vax and CMU Mach
>>>
>>> Slide 28 - APS had NH which was the model the DEC plate you show.
>>>  Maddog has it now on his Jeep when aps moved to CA (he also has the NH
>>> Linux plate but I don't remember the car -- you can ask him).   I have had
>>> the Massachusetts UNIX plate since 1983 (it's on my model S of course).
>>>  ghg has indiana from around the same time (I think on a pickup).  wnj had
>>> the CA vmunix on his Ferrari, but I don't know if he still has it or what
>>> its on.
>>>
>>> Slide 29 - Look in HenrySpencer-TUHS.org -- you'll find tail but not
>>> head.
>>>
>>> Slide 31 - Job Control can from Europe via MIT.  Jim Kulp wrote it.
>>>  Noel and I can give you the story if you want it.  It was on the PDP-11
>>> there.   Joy modified csh and added it to 4.1
>>>
>>> Slide 32 -- JC was not from UCB.   Joy got it from MIT   -- Dennis
>>> create ENV and it was first distributed in V7.
>>>
>>> Slide 33 -- No Bourne supported ENV in the new shell -- see me earlier
>>> email for how all this went down or ask Steve yourself.
>>>
>>> Slide 34 -- PCC was included, but the Ritchie Compiler (a.k.a.
>>> Typesetter C) was the default compiler.  You are missing a step BTW --
>>> typesetter C was released between V6 and V7.   As is the first draft of the
>>> White Book.  The new compiler had stdio but targets V6.
>>> Also mpx was part of DataKit support.
>>>
>>> Slide 35 --   Not sure that is true.   I thought Microsoft's Xenix ships
>>> before Venix.    Particularly since you made the comment about System III
>>> The original 8086 Xenix was a pure V7 port, with a few additions Gordon
>>> brought with him from Purdue (i.e. ghg hacks).
>>>
>>> Slide 52/53/54/55 -- wrong logo (see above)
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Thu, Sep 12, 2019 at 11:21 PM Warner Losh <imp at bsdimp.com> wrote:
>>>
>>>> OK. I've shared my slides for the talk.
>>>>
>>>> Some of the family trees are simplified (V7 doesn't have room for all
>>>> its ports, for example)
>>>> Some of it is a little cheeseball since I'm also trying to be witty and
>>>> entertaining (we'll see how that goes).
>>>> Please don't share them around until after my talk on the September 20th
>>>>
>>>> I'd like feedback on the bits I got wrong. Or left out. Or if you're in
>>>> this and don't want to be, etc.
>>>>
>>>> All the slides after the Questions slide won't be presented and will
>>>> likely be deleted.
>>>>
>>>>
>>>> https://docs.google.com/presentation/d/177KxOif5oHARyIdZHDq-OO67_GVtMkzIAlDX-cHxgb4/edit?usp=sharing
>>>>
>>>> Please be kind (but if it sucks, please do tell). I've turned on
>>>> commenting on the slides. Probably best if you comment there.
>>>>
>>>> I have a video of me giving this talk, but it's too rough to share...
>>>>
>>>> Thanks for any help you can give me.
>>>>
>>>> Warner
>>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190917/1c0672e5/attachment-0001.html>

From imp at bsdimp.com  Wed Sep 18 05:29:04 2019
From: imp at bsdimp.com (Warner Losh)
Date: Tue, 17 Sep 2019 13:29:04 -0600
Subject: [TUHS] My EuroBSDcon talk (preview for commentary)
In-Reply-To: <CAC20D2MKKm735_OR8GPnu_m0gdR4NEGNWin0qZkB0_C5ve_-+w@mail.gmail.com>
References: <CANCZdfrK4iFQCWOFP4MoUggpfJVmoJ0dnSg6H0cCi4dop7sVXw@mail.gmail.com>
 <CAC20D2NmXGzN7imTKy-RRWRZ2ewWMEmUV9oDuP3-e3a4R+ynpA@mail.gmail.com>
 <CAC20D2PXYWpv-8BQNKvUjgT=2W81GgzaOLyZiQ5=sM9+LXCWnw@mail.gmail.com>
 <CAC20D2MDbmoeMZq1esbuQvOCU7to0dUWsFyx98UQDLE3-c4fOA@mail.gmail.com>
 <CAC20D2MKKm735_OR8GPnu_m0gdR4NEGNWin0qZkB0_C5ve_-+w@mail.gmail.com>
Message-ID: <CANCZdfoPcNgkhZ6-ZyThyQm++42C=vSE7_RbfN64hohpECCjkQ@mail.gmail.com>

On Fri, Sep 13, 2019 at 3:31 PM Clem Cole <clemc at ccc.com> wrote:

> BTW: I just found my PWB 1.0 manual.   The date is May 1977, authors are
> T. (Ted) Dolotta, R. (Dick) Haight and E. Piskorik
> and it lists the site as 'Piscataway' as the site on the
> acknowlegements page.
>

Yes. That's the first release of PWB. However, they took delivery of their
first PDP-11 in 1973, which is when the PWB efforts began as part of the
BIS or BISP business unit (I have conflicting sources on the exact name).

After my talk is complete, I'd planned on going back and trying to piece
together release timelines as well, since although efforts happened
starting in 73, releases, as such, don't seem to start for another couple
of years. I suspect that when the number of groups being supported was
small, the overhead of a formal release cycle likely wasn't worth the
benefits (but have no documentation from the early days to prove that).

Warner


> On Fri, Sep 13, 2019 at 4:06 PM Clem Cole <clemc at ccc.com> wrote:
>
>> Another thought -- the first commercial licensee was Rand.   Hired some
>> former Harvard students who brought UNIX with them.   You probably need to
>> add things like Rand Ports (a.k.a. named pipes) which came from there.
>> Also Chesson and Co did the original ArpaNET NCP at University of Ill
>> with some help from the Rand folks.   That was done on a V6 system ~ 1978
>>
>> You also need need Ken's famous V6 'patch' tape -- that 'leaked'
>>
>>
>> On Fri, Sep 13, 2019 at 4:02 PM Clem Cole <clemc at ccc.com> wrote:
>>
>>> BTW:  I just thought of something else....  one of the b*tched about the
>>> commercial redistribution license from V7 in 1979, that was not fixed until
>>> the SVR3 licensing the mid-late 1980s  was AT&T's source policy.   As I
>>> said, a commercial source license was $20K for the first CPU and 5K for
>>> each additional one.   Later (System V) it went to $50K for the first and
>>> $10K for each additional.   But what really ticked off the vendors like
>>> DEC, Masscomp, Sun et al, was that each system that sources on was supposed
>>> to one of the 'second CPU licenses' - the binary license was not good
>>> enough.
>>>
>>> What most of us did, was make sure any system that was a 'source
>>> control' or 'master' system at any 'site' had a full source license, but we
>>> were all in violation of the source agreement on our personal
>>> workstations.  The argument was the sources on people's machines was
>>> ephemeral and not 'stored' there.   But it was definitely contentious.
>>>
>>>
>>>
>>> On Fri, Sep 13, 2019 at 3:47 PM Clem Cole <clemc at ccc.com> wrote:
>>>
>>>> slide 4 --  All of HP-UX, Ultrix and Digital UNIX/Tru64 are BSD
>>>> kernels.  HP-UP and Tru64 support System V calls.
>>>>
>>>> BTW:  DG-UX and Stratus built their own kernels, but used System V
>>>> command systems and System Call definitions - which are not listed.
>>>>
>>>> Slide 6 - if you want it I have another picture of the GE system from
>>>> some of their literature has a view of all of the components.   Send me
>>>> email if you want it.
>>>>
>>>> Slide 8 - Sets out to write version of Fortran came up with B.  Uses B
>>>> to write Assembler
>>>>
>>>> Slide 9 - Wrong DEC logo.  Should be the Blue one.  The maroon version
>>>> does not show up until the 1990s with Bob Palmer (and has bad memories for
>>>> some of us).
>>>>
>>>> Slide 17 - Ken write PDP-11 assembler on PDP-7 in B. , Dennis starts to
>>>> rewrite B compiler to output PDP-11 code.
>>>>
>>>> Slide 18 - B begins to become different enough that Dennis starts to
>>>> call it nb [new B], eventually deviates enough to become new language
>>>>
>>>> Slide 19 - 4th Edition release outside of the BTL.  Lou Katz
>>>> becomes 'user zero'
>>>>
>>>> Slide 20 -- We need to get you the site and group name from Mash.  It
>>>> was not in Summit, it was not USG - but was in NJ.  I thought it was Homdel
>>>> but I that is purely speculation.
>>>>                   Also the role of Columbus team needs to be defined.
>>>>  Ask Mary Ann.
>>>>
>>>> Slide 21 -- I'm not going to argue - but I would ask you to add a
>>>> disclaimer.   This is what you could reconstruct, but there is some
>>>> question of some of the arrows.   Heinz might be able to help, but as
>>>> Stienhart and I have said, its believed to be in LA; but no one has tracked
>>>> him down as he has been pursuing non-computer interests.
>>>>
>>>> Slide 22 --4th Edition went to Katz that this is wrong, who sometimes
>>>> reads this mailing list.  If not, send me a note, I'll reintroduce you.  He
>>>> might be able to give you a data.  Check with Warren, my >>memory<< is that
>>>> some of userland is still in C although a lot assembler is still there.
>>>>
>>>> Slide 23 -- ??widespread??   -- I'm not sure I would use that. Not even
>>>> 100 sites yet.     Also there were not "commercial version" this was the
>>>> first "commercial license" -- big difference [contact me if you want
>>>> explanation].  IIRC fee was 15K per CPU.  Commercial redistribution doesn't
>>>> occur until after 7th is released and was a separate license.   I would
>>>> add, Mike Lesk's portable C library is starting to be used, but most C
>>>> program do their own I/O with read/write
>>>>
>>>>           First real install man page and Dennis build tape
>>>> installation system.   Earlier version released as RK05 disk copies.
>>>>            Also numerous new peripherals. IIRC Support for the 11/40
>>>> starts here, 4th & 5th needed a 45 class, and earlier used the 20 with the
>>>> CSS MMU.
>>>>
>>>> Slide 24 -- CMU uses it to teaches OS class.  makes student in class
>>>> sign a sub-license.
>>>>
>>>> Slide 25 - missing the first USENIX tapes. which include Harvard and
>>>> the like.  Warren and I can probably help a little here.
>>>>
>>>> Slide 26 - new licenses.  Commercial license fees change to 20K for 1st
>>>> CPU/5K for each CPU afterward.  CMU buys first commercial license to use
>>>> UNIX to make money [after Cole and Klein go on strike].  Case Western
>>>> follows suit 6month later.   AT&T agrees for the Universities that they
>>>> only had to declare one CPU as commercial and could intermix otherwise and
>>>> notifies all the universities that if they were using it for commercial
>>>> purposes, then needed a license.
>>>>
>>>> AT&T creates first redistribution license.  Needed at least one $20K
>>>> commercial CPU and then $150k for the rights to redistribute.   Originally
>>>> $1K per binary CPU.
>>>>
>>>> Slide 27 -- missing Purdue Dual Vax and CMU Mach
>>>>
>>>> Slide 28 - APS had NH which was the model the DEC plate you show.
>>>>  Maddog has it now on his Jeep when aps moved to CA (he also has the NH
>>>> Linux plate but I don't remember the car -- you can ask him).   I have had
>>>> the Massachusetts UNIX plate since 1983 (it's on my model S of course).
>>>>  ghg has indiana from around the same time (I think on a pickup).  wnj had
>>>> the CA vmunix on his Ferrari, but I don't know if he still has it or what
>>>> its on.
>>>>
>>>> Slide 29 - Look in HenrySpencer-TUHS.org -- you'll find tail but not
>>>> head.
>>>>
>>>> Slide 31 - Job Control can from Europe via MIT.  Jim Kulp wrote it.
>>>>  Noel and I can give you the story if you want it.  It was on the PDP-11
>>>> there.   Joy modified csh and added it to 4.1
>>>>
>>>> Slide 32 -- JC was not from UCB.   Joy got it from MIT   -- Dennis
>>>> create ENV and it was first distributed in V7.
>>>>
>>>> Slide 33 -- No Bourne supported ENV in the new shell -- see me earlier
>>>> email for how all this went down or ask Steve yourself.
>>>>
>>>> Slide 34 -- PCC was included, but the Ritchie Compiler (a.k.a.
>>>> Typesetter C) was the default compiler.  You are missing a step BTW --
>>>> typesetter C was released between V6 and V7.   As is the first draft of the
>>>> White Book.  The new compiler had stdio but targets V6.
>>>> Also mpx was part of DataKit support.
>>>>
>>>> Slide 35 --   Not sure that is true.   I thought Microsoft's Xenix
>>>> ships before Venix.    Particularly since you made the comment about System
>>>> III
>>>> The original 8086 Xenix was a pure V7 port, with a few additions Gordon
>>>> brought with him from Purdue (i.e. ghg hacks).
>>>>
>>>> Slide 52/53/54/55 -- wrong logo (see above)
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Thu, Sep 12, 2019 at 11:21 PM Warner Losh <imp at bsdimp.com> wrote:
>>>>
>>>>> OK. I've shared my slides for the talk.
>>>>>
>>>>> Some of the family trees are simplified (V7 doesn't have room for all
>>>>> its ports, for example)
>>>>> Some of it is a little cheeseball since I'm also trying to be witty
>>>>> and entertaining (we'll see how that goes).
>>>>> Please don't share them around until after my talk on the September
>>>>> 20th
>>>>>
>>>>> I'd like feedback on the bits I got wrong. Or left out. Or if you're
>>>>> in this and don't want to be, etc.
>>>>>
>>>>> All the slides after the Questions slide won't be presented and will
>>>>> likely be deleted.
>>>>>
>>>>>
>>>>> https://docs.google.com/presentation/d/177KxOif5oHARyIdZHDq-OO67_GVtMkzIAlDX-cHxgb4/edit?usp=sharing
>>>>>
>>>>> Please be kind (but if it sucks, please do tell). I've turned on
>>>>> commenting on the slides. Probably best if you comment there.
>>>>>
>>>>> I have a video of me giving this talk, but it's too rough to share...
>>>>>
>>>>> Thanks for any help you can give me.
>>>>>
>>>>> Warner
>>>>>
>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190917/956d05e0/attachment.html>

From clemc at ccc.com  Wed Sep 18 06:13:30 2019
From: clemc at ccc.com (Clem Cole)
Date: Tue, 17 Sep 2019 16:13:30 -0400
Subject: [TUHS] My EuroBSDcon talk (preview for commentary)
In-Reply-To: <CANCZdfqB5FaNdxqSXOTx3c0OeYyptnkHqDG2YAAvPiT3gU7NoQ@mail.gmail.com>
References: <CANCZdfrK4iFQCWOFP4MoUggpfJVmoJ0dnSg6H0cCi4dop7sVXw@mail.gmail.com>
 <CAC20D2NmXGzN7imTKy-RRWRZ2ewWMEmUV9oDuP3-e3a4R+ynpA@mail.gmail.com>
 <CAC20D2PXYWpv-8BQNKvUjgT=2W81GgzaOLyZiQ5=sM9+LXCWnw@mail.gmail.com>
 <CAC20D2MDbmoeMZq1esbuQvOCU7to0dUWsFyx98UQDLE3-c4fOA@mail.gmail.com>
 <CANCZdfqB5FaNdxqSXOTx3c0OeYyptnkHqDG2YAAvPiT3gU7NoQ@mail.gmail.com>
Message-ID: <CAC20D2MK=QdzhEBS4fqQ7srmsXbrPTvBXew+2AhSg4Htx=3Bpw@mail.gmail.com>

On Tue, Sep 17, 2019 at 3:18 PM Warner Losh <imp at bsdimp.com> wrote:

>
> When I worked at The Wollongong Group they were quite specific that they
> had their license from V6 days, that it was a one-off that has unusually
> favorable terms, and that it was the first licensee. But that may be the
> first license to redistribute, rather than the first commercial user to be
> licensed...
>
Possible - as I said ISC might have something also.  But V7 was the first
generally available redistrbution license.  It might have had a few tunable
things, but generally it was what everyone had.  The per CPU terms was set
thinking a computer cost $150K-500K, not $1-2K.




>
>
> I'll see if I can work that in.. Is that the famous '50 patches' or is
> that something else?
>
Yes - the patch tape or 50 changes.


> ᐧ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190917/221f0e41/attachment.html>

From clemc at ccc.com  Wed Sep 18 06:17:34 2019
From: clemc at ccc.com (Clem Cole)
Date: Tue, 17 Sep 2019 16:17:34 -0400
Subject: [TUHS] My EuroBSDcon talk (preview for commentary)
In-Reply-To: <CANCZdfoPcNgkhZ6-ZyThyQm++42C=vSE7_RbfN64hohpECCjkQ@mail.gmail.com>
References: <CANCZdfrK4iFQCWOFP4MoUggpfJVmoJ0dnSg6H0cCi4dop7sVXw@mail.gmail.com>
 <CAC20D2NmXGzN7imTKy-RRWRZ2ewWMEmUV9oDuP3-e3a4R+ynpA@mail.gmail.com>
 <CAC20D2PXYWpv-8BQNKvUjgT=2W81GgzaOLyZiQ5=sM9+LXCWnw@mail.gmail.com>
 <CAC20D2MDbmoeMZq1esbuQvOCU7to0dUWsFyx98UQDLE3-c4fOA@mail.gmail.com>
 <CAC20D2MKKm735_OR8GPnu_m0gdR4NEGNWin0qZkB0_C5ve_-+w@mail.gmail.com>
 <CANCZdfoPcNgkhZ6-ZyThyQm++42C=vSE7_RbfN64hohpECCjkQ@mail.gmail.com>
Message-ID: <CAC20D2OYGoirzLy2gmCmyQRbWGJSJG8pd+YZNmnd_iHYdxTHug@mail.gmail.com>

On Tue, Sep 17, 2019 at 3:29 PM Warner Losh <imp at bsdimp.com> wrote:

> Yes. That's the first release of PWB. However, they took delivery of their
> first PDP-11 in 1973, which is when the PWB efforts began
>
Hmmm... I'd believe the efforts start then, but the idea if going outside
of that group was later.
Mashey is the person to ask.  Send me email off line and I'll introduce you.




> as part of the BIS or BISP business unit (I have conflicting sources on
> the exact name).
>
Yeah that sounds like something I remember.  Ask Mash.




> ᐧ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190917/e16c073a/attachment.html>

From dave at horsfall.org  Wed Sep 18 08:39:46 2019
From: dave at horsfall.org (Dave Horsfall)
Date: Wed, 18 Sep 2019 08:39:46 +1000 (EST)
Subject: [TUHS] earliest Unix roff
In-Reply-To: <20190917013357.GA2046@mcvoy.com>
References: <a29bfbe24692c1908f8a880041b816f6e9262baa@webmail.yaccman.com>
 <0bc0d10f-d17c-24df-2a7f-8f154eefd318@kilonet.net>
 <20190917011752.GY2046@mcvoy.com>
 <60761215-5B0E-41E9-A333-8799C6FAADD3@ccc.com>
 <20190917013357.GA2046@mcvoy.com>
Message-ID: <alpine.BSF.2.21.9999.1909180837580.18105@aneurin.horsfall.org>

On Mon, 16 Sep 2019, Larry McVoy wrote:

> In retrospect having / be roots home is a super bad idea but I think it 
> was fairly common practice, /root became a thing as idiots like me 
> messed things up :)

After my similar fsckup, I made /etc root's home directory (it was much 
easier to recover, and was available at boot time).

-- Dave

From dave at horsfall.org  Wed Sep 18 09:12:21 2019
From: dave at horsfall.org (Dave Horsfall)
Date: Wed, 18 Sep 2019 09:12:21 +1000 (EST)
Subject: [TUHS] A Couple of New Unix Artifacts
In-Reply-To: <20190917095435.GA16333@minnie.tuhs.org>
References: <20190917095435.GA16333@minnie.tuhs.org>
Message-ID: <alpine.BSF.2.21.9999.1909180909020.18105@aneurin.horsfall.org>

On Tue, 17 Sep 2019, Warren Toomey wrote:

[...]

> Now you have a new topic to talk about :-)

The infamous plaster cast of certain genitals (if it actually existed; the 
cast I mean)?

-- Dave

From krewat at kilonet.net  Wed Sep 18 09:25:00 2019
From: krewat at kilonet.net (Arthur Krewat)
Date: Tue, 17 Sep 2019 19:25:00 -0400
Subject: [TUHS] A Couple of New Unix Artifacts
In-Reply-To: <alpine.BSF.2.21.9999.1909180909020.18105@aneurin.horsfall.org>
References: <20190917095435.GA16333@minnie.tuhs.org>
 <alpine.BSF.2.21.9999.1909180909020.18105@aneurin.horsfall.org>
Message-ID: <ce2287fa-e11e-c25a-9cc6-441a386be3f7@kilonet.net>

My wish list is:

- Oracle (or some other licensee) coughed up SunOS. Legally.
- AT&T or some other derivative coughed up SVR4(.2)

Ok, that's all I got ;)

But yes, I'm insane enough to want: Oracle coughing up Solaris 11.x(4?) 
- legally. And I don't mean OpenSolaris.

BTW - I know a certain institution I know, I'm pretty sure used V6 for a 
graphics workstation. I'm pretty sure they had a source license, but I 
could be wrong. What's the reality when it came to V6 being used 
commercially in a product? This would be around the early 80's 
timeframe. And certain law enforcement agencies actually used at least 
one workstation for whatever reason.  It would have run on MIcro-11's, 
and MIcro-Vaxen.


On 9/17/2019 7:12 PM, Dave Horsfall wrote:
> On Tue, 17 Sep 2019, Warren Toomey wrote:
>
> [...]
>
>> Now you have a new topic to talk about :-)
>
> The infamous plaster cast of certain genitals (if it actually existed; 
> the cast I mean)?
>
> -- Dave
>


From athornton at gmail.com  Wed Sep 18 10:38:38 2019
From: athornton at gmail.com (Adam Thornton)
Date: Tue, 17 Sep 2019 17:38:38 -0700
Subject: [TUHS] PiDP-11 in action!
In-Reply-To: <CAC20D2Nzp-JoOC1qEQg4-b-K-uCuNwYKhqyvsAguZ4SQg-fSbg@mail.gmail.com>
References: <CAP2nic11x4sXEAdUJDeg_m_qs6bo41vnopgA_yGPkqcvEvSVSw@mail.gmail.com>
 <CAC20D2Nzp-JoOC1qEQg4-b-K-uCuNwYKhqyvsAguZ4SQg-fSbg@mail.gmail.com>
Message-ID: <CAP2nic3PemB=OVrJPS7veL0NuFAqkKBcAXM2q=MxJMg4SB5Q-Q@mail.gmail.com>

Busted EPROMs certainly would fit the symptoms.  What EPROM does a MicroVAX
3100 use, and does simh have the requisite binary image?  I've got a ROM
burner....

On Tue, Sep 17, 2019 at 7:28 AM Clem Cole <clemc at ccc.com> wrote:

> +1
> ᐧ
>
> On Mon, Sep 16, 2019 at 10:52 PM Adam Thornton <athornton at gmail.com>
> wrote:
>
>> https://share.icloud.com/photos/0MKJjk8pRBvkZAEzaobjfOyPQ
>>
>> I start v7 Unix and play "Hunt The Wumpus".
>>
>> (I finally got it put together this weekend, and fixed the last couple
>> dodgy joints tonight).
>>
>> Adam
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190917/fa378e62/attachment.html>

From athornton at gmail.com  Wed Sep 18 10:42:56 2019
From: athornton at gmail.com (Adam Thornton)
Date: Tue, 17 Sep 2019 17:42:56 -0700
Subject: [TUHS] earliest Unix roff
In-Reply-To: <201909171815.x8HIFfKS022066@freefriends.org>
References: <CAC20D2Nz-ofwD41vULF2-TL8-C33heCiHvoNNbcuj6GGKhtKzQ@mail.gmail.com>
 <20190913221345.GA16129@minnie.tuhs.org>
 <CAC20D2OQD-NJaFsqsLVL_kqmCsSeUOKAr7dm71P4uN9N8m+AbQ@mail.gmail.com>
 <20190914020240.GO2046@mcvoy.com> <20190914024433.GA19193@minnie.tuhs.org>
 <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org>
 <201909150654.x8F6sChG021185@freefriends.org>
 <CAC20D2PfLq=J5ei+izXb2J7dSvU6=L6-GRd0gKA2ShSNg1=qBg@mail.gmail.com>
 <201909160552.x8G5qBYK025195@freefriends.org>
 <CAC20D2N89jOBK+T9EPn8JKNaSOUx=yDr9t4=CcyHM+3qnB2bEg@mail.gmail.com>
 <20190916145122.GH2046@mcvoy.com>
 <201909170753.x8H7r8oT004491@freefriends.org>
 <CAFNqd5XKQu_gLy7BEYMeRY0QkoPXv64Y-1Od-TbbU-RTyHoSUA@mail.gmail.com>
 <201909171815.x8HIFfKS022066@freefriends.org>
Message-ID: <CAP2nic3H5iYWNmUbDqY9XN3vPo05YFUZW7Nye4YVSsks8fFAjQ@mail.gmail.com>

I always rather liked the IBM Bookmaster flavor of GML.  I wrote some
good-looking (and perhaps even useful) things in it.

Adam

On Tue, Sep 17, 2019 at 11:16 AM <arnold at skeeve.com> wrote:

> Hi.
>
> Christopher Browne <cbbrowne at gmail.com> wrote:
> > I had the other reaction to this...
> >
> > I have been managing my web presence via DocBook SGML for a goodly long
> > time.  It is, as mentioned upthread, pretty wordy what with all the
> verbose
> > tagging.
> >
> > It would be worth something to be able to edit it in TeXinfo form, with
> the
> > lesser amount of tagging required.  (And I'd kinda like to get off of
> > DocBook/SGML one of these days as the toolset is clearly mouldering away
> > pretty badly.)
>
> Looks like pandoc will go from DocBook to Texinfo.
>
> Me, I'd probably write a giant awk script to do the grunt work. :-)
>
> > For sophisticated material, TeXinfo is of use, notwithstanding notions to
> > make everything into brief man pages.
>
> As I've been saying, I use it for books.
>
> Good luck,
>
> Arnold
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190917/a15a8124/attachment.html>

From athornton at gmail.com  Wed Sep 18 10:47:40 2019
From: athornton at gmail.com (Adam Thornton)
Date: Tue, 17 Sep 2019 17:47:40 -0700
Subject: [TUHS] A Couple of New Unix Artifacts
In-Reply-To: <ce2287fa-e11e-c25a-9cc6-441a386be3f7@kilonet.net>
References: <20190917095435.GA16333@minnie.tuhs.org>
 <alpine.BSF.2.21.9999.1909180909020.18105@aneurin.horsfall.org>
 <ce2287fa-e11e-c25a-9cc6-441a386be3f7@kilonet.net>
Message-ID: <CAP2nic0Es7n2y=n6o39UD=+jCxT2-Uk0EyRaXNkxYs3CbHSFJg@mail.gmail.com>

We at Sine Nomine Associates read the entrails wrong.

We did a port of OpenSolaris to the zSeries architecture (although we
required z/VM; much like Linux, there's no point running it otherwise).  By
"we" I mean mostly Neale Ferguson for the heavy lifting and me for most of
the userland apps and toolchain stuff (although I did write most of the
disk device driver, which went through z/VM DIAGs rather than talking
directly to the hardware, but from the OpenSolaris perspective it was just
a device driver).

Both we and IBM thought IBM was going to buy Sun.  I'm sure that's why IBM
agreed to give us a couple extra DIAGs in z/VM to make the thing run a good
deal more efficiently.

And then IBM pushed too hard on price, apparently not knowing Sun was also
sitting on an offer from Larry Ellison.

My career would have been very different if that acquisition had happened.

Adam

On Tue, Sep 17, 2019 at 4:25 PM Arthur Krewat <krewat at kilonet.net> wrote:

> My wish list is:
>
> - Oracle (or some other licensee) coughed up SunOS. Legally.
> - AT&T or some other derivative coughed up SVR4(.2)
>
> Ok, that's all I got ;)
>
> But yes, I'm insane enough to want: Oracle coughing up Solaris 11.x(4?)
> - legally. And I don't mean OpenSolaris.
>
> BTW - I know a certain institution I know, I'm pretty sure used V6 for a
> graphics workstation. I'm pretty sure they had a source license, but I
> could be wrong. What's the reality when it came to V6 being used
> commercially in a product? This would be around the early 80's
> timeframe. And certain law enforcement agencies actually used at least
> one workstation for whatever reason.  It would have run on MIcro-11's,
> and MIcro-Vaxen.
>
>
> On 9/17/2019 7:12 PM, Dave Horsfall wrote:
> > On Tue, 17 Sep 2019, Warren Toomey wrote:
> >
> > [...]
> >
> >> Now you have a new topic to talk about :-)
> >
> > The infamous plaster cast of certain genitals (if it actually existed;
> > the cast I mean)?
> >
> > -- Dave
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190917/89ee2915/attachment.html>

From krewat at kilonet.net  Wed Sep 18 10:54:02 2019
From: krewat at kilonet.net (Arthur Krewat)
Date: Tue, 17 Sep 2019 20:54:02 -0400
Subject: [TUHS] A Couple of New Unix Artifacts
In-Reply-To: <CAP2nic0Es7n2y=n6o39UD=+jCxT2-Uk0EyRaXNkxYs3CbHSFJg@mail.gmail.com>
References: <20190917095435.GA16333@minnie.tuhs.org>
 <alpine.BSF.2.21.9999.1909180909020.18105@aneurin.horsfall.org>
 <ce2287fa-e11e-c25a-9cc6-441a386be3f7@kilonet.net>
 <CAP2nic0Es7n2y=n6o39UD=+jCxT2-Uk0EyRaXNkxYs3CbHSFJg@mail.gmail.com>
Message-ID: <e460d5ee-4ed1-d6bb-b5b2-cfefbc88dde7@kilonet.net>

On 9/17/2019 8:47 PM, Adam Thornton wrote:
>
> And then IBM pushed too hard on price, apparently not knowing Sun was 
> also sitting on an offer from Larry Ellison.
>
> My career would have been very different if that acquisition had happened.

Another factoid added to the gestalt in my head.


art k.



From athornton at gmail.com  Wed Sep 18 11:03:45 2019
From: athornton at gmail.com (Adam Thornton)
Date: Tue, 17 Sep 2019 18:03:45 -0700
Subject: [TUHS] A Couple of New Unix Artifacts
In-Reply-To: <e460d5ee-4ed1-d6bb-b5b2-cfefbc88dde7@kilonet.net>
References: <20190917095435.GA16333@minnie.tuhs.org>
 <alpine.BSF.2.21.9999.1909180909020.18105@aneurin.horsfall.org>
 <ce2287fa-e11e-c25a-9cc6-441a386be3f7@kilonet.net>
 <CAP2nic0Es7n2y=n6o39UD=+jCxT2-Uk0EyRaXNkxYs3CbHSFJg@mail.gmail.com>
 <e460d5ee-4ed1-d6bb-b5b2-cfefbc88dde7@kilonet.net>
Message-ID: <CAP2nic0ofR2DoTTg+19GQhc=XRvH+k2hPEHquHFipOgEG_Wgfg@mail.gmail.com>

Well, take it with a grain of salt.  I have no actual knowledge of what IBM
was attempting or what really happened.  But from where I sat the evidence
was pretty compelling: they wanted an OpenSolaris port enough to give us
some hypervisor changes we asked for (which certainly must have had
substantial engineering costs for them), and it was pretty clear to me at
the time that Sun was looking for a buyer and that IBM would be a natural
entity to buy them.

On Tue, Sep 17, 2019 at 5:54 PM Arthur Krewat <krewat at kilonet.net> wrote:

> On 9/17/2019 8:47 PM, Adam Thornton wrote:
> >
> > And then IBM pushed too hard on price, apparently not knowing Sun was
> > also sitting on an offer from Larry Ellison.
> >
> > My career would have been very different if that acquisition had
> happened.
>
> Another factoid added to the gestalt in my head.
>
>
> art k.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190917/232675d9/attachment.html>

From wlc at jctaylor.com  Wed Sep 18 11:40:52 2019
From: wlc at jctaylor.com (William Corcoran)
Date: Wed, 18 Sep 2019 01:40:52 +0000
Subject: [TUHS] cathode
Message-ID: <009D825B-EF35-4310-8008-48EEB2D34D4B@jctaylor.com>

Hello TUHS on Tues.,

Warren Toomey suggested I let the group know about a utility that exists at least for iMacs and IOS devices.  

It’s called “cathode” and you can find it on the Apple App Store.   Please forgive me if this has already been mentioned. 

This utility provides for an xterm window that looks like the display an old *tube.   You can set the curvature of the glass, the glow, various scan techniques, 9600 speed, and so on.   

It adds that extra dimension to give the look and feel of working on early UNIX with a tube. 

I would love to see profiles created that match actual ttys.  My favorite tube is the Wyse 50.   Another, one I remember is a Codex model with “slowopen” set in vi.  

Remember how early UNIX terminals behaved with slowopen, right?   The characters would overtype during insert mode in vi, but when you hit escape, the line you just clobbered reappears shifting the remaining text as appropriate to the right.

Cathode adds a little spice, albeit artificially, to the experience of early UNIX.

Truly,

Bill Corcoran

(*) For the uninitiated, we used to call the tty terminal a “tube.”   For example, you might hear my boss say, “Corcoran, that cheese you hacked yesterday launched a runaway that’s now soaking the client’s CPU.  Go jump on a free tube and fix it now!”


From lars at nocrew.org  Wed Sep 18 13:27:53 2019
From: lars at nocrew.org (Lars Brinkhoff)
Date: Wed, 18 Sep 2019 03:27:53 +0000
Subject: [TUHS] cathode
In-Reply-To: <009D825B-EF35-4310-8008-48EEB2D34D4B@jctaylor.com> (William
 Corcoran's message of "Wed, 18 Sep 2019 01:40:52 +0000")
References: <009D825B-EF35-4310-8008-48EEB2D34D4B@jctaylor.com>
Message-ID: <7wr24ejnba.fsf@junk.nocrew.org>

William Corcoran wrote:
> I would love to see profiles created that match actual ttys.

I would love it if they matched actual teletypes.  But that's for
another program.

From scj at yaccman.com  Wed Sep 18 14:47:47 2019
From: scj at yaccman.com (Steve Johnson)
Date: Tue, 17 Sep 2019 21:47:47 -0700
Subject: [TUHS] block operations in editors, was  My EuroBSDcon talk
In-Reply-To: <201909171731.x8HHVq2L096688@tahoe.cs.Dartmouth.EDU>
Message-ID: <2af4396e3f1133dfb93c2a92722e6f0e850ade55@webmail.yaccman.com>

This is one of my pet peeves.  "Random Access" memory is far from
random when you look at the time it takes to do the accesses.  With
modern memories, accessing a column can be 20 to 40x slower than
accessing a row.  This is particularly irritating when doing AI
training, where training reuses 4-d tensors transposed, a very painful
operation.

In FORTRAN days, I once used a vector package in which you described a
vector by giving the first element, the second element, and a count. 
So you could describe rows, columns, a matrix diagonal, and even rows
and columns from back to front.  Fortran passed arguments by address,
which made the whole thing easy and fast.

Steve

----- Original Message -----
From: "Doug McIlroy" <doug at cs.dartmouth.edu>
To:<tuhs at tuhs.org>, <jnc at mercury.lcs.mit.edu>
Cc:
Sent:Tue, 17 Sep 2019 13:31:52 -0400
Subject:Re: [TUHS] block operations in editors, was My EuroBSDcon talk

 Noel Chiappa wrote:

 > > From: Doug McIlroy
 >
 > > the absence of multidemensional arrays in C.
 >
 >?? From the 'C Reference Manual' (no date, but circa 'Typesetter
C'), pg. 11:
 >
 > "If the unadorned declarator D would specify an n-dimensional array
.. then
 > the declarator D[in+1] yields an (n+1)-dimensional array"
 >
 >
 >I'm not sure if I've _ever_ used one, but they are there.

 Yes, C allows arrays of arrays, and I've used them aplenty.
 However an "n-dimensional array" has one favored dimension,
 out of which you can slice an array of lower dimension. For
 example, you can pass a row of a 2D array to a function of a
 1D variable, but you can't pass a column. That asymmetry
 underlies my assertion. In Python, by contrast, n-dimensional
 arrays can be sliced on any dimension.

 Doug


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190917/f86a5b47/attachment.html>

From jon at fourwinds.com  Wed Sep 18 14:52:24 2019
From: jon at fourwinds.com (Jon Steinhart)
Date: Tue, 17 Sep 2019 21:52:24 -0700
Subject: [TUHS] block operations in editors, was My EuroBSDcon talk
In-Reply-To: <2af4396e3f1133dfb93c2a92722e6f0e850ade55@webmail.yaccman.com>
References: <2af4396e3f1133dfb93c2a92722e6f0e850ade55@webmail.yaccman.com>
Message-ID: <201909180452.x8I4qOiO002491@darkstar.fourwinds.com>

Steve Johnson writes:
> This is one of my pet peeves.  "Random Access" memory is far from random when
> you look at the time it takes to do the accesses.  With modern memories,
> accessing a column can be 20 to 40x slower than accessing a row.  This is
> particularly irritating when doing AI training, where training reuses 4-d
> tensors transposed, a very painful operation.
> 
> In FORTRAN days, I once used a vector package in which you described a vector
> by giving the first element, the second element, and a count.  So you could
> describe rows, columns, a matrix diagonal, and even rows and columns from back
> to front.  Fortran passed arguments by address, which made the whole thing easy
> and fast.
> 
> Steve

Remember the words of that great performance pioneer Jimmy Durante: ras-a-ma-cas.

From aap at papnet.eu  Wed Sep 18 18:31:33 2019
From: aap at papnet.eu (Angelo Papenhoff)
Date: Wed, 18 Sep 2019 10:31:33 +0200
Subject: [TUHS] cathode
In-Reply-To: <009D825B-EF35-4310-8008-48EEB2D34D4B@jctaylor.com>
References: <009D825B-EF35-4310-8008-48EEB2D34D4B@jctaylor.com>
Message-ID: <20190918083133.GA47585@indra.papnet.eu>

On 18/09/19, William Corcoran wrote:
> Hello TUHS on Tues.,
> 
> Warren Toomey suggested I let the group know about a utility that exists at least for iMacs and IOS devices.  
> 
> It’s called “cathode” and you can find it on the Apple App Store.   Please forgive me if this has already been mentioned. 
> 
> This utility provides for an xterm window that looks like the display an old *tube.   You can set the curvature of the glass, the glow, various scan techniques, 9600 speed, and so on.   

For the non-OS Xers there's cool-retro-term:
https://github.com/Swordfish90/cool-retro-term

Personally I think it could look more realistic. Looks like they went
for more of a movie-terminal look, but it's not easy to emulate a CRT
convincingly.

And I agree with Lars, I want cool-retro-asr33 (or 37)


aap

From tuhs at eric.allman.name  Wed Sep 18 18:48:26 2019
From: tuhs at eric.allman.name (Eric Allman)
Date: Wed, 18 Sep 2019 10:48:26 +0200
Subject: [TUHS] SCCS
In-Reply-To: <20190916172300.cjlkf%steffen@sdaoden.eu>
References: <20190911181101.GF3143@mcvoy.com>
 <alpine.BSF.2.21.9999.1909120846160.18105@aneurin.horsfall.org>
 <20190912034346.GJ2046@mcvoy.com>
 <a0231faa-8ad9-fa51-4b24-9854beb21210@gmail.com>
 <1457a2d6-2f17-482d-e4f7-ace439d34ca8@neophilic.com>
 <CAC20D2OZpnma4EX+PqgqfA7zNM7sofuDQ4zCURnLF7-G4TCKhQ@mail.gmail.com>
 <8db2e89c-ce50-a453-e38a-ecdfe69a746c@e-bbes.com>
 <20190913211104.aMZXy%steffen@sdaoden.eu> <20190913211751.GF2046@mcvoy.com>
 <20190913230312.XaeCQ%steffen@sdaoden.eu> <20190914015517.GD12480@mcvoy.com>
 <20190916172300.cjlkf%steffen@sdaoden.eu>
Message-ID: <94341a28-723a-f177-f658-0c827b35591b@neophilic.com>

On 2019-09-16 19:23 , Steffen Nurpmeso wrote:
> One thing he says, and which is an interesting part of this
> thread, is
> 
>   The statement of Eric Allman that Tichy used SCCS version
>   1 i cannot believe, because Tichy's releases are from 1982, and
>   SCCS version 4 was released as earyl as February 1977.  SCCS
>   version 3 used a binary history format, by the way.
> 
> That should have addressed Eric Allman, but the longer i use email
> in the public space the more i like that pub-like feeling.  (And
> not going to add that it reminds me of my childhood, where i was
> a boy under elder seasoned men _also_.)

I did not claim that Tichy used SCCS v1.  It's worse than that.  He only
read the IEEE paper, which pre-dated RCS --- so far as I know he never
even tried SCCS release 4 (current at the time Tichy published), which
fixed the obvious problem in the release 1 design as originally
published.  Despite careful descriptions of the changes, he refused to
stop slandering SCCS.  He was truly standing on toes, not shoulders.

eric

From akosela at andykosela.com  Wed Sep 18 19:05:54 2019
From: akosela at andykosela.com (Andy Kosela)
Date: Wed, 18 Sep 2019 11:05:54 +0200
Subject: [TUHS] cathode
In-Reply-To: <009D825B-EF35-4310-8008-48EEB2D34D4B@jctaylor.com>
References: <009D825B-EF35-4310-8008-48EEB2D34D4B@jctaylor.com>
Message-ID: <CALMnNGjthv_esjQNcN3M5ygGatLrUqLOGCK6a2xRQBrQAfLWQA@mail.gmail.com>

On 9/18/19, William Corcoran <wlc at jctaylor.com> wrote:
> Hello TUHS on Tues.,
>
> Warren Toomey suggested I let the group know about a utility that exists at
> least for iMacs and IOS devices.
>
> It’s called “cathode” and you can find it on the Apple App Store.   Please
> forgive me if this has already been mentioned.
>
> This utility provides for an xterm window that looks like the display an old
> *tube.   You can set the curvature of the glass, the glow, various scan
> techniques, 9600 speed, and so on.
>
> It adds that extra dimension to give the look and feel of working on early
> UNIX with a tube.

I used to run it, but I noticed it sucks battery like crazy.  In the
end I compromised on running X with good ol xterm on my MacBook.  It
is much more lightweight.

Plus it is impossible to create a realistic CRT experience on LCD,
especially in widescreen.  All terminals were 4:3 and rather small
from today point of view, but the sizes were just perfect for full
screen text modes.

I have tons of old terminals and CRT VGA monitors just so I can work
on a real thing.  There is something magical about the glow of
phosphor on those old tubes.

--Andy

From wobblygong at gmail.com  Wed Sep 18 19:06:54 2019
From: wobblygong at gmail.com (Wesley Parish)
Date: Wed, 18 Sep 2019 21:06:54 +1200
Subject: [TUHS] A Couple of New Unix Artifacts
In-Reply-To: <ce2287fa-e11e-c25a-9cc6-441a386be3f7@kilonet.net>
References: <20190917095435.GA16333@minnie.tuhs.org>
 <alpine.BSF.2.21.9999.1909180909020.18105@aneurin.horsfall.org>
 <ce2287fa-e11e-c25a-9cc6-441a386be3f7@kilonet.net>
Message-ID: <CACNPpebCXXC2z2P_dk-=q26HHcTLDiaif0gEGpYVOXS1HadM5Q@mail.gmail.com>

These are parts of my wish list:

Larry McVoy's Sourceware tape is discovered;
IBM donates the source and binaries for its obsolete Unixes;
HP donates the source and binaries of the Intel port of Unixware;
some of the late eighties/early nineties Unix CAD software gets donated.

Dreams are free, of course. I'm not holding my breath ... :)

Wesley Parish

On 9/18/19, Arthur Krewat <krewat at kilonet.net> wrote:
> My wish list is:
>
> - Oracle (or some other licensee) coughed up SunOS. Legally.
> - AT&T or some other derivative coughed up SVR4(.2)
>
> Ok, that's all I got ;)
>
> But yes, I'm insane enough to want: Oracle coughing up Solaris 11.x(4?)
> - legally. And I don't mean OpenSolaris.
>
> BTW - I know a certain institution I know, I'm pretty sure used V6 for a
> graphics workstation. I'm pretty sure they had a source license, but I
> could be wrong. What's the reality when it came to V6 being used
> commercially in a product? This would be around the early 80's
> timeframe. And certain law enforcement agencies actually used at least
> one workstation for whatever reason.  It would have run on MIcro-11's,
> and MIcro-Vaxen.
>
>
> On 9/17/2019 7:12 PM, Dave Horsfall wrote:
>> On Tue, 17 Sep 2019, Warren Toomey wrote:
>>
>> [...]
>>
>>> Now you have a new topic to talk about :-)
>>
>> The infamous plaster cast of certain genitals (if it actually existed;
>> the cast I mean)?
>>
>> -- Dave
>>
>
>

From usotsuki at buric.co  Wed Sep 18 19:12:38 2019
From: usotsuki at buric.co (Steve Nickolas)
Date: Wed, 18 Sep 2019 05:12:38 -0400 (EDT)
Subject: [TUHS] cathode
In-Reply-To: <CALMnNGjthv_esjQNcN3M5ygGatLrUqLOGCK6a2xRQBrQAfLWQA@mail.gmail.com>
References: <009D825B-EF35-4310-8008-48EEB2D34D4B@jctaylor.com>
 <CALMnNGjthv_esjQNcN3M5ygGatLrUqLOGCK6a2xRQBrQAfLWQA@mail.gmail.com>
Message-ID: <alpine.BSF.2.02.1909180510480.69681@frieza.hoshinet.org>

On Wed, 18 Sep 2019, Andy Kosela wrote:

> Plus it is impossible to create a realistic CRT experience on LCD,
> especially in widescreen.  All terminals were 4:3 and rather small
> from today point of view, but the sizes were just perfect for full
> screen text modes.
>
> I have tons of old terminals and CRT VGA monitors just so I can work
> on a real thing.  There is something magical about the glow of
> phosphor on those old tubes.

Nothing like the real thing.  Man, I'd kill for another 5151 monitor (and 
something to use it with).

Second to that I'd settle for an Apple monochrome display (either the 
Monitor ][ or the Monitor ///).

-uso.

From emu at e-bbes.com  Wed Sep 18 18:49:03 2019
From: emu at e-bbes.com (emanuel stiebler)
Date: Wed, 18 Sep 2019 10:49:03 +0200
Subject: [TUHS] PiDP-11 in action!
In-Reply-To: <CAP2nic3PemB=OVrJPS7veL0NuFAqkKBcAXM2q=MxJMg4SB5Q-Q@mail.gmail.com>
References: <CAP2nic11x4sXEAdUJDeg_m_qs6bo41vnopgA_yGPkqcvEvSVSw@mail.gmail.com>
 <CAC20D2Nzp-JoOC1qEQg4-b-K-uCuNwYKhqyvsAguZ4SQg-fSbg@mail.gmail.com>
 <CAP2nic3PemB=OVrJPS7veL0NuFAqkKBcAXM2q=MxJMg4SB5Q-Q@mail.gmail.com>
Message-ID: <9999dcdf-34dd-2ad7-dfe0-d6cb0825b05b@e-bbes.com>

On 2019-09-18 02:38, Adam Thornton wrote:
> Busted EPROMs certainly would fit the symptoms.  What EPROM does a
> MicroVAX 3100 use, and does simh have the requisite binary image?  I've
> got a ROM burner....

Which model? Look at the label in the back ...

From hpyle at cabezal.com  Wed Sep 18 20:24:20 2019
From: hpyle at cabezal.com (Hugh Pyle)
Date: Wed, 18 Sep 2019 06:24:20 -0400
Subject: [TUHS] cathode
In-Reply-To: <20190918083133.GA47585@indra.papnet.eu>
References: <009D825B-EF35-4310-8008-48EEB2D34D4B@jctaylor.com>
 <20190918083133.GA47585@indra.papnet.eu>
Message-ID: <CALvn94J2_ijDdVLcGQNjwONTNb0Wb2WPo0NUJoqFrfQoLNyJ6g@mail.gmail.com>

> And I agree with Lars, I want cool-retro-asr33 (or 37)

There's a nice 33 emulator here, with 10cps speed, overstrike, and other
features
https://github.com/Random832/ttyemu

If you have the Teletype fonts installed, use my fork
https://github.com/hughpyle/ttyemu
Sound and smell are not yet implemented.



>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190918/36edd3f3/attachment.html>

From clemc at ccc.com  Thu Sep 19 00:01:07 2019
From: clemc at ccc.com (Clem Cole)
Date: Wed, 18 Sep 2019 10:01:07 -0400
Subject: [TUHS] cathode
In-Reply-To: <7wr24ejnba.fsf@junk.nocrew.org>
References: <009D825B-EF35-4310-8008-48EEB2D34D4B@jctaylor.com>
 <7wr24ejnba.fsf@junk.nocrew.org>
Message-ID: <CAC20D2N8sKS834SerOXhYHHiSe7RLQBi1BW-9t50vHe9MCxo9g@mail.gmail.com>

Lars, I agree but, you can't get the distinct smell of machine oil without
something like  'smell-a-vision
<https://en.wikipedia.org/wiki/Smell-O-Vision>'

Bill, I've had Cathode since it first released it to try to demonstrate to
some the younger set a little what it was like.  I set up a Wyse-60, an H19
and my Mac running Cathode and let them play on a my simh based PiDP-11
running v6.

Clem

On Tue, Sep 17, 2019 at 11:28 PM Lars Brinkhoff <lars at nocrew.org> wrote:

> William Corcoran wrote:
> > I would love to see profiles created that match actual ttys.
>
> I would love it if they matched actual teletypes.  But that's for
> another program.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190918/4b72a086/attachment.html>

From lm at mcvoy.com  Thu Sep 19 00:40:12 2019
From: lm at mcvoy.com (Larry McVoy)
Date: Wed, 18 Sep 2019 07:40:12 -0700
Subject: [TUHS] A Couple of New Unix Artifacts
In-Reply-To: <CACNPpebCXXC2z2P_dk-=q26HHcTLDiaif0gEGpYVOXS1HadM5Q@mail.gmail.com>
References: <20190917095435.GA16333@minnie.tuhs.org>
 <alpine.BSF.2.21.9999.1909180909020.18105@aneurin.horsfall.org>
 <ce2287fa-e11e-c25a-9cc6-441a386be3f7@kilonet.net>
 <CACNPpebCXXC2z2P_dk-=q26HHcTLDiaif0gEGpYVOXS1HadM5Q@mail.gmail.com>
Message-ID: <20190918144012.GV2046@mcvoy.com>

On Wed, Sep 18, 2019 at 09:06:54PM +1200, Wesley Parish wrote:
> These are parts of my wish list:
> 
> Larry McVoy's Sourceware tape is discovered;

That's unlikely to happen, I didn't keep a copy when it became clear
that Sun wasn't going to do it.  It would not be that hard to recreate
it if SunOS 4.x were released.  As I recall, it was

A) Remove the STREAMS stuff.
B) Go find the BSD tty driver and put it back.
C) Remove RFS.
D) Maybe a syscall or two that were there for RFS.

From paul.winalski at gmail.com  Thu Sep 19 01:35:37 2019
From: paul.winalski at gmail.com (Paul Winalski)
Date: Wed, 18 Sep 2019 11:35:37 -0400
Subject: [TUHS] cathode
In-Reply-To: <009D825B-EF35-4310-8008-48EEB2D34D4B@jctaylor.com>
References: <009D825B-EF35-4310-8008-48EEB2D34D4B@jctaylor.com>
Message-ID: <CABH=_VRjBwPAS+XxoXMqXVCUFY1ELdQtW=jJVvK5yrTLz8dusQ@mail.gmail.com>

On 9/17/19, William Corcoran <wlc at jctaylor.com> wrote:
>
> I would love to see profiles created that match actual ttys.

Can they duplicate that distinctive "raspberry" sound that the VT52
had for its bell?

-Paul W.

From athornton at gmail.com  Thu Sep 19 01:39:11 2019
From: athornton at gmail.com (Adam Thornton)
Date: Wed, 18 Sep 2019 08:39:11 -0700
Subject: [TUHS] PiDP-11 in action!
In-Reply-To: <9999dcdf-34dd-2ad7-dfe0-d6cb0825b05b@e-bbes.com>
References: <CAP2nic11x4sXEAdUJDeg_m_qs6bo41vnopgA_yGPkqcvEvSVSw@mail.gmail.com>
 <CAC20D2Nzp-JoOC1qEQg4-b-K-uCuNwYKhqyvsAguZ4SQg-fSbg@mail.gmail.com>
 <CAP2nic3PemB=OVrJPS7veL0NuFAqkKBcAXM2q=MxJMg4SB5Q-Q@mail.gmail.com>
 <9999dcdf-34dd-2ad7-dfe0-d6cb0825b05b@e-bbes.com>
Message-ID: <FC326F0E-B54B-4999-BF0A-CD262E478F15@gmail.com>



> On Sep 18, 2019, at 1:49 AM, emanuel stiebler <emu at e-bbes.com> wrote:
> 
> On 2019-09-18 02:38, Adam Thornton wrote:
>> Busted EPROMs certainly would fit the symptoms.  What EPROM does a
>> MicroVAX 3100 use, and does simh have the requisite binary image?  I've
>> got a ROM burner....
> 
> Which model? Look at the label in the back ...

VS43A-BD

Adam

From athornton at gmail.com  Thu Sep 19 01:45:11 2019
From: athornton at gmail.com (Adam Thornton)
Date: Wed, 18 Sep 2019 08:45:11 -0700
Subject: [TUHS] cathode
In-Reply-To: <CALMnNGjthv_esjQNcN3M5ygGatLrUqLOGCK6a2xRQBrQAfLWQA@mail.gmail.com>
References: <009D825B-EF35-4310-8008-48EEB2D34D4B@jctaylor.com>
 <CALMnNGjthv_esjQNcN3M5ygGatLrUqLOGCK6a2xRQBrQAfLWQA@mail.gmail.com>
Message-ID: <9F4B368B-EA41-4E8D-879A-1CB8181D615F@gmail.com>



> On Sep 18, 2019, at 2:05 AM, Andy Kosela <akosela at andykosela.com> wrote:
> I used to run it, but I noticed it sucks battery like crazy.  In the
> end I compromised on running X with good ol xterm on my MacBook.  It
> is much more lightweight.


I’m a big fan of iTerm2 (if I don’t need X).  It doesn’t do any CRT emulation stuff, but it’s very configurable, Python-scriptable, has built-in tmux, very configurable mouse and wheel support, decent contextual highlighting, et cetera.

Adam 

From web at loomcom.com  Thu Sep 19 02:33:37 2019
From: web at loomcom.com (Seth Morabito)
Date: Wed, 18 Sep 2019 09:33:37 -0700
Subject: [TUHS] A Couple of New Unix Artifacts
In-Reply-To: <20190917095435.GA16333@minnie.tuhs.org>
References: <20190917095435.GA16333@minnie.tuhs.org>
Message-ID: <a920df41-f33d-4a28-abc7-259f75f08baa@www.fastmail.com>



On Tue, Sep 17, 2019, at 2:54 AM, Warren Toomey wrote:
>
> and I am going slowly crazy as I wait for them to be offically released.
>

And you just had to share the pain, eh? :^)

I look forward to the announcements with bated breath! I do secretly hope one is related to System V, since I've been working with SVR2/3/4 in such a grey area for so long, but I will be glad to see them no matter what they are.

-Seth
-- 
  Seth Morabito
  Poulsbo, WA
  web at loomcom.com

From steffen at sdaoden.eu  Thu Sep 19 03:33:18 2019
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Wed, 18 Sep 2019 19:33:18 +0200
Subject: [TUHS] SCCS
In-Reply-To: <94341a28-723a-f177-f658-0c827b35591b@neophilic.com>
References: <20190911181101.GF3143@mcvoy.com>
 <alpine.BSF.2.21.9999.1909120846160.18105@aneurin.horsfall.org>
 <20190912034346.GJ2046@mcvoy.com>
 <a0231faa-8ad9-fa51-4b24-9854beb21210@gmail.com>
 <1457a2d6-2f17-482d-e4f7-ace439d34ca8@neophilic.com>
 <CAC20D2OZpnma4EX+PqgqfA7zNM7sofuDQ4zCURnLF7-G4TCKhQ@mail.gmail.com>
 <8db2e89c-ce50-a453-e38a-ecdfe69a746c@e-bbes.com>
 <20190913211104.aMZXy%steffen@sdaoden.eu> <20190913211751.GF2046@mcvoy.com>
 <20190913230312.XaeCQ%steffen@sdaoden.eu> <20190914015517.GD12480@mcvoy.com>
 <20190916172300.cjlkf%steffen@sdaoden.eu>
 <94341a28-723a-f177-f658-0c827b35591b@neophilic.com>
Message-ID: <20190918173318.o9sxO%steffen@sdaoden.eu>

Eric Allman wrote in <94341a28-723a-f177-f658-0c827b35591b at neophilic.com>:
 |On 2019-09-16 19:23 , Steffen Nurpmeso wrote:
 |> One thing he says, and which is an interesting part of this
 |> thread, is
 |> 
 |>   The statement of Eric Allman that Tichy used SCCS version
 |>   1 i cannot believe, because Tichy's releases are from 1982, and
 |>   SCCS version 4 was released as earyl as February 1977.  SCCS
 |>   version 3 used a binary history format, by the way.
 |> 
 |> That should have addressed Eric Allman, but the longer i use email
 |> in the public space the more i like that pub-like feeling.  (And
 |> not going to add that it reminds me of my childhood, where i was
 |> a boy under elder seasoned men _also_.)
 |
 |I did not claim that Tichy used SCCS v1.  It's worse than that.  He only
 |read the IEEE paper, which pre-dated RCS --- so far as I know he never
 |even tried SCCS release 4 (current at the time Tichy published), which
 |fixed the obvious problem in the release 1 design as originally
 |published.  Despite careful descriptions of the changes, he refused to
 |stop slandering SCCS.  He was truly standing on toes, not shoulders.

Thank you.  I will forward your response to Jörg.

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

From a.phillip.garcia at gmail.com  Thu Sep 19 07:17:29 2019
From: a.phillip.garcia at gmail.com (A. P. Garcia)
Date: Wed, 18 Sep 2019 17:17:29 -0400
Subject: [TUHS] A Couple of New Unix Artifacts
In-Reply-To: <a920df41-f33d-4a28-abc7-259f75f08baa@www.fastmail.com>
References: <20190917095435.GA16333@minnie.tuhs.org>
 <a920df41-f33d-4a28-abc7-259f75f08baa@www.fastmail.com>
Message-ID: <CAFCBnZvyW5WH3ybuvwFJsRJByG_mOtzev4mnAcFh_XsBy_r0aw@mail.gmail.com>

On Wed, Sep 18, 2019 at 12:41 PM Seth Morabito <web at loomcom.com> wrote:
>
>
>
> On Tue, Sep 17, 2019, at 2:54 AM, Warren Toomey wrote:
> >
> > and I am going slowly crazy as I wait for them to be offically released.
> >
>
> And you just had to share the pain, eh? :^)
>
> I look forward to the announcements with bated breath! I do secretly hope one is related to System V, since I've been working with SVR2/3/4 in such a grey area for so long, but I will be glad to see them no matter what they are.
>
> -Seth
> --
>   Seth Morabito
>   Poulsbo, WA
>   web at loomcom.com

It's not what I was expecting, and probably not what Warren was
referring to, but Microsoft open sourced their C++ Standard Library. I
would say that's nontrivial, at least.

https://github.com/microsoft/STL

From sergioag at qmailhosting.net  Thu Sep 19 09:05:32 2019
From: sergioag at qmailhosting.net (Sergio Aguayo)
Date: Thu, 19 Sep 2019 01:05:32 +0200 (CEST)
Subject: [TUHS] A Couple of New Unix Artifacts
In-Reply-To: <20190917095435.GA16333@minnie.tuhs.org>
References: <20190917095435.GA16333@minnie.tuhs.org>
Message-ID: <1045827859.49123.1568847932946.JavaMail.zimbra@qmailhosting.net>

May I ask about the definition of "soon"? 


From: "Warren Toomey" <wkt at tuhs.org> 
To: tuhs at tuhs.org 
Sent: Tuesday, September 17, 2019 4:54:35 AM 
Subject: [TUHS] A Couple of New Unix Artifacts 

I fear we're drifting a bit here and the S/N ratio is dropping a bit w.r.t 
the actual history of Unix. Please no more on the relative merits of 
version control systems or alternative text processing systems. 

So I'll try to distract you by saying this. I'm sitting on two artifacts 
that have recently been given to me: 

+ by two large organisations 
+ of great significance to Unix history 
+ who want me to keep "mum" about them 
+ as they are going to make announcements about them soon * 

and I am going slowly crazy as I wait for them to be offically released. 

Now you have a new topic to talk about :-) 

Cheers, Warren 

* for some definition of "soon" 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190919/2cee84d3/attachment.html>

From wkt at tuhs.org  Thu Sep 19 09:25:41 2019
From: wkt at tuhs.org (Warren Toomey)
Date: Thu, 19 Sep 2019 09:25:41 +1000
Subject: [TUHS] A Couple of New Unix Artifacts
In-Reply-To: <1045827859.49123.1568847932946.JavaMail.zimbra@qmailhosting.net>
References: <20190917095435.GA16333@minnie.tuhs.org>
 <1045827859.49123.1568847932946.JavaMail.zimbra@qmailhosting.net>
Message-ID: <20190918232541.GA8434@minnie.tuhs.org>

On Thu, Sep 19, 2019 at 01:05:32AM +0200, Sergio Aguayo via TUHS wrote:
>    May I ask about the definition of "soon"?

Yes, I asked that question too :-)

The answer is to coincide with the Unix 50th anniversary
events that are scheduled for this year.

	Warren

From nw at retrocomputingtasmania.com  Thu Sep 19 10:42:14 2019
From: nw at retrocomputingtasmania.com (Nigel Williams)
Date: Thu, 19 Sep 2019 10:42:14 +1000
Subject: [TUHS] A Couple of New Unix Artifacts
In-Reply-To: <20190918232541.GA8434@minnie.tuhs.org>
References: <20190917095435.GA16333@minnie.tuhs.org>
 <1045827859.49123.1568847932946.JavaMail.zimbra@qmailhosting.net>
 <20190918232541.GA8434@minnie.tuhs.org>
Message-ID: <CACCFpdysLPginPKQKnCU6MeAoGdQexbE6DhegR_myh-8qqWwOQ@mail.gmail.com>

IBM open-sourcing AIX?
Apple releases A/UX source?

Personally I would like PRIMIX (UNIX overlay for PRIMOS) to be found,
but I appreciate that is the narrowest of niches :-)

From gregg.drwho8 at gmail.com  Thu Sep 19 11:35:21 2019
From: gregg.drwho8 at gmail.com (Gregg Levine)
Date: Wed, 18 Sep 2019 21:35:21 -0400
Subject: [TUHS] A Couple of New Unix Artifacts
In-Reply-To: <CACCFpdysLPginPKQKnCU6MeAoGdQexbE6DhegR_myh-8qqWwOQ@mail.gmail.com>
References: <20190917095435.GA16333@minnie.tuhs.org>
 <1045827859.49123.1568847932946.JavaMail.zimbra@qmailhosting.net>
 <20190918232541.GA8434@minnie.tuhs.org>
 <CACCFpdysLPginPKQKnCU6MeAoGdQexbE6DhegR_myh-8qqWwOQ@mail.gmail.com>
Message-ID: <CAC5iaNF9sv7ygjqiQZPPHMfQH3VVBKkvBHDSFO6CYknHSkjgmQ@mail.gmail.com>

Hello!
I'll add to that. The entire set of XENIX stuff. And a release of the
SunOs stuff.,

But let us be patient. Warren will advise us when the time comes.
-----
Gregg C Levine gregg.drwho8 at gmail.com
"This signature fought the Time Wars, time and again."

On Wed, Sep 18, 2019 at 8:43 PM Nigel Williams
<nw at retrocomputingtasmania.com> wrote:
>
> IBM open-sourcing AIX?
> Apple releases A/UX source?
>
> Personally I would like PRIMIX (UNIX overlay for PRIMOS) to be found,
> but I appreciate that is the narrowest of niches :-)

From lars at nocrew.org  Thu Sep 19 15:06:02 2019
From: lars at nocrew.org (Lars Brinkhoff)
Date: Thu, 19 Sep 2019 05:06:02 +0000
Subject: [TUHS] A Couple of New Unix Artifacts
In-Reply-To: <CAC5iaNF9sv7ygjqiQZPPHMfQH3VVBKkvBHDSFO6CYknHSkjgmQ@mail.gmail.com>
 (Gregg Levine's message of "Wed, 18 Sep 2019 21:35:21 -0400")
References: <20190917095435.GA16333@minnie.tuhs.org>
 <1045827859.49123.1568847932946.JavaMail.zimbra@qmailhosting.net>
 <20190918232541.GA8434@minnie.tuhs.org>
 <CACCFpdysLPginPKQKnCU6MeAoGdQexbE6DhegR_myh-8qqWwOQ@mail.gmail.com>
 <CAC5iaNF9sv7ygjqiQZPPHMfQH3VVBKkvBHDSFO6CYknHSkjgmQ@mail.gmail.com>
Message-ID: <7w4l18j2o5.fsf@junk.nocrew.org>

Is this the place to send Christmas wish lists?
I would like to see Space Travel.  There's a PDP-7 ready to do.

From norman at oclsc.org  Fri Sep 20 04:10:45 2019
From: norman at oclsc.org (Norman Wilson)
Date: Thu, 19 Sep 2019 14:10:45 -0400
Subject: [TUHS] earliest Unix roff
Message-ID: <1568916649.17313.for-standards-violators@oclsc.org>

Larry McVoy:

  If you have something like perl that needs a zillion sub pages, info
  makes sense.  For just a man page, info is horrible.

=====

This pokes me in one of my longest-standing complaints:

Manual entries, as printed by man and once upon a time in
the Programmers' Manual Volume 1, should be concise references.
They are not a place for tutorials or long-winded descriptions
or even long lists of hundreds of options (let alone descriptions
of why the developer thinks this is the neatest thing since
sliced bread and what bread he had in his sandwiches that day).

For many programs, one or two pages of concise reference is
all the documentation that's needed; no one needs a ten-page
tutorial on how to use cat or rm or ls, for example.  But some
programs really do deserve a longer treatment, either a tutorial
or an extended reference with more detail or both.  Those belong
in separate documents, and are why the Programmers' Manual had
a second volume.

Nowadays people think nothing of writing 68-page-long manual
entries (real example from something I'm working with right now)
that are long, chatty lists of options or configuration-file
directives with tutorial information interspersed.  The result
makes the developer feel good--look at all the documentation
I've written!!--but it's useless for someone trying to figure
out how to write a configuration file for the first time, and
not so great even for someone trying to edit an existing one.

Even the Research system didn't always get this right; some
manual entries ran on and on and on when what was really
needed was a concise list of something and a longer accompanying
document.  (The Tenth Edition manual was much better about
that, mostly because of all the work Doug put in.  I doubt
there has ever been a better editor for technical text than
Doug.)  But it's far worse now in most systems, because
there's rarely any editor at all; the manuals are just an
accreted clump.

And that's a shame, though I have no suggestions on how
to fix it.

Norman Wilson
Toronto ON

From clemc at ccc.com  Fri Sep 20 04:37:05 2019
From: clemc at ccc.com (Clem Cole)
Date: Thu, 19 Sep 2019 14:37:05 -0400
Subject: [TUHS] earliest Unix roff
In-Reply-To: <1568916649.17313.for-standards-violators@oclsc.org>
References: <1568916649.17313.for-standards-violators@oclsc.org>
Message-ID: <CAC20D2ONt_YrX5mboLQfVOa2vSEyn72PiHwRd0qkUWavc=5odQ@mail.gmail.com>

On Thu, Sep 19, 2019 at 2:11 PM Norman Wilson <norman at oclsc.org> wrote:

> Manual entries, as printed by man and once upon a time in
> the Programmers' Manual Volume 1, should be concise references.
> They are not a place for tutorials or long-winded descriptions
> or even long lists of hundreds of options (let alone descriptions
> of why the developer thinks this is the neatest thing since
> sliced bread and what bread he had in his sandwiches that day).
>
> For many programs, one or two pages of concise reference is
> all the documentation that's needed; no one needs a ten-page
> tutorial on how to use cat or rm or ls, for example.  But some
> programs really do deserve a longer treatment, either a tutorial
> or an extended reference with more detail or both.  Those belong
> in separate documents, and are why the Programmers' Manual had
> a second volume.
>
> Nowadays people think nothing of writing 68-page-long manual
> entries (real example from something I'm working with right now)
> that are long, chatty lists of options or configuration-file
> directives with tutorial information interspersed.  The result
> makes the developer feel good--look at all the documentation
> I've written!!--but it's useless for someone trying to figure
> out how to write a configuration file for the first time, and
> not so great even for someone trying to edit an existing one.
>
> Even the Research system didn't always get this right; some
> manual entries ran on and on and on when what was really
> needed was a concise list of something and a longer accompanying
> document.  (The Tenth Edition manual was much better about
> that, mostly because of all the work Doug put in.  I doubt
> there has ever been a better editor for technical text than
> Doug.)  But it's far worse now in most systems, because
> there's rarely any editor at all; the manuals are just an
> accreted clump.
>
> And that's a shame, though I have no suggestions on how
> to fix it.
>
> +1
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190919/0560aa4e/attachment.html>

From norman at oclsc.org  Fri Sep 20 04:42:58 2019
From: norman at oclsc.org (Norman Wilson)
Date: Thu, 19 Sep 2019 14:42:58 -0400
Subject: [TUHS] earliest Unix roff
Message-ID: <1568918582.18253.for-standards-violators@oclsc.org>

Clem Cole:

  Exactly!!!!   That's what Eric did when he wrote more(ucb) -  he *added to
  Unix*.   The funny part was that USG thought more(ucb) was a good idea and
  then wrote their own, pg(att); which was just as arrogant as the info
  behavior from the Gnu folks!!!

======

And others wrote their own too, of course.  The one I know
best is p(1), written by Rob Pike in the late 1970s at the
University of Toronto.  I encountered at Caltech on the
system Rob had set up before leaving for Bell Labs (and
which I cared for and hacked on for the next four years
before following him).  By the time I reached BTL it was
a normal part of the Research system; I believe it's in
all of the Eighth, Ninth, and Tenth Edition manuals.

p is interesting because it's so much lighter-weight, and
because it has rather a different interior design:

Rather than doing termcappy things, p just prints 22 lines
(or the number specified in an option), then doesn't print
the newline after the 22nd line.  Hit return and it will
print the next 22 lines, and so on.  The resulting text just
flows up the glass-tty screen without any fuss, cbreak, or
anything.  (I believe the first version predated V7 and
therefore cbreak.)

Why 22 lines instead of 24, the common height of glass ttys
back then?  Partly because that means you keep a line or two
of context when advancing pages, making reading simpler.
But also because in those days, a standard page destined for
a printer (e.g. from pr or nroff, and therefore from man) was
66 lines long.  22 evenly divides 66, so man something | p
never gives you a screen spanning pages.

p was able to back up: type - (and return) instead of just
return, and it reprints the previous 22-line page; -- (return)
the 22 lines before that; and so on.  This was implemented
in an interesting and clever way: a wrapper around the standard
I/O library which kept a circular buffer of some fixed number
of characters (8KiB in early versions, I think), and a new
call that, in effect, backed up the file pointer by one character
and returned the character just backed over.  That made it easy
to back over the previous N lines: just make that call until
you've seen N newlines, then discard the newline you've just
backed over, and you're at the beginning the first line you want
to reprint.

As I vaguely recall, more was able to back up, but only when
reading from a real file, not a pipeline.  p could do (limited
but sufficient) backup from a pipeline too.

As a creature of its pre-window-system era, you could also type
!command when p paused as well.

I remember being quite interested in that wrapper as a
possible library for use in other things, though I never
found a use for it.

I also remember a wonderful Elements-of-Programming-Style
adventure with Rob's code.  I discovered it had a bug under some
specific case when read returned less than a full bufferful.
I read the code carefully and couldn't see what was wrong.
So I wrote my own replacement for the problematic subroutine
from scratch, tested it carefully in corner cases, then with
listings of Rob's code and mine side-by-side walked through
each with the problem case and found the bug.

I still carry my own version of p (rewritten from scratch mainly
to make it more portable--Rob's code was old enough to be too
clever in some details) wherever I go; ironically, even back to
U of T where I have been on and off for the past 30 years.
more and less and pg and the like are certainly useful programs;
for various reasons they're not to my taste, but I don't scorn
them.  But I can't help being particular fond of p because it
taught me a few things about programming too.

Norman Wilson
Toronto ON

From jon at fourwinds.com  Fri Sep 20 04:44:34 2019
From: jon at fourwinds.com (Jon Steinhart)
Date: Thu, 19 Sep 2019 11:44:34 -0700
Subject: [TUHS] earliest Unix roff
In-Reply-To: <CAC20D2ONt_YrX5mboLQfVOa2vSEyn72PiHwRd0qkUWavc=5odQ@mail.gmail.com>
References: <1568916649.17313.for-standards-violators@oclsc.org>
 <CAC20D2ONt_YrX5mboLQfVOa2vSEyn72PiHwRd0qkUWavc=5odQ@mail.gmail.com>
Message-ID: <201909191844.x8JIiYoP018979@darkstar.fourwinds.com>

Clem Cole writes:
>
> On Thu, Sep 19, 2019 at 2:11 PM Norman Wilson <norman at oclsc.org> wrote:
>
> > Manual entries, as printed by man and once upon a time in
> > the Programmers' Manual Volume 1, should be concise references.
> > They are not a place for tutorials or long-winded descriptions
> > or even long lists of hundreds of options (let alone descriptions
> > of why the developer thinks this is the neatest thing since
> > sliced bread and what bread he had in his sandwiches that day).
> >
> > For many programs, one or two pages of concise reference is
> > all the documentation that's needed; no one needs a ten-page
> > tutorial on how to use cat or rm or ls, for example.  But some
> > programs really do deserve a longer treatment, either a tutorial
> > or an extended reference with more detail or both.  Those belong
> > in separate documents, and are why the Programmers' Manual had
> > a second volume.
> >
> > Nowadays people think nothing of writing 68-page-long manual
> > entries (real example from something I'm working with right now)
> > that are long, chatty lists of options or configuration-file
> > directives with tutorial information interspersed.  The result
> > makes the developer feel good--look at all the documentation
> > I've written!!--but it's useless for someone trying to figure
> > out how to write a configuration file for the first time, and
> > not so great even for someone trying to edit an existing one.
> >
> > Even the Research system didn't always get this right; some
> > manual entries ran on and on and on when what was really
> > needed was a concise list of something and a longer accompanying
> > document.  (The Tenth Edition manual was much better about
> > that, mostly because of all the work Doug put in.  I doubt
> > there has ever been a better editor for technical text than
> > Doug.)  But it's far worse now in most systems, because
> > there's rarely any editor at all; the manuals are just an
> > accreted clump.
> >
> > And that's a shame, though I have no suggestions on how
> > to fix it.
> >
> > +1

This is sort of my late in life mission.  Here's a description of a session
that I've proposed for an upcoming conference.

	Once upon a time there was Budweiser. Then, along came craft beer
	which started a movement. Now, one can find a whole range of
	offerings from craft cheese to artisanal baking soda. Hard to find
	is craft programming. What’s called "programming technology" today
	seems to be the art of minimizing the damage that can be done by
	monkeys at keyboards. Since we can no longer purchase even a
	toothpick that doesn’t contain a processor and a blue LED, we depend
	on code. How can we revive the art of programming? How do we foster
	the creation of good code instead of spending energy minimizing the
	damage that can be done by bad code? Our lives depend on it.

My two cents is that craft programmers know how to write good documentation.
Probably one of the things that made BTL so wonderful was the breadth of
knowledge that people had.  Ken was recently telling me about Lee McMahon who
was a classically trained monk in addition to writing qsort for V3.

From norman at oclsc.org  Fri Sep 20 04:50:26 2019
From: norman at oclsc.org (Norman Wilson)
Date: Thu, 19 Sep 2019 14:50:26 -0400
Subject: [TUHS] [OT] Re:  earliest Unix roff
Message-ID: <1568919029.18595.for-standards-violators@oclsc.org>

KatolaZ:
> We can discuss whether the split was necessary or "right" in the first
> instance, as we could discuss whether it was good or not for cat(1) to
> leave Murray Hill in 1979 with no options and come back from Berkley
> with a source code doubled in size and 9 options in 1982.

We needn't discuss that (though of course there are opinions and
mine are the correct ones), but in the interest of historic accuracy,
I should point out by 1979 (V7) cat had developed a single option -u
to turn off stdio buffering.

Sometime before 1984 or so, that option was removed, and cat was
simplified to just
	while ((n = read(fd, buf, sizeof(buf))) > 0)
		write(1, buf, n)
(error checking elided for clarity)
which worked just fine for the rest of the life of the Research
system.

So it's true that BSD added needless (in my humble but correct
opinion) options, but not that it had none before they touched it.
Unless all those other programs were stuffed into cat in an earlier
Berkeley system, but I don't think they were.

Norman Wilson
Toronto ON
(Three cats, no options)

From cym224 at gmail.com  Fri Sep 20 05:00:16 2019
From: cym224 at gmail.com (Nemo Nusquam)
Date: Thu, 19 Sep 2019 15:00:16 -0400
Subject: [TUHS] [OT] Re: earliest Unix roff
In-Reply-To: <1568919029.18595.for-standards-violators@oclsc.org>
References: <1568919029.18595.for-standards-violators@oclsc.org>
Message-ID: <bf4a47b4-9f7a-2b0c-b6cd-56f42fd8a5dd@gmail.com>

On 09/19/19 14:50, Norman Wilson wrote (in part):
> So it's true that BSD added needless (in my humble but correct
> opinion) options, but not that it had none before they touched it.
> Unless all those other programs were stuffed into cat in an earlier
> Berkeley system, but I don't think they were.

Who said "Cat came back from Berkeley waving flags."?

N.

> Norman Wilson
> Toronto ON
> (Three cats, no options)


From steffen at sdaoden.eu  Fri Sep 20 05:44:15 2019
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Thu, 19 Sep 2019 21:44:15 +0200
Subject: [TUHS] earliest Unix roff
In-Reply-To: <1568916649.17313.for-standards-violators@oclsc.org>
References: <1568916649.17313.for-standards-violators@oclsc.org>
Message-ID: <20190919194415.Tp6NO%steffen@sdaoden.eu>

Norman Wilson wrote in <1568916649.17313.for-standards-violators at oclsc.org>:
 |Larry McVoy:
 |
 |  If you have something like perl that needs a zillion sub pages, info
 |  makes sense.  For just a man page, info is horrible.
 |
 |=====
 |
 |This pokes me in one of my longest-standing complaints:
 |
 |Manual entries, as printed by man and once upon a time in
 |the Programmers' Manual Volume 1, should be concise references.
 |They are not a place for tutorials or long-winded descriptions
 |or even long lists of hundreds of options (let alone descriptions
 |of why the developer thinks this is the neatest thing since
 |sliced bread and what bread he had in his sandwiches that day).
 |
 |For many programs, one or two pages of concise reference is
 |all the documentation that's needed; no one needs a ten-page
 |tutorial on how to use cat or rm or ls, for example.  But some
 |programs really do deserve a longer treatment, either a tutorial
 |or an extended reference with more detail or both.  Those belong
 |in separate documents, and are why the Programmers' Manual had
 |a second volume.
 |
 |Nowadays people think nothing of writing 68-page-long manual
 |entries (real example from something I'm working with right now)
 |that are long, chatty lists of options or configuration-file
 |directives with tutorial information interspersed.  The result
 |makes the developer feel good--look at all the documentation
 |I've written!!--but it's useless for someone trying to figure
 |out how to write a configuration file for the first time, and
 |not so great even for someone trying to edit an existing one.
 |
 |Even the Research system didn't always get this right; some

I totally disagree with you.  Whereas i even admire McIlroy's
"concise", and really love reading Plan9 manual pages, and that
not only because one can imagine _who_ put their fingers on those,
i think manual pages should enable people to work with a program.
And not only intellectual elite, the absolute top of the pops
gathered together in this cave and grooving with a pict, but
"everybody" to the extend possible.

If i would have a lot of money in spare i could hire teams of
three people each which rotate through the develop / test
/ documentation cycle, and around each others work.  But that is
not how it goes here, you add a feature and write down the docs,
you extend one and patch in doc where you think it belongs, yet
get infos from someone and patch in doc to clarify something.  You
do all that short on time, and finally you have a rag rug.

So what you would need then is time to step back, let time pass,
come back with fresh eyes, reread the entire documentation once,
reflect, and work it all over.

Add the complications of not being a native speaker.
For some projects, add many translations done by volunteers, which
you leave behind if you adhere to this work cycle.  (But do not if
you just patch up.)

You could of course split the manual into several subsections, but
which one to split, which not.  Duplicate several, for example
command line options, which can initiate complicate tasks, which
need a lengthy text to become understandable?

Who is going to do all that work?  Who is the one who will spend
the time and strength necessary to keep all the individual parts
in sync?  For example, this week (at least the latter commit) on
FreeBSD the ZFS filesystem, thus a crucial part of the
infrastructure of FreeBSD (no Hammer or BTRFS support), the
i guess second largest free software environment, with quite some
people getting paid for working on the code base, was extended (i
do not use ZFS), but even the help string of the managing tool was
not updated until a follow up commit several days later fixed
that!

So for me this is not feasible.  I have the manual, and i have the
help string output for -h / --help, and a longer (long option) one
with --long-help.  If you want a quick shot, use -h.  If you need
documentation, use the manual.

  #?0|kent:mk$ man -l ../nail.1|wc -l
  troff: <standard input>:14382: name expected (got '\c'): treated as missing
  8172

Without TOC and anchors.
bug in groff mdoc macros in 1.22.3, by the way (.Lk i guessed).

  #?0|kent:mk$ mdoc ../nail.1|wc -l
  8307

With TOC and hundreds of internal and external anchors.

  #?0|kent:mk$ /tmp/y/s-nail -h|wc -l
  24
  #?0|kent:mk$ /tmp/y/s-nail --long-help|wc -l
  57

 |manual entries ran on and on and on when what was really
 |needed was a concise list of something and a longer accompanying
 |document.  (The Tenth Edition manual was much better about
 |that, mostly because of all the work Doug put in.  I doubt
 |there has ever been a better editor for technical text than
 |Doug.)  But it's far worse now in most systems, because
 |there's rarely any editor at all; the manuals are just an
 |accreted clump.
 |
 |And that's a shame, though I have no suggestions on how
 |to fix it.

I do not know either.  The car industry has the many pictures but
no content (for people who spend money), a repair manual for
underpaid mechanics, and detailed spare part foils for those
people working in the dusty spare parts depot.  That at least
thirty years ago when i snuffled into that industry.

 |Norman Wilson
 |Toronto ON
 --End of <1568916649.17313.for-standards-violators at oclsc.org>

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

From lm at mcvoy.com  Fri Sep 20 06:18:33 2019
From: lm at mcvoy.com (Larry McVoy)
Date: Thu, 19 Sep 2019 13:18:33 -0700
Subject: [TUHS] [OT] Re: earliest Unix roff
In-Reply-To: <bf4a47b4-9f7a-2b0c-b6cd-56f42fd8a5dd@gmail.com>
References: <1568919029.18595.for-standards-violators@oclsc.org>
 <bf4a47b4-9f7a-2b0c-b6cd-56f42fd8a5dd@gmail.com>
Message-ID: <20190919201833.GN2046@mcvoy.com>

On Thu, Sep 19, 2019 at 03:00:16PM -0400, Nemo Nusquam wrote:
> On 09/19/19 14:50, Norman Wilson wrote (in part):
> >So it's true that BSD added needless (in my humble but correct
> >opinion) options, but not that it had none before they touched it.
> >Unless all those other programs were stuffed into cat in an earlier
> >Berkeley system, but I don't think they were.
> 
> Who said "Cat came back from Berkeley waving flags."?

Rob Pike

From krewat at kilonet.net  Fri Sep 20 06:33:56 2019
From: krewat at kilonet.net (Arthur Krewat)
Date: Thu, 19 Sep 2019 16:33:56 -0400
Subject: [TUHS] [OT] Re: earliest Unix roff
In-Reply-To: <20190919201833.GN2046@mcvoy.com>
References: <1568919029.18595.for-standards-violators@oclsc.org>
 <bf4a47b4-9f7a-2b0c-b6cd-56f42fd8a5dd@gmail.com>
 <20190919201833.GN2046@mcvoy.com>
Message-ID: <19f9233f-6f54-46eb-116f-990660ca2a76@kilonet.net>

Serious question:

Which is better, creating a whole new binary to put in /usr/bin to do a 
single task, or add a flag to cat?

Which is better, a proliferation of binaries w/standalone source code, 
or a single code tree that can handle slightly different tasks and save 
space?

:)

art k.

PS: Using argv[0] (as in a symbolic link) to alter a program's behavior 
instead of using flags is cheating on the above test.




On 9/19/2019 4:18 PM, Larry McVoy wrote:
> On Thu, Sep 19, 2019 at 03:00:16PM -0400, Nemo Nusquam wrote:
>> On 09/19/19 14:50, Norman Wilson wrote (in part):
>>> So it's true that BSD added needless (in my humble but correct
>>> opinion) options, but not that it had none before they touched it.
>>> Unless all those other programs were stuffed into cat in an earlier
>>> Berkeley system, but I don't think they were.
>> Who said "Cat came back from Berkeley waving flags."?
> Rob Pike
>


From jpl.jpl at gmail.com  Fri Sep 20 06:38:51 2019
From: jpl.jpl at gmail.com (John P. Linderman)
Date: Thu, 19 Sep 2019 16:38:51 -0400
Subject: [TUHS] earliest Unix roff
In-Reply-To: <20190919194415.Tp6NO%steffen@sdaoden.eu>
References: <1568916649.17313.for-standards-violators@oclsc.org>
 <20190919194415.Tp6NO%steffen@sdaoden.eu>
Message-ID: <CAC0cEp-CVPb-OhcDHKfbj5nMoiYjkAOEZnEOf4Sv5ZrzTnDKTg@mail.gmail.com>

In the early 70's, Marc Rochkind recommended re-reading the entire UNIX
manual yearly. Back then, it was doable. Now it is probably growing faster
than I can read.

There is a place for a *concise* description of each command, and a
separate place for tutorials and conference papers.

On Thu, Sep 19, 2019 at 3:44 PM Steffen Nurpmeso <steffen at sdaoden.eu> wrote:

> Norman Wilson wrote in <1568916649.17313.for-standards-violators at oclsc.org
> >:
>  |Larry McVoy:
>  |
>  |  If you have something like perl that needs a zillion sub pages, info
>  |  makes sense.  For just a man page, info is horrible.
>  |
>  |=====
>  |
>  |This pokes me in one of my longest-standing complaints:
>  |
>  |Manual entries, as printed by man and once upon a time in
>  |the Programmers' Manual Volume 1, should be concise references.
>  |They are not a place for tutorials or long-winded descriptions
>  |or even long lists of hundreds of options (let alone descriptions
>  |of why the developer thinks this is the neatest thing since
>  |sliced bread and what bread he had in his sandwiches that day).
>  |
>  |For many programs, one or two pages of concise reference is
>  |all the documentation that's needed; no one needs a ten-page
>  |tutorial on how to use cat or rm or ls, for example.  But some
>  |programs really do deserve a longer treatment, either a tutorial
>  |or an extended reference with more detail or both.  Those belong
>  |in separate documents, and are why the Programmers' Manual had
>  |a second volume.
>  |
>  |Nowadays people think nothing of writing 68-page-long manual
>  |entries (real example from something I'm working with right now)
>  |that are long, chatty lists of options or configuration-file
>  |directives with tutorial information interspersed.  The result
>  |makes the developer feel good--look at all the documentation
>  |I've written!!--but it's useless for someone trying to figure
>  |out how to write a configuration file for the first time, and
>  |not so great even for someone trying to edit an existing one.
>  |
>  |Even the Research system didn't always get this right; some
>
> I totally disagree with you.  Whereas i even admire McIlroy's
> "concise", and really love reading Plan9 manual pages, and that
> not only because one can imagine _who_ put their fingers on those,
> i think manual pages should enable people to work with a program.
> And not only intellectual elite, the absolute top of the pops
> gathered together in this cave and grooving with a pict, but
> "everybody" to the extend possible.
>
> If i would have a lot of money in spare i could hire teams of
> three people each which rotate through the develop / test
> / documentation cycle, and around each others work.  But that is
> not how it goes here, you add a feature and write down the docs,
> you extend one and patch in doc where you think it belongs, yet
> get infos from someone and patch in doc to clarify something.  You
> do all that short on time, and finally you have a rag rug.
>
> So what you would need then is time to step back, let time pass,
> come back with fresh eyes, reread the entire documentation once,
> reflect, and work it all over.
>
> Add the complications of not being a native speaker.
> For some projects, add many translations done by volunteers, which
> you leave behind if you adhere to this work cycle.  (But do not if
> you just patch up.)
>
> You could of course split the manual into several subsections, but
> which one to split, which not.  Duplicate several, for example
> command line options, which can initiate complicate tasks, which
> need a lengthy text to become understandable?
>
> Who is going to do all that work?  Who is the one who will spend
> the time and strength necessary to keep all the individual parts
> in sync?  For example, this week (at least the latter commit) on
> FreeBSD the ZFS filesystem, thus a crucial part of the
> infrastructure of FreeBSD (no Hammer or BTRFS support), the
> i guess second largest free software environment, with quite some
> people getting paid for working on the code base, was extended (i
> do not use ZFS), but even the help string of the managing tool was
> not updated until a follow up commit several days later fixed
> that!
>
> So for me this is not feasible.  I have the manual, and i have the
> help string output for -h / --help, and a longer (long option) one
> with --long-help.  If you want a quick shot, use -h.  If you need
> documentation, use the manual.
>
>   #?0|kent:mk$ man -l ../nail.1|wc -l
>   troff: <standard input>:14382: name expected (got '\c'): treated as
> missing
>   8172
>
> Without TOC and anchors.
> bug in groff mdoc macros in 1.22.3, by the way (.Lk i guessed).
>
>   #?0|kent:mk$ mdoc ../nail.1|wc -l
>   8307
>
> With TOC and hundreds of internal and external anchors.
>
>   #?0|kent:mk$ /tmp/y/s-nail -h|wc -l
>   24
>   #?0|kent:mk$ /tmp/y/s-nail --long-help|wc -l
>   57
>
>  |manual entries ran on and on and on when what was really
>  |needed was a concise list of something and a longer accompanying
>  |document.  (The Tenth Edition manual was much better about
>  |that, mostly because of all the work Doug put in.  I doubt
>  |there has ever been a better editor for technical text than
>  |Doug.)  But it's far worse now in most systems, because
>  |there's rarely any editor at all; the manuals are just an
>  |accreted clump.
>  |
>  |And that's a shame, though I have no suggestions on how
>  |to fix it.
>
> I do not know either.  The car industry has the many pictures but
> no content (for people who spend money), a repair manual for
> underpaid mechanics, and detailed spare part foils for those
> people working in the dusty spare parts depot.  That at least
> thirty years ago when i snuffled into that industry.
>
>  |Norman Wilson
>  |Toronto ON
>  --End of <1568916649.17313.for-standards-violators at oclsc.org>
>
> --steffen
> |
> |Der Kragenbaer,                The moon bear,
> |der holt sich munter           he cheerfully and one by one
> |einen nach dem anderen runter  wa.ks himself off
> |(By Robert Gernhardt)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190919/cddb991a/attachment.html>

From jon at fourwinds.com  Fri Sep 20 06:39:31 2019
From: jon at fourwinds.com (Jon Steinhart)
Date: Thu, 19 Sep 2019 13:39:31 -0700
Subject: [TUHS] [OT] Re: earliest Unix roff
In-Reply-To: <19f9233f-6f54-46eb-116f-990660ca2a76@kilonet.net>
References: <1568919029.18595.for-standards-violators@oclsc.org>
 <bf4a47b4-9f7a-2b0c-b6cd-56f42fd8a5dd@gmail.com>
 <20190919201833.GN2046@mcvoy.com>
 <19f9233f-6f54-46eb-116f-990660ca2a76@kilonet.net>
Message-ID: <201909192039.x8JKdVtQ003479@darkstar.fourwinds.com>

Arthur Krewat writes:
> Serious question:
>
> Which is better, creating a whole new binary to put in /usr/bin to do a 
> single task, or add a flag to cat?
>
> Which is better, a proliferation of binaries w/standalone source code, 
> or a single code tree that can handle slightly different tasks and save 
> space?
>
> :)
>
> art k.
>
> PS: Using argv[0] (as in a symbolic link) to alter a program's behavior 
> instead of using flags is cheating on the above test.

I would argue the first.  In the case of current linux cat, I would make a
separate utility to number lines, a separate utility to squeeze out repeated
empty blank lines, a separate utility to show non printing characters that
might have an option to select the characters that would encompass -T.  All of
these are useful utilities by themselves.  Someone using a particular combo of
options a lot can always write their own scripts or use aliases.  That's the
beauty of composability.

Jon

From akosela at andykosela.com  Fri Sep 20 06:42:56 2019
From: akosela at andykosela.com (Andy Kosela)
Date: Thu, 19 Sep 2019 22:42:56 +0200
Subject: [TUHS] earliest Unix roff
In-Reply-To: <20190919201833.GN2046@mcvoy.com>
References: <1568919029.18595.for-standards-violators@oclsc.org>
 <bf4a47b4-9f7a-2b0c-b6cd-56f42fd8a5dd@gmail.com>
 <20190919201833.GN2046@mcvoy.com>
Message-ID: <CALMnNGjS_EBb1nMPxN27oQSo1McUV8hKu0FgUaYtXnWw1kXxjQ@mail.gmail.com>

On Thursday, September 19, 2019, Larry McVoy <lm at mcvoy.com> wrote:

> On Thu, Sep 19, 2019 at 03:00:16PM -0400, Nemo Nusquam wrote:
> > On 09/19/19 14:50, Norman Wilson wrote (in part):
> > >So it's true that BSD added needless (in my humble but correct
> > >opinion) options, but not that it had none before they touched it.
> > >Unless all those other programs were stuffed into cat in an earlier
> > >Berkeley system, but I don't think they were.
> >
> > Who said "Cat came back from Berkeley waving flags."?
>
> Rob Pike
>

 http://harmful.cat-v.org/cat-v/

--Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190919/3d4f4f23/attachment.html>

From bakul at bitblocks.com  Fri Sep 20 06:53:19 2019
From: bakul at bitblocks.com (Bakul Shah)
Date: Thu, 19 Sep 2019 13:53:19 -0700
Subject: [TUHS] earliest Unix roff
In-Reply-To: <1568916649.17313.for-standards-violators@oclsc.org>
References: <1568916649.17313.for-standards-violators@oclsc.org>
Message-ID: <7864DEA0-E980-4AAA-B5C0-059B6548C7DA@bitblocks.com>

On Sep 19, 2019, at 11:10 AM, Norman Wilson <norman at oclsc.org> wrote:
> 
> This pokes me in one of my longest-standing complaints:
> 
> Manual entries, as printed by man and once upon a time in
> the Programmers' Manual Volume 1, should be concise references.
> They are not a place for tutorials or long-winded descriptions
> or even long lists of hundreds of options (let alone descriptions
> of why the developer thinks this is the neatest thing since
> sliced bread and what bread he had in his sandwiches that day).
> 
> For many programs, one or two pages of concise reference is
> all the documentation that's needed; no one needs a ten-page
> tutorial on how to use cat or rm or ls, for example.  But some
> programs really do deserve a longer treatment, either a tutorial
> or an extended reference with more detail or both.  Those belong
> in separate documents, and are why the Programmers' Manual had
> a second volume.
> 
> Nowadays people think nothing of writing 68-page-long manual
> entries (real example from something I'm working with right now)
> that are long, chatty lists of options or configuration-file
> directives with tutorial information interspersed.  The result
> makes the developer feel good--look at all the documentation
> I've written!!--but it's useless for someone trying to figure
> out how to write a configuration file for the first time, and
> not so great even for someone trying to edit an existing one.
> 
> Even the Research system didn't always get this right; some
> manual entries ran on and on and on when what was really
> needed was a concise list of something and a longer accompanying
> document.  (The Tenth Edition manual was much better about
> that, mostly because of all the work Doug put in.  I doubt
> there has ever been a better editor for technical text than
> Doug.)  But it's far worse now in most systems, because
> there's rarely any editor at all; the manuals are just an
> accreted clump.
> 
> And that's a shame, though I have no suggestions on how
> to fix it.

Agree 100%. But I think what we are really complaining about
is more recent program design & interface. Why do programs
have so many options. Why is their functionality partitioned
better.


From norman at oclsc.org  Fri Sep 20 07:19:56 2019
From: norman at oclsc.org (Norman Wilson)
Date: Thu, 19 Sep 2019 17:19:56 -0400
Subject: [TUHS] [OT] Re: earliest Unix roff
Message-ID: <1568927999.21637.for-standards-violators@oclsc.org>

Arthur Krewat:

  Which is better, creating a whole new binary to put in /usr/bin to do a 
  single task, or add a flag to cat?

  Which is better, a proliferation of binaries w/standalone source code, 
  or a single code tree that can handle slightly different tasks and save 
  space?

======

Which is simpler to write correctly, to debug, and to maintain:
a simple program that does a single task, or a huge single program
with lots of tasks mashed together?

Which is easier to understand and use, individual programs each
with a few options specialized to a particular task, or a monolith
with many more options some of which apply only to one task or
another, others to all?

What are you trying to optimize for?  The speed with which
programmers can churn out yet another featureful utility full
of bugs and corner cases, or the ease with which the end-user
can figure out what tool to use and how to use it?

Norman Wilson
Toronto ON

From usotsuki at buric.co  Fri Sep 20 07:46:13 2019
From: usotsuki at buric.co (Steve Nickolas)
Date: Thu, 19 Sep 2019 17:46:13 -0400 (EDT)
Subject: [TUHS] [OT] Re: earliest Unix roff
In-Reply-To: <19f9233f-6f54-46eb-116f-990660ca2a76@kilonet.net>
References: <1568919029.18595.for-standards-violators@oclsc.org>
 <bf4a47b4-9f7a-2b0c-b6cd-56f42fd8a5dd@gmail.com>
 <20190919201833.GN2046@mcvoy.com>
 <19f9233f-6f54-46eb-116f-990660ca2a76@kilonet.net>
Message-ID: <alpine.BSF.2.02.1909191745270.12396@frieza.hoshinet.org>

On Thu, 19 Sep 2019, Arthur Krewat wrote:

> Serious question:
>
> Which is better, creating a whole new binary to put in /usr/bin to do a 
> single task, or add a flag to cat?
>
> Which is better, a proliferation of binaries w/standalone source code, or a 
> single code tree that can handle slightly different tasks and save space?
>
> :)
>
> art k.

I would argue that the more "Unix" way to do it is have the multiple 
binaries.  One job, one tool, and chain them together to make bigger 
tools.

-uso.

From lm at mcvoy.com  Fri Sep 20 07:51:07 2019
From: lm at mcvoy.com (Larry McVoy)
Date: Thu, 19 Sep 2019 14:51:07 -0700
Subject: [TUHS] [OT] Re: earliest Unix roff
In-Reply-To: <alpine.BSF.2.02.1909191745270.12396@frieza.hoshinet.org>
References: <1568919029.18595.for-standards-violators@oclsc.org>
 <bf4a47b4-9f7a-2b0c-b6cd-56f42fd8a5dd@gmail.com>
 <20190919201833.GN2046@mcvoy.com>
 <19f9233f-6f54-46eb-116f-990660ca2a76@kilonet.net>
 <alpine.BSF.2.02.1909191745270.12396@frieza.hoshinet.org>
Message-ID: <20190919215107.GA27727@mcvoy.com>

On Thu, Sep 19, 2019 at 05:46:13PM -0400, Steve Nickolas wrote:
> On Thu, 19 Sep 2019, Arthur Krewat wrote:
> 
> >Serious question:
> >
> >Which is better, creating a whole new binary to put in /usr/bin to do a
> >single task, or add a flag to cat?
> >
> >Which is better, a proliferation of binaries w/standalone source code, or
> >a single code tree that can handle slightly different tasks and save
> >space?
> >
> >:)
> >
> >art k.
> 
> I would argue that the more "Unix" way to do it is have the multiple
> binaries.  One job, one tool, and chain them together to make bigger tools.

That worked when we were running on 64K machines.  Modern machines do
a lot more and the problem space is not always a pipeline.

You aren't going to write a web server by spawning 

	cat | encrypt | http_servlet

That doesn't scale.  At all.

From robpike at gmail.com  Fri Sep 20 08:42:08 2019
From: robpike at gmail.com (Rob Pike)
Date: Fri, 20 Sep 2019 08:42:08 +1000
Subject: [TUHS] earliest Unix roff
In-Reply-To: <1568918582.18253.for-standards-violators@oclsc.org>
References: <1568918582.18253.for-standards-violators@oclsc.org>
Message-ID: <CAKzdPgySW=OowWHg=jEjdUj2q=kLKtpOAkYfF+bxx2VP4tA-ag@mail.gmail.com>

Here is the complete Plan 9 man page for p:

% 9 man p


     P(1)                                                         P(1)


     NAME

          p - paginate


     SYNOPSIS

          p [ -number ] [ file ... ]


     DESCRIPTION

          P copies its standard input, or the named files if given, to

          its standard output, stopping at the end of every 22nd line,

          and between files, to wait for a newline from the user.  The

          option sets the number of lines on a page.


          While waiting for a newline, p interprets the commands:


          !    Pass the rest of the line to the shell as a command.


          q    Quit.


     SOURCE

          /usr/local/plan9/src/cmd/p.c


     Page 1                       Plan 9             (printed 9/20/19)



On Fri, Sep 20, 2019 at 4:43 AM Norman Wilson <norman at oclsc.org> wrote:

> Clem Cole:
>
>   Exactly!!!!   That's what Eric did when he wrote more(ucb) -  he *added
> to
>   Unix*.   The funny part was that USG thought more(ucb) was a good idea
> and
>   then wrote their own, pg(att); which was just as arrogant as the info
>   behavior from the Gnu folks!!!
>
> ======
>
> And others wrote their own too, of course.  The one I know
> best is p(1), written by Rob Pike in the late 1970s at the
> University of Toronto.  I encountered at Caltech on the
> system Rob had set up before leaving for Bell Labs (and
> which I cared for and hacked on for the next four years
> before following him).  By the time I reached BTL it was
> a normal part of the Research system; I believe it's in
> all of the Eighth, Ninth, and Tenth Edition manuals.
>
> p is interesting because it's so much lighter-weight, and
> because it has rather a different interior design:
>
> Rather than doing termcappy things, p just prints 22 lines
> (or the number specified in an option), then doesn't print
> the newline after the 22nd line.  Hit return and it will
> print the next 22 lines, and so on.  The resulting text just
> flows up the glass-tty screen without any fuss, cbreak, or
> anything.  (I believe the first version predated V7 and
> therefore cbreak.)
>
> Why 22 lines instead of 24, the common height of glass ttys
> back then?  Partly because that means you keep a line or two
> of context when advancing pages, making reading simpler.
> But also because in those days, a standard page destined for
> a printer (e.g. from pr or nroff, and therefore from man) was
> 66 lines long.  22 evenly divides 66, so man something | p
> never gives you a screen spanning pages.
>
> p was able to back up: type - (and return) instead of just
> return, and it reprints the previous 22-line page; -- (return)
> the 22 lines before that; and so on.  This was implemented
> in an interesting and clever way: a wrapper around the standard
> I/O library which kept a circular buffer of some fixed number
> of characters (8KiB in early versions, I think), and a new
> call that, in effect, backed up the file pointer by one character
> and returned the character just backed over.  That made it easy
> to back over the previous N lines: just make that call until
> you've seen N newlines, then discard the newline you've just
> backed over, and you're at the beginning the first line you want
> to reprint.
>
> As I vaguely recall, more was able to back up, but only when
> reading from a real file, not a pipeline.  p could do (limited
> but sufficient) backup from a pipeline too.
>
> As a creature of its pre-window-system era, you could also type
> !command when p paused as well.
>
> I remember being quite interested in that wrapper as a
> possible library for use in other things, though I never
> found a use for it.
>
> I also remember a wonderful Elements-of-Programming-Style
> adventure with Rob's code.  I discovered it had a bug under some
> specific case when read returned less than a full bufferful.
> I read the code carefully and couldn't see what was wrong.
> So I wrote my own replacement for the problematic subroutine
> from scratch, tested it carefully in corner cases, then with
> listings of Rob's code and mine side-by-side walked through
> each with the problem case and found the bug.
>
> I still carry my own version of p (rewritten from scratch mainly
> to make it more portable--Rob's code was old enough to be too
> clever in some details) wherever I go; ironically, even back to
> U of T where I have been on and off for the past 30 years.
> more and less and pg and the like are certainly useful programs;
> for various reasons they're not to my taste, but I don't scorn
> them.  But I can't help being particular fond of p because it
> taught me a few things about programming too.
>
> Norman Wilson
> Toronto ON
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190920/fd1b38f3/attachment-0001.html>

From robpike at gmail.com  Fri Sep 20 08:44:44 2019
From: robpike at gmail.com (Rob Pike)
Date: Fri, 20 Sep 2019 08:44:44 +1000
Subject: [TUHS] [OT] Re: earliest Unix roff
In-Reply-To: <1568919029.18595.for-standards-violators@oclsc.org>
References: <1568919029.18595.for-standards-violators@oclsc.org>
Message-ID: <CAKzdPgyyJaAudnTXb0f6BLz93BdgF_=1_akdSC6Z7oay=9mFCQ@mail.gmail.com>

This was my fault, and it happened because I confronted DMR about the -u
flag for cat. He said it was there because it seemed important that cat be
writable in stdio, which was new at the time. I agreed but said the point
had been made and avoiding unnecessary flags was a higher goal. So cat was
simplified to do what it said, no more and no less, with read and write and
no nonsense.

-rob




On Fri, Sep 20, 2019 at 4:51 AM Norman Wilson <norman at oclsc.org> wrote:

> KatolaZ:
> > We can discuss whether the split was necessary or "right" in the first
> > instance, as we could discuss whether it was good or not for cat(1) to
> > leave Murray Hill in 1979 with no options and come back from Berkley
> > with a source code doubled in size and 9 options in 1982.
>
> We needn't discuss that (though of course there are opinions and
> mine are the correct ones), but in the interest of historic accuracy,
> I should point out by 1979 (V7) cat had developed a single option -u
> to turn off stdio buffering.
>
> Sometime before 1984 or so, that option was removed, and cat was
> simplified to just
>         while ((n = read(fd, buf, sizeof(buf))) > 0)
>                 write(1, buf, n)
> (error checking elided for clarity)
> which worked just fine for the rest of the life of the Research
> system.
>
> So it's true that BSD added needless (in my humble but correct
> opinion) options, but not that it had none before they touched it.
> Unless all those other programs were stuffed into cat in an earlier
> Berkeley system, but I don't think they were.
>
> Norman Wilson
> Toronto ON
> (Three cats, no options)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190920/4cb88e58/attachment.html>

From bakul at bitblocks.com  Fri Sep 20 08:55:22 2019
From: bakul at bitblocks.com (Bakul Shah)
Date: Thu, 19 Sep 2019 15:55:22 -0700
Subject: [TUHS] earliest Unix roff
In-Reply-To: Your message of "Fri, 20 Sep 2019 08:42:08 +1000."
 <CAKzdPgySW=OowWHg=jEjdUj2q=kLKtpOAkYfF+bxx2VP4tA-ag@mail.gmail.com>
References: <1568918582.18253.for-standards-violators@oclsc.org>
 <CAKzdPgySW=OowWHg=jEjdUj2q=kLKtpOAkYfF+bxx2VP4tA-ag@mail.gmail.com>
Message-ID: <20190919225529.ADCDD156E427@mail.bitblocks.com>

Re: more/less/p

At Fortune Systems Dave Yost added page mode to the tty driver
when his serial io optimizations made scrolling at 9600
blazing fast.  He also added an ioctl for page size.  By
setting it to something smaller than the tty number of rows
you can see some context as well.  This worked pretty well.

From alec at sensi.org  Fri Sep 20 18:59:31 2019
From: alec at sensi.org (Alexander Voropay)
Date: Fri, 20 Sep 2019 11:59:31 +0300
Subject: [TUHS] OpenSolaris Git ?
Message-ID: <CAGqcPWBmodgfQZHmmKBp-YFC2PUWtKM8vb_KqTTut1QX2uYuZg@mail.gmail.com>

Hi!

Is there a public OpenSolaris Git/CVS/SVN ?

The  openloaris.org  site is down.

AFIK the first sources set (not complete) was published around June 2005.
The latest available sources were b135 March 2010
(available at TUHS)
https://www.tuhs.org/cgi-bin/utree.pl?file=OpenSolaris_b135

It would be interesting to see an evolution of "pure" SysV R4.



--
-=AV=-
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190920/fc683aee/attachment.html>

From angus at fairhaven.za.net  Fri Sep 20 19:06:20 2019
From: angus at fairhaven.za.net (Angus Robinson)
Date: Fri, 20 Sep 2019 11:06:20 +0200
Subject: [TUHS] OpenSolaris Git ?
In-Reply-To: <CAGqcPWBmodgfQZHmmKBp-YFC2PUWtKM8vb_KqTTut1QX2uYuZg@mail.gmail.com>
References: <CAGqcPWBmodgfQZHmmKBp-YFC2PUWtKM8vb_KqTTut1QX2uYuZg@mail.gmail.com>
Message-ID: <CAE49LGmp25qpToO--ACPouXLBiZR05bekkkrhF3U8a1upbNs7w@mail.gmail.com>

Would this help?

https://repo.or.cz/opensolaris.git

On Fri, 20 Sep 2019, 11:00 Alexander Voropay, <alec at sensi.org> wrote:

> Hi!
>
> Is there a public OpenSolaris Git/CVS/SVN ?
>
> The  openloaris.org  site is down.
>
> AFIK the first sources set (not complete) was published around June 2005.
> The latest available sources were b135 March 2010
> (available at TUHS)
> https://www.tuhs.org/cgi-bin/utree.pl?file=OpenSolaris_b135
>
> It would be interesting to see an evolution of "pure" SysV R4.
>
>
>
> --
> -=AV=-
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190920/6aa89488/attachment.html>

From alec at sensi.org  Fri Sep 20 19:56:25 2019
From: alec at sensi.org (Alexander Voropay)
Date: Fri, 20 Sep 2019 12:56:25 +0300
Subject: [TUHS] OpenSolaris Git ?
In-Reply-To: <CAE49LGmp25qpToO--ACPouXLBiZR05bekkkrhF3U8a1upbNs7w@mail.gmail.com>
References: <CAGqcPWBmodgfQZHmmKBp-YFC2PUWtKM8vb_KqTTut1QX2uYuZg@mail.gmail.com>
 <CAE49LGmp25qpToO--ACPouXLBiZR05bekkkrhF3U8a1upbNs7w@mail.gmail.com>
Message-ID: <CAGqcPWB9KhJbFMFkzJ9pASo6tM3ogk3Gh9=C1=sPGbB=Uh606Q@mail.gmail.com>

Thank you!
This repository updates was stopped at Mar 2009 (but seems started from the
beginning at Jun 2005).

P.S. Some commands i.e. `date` are very stable :)
https://repo.or.cz/opensolaris.git/history/HEAD:/usr/src/cmd/date/date.c
No changes from the first release (and partial AT&T copyright inside)!


пт, 20 сент. 2019 г. в 12:06, Angus Robinson <angus at fairhaven.za.net>:

> Would this help?
>
> https://repo.or.cz/opensolaris.git
>
> On Fri, 20 Sep 2019, 11:00 Alexander Voropay, <alec at sensi.org> wrote:
>
>> Hi!
>>
>> Is there a public OpenSolaris Git/CVS/SVN ?
>>
>> The  openloaris.org  site is down.
>>
>> AFIK the first sources set (not complete) was published around June 2005.
>> The latest available sources were b135 March 2010
>> (available at TUHS)
>> https://www.tuhs.org/cgi-bin/utree.pl?file=OpenSolaris_b135
>>
>> It would be interesting to see an evolution of "pure" SysV R4.
>>
>>
>>
>> --
>> -=AV=-
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190920/018f4cc1/attachment.html>

From rosenfeld at grumpf.hope-2000.org  Fri Sep 20 20:20:11 2019
From: rosenfeld at grumpf.hope-2000.org (Hans Rosenfeld)
Date: Fri, 20 Sep 2019 12:20:11 +0200
Subject: [TUHS] OpenSolaris Git ?
In-Reply-To: <CAGqcPWBmodgfQZHmmKBp-YFC2PUWtKM8vb_KqTTut1QX2uYuZg@mail.gmail.com>
References: <CAGqcPWBmodgfQZHmmKBp-YFC2PUWtKM8vb_KqTTut1QX2uYuZg@mail.gmail.com>
Message-ID: <20190920102011.GF3209@grumpf.hope-2000.org>

On Fri, Sep 20, 2019 at 11:59:31AM +0300, Alexander Voropay wrote:
> Is there a public OpenSolaris Git/CVS/SVN ?
> 
> The  openloaris.org  site is down.
> 
> AFIK the first sources set (not complete) was published around June 2005.
> The latest available sources were b135 March 2010
> (available at TUHS)
> https://www.tuhs.org/cgi-bin/utree.pl?file=OpenSolaris_b135
> 
> It would be interesting to see an evolution of "pure" SysV R4.

The illumos project and the various distributions based on it continue
the development of what once was OpenSolaris.

https://illumos.org/
https://github.com/illumos/illumos-gate


Hans


-- 
%SYSTEM-F-ANARCHISM, The operating system has been overthrown

From alec at sensi.org  Fri Sep 20 23:19:23 2019
From: alec at sensi.org (Alexander Voropay)
Date: Fri, 20 Sep 2019 16:19:23 +0300
Subject: [TUHS] OpenSolaris Git ?
In-Reply-To: <20190920102011.GF3209@grumpf.hope-2000.org>
References: <CAGqcPWBmodgfQZHmmKBp-YFC2PUWtKM8vb_KqTTut1QX2uYuZg@mail.gmail.com>
 <20190920102011.GF3209@grumpf.hope-2000.org>
Message-ID: <CAGqcPWA7UoF2==qnWEBNqFa-1WV-18Q+s2SDXpZZDfqEnAy7Kw@mail.gmail.com>

Thank you!

The first illumos commit:
>0 parents   commit 7c478bd95313f5f23a4c958a745db2134aa03244
>committed on 14 Jun 2005



The illumos project and the various distributions based on it continue
> the development of what once was OpenSolaris.
>
> https://illumos.org/
> https://github.com/illumos/illumos-gate
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190920/e36d744e/attachment.html>

From steffen at sdaoden.eu  Fri Sep 20 23:41:37 2019
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Fri, 20 Sep 2019 15:41:37 +0200
Subject: [TUHS] earliest Unix roff
In-Reply-To: <CAC0cEp-CVPb-OhcDHKfbj5nMoiYjkAOEZnEOf4Sv5ZrzTnDKTg@mail.gmail.com>
References: <1568916649.17313.for-standards-violators@oclsc.org>
 <20190919194415.Tp6NO%steffen@sdaoden.eu>
 <CAC0cEp-CVPb-OhcDHKfbj5nMoiYjkAOEZnEOf4Sv5ZrzTnDKTg@mail.gmail.com>
Message-ID: <20190920134137.DXBTo%steffen@sdaoden.eu>

John P. Linderman wrote in <CAC0cEp-CVPb-OhcDHKfbj5nMoiYjkAOEZnEOf4Sv5Zr\
zTnDKTg at mail.gmail.com>:
 |In the early 70's, Marc Rochkind recommended re-reading the entire \
 |UNIX manual yearly. Back then, it was doable. Now it is probably growing \
 |faster than I can read.

It is however astonishing by how much even the POSIX standard
changes, as a lowest common denominator.  The IETF produces an
overwhelming amount of drafts and RFCs, which need to or should be
adhered to, affecting functionality and documentation.  So much
more time would be needed, for so many things.

 |There is a place for a concise description of each command, and a separate \
 |place for tutorials and conference papers.

Unfortunately not except in FreeBSD and NetBSD, which carry some
in /usr/share/doc, like the BSD mail manual.  You need to find it
here, and i wonder how many of those who have grown up in the
Linux world would find them at all.  (Or even do a search.)
They are not really updated in addition.  Though FreeBSD added
a clang entry, the time when developers invented ideas and
implementations, and documented those under /usr/share/doc are
over even there.  This is really sad.  Infrequently and getting
rarer i reread those, for example "Rethinking /dev and devices in
the UNIX kernel" about the introduction of devfs, which i still
find great.

It is great to hear you who is responsible that the "load of
options reached 17 in v9", whereas i maintain a fork of the
program which causes "old UNIX hands [to] groan at the monstrous
headers that come from latter-day mailers and at the fatness of
their manuals" (citing A Research UNIX Reader).

To offer a solution i could add another layer in between -h output
and full reference manual, and create a heavily minimized version
of the manual, renaming that one to -reference.1 maybe, and
prominently mention the reference.
Also, easy it is to concisely document that -n chooses a numeric
sort, and -r reverses the result order, but 

   -b addr, --bcc=..
          Send a blind carbon copy to recipient addr.

can result in dead-end or otherwise misunderstood situations
unless you really know that particular manual is stripped down,
and the reference manual makes this

   -b addr, --bcc=..
          Send a blind carbon copy to recipient addr, if the set[268]ting of
          expandaddr[408], one of the INTERNAL VARIABLES[29], allows; the
          ‘shquote’ expandaddr[408] flag is supported.  The option may be
          used multiple times.  Also see the section On sending mail, and
          non-interactive mode[7].

(Here, expandaddr has not been invented by me.)
But if you have the reference a bit present in your head, then

  #?0|kent:nail$ .obj/s-nail -h|grep -- -b
         [:-a attachment:] [:-b bcc-addr:] [:-c cc-addr:]
  . -b, -c, -r, -T, to-addr: ex at am.ple or '(Lovely) Ex <am at p.le>'

should also be sufficient.  Blasting the concise complexity of
a mathematical formula,

   -a file[=input-charset[#output-charset]], --attach=..
          Attach file to the message (for compose mode opportunities refer
          to ~@[317] and ~^[319]).

needs to backed as

   -a file[=input-charset[#output-charset]], --attach=..
          Attach file to the message (for compose mode opportunities refer
          to ~@[317] and ~^[319]).  Filename transformations[26] (also see
          file[193]) will be performed, except that shell variables are not
          expanded.  Shall file not be accessible but contain a ‘=’ charac‐
          ter, then anything before the last ‘=’ will be used as the file‐
          name, anything thereafter as a character set specification.

          If an input character set is specified, but no output character
          set, then the given input character set is fixed as-is, and no
          conversion will be applied; giving the empty string or the special
          string hyphen-minus ‘-’ will be treated as if ttycharset[590] has
          been specified (the default).

          If an output character set has also been given then the conversion
          will be performed exactly as specified and on-the-fly, not consid‐
          ering the file type and content.  As an exception the empty string
          or hyphen-minus ‘-’, select the default conversion algorithm (see
          Character sets[14]): no conversion is performed on-the-fly, file
          and its contents will be MIME-classified (HTML mail and MIME
          attachments[9], The mime.types files[35]); Only this mode is sup‐
          ported without support for character set conversions
          (features[411] does not mention ‘+iconv’).

for people to get at least enough of the picture to use the
option.  (Note the actual algorithm is documented somewhere else.)

  #?0|kent:nail$ .obj/s-nail -h|grep -- '-a '
           [:-a attachment:] [:-b bcc-addr:] [:-c cc-addr:]
  . -a attachment[=input-charset[#output-charset]]

But normally, all you say is "-a file" and the thing is fine
by default without just doing anything at all.  That is how it
should be.

Dear John P. Linderman, be warned that the above output of -b is
new, it was "-[bcrT]:" before, for which to understand regular
expressions or file patterns are implied.  I have given you credit
for the change.

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
-------------- next part --------------
An embedded message was scrubbed...
From: "John P. Linderman" <jpl.jpl at gmail.com>
Subject: Re: [TUHS] earliest Unix roff
Date: Thu, 19 Sep 2019 16:38:51 -0400
Size: 16566
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190920/705ce1f6/attachment.mht>

From krewat at kilonet.net  Sat Sep 21 00:37:51 2019
From: krewat at kilonet.net (Arthur Krewat)
Date: Fri, 20 Sep 2019 10:37:51 -0400
Subject: [TUHS] OpenSolaris Git ?
In-Reply-To: <CAGqcPWA7UoF2==qnWEBNqFa-1WV-18Q+s2SDXpZZDfqEnAy7Kw@mail.gmail.com>
References: <CAGqcPWBmodgfQZHmmKBp-YFC2PUWtKM8vb_KqTTut1QX2uYuZg@mail.gmail.com>
 <20190920102011.GF3209@grumpf.hope-2000.org>
 <CAGqcPWA7UoF2==qnWEBNqFa-1WV-18Q+s2SDXpZZDfqEnAy7Kw@mail.gmail.com>
Message-ID: <e4393997-4d9a-642d-f72e-d7c43c62beb4@kilonet.net>

And interestingly enough, last year, using Illumos, I could actually run 
Oracle Database 11g on it - I never tried anything newer.



On 9/20/2019 9:19 AM, Alexander Voropay wrote:
> Thank you!
>
> The first illumos commit:
> >0 parents   commit 7c478bd95313f5f23a4c958a745db2134aa03244
> >committed on 14 Jun 2005
>
>
>
>     The illumos project and the various distributions based on it continue
>     the development of what once was OpenSolaris.
>
>     https://illumos.org/
>     https://github.com/illumos/illumos-gate
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190920/19c5033c/attachment.html>

From steffen at sdaoden.eu  Sat Sep 21 01:03:14 2019
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Fri, 20 Sep 2019 17:03:14 +0200
Subject: [TUHS] earliest Unix roff
In-Reply-To: <20190920134137.DXBTo%steffen@sdaoden.eu>
References: <1568916649.17313.for-standards-violators@oclsc.org>
 <20190919194415.Tp6NO%steffen@sdaoden.eu>
 <CAC0cEp-CVPb-OhcDHKfbj5nMoiYjkAOEZnEOf4Sv5ZrzTnDKTg@mail.gmail.com>
 <20190920134137.DXBTo%steffen@sdaoden.eu>
Message-ID: <20190920150314.3iquv%steffen@sdaoden.eu>

Steffen Nurpmeso wrote in <20190920134137.DXBTo%steffen at sdaoden.eu>:
 |John P. Linderman wrote in <CAC0cEp-CVPb-OhcDHKfbj5nMoiYjkAOEZnEOf4Sv5Zr\
 |zTnDKTg at mail.gmail.com>:
 ...
 ||There is a place for a concise description of each command, and a \
 ||separate \
 ||place for tutorials and conference papers.
 ...
 |Also, easy it is to concisely document that -n chooses a numeric
 |sort, and -r reverses the result order, but 
 |
 |   -b addr, --bcc=..
 |          Send a blind carbon copy to recipient addr.
 |
 |can result in dead-end or otherwise misunderstood situations
 |unless you really know that particular manual is stripped down,
 |and the reference manual makes this
 ...

And i want to clarify that we talk about a program which does not
behave the way a user would normally expect, where normally is
that the mail is sent to all recipients.
In an academic or a lab environment you can ask someone, or go
over and say "Hi Ken" or "Hi Kurt", "your program misbehaves".
But in the wild people will simply start to mistrust a program, or
stop using it right away.  In 99 percent you will not even get
a bug report or hear just about anything.  (Except maybe for the
most popular and widely used programs.)  And then all the work,
the blood sweat and tears have been for nothing.

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

From athornton at gmail.com  Sat Sep 21 03:51:26 2019
From: athornton at gmail.com (Adam Thornton)
Date: Fri, 20 Sep 2019 10:51:26 -0700
Subject: [TUHS] OpenSolaris Git ?
In-Reply-To: <e4393997-4d9a-642d-f72e-d7c43c62beb4@kilonet.net>
References: <CAGqcPWBmodgfQZHmmKBp-YFC2PUWtKM8vb_KqTTut1QX2uYuZg@mail.gmail.com>
 <20190920102011.GF3209@grumpf.hope-2000.org>
 <CAGqcPWA7UoF2==qnWEBNqFa-1WV-18Q+s2SDXpZZDfqEnAy7Kw@mail.gmail.com>
 <e4393997-4d9a-642d-f72e-d7c43c62beb4@kilonet.net>
Message-ID: <CAP2nic1tVresmyREOZcpt0STPqrTjN6S2_d-OrZq8EorLbLNQQ@mail.gmail.com>

OpenSolaris was the only large project I ever contributed to that used
Mercurial as its source control system.  I am bad at git but I *really*
never wrapped my head around hg.

On Fri, Sep 20, 2019 at 7:38 AM Arthur Krewat <krewat at kilonet.net> wrote:

> And interestingly enough, last year, using Illumos, I could actually run
> Oracle Database 11g on it - I never tried anything newer.
>
>
>
> On 9/20/2019 9:19 AM, Alexander Voropay wrote:
>
> Thank you!
>
> The first illumos commit:
> >0 parents   commit 7c478bd95313f5f23a4c958a745db2134aa03244
> >committed on 14 Jun 2005
>
>
>
> The illumos project and the various distributions based on it continue
>> the development of what once was OpenSolaris.
>>
>> https://illumos.org/
>> https://github.com/illumos/illumos-gate
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190920/237bb8cf/attachment.html>

From fuz at fuz.su  Sat Sep 21 08:53:50 2019
From: fuz at fuz.su (Robert Clausecker)
Date: Sat, 21 Sep 2019 00:53:50 +0200
Subject: [TUHS] 8bc -- a B compiler for the PDP-8
Message-ID: <20190920225350.GA26132@fuz.su>

Greetings!

As a project for our university's seminar on the PDP-8 I wrote a
compiler for the B language targeting it.  It's a bit rough around
the edges and the runtime code needs some work (division and
remainder are missing), but it does compile B code correctly,
generating acceptable code (for my taste, though the function call
sequence could be better).

I hope some of you enjoy this compiler for an important historical
language for an important historical computer (makes me wonder why
the two weren't married before).

https://github.com/fuzxxl/8bc

Yours,
Robert Clausecker

-- 
()  ascii ribbon campaign - for an 8-bit clean world 
/\  - against html email  - against proprietary attachments

From imp at bsdimp.com  Sat Sep 21 20:47:19 2019
From: imp at bsdimp.com (Warner Losh)
Date: Sat, 21 Sep 2019 12:47:19 +0200
Subject: [TUHS] My talk today 2019-09-20 at UTC 1230
Message-ID: <CANCZdfpWUHU29GuMsK0g_FGXjqrznHMOy3ESUzYnFqWKA6xjew@mail.gmail.com>

https://2019.eurobsdcon.org/livestream-soria-moria/

Has a live stream. My talk is at 1230 UTC or just under 2 hours. There will
be a recording I think that I'll be able to share with you in a day or
three.

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190921/0c98344b/attachment.html>

From wkt at tuhs.org  Sat Sep 21 20:49:08 2019
From: wkt at tuhs.org (Warren Toomey)
Date: Sat, 21 Sep 2019 20:49:08 +1000
Subject: [TUHS] My talk today 2019-09-20 at UTC 1230
In-Reply-To: <CANCZdfpWUHU29GuMsK0g_FGXjqrznHMOy3ESUzYnFqWKA6xjew@mail.gmail.com>
References: <CANCZdfpWUHU29GuMsK0g_FGXjqrznHMOy3ESUzYnFqWKA6xjew@mail.gmail.com>
Message-ID: <FB48C49B-6723-4217-B3D8-03CF953F82C7@tuhs.org>

Best of luck with it Warner.
Cheers, Warren

On 21 September 2019 8:47:19 pm AEST, Warner Losh <imp at bsdimp.com> wrote:
>https://2019.eurobsdcon.org/livestream-soria-moria/
>
>Has a live stream. My talk is at 1230 UTC or just under 2 hours. There
>will
>be a recording I think that I'll be able to share with you in a day or
>three.
>
>Warner

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190921/83df88f7/attachment.html>

From spedraja at gmail.com  Sat Sep 21 21:26:14 2019
From: spedraja at gmail.com (SPC)
Date: Sat, 21 Sep 2019 13:26:14 +0200
Subject: [TUHS] My talk today 2019-09-20 at UTC 1230
In-Reply-To: <FB48C49B-6723-4217-B3D8-03CF953F82C7@tuhs.org>
References: <CANCZdfpWUHU29GuMsK0g_FGXjqrznHMOy3ESUzYnFqWKA6xjew@mail.gmail.com>
 <FB48C49B-6723-4217-B3D8-03CF953F82C7@tuhs.org>
Message-ID: <CACytpF9RX-VN6_NywbnN3vP0V1c-Gjnmpj_qDvcDsUkOKm0z-w@mail.gmail.com>

Best Wishes and Good Luck!

Cordiales saludos / Best Regards / Salutations / Freundliche Grüße
-----
Sergio Pedraja
Skype: spedraja at gmail.com

-----
Senior Technician in Computer Science, Systems Administration, and
Information Security. MBA. Qualified occupational trainer.

El sáb., 21 sept. 2019 12:49, Warren Toomey <wkt at tuhs.org> escribió:

> Best of luck with it Warner.
> Cheers, Warren
>
> On 21 September 2019 8:47:19 pm AEST, Warner Losh <imp at bsdimp.com> wrote:
>>
>> https://2019.eurobsdcon.org/livestream-soria-moria/
>>
>> Has a live stream. My talk is at 1230 UTC or just under 2 hours. There
>> will be a recording I think that I'll be able to share with you in a day or
>> three.
>>
>> Warner
>>
>
> --
> Sent from my Android phone with K-9 Mail. Please excuse my brevity.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190921/6532c2fe/attachment.html>

From clemc at ccc.com  Sat Sep 21 21:51:28 2019
From: clemc at ccc.com (Clem cole)
Date: Sat, 21 Sep 2019 07:51:28 -0400
Subject: [TUHS] My talk today 2019-09-20 at UTC 1230
In-Reply-To: <CANCZdfpWUHU29GuMsK0g_FGXjqrznHMOy3ESUzYnFqWKA6xjew@mail.gmail.com>
References: <CANCZdfpWUHU29GuMsK0g_FGXjqrznHMOy3ESUzYnFqWKA6xjew@mail.gmail.com>
Message-ID: <26F0B811-E6E4-4CD8-B8ED-801F2C5FBB19@ccc.com>

Indeed and have fun

Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. 

> On Sep 21, 2019, at 6:47 AM, Warner Losh <imp at bsdimp.com> wrote:
> 
> https://2019.eurobsdcon.org/livestream-soria-moria/
> 
> Has a live stream. My talk is at 1230 UTC or just under 2 hours. There will be a recording I think that I'll be able to share with you in a day or three.
> 
> Warner 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190921/e0a9b891/attachment.html>

From tuhs at eric.allman.name  Sat Sep 21 23:32:51 2019
From: tuhs at eric.allman.name (Eric Allman)
Date: Sat, 21 Sep 2019 15:32:51 +0200
Subject: [TUHS] congratulations to Warner on a great talk
Message-ID: <f0647776-4cbc-1b62-8e80-dd50fa9c4c6b@neophilic.com>

Warner's talk just finished --- it was excellent.  Those of you who
didn't see it live might well want to see the recording when it comes out.

eric

From tuhs at eric.allman.name  Sun Sep 22 00:44:34 2019
From: tuhs at eric.allman.name (Eric Allman)
Date: Sat, 21 Sep 2019 16:44:34 +0200
Subject: [TUHS] congratulations to Warner on a great talk
In-Reply-To: <49C268A5-42E6-41E2-95F9-0A8043DFC9F3@alchemistowl.org>
References: <f0647776-4cbc-1b62-8e80-dd50fa9c4c6b@neophilic.com>
 <49C268A5-42E6-41E2-95F9-0A8043DFC9F3@alchemistowl.org>
Message-ID: <65187b33-08f1-88ca-5729-eb40cdb5ced7@neophilic.com>

> That’s high praise! Let us know when it is out and where, please.

Word this morning was that the recordings will be up in "a couple of
days".  Keep an eye on https://2019.eurobsdcon.org/ — at the moment
there's a "livestream" pull-down, which I predict will be replaced with
a pointer to the recordings (although they could end up elsewhere; I
have no inside information).

eric

From arrigo at alchemistowl.org  Sun Sep 22 00:08:05 2019
From: arrigo at alchemistowl.org (Arrigo Triulzi)
Date: Sat, 21 Sep 2019 16:08:05 +0200
Subject: [TUHS] congratulations to Warner on a great talk
In-Reply-To: <f0647776-4cbc-1b62-8e80-dd50fa9c4c6b@neophilic.com>
References: <f0647776-4cbc-1b62-8e80-dd50fa9c4c6b@neophilic.com>
Message-ID: <49C268A5-42E6-41E2-95F9-0A8043DFC9F3@alchemistowl.org>

On 21 Sep 2019, at 15:33, Eric Allman <tuhs at eric.allman.name> wrote:
> 
> ﻿Warner's talk just finished --- it was excellent.  Those of you who
> didn't see it live might well want to see the recording when it comes out.

That’s high praise! Let us know when it is out and where, please.

Arrigo 
> 
> eric


From clemc at ccc.com  Sun Sep 22 02:39:35 2019
From: clemc at ccc.com (Clem Cole)
Date: Sat, 21 Sep 2019 12:39:35 -0400
Subject: [TUHS] congratulations to Warner on a great talk
In-Reply-To: <f0647776-4cbc-1b62-8e80-dd50fa9c4c6b@neophilic.com>
References: <f0647776-4cbc-1b62-8e80-dd50fa9c4c6b@neophilic.com>
Message-ID: <CAC20D2PUE4PTnh2sUVkWBSz5edg_poz8j5Kb9_ZBXwJ7USpruQ@mail.gmail.com>

Wonderful

On Sat, Sep 21, 2019 at 9:33 AM Eric Allman <tuhs at eric.allman.name> wrote:

> Warner's talk just finished --- it was excellent.  Those of you who
> didn't see it live might well want to see the recording when it comes out.
>
> eric
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190921/1c823b42/attachment.html>

From clemc at ccc.com  Tue Sep 24 03:25:40 2019
From: clemc at ccc.com (Clem Cole)
Date: Mon, 23 Sep 2019 13:25:40 -0400
Subject: [TUHS] 8bc -- a B compiler for the PDP-8
In-Reply-To: <20190920225350.GA26132@fuz.su>
References: <20190920225350.GA26132@fuz.su>
Message-ID: <CAC20D2NMVwL-tkSTAUq0TTZtE+FG+KiCKEe-WD_b+HcmRHs9MQ@mail.gmail.com>

below...

On Fri, Sep 20, 2019 at 7:08 PM Robert Clausecker <fuz at fuz.su> wrote:

> Greetings!
>
> As a project for our university's seminar on the PDP-8 I wrote a
> compiler for the B language targeting it.


Very cool.

>   It's a bit rough around
> the edges and the runtime code needs some work (division and
> remainder are missing), but it does compile B code correctly,
> generating acceptable code (for my taste, though the function call
> sequence could be better).
>
A suggestion,   Load TSS/8 on to your simh system with its Algol compiler
and look at how it generated code.  I would suspect you can use Algol's
calling conventions and probably some of its runtime.   Google is your
friend.  I had it running a while back, but do not have it active at the
moment - the key is all the pieces should be findable in the wild,.


>
> I hope some of you enjoy this compiler for an important historical
> language for an important historical computer (makes me wonder why
> the two weren't married before).
>
Might have been, although when Ken created B for the PDP-7, BCPL was his
model and there were already implementations of BCPL around for a number of
processors.  I would not be surprised if there was a BCPL/8.  I would check
in the DECUS library, much of which I think can be found online these days
??bit savers??.

FWIW: IIRC, the Grenoble Algol, a DEC Fortran and DEC Focal (plus
assembler) were the languages I remember on TSS/8.  I came late and short
lived to the PDP-8 world and did not do much with it.  So there could have
been/unlikely were more.   The 8 Gordon Bell and his students had used to
write it, was in the EE Dept at the time and most unused because we hard
started to collect PDP-11s.

But I do have a fondness for the TSS/8, because on a bet, one summer
weekend in about 1976 I think, a couple of us hacked on it to make it swap
to paper tape - you got about 2-4K of storage max (the read is destructive
and much more than that the tape ripped/got tangled).  But it worked enough
we got the beers and pizza and we claimed success for proving it could be
done.   Sadly I have long ago lost that code for that hack.   The PDP-8 we
used was a very early 8 that CMU had and at one point was in donated to
Boston Computer Museum/was on display until the museum closed.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190923/7fced605/attachment.html>

From henry.r.bent at gmail.com  Tue Sep 24 04:01:25 2019
From: henry.r.bent at gmail.com (Henry Bent)
Date: Mon, 23 Sep 2019 14:01:25 -0400
Subject: [TUHS] 8bc -- a B compiler for the PDP-8
In-Reply-To: <CAC20D2NMVwL-tkSTAUq0TTZtE+FG+KiCKEe-WD_b+HcmRHs9MQ@mail.gmail.com>
References: <20190920225350.GA26132@fuz.su>
 <CAC20D2NMVwL-tkSTAUq0TTZtE+FG+KiCKEe-WD_b+HcmRHs9MQ@mail.gmail.com>
Message-ID: <CAEdTPBfuvdNn3SBnsBsnFGc=Aq_Vt=Pn4v80N34hQRe+k1=5hw@mail.gmail.com>

On Mon, 23 Sep 2019 at 13:27, Clem Cole <clemc at ccc.com> wrote:

> below...
>
> On Fri, Sep 20, 2019 at 7:08 PM Robert Clausecker <fuz at fuz.su> wrote:
>
>>   It's a bit rough around
>> the edges and the runtime code needs some work (division and
>> remainder are missing), but it does compile B code correctly,
>> generating acceptable code (for my taste, though the function call
>> sequence could be better).
>>
> A suggestion,   Load TSS/8 on to your simh system with its Algol compiler
> and look at how it generated code.  I would suspect you can use Algol's
> calling conventions and probably some of its runtime.   Google is your
> friend.  I had it running a while back, but do not have it active at the
> moment - the key is all the pieces should be findable in the wild,.
>
>
>>
>> I hope some of you enjoy this compiler for an important historical
>> language for an important historical computer (makes me wonder why
>> the two weren't married before).
>>
> Might have been, although when Ken created B for the PDP-7, BCPL was his
> model and there were already implementations of BCPL around for a number of
> processors.  I would not be surprised if there was a BCPL/8.  I would check
> in the DECUS library, much of which I think can be found online these days
> ??bit savers??.
>

I checked here: http://so-much-stuff.com/pdp8/software/decus.php but did
not immediately see anything BCPL related.  8-330 is TSS/8 ALGOL.

-Henry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190923/7ae91960/attachment.html>

From arnold at skeeve.com  Wed Sep 25 03:10:37 2019
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Tue, 24 Sep 2019 11:10:37 -0600
Subject: [TUHS] Revived!  The 10 Edition spell program!
Message-ID: <201909241710.x8OHAbF8014895@freefriends.org>

Hello All.

I have revived the 10th edition spell(1) program, allowing it to compile
and run on "modern" systems.

See https://github.com/arnoldrobbins/v10spell ; the README.md gives
an overview of what was done.

Enjoy!

Arnold

From clemc at ccc.com  Wed Sep 25 03:15:31 2019
From: clemc at ccc.com (Clem Cole)
Date: Tue, 24 Sep 2019 13:15:31 -0400
Subject: [TUHS] Revived! The 10 Edition spell program!
In-Reply-To: <201909241710.x8OHAbF8014895@freefriends.org>
References: <201909241710.x8OHAbF8014895@freefriends.org>
Message-ID: <CAC20D2PFZDVmthfvv6NHmZcNTO-imTDRB6z79sg1+d2P1trUYg@mail.gmail.com>

Very cool.  Thank you

On Tue, Sep 24, 2019 at 1:11 PM <arnold at skeeve.com> wrote:

> Hello All.
>
> I have revived the 10th edition spell(1) program, allowing it to compile
> and run on "modern" systems.
>
> See https://github.com/arnoldrobbins/v10spell ; the README.md gives
> an overview of what was done.
>
> Enjoy!
>
> Arnold
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190924/70b737d7/attachment.html>

From arnold at skeeve.com  Wed Sep 25 03:30:43 2019
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Tue, 24 Sep 2019 11:30:43 -0600
Subject: [TUHS] Revived! The 10 Edition spell program!
In-Reply-To: <CAC20D2PFZDVmthfvv6NHmZcNTO-imTDRB6z79sg1+d2P1trUYg@mail.gmail.com>
References: <201909241710.x8OHAbF8014895@freefriends.org>
 <CAC20D2PFZDVmthfvv6NHmZcNTO-imTDRB6z79sg1+d2P1trUYg@mail.gmail.com>
Message-ID: <201909241730.x8OHUhvT015578@freefriends.org>

You're welcome.  Yet Another Labor of Love. :-)

Clem Cole <clemc at ccc.com> wrote:

> Very cool.  Thank you
>
> On Tue, Sep 24, 2019 at 1:11 PM <arnold at skeeve.com> wrote:
>
> > Hello All.
> >
> > I have revived the 10th edition spell(1) program, allowing it to compile
> > and run on "modern" systems.
> >
> > See https://github.com/arnoldrobbins/v10spell ; the README.md gives
> > an overview of what was done.
> >
> > Enjoy!
> >
> > Arnold
> >

From khm at sciops.net  Wed Sep 25 05:42:13 2019
From: khm at sciops.net (Kurt H Maier)
Date: Tue, 24 Sep 2019 12:42:13 -0700
Subject: [TUHS] Revived!  The 10 Edition spell program!
In-Reply-To: <201909241710.x8OHAbF8014895@freefriends.org>
References: <201909241710.x8OHAbF8014895@freefriends.org>
Message-ID: <20190924194213.GA74746@wopr>

On Tue, Sep 24, 2019 at 11:10:37AM -0600, arnold at skeeve.com wrote:
> Hello All.
> 
> I have revived the 10th edition spell(1) program, allowing it to compile
> and run on "modern" systems.

Great!  I've been using this extensively on my writing, but I've been
using the version that comes with plan9port.  It'll be nice to have a
standalone version.  

Thanks!
khm

From lm at mcvoy.com  Wed Sep 25 05:58:35 2019
From: lm at mcvoy.com (Larry McVoy)
Date: Tue, 24 Sep 2019 12:58:35 -0700
Subject: [TUHS] Revived!  The 10 Edition spell program!
In-Reply-To: <20190924194213.GA74746@wopr>
References: <201909241710.x8OHAbF8014895@freefriends.org>
 <20190924194213.GA74746@wopr>
Message-ID: <20190924195835.GB21722@mcvoy.com>

On Tue, Sep 24, 2019 at 12:42:13PM -0700, Kurt H Maier wrote:
> On Tue, Sep 24, 2019 at 11:10:37AM -0600, arnold at skeeve.com wrote:
> > Hello All.
> > 
> > I have revived the 10th edition spell(1) program, allowing it to compile
> > and run on "modern" systems.
> 
> Great!  I've been using this extensively on my writing, but I've been
> using the version that comes with plan9port.  It'll be nice to have a
> standalone version.  

How is this better than spell(1) on Linux?

From arnold at skeeve.com  Wed Sep 25 05:45:29 2019
From: arnold at skeeve.com (Arnold Robbins)
Date: Tue, 24 Sep 2019 22:45:29 +0300
Subject: [TUHS] Recovered!!! The Georgia Tech Software Tools Subystem for
 Prime Computers
Message-ID: <201909241945.x8OJjTCX032294@skeeve.com>

Hello All.

Believed lost in the mists of time for over 30 years, the Georgia Tech
Software Tools Subsystem for Prime Computers, along with the Georgia Tech
C Compiler for Prime Computers, have been recovered!

The source code and documentation (and binary files) are available in a
Github repo: https://github.com/arnoldrobbins/gt-swt.

The README.md there provides some brief history and credits with respect
to the recovery, and w.r.t. the subsystem and C compilers themselves.

Credit to Scott Lee for making and keeping the tapes and driving the
recovery process, and to Dennis Boone and yours truly for contributing
financially.  I set up the repo.

For anyone who used and/or contributed to this software, we hope you'll
enjoy this trip down memory lane.

Feel free to forward this note to interested parties.

Enjoy,

Arnold Robbins
(On behalf of the swt recovery team. :-)

From khm at sciops.net  Wed Sep 25 06:30:52 2019
From: khm at sciops.net (Kurt H Maier)
Date: Tue, 24 Sep 2019 13:30:52 -0700
Subject: [TUHS] Revived!  The 10 Edition spell program!
In-Reply-To: <20190924195835.GB21722@mcvoy.com>
References: <201909241710.x8OHAbF8014895@freefriends.org>
 <20190924194213.GA74746@wopr> <20190924195835.GB21722@mcvoy.com>
Message-ID: <20190924203052.GB74746@wopr>

On Tue, Sep 24, 2019 at 12:58:35PM -0700, Larry McVoy wrote:
> 
> How is this better than spell(1) on Linux?

Assuming you're talking about GNU spell, it suffers from feature creep
(localization stuff, hard-coded markup filters, etc) which makes the
code less pleasant to work with.  I'm not sure why my spellchecker needs
curses support, but GNU spell has it.  Also I don't like having to worry
about licensing cruft when I e.g. copy a binary over to a system at
work.  If I can do my work with 5% the source code, that's generally my
plan.


khm

From dscherrer at solar.stanford.edu  Wed Sep 25 07:29:36 2019
From: dscherrer at solar.stanford.edu (Deborah Scherrer)
Date: Tue, 24 Sep 2019 14:29:36 -0700
Subject: [TUHS] Recovered!!! The Georgia Tech Software Tools Subystem
 for Prime Computers
In-Reply-To: <201909241945.x8OJjTCX032294@skeeve.com>
References: <201909241945.x8OJjTCX032294@skeeve.com>
Message-ID: <a27b32e1-6b7a-5215-0b29-d5369cda461f@solar.stanford.edu>

Awesome!!!   Arnold, you're a saint!!!!
D

On 9/24/19 12:45 PM, Arnold Robbins wrote:
> Hello All.
>
> Believed lost in the mists of time for over 30 years, the Georgia Tech
> Software Tools Subsystem for Prime Computers, along with the Georgia Tech
> C Compiler for Prime Computers, have been recovered!
>
> The source code and documentation (and binary files) are available in a
> Github repo: https://github.com/arnoldrobbins/gt-swt.
>
> The README.md there provides some brief history and credits with respect
> to the recovery, and w.r.t. the subsystem and C compilers themselves.
>
> Credit to Scott Lee for making and keeping the tapes and driving the
> recovery process, and to Dennis Boone and yours truly for contributing
> financially.  I set up the repo.
>
> For anyone who used and/or contributed to this software, we hope you'll
> enjoy this trip down memory lane.
>
> Feel free to forward this note to interested parties.
>
> Enjoy,
>
> Arnold Robbins
> (On behalf of the swt recovery team. :-)


From arnold at skeeve.com  Wed Sep 25 16:15:50 2019
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Wed, 25 Sep 2019 00:15:50 -0600
Subject: [TUHS] Revived!  The 10 Edition spell program!
In-Reply-To: <20190924203052.GB74746@wopr>
References: <201909241710.x8OHAbF8014895@freefriends.org>
 <20190924194213.GA74746@wopr> <20190924195835.GB21722@mcvoy.com>
 <20190924203052.GB74746@wopr>
Message-ID: <201909250615.x8P6FoWX006682@freefriends.org>

Kurt H Maier <khm at sciops.net> wrote:

> On Tue, Sep 24, 2019 at 12:58:35PM -0700, Larry McVoy wrote:
> > 
> > How is this better than spell(1) on Linux?
>
> Assuming you're talking about GNU spell, it suffers from feature creep
> (localization stuff, hard-coded markup filters, etc) which makes the
> code less pleasant to work with.  I'm not sure why my spellchecker needs
> curses support, but GNU spell has it.  Also I don't like having to worry
> about licensing cruft when I e.g. copy a binary over to a system at
> work.  If I can do my work with 5% the source code, that's generally my
> plan.
>
>
> khm

It's not clear what 'spell' is --- it differs from distro to distro,
often based on aspell.  Whatever is on Ubuntu doesn't even know
how to use 'sort -u' on its output.

For myself, I don't claim that v10spell is better or worse than anything
else out there; it simply provides another option, especially for fans
of the original Unix code. :-)

Arnold

From arnold at skeeve.com  Wed Sep 25 16:17:12 2019
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Wed, 25 Sep 2019 00:17:12 -0600
Subject: [TUHS] Recovered!!! The Georgia Tech Software Tools Subystem
 for Prime Computers
In-Reply-To: <a27b32e1-6b7a-5215-0b29-d5369cda461f@solar.stanford.edu>
References: <201909241945.x8OJjTCX032294@skeeve.com>
 <a27b32e1-6b7a-5215-0b29-d5369cda461f@solar.stanford.edu>
Message-ID: <201909250617.x8P6HCrB006753@freefriends.org>

Thanks Deborah. But if you want to send flowers, send them to Scott
Lee; he's the one who had the tapes and drove getting them recovered.
"All" I did was get things usable for github. :-)

Arnold

Deborah Scherrer <dscherrer at solar.stanford.edu> wrote:

> Awesome!!!   Arnold, you're a saint!!!!
> D
>
> On 9/24/19 12:45 PM, Arnold Robbins wrote:
> > Hello All.
> >
> > Believed lost in the mists of time for over 30 years, the Georgia Tech
> > Software Tools Subsystem for Prime Computers, along with the Georgia Tech
> > C Compiler for Prime Computers, have been recovered!
> >
> > The source code and documentation (and binary files) are available in a
> > Github repo: https://github.com/arnoldrobbins/gt-swt.
> >
> > The README.md there provides some brief history and credits with respect
> > to the recovery, and w.r.t. the subsystem and C compilers themselves.
> >
> > Credit to Scott Lee for making and keeping the tapes and driving the
> > recovery process, and to Dennis Boone and yours truly for contributing
> > financially.  I set up the repo.
> >
> > For anyone who used and/or contributed to this software, we hope you'll
> > enjoy this trip down memory lane.
> >
> > Feel free to forward this note to interested parties.
> >
> > Enjoy,
> >
> > Arnold Robbins
> > (On behalf of the swt recovery team. :-)

From arrigo at alchemistowl.org  Thu Sep 26 00:41:18 2019
From: arrigo at alchemistowl.org (Arrigo Triulzi)
Date: Wed, 25 Sep 2019 16:41:18 +0200
Subject: [TUHS] congratulations to Warner on a great talk
In-Reply-To: <65187b33-08f1-88ca-5729-eb40cdb5ced7@neophilic.com>
References: <f0647776-4cbc-1b62-8e80-dd50fa9c4c6b@neophilic.com>
 <49C268A5-42E6-41E2-95F9-0A8043DFC9F3@alchemistowl.org>
 <65187b33-08f1-88ca-5729-eb40cdb5ced7@neophilic.com>
Message-ID: <F0785DDE-F597-4622-AC5E-1D242B749F6B@alchemistowl.org>

On 21 Sep 2019, at 16:44, Eric Allman <tuhs at eric.allman.name> wrote:
> Word this morning was that the recordings will be up in "a couple of
> days".  Keep an eye on https://2019.eurobsdcon.org/ — at the moment
> there's a "livestream" pull-down, which I predict will be replaced with
> a pointer to the recordings (although they could end up elsewhere; I
> have no inside information).

None of the talks appear to be published and, even more sadly, neither have slides appeared with the exception of the keynote on silly Slideshare.

I really hope they don’t disappear without trace.

Arrigo


From imp at bsdimp.com  Thu Sep 26 01:09:08 2019
From: imp at bsdimp.com (Warner Losh)
Date: Wed, 25 Sep 2019 09:09:08 -0600
Subject: [TUHS] congratulations to Warner on a great talk
In-Reply-To: <F0785DDE-F597-4622-AC5E-1D242B749F6B@alchemistowl.org>
References: <f0647776-4cbc-1b62-8e80-dd50fa9c4c6b@neophilic.com>
 <49C268A5-42E6-41E2-95F9-0A8043DFC9F3@alchemistowl.org>
 <65187b33-08f1-88ca-5729-eb40cdb5ced7@neophilic.com>
 <F0785DDE-F597-4622-AC5E-1D242B749F6B@alchemistowl.org>
Message-ID: <CANCZdfoJ1kTa58oUq2RAxVCHM4nRQ1YiOZweLoqSSmgXe7RR3A@mail.gmail.com>

On Wed, Sep 25, 2019 at 8:43 AM Arrigo Triulzi <arrigo at alchemistowl.org>
wrote:

> On 21 Sep 2019, at 16:44, Eric Allman <tuhs at eric.allman.name> wrote:
> > Word this morning was that the recordings will be up in "a couple of
> > days".  Keep an eye on https://2019.eurobsdcon.org/ — at the moment
> > there's a "livestream" pull-down, which I predict will be replaced with
> > a pointer to the recordings (although they could end up elsewhere; I
> > have no inside information).
>
> None of the talks appear to be published and, even more sadly, neither
> have slides appeared with the exception of the keynote on silly Slideshare.
>
> I really hope they don’t disappear without trace.
>

Slides have been published, though maybe not through the EuroBSDCon site. I
wasn't aware that I could publish them there.

https://docs.google.com/presentation/d/177KxOif5oHARyIdZHDq-OO67_GVtMkzIAlDX-cHxgb4/edit?usp=sharing

I'm told it will be a small number of weeks before the bsdtv folks that
taped everything can edit the talks down from the raw footage and post them
to youtube. They have the raw livestream, but a small number of tweaks need
to be made to each talk.

I'll be writing a followup paper, as well as an article for the FreeBSD
Journal. There's a number of small technical errors in the talk owing to
two factors: (1) I couldn't see my speaker notes during the talk so I think
I misspoke or neglected to include a clarifying sentence or two that I'd
planned and (2) I found more original material that helped to clarify
timelines (eg: PWB 1.0 was distributed outside of bell labs: it was V6 +
the "50 changes" based, but still retained features like the V6 TTY driver.
This was in 1978, about a year before V7 was released. PWB 2.0 was fully V7
based and included updates to the tools PWB added, exact details TBD). I
did talk a little about the ambiguity between UNIX/TS and PWB/UNIX 3.0 in
the talk, but the details of that need to be ironed out a bit. I hope to go
through more original sources to figure all that out as different people
remember things slightly differently, and sometimes contemporary
documentation or scholarly papers contradicts the remembrance so I need to
sort that out better, as well as where I can run diffs between supposed
sources of things to find as much of the truth around this that I can.

I hope to give this talk again, with some tweaks, since it was well
received. It's been a while since my talks have provoked that much
enthusiastic energy in the room. Maybe FOSDEM, BSDCan and something Linux
oriented / related in the US.

Warner

Warner

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190925/835446ca/attachment.html>

From imp at bsdimp.com  Thu Sep 26 01:15:21 2019
From: imp at bsdimp.com (Warner Losh)
Date: Wed, 25 Sep 2019 09:15:21 -0600
Subject: [TUHS] UNIX NEWS, volumes 1-7 out there?
Message-ID: <CANCZdfpWfxYj5gZ29_EY2kYi_y-hW_KhVOYees+o0MbHyYHLig@mail.gmail.com>

I'm looking for complete compies of UNIX NEWS volumes 1-7. 8 and newer are
available on the USENIX site, or on archive.org, but older ones are not. A
few excerpts are published in newer login issues, but nothing complete.
Reading the AUUGN issues, especially the early ones, are quite enlightening
and help one judge the relative merits of later accounts with better
contemporary context. I was hoping to get the same from UNIX NEWS (later
login) and any other news letters that may exist from the time (I think I
spotted references to one from the UK in AUUGN). It's really quite
enlightening.

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190925/698d68ea/attachment.html>

From arrigo at alchemistowl.org  Thu Sep 26 01:17:04 2019
From: arrigo at alchemistowl.org (Arrigo Triulzi)
Date: Wed, 25 Sep 2019 17:17:04 +0200
Subject: [TUHS] congratulations to Warner on a great talk
In-Reply-To: <CANCZdfoJ1kTa58oUq2RAxVCHM4nRQ1YiOZweLoqSSmgXe7RR3A@mail.gmail.com>
References: <f0647776-4cbc-1b62-8e80-dd50fa9c4c6b@neophilic.com>
 <49C268A5-42E6-41E2-95F9-0A8043DFC9F3@alchemistowl.org>
 <65187b33-08f1-88ca-5729-eb40cdb5ced7@neophilic.com>
 <F0785DDE-F597-4622-AC5E-1D242B749F6B@alchemistowl.org>
 <CANCZdfoJ1kTa58oUq2RAxVCHM4nRQ1YiOZweLoqSSmgXe7RR3A@mail.gmail.com>
Message-ID: <34674811-F25A-4CE8-9A54-249930AC7916@alchemistowl.org>

On 25 Sep 2019, at 17:09, Warner Losh <imp at bsdimp.com> wrote:
> Slides have been published, though maybe not through the EuroBSDCon site. I wasn't aware that I could publish them there.

I was under the mistaken impression that recordings of the talks would be made available on the site - I generally find it rather useful when conferences have slides, papers and recordings available on the web pages of past conferences, e.g. Usenix.

> https://docs.google.com/presentation/d/177KxOif5oHARyIdZHDq-OO67_GVtMkzIAlDX-cHxgb4/edit?usp=sharing

Ah, that’s the final version of what we got a preview of?

> I'm told it will be a small number of weeks before the bsdtv folks that taped everything can edit the talks down from the raw footage and post them to youtube. They have the raw livestream, but a small number of tweaks need to be made to each talk.

Right, that makes sense. I would like to see the “colour” which goes with the slides, i.e. all that isn’t written down..

> I'll be writing a followup paper, as well as an article for the FreeBSD Journal. There's a number of small technical errors in the talk owing to two factors: (1) I couldn't see my speaker notes during the talk so I think I misspoke or neglected to include a clarifying sentence or two that I'd planned and (2) I found more original material that helped to clarify timelines (eg: PWB 1.0 was distributed outside of bell labs: it was V6 + the "50 changes" based, but still retained features like the V6 TTY driver. This was in 1978, about a year before V7 was released. PWB 2.0 was fully V7 based and included updates to the tools PWB added, exact details TBD). I did talk a little about the ambiguity between UNIX/TS and PWB/UNIX 3.0 in the talk, but the details of that need to be ironed out a bit. I hope to go through more original sources to figure all that out as different people remember things slightly differently, and sometimes contemporary documentation or scholarly papers contradicts the remembrance so I need to sort that out better, as well as where I can run diffs between supposed sources of things to find as much of the truth around this that I can.

That is wonderful! I have been desperately trying to find the Unix tapes which made it to the University of Milan “Cybernetics” department back in the 70s but have failed miserably. Most of the people who were there at the time are sadly no longer with us and my dad can’t remember who had them. All that I have left is the photocopied Unix manual with the cover printed by the department in Italian, an nth copy Lions and then other bits and pieces. All the rest is gone forever (or, more likely, in some Italian state warehouse since the bureaucracy necessary to throw anything away, or donate it, was so daunting it was just stuck somewhere). Unfortunately there were three physical moves of the department so chances are the cellars were cleaned out by workers.

Thank you again for the talk!

Arrigo


From imp at bsdimp.com  Thu Sep 26 01:26:07 2019
From: imp at bsdimp.com (Warner Losh)
Date: Wed, 25 Sep 2019 09:26:07 -0600
Subject: [TUHS] congratulations to Warner on a great talk
In-Reply-To: <34674811-F25A-4CE8-9A54-249930AC7916@alchemistowl.org>
References: <f0647776-4cbc-1b62-8e80-dd50fa9c4c6b@neophilic.com>
 <49C268A5-42E6-41E2-95F9-0A8043DFC9F3@alchemistowl.org>
 <65187b33-08f1-88ca-5729-eb40cdb5ced7@neophilic.com>
 <F0785DDE-F597-4622-AC5E-1D242B749F6B@alchemistowl.org>
 <CANCZdfoJ1kTa58oUq2RAxVCHM4nRQ1YiOZweLoqSSmgXe7RR3A@mail.gmail.com>
 <34674811-F25A-4CE8-9A54-249930AC7916@alchemistowl.org>
Message-ID: <CANCZdfrysje+j6nxiYaNf1zFPUPmbA=xvqyLSWcSTgG2jfZPYA@mail.gmail.com>

On Wed, Sep 25, 2019 at 9:17 AM Arrigo Triulzi <arrigo at alchemistowl.org>
wrote:

> On 25 Sep 2019, at 17:09, Warner Losh <imp at bsdimp.com> wrote:
> > Slides have been published, though maybe not through the EuroBSDCon
> site. I wasn't aware that I could publish them there.
>
> I was under the mistaken impression that recordings of the talks would be
> made available on the site - I generally find it rather useful when
> conferences have slides, papers and recordings available on the web pages
> of past conferences, e.g. Usenix.
>

I think that links to the talks will be there, but they will be uploaded to
youtube. Most conferences give some instructions to speakers for uploading
talk related materials, but I've not seen anything from EuroBSDcon. Most
likely it is in a spam folder :(


> >
> https://docs.google.com/presentation/d/177KxOif5oHARyIdZHDq-OO67_GVtMkzIAlDX-cHxgb4/edit?usp=sharing
>
> Ah, that’s the final version of what we got a preview of?
>

Yes.


> > I'm told it will be a small number of weeks before the bsdtv folks that
> taped everything can edit the talks down from the raw footage and post them
> to youtube. They have the raw livestream, but a small number of tweaks need
> to be made to each talk.
>
> Right, that makes sense. I would like to see the “colour” which goes with
> the slides, i.e. all that isn’t written down..
>

I hope it will be there as well. I quite enjoyed giving the talk, though
the audience was small.


> > I'll be writing a followup paper, as well as an article for the FreeBSD
> Journal. There's a number of small technical errors in the talk owing to
> two factors: (1) I couldn't see my speaker notes during the talk so I think
> I misspoke or neglected to include a clarifying sentence or two that I'd
> planned and (2) I found more original material that helped to clarify
> timelines (eg: PWB 1.0 was distributed outside of bell labs: it was V6 +
> the "50 changes" based, but still retained features like the V6 TTY driver.
> This was in 1978, about a year before V7 was released. PWB 2.0 was fully V7
> based and included updates to the tools PWB added, exact details TBD). I
> did talk a little about the ambiguity between UNIX/TS and PWB/UNIX 3.0 in
> the talk, but the details of that need to be ironed out a bit. I hope to go
> through more original sources to figure all that out as different people
> remember things slightly differently, and sometimes contemporary
> documentation or scholarly papers contradicts the remembrance so I need to
> sort that out better, as well as where I can run diffs between supposed
> sources of things to find as much of the truth around this that I can.
>
> That is wonderful! I have been desperately trying to find the Unix tapes
> which made it to the University of Milan “Cybernetics” department back in
> the 70s but have failed miserably. Most of the people who were there at the
> time are sadly no longer with us and my dad can’t remember who had them.
> All that I have left is the photocopied Unix manual with the cover printed
> by the department in Italian, an nth copy Lions and then other bits and
> pieces. All the rest is gone forever (or, more likely, in some Italian
> state warehouse since the bureaucracy necessary to throw anything away, or
> donate it, was so daunting it was just stuck somewhere). Unfortunately
> there were three physical moves of the department so chances are the
> cellars were cleaned out by workers.
>

I would love to find that as well... At least one person came up to me
after the talk and told me about a set of Onyx Z8000 System III manuals he
had that we're making arrangements to find a good home (like maybe mine).
Future versions of this talk will likely include a plea for people to
contact me with historic artifacts so I might be able to copy them...

Warner


> Thank you again for the talk!
>
> Arrigo
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190925/107f2ea8/attachment.html>

From clemc at ccc.com  Thu Sep 26 01:30:47 2019
From: clemc at ccc.com (Clem Cole)
Date: Wed, 25 Sep 2019 11:30:47 -0400
Subject: [TUHS] UNIX NEWS, volumes 1-7 out there?
In-Reply-To: <CANCZdfpWfxYj5gZ29_EY2kYi_y-hW_KhVOYees+o0MbHyYHLig@mail.gmail.com>
References: <CANCZdfpWfxYj5gZ29_EY2kYi_y-hW_KhVOYees+o0MbHyYHLig@mail.gmail.com>
Message-ID: <CAC20D2O-Fj-=QepT82BTZpeSSFao=x2+eFfkSbg81my0OJ=zeg@mail.gmail.com>

FYI: the folks at USENIX has been looking for these for a number of years.
 Let me know if you find copies of them and I will get them pushed back to
the USENIX archives.

Clem

On Wed, Sep 25, 2019 at 11:16 AM Warner Losh <imp at bsdimp.com> wrote:

> I'm looking for complete compies of UNIX NEWS volumes 1-7. 8 and newer are
> available on the USENIX site, or on archive.org, but older ones are not.
> A few excerpts are published in newer login issues, but nothing complete.
> Reading the AUUGN issues, especially the early ones, are quite enlightening
> and help one judge the relative merits of later accounts with better
> contemporary context. I was hoping to get the same from UNIX NEWS (later
> login) and any other news letters that may exist from the time (I think I
> spotted references to one from the UK in AUUGN). It's really quite
> enlightening.
>
> Warner
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190925/767575cc/attachment.html>

From arrigo at alchemistowl.org  Thu Sep 26 01:32:24 2019
From: arrigo at alchemistowl.org (Arrigo Triulzi)
Date: Wed, 25 Sep 2019 17:32:24 +0200
Subject: [TUHS] congratulations to Warner on a great talk
In-Reply-To: <CANCZdfrysje+j6nxiYaNf1zFPUPmbA=xvqyLSWcSTgG2jfZPYA@mail.gmail.com>
References: <f0647776-4cbc-1b62-8e80-dd50fa9c4c6b@neophilic.com>
 <49C268A5-42E6-41E2-95F9-0A8043DFC9F3@alchemistowl.org>
 <65187b33-08f1-88ca-5729-eb40cdb5ced7@neophilic.com>
 <F0785DDE-F597-4622-AC5E-1D242B749F6B@alchemistowl.org>
 <CANCZdfoJ1kTa58oUq2RAxVCHM4nRQ1YiOZweLoqSSmgXe7RR3A@mail.gmail.com>
 <34674811-F25A-4CE8-9A54-249930AC7916@alchemistowl.org>
 <CANCZdfrysje+j6nxiYaNf1zFPUPmbA=xvqyLSWcSTgG2jfZPYA@mail.gmail.com>
Message-ID: <2BD243C6-BE68-4865-AC15-2AFD09919185@alchemistowl.org>

On 25 Sep 2019, at 17:26, Warner Losh <imp at bsdimp.com> wrote:
> I would love to find that as well... At least one person came up to me after the talk and told me about a set of Onyx Z8000 System III manuals he had that we're making arrangements to find a good home (like maybe mine). Future versions of this talk will likely include a plea for people to contact me with historic artifacts so I might be able to copy them…

Wait! I /have/ those: that’s the first Unix system we had at home (as opposed to having to dial into the university). It used to sit on its pedestal under my uncle’s home office table (how he worked with that noise I have no idea), I need to dig them up from my dad’s cellar but I am certain we have them, probably also some tapes. The machine is, sadly, long gone. I have fond memories of vi & C on that machine typing on my very own Italian ADM 3A clone instead of having to share dad’s TTY and modem.

Arrigo


From tuhs at eric.allman.name  Thu Sep 26 02:48:02 2019
From: tuhs at eric.allman.name (Eric Allman)
Date: Wed, 25 Sep 2019 18:48:02 +0200
Subject: [TUHS] congratulations to Warner on a great talk
In-Reply-To: <F0785DDE-F597-4622-AC5E-1D242B749F6B@alchemistowl.org>
References: <f0647776-4cbc-1b62-8e80-dd50fa9c4c6b@neophilic.com>
 <49C268A5-42E6-41E2-95F9-0A8043DFC9F3@alchemistowl.org>
 <65187b33-08f1-88ca-5729-eb40cdb5ced7@neophilic.com>
 <F0785DDE-F597-4622-AC5E-1D242B749F6B@alchemistowl.org>
Message-ID: <14e53cec-6c59-cf5b-68af-b34d758e89d6@neophilic.com>

I just got word from the EuroBSDcon crew requesting that authors submit
PDF of their slides for publication and mentioning that the recordings
will be available "in two to three months".  I was under the impression
that it would be a matter of days or maybe weeks instead of months ---
my fault entirely.  I'm pretty sure they are not going to disappear
though.  The A/V crew was very professional this year and it looks like
the source material should be excellent.

eric


On 2019-09-25 16:41 , Arrigo Triulzi wrote:
> On 21 Sep 2019, at 16:44, Eric Allman <tuhs at eric.allman.name> wrote:
>> Word this morning was that the recordings will be up in "a couple of
>> days".  Keep an eye on https://2019.eurobsdcon.org/ — at the moment
>> there's a "livestream" pull-down, which I predict will be replaced with
>> a pointer to the recordings (although they could end up elsewhere; I
>> have no inside information).
> 
> None of the talks appear to be published and, even more sadly, neither have slides appeared with the exception of the keynote on silly Slideshare.
> 
> I really hope they don’t disappear without trace.
> 
> Arrigo
> 

From khm at sciops.net  Thu Sep 26 12:54:37 2019
From: khm at sciops.net (Kurt H Maier)
Date: Wed, 25 Sep 2019 19:54:37 -0700
Subject: [TUHS] UNIX NEWS, volumes 1-7 out there?
In-Reply-To: <CAC20D2O-Fj-=QepT82BTZpeSSFao=x2+eFfkSbg81my0OJ=zeg@mail.gmail.com>
References: <CANCZdfpWfxYj5gZ29_EY2kYi_y-hW_KhVOYees+o0MbHyYHLig@mail.gmail.com>
 <CAC20D2O-Fj-=QepT82BTZpeSSFao=x2+eFfkSbg81my0OJ=zeg@mail.gmail.com>
Message-ID: <20190926025437.GC19436@wopr>

On Wed, Sep 25, 2019 at 11:30:47AM -0400, Clem Cole wrote:
> On Wed, Sep 25, 2019 at 11:16 AM Warner Losh <imp at bsdimp.com> wrote:
> 
> > I'm looking for complete compies of UNIX NEWS volumes 1-7. 8 and newer are
>
> FYI: the folks at USENIX has been looking for these for a number of years.
>  Let me know if you find copies of them and I will get them pushed back to
> the USENIX archives.

I have a large swath of #4, dated 19 March 1976, if we're talking about
the same thing.  I've scanned it in at 600 dpi: 
  http://sciops.net/images/unix-news/1976-03-19/

khm

From jsteve at superglobalmegacorp.com  Thu Sep 26 15:59:41 2019
From: jsteve at superglobalmegacorp.com (Jason Stevens)
Date: Thu, 26 Sep 2019 13:59:41 +0800
Subject: [TUHS] Recovered!!! The Georgia Tech Software Tools Subystemfor
 Prime Computers
In-Reply-To: <a27b32e1-6b7a-5215-0b29-d5369cda461f@solar.stanford.edu>
References: <201909241945.x8OJjTCX032294@skeeve.com>
 <a27b32e1-6b7a-5215-0b29-d5369cda461f@solar.stanford.edu>
Message-ID: <d515a88b-4851-4d9b-a798-5493139bf816@PU1APC01FT040.eop-APC01.prod.protection.outlook.com>

I see mention of an emulator in the GitHub repo, but I don’t see any emulator that is available.

Am I reading this wrong?

All that is mentioned is a telnet address to something that just drops.

From: Deborah Scherrer
Sent: Wednesday, September 25, 2019 5:46 AM
To: tuhs at minnie.tuhs.org
Subject: Re: [TUHS] Recovered!!! The Georgia Tech Software Tools Subystemfor Prime Computers

Awesome!!!   Arnold, you're a saint!!!!
D

On 9/24/19 12:45 PM, Arnold Robbins wrote:
> Hello All.
>
> Believed lost in the mists of time for over 30 years, the Georgia Tech
> Software Tools Subsystem for Prime Computers, along with the Georgia Tech
> C Compiler for Prime Computers, have been recovered!
>
> The source code and documentation (and binary files) are available in a
> Github repo: https://github.com/arnoldrobbins/gt-swt.
>
> The README.md there provides some brief history and credits with respect
> to the recovery, and w.r.t. the subsystem and C compilers themselves.
>
> Credit to Scott Lee for making and keeping the tapes and driving the
> recovery process, and to Dennis Boone and yours truly for contributing
> financially.  I set up the repo.
>
> For anyone who used and/or contributed to this software, we hope you'll
> enjoy this trip down memory lane.
>
> Feel free to forward this note to interested parties.
>
> Enjoy,
>
> Arnold Robbins
> (On behalf of the swt recovery team. :-)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190926/62b9fb77/attachment.html>

From lars at nocrew.org  Thu Sep 26 16:03:49 2019
From: lars at nocrew.org (Lars Brinkhoff)
Date: Thu, 26 Sep 2019 06:03:49 +0000
Subject: [TUHS] Recovered!!! The Georgia Tech Software Tools Subystemfor
 Prime Computers
In-Reply-To: <d515a88b-4851-4d9b-a798-5493139bf816@PU1APC01FT040.eop-APC01.prod.protection.outlook.com>
 (Jason Stevens's message of "Thu, 26 Sep 2019 13:59:41 +0800")
References: <201909241945.x8OJjTCX032294@skeeve.com>
 <a27b32e1-6b7a-5215-0b29-d5369cda461f@solar.stanford.edu>
 <d515a88b-4851-4d9b-a798-5493139bf816@PU1APC01FT040.eop-APC01.prod.protection.outlook.com>
Message-ID: <7wo8z7zj96.fsf@junk.nocrew.org>

> I see mention of an emulator in the GitHub repo, but I don’t see any
> emulator that is available.

I see this:

Welcome to the Prime Computer 50-series emulator, running Primos rev 24.0!

  Login as user guest, password pr1me
  Hit a few returns and Ctrl-q if it appears "stuck"; some bots are hitting the emulator
  After logging in, use the Prime HELP command for assistance.
  You are welcome to create a directory under GUEST for your files.
  The emacs terminal type is xterm
  The line erase character is ?
  There are other Primos revs running on ports 8001-8007
  Prime manuals at: http://yagi.h-net.msu.edu/prime_manuals/prirun_scans
  To report bugs or contact the author, send email to prirun at gmail.com

Enjoy your time travels!   -Jim Wilcoxson aka JIMMY

Login please.

login guest
Password?

GUEST (user 2) logged in Thursday, 26 Sep 19 02:03:08.
Welcome to PRIMOS version 24.0.0.r15
Copyright (c) Computervision, Corp. 1993.
Last login Tuesday, 24 Sep 19 19:58:08.


Warning!   There was 1 failed attempt to login under this id since the
           last successful login.

OK,

From jsteve at superglobalmegacorp.com  Thu Sep 26 16:08:01 2019
From: jsteve at superglobalmegacorp.com (Jason Stevens)
Date: Thu, 26 Sep 2019 14:08:01 +0800
Subject: [TUHS] Recovered!!! The Georgia Tech Software Tools Subystemfor
 Prime Computers
In-Reply-To: <7wo8z7zj96.fsf@junk.nocrew.org>
References: <201909241945.x8OJjTCX032294@skeeve.com>
 <a27b32e1-6b7a-5215-0b29-d5369cda461f@solar.stanford.edu>
 <d515a88b-4851-4d9b-a798-5493139bf816@PU1APC01FT040.eop-APC01.prod.protection.outlook.com>
 <7wo8z7zj96.fsf@junk.nocrew.org>
Message-ID: <0c66d8e5-ef8b-4682-b8a0-281c5c7c0359@PU1APC01FT115.eop-APC01.prod.protection.outlook.com>

I now get this:

All available connections are in use.                                                                                                                                                                                                           

Connection to host lost.
                                                                                                                                                                 

I guess progress.

Oh well, I guess it’s not possible to distribute the emulator? 


From: Lars Brinkhoff
Sent: Thursday, September 26, 2019 2:03 PM
To: Jason Stevens
Cc: tuhs at minnie.tuhs.org
Subject: Re: [TUHS] Recovered!!! The Georgia Tech Software Tools Subystemfor Prime Computers

> I see mention of an emulator in the GitHub repo, but I don’t see any
> emulator that is available.

I see this:

Welcome to the Prime Computer 50-series emulator, running Primos rev 24.0!

  Login as user guest, password pr1me
  Hit a few returns and Ctrl-q if it appears "stuck"; some bots are hitting the emulator
  After logging in, use the Prime HELP command for assistance.
  You are welcome to create a directory under GUEST for your files.
  The emacs terminal type is xterm
  The line erase character is ?
  There are other Primos revs running on ports 8001-8007
  Prime manuals at: http://yagi.h-net.msu.edu/prime_manuals/prirun_scans
  To report bugs or contact the author, send email to prirun at gmail.com

Enjoy your time travels!   -Jim Wilcoxson aka JIMMY

Login please.

login guest
Password?

GUEST (user 2) logged in Thursday, 26 Sep 19 02:03:08.
Welcome to PRIMOS version 24.0.0.r15
Copyright (c) Computervision, Corp. 1993.
Last login Tuesday, 24 Sep 19 19:58:08.


Warning!   There was 1 failed attempt to login under this id since the
           last successful login.

OK,

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190926/69c6d400/attachment.html>

From arnold at skeeve.com  Thu Sep 26 16:09:48 2019
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Thu, 26 Sep 2019 00:09:48 -0600
Subject: [TUHS] Recovered!!! The Georgia Tech Software Tools Subystemfor
 Prime Computers
In-Reply-To: <d515a88b-4851-4d9b-a798-5493139bf816@PU1APC01FT040.eop-APC01.prod.protection.outlook.com>
References: <201909241945.x8OJjTCX032294@skeeve.com>
 <a27b32e1-6b7a-5215-0b29-d5369cda461f@solar.stanford.edu>
 <d515a88b-4851-4d9b-a798-5493139bf816@PU1APC01FT040.eop-APC01.prod.protection.outlook.com>
Message-ID: <201909260609.x8Q69mUP017447@freefriends.org>

It has always worked for me, or I wouldn't have put it in the README.
Sounds like a network issue on your end.

(Now, why someone would go out of their way to work on Primos is another
question.  I *never* used it directly, but only via the SWT subsystem.
At Georgia Tech, we logged straigt into SWT.)

Arnold

Jason Stevens <jsteve at superglobalmegacorp.com> wrote:

> I see mention of an emulator in the GitHub repo, but I don’t see any emulator that is available.
>
> Am I reading this wrong?
>
> All that is mentioned is a telnet address to something that just drops.
>
> From: Deborah Scherrer
> Sent: Wednesday, September 25, 2019 5:46 AM
> To: tuhs at minnie.tuhs.org
> Subject: Re: [TUHS] Recovered!!! The Georgia Tech Software Tools Subystemfor Prime Computers
>
> Awesome!!!   Arnold, you're a saint!!!!
> D
>
> On 9/24/19 12:45 PM, Arnold Robbins wrote:
> > Hello All.
> >
> > Believed lost in the mists of time for over 30 years, the Georgia Tech
> > Software Tools Subsystem for Prime Computers, along with the Georgia Tech
> > C Compiler for Prime Computers, have been recovered!
> >
> > The source code and documentation (and binary files) are available in a
> > Github repo: https://github.com/arnoldrobbins/gt-swt.
> >
> > The README.md there provides some brief history and credits with respect
> > to the recovery, and w.r.t. the subsystem and C compilers themselves.
> >
> > Credit to Scott Lee for making and keeping the tapes and driving the
> > recovery process, and to Dennis Boone and yours truly for contributing
> > financially.  I set up the repo.
> >
> > For anyone who used and/or contributed to this software, we hope you'll
> > enjoy this trip down memory lane.
> >
> > Feel free to forward this note to interested parties.
> >
> > Enjoy,
> >
> > Arnold Robbins
> > (On behalf of the swt recovery team. :-)
>

From arnold at skeeve.com  Thu Sep 26 16:13:29 2019
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Thu, 26 Sep 2019 00:13:29 -0600
Subject: [TUHS] Recovered!!! The Georgia Tech Software Tools Subystemfor
 Prime Computers
In-Reply-To: <0c66d8e5-ef8b-4682-b8a0-281c5c7c0359@PU1APC01FT115.eop-APC01.prod.protection.outlook.com>
References: <201909241945.x8OJjTCX032294@skeeve.com>
 <a27b32e1-6b7a-5215-0b29-d5369cda461f@solar.stanford.edu>
 <d515a88b-4851-4d9b-a798-5493139bf816@PU1APC01FT040.eop-APC01.prod.protection.outlook.com>
 <7wo8z7zj96.fsf@junk.nocrew.org>
 <0c66d8e5-ef8b-4682-b8a0-281c5c7c0359@PU1APC01FT115.eop-APC01.prod.protection.outlook.com>
Message-ID: <201909260613.x8Q6DT4u017544@freefriends.org>

Hi.

The emulator is not at all related to GT-SWT.  You can contact
the guy who did it --- read the full message Lars quotes below.

Arnold

Jason Stevens <jsteve at superglobalmegacorp.com> wrote:

> I now get this:
>
> All available connections are in use.                                                                                                                                                                                                           
>
> Connection to host lost.
>                                                                                                                                                                  
>
> I guess progress.
>
> Oh well, I guess it’s not possible to distribute the emulator? 
>
>
> From: Lars Brinkhoff
> Sent: Thursday, September 26, 2019 2:03 PM
> To: Jason Stevens
> Cc: tuhs at minnie.tuhs.org
> Subject: Re: [TUHS] Recovered!!! The Georgia Tech Software Tools Subystemfor Prime Computers
>
> > I see mention of an emulator in the GitHub repo, but I don’t see any
> > emulator that is available.
>
> I see this:
>
> Welcome to the Prime Computer 50-series emulator, running Primos rev 24.0!
>
>   Login as user guest, password pr1me
>   Hit a few returns and Ctrl-q if it appears "stuck"; some bots are hitting the emulator
>   After logging in, use the Prime HELP command for assistance.
>   You are welcome to create a directory under GUEST for your files.
>   The emacs terminal type is xterm
>   The line erase character is ?
>   There are other Primos revs running on ports 8001-8007
>   Prime manuals at: http://yagi.h-net.msu.edu/prime_manuals/prirun_scans
>   To report bugs or contact the author, send email to prirun at gmail.com
>
> Enjoy your time travels!   -Jim Wilcoxson aka JIMMY
>
> Login please.
>
> login guest
> Password?
>
> GUEST (user 2) logged in Thursday, 26 Sep 19 02:03:08.
> Welcome to PRIMOS version 24.0.0.r15
> Copyright (c) Computervision, Corp. 1993.
> Last login Tuesday, 24 Sep 19 19:58:08.
>
>
> Warning!   There was 1 failed attempt to login under this id since the
>            last successful login.
>
> OK,
>

From lars at nocrew.org  Thu Sep 26 16:23:07 2019
From: lars at nocrew.org (Lars Brinkhoff)
Date: Thu, 26 Sep 2019 06:23:07 +0000
Subject: [TUHS] Recovered!!! The Georgia Tech Software Tools Subystemfor
 Prime Computers
In-Reply-To: <0c66d8e5-ef8b-4682-b8a0-281c5c7c0359@PU1APC01FT115.eop-APC01.prod.protection.outlook.com>
 (Jason Stevens's message of "Thu, 26 Sep 2019 14:08:01 +0800")
References: <201909241945.x8OJjTCX032294@skeeve.com>
 <a27b32e1-6b7a-5215-0b29-d5369cda461f@solar.stanford.edu>
 <d515a88b-4851-4d9b-a798-5493139bf816@PU1APC01FT040.eop-APC01.prod.protection.outlook.com>
 <7wo8z7zj96.fsf@junk.nocrew.org>
 <0c66d8e5-ef8b-4682-b8a0-281c5c7c0359@PU1APC01FT115.eop-APC01.prod.protection.outlook.com>
Message-ID: <7wblv7zid0.fsf@junk.nocrew.org>

Jason Stevens wrote:
> Oh well, I guess it’s not possible to distribute the emulator? 

>From what I hear, the main problem is that it's not possible to
distribute PRIMOS.  Which is a shame; it does have Emacs so it must be a
nice operating system.

This this thread is branching off topic anyway, I'll just quickly
mention that I'm currently working on "Small ITS".  An ITS-like
operating system for the MIT Logo group PDP-11/45.  "PDP-11" <- see,
almost back on topic.  Sorry, those who are curious may contact me
privately.

From arnold at skeeve.com  Thu Sep 26 16:27:34 2019
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Thu, 26 Sep 2019 00:27:34 -0600
Subject: [TUHS] Recovered!!! The Georgia Tech Software Tools Subystemfor
 Prime Computers
In-Reply-To: <7wblv7zid0.fsf@junk.nocrew.org>
References: <201909241945.x8OJjTCX032294@skeeve.com>
 <a27b32e1-6b7a-5215-0b29-d5369cda461f@solar.stanford.edu>
 <d515a88b-4851-4d9b-a798-5493139bf816@PU1APC01FT040.eop-APC01.prod.protection.outlook.com>
 <7wo8z7zj96.fsf@junk.nocrew.org>
 <0c66d8e5-ef8b-4682-b8a0-281c5c7c0359@PU1APC01FT115.eop-APC01.prod.protection.outlook.com>
 <7wblv7zid0.fsf@junk.nocrew.org>
Message-ID: <201909260627.x8Q6RYGq017933@freefriends.org>

Lars Brinkhoff <lars at nocrew.org> wrote:

> Jason Stevens wrote:
> > Oh well, I guess it’s not possible to distribute the emulator? 
>
> From what I hear, the main problem is that it's not possible to
> distribute PRIMOS.  Which is a shame; it does have Emacs so it must be a
> nice operating system.

Hahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahaha.

It was bizarre and ugly.  The only thing that made it anywhere
near usable were the Software Tools.

There's a reason Prime died pretty quickly once Unix started to
spread.  The architecture also was strange; the characters used
mark parity (8th bit always on).

My 2 cents.

Arnold

From cym224 at gmail.com  Thu Sep 26 23:28:39 2019
From: cym224 at gmail.com (Nemo)
Date: Thu, 26 Sep 2019 09:28:39 -0400
Subject: [TUHS] Recovered!!! The Georgia Tech Software Tools Subystemfor
 Prime Computers
In-Reply-To: <d515a88b-4851-4d9b-a798-5493139bf816@PU1APC01FT040.eop-APC01.prod.protection.outlook.com>
References: <201909241945.x8OJjTCX032294@skeeve.com>
 <a27b32e1-6b7a-5215-0b29-d5369cda461f@solar.stanford.edu>
 <d515a88b-4851-4d9b-a798-5493139bf816@PU1APC01FT040.eop-APC01.prod.protection.outlook.com>
Message-ID: <CAJfiPzwtHQ_Eqgp9vi8DY4Hi48rJB-pWTxv=M69WWf4gLvQNbQ@mail.gmail.com>

On 26/09/2019, Jason Stevens <jsteve at superglobalmegacorp.com> wrote (in part):
> All that is mentioned is a telnet address to something that just drops.

Some home routers drop incoming telnet.

N.

From clemc at ccc.com  Thu Sep 26 23:28:15 2019
From: clemc at ccc.com (Clem Cole)
Date: Thu, 26 Sep 2019 09:28:15 -0400
Subject: [TUHS] [COFF] [was TUHS] Pr1me and GT-SWT
In-Reply-To: <201909260627.x8Q6RYGq017933@freefriends.org>
References: <201909241945.x8OJjTCX032294@skeeve.com>
 <a27b32e1-6b7a-5215-0b29-d5369cda461f@solar.stanford.edu>
 <d515a88b-4851-4d9b-a798-5493139bf816@PU1APC01FT040.eop-APC01.prod.protection.outlook.com>
 <7wo8z7zj96.fsf@junk.nocrew.org>
 <0c66d8e5-ef8b-4682-b8a0-281c5c7c0359@PU1APC01FT115.eop-APC01.prod.protection.outlook.com>
 <7wblv7zid0.fsf@junk.nocrew.org> <201909260627.x8Q6RYGq017933@freefriends.org>
Message-ID: <CAC20D2P1zJmLOacwjKnnj2_izoN3HRtv7XkacysYeBePxUN4UQ@mail.gmail.com>

At the risk of this drifting, it probably should move over to the COFF
mailing list, which I have CC'ed.   I'll do this one last one here so
people not yet on COFF that want to follow up can see it.

On Thu, Sep 26, 2019 at 2:27 AM <arnold at skeeve.com> wrote:

> It was bizarre and ugly.  The only thing that made it anywhere
> near usable were the Software Tools.
>
Amen...  (more in a minute)

>
> There's a reason Prime died pretty quickly once Unix started to
> spread.  The architecture also was strange; the characters used
> mark parity (8th bit always on).
>
Yeah, it was an interesting box.  Fast and cost-effective for its time and
an excellent Fortran system which why they did as well as they did.

>
> My 2 cents.
>
> Arnold
>
You probably know this but you folks had a huge influence on the Pr1mates.
 So much so when Bill P, Paul L, and Michael S. left Pr1me to create
Apollo, the used your version of the SWT as their first command system for
Aegis (*a.k.a.* DOMAIN OS).   They did not quite get it that they needed a
real UNIX, so they roped tjt and myself from Masscomp went we all formed
Belmont (*a.k.a.* Stellar in a later renaming).  But they did recognize it
was useful and people wanted to use that style of interface, not something
dreamed up specific to that machine.

I remember trying to explain to Bill the difference - he's a vision guy,
but primarily a hardware type, although one of the most amazing people I
have ever known.  IMO: Leach never really understood the Unix ideas of
being simple (which is one of the reasons why Windows has that
forsaken registry sin from Aegis, he brought it with him from Apollo to
MSFT).   I used to argue with him about it in the 1980s (he hated/thought
ASCII text files were terrible and he should control everything in some
framework or privileged API).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190926/fb2b227b/attachment.html>

From spedraja at gmail.com  Fri Sep 27 00:54:31 2019
From: spedraja at gmail.com (SPC)
Date: Thu, 26 Sep 2019 16:54:31 +0200
Subject: [TUHS] Recovered!!! The Georgia Tech Software Tools Subystemfor
 Prime Computers
In-Reply-To: <CAJfiPzwtHQ_Eqgp9vi8DY4Hi48rJB-pWTxv=M69WWf4gLvQNbQ@mail.gmail.com>
References: <201909241945.x8OJjTCX032294@skeeve.com>
 <a27b32e1-6b7a-5215-0b29-d5369cda461f@solar.stanford.edu>
 <d515a88b-4851-4d9b-a798-5493139bf816@PU1APC01FT040.eop-APC01.prod.protection.outlook.com>
 <CAJfiPzwtHQ_Eqgp9vi8DY4Hi48rJB-pWTxv=M69WWf4gLvQNbQ@mail.gmail.com>
Message-ID: <CACytpF8ZtcdrGd4RfJb1-QSJyq26MjET1PnVoR-yioqvWepk8g@mail.gmail.com>

El jue., 26 sept. 2019 15:29, Nemo <cym224 at gmail.com> escribió:

> On 26/09/2019, Jason Stevens <jsteve at superglobalmegacorp.com> wrote (in
> part):
> > All that is mentioned is a telnet address to something that just drops.
>
> Some home routers drop incoming telnet.
>

I got connected without problem a coupoe of days ago. REMEMBER that you
*must* telnet to "em.prirun.com:《port_number》", being the port to use one
of the series from 8001 to 8007. There is one different version of PRIMOS
running at everyone of these ip ports.

Cordiales saludos / Best Regards / Salutations / Freundliche Grüße
-----
Sergio Pedraja
Skype: spedraja at gmail.com

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190926/19b115e7/attachment.html>

From jsteve at superglobalmegacorp.com  Fri Sep 27 01:48:07 2019
From: jsteve at superglobalmegacorp.com (Jason Stevens)
Date: Thu, 26 Sep 2019 15:48:07 +0000 (UTC)
Subject: [TUHS] Recovered!!! The Georgia Tech Software Tools Subystemfor
 Prime Computers
In-Reply-To: <CACytpF8ZtcdrGd4RfJb1-QSJyq26MjET1PnVoR-yioqvWepk8g@mail.gmail.com>
References: <201909241945.x8OJjTCX032294@skeeve.com>
 <a27b32e1-6b7a-5215-0b29-d5369cda461f@solar.stanford.edu>
 <d515a88b-4851-4d9b-a798-5493139bf816@PU1APC01FT040.eop-APC01.prod.protection.outlook.com>
 <CAJfiPzwtHQ_Eqgp9vi8DY4Hi48rJB-pWTxv=M69WWf4gLvQNbQ@mail.gmail.com>
 <CACytpF8ZtcdrGd4RfJb1-QSJyq26MjET1PnVoR-yioqvWepk8g@mail.gmail.com>
Message-ID: <ADFDF14544A65F35.923e89a2-0c07-4498-a634-896f0804a28d@mail.outlook.com>

I did use the port number.  It didn't work as it was either full or just dropping. 




It's too off topic anyways, I guess it'll be some other obscure thing with a C compiler, I guess. 




I guess the excitement is that it's written in Fortran?  I assume it's like those Unix emulation packages for VMS.  Although I've never seen one of those either. 











On Thu, Sep 26, 2019 at 10:54 PM +0800, "SPC" <spedraja at gmail.com> wrote:












El jue., 26 sept. 2019 15:29, Nemo <cym224 at gmail.com> escribió:
On 26/09/2019, Jason Stevens <jsteve at superglobalmegacorp.com> wrote (in part):

> All that is mentioned is a telnet address to something that just drops.



Some home routers drop incoming telnet.

I got connected without problem a coupoe of days ago. REMEMBER that you *must* telnet to "em.prirun.com:«port_number»", being the port to use one of the series from 8001 to 8007. There is one different version of PRIMOS running at everyone of these ip ports.
Cordiales saludos / Best Regards / Salutations / Freundliche Grüße
-----
Sergio Pedraja
Skype: spedraja at gmail.com






-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190926/da6533d9/attachment.html>

From sauer at technologists.com  Fri Sep 27 03:12:30 2019
From: sauer at technologists.com (Charles H Sauer)
Date: Thu, 26 Sep 2019 12:12:30 -0500
Subject: [TUHS] multi-booting four *nix plus 3 Win editions plus OS/2 on
 1992 Dell 486D/50
Message-ID: <28630762-1d91-0013-8d0d-e5f95a294674@technologists.com>

tl;dr multibooting a 1992 Dell 486D/50 
WFW3.11+Win95+Win2K+DellSVR4+NEXTSTEP+RedHat5.2+OS/2 3.0+OpenBSD2.5

https://www.youtube.com/watch?v=GgKjSXI7HOI

(Maybe it should be tl;dw — didn’t watch — the video is long.) This post 
is intended to both be more accessible summary and provide details that 
are not in the video.

https://notes.technologists.com/notes/2019/09/26/koko-welcome-to-eight-jurassic-o-s-on-1992-dell-486d-50/

Charlie
-- 
voice: +1.512.784.7526       e-mail: sauer at technologists.com
fax: +1.512.346.5240         Web: https://technologists.com/sauer/
Facebook/Google/Skype/Twitter: CharlesHSauer

From imp at bsdimp.com  Fri Sep 27 07:14:28 2019
From: imp at bsdimp.com (Warner Losh)
Date: Thu, 26 Sep 2019 15:14:28 -0600
Subject: [TUHS] UNIX NEWS, volumes 1-7 out there?
In-Reply-To: <20190926025437.GC19436@wopr>
References: <CANCZdfpWfxYj5gZ29_EY2kYi_y-hW_KhVOYees+o0MbHyYHLig@mail.gmail.com>
 <CAC20D2O-Fj-=QepT82BTZpeSSFao=x2+eFfkSbg81my0OJ=zeg@mail.gmail.com>
 <20190926025437.GC19436@wopr>
Message-ID: <CANCZdfpOFb0rbvNRrJzJB_kVJWfR9NeGnKBr=4WtnuDVWLZ_Rw@mail.gmail.com>

On Wed, Sep 25, 2019 at 8:54 PM Kurt H Maier <khm at sciops.net> wrote:

> On Wed, Sep 25, 2019 at 11:30:47AM -0400, Clem Cole wrote:
> > On Wed, Sep 25, 2019 at 11:16 AM Warner Losh <imp at bsdimp.com> wrote:
> >
> > > I'm looking for complete compies of UNIX NEWS volumes 1-7. 8 and newer
> are
> >
> > FYI: the folks at USENIX has been looking for these for a number of
> years.
> >  Let me know if you find copies of them and I will get them pushed back
> to
> > the USENIX archives.
>
> I have a large swath of #4, dated 19 March 1976, if we're talking about
> the same thing.  I've scanned it in at 600 dpi:
>   http://sciops.net/images/unix-news/1976-03-19/


Awesome... Yes. That sort of thing. I'm trying to pull together things like
this...

I fear Clem may be right, but I sure hope he's wrong....  History suggests
I'd be unwise to bet too much against him...  If he's wrong, it will be
only in the small...

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190926/333eedb7/attachment.html>

From clemc at ccc.com  Fri Sep 27 07:35:27 2019
From: clemc at ccc.com (Clem Cole)
Date: Thu, 26 Sep 2019 17:35:27 -0400
Subject: [TUHS] UNIX NEWS, volumes 1-7 out there?
In-Reply-To: <CANCZdfpOFb0rbvNRrJzJB_kVJWfR9NeGnKBr=4WtnuDVWLZ_Rw@mail.gmail.com>
References: <CANCZdfpWfxYj5gZ29_EY2kYi_y-hW_KhVOYees+o0MbHyYHLig@mail.gmail.com>
 <CAC20D2O-Fj-=QepT82BTZpeSSFao=x2+eFfkSbg81my0OJ=zeg@mail.gmail.com>
 <20190926025437.GC19436@wopr>
 <CANCZdfpOFb0rbvNRrJzJB_kVJWfR9NeGnKBr=4WtnuDVWLZ_Rw@mail.gmail.com>
Message-ID: <CAC20D2M9pWUrmD=U6xtd0XNkUs1vgBwsnL3v2_e11uuQSORGGQ@mail.gmail.com>

On Thu, Sep 26, 2019 at 5:14 PM Warner Losh <imp at bsdimp.com> wrote:

>
>
> On Wed, Sep 25, 2019 at 8:54 PM Kurt H Maier <khm at sciops.net> wrote:
>
>> On Wed, Sep 25, 2019 at 11:30:47AM -0400, Clem Cole wrote:
>> > On Wed, Sep 25, 2019 at 11:16 AM Warner Losh <imp at bsdimp.com> wrote:
>> >
>> > > I'm looking for complete compies of UNIX NEWS volumes 1-7. 8 and
>> newer are
>> >
>> > FYI: the folks at USENIX has been looking for these for a number of
>> years.
>> >  Let me know if you find copies of them and I will get them pushed back
>> to
>> > the USENIX archives.
>>
>> I have a large swath of #4, dated 19 March 1976, if we're talking about
>> the same thing.  I've scanned it in at 600 dpi:
>>   http://sciops.net/images/unix-news/1976-03-19/
>
>
> Awesome... Yes. That sort of thing. I'm trying to pull together things
> like this...
>
> I fear Clem may be right, but I sure hope he's wrong....
>
I would *love* to be proven otherwise.   I'm thrilled to see what Kurt has
found!!!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190926/37c50e61/attachment.html>

From wkt at tuhs.org  Sat Sep 28 12:02:30 2019
From: wkt at tuhs.org (Warren Toomey)
Date: Sat, 28 Sep 2019 12:02:30 +1000
Subject: [TUHS] Poll: good location for Unix documentation?
Message-ID: <20190928020230.GB18235@minnie.tuhs.org>

All, I'm just musing where is the best place to store Unix documentation.
My Unix Archive is really just a filesystem, so it's not so good to
capture and search metadata.

Is anybody using archive.org, gunkies or something else, and have
recommendations?

Cheers, Warren

From wkt at tuhs.org  Sat Sep 28 12:10:46 2019
From: wkt at tuhs.org (Warren Toomey)
Date: Sat, 28 Sep 2019 12:10:46 +1000
Subject: [TUHS] Poll: good location for Unix documentation?
In-Reply-To: <20190928020230.GB18235@minnie.tuhs.org>
References: <20190928020230.GB18235@minnie.tuhs.org>
Message-ID: <20190928021046.GA20696@minnie.tuhs.org>

On Sat, Sep 28, 2019 at 12:02:30PM +1000, Warren Toomey wrote:
> Is anybody using archive.org, gunkies or something else, and have
> recommendations?

Argh, bitsavers too, sorry Al, I forgot!
	Warren

From athornton at gmail.com  Sat Sep 28 12:38:05 2019
From: athornton at gmail.com (Adam Thornton)
Date: Fri, 27 Sep 2019 19:38:05 -0700
Subject: [TUHS] Poll: good location for Unix documentation?
In-Reply-To: <20190928020230.GB18235@minnie.tuhs.org>
References: <20190928020230.GB18235@minnie.tuhs.org>
Message-ID: <1AE27AAC-A1BB-4484-8518-769E849BBB6C@gmail.com>



> On Sep 27, 2019, at 7:02 PM, Warren Toomey <wkt at tuhs.org> wrote:
> 
> All, I'm just musing where is the best place to store Unix documentation.
> My Unix Archive is really just a filesystem, so it's not so good to
> capture and search metadata.
> 
> Is anybody using archive.org, gunkies or something else, and have
> recommendations?


I know Jason Scott at archive.org <http://archive.org/> and I trust him.  Bitsavers is also, obviously, known to be good.

I don’t know who’s behind gunkies but it seems like they have good stuff.

I would say: it’s not YOUR job to organize the metadata, it’s the search engines’.  Just hosting the docs and making them available for index is probably a lot of the battle.

Adam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190927/ec22e0be/attachment.html>

From lars at nocrew.org  Sat Sep 28 14:56:35 2019
From: lars at nocrew.org (Lars Brinkhoff)
Date: Sat, 28 Sep 2019 04:56:35 +0000
Subject: [TUHS] Poll: good location for Unix documentation?
In-Reply-To: <20190928021046.GA20696@minnie.tuhs.org> (Warren Toomey's message
 of "Sat, 28 Sep 2019 12:10:46 +1000")
References: <20190928020230.GB18235@minnie.tuhs.org>
 <20190928021046.GA20696@minnie.tuhs.org>
Message-ID: <7wk19tt3wc.fsf@junk.nocrew.org>

I like bitsavers.

Gunikes is a wiki, maybe not appropriate for uploading documents?

From jsteve at superglobalmegacorp.com  Sun Sep 29 18:25:20 2019
From: jsteve at superglobalmegacorp.com (Jason Stevens)
Date: Sun, 29 Sep 2019 08:25:20 +0000 (UTC)
Subject: [TUHS] Poll: good location for Unix documentation?
In-Reply-To: <20190928020230.GB18235@minnie.tuhs.org>
References: <20190928020230.GB18235@minnie.tuhs.org>
Message-ID: <ADFDF14544A65F35.821b4786-c942-4523-9b18-24b03c8fe5ab@mail.outlook.com>

Gunkies.org is a wiki that is really good for pointing to stuff, and things like tutorials, indexes and other non original stuff. 




Archive.org is a great dumping ground for stuff, although it's easy to get lost in the shuffle. 




I'm not an admin on gunkies.org but I do get my email at least answered, so if you have no luck trying to create an account I'll bug the owner to make it happen. 




When I had more spare time I tried to seed gunkies with as much as I could. 




Get Outlook for Android







On Sat, Sep 28, 2019 at 11:03 AM +0900, "Warren Toomey" <wkt at tuhs.org> wrote:










All, I'm just musing where is the best place to store Unix documentation.
My Unix Archive is really just a filesystem, so it's not so good to
capture and search metadata.

Is anybody using archive.org, gunkies or something else, and have
recommendations?

Cheers, Warren





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190929/f232a15b/attachment.html>

From spedraja at gmail.com  Sun Sep 29 18:52:50 2019
From: spedraja at gmail.com (SPC)
Date: Sun, 29 Sep 2019 10:52:50 +0200
Subject: [TUHS] Poll: good location for Unix documentation?
In-Reply-To: <20190928020230.GB18235@minnie.tuhs.org>
References: <20190928020230.GB18235@minnie.tuhs.org>
Message-ID: <CACytpF_KFnV=JE7rhJ1zaBO0qU1B=HR_evyi3M2hot=fBHnM1w@mail.gmail.com>

El sáb., 28 sept. 2019 4:03, Warren Toomey <wkt at tuhs.org> escribió:

>
> Is anybody using archive.org, gunkies or something else, and have
> recommendations?
>

I use archive.org *a lot* of times in relation with a wide number of
topics. Iam very happy with the results but I must admit that it's huge and
sometimes a bit confused. On the other hand a diverse kind of files can be
stored, mostly multimedia and pdf/ps/text. I think binary files too but not
as EXE. ISO images or similar are more usual.

Cordiales saludos / Best Regards / Salutations / Freundliche Grüße
-----
Sergio Pedraja

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190929/bf1e1da0/attachment.html>

From wkt at tuhs.org  Sun Sep 29 19:21:58 2019
From: wkt at tuhs.org (Warren Toomey)
Date: Sun, 29 Sep 2019 19:21:58 +1000
Subject: [TUHS] OT: compiler back-end bug
Message-ID: <20190929092158.GA27566@minnie.tuhs.org>

All, very off-topic for TUHS but you have a bounty of experience. If any
of you have Intel ia64 skills and/or fixing compiler back-end bugs, could
you contact me off-list? I'm writing a back-end for the SubC compiler and
I have 'one last bug'™ before it can compile itself, and I'm stuck.

Details at: https://minnie.tuhs.org/wktcloud/index.php/s/QdKZAqcBytoFBkQ/download?path=%2F&files=help.txt

Thanks, Warren

From ralph at inputplus.co.uk  Sun Sep 29 19:47:26 2019
From: ralph at inputplus.co.uk (Ralph Corderoy)
Date: Sun, 29 Sep 2019 10:47:26 +0100
Subject: [TUHS] OT: compiler back-end bug
In-Reply-To: <20190929092158.GA27566@minnie.tuhs.org>
References: <20190929092158.GA27566@minnie.tuhs.org>
Message-ID: <20190929094726.6488620154@orac.inputplus.co.uk>

Hi Warren,

> If any of you have Intel ia64 skills and/or fixing compiler back-end
> bugs, could you contact me off-list?

Sorry, on list, but it may help the willing eyeballs if

> To see the original compiler's assembly version of fwrite():
>
>         $ ./scc0 -S lib/fwrite.c
>
> To see my compiler's [faulty] assembly version of fwrite():
>
>         $ ./myscc -S lib/fwrite.c

these two were made easily available, e.g. a pastebin like 

    curl -sSF 'f:1=<-' ix.io <lib/fwrite.c

as then spotting the cause of

> At present, my compiler fwrite() code is passing bogus arguments to
> memcpy() where it crashes with a segfault.

wouldn't involve downloads, make, etc., that make it easy to think one
doesn't have the time to look.  :-)

-- 
Cheers, Ralph.

From wkt at tuhs.org  Sun Sep 29 20:03:36 2019
From: wkt at tuhs.org (Warren Toomey)
Date: Sun, 29 Sep 2019 20:03:36 +1000
Subject: [TUHS] OT: compiler back-end bug
In-Reply-To: <20190929094726.6488620154@orac.inputplus.co.uk>
References: <20190929092158.GA27566@minnie.tuhs.org>
 <20190929094726.6488620154@orac.inputplus.co.uk>
Message-ID: <20190929100336.GA2390@minnie.tuhs.org>

On Sun, Sep 29, 2019 at 10:47:26AM +0100, Ralph Corderoy wrote:
> these two were made easily available, e.g. a pastebin like 
> wouldn't involve downloads, make, etc., that make it easy to think one
> doesn't have the time to look.  :-)

Good point Ralph:
https://minnie.tuhs.org/wktcloud/index.php/s/HQjsggHb4i6wdWM?path=%2FSfiles

Thanks! Warren

From ralph at inputplus.co.uk  Sun Sep 29 20:50:16 2019
From: ralph at inputplus.co.uk (Ralph Corderoy)
Date: Sun, 29 Sep 2019 11:50:16 +0100
Subject: [TUHS] OT: compiler back-end bug
In-Reply-To: <20190929100336.GA2390@minnie.tuhs.org>
References: <20190929092158.GA27566@minnie.tuhs.org>
 <20190929094726.6488620154@orac.inputplus.co.uk>
 <20190929100336.GA2390@minnie.tuhs.org>
Message-ID: <20190929105016.92665200AB@orac.inputplus.co.uk>

Hi Warren,

> Good point Ralph:
> https://minnie.tuhs.org/wktcloud/index.php/s/HQjsggHb4i6wdWM?path=%2FSfiles

I've always tried to avoid x86 and friends for ARM, so I may be wrong,
but the run up to the first of the two memcpy() calls looks the same to
me.  Here's the assembler, values given an RBP of 100, and the stack
contents.  Good version first, bad second.

                                rbp = 100
    L29:
        movq  -8(%rbp),%rax     rax = *92
        pushq %rax                                            *92
        movq  16(%rbp),%rax     rax = *116
        pushq %rax                                            *92 *116
        movq  $64,%rax          rax = 64
        pushq %rax                                            *92 *116 64
        movq  32(%rbp),%rax     rax = *132
        popq  %rcx              rcx = 64                      *92 *116
        addq  %rcx,%rax         rcx = 64+*132
        movq  (%rax),%rax       rax = *(64+*132)
        pushq %rax                                            *92 *116 *(64+*132)
        movq  $40,%rax          rax = 40
        pushq %rax                                            *92 *116 *(64+*132) 40
        movq  32(%rbp),%rax     rax = *132
        popq  %rcx              rcx = 40                      *92 *116 *(64+*132)
        addq  %rcx,%rax         rax = 40+*132
        movq  (%rax),%rax       rax = *(40+*132)
        popq  %rcx              rcx = *(64+*132)              *92 *116
        addq  %rcx,%rax         rax = *(64+*132)+*(40+*132)
        pushq %rax                                            *92 *116 *(64+*132)+*(40+*132)
        call  Cmemcpy

                                rbp = 100
    L29:
        movq  -8(%rbp),%r8      r8 = *92
        pushq %r8                                             *92
        movq  16(%rbp),%r8      r8 = *116
        pushq %r8                                             *92 *116
        movq  $64,%r8           r8 = 64
        movq  32(%rbp),%r9      r9 = *132
        addq  %r9,%r8           r8 = *132+64
        movq  (%r8),%r8         r8 = *(*132+64)
        movq  $40,%r9           r9 = 40
        movq  32(%rbp),%r10     r10 = *132
        addq  %r10,%r9          r9 = *132+40
        movq  (%r9),%r9         r9 = *(*132+40)
        addq  %r9,%r8           r8 = *(*132+64)+*(*132+40)
        pushq %r8                                             *92 *116 *(*132+64)+*(*132+40)
        call  Cmemcpy

A glance at the second memcpy() call look equivalent too.

So perhaps it's not calculating the parameters to memcpy() that's wrong,
but the inputs into those calculations being faulty?  I'd use gdb(1) to
break at particular instructions, examine memory, etc., to work
backwards through the bad version until spotting where good data becomes
bad.

-- 
Cheers, Ralph.

From jnc at mercury.lcs.mit.edu  Mon Sep 30 04:53:20 2019
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Sun, 29 Sep 2019 14:53:20 -0400 (EDT)
Subject: [TUHS] Poll: good location for Unix documentation?
Message-ID: <20190929185320.5902C18C088@mercury.lcs.mit.edu>

    > From: Warren Toomey

    > All, I'm just musing where is the best place to store Unix
    > documentation. My Unix Archive is really just a filesystem, so it's not
    > so good to capture and search metadata.
    > Is anybody using archive.org, gunkies or something else

BitSavers seems to be the canonical location for old computer documentation.

The CHWiki (gunkies.org) isn't really the best place to put original documentation,
but that's where I'd recommend putting meta-data. As for searching meta-data, are
you speaking of something more powerful than Google?

    Noel

PS: Speaking of old Unix documentation, I recently acquired a paper copy of the
PDP-11 V6 Unix manual. Is that something I should scan? I don't know if you
already have it (I know where to find sources in the archives, but I don't
know where documentation scans live.)

From blstuart at bellsouth.net  Mon Sep 30 06:11:52 2019
From: blstuart at bellsouth.net (Brian L. Stuart)
Date: Sun, 29 Sep 2019 20:11:52 +0000 (UTC)
Subject: [TUHS] Poll: good location for Unix documentation?
In-Reply-To: <20190929185320.5902C18C088@mercury.lcs.mit.edu>
References: <20190929185320.5902C18C088@mercury.lcs.mit.edu>
Message-ID: <643282730.657492.1569787912823@mail.yahoo.com>

 On Sunday, September 29, 2019, 2:53:52 PM EDT, Noel Chiappa <jnc at mercury.lcs.mit.edu> wrote:
> PS: Speaking of old Unix documentation, I recently acquired a paper copy of the
> PDP-11 V6 Unix manual. Is that something I should scan? I don't know if you
> already have it (I know where to find sources in the archives, but I don't
> know where documentation scans live.)

I was looking for a copy of that for my exhibit at VCF southeast
this year, but I never could find a complete copy. There's a
mostly complete scan on archive.org, but there are some bits
missing. I'd have to do a little digging to say just which bits,
though. (The tmg doc was one I remember not being there.)

BLS
  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190929/427c08a1/attachment.html>

From clemc at ccc.com  Mon Sep 30 06:23:24 2019
From: clemc at ccc.com (Clem Cole)
Date: Sun, 29 Sep 2019 16:23:24 -0400
Subject: [TUHS] Poll: good location for Unix documentation?
In-Reply-To: <20190929185320.5902C18C088@mercury.lcs.mit.edu>
References: <20190929185320.5902C18C088@mercury.lcs.mit.edu>
Message-ID: <CAC20D2M+qj4RQvM1ZC9f93RCWKH24LB9id96F9cRUjZqJO83hA@mail.gmail.com>

On Sun, Sep 29, 2019 at 2:54 PM Noel Chiappa <jnc at mercury.lcs.mit.edu>
wrote:

>     > From: Warren Toomey
>
>     > All, I'm just musing where is the best place to store Unix
>     > documentation. My Unix Archive is really just a filesystem, so it's
> not
>     > so good to capture and search metadata.
>     > Is anybody using archive.org, gunkies or something else
>
> BitSavers seems to be the canonical location for old computer
> documentation.
>
I agree +1 BitSavers, but Warren you should keep your stuff.   One-stop
shopping for UNIX archives is a good thing.



>
> The CHWiki (gunkies.org) isn't really the best place to put original
> documentation,
> but that's where I'd recommend putting meta-data. As for searching
> meta-data, are
> you speaking of something more powerful than Google?
>
>     Noel
>
> PS: Speaking of old Unix documentation, I recently acquired a paper copy
> of the
> PDP-11 V6 Unix manual. Is that something I should scan? I don't know if you
> already have it (I know where to find sources in the archives, but I don't
> know where documentation scans live.)
>
What I personally have is impure, and I have not seen a complete one
elsewhere, so if you have a real manual, that is a good thing IMHO.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190929/8a7e22b8/attachment.html>

From wkt at tuhs.org  Mon Sep 30 07:34:46 2019
From: wkt at tuhs.org (Warren Toomey)
Date: Mon, 30 Sep 2019 07:34:46 +1000
Subject: [TUHS] Poll: good location for Unix documentation?
In-Reply-To: <20190929185320.5902C18C088@mercury.lcs.mit.edu>
References: <20190929185320.5902C18C088@mercury.lcs.mit.edu>
Message-ID: <20190929213446.GA30379@minnie.tuhs.org>

On Sun, Sep 29, 2019 at 02:53:20PM -0400, Noel Chiappa wrote:
> BitSavers seems to be the canonical location for old computer documentation.

Looks like BitSavers is the recommendation. Can someone point me at the
docs that outline the procedure to get documents to Al (others as well?) for
consideration.

I might put things in both bitsavers.org and archive.org.

Cheers, Warren

From jnc at mercury.lcs.mit.edu  Mon Sep 30 07:54:20 2019
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Sun, 29 Sep 2019 17:54:20 -0400 (EDT)
Subject: [TUHS] Poll: good location for Unix documentation?
Message-ID: <20190929215420.567C018C092@mercury.lcs.mit.edu>

    > From: "Brian L. Stuart"

    > (The tmg doc was one I remember not being there.)

Err, TMG(VI) is 1/2 page long. Is that really what you were looking for?
(I _did_ specify the 'UPM'.)

I do happen to have the V6-era TMG _manual_, if that's what you're looking
for.

   Noel

From dave at horsfall.org  Mon Sep 30 08:40:24 2019
From: dave at horsfall.org (Dave Horsfall)
Date: Mon, 30 Sep 2019 08:40:24 +1000 (EST)
Subject: [TUHS] Poll: good location for Unix documentation?
In-Reply-To: <20190929213446.GA30379@minnie.tuhs.org>
References: <20190929185320.5902C18C088@mercury.lcs.mit.edu>
 <20190929213446.GA30379@minnie.tuhs.org>
Message-ID: <alpine.BSF.2.21.9999.1909300839320.19040@aneurin.horsfall.org>

On Mon, 30 Sep 2019, Warren Toomey wrote:

> I might put things in both bitsavers.org and archive.org.

A bit of redundancy won't hurt...

-- Dave

From earl.baugh at gmail.com  Mon Sep 30 09:02:45 2019
From: earl.baugh at gmail.com (Earl Baugh)
Date: Sun, 29 Sep 2019 19:02:45 -0400
Subject: [TUHS] Poll: good location for Unix documentation?
In-Reply-To: <20190929213446.GA30379@minnie.tuhs.org>
References: <20190929213446.GA30379@minnie.tuhs.org>
Message-ID: <D0F905DE-8215-4884-911B-27FA98E495AB@gmail.com>

I really would suggest first and foremost just getting stuff scanned. Archive.org does pull from bitsavers ( according to Jason when I talked to him ) so posting there should hit both. Redundancy is good. So keeping it on your site as well doesn’t hurt. And having TUHS as a place to look at to start makes a lot of sense to me. 

Earl 

Sent from my iPhone

> On Sep 29, 2019, at 5:35 PM, Warren Toomey <wkt at tuhs.org> wrote:
> 
> ﻿On Sun, Sep 29, 2019 at 02:53:20PM -0400, Noel Chiappa wrote:
>> BitSavers seems to be the canonical location for old computer documentation.
> 
> Looks like BitSavers is the recommendation. Can someone point me at the
> docs that outline the procedure to get documents to Al (others as well?) for
> consideration.
> 
> I might put things in both bitsavers.org and archive.org.
> 
> Cheers, Warren

From blstuart at bellsouth.net  Mon Sep 30 09:03:05 2019
From: blstuart at bellsouth.net (Brian L. Stuart)
Date: Sun, 29 Sep 2019 23:03:05 +0000 (UTC)
Subject: [TUHS] Poll: good location for Unix documentation?
In-Reply-To: <20190929215420.567C018C092@mercury.lcs.mit.edu>
References: <20190929215420.567C018C092@mercury.lcs.mit.edu>
Message-ID: <1281188580.691065.1569798185056@mail.yahoo.com>

 On Sunday, September 29, 2019, 5:54:24 PM EDT, Noel Chiappa <jnc at mercury.lcs.mit.edu> wrote:
> > From: "Brian L. Stuart"
> > (The tmg doc was one I remember not being there.)
>
> Err, TMG(VI) is 1/2 page long. Is that really what you were looking for?
> (I _did_ specify the 'UPM'.)

My bad. I missed that part. Wishful thinking had me
thinking it included the docs as well as the man pages.

> I do happen to have the V6-era TMG _manual_, if that's what you're looking
> for.

It's one of the items I haven't yet found from the 6th ed
docs. The M6 manual is another one that I didn't find.
So far, I haven't found a scan of the docs that WE
shipped with the tape.

BLS
  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190929/ae3b687d/attachment.html>

From imp at bsdimp.com  Mon Sep 30 11:13:28 2019
From: imp at bsdimp.com (Warner Losh)
Date: Sun, 29 Sep 2019 19:13:28 -0600
Subject: [TUHS] Poll: good location for Unix documentation?
In-Reply-To: <1281188580.691065.1569798185056@mail.yahoo.com>
References: <20190929215420.567C018C092@mercury.lcs.mit.edu>
 <1281188580.691065.1569798185056@mail.yahoo.com>
Message-ID: <CANCZdfqCSsyaMOFh-HXLThd1TYM6i-G=nTc7EV2t_uY+TDiD_Q@mail.gmail.com>

On Sun, Sep 29, 2019, 6:12 PM Brian L. Stuart <blstuart at bellsouth.net>
wrote:

> On Sunday, September 29, 2019, 5:54:24 PM EDT, Noel Chiappa <
> jnc at mercury.lcs.mit.edu> wrote:
> > > From: "Brian L. Stuart"
> > > (The tmg doc was one I remember not being there.)
> >
> > Err, TMG(VI) is 1/2 page long. Is that really what you were looking for?
> > (I _did_ specify the 'UPM'.)
>
> My bad. I missed that part. Wishful thinking had me
> thinking it included the docs as well as the man pages.
>
> > I do happen to have the V6-era TMG _manual_, if that's what you're
> looking
> > for.
>
> It's one of the items I haven't yet found from the 6th ed
> docs.
>

https://www.tuhs.org/Archive/Distributions/Research/1972_stuff/tmg.pdf has
an earlier version.

The M6 manual is another one that I didn't find.
> So far, I haven't found a scan of the docs
>

Ebay number 113713199572 might be of interest.

Warner


BLS
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190929/1e1ce3de/attachment.html>

