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,MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 32421 invoked from network); 2 Sep 2021 20:14:02 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 2 Sep 2021 20:14:02 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id 4D48E9C8BB; Fri, 3 Sep 2021 06:14:01 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 8D1BE9C870; Fri, 3 Sep 2021 06:13:15 +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="oM9VjcRH"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id B360A9C870; Fri, 3 Sep 2021 06:13:10 +1000 (AEST) Received: from mail-oi1-f178.google.com (mail-oi1-f178.google.com [209.85.167.178]) by minnie.tuhs.org (Postfix) with ESMTPS id 3811A9BA1E for ; Fri, 3 Sep 2021 06:13:10 +1000 (AEST) Received: by mail-oi1-f178.google.com with SMTP id u25so4133243oiv.5 for ; Thu, 02 Sep 2021 13:13:10 -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:content-transfer-encoding; bh=mLvXLG0uMSwsX59m/+OTiE5z0vpP4a7kVuDKnkrkG7k=; b=oM9VjcRHvmDmEH9wAn6h2jQe2ziW31oY/qGru6dGPo8R8YEht7t9tEDpDY/yJETTYm vUCUZDlXqNXO49xDNS/mPtbHkOPCBX7/5RWu3Mehvi3acWFArfKYYrWecWbuo95yjF9n 5vyLMHhwJZyskNJbX2oe+gEXEGURW5PzX2p550aejOzwfWFD+vIqp/rOOJQrv0VR/y8C VbXSGaVbFSuJ0PSALkOb0qgWpuQgUVAxbbIyQgixu+zTqEF1Pi1aYg18L9S3RUdYhEDf gOApFYchqFAydUhViq4ciKH7Xq2y3dGtWUWIbxquNo3jxSx+Z1gTz62jjyGK1sYp7yDV rTkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=mLvXLG0uMSwsX59m/+OTiE5z0vpP4a7kVuDKnkrkG7k=; b=j8P2qcHJo1oNkeoOC7NHRglAnDkquthuMJ/5yazw8m9dAxAlnDIqpkZ3SEyuBtQBF2 oRvnO6T1MFnFP2M7KKge7rvG4X29o4n+b1S+yLL8JWeT/AzdDl0m6Hn1uZSiTBY3a0C5 BBOFVeRl2d2r0Z0YxoZAQSAu1woDNrMl2RyhEKJTMNvRoCzCX34SaeGVr7w3K0/SoJxC bN+VEXeH7Z38o2oDhBdjVTEe/Jw0kFOh+zHNyjhztgMdIyCXYPyHHnk0QUaW8jEgqZTC AlPx3kMuAT0V5tEB4duX0cEvkHP1I8iztci3+SjC1VjE4G3WB0EB6US5wnk7j7UWgMab DRBQ== X-Gm-Message-State: AOAM532VD3Jgg+ewd1stKgPHXcH9xUOMnheCG95wgdTa8q5x2zDVi2vL 6GvF5cVRyHWOU/EuhIjLRZVXJRCvsIBGYcy0xQE= X-Google-Smtp-Source: ABdhPJwaWl1tpj74N2qLuy2lMz3o7hBi205wIjqmDqSRr4b29LjFeIsJUAVGmYP5tWNcAUcRw9Y+1DeWZ/gRBbjKnqo= X-Received: by 2002:a05:6808:95:: with SMTP id s21mr52303oic.80.1630613589246; Thu, 02 Sep 2021 13:13:09 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Marshall Conover Date: Thu, 2 Sep 2021 16:12:58 -0400 Message-ID: To: Kevin Bowling Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" Kevin, I think that's a great framing of why this talk actually seemed inverted in its focus for me, and a good identification of why the presenter might see OS development stalling out and ossifying around Linux. I come from the opposite side of the presenter here: my frustration as a backend dev and user has been that modern OSs still think presenting an abstraction over my resources means making it easy to use one single machine (or, as the presenter brings up, a subset of the machine). Instead, my resources are spread out among many machines and a number of remote web services, for which I'd like to have one seamless interface - both for development and use. From an OS perspective, Plan 9 and its daughter systems have come the closest I've seen to addressing this by intentionally thinking about the problem and creating an API system for representing resources that reaches across networks, and a mutable namespace for using and manipulating those APIs. Despite pulling other ideas from 9, the importance of having an opinion on the distributed nature of modern computing seems to have been missed by prominent operating systems today. As a result, their development has been relegated to what they do: be a platform for things that actually provide an abstraction for my resources. And userspace systems have filled the demand for abstracting distributed resource usage to demonstrable business success, if questionable architectural success (as in, they can still be a confusing pain in the buns and require excess work sometimes). As a dev, the systems that have come the closest to presenting one unified abstraction over my resources are the meta-services offered by Google, MS and Amazon such as Azure and AWS. I think the distributed nature of things today is also potentially why the focus of the conference is on distributed systems now, as lamented by the presenter. Granted that I'm not the sharpest bulb in the drawer, but I can't think of a way an OS taking more direct control of the internal hardware of an individual computer would impact me beyond the security issues mentioned in the talk. However, I can think of a number of ways an OS being opinionated about working with networked machines would greatly improve my situation. Boy, it would be great to just spin up a cluster of machines, install one OS on all of them, and treat them as one resource. That's the dream the k8s mentality promises, and MS and Amazon are already walking towards being this sort of one-stop shop: "want cluster computing? Press a button to spin up a cluster with ECS, and store your containers in ECR. Want to run a program or twelve somewhere on the cluster? Just tell us which one and how many. Worried about storage? Just tell us what size storage it needs. We've got you covered!" None of it is perfect, but it shows that there's heavy demand for a system where users don't have to think about how to architect and maintain arbitrary groupings of their resources as necessitated by how OSs think of their job now, and instead just want to feel as if they're writing and running programs on one big 'thing'. So I think the ossification around Linux mentioned in the talk might be that unless operating systems start doing something more than being a host for the tools that actually provide an abstraction over all my resources, there's no real reason to make them do anything else. If you're not making it easier to use my resources than k8s or Azure, why would I want you? Cheers, Marshall On Thu, Sep 2, 2021 at 11:42 AM Kevin Bowling wr= ote: > > On Wed, Sep 1, 2021 at 3:00 PM Dan Cross wrote: > > > > One of the things I really appreciate about participating in this commu= nity and studying Unix history (and the history of other systems) is that i= t gives one firm intellectual ground from which to evaluate where one is go= ing: without understanding where one is and where one has been, it's diffic= ult 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 lead= ing to the systems we are studying, is that our thinking can become calcifi= ed in assuming that those systems continue to meet the needs of the problem= s of today. It is therefore always important to reevaluate our base assumpt= ions in light of either disconfirming evidence or (in our specific case) ch= anging environments. > > > > To that end, I found Timothy Roscoe's (ETH) joint keynote address at AT= C/OSDI'21 particularly compelling. He argues that what we consider the "ope= rating system" is only controlling a fraction of a modern computer these da= ys, and that in many ways our models for what we consider "the computer" ar= e outdated and incomplete, resulting in systems that are artificially const= rained, insecure, and with separate components that do not consider each ot= her and therefore frequently conflict. Further, hardware is ossifying aroun= d the need to present a system interface that can be controlled by somethin= g like Linux (used as a proxy more generally for a Unix-like operating syst= em), simultaneously broadening the divide and making it ever more entrenche= d. > > > > Another theme in the presentation is that, to the limited extent the br= oader systems research community is actually approaching OS topics at all, = it is focusing almost exclusively on Linux in lieu of new, novel systems; w= here non-Linux systems are featured (something like 3 accepted papers betwe= en SOSP and OSDI in the last two years out of $n$), the described systems a= re largely Linux-like. Here the presentation reminded me of Rob Pike's "Sys= tems Software Research is Irrelevant" talk (slides of which are available i= n 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 challen= ge and an opportunity for new research into operating systems specifically:= what would it look like to take a holistic approach towards the hardware w= hen 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, b= ut part of it is that we've lost sight of the larger picture. My own questi= on is, have we become entrenched in the world of systems that are "good eno= ugh"? > > > > 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 inte= rface, the process model, etc. He's mostly talking about taking into accoun= t the hardware. Also, in fairness, his highlighting a "small" portion of th= e 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 normalizi= ng 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, sa= y, the presidency). > > > > I'm curious about other peoples' thoughts on the talk and the overall t= opic? > > > > https://www.youtube.com/watch?v=3D36myc8wQhLo > > > > - Dan C. > > > One thing I've realized as the unit of computing becomes more and more > abundant (one off > HW->mainframes->minis->micros->servers->VMs->containers) the OS > increasingly becomes less visible and other software components become > more important. It's an implementation detail like a language runtime > and software developers are increasingly ill equipped to work at this > layer. Public cloud/*aaS is a major blow to interesting general > purpose OS work in commercial computing since businesses increasingly > outsource more and more of their workloads. The embedded (which > includes phones/Fuschia, accelerator firmware/payload, RTOS etc) and > academic (i.e. Cambridge CHERI) world may have to sustain OS research > for the foreseeable future. > > There is plenty of systems work going on but it takes place in > different ways, userspace systems are completely viable and do not > require switching to microkernels. Intel's DPDK/SPDK as one > ecosystem, Kubernetes as another - there is a ton of rich systems work > in this ecosystem with eBPF/XDP etc, and I used to dismiss it but it > is no longer possible to do so rationally. I would go as far as > saying Kubernetes is _the_ datacenter OS and has subsumed Linux itself > as the primary system abstraction for the next while.. even Microsoft > has a native implementation on Server 2022. It looks different and > smells different, but being able to program compute/storage/network > fabric with one abstraction is the holy grail of cluster computing and > interestingly it lets you swap the lower layer implementations out > with less risk but also less fanfare. > > Regards, > Kevin