The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
* [TUHS] Re: forgotten versions
@ 2022-06-18  0:35 Douglas McIlroy
  2022-06-18  5:00 ` Kevin Bowling
  0 siblings, 1 reply; 52+ messages in thread
From: Douglas McIlroy @ 2022-06-18  0:35 UTC (permalink / raw)
  To: TUHS main list

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

Besides streams, file system switch, /proc, and /dev/fd. v8 had the
Blit. Though Rob's relevant patent evoked disgruntled rumblings from
MIT that window systems were old hat, the Blit pioneered multiple
windows as we know them today. On the contemporary Lisp Machine, for
example, active computation happened in only one window at a time.

V8 also had Peter Weinberger's Remote File System. Unlike NFS, RFS
mapped UIDS, thus allowing files to be shared among computers in
different jurisdictions with different UID lists. Unfortunately, RFS
went the way of Reiser paging.

And then there was Norman Wilson, who polished the kernel and
administrative tools. All kinds of things became smaller and
cleaner--an inimitable accomplishment

> No clue what was new in V10

This suggests I should put on my to-do list an update of the Research
Unix Reader's combined table of man-page contents, which covers only
v1-v9. I think it's fair to say, though, that nothing introduced in
v10 was as influential as the features mentioned above.

Doug

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

* [TUHS] Re: forgotten versions
  2022-06-18  0:35 [TUHS] Re: forgotten versions Douglas McIlroy
@ 2022-06-18  5:00 ` Kevin Bowling
  2022-06-18  5:13   ` Adam Thornton
  2022-06-19 20:46   ` [TUHS] RFS (was Re: Re: forgotten versions) Derek Fawcus
  0 siblings, 2 replies; 52+ messages in thread
From: Kevin Bowling @ 2022-06-18  5:00 UTC (permalink / raw)
  To: Douglas McIlroy; +Cc: TUHS main list

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

On Fri, Jun 17, 2022 at 5:35 PM Douglas McIlroy <
douglas.mcilroy@dartmouth.edu> wrote:

> > I can think of at least 4 things, some big, some small, where post-V7
> > Research Unix was influential
>
> Besides streams, file system switch, /proc, and /dev/fd. v8 had the
> Blit. Though Rob's relevant patent evoked disgruntled rumblings from
> MIT that window systems were old hat, the Blit pioneered multiple
> windows as we know them today. On the contemporary Lisp Machine, for
> example, active computation happened in only one window at a time.
>
> V8 also had Peter Weinberger's Remote File System. Unlike NFS, RFS
> mapped UIDS, thus allowing files to be shared among computers in
> different jurisdictions with different UID lists. Unfortunately, RFS
> went the way of Reiser paging.
>

I believe RFS shipped in SVR3, at least as a package for the 3b2.


> And then there was Norman Wilson, who polished the kernel and
> administrative tools. All kinds of things became smaller and
> cleaner--an inimitable accomplishment
>
> > No clue what was new in V10
>
> This suggests I should put on my to-do list an update of the Research
> Unix Reader's combined table of man-page contents, which covers only
> v1-v9. I think it's fair to say, though, that nothing introduced in
> v10 was as influential as the features mentioned above.
>
> Doug
>

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

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

* [TUHS] Re: forgotten versions
  2022-06-18  5:00 ` Kevin Bowling
@ 2022-06-18  5:13   ` Adam Thornton
  2022-06-18 16:58     ` Clem Cole
  2022-06-19 20:46   ` [TUHS] RFS (was Re: Re: forgotten versions) Derek Fawcus
  1 sibling, 1 reply; 52+ messages in thread
From: Adam Thornton @ 2022-06-18  5:13 UTC (permalink / raw)
  To: Kevin Bowling; +Cc: Douglas McIlroy, TUHS main list

Could users outside Bell Labs actually get their hands on post-v7 Research Unixes?

It was always my impression that The Thing You Could Get From The Phone Company, after v7, was System III or System V.  Obviously it's not surprising that Research Unix features from later versions ended up in SysV, but did anyone actually learn about them from v8-v10, or just by way of SysV ?

Was there some (legal) mechanism for the post-v7 Unixes to get out into people's hands?

Adam

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

* [TUHS] Re: forgotten versions
  2022-06-18  5:13   ` Adam Thornton
@ 2022-06-18 16:58     ` Clem Cole
  2022-06-18 17:18       ` Warner Losh
  0 siblings, 1 reply; 52+ messages in thread
From: Clem Cole @ 2022-06-18 16:58 UTC (permalink / raw)
  To: Adam Thornton; +Cc: Douglas McIlroy, TUHS main list

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

TUHS Source Archive BTL Research Distributions
<https://streaklinks.com/BF0jaowo6HdJanOkuwoN8MED/https%3A%2F%2Fwww.tuhs.org%2FArchive%2FDistributions%2FResearch%2F>
you should find them all.
ᐧ

On Sat, Jun 18, 2022 at 1:13 AM Adam Thornton <athornton@gmail.com> wrote:

> Could users outside Bell Labs actually get their hands on post-v7 Research
> Unixes?
>
> It was always my impression that The Thing You Could Get From The Phone
> Company, after v7, was System III or System V.  Obviously it's not
> surprising that Research Unix features from later versions ended up in
> SysV, but did anyone actually learn about them from v8-v10, or just by way
> of SysV ?
>
> Was there some (legal) mechanism for the post-v7 Unixes to get out into
> people's hands?
>
> Adam

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

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

* [TUHS] Re: forgotten versions
  2022-06-18 16:58     ` Clem Cole
@ 2022-06-18 17:18       ` Warner Losh
  2022-06-18 17:57         ` Clem Cole
  0 siblings, 1 reply; 52+ messages in thread
From: Warner Losh @ 2022-06-18 17:18 UTC (permalink / raw)
  To: Clem Cole; +Cc: Douglas McIlroy, TUHS main list

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

Are these systems bootable? I see all the source, but recall previous
discussions
about how bootstrapping them was tricky, or at least involved a large
number of
steps, each of which wasn't bad, but the whole path wasn't well mapped out.
For V[67] we at least have boot tapes from back in the day, and V5 has a
bootable
disk image...

Warner

On Sat, Jun 18, 2022 at 10:58 AM Clem Cole <clemc@ccc.com> wrote:

