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_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FROM,HTML_MESSAGE,MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 6466 invoked from network); 17 Sep 2021 01:34:09 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 17 Sep 2021 01:34:09 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id A86889CAB7; Fri, 17 Sep 2021 11:34:08 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 77BA99CAB3; Fri, 17 Sep 2021 11:33:44 +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="kpnmmqQS"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id D4A619CAB3; Fri, 17 Sep 2021 11:33:40 +1000 (AEST) Received: from mail-ot1-f49.google.com (mail-ot1-f49.google.com [209.85.210.49]) by minnie.tuhs.org (Postfix) with ESMTPS id B5A569CAB2 for ; Fri, 17 Sep 2021 11:33:39 +1000 (AEST) Received: by mail-ot1-f49.google.com with SMTP id l16-20020a9d6a90000000b0053b71f7dc83so10785308otq.7 for ; Thu, 16 Sep 2021 18:33:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ObIawhmjw4mQ4EvsJMEqGGTi7NFArLKoIhyF9jHYIO8=; b=kpnmmqQS7lYx/YU5oJKbBE1D4s1rsW+LEEpaxoWM1ikg+uf14gmHNBvqUYxUJ5Rtj4 WQppS7k5CY1OPfKZNfFLK5rvdyxqGTpC4fpVXkxs1+ab5RTEEDjzKXQVJxx+pzZHNW4Q 2PBPTnCqrwplmQ9Gx8c5qL9Vh+Ox0QFWFI8Co/jy9O0Q9aEyIYlBMX7iW/Q5yg/qBwG/ xt3WPPDKT8DSyF+R2h622/mt31hA5i84ub7fdcmmvngxZnBd1v1evfx2Ici5la7PGEDZ oSAIw91mgO/Z13vG59nRfF73f0J8tP/iC+nA+TeBZ/nzFsXe+M7VL4Wd1t36rJRSIsr4 ie4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ObIawhmjw4mQ4EvsJMEqGGTi7NFArLKoIhyF9jHYIO8=; b=W80jBNhxJUwLIsjzLk6xg3a5LehS8NgGdKvQYppz2ibvSl8SDbmFQiVhSPWNFkb2en ydpH8pL7Oa5p4htlF1sidceL6fzAfO3P0lW68tW/4YZ/uH4IuLQwaEHfNPv8JaieQcyu x2xTYPijYVghwgh8NRX+sa0IbMb0bQRpUnmR6CDoTy7xmukleHz9eMgBJ79A6HLrb7m1 nzIVPScIN2/YVy6wAEjvL1zjO+PUxYHycf6Ts5J8F/D8E8b1EMTXIfFKgBv0SWXBJd4N Sc74QjfdiPM29jRrxmvdFmR3TuX6NEgMkXSgDM5j9hJS2B80KLNahO33FdGKNUxQsIpE mjEw== X-Gm-Message-State: AOAM530Pan0/nuHfJ59JvDmWXKp2GRu/EZzG45yGzsWOd7GhaCVW5j0S /3lbdVDRe2aFPm3bCnv/DgeKolKXpauQ4wb4qF+rr5ob X-Google-Smtp-Source: ABdhPJwSvW/EAXOt91fjGtxlV1XsMgV0s369QR4QEAfQkY7UsfnLGZAHymPW9Z01E977w/thpBS2VmXFiGx8TBvdwsE= X-Received: by 2002:a9d:4e04:: with SMTP id p4mr7348935otf.375.1631842418787; Thu, 16 Sep 2021 18:33:38 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dan Cross Date: Thu, 16 Sep 2021 21:33:02 -0400 Message-ID: To: "Theodore Ts'o" Content-Type: multipart/alternative; boundary="000000000000b389e605cc26eb6f" Subject: Re: [TUHS] ATC/OSDI'21 joint keynote: It's Time for Operating Systems to Rediscover Hardware (Timothy Roscoe) 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: , Cc: TUHS main list , Douglas McIlroy Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" --000000000000b389e605cc26eb6f Content-Type: text/plain; charset="UTF-8" On Thu, Sep 16, 2021 at 8:34 PM Theodore Ts'o wrote: > On Thu, Sep 16, 2021 at 03:27:17PM -0400, Dan Cross wrote: > > > > > > I'm really not convinced trying to build distributed computing into > > > the OS ala Plan 9 is viable. > > > > It seems like plan9 itself is an existence proof that this is possible. > > What it did not present was an existence proof of its scalability and it > > wasn't successful commercially. It probably bears mentioning that that > > wasn't really the point of plan9, though; it was a research system. > > I should have been more clear. I'm not realliy convinced that > building distributed computing into the OS ala Plan 9 is viable from > the perspective of commercial success. Of course, Plan 9 did it; but > it did it as a research system. > > The problem is that if a particular company is convinced that they > want to use Yellow Pages as their directory service --- or maybe X.509 > certificates as their authentication system, or maybe Apollo RPC is > the only RPC system for a particularly opinionated site administrator > --- and these prior biases disagree with the choices made by a > particular OS that had distributed computing services built in as a > core part of its functionality, that might be a reason for a > particular customer *not* to deploy a particular distributed OS. > Ah, I take your meaning. Yes, I can see that being a problem. But we've had similar problems before: "we only buy IBM", or, "does it integrate into our VAXcluster?" Put another way, _every_ system has opinions about how to do things. I suppose the distinction you're making is that we can paper over so many of those by building abstractions on top of the "node" OS. But the node OS is already forcing a shape onto our solutions. Folks working on the Go runtime have told me painful stories about detection of blocking system calls using timers and signals: wouldn't it be easier if the system provided real asynchronous abstractions? But the system call model in Unix/Linux/plan9 etc is highly synchronous. If `open` takes a while for whatever reason (say, blocking on reading directory entries looking up a name?) there's no async IO interface for that, hence shenanigans. But that's what the local node gives me; c'est la vie. Of course, this doesn't matter if you don't care if anyone uses it > after the paper(s) about said OS has been published. > I suspect most researchers don't expect the actual research artifacts to make it directly into products, but that the ideas will hopefully have some impact. Interestingly, Unix seems to have been an exception to this in that Unix itself did make it into industry. > Plan 9, as just one example, asked a lot of questions about the issues you > > mentioned above 30 years ago. They came up with _a_ set of answers; that > > set did evolve over time as things progressed. That doesn't mean that > those > > questions were resolved definitively, just that there was a group of > > researchers who came up with an approach to them that worked for that > group. > > There's nothing stopping researchers from creating other research OS's > that try to answer that question. True, but they aren't. I suspect there are a number of confounding factors at play here; certainly, the breadth and size of the standards they have to implement is an issue, but so is lack of documentation. No one is seriously looking at new system architectures, though. > However, creating an entire new > local node OS from scratch is challenging[1], and then if you then > have to recreate new versions of Kerberos, an LDAP directory server, > etc., so they all of these functions can be tightly integrated into a > single distributed OS ala Plan 9, that seems to be a huge amount of > work, requiring a lot of graduate students to pull off. > > [1] http://doc.cat-v.org/bell_labs/utah2000/ (Page 14, Standards) > Yup. That is the presentation I meant when I mentioned Rob Pike lamenting the situation 20 years ago in the previous message and earlier in the thread. An interesting thing here is that we assume that we have to redo _all_ of that, though. A lot of the software out there is just code that does something interesting, but actually touches the system in a pretty small way. gvisor is an interesting example of this; it provides something that looks an awful lot like Linux to an application, and a lot of stuff can run under it. But the number of system calls _it_ in turn makes to the underlying system is much smaller. > What's changed is that we now take for granted that Linux is there, and > > we've stopped asking questions about anything outside of that model. > > It's unclear to me that Linux is blamed as the reason why researchers > have stopped asking questions outside of that model. Why should Linux > have this effect when the presence of Unix didn't? > a) There's a lot more Linux in the world than there ever was Unix. b) There are more computers now than there were when Unix was popular. c) computers are significantly more complex now than they were when Unix was written. But to be clear, I don't think this trend started with Linux; I get the impression that by the 1980s, a lot of research focused on a Unix-like model to the exclusion of other architectures. The PDP-10 was basically dead by 1981, and we haven't seen a system like TOPS-20 since the 70s. Or is the argument that it's Linux's fault that Plan 9 has apparently > failed to compete with it in the marketplace of ideas? It's hard to make that argument when Linux borrowed so many of plan9's ideas: /proc, per-process namespaces, etc. > And arguably, > Plan 9 failed to make headway against Unix (and OSF/DCE, and Sun NFS, > etc.) in the early to mid 90's, which is well before Linux's became > popular, so that argument doesn't really make sense, either. > That wasn't the argument. There are a number of reasons why plan9 failed to achieve commercial success relative to Unix; most of them have little to do with technology. In many ways, AT&T strangled the baby by holding it too tightly to its chest, fearful of losing control the way they "lost" control of Unix (ironically, something that allowed Unix to flourish and become wildly successful). Incompatibility with the rest of the world was likely an issue, but inaccessibility and overly restrictive licensing in the early 90s practically made it a foregone conclusion. Also, it's a little bit of an aside, but I think we often undercount the impact of individual preference on systems. In so many ways, Linux succeeded because, simply put, people liked working on Linux more than they liked working on other systems. You've mentioned yourself that it was more fun to hack on Linux without having to appease some of the big personalities in the BSD world. - Dan C. --000000000000b389e605cc26eb6f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Sep 16, 2021 at 8:34 PM Theodore = Ts'o <tytso@mit.edu> wrote:<= br>
On Thu, Sep 16, 2021 at 03:27:17PM -0400, Dan Cross wrote:
> >
> > I'm really not convinced trying to build distributed computin= g into
> > the OS ala Plan 9 is viable.
>
> It seems like plan9 itself is an existence proof that this is possible= .
> What it did not present was an existence proof of its scalability and = it
> wasn't successful commercially. It probably bears mentioning that = that
> wasn't really the point of plan9, though; it was a research system= .

