The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: Clem Cole <clemc@ccc.com>
To: "Theodore Y. Ts'o" <tytso@mit.edu>
Cc: The Eunuchs Hysterical Society <tuhs@tuhs.org>,
	Noel Chiappa <jnc@mercury.lcs.mit.edu>
Subject: Re: [TUHS] core
Date: Mon, 18 Jun 2018 10:56:21 -0400	[thread overview]
Message-ID: <CAC20D2MfPSYDhgUFKBU0rJAtbv8mE611eqoH1+yQeCKQpe2riA@mail.gmail.com> (raw)
In-Reply-To: <20180617173341.GB31064@thunk.org>

[-- Attachment #1: Type: text/plain, Size: 3493 bytes --]

On Sun, Jun 17, 2018 at 1:33 PM, Theodore Y. Ts'o <tytso@mit.edu> wrote:

> On Sat, Jun 16, 2018 at 09:37:16AM -0400, Noel Chiappa wrote:
> > I can't speak to the motivations of everyone who repeats these stories,
> but my
> > professional career has been littered with examples of poor vision from
> > technical colleagues (some of whom should have known better), against
> which I
> > (in my role as an architect, which is necessarily somewhere where
> long-range
> > thinking is - or should be - a requirement) have struggled again and
> again -
> > sometimes successfully, more often, not....
> >
> > Examples of poor vision are legion - and more importantly, often/usually
> seen
> > to be such _at the time_ by some people - who were not listened to.
>
> To be fair, it's really easy to be wise to after the fact.  Let's
> start with Unix; Unix is very bare-bones, when other OS architects
> wanted to add lots of features that were spurned for simplicity's
> sake.

Amen brother.  I refer to this as figuring out and understanding what
matters and what is really just window dressing.​  That is much easier to
do after the fact and for those of us that lived UNIX, we spent a lot of
time defending it.  Many of the 'attacks' were from systems like VMS and
RSX that were thought to be more 'complete' or 'professional.'


> Or we could compare X.500 versus LDAP, and X.400 and SMTP.
>
​Hmmm. I'll accept X.500, but SMTP I always said was hardly 'simple' -
although compared to what it replaced (FTPing files and remote execution)
is was.​

​




>
> It's easy to mock decisions that weren't forward-thinking enough; but
> it's also really easy to mock failed protocols and designs that
> collapsed of their own weight because architects added too much "maybe
> it will be useful in the future".
>
​+1
​


>
> ​...
>  Adding a database into the kernel and making it a
> fundamental part of the file system?  OK, stupid?  How about adding
> all sorts of complexity in VMS and network protocols to support
> record-oriented files?
>
​tjt once put it well:  'It's not so bad that RMS has 250-1000 options, but
some has to check for each them on every IO.'



>
> Sometimes having architects being successful to add their "vision" to
> a product can be worst thing that ever happened to a operating sytsem
> or, say, the entire OSI networking protocol suite.
>
​I'll always describe it as having 'good taste.'  And part of 'good taste'
is learning what really works and what really does not.​  BTW: having good
taste in one thing does necessarily give you license in another area.  And
I think that is a common issues.   "Hey were were successfully here, we
must be genius..."   Much of DEC's SW as good, but not all of it as an
example.  Or to pick on my own BSD expereince, sendmail is a great example
of something that solved a problem we had, but boy do I wish Eric had not
screwed the SMTP Daemon into it ....



>
> > So, is poor vision common? All too common.
>
> Definitely.  The problem is it's hard to figure out in advance which
> is poor vision versus brilliant engineering to cut down the design so
> that it is "as simple as possible", but nevertheless, "as complex as
> necessary".

​Exactly...   or as was said before:  *as simple as possible, but not
simpler.​*

*​  *But I like to add that understanding 'possible' is different from 'it
works.'* ​*
ᐧ

[-- Attachment #2: Type: text/html, Size: 6603 bytes --]

  parent reply	other threads:[~2018-06-18 14:57 UTC|newest]

Thread overview: 73+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-16 13:37 Noel Chiappa
2018-06-16 18:59 ` Clem Cole
2018-06-17 12:15 ` Derek Fawcus
2018-06-17 17:33 ` Theodore Y. Ts'o
2018-06-17 19:50   ` Jon Forrest
2018-06-18 14:56   ` Clem Cole [this message]
2018-06-18 12:36 ` Tony Finch
  -- strict thread matches above, loose matches on Subject: below --
2018-06-21 22:44 Nelson H. F. Beebe
2018-06-21 23:07 ` Grant Taylor via TUHS
2018-06-21 23:38   ` Toby Thain
2018-06-21 17:40 Noel Chiappa
2018-06-21 17:07 Nelson H. F. Beebe
2018-06-21 13:46 Doug McIlroy
2018-06-21 16:13 ` Tim Bradshaw
2018-06-20 20:11 Doug McIlroy
2018-06-20 23:53 ` Tim Bradshaw
2018-06-19 12:23 Noel Chiappa
2018-06-19 12:58 ` Clem Cole
2018-06-19 13:53   ` John P. Linderman
2018-06-21 14:09 ` Paul Winalski
2018-06-19 11:50 Doug McIlroy
     [not found] <20180618121738.98BD118C087@mercury.lcs.mit.edu>
2018-06-18 21:13 ` Johnny Billquist
2018-06-18 17:56 Noel Chiappa
2018-06-18 18:51 ` Clem Cole
2018-06-18 14:51 Noel Chiappa
2018-06-18 14:58 ` Warner Losh
     [not found] <mailman.1.1529287201.13697.tuhs@minnie.tuhs.org>
2018-06-18  5:58 ` Johnny Billquist
2018-06-18 12:39   ` Ronald Natalie
2018-06-17 21:18 Noel Chiappa
2018-06-17 17:58 Noel Chiappa
2018-06-18  9:16 ` Tim Bradshaw
2018-06-18 15:33   ` Tim Bradshaw
2018-06-17 14:36 Noel Chiappa
2018-06-17 15:58 ` Derek Fawcus
2018-06-16 22:57 Noel Chiappa
     [not found] <mailman.1.1529175600.3826.tuhs@minnie.tuhs.org>
2018-06-16 22:14 ` Johnny Billquist
2018-06-16 22:38   ` Arthur Krewat
2018-06-17  0:15   ` Clem cole
2018-06-17  1:50     ` Johnny Billquist
2018-06-17 10:33       ` Ronald Natalie
2018-06-20 16:55       ` Paul Winalski
2018-06-20 21:35         ` Johnny Billquist
2018-06-20 22:24           ` Paul Winalski
2018-06-16 13:49 Noel Chiappa
2018-06-16 14:10 ` Clem Cole
2018-06-16 14:34   ` Lawrence Stewart
2018-06-16 15:28     ` Larry McVoy
2018-06-16 14:10 ` Steve Nickolas
2018-06-16 14:13   ` William Pechter
2018-06-16 12:58 Doug McIlroy
2018-06-20 11:10 ` Dave Horsfall
2018-06-16 12:51 Noel Chiappa
2018-06-16 13:11 ` Clem cole
2018-06-15 15:25 Noel Chiappa
2018-06-15 23:05 ` Dave Horsfall
2018-06-15 23:22   ` Lyndon Nerenberg
2018-06-16  6:36     ` Dave Horsfall
2018-06-16 19:07       ` Clem Cole
2018-06-18  9:25         ` Tim Bradshaw
2018-06-19 20:45           ` Peter Jeremy
2018-06-19 22:55             ` David Arnold
2018-06-20  5:04               ` Peter Jeremy
2018-06-20  5:41                 ` Warner Losh
2018-06-15 11:19 A. P. Garcia
2018-06-15 13:50 ` Steffen Nurpmeso
2018-06-15 14:21 ` Clem Cole
2018-06-15 15:11   ` John P. Linderman
2018-06-15 15:21     ` Larry McVoy
2018-06-16  1:08   ` Greg 'groggy' Lehey
2018-06-16  2:00     ` Nemo Nusquam
2018-06-16  2:17     ` John P. Linderman
2018-06-16  3:06     ` Clem cole
2018-06-20 10:06 ` Dave Horsfall

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=CAC20D2MfPSYDhgUFKBU0rJAtbv8mE611eqoH1+yQeCKQpe2riA@mail.gmail.com \
    --to=clemc@ccc.com \
    --cc=jnc@mercury.lcs.mit.edu \
    --cc=tuhs@tuhs.org \
    --cc=tytso@mit.edu \
    /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).