> TUHS Source Archive BTL Research Distributions
> <https://streaklinks.com/BF0jaowo6HdJanOkuwoN8MED/https%3A%2F%2Fwww.tuhs.org%2FArchive%2FDistributions%2FResearch%2F>
> you should find them all.
> ᐧ
>
> On Sat, Jun 18, 2022 at 1:13 AM Adam Thornton <athornton@gmail.com> wrote:
>
>> Could users outside Bell Labs actually get their hands on post-v7
>> Research Unixes?
>>
>> It was always my impression that The Thing You Could Get From The Phone
>> Company, after v7, was System III or System V.  Obviously it's not
>> surprising that Research Unix features from later versions ended up in
>> SysV, but did anyone actually learn about them from v8-v10, or just by way
>> of SysV ?
>>
>> Was there some (legal) mechanism for the post-v7 Unixes to get out into
>> people's hands?
>>
>> Adam
>
>

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

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

* [TUHS] Re: forgotten versions
  2022-06-18 17:18       ` Warner Losh
@ 2022-06-18 17:57         ` Clem Cole
  0 siblings, 0 replies; 52+ messages in thread
From: Clem Cole @ 2022-06-18 17:57 UTC (permalink / raw)
  To: Warner Losh; +Cc: Douglas McIlroy, TUHS main list

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

On Sat, Jun 18, 2022 at 1:19 PM Warner Losh <imp@bsdimp.com> wrote:

> Are these systems bootable?
>
It has been so reported - in this same space IIRC


> I see all the source, but recall previous discussions
> about how bootstrapping them was tricky, or at least involved a large
> number of
> steps, each of which wasn't bad, but the whole path wasn't well mapped out.
>
I believe that is also correct.  Been a ToDo item of mine to try to get
them running.  Supposedly people used V8 to get V9 running.



> For V[67] we at least have boot tapes from back in the day, and V5 has a
> bootable disk image...
>
Yep and it helps, some of us did it back in the day.

The problem has been expressed, that V{8,9,10} like Plan9, were locked away
for whatever reasons.   They were all created post-Judge Green when the
behavior of AT&T formally WRT to the rest of the world changed.   I don't
think the people in 1127's attitude changed (certainly not of my friends
that I interacted with) but what they could do was more constrained.

Before the 1956 consent decree, AT&T corporate was not allowed to be in the
computer business, post-Judge Green they were actively trying to be and
their SW was formally System III and the later System V versions.   BTW:
AT&T was unique in this behavior.   IBM and DEC did it too.  One of my
favorite stories (that I personally lived) is that of Motorola, which
became the 68000.  When I first got it (at Teklabs) it did not have a
number - which much, much later beget the 4404, it was explicitly told to
us that it was a toy and it was not committed.  We managed to get approx
$100 of them to make the first Magnolia machine
<https://streaklinks.com/BF0w99hsbHL5eGZttg1NqgOi/https%3A%2F%2Farchive.org%2Fdownload%2Fbitsavers_tektronixmliaplan_4739361%2F1980-9-16-magnolia-plan.pdf>
 But the original developers had given a couple of them to the research
teams of a few of their friends - the 6809 was the official product.
 Famously, when IBM asked Moto to bid on a processor for what was to later
become the PC, they had been playing with the future 68000 in NY and Conn,
already.  When the folks came to Austin, IBM was pressured to use the 6809
by Motorola marketing, and officially told that the other chip had no
future and was an experiment.

I always looked at V{8,9,10} and Plan9 in the same way.  BTW: I also think
that's part of why BSD got such a lead.   AT&T Marketing kept the 'consider
it standard' stuff in people's faces with System III and later Sys V.  Many
users  (like me) and our firms wanted no part of it.   If AT&T had been
offered V{8,9,10} or Plan9 under the same basic terms that V7 had
been, I suspect
that the story might have had a different ending.

Clem




> ᐧ

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

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

* [TUHS] RFS (was Re: Re: forgotten versions)
  2022-06-18  5:00 ` Kevin Bowling
  2022-06-18  5:13   ` Adam Thornton
@ 2022-06-19 20:46   ` Derek Fawcus
  2022-06-19 23:07     ` [TUHS] " Larry McVoy
  1 sibling, 1 reply; 52+ messages in thread
From: Derek Fawcus @ 2022-06-19 20:46 UTC (permalink / raw)
  To: TUHS main list

On Fri, Jun 17, 2022 at 10:00:19PM -0700, Kevin Bowling wrote:
> On Fri, Jun 17, 2022 at 5:35 PM Douglas McIlroy douglas.mcilroy@dartmouth.edu> wrote:
> >
> > V8 also had Peter Weinberger's Remote File System. Unlike NFS, RFS
> > mapped UIDS, thus allowing files to be shared among computers in
> > different jurisdictions with different UID lists. Unfortunately, RFS
> > went the way of Reiser paging.
> 
> I believe RFS shipped in SVR3, at least as a package for the 3b2.

Apparently. I've a book (ISBN 0-672-48440-4) with a short chapter on it within, authored by Douglas Harris.

It happens to state:

  AT&T's approach towards UNIX System V, Release 3.0 and beyond is to provide a /Remote File System/ (RFS) that is an extension of the ordinary file system arrangement. […]

  […]

  Remote File System Release 1.0 was first introduced in 1986 with Release 3.0 of UNIX System V for AT&T 3B2 machines with Starlan network connections. It makes heavy use of STREAMS, which were also introduced at that time. The next release RFS 1.1, accompanying System V Release 3.1, was greatly enhanced. At this time releases for other machines became available. In particular, with the release of a standard UNIX for Intel 80386-based machines that incorporated STREAMS, vendors of networking products could arrange for RFS to operate with those products, and RFS could run over Ethernet or any other network that could support a solid transport connection such as TCP/IP or NetBIOS. […]

So that may be somewhere to search, possibly someone can find a '386 image with it included?

DF

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

* [TUHS] Re: RFS (was Re: Re: forgotten versions)
  2022-06-19 20:46   ` [TUHS] RFS (was Re: Re: forgotten versions) Derek Fawcus
@ 2022-06-19 23:07     ` Larry McVoy
  2022-06-19 23:19       ` Brad Spencer
  0 siblings, 1 reply; 52+ messages in thread
From: Larry McVoy @ 2022-06-19 23:07 UTC (permalink / raw)
  To: Derek Fawcus; +Cc: TUHS main list

On Sun, Jun 19, 2022 at 09:46:31PM +0100, Derek Fawcus wrote:
> On Fri, Jun 17, 2022 at 10:00:19PM -0700, Kevin Bowling wrote:
> > On Fri, Jun 17, 2022 at 5:35 PM Douglas McIlroy douglas.mcilroy@dartmouth.edu> wrote:
> > >
> > > V8 also had Peter Weinberger's Remote File System. Unlike NFS, RFS
> > > mapped UIDS, thus allowing files to be shared among computers in
> > > different jurisdictions with different UID lists. Unfortunately, RFS
> > > went the way of Reiser paging.
> > 
> > I believe RFS shipped in SVR3, at least as a package for the 3b2.
> 
> Apparently. I've a book (ISBN 0-672-48440-4) with a short chapter on it within, authored by Douglas Harris.
> 
> It happens to state:
> 
>   AT&T's approach towards UNIX System V, Release 3.0 and beyond is to provide a /Remote File System/ (RFS) that is an extension of the ordinary file system arrangement. [???]

SunOS 4.x shipped RFS, Howard Chartok (my office mate at the time) did
the port I believe.  Thankless work since Sun ran their entire campus
on NFS; RFS never got any attention.  It's too bad because it did solve
some problems that NFS just punted on.  NFS is Clem's law in action,
it was good enough, not great, but still won.

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

* [TUHS] Re: RFS (was Re: Re: forgotten versions)
  2022-06-19 23:07     ` [TUHS] " Larry McVoy
