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.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 30332 invoked from network); 17 Sep 2021 18:25:29 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 17 Sep 2021 18:25:29 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id 1EFD09CACC; Sat, 18 Sep 2021 04:25:27 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 247119CAB3; Sat, 18 Sep 2021 04:24:58 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="Nh/YVV87"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id D2F269CAB3; Sat, 18 Sep 2021 04:24:56 +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 A410C9CAB2 for ; Sat, 18 Sep 2021 04:24:55 +1000 (AEST) Received: by mail-oi1-f178.google.com with SMTP id t189so2635213oie.7 for ; Fri, 17 Sep 2021 11:24:55 -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; bh=9Q7C5xkcXUGQ4Bau0uuVPDXBX6TmhAsX3hKhC4BHNOU=; b=Nh/YVV87Szc2V8iYYupC4ij9qGLuYDKNDKGRA4bfSZxJQ09TPrQyDR/I0SuoD4AVgX 4gIBhcMpp3mXuJ67lK2MD6kU+ZE0Bdb96L3uXWfjJOM6i5szDIeK1piAuZY2UM52MWEJ HUehO3DVGw4UaEyMeDoviiJOF7Pb3c0+RCoY7Qq37KvLCdQDkc8ypVG7cdEIXLHA2xaL K9d7tStKce0H1Rzef5VxXnQ8a4s8i4mhsVEOznYy9ey9Jdy8mzQMVma1juVzTJeZsHHW NcNaQnP+qBjUXTWlx5o9uPx1HSOrkIhuQsqR+EkQPo4V3yyG1wTFbMp6dZkLPLlFE9/0 wu6w== 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; bh=9Q7C5xkcXUGQ4Bau0uuVPDXBX6TmhAsX3hKhC4BHNOU=; b=5WKVWIiqG6Ok09Lc2fKBO5PdkKhuCYCMCazurcSePOqbTFu+EMslW0eQsw7+7L9cPv CG4SLXrUirzmju0vshX/hviL13s852jjUCY+FJCeVJMRfJpSL22Ka2ZOuPZb0uYFxYCe AdzAqv1ATcI3Lbp5CmV2p9FLPRmcWN6Ce7itn1yI1REF/ljiCCpkvyiqSXuQ1ACr2VtU VnaCTxmycJn2Y6LFnV+3cwqciqwBa44CpCZFBe74hBFAh+QaGytOb/8FBRsGnMM8sZfq gsaFigdpIYsOXca8+I6bRiqVzFlE9NmU/G2OtIIao5CbzM4pSfhKYi7eqik2LEPACK/j M2Jw== X-Gm-Message-State: AOAM531yzE3sjvRH5LsY03AdMqP87Wktzq+gUkR5R9RmUiI0uPMgPrGW 9SsEA8EBqlvRrYCjPWvz0SppmRXigiEvBxLRIw4Va3bs X-Google-Smtp-Source: ABdhPJz3SNOo2+5uVJdcby8f8MFY3B7kzILnpD5gUYT4Ht66VkLa7qI7yR1xFVUzZiuocFUWBnq89FnHdepi0TjSNgk= X-Received: by 2002:aca:400a:: with SMTP id n10mr5045390oia.49.1631903094341; Fri, 17 Sep 2021 11:24:54 -0700 (PDT) MIME-Version: 1.0 References: <202109161934.18GJYFsl881498@darkstar.fourwinds.com> <8A83BD02-E014-4282-A67D-FDD928AF35DE@iitbombay.org> In-Reply-To: <8A83BD02-E014-4282-A67D-FDD928AF35DE@iitbombay.org> From: ron minnich Date: Fri, 17 Sep 2021 11:24:42 -0700 Message-ID: To: TUHS main list Content-Type: text/plain; charset="UTF-8" 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" As a student weekend operator at Dupont, I saw the last 2 weeks of the 705 vacuum tube machine that ran payroll and then, over two years: the 7080 that ran the 705 in emulation; the 360 that ran the 7080 that ran the 705; the 370 that ran the 360 that ran the 7800 that ran the 705. The 370 sacrificed ASCII support so it could emulate a 360 (IBM ran out of bits in the PSW, so ASCII had to go). The Blue Gene compute node kernel (CNK) started out supporting the "most commonly used" 80 or so linux system calls; that grew by about 1 system call a month. As CNK became asymptotic to Linux, some sites threw in the towel and ran linux. Frequently, emulation is not enough. Linux itself supported SCO for a time; freebsd has a good linux subsystem; one could argue that Linux emulates Linux, given its binary compatibility guarantee. Unix had a JCL command through v5 and still has a GECOS field in the password. The x86 allocates 1/256 of its gigantic opcode space to the DAA instruction nobody uses. A multi-hundred core server can still boot CP/M and DOS 1.0 RISC-V started as clean-ish break with the past, and has followed the standard evilutionary path to x86-inspired 4k page sizes; big-endian support; and runtime BIOS. Successful systems rarely come as a complete break with the past. People frequently expect that the Unix "clean break" experience can be repeated, but. if anything, the history of Unix shows why that experience is unlikely to be repeated. But if you're going to do a new kernel, and you want broad usage, you're going to provide a VM to run Linux or something like it, or you're going to fail. Or target something invisible, like a security token, then you are free to do what you will -- the Google Open Titan security token runs a kernel written in Rust. Nobody knows about it so nobody cares. ron p.s. I remember the person who finally ported payroll from the 705 binary. "There's a bug in there, maybe, but i can't find it" -- 2 weeks later, in a not-to-be-repeated occurence, the paycheck of all us weekend students was 2x normal. We couldn't figure out who to report it to so we let it slide. p.p.s. The 7080 was the last mainframe I worked with that smelled of machine oil. On Fri, Sep 17, 2021 at 8:57 AM Bakul Shah wrote: > > On Sep 16, 2021, at 12:34 PM, Jon Steinhart wrote: > > > > 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? > > Recall that previously sysadmins used programs such as ghost to image a > system. A completely operational system with all the required software > could be created fairly quickly with minimum configuration. If your > h/w crashed, you can get up and running fairly quickly on a new machine > (provided your unique bits were backed up & restored). The same thing > could be done for server machines. By minimizing differences you can > apply security patches or put new machines in service quickly. A server > machine needs much more than the main service program before it can > be put in real service but machines providing the same service need > pretty much the same things. > > When VMs and containers started getting used, the same model could > be used for provisioning them. The docker folks simplified this > further. Now you can spin up new servers almost trivially (even if > later tooling via Kubernetes and such got quite complicated). Seems > to me, this provisioning of whole systems is what users of technologies > such as jail never quite got it. > > A couple of points on this: 1) I think this can be simplified even > further if one can rely on a fast control plane connection by basically > lazily pulling in the contents of each container. 2) If the underlying > system provides a capability architecture, you can probably achieve the > exact same functionality without containers as the required "many worlds" > functionality is already built in. > > -- Bakul