[-- 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 --]
[-- 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 --]
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
>
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
> >
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.
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 #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 --]
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.
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
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!).
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.
[-- 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 --]
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 #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 --]
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 #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 --]
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 > >
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 > > >
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
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
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
[-- 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 --]
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
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
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.)
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.
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 #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 --]
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.
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.
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
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.
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
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
[-- 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 --]
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