@ 2022-06-19 23:19       ` Brad Spencer
  2022-06-20  5:03         ` Arno Griffioen via TUHS
  0 siblings, 1 reply; 52+ messages in thread
From: Brad Spencer @ 2022-06-19 23:19 UTC (permalink / raw)
  To: Larry McVoy; +Cc: tuhs

Larry McVoy <lm@mcvoy.com> writes:

> On Sun, Jun 19, 2022 at 09:46:31PM +0100, Derek Fawcus wrote:
>> On Fri, Jun 17, 2022 at 10:00:19PM -0700, Kevin Bowling wrote:
>> > On Fri, Jun 17, 2022 at 5:35 PM Douglas McIlroy douglas.mcilroy@dartmouth.edu> wrote:
>> > >
>> > > V8 also had Peter Weinberger's Remote File System. Unlike NFS, RFS
>> > > mapped UIDS, thus allowing files to be shared among computers in
>> > > different jurisdictions with different UID lists. Unfortunately, RFS
>> > > went the way of Reiser paging.
>> > 
>> > I believe RFS shipped in SVR3, at least as a package for the 3b2.
>> 
>> Apparently. I've a book (ISBN 0-672-48440-4) with a short chapter on it within, authored by Douglas Harris.
>> 
>> It happens to state:
>> 
>>   AT&T's approach towards UNIX System V, Release 3.0 and beyond is to provide a /Remote File System/ (RFS) that is an extension of the ordinary file system arrangement. [???]
>
> SunOS 4.x shipped RFS, Howard Chartok (my office mate at the time) did
> the port I believe.  Thankless work since Sun ran their entire campus
> on NFS; RFS never got any attention.  It's too bad because it did solve
> some problems that NFS just punted on.  NFS is Clem's law in action,
> it was good enough, not great, but still won.




I remember SunOS 4.x having RFS..  I never used it but I vaguely recall
(probably misremembering) that there was a warning in the man page about
it that it might not interoperate with /dev devices correct if the byte
order of the machines was different.  I seem to recall that with RFS if
/dev was remoted you actually accessed the remote devices and not just
the device nodes from the system that /dev was mounted to.  At the AT&T
site I was at we used NFS exclusively too.



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

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

* [TUHS] Re: RFS (was Re: Re: forgotten versions)
  2022-06-19 23:19       ` Brad Spencer
@ 2022-06-20  5:03         ` Arno Griffioen via TUHS
  2022-06-20  6:53           ` Theodore Ts'o
  0 siblings, 1 reply; 52+ messages in thread
From: Arno Griffioen via TUHS @ 2022-06-20  5:03 UTC (permalink / raw)
  To: tuhs

On Sun, Jun 19, 2022 at 07:19:31PM -0400, Brad Spencer wrote:
> order of the machines was different.  I seem to recall that with RFS if
> /dev was remoted you actually accessed the remote devices and not just
> the device nodes from the system that /dev was mounted to.  At the AT&T
> site I was at we used NFS exclusively too.

Yup..

I used RFS on variuous SVR3 and SVR4 platforms back in the days, usually
for this purpose. Eg. to provide a simple way of giving 'workstation'
users access to modem-banks attached to central servers.

It worked fine as long as the platforms were pretty similar (eg. all
i386 based), but could indeed get 'interesting' once you added bits
in the mix that were based on other CPUs.

For me RFS came along 'before its time' as by design it could not handle 
things like creating diskless or dataless workstations easily, exactly 
because of the more fine-grained, file oriented, setup and that's where 
NFS did it's thing. 

The features RFS brought did, unfortunately, not seem as useful at the time 
for general applications as things like broadly sharing boot and/or home/staff
environments was 'the thing' needed for a long time and NFS did that
very (too ;) ) easily.

However.. I do see it more like the UNIX 'grandad' for things we now
have like SMB and cloud sync/share 'filesystem' tools which operate
much more on a style of access and granularity like RFS did.

I always wondered if the Mircrosoft engineers that worked on the initial
SMB implementations looked at RFS for ideas.

							Bye, Arno.

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

* [TUHS] Re: RFS (was Re: Re: forgotten versions)
  2022-06-20  5:03         ` Arno Griffioen via TUHS
@ 2022-06-20  6:53           ` Theodore Ts'o
  0 siblings, 0 replies; 52+ messages in thread
From: Theodore Ts'o @ 2022-06-20  6:53 UTC (permalink / raw)
  To: Arno Griffioen; +Cc: tuhs

I'll note there was another RFS that was posted to net.sources and
net.unix-wizards by Todd Brunhoff in January 1986.  This was
completely different from the AT&T System V's; Todd's RFS was done as
part of his Master's Degree at the University of Denver, and it was
heavily dependant on BSD 4.2/4.3's sockets interface.

For more information, see:

   https://groups.google.com/g/net.unix-wizards/c/QwRVsZS9jEM/m/V4ZI64CKopsJ?pli=1

We used this version of RFS at MIT Project Athena for a while before
switching to AFS, and it's mentioned in Professor Saltzer's Athena
Technical Plan, in the section entitled, "The Athena File Storage
Model":

    https://web.mit.edu/saltzer/www/publications/athenaplan/c.6.pdf

Project Athena integrated MIT Kerberos (Version 4) into both NFS and
RFS, and of course AFS used Kerberos for its authentication tokens.

     	    	       	    	     	     - Ted

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

* [TUHS] Re: forgotten versions
  2022-06-25 20:45   ` Paul Ruizendaal
