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, RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 9273 invoked from network); 8 Feb 2021 18:32:38 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 8 Feb 2021 18:32:38 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id EA5899BA66; Tue, 9 Feb 2021 04:32:35 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id D21109BA50; Tue, 9 Feb 2021 04:32:18 +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="sbGvbfQ9"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id C59139BA50; Tue, 9 Feb 2021 04:32:16 +1000 (AEST) Received: from mail-ua1-f54.google.com (mail-ua1-f54.google.com [209.85.222.54]) by minnie.tuhs.org (Postfix) with ESMTPS id F30419BA42 for ; Tue, 9 Feb 2021 04:32:15 +1000 (AEST) Received: by mail-ua1-f54.google.com with SMTP id g13so4994038uaw.5 for ; Mon, 08 Feb 2021 10:32:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fQ30wOKF+SWO6l/kjIo5j7Z8hnxamr5M8mvmQ8a5S6w=; b=sbGvbfQ9FcoXS1k5nfX/PhPHFC4p9oNKIFWrjOSNJaX1ChG5mdZe/hKflyhDqo/PjO xbDM0ShUGGwAoAVbmD7FPNMAUbC56q4grEa61r3FvINZuHKQrmGInkNfCb44pj/CK9IY Wmas4ZWcHaSRsZs4cyjTihphdRyx3nCEIsPmPmP2MzxEIt3rnyOBfP5cewPh7H7My8OF +NrMxibNhKeUM2LugNWn1VujHbpLTadOEHS1vHFtZF/lZiirBTINK/YqEQ5Tn1a7mkcL wMNWXU6E87dPFQJ0K1i6Z1NEm6ga3746+YBRGUsy3Zr9yAvC6Hi3NtGP+4ywju3SE1To pzHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=fQ30wOKF+SWO6l/kjIo5j7Z8hnxamr5M8mvmQ8a5S6w=; b=ZBb8FNxi80gkrv7GB+dYEOrbLV9aLU9ACUCadR1TM119772NiRSfY2swf5RwH0glQF qLs0BiZ7tDHGAzXcXtEn+9cxuZpUawBD46jPJP+wjN5j48/5c6ZQXiELYDLNPKYsoJjC O2K+/flxJnI2DsqzRfaV6CEmG13aawiQ3BqpvrvtFZI5vjndIcLvmoclsN96ic8ePMht FLH1RmUXuC9sbrGiuz7PZWAY0BmyRaeQXwugnDgpy9rt6ifOTRCS3xw9dNXiTYnbxlQF mJpZN5eb2EWVEKN32U4Xlkwcv7ajTnmN6Ojd5y7Z8RchLvtdJixmE5W9XdyhPkUBAXFu BuMg== X-Gm-Message-State: AOAM531nffK3gl6Th0PjiEhh0Ho7LHyvm5MWB3mzpMBt7yXNVvZn1xOz 2WcshU6CoSUL/cZoAWR/2H3LaXuY7wrvXlMMne8= X-Google-Smtp-Source: ABdhPJyFA8VhAbySdhJxyV4NO1lvxZ5yQzuVKPICsBJq82oIGf7W0wxPjteDr/CcUzqKbamZOyr8kzEh6lh3LObYt+8= X-Received: by 2002:a9f:3608:: with SMTP id r8mr5640733uad.141.1612809135093; Mon, 08 Feb 2021 10:32:15 -0800 (PST) MIME-Version: 1.0 References: <20210208182123.GI13701@mcvoy.com> In-Reply-To: <20210208182123.GI13701@mcvoy.com> From: Justin Coffey Date: Mon, 8 Feb 2021 10:32:03 -0800 Message-ID: To: Larry McVoy Content-Type: multipart/alternative; boundary="000000000000967a8d05bad7633c" Subject: Re: [TUHS] Macs and future unix derivatives 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" --000000000000967a8d05bad7633c Content-Type: text/plain; charset="UTF-8" On Mon, Feb 8, 2021 at 10:22 AM Larry McVoy wrote: > On Mon, Feb 08, 2021 at 12:11:08PM -0600, Will Senn wrote: > > And a bonus question, why, oh why, can't we have a contained kernel that > > provides minimal functionality (dare I say microkernel), that is > securable, > > and layers above it that other stuff (everything else) can run on with > > auditing and suchlike for traceability? > > I can answer the microkernel question I think. It's discipline. > The only microkernel I ever liked was QNX and I liked it because it was > a MICROkernel. The entire kernel easily fit in a 4K instruction cache. > > The only way that worked was discipline. There were 3 guys who could > touch the kernel, one of them, Dan Hildebrandt, was sort of a friend > of mine, we could, and did, have conversations about the benefits of a > monokernel vs a microkernel. He agreed with me that QNX only worked > because those 3 guys were really careful about what went into the > kernel. There was none of this "Oh, I measured performance and it is > only 1.5% slower now" nonsense, that's death by a hundred paper cuts. > Instead, every change came with before and after cache miss counts > under a benchmark. Stuff that increased the cache misses was heavily > frowned upon. > > Most teams don't have that sort of discipline. They say they do, > they think they do, but when marketing says we have to do $WHATEVER, > it goes in. > This describes pretty much every project I've ever worked on. It starts small, with a manageable feature set and a clean and performant codebase and then succumbs to external pressure for features and slowly bloats. If the features prove useful then the project will live on of course (and those features may well be the reason the project lives on), but at some point the bloat and techdebt become the dominant development story. My question then is, are there any examples of projects that maintained discipline, focus and relevance over years/decades that serve as counter examples to the above statement(s)? OpenBSD? Go? Is there anything to learn here? -Justin -- +1 (858) 230-1436 jqcoffey@gmail.com ----- --000000000000967a8d05bad7633c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Feb 8, 2021 at 10:22 AM Larry= McVoy <lm@mcvoy.com> wrote:
<= /div>
On Mon, Feb 08, 2021= at 12:11:08PM -0600, Will Senn wrote:
> And a bonus question, why, oh why, can't we have a contained kerne= l that
> provides minimal functionality (dare I say microkernel), that is secur= able,
> and layers above it that other stuff (everything else) can run on with=
> auditing and suchlike for traceability?

