The Unix Heritage Society mailing list
 help / Atom feed
* [TUHS] PWB vs Unix/TS
@ 2019-09-09  6:25 Warner Losh
  2019-09-09  6:36 ` arnold
  2019-09-10 15:16 ` Clem Cole
  0 siblings, 2 replies; 81+ messages in thread
From: Warner Losh @ 2019-09-09  6:25 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 918 bytes --]

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...

[-- Attachment #2: Type: text/html, Size: 1116 bytes --]

^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [TUHS] PWB vs Unix/TS
  2019-09-09  6:25 [TUHS] PWB vs Unix/TS Warner Losh
@ 2019-09-09  6:36 ` arnold
  2019-09-10 15:16 ` Clem Cole
  1 sibling, 0 replies; 81+ messages in thread
From: arnold @ 2019-09-09  6:36 UTC (permalink / raw)
  To: tuhs, imp

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@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...

^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [TUHS] PWB vs Unix/TS
  2019-09-09  6:25 [TUHS] PWB vs Unix/TS Warner Losh
  2019-09-09  6:36 ` arnold
@ 2019-09-10 15:16 ` Clem Cole
  2019-09-11  0:28   ` Steve Johnson
                     ` (3 more replies)
  1 sibling, 4 replies; 81+ messages in thread
From: Clem Cole @ 2019-09-10 15:16 UTC (permalink / raw)
  To: Warner Losh; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 13538 bytes --]

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@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

[-- Attachment #2: Type: text/html, Size: 27527 bytes --]

^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [TUHS] PWB vs Unix/TS
  2019-09-10 15:16 ` Clem Cole
@ 2019-09-11  0:28   ` Steve Johnson
  2019-09-11  3:53   ` Warner Losh
                     ` (2 subsequent siblings)
  3 siblings, 0 replies; 81+ messages in thread
From: Steve Johnson @ 2019-09-11  0:28 UTC (permalink / raw)
  To: Clem Cole, Warner Losh; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 18015 bytes --]

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@ccc.com>

To:
"Warner Losh" <imp@bsdimp.com>
Cc:
"The Eunuchs Hysterical Society" <tuhs@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@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@bsdimp.com
[2]
https://www.computerhistory.org/atchm/the-asilomar-microcomputer-workshop-and-the-billion-dollar-toilet-seat/


[-- Attachment #2: Type: text/html, Size: 32647 bytes --]

^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [TUHS] PWB vs Unix/TS
  2019-09-10 15:16 ` Clem Cole
  2019-09-11  0:28   ` Steve Johnson
@ 2019-09-11  3:53   ` Warner Losh
  2019-09-11 15:36     ` Clem Cole
  2019-09-11 16:05   ` [TUHS] PWB vs Unix/TS Paul Winalski
  2019-09-14  0:44   ` [TUHS] a book (was Re: PWB vs Unix/TS) reed
  3 siblings, 1 reply; 81+ messages in thread
From: Warner Losh @ 2019-09-11  3:53 UTC (permalink / raw)
  To: Clem Cole; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 16060 bytes --]

On Tue, Sep 10, 2019 at 9:17 AM Clem Cole <clemc@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@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
>

[-- Attachment #2: Type: text/html, Size: 31275 bytes --]

^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [TUHS] PWB vs Unix/TS
  2019-09-11  3:53   ` Warner Losh
@ 2019-09-11 15:36     ` Clem Cole
  2019-09-11 16:55       ` [TUHS] IBM Unix source licenses [was " Charles H Sauer
                         ` (2 more replies)
  0 siblings, 3 replies; 81+ messages in thread
From: Clem Cole @ 2019-09-11 15:36 UTC (permalink / raw)
  To: Warner Losh; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 8732 bytes --]

below...

On Tue, Sep 10, 2019 at 11:53 PM Warner Losh <imp@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.

[-- Attachment #2: Type: text/html, Size: 16240 bytes --]

^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [TUHS] PWB vs Unix/TS
  2019-09-10 15:16 ` Clem Cole
  2019-09-11  0:28   ` Steve Johnson
  2019-09-11  3:53   ` Warner Losh
@ 2019-09-11 16:05   ` Paul Winalski
  2019-09-11 17:14     ` ron
  2019-09-14  0:44   ` [TUHS] a book (was Re: PWB vs Unix/TS) reed
  3 siblings, 1 reply; 81+ messages in thread
From: Paul Winalski @ 2019-09-11 16:05 UTC (permalink / raw)
  To: Clem Cole; +Cc: The Eunuchs Hysterical Society

>On 9/10/19, Clem Cole <clemc@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.

^ permalink raw reply	[flat|nested] 81+ messages in thread

* [TUHS] IBM Unix source licenses [was Re:  PWB vs Unix/TS
  2019-09-11 15:36     ` Clem Cole
@ 2019-09-11 16:55       ` " Charles H Sauer
  2019-09-12 19:31         ` Kevin Bowling
  2019-09-11 17:49       ` [TUHS] " Richard Salz
  2019-09-11 18:11       ` Larry McVoy
  2 siblings, 1 reply; 81+ messages in thread
From: Charles H Sauer @ 2019-09-11 16:55 UTC (permalink / raw)
  To: tuhs

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@technologists.com
fax: +1.512.346.5240         Web: https://technologists.com/sauer/
Facebook/Google/Skype/Twitter: CharlesHSauer

^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [TUHS] PWB vs Unix/TS
  2019-09-11 16:05   ` [TUHS] PWB vs Unix/TS Paul Winalski
@ 2019-09-11 17:14     ` ron
  0 siblings, 0 replies; 81+ messages in thread
From: ron @ 2019-09-11 17:14 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

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.



^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [TUHS] PWB vs Unix/TS
  2019-09-11 15:36     ` Clem Cole
  2019-09-11 16:55       ` [TUHS] IBM Unix source licenses [was " Charles H Sauer
@ 2019-09-11 17:49       ` " Richard Salz
  2019-09-11 17:52         ` ron
  2019-09-11 18:11       ` Larry McVoy
  2 siblings, 1 reply; 81+ messages in thread
From: Richard Salz @ 2019-09-11 17:49 UTC (permalink / raw)
  To: Clem Cole; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 597 bytes --]

> 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. :)