I should have been more clear.=C2=A0 I'm not realliy convinced that
building distributed computing into the OS ala Plan 9 is viable from
the perspective of commercial success.=C2=A0 Of course, Plan 9 did it; but<= br> it did it as a research system.

The problem is that if a particular company is convinced that they
want to use Yellow Pages as their directory service --- or maybe X.509
certificates as their authentication system, or maybe Apollo RPC is
the only RPC system for a particularly opinionated site administrator
--- and these prior biases disagree with the choices made by a
particular OS that had distributed computing services built in as a
core part of its functionality, that might be a reason for a
particular customer *not* to deploy a particular distributed OS.

Ah, I take your meaning. Yes, I can see that bein= g a problem. But we've had similar problems before: "we only buy I= BM", or, "does it integrate into our VAXcluster?" Put anothe= r way, _every_ system has opinions about how to do things. I suppose the di= stinction you're making is that we can paper over so many of those by b= uilding abstractions on top of the "node" OS. But the node OS is = already forcing a shape onto our solutions. Folks working on the Go runtime= have told me painful stories about detection of blocking system calls usin= g timers and signals: wouldn't it be easier if the system provided real= asynchronous abstractions? But the system call model in Unix/Linux/plan9 e= tc is highly synchronous. If `open` takes a while for whatever reason (say,= blocking on reading directory entries looking up a name?) there's no a= sync IO interface for that, hence shenanigans. But that's what the loca= l node gives me; c'est la vie.