I can answer the microkernel question I think.=C2=A0 It's discipline. The only microkernel I ever liked was QNX and I liked it because it was
a MICROkernel.=C2=A0 The entire kernel easily fit in a 4K instruction cache= .

The only way that worked was discipline.=C2=A0 There were 3 guys who could<= br> touch the kernel, one of them, Dan Hildebrandt, was sort of a friend
of mine, we could, and did, have conversations about the benefits of a
monokernel vs a microkernel.=C2=A0 He agreed with me that QNX only worked because those 3 guys were really careful about what went into the
kernel.=C2=A0 There was none of this "Oh, I measured performance and i= t is
only 1.5% slower now" nonsense, that's death by a hundred paper cu= ts.
Instead, every change came with before and after cache miss counts
under a benchmark.=C2=A0 Stuff that increased the cache misses was heavily<= br> frowned upon.

Most teams don't have that sort of discipline.=C2=A0 They say they do,<= br> they think they do, but when marketing says we have to do $WHATEVER,
it goes in.

This describes pretty much = every project I've ever worked on.=C2=A0 It starts small, with a manage= able feature set and a clean and performant codebase and then succumbs to e= xternal pressure for features and slowly bloats.=C2=A0 If the features prov= e useful then the project will live on of course (and those features may we= ll be the reason the project lives on), but at some point the bloat and tec= hdebt become the dominant development story.

My qu= estion then is, are there any examples of projects that maintained discipli= ne, focus and relevance over years/decades that serve as counter examples t= o the above statement(s)?=C2=A0 OpenBSD?=C2=A0 Go?=C2=A0 Is there anything = to learn here?

-Justin
--
<= div dir=3D"ltr" class=3D"gmail_signature">
+1 (858) 23= 0-1436
--000000000000967a8d05bad7633c--