From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HTML_FONT_LOW_CONTRAST,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 30652 invoked from network); 6 Jul 2021 16:06:42 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 6 Jul 2021 16:06:42 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id 80D649CA2E; Wed, 7 Jul 2021 02:06:40 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 5B7BF9C9F2; Wed, 7 Jul 2021 02:05:40 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=fail reason="signature verification failed" (1024-bit key; unprotected) header.d=ccc.com header.i=@ccc.com header.b="bOEjH2v8"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id 29F4A9C9F2; Wed, 7 Jul 2021 02:05:36 +1000 (AEST) Received: from mail-qt1-f179.google.com (mail-qt1-f179.google.com [209.85.160.179]) by minnie.tuhs.org (Postfix) with ESMTPS id A53EE9C9F0 for ; Wed, 7 Jul 2021 02:05:31 +1000 (AEST) Received: by mail-qt1-f179.google.com with SMTP id f13so14781252qtb.6 for ; Tue, 06 Jul 2021 09:05:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ccc.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=SD7zHRuHwINGtsCXHjOgOXGyYYlLZX0kHQsZvyD3Kh4=; b=bOEjH2v8+5UxXPN/eWDrEa02zLK7H79uB+nVEidzJbVoDzI2MKNZv8mSgGvdhDwxwP SL+n/9vcGOETvB0osvs4gH9HU9NoV9XDYAYaqeLxbriSWWcRcCyzOFN3+KoNrmxxO/V8 oM0ZVCVUJrCxSNorm55XMk8a3GMtp59Bdhulk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=SD7zHRuHwINGtsCXHjOgOXGyYYlLZX0kHQsZvyD3Kh4=; b=FYdDVONsNS0LjLTv6DfKlHwkbgMcP59irHm0cyw2n1B67VtPGP+kEIkWzzhvaCFFNd duFglXZZxvkNlWqEG+h/WFyjdMz9d5cALA1Hxt19x9GlrQ1xOgcrwGE4lnmzy973RgzG NFd8iLKEGPeaigdytvW+2g3nCI85LWZJXjClqywZEhN1yRvYbwKP9gCtg7s8NC6EwguE YnwxqrYO1rlAZOfpvMah4JprXeiSB5zn8BOpFpE631VJ5fuinI1d9mclYphA7DQMI7qn IP+dgWQZVC7nLPUxMAHWwjxq7tsLP0rTigtcrnZ2oQB7BTBGO4iG9JS3de5rGP3kuKet ogww== X-Gm-Message-State: AOAM533ojL/TCEdFqbnvYLJ+ptgZnBhFO70P4hBqNw+Zei3FgrgeVlqx QUZGDbjjx3zWMJ+DaOgSFwcDVdtJxNJE+RMetZcBDg== X-Google-Smtp-Source: ABdhPJwm2czHZELsm1hcmJmZBRTSI0BaXVehgFSvs9w5/5zc66oe1k46BNUqOEV/x8aM3vJtHVaJFFoWb4XhI9wv6Po= X-Received: by 2002:a05:622a:1988:: with SMTP id u8mr17956724qtc.354.1625587530533; Tue, 06 Jul 2021 09:05:30 -0700 (PDT) MIME-Version: 1.0 References: <20210702213648.GW817@mcvoy.com> <396911b232bae5938068a14fe0f7181e@firemail.de> <20210704004757.GB24671@tau1.ceti.pl> <20210705071450.GA12885@tau1.ceti.pl> In-Reply-To: <20210705071450.GA12885@tau1.ceti.pl> From: Clem Cole Date: Tue, 6 Jul 2021 12:05:04 -0400 Message-ID: To: Tomasz Rola Content-Type: multipart/alternative; boundary="0000000000004f228d05c676974d" Subject: Re: [TUHS] [tuhs] The Unix shell: a 50-year view X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: tuhs@minnie.tuhs.org Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" --0000000000004f228d05c676974d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Jul 5, 2021 at 3:16 AM Tomasz Rola 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-diffusi= on-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. =E1=90=A7 --0000000000004f228d05c676974d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On M= on, Jul 5, 2021 at 3:16 AM Tomasz Rola <rtomek@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=C2=A0you have missed in this statement, as this is a gr= eat example of not seeing the forest because of all the trees.=C2=A0 You ar= e=C2=A0right=C2=A0that C and UNIX's=C2=A0success was intertwined=C2=A0b= ut I think you are missing the drivers for that.=C2=A0 =C2=A0They were succ= essful because of other things and because they were successful, we have th= em today.

So, Tomasz let me try again .. as an old f*rt that lived = this era and played a role in it.=C2=A0 Wrote some of the memos that 'j= ustified UNIX instead of a commercial solution,=C2=A0etc.'=C2=A0= 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 ment= ioned before=C2=A0much of this topic has been discussed here before.=C2=A0 = In fact, I wrote and published a=C2=A0much longer explanation of all of thi= s is in a paper I published a few years ago for a French group looking at h= ow computers and UNIX affected society:=C2=A0 If can be found at:=C2=A0=C2= =A0http://technique-societe.<= span class=3D"gmail-il">cnam.fr/coll= oque-international-unix-en-france-et-aux-etats-unis-innovation-diffusion-et= -appropriation--945215.kjsp=C2=A0=C2=A0or send = me an=C2=A0e-mail=C2=A0privately I can send you a PDF [note its formatted f= or A4 paper, but will print on US letter successfully].

