From dave at horsfall.org Sun Apr 1 07:10:16 2018 From: dave at horsfall.org (Dave Horsfall) Date: Sun, 1 Apr 2018 07:10:16 +1000 (EST) Subject: [TUHS] The dollar symbol Message-ID: On this day in 1778 businessman Oliver Pollock created the "$" sign, and now we see it everywhere: shell prompts and variables, macro strings, Perl variables, system references (SYS$BLAH, SWAP$SYS, etc), etc; where would we be without it? -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From mike.ab3ap at gmail.com Sun Apr 1 07:16:58 2018 From: mike.ab3ap at gmail.com (Mike Markowski) Date: Sat, 31 Mar 2018 17:16:58 -0400 Subject: [TUHS] The dollar symbol In-Reply-To: References: Message-ID: <9676094b-1b88-3c65-2df4-c98ba2fbd446@gmail.com> On 03/31/2018 05:10 PM, Dave Horsfall wrote: > On this day in 1778 businessman Oliver Pollock created the "$" sign, and > now we see it everywhere: shell prompts and variables, macro strings, > Perl variables, system references (SYS$BLAH, SWAP$SYS, etc), etc; where > would we be without it? A day late and a dollar short. From mparson at bl.org Sun Apr 1 00:56:51 2018 From: mparson at bl.org (Michael Parson) Date: Sat, 31 Mar 2018 09:56:51 -0500 (CDT) Subject: [TUHS] Novell, not SCO, found to own "Unix" In-Reply-To: References: Message-ID: On Fri, 30 Mar 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? My initial thought, when I saw that SCO had filed the $1B lawsuit, was that maybe Darl McBride was hoping that the next headline people read would be "IBM acquires SCO for $(some amount below $1B)." -- Michael Parson Pflugerville, TX KF5LGQ From dave at horsfall.org Sun Apr 1 10:13:02 2018 From: dave at horsfall.org (Dave Horsfall) Date: Sun, 1 Apr 2018 10:13:02 +1000 (EST) Subject: [TUHS] Novell, not SCO, found to own "Unix" In-Reply-To: References: Message-ID: On Sat, 31 Mar 2018, Michael Parson wrote: > My initial thought, when I saw that SCO had filed the $1B lawsuit, was > that maybe Darl McBride was hoping that the next headline people read > would be "IBM acquires SCO for $(some amount below $1B)." Yeah, that was going around too; remember that SCO was practically broke at the time, and couldn't possibly afford to lose (as if anyone could). -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From rminnich at gmail.com Tue Apr 3 02:11:30 2018 From: rminnich at gmail.com (ron minnich) Date: Mon, 02 Apr 2018 16:11:30 +0000 Subject: [TUHS] dead bstj unix link on wikipedia Message-ID: anyone got a fix? https://en.wikipedia.org/wiki/Bell_System_Technical_Journal see this text 1. Ritchie, D.M.; K. Thompson (July–August 1978). "The UNIX Time-Sharing System" . *Bell System Technical Journal*. *57* (6). Retrieved 2010-10-22 -------------- next part -------------- An HTML attachment was scrubbed... URL: From iamleot at gmail.com Tue Apr 3 02:24:16 2018 From: iamleot at gmail.com (Leonardo Taccari) Date: Mon, 02 Apr 2018 18:24:16 +0200 Subject: [TUHS] dead bstj unix link on wikipedia In-Reply-To: References: Message-ID: <5ac2594c.8f8d1c0a.16bdc.c039@mx.google.com> Hello ron, ron minnich writes: > anyone got a fix? > > https://en.wikipedia.org/wiki/Bell_System_Technical_Journal > > see this text > > > 1. Ritchie, D.M.; K. Thompson (July–August 1978). "The UNIX > Time-Sharing System" > . *Bell > System Technical Journal*. *57* (6). Retrieved 2010-10-22 > archive.org seems to have it: From jnc at mercury.lcs.mit.edu Tue Apr 3 03:34:46 2018 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Mon, 2 Apr 2018 13:34:46 -0400 (EDT) Subject: [TUHS] dead bstj unix link on wikipedia Message-ID: <20180402173446.91C9618C089@mercury.lcs.mit.edu> > From: Ron Minnich > anyone got a fix? Google quickly shows that Dennis' home page is now at: https://www.bell-labs.com/usr/dmr/www/ >From there, the CACM paper (HTML form) is at: https://www.bell-labs.com/usr/dmr/www/cacm.html Noel From 0intro at gmail.com Tue Apr 3 03:36:41 2018 From: 0intro at gmail.com (David du Colombier) Date: Mon, 2 Apr 2018 19:36:41 +0200 Subject: [TUHS] dead bstj unix link on wikipedia In-Reply-To: References: Message-ID: > anyone got a fix? > > https://en.wikipedia.org/wiki/Bell_System_Technical_Journal > > see this text > > Ritchie, D.M.; K. Thompson (July–August 1978). "The UNIX Time-Sharing > System". Bell System Technical Journal. 57 (6). Retrieved 2010-10-22 https://9p.io/cm/cs/who/dmr/cacm.html More generally, just replace "cm.bell-labs.com" with "9p.io". -- David du Colombier From rminnich at gmail.com Tue Apr 3 08:53:29 2018 From: rminnich at gmail.com (ron minnich) Date: Mon, 02 Apr 2018 22:53:29 +0000 Subject: [TUHS] dead bstj unix link on wikipedia In-Reply-To: References: Message-ID: That turned out to be the wrong paper. I'm looking for a paper that describes the (early) dialect of C that let you do stuff like this: struct w { char lo, hi; }; int x; char b = x.lo; I can't find my hardcopy so was looking for a pdf. ron On Mon, Apr 2, 2018 at 10:36 AM David du Colombier <0intro at gmail.com> wrote: > > anyone got a fix? > > > > https://en.wikipedia.org/wiki/Bell_System_Technical_Journal > > > > see this text > > > > Ritchie, D.M.; K. Thompson (July–August 1978). "The UNIX Time-Sharing > > System". Bell System Technical Journal. 57 (6). Retrieved 2010-10-22 > > https://9p.io/cm/cs/who/dmr/cacm.html > > More generally, just replace "cm.bell-labs.com" with "9p.io". > > -- > David du Colombier > -------------- next part -------------- An HTML attachment was scrubbed... URL: From 0intro at gmail.com Tue Apr 3 15:11:51 2018 From: 0intro at gmail.com (David du Colombier) Date: Tue, 3 Apr 2018 07:11:51 +0200 Subject: [TUHS] dead bstj unix link on wikipedia In-Reply-To: References: Message-ID: > That turned out to be the wrong paper. > > I'm looking for a paper that describes the (early) dialect of C that let you > do stuff like this: > > struct w { > char lo, hi; > }; > > int x; > > char b = x.lo; > > I can't find my hardcopy so was looking for a pdf. There is a list of C-related papers on Dennis Ritchie's page: http://9p.io/who/dmr/ -- David du Colombier From dfawcus+lists-tuhs at employees.org Wed Apr 4 01:49:41 2018 From: dfawcus+lists-tuhs at employees.org (Derek Fawcus) Date: Tue, 3 Apr 2018 16:49:41 +0100 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: <20180403154941.GA81508@accordion.employees.org> On Fri, Mar 30, 2018 at 06:42:09PM -0400, Clem Cole wrote: > > 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]. Well, there was a subtle difference between the Solaris SPARC version and the Linux i386 version which we ran in to when porting a program. I can't quite recall, something to do with symbol visibility for symbols defined in the main executable vs those in a shared object. DF From norman at oclsc.org Fri Apr 6 07:03:02 2018 From: norman at oclsc.org (Norman Wilson) Date: Thu, 05 Apr 2018 17:03:02 -0400 Subject: [TUHS] long lived programs Message-ID: <1522962186.9871.for-standards-violators@oclsc.org> Steve Johnson: 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. ==== This reminds me of an episode during my time at Bell Labs. The System V folks wanted to make pipes that were streams; our experience in Research showed that that was useful. We'd done it just by making pipe(2) create a stream. This caused some subtle differences in semantics (pipes became full-duplex; writing to a pipe put a delimiter in the stream, so that a corresponding read on the other end would stop at the delimiter; write(pipefd, "", 0) therefore generated something that would make read(pipeotherfd, buf, len) return 0). We'd been running all our systems that way for a while, and had uncovered no serious problems. But the System V folks were very nervous about it anyway, and wrote a planning document in which they proposed to create a new, different system call to make stream pipes. pipe(2) would make an old-fashioned pipe; spipe(2) (or whatever it was called, I forget the name) had to be called to get a stream. The document didn't really explain the justification for this. To us in Research it just sounded crazy. Someone else was going to attend a meeting with the developers, but at the last minute he had a conflict, so he drafted me to go. Although I can be pretty blunt in writing, I try not to be so much so in person when dealing with people I don't know; so rather than asking how they could be so crazy as to add a new kind of pipe, I asked why they really thought it necessary. It took a little probing, but the answer turned out to be that their management insisted that everything pass an official verification suite to prove compliance with the System V, Consider It Standard; and said verification suite didn't just check that the first file descriptor returned by pipe(2) could be read and the second written, it insisted that the first could not be written and the second not read. Full-duplex pipes didn't meet the standard, it was claimed. I asked what exactly is the standard? The SVID, I was told. What does the SVID really say, I wondered? We got a copy and looked up pipe(2). According to the official standard, the first file descriptor must be readable and the second writeable, but there was no statement that it couldn't work the other way too. Full-duplex pipes did in fact meet the standard; it was the verification suite that, in an excess of zeal, didn't conform. The developers were absolutely delighted with this. They too thought it was stupid to have two different kinds of pipes, particularly given our experience that full-duplex delimited pipes didn't break anything. They were very happy to have Research not just yell at them for doing things differently from us, but help them figure out how to justify doing things right. I don't know just how they took this further with management, but as it came out in SVr4, pipe(2) returned a full-duplex stream. This is still true even unto Solaris 10, where I just tested it. I made friends that day. That developer group kept in touch with me as they did further work on pipes, the terminal driver, pseudo-ttys, and other things. I didn't agree with everything they did, but we were able to discuss it all cordially. Sometimes the verification program just needs to be fixed. And sometimes the developers that seem set on doing the wrong thing really want help in subverting whatever is forcing that on them, because they really do know what the right thing is. Norman Wilson Toronto ON From clemc at ccc.com Fri Apr 6 07:23:59 2018 From: clemc at ccc.com (Clem Cole) Date: Thu, 5 Apr 2018 17:23:59 -0400 Subject: [TUHS] long lived programs In-Reply-To: <1522962186.9871.for-standards-violators@oclsc.org> References: <1522962186.9871.for-standards-violators@oclsc.org> Message-ID: On Thu, Apr 5, 2018 at 5:03 PM, Norman Wilson wrote: > Sometimes the verification program just needs to be fixed. > And sometimes the developers that seem set on doing the wrong > thing really want help in subverting whatever is forcing that > on them, because they really do know what the right thing is. > ​I like to refer to this as acting intelligently. And think a little about why an earlier implementation had a particular artifact. It is amazing how people can blindly follow ​ ​something because it has been that way. Not that you change things willy-nilly (aka Henry's Spencer's wonderful line: "4.2 BSD is just like Unix ..... only different." Two favorite examples are and case folding. Both are historical artifacts which made sense in an older age, but hardware outgrew then. Steve discussed the stuff a few week ago, so I'll not repeat; but it was always amazing to me that it got codified forever, in the 'text' file idea in things like the C standard -- how completely silly and what a waste of resources and engineering effort over the years. Case folding I find funnier however. Back in the days of 5 and 6 bit codes, particularly when file names were stored in things like rad50 it made perfect sense. The basic character code did not handle upper and lower well, and many keyboards were only one case anyway. But by the time of the 8 bit byte, CP/M and it's child DOS, blindly follow along. Instead of thinking why it was done and since we have a new file system format and thinking -- hmmm maybe we don't need to have the same limitation. Clem​ ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From bakul at bitblocks.com Fri Apr 6 07:38:38 2018 From: bakul at bitblocks.com (Bakul Shah) Date: Thu, 5 Apr 2018 14:38:38 -0700 Subject: [TUHS] long lived programs In-Reply-To: References: <1522962186.9871.for-standards-violators@oclsc.org> Message-ID: <3D0656AE-2164-468B-8C98-578F8B2F16EA@bitblocks.com> May be case itself is such a historical artifact? AFAIK all non-roman scripts are without case distinction. > On Apr 5, 2018, at 2:23 PM, Clem Cole wrote: > > Two favorite examples are and case folding. > > Both are historical artifacts which made sense in an older age, but hardware outgrew then. -------------- next part -------------- An HTML attachment was scrubbed... URL: From krewat at kilonet.net Fri Apr 6 08:46:55 2018 From: krewat at kilonet.net (Arthur Krewat) Date: Thu, 5 Apr 2018 18:46:55 -0400 Subject: [TUHS] long lived programs In-Reply-To: References: <1522962186.9871.for-standards-violators@oclsc.org> Message-ID: <60721fb1-d71b-1790-b2b6-d83453ef4dff@kilonet.net> On 4/5/2018 5:23 PM, Clem Cole wrote: > Case folding I find funnier however. Back in the days of 5 and 6 bit > codes, particularly when file names were stored in things like rad50 > it made perfect sense.   The basic character code did not handle upper > and lower well, and many keyboards were only one case anyway.   But by > the time of the 8 bit byte, CP/M and it's child DOS, blindly follow > along.  Instead of thinking why it was done and since we have a new > file system format and thinking -- hmmm maybe we don't need to have > the same limitation. > I come from the world of SIXBIT on TOPS-10. One of my first tasks for LIRICS/BOCES was to write a replacement for MIC, while still in High School. The TTY I used did only upper case. So all the comments in that source code were in upper case. When it came to real ASCII, and keyboard input, you could never assume that the TTY was going to give you lower case by default (or upper, for that matter). What to do? Be case-insensitive in everything you do. While I understand the simplicity of the code that had to deal with filenames in UNIX (no flipping bits), I don't understand why a file README.TXT is different than readme.txt in UNIX. Now, I love UNIX - I wouldn't have it any other way, but I often wonder what the design goal was. As for a "limitation" for case-sensitive file names, it's more like a feature to me. art k. -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.winalski at gmail.com Fri Apr 6 09:23:18 2018 From: paul.winalski at gmail.com (Paul Winalski) Date: Thu, 5 Apr 2018 19:23:18 -0400 Subject: [TUHS] long lived programs In-Reply-To: References: <1522962186.9871.for-standards-violators@oclsc.org> Message-ID: On 4/5/18, Clem Cole wrote: > > Case folding I find funnier however. Back in the days of 5 and 6 bit codes, > particularly when file names were stored in things like rad50 it made > perfect sense. The basic character code did not handle upper and lower > well, and many keyboards were only one case anyway. But by the time of > the 8 bit byte, CP/M and it's child DOS, blindly follow along. Instead of > thinking why it was done and since we have a new file system format and > thinking -- hmmm maybe we don't need to have the same limitation. > Maybe CP/M and DOS stored file names internally in rad50 or some other compressed form, to save space? The first PCs didn't have much memory (64K), and floppies didn't have much capacity. It was a throwback to the "every bit counts" design and programming days of the 60s/early 70s. -Paul W. From krewat at kilonet.net Fri Apr 6 09:33:43 2018 From: krewat at kilonet.net (Arthur Krewat) Date: Thu, 5 Apr 2018 19:33:43 -0400 Subject: [TUHS] long lived programs In-Reply-To: References: <1522962186.9871.for-standards-violators@oclsc.org> Message-ID: <55023f8d-533b-916e-da03-f26b925b221b@kilonet.net> On 4/5/2018 7:23 PM, Paul Winalski wrote: > Maybe CP/M and DOS stored file names internally in rad50 or some other > compressed form, to save space? Definitely not DOS, and I doubt CP/M did either. art k. From toby at telegraphics.com.au Fri Apr 6 10:05:39 2018 From: toby at telegraphics.com.au (Toby Thain) Date: Thu, 5 Apr 2018 20:05:39 -0400 Subject: [TUHS] long lived programs In-Reply-To: <55023f8d-533b-916e-da03-f26b925b221b@kilonet.net> References: <1522962186.9871.for-standards-violators@oclsc.org> <55023f8d-533b-916e-da03-f26b925b221b@kilonet.net> Message-ID: On 2018-04-05 7:33 PM, Arthur Krewat wrote: > On 4/5/2018 7:23 PM, Paul Winalski wrote: >> Maybe CP/M and DOS stored file names internally in rad50 or some other >> compressed form, to save space? > Definitely not DOS, and I doubt CP/M did either. Right. CP/M used (restricted) ASCII for directory entries. --T > > art k. > > From random832 at fastmail.com Fri Apr 6 12:03:40 2018 From: random832 at fastmail.com (Random832) Date: Thu, 05 Apr 2018 22:03:40 -0400 Subject: [TUHS] long lived programs In-Reply-To: <3D0656AE-2164-468B-8C98-578F8B2F16EA@bitblocks.com> References: <1522962186.9871.for-standards-violators@oclsc.org> <3D0656AE-2164-468B-8C98-578F8B2F16EA@bitblocks.com> Message-ID: <1522980220.3263789.1328338032.3CD6D7F7@webmail.messagingengine.com> On Thu, Apr 5, 2018, at 17:38, Bakul Shah wrote: > May be case itself is such a historical artifact? AFAIK all non-roman > scripts are without case distinction. Greek and Cyrillic both have cases. And the Hiragana/Katakana distinction in Japanese is similar to case in some ways (including limited computer systems using only one) Full list of scripts in unicode that have case distinctions (based on analyzing character names): Adlam, Armenian, Cherokee, Coptic, Cyrillic, Deseret, Georgian, Glagolitic, Greek, Latin, Old Hungarian, Osage, and Warang Citi. From imp at bsdimp.com Fri Apr 6 14:27:59 2018 From: imp at bsdimp.com (Warner Losh) Date: Fri, 06 Apr 2018 04:27:59 +0000 Subject: [TUHS] long lived programs In-Reply-To: <1522980220.3263789.1328338032.3CD6D7F7@webmail.messagingengine.com> References: <1522962186.9871.for-standards-violators@oclsc.org> <3D0656AE-2164-468B-8C98-578F8B2F16EA@bitblocks.com> <1522980220.3263789.1328338032.3CD6D7F7@webmail.messagingengine.com> Message-ID: On Thu, Apr 5, 2018, 8:04 PM Random832 wrote: > On Thu, Apr 5, 2018, at 17:38, Bakul Shah wrote: > > May be case itself is such a historical artifact? AFAIK all non-roman > > scripts are without case distinction. > > Greek and Cyrillic both have cases. And the Hiragana/Katakana distinction > in Japanese is similar to case in some ways (including limited computer > systems using only one) > Really? Those must be quite old as everything I've seen has both. But the difference between kata and kana is much larger than upper and lower case. It is rare to convert one to another as they are used to write different things. Only to look things up in a dictionary would you convert, and then you'd also be converting kanji to... In Roman languages, very little is changed with all caps, though a few things become ambiguous depending on the language... In Japanese, it could turn some foreign loan word into a native word with a totally different meaning... Warner > Full list of scripts in unicode that have case distinctions (based on > analyzing character names): Adlam, Armenian, Cherokee, Coptic, Cyrillic, > Deseret, Georgian, Glagolitic, Greek, Latin, Old Hungarian, Osage, and > Warang Citi. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From scj at yaccman.com Fri Apr 6 14:29:49 2018 From: scj at yaccman.com (Steve Johnson) Date: Thu, 05 Apr 2018 21:29:49 -0700 Subject: [TUHS] long lived programs In-Reply-To: <1522980220.3263789.1328338032.3CD6D7F7@webmail.messagingengine.com> Message-ID: <1b2174093a60698e1b86bf1180507f94b6b1235d@webmail.yaccman.com> Just to make life more interesting, in the early days anything other than letters and numbers were often different for different manufacturers.  I seem to recall Bell Labs buying a custom "print chain" in order to get enough special characters to handle printing programming languages (Doug, this was almost before my time -- do you remember the details?).   I remember there was a device that could print the contents of a punched card on the punched card itself.  It had a number of quirks, including that it only printed 40 (or was it 50) columns of the 80-column card, and had virtually no special symbols.  We quickly became adept at looking at the garbled subsection of the card and intuiting which card it really was... I became all to familiar with that card printer during one summer job.  I was working for Stan Brown, who had written a symbolic algebra system in assembler.   It was a real tour-de-force, and contained several thousand punched cards.  When I started my summer job, Stan made a copy of all the cards for me, so we each had a copy.   Shortly after I arrived, the comp center announced a brand-new feature -- permanent disc storage!  (actually, I think it was a drum...).   Stan and I were excited about the possibility that we could edit the single copy of the program and not have to keep our copies in sync, so we loaded the cards into the file.  There was a crude editor that would allow you to make one pass through the file in order, deleting lines or adding card images after certain line numbers.   You needed a printout of the file that told you the line numbers, but the printout was much easier to handle than the punched cards... A couple of days after the program was safely on the drum, Stan threw out his card deck, assuming that I had the backup copy.  At about the same time, I threw out my card deck, assuming that Stan had a copy.  We discovered this the hard way when I tried to do a fairly substantial edit of the file on disc.  It turned out that the editor only worked correctly when you wrote the edited file into a new file.  If you didn't specify a new file, it attepted to do the edit on top of the file as it edited, creating a jumble of fragments of the original file -- typically 3-10 lines.   By the time we realized this, the file was good and trashed, and we had no backup.   But we did have a listing... So I punched out the mangled file onto cards, and fed them through the card printer, and spent the weekend comparing line by line -- in many cases, I could simply move the punched cards into the proper order, but I did plenty of card punching as well.  Amazingly, I managed to get it working again, and Stan and I kept updated punched cards throughout the summer... Steve ----- Original Message ----- From: "Random832" To: Cc: Sent:Thu, 05 Apr 2018 22:03:40 -0400 Subject:Re: [TUHS] long lived programs On Thu, Apr 5, 2018, at 17:38, Bakul Shah wrote: > May be case itself is such a historical artifact? AFAIK all non-roman > scripts are without case distinction. Greek and Cyrillic both have cases. And the Hiragana/Katakana distinction in Japanese is similar to case in some ways (including limited computer systems using only one) Full list of scripts in unicode that have case distinctions (based on analyzing character names): Adlam, Armenian, Cherokee, Coptic, Cyrillic, Deseret, Georgian, Glagolitic, Greek, Latin, Old Hungarian, Osage, and Warang Citi. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon at fourwinds.com Fri Apr 6 14:31:04 2018 From: jon at fourwinds.com (Jon Steinhart) Date: Thu, 05 Apr 2018 21:31:04 -0700 Subject: [TUHS] long lived programs In-Reply-To: References: <1522962186.9871.for-standards-violators@oclsc.org> <3D0656AE-2164-468B-8C98-578F8B2F16EA@bitblocks.com> <1522980220.3263789.1328338032.3CD6D7F7@webmail.messagingengine.com> Message-ID: <201804060431.w364V4J4029590@darkstar.fourwinds.com> > Greek and Cyrillic both have cases. And the Hiragana/Katakana distinction > in Japanese is similar to case in some ways (including limited computer > systems using only one) Hiragana and Katakana are not cases. Hirigana is used for words of Japanese origin; Katakana is used for "foreign" words. From dave at horsfall.org Fri Apr 6 14:51:21 2018 From: dave at horsfall.org (Dave Horsfall) Date: Fri, 6 Apr 2018 14:51:21 +1000 (EST) Subject: [TUHS] long lived programs In-Reply-To: <1522962186.9871.for-standards-violators@oclsc.org> References: <1522962186.9871.for-standards-violators@oclsc.org> Message-ID: On Thu, 5 Apr 2018, Norman Wilson wrote: > [...] write(pipefd, "", 0) therefore generated something that would make > read(pipeotherfd, buf, len) return 0). Just like what I suggested at UniNSW in the 70s, and got ignored :-) It might even be in AUUGN too, along with my suggestion that stty() be applied to devices other than terminals... -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From usotsuki at buric.co Fri Apr 6 14:58:43 2018 From: usotsuki at buric.co (Steve Nickolas) Date: Fri, 6 Apr 2018 00:58:43 -0400 (EDT) Subject: [TUHS] long lived programs In-Reply-To: References: <1522962186.9871.for-standards-violators@oclsc.org> <3D0656AE-2164-468B-8C98-578F8B2F16EA@bitblocks.com> <1522980220.3263789.1328338032.3CD6D7F7@webmail.messagingengine.com> Message-ID: On Fri, 6 Apr 2018, Warner Losh wrote: > On Thu, Apr 5, 2018, 8:04 PM Random832 wrote: > >> On Thu, Apr 5, 2018, at 17:38, Bakul Shah wrote: >>> May be case itself is such a historical artifact? AFAIK all non-roman >>> scripts are without case distinction. >> >> Greek and Cyrillic both have cases. And the Hiragana/Katakana distinction >> in Japanese is similar to case in some ways (including limited computer >> systems using only one) >> > > Really? Those must be quite old as everything I've seen has both. But the > difference between kata and kana is much larger than upper and lower case. > It is rare to convert one to another as they are used to write different > things. Only to look things up in a dictionary would you convert, and then > you'd also be converting kanji to... > > In Roman languages, very little is changed with all caps, though a few > things become ambiguous depending on the language... > > In Japanese, it could turn some foreign loan word into a native word with a > totally different meaning... > > Warner Some computers in the early 80s, like the Apple ][ J-Plus, only do katakana. -uso. From jon at fourwinds.com Fri Apr 6 15:02:51 2018 From: jon at fourwinds.com (Jon Steinhart) Date: Thu, 05 Apr 2018 22:02:51 -0700 Subject: [TUHS] long lived programs In-Reply-To: References: <1522962186.9871.for-standards-violators@oclsc.org> <3D0656AE-2164-468B-8C98-578F8B2F16EA@bitblocks.com> <1522980220.3263789.1328338032.3CD6D7F7@webmail.messagingengine.com> Message-ID: <201804060502.w3652pmx001767@darkstar.fourwinds.com> > In Japanese, it could turn some foreign loan word into a native word with a > totally different meaning... Not the way that it works. Hiragana and katakana have exactly the same number of characters with exactly the same pronunciation and the same meaning. The difference is more akin to using italics to indicate foreign words. From bakul at bitblocks.com Fri Apr 6 15:57:49 2018 From: bakul at bitblocks.com (Bakul Shah) Date: Thu, 05 Apr 2018 22:57:49 -0700 Subject: [TUHS] long lived programs In-Reply-To: Your message of "Thu, 05 Apr 2018 22:03:40 -0400." <1522980220.3263789.1328338032.3CD6D7F7@webmail.messagingengine.com> References: <1522962186.9871.for-standards-violators@oclsc.org> <3D0656AE-2164-468B-8C98-578F8B2F16EA@bitblocks.com> <1522980220.3263789.1328338032.3CD6D7F7@webmail.messagingengine.com> Message-ID: <20180406055756.A6927156E510@mail.bitblocks.com> On Thu, 05 Apr 2018 22:03:40 -0400 Random832 wrote: Random832 writes: > On Thu, Apr 5, 2018, at 17:38, Bakul Shah wrote: > > May be case itself is such a historical artifact? AFAIK all non-roman > > scripts are without case distinction. > > Greek and Cyrillic both have cases. And the Hiragana/Katakana distinction in > Japanese is similar to case in some ways (including limited computer systems > using only one) > > Full list of scripts in unicode that have case distinctions (based on analyzi > ng character names): Adlam, Armenian, Cherokee, Coptic, Cyrillic, Deseret, Ge > orgian, Glagolitic, Greek, Latin, Old Hungarian, Osage, and Warang Citi. Thanks. I was being lazy. I understand old Latin, Greek & Cyrillic scripts used only one case? And that modern Georgian does not distinguish cases though its alphabet has *several* variants. Osage is very new and Cherokee script was designed in early 1800s (influenced by the europeans). So it seems a) case sensitive scripts are mainly alphabets and b) lower case letters must've been a later addition. [I can see why case was never added to abugida languages like the Indian languages -- they already have a large number of glyphs and complex shapes to remember!] Getting back to programming languages, I am not sure case distinction really helps. Many of the earlier languages such as Algol, PL/I, APL, Pascal, Fortran, Cobol, Lisp didn't have it and I don't think it was solely due to an attempt to pack more chars in a word. Capitalization can improve legibility in written languages but the meaning of a word often doesn't change in spite of case change. In modern PLs the meaning can be entirely different, and even the category (DO vs do) and I am not sure that increases legibility. Not to mention the camelCaseHorror. Much prefer hyphenated-words (and use of space before the negative sign when needed). From jgevaryahu at hotmail.com Fri Apr 6 07:37:11 2018 From: jgevaryahu at hotmail.com (Jonathan Gevaryahu) Date: Thu, 5 Apr 2018 21:37:11 +0000 Subject: [TUHS] dead bstj unix link on wikipedia In-Reply-To: References: Message-ID: The BSTJ 1922-1983 back catalog is now available (some paywalled? ip-watermarked?) at the IEEE explore site at http://ieeexplore.ieee.org/xpl/RecentIssue.jsp?punumber=6731005 (see https://www.bell-labs.com/our-research/technical-journal/ ) However, archived copies of the old bell/lucent site (http://www3.alcatel-lucent.com/bstj/) with some but not all of the pdfs can be found at https://web.archive.org/web/20110810202426/www3.alcatel-lucent.com/bstj/ Individual items containing all(?) the journals and pdfs are available at archive.org at https://archive.org/details/bstj-archives On 4/2/2018 12:11 PM, ron minnich wrote: anyone got a fix? https://en.wikipedia.org/wiki/Bell_System_Technical_Journal see this text 1. Ritchie, D.M.; K. Thompson (July–August 1978). "The UNIX Time-Sharing System". Bell System Technical Journal. 57 (6). Retrieved 2010-10-22 -- Jonathan Gevaryahu AKA Lord Nightmare jgevaryahu at gmail.com jgevaryahu at hotmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From pnr at planet.nl Fri Apr 6 21:34:23 2018 From: pnr at planet.nl (Paul Ruizendaal) Date: Fri, 6 Apr 2018 13:34:23 +0200 Subject: [TUHS] shared objects in Unix (Clem cole) / Accent influence In-Reply-To: References: Message-ID: <0585FDE4-FFC5-42EA-AF25-291E2D3E992D@planet.nl> > Date: Fri, 30 Mar 2018 00:28:13 -0400 > From: Clem cole > > 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. From an "outsider looking in” perspective I’m not sure I recognise such heavy influence in the sockets code base. Of course, suitability for distributed systems was an important part of the 4.2BSD design brief and Rick Rashid was one of the steering committee members, that is all agreed. However in the code evolution for sockets I only see two influences that seem not direct continuations from earlier arpanet unices and have a possible Accent origins: - Addition of sendto()/recvfrom() to the API. Earlier code had poor support for UDP and was forced through the TCP focused API’s, with fixed endpoint addresses. It could be Accent inspired, it could also be a natural solution for sending datagrams. For example, Jack Haverty had hacked a “raw datagram” facility into UoI Arpanet Unix around ’79 (it’s in the Unix Tree). - Addition of a facility to pass file descriptors using sendmsg()/recvmsg() in the local domain. This facility was only added at the very last moment (it was not in 4.1c, only in 4.2). I’m being told that the CSRG team procrastinated on this because they did not see much use for it — and indeed it was mostly ignored in the field for the next two decades. Joy had left by that time, so perhaps the dynamics had changed. Earlier I though that the select() call may have come from Accent, but it was inspired by the Ada select statement. Conceptually, it was preceded on Unix by Haverty’s await() call (also ’79). For clarity: I wasn’t there, just commenting on what I see in the code. Paul From clemc at ccc.com Fri Apr 6 22:03:37 2018 From: clemc at ccc.com (Clem cole) Date: Fri, 6 Apr 2018 08:03:37 -0400 Subject: [TUHS] shared objects in Unix (Clem cole) / Accent influence In-Reply-To: <0585FDE4-FFC5-42EA-AF25-291E2D3E992D@planet.nl> References: <0585FDE4-FFC5-42EA-AF25-291E2D3E992D@planet.nl> Message-ID: <8817996E-6755-4C08-AC3F-98CFF4ABF63D@ccc.com> Sorry autocorrect bit me. And being discussed by both faculty and grad students a like Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. > On Apr 6, 2018, at 7:34 AM, Paul Ruizendaal wrote: > > >> Date: Fri, 30 Mar 2018 00:28:13 -0400 >> From: Clem cole >> >> 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. > > From an "outsider looking in” perspective I’m not sure I recognise such heavy influence in the sockets code base. Of course, suitability for distributed systems was an important part of the 4.2BSD design brief and Rick Rashid was one of the steering committee members, that is all agreed. > > However in the code evolution for sockets I only see two influences that seem not direct continuations from earlier arpanet unices and have a possible Accent origins: > > - Addition of sendto()/recvfrom() to the API. Earlier code had poor support for UDP and was forced through the TCP focused API’s, with fixed endpoint addresses. It could be Accent inspired, it could also be a natural solution for sending datagrams. For example, Jack Haverty had hacked a “raw datagram” facility into UoI Arpanet Unix around ’79 (it’s in the Unix Tree). > > - Addition of a facility to pass file descriptors using sendmsg()/recvmsg() in the local domain. This facility was only added at the very last moment (it was not in 4.1c, only in 4.2). I’m being told that the CSRG team procrastinated on this because they did not see much use for it — and indeed it was mostly ignored in the field for the next two decades. Joy had left by that time, so perhaps the dynamics had changed. > > Earlier I though that the select() call may have come from Accent, but it was inspired by the Ada select statement. Conceptually, it was preceded on Unix by Haverty’s await() call (also ’79). > > For clarity: I wasn’t there, just commenting on what I see in the code. > > Paul From dot at dotat.at Sat Apr 7 01:00:03 2018 From: dot at dotat.at (Tony Finch) Date: Fri, 6 Apr 2018 16:00:03 +0100 Subject: [TUHS] long lived programs In-Reply-To: <1522962186.9871.for-standards-violators@oclsc.org> References: <1522962186.9871.for-standards-violators@oclsc.org> Message-ID: Norman Wilson wrote: > > We'd done it just by making pipe(2) create a stream. This caused some > subtle differences in semantics (pipes became full-duplex; writing to a > pipe put a delimiter in the stream, so that a corresponding read on the > other end would stop at the delimiter; Was it 4.4BSD which implemented pipe() using socketpair() under the covers? Full-duples like streams, but without the delimiters. Tony. -- f.anthony.n.finch http://dotat.at/ a fair voting system for all elections From dave at horsfall.org Sat Apr 7 06:56:44 2018 From: dave at horsfall.org (Dave Horsfall) Date: Sat, 7 Apr 2018 06:56:44 +1000 (EST) Subject: [TUHS] Happy birthday, Internet! Message-ID: The Internet (spelled with a capital "I", please, as it is a proper noun) was born on this day in 1969, when RFC-1 got published; it described the IMP and ARPAnet. As I said at a club lecture once, there are many internets, but only one Internet. -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From peter at rulingia.com Sat Apr 7 07:52:40 2018 From: peter at rulingia.com (Peter Jeremy) Date: Sat, 7 Apr 2018 07:52:40 +1000 Subject: [TUHS] long lived programs In-Reply-To: <20180406055756.A6927156E510@mail.bitblocks.com> References: <1522962186.9871.for-standards-violators@oclsc.org> <3D0656AE-2164-468B-8C98-578F8B2F16EA@bitblocks.com> <1522980220.3263789.1328338032.3CD6D7F7@webmail.messagingengine.com> <20180406055756.A6927156E510@mail.bitblocks.com> Message-ID: <20180406215240.GA57101@server.rulingia.com> On 2018-Apr-05 22:57:49 -0700, Bakul Shah wrote: >Getting back to programming languages, I am not sure case >distinction really helps. Many of the earlier languages such >as Algol, PL/I, APL, Pascal, Fortran, Cobol, Lisp didn't have >it and I don't think it was solely due to an attempt to pack >more chars in a word. Early APL implementations do have cases - they use underscored capitals as a second case (rather like early Unix would use A and \A). In the case of APL, I suspect the limiting factor was the number of characters on a golfball. Internally, it required 8-bit characters to represent all the symbols. >Capitalization can improve legibility in >written languages but the meaning of a word often doesn't >change in spite of case change. In modern PLs the meaning can >be entirely different, and even the category (DO vs do) and I >am not sure that increases legibility. Cases (particularly capitalisation) can add meaning - German and English both use capitalisation as hints (I'm not sure about other languages). Many programming languages have defacto conventions that use case to indicate the category of a name (eg constants and macros are all upper case in C) and Go uses capitalisation to control visibility. The problem of "DO" vs "do" is no different to "xl" vs "x1" vs "xI" or "DO" vs "D0" - they are distinct to the compiler but can be confusing to the reader and are probably better handled via style conventions than trying to mandate that the compiler makes them equivalent. >Not to mention the >camelCaseHorror. Much prefer hyphenated-words Hyphenated variable names don't work in many programming languages because "-" is an operator. The use of camelCase vs underscores tends to be a language convention. Whe Using "case-insensitive, case-preserving" helps in some cases but I suspect at least some of that is because that is mostly how English works and therefore English speakers will naturally read "THIS" and "this" as equivalent. Someone whose native language is not a latin script is likely to find having "THIS" and "this" being the same is quite confusing and an English speaker probably won't instinctively see "jqvkwrri" and "JQVKWRRI" as identical. (BTW, DNS is an example of a case-insensitive, case-preserving service). -- 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 doug at cs.dartmouth.edu Sat Apr 7 08:33:17 2018 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Fri, 06 Apr 2018 18:33:17 -0400 Subject: [TUHS] long lived programs Message-ID: <201804062233.w36MXHAr005863@coolidge.cs.Dartmouth.EDU> > Shortly after I arrived, the comp center announced a brand-new feature -- permanent disc storage!  (actually, I think it was a drum...) Irrelevant to the story (or Unix), but it was indeed a disc drive--much more storage per unit volume than drums, which date to the 1940s, if not before. Exact opposite of current technology: super heavy and rigid combs banged in and out of the disk stack. The washing-machine sized machine could be driven to walk across the floor. It would not be nice to be caught in its path. (Fortunately ordinary work loads did not have such an effect.) Vic Vyssotsky calculated that with only 10 times its 10MB capacity, we could have kept the entire printed output since the advent of computers at the Labs on line. Doug From cym224 at gmail.com Sat Apr 7 09:10:02 2018 From: cym224 at gmail.com (Nemo) Date: Fri, 6 Apr 2018 19:10:02 -0400 Subject: [TUHS] Happy birthday, Internet! In-Reply-To: References: Message-ID: On 06/04/2018, Dave Horsfall wrote: > The Internet (spelled with a capital "I", please, as it is a proper noun) > was born on this day in 1969, when RFC-1 got published; it described the > IMP and ARPAnet. This prompted me to look through the list (at https://www.rfc-editor.org/rfc-index.html). Some very interesting titles there. > As I said at a club lecture once, there are many internets, but only one > Internet. Where was this codified? (I recall reading RFCs that referred to "an internet" but cannot remember where.) N. From dave at horsfall.org Sat Apr 7 09:19:55 2018 From: dave at horsfall.org (Dave Horsfall) Date: Sat, 7 Apr 2018 09:19:55 +1000 (EST) Subject: [TUHS] Happy birthday, Internet! In-Reply-To: References: Message-ID: On Fri, 6 Apr 2018, Nemo wrote: > This prompted me to look through the list (at > https://www.rfc-editor.org/rfc-index.html). Some very interesting > titles there. Especially the ones published on 1st April :-) >> As I said at a club lecture once, there are many internets, but only >> one Internet. > > Where was this codified? (I recall reading RFCs that referred to "an > internet" but cannot remember where.) Dunno where I saw it, and I would credit it if I could (I certainly did not coin the phrase, but I may have adapted it). -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From khm at sciops.net Sat Apr 7 09:56:17 2018 From: khm at sciops.net (Kurt H Maier) Date: Fri, 6 Apr 2018 16:56:17 -0700 Subject: [TUHS] Happy birthday, Internet! In-Reply-To: References: Message-ID: <20180406235617.GA56598@wopr> On Fri, Apr 06, 2018 at 07:10:02PM -0400, Nemo wrote: > > Where was this codified? (I recall reading RFCs that referred to "an > internet" but cannot remember where.) It's all over the place in RFC 1180, although that's not a standards document. khm From paul.winalski at gmail.com Sat Apr 7 11:01:44 2018 From: paul.winalski at gmail.com (Paul Winalski) Date: Fri, 6 Apr 2018 21:01:44 -0400 Subject: [TUHS] long lived programs In-Reply-To: <201804062233.w36MXHAr005863@coolidge.cs.Dartmouth.EDU> References: <201804062233.w36MXHAr005863@coolidge.cs.Dartmouth.EDU> Message-ID: On 4/6/18, Doug McIlroy wrote: > The washing-machine > sized machine could be driven to walk across the floor. I had exactly that happen to me when I was a student operator of my college's System/360. We had a bank of three IBM 2311 disk drives (each washing machine size; capacity 7 MB). They were bolted together and at the opposite end of the raised floor computer room from the CPU and operator's station. Facing the console, I had my back to the disk drives. One evening I heard rattling noises behind me, turned my chair around, and was shocked to find the disk drives right behind me. IBM customer service had forgotten to lock the wheels on the drives, and they had crept across the floor. > Vic Vyssotsky calculated that with only > 10 times its 10MB capacity, we could have kept the entire printed > output since the advent of computers at the Labs on line. Last year I bought two 4 TB drives for backing up my home computer. As I walked to the check-out, it occurred to me that I was holding in my hands over a thousand times the entire disk capacity of the world at the time I started in the industry. -Paul W. From lm at mcvoy.com Sat Apr 7 11:09:36 2018 From: lm at mcvoy.com (Larry McVoy) Date: Fri, 6 Apr 2018 18:09:36 -0700 Subject: [TUHS] long lived programs In-Reply-To: References: <201804062233.w36MXHAr005863@coolidge.cs.Dartmouth.EDU> Message-ID: <20180407010936.GB14572@mcvoy.com> On Fri, Apr 06, 2018 at 09:01:44PM -0400, Paul Winalski wrote: > Last year I bought two 4 TB drives for backing up my home computer. > As I walked to the check-out, it occurred to me that I was holding in > my hands over a thousand times the entire disk capacity of the world > at the time I started in the industry. Yeah, it's crazy. When I was doing my first sys admin job it was on a Masscomp that had a 40MB disk for 20 people. We made it work. I believe someone announced a 40TB SSD, nope, just looked, Seagate announced a 60TB SSD in 2016. WTF, that's a huge drive for rotating, that's insane for SSD. We old farts live in interesting times. --lm From rudi.j.blom at gmail.com Sat Apr 7 14:54:33 2018 From: rudi.j.blom at gmail.com (Rudi Blom) Date: Sat, 7 Apr 2018 11:54:33 +0700 Subject: [TUHS] Happy birthday, Internet! Message-ID: Just had a look at RFC-1, my first look ever. First thing I noticed is the enormous amount of abbreviations one is assumed to be able to instantly place :-) So looking up IMP for instance the wiki page gives me this funny titbit "When Massachusetts Senator Edward Kennedy learned of BBN's accomplishment in signing this million-dollar agreement, he sent a telegram congratulating the company for being contracted to build the "Interfaith Message Processor"." https://en.wikipedia.org/wiki/Interface_Message_Processor From jgevaryahu at hotmail.com Fri Apr 6 07:17:48 2018 From: jgevaryahu at hotmail.com (Jonathan Gevaryahu) Date: Thu, 5 Apr 2018 21:17:48 +0000 Subject: [TUHS] dead bstj unix link on wikipedia In-Reply-To: References: Message-ID: That reminds me of the multicharacter constant vs 'byte' index used in speak.c, I didn't realize this was an intended 'feature' for faking tuples (and allowing to index by either the first or second element) in early C, it seemed a bit of a hack to me. I was hoping there was some elegant way to achieve nearly the same thing in modern C, but I didn't find anything obvious short of string comparisons and an array with a byte and a pointer to a string. On 4/2/2018 6:53 PM, ron minnich wrote: That turned out to be the wrong paper. I'm looking for a paper that describes the (early) dialect of C that let you do stuff like this: struct w { char lo, hi; }; int x; char b = x.lo; I can't find my hardcopy so was looking for a pdf. ron On Mon, Apr 2, 2018 at 10:36 AM David du Colombier <0intro at gmail.com> wrote: > anyone got a fix? > > https://en.wikipedia.org/wiki/Bell_System_Technical_Journal > > see this text > > Ritchie, D.M.; K. Thompson (July–August 1978). "The UNIX Time-Sharing > System". Bell System Technical Journal. 57 (6). Retrieved 2010-10-22 https://9p.io/cm/cs/who/dmr/cacm.html More generally, just replace "cm.bell-labs.com" with "9p.io". -- David du Colombier -- Jonathan Gevaryahu AKA Lord Nightmare jgevaryahu at gmail.com jgevaryahu at hotmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnc at mercury.lcs.mit.edu Sat Apr 7 22:50:41 2018 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Sat, 7 Apr 2018 08:50:41 -0400 (EDT) Subject: [TUHS] Happy birthday, Internet! Message-ID: <20180407125041.7A89318C089@mercury.lcs.mit.edu> > From: Dave Horsfall > The Internet ... was born on this day in 1969, when RFC-1 got published I have this vague memory that the Internet-History list decided that the appropriate day was actually the day the format of the v4 headers was set, i.e. 16 June, 1978. (See IEN-68, pg. 12, top.) Picking the date of RFC-1 seems a little odd. Why not the day the first packet was send over a deployed IMP, or the day the RFP was sent out, or the contract let? And the ARPANet was just one predecessor; one might equally have picked a CYCLADES date... > (spelled with a capital "I", please, as it is a proper noun) ... As I > said at a club lecture once, there are many internets, but only one > Internet. I myself prefer the formulation 'there are many white houses, but only one White House'! :-) Noel From usotsuki at buric.co Sun Apr 8 00:34:51 2018 From: usotsuki at buric.co (Steve Nickolas) Date: Sat, 7 Apr 2018 10:34:51 -0400 (EDT) Subject: [TUHS] Happy birthday, Internet! In-Reply-To: <20180407125041.7A89318C089@mercury.lcs.mit.edu> References: <20180407125041.7A89318C089@mercury.lcs.mit.edu> Message-ID: On Sat, 7 Apr 2018, Noel Chiappa wrote: > > From: Dave Horsfall > > > The Internet ... was born on this day in 1969, when RFC-1 got published > > I have this vague memory that the Internet-History list decided that the > appropriate day was actually the day the format of the v4 headers was set, > i.e. 16 June, 1978. (See IEN-68, pg. 12, top.) I thought the epoch of the Internet was January 1, 1983. -uso. From clemc at ccc.com Sun Apr 8 00:44:42 2018 From: clemc at ccc.com (Clem Cole) Date: Sat, 7 Apr 2018 10:44:42 -0400 Subject: [TUHS] Happy birthday, Internet! In-Reply-To: References: <20180407125041.7A89318C089@mercury.lcs.mit.edu> Message-ID: On Sat, Apr 7, 2018 at 10:34 AM, Steve Nickolas wrote: > > > I thought the epoch of the Internet was January 1, 1983. > ​In the USA, we have an idea called adoption day, which is picked when family of an adopted child celebrates their becoming part of the family, which when the kids are young we point is in many ways is more powerful than the birthday. because it says we picked you. ​So one might want to claim that 1983/01/01 is the Internet's 'Adoption Day' and not really care much about the others. Clem​ ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Sun Apr 8 01:21:10 2018 From: clemc at ccc.com (Clem Cole) Date: Sat, 7 Apr 2018 11:21:10 -0400 Subject: [TUHS] Happy birthday, Internet! In-Reply-To: References: Message-ID: On Sat, Apr 7, 2018 at 12:54 AM, Rudi Blom wrote: > Just had a look at RFC-1, my first look ever. First thing I noticed is > the enormous amount of abbreviations one is assumed to be able to > instantly place :-) > > So looking up IMP for instance the wiki page gives me this funny titbit > > "When Massachusetts Senator Edward Kennedy learned of BBN's > accomplishment in signing this million-dollar agreement, he sent a > telegram congratulating the company for being contracted to build the > "Interfaith Message Processor"." > https://en.wikipedia.org/wiki/Interface_Message_Processor > ​A small suggestion, instead of trying to piecemeal it together here; to all if you have not yet read (but certainly to newer and maybe younger readers of this list since I think this was late 1990s), please go find a copy of Katie Hafner's: Where Wizards Stay Up Late: The Origins Of The Internet . Many and more of these interesting facts can be found. It's a great read and I can say, a large number of the parts I lived and knew specifically about, pretty much follow the way I remembered it. There are things left out, and some other good stories not there [Dave Clark does not get enough credit in my opinion or in the infamous milkshake spilled into the CMU IMP]. But, the mail header wars are well handled. And certainly the road to the ARPAnet, then to the Internet itself is pretty thoroughly examined. Clem ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.winalski at gmail.com Sun Apr 8 06:41:28 2018 From: paul.winalski at gmail.com (Paul Winalski) Date: Sat, 7 Apr 2018 16:41:28 -0400 Subject: [TUHS] long lived programs In-Reply-To: <1522962186.9871.for-standards-violators@oclsc.org> References: <1522962186.9871.for-standards-violators@oclsc.org> Message-ID: On 4/5/18, Norman Wilson wrote: [regarding streams implementation of pipes] > > But the System V folks were very nervous about it anyway, and > wrote a planning document in which they proposed to create a > new, different system call to make stream pipes. pipe(2) would > make an old-fashioned pipe; spipe(2) (or whatever it was called, > I forget the name) had to be called to get a stream. The document > didn't really explain the justification for this. To us in > Research it just sounded crazy. Sometimes critical code can have unintended dependencies on buggy or undocumented behavior of system features. I ran into something of this sort in the Unix C runtime when I did the linker for VAX Fortran for Ultrix. The VAX Fortran runtime was written in several source languages, and there was no common back end for the compilers for these languages, so we decided that the easiest way to get the whole mess ported to Ultrix was to port the VAX/VMS linker to Ultrix and to teach it to understand a.out files and ar archives. To prevent any copyright or other IP problems, we did the project without reference to the Unix sources or anything other than publicly published documents. All went well until we got to testing, where we got a curious test failure. The cause of the failure was the allocation of the C RTL's iob structure, which is an array that holds the file descriptors associated with stdin, stdout, and stderr. The program was dying because it was accessing iob[2] (stderr), but my Ultrix linker had only allocated 8 bytes, not 12, for the iob array. ld, on the other hand, allocated 12 bytes. All of the objects that participated in the link had iob declared as an 8-byte common symbol, so I couldn't for the life of me understand why ld allocated 12 bytes for it. In desperation I looked at the source code for ld. a.out common symbols have the "external" bit specified, but unlike global reference symbols they have a non-zero value field. If there is a global definition for the name, the common symbol is resolved against that (i.e., it behaves like a global reference). If not, the linker allocates space in bss for the symbol, using the value field as the number of bytes to allocate. If common symbols of the same name from different object files have different sizes, the linker allocates the largest size. The other significant feature of common symbols is that if an archive member contains a common symbol that resolves a global reference, that isn't enough to cause the archive member to be loaded, as would be the case with a global definition. The root cause of my problem was a feature of the ranlib program. When ranlib built the archive index of global symbols, it merely looked at the "external" bit--it indexed common symbols as well as global definitions. So if a linker sees a name it's looking for in the ranlib index, it has to actually process the module's symbol table to make sure that it is a "hard" definition and not a common symbol. My ported VMS linker was very careful to do a pre-scan of each module before loading so as to prevent common symbols causing a load. ld took a different approach--it loaded the module and then processed its symbol table. If it found that a common symbol had provoked the load, it said "oops" and unloaded the module. But by then it had already maximized the sizes of any common symbols that were in the module--the new sizes didn't get backed out. So for common symbols ld would allocate not the largest size for the symbol in any module participating in the link, but the largest size IN ANY MODULE THAT LD SAW while doing the link! It turned out that there was a module in the Unix C runtime declared iob as a two-element array, but the code accessed iob[2]. They got away with this bug because ld always saw modules where iob was a three-element array when it processed libc.a and thus always allocated 12 bytes for it. My linker processed only the symbols in the modules that actually were brought in from libc.a, and hence it ended up allocating only 8 bytes. One of Murphy's laws of programming is that if a facility has undocumented side effects, there will be an important program that depends on them. Hence the reluctance of many software engineers to make radical changes to how a feature is implemented. -Paul W. From dave at horsfall.org Mon Apr 9 09:27:10 2018 From: dave at horsfall.org (Dave Horsfall) Date: Mon, 9 Apr 2018 09:27:10 +1000 (EST) Subject: [TUHS] Happy birthday, J. Presper Eckert! Message-ID: J. Presper Eckert was born on this day in 1919; along with John Mauchly, he was a co-designer of ENIAC, one of the world's first programmable electronic computers. Yes, there is a long-running dispute over whether ENIAC or Colossus was first; being a Pommie, I'm siding with Colossus :-) -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From dave at horsfall.org Mon Apr 9 09:34:03 2018 From: dave at horsfall.org (Dave Horsfall) Date: Mon, 9 Apr 2018 09:34:03 +1000 (EST) Subject: [TUHS] Happy birthday, Internet! In-Reply-To: <20180407125041.7A89318C089@mercury.lcs.mit.edu> References: <20180407125041.7A89318C089@mercury.lcs.mit.edu> Message-ID: On Sat, 7 Apr 2018, Noel Chiappa wrote: > I have this vague memory that the Internet-History list decided that the > appropriate day was actually the day the format of the v4 headers was > set, i.e. 16 June, 1978. (See IEN-68, pg. 12, top.) I'm happy to be corrected if we can reach a consensus; history is written by the victors, after all. > Picking the date of RFC-1 seems a little odd. Why not the day the first > packet was send over a deployed IMP, or the day the RFP was sent out, or > the contract let? And the ARPANet was just one predecessor; one might > equally have picked a CYCLADES date... I saw the reference on one of those history sites, I think. And I already have the date of the first packet. Again, updates to my list are always welcome; I'm not pronouncing them ex-cathedra or anything... > I myself prefer the formulation 'there are many white houses, but only > one White House'! :-) Yeah, well... -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From dave at horsfall.org Mon Apr 9 09:34:53 2018 From: dave at horsfall.org (Dave Horsfall) Date: Mon, 9 Apr 2018 09:34:53 +1000 (EST) Subject: [TUHS] Happy birthday, Internet! In-Reply-To: References: <20180407125041.7A89318C089@mercury.lcs.mit.edu> Message-ID: On Sat, 7 Apr 2018, Steve Nickolas wrote: > I thought the epoch of the Internet was January 1, 1983. Citation, please? -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From clemc at ccc.com Mon Apr 9 10:06:50 2018 From: clemc at ccc.com (Clem Cole) Date: Sun, 8 Apr 2018 20:06:50 -0400 Subject: [TUHS] Happy birthday, Internet! In-Reply-To: References: <20180407125041.7A89318C089@mercury.lcs.mit.edu> Message-ID: Dave, first of Jan 83 was the day the Arpanet was supposed to be turned off by then DDN who was running things and all sites were supposed to have switched to the IP. One of must have a copy of the DDN memo somewhere. The truth is, it did not happen, there were a few exceptions granted for some sites that were not quite ready (I've forgotten now). That BTW: the difference between ARPAnet to IP and IPv4 to v6 switch. There was someone in charge, the US Gov - which was paying the bills, so they could declare a red-letter day. IMHO: It really too bad, economic got in the way of sanity so we still have v4. Clem ᐧ On Sun, Apr 8, 2018 at 7:34 PM, Dave Horsfall wrote: > On Sat, 7 Apr 2018, Steve Nickolas wrote: > > I thought the epoch of the Internet was January 1, 1983. >> > > Citation, please? > > > -- > Dave Horsfall DTM (VK2KFU) "Those who don't understand security will > suffer." > -------------- next part -------------- An HTML attachment was scrubbed... URL: From khm at sciops.net Mon Apr 9 11:16:59 2018 From: khm at sciops.net (Kurt H Maier) Date: Sun, 8 Apr 2018 18:16:59 -0700 Subject: [TUHS] Happy birthday, Internet! In-Reply-To: References: <20180407125041.7A89318C089@mercury.lcs.mit.edu> Message-ID: <20180409011659.GA10849@wopr> On Sun, Apr 08, 2018 at 08:06:50PM -0400, Clem Cole wrote: > > That BTW: the difference between ARPAnet to IP and IPv4 to v6 switch. > The other difference is that IPv4 was a well-designed protocol, where IPv6 is a hodgepodge of harebrained pet projects. Despite being tagged version 6, it's the worst case of Second-System Effect I've ever seen in my life. Most sites I know of that have chosen to sit it out so far have done so because it's a massive engineering lift with little discernable benefit; it merely trades IPv4's problems for newer, experimental problems. This is the same situation that keeps UNIX entrenched: it's not flawless, but we understand the flaws, and the core design is at least comprehensible. khm From dave at horsfall.org Mon Apr 9 16:18:28 2018 From: dave at horsfall.org (Dave Horsfall) Date: Mon, 9 Apr 2018 16:18:28 +1000 (EST) Subject: [TUHS] That "SPL 0" instruction... Message-ID: A nerdy group on an Aussie list are discussing old Unix cracks, and the infamous "SPL 0" brick-that-box came up. I first saw it in ";login:" (I think), and, err, tried it (as did others)... Can anyone reproduce the code? It went something like: > [ SPL 0 ] > > I only did that once (and you should've heard what he said to me)... > I'm still trying to find the source for it (it was published in a > ";login:" journal) to see if SIMH is vulnerable. The concept was simple enough - fill your entire memory space with an uninterruptible instruction. It would have gone something like: opc = 000230 ; 000230 is the opcode for SPL 0 sys brk, -1 ; or whatever value got you all 64k of address space mov #place, sp jmp place . = opc - 2 ; the -2 is to allow for the PC increment on an instruction fetch, which I believe happens before any execution place: jsr pc, -(pc) Ring any bells, anyone? -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From jnc at mercury.lcs.mit.edu Tue Apr 10 00:52:32 2018 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Mon, 9 Apr 2018 10:52:32 -0400 (EDT) Subject: [TUHS] Happy birthday, Internet! Message-ID: <20180409145232.4DFDA18C073@mercury.lcs.mit.edu> > From: Steve Nickolas > I thought the epoch of the Internet was January 1, 1983. Turning off NCP was a significant step, but not that big a deal in terms of its actual effects, really. For those of us already on the Internet before that date (since as the number of ARPANet ports was severely limited, for many non-ARPANet-connected machines - which were almost all time-sharing systems, at that point in time, so lots of actual users - there was a lot of value in an Internet connection, so there were quite a few), it didn't produce any significant change - the universe of machines we could talk to didn't change (since we could only talk to ARPANet-connected machines with TCP), etc. And for ARPANET-connected machines, there too, things didn't change much - the services available (remote login, email, etc) remained the same - it was just carried over TCP, not NCP. I guess in some sense it marked 'coming of age' for TCP/IP, but I'd analogize it to that, rather than a 'birth' date. Noel From jnc at mercury.lcs.mit.edu Tue Apr 10 00:57:53 2018 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Mon, 9 Apr 2018 10:57:53 -0400 (EDT) Subject: [TUHS] Happy birthday, Internet! Message-ID: <20180409145753.5BF6818C073@mercury.lcs.mit.edu> > From: Clem Cole > Katie Hafner's: Where Wizards Stay Up Late: The Origins Of The Internet > ... > It's a great read Yes, she did a great deal of careful research, and it's quite accurate. It _is_ pointed toward a general readership, not a technical one, so it's not necessarily the best _technical_ history (which she had the material at hand to produce, had she wanted to - but did not). Still, very worthwhile. Noel From fair-tuhs at netbsd.org Tue Apr 10 01:01:40 2018 From: fair-tuhs at netbsd.org (Erik E. Fair) Date: Mon, 09 Apr 2018 08:01:40 -0700 Subject: [TUHS] Happy birthday, Internet! In-Reply-To: <20180409145232.4DFDA18C073@mercury.lcs.mit.edu> Message-ID: <10182.1523286100@cesium.clock.org> Noel, I'll disagree for the simple reason that as of the advent of TCP/IP, all those Ethernet and Chaosnet connected workstations became first class hosts on the Internet, which they could not be before. That was a very big deal. Erik Fair From jnc at mercury.lcs.mit.edu Tue Apr 10 01:37:43 2018 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Mon, 9 Apr 2018 11:37:43 -0400 (EDT) Subject: [TUHS] Happy birthday, Internet! Message-ID: <20180409153743.D925418C073@mercury.lcs.mit.edu> > From: Clem Cole > first of Jan 83 was the day the Arpanet was supposed to be turned off Err, NCP, not the ARPANet. The latter kept running for quite some time, serving as the Internet's wide-area backbone, and was only slowly turned off (IMP by IMP) in the late 80's, with the very last remnants finally being turned off in 1990. > The truth is, it did not happen, there were a few exceptions granted for > some sites that were not quite ready (I've forgotten now). A few, yes, but NCP was indeed turned off for most hosts on January 1, 1983. > From: "Erik E. Fair" > as of the advent of TCP/IP, all those Ethernet and Chaosnet connected > workstations became first class hosts on the Internet, which they > could not be before. Huh? As I just pointed out, TCP/IP (and the Internet) was a going concern well _before_ January 1, 1983 - and one can confidently say that even had NCP _not_ been turned off, history would have proceeded much as it actually did, since all the machines not on the ARPANET would have wanted to be connected to the Internet. (Also, to be technical, I'm not sure if TCP/IP ever really ran on CHAOSNet hardware - I know I did a spec for it, and the C Gateway implemented it, and there was a Unix machine at EECS that tried to use it, but it was not a great success. Workstations connected to the CHAOSNet as of that date - AFAIK, just LISP Machines - could only get access to the Internet via service gateways, since at that point they all only implemented the CHAOS protocols; Symbolics did TCP/IP somewhat later, IIRC, although I don't know the exact date.) Noel From dscherrer at solar.stanford.edu Tue Apr 10 07:28:08 2018 From: dscherrer at solar.stanford.edu (Deborah Scherrer) Date: Mon, 9 Apr 2018 14:28:08 -0700 Subject: [TUHS] Software Tools now in Wikipedia Message-ID: I rewrote the article on the Software Tools project and, thanks to Bruce Borden's efforts to upload, they accepted it within 1 day. You can see it here: https://en.wikipedia.org/wiki/Software_tools_users_group The Usenix article in Wiki is pretty thin, in case anyone would like to spiffy it up. Deborah From gregg.drwho8 at gmail.com Tue Apr 10 14:31:51 2018 From: gregg.drwho8 at gmail.com (Gregg Levine) Date: Tue, 10 Apr 2018 00:31:51 -0400 Subject: [TUHS] Software Tools now in Wikipedia In-Reply-To: References: Message-ID: Hello! That's amazing. I know of both Dennis Hall, especially Dennis Hall, and that of Joseph S. Sventek via Cliff Stoll's book "Cuckoo's Egg" of course. ----- Gregg C Levine gregg.drwho8 at gmail.com "This signature fought the Time Wars, time and again." On Mon, Apr 9, 2018 at 5:28 PM, Deborah Scherrer wrote: > I rewrote the article on the Software Tools project and, thanks to Bruce > Borden's efforts to upload, they accepted it within 1 day. You can see it > here: https://en.wikipedia.org/wiki/Software_tools_users_group > > The Usenix article in Wiki is pretty thin, in case anyone would like to > spiffy it up. > > Deborah From doug at cs.dartmouth.edu Tue Apr 10 20:52:34 2018 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Tue, 10 Apr 2018 06:52:34 -0400 Subject: [TUHS] Software Tools now in Wikipedia Message-ID: <201804101052.w3AAqYFW008800@coolidge.cs.Dartmouth.EDU> > I rewrote the article on the Software Tools project An excellent job, Deborah. > the Software Tools movement established one of the earliest traditions of open source Would you be open to saying "reestablished"? Open source (not so called, and in no way portable) was very much a tradition of SHARE in the late 1950s. Portability, as exemplified in ACM's collected algorithms, came in at the same time that industry moved to a model of trade secrets and intellectual property. Open source went into eclipse. Doug From clemc at ccc.com Wed Apr 11 04:32:09 2018 From: clemc at ccc.com (Clem Cole) Date: Tue, 10 Apr 2018 14:32:09 -0400 Subject: [TUHS] Happy birthday, Internet! In-Reply-To: <20180409153743.D925418C073@mercury.lcs.mit.edu> References: <20180409153743.D925418C073@mercury.lcs.mit.edu> Message-ID: On Mon, Apr 9, 2018 at 11:37 AM, Noel Chiappa wrote: > > From: Clem Cole > > > first of Jan 83 was the day the Arpanet was supposed to be turned off > > Err, NCP, not the ARPANet. ​Absolutely right. ​ Sorry about that.​ > The latter kept running for quite some time, > serving as the Internet's wide-area backbone, and was only slowly turned > off > (IMP by IMP) in the late 80's, with the very last remnants finally being > turned off in 1990. ​Indeed​ ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Wed Apr 11 05:11:56 2018 From: clemc at ccc.com (Clem Cole) Date: Tue, 10 Apr 2018 15:11:56 -0400 Subject: [TUHS] Happy birthday, Internet! In-Reply-To: <20180409153743.D925418C073@mercury.lcs.mit.edu> References: <20180409153743.D925418C073@mercury.lcs.mit.edu> Message-ID: On Mon, Apr 9, 2018 at 11:37 AM, Noel Chiappa wrote: > ​...​ > one can confidently say that even had NCP _not_ > been turned off, history would have proceeded much as it actually did, > since > all the machines not on the ARPANET would have wanted to be connected to > the > Internet. ​I agree - this is classic Metcalfe's law. Because no new NCP sites were being added, the Internet quickly became the more and more valuable. Which is exactly why IPv6 never flipped. We succeeded in keeping the old being more valuable than the new, so there was not real push. I had hoped the backbone providers would offer a rate differential (i.e. make it cheaper) to use IPv6 because it should have been easier for them. I practice is not and none of them ever did to my knowledge. So the economics just there like it was between NCP and IPv4. Clem ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From wkt at tuhs.org Wed Apr 11 23:32:09 2018 From: wkt at tuhs.org (Warren Toomey) Date: Wed, 11 Apr 2018 23:32:09 +1000 Subject: [TUHS] A Legal History of Unix Message-ID: <20180411133209.GA20747@minnie.tuhs.org> I was sure that I'd read a paper on the legal history of Unix. So I did a Google search for it, and found a link to the PDF. The linked PDF was on the TUHS website :-) http://wiki.tuhs.org/lib/exe/fetch.php?media=publications:theses:gmp_thesis.pdf I'd better do a backup of my brain, as I've got a few flakey DRAM chips. Cheers, Warren From imp at bsdimp.com Thu Apr 12 12:22:58 2018 From: imp at bsdimp.com (Warner Losh) Date: Wed, 11 Apr 2018 20:22:58 -0600 Subject: [TUHS] Minor Milestone: Venix 86 "user mode" interpreter Message-ID: Today I reached a minor milestone with my 'Venix restoration project' that I talked about months ago. I ran a Venix 86 binary (sync) to successful completion on my FreeBSD/amd64 box (though none of the code should be too FreeBSD specific). So, I hacked https://github.com/tkchia/reenigne.git to remove the DOS loader and emulator and to add a Venix system call loader and emulator, or at least the start of one. I've also added FP instruction parsing, but it's 100% wrong (it just parses the instructions and does nothing else to decode or implement them). With this, I'm able to load OMAGIC binaries from the extant venix 86 distributions and run them. The only one that runs successfully is sync() since I've not yet implemented argument passing or any of the other 58 system calls :). NMAGIC should be pretty quick after this. This is but a step on the road to getting the Venix compiler running so I can see how much of the system I can recreate from the v7 and other sources that are on TUHS. Not sure who, if anybody, cares about this stuff. I thought people here might be interested. I've pushed the results to https://github.com/bsdimp/venix if you care. This program is in the tools/86sim directory. There's also a doc directory where I document the Venix 86 ABI, as well as doing a very deep-dive into a disassembled /bin/sync to discover what I can from it (turns out, it's quite a lot). So, I thought I'd share this here. Don't know if anybody else is interested, but you never know until you tell people about stuff... Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From nw at retrocomputingtasmania.com Thu Apr 12 13:30:43 2018 From: nw at retrocomputingtasmania.com (Nigel Williams) Date: Thu, 12 Apr 2018 13:30:43 +1000 Subject: [TUHS] Minor Milestone: Venix 86 "user mode" interpreter In-Reply-To: References: Message-ID: On Thu, Apr 12, 2018 at 12:22 PM, Warner Losh wrote: > So, I thought I'd share this here. Don't know if anybody else is interested, > but you never know until you tell people about stuff... Definitely glad to see efforts to reverse-engineer this software. For the curious there is a good walk-through of Venix/86 2.1 being installed here on the MESS emulator: https://virtuallyfun.superglobalmegacorp.com/2015/08/14/venturcomm-venix86-on-messmame/ Has anyone established whether all the various Venix releases have been found and which of the add-on tools have been found? like the Fortran and RM/COBOL referenced on wikipedia? https://en.wikipedia.org/wiki/Venix From imp at bsdimp.com Thu Apr 12 14:23:26 2018 From: imp at bsdimp.com (Warner Losh) Date: Wed, 11 Apr 2018 22:23:26 -0600 Subject: [TUHS] Minor Milestone: Venix 86 "user mode" interpreter In-Reply-To: References: Message-ID: On Wed, Apr 11, 2018 at 9:30 PM, Nigel Williams < nw at retrocomputingtasmania.com> wrote: > On Thu, Apr 12, 2018 at 12:22 PM, Warner Losh wrote: > > So, I thought I'd share this here. Don't know if anybody else is > interested, > > but you never know until you tell people about stuff... > > Definitely glad to see efforts to reverse-engineer this software. > Cool... > For the curious there is a good walk-through of Venix/86 2.1 being > installed here on the MESS emulator: > > https://virtuallyfun.superglobalmegacorp.com/2015/ > 08/14/venturcomm-venix86-on-messmame/ Yea, this is where I got the XT version that's in my repo :) I've been working with the Rainbow mess emulator author to get the Rainbow version working.. Has anyone established whether all the various Venix releases have > been found and which of the add-on tools have been found? like the > Fortran and RM/COBOL referenced on wikipedia? > > https://en.wikipedia.org/wiki/Venix > I have none of them. I just have Venix... I'd love to see them... Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From jim at deitygraveyard.com Thu Apr 12 14:52:29 2018 From: jim at deitygraveyard.com (Jim Carpenter) Date: Thu, 12 Apr 2018 00:52:29 -0400 Subject: [TUHS] Minor Milestone: Venix 86 "user mode" interpreter In-Reply-To: References: Message-ID: <455da14d-3d14-82a3-3d4f-b0716f4a3b5c@deitygraveyard.com> On 04/11/2018 11:30 PM, Nigel Williams wrote: > For the curious there is a good walk-through of Venix/86 2.1 being > installed here on the MESS emulator: > > https://virtuallyfun.superglobalmegacorp.com/2015/08/14/venturcomm-venix86-on-messmame/ > I'm the one that wrote that walk-through. The challenge was very frustrating because MESS didn't/doesn't allow double-density media in high-density drives and the images I had to work with were a mix of both. Also, the one bootable image supported only one floppy drive and had no mknod. But I did win $100 for being the first to get it to compile and run a certain program. Yay! Back in the day I had always wanted Venix so it was nice finally getting to do something with it and make money doing it. Jim From mutiny.mutiny at rediffmail.com Thu Apr 12 18:10:38 2018 From: mutiny.mutiny at rediffmail.com (Mutiny) Date: 12 Apr 2018 08:10:38 -0000 Subject: [TUHS] =?utf-8?q?Minor_Milestone=3A_Venix_86_=22user_mode=22_inte?= =?utf-8?q?rpreter?= In-Reply-To: Message-ID: <1523499834.S.9518.22890.f5-147-235.1523520638.13994@webmail.rediffmail.com> Great! Thanks a lot! -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Thu Apr 12 23:22:24 2018 From: imp at bsdimp.com (Warner Losh) Date: Thu, 12 Apr 2018 07:22:24 -0600 Subject: [TUHS] Minor Milestone: Venix 86 "user mode" interpreter In-Reply-To: <455da14d-3d14-82a3-3d4f-b0716f4a3b5c@deitygraveyard.com> References: <455da14d-3d14-82a3-3d4f-b0716f4a3b5c@deitygraveyard.com> Message-ID: On Wed, Apr 11, 2018 at 10:52 PM, Jim Carpenter wrote: > On 04/11/2018 11:30 PM, Nigel Williams wrote: > > For the curious there is a good walk-through of Venix/86 2.1 being > > installed here on the MESS emulator: > > > > https://virtuallyfun.superglobalmegacorp.com/2015/ > 08/14/venturcomm-venix86-on-messmame/ > > > > > I'm the one that wrote that walk-through. The challenge was very > frustrating because MESS didn't/doesn't allow double-density media in > high-density drives and the images I had to work with were a mix of > both. Also, the one bootable image supported only one floppy drive and > had no mknod. But I did win $100 for being the first to get it to > compile and run a certain program. Yay! Back in the day I had always > wanted Venix so it was nice finally getting to do something with it and > make money doing it. > Yea, in my tools directory, there's a venixp2l.c that makes the diskettes into tarballs effectively. Though I never have figured out how to convert the /dev entries to proper c or b device nodes. It was quite helpful, because this image had low.s in it, which I didn't have yet :) Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Fri Apr 13 07:47:12 2018 From: dave at horsfall.org (Dave Horsfall) Date: Fri, 13 Apr 2018 07:47:12 +1000 (EST) Subject: [TUHS] RIP Robert Taylor Message-ID: We lost Robert Taylor, computer scientist and Internet pioneer, on this day in 2017. Amongst other things, he helped invent the mouse, pioneered computer communications leading up to ARPAnet, developed the computer science lab at Xerox... -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From stewart at serissa.com Fri Apr 13 09:33:08 2018 From: stewart at serissa.com (Lawrence Stewart) Date: Thu, 12 Apr 2018 19:33:08 -0400 Subject: [TUHS] RIP Robert Taylor In-Reply-To: References: Message-ID: Here’s the obit I wrote at the time. http://larry.stewart.org/2017/04/14/bob-taylor/ -Larry -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Fri Apr 13 10:26:00 2018 From: dave at horsfall.org (Dave Horsfall) Date: Fri, 13 Apr 2018 10:26:00 +1000 (EST) Subject: [TUHS] RIP Robert Taylor In-Reply-To: References: Message-ID: On Thu, 12 Apr 2018, Lawrence Stewart wrote: > Here’s the obit I wrote at the time. > http://larry.stewart.org/2017/04/14/bob-taylor/ Many thanks! I love this bit: At Xerox, the weekly group meetings were called Dealer, as in Dealer’s choice. The speaker set the rules. The culture was for the audience to do their level best to challenge the ideas. Bob talked about civility, and about the necessity of “turning type one disagreements into type two disagreements”. A type two disagreement is where each party understands and can explain the position of the other. We can all learn something from that... -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From lm at mcvoy.com Fri Apr 13 10:33:18 2018 From: lm at mcvoy.com (Larry McVoy) Date: Thu, 12 Apr 2018 17:33:18 -0700 Subject: [TUHS] RIP Robert Taylor In-Reply-To: References: Message-ID: <20180413003318.GJ25467@mcvoy.com> On Fri, Apr 13, 2018 at 10:26:00AM +1000, Dave Horsfall wrote: > On Thu, 12 Apr 2018, Lawrence Stewart wrote: > > >Here???s the obit I wrote at the time. > >http://larry.stewart.org/2017/04/14/bob-taylor/ > > Many thanks! I love this bit: > > At Xerox, the weekly group meetings were called Dealer, as in Dealer???s > choice. The speaker set the rules. The culture was for the audience > to do their level best to challenge the ideas. Bob talked about > civility, and about the necessity of ???turning type one disagreements > into type two disagreements???. A type two disagreement is where each > party understands and can explain the position of the other. > > We can all learn something from that... Indeed. The part about fishing the recording out of the core dump was cool too. Thanks for that obit Larry, nicely done! From dave at horsfall.org Sun Apr 15 08:00:30 2018 From: dave at horsfall.org (Dave Horsfall) Date: Sun, 15 Apr 2018 08:00:30 +1000 (EST) Subject: [TUHS] RIP Dick Hustvedt Message-ID: We lost software engineer Dick Hustvedt on this day in 2008, following severe injuries in a vehicle accident. He contributed much to RSX-11 and VMS, including the infamous "microfortnight" and the SD730 Fixed Head Solar Horologue. An obituary of him can be found at http://software.intel.com/en-us/blogs/2008/04/23/dick-hustvedt-the-consummate-software-engineer/ (and it's worth reading). -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From clemc at ccc.com Mon Apr 16 04:56:27 2018 From: clemc at ccc.com (Clem Cole) Date: Sun, 15 Apr 2018 14:56:27 -0400 Subject: [TUHS] RIP Dick Hustvedt In-Reply-To: References: Message-ID: On Sat, Apr 14, 2018 at 6:00 PM, Dave Horsfall wrote: > We lost software engineer Dick Hustvedt on this day in 2008, following > severe injuries in a vehicle accident. He contributed much to RSX-11 and > VMS, including the infamous "microfortnight" and the SD730 Fixed Head Solar > Horologue. An obituary of him can be found at > http://software.intel.com/en-us/blogs/2008/04/23/dick-hustve > dt-the-consummate-software-engineer/ (and it's worth reading). ​Indeed a real character, but a true gentleman. I don't think I ever saw him lose it, although I'm told he did once; and then kicked himself for a few days because he swore he was never going to let Culter get to him. But as much as I respect both Dave and Dick, the less well known is the late Roger Gourd that had the magic of getting the best of all of us. Roger was the really one of the first truly professional SW managers in the business. And I point out that the most successful projects I've seen developed, somehow Roger got the best people (like Dick) to implement them; but Roger got them shipped. Clem ​ ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From doug at cs.dartmouth.edu Fri Apr 20 10:56:01 2018 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Thu, 19 Apr 2018 20:56:01 -0400 Subject: [TUHS] [GROFF] groff as a asis for comprehensive documentation Message-ID: <201804200056.w3K0u1Rj030182@coolidge.cs.Dartmouth.EDU> Ingo wrote: > i have been working hard to reduce the number of options of low usefulness Ah, soothing classical Unix Musik, so rare in the cacophonous Linux era. Doug From drb at msu.edu Fri Apr 20 11:24:59 2018 From: drb at msu.edu (Dennis Boone) Date: Thu, 19 Apr 2018 21:24:59 -0400 Subject: [TUHS] MRS database software ca. 1979 Message-ID: <20180420012459.1C07EA584E9@yagi.h-net.msu.edu> Does anyone know if UToronto's MRS database system (from about 1979) has survived? It was described in: Robert Hudyma, John Kornatowski, Ivor Ladd. MRS: A microcomputer database management system. Proceedings of the 1981 ACM SIGSMALL symposium on Small systems and SIGMOD workshop on Small database systems, pp 174-180. Apparently it was distributed to over 50 unix sites. This is the software which became the MISTRESS and later EMPRESS products. De From lyndon at orthanc.ca Fri Apr 20 11:42:05 2018 From: lyndon at orthanc.ca (Lyndon Nerenberg) Date: Thu, 19 Apr 2018 18:42:05 -0700 (PDT) Subject: [TUHS] MRS database software ca. 1979 In-Reply-To: <20180420012459.1C07EA584E9@yagi.h-net.msu.edu> References: <20180420012459.1C07EA584E9@yagi.h-net.msu.edu> Message-ID: > Does anyone know if UToronto's MRS database system (from about 1979) has > survived? [...] > Apparently it was distributed to over 50 unix sites. This is the > software which became the MISTRESS and later EMPRESS products. Memories of running Mistress/Empress under CTIX come flooding back ... Back in the day (circa 1987) I recall Henry Spencer was going out with a woman who worked at Rhodnius (what that the name? it's been a while) on the commercial product. While Henry has vanished from the face of the Earth (it seems), Geoff Collyer might recall who she was, or maybe have pointers/links to others who worked on the code. --lyndon From lyndon at orthanc.ca Fri Apr 20 13:23:07 2018 From: lyndon at orthanc.ca (Lyndon Nerenberg) Date: Thu, 19 Apr 2018 20:23:07 -0700 (PDT) Subject: [TUHS] CTIX Provenance Message-ID: The recent Empress and earlier PC[67]300 conversations have churned my failing memory to catch up on the CTIX versions I ran throughout the 1980s. I (sort of) remember 5.x and 6.x as being the releases we faced. The 5.x ones were derived from SVR1 IIRC. When 6.x arrived, SVR2+ was the order of the day, but I don't recall much or anything of SVR3 creeping in. Certainly no RFS or the like. And Convergent wasn't shy about letting bits of Berkeley code sneak in when that made sense. I think the UUCP code got a significant update between 5 and 6. Didn't the 5.x uucico have the "window > 3 == core dump" bug? By 6.x I recall it grew 'G' protocol (at least). Any ex-Convergent hacks on the list who can fill in the blanks? --lyndon From lyndon at orthanc.ca Fri Apr 20 13:43:46 2018 From: lyndon at orthanc.ca (Lyndon Nerenberg) Date: Thu, 19 Apr 2018 20:43:46 -0700 (PDT) Subject: [TUHS] CTIX Provenance In-Reply-To: References: Message-ID: > I think the UUCP code got a significant update between 5 and 6. Didn't the > 5.x uucico have the "window > 3 == core dump" bug? Or maybe I'm thinking of binary patching uucico to open the window up to 7, and cutting off our Xenix UUCP peers, where that bug pervaded. If you didn't have a BSD or HDB source license, you were stuck with the worst of all possible uucico implementations in those days ... :-P --lyndon From arnold at skeeve.com Fri Apr 20 17:49:35 2018 From: arnold at skeeve.com (arnold at skeeve.com) Date: Fri, 20 Apr 2018 01:49:35 -0600 Subject: [TUHS] MRS database software ca. 1979 In-Reply-To: References: <20180420012459.1C07EA584E9@yagi.h-net.msu.edu> Message-ID: <201804200749.w3K7nZwj025746@freefriends.org> Lyndon Nerenberg wrote: > While Henry has vanished from the face of the Earth (it seems), He's still alive and well; at hspencer at utias-sfl.net if anyone needs to find him. His zoo.utoronto.ca address is gone for good, though. Arnold From dave at horsfall.org Fri Apr 20 18:00:41 2018 From: dave at horsfall.org (Dave Horsfall) Date: Fri, 20 Apr 2018 18:00:41 +1000 (EST) Subject: [TUHS] MRS database software ca. 1979 In-Reply-To: <201804200749.w3K7nZwj025746@freefriends.org> References: <20180420012459.1C07EA584E9@yagi.h-net.msu.edu> <201804200749.w3K7nZwj025746@freefriends.org> Message-ID: On Fri, 20 Apr 2018, arnold at skeeve.com wrote: > He's still alive and well; at hspencer at utias-sfl.net if anyone needs to > find him. His zoo.utoronto.ca address is gone for good, though. So he's still at U Toronto, then? I met him once, when he was in Sydney visiting his sister[*], and he was a thoroughly nice chap. [*] You knocked on the door, and were asked for a password (which to my knowledge was never distributed!); I responded with "SunOS-ish (adj): requiring 32-bit bug numbers" and was granted admittance :-) -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From ches at cheswick.com Fri Apr 20 19:09:18 2018 From: ches at cheswick.com (ches@Cheswick.com) Date: Fri, 20 Apr 2018 05:09:18 -0400 Subject: [TUHS] [GROFF] groff as a asis for comprehensive documentation In-Reply-To: <201804200056.w3K0u1Rj030182@coolidge.cs.Dartmouth.EDU> References: <201804200056.w3K0u1Rj030182@coolidge.cs.Dartmouth.EDU> Message-ID: <1215E4AB-4601-4E1F-A8C5-FE0239321027@cheswick.com> > Ah, soothing classical Unix Musik, so rare in the cacophonous Linux era. I understand Linus is actually removing code from his kernel in the next release. It’s a little of what it needs a lot of. From dave at horsfall.org Fri Apr 20 19:13:24 2018 From: dave at horsfall.org (Dave Horsfall) Date: Fri, 20 Apr 2018 19:13:24 +1000 (EST) Subject: [TUHS] [GROFF] groff as a asis for comprehensive documentation In-Reply-To: <1215E4AB-4601-4E1F-A8C5-FE0239321027@cheswick.com> References: <201804200056.w3K0u1Rj030182@coolidge.cs.Dartmouth.EDU> <1215E4AB-4601-4E1F-A8C5-FE0239321027@cheswick.com> Message-ID: On Fri, 20 Apr 2018, ches at Cheswick.com wrote: >> Ah, soothing classical Unix Musik, so rare in the cacophonous Linux >> era. > > I understand Linus is actually removing code from his kernel in the next > release. It’s a little of what it needs a lot of. I've often referred to Linux as "The Windows of the Unix world". -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From ca6c at bitmessage.ch Fri Apr 20 20:44:03 2018 From: ca6c at bitmessage.ch (=?iso-8859-1?B?Q+Fn?=) Date: Fri, 20 Apr 2018 10:44:03 +0000 Subject: [TUHS] [GROFF] groff as a asis for comprehensive documentation In-Reply-To: References: <201804200056.w3K0u1Rj030182@coolidge.cs.Dartmouth.EDU> <1215E4AB-4601-4E1F-A8C5-FE0239321027@cheswick.com> Message-ID: <20180420104403.GA5799@alpine.my.domain> Dave Horsfall wrote: > I've often referred to Linux as "The Windows of the Unix world". I wonder what operating systems people on this list use. AIX? BSD variants? Or maybe even IRIX? Also, OSX is "the Windows of the Unix world". -- caóc From david at collantes.us Fri Apr 20 22:07:02 2018 From: david at collantes.us (David Collantes) Date: Fri, 20 Apr 2018 08:07:02 -0400 Subject: [TUHS] [GROFF] groff as a asis for comprehensive documentation In-Reply-To: <20180420104403.GA5799@alpine.my.domain> References: <201804200056.w3K0u1Rj030182@coolidge.cs.Dartmouth.EDU> <1215E4AB-4601-4E1F-A8C5-FE0239321027@cheswick.com> <20180420104403.GA5799@alpine.my.domain> Message-ID: On 20 April 2018 at 06:44, Cág wrote: [...] > Also, OSX is "the Windows of the Unix world". Hey, I take this as an offense! ^_^ -- David Collantes +1-407-484-7171 -------------- next part -------------- An HTML attachment was scrubbed... URL: From chet.ramey at case.edu Fri Apr 20 23:13:25 2018 From: chet.ramey at case.edu (Chet Ramey) Date: Fri, 20 Apr 2018 09:13:25 -0400 Subject: [TUHS] [GROFF] groff as a asis for comprehensive documentation In-Reply-To: <20180420104403.GA5799@alpine.my.domain> References: <201804200056.w3K0u1Rj030182@coolidge.cs.Dartmouth.EDU> <1215E4AB-4601-4E1F-A8C5-FE0239321027@cheswick.com> <20180420104403.GA5799@alpine.my.domain> Message-ID: <722379ce-6a0b-5941-a14d-bac8eb9c85ad@case.edu> On 4/20/18 6:44 AM, Cág wrote: > Dave Horsfall wrote: > >> I've often referred to Linux as "The Windows of the Unix world". > > I wonder what operating systems people on this list use. AIX? BSD > variants? Or maybe even IRIX? I bet you'll find that many of us use Mac OS X on Apple hardware. -- ``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 tfb at tfeb.org Sat Apr 21 00:59:09 2018 From: tfb at tfeb.org (Tim Bradshaw) Date: Fri, 20 Apr 2018 15:59:09 +0100 Subject: [TUHS] [GROFF] groff as a asis for comprehensive documentation In-Reply-To: <201804200056.w3K0u1Rj030182@coolidge.cs.Dartmouth.EDU> References: <201804200056.w3K0u1Rj030182@coolidge.cs.Dartmouth.EDU> Message-ID: <7A1261AB-BEC3-4E3A-974F-81F14920DDC6@tfeb.org> On 20 Apr 2018, at 01:56, Doug McIlroy wrote: > > Ah, soothing classical Unix Musik, so rare in the cacophonous Linux era. The problem is that 'rarely used options of limited usefulness' can mean two things: options which no-one finds useful and options which only a small number of people find very useful. It is Not Funny when people decide to remove some option which not many people used but on which some critical bit of software you rely on turns out to depend. I think the canonical example of that in my experience was echo -n and certain shell scripts which may or may not have edited passwd files, in the transition from BSDoid SunOS to SYSVoid SunOS. I remember that being very much not funny. (Note I don't want to start a big argument about this, I just think it's a bit more nuanced than the minimalists sometimes think.) -------------- next part -------------- An HTML attachment was scrubbed... URL: From tfb at tfeb.org Sat Apr 21 01:02:04 2018 From: tfb at tfeb.org (Tim Bradshaw) Date: Fri, 20 Apr 2018 16:02:04 +0100 Subject: [TUHS] /dev/drum Message-ID: <8225C5DB-27BD-464E-930A-522C30C20EBD@tfeb.org> I am sure I remember a machine which had this (which would have been running a BSD 4.2 port). Is my memory right, and what was it for (something related to swap?)? It is stupidly hard to search for (or, alternatively, there are just no hits and the memory is false). --tim From clemc at ccc.com Sat Apr 21 01:58:54 2018 From: clemc at ccc.com (Clem Cole) Date: Fri, 20 Apr 2018 11:58:54 -0400 Subject: [TUHS] /dev/drum In-Reply-To: <8225C5DB-27BD-464E-930A-522C30C20EBD@tfeb.org> References: <8225C5DB-27BD-464E-930A-522C30C20EBD@tfeb.org> Message-ID: Yes - its the name of the paging device for the system. It allowed interleaved paging across multiple disk drives, so you could see and indirect look driver to multiple drives. It should be in section 4 of the BSD manual ᐧ On Fri, Apr 20, 2018 at 11:02 AM, Tim Bradshaw wrote: > I am sure I remember a machine which had this (which would have been > running a BSD 4.2 port). Is my memory right, and what was it for > (something related to swap?)? > > It is stupidly hard to search for (or, alternatively, there are just no > hits and the memory is false). > > --tim -------------- next part -------------- An HTML attachment was scrubbed... URL: From david at collantes.us Sat Apr 21 02:00:36 2018 From: david at collantes.us (David Collantes) Date: Fri, 20 Apr 2018 12:00:36 -0400 Subject: [TUHS] /dev/drum In-Reply-To: <8225C5DB-27BD-464E-930A-522C30C20EBD@tfeb.org> References: <8225C5DB-27BD-464E-930A-522C30C20EBD@tfeb.org> Message-ID: <25A1FED0-4F8B-408F-B27B-5728C649D8BE@collantes.us> I found a Wikipedia[0] entry for it. [0] https://en.m.wikipedia.org/wiki/Drum_memory -- David Collantes +1-407-484-7171 > On Apr 20, 2018, at 11:02, Tim Bradshaw wrote: > > I am sure I remember a machine which had this (which would have been running a BSD 4.2 port). Is my memory right, and what was it for (something related to swap?)? > > It is stupidly hard to search for (or, alternatively, there are just no hits and the memory is false). > > --tim -------------- next part -------------- An HTML attachment was scrubbed... URL: From krewat at kilonet.net Sat Apr 21 02:00:49 2018 From: krewat at kilonet.net (Arthur Krewat) Date: Fri, 20 Apr 2018 12:00:49 -0400 Subject: [TUHS] [GROFF] groff as a asis for comprehensive documentation In-Reply-To: <20180420104403.GA5799@alpine.my.domain> References: <201804200056.w3K0u1Rj030182@coolidge.cs.Dartmouth.EDU> <1215E4AB-4601-4E1F-A8C5-FE0239321027@cheswick.com> <20180420104403.GA5799@alpine.my.domain> Message-ID: As a workstation, Windows. As a server, Solaris 11.x (for the time being). On 4/20/2018 6:44 AM, Cág wrote: > Dave Horsfall wrote: > >> I've often referred to Linux as "The Windows of the Unix world". > I wonder what operating systems people on this list use. AIX? BSD > variants? Or maybe even IRIX? > > Also, OSX is "the Windows of the Unix world". > > -- > caóc > > From crossd at gmail.com Sat Apr 21 02:12:28 2018 From: crossd at gmail.com (Dan Cross) Date: Fri, 20 Apr 2018 12:12:28 -0400 Subject: [TUHS] /dev/drum In-Reply-To: <25A1FED0-4F8B-408F-B27B-5728C649D8BE@collantes.us> References: <8225C5DB-27BD-464E-930A-522C30C20EBD@tfeb.org> <25A1FED0-4F8B-408F-B27B-5728C649D8BE@collantes.us> Message-ID: That's a bit different. It's possible that some early Unix machines had actual drum devices for storage or swap (did any of them?), but the /dev/drum device is what Clem says it was. It's funny, I just happened across this a couple of days ago when I went looking for the `hier.7` man page from 4.4BSD-Lite2: https://www.freebsd.org/cgi/man.cgi?query=hier&apropos=0&sektion=7&manpath=4.4BSD+Lite2&arch=default&format=html It refers to this: https://www.freebsd.org/cgi/man.cgi?query=drum&sektion=4&apropos=0&manpath=4.4BSD+Lite2 The claim is that it came from 3.0BSD. Why was it called drum? I imagine that's historical license coupled with grad student imagination, but I'm curious if it has origin in actual hardware used at UC Berkeley. Clem, that was roughly your era, was it not? - Dan C. On Fri, Apr 20, 2018 at 12:00 PM, David Collantes wrote: > I found a Wikipedia[0] entry for it. > > [0] https://en.m.wikipedia.org/wiki/Drum_memory > > > -- > David Collantes > +1-407-484-7171 > > On Apr 20, 2018, at 11:02, Tim Bradshaw wrote: > > I am sure I remember a machine which had this (which would have been > running a BSD 4.2 port). Is my memory right, and what was it for > (something related to swap?)? > > It is stupidly hard to search for (or, alternatively, there are just no > hits and the memory is false). > > --tim > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Sat Apr 21 02:21:07 2018 From: clemc at ccc.com (Clem Cole) Date: Fri, 20 Apr 2018 12:21:07 -0400 Subject: [TUHS] /dev/drum In-Reply-To: References: <8225C5DB-27BD-464E-930A-522C30C20EBD@tfeb.org> <25A1FED0-4F8B-408F-B27B-5728C649D8BE@collantes.us> Message-ID: On Fri, Apr 20, 2018 at 12:12 PM, Dan Cross wrote: > That's a bit different. It's possible that some early Unix machines had > actual drum devices for storage or swap (did any of them?), but the > /dev/drum device is what Clem says it was. > > It's funny, I just happened across this a couple of days ago when I went > looking for the `hier.7` man page from 4.4BSD-Lite2: > > https://www.freebsd.org/cgi/man.cgi?query=hier&apropos=0&sek > tion=7&manpath=4.4BSD+Lite2&arch=default&format=html > > It refers to this: https://www.freebsd.org/cgi/man.cgi?query=drum&sektion > =4&apropos=0&manpath=4.4BSD+Lite2 > > The claim is that it came from 3.0BSD. > ​yes - I believe that is true,​ I just looked at a 4.1 manual it 's definitely there, > ​​ > Why was it called drum? > ​wnj was being 'cute' -- drum's were historically ​the device large systems paged too. So people understood the reference at the time. > I imagine that's historical license coupled with grad student imagination, > but I'm curious if it has origin in actual hardware used at UC Berkeley. > Clem, that was roughly your era, was it not? > ​Yes - very much my era, Clem​ ᐧ ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Sat Apr 21 02:33:04 2018 From: imp at bsdimp.com (Warner Losh) Date: Fri, 20 Apr 2018 10:33:04 -0600 Subject: [TUHS] /dev/drum In-Reply-To: References: <8225C5DB-27BD-464E-930A-522C30C20EBD@tfeb.org> <25A1FED0-4F8B-408F-B27B-5728C649D8BE@collantes.us> Message-ID: On Fri, Apr 20, 2018 at 10:12 AM, Dan Cross wrote: > That's a bit different. It's possible that some early Unix machines had > actual drum devices for storage or swap (did any of them?), but the > /dev/drum device is what Clem says it was. > > It's funny, I just happened across this a couple of days ago when I went > looking for the `hier.7` man page from 4.4BSD-Lite2: > > https://www.freebsd.org/cgi/man.cgi?query=hier&apropos=0& > sektion=7&manpath=4.4BSD+Lite2&arch=default&format=html > > It refers to this: https://www.freebsd.org/cgi/man.cgi?query=drum& > sektion=4&apropos=0&manpath=4.4BSD+Lite2 > > The claim is that it came from 3.0BSD. Why was it called drum? I imagine > that's historical license coupled with grad student imagination, but I'm > curious if it has origin in actual hardware used at UC Berkeley. Clem, that > was roughly your era, was it not? > http://www.tuhs.org/cgi-bin/utree.pl?file=3BSD/usr/src/sys/sys/vmdrum.c So there's something called drum in 3BSD. Haven't chased down the MAKEDEV and config glue to turn it into /dev/drum, but it's enough to support the 'It originated in 3BSD'. It certainly wasn't in 32V since that had no paging. This was 1980. Drum memory stopped being a new thing in the early 70's. So it was just recently obsolete. But its typical use was a very small, but very fast, hard drive to swap things to. There never was a drum device, at least a commercial, non-lab experiment, for the VAXen. They all swapped to spinning disks by then. Warner - Dan C. > > > On Fri, Apr 20, 2018 at 12:00 PM, David Collantes > wrote: > >> I found a Wikipedia[0] entry for it. >> >> [0] https://en.m.wikipedia.org/wiki/Drum_memory >> >> >> -- >> David Collantes >> +1-407-484-7171 >> >> On Apr 20, 2018, at 11:02, Tim Bradshaw wrote: >> >> I am sure I remember a machine which had this (which would have been >> running a BSD 4.2 port). Is my memory right, and what was it for >> (something related to swap?)? >> >> It is stupidly hard to search for (or, alternatively, there are just no >> hits and the memory is false). >> >> --tim >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnc at mercury.lcs.mit.edu Sat Apr 21 02:45:50 2018 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Fri, 20 Apr 2018 12:45:50 -0400 (EDT) Subject: [TUHS] /dev/drum Message-ID: <20180420164550.78CFC18C088@mercury.lcs.mit.edu> > From: Warner Losh > Drum memory stopped being a new thing in the early 70's. Mid 60's. Fixed-head disks replaced them - same basic concept, same amount of bits, less physical volume. Those lasted until the late 70's - early PDP-11 Unixes have drivers for the RF11 and RS0x fixed-head disks. The 'fire-hose' drum on the GE 645 Multics was the last one I've heard of. Amusing story about it here: http://www.multicians.org/low-bottle-pressure.html Although reading it, it may not have been (physically) a drum. > There never was a drum device, at least a commercial, non-lab > experiment, for the VAXen. They all swapped to spinning disks by then. s/spinning/non-fixed-head/. Noel From charles.unix.pro at gmail.com Sat Apr 21 02:53:53 2018 From: charles.unix.pro at gmail.com (Charles Anthony) Date: Fri, 20 Apr 2018 09:53:53 -0700 Subject: [TUHS] /dev/drum In-Reply-To: <20180420164550.78CFC18C088@mercury.lcs.mit.edu> References: <20180420164550.78CFC18C088@mercury.lcs.mit.edu> Message-ID: On Fri, Apr 20, 2018 at 9:45 AM, Noel Chiappa wrote: > > From: Warner Losh > > > Drum memory stopped being a new thing in the early 70's. > > Mid 60's. Fixed-head disks replaced them - same basic concept, same amount > of > bits, less physical volume. Those lasted until the late 70's - early PDP-11 > Unixes have drivers for the RF11 and RS0x fixed-head disks. > > The 'fire-hose' drum on the GE 645 Multics was the last one I've heard > of. Amusing story about it here: > > http://www.multicians.org/low-bottle-pressure.html > > Although reading it, it may not have been (physically) a drum. > > Correct; it was a fixed head disk; nicknamed firehose for the high data rate. I am not sure if this is the exact model number, but it was a Librafile device: https://archive.org/stream/TNM_Librafile_3800_mass_memory_from_Librascope_-__20170825_0139#page/n0/mode/2up -- Charles -------------- next part -------------- An HTML attachment was scrubbed... URL: From pechter at gmail.com Sat Apr 21 03:16:50 2018 From: pechter at gmail.com (William Pechter) Date: Fri, 20 Apr 2018 13:16:50 -0400 Subject: [TUHS] /dev/drum In-Reply-To: <20180420164550.78CFC18C088@mercury.lcs.mit.edu> References: <20180420164550.78CFC18C088@mercury.lcs.mit.edu> Message-ID: <11795ca0-54f0-9e50-35e7-1df1cec3f017@gmail.com> Noel Chiappa wrote: > > From: Warner Losh > > > Drum memory stopped being a new thing in the early 70's. > > Mid 60's. Fixed-head disks replaced them - same basic concept, same amount of > bits, less physical volume. Those lasted until the late 70's - early PDP-11 > Unixes have drivers for the RF11 and RS0x fixed-head disks. > > The 'fire-hose' drum on the GE 645 Multics was the last one I've heard > of. Amusing story about it here: > > http://www.multicians.org/low-bottle-pressure.html > > Although reading it, it may not have been (physically) a drum. > > > There never was a drum device, at least a commercial, non-lab > > experiment, for the VAXen. They all swapped to spinning disks by then. > > s/spinning/non-fixed-head/. > > Noe Just a note... back in my old DEC days I went around and installed a thing called the ML11-A (IIRC). It was a Massbus box of MK11/MS750 memory arrays interfaced to a disk emulation controller. Plug it on your Massbus, format the memory with the disk formatter and you have something like an RS04 swap device made out of memory with no rotation delay.  Consider it an early SSD. It used plain old PDP/VAX memory (and could format and bad block out ECC errors so the memory didn't have to be perfect) and was software compatible (I think) with the RS04... I installed one at the AT&T/NY Bell site next door to the World Trade Center back in 84-85 or so. I wonder if it was still running on 9/11.  Word was Unix really was improved on the 11/70 boxes without a huge investment on new gear.  Quick swap was a big help on heavily loaded boxes. Loved seeing the diag run tests and light the fault light on the box of memory.  Also had a write protect like every good drive should. Bill -- Digital had it then. Don't you wish you could buy it now! pechter-at-gmail.com http://xkcd.com/705/ From cym224 at gmail.com Sat Apr 21 04:39:53 2018 From: cym224 at gmail.com (Nemo) Date: Fri, 20 Apr 2018 14:39:53 -0400 Subject: [TUHS] MRS database software ca. 1979 In-Reply-To: <201804200749.w3K7nZwj025746@freefriends.org> References: <20180420012459.1C07EA584E9@yagi.h-net.msu.edu> <201804200749.w3K7nZwj025746@freefriends.org> Message-ID: On 20/04/2018, arnold at skeeve.com wrote: > Lyndon Nerenberg wrote: > >> While Henry has vanished from the face of the Earth (it seems), > > He's still alive and well; at hspencer at utias-sfl.net if anyone > needs to find him. His zoo.utoronto.ca address is gone for good, though. (Sigh) I regret never going over to meet him when I was a grad student at Toronto. Zoo was the next building over. I knew of him but it never happened. N. From lm at mcvoy.com Sat Apr 21 04:42:29 2018 From: lm at mcvoy.com (Larry McVoy) Date: Fri, 20 Apr 2018 11:42:29 -0700 Subject: [TUHS] MRS database software ca. 1979 In-Reply-To: References: <20180420012459.1C07EA584E9@yagi.h-net.msu.edu> <201804200749.w3K7nZwj025746@freefriends.org> Message-ID: <20180420184229.GA32371@mcvoy.com> On Fri, Apr 20, 2018 at 02:39:53PM -0400, Nemo wrote: > On 20/04/2018, arnold at skeeve.com wrote: > > Lyndon Nerenberg wrote: > > > >> While Henry has vanished from the face of the Earth (it seems), > > > > He's still alive and well; at hspencer at utias-sfl.net if anyone > > needs to find him. His zoo.utoronto.ca address is gone for good, though. What's he up to? From ron at ronnatalie.com Sat Apr 21 05:17:55 2018 From: ron at ronnatalie.com (Ron Natalie) Date: Fri, 20 Apr 2018 15:17:55 -0400 Subject: [TUHS] /dev/drum In-Reply-To: References: <8225C5DB-27BD-464E-930A-522C30C20EBD@tfeb.org> <25A1FED0-4F8B-408F-B27B-5728C649D8BE@collantes.us> Message-ID: <01ac01d3d8dc$498e65b0$dcab3110$@ronnatalie.com> I don't even remember a drum for any UNIBUS system. We had a RF-11 fixed head disk on our PDP-11/45 and augmented that with a "bulk core" box that looked like the RF-11 to the system as well. Drums were usually fixed head, although those UNIVACers out there will remember the Fastrand drums which had flying head. Massive units looked like 6' lengths of sewer pipe covered in iron oxide. It was sort of the basis of UNIVAC storage units. From clemc at ccc.com Sat Apr 21 06:23:40 2018 From: clemc at ccc.com (Clem Cole) Date: Fri, 20 Apr 2018 16:23:40 -0400 Subject: [TUHS] /dev/drum In-Reply-To: <01ac01d3d8dc$498e65b0$dcab3110$@ronnatalie.com> References: <8225C5DB-27BD-464E-930A-522C30C20EBD@tfeb.org> <25A1FED0-4F8B-408F-B27B-5728C649D8BE@collantes.us> <01ac01d3d8dc$498e65b0$dcab3110$@ronnatalie.com> Message-ID: On Fri, Apr 20, 2018 at 3:17 PM, Ron Natalie wrote: > > Drums were usually fixed head, although those UNIVACers out there will > remember the Fastrand drums which had flying head. Massive units looked > like 6' lengths of sewer pipe covered in iron oxide. > It was sort of the basis of UNIVAC storage units. > ​And big and did I say really *noisy* .... We had 4 of them and they so so noisy CMU partitioned the machine room so they they were by themselves. The CPUs and the operators were on the other side of glass wall. ​I was looking at an old pic of me in the CMU machine room circa '76. You can see console to the 1108 and the top of the door to the 'Fastrand' room (which was also the Vax serial #1 was for space reasons); but unfortunately one of the 360/67's 1Meg memory units (we had 4 - each a was a little larger than Vax 780 cabinet) is in the way, so the drums can not been seen. One thing I'll never forget was when the first time they powered up CMU's first KL10 (which was DEC's first ECL based system). It too was an early unit and DEC Pittsburgh had not been trained on them yet. Unfortunately, the on-site provisioning was mistakenly set up for a KA10, which was horribly insufficient. Well, the tech's blew every circuit breaker in the building - shutting down everything. The emergency lights came on and room was eerily quiet, not a single fan running, but there was this strange humming coming from Fastrand room. There was so much stored energy in the drums, they keep spinning for a very long time. ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Sat Apr 21 07:59:01 2018 From: dave at horsfall.org (Dave Horsfall) Date: Sat, 21 Apr 2018 07:59:01 +1000 (EST) Subject: [TUHS] [GROFF] groff as a asis for comprehensive documentation In-Reply-To: <20180420104403.GA5799@alpine.my.domain> References: <201804200056.w3K0u1Rj030182@coolidge.cs.Dartmouth.EDU> <1215E4AB-4601-4E1F-A8C5-FE0239321027@cheswick.com> <20180420104403.GA5799@alpine.my.domain> Message-ID: On Fri, 20 Apr 2018, Cág wrote: >> I've often referred to Linux as "The Windows of the Unix world". > > I wonder what operating systems people on this list use. AIX? BSD > variants? Or maybe even IRIX? My mail/web server is FreeBSD (of course), which is self-firewalled; that latter task will soon be taken over by OpenBSD (of course). The main client is a MacBook running Sierra (the poxy thing doesn't seem to like High Sierra), as FreeBSD for all its advantages is a piss-poor client. I have images of NetBSD etc lying around somewhere, to try on new boxen. And I keep a tame Debian laptop to see what the penguins have broken on my projects[*]... > Also, OSX is "the Windows of the Unix world". I was calling Linux that a fair while before OSX came along. [*] Just one example: it's 'stty -f ..." on most systems, but "stty -F" on Penguin/OS. Why? -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From dave at horsfall.org Sat Apr 21 08:10:12 2018 From: dave at horsfall.org (Dave Horsfall) Date: Sat, 21 Apr 2018 08:10:12 +1000 (EST) Subject: [TUHS] /dev/drum In-Reply-To: <01ac01d3d8dc$498e65b0$dcab3110$@ronnatalie.com> References: <8225C5DB-27BD-464E-930A-522C30C20EBD@tfeb.org> <25A1FED0-4F8B-408F-B27B-5728C649D8BE@collantes.us> <01ac01d3d8dc$498e65b0$dcab3110$@ronnatalie.com> Message-ID: On Fri, 20 Apr 2018, Ron Natalie wrote: > Drums were usually fixed head, although those UNIVACers out there will > remember the Fastrand drums which had flying head. Massive units looked > like 6' lengths of sewer pipe covered in iron oxide. It was sort of the > basis of UNIVAC storage units. Now you have me remembering (always dangerous)... Our DEC Field Circus gingerbeer mentioned that he had to maintain a drum, whereby the drum itself slid back and forth, and he used to take the female operators to, ahem, view it in action... -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From dave at horsfall.org Sat Apr 21 09:35:42 2018 From: dave at horsfall.org (Dave Horsfall) Date: Sat, 21 Apr 2018 09:35:42 +1000 (EST) Subject: [TUHS] /dev/drum In-Reply-To: <11795ca0-54f0-9e50-35e7-1df1cec3f017@gmail.com> References: <20180420164550.78CFC18C088@mercury.lcs.mit.edu> <11795ca0-54f0-9e50-35e7-1df1cec3f017@gmail.com> Message-ID: On Fri, 20 Apr 2018, William Pechter wrote: > Also had a write protect like every good drive should. Not only that, but I note that my Mac does not have a visible disk-activity indicator; not surprising, really, as it seems to be thrashing like hell whenever I have the temerity to focus (i.e. click) upon another window. Now, my Mac's system disk is external (don't ask), and it has a barely visible blue LED, which is why I know when it thrashes sometimes. I intend to throw together a photo-transistor and a high-efficiency LED (plus a 9v battery) for a more visible "Danger! Will Robinson!" alert. -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From steve at quintile.net Sun Apr 22 21:48:09 2018 From: steve at quintile.net (Steve Simon) Date: Sun, 22 Apr 2018 12:48:09 +0100 Subject: [TUHS] /dev/drum In-Reply-To: References: <20180420164550.78CFC18C088@mercury.lcs.mit.edu> <11795ca0-54f0-9e50-35e7-1df1cec3f017@gmail.com> Message-ID: <4231E0D1-B2BB-4F52-B609-D62E32858191@quintile.net> i remember the interdata i started my unix career on. it had a halt light which was a good indication of cpu inactivity. we planned (though never did) to attach a light dependant resistor a big cap and an old brass meter in a wood and glass case so we could have a measure of “bored” to “thrashed” in true frankinstien’s lab style. happy days -Steve > On 21 Apr 2018, at 00:35, Dave Horsfall wrote: > >> On Fri, 20 Apr 2018, William Pechter wrote: >> >> Also had a write protect like every good drive should. > > Not only that, but I note that my Mac does not have a visible disk-activity indicator; not surprising, really, as it seems to be thrashing like hell whenever I have the temerity to focus (i.e. click) upon another window. > > Now, my Mac's system disk is external (don't ask), and it has a barely visible blue LED, which is why I know when it thrashes sometimes. I intend to throw together a photo-transistor and a high-efficiency LED (plus a 9v battery) for a more visible "Danger! Will Robinson!" alert. > > -- > Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From lars at nocrew.org Mon Apr 23 03:01:16 2018 From: lars at nocrew.org (Lars Brinkhoff) Date: Sun, 22 Apr 2018 17:01:16 +0000 Subject: [TUHS] /dev/drum In-Reply-To: (Dan Cross's message of "Fri, 20 Apr 2018 12:12:28 -0400") References: <8225C5DB-27BD-464E-930A-522C30C20EBD@tfeb.org> <25A1FED0-4F8B-408F-B27B-5728C649D8BE@collantes.us> Message-ID: <7wfu3nuqeb.fsf@junk.nocrew.org> Dan Cross wrote: > Why was it called drum? I imagine that's historical license coupled > with grad student imagination, but I'm curious if it has origin in > actual hardware used at UC Berkeley. Clem, that was roughly your era, > was it not? Seems like the Project Genie 940 at UCB had a drum. Maybe someone wanted to carry the tradition forward. From clemc at ccc.com Mon Apr 23 03:37:27 2018 From: clemc at ccc.com (Clem Cole) Date: Sun, 22 Apr 2018 13:37:27 -0400 Subject: [TUHS] /dev/drum In-Reply-To: <7wfu3nuqeb.fsf@junk.nocrew.org> References: <8225C5DB-27BD-464E-930A-522C30C20EBD@tfeb.org> <25A1FED0-4F8B-408F-B27B-5728C649D8BE@collantes.us> <7wfu3nuqeb.fsf@junk.nocrew.org> Message-ID: On Sun, Apr 22, 2018 at 1:01 PM, Lars Brinkhoff wrote: > Dan Cross wrote: > > Why was it called drum? I imagine that's historical license coupled > > with grad student imagination, but I'm curious if it has origin in > > actual hardware used at UC Berkeley. Clem, that was roughly your era, > > was it not? > > Seems like the Project Genie 940 at UCB had a drum. Maybe someone > wanted to carry the tradition forward. ​The 'someone' in all of this was Bill Joy (wnj).​ As I said, in those days, all of us knew of older systems that used 'paging drums' - it was pretty common term for the hunk-a-storage that the system dedicated to be available to page itself. it really is just like the fact that by the time of the VAX, DEC was not shipping core memories at all (and few 11's shipped with core either as the thanks to Moore's law, the price of semiconductor memory had dropped), so calling the main system memory 'core' was obsolete. Thus, the UNIX term 'core dump' was really meaningless. [In fact, Magic, the OS for the Tektronix Magnolia Machine has 'mos dump' files - because I did that]. But the term 'core file' stuck, tools knew about, as did the programmers. The difference is that todays systems from Windows to UNIX flavors stopped needed a dedicated swapping or paging space and instead was taught to just use empty FS blocks. So today's hacker has grown up without really knowing what /dev/swap or /dev/drum was all about -- in fact that was exactly the question that started this thread. On the other hand, we still 'dump core' and use the core files for debugging. So, while the term 'drum' lost its meaning, 'core file' - might be considered 'quaint' by todays hacker, it still has meaning. Clem ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From norman at oclsc.org Mon Apr 23 04:06:50 2018 From: norman at oclsc.org (Norman Wilson) Date: Sun, 22 Apr 2018 14:06:50 -0400 Subject: [TUHS] /dev/drum Message-ID: <1524420413.188.for-standards-violators@oclsc.org> Clem Cole: On the other hand, we still 'dump core' and use the core files for debugging. So, while the term 'drum' lost its meaning, 'core file' - might be considered 'quaint' by todays hacker, it still has meaning. ==== Just as we still speak of dialling and hanging up the phone, electing Presidents, and other actions long since made obsolete by changes of technology and culture. Norman Wilson Toronto ON From bakul at bitblocks.com Mon Apr 23 05:14:14 2018 From: bakul at bitblocks.com (Bakul Shah) Date: Sun, 22 Apr 2018 12:14:14 -0700 Subject: [TUHS] /dev/drum In-Reply-To: Your message of "Sun, 22 Apr 2018 13:37:27 -0400." References: <8225C5DB-27BD-464E-930A-522C30C20EBD@tfeb.org> <25A1FED0-4F8B-408F-B27B-5728C649D8BE@collantes.us> <7wfu3nuqeb.fsf@junk.nocrew.org> Message-ID: <20180422191421.2BBAB156E510@mail.bitblocks.com> On Sun, 22 Apr 2018 13:37:27 -0400 Clem Cole wrote: > available to page itself. it really is just like the fact that by the > time of the VAX, DEC was not shipping core memories at all (and few 11's > shipped with core either as the thanks to Moore's law, the price of > semiconductor memory had dropped), so calling the main system memory 'core' > was obsolete. Thus, the UNIX term 'core dump' was really meaningless. > [In fact, Magic, the OS for the Tektronix Magnolia Machine has 'mos dump' > files - because I did that]. I have wondered if the word "kernel" got used instead of "core" for the essential part of an OS because core was already in use in relation to memory (and with a different derivation). "kernel" may have been used in this context in the '60s but I don't really know who used it first. From mutiny.mutiny at rediffmail.com Mon Apr 23 06:58:28 2018 From: mutiny.mutiny at rediffmail.com (Mutiny) Date: 22 Apr 2018 20:58:28 -0000 Subject: [TUHS] =?utf-8?q?/dev/drum?= In-Reply-To: Message-ID: <1524418712.S.11552.13927.f5-147-237.1524430708.19815@webmail.rediffmail.com> From: Clem Cole <clemc at ccc.com>Sent: Sun, 22 Apr 2018 23:08:32Thus, the UNIX term 'core dump' was really meaningless.UNIX didn't started in 1978 with the VAX and solid state ram. It started earlier when core was cheaper than ss ram in the dec world which was the case even in '77. Yes there was core, and yes, core dump isn't meaningless at all.... -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Mon Apr 23 07:41:29 2018 From: dave at horsfall.org (Dave Horsfall) Date: Mon, 23 Apr 2018 07:41:29 +1000 (EST) Subject: [TUHS] Happy birthday, Ray Tomlinson! Message-ID: Ray Tomlinson, computer pioneer, was born on this day in 1941. He is credited with inventing this weird thing called "email" on the ARPAnet, in particular the "@" sign to designate a remote host (although some jerk -- his name is not important -- is claiming that he was first). -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From dave at horsfall.org Mon Apr 23 07:51:39 2018 From: dave at horsfall.org (Dave Horsfall) Date: Mon, 23 Apr 2018 07:51:39 +1000 (EST) Subject: [TUHS] /dev/drum In-Reply-To: References: <8225C5DB-27BD-464E-930A-522C30C20EBD@tfeb.org> <25A1FED0-4F8B-408F-B27B-5728C649D8BE@collantes.us> <7wfu3nuqeb.fsf@junk.nocrew.org> Message-ID: On Sun, 22 Apr 2018, Clem Cole wrote: > The difference is that todays systems from Windows to UNIX flavors > stopped needed a dedicated swapping or paging space and instead was > taught to just use empty FS blocks.  So today's hacker has grown up > without really knowing what /dev/swap or /dev/drum was all about -- in > fact that was exactly the question that started this thread.  Heh heh... I remember the day that Basser (SydU) got AUSAM running on their spanking new VAX. It crashed, and it was traced to it swapping for the first time in its life (before that, it merely paged). Now, how many youngsters know the difference between paging and swapping? -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From clemc at ccc.com Mon Apr 23 08:37:31 2018 From: clemc at ccc.com (Clem cole) Date: Sun, 22 Apr 2018 18:37:31 -0400 Subject: [TUHS] /dev/drum In-Reply-To: <1524418712.S.11552.13927.f5-147-237.1524430708.19815@webmail.rediffmail.com> References: <1524418712.S.11552.13927.f5-147-237.1524430708.19815@webmail.rediffmail.com> Message-ID: Im not sure how you got there. I hardly said or implied that Unix started in 78 or on the Vax. I’m fairly aware that Ken had core in his PDP-7, as did many of us (including myself) on our many of PDP-11s in the old times. I started with Fifth and Sixth Edition. Dumping core had meaning to all of us in those days. All I said was that by the time of the VAX - which very much did spread the gospel of Unix to the world - core memory had fallen from favor and widespread use. The PDP11 was the last system DEC released core. BTW if you want to be correct about dates - the DEC released the Vax in 76 not 78 ( I personally used to program Vax serial #1 at CMU under VMS 1.0 before I was at UCB which is what Dan had asked). Also FWIW. Bill and Ozzie whom I knew from my UCB days, did not do the UCB Vax work until a few years later when the UCB EECS Dept got their first Berkeley VAX and Prof Fateman who had come from MIT wanted to run MAC Lisp on it - which very much required VM support. V32 ( the V7 port for the Vax from AT&T) swapped. Bill and Ozzie added paging support which was released as BSD 3.0 (Ozzie graduates and left for Cornell as I recall but where he went is fuzzy in my memory now). Primarily Bill but with the help of us others followed quickly with 4.0 and 4.1 (the later being the first wide spread Vax release) with his Fastvax support. Later still in the early 1980s Bill lead the CRSG team and released 4.1a/b/c. Bill left for Sun and I left for Masscomp. Kirk, Sam and Keith pushed out 4.2 et al to the final NET2 release which was after my time. Of those on the list from UCB which was my time there was also Mary Ann Horton in EECS and Debbie S. who was up the hill at LBL and who both also sometimes reply - I do look to them correct/affirm me for UCB history. But I personally go back in Unix history to the early/mid 1970s at CMU. I often defer to Noel C for memories of networking things which he was a part at MIT from the same time frame. I defer to Doug, Steve and obviously Ken for things at ATT and history before Fifth Edition. Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. > On Apr 22, 2018, at 4:58 PM, Mutiny wrote: > > From: Clem Cole > Sent: Sun, 22 Apr 2018 23:08:32 > Thus, the UNIX term 'core dump' was really meaningless. > UNIX didn't started in 1978 with the VAX and solid state ram. It started earlier when core was cheaper than ss ram in the dec world which was the case even in '77. Yes there was core, and yes, core dump isn't meaningless at all. > ... -------------- next part -------------- An HTML attachment was scrubbed... URL: From blake at mcbride.name Tue Apr 24 01:49:46 2018 From: blake at mcbride.name (Blake McBride) Date: Mon, 23 Apr 2018 10:49:46 -0500 Subject: [TUHS] [GROFF] groff as a asis for comprehensive documentation In-Reply-To: <20180420104403.GA5799@alpine.my.domain> References: <201804200056.w3K0u1Rj030182@coolidge.cs.Dartmouth.EDU> <1215E4AB-4601-4E1F-A8C5-FE0239321027@cheswick.com> <20180420104403.GA5799@alpine.my.domain> Message-ID: I use Linux on the desktop and Linux for my servers. Everything works perfectly. I used Mac for several years but drifted away for the following reasons: 1. Their hardware is the best in the business - but not at 3 times the price! 2. The don't make 17" laptops anymore. 3. OSX is great except for each place they drifted from Unix! 4. I don't like them, essentially, being in cohorts with MS against Linux. (They can compete with Windows in terms of quality, but they can't compete against the Linux price.) 5. I don't like the proprietary nature of their ecosystem. Blake McBride On Fri, Apr 20, 2018 at 5:44 AM, Cág wrote: > Dave Horsfall wrote: > > > I've often referred to Linux as "The Windows of the Unix world". > > I wonder what operating systems people on this list use. AIX? BSD > variants? Or maybe even IRIX? > > Also, OSX is "the Windows of the Unix world". > > -- > caóc > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tfb at tfeb.org Tue Apr 24 02:42:27 2018 From: tfb at tfeb.org (Tim Bradshaw) Date: Mon, 23 Apr 2018 17:42:27 +0100 Subject: [TUHS] /dev/drum In-Reply-To: References: <8225C5DB-27BD-464E-930A-522C30C20EBD@tfeb.org> <25A1FED0-4F8B-408F-B27B-5728C649D8BE@collantes.us> <7wfu3nuqeb.fsf@junk.nocrew.org> Message-ID: <3A18DFEC-42B7-4234-9DD1-367733270D50@tfeb.org> On 22 Apr 2018, at 18:37, Clem Cole wrote: > > But the term 'core file' stuck, tools knew about, as did the programmers. The difference is that todays systems from Windows to UNIX flavors stopped needed a dedicated swapping or paging space and instead was taught to just use empty FS blocks. So today's hacker has grown up without really knowing what /dev/swap or /dev/drum was all about -- in fact that was exactly the question that started this thread. Well, I had known but forgotten in fact. There's also a distinction between whether a system swaps/pages onto a dedicated device and whether it exposes that device by some special name in /dev. Solaris does (or did until fairly recently: I don't remember what the ZFSy systems do) generally use one or more special devices (not usually whole disks but they could be, and it could swap on files but not, I assume, write crash dumps to them) but I'm pretty sure they were not exposed as /dev/ other than the name they would already have in /dev/(r)dsk. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron at ronnatalie.com Tue Apr 24 03:30:01 2018 From: ron at ronnatalie.com (Ron Natalie) Date: Mon, 23 Apr 2018 13:30:01 -0400 Subject: [TUHS] /dev/drum In-Reply-To: <3A18DFEC-42B7-4234-9DD1-367733270D50@tfeb.org> References: <8225C5DB-27BD-464E-930A-522C30C20EBD@tfeb.org> <25A1FED0-4F8B-408F-B27B-5728C649D8BE@collantes.us> <7wfu3nuqeb.fsf@junk.nocrew.org> <3A18DFEC-42B7-4234-9DD1-367733270D50@tfeb.org> Message-ID: <0abe01d3db28$b6573660$2305a320$@ronnatalie.com> Ø Well, I had known but forgotten in fact. There's also a distinction between whether a system swaps/pages onto a dedicated device and whether it exposes that device by some special name in /dev. I’m pretty sure that swapping in V6 took place to a major/minor number configured at kernel build time. You could create a dev node for the swap device, but it wasn’t used for the actual swapping. -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Tue Apr 24 03:51:07 2018 From: clemc at ccc.com (Clem Cole) Date: Mon, 23 Apr 2018 13:51:07 -0400 Subject: [TUHS] /dev/drum In-Reply-To: <0abe01d3db28$b6573660$2305a320$@ronnatalie.com> References: <8225C5DB-27BD-464E-930A-522C30C20EBD@tfeb.org> <25A1FED0-4F8B-408F-B27B-5728C649D8BE@collantes.us> <7wfu3nuqeb.fsf@junk.nocrew.org> <3A18DFEC-42B7-4234-9DD1-367733270D50@tfeb.org> <0abe01d3db28$b6573660$2305a320$@ronnatalie.com> Message-ID: On Mon, Apr 23, 2018 at 1:30 PM, Ron Natalie wrote: > > > > > Ø Well, I had known but forgotten in fact. There's also a distinction > between whether a system swaps/pages onto a dedicated device and whether it > exposes that device by some special name in /dev. > > > > I’m pretty sure that swapping in V6 took place to a major/minor number > configured at kernel build time. You could create a dev node for the swap > device, but it wasn’t used for the actual swapping. > ​Exactly... For instance an RK04 was less that 5K blocks (4620 or some such - I've forgotten the actually amount). The disk was mkfs'ed to the first 4K and the left over was give to the swap system. By the time of 4.X, the RP06 was 'partitioned' into 'rings' (some overlapping). The 'a' partition was root, the 'b' was swap and one fo the others was the rest. Later the 'c' was a short form for copying the entire disk. What /dev/drum did was allow to cobble up those hunks of reserved space and view them as a single device. I've forgotten what user space programs used it, probably some of the tools like ps, vmstat *etc*. You'd have to look that the sources.​ > > > ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron at ronnatalie.com Tue Apr 24 04:30:51 2018 From: ron at ronnatalie.com (Ron Natalie) Date: Mon, 23 Apr 2018 14:30:51 -0400 Subject: [TUHS] /dev/drum In-Reply-To: References: <8225C5DB-27BD-464E-930A-522C30C20EBD@tfeb.org> <25A1FED0-4F8B-408F-B27B-5728C649D8BE@collantes.us> <7wfu3nuqeb.fsf@junk.nocrew.org> <3A18DFEC-42B7-4234-9DD1-367733270D50@tfeb.org> <0abe01d3db28$b6573660$2305a320$@ronnatalie.com> Message-ID: <0af301d3db31$35978800$a0c69800$@ronnatalie.com> RK05’s were 4872 blocks. Don’t know why that number has stuck with me, too many invocations of mkfs I guess. Oddly, DEC software for some reason never used the last 72 blocks. We used to the standalone ROLLIN to make backup copies of our root file system and I remember having to patch the program to make sure it copied all the blocks. Yeah, I remembrer swaplo and swapdev. We actually dedicated a full 1024 block RF11 fixed head to the system in the early days until we got the system of RK05 packs. I remember buying my personal RK05 pack for $75 thinking that was a lot of personal storage (2.4MB!). Amusingly, JHU believe in vol copy for backups. Our 80 Mb drive was divided into multiples of RK05 pack. The root file system was 5x4872 blocks. The main user file sytem was another 5. The rest was divided up into single RK05 size things. I remember writing a standalone volcopy to replace ROLLIN that was called “The Fabulous Amtork” program. The 80M drive was an Ampex. AM to RK, get it. I have no idea when or why the adjective “fabulous” became associated with it but that was what it was always called. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnc at mercury.lcs.mit.edu Tue Apr 24 04:41:22 2018 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Mon, 23 Apr 2018 14:41:22 -0400 (EDT) Subject: [TUHS] /dev/drum Message-ID: <20180423184122.82A0918C07E@mercury.lcs.mit.edu> > From: "Ron Natalie" > I'm pretty sure that swapping in V6 took place to a major/minor number > configured at kernel build time. Yup, in c.c, along with the block/character device switches (which converted major device numbers to routines). > You could create a dev node for the swap device, but it wasn't used for > the actual swapping. Yes. > We actually dedicated a full 1024 block RF11 fixed head to the system in > the early days Speaking of fixed-head disks, one of the Bell systems used (IIRC) an RS04 fixed-head disk for the root. DEC apparently only used that disk for swapping in their OS's... So the DEC diagnsotics felt free to scribble on the disk. So, Field Circus comes in to work on the machine... Ooops! Noel From ca6c at bitmessage.ch Tue Apr 24 04:48:20 2018 From: ca6c at bitmessage.ch (=?iso-8859-1?B?Q+Fn?=) Date: Mon, 23 Apr 2018 18:48:20 +0000 Subject: [TUHS] [GROFF] groff as a asis for comprehensive documentation In-Reply-To: References: <201804200056.w3K0u1Rj030182@coolidge.cs.Dartmouth.EDU> <1215E4AB-4601-4E1F-A8C5-FE0239321027@cheswick.com> <20180420104403.GA5799@alpine.my.domain> Message-ID: <20180423184820.GA9654@netbsd> Dave Horsfall wrote: > I have images of NetBSD etc lying around somewhere, to try on new > boxen. You might want to wait for 8.0, it's supposed it'll be a big release. > Just one example: it's 'stty -f ..." on most systems, but "stty -F" on > Penguin/OS. Why? -f/-F is a nonstandard (i.e. non-POSIX) option. BSDs have -f, GNU Coreutils (and BusyBox, which most of the time copies GNU behaviour) do have -F. Other Unix userlands (IRIX, HP-UX, Heirloom, Solaris(?)) don't have it at all. So, it's not a Penguin OS thing. Cheers! -- caóc From clemc at ccc.com Tue Apr 24 05:09:00 2018 From: clemc at ccc.com (Clem Cole) Date: Mon, 23 Apr 2018 15:09:00 -0400 Subject: [TUHS] /dev/drum In-Reply-To: <20180423184122.82A0918C07E@mercury.lcs.mit.edu> References: <20180423184122.82A0918C07E@mercury.lcs.mit.edu> Message-ID: On Mon, Apr 23, 2018 at 2:41 PM, Noel Chiappa wrote: > Speaking of fixed-head disks, one of the Bell systems used (IIRC) an RS04 > fixed-head disk for the root. DEC apparently only used that disk for > swapping > in their OS's... So the DEC diagnsotics felt free to scribble on the disk. > So, Field Circus comes in to work on the machine... Ooops! > ​teklabs 11/70 the RS04 was /tmp not quite an dangerous as root, but since the fs got wiped out the system would not boot - as it would fail trying to mount /tmp. IIRC the it was the field exerciser that did that by default. I seem to remember that you could configure it to use something else like the field service pack itself or may be not disk at all, but if I remember right if the exerciser found an RS04 it thought it was available by default. So, I had a big sticker on the FS pack that said see me before you loaded it after the first time the service guys took out /tmp. ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From gtaylor at tnetconsulting.net Tue Apr 24 06:47:14 2018 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Mon, 23 Apr 2018 14:47:14 -0600 Subject: [TUHS] /dev/drum In-Reply-To: References: <8225C5DB-27BD-464E-930A-522C30C20EBD@tfeb.org> <25A1FED0-4F8B-408F-B27B-5728C649D8BE@collantes.us> <7wfu3nuqeb.fsf@junk.nocrew.org> <3A18DFEC-42B7-4234-9DD1-367733270D50@tfeb.org> <0abe01d3db28$b6573660$2305a320$@ronnatalie.com> Message-ID: On 04/23/2018 11:51 AM, Clem Cole wrote: > By the time of 4.X, the RP06 was 'partitioned' into 'rings' (some > overlapping). The 'a' partition was root, the 'b' was swap and one fo > the others was the rest. Later the 'c' was a short form for copying > the entire disk. I had always wondered where Solaris (SunOS) got it's use of the different slices, including the slice that was the entire disk from. Now I'm guessing Solaris got it from SunOS which got it from 4.x BSD. -- 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 clemc at ccc.com Tue Apr 24 07:06:23 2018 From: clemc at ccc.com (Clem Cole) Date: Mon, 23 Apr 2018 17:06:23 -0400 Subject: [TUHS] /dev/drum In-Reply-To: References: <8225C5DB-27BD-464E-930A-522C30C20EBD@tfeb.org> <25A1FED0-4F8B-408F-B27B-5728C649D8BE@collantes.us> <7wfu3nuqeb.fsf@junk.nocrew.org> <3A18DFEC-42B7-4234-9DD1-367733270D50@tfeb.org> <0abe01d3db28$b6573660$2305a320$@ronnatalie.com> Message-ID: On Mon, Apr 23, 2018 at 4:47 PM, Grant Taylor via TUHS wrote: > On 04/23/2018 11:51 AM, Clem Cole wrote: > >> By the time of 4.X, the RP06 was 'partitioned' into 'rings' (some >> overlapping). The 'a' partition was root, the 'b' was swap and one fo the >> others was the rest. Later the 'c' was a short form for copying the entire >> disk. >> > > I had always wondered where Solaris (SunOS) got it's use of the different > slices, including the slice that was the entire disk from. > > Now I'm guessing Solaris got it from SunOS which got it from 4.x BSD ​It was not BSD - it was research. It may have been in 6th, but it was definitely in 7th. Cut/pasted from the V7 PDP-11 rp(4) man page: *NAME* rp − RP-11/RP03 moving-head disk *DESCRIPTION* The files rp0 ... rp7 refer to sections of RP disk drive 0. The files rp8 ... rp15 refer to drive 1 etc. This allows a large disk to be broken up into more manageable pieces. The origin and size of the pseudo-disks on each drive are as follows: disk start length 0 0 81000 1 0 5000 2 5000 2000 3 7000 74000 4-7 unassigned Thus rp0 covers the whole drive, while rp1, rp2, rp3 can serve usefully as a root, swap, and mounted user file system respectively. The rp files access the disk via the system’s normal buffering mechanism and may be read and written without regard to physical disk records. There is also a ‘raw’ interface which provides for direct transmission between the disk and the user’s read or write buffer. A single read or write call results in exactly one I/O operation and therefore raw I/O is considerably more efficient when many words are transmitted. The names of the raw RP files begin with rrp and end with a number which selects the same disk section as the corresponding rp file. In raw I/O the buffer must begin on a word boundary.​ ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From danmick at gmail.com Tue Apr 24 07:14:59 2018 From: danmick at gmail.com (Dan Mick) Date: Mon, 23 Apr 2018 14:14:59 -0700 Subject: [TUHS] /dev/drum In-Reply-To: References: <8225C5DB-27BD-464E-930A-522C30C20EBD@tfeb.org> <25A1FED0-4F8B-408F-B27B-5728C649D8BE@collantes.us> <7wfu3nuqeb.fsf@junk.nocrew.org> <3A18DFEC-42B7-4234-9DD1-367733270D50@tfeb.org> <0abe01d3db28$b6573660$2305a320$@ronnatalie.com> Message-ID: <4b95c9f6-0190-be93-7284-d03be289c4ba@gmail.com> On 04/23/2018 02:06 PM, Clem Cole wrote: > > > On Mon, Apr 23, 2018 at 4:47 PM, Grant Taylor via TUHS > > wrote: > > On 04/23/2018 11:51 AM, Clem Cole wrote: > > By the time of 4.X, the RP06 was 'partitioned' into 'rings' > (some overlapping).  The 'a' partition was root, the 'b' was > swap and one fo the others was the rest.  Later the 'c' was a > short form for copying the entire disk. > > > I had always wondered where Solaris (SunOS) got it's use of the > different slices, including the slice that was the entire disk from. > > Now I'm guessing Solaris got it from SunOS which got it from 4.x BSD > > ​It was not BSD - it was research.  It may have been in 6th, but it was > definitely in 7th.  Cut/pasted from the V7 PDP-11 rp(4) man page: > > *NAME* > > rp − RP-11/RP03 moving-head disk > > *DESCRIPTION* > > The files rp0 ... rp7 refer to sections of RP disk drive 0. The > files rp8 ... rp15 refer to drive 1 etc. This > > allows a large disk to be broken up into more manageable pieces. > > The origin and size of the pseudo-disks on each drive are as > follows: > > disk start length > > 0 0 81000 > > 1 0 5000 > > 2 5000 2000 > > 3 7000 74000 > > 4-7 unassigned > > Thus rp0 covers the whole drive, while rp1, rp2, rp3 can serve > usefully as a root, swap, and mounted user > > file system respectively. > > The rp files access the disk via the system’s normal buffering > mechanism and may be read and written > > without regard to physical disk records. There is also a ‘raw’ > interface which provides for direct transmission > > between the disk and the user’s read or write buffer. A single > read or write call results in exactly one > > I/O operation and therefore raw I/O is considerably more > efficient when many words are transmitted. The > > names of the raw RP files begin with rrp and end with a number > which selects the same disk section as the > > corresponding rp file. > > In raw I/O the buffer must begin on a word boundary.​ > > ᐧ But...that has numbers, not letters, and the third partition is not the whole drive, the first one is....? From clemc at ccc.com Tue Apr 24 07:27:29 2018 From: clemc at ccc.com (Clem Cole) Date: Mon, 23 Apr 2018 17:27:29 -0400 Subject: [TUHS] /dev/drum In-Reply-To: <4b95c9f6-0190-be93-7284-d03be289c4ba@gmail.com> References: <8225C5DB-27BD-464E-930A-522C30C20EBD@tfeb.org> <25A1FED0-4F8B-408F-B27B-5728C649D8BE@collantes.us> <7wfu3nuqeb.fsf@junk.nocrew.org> <3A18DFEC-42B7-4234-9DD1-367733270D50@tfeb.org> <0abe01d3db28$b6573660$2305a320$@ronnatalie.com> <4b95c9f6-0190-be93-7284-d03be289c4ba@gmail.com> Message-ID: On Mon, Apr 23, 2018 at 5:14 PM, Dan Mick wrote: > On 04/23/2018 02:06 PM, Clem Cole wrote: > > > > > > On Mon, Apr 23, 2018 at 4:47 PM, Grant Taylor via TUHS > > > wrote: > > > > On 04/23/2018 11:51 AM, Clem Cole wrote: > > > > By the time of 4.X, the RP06 was 'partitioned' into 'rings' > > (some overlapping). The 'a' partition was root, the 'b' was > > swap and one fo the others was the rest. Later the 'c' was a > > short form for copying the entire disk. > > > > > > I had always wondered where Solaris (SunOS) got it's use of the > > different slices, including the slice that was the entire disk from. > > > > Now I'm guessing Solaris got it from SunOS which got it from 4.x BSD > > > > ​It was not BSD - it was research. It may have been in 6th, but it was > > definitely in 7th. Cut/pasted from the V7 PDP-11 rp(4) man page: > > > > *NAME* > > > > rp − RP-11/RP03 moving-head disk > > > > *DESCRIPTION* > > > > The files rp0 ... rp7 refer to sections of RP disk drive 0. The > > files rp8 ... rp15 refer to drive 1 etc. This > > > > allows a large disk to be broken up into more manageable pieces. > > > > The origin and size of the pseudo-disks on each drive are as > > follows: > > > > disk start length > > > > 0 0 81000 > > > > 1 0 5000 > > > > 2 5000 2000 > > > > 3 7000 74000 > > > > 4-7 unassigned > > > > Thus rp0 covers the whole drive, while rp1, rp2, rp3 can serve > > usefully as a root, swap, and mounted user > > > > file system respectively. > > > > The rp files access the disk via the system’s normal buffering > > mechanism and may be read and written > > > > without regard to physical disk records. There is also a ‘raw’ > > interface which provides for direct transmission > > > > between the disk and the user’s read or write buffer. A single > > read or write call results in exactly one > > > > I/O operation and therefore raw I/O is considerably more > > efficient when many words are transmitted. The > > > > names of the raw RP files begin with rrp and end with a number > > which selects the same disk section as the > > > > corresponding rp file. > > > > In raw I/O the buffer must begin on a word boundary.​ > > > > ᐧ > > But...that has numbers, not letters, and the third partition is not the > whole drive, the first one is....? > Yup -- disk were pretty expensive in those days ($20-30K for a <100M drive) so often people did not have more than one. So they started with rp1, rp2 etc.. As disks dropped a little cheaper and having more than one RP06 became possible (RP06 aka IBM 3330 - project Winchester -- was a huge 200M drive - we had 3 on the Teklabs machine and that was considered very, very generous), then letters became the convention used in /dev/. i.e. /dev/{,r}rp0{a,b,c,d..} for each of the minor numbers. To be honest, I really don't remember - but I know we used letters for the different partitions on the 11/70 before BSD showed up. The reason for the partition originally was (and it must have been 6th edition when I first saw it), DEC finally made a disk large enough that number of blocks overflowed a 16 bit integer. So splitting the disk into smaller partitions allowed the original seek(2) to work without overflow. V7 introduced lseek(2) when the offset was a long. Clem ​ ᐧ ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnc at mercury.lcs.mit.edu Tue Apr 24 08:01:11 2018 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Mon, 23 Apr 2018 18:01:11 -0400 (EDT) Subject: [TUHS] /dev/drum Message-ID: <20180423220111.1F99A18C07E@mercury.lcs.mit.edu> > From: Clem Cole > To be honest, I really don't remember - but I know we used letters for > the different partitions on the 11/70 before BSD showed up. In V6 (and probably before that, too), it was numbers: http://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/man/man4/rp.4 So on my machine which had 2 x 50MB CalChomps, with a Diva controller, which we had to split up into two partition each (below), they were dv00, dv01, dv10 and dv11. Letters for the partitions made it easier... > The reason for the partition originally was (and it must have been 6th > edition when I first saw it), DEC finally made a disk large enough that > number of blocks overflowed a 16 bit integer. So splitting the disk > into smaller partitions allowed the original seek(2) to work without > overflow. No, in V6 filesystems, block numbers (in inodes, etc - also the file system size in the superblock) were only 16 bits, so a 50MB disk (100K blocks) had to be split up into partitions to use it all. True of the RP03/04 in V6 too (see the man page above). Noel From tfb at tfeb.org Tue Apr 24 08:07:13 2018 From: tfb at tfeb.org (Tim Bradshaw) Date: Mon, 23 Apr 2018 23:07:13 +0100 Subject: [TUHS] /dev/drum In-Reply-To: References: <8225C5DB-27BD-464E-930A-522C30C20EBD@tfeb.org> <25A1FED0-4F8B-408F-B27B-5728C649D8BE@collantes.us> <7wfu3nuqeb.fsf@junk.nocrew.org> <3A18DFEC-42B7-4234-9DD1-367733270D50@tfeb.org> <0abe01d3db28$b6573660$2305a320$@ronnatalie.com> Message-ID: On 23 Apr 2018, at 21:47, Grant Taylor via TUHS wrote: > I had always wondered where Solaris (SunOS) got it's use of the different slices, including the slice that was the entire disk from. > > Now I'm guessing Solaris got it from SunOS which got it from 4.x BSD. > There is a wonderful Sun cretinism about this. At some recent time (I am not sure how recent but probably mid 2000s), someone worked out that you wanted swap to be at one end of the disk (I think the outside) because on modern disks the data rate changes across the disk and you wanted it at the end with the highest data rate. But lots of things knew that swap was on s1, the second partition. So they changed the default installation tool so the slices of the disk were out of order: s1 was the first, s0 the second, s2 was the whole disk (which it already was) and so on. This was enormously entertaining in a bad way if you made the normal assumption that the slices were in order. There was also (either then or before) some magic needed such that swapping never touched the first n blocks of the disk where the label and boot blocks were, and it was possible to get this wrong so the machine would happily boot, run but would then fail to boot again, usually at a most inconvenient time. And the cretinism was that this was mid 2000s: if you had machine that was paging the answer was to buy more memory not to arrange for faster swap space: it was solving a problem that nobody had any more. From imp at bsdimp.com Tue Apr 24 08:09:47 2018 From: imp at bsdimp.com (Warner Losh) Date: Mon, 23 Apr 2018 16:09:47 -0600 Subject: [TUHS] /dev/drum In-Reply-To: <20180423220111.1F99A18C07E@mercury.lcs.mit.edu> References: <20180423220111.1F99A18C07E@mercury.lcs.mit.edu> Message-ID: On Mon, Apr 23, 2018 at 4:01 PM, Noel Chiappa wrote: > > > No, in V6 filesystems, block numbers (in inodes, etc - also the file system > size in the superblock) were only 16 bits, so a 50MB disk (100K blocks) > had to > be split up into partitions to use it all. True of the RP03/04 in V6 too > (see > the man page above). > Venix 86 2.0 has a daddr_t of 16-bit as well. Venix is V7 based and is limted to 32MB. It looks like the filesystem includes this limitation as well. The winchester driver doesn't have the partitioning trick that the r* drivers form the pdp-11, it seems. Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Tue Apr 24 08:15:05 2018 From: imp at bsdimp.com (Warner Losh) Date: Mon, 23 Apr 2018 16:15:05 -0600 Subject: [TUHS] /dev/drum In-Reply-To: References: <8225C5DB-27BD-464E-930A-522C30C20EBD@tfeb.org> <25A1FED0-4F8B-408F-B27B-5728C649D8BE@collantes.us> <7wfu3nuqeb.fsf@junk.nocrew.org> <3A18DFEC-42B7-4234-9DD1-367733270D50@tfeb.org> <0abe01d3db28$b6573660$2305a320$@ronnatalie.com> Message-ID: On Mon, Apr 23, 2018 at 4:07 PM, Tim Bradshaw wrote: > On 23 Apr 2018, at 21:47, Grant Taylor via TUHS > wrote: > > I had always wondered where Solaris (SunOS) got it's use of the > different slices, including the slice that was the entire disk from. > > > > Now I'm guessing Solaris got it from SunOS which got it from 4.x BSD. > > > > > There is a wonderful Sun cretinism about this. At some recent time (I am > not sure how recent but probably mid 2000s), someone worked out that you > wanted swap to be at one end of the disk (I think the outside) because on > modern disks the data rate changes across the disk and you wanted it at the > end with the highest data rate. But lots of things knew that swap was on > s1, the second partition. So they changed the default installation tool so > the slices of the disk were out of order: s1 was the first, s0 the second, > s2 was the whole disk (which it already was) and so on. This was > enormously entertaining in a bad way if you made the normal assumption that > the slices were in order. There was also (either then or before) some > magic needed such that swapping never touched the first n blocks of the > disk where the label and boot blocks were, and it was possible to get this > wrong so the machine would happily boot, run but would then fail to boot > again, usually at a most inconvenient time. > > And the cretinism was that this was mid 2000s: if you had machine that > was paging the answer was to buy more memory not to arrange for faster swap > space: it was solving a problem that nobody had any more. > It's weird. These days lower LBAs perform better on spinning drives. We're seeing about 1.5x better performance on the first 30% of a drive than on the last 30%, at least for read speeds for video streaming.... Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Tue Apr 24 09:01:39 2018 From: dave at horsfall.org (Dave Horsfall) Date: Tue, 24 Apr 2018 09:01:39 +1000 (EST) Subject: [TUHS] /dev/drum In-Reply-To: <20180423184122.82A0918C07E@mercury.lcs.mit.edu> References: <20180423184122.82A0918C07E@mercury.lcs.mit.edu> Message-ID: On Mon, 23 Apr 2018, Noel Chiappa wrote: > Speaking of fixed-head disks, one of the Bell systems used (IIRC) an > RS04 fixed-head disk for the root. DEC apparently only used that disk > for swapping in their OS's... So the DEC diagnsotics felt free to > scribble on the disk. So, Field Circus comes in to work on the > machine... Ooops! Giggle... We were probably the only site in Oz with two tape drives on our 11/40 at UNSW; the X-ray crystallographers (or was it the molecular biologists? They're all the same to me) used to produce a tape of their results on the 360/50, to be read under RSX-11 to go to another tape, thence to be plotted on our LV-11 Versatec (and probably the only one in the country). Well, this would never do, of course, as it required us to take down our Unix box (one of the first in Oz) to run RSX, so my then-boss wrote a program (in FORTRAN) so we could do it under Unix; said LV-11 actually spent most of its time plotting biorhythm charts with a program written by said boss (who also gave me my first taste of grass, and I hated it). Anyway... Elec Eng (our foe for some weird reason, as the CSU was regarded as "The Man") left a "valuable" tape online, after using our plotter for some unrelated reason. DEC Field Circus then took the box, as they were waiting for the monthly PM. Can you guess the rest? Let's just say that Elec Eng quickly learned what the "write ring" did... Hey, is Peter Ivanov on this list? He was the one who moaned to me about us writing over an unlabelled write-enabled tape... -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From gtaylor at tnetconsulting.net Tue Apr 24 09:30:24 2018 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Mon, 23 Apr 2018 17:30:24 -0600 Subject: [TUHS] /dev/drum In-Reply-To: References: <8225C5DB-27BD-464E-930A-522C30C20EBD@tfeb.org> <25A1FED0-4F8B-408F-B27B-5728C649D8BE@collantes.us> <7wfu3nuqeb.fsf@junk.nocrew.org> <3A18DFEC-42B7-4234-9DD1-367733270D50@tfeb.org> <0abe01d3db28$b6573660$2305a320$@ronnatalie.com> Message-ID: <866bbea1-3a26-20a4-e233-1b8dc0ea2683@spamtrap.tnetconsulting.net> On 04/23/2018 04:15 PM, Warner Losh wrote: > It's weird. These days lower LBAs perform better on spinning drives. > We're seeing about 1.5x better performance on the first 30% of a drive > than on the last 30%, at least for read speeds for video streaming.... I think manufacturers have switched things around on us. I'm used to higher LBA numbers being on the outside of the disk. But I've seen anecdotal indicators that the opposite is now true. -- 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 krewat at kilonet.net Tue Apr 24 09:45:59 2018 From: krewat at kilonet.net (Arthur Krewat) Date: Mon, 23 Apr 2018 19:45:59 -0400 Subject: [TUHS] /dev/drum In-Reply-To: References: <8225C5DB-27BD-464E-930A-522C30C20EBD@tfeb.org> <25A1FED0-4F8B-408F-B27B-5728C649D8BE@collantes.us> <7wfu3nuqeb.fsf@junk.nocrew.org> <3A18DFEC-42B7-4234-9DD1-367733270D50@tfeb.org> <0abe01d3db28$b6573660$2305a320$@ronnatalie.com> Message-ID: On 4/23/2018 6:07 PM, Tim Bradshaw wrote: > On 23 Apr 2018, at 21:47, Grant > And the cretinism was that this was mid 2000s: if you had machine that was paging the answer was to buy more memory not to arrange for faster swap space: it was solving a problem that nobody had any more. > > Wow, I was going to refute this, as I don't ever remember seeing any Solaris box do this. However, a Solaris 8 x86 vanilla install on VMware I did recently does indeed have swap on the first cylinders (see below). A Solaris 7 x86 install does not exhibit this behavior. Now I'm wondering if Solaris 9 does it. A Solaris 10 box I have access to has swap after root, not before. # format Searching for disks...done AVAILABLE DISK SELECTIONS:        0. c0d0           /pci at 0,0/pci-ide at 7,1/ide at 0/cmdk at 0,0 Specify disk (enter its number): 0 selecting c0d0 Controller working list found [disk formatted, defect list found] Warning: Current Disk has mounted partitions. FORMAT MENU:         disk       - select a disk         type       - select (define) a disk type         partition  - select (define) a partition table         current    - describe the current disk         format     - format and analyze the disk         fdisk      - run the fdisk program         repair     - repair a defective sector         show       - translate a disk address         label      - write label to the disk         analyze    - surface analysis         defect     - defect list management         backup     - search for backup labels         verify     - read and display labels         save       - save new disk/partition definitions         volname    - set 8-character volume name         !     - execute , then return         quit format> part PARTITION MENU:         0      - change `0' partition         1      - change `1' partition         2      - change `2' partition         3      - change `3' partition         4      - change `4' partition         5      - change `5' partition         6      - change `6' partition         7      - change `7' partition         select - select a predefined table         modify - modify a predefined partition table         name   - name the current table         print  - display the current table         label  - write partition map and label to the disk         ! - execute , then return         quit partition> pri Current partition table (original): Total disk cylinders available: 22166 + 2 (reserved cylinders) Part      Tag    Flag     Cylinders         Size Blocks   0       root    wm    1113 -  3704        1.17GB (2592/0/0)   2449440   1       swap    wu       3 -  1112      512.18MB (1110/0/0)   1048950   2     backup    wm       0 - 22166        9.99GB (22167/0/0) 20947815   3 unassigned    wm       0                0 (0/0/0)            0   4 unassigned    wm       0                0 (0/0/0)            0   5 unassigned    wm       0                0 (0/0/0)            0   6 unassigned    wm       0                0 (0/0/0)            0   7       home    wm    3705 - 22166        8.32GB (18462/0/0) 17446590   8       boot    wu       0 -     0        0.46MB (1/0/0)          945   9 alternates    wu       1 -     2        0.92MB (2/0/0)         1890 From dave at horsfall.org Tue Apr 24 09:49:34 2018 From: dave at horsfall.org (Dave Horsfall) Date: Tue, 24 Apr 2018 09:49:34 +1000 (EST) Subject: [TUHS] /dev/drum In-Reply-To: References: <20180423184122.82A0918C07E@mercury.lcs.mit.edu> Message-ID: On Tue, 24 Apr 2018, Dave Horsfall wrote: > Well, this would never do, of course, as it required us to take down our > Unix box (one of the first in Oz) to run RSX, so my then-boss wrote a > program (in FORTRAN) so we could do it under Unix; said LV-11 actually > spent most of its time plotting biorhythm charts with a program written > by said boss (who also gave me my first taste of grass, and I hated it). One minor detail that I forgot: it was the (mostly male) computer operators who asked us to plot both their biorhythms of their (mostly female) partners, and themselves, to see if they were compatible... I think we (not me) began charging their department per plot, as that thermal paper was pretty pricey... Hey, it was all funny money, after all! This was the 70s/80s, man... -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From bqt at update.uu.se Tue Apr 24 09:44:06 2018 From: bqt at update.uu.se (Johnny Billquist) Date: Tue, 24 Apr 2018 01:44:06 +0200 Subject: [TUHS] /dev/drum In-Reply-To: References: Message-ID: <9a5e49bb-f235-4b87-445b-1532d8facd2f@update.uu.se> On 2018-04-24 01:30, Grant Taylor wrote: > On 04/23/2018 04:15 PM, Warner Losh wrote: >> It's weird. These days lower LBAs perform better on spinning drives. >> We're seeing about 1.5x better performance on the first 30% of a drive >> than on the last 30%, at least for read speeds for video streaming.... > I think manufacturers have switched things around on us. I'm used to > higher LBA numbers being on the outside of the disk. But I've seen > anecdotal indicators that the opposite is now true. That must have been somewhere in the middle of history in that case. Old (proper) drives had/have track 0 at the outer edge. The disk loaded the heads after spin up, and that was at the outer edge, and then you just locked on to track 0, which should be near. Heads had to be retracted for the disk pack to be replaced. But this whole optimization for swap based on transfer speeds makes no sense to me. The dominating factor in spinning rust is seek times, and not transfer speed. If you place the swap at one end of the disk, it won't matter much that transfers will be faster, as seek times will on average be much longer, and that will eat up any transfer gain ten times over before even thinking. (Unless all your disk ever does is swapping, at which time the heads can stay around the swapping area all the time.) Which is also why the file system for RSX (ODS-1) placed the index file (equivalent of the inode table) at the middle of the disk by default. Not sure if Unix did that optimization, but I would hope so. (Never dug into that part of the code.) 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 usotsuki at buric.co Tue Apr 24 09:57:44 2018 From: usotsuki at buric.co (Steve Nickolas) Date: Mon, 23 Apr 2018 19:57:44 -0400 (EDT) Subject: [TUHS] /dev/drum In-Reply-To: <9a5e49bb-f235-4b87-445b-1532d8facd2f@update.uu.se> References: <9a5e49bb-f235-4b87-445b-1532d8facd2f@update.uu.se> Message-ID: On Tue, 24 Apr 2018, Johnny Billquist wrote: > Which is also why the file system for RSX (ODS-1) placed the index file > (equivalent of the inode table) at the middle of the disk by default. > > Not sure if Unix did that optimization, but I would hope so. (Never dug into > that part of the code.) That reminds me of the Apple ][, whose original DOS put the directory and bitmap table on track 17 (0-indexed) on a 35-track floppy disk. -uso. From ron at ronnatalie.com Tue Apr 24 10:24:47 2018 From: ron at ronnatalie.com (Ronald Natalie) Date: Mon, 23 Apr 2018 20:24:47 -0400 Subject: [TUHS] /dev/drum In-Reply-To: <9a5e49bb-f235-4b87-445b-1532d8facd2f@update.uu.se> References: <9a5e49bb-f235-4b87-445b-1532d8facd2f@update.uu.se> Message-ID: <4B7022C6-1629-45AF-8E8F-93FDBEE068E0@ronnatalie.com> It also makes no sense because disks of the day were constant angular density (unlike CDs for example, which are constant linear). There’s no different in transfer rate anywhere on the disk. Each track has the same number of sectors. We spent a lot of time in those days with “elevator” algorithms and clustering inodes to try to minimize seek time. The other thing that was done on the fancier devices (not often found on PDP-11s) was optimizing where you were in the rotational angle. The original UNIX filesystems were dumb. It was . Wasn’t until later things like the Berkeley file systems that things started to get more clever in layout. From wkt at tuhs.org Tue Apr 24 10:25:17 2018 From: wkt at tuhs.org (Warren Toomey) Date: Tue, 24 Apr 2018 10:25:17 +1000 Subject: [TUHS] /dev/drum In-Reply-To: <9a5e49bb-f235-4b87-445b-1532d8facd2f@update.uu.se> References: <9a5e49bb-f235-4b87-445b-1532d8facd2f@update.uu.se> Message-ID: <20180424002517.GA21197@minnie.tuhs.org> On Tue, Apr 24, 2018 at 01:44:06AM +0200, Johnny Billquist wrote: >Which is also why the file system for RSX (ODS-1) placed the index >file (equivalent of the inode table) at the middle of the disk by >default. > >Not sure if Unix did that optimization, but I would hope so. (Never >dug into that part of the code.) Boston Children's Museum RK05 driver for 6th Ed springs to mind! Cheers, Warren From ron at ronnatalie.com Tue Apr 24 10:26:23 2018 From: ron at ronnatalie.com (Ronald Natalie) Date: Mon, 23 Apr 2018 20:26:23 -0400 Subject: [TUHS] /dev/drum In-Reply-To: References: <20180423184122.82A0918C07E@mercury.lcs.mit.edu> Message-ID: <7C437958-7C49-4088-A202-00E517C7F6F5@ronnatalie.com> We never had to worry about DEC CEs. However, when we got to the VAX where we had a built in time of day clock, anytime anybody ran diagnostics or any DEC OS where they set the clock, it would get changed to localtime (what DEC used) rather than the Zulu time UNIX used. From wkt at tuhs.org Tue Apr 24 10:27:46 2018 From: wkt at tuhs.org (Warren Toomey) Date: Tue, 24 Apr 2018 10:27:46 +1000 Subject: [TUHS] i-nodes in middle of disk In-Reply-To: <20180424002517.GA21197@minnie.tuhs.org> References: <9a5e49bb-f235-4b87-445b-1532d8facd2f@update.uu.se> <20180424002517.GA21197@minnie.tuhs.org> Message-ID: <20180424002746.GA23743@minnie.tuhs.org> On Tue, Apr 24, 2018 at 10:25:17AM +1000, Warren Toomey wrote: >On Tue, Apr 24, 2018 at 01:44:06AM +0200, Johnny Billquist wrote: >>Which is also why the file system for RSX (ODS-1) placed the index >>file (equivalent of the inode table) at the middle of the disk by >>default. >> >>Not sure if Unix did that optimization, but I would hope so. (Never >>dug into that part of the code.) > >Boston Children's Museum RK05 driver for 6th Ed springs to mind! See the blurb for the UNSW 01 image here: http://www.tuhs.org/Archive/Distributions/UNSW UNSW 01 ------- Tape label: System Source Disk DD format URK? BS=24B count=203 800bpi 9track UNIX System Source 1 of 1 25/1/78 A distribution of UNIX source from UNSW, with several changes. record0.gz is an RK05 image laid out according to the `Boston Children's Museum' format (i-nodes in the middle). Latest file timestamp is Jan 24 1978. There is only kernel source, plus a `unswbatch' directory. The latter seems to hold the source to a UNIX batch system developed by Ian Johnstone and other at the School of Electrical Engineering at UNSW. record0.tar.gz is a tar archive of the RK05 image. Cheers, Warren From dave at horsfall.org Tue Apr 24 10:31:43 2018 From: dave at horsfall.org (Dave Horsfall) Date: Tue, 24 Apr 2018 10:31:43 +1000 (EST) Subject: [TUHS] /dev/drum In-Reply-To: <20180424002517.GA21197@minnie.tuhs.org> References: <9a5e49bb-f235-4b87-445b-1532d8facd2f@update.uu.se> <20180424002517.GA21197@minnie.tuhs.org> Message-ID: On Tue, 24 Apr 2018, Warren Toomey wrote: >> Not sure if Unix did that optimization, but I would hope so. (Never dug >> into that part of the code.) > > Boston Children's Museum RK05 driver for 6th Ed springs to mind! Yep, with the inodes in the middle of the disk! It also helped that we (UNSW) put the superblock in the middle of said slice... -- Dave Horsfall BSc DTM (VK2KFU) -- FuglySoft -- Gosford IT -- Unix/C/Perl (AbW) From lyndon at orthanc.ca Tue Apr 24 11:02:52 2018 From: lyndon at orthanc.ca (Lyndon Nerenberg) Date: Mon, 23 Apr 2018 18:02:52 -0700 (PDT) Subject: [TUHS] /dev/drum In-Reply-To: <9a5e49bb-f235-4b87-445b-1532d8facd2f@update.uu.se> References: <9a5e49bb-f235-4b87-445b-1532d8facd2f@update.uu.se> Message-ID: > But this whole optimization for swap based on transfer speeds makes no sense > to me. The dominating factor in spinning rust is seek times, and not transfer > speed. And thus were born cylinder groups. From itz at very.loosely.org Tue Apr 24 10:59:11 2018 From: itz at very.loosely.org (Ian Zimmerman) Date: Mon, 23 Apr 2018 17:59:11 -0700 Subject: [TUHS] Happy birthday, Niklaus Wirth! In-Reply-To: <20180216012554.zvfmbi7uhjtuwnd6@matica.foolinux.mooo.com> References: <20180216012554.zvfmbi7uhjtuwnd6@matica.foolinux.mooo.com> Message-ID: <20180424005911.vckimli2vo65xz3m@matica.foolinux.mooo.com> On 2018-02-15 17:25, Ian Zimmerman wrote: > I know one of the Franz founders, I'll ask him when I have a chance. So, the main link seems to be John Foderaro, who worked on both BSD and Franz. According to my source, he wrote biff(1). -- Please don't Cc: me privately on mailing lists and Usenet, if you also post the followup to the list or newsgroup. To reply privately _only_ on Usenet and on broken lists which rewrite From, fetch the TXT record for no-use.mooo.com. From dave at horsfall.org Tue Apr 24 13:26:34 2018 From: dave at horsfall.org (Dave Horsfall) Date: Tue, 24 Apr 2018 13:26:34 +1000 (EST) Subject: [TUHS] Happy birthday, Niklaus Wirth! In-Reply-To: <20180424005911.vckimli2vo65xz3m@matica.foolinux.mooo.com> References: <20180216012554.zvfmbi7uhjtuwnd6@matica.foolinux.mooo.com> <20180424005911.vckimli2vo65xz3m@matica.foolinux.mooo.com> Message-ID: On Mon, 23 Apr 2018, Ian Zimmerman wrote: > According to my source, he wrote biff(1). http://en.wikipedia.org/wiki/BIFF (I'd post the whole thing, but Warren would probably have my nuts.) -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From grog at lemis.com Tue Apr 24 13:28:30 2018 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Tue, 24 Apr 2018 13:28:30 +1000 Subject: [TUHS] 3330s, 3340s, Winchesters... (was: /dev/drum) In-Reply-To: References: <7wfu3nuqeb.fsf@junk.nocrew.org> <3A18DFEC-42B7-4234-9DD1-367733270D50@tfeb.org> <0abe01d3db28$b6573660$2305a320$@ronnatalie.com> <4b95c9f6-0190-be93-7284-d03be289c4ba@gmail.com> Message-ID: <20180424032830.GJ31055@eureka.lemis.com> On Monday, 23 April 2018 at 17:27:29 -0400, Clem Cole wrote: > > As disks dropped a little cheaper and having more than one RP06 > became possible (RP06 aka IBM 3330 - project Winchester You're confusing the 3330 with the 3340: the latter was the Winchester, the first disk with an HDA. The 3330 was the old-style disk pack in a cheese bell. A variant (apparently not from IBM; CDC maybe?) of the same disk pack stored 300 MB, and we used a lot of them at Tandem in the 1970s and early 1980s. I suppose they were pretty widespread. 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 drsalists at gmail.com Tue Apr 24 14:31:28 2018 From: drsalists at gmail.com (Dan Stromberg) Date: Mon, 23 Apr 2018 21:31:28 -0700 Subject: [TUHS] Happy birthday, Niklaus Wirth! In-Reply-To: <20180424005911.vckimli2vo65xz3m@matica.foolinux.mooo.com> References: <20180216012554.zvfmbi7uhjtuwnd6@matica.foolinux.mooo.com> <20180424005911.vckimli2vo65xz3m@matica.foolinux.mooo.com> Message-ID: On Mon, Apr 23, 2018 at 5:59 PM, Ian Zimmerman wrote: > On 2018-02-15 17:25, Ian Zimmerman wrote: > >> I know one of the Franz founders, I'll ask him when I have a chance. > > So, the main link seems to be John Foderaro, who worked on both BSD and Franz. > > According to my source, he wrote biff(1). I had been of the impression that biff(1) was named after a dog that barked at the slightest provocation... From gtaylor at tnetconsulting.net Tue Apr 24 14:32:26 2018 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Mon, 23 Apr 2018 22:32:26 -0600 Subject: [TUHS] /dev/drum In-Reply-To: <9a5e49bb-f235-4b87-445b-1532d8facd2f@update.uu.se> References: <9a5e49bb-f235-4b87-445b-1532d8facd2f@update.uu.se> Message-ID: On 04/23/2018 05:44 PM, Johnny Billquist wrote: > But this whole optimization for swap based on transfer speeds makes no > sense to me. The dominating factor in spinning rust is seek times, and > not transfer speed. If you place the swap at one end of the disk, it > won't matter much that transfers will be faster, as seek times will on > average be much longer, and that will eat up any transfer gain ten times > over before even thinking. (Unless all your disk ever does is swapping, > at which time the heads can stay around the swapping area all the time.) I wonder if part of the (perceived?) performance gain was from the likelihood that swap at one end of the drive meant that things could be contiguous. Seek, lay down / pick up a large (or at least not small) number of sectors, and seek back. I had always assumed that the outer edge (what I thought was the end of the disk) was faster than the inner edge (what I thought was the beginning of the disk) because of geometry. However, as Ronald stated, hard drives were constant angular density. Thus negating what I originally thought about speed. -- 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 bakul at bitblocks.com Tue Apr 24 14:49:34 2018 From: bakul at bitblocks.com (Bakul Shah) Date: Mon, 23 Apr 2018 21:49:34 -0700 Subject: [TUHS] /dev/drum In-Reply-To: Your message of "Mon, 23 Apr 2018 22:32:26 -0600." References: <9a5e49bb-f235-4b87-445b-1532d8facd2f@update.uu.se> Message-ID: <20180424044941.7C703156E510@mail.bitblocks.com> On Mon, 23 Apr 2018 22:32:26 -0600 Grant Taylor via TUHS wrote: > > I had always assumed that the outer edge (what I thought was the end of > the disk) was faster than the inner edge (what I thought was the > beginning of the disk) because of geometry. However, as Ronald stated, > hard drives were constant angular density. Thus negating what I > originally thought about speed. Constant angular velocity means faster "linear" velocity for tracks further away from the center. Since 1990 or so disk tracks are divided up in 16 or so "zones", where outer zones have more blocks per track. This translates to higher throughput. A modern Seagate Exos SAS disk may have a range of 279MB/s (outermost) to 136MB/s (innermost) or 300MB/s to 210MB/s for faster disks (15Krpm). Disk vendors don't seem to break this range out for consumer drives. But you can measure it using tools like diskinfo on FreeBSD. For example: # diskinfo -t /dev/ada4 # this is an 5 year old 1TB WD "Black" disk. /dev/ada4 ... Not_Zoned # Zone Mode <<== this seems wrong. ... Transfer rates: outside: 102400 kbytes in 0.972176 sec = 105331 kbytes/sec middle: 102400 kbytes in 1.088977 sec = 94033 kbytes/sec inside: 102400 kbytes in 1.804460 sec = 56748 kbytes/sec From imp at bsdimp.com Tue Apr 24 14:59:19 2018 From: imp at bsdimp.com (Warner Losh) Date: Mon, 23 Apr 2018 22:59:19 -0600 Subject: [TUHS] /dev/drum In-Reply-To: <20180424044941.7C703156E510@mail.bitblocks.com> References: <9a5e49bb-f235-4b87-445b-1532d8facd2f@update.uu.se> <20180424044941.7C703156E510@mail.bitblocks.com> Message-ID: On Mon, Apr 23, 2018 at 10:49 PM, Bakul Shah wrote: > On Mon, 23 Apr 2018 22:32:26 -0600 Grant Taylor via TUHS < > tuhs at minnie.tuhs.org> wrote: > > > > I had always assumed that the outer edge (what I thought was the end of > > the disk) was faster than the inner edge (what I thought was the > > beginning of the disk) because of geometry. However, as Ronald stated, > > hard drives were constant angular density. Thus negating what I > > originally thought about speed. > > Constant angular velocity means faster "linear" velocity for > tracks further away from the center. Since 1990 or so disk > tracks are divided up in 16 or so "zones", where outer zones > have more blocks per track. This translates to higher > throughput. > > A modern Seagate Exos SAS disk may have a range of 279MB/s > (outermost) to 136MB/s (innermost) or 300MB/s to 210MB/s for > faster disks (15Krpm). Disk vendors don't seem to break this > range out for consumer drives. But you can measure it using > tools like diskinfo on FreeBSD. For example: > > # diskinfo -t /dev/ada4 # this is an 5 year old 1TB WD "Black" disk. > /dev/ada4 > ... > Not_Zoned # Zone Mode <<== this seems wrong. > That's right. This is for BIO_ZONE stuff, which has to do with host managed and host aware SMR drive zones. That's different than the zones you are talking about. > ... > Transfer rates: > outside: 102400 kbytes in 0.972176 sec = 105331 > kbytes/sec > middle: 102400 kbytes in 1.088977 sec = 94033 > kbytes/sec > inside: 102400 kbytes in 1.804460 sec = 56748 > kbytes/sec > Yes. This matches our experience where we get 1.5x better on the low LBAs than the high LBAs. We're looking to 'short stroke' the drive to the first part of it to get better performance... Toss a filesystem on top of it, and have a more random workload and it's down to about 30% better than using the whole drive.... Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From bakul at bitblocks.com Tue Apr 24 16:22:41 2018 From: bakul at bitblocks.com (Bakul Shah) Date: Mon, 23 Apr 2018 23:22:41 -0700 Subject: [TUHS] /dev/drum In-Reply-To: Your message of "Mon, 23 Apr 2018 22:59:19 -0600." References: <9a5e49bb-f235-4b87-445b-1532d8facd2f@update.uu.se> <20180424044941.7C703156E510@mail.bitblocks.com> Message-ID: <20180424062248.9D2FE156E510@mail.bitblocks.com> On Mon, 23 Apr 2018 22:59:19 -0600 Warner Losh wrote: > > ... > > Not_Zoned # Zone Mode <<== this seems wrong. > > > > That's right. This is for BIO_ZONE stuff, which has to do with host managed > and host aware SMR drive zones. That's different than the zones you are > talking about. Ah. Thanks! Does host management of SMR zones provide better throughput for sequential writes? Enough to make it worht it? [I guess this may be something you guys may care about?] Haven't had a chance to work on storage stuff for ages. [Last I played with Ceph was 5 years ago and at a higher level than disks.] > Yes. This matches our experience where we get 1.5x better on the low LBAs > than the high LBAs. We're looking to 'short stroke' the drive to the first > part of it to get better performance... Toss a filesystem on top of it, and > have a more random workload and it's down to about 30% better than using > the whole drive.... Is the tradeoff worth it? Now you have choices like Sata vs SAS vs SDD vs PCIe.... We've come a long way from /dev/drum :-) From lars at nocrew.org Tue Apr 24 16:46:29 2018 From: lars at nocrew.org (Lars Brinkhoff) Date: Tue, 24 Apr 2018 06:46:29 +0000 Subject: [TUHS] /dev/drum In-Reply-To: <9a5e49bb-f235-4b87-445b-1532d8facd2f@update.uu.se> (Johnny Billquist's message of "Tue, 24 Apr 2018 01:44:06 +0200") References: <9a5e49bb-f235-4b87-445b-1532d8facd2f@update.uu.se> Message-ID: <7wa7ttt83e.fsf@junk.nocrew.org> Johnny Billquist wrote: > Which is also why the file system for RSX (ODS-1) placed the index > file (equivalent of the inode table) at the middle of the disk by > default. Not sure if Unix did that optimization, but I would hope so. I know of an operating system predating Unix which has that optimization. From rudi.j.blom at gmail.com Tue Apr 24 17:10:35 2018 From: rudi.j.blom at gmail.com (Rudi Blom) Date: Tue, 24 Apr 2018 14:10:35 +0700 Subject: [TUHS] /dev/drum Message-ID: >Date: Mon, 23 Apr 2018 13:51:07 -0400 >From: Clem Cole >To: Ron Natalie >Cc: Tim Bradshaw , TUHS main list >Subject: Re: [TUHS] /dev/drum >Message-ID: > kQS=H7npcEZ_OKXL1ffPxak5b2ENv4Q at mail.gmail.com> >Content-Type: text/plain; charset="utf-8" ... some stuff removed ... >​Exactly... For instance an RK04 was less that 5K blocks (4620 or some >such - I've forgotten the actually amount). The disk was mkfs'ed to the >first 4K and the left over was give to the swap system. By the time of >4.X, the RP06 was 'partitioned' into 'rings' (some overlapping). The 'a'. >partition was root, the 'b' was swap and one fo the others was the rest. >Later the 'c' was a short form for copying the entire disk. Wondered why, but I guess now I know that's the reason Digital UNIX on alpha used the same disk layout. From a AlphaServer DS10 running DU4.0g, output "disklabel -r rz16a" # /dev/rrz16a: type: SCSI disk: BB009222 label: flags: bytes/sector: 512 sectors/track: 168 tracks/cylinder: 20 sectors/cylinder: 3360 cylinders: 5273 sectors/unit: 17773524 rpm: 7200 interleave: 1 trackskew: 66 cylinderskew: 83 headswitch: 0 # milliseconds track-to-track seek: 0 # milliseconds drivedata: 0 8 partitions: # size offset fstype [fsize bsize cpg] # NOTE: values not exact a: 524288 0 AdvFS # (Cyl. 0 - 156*) b: 1572864 524288 swap # (Cyl. 156*- 624*) c: 17773524 0 unused 0 0 # (Cyl. 0 - 5289*) d: 0 0 unused 0 0 # (Cyl. 0 - -1) e: 0 0 unused 0 0 # (Cyl. 0 - -1) f: 0 0 unused 0 0 # (Cyl. 0 - -1) g: 4194304 2097152 AdvFS # (Cyl. 624*- 1872*) h: 11482068 6291456 AdvFS # (Cyl. 1872*- 5289*) From tfb at tfeb.org Tue Apr 24 18:05:06 2018 From: tfb at tfeb.org (tfb at tfeb.org) Date: Tue, 24 Apr 2018 09:05:06 +0100 Subject: [TUHS] /dev/drum In-Reply-To: References: <8225C5DB-27BD-464E-930A-522C30C20EBD@tfeb.org> <25A1FED0-4F8B-408F-B27B-5728C649D8BE@collantes.us> <7wfu3nuqeb.fsf@junk.nocrew.org> <3A18DFEC-42B7-4234-9DD1-367733270D50@tfeb.org> <0abe01d3db28$b6573660$2305a320$@ronnatalie.com> Message-ID: <183C2A87-9813-4C86-9F22-8E2B9D689162@tfeb.org> On 24 Apr 2018, at 00:45, Arthur Krewat wrote: > > Wow, I was going to refute this, as I don't ever remember seeing any Solaris box do this. However, a Solaris 8 x86 vanilla install on VMware I did recently does indeed have swap on the first cylinders (see below). A Solaris 7 x86 install does not exhibit this behavior. Now I'm wondering if Solaris 9 does it. A Solaris 10 box I have access to has swap after root, not before. It makes sense that it was 8. We hardly used 9 so I don't know what it did, but I suspect by 10 someone had had very strong words with whoever thought it was a good idea after some large customer had had an only-technically-their-fault outage because of it and been fierce at Sun. It was really stupidly dumb, I thought: solving a problem no-one had any more by the wrong method (if paging *was* a problem a better solution is to add a second slice on another physical disk as swap). -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at kjorling.se Tue Apr 24 19:37:09 2018 From: michael at kjorling.se (Michael =?utf-8?B?S2rDtnJsaW5n?=) Date: Tue, 24 Apr 2018 09:37:09 +0000 Subject: [TUHS] /dev/drum In-Reply-To: <866bbea1-3a26-20a4-e233-1b8dc0ea2683@spamtrap.tnetconsulting.net> References: <7wfu3nuqeb.fsf@junk.nocrew.org> <3A18DFEC-42B7-4234-9DD1-367733270D50@tfeb.org> <0abe01d3db28$b6573660$2305a320$@ronnatalie.com> <866bbea1-3a26-20a4-e233-1b8dc0ea2683@spamtrap.tnetconsulting.net> Message-ID: <20180424093709.GB7568@h-174-65.A328.priv.bahnhof.se> On 23 Apr 2018 17:30 -0600, from tuhs at minnie.tuhs.org (Grant Taylor via TUHS): > On 04/23/2018 04:15 PM, Warner Losh wrote: >> It's weird. These days lower LBAs perform better on spinning >> drives. We're seeing about 1.5x better performance on the first >> 30% of a drive than on the last 30%, at least for read speeds for >> video streaming.... > > I think manufacturers have switched things around on us. I'm used > to higher LBA numbers being on the outside of the disk. But I've > seen anecdotal indicators that the opposite is now true. I couldn't quite resist, so tried it out. Take this for what it is, an anecdote. Reading 10 GB in direct mode using dd with no skip at the beginning, in 1 MiB blocks, gives me about 190 MB/s on one of the Seagate SAS disks in my PC, and some 165 MB/s on one of the HGST SATA disks in the same PC. Obviously, that's for purely sequential I/O, with very little other I/O load. Doing the same with an initial skip of 3,500,000 blocks (these are 4 TB drives, so this puts the read toward the outer limit), I get 105 MB/s on the Seagate SAS and 100 MB/s on the HGST SATA. I did the same thing twice to make sure caching wasn't somehow interfering with the values. The differences for all reported transfer rates were marginal, and well within a reasonable margin of error. That's definitely statistically significantly slower toward the outer edge of the disk as presented by the OS. That _should_ translate to slower for higher LBAs, but with all the magic happening in modern systems, you might never know... Of course, back in ye olden days, even 100 MB/s would have been blazingly fast. Are we spoiled these days to think of throughputs on the order of a gigabit per second as slow? -- 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 dave at horsfall.org Tue Apr 24 19:57:25 2018 From: dave at horsfall.org (Dave Horsfall) Date: Tue, 24 Apr 2018 19:57:25 +1000 (EST) Subject: [TUHS] /dev/drum In-Reply-To: <20180424093709.GB7568@h-174-65.A328.priv.bahnhof.se> References: <7wfu3nuqeb.fsf@junk.nocrew.org> <3A18DFEC-42B7-4234-9DD1-367733270D50@tfeb.org> <0abe01d3db28$b6573660$2305a320$@ronnatalie.com> <866bbea1-3a26-20a4-e233-1b8dc0ea2683@spamtrap.tnetconsulting.net> <20180424093709.GB7568@h-174-65.A328.priv.bahnhof.se> Message-ID: On Tue, 24 Apr 2018, Michael Kjörling wrote: [ ... ] > That's definitely statistically significantly slower toward the outer > edge of the disk as presented by the OS. That _should_ translate to > slower for higher LBAs, but with all the magic happening in modern > systems, you might never know... Exactly; with disks these days it's pointless trying to second-guess what's happening under the bonnet (ObUS: hood). A well-known question in the security field, for instance, is how do you know that you have *really* erased that disk? The thing can lie as much as it likes, and you'll never know for sure. -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From dave at horsfall.org Tue Apr 24 20:19:26 2018 From: dave at horsfall.org (Dave Horsfall) Date: Tue, 24 Apr 2018 20:19:26 +1000 (EST) Subject: [TUHS] i-nodes in middle of disk In-Reply-To: <20180424002746.GA23743@minnie.tuhs.org> References: <9a5e49bb-f235-4b87-445b-1532d8facd2f@update.uu.se> <20180424002517.GA21197@minnie.tuhs.org> <20180424002746.GA23743@minnie.tuhs.org> Message-ID: On Tue, 24 Apr 2018, Warren Toomey wrote: > UNSW 01 > ------- > Tape label: System Source Disk > DD format URK? BS=24B count=203 800bpi 9track > UNIX System Source 1 of 1 > 25/1/78 > > A distribution of UNIX source from UNSW, with several changes. record0.gz is > an RK05 image laid out according to the `Boston Children's Museum' format > (i-nodes in the middle). Latest file timestamp is Jan 24 1978. There is only > kernel source, plus a `unswbatch' directory. The latter seems to hold the > source to a UNIX batch system developed by Ian Johnstone and other at the > School of Electrical Engineering at UNSW. Odd; I could've sworn that "URK" was un-rotated i.e. traditional format; are you sure about that? And "unswbatch"... Ahhh... I must take a look at that distribution some time, to see whether it has my fingerprints on it; Kevin Hill and I totally rewrote the system, throwing out IanJ's rubbish, with him doing the application stuff ("submit" etc[*]) and me doing the driver. After that, it actually worked (once I'd figured out a nasty bug in KRONOS' UT-200 driver, that led to a POLL/REJECT loop). [*] I did a memorable hack to "submit" once; you see, we had an old VT-05 in the fishbowl, facing outwards for the sheeple, and it displayed the batch queue (by title) in real time. Well, me being me, I hacked up the aforesaid "submit" command to take multiple arbitrary files as input with a specified title, so for a while it displayed "xxx... LLAMAS ARE BIGGER THAN FROGS" (job names were 8 characters, and I have no idea how that will display in people's MUAs).. (I *think* I was actually working for them at that time.) -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From paul.winalski at gmail.com Tue Apr 24 21:43:43 2018 From: paul.winalski at gmail.com (Paul Winalski) Date: Tue, 24 Apr 2018 07:43:43 -0400 Subject: [TUHS] 3330s, 3340s, Winchesters... (was: /dev/drum) In-Reply-To: <20180424032830.GJ31055@eureka.lemis.com> References: <7wfu3nuqeb.fsf@junk.nocrew.org> <3A18DFEC-42B7-4234-9DD1-367733270D50@tfeb.org> <0abe01d3db28$b6573660$2305a320$@ronnatalie.com> <4b95c9f6-0190-be93-7284-d03be289c4ba@gmail.com> <20180424032830.GJ31055@eureka.lemis.com> Message-ID: On 4/23/18, Greg 'groggy' Lehey wrote: > > You're confusing the 3330 with the 3340: the latter was the > Winchester, the first disk with an HDA. The 3330 was the old-style > disk pack in a cheese bell. A variant (apparently not from IBM; CDC > maybe?) of the same disk pack stored 300 MB, and we used a lot of them > at Tandem in the 1970s and early 1980s. I suppose they were pretty > widespread. The 3330 was, as you say, a conventional (for the day) disk drive where the heads remain with the drive and you removed the platters with a plastic cover very much like a cheese bell. The 3340 was the first IBM drive where the heads were sealed with the media. The disk packs looked somewhat like the front end of the Starship Enterprise, with something like a roll-top desk cover at the back. You put the pack in the drive, the drive opened the roll-top desk and plugged into the back of the head assembly, and you were in business. After a few years IBM discovered that nobody was removing their disks anymore, and so the 3340's follow-ons were not removable. But they still used the sealed-media technology still in use in hard drives today. Regarding the Winchester code name, I've argued about this with Clem before. Clem claims that the code name refers to various advances in disk technology first released in the 3330's disk packs. Wikipedia and my own memory agree with you that Winchester referred to the 3340. -Paul W. From paul.winalski at gmail.com Tue Apr 24 21:58:23 2018 From: paul.winalski at gmail.com (Paul Winalski) Date: Tue, 24 Apr 2018 07:58:23 -0400 Subject: [TUHS] VAX dates (was /dev/drum) Message-ID: On 4/22/18, Clem cole wrote: > > BTW if you want to be correct about dates - the DEC released the Vax in 76 > not 78 ( I personally used to program Vax serial #1 at CMU under VMS 1.0 > before I was at UCB which is what Dan had asked). As I remember it, DEC announced the VAX in 1976 or 1977, and first official customer ship didn't happen until 1978. Holy Cross had one of the hardware beta machines in 1977. It ran a beta version of VMS (version X0.5 initially). I ported a bunch of programs to the VAX, including the PDP-10 version of Adventure. -Paul W. From jnc at mercury.lcs.mit.edu Tue Apr 24 22:06:12 2018 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Tue, 24 Apr 2018 08:06:12 -0400 (EDT) Subject: [TUHS] 3330s, 3340s, Winchesters... (was: /dev/drum) Message-ID: <20180424120612.CD71B18C07A@mercury.lcs.mit.edu> > From: Paul Winalski > Regarding the Winchester code name, I've argued about this with Clem > before. Clem claims that the code name refers to various advances in > disk technology first released in the 3330's disk packs. Wikipedia and > my own memory agree with you that Winchester referred to the 3340. And you believe anything in Wikipedia? If so, I have a bridge to sell you! :-) But, in this case, it's correct. According to "IBM's 360 and Early 370 Computers" (Pugh, Johnson and Palmer - a very good book, BTW), pg. 507, the first Winchester was the 3340. The confusion comes from the fact that it had two spindles, each of 30MB capacity, making it a so-called "30-30" system - that being the name of Winchester's rifle. Noel From cym224 at gmail.com Tue Apr 24 23:01:34 2018 From: cym224 at gmail.com (Nemo) Date: Tue, 24 Apr 2018 09:01:34 -0400 Subject: [TUHS] /dev/drum In-Reply-To: References: <7wfu3nuqeb.fsf@junk.nocrew.org> <3A18DFEC-42B7-4234-9DD1-367733270D50@tfeb.org> <0abe01d3db28$b6573660$2305a320$@ronnatalie.com> <866bbea1-3a26-20a4-e233-1b8dc0ea2683@spamtrap.tnetconsulting.net> <20180424093709.GB7568@h-174-65.A328.priv.bahnhof.se> Message-ID: On 24 April 2018 at 05:57, Dave Horsfall wrote: [...] > A well-known question in the security field, for instance, is how do you > know that you have *really* erased that disk? The thing can lie as much as > it likes, and you'll never know for sure. That reminds of an old mil-spec that told you how to dispose of disc-packs by grinding down the platters by hand, what grit of paper to use, which directions, and how often. (Exact number escapes me.) N. From krewat at kilonet.net Tue Apr 24 23:03:48 2018 From: krewat at kilonet.net (Arthur Krewat) Date: Tue, 24 Apr 2018 09:03:48 -0400 Subject: [TUHS] /dev/drum In-Reply-To: <20180424093709.GB7568@h-174-65.A328.priv.bahnhof.se> References: <7wfu3nuqeb.fsf@junk.nocrew.org> <3A18DFEC-42B7-4234-9DD1-367733270D50@tfeb.org> <0abe01d3db28$b6573660$2305a320$@ronnatalie.com> <866bbea1-3a26-20a4-e233-1b8dc0ea2683@spamtrap.tnetconsulting.net> <20180424093709.GB7568@h-174-65.A328.priv.bahnhof.se> Message-ID: <69eb70c0-427b-c350-3674-bfb68fe15a86@kilonet.net> On 4/24/2018 5:37 AM, Michael Kjörling wrote: > > I couldn't quite resist, so tried it out. Take this for what it is, an > anecdote. > To make it even worse in terms of trying to figure out what a disk will do for (to) you in terms of performance... A new caching scheme on a set of 10TB drives I bought a while ago - they are HGST SAS drives. They incorporated a set of cylinders spaced across the disk that are "cache" cylinders. Wherever the heads are "right now", the closest cache cylinders will be used to write to. Once there's enough free time, it will go back and read those cache cylinders, and put the blocks where they are "supposed" to be. http://www.tomsitpro.com/articles/hgst-ultrastar-c15k600-hdd,2-906-3.html Those are not the drives I bought, but as far as I know, even their near-line SAS products have this feature, called NVC Quick Cache ak From clemc at ccc.com Tue Apr 24 23:13:41 2018 From: clemc at ccc.com (Clem Cole) Date: Tue, 24 Apr 2018 09:13:41 -0400 Subject: [TUHS] 3330s, 3340s, Winchesters... (was: /dev/drum) In-Reply-To: References: <7wfu3nuqeb.fsf@junk.nocrew.org> <3A18DFEC-42B7-4234-9DD1-367733270D50@tfeb.org> <0abe01d3db28$b6573660$2305a320$@ronnatalie.com> <4b95c9f6-0190-be93-7284-d03be289c4ba@gmail.com> <20180424032830.GJ31055@eureka.lemis.com> Message-ID: On Tue, Apr 24, 2018 at 7:43 AM, Paul Winalski wrote: > Clem claims that the code name refers to various advances in > disk technology first released in the 3330's disk packs. Wikipedia > and my own memory agree with you that Winchester referred to the 3340. ​Interesting ... My source was (is) my friend and former colleague from Stellar, Russ Robelen, ​who was the HW lead for the 360/50 and the IBM ACS systems. Russ said the original IBM project Winchester first begat the platter (as Noel pointed out was so named because of the 30-30 capacity of the original disk) - which showed up in the 3330 disks as well as the sealed head stuff that Paul and Greg are talking about. What I never asked him, was where Memorex fit it. It was a somehow a joint project with them, and they got at least some of the technology -- in fact DEC's OEM for the RP05/RP06 was Memorex [the big box of logic on the side of the DEC version was the Massbus to IBM I/O logic converter]. It is also true that real lasting piece of project Winchester was the embedded (sealed head) stuff that came from the 3340. I should ask Russ what he remembers, on this. I'm guessing that maybe there was two parts of the project. The sealed head stuff that Paul and Greg are discussing and probably was IBM only, as I do not remember that Memorex ever produced a similar product to the 3340 . But maybe platter stuff may have been joint. But I have asked Russ a couple of times, and he very much states that name 'Project Winchester' came from the platter technology which was first introduced in the IBM 3330. I'll have to dig up the book Noel suggests and see what they see (and ask Russ what he thinks of it). ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Tue Apr 24 23:42:57 2018 From: clemc at ccc.com (Clem Cole) Date: Tue, 24 Apr 2018 09:42:57 -0400 Subject: [TUHS] Happy birthday, Niklaus Wirth! In-Reply-To: References: <20180216012554.zvfmbi7uhjtuwnd6@matica.foolinux.mooo.com> <20180424005911.vckimli2vo65xz3m@matica.foolinux.mooo.com> Message-ID: On Tue, Apr 24, 2018 at 12:31 AM, Dan Stromberg wrote: > On Mon, Apr 23, 2018 at 5:59 PM, Ian Zimmerman > wrote: > > On 2018-02-15 17:25, Ian Zimmerman wrote: > > > >> I know one of the Franz founders, I'll ask him when I have a chance. > > > > So, the main link seems to be John Foderaro, who worked on both BSD and > Franz. > > > > According to my source, he wrote biff(1). > > I had been of the impression that biff(1) was named after a dog ​Indeed - Biff was Heidi's dog.​ > that > ​ ​ > barked at the slightest provocation... > ​Hmm, I'm not sure that is fair. Biff just warned Heidi that someone had entered their office​. ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Wed Apr 25 00:57:22 2018 From: imp at bsdimp.com (Warner Losh) Date: Tue, 24 Apr 2018 08:57:22 -0600 Subject: [TUHS] /dev/drum In-Reply-To: <20180424062248.9D2FE156E510@mail.bitblocks.com> References: <9a5e49bb-f235-4b87-445b-1532d8facd2f@update.uu.se> <20180424044941.7C703156E510@mail.bitblocks.com> <20180424062248.9D2FE156E510@mail.bitblocks.com> Message-ID: On Tue, Apr 24, 2018 at 12:22 AM, Bakul Shah wrote: > On Mon, 23 Apr 2018 22:59:19 -0600 Warner Losh wrote: > > > ... > > > Not_Zoned # Zone Mode <<== this seems wrong. > > > > > > > That's right. This is for BIO_ZONE stuff, which has to do with host > managed > > and host aware SMR drive zones. That's different than the zones you are > > talking about. > > Ah. Thanks! Does host management of SMR zones provide better > throughput for sequential writes? Enough to make it worht it? > [I guess this may be something you guys may care about?] > Haven't had a chance to work on storage stuff for ages. [Last > I played with Ceph was 5 years ago and at a higher level than > disks.] Right now, I don't think that we do anything in stock FreeBSD with the zones. I've looked at trying to create some kind of FS that copes with the large granularity writes blocks that host managed SMR drives would need to do and changes we'd need to a write-in-place FS to take advantage of it. It's possible, but it would turn UFS from a write-in-place system to a write-in-place, but only for meta-data, and different free block allocation methods. So far, it hasn't been enough of a win to be worth bothering with for our application (eg, we can get 10-20% more storage, but that delta is likely to remain constant, and the effort to make it happen is high enough that the savings isn't there to pay for the development). > Yes. This matches our experience where we get 1.5x better on the low LBAs > > than the high LBAs. We're looking to 'short stroke' the drive to the > first > > part of it to get better performance... Toss a filesystem on top of it, > and > > have a more random workload and it's down to about 30% better than using > > the whole drive.... > > Is the tradeoff worth it? Now you have choices like Sata vs > SAS vs SDD vs PCIe.... > We have a multi-tiered storage architecture. When you want to play a video from our service, we see if any of the close, fast boxes has a copy we can use. If they are too busy, we go back to slower, but more complete tiers. The last tier is made up of machines with lots of spinning disks. Some catalogs are small enough that only using 1/2 the drive, but getting 30% better throughput is the right engineering decision since it would improve network utilization w/o needing to deploy more servers. We use all those technologies in the different tiers: our fastest 100G boxes are NVMe, the 40G boxes we have are JBOD of SSDs, the 10G storage boxes are spinning rust. We use SATA for SSDs since the SAS SSDs are super pricy, but we use SAS HDDs since we need the deeper queues and other features of SAS that are absent from SATA. We also sometimes oversubscribe PCIe lanes to get better storage density at a cheaper price point. There's lots of tradeoffs that can be made.... Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From rminnich at gmail.com Wed Apr 25 02:46:18 2018 From: rminnich at gmail.com (ron minnich) Date: Tue, 24 Apr 2018 16:46:18 +0000 Subject: [TUHS] VAX dates (was /dev/drum) In-Reply-To: References: Message-ID: yeah we heard about the vax for several years at udel but my recollection is also around 1978 as "real" announcement. A friend at DEC worked on microcode, one version of which made the vax into a pdp-8. ron On Tue, Apr 24, 2018 at 4:58 AM Paul Winalski wrote: > On 4/22/18, Clem cole wrote: > > > > BTW if you want to be correct about dates - the DEC released the Vax in > 76 > > not 78 ( I personally used to program Vax serial #1 at CMU under VMS 1.0 > > before I was at UCB which is what Dan had asked). > > As I remember it, DEC announced the VAX in 1976 or 1977, and first > official customer ship didn't happen until 1978. Holy Cross had one > of the hardware beta machines in 1977. It ran a beta version of VMS > (version X0.5 initially). I ported a bunch of programs to the VAX, > including the PDP-10 version of Adventure. > > -Paul W. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From grog at lemis.com Wed Apr 25 10:47:34 2018 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Wed, 25 Apr 2018 10:47:34 +1000 Subject: [TUHS] 3330s, 3340s, Winchesters... (was: /dev/drum) In-Reply-To: <20180424120612.CD71B18C07A@mercury.lcs.mit.edu> References: <20180424120612.CD71B18C07A@mercury.lcs.mit.edu> Message-ID: <20180425004734.GK31055@eureka.lemis.com> On Tuesday, 24 April 2018 at 8:06:12 -0400, Noel Chiappa wrote: >> From: Paul Winalski > >> Regarding the Winchester code name, I've argued about this with Clem >> before. Clem claims that the code name refers to various advances in >> disk technology first released in the 3330's disk packs. Wikipedia and >> my own memory agree with you that Winchester referred to the 3340. > > And you believe anything in Wikipedia? Yes, most things, especially if they match my preconceived notions. To be fair, Wikipedia is relatively accurate. And if you find something wrong in it and don't fix it, you have only yourself to blame. > If so, I have a bridge to sell you! :-) Hey, that's my line ("Porting UNIX Software", page 9). > But, in this case, it's correct. According to "IBM's 360 and Early > 370 Computers" (Pugh, Johnson and Palmer - a very good book, BTW), > pg. 507, the first Winchester was the 3340. The confusion comes from > the fact that it had two spindles, each of 30MB capacity, making it > a so-called "30-30" system - that being the name of Winchester's > rifle. There are competing stories about why it was called "Winchester". Another I have heard was that it was developed at IBM's facility in Winchester Boulevard in Campbell CA. But the Wikipedia article only gives the 30/30 version, so I suppose it must be right :-) 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 grog at lemis.com Wed Apr 25 10:52:51 2018 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Wed, 25 Apr 2018 10:52:51 +1000 Subject: [TUHS] 3330s, 3340s, Winchesters... (was: /dev/drum) In-Reply-To: References: <3A18DFEC-42B7-4234-9DD1-367733270D50@tfeb.org> <0abe01d3db28$b6573660$2305a320$@ronnatalie.com> <4b95c9f6-0190-be93-7284-d03be289c4ba@gmail.com> <20180424032830.GJ31055@eureka.lemis.com> Message-ID: <20180425005251.GL31055@eureka.lemis.com> On Tuesday, 24 April 2018 at 9:13:41 -0400, Clem Cole wrote: > On Tue, Apr 24, 2018 at 7:43 AM, Paul Winalski > wrote: > >> Clem claims that the code name refers to various advances in >> disk technology first released in the 3330's disk packs. Wikipedia >> and my own memory agree with you that Winchester referred to the 3340. > > ???Interesting ... My source was (is) my friend and former colleague from > Stellar, Russ Robelen, ???who was the HW lead for the 360/50 and the IBM ACS > systems. Russ said the original IBM project Winchester first begat the > platter (as Noel pointed out was so named because of the 30-30 capacity of > the original disk) - which showed up in the 3330 disks as well as the > sealed head stuff that Paul and Greg are talking about. Hmm. The earliest 3330s had 100 MB per disk, considerably more than the 3340. I had thought that the 3340 had fewer surfaces. And the 3330s definitely only had one disk per unit, though they brought out an 8-drive cabinet with a whopping 2.4 GB (by the time I used them). > What I never asked him, was where Memorex fit it. It was a somehow > a joint project with them, and they got at least some of the > technology -- in fact DEC's OEM for the RP05/RP06 was Memorex [the > big box of logic on the side of the DEC version was the Massbus to > IBM I/O logic converter]. It is also true that real lasting piece > of project Winchester was the embedded (sealed head) stuff that came > from the 3340. Yesterday I suggested that CDC might have used the same disk packs as the 3330, but I'm now very sure that the ones we used came from Ampex. > I should ask Russ what he remembers, on this. It would also be interesting to hear if he can shed any light on the Winchester Boulevard vs. 30/30 controversy. 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 drsalists at gmail.com Wed Apr 25 11:27:24 2018 From: drsalists at gmail.com (Dan Stromberg) Date: Tue, 24 Apr 2018 18:27:24 -0700 Subject: [TUHS] /dev/drum In-Reply-To: References: <8225C5DB-27BD-464E-930A-522C30C20EBD@tfeb.org> <25A1FED0-4F8B-408F-B27B-5728C649D8BE@collantes.us> <7wfu3nuqeb.fsf@junk.nocrew.org> Message-ID: On Sun, Apr 22, 2018 at 2:51 PM, Dave Horsfall wrote: > Now, how many youngsters know the difference between paging and swapping? I'm a mere 52, but I believe paging is preferred over swapping. Swapping is an entire process at a time. Paging is just a page of memory at a time - like 4K or something thereabout. BTW: I love Linux :) at least until something better comes along. From grog at lemis.com Wed Apr 25 11:31:34 2018 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Wed, 25 Apr 2018 11:31:34 +1000 Subject: [TUHS] Disk data layout (was: /dev/drum) In-Reply-To: <866bbea1-3a26-20a4-e233-1b8dc0ea2683@spamtrap.tnetconsulting.net> References: <7wfu3nuqeb.fsf@junk.nocrew.org> <3A18DFEC-42B7-4234-9DD1-367733270D50@tfeb.org> <0abe01d3db28$b6573660$2305a320$@ronnatalie.com> <866bbea1-3a26-20a4-e233-1b8dc0ea2683@spamtrap.tnetconsulting.net> Message-ID: <20180425013134.GM31055@eureka.lemis.com> On Monday, 23 April 2018 at 17:30:24 -0600, Grant Taylor via TUHS wrote: > On 04/23/2018 04:15 PM, Warner Losh wrote: >> It's weird. These days lower LBAs perform better on spinning >> drives. We're seeing about 1.5x better performance on the first >> 30% of a drive than on the last 30%, at least for read speeds for >> video streaming.... This relates to modern disks, of course, where there are different amounts of data on each track. Until about 1990 each track had a constant amount of data on it. > I think manufacturers have switched things around on us. I'm used > to higher LBA numbers being on the outside of the disk. But I've > seen anecdotal indicators that the opposite is now true. "LBA" is newer than the time we're talking of. In those days, disk data was addressed physically, by cylinder, head and sector, terms that only died out round the turn of the century. I was heavily involved in disk data recovery in the 1980s, and I know beyond any doubt that cylinder 0 was on the outside (closest to where the heads retracted before changing a pack). I was amazed when I discovered that CD-ROMs started counting from the inside. But how do I prove it? I've done some net trawling and looking through my pile of junk here, but I can't find anything convincing. http://www.datadoctor.biz/data_recovery_programming_book_chapter2-page16.html shows a layout like this, and also the statement The tracks are numbered, starting from 0, starting at the outside of the platter and increasing as you go in. But by itself that's not overly convincing. I looked at the manual for the IBM 3330, but I couldn't find anything specific. Does anybody else have any useful reference? Of course, you can map CHS to LBA in multiple ways, and conceivably it has been done differently. 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 hellwig.geisse at mni.thm.de Wed Apr 25 16:43:05 2018 From: hellwig.geisse at mni.thm.de (Hellwig Geisse) Date: Wed, 25 Apr 2018 08:43:05 +0200 Subject: [TUHS] Disk data layout (was: /dev/drum) In-Reply-To: <20180425013134.GM31055@eureka.lemis.com> References: <7wfu3nuqeb.fsf@junk.nocrew.org> <3A18DFEC-42B7-4234-9DD1-367733270D50@tfeb.org> <0abe01d3db28$b6573660$2305a320$@ronnatalie.com> <866bbea1-3a26-20a4-e233-1b8dc0ea2683@spamtrap.tnetconsulting.net> <20180425013134.GM31055@eureka.lemis.com> Message-ID: <1524638585.2138.26.camel@mni.thm.de> On Mi, 2018-04-25 at 11:31 +1000, Greg 'groggy' Lehey wrote: >  > But by itself that's not overly convincing.  I looked at the manual > for the IBM 3330, but I couldn't find anything specific.  Does anybody > else have any useful reference? > I kept the manual of the first hard disk drive that I ever integrated into a microcomputer system. This was a Shugart SA600 Fixed Disk Drive; the OEM manual is Copyright 1981. It had the (then) common 5.25" form factor, and could store 8 Mbytes on non-replaceable platters with 6 surfaces. Figure 2-4 in the manual shows the disk surface. "TRK 000" is the outermost track, "TRK 159" the innermost one. Even closer to the spindle is the "Head Shipping Zone" on "TRK 182", which could be accessed by a regular seek. Finally, section 4.4.1 explicitly states that the interface signal "Track 00" is true only when "the read/write heads of the selected drive are at track 00 (the outermost track)". Hellwig From ron at ronnatalie.com Wed Apr 25 22:18:24 2018 From: ron at ronnatalie.com (Ronald Natalie) Date: Wed, 25 Apr 2018 08:18:24 -0400 Subject: [TUHS] /dev/drum In-Reply-To: References: <8225C5DB-27BD-464E-930A-522C30C20EBD@tfeb.org> <25A1FED0-4F8B-408F-B27B-5728C649D8BE@collantes.us> <7wfu3nuqeb.fsf@junk.nocrew.org> Message-ID: <24637D2D-4865-4E45-821B-529CAEEA5589@ronnatalie.com> > On Apr 24, 2018, at 9:27 PM, Dan Stromberg wrote: > > On Sun, Apr 22, 2018 at 2:51 PM, Dave Horsfall wrote: >> Now, how many youngsters know the difference between paging and swapping? > > I'm a mere 52, but I believe paging is preferred over swapping. > > Swapping is an entire process at a time. > > Paging is just a page of memory at a time - like 4K or something thereabout. Early pages were 1K. The fun argument is what is Virtual Memory. Typically, people align that with paging but you can stretch the definition to cover paging. This was a point of contention in the early VAX Unix days as the ATT (System III, even V?) didn’t support paging on the VAX where as BSD did. Our comment was that “It ain’t VIRTUAL memory if it isn’t all there” as opposed to virtual addressing. From tfb at tfeb.org Wed Apr 25 23:39:39 2018 From: tfb at tfeb.org (Tim Bradshaw) Date: Wed, 25 Apr 2018 14:39:39 +0100 Subject: [TUHS] /dev/drum In-Reply-To: <24637D2D-4865-4E45-821B-529CAEEA5589@ronnatalie.com> References: <8225C5DB-27BD-464E-930A-522C30C20EBD@tfeb.org> <25A1FED0-4F8B-408F-B27B-5728C649D8BE@collantes.us> <7wfu3nuqeb.fsf@junk.nocrew.org> <24637D2D-4865-4E45-821B-529CAEEA5589@ronnatalie.com> Message-ID: <088160C2-AB5A-45DC-8A0D-377FC7A2E402@tfeb.org> On 25 Apr 2018, at 13:18, Ronald Natalie wrote: > > Early pages were 1K. Do systems with huge pages page in the move-them-to-disk sense I wonder? I assume they don't in practice because it would be insane but I wonder if the VM system is in theory even willing to try. Something I never completely understood in the paging vs swapping thing was that I think that systems which could page (well, 4.xBSD in particular) would *also* swap if pushed. I think the reason for that was that, if you were really short of memory, swapping freed up the process structure and also the page tables &c for the process, which would still be needed even if all its pages had been evicted. Is that right? -------------- next part -------------- An HTML attachment was scrubbed... URL: From tih at hamartun.priv.no Thu Apr 26 00:02:05 2018 From: tih at hamartun.priv.no (Tom Ivar Helbekkmo) Date: Wed, 25 Apr 2018 16:02:05 +0200 Subject: [TUHS] /dev/drum In-Reply-To: <0af301d3db31$35978800$a0c69800$@ronnatalie.com> (Ron Natalie's message of "Mon, 23 Apr 2018 14:30:51 -0400") References: <8225C5DB-27BD-464E-930A-522C30C20EBD@tfeb.org> <25A1FED0-4F8B-408F-B27B-5728C649D8BE@collantes.us> <7wfu3nuqeb.fsf@junk.nocrew.org> <3A18DFEC-42B7-4234-9DD1-367733270D50@tfeb.org> <0abe01d3db28$b6573660$2305a320$@ronnatalie.com> <0af301d3db31$35978800$a0c69800$@ronnatalie.com> Message-ID: Ron Natalie writes: > RK05’s were 4872 blocks. Don’t know why that number has stuck with > me, too many invocations of mkfs I guess. Oddly, DEC software for > some reason never used the last 72 blocks. I guess that's because they implemented DEC Standard 144, known as bad144 in BSD Unix. It's a system of remapping bad sectors to spares at the end of the disk. I had fun implementing that for the wd (ST506) disk driver in NetBSD, once upon a time... -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 steffen at sdaoden.eu Thu Apr 26 00:15:36 2018 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Wed, 25 Apr 2018 16:15:36 +0200 Subject: [TUHS] 3330s, 3340s, Winchesters... (was: /dev/drum) In-Reply-To: <20180425004734.GK31055@eureka.lemis.com> References: <20180424120612.CD71B18C07A@mercury.lcs.mit.edu> <20180425004734.GK31055@eureka.lemis.com> Message-ID: <20180425141536.9aiQ4%steffen@sdaoden.eu> Greg 'groggy' Lehey wrote: |On Tuesday, 24 April 2018 at 8:06:12 -0400, Noel Chiappa wrote: |>> From: Paul Winalski |> |>> Regarding the Winchester code name, I've argued about this with Clem |>> before. Clem claims that the code name refers to various advances in |>> disk technology first released in the 3330's disk packs. Wikipedia and |>> my own memory agree with you that Winchester referred to the 3340. |> |> And you believe anything in Wikipedia? | |Yes, most things, especially if they match my preconceived notions. | |To be fair, Wikipedia is relatively accurate. And if you find |something wrong in it and don't fix it, you have only yourself to |blame. It is not that easy. For example there are people which "sit" there for a long time. Not all of them are good. For example i saw an absolutely inacceptible abstract on the jubilee of the battle of the somme in german wikipedia, which would have been correct only if russians lifes have not the same value than those of others. My own account is blacklisted because of the IP range my reseller uses, and there are strange people here which do not only soil nature, poison animals and drive races with their BMWs, but they seem to soil Wikipedia, too. (I never did so!) Unfortunately the entire address range is blocked, i complained but logging in with password is impossible. (Seems to be the same problem that Zoulas' blacklist daemon fixes so nicely by patching daemons which know what a connection is about, with shell hooks which then can manage the firewall. Much, much better than having a script iterating over textual server logs periodically.) I could create a SSH tunnel to my server and connect from there, though. I have this option now. So i could fix the german wikipedia entries on the MBOX format etc., which seem to have been written to prompt someone who cares and fixes the false. On the other hand the german desk of the chemicals department have even won a price. (You know, german and chemicals is a love story: nitrogen fertilizer, mustard gas, neonicotinoids ... The americans are not even to blame for monsanto anymore!) --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 itz at very.loosely.org Thu Apr 26 00:33:05 2018 From: itz at very.loosely.org (Ian Zimmerman) Date: Wed, 25 Apr 2018 07:33:05 -0700 Subject: [TUHS] /dev/drum In-Reply-To: <24637D2D-4865-4E45-821B-529CAEEA5589@ronnatalie.com> References: <8225C5DB-27BD-464E-930A-522C30C20EBD@tfeb.org> <25A1FED0-4F8B-408F-B27B-5728C649D8BE@collantes.us> <7wfu3nuqeb.fsf@junk.nocrew.org> <24637D2D-4865-4E45-821B-529CAEEA5589@ronnatalie.com> Message-ID: <20180425143305.fts3jlxvhvrpmpam@matica.foolinux.mooo.com> On 2018-04-25 08:18, Ronald Natalie wrote: > The fun argument is what is Virtual Memory. Typically, people align > that with paging but you can stretch the definition to cover paging. > This was a point of contention in the early VAX Unix days as the ATT > (System III, even V?) didn’t support paging on the VAX where as BSD > did. Our comment was that “It ain’t VIRTUAL memory if it isn’t all > there” as opposed to virtual addressing. What about overlays? Virtual or not? The main difference may be where the code lives which brings non-present address space back into directly addressable state: in the kernel (and where: in an interrupt handler or higher up) or in userspace. -- Please don't Cc: me privately on mailing lists and Usenet, if you also post the followup to the list or newsgroup. To reply privately _only_ on Usenet and on broken lists which rewrite From, fetch the TXT record for no-use.mooo.com. From arnold at skeeve.com Thu Apr 26 00:02:24 2018 From: arnold at skeeve.com (arnold at skeeve.com) Date: Wed, 25 Apr 2018 08:02:24 -0600 Subject: [TUHS] /dev/drum In-Reply-To: <088160C2-AB5A-45DC-8A0D-377FC7A2E402@tfeb.org> References: <8225C5DB-27BD-464E-930A-522C30C20EBD@tfeb.org> <25A1FED0-4F8B-408F-B27B-5728C649D8BE@collantes.us> <7wfu3nuqeb.fsf@junk.nocrew.org> <24637D2D-4865-4E45-821B-529CAEEA5589@ronnatalie.com> <088160C2-AB5A-45DC-8A0D-377FC7A2E402@tfeb.org> Message-ID: <201804251402.w3PE2OSa017596@freefriends.org> > On 25 Apr 2018, at 13:18, Ronald Natalie wrote: > > > > Early pages were 1K. Tim Bradshaw wrote: > Do systems with huge pages page in the move-them-to-disk sense I wonder? > I assume they don't in practice because it would be insane but I wonder > if the VM system is in theory even willing to try. Why not? If there's enough backing store availble? Note that many systems demand page-in the code section straight out of the executable, so if some of those pages aren't needed, they can just be released. And said pages can be shared among all processes running the same executable, for further savings. > Something I never completely understood in the paging vs swapping > thing was that I think that systems which could page (well, 4.xBSD in > particular) would *also* swap if pushed. I think the reason for that was > that, if you were really short of memory, swapping freed up the process > structure and also the page tables &c for the process, which would still > be needed even if all its pages had been evicted. Is that right? It depends upon the system. Some had pageable page tables, which is pretty hairy. Others didn't. I don't remember what 4BSD did on the Vax, but I suspect that the page tables and enough info to find everything on swap stayed in kernel memory. (Where's Chris Torek when you need him? :-) But yes, swapping was generally used to free up large amounts of memory if under heavy load. HTH, Arnold From clemc at ccc.com Thu Apr 26 00:38:36 2018 From: clemc at ccc.com (Clem Cole) Date: Wed, 25 Apr 2018 10:38:36 -0400 Subject: [TUHS] /dev/drum In-Reply-To: References: <8225C5DB-27BD-464E-930A-522C30C20EBD@tfeb.org> <25A1FED0-4F8B-408F-B27B-5728C649D8BE@collantes.us> <7wfu3nuqeb.fsf@junk.nocrew.org> <3A18DFEC-42B7-4234-9DD1-367733270D50@tfeb.org> <0abe01d3db28$b6573660$2305a320$@ronnatalie.com> <0af301d3db31$35978800$a0c69800$@ronnatalie.com> Message-ID: On Wed, Apr 25, 2018 at 10:02 AM, Tom Ivar Helbekkmo via TUHS < tuhs at minnie.tuhs.org> wrote: > Ron Natalie writes: > > > RK05’s were 4872 blocks. Don’t know why that number has stuck with > > me, too many invocations of mkfs I guess. Oddly, DEC software for > > some reason never used the last 72 blocks. > > I guess that's because they implemented DEC Standard 144, known as > bad144 in BSD Unix. It's a system of remapping bad sectors to spares at > the end of the disk. I had fun implementing that for the wd (ST506) > disk driver in NetBSD, once upon a time... ​Right - back in the day, certainly for RK05's we would purchase 'perfect' media, because the original Unix implementations did not handled bad blocks. You had to be careful, but you could purchase perfect RP06 disk packs from one or two vendors. That got harder to do as the disks got larger *i.e*. the RMxx series. A disk pack pack typically shipped with either a physical piece of paper or a sticker attached to them with the HD/CLY bit offset and/or if pre-formatted HD/CLY/SEC of an bad spots (int he old days disks used different formats depending on the controller and different sector sizes, meta data etc, so the bad spots were listed a bit position per ring). A typical thing that a number of us did if we did not have a perfect pack was, after we did the Unix mkfs, manually create a file in either root, or lost+found called bad_blocks, and then using fsdb or the like, assign the blocks that file. The problem was the concept of 'grown' bad spots. I'll stay away from the argument if they were possible or not (long story), but if in practice a pack ended up with a block that was causing issues after it was deployed (which did happen in practice). You needed to assign the bad block to the bad_block file manual. BAD144 was a scheme DEC had to reserve a few blocks and then map out any bad sectors. The problem of course, was that it screwed up all the prediction SW in the OS, as system would ask for block/cyl/sec - X/Y/Z and it could force a head seek to the of the drive to get one of those reserved blocks in the end of the disk. The advantage of the DEC scheme was the during formatting the known bad sectors would become 'invisible' and of course if the pack 'grew' and error the driver could add it to the list and replace the block on the fly (assuming there were available blocks in the reserved table). An interesting story on BAD144 - a good example of the original ideas of Open Source. It was actually the DEC 'Telephone Industries Group" in Merrimack, NH (*a.k.a.* TIG) that had Armando, Fred Canter *et. al.* that wrote the original support for DEC Standard 144; to help support the AT&T customers, pre Ultrix (remember for a long time AT&T was DEC'S largest customer). Once written, that code was also given to CRSG and released into the wild via the UCB stream (and of course would become part of Ultrix when DEC finally 'supported' UNIX officially). I've long ago forgotten, but aps might remember, I think is Fred that did the original work. ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Thu Apr 26 00:46:04 2018 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 25 Apr 2018 07:46:04 -0700 Subject: [TUHS] /dev/drum In-Reply-To: <20180425143305.fts3jlxvhvrpmpam@matica.foolinux.mooo.com> References: <8225C5DB-27BD-464E-930A-522C30C20EBD@tfeb.org> <25A1FED0-4F8B-408F-B27B-5728C649D8BE@collantes.us> <7wfu3nuqeb.fsf@junk.nocrew.org> <24637D2D-4865-4E45-821B-529CAEEA5589@ronnatalie.com> <20180425143305.fts3jlxvhvrpmpam@matica.foolinux.mooo.com> Message-ID: <20180425144604.GB15245@mcvoy.com> So is this also /dev/drums? https://www.youtube.com/watch?v=_pe6r06EIz0&feature=youtu.be -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From tfb at tfeb.org Thu Apr 26 00:59:48 2018 From: tfb at tfeb.org (tfb at tfeb.org) Date: Wed, 25 Apr 2018 15:59:48 +0100 Subject: [TUHS] /dev/drum In-Reply-To: <201804251402.w3PE2OSa017596@freefriends.org> References: <8225C5DB-27BD-464E-930A-522C30C20EBD@tfeb.org> <25A1FED0-4F8B-408F-B27B-5728C649D8BE@collantes.us> <7wfu3nuqeb.fsf@junk.nocrew.org> <24637D2D-4865-4E45-821B-529CAEEA5589@ronnatalie.com> <088160C2-AB5A-45DC-8A0D-377FC7A2E402@tfeb.org> <201804251402.w3PE2OSa017596@freefriends.org> Message-ID: <207B81D6-896A-4399-B3F8-7ED163FCAF95@tfeb.org> On 25 Apr 2018, at 15:02, arnold at skeeve.com wrote: > > Why not? If there's enough backing store availble? Well, I think because the situations where you are using huge pages and the situations where you're paging to backing store should really be mutually exclusive: if your system is paging to backing store you have problems which huge pages are not going to solve. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rminnich at gmail.com Thu Apr 26 01:03:47 2018 From: rminnich at gmail.com (ron minnich) Date: Wed, 25 Apr 2018 15:03:47 +0000 Subject: [TUHS] /dev/drum In-Reply-To: <20180425144604.GB15245@mcvoy.com> References: <8225C5DB-27BD-464E-930A-522C30C20EBD@tfeb.org> <25A1FED0-4F8B-408F-B27B-5728C649D8BE@collantes.us> <7wfu3nuqeb.fsf@junk.nocrew.org> <24637D2D-4865-4E45-821B-529CAEEA5589@ronnatalie.com> <20180425143305.fts3jlxvhvrpmpam@matica.foolinux.mooo.com> <20180425144604.GB15245@mcvoy.com> Message-ID: some of you doubtless remember the term 'expansion swap'. I was joking that at some companies, you seem to be moved just so you can end up in places where you have less room. I called this a 'compression swap'. Nobody got the joke. Oh well. ron -------------- next part -------------- An HTML attachment was scrubbed... URL: From winkywooster at gmail.com Thu Apr 26 06:22:54 2018 From: winkywooster at gmail.com (Eric Blood) Date: Wed, 25 Apr 2018 14:22:54 -0600 Subject: [TUHS] rm command Message-ID: I came across this yesterday: > Fun fact: according to unsubstantiated UNIX lore, "rm" is NOT short-hand > for "remove" but rather, it stands for the initials of the developer that wrote > the original implementation, Robert Morris. > > https://news.ycombinator.com/item?id=16916565 I was curious if there's any truth to it. I found http://minnie.tuhs.org/cgi-bin/utree.pl and was poking around but couldn't determine when the rm command came about. Thoughts? -- Eric Blood winkywooster at gmail.com From paul.winalski at gmail.com Thu Apr 26 06:29:41 2018 From: paul.winalski at gmail.com (Paul Winalski) Date: Wed, 25 Apr 2018 16:29:41 -0400 Subject: [TUHS] /dev/drum In-Reply-To: <24637D2D-4865-4E45-821B-529CAEEA5589@ronnatalie.com> References: <8225C5DB-27BD-464E-930A-522C30C20EBD@tfeb.org> <25A1FED0-4F8B-408F-B27B-5728C649D8BE@collantes.us> <7wfu3nuqeb.fsf@junk.nocrew.org> <24637D2D-4865-4E45-821B-529CAEEA5589@ronnatalie.com> Message-ID: On 4/25/18, Ronald Natalie wrote: > > Early pages were 1K. On the VAX, pages were 512 bytes, the same size as a disk record. > The fun argument is what is Virtual Memory. Typically, people align that > with paging but you can stretch the definition to cover paging. > This was a point of contention in the early VAX Unix days as the ATT (System > III, even V?) didn’t support paging on the VAX where as BSD did. In my book, virtual memory is any addressing scheme where the addresses that the program uses are different from the physical memory addresses. Nowadays most OSes use a scheme where each process has its own virtual address space, and virtual memory is demand-paged from backing store on disk. But there have been other schemes. Some PDP-11 models had a virtual addressing feature called PLAS (Program Logical Address Space). The PDP-11 had 16-bit addressing, allowing for at most 64K per process. To take advantage of physical memory larger than 64K, PLAS allowed multiple 64K virtual address spaces to be mapped to the larger physical memory. Sort of the reverse of the usual virtual addressing scheme, where there is more virtual memory than physical memory. IBM Disk Operating System for the System/370 (DOS/VS) had a single virtual address space that could be bigger than physical memory and was demand-paged. This address space could be divided into up to five partitions, each of which could run a program. Each partition thus represents what we now call a process. IBM OS/VS1 and OS/VS2 SVS also had a single virtual address space shared by all tasks (processes). OS/VS2 MVS had the modern concept of a separate virtual address space for each process. > Our comment was that “It ain’t VIRTUAL memory if it isn’t all there” as > opposed to virtual addressing. Gene Amdahl was not a fan of paging. He said that virtual memory merely magnifies the need for real memory. -Paul W. From lm at mcvoy.com Thu Apr 26 06:45:48 2018 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 25 Apr 2018 13:45:48 -0700 Subject: [TUHS] /dev/drum In-Reply-To: References: <8225C5DB-27BD-464E-930A-522C30C20EBD@tfeb.org> <25A1FED0-4F8B-408F-B27B-5728C649D8BE@collantes.us> <7wfu3nuqeb.fsf@junk.nocrew.org> <24637D2D-4865-4E45-821B-529CAEEA5589@ronnatalie.com> Message-ID: <20180425204548.GI15245@mcvoy.com> > > Our comment was that ???It ain???t VIRTUAL memory if it isn???t all there??? as > > opposed to virtual addressing. > > Gene Amdahl was not a fan of paging. He said that virtual memory > merely magnifies the need for real memory. Wasn't that a Seymour Cray quote? Seems like he was also not a fan of VM. From paul.winalski at gmail.com Thu Apr 26 06:54:16 2018 From: paul.winalski at gmail.com (Paul Winalski) Date: Wed, 25 Apr 2018 16:54:16 -0400 Subject: [TUHS] 3330s, 3340s, Winchesters... (was: /dev/drum) In-Reply-To: <20180425005251.GL31055@eureka.lemis.com> References: <3A18DFEC-42B7-4234-9DD1-367733270D50@tfeb.org> <0abe01d3db28$b6573660$2305a320$@ronnatalie.com> <4b95c9f6-0190-be93-7284-d03be289c4ba@gmail.com> <20180424032830.GJ31055@eureka.lemis.com> <20180425005251.GL31055@eureka.lemis.com> Message-ID: On 4/24/18, Greg 'groggy' Lehey wrote: > > Hmm. The earliest 3330s had 100 MB per disk, considerably more than > the 3340. I had thought that the 3340 had fewer surfaces. And the > 3330s definitely only had one disk per unit, though they brought out > an 8-drive cabinet with a whopping 2.4 GB (by the time I used them). The 3340 indeed had fewer platters per unit than the 3330, and because of that a lower disk capacity. Both the 3330 and 3340 were CKD format, not fixed-block, so the capacity depended on the record size. Highest storage capacity was achieved with one record with a zero-length key field covering the full track (called full-track blocking). According to the IBM Archives web page (https://www-03.ibm.com/ibm/history/exhibits/storage/storage_3330.html), the 3330 was code-named Merlin. It could have from 2 to 16 spindles per controller. Originally each disk pack had a maximum capacity of 100 MB. The 3330 model 11 used IBM 3336 disk packs that had double the original capacity (up to 200 MB). This IBM Archives web page (https://www-03.ibm.com/ibm/history/exhibits/storage/storage_3340.html) says that the 3340 was code-named Winchester. This page reports, but does not verify, the "30-30" Winchester rifle story. The IBM 3348 Data Module, the disk pack equivalent for the 3340, was a sealed module that contained the head assembly. This reduced the hazards of head misalignment and surface contamination. Unlike later sealed-module disks, the 3348s were removable media. Modules with maximum capacities of 35 MB or 70 MB were available. There was also a 70 MB module with up to 0.5 MB accessible from fixed heads. -Paul W. From stewart at serissa.com Thu Apr 26 07:14:14 2018 From: stewart at serissa.com (Lawrence Stewart) Date: Wed, 25 Apr 2018 17:14:14 -0400 Subject: [TUHS] /dev/drum In-Reply-To: <20180425204548.GI15245@mcvoy.com> References: <8225C5DB-27BD-464E-930A-522C30C20EBD@tfeb.org> <25A1FED0-4F8B-408F-B27B-5728C649D8BE@collantes.us> <7wfu3nuqeb.fsf@junk.nocrew.org> <24637D2D-4865-4E45-821B-529CAEEA5589@ronnatalie.com> <20180425204548.GI15245@mcvoy.com> Message-ID: > On 2018, Apr 25, at 4:45 PM, Larry McVoy wrote: > >>> Our comment was that ???It ain???t VIRTUAL memory if it isn???t all there??? as >>> opposed to virtual addressing. >> >> Gene Amdahl was not a fan of paging. He said that virtual memory >> merely magnifies the need for real memory. > > Wasn't that a Seymour Cray quote? Seems like he was also not a fan of VM. My favorite is due to Dave Clark at MIT: “Anytime someone says ‘virtual’ you should think ‘slow’” followed closely by “Any problem in computer science can be solved by adding a layer of abstraction” and “Any performance problem can be solved by removing a layer of abstraction.” As one converted to the HPC cults, I am naturally opposed to small pages, virtual anything, and interrupts… -L From paul.winalski at gmail.com Thu Apr 26 07:17:49 2018 From: paul.winalski at gmail.com (Paul Winalski) Date: Wed, 25 Apr 2018 17:17:49 -0400 Subject: [TUHS] Disk data layout (was: /dev/drum) In-Reply-To: <20180425013134.GM31055@eureka.lemis.com> References: <7wfu3nuqeb.fsf@junk.nocrew.org> <3A18DFEC-42B7-4234-9DD1-367733270D50@tfeb.org> <0abe01d3db28$b6573660$2305a320$@ronnatalie.com> <866bbea1-3a26-20a4-e233-1b8dc0ea2683@spamtrap.tnetconsulting.net> <20180425013134.GM31055@eureka.lemis.com> Message-ID: On 4/24/18, Greg 'groggy' Lehey wrote: > > "LBA" is newer than the time we're talking of. In those days, disk > data was addressed physically, by cylinder, head and sector, terms > that only died out round the turn of the century. IBM DASD--Direct Access Storage Device, a term that encompassed drums, disks and the data cell drive--addressed data on the media physically by bin, cylinder, head, and record, as a hexadecimal number BBCCHHR. Bin number was zero except on the IBM 2321 data cell drive. CKD drives supported a variable number of records on each track, hence the term "record" rather than "sector". Logical block addressing (LBA) for sector-oriented disks allowed the OS (or later, the disk controller) to hide bad block replacement from programs. VAX/VMS used a protected system file ([sysexe]badblock.sys) to keep track of the bad blocks on each disk volume. DEC once got a customer bug report complaining that if a privileged user gave the command "TYPE SYS$SYSTEM:BADBLOCK.SYS", the console logged bad block errors. How does/did Unix handle bad block replacement? -Paul W. From ralph at inputplus.co.uk Thu Apr 26 07:23:36 2018 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Wed, 25 Apr 2018 22:23:36 +0100 Subject: [TUHS] rm command In-Reply-To: References: Message-ID: <20180425212336.DDFB9206BE@orac.inputplus.co.uk> Hi Eric, > > it stands for the initials of the developer that wrote > > the original implementation, Robert Morris. http://minnie.tuhs.org/cgi-bin/utree.pl?file=V1/man/man1/rm.1, i.e. 1st Ed., says the OWNER is `ken, dmr' so it seems unlikely as I understand Bell Labs worked on a `last to touch it, owns it' principle. http://minnie.tuhs.org/cgi-bin/utree.pl?file=V1/u2.s has sysunlink. It's such a fundamental command that I'd have thought it was an early obvious addition, and a small one at that. Bob Morris seemed to always be involved in the more intricate stuff like various crypt(3)s, and TML, based on what we hear about him. (Google didn't seem to turn up much on TML.) -- Cheers, Ralph. https://plus.google.com/+RalphCorderoy From doug at cs.dartmouth.edu Thu Apr 26 07:30:17 2018 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Wed, 25 Apr 2018 17:30:17 -0400 Subject: [TUHS] [TUHS} rm command Message-ID: <201804252130.w3PLUHRb021294@coolidge.cs.Dartmouth.EDU> Fake news knocks on the doors of Unixland: there's absolutely no truth to the claim that the rm command was written by Robert Morris. Rm was there from the beginning, when only two people wrote Unix code--Thompson and Ritchie. In fact, it would have been on PDP8 Unix, which Morris never used. Doug From rminnich at gmail.com Thu Apr 26 07:30:13 2018 From: rminnich at gmail.com (ron minnich) Date: Wed, 25 Apr 2018 21:30:13 +0000 Subject: [TUHS] /dev/drum In-Reply-To: References: <8225C5DB-27BD-464E-930A-522C30C20EBD@tfeb.org> <25A1FED0-4F8B-408F-B27B-5728C649D8BE@collantes.us> <7wfu3nuqeb.fsf@junk.nocrew.org> <24637D2D-4865-4E45-821B-529CAEEA5589@ronnatalie.com> <20180425204548.GI15245@mcvoy.com> Message-ID: there's an interesting parallel discussion going on over at riscv about page size. 4k won the day. fairly shocking in a world of 4 TiB systems but ... ron On Wed, Apr 25, 2018 at 2:21 PM Lawrence Stewart wrote: > > > On 2018, Apr 25, at 4:45 PM, Larry McVoy wrote: > > > >>> Our comment was that ???It ain???t VIRTUAL memory if it isn???t all > there??? as > >>> opposed to virtual addressing. > >> > >> Gene Amdahl was not a fan of paging. He said that virtual memory > >> merely magnifies the need for real memory. > > > > Wasn't that a Seymour Cray quote? Seems like he was also not a fan of > VM. > > My favorite is due to Dave Clark at MIT: “Anytime someone says ‘virtual’ > you should think ‘slow’” > > followed closely by “Any problem in computer science can be solved by > adding a layer of abstraction” and “Any performance problem can be solved > by removing a layer of abstraction.” > > As one converted to the HPC cults, I am naturally opposed to small pages, > virtual anything, and interrupts… > > -L > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jpl.jpl at gmail.com Thu Apr 26 07:33:24 2018 From: jpl.jpl at gmail.com (John P. Linderman) Date: Wed, 25 Apr 2018 14:33:24 -0700 Subject: [TUHS] rm command In-Reply-To: References: Message-ID: Another country heard from. I doubt the Robert Morris story, given that a command as fundamental as "rm" must have come about very early in the development, and there isn't a pattern of naming commands after their authors. On Wed, Apr 25, 2018 at 1:22 PM, Eric Blood wrote: > I came across this yesterday: > > > Fun fact: according to unsubstantiated UNIX lore, "rm" is NOT short-hand > > for "remove" but rather, it stands for the initials of the developer > that wrote > > the original implementation, Robert Morris. > > > > https://news.ycombinator.com/item?id=16916565 > > I was curious if there's any truth to it. I found > http://minnie.tuhs.org/cgi-bin/utree.pl and was poking around but > couldn't determine when the rm command came about. > > Thoughts? > > -- > Eric Blood > winkywooster at gmail.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bqt at update.uu.se Thu Apr 26 07:43:42 2018 From: bqt at update.uu.se (Johnny Billquist) Date: Wed, 25 Apr 2018 23:43:42 +0200 Subject: [TUHS] /dev/drum In-Reply-To: References: Message-ID: <2f1b9b1a-0513-7035-3e9a-7695809e7747@update.uu.se> On 2018-04-25 16:39, Ronald Natalie wrote: > >> On Apr 24, 2018, at 9:27 PM, Dan Stromberg wrote: >> >> On Sun, Apr 22, 2018 at 2:51 PM, Dave Horsfall wrote: >>> Now, how many youngsters know the difference between paging and swapping? >> I'm a mere 52, but I believe paging is preferred over swapping. >> >> Swapping is an entire process at a time. >> >> Paging is just a page of memory at a time - like 4K or something thereabout. > Early pages were 1K. What machines are we talking about then? PDP-11 have 8K pages. VAX have 512 byte pages, if we talk about hardware. (And yes, I know pages on PDP-11s are not fixed in size, but if you want the page to go right up to the next page, it's 8K.) > The fun argument is what is Virtual Memory. Typically, people align that with paging but you can stretch the definition to cover paging. > This was a point of contention in the early VAX Unix days as the ATT (System III, even V?) didn’t support paging on the VAX where as BSD did. > Our comment was that “It ain’t VIRTUAL memory if it isn’t all there” as opposed to virtual addressing. Weird comment. What does that mean? On a PDP-11, all your virtual memory was always there when the process was on the CPU, but it might not be there at other times. Just as not all processes memory would be in physical memory all the time, since that often would require more physical memory than you had. But you normally did not have demand paging, since that was not really gaining you much on a PDP-11. On the other hand, overlays do the same thing for you, but in userspace. So you would claim that ATT Unix did not have virtual memory because it didn't do demand paging? 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 wlc at jctaylor.com Thu Apr 26 07:53:26 2018 From: wlc at jctaylor.com (William Corcoran) Date: Wed, 25 Apr 2018 21:53:26 +0000 Subject: [TUHS] rm command In-Reply-To: References: , Message-ID: Agreed. Plus, it’s unmistakable that rm meant “remove” when you examine her sister “rmdir.” I think it’s a bit more interesting to uncover why rm does not remove directories by default thereby obviating the need for rmdir—-especially since the potentially nightmarish incantation of “rm -rf” does include files, folders and just about everything else in between. Bill Corcoran On Apr 25, 2018, at 5:36 PM, John P. Linderman > wrote: Another country heard from. I doubt the Robert Morris story, given that a command as fundamental as "rm" must have come about very early in the development, and there isn't a pattern of naming commands after their authors. On Wed, Apr 25, 2018 at 1:22 PM, Eric Blood > wrote: I came across this yesterday: > Fun fact: according to unsubstantiated UNIX lore, "rm" is NOT short-hand > for "remove" but rather, it stands for the initials of the developer that wrote > the original implementation, Robert Morris. > > https://news.ycombinator.com/item?id=16916565 I was curious if there's any truth to it. I found http://minnie.tuhs.org/cgi-bin/utree.pl and was poking around but couldn't determine when the rm command came about. Thoughts? -- Eric Blood winkywooster at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From bakul at bitblocks.com Thu Apr 26 07:55:29 2018 From: bakul at bitblocks.com (Bakul Shah) Date: Wed, 25 Apr 2018 14:55:29 -0700 Subject: [TUHS] Disk data layout (was: /dev/drum) In-Reply-To: References: <7wfu3nuqeb.fsf@junk.nocrew.org> <3A18DFEC-42B7-4234-9DD1-367733270D50@tfeb.org> <0abe01d3db28$b6573660$2305a320$@ronnatalie.com> <866bbea1-3a26-20a4-e233-1b8dc0ea2683@spamtrap.tnetconsulting.net> <20180425013134.GM31055@eureka.lemis.com> Message-ID: @Fortune Systems we kept a forwarding map of bad blocks. This was stored in a file at inode#1 IIRC. To read/write block n you check if n was in the list. If not, you read/write disk block n. Else you use the mapped block. The last N blocks were reserved for this. Actually we had to keep some state. A block that gave an error on read was marked bad so that further reads errored out. But a write to such a block would allocate a new block and add an entry in the bad block forwarding map. Further read/writes would then Go to this block. I also kept soft (correctable) error stats. These blocks were more likely to go bad so periodically a background task would preemptively forward these blocks. To test this logic I used to build the v7 kernel on a very unreliable disk! But this slowed things down a lot - having to seek to the end zone and then back for the next block. I think in later disk drives an extra block per track was reserved for this and the drive took care of this. It would’ve made more sense to avoid this forwarding by exposing bad blocks to the file system layer so that it can avoid allocating them but this would’ve complicated the interface. > On Apr 25, 2018, at 2:17 PM, Paul Winalski wrote: > > How does/did Unix handle bad block replacement? From dfawcus+lists-tuhs at employees.org Thu Apr 26 07:58:58 2018 From: dfawcus+lists-tuhs at employees.org (Derek Fawcus) Date: Wed, 25 Apr 2018 22:58:58 +0100 Subject: [TUHS] rm command In-Reply-To: References: Message-ID: <20180425215858.GA1568@accordion.employees.org> On Wed, Apr 25, 2018 at 09:53:26PM +0000, William Corcoran wrote: > Agreed. Plus, it’s unmistakable that rm meant “remove” when you examine her sister “rmdir.” > > I think it’s a bit more interesting to uncover why rm does not remove directories by default thereby obviating the need for rmdir—-especially since the potentially nightmarish incantation of “rm -rf” does include files, folders and just about everything else in between. Maybe because rm could just be wrapper around unlink, whereas rmdir also had to remove '.' and '..' before unlinking the directory? Or maybe just symmetry with mkdir which had to use mknod, and manual population of '.' and '..'? DF From ralph at inputplus.co.uk Thu Apr 26 08:09:16 2018 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Wed, 25 Apr 2018 23:09:16 +0100 Subject: [TUHS] rm command In-Reply-To: References: , Message-ID: <20180425220916.63C52206BE@orac.inputplus.co.uk> Hi Bill, > I think it’s a bit more interesting to uncover why rm does not remove > directories by default thereby obviating the need for rmdir Well, I'd guess it's: rm just does a single unlink to decrement an inode's reference count by one, actually increment it since they were negative, whereas rmdir on an empty directory needs to do two decrements, one for its directory entry in the parent, and one for `..'. (I think hard links could apply to directories in the early days, until it made things too awkward, e.g. du(1) and cycles.) -- Cheers, Ralph. https://plus.google.com/+RalphCorderoy From jnc at mercury.lcs.mit.edu Thu Apr 26 08:17:16 2018 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Wed, 25 Apr 2018 18:17:16 -0400 (EDT) Subject: [TUHS] rm command Message-ID: <20180425221716.B4C6718C086@mercury.lcs.mit.edu> > From: William Corcoran > I think it's a bit more interesting to uncover why rm does not remove > directories by default thereby obviating the need for rmdir On early PDP-11 Unixes, 'rm' is an ordinary program, and 'rmdir' is setuid-root, since it has to do special magic (writing into directory files, etc). Given that, it made sense to have 'rm' run with the least amount of privilege needed to do its job. Noel From bqt at update.uu.se Thu Apr 26 08:24:34 2018 From: bqt at update.uu.se (Johnny Billquist) Date: Thu, 26 Apr 2018 00:24:34 +0200 Subject: [TUHS] /dev/drum In-Reply-To: References: Message-ID: <55000939-330c-85fe-7b07-5711b3578ecb@update.uu.se> On 2018-04-25 16:39, Tom Ivar Helbekkmo wrote: > > Ron Natalie writes: > >> RK05’s were 4872 blocks. Don’t know why that number has stuck with >> me, too many invocations of mkfs I guess. Oddly, DEC software for >> some reason never used the last 72 blocks. > I guess that's because they implemented DEC Standard 144, known as > bad144 in BSD Unix. It's a system of remapping bad sectors to spares at > the end of the disk. I had fun implementing that for the wd (ST506) > disk driver in NetBSD, once upon a time... Uh... DEC STD 144 does not have anything to do with remapping bad blocks to replacement good blocks. DEC STD 144 describes how a media stores known bad blocks on a disk, so that file system initialization can then take whatever action needed to that these blocks are not used by anything. In RSX (and VMS), they will be included in a file called BADBLK.SYS, and thus be perceived as "used". bad144 in NetBSD will keep the a table in memory for such disks, and "skip" blocks listed in the list as bad, meaning all other blocks gets shifted. So it sortof do a remapping to good blocks by extending the used blocks, and does not allocate anything at the end of the disk per se. However, that is a Unix specific solution. OS/8 had a similar solution for RL01 and RL02 drives, but not RK05 (as RK05 disks don't follow DEC STD 144.) I don't know exactly why DEC left the last three tracks unused. Might have been for diagnostic tools to have a scratch area to play with. Might have been that those tracks were found to be less reliable. Or maybe something completely different. But it was not for bad block replacement, as DEC didn't even do that on RK05 (or more or less in general at all before MSCP. MSCP, by the way, does not use DEC STD 144.) Something Unix and other implementations usually miss with DEC STD 144 is that there are actually two tables with bad blocks defined by the standard. There is the manufacturer defined bad blocks, which all software seems to know and deal with, and there are the user defined bad blocks, which are supposed to be where all bad blocks that develop after manufacture are supposed to be placed. Lots of software does not deal with this second list. In addition, you also have the pack serial number and some stuff defined by DEC STD 144, which is also recorded on the last track, where the bad block lists also are stored. Note that this information is supposed to be on the last track, meaning you cannot use the scheme Unix uses to remap bad blocks, unless you keep some blocks before the last track unallocated. The ultimate irony was when I discovered that bad144 under NetBSD was only built for x86 machine, and not being built for VAX, which is the only architecture supported which actually have real disks which follow the DEC STD 144. But that was corrected about 20 years ago now (time flies). 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 bqt at update.uu.se Thu Apr 26 08:37:09 2018 From: bqt at update.uu.se (Johnny Billquist) Date: Thu, 26 Apr 2018 00:37:09 +0200 Subject: [TUHS] /dev/drum In-Reply-To: References: Message-ID: <0224de12-ef13-adfc-1e1f-c50e349510d4@update.uu.se> On 2018-04-25 16:39, arnold at skeeve.com wrote: > Tim Bradshaw wrote: > >> Do systems with huge pages page in the move-them-to-disk sense I wonder? >> I assume they don't in practice because it would be insane but I wonder >> if the VM system is in theory even willing to try. > Why not? If there's enough backing store availble? > > Note that many systems demand page-in the code section straight out of the > executable, so if some of those pages aren't needed, they can just > be released. And said pages can be shared among all processes running > the same executable, for further savings. Right. >> Something I never completely understood in the paging vs swapping >> thing was that I think that systems which could page (well, 4.xBSD in >> particular) would*also* swap if pushed. I think the reason for that was >> that, if you were really short of memory, swapping freed up the process >> structure and also the page tables &c for the process, which would still >> be needed even if all its pages had been evicted. Is that right? > It depends upon the system. Some had pageable page tables, which is > pretty hairy. Others didn't. I don't remember what 4BSD did on the > Vax, but I suspect that the page tables and enough info to find everything > on swap stayed in kernel memory. (Where's Chris Torek when you need > him?:-) The pages tables describing the users memory space are themselves located in virtual memory on the VAX, so they can be paged out without problem. If you refer to an entry in the user page table, and that page itself is paged out, you'll get a page fault for the system page table, so you'll need to page in that page of the system. But I seem to remember 4BSD (as well as NetBSD) keep all of the kernel in physical memory all the time, and don't page the kernel parts, including process page tables. > But yes, swapping was generally used to free up large amounts of memory > if under heavy load. Paging would free up the same amount of memory, if we talk about the memory used by the process itself. However, there are various meta data in the kernel itself that is needed for a process, which will remain in memory even if no pages are in memory. Swapping will also move non-essential kernel structures out to disk for the process, in addition to the pages. Thus, there is a difference between swapping and paging. The whole process context for example. Which includes both the page tables as well as the kernel mode stack for the process, processor registers, and possibly also open file contexts, and probably some other things I'm forgetting now. Very little needs to be kept in memory for a process if you are not interested in resuming it on short notice. 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 jnc at mercury.lcs.mit.edu Thu Apr 26 08:46:46 2018 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Wed, 25 Apr 2018 18:46:46 -0400 (EDT) Subject: [TUHS] /dev/drum Message-ID: <20180425224646.80DB718C086@mercury.lcs.mit.edu> > From: Johnny Billquist > I don't know exactly why DEC left the last three tracks unused. Might > have been for diagnostic tools to have a scratch area to play with. > Might have been that those tracks were found to be less reliable. Or > maybe something completely different. But it was not for bad block > replacement, as DEC didn't even do that on RK05 The "pdp11 peripherals handbook" (1975 edition at least, I can't be bothered to check them all) says, for the RK11: "Tracks/surface: 200+3 spare" and for the RP11: "Tracks/surface: 400 (plus 6 spares)" which sounds like it could be for bad block replacement, but the RP11-C Maintenance Manual says (pg. 3-10) "the inner-most cylinders 400-405 are only used for maintenance". Unix blithely ignored all that, and used every block available on both the RK11 and RP11. Noel From bqt at update.uu.se Thu Apr 26 08:54:02 2018 From: bqt at update.uu.se (Johnny Billquist) Date: Thu, 26 Apr 2018 00:54:02 +0200 Subject: [TUHS] /dev/drum In-Reply-To: References: Message-ID: On 2018-04-25 23:14, Paul Winalski wrote: > On 4/25/18, Ronald Natalie > wrote: >> The fun argument is what is Virtual Memory. Typically, people align that >> with paging but you can stretch the definition to cover paging. >> This was a point of contention in the early VAX Unix days as the ATT (System >> III, even V?) didn’t support paging on the VAX where as BSD did. > In my book, virtual memory is any addressing scheme where the > addresses that the program uses are different from the physical memory > addresses. Nowadays most OSes use a scheme where each process has its > own virtual address space, and virtual memory is demand-paged from > backing store on disk. But there have been other schemes. Yeah... > Some PDP-11 models had a virtual addressing feature called PLAS > (Program Logical Address Space). The PDP-11 had 16-bit addressing, > allowing for at most 64K per process. To take advantage of physical > memory larger than 64K, PLAS allowed multiple 64K virtual address > spaces to be mapped to the larger physical memory. Sort of the > reverse of the usual virtual addressing scheme, where there is more > virtual memory than physical memory. Note that PLAS is not a PDP-11 hardware thing. PLAS was the name for the mechanism provided by the OS for applications to be able to access more than 64K of memory while still be limited by the virtual address space limit of 64K. PLAS is in one way very similar to mmap, except that it's not backed by a file. But you create a memory region though the OS (giving it a name and a size, which can be more than 64K), and then you can map to it, specifying the offset into it and window size, as well as where to map to in your virtual address space. This is realized by just using the pages of the MMU of the PDP-11 map to different parts and things. Any OS that had the PLAS capability by necessity had to have an MMU, which was the hardware part that allowed this to be implemented. So, all PDP-11s with an MMU could allow the OS running on it to provide the PLAS capabilities. A PDP-11 in general is "reversed" in that the physical address space is much larger than the virtual one. Although, the same was also true on the VAX in the last iteration where the NVAX implementation allowed for a 34 bit physical address, while the virtual address space was still only 32 bits. But that doesn't make the virtual memory any less virtual. 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 jnc at mercury.lcs.mit.edu Thu Apr 26 08:55:51 2018 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Wed, 25 Apr 2018 18:55:51 -0400 (EDT) Subject: [TUHS] /dev/drum Message-ID: <20180425225551.3685318C086@mercury.lcs.mit.edu> > From: Johnny Billquist > PDP-11 have 8K pages. Segments. :-) (This is an old argument between Johnny and me, I'm not trying to re-open it, just yanking his chain... :-) > On a PDP-11, all your virtual memory was always there when the process > was on the CPU In theory, at least (I don't know of an OS that made use of this), didn't the memory management hardware allow the possibility to do demand-paging? I note that Access Control Field value 0 is "non-resident". Unix kinda-sorta used this stuff, to automatically extend the stack when the user ran off the end of it (causing a trap). > you normally did not have demand paging, since that was not really > gaining you much on a PDP-11 Especially on the later machines, with more than 256KB of hardware main memory. Maybe it might have been useful on the earlier ones (e.g. the -11/45). Noel From bakul at bitblocks.com Thu Apr 26 09:01:37 2018 From: bakul at bitblocks.com (Bakul Shah) Date: Wed, 25 Apr 2018 16:01:37 -0700 Subject: [TUHS] /dev/drum In-Reply-To: References: <8225C5DB-27BD-464E-930A-522C30C20EBD@tfeb.org> <25A1FED0-4F8B-408F-B27B-5728C649D8BE@collantes.us> <7wfu3nuqeb.fsf@junk.nocrew.org> <24637D2D-4865-4E45-821B-529CAEEA5589@ronnatalie.com> Message-ID: <22516FB0-C89C-4727-B171-BEB84B27DD7C@bitblocks.com> This is what we did at Fortune Systems for our 68k based v7 system. There was an external “mmu” which added a base value to a 16 bit virtual address to compute a physical address. And compared against a limit. There were four base,limit pairs that you had to rewrite to context switch: Text, data, spare and stack. At a minimum the system shipped with 256KB so you could have a number of processes memory resident. You swapped out a complete segment when you ran out of space. I imagine other 16bit word size machines of that era used similar schemes. > On Apr 25, 2018, at 1:29 PM, Paul Winalski wrote: > > Some PDP-11 models had a virtual addressing feature called PLAS > (Program Logical Address Space). The PDP-11 had 16-bit addressing, > allowing for at most 64K per process. To take advantage of physical > memory larger than 64K, PLAS allowed multiple 64K virtual address > spaces to be mapped to the larger physical memory. Sort of the > reverse of the usual virtual addressing scheme, where there is more > virtual memory than physical memory. From bqt at update.uu.se Thu Apr 26 09:08:14 2018 From: bqt at update.uu.se (Johnny Billquist) Date: Thu, 26 Apr 2018 01:08:14 +0200 Subject: [TUHS] /dev/drum In-Reply-To: References: Message-ID: <7193c242-fa54-8f95-71a1-e22e7f70975a@update.uu.se> On 2018-04-26 00:55, jnc at mercury.lcs.mit.edu (Noel Chiappa) wrote: > > From: Johnny Billquist > > > PDP-11 have 8K pages. > > Segments.:-) (This is an old argument between Johnny and me, I'm not trying > to re-open it, just yanking his chain...:-) :-) And if you hadn't had the ability for them to be less than 8K, you wouldn't even try that argument. But just because the hardware gives you some extra capabilities, you suddenly want to associate them with a technology that really gives you much less capabilities. Either way, the next page always start at the next 8K boundary. > > On a PDP-11, all your virtual memory was always there when the process > > was on the CPU > > In theory, at least (I don't know of an OS that made use of this), didn't the > memory management hardware allow the possibility to do demand-paging? I note > that Access Control Field value 0 is "non-resident". Oh yes. You definitely could do demand paging based on the hardware capabilities. > Unix kinda-sorta used this stuff, to automatically extend the stack when the > user ran off the end of it (causing a trap). Ah. Good point. The same is also true for brk, even though that is an explicit request to grow your memory space at the other side. DEC OSes had the brk part as well, but stack was not automatically extended if needed. DEC liked to have the stack at the low end of address space, and have hardware that trapped if the stack grew below 400 (octal). > > you normally did not have demand paging, since that was not really > > gaining you much on a PDP-11 > > Especially on the later machines, with more than 256KB of hardware main > memory. Maybe it might have been useful on the earlier ones (e.g. the -11/45). Yeah, it would actually probably have been more useful on an 11/45. 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 jnc at mercury.lcs.mit.edu Thu Apr 26 11:53:05 2018 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Wed, 25 Apr 2018 21:53:05 -0400 (EDT) Subject: [TUHS] /dev/drum Message-ID: <20180426015305.3CD6618C086@mercury.lcs.mit.edu> > From: Johnny Billquist > if you hadn't had the ability for them to be less than 8K, you wouldn't > even try that argument. Well, the 1972 edition of the -11/45 processor handbook called them segments.. :-) I figure some marketing droid found out that 'paging' was the new buzzword, and changed the name... :-) :-) Noel From doug at cs.dartmouth.edu Thu Apr 26 12:19:46 2018 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Wed, 25 Apr 2018 22:19:46 -0400 Subject: [TUHS] rm command Message-ID: <201804260219.w3Q2Jk5c022969@coolidge.cs.Dartmouth.EDU> > Google didn't seem to turn up much on TML Perhaps because there was no TML. I suspect you mean TMG, which I implemented from scratch, based on Bob McClure's original, on both PDP 8 and PDP 11 Unix. Bob Morris and I used it to make EPL, the "early PL/I" compiler for Multics. Off topic, but TMG on the GE 635, usedto buld Multics got there via quite an Odyssey. Bob McClure created it for the CDC 1604. He tranliterated it by hand from 1604 assembly language to IBM 7090 and sent the green coding sheets to me. Debugging it was an unusual exercise: I knew the logic was right; allI had to do was ferret out mistranslations. The most prevalant problem was confusion between CLA (signed load) and CAL (unsigned). When we decided to do EPL, Clem Pease mechanically reproduced a 7090 inside a Ge 635, by defining 7090 instructions as macros--sometimes quite hairy, but they worked. Doug From tih at hamartun.priv.no Thu Apr 26 15:51:01 2018 From: tih at hamartun.priv.no (Tom Ivar Helbekkmo) Date: Thu, 26 Apr 2018 07:51:01 +0200 Subject: [TUHS] /dev/drum In-Reply-To: <55000939-330c-85fe-7b07-5711b3578ecb@update.uu.se> (Johnny Billquist's message of "Thu, 26 Apr 2018 00:24:34 +0200") References: <55000939-330c-85fe-7b07-5711b3578ecb@update.uu.se> Message-ID: Johnny Billquist writes: > Uh... DEC STD 144 does not have anything to do with remapping bad > blocks to replacement good blocks. DEC STD 144 describes how a media > stores known bad blocks on a disk, so that file system initialization > can then take whatever action needed to that these blocks are not used > by anything. In RSX (and VMS), they will be included in a file called > BADBLK.SYS, and thus be perceived as "used". Thanks for the clarification, Johnny! As with so much else these days, DEC STD 144 is available on-line: https://archive.org/details/bitsavers_decstandar_576622 Interesting reading -- and the scheme used in RSX and VMS is exactly as required by the standard in section 4.1: "Small Operating System Conformance". -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 ralph at inputplus.co.uk Thu Apr 26 19:41:29 2018 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Thu, 26 Apr 2018 10:41:29 +0100 Subject: [TUHS] rm command In-Reply-To: <201804260219.w3Q2Jk5c022969@coolidge.cs.Dartmouth.EDU> References: <201804260219.w3Q2Jk5c022969@coolidge.cs.Dartmouth.EDU> Message-ID: <20180426094129.10CBE208E8@orac.inputplus.co.uk> Hi Doug, > > Google didn't seem to turn up much on TML > > Perhaps because there was no TML. I suspect you mean TMG I do indeed, thanks; all these `ML's nowadays must have corrupted my memory. Google knows lots about TMG, http://multicians.org/pl1.html#EPL http://multicians.org/tmg.html https://www.princeton.edu/~hos/mike/transcripts/mcilroy.htm http://hopl.info/showlanguage.prx?exp=242 and even GNU m4 has info '(m4)History' | cat -- Cheers, Ralph. https://plus.google.com/+RalphCorderoy From web at loomcom.com Fri Apr 27 05:18:13 2018 From: web at loomcom.com (Seth Morabito) Date: Thu, 26 Apr 2018 12:18:13 -0700 Subject: [TUHS] Looking for 3B2 SVR3 driver source code Message-ID: <1524770293.2186156.1352041392.2E5B643A@webmail.messagingengine.com> Hello all, I recently wrote a 3B2/400 simulator on the SIMH platform. It emulates the core system board and peripherals quite well, but I am now turning my attention to the emulating the 3B2 IO expansion boards. The first board I've emulated is the PORTS 4-port serial card, which came together fairly easily because I have the full source code for the SVR3 driver. Other cards, though, are more challenging because I do not have source code for them. I would like to emulate the following two cards: * The CTC cartridge tape controller * The NI 10base5 Ethernet controller Of these two, I have partial source code for the CTC driver (ct.c, ct.h, ct_lla.h, ct_deps.h), but I am missing a core file (ct_lla.c) that would greatly help explain what's going on. And I have NO source code at all for the NI driver. There was a source code package for the NI driver called "nisrc", probably distributed on tape or floppy, but I have never seen it. If you or anyone you know happens to have these source packages and a way to get at them, could you please let me know? I would be grateful. -Seth -- Seth Morabito web at loomcom.com From dave at horsfall.org Fri Apr 27 15:15:21 2018 From: dave at horsfall.org (Dave Horsfall) Date: Fri, 27 Apr 2018 15:15:21 +1000 (EST) Subject: [TUHS] 3330s, 3340s, Winchesters... (was: /dev/drum) In-Reply-To: <20180425141536.9aiQ4%steffen@sdaoden.eu> References: <20180424120612.CD71B18C07A@mercury.lcs.mit.edu> <20180425004734.GK31055@eureka.lemis.com> <20180425141536.9aiQ4%steffen@sdaoden.eu> Message-ID: On Wed, 25 Apr 2018, Steffen Nurpmeso wrote: > |To be fair, Wikipedia is relatively accurate. And if you find > |something wrong in it and don't fix it, you have only yourself to > |blame. > > It is not that easy. For example there are people which "sit" > there for a long time. Not all of them are good. [...] Wikipedia simply cannot be trusted (as if it ever could). You will get some imbecile who thinks that they "own" that topic, and when you challenge said moron because you happen to have personal information i.e. you were *there* at the time then the coward will simply block you. Wikipedia is only as accurate as the last idiot who updated it. -- Dave Horsfall BSc DTM (VK2KFU) -- FuglySoft -- Gosford IT -- Unix/C/Perl (AbW) People who fail to / understand security / surely will suffer. (tks: RichardM) From dave at horsfall.org Fri Apr 27 19:57:51 2018 From: dave at horsfall.org (Dave Horsfall) Date: Fri, 27 Apr 2018 19:57:51 +1000 (EST) Subject: [TUHS] Happy birthday, computer mouse! Message-ID: Blimey, but I nearly missed this one (I was sick in bed). On this day in 1981, some little company called Xerox PARC introduced something called a "mouse" (mostly because it has a tail), but I'm struggling to find more information about it; wasn't there a photo of a big boxy device? -- Dave Horsfall BSc DTM (VK2KFU) -- FuglySoft -- Gosford IT -- Unix/C/Perl (AbW) People who fail to / understand security / surely will suffer. (tks: RichardM) From hellwig.geisse at mni.thm.de Fri Apr 27 20:18:47 2018 From: hellwig.geisse at mni.thm.de (Hellwig Geisse) Date: Fri, 27 Apr 2018 12:18:47 +0200 Subject: [TUHS] Happy birthday, computer mouse! In-Reply-To: References: Message-ID: <1524824327.2138.71.camel@mni.thm.de> On Fr, 2018-04-27 at 19:57 +1000, Dave Horsfall wrote: > > On this day in 1981, some little company called Xerox PARC introduced  > something called a "mouse" (mostly because it has a tail), but I'm  > struggling to find more information about it; wasn't there a photo of a  > big boxy device? > This seems to be a date which is much too late. Even Smalltalk-72 on the Alto used a pointing device. In his book "Smalltalk-80: Bits of History, Words of Advice" Glenn Krasner wrote: "Smalltalk-72 was ported to the Alto [...] Soon many interesting and useful applications were written, including a mouse-driven program editor [...]" Hellwig From peter at rulingia.com Fri Apr 27 21:13:38 2018 From: peter at rulingia.com (Peter Jeremy) Date: Fri, 27 Apr 2018 21:13:38 +1000 Subject: [TUHS] Happy birthday, computer mouse! In-Reply-To: References: Message-ID: <20180427111338.GA78877@server.rulingia.com> On 2018-Apr-27 19:57:51 +1000, Dave Horsfall wrote: >On this day in 1981, some little company called Xerox PARC introduced Well, the company was Xerox. PARC was their research facility. >something called a "mouse" (mostly because it has a tail), but I'm Douglas Engelbart demonstrated the mouse in his "Mother of All Demos" on 1968-Dec-09 (see https://www.youtube.com/watch?v=yJDv-zdhzMY). According to WP, he applied for the patent in 1967 so I'm not sure when he invented it. -- 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 wlc at jctaylor.com Fri Apr 27 20:58:15 2018 From: wlc at jctaylor.com (William Corcoran) Date: Fri, 27 Apr 2018 10:58:15 +0000 Subject: [TUHS] Happy birthday, computer mouse! In-Reply-To: <1524824327.2138.71.camel@mni.thm.de> References: , <1524824327.2138.71.camel@mni.thm.de> Message-ID: <71628EA8-EAC4-43FF-98CF-EA1B72635B8B@jctaylor.com> Absolutely Hellwig. Please take a look at the early DARPA/Internet RFCs from ~1969 and they make reference to a mouse. I will try to dig it up. BIll Corcoran > On Apr 27, 2018, at 6:38 AM, Hellwig Geisse wrote: > >> On Fr, 2018-04-27 at 19:57 +1000, Dave Horsfall wrote: >> >> On this day in 1981, some little company called Xerox PARC introduced >> something called a "mouse" (mostly because it has a tail), but I'm >> struggling to find more information about it; wasn't there a photo of a >> big boxy device? >> > > This seems to be a date which is much too late. Even Smalltalk-72 > on the Alto used a pointing device. In his book "Smalltalk-80: > Bits of History, Words of Advice" Glenn Krasner wrote: > "Smalltalk-72 was ported to the Alto [...] Soon many interesting > and useful applications were written, including a mouse-driven > program editor [...]" > > Hellwig From bakul at bitblocks.com Fri Apr 27 22:13:31 2018 From: bakul at bitblocks.com (Bakul Shah) Date: Fri, 27 Apr 2018 05:13:31 -0700 Subject: [TUHS] Happy birthday, computer mouse! In-Reply-To: <20180427111338.GA78877@server.rulingia.com> References: <20180427111338.GA78877@server.rulingia.com> Message-ID: <10515862-3E7B-4D22-9147-994512983FF1@bitblocks.com> >> On Apr 27, 2018, at 4:13 AM, Peter Jeremy wrote: >> >> On 2018-Apr-27 19:57:51 +1000, Dave Horsfall wrote: >> On this day in 1981, some little company called Xerox PARC introduced > > Well, the company was Xerox. PARC was their research facility. > >> something called a "mouse" (mostly because it has a tail), but I'm > > Douglas Engelbart demonstrated the mouse in his "Mother of All Demos" on > 1968-Dec-09 (see https://www.youtube.com/watch?v=yJDv-zdhzMY). According > to WP, he applied for the patent in 1967 so I'm not sure when he invented it. > > -- > Peter Jeremy According to https://www.macworld.com/article/1137400/input-devices/mouse40.html Bill English designed the first mouse in 1963 based on Engelbart’s sketches. By 1982 we had access to a Mouse Systems’ mouse. I played with it but gave up as it was no fun using it with a character only 80x25 screen. -------------- next part -------------- An HTML attachment was scrubbed... URL: From steffen at sdaoden.eu Fri Apr 27 22:48:58 2018 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Fri, 27 Apr 2018 14:48:58 +0200 Subject: [TUHS] Happy birthday, computer mouse! In-Reply-To: References: Message-ID: <20180427124858.XUJKL%steffen@sdaoden.eu> Dave Horsfall wrote: |Blimey, but I nearly missed this one (I was sick in bed). | |On this day in 1981, some little company called Xerox PARC introduced |something called a "mouse" (mostly because it has a tail), but I'm |struggling to find more information about it; wasn't there a photo of a |big boxy device? http://cerncourier.com/cws/article/cern/28358/1/cernbooks2_12-00 --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 steffen at sdaoden.eu Fri Apr 27 23:13:04 2018 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Fri, 27 Apr 2018 15:13:04 +0200 Subject: [TUHS] 3330s, 3340s, Winchesters... (was: /dev/drum) In-Reply-To: References: <20180424120612.CD71B18C07A@mercury.lcs.mit.edu> <20180425004734.GK31055@eureka.lemis.com> <20180425141536.9aiQ4%steffen@sdaoden.eu> Message-ID: <20180427131304.1cZ2M%steffen@sdaoden.eu> Dave Horsfall wrote: |On Wed, 25 Apr 2018, Steffen Nurpmeso wrote: | |>|To be fair, Wikipedia is relatively accurate. And if you find |>|something wrong in it and don't fix it, you have only yourself to |>|blame. |> |> It is not that easy. For example there are people which "sit" |> there for a long time. Not all of them are good. [...] | |Wikipedia simply cannot be trusted (as if it ever could). | |You will get some imbecile who thinks that they "own" that topic, and when |you challenge said moron because you happen to have personal information |i.e. you were *there* at the time then the coward will simply block you. | |Wikipedia is only as accurate as the last idiot who updated it. Unfortunately all reference texts like Encyclopedia Britannica now only exist in online versions; the Encyclopedia Britannica was one of the first i think (according to [1] computer mouse is even as old as 1963-64!), the "Fischer Weltalmanach" the last i know of; mourning of loss in German at [2], titled "A Victim on the Altar of Availability"; me too: when i was young it was of value to have an entire cupboard of editorially edited general knowledge at home. [1] https://www.britannica.com/biography/Douglas-Engelbart [2] https://derstandard.at/2000077097204/Fischer-Weltalmanach-Ein-Opfer-auf-dem-Altar-der-Verfuegbarkeit --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 itz at very.loosely.org Sat Apr 28 00:42:36 2018 From: itz at very.loosely.org (Ian Zimmerman) Date: Fri, 27 Apr 2018 07:42:36 -0700 Subject: [TUHS] 3330s, 3340s, Winchesters... (was: /dev/drum) In-Reply-To: References: <20180424120612.CD71B18C07A@mercury.lcs.mit.edu> <20180425004734.GK31055@eureka.lemis.com> <20180425141536.9aiQ4%steffen@sdaoden.eu> Message-ID: <20180427144236.bj2a6oplg6vedmqi@matica.foolinux.mooo.com> On 2018-04-27 15:15, Dave Horsfall wrote: > Wikipedia is only as accurate as the last idiot who updated it. One should always question authority, nonetheless in many areas wikipedia is excellent. I get more out of slowly and carefully reading a wikipedia maths article than I ever got out of sitting through a university lecture. I can say the same about botany articles. I guess that's because idiots aren't drawn to these fields in large numbers. -- Please don't Cc: me privately on mailing lists and Usenet, if you also post the followup to the list or newsgroup. To reply privately _only_ on Usenet and on broken lists which rewrite From, fetch the TXT record for no-use.mooo.com. From ron at ronnatalie.com Sat Apr 28 00:47:57 2018 From: ron at ronnatalie.com (Ronald Natalie) Date: Fri, 27 Apr 2018 10:47:57 -0400 Subject: [TUHS] Happy birthday, computer mouse! In-Reply-To: <20180427111338.GA78877@server.rulingia.com> References: <20180427111338.GA78877@server.rulingia.com> Message-ID: <777DD6D1-467D-4486-82E2-495AAE863F43@ronnatalie.com> Interesting Typography on the demo film. Never seen capital letters identified with overscores. PARC is well known for contributing things to the public that Xerox never quite got into a real product. I always loved going to meetings there just to see what they had come up with this time. From dave at horsfall.org Sat Apr 28 01:47:42 2018 From: dave at horsfall.org (Dave Horsfall) Date: Sat, 28 Apr 2018 01:47:42 +1000 (EST) Subject: [TUHS] Disk data layout (was: /dev/drum) In-Reply-To: References: <7wfu3nuqeb.fsf@junk.nocrew.org> <3A18DFEC-42B7-4234-9DD1-367733270D50@tfeb.org> <0abe01d3db28$b6573660$2305a320$@ronnatalie.com> <866bbea1-3a26-20a4-e233-1b8dc0ea2683@spamtrap.tnetconsulting.net> <20180425013134.GM31055@eureka.lemis.com> Message-ID: On Wed, 25 Apr 2018, Paul Winalski wrote: > Bin number was zero except on the IBM 2321 data cell drive. CKD drives > supported a variable number of records on each track, hence the term > "record" rather than "sector". Would that have been the infamous chicken-plucker?[*] Wherein if things went OK, then they were OK, but if things went wrong... [*] Also known by, ahem, a name that rhymes... -- Dave Horsfall BSc DTM (VK2KFU) -- FuglySoft -- Gosford IT -- Unix/C/Perl (AbW) People who fail to / understand security / surely will suffer. (tks: RichardM) From dave at horsfall.org Sat Apr 28 02:26:16 2018 From: dave at horsfall.org (Dave Horsfall) Date: Sat, 28 Apr 2018 02:26:16 +1000 (EST) Subject: [TUHS] rm command In-Reply-To: <20180425221716.B4C6718C086@mercury.lcs.mit.edu> References: <20180425221716.B4C6718C086@mercury.lcs.mit.edu> Message-ID: On Wed, 25 Apr 2018, Noel Chiappa wrote: > On early PDP-11 Unixes, 'rm' is an ordinary program, and 'rmdir' is > setuid-root, since it has to do special magic (writing into directory > files, etc). Given that, it made sense to have 'rm' run with the least > amount of privilege needed to do its job. I am constantly bemused by the number of "setuid root" commands, when a simple "setgid whatever" will achieve the same task. My mantra has always been: "If you think you need setuid root, then you are probably thinking wrong." My favourite here is the "ps" command: On my FreeBSD server: % ls -l /bin/ps -r-xr-xr-x 1 root wheel 35640 Oct 15 2017 /bin/ps On my crappy MacBook: % ls -l /bin/ps -rwsr-xr-x 1 root wheel 51200 Jul 15 2017 /bin/ps (I didn't check my Penguin box, because I don't think that I'll like what I'll see.) -- Dave From jnc at mercury.lcs.mit.edu Sat Apr 28 02:42:12 2018 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Fri, 27 Apr 2018 12:42:12 -0400 (EDT) Subject: [TUHS] rm command Message-ID: <20180427164212.BD94718C088@mercury.lcs.mit.edu> > From: Dave Horsfall > I am constantly bemused by the number of "setuid root" commands, when a > simple "setgid whatever" will achieve the same task. http://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/sys/ken/sys4.c /* * Unlink system call. */ unlink() { ... if((ip->i_mode&IFMT)==IFDIR && !suser()) goto out; For many things, yes. Not in this particular case. Noel From itz at very.loosely.org Sat Apr 28 02:58:31 2018 From: itz at very.loosely.org (Ian Zimmerman) Date: Fri, 27 Apr 2018 09:58:31 -0700 Subject: [TUHS] rm command In-Reply-To: References: <20180425221716.B4C6718C086@mercury.lcs.mit.edu> Message-ID: <20180427165831.loewgjeqju6u2alh@matica.foolinux.mooo.com> On 2018-04-28 02:26, Dave Horsfall wrote: > On my FreeBSD server: > > % ls -l /bin/ps > -r-xr-xr-x 1 root wheel 35640 Oct 15 2017 /bin/ps > > On my crappy MacBook: > > % ls -l /bin/ps > -rwsr-xr-x 1 root wheel 51200 Jul 15 2017 /bin/ps Clearly this will depend on how ps is implemented, which is one of the messier aspects of our favorite OS. If it does its thing just by reading a pseudo-file or a pseudo-device, then setgid will be enough, but maybe it needs to execute a root-only system call. There is a longish thread on comp.unix.programmer right now about this very topic. -- Please don't Cc: me privately on mailing lists and Usenet, if you also post the followup to the list or newsgroup. To reply privately _only_ on Usenet and on broken lists which rewrite From, fetch the TXT record for no-use.mooo.com. From usotsuki at buric.co Sat Apr 28 04:14:15 2018 From: usotsuki at buric.co (Steve Nickolas) Date: Fri, 27 Apr 2018 14:14:15 -0400 (EDT) Subject: [TUHS] rm command In-Reply-To: References: <20180425221716.B4C6718C086@mercury.lcs.mit.edu> Message-ID: On Sat, 28 Apr 2018, Dave Horsfall wrote: > On Wed, 25 Apr 2018, Noel Chiappa wrote: > >> On early PDP-11 Unixes, 'rm' is an ordinary program, and 'rmdir' is >> setuid-root, since it has to do special magic (writing into directory >> files, etc). Given that, it made sense to have 'rm' run with the least >> amount of privilege needed to do its job. > > I am constantly bemused by the number of "setuid root" commands, when a > simple "setgid whatever" will achieve the same task. > > My mantra has always been: "If you think you need setuid root, then you are > probably thinking wrong." > > My favourite here is the "ps" command: > > On my FreeBSD server: > > % ls -l /bin/ps > -r-xr-xr-x 1 root wheel 35640 Oct 15 2017 /bin/ps > > On my crappy MacBook: > > % ls -l /bin/ps > -rwsr-xr-x 1 root wheel 51200 Jul 15 2017 /bin/ps > > (I didn't check my Penguin box, because I don't think that I'll like what > I'll see.) > > -- Dave > Debian 9: nicci at jesustheasus:~$ ls -l $(which ps) -rwxr-xr-x 1 root root 129336 Nov 22 2016 /bin/ps Debian 8 kFreeBSD: [usotsuki at licca ~]$ ls -l $(which ps) -rwxr-xr-x 1 root root 93088 Mar 6 2015 /bin/ps -uso. From paul.winalski at gmail.com Sat Apr 28 04:16:31 2018 From: paul.winalski at gmail.com (Paul Winalski) Date: Fri, 27 Apr 2018 14:16:31 -0400 Subject: [TUHS] Disk data layout (was: /dev/drum) In-Reply-To: References: <7wfu3nuqeb.fsf@junk.nocrew.org> <3A18DFEC-42B7-4234-9DD1-367733270D50@tfeb.org> <0abe01d3db28$b6573660$2305a320$@ronnatalie.com> <866bbea1-3a26-20a4-e233-1b8dc0ea2683@spamtrap.tnetconsulting.net> <20180425013134.GM31055@eureka.lemis.com> Message-ID: On 4/27/18, Dave Horsfall wrote: > On Wed, 25 Apr 2018, Paul Winalski wrote: > >> Bin number was zero except on the IBM 2321 data cell drive. CKD drives >> supported a variable number of records on each track, hence the term >> "record" rather than "sector". > > Would that have been the infamous chicken-plucker?[*] Wherein if things > went OK, then they were OK, but if things went wrong... That's the one. I'd always heard "noodle picker", though. From the outside it looked like a drum in the shape of a multi-sided polygon. Each bin held a number of wide pieces of multitrack magnetic tape. To seek to your data, the drum rotated under a head that pulled the appropriate tape out of the bin and wrapped it on rotating drum. From there reading and writing was much like any other drum device. It's as if someone asked Rube Goldberg to design a disk drive. -Paul W. From paul.winalski at gmail.com Sat Apr 28 04:23:25 2018 From: paul.winalski at gmail.com (Paul Winalski) Date: Fri, 27 Apr 2018 14:23:25 -0400 Subject: [TUHS] Happy birthday, computer mouse! In-Reply-To: <777DD6D1-467D-4486-82E2-495AAE863F43@ronnatalie.com> References: <20180427111338.GA78877@server.rulingia.com> <777DD6D1-467D-4486-82E2-495AAE863F43@ronnatalie.com> Message-ID: On 4/27/18, Ronald Natalie wrote: > > PARC is well known for contributing things to the public that Xerox never > quite got into a real product. I always loved going to meetings there just > to see what they had come up with this time. For a while Gordon Bell used to hand out the Xerox PARC Award to the R&D project that simultaneously did the most to advance the state of the art and contributed the least to DEC's bottom line. -Paul W. From pete at nomadlogic.org Sat Apr 28 04:17:45 2018 From: pete at nomadlogic.org (Pete Wright) Date: Fri, 27 Apr 2018 11:17:45 -0700 Subject: [TUHS] rm command In-Reply-To: References: <20180425221716.B4C6718C086@mercury.lcs.mit.edu> Message-ID: On 04/27/2018 11:14, Steve Nickolas wrote: > On Sat, 28 Apr 2018, Dave Horsfall wrote: > >> On Wed, 25 Apr 2018, Noel Chiappa wrote: >> >>> On early PDP-11 Unixes, 'rm' is an ordinary program, and 'rmdir' is >>> setuid-root, since it has to do special magic (writing into >>> directory files, etc). Given that, it made sense to have 'rm' run >>> with the least amount of privilege needed to do its job. >> >> I am constantly bemused by the number of "setuid root" commands, when >> a simple "setgid whatever" will achieve the same task. >> >> My mantra has always been: "If you think you need setuid root, then >> you are probably thinking wrong." >> >> My favourite here is the "ps" command: >> >>    On my FreeBSD server: >> >>     % ls -l /bin/ps >>     -r-xr-xr-x  1 root  wheel  35640 Oct 15  2017 /bin/ps >> >>    On my crappy MacBook: >> >>     % ls -l /bin/ps >>     -rwsr-xr-x  1 root  wheel  51200 Jul 15  2017 /bin/ps >> >> (I didn't check my Penguin box, because I don't think that I'll like >> what I'll see.) >> >> -- Dave >> > > Debian 9: > > nicci at jesustheasus:~$ ls -l $(which ps) > -rwxr-xr-x 1 root root 129336 Nov 22  2016 /bin/ps > > Debian 8 kFreeBSD: > > [usotsuki at licca ~]$ ls -l $(which ps) > -rwxr-xr-x 1 root root 93088 Mar  6  2015 /bin/ps > interesting how the gnu userland marks ps as owner-writable, not sure it matters, but interesting... -p -- Pete Wright pete at nomadlogic.org @nomadlogicLA From clemc at ccc.com Sat Apr 28 04:37:15 2018 From: clemc at ccc.com (Clem Cole) Date: Fri, 27 Apr 2018 14:37:15 -0400 Subject: [TUHS] Disk data layout (was: /dev/drum) In-Reply-To: References: <7wfu3nuqeb.fsf@junk.nocrew.org> <3A18DFEC-42B7-4234-9DD1-367733270D50@tfeb.org> <0abe01d3db28$b6573660$2305a320$@ronnatalie.com> <866bbea1-3a26-20a4-e233-1b8dc0ea2683@spamtrap.tnetconsulting.net> <20180425013134.GM31055@eureka.lemis.com> Message-ID: On Fri, Apr 27, 2018 at 2:16 PM, Paul Winalski wrote: > On 4/27/18, Dave Horsfall wrote: > > On Wed, 25 Apr 2018, Paul Winalski wrote: > > > >> Bin number was zero except on the IBM 2321 data cell drive. CKD drives > >> supported a variable number of records on each track, hence the term > >> "record" rather than "sector". > > > > Would that have been the infamous chicken-plucker?[*] Wherein if things > > went OK, then they were OK, but if things went wrong... > > That's the one. I'd always heard "noodle picker", though. From the > outside it looked like a drum in the shape of a multi-sided polygon. > Each bin held a number of wide pieces of multitrack magnetic tape. To > seek to your data, the drum rotated under a head that pulled the > appropriate tape out of the bin and wrapped it on rotating drum. From > there reading and writing was much like any other drum device. It's > as if someone asked Rube Goldberg to design a disk drive. ​Accept that it will like tape in the head contacted the media. Question for Debbie S --- my memory is you folks had one up the hill at LBL. I think that's where I saw it in action.​ ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ca6c at bitmessage.ch Sat Apr 28 07:00:45 2018 From: ca6c at bitmessage.ch (=?utf-8?B?Q8OhZw==?=) Date: Fri, 27 Apr 2018 21:00:45 +0000 Subject: [TUHS] Happy birthday, computer mouse! In-Reply-To: References: Message-ID: <20180427210045.2oGgl%ca6c@bitmessage.ch> No offence, but anything that makes me move my fingers from my keyboard, be it a mouse, a touchpad etc., takes a menacing look from me. -- caóc From bqt at update.uu.se Sat Apr 28 08:41:07 2018 From: bqt at update.uu.se (Johnny Billquist) Date: Sat, 28 Apr 2018 00:41:07 +0200 Subject: [TUHS] /dev/drum In-Reply-To: References: Message-ID: <46f842e4-9ffb-289f-133e-0b391cb26ed9@update.uu.se> On 2018-04-26 04:00, jnc at mercury.lcs.mit.edu (Noel Chiappa) wrote: > > From: Johnny Billquist > > > if you hadn't had the ability for them to be less than 8K, you wouldn't > > even try that argument. > > Well, the 1972 edition of the -11/45 processor handbook called them segments..:-) I think we had this argument before as well. It would be nice if you actually could point out where this is the case. I just went through that 1973 PDP-11/45 handbook, and all it says are "page" everywhere I look. I also checked the 1972 PDP-11/40 handbook, and except for one mention of "segment" in the introduction part of the handbook, which is not even clear if it actually specifically refers to the MMU capabilities, that handbook also use the word "page" everywhere. I also checked the PDP-11/20 handbook, but that one does not even cover any MMU, so no mention of neither "page" nor "segment" can be found. > I figure some marketing droid found out that 'paging' was the new buzzword, and > changed the name...:-) :-) Somehow I doubt it, but looking forward to your references... :-) 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 jnc at mercury.lcs.mit.edu Sat Apr 28 09:01:30 2018 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Fri, 27 Apr 2018 19:01:30 -0400 (EDT) Subject: [TUHS] /dev/drum Message-ID: <20180427230130.C933818C08B@mercury.lcs.mit.edu> > From: Johnny Billquist >> Well, the 1972 edition of the -11/45 processor handbook ^^ > It would be nice if you actually could point out where this is the > case. I just went through that 1973 PDP-11/45 handbook ^^ Yes, the '73 one (red/purple cover) had switched. It's only the '72 one (red/white cover) that says 'segments'. Noel From dave at horsfall.org Sat Apr 28 09:06:54 2018 From: dave at horsfall.org (Dave Horsfall) Date: Sat, 28 Apr 2018 09:06:54 +1000 (EST) Subject: [TUHS] Happy birthday, computer mouse! In-Reply-To: References: Message-ID: Sorry, folks; thanks for all the feedback (ouch!) and I'll check my references better next time (along with my medications, as I have a suspect pros gl.) -- Dave Horsfall BSc DTM (VK2KFU) -- FuglySoft -- Gosford IT -- Unix/C/Perl (AbW) People who fail to / understand security / surely will suffer. (tks: RichardM) From bqt at update.uu.se Sat Apr 28 09:10:57 2018 From: bqt at update.uu.se (Johnny Billquist) Date: Sat, 28 Apr 2018 01:10:57 +0200 Subject: [TUHS] /dev/drum In-Reply-To: <20180427230130.C933818C08B@mercury.lcs.mit.edu> References: <20180427230130.C933818C08B@mercury.lcs.mit.edu> Message-ID: On 2018-04-28 01:01, Noel Chiappa wrote: > > From: Johnny Billquist > > >> Well, the 1972 edition of the -11/45 processor handbook > ^^ > > > It would be nice if you actually could point out where this is the > > case. I just went through that 1973 PDP-11/45 handbook > ^^ > > Yes, the '73 one (red/purple cover) had switched. It's only the '72 one > (red/white cover) that says 'segments'. Yes, I know you said 1972, and I said 1973. For 1972 I only found the 11/40 handbook. But, as I said, that handbook also says "page". If you have some link to the version you refer to, it would be interesting. Told you I searched around in different handbooks from that era, and found none who said segments. 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 imp at bsdimp.com Sat Apr 28 09:39:27 2018 From: imp at bsdimp.com (Warner Losh) Date: Fri, 27 Apr 2018 17:39:27 -0600 Subject: [TUHS] /dev/drum In-Reply-To: References: <20180427230130.C933818C08B@mercury.lcs.mit.edu> Message-ID: On Fri, Apr 27, 2018 at 5:10 PM, Johnny Billquist wrote: > On 2018-04-28 01:01, Noel Chiappa wrote: > >> > From: Johnny Billquist >> >> >> Well, the 1972 edition of the -11/45 processor handbook >> ^^ >> >> > It would be nice if you actually could point out where this is the >> > case. I just went through that 1973 PDP-11/45 handbook >> ^^ >> >> Yes, the '73 one (red/purple cover) had switched. It's only the '72 one >> (red/white cover) that says 'segments'. >> > > > Yes, I know you said 1972, and I said 1973. > For 1972 I only found the 11/40 handbook. But, as I said, that handbook > also says "page". If you have some link to the version you refer to, it > would be interesting. > > Told you I searched around in different handbooks from that era, and found > none who said segments. The OS Book I used in college in the late 80's said 'segments' to describe the PDP-11 MMU. At least that's my memory, I can't even recall the name of the OS book, and my cache of college textbooks has gone to good will years ago. IIRC, it was because they were so large relative to the VAX and made 'page demand' difficult to implement. Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnc at mercury.lcs.mit.edu Sat Apr 28 10:19:20 2018 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Fri, 27 Apr 2018 20:19:20 -0400 (EDT) Subject: [TUHS] /dev/drum Message-ID: <20180428001920.30BA018C08D@mercury.lcs.mit.edu> > From: Johnny Billquist > For 1972 I only found the 11/40 handbook. I have a spare copy of the '72 /45 handbook; send me your address, and I'll send it along. (Every PDP-11 fan should have a copy of every edition of every model's handbooks... :-) In the meantime, I'm too lazy to scan the whole thing, but here's the first page of Chapter 6 from the '72: http://ana-3.lcs.mit.edu/~jnc/tech/pdp11/jpg/tmp/PDP11145ProcHbook72pg6-1.jpg > went though the 1972 Maintenance Reference Manual for the 11/45. That > one also says "page". :-) There are a few remnant relics of the 'segment' phase, e.g. here: http://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/sys/conf/m45.s which has this comment: / turn on segmentation Also, if you look at the end, you'll see SSR0, SSR1 etc (as per the '72 handbook), instead of the later SR0, SR1, etc. Noel From wobblygong at gmail.com Sat Apr 28 18:05:24 2018 From: wobblygong at gmail.com (Wesley Parish) Date: Sat, 28 Apr 2018 20:05:24 +1200 Subject: [TUHS] 3330s, 3340s, Winchesters... (was: /dev/drum) In-Reply-To: <20180427144236.bj2a6oplg6vedmqi@matica.foolinux.mooo.com> References: <20180424120612.CD71B18C07A@mercury.lcs.mit.edu> <20180425004734.GK31055@eureka.lemis.com> <20180425141536.9aiQ4%steffen@sdaoden.eu> <20180427144236.bj2a6oplg6vedmqi@matica.foolinux.mooo.com> Message-ID: wikipedia and politics is a bad mixture. wikipedia and religion is a bad mixture. wikipedia and ego is a bad mixture. Imagine wikipedia articles edited and counteredited by the Newton crowd and the Leibnitz crowd during that long dispute over who had had priority, who had borrowed, who had stolen, who had ... (censored) (censored) (censored) .... Subjects where there is plentiful knowledge, even if it is obscure - Calculus, Old English, the structure of the Unix file system, Lewis Carroll's poem the Jabberwocky, the shape of the British constitution and its offshoots, etc - they tend to reproduce the best known data. On other matters, it can be decidedly iffy. Wesley Parish On 4/28/18, Ian Zimmerman wrote: > On 2018-04-27 15:15, Dave Horsfall wrote: > >> Wikipedia is only as accurate as the last idiot who updated it. > > One should always question authority, nonetheless in many areas > wikipedia is excellent. I get more out of slowly and carefully reading > a wikipedia maths article than I ever got out of sitting through a > university lecture. I can say the same about botany articles. > > I guess that's because idiots aren't drawn to these fields in large > numbers. > > -- > Please don't Cc: me privately on mailing lists and Usenet, > if you also post the followup to the list or newsgroup. > To reply privately _only_ on Usenet and on broken lists > which rewrite From, fetch the TXT record for no-use.mooo.com. > From bqt at update.uu.se Sat Apr 28 20:41:37 2018 From: bqt at update.uu.se (Johnny Billquist) Date: Sat, 28 Apr 2018 12:41:37 +0200 Subject: [TUHS] /dev/drum In-Reply-To: <20180428001920.30BA018C08D@mercury.lcs.mit.edu> References: <20180428001920.30BA018C08D@mercury.lcs.mit.edu> Message-ID: On 2018-04-28 02:19, Noel Chiappa wrote: > > From: Johnny Billquist > > > For 1972 I only found the 11/40 handbook. > > I have a spare copy of the '72 /45 handbook; send me your address, and I'll > send it along. (Every PDP-11 fan should have a copy of every edition of every > model's handbooks... :-) Gah. If I were to try and collect every copy made, it would be quite a collection. Thanks for the offer. If you really want to get rid of one, and is willing to send to Switzerland, then I'll take it in a private mail. But you don't really have to. > In the meantime, I'm too lazy to scan the whole thing, but here's the first > page of Chapter 6 from the '72: > > http://ana-3.lcs.mit.edu/~jnc/tech/pdp11/jpg/tmp/PDP11145ProcHbook72pg6-1.jpg Cool. Thanks. That is a very different terminology. The MMU is not even called the MMU, but the "Memory Segmentation Unit". Very interesting. > > went though the 1972 Maintenance Reference Manual for the 11/45. That > > one also says "page". :-) > > There are a few remnant relics of the 'segment' phase, e.g. here: > > http://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/sys/conf/m45.s > > which has this comment: > > / turn on segmentation > > Also, if you look at the end, you'll see SSR0, SSR1 etc (as per the '72 > handbook), instead of the later SR0, SR1, etc. So there was a total change in terminology early in the 11/45 life, it would appear. I wonder why. I can only speculate, but I probably would not blame some market droids. Trying to think about this, I feel that one of the most important differences between segmentation and pages are that with segmentation you only have one contiguous range of memory, described by a base and a length register. This will be a contiguous range of memory both in virtual memory, and in physical memory. With segmentation you cannot have your virtual memory split up and spread out over physical memory. You can also, pretty much, arbitrarily point where in physical memory your virtual memory starts and ends. With pages, this is obviously not the case anymore. The PDP-11 do have the ability to have pages start at close to arbitrary addresses in physical memory, but you can certainly have your virtual memory spread out over different places in physical memory. Your virtual memory is also not just described by a base and length, as you have 8 pages, starting at fixed virtual memory addresses. You can also have "holes" in your memory, with pages that are invalid, yet have pages higher up in your virtual memory which are valid. Something that is impossible with segmentation, since you only have one set of registers for each memory type (at most) in a segmented memory implementation. I mean, when people talk about segmented memory, what most everyone today thinks of is the x86 model, where all of this certainly is true. So, by this definition, it would be very wrong to call what the PDP-11 have segmentation. And I would suspect that to be the reason why DEC changed their terminology. Segmentation simply started to become an established term, and it did not match what the PDP-11 did, so the documentation had to change to better describe what it was. 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 rp at servium.ch Sat Apr 28 22:19:55 2018 From: rp at servium.ch (Rico Pajarola) Date: Sat, 28 Apr 2018 14:19:55 +0200 Subject: [TUHS] /dev/drum In-Reply-To: References: <20180428001920.30BA018C08D@mercury.lcs.mit.edu> Message-ID: On Sat, Apr 28, 2018 at 12:41 PM, Johnny Billquist wrote: > On 2018-04-28 02:19, Noel Chiappa wrote: > >> I have a spare copy of the '72 /45 handbook; send me your address, and >> I'll >> send it along. (Every PDP-11 fan should have a copy of every edition of >> every >> model's handbooks... :-) >> > > Gah. If I were to try and collect every copy made, it would be quite a > collection. Thanks for the offer. If you really want to get rid of one, and > is willing to send to Switzerland, then I'll take it in a private mail. But > you don't really have to. Noel, If you can send it to California within the next 7 days, I can hand deliver it to Johnny in Switzerland -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at kjorling.se Sun Apr 29 02:33:51 2018 From: michael at kjorling.se (Michael =?utf-8?B?S2rDtnJsaW5n?=) Date: Sat, 28 Apr 2018 16:33:51 +0000 Subject: [TUHS] rm command In-Reply-To: References: <20180425221716.B4C6718C086@mercury.lcs.mit.edu> Message-ID: <20180428163351.GG20510@h-174-65.A328.priv.bahnhof.se> On 27 Apr 2018 11:17 -0700, from pete at nomadlogic.org (Pete Wright): >>>    On my FreeBSD server: >>> >>>     % ls -l /bin/ps >>>     -r-xr-xr-x  1 root  wheel  35640 Oct 15  2017 /bin/ps >>> >>>    On my crappy MacBook: >>> >>>     % ls -l /bin/ps >>>     -rwsr-xr-x  1 root  wheel  51200 Jul 15  2017 /bin/ps >> >> Debian 9: >> >> nicci at jesustheasus:~$ ls -l $(which ps) >> -rwxr-xr-x 1 root root 129336 Nov 22  2016 /bin/ps >> >> Debian 8 kFreeBSD: >> >> [usotsuki at licca ~]$ ls -l $(which ps) >> -rwxr-xr-x 1 root root 93088 Mar  6  2015 /bin/ps Debian 7 is the same, except /bin/ps is 93120 bytes there. > interesting how the gnu userland marks ps as owner-writable, not > sure it matters, but interesting... That's more likely the package manager, or the packaging done by the package maintainer, than it is anything about GNU per se. I've got a gazillion 0755 0:0 binaries on my system. In fact, running `ls -l /usr/bin | grep -v '^.rwx'` on my desktop Debian box returns only a handful of hits, all of which are u=rws and a few of which are g=r-s. If you're root enough to take advantage of the owner-writable bit on a file owned by root, then you're root enough to make quite a mess even if they were mode 0555 or even 0111. If you want weird, then tell me why on Earth /bin/ping _really_ needs to be setuid root on Linux (has no one heard of capabilities?), or why /bin/fusermount is, of all modes they could choose from, `-rwsr-xr--`. -- 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 ron at ronnatalie.com Sun Apr 29 02:53:22 2018 From: ron at ronnatalie.com (Ron Natalie) Date: Sat, 28 Apr 2018 12:53:22 -0400 Subject: [TUHS] Utility privs Message-ID: <021201d3df11$6ba65fa0$42f31ee0$@ronnatalie.com> Depending on the system PS may or may not need to be setuid to work by non-root users. Ping needs to be setuid because it uses raw sockets which are restricted (much like opening listens on low number ports) in many systems. From itz at very.loosely.org Sun Apr 29 04:01:47 2018 From: itz at very.loosely.org (Ian Zimmerman) Date: Sat, 28 Apr 2018 11:01:47 -0700 Subject: [TUHS] rm command In-Reply-To: <20180428163351.GG20510@h-174-65.A328.priv.bahnhof.se> References: <20180425221716.B4C6718C086@mercury.lcs.mit.edu> <20180428163351.GG20510@h-174-65.A328.priv.bahnhof.se> Message-ID: <20180428180147.vk7f23hguvmag4ir@matica.foolinux.mooo.com> On 2018-04-28 16:33, Michael Kjörling wrote: > /bin/fusermount is, of all modes they could choose from, `-rwsr-xr--`. it is setuid root because it needs the mount() syscall. it is only executable by a group (probably other than root, but you didn't say) to restrict the functionality to a subset of real users. I find than debian has these things _very_ well thought out - better than any Unix-like system in widespread use now. Or rather, 2 years ago when I stopped using it because systemd. -- Please don't Cc: me privately on mailing lists and Usenet, if you also post the followup to the list or newsgroup. To reply privately _only_ on Usenet and on broken lists which rewrite From, fetch the TXT record for no-use.mooo.com. From dfawcus+lists-tuhs at employees.org Sun Apr 29 04:51:15 2018 From: dfawcus+lists-tuhs at employees.org (Derek Fawcus) Date: Sat, 28 Apr 2018 19:51:15 +0100 Subject: [TUHS] rm command In-Reply-To: <20180428163351.GG20510@h-174-65.A328.priv.bahnhof.se> References: <20180425221716.B4C6718C086@mercury.lcs.mit.edu> <20180428163351.GG20510@h-174-65.A328.priv.bahnhof.se> Message-ID: <20180428185115.GA97169@accordion.employees.org> On Sat, Apr 28, 2018 at 04:33:51PM +0000, Michael Kjörling wrote: > > If you want weird, then tell me why on Earth /bin/ping _really_ needs > to be setuid root on Linux (has no one heard of capabilities?), It doesn't even need that anymore, like darwin it supports SOCK_DGRAM ICMP sockets, such that ping can be written as an unpriviledged program. DF From jnc at mercury.lcs.mit.edu Sun Apr 29 06:40:08 2018 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Sat, 28 Apr 2018 16:40:08 -0400 (EDT) Subject: [TUHS] /dev/drum Message-ID: <20180428204008.5D76D18C094@mercury.lcs.mit.edu> > From: Johnny Billquist > Gah. If I were to try and collect every copy made, it would be quite a > collection. Well, just the 'processor handbook's (the little paperback things), I have about 30. (If you add devices, that probably doubles it.) I think my collection is complete. > So there was a total change in terminology early in the 11/45 life, it > would appear. I wonder why. ... I probably would not blame some market > droids. I was joking, but also serious. I really do think it was most likely marketing-driven. (See below for why I don't think it was engineering-driven, which leaves....) I wonder if there's anything in the DEC archives (a big chunk of which are now at the CHM) which would shed any light? Some of the archives are online there, e.g.: http://www.bitsavers.org/pdf/dec/pdp11/memos/ but it seems to be mostly engineering (although there's some that would be characterized as marketing). > one of the most important differences between segmentation and pages are > that with segmentation you only have one contiguous range of memory, > described by a base and a length register. This will be a contiguous > range of memory both in virtual memory, and in physical memory. I agree completely (although I extend it to multiple segments, each of which has the characterstics you describe). Which is why I think the original DEC nomenclature for the PDP-11's memory management was more appropriate - the description above is _exactly_ the functionality provided for each of the 8 'chunks' (to temporarily use a neutral term) of PDP-11 address space, which don't quack like most other 'pages' (to use the 'if it quacks like a duck' standard). One query I have comes from the usual goal of 'virtual memory' (which is the concept most tightly associated with 'pages'), which is to allow a process to run without all of its pages in physical memory. I don't know much about PDP-11 DEC OS's, but do any of them do this? (I.e. allow partial residency.) If not, that would be ironic (in view of the later name) - and, I think, evidence that the PDP-11 'chunks' aren't really pages. BTW, did you know that prior to the -11/45, there was a memory management device for the PDP-11 which provided 'real' paging, the KT11-B? More here: http://gunkies.org/wiki/KT11-B_Paging_Option I seem to recall some memos in the memo archive that discussed it; I _think_ it mentioned why they decided not to go that way in doing memory management for the /45, but I forget the details? (Maybe the performance hit of keeping the page tables in main memory was significant?)_ > With segmentation you cannot have your virtual memory split up and > spread out over physical memory. Err, Multics did that; the process' address space was split up into many segments (a true 2-dimensional naming system, with 18 bits of segment number), which were then split up into pages, for both virtual memory ('not all resident'), and for physical memory allocation. Although I suppose one could view that as two separate, sequential steps - i.e. i) the division into segments, and ii) the division of segments into pages. In fact, I take this approach in describing the Multics memory system, since it's easier to understand as two independent things. > You can also have "holes" in your memory, with pages that are invalid, > yet have pages higher up in your memory .. Something that is impossible > with segmentation, since you only have one set of registers for each > memory type (at most) in a segmented memory implementation. You seem to be thinking of segmentation a la Intel 8086, which is a hack they added to allow use of more memory (although I suspect that PDP-11 chunks were a hack of a similar flavour). At the time we are speaking of, the Intel 8086 did not exist (it came along quite few years later). The systems which supported segmentation, such as Multics, the Burroughs 5000 and successors, etc had 'real' segmentation, with a full two-dimensional naming system for memory. (Burroughs 5000 segment numbers were 10 bits wide.) > I mean, when people talk about segmented memory, what most everyone > today thinks of is the x86 model, where all of this certainly is true. It's also (IMNSHO) irrelevant to this. Intel's brain-damage is not the entirety of computer science (or shouldn't be). (BTW, later Intel xx86 machines did allow you have to 'holes' in segments, via the per-segment page tables.) > it would be very wrong to call what the PDP-11 have segmentation The problem is that what PDP-11 memory management does isn't really like _either_ segmentation, or paging, as practised in other machines. With only 8 chunks, it's not like Multics etc, which have very large address spaces split up into many segments. (And maybe _that_'s why the name was changed - when people heard 'segments' they thought 'lots of them'.) However, it's not like paging on effectively all other systems with paging, because in them paging's used to provide virtual memory (in the sense of 'the process runs with pages missing from real memory'), and to make memory allocation simple by use of fixed-size page frames. So any name given PDP-11 'chunks' is going to have _some_ problems. It just thing 'segmentation' (as you defined it at the top) is a better fit than the alternative... Noel From imp at bsdimp.com Sun Apr 29 07:03:06 2018 From: imp at bsdimp.com (Warner Losh) Date: Sat, 28 Apr 2018 15:03:06 -0600 Subject: [TUHS] Utility privs In-Reply-To: <021201d3df11$6ba65fa0$42f31ee0$@ronnatalie.com> References: <021201d3df11$6ba65fa0$42f31ee0$@ronnatalie.com> Message-ID: On Sat, Apr 28, 2018 at 10:53 AM, Ron Natalie wrote: > Depending on the system PS may or may not need to be setuid to work by > non-root users. > > Ping needs to be setuid because it uses raw sockets which are restricted > (much like opening listens on low number ports) in many systems. > OSes could provide a controlled interface to ping, but there's not enough of a win to do so. Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From bqt at update.uu.se Mon Apr 30 01:37:46 2018 From: bqt at update.uu.se (Johnny Billquist) Date: Sun, 29 Apr 2018 17:37:46 +0200 Subject: [TUHS] /dev/drum In-Reply-To: <20180428204008.5D76D18C094@mercury.lcs.mit.edu> References: <20180428204008.5D76D18C094@mercury.lcs.mit.edu> Message-ID: On 2018-04-28 22:40, Noel Chiappa wrote: > > From: Johnny Billquist > > > Gah. If I were to try and collect every copy made, it would be quite a > > collection. > > Well, just the 'processor handbook's (the little paperback things), I have > about 30. (If you add devices, that probably doubles it.) I think my > collection is complete. I have no idea how many different editions DEC printed. There were certainly several done for some models, as well as several books that covered different combinations of models. All in all, 30 does not surprise me. And I would not be surprised if it were even more... > > So there was a total change in terminology early in the 11/45 life, it > > would appear. I wonder why. ... I probably would not blame some market > > droids. > > I was joking, but also serious. I really do think it was most likely > marketing-driven. (See below for why I don't think it was engineering-driven, > which leaves....) > > I wonder if there's anything in the DEC archives (a big chunk of which are now > at the CHM) which would shed any light? Some of the archives are online there, > e.g.: > > http://www.bitsavers.org/pdf/dec/pdp11/memos/ > > but it seems to be mostly engineering (although there's some that would be > characterized as marketing). Yeah. I've read a bunch of those memos in the past. I don't think they in general were concerned with terminology, so I'm not surprised if you don't find anything relevant there. > > one of the most important differences between segmentation and pages are > > that with segmentation you only have one contiguous range of memory, > > described by a base and a length register. This will be a contiguous > > range of memory both in virtual memory, and in physical memory. > > I agree completely (although I extend it to multiple segments, each of which > has the characterstics you describe). Right. The I think we're on the same page. I won't comment further on the x86 which I mentioned before, since I think we can all agree that that one is really brain damaged. > Which is why I think the original DEC nomenclature for the PDP-11's memory > management was more appropriate - the description above is _exactly_ the > functionality provided for each of the 8 'chunks' (to temporarily use a > neutral term) of PDP-11 address space, which don't quack like most other > 'pages' (to use the 'if it quacks like a duck' standard). This is where I disagree. The problem is that the chunks in the PDP-11 do not describe things from a zero offset, while a segment do. Only chunk 0 is describing addresses from a 0 offset. And exactly which chunk is selected is based on the virtual address, and nothing else. It's a good analogy to view segments in the same way as you might view them in object files, or sometimes even in executables. One segment is a more or less self contained chunk, described by one segment descriptor, or whatever you want to call them. This is not possible to do on a PDP-11 with the chunks we have. > One query I have comes from the usual goal of 'virtual memory' (which is the > concept most tightly associated with 'pages'), which is to allow a process to > run without all of its pages in physical memory. > > I don't know much about PDP-11 DEC OS's, but do any of them do this? (I.e. > allow partial residency.) If not, that would be ironic (in view of the later > name) - and, I think, evidence that the PDP-11 'chunks' aren't really pages. Demand paging really is a separate thing from virtual memory. It's a very bad thing to try and conflate the two. There is nothing about virtual memory that says that you do not have to have all of your virtual memory mapped to physical memory when the process is running. Virtual memory is just *virtual* memory. It's not "real" or physical in the sense that it has a dedicated location in physical memory, which would be the same for all processes talking about that memory address. Instead, each process has its own memory, which might be mapped somewhere in physical memory, but it might also not be. And one processes address 0 is not the same as another processes address 0. They both have the illusion that they have the full memory address range to them selves, unaware of the fact that there are many processes who also have that same illusion. And meanwhile, the OS has it's own idea about the memory, and the OS also knows how the physical memory is used, and keeps resources, and the allocation of them, under control on behalf of the processes, without the processes knowing this. Without virtual memory, each process would have to deal with physical memory, and then each process would have to be aware of all the other processes that use memory, and make sure that no two processes try to use the same memory, or chaos ensues. You can do virtual memory with segmentation as well. Since this also means have a translation between your virtual address and a physical address. It's just that the translations are a bit easier and more straight forward with segments. > BTW, did you know that prior to the -11/45, there was a memory management > device for the PDP-11 which provided 'real' paging, the KT11-B? More here: > > http://gunkies.org/wiki/KT11-B_Paging_Option I knew about it, but have never read any technical details. Interesting read. > I seem to recall some memos in the memo archive that discussed it; I _think_ > it mentioned why they decided not to go that way in doing memory management > for the /45, but I forget the details? (Maybe the performance hit of keeping > the page tables in main memory was significant?)_ There might have been several reasons, but performance would most likely be one of them. > > With segmentation you cannot have your virtual memory split up and > > spread out over physical memory. > > Err, Multics did that; the process' address space was split up into many > segments (a true 2-dimensional naming system, with 18 bits of segment number), > which were then split up into pages, for both virtual memory ('not all > resident'), and for physical memory allocation. > > Although I suppose one could view that as two separate, sequential steps - > i.e. i) the division into segments, and ii) the division of segments into > pages. In fact, I take this approach in describing the Multics memory system, > since it's easier to understand as two independent things. Yes. I definitely view that as two independent things stacked on top of each other. And it would appear you do too. :-) And that allows such a spread, as well as holes, through the paging part. The segmentation part does not allow for it. > > it would be very wrong to call what the PDP-11 have segmentation > > The problem is that what PDP-11 memory management does isn't really like > _either_ segmentation, or paging, as practised in other machines. With only 8 > chunks, it's not like Multics etc, which have very large address spaces split > up into many segments. (And maybe _that_'s why the name was changed - when > people heard 'segments' they thought 'lots of them'.) > > However, it's not like paging on effectively all other systems with paging, > because in them paging's used to provide virtual memory (in the sense of 'the > process runs with pages missing from real memory'), and to make memory > allocation simple by use of fixed-size page frames. > > So any name given PDP-11 'chunks' is going to have _some_ problems. It just > thing 'segmentation' (as you defined it at the top) is a better fit than the > alternative... Agreed that there is some problem in classifying them either way. However, the objection against pages are solely based on the fact that they are not fixed in size, while with segments, it becomes much more strange. But how do you then view modern architectures which have different sized pages? Are they no longer pages then? 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 usotsuki at buric.co Mon Apr 30 02:34:49 2018 From: usotsuki at buric.co (Steve Nickolas) Date: Sun, 29 Apr 2018 12:34:49 -0400 (EDT) Subject: [TUHS] /dev/drum In-Reply-To: References: <20180428204008.5D76D18C094@mercury.lcs.mit.edu> Message-ID: On Sun, 29 Apr 2018, Johnny Billquist wrote: > Right. The I think we're on the same page. I won't comment further on the x86 > which I mentioned before, since I think we can all agree that that one is > really brain damaged. I'm not sure whether the 65C816 might actually be *more* brain-damaged in its segmentation than the 8088. That said, I suspect the 8088 is worse because of the bitshift. -uso. From imp at bsdimp.com Mon Apr 30 02:48:26 2018 From: imp at bsdimp.com (Warner Losh) Date: Sun, 29 Apr 2018 10:48:26 -0600 Subject: [TUHS] /dev/drum In-Reply-To: References: <20180428204008.5D76D18C094@mercury.lcs.mit.edu> Message-ID: On Sun, Apr 29, 2018 at 10:34 AM, Steve Nickolas wrote: > On Sun, 29 Apr 2018, Johnny Billquist wrote: > > Right. The I think we're on the same page. I won't comment further on the >> x86 which I mentioned before, since I think we can all agree that that one >> is really brain damaged. >> > > I'm not sure whether the 65C816 might actually be *more* brain-damaged in > its segmentation than the 8088. That said, I suspect the 8088 is worse > because of the bitshift. > For the 8088, it depends. If you don't care about no memory protection, then the segments make a nice fairly granular way to slice up the space between 'processes'. Old-school Unix for the 8088 used 'small model' to get relocatable binaries anywhere in the 1MB space. For that use case, it's quite convenient. Of course, for anything else, or if you want memory protection, or demand pages, or well a bunch of other stuff here, it totally sucks. Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: