The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: bakul@bitblocks.com (Bakul Shah)
Subject: [TUHS] Charles Forsyth on putting Unix on a diet.
Date: Fri, 27 Oct 2017 19:00:44 -0700	[thread overview]
Message-ID: <20171028020100.26A50156E7D7@mail.bitblocks.com> (raw)
In-Reply-To: Your message of "Fri, 27 Oct 2017 23:51:12 +0200." <CALMnNGiKFq4UpdOxqoit1+24vakP=qH6bn+PsQxtApSQOVKOXg@mail.gmail.com>

On Fri, 27 Oct 2017 23:51:12 +0200 Andy Kosela <akosela at andykosela.com> wrote:
> We don't even have to look at M$.  We can look at our own backyard and find
> the same pattern.  UNIX in the 70s was small and simple, the same way Linux
> kernel was small and simple in the early 90s.  Now it is a bloated,
> fat monster.
> 
> It seems that it is very hard to avoid bloat in the software world in the
> long run.  Most people don't care, but the original UNIX and C, Plan 9 and
> Go projects could be one of the few I can think of that really cared about
> minimalism.  It is interesting to note that they were built by the
> very same group of people.
> 
> Minimalism is the main word here.  If you read personal website of Charles
> Forsyth then you will notice he mentions it explicitly as his "overarching
> theme".  That is the secret key to beauty and elegance in the software
> world.

Minimalism as a goal has been long lost in the Unix world.
(Well, everywhere but at least Unix started out lean). Even
the generic FreeBSD kernel is 20MB or so (txtsize).  When you
add in all the loadable kernel modules, it is about 52MB[1].
Linux is of course more bloated. Plan9 is quite lean but other
than a few diehard fans no one uses it. Worse, its leanness
lessons have not been learned by any other OS.

I wish there was a way to evolve plan9 into a modern Unix.
Making an existing modern Unix diet into a lean OS is close to
impossible.

A unix kernel boils down to a few subsystems: device drivers +
device switch, scheduling, VM, networking and network switch,
filesystems + filesystem switch, interrupt handling, process
management. Some graphics support. A bunch of this can be
pushed out of the kernel without much loss of efficiency.  And
may be the original design decisions of Unix need to be
revisited for 21st century hardware.

A comment on Charles Forsyth's paper. I saw most of his work
as essentially re-engineering (or perhaps just engineering).
This is actually pretty important and something we don't seem
to pay a lot of attention to. It is improving the fit and
finish of parts so that they fit well together. It is making
it easy to take things apart or put them together well.  It is
making diagnosis and repair easy.  Make reproducibiliy easy
etc. But we don't have a clear idea of what metrics to focus
on that will help this engineering.  Performance? Number of
lines of code?  Latency?  Energy used?  Maintainability?
Extensibility?  Curiously, what is most tangible to me not
what can be measured but a sense of aesthetics.

Bakul

[1] FreeBSD has some strange things: if_bxe.ko (for the Qlogic
10GBe card) is 2+ MB (larger than zfs.ko)! May be due to
proprietary binary blobs? The next after zfs is a driver for
another Qlogic card.


  parent reply	other threads:[~2017-10-28  2:00 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-27 10:36 Noel Chiappa
2017-10-27 13:03 ` Clem Cole
2017-10-27 13:23   ` Steve Nickolas
2017-10-27 21:51     ` Andy Kosela
2017-10-27 23:04       ` Larry McVoy
2017-10-27 23:15         ` Steve Simon
2017-10-27 23:39           ` Tim Bradshaw
2017-10-28  2:00       ` Bakul Shah [this message]
2017-10-28  2:34         ` Lyndon Nerenberg
2017-10-28  2:42           ` Lyndon Nerenberg
2017-10-28  6:38           ` Bakul Shah
2017-10-27 21:43   ` Dave Horsfall
  -- strict thread matches above, loose matches on Subject: below --
2017-10-28 13:11 Norman Wilson
2017-10-27 21:30 Norman Wilson
2017-10-27 22:49 ` Chris Torek
2017-10-26 14:57 Doug McIlroy
2017-10-26 22:07 ` George Michaelson
2017-10-25  2:51 Dan Cross
2017-10-25  3:14 ` Larry McVoy
2017-10-26 17:27 ` Larry McVoy
2017-10-26 22:12   ` George Michaelson
2017-10-27  3:49     ` Steve Nickolas
2017-10-27  6:55       ` arnold
2017-10-27  7:30   ` Derek Fawcus
2017-10-27  9:44     ` David Arnold

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=20171028020100.26A50156E7D7@mail.bitblocks.com \
    --to=bakul@bitblocks.com \
    /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).