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: 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: References: Message-ID: 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: Message-ID: >> 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: References: Message-ID: 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 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 > 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: 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: References: Message-ID: 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: References: 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: References: 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" : > 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: 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: On Sun, Mar 4, 2018 at 3:23 PM, Doug McIlroy 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: 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: References: Message-ID: On 3/4/18, Dave Horsfall 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: References: <201803042023.w24KN0Kt013712@coolidge.cs.Dartmouth.EDU> Message-ID: <645D5FCC-7AAB-43D0-8035-FABB23986EAA@bitblocks.com> > On Mar 4, 2018, at 12:42 PM, Clem Cole wrote: > > >> On Sun, Mar 4, 2018 at 3:23 PM, Doug McIlroy 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: 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> <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 > wrote: > >> >> On Sun, Mar 4, 2018 at 3:23 PM, Doug McIlroy > > 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: References: Message-ID: 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> <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: References: Message-ID: On Sun, Mar 4, 2018 at 4:47 PM, Dave Horsfall 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: 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> <645D5FCC-7AAB-43D0-8035-FABB23986EAA@bitblocks.com> <20180304215023.883981F96E@orac.inputplus.co.uk> Message-ID: > On Mar 4, 2018, at 1:50 PM, Ralph Corderoy 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: References: Message-ID: On Mar 4, 2018 5:23 PM, "Clem Cole" 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: 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: On Sun, Mar 4, 2018 at 6:55 PM, Doug McIlroy 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: 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: 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: 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 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: 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: References: <20180306181127.2B21718C0D8@mercury.lcs.mit.edu> Message-ID: On 3/6/18, Clem Cole 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: References: <20180306181127.2B21718C0D8@mercury.lcs.mit.edu> 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: References: <20180306181127.2B21718C0D8@mercury.lcs.mit.edu> Message-ID: On 3/6/18, Clem Cole 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: >Date: Wed, 7 Mar 2018 13:54:32 -0500 >From: Paul Winalski >To: Clem Cole >Cc: The Eunuchs Hysterical Society >Subject: Re: [TUHS] Sleep()y musings >Message-ID: > 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: An HTML attachment was scrubbed... URL: 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: 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: References: 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: References: Message-ID: 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: References: Message-ID: https://trisquel.info/ On Wed, Mar 7, 2018 at 10:42 PM, iPwn iPwn 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: 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: <20180308044832.GA10361@minnie.tuhs.org> Message-ID: 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: References: <20180308044832.GA10361@minnie.tuhs.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: 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: <20180308044832.GA10361@minnie.tuhs.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: References: <20180308044832.GA10361@minnie.tuhs.org> Message-ID: On 08/03/2018, Steve Nickolas 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: 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 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: 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: 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: References: Message-ID: 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: References: Message-ID: 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 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: 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: References: Message-ID: 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 . > > 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: 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: References: 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: <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: <20180314222309.GO16269@h-174-65.A328.priv.bahnhof.se> <13236cac-eb96-7527-0eca-9ed1bb998dfb@kilonet.net> Message-ID: 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: 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: References: <20180314222309.GO16269@h-174-65.A328.priv.bahnhof.se> <13236cac-eb96-7527-0eca-9ed1bb998dfb@kilonet.net> 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: References: Message-ID: 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 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 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: 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: References: Message-ID: 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 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 > 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 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: References: Message-ID: 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 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 > 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 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: 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: 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: 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: References: 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: 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: References: <001d01d3bc73$3bcf5220$b36df660$@ronnatalie.com> 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: <001d01d3bc73$3bcf5220$b36df660$@ronnatalie.com> Message-ID: 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: References: Message-ID: On Thu, Mar 15, 2018 at 11:29 AM, Dan Cross 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: 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: References: Message-ID: On Thu, Mar 15, 2018 at 11:51 AM, Clem Cole 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: 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: References: 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: 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: References: Message-ID: (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: <20180314222309.GO16269@h-174-65.A328.priv.bahnhof.se> Message-ID: Michael Kjörling 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 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: References: Message-ID: Pete Wright 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 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: References: <001d01d3bc73$3bcf5220$b36df660$@ronnatalie.com> Message-ID: 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: References: <001d01d3bc73$3bcf5220$b36df660$@ronnatalie.com> Message-ID: On Thu, Mar 15, 2018 at 2:20 PM, Dave Horsfall 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: 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: 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: References: <20180314222309.GO16269@h-174-65.A328.priv.bahnhof.se> Message-ID: 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 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: References: <20180314222309.GO16269@h-174-65.A328.priv.bahnhof.se> Message-ID: Dave Horsfall 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 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: References: <20180314222309.GO16269@h-174-65.A328.priv.bahnhof.se> 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 wrote: > > Dave Horsfall 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 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: References: <20180314222309.GO16269@h-174-65.A328.priv.bahnhof.se> Message-ID: On Thu, Mar 15, 2018 at 5:04 PM, Dave Horsfall 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: 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: 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: References: <20180314222309.GO16269@h-174-65.A328.priv.bahnhof.se> Message-ID: 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: References: Message-ID: On Fri, Mar 16, 2018 at 2:52 PM, Dave Horsfall 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: References: Message-ID: 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: References: Message-ID: 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: References: Message-ID: 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: References: 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: 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: References: Message-ID: On 16/03/2018, Dave Horsfall 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: References: Message-ID: On Mar 16, 2018, at 2:52 PM, Dave Horsfall 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: References: Message-ID: On Fri, Mar 16, 2018 at 5:52 PM, Dave Horsfall 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: 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: References: Message-ID: <7A56D946-3D0D-4ED3-81CD-68EB9FD97CF0@mcjones.org> Dave Horsfall 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: 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: <7A56D946-3D0D-4ED3-81CD-68EB9FD97CF0@mcjones.org> Message-ID: 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: References: Message-ID: On 3/17/2018 8:54 AM, Dave Horsfall 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: 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: References: Message-ID: 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 wrote: > > > >> On Fri, Mar 16, 2018 at 5:52 PM, Dave Horsfall 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: 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: References: 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: References: 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: References: Message-ID: <46927130-75DF-4B8A-8B46-C6CF23539B2C@tfeb.org> On 17 Mar 2018, at 13:43, Clem Cole 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: 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: References: Message-ID: 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: <20180317191501.GA4137@vagabond> Message-ID: On Sat, Mar 17, 2018 at 12:15 PM, Pierre DAVID 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: 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: References: Message-ID: <1d3a154d-c80d-2bb5-dce1-e027b4cfaa59@mcjones.org> On 3/17/2018 12:22 PM, Steve Simon 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: 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: References: Message-ID: <4943fffb-dee6-fb51-1ca2-8d4b17fa7a2f@mcjones.org> On 3/17/2018 12:22 PM, Arthur Krewat 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: 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: <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: 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: <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: 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: <20180317191501.GA4137@vagabond> Message-ID: 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 > 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: References: Message-ID: On 3/16/18, Dave Horsfall 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: References: Message-ID: On Sun, Mar 18, 2018 at 2:51 PM, Paul Winalski wrote: > On 3/16/18, Dave Horsfall 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: 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: References: Message-ID: On 18 Mar 2018, at 18:51, Paul Winalski 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: 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: 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: 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: <52c5a2e1a53e5a0d88246bf29e52acf696e9c85a@webmail.yaccman.com> Message-ID: On Sun, Mar 18, 2018 at 6:26 PM, Steve Johnson 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: 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: References: Message-ID: On Sun, Mar 18, 2018 at 5:07 PM, Clem Cole 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: 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: References: Message-ID: On Mon, Mar 19, 2018 at 10:50 AM, Dan Cross 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: 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: References: Message-ID: 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 wrote: > > > On Mon, Mar 19, 2018 at 10:50 AM, Dan Cross 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: 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: References: Message-ID: On Mon, Mar 19, 2018 at 10:50 AM, Dan Cross 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: 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: 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: 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: 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: References: Message-ID: On 3/19/18, Clem Cole 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: References: Message-ID: 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: References: Message-ID: 6th edition had 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 wrote: > On 3/19/18, Clem Cole 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: 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: References: 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: References: Message-ID: 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: <6bc3b4da-08df-1a59-30b9-75d95541fdca@gmail.com> Message-ID: Jon Forrest 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: 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: <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: References: <6bc3b4da-08df-1a59-30b9-75d95541fdca@gmail.com> Message-ID: 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: 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: 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: References: Message-ID: 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: References: Message-ID: <878tanplgf.fsf@terra.i-did-not-set--mail-host-address--so-tickle-me> "A. P. Garcia" 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: References: 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: 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: <94366db0-293b-214a-23a3-c7c895e4d30b@spamtrap.tnetconsulting.net> Message-ID: 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: References: <94366db0-293b-214a-23a3-c7c895e4d30b@spamtrap.tnetconsulting.net> 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: 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: <94366db0-293b-214a-23a3-c7c895e4d30b@spamtrap.tnetconsulting.net> <98451f10-9b1b-049b-61ed-fd73586572fd@spamtrap.tnetconsulting.net> Message-ID: On Mar 19, 2018 11:40 PM, "Grant Taylor via TUHS" 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: 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: <94366db0-293b-214a-23a3-c7c895e4d30b@spamtrap.tnetconsulting.net> Message-ID: On Monday, March 19, 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 actually always liked the term 'dragons'. This I believe came from MIT. --Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: 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: <94366db0-293b-214a-23a3-c7c895e4d30b@spamtrap.tnetconsulting.net> Message-ID: On 20/03/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. 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: References: <61051ebbca4809c08b60e92014851069e83a07f8@webmail.yaccman.com> Message-ID: 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: References: <61051ebbca4809c08b60e92014851069e83a07f8@webmail.yaccman.com> Message-ID: 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 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: References: Message-ID: On 3/19/18, A. P. Garcia 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: References: Message-ID: 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 wrote: > On 3/19/18, A. P. Garcia 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: References: Message-ID: On Tue, Mar 20, 2018 at 1:56 PM, George Michaelson 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: 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: <61051ebbca4809c08b60e92014851069e83a07f8@webmail.yaccman.com> Message-ID: On Mon, Mar 19, 2018 at 12:58 PM, Steve Johnson 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: 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." References: Message-ID: <20180320182445.5BBA8156E510@mail.bitblocks.com> On Tue, 20 Mar 2018 14:04:38 -0400 Dan Cross wrote: Dan Cross writes: > > On Tue, Mar 20, 2018 at 1:56 PM, George Michaelson 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: <20180320182445.5BBA8156E510@mail.bitblocks.com> Message-ID: On Tue, Mar 20, 2018 at 2:24 PM, Bakul Shah wrote: > On Tue, 20 Mar 2018 14:04:38 -0400 Dan Cross wrote: > Dan Cross writes: > > > > On Tue, Mar 20, 2018 at 1:56 PM, George Michaelson > 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: 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: <20180320182445.5BBA8156E510@mail.bitblocks.com> Message-ID: On 2018-03-20 2:24 PM, Bakul Shah wrote: > On Tue, 20 Mar 2018 14:04:38 -0400 Dan Cross wrote: > Dan Cross writes: >> >> On Tue, Mar 20, 2018 at 1:56 PM, George Michaelson 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: References: <20180320182445.5BBA8156E510@mail.bitblocks.com> Message-ID: On Mar 20, 2018, at 11:46 AM, Clem Cole wrote: > > On Tue, Mar 20, 2018 at 2:24 PM, Bakul Shah wrote: > On Tue, 20 Mar 2018 14:04:38 -0400 Dan Cross wrote: > Dan Cross writes: > > > > On Tue, Mar 20, 2018 at 1:56 PM, George Michaelson 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: References: 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 > 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: References: <61051ebbca4809c08b60e92014851069e83a07f8@webmail.yaccman.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: 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: References: <20180320182445.5BBA8156E510@mail.bitblocks.com> Message-ID: On Tue, Mar 20, 2018 at 3:10 PM, Bakul Shah wrote: > On Mar 20, 2018, at 11:46 AM, Clem Cole wrote: > > > > On Tue, Mar 20, 2018 at 2:24 PM, Bakul Shah wrote: > > On Tue, 20 Mar 2018 14:04:38 -0400 Dan Cross wrote: > > Dan Cross writes: > > > > > > On Tue, Mar 20, 2018 at 1:56 PM, George Michaelson > 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: 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: References: <20180320182445.5BBA8156E510@mail.bitblocks.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 wrote: > > > >> On Tue, Mar 20, 2018 at 2:24 PM, Bakul Shah wrote: >> On Tue, 20 Mar 2018 14:04:38 -0400 Dan Cross wrote: >> Dan Cross writes: >> > >> > On Tue, Mar 20, 2018 at 1:56 PM, George Michaelson 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: 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: References: <20180320182445.5BBA8156E510@mail.bitblocks.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: <61051ebbca4809c08b60e92014851069e83a07f8@webmail.yaccman.com> <002f01d3c085$6b5a26d0$420e7470$@ronnatalie.com> Message-ID: On 3/20/18, Ron Natalie 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: <20180320182445.5BBA8156E510@mail.bitblocks.com> <20180320201441.GA28553@minnie.tuhs.org> Message-ID: 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: References: <61051ebbca4809c08b60e92014851069e83a07f8@webmail.yaccman.com> <002f01d3c085$6b5a26d0$420e7470$@ronnatalie.com> Message-ID: On Tue, Mar 20, 2018 at 2:21 PM, Paul Winalski wrote: > On 3/20/18, Ron Natalie 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: 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: <20180320182445.5BBA8156E510@mail.bitblocks.com> <20180320201441.GA28553@minnie.tuhs.org> Message-ID: On Tue, Mar 20, 2018 at 4:14 PM, Warren Toomey 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: 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: <20180320182445.5BBA8156E510@mail.bitblocks.com> <4B8624EE-EB25-4029-8C35-8F8266107D2C@tfeb.org> Message-ID: On Mar 20, 2018 2:58 PM, "Tim Bradshaw" 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: 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: References: <20180320182445.5BBA8156E510@mail.bitblocks.com> <20180320201441.GA28553@minnie.tuhs.org> Message-ID: On Tue, Mar 20, 2018 at 4:25 PM, Paul Winalski 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: 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: 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 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: <61051ebbca4809c08b60e92014851069e83a07f8@webmail.yaccman.com> <002f01d3c085$6b5a26d0$420e7470$@ronnatalie.com> Message-ID: On Tue, Mar 20, 2018 at 3:55 PM, Ron Natalie 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: 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: References: <20180320182445.5BBA8156E510@mail.bitblocks.com> <4B8624EE-EB25-4029-8C35-8F8266107D2C@tfeb.org> Message-ID: On Tuesday, March 20, 2018, A. P. Garcia wrote: > > > On Mar 20, 2018 2:58 PM, "Tim Bradshaw" 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: 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: References: <61051ebbca4809c08b60e92014851069e83a07f8@webmail.yaccman.com> <002f01d3c085$6b5a26d0$420e7470$@ronnatalie.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: 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: 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: References: <61051ebbca4809c08b60e92014851069e83a07f8@webmail.yaccman.com> <002f01d3c085$6b5a26d0$420e7470$@ronnatalie.com> Message-ID: <8E0EC81A-D1EB-4070-AAD5-FBFF3139975E@bitblocks.com> On Mar 20, 2018, at 2:36 PM, Clem Cole 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: References: Message-ID: 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: References: 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: <94366db0-293b-214a-23a3-c7c895e4d30b@spamtrap.tnetconsulting.net> <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: <94366db0-293b-214a-23a3-c7c895e4d30b@spamtrap.tnetconsulting.net> <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: <94366db0-293b-214a-23a3-c7c895e4d30b@spamtrap.tnetconsulting.net> <98451f10-9b1b-049b-61ed-fd73586572fd@spamtrap.tnetconsulting.net> <20180321023125.GC6850@thunk.org> Message-ID: On Tue, Mar 20, 2018 at 8:31 PM, 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. > 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: 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: <94366db0-293b-214a-23a3-c7c895e4d30b@spamtrap.tnetconsulting.net> <98451f10-9b1b-049b-61ed-fd73586572fd@spamtrap.tnetconsulting.net> <20180321023125.GC6850@thunk.org> Message-ID: 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 differently than it was done in . 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: 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: <20180320182445.5BBA8156E510@mail.bitblocks.com> <4B8624EE-EB25-4029-8C35-8F8266107D2C@tfeb.org> Message-ID: 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 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 wrote: >> >> >> >>> On Tue, Mar 20, 2018 at 2:24 PM, Bakul Shah wrote: >>> On Tue, 20 Mar 2018 14:04:38 -0400 Dan Cross wrote: >>> Dan Cross writes: >>> > >>> > On Tue, Mar 20, 2018 at 1:56 PM, George Michaelson >>> > 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: 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: 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: References: <61051ebbca4809c08b60e92014851069e83a07f8@webmail.yaccman.com> <002f01d3c085$6b5a26d0$420e7470$@ronnatalie.com> Message-ID: <20180321081042.GA7611@server.rulingia.com> On 2018-Mar-20 16:21:12 -0400, Paul Winalski 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: 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: <94366db0-293b-214a-23a3-c7c895e4d30b@spamtrap.tnetconsulting.net> <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 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 267 bytes Desc: Message signed with OpenPGP URL: 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: References: Message-ID: 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: References: <61051ebbca4809c08b60e92014851069e83a07f8@webmail.yaccman.com> <002f01d3c085$6b5a26d0$420e7470$@ronnatalie.com> Message-ID: On 3/20/18, Clem Cole 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: <94366db0-293b-214a-23a3-c7c895e4d30b@spamtrap.tnetconsulting.net> <98451f10-9b1b-049b-61ed-fd73586572fd@spamtrap.tnetconsulting.net> <20180321023125.GC6850@thunk.org> Message-ID: On Tue, Mar 20, 2018 at 10:31 PM, 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. ​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: 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 > 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: References: <94366db0-293b-214a-23a3-c7c895e4d30b@spamtrap.tnetconsulting.net> <98451f10-9b1b-049b-61ed-fd73586572fd@spamtrap.tnetconsulting.net> <20180321023125.GC6850@thunk.org> Message-ID: On Tue, Mar 20, 2018 at 10:31 PM, 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. > 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: On Wed, Mar 21, 2018 at 10:17 AM, Noel Chiappa wrote: > > From: Larry McVoy > > > 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: 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: References: <94366db0-293b-214a-23a3-c7c895e4d30b@spamtrap.tnetconsulting.net> <98451f10-9b1b-049b-61ed-fd73586572fd@spamtrap.tnetconsulting.net> <20180321023125.GC6850@thunk.org> Message-ID: On Wed, Mar 21, 2018 at 8:18 AM, Paul Winalski wrote: > On Tue, Mar 20, 2018 at 10:31 PM, 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. > > > 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: 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: References: <94366db0-293b-214a-23a3-c7c895e4d30b@spamtrap.tnetconsulting.net> <98451f10-9b1b-049b-61ed-fd73586572fd@spamtrap.tnetconsulting.net> <20180321023125.GC6850@thunk.org> Message-ID: On Wednesday, March 21, 2018, Warner Losh wrote: > > > On Wed, Mar 21, 2018 at 8:18 AM, Paul Winalski > wrote: > >> On Tue, Mar 20, 2018 at 10:31 PM, 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. >> > >> 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: 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: References: <94366db0-293b-214a-23a3-c7c895e4d30b@spamtrap.tnetconsulting.net> <98451f10-9b1b-049b-61ed-fd73586572fd@spamtrap.tnetconsulting.net> <20180321023125.GC6850@thunk.org> Message-ID: On Wed, Mar 21, 2018 at 9:45 AM, Andy Kosela wrote: > > > On Wednesday, March 21, 2018, Warner Losh wrote: > >> >> >> On Wed, Mar 21, 2018 at 8:18 AM, Paul Winalski >> wrote: >> >>> On Tue, Mar 20, 2018 at 10:31 PM, 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. >>> > >>> 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: 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: References: <20180321141753.25C4418C088@mercury.lcs.mit.edu> 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: 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> <6c6699c0-15db-604a-181c-7dad282599e1@kilonet.net> Message-ID: On 3/21/18, Arthur Krewat 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: References: <20180321141753.25C4418C088@mercury.lcs.mit.edu> <6c6699c0-15db-604a-181c-7dad282599e1@kilonet.net> Message-ID: 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 wrote: > On 3/21/18, Arthur Krewat 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: References: <20180321141753.25C4418C088@mercury.lcs.mit.edu> <6c6699c0-15db-604a-181c-7dad282599e1@kilonet.net> 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 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: References: <20180321141753.25C4418C088@mercury.lcs.mit.edu> <6c6699c0-15db-604a-181c-7dad282599e1@kilonet.net> Message-ID: <6DD0967F-D864-432B-A669-A2C51E03050D@cheswick.com> > On Mar 21, 2018, at 1:28 PM, Paul Winalski 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: 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: References: <20180321141753.25C4418C088@mercury.lcs.mit.edu> <6c6699c0-15db-604a-181c-7dad282599e1@kilonet.net> 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> <6c6699c0-15db-604a-181c-7dad282599e1@kilonet.net> <6DD0967F-D864-432B-A669-A2C51E03050D@cheswick.com> Message-ID: 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: References: <20180321141753.25C4418C088@mercury.lcs.mit.edu> <6c6699c0-15db-604a-181c-7dad282599e1@kilonet.net> Message-ID: On 21 March 2018 at 13:28, Paul Winalski 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: References: <20180321141753.25C4418C088@mercury.lcs.mit.edu> <6c6699c0-15db-604a-181c-7dad282599e1@kilonet.net> 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 > 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: References: <20180321141753.25C4418C088@mercury.lcs.mit.edu> <6c6699c0-15db-604a-181c-7dad282599e1@kilonet.net> Message-ID: On Wed, Mar 21, 2018 at 1:28 PM, Paul Winalski wrote: > On 3/21/18, Arthur Krewat 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: 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: References: <20180321141753.25C4418C088@mercury.lcs.mit.edu> <6c6699c0-15db-604a-181c-7dad282599e1@kilonet.net> Message-ID: On 3/21/18, George Michaelson 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> <6c6699c0-15db-604a-181c-7dad282599e1@kilonet.net> <5315f6af-c541-e2d5-588a-d5b7f95b479d@kilonet.net> Message-ID: On Mar 21, 2018 12:51 PM, "Arthur Krewat" 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: 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: References: <20180321141753.25C4418C088@mercury.lcs.mit.edu> <6c6699c0-15db-604a-181c-7dad282599e1@kilonet.net> Message-ID: On Wed, Mar 21, 2018 at 2:04 PM, Dan Cross 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: 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: References: <20180321141753.25C4418C088@mercury.lcs.mit.edu> <6c6699c0-15db-604a-181c-7dad282599e1@kilonet.net> 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: 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: References: <20180321141753.25C4418C088@mercury.lcs.mit.edu> <6c6699c0-15db-604a-181c-7dad282599e1@kilonet.net> Message-ID: 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> <6c6699c0-15db-604a-181c-7dad282599e1@kilonet.net> <13FBBB55-93FA-49CF-9FEF-4F66A3611524@gmail.com> Message-ID: 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: References: <20180321141753.25C4418C088@mercury.lcs.mit.edu> <6c6699c0-15db-604a-181c-7dad282599e1@kilonet.net> 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> <6c6699c0-15db-604a-181c-7dad282599e1@kilonet.net> <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: References: <20180321141753.25C4418C088@mercury.lcs.mit.edu> <6c6699c0-15db-604a-181c-7dad282599e1@kilonet.net> <13FBBB55-93FA-49CF-9FEF-4F66A3611524@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: References: <61051ebbca4809c08b60e92014851069e83a07f8@webmail.yaccman.com> <002f01d3c085$6b5a26d0$420e7470$@ronnatalie.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: <61051ebbca4809c08b60e92014851069e83a07f8@webmail.yaccman.com> <002f01d3c085$6b5a26d0$420e7470$@ronnatalie.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> <61051ebbca4809c08b60e92014851069e83a07f8@webmail.yaccman.com> <002f01d3c085$6b5a26d0$420e7470$@ronnatalie.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: 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: On Wed, Mar 21, 2018 at 7:51 AM, Noel Chiappa 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: 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: References: Message-ID: 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 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> <6c6699c0-15db-604a-181c-7dad282599e1@kilonet.net> <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 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: 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> <6c6699c0-15db-604a-181c-7dad282599e1@kilonet.net> <20180321202810.GA6280@minnie.tuhs.org> <4ED5DE5D-B2FC-4018-B4A8-2639CDB2073E@jctaylor.com> Message-ID: On Wed, Mar 21, 2018 at 6:18 PM, William Corcoran 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: 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: References: Message-ID: On 2018-03-21 14:48, Paul Winalski wrote: > > On 3/20/18, Clem Cole 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> <6c6699c0-15db-604a-181c-7dad282599e1@kilonet.net> <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> <6c6699c0-15db-604a-181c-7dad282599e1@kilonet.net> <20180321202810.GA6280@minnie.tuhs.org> Message-ID: On Wed, Mar 21, 2018 at 2:28 PM, Warren Toomey 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: 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> <6c6699c0-15db-604a-181c-7dad282599e1@kilonet.net> <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: <94366db0-293b-214a-23a3-c7c895e4d30b@spamtrap.tnetconsulting.net> <98451f10-9b1b-049b-61ed-fd73586572fd@spamtrap.tnetconsulting.net> <20180321023125.GC6850@thunk.org> <76E7D09E-023B-4A29-ACCD-AF9ED425EE5F@xs4all.nl> Message-ID: 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: 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: References: <94366db0-293b-214a-23a3-c7c895e4d30b@spamtrap.tnetconsulting.net> <98451f10-9b1b-049b-61ed-fd73586572fd@spamtrap.tnetconsulting.net> <20180321023125.GC6850@thunk.org> <76E7D09E-023B-4A29-ACCD-AF9ED425EE5F@xs4all.nl> 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: References: <94366db0-293b-214a-23a3-c7c895e4d30b@spamtrap.tnetconsulting.net> <98451f10-9b1b-049b-61ed-fd73586572fd@spamtrap.tnetconsulting.net> <20180321023125.GC6850@thunk.org> Message-ID: 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: 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: References: Message-ID: On Wednesday, March 21, 2018, Jeremy C. Reed 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: 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: 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: 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> <6c6699c0-15db-604a-181c-7dad282599e1@kilonet.net> <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: 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> <6c6699c0-15db-604a-181c-7dad282599e1@kilonet.net> <20180321202810.GA6280@minnie.tuhs.org> Message-ID: On Wednesday, March 21, 2018, Warren Toomey 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: 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: References: <6c6699c0-15db-604a-181c-7dad282599e1@kilonet.net> <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: <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: References: Message-ID: 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: References: Message-ID: On Wed, Mar 21, 2018 at 17:30 Andy Kosela wrote: > > > On Wednesday, March 21, 2018, Jeremy C. Reed 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: 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: References: <20180321141753.25C4418C088@mercury.lcs.mit.edu> <6c6699c0-15db-604a-181c-7dad282599e1@kilonet.net> <20180321202810.GA6280@minnie.tuhs.org> 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: References: <20180321141753.25C4418C088@mercury.lcs.mit.edu> <6c6699c0-15db-604a-181c-7dad282599e1@kilonet.net> <20180321202810.GA6280@minnie.tuhs.org> <4ED5DE5D-B2FC-4018-B4A8-2639CDB2073E@jctaylor.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 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 > 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 > "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: References: 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> <6c6699c0-15db-604a-181c-7dad282599e1@kilonet.net> <20180321202810.GA6280@minnie.tuhs.org> <20180322012720.GN9739@mcvoy.com> Message-ID: <1CF996A2-CEA3-4EC3-835D-9518729D2E36@bitblocks.com> On Mar 21, 2018, at 6:27 PM, Larry McVoy 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: 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> <6c6699c0-15db-604a-181c-7dad282599e1@kilonet.net> <20180321173403.GD9739@mcvoy.com> Message-ID: 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: <94366db0-293b-214a-23a3-c7c895e4d30b@spamtrap.tnetconsulting.net> <98451f10-9b1b-049b-61ed-fd73586572fd@spamtrap.tnetconsulting.net> <20180321023125.GC6850@thunk.org> <76E7D09E-023B-4A29-ACCD-AF9ED425EE5F@xs4all.nl> <20180322002246.GK9739@mcvoy.com> Message-ID: 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: On 22/03/2018, Doug McIlroy 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> <6c6699c0-15db-604a-181c-7dad282599e1@kilonet.net> <20180321202810.GA6280@minnie.tuhs.org> <20180322012720.GN9739@mcvoy.com> Message-ID: > On 22 Mar 2018, at 01:27, Larry McVoy 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: References: <20180321141753.25C4418C088@mercury.lcs.mit.edu> <6c6699c0-15db-604a-181c-7dad282599e1@kilonet.net> <20180321202810.GA6280@minnie.tuhs.org> <20180322012720.GN9739@mcvoy.com> Message-ID: 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 wrote: > > > > On 22 Mar 2018, at 01:27, Larry McVoy 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: 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: References: <20180321141753.25C4418C088@mercury.lcs.mit.edu> <6c6699c0-15db-604a-181c-7dad282599e1@kilonet.net> <20180321202810.GA6280@minnie.tuhs.org> <20180322012720.GN9739@mcvoy.com> 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 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 . 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> <6c6699c0-15db-604a-181c-7dad282599e1@kilonet.net> <20180321202810.GA6280@minnie.tuhs.org> <20180322012720.GN9739@mcvoy.com> <01d401d3c1f9$ebd18270$c3748750$@ronnatalie.com> Message-ID: <201803221632.w2MGWSTC016570@freefriends.org> "Ron Natalie" 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> <20180321202810.GA6280@minnie.tuhs.org> <20180322012720.GN9739@mcvoy.com> <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: On 2018-03-22 12:30 PM, arnold at skeeve.com wrote: > Doug McIlroy 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 . 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: On Wed, Mar 21, 2018 at 7:50 PM, Larry McVoy 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 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 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: 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 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 . > > 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: References: Message-ID: On Thu, Mar 22, 2018 at 1:10 PM, Clem Cole wrote: > On Wed, Mar 21, 2018 at 7:50 PM, Larry McVoy 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 > 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: 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: References: Message-ID: > From: Dave Horsfall > 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> <6c6699c0-15db-604a-181c-7dad282599e1@kilonet.net> <20180321202810.GA6280@minnie.tuhs.org> <20180322012720.GN9739@mcvoy.com> <01d401d3c1f9$ebd18270$c3748750$@ronnatalie.com> <201803221632.w2MGWSTC016570@freefriends.org> Message-ID: > 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: On Mar 17, 2018, at 3:27 PM, Steve Johnson 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: References: <284abf07f5b9d442caf233a8017a8cebb5518bbc@webmail.yaccman.com> Message-ID: On Thu, Mar 22, 2018 at 5:05 PM, Bakul Shah 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: 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> <6c6699c0-15db-604a-181c-7dad282599e1@kilonet.net> <20180321202810.GA6280@minnie.tuhs.org> <20180322012720.GN9739@mcvoy.com> Message-ID: On Wed, Mar 21, 2018 at 6:27 PM, Larry McVoy 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: 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: References: <284abf07f5b9d442caf233a8017a8cebb5518bbc@webmail.yaccman.com> Message-ID: <92ACA4B4-31AC-4202-95DD-14E30C5D164C@tfeb.org> On 22 Mar 2018, at 21:05, Bakul Shah 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: 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: 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: On Fri, Mar 23, 2018 at 11:51 AM, Ron Natalie 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: 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: References: <02ab01d3c2be$cf335920$6d9a0b60$@ronnatalie.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: (Clem Cole's message of "Fri, 23 Mar 2018 11:57:36 -0400") References: <02ab01d3c2be$cf335920$6d9a0b60$@ronnatalie.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> <7wfu4qrc6w.fsf@junk.nocrew.org> Message-ID: 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 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: References: <02ab01d3c2be$cf335920$6d9a0b60$@ronnatalie.com> <7wfu4qrc6w.fsf@junk.nocrew.org> Message-ID: 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 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: References: <284abf07f5b9d442caf233a8017a8cebb5518bbc@webmail.yaccman.com> Message-ID: On Mar 22, 2018, at 2:35 PM, Clem Cole 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 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 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: References: <284abf07f5b9d442caf233a8017a8cebb5518bbc@webmail.yaccman.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 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 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 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: 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: 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: References: <5DAB3926-947C-4DC1-8C9D-04ADB40FB007@bitblocks.com> Message-ID: On Fri, Mar 23, 2018 at 4:50 PM, Steve Johnson 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: 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: References: <284abf07f5b9d442caf233a8017a8cebb5518bbc@webmail.yaccman.com> Message-ID: On Fri, Mar 23, 2018 at 3:28 PM, Bakul Shah 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: 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: References: <284abf07f5b9d442caf233a8017a8cebb5518bbc@webmail.yaccman.com> Message-ID: On Fri, Mar 23, 2018 at 3:23 PM, Clem Cole 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: 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: 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" To: "Clem Cole" Cc: "TUHS main list" 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 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: 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: References: 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: <660e1afc-05c6-6192-2168-23302df0b1ed@e-bbes.com> Message-ID: 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 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: References: <660e1afc-05c6-6192-2168-23302df0b1ed@e-bbes.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 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: References: <284abf07f5b9d442caf233a8017a8cebb5518bbc@webmail.yaccman.com> Message-ID: On 23 Mar 2018, at 19:28, Bakul Shah 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: 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: References: <284abf07f5b9d442caf233a8017a8cebb5518bbc@webmail.yaccman.com> Message-ID: On 3/26/18, Tim Bradshaw wrote: > On 23 Mar 2018, at 19:28, Bakul Shah 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: References: <284abf07f5b9d442caf233a8017a8cebb5518bbc@webmail.yaccman.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: References: <284abf07f5b9d442caf233a8017a8cebb5518bbc@webmail.yaccman.com> Message-ID: <4A5BA823-F928-4711-8CAA-F790F78070C1@bitblocks.com> > On Mar 26, 2018, at 6:43 AM, Tim Bradshaw wrote: > > On 23 Mar 2018, at 19:28, Bakul Shah 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> <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: References: <284abf07f5b9d442caf233a8017a8cebb5518bbc@webmail.yaccman.com> <92ACA4B4-31AC-4202-95DD-14E30C5D164C@tfeb.org> Message-ID: [try-II] On Fri, Mar 23, 2018 at 6:43 AM, Tim Bradshaw wrote: > On 22 Mar 2018, at 21:05, Bakul Shah 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: HPC_CloudBubble_nomarks20180323.png Type: image/png Size: 444678 bytes Desc: not available URL: 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: References: <284abf07f5b9d442caf233a8017a8cebb5518bbc@webmail.yaccman.com> Message-ID: On Mon, Mar 26, 2018 at 12:19 PM, Paul Winalski 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: 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: Message-ID: 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" . . . 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: 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: References: Message-ID: On Mon, Mar 26, 2018 at 9:21 PM, Steve Johnson 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: 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: 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: References: Message-ID: On 3/29/18, Dave Horsfall 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: 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: References: Message-ID: On 29 March 2018 at 17:37, 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. > 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: 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: References: Message-ID: On Thu, Mar 29, 2018 at 3:37 PM, 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. > 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: 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: References: Message-ID: 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: References: Message-ID: On Mar 29, 2018 5:12 PM, "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. 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: 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: References: 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: <20180329232409.GH8921@mcvoy.com> Message-ID: 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: 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: References: Message-ID: On Thu, Mar 29, 2018 at 5:37 PM, Paul Winalski 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: 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: References: Message-ID: On Thu, Mar 29, 2018 at 5:19 PM, Paul Winalski 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: 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: References: Message-ID: > 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: References: <20180329232409.GH8921@mcvoy.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: References: Message-ID: <65E0C49A-2115-47F9-89C1-AEAF2633FD98@technologists.com> > On Mar 29, 2018, at 7:40 PM, Clem Cole wrote: > > > > On Thu, Mar 29, 2018 at 5:37 PM, Paul Winalski > 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 fax: +1.512.346.5240 web: http://technologists.com/sauer/ Facebook/Google/Skype/Twitter: CharlesHSauer -------------- next part -------------- An HTML attachment was scrubbed... URL: 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: <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 wrote: > > > > > > > > On Thu, Mar 29, 2018 at 5:37 PM, Paul Winalski > 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: <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 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 wrote: >>> >>> >>> >>> On Thu, Mar 29, 2018 at 5:37 PM, Paul Winalski > 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: 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: References: 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: 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: <65E0C49A-2115-47F9-89C1-AEAF2633FD98@technologists.com> <20180330021016.GK8921@mcvoy.com> <1D00C2FE-B36F-4CC3-8548-6FB677443C39@technologists.com> Message-ID: On Thu, Mar 29, 2018 at 8:34 PM, Charles H. Sauer wrote: > > > On Mar 29, 2018, at 9:10 PM, Larry McVoy 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 wrote: > > > > On Thu, Mar 29, 2018 at 5:37 PM, Paul Winalski 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. > 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: 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: <20180329232409.GH8921@mcvoy.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 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: <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 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: 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: <20180329232409.GH8921@mcvoy.com> <20180330014642.GI8921@mcvoy.com> <048A69EA-7B2C-4D2C-A69B-76CE8E082826@ccc.com> Message-ID: [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: Message-ID: ----- Original Message ----- From: "Clem Cole" To:"Paul Winalski" Cc:"The Eunuchs Hysterical Society" 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: 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: References: <20180329232409.GH8921@mcvoy.com> <20180330014642.GI8921@mcvoy.com> <048A69EA-7B2C-4D2C-A69B-76CE8E082826@ccc.com> Message-ID: On Fri, Mar 30, 2018 at 4:52 PM, Jon Forrest 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: 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: References: Message-ID: On 29/03/2018, Dave Horsfall 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: References: <20180329232409.GH8921@mcvoy.com> <20180330014642.GI8921@mcvoy.com> <048A69EA-7B2C-4D2C-A69B-76CE8E082826@ccc.com> Message-ID: 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: References: 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: <20180331003430.GH9300@thunk.org> Message-ID: 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 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 >