[-- Attachment #2: Type: text/html, Size: 1325 bytes --]

^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [TUHS] PWB vs Unix/TS
  2019-09-11 17:49       ` [TUHS] " Richard Salz
@ 2019-09-11 17:52         ` ron
  2019-09-11 21:44           ` Clem Cole
  0 siblings, 1 reply; 81+ messages in thread
From: ron @ 2019-09-11 17:52 UTC (permalink / raw)
  To: Richard Salz, Clem Cole; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 1122 bytes --]

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@minnie.tuhs.org> On Behalf Of Richard Salz
Sent: Wednesday, September 11, 2019 1:49 PM
To: Clem Cole <clemc@ccc.com>
Cc: The Eunuchs Hysterical Society <tuhs@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. :)

 


[-- Attachment #2: Type: text/html, Size: 3573 bytes --]

^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [TUHS] PWB vs Unix/TS
  2019-09-11 15:36     ` Clem Cole
  2019-09-11 16:55       ` [TUHS] IBM Unix source licenses [was " Charles H Sauer
  2019-09-11 17:49       ` [TUHS] " Richard Salz
@ 2019-09-11 18:11       ` Larry McVoy
  2019-09-11 18:18         ` Richard Salz
                           ` (2 more replies)
  2 siblings, 3 replies; 81+ messages in thread
From: Larry McVoy @ 2019-09-11 18:11 UTC (permalink / raw)
  To: Clem Cole; +Cc: The Eunuchs Hysterical Society

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.

^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [TUHS] PWB vs Unix/TS
  2019-09-11 18:11       ` Larry McVoy
@ 2019-09-11 18:18         ` Richard Salz
  2019-09-11 18:54           ` Larry McVoy
  2019-09-11 21:59           ` Clem Cole
  2019-09-11 21:50         ` Clem Cole
  2019-09-11 22:49         ` Dave Horsfall
  2 siblings, 2 replies; 81+ messages in thread
From: Richard Salz @ 2019-09-11 18:18 UTC (permalink / raw)
  To: Larry McVoy; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 265 bytes --]

>
>   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.

[-- Attachment #2: Type: text/html, Size: 565 bytes --]

^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [TUHS] PWB vs Unix/TS
  2019-09-11 18:18         ` Richard Salz
@ 2019-09-11 18:54           ` Larry McVoy
  2019-09-11 21:05             ` Steve Johnson
                               ` (2 more replies)
  2019-09-11 21:59           ` Clem Cole
  1 sibling, 3 replies; 81+ messages in thread
From: Larry McVoy @ 2019-09-11 18:54 UTC (permalink / raw)
  To: Richard Salz; +Cc: The Eunuchs Hysterical Society

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.

^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [TUHS] PWB vs Unix/TS
  2019-09-11 18:54           ` Larry McVoy
@ 2019-09-11 21:05             ` Steve Johnson
  2019-09-11 21:34             ` Steve Johnson
  2019-09-11 21:57             ` Clem Cole
  2 siblings, 0 replies; 81+ messages in thread
From: Steve Johnson @ 2019-09-11 21:05 UTC (permalink / raw)
  To: Larry McVoy, Richard Salz; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 1664 bytes --]


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@mcvoy.com>
To:"Richard Salz" <rich.salz@gmail.com>
Cc:"The Eunuchs Hysterical Society" <tuhs@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.