@ 2022-06-27  0:57     ` Kevin Bowling
  0 siblings, 0 replies; 52+ messages in thread
From: Kevin Bowling @ 2022-06-27  0:57 UTC (permalink / raw)
  To: Paul Ruizendaal; +Cc: tuhs

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

On Sat, Jun 25, 2022 at 1:46 PM Paul Ruizendaal <pnr@planet.nl> wrote:

>
> > On 25 Jun 2022, at 21:16, Anthony Martin <ality@pbrane.org> wrote:
> >
> > The following papers are a good overview of Datakit and its
> > predecessors.
> >
> > A. Fraser, "Towards a Universal Data Transport System," in IEEE
> > Journal on Selected Areas in Communications, vol. 1, no. 5, pp.
> > 803-816, November 1983, doi: 10.1109/JSAC.1983.1145998.
> >
> > A. G. Fraser, "Early experiments with asynchronous time division
> > networks," in IEEE Network, vol. 7, no. 1, pp. 12-26, Jan. 1993,
> > doi:10.1109/65.193084.
> >
> > The latter mentions Plan 9 but only in passing.
>
> Yes, those are great papers - unfortunately behind a paywall.
>
> There is a great 1994 video on Youtube by Sandy Fraser himself that more
> or less follows the 1993 paper:
>
> https://www.youtube.com/watch?v=ojRtJ1U6Qzw
>

Superb.  The story of an invention told through metaphors and mistakes.


> As Doug mentioned on this list, Sandy Fraser passed away earlier this
> month.
>

I was unfamiliar with Sandy prior to this thread.


> In the past years I’ve worked on understanding (early) Datakit and Sandy
> Fraser and his wife were most kind with assistance looking for papers. I’ve
> also benefitted from the input of Bill Marshall and of course Doug McIlroy.
> I’ll share my summary of Research Datakit in a separate post.
>
> Paul
>
> > Paul Ruizendaal <pnr@planet.nl> once said:
> >> Probably you will see echoes of this in early Plan9 network code, but I
> have not studied that.
> >
> > As someone how has studied Plan 9 extensively, though with no insider
> > knowledge, it's definitely noticeable.
> >
> > "In the aftermath, perhaps the most valuable effect of dealing with
> > Datakit was to encourage the generalized and flexible approach to
> > networking begun in 8th edition Unix that is carried forward into Plan
> > 9." - dmr (2004)
> >
> > Cheers,
> >  Anthony
>
>

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

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

* [TUHS] Re: forgotten versions
  2022-06-25 19:16 ` Anthony Martin
@ 2022-06-25 20:45   ` Paul Ruizendaal
  2022-06-27  0:57     ` Kevin Bowling
  0 siblings, 1 reply; 52+ messages in thread
From: Paul Ruizendaal @ 2022-06-25 20:45 UTC (permalink / raw)
  To: Anthony Martin; +Cc: tuhs


> On 25 Jun 2022, at 21:16, Anthony Martin <ality@pbrane.org> wrote:
> 
> The following papers are a good overview of Datakit and its
> predecessors.
> 
> A. Fraser, "Towards a Universal Data Transport System," in IEEE
> Journal on Selected Areas in Communications, vol. 1, no. 5, pp.
> 803-816, November 1983, doi: 10.1109/JSAC.1983.1145998.
> 
> A. G. Fraser, "Early experiments with asynchronous time division
> networks," in IEEE Network, vol. 7, no. 1, pp. 12-26, Jan. 1993,
> doi:10.1109/65.193084.
> 
> The latter mentions Plan 9 but only in passing.

Yes, those are great papers - unfortunately behind a paywall.

There is a great 1994 video on Youtube by Sandy Fraser himself that more or less follows the 1993 paper: 

https://www.youtube.com/watch?v=ojRtJ1U6Qzw

As Doug mentioned on this list, Sandy Fraser passed away earlier this month.

In the past years I’ve worked on understanding (early) Datakit and Sandy Fraser and his wife were most kind with assistance looking for papers. I’ve also benefitted from the input of Bill Marshall and of course Doug McIlroy. I’ll share my summary of Research Datakit in a separate post.

Paul

> Paul Ruizendaal <pnr@planet.nl> once said:
>> Probably you will see echoes of this in early Plan9 network code, but I have not studied that.
> 
> As someone how has studied Plan 9 extensively, though with no insider
> knowledge, it's definitely noticeable.
> 
> "In the aftermath, perhaps the most valuable effect of dealing with
> Datakit was to encourage the generalized and flexible approach to
> networking begun in 8th edition Unix that is carried forward into Plan
> 9." - dmr (2004)
> 
> Cheers,
>  Anthony


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

* [TUHS] Re: forgotten versions
  2022-06-24  6:47 [TUHS] Re: forgotten versions Paul Ruizendaal
@ 2022-06-25 19:16 ` Anthony Martin
  2022-06-25 20:45   ` Paul Ruizendaal
  0 siblings, 1 reply; 52+ messages in thread
From: Anthony Martin @ 2022-06-25 19:16 UTC (permalink / raw)
  To: Paul Ruizendaal; +Cc: tuhs

The following papers are a good overview of Datakit and its
predecessors.

A. Fraser, "Towards a Universal Data Transport System," in IEEE
Journal on Selected Areas in Communications, vol. 1, no. 5, pp.
803-816, November 1983, doi: 10.1109/JSAC.1983.1145998.

A. G. Fraser, "Early experiments with asynchronous time division
networks," in IEEE Network, vol. 7, no. 1, pp. 12-26, Jan. 1993,
doi:10.1109/65.193084.

The latter mentions Plan 9 but only in passing.

Paul Ruizendaal <pnr@planet.nl> once said:
> Probably you will see echoes of this in early Plan9 network code, but I have not studied that.

As someone how has studied Plan 9 extensively, though with no insider
knowledge, it's definitely noticeable.

"In the aftermath, perhaps the most valuable effect of dealing with
Datakit was to encourage the generalized and flexible approach to
networking begun in 8th edition Unix that is carried forward into Plan
9." - dmr (2004)

Cheers,
  Anthony

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

