From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 28726 invoked from network); 25 Jun 2020 00:57:47 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 25 Jun 2020 00:57:47 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id 1CD9C9459D; Thu, 25 Jun 2020 10:57:46 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id BD70A9459A; Thu, 25 Jun 2020 10:57:13 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="ifjnsZD+"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id 8AE299459A; Thu, 25 Jun 2020 10:57:06 +1000 (AEST) Received: from mail-pl1-f171.google.com (mail-pl1-f171.google.com [209.85.214.171]) by minnie.tuhs.org (Postfix) with ESMTPS id 16C9E94599 for ; Thu, 25 Jun 2020 10:57:03 +1000 (AEST) Received: by mail-pl1-f171.google.com with SMTP id n2so1963566pld.13 for ; Wed, 24 Jun 2020 17:57:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:reply-to:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=z71L5AqxBWE47LGtMwSTHf/xmxjgDmvIwzu/fEnioZQ=; b=ifjnsZD+cLubvWIOCcvrvWlPp0JlqHS5d4Tk4NosfdovMcdwo0N5F0a1QuKalGGkS+ 1Ptj17/53Y2wexaG7TRXlFmlOIJV+N+c2v8AsaOm0o9cki0oJYVBIWFExgGLQaR1ImWz XvzMiubvlKv4/AjpIRZlTbHja0kko3jz0pyLLZIHoVj3w2CerOzFtZmYmdsBiWSuTdLF MOyTNSvyvJhcuw+FTWtx2YdeYfm7mdGawXgXhc5r30jWequsGHZMlKrhMGmfiVyGTJF+ NbEL3Vg21ef8Cu1aPyQCBj2DjcepfURQD5bICvViDzhgFT/M6xKxH6qzJwbM3Mta7prH XmRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:reply-to:subject:to:references:from :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=z71L5AqxBWE47LGtMwSTHf/xmxjgDmvIwzu/fEnioZQ=; b=lmKaLGL18MbJVHPVQmW7i9daEmrU5N591ZasQVKegevr6so90AD4uQ20qK6Zpvq+9P J/8GyXlGJPW6drOKaBMEQZVdsbhR7iczkayyJY4CbZNpbxeTuKrM6t27KJjGOupw66jn eCmh0Z3yvYoe45QIYzT8B/blyisjKcuDUXKYGCH8RkVDjROGjS6mBNdq++h8Daa5IFyz hj3wecLY+cy8VXpA6BEVOkyLtzO/bPYf7FYLMTx3d3omfjRG2e2pA1X7T5EldniCZRb6 lpdHcXuxm+vv8m4Nb1fzEAH+jc2w2lMfEA2/wHAd/UTl9SwliDsVxJTgvZ60wCfyrmDV QXlA== X-Gm-Message-State: AOAM532GYnaT5LtN+vnDhKuHcSwiJJw2VKAjgz/YM6JskI9YPYrR6bbk 7kWOoRHQaFClU4wX8HCn+xf/w39DASI= X-Google-Smtp-Source: ABdhPJw0ZZAiPLPOgKAliSUSEATUogrUczzENfOkOZ3fUgxFFCthwIGMep5oyzbiQ736bo6c6eXSzw== X-Received: by 2002:a17:90a:fc81:: with SMTP id ci1mr501979pjb.26.1593046621811; Wed, 24 Jun 2020 17:57:01 -0700 (PDT) Received: from [10.0.0.18] (c-98-210-178-152.hsd1.ca.comcast.net. [98.210.178.152]) by smtp.gmail.com with ESMTPSA id c2sm17516441pgk.77.2020.06.24.17.57.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 24 Jun 2020 17:57:00 -0700 (PDT) To: Paul Ruizendaal , Anthony Martin , TUHS main list References: <4FC7FA55-5035-41A2-B52F-AE26DC8BED2C@planet.nl> <20200624165107.GA5737@alice> <17CD58F0-2474-4308-86BA-C8847D7ABA21@planet.nl> Message-ID: <57bb4779-66e3-6501-c19c-0bc2afb8fbd7@computer.org> Date: Wed, 24 Jun 2020 17:56:58 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <17CD58F0-2474-4308-86BA-C8847D7ABA21@planet.nl> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [TUHS] VFS prior to 1984 X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Rob Gingell via TUHS Reply-To: gingell@computer.org Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" 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.