[TUHS] [tuhs] The Unix shell: a 50-year view

Clem Cole clemc at ccc.com
Wed Jul 7 02:05:04 AEST 2021


On Mon, Jul 5, 2021 at 3:16 AM Tomasz Rola <rtomek at ceti.pl> wrote:

> I have misread you then. I suppose the main problem that Unix solved
> fifty years ago was the need for OS on a not very big (but cheap!)
> machine. There were quite a few such systems and various such 16,
> 18-bit machines. So Unix was one of many, and what made it successful
> was rewriting in C (I think I have read about it somewhere). Various
> guys ported C compiler to their machines and to test it, they compiled
> Unix sources (I am sure I have read about this). So as C gained
> popularity, so did Unix gained popularity and C was the prog lang of
> Unix, thus with every new Unix install C gained even more popularity.


Ouch!!! This is so much important that you have missed in this statement,
as this is a great example of not seeing the forest because of all the
trees.  You are right that C and UNIX's success was intertwined but I think
you are missing the drivers for that.   They were successful because of
other things and because they were successful, we have them today.

So, Tomasz let me try again .. as an old f*rt that lived this era and
played a role in it.  Wrote some of the memos that 'justified UNIX instead
of a commercial solution, *etc*.'  UNIX was hardly a slam and it could have
easily not been successful, a lot of things had to occur for the result we
see today.

As I have mentioned before much of this topic has been discussed here
before.  In fact, I wrote and published a much longer explanation of all of
this is in a paper I published a few years ago for a French group looking
at how computers and UNIX affected society:  If can be found at:
http://technique-societe.cnam.fr
/colloque-international-unix-en-france-et-aux-etats-unis-innovation-diffusion-et-appropriation--945215.kjsp
  or send me an e-mail privately I can send you a PDF [note its formatted
for A4 paper, but will print on US letter successfully].

First ignore UNIX, Multics, or anything else.  Please concentrate on the
systems that IBM, BUNCH, DG, and DG had in the 1960s and 1970s.   An IBM
term was 'access method.'   Every program has to use a specifically defined
scheme to read the data:  ISAM/VSAM or in DEC's case RMS.  One of my
friends once said of RMS, it was not so bad that RMS had 256 to a thousand
optional features on each QIO call, but Culter had to check for each one of
them sequentially.  Yecch!!!!!

Unix as a programming system was a real breath of fresh air -- just
treating files as an unstructured bag of bits and the program figure out
how to deal with them was giant and very much against the thought of the
times.  And if you used ASCII, not a binary format, it means that humans
might even be able to debug it the system using the data!!  Don't write
huge programs to solve every possible problem you encounter with your
system.  Instead, write little ones that can be hooked together and reuse
the different smaller programs.  Build a library of complete simple
programs.

BTW:  UNIX was not the only system in those days exposing these types of
ideas.  I believe that it was Bert Sullivan (Ivan's brother) who built a
system at Lincoln labs that using what IIRC was Simula objects, that could
hook up small things together to manipulate something larger - not unlike
Doug's pipe ideas.   This stuff gave way to the later OOB programming
movement [and I would suggest much of the C++ we live with today too, but I
digress].

The idea of lots of little programs that cooperate with each other is not
what IBM and the like wanted/was providing.  They were selling closed
'solutions' complete SW systems ("walled gardens" controlled by them or
their programming minions) and yes needed the big iron they sold.  Note
the IBM 'solutions were not sold to engineers, their products were sold on
the golf course to the 'managers' of what we know call IT shops.

FWIW:  DEC was in a strange position.  It had come from serving the
engineers, but systems like VMS have slowly become more and more
interesting to the enterprise and that was a much more lucrative market.
 Remember what did Charlie Brown (AT&T's CEO) do after they were broken up
-- he wants to go after IBM!!!  AT&T's new marketing folks even change the
name of the codebase from the 'Programmers Workbench' to 'System III'
because they are afraid 'programmer' will not play well in enterprise sales.

The point here is that the 'enterprise type of system is really different
than engineers at BTL, Lincoln Labs, much less in the research campuses of
important universities.

The important thing is that the latter group (not enterprise) did not have
as much money but was a completely different population.   UNIX is 100% a
'Christiansen style Disruption'  ( read his book completely if you have
not, please).  It's a 'lessor technology,' running on smaller equipment,
targeting a new and different consumer who does not care that it is 'not as
good' as the established products.  If you compare UNIX to IBM's OS or VMS
for that matter, UNIX does not have the 'features' that are valued by the
'enterprise market.'

Ken/Dennis, *et al*, clearly do not care -- they were building something
they (the engineers) needed and wanted (thankfully).  And yes it had to run
on modest hardware because that is what they could afford and had access
to.  But because since the HW was modest, that forces a mindset of what are
we really doing on the SW?  How can we do it effectively.  The designers
are asking an important research question? *Maybe some of these other
schemes are not necessary*.

You are correct the C grew because of UNIX, but you kind of have it
backward. I'm a perfect example of what happened.  These new
microprocessors from Intel/Zilog/Moto/MOS Tech became available to us
(engineers mind you).  Hey, I was at CMU in the mid-1970s, I even had
access to the BLISS sources, but most people did not.  A BLISS cross
compiler binary cost $5K per CPU!!! And by the time what would become the
M68K shows up (I had access to the experimental chip that was not numbered)
I was at Tektronix and I then did not have BLISS sources.  *But I did have
the UNIX sources and those included a C compiler that dmr had written for
the PDP-11.   So I retargeted it.*   Same story with Steve Ward's crew in
the RTS at MIT, although they used both dmr and Steve's compilers.   I know
that same song played again at Purdue, also in UNSW, as well in the EU in a
couple of places if you look on the USENIX tapes.

It was *not that we tested our compiler by porting UNIX*.  We wanted a *C
compiler for whatever* program/project we had for these new devices.  Most
of the time we cross-compiled on our local UNIX box, of course. This was
true of the C8086 and Z80 tools I had in 1978/79.  But we all ran it on our
PDP-11s or later Vaxen.   It takes a few years before 'JAWS' start and we
see all the UNIX ports, but the C *vs.* Pascal wars were well underweight
by that time, and the UNIX vs. VMS vs. TOPS vs. Tenex vs. VM/CMS vs. TSS
vs. MTS, *etc*. wars had already become the stuff of legend.

The key point is that UNIX was inexpensive and worked on modest hardware.
Yes C came with it and that is why I think we use it not BLISS, BCPL, or
some flavor of PLx today.

It's simply a Christiansen style Disruption Technology -- something valued
by a new market that grew faster than the old market.   But the problem we
have with UNIX is as it displaced the old market, the old ideas/behaviors
of the other players that survived started to added back into the new
system their old scheme (with new names mind you -- but the same effect).

i.e. those not willing to learn from the errors and why success occurred in
history will repeat the errors of before.  Sadly, I have personally lived
this statement multiple times in my professional employment.
ᐧ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210706/7ce42ec4/attachment-0001.htm>


More information about the TUHS mailing list