* [TUHS] Re: forgotten versions
@ 2022-06-24  6:47 Paul Ruizendaal
  2022-06-25 19:16 ` Anthony Martin
  0 siblings, 1 reply; 52+ messages in thread
From: Paul Ruizendaal @ 2022-06-24  6:47 UTC (permalink / raw)
  To: tuhs


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.

There are at least 2 versions of Datakit. I my current understanding there are “Datakit” which is the research version, and “Datakit II” which seems to be the version that was broadly deployed into the AT&T network in the late 80’s -- but very likely the story is more complicated than that. Plan9 is contemporaneous with Datakit II.

In short, Sandy Fraser developed the “Spider” network in 1970-1974 and this was actively used with early Unix (at least V4, maybe earlier). Sandy was dissatisfied with Spider and used its learnings to start again. The key ideas seem to have gelled together around 1977 with the first switches being available in 1979 or so. The first deployment into the Bell system was around 1982 (initially connecting a handful of Bell sites).

In 1979/1980 there were two Datakit switches, one in the office of Greg Chesson who was writing the first iteration of its control software, and one in the office/lab of Gottfried Luderer et al., who used it to develop a distributed Unix.

Datakit at this time is well described in two papers that the ACM recently moved from behind its paywall:

https://dl.acm.org/doi/pdf/10.1145/1013879.802670  (mostly about 1980 Datakit)

https://dl.acm.org/doi/pdf/10.1145/800216.806604  (mostly about distributed Unix)

The Chesson control software was replaced by new code written by Lee McMahon around 1981 (note: this is still Datakit 1). The Datakit driver code in V8 is designed to work with this revised Datakit. Three aspects of Datakit show through in the design the V8-V10 networking code:
- a separation in control words and data words (this e.g. comes back in ‘streams')
- it works with virtual circuits; a connection is expensive to set up (‘dial’), but cheap to use
- it does not guarantee reliable packet delivery, but it does guarantee in-order delivery

Probably you will see echoes of this in early Plan9 network code, but I have not studied that.



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

* [TUHS] Re: forgotten versions
@ 2022-06-23  2:18 Noel Chiappa
  0 siblings, 0 replies; 52+ messages in thread
From: Noel Chiappa @ 2022-06-23  2:18 UTC (permalink / raw)
  To: tuhs; +Cc: jnc

    > From: Dan Cross

    > I believe that's actually a menu

Hence the "erroneous _impression_" (emphasis added).

I'm curious as to how they decided which models to run which editions on.
Although V4 _ran_ on the /45, split I+D wasn't supported - for user or kernel
- until V6. (I'm assuming a number of things - both in the kernel, and
applications - started hitting the 64KB limit, which led to its support.)


Speaking of split I+D, there's an interesting little mystery in V6 that at
one point in time I thought involved split I+D - but now that I look closely,
apparently not. The mystery involves a 'tombstone' in the V6 buf.h:

  #define B_RELOC 0200 /* no longer used */

I had created (in my mind) an explanation what this is all about - but now
that I look, it's probably all wrong!

My explanation involves the slightly odd layout of the kernel in physical
memory, with split I+D; data below the code, at physical 0. This actually
makes a lot of sense; it means the virtual address of any data (e.g. a
buffer) is the same as its physical address (needed for DMA). It does require
the oddness of 'sysfix', to invert the order of code+data in the system
binary, plus odd little quirks in the assembler startup (e.g. copying the
code up to make room for BSS).

So I thought that B_RELOC was a hangover from a time, at the start of split
I+D, when data _wasn't_ at physical 0, so a buffer's virtual and phsyical
addresses differed.

But that must be wrong (at least in any simple way). B_RELOC was in buf.h as
of V4 - the first kernel version in C - with no split I+D. So my theory has
to be wrong.

However, I am unable to find any code in the V4 kernel which uses it! So
unless someone who remembers the very early PDP-11 kernel can enlighten us,
its purpose will always remain a mystery!

	Noel

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

* [TUHS] Re: forgotten versions
  2022-06-22 12:06 Noel Chiappa
@ 2022-06-23  0:02 ` Dan Cross
  0 siblings, 0 replies; 52+ messages in thread
From: Dan Cross @ 2022-06-23  0:02 UTC (permalink / raw)
  To: Noel Chiappa; +Cc: The Eunuchs Hysterical Society

On Wed, Jun 22, 2022 at 8:06 AM Noel Chiappa <jnc@mercury.lcs.mit.edu> wrote:
>     > From: Paul Ruizendaal
>
>     > [c]  Fifth Edition UNIX     PDP-11/40   June     1974
>     > [d]  Sixth Edition UNIX     PDP-11/45   May      1975
>     > [e]  Seventh Edition UNIX   PDP-11/70   January  1979
>
> This table gives an erroneous impression of which versions supported which
> PDP-11 models. 4th Edition supported only the /45; 5th Edition added support
> for the /40; and the /70 appeared in 6th edition.

I believe that's actually a menu, and that selecting from it will connect you to
an (emulated) machine of the given type running that version of the OS.
Stephen Jones and LCM+L set that up for the Unix 50th anniversary.

        - Dan C.

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

* [TUHS] Re: forgotten versions
@ 2022-06-22 12:06 Noel Chiappa
  2022-06-23  0:02 ` Dan Cross
  0 siblings, 1 reply; 52+ messages in thread
From: Noel Chiappa @ 2022-06-22 12:06 UTC (permalink / raw)
  To: tuhs; +Cc: jnc

    > From: Paul Ruizendaal

    > [c]  Fifth Edition UNIX     PDP-11/40   June     1974
    > [d]  Sixth Edition UNIX     PDP-11/45   May      1975
    > [e]  Seventh Edition UNIX   PDP-11/70   January  1979

This table gives an erroneous impression of which versions supported which
PDP-11 models. 4th Edition supported only the /45; 5th Edition added support
for the /40; and the /70 appeared in 6th edition.

	Noel

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

* [TUHS] Re: forgotten versions
  2022-06-22  2:58                           ` Rob Pike
@ 2022-06-22  3:09                             ` George Michaelson
  0 siblings, 0 replies; 52+ messages in thread
From: George Michaelson @ 2022-06-22  3:09 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

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

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

* [TUHS] Re: forgotten versions
  2022-06-22  2:19                         ` Andrew Hume
@ 2022-06-22  2:58                           ` Rob Pike
  2022-06-22  3:09                             ` George Michaelson
  0 siblings, 1 reply; 52+ messages in thread
From: Rob Pike @ 2022-06-22  2:58 UTC (permalink / raw)
  To: Andrew Hume; +Cc: The Eunuchs Hysterical Society

[-- 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 --]

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

* [TUHS] Re: forgotten versions
  2022-06-22  0:13                 ` Larry McVoy
  2022-06-22  0:48                   ` Rob Pike
  2022-06-22  2:16                   ` Andrew Hume
@ 2022-06-22  2:55                   ` Brad Spencer
  2 siblings, 0 replies; 52+ messages in thread
From: Brad Spencer @ 2022-06-22  2:55 UTC (permalink / raw)
  To: Larry McVoy; +Cc: tuhs

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

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

