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 6412 invoked from network); 1 Sep 2021 21:59:59 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 1 Sep 2021 21:59:59 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id 0E9799D539; Thu, 2 Sep 2021 07:59:58 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id E36F89BA56; Thu, 2 Sep 2021 07:59:34 +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="SC6uaC85"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id 64F249BA56; Thu, 2 Sep 2021 07:59:33 +1000 (AEST) Received: from mail-ot1-f42.google.com (mail-ot1-f42.google.com [209.85.210.42]) by minnie.tuhs.org (Postfix) with ESMTPS id DB6DF9B9F9 for ; Thu, 2 Sep 2021 07:59:32 +1000 (AEST) Received: by mail-ot1-f42.google.com with SMTP id m7-20020a9d4c87000000b0051875f56b95so6194otf.6 for ; Wed, 01 Sep 2021 14:59:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=L6L15Tvp/s0oASjEfpW1e6qCo8MaM402UuZnYRrt92k=; b=SC6uaC853fJjUjfQ2tTU/SQiXXxYn2Ur9OnprHzW3tY8Td98oIT5KqNWPAJAsCvzF/ UD1mbF7ua3t3z43TuLYFXdUBm6nzTFVLGCjO//jvY4kmcLAdcX+xSM3TR/LoJ/SCwatT 20CDSOBnk7UxrwpevLByniEcqqAwCPO8taUFj0CUv/Z7JPBXg4SweFnstNdmBf5iStui 1D1esLBrxywfKHEixeiSSDfiMqad0/O5mTp1BBpxPJmWR8S7cHNigGZU0VeKOvTSWlsd o19BmbOC4vW/o5Yhz631h1JdbBkhNTeFcUzuYealsSYNB+egMEwIvWYwepYM7tLuHspb eoPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=L6L15Tvp/s0oASjEfpW1e6qCo8MaM402UuZnYRrt92k=; b=Errt4A/bt+hTwEBKzxWOLKhJ0JnKRwU6WNvzzNVDY+6y/GmYe3/0+fSIMGkMOoImoL Md+YLZJmUShLQmttFwaiSh0wNm6EBnhOZJh7yo0Nd8Qi/J1kyLvLqmFASmNBbdceRj5Z 8fSLz8mtKZUNjBbLb8MLuu57Fu2XGq2NmkZX6nCe026uEQ4R1jdOZECKDUBNELQVNGy0 S+8krls2EUQxsdEAILzNptzb5V4aMQvpoCYrPbwEQVB4YGoBSKqVGdGJTOFj6T98o/CJ e9flW8AsYjVUKPLgbYkQ6Kw5B/Hkn9I3NHipii+cvBdO49XrWypU7/kEFr1c3mg/D4P9 FUWg== X-Gm-Message-State: AOAM530f2XvoA0jA5DVTLv9j1eN9DuRx3rCb6G/HozEFK0RL3KeJHOrM XSK0Fc1srWwreWPGEnYsggRQISxzEB+j7HiPnq8SvjUWeTAgpg== X-Google-Smtp-Source: ABdhPJxEOYf8D12lDke5mHyhMHBmXJKfFL9yJpi5er1on/LGUsoUKNIEVvyVlCW1k4+oa9A1Rt1Pd25pXSRHcmPJKkI= X-Received: by 2002:a9d:5a8e:: with SMTP id w14mr1374886oth.65.1630533571921; Wed, 01 Sep 2021 14:59:31 -0700 (PDT) MIME-Version: 1.0 From: Dan Cross Date: Wed, 1 Sep 2021 17:58:56 -0400 Message-ID: To: TUHS main list Content-Type: multipart/alternative; boundary="0000000000005949f405caf62ec1" Subject: [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: , Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" --0000000000005949f405caf62ec1 Content-Type: text/plain; charset="UTF-8" One of the things I really appreciate about participating in this community and studying Unix history (and the history of other systems) is that it gives one firm intellectual ground from which to evaluate where one is going: without understanding where one is and where one has been, it's difficult to assert that one isn't going sideways or completely backwards. Maybe either of those outcomes is appropriate at times (paradigms shift; we make mistakes; etc) but generally we want to be moving mostly forward. The danger when immersing ourselves in history, where we must consider and appreciate the set of problems that created the evolutionary paths leading to the systems we are studying, is that our thinking can become calcified in assuming that those systems continue to meet the needs of the problems of today. It is therefore always important to reevaluate our base assumptions in light of either disconfirming evidence or (in our specific case) changing environments. To that end, I found Timothy Roscoe's (ETH) joint keynote address at ATC/OSDI'21 particularly compelling. He argues that what we consider the "operating system" is only controlling a fraction of a modern computer these days, and that in many ways our models for what we consider "the computer" are outdated and incomplete, resulting in systems that are artificially constrained, insecure, and with separate components that do not consider each other and therefore frequently conflict. Further, hardware is ossifying around the need to present a system interface that can be controlled by something like Linux (used as a proxy more generally for a Unix-like operating system), simultaneously broadening the divide and making it ever more entrenched. Another theme in the presentation is that, to the limited extent the broader systems research community is actually approaching OS topics at all, it is focusing almost exclusively on Linux in lieu of new, novel systems; where non-Linux systems are featured (something like 3 accepted papers between SOSP and OSDI in the last two years out of $n$), the described systems are largely Linux-like. Here the presentation reminded me of Rob Pike's "Systems Software Research is Irrelevant" talk (slides of which are available in various places, though I know of no recording of that talk). Roscoe's challenge is that all of this should be seen as both a challenge and an opportunity for new research into operating systems specifically: what would it look like to take a holistic approach towards the hardware when architecting a new system to drive all this hardware? We have new tools that can make this tractable, so why don't we do it? Part of it is bias, but part of it is that we've lost sight of the larger picture. My own question is, have we become entrenched in the world of systems that are "good enough"? Things he does NOT mention are system interfaces to userspace software; he doesn't seem to have any quibbles with, say, the Linux system call interface, the process model, etc. He's mostly talking about taking into account the hardware. Also, in fairness, his highlighting a "small" portion of the system and saying, "that's what the OS drives!" sort of reminds me of the US voter maps that show vast tracts of largely unpopulated land colored a certain shade as having voted for a particular candidate, without normalizing for population (land doesn't vote, people do, though in the US there is a relationship between how these things impact the overall election for, say, the presidency). I'm curious about other peoples' thoughts on the talk and the overall topic? https://www.youtube.com/watch?v=36myc8wQhLo - Dan C. --0000000000005949f405caf62ec1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
One of the things I really appreciate about participa= ting in this community and studying Unix history (and the history of other = systems) is that it gives one firm intellectual ground from which to evalua= te where one is going: without=C2=A0understanding where one is and where on= e has been, it's difficult to assert that one isn't going sideways = or completely backwards. Maybe either of those outcomes is appropriate at t= imes (paradigms shift; we make mistakes; etc) but generally we want to be m= oving mostly forward.

