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.0 required=5.0 tests=MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 31504 invoked from network); 16 Sep 2021 19:41:17 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 16 Sep 2021 19:41:17 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id D012C9CACF; Fri, 17 Sep 2021 05:41:14 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 4E34B9CAB3; Fri, 17 Sep 2021 05:41:06 +1000 (AEST) Received: by minnie.tuhs.org (Postfix, from userid 112) id CCED29CAB3; Fri, 17 Sep 2021 05:41:04 +1000 (AEST) Received: from mcvoy.com (mcvoy.com [192.169.23.250]) by minnie.tuhs.org (Postfix) with ESMTPS id 58F939CAB2 for ; Fri, 17 Sep 2021 05:41:04 +1000 (AEST) Received: by mcvoy.com (Postfix, from userid 3546) id 4ABA335E14C; Thu, 16 Sep 2021 12:41:03 -0700 (PDT) Date: Thu, 16 Sep 2021 12:41:03 -0700 From: Larry McVoy To: Jon Steinhart Message-ID: <20210916194103.GK26820@mcvoy.com> References: <202109161934.18GJYFsl881498@darkstar.fourwinds.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <202109161934.18GJYFsl881498@darkstar.fourwinds.com> User-Agent: Mutt/1.5.24 (2015-08-30) 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" 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!