* [TUHS] Re: forgotten versions
  2022-06-22  2:14                       ` Jon Steinhart
@ 2022-06-22  2:19                         ` Andrew Hume
  2022-06-22  2:58                           ` Rob Pike
  0 siblings, 1 reply; 52+ messages in thread
From: Andrew Hume @ 2022-06-22  2:19 UTC (permalink / raw)
  To: Jon Steinhart; +Cc: The Eunuchs Hysterical Society

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


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

* [TUHS] Re: forgotten versions
  2022-06-22  0:13                 ` Larry McVoy
  2022-06-22  0:48                   ` Rob Pike
@ 2022-06-22  2:16                   ` Andrew Hume
  2022-06-22  2:55                   ` Brad Spencer
  2 siblings, 0 replies; 52+ messages in thread
From: Andrew Hume @ 2022-06-22  2:16 UTC (permalink / raw)
  To: Larry McVoy; +Cc: tuhs

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.


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

* [TUHS] Re: forgotten versions
  2022-06-22  1:55                     ` George Michaelson
  2022-06-22  2:10                       ` Bakul Shah
@ 2022-06-22  2:14                       ` Jon Steinhart
  2022-06-22  2:19                         ` Andrew Hume
  1 sibling, 1 reply; 52+ messages in thread
From: Jon Steinhart @ 2022-06-22  2:14 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

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

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

* [TUHS] Re: forgotten versions
  2022-06-22  1:55                     ` George Michaelson
@ 2022-06-22  2:10                       ` Bakul Shah
  2022-06-22  2:14                       ` Jon Steinhart
  1 sibling, 0 replies; 52+ messages in thread
From: Bakul Shah @ 2022-06-22  2:10 UTC (permalink / raw)
  To: George Michaelson; +Cc: The Eunuchs Hysterical Society

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.


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

* [TUHS] Re: forgotten versions
  2022-06-22  0:48                   ` Rob Pike
@ 2022-06-22  1:55                     ` George Michaelson
  2022-06-22  2:10                       ` Bakul Shah
  2022-06-22  2:14                       ` Jon Steinhart
  0 siblings, 2 replies; 52+ messages in thread
From: George Michaelson @ 2022-06-22  1:55 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

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.

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

* [TUHS] Re: forgotten versions
  2022-06-22  0:13                 ` Larry McVoy
@ 2022-06-22  0:48                   ` Rob Pike
  2022-06-22  1:55                     ` George Michaelson
  2022-06-22  2:16                   ` Andrew Hume
  2022-06-22  2:55                   ` Brad Spencer
  2 siblings, 1 reply; 52+ messages in thread
From: Rob Pike @ 2022-06-22  0:48 UTC (permalink / raw)
  To: Larry McVoy; +Cc: The Eunuchs Hysterical Society

[-- 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 --]

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

* [TUHS] Re: forgotten versions
  2022-06-21 23:56               ` Jacob Moody
@ 2022-06-22  0:13                 ` Larry McVoy
  2022-06-22  0:48                   ` Rob Pike
                                     ` (2 more replies)
  0 siblings, 3 replies; 52+ messages in thread
From: Larry McVoy @ 2022-06-22  0:13 UTC (permalink / raw)
  To: Jacob Moody; +Cc: tuhs

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.

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

* [TUHS] Re: forgotten versions
  2022-06-19 18:38             ` Dan Cross
@ 2022-06-21 23:56               ` Jacob Moody
  2022-06-22  0:13                 ` Larry McVoy
  0 siblings, 1 reply; 52+ messages in thread
From: Jacob Moody @ 2022-06-21 23:56 UTC (permalink / raw)
  To: tuhs

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.


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

* [TUHS] Re: forgotten versions
  2022-06-19 18:32           ` Theodore Ts'o
@ 2022-06-19 18:38             ` Dan Cross
  2022-06-21 23:56               ` Jacob Moody
  0 siblings, 1 reply; 52+ messages in thread
From: Dan Cross @ 2022-06-19 18:38 UTC (permalink / raw)
  To: Theodore Ts'o; +Cc: The Eunuchs Hysterical Society

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

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

* [TUHS] Re: forgotten versions
  2022-06-19 14:47         ` Kenneth Goodwin
  2022-06-19 16:27           ` Al Kossow
@ 2022-06-19 18:32           ` Theodore Ts'o
  2022-06-19 18:38             ` Dan Cross
  1 sibling, 1 reply; 52+ messages in thread
From: Theodore Ts'o @ 2022-06-19 18:32 UTC (permalink / raw)
  To: Kenneth Goodwin; +Cc: The Eunuchs Hysterical Society

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

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

* [TUHS] Re: forgotten versions
  2022-06-19 14:47         ` Kenneth Goodwin
@ 2022-06-19 16:27           ` Al Kossow
  2022-06-19 18:32           ` Theodore Ts'o
  1 sibling, 0 replies; 52+ messages in thread
From: Al Kossow @ 2022-06-19 16:27 UTC (permalink / raw)
  To: tuhs

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


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

* [TUHS] Re: forgotten versions
  2022-06-19  8:53       ` Rob Pike
  2022-06-19  9:02         ` Angelo Papenhoff
@ 2022-06-19 14:47         ` Kenneth Goodwin
  2022-06-19 16:27           ` Al Kossow
  2022-06-19 18:32           ` Theodore Ts'o
  1 sibling, 2 replies; 52+ messages in thread
From: Kenneth Goodwin @ 2022-06-19 14:47 UTC (permalink / raw)
  To: Rob Pike; +Cc: The Eunuchs Hysterical Society

[-- 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 --]

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

* [TUHS] Re: forgotten versions
  2022-06-19  9:23               ` arnold
@ 2022-06-19 11:37                 ` Matthias Bruestle
  0 siblings, 0 replies; 52+ messages in thread
From: Matthias Bruestle @ 2022-06-19 11:37 UTC (permalink / raw)
  To: tuhs

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

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

* [TUHS] Re: forgotten versions
  2022-06-19  9:19             ` Angelo Papenhoff
@ 2022-06-19  9:23               ` arnold
  2022-06-19 11:37                 ` Matthias Bruestle
  0 siblings, 1 reply; 52+ messages in thread
From: arnold @ 2022-06-19  9:23 UTC (permalink / raw)
  To: arnold, aap; +Cc: tuhs

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

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

* [TUHS] Re: forgotten versions
  2022-06-19  9:14           ` arnold
@ 2022-06-19  9:19             ` Angelo Papenhoff
  2022-06-19  9:23               ` arnold
  0 siblings, 1 reply; 52+ messages in thread
From: Angelo Papenhoff @ 2022-06-19  9:19 UTC (permalink / raw)
  To: arnold; +Cc: tuhs

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

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

* [TUHS] Re: forgotten versions
  2022-06-19  9:02         ` Angelo Papenhoff
@ 2022-06-19  9:14           ` arnold
  2022-06-19  9:19             ` Angelo Papenhoff
  0 siblings, 1 reply; 52+ messages in thread