The danger when immersing ou= rselves in history, where we must consider and appreciate the set of proble= ms that created the evolutionary paths leading to the systems we are studyi= ng, is that our thinking can become calcified in assuming that those system= s continue to meet the needs of the problems of today. It is therefore alwa= ys important to reevaluate our base assumptions in light of either disconfi= rming evidence or (in our specific case) changing environments.
<= br>
To that end, I found Timothy Roscoe's (ETH) joint keynote= address at ATC/OSDI'21 particularly compelling. He argues that what we= consider the "operating system" is only controlling a fraction o= f a modern computer these days, and that in many ways our models for what w= e consider "the computer" are outdated and incomplete, resulting = in systems that are artificially constrained, insecure, and with separate c= omponents that do not consider each other and therefore frequently conflict= . Further, hardware is ossifying around the need to present a system interf= ace that can be controlled by something like Linux (used as a proxy more ge= nerally for a Unix-like operating system), simultaneously broadening the di= vide and making it ever more entrenched.

Another t= heme in the presentation is that, to the limited extent the=C2=A0broader sy= stems research community is actually approaching OS topics at all, it is fo= cusing almost exclusively on Linux in lieu of new, novel systems; where non= -Linux systems are featured (something like 3 accepted papers between SOSP = and OSDI in the last two years out of $n$), the described systems are large= ly Linux-like. Here the presentation reminded me of Rob Pike's "Sy= stems Software Research is Irrelevant" talk=C2=A0(slides of which are = available in various places, though I know of no recording of that talk).

Roscoe's challenge is that all of this should b= e seen as both a challenge and an opportunity for new research into operati= ng systems specifically: what would it look like to take a holistic approac= h towards the hardware when architecting a new system to drive all this har= dware? We have new tools that can make this tractable, so why don't we = do it? Part of it is bias, but part of it is that we've lost sight of t= he larger picture. My own question is, have we become entrenched in the wor= ld of systems that are "good enough"?

Th= ings he does NOT mention are system interfaces to userspace software; he do= esn't seem to have any quibbles with, say, the Linux system call interf= ace, the process model, etc. He's mostly talking about taking into acco= unt the hardware. Also, in fairness, his highlighting a "small" p= ortion of the system and saying, "that's what the OS drives!"= sort of reminds me of the US voter maps that show vast tracts of largely u= npopulated land colored a certain shade as having voted for a particular ca= ndidate, without normalizing for population (land doesn't vote, people = do, though in the US there is a relationship between how these things impac= t the overall election for, say, the presidency).

= I'm curious about other peoples' thoughts on the talk and the overa= ll topic?

https://www.youtube.com/watch?v=3D36myc8wQhLo

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

--0000000000005949f405caf62ec1--