The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: Bakul Shah <bakul@iitbombay.org>
To: TUHS main list <tuhs@minnie.tuhs.org>
Subject: Re: [TUHS] ATC/OSDI'21 joint keynote: It's Time for Operating Systems to Rediscover Hardware (Timothy Roscoe)
Date: Fri, 17 Sep 2021 08:56:13 -0700	[thread overview]
Message-ID: <8A83BD02-E014-4282-A67D-FDD928AF35DE@iitbombay.org> (raw)
In-Reply-To: <202109161934.18GJYFsl881498@darkstar.fourwinds.com>

On Sep 16, 2021, at 12:34 PM, Jon Steinhart <jon@fourwinds.com> 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

  parent reply	other threads:[~2021-09-17 15:56 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-01 21:58 Dan Cross
2021-09-02  8:42 ` Tony Finch
2021-09-03  0:19   ` John Cowan
2021-09-03  3:24     ` Douglas McIlroy
2021-09-03 13:21       ` Theodore Ts'o
2021-09-08 11:14         ` Tony Finch
2021-09-16 19:27         ` Dan Cross
2021-09-17  0:34           ` Theodore Ts'o
2021-09-17  0:44             ` Larry McVoy
2021-09-17 17:07               ` Bakul Shah
2021-09-17  1:33             ` Dan Cross
2021-09-02 15:41 ` Kevin Bowling
2021-09-02 20:12   ` Marshall Conover
2021-09-03 15:56 ` Warner Losh
2021-09-03 17:10   ` Adam Thornton
2021-09-03 17:28     ` Larry McVoy
2021-09-03 17:42       ` John Floren
2021-09-03 19:02       ` Lawrence Stewart
2021-09-03 19:11       ` Clem Cole
2021-09-03 17:46     ` [TUHS] ATC/OSDI'21 joint keynote: It's Time for Operating Systems to Rediscover Hardware [ really a comment on SoCs ] Jon Steinhart
2021-09-16 18:38 ` [TUHS] ATC/OSDI'21 joint keynote: It's Time for Operating Systems to Rediscover Hardware (Timothy Roscoe) Dan Cross
2021-09-16 19:34   ` Jon Steinhart
2021-09-16 19:41     ` Larry McVoy
2021-09-16 23:14       ` Marshall Conover
2021-09-16 23:44         ` Rob Pike
2021-09-17  0:37           ` Larry McVoy
2021-09-17  1:38         ` Jon Steinhart
2021-09-17  3:54         ` John Cowan
2021-09-16 23:45       ` Jon Steinhart
2021-09-17  0:06         ` Al Kossow
2021-09-17  4:06           ` John Cowan
2021-09-17  4:18             ` Al Kossow
2021-09-17  0:32         ` Larry McVoy
2021-09-16 23:54       ` David Arnold
2021-09-17  1:10         ` Jon Steinhart
2021-09-17  1:28           ` Larry McVoy
2021-09-17  1:40             ` Jon Steinhart
2021-09-17  2:04               ` Larry McVoy
2021-09-17  2:21                 ` Jon Steinhart
2021-09-17  2:48           ` Theodore Ts'o
2021-09-17 17:39         ` Bakul Shah
2021-09-17 17:51           ` Jon Steinhart
2021-09-17 18:07             ` Larry McVoy
2021-09-17 21:03               ` Derek Fawcus
2021-09-17 22:11                 ` Larry McVoy
2021-09-19  4:05                   ` Theodore Ts'o
2021-09-17 18:34             ` Bakul Shah
2021-09-17 18:56               ` Jon Steinhart
2021-09-17 19:16                 ` Bakul Shah
2021-09-17 19:35                   ` Jon Steinhart
2021-09-17 15:56     ` Bakul Shah [this message]
2021-09-17 18:24       ` ron minnich

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8A83BD02-E014-4282-A67D-FDD928AF35DE@iitbombay.org \
    --to=bakul@iitbombay.org \
    --cc=tuhs@minnie.tuhs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).