From: arnold @ 2022-06-19  9:14 UTC (permalink / raw)
  To: tuhs, aap

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

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

* [TUHS] Re: forgotten versions
  2022-06-19  8:53       ` Rob Pike
@ 2022-06-19  9:02         ` Angelo Papenhoff
  2022-06-19  9:14           ` arnold
  2022-06-19 14:47         ` Kenneth Goodwin
  1 sibling, 1 reply; 52+ messages in thread
From: Angelo Papenhoff @ 2022-06-19  9:02 UTC (permalink / raw)
  To: tuhs

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

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

* [TUHS] Re: forgotten versions
  2022-06-19  8:17     ` Angelo Papenhoff
@ 2022-06-19  8:53       ` Rob Pike
  2022-06-19  9:02         ` Angelo Papenhoff
  2022-06-19 14:47         ` Kenneth Goodwin
  0 siblings, 2 replies; 52+ messages in thread
From: Rob Pike @ 2022-06-19  8:53 UTC (permalink / raw)
  To: Angelo Papenhoff; +Cc: The Eunuchs Hysterical Society

[-- 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 --]

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

* [TUHS] Re: forgotten versions
  2022-06-19  7:50   ` Rob Pike
@ 2022-06-19  8:17     ` Angelo Papenhoff
  2022-06-19  8:53       ` Rob Pike
  0 siblings, 1 reply; 52+ messages in thread
From: Angelo Papenhoff @ 2022-06-19  8:17 UTC (permalink / raw)
  To: tuhs

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

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

* [TUHS] Re: forgotten versions
  2022-06-18  7:05 ` Angelo Papenhoff
@ 2022-06-19  7:50   ` Rob Pike
  2022-06-19  8:17     ` Angelo Papenhoff
  0 siblings, 1 reply; 52+ messages in thread
From: Rob Pike @ 2022-06-19  7:50 UTC (permalink / raw)
  To: Angelo Papenhoff; +Cc: The Eunuchs Hysterical Society

[-- 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 --]

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

* [TUHS] Re: forgotten versions
@ 2022-06-18 19:55 Paul Ruizendaal
  0 siblings, 0 replies; 52+ messages in thread
From: Paul Ruizendaal @ 2022-06-18 19:55 UTC (permalink / raw)
  To: tuhs


For those interested in a quick feel for V8 and early SysV, I recommend the excellent unix50 stuff:

SSH to unix50: "ssh unix50@unix50.org”

Password is “unix50”

You end up in a menu with:

SDF Public Access UNIX System presents ...

   /~/~/~/~/~/~/~/~/~/~/~/~/~/~/~/~/~/~/~/~/~/~/~/~/~/~/~/
   /~/~ H Y S T E R I C A L ~ U N I X ~ S Y S T E M S ~/~/
   /~/~/~/~/~/~/~/~/~/~/~/~/~/~/~/~/~/~/~/~/~/~/~/~/~/~/~/

    [a]  UNICS (Version Zero)   PDP-7       Summer   1969
    [b]  First Edition UNIX     PDP-11/20   November 1971
    [c]  Fifth Edition UNIX     PDP-11/40   June     1974
    [d]  Sixth Edition UNIX     PDP-11/45   May      1975
    [e]  Seventh Edition UNIX   PDP-11/70   January  1979
    [f]  Research UNIX 8        VAX-11/750           1984
    [g]  AT&T UNIX System III   PDP-11/70   Fall     1982
    [h]  AT&T UNIX System V     PDP-11/70            1983
    [i]  AT&T UNIX System V     3b2/400              1984
    [j]  4.3 BSD                MicroVAX    June     1986
    [k]  2.11 BSD               PDP-11/70   January  1992
    [w]  What's running now?
    [q]  QUIT (and run away in fear!)

    User contributed tutorials are at https://sdf.org/?tutorials/unix50th
    Want persistent images? networking? more ttys? Join https://sdf.org

Don’t to exit from a run, press Ctrl-E to return to sims, type 'exit', type ‘q'

I just tried V8 and it still works, although the boot log suggests that an image reset may be in order.

Many, many thanks to whoever is maintaining this!



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

* [TUHS] Re: forgotten versions
  2022-06-16 23:06 [TUHS] " Rob Pike
                   ` (3 preceding siblings ...)
  2022-06-17 10:52 ` arnold
@ 2022-06-18  7:05 ` Angelo Papenhoff
  2022-06-19  7:50   ` Rob Pike
  4 siblings, 1 reply; 52+ messages in thread
From: Angelo Papenhoff @ 2022-06-18  7:05 UTC (permalink / raw)
  To: tuhs

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

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

* [TUHS] Re: forgotten versions
@ 2022-06-17 14:50 Paul Ruizendaal
  0 siblings, 0 replies; 52+ messages in thread
From: Paul Ruizendaal @ 2022-06-17 14:50 UTC (permalink / raw)
  To: tuhs


Wholeheartedly agree with the observations on forgotten versions, lack of source and a smaller pool of people back in the day.

It is not just the Research versions, also the internal AT&T versions and the base System V versions get little attention. Same reasons I think.

Luckily, these days the sources are available (although in the case of SysV of unclear legal status).

Part of the problem I think is that it is not well known what innovations are in each version. About 2 years ago I did a lot of spelunking through the V8 source and with the help of this list could come up with a list of highlights for V8 (text is now on the TUHS V8 source web page).

Never had the time to do that for V9. I think it was mentioned that it had a new filesystem with a bitmap free list. Also, it seems to have a lot of cleaned-up implementations of things that were new and rough in V8.

No clue what was new in V10.

Similar with Unix 3, Unix 4 and Unix 5. I’m thrilled that the docs for Unix 4 showed up recently. In these doc’s there is no material on IPC. From this I think that the IPC primitives from CB-Unix did not get merged in Unix 4, but only in Unix 5 (in a reworked form).

Personally, I’m still working (off and on) on recreating the Reiser demand paging system. To keep it interesting I’ve now got Sys III running on a small RISC-V board, and when I find another time slot I’ll try to add Reiser paging to it.

So the forgotten versions are only mostly forgotten, not totally forgotten :^)


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

* [TUHS] Re: forgotten versions
  2022-06-16 23:06 [TUHS] " Rob Pike
                   ` (2 preceding siblings ...)
  2022-06-17  7:20 ` Diomidis Spinellis
@ 2022-06-17 10:52 ` arnold
  2022-06-18  7:05 ` Angelo Papenhoff
  4 siblings, 0 replies; 52+ messages in thread
From: arnold @ 2022-06-17 10:52 UTC (permalink / raw)
  To: tuhs, robpike

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

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