[-- Attachment #2: Type: text/html, Size: 2431 bytes --]

^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [TUHS] PWB vs Unix/TS
  2019-09-11 18:54           ` Larry McVoy
  2019-09-11 21:05             ` Steve Johnson
@ 2019-09-11 21:34             ` Steve Johnson
  2019-09-11 21:57             ` Clem Cole
  2 siblings, 0 replies; 81+ messages in thread
From: Steve Johnson @ 2019-09-11 21:34 UTC (permalink / raw)
  To: Larry McVoy, Richard Salz; +Cc: The Eunuchs Hysterical Society, Brian Kernighan

[-- Attachment #1: Type: text/plain, Size: 2012 bytes --]


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@mcvoy.com>
To:"Richard Salz" <rich.salz@gmail.com>
Cc:"The Eunuchs Hysterical Society" <tuhs@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.



[-- Attachment #2: Type: text/html, Size: 2890 bytes --]

^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [TUHS] PWB vs Unix/TS
  2019-09-11 17:52         ` ron
@ 2019-09-11 21:44           ` Clem Cole
  0 siblings, 0 replies; 81+ messages in thread
From: Clem Cole @ 2019-09-11 21:44 UTC (permalink / raw)
  To: Ronald Natalie; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 808 bytes --]

On Wed, Sep 11, 2019 at 1:52 PM <ron@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 ;-)

[-- Attachment #2: Type: text/html, Size: 2203 bytes --]

^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [TUHS] PWB vs Unix/TS
  2019-09-11 18:11       ` Larry McVoy
  2019-09-11 18:18         ` Richard Salz
@ 2019-09-11 21:50         ` Clem Cole
  2019-09-11 22:49         ` Dave Horsfall
  2 siblings, 0 replies; 81+ messages in thread
From: Clem Cole @ 2019-09-11 21:50 UTC (permalink / raw)
  To: Larry McVoy; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 815 bytes --]

On Wed, Sep 11, 2019 at 2:11 PM Larry McVoy <lm@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.

[-- Attachment #2: Type: text/html, Size: 1547 bytes --]

^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [TUHS] PWB vs Unix/TS
  2019-09-11 18:54           ` Larry McVoy
  2019-09-11 21:05             ` Steve Johnson
  2019-09-11 21:34             ` Steve Johnson
@ 2019-09-11 21:57             ` Clem Cole
  2019-09-11 22:50               ` Arthur Krewat
  2 siblings, 1 reply; 81+ messages in thread
From: Clem Cole @ 2019-09-11 21:57 UTC (permalink / raw)
  To: Larry McVoy; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 789 bytes --]

On Wed, Sep 11, 2019 at 2:54 PM Larry McVoy <lm@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.

[-- Attachment #2: Type: text/html, Size: 2076 bytes --]

^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [TUHS] PWB vs Unix/TS
  2019-09-11 18:18         ` Richard Salz
  2019-09-11 18:54           ` Larry McVoy
@ 2019-09-11 21:59           ` Clem Cole
  1 sibling, 0 replies; 81+ messages in thread
From: Clem Cole @ 2019-09-11 21:59 UTC (permalink / raw)
  To: Richard Salz; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 376 bytes --]

On Wed, Sep 11, 2019 at 2:18 PM Richard Salz <rich.salz@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.

[-- Attachment #2: Type: text/html, Size: 1088 bytes --]

^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [TUHS] PWB vs Unix/TS
  2019-09-11 18:11       ` Larry McVoy
  2019-09-11 18:18         ` Richard Salz
  2019-09-11 21:50         ` Clem Cole
@ 2019-09-11 22:49         ` Dave Horsfall
  2019-09-12  3:43           ` [TUHS] SCCS Larry McVoy
  2 siblings, 1 reply; 81+ messages in thread
From: Dave Horsfall @ 2019-09-11 22:49 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

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

^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [TUHS] PWB vs Unix/TS
  2019-09-11 21:57             ` Clem Cole
@ 2019-09-11 22:50               ` Arthur Krewat
  0 siblings, 0 replies; 81+ messages in thread
From: Arthur Krewat @ 2019-09-11 22:50 UTC (permalink / raw)
  To: tuhs

[-- Attachment #1: Type: text/plain, Size: 1415 bytes --]

On 9/11/2019 5:57 PM, Clem Cole wrote:
>
>
> On Wed, Sep 11, 2019 at 2:54 PM Larry McVoy <lm@mcvoy.com 
> <mailto:lm@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

[-- Attachment #2: Type: text/html, Size: 2840 bytes --]

^ permalink raw reply	[flat|nested] 81+ messages in thread

* [TUHS] SCCS
  2019-09-11 22:49         ` Dave Horsfall
@ 2019-09-12  3:43           ` Larry McVoy
  2019-09-12  4:20             ` George Michaelson
                               ` (2 more replies)
  0 siblings, 3 replies; 81+ messages in thread
From: Larry McVoy @ 2019-09-12  3:43 UTC (permalink / raw)
  To: Dave Horsfall; +Cc: The Eunuchs Hysterical Society, rick

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

^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [TUHS] SCCS
  2019-09-12  3:43           ` [TUHS] SCCS Larry McVoy
@ 2019-09-12  4:20             ` George Michaelson
  2019-09-12  4:31               ` [TUHS] [SPAM] SCCS Larry McVoy
  2019-09-12  4:28             ` [TUHS] SCCS Jon Forrest
  2019-09-12 20:07             ` Nemo
  2 siblings, 1 reply; 81+ messages in thread
From: George Michaelson @ 2019-09-12  4:20 UTC (permalink / raw)
  To: Larry McVoy; +Cc: The Eunuchs Hysterical Society, rick

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@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

^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [TUHS] SCCS
  2019-09-12  3:43           ` [TUHS] SCCS Larry McVoy
  2019-09-12  4:20             ` George Michaelson
@ 2019-09-12  4:28             ` Jon Forrest
  2019-09-12  4:33               ` Larry McVoy
  2019-09-12 16:45               ` Eric Allman
  2019-09-12 20:07             ` Nemo
  2 siblings, 2 replies; 81+ messages in thread
From: Jon Forrest @ 2019-09-12  4:28 UTC (permalink / raw)
  To: tuhs



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

^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [TUHS] [SPAM] Re:  SCCS
  2019-09-12  4:20             ` George Michaelson
@ 2019-09-12  4:31               ` Larry McVoy
  2019-09-12 13:44                 ` Tony Finch
  0 siblings, 1 reply; 81+ messages in thread
From: Larry McVoy @ 2019-09-12  4:31 UTC (permalink / raw)
  To: George Michaelson; +Cc: The Eunuchs Hysterical Society, rick

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@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 

^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [TUHS] SCCS
  2019-09-12  4:28             ` [TUHS] SCCS Jon Forrest
@ 2019-09-12  4:33               ` Larry McVoy
  2019-09-12  6:12                 ` William Corcoran
  2019-09-13  5:22                 ` Dave Horsfall
  2019-09-12 16:45               ` Eric Allman
  1 sibling, 2 replies; 81+ messages in thread
From: Larry McVoy @ 2019-09-12  4:33 UTC (permalink / raw)
  To: Jon Forrest; +Cc: tuhs

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 

^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [TUHS] SCCS
  2019-09-12  4:33               ` Larry McVoy
@ 2019-09-12  6:12                 ` William Corcoran
  2019-09-12 14:35                   ` Clem Cole
  2019-09-13  5:22                 ` Dave Horsfall
  1 sibling, 1 reply; 81+ messages in thread
From: William Corcoran @ 2019-09-12  6:12 UTC (permalink / raw)
  To: Larry McVoy; +Cc: tuhs

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@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 

^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [TUHS] [SPAM] Re:  SCCS
  2019-09-12  4:31               ` [TUHS] [SPAM] SCCS Larry McVoy
@ 2019-09-12 13:44                 ` Tony Finch
  2019-09-13  4:11                   ` Larry McVoy
  0 siblings, 1 reply; 81+ messages in thread
From: Tony Finch @ 2019-09-12 13:44 UTC (permalink / raw)
  To: Larry McVoy; +Cc: The Eunuchs Hysterical Society

Larry McVoy <lm@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@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.

^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [TUHS] SCCS
  2019-09-12  6:12                 ` William Corcoran
@ 2019-09-12 14:35                   ` Clem Cole
  0 siblings, 0 replies; 81+ messages in thread
From: Clem Cole @ 2019-09-12 14:35 UTC (permalink / raw)
  To: Larry McVoy, tuhs

[-- Attachment #1: Type: text/plain, Size: 4592 bytes --]

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.

[-- Attachment #2: Type: text/html, Size: 7363 bytes --]

^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [TUHS] SCCS
  2019-09-12  4:28             ` [TUHS] SCCS Jon Forrest
  2019-09-12  4:33               ` Larry McVoy
@ 2019-09-12 16:45               ` Eric Allman
  2019-09-12 17:29                 ` Clem Cole
  1 sibling, 1 reply; 81+ messages in thread
From: Eric Allman @ 2019-09-12 16:45 UTC (permalink / raw)
  To: Jon Forrest, tuhs

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

^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [TUHS] SCCS
  2019-09-12 16:45               ` Eric Allman
@ 2019-09-12 17:29                 ` Clem Cole
  2019-09-12 17:47                   ` Warner Losh
  2019-09-13  8:12                   ` emanuel stiebler
  0 siblings, 2 replies; 81+ messages in thread
From: Clem Cole @ 2019-09-12 17:29 UTC (permalink / raw)
  To: Eric Allman; +Cc: TUHS main list

[-- Attachment #1: Type: text/plain, Size: 441 bytes --]

On Thu, Sep 12, 2019 at 1:16 PM Eric Allman <tuhs@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

[-- Attachment #2: Type: text/html, Size: 1029 bytes --]

^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [TUHS] SCCS
  2019-09-12 17:29                 ` Clem Cole
@ 2019-09-12 17:47                   ` Warner Losh
  2019-09-13  8:12                   ` emanuel stiebler
  1 sibling, 0 replies; 81+ messages in thread
From: Warner Losh @ 2019-09-12 17:47 UTC (permalink / raw)
  To: Clem Cole; +Cc: TUHS main list

[-- Attachment #1: Type: text/plain, Size: 920 bytes --]

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

>
>
> On Thu, Sep 12, 2019 at 1:16 PM Eric Allman <tuhs@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

>

[-- Attachment #2: Type: text/html, Size: 2112 bytes --]

^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [TUHS] IBM Unix source licenses [was Re: PWB vs Unix/TS
  2019-09-11 16:55       ` [TUHS] IBM Unix source licenses [was " Charles H Sauer
@ 2019-09-12 19:31         ` Kevin Bowling
  2019-09-12 20:59           ` Clem Cole
  2019-09-12 21:29           ` [TUHS] IBM Unix source licenses [was Re: PWB vs Unix/TS Charles H Sauer
  0 siblings, 2 replies; 81+ messages in thread
From: Kevin Bowling @ 2019-09-12 19:31 UTC (permalink / raw)
  To: Charles H Sauer; +Cc: TUHS main list

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@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@technologists.com
> fax: +1.512.346.5240         Web: https://technologists.com/sauer/
> Facebook/Google/Skype/Twitter: CharlesHSauer

^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [TUHS] SCCS
  2019-09-12  3:43           ` [TUHS] SCCS Larry McVoy
  2019-09-12  4:20             ` George Michaelson
  2019-09-12  4:28             ` [TUHS] SCCS Jon Forrest
@ 2019-09-12 20:07             ` Nemo
  2 siblings, 0 replies; 81+ messages in thread
From: Nemo @ 2019-09-12 20:07 UTC (permalink / raw)
  To: Larry McVoy; +Cc: The Eunuchs Hysterical Society

On 11/09/2019, Larry McVoy <lm@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.

^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [TUHS] IBM Unix source licenses [was Re: PWB vs Unix/TS
  2019-09-12 19:31         ` Kevin Bowling
@ 2019-09-12 20:59           ` Clem Cole
  2019-09-12 21:09             ` [TUHS] IBM Unix source licenses - Series/1 NUXI Ronald Natalie
                               ` (2 more replies)
  2019-09-12 21:29           ` [TUHS] IBM Unix source licenses [was Re: PWB vs Unix/TS Charles H Sauer
  1 sibling, 3 replies; 81+ messages in thread
From: Clem Cole @ 2019-09-12 20:59 UTC (permalink / raw)
  To: Kevin Bowling; +Cc: TUHS main list

[-- Attachment #1: Type: text/plain, Size: 1767 bytes --]

Kevin/Charlie:

On Thu, Sep 12, 2019 at 3:31 PM Kevin Bowling <kevin.bowling@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.

[-- Attachment #2: Type: text/html, Size: 3216 bytes --]

^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [TUHS] IBM Unix source licenses - Series/1 NUXI
  2019-09-12 20:59           ` Clem Cole
@ 2019-09-12 21:09             ` Ronald Natalie
  2019-09-12 21:31             ` [TUHS] IBM Unix source licenses [was Re: PWB vs Unix/TS Warner Losh
  2019-09-12 22:30             ` jcs
  2 siblings, 0 replies; 81+ messages in thread
From: Ronald Natalie @ 2019-09-12 21:09 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 3192 bytes --]

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@ccc.com> wrote:
> 
> Kevin/Charlie:
> 
> On Thu, Sep 12, 2019 at 3:31 PM Kevin Bowling <kevin.bowling@kev009.com <mailto:kevin.bowling@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. 


[-- Attachment #2: Type: text/html, Size: 5479 bytes --]

^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [TUHS] IBM Unix source licenses [was Re: PWB vs Unix/TS
  2019-09-12 19:31         ` Kevin Bowling
  2019-09-12 20:59           ` Clem Cole
@ 2019-09-12 21:29           ` Charles H Sauer
  1 sibling, 0 replies; 81+ messages in thread
From: Charles H Sauer @ 2019-09-12 21:29 UTC (permalink / raw)
  To: Kevin Bowling; +Cc: TUHS main list



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@technologists.com
fax: +1.512.346.5240         Web: https://technologists.com/sauer/
Facebook/Google/Skype/Twitter: CharlesHSauer

^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [TUHS] IBM Unix source licenses [was Re: PWB vs Unix/TS
  2019-09-12 20:59           ` Clem Cole
  2019-09-12 21:09             ` [TUHS] IBM Unix source licenses - Series/1 NUXI Ronald Natalie
@ 2019-09-12 21:31             ` Warner Losh
  2019-09-12 22:30             ` jcs
  2 siblings, 0 replies; 81+ messages in thread
From: Warner Losh @ 2019-09-12 21:31 UTC (permalink / raw)
  To: Clem Cole; +Cc: TUHS main list

[-- Attachment #1: Type: text/plain, Size: 2008 bytes --]

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

> Kevin/Charlie:
>
> On Thu, Sep 12, 2019 at 3:31 PM Kevin Bowling <kevin.bowling@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

[-- Attachment #2: Type: text/html, Size: 3700 bytes --]

^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [TUHS] IBM Unix source licenses [was Re: PWB vs Unix/TS
  2019-09-12 20:59           ` Clem Cole
  2019-09-12 21:09             ` [TUHS] IBM Unix source licenses - Series/1 NUXI Ronald Natalie
  2019-09-12 21:31             ` [TUHS] IBM Unix source licenses [was Re: PWB vs Unix/TS Warner Losh
@ 2019-09-12 22:30             ` jcs
  2019-09-12 23:12               ` reed
  2019-09-12 23:29               ` [TUHS] IBM Unix source licenses Warren Toomey
  2 siblings, 2 replies; 81+ messages in thread
From: jcs @ 2019-09-12 22:30 UTC (permalink / raw)
  To: tuhs


Clem Cole <clemc@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

^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [TUHS] IBM Unix source licenses [was Re: PWB vs Unix/TS
  2019-09-12 22:30             ` jcs
@ 2019-09-12 23:12               ` reed
  2019-09-12 23:22                 ` jcs
  2019-09-12 23:29               ` [TUHS] IBM Unix source licenses Warren Toomey
  1 sibling, 1 reply; 81+ messages in thread
From: reed @ 2019-09-12 23:12 UTC (permalink / raw)
  To: jcs; +Cc: tuhs

On Thu, 12 Sep 2019, jcs wrote:

> 
> Clem Cole <clemc@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.)

^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [TUHS] IBM Unix source licenses [was Re: PWB vs Unix/TS
  2019-09-12 23:12               ` reed
@ 2019-09-12 23:22                 ` jcs
  0 siblings, 0 replies; 81+ messages in thread
From: jcs @ 2019-09-12 23:22 UTC (permalink / raw)
  To: reed; +Cc: tuhs


reed@reedmedia.net writes:

> On Thu, 12 Sep 2019, jcs wrote:
>
>> 
>> Clem Cole <clemc@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.

^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [TUHS] IBM Unix source licenses
  2019-09-12 22:30             ` jcs
  2019-09-12 23:12               ` reed
@ 2019-09-12 23:29               ` Warren Toomey
  2019-09-13  7:06                 ` arnold
  2019-09-13  8:30                 ` SPC
  1 sibling, 2 replies; 81+ messages in thread
From: Warren Toomey @ 2019-09-12 23:29 UTC (permalink / raw)
  Cc: tuhs

Clem Cole <clemc@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

^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [TUHS] [SPAM] Re:  SCCS
  2019-09-12 13:44                 ` Tony Finch
@ 2019-09-13  4:11                   ` Larry McVoy
  2019-09-13  5:54                     ` Dave Horsfall
  0 siblings, 1 reply; 81+ messages in thread
From: Larry McVoy @ 2019-09-13  4:11 UTC (permalink / raw)
  To: Tony Finch; +Cc: The Eunuchs Hysterical Society

On Thu, Sep 12, 2019 at 02:44:45PM +0100, Tony Finch wrote:
> Larry McVoy <lm@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

^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [TUHS] SCCS
  2019-09-12  4:33               ` Larry McVoy
  2019-09-12  6:12                 ` William Corcoran
@ 2019-09-13  5:22                 ` Dave Horsfall
  2019-09-13  5:50                   ` Bakul Shah
  1 sibling, 1 reply; 81+ messages in thread
From: Dave Horsfall @ 2019-09-13  5:22 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

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

^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [TUHS] SCCS
  2019-09-13  5:22                 ` Dave Horsfall
@ 2019-09-13  5:50                   ` Bakul Shah
  0 siblings, 0 replies; 81+ messages in thread
From: Bakul Shah @ 2019-09-13  5:50 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

On Fri, 13 Sep 2019 15:22:58 +1000 Dave Horsfall <dave@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.

^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [TUHS] [SPAM] Re:  SCCS
  2019-09-13  4:11                   ` Larry McVoy
@ 2019-09-13  5:54                     ` Dave Horsfall
  2019-09-13  8:00                       ` Peter Jeremy
  0 siblings, 1 reply; 81+ messages in thread
From: Dave Horsfall @ 2019-09-13  5:54 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

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

^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [TUHS] IBM Unix source licenses
  2019-09-12 23:29               ` [TUHS] IBM Unix source licenses Warren Toomey
@ 2019-09-13  7:06                 ` arnold
  2019-09-13  8:30                 ` SPC
  1 sibling, 0 replies; 81+ messages in thread
From: arnold @ 2019-09-13  7:06 UTC (permalink / raw)
  To: wkt; +Cc: tuhs

Warren Toomey <wkt@tuhs.org> wrote:

> Clem Cole <clemc@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

^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [TUHS] [SPAM] Re:  SCCS
  2019-09-13  5:54                     ` Dave Horsfall
@ 2019-09-13  8:00                       ` Peter Jeremy
  2019-09-13 15:23                         ` Larry McVoy
  2019-09-13 21:36                         ` Dave Horsfall
  0 siblings, 2 replies; 81+ messages in thread
From: Peter Jeremy @ 2019-09-13  8:00 UTC (permalink / raw)
  To: Dave Horsfall; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 1027 bytes --]

On 2019-Sep-13 15:54:32 +1000, Dave Horsfall <dave@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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [TUHS] SCCS
  2019-09-12 17:29                 ` Clem Cole
  2019-09-12 17:47                   ` Warner Losh
@ 2019-09-13  8:12                   ` emanuel stiebler
  2019-09-13 21:11                     ` Steffen Nurpmeso
  1 sibling, 1 reply; 81+ messages in thread
From: emanuel stiebler @ 2019-09-13  8:12 UTC (permalink / raw)
  To: Clem Cole, Eric Allman; +Cc: TUHS main list

On 2019-09-12 19:29, Clem Cole wrote:
> 
> 
> On Thu, Sep 12, 2019 at 1:16 PM Eric Allman <tuhs@eric.allman.name
> <mailto:tuhs@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/

^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [TUHS] IBM Unix source licenses
  2019-09-12 23:29               ` [TUHS] IBM Unix source licenses Warren Toomey
  2019-09-13  7:06                 ` arnold
@ 2019-09-13  8:30                 ` SPC
  2019-09-14 18:29                   ` Warner Losh
  1 sibling, 1 reply; 81+ messages in thread
From: SPC @ 2019-09-13  8:30 UTC (permalink / raw)
  To: Warren Toomey; +Cc: tuhs

[-- Attachment #1: Type: text/plain, Size: 696 bytes --]

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

> Clem Cole <clemc@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*

[-- Attachment #2: Type: text/html, Size: 2647 bytes --]

^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [TUHS] [SPAM] Re:  SCCS
  2019-09-13  8:00                       ` Peter Jeremy
@ 2019-09-13 15:23                         ` Larry McVoy
  2019-09-13 21:36                         ` Dave Horsfall
  1 sibling, 0 replies; 81+ messages in thread
From: Larry McVoy @ 2019-09-13 15:23 UTC (permalink / raw)
  To: Peter Jeremy; +Cc: The Eunuchs Hysterical Society

On Fri, Sep 13, 2019 at 06:00:09PM +1000, Peter Jeremy wrote:
> On 2019-Sep-13 15:54:32 +1000, Dave Horsfall <dave@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.

^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [TUHS] SCCS
  2019-09-13  8:12                   ` emanuel stiebler
@ 2019-09-13 21:11                     ` Steffen Nurpmeso
  2019-09-13 21:17                       ` Larry McVoy
  0 siblings, 1 reply; 81+ messages in thread
From: Steffen Nurpmeso @ 2019-09-13 21:11 UTC (permalink / raw)
  To: emanuel stiebler; +Cc: TUHS main list

emanuel stiebler wrote in <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@eric.allman.name
 |> <mailto:tuhs@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)

^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [TUHS] SCCS
  2019-09-13 21:11                     ` Steffen Nurpmeso
@ 2019-09-13 21:17                       ` Larry McVoy
  2019-09-13 21:48                         ` Bakul Shah
  2019-09-13 23:03                         ` Steffen Nurpmeso
  0 siblings, 2 replies; 81+ messages in thread
From: Larry McVoy @ 2019-09-13 21:17 UTC (permalink / raw)
  To: emanuel stiebler, Clem Cole, Eric Allman, TUHS main list

On Fri, Sep 13, 2019 at 11:11:04PM +0200, Steffen Nurpmeso wrote:
> emanuel stiebler wrote in <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@eric.allman.name
>  |> <mailto:tuhs@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).

^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [TUHS] [SPAM] Re:  SCCS
  2019-09-13  8:00                       ` Peter Jeremy
  2019-09-13 15:23                         ` Larry McVoy
@ 2019-09-13 21:36                         ` Dave Horsfall
  1 sibling, 0 replies; 81+ messages in thread
From: Dave Horsfall @ 2019-09-13 21:36 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

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

^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [TUHS] SCCS
  2019-09-13 21:17                       ` Larry McVoy
@ 2019-09-13 21:48                         ` Bakul Shah
  2019-09-13 23:12                           ` Steffen Nurpmeso
  2019-09-13 23:03                         ` Steffen Nurpmeso
  1 sibling, 1 reply; 81+ messages in thread
From: Bakul Shah @ 2019-09-13 21:48 UTC (permalink / raw)
  To: TUHS main list

On Fri, 13 Sep 2019 14:17:51 -0700 Larry McVoy <lm@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.

^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [TUHS] SCCS
  2019-09-13 21:17                       ` Larry McVoy
  2019-09-13 21:48                         ` Bakul Shah
@ 2019-09-13 23:03                         ` Steffen Nurpmeso
  2019-09-14  1:55                           ` [TUHS] [SPAM] SCCS Larry McVoy
  1 sibling, 1 reply; 81+ messages in thread
From: Steffen Nurpmeso @ 2019-09-13 23:03 UTC (permalink / raw)
  To: Larry McVoy; +Cc: Joerg.Schilling, TUHS main list

Larry McVoy wrote in <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@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@eric.allman.name
 |>|> <mailto:tuhs@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)

^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [TUHS] SCCS
  2019-09-13 21:48                         ` Bakul Shah
@ 2019-09-13 23:12                           ` Steffen Nurpmeso
  0 siblings, 0 replies; 81+ messages in thread
From: Steffen Nurpmeso @ 2019-09-13 23:12 UTC (permalink / raw)
  To: Bakul Shah; +Cc: TUHS main list

Bakul Shah wrote in <20190913214905.339ED1570CE9@mail.bitblocks.com>:
 |On Fri, 13 Sep 2019 14:17:51 -0700 Larry McVoy <lm@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)

^ permalink raw reply	[flat|nested] 81+ messages in thread

* [TUHS] a book (was Re:  PWB vs Unix/TS)
  2019-09-10 15:16 ` Clem Cole
                     ` (2 preceding siblings ...)
  2019-09-11 16:05   ` [TUHS] PWB vs Unix/TS Paul Winalski
@ 2019-09-14  0:44   ` reed
  2019-09-14  2:53     ` Warner Losh
                       ` (2 more replies)
  3 siblings, 3 replies; 81+ messages in thread
From: reed @ 2019-09-14  0:44 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

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"

^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [TUHS] [SPAM] Re:  SCCS
  2019-09-13 23:03                         ` Steffen Nurpmeso
@ 2019-09-14  1:55                           ` Larry McVoy
  2019-09-16 17:23                             ` [TUHS] SCCS Steffen Nurpmeso
  0 siblings, 1 reply; 81+ messages in thread
From: Larry McVoy @ 2019-09-14  1:55 UTC (permalink / raw)
  To: Larry McVoy, emanuel stiebler, Clem Cole, Eric Allman,
	TUHS main list, Joerg.Schilling

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

^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [TUHS] a book (was Re: PWB vs Unix/TS)
  2019-09-14  0:44   ` [TUHS] a book (was Re: PWB vs Unix/TS) reed
@ 2019-09-14  2:53     ` Warner Losh
  2019-09-15  2:18       ` Jon Steinhart
  2019-09-14 22:46     ` Clem cole
  2019-09-15  7:43     ` Andy Kosela
  2 siblings, 1 reply; 81+ messages in thread
From: Warner Losh @ 2019-09-14  2:53 UTC (permalink / raw)
  To: Jeremy C. Reed; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 3946 bytes --]

On Fri, Sep 13, 2019 at 7:31 PM <reed@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"
>

[-- Attachment #2: Type: text/html, Size: 5171 bytes --]

^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [TUHS] IBM Unix source licenses
  2019-09-13  8:30                 ` SPC
@ 2019-09-14 18:29                   ` Warner Losh
  0 siblings, 0 replies; 81+ messages in thread
From: Warner Losh @ 2019-09-14 18:29 UTC (permalink / raw)
  To: SPC; +Cc: TUHS main list

[-- Attachment #1: Type: text/plain, Size: 876 bytes --]

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

>
> El vie., 13 sept. 2019 a las 1:29, Warren Toomey (<wkt@tuhs.org>)
> escribió:
>
>> Clem Cole <clemc@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*
>
>

[-- Attachment #2: Type: text/html, Size: 3490 bytes --]

^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [TUHS] a book (was Re:  PWB vs Unix/TS)
  2019-09-14  0:44   ` [TUHS] a book (was Re: PWB vs Unix/TS) reed
  2019-09-14  2:53     ` Warner Losh
@ 2019-09-14 22:46     ` Clem cole
  2019-09-15  0:58       ` Adam Thornton
  2019-09-15  7:43     ` Andy Kosela
  2 siblings, 1 reply; 81+ messages in thread
From: Clem cole @ 2019-09-14 22:46 UTC (permalink / raw)
  To: reed; +Cc: The Eunuchs Hysterical Society

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@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"

^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [TUHS] a book (was Re: PWB vs Unix/TS)
  2019-09-14 22:46     ` Clem cole
@ 2019-09-15  0:58       ` Adam Thornton
  2019-09-15  3:30         ` Eric Allman
  0 siblings, 1 reply; 81+ messages in thread
From: Adam Thornton @ 2019-09-15  0:58 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 4323 bytes --]

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@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@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"
>

[-- Attachment #2: Type: text/html, Size: 5309 bytes --]

^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [TUHS] a book (was Re: PWB vs Unix/TS)
  2019-09-14  2:53     ` Warner Losh
@ 2019-09-15  2:18       ` Jon Steinhart
  2019-09-15  2:39         ` Clem Cole
  2019-09-15  3:24         ` Adam Thornton
  0 siblings, 2 replies; 81+ messages in thread
From: Jon Steinhart @ 2019-09-15  2:18 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

On Fri, Sep 13, 2019 at 7:31 PM <reed@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

^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [TUHS] a book (was Re: PWB vs Unix/TS)
  2019-09-15  2:18       ` Jon Steinhart
@ 2019-09-15  2:39         ` Clem Cole
  2019-09-15  3:24         ` Adam Thornton
  1 sibling, 0 replies; 81+ messages in thread
From: Clem Cole @ 2019-09-15  2:39 UTC (permalink / raw)
  To: Jon Steinhart; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 1147 bytes --]

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

> On Fri, Sep 13, 2019 at 7:31 PM <reed@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

[-- Attachment #2: Type: text/html, Size: 1644 bytes --]

^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [TUHS] a book (was Re: PWB vs Unix/TS)
  2019-09-15  2:18       ` Jon Steinhart
  2019-09-15  2:39         ` Clem Cole
@ 2019-09-15  3:24         ` Adam Thornton
  1 sibling, 0 replies; 81+ messages in thread
From: Adam Thornton @ 2019-09-15  3:24 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 1513 bytes --]

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@fourwinds.com> wrote:

> On Fri, Sep 13, 2019 at 7:31 PM <reed@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
>

[-- Attachment #2: Type: text/html, Size: 2062 bytes --]

^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [TUHS] a book (was Re: PWB vs Unix/TS)
  2019-09-15  0:58       ` Adam Thornton
@ 2019-09-15  3:30         ` Eric Allman
  2019-09-15  4:21           ` Larry McVoy
  2019-09-15 20:12           ` Clem Cole
  0 siblings, 2 replies; 81+ messages in thread
From: Eric Allman @ 2019-09-15  3:30 UTC (permalink / raw)
  To: Adam Thornton, The Eunuchs Hysterical Society

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

^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [TUHS] a book (was Re: PWB vs Unix/TS)
  2019-09-15  3:30         ` Eric Allman
@ 2019-09-15  4:21           ` Larry McVoy
  2019-09-15  5:17             ` Jon Steinhart
  2019-09-15 20:12           ` Clem Cole
  1 sibling, 1 reply; 81+ messages in thread
From: Larry McVoy @ 2019-09-15  4:21 UTC (permalink / raw)
  To: Eric Allman; +Cc: The Eunuchs Hysterical Society

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.

^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [TUHS] a book (was Re: PWB vs Unix/TS)
  2019-09-15  4:21           ` Larry McVoy
@ 2019-09-15  5:17             ` Jon Steinhart
  2019-09-15 20:14               ` Clem Cole
  0 siblings, 1 reply; 81+ messages in thread
From: Jon Steinhart @ 2019-09-15  5:17 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

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

^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [TUHS] a book (was Re: PWB vs Unix/TS)
  2019-09-14  0:44   ` [TUHS] a book (was Re: PWB vs Unix/TS) reed
  2019-09-14  2:53     ` Warner Losh
  2019-09-14 22:46     ` Clem cole
@ 2019-09-15  7:43     ` Andy Kosela
  2 siblings, 0 replies; 81+ messages in thread
From: Andy Kosela @ 2019-09-15  7:43 UTC (permalink / raw)
  To: reed; +Cc: The Eunuchs Hysterical Society

On Saturday, September 14, 2019, <reed@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

^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [TUHS] a book (was Re: PWB vs Unix/TS)
  2019-09-15  3:30         ` Eric Allman
  2019-09-15  4:21           ` Larry McVoy
@ 2019-09-15 20:12           ` Clem Cole
  2019-09-15 21:28             ` Dave Horsfall
  1 sibling, 1 reply; 81+ messages in thread
From: Clem Cole @ 2019-09-15 20:12 UTC (permalink / raw)
  To: Eric Allman; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 2804 bytes --]

On Sun, Sep 15, 2019 at 12:16 AM Eric Allman <tuhs@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.

[-- Attachment #2: Type: text/html, Size: 7571 bytes --]

^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [TUHS] a book (was Re: PWB vs Unix/TS)
  2019-09-15  5:17             ` Jon Steinhart
@ 2019-09-15 20:14               ` Clem Cole
  2019-09-15 20:21                 ` Jon Steinhart
  0 siblings, 1 reply; 81+ messages in thread
From: Clem Cole @ 2019-09-15 20:14 UTC (permalink / raw)
  To: Jon Steinhart; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 386 bytes --]

On Sun, Sep 15, 2019 at 1:18 AM Jon Steinhart <jon@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...

[-- Attachment #2: Type: text/html, Size: 1359 bytes --]

^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [TUHS] a book (was Re: PWB vs Unix/TS)
  2019-09-15 20:14               ` Clem Cole
@ 2019-09-15 20:21                 ` Jon Steinhart
  0 siblings, 0 replies; 81+ messages in thread
From: Jon Steinhart @ 2019-09-15 20:21 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

Clem Cole writes:
>
> On Sun, Sep 15, 2019 at 1:18 AM Jon Steinhart <jon@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

^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [TUHS] a book (was Re: PWB vs Unix/TS)
  2019-09-15 20:12           ` Clem Cole
@ 2019-09-15 21:28             ` Dave Horsfall
  2019-09-15 23:27               ` Clem cole
  0 siblings, 1 reply; 81+ messages in thread
From: Dave Horsfall @ 2019-09-15 21:28 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 734 bytes --]

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

^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [TUHS] a book (was Re: PWB vs Unix/TS)
  2019-09-15 21:28             ` Dave Horsfall
@ 2019-09-15 23:27               ` Clem cole
  2019-09-15 23:45                 ` Richard Salz
  0 siblings, 1 reply; 81+ messages in thread
From: Clem cole @ 2019-09-15 23:27 UTC (permalink / raw)
  To: Dave Horsfall; +Cc: The Eunuchs Hysterical Society

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@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

^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [TUHS] a book (was Re: PWB vs Unix/TS)
  2019-09-15 23:27               ` Clem cole
@ 2019-09-15 23:45                 ` Richard Salz
  0 siblings, 0 replies; 81+ messages in thread
From: Richard Salz @ 2019-09-15 23:45 UTC (permalink / raw)
  To: Clem cole; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 395 bytes --]

> 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

[-- Attachment #2: Type: text/html, Size: 770 bytes --]

^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [TUHS] SCCS
  2019-09-14  1:55                           ` [TUHS] [SPAM] SCCS Larry McVoy
@ 2019-09-16 17:23                             ` Steffen Nurpmeso
  2019-09-16 20:31                               ` Larry McVoy
  2019-09-18  8:48                               ` Eric Allman
  0 siblings, 2 replies; 81+ messages in thread
From: Steffen Nurpmeso @ 2019-09-16 17:23 UTC (permalink / raw)
  To: Larry McVoy; +Cc: Jörg Schilling, TUHS main list

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@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)

^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [TUHS] SCCS
  2019-09-16 17:23                             ` [TUHS] SCCS Steffen Nurpmeso
@ 2019-09-16 20:31                               ` Larry McVoy
  2019-09-17 17:57                                 ` Steffen Nurpmeso
  2019-09-18  8:48                               ` Eric Allman
  1 sibling, 1 reply; 81+ messages in thread
From: Larry McVoy @ 2019-09-16 20:31 UTC (permalink / raw)
  To: Larry McVoy, emanuel stiebler, Clem Cole, Eric Allman,
	TUHS main list, J??rg Schilling

On Mon, Sep 16, 2019 at 07:23:00PM +0200, Steffen Nurpmeso wrote:
> Larry McVoy wrote in <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.
> 
> 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

^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [TUHS] SCCS
  2019-09-16 20:31                               ` Larry McVoy
@ 2019-09-17 17:57                                 ` Steffen Nurpmeso
  0 siblings, 0 replies; 81+ messages in thread
From: Steffen Nurpmeso @ 2019-09-17 17:57 UTC (permalink / raw)
  To: Larry McVoy; +Cc: Jörg Schilling, TUHS main list

Larry McVoy wrote in <20190916203152.GB9704@mcvoy.com>:
 |On Mon, Sep 16, 2019 at 07:23:00PM +0200, Steffen Nurpmeso wrote:
 |> Larry McVoy wrote in <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.
 |> 
 |> 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@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)

^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [TUHS] SCCS
  2019-09-16 17:23                             ` [TUHS] SCCS Steffen Nurpmeso
  2019-09-16 20:31                               ` Larry McVoy
@ 2019-09-18  8:48                               ` Eric Allman
  1 sibling, 0 replies; 81+ messages in thread
From: Eric Allman @ 2019-09-18  8:48 UTC (permalink / raw)
  To: TUHS main list

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

^ permalink raw reply	[flat|nested] 81+ messages in thread

end of thread, back to index

Thread overview: 81+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-09-09  6:25 [TUHS] PWB vs Unix/TS Warner Losh
2019-09-09  6:36 ` arnold
2019-09-10 15:16 ` Clem Cole
2019-09-11  0:28   ` Steve Johnson
2019-09-11  3:53   ` Warner Losh
2019-09-11 15:36     ` Clem Cole
2019-09-11 16:55       ` [TUHS] IBM Unix source licenses [was " Charles H Sauer
2019-09-12 19:31         ` Kevin Bowling
2019-09-12 20:59           ` Clem Cole
2019-09-12 21:09             ` [TUHS] IBM Unix source licenses - Series/1 NUXI Ronald Natalie
2019-09-12 21:31             ` [TUHS] IBM Unix source licenses [was Re: PWB vs Unix/TS Warner Losh
2019-09-12 22:30             ` jcs
2019-09-12 23:12               ` reed
2019-09-12 23:22                 ` jcs
2019-09-12 23:29               ` [TUHS] IBM Unix source licenses Warren Toomey
2019-09-13  7:06                 ` arnold
2019-09-13  8:30                 ` SPC
2019-09-14 18:29                   ` Warner Losh
2019-09-12 21:29           ` [TUHS] IBM Unix source licenses [was Re: PWB vs Unix/TS Charles H Sauer
2019-09-11 17:49       ` [TUHS] " Richard Salz
2019-09-11 17:52         ` ron
2019-09-11 21:44           ` Clem Cole
2019-09-11 18:11       ` Larry McVoy
2019-09-11 18:18         ` Richard Salz
2019-09-11 18:54           ` Larry McVoy
2019-09-11 21:05             ` Steve Johnson
2019-09-11 21:34             ` Steve Johnson
2019-09-11 21:57             ` Clem Cole
2019-09-11 22:50               ` Arthur Krewat
2019-09-11 21:59           ` Clem Cole
2019-09-11 21:50         ` Clem Cole
2019-09-11 22:49         ` Dave Horsfall
2019-09-12  3:43           ` [TUHS] SCCS Larry McVoy
2019-09-12  4:20             ` George Michaelson
2019-09-12  4:31               ` [TUHS] [SPAM] SCCS Larry McVoy
2019-09-12 13:44                 ` Tony Finch
2019-09-13  4:11                   ` Larry McVoy
2019-09-13  5:54                     ` Dave Horsfall
2019-09-13  8:00                       ` Peter Jeremy
2019-09-13 15:23                         ` Larry McVoy
2019-09-13 21:36                         ` Dave Horsfall
2019-09-12  4:28             ` [TUHS] SCCS Jon Forrest
2019-09-12  4:33               ` Larry McVoy
2019-09-12  6:12                 ` William Corcoran
2019-09-12 14:35                   ` Clem Cole
2019-09-13  5:22                 ` Dave Horsfall
2019-09-13  5:50                   ` Bakul Shah
2019-09-12 16:45               ` Eric Allman
2019-09-12 17:29                 ` Clem Cole
2019-09-12 17:47                   ` Warner Losh
2019-09-13  8:12                   ` emanuel stiebler
2019-09-13 21:11                     ` Steffen Nurpmeso
2019-09-13 21:17                       ` Larry McVoy
2019-09-13 21:48                         ` Bakul Shah
2019-09-13 23:12                           ` Steffen Nurpmeso
2019-09-13 23:03                         ` Steffen Nurpmeso
2019-09-14  1:55                           ` [TUHS] [SPAM] SCCS Larry McVoy
2019-09-16 17:23                             ` [TUHS] SCCS Steffen Nurpmeso
2019-09-16 20:31                               ` Larry McVoy
2019-09-17 17:57                                 ` Steffen Nurpmeso
2019-09-18  8:48                               ` Eric Allman
2019-09-12 20:07             ` Nemo
2019-09-11 16:05   ` [TUHS] PWB vs Unix/TS Paul Winalski
2019-09-11 17:14     ` ron
2019-09-14  0:44   ` [TUHS] a book (was Re: PWB vs Unix/TS) reed
2019-09-14  2:53     ` Warner Losh
2019-09-15  2:18       ` Jon Steinhart
2019-09-15  2:39         ` Clem Cole
2019-09-15  3:24         ` Adam Thornton
2019-09-14 22:46     ` Clem cole
2019-09-15  0:58       ` Adam Thornton
2019-09-15  3:30         ` Eric Allman
2019-09-15  4:21           ` Larry McVoy
2019-09-15  5:17             ` Jon Steinhart
2019-09-15 20:14               ` Clem Cole
2019-09-15 20:21                 ` Jon Steinhart
2019-09-15 20:12           ` Clem Cole
2019-09-15 21:28             ` Dave Horsfall
2019-09-15 23:27               ` Clem cole
2019-09-15 23:45                 ` Richard Salz
2019-09-15  7:43     ` Andy Kosela

The Unix Heritage Society mailing list

Archives are clonable: git clone --mirror http://inbox.vuxu.org/tuhs

Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.tuhs


AGPL code for this site: git clone https://public-inbox.org/ public-inbox