[TUHS] daemons are not to be exorcised

[Clem Cole]

On Tue, Mar 20, 2018 at 10:31 PM, Theodore Y. Ts'o <tytso at mit.edu> 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.

​Actually I want to +1 for both of you.​

​I think you might be closer to agreeing than disagreeing and frankly the
issue is the paradox that we live - which is called a 'success problem.'​
The magic behind Ken and Dennis's work was the simple elegance of the UNIX
ideas and practical implements of those ideas  that I think we on this list
admire.   With 'modest' hardware, the produced an amazing functional system
- in fact one way more functional for their target (programmers) than their
contemporary systems from ''commercial' vendors.

But at the time ... we (programmers) were willing to give up some
'features' of those commercial systems that we did not value in return for
a system that made more sense to us. But time did not stop and our needs as
users and what we considered 'ante' to play the game much less 'jacks to
open', has changed.

As I point out elsewhere, as much as I pine for the simplicity of 6th and
7th editions; I believe that UNIX implementations got fat and bloated as it
grew up, I would not be able to use same today as my day to day system [my
favorite example of 'baddness' of an UNIX implementation was the SVR3 boot
loader being so much larger than the V6 kernel - IIRC it was 2-3 times the
text and data size].   That said, my own requirements for a minimal system,
as have others on this list, require features that just were not there in
those systems (Ted's need for a system logger to support for pluggable HW,
much less basic support for networking, web browsing, better email, more
languages choices, *etc*.). [I personally use a Mac as my 'primary' system,
but ssh/vnc *etc* to program on Linux systems daily for work].

Larry rightly mentions 'clean and simple' as a huge part of the 'Unix
philosophy'  - in fact, I will take that farther to say it was the greatest
gift of UNIX (the system idea as opposed the implementation).  The key
point is that with 'modest hardware' of the day and the limits that said
hardware forced, simple and clean was required to get the job done.  UNIX
(the idea) gave us a way to solve complex problems without a lot of the
goop that other systems had to get the same or better results.

And here comes the hard part ...   as the Unix implementations moved from
the 16 bit resource constrained system to the VAX and the unburdening of
those restrictions unleashed a new way to build tools that worked with UNIX
as a system (the idea).   Pike's railing on 'cat -v harmful' said it all.
 Basically, we forgot what was 'UNIX' - in fact we eventually started to
argue about it and have not stopped since ;-)

Frankly, my sisters and brothers at UCB were some of the worst offenders of
the bloat, because they could be.  I've always said as an example, if Eric
had not put the system SMTP send/recv daemon inside of sendmail, the
sendmail tool would never have spread the way it did.   Under the 'pure'
Unix philosophy,  'smptd' really should have been a seperate program [like
it was in the original BBN networking code] and the header
rewriting system, really should have been some other program; and probably
a separate daemon for local delivery   *i.e.* small tools to do one job.
Yet it was easier for him to combine them at the time and he could, so he
did.    He first added the SMTP protocol to the BSD delivery agent
(delivermail), and as the header wars started hacked on the program to do
rewriting.   The morphed as we know and the rewriting portion quickly
dominated the tool.

The key is that the combined result was a useful tool for BSD, and made
available with BSD as the mail system.   It was 'grandfathered' in at most
sites that did not need to do the rewriting, because it solved the SMTPD
problem well.  Then they discovered the rewrite features and rest -- well
we all know what happened.   Did other 'better' mail agents appear for UNIX
and get used in many places, sure, but for whatever reasons - never
displaced it as widely.

But the fact remains, sendmail is hardly a 'simple' nor 'elegant'.  I
personally believe that if Pressotto's email system for the V8 had been the
'Berkeley' mail (which did follow the elegant and simple 'UNIX' design), we
might have seen a different history (the Morris worm for instance, would
have been much less likely).

Now, I ask you did we trash BSD UNIX because on of sendmail?  Hardly, some
people loved sendmail; others loath it and did something different. The
*BSD and Linux of today are just examples same issue at the system level.
Neither is better, neither is good or bad.  The problem is we have these
features and we are less constrained, so 'modern' programmers rarely have
to think in the same terms that Ken and Dennis, so very do.

Like Grant, I worry that many young programmers do not have enough the the
history behind them (trying reading the questions on Quora if you want some
examples of this issue).  Ken and Dennis were forced to be clean and
simple, few of today's programs even consider it. But, that said, we do
need to remember to keep UNIX the ideas and specific implementations
distinct.  V7 is deficient for today's world - as Larry says - real life
gets in the way.

Could/Should linux (or *BSD) go on a diet?   Probably, the question is can
you do that reasonably and be successful.  Plan 9 I think was Ken's
attempt.   For whatever reason, it did not take off ( I think the licensing
at the time of its birth cause much of that - i.e. timing is everything).
 Maybe Google or someone else will be able to do something like that.   If
it happens, I suspect, it is not going to be Linux because it has already
(like *BSD) picked up a following that is not going to give up many of the
'features' that make it useful and 'better.'  Clay Christiansen tells is
this in his theory, just as Linux disrupted the entrenched *BSD.

For me, the key point for us, is can be teach the next generation what the
core idea of UNIX is - simple and elegant.   What we need to continue to
learn and model the ideas and then apply the appropriately.  Then whatever
'UNIX' becomes as the current implementation, be it Linux, Plan9++ or a
RustOS, we get to keep the core of the system we love and admire, are able
to move on to what in 'real life' fits.




On another topic, as for the arguments about syslogd - the history is that
sendmail had nothing to do it.  VMS was more the model/reason.  You need to
remember, CSRG was under great pressure to build into BSD features that
DoD/Arpa community that was funding them desired.   Their was huge
pressure at the time to use a commercial system and in fact many in Arpa
wanted to be out of the computer business, *i.e. *felt that
commercial firms should be doing that work.  The primary 'competition' was
VMS for the VAX, and at the time CSRG has a list of 'commercial OS
features' that systems like TOPS-10, VMS, VM/CMS *etc.* supported that were
slowly being added.

Clem





ᐧ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180321/09beb7d7/attachment.html>