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 26139 invoked from network); 16 Sep 2021 23:45:27 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 16 Sep 2021 23:45:27 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id 8E6969CABE; Fri, 17 Sep 2021 09:45:26 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 2FA019CAB3; Fri, 17 Sep 2021 09:44:57 +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="UPfwXt6t"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id 27A5E9CAB3; Fri, 17 Sep 2021 09:44:55 +1000 (AEST) Received: from mail-pg1-f169.google.com (mail-pg1-f169.google.com [209.85.215.169]) by minnie.tuhs.org (Postfix) with ESMTPS id A868C9CAB2 for ; Fri, 17 Sep 2021 09:44:54 +1000 (AEST) Received: by mail-pg1-f169.google.com with SMTP id t1so7828343pgv.3 for ; Thu, 16 Sep 2021 16:44:54 -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=W5IfIogncfGoW1Y6KyaWo9TFl4UGSRI+quDKo0GPMQo=; b=UPfwXt6t6kbs0j5xqdcrAgY3LFVtvM7BjDWpaU/sQPJfXuYdO5G0VDGQtdXb2EXbQG mjkJ9Jc00pm/W8zV/JTyWuyz/PAeG0/DS7cXMeXD53nMXdN+nd9WGAbqiZmWGZHmn+GX w+XVhuVeaSVflWqBoopR67gKjhvrBxpMVvLJ81oaLdypyTThMROKFiK875z4s16I3/47 +M0mZANNucdO+rMp/MrbN11DV49xpMHTAn5eUkrMD8kvaSFA17Ngwr/U7Msq8WIVWFBM Ec1AYnETdifyuPF2+4BRW/fgJTK6SjjLrx3q1QoH1mUKnCBfTk3yL2qi9+Hz3lMO81sy m23w== 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=W5IfIogncfGoW1Y6KyaWo9TFl4UGSRI+quDKo0GPMQo=; b=2OrTRZWwNwH247B6V7rRR46KIJvjgv3s8E8OfJwH6hVmp9IDQyXK3X9uHxp5PC+uj0 Omr0hO9cgNV+RL7RPuyjmbfHSbZadEvbOyTH31SJyOk6TZdmrgTYc2qY4tiW615Cv5xj xwRvdflBQl1F5vb4izK9XkP4rBTZMzHYRH3VJJYgL9aMa4iOTd7/Bl681+RqX1y3FZb5 t37lOVTLLdJSWN/xjak/IXaOdLbsfGurVk/8PPk5mbEd8TIQeTGVkpAwC4zGDdUxTqzd B5kmausytVPk72mVZqYSgqxOvhgz/nYazsLy3XzeEJvHNTGSIgi9Tp3j6/aSBhrYrw7E wSkg== X-Gm-Message-State: AOAM532g7AnNxagFhDvJxqFk4rN/4BWndTUwoDnXUbyeu1SGFiBeeWKc I4cOoZ+vUGCrKY6lPN2umaSqlF5vxJGWbNZpfm9jV5g4QiY= X-Google-Smtp-Source: ABdhPJz8+GZyVTcQJ3461SlFDC8vDl27eOcmDvjNwyvQc/G4auL8J46mLgTCjRSUScvKSprX3olG0tRGxFu4+hFhVms= X-Received: by 2002:a62:6103:0:b0:405:2c7a:9ee9 with SMTP id v3-20020a626103000000b004052c7a9ee9mr7668269pfb.71.1631835893942; Thu, 16 Sep 2021 16:44:53 -0700 (PDT) MIME-Version: 1.0 References: <202109161934.18GJYFsl881498@darkstar.fourwinds.com> <20210916194103.GK26820@mcvoy.com> In-Reply-To: From: Rob Pike Date: Fri, 17 Sep 2021 09:44:42 +1000 Message-ID: To: Marshall Conover Content-Type: multipart/alternative; boundary="000000000000ca4dae05cc2566b1" 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" --000000000000ca4dae05cc2566b1 Content-Type: text/plain; charset="UTF-8" I believe that Docker would not have been nearly as successful if shared libraries had not taken over the Unix world. Docker would have been helpful for putting together Python and Java installations, with all their ancillary bits, but less so for C binaries. Now, though, we run an OS on the machine, put a VM on that, install a container on that, and run another VM (or JVM) inside the container, then maybe we're at the level where we can execute actual code. And that misses all the extra pieces that are distributed and layered and indirected and virtualized for management, logging, security, data warehousing, ... It's a wonder any of it works at all. Here's a map to guide you: https://landscape.cncf.io/ -rob On Fri, Sep 17, 2021 at 9:15 AM Marshall Conover wrote: > 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! > --000000000000ca4dae05cc2566b1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I believe that Docker would not have been nearly as succes= sful if shared libraries had not taken over the Unix world.

<= div>Docker would have been helpful for putting together Python and Java ins= tallations, with all their ancillary bits, but less so for C binaries.

Now, though, we run an OS on the machine, put a VM on = that, install a container on that, and run another VM (or JVM) inside the c= ontainer, then maybe we're at the level where we can execute actual cod= e. And that misses all the extra pieces that are distributed and layered an= d indirected and virtualized for management, logging, security, data wareho= using, ...

It's a wonder any of it works at al= l.

Here's a map to guide you:=C2=A0https://landscape.cncf.io/

-rob


On Fri, Sep 17, 2021 at 9:15 AM Marshall = Conover <marzhall.o@gmail.com> wrote:
Whi= le 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<= br> configuration I forgot about on the dev server that I need for prod."<= br> 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 wri= ting
business logic today are targeting an OS-independent platform: the
browser. That's where developers need solutions, and that's where w= e
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,<= br> 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<= br> 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 -<= br> 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 <lm@mcvoy.com> 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.=C2=A0 It's not= OK to me from a
> > security, safety, and reliability perspective to build on a rotti= ng
> > foundation.
>
> Amen.
>
> > It's my opinion that the whole container thing sort of starte= d as a "we
> > can't secure the underlying system so we'll build somethi= ng secure on top"
> > combined with "it's no fun to fix the unnecessary incomp= atible mess among
> > virtually identical systems that we've made so we'll buil= d a new fix-it
> > layer" ideologies.=C2=A0 How long until problems are found w= ith containers
> > it's decided that the way to fix it is to build "safe de= posit boxes" that
> > run in container?=C2=A0 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.=C2=A0 I agree tha= t they
> will hit problems and likely build "safe deposit boxes" beca= use the
> containers are "too complex".
>
> Oh, and get off my lawn!
--000000000000ca4dae05cc2566b1--