From arnold at skeeve.com  Fri Mar  2 00:20:41 2018
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Thu, 01 Mar 2018 07:20:41 -0700
Subject: [TUHS] Some articles about early usenet
Message-ID: <201803011420.w21EKf4L021550@freefriends.org>

https://www.cs.columbia.edu/~smb/blog//2018-02/2018-02-23.html

By Steve Bellovin on "Usenet, Authentication, and Engineering (or:
Early Design Decisions for Usenet)"

http://www.newsweek.com/april-fools-day-april-fools-kremvax-kremlin-soviet-union-usenet-piet-beertema-318451

On the Kremvax April Fools joke.

Arnold


From beebe at math.utah.edu  Fri Mar  2 09:28:18 2018
From: beebe at math.utah.edu (Nelson H. F. Beebe)
Date: Thu, 1 Mar 2018 16:28:18 -0700
Subject: [TUHS]  new paper comparing Unix kernel designs
Message-ID: <CMM.0.96.0.1519946898.beebe@gamma.math.utah.edu>

A new paper comparing Unix kernel designs was published earlier today:

	Stergios Papadimitriou and Lefteris Moussiades
	Mac OS versus FreeBSD: A Comparative Evaluation
	[IEEE] Computer 52(2), 44--53, February 2018
	https://doi.org/10.1109/MC.2018.1451648

Despite the title, GNU/Linux also is included in the comparisons.  The
abstract is:

>> ...
>> FreeBSD (an open source Unix-like OS) and Apple's Mac OS use similar
>> BSD functionality but take different approaches. FreeBSD implements a
>> traditional compact monolithic Unix kernel, whereas Mac OS builds the
>> BSD Unix functionality on top of the Mach microkernel. The authors
>> provide an in-depth technical investigation of both approaches.
>> ...

Our fellow list member Larry McVoy, and his lmbench suite, are
mentioned in the article, along with results of that suite.

There are about 200 numbers in the two large tables of performance
measurements, and while many are comparable across operating systems,
there are some benchmarks that show up to a 40x difference between
systems on the same hardware.

-------------------------------------------------------------------------------
- Nelson H. F. Beebe                    Tel: +1 801 581 5254                  -
- University of Utah                    FAX: +1 801 581 4148                  -
- Department of Mathematics, 110 LCB    Internet e-mail: beebe at math.utah.edu  -
- 155 S 1400 E RM 233                       beebe at acm.org  beebe at computer.org -
- Salt Lake City, UT 84112-0090, USA    URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------


From dave at horsfall.org  Fri Mar  2 09:44:22 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Fri, 2 Mar 2018 10:44:22 +1100 (EST)
Subject: [TUHS] new paper comparing Unix kernel designs
In-Reply-To: <CMM.0.96.0.1519946898.beebe@gamma.math.utah.edu>
References: <CMM.0.96.0.1519946898.beebe@gamma.math.utah.edu>
Message-ID: <alpine.BSF.2.21.1803021042580.9447@aneurin.horsfall.org>

On Thu, 1 Mar 2018, Nelson H. F. Beebe wrote:

> A new paper comparing Unix kernel designs was published earlier today:
>
> 	Stergios Papadimitriou and Lefteris Moussiades
> 	Mac OS versus FreeBSD: A Comparative Evaluation
> 	[IEEE] Computer 52(2), 44--53, February 2018
> 	https://doi.org/10.1109/MC.2018.1451648

And US$33.00 for non-IEEE members; I'll pass...

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."


From beebe at math.utah.edu  Fri Mar  2 10:10:23 2018
From: beebe at math.utah.edu (Nelson H. F. Beebe)
Date: Thu, 1 Mar 2018 17:10:23 -0700
Subject: [TUHS] new paper comparing Unix kernel designs
In-Reply-To: <alpine.BSF.2.21.1803021042580.9447@aneurin.horsfall.org>
Message-ID: <CMM.0.96.0.1519949423.beebe@gamma.math.utah.edu>

>> And US$33.00 for non-IEEE members; 

Yes, that can be a problem for journal publications.

However, throughout the developed world, many academic, city, county,
and regional libraries offer their clients Interlibrary Loan service
that might be zero cost to you.  I use that service many times a year,
and I even once got a loaned hardcopy book that came to Utah from a
library in Scotland (and was later safely returned to Scotland).

-------------------------------------------------------------------------------
- Nelson H. F. Beebe                    Tel: +1 801 581 5254                  -
- University of Utah                    FAX: +1 801 581 4148                  -
- Department of Mathematics, 110 LCB    Internet e-mail: beebe at math.utah.edu  -
- 155 S 1400 E RM 233                       beebe at acm.org  beebe at computer.org -
- Salt Lake City, UT 84112-0090, USA    URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------


From clemc at ccc.com  Fri Mar  2 10:47:50 2018
From: clemc at ccc.com (Clem Cole)
Date: Fri, 02 Mar 2018 00:47:50 +0000
Subject: [TUHS] new paper comparing Unix kernel designs
In-Reply-To: <CMM.0.96.0.1519949423.beebe@gamma.math.utah.edu>
References: <alpine.BSF.2.21.1803021042580.9447@aneurin.horsfall.org>
 <CMM.0.96.0.1519949423.beebe@gamma.math.utah.edu>
Message-ID: <CAC20D2Pc_gT3sDY2SVTo9dkT0LFHMkWAUbrTyfFrEjZu+48VRg@mail.gmail.com>

Unix history. Btw.  One of the things I'm proud of as president at the time
- Usenix was the first of the academic orgs to remove it's pay wall and go
100% free access.

On Thu, Mar 1, 2018 at 7:11 PM Nelson H. F. Beebe <beebe at math.utah.edu>
wrote:

> >> And US$33.00 for non-IEEE members;
>
> Yes, that can be a problem for journal publications.
>
> However, throughout the developed world, many academic, city, county,
> and regional libraries offer their clients Interlibrary Loan service
> that might be zero cost to you.  I use that service many times a year,
> and I even once got a loaned hardcopy book that came to Utah from a
> library in Scotland (and was later safely returned to Scotland).
>
>
> -------------------------------------------------------------------------------
> - Nelson H. F. Beebe                    Tel: +1 801 581 5254
>     -
> - University of Utah                    FAX: +1 801 581 4148
>     -
> - Department of Mathematics, 110 LCB    Internet e-mail:
> beebe at math.utah.edu  -
> - 155 S 1400 E RM
> <https://maps.google.com/?q=%0A-+155+S+1400+E+RM+&entry=gmail&source=g>233
>                      beebe at acm.org  beebe at computer.org -
> - Salt Lake City, UT 84112-0090, USA    URL:
> http://www.math.utah.edu/~beebe/ -
>
> -------------------------------------------------------------------------------
>
-- 
Sent from a handheld expect more typos than usual
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180302/55fdf588/attachment.html>

From dave at horsfall.org  Fri Mar  2 10:54:31 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Fri, 2 Mar 2018 11:54:31 +1100 (EST)
Subject: [TUHS] new paper comparing Unix kernel designs
In-Reply-To: <CMM.0.96.0.1519949423.beebe@gamma.math.utah.edu>
References: <CMM.0.96.0.1519949423.beebe@gamma.math.utah.edu>
Message-ID: <alpine.BSF.2.21.1803021151390.9447@aneurin.horsfall.org>

On Thu, 1 Mar 2018, Nelson H. F. Beebe wrote:

>>> And US$33.00 for non-IEEE members;
>
> Yes, that can be a problem for journal publications.
>
> However, throughout the developed world, many academic, city, county,
> and regional libraries offer their clients Interlibrary Loan service
> that might be zero cost to you.  I use that service many times a year,
> and I even once got a loaned hardcopy book that came to Utah from a
> library in Scotland (and was later safely returned to Scotland).

Yeah, Australia is developed (although sometimes I wonder), so I'll
check out my library; should be free 'cuz I'm a member of it.

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."


From lm at mcvoy.com  Fri Mar  2 11:42:44 2018
From: lm at mcvoy.com (Larry McVoy)
Date: Thu, 1 Mar 2018 17:42:44 -0800
Subject: [TUHS] new paper comparing Unix kernel designs
In-Reply-To: <alpine.BSF.2.21.1803021042580.9447@aneurin.horsfall.org>
References: <CMM.0.96.0.1519946898.beebe@gamma.math.utah.edu>
 <alpine.BSF.2.21.1803021042580.9447@aneurin.horsfall.org>
Message-ID: <20180302014244.GD7093@mcvoy.com>

On Fri, Mar 02, 2018 at 10:44:22AM +1100, Dave Horsfall wrote:
> On Thu, 1 Mar 2018, Nelson H. F. Beebe wrote:
> 
> >A new paper comparing Unix kernel designs was published earlier today:
> >
> >	Stergios Papadimitriou and Lefteris Moussiades
> >	Mac OS versus FreeBSD: A Comparative Evaluation
> >	[IEEE] Computer 52(2), 44--53, February 2018
> >	https://doi.org/10.1109/MC.2018.1451648
> 
> And US$33.00 for non-IEEE members; I'll pass...

I really hate that they do that, it restricts the information flow.
I always stuck up pdfs of my papers so people could grab them.


From mutiny.mutiny at india.com  Fri Mar  2 19:10:30 2018
From: mutiny.mutiny at india.com (Donald ODona)
Date: Fri, 2 Mar 2018 09:10:30 +0000 (UTC)
Subject: [TUHS] new paper comparing Unix kernel designs
In-Reply-To: <CMM.0.96.0.1519946898.beebe@gamma.math.utah.edu>
References: <CMM.0.96.0.1519946898.beebe@gamma.math.utah.edu>
Message-ID: <107018897.53043.1519981830149.JavaMail.tomcat@india-live-be02>

macos uses a (far flung mach derived) osf kernel, which is a hybrid and not a microkernel. Additionally macos utilize other bsd kernel functionality.

At 1 Mar 2018 23:29:36 +0000 (+00:00) from "Nelson H. F. Beebe" <beebe at math.utah.edu>:
> A new paper comparing Unix kernel designs was published earlier today:
> >> ... FreeBSD implements a
> >> traditional compact monolithic Unix kernel, whereas Mac OS builds the
> >> BSD Unix functionality on top of the Mach microkernel. The authors
> >> provide an in-depth technical investigation of both approaches.


From doug at cs.dartmouth.edu  Mon Mar  5 06:23:00 2018
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Sun, 04 Mar 2018 15:23:00 -0500
Subject: [TUHS] [groff] The hyphenation algorithm produces wrong results
Message-ID: <201803042023.w24KN0Kt013712@coolidge.cs.Dartmouth.EDU>


I hadn't realized that groff hyphenation had been taken from
Tex, not troff. Is that becuase Tex did a better job, or 
because troff's was deemed proprietary?



From dave at horsfall.org  Mon Mar  5 06:30:02 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Mon, 5 Mar 2018 07:30:02 +1100 (EST)
Subject: [TUHS] RIP Ray Tomlinson
Message-ID: <alpine.BSF.2.21.1803050725260.9447@aneurin.horsfall.org>

We lost Ray Tomlinson on this day in 2016; known as the inventor of email, 
he sent the first message between two hosts on the ARPAnet (prior to that 
the users had to be on the same host), and pioneered the use of the "@" 
sign.

In the meantime, some tosser (his name is not important) is claiming that 
he invented email first; I recall that APL\360 had a "mailbox" facility, 
but it certainly didn't use "@".

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."


From clemc at ccc.com  Mon Mar  5 06:42:40 2018
From: clemc at ccc.com (Clem Cole)
Date: Sun, 4 Mar 2018 15:42:40 -0500
Subject: [TUHS] [groff] The hyphenation algorithm produces wrong results
In-Reply-To: <201803042023.w24KN0Kt013712@coolidge.cs.Dartmouth.EDU>
References: <201803042023.w24KN0Kt013712@coolidge.cs.Dartmouth.EDU>
Message-ID: <CAC20D2OABQOq6w230j3NddaX=bRQ-963zBD=uzXHMDYY1S7V1w@mail.gmail.com>

On Sun, Mar 4, 2018 at 3:23 PM, Doug McIlroy <doug at cs.dartmouth.edu> wrote:

>
> I hadn't realized that groff hyphenation had been taken from
> Tex, not troff. Is that becuase Tex did a better job, or
> because troff's was deemed proprietary?
>
> Given the author, I would guess the later as he wanted to be FOSS and
would not have looked at the ditroff source - but that guess is worth just
that ;-)


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

From paul.winalski at gmail.com  Mon Mar  5 06:50:14 2018
From: paul.winalski at gmail.com (Paul Winalski)
Date: Sun, 4 Mar 2018 15:50:14 -0500
Subject: [TUHS] RIP Ray Tomlinson
In-Reply-To: <alpine.BSF.2.21.1803050725260.9447@aneurin.horsfall.org>
References: <alpine.BSF.2.21.1803050725260.9447@aneurin.horsfall.org>
Message-ID: <CABH=_VQkrG=PPk=-oXiHDuFcFXXrzSUQz-vYKm58HXp49EL7Mw@mail.gmail.com>

On 3/4/18, Dave Horsfall <dave at horsfall.org> wrote:
>
> In the meantime, some tosser (his name is not important) is claiming that
> he invented email first; I recall that APL\360 had a "mailbox" facility,
> but it certainly didn't use "@".
>
VAX/VMS version 1 (1978) had email, capable of sending messages either
locally or over a DECnet network.  In keeping with standard DECnet
syntax, it used "::" instead of "@".  Len Kawell was the author of VMS
mail.  He got the idea, and copied the UI, from the University of
Illinois PLATO CAI system, which had email capability.  I don't know
if PLATO's email was capable of transmitting messages between computer
systems; Tomlinson may have been the first to do that.

But the concept of email goes way back.

-Paul W.


From bakul at bitblocks.com  Mon Mar  5 07:00:22 2018
From: bakul at bitblocks.com (Bakul Shah)
Date: Sun, 4 Mar 2018 13:00:22 -0800
Subject: [TUHS] [groff] The hyphenation algorithm produces wrong results
In-Reply-To: <CAC20D2OABQOq6w230j3NddaX=bRQ-963zBD=uzXHMDYY1S7V1w@mail.gmail.com>
References: <201803042023.w24KN0Kt013712@coolidge.cs.Dartmouth.EDU>
 <CAC20D2OABQOq6w230j3NddaX=bRQ-963zBD=uzXHMDYY1S7V1w@mail.gmail.com>
Message-ID: <645D5FCC-7AAB-43D0-8035-FABB23986EAA@bitblocks.com>



> On Mar 4, 2018, at 12:42 PM, Clem Cole <clemc at ccc.com> wrote:
> 
> 
>> On Sun, Mar 4, 2018 at 3:23 PM, Doug McIlroy <doug at cs.dartmouth.edu> wrote:
>> 
>> I hadn't realized that groff hyphenation had been taken from
>> Tex, not troff. Is that becuase Tex did a better job, or
>> because troff's was deemed proprietary?
>> 
> 
> Given the author, I would guess the later as he wanted to be FOSS and would not have looked at the ditroff source - but that guess is worth just that ;-)

I remembered reading about Knuth's line-breaking  algorithm in
Software Practice & Experience in early eighties and being quite
impressed with it. So may be that clear description of the algorithm
has something to do with it? Ah, here it is:

“Breaking Paragraphs into lines” by Donald Knuth & Plass,
SP&E, Volume 11, issue 11, Nov. 1981

(Download from Wiley is not free)



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180304/3b71374a/attachment.html>

From toby at telegraphics.com.au  Mon Mar  5 07:32:02 2018
From: toby at telegraphics.com.au (Toby Thain)
Date: Sun, 4 Mar 2018 16:32:02 -0500
Subject: [TUHS] [groff] The hyphenation algorithm produces wrong results
In-Reply-To: <645D5FCC-7AAB-43D0-8035-FABB23986EAA@bitblocks.com>
References: <201803042023.w24KN0Kt013712@coolidge.cs.Dartmouth.EDU>
 <CAC20D2OABQOq6w230j3NddaX=bRQ-963zBD=uzXHMDYY1S7V1w@mail.gmail.com>
 <645D5FCC-7AAB-43D0-8035-FABB23986EAA@bitblocks.com>
Message-ID: <94e00e6e-162f-1b61-c6e1-5d4a64287229@telegraphics.com.au>

On 2018-03-04 4:00 PM, Bakul Shah wrote:
> 
> 
> On Mar 4, 2018, at 12:42 PM, Clem Cole <clemc at ccc.com
> <mailto:clemc at ccc.com>> wrote:
> 
>>
>> On Sun, Mar 4, 2018 at 3:23 PM, Doug McIlroy <doug at cs.dartmouth.edu
>> <mailto:doug at cs.dartmouth.edu>> wrote:
>>
>>
>>     I hadn't realized that groff hyphenation had been taken from
>>     Tex, not troff. Is that becuase Tex did a better job, or
>>     because troff's was deemed proprietary?
>>
>> Given the author, I would guess the later as he wanted to be FOSS and
>> would not have looked at the ditroff source - but that guess is worth
>> just that ;-)
> 
> I remembered reading about Knuth's line-breaking  algorithm in
> Software Practice & Experience in early eighties and being quite
> impressed with it. So may be that clear description of the algorithm
> has something to do with it? Ah, here it is:
> 
> “Breaking Paragraphs into lines” by Donald Knuth & Plass,
> SP&E, Volume 11, issue 11, Nov. 1981

That's the line breaker, which is an important contributor to the
quality of TeX output.

But TeX's *hyphenation* algorithm per se was invented by Franklin Mark
Liang and was indeed considerably better than its predecessors and
competitors (including most or all commercial typesetting software --
which was a big part of the motivation for it):

https://tug.org/docs/liang/liang-thesis.pdf

--Toby


> 
> (Download from Wiley is not free)
> 
> 
> 



From dave at horsfall.org  Mon Mar  5 07:47:32 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Mon, 5 Mar 2018 08:47:32 +1100 (EST)
Subject: [TUHS] RIP Ray Tomlinson
In-Reply-To: <CABH=_VQkrG=PPk=-oXiHDuFcFXXrzSUQz-vYKm58HXp49EL7Mw@mail.gmail.com>
References: <alpine.BSF.2.21.1803050725260.9447@aneurin.horsfall.org>
 <CABH=_VQkrG=PPk=-oXiHDuFcFXXrzSUQz-vYKm58HXp49EL7Mw@mail.gmail.com>
Message-ID: <alpine.BSF.2.21.1803050846000.9447@aneurin.horsfall.org>

On Sun, 4 Mar 2018, Paul Winalski wrote:

> [ ... ] I don't know if PLATO's email was capable of transmitting 
> messages between computer systems; Tomlinson may have been the first to 
> do that.

That's the claim, yes.

> But the concept of email goes way back.

Indeed, it does, but only on the same system.

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."


From ralph at inputplus.co.uk  Mon Mar  5 07:50:23 2018
From: ralph at inputplus.co.uk (Ralph Corderoy)
Date: Sun, 04 Mar 2018 21:50:23 +0000
Subject: [TUHS] [groff] The hyphenation algorithm produces wrong results
In-Reply-To: <645D5FCC-7AAB-43D0-8035-FABB23986EAA@bitblocks.com>
References: <201803042023.w24KN0Kt013712@coolidge.cs.Dartmouth.EDU>
 <CAC20D2OABQOq6w230j3NddaX=bRQ-963zBD=uzXHMDYY1S7V1w@mail.gmail.com>
 <645D5FCC-7AAB-43D0-8035-FABB23986EAA@bitblocks.com>
Message-ID: <20180304215023.883981F96E@orac.inputplus.co.uk>

Hi Doug,

Bakul wrote:
> I remembered reading about Knuth's line-breaking algorithm in Software
> Practice & Experience in early eighties and being quite impressed with
> it.  So may be that clear description of the algorithm has something
> to do with it?  Ah, here it is:
>
> “Breaking Paragraphs into lines” by Donald Knuth & Plass, SP&E, Volume
> 11, issue 11, Nov. 1981

That's more to do with TeX looking at the whole paragraph when deciding
where to split lines.  Hyphenation is part of that because a word might
help out by being the ideal thing to split and have the rest of the
lines sit easily in their length, but TeX's hyphenation algorithm is
distinct again.

Ted Harding gives some background on the groff list back in 2001,
https://lists.gnu.org/archive/html/groff/2001-03/msg00026.html
but I expect groff used TeX's algorithm because it was published, could
handle multiple languages, e.g. hyphen.us, and the data files were
available to contort into what groff ended up using in its simplified
TeX algorithm.

    $ cd /usr/share/groff/1.22.3/tmac
    $ ls hyphen*
    hyphen.den  hyphenex.cs hyphenex.us hyphen.sv   hyphen.us
    hyphen.cs   hyphen.det  hyphenex.de hyphen.fr
    $

They've comments explaining their content.

Werner Lemburg on the groff list probably knows for certain as he had to
fathom all this out before becoming groff's excellent maintainer for
many years.

-- 
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy


From clemc at ccc.com  Mon Mar  5 08:22:16 2018
From: clemc at ccc.com (Clem Cole)
Date: Sun, 4 Mar 2018 17:22:16 -0500
Subject: [TUHS] RIP Ray Tomlinson
In-Reply-To: <alpine.BSF.2.21.1803050846000.9447@aneurin.horsfall.org>
References: <alpine.BSF.2.21.1803050725260.9447@aneurin.horsfall.org>
 <CABH=_VQkrG=PPk=-oXiHDuFcFXXrzSUQz-vYKm58HXp49EL7Mw@mail.gmail.com>
 <alpine.BSF.2.21.1803050846000.9447@aneurin.horsfall.org>
Message-ID: <CAC20D2P51MKwpTjTgQotOEnVifU9dSoZo2xvTxxbqRkGjJHHMA@mail.gmail.com>

On Sun, Mar 4, 2018 at 4:47 PM, Dave Horsfall <dave at horsfall.org> wrote:

> On Sun, 4 Mar 2018, Paul Winalski wrote:
>
> [ ... ] I don't know if PLATO's email was capable of transmitting messages
>> between computer systems; Tomlinson may have been the first to do that.
>>
>
> That's the claim, yes.

​I just finished Brian Dear's 'Friendly Orange Glow" and Plato was after
Tomlinson.



>
>
> But the concept of email goes way back.
>>
>
> Indeed, it does, but only on the same system.


Some sort of messaging between users was pretty standard on timeshared
systems.   It was in IBM and DEC systems in the late 60s.  But if you
believe the Internet history in Katie Hafner's 'Where Wizards Stay Up Late'
Tomlinson ​extended to the ArpaNet - where is why the @ was important.  The
book is great but the whole chapter on Mail formats is really a fun
read.   ArpaNet
mail had been around a for a few years before any attempt to standardize it
occurred.   This was in part because most of the systems were supplied by
DARPA and thus had some level of commoniality - al buet extensively
modified (TOPS-10 vs TENEX vs ITS).    Brian Reed is quoted in that book
extensively and I remember some of the events described between the
PDP-10's that made up most of the ArpaNet in those days.

I always have gotten a kick out of SMTP being considered 'simple' - but
given then before that email was a hacked on to FTP  and really was a
kludge and after though.

BTW: Paul's comment about DECnet's use of double colon (muchless UUCP's use
of bang) to describe separate 'nodes' is all post ArpaNet and Tomlinson's
original work.    DEC did not even start the work on DECnet, nor IBM on SNA
until long after the ArpaNet succeeded.   In fact, both firms originally
poo-pooed the ideas [again read Katie's book -- a fascinating history].

As for the 'tosser' that is making claims, I am under the impression he
some how succeeded in getting a copyright for it.  How is unclear, but he
did.   And that's his claim for invention based on work he did which he
admits was in 1978 -- which is 7-10 years after the ArpaNet:  [
http://fortune.com/2016/03/07/who-really-invented-email/.]  To me, a
strange part is that he suing people that claim otherwise.  I really don't
see how he can win those, but I'm not a laywer and I guess copyright gives
him certain rights.   O note that, I have been using messaging system - aka
email, pretty nearly ever day since I first start using computers in the
late 1960s.  So I have a very hard time taking this guy seriously.

Clem



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

From bakul at bitblocks.com  Mon Mar  5 08:36:58 2018
From: bakul at bitblocks.com (Bakul Shah)
Date: Sun, 4 Mar 2018 14:36:58 -0800
Subject: [TUHS] [groff] The hyphenation algorithm produces wrong results
In-Reply-To: <20180304215023.883981F96E@orac.inputplus.co.uk>
References: <201803042023.w24KN0Kt013712@coolidge.cs.Dartmouth.EDU>
 <CAC20D2OABQOq6w230j3NddaX=bRQ-963zBD=uzXHMDYY1S7V1w@mail.gmail.com>
 <645D5FCC-7AAB-43D0-8035-FABB23986EAA@bitblocks.com>
 <20180304215023.883981F96E@orac.inputplus.co.uk>
Message-ID: <D39FBC5F-28BB-43F6-9B3B-7E87F816DC8A@bitblocks.com>



> On Mar 4, 2018, at 1:50 PM, Ralph Corderoy <ralph at inputplus.co.uk> wrote:
> 
> Hi Doug,
> 
> Bakul wrote:
>> I remembered reading about Knuth's line-breaking algorithm in Software
>> Practice & Experience in early eighties and being quite impressed with
>> it.  So may be that clear description of the algorithm has something
>> to do with it?  Ah, here it is:
>> 
>> “Breaking Paragraphs into lines” by Donald Knuth & Plass, SP&E, Volume
>> 11, issue 11, Nov. 1981
> 
> That's more to do with TeX looking at the whole paragraph when deciding
> where to split lines.  Hyphenation is part of that because a word might
> help out by being the ideal thing to split and have the rest of the
> lines sit easily in their length, but TeX's hyphenation algorithm is
> distinct again.
> 
> Ted Harding gives some background on the groff list back in 2001,
> https://lists.gnu.org/archive/html/groff/2001-03/msg00026.html
> but I expect groff used TeX's algorithm because it was published, could
> handle multiple languages, e.g. hyphen.us, and the data files were
> available to contort into what groff ended up using in its simplified
> TeX algorithm.
> 
>    $ cd /usr/share/groff/1.22.3/tmac
>    $ ls hyphen*
>    hyphen.den  hyphenex.cs hyphenex.us hyphen.sv   hyphen.us
>    hyphen.cs   hyphen.det  hyphenex.de hyphen.fr
>    $
> 
> They've comments explaining their content.
> 
> Werner Lemburg on the groff list probably knows for certain as he had to
> fathom all this out before becoming groff's excellent maintainer for
> many years.
> 
> -- 
> Cheers, Ralph.
> https://plus.google.com/+RalphCorderoy

Thanks Ralph and Toby. “Because it was clearly described and published”
was the point I was trying to make and should’ve stopped there : ). SP&E
article had made a strong impression on me and that is what I instantly
thought of. 


From crossd at gmail.com  Mon Mar  5 09:16:38 2018
From: crossd at gmail.com (Dan Cross)
Date: Sun, 4 Mar 2018 18:16:38 -0500
Subject: [TUHS] RIP Ray Tomlinson
In-Reply-To: <CAC20D2P51MKwpTjTgQotOEnVifU9dSoZo2xvTxxbqRkGjJHHMA@mail.gmail.com>
References: <alpine.BSF.2.21.1803050725260.9447@aneurin.horsfall.org>
 <CABH=_VQkrG=PPk=-oXiHDuFcFXXrzSUQz-vYKm58HXp49EL7Mw@mail.gmail.com>
 <alpine.BSF.2.21.1803050846000.9447@aneurin.horsfall.org>
 <CAC20D2P51MKwpTjTgQotOEnVifU9dSoZo2xvTxxbqRkGjJHHMA@mail.gmail.com>
Message-ID: <CAEoi9W5+EhcEyi7LDi_JzrEY=J7UOQ4Uba7nXPMFyV5gMyD7Xg@mail.gmail.com>

On Mar 4, 2018 5:23 PM, "Clem Cole" <clemc at ccc.com> wrote:

As for the 'tosser' that is making claims, I am under the impression he
some how succeeded in getting a copyright for it.  How is unclear, but he
did.   And that's his claim for invention based on work he did which he
admits was in 1978 -- which is 7-10 years after the ArpaNet:  [
http://fortune.com/2016/03/07/who-really-invented-email/.]  To me, a
strange part is that he suing people that claim otherwise.  I really don't
see how he can win those, but I'm not a laywer and I guess copyright gives
him certain rights.   O note that, I have been using messaging system - aka
email, pretty nearly ever day since I first start using computers in the
late 1960s.  So I have a very hard time taking this guy seriously.


Not only is he a tosser, he's also a political crank. He took part in a
"free speech" rally this past summer, which was a thinly disguised venue
for white supremacists.

He's apparently mounting a bid for the US Senate, which is odd in and of
itself, but he's acquired an aged school bus that he's painted and is using
as a prop for his candidacy. It just so happens that I was driving down the
same road as that bus earlier today and was stopped at a traffic light next
to it for a minute or so. "Oh, that's that crazy email guy...." It made me
more than usually annoyed.

        - Dan C.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180304/a059b7b1/attachment.html>

From doug at cs.dartmouth.edu  Mon Mar  5 09:55:00 2018
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Sun, 04 Mar 2018 18:55:00 -0500
Subject: [TUHS] RIP Ray Tomlinson
Message-ID: <201803042355.w24Nt00D015148@coolidge.cs.Dartmouth.EDU>

> > But the concept of email goes way back.

> Indeed, it does, but only on the same system.

Very far back. CTSS had a mail utility.

If communication within one system is not
recognized as email, then the exchange that
opened in Boston in 1877 was not a
telephone system.

Doug


From clemc at ccc.com  Tue Mar  6 04:24:00 2018
From: clemc at ccc.com (Clem Cole)
Date: Mon, 5 Mar 2018 13:24:00 -0500
Subject: [TUHS] RIP Ray Tomlinson
In-Reply-To: <201803042355.w24Nt00D015148@coolidge.cs.Dartmouth.EDU>
References: <201803042355.w24Nt00D015148@coolidge.cs.Dartmouth.EDU>
Message-ID: <CAC20D2N2YjJS6F_bTo5=aA=72GEGAS2tK6gyDoh5OCTVBmJQDw@mail.gmail.com>

On Sun, Mar 4, 2018 at 6:55 PM, Doug McIlroy <doug at cs.dartmouth.edu> wrote:

> Very far back. CTSS had a mail utility.
>
​Yep, as I said, it was pretty standard for timesharing...​ and certainly
IBM, DEC and most of the BUNCH companies had something like it in their
1960s developed systems.



>
> If communication within one system is not
> ​ ​
> recognized as email, then the exchange that
> opened in Boston in 1877 was not a
> ​ ​
> telephone system.

​Amen...

It's all about MetCalfe's Law and the value of the messaging system with
the # of users.   The ARPANet, like the connected exchanges, increase the
number of #s.​

ᐧ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180305/373c4ed2/attachment.html>

From dave at horsfall.org  Wed Mar  7 03:58:01 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Wed, 7 Mar 2018 04:58:01 +1100 (EST)
Subject: [TUHS] Sleep()y musings
Message-ID: <alpine.BSF.2.21.1803070411380.36136@aneurin.horsfall.org>

Back when the dinosaurs were using card readers (and yes, I've used a card 
reader on Unix; I think it was a desktop CDC model, and the driver would 
handle two modes: strict 80-column i.e. one 12-bit column per 16-bit word 
and you got 80 of 'em on a DMA channel, or ASCII NL-terminated after last 
non-blank column, and no, I have no idea whether it handled EBCDIC or CDC 
etc, but I digress as usual).

Where was I?  Oh yes, sleeps...

Back when sleep(3) was sleep(2) (yes, Virginia, sleep() used to be a 
system call, then it became alarm()/pause(), and now it seems to be 
nanosleep(), and I'm wandering again), you never called sleep(1) because 
its granularity was +/-1 second (and all the way up to +infinity, 
actually, on a really busy machine), thus it could return right away, with 
ensuing hilarity.

So, I'm curious:

When did sleep(2) become sleep(3)?  Was it V7, or some BSD?  Or Babbage 
help me, SysVile?

When did the caveat about sleeping for 1 second become known?  I don't 
think that I ever saw it documented, but was one of those "lore" things 
passed around at Unix conferences and the like.

And when did it start using nanosleep() instead of alarm()/pause()?  I see 
that my Penguin box has a bet both ways; it "may" use SIGALRM[a] (thus 
"mixing calls to alarm(2) and sleep() is a bad idea" (well, I've used 
both), and also refers to nanosleep().

[a]
Alpine's spell-checker suggested "SICKROOM" here; pretty close when 
dealing with timed-out reads on a TTY connection[ii] :-)

[ii]
Have you tried this with Perl?  You can't rely on EINTR[3], so you have to 
use eval{} blocks instead, and it starts getting pretty fugly...

[3]
And here it suggested "ENTREE".

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."


From jnc at mercury.lcs.mit.edu  Wed Mar  7 04:11:27 2018
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Tue,  6 Mar 2018 13:11:27 -0500 (EST)
Subject: [TUHS] Sleep()y musings
Message-ID: <20180306181127.2B21718C0D8@mercury.lcs.mit.edu>

    > From: Dave Horsfall

    > When did sleep(2) become sleep(3)?  Was it V7, or some BSD?

Before V7. The MIT system (~PWB1) says, on the man page for sleep (II), "As of
this writing the system call is still available although the C routine
implmeneting the function uses 'alarm' and 'pause' (II). It will be withdrawn
when convenient."

Probably left the system call there for compiled commands, etc which used it?

	 Noel


From clemc at ccc.com  Wed Mar  7 06:53:29 2018
From: clemc at ccc.com (Clem Cole)
Date: Tue, 6 Mar 2018 15:53:29 -0500
Subject: [TUHS] Sleep()y musings
In-Reply-To: <20180306181127.2B21718C0D8@mercury.lcs.mit.edu>
References: <20180306181127.2B21718C0D8@mercury.lcs.mit.edu>
Message-ID: <CAC20D2NLhbLg3s+VRD0P3U1j7W_HcZsEEOTgd998eb0e-z3YRg@mail.gmail.com>

I'm pretty sure it  was in TS also, but I'm willing to bet it was PWB1
first.  Have to ask someone like Mashey.

FWIW: The issue on time for BSD was somewhat forced by the ARPA community.
The 60th (or 50th) of second (much less 1 second) started to not be fine
enough for many applications.   I remember a big argument at a system
seminar circa 82/83 about it.   IIRC it was Mike Powell (DEMOS fame) that
was bitching at Joy about it.  In the end, BSD4.2 ended up with new time
calls because of that community and started doing things in 100th of second
- which again IIRC was the best the Vax could do.

I've forgotten what the time resolution on the PDP-10s were, but the Crays
and CDC boxes of the day, were much more fine grained than the Vaxen.
Joy was trying to bring Unix closer to what the labs wanted, since they
were paying a lot of the bills.
ᐧ

On Tue, Mar 6, 2018 at 1:11 PM, Noel Chiappa <jnc at mercury.lcs.mit.edu>
wrote:

>     > From: Dave Horsfall
>
>     > When did sleep(2) become sleep(3)?  Was it V7, or some BSD?
>
> Before V7. The MIT system (~PWB1) says, on the man page for sleep (II),
> "As of
> this writing the system call is still available although the C routine
> implmeneting the function uses 'alarm' and 'pause' (II). It will be
> withdrawn
> when convenient."
>
> Probably left the system call there for compiled commands, etc which used
> it?
>
>          Noel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180306/187a6fa6/attachment.html>

From paul.winalski at gmail.com  Wed Mar  7 07:39:34 2018
From: paul.winalski at gmail.com (Paul Winalski)
Date: Tue, 6 Mar 2018 16:39:34 -0500
Subject: [TUHS] Sleep()y musings
In-Reply-To: <CAC20D2NLhbLg3s+VRD0P3U1j7W_HcZsEEOTgd998eb0e-z3YRg@mail.gmail.com>
References: <20180306181127.2B21718C0D8@mercury.lcs.mit.edu>
 <CAC20D2NLhbLg3s+VRD0P3U1j7W_HcZsEEOTgd998eb0e-z3YRg@mail.gmail.com>
Message-ID: <CABH=_VTWGKTJJXksETTMTmcPT_USkJtPC_DU0-j3M37Y6GL9Zg@mail.gmail.com>

On 3/6/18, Clem Cole <clemc at ccc.com> wrote:
>
> FWIW: The issue on time for BSD was somewhat forced by the ARPA community.
> The 60th (or 50th) of second (much less 1 second) started to not be fine
> enough for many applications.   I remember a big argument at a system
> seminar circa 82/83 about it.   IIRC it was Mike Powell (DEMOS fame) that
> was bitching at Joy about it.  In the end, BSD4.2 ended up with new time
> calls because of that community and started doing things in 100th of second
> - which again IIRC was the best the Vax could do.
>
Yes--the resolution of the interval timer on the VAX was 10
microseconds (1/100 of a second).

-Paul W.


From michael at kjorling.se  Thu Mar  8 02:33:08 2018
From: michael at kjorling.se (Michael =?utf-8?B?S2rDtnJsaW5n?=)
Date: Wed, 7 Mar 2018 16:33:08 +0000
Subject: [TUHS] Sleep()y musings
In-Reply-To: <CABH=_VTWGKTJJXksETTMTmcPT_USkJtPC_DU0-j3M37Y6GL9Zg@mail.gmail.com>
References: <20180306181127.2B21718C0D8@mercury.lcs.mit.edu>
 <CAC20D2NLhbLg3s+VRD0P3U1j7W_HcZsEEOTgd998eb0e-z3YRg@mail.gmail.com>
 <CABH=_VTWGKTJJXksETTMTmcPT_USkJtPC_DU0-j3M37Y6GL9Zg@mail.gmail.com>
Message-ID: <20180307163308.GE30090@h-174-65.A328.priv.bahnhof.se>

On 6 Mar 2018 16:39 -0500, from paul.winalski at gmail.com (Paul Winalski):
> Yes--the resolution of the interval timer on the VAX was 10
> microseconds (1/100 of a second).

Surely you just mistyped milliseconds?

-- 
Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se
  “The most dangerous thought that you can have as a creative person
              is to think you know what you’re doing.” (Bret Victor)


From paul.winalski at gmail.com  Thu Mar  8 04:54:32 2018
From: paul.winalski at gmail.com (Paul Winalski)
Date: Wed, 7 Mar 2018 13:54:32 -0500
Subject: [TUHS] Sleep()y musings
In-Reply-To: <CAC20D2NLhbLg3s+VRD0P3U1j7W_HcZsEEOTgd998eb0e-z3YRg@mail.gmail.com>
References: <20180306181127.2B21718C0D8@mercury.lcs.mit.edu>
 <CAC20D2NLhbLg3s+VRD0P3U1j7W_HcZsEEOTgd998eb0e-z3YRg@mail.gmail.com>
Message-ID: <CABH=_VTO7sdgGypp3U7zQoWdJ3HsGUUjrk-6_Rf5VE5gyNGD7g@mail.gmail.com>

On 3/6/18, Clem Cole <clemc at ccc.com> wrote:
>
> In the end, BSD4.2 ended up with new time
> calls because of that community and started doing things in 100th of second
> - which again IIRC was the best the Vax could do.
>
When all else fails, RTFM.  :-)

According to the VAX Architecture Reference Manual (1987), the
Interval Clock Register, which is used by OSes to keep track of real
time, is a 32-bit unsigned value incremented at 1-microsecond
(0.000001 second) intervals.

VAX also has a Time-of-Year Clock Register (colloquially called the
TOY clock), a 32-bit unsigned value whose LSB represents a resolution
of 10 milliseconds (0.01 second).  All VAX models except the
VAX-11/730 provided battery backup for the TOY clock so that it
continued to operate even when the system was powered off.  A VAX can
thus be powered off for about 497 days and still remember the
date/time.

I think Clem was remembering the TOY clock.  It would be the Interval
Clock Register that was used by BSD to implement sleep() and other
time-related services.

-Paul W.


From rudi.j.blom at gmail.com  Thu Mar  8 13:39:11 2018
From: rudi.j.blom at gmail.com (Rudi Blom)
Date: Thu, 8 Mar 2018 10:39:11 +0700
Subject: [TUHS] Sleep()y musings
Message-ID: <CAMYpm87z_tqs9h0S4OoeB4ZXi1vDwr=9KKfWbxW4_gd5gvX+bw@mail.gmail.com>

>Date: Wed, 7 Mar 2018 13:54:32 -0500
>From: Paul Winalski <paul.winalski at gmail.com>
>To: Clem Cole <clemc at ccc.com>
>Cc: The Eunuchs Hysterical Society <tuhs at tuhs.org>
>Subject: Re: [TUHS] Sleep()y musings
>Message-ID:
>        <CABH=_VTO7sdgGypp3U7zQoWdJ3HsGUUjrk->6_Rf5VE5gyNGD7g at mail.gmail.com>
>Content-Type: text/plain; charset="UTF-8"
>
>...
>VAX also has a Time-of-Year Clock Register (colloquially called the
>TOY clock), a 32-bit unsigned value whose LSB represents a resolution
>of 10 milliseconds (0.01 second).  All VAX models except the
>VAX-11/730 provided battery backup for the TOY clock so that it
>continued to operate even when the system was powered off.  A VAX can
>thus be powered off for about 497 days and still remember the
>date/time.

Also in AlphaServers we still have this TOY, the clock and the battery that is.
>From a DS10 running Digital Unix 4.0G, /var/adm/messages file, I only
removed the BEL characters

Dec 12 03:01:27 br0011 vmunix: You must reset the system time manually
Dec 12 03:01:27 br0011 vmunix: Time of year (TOY) clock returned zero
as the current time
Dec 12 03:01:27 br0011 vmunix:
Dec 12 03:01:27 br0011 vmunix:
Dec 12 03:01:27 br0011 vmunix: WARNING: preposterous time in TOY clock
-- CHECK AND RESET THE DATE!!
Dec 12 03:01:27 br0011 vmunix:
Dec 12 03:01:27 br0011 vmunix: i2c: Server Management Hardware Present
Dec 12 03:01:27 br0011 vmunix: datalink: links=128, macs=6
Dec 12 03:01:27 br0011 vmunix: NOTE: dxb_configure: Configure values:
dxb, ffffffffffffff9d, ffffffff90bfbf80, ffffffff90bf9a20
Dec 12 03:01:27 br0011 vmunix: WARNING: dxb_configure:
configure_driver error = 22
Dec 12 03:01:28 br0011 vmunix: Node ID is 00-10-64-30-ae-38 (from device tu0)
Dec 12 03:01:28 br0011 vmunix: WARNING: Time of year (TOY) clock
battery is dead, time and NVR contents ignored
Dec 12 03:01:28 br0011 vmunix:
Dec 12 03:01:28 br0011 vmunix: You must reset the system time manually

Cheers,
uncle rubl


From ipwn at email.com  Thu Mar  8 14:10:23 2018
From: ipwn at email.com (iPwn iPwn)
Date: Thu, 8 Mar 2018 05:10:23 +0100
Subject: [TUHS] nix/Linux friendly hardware free of proprietary software
Message-ID: <trinity-0e50f317-a460-438e-949c-408794abd52e-1520482223532@3c-app-mailcom-lxa05>

An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180308/0308a78a/attachment.html>

From ipwn at email.com  Thu Mar  8 14:42:12 2018
From: ipwn at email.com (iPwn iPwn)
Date: Thu, 8 Mar 2018 05:42:12 +0100
Subject: [TUHS] Unix friendly hardware free of proprietary software
Message-ID: <trinity-92fc006f-aefc-44b5-86a6-e040f2e16ee4-1520484132105@3c-app-mailcom-lxa05>

hi,

im looking for Unix/Unix-like/Linux friendly hardware(desks,laps,phones,etc) free of proprietary software or compatible with free software(OS,BIOS firmware,etc) something that is easy to replace stock or something that cames with free software preinstalled and that i can replace them if i want to.
i've seen some lists that contain vendors that are Unix/Linux friendly and also the hardware endorsed by FSF which seem to be Lenovo thinkpads,etc the thing is it seems most of hardware require external flashing to replace BIOS,etc and makes the task harder..

my question are,
what are the bests Unix/Unix-like/Linux friendly hardware manufacturers?
which hardware is the best to make a computer 100% free (free BIOS and OS) and that is optimized and behave better under Unix/Unix-like/Linux based OS's?

Thank you.
 
--
PHACT Phreakers / Hackers / Anarchists / Cyberpunks / Technologists


From wkt at tuhs.org  Thu Mar  8 14:48:32 2018
From: wkt at tuhs.org (Warren Toomey)
Date: Thu, 8 Mar 2018 14:48:32 +1000
Subject: [TUHS] nix/Linux friendly hardware free of proprietary software
In-Reply-To: <trinity-0e50f317-a460-438e-949c-408794abd52e-1520482223532@3c-app-mailcom-lxa05>
References: <trinity-0e50f317-a460-438e-949c-408794abd52e-1520482223532@3c-app-mailcom-lxa05>
Message-ID: <20180308044832.GA10361@minnie.tuhs.org>

On Thu, Mar 08, 2018 at 05:10:23AM +0100, iPwn iPwn wrote:
>   im looking for Unix/Linux friendly hardware(desks,laps,phones,etc) free
>   of proprietary software.

Hmm, looks like I let someone in who gave me some bona fides (he knew
about gunkies), but wasn't really after heritage Unix. Sorry about that.

	Warren


From dave at horsfall.org  Fri Mar  9 07:50:22 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Fri, 9 Mar 2018 08:50:22 +1100 (EST)
Subject: [TUHS] Sleep()y musings
In-Reply-To: <alpine.BSF.2.21.1803070411380.36136@aneurin.horsfall.org>
References: <alpine.BSF.2.21.1803070411380.36136@aneurin.horsfall.org>
Message-ID: <alpine.BSF.2.21.1803090849050.36136@aneurin.horsfall.org>

OK, I've generated some discussion (both public and private) so after the 
dust settles I'll summarise the responses.

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."


From blake at mcbride.name  Fri Mar  9 13:57:11 2018
From: blake at mcbride.name (Blake McBride)
Date: Thu, 8 Mar 2018 21:57:11 -0600
Subject: [TUHS] Unix friendly hardware free of proprietary software
In-Reply-To: <trinity-92fc006f-aefc-44b5-86a6-e040f2e16ee4-1520484132105@3c-app-mailcom-lxa05>
References: <trinity-92fc006f-aefc-44b5-86a6-e040f2e16ee4-1520484132105@3c-app-mailcom-lxa05>
Message-ID: <CABwHSOuFGAO0V0gW5L0hoHBsT-hPYP3=fY=FxqruBqeng_85pQ@mail.gmail.com>

https://trisquel.info/


On Wed, Mar 7, 2018 at 10:42 PM, iPwn iPwn <ipwn at email.com> wrote:

> hi,
>
> im looking for Unix/Unix-like/Linux friendly hardware(desks,laps,phones,etc)
> free of proprietary software or compatible with free software(OS,BIOS
> firmware,etc) something that is easy to replace stock or something that
> cames with free software preinstalled and that i can replace them if i want
> to.
> i've seen some lists that contain vendors that are Unix/Linux friendly and
> also the hardware endorsed by FSF which seem to be Lenovo thinkpads,etc the
> thing is it seems most of hardware require external flashing to replace
> BIOS,etc and makes the task harder..
>
> my question are,
> what are the bests Unix/Unix-like/Linux friendly hardware manufacturers?
> which hardware is the best to make a computer 100% free (free BIOS and OS)
> and that is optimized and behave better under Unix/Unix-like/Linux based
> OS's?
>
> Thank you.
>
> --
> PHACT Phreakers / Hackers / Anarchists / Cyberpunks / Technologists
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180308/01187143/attachment.html>

From usotsuki at buric.co  Fri Mar  9 14:13:23 2018
From: usotsuki at buric.co (Steve Nickolas)
Date: Thu, 8 Mar 2018 23:13:23 -0500 (EST)
Subject: [TUHS] nix/Linux friendly hardware free of proprietary software
In-Reply-To: <20180308044832.GA10361@minnie.tuhs.org>
References: <trinity-0e50f317-a460-438e-949c-408794abd52e-1520482223532@3c-app-mailcom-lxa05>
 <20180308044832.GA10361@minnie.tuhs.org>
Message-ID: <alpine.BSF.2.02.1803082312090.240@frieza.hoshinet.org>

On Thu, 8 Mar 2018, Warren Toomey wrote:

> On Thu, Mar 08, 2018 at 05:10:23AM +0100, iPwn iPwn wrote:
>>   im looking for Unix/Linux friendly hardware(desks,laps,phones,etc) free
>>   of proprietary software.
>
> Hmm, looks like I let someone in who gave me some bona fides (he knew
> about gunkies), but wasn't really after heritage Unix. Sorry about that.
>
> 	Warren
>

Well, some people seem to think Linux and Unix are the same...

I have yet to see one Linux distribution that licenses the Unix trademark.

-uso.


From gtaylor at tnetconsulting.net  Sat Mar 10 03:54:41 2018
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Fri, 9 Mar 2018 10:54:41 -0700
Subject: [TUHS] nix/Linux friendly hardware free of proprietary software
In-Reply-To: <alpine.BSF.2.02.1803082312090.240@frieza.hoshinet.org>
References: <trinity-0e50f317-a460-438e-949c-408794abd52e-1520482223532@3c-app-mailcom-lxa05>
 <20180308044832.GA10361@minnie.tuhs.org>
 <alpine.BSF.2.02.1803082312090.240@frieza.hoshinet.org>
Message-ID: <848dacd3-7094-4af5-4e1b-f9bf5c17f76d@spamtrap.tnetconsulting.net>

On 03/08/2018 09:13 PM, Steve Nickolas wrote:
> Well, some people seem to think Linux and Unix are the same...

"The same" no.  "Similar" yes.

> I have yet to see one Linux distribution that licenses the Unix trademark.

Why would a Linux distribution license the Unix trademark?  Why would a 
Linux distribution want to call itself Unix?  Why would a Linux 
distribution not want to call itself Linux?



-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3982 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180309/890aa3b9/attachment.bin>

From pete at nomadlogic.org  Sat Mar 10 04:21:37 2018
From: pete at nomadlogic.org (Pete Wright)
Date: Fri, 9 Mar 2018 10:21:37 -0800
Subject: [TUHS] nix/Linux friendly hardware free of proprietary software
In-Reply-To: <848dacd3-7094-4af5-4e1b-f9bf5c17f76d@spamtrap.tnetconsulting.net>
References: <trinity-0e50f317-a460-438e-949c-408794abd52e-1520482223532@3c-app-mailcom-lxa05>
 <20180308044832.GA10361@minnie.tuhs.org>
 <alpine.BSF.2.02.1803082312090.240@frieza.hoshinet.org>
 <848dacd3-7094-4af5-4e1b-f9bf5c17f76d@spamtrap.tnetconsulting.net>
Message-ID: <7750d033-b390-dab7-95d2-9a93b5a0c6af@nomadlogic.org>



On 03/09/2018 09:54, Grant Taylor via TUHS wrote:
> On 03/08/2018 09:13 PM, Steve Nickolas wrote:
>> Well, some people seem to think Linux and Unix are the same...
>
> "The same" no.  "Similar" yes.
>
>> I have yet to see one Linux distribution that licenses the Unix 
>> trademark.
>
> Why would a Linux distribution license the Unix trademark?  Why would 
> a Linux distribution want to call itself Unix?  Why would a Linux 
> distribution not want to call itself Linux?
>
>
hrm...maybe because Gnu's Not Unix?  heh sorry couldn't resist, i'll 
back under the bridge I live under.

-p

-- 
Pete Wright
pete at nomadlogic.org
@nomadlogicLA



From cym224 at gmail.com  Sat Mar 10 13:03:28 2018
From: cym224 at gmail.com (Nemo)
Date: Fri, 9 Mar 2018 22:03:28 -0500
Subject: [TUHS] nix/Linux friendly hardware free of proprietary software
In-Reply-To: <alpine.BSF.2.02.1803082312090.240@frieza.hoshinet.org>
References: <trinity-0e50f317-a460-438e-949c-408794abd52e-1520482223532@3c-app-mailcom-lxa05>
 <20180308044832.GA10361@minnie.tuhs.org>
 <alpine.BSF.2.02.1803082312090.240@frieza.hoshinet.org>
Message-ID: <CAJfiPzy4W-EtbE8bP-PU2G259TbH7T8ZK6caeZi-xJJ55aNzMQ@mail.gmail.com>

On 08/03/2018, Steve Nickolas <usotsuki at buric.co> wrote:
[...]
> Well, some people seem to think Linux and Unix are the same...
>
> I have yet to see one Linux distribution that licenses the Unix trademark.
>
> -uso.

Unifix Linux was POSIX.1 certified
(http://www.unifix.de/products/unifix_2_0/ -- I have their s/w
somewhere).  No clue what happened to them.

N.


From lars at nocrew.org  Wed Mar 14 21:36:14 2018
From: lars at nocrew.org (Lars Brinkhoff)
Date: Wed, 14 Mar 2018 11:36:14 +0000
Subject: [TUHS] Illinois PDP-11 Network Unix
Message-ID: <7wr2omc2j5.fsf@junk.nocrew.org>

Hello,

Is this "Network Unix" available?

https://www.ideals.illinois.edu/bitstream/handle/2142/32817/networkunixsyste243kell.pdf

https://tools.ietf.org/html/rfc681

Or, is there another Unix which will do pre-TCP/IP Arpanet?  I have an
off-topic system with NCP, but no one to talk to.


From jnc at mercury.lcs.mit.edu  Wed Mar 14 22:58:56 2018
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Wed, 14 Mar 2018 08:58:56 -0400 (EDT)
Subject: [TUHS] Illinois PDP-11 Network Unix
Message-ID: <20180314125856.E4A3818C0DD@mercury.lcs.mit.edu>

    > From: Lars Brinkhoff

    > Is this "Network Unix" available?

??? This was announced here not long ago:

  http://minnie.tuhs.org/cgi-bin/utree.pl?file=SRI-NOSC

It's called 'NOSC' because that's where it came from, but it has the Illinois
NCP code in it.

    Noel


From lars at nocrew.org  Wed Mar 14 23:27:51 2018
From: lars at nocrew.org (Lars Brinkhoff)
Date: Wed, 14 Mar 2018 13:27:51 +0000
Subject: [TUHS] Illinois PDP-11 Network Unix
In-Reply-To: <20180314125856.E4A3818C0DD@mercury.lcs.mit.edu> (Noel Chiappa's
 message of "Wed, 14 Mar 2018 08:58:56 -0400 (EDT)")
References: <20180314125856.E4A3818C0DD@mercury.lcs.mit.edu>
Message-ID: <7wlgeubxd4.fsf@junk.nocrew.org>

Noel Chiappa writes:
>     > Is this "Network Unix" available?
> ??? This was announced here not long ago:
> http://minnie.tuhs.org/cgi-bin/utree.pl?file=SRI-NOSC

Thanks!  I didn't see the announcement.


From rminnich at gmail.com  Thu Mar 15 01:59:13 2018
From: rminnich at gmail.com (ron minnich)
Date: Wed, 14 Mar 2018 15:59:13 +0000
Subject: [TUHS] Illinois PDP-11 Network Unix
In-Reply-To: <7wlgeubxd4.fsf@junk.nocrew.org>
References: <20180314125856.E4A3818C0DD@mercury.lcs.mit.edu>
 <7wlgeubxd4.fsf@junk.nocrew.org>
Message-ID: <CAP6exYLe1rTdCVB7PKWYY=A9yo0yejFTz6bRMPFKrkYr8QJdAg@mail.gmail.com>

and does anyone still have their "I survived ..." badges for the conversion
to TCP?

On Wed, Mar 14, 2018 at 6:28 AM Lars Brinkhoff <lars at nocrew.org> wrote:

> Noel Chiappa writes:
> >     > Is this "Network Unix" available?
> > ??? This was announced here not long ago:
> > http://minnie.tuhs.org/cgi-bin/utree.pl?file=SRI-NOSC
>
> Thanks!  I didn't see the announcement.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180314/40a571dd/attachment.html>

From dave at horsfall.org  Thu Mar 15 07:14:35 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Thu, 15 Mar 2018 08:14:35 +1100 (EST)
Subject: [TUHS] Happy birthday, symbolics.com!
Message-ID: <alpine.BSF.2.21.1803150808270.819@aneurin.horsfall.org>

The first Internet domain, symbolics.com, was registered in 1985 at 0500Z 
("Zulu" time, i.e. UTC).

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."


From pete at nomadlogic.org  Thu Mar 15 07:18:16 2018
From: pete at nomadlogic.org (Pete Wright)
Date: Wed, 14 Mar 2018 14:18:16 -0700
Subject: [TUHS] Happy birthday, symbolics.com!
In-Reply-To: <alpine.BSF.2.21.1803150808270.819@aneurin.horsfall.org>
References: <alpine.BSF.2.21.1803150808270.819@aneurin.horsfall.org>
Message-ID: <fa0555d7-4d58-8e8d-4570-b765563f8e78@nomadlogic.org>



On 03/14/2018 14:14, Dave Horsfall wrote:
> The first Internet domain, symbolics.com, was registered in 1985 at 
> 0500Z ("Zulu" time, i.e. UTC).
>

This was well before my time, so pardon my ignorance here, but who was 
the registrar that they used to register this domain?

thanks!
-pete


-- 
Pete Wright
pete at nomadlogic.org
@nomadlogicLA



From angus at fairhaven.za.net  Thu Mar 15 08:14:26 2018
From: angus at fairhaven.za.net (Angus Robinson)
Date: Wed, 14 Mar 2018 22:14:26 +0000
Subject: [TUHS] Happy birthday, symbolics.com!
In-Reply-To: <fa0555d7-4d58-8e8d-4570-b765563f8e78@nomadlogic.org>
References: <alpine.BSF.2.21.1803150808270.819@aneurin.horsfall.org>
 <fa0555d7-4d58-8e8d-4570-b765563f8e78@nomadlogic.org>
Message-ID: <CAE49LG=P7pcFbKz5nM9erKUbMC8CDwkg2umfjGx-U6GDFa=JjA@mail.gmail.com>

According to wikipoedia, .com was setup in January of 1985 and was
administered by the US Department of Defense. Although they contracted SRI
International, which in turn created DDN-NIC (SRI-NIC), which was found at
nic.ddn.mil.

Assuming they registered it under SRI-NIC.

On Wed, Mar 14, 2018 at 2:18 PM Pete Wright <pete at nomadlogic.org> wrote:

>
>
> On 03/14/2018 14:14, Dave Horsfall wrote:
> > The first Internet domain, symbolics.com, was registered in 1985 at
> > 0500Z ("Zulu" time, i.e. UTC).
> >
>
> This was well before my time, so pardon my ignorance here, but who was
> the registrar that they used to register this domain?
>
> thanks!
> -pete
>
>
> --
> Pete Wright
> pete at nomadlogic.org
> @nomadlogicLA
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180314/694d6395/attachment.html>

From pete at nomadlogic.org  Thu Mar 15 08:19:04 2018
From: pete at nomadlogic.org (Pete Wright)
Date: Wed, 14 Mar 2018 15:19:04 -0700
Subject: [TUHS] Happy birthday, symbolics.com!
In-Reply-To: <CAE49LG=P7pcFbKz5nM9erKUbMC8CDwkg2umfjGx-U6GDFa=JjA@mail.gmail.com>
References: <alpine.BSF.2.21.1803150808270.819@aneurin.horsfall.org>
 <fa0555d7-4d58-8e8d-4570-b765563f8e78@nomadlogic.org>
 <CAE49LG=P7pcFbKz5nM9erKUbMC8CDwkg2umfjGx-U6GDFa=JjA@mail.gmail.com>
Message-ID: <f37d3cc6-8646-9905-b2cf-0a93ce20d5c7@nomadlogic.org>



On 03/14/2018 15:14, Angus Robinson wrote:
> According to wikipoedia, .com was setup in January of 1985 and was 
> administered by the US Department of Defense. Although they contracted 
> SRI International, which in turn created DDN-NIC (SRI-NIC), which was 
> found at nic.ddn.mil <http://nic.ddn.mil>.
>
> Assuming they registered it under SRI-NIC.
>
interesting - thanks!  this makes sense in hindsight :)

-pete

-- 
Pete Wright
pete at nomadlogic.org
@nomadlogicLA

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180314/169dbc8e/attachment.html>

From jnc at mercury.lcs.mit.edu  Thu Mar 15 08:00:45 2018
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Wed, 14 Mar 2018 18:00:45 -0400 (EDT)
Subject: [TUHS] Happy birthday, symbolics.com!
Message-ID: <20180314220045.269EC18C0D3@mercury.lcs.mit.edu>

    > From: Pete Wright

    > who was the registrar that they used to register this domain?

Postel (or one of his minions).

       Noel


From michael at kjorling.se  Thu Mar 15 08:23:09 2018
From: michael at kjorling.se (Michael =?utf-8?B?S2rDtnJsaW5n?=)
Date: Wed, 14 Mar 2018 22:23:09 +0000
Subject: [TUHS] Happy birthday, symbolics.com!
In-Reply-To: <alpine.BSF.2.21.1803150808270.819@aneurin.horsfall.org>
References: <alpine.BSF.2.21.1803150808270.819@aneurin.horsfall.org>
Message-ID: <20180314222309.GO16269@h-174-65.A328.priv.bahnhof.se>

On 15 Mar 2018 08:14 +1100, from dave at horsfall.org (Dave Horsfall):
> The first Internet domain, symbolics.com,

What qualifies as an "Internet domain" in this context? I'm honestly
curious about the definition you're using.

Poking at RFCs at random, RFC 820 mentions mailboxes with SMTP-style
(as opposed to e.g. UUCP) addresses, but with only a single label as
the hostname (for example, "KLH at NIC" or "Hinden at BBN-Unix"). That one
is dated January 1983.

The August 1982 (!?) RFC 821 has example SMTP conversations that use
addresses on the form foo at bar.ARPA. So the concept of domain names
similar to today certainly existed before 1985, and the DNS RFCs
(initially 1034, 1035) were only published in 1987...

So by what definition would symbolics.com in 1985 be the first
Internet domain registered?

-- 
Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se
  “The most dangerous thought that you can have as a creative person
              is to think you know what you’re doing.” (Bret Victor)


From krewat at kilonet.net  Thu Mar 15 08:42:12 2018
From: krewat at kilonet.net (Arthur Krewat)
Date: Wed, 14 Mar 2018 18:42:12 -0400
Subject: [TUHS] Happy birthday, symbolics.com!
In-Reply-To: <20180314222309.GO16269@h-174-65.A328.priv.bahnhof.se>
References: <alpine.BSF.2.21.1803150808270.819@aneurin.horsfall.org>
 <20180314222309.GO16269@h-174-65.A328.priv.bahnhof.se>
Message-ID: <13236cac-eb96-7527-0eca-9ed1bb998dfb@kilonet.net>

The key might be in the definition/timing of the term "Internet".

;)



On 3/14/2018 6:23 PM, Michael Kjörling wrote:
> On 15 Mar 2018 08:14 +1100, from dave at horsfall.org (Dave Horsfall):
>> The first Internet domain, symbolics.com,
> What qualifies as an "Internet domain" in this context? I'm honestly
> curious about the definition you're using.
>
> Poking at RFCs at random, RFC 820 mentions mailboxes with SMTP-style
> (as opposed to e.g. UUCP) addresses, but with only a single label as
> the hostname (for example, "KLH at NIC" or "Hinden at BBN-Unix"). That one
> is dated January 1983.
>
> The August 1982 (!?) RFC 821 has example SMTP conversations that use
> addresses on the form foo at bar.ARPA. So the concept of domain names
> similar to today certainly existed before 1985, and the DNS RFCs
> (initially 1034, 1035) were only published in 1987...
>
> So by what definition would symbolics.com in 1985 be the first
> Internet domain registered?
>



From ggm at algebras.org  Thu Mar 15 08:52:10 2018
From: ggm at algebras.org (George Michaelson)
Date: Thu, 15 Mar 2018 08:52:10 +1000
Subject: [TUHS] Happy birthday, symbolics.com!
In-Reply-To: <13236cac-eb96-7527-0eca-9ed1bb998dfb@kilonet.net>
References: <alpine.BSF.2.21.1803150808270.819@aneurin.horsfall.org>
 <20180314222309.GO16269@h-174-65.A328.priv.bahnhof.se>
 <13236cac-eb96-7527-0eca-9ed1bb998dfb@kilonet.net>
Message-ID: <CAKr6gn2+M9AHBXK_4QiKGwurm5Qi2WH=ONwYtd9kgP4vvxw+Og@mail.gmail.com>

the key might be in the meaning of the word 'register'

getting into a honeydanber database used to be as simple as posting
news with structured text.


From dave at horsfall.org  Thu Mar 15 08:58:12 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Thu, 15 Mar 2018 09:58:12 +1100 (EST)
Subject: [TUHS] Happy birthday, symbolics.com!
In-Reply-To: <20180314220045.269EC18C0D3@mercury.lcs.mit.edu>
References: <20180314220045.269EC18C0D3@mercury.lcs.mit.edu>
Message-ID: <alpine.BSF.2.21.1803150956500.819@aneurin.horsfall.org>

On Wed, 14 Mar 2018, Noel Chiappa wrote:

>    > who was the registrar that they used to register this domain?
>
> Postel (or one of his minions).

If so, he would've been the registraNT, no?

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."


From jnc at mercury.lcs.mit.edu  Thu Mar 15 09:01:06 2018
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Wed, 14 Mar 2018 19:01:06 -0400 (EDT)
Subject: [TUHS] Happy birthday, symbolics.com!
Message-ID: <20180314230106.B622618C0D3@mercury.lcs.mit.edu>

    > From: Michael Kjörling

    > the DNS RFCs (initially 1034, 1035) were only published in 1987...

Ah, those were later versions; the originals were:

  0882 Domain names: Concepts and facilities. P.V. Mockapetris. November
     1983.
  0883 Domain names: Implementation specification. P.V. Mockapetris.
     November 1983.

Both were updated by RFC0973 before being replaced by 1034/1035.

You might also want to look at:

  0881 Domain names plan and schedule. J. Postel. November 1983.
  0897 Domain name system implementation schedule. J. Postel. February 1984.
  0921 Domain name system implementation schedule - revised. J. Postel. October 1984. 

Note that ".com" didn't exist in the early revs.

     Noel


From krewat at kilonet.net  Thu Mar 15 09:05:49 2018
From: krewat at kilonet.net (Arthur Krewat)
Date: Wed, 14 Mar 2018 19:05:49 -0400
Subject: [TUHS] Happy birthday, symbolics.com!
In-Reply-To: <CAKr6gn2+M9AHBXK_4QiKGwurm5Qi2WH=ONwYtd9kgP4vvxw+Og@mail.gmail.com>
References: <alpine.BSF.2.21.1803150808270.819@aneurin.horsfall.org>
 <20180314222309.GO16269@h-174-65.A328.priv.bahnhof.se>
 <13236cac-eb96-7527-0eca-9ed1bb998dfb@kilonet.net>
 <CAKr6gn2+M9AHBXK_4QiKGwurm5Qi2WH=ONwYtd9kgP4vvxw+Og@mail.gmail.com>
Message-ID: <65ceb1b7-67db-3cef-ce21-a6c7854b4600@kilonet.net>

On 3/14/2018 6:52 PM, George Michaelson wrote:
> the key might be in the meaning of the word 'register'
>
> getting into a honeydanber database used to be as simple as posting
> news with structured text.
>
Quite true.


From jnc at mercury.lcs.mit.edu  Thu Mar 15 09:07:33 2018
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Wed, 14 Mar 2018 19:07:33 -0400 (EDT)
Subject: [TUHS] Happy birthday, symbolics.com!
Message-ID: <20180314230733.2CC3218C0D3@mercury.lcs.mit.edu>

    > From: Dave Horsfall

    > he would've been the registraNT, no?

Symbolics was the registrant.

I may have spoken too soon, Postel/ISI might not have been the registrar when
".com" was set up, so maybe it was someone at SRI/NIC. (The memory is dim.) I
don't remember how "MIT.EDU" got registered - I'm not sure if I did it. It
was definitely Jon handing out addresses, not SRI - I do recall us going to
Jon to get 128.30 & 31.

	Noel


From imp at bsdimp.com  Thu Mar 15 09:22:13 2018
From: imp at bsdimp.com (Warner Losh)
Date: Wed, 14 Mar 2018 17:22:13 -0600
Subject: [TUHS] Happy birthday, symbolics.com!
In-Reply-To: <CAE49LG=P7pcFbKz5nM9erKUbMC8CDwkg2umfjGx-U6GDFa=JjA@mail.gmail.com>
References: <alpine.BSF.2.21.1803150808270.819@aneurin.horsfall.org>
 <fa0555d7-4d58-8e8d-4570-b765563f8e78@nomadlogic.org>
 <CAE49LG=P7pcFbKz5nM9erKUbMC8CDwkg2umfjGx-U6GDFa=JjA@mail.gmail.com>
Message-ID: <CANCZdfq3gRLMPUWbP-U+7_jUSeJx0wkLiT=gF8Gj+QQNXXNyMQ@mail.gmail.com>

nic.ddn.mil post-dated symbolics.com registering by a couple of years. They
had a complicated form to fill out to get a domain name after the less
formal system became too burdensome to scale.

Warner

On Wed, Mar 14, 2018 at 4:14 PM, Angus Robinson <angus at fairhaven.za.net>
wrote:

> According to wikipoedia, .com was setup in January of 1985 and was
> administered by the US Department of Defense. Although they contracted SRI
> International, which in turn created DDN-NIC (SRI-NIC), which was found at
> nic.ddn.mil.
>
> Assuming they registered it under SRI-NIC.
>
> On Wed, Mar 14, 2018 at 2:18 PM Pete Wright <pete at nomadlogic.org> wrote:
>
>>
>>
>> On 03/14/2018 14:14, Dave Horsfall wrote:
>> > The first Internet domain, symbolics.com, was registered in 1985 at
>> > 0500Z ("Zulu" time, i.e. UTC).
>> >
>>
>> This was well before my time, so pardon my ignorance here, but who was
>> the registrar that they used to register this domain?
>>
>> thanks!
>> -pete
>>
>>
>> --
>> Pete Wright
>> pete at nomadlogic.org
>> @nomadlogicLA
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180314/4d51b492/attachment.html>

From ggm at algebras.org  Thu Mar 15 09:31:01 2018
From: ggm at algebras.org (George Michaelson)
Date: Thu, 15 Mar 2018 09:31:01 +1000
Subject: [TUHS] Happy birthday, symbolics.com!
In-Reply-To: <CANCZdfq3gRLMPUWbP-U+7_jUSeJx0wkLiT=gF8Gj+QQNXXNyMQ@mail.gmail.com>
References: <alpine.BSF.2.21.1803150808270.819@aneurin.horsfall.org>
 <fa0555d7-4d58-8e8d-4570-b765563f8e78@nomadlogic.org>
 <CAE49LG=P7pcFbKz5nM9erKUbMC8CDwkg2umfjGx-U6GDFa=JjA@mail.gmail.com>
 <CANCZdfq3gRLMPUWbP-U+7_jUSeJx0wkLiT=gF8Gj+QQNXXNyMQ@mail.gmail.com>
Message-ID: <CAKr6gn1knK-3TL4iA0MGzxwt7Z7wTV4Xg_veQzPQq70qvBeQrQ@mail.gmail.com>

I was at UCL-CS when we turned on DNS in 85/6 -This was the eastern
end of the spiral arm of the galaxy, feeding MoD and Goonhilly downs
and the Post Office, as well as a rather odd service mapping ARPAnet
to JANET via kermit amongst other things.  Smoke filled rooms with
spooks in dark glasses and men with ribbon-chest-boards were mentioned
in passing when UCL staff went to SRI for meetings. Odd times. I never
went. Bob Braden came over for some liaison meeting at the end of
SATNET (2meg satlink, huge for the day) and was grumpy because due
deference was not shown. Mike Lesk came for a long residency. he was
nice, chatty, obsessed with Tristram Shandy. I liked him more.

At one level, "nothing happened" because mail and news still flowed as
it used to. But random connects in FTP and Telnet now had subtly
different underpinnings. Before this turn-on, when we used
/etc/hosts.txt in anger we could wind up being delayed beyond the 30
second login timer and fail to connect for service because lookups
files timed out. After this turn-on, we connected more reliably more
often.  I was doing OSI code work, and had to share some files with
people at BRL and UDel and other places, it was a real pain in the
neck.

The fuzzball had been turned off in favour of a BBN butterfly. oooooh
multiprocessing. sexy. Also flakey as hell.

I had root on some of the boxes, two or three flicks of configuration
changed from one t'other and back again.  It was hard to get excited
about it because ubiquitous meant still having serial-line
communications with UUCP and dealing with Jacob Palme in his
not-quite-USENET world of research mailing lists, and bitnet.  mmdf
and news looks the same if you ship the bytes on tape, in the end.

On Thu, Mar 15, 2018 at 9:22 AM, Warner Losh <imp at bsdimp.com> wrote:
> nic.ddn.mil post-dated symbolics.com registering by a couple of years. They
> had a complicated form to fill out to get a domain name after the less
> formal system became too burdensome to scale.
>
> Warner
>
>
> On Wed, Mar 14, 2018 at 4:14 PM, Angus Robinson <angus at fairhaven.za.net>
> wrote:
>>
>> According to wikipoedia, .com was setup in January of 1985 and was
>> administered by the US Department of Defense. Although they contracted SRI
>> International, which in turn created DDN-NIC (SRI-NIC), which was found at
>> nic.ddn.mil.
>>
>> Assuming they registered it under SRI-NIC.
>>
>> On Wed, Mar 14, 2018 at 2:18 PM Pete Wright <pete at nomadlogic.org> wrote:
>>>
>>>
>>>
>>> On 03/14/2018 14:14, Dave Horsfall wrote:
>>> > The first Internet domain, symbolics.com, was registered in 1985 at
>>> > 0500Z ("Zulu" time, i.e. UTC).
>>> >
>>>
>>> This was well before my time, so pardon my ignorance here, but who was
>>> the registrar that they used to register this domain?
>>>
>>> thanks!
>>> -pete
>>>
>>>
>>> --
>>> Pete Wright
>>> pete at nomadlogic.org
>>> @nomadlogicLA
>>>
>


From imp at bsdimp.com  Thu Mar 15 09:38:55 2018
From: imp at bsdimp.com (Warner Losh)
Date: Wed, 14 Mar 2018 17:38:55 -0600
Subject: [TUHS] Happy birthday, symbolics.com!
In-Reply-To: <CANCZdfq3gRLMPUWbP-U+7_jUSeJx0wkLiT=gF8Gj+QQNXXNyMQ@mail.gmail.com>
References: <alpine.BSF.2.21.1803150808270.819@aneurin.horsfall.org>
 <fa0555d7-4d58-8e8d-4570-b765563f8e78@nomadlogic.org>
 <CAE49LG=P7pcFbKz5nM9erKUbMC8CDwkg2umfjGx-U6GDFa=JjA@mail.gmail.com>
 <CANCZdfq3gRLMPUWbP-U+7_jUSeJx0wkLiT=gF8Gj+QQNXXNyMQ@mail.gmail.com>
Message-ID: <CANCZdfrnQijCPtKQ6EeGnPgKyQWPqOEO1=z5PmLJ7nW2Ry-COQ@mail.gmail.com>

Sorry to reply to myself....

But for a few years after we started registering names, requests went to
hostmaster at sri-nic.arpa. Around 1987 or so, a big email came out that said
you had to go through hostmaster at nic.ddn.mil to get them, and you needed to
fill out an email form that was programmatically parsed. I recall from the
day that getting domains registers was a hit-or-miss sort of affair, since
the parser was super picky. I know a friend missed out on grue.com because
his first attempt had some misplaced word and by the time he heard back and
redid it, someone else had jumped in line in front of him...

Warner

On Wed, Mar 14, 2018 at 5:22 PM, Warner Losh <imp at bsdimp.com> wrote:

> nic.ddn.mil post-dated symbolics.com registering by a couple of years.
> They had a complicated form to fill out to get a domain name after the less
> formal system became too burdensome to scale.
>
> Warner
>
>
> On Wed, Mar 14, 2018 at 4:14 PM, Angus Robinson <angus at fairhaven.za.net>
> wrote:
>
>> According to wikipoedia, .com was setup in January of 1985 and was
>> administered by the US Department of Defense. Although they contracted SRI
>> International, which in turn created DDN-NIC (SRI-NIC), which was found at
>> nic.ddn.mil.
>>
>> Assuming they registered it under SRI-NIC.
>>
>> On Wed, Mar 14, 2018 at 2:18 PM Pete Wright <pete at nomadlogic.org> wrote:
>>
>>>
>>>
>>> On 03/14/2018 14:14, Dave Horsfall wrote:
>>> > The first Internet domain, symbolics.com, was registered in 1985 at
>>> > 0500Z ("Zulu" time, i.e. UTC).
>>> >
>>>
>>> This was well before my time, so pardon my ignorance here, but who was
>>> the registrar that they used to register this domain?
>>>
>>> thanks!
>>> -pete
>>>
>>>
>>> --
>>> Pete Wright
>>> pete at nomadlogic.org
>>> @nomadlogicLA
>>>
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180314/56da9727/attachment.html>

From crossd at gmail.com  Fri Mar 16 01:29:11 2018
From: crossd at gmail.com (Dan Cross)
Date: Thu, 15 Mar 2018 11:29:11 -0400
Subject: [TUHS] Origin of the MOTD file?
Message-ID: <CAEoi9W49jx_hrNd11meGGJi00cZ+FDs9BtB_W7b2c=drujzNSA@mail.gmail.com>

One of the things that's always fascinated me about Unix is the community
aspect; in particular, I imagine that in the early days when machines were
multiplexed among many simultaneous users, I wonder whether there was a
greater sense of knowing what others were up to, working on, or generally
doing.

I think of the /etc/motd file as being a part of this. It is, in some very
real sense, a way to announce things to the entire user community.

So what are its origins? Where did it first appear? I haven't dug into
this, but I imagine it was at Berkeley. What was it used for early on at
individual sites?

        - Dan C.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180315/d9912e94/attachment.html>

From ron at ronnatalie.com  Fri Mar 16 01:35:22 2018
From: ron at ronnatalie.com (Ron Natalie)
Date: Thu, 15 Mar 2018 11:35:22 -0400
Subject: [TUHS] Origin of the MOTD file?
In-Reply-To: <CAEoi9W49jx_hrNd11meGGJi00cZ+FDs9BtB_W7b2c=drujzNSA@mail.gmail.com>
References: <CAEoi9W49jx_hrNd11meGGJi00cZ+FDs9BtB_W7b2c=drujzNSA@mail.gmail.com>
Message-ID: <001d01d3bc73$3bcf5220$b36df660$@ronnatalie.com>

 

Ø  So what are its origins? Where did it first appear? I haven't dug into this, but I imagine it was at Berkeley. What was it used for early on at individual sites?

 

It was certainly present in Version 6 UNIX, so it predates Berkeley.    While it being a “file” is very UNIX-ish, the concept of a settable sign on message doesn’t originate with UNIX.    I had used other systems that ran a user defined program on user login (sort of a compiled .profile) and it was common to put the system “news” in such.

 

One amusing thing to do with /etc/motd is to add the like “You might have mail.”    I thought it was a cute joke, but I never realized how much confusion it would cause.     I did it at BRL and had people sending me email asking why they didn’t have mail (it only said you MIGHT).


I told one of my student programmers working for me at Rutgers that if he put that in the motd on one of our systems I guaranteed within an hour someone will tell us they didn’t have mail.
It took about 15 minutes for one of my SENIOR systems programmers to come into the office and tell me that.

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180315/8de060a6/attachment.html>

From ron at ronnatalie.com  Fri Mar 16 01:41:11 2018
From: ron at ronnatalie.com (Ron Natalie)
Date: Thu, 15 Mar 2018 11:41:11 -0400
Subject: [TUHS] Origin of the MOTD file?
In-Reply-To: <d0099789-dc3b-2f0a-59b3-0c72c3c896c0@case.edu>
References: <CAEoi9W49jx_hrNd11meGGJi00cZ+FDs9BtB_W7b2c=drujzNSA@mail.gmail.com>
 <001d01d3bc73$3bcf5220$b36df660$@ronnatalie.com>
 <d0099789-dc3b-2f0a-59b3-0c72c3c896c0@case.edu>
Message-ID: <002d01d3bc74$0bbab510$23301f30$@ronnatalie.com>


> Try adding "Segmentation Fault (core dumped)".

About the time  computers went from being a tool of the research geeks to operational use at BRL (we went from senior management saying "don't send us email, we don't read it" to management telling everybody "they must check their email regularly for important messages from them:"), the security officers found out about /etc/motd.    They would periodically put the same kind of "security rah rah" stuff we had posters all over the facility ("Strike up the band for safety.", etc...).    After a few months of this I started sneaking in slogans of my own.   The first few (things like "Security is good") escaped notice.    But they caught on the day I put up "Even the ears have walls."




From chet.ramey at case.edu  Fri Mar 16 01:36:49 2018
From: chet.ramey at case.edu (Chet Ramey)
Date: Thu, 15 Mar 2018 11:36:49 -0400
Subject: [TUHS] Origin of the MOTD file?
In-Reply-To: <001d01d3bc73$3bcf5220$b36df660$@ronnatalie.com>
References: <CAEoi9W49jx_hrNd11meGGJi00cZ+FDs9BtB_W7b2c=drujzNSA@mail.gmail.com>
 <001d01d3bc73$3bcf5220$b36df660$@ronnatalie.com>
Message-ID: <d0099789-dc3b-2f0a-59b3-0c72c3c896c0@case.edu>

On 3/15/18 11:35 AM, Ron Natalie wrote:

> One amusing thing to do with /etc/motd is to add the like “You might have
> mail.”    I thought it was a cute joke, but I never realized how much
> confusion it would cause.     I did it at BRL and had people sending me
> email asking why they didn’t have mail (it only said you MIGHT).

Try adding "Segmentation Fault (core dumped)".


-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet at case.edu    http://tiswww.cwru.edu/~chet/


From clemc at ccc.com  Fri Mar 16 01:51:59 2018
From: clemc at ccc.com (Clem Cole)
Date: Thu, 15 Mar 2018 11:51:59 -0400
Subject: [TUHS] Origin of the MOTD file?
In-Reply-To: <CAEoi9W49jx_hrNd11meGGJi00cZ+FDs9BtB_W7b2c=drujzNSA@mail.gmail.com>
References: <CAEoi9W49jx_hrNd11meGGJi00cZ+FDs9BtB_W7b2c=drujzNSA@mail.gmail.com>
Message-ID: <CAC20D2MSuHUt_1c8ne-3L7_2=jaTSs856bvVRk3o+uyDz+aj4Q@mail.gmail.com>

On Thu, Mar 15, 2018 at 11:29 AM, Dan Cross <crossd at gmail.com> wrote:

> One of the things that's always fascinated me about Unix is the community
> aspect; in particular, I imagine that in the early days when machines were
> multiplexed among many simultaneous users, I wonder whether there was a
> greater sense of knowing what others were up to, working on, or generally
> doing.
>
> I think of the /etc/motd file as being a part of this. It is, in some very
> real sense, a way to announce things to the entire user community.
>
> So what are its origins? Where did it first appear? I haven't dug into
> this, but I imagine it was at Berkeley. What was it used for early on at
> individual sites?
>

​I'm pretty sure it predates the #1 editions, if check the sources for the
login program on TUHS you can be sure. Steve Johnson and others have
pointed out that systems people (such as Dennis) were often night owls and
often added/changed things​ in the UNIX group or their own systems.   This
was no different than the way other systems (such as timesharing system
like TOPS or TSS worked).   System time in the day was expensive and if you
wanted to make a change the affected a lot of people, you did it 'off
hours.'

Remember, most people in those days were 'dialing in' or going to a
terminal room.   So you got a fresh log in session once or twice a day.
 So, I believe that the idea of motd was to have a standard place where
everyone could get messages that might affect them and be pretty sure you
saw it before you started your work.

For instance, two messages I can think of I put the EE/Mellon systems years
ago were on the order of:  *'New Pascal compiler installed, should fix the
core dump issue Tron was having - send me email if you are still having
issues.   Clem'*    Or  *'Klone and I just updated our RK07 disk driver to
add bad disk block support -- we think its working as far as we have been
able to test.   If you notice something strange, please check the console
log before you call either us..  Clem'*

You get the idea,
Clem

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

From clemc at ccc.com  Fri Mar 16 01:53:17 2018
From: clemc at ccc.com (Clem Cole)
Date: Thu, 15 Mar 2018 11:53:17 -0400
Subject: [TUHS] Origin of the MOTD file?
In-Reply-To: <CAC20D2MSuHUt_1c8ne-3L7_2=jaTSs856bvVRk3o+uyDz+aj4Q@mail.gmail.com>
References: <CAEoi9W49jx_hrNd11meGGJi00cZ+FDs9BtB_W7b2c=drujzNSA@mail.gmail.com>
 <CAC20D2MSuHUt_1c8ne-3L7_2=jaTSs856bvVRk3o+uyDz+aj4Q@mail.gmail.com>
Message-ID: <CAC20D2ON5GzWLOeobuLWwujX8hhnd3f9ao+u0Jd-_pTWM1o9qA@mail.gmail.com>

On Thu, Mar 15, 2018 at 11:51 AM, Clem Cole <clemc at ccc.com> wrote:

>
>
> ​I'm pretty sure it predates the #1 editions
>

​The numbered editions is what I was trying to say....​
ᐧ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180315/524e0ba3/attachment.html>

From ron at ronnatalie.com  Fri Mar 16 02:55:20 2018
From: ron at ronnatalie.com (Ron Natalie)
Date: Thu, 15 Mar 2018 12:55:20 -0400
Subject: [TUHS] Origin of the MOTD file?
In-Reply-To: <CAC20D2MSuHUt_1c8ne-3L7_2=jaTSs856bvVRk3o+uyDz+aj4Q@mail.gmail.com>
References: <CAEoi9W49jx_hrNd11meGGJi00cZ+FDs9BtB_W7b2c=drujzNSA@mail.gmail.com>
 <CAC20D2MSuHUt_1c8ne-3L7_2=jaTSs856bvVRk3o+uyDz+aj4Q@mail.gmail.com>
Message-ID: <005301d3bc7e$67807790$368166b0$@ronnatalie.com>

One of the funniest I saw was logging into a Denelcor engineering machine.   Their company slogan was “Tomorrow’s computers…Today.”
I logged in to see the message “Tomorrow’s computers…some time next month.”



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180315/a418b70e/attachment.html>

From reed at reedmedia.net  Fri Mar 16 04:04:51 2018
From: reed at reedmedia.net (Jeremy C. Reed)
Date: Thu, 15 Mar 2018 13:04:51 -0500 (CDT)
Subject: [TUHS] Origin of the MOTD file?
In-Reply-To: <CAEoi9W49jx_hrNd11meGGJi00cZ+FDs9BtB_W7b2c=drujzNSA@mail.gmail.com>
References: <CAEoi9W49jx_hrNd11meGGJi00cZ+FDs9BtB_W7b2c=drujzNSA@mail.gmail.com>
Message-ID: <alpine.NEB.2.20.1803151300180.25928@t1.m.reedmedia.net>

(A similar question was asked a month ago here. From my response then 
...)

v1 has the concept "message of the day"
http://minnie.tuhs.org/cgi-bin/utree.pl?file=V1/man/man7/login.7
but I don't find the code for it.

v2 login reads "/etc/motd"
http://minnie.tuhs.org/cgi-bin/utree.pl?file=V2/cmd/login.s

By the way, where is the code for the shell referenced in init.s for 
the earlier Unix? http://minnie.tuhs.org/cgi-bin/utree.pl?file=PDP7-Unix 


From dot at dotat.at  Fri Mar 16 05:38:05 2018
From: dot at dotat.at (Tony Finch)
Date: Thu, 15 Mar 2018 19:38:05 +0000
Subject: [TUHS] Happy birthday, symbolics.com!
In-Reply-To: <20180314222309.GO16269@h-174-65.A328.priv.bahnhof.se>
References: <alpine.BSF.2.21.1803150808270.819@aneurin.horsfall.org>
 <20180314222309.GO16269@h-174-65.A328.priv.bahnhof.se>
Message-ID: <alpine.DEB.2.11.1803151929460.690@grey.csi.cam.ac.uk>

Michael Kjörling <michael at kjorling.se> wrote:
>
> So by what definition would symbolics.com in 1985 be the first
> Internet domain registered?

As I understand it, the old hosts.txt registrations got grandfathered into
the DNS in the .arpa zone - they were ARPANET hosts (e.g. see RFC 921).
The modern structure was set up after the transition to IP, so it's fair
to call .com and friends Internet domains. (See RFC 920.)

But it looks like there were a bunch of .edu and .gov names before
Symbolics.

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/  -  I xn--zr8h punycode
Northeast Viking, North Utsire: Southeasterly 5 to 7, occasionally gale 8 in
south, decreasing 4 at times in north. Moderate or rough in northern and
eastern North Utsire, otherwise rough or very rough. Fair. Good.

From dot at dotat.at  Fri Mar 16 05:44:29 2018
From: dot at dotat.at (Tony Finch)
Date: Thu, 15 Mar 2018 19:44:29 +0000
Subject: [TUHS] Happy birthday, symbolics.com!
In-Reply-To: <fa0555d7-4d58-8e8d-4570-b765563f8e78@nomadlogic.org>
References: <alpine.BSF.2.21.1803150808270.819@aneurin.horsfall.org>
 <fa0555d7-4d58-8e8d-4570-b765563f8e78@nomadlogic.org>
Message-ID: <alpine.DEB.2.11.1803151938480.690@grey.csi.cam.ac.uk>

Pete Wright <pete at nomadlogic.org> wrote:
>
> This was well before my time, so pardon my ignorance here, but who was
> the registrar that they used to register this domain?

Registrars are a late 1990s concept :-) They are a consequence of the
effort to break up the Network Solutions monopoly - the IAHC and the
foundation of ICANN. (Another consequence was the introduction of new
TLDs.) The early technical mechanism underpinning this policy decision was
the registry-registrar protocol (RRP, RFC 2832) which has a much more
straightforward name (and design) than its successor EPP, the extensible
provisioning protocol.

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/  -  I xn--zr8h punycode
Northeast Viking, North Utsire: Southeasterly 5 to 7, occasionally gale 8 in
south, decreasing 4 at times in north. Moderate or rough in northern and
eastern North Utsire, otherwise rough or very rough. Fair. Good.


From doug at cs.dartmouth.edu  Fri Mar 16 06:00:10 2018
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Thu, 15 Mar 2018 16:00:10 -0400
Subject: [TUHS] Origin of the MOTD file?
Message-ID: <201803152000.w2FK0Aul031777@coolidge.cs.Dartmouth.EDU>


> So what are its origins? Where did it first appear?

It was a direct copy from CTSS, which already had it
n 1965 when we BTL folk began to use it.

The greatest MOTD story of all time happened at CTSS.

To set the stage, the CTSS editor made a temp file,
always of the same name, in one's home directory.
The MOTD was posted by the administrator account.

The password file was plain text, maintained by
editing it.

And multiple people had access to the administrator
account.

It happened one day that one administrator was
working on the password file at the same time
another was posting MOTD. The result: the password
file (probably the most secret file on the system)
got posted as the MOTD (the most public).

Upon seeing the password file type out before him,
an alert user shut the machine down by writing
and running one line of assembly code:

	HERE	TRA *HERE

(The star is for indirect addressing, and indirection
was transitive.)

Doug


From dave at horsfall.org  Fri Mar 16 06:20:14 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Fri, 16 Mar 2018 07:20:14 +1100 (EST)
Subject: [TUHS] Origin of the MOTD file?
In-Reply-To: <d0099789-dc3b-2f0a-59b3-0c72c3c896c0@case.edu>
References: <CAEoi9W49jx_hrNd11meGGJi00cZ+FDs9BtB_W7b2c=drujzNSA@mail.gmail.com>
 <001d01d3bc73$3bcf5220$b36df660$@ronnatalie.com>
 <d0099789-dc3b-2f0a-59b3-0c72c3c896c0@case.edu>
Message-ID: <alpine.BSF.2.21.1803160713350.819@aneurin.horsfall.org>

On Thu, 15 Mar 2018, Chet Ramey wrote:

>> One amusing thing to do with /etc/motd is to add the like “You might 
>> have mail.”  [...]
>
> Try adding "Segmentation Fault (core dumped)".

I've done both of those, along with "System down for disk crashing at 
...".  It was sort of true, as it was scheduled maintenance which involved 
removing the RK-05 disks, prising them open with something like a speculum 
(in the open air!), and running some sort of a deflection gauge along the 
platter to see how warped it was.  I think the DEC Field Circus 
Ginger-Beer also wiped the heads and replaced the NiCd battery...

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

From imp at bsdimp.com  Fri Mar 16 06:25:17 2018
From: imp at bsdimp.com (Warner Losh)
Date: Thu, 15 Mar 2018 14:25:17 -0600
Subject: [TUHS] Origin of the MOTD file?
In-Reply-To: <alpine.BSF.2.21.1803160713350.819@aneurin.horsfall.org>
References: <CAEoi9W49jx_hrNd11meGGJi00cZ+FDs9BtB_W7b2c=drujzNSA@mail.gmail.com>
 <001d01d3bc73$3bcf5220$b36df660$@ronnatalie.com>
 <d0099789-dc3b-2f0a-59b3-0c72c3c896c0@case.edu>
 <alpine.BSF.2.21.1803160713350.819@aneurin.horsfall.org>
Message-ID: <CANCZdfr51Jm75o8nTyVtC8Ua1kmCQkunxinvuX0eCUyP5s+2OQ@mail.gmail.com>

On Thu, Mar 15, 2018 at 2:20 PM, Dave Horsfall <dave at horsfall.org> wrote:

> On Thu, 15 Mar 2018, Chet Ramey wrote:
>
> One amusing thing to do with /etc/motd is to add the like “You might have
>>> mail.”  [...]
>>>
>>
>> Try adding "Segmentation Fault (core dumped)".
>>
>
> I've done both of those, along with "System down for disk crashing at
> ...".  It was sort of true, as it was scheduled maintenance which involved
> removing the RK-05 disks, prising them open with something like a speculum
> (in the open air!), and running some sort of a deflection gauge along the
> platter to see how warped it was.  I think the DEC Field Circus Ginger-Beer
> also wiped the heads and replaced the NiCd battery...


At school, one of the admins had in place, for a day or three, a cron job
that randomly changed /etc/motd every few minutes to append one of several
variations of Segmentation Fault (core dumped), but it was deviously
different. "Segretation Fault (core dumped)" "Segmentation Fault (core
duped)" "Bussing Error (cops deployed)" etc

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180315/9fe18d43/attachment.html>

From dave at horsfall.org  Fri Mar 16 06:51:49 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Fri, 16 Mar 2018 07:51:49 +1100 (EST)
Subject: [TUHS] Origin of the MOTD file?
In-Reply-To: <201803152000.w2FK0Aul031777@coolidge.cs.Dartmouth.EDU>
References: <201803152000.w2FK0Aul031777@coolidge.cs.Dartmouth.EDU>
Message-ID: <alpine.BSF.2.21.1803160750490.819@aneurin.horsfall.org>

On Thu, 15 Mar 2018, Doug McIlroy wrote:

> The greatest MOTD story of all time happened at CTSS.

[...]

Thanks for the real story; I keep seeing various versions of it.

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."


From dave at horsfall.org  Fri Mar 16 07:04:21 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Fri, 16 Mar 2018 08:04:21 +1100 (EST)
Subject: [TUHS] Happy birthday, symbolics.com!
In-Reply-To: <alpine.DEB.2.11.1803151929460.690@grey.csi.cam.ac.uk>
References: <alpine.BSF.2.21.1803150808270.819@aneurin.horsfall.org>
 <20180314222309.GO16269@h-174-65.A328.priv.bahnhof.se>
 <alpine.DEB.2.11.1803151929460.690@grey.csi.cam.ac.uk>
Message-ID: <alpine.BSF.2.21.1803160757140.819@aneurin.horsfall.org>

On Thu, 15 Mar 2018, Tony Finch wrote:

> As I understand it, the old hosts.txt registrations got grandfathered 
> into the DNS in the .arpa zone - they were ARPANET hosts (e.g. see RFC 
> 921). The modern structure was set up after the transition to IP, so 
> it's fair to call .com and friends Internet domains. (See RFC 920.)

Yeah, I was referring to DNS as opposed to HOSTS.TXT of course.

> But it looks like there were a bunch of .edu and .gov names before 
> Symbolics.

I'm happy to be corrected/updated; I happen to have an interest in geeky 
history (as if that wasn't apparent).

> -- 
> f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/  -  I xn--zr8h punycode
> Northeast Viking, North Utsire: Southeasterly 5 to 7, occasionally gale 8 in
> south, decreasing 4 at times in north. Moderate or rough in northern and
> eastern North Utsire, otherwise rough or very rough. Fair. Good.

OK, I'll bite: how do you do this?

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."


From dot at dotat.at  Fri Mar 16 19:51:12 2018
From: dot at dotat.at (Tony Finch)
Date: Fri, 16 Mar 2018 09:51:12 +0000
Subject: [TUHS] Happy birthday, symbolics.com!
In-Reply-To: <alpine.BSF.2.21.1803160757140.819@aneurin.horsfall.org>
References: <alpine.BSF.2.21.1803150808270.819@aneurin.horsfall.org>
 <20180314222309.GO16269@h-174-65.A328.priv.bahnhof.se>
 <alpine.DEB.2.11.1803151929460.690@grey.csi.cam.ac.uk>
 <alpine.BSF.2.21.1803160757140.819@aneurin.horsfall.org>
Message-ID: <alpine.DEB.2.11.1803160940460.25218@grey.csi.cam.ac.uk>

Dave Horsfall <dave at horsfall.org> wrote:
>
> OK, I'll bite: how do you do this?

A script that massages the data from the Met Office Shipping Forecast and
prints it into a named pipe which my MUA reads from.
http://www.metoffice.gov.uk/public/data/CoreProductCache/ShippingForecast/Latest
It's XML now, but when I started using this .sig the data looked like it
was coming from a system designed for distributing the forecast via telex.
(Radio telex to ships maybe?)

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/  -  I xn--zr8h punycode
Rockall, Malin, Hebrides, Bailey: Southerly or southeasterly, 4 or 5 at first
in south Rockall, otherwise 6 to gale 8. Moderate in east Malin and east
Hebrides, otherwise rough or very rough, occasionally high at first in
Hebrides and Bailey. Rain at times. Moderate or good.


From tfb at tfeb.org  Fri Mar 16 22:00:21 2018
From: tfb at tfeb.org (Tim Bradshaw)
Date: Fri, 16 Mar 2018 12:00:21 +0000
Subject: [TUHS] Happy birthday, symbolics.com!
In-Reply-To: <alpine.DEB.2.11.1803160940460.25218@grey.csi.cam.ac.uk>
References: <alpine.BSF.2.21.1803150808270.819@aneurin.horsfall.org>
 <20180314222309.GO16269@h-174-65.A328.priv.bahnhof.se>
 <alpine.DEB.2.11.1803151929460.690@grey.csi.cam.ac.uk>
 <alpine.BSF.2.21.1803160757140.819@aneurin.horsfall.org>
 <alpine.DEB.2.11.1803160940460.25218@grey.csi.cam.ac.uk>
Message-ID: <2D5455C3-77E6-46AD-9799-8804BA68157D@tfeb.org>

I think it is maybe NAVTEX or some ancestor of that.  Somewhere there are still warnings that the shipping forecast via the internet is not to be relied on: the one transmitted by NAVTEX or equivalent is (as well as, perhaps, the voice one on LW), and that version always gets out (well, if it doesn't it's because the Met Office is a radioactive hole in the ground).

--tim
> On 16 Mar 2018, at 09:51, Tony Finch <dot at dotat.at> wrote:
> 
> Dave Horsfall <dave at horsfall.org> wrote:
>> 
>> OK, I'll bite: how do you do this?
> 
> A script that massages the data from the Met Office Shipping Forecast and
> prints it into a named pipe which my MUA reads from.
> http://www.metoffice.gov.uk/public/data/CoreProductCache/ShippingForecast/Latest
> It's XML now, but when I started using this .sig the data looked like it
> was coming from a system designed for distributing the forecast via telex.
> (Radio telex to ships maybe?)
> 
> Tony.
> -- 
> f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/  -  I xn--zr8h punycode
> Rockall, Malin, Hebrides, Bailey: Southerly or southeasterly, 4 or 5 at first
> in south Rockall, otherwise 6 to gale 8. Moderate in east Malin and east
> Hebrides, otherwise rough or very rough, occasionally high at first in
> Hebrides and Bailey. Rain at times. Moderate or good.



From clemc at ccc.com  Sat Mar 17 05:09:06 2018
From: clemc at ccc.com (Clem Cole)
Date: Fri, 16 Mar 2018 15:09:06 -0400
Subject: [TUHS] Happy birthday, symbolics.com!
In-Reply-To: <alpine.BSF.2.21.1803160757140.819@aneurin.horsfall.org>
References: <alpine.BSF.2.21.1803150808270.819@aneurin.horsfall.org>
 <20180314222309.GO16269@h-174-65.A328.priv.bahnhof.se>
 <alpine.DEB.2.11.1803151929460.690@grey.csi.cam.ac.uk>
 <alpine.BSF.2.21.1803160757140.819@aneurin.horsfall.org>
Message-ID: <CAC20D2PR8HnQdgnc5_Z7Bqjbfb9cf-3Sk+owOVEAur2_t=7cGg@mail.gmail.com>

On Thu, Mar 15, 2018 at 5:04 PM, Dave Horsfall <dave at horsfall.org> wrote:

> On Thu, 15 Mar 2018, Tony Finch wrote:
>
> As I understand it, the old hosts.txt registrations got grandfathered into
>> the DNS in the .arpa zone - they were ARPANET hosts (e.g. see RFC 921). The
>> modern structure was set up after the transition to IP, so it's fair to
>> call .com and friends Internet domains. (See RFC 920.)
>>
>
> Yeah, I was referring to DNS as opposed to HOSTS.TXT of course.
>
> But it looks like there were a bunch of .edu and .gov names before
>> Symbolics.
>>
>
> I'm happy to be corrected/updated; I happen to have an interest in geeky
> history (as if that wasn't apparent).



​Well this history is sort of strange because it was more random/back
patched than the historian likes to admit.  For instance DEC definitely had
an ARPAnet connection and I think IBM did also. Note Tektronix and HP did
not have ARPAnet connections, but Tek was a very early UUCP site and HP
followed suite about 2 years later.

As others have pointed out the ARPANETname space was a tad more flat:
user at site and SITE was sort of large (MIT, CMU, DEC) - which originally
mapped to IMPs.    Different networks (like SAT-NET) started to strain the
naming scheme. As Ron reminded us, with the coming of the splitting off the
DoD to DDN's responsibility and the creation of MIL-Net people began to
talk about needing more that 'site.'

Hence the creation of responsibility 'domains' ​-- which (as I recall) was
less for SW naming and more for administrative control.

Their a a number of salient points here.  First there was no real
registration as we think of today.   For instance, I was personally
assigned ccc.com because I had been 'ccc' on the UUCP net, and I was
already moving packets around from UUCP and to Arpa/Internet folks via
gateways.

It was confusing time and a lot of different networks had bridges/email
gateways.  At that time, my friends at BBN just put me in the database long
before I was directly connected or assigned my own Class C network (which
happened a few years later).   This allowed ARPAnet, CS-Net etc to send
emails to me the gateway point was defined in the BBN database for MMDF
(not sendmail BTW) -- I've forgotten where all that name washing got done
-- it might have been BBN proper, but somehow I think UDEL was in the
middle of some of that [someone like Ron might remember].

Adding sites like me was done because BBN was trying to 'flatten' some of
the UUCP naming mess on their side (the message on the 'user' part of the
ARPA addresses was a wash with funny characters - like !, % etc to try to
slime in the different gateways].

A key thing to remember here, is that all happened before Symbolics was
incorporated.  And I was 'late' compared to others.   In fact 'Tektronix'
was running IP internally but used UUCP for external email as they could
not get an ARPAnet connection.  They later would joined CS-NET and used
Phone Net when that was first allowed and finally they were an early
'commercial' IP site that BBN connected with Cisco gear.

It should also be pointed out that since DEC was existed on the ARPAnet and
was grandfathered as DEC.Com (and I believe IBM the same) - this is all
long before Symbolics.Com was created.  So it's hard to really call
Symbolics 'first' other than to say the were probably the first firm to ask
BBN how do we do this and make it formal, right around the time when DoD
was trying to get out of the ARPAnet and was trying to find a way to
transition it to commercial firms.

For whatever it is worth, I also remember being ticked off when I got my
first bill years later from Network Solutions because at some point, the
BBN/SRI databases came under their control.   I had been CCC.COM for a long
number of years by then (5-10 maybe) and what was this all about.

Clem
ᐧ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180316/c1a05d70/attachment.html>

From dave at horsfall.org  Sat Mar 17 07:52:49 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Sat, 17 Mar 2018 08:52:49 +1100 (EST)
Subject: [TUHS] RIP John Backus
Message-ID: <alpine.BSF.2.21.1803170848420.819@aneurin.horsfall.org>

We lost computer pioneer John Backus on this day in 2007; amongst other 
things he gave us FORTRAN (yuck!) and BNF, which is ironic, really, 
because FORTRAN has no syntax to speak of.

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."


From dave at horsfall.org  Sat Mar 17 08:51:35 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Sat, 17 Mar 2018 09:51:35 +1100 (EST)
Subject: [TUHS] Happy birthday, symbolics.com!
In-Reply-To: <alpine.DEB.2.11.1803160940460.25218@grey.csi.cam.ac.uk>
References: <alpine.BSF.2.21.1803150808270.819@aneurin.horsfall.org>
 <20180314222309.GO16269@h-174-65.A328.priv.bahnhof.se>
 <alpine.DEB.2.11.1803151929460.690@grey.csi.cam.ac.uk>
 <alpine.BSF.2.21.1803160757140.819@aneurin.horsfall.org>
 <alpine.DEB.2.11.1803160940460.25218@grey.csi.cam.ac.uk>
Message-ID: <alpine.BSF.2.21.1803170948210.819@aneurin.horsfall.org>

On Fri, 16 Mar 2018, Tony Finch wrote:

[ Tony's weather .sig ]

> It's XML now, but when I started using this .sig the data looked like it 
> was coming from a system designed for distributing the forecast via 
> telex. (Radio telex to ships maybe?)

Yes; weather forecasts are rather important to a ship in the North Sea :-)

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."


From drsalists at gmail.com  Sat Mar 17 09:42:11 2018
From: drsalists at gmail.com (Dan Stromberg)
Date: Fri, 16 Mar 2018 16:42:11 -0700
Subject: [TUHS] RIP John Backus
In-Reply-To: <alpine.BSF.2.21.1803170848420.819@aneurin.horsfall.org>
References: <alpine.BSF.2.21.1803170848420.819@aneurin.horsfall.org>
Message-ID: <CAGGBd_rYndvxWms84QofZ4=Kb=sTi-HcNm78jLW3e7v-4C90VQ@mail.gmail.com>

On Fri, Mar 16, 2018 at 2:52 PM, Dave Horsfall <dave at horsfall.org> wrote:
> We lost computer pioneer John Backus on this day in 2007; amongst other
> things he gave us FORTRAN (yuck!) and BNF, which is ironic, really, because
> FORTRAN has no syntax to speak of.

FORTRAN isn't that bad.  F77 had too much and too little whitespace
significance, but from what I've heard, F90 is pretty decent.


From dave at horsfall.org  Sat Mar 17 10:08:04 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Sat, 17 Mar 2018 11:08:04 +1100 (EST)
Subject: [TUHS] RIP John Backus
In-Reply-To: <CAGGBd_rYndvxWms84QofZ4=Kb=sTi-HcNm78jLW3e7v-4C90VQ@mail.gmail.com>
References: <alpine.BSF.2.21.1803170848420.819@aneurin.horsfall.org>
 <CAGGBd_rYndvxWms84QofZ4=Kb=sTi-HcNm78jLW3e7v-4C90VQ@mail.gmail.com>
Message-ID: <alpine.BSF.2.21.1803171058060.819@aneurin.horsfall.org>

On Fri, 16 Mar 2018, Dan Stromberg wrote:

> FORTRAN isn't that bad.  F77 had too much and too little whitespace 
> significance, but from what I've heard, F90 is pretty decent.

Dunno; I taught myself FORTRAN-II after winning a book at school (yes, 
really!), and somehow ploughed through WATFOR (urk!) and WATFIV (a bit 
better) in my early CompSci classes, then was allowed to use FORTRAN-G in 
later on.

And if we promised to behave ourselves i.e. debug the program on FORTRAN-G 
first then we were allowed to use FORTRAN-H (which needed a special code 
on the JOB card, as I recall).

Never used the abomination since...

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."


From krewat at kilonet.net  Sat Mar 17 10:26:18 2018
From: krewat at kilonet.net (Arthur Krewat)
Date: Fri, 16 Mar 2018 20:26:18 -0400
Subject: [TUHS] RIP John Backus
In-Reply-To: <alpine.BSF.2.21.1803171058060.819@aneurin.horsfall.org>
References: <alpine.BSF.2.21.1803170848420.819@aneurin.horsfall.org>
 <CAGGBd_rYndvxWms84QofZ4=Kb=sTi-HcNm78jLW3e7v-4C90VQ@mail.gmail.com>
 <alpine.BSF.2.21.1803171058060.819@aneurin.horsfall.org>
Message-ID: <ccc3c554-e61e-cbbb-c374-74cae0663288@kilonet.net>

On 3/16/2018 8:08 PM, Dave Horsfall wrote:
> Dunno; I taught myself FORTRAN-II after winning a book at school (yes, 
> really!)

I taught myself Fortran after stealing a book from the library a few 
towns over. Returned it a few years later by dropping it in the book 
deposit.


From dave at horsfall.org  Sat Mar 17 10:36:32 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Sat, 17 Mar 2018 11:36:32 +1100 (EST)
Subject: [TUHS] RIP John Backus
In-Reply-To: <ccc3c554-e61e-cbbb-c374-74cae0663288@kilonet.net>
References: <alpine.BSF.2.21.1803170848420.819@aneurin.horsfall.org>
 <CAGGBd_rYndvxWms84QofZ4=Kb=sTi-HcNm78jLW3e7v-4C90VQ@mail.gmail.com>
 <alpine.BSF.2.21.1803171058060.819@aneurin.horsfall.org>
 <ccc3c554-e61e-cbbb-c374-74cae0663288@kilonet.net>
Message-ID: <alpine.BSF.2.21.1803171131170.819@aneurin.horsfall.org>

On Fri, 16 Mar 2018, Arthur Krewat wrote:

> I taught myself Fortran after stealing a book from the library a few 
> towns over. Returned it a few years later by dropping it in the book 
> deposit.

I forgot to mention that the other book I won (apparently I topped my 
school in Science or something, and could pick two books from a list) was 
"Business Data Processing", so I taught myself simple COBOL :-)

I lost both books in a house move, alas...

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."


From sauer at technologists.com  Sat Mar 17 11:40:04 2018
From: sauer at technologists.com (Charles H Sauer)
Date: Fri, 16 Mar 2018 20:40:04 -0500
Subject: [TUHS] RIP John Backus
In-Reply-To: <ccc3c554-e61e-cbbb-c374-74cae0663288@kilonet.net>
References: <alpine.BSF.2.21.1803170848420.819@aneurin.horsfall.org>
 <CAGGBd_rYndvxWms84QofZ4=Kb=sTi-HcNm78jLW3e7v-4C90VQ@mail.gmail.com>
 <alpine.BSF.2.21.1803171058060.819@aneurin.horsfall.org>
 <ccc3c554-e61e-cbbb-c374-74cae0663288@kilonet.net>
Message-ID: <140ead43-b6de-cb1e-1c86-181edb10ee30@technologists.com>

On 3/16/2018 7:26 PM, Arthur Krewat wrote:
> On 3/16/2018 8:08 PM, Dave Horsfall wrote:
>> Dunno; I taught myself FORTRAN-II after winning a book at school 
>> (yes, really!)
>
> I taught myself Fortran after stealing a book from the library a few 
> towns over. Returned it a few years later by dropping it in the book 
> deposit.

Another book of note, /FORTRAN für Anfänger/ 
(https://link.springer.com/book/10.1007/978-3-642-96076-5), was popular 
among UT-Austin doctoral candidates in meeting the foreign language 
requirements...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180316/ddc71ce9/attachment.html>

From cym224 at gmail.com  Sat Mar 17 11:57:19 2018
From: cym224 at gmail.com (Nemo)
Date: Fri, 16 Mar 2018 21:57:19 -0400
Subject: [TUHS] RIP John Backus
In-Reply-To: <alpine.BSF.2.21.1803170848420.819@aneurin.horsfall.org>
References: <alpine.BSF.2.21.1803170848420.819@aneurin.horsfall.org>
Message-ID: <CAJfiPzz-o8yw+FmwF-LvvkTSpzUvzobxAyqOw8CHjbCkjtKsLw@mail.gmail.com>

On 16/03/2018, Dave Horsfall <dave at horsfall.org> wrote:
> We lost computer pioneer John Backus on this day in 2007; amongst other
> things he gave us FORTRAN (yuck!) and BNF, which is ironic, really,
> because FORTRAN has no syntax to speak of.

Early on, I landed a job requiring VAX FORTRAN but I was not actually
conversant in it -- I told a white lie.  I saw "FORTRAN Tools for
VAX/VMS" at a local technical store and read it cover to cover.  (The
title was an intentional play on Kernighan & Plauger and built similar
tools using FORTRAN -- side topic but whatever happened to Plauger?)
Said implementation pleasantly surprised me:  nothing at all like the
primitive early versions.

N.

>
> --
> Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will
> suffer."
>


From bakul at bitblocks.com  Sat Mar 17 17:20:36 2018
From: bakul at bitblocks.com (Bakul Shah)
Date: Sat, 17 Mar 2018 00:20:36 -0700
Subject: [TUHS] RIP John Backus
In-Reply-To: <alpine.BSF.2.21.1803170848420.819@aneurin.horsfall.org>
References: <alpine.BSF.2.21.1803170848420.819@aneurin.horsfall.org>
Message-ID: <E7F8EC6F-AD3A-48E8-B663-2724071367F3@bitblocks.com>

On Mar 16, 2018, at 2:52 PM, Dave Horsfall <dave at horsfall.org> wrote:
> 
> We lost computer pioneer John Backus on this day in 2007; amongst other things he gave us FORTRAN (yuck!) and BNF, which is ironic, really, because FORTRAN has no syntax to speak of.

He atoned for designing FORTRAN, so to speak, by coming up
with FP, one of the first functional programming languages
(though he called it FP system). See his 1977 Turing Award
lecture: 
  https://doi.org/10.1145%2F359576.359579

IIRC, someone had posted an interpreter for FP to
comp.sources.unix. Ah, here it is: Volume 20, Issue 50.
  https://groups.google.com/forum/#!msg/comp.sources.unix/O68WmHasQZ8/2v3_YuEbH6IJ

FP's clear inspiration was APL. It didn't succeed but it was
quite influential for the field of functional programming
languages. Though modern FPLs are lambda calculus based (Backus
thought lambda calculus was too powerful and may lead to chaos).

Backus was also involved in the design of Algol58 and Algol60,
which is where he came up with BNF. There is an ancient grammar
notation that is as least as powerful as BNF but it seems Backus
was unaware of it. [Pāṇinian rules can describe languages larger
than CFL but not as large as context sensitive languages]

From clemc at ccc.com  Sat Mar 17 23:43:48 2018
From: clemc at ccc.com (Clem Cole)
Date: Sat, 17 Mar 2018 09:43:48 -0400
Subject: [TUHS] RIP John Backus
In-Reply-To: <alpine.BSF.2.21.1803170848420.819@aneurin.horsfall.org>
References: <alpine.BSF.2.21.1803170848420.819@aneurin.horsfall.org>
Message-ID: <CAC20D2N9rxA_ZEQ7ufmvCDruznWFdh-OGy7yhxo+D7Psh9Na5A@mail.gmail.com>

On Fri, Mar 16, 2018 at 5:52 PM, Dave Horsfall <dave at horsfall.org> wrote:

> We lost computer pioneer John Backus on this day in 2007; amongst other
> things he gave us FORTRAN (yuck!) and BNF, which is ironic, really, because
> FORTRAN has no syntax to speak of
> ​.
>

​Dave -- please be careful about the disparaging comments.

As a system's person, I don't need to write in it, (although I can
understand it when I need too) and neither do I believe many of our
colleagues in the system business; since it is not the right thing for my
or their needs.  But Fortran has a place and it still pays my and many of
our salaries (and I happen to know it paid the salary if a number of folks
on this list and I think, like me still does).


​I'll save people on the list from the full argument and try to keep a
flame war from starting but I offer that you instead read:  Clem Cole's
answer to Is Fortran Still Alive
<https://www.quora.com/Is-Fortran-still-alive/answer/Clem-Cole>  and
Clem Cole's answer to Why is the Fortran language still in use and (most
importantly) relevant in HPC? Is it just because this language has
tremendous numerical calculation capability which is an important part of
HPC?
<https://www.quora.com/Why-is-the-Fortran-language-still-in-use-and-most-importantly-relevant-in-HPC-Is-it-just-because-this-language-has-tremendous-numerical-calculation-capability-which-is-an-important-part-of-HPC/answer/Clem-Cole>


Simply out (and for those) that don't want to reads the more details
arguments - please don't try to compare Fortran to C, Pascal, Java, Rust *etc.
*or many other languages - please do not knock it because you don't need to
use it or look down on those that do use because it helps them.  But,
instead remember that is in your toolbox, has been and is *an appropriate
solution for many problems*, and is likely to continue to be for many years.

Are their 'better' tools, like the QUERTY keyboard? Sure but they not
economically interesting.  I ask you to please be kind before you make
disparaging comments.   As I point out in those answer, even if I could
wave wand and have all those oce that we have today magically rewritten
into a modern language from C to Rust or something else that strikes your
fancy, there is no way it would be economical (much less wise) to try to
revalidate the years and years of data that Fortran based codes have
created.

As I close, I try to remember that many Frenchman have been
historical annoyed  because French, which is said to be a 'pure and
beautiful' did not become the universal world language, and the wretched
and crass anglo saxon English did.  Yet many 'British' be moan that
'American' is not English either.   And many 'merkins' can hardly
understand people in many parts of the world .  It does not make either
anyone language better than the other.  Both are useful - communications is
passing information between to parties and they all usually get the job
done, some more easily than others.

Today's Fortran is not, the language Backus and team at IBM created in the
late 1950s.   Like English (or 'American English' maybe), it has morphed a
bit and taken ideas from other languages.

'nuf said I hope.

Clem


ᐧ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180317/7cdb735e/attachment.html>

From paul at mcjones.org  Sun Mar 18 00:47:41 2018
From: paul at mcjones.org (Paul McJones)
Date: Sat, 17 Mar 2018 07:47:41 -0700
Subject: [TUHS] RIP John Backus
In-Reply-To: <mailman.17.1521243734.3788.tuhs@minnie.tuhs.org>
References: <mailman.17.1521243734.3788.tuhs@minnie.tuhs.org>
Message-ID: <7A56D946-3D0D-4ED3-81CD-68EB9FD97CF0@mcjones.org>

Dave Horsfall <dave at horsfall.org> wrote:

> We lost computer pioneer John Backus on this day in 2007; amongst other 
> things he gave us FORTRAN (yuck!) and BNF, which is ironic, really, 
> because FORTRAN has no syntax to speak of.

I think of FORTRAN as having established the very idea of high-level programming languages. For example, John McCarthy’s first idea for what became LISP was to extend FORTRAN with function subroutines written in assembly language for list-manipulation. (He had to give up on this idea when he realized a conditional expression operator wouldn’t work correctly since both the then-expression and the else-expression would be evaluated before the condition was tested.) The original FORTRAN compiler pioneered code optimization, generating code good enough for the users at the physics labs and aerospace companies. For more on this compiler, see:

http://www.softwarepreservation.org/projects/FORTRAN/

Disclosure: I worked with John in the 1970s (on functional programming) — see:

http://www.mcjones.org/dustydecks/archives/2007/04/01/60/ .


Paul McJones

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180317/66768234/attachment.html>

From dave at horsfall.org  Sun Mar 18 01:54:46 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Sun, 18 Mar 2018 02:54:46 +1100 (EST)
Subject: [TUHS] RIP John Backus
In-Reply-To: <7A56D946-3D0D-4ED3-81CD-68EB9FD97CF0@mcjones.org>
References: <mailman.17.1521243734.3788.tuhs@minnie.tuhs.org>
 <7A56D946-3D0D-4ED3-81CD-68EB9FD97CF0@mcjones.org>
Message-ID: <alpine.BSF.2.21.1803180211130.819@aneurin.horsfall.org>

On Sat, 17 Mar 2018, Paul McJones wrote:

>       [...] because FORTRAN has no syntax to speak of.
> 
> I think of FORTRAN as having established the very idea of high-level 
> programming languages. [...]

Thanks; that's the sort of discussion that I was hoping to promote 
("stirring" is a long-established tradition here in Oz).  And I happen to 
agree, oddly enough...  Was it the 704, or the 709?  I recall that the 
array indexing order mapped directly into its index register or something 
(like C's "do { ... } while (--i)" maps straight into "SOB" (although I 
don't know whether the former was influenced by the latter).

I have an article somewhere in AUUGN (I don't know which) describing our 
visit to a DECUS conference.  One of the presentations was a slide that 
compared high- and low-level languages.  I don't remember what definition 
they used, and I can't recall whether BLISS was high or low (I think it 
was "low with a pointer towards the right"), but they showed FORTRAN on 
the right, and me being me I piped up with "FORTRAN a high-level 
language?"

I don't recall the exact wording in my subsequent AUUGN report, but it 
went something like "Half the room broke up into fits of the giggles, and 
the other half were stonily wondering what was so funny."

I never did get that job with DEC some years afterwards, mostly because
got borged by Compact (?) with an ensuing management broom (and I've long 
since lost track of who bought out whom since).

> Disclosure: I worked with John in the 1970s (on functional programming) 
> — see:
> 
> http://www.mcjones.org/dustydecks/archives/2007/04/01/60/ .

Neat story!

The bookshelf: I had most of those books once; what's the one on the 
bottom right?  It has a "paperback" look about it, but I can't quite make 
it out because of the reflection on the spine.

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

From paul at mcjones.org  Sun Mar 18 03:49:31 2018
From: paul at mcjones.org (Paul McJones)
Date: Sat, 17 Mar 2018 10:49:31 -0700
Subject: [TUHS] RIP John Backus
In-Reply-To: <mailman.19.1521302091.3788.tuhs@minnie.tuhs.org>
References: <mailman.19.1521302091.3788.tuhs@minnie.tuhs.org>
Message-ID: <ecea8e70-4256-2476-1e3e-aa942a8627f9@mcjones.org>

On 3/17/2018 8:54 AM, Dave Horsfall <dave at horsfall.org> wrote:

> ...  Was it the 704, or the 709?  I recall that the
> array indexing order mapped directly into its index register or something
> ...

It first ran on the IBM 704, whose index registers subtracted (as did 
the follow-on 709, 7090, etc), so array indexing went from higher memory 
addresses to lower.

> The bookshelf: I had most of those books once; what's the one on the
> bottom right?  It has a "paperback" look about it, but I can't quite make
> it out because of the reflection on the spine.

I'm not sure, and things have shifted since then on the shelves, but I 
sent the original photo to your email address.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180317/dbd356e5/attachment.html>

From steve at quintile.net  Sun Mar 18 03:06:51 2018
From: steve at quintile.net (Steve Simon)
Date: Sat, 17 Mar 2018 17:06:51 +0000
Subject: [TUHS] RIP John Backus
In-Reply-To: <CAC20D2N9rxA_ZEQ7ufmvCDruznWFdh-OGy7yhxo+D7Psh9Na5A@mail.gmail.com>
References: <alpine.BSF.2.21.1803170848420.819@aneurin.horsfall.org>
 <CAC20D2N9rxA_ZEQ7ufmvCDruznWFdh-OGy7yhxo+D7Psh9Na5A@mail.gmail.com>
Message-ID: <E0E2D8CE-6497-4E33-A603-37B9B56F05E6@quintile.net>


personally, when i have add significant modules to fortran projects i have written new code in rat4 which i find an excellent solution - others may disagree.

on the subject of fortran’s language, i remember hearing tell of a French version. anyone ever meet any? 

-Steve


> On 17 Mar 2018, at 13:43, Clem Cole <clemc at ccc.com> wrote:
> 
> 
> 
>> On Fri, Mar 16, 2018 at 5:52 PM, Dave Horsfall <dave at horsfall.org> wrote:
>> We lost computer pioneer John Backus on this day in 2007; amongst other things he gave us FORTRAN (yuck!) and BNF, which is ironic, really, because FORTRAN has no syntax to speak of​.
>  
> ​Dave -- please be careful about the disparaging comments.
> 
> As a system's person, I don't need to write in it, (although I can understand it when I need too) and neither do I believe many of our colleagues in the system business; since it is not the right thing for my or their needs.  But Fortran has a place and it still pays my and many of our salaries (and I happen to know it paid the salary if a number of folks on this list and I think, like me still does). 
> 
> ​I'll save people on the list from the full argument and try to keep a flame war from starting but I offer that you instead read:  Clem Cole's answer to Is Fortran Still Alive  and
> Clem Cole's answer to Why is the Fortran language still in use and (most importantly) relevant in HPC? Is it just because this language has tremendous numerical calculation capability which is an important part of HPC? 
> 
> Simply out (and for those) that don't want to reads the more details arguments - please don't try to compare Fortran to C, Pascal, Java, Rust etc. or many other languages - please do not knock it because you don't need to use it or look down on those that do use because it helps them.  But, instead remember that is in your toolbox, has been and is an appropriate solution for many problems, and is likely to continue to be for many years.
> 
> Are their 'better' tools, like the QUERTY keyboard? Sure but they not economically interesting.  I ask you to please be kind before you make disparaging comments.   As I point out in those answer, even if I could wave wand and have all those oce that we have today magically rewritten into a modern language from C to Rust or something else that strikes your fancy, there is no way it would be economical (much less wise) to try to revalidate the years and years of data that Fortran based codes have created.
> 
> As I close, I try to remember that many Frenchman have been historical annoyed  because French, which is said to be a 'pure and beautiful' did not become the universal world language, and the wretched and crass anglo saxon English did.  Yet many 'British' be moan that 'American' is not English either.   And many 'merkins' can hardly understand people in many parts of the world .  It does not make either anyone language better than the other.  Both are useful - communications is passing information between to parties and they all usually get the job done, some more easily than others.
> 
> Today's Fortran is not, the language Backus and team at IBM created in the late 1950s.   Like English (or 'American English' maybe), it has morphed a bit and taken ideas from other languages.
> 
> 'nuf said I hope.
> 
> Clem
> 
> 
> ᐧ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180317/8b7dff12/attachment.html>

From krewat at kilonet.net  Sun Mar 18 04:52:29 2018
From: krewat at kilonet.net (Arthur Krewat)
Date: Sat, 17 Mar 2018 14:52:29 -0400
Subject: [TUHS] RIP John Backus
In-Reply-To: <ecea8e70-4256-2476-1e3e-aa942a8627f9@mcjones.org>
References: <mailman.19.1521302091.3788.tuhs@minnie.tuhs.org>
 <ecea8e70-4256-2476-1e3e-aa942a8627f9@mcjones.org>
Message-ID: <1881ddbc-690a-2901-a68e-91334322065d@kilonet.net>

On 3/17/2018 1:49 PM, Paul McJones wrote:
> It first ran on the IBM 704, whose index registers subtracted (as did 
> the follow-on 709, 7090, etc), so array indexing went from higher 
> memory addresses to lower.

Leave it to IBM to do something backwards.

Of course, that was in 1954, so I can't complain, it was 11 years before 
I was born. But that's ... odd.

Was subtraction easier than addition with digital electronics back then? 
I would think that they were both the same level of effort (clock 
cycles) so why do something obviously backwards logically?

ak


From pdagog at gmail.com  Sun Mar 18 05:15:01 2018
From: pdagog at gmail.com (Pierre DAVID)
Date: Sat, 17 Mar 2018 20:15:01 +0100
Subject: [TUHS] RIP John Backus
In-Reply-To: <E0E2D8CE-6497-4E33-A603-37B9B56F05E6@quintile.net>
References: <alpine.BSF.2.21.1803170848420.819@aneurin.horsfall.org>
 <CAC20D2N9rxA_ZEQ7ufmvCDruznWFdh-OGy7yhxo+D7Psh9Na5A@mail.gmail.com>
 <E0E2D8CE-6497-4E33-A603-37B9B56F05E6@quintile.net>
Message-ID: <20180317191501.GA4137@vagabond>

On Sat, Mar 17, 2018 at 05:06:51PM +0000, Steve Simon wrote:
>
>on the subject of fortran’s language, i remember hearing tell of a French version. anyone ever meet any?
>

Never heard of a French version of Fortran, but you may have been confused
with LSE (Langage Symbolique d'Enseignement, aka Symbolic Language for
Education), which was a BASIC variant with French keywords.

Kind of weird, never used it, but it was popular in the 1970s in France.

English Wikipeda page:
    https://en.wikipedia.org/wiki/LSE_(programming_language)

More complete French Wikipedia page:
    https://fr.wikipedia.org/wiki/LSE_(langage)

Pierre


From tfb at tfeb.org  Sun Mar 18 05:22:23 2018
From: tfb at tfeb.org (Tim Bradshaw)
Date: Sat, 17 Mar 2018 19:22:23 +0000
Subject: [TUHS] RIP John Backus
In-Reply-To: <CAC20D2N9rxA_ZEQ7ufmvCDruznWFdh-OGy7yhxo+D7Psh9Na5A@mail.gmail.com>
References: <alpine.BSF.2.21.1803170848420.819@aneurin.horsfall.org>
 <CAC20D2N9rxA_ZEQ7ufmvCDruznWFdh-OGy7yhxo+D7Psh9Na5A@mail.gmail.com>
Message-ID: <46927130-75DF-4B8A-8B46-C6CF23539B2C@tfeb.org>

On 17 Mar 2018, at 13:43, Clem Cole <clemc at ccc.com> wrote:
> 
> Simply out (and for those) that don't want to reads the more details arguments - please don't try to compare Fortran to C, Pascal, Java, Rust etc. or many other languages - please do not knock it because you don't need to use it or look down on those that do use because it helps them.  But, instead remember that is in your toolbox, has been and is an appropriate solution for many problems, and is likely to continue to be for many years.
> 
> [...]
> 
> Today's Fortran is not, the language Backus and team at IBM created in the late 1950s.   Like English (or 'American English' maybe), it has morphed a bit and taken ideas from other languages.

Also without wanting to start a war about this, I want to agree strongly with it.  I work somewhere where our main computational tool is a large Fortran program which does things critical to the security (both economic and defence) of the country I live in.  It's officially in Fortran 90 but I think older chunks of it are probably still in FORTRAN 77 and yet other chunks written to more recent standards.

It's a horrible thing, but it's a horrible thing because it has been written by scientists rather than people who have software backgrounds, and written & maintained over something like 30 years or more.  In particular it's not horrible because it's in Fortran: Fortran 90 is a reasonably pleasant language as far as I can see (I learnt FORTRAN 77 and since I don't work directly on this program I'm not really familiar enough with the later standards to make a strong statement), and later standards seem even more pleasant.

We're in the early stages of replacing this program by something which will scale bette (to, eventually, millions rather than thousands of cores).  That program is going to be written in Fortran (with fairly extensive preprocessing to isolate science code from details of the implementation), and that's *the right decision*.

--tim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180317/949939f8/attachment.html>

From mike.ab3ap at gmail.com  Sun Mar 18 05:28:25 2018
From: mike.ab3ap at gmail.com (Mike Markowski)
Date: Sat, 17 Mar 2018 15:28:25 -0400
Subject: [TUHS] RIP John Backus
In-Reply-To: <CAC20D2N9rxA_ZEQ7ufmvCDruznWFdh-OGy7yhxo+D7Psh9Na5A@mail.gmail.com>
References: <alpine.BSF.2.21.1803170848420.819@aneurin.horsfall.org>
 <CAC20D2N9rxA_ZEQ7ufmvCDruznWFdh-OGy7yhxo+D7Psh9Na5A@mail.gmail.com>
Message-ID: <a2667902-c912-531e-79cb-bc5ef6f20da6@gmail.com>

On 03/17/2018 09:43 AM, Clem Cole wrote:>
> [...]  But Fortran has a place and it still pays my and
> many of our salaries (and I happen to know it paid the salary if a 
> number of folks on this list and I think, like me still does).
> [...]
As something sorta, kinda like a proof by contradiction, I work in an RF 
lab.  A fair amount of effort is put into writing code to control lab 
gear to automate data collection, reach confidence level, etc.

For one project the customer required that it be written in Java.  Most 
RF lab gear and radios use I/Q (in-phase/quadrature) signals and the 
associated math is complex.  Try doing complex DSP in Java and you will 
soon sing the praises of Fortran where it's a snap.  :-)

Mike Markowski


From charles.unix.pro at gmail.com  Sun Mar 18 05:41:15 2018
From: charles.unix.pro at gmail.com (Charles Anthony)
Date: Sat, 17 Mar 2018 12:41:15 -0700
Subject: [TUHS] RIP John Backus
In-Reply-To: <20180317191501.GA4137@vagabond>
References: <alpine.BSF.2.21.1803170848420.819@aneurin.horsfall.org>
 <CAC20D2N9rxA_ZEQ7ufmvCDruznWFdh-OGy7yhxo+D7Psh9Na5A@mail.gmail.com>
 <E0E2D8CE-6497-4E33-A603-37B9B56F05E6@quintile.net>
 <20180317191501.GA4137@vagabond>
Message-ID: <CANV78LSG999t-7d2hKk1EKq08+8ECnSTFn9VXUwSGfhBJ6-HiA@mail.gmail.com>

On Sat, Mar 17, 2018 at 12:15 PM, Pierre DAVID <pdagog at gmail.com> wrote:

> On Sat, Mar 17, 2018 at 05:06:51PM +0000, Steve Simon wrote:
>
>>
>> on the subject of fortran’s language, i remember hearing tell of a French
>> version. anyone ever meet any?
>>
>>
> Never heard of a French version of Fortran, but you may have been confused
> with LSE (Langage Symbolique d'Enseignement, aka Symbolic Language for
> Education), which was a BASIC variant with French keywords.
>
>
The Multics Pascal compiler has a "-french" option which maps all of the
keywords to French.

Some examples from "pascal_french_keywords.gi.info":

English             French
-------             ------
$export             $exporte
array               tableau
file                fichier
otherwise           autrement
unpack              detasser


-- Charles
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180317/746702c0/attachment.html>

From paul at mcjones.org  Sun Mar 18 06:01:30 2018
From: paul at mcjones.org (Paul McJones)
Date: Sat, 17 Mar 2018 13:01:30 -0700
Subject: [TUHS] RIP John Backus
In-Reply-To: <mailman.21.1521314548.3788.tuhs@minnie.tuhs.org>
References: <mailman.21.1521314548.3788.tuhs@minnie.tuhs.org>
Message-ID: <1d3a154d-c80d-2bb5-dce1-e027b4cfaa59@mcjones.org>

On 3/17/2018 12:22 PM, Steve Simon <steve at quintile.net> wrote:

> on the subject of fortran’s language, i remember hearing tell of a French version. anyone ever meet any?

Yes: here is the French version of the original Fortran manual, with 
keywords in French (via 
http://www.softwarepreservation.org/projects/FORTRAN/):

Anonymous. FORTRAN Programmation Automatique de L'Ordinateur IBM 704 : 
Manuel du Programmeur. IBM France, Institut de Calcul Scientifique, 
Paris. No date, 51 pages. Given to Paul McJones by John Backus.
http://archive.computerhistory.org/resources/text/Fortran/102663111.05.01.acc.pdf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180317/896481de/attachment.html>

From paul at mcjones.org  Sun Mar 18 06:14:37 2018
From: paul at mcjones.org (Paul McJones)
Date: Sat, 17 Mar 2018 13:14:37 -0700
Subject: [TUHS] RIP John Backus
In-Reply-To: <mailman.21.1521314548.3788.tuhs@minnie.tuhs.org>
References: <mailman.21.1521314548.3788.tuhs@minnie.tuhs.org>
Message-ID: <4943fffb-dee6-fb51-1ca2-8d4b17fa7a2f@mcjones.org>

On 3/17/2018 12:22 PM, Arthur Krewat <krewat at kilonet.net> wrote:
> Leave it to IBM to do something backwards.
>
> Of course, that was in 1954, so I can't complain, it was 11 years before
> I was born. But that's ... odd.
>
> Was subtraction easier than addition with digital electronics back then?
> I would think that they were both the same level of effort (clock
> cycles) so why do something obviously backwards logically?

Subtraction was done by taking the two's complement and adding. I 
suspect the CPU architect (Gene Amdahl -- not exactly a dullard) 
intended programmers store array elements at increasing memory 
addresses, and reference an array element relative to the address of the 
last element plus one. This would allow a single index register (and 
there were only three) to be used as the index and the (decreasing) 
count. See the example on page 97 of:

James A. Saxon
Programming the IBM 7090: A Self-Instructional Programmed Manual
Prentice-Hall, 1963
http://www.bitsavers.org/pdf/ibm/7090/books/Saxon_Programming_the_IBM_7090_1963.pdf

The Fortran compiler writers decided to reverse the layout of array 
elements so a Fortran subscript could be used directly in an index register.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180317/4da38e01/attachment.html>

From grog at lemis.com  Sun Mar 18 13:39:02 2018
From: grog at lemis.com (Greg 'groggy' Lehey)
Date: Sun, 18 Mar 2018 14:39:02 +1100
Subject: [TUHS] RIP John Backus
In-Reply-To: <1881ddbc-690a-2901-a68e-91334322065d@kilonet.net>
References: <mailman.19.1521302091.3788.tuhs@minnie.tuhs.org>
 <ecea8e70-4256-2476-1e3e-aa942a8627f9@mcjones.org>
 <1881ddbc-690a-2901-a68e-91334322065d@kilonet.net>
Message-ID: <20180318033902.GI60320@eureka.lemis.com>

On Saturday, 17 March 2018 at 14:52:29 -0400, Arthur Krewat wrote:
> On 3/17/2018 1:49 PM, Paul McJones wrote:
>> It first ran on the IBM 704, whose index registers subtracted (as did
>> the follow-on 709, 7090, etc), so array indexing went from higher
>> memory addresses to lower.
>
> Leave it to IBM to do something backwards.
>
> Of course, that was in 1954, so I can't complain, it was 11 years before
> I was born. But that's ... odd.
>
> Was subtraction easier than addition with digital electronics back
> then?

Yes.  The basic arithmetic operation on ones-complement machines
(which meant just about every big computer of the day) was
subtraction.

> I would think that they were both the same level of effort (clock
> cycles) so why do something obviously backwards logically?

If I recall this correctly, the big issue was -0.  It was easier to
avoid this value with a subtractive adder than with an additive adder.
Possibly the adder itself was also marginally simpler as a result.

The other interesting thing about the 704 and 709 was that there was a
3 bit field for the decrement registers (as the index were called),
and each bit selected one register, so you could use any or all of the
registers in an operation.  I'd like to claim that this was the reason
for 3 array subscripts in early FORTRAN, but last time I made a claim
like that I was soundly trounced.

Later 70* machines expanded to 7 decrement registers, and this feature
was lost.

Greg
--
Sent from my desktop computer.
Finger grog at lemis.com for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 163 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180318/8373455f/attachment.sig>

From otto at drijf.net  Sun Mar 18 17:35:56 2018
From: otto at drijf.net (Otto Moerbeek)
Date: Sun, 18 Mar 2018 08:35:56 +0100
Subject: [TUHS] RIP John Backus
In-Reply-To: <1881ddbc-690a-2901-a68e-91334322065d@kilonet.net>
References: <mailman.19.1521302091.3788.tuhs@minnie.tuhs.org>
 <ecea8e70-4256-2476-1e3e-aa942a8627f9@mcjones.org>
 <1881ddbc-690a-2901-a68e-91334322065d@kilonet.net>
Message-ID: <20180318073556.GC53333@clue.drijf.net>

On Sat, Mar 17, 2018 at 02:52:29PM -0400, Arthur Krewat wrote:

> On 3/17/2018 1:49 PM, Paul McJones wrote:
> > It first ran on the IBM 704, whose index registers subtracted (as did
> > the follow-on 709, 7090, etc), so array indexing went from higher memory
> > addresses to lower.
> 
> Leave it to IBM to do something backwards.
> 
> Of course, that was in 1954, so I can't complain, it was 11 years before I
> was born. But that's ... odd.
> 
> Was subtraction easier than addition with digital electronics back then? I
> would think that they were both the same level of effort (clock cycles) so
> why do something obviously backwards logically?
> 
> ak

Speculation:

If you only have a conditional jump on zero, a loop that ends at an
index becoming zero is more easy, it saves an extra subtraction to
test for the end condition. You load the size of the array into the
index register, and then loop until it becomes zero. If you then use
the end the array as the base, you still have a forward loops since the
effective address will be computed as end - index with index begin
decremented in the loop.

	-Otto


From scj at yaccman.com  Sun Mar 18 08:27:41 2018
From: scj at yaccman.com (Steve Johnson)
Date: Sat, 17 Mar 2018 15:27:41 -0700
Subject: [TUHS] RIP John Backus
In-Reply-To: <4943fffb-dee6-fb51-1ca2-8d4b17fa7a2f@mcjones.org>
Message-ID: <284abf07f5b9d442caf233a8017a8cebb5518bbc@webmail.yaccman.com>


Let me offer a somewhat different perspective on FORTRAN.  When an
airplane is designed, the design undergoes a number of engineering
tests under simulation at the design stage.  Many countries require
that these simulation runs be archived for the lifetime of the
airplane so that, in the event of a crash, they can be run again with
the conditions experienced by the aircraft to see whether the problem
was in the design.  Airplanes commonly take 10 years from first
design to first shipment.  And then are sold for 10 years or so. 
And the planes can fly for up to 30 years after that.   So these
tests need to be written in a computer language that can be run 50
years in the future -- that is a stipulation of the archive
requirement.  There really aren't any alternative languages that I'm
aware of that could meet this criterion -- that's particularly true
today, when there is a sea change from serial to parallel programming
and it's hard to pick a winner with five decades of life ahead of
it...

Does anyone have any candidates?

Steve


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180317/632600a7/attachment.html>

From steve at quintile.net  Sun Mar 18 21:02:34 2018
From: steve at quintile.net (Steve Simon)
Date: Sun, 18 Mar 2018 11:02:34 +0000
Subject: [TUHS] RIP John Backus
In-Reply-To: <20180317191501.GA4137@vagabond>
References: <alpine.BSF.2.21.1803170848420.819@aneurin.horsfall.org>
 <CAC20D2N9rxA_ZEQ7ufmvCDruznWFdh-OGy7yhxo+D7Psh9Na5A@mail.gmail.com>
 <E0E2D8CE-6497-4E33-A603-37B9B56F05E6@quintile.net>
 <20180317191501.GA4137@vagabond>
Message-ID: <A68B302A-A026-4195-95AB-309E5473935B@quintile.net>


again, a personal view,

i think fortran 66 was not a great language but by the time 77 came around it was good enough (especially with rat4 in front)

the problem fortran had was its position in time, in the early days of computer programming the authors of some large systems tended to be experts in their fields, but not always good programmers.

in previous jobs i supported both Pafec FE and Flow3d. both of these started out as well structured systems but where amended by many hackers.

fortran gets the blame for this because fortran was what people used then, but its not the languages fault.

-Steve




From jnc at mercury.lcs.mit.edu  Sun Mar 18 23:33:39 2018
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Sun, 18 Mar 2018 09:33:39 -0400 (EDT)
Subject: [TUHS] RIP John Backus
Message-ID: <20180318133339.794D318C08E@mercury.lcs.mit.edu>

    > From: Paul McJones <paul at mcjones.org>

    > I suspect the CPU architect (Gene Amdahl -- not exactly a dullard)
    > intended programmers store array elements at increasing memory
    > addresses, and reference an array element relative to the address of the
    > last element plus one. This would allow a single index register (and
    > there were only three) to be used as the index and the (decreasing)
    > count.

I suspect the younger members of the list, who've only ever lived in a world
in which one lights ones cigars with mega-gates, so to speak, may be missing
the implication here.

Back when the 704 (a _tube_ machine) was built, a register meant a whole row
of tubes. That's why early machines had few/one register(s).

So being able to double up on what a register did like this was _HYYUUGE_.

       Noel


From paul.winalski at gmail.com  Mon Mar 19 04:51:02 2018
From: paul.winalski at gmail.com (Paul Winalski)
Date: Sun, 18 Mar 2018 14:51:02 -0400
Subject: [TUHS] RIP John Backus
In-Reply-To: <alpine.BSF.2.21.1803170848420.819@aneurin.horsfall.org>
References: <alpine.BSF.2.21.1803170848420.819@aneurin.horsfall.org>
Message-ID: <CABH=_VSEyOwDPr0wtnn2cQZ1tCQU+v_R4pBEg=-VeQVUxu6Jhw@mail.gmail.com>

On 3/16/18, Dave Horsfall <dave at horsfall.org> wrote:
> We lost computer pioneer John Backus on this day in 2007; amongst other
> things he gave us FORTRAN (yuck!) and BNF, which is ironic, really,
> because FORTRAN has no syntax to speak of.
>
(Mis-)features such as the insignificance of white space made some
sense when the target consumers for the language (numerical analysts)
were accustomed to writing numbers with commas or spaces separating
groups of digits (e.g., 1 234 567 and 1,234,567).  Of course, that
does lead to grammatical nasties such as the need for
context-sensitive lexical analysis.

I suspect that FORTRAN's syntax was designed before its creators had
read any of the formal language work of Chomsky et. al., hence its
poorly-behaved grammar.

-Paul W.


From clemc at ccc.com  Mon Mar 19 07:07:29 2018
From: clemc at ccc.com (Clem Cole)
Date: Sun, 18 Mar 2018 17:07:29 -0400
Subject: [TUHS] RIP John Backus
In-Reply-To: <CABH=_VSEyOwDPr0wtnn2cQZ1tCQU+v_R4pBEg=-VeQVUxu6Jhw@mail.gmail.com>
References: <alpine.BSF.2.21.1803170848420.819@aneurin.horsfall.org>
 <CABH=_VSEyOwDPr0wtnn2cQZ1tCQU+v_R4pBEg=-VeQVUxu6Jhw@mail.gmail.com>
Message-ID: <CAC20D2POLKfgPefXSOECX3N5AKffxGKMjNJLi9pD-xWkX8Ffhg@mail.gmail.com>

On Sun, Mar 18, 2018 at 2:51 PM, Paul Winalski <paul.winalski at gmail.com>
wrote:

> On 3/16/18, Dave Horsfall <dave at horsfall.org> wrote:
> > We lost computer pioneer John Backus on this day in 2007; amongst other
> > things he gave us FORTRAN (yuck!) and BNF, which is ironic, really,
> > because FORTRAN has no syntax to speak of.
> >
> (Mis-)features such as the insignificance of white space made some
> sense when the target consumers for the language (numerical analysts)
> were accustomed to writing numbers with commas or spaces separating
> groups of digits (e.g., 1 234 567 and 1,234,567).  Of course, that
> does lead to grammatical nasties such as the need for
> context-sensitive lexical analysis.
>
> I suspect that FORTRAN's syntax was designed before its creators had
> read any of the formal language work of Chomsky et. al., hence its
> poorly-behaved grammar.
>
> -Paul W.
>
Right .. my point was it is easy to trash talk something that was
remarkably successful such as FORTRAN when it was created (60 years) later​

​when we get to look back on the design with a great deal more knowledge
that original designers had creating it​.   To be honest, I have a hard
time imagining writing some of the programs my late father did when he was
a 'computer' in the later 50s and early 60s and he and his peeps started to
convert their work from manual equation grinding to computer simulation (
*i.e.* the movie Hidden Figures).

As importantly, it was just those old codes that made the market to allowed
computers to become valuable.  Remember that the original estimates in the
1940-50s was a tens of systems world wide.   FORTRAN was really the key
enabler that made market and created the need for more computers.

Again, we can not judge with today's lens if for no other reason than
because so much of what we have in computing (just the space and speed of
the systems alone) were unimaginable in the 50s & 60s.    Computer time was
much more expensive/too precious.  I'm not sure my adult aged children or
most of their friends have ever used systems were 'accounting' was done and
'charge back' was performed, number of seconds of CPU time was calculated.
 [IIRC: The student WatFIV compiler at CMU on TSS/360 gave you no more than
10 seconds of compile time and 2.5 seconds of run time for your batch
job].  Today we have IDE's, and interactive debuggers etc...    such were
just not cost effective.   The key point being that computers cost more
than people.

To bring this back to UNIX.   That was one of the really remarkable things
about Ken and Dennis work.   Interactive systems like UNIX were not the
norm.   Yes, DEC sold them and they were are hit for only a small group,
but even TOPS-10 systems were out of reach for many (remember K&D had their
PDP-10 proposal tossed out by their management].   Unix ran on 'modest'
hardware and that changed a lot of things.  And I think that is one of the
reasons why Fortran was 'knocked' out of its position with many
programmers.   Interactive computing changed who was using computers.


But as Paul mentioned, Fortran had already become the linga-franc of the
scientific community before we were able to use computers as we do today.
As I said, the math they used has not changed and it is remarkable that
that old 1960's code still works.   Steve put it well and I'll add a
challenge to any hot shot programmer (which at one time I guess I
considered myself to be) to have done much better (I'm sure I could not
have).   I am humbled by how good a job they did with creating both the
language itself, the codes that used it, and how long/well those codes have
stood the test of time.

I was introduced at FORTRAN-IV, after learning Assembler and BASIC and
learned Algol-W at the same time.  At the time, I was pretty impressed,
with F4, some of its strangeness like white space, or column orientation
were not that strange given we all were on cards.    But I was lucky to be
at a place were interactive computing was also blossoming and was given all
the computer I wanted on PDP-10s and PDP-11s.   I stopped writing FORTRAN
because we had SAIL, BLISS and eventually C and Pascal.  Although thinking
back, the last large Fortran program I wrote for CMU was an accounting
program for the PDP-20's in '76 that computer center had.   I'm not sure
why they wanted it in Fortran, but I do remember that was a requirement,
probably because it had to run TSS also.

I do remember, one of the big issues with UNIX being picked up into the EE
department was the lack of a 'proper Fortran.'    As much as modern
languages like C and Pascal were clearly the direction, a lot of professors
had a lot of code in FORTRAN they wanted to run.

So now I live in a world were the best FORTRAN compilers are UNIX based and
I don't write with FORTRAN anymore.   I still have a ton of respect for
those that do and even more for the wizards like Paul and co that have
spent their careers creating compilers for FORTRAN that have spanned such
changes in the underlying system hardware, as well as the language itself
and keep those same user codes getting correct answers and using the
hardware as well as can be.

So I never knock FORTRAN or FORTRAN programmers.   While we may not chose
to use it because it is the wrong tool for our job, they have done and
continue to do much for all of us and we all should really remember that.

Clem



ᐧ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180318/5a4702a8/attachment.html>

From tfb at tfeb.org  Mon Mar 19 07:26:05 2018
From: tfb at tfeb.org (Tim Bradshaw)
Date: Sun, 18 Mar 2018 21:26:05 +0000
Subject: [TUHS] RIP John Backus
In-Reply-To: <CABH=_VSEyOwDPr0wtnn2cQZ1tCQU+v_R4pBEg=-VeQVUxu6Jhw@mail.gmail.com>
References: <alpine.BSF.2.21.1803170848420.819@aneurin.horsfall.org>
 <CABH=_VSEyOwDPr0wtnn2cQZ1tCQU+v_R4pBEg=-VeQVUxu6Jhw@mail.gmail.com>
Message-ID: <C2E39E24-0037-4AF8-9303-0A5D21669471@tfeb.org>

On 18 Mar 2018, at 18:51, Paul Winalski <paul.winalski at gmail.com> wrote:
> 
> I suspect that FORTRAN's syntax was designed before its creators had
> read any of the formal language work of Chomsky et. al., hence its
> poorly-behaved grammar.

They probably could not have read it: if I'm right, the draft specification for FORTRAN was 1954, with the manual and an implementation following in October 1956 & April 1957.  The Chomsky hierarchy was described by Chomsky in 1956.  So they got FORTRAN 'wrong' because no-one knew what 'right' was, or how it differed from 'wrong' at the point they had to decide what the syntax was going to be.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180318/23beeec0/attachment.html>

From jnc at mercury.lcs.mit.edu  Mon Mar 19 07:38:57 2018
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Sun, 18 Mar 2018 17:38:57 -0400 (EDT)
Subject: [TUHS] PDP-11 DIV instruction lossage
Message-ID: <20180318213857.8EE9918C089@mercury.lcs.mit.edu>

So, I have discovered, to my astonishment, that the double-word version of the
DIV instruction on the PDP-11 won't do a divide if the result won't fit into
15 bits. OK, I can understand it bitching if the quotient wouldn't fit into 16
bits - but what's the problem with returning an unsigned quotient?

And, just for grins, the results left in the registers which hold the quotient
and remainer is different in the -11/23 (KDF11-A) and the -11/73 (KDJ11-A).
(Although, to be fair, the PDP-11 Architecture Manual says 'register contents
are unpredictable if there's an overflow'.)

Oh well, guess I'll have to redo my kludgy fix to gmtime() (the distributed
version of which in V6 qhas a problem when the number of 8-hour periods since
the epoch overflows 15 bits)! I guess I'll have to fix it for real, instead of
my kludgy fix (which extended it to work for 16-bit results). :-)


I discovered this when I plugged in an -11/73 to make sure the prototype QSIC
(our RK11/etc emulator for the QBUS) worked with the -11/73 as well as the
-11/23 (which is what we'd mostly been using - when we first started working
on the DMA and interrupts, we did try them both). I noticed that with the
-11/73, the date printed incorrectly:

  Sun Mar 10 93:71:92 EST 1991

After a certain amount of poking and prodding, I discovered the issue - and
on further reading, discovered the limitation to 15-bit results.


For those who are interested in the details, here's a little test program that
displays the problem:

       r = ldiv(a, b, d);
       m = ldivr;

       printf("a: 0%o %d.  b: 0%o %d.  d: 0%o %d.\n", a, a, b, b, d, d);
       printf("q: 0%o %d.  r: 0%o %d.\n", r, r, m, m);

and, for those who don't have V6 source at hand, here's ldiv():

        mov     2(sp),r0
        mov     4(sp),r1
        div     6(sp),r0
        mov     r1,_ldivr
        rts     pc

So here are the results, first from a simulator:

  tld 055256 0145510 070200
  a: 055256 23214.  b: 0145510 -13496.  d: 070200 28800.
  q: 0147132 -12710.  r: 037110 15944.

This is _mathematically_ correct: 055256,0145510 = 1521404744., 070200 =
28800., and 1521404744./28800. = 0147132.

And on the -11/23:

  a: 055256 23214.  b: 0145510 -13496.  d: 070200 28800.
  q: 055256 23214.  r: 037110 15944.

Note that the returned 'quotient' is simply the high part of the dividend.

And on the -11/73:

  a: 055256 23214.  b: 0145510 -13496.  d: 070200 28800.
  q: 055256 23214.  r: 037110 15944.

Note that in addition to the quotient behaviour, as with the /23, the
'remainder' is the low part of the dividend.

	    Noel



From scj at yaccman.com  Mon Mar 19 10:26:36 2018
From: scj at yaccman.com (Steve Johnson)
Date: Sun, 18 Mar 2018 17:26:36 -0700
Subject: [TUHS] RIP John Backus
In-Reply-To: <CABH=_VSEyOwDPr0wtnn2cQZ1tCQU+v_R4pBEg=-VeQVUxu6Jhw@mail.gmail.com>
Message-ID: <52c5a2e1a53e5a0d88246bf29e52acf696e9c85a@webmail.yaccman.com>

I had an interesting run-in with FORTRAN's blank treatment very early
in my career.   A couple of weeks after I graduated from college I
had a summer job at Bell Labs.  I was given a job to program a state
minimization algorithm -- they expected it to take me the whole
summer.  A couple of days after arriving, i heard about a new
language, SNOBOL, developed at another location at Bell Labs.  This
sounded like the perfect language to write my program in, so I got a
copy to use (I think I was the first user at Murray Hill).

Now, in those days, there were rooms full of "keypunch girls" (sic)
whose job was to punch up our programs (written on coding sheets) and
verify them and give us the deck back.  The vast majority of jobs
they encountered were FORTRAN, and to avoid ambiguity they simply
skipped all blanks.   (it wasn't quite that easy -- they knew about
column 7 and hollerith strings).  But any blanks that we wanted on
the cards had to be explicitly indicated on the coding sheet.

Of course, SNOBOL had what we would consider now a more modern syntax
with blanks significant and nothing magic about columns 6 or 7...   
So when I gave them my first 2-page SNOBOL program, they typed
everything on each line starting in column 7 and with all blanks
removed.    For some reason, the first couple of cards looked OK to
me, so I submitted the deck, and proceeded to get a thick printout
that I think enumerated every error message the compiler could
produce.

I started indicating my blanks carefully but their habit persisted,
and almost any nontrivial job  I gave them had errors, either because
I hadn't inidicated a blank or they hadn't typed it when I indicated
it.

Since I had been punching cards myself for a couple of years at
college, and when working 2nd shift (when turnaround was much better)
there were no keypunchers available, after a couple of weeks I got
them to agree to let me keypunch my own programs.  A few years later,
the keypunchers were gone, having been rendered obsolete by time
sharing and online editing...

Oh, and I got the job done in 3 weeks once I got SNOBOL to work...  
It really was the right language for the job...

Steve

PS:  For years afterwards, when I punched in FORTRAN programs I left
out all the blanks.  It wasn't until  I worked on a large program
with several other people that I was forced to change this habit, my
coworkers having threatened me with death or dismemberment if I
didn't... 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180318/2a26a542/attachment.html>

From jnc at mercury.lcs.mit.edu  Tue Mar 20 00:03:59 2018
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Mon, 19 Mar 2018 10:03:59 -0400 (EDT)
Subject: [TUHS] PDP-11 DIV instruction lossage
Message-ID: <20180319140359.2204C18C088@mercury.lcs.mit.edu>

    > I'll have to redo my kludgy fix to gmtime() ... I guess I'll have to fix
    > it for real, instead of my kludgy fix (which extended it to work for
    > 16-bit results). :-)
    > ...
    > And on the -11/23:
    > Note that the returned 'quotient' is simply the high part of the dividend.

Heh. I had decided that the easiest clean and long-lived fix was to just to do
it right, using the long division routine used in the V7 C compiler runtime:

  http://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/libc/crt/ldiv.s

and I vaguely recalled reading a DMR story that talked about that, so just for
amusement I decided to re-read it, and looked it up:

  https://www.bell-labs.com/usr/dmr/www/odd.html

(the section "Comments I do feel guilty about"), and it's lucky I did, because
I found this:

  Addendum 18 Oct 1998

  Amos Shapir of nSOF (and of long memory!) just blackened (or widened) the
  spot a bit more in a mail message, to wit:
 
  'I gather the "almost" here is because this trick almost worked... It has a
  nasty bug which I had to find the hard way!

  The "clever part" relies on the fact that if the "bvc 1f" is not taken, it
  means that the result could not fit in 16 bits; in that case the long value
  in r0,r1 is left unchanged. The bug is that this behavior is not documented;
  in later models (I found this on an 11/34) when the result does fit in 16
  bits but not in 15 bits ... which makes this routine provide very strange
  results!'

So this code won't work on an 11/23 either (which bashes the low register of
the pair; above). I'd have been groveling in buggy math, again...

Caveat Haquur (if you're trying to run stock V7 on a /23 or /34)!

       Noel


From imp at bsdimp.com  Tue Mar 20 00:26:11 2018
From: imp at bsdimp.com (Warner Losh)
Date: Mon, 19 Mar 2018 08:26:11 -0600
Subject: [TUHS] RIP John Backus
In-Reply-To: <52c5a2e1a53e5a0d88246bf29e52acf696e9c85a@webmail.yaccman.com>
References: <CABH=_VSEyOwDPr0wtnn2cQZ1tCQU+v_R4pBEg=-VeQVUxu6Jhw@mail.gmail.com>
 <52c5a2e1a53e5a0d88246bf29e52acf696e9c85a@webmail.yaccman.com>
Message-ID: <CANCZdfqCTZsL3n=qTEpPG7As6SQNsDbPEONNK4=Ha4atuqOEbQ@mail.gmail.com>

On Sun, Mar 18, 2018 at 6:26 PM, Steve Johnson <scj at yaccman.com> wrote:

> PS:  For years afterwards, when I punched in FORTRAN programs I left out
> all the blanks.  It wasn't until  I worked on a large program with several
> other people that I was forced to change this habit, my coworkers having
> threatened me with death or dismemberment if I didn't...
>

No boiling oil? I'd say they were going light on you :)

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180319/937a8920/attachment.html>

From crossd at gmail.com  Tue Mar 20 00:50:37 2018
From: crossd at gmail.com (Dan Cross)
Date: Mon, 19 Mar 2018 10:50:37 -0400
Subject: [TUHS] RIP John Backus
In-Reply-To: <CAC20D2POLKfgPefXSOECX3N5AKffxGKMjNJLi9pD-xWkX8Ffhg@mail.gmail.com>
References: <alpine.BSF.2.21.1803170848420.819@aneurin.horsfall.org>
 <CABH=_VSEyOwDPr0wtnn2cQZ1tCQU+v_R4pBEg=-VeQVUxu6Jhw@mail.gmail.com>
 <CAC20D2POLKfgPefXSOECX3N5AKffxGKMjNJLi9pD-xWkX8Ffhg@mail.gmail.com>
Message-ID: <CAEoi9W6_JLMubF0yM4dH+ep6DTHCia9X666kSQGPCuOodUR2LQ@mail.gmail.com>

On Sun, Mar 18, 2018 at 5:07 PM, Clem Cole <clemc at ccc.com> wrote:
>
> [...]
> I do remember, one of the big issues with UNIX being picked up into the EE
> department was the lack of a 'proper Fortran.'    As much as modern
> languages like C and Pascal were clearly the direction, a lot of professors
> had a lot of code in FORTRAN they wanted to run.
>
> So now I live in a world were the best FORTRAN compilers are UNIX based
> and I don't write with FORTRAN anymore.   I still have a ton of respect for
> those that do and even more for the wizards like Paul and co that have
> spent their careers creating compilers for FORTRAN that have spanned such
> changes in the underlying system hardware, as well as the language itself
> and keep those same user codes getting correct answers and using the
> hardware as well as can be.
>

And to bring this back around to Unix, here are a couple of random
questions....

First, in Dennis Ritchie's paper, "The Development of the C Language" (
https://www.bell-labs.com/usr/dmr/www/chist.html) he mentions the early
days of Unix, Ken taking Doug McIlroy's implementation of "TMG" on the
PDP-7 as a challenge and deciding to produce a "systems programming
language." The first effort was, apparently, "a rapidly scuttled attempt at
Fortran", followed by B.

I'm curious at the FORTRAN effort: what was that about, where did it come
from, and why was it abandoned?

Second, 7th Edition came with the "f77" command implementing
(unsurprisingly) Fortran 77. A paper by Stu Feldman and Peter Weinberger in
Volume 2 describes the compiler and includes this line: "This is believed
to be the first complete Fortran 77 system to be implemented." (
https://s3.amazonaws.com/plan9-bell-labs/7thEdMan/vol2/f77.txt)

Was that true? Notable in this paper is mention that the Fortran compiler
can drive the backend of either Ritchie's PDP-11 C compiler *or* Johnson's
portable C compiler. What was the local story? Did this see local use?

        - Dan C.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180319/5452fa3e/attachment.html>

From random832 at fastmail.com  Tue Mar 20 01:32:38 2018
From: random832 at fastmail.com (Random832)
Date: Mon, 19 Mar 2018 11:32:38 -0400
Subject: [TUHS] PDP-11 DIV instruction lossage
In-Reply-To: <20180319140359.2204C18C088@mercury.lcs.mit.edu>
References: <20180319140359.2204C18C088@mercury.lcs.mit.edu>
Message-ID: <1521473558.1945631.1308301672.0CD3ACAD@webmail.messagingengine.com>

On Mon, Mar 19, 2018, at 10:03, Noel Chiappa wrote:
>     > I'll have to redo my kludgy fix to gmtime() ... I guess I'll have to fix
>     > it for real, instead of my kludgy fix (which extended it to work for
>     > 16-bit results). :-)
>     > ...
>     > And on the -11/23:
>     > Note that the returned 'quotient' is simply the high part of the dividend.
> 
> Heh. I had decided that the easiest clean and long-lived fix was to just to do
> it right, using the long division routine used in the V7 C compiler runtime:

I did a version of gmtime a few months ago that divides by 86400 using the V6 ldiv function (by shifting by 7 to divide by 128 first, then dividing by 675). My main interest was in getting it to treat timestamps as unsigned (despite the V6 compiler having neither an unsigned type nor a long type) in order to push back the 2038 problem. After adding an overflow warning to apout, it looks like mine manages to avoid hitting the overflow until September of 2059.


From clemc at ccc.com  Tue Mar 20 01:43:45 2018
From: clemc at ccc.com (Clem Cole)
Date: Mon, 19 Mar 2018 11:43:45 -0400
Subject: [TUHS] RIP John Backus
In-Reply-To: <CAEoi9W6_JLMubF0yM4dH+ep6DTHCia9X666kSQGPCuOodUR2LQ@mail.gmail.com>
References: <alpine.BSF.2.21.1803170848420.819@aneurin.horsfall.org>
 <CABH=_VSEyOwDPr0wtnn2cQZ1tCQU+v_R4pBEg=-VeQVUxu6Jhw@mail.gmail.com>
 <CAC20D2POLKfgPefXSOECX3N5AKffxGKMjNJLi9pD-xWkX8Ffhg@mail.gmail.com>
 <CAEoi9W6_JLMubF0yM4dH+ep6DTHCia9X666kSQGPCuOodUR2LQ@mail.gmail.com>
Message-ID: <CAC20D2PDOdvqv4-dGcNr7KTujE-aH7kAsUz+tspXZDhWPAix4w@mail.gmail.com>

On Mon, Mar 19, 2018 at 10:50 AM, Dan Cross <crossd at gmail.com> wrote:

> I'm curious at the FORTRAN effort: what was that about, where did it come
> from, and why was it abandoned?
>
​I'll let Ken, Steve or Doug answer definitively that​ but I would suspect
- it is a lot of work and at time t0, it was less valuable than some of the
other efforts going at the time.



>
> Second, 7th Edition came with the "f77" command implementing
> (unsurprisingly) Fortran 77. A paper by Stu Feldman and Peter Weinberger in
> Volume 2 describes the compiler and includes this line: "This is believed
> to be the first complete Fortran 77 system to be implemented." (
> https://s3.amazonaws.com/plan9-bell-labs/7thEdMan/vol2/f77.txt)
>
​Mumble, although probably true in absolute fact.  The DEC VAX/VMS Fortran
compiler was contemporary.   I have always said that the best piece of work
DEC Marketing ever did was convince the world that VMS Fortran was F77 (it
was not).   It ended up being a super-set, although it did not start out
that way (similar to people believing VT-100's are ANSI - they are and in
that case never did fully conform).




>
> Was that true? Notable in this paper is mention that the Fortran compiler
> can drive the backend of either Ritchie's PDP-11 C compiler *or* Johnson's
> portable C compiler. What was the local story? Did this see local use?
>
​I used the PCC/VAX version extensively (as well as ratfor) for the 'users
space' part of my thesis work.   My housemate, Tom Quarles, had developed
SPICE3 (in C) and Ellis Cohen had written SPICE2 in FORTRAN.   FPS had done
a great deal of development on the array processor that was the basis for
my work, all in Ratfor but assuming VMS under the coveres (they wrote an
optimizing parallel Fortran compiler in same -- those guys are now the
Portland Compiler Group).​


​I worked, although moving stuff from VMS to BSD was huge because F77 !=
VMS Fortran.  Much of the 'grunt' work I had was making all that work.​   In
fact, it was this work that I found a bug in the C compiler runtimes, that
I have written about elsewhere.  The ratfor code called F77, which shared
C's runtime.

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

From clemc at ccc.com  Tue Mar 20 01:46:54 2018
From: clemc at ccc.com (Clem Cole)
Date: Mon, 19 Mar 2018 11:46:54 -0400
Subject: [TUHS] RIP John Backus
In-Reply-To: <CAC20D2PDOdvqv4-dGcNr7KTujE-aH7kAsUz+tspXZDhWPAix4w@mail.gmail.com>
References: <alpine.BSF.2.21.1803170848420.819@aneurin.horsfall.org>
 <CABH=_VSEyOwDPr0wtnn2cQZ1tCQU+v_R4pBEg=-VeQVUxu6Jhw@mail.gmail.com>
 <CAC20D2POLKfgPefXSOECX3N5AKffxGKMjNJLi9pD-xWkX8Ffhg@mail.gmail.com>
 <CAEoi9W6_JLMubF0yM4dH+ep6DTHCia9X666kSQGPCuOodUR2LQ@mail.gmail.com>
 <CAC20D2PDOdvqv4-dGcNr7KTujE-aH7kAsUz+tspXZDhWPAix4w@mail.gmail.com>
Message-ID: <CAC20D2Mtgr1Sbsbe7jxSL+r6FJ2cC3n+z1UtczmdH_kce-g64g@mail.gmail.com>

arrgh -- dyslexia -- VT-100's are NOT  full ansi [they use the ANSI
sequences, but do not implement all of the features/behaviors in the
spec].  VMS Fortran started the same way, although it did conform in time
because it had to pass the Fortran validation tests.
ᐧ

On Mon, Mar 19, 2018 at 11:43 AM, Clem Cole <clemc at ccc.com> wrote:

>
>
> On Mon, Mar 19, 2018 at 10:50 AM, Dan Cross <crossd at gmail.com> wrote:
>
>> I'm curious at the FORTRAN effort: what was that about, where did it come
>> from, and why was it abandoned?
>>
> ​I'll let Ken, Steve or Doug answer definitively that​ but I would suspect
> - it is a lot of work and at time t0, it was less valuable than some of the
> other efforts going at the time.
>
>
>
>>
>> Second, 7th Edition came with the "f77" command implementing
>> (unsurprisingly) Fortran 77. A paper by Stu Feldman and Peter Weinberger in
>> Volume 2 describes the compiler and includes this line: "This is believed
>> to be the first complete Fortran 77 system to be implemented." (
>> https://s3.amazonaws.com/plan9-bell-labs/7thEdMan/vol2/f77.txt)
>>
> ​Mumble, although probably true in absolute fact.  The DEC VAX/VMS Fortran
> compiler was contemporary.   I have always said that the best piece of work
> DEC Marketing ever did was convince the world that VMS Fortran was F77 (it
> was not).   It ended up being a super-set, although it did not start out
> that way (similar to people believing VT-100's are ANSI - they are and in
> that case never did fully conform).
>
>
>
>
>>
>> Was that true? Notable in this paper is mention that the Fortran compiler
>> can drive the backend of either Ritchie's PDP-11 C compiler *or* Johnson's
>> portable C compiler. What was the local story? Did this see local use?
>>
> ​I used the PCC/VAX version extensively (as well as ratfor) for the 'users
> space' part of my thesis work.   My housemate, Tom Quarles, had developed
> SPICE3 (in C) and Ellis Cohen had written SPICE2 in FORTRAN.   FPS had done
> a great deal of development on the array processor that was the basis for
> my work, all in Ratfor but assuming VMS under the coveres (they wrote an
> optimizing parallel Fortran compiler in same -- those guys are now the
> Portland Compiler Group).​
>
>
> ​I worked, although moving stuff from VMS to BSD was huge because F77 !=
> VMS Fortran.  Much of the 'grunt' work I had was making all that work.​   In
> fact, it was this work that I found a bug in the C compiler runtimes, that
> I have written about elsewhere.  The ratfor code called F77, which shared
> C's runtime.
>
> ᐧ
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180319/df2c2825/attachment.html>

From clemc at ccc.com  Tue Mar 20 01:55:00 2018
From: clemc at ccc.com (Clem Cole)
Date: Mon, 19 Mar 2018 11:55:00 -0400
Subject: [TUHS] RIP John Backus
In-Reply-To: <CAEoi9W6_JLMubF0yM4dH+ep6DTHCia9X666kSQGPCuOodUR2LQ@mail.gmail.com>
References: <alpine.BSF.2.21.1803170848420.819@aneurin.horsfall.org>
 <CABH=_VSEyOwDPr0wtnn2cQZ1tCQU+v_R4pBEg=-VeQVUxu6Jhw@mail.gmail.com>
 <CAC20D2POLKfgPefXSOECX3N5AKffxGKMjNJLi9pD-xWkX8Ffhg@mail.gmail.com>
 <CAEoi9W6_JLMubF0yM4dH+ep6DTHCia9X666kSQGPCuOodUR2LQ@mail.gmail.com>
Message-ID: <CAC20D2P-dNX8AM_mh5N+Th-VYsG9COP8PX8QufLmFE2zh7MUqw@mail.gmail.com>

On Mon, Mar 19, 2018 at 10:50 AM, Dan Cross <crossd at gmail.com> wrote:

> "This is believed to be the first complete Fortran 77 system to be
> implemented." (https://s3.amazonaws.com/plan9-bell-labs/7thEdMan/vol2/f77.
> txt)
>

​Question to Steve or aps -- certainly V7's version could not pass the
validation test as distributed from AT&T and UCB (at Masscomp we actually
ran the validation suite through it in the our 4.1 Vax -- we decided it was
going to be too much work and we had started over with new front and back
ends  when we created a compiler group with ex-DECies - C and Fortran being
the primary).  But I assume at some time folks in Summit did the work on
making the AT&T version pass at least by the timer PCC2.  Assuming it did,
do you have any idea when it was running through and got an official seal
as being validated?

ᐧ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180319/0b38cfe8/attachment.html>

From scj at yaccman.com  Tue Mar 20 02:58:48 2018
From: scj at yaccman.com (Steve Johnson)
Date: Mon, 19 Mar 2018 09:58:48 -0700
Subject: [TUHS]  FORTRAN
In-Reply-To: <CAC20D2P-dNX8AM_mh5N+Th-VYsG9COP8PX8QufLmFE2zh7MUqw@mail.gmail.com>
Message-ID: <61051ebbca4809c08b60e92014851069e83a07f8@webmail.yaccman.com>

Here is the FORTRAN story as I remember it.

At Bell Labs, during the 7094 days a lot of code was written with FAP
macros.   I remember a LISP compiler that could go 150 levels
deep.  There was an excellent simulation package for filters that was
all assembler and macros.

When we switched to the GE (later Honeywell), all that work was
lost.   It was very painful, and a majority of people swore "never
again" and switched to FORTRAN.  A symbolic algebra program in
assembler, ALPACK, was slowly recreated in FORTRAN by a team of about
five of us.  That was the first time I worked with Dennis, who was
able to make a dynamic storage allocator and support recursive calling
in FORTRAN, a tour de force.  We were acutely aware that not all
FORTRAN compilers were compatible, and Barbara Ryder wrote a PFORT, a
program that validated that our programs fell into the subset of
FORTRAN that actually worked on the six major manufacturers'
FORTRANs.  PFORT was one of the inspirations for Lint.  Many of the
differences were completely bizarre -- one FORTRAN would abort if you
began a program with more than fifty comment lines...

At the time, the main computing center was actually run by the
Research department, using a kludged-up OS on the GE--one that had
originally been intended to run the much-delayed Multics.    When
they finally set up a separate computing dept., I was asked to move
over for a couple of years to make sure things went well.   I found
that I needed to write some service programs for the GE, and didn't
want to learn assembly language.  By this time, Dennis had B running
on the PDP-11, and I suggested he port it to the GE.   He said the
sentence that changed my life -- "Why don't you do it.  After all,
it's just a program!".   B was well suited to the GE, being a
word-addressed machine.and soon I was adding features such as a way to
make character constants for the GE's 6-bit character set.  And I
added the ability to call FORTRAN programs, with a FORTRAN keyword. 
(Though it would have been useful, FORTRAN calling B was tricky
because of the need to set up the stack...)

So the point is, FORTRAN was dominant at Bell Labs for most of the
time that C was being developed.  There was a group that was pushing
the adoption of PL/1, being used to code Multics, but the compiler was
late and not very good and it never really caught on.  The GE
compiler was one of the three that I abstracted the machine
independent code from for PCC (the other two were PDP-11 and IBM 360).

Stu Feldman decided to do F77 -- I'm not sure what his motivation was,
but there were a number of compelling ones available.  We talked
about what would be needed in the code generator and it wasn't much. 
 F77 pretty much used the C calling sequence and runtime library,
with added functions to do format statements, etc.  And knowing Stu,
it was as close to the standard as he could make it.

Fast forward a few years.   Unix and C were widely used in the Labs,
and while FORTRAN was still important for heavy numerical work, it was
waning in popularity.  I had accepted a job in development, being in
charge of System V languages -- C, Pascal, FORTRAN,Ada, and later the
first commercial C++ compiler..  It was obvious that F77 was losing
business bigtime to DEC VMS because their FORTRAN was better.  In
particular, the VMS programs ran faster.  So I put together a small
team of some of my best people to write a FORTRAN optimizer.

That project was very difficult to save -- every six weeks or so,
people would look at it, decide FORTRAN was passe, and cut it out of
the budget.  I would go to the mat and insist that it was important
and get it put back in.   We almost put entries in our calendars
every six weeks -- time to save FORTAN again.  The AT&T marketing
department treated languages as completely unimportant, and kept
assigning their newest hire to interface with me.  I had the same
meeting every month for a half-year or more, each with a different
newbie with no idea what a computer language was.  

By 1986 it became clear to me that I loved development but that AT&T
was never going to make it in the computer business.  I accepted a
job in California at a startup.  Less than a month after I left, the
FORTRAN optimizer (by now almost ready to ship) was cancelled.   A
couple of months later, it was revived and finally went to market.

I'm told that six months after that it was the best selling language
product...

Steve


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180319/189d314f/attachment.html>

From nobozo at gmail.com  Tue Mar 20 03:32:57 2018
From: nobozo at gmail.com (Jon Forrest)
Date: Mon, 19 Mar 2018 10:32:57 -0700
Subject: [TUHS] FORTRAN
In-Reply-To: <61051ebbca4809c08b60e92014851069e83a07f8@webmail.yaccman.com>
References: <61051ebbca4809c08b60e92014851069e83a07f8@webmail.yaccman.com>
Message-ID: <e3c0e8ee-4b95-3661-1a5f-39d1aa6323f4@gmail.com>



In roughly 1977 I was trying to use the 'fc' Fortran compiler
that came with Version 6 Unix at UC Santa Barbara. I needed to
do some binary I/O to read digitized speech data. That compiler
was very limited so I did what anybody would do back then - I called
Dennis Ritchie, who had written 'fc', to ask him what to do. I remember
he was surprisingly gracious but I don't remember what he said to do.

Version 7 Unix came to UCSB soon afterwards and I started using it.
It was easy to call C routines from it, which I did for a number of
low level purposes. However, I soon discovered some 'f77' bugs.
Fortunately Stu Feldman was visiting UCSB so I was able to demonstrate
the bugs to him personally. Again, I don't remember what came of this
but the Unix world was so small back then that it was common to be able
to communicate with many of the key developers.

Jon Forrest


From paul.winalski at gmail.com  Tue Mar 20 03:39:46 2018
From: paul.winalski at gmail.com (Paul Winalski)
Date: Mon, 19 Mar 2018 13:39:46 -0400
Subject: [TUHS] RIP John Backus
In-Reply-To: <CAC20D2Mtgr1Sbsbe7jxSL+r6FJ2cC3n+z1UtczmdH_kce-g64g@mail.gmail.com>
References: <alpine.BSF.2.21.1803170848420.819@aneurin.horsfall.org>
 <CABH=_VSEyOwDPr0wtnn2cQZ1tCQU+v_R4pBEg=-VeQVUxu6Jhw@mail.gmail.com>
 <CAC20D2POLKfgPefXSOECX3N5AKffxGKMjNJLi9pD-xWkX8Ffhg@mail.gmail.com>
 <CAEoi9W6_JLMubF0yM4dH+ep6DTHCia9X666kSQGPCuOodUR2LQ@mail.gmail.com>
 <CAC20D2PDOdvqv4-dGcNr7KTujE-aH7kAsUz+tspXZDhWPAix4w@mail.gmail.com>
 <CAC20D2Mtgr1Sbsbe7jxSL+r6FJ2cC3n+z1UtczmdH_kce-g64g@mail.gmail.com>
Message-ID: <CABH=_VRs8OVAwYGuEbhSVVYy8L7dmxnkx-TmXnqafpzKZ-A5fg@mail.gmail.com>

On 3/19/18, Clem Cole <clemc at ccc.com> wrote:
> arrgh -- dyslexia -- VT-100's are NOT  full ansi [they use the ANSI
> sequences, but do not implement all of the features/behaviors in the
> spec].  VMS Fortran started the same way, although it did conform in time
> because it had to pass the Fortran validation tests.
>
VAX/VMS Fortran was under development at the same time as the
Fortran-77 standard.  For the VMS Fortran development team, the new
F77 features weren't a particularly high priority at the time because
there wasn't any existing code that used them, whereas there was a ton
of dusty-deck IBM FORTRAN II and FORTRAN IV code out there, especially
in the educational market DEC was keenest to sell the VAX into.  F77
features were implemented over time in VAX/VMS Fortran, and after a
couple of releases it was fully Fortran-77 compliant.  But at first
release in 1978 it was an extended subset of F77.

Was f77 the first Fortran for UNIX, or were there other compilers for
Fortran before f77 came along?

-Paul W.


From ggm at algebras.org  Tue Mar 20 03:43:24 2018
From: ggm at algebras.org (George Michaelson)
Date: Mon, 19 Mar 2018 17:43:24 +0000
Subject: [TUHS] RIP John Backus
In-Reply-To: <CABH=_VRs8OVAwYGuEbhSVVYy8L7dmxnkx-TmXnqafpzKZ-A5fg@mail.gmail.com>
References: <alpine.BSF.2.21.1803170848420.819@aneurin.horsfall.org>
 <CABH=_VSEyOwDPr0wtnn2cQZ1tCQU+v_R4pBEg=-VeQVUxu6Jhw@mail.gmail.com>
 <CAC20D2POLKfgPefXSOECX3N5AKffxGKMjNJLi9pD-xWkX8Ffhg@mail.gmail.com>
 <CAEoi9W6_JLMubF0yM4dH+ep6DTHCia9X666kSQGPCuOodUR2LQ@mail.gmail.com>
 <CAC20D2PDOdvqv4-dGcNr7KTujE-aH7kAsUz+tspXZDhWPAix4w@mail.gmail.com>
 <CAC20D2Mtgr1Sbsbe7jxSL+r6FJ2cC3n+z1UtczmdH_kce-g64g@mail.gmail.com>
 <CABH=_VRs8OVAwYGuEbhSVVYy8L7dmxnkx-TmXnqafpzKZ-A5fg@mail.gmail.com>
Message-ID: <CAKr6gn3FUT4MaRqfPeP8nbreEqzQxp=GcvG0ks6sasTAngb1ew@mail.gmail.com>

Once f2c could compile "zork" I stopped caring. Maybe that says it all.


From clemc at ccc.com  Tue Mar 20 03:48:45 2018
From: clemc at ccc.com (Clem Cole)
Date: Mon, 19 Mar 2018 13:48:45 -0400
Subject: [TUHS] RIP John Backus
In-Reply-To: <CABH=_VRs8OVAwYGuEbhSVVYy8L7dmxnkx-TmXnqafpzKZ-A5fg@mail.gmail.com>
References: <alpine.BSF.2.21.1803170848420.819@aneurin.horsfall.org>
 <CABH=_VSEyOwDPr0wtnn2cQZ1tCQU+v_R4pBEg=-VeQVUxu6Jhw@mail.gmail.com>
 <CAC20D2POLKfgPefXSOECX3N5AKffxGKMjNJLi9pD-xWkX8Ffhg@mail.gmail.com>
 <CAEoi9W6_JLMubF0yM4dH+ep6DTHCia9X666kSQGPCuOodUR2LQ@mail.gmail.com>
 <CAC20D2PDOdvqv4-dGcNr7KTujE-aH7kAsUz+tspXZDhWPAix4w@mail.gmail.com>
 <CAC20D2Mtgr1Sbsbe7jxSL+r6FJ2cC3n+z1UtczmdH_kce-g64g@mail.gmail.com>
 <CABH=_VRs8OVAwYGuEbhSVVYy8L7dmxnkx-TmXnqafpzKZ-A5fg@mail.gmail.com>
Message-ID: <CAC20D2NFfTNmD+OYa-7_RFF-WQmnwdBW-OXzNngKPJ-Qm=hQAg@mail.gmail.com>

6th edition had fc <http://man.cat-v.org/unix-6th/1/fc> but it would not
take a standard F4 (or F2) deck to my knowledge. It may have been in 5th
also.   It was pretty limited.  As I said, I remember one of the arguments
for why not UNIX in the EE Dept was the lack of a 'proper' Fortran
implementation.

I remember an an early attempt at f2c in those days [which I think came
from UMich], but it did not work much better than fc itself as it was a
subset language. FYI: f2c was much later (I want to say 82-83ish and post
f77).  But it was what Ted and I used to start to convert advent to C for
the UNIX, so that was pre V7 and must have been 76ish.

Clem
ᐧ

On Mon, Mar 19, 2018 at 1:39 PM, Paul Winalski <paul.winalski at gmail.com>
wrote:

> On 3/19/18, Clem Cole <clemc at ccc.com> wrote:
> > arrgh -- dyslexia -- VT-100's are NOT  full ansi [they use the ANSI
> > sequences, but do not implement all of the features/behaviors in the
> > spec].  VMS Fortran started the same way, although it did conform in time
> > because it had to pass the Fortran validation tests.
> >
> VAX/VMS Fortran was under development at the same time as the
> Fortran-77 standard.  For the VMS Fortran development team, the new
> F77 features weren't a particularly high priority at the time because
> there wasn't any existing code that used them, whereas there was a ton
> of dusty-deck IBM FORTRAN II and FORTRAN IV code out there, especially
> in the educational market DEC was keenest to sell the VAX into.  F77
> features were implemented over time in VAX/VMS Fortran, and after a
> couple of releases it was fully Fortran-77 compliant.  But at first
> release in 1978 it was an extended subset of F77.
>
> Was f77 the first Fortran for UNIX, or were there other compilers for
> Fortran before f77 came along?
>
> -Paul W.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180319/42064f3d/attachment.html>

From nobozo at gmail.com  Tue Mar 20 03:59:00 2018
From: nobozo at gmail.com (Jon Forrest)
Date: Mon, 19 Mar 2018 10:59:00 -0700
Subject: [TUHS] RIP John Backus
In-Reply-To: <CAC20D2NFfTNmD+OYa-7_RFF-WQmnwdBW-OXzNngKPJ-Qm=hQAg@mail.gmail.com>
References: <alpine.BSF.2.21.1803170848420.819@aneurin.horsfall.org>
 <CABH=_VSEyOwDPr0wtnn2cQZ1tCQU+v_R4pBEg=-VeQVUxu6Jhw@mail.gmail.com>
 <CAC20D2POLKfgPefXSOECX3N5AKffxGKMjNJLi9pD-xWkX8Ffhg@mail.gmail.com>
 <CAEoi9W6_JLMubF0yM4dH+ep6DTHCia9X666kSQGPCuOodUR2LQ@mail.gmail.com>
 <CAC20D2PDOdvqv4-dGcNr7KTujE-aH7kAsUz+tspXZDhWPAix4w@mail.gmail.com>
 <CAC20D2Mtgr1Sbsbe7jxSL+r6FJ2cC3n+z1UtczmdH_kce-g64g@mail.gmail.com>
 <CABH=_VRs8OVAwYGuEbhSVVYy8L7dmxnkx-TmXnqafpzKZ-A5fg@mail.gmail.com>
 <CAC20D2NFfTNmD+OYa-7_RFF-WQmnwdBW-OXzNngKPJ-Qm=hQAg@mail.gmail.com>
Message-ID: <6bc3b4da-08df-1a59-30b9-75d95541fdca@gmail.com>

One reason VAX Fortran was so popular is because DEC often
included it in quotes for Vaxes. If you were writing software
in a high-level language on VMS back then, writing it in Fortran
was a good bet since almost all Vaxes running VMS had Vax Fortran.

It took a while before the VAX C compiler was good enough, and
even then, it wasn't cheap. I was in the VMS development group
at Sybase in the early 1990s and we often hit issues in VAX C,
and in the VAX Debug support for it.

Back to Unix ...

Jon Forrest


From usotsuki at buric.co  Tue Mar 20 04:16:26 2018
From: usotsuki at buric.co (Steve Nickolas)
Date: Mon, 19 Mar 2018 14:16:26 -0400 (EDT)
Subject: [TUHS] RIP John Backus
In-Reply-To: <CAKr6gn3FUT4MaRqfPeP8nbreEqzQxp=GcvG0ks6sasTAngb1ew@mail.gmail.com>
References: <alpine.BSF.2.21.1803170848420.819@aneurin.horsfall.org>
 <CABH=_VSEyOwDPr0wtnn2cQZ1tCQU+v_R4pBEg=-VeQVUxu6Jhw@mail.gmail.com>
 <CAC20D2POLKfgPefXSOECX3N5AKffxGKMjNJLi9pD-xWkX8Ffhg@mail.gmail.com>
 <CAEoi9W6_JLMubF0yM4dH+ep6DTHCia9X666kSQGPCuOodUR2LQ@mail.gmail.com>
 <CAC20D2PDOdvqv4-dGcNr7KTujE-aH7kAsUz+tspXZDhWPAix4w@mail.gmail.com>
 <CAC20D2Mtgr1Sbsbe7jxSL+r6FJ2cC3n+z1UtczmdH_kce-g64g@mail.gmail.com>
 <CABH=_VRs8OVAwYGuEbhSVVYy8L7dmxnkx-TmXnqafpzKZ-A5fg@mail.gmail.com>
 <CAKr6gn3FUT4MaRqfPeP8nbreEqzQxp=GcvG0ks6sasTAngb1ew@mail.gmail.com>
Message-ID: <alpine.BSF.2.02.1803191415290.7526@frieza.hoshinet.org>

On Mon, 19 Mar 2018, George Michaelson wrote:

> Once f2c could compile "zork" I stopped caring. Maybe that says it all.

XD

That's the only Fortran program that matters to me. ;)

-uso.


From tih at hamartun.priv.no  Tue Mar 20 04:40:18 2018
From: tih at hamartun.priv.no (Tom Ivar Helbekkmo)
Date: Mon, 19 Mar 2018 19:40:18 +0100
Subject: [TUHS] RIP John Backus
In-Reply-To: <6bc3b4da-08df-1a59-30b9-75d95541fdca@gmail.com> (Jon Forrest's
 message of "Mon, 19 Mar 2018 10:59:00 -0700")
References: <alpine.BSF.2.21.1803170848420.819@aneurin.horsfall.org>
 <CABH=_VSEyOwDPr0wtnn2cQZ1tCQU+v_R4pBEg=-VeQVUxu6Jhw@mail.gmail.com>
 <CAC20D2POLKfgPefXSOECX3N5AKffxGKMjNJLi9pD-xWkX8Ffhg@mail.gmail.com>
 <CAEoi9W6_JLMubF0yM4dH+ep6DTHCia9X666kSQGPCuOodUR2LQ@mail.gmail.com>
 <CAC20D2PDOdvqv4-dGcNr7KTujE-aH7kAsUz+tspXZDhWPAix4w@mail.gmail.com>
 <CAC20D2Mtgr1Sbsbe7jxSL+r6FJ2cC3n+z1UtczmdH_kce-g64g@mail.gmail.com>
 <CABH=_VRs8OVAwYGuEbhSVVYy8L7dmxnkx-TmXnqafpzKZ-A5fg@mail.gmail.com>
 <CAC20D2NFfTNmD+OYa-7_RFF-WQmnwdBW-OXzNngKPJ-Qm=hQAg@mail.gmail.com>
 <6bc3b4da-08df-1a59-30b9-75d95541fdca@gmail.com>
Message-ID: <m2y3insyct.fsf@thuvia.hamartun.priv.no>

Jon Forrest <nobozo at gmail.com> writes:

> It took a while before the VAX C compiler was good enough, and
> even then, it wasn't cheap. I was in the VMS development group
> at Sybase in the early 1990s and we often hit issues in VAX C,
> and in the VAX Debug support for it.

VAX C was still pretty awful in the late 90s, while their FORTRAN was
really excellent, not least because of the high quality optimizer.

> Back to Unix ...

Agreed.  :)

...but first: being Norwegian, I have to plug another really good
FORTRAN compiler; the one in SINTRAN, the operating system for the
Norwegian built mini computers from Norsk Data.  They took FORTRAN-77,
and added even more bling to it, resulting in a compiler that could
accept the following program:

C    This FORTRAN progam may be compiled and run on a Norsk Data
C    computer running SINTRAN and the FTN compiler.  It uses only
C    FORTRAN reserved words, and contains just one numerical
C    constant, in a character string (a format specifier).  When
C    you run it, it prints a well known mathematical construct...
C
C    Even FORTRAN is a block structured programming language:

      PROGRAM
     ;PROGRAM;INTEGERIF,INTEGER,GOTO,IMPLICIT;REALREAL,DIMENSION,EXTERNA
     AL,FORMAT,END;INTEGERLOGICAL;REALCOMPLEX,DATA,CALL,ASSIGN,CHARACTER
     R;DOFORIF=INTEGER,INTEGER;ENDDO;INTEGER=IF+IF;GOTO=INTEGER*INTEGER*
     *INTEGER*INTEGER-INTEGER-IF;CALLFUNCTION(IMPLICIT,REAL,DIMENSION,EX
     XTERNAL,FORMAT,END,LOGICAL,COMPLEX,DATA,CALL,ASSIGN,CHARACTER);CALL
     LSUBROUTINE(IMPLICIT,LOGICAL,GOTO,IF,INTEGER);END;SUBROUTINEFUNCTIO
     ON(IMPLICIT,REAL,DIMENSION,EXTERNAL,FORMAT,END,LOGICAL,COMPLEX,DATA
     A,CALL,ASSIGN,CHARACTER);RETURN;END;SUBROUTINESUBROUTINE(IMPLICIT,L
     LOGICAL,GOTO,IF,INTEGER);INTEGERGOTO,IMPLICIT(GOTO),LOGICAL(GOTO),I
     IF,INTEGER,EXTERNAL,RETURN;DOFOREXTERNAL=IF,GOTO;DOFORRETURN=INTEGE
     ER,EXTERNAL-IF;IMPLICIT(RETURN)=LOGICAL(RETURN)+LOGICAL(RETURN-IF);
     ;ENDDO;IMPLICIT(IF)=IF;IMPLICIT(EXTERNAL)=IF;DOFORRETURN=IF,GOTO-EX
     XTERNAL;WRITE(IF,'(''$  '')');ENDDO;DOFORRETURN=IF,EXTERNAL;WRITE(I
     IF,'(''$''I4)')IMPLICIT(RETURN);ENDDO;WRITE(IF,'( /)');DOFORRETURN=
     =IF,GOTO;LOGICAL(RETURN)=IMPLICIT(RETURN);ENDDO;ENDDO;END

Anyone care to guess what the output looks like?

-tih
-- 
Most people who graduate with CS degrees don't understand the significance
of Lisp.  Lisp is the most important idea in computer science.  --Alan Kay
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180319/cbfb2413/attachment.sig>

From lm at mcvoy.com  Tue Mar 20 04:47:30 2018
From: lm at mcvoy.com (Larry McVoy)
Date: Mon, 19 Mar 2018 11:47:30 -0700
Subject: [TUHS] FORTRAN
In-Reply-To: <61051ebbca4809c08b60e92014851069e83a07f8@webmail.yaccman.com>
References: <CAC20D2P-dNX8AM_mh5N+Th-VYsG9COP8PX8QufLmFE2zh7MUqw@mail.gmail.com>
 <61051ebbca4809c08b60e92014851069e83a07f8@webmail.yaccman.com>
Message-ID: <20180319184730.GA7948@mcvoy.com>

On Mon, Mar 19, 2018 at 09:58:48AM -0700, Steve Johnson wrote:
> Here is the FORTRAN story as I remember it.
> 
> [much removed for brevity]

> By 1986 it became clear to me that I loved development but that AT&T
> was never going to make it in the computer business.?? I accepted a
> job in California at a startup.?? Less than a month after I left, the
> FORTRAN optimizer (by now almost ready to ship) was cancelled.?? ??A
> couple of months later, it was revived and finally went to market.
> 
> I'm told that six months after that it was the best selling language
> product...

Isn't it amusing (aka depressing) how some stuff has to be crammed down
people's throats?


From krewat at kilonet.net  Tue Mar 20 05:40:03 2018
From: krewat at kilonet.net (Arthur Krewat)
Date: Mon, 19 Mar 2018 15:40:03 -0400
Subject: [TUHS] RIP John Backus
In-Reply-To: <m2y3insyct.fsf@thuvia.hamartun.priv.no>
References: <alpine.BSF.2.21.1803170848420.819@aneurin.horsfall.org>
 <CABH=_VSEyOwDPr0wtnn2cQZ1tCQU+v_R4pBEg=-VeQVUxu6Jhw@mail.gmail.com>
 <CAC20D2POLKfgPefXSOECX3N5AKffxGKMjNJLi9pD-xWkX8Ffhg@mail.gmail.com>
 <CAEoi9W6_JLMubF0yM4dH+ep6DTHCia9X666kSQGPCuOodUR2LQ@mail.gmail.com>
 <CAC20D2PDOdvqv4-dGcNr7KTujE-aH7kAsUz+tspXZDhWPAix4w@mail.gmail.com>
 <CAC20D2Mtgr1Sbsbe7jxSL+r6FJ2cC3n+z1UtczmdH_kce-g64g@mail.gmail.com>
 <CABH=_VRs8OVAwYGuEbhSVVYy8L7dmxnkx-TmXnqafpzKZ-A5fg@mail.gmail.com>
 <CAC20D2NFfTNmD+OYa-7_RFF-WQmnwdBW-OXzNngKPJ-Qm=hQAg@mail.gmail.com>
 <6bc3b4da-08df-1a59-30b9-75d95541fdca@gmail.com>
 <m2y3insyct.fsf@thuvia.hamartun.priv.no>
Message-ID: <f67acfe3-5afe-9228-b8b3-26d86e559944@kilonet.net>

On 3/19/2018 2:40 PM, Tom Ivar Helbekkmo via TUHS wrote:
>
> VAX C was still pretty awful in the late 90s, while their FORTRAN was
> really excellent, not least because of the high quality optimizer.
>

I had a chance to try compiling a heavily-pthread'd queuing system I 
wrote, using VAX C on VMS 6.0+, actually running it on a VAXSTATION-3200.

I originally developed it on Sun Solaris, but with minimal compatibility 
issues, also ran on HP/UX, Linux, FreeBSD, etc.

It compiled on the VAX cleanly, needed some FIONBIO ioctl's (like 
FreeBSD) and ran suprisingly well for what it was. A 10Mbps NIC could 
only get so much data forced through it.

It could handle a few thousand threads before it became unusable, IIRC.

Good times.

ak






From a.phillip.garcia at gmail.com  Tue Mar 20 11:26:41 2018
From: a.phillip.garcia at gmail.com (A. P. Garcia)
Date: Mon, 19 Mar 2018 20:26:41 -0500
Subject: [TUHS] daemons are not to be exorcised
Message-ID: <CAFCBnZsS8Si6YGD4w_3W_znf3J5nVZGThkHVuQm5nD+FFm0DOg@mail.gmail.com>

Hi,

The Hacker's Dictionary says that daemons were so named in CTSS. I'm
guessing then that Ken Thompson brought them into Unix? I've noticed that
more recent implementations of init have shunned the traditional
terminology in favor of the more prosaic word "services". For example,
Solaris now has SMF, the Service Management Facility, and systemd, the
linux replacement for init, has services as well. It makes me a little sad,
because it feels like some of the imaginativeness, fancifulness, and
playfulness that imbue the Unix spirit are being lost.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180319/ebbb4e7c/attachment.html>

From dave at horsfall.org  Tue Mar 20 11:40:46 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Tue, 20 Mar 2018 12:40:46 +1100 (EST)
Subject: [TUHS] daemons are not to be exorcised
In-Reply-To: <CAFCBnZsS8Si6YGD4w_3W_znf3J5nVZGThkHVuQm5nD+FFm0DOg@mail.gmail.com>
References: <CAFCBnZsS8Si6YGD4w_3W_znf3J5nVZGThkHVuQm5nD+FFm0DOg@mail.gmail.com>
Message-ID: <alpine.BSF.2.21.1803201236120.36168@aneurin.horsfall.org>

On Mon, 19 Mar 2018, A. P. Garcia wrote:

> [...] It makes me a little sad, because it feels like some of the 
> imaginativeness, fancifulness, and playfulness that imbue the Unix 
> spirit are being lost.

Probably around the time that BUGS got renamed by the suits to something a 
little more marketoid-friendly?

(Still catching up on the Backus/Fortran thread, unless WKT shuts it down 
first, so no, I'm not ignoring anyone.)

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."


From maxigas at anargeek.net  Tue Mar 20 11:47:12 2018
From: maxigas at anargeek.net (maxigas)
Date: Tue, 20 Mar 2018 01:47:12 +0000
Subject: [TUHS] daemons are not to be exorcised
In-Reply-To: <CAFCBnZsS8Si6YGD4w_3W_znf3J5nVZGThkHVuQm5nD+FFm0DOg@mail.gmail.com>
References: <CAFCBnZsS8Si6YGD4w_3W_znf3J5nVZGThkHVuQm5nD+FFm0DOg@mail.gmail.com>
Message-ID: <878tanplgf.fsf@terra.i-did-not-set--mail-host-address--so-tickle-me>

"A. P. Garcia" <a.phillip.garcia at gmail.com> writes:

> The Hacker's Dictionary says that daemons were so named in CTSS. I'm
> guessing then that Ken Thompson brought them into Unix? I've noticed that
> more recent implementations of init have shunned the traditional
> terminology in favor of the more prosaic word "services". For example,
> Solaris now has SMF, the Service Management Facility, and systemd, the
> linux replacement for init, has services as well. It makes me a little sad,
> because it feels like some of the imaginativeness, fancifulness, and
> playfulness that imbue the Unix spirit are being lost.

Sweet and sour observation indeed.  I totally agree.  However, not all
is lost and there is some poetic justice in systemd being called
system-D, where the last letter still stands for a daemon.

-- 
Maxigas, kiberpunk
FA00 8129 13E9 2617 C614 0901 7879 63BC 287E D166
Lecturer in Critical Digital Media Practice
Center for Science Studies
Department of Sociology
Lancaster University

https://relay70.metatron.ai/

Unix is a Registered Bell of AT&T Trademark Laboratories. - Donn Seeley


From gtaylor at tnetconsulting.net  Tue Mar 20 14:23:01 2018
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Mon, 19 Mar 2018 22:23:01 -0600
Subject: [TUHS] daemons are not to be exorcised
In-Reply-To: <CAFCBnZsS8Si6YGD4w_3W_znf3J5nVZGThkHVuQm5nD+FFm0DOg@mail.gmail.com>
References: <CAFCBnZsS8Si6YGD4w_3W_znf3J5nVZGThkHVuQm5nD+FFm0DOg@mail.gmail.com>
Message-ID: <94366db0-293b-214a-23a3-c7c895e4d30b@spamtrap.tnetconsulting.net>

On 03/19/2018 07:26 PM, A. P. Garcia wrote:
> It makes me a little sad, because it feels like some of the 
> imaginativeness, fancifulness, and playfulness that imbue the Unix spirit 
> are being lost.

I feel like a lot of the Unix heritage is being lost, particularly in Linux.

Exorcise your demons and feed your daemons.



-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3982 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180319/1b00127e/attachment.bin>

From usotsuki at buric.co  Tue Mar 20 14:24:09 2018
From: usotsuki at buric.co (Steve Nickolas)
Date: Tue, 20 Mar 2018 00:24:09 -0400 (EDT)
Subject: [TUHS] daemons are not to be exorcised
In-Reply-To: <94366db0-293b-214a-23a3-c7c895e4d30b@spamtrap.tnetconsulting.net>
References: <CAFCBnZsS8Si6YGD4w_3W_znf3J5nVZGThkHVuQm5nD+FFm0DOg@mail.gmail.com>
 <94366db0-293b-214a-23a3-c7c895e4d30b@spamtrap.tnetconsulting.net>
Message-ID: <alpine.BSF.2.02.1803200023360.43136@frieza.hoshinet.org>

On Mon, 19 Mar 2018, Grant Taylor via TUHS wrote:

> On 03/19/2018 07:26 PM, A. P. Garcia wrote:
>> It makes me a little sad, because it feels like some of the 
>> imaginativeness, fancifulness, and playfulness that imbue the Unix spirit 
>> are being lost.
>
> I feel like a lot of the Unix heritage is being lost, particularly in Linux.
>
> Exorcise your demons and feed your daemons.

I think some people forget that Linux is *supposed* to act like Unix.

-uso.


From gtaylor at tnetconsulting.net  Tue Mar 20 14:40:44 2018
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Mon, 19 Mar 2018 22:40:44 -0600
Subject: [TUHS] daemons are not to be exorcised
In-Reply-To: <alpine.BSF.2.02.1803200023360.43136@frieza.hoshinet.org>
References: <CAFCBnZsS8Si6YGD4w_3W_znf3J5nVZGThkHVuQm5nD+FFm0DOg@mail.gmail.com>
 <94366db0-293b-214a-23a3-c7c895e4d30b@spamtrap.tnetconsulting.net>
 <alpine.BSF.2.02.1803200023360.43136@frieza.hoshinet.org>
Message-ID: <98451f10-9b1b-049b-61ed-fd73586572fd@spamtrap.tnetconsulting.net>

On 03/19/2018 10:24 PM, Steve Nickolas wrote:
> I think some people forget that Linux is *supposed* to act like Unix.

Well, I think that is the general idea.

At least the lower case "unix".  Maybe not any specific "Unix".  Things 
do grow / evolve / change over time.

I think many people working on Linux are genuinely trying to make it 
better.  They just have no conceptual history to guide them.

What's the saying?  Those who do not understand history are doomed to 
repeat it?  (For better or worse.)



-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3982 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180319/db94c406/attachment.bin>

From a.phillip.garcia at gmail.com  Tue Mar 20 15:19:12 2018
From: a.phillip.garcia at gmail.com (A. P. Garcia)
Date: Tue, 20 Mar 2018 00:19:12 -0500
Subject: [TUHS] daemons are not to be exorcised
In-Reply-To: <98451f10-9b1b-049b-61ed-fd73586572fd@spamtrap.tnetconsulting.net>
References: <CAFCBnZsS8Si6YGD4w_3W_znf3J5nVZGThkHVuQm5nD+FFm0DOg@mail.gmail.com>
 <94366db0-293b-214a-23a3-c7c895e4d30b@spamtrap.tnetconsulting.net>
 <alpine.BSF.2.02.1803200023360.43136@frieza.hoshinet.org>
 <98451f10-9b1b-049b-61ed-fd73586572fd@spamtrap.tnetconsulting.net>
Message-ID: <CAFCBnZs=krRCQASFOEia2LLQ4eDVrNGeyJzU1BA_CP=5aRXo4Q@mail.gmail.com>

On Mar 19, 2018 11:40 PM, "Grant Taylor via TUHS" <tuhs at minnie.tuhs.org>
wrote:

On 03/19/2018 10:24 PM, Steve Nickolas wrote:

> I think some people forget that Linux is *supposed* to act like Unix.
>

Well, I think that is the general idea.

At least the lower case "unix".  Maybe not any specific "Unix".  Things do
grow / evolve / change over time.

I think many people working on Linux are genuinely trying to make it
better.  They just have no conceptual history to guide them.

What's the saying?  Those who do not understand history are doomed to
repeat it?  (For better or worse.)

-- 
Grant. . . .
unix || die


Aye, and the script kitties seem to have won the war to commandeer the word
hacker.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180320/725ce56d/attachment.html>

From akosela at andykosela.com  Tue Mar 20 16:32:20 2018
From: akosela at andykosela.com (Andy Kosela)
Date: Tue, 20 Mar 2018 01:32:20 -0500
Subject: [TUHS] daemons are not to be exorcised
In-Reply-To: <94366db0-293b-214a-23a3-c7c895e4d30b@spamtrap.tnetconsulting.net>
References: <CAFCBnZsS8Si6YGD4w_3W_znf3J5nVZGThkHVuQm5nD+FFm0DOg@mail.gmail.com>
 <94366db0-293b-214a-23a3-c7c895e4d30b@spamtrap.tnetconsulting.net>
Message-ID: <CALMnNGhvdRccRjgHtKMUCh8h3reaPWLTJEVGpqcAe16CVOOLbQ@mail.gmail.com>

On Monday, March 19, 2018, Grant Taylor via TUHS <tuhs at minnie.tuhs.org>
wrote:

> On 03/19/2018 07:26 PM, A. P. Garcia wrote:
>
>> It makes me a little sad, because it feels like some of the
>> imaginativeness, fancifulness, and playfulness that imbue the Unix spirit
>> are being lost.
>>
>
> I feel like a lot of the Unix heritage is being lost, particularly in
> Linux.
>
> Exorcise your demons and feed your daemons.
>
>
I actually always liked the term 'dragons'.  This I believe came from MIT.

--Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180320/5e812581/attachment.html>

From cym224 at gmail.com  Tue Mar 20 22:31:55 2018
From: cym224 at gmail.com (Nemo)
Date: Tue, 20 Mar 2018 08:31:55 -0400
Subject: [TUHS] daemons are not to be exorcised
In-Reply-To: <94366db0-293b-214a-23a3-c7c895e4d30b@spamtrap.tnetconsulting.net>
References: <CAFCBnZsS8Si6YGD4w_3W_znf3J5nVZGThkHVuQm5nD+FFm0DOg@mail.gmail.com>
 <94366db0-293b-214a-23a3-c7c895e4d30b@spamtrap.tnetconsulting.net>
Message-ID: <CAJfiPzzVQuRj_FAbS-3ecq88L7QVbEcYQ-xKnmySHi2F_YLWhw@mail.gmail.com>

On 20/03/2018, Grant Taylor via TUHS <tuhs at minnie.tuhs.org> wrote:
> On 03/19/2018 07:26 PM, A. P. Garcia wrote:
>> It makes me a little sad, because it feels like some of the
>> imaginativeness, fancifulness, and playfulness that imbue the Unix spirit
>> are being lost.
>
> I feel like a lot of the Unix heritage is being lost, particularly in Linux.

Indeed, Wise Henry today would have written: Eschew the heresy that
all's the world Linux.  (And try building something such as llvm on a
UNIX box.)

> Exorcise your demons and feed your daemons.

There is a wonderful image with caption "/etc/init.d/daemon stop".
Easily found but I give no link because I cannot ascertain the
copyright.

N.

> --
> Grant. . . .
> unix || die


From paul.winalski at gmail.com  Wed Mar 21 03:42:22 2018
From: paul.winalski at gmail.com (Paul Winalski)
Date: Tue, 20 Mar 2018 13:42:22 -0400
Subject: [TUHS] FORTRAN
In-Reply-To: <e3c0e8ee-4b95-3661-1a5f-39d1aa6323f4@gmail.com>
References: <61051ebbca4809c08b60e92014851069e83a07f8@webmail.yaccman.com>
 <e3c0e8ee-4b95-3661-1a5f-39d1aa6323f4@gmail.com>
Message-ID: <CABH=_VToT+y25XBfsyYATAPNReZFKeT1Zh22f37O_PekuXZZkQ@mail.gmail.com>

Another bit of history of Fortran on UNIX:

DEC initially offered f77 on Ultrix, its commercial UNIX release for
the VAX.  When the decision to market Ultrix was made, our engineering
group, which developed the compiler and software development tools
suite for VAX/VMS, offered to port some of our products, including VAX
Fortran, to Ultrix.  The Ultrix engineering group fought the proposal
tooth and nail, and so we dropped the idea.

f77 was never taken very seriously by the Fortran user community,
whereas VAX Fortran was considered the gold standard for the language.
There were repeated calls from potential Ultrix customers for DEC to
make VAX Fortran available on that platform.  Eventually circa 1985
there was a panic rush project to port VAX Fortran to Ultrix.  It was
decided that, if we were to meet the short time-to-market goal,
modifying the VAX Fortran code generator to emit zmagic object files
was out of the question.  Instead, we would have it continue to
produce VMS object files, and we would port the VMS linker to Ultrix
and teach it to understand zmagic, stab-style debug information, and
ar archives.  I led the team that produced the lk linker, which could
take in either zmagic or VAX object files and produced a.out-style
images.  lk didn't implement some of the esoteric features of ld, but
it got the job done.  The Fortran RTL was shipped as VMS-style object
files.

One feature of VMS object files is that the name of the compiler that
produced them is recorded.  The lk linker reported this in the link
maps it produced.  VAX Fortran for Ultrix customers were rather
surprised to see the variety of languages (BLISS, Pascal, BASIC,
Fortran, assembler, etc.) that had been used to implement the Fortran
RTL.

-Paul W.


From ggm at algebras.org  Wed Mar 21 03:47:16 2018
From: ggm at algebras.org (George Michaelson)
Date: Tue, 20 Mar 2018 17:47:16 +0000
Subject: [TUHS] FORTRAN
In-Reply-To: <CABH=_VToT+y25XBfsyYATAPNReZFKeT1Zh22f37O_PekuXZZkQ@mail.gmail.com>
References: <61051ebbca4809c08b60e92014851069e83a07f8@webmail.yaccman.com>
 <e3c0e8ee-4b95-3661-1a5f-39d1aa6323f4@gmail.com>
 <CABH=_VToT+y25XBfsyYATAPNReZFKeT1Zh22f37O_PekuXZZkQ@mail.gmail.com>
Message-ID: <CAKr6gn31aWY7Zmi2mGffB-b3W3BinHfj1h1SqmgQyNww9n1RoQ@mail.gmail.com>

I have some sympathy with the compiler writers, because if you have
invested in passing compliance and test suites, to make code which NAG
will then be compiled through, somebody out there is going to use this
code to test the strain in a bridge (topical...) or something similar,
and when it fails under load because the loop terminated the way you
didn't expect, things are very ugly.

If you know your compiler is what you stand behind, it makes sense to
push for it to be the one adopted. The likelihood the linker causes
the problem feels lower.

Actually I think it was just not-invented-here, but I do have some sympathy.

-G

On Tue, Mar 20, 2018 at 5:42 PM, Paul Winalski <paul.winalski at gmail.com> wrote:
> Another bit of history of Fortran on UNIX:
>
> DEC initially offered f77 on Ultrix, its commercial UNIX release for
> the VAX.  When the decision to market Ultrix was made, our engineering
> group, which developed the compiler and software development tools
> suite for VAX/VMS, offered to port some of our products, including VAX
> Fortran, to Ultrix.  The Ultrix engineering group fought the proposal
> tooth and nail, and so we dropped the idea.
>
> f77 was never taken very seriously by the Fortran user community,
> whereas VAX Fortran was considered the gold standard for the language.
> There were repeated calls from potential Ultrix customers for DEC to
> make VAX Fortran available on that platform.  Eventually circa 1985
> there was a panic rush project to port VAX Fortran to Ultrix.  It was
> decided that, if we were to meet the short time-to-market goal,
> modifying the VAX Fortran code generator to emit zmagic object files
> was out of the question.  Instead, we would have it continue to
> produce VMS object files, and we would port the VMS linker to Ultrix
> and teach it to understand zmagic, stab-style debug information, and
> ar archives.  I led the team that produced the lk linker, which could
> take in either zmagic or VAX object files and produced a.out-style
> images.  lk didn't implement some of the esoteric features of ld, but
> it got the job done.  The Fortran RTL was shipped as VMS-style object
> files.
>
> One feature of VMS object files is that the name of the compiler that
> produced them is recorded.  The lk linker reported this in the link
> maps it produced.  VAX Fortran for Ultrix customers were rather
> surprised to see the variety of languages (BLISS, Pascal, BASIC,
> Fortran, assembler, etc.) that had been used to implement the Fortran
> RTL.
>
> -Paul W.


From paul.winalski at gmail.com  Wed Mar 21 03:48:02 2018
From: paul.winalski at gmail.com (Paul Winalski)
Date: Tue, 20 Mar 2018 13:48:02 -0400
Subject: [TUHS] daemons are not to be exorcised
In-Reply-To: <CAFCBnZsS8Si6YGD4w_3W_znf3J5nVZGThkHVuQm5nD+FFm0DOg@mail.gmail.com>
References: <CAFCBnZsS8Si6YGD4w_3W_znf3J5nVZGThkHVuQm5nD+FFm0DOg@mail.gmail.com>
Message-ID: <CABH=_VQ3w+XtR3Ow1m6g69828CTDY3SMduCNN-LevO_EZFKypg@mail.gmail.com>

On 3/19/18, A. P. Garcia <a.phillip.garcia at gmail.com> wrote:
>
> I've noticed that
> more recent implementations of init have shunned the traditional
> terminology in favor of the more prosaic word "services". For example,
> Solaris now has SMF, the Service Management Facility, and systemd, the
> linux replacement for init, has services as well. It makes me a little sad,
> because it feels like some of the imaginativeness, fancifulness, and
> playfulness that imbue the Unix spirit are being lost.
>
The term "daemon" doesn't go down very well with some Christians.  I
know of hackers wearing clothing depicting the BSD daemon being
hassled in Texas and other places in the deep South.  Replacing
"daemons" with "services" is probably a concession to the fundies.  I
agree it's rather sad.

-Paul W.


From ggm at algebras.org  Wed Mar 21 03:56:50 2018
From: ggm at algebras.org (George Michaelson)
Date: Tue, 20 Mar 2018 17:56:50 +0000
Subject: [TUHS] daemons are not to be exorcised
In-Reply-To: <CABH=_VQ3w+XtR3Ow1m6g69828CTDY3SMduCNN-LevO_EZFKypg@mail.gmail.com>
References: <CAFCBnZsS8Si6YGD4w_3W_znf3J5nVZGThkHVuQm5nD+FFm0DOg@mail.gmail.com>
 <CABH=_VQ3w+XtR3Ow1m6g69828CTDY3SMduCNN-LevO_EZFKypg@mail.gmail.com>
Message-ID: <CAKr6gn3nuFKhQ5cx124kiSuGi3Znbs3-zccpe5KGUn-o-bEcpw@mail.gmail.com>

we call them "busses" because back in the day, real electrical
engineers called any huge solid carrier of signal or power a bus line,
because it looked like the way trolly busses got their power.

I think daemon/demon came from printers demon, which is carved into
the government printing office in Brisbane. the printers demon is the
one which stuffed up letters in the tray, to make printers tear their
hair out. Did I say tray? I meant case, upper case, the one above,
with the big letters, and lower case, the case with the little
letters. oh dear. really? is that why they are cases?

data bus cables used to be the size of a moderate Dr Who Scarf, and
just as colourful. Now we're all settled on terahertz speed 2 wire
protocols or even one-wire, Its all a bit moot. At least we still talk
about the backplane, but usually now, its connecting the edge of a CPU
cluster, to the combination of power and a switch fabric. I dont think
people assume a computer spans more than one card any more, unless its
Intel struggling to fit the CPU on one chip, mounting two chips side
by side and then spreading the power budget into two lines on the bus.
Oh dear..

I got given the last generation PDP-11 on a chip, in a 72pin DIP. I
gave it to somebody else who could use it. At the time, I thought it
was Teh Awesome l33t to have an entire pdp11 on one chip. imagine! my
god, the power, the power. I think the day is coming when a CPU has
gold pins top and bottom. they have a very large number of pins.
Somebody smart will have to invent code to work out how to wire the
pins. Oh, hang on, thats why Djikstra's algorrithm which lies at the
heart of routing protocols was written back in the day. oh dear.. its
turtles all the way down isn't it?

On Tue, Mar 20, 2018 at 5:48 PM, Paul Winalski <paul.winalski at gmail.com> wrote:
> On 3/19/18, A. P. Garcia <a.phillip.garcia at gmail.com> wrote:
>>
>> I've noticed that
>> more recent implementations of init have shunned the traditional
>> terminology in favor of the more prosaic word "services". For example,
>> Solaris now has SMF, the Service Management Facility, and systemd, the
>> linux replacement for init, has services as well. It makes me a little sad,
>> because it feels like some of the imaginativeness, fancifulness, and
>> playfulness that imbue the Unix spirit are being lost.
>>
> The term "daemon" doesn't go down very well with some Christians.  I
> know of hackers wearing clothing depicting the BSD daemon being
> hassled in Texas and other places in the deep South.  Replacing
> "daemons" with "services" is probably a concession to the fundies.  I
> agree it's rather sad.
>
> -Paul W.


From crossd at gmail.com  Wed Mar 21 04:04:38 2018
From: crossd at gmail.com (Dan Cross)
Date: Tue, 20 Mar 2018 14:04:38 -0400
Subject: [TUHS] daemons are not to be exorcised
In-Reply-To: <CAKr6gn3nuFKhQ5cx124kiSuGi3Znbs3-zccpe5KGUn-o-bEcpw@mail.gmail.com>
References: <CAFCBnZsS8Si6YGD4w_3W_znf3J5nVZGThkHVuQm5nD+FFm0DOg@mail.gmail.com>
 <CABH=_VQ3w+XtR3Ow1m6g69828CTDY3SMduCNN-LevO_EZFKypg@mail.gmail.com>
 <CAKr6gn3nuFKhQ5cx124kiSuGi3Znbs3-zccpe5KGUn-o-bEcpw@mail.gmail.com>
Message-ID: <CAEoi9W66vwNnSSH8j2F5nYuo9T9MEjvDhzAwWodZ8ZA3nO2wMw@mail.gmail.com>

On Tue, Mar 20, 2018 at 1:56 PM, George Michaelson <ggm at algebras.org> wrote:

> we call them "busses" because back in the day, real electrical
> engineers called any huge solid carrier of signal or power a bus line,
> because it looked like the way trolly busses got their power.
>

THANK YOU! I have wondered about the etymology of the word "bus" in an
electrical context for YEARS.

I think daemon/demon came from printers demon, which is carved into
> the government printing office in Brisbane. the printers demon is the
> one which stuffed up letters in the tray, to make printers tear their
> hair out. Did I say tray? I meant case, upper case, the one above,
> with the big letters, and lower case, the case with the little
> letters. oh dear. really? is that why they are cases?
>

While this story (and the others I trimmed for brevity) is (are) great,
"daemon" is actually from the Greek, I believe: an intermediary between
humans (users) and the gods (the kernel).

        - Dan C.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180320/653118ca/attachment.html>

From crossd at gmail.com  Wed Mar 21 04:15:04 2018
From: crossd at gmail.com (Dan Cross)
Date: Tue, 20 Mar 2018 14:15:04 -0400
Subject: [TUHS] FORTRAN
In-Reply-To: <61051ebbca4809c08b60e92014851069e83a07f8@webmail.yaccman.com>
References: <CAC20D2P-dNX8AM_mh5N+Th-VYsG9COP8PX8QufLmFE2zh7MUqw@mail.gmail.com>
 <61051ebbca4809c08b60e92014851069e83a07f8@webmail.yaccman.com>
Message-ID: <CAEoi9W6kLW5U-=kycN_8Orp228XZfFBv=88xzgam=76AWcJV3w@mail.gmail.com>

On Mon, Mar 19, 2018 at 12:58 PM, Steve Johnson <scj at yaccman.com> wrote:

> [...]
> So the point is, FORTRAN was dominant at Bell Labs for most of the time
> that C was being developed.  There was a group that was pushing the
> adoption of PL/1, being used to code Multics, but the compiler was late and
> not very good and it never really caught on.  The GE compiler was one of
> the three that I abstracted the machine independent code from for PCC (the
> other two were PDP-11 and IBM 360).
>
[...]
>

Thanks Steve.

Ok, so if we take a step back, could it be said that one of the reasons for
the initial scuttled attempt at Fortran as a Unix systems programming
language was that it was the local "language of record" at the time? I'm
curious how far the effort got...was it just the proverbial cat reading the
paper, "I should really do a Fortran dialect..." or was there actual code?
Did anything survive into the modern era?

        - Dan C.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180320/42cd3b35/attachment.html>

From bakul at bitblocks.com  Wed Mar 21 04:24:30 2018
From: bakul at bitblocks.com (Bakul Shah)
Date: Tue, 20 Mar 2018 11:24:30 -0700
Subject: [TUHS] daemons are not to be exorcised
In-Reply-To: Your message of "Tue, 20 Mar 2018 14:04:38 -0400."
 <CAEoi9W66vwNnSSH8j2F5nYuo9T9MEjvDhzAwWodZ8ZA3nO2wMw@mail.gmail.com>
References: <CAFCBnZsS8Si6YGD4w_3W_znf3J5nVZGThkHVuQm5nD+FFm0DOg@mail.gmail.com>
 <CABH=_VQ3w+XtR3Ow1m6g69828CTDY3SMduCNN-LevO_EZFKypg@mail.gmail.com>
 <CAKr6gn3nuFKhQ5cx124kiSuGi3Znbs3-zccpe5KGUn-o-bEcpw@mail.gmail.com>
 <CAEoi9W66vwNnSSH8j2F5nYuo9T9MEjvDhzAwWodZ8ZA3nO2wMw@mail.gmail.com>
Message-ID: <20180320182445.5BBA8156E510@mail.bitblocks.com>

On Tue, 20 Mar 2018 14:04:38 -0400 Dan Cross <crossd at gmail.com> wrote:
Dan Cross writes:
> 
> On Tue, Mar 20, 2018 at 1:56 PM, George Michaelson <ggm at algebras.org> wrote:
> 
> I think daemon/demon came from printers demon, which is carved into
> > the government printing office in Brisbane. the printers demon is the
> > one which stuffed up letters in the tray, to make printers tear their
> > hair out. Did I say tray? I meant case, upper case, the one above,
> > with the big letters, and lower case, the case with the little
> > letters. oh dear. really? is that why they are cases?
> >
> 
> While this story (and the others I trimmed for brevity) is (are) great,
> "daemon" is actually from the Greek, I believe: an intermediary between
> humans (users) and the gods (the kernel).

>From http://ei.cs.vt.edu/~history/Daemon.html

  Fernando J. Corbato: ... Our use of the word daemon (@
  Project MAC in 1963) was inspired by the Maxwell's daemon of
  physics and thermodynamics. (My background is Physics.)
  Maxwell's daemon was an imaginary agent which helped sort
  molecules of different speeds and worked tirelessly in the
  background. We fancifully began to use the word daemon to
  describe background processes which worked tirelessly to
  perform system chores.


From clemc at ccc.com  Wed Mar 21 04:46:00 2018
From: clemc at ccc.com (Clem Cole)
Date: Tue, 20 Mar 2018 14:46:00 -0400
Subject: [TUHS] daemons are not to be exorcised
In-Reply-To: <20180320182445.5BBA8156E510@mail.bitblocks.com>
References: <CAFCBnZsS8Si6YGD4w_3W_znf3J5nVZGThkHVuQm5nD+FFm0DOg@mail.gmail.com>
 <CABH=_VQ3w+XtR3Ow1m6g69828CTDY3SMduCNN-LevO_EZFKypg@mail.gmail.com>
 <CAKr6gn3nuFKhQ5cx124kiSuGi3Znbs3-zccpe5KGUn-o-bEcpw@mail.gmail.com>
 <CAEoi9W66vwNnSSH8j2F5nYuo9T9MEjvDhzAwWodZ8ZA3nO2wMw@mail.gmail.com>
 <20180320182445.5BBA8156E510@mail.bitblocks.com>
Message-ID: <CAC20D2Mez9m17ov=MFVKnqB8biEkTJqd8jDOQCDiRqQwduX8mw@mail.gmail.com>

On Tue, Mar 20, 2018 at 2:24 PM, Bakul Shah <bakul at bitblocks.com> wrote:

> On Tue, 20 Mar 2018 14:04:38 -0400 Dan Cross <crossd at gmail.com> wrote:
> Dan Cross writes:
> >
> > On Tue, Mar 20, 2018 at 1:56 PM, George Michaelson <ggm at algebras.org>
> wrote:
> >
> > I think daemon/demon came from printers demon, which is carved into
> > > the government printing office in Brisbane. the printers demon is the
> > > one which stuffed up letters in the tray, to make printers tear their
> > > hair out. Did I say tray? I meant case, upper case, the one above,
> > > with the big letters, and lower case, the case with the little
> > > letters. oh dear. really? is that why they are cases?
> > >
> >
> > While this story (and the others I trimmed for brevity) is (are) great,
> > "daemon" is actually from the Greek, I believe: an intermediary between
> > humans (users) and the gods (the kernel).
>
> From http://ei.cs.vt.edu/~history/Daemon.html
>
>   Fernando J. Corbato: ... Our use of the word daemon (@
>   Project MAC in 1963) was inspired by the Maxwell's daemon of
>   physics and thermodynamics. (My background is Physics.)
>   Maxwell's daemon was an imaginary agent which helped sort
>   molecules of different speeds and worked tirelessly in the
>   background. We fancifully began to use the word daemon to
>   describe background processes which worked tirelessly to
> ​​
>
>   perform system chores.
>


​Right -- that is what I was under the impression from where the term came
for computer use.   Although, I was also under  the impression that Maxwell
had taken the term from ideas from some his Cambridge colleagues that were
working on human thought and described the ideas of these daemons running
around in your head supporting things like vision, hearing and your other
senses.   The later was formalized I believe years later by Oliver
Suthridge (IIRC my Cog Psych of many years ago) - into the something like
the Pandemonium model of cognition.

i.e. I think the term was used first in Cognition, then to Physics and
finally to Computers.

As for Paul's comment about the daemons.  Yes, Kirk McKusick who actually
drew the original BSD daemon with purple sneakers, was wearing the infamous
blue tee with said logo out walking on the street, as one someone else in
the party (maybe Sam Leffler) sporting a 10 anniversary USENIX shirt in San
Antonio many years ago, which has the daemons shown top of a PDP-11 with
pipes, the null device, *et al*.   He has quite a tale of the experience.

Clem





ᐧ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180320/80d92bda/attachment.html>

From toby at telegraphics.com.au  Wed Mar 21 04:53:46 2018
From: toby at telegraphics.com.au (Toby Thain)
Date: Tue, 20 Mar 2018 14:53:46 -0400
Subject: [TUHS] daemons are not to be exorcised
In-Reply-To: <20180320182445.5BBA8156E510@mail.bitblocks.com>
References: <CAFCBnZsS8Si6YGD4w_3W_znf3J5nVZGThkHVuQm5nD+FFm0DOg@mail.gmail.com>
 <CABH=_VQ3w+XtR3Ow1m6g69828CTDY3SMduCNN-LevO_EZFKypg@mail.gmail.com>
 <CAKr6gn3nuFKhQ5cx124kiSuGi3Znbs3-zccpe5KGUn-o-bEcpw@mail.gmail.com>
 <CAEoi9W66vwNnSSH8j2F5nYuo9T9MEjvDhzAwWodZ8ZA3nO2wMw@mail.gmail.com>
 <20180320182445.5BBA8156E510@mail.bitblocks.com>
Message-ID: <aed5ca46-d74f-440d-091c-5ab8a77f0229@telegraphics.com.au>

On 2018-03-20 2:24 PM, Bakul Shah wrote:
> On Tue, 20 Mar 2018 14:04:38 -0400 Dan Cross <crossd at gmail.com> wrote:
> Dan Cross writes:
>>
>> On Tue, Mar 20, 2018 at 1:56 PM, George Michaelson <ggm at algebras.org> wrote:
>>
>> I think daemon/demon came from printers demon, which is carved into
>>> the government printing office in Brisbane. the printers demon is the
>>> one which stuffed up letters in the tray, to make printers tear their
>>> hair out. Did I say tray? I meant case, upper case, the one above,
>>> with the big letters, and lower case, the case with the little
>>> letters. oh dear. really? is that why they are cases?
>>>
>>
>> While this story (and the others I trimmed for brevity) is (are) great,
>> "daemon" is actually from the Greek, I believe: an intermediary between
>> humans (users) and the gods (the kernel).
> 
>>From http://ei.cs.vt.edu/~history/Daemon.html
> 
>   Fernando J. Corbato: ... Our use of the word daemon (@
>   Project MAC in 1963) was inspired by the Maxwell's daemon of
>   physics and thermodynamics. (My background is Physics.)
>   Maxwell's daemon was an imaginary agent which helped sort
>   molecules of different speeds and worked tirelessly in the
>   background. We fancifully began to use the word daemon to
>   describe background processes which worked tirelessly to
>   perform system chores.
> 

OK, but where did Maxwell get it? :-)


From bakul at bitblocks.com  Wed Mar 21 05:10:37 2018
From: bakul at bitblocks.com (Bakul Shah)
Date: Tue, 20 Mar 2018 12:10:37 -0700
Subject: [TUHS] daemons are not to be exorcised
In-Reply-To: <CAC20D2Mez9m17ov=MFVKnqB8biEkTJqd8jDOQCDiRqQwduX8mw@mail.gmail.com>
References: <CAFCBnZsS8Si6YGD4w_3W_znf3J5nVZGThkHVuQm5nD+FFm0DOg@mail.gmail.com>
 <CABH=_VQ3w+XtR3Ow1m6g69828CTDY3SMduCNN-LevO_EZFKypg@mail.gmail.com>
 <CAKr6gn3nuFKhQ5cx124kiSuGi3Znbs3-zccpe5KGUn-o-bEcpw@mail.gmail.com>
 <CAEoi9W66vwNnSSH8j2F5nYuo9T9MEjvDhzAwWodZ8ZA3nO2wMw@mail.gmail.com>
 <20180320182445.5BBA8156E510@mail.bitblocks.com>
 <CAC20D2Mez9m17ov=MFVKnqB8biEkTJqd8jDOQCDiRqQwduX8mw@mail.gmail.com>
Message-ID: <FD580007-FBFA-4718-95DE-6AB55C4D7BEF@bitblocks.com>

On Mar 20, 2018, at 11:46 AM, Clem Cole <clemc at ccc.com> wrote:
> 
> On Tue, Mar 20, 2018 at 2:24 PM, Bakul Shah <bakul at bitblocks.com> wrote:
> On Tue, 20 Mar 2018 14:04:38 -0400 Dan Cross <crossd at gmail.com> wrote:
> Dan Cross writes:
> >
> > On Tue, Mar 20, 2018 at 1:56 PM, George Michaelson <ggm at algebras.org> wrote:
> >
> > I think daemon/demon came from printers demon, which is carved into
> > > the government printing office in Brisbane. the printers demon is the
> > > one which stuffed up letters in the tray, to make printers tear their
> > > hair out. Did I say tray? I meant case, upper case, the one above,
> > > with the big letters, and lower case, the case with the little
> > > letters. oh dear. really? is that why they are cases?
> > >
> >
> > While this story (and the others I trimmed for brevity) is (are) great,
> > "daemon" is actually from the Greek, I believe: an intermediary between
> > humans (users) and the gods (the kernel).
> 
> From http://ei.cs.vt.edu/~history/Daemon.html
> 
>   Fernando J. Corbato: ... Our use of the word daemon (@
>   Project MAC in 1963) was inspired by the Maxwell's daemon of
>   physics and thermodynamics. (My background is Physics.)
>   Maxwell's daemon was an imaginary agent which helped sort
>   molecules of different speeds and worked tirelessly in the
>   background. We fancifully began to use the word daemon to
>   describe background processes which worked tirelessly to​​
>   perform system chores.
> 
> 
> ​Right -- that is what I was under the impression from where the term came for computer use.   Although, I was also under  the impression that Maxwell had taken the term from ideas from some his Cambridge colleagues that were working on human thought and described the ideas of these daemons running around in your head supporting things like vision, hearing and your other senses.   The later was formalized I believe years later by Oliver Suthridge (IIRC my Cog Psych of many years ago) - into the something like the Pandemonium model of cognition.

This origin must've been better known 30+ years back because I
remembered this as well. To check I first looked at the Wikipedia
entry for Maxwell's demons (I learned new facts but also confused
myself as I couldn't see the connection).

As to where Maxwell got his demons, see
https://archive.org/stream/lifescientificwo00knotuoft#page/212/mode/2up
and page 214 as well:

  Maxwell constructed the following Catechism:
  
    "Concerning demons.
    "1. Who gave them this name? Thomson
    "2. What were they by nature? Very small BUT lively beings incapable of 
        doing work but also able to open and shut valves which move without
        friction or inertia.
    etc.


> i.e. I think the term was used first in Cognition, then to Physics and finally to Computers.
> 
> As for Paul's comment about the daemons.  Yes, Kirk McKusick who actually drew the original BSD daemon with purple sneakers, was wearing the infamous blue tee with said logo out walking on the street, as one someone else in the party (maybe Sam Leffler) sporting a 10 anniversary USENIX shirt in San Antonio many years ago, which has the daemons shown top of a PDP-11 with pipes, the null device, et al.   He has quite a tale of the experience.

BSD's daemon is much cuter than that damned nemesis of Batman :-)

From cym224 at gmail.com  Wed Mar 21 05:24:51 2018
From: cym224 at gmail.com (Nemo Nusquam)
Date: Tue, 20 Mar 2018 15:24:51 -0400
Subject: [TUHS] daemons are not to be exorcised
In-Reply-To: <CAEoi9W66vwNnSSH8j2F5nYuo9T9MEjvDhzAwWodZ8ZA3nO2wMw@mail.gmail.com>
References: <CAFCBnZsS8Si6YGD4w_3W_znf3J5nVZGThkHVuQm5nD+FFm0DOg@mail.gmail.com>
 <CABH=_VQ3w+XtR3Ow1m6g69828CTDY3SMduCNN-LevO_EZFKypg@mail.gmail.com>
 <CAKr6gn3nuFKhQ5cx124kiSuGi3Znbs3-zccpe5KGUn-o-bEcpw@mail.gmail.com>
 <CAEoi9W66vwNnSSH8j2F5nYuo9T9MEjvDhzAwWodZ8ZA3nO2wMw@mail.gmail.com>
Message-ID: <306c2237-0522-b346-e4ea-14d41c33600f@gmail.com>

On 03/20/18 14:04, Dan Cross wrote:
> On Tue, Mar 20, 2018 at 1:56 PM, George Michaelson <ggm at algebras.org
> <mailto:ggm at algebras.org>> wrote:
>
>     we call them "busses" because back in the day, real electrical
>     engineers called any huge solid carrier of signal or power a bus line,
>     because it looked like the way trolly busses got their power.
>
>
> THANK YOU! I have wondered about the etymology of the word "bus" in an
> electrical context for YEARS.

I thought they were written buss lines until IBM started dropping an 's'.

N.


From ron at ronnatalie.com  Wed Mar 21 05:55:36 2018
From: ron at ronnatalie.com (Ron Natalie)
Date: Tue, 20 Mar 2018 15:55:36 -0400
Subject: [TUHS] FORTRAN
In-Reply-To: <CAEoi9W6kLW5U-=kycN_8Orp228XZfFBv=88xzgam=76AWcJV3w@mail.gmail.com>
References: <CAC20D2P-dNX8AM_mh5N+Th-VYsG9COP8PX8QufLmFE2zh7MUqw@mail.gmail.com>
 <61051ebbca4809c08b60e92014851069e83a07f8@webmail.yaccman.com>
 <CAEoi9W6kLW5U-=kycN_8Orp228XZfFBv=88xzgam=76AWcJV3w@mail.gmail.com>
Message-ID: <002f01d3c085$6b5a26d0$420e7470$@ronnatalie.com>

Having worked on system programming for UNIX and a few of the PDP-11 DEC OS’s (DOS, RT, RSX, and in passing RSTS), I can tell you Fortran was abhorrent.

Sure it was the only high-level language I had on the RT and RSX systems, but its character handling was awful.    I ended up writing almost all that stuff in assembler

(which fortunately the PDP-11 is wonderful for).

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180320/e88c9b9a/attachment.html>

From crossd at gmail.com  Wed Mar 21 05:55:10 2018
From: crossd at gmail.com (Dan Cross)
Date: Tue, 20 Mar 2018 15:55:10 -0400
Subject: [TUHS] daemons are not to be exorcised
In-Reply-To: <FD580007-FBFA-4718-95DE-6AB55C4D7BEF@bitblocks.com>
References: <CAFCBnZsS8Si6YGD4w_3W_znf3J5nVZGThkHVuQm5nD+FFm0DOg@mail.gmail.com>
 <CABH=_VQ3w+XtR3Ow1m6g69828CTDY3SMduCNN-LevO_EZFKypg@mail.gmail.com>
 <CAKr6gn3nuFKhQ5cx124kiSuGi3Znbs3-zccpe5KGUn-o-bEcpw@mail.gmail.com>
 <CAEoi9W66vwNnSSH8j2F5nYuo9T9MEjvDhzAwWodZ8ZA3nO2wMw@mail.gmail.com>
 <20180320182445.5BBA8156E510@mail.bitblocks.com>
 <CAC20D2Mez9m17ov=MFVKnqB8biEkTJqd8jDOQCDiRqQwduX8mw@mail.gmail.com>
 <FD580007-FBFA-4718-95DE-6AB55C4D7BEF@bitblocks.com>
Message-ID: <CAEoi9W6uTYvG0KxnegUFyb-a0ckz=eeY4aow9R1MnkYUgP3eFw@mail.gmail.com>

On Tue, Mar 20, 2018 at 3:10 PM, Bakul Shah <bakul at bitblocks.com> wrote:

> On Mar 20, 2018, at 11:46 AM, Clem Cole <clemc at ccc.com> wrote:
> >
> > On Tue, Mar 20, 2018 at 2:24 PM, Bakul Shah <bakul at bitblocks.com> wrote:
> > On Tue, 20 Mar 2018 14:04:38 -0400 Dan Cross <crossd at gmail.com> wrote:
> > Dan Cross writes:
> > >
> > > On Tue, Mar 20, 2018 at 1:56 PM, George Michaelson <ggm at algebras.org>
> wrote:
> > >
> > > I think daemon/demon came from printers demon, which is carved into
> > > > the government printing office in Brisbane. the printers demon is the
> > > > one which stuffed up letters in the tray, to make printers tear their
> > > > hair out. Did I say tray? I meant case, upper case, the one above,
> > > > with the big letters, and lower case, the case with the little
> > > > letters. oh dear. really? is that why they are cases?
> > > >
> > >
> > > While this story (and the others I trimmed for brevity) is (are) great,
> > > "daemon" is actually from the Greek, I believe: an intermediary between
> > > humans (users) and the gods (the kernel).
> >
> > From http://ei.cs.vt.edu/~history/Daemon.html
> >
> >   Fernando J. Corbato: ... Our use of the word daemon (@
> >   Project MAC in 1963) was inspired by the Maxwell's daemon of
> >   physics and thermodynamics. (My background is Physics.)
> >   Maxwell's daemon was an imaginary agent which helped sort
> >   molecules of different speeds and worked tirelessly in the
> >   background. We fancifully began to use the word daemon to
> >   describe background processes which worked tirelessly to​​
> >   perform system chores.
> >
> >
> > ​Right -- that is what I was under the impression from where the term
> came for computer use.   Although, I was also under  the impression that
> Maxwell had taken the term from ideas from some his Cambridge colleagues
> that were working on human thought and described the ideas of these daemons
> running around in your head supporting things like vision, hearing and your
> other senses.   The later was formalized I believe years later by Oliver
> Suthridge (IIRC my Cog Psych of many years ago) - into the something like
> the Pandemonium model of cognition.
>
> This origin must've been better known 30+ years back because I
> remembered this as well. To check I first looked at the Wikipedia
> entry for Maxwell's demons (I learned new facts but also confused
> myself as I couldn't see the connection).
>
> As to where Maxwell got his demons, see
> https://archive.org/stream/lifescientificwo00knotuoft#page/212/mode/2up
> and page 214 as well:
>

Oh how interesting.

Of note Maxwell's first quoted letter describes the theory in terms of
"finite beings"; Wikipedia claims it was Lord Kelvin who first labeled them
"demons" in a paper published in the journal "Nature" in 1879 (citation
here: https://www.nature.com/articles/020126a0; full text here:
https://zapatopi.net/kelvin/papers/the_sorting_demon_of_maxwell.html) and
that seems to be backed up by what you quoted below:

  Maxwell constructed the following Catechism:
>
>     "Concerning demons.
>     "1. Who gave them this name? Thomson
>     "2. What were they by nature? Very small BUT lively beings incapable of
>         doing work but also able to open and shut valves which move without
>         friction or inertia.
>     etc.


Here, Maxwell seems to be corresponding with Thomson in 1867 but it is not
until more than a decade later Thomson writes his nature article which
clearly associates the concept with to the Greek notion. Kelvin's
article seems to be describing a lecture, and further seems to imply that
the concept was ideas recognized -- at least in scientific circles, by 1879.

Anyway, by his own admission Corbato came into contact with the concept via
physics and uses it on Multics to describe programs doing more or less what
any of us would think of a "daemon" doing, and from there it went into
Unix. I wonder where the archaic spelling came from.

So it does come from the Greek notion, albeit in a roundabout fashion. Does
that seem accurate?

> i.e. I think the term was used first in Cognition, then to Physics and
> finally to Computers.
> >
> > As for Paul's comment about the daemons.  Yes, Kirk McKusick who
> actually drew the original BSD daemon with purple sneakers, was wearing the
> infamous blue tee with said logo out walking on the street, as one someone
> else in the party (maybe Sam Leffler) sporting a 10 anniversary USENIX
> shirt in San Antonio many years ago, which has the daemons shown top of a
> PDP-11 with pipes, the null device, et al.   He has quite a tale of the
> experience.
>
> BSD's daemon is much cuter than that damned nemesis of Batman :-)


I'm mildly surprised that such a thing would happen in San Antonio, which
is a bit more cosmopolitan than much of the rest of Texas. But only mildly.

        - Dan C.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180320/a1f2534c/attachment.html>

From tfb at tfeb.org  Wed Mar 21 05:56:13 2018
From: tfb at tfeb.org (Tim Bradshaw)
Date: Tue, 20 Mar 2018 19:56:13 +0000
Subject: [TUHS] daemons are not to be exorcised
In-Reply-To: <CAC20D2Mez9m17ov=MFVKnqB8biEkTJqd8jDOQCDiRqQwduX8mw@mail.gmail.com>
References: <CAFCBnZsS8Si6YGD4w_3W_znf3J5nVZGThkHVuQm5nD+FFm0DOg@mail.gmail.com>
 <CABH=_VQ3w+XtR3Ow1m6g69828CTDY3SMduCNN-LevO_EZFKypg@mail.gmail.com>
 <CAKr6gn3nuFKhQ5cx124kiSuGi3Znbs3-zccpe5KGUn-o-bEcpw@mail.gmail.com>
 <CAEoi9W66vwNnSSH8j2F5nYuo9T9MEjvDhzAwWodZ8ZA3nO2wMw@mail.gmail.com>
 <20180320182445.5BBA8156E510@mail.bitblocks.com>
 <CAC20D2Mez9m17ov=MFVKnqB8biEkTJqd8jDOQCDiRqQwduX8mw@mail.gmail.com>
Message-ID: <4B8624EE-EB25-4029-8C35-8F8266107D2C@tfeb.org>

This seems like an unduly complicated theory.  Maxwell had a good 19th-century Scottish gentleman's education (he knew great chunks of Paradise Lost by heart as a child) and he would have been far more familiar with classical literature than most scientists are today as a result.  Chances are he knew what daemons were in mythology because he'd  read either the Greek originals or Latin translations at school & university.

Even today the term can be used without the connotations of evil that it often has: His Dark Materials has daemons which are not in any way evil.  Perhaps significantly it is heavily influenced by Paradise Lost as well: perhaps the common source is that.  I have a copy but I haven't read it, sadly.

> On 20 Mar 2018, at 18:46, Clem Cole <clemc at ccc.com> wrote:
> 
> 
> 
>> On Tue, Mar 20, 2018 at 2:24 PM, Bakul Shah <bakul at bitblocks.com> wrote:
>> On Tue, 20 Mar 2018 14:04:38 -0400 Dan Cross <crossd at gmail.com> wrote:
>> Dan Cross writes:
>> >
>> > On Tue, Mar 20, 2018 at 1:56 PM, George Michaelson <ggm at algebras.org> wrote:
>> >
>> > I think daemon/demon came from printers demon, which is carved into
>> > > the government printing office in Brisbane. the printers demon is the
>> > > one which stuffed up letters in the tray, to make printers tear their
>> > > hair out. Did I say tray? I meant case, upper case, the one above,
>> > > with the big letters, and lower case, the case with the little
>> > > letters. oh dear. really? is that why they are cases?
>> > >
>> >
>> > While this story (and the others I trimmed for brevity) is (are) great,
>> > "daemon" is actually from the Greek, I believe: an intermediary between
>> > humans (users) and the gods (the kernel).
>> 
>> From http://ei.cs.vt.edu/~history/Daemon.html
>> 
>>   Fernando J. Corbato: ... Our use of the word daemon (@
>>   Project MAC in 1963) was inspired by the Maxwell's daemon of
>>   physics and thermodynamics. (My background is Physics.)
>>   Maxwell's daemon was an imaginary agent which helped sort
>>   molecules of different speeds and worked tirelessly in the
>>   background. We fancifully began to use the word daemon to
>>   describe background processes which worked tirelessly to​​
>>   perform system chores.
> 
> 
> ​Right -- that is what I was under the impression from where the term came for computer use.   Although, I was also under  the impression that Maxwell had taken the term from ideas from some his Cambridge colleagues that were working on human thought and described the ideas of these daemons running around in your head supporting things like vision, hearing and your other senses.   The later was formalized I believe years later by Oliver Suthridge (IIRC my Cog Psych of many years ago) - into the something like the Pandemonium model of cognition.
> 
> i.e. I think the term was used first in Cognition, then to Physics and finally to Computers.
> 
> As for Paul's comment about the daemons.  Yes, Kirk McKusick who actually drew the original BSD daemon with purple sneakers, was wearing the infamous blue tee with said logo out walking on the street, as one someone else in the party (maybe Sam Leffler) sporting a 10 anniversary USENIX shirt in San Antonio many years ago, which has the daemons shown top of a PDP-11 with pipes, the null device, et al.   He has quite a tale of the experience.
> 
> Clem
> 
> 
> 
> 
> 
> ᐧ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180320/5dbfc37d/attachment.html>

From wkt at tuhs.org  Wed Mar 21 06:14:41 2018
From: wkt at tuhs.org (Warren Toomey)
Date: Wed, 21 Mar 2018 06:14:41 +1000
Subject: [TUHS] daemons are not to be exorcised
In-Reply-To: <CAC20D2Mez9m17ov=MFVKnqB8biEkTJqd8jDOQCDiRqQwduX8mw@mail.gmail.com>
References: <CAFCBnZsS8Si6YGD4w_3W_znf3J5nVZGThkHVuQm5nD+FFm0DOg@mail.gmail.com>
 <CABH=_VQ3w+XtR3Ow1m6g69828CTDY3SMduCNN-LevO_EZFKypg@mail.gmail.com>
 <CAKr6gn3nuFKhQ5cx124kiSuGi3Znbs3-zccpe5KGUn-o-bEcpw@mail.gmail.com>
 <CAEoi9W66vwNnSSH8j2F5nYuo9T9MEjvDhzAwWodZ8ZA3nO2wMw@mail.gmail.com>
 <20180320182445.5BBA8156E510@mail.bitblocks.com>
 <CAC20D2Mez9m17ov=MFVKnqB8biEkTJqd8jDOQCDiRqQwduX8mw@mail.gmail.com>
Message-ID: <20180320201441.GA28553@minnie.tuhs.org>

On Tue, Mar 20, 2018 at 02:46:00PM -0400, Clem Cole wrote:
>   As for Paul's comment about the daemons.  Yes, Kirk McKusick who
>   actually drew the original BSD daemon with purple sneakers, was wearing
>   the infamous blue tee with said logo out walking on the street, as one
>   someone else in the party (maybe Sam Leffler) sporting a 10 anniversary
>   USENIX shirt in San Antonio many years ago, which has the daemons shown
>   top of a PDP-11 with pipes, the null device, et al.   He has quite a
>   tale of the experience.

The daemons on the PDP-11 with pipes was drawn by Phil Foglio:
https://www.mckusick.com/beastie/shirts/usenix.html

and this image was the inspiration for the BSD daemon.

Cheers, Warren


From paul.winalski at gmail.com  Wed Mar 21 06:21:12 2018
From: paul.winalski at gmail.com (Paul Winalski)
Date: Tue, 20 Mar 2018 16:21:12 -0400
Subject: [TUHS] FORTRAN
In-Reply-To: <002f01d3c085$6b5a26d0$420e7470$@ronnatalie.com>
References: <CAC20D2P-dNX8AM_mh5N+Th-VYsG9COP8PX8QufLmFE2zh7MUqw@mail.gmail.com>
 <61051ebbca4809c08b60e92014851069e83a07f8@webmail.yaccman.com>
 <CAEoi9W6kLW5U-=kycN_8Orp228XZfFBv=88xzgam=76AWcJV3w@mail.gmail.com>
 <002f01d3c085$6b5a26d0$420e7470$@ronnatalie.com>
Message-ID: <CABH=_VSjLP1XRVa6MG-q_nCyNRMqF8iKSrt8o5Tu-e+615zDMQ@mail.gmail.com>

On 3/20/18, Ron Natalie <ron at ronnatalie.com> wrote:
> Having worked on system programming for UNIX and a few of the PDP-11 DEC
> OS’s (DOS, RT, RSX, and in passing RSTS), I can tell you Fortran was
> abhorrent.
>
Yes, Fortran is as awful for system programming as C is for numeric
programming that involves throwing multidimensional arrays around.
Screwdrivers always make bad hammers.

-Paul W.


From paul.winalski at gmail.com  Wed Mar 21 06:25:06 2018
From: paul.winalski at gmail.com (Paul Winalski)
Date: Tue, 20 Mar 2018 16:25:06 -0400
Subject: [TUHS] daemons are not to be exorcised
In-Reply-To: <20180320201441.GA28553@minnie.tuhs.org>
References: <CAFCBnZsS8Si6YGD4w_3W_znf3J5nVZGThkHVuQm5nD+FFm0DOg@mail.gmail.com>
 <CABH=_VQ3w+XtR3Ow1m6g69828CTDY3SMduCNN-LevO_EZFKypg@mail.gmail.com>
 <CAKr6gn3nuFKhQ5cx124kiSuGi3Znbs3-zccpe5KGUn-o-bEcpw@mail.gmail.com>
 <CAEoi9W66vwNnSSH8j2F5nYuo9T9MEjvDhzAwWodZ8ZA3nO2wMw@mail.gmail.com>
 <20180320182445.5BBA8156E510@mail.bitblocks.com>
 <CAC20D2Mez9m17ov=MFVKnqB8biEkTJqd8jDOQCDiRqQwduX8mw@mail.gmail.com>
 <20180320201441.GA28553@minnie.tuhs.org>
Message-ID: <CABH=_VS2J9ExMiqMUfr7JDRDirvYxfaL+-dwhthc5tP3idW2mQ@mail.gmail.com>

TOPS-10 had daemons (file daemon, for example).  Does the TOPS-10
usage of the term predate or postdate its use in Unix?

-Paul W.


From imp at bsdimp.com  Wed Mar 21 06:27:39 2018
From: imp at bsdimp.com (Warner Losh)
Date: Tue, 20 Mar 2018 14:27:39 -0600
Subject: [TUHS] FORTRAN
In-Reply-To: <CABH=_VSjLP1XRVa6MG-q_nCyNRMqF8iKSrt8o5Tu-e+615zDMQ@mail.gmail.com>
References: <CAC20D2P-dNX8AM_mh5N+Th-VYsG9COP8PX8QufLmFE2zh7MUqw@mail.gmail.com>
 <61051ebbca4809c08b60e92014851069e83a07f8@webmail.yaccman.com>
 <CAEoi9W6kLW5U-=kycN_8Orp228XZfFBv=88xzgam=76AWcJV3w@mail.gmail.com>
 <002f01d3c085$6b5a26d0$420e7470$@ronnatalie.com>
 <CABH=_VSjLP1XRVa6MG-q_nCyNRMqF8iKSrt8o5Tu-e+615zDMQ@mail.gmail.com>
Message-ID: <CANCZdfpnvqjZAgYXGHVk2koHEUWLEyErs=iM-YUDx4ez6UpJzw@mail.gmail.com>

On Tue, Mar 20, 2018 at 2:21 PM, Paul Winalski <paul.winalski at gmail.com>
wrote:

> On 3/20/18, Ron Natalie <ron at ronnatalie.com> wrote:
> > Having worked on system programming for UNIX and a few of the PDP-11 DEC
> > OS’s (DOS, RT, RSX, and in passing RSTS), I can tell you Fortran was
> > abhorrent.
> >
> Yes, Fortran is as awful for system programming as C is for numeric
> programming that involves throwing multidimensional arrays around.
> Screwdrivers always make bad hammers.
>

With care, and the right additional pseudo-primitives, you can do quite
interesting systems-programming-like things in Fortran. But they are
usually a variation on RATFOR and often involve more pain than would
otherwise have been needed, but it's possible. I once did some low-level
systems stuff in FORTRAN-66 that lived under a psuedo Fortran 77
pre-processor that had some CPP-like macro features....

And I will never, ever, do it again :). I might do Turbo-PASCAL again, but
no system's programming in Fortran.

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180320/9d76599d/attachment.html>

From clemc at ccc.com  Wed Mar 21 07:09:17 2018
From: clemc at ccc.com (Clem Cole)
Date: Tue, 20 Mar 2018 17:09:17 -0400
Subject: [TUHS] daemons are not to be exorcised
In-Reply-To: <20180320201441.GA28553@minnie.tuhs.org>
References: <CAFCBnZsS8Si6YGD4w_3W_znf3J5nVZGThkHVuQm5nD+FFm0DOg@mail.gmail.com>
 <CABH=_VQ3w+XtR3Ow1m6g69828CTDY3SMduCNN-LevO_EZFKypg@mail.gmail.com>
 <CAKr6gn3nuFKhQ5cx124kiSuGi3Znbs3-zccpe5KGUn-o-bEcpw@mail.gmail.com>
 <CAEoi9W66vwNnSSH8j2F5nYuo9T9MEjvDhzAwWodZ8ZA3nO2wMw@mail.gmail.com>
 <20180320182445.5BBA8156E510@mail.bitblocks.com>
 <CAC20D2Mez9m17ov=MFVKnqB8biEkTJqd8jDOQCDiRqQwduX8mw@mail.gmail.com>
 <20180320201441.GA28553@minnie.tuhs.org>
Message-ID: <CAC20D2MsumeGBTg6=0YSS8jv4M7xe88FcQL_ew5VCvpNnW1bJQ@mail.gmail.com>

On Tue, Mar 20, 2018 at 4:14 PM, Warren Toomey <wkt at tuhs.org> wrote:

> On Tue, Mar 20, 2018 at 02:46:00PM -0400, Clem Cole wrote:
>
>>   As for Paul's comment about the daemons.  Yes, Kirk McKusick who
>>   actually drew the original BSD daemon with purple sneakers, was wearing
>>   the infamous blue tee with said logo out walking on the street, as one
>>   someone else in the party (maybe Sam Leffler) sporting a 10 anniversary
>>   USENIX shirt in San Antonio many years ago, which has the daemons shown
>>   top of a PDP-11 with pipes, the null device, et al.   He has quite a
>>   tale of the experience.
>>
>
> The daemons on the PDP-11 with pipes was drawn by Phil Foglio:
> https://www.mckusick.com/beastie/shirts/usenix.html
>
> and this image was the inspiration for the BSD daemon.
>

​Indeed.   Kirk ended up getting some sort of legal rights for his version
of it [don't ask me which - trademark/copyright] .

Sadly my wife threw out my Foglio shirt a few years after we were married
(one of our first disagreements on the value of 'old' things - which
continues today - now she stay out the basement where my museum is😎.   In
her defense, it was probably 5-6 years old then, had holes and had not worn
well.   The shirts were very inexpensively made and frankly after 20-30
washings, the red piping on the side had faded and a few more washing the
printing started to fall off.
ᐧ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180320/0dcdacb4/attachment.html>

From a.phillip.garcia at gmail.com  Wed Mar 21 07:12:55 2018
From: a.phillip.garcia at gmail.com (A. P. Garcia)
Date: Tue, 20 Mar 2018 16:12:55 -0500
Subject: [TUHS] daemons are not to be exorcised
In-Reply-To: <4B8624EE-EB25-4029-8C35-8F8266107D2C@tfeb.org>
References: <CAFCBnZsS8Si6YGD4w_3W_znf3J5nVZGThkHVuQm5nD+FFm0DOg@mail.gmail.com>
 <CABH=_VQ3w+XtR3Ow1m6g69828CTDY3SMduCNN-LevO_EZFKypg@mail.gmail.com>
 <CAKr6gn3nuFKhQ5cx124kiSuGi3Znbs3-zccpe5KGUn-o-bEcpw@mail.gmail.com>
 <CAEoi9W66vwNnSSH8j2F5nYuo9T9MEjvDhzAwWodZ8ZA3nO2wMw@mail.gmail.com>
 <20180320182445.5BBA8156E510@mail.bitblocks.com>
 <CAC20D2Mez9m17ov=MFVKnqB8biEkTJqd8jDOQCDiRqQwduX8mw@mail.gmail.com>
 <4B8624EE-EB25-4029-8C35-8F8266107D2C@tfeb.org>
Message-ID: <CAFCBnZscLQFERNVy4LmLDNxDdeOWq5fZXCE86AvaR5PNaZoGNw@mail.gmail.com>

On Mar 20, 2018 2:58 PM, "Tim Bradshaw" <tfb at tfeb.org> wrote:

This seems like an unduly complicated theory.  Maxwell had a good
19th-century Scottish gentleman's education (he knew great chunks of
Paradise Lost by heart as a child) and he would have been far more familiar
with classical literature than most scientists are today as a result.
Chances are he knew what daemons were in mythology because he'd  read
either the Greek originals or Latin translations at school & university.


Given that, he could also have read about them in Plato's Republic when he
discusses the myth of Er at the end of the work.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180320/9f4d8e40/attachment.html>

From clemc at ccc.com  Wed Mar 21 07:15:06 2018
From: clemc at ccc.com (Clem Cole)
Date: Tue, 20 Mar 2018 17:15:06 -0400
Subject: [TUHS] daemons are not to be exorcised
In-Reply-To: <CABH=_VS2J9ExMiqMUfr7JDRDirvYxfaL+-dwhthc5tP3idW2mQ@mail.gmail.com>
References: <CAFCBnZsS8Si6YGD4w_3W_znf3J5nVZGThkHVuQm5nD+FFm0DOg@mail.gmail.com>
 <CABH=_VQ3w+XtR3Ow1m6g69828CTDY3SMduCNN-LevO_EZFKypg@mail.gmail.com>
 <CAKr6gn3nuFKhQ5cx124kiSuGi3Znbs3-zccpe5KGUn-o-bEcpw@mail.gmail.com>
 <CAEoi9W66vwNnSSH8j2F5nYuo9T9MEjvDhzAwWodZ8ZA3nO2wMw@mail.gmail.com>
 <20180320182445.5BBA8156E510@mail.bitblocks.com>
 <CAC20D2Mez9m17ov=MFVKnqB8biEkTJqd8jDOQCDiRqQwduX8mw@mail.gmail.com>
 <20180320201441.GA28553@minnie.tuhs.org>
 <CABH=_VS2J9ExMiqMUfr7JDRDirvYxfaL+-dwhthc5tP3idW2mQ@mail.gmail.com>
Message-ID: <CAC20D2MfSs_Brc0UjxC47Si0CXNRe_mrQmMUFqxf1OX4vWNZ-g@mail.gmail.com>

On Tue, Mar 20, 2018 at 4:25 PM, Paul Winalski <paul.winalski at gmail.com>
wrote:

> TOPS-10 had daemons (file daemon, for example).  Does the TOPS-10
> usage of the term predate or postdate its use in Unix?
>
> -Paul W.
>

​It was all pretty contemporary in my view. I suspect CTSS was first and
the others picked up the idea from there. Univac EXEC-8 called them
'symbiants' as I recall, and I think TSS used the term 'system tasks' but
we did refer to them as daemons also. Of course, I saw them called daemons
on TOPS and UNIX around the same time and never really made a big deal one
way or the other; again I think because we used the term on the IBM systems
sometimes.

Clem

ᐧ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180320/7ed772bf/attachment.html>

From beebe at math.utah.edu  Wed Mar 21 07:32:33 2018
From: beebe at math.utah.edu (Nelson H. F. Beebe)
Date: Tue, 20 Mar 2018 15:32:33 -0600
Subject: [TUHS] daemons are not to be exorcised
Message-ID: <CMM.0.96.0.1521581553.beebe@gamma.math.utah.edu>

Peter Guthrie Tait (1831--1901) seems to have recorded the oldest
mention of the thermodynamic demon of James {Clerk Maxwell} in the
page 213 image from Tait's book ``Sketch of Thermodynamics'' at

	https://archive.org/stream/lifescientificwo00knotuoft#page/212/mode/2up

that was posted to this list by Bakul Shah <bakul at bitblocks.com> on
Tue, 20 Mar 2018 12:10:37 -0700.

I've been working on a bibliography (still unreleased) of Clerk
Maxwell, and the oldest reference that I had so far found to Maxwell's
demon is from an address by Sir William Thomson (later raised to Lord
Kelvin) entitled

	The sorting demon of Maxwell: [Abstract of a Friday evening
	Lecture before the Royal Institution of Great Britain,
	February 28, 1879]
	Proceedings of the Royal Institution of Great Britain 9,
	113--114 (1882)

However, I've not been able to find that volume online.  Hathi Trust
has only volumes 30--71, with numerous holes, and often, it will not
show page contents at all.  The journal issue is old enough that few
university libraries are likely to have it, but it is probably
available through the Interlibrary Loan service.

I had also recorded

	Harold Whiting
	Maxwell's demons
	Science (new series) 6(130), 83, July 1885
	https://doi.org/10.1126/science.ns-6.130.83

and
	W. Ehrenberg
	Maxwell's demon
	Scientific American 217(5) 103--110, November 1967
	https://doi.org/10.1038/scientificamerican1167-103

plus numerous later papers and books.

I also went through a score of books on my shelf about physics or
thermodynamics, and finally found a brief mention of Maxwell's demon
in G. N. Lewis & M. Randall's famous text ``Thermodynamics'', first
published in 1923 (I have a 1961 reprint).  The other books that I
checked remain strangely silent on that topic.

The Oxford English Dictionary (OED) online has this definition and
etymology:

>> ...
>> Maxwell's demon n. (also Maxwell demon) an entity imagined by Maxwell
>> as allowing only fast-moving molecules to pass through a hole in one
>> direction and only slow-moving ones in the other direction, so that if
>> the hole is in a partition dividing a gas-filled vessel, one side
>> becomes warmer and the other cooler, in contradiction of the second
>> law of thermodynamics.
>>
>> 1879 W. Thomson in Proc. Royal Inst. 9 113 Clerk Maxwell's `demon' is
>>      a creature of imagination.., invented to help us to understand the
>>      `Dissipation of Energy' in nature.
>>
>> 1885 Science 31 July 83/1 (heading) Maxwell's demons.
>>
>> 1956 E. H. Hutten Lang. Mod. Physics iv. 152 It would require a
>>      Maxwell demon..to select the rapidly moving molecules according to
>>      their velocity and concentrate them in one corner of the vessel.
>>
>> 1971 Sci. Amer. Sept. 182/2 Maxwell's demon became an intellectual
>>      thorn in the side of thermodynamicists for almost a century. The
>>      challenge to the second law of thermodynamics was this: Is the
>>      principle of the increase of entropy in all spontaneous processes
>>      invalid where intelligence intervenes?
>>
>> 1988 Nature 27 Oct. 779/2 Questions about the energy needed in
>>      measurement began with Maxwell's demon.
>> ...

For the word `daemon', the OED has this:

>> ...
>> Etymology: Probably an extended use of demon ....
>>
>> A program (or part of a program), esp. within a Unix system, which
>> runs in the background without intervention by the user, either
>> continuously or only when automatically activated by a particular
>> event or condition.  A distinction is sometimes made between the form
>> daemon, referring to a program on an operating system, and demon,
>> referring to a portion of a program, but the forms seem generally to
>> be used interchangeably, daemon being more usual.
>>
>> 1971 A. Bhushan Request for Comments (Network Working Group)
>>      (Electronic text) No. 114. 2 The cooperating processes may be
>>      `daemon' processes which `listen' to agreed-upon sockets, and
>>      follow the initial connection protocol.
>>
>> 1983 E. S. Raymond Hacker's Dict. 53 The printer daemon is just a
>>      program that is always running; it checks the special directory
>>      periodically, and whenever it finds a file there it prints it
>>      and then deletes it.
>>
>> 1989 DesignCenter ii. 41/3 The file server runs a standard set of
>>      HP-UX system and network daemons.
>>
>> 1992 New Scientist 18 Jan. 35/2 These programs, which could recognise
>>      simple patterns, were made up of several independent
>>      information-processing units, or `demons', and a `master
>>      demon'.
>>
>> 2002 N.Y. Times 7 Mar. d4/5 A mailer daemon installed on an e-mail
>>      system can respond to a piece of incorrectly addressed e-mail
>>      by generating an automated message to the sender that the
>>      message was undeliverable.
>> ...

	       ----------------------------------------

>From The Hacker's Dictionary (1983), reproduced in the Emacs info node
Jargon, I find another `explanation' of daemon:

>> ...
>> :daemon: /day'mn/ or /dee'mn/ /n./  [from the mythological
>>    meaning, later rationalized as the acronym `Disk And Execution
>>    MONitor'] A program that is not invoked explicitly, but lies
>>    dormant waiting for some condition(s) to occur.  The idea is that
>>    the perpetrator of the condition need not be aware that a daemon is
>>    lurking (though often a program will commit an action only because
>>    it knows that it will implicitly invoke a daemon).  For example,
>>    under {{ITS}} writing a file on the {LPT} spooler's directory
>>    would invoke the spooling daemon, which would then print the file.
>>    The advantage is that programs wanting (in this example) files
>>    printed need neither compete for access to nor understand any
>>    idiosyncrasies of the {LPT}.  They simply enter their implicit
>>    requests and let the daemon decide what to do with them.  Daemons
>>    are usually spawned automatically by the system, and may either
>>    live forever or be regenerated at intervals.
>>
>>    Daemon and {demon} are often used interchangeably, but seem to
>>    have distinct connotations.  The term `daemon' was introduced to
>>    computing by {CTSS} people (who pronounced it /dee'mon/) and
>>    used it to refer to what ITS called a {dragon}.  Although the
>>    meaning and the pronunciation have drifted, we think this glossary
>>    reflects current (1996) usage.
>> ...

-------------------------------------------------------------------------------
- Nelson H. F. Beebe                    Tel: +1 801 581 5254                  -
- University of Utah                    FAX: +1 801 581 4148                  -
- Department of Mathematics, 110 LCB    Internet e-mail: beebe at math.utah.edu  -
- 155 S 1400 E RM 233                       beebe at acm.org  beebe at computer.org -
- Salt Lake City, UT 84112-0090, USA    URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------


From clemc at ccc.com  Wed Mar 21 07:36:16 2018
From: clemc at ccc.com (Clem Cole)
Date: Tue, 20 Mar 2018 17:36:16 -0400
Subject: [TUHS] FORTRAN
In-Reply-To: <002f01d3c085$6b5a26d0$420e7470$@ronnatalie.com>
References: <CAC20D2P-dNX8AM_mh5N+Th-VYsG9COP8PX8QufLmFE2zh7MUqw@mail.gmail.com>
 <61051ebbca4809c08b60e92014851069e83a07f8@webmail.yaccman.com>
 <CAEoi9W6kLW5U-=kycN_8Orp228XZfFBv=88xzgam=76AWcJV3w@mail.gmail.com>
 <002f01d3c085$6b5a26d0$420e7470$@ronnatalie.com>
Message-ID: <CAC20D2NNxp-3Qpw1=_3+3ZT6pk-b_answ88-KLZCw7j3gf7WOw@mail.gmail.com>

On Tue, Mar 20, 2018 at 3:55 PM, Ron Natalie <ron at ronnatalie.com> wrote:

> Having worked on system programming for UNIX and a few of the PDP-11 DEC
> OS’s (DOS, RT, RSX, and in passing RSTS), I can tell you Fortran was
> abhorrent.
>
> Sure it was the only high-level language I had on the RT and RSX systems,
>
​And that was the problem... DEC did not market good tools besides
assembler and FTN for RT and RSX.   3rd parties like Oregon SW and
Whitesmiths' eventually produced good Pascal and C implementation
respectfully.   But, like you, most people I knew, and in my own
experience; nothing but asm and FTN was there.

Paul can correct me, but I don't think DEC even developed a Pascal for TOPS
originally - IIRC the one I used came from the universities.   I think the
first Pascal sold was targeted for the VAX.  Also, RT11 and RSX were
'laboratory' systems and those systems were dominated by Fortran back in
the day - so DEC marketing thought in those terms.

I remember that CMU's Mellon Institute built an automated realtime
newspaper sorting/delivery system for the Pittsburgh Press and a number of
other newspapers and ended up using FORTRAN - because that's all they had
for RT11 that they trusted (thankfully that project started after I had
left, although I helped with the bidding and assessment). We had wanted to
use BLISS but that meant cross compiling from the 10's and the customer
wanted the system self hosting as I recall. By the time the Mellon folks
completed the project, OMSI's Pascal compiler for RT11 was available, but
the water was under the bridge.



> but its character handling was awful.
>
​Yep - but as others have pointed out, with something like RATFOR it could
be made usable and that's what a lot of people I know did when they had
too.   As I said, the FPS folks wrote a parallelizing, Fortran for the
FPS-164 in Ratfor A compiler, to me, is the definition if a character based
application if I can name one.




>   I ended up writing almost all that stuff in assembler
> ​ ​
> (which fortunately the PDP-11 is wonderful for).
>
> ​You and many others ;-)

Clem​
ᐧ
ᐧ
ᐧ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180320/35237ea8/attachment.html>

From akosela at andykosela.com  Wed Mar 21 07:40:09 2018
From: akosela at andykosela.com (Andy Kosela)
Date: Tue, 20 Mar 2018 16:40:09 -0500
Subject: [TUHS] daemons are not to be exorcised
In-Reply-To: <CAFCBnZscLQFERNVy4LmLDNxDdeOWq5fZXCE86AvaR5PNaZoGNw@mail.gmail.com>
References: <CAFCBnZsS8Si6YGD4w_3W_znf3J5nVZGThkHVuQm5nD+FFm0DOg@mail.gmail.com>
 <CABH=_VQ3w+XtR3Ow1m6g69828CTDY3SMduCNN-LevO_EZFKypg@mail.gmail.com>
 <CAKr6gn3nuFKhQ5cx124kiSuGi3Znbs3-zccpe5KGUn-o-bEcpw@mail.gmail.com>
 <CAEoi9W66vwNnSSH8j2F5nYuo9T9MEjvDhzAwWodZ8ZA3nO2wMw@mail.gmail.com>
 <20180320182445.5BBA8156E510@mail.bitblocks.com>
 <CAC20D2Mez9m17ov=MFVKnqB8biEkTJqd8jDOQCDiRqQwduX8mw@mail.gmail.com>
 <4B8624EE-EB25-4029-8C35-8F8266107D2C@tfeb.org>
 <CAFCBnZscLQFERNVy4LmLDNxDdeOWq5fZXCE86AvaR5PNaZoGNw@mail.gmail.com>
Message-ID: <CALMnNGhq=yZTfT_ytE2km5Kr-=rKHpiojYMAyJbb2RA+dJGw9Q@mail.gmail.com>

On Tuesday, March 20, 2018, A. P. Garcia <a.phillip.garcia at gmail.com> wrote:

>
>
> On Mar 20, 2018 2:58 PM, "Tim Bradshaw" <tfb at tfeb.org> wrote:
>
> This seems like an unduly complicated theory.  Maxwell had a good
> 19th-century Scottish gentleman's education (he knew great chunks of
> Paradise Lost by heart as a child) and he would have been far more familiar
> with classical literature than most scientists are today as a result.
> Chances are he knew what daemons were in mythology because he'd  read
> either the Greek originals or Latin translations at school & university.
>
>
> Given that, he could also have read about them in Plato's Republic when he
> discusses the myth of Er at the end of the work.
>

Exactly.  Plato also writes extensively on it in his other works, e.g.
Cratylus.  He is using the term 'daimones' and it could be best described
as the guardian angel of the Christians.  So there is a big difference
between evil demons (devils) of Christianity and the daimon of Socrates and
Plato.

--Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180320/b9d5d8ec/attachment.html>

From ron at ronnatalie.com  Wed Mar 21 07:59:13 2018
From: ron at ronnatalie.com (Ron Natalie)
Date: Tue, 20 Mar 2018 17:59:13 -0400
Subject: [TUHS] FORTRAN
In-Reply-To: <CAC20D2NNxp-3Qpw1=_3+3ZT6pk-b_answ88-KLZCw7j3gf7WOw@mail.gmail.com>
References: <CAC20D2P-dNX8AM_mh5N+Th-VYsG9COP8PX8QufLmFE2zh7MUqw@mail.gmail.com>
 <61051ebbca4809c08b60e92014851069e83a07f8@webmail.yaccman.com>
 <CAEoi9W6kLW5U-=kycN_8Orp228XZfFBv=88xzgam=76AWcJV3w@mail.gmail.com>
 <002f01d3c085$6b5a26d0$420e7470$@ronnatalie.com>
 <CAC20D2NNxp-3Qpw1=_3+3ZT6pk-b_answ88-KLZCw7j3gf7WOw@mail.gmail.com>
Message-ID: <006c01d3c096$afa54e30$0eefea90$@ronnatalie.com>



> Paul can correct me, but I don't think DEC even developed a Pascal for TOPS originally - IIRC the one I used came from the universities.   I think the first Pascal sold was targeted for the VAX.  
We made heavy use of PASCAL on the TOPS10 system at JHU, but I don't know what the origin of it was.    I'd be surprised if it wasn't DEC.   That shop wasn't overly innovative. 
>>  but its character handling was awful.  
​> Yep - but as others have pointed out, with something like RATFOR it could be made usable and that's what a lot of people I know did when they had too.   As I said, the FPS folks wrote a parallelizing, Fortran for the FPS-164 in Ratfor A compiler, to me, is the definition if a character based application if I can name one.

Ratfor got you decent control structures but it didn't get around the fortran data model suckage.
 
 
ᐧ
ᐧ
ᐧ



From dds at aueb.gr  Wed Mar 21 08:16:25 2018
From: dds at aueb.gr (Diomidis Spinellis)
Date: Wed, 21 Mar 2018 00:16:25 +0200
Subject: [TUHS] Timelines of 15,
	596 documented Unix facilities from 1970 until today
Message-ID: <dcd38752-f849-807e-e7d8-ef6d3b629569@aueb.gr>

I've put online at https://dspinellis.github.io/unix-history-man/ nine 
timelines detailing the evolution of 15,596 unique documented facilities 
(commands, system calls, library functions, device drivers, etc.) across 
93 major Unix releases tracked by the Unix history repository.

For each facility you get a timeline starting from the release it first 
appeared.  Clicking on the timeline opens up the manual page for the 
corresponding release.  (Sadly, the formatting is often messed up, 
because more work is needed on the JavaScript troff renderer I'm using.) 
  The associated scripts and the raw data are all available on GitHub.

Diomidis


From dscherrer at solar.stanford.edu  Wed Mar 21 07:56:55 2018
From: dscherrer at solar.stanford.edu (Deborah Scherrer)
Date: Tue, 20 Mar 2018 14:56:55 -0700
Subject: [TUHS] mt Xinu Unix manuals
Message-ID: <fc99c4e1-523b-27e9-f841-2acc8c24207f@solar.stanford.edu>

A while ago someone was asking about the mt Xinu Unix manuals.  I have a 
found a complete set, currently owned by Vance Vaughan, one of the mt 
Xinu founders.  He is willing to donate them to Warren's Unix archive.  
However, they are too expensive to ship to Australia.

Would anyone be willing to scan them in for the archive?  Ah, there are 
a lot of them (8? volumes).   If so, I might be able to ship them to 
somewhere in the US.

Let me know.

Thanks.
Deborah


From bakul at bitblocks.com  Wed Mar 21 09:00:32 2018
From: bakul at bitblocks.com (Bakul Shah)
Date: Tue, 20 Mar 2018 16:00:32 -0700
Subject: [TUHS] FORTRAN
In-Reply-To: <CAC20D2NNxp-3Qpw1=_3+3ZT6pk-b_answ88-KLZCw7j3gf7WOw@mail.gmail.com>
References: <CAC20D2P-dNX8AM_mh5N+Th-VYsG9COP8PX8QufLmFE2zh7MUqw@mail.gmail.com>
 <61051ebbca4809c08b60e92014851069e83a07f8@webmail.yaccman.com>
 <CAEoi9W6kLW5U-=kycN_8Orp228XZfFBv=88xzgam=76AWcJV3w@mail.gmail.com>
 <002f01d3c085$6b5a26d0$420e7470$@ronnatalie.com>
 <CAC20D2NNxp-3Qpw1=_3+3ZT6pk-b_answ88-KLZCw7j3gf7WOw@mail.gmail.com>
Message-ID: <8E0EC81A-D1EB-4070-AAD5-FBFF3139975E@bitblocks.com>

On Mar 20, 2018, at 2:36 PM, Clem Cole <clemc at ccc.com> wrote:
> 
> Paul can correct me, but I don't think DEC even developed a Pascal for TOPS originally - IIRC the one I used came from the universities.   I think the first Pascal sold was targeted for the VAX.  Also, RT11 and RSX were 'laboratory' systems and those systems were dominated by Fortran back in the day - so DEC marketing thought in those terms.

True re TOPS-10.

The TOP-10 Pascal compiler was ported from the one for
CDC-6000 (authors: Urs Amman, Kesav Nori and may be others).
The CDC version was what was described in the Pascal User
Manual and Report by Jensen and Wirth. IIRC, someone at Purdue
was maintaining it. I knew it well as I had added formatted IO
for scalars, sets & a few more things that I forget now + I
was studying it with an aim to write my own compiler. I 
believe this was the port:

https://www.researchgate.net/publication/220846309_A_pascal_compiler_bootstrapped_on_a_DEC-System_10

[Even the portable "P4" Pascal compiler must've been derived
from the same original code as I recognize its code shape and
random stuff like variable names etc.  p4 sources are online
but I don't see the tops-10 ones]

From toby at telegraphics.com.au  Wed Mar 21 09:21:22 2018
From: toby at telegraphics.com.au (Toby Thain)
Date: Tue, 20 Mar 2018 19:21:22 -0400
Subject: [TUHS] mt Xinu Unix manuals
In-Reply-To: <fc99c4e1-523b-27e9-f841-2acc8c24207f@solar.stanford.edu>
References: <fc99c4e1-523b-27e9-f841-2acc8c24207f@solar.stanford.edu>
Message-ID: <edf1bb85-7124-1d72-bc85-cb0eceaff23a@telegraphics.com.au>

On 2018-03-20 5:56 PM, Deborah Scherrer wrote:
> A while ago someone was asking about the mt Xinu Unix manuals.  I have a
> found a complete set, currently owned by Vance Vaughan, one of the mt
> Xinu founders.  He is willing to donate them to Warren's Unix archive. 
> However, they are too expensive to ship to Australia.
> 
> Would anyone be willing to scan them in for the archive?  Ah, there are
> a lot of them (8? volumes).   If so, I might be able to ship them to
> somewhere in the US.

How are they bound?

The usual scanning repository is Bitsavers, where you can contact Al
Kossow (he's probably even on this list).

--Toby

> 
> Let me know.
> 
> Thanks.
> Deborah
> 



From dscherrer at solar.stanford.edu  Wed Mar 21 09:23:17 2018
From: dscherrer at solar.stanford.edu (Deborah Scherrer)
Date: Tue, 20 Mar 2018 16:23:17 -0700
Subject: [TUHS] mt Xinu Unix manuals
In-Reply-To: <edf1bb85-7124-1d72-bc85-cb0eceaff23a@telegraphics.com.au>
References: <fc99c4e1-523b-27e9-f841-2acc8c24207f@solar.stanford.edu>
 <edf1bb85-7124-1d72-bc85-cb0eceaff23a@telegraphics.com.au>
Message-ID: <224928b1-2ab2-2d1e-b135-12ed8ac80e8f@solar.stanford.edu>

Thanks.  Al has already contacted me, as has David Arnold.  Amongst us 
we'll get them to Warren.

Thanks everyone for the quick and wonderful responses!
Deborah

On 3/20/18 4:21 PM, Toby Thain wrote:
> On 2018-03-20 5:56 PM, Deborah Scherrer wrote:
>> A while ago someone was asking about the mt Xinu Unix manuals.  I have a
>> found a complete set, currently owned by Vance Vaughan, one of the mt
>> Xinu founders.  He is willing to donate them to Warren's Unix archive.
>> However, they are too expensive to ship to Australia.
>>
>> Would anyone be willing to scan them in for the archive?  Ah, there are
>> a lot of them (8? volumes).   If so, I might be able to ship them to
>> somewhere in the US.
> How are they bound?
>
> The usual scanning repository is Bitsavers, where you can contact Al
> Kossow (he's probably even on this list).
>
> --Toby
>
>> Let me know.
>>
>> Thanks.
>> Deborah
>>



From tytso at mit.edu  Wed Mar 21 12:31:25 2018
From: tytso at mit.edu (Theodore Y. Ts'o)
Date: Tue, 20 Mar 2018 22:31:25 -0400
Subject: [TUHS] daemons are not to be exorcised
In-Reply-To: <98451f10-9b1b-049b-61ed-fd73586572fd@spamtrap.tnetconsulting.net>
References: <CAFCBnZsS8Si6YGD4w_3W_znf3J5nVZGThkHVuQm5nD+FFm0DOg@mail.gmail.com>
 <94366db0-293b-214a-23a3-c7c895e4d30b@spamtrap.tnetconsulting.net>
 <alpine.BSF.2.02.1803200023360.43136@frieza.hoshinet.org>
 <98451f10-9b1b-049b-61ed-fd73586572fd@spamtrap.tnetconsulting.net>
Message-ID: <20180321023125.GC6850@thunk.org>

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


From lm at mcvoy.com  Wed Mar 21 13:20:58 2018
From: lm at mcvoy.com (Larry McVoy)
Date: Tue, 20 Mar 2018 20:20:58 -0700
Subject: [TUHS] daemons are not to be exorcised
In-Reply-To: <20180321023125.GC6850@thunk.org>
References: <CAFCBnZsS8Si6YGD4w_3W_znf3J5nVZGThkHVuQm5nD+FFm0DOg@mail.gmail.com>
 <94366db0-293b-214a-23a3-c7c895e4d30b@spamtrap.tnetconsulting.net>
 <alpine.BSF.2.02.1803200023360.43136@frieza.hoshinet.org>
 <98451f10-9b1b-049b-61ed-fd73586572fd@spamtrap.tnetconsulting.net>
 <20180321023125.GC6850@thunk.org>
Message-ID: <20180321032058.GM25650@mcvoy.com>

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 


From imp at bsdimp.com  Wed Mar 21 14:30:27 2018
From: imp at bsdimp.com (Warner Losh)
Date: Tue, 20 Mar 2018 22:30:27 -0600
Subject: [TUHS] daemons are not to be exorcised
In-Reply-To: <20180321023125.GC6850@thunk.org>
References: <CAFCBnZsS8Si6YGD4w_3W_znf3J5nVZGThkHVuQm5nD+FFm0DOg@mail.gmail.com>
 <94366db0-293b-214a-23a3-c7c895e4d30b@spamtrap.tnetconsulting.net>
 <alpine.BSF.2.02.1803200023360.43136@frieza.hoshinet.org>
 <98451f10-9b1b-049b-61ed-fd73586572fd@spamtrap.tnetconsulting.net>
 <20180321023125.GC6850@thunk.org>
Message-ID: <CANCZdfrm8gkZO6nDmyM=NqnEk92X0Lh=bpLxH4CzRCT8RbsP2Q@mail.gmail.com>

On Tue, Mar 20, 2018 at 8: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.  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.
>

At Netflix, we log JSON entries and scrape the logs to upload to our data
base.... Simple syslogd can work, but I've often seen other packets layered
upon its simple protocol...

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.
>

To be fair, the earliest versions of Linux's PC Card support did likewise.
Like the BSDs, the initial drivers were network or serial that were hacks
on existing drivers that "reached over" and configured the PCIC so the
device could probe. Those hacks were later replaced with better code that
allowed for a wider array of drivers, as well as allowing them to come and
go. The first hacks for hot-plug PCI also followed a similar trajectory:
some hack to let people boot with the hardware in place, either in the
driver itself, or in the bridges, followed months or years later by proper
hot-plug support. USB was similar, but plug and unplug were well-trodden
paths by the time it came along, so there was no lag...


> 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?
>

Much the same way that FreeBSD has gone: to move away form the hand-tweaked
config tables with lots of ifdefs in v7 to having each driver self
contained with an init function that registers other interesting things and
a way to add to the tree dynamically after boot. But maybe I'm biased,
though it is approximately the model that Linux's device discovery evolved
into after trying a couple of different strategies out first...

But there's many things that v7 never had to deal with: multiple CPU
(everybody did that differently), dynamic devices, thousands of different
devices supported by hundreds of drivers (it supports like 10 or 15 major
ones), cope with large memory systems, deal with devices that had widely
varying performance (all disks were the same: you submitted the request and
tens of milliseconds later you got the results: no imbalances if you had a
system with both NVMe with microsecond response time and tens of thousands
of queue entires along with spinning rust with 10ms response time and maybe
a few dozen). v7 didn't have to cope with devices that were very smart, so
it didn't have to deal with dynamically balancing system resources to cope.
It didn't have to deal with demand paging, or pages of different sizes. It
didn't have to cope with cache coherency issues. It didn't even bother with
shared libraries, nor did it require a MMU, though there were performance
and security benefits. Oh, and it didn't deal with security very well by
today's standards.

Even so, the code is very simple to read and understand. And now that's
it's available, it makes so many other decisions and design patterns make
so much more sense than even finely written prose describing them. The
simple elegance of its ideas and implementation afforded a clarity of
design that allowed one to see the basics and hold it all in your head with
not too much study. The same cannot be said for any modern OS.

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180320/befef091/attachment.html>

From gtaylor at tnetconsulting.net  Wed Mar 21 14:52:39 2018
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Tue, 20 Mar 2018 22:52:39 -0600
Subject: [TUHS] daemons are not to be exorcised
In-Reply-To: <20180321023125.GC6850@thunk.org>
References: <CAFCBnZsS8Si6YGD4w_3W_znf3J5nVZGThkHVuQm5nD+FFm0DOg@mail.gmail.com>
 <94366db0-293b-214a-23a3-c7c895e4d30b@spamtrap.tnetconsulting.net>
 <alpine.BSF.2.02.1803200023360.43136@frieza.hoshinet.org>
 <98451f10-9b1b-049b-61ed-fd73586572fd@spamtrap.tnetconsulting.net>
 <20180321023125.GC6850@thunk.org>
Message-ID: <d959fe31-83ad-2c93-8c50-7451e757e8d1@spamtrap.tnetconsulting.net>

On 03/20/2018 08:31 PM, Theodore Y. Ts'o wrote:
> There are also ways in which Unix is just simply deficient.

I get the impression that you seem to think that I think that what Unix 
was around the time of BSD 4.3 was sufficient.  -  I'm not making that 
claim or even thinking it.

I'm talking about the spirit, as in "do one thing and do it well".  Not 
that e.g. syslog shall be these specific facilities and these specific 
severrities.

I want people to understand what was done, why it was done, and to the 
best of their ability, make an informed decision when changing from 
history.  -  I'd really like people to be able to answer the question 
"Why did you do <bla> differently than it was done in <blaBlaBla>.  What 
was wrong / lacking / needed to be improved from the old way."

As long as people 1) have answers to those questions and 2) can speak to 
why they did what they did, then by all means, move forward with 
something new to try.

I hear tell of people putting reverse proxies in containers in front of 
web server containers so that they can have basic traffic counters, 
which they can't get (for some unknown to me reason) from their web 
server container.  -  Where if they had bothered to ask the network 
people, there are very likely multiple ways to get said traffic 
counters.  Further, ways to do it without adding the additional 
complexity (read: exposure) / latency of additional containers.



-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3982 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180320/2d5f8b7f/attachment.bin>

From wobblygong at gmail.com  Wed Mar 21 16:32:40 2018
From: wobblygong at gmail.com (Wesley Parish)
Date: Wed, 21 Mar 2018 19:32:40 +1300
Subject: [TUHS] daemons are not to be exorcised
In-Reply-To: <4B8624EE-EB25-4029-8C35-8F8266107D2C@tfeb.org>
References: <CAFCBnZsS8Si6YGD4w_3W_znf3J5nVZGThkHVuQm5nD+FFm0DOg@mail.gmail.com>
 <CABH=_VQ3w+XtR3Ow1m6g69828CTDY3SMduCNN-LevO_EZFKypg@mail.gmail.com>
 <CAKr6gn3nuFKhQ5cx124kiSuGi3Znbs3-zccpe5KGUn-o-bEcpw@mail.gmail.com>
 <CAEoi9W66vwNnSSH8j2F5nYuo9T9MEjvDhzAwWodZ8ZA3nO2wMw@mail.gmail.com>
 <20180320182445.5BBA8156E510@mail.bitblocks.com>
 <CAC20D2Mez9m17ov=MFVKnqB8biEkTJqd8jDOQCDiRqQwduX8mw@mail.gmail.com>
 <4B8624EE-EB25-4029-8C35-8F8266107D2C@tfeb.org>
Message-ID: <CACNPpebF1DDrSS2TPnpCroRax8F7YvcLcGWjQ421SWvupRVSFg@mail.gmail.com>

Allow me to add my 2 cents:

Ancient Greece, like all other "primitive" societies that I am aware
of, had beliefs in "spirits" as well as in the CxO level deities (Most
hunter-gatherer and farmer/hunter Stone Age societies didn't get to
the level of CxO dieties, they stuck with spirits behind everything.).
The CxO deities made the policies; very few of them actually carried
those policies out themselves; they relied on a bunch of lesser
spirits to do them. In Classical Greek, daemonoi.

Where the connection with the English word "demon" comes in, is this:
the Christian Church by and large did not believe in the goodness of
most of those alleged daemonoi and labelled them evil, in large part
because in the Christian mythology, there is very little room for
subsidiary spirits; The Christian God is a god without a specific
portfolio: he runs the whole show. Heaps more history there. too much
to cover.

So Maxwell with his Classical education with its heavy emphasis on
Latin and Greek language and culture, would've had a handy metaphor
immediately understandable by all his scientific peers in the Royal
Society, in France, Germany, Russia, the USA, and elsewhere.

And as such, it would be easily extendable to computer science looking
for a handy term to cover system-level background programs handling
details that were between low-level OS procedures and functions and
high-level user programs.

Wesley Parish

PS FWVLIW, JRR Tolkien took one specific subset of these "spirits",
the woodland spirits, "baptised" them so to speak as he was a devout
Catholic, and turned them into one of the axes of his fiction. Some
years later Cordwainer Smith played the same trick with his Daimoni,
except these Daimoni are more like spirits of the stars. So if you're
a fan of both JRR Tolkien and Cordwainer Smith and wonder why they
seem at times so similar, that is part of the reason.

On 3/21/18, Tim Bradshaw <tfb at tfeb.org> wrote:
> This seems like an unduly complicated theory.  Maxwell had a good
> 19th-century Scottish gentleman's education (he knew great chunks of
> Paradise Lost by heart as a child) and he would have been far more familiar
> with classical literature than most scientists are today as a result.
> Chances are he knew what daemons were in mythology because he'd  read either
> the Greek originals or Latin translations at school & university.
>
> Even today the term can be used without the connotations of evil that it
> often has: His Dark Materials has daemons which are not in any way evil.
> Perhaps significantly it is heavily influenced by Paradise Lost as well:
> perhaps the common source is that.  I have a copy but I haven't read it,
> sadly.
>
>> On 20 Mar 2018, at 18:46, Clem Cole <clemc at ccc.com> wrote:
>>
>>
>>
>>> On Tue, Mar 20, 2018 at 2:24 PM, Bakul Shah <bakul at bitblocks.com> wrote:
>>> On Tue, 20 Mar 2018 14:04:38 -0400 Dan Cross <crossd at gmail.com> wrote:
>>> Dan Cross writes:
>>> >
>>> > On Tue, Mar 20, 2018 at 1:56 PM, George Michaelson <ggm at algebras.org>
>>> > wrote:
>>> >
>>> > I think daemon/demon came from printers demon, which is carved into
>>> > > the government printing office in Brisbane. the printers demon is
>>> > > the
>>> > > one which stuffed up letters in the tray, to make printers tear
>>> > > their
>>> > > hair out. Did I say tray? I meant case, upper case, the one above,
>>> > > with the big letters, and lower case, the case with the little
>>> > > letters. oh dear. really? is that why they are cases?
>>> > >
>>> >
>>> > While this story (and the others I trimmed for brevity) is (are)
>>> > great,
>>> > "daemon" is actually from the Greek, I believe: an intermediary
>>> > between
>>> > humans (users) and the gods (the kernel).
>>>
>>> From http://ei.cs.vt.edu/~history/Daemon.html
>>>
>>>   Fernando J. Corbato: ... Our use of the word daemon (@
>>>   Project MAC in 1963) was inspired by the Maxwell's daemon of
>>>   physics and thermodynamics. (My background is Physics.)
>>>   Maxwell's daemon was an imaginary agent which helped sort
>>>   molecules of different speeds and worked tirelessly in the
>>>   background. We fancifully began to use the word daemon to
>>>   describe background processes which worked tirelessly to​​
>>>   perform system chores.
>>
>>
>> ​Right -- that is what I was under the impression from where the term came
>> for computer use.   Although, I was also under  the impression that
>> Maxwell had taken the term from ideas from some his Cambridge colleagues
>> that were working on human thought and described the ideas of these
>> daemons running around in your head supporting things like vision, hearing
>> and your other senses.   The later was formalized I believe years later by
>> Oliver Suthridge (IIRC my Cog Psych of many years ago) - into the
>> something like the Pandemonium model of cognition.
>>
>> i.e. I think the term was used first in Cognition, then to Physics and
>> finally to Computers.
>>
>> As for Paul's comment about the daemons.  Yes, Kirk McKusick who actually
>> drew the original BSD daemon with purple sneakers, was wearing the
>> infamous blue tee with said logo out walking on the street, as one someone
>> else in the party (maybe Sam Leffler) sporting a 10 anniversary USENIX
>> shirt in San Antonio many years ago, which has the daemons shown top of a
>> PDP-11 with pipes, the null device, et al.   He has quite a tale of the
>> experience.
>>
>> Clem
>>
>>
>>
>>
>>
>> ᐧ
>


From mutiny.mutiny at rediffmail.com  Wed Mar 21 17:09:12 2018
From: mutiny.mutiny at rediffmail.com (Mutiny)
Date: 21 Mar 2018 07:09:12 -0000
Subject: [TUHS]
	=?utf-8?q?Timelines_of_15=2C_596_documented_Unix_facilitie?=
	=?utf-8?q?s_from_1970_until_today?=
In-Reply-To: <dcd38752-f849-807e-e7d8-ef6d3b629569@aueb.gr>
Message-ID: <1521584526.S.5206.25616.f5-147-237.1521616152.15189@webmail.rediffmail.com>

great. Thanks a lot!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180321/f0d0d7d0/attachment.html>

From peter at rulingia.com  Wed Mar 21 18:10:42 2018
From: peter at rulingia.com (Peter Jeremy)
Date: Wed, 21 Mar 2018 19:10:42 +1100
Subject: [TUHS] FORTRAN
In-Reply-To: <CABH=_VSjLP1XRVa6MG-q_nCyNRMqF8iKSrt8o5Tu-e+615zDMQ@mail.gmail.com>
References: <CAC20D2P-dNX8AM_mh5N+Th-VYsG9COP8PX8QufLmFE2zh7MUqw@mail.gmail.com>
 <61051ebbca4809c08b60e92014851069e83a07f8@webmail.yaccman.com>
 <CAEoi9W6kLW5U-=kycN_8Orp228XZfFBv=88xzgam=76AWcJV3w@mail.gmail.com>
 <002f01d3c085$6b5a26d0$420e7470$@ronnatalie.com>
 <CABH=_VSjLP1XRVa6MG-q_nCyNRMqF8iKSrt8o5Tu-e+615zDMQ@mail.gmail.com>
Message-ID: <20180321081042.GA7611@server.rulingia.com>

On 2018-Mar-20 16:21:12 -0400, Paul Winalski <paul.winalski at gmail.com> wrote:
>Yes, Fortran is as awful for system programming as C is for numeric
>programming that involves throwing multidimensional arrays around.

Note that Pr1meOS was written in Fortran.  I did study it but no longer
recall what extensions it had to make that practical.

-- 
Peter Jeremy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180321/05cf7c64/attachment.sig>

From jaapna at xs4all.nl  Wed Mar 21 19:16:49 2018
From: jaapna at xs4all.nl (Jaap Akkerhuis)
Date: Wed, 21 Mar 2018 10:16:49 +0100
Subject: [TUHS] daemons are not to be exorcised
In-Reply-To: <20180321023125.GC6850@thunk.org>
References: <CAFCBnZsS8Si6YGD4w_3W_znf3J5nVZGThkHVuQm5nD+FFm0DOg@mail.gmail.com>
 <94366db0-293b-214a-23a3-c7c895e4d30b@spamtrap.tnetconsulting.net>
 <alpine.BSF.2.02.1803200023360.43136@frieza.hoshinet.org>
 <98451f10-9b1b-049b-61ed-fd73586572fd@spamtrap.tnetconsulting.net>
 <20180321023125.GC6850@thunk.org>
Message-ID: <76E7D09E-023B-4A29-ACCD-AF9ED425EE5F@xs4all.nl>



> On Mar 21, 2018, at 3:31, Theodore Y. Ts'o <tytso at mit.edu> wrote:
> 
> 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.

I've been told that syslog was came in existence as a debugging aid for sendmai.

	jaap

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180321/d5eef898/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 267 bytes
Desc: Message signed with OpenPGP
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180321/d5eef898/attachment.sig>

From emu at e-bbes.com  Wed Mar 21 22:10:35 2018
From: emu at e-bbes.com (emanuel stiebler)
Date: Wed, 21 Mar 2018 13:10:35 +0100
Subject: [TUHS] daemons are not to be exorcised
In-Reply-To: <CAKr6gn3nuFKhQ5cx124kiSuGi3Znbs3-zccpe5KGUn-o-bEcpw@mail.gmail.com>
References: <CAFCBnZsS8Si6YGD4w_3W_znf3J5nVZGThkHVuQm5nD+FFm0DOg@mail.gmail.com>
 <CABH=_VQ3w+XtR3Ow1m6g69828CTDY3SMduCNN-LevO_EZFKypg@mail.gmail.com>
 <CAKr6gn3nuFKhQ5cx124kiSuGi3Znbs3-zccpe5KGUn-o-bEcpw@mail.gmail.com>
Message-ID: <d5a9402c-ae10-d74a-992c-41c7bf9b08ec@e-bbes.com>

On 2018-03-20 18:56, George Michaelson wrote:

> I got given the last generation PDP-11 on a chip, in a 72pin DIP. I
> gave it to somebody else who could use it. 

72 pins?


From paul.winalski at gmail.com  Wed Mar 21 23:48:46 2018
From: paul.winalski at gmail.com (Paul Winalski)
Date: Wed, 21 Mar 2018 09:48:46 -0400
Subject: [TUHS] FORTRAN
In-Reply-To: <CAC20D2NNxp-3Qpw1=_3+3ZT6pk-b_answ88-KLZCw7j3gf7WOw@mail.gmail.com>
References: <CAC20D2P-dNX8AM_mh5N+Th-VYsG9COP8PX8QufLmFE2zh7MUqw@mail.gmail.com>
 <61051ebbca4809c08b60e92014851069e83a07f8@webmail.yaccman.com>
 <CAEoi9W6kLW5U-=kycN_8Orp228XZfFBv=88xzgam=76AWcJV3w@mail.gmail.com>
 <002f01d3c085$6b5a26d0$420e7470$@ronnatalie.com>
 <CAC20D2NNxp-3Qpw1=_3+3ZT6pk-b_answ88-KLZCw7j3gf7WOw@mail.gmail.com>
Message-ID: <CABH=_VTx13un9KxJStZEoo46MBrPLQwkaT+QQ0XzD9KQkKMxhw@mail.gmail.com>

On 3/20/18, Clem Cole <clemc at ccc.com> wrote:
>
> Paul can correct me, but I don't think DEC even developed a Pascal for TOPS
> originally - IIRC the one I used came from the universities.   I think the
> first Pascal sold was targeted for the VAX.  Also, RT11 and RSX were
> 'laboratory' systems and those systems were dominated by Fortran back in
> the day - so DEC marketing thought in those terms.
>
DEC did do a Pascal for RSX.  I don't remember if it supported RT11 or
RSTS.  DEC did a BASIC compiler for RSTS and RSX.  RSX and especially
RT were designed mainly for real-time process control in laboratories.
   A lot of the programming was in assembler for efficiency reasons
(both time and space).

-Paul W.


From clemc at ccc.com  Wed Mar 21 23:59:05 2018
From: clemc at ccc.com (Clem Cole)
Date: Wed, 21 Mar 2018 09:59:05 -0400
Subject: [TUHS] daemons are not to be exorcised
In-Reply-To: <20180321023125.GC6850@thunk.org>
References: <CAFCBnZsS8Si6YGD4w_3W_znf3J5nVZGThkHVuQm5nD+FFm0DOg@mail.gmail.com>
 <94366db0-293b-214a-23a3-c7c895e4d30b@spamtrap.tnetconsulting.net>
 <alpine.BSF.2.02.1803200023360.43136@frieza.hoshinet.org>
 <98451f10-9b1b-049b-61ed-fd73586572fd@spamtrap.tnetconsulting.net>
 <20180321023125.GC6850@thunk.org>
Message-ID: <CAC20D2PPP4pPfY7vQY23_ttfwRhK0t1-jP_vV=X_D=kL9zpkdQ@mail.gmail.com>

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>

From jnc at mercury.lcs.mit.edu  Thu Mar 22 00:17:53 2018
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Wed, 21 Mar 2018 10:17:53 -0400 (EDT)
Subject: [TUHS] daemons are not to be exorcised
Message-ID: <20180321141753.25C4418C088@mercury.lcs.mit.edu>

    > From: Larry McVoy <lm at mcvoy.com>

    > Going forward, I wish that people tried to be simple as they tackle the
    > more complicated problems we have.

I have a couple of relevant quotations on my 'Some Computer-Related Lines'
page:

  "Deliberate complexity is the mark of an amateur. Elegant simplicity is the
  mark of a master."
	-- Unknown, quoted by Robert A. Crawford 

  "Fools ignore complexity. Pragmatists suffer it. Some can avoid it. Geniuses
  remove it."
	-- Alan Perlis

  "The most reliable components are the ones you leave out." 
	-- Gordon Bell

(For software, the latter needs to be read as 'The most bug-free lines of
codqe are the ones you leave out', of course.)


I remember watching the people building the LISP machine, and thinking 'Wow,
that system is complex'. I eventually decided the problem was that they were
_too_ smart. They could understand, and retain in their minds, all that
complexity.

	Noel


From paul.winalski at gmail.com  Thu Mar 22 00:18:18 2018
From: paul.winalski at gmail.com (Paul Winalski)
Date: Wed, 21 Mar 2018 10:18:18 -0400
Subject: [TUHS] daemons are not to be exorcised
In-Reply-To: <CAC20D2PPP4pPfY7vQY23_ttfwRhK0t1-jP_vV=X_D=kL9zpkdQ@mail.gmail.com>
References: <CAFCBnZsS8Si6YGD4w_3W_znf3J5nVZGThkHVuQm5nD+FFm0DOg@mail.gmail.com>
 <94366db0-293b-214a-23a3-c7c895e4d30b@spamtrap.tnetconsulting.net>
 <alpine.BSF.2.02.1803200023360.43136@frieza.hoshinet.org>
 <98451f10-9b1b-049b-61ed-fd73586572fd@spamtrap.tnetconsulting.net>
 <20180321023125.GC6850@thunk.org>
 <CAC20D2PPP4pPfY7vQY23_ttfwRhK0t1-jP_vV=X_D=kL9zpkdQ@mail.gmail.com>
Message-ID: <CABH=_VS2H0NzwkKrL1mOQbrs0C87Q=c_6duuxspw9cRpLag-XQ@mail.gmail.com>

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.
>
I think a corollary of Albert Einstein's aphorism regarding theories
applies here: "Features should be as simple as possible, but no
simpler."

-Paul W.


From jnc at mercury.lcs.mit.edu  Thu Mar 22 00:51:41 2018
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Wed, 21 Mar 2018 10:51:41 -0400 (EDT)
Subject: [TUHS] FORTRAN
Message-ID: <20180321145141.EF02718C088@mercury.lcs.mit.edu>

    > From: "Steve Johnson"

So, I have this persistent memory that I read, in some early Multics (possibly
CTSS, but ISTR it was Multics) document, a footnote explaining the origin of
the term 'daemon'. I went looking for it, but couldn't find it in a 'quick'
scan.

I did find this, though, which is of some interest: R. A. Freiburghouse, "The
Multics PL/1 Compiler" (available online here:

  http://multicians.org/pl1-raf.html

if anyone is interested).

    > There was a group that was pushing the adoption of PL/1, being used to
    > code Multics, but the compiler was late and not very good and it never
    > really caught on.

So, in that I read:

  The entire compiler and the Multics operating system were written in EPL, a
  large subset of PL/1 ... The EPL compiler was built by a team headed by
  M. D. McIlroy and R. Morris ... Several members of the Multics PL/1 project
  modified the original EPL compiler to improve its object code performance,
  and utilized the knowledge acquired from this experience in the design of
  the Multics PL/1 compiler.

The EPL compiler was written when the _original_ PL/1 compiler (supposedly
being produced by a consulting company, Digitek) blew up. More detail is
available here:

  http://multicians.org/pl1.html

I assume it's the Digitek compiler you were thinking of above?

	Noel


From clemc at ccc.com  Thu Mar 22 01:03:13 2018
From: clemc at ccc.com (Clem Cole)
Date: Wed, 21 Mar 2018 11:03:13 -0400
Subject: [TUHS] daemons are not to be exorcised
In-Reply-To: <20180321141753.25C4418C088@mercury.lcs.mit.edu>
References: <20180321141753.25C4418C088@mercury.lcs.mit.edu>
Message-ID: <CAC20D2M6x5wn5_=HDWYsZyBqu_Ba58-oQ8Ca53XBmaRjS62=6Q@mail.gmail.com>

On Wed, Mar 21, 2018 at 10:17 AM, Noel Chiappa <jnc at mercury.lcs.mit.edu>
wrote:

>     > From: Larry McVoy <lm at mcvoy.com>
>
>     > Going forward, I wish that people tried to be simple as they tackle
> the
>     > more complicated problems we have.
>
> I have a couple of relevant quotations on my 'Some Computer-Related Lines'
> page:
>
>   "Deliberate complexity is the mark of an amateur. Elegant simplicity is
> the
>   mark of a master."
>         -- Unknown, quoted by Robert A. Crawford
>
>   "Fools ignore complexity. Pragmatists suffer it. Some can avoid it.
> Geniuses
>   remove it."
>         -- Alan Perlis
>
>   "The most reliable components are the ones you leave out."
>         -- Gordon Bell
>
> (For software, the latter needs to be read as 'The most bug-free lines of
> code are the ones you leave out', of course.)
>
​Amen...​




>
>
> I remember watching the people building the LISP machine, and thinking
> 'Wow,
> that system is complex'. I eventually decided the problem was that they
> were
> _too_ smart. They could understand, and retain in their minds, all that
> ​ ​
> complexity.

​And therein lies another interesting paradox... smart people don't always
realize that ​
​their being "smarter than the average bear" as it were, means mortals are
unlikely to be able to understand what you are doing.  Or more importantly,
your might not be that 'smart' later.

I'll never forget a conversation with one of my officemates at Masscomp who
had come from Steve Ward's group at MIT, who I will not name.  But he is
one the smartest people I ever worked with and someone I have tremendous
respect.   CMU used to have a required SW Engineering course and one of the
things drilled into us was commenting (you can usually tell code I worked
on by the dyslexia in my comments - but I do try to leave bit crumbs).​

Anyway, said person never had a such a course.  He says to me -- "Well I
only comment things I did not understand."   I looked at him in awe and
said:  "'Fred' -  you are one of the smartest people I know, please put the
comments in there for the rest of us."

A bit later, he got cut by his own sword.  He had had to pick up a piece of
code he had written a long time before and of course the context that he
had had when he wrote it was by that time completely lost.  Guess what - he
could not understand what the code was doing [BTW:  The last time I saw
something he wrote, he was wonderful at writing comments].

To me, "keep it short, simple, but always explain your intentions in prose"
need to be the guiding lights for programmers.

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

From imp at bsdimp.com  Thu Mar 22 01:15:32 2018
From: imp at bsdimp.com (Warner Losh)
Date: Wed, 21 Mar 2018 09:15:32 -0600
Subject: [TUHS] daemons are not to be exorcised
In-Reply-To: <CABH=_VS2H0NzwkKrL1mOQbrs0C87Q=c_6duuxspw9cRpLag-XQ@mail.gmail.com>
References: <CAFCBnZsS8Si6YGD4w_3W_znf3J5nVZGThkHVuQm5nD+FFm0DOg@mail.gmail.com>
 <94366db0-293b-214a-23a3-c7c895e4d30b@spamtrap.tnetconsulting.net>
 <alpine.BSF.2.02.1803200023360.43136@frieza.hoshinet.org>
 <98451f10-9b1b-049b-61ed-fd73586572fd@spamtrap.tnetconsulting.net>
 <20180321023125.GC6850@thunk.org>
 <CAC20D2PPP4pPfY7vQY23_ttfwRhK0t1-jP_vV=X_D=kL9zpkdQ@mail.gmail.com>
 <CABH=_VS2H0NzwkKrL1mOQbrs0C87Q=c_6duuxspw9cRpLag-XQ@mail.gmail.com>
Message-ID: <CANCZdfo6sPKxwC=qiFSBgJ51NEnTTWYO6qY=v5r2WmaZgpCKDg@mail.gmail.com>

On Wed, Mar 21, 2018 at 8:18 AM, Paul Winalski <paul.winalski at gmail.com>
wrote:

> 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.
> >
> I think a corollary of Albert Einstein's aphorism regarding theories
> applies here: "Features should be as simple as possible, but no
> simpler."
>

"Perfection is Achieved Not When There Is Nothing More to Add, But When
There Is Nothing Left to Take Away" Antoine de Saint-Exupery

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180321/17614ff9/attachment.html>

From akosela at andykosela.com  Thu Mar 22 01:45:27 2018
From: akosela at andykosela.com (Andy Kosela)
Date: Wed, 21 Mar 2018 10:45:27 -0500
Subject: [TUHS] daemons are not to be exorcised
In-Reply-To: <CANCZdfo6sPKxwC=qiFSBgJ51NEnTTWYO6qY=v5r2WmaZgpCKDg@mail.gmail.com>
References: <CAFCBnZsS8Si6YGD4w_3W_znf3J5nVZGThkHVuQm5nD+FFm0DOg@mail.gmail.com>
 <94366db0-293b-214a-23a3-c7c895e4d30b@spamtrap.tnetconsulting.net>
 <alpine.BSF.2.02.1803200023360.43136@frieza.hoshinet.org>
 <98451f10-9b1b-049b-61ed-fd73586572fd@spamtrap.tnetconsulting.net>
 <20180321023125.GC6850@thunk.org>
 <CAC20D2PPP4pPfY7vQY23_ttfwRhK0t1-jP_vV=X_D=kL9zpkdQ@mail.gmail.com>
 <CABH=_VS2H0NzwkKrL1mOQbrs0C87Q=c_6duuxspw9cRpLag-XQ@mail.gmail.com>
 <CANCZdfo6sPKxwC=qiFSBgJ51NEnTTWYO6qY=v5r2WmaZgpCKDg@mail.gmail.com>
Message-ID: <CALMnNGiKouKUX-Yc_K3sq9v=uMRE+ARV=fu_t5Xgdkk0YfbPiQ@mail.gmail.com>

On Wednesday, March 21, 2018, Warner Losh <imp at bsdimp.com> wrote:

>
>
> On Wed, Mar 21, 2018 at 8:18 AM, Paul Winalski <paul.winalski at gmail.com>
> wrote:
>
>> 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.
>> >
>> I think a corollary of Albert Einstein's aphorism regarding theories
>> applies here: "Features should be as simple as possible, but no
>> simpler."
>>
>
> "Perfection is Achieved Not When There Is Nothing More to Add, But When
> There Is Nothing Left to Take Away" Antoine de Saint-Exupery
>
>
There are two kinds of people in this world.  Those that think that adding
more is better (more is more approach), and those that think the complete
opposite (less is more approach).  The second type is usually associated
with minimalistic philosophy and approach to life.  I believe Ken and the
team were the masters of minimalism.

Today the only current OS that I can think of that still adores this
minimalistic approach is probably only OpenBSD.  Even its installer is as
minimal as you can get... I really like it.

--Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180321/91777e1e/attachment.html>

From imp at bsdimp.com  Thu Mar 22 01:49:45 2018
From: imp at bsdimp.com (Warner Losh)
Date: Wed, 21 Mar 2018 09:49:45 -0600
Subject: [TUHS] daemons are not to be exorcised
In-Reply-To: <CALMnNGiKouKUX-Yc_K3sq9v=uMRE+ARV=fu_t5Xgdkk0YfbPiQ@mail.gmail.com>
References: <CAFCBnZsS8Si6YGD4w_3W_znf3J5nVZGThkHVuQm5nD+FFm0DOg@mail.gmail.com>
 <94366db0-293b-214a-23a3-c7c895e4d30b@spamtrap.tnetconsulting.net>
 <alpine.BSF.2.02.1803200023360.43136@frieza.hoshinet.org>
 <98451f10-9b1b-049b-61ed-fd73586572fd@spamtrap.tnetconsulting.net>
 <20180321023125.GC6850@thunk.org>
 <CAC20D2PPP4pPfY7vQY23_ttfwRhK0t1-jP_vV=X_D=kL9zpkdQ@mail.gmail.com>
 <CABH=_VS2H0NzwkKrL1mOQbrs0C87Q=c_6duuxspw9cRpLag-XQ@mail.gmail.com>
 <CANCZdfo6sPKxwC=qiFSBgJ51NEnTTWYO6qY=v5r2WmaZgpCKDg@mail.gmail.com>
 <CALMnNGiKouKUX-Yc_K3sq9v=uMRE+ARV=fu_t5Xgdkk0YfbPiQ@mail.gmail.com>
Message-ID: <CANCZdfpYMQ6XgXohG6CRRQiZ1TMyorPe7moVXMgedM_unc37vg@mail.gmail.com>

On Wed, Mar 21, 2018 at 9:45 AM, Andy Kosela <akosela at andykosela.com> wrote:

>
>
> On Wednesday, March 21, 2018, Warner Losh <imp at bsdimp.com> wrote:
>
>>
>>
>> On Wed, Mar 21, 2018 at 8:18 AM, Paul Winalski <paul.winalski at gmail.com>
>> wrote:
>>
>>> 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.
>>> >
>>> I think a corollary of Albert Einstein's aphorism regarding theories
>>> applies here: "Features should be as simple as possible, but no
>>> simpler."
>>>
>>
>> "Perfection is Achieved Not When There Is Nothing More to Add, But When
>> There Is Nothing Left to Take Away" Antoine de Saint-Exupery
>>
>>
> There are two kinds of people in this world.  Those that think that adding
> more is better (more is more approach), and those that think the complete
> opposite (less is more approach).  The second type is usually associated
> with minimalistic philosophy and approach to life.  I believe Ken and the
> team were the masters of minimalism.
>
> Today the only current OS that I can think of that still adores this
> minimalistic approach is probably only OpenBSD.  Even its installer is as
> minimal as you can get... I really like it.
>

I'm not so sure about that. It's installer is minimal, but there's still
lots of bloat in it's kernel...

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

From krewat at kilonet.net  Thu Mar 22 02:18:21 2018
From: krewat at kilonet.net (Arthur Krewat)
Date: Wed, 21 Mar 2018 12:18:21 -0400
Subject: [TUHS] daemons are not to be exorcised
In-Reply-To: <CAC20D2M6x5wn5_=HDWYsZyBqu_Ba58-oQ8Ca53XBmaRjS62=6Q@mail.gmail.com>
References: <20180321141753.25C4418C088@mercury.lcs.mit.edu>
 <CAC20D2M6x5wn5_=HDWYsZyBqu_Ba58-oQ8Ca53XBmaRjS62=6Q@mail.gmail.com>
Message-ID: <6c6699c0-15db-604a-181c-7dad282599e1@kilonet.net>

On 3/21/2018 11:03 AM, Clem Cole wrote:
>
> To me, "keep it short, simple, but always explain your intentions in 
> prose" need to be the guiding lights for programmers.

It was instilled in me early on by my one and only mentor that someone 
that comes along later may have no idea what my code is doing. So 
comment. Even when it might be self-explanitory, comment anyway. This 
was on TOPS-10 back in the early 80's, usually MACRO-10 although I 
dabbled in ALGOL, SNOBOL, FORTRAN, etc.

When I look back at my own code, I can read the comments as the 
plot-line, so to speak, and the code itself just follows along.

I have noticed a lot of newer programmers these days that say 
(paraphrased): "Good code will explain itself" as a reason not to 
comment. Mostly C++ and Java programmers.

I call bullshit on that. Not commenting is lazy. There's no reason NOT 
to comment.

Most of my stuff has more comments byte-wise than real code. Something I 
wrote just yesterday as part of a much larger project:

// remove the UTF-8 BOM at the beginning of a line of text.
char bom[] = { 0xEF, 0xBB, 0xBF, 0 };                  // UTF-8 BOM
void remove_bom(char *str) {

     if (strncmp(str, bom, strlen(bom)) == 0) {         // can we find 
the BOM at the beginning of the line?
         strcpy(str, str + strlen(bom));             // yup, kill it.
     }
}

While that is definitely self-explanitory, I just can't help myself - 
and no, don't comment on my brazen assumptions of string length, or the 
fact that I assume it's UTF-8 - I've taken care of all of that 
elsewhere...  ;)

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

From paul.winalski at gmail.com  Thu Mar 22 03:28:34 2018
From: paul.winalski at gmail.com (Paul Winalski)
Date: Wed, 21 Mar 2018 13:28:34 -0400
Subject: [TUHS] daemons are not to be exorcised
In-Reply-To: <6c6699c0-15db-604a-181c-7dad282599e1@kilonet.net>
References: <20180321141753.25C4418C088@mercury.lcs.mit.edu>
 <CAC20D2M6x5wn5_=HDWYsZyBqu_Ba58-oQ8Ca53XBmaRjS62=6Q@mail.gmail.com>
 <6c6699c0-15db-604a-181c-7dad282599e1@kilonet.net>
Message-ID: <CABH=_VREt+Ay+T3wnGKvGyKn-7W7dn6K4vT7huBmX4a4GzjQKg@mail.gmail.com>

On 3/21/18, Arthur Krewat <krewat at kilonet.net> wrote:
>
> It was instilled in me early on by my one and only mentor that someone
> that comes along later may have no idea what my code is doing. So
> comment. Even when it might be self-explanitory, comment anyway.

In my 40-year career as a programmer, I've more than once had that
someone who comes along later be myself.

I also apply what I call the Bus Principle.  If you get hit by a bus
and killed, one of your colleagues is going to have to take over your
work.  Give them a fighting chance with code comments, and maybe even
a design document for large or complex things.

> I have noticed a lot of newer programmers these days that say
> (paraphrased): "Good code will explain itself" as a reason not to
> comment. Mostly C++ and Java programmers.
>
> I call bullshit on that. Not commenting is lazy. There's no reason NOT
> to comment.

Amen to that!  Good comments are one of the things that distinguishes
Software Engineering from mere programming.

-Paul W.


From ggm at algebras.org  Thu Mar 22 03:33:50 2018
From: ggm at algebras.org (George Michaelson)
Date: Wed, 21 Mar 2018 17:33:50 +0000
Subject: [TUHS] daemons are not to be exorcised
In-Reply-To: <CABH=_VREt+Ay+T3wnGKvGyKn-7W7dn6K4vT7huBmX4a4GzjQKg@mail.gmail.com>
References: <20180321141753.25C4418C088@mercury.lcs.mit.edu>
 <CAC20D2M6x5wn5_=HDWYsZyBqu_Ba58-oQ8Ca53XBmaRjS62=6Q@mail.gmail.com>
 <6c6699c0-15db-604a-181c-7dad282599e1@kilonet.net>
 <CABH=_VREt+Ay+T3wnGKvGyKn-7W7dn6K4vT7huBmX4a4GzjQKg@mail.gmail.com>
Message-ID: <CAKr6gn1StLgkPAt12PYCzmKde=J3gEo-MFVbmAb_XBvi8fCmUw@mail.gmail.com>

I think there's a middle ground. saying "this is a loop" is not
informative. saying "I did this as a loop because..." can be very
informative.

I think with short circuit evaluation and side-effects in C, this kind
of code is especially worth commenting: people need to remember the
right hand side of a complex set of expressions might actually not
have done anything.

Here at IETF a really cute corner-case of optimization-for-bug came
up. Somebody who thought they had worked out a given packet in UDP dns
messages always had a pair of specific chars 0x0c and 0xc0 in sequence
(or something) and coded for it, not realizing they were coding below
the outcome of a DNS label compression pattern which didn't always
hold. Sometimes, people code from faulty or incomplete information. So
this one, (for instance) would have been much better commented than
not.

It would have let the following people hit the coder with a thin whippy stick.

On Wed, Mar 21, 2018 at 5:28 PM, Paul Winalski <paul.winalski at gmail.com> wrote:
> On 3/21/18, Arthur Krewat <krewat at kilonet.net> wrote:
>>
>> It was instilled in me early on by my one and only mentor that someone
>> that comes along later may have no idea what my code is doing. So
>> comment. Even when it might be self-explanitory, comment anyway.
>
> In my 40-year career as a programmer, I've more than once had that
> someone who comes along later be myself.
>
> I also apply what I call the Bus Principle.  If you get hit by a bus
> and killed, one of your colleagues is going to have to take over your
> work.  Give them a fighting chance with code comments, and maybe even
> a design document for large or complex things.
>
>> I have noticed a lot of newer programmers these days that say
>> (paraphrased): "Good code will explain itself" as a reason not to
>> comment. Mostly C++ and Java programmers.
>>
>> I call bullshit on that. Not commenting is lazy. There's no reason NOT
>> to comment.
>
> Amen to that!  Good comments are one of the things that distinguishes
> Software Engineering from mere programming.
>
> -Paul W.


From lm at mcvoy.com  Thu Mar 22 03:34:03 2018
From: lm at mcvoy.com (Larry McVoy)
Date: Wed, 21 Mar 2018 10:34:03 -0700
Subject: [TUHS] daemons are not to be exorcised
In-Reply-To: <CABH=_VREt+Ay+T3wnGKvGyKn-7W7dn6K4vT7huBmX4a4GzjQKg@mail.gmail.com>
References: <20180321141753.25C4418C088@mercury.lcs.mit.edu>
 <CAC20D2M6x5wn5_=HDWYsZyBqu_Ba58-oQ8Ca53XBmaRjS62=6Q@mail.gmail.com>
 <6c6699c0-15db-604a-181c-7dad282599e1@kilonet.net>
 <CABH=_VREt+Ay+T3wnGKvGyKn-7W7dn6K4vT7huBmX4a4GzjQKg@mail.gmail.com>
Message-ID: <20180321173403.GD9739@mcvoy.com>

On Wed, Mar 21, 2018 at 01:28:34PM -0400, Paul Winalski wrote:
> On 3/21/18, Arthur Krewat <krewat at kilonet.net> wrote:
> >
> > It was instilled in me early on by my one and only mentor that someone
> > that comes along later may have no idea what my code is doing. So
> > comment. Even when it might be self-explanitory, comment anyway.
> 
> In my 40-year career as a programmer, I've more than once had that
> someone who comes along later be myself.

Yep.  Someone once told me "any code that you wrote more than 6 months
ago might as well have been written by someone else.  So write it in a
way that you can debug it".


From ches at cheswick.com  Thu Mar 22 03:39:17 2018
From: ches at cheswick.com (WIlliam Cheswick)
Date: Wed, 21 Mar 2018 13:39:17 -0400
Subject: [TUHS] daemons are not to be exorcised
In-Reply-To: <CABH=_VREt+Ay+T3wnGKvGyKn-7W7dn6K4vT7huBmX4a4GzjQKg@mail.gmail.com>
References: <20180321141753.25C4418C088@mercury.lcs.mit.edu>
 <CAC20D2M6x5wn5_=HDWYsZyBqu_Ba58-oQ8Ca53XBmaRjS62=6Q@mail.gmail.com>
 <6c6699c0-15db-604a-181c-7dad282599e1@kilonet.net>
 <CABH=_VREt+Ay+T3wnGKvGyKn-7W7dn6K4vT7huBmX4a4GzjQKg@mail.gmail.com>
Message-ID: <6DD0967F-D864-432B-A669-A2C51E03050D@cheswick.com>


> On Mar 21, 2018, at 1:28 PM, Paul Winalski <paul.winalski at gmail.com> wrote:
> 
> In my 40-year career as a programmer, I've more than once had that
> someone who comes along later be myself.

“Comments are love letters we write to our future selves.”
 - Jon Bentley

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

From krewat at kilonet.net  Thu Mar 22 03:50:43 2018
From: krewat at kilonet.net (Arthur Krewat)
Date: Wed, 21 Mar 2018 13:50:43 -0400
Subject: [TUHS] daemons are not to be exorcised
In-Reply-To: <CAKr6gn1StLgkPAt12PYCzmKde=J3gEo-MFVbmAb_XBvi8fCmUw@mail.gmail.com>
References: <20180321141753.25C4418C088@mercury.lcs.mit.edu>
 <CAC20D2M6x5wn5_=HDWYsZyBqu_Ba58-oQ8Ca53XBmaRjS62=6Q@mail.gmail.com>
 <6c6699c0-15db-604a-181c-7dad282599e1@kilonet.net>
 <CABH=_VREt+Ay+T3wnGKvGyKn-7W7dn6K4vT7huBmX4a4GzjQKg@mail.gmail.com>
 <CAKr6gn1StLgkPAt12PYCzmKde=J3gEo-MFVbmAb_XBvi8fCmUw@mail.gmail.com>
Message-ID: <5315f6af-c541-e2d5-588a-d5b7f95b479d@kilonet.net>

On 3/21/2018 1:33 PM, George Michaelson wrote:
> I think there's a middle ground. saying "this is a loop" is not
> informative. saying "I did this as a loop because..." can be very
> informative.
Absolutely. Using my "comments as the plot" analogy, that would be like 
the main character in a movie saying "this is a chair" instead of "this 
is my dad's chair".

So much more meaning ;)

And bringing it back to UNIX, I remember reading here on this list that 
comments were sanitized, removing any humor. Anyone got any good 
examples of that?




From krewat at kilonet.net  Thu Mar 22 03:52:01 2018
From: krewat at kilonet.net (Arthur Krewat)
Date: Wed, 21 Mar 2018 13:52:01 -0400
Subject: [TUHS] daemons are not to be exorcised
In-Reply-To: <6DD0967F-D864-432B-A669-A2C51E03050D@cheswick.com>
References: <20180321141753.25C4418C088@mercury.lcs.mit.edu>
 <CAC20D2M6x5wn5_=HDWYsZyBqu_Ba58-oQ8Ca53XBmaRjS62=6Q@mail.gmail.com>
 <6c6699c0-15db-604a-181c-7dad282599e1@kilonet.net>
 <CABH=_VREt+Ay+T3wnGKvGyKn-7W7dn6K4vT7huBmX4a4GzjQKg@mail.gmail.com>
 <6DD0967F-D864-432B-A669-A2C51E03050D@cheswick.com>
Message-ID: <b78c5aa4-6908-e201-e701-5ea16fb1abf6@kilonet.net>

On 3/21/2018 1:39 PM, WIlliam Cheswick wrote:
>
> “Comments are love letters we write to our future selves.”
>  - Jon Bentley

Truth be told, I sometimes get into a melancholy state, and go back to 
code I wrote decades ago just to go through the history section and 
remind myself why I got into this line of work in the first place.

ak


From cym224 at gmail.com  Thu Mar 22 03:56:38 2018
From: cym224 at gmail.com (Nemo)
Date: Wed, 21 Mar 2018 13:56:38 -0400
Subject: [TUHS] daemons are not to be exorcised
In-Reply-To: <CABH=_VREt+Ay+T3wnGKvGyKn-7W7dn6K4vT7huBmX4a4GzjQKg@mail.gmail.com>
References: <20180321141753.25C4418C088@mercury.lcs.mit.edu>
 <CAC20D2M6x5wn5_=HDWYsZyBqu_Ba58-oQ8Ca53XBmaRjS62=6Q@mail.gmail.com>
 <6c6699c0-15db-604a-181c-7dad282599e1@kilonet.net>
 <CABH=_VREt+Ay+T3wnGKvGyKn-7W7dn6K4vT7huBmX4a4GzjQKg@mail.gmail.com>
Message-ID: <CAJfiPzyoVoVGtFBBcnVCLfh7=qpgAVNBiDh9+KVoA2CRzmnBpw@mail.gmail.com>

On 21 March 2018 at 13:28, Paul Winalski <paul.winalski at gmail.com>
wrote (in part):
> I also apply what I call the Bus Principle.  If you get hit by a bus
> and killed, one of your colleagues is going to have to take over your
> work.  Give them a fighting chance with code comments, and maybe even
> a design document for large or complex things.

A manager insisted that everyone spend the last 15min of the day
writing down what was done that day on a sheet of paper and putting in
your desk drawer.  No one was run over by a bus but the paper became
the first thing many consulted next day (and the act of writing
consolidated thoughts -- something much lost today).

N.


From lm at mcvoy.com  Thu Mar 22 04:01:46 2018
From: lm at mcvoy.com (Larry McVoy)
Date: Wed, 21 Mar 2018 11:01:46 -0700
Subject: [TUHS] daemons are not to be exorcised
In-Reply-To: <CAJfiPzyoVoVGtFBBcnVCLfh7=qpgAVNBiDh9+KVoA2CRzmnBpw@mail.gmail.com>
References: <20180321141753.25C4418C088@mercury.lcs.mit.edu>
 <CAC20D2M6x5wn5_=HDWYsZyBqu_Ba58-oQ8Ca53XBmaRjS62=6Q@mail.gmail.com>
 <6c6699c0-15db-604a-181c-7dad282599e1@kilonet.net>
 <CABH=_VREt+Ay+T3wnGKvGyKn-7W7dn6K4vT7huBmX4a4GzjQKg@mail.gmail.com>
 <CAJfiPzyoVoVGtFBBcnVCLfh7=qpgAVNBiDh9+KVoA2CRzmnBpw@mail.gmail.com>
Message-ID: <20180321180146.GG9739@mcvoy.com>

On Wed, Mar 21, 2018 at 01:56:38PM -0400, Nemo wrote:
> On 21 March 2018 at 13:28, Paul Winalski <paul.winalski at gmail.com>
> wrote (in part):
> > I also apply what I call the Bus Principle.  If you get hit by a bus
> > and killed, one of your colleagues is going to have to take over your
> > work.  Give them a fighting chance with code comments, and maybe even
> > a design document for large or complex things.
> 
> A manager insisted that everyone spend the last 15min of the day
> writing down what was done that day on a sheet of paper and putting in
> your desk drawer.  No one was run over by a bus but the paper became
> the first thing many consulted next day (and the act of writing
> consolidated thoughts -- something much lost today).

I'd like a $repo/src/STATE file filled out at the end of my day.  Back in
the day I had a coworker that would do a 

	find /home/bk/lm -maxdepth 3 -name STATE -mtime -1

in the morning to see what I had been up to :)

The act of dumping what I was trying to do, what I had figured out so far,
just dumping state, frequently lead to the solution.  So it had the "bad"
effect of making me work longer to actually finish.

I've worked on problems in the kernel that were hard enough that it could
take me as much as 8 hours of thinking to get back to where I was yesterday.
The STATE file came out of that, it ramped me up faster.

--lm


From crossd at gmail.com  Thu Mar 22 04:04:05 2018
From: crossd at gmail.com (Dan Cross)
Date: Wed, 21 Mar 2018 14:04:05 -0400
Subject: [TUHS] daemons are not to be exorcised
In-Reply-To: <CABH=_VREt+Ay+T3wnGKvGyKn-7W7dn6K4vT7huBmX4a4GzjQKg@mail.gmail.com>
References: <20180321141753.25C4418C088@mercury.lcs.mit.edu>
 <CAC20D2M6x5wn5_=HDWYsZyBqu_Ba58-oQ8Ca53XBmaRjS62=6Q@mail.gmail.com>
 <6c6699c0-15db-604a-181c-7dad282599e1@kilonet.net>
 <CABH=_VREt+Ay+T3wnGKvGyKn-7W7dn6K4vT7huBmX4a4GzjQKg@mail.gmail.com>
Message-ID: <CAEoi9W6_-2HLs=ywM42OtOG00GeBd=c0odxXhtsDcZhKy-n4Ew@mail.gmail.com>

On Wed, Mar 21, 2018 at 1:28 PM, Paul Winalski <paul.winalski at gmail.com>
wrote:

> On 3/21/18, Arthur Krewat <krewat at kilonet.net> wrote:
> > [...]
> > I call bullshit on that. Not commenting is lazy. There's no reason NOT
> > to comment.
>
> Amen to that!  Good comments are one of the things that distinguishes
> Software Engineering from mere programming.


Critical to that, however, is the adjective "good", as in "good comments."
Writing comments can be incredibly useful, but writing *good* comments is a
learned skill that requires judgement and taste.

Much ado is made nowadays about the "craft" of programming. I dislike this
analogy for a number of reasons, but there's no denying that good
programming has a craft element to it, and I claim that good commenting is
one of the harder of the craft skills to master. In particular, there *are*
good reasons NOT to comment something: the code is so obvious the comment
would just be a restatement of the manifestly evident, but with the added
visual clutter and cognitive load imposed by simply existing and the added
maintenance burden of being kept in sync. When I see a comment, I often
take it as an indication that something notable is happening: if the
comment is superfluous then I'm left wondering WHY it's there and what
about the code I'm missing. Similarly, comments must be maintained: my
experience is that out-of-date comments that have fallen out of sync with
the code are strictly a liability. Finding balance between the costs of
commenting and the positive benefits of comments takes time to develop.

When I was younger, I dressed somewhat better than I do now and when I was
in the Marines I once found myself in a social situation where it made
sense to wear a tweed jacket. Another Marine introduced me to the concept
of, "always, sometimes, never" vis which of the three buttons on the front
of my jacket to button: top button always, middle button sometimes, bottom
button never (whether this is good fashion advice or not is another
matter). I think that something analogous is true of writing good comments:

1. A comment should never simply parrot the code:  i++;  // Increment i.
2. A comment should sometimes explain *what* the code is doing.
3. A comment should always explain *why* the code is doing what it's doing.

Note that these are specific to comments, not to code: it does not follow,
for example, that a line or stanza of code should always be adorned with a
comment explaining why it exists: (think, `i++;  // Increment the array
index for the next iteration of the loop.` Ugh).

Btw, this is something I think that Unix did very well.

        - Dan C.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180321/29852f97/attachment.html>

From paul.winalski at gmail.com  Thu Mar 22 05:37:41 2018
From: paul.winalski at gmail.com (Paul Winalski)
Date: Wed, 21 Mar 2018 15:37:41 -0400
Subject: [TUHS] daemons are not to be exorcised
In-Reply-To: <CAKr6gn1StLgkPAt12PYCzmKde=J3gEo-MFVbmAb_XBvi8fCmUw@mail.gmail.com>
References: <20180321141753.25C4418C088@mercury.lcs.mit.edu>
 <CAC20D2M6x5wn5_=HDWYsZyBqu_Ba58-oQ8Ca53XBmaRjS62=6Q@mail.gmail.com>
 <6c6699c0-15db-604a-181c-7dad282599e1@kilonet.net>
 <CABH=_VREt+Ay+T3wnGKvGyKn-7W7dn6K4vT7huBmX4a4GzjQKg@mail.gmail.com>
 <CAKr6gn1StLgkPAt12PYCzmKde=J3gEo-MFVbmAb_XBvi8fCmUw@mail.gmail.com>
Message-ID: <CABH=_VRuMGKfz-mZNWLMZEie52-XAXURkfR_sCSekuuxaKXzng@mail.gmail.com>

On 3/21/18, George Michaelson <ggm at algebras.org> wrote:
>
> I think with short circuit evaluation and side-effects in C, this kind
> of code is especially worth commenting: people need to remember the
> right hand side of a complex set of expressions might actually not
> have done anything.
>
One thing that is always worth a comment is Perl regular expressions.
A prose description of what the regex is supposed to match can save
someone else a lot of time.

-Paul W.


From a.phillip.garcia at gmail.com  Thu Mar 22 05:49:49 2018
From: a.phillip.garcia at gmail.com (A. P. Garcia)
Date: Wed, 21 Mar 2018 14:49:49 -0500
Subject: [TUHS] daemons are not to be exorcised
In-Reply-To: <5315f6af-c541-e2d5-588a-d5b7f95b479d@kilonet.net>
References: <20180321141753.25C4418C088@mercury.lcs.mit.edu>
 <CAC20D2M6x5wn5_=HDWYsZyBqu_Ba58-oQ8Ca53XBmaRjS62=6Q@mail.gmail.com>
 <6c6699c0-15db-604a-181c-7dad282599e1@kilonet.net>
 <CABH=_VREt+Ay+T3wnGKvGyKn-7W7dn6K4vT7huBmX4a4GzjQKg@mail.gmail.com>
 <CAKr6gn1StLgkPAt12PYCzmKde=J3gEo-MFVbmAb_XBvi8fCmUw@mail.gmail.com>
 <5315f6af-c541-e2d5-588a-d5b7f95b479d@kilonet.net>
Message-ID: <CAFCBnZvjk0Q4EewgkHDGH6fHTjtv-XC-iH1ieCohdqs4U=euNQ@mail.gmail.com>

On Mar 21, 2018 12:51 PM, "Arthur Krewat" <krewat at kilonet.net> wrote:

On 3/21/2018 1:33 PM, George Michaelson wrote:

> I think there's a middle ground. saying "this is a loop" is not
> informative. saying "I did this as a loop because..." can be very
> informative.
>
Absolutely. Using my "comments as the plot" analogy, that would be like the
main character in a movie saying "this is a chair" instead of "this is my
dad's chair".

So much more meaning ;)

And bringing it back to UNIX, I remember reading here on this list that
comments were sanitized, removing any humor. Anyone got any good examples
of that?


Well, I remember many years ago seeing a comment in the Linux kernel to the
effect that the kernel would never be larger than 2 MB IIRC. Which to me is
kind of humorous in retrospect.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180321/2a9bcb35/attachment.html>

From clemc at ccc.com  Thu Mar 22 05:56:57 2018
From: clemc at ccc.com (Clem Cole)
Date: Wed, 21 Mar 2018 15:56:57 -0400
Subject: [TUHS] daemons are not to be exorcised
In-Reply-To: <CAEoi9W6_-2HLs=ywM42OtOG00GeBd=c0odxXhtsDcZhKy-n4Ew@mail.gmail.com>
References: <20180321141753.25C4418C088@mercury.lcs.mit.edu>
 <CAC20D2M6x5wn5_=HDWYsZyBqu_Ba58-oQ8Ca53XBmaRjS62=6Q@mail.gmail.com>
 <6c6699c0-15db-604a-181c-7dad282599e1@kilonet.net>
 <CABH=_VREt+Ay+T3wnGKvGyKn-7W7dn6K4vT7huBmX4a4GzjQKg@mail.gmail.com>
 <CAEoi9W6_-2HLs=ywM42OtOG00GeBd=c0odxXhtsDcZhKy-n4Ew@mail.gmail.com>
Message-ID: <CAC20D2ORh+k9cBF1DgZ=A86YkrWKPtiNYzO=7MLz-=SNDTPEew@mail.gmail.com>

On Wed, Mar 21, 2018 at 2:04 PM, Dan Cross <crossd at gmail.com> wrote:

>
> Critical to that, however, is the adjective "good", as in "good comments."
> Writing comments can be incredibly useful, but writing *good* comments is a
> learned skill that requires judgement and taste.
>
> ​....​
>
> 1. A comment should never simply parrot the code:  i++;  // Increment i.
> 2. A comment should sometimes explain *what* the code is doing.
> 3. A comment should always explain *why* the code is doing what it's doing.
>

i.e. there is a difference between: ​       i++;  // Increment i
*v.s.* the line: ​                      ptr->field++;  // ensure
reference count
stays sane

The former fails your first test, the second follows 2 & 3 as a note to my
future self that this is where I am doing the this piece of support work
(reference count maintenance).


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

From earl.baugh at gmail.com  Thu Mar 22 06:04:04 2018
From: earl.baugh at gmail.com (Earl Baugh)
Date: Wed, 21 Mar 2018 16:04:04 -0400
Subject: [TUHS] comments ( was daemons exorcised )
In-Reply-To: <CAC20D2ORh+k9cBF1DgZ=A86YkrWKPtiNYzO=7MLz-=SNDTPEew@mail.gmail.com>
References: <20180321141753.25C4418C088@mercury.lcs.mit.edu>
 <CAC20D2M6x5wn5_=HDWYsZyBqu_Ba58-oQ8Ca53XBmaRjS62=6Q@mail.gmail.com>
 <6c6699c0-15db-604a-181c-7dad282599e1@kilonet.net>
 <CABH=_VREt+Ay+T3wnGKvGyKn-7W7dn6K4vT7huBmX4a4GzjQKg@mail.gmail.com>
 <CAEoi9W6_-2HLs=ywM42OtOG00GeBd=c0odxXhtsDcZhKy-n4Ew@mail.gmail.com>
 <CAC20D2ORh+k9cBF1DgZ=A86YkrWKPtiNYzO=7MLz-=SNDTPEew@mail.gmail.com>
Message-ID: <13FBBB55-93FA-49CF-9FEF-4F66A3611524@gmail.com>

I remember seeing a fortune or the like that said :

Documentation is like sex. When it’s good its very very good. When it’s  bad, it’s better than nothing. 

I found many times this rule applies to comments I’ve encountered in difficult code I’ve had the chore in debugging. :-) 

Earl 

Sent from my iPhone
> ᐧ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180321/fb6d6e79/attachment.html>

From paul.winalski at gmail.com  Thu Mar 22 06:13:42 2018
From: paul.winalski at gmail.com (Paul Winalski)
Date: Wed, 21 Mar 2018 16:13:42 -0400
Subject: [TUHS] daemons are not to be exorcised
In-Reply-To: <CAC20D2ORh+k9cBF1DgZ=A86YkrWKPtiNYzO=7MLz-=SNDTPEew@mail.gmail.com>
References: <20180321141753.25C4418C088@mercury.lcs.mit.edu>
 <CAC20D2M6x5wn5_=HDWYsZyBqu_Ba58-oQ8Ca53XBmaRjS62=6Q@mail.gmail.com>
 <6c6699c0-15db-604a-181c-7dad282599e1@kilonet.net>
 <CABH=_VREt+Ay+T3wnGKvGyKn-7W7dn6K4vT7huBmX4a4GzjQKg@mail.gmail.com>
 <CAEoi9W6_-2HLs=ywM42OtOG00GeBd=c0odxXhtsDcZhKy-n4Ew@mail.gmail.com>
 <CAC20D2ORh+k9cBF1DgZ=A86YkrWKPtiNYzO=7MLz-=SNDTPEew@mail.gmail.com>
Message-ID: <CABH=_VT+Pu=xZ=vk30Z3JrZN0cf=BG6hg7x++FTnb4iptzbNMw@mail.gmail.com>

Regarding comments, when I'm modifying code to fix a bug I find it
useful to insert a comment that references the bug's number in the bug
tracking system.  It can help answer the question "why is this code
here?" for someone reading the code later on, and sometimes it can
prevent regressions being introduced.

To bring this back to Unix, how well have the various commenting
principles we've been discussing been adhered to in the code base?

-Paul W.


From paul.winalski at gmail.com  Thu Mar 22 06:18:55 2018
From: paul.winalski at gmail.com (Paul Winalski)
Date: Wed, 21 Mar 2018 16:18:55 -0400
Subject: [TUHS] comments ( was daemons exorcised )
In-Reply-To: <13FBBB55-93FA-49CF-9FEF-4F66A3611524@gmail.com>
References: <20180321141753.25C4418C088@mercury.lcs.mit.edu>
 <CAC20D2M6x5wn5_=HDWYsZyBqu_Ba58-oQ8Ca53XBmaRjS62=6Q@mail.gmail.com>
 <6c6699c0-15db-604a-181c-7dad282599e1@kilonet.net>
 <CABH=_VREt+Ay+T3wnGKvGyKn-7W7dn6K4vT7huBmX4a4GzjQKg@mail.gmail.com>
 <CAEoi9W6_-2HLs=ywM42OtOG00GeBd=c0odxXhtsDcZhKy-n4Ew@mail.gmail.com>
 <CAC20D2ORh+k9cBF1DgZ=A86YkrWKPtiNYzO=7MLz-=SNDTPEew@mail.gmail.com>
 <13FBBB55-93FA-49CF-9FEF-4F66A3611524@gmail.com>
Message-ID: <CABH=_VTU+5DYiqpzv40EAL6G2wRefXp7Hgt=aS9h3Zi5unempA@mail.gmail.com>

A co-worker of mine once had a particularly nasty time debugging a
customer bug.  When he finally tracked down the faulty code, it was
preceded by a comment that said, "Someday someone will hate me for
this."

-Paul W.


From wkt at tuhs.org  Thu Mar 22 06:28:10 2018
From: wkt at tuhs.org (Warren Toomey)
Date: Thu, 22 Mar 2018 06:28:10 +1000
Subject: [TUHS] Comments in early Unix systems
In-Reply-To: <CABH=_VT+Pu=xZ=vk30Z3JrZN0cf=BG6hg7x++FTnb4iptzbNMw@mail.gmail.com>
References: <20180321141753.25C4418C088@mercury.lcs.mit.edu>
 <CAC20D2M6x5wn5_=HDWYsZyBqu_Ba58-oQ8Ca53XBmaRjS62=6Q@mail.gmail.com>
 <6c6699c0-15db-604a-181c-7dad282599e1@kilonet.net>
 <CABH=_VREt+Ay+T3wnGKvGyKn-7W7dn6K4vT7huBmX4a4GzjQKg@mail.gmail.com>
 <CAEoi9W6_-2HLs=ywM42OtOG00GeBd=c0odxXhtsDcZhKy-n4Ew@mail.gmail.com>
 <CAC20D2ORh+k9cBF1DgZ=A86YkrWKPtiNYzO=7MLz-=SNDTPEew@mail.gmail.com>
 <CABH=_VT+Pu=xZ=vk30Z3JrZN0cf=BG6hg7x++FTnb4iptzbNMw@mail.gmail.com>
Message-ID: <20180321202810.GA6280@minnie.tuhs.org>

On Wed, Mar 21, 2018 at 04:13:42PM -0400, Paul Winalski wrote:
>To bring this back to Unix, how well have the various commenting
>principles we've been discussing been adhered to in the code base?

This is something that has bugged me forever.

The Unix design is simple and elegant. The manuals are lucid and
understandable. However, there is next to no commenting in the
early code bases. Why? [and I know ken is reading this]

Given that the comments never made it into the compiled code, there
was no space reason to omit comments. There must have been another
reason.

Cheers, Warren


From ron at ronnatalie.com  Thu Mar 22 06:48:35 2018
From: ron at ronnatalie.com (Ron Natalie)
Date: Wed, 21 Mar 2018 16:48:35 -0400
Subject: [TUHS] Comments in early Unix systems
In-Reply-To: <20180321202810.GA6280@minnie.tuhs.org>
References: <20180321141753.25C4418C088@mercury.lcs.mit.edu>
 <CAC20D2M6x5wn5_=HDWYsZyBqu_Ba58-oQ8Ca53XBmaRjS62=6Q@mail.gmail.com>
 <6c6699c0-15db-604a-181c-7dad282599e1@kilonet.net>
 <CABH=_VREt+Ay+T3wnGKvGyKn-7W7dn6K4vT7huBmX4a4GzjQKg@mail.gmail.com>
 <CAEoi9W6_-2HLs=ywM42OtOG00GeBd=c0odxXhtsDcZhKy-n4Ew@mail.gmail.com>
 <CAC20D2ORh+k9cBF1DgZ=A86YkrWKPtiNYzO=7MLz-=SNDTPEew@mail.gmail.com>
 <CABH=_VT+Pu=xZ=vk30Z3JrZN0cf=BG6hg7x++FTnb4iptzbNMw@mail.gmail.com>
 <20180321202810.GA6280@minnie.tuhs.org>
Message-ID: <012b01d3c155$fb931e20$f2b95a60$@ronnatalie.com>

> Given that the comments never made it into the compiled code, there was no
space reason to omit comments. There must have been another reason.

Attitudes in software engineering have changed a lot over the 60 years we've
been programming.     Actually, UNIX was better than a lot of OS sources
I've dealt with.   Further, you had disk space and compile time issues to
worry about.

Amusingly, I worked with Mike Muuss for years (first at JHU and then at
BRL).   Mike believed much in putting comments on everything.    The DMR
"You're not expected to understand this" comment incensed him so much (yes I
know that's not what DMR meant) that he wrote an entire page to explain just
what retu/aretu/setka6 were doing there.

Amusingly, Mike was further incensed when Mike submitted a bunch of
revisions to BSD and McKusick, in the name of maintaining a uniform
commenting style, deleted all the comments.
I guess NONE is pretty consistent.

While this next anecdote strays from UNIX, I worked on a project my first
job out of college on a database system written in Fortran and Macro 11 on a
two-system RSX-11M+ system.    One of the early  projects there was to write
a program that counted "lines of code" to report to the customer progress or
something.     The head of software came up to the head database programmer
(not me) and said, "Do you know that we ran our line counter on your modules
and it said that there is only one line of comments in your entire module).
Jerry pointed out their software had to be in error, there weren't any lines
of comments.    In fact, a closer examination noted it counted one of the
MACRO-11 directives (.TITLE or something like that) as a comment.     In
Jerry's defense, there were comments in the code, just not lines that were
only comments.   They were just put at the end of the lines of existing
instructions.



From ron at ronnatalie.com  Thu Mar 22 06:51:28 2018
From: ron at ronnatalie.com (Ron Natalie)
Date: Wed, 21 Mar 2018 16:51:28 -0400
Subject: [TUHS] comments ( was daemons exorcised )
In-Reply-To: <CABH=_VTU+5DYiqpzv40EAL6G2wRefXp7Hgt=aS9h3Zi5unempA@mail.gmail.com>
References: <20180321141753.25C4418C088@mercury.lcs.mit.edu>
 <CAC20D2M6x5wn5_=HDWYsZyBqu_Ba58-oQ8Ca53XBmaRjS62=6Q@mail.gmail.com>
 <6c6699c0-15db-604a-181c-7dad282599e1@kilonet.net>
 <CABH=_VREt+Ay+T3wnGKvGyKn-7W7dn6K4vT7huBmX4a4GzjQKg@mail.gmail.com>
 <CAEoi9W6_-2HLs=ywM42OtOG00GeBd=c0odxXhtsDcZhKy-n4Ew@mail.gmail.com>
 <CAC20D2ORh+k9cBF1DgZ=A86YkrWKPtiNYzO=7MLz-=SNDTPEew@mail.gmail.com>
 <13FBBB55-93FA-49CF-9FEF-4F66A3611524@gmail.com>
 <CABH=_VTU+5DYiqpzv40EAL6G2wRefXp7Hgt=aS9h3Zi5unempA@mail.gmail.com>
Message-ID: <012d01d3c156$62ecca30$28c65e90$@ronnatalie.com>

Having been a supervisor of a large software package of which there were programmers of all skill levels I would periodically review the software.
Every once and a while I would note something that needed to be fixed by putting the comment "BOGUS" on that region.      Depending on out bad it was, the number of Os in BOGUS would increase.
My second-in-command realized this one section needed to be rewritten when it was marked BOOOOOOOOOOOOGUS.





From ron at ronnatalie.com  Thu Mar 22 06:55:01 2018
From: ron at ronnatalie.com (Ron Natalie)
Date: Wed, 21 Mar 2018 16:55:01 -0400
Subject: [TUHS] FORTRAN
In-Reply-To: <CABH=_VTx13un9KxJStZEoo46MBrPLQwkaT+QQ0XzD9KQkKMxhw@mail.gmail.com>
References: <CAC20D2P-dNX8AM_mh5N+Th-VYsG9COP8PX8QufLmFE2zh7MUqw@mail.gmail.com>
 <61051ebbca4809c08b60e92014851069e83a07f8@webmail.yaccman.com>
 <CAEoi9W6kLW5U-=kycN_8Orp228XZfFBv=88xzgam=76AWcJV3w@mail.gmail.com>
 <002f01d3c085$6b5a26d0$420e7470$@ronnatalie.com>
 <CAC20D2NNxp-3Qpw1=_3+3ZT6pk-b_answ88-KLZCw7j3gf7WOw@mail.gmail.com>
 <CABH=_VTx13un9KxJStZEoo46MBrPLQwkaT+QQ0XzD9KQkKMxhw@mail.gmail.com>
Message-ID: <012f01d3c156$e18bcc60$a4a36520$@ronnatalie.com>

>    DEC did a BASIC compiler for RSTS and RSX

BasicPlus was about the only good thing about RSTS.    In fact, we were allowed to replace the RSTS with UNIX at JHU if we could get BASIC PLUS ported over.
Fortunately, RSTS used EMT instructions for system calls (bizarre if you read the PDP-11 Processor Handbook) where as UNIX used the expected TRAP instruction.   All we had to do was add a "nostack" system call (I think we put it in, it might have already been there) to disable UNIX's idea of how a stack should work.




From ron at ronnatalie.com  Thu Mar 22 06:56:46 2018
From: ron at ronnatalie.com (Ron Natalie)
Date: Wed, 21 Mar 2018 16:56:46 -0400
Subject: [TUHS] FORTRAN
In-Reply-To: <20180321081042.GA7611@server.rulingia.com>
References: <CAC20D2P-dNX8AM_mh5N+Th-VYsG9COP8PX8QufLmFE2zh7MUqw@mail.gmail.com>
 <61051ebbca4809c08b60e92014851069e83a07f8@webmail.yaccman.com>
 <CAEoi9W6kLW5U-=kycN_8Orp228XZfFBv=88xzgam=76AWcJV3w@mail.gmail.com>
 <002f01d3c085$6b5a26d0$420e7470$@ronnatalie.com>
 <CABH=_VSjLP1XRVa6MG-q_nCyNRMqF8iKSrt8o5Tu-e+615zDMQ@mail.gmail.com>
 <20180321081042.GA7611@server.rulingia.com>
Message-ID: <013401d3c157$201db650$605922f0$@ronnatalie.com>



> Note that Pr1meOS was written in Fortran.  I did study it but no longer
recall what extensions it had to make that practical.

Prime was the company that tried to trademark English as the name of their
programming language, wasn't it?




From drb at msu.edu  Thu Mar 22 07:15:37 2018
From: drb at msu.edu (Dennis Boone)
Date: Wed, 21 Mar 2018 17:15:37 -0400
Subject: [TUHS] FORTRAN
In-Reply-To: (Your message of Wed, 21 Mar 2018 19:10:42 +1100.)
 <20180321081042.GA7611@server.rulingia.com>
References: <20180321081042.GA7611@server.rulingia.com>
 <CAC20D2P-dNX8AM_mh5N+Th-VYsG9COP8PX8QufLmFE2zh7MUqw@mail.gmail.com>
 <61051ebbca4809c08b60e92014851069e83a07f8@webmail.yaccman.com>
 <CAEoi9W6kLW5U-=kycN_8Orp228XZfFBv=88xzgam=76AWcJV3w@mail.gmail.com>
 <002f01d3c085$6b5a26d0$420e7470$@ronnatalie.com>
 <CABH=_VSjLP1XRVa6MG-q_nCyNRMqF8iKSrt8o5Tu-e+615zDMQ@mail.gmail.com>
Message-ID: <20180321211537.BFE39A58617@yagi.h-net.msu.edu>

 > >Yes, Fortran is as awful for system programming as C is for numeric
 > >programming that involves throwing multidimensional arrays around.

 > Note that Pr1meOS was written in Fortran.  I did study it but no
 > longer recall what extensions it had to make that practical.

It's just PRIMOS, no E.  And the '1' in place of 'i' thing was just a
marketing/logo gimmick.

Surprisingly few language extensions.  Octal constants (:1234567).  A
file inclusion facility ($INSERT FILE>PATH>XYZ.INS.FTN).  Not much else.

Originally, much of PRIMOS was in FORTRAN, with some assembler (PMA).
Later, significant rewrites and extensions were done in PL/1 derived
systems languages (PLP and SPL), and even later some in Modula.

Awfulness is relative.  Bill Poduska has said that writing most of the
system in a higher level language saved them a lot of time, over using
assembler.

De


From dave at horsfall.org  Thu Mar 22 07:52:13 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Thu, 22 Mar 2018 08:52:13 +1100 (EST)
Subject: [TUHS] Happy birthday, PDP-8!
Message-ID: <alpine.BSF.2.21.1803220840570.36168@aneurin.horsfall.org>

Let's see how much this thread can drift...

The venerable PDP-8 was introduced in 1965 today (or tomorrow if you're on 
the wrong side of the date line).  It was the first computer I ever used, 
back around 1970 (I think I'd just left school and was checking out the 
local University's computer department, and played with BASIC and FOCAL).

And (hopefully) coincidentally the Pentium first shipped in 1993; the 
infamous FDIV defect was discovered a year later (and it turned out that 
Intel was made aware of it by a post-grad student a bit earlier), and what 
followed next was an utter farce, with some dealers refusing to accept the 
results of a widely-distributed program as evidence of a faulty FPU.

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."


From charles.unix.pro at gmail.com  Thu Mar 22 07:57:59 2018
From: charles.unix.pro at gmail.com (Charles Anthony)
Date: Wed, 21 Mar 2018 14:57:59 -0700
Subject: [TUHS] FORTRAN
In-Reply-To: <20180321145141.EF02718C088@mercury.lcs.mit.edu>
References: <20180321145141.EF02718C088@mercury.lcs.mit.edu>
Message-ID: <CANV78LRPScZsTB5D8SRfuwp+5ChBs_vy_BjkWek2CPvDZmFQmg@mail.gmail.com>

On Wed, Mar 21, 2018 at 7:51 AM, Noel Chiappa <jnc at mercury.lcs.mit.edu>
wrote:

>     > From: "Steve Johnson"
>
> So, I have this persistent memory that I read, in some early Multics
> (possibly
> CTSS, but ISTR it was Multics) document, a footnote explaining the origin
> of
> the term 'daemon'. I went looking for it, but couldn't find it in a 'quick'
> scan.
>

>From multician.org: http://multicians.org/mgd.html:

" daemon

A beneficent spirit. A process, not associated with a human operator, that
runs all the time and waits for requests to do something for a user. This
term is respectable English; the application to computer processes is
usually credited to M. J. Bailey, working on the design of CTSS in the
early 60s.

[JHS] "I'm working from memory here, but I think this is the story.
Although the word 'process' wasn't in the vocabulary yet, we had just
figured out that what one would now call 'system processes' were a solution
to several problems, and we were looking for a good label for them. A
British gentleman named Michael (Mick) Bailey, working on the CTSS
programming staff at MIT, suggested the word 'daemon' and quoted the OED in
support of both the meaning and spelling. Bailey's etymology was so
impeccable that questions as to whether the spelling should be simplified
to 'demon' went on for only about 30 seconds. On both CTSS and Multics, the
documentation and the process names use the spelling 'daemon.' I suspect
that the date on the memo that first used the term would be in 1962 or
1963."(note to Kirk McKusick, 24 Aug 1988)"

-- Charles
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180321/0af1ebd2/attachment.html>

From ggm at algebras.org  Thu Mar 22 07:59:36 2018
From: ggm at algebras.org (George Michaelson)
Date: Wed, 21 Mar 2018 21:59:36 +0000
Subject: [TUHS] Happy birthday, PDP-8!
In-Reply-To: <alpine.BSF.2.21.1803220840570.36168@aneurin.horsfall.org>
References: <alpine.BSF.2.21.1803220840570.36168@aneurin.horsfall.org>
Message-ID: <CAKr6gn37tKHMOWEUqB6iHKos28zG0ucA9B0buSFzc=h=-f9nUQ@mail.gmail.com>

I briefly, at the age of 7 had a dual-processor cardboard pdp-8.

IFIP68 was held in edinburgh, and my dad was on the organizing
committee. So I got to go to the trade show alongside, and Dec had
cardboard 8's they handed out as a promotional freebie to anyone who
signed up.

I got two. But I'd had the wooden crate a PDP-1 came in for a backyard
tank before that so I was kinda- downsizing.

-G

On Wed, Mar 21, 2018 at 9:52 PM, Dave Horsfall <dave at horsfall.org> wrote:
> Let's see how much this thread can drift...
>
> The venerable PDP-8 was introduced in 1965 today (or tomorrow if you're on
> the wrong side of the date line).  It was the first computer I ever used,
> back around 1970 (I think I'd just left school and was checking out the
> local University's computer department, and played with BASIC and FOCAL).
>
> And (hopefully) coincidentally the Pentium first shipped in 1993; the
> infamous FDIV defect was discovered a year later (and it turned out that
> Intel was made aware of it by a post-grad student a bit earlier), and what
> followed next was an utter farce, with some dealers refusing to accept the
> results of a widely-distributed program as evidence of a faulty FPU.
>
> --
> Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will
> suffer."


From wlc at jctaylor.com  Thu Mar 22 08:18:49 2018
From: wlc at jctaylor.com (William Corcoran)
Date: Wed, 21 Mar 2018 22:18:49 +0000
Subject: [TUHS] Comments in early Unix systems
In-Reply-To: <20180321202810.GA6280@minnie.tuhs.org>
References: <20180321141753.25C4418C088@mercury.lcs.mit.edu>
 <CAC20D2M6x5wn5_=HDWYsZyBqu_Ba58-oQ8Ca53XBmaRjS62=6Q@mail.gmail.com>
 <6c6699c0-15db-604a-181c-7dad282599e1@kilonet.net>
 <CABH=_VREt+Ay+T3wnGKvGyKn-7W7dn6K4vT7huBmX4a4GzjQKg@mail.gmail.com>
 <CAEoi9W6_-2HLs=ywM42OtOG00GeBd=c0odxXhtsDcZhKy-n4Ew@mail.gmail.com>
 <CAC20D2ORh+k9cBF1DgZ=A86YkrWKPtiNYzO=7MLz-=SNDTPEew@mail.gmail.com>
 <CABH=_VT+Pu=xZ=vk30Z3JrZN0cf=BG6hg7x++FTnb4iptzbNMw@mail.gmail.com>
 <20180321202810.GA6280@minnie.tuhs.org>
Message-ID: <4ED5DE5D-B2FC-4018-B4A8-2639CDB2073E@jctaylor.com>

Along the same lines:  

As UNIX *transitioned from the relative safety of academia (V7) into the cold, cruel  corporate world (System V), was there a corresponding effort to maintain and protect the UNIX codebase into a unified master repository with SCCS, for example?  

Is there any chance of finding a publicly available UNIX archive that includes the corresponding SCCS data for UNIX---to the extent that SCCS deltas and PRS comments can be examined?   

Bill Corcoran 

(*) IMHO


On Mar 21, 2018, at 4:28 PM, Warren Toomey <wkt at tuhs.org> wrote:

. . . 

Given that the comments never made it into the compiled code, there
was no space reason to omit comments. There must have been another
reason.

Cheers, Warren



From reed at reedmedia.net  Thu Mar 22 08:35:49 2018
From: reed at reedmedia.net (Jeremy C. Reed)
Date: Wed, 21 Mar 2018 17:35:49 -0500 (CDT)
Subject: [TUHS] Happy 25th Birthday NetBSD!
Message-ID: <alpine.NEB.2.20.1803211456560.25928@t1.m.reedmedia.net>

Revision 1.1, Sun Mar 21 09:45:37 1993 UTC (25 years ago) by cgd 

http://cvsweb.netbsd.org/bsdweb.cgi/src/sbin/init/init.c?rev=1.1&content-type=text/x-cvsweb-markup&only_with_tag=MAIN

Today is commonly considered the birthday of NetBSD.

Theo told me (seven years ago) that he, cgd, and glass (and one other 
person) planned it within 30 minutes after discussing with the CSRG and 
BSDI guys in the hot tub at the Town & Country Resort in San Diego at 
the January 25-29 1993 USENIX conference. (Does anyone have more to 
share about this discussion?) Soon, cgd had setup a CVS repository 
(forked 386BSD with many patchkits) which was re-rolled a few times (due 
to corrupted CVS). (So maybe March 21 is later than the real birthday.)

As far as I know, it is the oldest continuously-maintained complete 
open source operating system. (It predates Slackware Linux, FreeBSD, 
and Debian Linux by some months.)

"NetBSD" wasn't mentioned by name in the April 19. 1993 release files 
(but was named in the announcement). 
ftp://ftp.netbsd.org/pub/NetBSD/misc/release/NetBSD/NetBSD-0.8

On April 28, the kernel was renamed to /netbsd, the boot loader 
identified it as NetBSD, and various references of 386BSD were changed 
to NetBSD.
https://github.com/NetBSD/src/commit/a477732ff85d5557eef2808b5cbf221f3c74553b
https://github.com/NetBSD/src/commit/446115f2d63299e52f34977fb4a88c289dcae92f


From clemc at ccc.com  Thu Mar 22 09:02:24 2018
From: clemc at ccc.com (Clem Cole)
Date: Wed, 21 Mar 2018 19:02:24 -0400
Subject: [TUHS] Comments in early Unix systems
In-Reply-To: <4ED5DE5D-B2FC-4018-B4A8-2639CDB2073E@jctaylor.com>
References: <20180321141753.25C4418C088@mercury.lcs.mit.edu>
 <CAC20D2M6x5wn5_=HDWYsZyBqu_Ba58-oQ8Ca53XBmaRjS62=6Q@mail.gmail.com>
 <6c6699c0-15db-604a-181c-7dad282599e1@kilonet.net>
 <CABH=_VREt+Ay+T3wnGKvGyKn-7W7dn6K4vT7huBmX4a4GzjQKg@mail.gmail.com>
 <CAEoi9W6_-2HLs=ywM42OtOG00GeBd=c0odxXhtsDcZhKy-n4Ew@mail.gmail.com>
 <CAC20D2ORh+k9cBF1DgZ=A86YkrWKPtiNYzO=7MLz-=SNDTPEew@mail.gmail.com>
 <CABH=_VT+Pu=xZ=vk30Z3JrZN0cf=BG6hg7x++FTnb4iptzbNMw@mail.gmail.com>
 <20180321202810.GA6280@minnie.tuhs.org>
 <4ED5DE5D-B2FC-4018-B4A8-2639CDB2073E@jctaylor.com>
Message-ID: <CAC20D2OyW9iJYCC35DBrWB0YP_2rf+i9UN+Ko1QeQNJ4X8yJwA@mail.gmail.com>

On Wed, Mar 21, 2018 at 6:18 PM, William Corcoran <wlc at jctaylor.com> wrote:

> Along the same lines:
> ​...
>
> Is there any chance of finding a publicly available UNIX archive that
> includes the corresponding SCCS data for UNIX---to the extent that SCCS
> deltas and PRS comments can be examined?
>
>
Bill check out Diomidis Spinellis truely amazing work at:
https://github.com/dspinellis/unix-history-repo

​He has done an amazing job of reconstructing much of the lost work.  It is
a treasure for us all.

Clem​


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

From bqt at update.uu.se  Thu Mar 22 08:58:51 2018
From: bqt at update.uu.se (Johnny Billquist)
Date: Wed, 21 Mar 2018 23:58:51 +0100
Subject: [TUHS] FORTRAN
In-Reply-To: <mailman.48.1521640130.3788.tuhs@minnie.tuhs.org>
References: <mailman.48.1521640130.3788.tuhs@minnie.tuhs.org>
Message-ID: <c55cef95-17de-7398-a0bc-dbce17228d49@update.uu.se>

On 2018-03-21 14:48, Paul Winalski<paul.winalski at gmail.com> wrote:
> 
> On 3/20/18, Clem Cole<clemc at ccc.com>  wrote:
>> Paul can correct me, but I don't think DEC even developed a Pascal for TOPS
>> originally - IIRC the one I used came from the universities.   I think the
>> first Pascal sold was targeted for the VAX.  Also, RT11 and RSX were
>> 'laboratory' systems and those systems were dominated by Fortran back in
>> the day - so DEC marketing thought in those terms.
>>
> DEC did do a Pascal for RSX.  I don't remember if it supported RT11 or
> RSTS.  DEC did a BASIC compiler for RSTS and RSX.  RSX and especially
> RT were designed mainly for real-time process control in laboratories.

DEC did both COBOL, DIBOL, PASCAL, FORTRAN (-IV, -IV-PLUS, -77), C as 
well as Datatrieve for RSX and RSTS/E. Some of these were also available 
for RT-11. Admittedly, the C compiler was very late to the game.

>     A lot of the programming was in assembler for efficiency reasons
> (both time and space).

Yes. And MACRO-11 is pretty nice.

   Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt at softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol


From krewat at kilonet.net  Thu Mar 22 09:17:11 2018
From: krewat at kilonet.net (Arthur Krewat)
Date: Wed, 21 Mar 2018 19:17:11 -0400
Subject: [TUHS] Comments in early Unix systems
In-Reply-To: <4ED5DE5D-B2FC-4018-B4A8-2639CDB2073E@jctaylor.com>
References: <20180321141753.25C4418C088@mercury.lcs.mit.edu>
 <CAC20D2M6x5wn5_=HDWYsZyBqu_Ba58-oQ8Ca53XBmaRjS62=6Q@mail.gmail.com>
 <6c6699c0-15db-604a-181c-7dad282599e1@kilonet.net>
 <CABH=_VREt+Ay+T3wnGKvGyKn-7W7dn6K4vT7huBmX4a4GzjQKg@mail.gmail.com>
 <CAEoi9W6_-2HLs=ywM42OtOG00GeBd=c0odxXhtsDcZhKy-n4Ew@mail.gmail.com>
 <CAC20D2ORh+k9cBF1DgZ=A86YkrWKPtiNYzO=7MLz-=SNDTPEew@mail.gmail.com>
 <CABH=_VT+Pu=xZ=vk30Z3JrZN0cf=BG6hg7x++FTnb4iptzbNMw@mail.gmail.com>
 <20180321202810.GA6280@minnie.tuhs.org>
 <4ED5DE5D-B2FC-4018-B4A8-2639CDB2073E@jctaylor.com>
Message-ID: <394bc27c-8dff-03e1-9e13-9536a4ba195f@kilonet.net>

On 3/21/2018 6:18 PM, William Corcoran wrote:
> Given that the comments never made it into the compiled code, there
> was no space reason to omit comments. There must have been another
> reason.

I used to regularly compress sources of various distributions (not UNIX, 
but inn, pine, elm, etc) that I compiled, just to save space.

And that was in the early 90's when I could buy a 1GB SCSI drive for 
$1000. I can't imagine working off of the early hard drives...

ak


From imp at bsdimp.com  Thu Mar 22 09:45:16 2018
From: imp at bsdimp.com (Warner Losh)
Date: Wed, 21 Mar 2018 17:45:16 -0600
Subject: [TUHS] Comments in early Unix systems
In-Reply-To: <20180321202810.GA6280@minnie.tuhs.org>
References: <20180321141753.25C4418C088@mercury.lcs.mit.edu>
 <CAC20D2M6x5wn5_=HDWYsZyBqu_Ba58-oQ8Ca53XBmaRjS62=6Q@mail.gmail.com>
 <6c6699c0-15db-604a-181c-7dad282599e1@kilonet.net>
 <CABH=_VREt+Ay+T3wnGKvGyKn-7W7dn6K4vT7huBmX4a4GzjQKg@mail.gmail.com>
 <CAEoi9W6_-2HLs=ywM42OtOG00GeBd=c0odxXhtsDcZhKy-n4Ew@mail.gmail.com>
 <CAC20D2ORh+k9cBF1DgZ=A86YkrWKPtiNYzO=7MLz-=SNDTPEew@mail.gmail.com>
 <CABH=_VT+Pu=xZ=vk30Z3JrZN0cf=BG6hg7x++FTnb4iptzbNMw@mail.gmail.com>
 <20180321202810.GA6280@minnie.tuhs.org>
Message-ID: <CANCZdfoNecBZHVBXrEUfbj1MpxAfbQ0+=TUMGyNiqUtb7qt9NA@mail.gmail.com>

On Wed, Mar 21, 2018 at 2:28 PM, Warren Toomey <wkt at tuhs.org> wrote:

> On Wed, Mar 21, 2018 at 04:13:42PM -0400, Paul Winalski wrote:
>
>> To bring this back to Unix, how well have the various commenting
>> principles we've been discussing been adhered to in the code base?
>>
>
> This is something that has bugged me forever.
>
> The Unix design is simple and elegant. The manuals are lucid and
> understandable. However, there is next to no commenting in the
> early code bases. Why? [and I know ken is reading this]
>
> Given that the comments never made it into the compiled code, there
> was no space reason to omit comments. There must have been another
> reason.
>

I was told in school (in 1985) that if I was ever lucky enough to have
access to the unix source, I'd find there were no comments. The reason, I
was told at the time, was that comments would make the source code useful,
and selling software was something AT&T couldn't do due to some consent
decree. I've never been able to verify this story, but it came from someone
who started with v5. Sadly, he passed away 15 years ago, or I'd just ask
him again...

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180321/33017e3a/attachment.html>

From lm at mcvoy.com  Thu Mar 22 09:50:33 2018
From: lm at mcvoy.com (Larry McVoy)
Date: Wed, 21 Mar 2018 16:50:33 -0700
Subject: [TUHS] Comments in early Unix systems
In-Reply-To: <394bc27c-8dff-03e1-9e13-9536a4ba195f@kilonet.net>
References: <20180321141753.25C4418C088@mercury.lcs.mit.edu>
 <CAC20D2M6x5wn5_=HDWYsZyBqu_Ba58-oQ8Ca53XBmaRjS62=6Q@mail.gmail.com>
 <6c6699c0-15db-604a-181c-7dad282599e1@kilonet.net>
 <CABH=_VREt+Ay+T3wnGKvGyKn-7W7dn6K4vT7huBmX4a4GzjQKg@mail.gmail.com>
 <CAEoi9W6_-2HLs=ywM42OtOG00GeBd=c0odxXhtsDcZhKy-n4Ew@mail.gmail.com>
 <CAC20D2ORh+k9cBF1DgZ=A86YkrWKPtiNYzO=7MLz-=SNDTPEew@mail.gmail.com>
 <CABH=_VT+Pu=xZ=vk30Z3JrZN0cf=BG6hg7x++FTnb4iptzbNMw@mail.gmail.com>
 <20180321202810.GA6280@minnie.tuhs.org>
 <4ED5DE5D-B2FC-4018-B4A8-2639CDB2073E@jctaylor.com>
 <394bc27c-8dff-03e1-9e13-9536a4ba195f@kilonet.net>
Message-ID: <20180321235033.GJ9739@mcvoy.com>

On Wed, Mar 21, 2018 at 07:17:11PM -0400, Arthur Krewat wrote:
> I used to regularly compress sources of various distributions (not UNIX, but
> inn, pine, elm, etc) that I compiled, just to save space.
> 
> And that was in the early 90's when I could buy a 1GB SCSI drive for $1000.
> I can't imagine working off of the early hard drives...

I was sys admin for a Masscomp with a 40MB disk and 20 users.  That
was, um, "fun".


From gtaylor at tnetconsulting.net  Thu Mar 22 10:18:37 2018
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Wed, 21 Mar 2018 18:18:37 -0600
Subject: [TUHS] daemons are not to be exorcised
In-Reply-To: <76E7D09E-023B-4A29-ACCD-AF9ED425EE5F@xs4all.nl>
References: <CAFCBnZsS8Si6YGD4w_3W_znf3J5nVZGThkHVuQm5nD+FFm0DOg@mail.gmail.com>
 <94366db0-293b-214a-23a3-c7c895e4d30b@spamtrap.tnetconsulting.net>
 <alpine.BSF.2.02.1803200023360.43136@frieza.hoshinet.org>
 <98451f10-9b1b-049b-61ed-fd73586572fd@spamtrap.tnetconsulting.net>
 <20180321023125.GC6850@thunk.org>
 <76E7D09E-023B-4A29-ACCD-AF9ED425EE5F@xs4all.nl>
Message-ID: <e38e9935-8633-2cee-8cae-c5e8be180966@spamtrap.tnetconsulting.net>

On 03/21/2018 03:16 AM, Jaap Akkerhuis wrote:
> I've been told that syslog was came in existence as a debugging aid for 
> sendmai.

I can't prove to the contrary.  But that does seem a little extreme to me.



-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3982 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180321/e4dc0e27/attachment.bin>

From lm at mcvoy.com  Thu Mar 22 10:22:46 2018
From: lm at mcvoy.com (Larry McVoy)
Date: Wed, 21 Mar 2018 17:22:46 -0700
Subject: [TUHS] daemons are not to be exorcised
In-Reply-To: <e38e9935-8633-2cee-8cae-c5e8be180966@spamtrap.tnetconsulting.net>
References: <CAFCBnZsS8Si6YGD4w_3W_znf3J5nVZGThkHVuQm5nD+FFm0DOg@mail.gmail.com>
 <94366db0-293b-214a-23a3-c7c895e4d30b@spamtrap.tnetconsulting.net>
 <alpine.BSF.2.02.1803200023360.43136@frieza.hoshinet.org>
 <98451f10-9b1b-049b-61ed-fd73586572fd@spamtrap.tnetconsulting.net>
 <20180321023125.GC6850@thunk.org>
 <76E7D09E-023B-4A29-ACCD-AF9ED425EE5F@xs4all.nl>
 <e38e9935-8633-2cee-8cae-c5e8be180966@spamtrap.tnetconsulting.net>
Message-ID: <20180322002246.GK9739@mcvoy.com>

On Wed, Mar 21, 2018 at 06:18:37PM -0600, Grant Taylor via TUHS wrote:
> On 03/21/2018 03:16 AM, Jaap Akkerhuis wrote:
> >I've been told that syslog was came in existence as a debugging aid for
> >sendmai.
> 
> I can't prove to the contrary.  But that does seem a little extreme to me.

For what it is worth, the syslog/sendmail connection rings a tiny bell for
me, I can't prove it either, but I feel like there was some connection.
Is Eric on the list?


From gtaylor at tnetconsulting.net  Thu Mar 22 10:28:15 2018
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Wed, 21 Mar 2018 18:28:15 -0600
Subject: [TUHS] daemons are not to be exorcised
In-Reply-To: <CAC20D2PPP4pPfY7vQY23_ttfwRhK0t1-jP_vV=X_D=kL9zpkdQ@mail.gmail.com>
References: <CAFCBnZsS8Si6YGD4w_3W_znf3J5nVZGThkHVuQm5nD+FFm0DOg@mail.gmail.com>
 <94366db0-293b-214a-23a3-c7c895e4d30b@spamtrap.tnetconsulting.net>
 <alpine.BSF.2.02.1803200023360.43136@frieza.hoshinet.org>
 <98451f10-9b1b-049b-61ed-fd73586572fd@spamtrap.tnetconsulting.net>
 <20180321023125.GC6850@thunk.org>
 <CAC20D2PPP4pPfY7vQY23_ttfwRhK0t1-jP_vV=X_D=kL9zpkdQ@mail.gmail.com>
Message-ID: <ff0e9915-2b6e-0290-85d7-d53cc7efbe36@spamtrap.tnetconsulting.net>

On 03/21/2018 07:59 AM, Clem Cole wrote:
> 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.'

I suspect the container / lightweight VM movement will help with some of 
this.

People are learning the value of smaller, easier to maintain containers 
/ VMs.  Granted, containers are multi-OS and not just unix.



-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3982 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180321/8d8031df/attachment.bin>

From akosela at andykosela.com  Thu Mar 22 10:30:22 2018
From: akosela at andykosela.com (Andy Kosela)
Date: Wed, 21 Mar 2018 19:30:22 -0500
Subject: [TUHS] Happy 25th Birthday NetBSD!
In-Reply-To: <alpine.NEB.2.20.1803211456560.25928@t1.m.reedmedia.net>
References: <alpine.NEB.2.20.1803211456560.25928@t1.m.reedmedia.net>
Message-ID: <CALMnNGgCSUpakX0MVQ5nMmZY2doje-zKhWisiLCxbXEO3Swq2A@mail.gmail.com>

On Wednesday, March 21, 2018, Jeremy C. Reed <reed at reedmedia.net> wrote:

> Revision 1.1, Sun Mar 21 09:45:37 1993 UTC (25 years ago) by cgd
>
> http://cvsweb.netbsd.org/bsdweb.cgi/src/sbin/init/init.
> c?rev=1.1&content-type=text/x-cvsweb-markup&only_with_tag=MAIN
>
> Today is commonly considered the birthday of NetBSD.
>
> Theo told me (seven years ago) that he, cgd, and glass (and one other
> person) planned it within 30 minutes after discussing with the CSRG and
> BSDI guys in the hot tub at the Town & Country Resort in San Diego at
> the January 25-29 1993 USENIX conference. (Does anyone have more to
> share about this discussion?) Soon, cgd had setup a CVS repository
> (forked 386BSD with many patchkits) which was re-rolled a few times (due
> to corrupted CVS). (So maybe March 21 is later than the real birthday.)
>
> As far as I know, it is the oldest continuously-maintained complete
> open source operating system. (It predates Slackware Linux, FreeBSD,
> and Debian Linux by some months.)
>
>
Speaking about NetBSD anyone know what Chris Demetriou is doing these
days?  He has not been very active in the community for the last 20 years
or so.  Last I heard he was working for Broadcom, but that was 18 years
ago...

--Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180321/7648324a/attachment.html>

From scj at yaccman.com  Thu Mar 22 10:31:18 2018
From: scj at yaccman.com (Steve Johnson)
Date: Wed, 21 Mar 2018 17:31:18 -0700
Subject: [TUHS] Comments in early Unix systems
In-Reply-To: <CANCZdfoNecBZHVBXrEUfbj1MpxAfbQ0+=TUMGyNiqUtb7qt9NA@mail.gmail.com>
Message-ID: <7a11bdbf519e37dfaa876883722d90ea49a19c5a@webmail.yaccman.com>



"I was told in school (in 1985) that if I was ever lucky enough to
have access to the unix source, I'd find there were no comments. The
reason, I was told at the time, was that comments would make the
source code useful, and selling software was something AT&T couldn't
do due to some consent decree. I've never been able to verify this
story, but it came from someone who started with v5. Sadly, he passed
away 15 years ago, or I'd just ask him again..."

Ah, the consent decree.   The basic idea of the consent decree was
to prevent AT&T's regulated monopoly from giving it an unfair
advantage in other areas.   And, since the regulation guaranteed a
rate of return, certain restrictions were put on the ability of AT&T
to do business outside of the telephone arena.  In particular, one
requirement was that AT&T MUST patent anything they did that was
patentable.  And furthermore, they must license that patent to all
comers at a "reasonable" rate.

The decree was signed in 1956.   And then, along came software! 
AT&T foundi itself required to patent software inventions at a time
that nobody was sure what that meant, or whether software was even
patentable.  There were some very strange patents, or at least patent
applications, that came out of this.  I remember an algorithm for
generating permutations that was recast as a relay computer because
that was probably patenable and, if so, AT&T had to do it.  

Also, the mindset of AT&T was to plan in 20 year timescales, and they
had trouble understanding the increasing speed of software
innovation.  The patent department's attitude about a lot of the
issues of Unix licensing, etc., was basically to wait 5 years until
there was some precedent before acting.  Meanwhile, when they took an
interest they would issue some directive, often to reverse themselves
several months later.  I remember before one of the releases we had
to make sure we had a copyright notice on every file, only to be told
six months later to make sure that we removed all copyright notices
from all files.

One run-in that I had with the legal team happened just as Unix and C
were beginning to become popular, and some new C compilers were
appearing.  I made a strong appeal, with the support of my
management, to release the front end of PCC (or at least the Yacc
grammar for C) into the public domain, to try to encourage some
consistency in what we intended to be a portable language.  Meetings
dragged on for months, and we were finally told no.   I don't know
whether, had I been successfu, we could have avoided all the ANSI /
Posix confusion that came later, or at least limit the number of
incompatibilities that rapidly appeared in "C" compilers.  But it
might have helped...

Steve


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

From mike.ab3ap at gmail.com  Thu Mar 22 10:55:44 2018
From: mike.ab3ap at gmail.com (Mike Markowski)
Date: Wed, 21 Mar 2018 20:55:44 -0400
Subject: [TUHS] Comments in early Unix systems
In-Reply-To: <20180321235033.GJ9739@mcvoy.com>
References: <20180321141753.25C4418C088@mercury.lcs.mit.edu>
 <CAC20D2M6x5wn5_=HDWYsZyBqu_Ba58-oQ8Ca53XBmaRjS62=6Q@mail.gmail.com>
 <6c6699c0-15db-604a-181c-7dad282599e1@kilonet.net>
 <CABH=_VREt+Ay+T3wnGKvGyKn-7W7dn6K4vT7huBmX4a4GzjQKg@mail.gmail.com>
 <CAEoi9W6_-2HLs=ywM42OtOG00GeBd=c0odxXhtsDcZhKy-n4Ew@mail.gmail.com>
 <CAC20D2ORh+k9cBF1DgZ=A86YkrWKPtiNYzO=7MLz-=SNDTPEew@mail.gmail.com>
 <CABH=_VT+Pu=xZ=vk30Z3JrZN0cf=BG6hg7x++FTnb4iptzbNMw@mail.gmail.com>
 <20180321202810.GA6280@minnie.tuhs.org>
 <4ED5DE5D-B2FC-4018-B4A8-2639CDB2073E@jctaylor.com>
 <394bc27c-8dff-03e1-9e13-9536a4ba195f@kilonet.net>
 <20180321235033.GJ9739@mcvoy.com>
Message-ID: <dbf048a5-374a-b08b-21ce-f67ed46264ef@gmail.com>

On 03/21/2018 07:50 PM, Larry McVoy wrote:
> On Wed, Mar 21, 2018 at 07:17:11PM -0400, Arthur Krewat wrote:
>> I used to regularly compress sources of various distributions (not UNIX, but
>> inn, pine, elm, etc) that I compiled, just to save space.
>>
>> And that was in the early 90's when I could buy a 1GB SCSI drive for $1000.
>> I can't imagine working off of the early hard drives...
> 
> I was sys admin for a Masscomp with a 40MB disk and 20 users.  That
> was, um, "fun".

I remember Masscomp...  We used one (I forget model) in the field in the 
late 80s in the back of a tractor trailer.  We'd capture radar signals 
with it because it allowed data acquisition to not be swapped out.  It 
was a very expensive failure if, just as you started getting the short 
radar return, something like system logging swapped you out for a little!

Mike Markowski


From akosela at andykosela.com  Thu Mar 22 10:58:11 2018
From: akosela at andykosela.com (Andy Kosela)
Date: Wed, 21 Mar 2018 19:58:11 -0500
Subject: [TUHS] Comments in early Unix systems
In-Reply-To: <20180321202810.GA6280@minnie.tuhs.org>
References: <20180321141753.25C4418C088@mercury.lcs.mit.edu>
 <CAC20D2M6x5wn5_=HDWYsZyBqu_Ba58-oQ8Ca53XBmaRjS62=6Q@mail.gmail.com>
 <6c6699c0-15db-604a-181c-7dad282599e1@kilonet.net>
 <CABH=_VREt+Ay+T3wnGKvGyKn-7W7dn6K4vT7huBmX4a4GzjQKg@mail.gmail.com>
 <CAEoi9W6_-2HLs=ywM42OtOG00GeBd=c0odxXhtsDcZhKy-n4Ew@mail.gmail.com>
 <CAC20D2ORh+k9cBF1DgZ=A86YkrWKPtiNYzO=7MLz-=SNDTPEew@mail.gmail.com>
 <CABH=_VT+Pu=xZ=vk30Z3JrZN0cf=BG6hg7x++FTnb4iptzbNMw@mail.gmail.com>
 <20180321202810.GA6280@minnie.tuhs.org>
Message-ID: <CALMnNGhD_3CbGaKx0_U0Hcbjq0E6Edecs39F0ZuWH-xys8gAcQ@mail.gmail.com>

On Wednesday, March 21, 2018, Warren Toomey <wkt at tuhs.org> wrote:

> On Wed, Mar 21, 2018 at 04:13:42PM -0400, Paul Winalski wrote:
>
>> To bring this back to Unix, how well have the various commenting
>> principles we've been discussing been adhered to in the code base?
>>
>
> This is something that has bugged me forever.
>
> The Unix design is simple and elegant. The manuals are lucid and
> understandable. However, there is next to no commenting in the
> early code bases. Why? [and I know ken is reading this]
>
> Given that the comments never made it into the compiled code, there
> was no space reason to omit comments. There must have been another
> reason.
>
>
I think some answers could be find in "Practice of Programming" by Rob Pike
and Brian Kernighan.  In the section about comments they express why they
are not big fans of verbose commenting style.

They also state: "Comments are meant to help the reader of a program.  They
do not help by saying things the code already plainly says, or by
contradicting the code, or by distracting the reader with elaborate
typographical displays.  The best comments aid the understanding of a
program by briefly pointing out salient details or by providing a
larger-scale view of the proceedings."

--Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180321/13e55582/attachment.html>

From lm at mcvoy.com  Thu Mar 22 11:00:56 2018
From: lm at mcvoy.com (Larry McVoy)
Date: Wed, 21 Mar 2018 18:00:56 -0700
Subject: [TUHS] Comments in early Unix systems
In-Reply-To: <dbf048a5-374a-b08b-21ce-f67ed46264ef@gmail.com>
References: <6c6699c0-15db-604a-181c-7dad282599e1@kilonet.net>
 <CABH=_VREt+Ay+T3wnGKvGyKn-7W7dn6K4vT7huBmX4a4GzjQKg@mail.gmail.com>
 <CAEoi9W6_-2HLs=ywM42OtOG00GeBd=c0odxXhtsDcZhKy-n4Ew@mail.gmail.com>
 <CAC20D2ORh+k9cBF1DgZ=A86YkrWKPtiNYzO=7MLz-=SNDTPEew@mail.gmail.com>
 <CABH=_VT+Pu=xZ=vk30Z3JrZN0cf=BG6hg7x++FTnb4iptzbNMw@mail.gmail.com>
 <20180321202810.GA6280@minnie.tuhs.org>
 <4ED5DE5D-B2FC-4018-B4A8-2639CDB2073E@jctaylor.com>
 <394bc27c-8dff-03e1-9e13-9536a4ba195f@kilonet.net>
 <20180321235033.GJ9739@mcvoy.com>
 <dbf048a5-374a-b08b-21ce-f67ed46264ef@gmail.com>
Message-ID: <20180322010056.GM9739@mcvoy.com>

On Wed, Mar 21, 2018 at 08:55:44PM -0400, Mike Markowski wrote:
> On 03/21/2018 07:50 PM, Larry McVoy wrote:
> >On Wed, Mar 21, 2018 at 07:17:11PM -0400, Arthur Krewat wrote:
> >>I used to regularly compress sources of various distributions (not UNIX, but
> >>inn, pine, elm, etc) that I compiled, just to save space.
> >>
> >>And that was in the early 90's when I could buy a 1GB SCSI drive for $1000.
> >>I can't imagine working off of the early hard drives...
> >
> >I was sys admin for a Masscomp with a 40MB disk and 20 users.  That
> >was, um, "fun".
> 
> I remember Masscomp...  We used one (I forget model) in the field in the
> late 80s in the back of a tractor trailer.  We'd capture radar signals with
> it because it allowed data acquisition to not be swapped out.  It was a very
> expensive failure if, just as you started getting the short radar return,
> something like system logging swapped you out for a little!

I remember the Masscomps we had fondly.  The ones we had were 68000 based
and they had two of those CPUs running in lock step (or something, Clem
will correct this, he was one of the main devs at Masscomp) because the
68K didn't do VM right.  I can't remember the details, it was something
like they didn't handle faults right so they ran two CPUs and when the 
fault happened the 2nd CPU somehow got involved.

Clem, what model was that?  And can you provide the real version of what
I was trying say?

--lm


From dave at horsfall.org  Thu Mar 22 11:09:19 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Thu, 22 Mar 2018 12:09:19 +1100 (EST)
Subject: [TUHS] Happy 25th Birthday NetBSD!
In-Reply-To: <alpine.NEB.2.20.1803211456560.25928@t1.m.reedmedia.net>
References: <alpine.NEB.2.20.1803211456560.25928@t1.m.reedmedia.net>
Message-ID: <alpine.BSF.2.21.1803221206000.36168@aneurin.horsfall.org>

Many thanks; I've added it to my list (with attribution, of course).

All geeky contributions to my list are welcome; one day I'll stick it on a 
web page somewhere (when I figure out how to calendarise it) as Yet 
Another Damned History Site...

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."


From erik at ono-sendai.com  Thu Mar 22 11:21:15 2018
From: erik at ono-sendai.com (Erik Berls)
Date: Thu, 22 Mar 2018 01:21:15 +0000
Subject: [TUHS] Happy 25th Birthday NetBSD!
In-Reply-To: <CALMnNGgCSUpakX0MVQ5nMmZY2doje-zKhWisiLCxbXEO3Swq2A@mail.gmail.com>
References: <alpine.NEB.2.20.1803211456560.25928@t1.m.reedmedia.net>
 <CALMnNGgCSUpakX0MVQ5nMmZY2doje-zKhWisiLCxbXEO3Swq2A@mail.gmail.com>
Message-ID: <CAEFkZw9xLdCkSCJU87DJajybbWj4XoXPh8-6hKsqzVJuVwixUg@mail.gmail.com>

On Wed, Mar 21, 2018 at 17:30 Andy Kosela <akosela at andykosela.com> wrote:

>
>
> On Wednesday, March 21, 2018, Jeremy C. Reed <reed at reedmedia.net> wrote:
>
>> Revision 1.1, Sun Mar 21 09:45:37 1993 UTC (25 years ago) by cgd
>>
>>
>> http://cvsweb.netbsd.org/bsdweb.cgi/src/sbin/init/init.c?rev=1.1&content-type=text/x-cvsweb-markup&only_with_tag=MAIN
>>
>> Today is commonly considered the birthday of NetBSD.
>>
>> Theo told me (seven years ago) that he, cgd, and glass (and one other
>> person) planned it within 30 minutes after discussing with the CSRG and
>> BSDI guys in the hot tub at the Town & Country Resort in San Diego at
>> the January 25-29 1993 USENIX conference. (Does anyone have more to
>> share about this discussion?) Soon, cgd had setup a CVS repository
>> (forked 386BSD with many patchkits) which was re-rolled a few times (due
>> to corrupted CVS). (So maybe March 21 is later than the real birthday.)
>>
>> As far as I know, it is the oldest continuously-maintained complete
>> open source operating system. (It predates Slackware Linux, FreeBSD,
>> and Debian Linux by some months.)
>>
>>
> Speaking about NetBSD anyone know what Chris Demetriou is doing these
> days?  He has not been very active in the community for the last 20 years
> or so.  Last I heard he was working for Broadcom, but that was 18 years
> ago...
>

Last I talked to him a few years back he was a Eng Director at Google.
LinkedIn still shows him there.


> --Andy
>
-- 
-=erik.
--
Look, I lived through the Gray Davis years.  I *need* a UPS.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180322/06dafb8d/attachment.html>

From lm at mcvoy.com  Thu Mar 22 11:27:20 2018
From: lm at mcvoy.com (Larry McVoy)
Date: Wed, 21 Mar 2018 18:27:20 -0700
Subject: [TUHS] Comments in early Unix systems
In-Reply-To: <CALMnNGhD_3CbGaKx0_U0Hcbjq0E6Edecs39F0ZuWH-xys8gAcQ@mail.gmail.com>
References: <20180321141753.25C4418C088@mercury.lcs.mit.edu>
 <CAC20D2M6x5wn5_=HDWYsZyBqu_Ba58-oQ8Ca53XBmaRjS62=6Q@mail.gmail.com>
 <6c6699c0-15db-604a-181c-7dad282599e1@kilonet.net>
 <CABH=_VREt+Ay+T3wnGKvGyKn-7W7dn6K4vT7huBmX4a4GzjQKg@mail.gmail.com>
 <CAEoi9W6_-2HLs=ywM42OtOG00GeBd=c0odxXhtsDcZhKy-n4Ew@mail.gmail.com>
 <CAC20D2ORh+k9cBF1DgZ=A86YkrWKPtiNYzO=7MLz-=SNDTPEew@mail.gmail.com>
 <CABH=_VT+Pu=xZ=vk30Z3JrZN0cf=BG6hg7x++FTnb4iptzbNMw@mail.gmail.com>
 <20180321202810.GA6280@minnie.tuhs.org>
 <CALMnNGhD_3CbGaKx0_U0Hcbjq0E6Edecs39F0ZuWH-xys8gAcQ@mail.gmail.com>
Message-ID: <20180322012720.GN9739@mcvoy.com>

On Wed, Mar 21, 2018 at 07:58:11PM -0500, Andy Kosela wrote:
> They also state: "Comments are meant to help the reader of a program.  They
> do not help by saying things the code already plainly says, or by
> contradicting the code, or by distracting the reader with elaborate
> typographical displays.  The best comments aid the understanding of a
> program by briefly pointing out salient details or by providing a
> larger-scale view of the proceedings."

I so agree with this.  Verbose comments suck.  Too many comments suck.
Why?  Because the code evolves and it's work to evolve the comments
as well.  Too many comments means they are not maintained and they 
become incorrect.

I *HATE* comments that are not correct, hate that so much that if you did
that we would talk, if you kept doing that, you are fired.  No comments
are MUCH better than incorrect comments.

Terseness in comments is good.  Comment where it is not obvious what
is going on.  And maintain the comments like you maintain the code.

I agree with Dan (I think) that coding is still a craft and getting the
comments right is one of the hardest things to master (and I agree that
Unix did it pretty darn well).  No comments suck, too much sucks, just
right is so darn pleasant.

--lm


From lm at mcvoy.com  Thu Mar 22 11:31:23 2018
From: lm at mcvoy.com (Larry McVoy)
Date: Wed, 21 Mar 2018 18:31:23 -0700
Subject: [TUHS] Comments in early Unix systems
In-Reply-To: <CAC20D2OyW9iJYCC35DBrWB0YP_2rf+i9UN+Ko1QeQNJ4X8yJwA@mail.gmail.com>
References: <20180321141753.25C4418C088@mercury.lcs.mit.edu>
 <CAC20D2M6x5wn5_=HDWYsZyBqu_Ba58-oQ8Ca53XBmaRjS62=6Q@mail.gmail.com>
 <6c6699c0-15db-604a-181c-7dad282599e1@kilonet.net>
 <CABH=_VREt+Ay+T3wnGKvGyKn-7W7dn6K4vT7huBmX4a4GzjQKg@mail.gmail.com>
 <CAEoi9W6_-2HLs=ywM42OtOG00GeBd=c0odxXhtsDcZhKy-n4Ew@mail.gmail.com>
 <CAC20D2ORh+k9cBF1DgZ=A86YkrWKPtiNYzO=7MLz-=SNDTPEew@mail.gmail.com>
 <CABH=_VT+Pu=xZ=vk30Z3JrZN0cf=BG6hg7x++FTnb4iptzbNMw@mail.gmail.com>
 <20180321202810.GA6280@minnie.tuhs.org>
 <4ED5DE5D-B2FC-4018-B4A8-2639CDB2073E@jctaylor.com>
 <CAC20D2OyW9iJYCC35DBrWB0YP_2rf+i9UN+Ko1QeQNJ4X8yJwA@mail.gmail.com>
Message-ID: <20180322013123.GO9739@mcvoy.com>

On Wed, Mar 21, 2018 at 07:02:24PM -0400, Clem Cole wrote:
> On Wed, Mar 21, 2018 at 6:18 PM, William Corcoran <wlc at jctaylor.com> wrote:
> 
> > Along the same lines:
> > ???...
> >
> > Is there any chance of finding a publicly available UNIX archive that
> > includes the corresponding SCCS data for UNIX---to the extent that SCCS
> > deltas and PRS comments can be examined?
> >
> >
> Bill check out Diomidis Spinellis truely amazing work at:
> https://github.com/dspinellis/unix-history-repo
> 
> ???He has done an amazing job of reconstructing much of the lost work.  It is
> a treasure for us all.

Agreed but I'd still like the SCCS history.  I have it somewhere for BSD, it
was on Kirk's cds but I'd love to wander through the SCCS from Bell Labs.

I'm an SCCS fan, BitKeeper (sadly forgotten these days, my baby) was SCCS
on steriods.  BK has an import tool that will take SCCS history and intuit
what we today call commits, it will find the changes that are in the same
time and by the same person and create a changeset for that.  BK is still,
to this day, by far the best tool to use to browse history.  So if I could
get the SCCS history for early Unix I could give you all a super pleasant
way to look at that history (we open sourced BK when we shut down).

--lm


From jnc at mercury.lcs.mit.edu  Thu Mar 22 11:40:03 2018
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Wed, 21 Mar 2018 21:40:03 -0400 (EDT)
Subject: [TUHS] Comments in early Unix systems
Message-ID: <20180322014003.2184E18C085@mercury.lcs.mit.edu>

    > From: Warren Toomey <wkt at tuhs.org>

    > there is next to no commenting in the early code bases.

By 'early' you must mean the first 'C' PDP-11 Unixes, because certainly
starting with V6, it is reasonably well commented (to the point where I like
to say that I learned how to comment by reading the V6 code), e.g.:

  http://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/sys/ken/slp.c
  http://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/sys/dmr/bio.c

to pick examples from each author; and there are _some_ comments in the
assembler systems (both PDP-7 and PDP-11).

    > Given that the comments never made it into the compiled code, there was
    > no space reason to omit comments. There must have been another reason.

I was going to say 'the early disks were really small', but that hypothesis
fails because the very earliest versions (in assembler) do have some comments.

Although assembler is often so cryptic, the habit of putting a comment on each
instruction isn't so unreasonable.

So maybe the sort of comments one sees in assembler code (line-by-line
descriptions of what's happening; for subroutines, which arguments are in
which registers; etc) aren't needed in C code, and it took a while for them to
work out what sort of commenting _was_ appropriate/useful for C code?

The sudden appearance in V6 does make it seem as if there was a deliberate
decision to comment the code, and they went through it and added them in a
deliberate campaign.


    > From: Andy Kosela <akosela at andykosela.com>

    > "Practice of Programming" by Rob Pike and Brian Kernighan.
    > ...
    > They also state: "Comments ... do not help by saying things the code
    > already plainly says ... The best comments aid ... by briefly pointing
    > out salient details or by providing a larger-scale view of the
    > proceedings."

Exactly.

     Noel


From nobozo at gmail.com  Thu Mar 22 11:41:19 2018
From: nobozo at gmail.com (Jon Forrest)
Date: Wed, 21 Mar 2018 18:41:19 -0700
Subject: [TUHS] Happy 25th Birthday NetBSD!
In-Reply-To: <CAEFkZw9xLdCkSCJU87DJajybbWj4XoXPh8-6hKsqzVJuVwixUg@mail.gmail.com>
References: <alpine.NEB.2.20.1803211456560.25928@t1.m.reedmedia.net>
 <CALMnNGgCSUpakX0MVQ5nMmZY2doje-zKhWisiLCxbXEO3Swq2A@mail.gmail.com>
 <CAEFkZw9xLdCkSCJU87DJajybbWj4XoXPh8-6hKsqzVJuVwixUg@mail.gmail.com>
Message-ID: <9b28d958-a5d9-c6c9-5b55-51cd47f547bf@gmail.com>



On 3/21/2018 6:21 PM, Erik Berls wrote:
>
> Last I talked to him a few years back he was a Eng Director at Google. 
> LinkedIn still shows him there.

He's acknowledged in the beginning of the Go Programming Language
book.

Jon



From bakul at bitblocks.com  Thu Mar 22 11:59:33 2018
From: bakul at bitblocks.com (Bakul Shah)
Date: Wed, 21 Mar 2018 18:59:33 -0700
Subject: [TUHS] Comments in early Unix systems
In-Reply-To: <20180322012720.GN9739@mcvoy.com>
References: <20180321141753.25C4418C088@mercury.lcs.mit.edu>
 <CAC20D2M6x5wn5_=HDWYsZyBqu_Ba58-oQ8Ca53XBmaRjS62=6Q@mail.gmail.com>
 <6c6699c0-15db-604a-181c-7dad282599e1@kilonet.net>
 <CABH=_VREt+Ay+T3wnGKvGyKn-7W7dn6K4vT7huBmX4a4GzjQKg@mail.gmail.com>
 <CAEoi9W6_-2HLs=ywM42OtOG00GeBd=c0odxXhtsDcZhKy-n4Ew@mail.gmail.com>
 <CAC20D2ORh+k9cBF1DgZ=A86YkrWKPtiNYzO=7MLz-=SNDTPEew@mail.gmail.com>
 <CABH=_VT+Pu=xZ=vk30Z3JrZN0cf=BG6hg7x++FTnb4iptzbNMw@mail.gmail.com>
 <20180321202810.GA6280@minnie.tuhs.org>
 <CALMnNGhD_3CbGaKx0_U0Hcbjq0E6Edecs39F0ZuWH-xys8gAcQ@mail.gmail.com>
 <20180322012720.GN9739@mcvoy.com>
Message-ID: <1CF996A2-CEA3-4EC3-835D-9518729D2E36@bitblocks.com>

On Mar 21, 2018, at 6:27 PM, Larry McVoy <lm at mcvoy.com> wrote:
> 
> On Wed, Mar 21, 2018 at 07:58:11PM -0500, Andy Kosela wrote:
>> They also state: "Comments are meant to help the reader of a program.  They
>> do not help by saying things the code already plainly says, or by
>> contradicting the code, or by distracting the reader with elaborate
>> typographical displays.  The best comments aid the understanding of a
>> program by briefly pointing out salient details or by providing a
>> larger-scale view of the proceedings."
> 
> I so agree with this.  Verbose comments suck.  Too many comments suck.
> Why?  Because the code evolves and it's work to evolve the comments
> as well.  Too many comments means they are not maintained and they 
> become incorrect.
> 
> I *HATE* comments that are not correct, hate that so much that if you did
> that we would talk, if you kept doing that, you are fired.  No comments
> are MUCH better than incorrect comments.
> 
> Terseness in comments is good.  Comment where it is not obvious what
> is going on.  And maintain the comments like you maintain the code.
> 
> I agree with Dan (I think) that coding is still a craft and getting the
> comments right is one of the hardest things to master (and I agree that
> Unix did it pretty darn well).  No comments suck, too much sucks, just
> right is so darn pleasant.

When reading new code, I initially ignore comments,
at least within a function, and just try to figure
out what the code does. This is because often people
do not update comments. Code has to at least compile
so they are forced to update it and hopefully test
it but comments....

In the Go language ecosystem they have "go doc" which
can pull out comments at different level. Example:

go doc io // package level + top level exported declarations
go doc io.Copy // function level comments + header
go doc io.Reader // interface level + interface body

and so on. This does incentivize people to write good
comments.  This is very handy in that you can see how
your comments read when divorced from the code. But
notice that no comments within a function are output.
[Perhaps IDEs show relevant comments too but I find
them too heavyweight and don't use them]

A larger point is appropriate documentation, not just
source comments. There should be a function spec as
well. I used to write a manpage for a command etc.
first, especially when someone else has to code it.
A manpage is describes the syntax, function, results
and errors and links to related manpages. All this
usually in a page or two!



From usotsuki at buric.co  Thu Mar 22 12:19:12 2018
From: usotsuki at buric.co (Steve Nickolas)
Date: Wed, 21 Mar 2018 22:19:12 -0400 (EDT)
Subject: [TUHS] Comments in early Unix systems
In-Reply-To: <20180322014003.2184E18C085@mercury.lcs.mit.edu>
References: <20180322014003.2184E18C085@mercury.lcs.mit.edu>
Message-ID: <alpine.BSF.2.02.1803212218090.4662@frieza.hoshinet.org>

On Wed, 21 Mar 2018, Noel Chiappa wrote:

> Although assembler is often so cryptic, the habit of putting a comment on each
> instruction isn't so unreasonable.
>
> So maybe the sort of comments one sees in assembler code (line-by-line
> descriptions of what's happening; for subroutines, which arguments are in
> which registers; etc) aren't needed in C code, and it took a while for them to
> work out what sort of commenting _was_ appropriate/useful for C code?

I tend to use more comments in my ASM than my C, for what it's worth. 
(Most of my coding lately has been in 6502 assembly.)

-uxo.


From dave at horsfall.org  Thu Mar 22 12:24:04 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Thu, 22 Mar 2018 13:24:04 +1100 (EST)
Subject: [TUHS] daemons are not to be exorcised
In-Reply-To: <20180321173403.GD9739@mcvoy.com>
References: <20180321141753.25C4418C088@mercury.lcs.mit.edu>
 <CAC20D2M6x5wn5_=HDWYsZyBqu_Ba58-oQ8Ca53XBmaRjS62=6Q@mail.gmail.com>
 <6c6699c0-15db-604a-181c-7dad282599e1@kilonet.net>
 <CABH=_VREt+Ay+T3wnGKvGyKn-7W7dn6K4vT7huBmX4a4GzjQKg@mail.gmail.com>
 <20180321173403.GD9739@mcvoy.com>
Message-ID: <alpine.BSF.2.21.1803221317330.36168@aneurin.horsfall.org>

On Wed, 21 Mar 2018, Larry McVoy wrote:

> Yep.  Someone once told me "any code that you wrote more than 6 months 
> ago might as well have been written by someone else.  So write it in a 
> way that you can debug it".

Yep, and I'm glad that I had bosses to whom I didn't have to explain why 
my comments were so voluminous.

And who first said "Write your code as though the next person to maintain 
it is a psychotic axe-wielding murderer who knows where you live"?  I've 
often thought that way (as the murderer I mean, not the murderee).

I'd name names, but he might be on this list...

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."


From reed at reedmedia.net  Thu Mar 22 12:25:10 2018
From: reed at reedmedia.net (Jeremy C. Reed)
Date: Wed, 21 Mar 2018 21:25:10 -0500 (CDT)
Subject: [TUHS] syslog (was Re:  daemons are not to be exorcised)
In-Reply-To: <20180322002246.GK9739@mcvoy.com>
References: <CAFCBnZsS8Si6YGD4w_3W_znf3J5nVZGThkHVuQm5nD+FFm0DOg@mail.gmail.com>
 <94366db0-293b-214a-23a3-c7c895e4d30b@spamtrap.tnetconsulting.net>
 <alpine.BSF.2.02.1803200023360.43136@frieza.hoshinet.org>
 <98451f10-9b1b-049b-61ed-fd73586572fd@spamtrap.tnetconsulting.net>
 <20180321023125.GC6850@thunk.org>
 <76E7D09E-023B-4A29-ACCD-AF9ED425EE5F@xs4all.nl>
 <e38e9935-8633-2cee-8cae-c5e8be180966@spamtrap.tnetconsulting.net>
 <20180322002246.GK9739@mcvoy.com>
Message-ID: <alpine.NEB.2.20.1803212017420.25928@t1.m.reedmedia.net>

On Wed, 21 Mar 2018, Larry McVoy wrote:

> On Wed, Mar 21, 2018 at 06:18:37PM -0600, Grant Taylor via TUHS wrote:
> > On 03/21/2018 03:16 AM, Jaap Akkerhuis wrote:
> > >I've been told that syslog was came in existence as a debugging aid for
> > >sendmai.
> > 
> > I can't prove to the contrary.  But that does seem a little extreme to me.
> 
> For what it is worth, the syslog/sendmail connection rings a tiny bell for
> me, I can't prove it either, but I feel like there was some connection.
> Is Eric on the list?

Allman's logging was somewhat in 4BSD (4.0).

#               -DLOG -- include log information.  This is probably
#                       only useful on systems that include the logger.

delivermail was build with that flag.
But it used log.h which was not shipped in the version I have.
Some of the code has ifdef LOG and some doesn't.

2.79BSD (from McKusick's disk) which is later has logmsg(3) manual and 
its corresponding syslog(8) daemon manual (both Feb 5 1981).

I cannot find those files online so here they are:
http://reedmedia.net/~reed/tmp-oicyi3t6984y/logmsg.3.txt
Notice that it says "12/31/79"

http://reedmedia.net/~reed/tmp-oicyi3t6984y/syslog.8.txt

But no code there for logmsg, initlog, nor syslog.

(Note that uucp's logent.c has a syslog() but that is different.)

McKusick said that syslog was first in 4.1c and official in 4.2.
In both places shipped with sendmail code.
He said it was one of the first applications to use sockets.

4.1c.1 version says "reads datagrams from an IPC port
(currently port 2222, for no good reason)"
It uses the /etc/syslog.conf file.

Allman's 4.1c.1 code says:
**      This program implements a system log, implemented as the
**      "/dev/log" mpx file on a pre-4.2bsd system or a port on
**      a post-4.2bsd system.

I think this code is not in the dspinellis/unix-history-repo
(if you find it, please teach me how to find it).

The 4.1c code entirely changed api naming and some usage from

       initlog("delivermail", 0, LOG_INDEP);

to

        openlog("sendmail", LOG_PID);

(even though comments in syslog.h and syslog.c still mentioned initlog)

and from:

logmsg(LOG_INFO, "%s->%s: %ld: %s", From.q_paddr, To, MsgSize, statmsg);

to like:

syslog(LOG_INFO, "%s: message-id=%s", e->e_id, p);

even though syslog.c there defined logmsg() use and  not syslog()

I may have overlooked but don't see any use of the code outside of 
sendmail in 4.1c. The logger.c  (without manpage) utility was included 
in the sendmail source.

4.2 shipped two version of syslog(3) source code that no longer had 
logmsg() api. (One in libc and one with sendmail.)

4.2 could started it with rc.local. While I didn't see other use of it, 
a syslog.3 showed another example use:

openlog("serverftp", LOG_PID);

4.3 finally had lots of use (including in contrib): comsat, courier, 
various mh daemons, nntpd, savecore, shutdown, lpd, telnetd, r services, 
inetd, named, and much more. Even the date tool:

        syslog(LOG_NOTICE, "set by %s", username);



From doug at cs.dartmouth.edu  Thu Mar 22 23:49:02 2018
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Thu, 22 Mar 2018 09:49:02 -0400
Subject: [TUHS] Comments in early Unix systems
Message-ID: <201803221349.w2MDn23w100793@tahoe.cs.Dartmouth.EDU>

"I was told in school (in 1985) that if I was ever lucky enough to
have access to the unix source, I'd find there were no comments. The
reason, I was told at the time, was that comments would make the
source code useful, and selling software was something AT&T couldn't
do due to some consent decree."

I can't speak for SYS V, but no such idea was ever mentioned in
Research circles. Aside from copyright notices, the licensing folks
took no interest in comments. Within rsearch there was tacit
recognition of good coding style--Ken's cut-to-the-bone code was
universally admired. This cultural understanding did not extend
to comments. There was disparagement for the bad, but not honor
for the good. Whatever comments you find in the code were put
there at the author's whim.

My own commenting style is consistent within a project, but
wildly inconsistent across projects, and not well correlated
with my perception of the audience I might be writing for.
Why? I'm still groping for the answer.

For imoortant code, custom is to describe it in a separate
paper, which is of course not maintained in parallel with
the code. In fact, comments are often out of date, too.
Knuth offered the remedy of "literate programming", which
might help in academic circles. In business, probably not.
Yet think of the possibility of a "literate spec", where
the code grows organically with the understanding of what
has to be done.

Doug


From cym224 at gmail.com  Fri Mar 23 00:29:17 2018
From: cym224 at gmail.com (Nemo)
Date: Thu, 22 Mar 2018 10:29:17 -0400
Subject: [TUHS] Comments in early Unix systems
In-Reply-To: <201803221349.w2MDn23w100793@tahoe.cs.Dartmouth.EDU>
References: <201803221349.w2MDn23w100793@tahoe.cs.Dartmouth.EDU>
Message-ID: <CAJfiPzx6p+ksM8Nbf4T2BLs60pjzTrV8SMp==Mi=yDaezXa=Hw@mail.gmail.com>

On 22/03/2018, Doug McIlroy <doug at cs.dartmouth.edu> wrote:
[...]
> For imoortant code, custom is to describe it in a separate
> paper, which is of course not maintained in parallel with
> the code. In fact, comments are often out of date, too.
> Knuth offered the remedy of "literate programming", which
> might help in academic circles. In business, probably not.
> Yet think of the possibility of a "literate spec", where
> the code grows organically with the understanding of what
> has to be done.

At a previous company, we used Ramsey's noweb with good results.  The
code was very heavy in math;  being able to read the typeset
explanation alongside the code was very helpful, especially for
understanding the optimization transformations.  (We also began to
include Xfig diagrams to document data flow and so on.) The next
manager decided to describe the code in separate documents, with mixed
results.  In hindsight, I probably would not have used noweb on the
typical stuff but I would definitely use noweb again to document the
math-intensive stuff.

N.

>
> Doug
>


From steve at quintile.net  Fri Mar 23 00:46:13 2018
From: steve at quintile.net (Steve Simon)
Date: Thu, 22 Mar 2018 14:46:13 +0000
Subject: [TUHS] Comments in early Unix systems
In-Reply-To: <20180322012720.GN9739@mcvoy.com>
References: <20180321141753.25C4418C088@mercury.lcs.mit.edu>
 <CAC20D2M6x5wn5_=HDWYsZyBqu_Ba58-oQ8Ca53XBmaRjS62=6Q@mail.gmail.com>
 <6c6699c0-15db-604a-181c-7dad282599e1@kilonet.net>
 <CABH=_VREt+Ay+T3wnGKvGyKn-7W7dn6K4vT7huBmX4a4GzjQKg@mail.gmail.com>
 <CAEoi9W6_-2HLs=ywM42OtOG00GeBd=c0odxXhtsDcZhKy-n4Ew@mail.gmail.com>
 <CAC20D2ORh+k9cBF1DgZ=A86YkrWKPtiNYzO=7MLz-=SNDTPEew@mail.gmail.com>
 <CABH=_VT+Pu=xZ=vk30Z3JrZN0cf=BG6hg7x++FTnb4iptzbNMw@mail.gmail.com>
 <20180321202810.GA6280@minnie.tuhs.org>
 <CALMnNGhD_3CbGaKx0_U0Hcbjq0E6Edecs39F0ZuWH-xys8gAcQ@mail.gmail.com>
 <20180322012720.GN9739@mcvoy.com>
Message-ID: <F86441D1-FB0C-41D9-8519-E31F3238A235@quintile.net>



> On 22 Mar 2018, at 01:27, Larry McVoy <lm at mcvoy.com> wrote:
> 
>> On Wed, Mar 21, 2018 at 07:58:11PM -0500, Andy Kosela wrote:
>> They also state: "Comments are meant to help the reader of a program.  They
>> do not help by saying things the code already plainly says, or by
>> contradicting the code, or by distracting the reader with elaborate
>> typographical displays.  The best comments aid the understanding of a
>> program by briefly pointing out salient details or by providing a
>> larger-scale view of the proceedings."
> 
> I so agree with this.  Verbose comments suck.  Too many comments suck.
> Why?  Because the code evolves and it's work to evolve the comments
> as well.  Too many comments means they are not maintained and they 
> become incorrect.
> 
> I *HATE* comments that are not correct, hate that so much that if you did
> that we would talk, if you kept doing that, you are fired.  No comments
> are MUCH better than incorrect comments.
> 
> Terseness in comments is good.  Comment where it is not obvious what
> is going on.  And maintain the comments like you maintain the code.
> 
> I agree with Dan (I think) that coding is still a craft and getting the
> comments right is one of the hardest things to master (and I agree that
> Unix did it pretty darn well).  No comments suck, too much sucks, just
> right is so darn pleasant.
> 
> --lm

on the commenting subject, and as it was Shannon’s anniversary recently... i always felt information theory relates well to comments.

i.e. repeating anything i can see from the code (like “returns void”) tells me nothing.

telling me something non-obvious (“allocate one more for end of list sentinel”)  really helps.

-Steve




From rminnich at gmail.com  Fri Mar 23 01:22:00 2018
From: rminnich at gmail.com (ron minnich)
Date: Thu, 22 Mar 2018 15:22:00 +0000
Subject: [TUHS] Comments in early Unix systems
In-Reply-To: <F86441D1-FB0C-41D9-8519-E31F3238A235@quintile.net>
References: <20180321141753.25C4418C088@mercury.lcs.mit.edu>
 <CAC20D2M6x5wn5_=HDWYsZyBqu_Ba58-oQ8Ca53XBmaRjS62=6Q@mail.gmail.com>
 <6c6699c0-15db-604a-181c-7dad282599e1@kilonet.net>
 <CABH=_VREt+Ay+T3wnGKvGyKn-7W7dn6K4vT7huBmX4a4GzjQKg@mail.gmail.com>
 <CAEoi9W6_-2HLs=ywM42OtOG00GeBd=c0odxXhtsDcZhKy-n4Ew@mail.gmail.com>
 <CAC20D2ORh+k9cBF1DgZ=A86YkrWKPtiNYzO=7MLz-=SNDTPEew@mail.gmail.com>
 <CABH=_VT+Pu=xZ=vk30Z3JrZN0cf=BG6hg7x++FTnb4iptzbNMw@mail.gmail.com>
 <20180321202810.GA6280@minnie.tuhs.org>
 <CALMnNGhD_3CbGaKx0_U0Hcbjq0E6Edecs39F0ZuWH-xys8gAcQ@mail.gmail.com>
 <20180322012720.GN9739@mcvoy.com>
 <F86441D1-FB0C-41D9-8519-E31F3238A235@quintile.net>
Message-ID: <CAP6exYL+y11e18NJVDpqcH_yk_NiiGPJF=-yu8F=JThjP2=F1A@mail.gmail.com>

so if you had an 11/45 with dual RKO5s back in the day with their massive
storage capacity, then you had source and your system with source and docs
could run out of L2 cache in a modern cheapo IOT board.

Now wouldn't that be a hoot. But how would we simulate pulling the RK05
cartridge out of the drive?

On Thu, Mar 22, 2018 at 8:05 AM Steve Simon <steve at quintile.net> wrote:

>
>
> > On 22 Mar 2018, at 01:27, Larry McVoy <lm at mcvoy.com> wrote:
> >
> >> On Wed, Mar 21, 2018 at 07:58:11PM -0500, Andy Kosela wrote:
> >> They also state: "Comments are meant to help the reader of a program.
> They
> >> do not help by saying things the code already plainly says, or by
> >> contradicting the code, or by distracting the reader with elaborate
> >> typographical displays.  The best comments aid the understanding of a
> >> program by briefly pointing out salient details or by providing a
> >> larger-scale view of the proceedings."
> >
> > I so agree with this.  Verbose comments suck.  Too many comments suck.
> > Why?  Because the code evolves and it's work to evolve the comments
> > as well.  Too many comments means they are not maintained and they
> > become incorrect.
> >
> > I *HATE* comments that are not correct, hate that so much that if you did
> > that we would talk, if you kept doing that, you are fired.  No comments
> > are MUCH better than incorrect comments.
> >
> > Terseness in comments is good.  Comment where it is not obvious what
> > is going on.  And maintain the comments like you maintain the code.
> >
> > I agree with Dan (I think) that coding is still a craft and getting the
> > comments right is one of the hardest things to master (and I agree that
> > Unix did it pretty darn well).  No comments suck, too much sucks, just
> > right is so darn pleasant.
> >
> > --lm
>
> on the commenting subject, and as it was Shannon’s anniversary recently...
> i always felt information theory relates well to comments.
>
> i.e. repeating anything i can see from the code (like “returns void”)
> tells me nothing.
>
> telling me something non-obvious (“allocate one more for end of list
> sentinel”)  really helps.
>
> -Steve
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180322/1fcbb6ff/attachment.html>

From ron at ronnatalie.com  Fri Mar 23 02:22:06 2018
From: ron at ronnatalie.com (Ron Natalie)
Date: Thu, 22 Mar 2018 12:22:06 -0400
Subject: [TUHS] Comments in early Unix systems
In-Reply-To: <F86441D1-FB0C-41D9-8519-E31F3238A235@quintile.net>
References: <20180321141753.25C4418C088@mercury.lcs.mit.edu>
 <CAC20D2M6x5wn5_=HDWYsZyBqu_Ba58-oQ8Ca53XBmaRjS62=6Q@mail.gmail.com>
 <6c6699c0-15db-604a-181c-7dad282599e1@kilonet.net>
 <CABH=_VREt+Ay+T3wnGKvGyKn-7W7dn6K4vT7huBmX4a4GzjQKg@mail.gmail.com>
 <CAEoi9W6_-2HLs=ywM42OtOG00GeBd=c0odxXhtsDcZhKy-n4Ew@mail.gmail.com>
 <CAC20D2ORh+k9cBF1DgZ=A86YkrWKPtiNYzO=7MLz-=SNDTPEew@mail.gmail.com>
 <CABH=_VT+Pu=xZ=vk30Z3JrZN0cf=BG6hg7x++FTnb4iptzbNMw@mail.gmail.com>
 <20180321202810.GA6280@minnie.tuhs.org>
 <CALMnNGhD_3CbGaKx0_U0Hcbjq0E6Edecs39F0ZuWH-xys8gAcQ@mail.gmail.com>
 <20180322012720.GN9739@mcvoy.com>
 <F86441D1-FB0C-41D9-8519-E31F3238A235@quintile.net>
Message-ID: <01d401d3c1f9$ebd18270$c3748750$@ronnatalie.com>


 

>  i.e. repeating anything i can see from the code (like “returns void”) tells me nothing.

It's right up there with using #defines for silly things like
    #define FOUR 4

Great.   What doe this tell me that the literal 4 doesn't.    It's a matter of time until someone says
    #define FOUR 5

I actually found some code in use that had

#define notdef 1

in it.    I about went through the roof.

Frankly, I have immense distaste for the definition NULL.    Especially those implementations that try to fix it by introducing a spurious cast on it.





From arnold at skeeve.com  Fri Mar 23 02:30:05 2018
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Thu, 22 Mar 2018 10:30:05 -0600
Subject: [TUHS] Literate Programming (was Comments in early Unix systems)
In-Reply-To: <201803221349.w2MDn23w100793@tahoe.cs.Dartmouth.EDU>
References: <201803221349.w2MDn23w100793@tahoe.cs.Dartmouth.EDU>
Message-ID: <201803221630.w2MGU5Aw016397@freefriends.org>

Doug McIlroy <doug at cs.dartmouth.edu> wrote:

> Knuth offered the remedy of "literate programming", which
> might help in academic circles. In business, probably not.

IMHO this is too bad. Code I've written using LP is generally 
more correct earlier on than otherwise. And it's very enjoyable
to write code and explanation at the same time; I feel like I'm
talking out loud directly to my reader, a person, and not just
coding for myself or the compiler.

Significant proofs by example are Knuth's TeX and MetaFont,
and the lcc compiler by Dave Hanson and <I forgot>.

Shameless plug: I have written a small LP system in gawk designed
for use with the Texinfo markup language. It is written using itself.
I have written two other good size awk scripts using it as well.
I think it will scale well to larger stuff in C or C++ but simply
have not had an opportunity to use it for anything like that yet.

See https://github.com/arnoldrobbins/texiwebjr if interested;
and feel free to follow up privately instead of on the list to keep
things on topic.

Thanks,

Arnold


From arnold at skeeve.com  Fri Mar 23 02:32:28 2018
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Thu, 22 Mar 2018 10:32:28 -0600
Subject: [TUHS] Comments in early Unix systems
In-Reply-To: <01d401d3c1f9$ebd18270$c3748750$@ronnatalie.com>
References: <20180321141753.25C4418C088@mercury.lcs.mit.edu>
 <CAC20D2M6x5wn5_=HDWYsZyBqu_Ba58-oQ8Ca53XBmaRjS62=6Q@mail.gmail.com>
 <6c6699c0-15db-604a-181c-7dad282599e1@kilonet.net>
 <CABH=_VREt+Ay+T3wnGKvGyKn-7W7dn6K4vT7huBmX4a4GzjQKg@mail.gmail.com>
 <CAEoi9W6_-2HLs=ywM42OtOG00GeBd=c0odxXhtsDcZhKy-n4Ew@mail.gmail.com>
 <CAC20D2ORh+k9cBF1DgZ=A86YkrWKPtiNYzO=7MLz-=SNDTPEew@mail.gmail.com>
 <CABH=_VT+Pu=xZ=vk30Z3JrZN0cf=BG6hg7x++FTnb4iptzbNMw@mail.gmail.com>
 <20180321202810.GA6280@minnie.tuhs.org>
 <CALMnNGhD_3CbGaKx0_U0Hcbjq0E6Edecs39F0ZuWH-xys8gAcQ@mail.gmail.com>
 <20180322012720.GN9739@mcvoy.com>
 <F86441D1-FB0C-41D9-8519-E31F3238A235@quintile.net>
 <01d401d3c1f9$ebd18270$c3748750$@ronnatalie.com>
Message-ID: <201803221632.w2MGWSTC016570@freefriends.org>

"Ron Natalie" <ron at ronnatalie.com> wrote:

> Frankly, I have immense distaste for the definition NULL.    Especially
> those implementations that try to fix it by introducing a spurious cast
> on it.

I'll agree with the latter part. But in my own code I try to be very
careful to use NULL for pointers, '\0' for end of string, and 0 for
numbers. Even though 0 could be used in all three cases, the different
forms make it much more clear what the type of data is that I'm working
with.

My two cents,

Arnold


From khm at sciops.net  Fri Mar 23 02:33:26 2018
From: khm at sciops.net (Kurt H Maier)
Date: Thu, 22 Mar 2018 09:33:26 -0700
Subject: [TUHS] Comments in early Unix systems
In-Reply-To: <01d401d3c1f9$ebd18270$c3748750$@ronnatalie.com>
References: <6c6699c0-15db-604a-181c-7dad282599e1@kilonet.net>
 <CABH=_VREt+Ay+T3wnGKvGyKn-7W7dn6K4vT7huBmX4a4GzjQKg@mail.gmail.com>
 <CAEoi9W6_-2HLs=ywM42OtOG00GeBd=c0odxXhtsDcZhKy-n4Ew@mail.gmail.com>
 <CAC20D2ORh+k9cBF1DgZ=A86YkrWKPtiNYzO=7MLz-=SNDTPEew@mail.gmail.com>
 <CABH=_VT+Pu=xZ=vk30Z3JrZN0cf=BG6hg7x++FTnb4iptzbNMw@mail.gmail.com>
 <20180321202810.GA6280@minnie.tuhs.org>
 <CALMnNGhD_3CbGaKx0_U0Hcbjq0E6Edecs39F0ZuWH-xys8gAcQ@mail.gmail.com>
 <20180322012720.GN9739@mcvoy.com>
 <F86441D1-FB0C-41D9-8519-E31F3238A235@quintile.net>
 <01d401d3c1f9$ebd18270$c3748750$@ronnatalie.com>
Message-ID: <20180322163326.GA56561@wopr>

On Thu, Mar 22, 2018 at 12:22:06PM -0400, Ron Natalie wrote:
> 
> It's right up there with using #defines for silly things like
>     #define FOUR 4
> 
> Great.   What doe this tell me that the literal 4 doesn't.    It's a matter of time until someone says
>     #define FOUR 5
> 

One of my favorite messages I've ever received:
          
http://sourceware.org/ml/glibc-cvs/2013-q1/msg00115.html
          
khm



From toby at telegraphics.com.au  Fri Mar 23 03:07:36 2018
From: toby at telegraphics.com.au (Toby Thain)
Date: Thu, 22 Mar 2018 13:07:36 -0400
Subject: [TUHS] Literate Programming (was Comments in early Unix systems)
In-Reply-To: <201803221630.w2MGU5Aw016397@freefriends.org>
References: <201803221349.w2MDn23w100793@tahoe.cs.Dartmouth.EDU>
 <201803221630.w2MGU5Aw016397@freefriends.org>
Message-ID: <c6878787-23b3-3c37-7133-d106d332d3e1@telegraphics.com.au>

On 2018-03-22 12:30 PM, arnold at skeeve.com wrote:
> Doug McIlroy <doug at cs.dartmouth.edu> wrote:
> 
>> Knuth offered the remedy of "literate programming", which
>> might help in academic circles. In business, probably not.
> 
> IMHO this is too bad. Code I've written using LP is generally 
> more correct earlier on than otherwise. And it's very enjoyable
> to write code and explanation at the same time; I feel like I'm
> talking out loud directly to my reader, a person, and not just
> coding for myself or the compiler.
> 
> Significant proofs by example are Knuth's TeX and MetaFont,
> and the lcc compiler by Dave Hanson and <I forgot>.

Chris Fraser (AT&T Bell Labs at the time).

As you say, the whole book is a literate program:
https://www.pearson.com/us/higher-education/program/Hanson-Retargetable-C-Compiler-A-Design-and-Implementation/PGM166351.html


> 
> Shameless plug: I have written a small LP system in gawk designed
> for use with the Texinfo markup language. ...
> Thanks,
> 
> Arnold
> 



From clemc at ccc.com  Fri Mar 23 03:10:58 2018
From: clemc at ccc.com (Clem Cole)
Date: Thu, 22 Mar 2018 13:10:58 -0400
Subject: [TUHS]  Masscomp - Real Time Unix (RTU) an early UNIX based system,
 the first commercial multiprocessor and was realtime
Message-ID: <CAC20D2MrAJBorJcOUUX3RMmEEU+A+vwEX41z2n=XeNds0DUXYA@mail.gmail.com>

On Wed, Mar 21, 2018 at 7:50 PM, Larry McVoy <lm at mcvoy.com> wrote:

> I was sys admin for a Masscomp with a 40MB disk

Right an early MC-500/DP system - although I think the minimum was a 20M
[ST-506 based] disk.

On Wed, Mar 21, 2018 at 8:55 PM, Mike Markowski <mike.ab3ap at gmail.com>
wrote:

> I remember Masscomp  ...  it allowed data acquisition to not be swapped
>> out.
>>
> Actually, not quite right in how it worked, but in practice you got the
desired behavior. More in a minute.

On Wed, Mar 21, 2018 at 9:00 PM, Larry McVoy <lm at mcvoy.com> wrote:

> I remember the Masscomps we had fondly.  The ones we had were 68000 based
> and they had two of those CPUs running in lock step

Not lock step ... 'executor' and 'fixor' -- actually a solution Forest
Basket proposed at Stanford.   The two implementations that actually did
this were the Masscomp MC-500 family and the original Apollo.


> ... because the
> 68K didn't do VM right.  I can't remember the details, it was something
> like they didn't handle faults right so they ran two CPUs and when the
> fault happened the 2nd CPU somehow got involved.
>
Right, it the original 68000 did not save the faulting address properly
when it took the
exception, so there was not enough information to roll back the from the
fault and restart.   The microcode in the 68010 corrected this flaw.



>
> Clem, what model was that?

We called the dual 68000 board the CPU board and the 68010/68000 board the
MPU.  The difference was which chip was in the 'executor' socket and some
small changes in some PALs on the board to allow the 68010 to actually take
the exception.   Either way, the memory fault was processed by the
'fixor'.   BTW: the original MC-500/DP was a dual processor system, so it
has 4 68000 just for the 2 'cpu boards -- i.e. an executor and fixor on
each board.  The later MC-5000 family could handle up to 16 processor
boards depending the model (MC-5000/300 was dual, MC-5000/500 up to 4 and
the MC-5000/700 up to 16 processor boards).

Also for the record, the MC-500/DP and MC-5000/700 predate the
multiprocessor 'Symmetry System' that Sequent would produce by a number of
years).  The original RTU ran master/slave (Purdue VAX style) for the first
generation (certainly through RT 2.x and maybe 3.x).   That restriction was
removed and a fully symmetric OS was created, as we did the 700
development.  I've forgotten which OS release brought that out.

A few years later Stellix, while not in direct source development a child,
had the same Texieria/Cole team as RTU - was always fully symmetric - i.e.
lesson learned.



> And can you provide the real version of what I was trying say?
>
Sure ... soon after Motorola released the 68000, Stanford's Forest Baskett
in a paper I have sadly lost, proposed that the solution the 68000's issue
of not saving enough information when an illegal memory exception
occured,  was to instead of allowing the memory exception, return 'wait
states' to the processor - thus never letting it fault.

More specifically, the original microprocessor designs had a fixed time
that the memory system needed to respond on a read or write cycle that was
defined by the system clock.  I don't have either Motorola 68000 or MOS
6502 processor books handy, but as a for instance IIRC on a 1 Mhz MOS 6502
you had 100 nS for this operation.  Because EPROMs of the day could not
respond that fast (IIRC 400ns for a read), the CPU chip designers created a
special 'WAIT' signal that would tell the processor, to look for the data
in on the next clock tick (and the wait signal could be repeated for each
tick for an indefinite wait if need be).   *i.e. *in effect, when running
from ROM a 6502 would run at .25MHz if it was doing direct fetches from
something like an Intel 1702 ROM on every cycle.  Similarly, early dynamic
RAM, while faster that ROM, had access issues with needing to ensure the
refresh cycles and the access cycles aligned.  Static RAMs which were fast,
did not have these problems and could directly interface to processor, but
static RAMs of the day were the quite expensive chips (5-10 times) in
comparison to DRAM cost, so small caches were built to front end the memory
system.

Hence, the HW 'wait state' feature became standard (and I think is still
supported in todays processors), since it allows the memory system speed
and the processor to work at differing rates.  i*.e.* the difference in
speed could be 'biased' to each side -> processor vs memory.

In his paper, Forest Basket observed that if a HW designer used the wait
state feature, a memory system could be built that refreshed the cache
using another processor, as long as the second processor that was 'fixing
up' the exception ( i.e. refilled the cache with proper data) could be
ensured it never had a memory fault.

Basket's idea was exactly how both the original Apollo and Masscomp CPU
boards were designed.  On the Masscomp CPU board, there was a 68000 that
always ran from a static ram based cache (which we called the 'executor.'
If it tried to access a memory location that was not yet in cache, or if it
was a legal memory access, the memory system sent wait states until  the
cache was refilled as you might expect.  If the location was illegal, the
memory system also return a error exception as expected.  However, it was
legal address but not yet in memory, the second 6800 (the 'fixor') was
notified of desire to access that specific memory location and the fixor
ran the paging code to put the page into the live memory.  Once the cache
was properly set up, then the executor could be released from wait state
and instruction allowed to complete.

When Motorola released the 68010 with the internal fixes that would allow
an faulting instruction to be restarted, Masscomp revised the CPU board
(creating the MPU board) to install a 68010 in the executor socket and
changed a few PALs in the memory system on the board.   If a memory address
was discovered to be legal, but not in memory, the executor (now a 68010)
was allowed to returned a paging exception and stack was saved
appropriately, and the executor did a context switch to different process -
allow the executor to do something useful while the fixor processed the
fault.   Although we now had to add kernel code for the executor processor
to return from restart at the fault instruction on a context switch back to
the original process.   The original fixor code did not need to be changed,
other than to remove need to clearing of the 'waiting flop' for that
restarted the executor.   [RTU would detect which board was plugged into a
specific system automatically so it was an invisible change to the end user
- other than you got a few percent performance back if there was a lot of
page faults in your application since the executor never wait stated].

As for the way real time and analog I/O worked that Mike commented upon.
 Yes, RTU - Real Time Unix supported features that could guarantee that I/O
would not be lost from the DMA front end.     For those not familiar with
the system, it was a 'federated system' with a number of subsystems: the
primary UNIX portion that I just described and then a number of other
specialized processors that surrounded it for specific tasks.  This
architecture was chosen because the market we were attacking was a
scientific laboratory and in particular real-time oriented - for instance,
some uses were Mass General in the Cardiac ward, on board ever EWACS plane
to collect all and retain all signals during any sortie [very interesting
application], NASA used 75 of them in Mission Control to be the 'consoles'
you see on TV, *etc *[ which have only recently be replaced by PCs, as some
were still in use at least 2 years ago when I was last in Houston].

So besides the 2/4 68000s in the main UNIX system, their was another
dedicated 68000 running a graphics system on the graphics board, another
80186 running TCP/IP, and an AM2900 bit slices processor called Data
Acquisition and Control Processor (DA/CP) - which Mike hinted, as well as
29000's for the FP unit and Array processor functionality.   Using ther
DA/CP, in 1984, and MC-500 system could handle multiple 1MHz analog 16 bit
signals - just by sampling them -> in fact, a cute demo at the Computer
Museum in Boston just connected a TV camera to the DA/CP and without any
special HW, it could 'read' the video signal (if you normally have a
connection a TV camera, it usually takes a bunch of special logic to
interface to the TV signals -- in this case it was just SW in the DA/CP).

The resultant OS was RTU, were we had modified a combined 4.1BSD and System
III 'unices' (later up dated to 4.2 and V.2] to support RT behaviors, with
pre-emption, ASTs [which I still miss - a great idea but nicer than
traditional UNIX signals], async I/O, *etc*.. Another interesting idea was
the concept of 'universes' that allowed on a per user basis, to see a BSD
view of the system or an System V view].

One of the important things we did in RTU was rethink the file system
(although only a little then).   Besides all the file types and storage
schemes you have with UFS, Masscomp added support for an pre-allocated
extent based files (like VMS and RSX) and then created a new file type
called contiguous file that used it [by the time of the Stellar and
Stellix, we just made all files extent based and got rid of the special
file type - *i.e.* looked like UFS to the user, but under the covers was
fully extend based].   So under RTU, once we had preallocated files that we
knew were on contiguous blocks, we could make all sorts of speed ups and
guarantees that traditional UNIX can not because of the randomized location
of the disk blocks.

So the feature that Mike was using, was actually less a UNIX change and did
not actually use the preemption and other types of RT features.  We had
added the ability for the DA/CP to write/read information directly from the
disk without OS getting in the  way - (we called it Direct to Disk IO).
 An RTU application created a contiguous file large enough on disk to store
the data the DA/CP might receive - many megabytes typically - but the data
itself was never passed thru or stored in the UNIX buffer cache *etc*.
 The microcode of the DA/CP and the RTU disk driver could/would cooperate
and all kernel or user processing on the UNIX side was by-passed.  Thus,
when the real time data started to be produced by the DA/CP (say the EWACS
started getting radio signals on one of those 16 bit analog converters) the
digital representation of those analog signals were stored in the users
file system independent of what RTU was doing.

The same idea, by the way was why we chose to run IP/TCP on a
co-processor.   So much of network I/O is 'unexpected,' we could
potentially lose the ability to make real-time guarantees.   But keeping
all the protocol work outside of UNIX,  the network I/O just operated on
'final bits' at the rate that was right for it.   As an interesting aside,
this worked until we switched to a Motorola 68020 at 16 Mhz or 20Mhz
(whatever it was I've forgotten now) in the MC-5000 system.    The host
ended up be so much faster than the 80186 in the ethernet coprocessor
board.   We ended up offering a mode were they swapping roles and just used
the '186 board as a very heavily buffered ethernet controller, so we could
keep protocol processing very low priority compared to other tasks.
However if we did that, it did mean some of the system guarantees had to be
removed.  My recollection is that only a couple of die hard RT style
customers, ended up continuing to use the original networking configuration.

Clem
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180322/c0229ec1/attachment.html>

From jon at fourwinds.com  Fri Mar 23 02:48:10 2018
From: jon at fourwinds.com (Jon Steinhart)
Date: Thu, 22 Mar 2018 09:48:10 -0700
Subject: [TUHS] Literate Programming (was Comments in early Unix systems)
In-Reply-To: <201803221630.w2MGU5Aw016397@freefriends.org>
References: <201803221349.w2MDn23w100793@tahoe.cs.Dartmouth.EDU>
 <201803221630.w2MGU5Aw016397@freefriends.org>
Message-ID: <201803221648.w2MGmAFD001438@darkstar.fourwinds.com>

arnold at skeeve.com writes:
> Doug McIlroy <doug at cs.dartmouth.edu> wrote:
>
> > Knuth offered the remedy of "literate programming", which
> > might help in academic circles. In business, probably not.
>
> IMHO this is too bad. Code I've written using LP is generally 
> more correct earlier on than otherwise. And it's very enjoyable
> to write code and explanation at the same time; I feel like I'm
> talking out loud directly to my reader, a person, and not just
> coding for myself or the compiler.
>
> Significant proofs by example are Knuth's TeX and MetaFont,
> and the lcc compiler by Dave Hanson and <I forgot>.
>
> Shameless plug: I have written a small LP system in gawk designed
> for use with the Texinfo markup language. It is written using itself.
> I have written two other good size awk scripts using it as well.
> I think it will scale well to larger stuff in C or C++ but simply
> have not had an opportunity to use it for anything like that yet.
>
> See https://github.com/arnoldrobbins/texiwebjr if interested;
> and feel free to follow up privately instead of on the list to keep
> things on topic.
>
> Thanks,
>
> Arnold

In mid-1985 I independently had the idea that combining code and
documentation would make it easier to keep them in sync.  I wrote
a program called "xman" for "eXtract MAN pages" that generated troff
man pages from special comments that began with /**.  A few months
later I got a course proposal accepted by SIGGRAPH and asked James
Gosling to participate.  During one of our get-togethers I showed
him xman.  While correlation doesn't equal causation (and James
doesn't remember), /** reappeared in JavaDoc which spread like the
plague to doxygen et. al.

We abandoned xman after a few months.  It was an interesting experiment,
but was only "useful" for producing large volumes of nicely typeset
utterly irrelevant documentation.  Which, of course, since many others
have since drunk the Kool-Aid, is the state of much documentation today.

What works for me documentation wise-is:

 o  Block comments that say what the code does, not how it does it unless
    it's not obvious from looking at the code.

 o  Inline or block comments for things that aren't obvious.

 o  Separate BTL-style document that explains what the program does,
    describes the data structures, and how the different parts of the
    program manipulate those structures.  Sometimes that can go in a
    code file if it's a small and simple program.

While I'm at it, my two cents on the NULL topic.  I use '\0' for NUL
as that's not the same as NULL.  When I want NULL, I always cast it,
for example, (struct foo *)0 because that locally provides some often
non-local information about the type of the things that's being compared
or set to NULL.

Jon


From mike.ab3ap at gmail.com  Fri Mar 23 05:02:55 2018
From: mike.ab3ap at gmail.com (Mike Markowski)
Date: Thu, 22 Mar 2018 15:02:55 -0400
Subject: [TUHS] Masscomp - Real Time Unix (RTU) an early UNIX based
 system, the first commercial multiprocessor and was realtime
In-Reply-To: <CAC20D2MrAJBorJcOUUX3RMmEEU+A+vwEX41z2n=XeNds0DUXYA@mail.gmail.com>
References: <CAC20D2MrAJBorJcOUUX3RMmEEU+A+vwEX41z2n=XeNds0DUXYA@mail.gmail.com>
Message-ID: <CANq1pfkdxOG6nJ4uibn3+b1D4w-oH7AV4dT_5n-qkihP7KpX1Q@mail.gmail.com>

On Thu, Mar 22, 2018 at 1:10 PM, Clem Cole <clemc at ccc.com> wrote:

> On Wed, Mar 21, 2018 at 7:50 PM, Larry McVoy <lm at mcvoy.com> wrote:
>
>> I was sys admin for a Masscomp with a 40MB disk
>
> Right an early MC-500/DP system - although I think the minimum was a 20M
> [ST-506 based] disk.
>
> On Wed, Mar 21, 2018 at 8:55 PM, Mike Markowski <mike.ab3ap at gmail.com>
> wrote:
>
>> I remember Masscomp  ...  it allowed data acquisition to not be swapped
>>> out.
>>>
>> Actually, not quite right in how it worked, but in practice you got the
> desired behavior. More in a minute.
>
[...lots of good stuff...]

>
> Clem
>

Thanks very much, Clem!  I had no idea what was under the hood of the
Masscomps I was using then, fresh out of grad school.  I was on a team
designing a tracking radar system and using the Masscomp as a tool to
control gear and acquire the return signals.  All my attention was on that
and not so much the computer itself.  Super interesting to learn about it.

Mike Markowski
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180322/5ca17d66/attachment.html>

From david at kdbarto.org  Fri Mar 23 05:01:40 2018
From: david at kdbarto.org (David)
Date: Thu, 22 Mar 2018 12:01:40 -0700
Subject: [TUHS]  daemons are not to be exorcised/Comments in code
In-Reply-To: <mailman.68.1521732132.3788.tuhs@minnie.tuhs.org>
References: <mailman.68.1521732132.3788.tuhs@minnie.tuhs.org>
Message-ID: <C4983039-5958-4336-ADFE-9A20DA9767B7@kdbarto.org>


> From: Dave Horsfall <dave at horsfall.org>
> Yep, and I'm glad that I had bosses to whom I didn't have to explain why 
> my comments were so voluminous.
> 
> And who first said "Write your code as though the next person to maintain 
> it is a psychotic axe-wielding murderer who knows where you live"?  I've 
> often thought that way (as the murderer I mean, not the murderee).
> 
> I'd name names, but he might be on this list...
> 
I’ve always said that the person was a ‘reformed’ axe-wielding murderer
who knows where you live.

Please, a little decorum.

W.R.T. comments in code, and a bit of Unix, when I taught Unix Systems
programming at UCSD one of my students wanted to use his personal
computer for the programming. I didn’t care as long as it would pass the
tests I ran after the fact.

After his second homework was turned in, I stopped looking at his code
or even running it, as the comment blocks were just so well done. Nary
a comment in the function itself, just a block before each one very clearly
explaining what was happening.

	David



From lyndon at orthanc.ca  Fri Mar 23 06:20:23 2018
From: lyndon at orthanc.ca (Lyndon Nerenberg)
Date: Thu, 22 Mar 2018 13:20:23 -0700 (PDT)
Subject: [TUHS] Comments in early Unix systems
In-Reply-To: <201803221632.w2MGWSTC016570@freefriends.org>
References: <20180321141753.25C4418C088@mercury.lcs.mit.edu>
 <CAC20D2M6x5wn5_=HDWYsZyBqu_Ba58-oQ8Ca53XBmaRjS62=6Q@mail.gmail.com>
 <6c6699c0-15db-604a-181c-7dad282599e1@kilonet.net>
 <CABH=_VREt+Ay+T3wnGKvGyKn-7W7dn6K4vT7huBmX4a4GzjQKg@mail.gmail.com>
 <CAEoi9W6_-2HLs=ywM42OtOG00GeBd=c0odxXhtsDcZhKy-n4Ew@mail.gmail.com>
 <CAC20D2ORh+k9cBF1DgZ=A86YkrWKPtiNYzO=7MLz-=SNDTPEew@mail.gmail.com>
 <CABH=_VT+Pu=xZ=vk30Z3JrZN0cf=BG6hg7x++FTnb4iptzbNMw@mail.gmail.com>
 <20180321202810.GA6280@minnie.tuhs.org>
 <CALMnNGhD_3CbGaKx0_U0Hcbjq0E6Edecs39F0ZuWH-xys8gAcQ@mail.gmail.com>
 <20180322012720.GN9739@mcvoy.com>
 <F86441D1-FB0C-41D9-8519-E31F3238A235@quintile.net>
 <01d401d3c1f9$ebd18270$c3748750$@ronnatalie.com>
 <201803221632.w2MGWSTC016570@freefriends.org>
Message-ID: <alpine.BSF.2.21.1803221316390.94027@orthanc.ca>

> I'll agree with the latter part. But in my own code I try to be very
> careful to use NULL for pointers, '\0' for end of string,

In the '\0' case I have a preference for NUL, but admittedly it's easy to 
confuse/typo with NULL.  That convention follows from my habit of enuming 
ASCII constants with their three-letter 'names' (e.g. CAN, DLE, ...).

--lyndon


From bakul at bitblocks.com  Fri Mar 23 07:05:14 2018
From: bakul at bitblocks.com (Bakul Shah)
Date: Thu, 22 Mar 2018 14:05:14 -0700
Subject: [TUHS] long lived programs (was Re:  RIP John Backus
In-Reply-To: <284abf07f5b9d442caf233a8017a8cebb5518bbc@webmail.yaccman.com>
References: <284abf07f5b9d442caf233a8017a8cebb5518bbc@webmail.yaccman.com>
Message-ID: <D5A7C3A8-F85C-407D-9126-B34D56DE6251@bitblocks.com>

On Mar 17, 2018, at 3:27 PM, Steve Johnson <scj at yaccman.com> wrote:
> 
> Let me offer a somewhat different perspective on FORTRAN.  When an airplane is designed, the design undergoes a number of engineering tests under simulation at the design stage.  Many countries require that these simulation runs be archived for the lifetime of the airplane so that, in the event of a crash, they can be run again with the conditions experienced by the aircraft to see whether the problem was in the design.  Airplanes commonly take 10 years from first design to first shipment.  And then are sold for 10 years or so.  And the planes can fly for up to 30 years after that.   So these tests need to be written in a computer language that can be run 50 years in the future -- that is a stipulation of the archive requirement.  There really aren't any alternative languages that I'm aware of that could meet this criterion -- that's particularly true today, when there is a sea change from serial to parallel programming and it's hard to pick a winner with five decades of life ahead of it...
> 
> Does anyone have any candidates?

I was thinking about a similar issue after reading Bradshaw's
message about FORTRAN programs being critical to his country's
security. What happens in 50-100 years when such programs have
been in use for a long time but none of the original authors
may be alive? The world may have moved on to newer languages
and there may be very few people who study "ancient" computer
languages and even they won't have in-depth experience to
understand the nuances & traps of these languages well enough.
No guarantee that FORTRAN will be in much use then! Will it be
like in science fiction where ancient spaceships continue
working but no one knows what to do when they break?

Even on a much much smaller time scale I have seen million+
line code base, with original programmers long gone. Newer
programmers understand enough to add new layers of code or fix
some bugs but not enough to fix any deep problems. Such
programs are difficult to understand *today* due to their poor
structure but as they serve a useful purpose and continued to
be used.

We move archived data to newer media & may be make multiple
copies so as to be able to continue accessing them but when it
comes to "moving" critical programs to newer programming
languages, we are stuck. I think "y2k" was just a small taste
of this. We don't have enough tests to fully characterize
them, not clear specifications etc. You can reimplement a
small programs (up to 5K lines of C/C++ or so) with some
effort by analyzing their IO behavior but this gets
exponentially harder for larger programs.

The only thing I can think of is to use have programs that
translate programs in todays languages to a common but very
simple universal language for their "long term storage". May
be something like Lamport's TLA+? A very tough job.

We may be incurring a lot of "technical debt" that future
generations may have to pay!




From clemc at ccc.com  Fri Mar 23 07:35:20 2018
From: clemc at ccc.com (Clem Cole)
Date: Thu, 22 Mar 2018 17:35:20 -0400
Subject: [TUHS] long lived programs (was Re: RIP John Backus
In-Reply-To: <D5A7C3A8-F85C-407D-9126-B34D56DE6251@bitblocks.com>
References: <284abf07f5b9d442caf233a8017a8cebb5518bbc@webmail.yaccman.com>
 <D5A7C3A8-F85C-407D-9126-B34D56DE6251@bitblocks.com>
Message-ID: <CAC20D2NXwa3wKmwO4GkeKKWmrfBHqp11gDtx0i=kZAs_gTN6Dg@mail.gmail.com>

On Thu, Mar 22, 2018 at 5:05 PM, Bakul Shah <bakul at bitblocks.com> wrote:

>
> I was thinking about a similar issue after reading Bradshaw's
> message about FORTRAN programs being critical to his country's
> security. What happens in 50-100 years when such programs have
> been in use for a long time but none of the original authors
> may be alive?
>
​....​


>
> We may be incurring a lot of "technical debt" that future
> generations may have to pay!
>

​Maybe and maybe not.​ I worried about this a bit myself.  But I think the
difference I think is that while computer scientist may be using Fortran,
it is still pretty heavily used in the 'hard science' - certainly physics
and chemistry - because as was already pointed out -- it is still the best
language for doing complex mathematics.   And more over, the language (like
UNIX) has changed.  If you look at modern Fortran code, it looks more like
Algol than Fortran-IV.

Every scientific code that I know of (with the exception of SPICE), that
got recoded into C or C++ -- *has slowed down or gotten more complex.*
 And in SPICE3's case, TQ spend hours staring at Ellis code in SPICE2.  Tom
was on his own a 'bad ass' Fortran programmer, so he knew the trick Ellis
was taking.   And, like other codes I know, it took a bit before TQ got
SPICE3 in parity much less better.   In the end, what made SPICE3 replace
its older brother, was a new feature (easy addition of new transistor
models), but I think TQ would we one the first to tell you, it was very
hard to beat Ellis's FORTRAN.

The reality is Fortran is a great tool for what it is designed to do.   An
most of us on this list don't do that work, so we don't value it.   But if
you have to nasty math is partial differentials, complex numbers, etc -
Python, C, C++ are fine for very small things.   But if you have a
production code that is going to run for hours, if not days, on a
supercomputer, chances are it is Fortran.

For instance the last time I looked at WRF about a a year ago, which is the
premier weather code (and you hear about every night on the news with the
different 'models' the weatherman talk about), that is a FORTRAN-90 code.
 We were looking at the how to speed of the messaging stack under the
covers and were interested in how it stressed the networking stack.  It has
begin/end style looping, and its very modular.   The complex  and
unreadable part is MPI and the stuff to make it run in parallel.  It's not
the Fortran-ness.   I suspect anyone on this list like me, that reads C
could look at that code and understand it pretty quick.

The question (and a good one) is if you are not 'a Fortran person,' are you
going to be able to understand it well enough to not do damage to it, if
you modify it?  Which is of course the crux the question Bakul is asking.

I suspect, it is not as bad the science fiction movies profess.   Because
the codes have matured over time, which is not what happened with Y2K.
 Are their 'dusty decks' sure - but they are not quite so dusty as it might
think, and as importantly, the code we care about are and have been in
continuous use for years.  So there has been a new generation of
programmers that took of the maintenance of them.

ᐧ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180322/990a5dde/attachment.html>

From charles.unix.pro at gmail.com  Fri Mar 23 11:31:45 2018
From: charles.unix.pro at gmail.com (Charles Anthony)
Date: Thu, 22 Mar 2018 18:31:45 -0700
Subject: [TUHS] Comments in early Unix systems
In-Reply-To: <20180322012720.GN9739@mcvoy.com>
References: <20180321141753.25C4418C088@mercury.lcs.mit.edu>
 <CAC20D2M6x5wn5_=HDWYsZyBqu_Ba58-oQ8Ca53XBmaRjS62=6Q@mail.gmail.com>
 <6c6699c0-15db-604a-181c-7dad282599e1@kilonet.net>
 <CABH=_VREt+Ay+T3wnGKvGyKn-7W7dn6K4vT7huBmX4a4GzjQKg@mail.gmail.com>
 <CAEoi9W6_-2HLs=ywM42OtOG00GeBd=c0odxXhtsDcZhKy-n4Ew@mail.gmail.com>
 <CAC20D2ORh+k9cBF1DgZ=A86YkrWKPtiNYzO=7MLz-=SNDTPEew@mail.gmail.com>
 <CABH=_VT+Pu=xZ=vk30Z3JrZN0cf=BG6hg7x++FTnb4iptzbNMw@mail.gmail.com>
 <20180321202810.GA6280@minnie.tuhs.org>
 <CALMnNGhD_3CbGaKx0_U0Hcbjq0E6Edecs39F0ZuWH-xys8gAcQ@mail.gmail.com>
 <20180322012720.GN9739@mcvoy.com>
Message-ID: <CANV78LTbtgVm_VrmZKMy8ykb689GEwGayeLgJQG-PvS5j6dPGw@mail.gmail.com>

On Wed, Mar 21, 2018 at 6:27 PM, Larry McVoy <lm at mcvoy.com> wrote:

>
> I *HATE* comments that are not correct, hate that so much that if you did
> that we would talk, if you kept doing that, you are fired.  No comments
> are MUCH better than incorrect comments.
>
>
>From "Programming Pearls": "If the code and the comments disagree, they are
probably both wrong."

-- Charles
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180322/aba87c4a/attachment.html>

From doug at cs.dartmouth.edu  Fri Mar 23 11:54:07 2018
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Thu, 22 Mar 2018 21:54:07 -0400
Subject: [TUHS] Comments in early Unix systems
Message-ID: <201803230154.w2N1s75N002066@tahoe.cs.Dartmouth.EDU>

Thanks for the noweb story. A reward for straying off topic!

Doug


From doug at cs.dartmouth.edu  Fri Mar 23 12:53:53 2018
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Thu, 22 Mar 2018 22:53:53 -0400
Subject: [TUHS] long lived programs (was Re: RIP John Backus
Message-ID: <201803230253.w2N2rr6O005722@tahoe.cs.Dartmouth.EDU>

"The only thing I can think of is to use have programs that
translate programs in todays languages to a common but very
simple universal language for their "long term storage". May
be something like Lamport's TLA+? A very tough job.
"

Maybe not so hard. An existence proof is Brenda Baker's "struct",
which was in v7. It converted Fortran to Ratfor (which of course
turned it back to Fortran). Interestingly, authors found their
completely reorganized code easier to read than what they had
written in the first place. 

Her big discovery was a canonical form--it was not a matter of
taste or choice how the code got rearranged.

It would be harder to convert the code to say, Matlab,
because then you'd have to unravel COMMON statements and
format strings. It's easy to cook up nasty examples, like
getting away with writing behyond the end of an array, but
such things are rare in working code.

Doug


From tfb at tfeb.org  Fri Mar 23 20:43:30 2018
From: tfb at tfeb.org (Tim Bradshaw)
Date: Fri, 23 Mar 2018 10:43:30 +0000
Subject: [TUHS] long lived programs (was Re:  RIP John Backus
In-Reply-To: <D5A7C3A8-F85C-407D-9126-B34D56DE6251@bitblocks.com>
References: <284abf07f5b9d442caf233a8017a8cebb5518bbc@webmail.yaccman.com>
 <D5A7C3A8-F85C-407D-9126-B34D56DE6251@bitblocks.com>
Message-ID: <92ACA4B4-31AC-4202-95DD-14E30C5D164C@tfeb.org>

On 22 Mar 2018, at 21:05, Bakul Shah <bakul at bitblocks.com> wrote:
> 
> I was thinking about a similar issue after reading Bradshaw's
> message about FORTRAN programs being critical to his country's
> security. What happens in 50-100 years when such programs have
> been in use for a long time but none of the original authors
> may be alive? The world may have moved on to newer languages
> and there may be very few people who study "ancient" computer
> languages and even they won't have in-depth experience to
> understand the nuances & traps of these languages well enough.
> No guarantee that FORTRAN will be in much use then! Will it be
> like in science fiction where ancient spaceships continue
> working but no one knows what to do when they break?

My experience of large systems like this is that this isn't how they work at all.  The program I deal with (which is around 5 million lines naively (counting a lot of stuff which probably is not source but is in the source tree)) is looked after by probably several hundred people.  It's been through several major changes in its essential guts and in the next ten years or so it will be entirely replaced by a new version of itself to deal with scaling problems inherent in the current implementation.  We get a new machine every few years onto which it needs to be ported, and those machines have not all been just faster versions of the previous one, and will probably never be so.

What it doesn't do is to just sit there as some sacred artifact which no-one understands, and it's unlikely ever to do so.  The requirements for it to become like that would be at least that the technology of large-scale computers was entirely stable, compilers, libraries and operating systems had become entirely stable and people had stopped caring about making it do what it does better.  None of those things seems very likely to me.

(Just to be clear: this thing isn't simulating bombs: it's forecasting the weather.)

--tim

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180323/100a7e18/attachment.html>

From ron at ronnatalie.com  Sat Mar 24 01:51:29 2018
From: ron at ronnatalie.com (Ron Natalie)
Date: Fri, 23 Mar 2018 11:51:29 -0400
Subject: [TUHS] long lived programs
Message-ID: <02ab01d3c2be$cf335920$6d9a0b60$@ronnatalie.com>

A core package in a lot of the geospatial applications is a old piece of
mathematical code originally written in Fortran (probably in the sixties).
Someone probably in the 80's recoded the thing pretty much line for line
(maintaining the horrendous F66 variable names etc.) into C.     It's
probably ripe for a jump to something else now.

 

We've been through four major generations of the software.    The original
was all VAX based with specialized hardware (don't know what it was written
in).    We followed that on with a portable UNIX (but mostly Suns, but ours
worked on SGI, Ardent, Stellar, various IBM AIX platofrms, Apollo DN1000's,
HP, DEC Alphas).   This was primarily a C application.    Then right about
the year 2000, we jumped to C++ on Windows.    Subsequently it got back
ported to Linux.     Yes there are some modules that have been unchanged for
decades, but the system on the whole has been maintained.

 

The bigger issue than software getting obsoleted is that the platform needed
to run it goes away.   

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180323/a6ab4cdb/attachment.html>

From clemc at ccc.com  Sat Mar 24 01:57:36 2018
From: clemc at ccc.com (Clem Cole)
Date: Fri, 23 Mar 2018 11:57:36 -0400
Subject: [TUHS] long lived programs
In-Reply-To: <02ab01d3c2be$cf335920$6d9a0b60$@ronnatalie.com>
References: <02ab01d3c2be$cf335920$6d9a0b60$@ronnatalie.com>
Message-ID: <CAC20D2N15kvH0Sad9Xn6Cswjw9AG8Czf6GJVc=LqaFGbyPHscA@mail.gmail.com>

On Fri, Mar 23, 2018 at 11:51 AM, Ron Natalie <ron at ronnatalie.com> wrote:

>
> The bigger issue than software getting obsoleted is that the platform
> needed to run it goes away.
>
​+1

Although simh is huge step in that direction ;)
​
ᐧ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180323/065f6c5d/attachment.html>

From ron at ronnatalie.com  Sat Mar 24 02:32:41 2018
From: ron at ronnatalie.com (Ron Natalie)
Date: Fri, 23 Mar 2018 12:32:41 -0400
Subject: [TUHS] long lived programs
In-Reply-To: <CAC20D2N15kvH0Sad9Xn6Cswjw9AG8Czf6GJVc=LqaFGbyPHscA@mail.gmail.com>
References: <02ab01d3c2be$cf335920$6d9a0b60$@ronnatalie.com>
 <CAC20D2N15kvH0Sad9Xn6Cswjw9AG8Czf6GJVc=LqaFGbyPHscA@mail.gmail.com>
Message-ID: <02c401d3c2c4$90fe9ba0$b2fbd2e0$@ronnatalie.com>

➢ Although simh is huge step in that direction ;)
 
Yep, sometimes that's the easier solution.    Remember the old Honeywell IMPs.     BBN wanted to move forward, but all the code was in 516 emulators (having been ported over from the PDP-1, they should have realized that portability would be important).   They built the C-30 to emulate the Honeywell.

Of course, this isn't even accounting for the VAX emulating the PDP and the like.

You do find some relics still running stuff.    I remember seing a new computer being installed at some FAA facilities.   It was some Apollo systems long after HP had pulled the plug on the DomainOS and the related hardware. 

I still remember a while when we were in the business of porting/selling MOTIF on a wide variety of platforms.    One day, the reps from Stellar insisted they need their loaner machine back.   This was a trade show unit and had an huge anvil shipping case.    I packed it up and put it on our loading dock.    The next day Stellar announced they were out of business.   I didn't think anything about it for a couple of years when I went out to our loading dock and said "Is this stupid thing still here."   They had never come for it.   I then was called into our sales manager's office.    Some guy needs a MOTIF for a Stellar.    I chuckle.    He goes "Yeah I know they're out of business."   I tell him that today's his lucky day.   I still have one.   I uncrated the thing, wrote him out a tape, and packed it back up.    Last I saw one of the CPU boards was hanging on the wall of our conference room as a decoration and another programmer and ripped out the Wyse PC the thing had in the top of it as a boot-up/maintenance processor to take home.



From lars at nocrew.org  Sat Mar 24 02:25:43 2018
From: lars at nocrew.org (Lars Brinkhoff)
Date: Fri, 23 Mar 2018 16:25:43 +0000
Subject: [TUHS] long lived programs
In-Reply-To: <CAC20D2N15kvH0Sad9Xn6Cswjw9AG8Czf6GJVc=LqaFGbyPHscA@mail.gmail.com>
 (Clem Cole's message of "Fri, 23 Mar 2018 11:57:36 -0400")
References: <02ab01d3c2be$cf335920$6d9a0b60$@ronnatalie.com>
 <CAC20D2N15kvH0Sad9Xn6Cswjw9AG8Czf6GJVc=LqaFGbyPHscA@mail.gmail.com>
Message-ID: <7wfu4qrc6w.fsf@junk.nocrew.org>

Clem Cole wrote:
> Ron Natalie wrote:
>>  The bigger issue than software getting obsoleted is that the platform
>>  needed to run it goes away. 
>
> Although simh is huge step in that direction ;)

I imagine a future where SIMH itself only runs on obsolete platforms and
has to be run inside an emulator.  Repeat, etc etc.


From stewart at serissa.com  Sat Mar 24 02:59:03 2018
From: stewart at serissa.com (Lawrence Stewart)
Date: Fri, 23 Mar 2018 12:59:03 -0400
Subject: [TUHS] long lived programs
In-Reply-To: <7wfu4qrc6w.fsf@junk.nocrew.org>
References: <02ab01d3c2be$cf335920$6d9a0b60$@ronnatalie.com>
 <CAC20D2N15kvH0Sad9Xn6Cswjw9AG8Czf6GJVc=LqaFGbyPHscA@mail.gmail.com>
 <7wfu4qrc6w.fsf@junk.nocrew.org>
Message-ID: <C18A05EC-8E01-4716-9B99-51AD7AF4D420@serissa.com>

Suppose we define a machine architecture not for building hardware, but specifically for itself being easy to emulate?

This is by analogy to para-virtualized device drivers, which are not there to model real devices, but to be easy to support in a virtual machine environment.
 

> On 2018, Mar 23, at 12:25 PM, Lars Brinkhoff <lars at nocrew.org> wrote:
> 
> Clem Cole wrote:
>> Ron Natalie wrote:
>>> The bigger issue than software getting obsoleted is that the platform
>>> needed to run it goes away. 
>> 
>> Although simh is huge step in that direction ;)
> 
> I imagine a future where SIMH itself only runs on obsolete platforms and
> has to be run inside an emulator.  Repeat, etc etc.



From usotsuki at buric.co  Sat Mar 24 03:31:49 2018
From: usotsuki at buric.co (Steve Nickolas)
Date: Fri, 23 Mar 2018 13:31:49 -0400 (EDT)
Subject: [TUHS] long lived programs
In-Reply-To: <C18A05EC-8E01-4716-9B99-51AD7AF4D420@serissa.com>
References: <02ab01d3c2be$cf335920$6d9a0b60$@ronnatalie.com>
 <CAC20D2N15kvH0Sad9Xn6Cswjw9AG8Czf6GJVc=LqaFGbyPHscA@mail.gmail.com>
 <7wfu4qrc6w.fsf@junk.nocrew.org>
 <C18A05EC-8E01-4716-9B99-51AD7AF4D420@serissa.com>
Message-ID: <alpine.BSF.2.02.1803231329210.43710@frieza.hoshinet.org>

On Fri, 23 Mar 2018, Lawrence Stewart wrote:

> Suppose we define a machine architecture not for building hardware, but 
> specifically for itself being easy to emulate?
>
> This is by analogy to para-virtualized device drivers, which are not 
> there to model real devices, but to be easy to support in a virtual 
> machine environment.

I've had an idea to create a sort of idealized VM for running C in (like a 
JVM designed specifically for C) and a full VM-OS type thing as well - but 
I couldn't figure out how to go about implementing it.  Still...sounds 
similar to what you propose, which might not be a bad idea.

-uso.


From bakul at bitblocks.com  Sat Mar 24 04:27:08 2018
From: bakul at bitblocks.com (Bakul Shah)
Date: Fri, 23 Mar 2018 11:27:08 -0700
Subject: [TUHS] long lived programs (was Re: RIP John Backus
In-Reply-To: <201803230253.w2N2rr6O005722@tahoe.cs.Dartmouth.EDU>
References: <201803230253.w2N2rr6O005722@tahoe.cs.Dartmouth.EDU>
Message-ID: <5DAB3926-947C-4DC1-8C9D-04ADB40FB007@bitblocks.com>

On Mar 22, 2018, at 7:53 PM, Doug McIlroy <doug at cs.dartmouth.edu> wrote:
> 
> "The only thing I can think of is to use have programs that
> translate programs in todays languages to a common but very
> simple universal language for their "long term storage". May
> be something like Lamport's TLA+? A very tough job.
> "
> 
> Maybe not so hard. An existence proof is Brenda Baker's "struct",
> which was in v7. It converted Fortran to Ratfor (which of course
> turned it back to Fortran). Interestingly, authors found their
> completely reorganized code easier to read than what they had
> written in the first place.
> 
> Her big discovery was a canonical form--it was not a matter of
> taste or choice how the code got rearranged.
> 
> It would be harder to convert the code to say, Matlab,
> because then you'd have to unravel COMMON statements and
> format strings. It's easy to cook up nasty examples, like
> getting away with writing behyond the end of an array, but
> such things are rare in working code.

I can believe that for Fortran but for C/C++ or other such 
less well defined languages this may be much harder. Far
easier to write an emulator for x86 and that is fine if all
you want to do is run the same old compiled program but if you
want to make changes, de-compiling x86 code to something
structured would be much harder. Compiling the original code
to a multi-paradigm language such as Scheme or Lisp may be
another alternative....
 
[Aside:
Thanks for mentioning the name of this program as I had 
forgotten it.  I used "struct" once to convert a Fortran 
program to Ratfor and then manually to C. This was for 
programming PALs and we wanted to make some local changes.
IIRC, this was back in '82, back when vendors gave you
programs with sources for their devices, unlike the Xilinx &
Altera of today who don't even publish bitstream formats used
to program their devices.]


From bakul at bitblocks.com  Sat Mar 24 05:28:47 2018
From: bakul at bitblocks.com (Bakul Shah)
Date: Fri, 23 Mar 2018 12:28:47 -0700
Subject: [TUHS] long lived programs (was Re: RIP John Backus
In-Reply-To: <CAC20D2NXwa3wKmwO4GkeKKWmrfBHqp11gDtx0i=kZAs_gTN6Dg@mail.gmail.com>
References: <284abf07f5b9d442caf233a8017a8cebb5518bbc@webmail.yaccman.com>
 <D5A7C3A8-F85C-407D-9126-B34D56DE6251@bitblocks.com>
 <CAC20D2NXwa3wKmwO4GkeKKWmrfBHqp11gDtx0i=kZAs_gTN6Dg@mail.gmail.com>
Message-ID: <F7B50FE2-49A8-431E-9C5D-7B40B6C28665@bitblocks.com>

On Mar 22, 2018, at 2:35 PM, Clem Cole <clemc at ccc.com> wrote:
> 
> The question (and a good one) is if you are not 'a Fortran person,' are you going to be able to understand it well enough to not do damage to it, if you modify it?  Which is of course the crux the question Bakul is asking.

This is indeed the case, but I am asking not just about 
Fortran.  Will we continue programming in 50-100 years in
C/C++/Java/Fortran?  That is, are we going through the
Cambrian Explosion of programming languages now and it will
settle down in a few decades or have we just started?

> I suspect, it is not as bad the science fiction movies profess.   Because the codes have matured over time, which is not what happened with Y2K.   Are their 'dusty decks' sure - but they are not quite so dusty as it might think, and as importantly, the code we care about are and have been in continuous use for years.  So there has been a new generation of programmers that took of the maintenance of them.

Perhaps a more important question is what % of programs are
important enough and will be around in 50-100 years.

On Mar 23, 2018, at 3:43 AM, Tim Bradshaw <tfb at tfeb.org> wrote:
> 
> My experience of large systems like this is that this isn't how they work at all.  The program I deal with (which is around 5 million lines naively (counting a lot of stuff which probably is not source but is in the source tree)) is looked after by probably several hundred people.  It's been through several major changes in its essential guts and in the next ten years or so it will be entirely replaced by a new version of itself to deal with scaling problems inherent in the current implementation.  We get a new machine every few years onto which it needs to be ported, and those machines have not all been just faster versions of the previous one, and will probably never be so.

By now most major systems has been computerized. Banks,
govt, finance, communication, shipping, various industries,
research, publishing, medicine etc. Will the critical
systems within each area have as many resources as & when
needed as weather forecasting system Tim is talking about?
[Of course, the same question can be asked in relation to
the conversion I am wondering about!]

On Mar 23, 2018, at 8:51 AM, Ron Natalie <ron at ronnatalie.com> wrote:
> 
> A core package in a lot of the geospatial applications is a old piece of mathematical code originally written in Fortran (probably in the sixties).   Someone probably in the 80’s recoded the thing pretty much line for line (maintaining the horrendous F66 variable names etc…) into C.     It’s probably ripe for a jump to something else now.
>  
> We’ve been through four major generations of the software.    The original was all VAX based with specialized hardware (don’t know what it was written in).    We followed that on with a portable UNIX (but mostly Suns, but ours worked on SGI, Ardent, Stellar, various IBM AIX platofrms, Apollo DN1000’s, HP, DEC Alphas).   This was primarily a C application.    Then right about the year 2000, we jumped to C++ on Windows.    Subsequently it got back ported to Linux.     Yes there are some modules that have been unchanged for decades, but the system on the whole has been maintained.

I wonder if we will continue doing this sort of adhoc
but expensive rewrites for a long time.... 

[This may be somewhat relevant to TUHS, from a future
 historian's perspective :-)]



From lm at mcvoy.com  Sat Mar 24 05:44:13 2018
From: lm at mcvoy.com (Larry McVoy)
Date: Fri, 23 Mar 2018 12:44:13 -0700
Subject: [TUHS] long lived programs (was Re: RIP John Backus
In-Reply-To: <F7B50FE2-49A8-431E-9C5D-7B40B6C28665@bitblocks.com>
References: <284abf07f5b9d442caf233a8017a8cebb5518bbc@webmail.yaccman.com>
 <D5A7C3A8-F85C-407D-9126-B34D56DE6251@bitblocks.com>
 <CAC20D2NXwa3wKmwO4GkeKKWmrfBHqp11gDtx0i=kZAs_gTN6Dg@mail.gmail.com>
 <F7B50FE2-49A8-431E-9C5D-7B40B6C28665@bitblocks.com>
Message-ID: <20180323194413.GL18044@mcvoy.com>

I'm really not worried about it.  When I got into kernel programming
I had no idea what I was doing.  I just kept at it, did small stuff,
the bigger picture slowly came into focus.  After a couple of years there
wasn't much that I wouldn't take on.  I stayed away from drivers because I
had figured out that Sun had their stuff but it was going to be different
than SGI's stuff and both different from PC stuff (even the PC stuff was
different, I would have been working on ISA bus devices and that's long
gone so far as I know).  But file systems, networking, VM, processes,
signals, all of that stuff was pretty easy after you got to know the code.

Every year someone takes some young hotshot and points them at some
"impossible" thing and one of them makes it work.  I don't see that
changing.

On Fri, Mar 23, 2018 at 12:28:47PM -0700, Bakul Shah wrote:
> On Mar 22, 2018, at 2:35 PM, Clem Cole <clemc at ccc.com> wrote:
> > 
> > The question (and a good one) is if you are not 'a Fortran person,' are you going to be able to understand it well enough to not do damage to it, if you modify it?  Which is of course the crux the question Bakul is asking.
> 
> This is indeed the case, but I am asking not just about 
> Fortran.  Will we continue programming in 50-100 years in
> C/C++/Java/Fortran?  That is, are we going through the
> Cambrian Explosion of programming languages now and it will
> settle down in a few decades or have we just started?
> 
> > I suspect, it is not as bad the science fiction movies profess.   Because the codes have matured over time, which is not what happened with Y2K.   Are their 'dusty decks' sure - but they are not quite so dusty as it might think, and as importantly, the code we care about are and have been in continuous use for years.  So there has been a new generation of programmers that took of the maintenance of them.
> 
> Perhaps a more important question is what % of programs are
> important enough and will be around in 50-100 years.
> 
> On Mar 23, 2018, at 3:43 AM, Tim Bradshaw <tfb at tfeb.org> wrote:
> > 
> > My experience of large systems like this is that this isn't how they work at all.  The program I deal with (which is around 5 million lines naively (counting a lot of stuff which probably is not source but is in the source tree)) is looked after by probably several hundred people.  It's been through several major changes in its essential guts and in the next ten years or so it will be entirely replaced by a new version of itself to deal with scaling problems inherent in the current implementation.  We get a new machine every few years onto which it needs to be ported, and those machines have not all been just faster versions of the previous one, and will probably never be so.
> 
> By now most major systems has been computerized. Banks,
> govt, finance, communication, shipping, various industries,
> research, publishing, medicine etc. Will the critical
> systems within each area have as many resources as & when
> needed as weather forecasting system Tim is talking about?
> [Of course, the same question can be asked in relation to
> the conversion I am wondering about!]
> 
> On Mar 23, 2018, at 8:51 AM, Ron Natalie <ron at ronnatalie.com> wrote:
> > 
> > A core package in a lot of the geospatial applications is a old piece of mathematical code originally written in Fortran (probably in the sixties).   Someone probably in the 80???s recoded the thing pretty much line for line (maintaining the horrendous F66 variable names etc???) into C.     It???s probably ripe for a jump to something else now.
> >  
> > We???ve been through four major generations of the software.    The original was all VAX based with specialized hardware (don???t know what it was written in).    We followed that on with a portable UNIX (but mostly Suns, but ours worked on SGI, Ardent, Stellar, various IBM AIX platofrms, Apollo DN1000???s, HP, DEC Alphas).   This was primarily a C application.    Then right about the year 2000, we jumped to C++ on Windows.    Subsequently it got back ported to Linux.     Yes there are some modules that have been unchanged for decades, but the system on the whole has been maintained.
> 
> I wonder if we will continue doing this sort of adhoc
> but expensive rewrites for a long time.... 
> 
> [This may be somewhat relevant to TUHS, from a future
>  historian's perspective :-)]

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


From scj at yaccman.com  Sat Mar 24 06:50:15 2018
From: scj at yaccman.com (Steve Johnson)
Date: Fri, 23 Mar 2018 13:50:15 -0700
Subject: [TUHS] long lived programs
In-Reply-To: <5DAB3926-947C-4DC1-8C9D-04ADB40FB007@bitblocks.com>
Message-ID: <e4bb1950ab54f6b5319e718be78bbfe7738c6c00@webmail.yaccman.com>

Another issue to consider.  I once talked with someone who was
designing nuclear reactors.  They had a similar requirement to
archive their design simulations.  But in this case, part of the
requirement was to pass some standard simulation tests (in FORTRAN, of
course).  He was complaining that these programs had bugs and didn't
give the right answer.   So they ran the corrected programs to make
sure the thing would not blow up, and then tweaked their parameters so
it would pass the buggy program that was written into law...

Steve


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180323/f34081d8/attachment.html>

From clemc at ccc.com  Sat Mar 24 07:07:27 2018
From: clemc at ccc.com (Clem Cole)
Date: Fri, 23 Mar 2018 17:07:27 -0400
Subject: [TUHS] long lived programs
In-Reply-To: <e4bb1950ab54f6b5319e718be78bbfe7738c6c00@webmail.yaccman.com>
References: <5DAB3926-947C-4DC1-8C9D-04ADB40FB007@bitblocks.com>
 <e4bb1950ab54f6b5319e718be78bbfe7738c6c00@webmail.yaccman.com>
Message-ID: <CAC20D2NK4BmREezVEryo4c0EYVR5dwVfSgOkVwrukd1Ou=6LkQ@mail.gmail.com>

On Fri, Mar 23, 2018 at 4:50 PM, Steve Johnson <scj at yaccman.com> wrote:

> Another issue to consider.  I once talked with someone who was designing
> nuclear reactors.  They had a similar requirement to archive their design
> simulations.  But in this case, part of the requirement was to pass some
> standard simulation tests (in FORTRAN, of course).  He was complaining that
> these programs had bugs and didn't give the right answer.   So they ran the
> corrected programs to make sure the thing would not blow up, and then
> tweaked their parameters so it would pass the buggy program that was
> written into law...
>
> Steve
>

​That's not Fortran's problem -- that is our legal system.​

ᐧ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180323/4e169ddf/attachment.html>

From clemc at ccc.com  Sat Mar 24 07:23:18 2018
From: clemc at ccc.com (Clem Cole)
Date: Fri, 23 Mar 2018 17:23:18 -0400
Subject: [TUHS] long lived programs (was Re: RIP John Backus
In-Reply-To: <F7B50FE2-49A8-431E-9C5D-7B40B6C28665@bitblocks.com>
References: <284abf07f5b9d442caf233a8017a8cebb5518bbc@webmail.yaccman.com>
 <D5A7C3A8-F85C-407D-9126-B34D56DE6251@bitblocks.com>
 <CAC20D2NXwa3wKmwO4GkeKKWmrfBHqp11gDtx0i=kZAs_gTN6Dg@mail.gmail.com>
 <F7B50FE2-49A8-431E-9C5D-7B40B6C28665@bitblocks.com>
Message-ID: <CAC20D2P6dX+ZavT=DuvfbE4k65qFRsGhzSW9fhp6q4Qr_hRqOQ@mail.gmail.com>

On Fri, Mar 23, 2018 at 3:28 PM, Bakul Shah <bakul at bitblocks.com> wrote:

>
> By now most major systems has been computerized. Banks,
> govt, finance, communication, shipping, various industries,
> research, publishing, medicine etc. Will the critical
> systems within each area have as many resources as & when
> needed as weather forecasting system Tim is talking about?
> [Of course, the same question can be asked in relation to
> the conversion I am wondering about!]


​I suspect we agree more than we disagree.

I offer the following observation.    Except for high end HPC particularly
DoD, DoE and big science types of applications, there has been a
'Christiansen' style​ disruption were a 'worse' technology was created and
loved by a new group of users and that new technology eventually got better
and replaced (disrupted) the earlier one (Banks/Finance were cobol - now
its Oracle and the like, SAP et al; Communications was SS7 over custom HW,
now its IP running on all sorts of stuff).  The key is the disruptor was on
a economic curve that make it successful.

But HE HPC is the same people, doing the same things they did before -- the
difference is the data sets are larger, need for better precision,
different data representation (e.g., graphics). Again, the math has not
changed.  But I don't see a new customer for those style of applications,
which is what is needed to basically bank roll the replacement (originally
less 'good') technology.  The economics are their to replace it - at least
so far.

The idea of the 'under served' or 'missing middle' market for HPC has been
discussed for a bit.  I used to believe it.  I'm not so sure now.

Which bringing this back to UNIX.  Linux is the UNIX disruptor - which is
great.  Linux keeps 'UNIX' alive and getting better.  I don't see an
economic reason to replace it, but who knows.  Maybe that's what the new
good folks at Goggle, Amazon, Intel or some University is doing.  But so
far, the economics is not there.

Clem
ᐧ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180323/8e454207/attachment.html>

From imp at bsdimp.com  Sat Mar 24 07:36:02 2018
From: imp at bsdimp.com (Warner Losh)
Date: Fri, 23 Mar 2018 15:36:02 -0600
Subject: [TUHS] long lived programs (was Re: RIP John Backus
In-Reply-To: <CAC20D2P6dX+ZavT=DuvfbE4k65qFRsGhzSW9fhp6q4Qr_hRqOQ@mail.gmail.com>
References: <284abf07f5b9d442caf233a8017a8cebb5518bbc@webmail.yaccman.com>
 <D5A7C3A8-F85C-407D-9126-B34D56DE6251@bitblocks.com>
 <CAC20D2NXwa3wKmwO4GkeKKWmrfBHqp11gDtx0i=kZAs_gTN6Dg@mail.gmail.com>
 <F7B50FE2-49A8-431E-9C5D-7B40B6C28665@bitblocks.com>
 <CAC20D2P6dX+ZavT=DuvfbE4k65qFRsGhzSW9fhp6q4Qr_hRqOQ@mail.gmail.com>
Message-ID: <CANCZdfpJbW0jsfjHs6JdqyqVreV0CPuHFqe=0mP_DdMp_X5EYQ@mail.gmail.com>

On Fri, Mar 23, 2018 at 3:23 PM, Clem Cole <clemc at ccc.com> wrote:
>
> Which bringing this back to UNIX.  Linux is the UNIX disruptor - which is
> great.  Linux keeps 'UNIX' alive and getting better.  I don't see an
> economic reason to replace it, but who knows.  Maybe that's what the new
> good folks at Goggle, Amazon, Intel or some University is doing.  But so
> far, the economics is not there.
>

Speaking of how ancient code works... There's still AT&T code dating to v5
or older in *BSD.... It's been updated, improved upon, parts replaced, etc.
But there's still some bits dating all the way back to those early times.
Having competition from Linux is great and keeps the BSDs honest...

Warner

> ᐧ
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180323/7f03f6d6/attachment.html>

From scj at yaccman.com  Sat Mar 24 08:02:57 2018
From: scj at yaccman.com (Steve Johnson)
Date: Fri, 23 Mar 2018 15:02:57 -0700
Subject: [TUHS] long lived programs (was Re: RIP John Backus
In-Reply-To: <CANCZdfpJbW0jsfjHs6JdqyqVreV0CPuHFqe=0mP_DdMp_X5EYQ@mail.gmail.com>
Message-ID: <11b473d966bf0dd48f5f1c10e55974173010e5aa@webmail.yaccman.com>


Reminds me a bit of the old saying: "This is George Washington's
Axe.  Of course, it's had six new handles and four new heads since he
owned it..."

Steve

----- Original Message -----
From:
 "Warner Losh" <imp at bsdimp.com>

To:
"Clem Cole" <clemc at ccc.com>
Cc:
"TUHS main list" <tuhs at minnie.tuhs.org>
Sent:
Fri, 23 Mar 2018 15:36:02 -0600
Subject:
Re: [TUHS] long lived programs (was Re: RIP John Backus

On Fri, Mar 23, 2018 at 3:23 PM, Clem Cole <clemc at ccc.com [1]>
 wrote:Which bringing this back to UNIX.  Linux is the UNIX 

disruptor - which is great.  Linux keeps 'UNIX' alive and getting
better.  I don't see an economic reason to replace it, but who
knows.  Maybe that's what the new good folks at Goggle, Amazon, Intel
or some University is doing.  But so far, the economics is not
there.

Speaking of how ancient code works... There's still AT&T code dating
to v5 or older in *BSD.... It's been updated, improved upon, parts
replaced, etc. But there's still some bits dating all the way back to
those early times. Having competition from Linux is great and keeps
the BSDs honest...

Warner
ᐧ

 

Links:
------
[1] mailto:clemc at ccc.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180323/3aaf806f/attachment.html>

From doug at cs.dartmouth.edu  Sat Mar 24 11:26:29 2018
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Fri, 23 Mar 2018 21:26:29 -0400
Subject: [TUHS] mail tuhs@minnie.tuhs.org
Message-ID: <201803240126.w2O1QTB5109348@tahoe.cs.Dartmouth.EDU>

[TUHS] long lived programs (was Re: RIP John Backus
> Every year someone takes some young hotshot and points them at some
"impossible" thing and one of them makes it work.  I don't see that
changing.

Case in point.
We hired Tom Killian, a young high-energy physicist  disenchanted
with contributing to hundred-author papers. He'd done plenty of
instrument programming, but no operating systems. So, high-energy
as he was, he cooked up an exercise to get his feet wet.

The result: /proc

Doug


From lm at mcvoy.com  Sat Mar 24 11:54:36 2018
From: lm at mcvoy.com (Larry McVoy)
Date: Fri, 23 Mar 2018 18:54:36 -0700
Subject: [TUHS] mail tuhs@minnie.tuhs.org
In-Reply-To: <201803240126.w2O1QTB5109348@tahoe.cs.Dartmouth.EDU>
References: <201803240126.w2O1QTB5109348@tahoe.cs.Dartmouth.EDU>
Message-ID: <20180324015436.GQ18044@mcvoy.com>

On Fri, Mar 23, 2018 at 09:26:29PM -0400, Doug McIlroy wrote:
> [TUHS] long lived programs (was Re: RIP John Backus
> > Every year someone takes some young hotshot and points them at some
> "impossible" thing and one of them makes it work.  I don't see that
> changing.
> 
> Case in point.
> We hired Tom Killian, a young high-energy physicist  disenchanted
> with contributing to hundred-author papers. He'd done plenty of
> instrument programming, but no operating systems. So, high-energy
> as he was, he cooked up an exercise to get his feet wet.
> 
> The result: /proc

Didn't Roger Faulkner have something to do with that?  Or did he come 
after?

I ask because Roger and I were friends, so I'm always curious about his
history.  How we became friends is some folklore from Sun, it was when
Solaris was a thing so it was SysV based and it had /proc.  I had some
question about /proc and I heard Roger was the guy, he was pretty much 
directly under me in building 5, I went down and kind of hung out in
his doorway waiting for him to look up.  Nothing.  10 minutes later,
nothing, he's staring intently at his screen and working, I might as
well have been invisible.

So I go into his office and sit on his desk.

Without looking up he says something like "who the hell are you and what
do you want?".

"I want to ask you a question"

"And why should I answer?"

"Because I'm going to sit on your desk and belch and fart until you do"

He leaned back, roared with laughter, and we became friends right there.

He's left us, I still miss him.  Huge nerd, cared deeply about doing the
right thing in the code.

--lm


From steffen at sdaoden.eu  Sun Mar 25 12:07:29 2018
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Sun, 25 Mar 2018 04:07:29 +0200
Subject: [TUHS] 1978-03-25 - 2018-03-25: 40 years BSD Mail
Message-ID: <20180325020729.t9MY5%steffen@sdaoden.eu>

On this day in 1978 Kurt Shoens placed the following comment in
def.h (the fork i maintain keeps it in nail.h):

  /*
   * Mail -- a mail program
   *
   * Author: Kurt Shoens (UCB) March 25, 1978
   */

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)


From emu at e-bbes.com  Mon Mar 26 05:56:30 2018
From: emu at e-bbes.com (emanuel stiebler)
Date: Sun, 25 Mar 2018 13:56:30 -0600
Subject: [TUHS] daemons are not to be exorcised
In-Reply-To: <CAKr6gn3nuFKhQ5cx124kiSuGi3Znbs3-zccpe5KGUn-o-bEcpw@mail.gmail.com>
References: <CAFCBnZsS8Si6YGD4w_3W_znf3J5nVZGThkHVuQm5nD+FFm0DOg@mail.gmail.com>
 <CABH=_VQ3w+XtR3Ow1m6g69828CTDY3SMduCNN-LevO_EZFKypg@mail.gmail.com>
 <CAKr6gn3nuFKhQ5cx124kiSuGi3Znbs3-zccpe5KGUn-o-bEcpw@mail.gmail.com>
Message-ID: <660e1afc-05c6-6192-2168-23302df0b1ed@e-bbes.com>

On 2018-03-20 11:56, George Michaelson wrote:
> I got given the last generation PDP-11 on a chip, in a 72pin DIP. I
> gave it to somebody else who could use it. At the time, I thought it
> was Teh Awesome l33t to have an entire pdp11 on one chip. imagine! my
> god, the power, the power. I think the day is coming when a CPU has
> gold pins top and bottom. they have a very large number of pins.
> Somebody smart will have to invent code to work out how to wire the
> pins. Oh, hang on, thats why Djikstra's algorrithm which lies at the
> heart of routing protocols was written back in the day. oh dear.. its
> turtles all the way down isn't it?

Could you tell us more about this 72-pin version of a pdp11?


From ggm at algebras.org  Mon Mar 26 19:44:22 2018
From: ggm at algebras.org (George Michaelson)
Date: Mon, 26 Mar 2018 09:44:22 +0000
Subject: [TUHS] daemons are not to be exorcised
In-Reply-To: <660e1afc-05c6-6192-2168-23302df0b1ed@e-bbes.com>
References: <CAFCBnZsS8Si6YGD4w_3W_znf3J5nVZGThkHVuQm5nD+FFm0DOg@mail.gmail.com>
 <CABH=_VQ3w+XtR3Ow1m6g69828CTDY3SMduCNN-LevO_EZFKypg@mail.gmail.com>
 <CAKr6gn3nuFKhQ5cx124kiSuGi3Znbs3-zccpe5KGUn-o-bEcpw@mail.gmail.com>
 <660e1afc-05c6-6192-2168-23302df0b1ed@e-bbes.com>
Message-ID: <CAKr6gn3EZ8S-F7kf0WZbpW1BEOJB1zRUb3zi9gSTUwn4359jew@mail.gmail.com>

I never ran it. It was a huge, ceramic enclosed DIP. Ginormous.
BIggest chip I'd ever seen. I think it required dual voltages.

I can see specsheets for what is called a J11. I don't think I
remember it looking like that, but it was a long time ago.

-G

On Sun, Mar 25, 2018 at 7:56 PM, emanuel stiebler <emu at e-bbes.com> wrote:
> On 2018-03-20 11:56, George Michaelson wrote:
>> I got given the last generation PDP-11 on a chip, in a 72pin DIP. I
>> gave it to somebody else who could use it. At the time, I thought it
>> was Teh Awesome l33t to have an entire pdp11 on one chip. imagine! my
>> god, the power, the power. I think the day is coming when a CPU has
>> gold pins top and bottom. they have a very large number of pins.
>> Somebody smart will have to invent code to work out how to wire the
>> pins. Oh, hang on, thats why Djikstra's algorrithm which lies at the
>> heart of routing protocols was written back in the day. oh dear.. its
>> turtles all the way down isn't it?
>
> Could you tell us more about this 72-pin version of a pdp11?


From emu at e-bbes.com  Mon Mar 26 22:38:34 2018
From: emu at e-bbes.com (emanuel stiebler)
Date: Mon, 26 Mar 2018 06:38:34 -0600
Subject: [TUHS] daemons are not to be exorcised
In-Reply-To: <CAKr6gn3EZ8S-F7kf0WZbpW1BEOJB1zRUb3zi9gSTUwn4359jew@mail.gmail.com>
References: <CAFCBnZsS8Si6YGD4w_3W_znf3J5nVZGThkHVuQm5nD+FFm0DOg@mail.gmail.com>
 <CABH=_VQ3w+XtR3Ow1m6g69828CTDY3SMduCNN-LevO_EZFKypg@mail.gmail.com>
 <CAKr6gn3nuFKhQ5cx124kiSuGi3Znbs3-zccpe5KGUn-o-bEcpw@mail.gmail.com>
 <660e1afc-05c6-6192-2168-23302df0b1ed@e-bbes.com>
 <CAKr6gn3EZ8S-F7kf0WZbpW1BEOJB1zRUb3zi9gSTUwn4359jew@mail.gmail.com>
Message-ID: <3f9a72cd-eca0-2216-fa26-66bdc22d89b4@e-bbes.com>

On 2018-03-26 03:44, George Michaelson wrote:
> I never ran it. It was a huge, ceramic enclosed DIP. Ginormous.
> BIggest chip I'd ever seen. I think it required dual voltages.
>
> I can see specsheets for what is called a J11. I don't think I
> remember it looking like that, but it was a long time ago.

That's why I was asking. I know the J11 pretty well, with it's 60 pins,
it is big. Was curious about a bigger one ;-)

Cheers & thanks!


> -G
>
> On Sun, Mar 25, 2018 at 7:56 PM, emanuel stiebler <emu at e-bbes.com> wrote:
>> On 2018-03-20 11:56, George Michaelson wrote:
>>> I got given the last generation PDP-11 on a chip, in a 72pin DIP. I
>>> gave it to somebody else who could use it. At the time, I thought it
>>> was Teh Awesome l33t to have an entire pdp11 on one chip. imagine! my
>>> god, the power, the power. I think the day is coming when a CPU has
>>> gold pins top and bottom. they have a very large number of pins.
>>> Somebody smart will have to invent code to work out how to wire the
>>> pins. Oh, hang on, thats why Djikstra's algorrithm which lies at the
>>> heart of routing protocols was written back in the day. oh dear.. its
>>> turtles all the way down isn't it?
>>
>> Could you tell us more about this 72-pin version of a pdp11?
>
>


From tfb at tfeb.org  Mon Mar 26 23:43:22 2018
From: tfb at tfeb.org (Tim Bradshaw)
Date: Mon, 26 Mar 2018 14:43:22 +0100
Subject: [TUHS] long lived programs (was Re: RIP John Backus
In-Reply-To: <F7B50FE2-49A8-431E-9C5D-7B40B6C28665@bitblocks.com>
References: <284abf07f5b9d442caf233a8017a8cebb5518bbc@webmail.yaccman.com>
 <D5A7C3A8-F85C-407D-9126-B34D56DE6251@bitblocks.com>
 <CAC20D2NXwa3wKmwO4GkeKKWmrfBHqp11gDtx0i=kZAs_gTN6Dg@mail.gmail.com>
 <F7B50FE2-49A8-431E-9C5D-7B40B6C28665@bitblocks.com>
Message-ID: <D51BFDAA-889B-4A9F-BAA4-8A961FFB7F8D@tfeb.org>

On 23 Mar 2018, at 19:28, Bakul Shah <bakul at bitblocks.com> wrote:
> 
> By now most major systems has been computerized. Banks,
> govt, finance, communication, shipping, various industries,
> research, publishing, medicine etc. Will the critical
> systems within each area have as many resources as & when
> needed as weather forecasting system Tim is talking about?

I think that this is indeed a problem: it just isn't a problem for the kind of huge numerical simulation that gave rise to this thread.  In general programs where

- you continually are looking for more performance,
- you are continually updating what the program can do (adding better cloud models, say),

are pretty safe.  But programs which get deployed *and then just work* are liable to rot.  So, for instance, a retail bank's writes or buys a system to deal with mortgages: once this thing works then the chances are it will keep working for a very long time because the number of mortgages might double in ten years or something, but it won't go up by enormous factors and mortgages (at the retail bank end, not at the mortgage-backs end) are kind of boring.

Retail banks are risk-averse so they like to avoid the risks associated with porting the thing to new platforms.  And since there's no development most of the developers leave.

And then ten or twenty years later you have this arcane thing which no-one understands any more running on a platform which is falling off the end of support.

And if that was the only problem everything would be fine.  In fact, several times during the life of this thing, the bank wanted to offer some new kind of mortgage.  But no-one understood the existing mortgage platform any more, *so they deployed a new one alongside it*.  So in fact you have *four* of these platforms, all of them critical, and none of them understood by anyone.

To bring this back to Unix history, I think this is an example of a place where Unix has failed (or, perhaps, where people have failed to make use of it properly).  Half the reason these things are such a trouble is that they aren't written to any really portable API, so the bit that runs on Solaris isn't going to run on AIX or Linux, and it only might run on the current version of Solaris in fact.

I don't know what the solution to this problem: I think it is essentially teleological to assume that there *is* a solution.

--tim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180326/989dbb4e/attachment.html>

From paul.winalski at gmail.com  Tue Mar 27 02:19:44 2018
From: paul.winalski at gmail.com (Paul Winalski)
Date: Mon, 26 Mar 2018 12:19:44 -0400
Subject: [TUHS] long lived programs (was Re: RIP John Backus
In-Reply-To: <D51BFDAA-889B-4A9F-BAA4-8A961FFB7F8D@tfeb.org>
References: <284abf07f5b9d442caf233a8017a8cebb5518bbc@webmail.yaccman.com>
 <D5A7C3A8-F85C-407D-9126-B34D56DE6251@bitblocks.com>
 <CAC20D2NXwa3wKmwO4GkeKKWmrfBHqp11gDtx0i=kZAs_gTN6Dg@mail.gmail.com>
 <F7B50FE2-49A8-431E-9C5D-7B40B6C28665@bitblocks.com>
 <D51BFDAA-889B-4A9F-BAA4-8A961FFB7F8D@tfeb.org>
Message-ID: <CABH=_VSQpX+wid5_nE3OUjTCJQ2njY+hWwBQQDXamu65HUqa9A@mail.gmail.com>

On 3/26/18, Tim Bradshaw <tfb at tfeb.org> wrote:
> On 23 Mar 2018, at 19:28, Bakul Shah <bakul at bitblocks.com> wrote:
> Retail banks are risk-averse so they like to avoid the risks associated with
> porting the thing to new platforms.  And since there's no development most
> of the developers leave.
>
> And then ten or twenty years later you have this arcane thing which no-one
> understands any more running on a platform which is falling off the end of
> support.
>
After grad school (1978) one of my first job interviews was for a job
as system manager for an insurance company.  Their data center took
the "don't risk porting software" to an extreme.  As new technology
came out they bought it, but only to run new applications.  Existing
applications were never ported and continued to run on their existing
hardware.  Their machine room looked like a computer museum.  They had
two IBM 1400s (one in use; one was cannabilized for parts to keep the
active machine going), two System/360 model 50s, with a drum and a
2321 data cell drive.  Their only modern hardware was a System/370
model 158.

Operating systems seem to have taken one of two policies regarding
legacy programs.  IBM's OS and DEC's VMS emphasized backwards
compatibility--new features mustn't break existing applications.  VMS
software developers called the philosophy of strict backward
compatibility "The Promise" and took it very seriously.  Unix, on the
other hand, has always struck me as being less concerned with backward
compatibility and more about innovation and experimentation.  I think
the assumption with Unix is that you have the sources for your
programs, so you can recompile or modify them to keep up with
incompatible changes.  This is fine for research and HPTC
environments, but it doesn't fly in corporate data centers, where even
a simple recompile means that the new version of the application has
to undergo expensive qualification testing before it can be put into
production.  Which philosophy regarding backwards compatibility is
better?  It depends on your target audience.

-Paul W.


From krewat at kilonet.net  Tue Mar 27 02:41:15 2018
From: krewat at kilonet.net (Arthur Krewat)
Date: Mon, 26 Mar 2018 12:41:15 -0400
Subject: [TUHS] long lived programs (was Re: RIP John Backus
In-Reply-To: <CABH=_VSQpX+wid5_nE3OUjTCJQ2njY+hWwBQQDXamu65HUqa9A@mail.gmail.com>
References: <284abf07f5b9d442caf233a8017a8cebb5518bbc@webmail.yaccman.com>
 <D5A7C3A8-F85C-407D-9126-B34D56DE6251@bitblocks.com>
 <CAC20D2NXwa3wKmwO4GkeKKWmrfBHqp11gDtx0i=kZAs_gTN6Dg@mail.gmail.com>
 <F7B50FE2-49A8-431E-9C5D-7B40B6C28665@bitblocks.com>
 <D51BFDAA-889B-4A9F-BAA4-8A961FFB7F8D@tfeb.org>
 <CABH=_VSQpX+wid5_nE3OUjTCJQ2njY+hWwBQQDXamu65HUqa9A@mail.gmail.com>
Message-ID: <1aef71d4-0096-9666-c5ce-d9bbe44f4cd2@kilonet.net>

On 3/26/2018 12:19 PM, Paul Winalski wrote:
>   Unix, on the
> other hand, has always struck me as being less concerned with backward
> compatibility and more about innovation and experimentation.
For Sun, it was quite the contrary.

It was normal to run binaries from SunOS on Solaris. For the longest 
time, the "xv" binary I used on SPARC hardware was compiled on SunOS. 
It's even an X-windows application, and the libraries work.

Even in Solaris 10, it still runs:

-bash-3.00$ ./xv.sparc
ld.so.1: xv.sparc: warning: /usr/4lib/libX11.so.4.3: has older revision 
than expected 10
ld.so.1: xv.sparc: warning: /usr/4lib/libc.so.1.9: has older revision 
than expected 160
-bash-3.00$ file xv.sparc
xv.sparc:       Sun demand paged SPARC executable dynamically linked
-bash-3.00$ uname -a
SunOS redacted 5.10 Generic_120011-11 sun4u sparc SUNW,SPARC-Enterprise


This has been deprecated as of Solaris 11, supposedly. Backwards 
compatibility for Solaris binaries is also a "thing".

art k.



From bakul at bitblocks.com  Tue Mar 27 05:04:24 2018
From: bakul at bitblocks.com (Bakul Shah)
Date: Mon, 26 Mar 2018 12:04:24 -0700
Subject: [TUHS] long lived programs (was Re: RIP John Backus
In-Reply-To: <D51BFDAA-889B-4A9F-BAA4-8A961FFB7F8D@tfeb.org>
References: <284abf07f5b9d442caf233a8017a8cebb5518bbc@webmail.yaccman.com>
 <D5A7C3A8-F85C-407D-9126-B34D56DE6251@bitblocks.com>
 <CAC20D2NXwa3wKmwO4GkeKKWmrfBHqp11gDtx0i=kZAs_gTN6Dg@mail.gmail.com>
 <F7B50FE2-49A8-431E-9C5D-7B40B6C28665@bitblocks.com>
 <D51BFDAA-889B-4A9F-BAA4-8A961FFB7F8D@tfeb.org>
Message-ID: <4A5BA823-F928-4711-8CAA-F790F78070C1@bitblocks.com>



> On Mar 26, 2018, at 6:43 AM, Tim Bradshaw <tfb at tfeb.org> wrote:
> 
> On 23 Mar 2018, at 19:28, Bakul Shah <bakul at bitblocks.com> wrote:
>> 
>> By now most major systems has been computerized. Banks,
>> govt, finance, communication, shipping, various industries,
>> research, publishing, medicine etc. Will the critical
>> systems within each area have as many resources as & when
>> needed as weather forecasting system Tim is talking about?
> 
> I think that this is indeed a problem: it just isn't a problem for the kind of huge numerical simulation that gave rise to this thread.  In general programs where

I started thinking about Fortran programs but soon expanded to
the more general problem.
> 
> - you continually are looking for more performance,
> - you are continually updating what the program can do (adding better cloud models, say),
> 
> are pretty safe.  But programs which get deployed *and then just work* are liable to rot.  So, for

Even here attention can flag over time.

> And if that was the only problem everything would be fine.  In fact, several times during the life of this thing, the bank wanted to offer some new kind of mortgage.  But no-one understood the existing mortgage platform any more, *so they deployed a new one alongside it*.  So in fact you have *four* of these platforms, all of them critical, and none of them understood by anyone.

This is the modification problem I was talking about. Running an
unchanged binary on an emulated processor is much easier.

> 
> To bring this back to Unix history, I think this is an example of a place where Unix has failed (or, perhaps, where people have failed to make use of it properly).  Half the reason these things are such a trouble is that they aren't written to any really portable API, so the bit that runs on Solaris isn't going to run on AIX or Linux, and it only might run on the current version of Solaris in fact.

1) This is when the OS doesn't live as long as the application.
2) The rate of change in open source technologies is far too high.
   Open source is often open loop. Hundreds of bugs remain unfixed
   while a new feature will be added.

> I don't know what the solution to this problem: I think it is essentially teleological to assume that there *is* a solution.

It is an interesting problem even if there is no clear solution.
But now I think may be it doesn't matter in the long run.  We
will let our new AI lords worry about it :-)

From lm at mcvoy.com  Tue Mar 27 05:53:03 2018
From: lm at mcvoy.com (Larry McVoy)
Date: Mon, 26 Mar 2018 12:53:03 -0700
Subject: [TUHS] long lived programs (was Re: RIP John Backus
In-Reply-To: <1aef71d4-0096-9666-c5ce-d9bbe44f4cd2@kilonet.net>
References: <284abf07f5b9d442caf233a8017a8cebb5518bbc@webmail.yaccman.com>
 <D5A7C3A8-F85C-407D-9126-B34D56DE6251@bitblocks.com>
 <CAC20D2NXwa3wKmwO4GkeKKWmrfBHqp11gDtx0i=kZAs_gTN6Dg@mail.gmail.com>
 <F7B50FE2-49A8-431E-9C5D-7B40B6C28665@bitblocks.com>
 <D51BFDAA-889B-4A9F-BAA4-8A961FFB7F8D@tfeb.org>
 <CABH=_VSQpX+wid5_nE3OUjTCJQ2njY+hWwBQQDXamu65HUqa9A@mail.gmail.com>
 <1aef71d4-0096-9666-c5ce-d9bbe44f4cd2@kilonet.net>
Message-ID: <20180326195303.GM6072@mcvoy.com>

On Mon, Mar 26, 2018 at 12:41:15PM -0400, Arthur Krewat wrote:
> On 3/26/2018 12:19 PM, Paul Winalski wrote:
> >  Unix, on the
> >other hand, has always struck me as being less concerned with backward
> >compatibility and more about innovation and experimentation.
> For Sun, it was quite the contrary.
> 
> It was normal to run binaries from SunOS on Solaris. For the longest time,
> the "xv" binary I used on SPARC hardware was compiled on SunOS. It's even an
> X-windows application, and the libraries work.

Yeah, Sun was very good about that.  You got smacked if you broke compat.


From clemc at ccc.com  Mon Mar 26 10:53:03 2018
From: clemc at ccc.com (Clem Cole)
Date: Sun, 25 Mar 2018 20:53:03 -0400
Subject: [TUHS] Fwd:  long lived programs (was Re: RIP John Backus
In-Reply-To: <CAC20D2P1CZwaD0uJpMhWg11muDeH9rEn3X+AUjXvwMKsNjs7ng@mail.gmail.com>
References: <284abf07f5b9d442caf233a8017a8cebb5518bbc@webmail.yaccman.com>
 <D5A7C3A8-F85C-407D-9126-B34D56DE6251@bitblocks.com>
 <92ACA4B4-31AC-4202-95DD-14E30C5D164C@tfeb.org>
 <CAC20D2P1CZwaD0uJpMhWg11muDeH9rEn3X+AUjXvwMKsNjs7ng@mail.gmail.com>
Message-ID: <CAC20D2P5JBDRirjnG+g-AadR7kHrpT16wqtwVx22OnAZzvFUnA@mail.gmail.com>

[try-II]




On Fri, Mar 23, 2018 at 6:43 AM, Tim Bradshaw <tfb at tfeb.org> wrote:

> On 22 Mar 2018, at 21:05, Bakul Shah <bakul at bitblocks.com> wrote:
>
>
> I was thinking about a similar issue after reading Bradshaw's
> message about FORTRAN programs being critical to his country's
> security. What happens in 50-100 years when such programs have
> been in use for a long time but none of the original authors
> may be alive? The world may have moved on to newer languages
> and there may be very few people who study "ancient" computer
> languages and even they won't have in-depth experience to
> understand the nuances & traps of these languages well enough.
> No guarantee that FORTRAN will be in much use then! Will it be
> like in science fiction where ancient spaceships continue
> working but no one knows what to do when they break?
>
>
> My experience of large systems like this is that this isn't how they work
> at all.  The program I deal with (which is around 5 million lines naively
> (counting a lot of stuff which probably is not source but is in the source
> tree)) is looked after by probably several hundred people.  It's been
> through several major changes in its essential guts and in the next ten
> years or so it will be entirely replaced by a new version of itself to deal
> with scaling problems inherent in the current implementation.  We get a new
> machine every few years onto which it needs to be ported, and those
> machines have not all been just faster versions of the previous one, and
> will probably never be so.
>
> What it doesn't do is to just sit there as some sacred artifact which
> no-one understands, and it's unlikely ever to do so.  The requirements for
> it to become like that would be at least that the technology of large-scale
> computers was entirely stable, compilers, libraries and operating systems
> had become entirely stable and people had stopped caring about making it do
> what it does better.  None of those things seems very likely to me.
>
> (Just to be clear: this thing isn't simulating bombs: it's forecasting the
> weather.)
>

​+1 - exactly
​my ​
point.​

We have drifted a bit from pure UNIX, but I actually do think this is
relevant to UNIX history.   Once UNIX started to run on systems targeting
HPC loads where Fortran was the dominate programming language, UNIX quickly
displaced custom OSs and became the dominant target even if at the
beginning of that transition
​as ​
the 'flavor' of UNIX did vary (we probably can and should discuss how that
happened and why independently
​-- although
 I will point out the UNIX/Linux implementation running at say LLNL != the
version running at say Nasa Moffitt).    And the truth is today, for small
experiments you probably run Fortran on Windows on your desktop.   But for
'production'  - the primary OS for Fortran is a UNIX flavor of some type
and has been that way since the mid-1980s - really starting with the UNIX
wars of that time.

As I also have said here and elsewhere, while HPC and very much its
lubricant, Fortran, are not something 'academic CS types' like to study
these days
​ - even though​
 Fortran (HPC) pays my
​ and many of our​
salar
​ies​
.    Yet it runs on the system the those same academic types all prefer -
*i.e.* Ken and Dennis' ideas.    The primary difference is the type of
program the users are running.   But Ken and Dennis ideas work well for
almost all users and spans
​specific ​
application market
​s.​

Here is a
​picture
 I did a few years ago for a number of Intel exec's.  At the time I was
trying to explain to them that HPC is not a single style of application and
also help them understand that there two types of value - the code itself
and the data.  Some markets (
​*e.g.* ​
Financial) use public data but the methods they use
​to crunch it ​
(
​*i.e.* ​the
code
​s​
)
​are
 private, while others
​market segments ​
might have private data (*e.g.*
​ ​
oil and gas) but
​different customers ​
use the same or similar codes to crunch it.
​F
or this discussion, think about how much of the code I sho
​w​
below is complex arithmetics -
​while ​
much of it is searching
​ google style​
, but a lot is
​just plain ​
nasty math.   The 'nasty math' that has not changed
​over the years ​
and thus those codes are dominated by Fortran.
​ [Note Steve has pointed out that with AI maybe the math could change in
the future - but certainly so far, history of these markets is basically
differential equations solvers].​


 As Tim says, I really can not
​see ​
that changing and
​the ​
reason (I believe) is I do not see any
​compelling ​
economic reason to do so.
Clem​



ᐧ

ᐧ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180325/c411356f/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: HPC_CloudBubble_nomarks20180323.png
Type: image/png
Size: 444678 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180325/c411356f/attachment.png>

From clemc at ccc.com  Tue Mar 27 11:08:11 2018
From: clemc at ccc.com (Clem Cole)
Date: Mon, 26 Mar 2018 21:08:11 -0400
Subject: [TUHS] long lived programs (was Re: RIP John Backus
In-Reply-To: <CABH=_VSQpX+wid5_nE3OUjTCJQ2njY+hWwBQQDXamu65HUqa9A@mail.gmail.com>
References: <284abf07f5b9d442caf233a8017a8cebb5518bbc@webmail.yaccman.com>
 <D5A7C3A8-F85C-407D-9126-B34D56DE6251@bitblocks.com>
 <CAC20D2NXwa3wKmwO4GkeKKWmrfBHqp11gDtx0i=kZAs_gTN6Dg@mail.gmail.com>
 <F7B50FE2-49A8-431E-9C5D-7B40B6C28665@bitblocks.com>
 <D51BFDAA-889B-4A9F-BAA4-8A961FFB7F8D@tfeb.org>
 <CABH=_VSQpX+wid5_nE3OUjTCJQ2njY+hWwBQQDXamu65HUqa9A@mail.gmail.com>
Message-ID: <CAC20D2P0RL_eAQYxp0p4zXt6v7r84MycBPpWtn1ax6S_UxfPzQ@mail.gmail.com>

On Mon, Mar 26, 2018 at 12:19 PM, Paul Winalski <paul.winalski at gmail.com>
wrote:

> ​... ​
> VMS
> ​ ​
> software developers called the philosophy of strict backward
> compatibility "The Promise" and took it very seriously.  Unix, on the
> other hand, has always struck me as being less concerned with backward
> compatibility and more about innovation and experimentation.  I think
> the assumption with Unix is that you have the sources for your
> programs, so you can recompile or modify them to keep up with
> incompatible changes.


​Paul be careful here.   Yes, BSD did that.  I'll never forget hearing Joy
once saying he thought it was a good idea to make people recompile because
their code stayed fresh.

But as UNIX move from Universities to commercial firms, ​binaries became
really important.
DEC, Masscomp (being ex-DECies) and eventually Sun took that same promise
with them.

Linux has been mixed.  The problem is that UNIX is more than just the
kernel itself.  As the SPEC1170 work revealed in the late 1980s/early
1990's - there were 1170 different interfaces that ISVs had to think about
and agreeing between vendors much less releases within vendors was
difficult.

And here is an interesting observation ...

The ideas behind UNIX was (more or less) HW independant.   Just think, how
hard it was for DEC, Masscomp or SUN to keep VMS or Ultrix/Tru64, RTU,
SunOS/Solaris binary compatible.   It's part of why the whole UNIX
standards of API *vs.* ABI wars raged.   It was and is a control problem.

Linux (sort of) solves it by keeping the Kernel as their definition.   But
that really only partly works.   kernel.org streams out new kernels way
faster than the distros.  And the distros can not agree on the different
placements for things.   Then you get into things like Messaging stacks.
 It why Intel had to develop 'Cluster Ready.'   I will not say to protect
the guilty, but one very well known HPC ISV had a test matrix of 144
different linux combinations before they could ship....

Just to give you an idea .. if they developed say on IBM/Lenovo under RHEL
version mumble, but tried to release a binary on the same RHEL but on say
HP gear, it would not work, because IBM had used Qlogic IB and HP Mellanox
say.   Or worse they both had used the same vendor of the gear but
different releases of the IB stack (it gets worse and worse).

The issue is that each vendor wants (needs) to have some level of control.


Clem
ᐧ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180326/20c7d5d0/attachment.html>

From scj at yaccman.com  Tue Mar 27 11:21:49 2018
From: scj at yaccman.com (Steve Johnson)
Date: Mon, 26 Mar 2018 18:21:49 -0700
Subject: [TUHS] long lived programs (was Re: RIP John Backus
In-Reply-To: <D51BFDAA-889B-4A9F-BAA4-8A961FFB7F8D@tfeb.org>
Message-ID: <cc3c05aa2a06dcc9c0a61c18649d9f03a4880097@webmail.yaccman.com>

Portability and standard API are very good for users, but
manufacturers hate them.  Unix portability was supported by AT&T in
part because they were getting flak from non-DEC manufacturers about
Unix running only on the PDP-11.   Once Unix was ported,
applications could run on hardware that was cheapest and most
appropriate to the application rather than where it was first
written.  Users, much more than computer companies, benefited from
portability.  And DARPA, with a similarly broad view, for the most
part did things that helped users rather than specific manufacturers.

In fact, the first thing most manufacturers did with Unix was to
change it.  The rot set in quickly, leading to long boring chaotic
standards efforts over POSIX and C (remember OSF?).

On the other hand, manufacturers love open source.   There are no
apparent limits on growth, and few guiding hands to prevent silly, or
downright dangerous features from creeping into the endlessly bloating
code bases.  Each company can get their own version at low cost and
keep their customers happy, serene in the knowledge that if the
customers try to use another system they will have to deal with the
100+ pages of incompatible GCC options and have to tame piles of
poorly concieved and documented code.  None of the stakeholders in
open source have anything to gain by being compatible, or even letting
people know when they change something incompatibly without warning. 
After all, it can only hurt the other stakeholders, not them...

Yes, I'm old and cynical, and yes there are some islands of sanity
fighting the general trend.   And yes, I think this is a cyclical
problem that will swing back towards sanity, hopefully soon.  But
where is the AT&T or DARPA with enough smarts and resources to do
things simply, and motivation to make users happy rather than
increasing profits?

Steve

----- Original Message -----
From: "Tim Bradshaw" <tfb at tfeb.org>. . .

To bring this back to Unix history, I think this is an example of a
place where Unix has failed (or, perhaps, where people have failed to
make use of it properly).  Half the reason these things are such a
trouble is that they aren't written to any really portable API, so the
bit that runs on Solaris isn't going to run on AIX or Linux, and it
only might run on the current version of Solaris in fact.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180326/596b740f/attachment.html>

From clemc at ccc.com  Tue Mar 27 11:46:00 2018
From: clemc at ccc.com (Clem Cole)
Date: Mon, 26 Mar 2018 21:46:00 -0400
Subject: [TUHS] long lived programs (was Re: RIP John Backus
In-Reply-To: <cc3c05aa2a06dcc9c0a61c18649d9f03a4880097@webmail.yaccman.com>
References: <D51BFDAA-889B-4A9F-BAA4-8A961FFB7F8D@tfeb.org>
 <cc3c05aa2a06dcc9c0a61c18649d9f03a4880097@webmail.yaccman.com>
Message-ID: <CAC20D2NSpnB5+RDECTpi1o_SN2T7WNZyh=JV7L+DZJS-Ee=Fng@mail.gmail.com>

On Mon, Mar 26, 2018 at 9:21 PM, Steve Johnson <scj at yaccman.com> wrote:

> On the other hand, manufacturers love open source.
>
​HW manufacturers love FOSS because it got them out of yet another thing
that cost them money.   We saw the investment in compilers going away, now
we see the same in the OS.   But many ISV's are still not so sure.​

Funny compilers are a strange thing ... it's not in Gnu, much less
Microsoft's interest to get that last few percent out of any chip, as much
as it is for the chip developer.   Firms like Intel have their own compiler
team, ARM and AMD pay third parties.   But because if the competition, the
FOSS or even proprietary compilers get better [Certainly for languages like
Fortran were performance is everything - which is why 'production' shops
will pay for a high end compiler - be it from PCG, Intel or Cray say].

Truth is FOSS has changed the model.  But there are only some people who
will pay for support (particularly large HPC sites we all can name).   They
will pay some things, but those sites want to change everything (yet
another rant I'll leave for another day ;-)



​
ᐧ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180326/61ecbf1a/attachment.html>

From mj at mjturner.net  Tue Mar 27 19:20:58 2018
From: mj at mjturner.net (Michael-John Turner)
Date: Tue, 27 Mar 2018 10:20:58 +0100
Subject: [TUHS] mail tuhs@minnie.tuhs.org
In-Reply-To: <20180324015436.GQ18044@mcvoy.com>
References: <201803240126.w2O1QTB5109348@tahoe.cs.Dartmouth.EDU>
 <20180324015436.GQ18044@mcvoy.com>
Message-ID: <20180327092057.zukptcqehbaoyshr@saucer.turnde.net>

On Sat, Mar 24, 2018 at 01:54:36AM +0000, Larry McVoy wrote:
>Didn't Roger Faulkner have something to do with that?  Or did he come
>after?

I mistakenly thought /proc was Roger Faulkner's creation. A little bit of 
digging turned up this reasonable summary: 
https://blogs.oracle.com/eschrock/a-brief-history-of-proc

The best part is that it contains the references to the original papers
(links added by me):
T. J. Killian. Processes as Files. Proceedings of the USENIX Software Tools 
Users Group Summer Conference, pp 203-207, June 1984 [1]

R. Faulkner and R. Gomes. The Process File System and Process Model in UNIX 
System V. USENIX Conference Proceedings. Dallas, Texas. January 1991 [2]

[1] http://lucasvr.gobolinux.org/etc/Killian84-Procfs-USENIX.pdf
[2] https://www.usenix.org/sites/default/files/usenix_winter91_faulkner.pdf

Cheers, MJ
-- 
Michael-John Turner * mj at mjturner.net * http://mjturner.net/ 



From dave at horsfall.org  Fri Mar 30 06:51:15 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Fri, 30 Mar 2018 07:51:15 +1100 (EST)
Subject: [TUHS] Novell, not SCO, found to own "Unix"
Message-ID: <alpine.BSF.2.21.1803300721250.3361@aneurin.horsfall.org>

Time for another hand-grenade in the duck pond :-)  Or as we call it 
down-under, "stirring the possum".

On this day in 2010, it was found unanimously that Novell, not SCO, owned 
"Unix".  SCO appealed later, and it was dismissed "with prejudice"; SCO 
shares plummeted as a result.

As an aside, this was the first and only time that I was on IBM's side, 
and I still wonder whether M$ was bankrolling SCO in an effort to wipe 
Linux off the map; what sort of an idiot would take on IBM?

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."


From paul.winalski at gmail.com  Fri Mar 30 07:19:46 2018
From: paul.winalski at gmail.com (Paul Winalski)
Date: Thu, 29 Mar 2018 17:19:46 -0400
Subject: [TUHS] Novell, not SCO, found to own "Unix"
In-Reply-To: <alpine.BSF.2.21.1803300721250.3361@aneurin.horsfall.org>
References: <alpine.BSF.2.21.1803300721250.3361@aneurin.horsfall.org>
Message-ID: <CABH=_VR2QLgnPPLCgC-w1ePR8=sufEEG1SarkCrYOdA_sY02Tw@mail.gmail.com>

On 3/29/18, Dave Horsfall <dave at horsfall.org> wrote:
>
> On this day in 2010, it was found unanimously that Novell, not SCO, owned
> "Unix".  SCO appealed later, and it was dismissed "with prejudice"; SCO
> shares plummeted as a result.

A pox on both their houses, IMO.  And apparently the SCO vs. IBM
lawsuit is still alive.  The situation is almost farcical.

> what sort of an idiot would take on IBM?

Back in the 1960s IBM was facing two antitrust lawsuits over alleged
attempts to use its dominant market position to freeze the HPTC market
while they attempted to complete and ship the long-delayed System/360
model 90.  One lawsuit was brought by the Justice Department and
famously dragged on in court for a decade.  CDC also filed a civil
lawsuit.  CDC's lawyers built a computerized database of all the IBM
internal documents that they found during the discovery phase of suit.
IBM and CDC settled out of court.  IBM gave its Service Bureau
Corporation subsidiary to CDC and agreed to stay out of the service
bureau business for 10 years.  CDC agreed to destroy the database of
IBM internal documents.  The Justice Department tried but failed to
get access to the CDC database for their own lawsuit.

-Paul W.


From paul.winalski at gmail.com  Fri Mar 30 07:37:28 2018
From: paul.winalski at gmail.com (Paul Winalski)
Date: Thu, 29 Mar 2018 17:37:28 -0400
Subject: [TUHS] shared objects in Unix
Message-ID: <CABH=_VQvhHKemfOOvVFSu9K+Go1LB5e2Ck214KdLJvtE--z8Hg@mail.gmail.com>

The recent discussion of long-lived applications, and backwards
compatibility in Unix, got me thinking about the history of shared
objects.  My own experience with Linux and MacOS is that
statically-linked applications tend to continue working from release
to release, but shared objects provided by the OS tend not to be
backwards compatible, and one often has to carry around with your
application the exact C runtime and other shared objects your program
was linked against.  This is in big contrast to shared libraries on
VMS, where great care is taken to maintain strict backward
compatibility release to release.

What is the history of shared objects on Unix?  When did they first
appear, and with what object/executable file format?  The a.out ZMAGIC
format doesn't seem to support them.  I don't recall if COFF does.
MACH-O, at least the MacOS dialect of it, supports dynamic libraries.
ELF supports them.

Also, when was symbol preemption invented?  Traditional shared library
designs such as in IBM System/370, VMS, and Windows NT doesn't have
it.  As one who worked on optimizations in compilers, I came to hate
symbol preemption because it prohibits many useful optimizations.  ELF
does provide a way to turn it off, but it's on by default--you have to
explicitly declare symbols as protected or hidden via source language
pragmas to get rid of it.

-Paul W.


From henry.r.bent at gmail.com  Fri Mar 30 08:01:42 2018
From: henry.r.bent at gmail.com (Henry Bent)
Date: Thu, 29 Mar 2018 18:01:42 -0400
Subject: [TUHS] shared objects in Unix
In-Reply-To: <CABH=_VQvhHKemfOOvVFSu9K+Go1LB5e2Ck214KdLJvtE--z8Hg@mail.gmail.com>
References: <CABH=_VQvhHKemfOOvVFSu9K+Go1LB5e2Ck214KdLJvtE--z8Hg@mail.gmail.com>
Message-ID: <CAEdTPBdWS6W0om+4HeSHmNSZb-NQEhZyzmFWyS3EmN=EhmXzOw@mail.gmail.com>

On 29 March 2018 at 17:37, Paul Winalski <paul.winalski at gmail.com> wrote:

>
> What is the history of shared objects on Unix?  When did they first
> appear, and with what object/executable file format?  The a.out ZMAGIC
> format doesn't seem to support them.  I don't recall if COFF does.
>

IRIX 4 had COFF shared libraries, barely.  The OS included libc_s, libgl_s,
and maybe one or two other things.  They were very difficult and
time-consuming to create, and if you had external dependencies then things
were even worse.

-Henry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180329/4eeeddb3/attachment.html>

From imp at bsdimp.com  Fri Mar 30 08:26:40 2018
From: imp at bsdimp.com (Warner Losh)
Date: Thu, 29 Mar 2018 16:26:40 -0600
Subject: [TUHS] shared objects in Unix
In-Reply-To: <CABH=_VQvhHKemfOOvVFSu9K+Go1LB5e2Ck214KdLJvtE--z8Hg@mail.gmail.com>
References: <CABH=_VQvhHKemfOOvVFSu9K+Go1LB5e2Ck214KdLJvtE--z8Hg@mail.gmail.com>
Message-ID: <CANCZdfq0XmMpKykVjfU3sDKWMcyqj_B56xfz8V5nbjdorZCQXw@mail.gmail.com>

On Thu, Mar 29, 2018 at 3:37 PM, Paul Winalski <paul.winalski at gmail.com>
wrote:
>
> What is the history of shared objects on Unix?  When did they first
> appear, and with what object/executable file format?  The a.out ZMAGIC
> format doesn't seem to support them.  I don't recall if COFF does.
> MACH-O, at least the MacOS dialect of it, supports dynamic libraries.
> ELF supports them.
>

Both FreeBSD and Linux supported shared libraries for a.out, though I can't
recall which of the *MAGIC formats they were. The Linux ones had fixed load
addresses, while the FreeBSD ones allowed any load address. Each of these
approaches has pros and cons, but both were tossed away in favor of ELF
just as soon as ELF was stable. Though, FreeBSD still has an a.out run time
linker in the tree. I wouldn't think it was still in use, but the
maintainer still fixes a bug in it every 9-24 months that some user has
reported...

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180329/53060dae/attachment.html>

From dave at horsfall.org  Fri Mar 30 09:11:42 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Fri, 30 Mar 2018 10:11:42 +1100 (EST)
Subject: [TUHS] shared objects in Unix
In-Reply-To: <CABH=_VQvhHKemfOOvVFSu9K+Go1LB5e2Ck214KdLJvtE--z8Hg@mail.gmail.com>
References: <CABH=_VQvhHKemfOOvVFSu9K+Go1LB5e2Ck214KdLJvtE--z8Hg@mail.gmail.com>
Message-ID: <alpine.BSF.2.21.1803301009140.3361@aneurin.horsfall.org>

On Thu, 29 Mar 2018, Paul Winalski wrote:

[...]

> What is the history of shared objects on Unix?  When did they first 
> appear, and with what object/executable file format?  The a.out ZMAGIC 
> format doesn't seem to support them.  I don't recall if COFF does. 
> MACH-O, at least the MacOS dialect of it, supports dynamic libraries. 
> ELF supports them.

I first saw 'em when they appeared in SunOS (can't remember which release) 
and thought they were wonderful, along with loadable drivers.

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."


From imp at bsdimp.com  Fri Mar 30 09:22:41 2018
From: imp at bsdimp.com (Warner Losh)
Date: Thu, 29 Mar 2018 17:22:41 -0600
Subject: [TUHS] shared objects in Unix
In-Reply-To: <alpine.BSF.2.21.1803301009140.3361@aneurin.horsfall.org>
References: <CABH=_VQvhHKemfOOvVFSu9K+Go1LB5e2Ck214KdLJvtE--z8Hg@mail.gmail.com>
 <alpine.BSF.2.21.1803301009140.3361@aneurin.horsfall.org>
Message-ID: <CANCZdfryz5AwaC8xhKZNMTN5eFL8O+SqyJPYTB34RohW_XAAPA@mail.gmail.com>

On Mar 29, 2018 5:12 PM, "Dave Horsfall" <dave at horsfall.org> wrote:

On Thu, 29 Mar 2018, Paul Winalski wrote:

[...]


What is the history of shared objects on Unix?  When did they first appear,
> and with what object/executable file format?  The a.out ZMAGIC format
> doesn't seem to support them.  I don't recall if COFF does. MACH-O, at
> least the MacOS dialect of it, supports dynamic libraries. ELF supports
> them.
>

I first saw 'em when they appeared in SunOS (can't remember which release)
and thought they were wonderful, along with loadable drivers.


Shared libraries were 4.0 due to the new mmap call. These were a.out based
I'm pretty sure.

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180329/f13c9df8/attachment.html>

From lm at mcvoy.com  Fri Mar 30 09:24:09 2018
From: lm at mcvoy.com (Larry McVoy)
Date: Thu, 29 Mar 2018 16:24:09 -0700
Subject: [TUHS] shared objects in Unix
In-Reply-To: <alpine.BSF.2.21.1803301009140.3361@aneurin.horsfall.org>
References: <CABH=_VQvhHKemfOOvVFSu9K+Go1LB5e2Ck214KdLJvtE--z8Hg@mail.gmail.com>
 <alpine.BSF.2.21.1803301009140.3361@aneurin.horsfall.org>
Message-ID: <20180329232409.GH8921@mcvoy.com>

On Fri, Mar 30, 2018 at 10:11:42AM +1100, Dave Horsfall wrote:
> On Thu, 29 Mar 2018, Paul Winalski wrote:
> 
> [...]
> 
> >What is the history of shared objects on Unix?  When did they first
> >appear, and with what object/executable file format?  The a.out ZMAGIC
> >format doesn't seem to support them.  I don't recall if COFF does. MACH-O,
> >at least the MacOS dialect of it, supports dynamic libraries. ELF supports
> >them.
> 
> I first saw 'em when they appeared in SunOS (can't remember which release)
> and thought they were wonderful, along with loadable drivers.

Warner and I have been going back and forth about this.  We're both pretty
sure that shared libs were part of the 4.0 release (that was the release
that had the VM system rewrite by Joe Moran (mojo at sun.com) with mmap() as
invisioned by Bill Joy while still at Berkeley.  

I've got a number of papers about it:

http://mcvoy.com/lm/papers/SunOS.shlib.pdf - that's the shared lib paper
http://mcvoy.com/lm/papers/SunOS.vm_arch.pdf - that's the VM architectue paper
http://mcvoy.com/lm/papers/SunOS.vm_impl.pdf - that's the VM implementation paper

There's other stuff there too if you are bored.  SunOS.smoosh.pdf is the basic
idea that is the under pinnings of every distributed source management system,
SunOS.tfs.pdf is Dave Hendrick's copy on write file system writeup, 
SunOS.ufs_clustering.pdf is the work I did in UFS to get platter speed perf
out of UFS, etc.  Most of that stuff is Sun stuff though there is some other
random bits.  If you are curious about any of it I can go into detain off
(or on) list.

--lm


From clemc at ccc.com  Fri Mar 30 10:22:14 2018
From: clemc at ccc.com (Clem Cole)
Date: Thu, 29 Mar 2018 20:22:14 -0400
Subject: [TUHS] shared objects in Unix
In-Reply-To: <20180329232409.GH8921@mcvoy.com>
References: <CABH=_VQvhHKemfOOvVFSu9K+Go1LB5e2Ck214KdLJvtE--z8Hg@mail.gmail.com>
 <alpine.BSF.2.21.1803301009140.3361@aneurin.horsfall.org>
 <20180329232409.GH8921@mcvoy.com>
Message-ID: <CAC20D2ORfP-bCTZiM0rxYywGmF7QpsORTtCGx86++tzeyjRwbw@mail.gmail.com>

Paul,

The point is that there were a number of different shared library
implementations for UNIX over the years.  That was one of the 'knocks' when
comparing VMS to 4.1BSD in the early 80s.   VMS had shared libraries from
the start.   I'm pretty sure the first unix to support shared libraries was
CMU's Mach using its modified about called macho, which lives today in Mac
OSX.     BSD4.2 had started to implement it, but it was incomplete so folks
like Sun and Masscomp each did their own scheme, both based on modified
a.out. A big problem was every vendor messed with a.out in a different way
-- so Sun's, Masscomp and Apollo's versions were all a little different and
you a linker guy, you know that a.out was not a great format for same.

With System V.3, AT&T introduced was an a new file format, called the
Common Object File Format - *a.k.a.* COFF. SVR3 supported shared libs.  In
fairness, COFF was a huge improvement over a.out, but it was done when AT&T
was in its 'consider it standard' time and trying to force its will and
wanted licensing fees.   Let's say that failed for non-technical reasons.
Unfortunately, it lead to more confusion and we ended up a number of
different COFF-almost, sort-of, extensions.  IIRC, IBM went with a modified
COFF, but again we were in a cold war of who could do what.  I remember
that the time, the Gnu guys wrote tool called 'robitussin' - which 'cured
COFFs.'

With, AT&T's SVR4 release the world was introduced to the 'Extended Linker
Format' - ELF, which fixed a number of issues with COFF, the primary one
being that it could loaded images faster and you could page from directly,
which neither a.out nor COFF could easily.  Again IIRC, SVR4's linker could
handled AT&T's COFF files.

I have never known the legals on it, but some how the details of ELF did
become public and somebody reimplemented the GNU compilers to use it and
AT&T for whatever reason did not complain (maybe the had their hands full
at time with BSDi case).   Anyway, eventually both Linux and FreeBSD
switched to that version of Gnu and its pretty much been stable since.
ᐧ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180329/455b07c7/attachment.html>

From clemc at ccc.com  Fri Mar 30 10:40:36 2018
From: clemc at ccc.com (Clem Cole)
Date: Thu, 29 Mar 2018 20:40:36 -0400
Subject: [TUHS] shared objects in Unix
In-Reply-To: <CABH=_VQvhHKemfOOvVFSu9K+Go1LB5e2Ck214KdLJvtE--z8Hg@mail.gmail.com>
References: <CABH=_VQvhHKemfOOvVFSu9K+Go1LB5e2Ck214KdLJvtE--z8Hg@mail.gmail.com>
Message-ID: <CAC20D2O8iAMhmywzywVkAZqzcHELH5fDLsc+HtwArh2Ft=yoPA@mail.gmail.com>

On Thu, Mar 29, 2018 at 5:37 PM, Paul Winalski <paul.winalski at gmail.com>
wrote:

> Also, when was symbol preemption invented?  Traditional shared library
> designs such as in IBM System/370, VMS, and Windows NT doesn't have
> it.  As one who worked on optimizations in compilers, I came to hate
> symbol preemption because it prohibits many useful optimizations.  ELF
> does provide a way to turn it off, but it's on by default--you have to
> explicitly declare symbols as protected or hidden via source language
> pragmas to get rid of it.


​Unless it came from a place like Sun or Sun where Larry or Charlie might
remember, I suspect that Steve Johnson is probably best to answer this part
of your question -- assuming that it was created during his time in the
compiler team in Summit.

But, I don't remember when it came on to the scene frankly because it did
not effect me.   I think it might have been in the original COFF which came
from those days, but its possible its from one of the many bastardization
of COFF that occurred after its birth.    I don't remember it being in any
of the a.out flavors and I don't think macho has it.

As an OS guy, all I remember about it frankly is you and some the compiler
folks b*tching about it as a misfeature of UNIX at lunch ;-)

​
ᐧ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180329/caefc951/attachment.html>

From clemc at ccc.com  Fri Mar 30 11:01:07 2018
From: clemc at ccc.com (Clem Cole)
Date: Thu, 29 Mar 2018 21:01:07 -0400
Subject: [TUHS] Novell, not SCO, found to own "Unix"
In-Reply-To: <CABH=_VR2QLgnPPLCgC-w1ePR8=sufEEG1SarkCrYOdA_sY02Tw@mail.gmail.com>
References: <alpine.BSF.2.21.1803300721250.3361@aneurin.horsfall.org>
 <CABH=_VR2QLgnPPLCgC-w1ePR8=sufEEG1SarkCrYOdA_sY02Tw@mail.gmail.com>
Message-ID: <CAC20D2OmnNQY3hMQ+SZEmjj2X2wnT6Bk-hsNJ6maK8ZncKWGxQ@mail.gmail.com>

On Thu, Mar 29, 2018 at 5:19 PM, Paul Winalski <paul.winalski at gmail.com>
wrote:

> Back in the 1960s IBM was facing two antitrust lawsuits over alleged
> attempts to use its dominant market position to freeze the HPTC market
> while they attempted to complete and ship the long-delayed System/360
> model 90.  One lawsuit was brought by the Justice Department and
> famously dragged on in court for a decade.


​My favorite part of that story is that, IBM instead of sending exactly
what was required by the courts, *i.e*. the minimum possible, the IBM legal
team filled the basement of the justice department in Washing DC with many,
many tractor trailer loads of filling cabinets, mag tapes *etc*. 'Hey, here
you go, you asked for it...'

So IBM is being sued for anti-trust/monopoly position - what does IBM do
next?  They send a sales team to Justice and ask if the folks in Justice
wanted to buy computer equipment to examine what they now had in their
possession.

Furthermore, contemporary to the IBM suit, AT&T was also being sued by the
same Justice dept for belief that it was had failed to follow the 1956
consent decree and was using its legal monopoly position with prohibited
actions.   AT&T took a rather​ different approach of giving justice a
exactly the information that was required and no more.

Well, we all know what happened January 8, 1982 - the IBM suit was dropped
and AT&T was broken up.
ᐧ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180329/3acf7cc8/attachment.html>

From lyndon at orthanc.ca  Fri Mar 30 11:20:00 2018
From: lyndon at orthanc.ca (Lyndon Nerenberg)
Date: Thu, 29 Mar 2018 18:20:00 -0700 (PDT)
Subject: [TUHS] shared objects in Unix
In-Reply-To: <alpine.BSF.2.21.1803301009140.3361@aneurin.horsfall.org>
References: <CABH=_VQvhHKemfOOvVFSu9K+Go1LB5e2Ck214KdLJvtE--z8Hg@mail.gmail.com>
 <alpine.BSF.2.21.1803301009140.3361@aneurin.horsfall.org>
Message-ID: <alpine.BSF.2.21.1.1803291819250.85641@orthanc.ca>

> I first saw 'em when they appeared in SunOS (can't remember which release) 
> and thought they were wonderful, along with loadable drivers.

SunOS 4 IIRC.


From lm at mcvoy.com  Fri Mar 30 11:46:42 2018
From: lm at mcvoy.com (Larry McVoy)
Date: Thu, 29 Mar 2018 18:46:42 -0700
Subject: [TUHS] shared objects in Unix
In-Reply-To: <CAC20D2ORfP-bCTZiM0rxYywGmF7QpsORTtCGx86++tzeyjRwbw@mail.gmail.com>
References: <CABH=_VQvhHKemfOOvVFSu9K+Go1LB5e2Ck214KdLJvtE--z8Hg@mail.gmail.com>
 <alpine.BSF.2.21.1803301009140.3361@aneurin.horsfall.org>
 <20180329232409.GH8921@mcvoy.com>
 <CAC20D2ORfP-bCTZiM0rxYywGmF7QpsORTtCGx86++tzeyjRwbw@mail.gmail.com>
Message-ID: <20180330014642.GI8921@mcvoy.com>

On Thu, Mar 29, 2018 at 08:22:14PM -0400, Clem Cole wrote:
> I'm pretty sure the first unix to support shared libraries was
> CMU's Mach using its modified about called macho, which lives today in Mac
> OSX.     

Uh, you sure about that?

http://cs.cmu.edu/afs/cs.cmu.edu/project/mach/public/doc/published/mapfiles87.ps

is as close as I can find, and that's talking about stuff that was long after
Sun's shared libraries.

There may have been earlier stuff but the approach laid out in

http://www.mcvoy.com/lm/papers/SunOS.shlib.pdf

is pretty much the shared library world as we know it today so far as I
know.

I remember the world before that, I lived in it, and shared libraries were
not a working thing in my memory.  Maybe on VMS, I didn't program much on
VMS, but on any Unix I could get my hands on, Sun was the first to have
working shared libraries.

CMU's Mach, mem, I am by no means a fan (I bought into the hype, read
all the papers, when I finally got to see the code, wow.  NOTHING like Sun's
VM system, I mean, nothing.  It claimed to be the same sort of thing, it was
an ugly mess and it still is.  Sun's VM system was a thing of beauty, you
could read the code and figure out the architecture from the code.  I'd 
challenge anyone to do that from the Mach code).  

But maybe it had shared libs before SunOS but who was using that code?
So far as I know the first time the Mach code was in a commercial product
was Next.  Their first release was October 1988, SunOS 4.0 was Dec 1988
and was a far far far more mature release.

Here's a way to put it into perspective.  In the mid 80's, and maybe 
before, every single open source project's makefile just worked on
a Sun.  I don't ever remember seeing a Makefile that just worked on 
a Next (and I don't know of any other Mach based platform until Apple
many years later).


From sauer at technologists.com  Fri Mar 30 11:35:50 2018
From: sauer at technologists.com (Charles H. Sauer)
Date: Thu, 29 Mar 2018 20:35:50 -0500
Subject: [TUHS] shared objects in Unix
In-Reply-To: <CAC20D2O8iAMhmywzywVkAZqzcHELH5fDLsc+HtwArh2Ft=yoPA@mail.gmail.com>
References: <CABH=_VQvhHKemfOOvVFSu9K+Go1LB5e2Ck214KdLJvtE--z8Hg@mail.gmail.com>
 <CAC20D2O8iAMhmywzywVkAZqzcHELH5fDLsc+HtwArh2Ft=yoPA@mail.gmail.com>
Message-ID: <65E0C49A-2115-47F9-89C1-AEAF2633FD98@technologists.com>



> On Mar 29, 2018, at 7:40 PM, Clem Cole <clemc at ccc.com> wrote:
> 
> 
> 
> On Thu, Mar 29, 2018 at 5:37 PM, Paul Winalski <paul.winalski at gmail.com <mailto:paul.winalski at gmail.com>> wrote:
> Also, when was symbol preemption invented?  Traditional shared library
> designs such as in IBM System/370, VMS, and Windows NT doesn't have
> it.  As one who worked on optimizations in compilers, I came to hate
> symbol preemption because it prohibits many useful optimizations.  ELF
> does provide a way to turn it off, but it's on by default--you have to
> explicitly declare symbols as protected or hidden via source language
> pragmas to get rid of it.
> 
> ​Unless it came from a place like Sun or Sun where Larry or Charlie might remember, I suspect that Steve Johnson is probably best to answer this part of your question -- assuming that it was created during his time in the compiler team in Summit.
> 
> But, I don't remember when it came on to the scene frankly because it did not effect me.   I think it might have been in the original COFF which came from those days, but its possible its from one of the many bastardization of COFF that occurred after its birth.    I don't remember it being in any of the a.out flavors and I don't think macho has it.
> 
> As an OS guy, all I remember about it frankly is you and some the compiler folks b*tching about it as a misfeature of UNIX at lunch ;-)
> 
> ​
> ᐧ


I’m not sure if Clem meant to type “Sun or IBM where Larry or Charlie” … 

I don’t readily find any documentation or history older than AIX 4.2, well beyond my tenure, but I believe we had shared libraries from the very beginning with AIX on the RT, presumably based on a.out. My recollection is that this was driven by (late) Larry Loucks, with assistance from Jack O’Quin and several of the ISC folks.

Charlie

--
voice: +1.512.784.7526       e-mail: sauer at technologists.com <mailto:sauer at technologists.com>           
fax: +1.512.346.5240         web: http://technologists.com/sauer/ <http://technologists.com/sauer/>
Facebook/Google/Skype/Twitter: CharlesHSauer

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180329/4029b08e/attachment.html>

From lm at mcvoy.com  Fri Mar 30 12:10:16 2018
From: lm at mcvoy.com (Larry McVoy)
Date: Thu, 29 Mar 2018 19:10:16 -0700
Subject: [TUHS] shared objects in Unix
In-Reply-To: <65E0C49A-2115-47F9-89C1-AEAF2633FD98@technologists.com>
References: <CABH=_VQvhHKemfOOvVFSu9K+Go1LB5e2Ck214KdLJvtE--z8Hg@mail.gmail.com>
 <CAC20D2O8iAMhmywzywVkAZqzcHELH5fDLsc+HtwArh2Ft=yoPA@mail.gmail.com>
 <65E0C49A-2115-47F9-89C1-AEAF2633FD98@technologists.com>
Message-ID: <20180330021016.GK8921@mcvoy.com>

On Thu, Mar 29, 2018 at 08:35:50PM -0500, Charles H. Sauer wrote:
> 
> 
> > On Mar 29, 2018, at 7:40 PM, Clem Cole <clemc at ccc.com> wrote:
> > 
> > 
> > 
> > On Thu, Mar 29, 2018 at 5:37 PM, Paul Winalski <paul.winalski at gmail.com <mailto:paul.winalski at gmail.com>> wrote:
> > Also, when was symbol preemption invented?  Traditional shared library
> > designs such as in IBM System/370, VMS, and Windows NT doesn't have
> > it.  As one who worked on optimizations in compilers, I came to hate
> > symbol preemption because it prohibits many useful optimizations.  ELF
> > does provide a way to turn it off, but it's on by default--you have to
> > explicitly declare symbols as protected or hidden via source language
> > pragmas to get rid of it.
> > 
> > ???Unless it came from a place like Sun or Sun where Larry or Charlie might remember, I suspect that Steve Johnson is probably best to answer this part of your question -- assuming that it was created during his time in the compiler team in Summit.
> > 
> > But, I don't remember when it came on to the scene frankly because it did not effect me.   I think it might have been in the original COFF which came from those days, but its possible its from one of the many bastardization of COFF that occurred after its birth.    I don't remember it being in any of the a.out flavors and I don't think macho has it.
> > 
> > As an OS guy, all I remember about it frankly is you and some the compiler folks b*tching about it as a misfeature of UNIX at lunch ;-)
> > 
> > ???
> > ???
> 
> 
> I???m not sure if Clem meant to type ???Sun or IBM where Larry or Charlie??? ??? 
> 
> I don???t readily find any documentation or history older than AIX 4.2, well beyond my tenure, but I believe we had shared libraries from the very beginning with AIX on the RT, presumably based on a.out. My recollection is that this was driven by (late) Larry Loucks, with assistance from Jack O???Quin and several of the ISC folks.

What was the underlying technology that enabled them in AIX?


From sauer at technologists.com  Fri Mar 30 12:34:09 2018
From: sauer at technologists.com (Charles H. Sauer)
Date: Thu, 29 Mar 2018 21:34:09 -0500
Subject: [TUHS] shared objects in Unix
In-Reply-To: <20180330021016.GK8921@mcvoy.com>
References: <CABH=_VQvhHKemfOOvVFSu9K+Go1LB5e2Ck214KdLJvtE--z8Hg@mail.gmail.com>
 <CAC20D2O8iAMhmywzywVkAZqzcHELH5fDLsc+HtwArh2Ft=yoPA@mail.gmail.com>
 <65E0C49A-2115-47F9-89C1-AEAF2633FD98@technologists.com>
 <20180330021016.GK8921@mcvoy.com>
Message-ID: <1D00C2FE-B36F-4CC3-8548-6FB677443C39@technologists.com>



> On Mar 29, 2018, at 9:10 PM, Larry McVoy <lm at mcvoy.com> wrote:
> 
> On Thu, Mar 29, 2018 at 08:35:50PM -0500, Charles H. Sauer wrote:
>> 
>> 
>>> On Mar 29, 2018, at 7:40 PM, Clem Cole <clemc at ccc.com> wrote:
>>> 
>>> 
>>> 
>>> On Thu, Mar 29, 2018 at 5:37 PM, Paul Winalski <paul.winalski at gmail.com <mailto:paul.winalski at gmail.com>> wrote:
>>> Also, when was symbol preemption invented?  Traditional shared library
>>> designs such as in IBM System/370, VMS, and Windows NT doesn't have
>>> it.  As one who worked on optimizations in compilers, I came to hate
>>> symbol preemption because it prohibits many useful optimizations.  ELF
>>> does provide a way to turn it off, but it's on by default--you have to
>>> explicitly declare symbols as protected or hidden via source language
>>> pragmas to get rid of it.
>>> 
>>> ???Unless it came from a place like Sun or Sun where Larry or Charlie might remember, I suspect that Steve Johnson is probably best to answer this part of your question -- assuming that it was created during his time in the compiler team in Summit.
>>> 
>>> But, I don't remember when it came on to the scene frankly because it did not effect me.   I think it might have been in the original COFF which came from those days, but its possible its from one of the many bastardization of COFF that occurred after its birth.    I don't remember it being in any of the a.out flavors and I don't think macho has it.
>>> 
>>> As an OS guy, all I remember about it frankly is you and some the compiler folks b*tching about it as a misfeature of UNIX at lunch ;-)
>>> 
>>> ???
>>> ???
>> 
>> 
>> I???m not sure if Clem meant to type ???Sun or IBM where Larry or Charlie??? ??? 
>> 
>> I don???t readily find any documentation or history older than AIX 4.2, well beyond my tenure, but I believe we had shared libraries from the very beginning with AIX on the RT, presumably based on a.out. My recollection is that this was driven by (late) Larry Loucks, with assistance from Jack O???Quin and several of the ISC folks.
> 
> What was the underlying technology that enabled them in AIX?

I didn’t pay much attention to this at the time, and don’t remember specifics. 

Given the change in focus from RT to RS/6000 in the transition from AIX 2 to AIX 3, and all of the other changes that occurred in AIX 3, I assume we started with something very primitive in AIX 1 and re-implemented for AIX 3. 

I’ve sent Jack a note about this discussion. Unless he or ISC folks chime in, or I find someone else to comment or provide documentation, I probably can’t add more. Rick Simpson wrote an article for Byte that might have something about this. He probably contributed to the initial design and (presumed) re-design.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180329/2e86423c/attachment.html>

From ron at ronnatalie.com  Fri Mar 30 13:00:41 2018
From: ron at ronnatalie.com (Ron Natalie)
Date: Thu, 29 Mar 2018 23:00:41 -0400
Subject: [TUHS] shared objects in Unix
In-Reply-To: <CAC20D2O8iAMhmywzywVkAZqzcHELH5fDLsc+HtwArh2Ft=yoPA@mail.gmail.com>
References: <CABH=_VQvhHKemfOOvVFSu9K+Go1LB5e2Ck214KdLJvtE--z8Hg@mail.gmail.com>
 <CAC20D2O8iAMhmywzywVkAZqzcHELH5fDLsc+HtwArh2Ft=yoPA@mail.gmail.com>
Message-ID: <01f301d3c7d3$4abb1d80$e0315880$@ronnatalie.com>

I’m fairly sure Unix didn’t invent the dynamic linking symbol preemption.    It was fundamental in the UNIVAC Exec8 operating system.  

 

EXEC8 also predates UNIX on the concept of fork() (or as they call it ER FORK$).

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180329/9f44f4e4/attachment.html>

From imp at bsdimp.com  Fri Mar 30 13:04:34 2018
From: imp at bsdimp.com (Warner Losh)
Date: Thu, 29 Mar 2018 21:04:34 -0600
Subject: [TUHS] shared objects in Unix
In-Reply-To: <1D00C2FE-B36F-4CC3-8548-6FB677443C39@technologists.com>
References: <CABH=_VQvhHKemfOOvVFSu9K+Go1LB5e2Ck214KdLJvtE--z8Hg@mail.gmail.com>
 <CAC20D2O8iAMhmywzywVkAZqzcHELH5fDLsc+HtwArh2Ft=yoPA@mail.gmail.com>
 <65E0C49A-2115-47F9-89C1-AEAF2633FD98@technologists.com>
 <20180330021016.GK8921@mcvoy.com>
 <1D00C2FE-B36F-4CC3-8548-6FB677443C39@technologists.com>
Message-ID: <CANCZdfqLY5MLZxOZqEcvOuG3TaXrKXvY1=47QPegsXKdiTT0wQ@mail.gmail.com>

On Thu, Mar 29, 2018 at 8:34 PM, Charles H. Sauer <sauer at technologists.com>
wrote:

>
>
> On Mar 29, 2018, at 9:10 PM, Larry McVoy <lm at mcvoy.com> wrote:
>
> On Thu, Mar 29, 2018 at 08:35:50PM -0500, Charles H. Sauer wrote:
>
>
>
> On Mar 29, 2018, at 7:40 PM, Clem Cole <clemc at ccc.com> wrote:
>
>
>
> On Thu, Mar 29, 2018 at 5:37 PM, Paul Winalski <paul.winalski at gmail.com <
> mailto:paul.winalski at gmail.com <paul.winalski at gmail.com>>> wrote:
> Also, when was symbol preemption invented?  Traditional shared library
> designs such as in IBM System/370, VMS, and Windows NT doesn't have
> it.  As one who worked on optimizations in compilers, I came to hate
> symbol preemption because it prohibits many useful optimizations.  ELF
> does provide a way to turn it off, but it's on by default--you have to
> explicitly declare symbols as protected or hidden via source language
> pragmas to get rid of it.
>
> ???Unless it came from a place like Sun or Sun where Larry or Charlie
> might remember, I suspect that Steve Johnson is probably best to answer
> this part of your question -- assuming that it was created during his time
> in the compiler team in Summit.
>
> But, I don't remember when it came on to the scene frankly because it did
> not effect me.   I think it might have been in the original COFF which came
> from those days, but its possible its from one of the many bastardization
> of COFF that occurred after its birth.    I don't remember it being in any
> of the a.out flavors and I don't think macho has it.
>
> As an OS guy, all I remember about it frankly is you and some the compiler
> folks b*tching about it as a misfeature of UNIX at lunch ;-)
>
> ???
> ???
>
>
>
> I???m not sure if Clem meant to type ???Sun or IBM where Larry or
> Charlie??? ???
>
> I don???t readily find any documentation or history older than AIX 4.2,
> well beyond my tenure, but I believe we had shared libraries from the very
> beginning with AIX on the RT, presumably based on a.out. My recollection is
> that this was driven by (late) Larry Loucks, with assistance from Jack
> O???Quin and several of the ISC folks.
>
>
> What was the underlying technology that enabled them in AIX?
>
>
> I didn’t pay much attention to this at the time, and don’t remember
> specifics.
>
> Given the change in focus from RT to RS/6000 in the transition from AIX 2
> to AIX 3, and all of the other changes that occurred in AIX 3, I assume we
> started with something very primitive in AIX 1 and re-implemented for AIX
> 3.
>

Wikipedia says AIX v3 did shared libraries in 1990. SunOS 4.0 had them in
1988, also from wikipedia (though I can confirm 4.0 had shared libraries
now). I recall vaguely working with them in 1991 when porting OI from SunOS
to AIX 3.mumble, iirc. xlC was the weirdest C++ compiler at the time (which
effectively means it wasn't cfront based). But I can't say with absolute
certainty....

I’ve sent Jack a note about this discussion. Unless he or ISC folks chime
> in, or I find someone else to comment or provide documentation, I probably
> can’t add more. Rick Simpson wrote an article for Byte that might have
> something about this. He probably contributed to the initial design and
> (presumed) re-design.
>

I'd love to see something more definitive than my memory at the time +
vague backup from Wikipedia...
http://ps-2.kev009.com/rs6000/aix_ps_pdf/programming/using_shared_libraries.pdf
is a primary source, but talks of AIX 4.1

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180329/cfd3fbdc/attachment.html>

From clemc at ccc.com  Fri Mar 30 14:28:13 2018
From: clemc at ccc.com (Clem cole)
Date: Fri, 30 Mar 2018 00:28:13 -0400
Subject: [TUHS] shared objects in Unix
In-Reply-To: <20180330014642.GI8921@mcvoy.com>
References: <CABH=_VQvhHKemfOOvVFSu9K+Go1LB5e2Ck214KdLJvtE--z8Hg@mail.gmail.com>
 <alpine.BSF.2.21.1803301009140.3361@aneurin.horsfall.org>
 <20180329232409.GH8921@mcvoy.com>
 <CAC20D2ORfP-bCTZiM0rxYywGmF7QpsORTtCGx86++tzeyjRwbw@mail.gmail.com>
 <20180330014642.GI8921@mcvoy.com>
Message-ID: <048A69EA-7B2C-4D2C-A69B-76CE8E082826@ccc.com>

You might be right i don’t exactly remember the dates of each release.  that said I do remember  Mach ran on a number of systems before Next, but they were not commercial.  It was similar to BSD where CMU ported to that hardware - I’ve forgotten the name of the guys that spun out of DG that had an early MP based system that used reflected memory- but I remember CMU had very early version of Mach running there that was based on the 4.1mash up like the original Vax code from CMU that they started.  

The point is that early Mach was working before 4.2 way final and released to the DARPA community not much later. CRSG was doing Val support for DARPA and CMU was more researchy (which was a point of contention in a lot of fronts that I’ll not scratch open any further).

I was not commenting on the implementation of the goodness of the CMU or CSRG code by the wsy.  Sun could have had the first commercial version of shared libs that worked well, although IBM might have been around the same time as Charlie pointed.  

What had Paul asked when shared libs came to being for Unix.  I was trying to say it did not come from any one point.  I do believe Mach and it’s parent Accent (which was not Unix) was the first time any Unix had it but like BSD was a DARPA funded project and not commercial. But a lot of different places were working on the idea as it was commonly held to be an issue with Unix. 

Also, joy / BSD 4.2 was heavily influenced by Accent (and RIG )and the Mach memory system would eventually go back into BSD (4.3 IIRC) - which we have talked about before wrt to sockets and Accent/Mach’s port concept. 

FWIW If I'm remembering the sequence right I believe Mach 2.5 was quickly created as a update to the original release after joy et al released the final 4.2.  4.1c was 83 as I was leaving UCB and I brought it with me.  But  I think we had an early 4.1 based Mach tape at Masscomp not too much later ??a year maybe??  And one of the reasons we were interested in it was the shared library code because the exVMS at Masscomp all felt that was a deficiency of Unix and at the time the only ‘open source’ in a HLL if you will that had it was Mach. 


Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. 

> On Mar 29, 2018, at 9:46 PM, Larry McVoy <lm at mcvoy.com> wrote:
> 
>> On Thu, Mar 29, 2018 at 08:22:14PM -0400, Clem Cole wrote:
>> I'm pretty sure the first unix to support shared libraries was
>> CMU's Mach using its modified about called macho, which lives today in Mac
>> OSX.     
> 
> Uh, you sure about that?
> 
> http://cs.cmu.edu/afs/cs.cmu.edu/project/mach/public/doc/published/mapfiles87.ps
> 
> is as close as I can find, and that's talking about stuff that was long after
> Sun's shared libraries.
> 
> There may have been earlier stuff but the approach laid out in
> 
> http://www.mcvoy.com/lm/papers/SunOS.shlib.pdf
> 
> is pretty much the shared library world as we know it today so far as I
> know.
> 
> I remember the world before that, I lived in it, and shared libraries were
> not a working thing in my memory.  Maybe on VMS, I didn't program much on
> VMS, but on any Unix I could get my hands on, Sun was the first to have
> working shared libraries.
> 
> CMU's Mach, mem, I am by no means a fan (I bought into the hype, read
> all the papers, when I finally got to see the code, wow.  NOTHING like Sun's
> VM system, I mean, nothing.  It claimed to be the same sort of thing, it was
> an ugly mess and it still is.  Sun's VM system was a thing of beauty, you
> could read the code and figure out the architecture from the code.  I'd 
> challenge anyone to do that from the Mach code).  
> 
> But maybe it had shared libs before SunOS but who was using that code?
> So far as I know the first time the Mach code was in a commercial product
> was Next.  Their first release was October 1988, SunOS 4.0 was Dec 1988
> and was a far far far more mature release.
> 
> Here's a way to put it into perspective.  In the mid 80's, and maybe 
> before, every single open source project's makefile just worked on
> a Sun.  I don't ever remember seeing a Makefile that just worked on 
> a Next (and I don't know of any other Mach based platform until Apple
> many years later).


From sauer at technologists.com  Sat Mar 31 06:33:45 2018
From: sauer at technologists.com (Charles H Sauer)
Date: Fri, 30 Mar 2018 15:33:45 -0500
Subject: [TUHS] shared objects in Unix
In-Reply-To: <1D00C2FE-B36F-4CC3-8548-6FB677443C39@technologists.com>
References: <CABH=_VQvhHKemfOOvVFSu9K+Go1LB5e2Ck214KdLJvtE--z8Hg@mail.gmail.com>
 <CAC20D2O8iAMhmywzywVkAZqzcHELH5fDLsc+HtwArh2Ft=yoPA@mail.gmail.com>
 <65E0C49A-2115-47F9-89C1-AEAF2633FD98@technologists.com>
 <20180330021016.GK8921@mcvoy.com>
 <1D00C2FE-B36F-4CC3-8548-6FB677443C39@technologists.com>
Message-ID: <6B220C837E77400D8BBA3752D746FB51@studyvista>

  On Thu, Mar 29, 2018 at 09:35PM -0500, Charles H. Sauer wrote:



    On Mar 29, 2018, at 9:10 PM, Larry McVoy <lm at mcvoy.com> wrote:

    On Thu, Mar 29, 2018 at 08:35:50PM -0500, Charles H. Sauer wrote:

      I don’t readily find any documentation or history older than AIX 4.2, well beyond my tenure, but I believe we had shared libraries from the very beginning with AIX on the RT, presumably based on a.out. My recollection is that this was driven by (late) Larry Loucks, with assistance from Jack O’Quin and several of the ISC folks.

    What was the underlying technology that enabled them in AIX?

  I didn’t pay much attention to this at the time, and don’t remember specifics. 


  Given the change in focus from RT to RS/6000 in the transition from AIX 2 to AIX 3, and all of the other changes that occurred in AIX 3, I assume we started with something very primitive in AIX 1 and re-implemented for AIX 3. 


  I’ve sent Jack a note about this discussion. Unless he or ISC folks chime in, or I find someone else to comment or provide documentation, I probably can’t add more. Rick Simpson wrote an article for Byte that might have something about this. He probably contributed to the initial design and (presumed) re-design.

Jack responded, credits Larry regarding AIX 1 & 2 and adds a little about AIX 3 re-implementation: 
  Larry was definitely the driving force behind shared library support in AIX on the RT. While I did some minor compiler optimization work in that timeframe, I didn't work on the linker, which was the traditional Unix "ld" implementation, ported by ISC. I don't remember what, if any, special work they may have done to support shared libraries.

  I had more to do with the RS/6000 implementation. That linker had been written at Yorktown by Greg Chaiten (of information theory fame). It was highly optimized for fast loading with shared libraries. All load-time external references were collected into a Table of Contents that fit in a few contiguous pages. The rest of the executable was read-only, with pages that could be shared and reused by multiple processes.
  -- 

  joq

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180330/0735731f/attachment.html>

From nobozo at gmail.com  Sat Mar 31 06:52:44 2018
From: nobozo at gmail.com (Jon Forrest)
Date: Fri, 30 Mar 2018 13:52:44 -0700
Subject: [TUHS] shared objects in Unix
In-Reply-To: <048A69EA-7B2C-4D2C-A69B-76CE8E082826@ccc.com>
References: <CABH=_VQvhHKemfOOvVFSu9K+Go1LB5e2Ck214KdLJvtE--z8Hg@mail.gmail.com>
 <alpine.BSF.2.21.1803301009140.3361@aneurin.horsfall.org>
 <20180329232409.GH8921@mcvoy.com>
 <CAC20D2ORfP-bCTZiM0rxYywGmF7QpsORTtCGx86++tzeyjRwbw@mail.gmail.com>
 <20180330014642.GI8921@mcvoy.com>
 <048A69EA-7B2C-4D2C-A69B-76CE8E082826@ccc.com>
Message-ID: <be27e8d3-8549-a056-9a1f-0fb31fca4eab@gmail.com>




[Larry McVoy said ...]
>> CMU's Mach, mem, I am by no means a fan (I bought into the hype, read
>> all the papers, when I finally got to see the code, wow.  NOTHING like Sun's
>> VM system, I mean, nothing.  It claimed to be the same sort of thing, it was
>> an ugly mess and it still is.

This is typical of university research projects. To those of us who
worked in the Postgres research group at UC Berkeley, one of the great
mysteries of the world is how the PostgreSQL community was able to take
the research Postgres code and make it into the production quality
database it is now.

Most research projects suffer because the goal of the people who
work on it is to hack on it to get their research done, so that
they can get their MS/PhD and then get the hell out. Code quality
is rarely a major concern. Postgres (and Ingres) benefited from
having a Chief Programmer who attempted to minimize this problem.

Jon Forrest




From scj at yaccman.com  Sat Mar 31 07:53:09 2018
From: scj at yaccman.com (Steve Johnson)
Date: Fri, 30 Mar 2018 14:53:09 -0700
Subject: [TUHS] shared objects in Unix
In-Reply-To: <CAC20D2O8iAMhmywzywVkAZqzcHELH5fDLsc+HtwArh2Ft=yoPA@mail.gmail.com>
Message-ID: <d8695042750040224892d559107c7a1b716a911b@webmail.yaccman.com>



----- Original Message -----
From: "Clem Cole" <clemc at ccc.com>
To:"Paul Winalski" <paul.winalski at gmail.com>
Cc:"The Eunuchs Hysterical Society" <tuhs at tuhs.org>
Sent:Thu, 29 Mar 2018 20:40:36 -0400
Subject:Re: [TUHS] shared objects in Unix

....

​Unless it came from a place like Sun or Sun where Larry or Charlie
might remember, I suspect that Steve Johnson is probably best to
answer this part of your question -- assuming that it was created
during his time in the compiler team in Summit.

I think shared libraries were already in the code base (although
perhaps not released) when I came to Summit in 1982.   One of my
main motivations was to make a product out of C++, which already
looked like a winner in Research.  One of the first things I did was
to ship cfront -- this was a RATFOR like extension that translated C++
into C and then compiled it.   Writing C++ with it wasn't too bad,
because it mapped the C++ line numbers into the C file, but debugging
it was ghastly.  The mapping to C involved long names that had
encoded information about the type and class membership and other
gook, making the debugger almost worthless.  (We were also shipping
Pascal, Ada, and Fortran, which had lesser versions of the same
problem).  So we immediately set off to improve the debugging.  I
think shared libraries was based on an implementation done in a
development area rather than Research, but it and COFF got a lot of
tweaking to support Elf and Dwarf.  A real C++ compiler, based on the
PCC2 backend, came along as well, about the time we got the debugging
figured out, and the final product was, IMHO, pretty respectable.

A word about why I went to Summit.  When I started managing, my
interest in technology transfer ramped up quickly.  As far as AT&T
was concerned, the research culture and the development culture were
very different.  And the only technology transfer that seemed to work
involved moving people.  Reseach people had the best job in the
world, and didn't want to move. But I found that, more and more, I was
enjoying writing code that people liked to use much more than I
enjoyed giving papers to 200 people who couldn't wait for me to sit
down so they could talk about what they were doing.  So I decided to
give it a try.

I still remember my first staff meeting with my department's
supervisors.  In 15 years in Reasearch, I never had heard anyone
commit to deliver a given feature at a given time!  And this happened
many times in that meeting.  By the end, I realized that I wasn't in
Kansas any more...   I learned tons from my supervisors, and I think
they learned a lot from me.  It was altogether a wonderful
experience, except for the fact that AT&T continually demonstrated its
complete ignorance of the software marketplace by hiring clueless
people.  At one point, a documentation person wrote up so
documentation based on fodder we have given them.  When it came back,
it was completely incoherent.  I gave it to my supervisors and they
didn't get it either.  Suddenly one said.  "My God!  They think the
Fortran Optimizer is a piece of hardware!"   Sure enough, from that
point of view it made sense despite its total isolation from the real
world.

Steve


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180330/8e297379/attachment.html>

From clemc at ccc.com  Sat Mar 31 08:42:09 2018
From: clemc at ccc.com (Clem Cole)
Date: Fri, 30 Mar 2018 18:42:09 -0400
Subject: [TUHS] shared objects in Unix
In-Reply-To: <be27e8d3-8549-a056-9a1f-0fb31fca4eab@gmail.com>
References: <CABH=_VQvhHKemfOOvVFSu9K+Go1LB5e2Ck214KdLJvtE--z8Hg@mail.gmail.com>
 <alpine.BSF.2.21.1803301009140.3361@aneurin.horsfall.org>
 <20180329232409.GH8921@mcvoy.com>
 <CAC20D2ORfP-bCTZiM0rxYywGmF7QpsORTtCGx86++tzeyjRwbw@mail.gmail.com>
 <20180330014642.GI8921@mcvoy.com>
 <048A69EA-7B2C-4D2C-A69B-76CE8E082826@ccc.com>
 <be27e8d3-8549-a056-9a1f-0fb31fca4eab@gmail.com>
Message-ID: <CAC20D2P3FXPeC-Vy+rpuNh9j9vcNfca=ASDLYMK2HM4k+vSn-g@mail.gmail.com>

On Fri, Mar 30, 2018 at 4:52 PM, Jon Forrest <nobozo at gmail.com> wrote:

> [Larry McVoy said ...]
>
>> CMU's Mach, mem,
>>> ​...
>>>  NOTHING like Sun's
>>> VM system, I mean, nothing.
>>>
>>
> ​...
>


> Most research projects suffer because the goal of the people who
> ​ ​
> work on it is to hack on it to get their research done,


​Two things...

1.) I think we are in complete agreement wrt to code quality - and I think
LM is probably correct that Sun had the first real quality implementation.
2.) Paul's question was a little different and I was able to chat with him
about it at lunch today.    Until a year or so ago, Paul was a
compiler/linker guy and was interested less in the OS extension to support
shared libraries, but more when did different tool chains start to support
it. * i.e.* How did we get from a.out to ELF.

The key is that make shared libraries real for the tool chain, you need OS
support for shared memories.    It turns out that Joy's BSD Unix took its
shared memory API (mmap) from Tenex's 'PMAP JSYS' (which BTW, the '72 Tenex
CACM paper calls out shared libraries modelled after Multics - I was trying
to google the API specific and failed - I think its darned near 1x1).  I'm
also pretty sure that PMAP influenced the VMS shared memory call that
Cutler would build in the mid 70s.  Not only that, In Rashid's 81 Accent
paper, he too referenced Tenex's PMAP too (more in a minute).

Also, please remember, that BSD's mmap was not the first shared memory call
for any UNIX.  Horton & Johnson can correct me, but I think Dale's team in
Columbus had a shared memory in a  PDP-11 ??PWB 1.0?? style system - that
would eventually begat the System V shmem call (i've got a hard copy of it
somewhere in my archives).

What I do not remember, and this is where someone like Steve might know,
was could COFF use the Columbus shmem to do shared libs?   Certainly by
that time, shared libraries for UNIX was being heavily discussed both in
and out of AT&T.  I remember that either V.2 or V.3 had a shared lib scheme
that put the libraries at a static address as the System V kernel support
was not very flexible.   But to Paul's question, was that AT&T had started
to put shared libs into their flavor around the same time?   *i.e. *when
did Summit start to support it.

I was trying to get an account of which versions of which OS
distributions/releases had some sorts of kernel extensions that allowed
shared libraries and that also supported tool chains that could provide
them -- *i.e.* what Paul was asking about.  I was not commenting on who's
kernel to support same was good or bad.  I did comment on the file format.
COFF was a dead end because of the way Summit's management introduced it to
larger Unix community, even if it was 'better' and solved some of the
earlier issues with a.out.

Macho was already there for instance, and it was an 'extensible' version of
a.out and had some level of support for architecture of the binary
contained within.   How v6/v7 a.out got extended to support shared libs,
had varied widely by different manufacturers tool chains.   Originally,
most manufacturers still called it a.out and just hacked on their own
version of the toolchain.  CMU gave it a different name (macho) and IIRC made
the kernel handle both *i.e. *still supported the original BSD a.out but
you were limited in what could be done with it to only the 4.1BSD api.
Remember, Mach 1.0, reacting to Accent' failure, was BSD4.1++ so they
wanted to be able to run BSD binaries, at least on Vaxen.  In fact the way
you installed Mach1.0 was build a new kernel boot it on your 4.1BSD system.
Binary compatibility was sort of new concept for the University community
--- in fact, around that time at UCB I remember Joy once saying he thought
it was good to force people to recompile as it ensured the code was not
stale.


So moving forward, AT&T's COFF had tried to repair the many different
a.outs, but AT&T made other major non-technical missteps so only firms that
were late in the Unix world bothered with it.  And even after trying to be
'common', it too,  got extended in N different incompatible (uncommon) ways.

As I said, I am not sure how ELF really became the universal format, other
than timing.   AT&T for whatever reason did not have a fit when it was
reimplemented by Gnu - but by the Gnu guys doing that, and the FOSS
community switching to that version of the compiler, ELF did win in the
long run.   And fortunately, the Gnu version of ELF and the SVR4 version
seems/appears to be were pretty close [as far as I know they matched, but
if someone knows otherwise, I defer to them].

As for the kernel stuff, my other point is that >>idea<< of mmap/pmap was
kicking around the Unix community by numerous folks hacking on the kernel
for a longer time then when it was finally implemented.  LM reminds us that
you need something for memory sharing to implement shared libraries.  But
memory sharing added to Unix before shared libraries was added to the tool
chains.

 I do find it interesting the UCB mmap API call pretty much was all of the
Unix kernel implementation agreed to be the memory sharing API and that it
happens to be pretty much the same call as Tenex's PMAP.   As Paul
mentioned at lunch today for him, VMS, Tenex/TOP-20 and eventually Unix it
was pretty much the same call for him implementing the user space
linker/loader calls, which is part of why he was asking when did the tools
start to support it all.

Clem
ᐧ
ᐧ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180330/2341c230/attachment.html>

From cym224 at gmail.com  Sat Mar 31 09:22:57 2018
From: cym224 at gmail.com (Nemo)
Date: Fri, 30 Mar 2018 19:22:57 -0400
Subject: [TUHS] Novell, not SCO, found to own "Unix"
In-Reply-To: <alpine.BSF.2.21.1803300721250.3361@aneurin.horsfall.org>
References: <alpine.BSF.2.21.1803300721250.3361@aneurin.horsfall.org>
Message-ID: <CAJfiPzx+0A9oQrhwfKiwH4f-Fea9e0URe=wihJAvBOxiuitWiA@mail.gmail.com>

On 29/03/2018, Dave Horsfall <dave at horsfall.org> wrote:
> Time for another hand-grenade in the duck pond :-)  Or as we call it
> down-under, "stirring the possum".
>
> On this day in 2010, it was found unanimously that Novell, not SCO, owned
> "Unix".  SCO appealed later, and it was dismissed "with prejudice"; SCO
> shares plummeted as a result.
>
> As an aside, this was the first and only time that I was on IBM's side,
> and I still wonder whether M$ was bankrolling SCO in an effort to wipe
> Linux off the map; what sort of an idiot would take on IBM?

Methinks a mention of the wonderful record at Groklaw
(http://www.groklaw.net) is in order.

N.

>
> --
> Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will
> suffer."
>


From paul.winalski at gmail.com  Sat Mar 31 09:29:03 2018
From: paul.winalski at gmail.com (Paul Winalski)
Date: Fri, 30 Mar 2018 19:29:03 -0400
Subject: [TUHS] shared objects in Unix
In-Reply-To: <CAC20D2P3FXPeC-Vy+rpuNh9j9vcNfca=ASDLYMK2HM4k+vSn-g@mail.gmail.com>
References: <CABH=_VQvhHKemfOOvVFSu9K+Go1LB5e2Ck214KdLJvtE--z8Hg@mail.gmail.com>
 <alpine.BSF.2.21.1803301009140.3361@aneurin.horsfall.org>
 <20180329232409.GH8921@mcvoy.com>
 <CAC20D2ORfP-bCTZiM0rxYywGmF7QpsORTtCGx86++tzeyjRwbw@mail.gmail.com>
 <20180330014642.GI8921@mcvoy.com>
 <048A69EA-7B2C-4D2C-A69B-76CE8E082826@ccc.com>
 <be27e8d3-8549-a056-9a1f-0fb31fca4eab@gmail.com>
 <CAC20D2P3FXPeC-Vy+rpuNh9j9vcNfca=ASDLYMK2HM4k+vSn-g@mail.gmail.com>
Message-ID: <CABH=_VRNbkVvMduP4L5m3+BCi=uf3qLnXkRo2f3k59un7qWqJw@mail.gmail.com>

Regarding the various object/program image formats on Unix:

a.out ZMAGIC had three sections (.text, .data, BSS) and .text was
read-only and therefore shareable between processes running the same
image.  And if .text and .data started on a page boundary, you could
do demand paging of them from the a.out file on disk (you'd of course
need to do copy-on-write of .data to space in a page file).  I can see
how, with mmap, one could map multiple ZMAGIC images to the same
address space, thus implementing shared objects, but there isn't
anything in ZMAGIC to direct the runtime loader as to which images
need to be so mapped or where to map them.

MACH-O was a big advance over a.out in that it was extensible--you
could have up to 16 sections.  MacOS-X indeed uses some of the extra
sections to implement its shared memory scheme.

COFF was another step forward.  One now had a lot more sections to
play with.  But a lot of the meta-data needed by the runtime loader to
do shared image binding was in auxiliary data structures outside such
as the optional header (which in practice is anything but optional).
And, as Clem pointed out, it suffered from a dialect problem.
Microsoft adopted COFF as the object and image format for Windows NT.
But as MS does so often, they took a "embrace and extend" approach to
it.  When I had to implement object file writing support in DEC's GEM
back end for Microsoft PECOFF, I found it significantly different from
Tru64 Unix's COFF.  I found myself putting so many "if (is_pecoff)"
conditionals in the code that I gave up on that and wrote a separate
module for PECOFF (just as the VMS OBJ support had its own module).
The two COFF-based shared object designs I'm familiar with (Tru64 Unix
and Windows NT) both hung the data structures for shared object
loading off of the optional header.

ELF is the cleanest and the easiest to work with, from a compiler
writer's point of view.  Everything is a section.  The one mistake
they made was using a 16-bit field for the section number, thus
limiting each file to 64K sections.  The grouped communal sections for
C++ can blow through that limit quite easily.  A hack was later added
to ELF to support 32-bit section numbers.  It's not as clean as it
would have been if section numbers had been 32 bits from the get-go,
but it does mean that only modules that need a grossly large number of
sections incur the file bloat from the larger section numbers.  ELF is
nice enough that when VMS did their port to Itanium, they decided to
use ELF rather than try to add Itanium's extensive set of relocations
to the OBJ format in use on Alpha.

-Paul W.


From tytso at mit.edu  Sat Mar 31 10:34:30 2018
From: tytso at mit.edu (Theodore Y. Ts'o)
Date: Fri, 30 Mar 2018 20:34:30 -0400
Subject: [TUHS] Novell, not SCO, found to own "Unix"
In-Reply-To: <CAJfiPzx+0A9oQrhwfKiwH4f-Fea9e0URe=wihJAvBOxiuitWiA@mail.gmail.com>
References: <alpine.BSF.2.21.1803300721250.3361@aneurin.horsfall.org>
 <CAJfiPzx+0A9oQrhwfKiwH4f-Fea9e0URe=wihJAvBOxiuitWiA@mail.gmail.com>
Message-ID: <20180331003430.GH9300@thunk.org>

On Fri, Mar 30, 2018 at 07:22:57PM -0400, Nemo wrote:
> > As an aside, this was the first and only time that I was on IBM's side,
> > and I still wonder whether M$ was bankrolling SCO in an effort to wipe
> > Linux off the map; what sort of an idiot would take on IBM?
> 
> Methinks a mention of the wonderful record at Groklaw
> (http://www.groklaw.net) is in order.

The idiots were at SCO.  In terms of Microsoft, if that theory is
true, it makes sense if you think in a fairly amoral way ("fiduciary
responsibility to shareholders excuses all business tactics" aka the
sociopathic theory of corporations) and consider it a fairly cheap PR
campaign to spread FUD about Linux.  So it you could actually consider
it a fairly cunning tactics; it was probably cheaper than, say, the
national TV advertising spots IBM had been running to support Linux.

Of course, whether SCO was actually colluding with Microsoft, or just
a "useful idiot" that was manipulated into taking on IBM, who knows?
And short of having a special prosecutor look into it, I doubt we'll
ever know for sure.

Speaking of PR exercises, there were rumors that Pamela at Groklaw was
secretly being funded by IBM as a counter PR campaign.  Even as an IBM
employee, I never saw any hard evidence of this, and everything Pamela
posted was backed by hard legal analysis and the actual court filings,
but I know people who were quite familiar with the players (including
those who knew, or at least claimed, that Pamela lived in Westchester
County in upstate NY) who were quite certain of this theory.
Certainly if it were not true, the person or people running Groklaw
must have donated huge amounts of their free time to keep the site
running and post the very rich amount of content available at Groklaw.

						- Ted


From wobblygong at gmail.com  Sat Mar 31 11:53:10 2018
From: wobblygong at gmail.com (Wesley Parish)
Date: Sat, 31 Mar 2018 14:53:10 +1300
Subject: [TUHS] Novell, not SCO, found to own "Unix"
In-Reply-To: <20180331003430.GH9300@thunk.org>
References: <alpine.BSF.2.21.1803300721250.3361@aneurin.horsfall.org>
 <CAJfiPzx+0A9oQrhwfKiwH4f-Fea9e0URe=wihJAvBOxiuitWiA@mail.gmail.com>
 <20180331003430.GH9300@thunk.org>
Message-ID: <CACNPpeYzb9NEY2C_icaZd9v8TE5N=Wo0+boQcC+vOduCvQKoCQ@mail.gmail.com>

Also one of the bigger mistakes the anti-Linux groups made. Among
other things it brought a whole lot of Unix history into the light.
And that was a Good Thing (TM).

I doubt IBM ever did anything more than send an occasional hint
Pamela's way. She did not seem the sort to follow a boss's orders that
way. I did start to worry she'd bought into the Google "Do no evil"
hype at the end, but then she folded it up and stopped posting
articles, so that's moot.

(For what it's worth, I can give an example of her depth of experience
in the software development process: I found in a relatively ancient
MS Windows 3.1 CDROM archive a small Microsoft Windows text editor
project, with a README stating it was in the public domain. It had
obviously been released to help nervous software developers kickstart
their own projects by offering a free windowing framework and text
editing source code. I email her and told her about it, and she
replied it would not be a good idea to let Microsoft know about it or
they would lock it up again. She was a legal assistant, and understood
well tracking cases through the courts, not the software development
process.)

Wesley Parish

On 3/31/18, Theodore Y. Ts'o <tytso at mit.edu> wrote:
> On Fri, Mar 30, 2018 at 07:22:57PM -0400, Nemo wrote:
>> > As an aside, this was the first and only time that I was on IBM's side,
>> > and I still wonder whether M$ was bankrolling SCO in an effort to wipe
>> > Linux off the map; what sort of an idiot would take on IBM?
>>
>> Methinks a mention of the wonderful record at Groklaw
>> (http://www.groklaw.net) is in order.
>
> The idiots were at SCO.  In terms of Microsoft, if that theory is
> true, it makes sense if you think in a fairly amoral way ("fiduciary
> responsibility to shareholders excuses all business tactics" aka the
> sociopathic theory of corporations) and consider it a fairly cheap PR
> campaign to spread FUD about Linux.  So it you could actually consider
> it a fairly cunning tactics; it was probably cheaper than, say, the
> national TV advertising spots IBM had been running to support Linux.
>
> Of course, whether SCO was actually colluding with Microsoft, or just
> a "useful idiot" that was manipulated into taking on IBM, who knows?
> And short of having a special prosecutor look into it, I doubt we'll
> ever know for sure.
>
> Speaking of PR exercises, there were rumors that Pamela at Groklaw was
> secretly being funded by IBM as a counter PR campaign.  Even as an IBM
> employee, I never saw any hard evidence of this, and everything Pamela
> posted was backed by hard legal analysis and the actual court filings,
> but I know people who were quite familiar with the players (including
> those who knew, or at least claimed, that Pamela lived in Westchester
> County in upstate NY) who were quite certain of this theory.
> Certainly if it were not true, the person or people running Groklaw
> must have donated huge amounts of their free time to keep the site
> running and post the very rich amount of content available at Groklaw.
>
> 						- Ted
>