Of course, this doesn't matter if you don't care if anyone uses it<= br> after the paper(s) about said OS has been published.
<= br>
I suspect most researchers don't expect the actual resear= ch artifacts to make it directly into products,=C2=A0but that the ideas wil= l hopefully have some impact. Interestingly, Unix seems to have been an exc= eption to this in that Unix itself did make it into industry.
> Plan 9, as just one example, asked a lot of questions about the issues= you
> mentioned above 30 years ago. They came up with _a_ set of answers; th= at
> set did evolve over time as things progressed. That doesn't mean t= hat those
> questions were resolved definitively, just that there was a group of > researchers who came up with an approach to them that worked for that = group.

There's nothing stopping researchers from creating other research OS= 9;s
that try to answer that question.

True, but= they aren't. I suspect there are a number of confounding factors at pl= ay here; certainly, the breadth and size of the standards they have to impl= ement is an issue, but so is lack of documentation. No one is seriously loo= king at new system architectures, though.
=C2=A0
However, creating an entire new
local node OS from scratch is challenging[1], and then if you then
have to recreate new versions of Kerberos, an LDAP directory server,
etc., so they all of these functions can be tightly integrated into a
single distributed OS ala Plan 9, that seems to be a huge amount of
work, requiring a lot of graduate students to pull off.

