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 22951 invoked from network); 16 Sep 2021 23:15:28 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 16 Sep 2021 23:15:28 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id 750669CAC5; Fri, 17 Sep 2021 09:15:26 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 8DDA09CAB3; Fri, 17 Sep 2021 09:14:55 +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="YhI8CBWZ"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id 36A629CAB3; Fri, 17 Sep 2021 09:14:52 +1000 (AEST) Received: from mail-ot1-f45.google.com (mail-ot1-f45.google.com [209.85.210.45]) by minnie.tuhs.org (Postfix) with ESMTPS id B590C9CAB2 for ; Fri, 17 Sep 2021 09:14:51 +1000 (AEST) Received: by mail-ot1-f45.google.com with SMTP id 97-20020a9d006a000000b00545420bff9eso3520734ota.8 for ; Thu, 16 Sep 2021 16:14:51 -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=uP6DQukI6wvi+TFW0TI0ILvkllVthPCTztAzwblA5HU=; b=YhI8CBWZNXaesprO2reNQ8nlT/1MaJbqsnXWDkg9+TsucbOrKoA4G/teqhI1vllc4j 70hg3zUSxRU5TepASkMXNC0mvjAPPVQ+/qdzntEDERjaVn3IKzQztZ7TqsUCaOM9If7p /6mbtlSiRtbGNPEmnRP1B9QiN+8+AJtcaNGr6l306wp0Ab9dCUieprLXm/c0l9f3wA34 n9VGRcnYuGUp1c2R1kzNGaYJGEh1bY9dXMHu3yESXAeAxAymvVui+2CGq1uM1qA0AleP 2V/J7gbjFNqrw5vPRUrYL/uVAcommRq/BEzT+CwguIB38FVFUp3CNrBOARi31sVJ12Y6 ZZ4Q== 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=uP6DQukI6wvi+TFW0TI0ILvkllVthPCTztAzwblA5HU=; b=lfpeFX3KQYLAIcotKOBXc6kUgWJNJucd5qyUfwXTFwMqrcdqWFFyVuvjbQdd1DF/yY rKPS7iC/eAEXM6yR/mP3EOGonyh619Z9IUgkhx1g/20L6AG/bj/VHFJoRZ9spgjYnzs6 gXhUARQZszY2moY0r90PoIMdRUjMZ8hkmtymVlmpSfyScpV7rwTYm6KlaphJpvsJNPrK DmjyhwOfvwUGGpj2sg1OalQHvDV91Zo7a4hnUglk1ff2ftHCZ+fmWz9ch6PTlcjAAko/ md15p9VDkU3X4zSHh7DrLFxcMtmHMmkSqmOTuBl74VWgpWgfGhftCEwwNVwZAK3jMRF/ uB6A== X-Gm-Message-State: AOAM532NjTK7m/XZwxTqekz9h0UnxLv5ha7Zo+xAg8PuE/uDuX8JiQZB cyEm7GLGvgH3OJoRXmz95p4+Utfxr7nym7KXA9Q= X-Google-Smtp-Source: ABdhPJwzQ8B9a8l7TTP8Hrm2+tAmmsrrtOEqZvy4qtY54ppMtErAasM/bSxiU5TazbEDvUxCrQghA/MjoPOdSjSgFGw= X-Received: by 2002:a9d:740c:: with SMTP id n12mr4925153otk.326.1631834087625; Thu, 16 Sep 2021 16:14:47 -0700 (PDT) MIME-Version: 1.0 References: <202109161934.18GJYFsl881498@darkstar.fourwinds.com> <20210916194103.GK26820@mcvoy.com> In-Reply-To: <20210916194103.GK26820@mcvoy.com> From: Marshall Conover Date: Thu, 16 Sep 2021 19:14:36 -0400 Message-ID: To: Larry McVoy 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: , Cc: TUHS main list Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" While I got a chuckle from this, it focuses on security, and I don't think security sold docker containers. I think what really sold containers was their ability to solve the old, hard problems of configuring and maintaining servers. Docker's use of per-process namespaces is a godsend for running different services on the same machine. I no longer run into two applications fighting over dependency versions, because both applications are running in their own world. This was somewhat possible in chroots, but as someone who tried to use chroots that way a decade ago, docker's made it trivial. Containers are also a godsend for applications that have to be deployed somewhere else. I know a container I deploy will have everything it needs wherever it goes, and will be exactly the thing I built and tested. It's hard to understate the benefits of this: when deploying, I no longer run into issues like "oh shoot, there was some configuration I forgot about on the dev server that I need for prod." I no longer have to create server configuration documentation either, as the documentation is "docker build," followed by "docker run." When we were first starting out on our current project, we built a container that runs our build system's agents. At one point the VM on which we were running those agents went down, and our stop-gap fix was to download and run a few copies of that container locally. As a result, we had builds going the entire time we worked to fix the issue. --------------- Separately, for the larger discussion, I think the abstraction-aerospace-engineering seen over the last few decades comes from the adage "necessity is the mother of invention." People writing business logic today are targeting an OS-independent platform: the browser. That's where developers need solutions, and that's where we see movement. Considering this, it's no surprise the browser has stumbled backwards from a markup language-renderer into a full platform for downloading and running applications and managing their resources, as well as providing complex abstractions for interacting with distributed systems. And it's no surprise those distributed systems have separated as much as possible from whatever's not the browser. In fact, we're seeing agreement in the browser ecosystem for problems like the directory system choice mentioned above. The OIDC workflow was born out of the internet's many-users-to-many-services issue. Now, it's such a decided approach for managing users' access to services that big names like Amazon and Google offer identity provider services using it, and I, as a service writer, can swap between any of them transparently. The services I run only care that the token they're handed is signed by the auth server they're configured to use, and that the token says the user is allowed to use the service contacted. The applications I write and use have no clue what the OS' permissions are for anything they deal with. For them, OS permissions have been made redundant. With this context, I think most of us here have learned by experience why the OS gets no more development, in every discussion they've had with management where they've said "we need to refactor some code that is wonky, but mostly works, because there will probably be errors and bugs and security issues in the future if we don't." Management - which in this case, means the world at large - demands new features, not unspecified heisen-benefits from redoing things that already work. For new features, the browser is their only recourse. And, to boot - if you change the thing under the browser, what if it breaks the browser? Cheers! Marshall On Thu, Sep 16, 2021 at 3:41 PM Larry McVoy wrote: > > On Thu, Sep 16, 2021 at 12:34:15PM -0700, Jon Steinhart wrote: > > 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. > > Amen. > > > 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? > > I think it is that the newer kids are less willing to understand stuff. > So they build something on top that they understand. I agree that they > will hit problems and likely build "safe deposit boxes" because the > containers are "too complex". > > Oh, and get off my lawn!