First ignor= e UNIX, Multics, or anything else.=C2=A0 Please concentrate on the systems = that IBM, BUNCH, DG, and DG had in the 1960s and 1970s.=C2=A0 =C2=A0An IBM = term was 'access method.'=C2=A0 =C2=A0Every program has to use a sp= ecifically defined scheme to read the data:=C2=A0 ISAM/VSAM or in DEC's= case RMS.=C2=A0 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 h= ad to check for each one of them sequentially.=C2=A0 Yecch!!!!!

Uni= x as a programming system was a real breath of fresh air -- just treating f= iles as an unstructured bag of bits and the program figure out how to deal = with them was=C2=A0giant and very much against the thought of the times.=C2= =A0 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!!=C2=A0 Don't write = huge programs to solve every possible problem you=C2=A0encounter with your = system.=C2=A0 Instead, write little ones that can be hooked together and re= use the different smaller programs.=C2=A0 Build a library of complete simpl= e programs.

BTW:=C2=A0 UNIX was not the only system in those days e= xposing these types of ideas.=C2=A0 I believe that it was Bert Sullivan (Iv= an's brother) who built a system at Lincoln labs that using what IIRC w= as Simula objects, that could hook up small things together to manipulate s= omething larger - not unlike Doug's pipe ideas.=C2=A0 =C2=A0This 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=C2=A0idea of l= ots=C2=A0of little programs that cooperate with each other is not what IBM = and the like wanted/was providing.=C2=A0 They were selling closed 'solu= tions' complete SW systems ("walled gardens" controlled by th= em or their programming minions) and yes needed the big iron they sold.=C2= =A0 Note the=C2=A0IBM 'solutions=C2=A0were not sold to engineers, their= products were sold on the golf course to the 'managers' of what we= know call IT shops.

FWIW:=C2=A0 DEC was in a strange position.=C2= =A0 It had come from serving the engineers, but systems like VMS have slowl= y become=C2=A0more and more interesting to the enterprise and that was a mu= ch more lucrative market.=C2=A0 =C2=A0Remember what did Charlie Brown (AT&a= mp;T's CEO) do after they were broken up -- he wants to go after IBM!!!= =C2=A0 AT&T's new marketing folks even change the name of the codeb= ase=C2=A0from the 'Programmers Workbench' to 'System III' b= ecause they are afraid 'programmer' will not play well in enterpris= e sales.

The=C2=A0point here is that the 'enterprise=C2=A0type = of system is really different than engineers at BTL, Lincoln Labs, much les= s 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.=C2=A0 =C2=A0UNIX is 100% a '= ;Christiansen style Disruption'=C2=A0 ( read his book completely if you= have not, please).=C2=A0 It's a 'lessor technology,' running o= n smaller equipment, targeting a new and different consumer who does not ca= re that it is 'not as good' as the established products.=C2=A0=C2= =A0If you compare UNIX to IBM'= ;s OS or VMS for that matter, UNIX does not have the 'features' tha= t are valued by the 'enterprise market.'

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

<= /font>
You are correct the C grew because o= f UNIX, but you kind of have it backward. I'm a perfect example of what= happened.=C2=A0 These new microprocessors from Intel/Zilog/Moto/MOS Tech b= ecame available to us (engineers mind you).=C2=A0 Hey, I was at CMU in the = mid-1970s, I even had access to the BLISS sources, but most people did not.= =C2=A0 A BLISS cross compiler binary=C2=A0cost $5K per CPU!!! And by the ti= me what would become the M68K shows up (I had access to the experimental ch= ip that was not numbered) I was at Tektronix and I then did not have BLISS = sources.=C2=A0 But I did have the UNIX sources and those included a C co= mpiler that=C2=A0dmr had written for the PDP-11.=C2=A0 =C2=A0So I retargete= d it.=C2=A0 =C2=A0Same story with=C2=A0Steve Ward's crew in the=C2= =A0RTS at MIT, although they used both dmr and Steve's compilers.=C2=A0= =C2=A0I 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.=C2=A0 W= e wanted a C compiler for whatever program/project we had for these = new devices.=C2=A0 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.=C2= =A0 But we all ran it on our PDP-11s or later Vaxen.=C2=A0 =C2=A0It takes a= few years before 'JAWS' start and we see all the UNIX ports, but t= he C vs. Pascal wars were well underweight by that time, and the UNI= X vs. VMS vs. TOPS vs. Tenex vs. VM/CMS vs. TSS vs. MTS, etc. wars h= ad already become the stuff of=C2=A0legend.

The key point is that U= NIX was inexpensive and worked on modest hardware.=C2=A0 Yes C came with it= and that is why I think we use it not BLISS, BCPL, or some flavor of PLx t= oday.

It's simply a=C2=A0Christiansen style Disruption Technology -- something valued by a new m= arket that grew faster than the old market.=C2=A0 =C2=A0But the problem we = have with UNIX is as it displaced the old market, the old ideas/behaviors o= f the other players that survived started to added back into the new system= their old=C2=A0scheme (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=C2=A0errors of before.= =C2=A0 Sadly, I have personally lived this statement multiple times in my p= rofessional employment.
3D""=E1=90=A7
--0000000000004f228d05c676974d--