[TUHS] forgotten versions

[TUHS] forgotten versions

[Rob Pike]

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

Excited as I was to see this history of Unix code in a single repository:

https://github.com/dspinellis/unix-history-repo

it continues the long-standing tradition of ignoring all the work done at
Bell Labs after v7. I consider v8 v9 v10 to be worth of attention, even
influential, but to hear this list talk about it - or discussions just
about anywhere else - you'd think they never existed. There are exceptions,
but this site does reinforce the broadly known version of the story.

It's doubly ironic for me because people often mistakenly credit me for
working on Unix, but I landed at the Labs after v7 was long dispatched. At
the Labs, I first worked on what became v8.

I suppose it's because the history flowed as this site shows, with BSD
being the driving force for a number of reasons, but it feels to me that a
large piece of Unix history has been sidelined.

I know it's a whiny lament, but those neglected systems had interesting
advances.

-rob

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

[TUHS] Re: forgotten versions

[Earl Baugh]

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

I’ve only cursorily heard of versions past v7. 
I personally be interested in hearing the history and seeing what changes/improvements/differences came in those versions. 

I’ve learned that the Unix history I thought I knew had huge gaping holes in it from this list and members.   Joe Ossanna’s contributions, for example, were a complete revelation to me. 

Earl 

Sent from my iPhone

> On Jun 16, 2022, at 7:06 PM, Rob Pike <robpike@gmail.com> wrote:
> 
> 
> Excited as I was to see this history of Unix code in a single repository:
> 
> https://github.com/dspinellis/unix-history-repo
> 
> it continues the long-standing tradition of ignoring all the work done at Bell Labs after v7. I consider v8 v9 v10 to be worth of attention, even influential, but to hear this list talk about it - or discussions just about anywhere else - you'd think they never existed. There are exceptions, but this site does reinforce the broadly known version of the story.
> 
> It's doubly ironic for me because people often mistakenly credit me for working on Unix, but I landed at the Labs after v7 was long dispatched. At the Labs, I first worked on what became v8.
> 
> I suppose it's because the history flowed as this site shows, with BSD being the driving force for a number of reasons, but it feels to me that a large piece of Unix history has been sidelined.
> 
> I know it's a whiny lament, but those neglected systems had interesting advances.
> 
> -rob
> 

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

[TUHS] Re: forgotten versions

[George Michaelson]

you're not wrong, but the other take on this is that the AT&T
licensing and some other things tended to make the circle of people
who could "see" this code significantly smaller than those feeding off
Unix 32V/v7 -> BSD -> Solaris.

this isn't meant to imply you did anything "wrong" -It was probably a
huge distraction having randoms begging for a tape of v8/9/10 with low
to no willingness to "give back"

-G

On Fri, Jun 17, 2022 at 9:06 AM Rob Pike <robpike@gmail.com> wrote:
>
> Excited as I was to see this history of Unix code in a single repository:
>
> https://github.com/dspinellis/unix-history-repo
>
> it continues the long-standing tradition of ignoring all the work done at Bell Labs after v7. I consider v8 v9 v10 to be worth of attention, even influential, but to hear this list talk about it - or discussions just about anywhere else - you'd think they never existed. There are exceptions, but this site does reinforce the broadly known version of the story.
>
> It's doubly ironic for me because people often mistakenly credit me for working on Unix, but I landed at the Labs after v7 was long dispatched. At the Labs, I first worked on what became v8.
>
> I suppose it's because the history flowed as this site shows, with BSD being the driving force for a number of reasons, but it feels to me that a large piece of Unix history has been sidelined.
>
> I know it's a whiny lament, but those neglected systems had interesting advances.
>
> -rob
>

[TUHS] Re: forgotten versions

[George Michaelson]

Another take on this is Mike Lesk's saying "its easy to occupy a
vacuum its harder to push something aside" said of UUCP.

v7 exploded into the world, and made BSD and SunOS happen.

v8 and 9 and 10 had to work harder to get mindshare because something
was already there.

things like rc were too "confrontational" to a mind attuned to bourne
shell.  Sockets (which btw, totally SUCK PUS) were coded into things
and even (YECHH) made POSIX and IETF spec status. Streams didn't stand
a chance.

basically, v7 succeeded too well, for v8/9/10 to get mindshare. I
agree it sucks they aren't documented, its just wrong: Serious OS
history needs to look beyond the narrow path in view. I'd say anyone
who doesn't write about them at length hasn't done their homework.

-G

On Fri, Jun 17, 2022 at 9:18 AM George Michaelson <ggm@algebras.org> wrote:
>
> you're not wrong, but the other take on this is that the AT&T
> licensing and some other things tended to make the circle of people
> who could "see" this code significantly smaller than those feeding off
> Unix 32V/v7 -> BSD -> Solaris.
>
> this isn't meant to imply you did anything "wrong" -It was probably a
> huge distraction having randoms begging for a tape of v8/9/10 with low
> to no willingness to "give back"
>
> -G
>
> On Fri, Jun 17, 2022 at 9:06 AM Rob Pike <robpike@gmail.com> wrote:
> >
> > Excited as I was to see this history of Unix code in a single repository:
> >
> > https://github.com/dspinellis/unix-history-repo
> >
> > it continues the long-standing tradition of ignoring all the work done at Bell Labs after v7. I consider v8 v9 v10 to be worth of attention, even influential, but to hear this list talk about it - or discussions just about anywhere else - you'd think they never existed. There are exceptions, but this site does reinforce the broadly known version of the story.
> >
> > It's doubly ironic for me because people often mistakenly credit me for working on Unix, but I landed at the Labs after v7 was long dispatched. At the Labs, I first worked on what became v8.
> >
> > I suppose it's because the history flowed as this site shows, with BSD being the driving force for a number of reasons, but it feels to me that a large piece of Unix history has been sidelined.
> >
> > I know it's a whiny lament, but those neglected systems had interesting advances.
> >
> > -rob
> >

[TUHS] Re: forgotten versions

[Larry McVoy]

On Fri, Jun 17, 2022 at 09:44:02AM +1000, George Michaelson wrote:
> v7 exploded into the world, and made BSD and SunOS happen.
> 
> v8 and 9 and 10 had to work harder to get mindshare because something
> was already there.

I think this is spot on.  v7 was pretty easy to find in src form, I know
I've seen some of v{8,9,10} in Shannon's treasure trove of Unix source
at Sun but they were less common.

> things like rc were too "confrontational" to a mind attuned to bourne
> shell.  Sockets (which btw, totally SUCK PUS) were coded into things
> and even (YECHH) made POSIX and IETF spec status. Streams didn't stand
> a chance.

