The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: lm@mcvoy.com (Larry McVoy)
Subject: [TUHS] daemons are not to be exorcised
Date: Tue, 20 Mar 2018 20:20:58 -0700	[thread overview]
Message-ID: <20180321032058.GM25650@mcvoy.com> (raw)
In-Reply-To: <20180321023125.GC6850@thunk.org>

I can't +1 Ted's post enough.  I love simple, it's how I code, it's how
I design, I force everything through simple.  And Unix is like that, it's
simple.

But real life gets in the way, what Ted is saying is true.

Going forward, I wish that people tried to be simple as they tackle the 
more complicated problems we have.  I've watched stuff like the replacement
for inetd and init and just groaned.

On Tue, Mar 20, 2018 at 10:31:25PM -0400, Theodore Y. Ts'o wrote:
> On Mon, Mar 19, 2018 at 10:40:44PM -0600, Grant Taylor via TUHS wrote:
> > 
> > I think many people working on Linux are genuinely trying to make it better.
> > They just have no conceptual history to guide them.
> 
> There are also ways in which Unix is just simply deficient.  For
> example, take syslog.  It's simple, sure, but it has an extremely
> simple structure, and it's not nearly flexible enough for more
> sophisticated use cases.  As a result, *many* commercial Unix systems
> have tried reinventing an event logging system which had more structure.
> 
> Tru64 (OSF/1) had uerf.  AIX had eventlog.  Solaris had a structured
> event log as part of ILOM.  And, guess what?  syslog-ng came up with a
> set of extensions to add structure.  And sytemd has come up journald.
> 
> People can point at journald and laugh, and say, why so complicated?
> Why not the pure, simple Unix approach that was good enough for BSDh
> 4.3?  But I'll point out that *many* commercial Unix systems had
> decided that syslog was not good enough, and tried to invent their
> own.  Some that were pretty good, IMHO, and some that were a creeping
> horror.  (And your opinion may be different than mine about which were
> the creeping horror.  :-)
> 
> So it's not so simple.  Unix dind't have to deal with hardware which
> was hot-pluggable, for example.  How you handle devices that appear
> and disappear after boot with a static set of device nodes in /dev is
> another case where different commercial Unix systems have had their
> own divergent idea of how to solve the system --- and of course, some
> completely punted and coulthdn't deal with things like USB devices at
> all.
> 
> Early NetBSD and FreeBSD systems required a reboot when you inserted a
> PCMCIA card, and would crash if you ever tried to eject a PCMCIA card.
> You may not like Linux's solution for supporting these sorts of
> hardware --- but tell me: How would you hack V7 Unix to support them?  
> 
> 					- Ted

-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 


  reply	other threads:[~2018-03-21  3:20 UTC|newest]

Thread overview: 62+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-20  1:26 A. P. Garcia
2018-03-20  1:40 ` Dave Horsfall
2018-03-20  1:47 ` maxigas
2018-03-20  4:23 ` Grant Taylor
2018-03-20  4:24   ` Steve Nickolas
2018-03-20  4:40     ` Grant Taylor
2018-03-20  5:19       ` A. P. Garcia
2018-03-21  2:31       ` Theodore Y. Ts'o
2018-03-21  3:20         ` Larry McVoy [this message]
2018-03-21  4:30         ` Warner Losh
2018-03-21  4:52         ` Grant Taylor
2018-03-21  9:16         ` Jaap Akkerhuis
2018-03-22  0:18           ` Grant Taylor
2018-03-22  0:22             ` Larry McVoy
2018-03-22  2:25               ` [TUHS] syslog (was Re: daemons are not to be exorcised) Jeremy C. Reed
2018-03-21 13:59         ` [TUHS] daemons are not to be exorcised Clem Cole
2018-03-21 14:18           ` Paul Winalski
2018-03-21 15:15             ` Warner Losh
2018-03-21 15:45               ` Andy Kosela
2018-03-21 15:49                 ` Warner Losh
2018-03-22  0:28           ` Grant Taylor
2018-03-20  6:32   ` Andy Kosela
2018-03-20 12:31   ` Nemo
2018-03-20 17:48 ` Paul Winalski
2018-03-20 17:56   ` George Michaelson
2018-03-20 18:04     ` Dan Cross
2018-03-20 18:24       ` Bakul Shah
2018-03-20 18:46         ` Clem Cole
2018-03-20 19:10           ` Bakul Shah
2018-03-20 19:55             ` Dan Cross
2018-03-20 19:56           ` Tim Bradshaw
2018-03-20 21:12             ` A. P. Garcia
2018-03-20 21:40               ` Andy Kosela
2018-03-21  6:32             ` Wesley Parish
2018-03-20 20:14           ` Warren Toomey
2018-03-20 20:25             ` Paul Winalski
2018-03-20 21:15               ` Clem Cole
2018-03-20 21:09             ` Clem Cole
2018-03-20 18:53         ` Toby Thain
2018-03-20 19:24       ` Nemo Nusquam
2018-03-21 12:10     ` emanuel stiebler
2018-03-25 19:56     ` emanuel stiebler
2018-03-26  9:44       ` George Michaelson
2018-03-26 12:38         ` emanuel stiebler
2018-03-20 21:32 Nelson H. F. Beebe
2018-03-21 14:17 Noel Chiappa
2018-03-21 15:03 ` Clem Cole
2018-03-21 16:18   ` Arthur Krewat
2018-03-21 17:28     ` Paul Winalski
2018-03-21 17:33       ` George Michaelson
2018-03-21 17:50         ` Arthur Krewat
2018-03-21 19:49           ` A. P. Garcia
2018-03-21 19:37         ` Paul Winalski
2018-03-21 17:34       ` Larry McVoy
2018-03-22  2:24         ` Dave Horsfall
2018-03-21 17:39       ` WIlliam Cheswick
2018-03-21 17:52         ` Arthur Krewat
2018-03-21 17:56       ` Nemo
2018-03-21 18:01         ` Larry McVoy
2018-03-21 18:04       ` Dan Cross
2018-03-21 19:56         ` Clem Cole
2018-03-21 20:13           ` Paul Winalski

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=20180321032058.GM25650@mcvoy.com \
    --to=lm@mcvoy.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).