The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: Rob Gingell via TUHS <tuhs@minnie.tuhs.org>
To: Paul Ruizendaal <pnr@planet.nl>,
	Anthony Martin <ality@pbrane.org>,
	TUHS main list <tuhs@minnie.tuhs.org>
Subject: Re: [TUHS] VFS prior to 1984
Date: Wed, 24 Jun 2020 17:56:58 -0700	[thread overview]
Message-ID: <57bb4779-66e3-6501-c19c-0bc2afb8fbd7@computer.org> (raw)
In-Reply-To: <17CD58F0-2474-4308-86BA-C8847D7ABA21@planet.nl>

On 6/24/2020 11:31 AM, Paul Ruizendaal wrote:
> I came across this 1979 paper by P.M. Lu from Bell Labs Naperville
> https://ieeexplore.ieee.org/document/762533
> 
> The abstract says:
> 
> "RIDE (Resource-Sharing in a Distributed Environment) ...
RIDE seems very reminiscent of the RSEXEC (Resource Sharing EXEC) done 
on TENEX earlier in the 1970s. The implementation of RSEXEC involved 
encapsulation of a process fork by its parent rather than an 
object-oriented abstraction inserted behind an existing interface like 
VFS is. Both are functionally transparent to their users but are kind of 
going in opposite directions in implementation.

As with other mechanisms that have been referenced in this thread, these 
illustrate the claim that "all problems in computer science can be 
solved by [adding] another layer of indirection". I don't know that 
that's absolutely true but I've certainly applied it a lot, and like a 
lot of things, excessive application can create more problems.

(I never knew who was the first to utter the claim as I've heard it said 
by lots of people. However a quick check shows an attribution to David 
Wheeler in the form of the "Fundamental theorem of software engineering".)

https://en.wikipedia.org/wiki/Fundamental_theorem_of_software_engineering

RSEXEC was a pretty remarkable facility in action. It (approximately) 
was like having a command interpreter for the aggregated TENEX resources 
of the ARPAnet. It was at least partly intended to serve users of TIPs 
(the terminal interface processors used to access hosts) by letting them 
treat all TENEXes as a single resource and not worry about which one 
they got hosted onto "this time" with respect to their files, 
applications, etc., and importantly also not worry about the where their 
collaborators were hosted at the moment.

A description of RSEXEC is at:

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.830.1403&rep=rep1&type=pdf

The encapsulation mechanism was JSYS Traps, JSYS being the system call 
instruction on PDP-10s modified to run TENEX. A description of that is at:

https://archive.org/details/bitsavers_bbntenexTh_1137399

In it's way, RSEXEC illustrated one characteristic of many excellent 
innovations in that when used as intended it was "deceptively 
unimpressive". As in: harder to demo.

NFS and other things share this trait, and indeed early trade show 
demonstrations of NFS were frustrating (in those days, the engineers did 
booth duty). At first, demos reduced to typing "ls". Which, 
unsurprisingly, produced a list of files. It's not until you know how it 
was done that it's impressive.

There can be a real utilitarian pleasure in things that, when shown to 
others, produce a "yeah, wasn't it supposed to do that?" reaction. Part 
of that aesthetic appreciation for me originated with RSEXEC. Which 
brings me to VFS and such.

Earlier in this thread Clem Cole observed:

On 6/23/2020 8:12 AM, Clem Cole wrote:
> That said, and to give the NFS team_a huge amount of credit _(and great 
> applause), the VFS layer was better thought out than the FSS and in fact 
> made it possible to add a lot of different file systems into UNIX 
> later.  FSS was much more ad hoc.

I think VFS and several related things are another instance of that 
aesthetic appreciation. [I'm not claiming any credit, the initial NFS 
work was just finishing up as I arrived at Sun. That work like that 
happened there was part of why I wanted to be there and so I share 
Clem's appreciation for the team.]

NFS could have been implemented by sprinkling "if (network)" statements 
around a lot of code. A user or application program would not know any 
differently had it been done that way. (Though they would over time as 
the code became less maintainable with that implementation approach.)

That VFS has the qualities leading to Clem's applause is I think due to 
a confluence of several things that likely hadn't occurred previously 
and thus entitle it to claim "first" in response to the thread-starting 
question.

One of the motivators was the desire to have a network filing 
abstraction, and to replace "nd" for diskless workstations among other 
things. (That took a while, "nd" really hung on for various reasons.) 
That's occurring in an environment of heterogeneity and "open systems" 
thinking (which is a different thing from "open source"), and the desire 
to be more "of the network" in the product offerings.

There was kind of a group-innate understanding that to be successful in 
introducing these capabilities that they had to occur largely "behind" 
the extant interfaces used by the nascent UNIX application market. To 
some extent Sun's market success was based on being deliberately "more 
vanilla than thou" with respect to APIs. The variations already extant 
were a market-fragmenting influence and thus didn't need an additional 
player doing more of it.

To be "of the network" made NFS a "file system for the Network (that 
happens to look like UNIX)". The similarity and the known semantic 
differences lead some to look at it as "it failed to do UNIX" but it's 
not. The intent was "do the network, the network is NOT 'a' computer 
(irony alert), the fallacies of networking apply and we resolve the 
irreconcilable in favor of the network".

(An intangible factor relates to the group that Sun formed, talented 
engineers, strikingly different people who shared good taste in design 
and the desire to do the work to find the "simple" in a problem. A 
different group of people with the same problem set wouldn't have 
automatically gotten the same or even similar answer, sometimes it's 
just in the air. Of course, a different group might have made an even 
better answer, "innovation happens elsewhere" is more true than the 
earlier-referenced layer of indirection principle.)

