[TUHS] Re: forgotten versions

[TUHS] Re: forgotten versions

[Douglas McIlroy]

> 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

[TUHS] Re: forgotten versions

[Kevin Bowling]

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

[TUHS] Re: forgotten versions

[Adam Thornton]

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

[TUHS] Re: forgotten versions

[Clem Cole]

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

[TUHS] Re: forgotten versions

[Warner Losh]

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

[TUHS] Re: forgotten versions

[Clem Cole]

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

[TUHS] RFS (was Re: Re: forgotten versions)

[Derek Fawcus]

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

[TUHS] Re: RFS (was Re: Re: forgotten versions)

[Larry McVoy]

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.

[TUHS] Re: RFS (was Re: Re: forgotten versions)

[Brad Spencer]

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

[TUHS] Re: RFS (was Re: Re: forgotten versions)

[Arno Griffioen via 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.

[TUHS] Re: RFS (was Re: Re: forgotten versions)

[Theodore Ts'o]

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

[TUHS] Re: RFS (was Re: Re: forgotten versions)

[Derek Fawcus]

On Mon, Jun 20, 2022 at 02:28:06PM +0200, Paul Ruizendaal via TUHS wrote:
> 
> > Peter, being a self-described fan of cheap hacks, also wasn't
> > inclined to spend much time thinking about general abstractions;
> > in effect he just turned various existing kernel subroutines
> > (when applied to a network file system) into RPCs.  The
> > structure of the file system switch was rather UNIX-specific,
> > reflecting that.
> 
> Yes, well put. I’ve back ported his filesystem switch to V6/V7 and it is very light touch: on the PDP11 it added only some 500 bytes of kernel code (after some refactoring).
> 
> With hindsight it seems such a logical idea, certainly in a context where the labs were experimenting with remote system calls in the mid 70’s (Heinz Lycklama's work on satellite Unix) and early 80’s (Gottfried Luderer et al. on distributed Unix — another forgotten version). It is such a powerful abstraction, but apparently very elusive to invent.

Interesting, given the earlier mention of SMB.  As I recall, the MS-DOS Redirector interface is sort of at a similar level, but probably a lot more messy in terms of how the internal 'interfaces' are exposed.

That was in DOS 3.0, which according to Wikipedia was released in April '85, with 8th edition being around Feb '85, I guess they may have been done in parallel?

DF

[TUHS] Re: RFS (was Re: Re: forgotten versions)

[Paul Ruizendaal via TUHS]

> I don't know the exact history of RFS a la System V, but I
> don't think it was Peter Weinberger's stuff, and it certainly
> wasn't his code.

Peter’s code is available in the V8 and V9 trees on TUHS.

The Sys V repositories on Github appear to include RFS code in all of R3.0, R3.1 and R3.2.

At first glance, it seems quite different from the V8/V9 code.

> Peter, being a self-described fan of cheap hacks, also wasn't
> inclined to spend much time thinking about general abstractions;
> in effect he just turned various existing kernel subroutines
> (when applied to a network file system) into RPCs.  The
> structure of the file system switch was rather UNIX-specific,
> reflecting that.

Yes, well put. I’ve back ported his filesystem switch to V6/V7 and it is very light touch: on the PDP11 it added only some 500 bytes of kernel code (after some refactoring).

With hindsight it seems such a logical idea, certainly in a context where the labs were experimenting with remote system calls in the mid 70’s (Heinz Lycklama's work on satellite Unix) and early 80’s (Gottfried Luderer et al. on distributed Unix — another forgotten version). It is such a powerful abstraction, but apparently very elusive to invent.

Paul

[TUHS] Re: RFS (was Re: Re: forgotten versions)

[arnold]

RFS was not Peter's code. It was stateful, which had advantages
and disadvantages.  And, as someone else mentioned, if two systems
were binary compatible, remote device access worked, including ioctls.

IIRC Steve Rago ported Peter's code to System V Release 4,
and publilshed a paper about it, but I don't think the code ever
escaped AT&T.

System V Release 4 sorta overdid the special file system thing;
as I recall /dev/fd was done as a file system!

FWIW,

Arnold

norman@oclsc.org (Norman Wilson) wrote:

> I don't know the exact history of RFS a la System V, but I
> don't think it was Peter Weinberger's stuff, and it certainly
> wasn't his code.  Nor his name: he called his first version
> neta and his second netb (he knew it would be changing and
> allowed for it in the name from the start).
>
> I don't remember us ever calling it RFS, or even remote
> file systems, inside 1127; we called it network file systems
> (never NFS because the Sun stuff existed by then).
>
> For those who don't know it, Peter's goal was quite different
> from that of NFS.  The idea behind NFS seems always to have
> been to mount a remote file system as if it were local, with
> a base assumption early on that everything was within the
> same administrative domain so it was OK to make assumptions
> about userids matching up, and running code as super-user.
> Peter described his intent as `I want to be able to use your
> disks, and that's a lot simpler if I don't have to get you
> to add code to your kernel, or even to run a program as
> super-user.'  Hence the entirely-user-mode server program,
> which could use super-user privileges to afford access as
> any user if it had them, but also worked fine when run as
> an ordinary user with only that user's file permissions.
> We did in fact normally run it as super-user so each of
> our 15 or so VAXes could see the file system tree on each
> other, but we also occasionally did it otherwise.
>
> That was one reason device files worked as they did, accessing
> the device on the server end rather than acting like a local
> special file on the client: we didn't care about running
> diskless clients, but we did occasionally care about accessing
> a remote system's tape drive.
>
> Peter, being a self-described fan of cheap hacks, also wasn't
> inclined to spend much time thinking about general abstractions;
> in effect he just turned various existing kernel subroutines
> (when applied to a network file system) into RPCs.  The
> structure of the file system switch was rather UNIX-specific,
> reflecting that.
>
> That also means Peter's code was a bit ad-hoc and wonky in
> places.  He cleaned it up considerably between neta and netb,
> and I did further cleanup later.  I even had a go at a library
> to isolate the network protocol from the server proper, converted
> the netb server to use it, and made a few demo servers of my own
> like one to read and write raw FILES-11 file systems--useful for
> working with the console file system on the VAX 8800 series,
> which was exported to the host as a block device--and a daemon
> to allow a tar archive to be mounted as a read-only file system.
>
> In modern systems, you can do the same sort of things with FUSE,
> and set up the same I-want-to-use-your-disks (or I want to get
> at my own files from afar without privileges) scheme with sshfs.
> I would be very surprised to learn that either of those borrowed
> from their ancient cousins in Research UNIX; so far as I know
> they're independent inventions.  Either way I'm glad they exist.
>
> Norman Wilson
> Toronto ON

[TUHS] Re: RFS (was Re: Re: forgotten versions)

[George Michaelson]

I probably tend too much to the sociological more than technical in
this, but I do know we were very prejudiced against RFS. Very. We just
didn't like it.

Probably? This was some kind of bizarre chauvinism about NFS and Suns,
and access to the systems. But, my memory is that RFS as available to
us was not very easy to deploy, and may have been by default a "hard"
mount just at the point we were finding the benefit of having a "soft"
mount, in experience. Sure, a soft mount is significantly less
reliable, but with unreliable campus networks and systems, half a
usable system is better than none at all, and RFS tended to 'all or
nothing'

This was during the window where Sun was breaking the UDP checksum,
and also Ethernet backoff. So, its UDP checksum gaming meant it was
"faster" because it did less work, and its Ethernet backoff gaming
meant it was always first-to-fire in a contention event on the cable.
Two cheats! I don't think RFS did either, so there was also specious
benchmarking coming into effect,

-G

[TUHS] Re: RFS (was Re: Re: forgotten versions)

[Norman Wilson]

I don't know the exact history of RFS a la System V, but I
don't think it was Peter Weinberger's stuff, and it certainly
wasn't his code.  Nor his name: he called his first version
neta and his second netb (he knew it would be changing and
allowed for it in the name from the start).

I don't remember us ever calling it RFS, or even remote
file systems, inside 1127; we called it network file systems
(never NFS because the Sun stuff existed by then).

For those who don't know it, Peter's goal was quite different
from that of NFS.  The idea behind NFS seems always to have
been to mount a remote file system as if it were local, with
a base assumption early on that everything was within the
same administrative domain so it was OK to make assumptions
about userids matching up, and running code as super-user.
Peter described his intent as `I want to be able to use your
disks, and that's a lot simpler if I don't have to get you
to add code to your kernel, or even to run a program as
super-user.'  Hence the entirely-user-mode server program,
which could use super-user privileges to afford access as
any user if it had them, but also worked fine when run as
an ordinary user with only that user's file permissions.
We did in fact normally run it as super-user so each of
our 15 or so VAXes could see the file system tree on each
other, but we also occasionally did it otherwise.

That was one reason device files worked as they did, accessing
the device on the server end rather than acting like a local
special file on the client: we didn't care about running
diskless clients, but we did occasionally care about accessing
a remote system's tape drive.

Peter, being a self-described fan of cheap hacks, also wasn't
inclined to spend much time thinking about general abstractions;
in effect he just turned various existing kernel subroutines
(when applied to a network file system) into RPCs.  The
structure of the file system switch was rather UNIX-specific,
reflecting that.

That also means Peter's code was a bit ad-hoc and wonky in
places.  He cleaned it up considerably between neta and netb,
and I did further cleanup later.  I even had a go at a library
to isolate the network protocol from the server proper, converted
the netb server to use it, and made a few demo servers of my own
like one to read and write raw FILES-11 file systems--useful for
working with the console file system on the VAX 8800 series,
which was exported to the host as a block device--and a daemon
to allow a tar archive to be mounted as a read-only file system.

In modern systems, you can do the same sort of things with FUSE,
and set up the same I-want-to-use-your-disks (or I want to get
at my own files from afar without privileges) scheme with sshfs.
I would be very surprised to learn that either of those borrowed
from their ancient cousins in Research UNIX; so far as I know
they're independent inventions.  Either way I'm glad they exist.

Norman Wilson
Toronto ON