* [TUHS] Re: forgotten versions
  2022-06-17  7:20 ` Diomidis Spinellis
  2022-06-17  7:33   ` Rob Pike
@ 2022-06-17  8:34   ` arnold
  1 sibling, 0 replies; 52+ messages in thread
From: arnold @ 2022-06-17  8:34 UTC (permalink / raw)
  To: tuhs, robpike, dds

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. 

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

* [TUHS] Re: forgotten versions
  2022-06-17  7:20 ` Diomidis Spinellis
@ 2022-06-17  7:33   ` Rob Pike
  2022-06-17  8:34   ` arnold
  1 sibling, 0 replies; 52+ messages in thread
From: Rob Pike @ 2022-06-17  7:33 UTC (permalink / raw)
  To: Diomidis Spinellis; +Cc: The Eunuchs Hysterical Society

[-- 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 --]

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

* [TUHS] Re: forgotten versions
  2022-06-16 23:06 [TUHS] " Rob Pike
  2022-06-16 23:17 ` [TUHS] " Earl Baugh
  2022-06-16 23:18 ` George Michaelson
@ 2022-06-17  7:20 ` Diomidis Spinellis
  2022-06-17  7:33   ` Rob Pike
  2022-06-17  8:34   ` arnold
  2022-06-17 10:52 ` arnold
  2022-06-18  7:05 ` Angelo Papenhoff
  4 siblings, 2 replies; 52+ messages in thread
From: Diomidis Spinellis @ 2022-06-17  7:20 UTC (permalink / raw)
  To: Rob Pike, The Eunuchs Hysterical Society

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. 

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

* [TUHS] Re: forgotten versions
  2022-06-16 23:44   ` George Michaelson
@ 2022-06-17  0:10     ` Larry McVoy
  0 siblings, 0 replies; 52+ messages in thread
From: Larry McVoy @ 2022-06-17  0:10 UTC (permalink / raw)
  To: George Michaelson; +Cc: The Eunuchs Hysterical Society

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.

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

* [TUHS] Re: forgotten versions
  2022-06-16 23:18 ` George Michaelson
@ 2022-06-16 23:44   ` George Michaelson
  2022-06-17  0:10     ` Larry McVoy
  0 siblings, 1 reply; 52+ messages in thread
From: George Michaelson @ 2022-06-16 23:44 UTC (permalink / raw)
  To: Rob Pike; +Cc: The Eunuchs Hysterical Society

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

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

* [TUHS] Re: forgotten versions
  2022-06-16 23:06 [TUHS] " Rob Pike
  2022-06-16 23:17 ` [TUHS] " Earl Baugh
@ 2022-06-16 23:18 ` George Michaelson
  2022-06-16 23:44   ` George Michaelson
  2022-06-17  7:20 ` Diomidis Spinellis
                   ` (2 subsequent siblings)
  4 siblings, 1 reply; 52+ messages in thread
From: George Michaelson @ 2022-06-16 23:18 UTC (permalink / raw)
  To: Rob Pike; +Cc: The Eunuchs Hysterical Society

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
>

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

* [TUHS] Re: forgotten versions
  2022-06-16 23:06 [TUHS] " Rob Pike
@ 2022-06-16 23:17 ` Earl Baugh
  2022-06-16 23:18 ` George Michaelson
                   ` (3 subsequent siblings)
  4 siblings, 0 replies; 52+ messages in thread
From: Earl Baugh @ 2022-06-16 23:17 UTC (permalink / raw)
  To: Rob Pike; +Cc: The Eunuchs Hysterical Society

[-- 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 --]

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

end of thread, other threads:[~2022-06-27  0:59 UTC | newest]

Thread overview: 52+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-06-18  0:35 [TUHS] Re: forgotten versions Douglas McIlroy
2022-06-18  5:00 ` Kevin Bowling
2022-06-18  5:13   ` Adam Thornton
2022-06-18 16:58     ` Clem Cole
2022-06-18 17:18       ` Warner Losh
2022-06-18 17:57         ` Clem Cole
2022-06-19 20:46   ` [TUHS] RFS (was Re: Re: forgotten versions) Derek Fawcus
2022-06-19 23:07     ` [TUHS] " Larry McVoy
2022-06-19 23:19       ` Brad Spencer
2022-06-20  5:03         ` Arno Griffioen via TUHS
2022-06-20  6:53           ` Theodore Ts'o
  -- strict thread matches above, loose matches on Subject: below --
2022-06-24  6:47 [TUHS] Re: forgotten versions Paul Ruizendaal
2022-06-25 19:16 ` Anthony Martin
2022-06-25 20:45   ` Paul Ruizendaal
2022-06-27  0:57     ` Kevin Bowling
2022-06-23  2:18 Noel Chiappa
2022-06-22 12:06 Noel Chiappa
2022-06-23  0:02 ` Dan Cross
2022-06-18 19:55 Paul Ruizendaal
2022-06-17 14:50 Paul Ruizendaal
2022-06-16 23:06 [TUHS] " Rob Pike
2022-06-16 23:17 ` [TUHS] " Earl Baugh
2022-06-16 23:18 ` George Michaelson
2022-06-16 23:44   ` George Michaelson
2022-06-17  0:10     ` Larry McVoy
2022-06-17  7:20 ` Diomidis Spinellis
2022-06-17  7:33   ` Rob Pike
2022-06-17  8:34   ` arnold
2022-06-17 10:52 ` arnold
2022-06-18  7:05 ` Angelo Papenhoff
2022-06-19  7:50   ` Rob Pike
2022-06-19  8:17     ` Angelo Papenhoff
2022-06-19  8:53       ` Rob Pike
2022-06-19  9:02         ` Angelo Papenhoff
2022-06-19  9:14           ` arnold
2022-06-19  9:19             ` Angelo Papenhoff
2022-06-19  9:23               ` arnold
2022-06-19 11:37                 ` Matthias Bruestle
2022-06-19 14:47         ` Kenneth Goodwin
2022-06-19 16:27           ` Al Kossow
2022-06-19 18:32           ` Theodore Ts'o
2022-06-19 18:38             ` Dan Cross
2022-06-21 23:56               ` Jacob Moody
2022-06-22  0:13                 ` Larry McVoy
2022-06-22  0:48                   ` Rob Pike
2022-06-22  1:55                     ` George Michaelson
2022-06-22  2:10                       ` Bakul Shah
2022-06-22  2:14                       ` Jon Steinhart
2022-06-22  2:19                         ` Andrew Hume
2022-06-22  2:58                           ` Rob Pike
2022-06-22  3:09                             ` George Michaelson
2022-06-22  2:16                   ` Andrew Hume
2022-06-22  2:55                   ` Brad Spencer

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).