Sometimes (mostly even), good taste is expressed in framing the problem 
appropriately. The "N" in NFS is deliberately not a "D". That's obvious 
from the resulting definition but earlier in the effort it was a choice. 
The intended distinction was that we weren't doing operating system work 
in order to transcend the network by submerging it in the abstractions 
of an OS. Rather, we wanted to build a network environment populated by 
systems which were of a piece with it. While not codified until much 
later, Deutsch's "Fallacies of Networking" were the controlling notions 
in a lot of thinking and influenced things that at first wouldn't seem 
to have anything to do with networking (e.g., msync()).

However, it would be wrong to say we realized enough at the time to 
*know* that our goal was to build a system defined by a metric that it 
avoid all of the networking fallacies. We knew some of it, were 
incrementally hunting it, instincts were oriented that way. Had we been 
a research organization that might have given rise to an initiative that 
was more clearly defined. (But, I think we did a reasonable job of 
pursuing the ideas while making products that people who weren't 
thinking of such things bought. As it happens, a lot of FORTRAN users as 
has been noted here before.

Regarding the earlier irony alert: to the extent that the evocative 
marketing slogan of "The Network is the Computer" had any technical 
underpinnings, it was an expression of this aim to design in favor of 
the network. It isn't really irony so much as consequence.

The real irony is that when the slogan was first trotted out almost all 
of the company but particularly engineering barfed at it. I recall the 
marketing person(s) (individual contributors, not the executives later 
claiming credit) trying to push it receiving huge rations of abuse. But 
it stuck. And we came around once we looked beyond its technical 
deficiency as a literal statement and saw it as evocative of what we had 
been doing. They knew us better than we did. And, independent of any 
technical matter, it worked really well. 'Find the simple" is a useful 
admonition for marketing as well as engineering.

  reply	other threads:[~2020-06-25  0:57 UTC|newest]

Thread overview: 65+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-23  9:09 Paul Ruizendaal
2020-06-23 14:01 ` Larry McVoy
2020-06-23 15:12   ` Clem Cole
2020-06-23 15:55     ` Rich Morin
2020-06-23 20:38     ` Rob Pike
2020-06-23 20:57       ` Larry McVoy
2020-06-24  5:14       ` arnold
2020-06-24 21:08         ` Dave Horsfall
2020-06-24 19:30       ` Clem Cole
2020-06-24 19:36     ` Larry McVoy
2020-06-25  6:52       ` Rob Gingell
2020-07-05  0:05       ` Dave Horsfall
2020-07-05  0:16         ` Larry McVoy
2020-07-06  4:42           ` Dave Horsfall
2020-07-06 16:51           ` Chris Torek
2020-07-06 23:23             ` [TUHS] ECC memory John Gilmore
2020-07-07  1:07             ` [TUHS] VFS prior to 1984 Bakul Shah
2020-07-05  1:43         ` Clem Cole
2020-07-05 14:43           ` Larry McVoy
2020-07-05 18:40             ` Arthur Krewat
2020-07-05 20:08             ` Clem Cole
2020-07-05 20:42               ` John Cowan
2020-07-05 21:04                 ` Clem Cole
2020-07-05 21:14                   ` Dan Cross
2020-06-24 16:51 ` Anthony Martin
2020-06-24 17:31   ` Anthony Martin
2020-06-24 18:31   ` Paul Ruizendaal
2020-06-25  0:56     ` Rob Gingell via TUHS [this message]
2020-06-25  4:15       ` [TUHS] Oh, things were very different Rich Morin
2020-06-25 15:45         ` Lawrence Stewart
2020-06-25 16:24           ` Warner Losh
2020-06-25 17:57           ` Arthur Krewat
2020-06-25 20:22         ` Dave Horsfall
2020-06-25 20:42           ` Michael Kjörling
2020-06-25 20:49           ` Clem Cole
2020-06-26  0:48             ` Dave Horsfall
2020-06-24 19:05   ` [TUHS] VFS prior to 1984 Paul Ruizendaal
2020-06-24 20:27 ` Derek Fawcus
2020-06-24 21:33 ` Greg A. Woods
2020-06-25  0:45   ` Adam Thornton
2020-06-25 19:40     ` Greg A. Woods
2020-06-23 22:17 Norman Wilson
2020-06-23 22:24 ` Dave Horsfall
2020-06-24  4:09   ` Warner Losh
2020-06-24  5:10     ` Dave Horsfall
2020-06-24  5:33       ` Bakul Shah
2020-06-24  9:10         ` Andrew Warkentin
2020-06-24 14:31 Noel Chiappa
2020-06-24 15:21 ` Clem Cole
2020-06-24 17:51 Noel Chiappa
2020-06-24 18:13 ` Richard Salz
2020-06-24 18:46   ` Lars Brinkhoff
2020-06-24 18:31 Norman Wilson
2020-06-25  6:22 ` arnold
2020-06-25 19:31 Noel Chiappa
2020-06-25 20:23 Noel Chiappa
2020-06-25 20:25 Noel Chiappa
2020-06-26  5:49 ` Lars Brinkhoff
2020-06-26  8:34   ` Dave Horsfall
2020-06-26 11:13     ` arnold
2020-06-29  9:11 Paul Ruizendaal
2020-06-29 14:45 ` Larry McVoy
2020-06-29 14:53   ` Paul Ruizendaal
2020-06-29 15:14     ` Larry McVoy
2020-06-29 16:34 ` Heinz Lycklama

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=57bb4779-66e3-6501-c19c-0bc2afb8fbd7@computer.org \
    --to=tuhs@minnie.tuhs.org \
    --cc=ality@pbrane.org \
    --cc=gingell@computer.org \
    --cc=pnr@planet.nl \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).