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=-1.0 required=5.0 tests=MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 30812 invoked from network); 16 Sep 2021 19:34:34 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 16 Sep 2021 19:34:34 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id 74DD99CACC; Fri, 17 Sep 2021 05:34:33 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id A7EEB9CAB3; Fri, 17 Sep 2021 05:34:18 +1000 (AEST) Received: by minnie.tuhs.org (Postfix, from userid 112) id E33C59CAB3; Fri, 17 Sep 2021 05:34:16 +1000 (AEST) Received: from darkstar.fourwinds.com (fourwinds.com [63.64.179.162]) by minnie.tuhs.org (Postfix) with ESMTPS id 61F7F9CAB2 for ; Fri, 17 Sep 2021 05:34:16 +1000 (AEST) Received: from darkstar.fourwinds.com (localhost [127.0.0.1]) by darkstar.fourwinds.com (8.16.1/8.15.2) with ESMTP id 18GJYF1Q881501 for ; Thu, 16 Sep 2021 12:34:15 -0700 Received: from darkstar.fourwinds.com (jon@localhost) by darkstar.fourwinds.com (8.16.1/8.15.2/Submit) with ESMTP id 18GJYFsl881498 for ; Thu, 16 Sep 2021 12:34:15 -0700 Message-Id: <202109161934.18GJYFsl881498@darkstar.fourwinds.com> From: Jon Steinhart To: TUHS main list In-reply-to: References: Comments: In-reply-to Dan Cross message dated "Thu, 16 Sep 2021 14:38:38 -0400." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <881496.1631820855.1@darkstar.fourwinds.com> Date: Thu, 16 Sep 2021 12:34:15 -0700 X-JON-SPAM: local delivery 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: , Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" Dan Cross writes: > > First, thank you for all of the thoughtful responses, both on-list and off. > > An interesting theme in many of the responses was essentially questioning > whether the underlying OS still matters, since the focus on development has > shifted to higher levels? E.g., we now provision components of our > enormously large and complicated distributed applications with > building blocks like containers, less physical machines, let alone > processes etc. That is certainly a trend, but it strikes me that those > containers have to run somewhere, and at some point, we've still got > instructions executing on some CPU, modifying words of memory, registers, > etc; presumably all of that runs under the control of an operating system. > > It is a worthwhile question to ask whether that operating system still > matters at all: what we have works, and since it's so hidden behind layers > upon layers of abstraction, do we really care what it is? But I claim that > it does perhaps more than most folks realize. Certainly, there are metrics > that people care about (tail latency, jitter, efficiency at the 90th, 95th, > 99th percentile...) and OS effects can have outsized impacts there; Mothy's > talk alludes to this when he talks about all of the hidden processing > that's happening all over a modern computer, eventually some of that > trickles onto the cores that are running one's containerized Node > application or whatever (lookin' at you, SMM mode...). At the end of the > day, the code we care about still runs in some process under some OS on > some bit of physical hardware, regardless of all of the abstractions we've > placed on top of those things. What that system does, and the abstractions > that its interface provides to programs, still matters. > > Perhaps another question worth asking is, does it make sense to look at > different models for those systems? My subjective impression is that, back > in the 60s and 70s, there was much greater variation in system > architectures than today. A common explanation for this is that we didn't > know how to build systems at the time, so folks threw a lot of stuff at the > wall to see what would stick. But we no longer do that...again, Mothy > alludes to this in his brief survey of OSDI papers: basically, new systems > aren't being presented. Rob Pike also lamented that state of affairs 20 > years ago, so it's been going on for a while. Does that mean that we've > come up with a recipe for systems that work and work well, and therefore we > don't need to rethink those basic building blocks? Or does that mean that > we're so used to our systems working well enough that we've become myopic > about their architecture, and thus blind to their faults? > > - Dan C. Well, I have two different thoughts on this question. The obvious one to me is that of course it matters. I'll start by drawing a lame analogy as our 12 week deck reconstruction project just finished up an hour ago. In a conversation with the contractor he said "You're technically doing a repair so you don't have to pull a permit and bring it up to current code. But, there are some things that I recommend that you do anyway because the technology is much better than what it was when this thing was built 30 years ago." My point here is that sure, we can survive with what's there, but that doesn't mean that we should ignore new technology. I had dinner with one of the people I mentor a few weeks ago. He told me that while he was generally ok working for Google and making gobs of money that he felt sort of empty. He told me that if his project got cancelled he didn't think that the world would notice, and as a mid-20s person seeing the planet that he's living on burning up, he's thinking about changing careers to something that's more meaningful (to him). I think that there is still plenty of work to do on things like efficiency that would be easy to justify if politically energy wasn't so heavily subsidized. Think back a few decades to all of the power-saving changes that the OLPC spawned. Most felt like things were fine the way they were back then too. I think that layers upon layers is wasteful. As I've said before, I'm having difficulty distinguishing the "full stack" in full stack programming from a compost heap. It's not OK to me from a security, safety, and reliability perspective to build on a rotting foundation. It's my opinion that the whole container thing sort of started as a "we can't secure the underlying system so we'll build something secure on top" combined with "it's no fun to fix the unnecessary incompatible mess among virtually identical systems that we've made so we'll build a new fix-it layer" ideologies. How long until problems are found with containers it's decided that the way to fix it is to build "safe deposit boxes" that run in container? Is there ever an end in sight? My second train of thought is to ask the question "what is a computer?" Having started in an era where computing meant basking in the warm glow of vacuum tubes, it's easy to think that it's the hardware. But somewhere along the line microcode made an appearance, followed by nanocode and so on. I'm guessing, especially from spending time with current CS students, that to many a computer is some high-level abstraction. So the question is, below what layer is considered a computer today?