There was streams (from Dennis) and STREAMS from Sys whatever.  I don't
know how great streams was, I read the paper and it seemed fine for a tty
driver, networking I dunno.  And having seen an SGI SMP machine brought
to it's knees by racks and racks of modems, I'm not sure streams is even
a good idea for ttys; it's fine for a personal system, I've never seen
that sort of layered design perform well at scale.  I have seen what a
networking stack in STREAMS did, it was awful, absolutely awful.
Sun bought the STREAMS networking stack from Lachman, same one that
I ported to the ETA 10 and SCO Unix, it sucked hard.  Sun threw it out,
hired Mentat to give them a performant STREAMS stack, I'm not sure
that ever worked.  I know they put back the socket interface, as much
as people don't like it, it's a non-starter to have an OS without it.

[TUHS] Re: forgotten versions

[Diomidis Spinellis]

It is indeed problematic that the Unix history repository is missing the 
Research Editions.  At the time I created it, the source code of the 
Research Unix Eighth and Ninth Editions wasn't openly available.  I'm 
now discussing with another member of this list for a pull request to 
add them.  Incorporating them properly isn't trivial, because various 
mappings are needed to establish authorship information and to allow 
git-blame to work across snapshots of moved files.

Diomidis - https://www.spinellis.gr/

On 17-Jun-22 2:06, Rob Pike wrote:
> Excited as I was to see this history of Unix code in a single repository:
> 
> https://github.com/dspinellis/unix-history-repo 
> <https://github.com/dspinellis/unix-history-repo>
> 
> it continues the long-standing tradition of ignoring all the work done 
> at Bell Labs after v7. I consider v8 v9 v10 to be worth of attention, 
> even influential, but to hear this list talk about it - or discussions 
> just about anywhere else - you'd think they never existed. 

[TUHS] Re: forgotten versions

[Rob Pike]

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

That's great. In the unlikely event I can help in any way, please let me
know.

-rob


On Fri, Jun 17, 2022 at 5:21 PM Diomidis Spinellis <dds@aueb.gr> wrote:

> It is indeed problematic that the Unix history repository is missing the
> Research Editions.  At the time I created it, the source code of the
> Research Unix Eighth and Ninth Editions wasn't openly available.  I'm
> now discussing with another member of this list for a pull request to
> add them.  Incorporating them properly isn't trivial, because various
> mappings are needed to establish authorship information and to allow
> git-blame to work across snapshots of moved files.
>
> Diomidis - https://www.spinellis.gr/
>
> On 17-Jun-22 2:06, Rob Pike wrote:
> > Excited as I was to see this history of Unix code in a single repository:
> >
> > https://github.com/dspinellis/unix-history-repo
> > <https://github.com/dspinellis/unix-history-repo>
> >
> > it continues the long-standing tradition of ignoring all the work done
> > at Bell Labs after v7. I consider v8 v9 v10 to be worth of attention,
> > even influential, but to hear this list talk about it - or discussions
> > just about anywhere else - you'd think they never existed.
>

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

[TUHS] Re: forgotten versions

[arnold]

Very cool.

I assume you know this, but the Tenth Edition code is also in
the TUHS archives and should not be left out.

Thanks,

Arnold

Diomidis Spinellis <dds@aueb.gr> wrote:

> It is indeed problematic that the Unix history repository is missing the 
> Research Editions.  At the time I created it, the source code of the 
> Research Unix Eighth and Ninth Editions wasn't openly available.  I'm 
> now discussing with another member of this list for a pull request to 
> add them.  Incorporating them properly isn't trivial, because various 
> mappings are needed to establish authorship information and to allow 
> git-blame to work across snapshots of moved files.
>
> Diomidis - https://www.spinellis.gr/
>
> On 17-Jun-22 2:06, Rob Pike wrote:
> > Excited as I was to see this history of Unix code in a single repository:
> > 
> > https://github.com/dspinellis/unix-history-repo 
> > <https://github.com/dspinellis/unix-history-repo>
> > 
> > it continues the long-standing tradition of ignoring all the work done 
> > at Bell Labs after v7. I consider v8 v9 v10 to be worth of attention, 
> > even influential, but to hear this list talk about it - or discussions 
> > just about anywhere else - you'd think they never existed. 

[TUHS] Re: forgotten versions

[arnold]

Rob Pike <robpike@gmail.com> wrote:

> Excited as I was to see this history of Unix code in a single repository:
>
> https://github.com/dspinellis/unix-history-repo
>
> it continues the long-standing tradition of ignoring all the work done at
> Bell Labs after v7. I consider v8 v9 v10 to be worth of attention, even
> influential,

I can think of at least 4 things, some big, some small, where post-V7
Research Unix was influential:

- Streams (as STREAMS in S5R3 & greater)

- The filesystem switch (in S5R3, replaced by Sun vnodes in S5R4)

- /proc ! This lives on in most Unixes and in Linux

- /dev/{stdin,stdout,stderr}, /dev/fd/N - Minor but a nice generalization

The influence was less from code and more from published papers, but
there certainly was a notable influence.

I was lucky enough in the late 80s and 90s to have an inside friend
in the labs (BWK), who was kind enough to obtain for me a real printed
Eighth Edition manual. Later he put me in touch with Doug who at first
wasn't sure, but found out that the could, sell me a Ninth Edition
manual. ($50 IIRC).  I bought the published Tenth Edition manuals as well.
It was great to read those things, even if at the time I couldn't
get to the code.

For whatever it's worth,

Arnold

