From: Justin Coffey <jqcoffey@gmail.com>
To: Larry McVoy <lm@mcvoy.com>
Cc: TUHS main list <tuhs@minnie.tuhs.org>
Subject: Re: [TUHS] Macs and future unix derivatives
Date: Mon, 8 Feb 2021 10:32:03 -0800 [thread overview]
Message-ID: <CAMAV7_BVhZM3er=U3mM_EHq0tzDBkdp0Av=m8nCHgX=-y4T9_Q@mail.gmail.com> (raw)
In-Reply-To: <20210208182123.GI13701@mcvoy.com>
[-- Attachment #1: Type: text/plain, Size: 2159 bytes --]
On Mon, Feb 8, 2021 at 10:22 AM Larry McVoy <lm@mcvoy.com> 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
-----
[-- Attachment #2: Type: text/html, Size: 2813 bytes --]
next prev parent reply other threads:[~2021-02-08 18:32 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-08 18:11 Will Senn
2021-02-08 18:21 ` Larry McVoy
2021-02-08 18:32 ` Justin Coffey [this message]
2021-02-08 18:39 ` Larry McVoy
2021-02-09 1:59 ` Theodore Ts'o
2021-02-12 13:48 ` Angel M Alganza
2021-02-08 18:42 ` Henry Bent
2021-02-09 6:55 ` John Gilmore
2021-02-09 7:05 ` Michael Huff
2021-02-16 22:55 ` Greg A. Woods
2021-02-09 7:17 ` Will Senn
2021-02-09 19:02 ` Theodore Ts'o
2021-02-10 1:34 ` Larry McVoy
2021-02-09 22:59 ` Wesley Parish
2021-02-08 18:43 ` Dan Stromberg
2021-02-12 13:39 ` Angel M Alganza
2021-02-08 18:45 ` Thomas Paulsen
2021-02-25 22:45 ` Dave Horsfall
2021-02-08 20:07 ` Al Kossow
2021-02-09 5:10 ` Andrew Warkentin
2021-02-09 7:42 ` [TUHS] QNX John Gilmore
2021-02-09 11:03 ` Robert Brockway
2021-02-09 18:24 ` Nemo Nusquam
2021-02-09 20:18 ` Jose R Valverde via TUHS
2021-02-09 14:05 ` Larry McVoy
2021-02-09 3:58 [TUHS] Macs and future unix derivatives M Douglas McIlroy
2021-02-09 4:07 ` Adam Thornton
2021-02-09 4:13 ` Will Senn
2021-02-09 5:21 ` Andrew Warkentin
2021-02-09 5:29 ` Theodore Ts'o
2021-02-09 6:37 ` Andrew Warkentin
2021-02-09 16:13 ` Theodore Ts'o
2021-02-09 17:31 ` John Cowan
2021-02-09 19:06 ` Chet Ramey
2021-02-10 2:31 ` Andrew Warkentin
2021-02-09 19:00 ` Jon Steinhart
2021-02-10 1:41 ` Larry McVoy
2021-02-10 1:52 ` George Michaelson
2021-02-10 2:24 ` Larry McVoy
2021-02-10 2:44 ` Dan Cross
2021-02-10 3:10 ` Larry McVoy
2021-02-10 20:03 ` Kevin Bowling
2021-02-10 2:57 ` Warner Losh
2021-02-10 2:56 ` Warner Losh
2021-02-10 3:02 ` Larry McVoy
2021-02-10 3:53 ` Andrew Warkentin
2021-02-09 11:34 ` Thomas Paulsen
2021-02-09 18:29 ` Nemo Nusquam
2021-02-09 8:30 Bakul Shah
2021-02-09 12:22 M Douglas McIlroy
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='CAMAV7_BVhZM3er=U3mM_EHq0tzDBkdp0Av=m8nCHgX=-y4T9_Q@mail.gmail.com' \
--to=jqcoffey@gmail.com \
--cc=lm@mcvoy.com \
--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).