[TUHS] ATC/OSDI'21 joint keynote: It's Time for Operating Systems to Rediscover Hardware (Timothy Roscoe)

[Rob Pike]

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 <marzhall.o at gmail.com>
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 <lm at 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.  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!
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210917/488cba60/attachment.htm>