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