[TUHS] Sockets vs Streams (was Re: forgotten versions

[Bakul Shah]

On Jun 16, 2022, at 4:44 PM, George Michaelson <ggm@algebras.org> wrote:
> 
> Sockets (which btw, totally SUCK PUS) were coded into things
> and even (YECHH) made POSIX and IETF spec status. Streams didn't stand
> a chance.

The stream abstraction is a nice (c)lean abstraction but it doesn't
quite work for things like multicast or datagrams in general. Plan9
doesn't have sockets but the way it deals with UDP is not simple either.
The complexity is in the protocols themselves. Even at layer 2 (below
the IP layer) the amount of complexity is mind boggling (though I
suppose high-speed backbone switches do all this in hardware!).

[TUHS] Re: Sockets vs Streams (was Re: forgotten versions

[Paul Winalski]

On 6/17/22, Bakul Shah <bakul@iitbombay.org> wrote:
>
> The stream abstraction is a nice (c)lean abstraction but it doesn't
> quite work for things like multicast or datagrams in general.

Every networking protocol I know of involves the exchange of discrete
packets of data and thus is inherently record-based.  In my
experience, layering a stream-oriented interface on top of that
usually means that the software at the layers above that have to take
extra measures to reconstruct the original record-oriented packets.

-Paul W.

[TUHS] Re: Sockets vs Streams (was Re: forgotten versions

[Dan Stromberg]

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

On Fri, Jun 17, 2022 at 9:24 AM Bakul Shah <bakul@iitbombay.org> wrote:

> On Jun 16, 2022, at 4:44 PM, George Michaelson <ggm@algebras.org> wrote:
> >
> > Sockets (which btw, totally SUCK PUS) were coded into things
> > and even (YECHH) made POSIX and IETF spec status. Streams didn't stand
> > a chance.
>
> The stream abstraction is a nice (c)lean abstraction but it doesn't
> quite work for things like multicast or datagrams in general. Plan9
> doesn't have sockets but the way it deals with UDP is not simple either.
> The complexity is in the protocols themselves. Even at layer 2 (below
> the IP layer) the amount of complexity is mind boggling (though I
> suppose high-speed backbone switches do all this in hardware!).
>

I've heard good things about Streams, but never really had a problem with
Sockets once I realized that send's and recv's don't necessarily have a 1-1
correspondence.

I do think that Sockets need something analogous to stdio though.

And I believe inetd allowed you to do that.

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

[TUHS] Re: forgotten versions

[Angelo Papenhoff]

To make people more aware of post-v7 Research UNIX it would be great if
you could actually run all of them in a simulator and have the manuals
available.

V8 is working perfectly in simh and there's blit (jerq) emulation as well.
DMD 5620 emulation should be possible as well with Seth Morabito's
emulator, but as far as I understand it needs a different ROM that we
don't have a dump of. (I've had a real 5620 connected to my laptop
running v8 in simh, it worked perfectly)

V9 exists as a port to Sun-3 and it can actually be booted apparently.
The source seems incomplete, but the VAX kernel source seems to be
included as well. Maybe it could be gotten to run in simh on a VAX
in some form or another?

V10 exists but not as anything that boots. I think getting this to work
would be the holy grail but also requires quite a bit of effort.
I don't know if the V8 and V10 file systems are compatible, but if that
is the case one could probably start by bootstrapping from V8.
It also includes the multilevel-secure IX system and software for the
630 MTG terminal.


As for the manual...

The V8 files have the man pages but not much of the documents.

The V9 files seem to have neither.

The V10 files have both the man pages and the documents but I have not
yet tried to troff any of this.

Since I know at least the V10 manual to be a work of art and beauty I
think it should be available to everyone. I have not seen the physical
V8 and V9 manuals, but if they look anything like the V10 one, they too
deserve to be available to the public.


Does anyone have a plan of attack? I'd gladly join some effort to make
the research systems more visible or available again (but probably don't
have the motivation to do so alone).

Angelo/aap

[TUHS] Re: forgotten versions

[Rob Pike]

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

The VAX Plan 9 kernel isn't worth anything. It never worked, was never
used, and was abandoned completely when better SMP machines started
appearing. The VAX code wasn't even ported, as I remember it; Ken and I
started over from scratch with a pair of 4-core SGI machines with MIPS CPUs
and wackadoo synchronization hardware.

-rob


On Sat, Jun 18, 2022 at 5:05 PM Angelo Papenhoff <aap@papnet.eu> wrote:

> To make people more aware of post-v7 Research UNIX it would be great if
> you could actually run all of them in a simulator and have the manuals
> available.
>
> V8 is working perfectly in simh and there's blit (jerq) emulation as well.
> DMD 5620 emulation should be possible as well with Seth Morabito's
> emulator, but as far as I understand it needs a different ROM that we
> don't have a dump of. (I've had a real 5620 connected to my laptop
> running v8 in simh, it worked perfectly)
>
> V9 exists as a port to Sun-3 and it can actually be booted apparently.
> The source seems incomplete, but the VAX kernel source seems to be
> included as well. Maybe it could be gotten to run in simh on a VAX
> in some form or another?
>
> V10 exists but not as anything that boots. I think getting this to work
> would be the holy grail but also requires quite a bit of effort.
> I don't know if the V8 and V10 file systems are compatible, but if that
> is the case one could probably start by bootstrapping from V8.
> It also includes the multilevel-secure IX system and software for the
> 630 MTG terminal.
>
>
> As for the manual...
>
> The V8 files have the man pages but not much of the documents.
>
> The V9 files seem to have neither.
>
> The V10 files have both the man pages and the documents but I have not
> yet tried to troff any of this.
>
> Since I know at least the V10 manual to be a work of art and beauty I
> think it should be available to everyone. I have not seen the physical
> V8 and V9 manuals, but if they look anything like the V10 one, they too
> deserve to be available to the public.
>
>
> Does anyone have a plan of attack? I'd gladly join some effort to make
> the research systems more visible or available again (but probably don't
> have the motivation to do so alone).
>
> Angelo/aap
>

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

[TUHS] Re: forgotten versions

[Angelo Papenhoff]

I wasn't talking about Plan 9, but it's interesting to know that there
was an attempt at a VAX kernel.

On 19/06/22, Rob Pike wrote:
> The VAX Plan 9 kernel isn't worth anything. It never worked, was never
> used, and was abandoned completely when better SMP machines started
> appearing. The VAX code wasn't even ported, as I remember it; Ken and I
> started over from scratch with a pair of 4-core SGI machines with MIPS CPUs
> and wackadoo synchronization hardware.
> 
> -rob

[TUHS] Re: forgotten versions

[Rob Pike]

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

Aha, yes, my mistake, sorry about that. I bet I misread that mail because
of the mention of a Sun port, which put me in a nostalgic (read: resentful)
mood.

Anyway, knowing about the Plan 9 VAX kernel might be interesting, but the
kernel itself was not.

-rob


On Sun, Jun 19, 2022 at 6:17 PM Angelo Papenhoff <aap@papnet.eu> wrote:

> I wasn't talking about Plan 9, but it's interesting to know that there
> was an attempt at a VAX kernel.
>
> On 19/06/22, Rob Pike wrote:
> > The VAX Plan 9 kernel isn't worth anything. It never worked, was never
> > used, and was abandoned completely when better SMP machines started
> > appearing. The VAX code wasn't even ported, as I remember it; Ken and I
> > started over from scratch with a pair of 4-core SGI machines with MIPS
> CPUs
> > and wackadoo synchronization hardware.
> >
> > -rob
>

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

[TUHS] Re: forgotten versions

[Angelo Papenhoff]

It brings up one other question for me though:
rsc made a repo of the plan 9 kernel source code (https://9p.io/sources/extra/9hist/)
(which can now be found in git format too: https://github.com/0intro/9hist)
But what about the non-kernel parts of the system?
Is there a chance of getting the user space stuff as well? Does it even
still exist?

aap

On 19/06/22, Rob Pike wrote:
> Aha, yes, my mistake, sorry about that. I bet I misread that mail because
> of the mention of a Sun port, which put me in a nostalgic (read: resentful)
> mood.
> 
> Anyway, knowing about the Plan 9 VAX kernel might be interesting, but the
> kernel itself was not.
> 
> -rob
> 
> 
> On Sun, Jun 19, 2022 at 6:17 PM Angelo Papenhoff <aap@papnet.eu> wrote:
> 
> > I wasn't talking about Plan 9, but it's interesting to know that there
> > was an attempt at a VAX kernel.
> >
> > On 19/06/22, Rob Pike wrote:
> > > The VAX Plan 9 kernel isn't worth anything. It never worked, was never
> > > used, and was abandoned completely when better SMP machines started
> > > appearing. The VAX code wasn't even ported, as I remember it; Ken and I
> > > started over from scratch with a pair of 4-core SGI machines with MIPS
> > CPUs
> > > and wackadoo synchronization hardware.
> > >
> > > -rob
> >

[TUHS] Re: forgotten versions

[arnold]

See https://plan9foundation.org/ and https://p9f.org/dl/ in particular
to download the sources.

Arnold

Angelo Papenhoff <aap@papnet.eu> wrote:

> It brings up one other question for me though:
> rsc made a repo of the plan 9 kernel source code (https://9p.io/sources/extra/9hist/)
> (which can now be found in git format too: https://github.com/0intro/9hist)
> But what about the non-kernel parts of the system?
> Is there a chance of getting the user space stuff as well? Does it even
> still exist?
>
> aap
>
> On 19/06/22, Rob Pike wrote:
> > Aha, yes, my mistake, sorry about that. I bet I misread that mail because
> > of the mention of a Sun port, which put me in a nostalgic (read: resentful)
> > mood.
> > 
> > Anyway, knowing about the Plan 9 VAX kernel might be interesting, but the
> > kernel itself was not.
> > 
> > -rob
> > 
> > 
> > On Sun, Jun 19, 2022 at 6:17 PM Angelo Papenhoff <aap@papnet.eu> wrote:
> > 
> > > I wasn't talking about Plan 9, but it's interesting to know that there
> > > was an attempt at a VAX kernel.
> > >
> > > On 19/06/22, Rob Pike wrote:
> > > > The VAX Plan 9 kernel isn't worth anything. It never worked, was never
> > > > used, and was abandoned completely when better SMP machines started
> > > > appearing. The VAX code wasn't even ported, as I remember it; Ken and I
> > > > started over from scratch with a pair of 4-core SGI machines with MIPS
> > > CPUs
> > > > and wackadoo synchronization hardware.
> > > >
> > > > -rob
> > >

[TUHS] Re: forgotten versions

[Angelo Papenhoff]

That's only the releases. I meant the earlier pre-1e code.

aap

On 19/06/22, arnold@skeeve.com wrote:
> See https://plan9foundation.org/ and https://p9f.org/dl/ in particular
> to download the sources.
> 
> Arnold

[TUHS] Re: forgotten versions

[arnold]

Maybe it exists on the WORM drive at Bell Labs... :-(

Angelo Papenhoff <aap@papnet.eu> wrote:

> That's only the releases. I meant the earlier pre-1e code.
>
> aap
>
> On 19/06/22, arnold@skeeve.com wrote:
> > See https://plan9foundation.org/ and https://p9f.org/dl/ in particular
> > to download the sources.
> > 
> > Arnold

[TUHS] Re: forgotten versions

[Matthias Bruestle]

More like a WORN drive when nobody is looking at it.

On Sun, Jun 19, 2022 at 03:23:50AM -0600, arnold@skeeve.com wrote:
> Maybe it exists on the WORM drive at Bell Labs... :-(
> 
> Angelo Papenhoff <aap@papnet.eu> wrote:
> 
> > That's only the releases. I meant the earlier pre-1e code.

-- 
When You Find Out Your Normal Daily Lifestyle Is Called Quarantine

[TUHS] Re: forgotten versions

[Kenneth Goodwin]

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

Just chiming in a bit..

Rob, it might be interesting to old geezers like me as well as newbies
entering the field to get a perspective on Plan 9 and its evolution. The
motivations behind it. What your group was trying to accomplish,  the
approach, pitfalls and the entire decision making process as things went
along. Even things that went horribly wrong and what happened etc.

Sorry for my potential ignorance here,  but other than the documents that
come with the source code distribution, there does not seem to be any
official textbook style document available with that level of detail going
into the evolution and back story.

I am thinking more in terms of the multics book that came out after that
project failed.

Perhaps even some college level tutorial videos on YouTube that do a deep
dive. Leaving your group's collective wisdom and insight for prosperity.
Anatomy of a Research Operating System. Approaching the Design of a modern
day distributed Operating Systems, practices and pitfalls.

(You can stop laughing 😃 now....)

On Sun, Jun 19, 2022, 4:53 AM Rob Pike <robpike@gmail.com> wrote:

> Aha, yes, my mistake, sorry about that. I bet I misread that mail because
> of the mention of a Sun port, which put me in a nostalgic (read: resentful)
> mood.
>
> Anyway, knowing about the Plan 9 VAX kernel might be interesting, but the
> kernel itself was not.
>
> -rob
>
>
> On Sun, Jun 19, 2022 at 6:17 PM Angelo Papenhoff <aap@papnet.eu> wrote:
>
>> I wasn't talking about Plan 9, but it's interesting to know that there
>> was an attempt at a VAX kernel.
>>
>> On 19/06/22, Rob Pike wrote:
>> > The VAX Plan 9 kernel isn't worth anything. It never worked, was never
>> > used, and was abandoned completely when better SMP machines started
>> > appearing. The VAX code wasn't even ported, as I remember it; Ken and I
>> > started over from scratch with a pair of 4-core SGI machines with MIPS
>> CPUs
>> > and wackadoo synchronization hardware.
>> >
>> > -rob
>>
>

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

[TUHS] Re: forgotten versions

[Al Kossow]

On 6/19/22 7:47 AM, Kenneth Goodwin wrote:

> Perhaps even some college level tutorial videos on YouTube

Put it in writing
Eschew ewe toob

[TUHS] Re: forgotten versions

[Theodore Ts'o]

On Sun, Jun 19, 2022 at 10:47:23AM -0400, Kenneth Goodwin wrote:
> Just chiming in a bit..
> 
> Rob, it might be interesting to old geezers like me as well as newbies
> entering the field to get a perspective on Plan 9 and its evolution. The
> motivations behind it. What your group was trying to accomplish,  the
> approach, pitfalls and the entire decision making process as things went
> along. Even things that went horribly wrong and what happened etc.

I'll second that.  I think it would be really helpful.

There was a time when I was reviewing a paper which made a bunch of
claims about what Plan 9 was trying to accomplish and in particular
about what the ultimate design goals for a particular component of
Plan 9.  (I won't go into further details since as far as I know, that
paper was never published.)

In any case, since I wasn't familiar with the history of Plan 9 to
evaluate these claims, with the permission of the PC chairs, I found
someone who had been part of the Plan 9 team, and asked them to review
certain passages for accuracy, and they said, "Uh, no.... that's
totally not the case.  They're completely wrong."

So if someone were willing to create additional write ups about
lessons learned, or if that's too much work, maybe someone could do
some interview for a podcast or a vlog, that would be really
excellent.

						- Ted

[TUHS] Re: forgotten versions

[Dan Cross]

On Sun, Jun 19, 2022 at 2:33 PM Theodore Ts'o <tytso@mit.edu> wrote:
> On Sun, Jun 19, 2022 at 10:47:23AM -0400, Kenneth Goodwin wrote:
> > Just chiming in a bit..
> >
> > Rob, it might be interesting to old geezers like me as well as newbies
> > entering the field to get a perspective on Plan 9 and its evolution. The
> > motivations behind it. What your group was trying to accomplish,  the
> > approach, pitfalls and the entire decision making process as things went
> > along. Even things that went horribly wrong and what happened etc.
>
> I'll second that.  I think it would be really helpful.
>
> There was a time when I was reviewing a paper which made a bunch of
> claims about what Plan 9 was trying to accomplish and in particular
> about what the ultimate design goals for a particular component of
> Plan 9.  (I won't go into further details since as far as I know, that
> paper was never published.)
>
> In any case, since I wasn't familiar with the history of Plan 9 to
> evaluate these claims, with the permission of the PC chairs, I found
> someone who had been part of the Plan 9 team, and asked them to review
> certain passages for accuracy, and they said, "Uh, no.... that's
> totally not the case.  They're completely wrong."
>
> So if someone were willing to create additional write ups about
> lessons learned, or if that's too much work, maybe someone could do
> some interview for a podcast or a vlog, that would be really
> excellent.

Agreed. A retrospective would be a very welcome addition to the canon.

        - Dan C.

(PS: I _had_ heard of the VAX effort before, but I don't think I'd known
quite how nascent it was before it was abandoned in favor of MIPS and
68k.)

[TUHS] Re: forgotten versions

[Jacob Moody]

On 6/19/22 12:38, Dan Cross wrote:
> On Sun, Jun 19, 2022 at 2:33 PM Theodore Ts'o <tytso@mit.edu> wrote:
>> On Sun, Jun 19, 2022 at 10:47:23AM -0400, Kenneth Goodwin wrote:
>>> Just chiming in a bit..
>>>
>>> Rob, it might be interesting to old geezers like me as well as newbies
>>> entering the field to get a perspective on Plan 9 and its evolution. The
>>> motivations behind it. What your group was trying to accomplish,  the
>>> approach, pitfalls and the entire decision making process as things went
>>> along. Even things that went horribly wrong and what happened etc.
>>
>> I'll second that.  I think it would be really helpful.
>>
>> There was a time when I was reviewing a paper which made a bunch of
>> claims about what Plan 9 was trying to accomplish and in particular
>> about what the ultimate design goals for a particular component of
>> Plan 9.  (I won't go into further details since as far as I know, that
>> paper was never published.)
>>
>> In any case, since I wasn't familiar with the history of Plan 9 to
>> evaluate these claims, with the permission of the PC chairs, I found
>> someone who had been part of the Plan 9 team, and asked them to review
>> certain passages for accuracy, and they said, "Uh, no.... that's
>> totally not the case.  They're completely wrong."
>>
>> So if someone were willing to create additional write ups about
>> lessons learned, or if that's too much work, maybe someone could do
>> some interview for a podcast or a vlog, that would be really
>> excellent.
> 
> Agreed. A retrospective would be a very welcome addition to the canon.
> 
>         - Dan C.
> 
> (PS: I _had_ heard of the VAX effort before, but I don't think I'd known
> quite how nascent it was before it was abandoned in favor of MIPS and
> 68k.)

Adding my vote in for getting some sort of retrospective.

I recently stumbled across the existence of datakit
when going through the plan9foundation source archives.
Would be curious to hear more about its involvement
with plan9.

[TUHS] Re: forgotten versions

[Larry McVoy]

On Tue, Jun 21, 2022 at 05:56:02PM -0600, Jacob Moody wrote:
> I recently stumbled across the existence of datakit
> when going through the plan9foundation source archives.
> Would be curious to hear more about its involvement
> with plan9.

Pretty sure datakit predated Plan 9, didn't Greg Chesson work on that?
He was my mentor at SGI, my memory is datakit was sort of early on in
his career and then he did XTP, which nobody knows about but I believe
is still used by the military.

Unless the early Bell Labs datakit and the Plan 9 datakit are different
things.

[TUHS] Re: forgotten versions

[Rob Pike]

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

Plan 9 used Datakit as its network for quite a while. The Gnot terminals
had an INCON interface, a megabit (approximately) twisted pair adjunct to
Datakit. I had an INCON link running over a T-1 link to my house - great
excitement back in the day. (The kernel downloaded over the line and booted
the machine up to the window system - there was no local disk - from power
up, in 7 seconds.) NJ Bell needed to install a new nitrogen-pressurized
26-pair cable, supported by a new telephone pole, to set it up, because I
had already used up all available pairs on the existing line to my house.
All included at no extra cost. (You pay for the service, not its
construction.)

When the internet became unavoidable, we used Plan 9's import mechanism to
import the single external TCP/IP interface from our gateway machine, over
Datakit, to the Gnots. We did the same, but importing now over IL (an
ethernet protocol built by Phil Winterbottom) when our terminals became PCs.

That's how I remember it, at least, but I might have got some details
wrong. I think much of this is covered in
http://doc.cat-v.org/plan_9/4th_edition/papers/net/

-rob


On Wed, Jun 22, 2022 at 10:13 AM Larry McVoy <lm@mcvoy.com> wrote:

> On Tue, Jun 21, 2022 at 05:56:02PM -0600, Jacob Moody wrote:
> > I recently stumbled across the existence of datakit
> > when going through the plan9foundation source archives.
> > Would be curious to hear more about its involvement
> > with plan9.
>
> Pretty sure datakit predated Plan 9, didn't Greg Chesson work on that?
> He was my mentor at SGI, my memory is datakit was sort of early on in
> his career and then he did XTP, which nobody knows about but I believe
> is still used by the military.
>
> Unless the early Bell Labs datakit and the Plan 9 datakit are different
> things.
>

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

[TUHS] Re: forgotten versions

[George Michaelson]

There was this persisting story that Ken got permission from somebody
like CBS or Sony to have a very large amount of classical music on a
400MB drive, for research purposes. No, really: he was doing some
psycho-acoustic thing comparing compressed to uncompressed for
somebody, or improving on the fraunhoffer algorithms which became MP3.
The point was, the rest of us had to listen to CDs and Ken had the
complete works of Bach (or something) on a hard drive, which we were
told he kept in the office, and played at home over a landline of some
horrendously high bandwidth, un-imaginable speeds like a megabit,
imagine, a MILLION of those suckers. How dare he. Thats more than the
whole of queensland. I imagine the truth is much less interesting, and
there was no major IPR fraud going on at the labs coding stuff as MP3
like we imagined, under the table.

I imagine this would also have been a Datakit T-1. But surely that was
a 1.44mbit carrier? T1 was smaller than E1 because europeans and
asians learned to count to 32 not 24.

-G

On Wed, Jun 22, 2022 at 10:48 AM Rob Pike <robpike@gmail.com> wrote:
>
> Plan 9 used Datakit as its network for quite a while. The Gnot terminals had an INCON interface, a megabit (approximately) twisted pair adjunct to Datakit. I had an INCON link running over a T-1 link to my house - great excitement back in the day. (The kernel downloaded over the line and booted the machine up to the window system - there was no local disk - from power up, in 7 seconds.) NJ Bell needed to install a new nitrogen-pressurized 26-pair cable, supported by a new telephone pole, to set it up, because I had already used up all available pairs on the existing line to my house. All included at no extra cost. (You pay for the service, not its construction.)
>
> When the internet became unavoidable, we used Plan 9's import mechanism to import the single external TCP/IP interface from our gateway machine, over Datakit, to the Gnots. We did the same, but importing now over IL (an ethernet protocol built by Phil Winterbottom) when our terminals became PCs.
>
> That's how I remember it, at least, but I might have got some details wrong. I think much of this is covered in http://doc.cat-v.org/plan_9/4th_edition/papers/net/
>
> -rob
>
>
> On Wed, Jun 22, 2022 at 10:13 AM Larry McVoy <lm@mcvoy.com> wrote:
>>
>> On Tue, Jun 21, 2022 at 05:56:02PM -0600, Jacob Moody wrote:
>> > I recently stumbled across the existence of datakit
>> > when going through the plan9foundation source archives.
>> > Would be curious to hear more about its involvement
>> > with plan9.
>>
>> Pretty sure datakit predated Plan 9, didn't Greg Chesson work on that?
>> He was my mentor at SGI, my memory is datakit was sort of early on in
>> his career and then he did XTP, which nobody knows about but I believe
>> is still used by the military.
>>
>> Unless the early Bell Labs datakit and the Plan 9 datakit are different
>> things.

[TUHS] Re: forgotten versions

[Bakul Shah]

400MB is less than a CD's worth! Compressed (MP3) would reduce the space
by a factor of 11 or so. 

> On Jun 21, 2022, at 6:55 PM, George Michaelson <ggm@algebras.org> wrote:
> 
> There was this persisting story that Ken got permission from somebody
> like CBS or Sony to have a very large amount of classical music on a
> 400MB drive, for research purposes. No, really: he was doing some
> psycho-acoustic thing comparing compressed to uncompressed for
> somebody, or improving on the fraunhoffer algorithms which became MP3.
> The point was, the rest of us had to listen to CDs and Ken had the
> complete works of Bach (or something) on a hard drive, which we were
> told he kept in the office, and played at home over a landline of some
> horrendously high bandwidth, un-imaginable speeds like a megabit,
> imagine, a MILLION of those suckers. How dare he. Thats more than the
> whole of queensland. I imagine the truth is much less interesting, and
> there was no major IPR fraud going on at the labs coding stuff as MP3
> like we imagined, under the table.
> 
> I imagine this would also have been a Datakit T-1. But surely that was
> a 1.44mbit carrier? T1 was smaller than E1 because europeans and
> asians learned to count to 32 not 24.
> 
> -G
> 
> On Wed, Jun 22, 2022 at 10:48 AM Rob Pike <robpike@gmail.com> wrote:
>> 
>> Plan 9 used Datakit as its network for quite a while. The Gnot terminals had an INCON interface, a megabit (approximately) twisted pair adjunct to Datakit. I had an INCON link running over a T-1 link to my house - great excitement back in the day. (The kernel downloaded over the line and booted the machine up to the window system - there was no local disk - from power up, in 7 seconds.) NJ Bell needed to install a new nitrogen-pressurized 26-pair cable, supported by a new telephone pole, to set it up, because I had already used up all available pairs on the existing line to my house. All included at no extra cost. (You pay for the service, not its construction.)
>> 
>> When the internet became unavoidable, we used Plan 9's import mechanism to import the single external TCP/IP interface from our gateway machine, over Datakit, to the Gnots. We did the same, but importing now over IL (an ethernet protocol built by Phil Winterbottom) when our terminals became PCs.
>> 
>> That's how I remember it, at least, but I might have got some details wrong. I think much of this is covered in http://doc.cat-v.org/plan_9/4th_edition/papers/net/
>> 
>> -rob
>> 
>> 
>> On Wed, Jun 22, 2022 at 10:13 AM Larry McVoy <lm@mcvoy.com> wrote:
>>> 
>>> On Tue, Jun 21, 2022 at 05:56:02PM -0600, Jacob Moody wrote:
>>>> I recently stumbled across the existence of datakit
>>>> when going through the plan9foundation source archives.
>>>> Would be curious to hear more about its involvement
>>>> with plan9.
>>> 
>>> Pretty sure datakit predated Plan 9, didn't Greg Chesson work on that?
>>> He was my mentor at SGI, my memory is datakit was sort of early on in
>>> his career and then he did XTP, which nobody knows about but I believe
>>> is still used by the military.
>>> 
>>> Unless the early Bell Labs datakit and the Plan 9 datakit are different
>>> things.

[TUHS] Re: forgotten versions

[Jon Steinhart]

George Michaelson writes:
> There was this persisting story that Ken got permission from somebody
> like CBS or Sony to have a very large amount of classical music on a
> 400MB drive, for research purposes. No, really: he was doing some
> psycho-acoustic thing comparing compressed to uncompressed for
> somebody, or improving on the fraunhoffer algorithms which became MP3.
> The point was, the rest of us had to listen to CDs and Ken had the
> complete works of Bach (or something) on a hard drive, which we were
> told he kept in the office, and played at home over a landline of some
> horrendously high bandwidth, un-imaginable speeds like a megabit,
> imagine, a MILLION of those suckers. How dare he. Thats more than the
> whole of queensland. I imagine the truth is much less interesting, and
> there was no major IPR fraud going on at the labs coding stuff as MP3
> like we imagined, under the table.
>
> I imagine this would also have been a Datakit T-1. But surely that was
> a 1.44mbit carrier? T1 was smaller than E1 because europeans and
> asians learned to count to 32 not 24.
>
> -G

This reminds me of a Ken story from the late '90s.  I was at a conference
that I won't name where Ken gave a talk about his compression work; if I
remember correctly his goal was to fit all of the Billboard Top 100 songs
of all time onto a single CD.  He showed us the big stack of disks that he
made to give to us, but then said that to his surprise the the lawyers
refused to give permission.  At that point he became very focused on messing
with his slides while everyone got up, got in line, and took a disc.  After
the pile was gone Ken looked up and nonchalantly continued his talk.

That might also have been the conference at which Ken showed us videos of
him in a MIG.

Jon

[TUHS] Re: forgotten versions

[Andrew Hume]

i joined the labs in 1981. during that first year, i worked on S/NET and
did a comparison with data kit (or a direct predecessor).

> On Jun 21, 2022, at 5:13 PM, Larry McVoy <lm@mcvoy.com> wrote:
> 
> On Tue, Jun 21, 2022 at 05:56:02PM -0600, Jacob Moody wrote:
>> I recently stumbled across the existence of datakit
>> when going through the plan9foundation source archives.
>> Would be curious to hear more about its involvement
>> with plan9.
> 
> Pretty sure datakit predated Plan 9, didn't Greg Chesson work on that?
> He was my mentor at SGI, my memory is datakit was sort of early on in
> his career and then he did XTP, which nobody knows about but I believe
> is still used by the military.
> 
> Unless the early Bell Labs datakit and the Plan 9 datakit are different
> things.

[TUHS] Re: forgotten versions

[Andrew Hume]

the early versions of the audio compression stuff were not quite is good as
the later versions (which became apples stuff) but compressed to substantially
smaller size. ken compressed 2-3 hrs or so of music for my wedding and that
was rather less than a CD.

> On Jun 21, 2022, at 7:14 PM, Jon Steinhart <jon@fourwinds.com> wrote:
> 
> George Michaelson writes:
>> There was this persisting story that Ken got permission from somebody
>> like CBS or Sony to have a very large amount of classical music on a
>> 400MB drive, for research purposes. No, really: he was doing some
>> psycho-acoustic thing comparing compressed to uncompressed for
>> somebody, or improving on the fraunhoffer algorithms which became MP3.
>> The point was, the rest of us had to listen to CDs and Ken had the
>> complete works of Bach (or something) on a hard drive, which we were
>> told he kept in the office, and played at home over a landline of some
>> horrendously high bandwidth, un-imaginable speeds like a megabit,
>> imagine, a MILLION of those suckers. How dare he. Thats more than the
>> whole of queensland. I imagine the truth is much less interesting, and
>> there was no major IPR fraud going on at the labs coding stuff as MP3
>> like we imagined, under the table.
>> 
>> I imagine this would also have been a Datakit T-1. But surely that was
>> a 1.44mbit carrier? T1 was smaller than E1 because europeans and
>> asians learned to count to 32 not 24.
>> 
>> -G
> 
> This reminds me of a Ken story from the late '90s.  I was at a conference
> that I won't name where Ken gave a talk about his compression work; if I
> remember correctly his goal was to fit all of the Billboard Top 100 songs
> of all time onto a single CD.  He showed us the big stack of disks that he
> made to give to us, but then said that to his surprise the the lawyers
> refused to give permission.  At that point he became very focused on messing
> with his slides while everyone got up, got in line, and took a disc.  After
> the pile was gone Ken looked up and nonchalantly continued his talk.
> 
> That might also have been the conference at which Ken showed us videos of
> him in a MIG.
> 
> Jon

[TUHS] Re: forgotten versions

[Brad Spencer]

Larry McVoy <lm@mcvoy.com> writes:

> On Tue, Jun 21, 2022 at 05:56:02PM -0600, Jacob Moody wrote:
>> I recently stumbled across the existence of datakit
>> when going through the plan9foundation source archives.
>> Would be curious to hear more about its involvement
>> with plan9.
>
> Pretty sure datakit predated Plan 9, didn't Greg Chesson work on that?
> He was my mentor at SGI, my memory is datakit was sort of early on in
> his career and then he did XTP, which nobody knows about but I believe
> is still used by the military.
>
> Unless the early Bell Labs datakit and the Plan 9 datakit are different
> things.


When I was at AT&T in the early to mid '90s Datakit could manifest in a
couple of ways.  The simplest was as a tty ..  that is you had a serial
terminal and used a dial string with bangs in it to get somewhere.  This
method would have used some number of copper pairs into a RJ45 to DB25
adaptor connected to the terminal.  The terminals were usually 730s or
6xx (630s maybe).  They had some graphics ability, sort of, with some
windowing support.  The version of SVR3 we had running on the Vaxs had a
program in it that would be able to take advantage of the windowing
features of the 730 over a serial tty line (multiple windows, X-Windows
like sort of).  I have totally forgotten what that was called, however.
These terminals also had a mouse with them.  The second way that Datakit
would show itself was as a fiber pair tied directly to a computer
system.  There were Datakit fiber boards for nearly all of the platforms
that the group I was in used...  Vax (via a companion box), Tandem, Sun
Sparc, at the very least.  There was, usually, a third party kernel
driver required that would sometimes be a bit messy and/or have a
personality to it.  This set up sometimes provided a dkcu command and/or
a modified cu command and you could use a bang path dial string from the
system to get somewhere else using the Datakit network and act like a
tty.  Or, you could do native Datakit in your user land code.  This is
what the product I worked on did to talk to a Datakit network at the
RBOCs to get access to the switches in the telco network for monitoring
purposes.  Often in those cases, Datakit would be transported over a
X.25 network.  Later, as ethernet and TCP/UDP/IP became the thing, the
switches learned how to speak TCP/IP, although sometimes indirectly
though a translator box in front of the switch.  A number of the telco
switches we talked to spoke a dialect of X.25 called BX.25 (Bell X.25 or
some such) and the translator boxes would exist on the switch side and
our side and basically tunnel BX.25 over TCP/IP.  This was a bit
different then using the Datakit network to get to the switch, but I
seem to remember that some RBOCs did something where BX.25 was sent via
Datakit which in the wider area network was transported over X.25 to the
monitoring system.

There were things called Datakit switches that was a cabinet a few feet
tall and a couple of feet wide.  It housed a bunch of boards of your
choosing depending on how you wanted to use Datakit.  Our group had
their own switch at the site I was at run by the persons dealing with
our development lab.  There was also a number of Datakit switches for
the site itself run by the general IT organization.  I seem to remember
those switches having hot pluggable boards with an embedded 3B system
inside (although I may be misremembering that a bit).





-- 
Brad Spencer - brad@anduin.eldar.org - KC8VKS - http://anduin.eldar.org

[TUHS] Re: forgotten versions

[Rob Pike]

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

The Plan 9 CD-ROM needed about 100MB for the full distribution, if that. We
hatched a plan to fill up the rest with encoded music and include the
software to decode it. (We wanted to get the encoder out too, but lawyers
stood in the way. Keep reading.) Using connections I had with folks in the
area, and some very helpful friends in the music business, I got permission
to distribute several hours of existing recorded stuff from groups like the
Residents and Wire. Lou Reed gave a couple of pieces too - he was very
interested in Ken and Sean's work (which, it should be noted, was built on
groundbreaking work done in the acoustics center at Bell Labs) and visited
us to check it out. Debby Harry even recorded an original song for us in
the studio.

We had permission for all this of course, and releases from everyone
involved. It was very exciting.

So naturally, just before release, an asshole (I am being kind) lawyer at
AT&T headquarters in Manhattan stopped the project cold. In a phone call
that treated me as shabbily as I have ever been, he said he didn't know who
these "assholes" (again, but this time his term) were and therefore the
releases were meaningless because anyone could have written them.

And that, my friends, is why MP-3 took off instead of the far better
follow-on system we were on the cusp of getting out the door.

-rob

P.S. No, I don't have the music any more. Too sad to keep.


On Wed, Jun 22, 2022 at 12:19 PM Andrew Hume <andrew@humeweb.com> wrote:

> the early versions of the audio compression stuff were not quite is good as
> the later versions (which became apples stuff) but compressed to
> substantially
> smaller size. ken compressed 2-3 hrs or so of music for my wedding and that
> was rather less than a CD.
>
> > On Jun 21, 2022, at 7:14 PM, Jon Steinhart <jon@fourwinds.com> wrote:
> >
> > George Michaelson writes:
> >> There was this persisting story that Ken got permission from somebody
> >> like CBS or Sony to have a very large amount of classical music on a
> >> 400MB drive, for research purposes. No, really: he was doing some
> >> psycho-acoustic thing comparing compressed to uncompressed for
> >> somebody, or improving on the fraunhoffer algorithms which became MP3.
> >> The point was, the rest of us had to listen to CDs and Ken had the
> >> complete works of Bach (or something) on a hard drive, which we were
> >> told he kept in the office, and played at home over a landline of some
> >> horrendously high bandwidth, un-imaginable speeds like a megabit,
> >> imagine, a MILLION of those suckers. How dare he. Thats more than the
> >> whole of queensland. I imagine the truth is much less interesting, and
> >> there was no major IPR fraud going on at the labs coding stuff as MP3
> >> like we imagined, under the table.
> >>
> >> I imagine this would also have been a Datakit T-1. But surely that was
> >> a 1.44mbit carrier? T1 was smaller than E1 because europeans and
> >> asians learned to count to 32 not 24.
> >>
> >> -G
> >
> > This reminds me of a Ken story from the late '90s.  I was at a conference
> > that I won't name where Ken gave a talk about his compression work; if I
> > remember correctly his goal was to fit all of the Billboard Top 100 songs
> > of all time onto a single CD.  He showed us the big stack of disks that
> he
> > made to give to us, but then said that to his surprise the the lawyers
> > refused to give permission.  At that point he became very focused on
> messing
> > with his slides while everyone got up, got in line, and took a disc.
> After
> > the pile was gone Ken looked up and nonchalantly continued his talk.
> >
> > That might also have been the conference at which Ken showed us videos of
> > him in a MIG.
> >
> > Jon
>
>

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

[TUHS] Re: forgotten versions

[George Michaelson]

as usual, truth is stranger than fiction, or the chinese whispers
versions of this which got out.  What a very sad, but all to
believable story. Believable but.. if you saw this as an episode of a
TV series, you'd say "nah.. this couldn't happen in real life"

-G

[TUHS] Re: Sockets vs Streams (was Re: forgotten versions

[Norman Wilson]

As one of the few remaining people who has actually worked
with the original dmr stream I/O system, I'd love to dive
into the debate here, but I don't have time.  I can't resist
commenting on a few things that have flown by, though.  Maybe
I can find time to engage better on the weekend.

-- If you think there were no record delimiters in the stream
system, you don't know enough about it.  A good resource to
repair that is Dennis's BSTJ paper:

	https://www.bell-labs.com/usr/dmr/www/st.pdf

It's an early description and some of the details later
evolved (for example we realized that once pipes were
streams, we no longer needed pseudoterminals) but the
fundamentals remained constant.

See the section about Message blocks, and the distinction
between data and control blocks.  Delimiters were one kind
of control; there were others, some of them potentially
specific to the network at hand.  In particular, Datakit
(despite being a virtual-circuit network) had several sorts
of control words, including message delimiters.  Delimiters
were necessary even just for terminals, though: how else
does the generic read(2) code know to return early, before
filling the buffer, when a complete line has arrived?

-- It's hard to compare sockets to streams and make much
sense, because they are very different kinds of thing.
When people talk about sockets, especially when complaining
that sockets are a mess, they usually mean the API: system
calls like connect and listen and getpeername and so on.

The stream system was mainly about the internal structure--
the composable modules and the general-purpose queue interface
between them, so that you could take a stream representing
an (already set up) network connection and push the tty
module on it and have a working remote terminal, no need
for user-mode programs and pseudo-terminals.

It's not inconceivable to build a system with socket-like
API and stream internals.

-- Connection setup was initially done with network-specific
magic messages and magic ioctls.  Later we moved the knowledge
of that messy crap into network-specific daemons, so a user
program could make a network call just by calling
	fd = ipcopen("string-destination-name")
without knowing or caring whether the network transport was
TCP or Datakit or involved forwarding over Datakit to a
gateway that then placed a TCP call to the Internet or whatnot.
That's what the connection server was all about:

	https://www.bell-labs.com/usr/dmr/www/spe.pdf

Again, the API is not specific to the stream system.  It
wouldn't be hard to write a connection server that provided
the same universal just-use-a-string interface (with the
privileged parts or network details left up to daemons)
on a system with only socket networking; the only subtle
bit is that it needs to be possible to pass an open file
descriptor from one process to another (on the same system),
which I don't think the socket world had early on but I
believe they added long ago.

-- There's nothing especially hard about UDP or broadcast.
It's not as if the socket abstraction has some sort of magic
datagram-specific file descriptor.  Since every message sent
and every message received has to include the far end's
address info, you have to decide how to do that, whether
by specifying a format for the data (the first N bytes are
always the remote's address, for example) or provide an
out-of-band mechanism (some ioctl mess that lets you
supply it separately, a la sendto/recvfrom, and encodes it
as a control message).

There was an attempt to make UDP work in the 9th/10th edition
era.  I don't think it ever worked very cleanly.  When I
took an unofficial snapshot and started running the system
at home in the mid-1990s, I ended up just tossing UDP out,
because I didn't urgently need it (at the time TCP was good
enough for DNS, and I had to write my own DNS resolver anyway).
I figured I'd get around to fixing it later but never did.
But I think the only hard part is in deciding on an interface.

-- It's certainly true that the Research-system TCP/IP code
was never really production-quality (and I say that even
though I used it for my home firewall/gateway for 15 years).
TCP/IP wasn't taken as seriously as it ought to have been
by most of us in 1127 in the 1980s.  But that wasn't because
of the stream structure--the IP implementation was in fact
a copy of that from 4.2 (I think) BSD, repackaged and
shoehorned into the stream world by Robert T Morris, and
later cleaned up quite a bit by Paul Glick.  Maybe it would
have worked better had it been done from scratch by someone
who cared a lot about it, as the TCP/IP implementors in the
BSD world very much did.  Certainly it's a non-trivial design
problem--the IP protocols and their sloppy observance of
layering (cf the `pseudo header' in the TCP and UDP standards)
make them more complicated to implement in a general-purpose
framework.

Or maybe it just can't be done, but I wish someone had
tried in the original simpler setup rather than the
cluttered SVr4 STREAMS.

Norman Wilson
Toronto ON