[1] http://doc.cat-v.org/bell_labs/utah2000/=C2=A0 =C2= =A0(Page 14, Standards)

Yup. That is th= e presentation I meant when I mentioned Rob Pike lamenting the situation 20= years ago in the previous message and earlier in the thread.
An interesting thing here is that we assume that we have to red= o _all_ of that, though. A lot of the software out there is just code that = does something interesting, but actually touches the system in a pretty sma= ll way. gvisor is an interesting example of this; it provides something tha= t looks an awful lot like Linux to an application, and a lot of stuff can r= un under it. But the number of system calls _it_ in turn makes to the under= lying system is much smaller.

> What's changed is that we now take for granted that Linux is there= , and
> we've stopped asking questions about anything outside of that mode= l.

It's unclear to me that Linux is blamed as the reason why researchers have stopped asking questions outside of that model.=C2=A0 Why should Linux=
have this effect when the presence of Unix didn't?

a) There's a lot more Linux in the world than there eve= r was Unix. b) There are more computers now than there were when Unix was p= opular. c) computers are significantly more complex now than they were when= Unix was written.

But to be clear, I don't th= ink this trend started with Linux; I get the impression that by the 1980s, = a lot of research focused on a Unix-like model to the exclusion of other ar= chitectures. The PDP-10 was basically dead by 1981, and we haven't seen= a system like TOPS-20 since the 70s.

Or is the argument that it's Linux's fault that Plan 9 has apparent= ly
failed to compete with it in the marketplace of ideas?
It's hard to make that argument when Linux borrowed so many= of plan9's ideas: /proc, per-process namespaces, etc.
=C2=A0=
And arguably,
Plan 9 failed to make headway against Unix (and OSF/DCE, and Sun NFS,
etc.) in the early to mid 90's, which is well before Linux's became=
popular, so that argument doesn't really make sense, either.

That wasn't the=C2=A0argument. There are a nu= mber of reasons why plan9 failed to achieve commercial success relative to = Unix; most of them have little to do with technology. In many ways,=C2=A0AT= &T strangled the baby by holding it too tightly to its chest,=C2=A0fear= ful of losing control the=C2=A0way they "lost" control of Unix (i= ronically, something that allowed=C2=A0Unix to flourish and become wildly s= uccessful). Incompatibility with the rest of the world was likely an issue,= but inaccessibility and overly restrictive licensing in the early 90s prac= tically made it a foregone conclusion.

Also, it= 9;s a little bit of an aside, but I think we often undercount the impact of= individual preference on systems. In so many ways, Linux succeeded because= , simply put, people liked working on Linux more than they liked working on= other systems. You've mentioned yourself that it was more fun to hack = on Linux without having to appease some of the big personalities in the BSD= world.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 - Dan C.
=

--000000000000b389e605cc26eb6f--