From jnc at mercury.lcs.mit.edu Sun Jun 1 00:19:14 2014 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Sat, 31 May 2014 10:19:14 -0400 (EDT) Subject: [TUHS] Bugs in V6 'dcheck' Message-ID: <20140531141914.BB15818C0CA@mercury.lcs.mit.edu> > From: Ronald Natalie > If I understand what you are saying, it only occurs when you run dcheck > with mutliple volumes at one time? Right, _both_ bugs have that characteristic. But the first one (the fence-post) only happens in very particular circumstances; the second (the un-initialized variable) should have happened every time. > From: norman at oclsc.org (Norman Wilson) > To me it's not surprising at all. > On one hand, current examples of widely-distributed critical code > containing serious flaws are legion. What astonished me was not that there was a bug (which I can easily believe), but that it was one that would have happened _every time they ran it_. 'dcheck' has this list of disks compiled into it. (Oh, BTW, my fixed version now reads a file, /etc/disks; I am running a number of simulated machines, and the compiled-in table was a pain.) So I would have thought they must have at least tried that mode of operation once? And running it that way just once should have shown the bug. Or did they try it, see the bug, and 'dealt' with it by just never running it that way? Noel From jnc at mercury.lcs.mit.edu Sun Jun 1 01:55:27 2014 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Sat, 31 May 2014 11:55:27 -0400 (EDT) Subject: [TUHS] Bugs in V6 'dcheck' Message-ID: <20140531155527.39A3B18C09C@mercury.lcs.mit.edu> > From: jnc at mercury.lcs.mit.edu (Noel Chiappa) > the second (the un-initialized variable) should have happened every > time. OK, so I was wrong! The variable in question was a global static, 'ino' (the current inode number), so the answer isn't something simple like 'it was an auto that happened to be cleared for each disk'. But now that I look closely, I think I see a way it might have worked. 'dcheck' is a two-pass per disk thing: it begins each disk by clearing its 'inode link count' table; then the first pass does a pass over all the inodes, and for ones that are directories, increments counts for all the entries; the second pass re-scans all the inodes, and makes sure that the link count in the inode itself matches the computed count in the table. 'ino' was cleared before the _second_ pass, but not the _first_. So it was zero for the first pass of the first disk, but non-zero for the first pass on the second disk. This looks like the kind of bug that should almost always be fatal, right? That's what I thought at first... (and I tried the original version on one of my machines to make sure it did fail). But... The loop in each pass has two index variables, one of which is 'ino', which it compares with the maximum inode number for that disk (per the super-block), and bails if it reaches the max: for(i=0; ino References: <20140531133051.5F2531DE37F@lignose.oclsc.org> Message-ID: <20140531160302.GB371@mercury.ccil.org> Norman Wilson scripsit: > (To me, anyway. Back in the 1980s, when I was at Bell Labs, > SP&E published a paper by Don Knuth discussing all the many > bugs found in TeX, including some statistical analysis. I > thought it fascinating and revealing and think reading it > made me a better programmer. Rob Pike thought it was terribly > boring and shouldn't have been published. Decidedly different > viewpoints.) I agree that "The Errors of TeX" was an excellent article. Mr. Pike is well-known to be, mmmm, easily bored. On the other hand, his sense of humor isn't to everyone's taste, either. -- John Cowan http://www.ccil.org/~cowan cowan at ccil.org Even the best of friends cannot attend each others' funeral. --Kehlog Albran, The Profit From ron at ronnatalie.com Sun Jun 1 02:18:06 2014 From: ron at ronnatalie.com (Ron Natalie) Date: Sat, 31 May 2014 12:18:06 -0400 Subject: [TUHS] Bugs in V6 'dcheck' In-Reply-To: <20140531155527.39A3B18C09C@mercury.lcs.mit.edu> References: <20140531155527.39A3B18C09C@mercury.lcs.mit.edu> Message-ID: <006001cf7ceb$e81ac120$b8504360$@ronnatalie.com> > OK, so I was wrong! The variable in question was a global static, 'ino' (the current inode number), Static is a much overloaded word in C, it's just a global variable. > 'ino' was cleared before the _second_ pass, but not the _first_. So it was zero for the first pass of the first disk, but non-zero for the first pass on the second disk. Yes, and in the version 7 version of icheck (http://www.tuhs.org/Archive/PDP-11/Trees/V7/usr/src/cmd/dcheck.c) they appear to have fixed it. It is set to zero before both the pass1 and pass2 loops. I'm pretty sure whoever added the feature to check more than one file system at a time didn't test it very well in V6. From cowan at mercury.ccil.org Sun Jun 1 03:16:17 2014 From: cowan at mercury.ccil.org (John Cowan) Date: Sat, 31 May 2014 13:16:17 -0400 Subject: [TUHS] Bugs in V6 'dcheck' In-Reply-To: <20140531161620.GL28034@mcvoy.com> References: <20140531133051.5F2531DE37F@lignose.oclsc.org> <20140531160302.GB371@mercury.ccil.org> <20140531161620.GL28034@mcvoy.com> Message-ID: <20140531171617.GB10214@mercury.ccil.org> Larry McVoy scripsit: > I love Rob Pike, he's spot on on a lot of stuff. I'm a big fan of > "if you think you need threads then your processes are too fat". Oh, he's a brilliant fellow. I don't know him personally, but I know people who do, and I don't think I'd love him if I knew him. Humanity has always found it useful to keep its (demi)gods at arm's length at least. -- John Cowan http://www.ccil.org/~cowan cowan at ccil.org Barry thirteen gules and argent on a canton azure fifty mullets of five points of the second, six, five, six, five, six, five, six, five, and six. --blazoning the U.S. flag From tim.newsham at gmail.com Sun Jun 1 04:58:39 2014 From: tim.newsham at gmail.com (Tim Newsham) Date: Sat, 31 May 2014 08:58:39 -1000 Subject: [TUHS] Bugs in V6 'dcheck' In-Reply-To: <20140531131504.AC41E18C0C8@mercury.lcs.mit.edu> References: <20140531131504.AC41E18C0C8@mercury.lcs.mit.edu> Message-ID: There are bugs to be found, and it can be a fun hunt (though not too much of a challenge). Here are some more (security related, as thats my inclination): http://marc.info/?l=bugtraq&m=108627540130457&w=2 http://minnie.tuhs.org/pipermail/unix-jun72/2008-May/000126.html http://minnie.tuhs.org/pipermail/unix-jun72/2008-May/000250.html Tim On Sat, May 31, 2014 at 3:15 AM, Noel Chiappa wrote: > So it turns out the 'dcheck' distributed with V6 has two (well, three, but > the third one was only a potential problem for me) bugs it. > > > The first was a fence-post error on a table clearing operation; it could > cause the entry for the last inode of the disk in the constructed table of > directory entry counts to start with a non-zero count when a second disk was > scanned. However, it was only triggered in very specific circumstances: > > - A larger disk was listed before a smaller one (either in the command line, > or compiled in) > - The inode on the larger disk corresponding to the last inode on the smaller > one was in use > > I can understand how they never ran across this one. > > > The other one, however, which was an un-initalized variable, should have > bitten them anytime they had more than one disk listed! It caused the > constructed table of directory entry counts to be partially or wholly > (depending on the size of the two disks) blank in all disks after the first > one, causing numerous (bogus) error reports. > > (It was also amusing to find an un-used procedure in the source; it looks > like dcheck was written starting with the code for 'icheck' - which explains > the second bug; since the logic in icheck is subtly different, that variable > _is_ set properly in icheck.) > > How this bug never bit them I cannot understand - unless they saw it, and > couldn't be bothered to find and fix it! > > To me, it's completely amazing to find such a serious bug in such a critical > piece of widely-distributd code! A lesson for archaeologists... > > > Anyway, a fixed version is here: > > http://ana-3.lcs.mit.edu/~jnc/tech/unix/ucmd/dcheck.c > > if anyone cares/needs it. > > Noel > _______________________________________________ > TUHS mailing list > TUHS at minnie.tuhs.org > https://minnie.tuhs.org/mailman/listinfo/tuhs -- Tim Newsham | www.thenewsh.com/~newsham | @newshtwit | thenewsh.blogspot.com From clemc at ccc.com Sun Jun 1 05:48:09 2014 From: clemc at ccc.com (Clem Cole) Date: Sat, 31 May 2014 15:48:09 -0400 Subject: [TUHS] Bugs in V6 'dcheck' In-Reply-To: <20140531131504.AC41E18C0C8@mercury.lcs.mit.edu> References: <20140531131504.AC41E18C0C8@mercury.lcs.mit.edu> Message-ID: <86E5991D-308B-4700-946B-449A35C06084@ccc.com> btw. there is a v6 version of fsck floating around. CMU was still running v6 when Ted did his OYOC. he later moved it to unix/TS (aka v7) which was the release mechanics out side of BTL. I'm wonder if I can find a readable copy. funny I remember the first time fsck saved our butts we had had power failure and corrupted two file systems on the EE dept 11/34 I was running Icheck/dcheck and the like trying patch the system and getting it running a gaining. this new grad student (tjk) says he has something he wanted to try that he wrote over the summer /he had started writing at michiga. the machine was dead Ted had it on a tape and getting it on to an rk05 was a trick - we ended up doing it on the IUS system in CS. once it was running we were in awe man that program migrated to all the CMU pdp11s within hours Clem > On May 31, 2014, at 9:15 AM, jnc at mercury.lcs.mit.edu (Noel Chiappa) wrote: > > So it turns out the 'dcheck' distributed with V6 has two (well, three, but > the third one was only a potential problem for me) bugs it. > > > The first was a fence-post error on a table clearing operation; it could > cause the entry for the last inode of the disk in the constructed table of > directory entry counts to start with a non-zero count when a second disk was > scanned. However, it was only triggered in very specific circumstances: > > - A larger disk was listed before a smaller one (either in the command line, > or compiled in) > - The inode on the larger disk corresponding to the last inode on the smaller > one was in use > > I can understand how they never ran across this one. > > > The other one, however, which was an un-initalized variable, should have > bitten them anytime they had more than one disk listed! It caused the > constructed table of directory entry counts to be partially or wholly > (depending on the size of the two disks) blank in all disks after the first > one, causing numerous (bogus) error reports. > > (It was also amusing to find an un-used procedure in the source; it looks > like dcheck was written starting with the code for 'icheck' - which explains > the second bug; since the logic in icheck is subtly different, that variable > _is_ set properly in icheck.) > > How this bug never bit them I cannot understand - unless they saw it, and > couldn't be bothered to find and fix it! > > To me, it's completely amazing to find such a serious bug in such a critical > piece of widely-distributd code! A lesson for archaeologists... > > > Anyway, a fixed version is here: > > http://ana-3.lcs.mit.edu/~jnc/tech/unix/ucmd/dcheck.c > > if anyone cares/needs it. > > Noel > _______________________________________________ > TUHS mailing list > TUHS at minnie.tuhs.org > https://minnie.tuhs.org/mailman/listinfo/tuhs From doug at cs.dartmouth.edu Sun Jun 1 09:24:57 2014 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Sat, 31 May 2014 19:24:57 -0400 Subject: [TUHS] Bugs in V6 'dcheck' Message-ID: <201405312324.s4VNOvFV028181@stowe.cs.dartmouth.edu> > Ken and Dennis and the other guys behind > the earliest UNIX code were smart guys and good programmers, > but they were far from perfect; and back in those days we > were all a lot sloppier. The observation that exploits may be able to parlay mundane bugs into security holes was not a commonplace back then--even in the Unix room. So input buffers were often made "bigger than ever will be needed" and left that way on the understanding that crashes are tolerable on outlandish data. In an idle moment one day, Dennis fed a huge line of input to most everything in /bin. To the surprise of nobody, including Dennis, lots of programs crashed. We WERE surprised a few years later, when a journal published this fact as a research result. Does anybody remember who published that deep new insight and/or where? Doug From schoedel at kw.igs.net Sun Jun 1 10:17:12 2014 From: schoedel at kw.igs.net (Kevin Schoedel) Date: Sat, 31 May 2014 20:17:12 -0400 Subject: [TUHS] Bugs in V6 'dcheck' In-Reply-To: <201405312324.s4VNOvFV028181@stowe.cs.dartmouth.edu> References: <201405312324.s4VNOvFV028181@stowe.cs.dartmouth.edu> Message-ID: At 7:24 ?pm -0400 2014/05/31, Doug McIlroy wrote: >Does anybody >remember who published that deep new insight and/or where? Probably this: B.P. Miller, L. Fredriksen, So, B. "An Empirical Study of the Reliability of UNIX Utilities", Communications of the ACM 33, 12 (December 1990) -- Kevin Schoedel VA3TCS From scj at yaccman.com Mon Jun 2 08:54:38 2014 From: scj at yaccman.com (scj at yaccman.com) Date: Sun, 1 Jun 2014 15:54:38 -0700 Subject: [TUHS] Bugs in V6 'dcheck' In-Reply-To: References: <201405312324.s4VNOvFV028181@stowe.cs.dartmouth.edu> Message-ID: <165d8f375f191dc4367028c096d457ce.squirrel@webmail.yaccman.com> Doug is quite right that we were much more relaxed about security then. THe academic world was very much inspired at the time by the idea that one could prove programs correct using mathematics. I remember having some very spirited arguments on this topic with some academics. My argument was roughly "Proving programs is stupid. Look at Unix. It's insanely useful, but most programs can't be proved correct because they aren't!". Buffer overflow was one of the bugs I had in mind. It was embarrassing in later years to read about all the hackers exploiting these bugs. In our defence, with only <= 64KB for programs and data and the slow machines of the day, dynamic allocation and subscript checking were often impractical... Steve > At 7:24 ?pm -0400 2014/05/31, Doug McIlroy wrote: >>Does anybody >>remember who published that deep new insight and/or where? > > Probably this: > B.P. Miller, L. Fredriksen, So, B. "An Empirical Study of the Reliability > of UNIX Utilities", Communications of the ACM 33, 12 (December 1990) > > > -- > Kevin Schoedel VA3TCS > _______________________________________________ > TUHS mailing list > TUHS at minnie.tuhs.org > https://minnie.tuhs.org/mailman/listinfo/tuhs > From a.phillip.garcia at gmail.com Mon Jun 2 09:48:48 2014 From: a.phillip.garcia at gmail.com (A. P. Garcia) Date: Sun, 1 Jun 2014 18:48:48 -0500 Subject: [TUHS] Bugs in V6 'dcheck' In-Reply-To: <201405312324.s4VNOvFV028181@stowe.cs.dartmouth.edu> References: <201405312324.s4VNOvFV028181@stowe.cs.dartmouth.edu> Message-ID: On May 31, 2014 6:25 PM, "Doug McIlroy" wrote: > > > Ken and Dennis and the other guys behind > > the earliest UNIX code were smart guys and good programmers, > > but they were far from perfect; and back in those days we > > were all a lot sloppier. > > The observation that exploits may be able to parlay > mundane bugs into security holes was not a commonplace > back then--even in the Unix room. So input buffers were > often made "bigger than ever will be needed" and left > that way on the understanding that crashes are tolerable > on outlandish data. In an idle moment one day, Dennis fed > a huge line of input to most everything in /bin. To the > surprise of nobody, including Dennis, lots of programs > crashed. We WERE surprised a few years later, when a journal > published this fact as a research result. Does anybody > remember who published that deep new insight and/or where? > > Doug yeah, that's not really sporting. I've always wondered about something else, though: Were the original Unix authors annoyed when they learned that some irascible young upstart named Richard Stallman was determined to make a free Unix clone? Was he a gadfly, or just some kook you decided to ignore? The fathers of Unix have been strangely silent on this topic for many years. Maybe nobody's ever asked? -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron at ronnatalie.com Mon Jun 2 11:11:30 2014 From: ron at ronnatalie.com (Ronald Natalie) Date: Sun, 1 Jun 2014 21:11:30 -0400 Subject: [TUHS] Bugs in V6 'dcheck' In-Reply-To: References: <201405312324.s4VNOvFV028181@stowe.cs.dartmouth.edu> Message-ID: Some UPSTART named RMS in his whole odipherous spledor couldn't even spell LINUX. If you read his earlier manifesto rants he hated UNIX with a passion. Holding out the TOPS operating systems as the be-all and end-all of user interface. Despite his disingenous propaganda, he didn't invent LINUX (or any other UNIX clone). RMS didn't even enter onto the UNIX scene until after he had been burned by LMI/Symbolics/MIT over contributions he made to the Lisp Machine that he assumed would always be freely available. I was a rather late comer to UNIX, having not started on it until 1977, RMS wasn't anywhere around until over a decade later. I was happy that Ken and Dennis and the folks were coming up with the design pattern and not worrying about every single bug in the system. This was RESEARCH. Those of us in the direct trenches at the places that got UNIX under the "scrap metal" provisions got to make our own contribution by increasing robustness and performance as well as extended the underlying paradigm. > yeah, that's not really sporting. I've always wondered about something else, though: Were the original Unix authors annoyed when they learned that some irascible young upstart named Richard Stallman was determined to make a free Unix clone? Was he a gadfly, or just some kook you decided to ignore? The fathers of Unix have been strangely silent on this topic for many years. Maybe nobody's ever asked? > > _______________________________________________ > TUHS mailing list > TUHS at minnie.tuhs.org > https://minnie.tuhs.org/mailman/listinfo/tuhs -------------- next part -------------- An HTML attachment was scrubbed... URL: From doug at cs.dartmouth.edu Mon Jun 2 12:09:26 2014 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Sun, 01 Jun 2014 22:09:26 -0400 Subject: [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck') Message-ID: <201406020209.s5229Q5o006174@stowe.cs.dartmouth.edu> Phil Garcia wrote: I've always wondered about something else, though: Were the original Unix authors annoyed when they learned that some irascible young upstart named Richard Stallman was determined to make a free Unix clone? Was he a gadfly, or just some kook you decided to ignore? The fathers of Unix have been strangely silent on this topic for many years. Maybe nobody's ever asked? Gnu was always taken as a compliment. And of course the Unix clone was pie in the sky until Linus came along. I wonder about the power relationship underlying "GNU/Linux", as rms modestly styles it. There are certain differences in taste between Unix and Gnu, vide emacs and texinfo. (I grit my teeth every time a man page tells me, "The full documentation for ___ is maintained as a Texinfo file.") But all disagreement is swept away before the fact that the old familiar environment is everywhere, from Cray to Apple, with rms a very important contributor. Doug From a.phillip.garcia at gmail.com Mon Jun 2 12:10:01 2014 From: a.phillip.garcia at gmail.com (A. P. Garcia) Date: Sun, 1 Jun 2014 21:10:01 -0500 Subject: [TUHS] Bugs in V6 'dcheck' In-Reply-To: References: <201405312324.s4VNOvFV028181@stowe.cs.dartmouth.edu> Message-ID: On Jun 1, 2014 8:11 PM, "Ronald Natalie" wrote: > > Some UPSTART named RMS in his whole odipherous spledor couldn't even spell LINUX. This I've always found ironic, that he's sore because people call the os linux and don't give gnu credit, when gnu itself was simply a unix ripoff. Trying to empathize with the creators of unix, I think I would've felt like someone was stealing things I'd worked hard to produce. But I don't know. Like you said, he wrote manifestos and rants, so I might just as well have dismissed him as a nut. You could also take the magnanimous view that he was actually helping spread your ideas, albeit while putting his own political spin on things. I'm sorry, I wasn't trying to troll or start a flame war. RMS is something of an enigma to me. > RMS didn't even enter onto the UNIX scene until after he had been burned by LMI/Symbolics/MIT over contributions he made to the Lisp Machine that he assumed would always be freely available. I was a rather late comer to UNIX, having not started on it until 1977, RMS wasn't anywhere around until over a decade later. I think he likes to throw 1984 around as the year he wrote the 'gnu manifesto'. > I was happy that Ken and Dennis and the folks were coming up with the design pattern and not worrying about every single bug in the system. This was RESEARCH. Those of us in the direct trenches at the places that got UNIX under the "scrap metal" provisions got to make our own contribution by increasing robustness and performance as well as extended the underlying paradigm. And it's a beautiful design that has adapted remarkably well to new technologies for decades. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cowan at mercury.ccil.org Mon Jun 2 12:24:20 2014 From: cowan at mercury.ccil.org (John Cowan) Date: Sun, 1 Jun 2014 22:24:20 -0400 Subject: [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck') In-Reply-To: <201406020209.s5229Q5o006174@stowe.cs.dartmouth.edu> References: <201406020209.s5229Q5o006174@stowe.cs.dartmouth.edu> Message-ID: <20140602022420.GD18282@mercury.ccil.org> Doug McIlroy scripsit: > But all disagreement is swept away before the fact that the old > familiar environment is everywhere, from Cray to Apple, with rms > a very important contributor. Amen. My checkered career has taken me from Eunice to Microsoft Xenix System III to Solaris to BSD386 to Linux (native and CoLinux) to Cygwin, and except when playing a sysadmin I have never had to know or care which flavor of the Grand Ole OSry I was using that year. -- John Cowan http://www.ccil.org/~cowan cowan at ccil.org Assent may be registered by a signature, a handshake, or a click of a computer mouse transmitted across the invisible ether of the Internet. Formality is not a requisite; any sign, symbol or action, or even willful inaction, as long as it is unequivocally referable to the promise, may create a contract. --Specht v. Netscape From msokolov at ivan.Harhan.ORG Mon Jun 2 12:14:25 2014 From: msokolov at ivan.Harhan.ORG (Michael Spacefalcon) Date: Mon, 2 Jun 2014 02:14:25 GMT Subject: [TUHS] Bugs in V6 'dcheck' Message-ID: <1406020214.AA11094@ivan.Harhan.ORG> A. P. Garcia wrote: > Were the original Unix authors annoyed when they learned that > some irascible young upstart named Richard Stallman was determined to make > a free Unix clone? A deeper, more profound question would be: how did these original Unix authors feel about their employer owning the rights to their creation? Did they feel any guilt at all for having had to sign over all rights in exchange for their paychecks? Did Dennis and/or Ken personally wish their creation were free to the world, public domain, or were they personally in agreement with the licensing policies of their employer? I argue that this question is far more important than how they felt about RMS (if they cared at all). Ronald Natalie wrote: > [RMS] If you read his earlier manifesto rants he hated UNIX = > with a passion. > Holding out the TOPS operating systems as the be-all and end-all of user = > interface. I wish more people would point out this aspect of RMS and GNU. While I wholeheartedly agree with Richard on the general philosophy of free software, i.e., the *ethics* part and the Four Freedoms, when it comes to GNU as a specific OS, in technical terms, I've always disliked everything about it. I love UNIX, and as Ron pointed it out like few people do, GNU was fundamentally born out of hatred for the thing I love. SF From cowan at mercury.ccil.org Mon Jun 2 12:51:23 2014 From: cowan at mercury.ccil.org (John Cowan) Date: Sun, 1 Jun 2014 22:51:23 -0400 Subject: [TUHS] Bugs in V6 'dcheck' In-Reply-To: <1406020214.AA11094@ivan.Harhan.ORG> References: <1406020214.AA11094@ivan.Harhan.ORG> Message-ID: <20140602025123.GE18282@mercury.ccil.org> Michael Spacefalcon scripsit: > Did Dennis and/or Ken personally wish their creation were free to the > world, public domain, or were they personally in agreement with the > licensing policies of their employer? The record is quite clear on that. How the 50 fixes tape got out of Bell Labs may not be as puzzling as the song the Sirens sang or who blew up Mallow Bridge, but likewise the question is not beyond all conjecture. Ken wanted those diffs out there, the more so because they didn't all come from inside the Labs. See the seventh page of for details. -- John Cowan http://www.ccil.org/~cowan cowan at ccil.org 'Tis the Linux rebellion / Let coders take their place, The Linux-nationale / Shall Microsoft outpace, We can write better programs / Our CPUs won't stall, So raise the penguin banner of / The Linux-nationale. --Greg Baker From imp at bsdimp.com Mon Jun 2 12:59:13 2014 From: imp at bsdimp.com (Warner Losh) Date: Sun, 1 Jun 2014 20:59:13 -0600 Subject: [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck') In-Reply-To: <201406020209.s5229Q5o006174@stowe.cs.dartmouth.edu> References: <201406020209.s5229Q5o006174@stowe.cs.dartmouth.edu> Message-ID: <00668C2D-BF21-44EA-A7D8-A9530CA24551@bsdimp.com> On Jun 1, 2014, at 8:09 PM, Doug McIlroy wrote: > Phil Garcia wrote: > I've always wondered about something > else, though: Were the original Unix authors annoyed when they learned that > some irascible young upstart named Richard Stallman was determined to make > a free Unix clone? Was he a gadfly, or just some kook you decided to > ignore? The fathers of Unix have been strangely silent on this topic for > many years. Maybe nobody's ever asked? In private moments, some of the BSD old-timers have told me they are silent due to bad blood that Stallman’s early fund-raising and propaganda efforts created. Why rehash 20 year old battles with an obvious nutcase, eh? Since more than one person has told me this, so I think silence is a wide-spread case of “If you can’t say anything nice, say nothing at all." > Gnu was always taken as a compliment. And of course the Unix clone > was pie in the sky until Linus came along. I wonder about the power > relationship underlying "GNU/Linux", as rms modestly styles it. Of course, it should be noted that the GNU project was totally incapable of producing a working kernel… They did decent clones of user land stuff, but Hurd was a total dead end... > There are certain differences in taste between Unix and Gnu, vide > emacs and texinfo. (I grit my teeth every time a man page tells me, > "The full documentation for ___ is maintained as a Texinfo file.") > But all disagreement is swept away before the fact that the old > familiar environment is everywhere, from Cray to Apple, with rms > a very important contributor. Emacs is awesome…. Warner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: From jnc at mercury.lcs.mit.edu Mon Jun 2 13:18:07 2014 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Sun, 1 Jun 2014 23:18:07 -0400 (EDT) Subject: [TUHS] Bugs in V6 'dcheck' Message-ID: <20140602031807.8B4DC18C0AD@mercury.lcs.mit.edu> > From: "Ron Natalie" > The variable in question was a global static, 'ino' (the current inode > number), > Static is a much overloaded word in C, it's just a global variable. Sorry; I was using 'static' in the general CS sense, not C-specific! > in the version 7 version of icheck .. they appear to have fixed it. Actually, they seem to have got all three bugs I saw (including the one I hadn't actually experienced yet, which would cause a segmentation violation). > From: Tim Newsham > There are bugs to be found .. Here are some more (security related, as > thats my inclination): > ... > http://minnie.tuhs.org/pipermail/unix-jun72/2008-May/000126.html Fascinating mailing list! Thanks for the pointer. Noel From cowan at mercury.ccil.org Mon Jun 2 13:18:13 2014 From: cowan at mercury.ccil.org (John Cowan) Date: Sun, 1 Jun 2014 23:18:13 -0400 Subject: [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck') In-Reply-To: <00668C2D-BF21-44EA-A7D8-A9530CA24551@bsdimp.com> References: <201406020209.s5229Q5o006174@stowe.cs.dartmouth.edu> <00668C2D-BF21-44EA-A7D8-A9530CA24551@bsdimp.com> Message-ID: <20140602031813.GF18282@mercury.ccil.org> Warner Losh scripsit: > “If you can’t say anything nice, say nothing at all." And a Good Thing Too. Public squabbling about trivia serves no one's interest except the enemies'. > They did decent clones of user land stuff, Much less buggy and more Posix-compliant, I think you mean. (The .sig below was chosen at random and in advance, but it's fitting.) -- John Cowan http://www.ccil.org/~cowan cowan at ccil.org We are lost, lost. No name, no business, no Precious, nothing. Only empty. Only hungry: yes, we are hungry. A few little fishes, nassty bony little fishes, for a poor creature, and they say death. So wise they are; so just, so very just. --Gollum From grog at lemis.com Mon Jun 2 13:17:15 2014 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Mon, 2 Jun 2014 13:17:15 +1000 Subject: [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck') In-Reply-To: <00668C2D-BF21-44EA-A7D8-A9530CA24551@bsdimp.com> References: <201406020209.s5229Q5o006174@stowe.cs.dartmouth.edu> <00668C2D-BF21-44EA-A7D8-A9530CA24551@bsdimp.com> Message-ID: <20140602031715.GA27136@eureka.lemis.com> On Sunday, 1 June 2014 at 20:59:13 -0600, Warner Losh wrote: > > On Jun 1, 2014, at 8:09 PM, Doug McIlroy wrote: > >> Phil Garcia wrote: >> I've always wondered about something >> else, though: Were the original Unix authors annoyed when they learned that >> some irascible young upstart named Richard Stallman was determined to make >> a free Unix clone? Was he a gadfly, or just some kook you decided to >> ignore? The fathers of Unix have been strangely silent on this topic for >> many years. Maybe nobody's ever asked? > > In private moments, some of the BSD old-timers have told me they are > silent due to bad blood that Stallman?s early fund-raising and > propaganda efforts created. Why rehash 20 year old battles with an > obvious nutcase, eh? Since more than one person has told me this, so > I think silence is a wide-spread case of ?If you can?t say anything > nice, say nothing at all." But now you've said something, and it's not nice. Clearly this is indicative of the standpoints of the others as well. A lot is simply personality conflict. As you know, I don't share that opinion, and I think the emphasis that FreeBSD places on ridding itself of GNU software is unhealthy. Yes, rms is "unusual", but that goes for a lot of the BSD crowd too. And I know enough people in the Linux space who dislike him as well. >> Gnu was always taken as a compliment. And of course the Unix clone >> was pie in the sky until Linus came along. I wonder about the power >> relationship underlying "GNU/Linux", as rms modestly styles it. > > Of course, it should be noted that the GNU project was totally > incapable of producing a working kernel? They did decent clones of > user land stuff, but Hurd was a total dead end... But if you state that, you need to analyse why. I think the big issue was the grandiose goals that they set. And who knows what might have happened if Linux and the free BSDs hadn't come along? I don't think it's fair to simply dismiss it as a dead end. >> There are certain differences in taste between Unix and Gnu, vide >> emacs and texinfo... > > Emacs is awesome?. Not part of my vocabulary, but I couldn't live without Emacs. Shall we degrade this discussion into a vi/Emacs fight? Greg -- Sent from my desktop computer. Finger grog at FreeBSD.org for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft MUA reports problems, please read http://tinyurl.com/broken-mua -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available URL: From jnc at mercury.lcs.mit.edu Mon Jun 2 13:34:05 2014 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Sun, 1 Jun 2014 23:34:05 -0400 (EDT) Subject: [TUHS] Bugs in V6 'dcheck' Message-ID: <20140602033405.E0EA818C0AD@mercury.lcs.mit.edu> > From: norman at oclsc.org (Norman Wilson) > SP&E published a paper by Don Knuth discussing all the many bugs found > in TeX, including some statistical analysis. > From: John Cowan > "The Errors of TeX" was an excellent article. Thanks for the pointer; it sounds like a great paper, but alas the only copies I could fine online were behind paywalls. > From: Clem Cole > btw. there is a v6 version of fsck floating around. Yes, we had it at MIT. > I'm wonder if I can find a readable copy. As I've mentioned, I have this goal of putting the MIT Unix (the kernel was basically PWB1, with a host of new applications) sources online. I have recently discovered (in my basement!) two sets of full dump tapes (1/2" magtape) of what I think are the whole filesystem, so if I can find a way to get them read, we'll have the V6 fsck - and much more besides (such as a TCP/IP for V6). So I think you may soon get your wish! Noel From cowan at mercury.ccil.org Mon Jun 2 13:37:46 2014 From: cowan at mercury.ccil.org (John Cowan) Date: Sun, 1 Jun 2014 23:37:46 -0400 Subject: [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck') In-Reply-To: <20140602031715.GA27136@eureka.lemis.com> References: <201406020209.s5229Q5o006174@stowe.cs.dartmouth.edu> <00668C2D-BF21-44EA-A7D8-A9530CA24551@bsdimp.com> <20140602031715.GA27136@eureka.lemis.com> Message-ID: <20140602033746.GG18282@mercury.ccil.org> Greg 'groggy' Lehey scripsit: > Not part of my vocabulary, but I couldn't live without Emacs. Shall > we degrade this discussion into a vi/Emacs fight? Sure, go ahead. As a firm adherent to "ex", I'll umpire the contest. -- "Well, I'm back." --Sam John Cowan From downing.nick at gmail.com Mon Jun 2 14:04:43 2014 From: downing.nick at gmail.com (Nick Downing) Date: Mon, 2 Jun 2014 14:04:43 +1000 Subject: [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck') In-Reply-To: <20140602031715.GA27136@eureka.lemis.com> References: <201406020209.s5229Q5o006174@stowe.cs.dartmouth.edu> <00668C2D-BF21-44EA-A7D8-A9530CA24551@bsdimp.com> <20140602031715.GA27136@eureka.lemis.com> Message-ID: Yeah. I think Richard Stallman is a legend (umm if that's too close to "awesome" vocabulary wise then let's say he's an inspiration :) :) ), I totally agree with everything he's done for & on behalf of free software and really it's easy to forget how totally locked out of the unix world I was as a 10yr old MS Basic programming hobbyist or 20yr old MS Basic programming developer, never even used an SCCS until I was nearly 30. My professional life would have been way more productive and satisfying if Stallman had come along much earlier... I knew people who used unix and packet-switched networks such as X.25 but being run for profit by large corporations it was totally out of my price range. I also remember how much I just yearned to have the source code of MS DOS, CP/M, AppleSoft & DOS 3.3, etc, so many unanswered questions that were only partially alleviated by books such as "Undocumented DOS" and "Beneath Apple DOS"... I did eventually get some of those sources or a version of them when it was much too late & was disappointed to see how mediocre they looked from developer's viewpoint... community could have dome much better but were locked out of the process & relegated to writing apps & device drivers that took ages to get working in light of limited technical info. I'll never be in that situation again thanks to Stallman's insights and Torvalds's and everyone else's contribution. I deplore the infighting though and have had bad experiences in trying to offer what little time I could afford to open source projects, now I do not really bother & just use the tools with my own private modifications. I do think Stallman has a point about naming of Linux v. GNU/Linux though. What I do not like about GNU is the "kitchen sink" philosophy of including every little used feature in every utility with longer and longer command line switches and manpages. Bash I guess is an extreme example of this, we do not need a commandline shell that is 1Mb in size!! Another issue I have is the incredibly complex tools such as GCC being written in plain C when some subset of C++ would clearly be more appropriate given their fundamentally object oriented design. This is very laborious, repetitive and wasteful and involves a lot of differing "private solutions" to already-solved problems. Further the build systems are totally broken, I appreciate what automake/autoconf is doing but from a developer point of view they are totally unwieldy and another example of the "kitchen sink" philosophy of supporting every conceivable, and outdated, architecture. Much better solutions exist for these kinds of problems. For these reasons I would likely not work on a GNU project, however I use the tools daily and simply ignore the parts I don't like. If software development were left to me I would be infinitely subroutinized, redesigning the CPU so I could redesign the ISA and then return to redesigning the compiler followed by the OS kernel followed by the C library, the windowing system and the apps hehehe so RMS perceived a need and filled it within a useful timescale and I'm infinitely grateful :) cheers, Nick On 02/06/2014 1:26 PM, "Greg 'groggy' Lehey" wrote: > On Sunday, 1 June 2014 at 20:59:13 -0600, Warner Losh wrote: > > > > On Jun 1, 2014, at 8:09 PM, Doug McIlroy wrote: > > > >> Phil Garcia wrote: > >> I've always wondered about something > >> else, though: Were the original Unix authors annoyed when they learned > that > >> some irascible young upstart named Richard Stallman was determined to > make > >> a free Unix clone? Was he a gadfly, or just some kook you decided to > >> ignore? The fathers of Unix have been strangely silent on this topic for > >> many years. Maybe nobody's ever asked? > > > > In private moments, some of the BSD old-timers have told me they are > > silent due to bad blood that Stallman?s early fund-raising and > > propaganda efforts created. Why rehash 20 year old battles with an > > obvious nutcase, eh? Since more than one person has told me this, so > > I think silence is a wide-spread case of ?If you can?t say anything > > nice, say nothing at all." > > But now you've said something, and it's not nice. > > Clearly this is indicative of the standpoints of the others as well. > A lot is simply personality conflict. As you know, I don't share that > opinion, and I think the emphasis that FreeBSD places on ridding > itself of GNU software is unhealthy. Yes, rms is "unusual", but that > goes for a lot of the BSD crowd too. And I know enough people in the > Linux space who dislike him as well. > > >> Gnu was always taken as a compliment. And of course the Unix clone > >> was pie in the sky until Linus came along. I wonder about the power > >> relationship underlying "GNU/Linux", as rms modestly styles it. > > > > Of course, it should be noted that the GNU project was totally > > incapable of producing a working kernel? They did decent clones of > > user land stuff, but Hurd was a total dead end... > > But if you state that, you need to analyse why. I think the big issue > was the grandiose goals that they set. And who knows what might have > happened if Linux and the free BSDs hadn't come along? I don't think > it's fair to simply dismiss it as a dead end. > > >> There are certain differences in taste between Unix and Gnu, vide > >> emacs and texinfo... > > > > Emacs is awesome?. > > Not part of my vocabulary, but I couldn't live without Emacs. Shall > we degrade this discussion into a vi/Emacs fight? > > Greg > -- > Sent from my desktop computer. > Finger grog at FreeBSD.org for PGP public key. > See complete headers for address and phone numbers. > This message is digitally signed. If your Microsoft MUA reports > problems, please read http://tinyurl.com/broken-mua > > _______________________________________________ > TUHS mailing list > TUHS at minnie.tuhs.org > https://minnie.tuhs.org/mailman/listinfo/tuhs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From scj at yaccman.com Mon Jun 2 14:08:20 2014 From: scj at yaccman.com (scj at yaccman.com) Date: Sun, 1 Jun 2014 21:08:20 -0700 Subject: [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck') In-Reply-To: <20140602033746.GG18282@mercury.ccil.org> References: <201406020209.s5229Q5o006174@stowe.cs.dartmouth.edu> <00668C2D-BF21-44EA-A7D8-A9530CA24551@bsdimp.com> <20140602031715.GA27136@eureka.lemis.com> <20140602033746.GG18282@mercury.ccil.org> Message-ID: <8ddc2a2d9aeea13a5bc6f98903380f62.squirrel@webmail.yaccman.com> Three comments on Gnu/Unix. The first is that the Unix creators were very ambivalent about the AT&T Lawyers. The legal situation surrounding AT&T licensing software was murky, and the lawyers attitude was often "let's wait 10 years and see what happens in case law...". I spent about six months trying to get the PCC C grammar released to the public domain, with the notion that this would help limit the splintering of the language that was starting to happen pre ANSI C. I couldn't get anywhere with that. The second comment is that, for me personally, the ripping off bothered me less than the complete lack of attribution of the original creators. There were easily two dozen people who contributed some significant code and/or ideas to Unix, but you'd never know it by looking at Gnu. The third comment is that the loss of central control has had its costs. I get a rash looking at the 500-page gcc manual, orders of magnitude larger than the code for pcc. It's hard to steer a sensible course between stagnated central control and chaotic anarchy, but for my taste letting every grad student with a couple of hours of spare time piddle on the code base has not, on the whole, been a good thing.] Steve From cowan at mercury.ccil.org Mon Jun 2 14:43:48 2014 From: cowan at mercury.ccil.org (John Cowan) Date: Mon, 2 Jun 2014 00:43:48 -0400 Subject: [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck') In-Reply-To: References: <201406020209.s5229Q5o006174@stowe.cs.dartmouth.edu> <00668C2D-BF21-44EA-A7D8-A9530CA24551@bsdimp.com> <20140602031715.GA27136@eureka.lemis.com> Message-ID: <20140602044348.GJ18282@mercury.ccil.org> Nick Downing scripsit: > Bash I guess is an extreme example of this, we do not need a commandline > shell that is 1Mb in size!! Well, some people find it useful. But if you want dash or Unix rc, you know where to find them. > Further the build systems are totally broken, I > appreciate what automake/autoconf is doing but from a developer point of > view they are totally unwieldy and another example of the "kitchen sink" > philosophy of supporting every conceivable, and outdated, architecture. Indeed. I rather like the Chicken Scheme approach: there is a Makefile fragment for each supported architecture, currently BSD, Solaris, Android, AIX, Haiku, iOS, MinGW with or without MSYS, Cygwin, Hurd, MacOSX, and Linux. If you want anything else, provide your own Makefile fragment. -- John Cowan http://www.ccil.org/~cowan cowan at ccil.org Eric Raymond is the Margaret Mead of the Open Source movement. --Bruce Perens, a long time ago From grog at lemis.com Mon Jun 2 15:03:18 2014 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Mon, 2 Jun 2014 15:03:18 +1000 Subject: [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck') In-Reply-To: <20140602033746.GG18282@mercury.ccil.org> References: <201406020209.s5229Q5o006174@stowe.cs.dartmouth.edu> <00668C2D-BF21-44EA-A7D8-A9530CA24551@bsdimp.com> <20140602031715.GA27136@eureka.lemis.com> <20140602033746.GG18282@mercury.ccil.org> Message-ID: <20140602050317.GB27136@eureka.lemis.com> On Sunday, 1 June 2014 at 23:37:46 -0400, John Cowan wrote: > Greg 'groggy' Lehey scripsit: > >> Not part of my vocabulary, but I couldn't live without Emacs. Shall >> we degrade this discussion into a vi/Emacs fight? > > Sure, go ahead. As a firm adherent to "ex", I'll umpire the > contest. :-) Greg -- Sent from my desktop computer. Finger grog at FreeBSD.org for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft MUA reports problems, please read http://tinyurl.com/broken-mua -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available URL: From mah at mhorton.net Mon Jun 2 14:05:43 2014 From: mah at mhorton.net (Mary Ann Horton) Date: Sun, 01 Jun 2014 21:05:43 -0700 Subject: [TUHS] Bugs in V6 'dcheck' In-Reply-To: <20140602033405.E0EA818C0AD@mercury.lcs.mit.edu> References: <20140602033405.E0EA818C0AD@mercury.lcs.mit.edu> Message-ID: <538BF817.9070604@mhorton.net> I would also love to find a way to read 9 track tapes back in. Everyone has ditched the hardware. I have several 4BSD and System V tapes as well as personal tapes I'd love to read in. (Anyone remember IBM "picture tapes"?) On 06/01/2014 08:34 PM, Noel Chiappa wrote: > > From: norman at oclsc.org (Norman Wilson) > > > SP&E published a paper by Don Knuth discussing all the many bugs found > > in TeX, including some statistical analysis. > > > From: John Cowan > > > "The Errors of TeX" was an excellent article. > > Thanks for the pointer; it sounds like a great paper, but alas the only > copies I could fine online were behind paywalls. > > > > From: Clem Cole > > > btw. there is a v6 version of fsck floating around. > > Yes, we had it at MIT. > > > I'm wonder if I can find a readable copy. > > As I've mentioned, I have this goal of putting the MIT Unix (the kernel was > basically PWB1, with a host of new applications) sources online. > > I have recently discovered (in my basement!) two sets of full dump tapes > (1/2" magtape) of what I think are the whole filesystem, so if I can find a > way to get them read, we'll have the V6 fsck - and much more besides (such > as a TCP/IP for V6). So I think you may soon get your wish! > > Noel > _______________________________________________ > TUHS mailing list > TUHS at minnie.tuhs.org > https://minnie.tuhs.org/mailman/listinfo/tuhs From usotsuki at buric.co Mon Jun 2 16:08:19 2014 From: usotsuki at buric.co (Steve Nickolas) Date: Mon, 2 Jun 2014 06:08:19 +0000 (UTC) Subject: [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck') In-Reply-To: <00668C2D-BF21-44EA-A7D8-A9530CA24551@bsdimp.com> References: <201406020209.s5229Q5o006174@stowe.cs.dartmouth.edu> <00668C2D-BF21-44EA-A7D8-A9530CA24551@bsdimp.com> Message-ID: On Sun, 1 Jun 2014, Warner Losh wrote: > Of course, it should be noted that the GNU project was totally incapable > of producing a working kernel… They did decent clones of user land stuff, > but Hurd was a total dead end... The HURD isn't even a joke, it's just a punch line... That said, to me with the userland, BSD gets it right, and GNU is a joke - slow and bloated. You know how Microsoft is known for "embrace, extend and exterminate" ? GNU does the same damn thing. From arnold at skeeve.com Mon Jun 2 16:23:38 2014 From: arnold at skeeve.com (arnold at skeeve.com) Date: Mon, 02 Jun 2014 00:23:38 -0600 Subject: [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck') In-Reply-To: <20140602044348.GJ18282@mercury.ccil.org> References: <201406020209.s5229Q5o006174@stowe.cs.dartmouth.edu> <00668C2D-BF21-44EA-A7D8-A9530CA24551@bsdimp.com> <20140602031715.GA27136@eureka.lemis.com> <20140602044348.GJ18282@mercury.ccil.org> Message-ID: <201406020623.s526Nctu017760@freefriends.org> John Cowan wrote: > Indeed. I rather like the Chicken Scheme approach: there is a Makefile > fragment for each supported architecture, currently BSD, Solaris, Android, > AIX, Haiku, iOS, MinGW with or without MSYS, Cygwin, Hurd, MacOSX, > and Linux. If you want anything else, provide your own Makefile fragment. This is only possible because of the standardization efforts at the C and POSIX levels. Remember that Autoconf/Automake were invented to solve the issue of all the forks: SunOS / Solaris / HP-UX / Ultrix / MIPS / Pryamid / DG-UX / ad nauseum. Lots of things that were almost but not quite entirely like V7 or System V Unix. Today many of those players are no longer around, AND standardization of header files and libraries means that C code is *more* portable than it was in 1992. So there's less need for those tools *now*, but that doesn't mean they didn't solve a real problem when they first came along. I'll agree on most of the GNU complaints (and I'm a GNU developer...); the original Unix "Small Is Beautiful" baby has been thrown out along with the proprietary licensing bath water. Sigh. (Boy, was that a great use for an old cliche, or what? :-) Thanks, Arnold From arnold at skeeve.com Mon Jun 2 16:12:46 2014 From: arnold at skeeve.com (arnold at skeeve.com) Date: Mon, 02 Jun 2014 00:12:46 -0600 Subject: [TUHS] Bugs in V6 'dcheck' In-Reply-To: <20140602033405.E0EA818C0AD@mercury.lcs.mit.edu> References: <20140602033405.E0EA818C0AD@mercury.lcs.mit.edu> Message-ID: <201406020612.s526CkYO017517@freefriends.org> > > "The Errors of TeX" was an excellent article. > > Thanks for the pointer; it sounds like a great paper, but alas the only > copies I could fine online were behind paywalls. IIRC it's reproduced in Knuth's book "Literate programming" which is well worth ownding and reading. A soft copy might actually come with TeX itself. Arnold From clemc at ccc.com Mon Jun 2 22:04:37 2014 From: clemc at ccc.com (Clem Cole) Date: Mon, 2 Jun 2014 08:04:37 -0400 Subject: [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck') In-Reply-To: <201406020209.s5229Q5o006174@stowe.cs.dartmouth.edu> References: <201406020209.s5229Q5o006174@stowe.cs.dartmouth.edu> Message-ID: On Sun, Jun 1, 2014 at 10:09 PM, Doug McIlroy wrote: > Gnu was always taken as a compliment. And of course the Unix clone > was pie in the sky until Linus came along. > ​Actually I would say the real contribution was not emacs or the getting the user space code rewritten, but gcc. While compared to many commercial compilers it ​has never been the "the best" but is seems like its always "up there" when compared and in fact I find it a "better" compiler than some of the commercial ones in the embedded space. rms's gift was getting a "production quality" compiler in the everyone's hands that was portable "enough" that it was basically OS independent. As for UNIX clones, Doug, I would sort of differ with you on that. There were numerous "clones" and rewrites from Plauger's Irdis efforts to Andy's Minux if you want to discount the slow rewrite from the inside out of BSD. I content, what really made Linux happen was the ill fated AT&T vs BSDi/UCB case -- a lot of people (myself included) miss understood and were worried BSD would have to go away. I would later be educated in realize, if AT&T had won all of the UNIX "clones" would have had to go away in the west/Nato countries. And frankly, I'm not sure it would have survived that. I agree with you about being annoyed with the words ""The full documentation for ___ is maintained as a Texinfo file" but I find a number of things in Linux that make me just as annoyed. It seems like there are a lot of changes because they could, not be cause it really mattered. But then I remember that as you point out, it runs on everything and that does make me smile and does make life so much easier for all of us. Clem -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron at ronnatalie.com Mon Jun 2 22:27:14 2014 From: ron at ronnatalie.com (Ronald Natalie) Date: Mon, 2 Jun 2014 08:27:14 -0400 Subject: [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck') In-Reply-To: References: <201406020209.s5229Q5o006174@stowe.cs.dartmouth.edu> Message-ID: Well PCC wasn't bad (we used it to build the compilers for the HEP Supercomputer), but you are correct GCC was reasonably good. In addition to Idris mentioned, there was also Mark Williams's Coherent. The bigger issues with these "clones" and the legitimate Unices like XENIX, IS/1, etc... were that the PC platform wasn't quite there yet. Still with all it's flaws, on the 286 and later UNIX actually did run in protected mode, something it took ages for DOS/Windows (one can argue backwards compatibility with the early processors) or Apple (no excuse here, the early Macs were 68000's which had protection) to pick up upon. Wasn't just us in academia who were concerned. Spent an evening sitting in the hallway of some dormitory (UDel?) with Dennis Mumaugh from the NSA discussing security holes we'd fixed. Carping about obscure bugs in Version 6 is sort of silly (as I stated, they were even fixed as of V7) and frankly, software security / reliability was a different world back then. We had less of a time with our TOPS-10 system only because we didn't give students so much free rain on the accounts (compared to the UNIX system which you just had to ask pretty much) but I still remember crashing the EXEC-8 system at UofM with a corrupted file I kept around. Of course there were always hardware bugs to deal with. There were some on the PDP-11 and even on the 386 (when I was working with AIX ...really the UCLA Locus version of UNIX) there was disgusting hacks that doiubled up the paging protection with the old segment-offset stuff because of a security bug there. From ron at ronnatalie.com Mon Jun 2 22:31:34 2014 From: ron at ronnatalie.com (Ronald Natalie) Date: Mon, 2 Jun 2014 08:31:34 -0400 Subject: [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck') In-Reply-To: <20140602050317.GB27136@eureka.lemis.com> References: <201406020209.s5229Q5o006174@stowe.cs.dartmouth.edu> <00668C2D-BF21-44EA-A7D8-A9530CA24551@bsdimp.com> <20140602031715.GA27136@eureka.lemis.com> <20140602033746.GG18282@mercury.ccil.org> <20140602050317.GB27136@eureka.lemis.com> Message-ID: Amusingly I never learned VI. I had worked for a group that was beholden to Interactive Systems editor (which I believe was a variant of Yost's Rand Editor) and by the time I left there I was working with various pre-GNU Unix EMACS (Warren Montgomery, JOVE, Gosling). I even worked for Unipress for a very short period as a consultant. To this day if there's no EMACS I juse use ed or ex. It always amazed my coworkers how fast I fly in line editor mode. On Jun 2, 2014, at 1:03 AM, Greg 'groggy' Lehey wrote: >> >> >>> Not part of my vocabulary, but I couldn't live without Emacs. Shall >>> we degrade this discussion into a vi/Emacs fight? >> >> Sure, go ahead. As a firm adherent to "ex", I'll umpire the >> contest. > > : From clemc at ccc.com Mon Jun 2 23:28:58 2014 From: clemc at ccc.com (Clem Cole) Date: Mon, 2 Jun 2014 09:28:58 -0400 Subject: [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck') In-Reply-To: References: <201406020209.s5229Q5o006174@stowe.cs.dartmouth.edu> Message-ID: On Mon, Jun 2, 2014 at 8:27 AM, Ronald Natalie wrote: > Well PCC wasn't bad (we used it to build the compilers for the HEP > Supercomputer), but you are correct GCC was reasonably good. ​Ron you are right.. A number of us used dmr's compiler much less Steve's compiler to "port UNIX" to a lot of different things (some where good and some not so good - my own attempt at retargeting the V7 Rtichie compiler to yet to be name processed experimental process from Moto (later called the 68000) proved "good enough" for the Magnolia project at Tek but it was not really not a very good compiler). But you had to have an AT&T license to get it. Admittedly a lot of universities did and that did certainly cause C to get a huge foot hold over its contemporaries (say BCPL, BLISS and maybe PL/360). IMHO: what rms did was put a production quality compiler into play that had sources, that anyone could use and anyone could hack on without having to purchase it or need some sort of license other than his GPL. At the time, there had been lots of attempts at different compilers both "free" and commercial - some with sources some not (I fondly remember Ron Cain's Small C for the 8080 being pushed in Byte Magazine the late 1970s/early 1980)​. Even Whitesmith's (Plauger's) compiler was really not what would we have called production code quality. gcc was not (still is not) perfect and compared to a number of commercial compilers -- say something like the current Intel compiler or the old DEC, Masscomp or Sun compilers. But the "gcc family" did prove to be fairly easy move to a lot of UNIX/UNIX-like and non-UNIX OS platforms, at the same time able to be retarget to a number of different ISAs, even a number of different front ends; all while generally creating good/reasonable if not darned good/close to optimal code (at least for many of the targets were the most popular/that mattered). Frankly, we have seen few developer suites that have been as lasting and I might suggest that until the LLVM project there has been few (none) that have had a chance of being so [Tannebaum's compiler kit maybe - but I never same that it never really went anywhere]. My observation is that without a "pretty good" compiler that was reasonably "universal" the rest of the command suite would have languished/not happened. As Doug points out the base OS really never happened from rms (they had Trix, then the Hurd and finally defaulted to Linux). But the command suite was able to grow and lots of people besides rms contribute to it, because the basic development tools were there. As strange and difficult a person he is, I suspect we do all own rms a certain level of thanks for the basic dev tools. Clem -------------- next part -------------- An HTML attachment was scrubbed... URL: From tfb at tfeb.org Tue Jun 3 00:11:45 2014 From: tfb at tfeb.org (Tim Bradshaw) Date: Mon, 2 Jun 2014 15:11:45 +0100 Subject: [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck') In-Reply-To: References: <201406020209.s5229Q5o006174@stowe.cs.dartmouth.edu> Message-ID: <59D01DBF-EF49-45B8-8F80-FA03E644A528@tfeb.org> On 2 Jun 2014, at 14:28, Clem Cole wrote: > [About gcc] > But the command suite was able to grow and lots of people besides rms contribute to it, because the basic development tools were there. As strange and difficult a person he is, I suspect we do all own rms a certain level of thanks for the basic dev tools. In particular I think the existence of GCC was critical to the existence of Linux: there is some complicated history involving a GCC port to ?Minix?, which I think was done because Minix's compiler was rudimentary, and that port enabling some Finnish guy (using Minix I guess) to bring up a kernel. I suspect there are people on this list who remember this better than I do though. --tim -------------- next part -------------- An HTML attachment was scrubbed... URL: From cowan at mercury.ccil.org Tue Jun 3 00:24:48 2014 From: cowan at mercury.ccil.org (John Cowan) Date: Mon, 2 Jun 2014 10:24:48 -0400 Subject: [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck') In-Reply-To: References: <201406020209.s5229Q5o006174@stowe.cs.dartmouth.edu> Message-ID: <20140602142446.GM18282@mercury.ccil.org> Ronald Natalie scripsit: > Still with all it's flaws, on the 286 and later UNIX actually did run in > protected mode, something it took ages for DOS/Windows (one can argue > backwards compatibility with the early processors) or Apple (no excuse > here, the early Macs were 68000's which had protection) to pick up upon. The original Mac 128K was a 68000 processor, and IIRC memory protection didn't arrive until the 68020. -- John Cowan http://www.ccil.org/~cowan cowan at ccil.org 'Tis the Linux rebellion / Let coders take their place, The Linux-nationale / Shall Microsoft outpace, We can write better programs / Our CPUs won't stall, So raise the penguin banner of / The Linux-nationale. --Greg Baker From clemc at ccc.com Tue Jun 3 00:25:58 2014 From: clemc at ccc.com (Clem Cole) Date: Mon, 2 Jun 2014 10:25:58 -0400 Subject: [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck') In-Reply-To: <59D01DBF-EF49-45B8-8F80-FA03E644A528@tfeb.org> References: <201406020209.s5229Q5o006174@stowe.cs.dartmouth.edu> <59D01DBF-EF49-45B8-8F80-FA03E644A528@tfeb.org> Message-ID: Tim - cart and horse reversed.. ;-) Linus did not like the fact the when Andy wrote Minux, he and his students did not use the 386 MMU HW. It was made to run on a 8086/8088 -- straight PC/XT because Andy wanted the lowest cost of entry for his students. Also at the time, Andy's compiler tool kit was not as easy to get the source. My memory on this part is hazy, but I think you had to purchase the compiler sources. So Linus started with MINUX and started to add more and more support. He eventually tossed out the ukernel nature of Minux and went the more traditional kernel architecture. He and Andy would famously fight about that choice on usenet. Linus this would eventually need a compiler and pulled rms' suite. The funny part is that his University has 386BSD (aka 4.2 for the 386) at the time which did use the MMU, had networking and even the first step at X11. At the time I had helped the guys get the AT disk driver working as I had access to all the Western Digital documentation. But to get the code from CRSG, you needed at BSD license, which required an AT&T license. Linus' university had one, but he did know know the magic ftp site to download or have access. I've often wondered what would have happened if he had known about it. And again, fast forward about 18-24 months and folks like me were worried when the BSDi case came out that we were going to lose access to a UNIX for the Intel processor. So we started to help him, even though at the time is a huge step backwards. Clearly, the "powers" at AT&T really did not know they were awaking a sleeping animal in the hacker community. Clem On Mon, Jun 2, 2014 at 10:11 AM, Tim Bradshaw wrote: > > On 2 Jun 2014, at 14:28, Clem Cole wrote: > > [About gcc] > > But the command suite was able to grow and lots of people besides rms > contribute to it, because the basic development tools were there. As > strange and difficult a person he is, I suspect we do all own rms a certain > level of thanks for the basic dev tools. > > > In particular I think the existence of GCC was critical to the existence > of Linux: there is some complicated history involving a GCC port to > ?Minix?, which I think was done because Minix's compiler was rudimentary, > and that port enabling some Finnish guy (using Minix I guess) to bring up a > kernel. I suspect there are people on this list who remember this better > than I do though. > > --tim > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnold at skeeve.com Tue Jun 3 00:26:57 2014 From: arnold at skeeve.com (arnold at skeeve.com) Date: Mon, 02 Jun 2014 08:26:57 -0600 Subject: [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck') In-Reply-To: <59D01DBF-EF49-45B8-8F80-FA03E644A528@tfeb.org> References: <201406020209.s5229Q5o006174@stowe.cs.dartmouth.edu> <59D01DBF-EF49-45B8-8F80-FA03E644A528@tfeb.org> Message-ID: <201406021426.s52EQvxp007291@freefriends.org> Tim Bradshaw wrote: > > In particular I think the existence of GCC was critical to the existence > of Linux: Linus himself has said as much. I can't find the quote, but I'm pretty sure he acknowledges that. Arnold From ron at ronnatalie.com Tue Jun 3 00:29:30 2014 From: ron at ronnatalie.com (Ronald Natalie) Date: Mon, 2 Jun 2014 10:29:30 -0400 Subject: [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck') In-Reply-To: <20140602142446.GM18282@mercury.ccil.org> References: <201406020209.s5229Q5o006174@stowe.cs.dartmouth.edu> <20140602142446.GM18282@mercury.ccil.org> Message-ID: <7DC97BD4-337C-4E32-9EA3-AA485923AC97@ronnatalie.com> On Jun 2, 2014, at 10:24 AM, John Cowan wrote: > Ronald Natalie scripsit: > >> Still with all it's flaws, on the 286 and later UNIX actually did run in >> protected mode, something it took ages for DOS/Windows (one can argue >> backwards compatibility with the early processors) or Apple (no excuse >> here, the early Macs were 68000's which had protection) to pick up upon. > > The original Mac 128K was a 68000 processor, and IIRC memory protection > didn't arrive until the 68020. > > -- Yeah, you're right. You could get it off-chip with the -010 or it was integrated with the -020. From cowan at mercury.ccil.org Tue Jun 3 00:30:20 2014 From: cowan at mercury.ccil.org (John Cowan) Date: Mon, 2 Jun 2014 10:30:20 -0400 Subject: [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck') In-Reply-To: References: <201406020209.s5229Q5o006174@stowe.cs.dartmouth.edu> Message-ID: <20140602143020.GN18282@mercury.ccil.org> Clem Cole scripsit: > Frankly, we have seen few developer suites that have been as lasting and I > might suggest that until the LLVM project there has been few (none) that > have had a chance of being so [Tannebaum's compiler kit maybe - but I never > same that it never really went anywhere]. "The university is free but the compiler is not", as Tanenbaum said to RMS. However, eventually he caught up, and it was BSD-licensed in 2003. -- John Cowan http://www.ccil.org/~cowan cowan at ccil.org Heckler: "Go on, Al, tell 'em all you know. It won't take long." Al Smith: "I'll tell 'em all we *both* know. It won't take any longer." From clemc at ccc.com Tue Jun 3 00:37:52 2014 From: clemc at ccc.com (Clem Cole) Date: Mon, 2 Jun 2014 10:37:52 -0400 Subject: [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck') In-Reply-To: <20140602142446.GM18282@mercury.ccil.org> References: <201406020209.s5229Q5o006174@stowe.cs.dartmouth.edu> <20140602142446.GM18282@mercury.ccil.org> Message-ID: On Mon, Jun 2, 2014 at 10:24 AM, John Cowan wrote: > The original Mac 128K was a 68000 processor, and IIRC memory protection > didn't arrive until the 68020. > ​Sort of. Did not arrive to >>Apple<< until the '020 based Mac-II. Les Crudele (one the 68k's designers) tells a great story about this. The original device had a PDP-11 base/limit register MMU as an external chip who's number I forget (and could not do demand paging by itself -- Masscomp and Apollo would use 2 of them and build their own MMU). According to Les, Moto offered to give Apple the MMU chip at a substantial discount (maybe even free) if they would use it for the Mac. But Jobs famously said it was a personal computer and did not need it (remember the Alto's did not have an MMU either). Later, Moto would release the '010 ​which could do demanding paging with help of an external MMU. The Stanford University Network Terminal (aka "SUN" board) could use the '10. I don't think Apple did themselves, but my memory is that the was an after market '010 mod for some of the Macs. At Masscomp, we retrofited the original CPU board to take a '010. In this mode, the 'fixer' 68K and the '010 could run in parallel during a page fault, which was slightly faster. But functionally, to the end user it was the same as two 68K's. I'm not sure if Apollo did a retrofit. Clem -------------- next part -------------- An HTML attachment was scrubbed... URL: From cowan at mercury.ccil.org Tue Jun 3 00:41:05 2014 From: cowan at mercury.ccil.org (John Cowan) Date: Mon, 2 Jun 2014 10:41:05 -0400 Subject: [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck') In-Reply-To: References: <201406020209.s5229Q5o006174@stowe.cs.dartmouth.edu> <59D01DBF-EF49-45B8-8F80-FA03E644A528@tfeb.org> Message-ID: <20140602144105.GO18282@mercury.ccil.org> Clem Cole scripsit: > I've often wondered what would have happened if he had known about it. Linus is on record as saying that if either the Hurd or the 386BSD system had been available to him, he would never have written the Linux kernel. -- John Cowan http://www.ccil.org/~cowan cowan at ccil.org If I have seen farther than others, it is because I was standing on the shoulders of giants. --Isaac Newton From aps at ieee.org Tue Jun 3 00:50:08 2014 From: aps at ieee.org (Armando Stettner) Date: Mon, 2 Jun 2014 07:50:08 -0700 Subject: [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck') In-Reply-To: <20140602144105.GO18282@mercury.ccil.org> References: <201406020209.s5229Q5o006174@stowe.cs.dartmouth.edu> <59D01DBF-EF49-45B8-8F80-FA03E644A528@tfeb.org> <20140602144105.GO18282@mercury.ccil.org> Message-ID: And, to think, I thought operating system wars and editor religions had died long ago.... aps. Begin forwarded message: > From: John Cowan > Subject: Re: [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck') > Date: June 2, 2014 at 7:41:05 AM PDT > To: Clem Cole > Cc: TUHS main list , Tim Bradshaw , Doug McIlroy > > Clem Cole scripsit: > >> I've often wondered what would have happened if he had known about it. > > Linus is on record as saying that if either the Hurd or the 386BSD system > had been available to him, he would never have written the Linux kernel. > > -- > John Cowan http://www.ccil.org/~cowan cowan at ccil.org > If I have seen farther than others, it is because I was standing on > the shoulders of giants. --Isaac Newton > _______________________________________________ > TUHS mailing list > TUHS at minnie.tuhs.org > https://minnie.tuhs.org/mailman/listinfo/tuhs > From cowan at mercury.ccil.org Tue Jun 3 03:35:21 2014 From: cowan at mercury.ccil.org (John Cowan) Date: Mon, 2 Jun 2014 13:35:21 -0400 Subject: [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck') In-Reply-To: <201406020623.s526Nctu017760@freefriends.org> References: <201406020209.s5229Q5o006174@stowe.cs.dartmouth.edu> <00668C2D-BF21-44EA-A7D8-A9530CA24551@bsdimp.com> <20140602031715.GA27136@eureka.lemis.com> <20140602044348.GJ18282@mercury.ccil.org> <201406020623.s526Nctu017760@freefriends.org> Message-ID: <20140602173521.GX18282@mercury.ccil.org> arnold at skeeve.com scripsit: > This is only possible because of the standardization efforts at the > C and POSIX levels. Remember that Autoconf/Automake were invented to > solve the issue of all the forks: SunOS / Solaris / HP-UX / Ultrix / > MIPS / Pryamid / DG-UX / ad nauseum. Lots of things that were almost but > not quite entirely like V7 or System V Unix. Oh, absolutely. But Autotools themselves are very unstable, so we've apparently replaced spatial variation with longitudinal variation. The Chicken project was undergoing too much churn trying to run correctly with different installed versions of Autotools. So we switched to CMake, but that was even more unstable, and couldn't handle a bootstrapped self-compiler well. So finally we switched to the current scheme of Makefile fragments. Each fragment specifies appropriate cc and ld options, including libraries required, and then writes out a chicken-defaults.h file with a bunch of HAVE_* macros. That's all that's needed. -- John Cowan http://www.ccil.org/~cowan cowan at ccil.org That you can cover for the plentiful and often gaping errors, misconstruals and disinformation in your posts through sheer volume -- that is another misconception. --Mike to Peter From tim.newsham at gmail.com Tue Jun 3 04:41:36 2014 From: tim.newsham at gmail.com (Tim Newsham) Date: Mon, 2 Jun 2014 08:41:36 -1000 Subject: [TUHS] unix history git Message-ID: have you guys seen this? https://github.com/dspinellis/unix-history-repo (I'm not involved, just came across it by way of twitter) -- Tim Newsham | www.thenewsh.com/~newsham | @newshtwit | thenewsh.blogspot.com From brantley at coraid.com Tue Jun 3 04:27:02 2014 From: brantley at coraid.com (Brantley Coile) Date: Mon, 2 Jun 2014 18:27:02 +0000 Subject: [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck') In-Reply-To: References: <201406020209.s5229Q5o006174@stowe.cs.dartmouth.edu> <59D01DBF-EF49-45B8-8F80-FA03E644A528@tfeb.org> <20140602144105.GO18282@mercury.ccil.org>, Message-ID: Isn't it part of the nostalgia? iPhone email > On Jun 2, 2014, at 10:57 AM, "Armando Stettner" wrote: > > And, to think, I thought operating system wars and editor religions had died long ago.... > > aps. > > > Begin forwarded message: > >> From: John Cowan >> Subject: Re: [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck') >> Date: June 2, 2014 at 7:41:05 AM PDT >> To: Clem Cole >> Cc: TUHS main list , Tim Bradshaw , Doug McIlroy >> >> Clem Cole scripsit: >> >>> I've often wondered what would have happened if he had known about it. >> >> Linus is on record as saying that if either the Hurd or the 386BSD system >> had been available to him, he would never have written the Linux kernel. >> >> -- >> John Cowan http://www.ccil.org/~cowan cowan at ccil.org >> If I have seen farther than others, it is because I was standing on >> the shoulders of giants. --Isaac Newton >> _______________________________________________ >> TUHS mailing list >> TUHS at minnie.tuhs.org >> https://minnie.tuhs.org/mailman/listinfo/tuhs > _______________________________________________ > TUHS mailing list > TUHS at minnie.tuhs.org > https://minnie.tuhs.org/mailman/listinfo/tuhs From imp at bsdimp.com Tue Jun 3 04:44:46 2014 From: imp at bsdimp.com (Warner Losh) Date: Mon, 2 Jun 2014 12:44:46 -0600 Subject: [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck') In-Reply-To: <20140602173521.GX18282@mercury.ccil.org> References: <201406020209.s5229Q5o006174@stowe.cs.dartmouth.edu> <00668C2D-BF21-44EA-A7D8-A9530CA24551@bsdimp.com> <20140602031715.GA27136@eureka.lemis.com> <20140602044348.GJ18282@mercury.ccil.org> <201406020623.s526Nctu017760@freefriends.org> <20140602173521.GX18282@mercury.ccil.org> Message-ID: <0336AA23-2BB0-4ACE-80DC-570B2A32F19E@bsdimp.com> On Jun 2, 2014, at 11:35 AM, John Cowan wrote: > arnold at skeeve.com scripsit: > > >> This is only possible because of the standardization efforts at the >> C and POSIX levels. Remember that Autoconf/Automake were invented to >> solve the issue of all the forks: SunOS / Solaris / HP-UX / Ultrix / >> MIPS / Pryamid / DG-UX / ad nauseum. Lots of things that were almost but >> not quite entirely like V7 or System V Unix. > > Oh, absolutely. But Autotools themselves are very unstable, so we've > apparently replaced spatial variation with longitudinal variation. > The Chicken project was undergoing too much churn trying to run correctly > with different installed versions of Autotools. So we switched to CMake, > but that was even more unstable, and couldn't handle a bootstrapped > self-compiler well. > > So finally we switched to the current scheme of Makefile fragments. > Each fragment specifies appropriate cc and ld options, including libraries > required, and then writes out a chicken-defaults.h file with a bunch of > HAVE_* macros. That's all that's needed. Sounds a bit like imake-uberlite… Or should I not mention imake lest the love-fest for all things evil continue on it. :) Warner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: From cowan at mercury.ccil.org Tue Jun 3 04:52:00 2014 From: cowan at mercury.ccil.org (John Cowan) Date: Mon, 2 Jun 2014 14:52:00 -0400 Subject: [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck') In-Reply-To: <0336AA23-2BB0-4ACE-80DC-570B2A32F19E@bsdimp.com> References: <201406020209.s5229Q5o006174@stowe.cs.dartmouth.edu> <00668C2D-BF21-44EA-A7D8-A9530CA24551@bsdimp.com> <20140602031715.GA27136@eureka.lemis.com> <20140602044348.GJ18282@mercury.ccil.org> <201406020623.s526Nctu017760@freefriends.org> <20140602173521.GX18282@mercury.ccil.org> <0336AA23-2BB0-4ACE-80DC-570B2A32F19E@bsdimp.com> Message-ID: <20140602185200.GZ18282@mercury.ccil.org> Warner Losh scripsit: > Sounds a bit like imake-uberlite… Or should I not mention imake > lest the love-fest for all things evil continue on it. :) Not much like, because there is no configuration tool at all. You just say "make PLATFORM=foo" and it includes Makefile.foo. I've attached a couple of Makefile fragments to this email for easy comparison. -- John Cowan http://www.ccil.org/~cowan cowan at ccil.org Principles. You can't say A is made of B or vice versa. All mass is interaction. --Richard Feynman -------------- next part -------------- # Makefile.linux - configuration for Linux -*- Makefile -*- # # Copyright (c) 2008-2014, The Chicken Team # Copyright (c) 2007, Felix L. Winkelmann # All rights reserved. # # Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following # conditions are met: # # Redistributions of source code must retain the above copyright notice, this list of conditions and the following # disclaimer. # Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following # disclaimer in the documentation and/or other materials provided with the distribution. # Neither the name of the author nor the names of its contributors may be used to endorse or promote # products derived from this software without specific prior written permission. # # THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS # OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY # AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDERS OR # CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR # CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR # SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY # THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR # OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE # POSSIBILITY OF SUCH DAMAGE. ifneq ($(CONFIG),) include $(CONFIG) endif SRCDIR ?= ./ # platform configuration ARCH ?= $(shell sh $(SRCDIR)/config-arch.sh) # options C_COMPILER_OPTIONS ?= -fno-strict-aliasing -fwrapv -DHAVE_CHICKEN_CONFIG_H ifdef DEBUGBUILD C_COMPILER_OPTIMIZATION_OPTIONS ?= -g -Wall -Wno-unused else ifdef OPTIMIZE_FOR_SPEED C_COMPILER_OPTIMIZATION_OPTIONS ?= -O3 -fomit-frame-pointer else C_COMPILER_OPTIMIZATION_OPTIONS ?= -Os -fomit-frame-pointer endif endif LINKER_LINK_SHARED_LIBRARY_OPTIONS = -shared LINKER_LINK_SHARED_DLOADABLE_OPTIONS = -L. -shared -Wl,-R"$(RUNTIME_LINKER_PATH)" LINKER_LINK_SHARED_PROGRAM_OPTIONS = -Wl,-R"$(RUNTIME_LINKER_PATH)" LIBCHICKEN_SO_LINKER_OPTIONS = -Wl,-soname,lib$(PROGRAM_PREFIX)chicken$(PROGRAM_SUFFIX).so.$(BINARYVERSION) LIBRARIES = -lm -ldl NEEDS_RELINKING = yes USES_SONAME = yes # special files CHICKEN_CONFIG_H = chicken-config.h # select default and internal settings include $(SRCDIR)/defaults.make chicken-config.h: chicken-defaults.h echo "/* GENERATED */" >$@ echo "#define HAVE_DIRENT_H 1" >>$@ echo "#define HAVE_DLFCN_H 1" >>$@ echo "#define HAVE_INTTYPES_H 1" >>$@ echo "#define HAVE_LIMITS_H 1" >>$@ echo "#define HAVE_LONG_LONG 1" >>$@ echo "#define HAVE_MEMMOVE 1" >>$@ echo "#define HAVE_MEMORY_H 1" >>$@ echo "#define HAVE_POSIX_POLL 1" >>$@ echo "#define HAVE_SIGACTION 1" >>$@ echo "#define HAVE_SIGSETJMP 1" >>$@ echo "#define HAVE_SIGPROCMASK 1" >>$@ echo "#define HAVE_STDINT_H 1" >>$@ echo "#define HAVE_STDLIB_H 1" >>$@ echo "#define HAVE_STRERROR 1" >>$@ echo "#define HAVE_STRINGS_H 1" >>$@ echo "#define HAVE_STRING_H 1" >>$@ echo "#define HAVE_STRTOLL 1" >>$@ echo "#define HAVE_STRTOQ 1" >>$@ echo "#define HAVE_SYS_STAT_H 1" >>$@ echo "#define HAVE_SYS_TYPES_H 1" >>$@ echo "#define HAVE_SETENV 1" >>$@ echo "#define HAVE_UNISTD_H 1" >>$@ echo "#define HAVE_UNSIGNED_LONG_LONG 1" >>$@ echo "#define STDC_HEADERS 1" >>$@ echo "#define HAVE_ALLOCA 1" >>$@ echo "#define HAVE_ALLOCA_H 1" >>$@ echo "#define HAVE_GRP_H 1" >>$@ echo "#define HAVE_ERRNO_H 1" >>$@ echo "#define HAVE_SYSEXITS_H 1" >>$@ echo "#define HAVE_MEMMOVE 1" >>$@ echo "#define C_STACK_GROWS_DOWNWARD 1" >>$@ ifdef GCHOOKS echo "#define C_GC_HOOKS" >>$@ endif ifdef SYMBOLGC echo "#define C_COLLECT_ALL_SYMBOLS" >>$@ endif ifneq ($(HACKED_APPLY),) echo "#define C_HACKED_APPLY" >>$@ endif cat chicken-defaults.h >>$@ include $(SRCDIR)/rules.make -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile.bsd Type: chemical/x-crossfire Size: 4200 bytes Desc: not available URL: -------------- next part -------------- # Makefile.solaris - configuration for Solaris -*- Makefile -*- # # Copyright (c) 2008-2014, The Chicken Team # Copyright (c) 2007, Felix L. Winkelmann # All rights reserved. # # Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following # conditions are met: # # Redistributions of source code must retain the above copyright notice, this list of conditions and the following # disclaimer. # Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following # disclaimer in the documentation and/or other materials provided with the distribution. # Neither the name of the author nor the names of its contributors may be used to endorse or promote # products derived from this software without specific prior written permission. # # THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS # OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY # AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDERS OR # CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR # CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR # SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY # THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR # OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE # POSSIBILITY OF SUCH DAMAGE. ifneq ($(CONFIG),) include $(CONFIG) endif SRCDIR = ./ # platform configuration ARCH ?= $(shell sh $(SRCDIR)/config-arch.sh) # default to gcc - use "make ... C_COMPILER=cc ..." to use SunPro CC export C_COMPILER ?= gcc export INSTALL_PROGRAM ?= ginstall # options ifeq ($(C_COMPILER),cc) ifneq (,$(filter-out x86 x86-64,$(ARCH))) # -xannotate=no is not supported on x86/x86-64 DISABLE_ANNOTATIONS=-xannotate=no else DISABLE_ANNOTATIONS= endif C_COMPILER_OPTIONS ?= -errtags -xdebugformat=stabs $(DISABLE_ANNOTATIONS) -DHAVE_CHICKEN_CONFIG_H else C_COMPILER_OPTIONS ?= -fno-strict-aliasing -fwrapv -DHAVE_CHICKEN_CONFIG_H endif ifdef DEBUGBUILD ifeq ($(C_COMPILER),cc) C_COMPILER_OPTIMIZATION_OPTIONS ?= -g +w else C_COMPILER_OPTIMIZATION_OPTIONS ?= -g -Wall -Wno-unused endif else ifdef OPTIMIZE_FOR_SPEED ifeq ($(C_COMPILER),cc) C_COMPILER_OPTIMIZATION_OPTIONS += -g -xO4 else C_COMPILER_OPTIMIZATION_OPTIONS ?= -O3 -fomit-frame-pointer endif else ifeq ($(C_COMPILER),cc) C_COMPILER_OPTIMIZATION_OPTIONS += -g -xO3 else C_COMPILER_OPTIMIZATION_OPTIONS ?= -Os -fomit-frame-pointer endif endif endif ifeq ($(C_COMPILER),cc) # Assuming 'cc' means SunW/SunStudio compiler LINKER_LINK_SHARED_LIBRARY_OPTIONS = -G $(DISABLE_ANNOTATIONS) LINKER_LINK_SHARED_DLOADABLE_OPTIONS = -G $(DISABLE_ANNOTATIONS) -R"$(RUNTIME_LINKER_PATH)" -L. LINKER_LINK_SHARED_PROGRAM_OPTIONS = -R"$(RUNTIME_LINKER_PATH)" else LINKER_LINK_SHARED_LIBRARY_OPTIONS = -shared LINKER_LINK_SHARED_DLOADABLE_OPTIONS = -shared -Wl,-R"$(RUNTIME_LINKER_PATH)" -Wl,-L. LINKER_LINK_SHARED_PROGRAM_OPTIONS = -Wl,-R"$(RUNTIME_LINKER_PATH)" endif LIBRARIES = -lsocket -lnsl -lm -ldl -lrt NEEDS_RELINKING = yes USES_SONAME = yes # special files CHICKEN_CONFIG_H = chicken-config.h # select default and internal settings include $(SRCDIR)/defaults.make chicken-config.h: chicken-defaults.h echo "/* END OF FILE */" >$@ echo "#define HAVE_DIRENT_H 1" >>$@ echo "#define HAVE_DLFCN_H 1" >>$@ echo "#define HAVE_INTTYPES_H 1" >>$@ echo "#define HAVE_LIMITS_H 1" >>$@ echo "#define HAVE_LONG_LONG 1" >>$@ echo "#define HAVE_MEMMOVE 1" >>$@ echo "#define HAVE_MEMORY_H 1" >>$@ echo "#define HAVE_POSIX_POLL 1" >>$@ echo "#define HAVE_SIGACTION 1" >>$@ echo "#define HAVE_STDINT_H 1" >>$@ echo "#define HAVE_STDLIB_H 1" >>$@ echo "#define HAVE_STRERROR 1" >>$@ echo "#define HAVE_STRINGS_H 1" >>$@ echo "#define HAVE_STRING_H 1" >>$@ echo "#define HAVE_STRLCAT 1" >>$@ echo "#define HAVE_STRLCPY 1" >>$@ echo "#define HAVE_STRTOLL 1" >>$@ echo "#define HAVE_SYS_STAT_H 1" >>$@ echo "#define HAVE_SYS_TYPES_H 1" >>$@ echo "#define HAVE_SETENV 1" >>$@ echo "#define HAVE_UNISTD_H 1" >>$@ echo "#define HAVE_UNSIGNED_LONG_LONG 1" >>$@ echo "#define STDC_HEADERS 1" >>$@ echo "#define HAVE_ALLOCA_H 1" >>$@ echo "#define HAVE_ALLOCA 1" >>$@ echo "#define HAVE_GRP_H 1" >>$@ echo "#define HAVE_ERRNO_H 1" >>$@ echo "#define HAVE_SYSEXITS_H 1" >>$@ echo "#define C_STACK_GROWS_DOWNWARD 1" >>$@ ifdef GCHOOKS echo "#define C_GC_HOOKS" >>$@ endif ifdef SYMBOLGC echo "#define C_COLLECT_ALL_SYMBOLS" >>$@ endif ifneq ($(HACKED_APPLY),) echo "#define C_HACKED_APPLY" >>$@ endif cat chicken-defaults.h >>$@ include $(SRCDIR)/rules.make -------------- next part -------------- # Makefile.cygwin - configuration for Linux -*- Makefile -*- # # Copyright (c) 2008-2014, The Chicken Team # Copyright (c) 2007, Felix L. Winkelmann # All rights reserved. # # Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following # conditions are met: # # Redistributions of source code must retain the above copyright notice, this list of conditions and the following # disclaimer. # Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following # disclaimer in the documentation and/or other materials provided with the distribution. # Neither the name of the author nor the names of its contributors may be used to endorse or promote # products derived from this software without specific prior written permission. # # THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS # OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY # AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDERS OR # CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR # CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR # SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY # THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR # OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE # POSSIBILITY OF SUCH DAMAGE. ifneq ($(CONFIG),) include $(CONFIG) endif SRCDIR = ./ # platform configuration ARCH ?= $(shell sh $(SRCDIR)/config-arch.sh) HACKED_APPLY ?= 1 DLLSINPATH = 1 # options SO = .dll EXE = .exe C_COMPILER = gcc CXX_COMPILER = g++ RC_COMPILER = windres LINKER = gcc TARGET_RC_COMPILER ?= $(RC_COMPILER) C_COMPILER_OPTIONS ?= -fno-strict-aliasing -fwrapv -DHAVE_CHICKEN_CONFIG_H ifdef DEBUGBUILD C_COMPILER_OPTIMIZATION_OPTIONS ?= -g -Wall -Wno-unused else ifdef OPTIMIZE_FOR_SPEED C_COMPILER_OPTIMIZATION_OPTIONS ?= -O3 -fomit-frame-pointer else C_COMPILER_OPTIMIZATION_OPTIONS ?= -Os -fomit-frame-pointer endif endif C_COMPILER_SHARED_OPTIONS = -DPIC LINKER_LINK_SHARED_LIBRARY_OPTIONS = -shared LINKER_LINK_SHARED_PROGRAM_OPTIONS = -Wl,--dll-search-prefix=cyg LIBCHICKEN_SO_LINKER_OPTIONS = -Wl,--out-implib,lib$(PROGRAM_PREFIX)chicken$(PROGRAM_SUFFIX).dll.a \ -Wl,--export-all-symbols \ -Wl,--enable-auto-import \ -Wl,--image-base=0x10000000 \ -Wl,--dll \ -Wl,--add-stdcall-alias \ -Wl,--no-whole-archive LIBRARIES = -lm LIBCHICKEN_IMPORT_LIBRARY = lib$(PROGRAM_PREFIX)chicken$(PROGRAM_SUFFIX).dll.a # special files CHICKEN_CONFIG_H = chicken-config.h APPLY_HACK_OBJECT = apply-hack.$(ARCH)$(O) # select default and internal settings include $(SRCDIR)/defaults.make LIBCHICKEN_SO_LIBRARIES = $(LIBRARIES) chicken-config.h: chicken-defaults.h echo "/* GENERATED */" >$@ echo "#define C_INSTALL_RC_COMPILER \"$(RC_COMPILER)\"" >>$@ echo "#define C_TARGET_RC_COMPILER \"$(TARGET_RC_COMPILER)\"" >>$@ echo "#define HAVE_DIRENT_H 1" >>$@ echo "#define HAVE_INTTYPES_H 1" >>$@ echo "#define HAVE_LIMITS_H 1" >>$@ echo "#define HAVE_LONG_LONG 1" >>$@ echo "#define HAVE_MEMMOVE 1" >>$@ echo "#define HAVE_MEMORY_H 1" >>$@ echo "#define HAVE_POSIX_POLL 1" >>$@ echo "#define HAVE_SIGACTION 1" >>$@ echo "#define HAVE_STDINT_H 1" >>$@ echo "#define HAVE_STDLIB_H 1" >>$@ echo "#define HAVE_STRERROR 1" >>$@ echo "#define HAVE_STRINGS_H 1" >>$@ echo "#define HAVE_STRING_H 1" >>$@ echo "#define HAVE_STRLCAT 1" >>$@ echo "#define HAVE_STRLCPY 1" >>$@ echo "#define HAVE_STRTOLL 1" >>$@ echo "#define HAVE_STRTOQ 1" >>$@ echo "#define HAVE_SYS_STAT_H 1" >>$@ echo "#define HAVE_SYS_TYPES_H 1" >>$@ echo "#define HAVE_UNISTD_H 1" >>$@ echo "#define HAVE_UNSIGNED_LONG_LONG 1" >>$@ echo "#define STDC_HEADERS 1" >>$@ echo "#define HAVE_ALLOCA 1" >>$@ echo "#define HAVE_ALLOCA_H 1" >>$@ echo "#define HAVE_GRP_H 1" >>$@ echo "#define HAVE_ERRNO_H 1" >>$@ echo "#define HAVE_SYSEXITS_H 1" >>$@ echo "#define HAVE_DLFCN_H 1" >>$@ echo "#define C_STACK_GROWS_DOWNWARD 1" >>$@ ifdef GCHOOKS echo "#define C_GC_HOOKS" >>$@ endif ifdef SYMBOLGC echo "#define C_COLLECT_ALL_SYMBOLS" >>$@ endif ifdef HACKED_APPLY echo "#define C_HACKED_APPLY" >>$@ endif cat chicken-defaults.h >>$@ include $(SRCDIR)/rules.make From crossd at gmail.com Tue Jun 3 04:52:12 2014 From: crossd at gmail.com (Dan Cross) Date: Mon, 2 Jun 2014 14:52:12 -0400 Subject: [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck') In-Reply-To: References: <201406020209.s5229Q5o006174@stowe.cs.dartmouth.edu> <59D01DBF-EF49-45B8-8F80-FA03E644A528@tfeb.org> <20140602144105.GO18282@mercury.ccil.org> Message-ID: On Mon, Jun 2, 2014 at 2:27 PM, Brantley Coile wrote: > Isn't it part of the nostalgia? > Perhaps. But nostalgia aside, something I find interesting (and frankly a bit distressing) is what seems to me to simply be an acceptance that it's all going to end with Linux. That is to say, no one ever seems to talk about what will come *after* Linux. Will Linus's kernel truly be the last kernel anyone works on seriously? Somehow I very much doubt that. And yet, you don't see a lot of talk about evolutionary paths beyond Linux; it's a sort of tunnel vision. For a while, it seemed like Plan 9 and/or Inferno could be the way forward, but they seem to be all but dead. What will be the next step forward? - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnold at skeeve.com Tue Jun 3 05:10:14 2014 From: arnold at skeeve.com (arnold at skeeve.com) Date: Mon, 02 Jun 2014 13:10:14 -0600 Subject: [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck') In-Reply-To: References: <201406020209.s5229Q5o006174@stowe.cs.dartmouth.edu> <59D01DBF-EF49-45B8-8F80-FA03E644A528@tfeb.org> <20140602144105.GO18282@mercury.ccil.org> Message-ID: <201406021910.s52JAEMM025574@freefriends.org> Dan Cross wrote: > But nostalgia aside, something I find interesting (and frankly a bit > distressing) is what seems to me to simply be an acceptance that it's all > going to end with Linux. That is to say, no one ever seems to talk about > what will come *after* Linux. Will Linus's kernel truly be the last kernel > anyone works on seriously? Somehow I very much doubt that. And yet, you > don't see a lot of talk about evolutionary paths beyond Linux; it's a sort > of tunnel vision. > > For a while, it seemed like Plan 9 and/or Inferno could be the way forward, > but they seem to be all but dead. What will be the next step forward? Brantley can tell you that Plan 9 isn't dead, although the Labs aren't really providiing the "central control" that Steve mentioned and which is so valuable. There is even some innovation in the Plan 9 world, but much of it is "researchy" - not something to run your enterprise on. (At least, not without a few very sharp gurus handy.) It seems like Plan 9 has been stuck somewhere between V7 and 4.3BSD in terms of "solidity" for many years now. This is rather sad. Arnold From cowan at mercury.ccil.org Tue Jun 3 05:30:55 2014 From: cowan at mercury.ccil.org (John Cowan) Date: Mon, 2 Jun 2014 15:30:55 -0400 Subject: [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck') In-Reply-To: References: <201406020209.s5229Q5o006174@stowe.cs.dartmouth.edu> <59D01DBF-EF49-45B8-8F80-FA03E644A528@tfeb.org> <20140602144105.GO18282@mercury.ccil.org> Message-ID: <20140602193055.GC18282@mercury.ccil.org> Dan Cross scripsit: > But nostalgia aside, something I find interesting (and frankly a bit > distressing) is what seems to me to simply be an acceptance that it's all > going to end with Linux. That is to say, no one ever seems to talk about > what will come *after* Linux. Will Linus's kernel truly be the last kernel > anyone works on seriously? Somehow I very much doubt that. And yet, you > don't see a lot of talk about evolutionary paths beyond Linux; it's a sort > of tunnel vision. This is like asking when there will be a new scientific discovery in some field. There will be a new kernel when someone decides, as Linus did, to write a new kernel. If it catches on, it may supplement or replace Linux. -- John Cowan http://www.ccil.org/~cowan cowan at ccil.org Sir, I quite agree with you, but what are we two against so many? --George Bernard Shaw, to a man booing at the opening of _Arms and the Man_ From crossd at gmail.com Tue Jun 3 05:54:28 2014 From: crossd at gmail.com (Dan Cross) Date: Mon, 2 Jun 2014 15:54:28 -0400 Subject: [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck') In-Reply-To: <20140602193055.GC18282@mercury.ccil.org> References: <201406020209.s5229Q5o006174@stowe.cs.dartmouth.edu> <59D01DBF-EF49-45B8-8F80-FA03E644A528@tfeb.org> <20140602144105.GO18282@mercury.ccil.org> <20140602193055.GC18282@mercury.ccil.org> Message-ID: On Mon, Jun 2, 2014 at 3:30 PM, John Cowan wrote: > Dan Cross scripsit: > > > But nostalgia aside, something I find interesting (and frankly a bit > > distressing) is what seems to me to simply be an acceptance that it's all > > going to end with Linux. That is to say, no one ever seems to talk about > > what will come *after* Linux. Will Linus's kernel truly be the last > kernel > > anyone works on seriously? Somehow I very much doubt that. And yet, you > > don't see a lot of talk about evolutionary paths beyond Linux; it's a > sort > > of tunnel vision. > > This is like asking when there will be a new scientific discovery in some > field. Forgive me, but I think that's a bit of an odd analogy (or perhaps an indication that I did not adequately explain what I meant). However, let me run with it for a moment and rephrase my statement: there can only be a discovery if one decides it's worth doing the sort of investigation that would lead to a new discovery, and I wonder whether "we" still have that kind of curiosity or drive. Or has Linux become so entrenched that no one can imagine bothering anymore? There will be a new kernel when someone decides, as Linus did, to > write a new kernel. If it catches on, it may supplement or replace Linux. To whit: it appears that "we" (for some large value of "we") have collectively decided that it's not worth looking for a replacement for Linux. If nothing else, I find that interesting. - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cnehren+tuhs at pobox.com Tue Jun 3 05:47:49 2014 From: cnehren+tuhs at pobox.com (Chris Nehren) Date: Mon, 2 Jun 2014 15:47:49 -0400 Subject: [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck') In-Reply-To: References: <201406020209.s5229Q5o006174@stowe.cs.dartmouth.edu> <59D01DBF-EF49-45B8-8F80-FA03E644A528@tfeb.org> <20140602144105.GO18282@mercury.ccil.org> Message-ID: <20140602194749.GA2463@behemoth> On Mon, Jun 02, 2014 at 14:52:12 -0400, Dan Cross wrote: > But nostalgia aside, something I find interesting (and frankly a bit > distressing) is what seems to me to simply be an acceptance that it's all > going to end with Linux. That is to say, no one ever seems to talk about > what will come *after* Linux. Will Linus's kernel truly be the last kernel > anyone works on seriously? Somehow I very much doubt that. And yet, you > don't see a lot of talk about evolutionary paths beyond Linux; it's a sort > of tunnel vision. You (specifically) don't see a lot of evolutionary paths beyond Linux because you're not looking for them. There is a lot of innovation happening in illumos and BSD. Thanks to the aforementioned rms, Linux has been about evangelism almost from the start. The illumos and BSD communities are more focused on great engineering rather than proselytization. Let Linux have the fame; everyone who wants to do great work (that Linux users will then want to steal, and then gripe about because of licensing FUD) is elsewhere. -- Chris Nehren -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 907 bytes Desc: not available URL: From dugo at xs4all.nl Tue Jun 3 06:06:52 2014 From: dugo at xs4all.nl (Jacob Goense) Date: Mon, 02 Jun 2014 22:06:52 +0200 Subject: [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck') In-Reply-To: References: <201406020209.s5229Q5o006174@stowe.cs.dartmouth.edu> <59D01DBF-EF49-45B8-8F80-FA03E644A528@tfeb.org> Message-ID: <498a888e69bc1600ab199aeb40e0e485@xs4all.nl> On 2014-06-02 16:25, Clem Cole wrote: > Linus this would eventually need a compiler and pulled rms' suite. > > The funny part is that his University has 386BSD (aka 4.2 for the > 386) at the time which did use the MMU, had networking and even the > first step at X11. At the time I had helped the guys get the AT disk > driver working as I had access to all the Western Digital > documentation. But to get the code from CRSG, you needed at BSD > license, which required an AT&T license. Linus' university had one, > but he did know know the magic ftp site to download or have access. > > I've often wondered what would have happened if he had known about it. AFAICT 386BSD port started out with 4.3BSD-Tahoe sources. Jolitz pulled in GCC[1], and Linus would have run into the same compiler. Did Jolitz even have much of a choice back in '89? [1] - From the original project proposal for 386BSD 3.1. Language tools: We will base our port on nascent language utilities from RMS's GNU project (GCC & GAS & LD), which are fairly well fleshed-out but have never been put to the acid test. Obviously, we will encounter and bypass and/or fix compiler bugs. Until we find a dedicated compiler participant who is familiar with GCC, the author will field all compiler problems and be responsible for fixes and/or workarounds. We think that GCC is an excellent compiler to work with, and hope that our use of it will provide FSF with much useful feedback on fixes and improvements. From crossd at gmail.com Tue Jun 3 06:23:03 2014 From: crossd at gmail.com (Dan Cross) Date: Mon, 2 Jun 2014 16:23:03 -0400 Subject: [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck') In-Reply-To: <20140602194749.GA2463@behemoth> References: <201406020209.s5229Q5o006174@stowe.cs.dartmouth.edu> <59D01DBF-EF49-45B8-8F80-FA03E644A528@tfeb.org> <20140602144105.GO18282@mercury.ccil.org> <20140602194749.GA2463@behemoth> Message-ID: On Mon, Jun 2, 2014 at 3:47 PM, Chris Nehren wrote: > On Mon, Jun 02, 2014 at 14:52:12 -0400, Dan Cross wrote: > > But nostalgia aside, something I find interesting (and frankly a bit > > distressing) is what seems to me to simply be an acceptance that it's all > > going to end with Linux. That is to say, no one ever seems to talk about > > what will come *after* Linux. Will Linus's kernel truly be the last > kernel > > anyone works on seriously? Somehow I very much doubt that. And yet, you > > don't see a lot of talk about evolutionary paths beyond Linux; it's a > sort > > of tunnel vision. > > You (specifically) don't see a lot of evolutionary paths beyond > Linux because you're not looking for them. Well, without knowing me or a thing about me, that's a strong statement. There is a lot of innovation happening in illumos and BSD. [snip] This is my point. s/Linux/(Illumos|.*BSD)/ and the point remains largely the same. These aren't new systems trying out fundamentally new ideas; they're making incremental improvements on things that have come before. That's all well and good (and it's nice to have an alternative to Linux specifically), but building on a nearly 50 year old framework isn't particularly innovative, despite claims to the contrary. Now don't get me wrong, that framework remains wildly useful, and so that work has value, but my question is more generally whether anyone has the kind of drive to come up with the sort of next generation system that Unix represented when Unix was new? Things like Plan 9 and Akaros are more along the lines of what I was thinking of: mentioning *BSD or other such systems reinforces my thesis. - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From corky1951 at comcast.net Tue Jun 3 07:08:15 2014 From: corky1951 at comcast.net (Charlie Kester) Date: Mon, 2 Jun 2014 14:08:15 -0700 Subject: [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck') In-Reply-To: References: <201406020209.s5229Q5o006174@stowe.cs.dartmouth.edu> <59D01DBF-EF49-45B8-8F80-FA03E644A528@tfeb.org> <20140602144105.GO18282@mercury.ccil.org> Message-ID: <20140602210815.GA25138@comcast.net> On Mon 02 Jun 2014 at 11:52:12 PDT Dan Cross wrote: > On Mon, Jun 2, 2014 at 2:27 PM, Brantley Coile <[1]brantley at coraid.com> > wrote: > > Isn't it part of the nostalgia? > > Perhaps. > But nostalgia aside, something I find interesting (and frankly a bit > distressing) is what seems to me to simply be an acceptance that it's all > going to end with Linux.  That is to say, no one ever seems to talk about > what will come *after* Linux.  Will Linus's kernel truly be the last > kernel anyone works on seriously?  Somehow I very much doubt that.  And > yet, you don't see a lot of talk about evolutionary paths beyond Linux; > it's a sort of tunnel vision. > For a while, it seemed like Plan 9 and/or Inferno could be the way > forward, but they seem to be all but dead.  What will be the next step > forward? The recent dustup over systemd does seem to have many people looking for alternatives to the main Linux distros -- and perhaps to Linux itself. There's an opportunity, but it isn't clear that anyone is prepared to seize it. From dds at aueb.gr Tue Jun 3 08:05:49 2014 From: dds at aueb.gr (Diomidis Spinellis) Date: Tue, 03 Jun 2014 01:05:49 +0300 Subject: [TUHS] unix history git In-Reply-To: References: Message-ID: <538CF53D.1090801@aueb.gr> Thank you for bringing this up. I first posted to the list about the project in February 2013 [1], and some of you helpfully supplied me login names I was looking for. Over the past few weeks I managed to solve a difficult problem that was puzzling me, namely how to commit each release snapshot files incrementally, while also ensuring that git blame would work correctly across releases. Having solved the problem, I created a working repository with a some key releases in it, and was waiting to tidy up a few loose ends before coming to the list for more help. Now hat the cat is out of the bag, here are a few things I could need your help. 1. The login names of the following Bell Labs researchers Charles B. Haley E. Schmidt 2. The login names of the following Berkeley authors A. R. Newton Charles Haley Colin L. Mc Master Douglas Lanam D. O. Pederson Ellis Cohen Earl T. Cohen Ivan Maltz Juan Porcar Jeff Schriebman Kurt Shoens Len Edmondson Olivier Roubine R. Dowell Ross Harvey Richard Tuck Robert Toxen Susan L. Graham Zhishun Alex Liu 3. The names corresponding to the following Berkeley ids claudio csvaf denise ecc epg evan fitz fortran harrison lam opcode orange rt 4. The authors of a few relatively large contributions (the numbers are the changed lines associated with the specific release and corresponding total lines). Research-V6 usr/source/sno 1606 1606 usr/source/cref/src 1448 1463 Research-V7 usr/src/games/chess 3985 3993 usr/games/ching.d 2366 2366 usr/src/cmd/cpp 1413 1417 usr/src/cmd/lpr 1318 1318 usr/src/libF77 1271 1271 1BSD pcs 1800 1800 portlib 1701 1781 opcodes 1580 1580 3BSD usr/src/sys/sys 8163 16488 usr/src/cmd/f77 5981 17252 usr/src/new/libI77uc 4379 5395 usr/src/cmd/versatec 3885 4271 usr/games/advfiles/cave 1772 1772 usr/games/quiz.k 1709 1709 usr/src/cmd/uucp 1358 7387 usr/src/sys/stand 1350 3382 usr/src/games/banner.c 1129 1129 5. Errors and omissions in the files that map file paths to authors. [2] You can supply these things via the list, if you think they're of wider interest, through private email, or through git pull requests. [1] http://minnie.tuhs.org/pipermail/tuhs/2013-February/002836.html [2] https://github.com/dspinellis/unix-history-make/blob/master/src/author-path Diomidis Spinellis On 02/06/2014 21:41, Tim Newsham wrote: > have you guys seen this? > https://github.com/dspinellis/unix-history-repo > > (I'm not involved, just came across it by way of twitter) > From clemc at ccc.com Tue Jun 3 08:47:18 2014 From: clemc at ccc.com (Clem Cole) Date: Mon, 2 Jun 2014 18:47:18 -0400 Subject: [TUHS] unix history git In-Reply-To: <538CF53D.1090801@aueb.gr> References: <538CF53D.1090801@aueb.gr> Message-ID: <5A14B477-ED7D-4A27-8CCE-86AAABCE09E6@ccc.com> the late rich newton had three login's. arn newton and merkin the late don Pederson was dop btw. dop more than anyone else really is the father of what now call the open source movement. > On Jun 2, 2014, at 6:05 PM, Diomidis Spinellis wrote: > > Thank you for bringing this up. I first posted to the list about the project in February 2013 [1], and some of you helpfully supplied me login names I was looking for. > > Over the past few weeks I managed to solve a difficult problem that was puzzling me, namely how to commit each release snapshot files incrementally, while also ensuring that git blame would work correctly across releases. Having solved the problem, I created a working repository with a some key releases in it, and was waiting to tidy up a few loose ends before coming to the list for more help. > > Now hat the cat is out of the bag, here are a few things I could need your help. > > 1. The login names of the following Bell Labs researchers > Charles B. Haley > E. Schmidt > > 2. The login names of the following Berkeley authors > A. R. Newton > Charles Haley > Colin L. Mc Master > Douglas Lanam > D. O. Pederson > Ellis Cohen > Earl T. Cohen > Ivan Maltz > Juan Porcar > Jeff Schriebman > Kurt Shoens > Len Edmondson > Olivier Roubine > R. Dowell > Ross Harvey > Richard Tuck > Robert Toxen > Susan L. Graham > Zhishun Alex Liu > > 3. The names corresponding to the following Berkeley ids > claudio > csvaf > denise > ecc > epg > evan > fitz > fortran > harrison > lam > opcode > orange > rt > > 4. The authors of a few relatively large contributions (the numbers are the changed lines associated with the specific release and corresponding total lines). > > Research-V6 > usr/source/sno 1606 1606 > usr/source/cref/src 1448 1463 > > Research-V7 > usr/src/games/chess 3985 3993 > usr/games/ching.d 2366 2366 > usr/src/cmd/cpp 1413 1417 > usr/src/cmd/lpr 1318 1318 > usr/src/libF77 1271 1271 > > 1BSD > pcs 1800 1800 > portlib 1701 1781 > opcodes 1580 1580 > > 3BSD > usr/src/sys/sys 8163 16488 > usr/src/cmd/f77 5981 17252 > usr/src/new/libI77uc 4379 5395 > usr/src/cmd/versatec 3885 4271 > usr/games/advfiles/cave 1772 1772 > usr/games/quiz.k 1709 1709 > usr/src/cmd/uucp 1358 7387 > usr/src/sys/stand 1350 3382 > usr/src/games/banner.c 1129 1129 > > 5. Errors and omissions in the files that map file paths to authors. [2] > > You can supply these things via the list, if you think they're of wider interest, through private email, or through git pull requests. > > [1] http://minnie.tuhs.org/pipermail/tuhs/2013-February/002836.html > [2] https://github.com/dspinellis/unix-history-make/blob/master/src/author-path > > Diomidis Spinellis > >> On 02/06/2014 21:41, Tim Newsham wrote: >> have you guys seen this? >> https://github.com/dspinellis/unix-history-repo >> >> (I'm not involved, just came across it by way of twitter) >> > > _______________________________________________ > TUHS mailing list > TUHS at minnie.tuhs.org > https://minnie.tuhs.org/mailman/listinfo/tuhs From cowan at mercury.ccil.org Tue Jun 3 09:37:21 2014 From: cowan at mercury.ccil.org (John Cowan) Date: Mon, 2 Jun 2014 19:37:21 -0400 Subject: [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck') In-Reply-To: References: <59D01DBF-EF49-45B8-8F80-FA03E644A528@tfeb.org> <20140602144105.GO18282@mercury.ccil.org> <20140602193055.GC18282@mercury.ccil.org> Message-ID: <20140602233721.GF18282@mercury.ccil.org> Dan Cross scripsit: > > There will be a new kernel when someone decides, as Linus did, to > > write a new kernel. If it catches on, it may supplement or replace Linux. > > To whit: it appears that "we" (for some large value of "we") have > collectively decided that it's not worth looking for a replacement for > Linux. If nothing else, I find that interesting. It doesn't matter how many people decide not to do it, any more than it matters how many people decide not to try to find a replacement for the Standard Model. It only takes one to decide *to* do it. Of course, some people may decide and never do it, or never finish it, or be mute inglorious Miltons who are never heard of, or who are heard of but fail to take over the world. All anyone can do is either do it themselves or wait for someone else to do so. -- John Cowan http://www.ccil.org/~cowan cowan at ccil.org If I have not seen as far as others, it is because giants were standing on my shoulders. --Hal Abelson From tim.newsham at gmail.com Tue Jun 3 10:37:52 2014 From: tim.newsham at gmail.com (Tim Newsham) Date: Mon, 2 Jun 2014 14:37:52 -1000 Subject: [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck') In-Reply-To: References: <201406020209.s5229Q5o006174@stowe.cs.dartmouth.edu> <59D01DBF-EF49-45B8-8F80-FA03E644A528@tfeb.org> <20140602144105.GO18282@mercury.ccil.org> Message-ID: It would be nice if we end up moving towards something with a solid theoretical underpinning.. seL4 comes to mind. I'd be happy to trade off some performance for some security and strongly enforced modularity. There's still lots to be done (sel4 is just a small microkernel (needed: drivers, filesystems, memory subsystems, etc), and there's little point in having a proven microkernel if you don't keep building up strong software on top of that foundation). On Mon, Jun 2, 2014 at 8:52 AM, Dan Cross wrote: > On Mon, Jun 2, 2014 at 2:27 PM, Brantley Coile wrote: >> >> Isn't it part of the nostalgia? > > > Perhaps. > > But nostalgia aside, something I find interesting (and frankly a bit > distressing) is what seems to me to simply be an acceptance that it's all > going to end with Linux. That is to say, no one ever seems to talk about > what will come *after* Linux. Will Linus's kernel truly be the last kernel > anyone works on seriously? Somehow I very much doubt that. And yet, you > don't see a lot of talk about evolutionary paths beyond Linux; it's a sort > of tunnel vision. > > For a while, it seemed like Plan 9 and/or Inferno could be the way forward, > but they seem to be all but dead. What will be the next step forward? > > - Dan C. > > > _______________________________________________ > TUHS mailing list > TUHS at minnie.tuhs.org > https://minnie.tuhs.org/mailman/listinfo/tuhs > -- Tim Newsham | www.thenewsh.com/~newsham | @newshtwit | thenewsh.blogspot.com From crossd at gmail.com Tue Jun 3 11:24:39 2014 From: crossd at gmail.com (Dan Cross) Date: Mon, 2 Jun 2014 21:24:39 -0400 Subject: [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck') In-Reply-To: <20140602233721.GF18282@mercury.ccil.org> References: <59D01DBF-EF49-45B8-8F80-FA03E644A528@tfeb.org> <20140602144105.GO18282@mercury.ccil.org> <20140602193055.GC18282@mercury.ccil.org> <20140602233721.GF18282@mercury.ccil.org> Message-ID: You are, of course, free to not find it interesting in the way that I do. :-) On Mon, Jun 2, 2014 at 7:37 PM, John Cowan wrote: > Dan Cross scripsit: > > > > There will be a new kernel when someone decides, as Linus did, to > > > write a new kernel. If it catches on, it may supplement or replace > Linux. > > > > To whit: it appears that "we" (for some large value of "we") have > > collectively decided that it's not worth looking for a replacement for > > Linux. If nothing else, I find that interesting. > > It doesn't matter how many people decide not to do it, any more than it > matters how many people decide not to try to find a replacement for the > Standard Model. It only takes one to decide *to* do it. Of course, > some people may decide and never do it, or never finish it, or be mute > inglorious Miltons who are never heard of, or who are heard of but fail > to take over the world. > > All anyone can do is either do it themselves or wait for someone else > to do so. > > -- > John Cowan http://www.ccil.org/~cowan cowan at ccil.org > If I have not seen as far as others, it is because giants were standing > on my shoulders. --Hal Abelson > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brantley at coraid.com Tue Jun 3 11:45:40 2014 From: brantley at coraid.com (Brantley Coile) Date: Tue, 3 Jun 2014 01:45:40 +0000 Subject: [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck') In-Reply-To: <201406021910.s52JAEMM025574@freefriends.org> References: <201406020209.s5229Q5o006174@stowe.cs.dartmouth.edu> <59D01DBF-EF49-45B8-8F80-FA03E644A528@tfeb.org> <20140602144105.GO18282@mercury.ccil.org> <201406021910.s52JAEMM025574@freefriends.org> Message-ID: On Jun 2, 2014, at 3:10 PM, arnold at skeeve.com wrote: > Brantley can tell you that Plan 9 isn't dead, although the Labs aren't > really providiing the "central control" that Steve mentioned and which > is so valuable. Plan 9 will be my development system for the foreseeable future. I built the PIX on BSDI using all the tools from the Labs that I could get my hands on, such as sam(1), rc(1) (from Byron), mk(1), and 9win. I shifted the group to real Plan 9 in 1995, when it became available. I used it to build Coraid and I’ll use it for any startups in the future. I get more done faster using it than any other system I’ve tried. I have always kept an independent version running and pick and choose what goes into it. For example, I still run a Ken Thompson file server, even after it was replaced with “better” technology. Plan 9’s stability is one of the things I greatly value; some parts of our system have uptime’s longer than two years. In the past few years, Erik Quanstrom has been Coraid's keeper of our version of Plan 9. For me, he still is. He has worked, with others, to keep the drivers current and adjust things to the changes in hardware. We run a 64 version, for example, on the latest Intel hardware. It might have a very tiny user base, but they will pry Plan 9 out of my cold dead fingers. (That’s a Mike O’Dell reference.) So it will remain alive. Post script. If you want a mindblowingly elegant and beautiful system, study the Oberon system from the 1980’s by Niklaus Wirth. It inspired the Plan 9 editor acme(1). I’ve seen nothing that compares to it’s clarity of thought. Interestingly, Ken Thompson and Niklaus Wirth were both students at Berkeley at same time. I wonder if Harry Huskey’s values are reflected in their work. Brantley From cowan at mercury.ccil.org Tue Jun 3 12:16:13 2014 From: cowan at mercury.ccil.org (John Cowan) Date: Mon, 2 Jun 2014 22:16:13 -0400 Subject: [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck') In-Reply-To: References: <59D01DBF-EF49-45B8-8F80-FA03E644A528@tfeb.org> <20140602144105.GO18282@mercury.ccil.org> <20140602193055.GC18282@mercury.ccil.org> <20140602233721.GF18282@mercury.ccil.org> Message-ID: <20140603021613.GG18282@mercury.ccil.org> Dan Cross scripsit: > You are, of course, free to not find it interesting in the way that I do. It's not that, I just think you are asking for a prediction of the inherently unpredictable. -- John Cowan http://www.ccil.org/~cowan cowan at ccil.org I amar prestar aen, han mathon ne nen, http://www.ccil.org/~cowan han mathon ne chae, a han noston ne 'wilith. --Galadriel, LOTR:FOTR From crossd at gmail.com Tue Jun 3 12:18:14 2014 From: crossd at gmail.com (Dan Cross) Date: Mon, 2 Jun 2014 22:18:14 -0400 Subject: [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck') In-Reply-To: <20140603021613.GG18282@mercury.ccil.org> References: <59D01DBF-EF49-45B8-8F80-FA03E644A528@tfeb.org> <20140602144105.GO18282@mercury.ccil.org> <20140602193055.GC18282@mercury.ccil.org> <20140602233721.GF18282@mercury.ccil.org> <20140603021613.GG18282@mercury.ccil.org> Message-ID: On Mon, Jun 2, 2014 at 10:16 PM, John Cowan wrote: > Dan Cross scripsit: > > You are, of course, free to not find it interesting in the way that I do. > > It's not that, I just think you are asking for a prediction of the > inherently > unpredictable. I'm not asking for any prediction. I'm merely stating that it seems to me that people aren't interested in these sorts of things anymore. I find that interesting (and a little sad). - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From reed at reedmedia.net Tue Jun 3 14:07:54 2014 From: reed at reedmedia.net (Jeremy C. Reed) Date: Mon, 2 Jun 2014 23:07:54 -0500 (CDT) Subject: [TUHS] unix history git In-Reply-To: <538CF53D.1090801@aueb.gr> References: <538CF53D.1090801@aueb.gr> Message-ID: On Tue, 3 Jun 2014, Diomidis Spinellis wrote: > 2. The login names of the following Berkeley authors > A. R. Newton What code? > Charles Haley chuck (per 1BSD's winfo, sh.1, cpall.6, where.6, whoison.6) > Douglas Lanam What code? > D. O. Pederson Real name is probably "Donald". But what code? > Ellis Cohen cohen (per 1BSD's where.6 ; I don't think is Earl) > Juan Porcar What specific code file for Juan Porcar? > Jeff Schriebman jeff (per 1BSD's winfo) > Kurt Shoens kurt (per 1BSD's winfo, mvall.6, whoison.6) > R. Dowell Richard "Dick" Dowell of Hewlett Packard. > Ross Harvey UCSF Computer Graphics Laboratory > Richard Tuck tuck (per 2BSD netintro.n) > 3. The names corresponding to the following Berkeley ids > claudio The login "dlw" included DLW as part of SCCS commit messages. The claudio entry also says "DLW". So probably David L. Wasley. > csvaf Alastair Fyfe > denise Denise Draper > ecc Eric C. Cooper (login name also is "cooper" later) > epg > evan > fitz Dan Fitzpatrick > fortran I don't see this one. > harrison Mike Harrison or Susan Graham Harrison (except I don't know timing for that name). > lam Karen Lam of BBN > opcode Mark Opperman > orange Carol Orange > rt I also don't find "rt" > 1BSD > pcs 1800 1800 One of the files says "Wirth" and note that other files have spellings like "funktion", "prozedure", "konstant". So maybe all this is from Wirth? > portlib 1701 1781 I think this portlib is from Eric Allman. > opcodes 1580 1580 I guess Thompson, Haley or Joy. > 3BSD I assume you are refering to parts not from 32V... > usr/src/sys/sys 8163 16488 I guess Babaoglu, maybe Juan Porcar, and Joy. Note that the TODO mentions code given to Joy. > usr/src/cmd/f77 5981 17252 I think some of the improvements came from the upstream (November 1978 1.16 vs. January 1980's 2.00). > usr/src/new/libI77uc 4379 5395 Files say originally P. Weinberger and modified by David Wasley. > usr/src/cmd/versatec 3885 4271 sidebyside was written by Joy (per Len Edmondson personal correspondence). > usr/games/advfiles/cave 1772 1772 It was common that some source for games weren't included. Says originally developed by Willie Crowther and most features added by Don Woods (don @ su-ai). And the file says to ask "ark" for questions. I think was in a group called MHTSA (but I don't kno what means). > usr/src/cmd/uucp 1358 7387 Maybe Dave Nowitz? > usr/src/sys/stand 1350 3382 Some of this is just from 32V. I can only guess the changes were from Joy. > usr/src/games/banner.c 1129 1129 Mark Horton (see corresponding man page!) (As a reminder to list readers ... I am authoring a very detailed book covering the history of Berkeley Unix. I have done interviews either by email, phone, and some in person with over 80 of the very early contributors.) From emu at e-bbes.com Tue Jun 3 22:11:21 2014 From: emu at e-bbes.com (emanuel stiebler) Date: Tue, 03 Jun 2014 14:11:21 +0200 Subject: [TUHS] Bugs in V6 'dcheck' In-Reply-To: <20140602033405.E0EA818C0AD@mercury.lcs.mit.edu> References: <20140602033405.E0EA818C0AD@mercury.lcs.mit.edu> Message-ID: <538DBB69.2000206@e-bbes.com> On 2014-06-02 05:34, Noel Chiappa wrote: > I have recently discovered (in my basement!) two sets of full dump tapes > (1/2" magtape) of what I think are the whole filesystem, so if I can find a > way to get them read, we'll have the V6 fsck - and much more besides (such > as a TCP/IP for V6). So I think you may soon get your wish! IIRC, we had a list of people somewhere on TUHS/PUPS, which still can read & write tapes. We had this service for people, who couldn't pull the whole archive through the net, so we send out tapes ... Cheers P.S. Sorry, can't find a link for it at the moment From beebe at math.utah.edu Wed Jun 4 02:38:21 2014 From: beebe at math.utah.edu (Nelson H. F. Beebe) Date: Tue, 3 Jun 2014 10:38:21 -0600 (MDT) Subject: [TUHS] Bugs in V6 'dcheck' In-Reply-To: <201405312324.s4VNOvFV028181@stowe.cs.dartmouth.edu> Message-ID: Doug McIlroy wrote on Sat, 31 May 2014 19:24:57 -0400: >> ... >> In an idle moment one day, Dennis fed a huge line of input to most >> everything in /bin. To the surprise of nobody, including Dennis, lots >> of programs crashed. We WERE surprised a few years later, when a >> journal published this fact as a research result. Does anybody >> remember who published that deep new insight and/or where? >> ... I suspect that two relevant papers that Doug is recalling are these (I routinely use their fuzz-test code on my own software): @String{j-CACM = "Communications of the ACM"} @Article{Miller:1990:ESR, author = "Barton P. Miller and Lars Fredriksen and Bryan So", title = "An empirical study of the reliability of {UNIX} utilities", journal = j-CACM, volume = "33", number = "12", pages = "32--44", month = dec, year = "1990", CODEN = "CACMA2", ISSN = "0001-0782 (print), 1557-7317 (electronic)", ISSN-L = "0001-0782", bibdate = "Wed Sep 25 09:24:48 2002", bibsource = "ftp://ftp.ira.uka.de/pub/bibliography/Misc/IMMD_IV.bib; http://www.acm.org/pubs/toc/; http://www.math.utah.edu/pub/tex/bib/cacm1990.bib", note = "This is a fascinating paper on what happens when random input streams are fed into important UNIX utilities on several commercial UNIX systems. In some cases, the tests were able to crash the entire operating system. In 1995, a (sadly, unpublished) followup study showed that many of the failures diagnosed in 1990 still had not been repaired in the commercial systems, and that the GNU implementations were generally more robust. Both 1990 and 1995 papers, and the fuzz-generating software, are available at the authors' FTP site at \path|ftp://grilled.cs.wisc.edu/technical_papers/fuzz.ps| and \path|ftp://grilled.cs.wisc.edu/technical_papers/fuzz-revisited.ps|.", URL = "ftp://grilled.cs.wisc.edu/technical_papers/fuzz-revisited.ps; ftp://grilled.cs.wisc.edu/technical_papers/fuzz.ps; http://www.acm.org/pubs/toc/Abstracts/0001-0782/96279.html", acknowledgement = ack-nhfb, journal-URL = "http://portal.acm.org/browse_dl.cfm?idx=J79", keywords = "design; reliability; security", note2 = "[25-Sep-2002]: The fuzz software archive has been moved to \path|ftp://ftp.cs.wisc.edu/pub/paradyn/fuzz/|, and the technical reports to \path|ftp://ftp.cs.wisc.edu/pub/paradyn/technical_papers/fuzz*|.", subject = "{\bf D.4.5}: Software, OPERATING SYSTEMS, Reliability. {\bf D.4.0}: Software, OPERATING SYSTEMS, General, UNIX. {\bf D.4.9}: Software, OPERATING SYSTEMS, Systems Programs and Utilities. {\bf D.2.5}: Software, SOFTWARE ENGINEERING, Testing and Debugging.", } @String{j-OPER-SYS-REV = "Operating Systems Review"} @Article{Miller:2007:ESR, author = "Barton P. Miller and Gregory Cooksey and Fredrick Moore", title = "An empirical study of the robustness of {MacOS} applications using random testing", journal = j-OPER-SYS-REV, volume = "41", number = "1", pages = "78--86", month = jan, year = "2007", CODEN = "OSRED8", DOI = "http://doi.acm.org/10.1145/1228291.1228308", ISSN = "0163-5980 (print), 1943-586X (electronic)", ISSN-L = "0163-5980", bibdate = "Fri Jun 20 17:15:27 MDT 2008", bibsource = "http://portal.acm.org/; http://www.math.utah.edu/pub/tex/bib/opersysrev.bib", abstract = "We report on the fourth in a series of studies on the reliability of application programs in the face of random input. Over the previous 15 years, we have studied the reliability of UNIX command line and X-Window based (GUI) applications and Windows applications. In this study, we apply our fuzz testing techniques to applications running on the Mac OS X operating system. We continue to use a simple, or even simplistic technique: unstructured black-box random testing, considering a failure to be a crash or hang. As in the previous three studies, the technique is crude but seems to be effective in locating bugs in real programs. We tested the reliability of 135 command-line UNIX utilities and thirty graphical applications on Mac OS X by feeding random input to each. We report on application failures --- crashes (dumps core) or hangs (loops indefinitely) --- and, where source code is available, we identify the causes of these failures and categorize them. Our testing crashed only 7\% of the command-line utilities, a considerably lower rate of failure than observed in almost all cases of previous studies. We found the GUI-based applications to be less reliable: of the thirty that we tested, only eight did not crash or hang. Twenty others crashed, and two hung. These GUI results were noticeably worse than either of the previous Windows (Win32) or UNIX (X-Windows) studies.", acknowledgement = ack-nhfb, fjournal = "ACM SIGOPS Operating Systems Review", journal-URL = "http://portal.acm.org/browse_dl.cfm?idx=J597", keywords = "fuzz; random testing", } ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah FAX: +1 801 581 4148 - - Department of Mathematics, 110 LCB Internet e-mail: beebe at math.utah.edu - - 155 S 1400 E RM 233 beebe at acm.org beebe at computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - ------------------------------------------------------------------------------- From beebe at math.utah.edu Wed Jun 4 03:33:10 2014 From: beebe at math.utah.edu (Nelson H. F. Beebe) Date: Tue, 3 Jun 2014 11:33:10 -0600 (MDT) Subject: [TUHS] Bugs in V6 'dcheck' Message-ID: I noted just as I sent my previous posting with two references to fuzz-test papers that the abstract of the second mentions two earlier ones. I've just tracked them down, and added them to various bibliographies. Here are short references to them: Fuzz Revisited: A Re-examination of the Reliability of UNIX Utilities and Services ftp://ftp.cs.wisc.edu/pub/techreports/1995/TR1268.pdf An Empirical Study of the Robustness of MacOS Applications Using Random Testing http://dx.doi.org/10.1145/1228291.1228308 ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah FAX: +1 801 581 4148 - - Department of Mathematics, 110 LCB Internet e-mail: beebe at math.utah.edu - - 155 S 1400 E RM 233 beebe at acm.org beebe at computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - ------------------------------------------------------------------------------- From scj at yaccman.com Wed Jun 4 04:48:25 2014 From: scj at yaccman.com (scj at yaccman.com) Date: Tue, 3 Jun 2014 11:48:25 -0700 Subject: [TUHS] Evolutionary Paths (was Gnu/Stallman (was Bugs in V6 'dcheck')) In-Reply-To: References: <201406020209.s5229Q5o006174@stowe.cs.dartmouth.edu> <59D01DBF-EF49-45B8-8F80-FA03E644A528@tfeb.org> <20140602144105.GO18282@mercury.ccil.org> <20140602194749.GA2463@behemoth> Message-ID: <57e9892e6ab11d0d12d0cea5bf6e8d6b.squirrel@webmail.yaccman.com> Well, I'm sure my biases are showing, but I see the Kernel as a means for supplying features for a model of computation, and the programming language as the delivery vehicle for that model of computation. And in my view, C/C++ is far more obsolete than Linux. Hardware has left software in the dust. It is quite feasible to produce a chip with 1000 or 10,000 processors on it, each with a bit of memory and a communication fabric. That's what tomorrow's technology is giving us. Multicore and named threads are just not going to cut it when using such a system. A central supplier of any service is a bottleneck. We've got to write our software to act more like an ant farm than a military hierarchy. Otherwise said, we have to learn to think different. Very different. And the hardest part of that is letting go of the old ways of thinking. Perhaps encroaching senility is help in this... Steve From lm at mcvoy.com Wed Jun 4 10:57:38 2014 From: lm at mcvoy.com (Larry McVoy) Date: Tue, 3 Jun 2014 17:57:38 -0700 Subject: [TUHS] unix history git In-Reply-To: References: <538CF53D.1090801@aueb.gr> Message-ID: <20140604005738.GE17402@mcvoy.com> > (As a reminder to list readers ... I am authoring a very detailed book > covering the history of Berkeley Unix. I have done interviews either by > email, phone, and some in person with over 80 of the very > early contributors.) Very interesting. Does your research extend into Sun? Because wnj went there and SunOS (not that Solaris stuff) was a "better BSD than BSD". mmap, vnodes, lots of very cool OS stuff happened at Sun that did not happen at Berkeley. No disrespect to Berkeley, they got the ball rolling, in some ways they were the Linux of the day, moving stuff forward while the rest of the world stalled. What was that Ken quote? Something about cat went to Berkeley and came back waving tails? Something like that? Whatever, I've been part of Unix dev for a long time and I'm painfully aware of the pushback that happens when people want to make things better. Berkeley made Unix better. Sun made it hugely better in my opinion. I was there at the tail end, you don't want to talk to me, you want to talk to wnj, rusty, moran, srk. They did some cool stuff. -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From lm at mcvoy.com Wed Jun 4 11:10:11 2014 From: lm at mcvoy.com (Larry McVoy) Date: Tue, 3 Jun 2014 18:10:11 -0700 Subject: [TUHS] Evolutionary Paths (was Gnu/Stallman (was Bugs in V6 'dcheck')) In-Reply-To: <57e9892e6ab11d0d12d0cea5bf6e8d6b.squirrel@webmail.yaccman.com> References: <59D01DBF-EF49-45B8-8F80-FA03E644A528@tfeb.org> <20140602144105.GO18282@mercury.ccil.org> <20140602194749.GA2463@behemoth> <57e9892e6ab11d0d12d0cea5bf6e8d6b.squirrel@webmail.yaccman.com> Message-ID: <20140604011011.GF17402@mcvoy.com> First, let me say how cool it is to be replying to the guy who did yacc. I've used it for decades, thank you for that. I was at SGI when they did the Origin servers, the architecture (as I remember it) was a board with 2 CPUS, some local memory, and an connection to a hypercube style of memory. An interesting aside is that this is where I learned that infinitely large packets in a network are infinitely stupid because you have to buffer a packet if the outgoing port is busy. I used to be a fan of big packets on ethernet, that system taught me that ethernet is just fine. The Origin "network" had ~32 byte packets. Buffering those was "easy". The problem with the lots-of-cpus design is that memory latency goes up. It was OK for local memory, it was not OK for remote memory. Don't get me wrong, SGI did a really great job at it, but when you compare a bunch of networked boxes with the SMP model SGI had, SGI won on jobs that needed shared memory, the bunch of networked boxes kicked ass on everything else. Cross reference: google. Intel's test harness. And a bunch of others. When you are benchmarking against a 10,000 node cluster and the cluster is winning, yeah, you need to rethink what you are doing. I've copied Greg Chesson, you guys should know him, he's ex Bell Labs, he can correct my ramblings, I worked for him at SGI. --lm On Tue, Jun 03, 2014 at 11:48:25AM -0700, scj at yaccman.com wrote: > Well, I'm sure my biases are showing, but I see the Kernel as a means for > supplying features for a model of computation, and the programming > language as the delivery vehicle for that model of computation. And in my > view, C/C++ is far more obsolete than Linux. > > Hardware has left software in the dust. It is quite feasible to produce a > chip with 1000 or 10,000 processors on it, each with a bit of memory and a > communication fabric. That's what tomorrow's technology is giving us. > Multicore and named threads are just not going to cut it when using such a > system. A central supplier of any service is a bottleneck. We've got to > write our software to act more like an ant farm than a military hierarchy. > > Otherwise said, we have to learn to think different. Very different. And > the hardest part of that is letting go of the old ways of thinking. > Perhaps encroaching senility is help in this... > > Steve From lars at nocrew.org Wed Jun 4 15:53:50 2014 From: lars at nocrew.org (Lars Brinkhoff) Date: Wed, 04 Jun 2014 07:53:50 +0200 Subject: [TUHS] unix history git In-Reply-To: <20140604005738.GE17402@mcvoy.com> (Larry McVoy's message of "Tue\, 3 Jun 2014 17\:57\:38 -0700") References: <538CF53D.1090801@aueb.gr> <20140604005738.GE17402@mcvoy.com> Message-ID: <85y4xdmd8x.fsf@junk.nocrew.org> Larry McVoy wrote: > What was that Ken quote? Something about cat went to Berkeley and > came back waving tails? Flags. From lm at mcvoy.com Thu Jun 5 00:31:45 2014 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 4 Jun 2014 07:31:45 -0700 Subject: [TUHS] SunOS 4.1.1 or later? Message-ID: <20140604143145.GA30260@mcvoy.com> Does anyone have that running on anything? If so, I'd like a copy of the lint libraries, probably /usr/lib/ll* or something like that. It's not well known but I spent a pile of time creating lint libraries for pure BSD, System V, etc, so you could lint your code against a target and know if you let some non-standard stuff creep in. I suppose I could fire up a Sun3 emulator like this and find them: http://www.abiyo.net/retrocomputing/installingsunos411tosun3emulatedintme08onlinux If someone has a SunOS 4.1.1 box on the net and can give me a login (non-root) that would be appreciated. Thanks, --lm From mah at mhorton.net Thu Jun 5 01:41:00 2014 From: mah at mhorton.net (Mary Ann Horton) Date: Wed, 04 Jun 2014 08:41:00 -0700 Subject: [TUHS] SunOS 4.1.3 In-Reply-To: <20140604143145.GA30260@mcvoy.com> References: <20140604143145.GA30260@mcvoy.com> Message-ID: <20140604084100.2019735cou0nxkp8@webmail.mhorton.net> I would love to find a CD or ISO of SunOS 4.1.3 (whichever was the latest before Solaris 2)? Thanks, Mary Ann From dds at aueb.gr Thu Jun 5 04:45:36 2014 From: dds at aueb.gr (Diomidis Spinellis) Date: Wed, 04 Jun 2014 21:45:36 +0300 Subject: [TUHS] unix history git In-Reply-To: References: <538CF53D.1090801@aueb.gr> Message-ID: <538F6950.9000909@aueb.gr> Thank you! I have committed your contribution through https://github.com/dspinellis/unix-history-make/commit/830221fb3d20395f723a584a48e3323ba400ffdb Regarding your questions, please see my responses below. Kind regards, Diomidis Spinellis On 03/06/2014 07:07, Jeremy C. Reed wrote: > On Tue, 3 Jun 2014, Diomidis Spinellis wrote: [...] >> 2. The login names of the following Berkeley authors >> A. R. Newton > > What code? 3bsd/usr/man/man1/spice.1:``Users Guide for Spice2'' by D. Dowell, A. R. Newton, >> Douglas Lanam > > What code? 3bsd/usr/man/man1/apl.1:Ken Thompson, Ross Harvey, Douglas Lanam >> Juan Porcar > > What specific code file for Juan Porcar? 3bsd/usr/src/sys/sys/makefile:# Virtual UNIX Mods by Ozalp Babaoglu, Bill Joy and Juan Porcar 3bsd/usr/src/sys/sys/makefile.bak:# Virtual UNIX Mods by Ozalp Babaoglu, Bill Joy and Juan Porcar 3bsd/usr/doc/vmunix/design.t:Juan Porcar From lm at mcvoy.com Thu Jun 5 05:18:27 2014 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 4 Jun 2014 12:18:27 -0700 Subject: [TUHS] SunOS 4.1.1 or later? In-Reply-To: <20140604143145.GA30260@mcvoy.com> References: <20140604143145.GA30260@mcvoy.com> Message-ID: <20140604191827.GA1461@mcvoy.com> I found 'em, thanks. On Wed, Jun 04, 2014 at 07:31:45AM -0700, Larry McVoy wrote: > Does anyone have that running on anything? If so, I'd like a copy of the > lint libraries, probably /usr/lib/ll* or something like that. > > It's not well known but I spent a pile of time creating lint libraries for > pure BSD, System V, etc, so you could lint your code against a target and > know if you let some non-standard stuff creep in. > > I suppose I could fire up a Sun3 emulator like this and find them: > > http://www.abiyo.net/retrocomputing/installingsunos411tosun3emulatedintme08onlinux > > If someone has a SunOS 4.1.1 box on the net and can give me a login (non-root) > that would be appreciated. > > Thanks, > > --lm > _______________________________________________ > TUHS mailing list > TUHS at minnie.tuhs.org > https://minnie.tuhs.org/mailman/listinfo/tuhs -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From lm at mcvoy.com Thu Jun 5 10:43:58 2014 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 4 Jun 2014 17:43:58 -0700 Subject: [TUHS] Evolutionary Paths (was Gnu/Stallman (was Bugs in V6 'dcheck')) In-Reply-To: References: <20140602144105.GO18282@mercury.ccil.org> <20140602194749.GA2463@behemoth> <57e9892e6ab11d0d12d0cea5bf6e8d6b.squirrel@webmail.yaccman.com> <20140604011011.GF17402@mcvoy.com> Message-ID: <20140605004358.GD3313@mcvoy.com> Hey Greg, It's "tuhs" not "tubs" and it stands for The Unix Historical Society so far as I know. Lots of Bell Labs and other folks on the list, it's a fun walk down memory lane, you should join. What started the conversation was someone musing on whether Linux is the end of OS development. Steve was talking about problems that SGI worked on so I wanted to point out that there might be something to mine there. --lm On Tue, Jun 03, 2014 at 08:42:56PM -0700, Greg Chesson wrote: > Hi, > > I certainly know scj from Murray Hill. Not sure who is tubs. > > Distributed and parallel hardware has evolved far beyond the ability > of most sw. Everyone agrees, I think; and, GPUs just make it more so. > > On the other hand, cpu architecture remains classic Von Neumann > with registers, alus, and familiar memory hierarchies. Close to the > hardware where instructions are visible, there is not much change. > And I think there are compelling technical reasons on why that > is so as a consequence of digital logic and transistor circuitry > and electrical signalling. C/C++ remains a good fit at that level > because it is still a reflection of the hardware. > > I agree with Steve - and so would Ken as I have heard him say > it several times going back many years - the kernel is basically > a multiplexor for memory, io, and time. What happens above that > in terms of data representation and anything like intelligence > is a higher-order function and demands higher-order programming > than what works for most kernel tasks. I use the term "higher-order" > in the same sense that Church's type theory (lambda calculus) > is higher order than first order predicate logic. > > I've always liked what Knuth wrote long ago about the evolution > of programming languages. He observed that languages > have evolved first from binary, to assembly language, and > then jumped to Fortran because programmers who found > they were writing the same kind of stuff over and over, > sometimes in the same program, looked for ways to express > more with less. That still happens today and will continue. > > But wait, there's more. > Imagine what would be needed to implement a human brain model > with something like 10^11 neurons and 10^14 connections. > Out of reach today. > > People are just now trying to emulate the 302 neurons in the nervous > system of Caenorhabditis elegans. C/C++ and Von Neumann cpus > are not a good match for such problems - and there are many > computations (and searches) of stupendous enormous scale that would dwarf > any supercomputer in the planning stages today. > > I hope I get to see some of what comes next, and maybe even > help carry forward a few building blocks. > > What started this conversation? > > Greg > > > On Tue, Jun 3, 2014 at 6:10 PM, Larry McVoy wrote: > > > First, let me say how cool it is to be replying to the guy who did yacc. > > I've used it for decades, thank you for that. > > > > I was at SGI when they did the Origin servers, the architecture (as I > > remember it) was a board with 2 CPUS, some local memory, and an connection > > to a hypercube style of memory. An interesting aside is that this is > > where I learned that infinitely large packets in a network are infinitely > > stupid because you have to buffer a packet if the outgoing port is busy. > > I used to be a fan of big packets on ethernet, that system taught me > > that ethernet is just fine. The Origin "network" had ~32 byte packets. > > Buffering those was "easy". > > > > The problem with the lots-of-cpus design is that memory latency goes up. > > It was OK for local memory, it was not OK for remote memory. Don't get > > me wrong, SGI did a really great job at it, but when you compare a bunch > > of networked boxes with the SMP model SGI had, SGI won on jobs that needed > > shared memory, the bunch of networked boxes kicked ass on everything else. > > Cross reference: google. Intel's test harness. And a bunch of others. > > When you are benchmarking against a 10,000 node cluster and the cluster > > is winning, yeah, you need to rethink what you are doing. > > > > I've copied Greg Chesson, you guys should know him, he's ex Bell Labs, > > he can correct my ramblings, I worked for him at SGI. > > > > --lm > > > > On Tue, Jun 03, 2014 at 11:48:25AM -0700, scj at yaccman.com wrote: > > > Well, I'm sure my biases are showing, but I see the Kernel as a means for > > > supplying features for a model of computation, and the programming > > > language as the delivery vehicle for that model of computation. And in > > my > > > view, C/C++ is far more obsolete than Linux. > > > > > > Hardware has left software in the dust. It is quite feasible to produce > > a > > > chip with 1000 or 10,000 processors on it, each with a bit of memory and > > a > > > communication fabric. That's what tomorrow's technology is giving us. > > > Multicore and named threads are just not going to cut it when using such > > a > > > system. A central supplier of any service is a bottleneck. We've got to > > > write our software to act more like an ant farm than a military > > hierarchy. > > > > > > Otherwise said, we have to learn to think different. Very different. > > And > > > the hardest part of that is letting go of the old ways of thinking. > > > Perhaps encroaching senility is help in this... > > > > > > Steve > > -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From arno.griffioen at ieee.org Thu Jun 5 17:31:12 2014 From: arno.griffioen at ieee.org (Arno Griffioen) Date: Thu, 5 Jun 2014 09:31:12 +0200 Subject: [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck') In-Reply-To: <20140602142446.GM18282@mercury.ccil.org> References: <201406020209.s5229Q5o006174@stowe.cs.dartmouth.edu> <20140602142446.GM18282@mercury.ccil.org> Message-ID: <20140605073112.GD10373@attic.nerdnet.nl> On Mon, Jun 02, 2014 at 10:24:48AM -0400, John Cowan wrote: > Ronald Natalie scripsit: > > > Still with all it's flaws, on the 286 and later UNIX actually did run in > > protected mode, something it took ages for DOS/Windows (one can argue > > backwards compatibility with the early processors) or Apple (no excuse > > here, the early Macs were 68000's which had protection) to pick up upon. > > The original Mac 128K was a 68000 processor, and IIRC memory protection > didn't arrive until the 68020. As mentioned by others the 68010 could, with additional external hardware, support memory management. The original 68000 (and 8-bit data bus 68008) did already have the full 32 bit instruction and data support of the complete family, but for MMU use it lacked one critical feature in the fact that it did not push enough page-fault information on the stack to re-start an instruction in case of an (externally signalled) page-fault. So even if you interfaced external MMU logic then a basic 68000 was still in trouble when a page fault occurred as it could not 'start over' the faulted instruction. The 68010 added the correct stack frames to be able to restart a faulted instruction and also added the first small performance enhancement in the form of a 'loop mode' where the CPU could basically cache a small loop and execute this without incurring addtional memory wait cycles. As a result the '010 was usually used in various *NIX machines of the era like some SUN2's and various machines (one-offs or low production) from other brands. Eg. I still have a machine in my collection which is from a small local production run that utilises an '010 with a custom, but quite rudimentary, MMU based on some simple logic chips and it used to run SVR2. Very slowly as it had a whopping 1 Mbyte of RAM and the MMU could give you a virtual memory size of 4 Mbyte. I did port MINIX to it and added memory management/protection support to the kernel. Ran a lot faster :) With the release of the '020 Motorola delivered their own full-blown (but still external) MMU in the shape of the MC68851 Many non-UNIX '020 based machines of the era did not have the MC68851 on board at all (eg. most Apples from the time) as it was relatively expensive and could incur extra memory latency/cycles being an external unit. With the '030 Motorola finally moved the MMU onto the same die as the CPU (reducing the latency and cost) and it became more prevalent on more platforms (although the cheaper 68EC030 was available without an MMU and used in many machines) Bringing this back to UNIX, I used to do some local supporting work at CBM for the Commodore UNIX'es that were Amiga, and of course M68k based. The official Amiga 2000 '020 turboboard (or one of the A2500UX'es like I have at home :) ) does have both the MC68851 MMU and the MC68881 FPU and these were used for a, mostly in-house at CBM, SVR3.2 based UNIX version. AmigaDOS of course also ran fine on it, but did not use the MMU. The later, general release, SVR4 UNIX version was desgined to run on the '030 based A3000UX'es, although it still ran on the '020+MMU cards in their limited (4Mb) DRAM. Bye, Arno. From emu at e-bbes.com Thu Jun 5 18:24:22 2014 From: emu at e-bbes.com (emu at e-bbes.com) Date: Thu, 05 Jun 2014 10:24:22 +0200 Subject: [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck') In-Reply-To: <20140605073112.GD10373@attic.nerdnet.nl> References: <201406020209.s5229Q5o006174@stowe.cs.dartmouth.edu> <20140602142446.GM18282@mercury.ccil.org> <20140605073112.GD10373@attic.nerdnet.nl> Message-ID: <20140605102422.gzf106rf5moc88c0@webmail.opentransfer.com> Zitat von Arno Griffioen : > As a result the '010 was usually used in various *NIX machines of the > era like some SUN2's and various machines (one-offs or low production) > from other brands. One "nice" machine, which actually ran Unix on the 68010 was: http://en.wikipedia.org/wiki/AT%26T_Unix_PC From wes.parish at paradise.net.nz Thu Jun 5 19:17:04 2014 From: wes.parish at paradise.net.nz (Wesley Parish) Date: Thu, 05 Jun 2014 21:17:04 +1200 (NZST) Subject: [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck') In-Reply-To: <20140605073112.GD10373@attic.nerdnet.nl> References: <201406020209.s5229Q5o006174@stowe.cs.dartmouth.edu> <20140602142446.GM18282@mercury.ccil.org> <20140605073112.GD10373@attic.nerdnet.nl> Message-ID: <1401959824.53903590d25f5@www.paradise.net.nz> Which of course raises the question: how did AmigaDOS manage context switches and the like for its brand of multitasking? I know BYTE explained it in the early 1990s, but I threw away all my BYTEs a couple of decades ago, and don't remember the details. Thanks Wesley Parish Quoting Arno Griffioen : > On Mon, Jun 02, 2014 at 10:24:48AM -0400, John Cowan wrote: > > Ronald Natalie scripsit: > > > > > Still with all it's flaws, on the 286 and later UNIX actually did > run in > > > protected mode, something it took ages for DOS/Windows (one can > argue > > > backwards compatibility with the early processors) or Apple (no > excuse > > > here, the early Macs were 68000's which had protection) to pick up > upon. > > > > The original Mac 128K was a 68000 processor, and IIRC memory > protection > > didn't arrive until the 68020. > > As mentioned by others the 68010 could, with additional external > hardware, > support memory management. > > The original 68000 (and 8-bit data bus 68008) did already have the full > 32 > bit instruction and data support of the complete family, but for MMU use > it > lacked one critical feature in the fact that it did not push enough > page-fault > information on the stack to re-start an instruction in case of an > (externally > signalled) page-fault. > > So even if you interfaced external MMU logic then a basic 68000 was > still in > trouble when a page fault occurred as it could not 'start over' the > faulted instruction. > > The 68010 added the correct stack frames to be able to restart a > faulted > instruction and also added the first small performance enhancement in > the > form of a 'loop mode' where the CPU could basically cache a small loop > and execute this without incurring addtional memory wait cycles. > > As a result the '010 was usually used in various *NIX machines of the > era like some SUN2's and various machines (one-offs or low production) > from other brands. > > Eg. I still have a machine in my collection which is from a small local > > production run that utilises an '010 with a custom, but quite > rudimentary, > MMU based on some simple logic chips and it used to run SVR2. Very > slowly > as it had a whopping 1 Mbyte of RAM and the MMU could give you a virtual > > memory size of 4 Mbyte. > > I did port MINIX to it and added memory management/protection support to > > the kernel. Ran a lot faster :) > > With the release of the '020 Motorola delivered their own full-blown > (but > still external) MMU in the shape of the MC68851 > > Many non-UNIX '020 based machines of the era did not have the MC68851 on > > board at all (eg. most Apples from the time) as it was relatively > expensive > and could incur extra memory latency/cycles being an external unit. > > With the '030 Motorola finally moved the MMU onto the same die as the > CPU > (reducing the latency and cost) and it became more prevalent on more > platforms (although the cheaper 68EC030 was available without an MMU and > > used in many machines) > > Bringing this back to UNIX, I used to do some local supporting work at > CBM for > the Commodore UNIX'es that were Amiga, and of course M68k based. > > The official Amiga 2000 '020 turboboard (or one of the A2500UX'es like I > have > at home :) ) does have both the MC68851 MMU and the MC68881 FPU and > these > were used for a, mostly in-house at CBM, SVR3.2 based UNIX version. > > AmigaDOS of course also ran fine on it, but did not use the MMU. > > The later, general release, SVR4 UNIX version was desgined to run on > the > '030 based A3000UX'es, although it still ran on the '020+MMU cards in > their > limited (4Mb) DRAM. > > Bye, Arno. > _______________________________________________ > TUHS mailing list > TUHS at minnie.tuhs.org > https://minnie.tuhs.org/mailman/listinfo/tuh s > From brantley at coraid.com Thu Jun 5 21:26:05 2014 From: brantley at coraid.com (Brantley Coile) Date: Thu, 5 Jun 2014 11:26:05 +0000 Subject: [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck') In-Reply-To: <1401959824.53903590d25f5@www.paradise.net.nz> References: <201406020209.s5229Q5o006174@stowe.cs.dartmouth.edu> <20140602142446.GM18282@mercury.ccil.org> <20140605073112.GD10373@attic.nerdnet.nl>, <1401959824.53903590d25f5@www.paradise.net.nz> Message-ID: <1968586D-53E6-4C90-A844-E975FA6FA5AF@coraid.com> I ported Unix to the 68000 in the early 1980's and I did what I assume AmigoDOS did; getting a page fault for anything but a stack frame access was fatal to the process. In other worlds, no paging-in a process. The problem for paging was handling side effects from auto increment or decrement access modes. If the faulting instruction used one of those modes, the 68000 didn't provide enough information to do what we did on PDP-11's and simulate the faulted instruction. Nor could it automatically restart the instruction, which was done in the 68010. A process had to be loaded completely before being swtch'ed to, just like in 32v. This left only the fault resulting from the stack meeting to grow. To solve for that problem, we solicited help from the compiler. The function prologue of every function would fetch the farthest used word from the frame pointer. In most cases this would do nothing. For a frame that needed more stack allocated, this would cause a page fault. We looked at the instruction at the faulted program counter, verified it was a "grow me" instruction, allocated more core and put the process back on the run queue. The result of the instruction was ignored, so we didn't need to have the kernel restart it or simulate it. This method wasn't original to me. It was common practice at the time. I assume this the technique used by AmigaDOS. Sent from my iPad > On Jun 5, 2014, at 5:33 AM, "Wesley Parish" wrote: > > Which of course raises the question: how did AmigaDOS manage context switches > and the like for its brand of multitasking? I know BYTE explained it in the > early 1990s, but I threw away all my BYTEs a couple of decades ago, and don't > remember the details. > > Thanks > > Wesley Parish > > Quoting Arno Griffioen : > >>> On Mon, Jun 02, 2014 at 10:24:48AM -0400, John Cowan wrote: >>> Ronald Natalie scripsit: >>> >>>> Still with all it's flaws, on the 286 and later UNIX actually did >> run in >>>> protected mode, something it took ages for DOS/Windows (one can >> argue >>>> backwards compatibility with the early processors) or Apple (no >> excuse >>>> here, the early Macs were 68000's which had protection) to pick up >> upon. >>> >>> The original Mac 128K was a 68000 processor, and IIRC memory >> protection >>> didn't arrive until the 68020. >> >> As mentioned by others the 68010 could, with additional external >> hardware, >> support memory management. >> >> The original 68000 (and 8-bit data bus 68008) did already have the full >> 32 >> bit instruction and data support of the complete family, but for MMU use >> it >> lacked one critical feature in the fact that it did not push enough >> page-fault >> information on the stack to re-start an instruction in case of an >> (externally >> signalled) page-fault. >> >> So even if you interfaced external MMU logic then a basic 68000 was >> still in >> trouble when a page fault occurred as it could not 'start over' the >> faulted instruction. >> >> The 68010 added the correct stack frames to be able to restart a >> faulted >> instruction and also added the first small performance enhancement in >> the >> form of a 'loop mode' where the CPU could basically cache a small loop >> and execute this without incurring addtional memory wait cycles. >> >> As a result the '010 was usually used in various *NIX machines of the >> era like some SUN2's and various machines (one-offs or low production) >> from other brands. >> >> Eg. I still have a machine in my collection which is from a small local >> >> production run that utilises an '010 with a custom, but quite >> rudimentary, >> MMU based on some simple logic chips and it used to run SVR2. Very >> slowly >> as it had a whopping 1 Mbyte of RAM and the MMU could give you a virtual >> >> memory size of 4 Mbyte. >> >> I did port MINIX to it and added memory management/protection support to >> >> the kernel. Ran a lot faster :) >> >> With the release of the '020 Motorola delivered their own full-blown >> (but >> still external) MMU in the shape of the MC68851 >> >> Many non-UNIX '020 based machines of the era did not have the MC68851 on >> >> board at all (eg. most Apples from the time) as it was relatively >> expensive >> and could incur extra memory latency/cycles being an external unit. >> >> With the '030 Motorola finally moved the MMU onto the same die as the >> CPU >> (reducing the latency and cost) and it became more prevalent on more >> platforms (although the cheaper 68EC030 was available without an MMU and >> >> used in many machines) >> >> Bringing this back to UNIX, I used to do some local supporting work at >> CBM for >> the Commodore UNIX'es that were Amiga, and of course M68k based. >> >> The official Amiga 2000 '020 turboboard (or one of the A2500UX'es like I >> have >> at home :) ) does have both the MC68851 MMU and the MC68881 FPU and >> these >> were used for a, mostly in-house at CBM, SVR3.2 based UNIX version. >> >> AmigaDOS of course also ran fine on it, but did not use the MMU. >> >> The later, general release, SVR4 UNIX version was desgined to run on >> the >> '030 based A3000UX'es, although it still ran on the '020+MMU cards in >> their >> limited (4Mb) DRAM. >> >> Bye, Arno. >> _______________________________________________ >> TUHS mailing list >> TUHS at minnie.tuhs.org >> https://minnie.tuhs.org/mailman/listinfo/tuh s > > _______________________________________________ > TUHS mailing list > TUHS at minnie.tuhs.org > https://minnie.tuhs.org/mailman/listinfo/tuhs From jcea at jcea.es Thu Jun 5 23:34:31 2014 From: jcea at jcea.es (Jesus Cea) Date: Thu, 05 Jun 2014 15:34:31 +0200 Subject: [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck') In-Reply-To: <1968586D-53E6-4C90-A844-E975FA6FA5AF@coraid.com> References: <201406020209.s5229Q5o006174@stowe.cs.dartmouth.edu> <20140602142446.GM18282@mercury.ccil.org> <20140605073112.GD10373@attic.nerdnet.nl>, <1401959824.53903590d25f5@www.paradise.net.nz> <1968586D-53E6-4C90-A844-E975FA6FA5AF@coraid.com> Message-ID: <539071E7.9040807@jcea.es> On 05/06/14 13:26, Brantley Coile wrote: > This method wasn't original to me. It was common practice at the > time. I assume this the technique used by AmigaDOS. I have no direct knowledge of AmigaDOS, but since there was no hardware protection between processes and all processes shared the same address space, context switching COULD BE just "store process registers, including stack pointer and Program Counter, for process A", "restore process registers, including stack pointer and program counter from process B". Certainly I did this in the 8 bit era (well, 6502 CPU have the stack in a fixed position but only just 256 bytes long, so I just copy it around when doing context switching) and in Atari ST (68000 based computer). -- Jesús Cea Avión _/_/ _/_/_/ _/_/_/ jcea at jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/ Twitter: @jcea _/_/ _/_/ _/_/_/_/_/ jabber / xmpp:jcea at jabber.org _/_/ _/_/ _/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/ "My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 538 bytes Desc: OpenPGP digital signature URL: From clemc at ccc.com Fri Jun 6 01:07:44 2014 From: clemc at ccc.com (Clem Cole) Date: Thu, 5 Jun 2014 11:07:44 -0400 Subject: [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck') In-Reply-To: <20140605073112.GD10373@attic.nerdnet.nl> References: <201406020209.s5229Q5o006174@stowe.cs.dartmouth.edu> <20140602142446.GM18282@mercury.ccil.org> <20140605073112.GD10373@attic.nerdnet.nl> Message-ID: On Thu, Jun 5, 2014 at 3:31 AM, Arno Griffioen ‪ wrote: The original 68000 (and 8-bit data bus 68008) did already have the full 32 bit instruction and data support of the complete family, But the original 68000 was actually a 16 bit internal architecture -- is was made with a 16 bit barrel shifter and any 32 bit op took two ticks. Yes, they (fortunately) did define the 32 bit data types and many of the 32 bit operations. There was an argument at the time was it a 16 bit or 32 bit chip and between people implementing compilers - should a C "int" be 16 bits or 32. Since I had hacked the Ritchie PDP-11 compiler for mine, I used 16 bits, while the MIT guys used 32 (I think they were hacking on Steve's if my memory is correct). The advantage of the later was int == ptr and that the time V6 and V7 was definitely pointer "dirty" the worst example being the Bourne shell and how break(2) was implemented. The advantage of the former was it was the natural size of the chip internals and so it made it easier for me to generate "optimal" (well let's just say "better") code plus that's what's Dennis's compiler "knew." Jeff Mogul ended up at Stanford around that time. He and I had a long argument about it when we first met. We each we sure the other was wrong - :-0 Years later when we became colleagues we reminded of the old argument, I think we agreed that other was "right." It was a tough choice and there were good arguments on both sides. BTW: I once asked Les about it during our Stellar time. He said they thought of it as a 16 bit chip - a PDP-11 like system without running into the problem that Cal Data did with "cloning" the 11. Les and team has been using PDP-11's before they joined Moto. But the reality is that UNIX code really wanted int==ptr for a long time [as well as: ptr = 0; *ptr == 0]. That really was not forced to be fixed until Alpha came on the scene and people cleaned up there code. but for MMU use it ​ ​ lacked one critical feature in the fact that it did not push enough page-fault information on the stack to re-start an instruction in case of an (externally ​ ​ signalled) page-fault. True that the original 68000 lacked the instruction restart ability, but the MMU could be made to not need restart. So even if you interfaced external MMU logic then a basic 68000 was still in ​ ​ trouble when a page fault occurred as it could not 'start over' the ​ ​ faulted instruction. As I said this is not completely true - you just never stopped the instruction. The fact is that a 68000 could do VM, but it took a bit of work a external logic. Forest Basket wrote a paper on how to do it and it was actually what both Apollo and Masscomp implemented in this first products. The trick was that the 68000 "CPU" could not complete the instruction when the fault occurred (or as you mentioned - the reason was that bad things happened was because the microcode did not correctly save the internal instruction state). So the "executor" 68000 CPU was sent wait states by the MMU -- in effect forcing it to have a very slow memory read. While it was waiting for the memory to fill, the fault had to be handled by something else. In Masscomp's case (and I believe Apollo also) the "fixer" was another second 68000 that ran in kernel code that handled the fault and refilled the MMU's TLB (or if you we schooled by Digital - the "TB"). At the time Dave Cane and Jeff ??? ( the logic designer sat Masscomp - Jeff's last name now escapes me) had been from the 11/34 and VAX projects previously. They were horrified to have to use a second processor just for memory refills, and spent weeks trying to find a way out but eventually relented to what the SW guys where telling them. As I said, when the '010 came out, Masscomp retrofitted the CPU card to allow the fault to occur and not wait state the CPU. The RTU kernel detected the actual chip being used, and when it was running on a ' 010, would immediately do a task switch on the executor and run some other code, while the fixer handled the fault. I've forgotten now, but my memory is that the fixer always ran out of the cache. BTW: the '010 originally still had VM issues that did not get fixed until the '020. The way Moto handled the fault was to dump the state of the internal microcode to the CPU stack, and when the instruction was restarted, was to suck the state back into the processor. The problem was that as that Moto was updating the microcode in manufacturing not thinking it was an issues for customers a processor with the step logic stepping might have different microcode - which was not a problem for 99% of their customers. However, Masscomp actually made the first dual processor UNIX box - the MC-500/DP which was released about 12 months after the MC-500 (they predated Sequent by about 2-3 years). A couple of months after we started shipping the DP, we started to see a strange failure in the field. The issues was that a fault would occur on one CPU and the kernel would try to restart to the instruction on a different processor, and unless both CPU boards had executor chips from the same manufacturing lot - you had to restart in the same physical chip that took the fault. Because the original RTU DP system was modeled on the Goble Vax, were kernel mode was on one processor at a time and the original DP had a NUMA memory system (the 5000 was SMP with UMA memory). Thus usually, processes tended to get started on one processor and not migrate to the other, but under they could migrate. All the test systems in engineering had matched processors - no problem. But when field service started to swap boards, around at customer sites, bad things started to happen. We had quite the panic figuring out what it was and then forced field service to ensure all CPU cards were matched -- what a pain in the tuckus. With the 5000 when we went full SMP, we screamed at Moto and got them to clean up their act so that what was dumped on the stack could be restarted on any '020 regardless of stepping/microcode etc. Clem -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron at ronnatalie.com Fri Jun 6 04:26:38 2014 From: ron at ronnatalie.com (Ronald Natalie) Date: Thu, 5 Jun 2014 14:26:38 -0400 Subject: [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck') In-Reply-To: References: <201406020209.s5229Q5o006174@stowe.cs.dartmouth.edu> <20140602142446.GM18282@mercury.ccil.org> <20140605073112.GD10373@attic.nerdnet.nl> Message-ID: On Jun 5, 2014, at 11:07 AM, Clem Cole wrote: > We had quite the panic figuring out what it was and then forced field service to ensure all CPU cards were matched -- what a pain in the tuckus. With the 5000 when we went full SMP, we screamed at Moto and got them to clean up their act so that what was dumped on the stack could be restarted on any '020 regardless of stepping/microcode etc. > Sounds like our fun with Intel and their i860 RISC chips. Every chip stepping had it's own "INTEL PROPRIETARY" errata which had fun things like "A store followed by any number of instructions and then a load from the same location may ...." I loved the fact that Intel didn't think it was a good idea to tell people what they had to do to make the chips work. Even when we got the Errata, they were sometimes wrong. I spent a lot of time when stuck calling my contact at the factory and making discrete inquiries which led to things like: Intel: Remember those two NOP instructions we told you to put at the beginning of the ISR? Me: Yes, but the errata sheet says that ceased to be necessary after the B2 stepping of the chip. Intel: Well put them back and perhaps five or six more. Of course they weren't as bad as dealing with some aspects of IBM at the time. Me: There's a bug in the driver for this card. IBM: That's not possible, it's product. Oh, excuse me....there can't possibly be problems in the released product. -------------- next part -------------- An HTML attachment was scrubbed... URL: From xtp at google.com Wed Jun 4 13:42:56 2014 From: xtp at google.com (Greg Chesson) Date: Tue, 3 Jun 2014 20:42:56 -0700 Subject: [TUHS] Evolutionary Paths (was Gnu/Stallman (was Bugs in V6 'dcheck')) In-Reply-To: <20140604011011.GF17402@mcvoy.com> References: <59D01DBF-EF49-45B8-8F80-FA03E644A528@tfeb.org> <20140602144105.GO18282@mercury.ccil.org> <20140602194749.GA2463@behemoth> <57e9892e6ab11d0d12d0cea5bf6e8d6b.squirrel@webmail.yaccman.com> <20140604011011.GF17402@mcvoy.com> Message-ID: Hi, I certainly know scj from Murray Hill. Not sure who is tubs. Distributed and parallel hardware has evolved far beyond the ability of most sw. Everyone agrees, I think; and, GPUs just make it more so. On the other hand, cpu architecture remains classic Von Neumann with registers, alus, and familiar memory hierarchies. Close to the hardware where instructions are visible, there is not much change. And I think there are compelling technical reasons on why that is so as a consequence of digital logic and transistor circuitry and electrical signalling. C/C++ remains a good fit at that level because it is still a reflection of the hardware. I agree with Steve - and so would Ken as I have heard him say it several times going back many years - the kernel is basically a multiplexor for memory, io, and time. What happens above that in terms of data representation and anything like intelligence is a higher-order function and demands higher-order programming than what works for most kernel tasks. I use the term "higher-order" in the same sense that Church's type theory (lambda calculus) is higher order than first order predicate logic. I've always liked what Knuth wrote long ago about the evolution of programming languages. He observed that languages have evolved first from binary, to assembly language, and then jumped to Fortran because programmers who found they were writing the same kind of stuff over and over, sometimes in the same program, looked for ways to express more with less. That still happens today and will continue. But wait, there's more. Imagine what would be needed to implement a human brain model with something like 10^11 neurons and 10^14 connections. Out of reach today. People are just now trying to emulate the 302 neurons in the nervous system of Caenorhabditis elegans. C/C++ and Von Neumann cpus are not a good match for such problems - and there are many computations (and searches) of stupendous enormous scale that would dwarf any supercomputer in the planning stages today. I hope I get to see some of what comes next, and maybe even help carry forward a few building blocks. What started this conversation? Greg On Tue, Jun 3, 2014 at 6:10 PM, Larry McVoy wrote: > First, let me say how cool it is to be replying to the guy who did yacc. > I've used it for decades, thank you for that. > > I was at SGI when they did the Origin servers, the architecture (as I > remember it) was a board with 2 CPUS, some local memory, and an connection > to a hypercube style of memory. An interesting aside is that this is > where I learned that infinitely large packets in a network are infinitely > stupid because you have to buffer a packet if the outgoing port is busy. > I used to be a fan of big packets on ethernet, that system taught me > that ethernet is just fine. The Origin "network" had ~32 byte packets. > Buffering those was "easy". > > The problem with the lots-of-cpus design is that memory latency goes up. > It was OK for local memory, it was not OK for remote memory. Don't get > me wrong, SGI did a really great job at it, but when you compare a bunch > of networked boxes with the SMP model SGI had, SGI won on jobs that needed > shared memory, the bunch of networked boxes kicked ass on everything else. > Cross reference: google. Intel's test harness. And a bunch of others. > When you are benchmarking against a 10,000 node cluster and the cluster > is winning, yeah, you need to rethink what you are doing. > > I've copied Greg Chesson, you guys should know him, he's ex Bell Labs, > he can correct my ramblings, I worked for him at SGI. > > --lm > > On Tue, Jun 03, 2014 at 11:48:25AM -0700, scj at yaccman.com wrote: > > Well, I'm sure my biases are showing, but I see the Kernel as a means for > > supplying features for a model of computation, and the programming > > language as the delivery vehicle for that model of computation. And in > my > > view, C/C++ is far more obsolete than Linux. > > > > Hardware has left software in the dust. It is quite feasible to produce > a > > chip with 1000 or 10,000 processors on it, each with a bit of memory and > a > > communication fabric. That's what tomorrow's technology is giving us. > > Multicore and named threads are just not going to cut it when using such > a > > system. A central supplier of any service is a bottleneck. We've got to > > write our software to act more like an ant farm than a military > hierarchy. > > > > Otherwise said, we have to learn to think different. Very different. > And > > the hardest part of that is letting go of the old ways of thinking. > > Perhaps encroaching senility is help in this... > > > > Steve > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mparson at bl.org Wed Jun 11 22:10:17 2014 From: mparson at bl.org (Michael Parson) Date: Wed, 11 Jun 2014 07:10:17 -0500 (CDT) Subject: [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck') In-Reply-To: <1401959824.53903590d25f5@www.paradise.net.nz> References: <201406020209.s5229Q5o006174@stowe.cs.dartmouth.edu> <20140602142446.GM18282@mercury.ccil.org> <20140605073112.GD10373@attic.nerdnet.nl> <1401959824.53903590d25f5@www.paradise.net.nz> Message-ID: On Thu, 5 Jun 2014, Wesley Parish wrote: > Which of course raises the question: how did AmigaDOS manage context switches > and the like for its brand of multitasking? I know BYTE explained it in the > early 1990s, but I threw away all my BYTEs a couple of decades ago, and don't > remember the details. If you want to re-read the original article: https://archive.org/details/BYTE_Vol_10-08_1985-08_The_Amiga -- Michael Parson Austin, TX KF5LGQ From wes.parish at paradise.net.nz Thu Jun 12 11:20:39 2014 From: wes.parish at paradise.net.nz (Wesley Parish) Date: Thu, 12 Jun 2014 13:20:39 +1200 (NZST) Subject: [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck') In-Reply-To: References: <201406020209.s5229Q5o006174@stowe.cs.dartmouth.edu> <20140602142446.GM18282@mercury.ccil.org> <20140605073112.GD10373@attic.nerdnet.nl> <1401959824.53903590d25f5@www.paradise.net.nz> Message-ID: <1402536039.5399006719ff4@www.paradise.net.nz> Thanks. Will do. Quoting Michael Parson : > On Thu, 5 Jun 2014, Wesley Parish wrote: > > > Which of course raises the question: how did AmigaDOS manage context > switches > > and the like for its brand of multitasking? I know BYTE explained it > in the > > early 1990s, but I threw away all my BYTEs a couple of decades ago, > and don't > > remember the details. > > If you want to re-read the original article: > > https://archive.org/details/BYTE_Vol_10-08_1985-08_The_Amiga > > -- > Michael Parson > Austin, TX > KF5LGQ > _______________________________________________ > TUHS mailing list > TUHS at minnie.tuhs.org > https://minnie.tuhs.org/mailman/listinfo/tuh s > From slapinid at gmail.com Thu Jun 12 13:10:16 2014 From: slapinid at gmail.com (Sergey Lapin) Date: Thu, 12 Jun 2014 07:10:16 +0400 Subject: [TUHS] UNIX magazines Message-ID: Hi, all! I've read recently published link to byte article and got an idea.... Was there a magazine related to UNIX systems in 70s-80s? I had so much fun reading that Byte issue, even ads (especially ads!) It is so fun... -------------- next part -------------- An HTML attachment was scrubbed... URL: From dscherrer at solar.stanford.edu Thu Jun 12 13:38:42 2014 From: dscherrer at solar.stanford.edu (Deborah Scherrer) Date: Wed, 11 Jun 2014 20:38:42 -0700 Subject: [TUHS] UNIX magazines In-Reply-To: References: Message-ID: <539920C2.8050409@solar.stanford.edu> Oh yes, there was Unix Review, and several others. Unix Review was special in that the editor chose to set up an Editorial Board by inviting key people in the Unix field, e.g. John Mashey, Steve Bourne, etc., to direct and comment upon editorial content (in a volunteer, as opposed to paid, fashion). The group met once a month at Chantilly, a posh restaurant in Palo Alto. Deborah On 6/11/14 8:10 PM, Sergey Lapin wrote: > Hi, all! > > I've read recently published link to byte article and got an idea.... > Was there a magazine related to UNIX systems in 70s-80s? > I had so much fun reading that Byte issue, even ads (especially ads!) > It is so fun... > > > _______________________________________________ > TUHS mailing list > TUHS at minnie.tuhs.org > https://minnie.tuhs.org/mailman/listinfo/tuhs -------------- next part -------------- An HTML attachment was scrubbed... URL: From downing.nick at gmail.com Thu Jun 12 13:46:56 2014 From: downing.nick at gmail.com (Nick Downing) Date: Thu, 12 Jun 2014 13:46:56 +1000 Subject: [TUHS] UNIX magazines In-Reply-To: References: Message-ID: hehe my thoughts too..like a time machine :) On 12/06/2014 1:11 PM, "Sergey Lapin" wrote: > Hi, all! > > I've read recently published link to byte article and got an idea.... > Was there a magazine related to UNIX systems in 70s-80s? > I had so much fun reading that Byte issue, even ads (especially ads!) > It is so fun... > > _______________________________________________ > TUHS mailing list > TUHS at minnie.tuhs.org > https://minnie.tuhs.org/mailman/listinfo/tuhs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From crossd at gmail.com Thu Jun 12 13:59:04 2014 From: crossd at gmail.com (Dan Cross) Date: Wed, 11 Jun 2014 23:59:04 -0400 Subject: [TUHS] UNIX magazines In-Reply-To: References: Message-ID: There were several, starting I guess in the 80s mostly. The one I remember in particular was "Unix Review", but there were a few "journal" type magazines that also specialized in Unix-y things (e.g., ";login:" from USENIX; still published, I believe), and several associated with particular vendors: "SunExpert" was one, if I recall correctly. Occasionally, Unix and related things showed up in the "mainstream" consumer computer press of the time. I can remember in particular an issue of "PC Magazine" (I think June of 1993) that ran a lengthy couple of articles proving machines from Sun and SGI, in addition to version of Unix that ran on PCs (interestingly, Linux was omitted despite really starting to capture a lot of the imagination in that space; similarly I don't recall any mention of BSD). Some of these old magazines are definitely blasts from the past. - Dan C. On Wed, Jun 11, 2014 at 11:10 PM, Sergey Lapin wrote: > Hi, all! > > I've read recently published link to byte article and got an idea.... > Was there a magazine related to UNIX systems in 70s-80s? > I had so much fun reading that Byte issue, even ads (especially ads!) > It is so fun... > > _______________________________________________ > TUHS mailing list > TUHS at minnie.tuhs.org > https://minnie.tuhs.org/mailman/listinfo/tuhs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaapna at xs4all.nl Thu Jun 12 18:00:27 2014 From: jaapna at xs4all.nl (Jaap Akkerhuis) Date: Thu, 12 Jun 2014 10:00:27 +0200 Subject: [TUHS] UNIX magazines In-Reply-To: <539920C2.8050409@solar.stanford.edu> References: <539920C2.8050409@solar.stanford.edu> Message-ID: <54CA3DB9-C496-490E-A72C-CCE2CD82F3AD@xs4all.nl> On Jun 12, 2014, at 5:38, Deborah Scherrer wrote: > The group met once a month at Chantilly, > a posh restaurant in Palo Alto. Reminds me of a story (might have been an urban legend) that someone was making money out of these diners. He new when they where and in exchange for money he would introduce people to the celebrities. jaap -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 235 bytes Desc: Message signed with OpenPGP using GPGMail URL: From dscherrer at solar.stanford.edu Fri Jun 13 02:07:45 2014 From: dscherrer at solar.stanford.edu (Deborah Scherrer) Date: Thu, 12 Jun 2014 09:07:45 -0700 Subject: [TUHS] UNIX magazines In-Reply-To: <54CA3DB9-C496-490E-A72C-CCE2CD82F3AD@xs4all.nl> References: <539920C2.8050409@solar.stanford.edu> <54CA3DB9-C496-490E-A72C-CCE2CD82F3AD@xs4all.nl> Message-ID: <5399D051.3050708@solar.stanford.edu> Nope. I was on those Boards. That didn't happen. Debbie On 6/12/14 1:00 AM, Jaap Akkerhuis wrote: > On Jun 12, 2014, at 5:38, Deborah Scherrer wrote: > >> The group met once a month at Chantilly, >> a posh restaurant in Palo Alto. > Reminds me of a story (might have been an urban legend) that someone > was making money out of these diners. He new when they where and > in exchange for money he would introduce people to the celebrities. > > jaap From jhj at trnsz.com Thu Jun 12 22:56:46 2014 From: jhj at trnsz.com (Jeff Johnson) Date: Thu, 12 Jun 2014 08:56:46 -0400 Subject: [TUHS] UNIX magazines In-Reply-To: References: Message-ID: <475C9682-637A-40F0-9E87-692185D3A42B@trnsz.com> There is also SGI's Iris Universe, which was their in-house magazine. I have no idea when it started or ceased but I have quite a few of the early and mid 1990s issues that have really great articles and advertisements. I'll have to see if I can find them and scan them in to share. -- Jeff Johnson jhj at trnsz.com > On Jun 11, 2014, at 11:59 PM, Dan Cross wrote: > > There were several, starting I guess in the 80s mostly. The one I remember in particular was "Unix Review", but there were a few "journal" type magazines that also specialized in Unix-y things (e.g., ";login:" from USENIX; still published, I believe), and several associated with particular vendors: "SunExpert" was one, if I recall correctly. > > Occasionally, Unix and related things showed up in the "mainstream" consumer computer press of the time. I can remember in particular an issue of "PC Magazine" (I think June of 1993) that ran a lengthy couple of articles proving machines from Sun and SGI, in addition to version of Unix that ran on PCs (interestingly, Linux was omitted despite really starting to capture a lot of the imagination in that space; similarly I don't recall any mention of BSD). > > Some of these old magazines are definitely blasts from the past. > > - Dan C. > > > >> On Wed, Jun 11, 2014 at 11:10 PM, Sergey Lapin wrote: >> Hi, all! >> >> I've read recently published link to byte article and got an idea.... >> Was there a magazine related to UNIX systems in 70s-80s? >> I had so much fun reading that Byte issue, even ads (especially ads!) >> It is so fun... >> >> _______________________________________________ >> TUHS mailing list >> TUHS at minnie.tuhs.org >> https://minnie.tuhs.org/mailman/listinfo/tuhs > > _______________________________________________ > TUHS mailing list > TUHS at minnie.tuhs.org > https://minnie.tuhs.org/mailman/listinfo/tuhs -------------- next part -------------- An HTML attachment was scrubbed... URL: From norman at oclsc.org Fri Jun 13 10:45:44 2014 From: norman at oclsc.org (Norman Wilson) Date: Thu, 12 Jun 2014 20:45:44 -0400 (EDT) Subject: [TUHS] UNIX magazines Message-ID: <20140613004544.E9DFD1DE37F@lignose.oclsc.org> Dan Cross: ... there were a few "journal" type magazines that also specialized in Unix-y things (e.g., ";login:" from USENIX; still published, I believe) ... ====== ;login: is alive and well. So is USENIX. It's no longer the UNIX user's group it started as many decades ago; the focus has broadened to advanced computing and systems research, though the descendants of UNIX are still prominent in those areas. For an old-fashioned programmer/systems hack/systems generalist like me, it's still quite a worthwhile journal and a worthwhile organization. They've even been known to have a talk or two about resurrecting old versions of UNIX. I'm just off to the federation of medium-sized conferences and workshops that has grown out of the former USENIX Annual Technical Conference. I'm looking forward to it. Norman Wilson Toronto ON From doug at cs.dartmouth.edu Fri Jun 13 12:18:31 2014 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Thu, 12 Jun 2014 22:18:31 -0400 Subject: [TUHS] UNIX magazines Message-ID: <201406130218.s5D2IVS9022877@stowe.cs.dartmouth.edu> > ;login: is alive and well. For a few years Usenix even published a refereed technical journal, "Computing Systems", quite different in tone from ;login: It had some nice content. Does anyone know why it folded? Doug From arnold at skeeve.com Fri Jun 13 12:45:13 2014 From: arnold at skeeve.com (arnold at skeeve.com) Date: Thu, 12 Jun 2014 20:45:13 -0600 Subject: [TUHS] UNIX magazines In-Reply-To: <201406130218.s5D2IVS9022877@stowe.cs.dartmouth.edu> References: <201406130218.s5D2IVS9022877@stowe.cs.dartmouth.edu> Message-ID: <201406130245.s5D2jDOu014594@freefriends.org> Doug McIlroy wrote: > > ;login: is alive and well. > > For a few years Usenix even published a refereed technical > journal, "Computing Systems", quite different in tone from > ;login: It had some nice content. I have the full set on a shelf in my basement. > Does anyone know why it folded? ISTR that they simply ran out of content; they weren't getting enough submissions to keep it going, and journal production isn't an inexpensive undertaking. Arnold From norman at oclsc.org Fri Jun 13 14:03:22 2014 From: norman at oclsc.org (Norman Wilson) Date: Fri, 13 Jun 2014 00:03:22 -0400 (EDT) Subject: [TUHS] UNIX magazines Message-ID: <20140613040322.793E81DE37F@lignose.oclsc.org> Doug McIlroy: > Does anyone know why [Computing Systems] folded? Arnold Skeeve: ISTR that they simply ran out of content; they weren't getting enough submissions to keep it going, and journal production isn't an inexpensive undertaking. ====== That's what I remember too, though there may also have been insufficient interest from the members. The front matter in the last issue suggests that. Computing Systems was published from Winter 1988 to Fall 1996. (More years than I'd have guessed, even looking at the physical journals on my shelf; it was a quarterly.) It would probably not have lasted much longer no matter what, as the USENIX community was likely in the forefront of putting papers online on the World-Wide Web. USENIX now makes all their conference papers available online, free to anyone, except that only those registered for a conference can read them before the conference actually happens. That's not a bad substitute for a journal, I suppose. Norman Wilson Toronto ON From arnold at skeeve.com Fri Jun 13 14:54:50 2014 From: arnold at skeeve.com (arnold at skeeve.com) Date: Thu, 12 Jun 2014 22:54:50 -0600 Subject: [TUHS] UNIX magazines In-Reply-To: <20140613040322.793E81DE37F@lignose.oclsc.org> References: <20140613040322.793E81DE37F@lignose.oclsc.org> Message-ID: <201406130454.s5D4socW025618@freefriends.org> norman at oclsc.org (Norman Wilson) wrote: > Arnold Skeeve: 'skeeve' is my domain name. Robbins is my surname. From tuhs at cuzuco.com Fri Jun 13 15:07:01 2014 From: tuhs at cuzuco.com (Brian Walden) Date: Fri, 13 Jun 2014 01:07:01 -0400 (EDT) Subject: [TUHS] UNIX magazines Message-ID: <201406130507.s5D571jv022914@cuzuco.com> UNIX/WORLD started in 1984 and was renamed UnixWorld Magazine: Open Systems Computing in 1991 and then UnixWorld's Open Computing in 1994 and it folded in 1995. SunExpert started in 1989 was renamed to Server/Workstatsion Expert in 1999 and it folded in 2001. I always enjoyed Mike OBrien's offbeat "Ask Mr. Protocol" > From: Dan Cross > There were several, starting I guess in the 80s mostly. The one I remember > in particular was "Unix Review", but there were a few "journal" type > magazines that also specialized in Unix-y things (e.g., ";login:" from > USENIX; still published, I believe), and several associated with particular > vendors: "SunExpert" was one, if I recall correctly. > > Occasionally, Unix and related things showed up in the "mainstream" > consumer computer press of the time. I can remember in particular an issue > of "PC Magazine" (I think June of 1993) that ran a lengthy couple of > articles proving machines from Sun and SGI, in addition to version of Unix > that ran on PCs (interestingly, Linux was omitted despite really starting > to capture a lot of the imagination in that space; similarly I don't recall > any mention of BSD). > > Some of these old magazines are definitely blasts from the past. > > - Dan C. > > > > On Wed, Jun 11, 2014 at 11:10 PM, Sergey Lapin wrote: > > > Hi, all! > > > > I've read recently published link to byte article and got an idea.... > > Was there a magazine related to UNIX systems in 70s-80s? > > I had so much fun reading that Byte issue, even ads (especially ads!) > > It is so fun... > > > > _______________________________________________ > > TUHS mailing list > > TUHS at minnie.tuhs.org > > https://minnie.tuhs.org/mailman/listinfo/tuhs > > From norman at oclsc.org Fri Jun 13 22:03:21 2014 From: norman at oclsc.org (Norman Wilson) Date: Fri, 13 Jun 2014 08:03:21 -0400 (EDT) Subject: [TUHS] UNIX magazines Message-ID: <20140613120321.A51F71DE376@lignose.oclsc.org> 'skeeve' is my domain name. Robbins is my surname. Sorry about that; up too late with too many balls in the air (packing, finishing a tax return, listening to our provincial election results). At least I didn't further truncate it to skeev, as Ken might have done. From arnold at skeeve.com Fri Jun 13 23:10:08 2014 From: arnold at skeeve.com (arnold at skeeve.com) Date: Fri, 13 Jun 2014 07:10:08 -0600 Subject: [TUHS] UNIX magazines In-Reply-To: <20140613120321.A51F71DE376@lignose.oclsc.org> References: <20140613120321.A51F71DE376@lignose.oclsc.org> Message-ID: <201406131310.s5DDA8H2021287@freefriends.org> norman at oclsc.org (Norman Wilson) wrote: > 'skeeve' is my domain name. Robbins is my surname. > > Sorry about that; up too late with too many balls > in the air (packing, finishing a tax return, listening > to our provincial election results). NP. > At least I didn't further truncate it to skeev, as > Ken might have done. :-) Arnold From clemc at ccc.com Fri Jun 13 23:43:18 2014 From: clemc at ccc.com (Clem Cole) Date: Fri, 13 Jun 2014 09:43:18 -0400 Subject: [TUHS] UNIX magazines In-Reply-To: <20140613040322.793E81DE37F@lignose.oclsc.org> References: <20140613040322.793E81DE37F@lignose.oclsc.org> Message-ID: On Fri, Jun 13, 2014 at 12:03 AM, Norman Wilson wrote: > USENIX now makes all their conference papers available online, > free to anyone, except that only those registered for a > conference can read them before the conference actually happens. > That's not a bad substitute for a journal, I suppose. > ​Thank you Norman.​ ​As President of USENIX during that choice, that is a legacy I am particularly proud. It was a bit of a scary thing to do and so far ACM and IEEE have been loath to follow suite as completely (I suspect because the digital library is (was) a significant source of revenue for all three organizations). [To be fair, there are some exceptions, I believe ACM Queue is downloadable - although I note that it is interesting a lot of people working on Queue are also USENIX folks some of whom may be lurking on this mailing list]. For what ever its worth, just a month or so ago, I was very pleased to see my now Sr in college CS major daughter -- who went to her first USENIX conference in 1993 in stroller -- just joined USENIX (maybe its a little like joining "the party"). But if USENIX is to continue their tradition of being open and freely accessible, I offer an unabashed advertisement (i.e no pay walls): like her and her college peers, please consider a USENIX membership and/or going to a conference or two. To Doug's question -- I agree that the answers about "Computing Systems" that have been given are pretty much to the mark. It was not an insignificant undertaking to publish such a journal; and keeping it/dropping was a trade off. To all on the list, I can say that the Board has toyed with bring it back a couple of times when I was on it. If any of you have thoughts on the matter, send them to the current Board of Directors ( bod at usenix.org ) and/or the Executive Director: Casey Henderson (execdir at usenix.org). Clem -------------- next part -------------- An HTML attachment was scrubbed... URL: From scj at yaccman.com Sat Jun 14 02:04:35 2014 From: scj at yaccman.com (scj at yaccman.com) Date: Fri, 13 Jun 2014 09:04:35 -0700 Subject: [TUHS] UNIX magazines In-Reply-To: References: <20140613040322.793E81DE37F@lignose.oclsc.org> Message-ID: I was on the Usenix board when we decided to stop publishing Computing Systems. One of the key problems, not yet mentioned, was that the readership was too small. Several very good papers went elsewhere because the authors correctly felt that few people would see them if they published in CS. A related problem was that many university libraries were reluctant to subscribe. It seems that a certain critical mass is necessary to make a journal viable, and we never quite got there with CS... > On Fri, Jun 13, 2014 at 12:03 AM, Norman Wilson wrote: > >> USENIX now makes all their conference papers available online, >> free to anyone, except that only those registered for a >> conference can read them before the conference actually happens. >> That's not a bad substitute for a journal, I suppose. >> > > ​Thank you Norman.​ > > ​As President of USENIX during that choice, that is a legacy I am > particularly proud. It was a bit of a scary thing to do and so far ACM > and > IEEE have been loath to follow suite as completely (I suspect because the > digital library is (was) a significant source of revenue for all three > organizations). [To be fair, there are some exceptions, I believe ACM > Queue is downloadable - although I note that it is interesting a lot of > people working on Queue are also USENIX folks some of whom may be lurking > on this mailing list]. > > For what ever its worth, just a month or so ago, I was very pleased to see > my now Sr in college CS major daughter -- who went to her first USENIX > conference in 1993 in stroller -- just joined USENIX (maybe its a little > like joining "the party"). But if USENIX is to continue their tradition > of > being open and freely accessible, I offer an unabashed advertisement (i.e > no pay walls): like her and her college peers, please consider a USENIX > membership and/or going to a conference or two. > > > To Doug's question -- I agree that the answers about "Computing Systems" > that have been given are pretty much to the mark. It was not an > insignificant undertaking to publish such a journal; and keeping > it/dropping was a trade off. > > To all on the list, I can say that the Board has toyed with bring it back > a > couple of times when I was on it. If any of you have thoughts on the > matter, send them to the current Board of Directors ( bod at usenix.org ) > and/or the Executive Director: Casey Henderson (execdir at usenix.org). > > > Clem > _______________________________________________ > TUHS mailing list > TUHS at minnie.tuhs.org > https://minnie.tuhs.org/mailman/listinfo/tuhs > From jgsinowitz at yahoo.com Sat Jun 14 03:02:33 2014 From: jgsinowitz at yahoo.com (jgsinowitz at yahoo.com) Date: Fri, 13 Jun 2014 10:02:33 -0700 (PDT) Subject: [TUHS] TUHS Digest, Vol 113, Issue 21 In-Reply-To: Message-ID: <1402678953.55516.YahooMailAndroidMobile@web141601.mail.bf1.yahoo.com> This is a very enjoyable thread to follow! Jonah G Sinowitz Consultant 320 8th Street, #19 Lakewood, NJ 08701 732.367.7450 -------------- next part -------------- An HTML attachment was scrubbed... URL: From beebe at math.utah.edu Sat Jun 14 10:42:59 2014 From: beebe at math.utah.edu (Nelson H. F. Beebe) Date: Fri, 13 Jun 2014 18:42:59 -0600 (MDT) Subject: [TUHS] UNIX magazines Message-ID: There is a complete bibliography of the journal Computing Systems (1988--1996) here: http://www.math.utah.edu/pub/tex/bib/compsys.bib [change .bib to .html for a version with hyperlinks] Other journals about aspects of Unix include: Bell System Technical journal family (complete 1920--date) http://www.math.utah.edu/pub/tex/bib/bstj1920.bib http://www.math.utah.edu/pub/tex/bib/bstj1930.bib http://www.math.utah.edu/pub/tex/bib/bstj1940.bib http://www.math.utah.edu/pub/tex/bib/bstj1950.bib http://www.math.utah.edu/pub/tex/bib/bstj1960.bib http://www.math.utah.edu/pub/tex/bib/bstj1970.bib http://www.math.utah.edu/pub/tex/bib/bstj1980.bib http://www.math.utah.edu/pub/tex/bib/bstj1990.bib http://www.math.utah.edu/pub/tex/bib/bstj2000.bib http://www.math.utah.edu/pub/tex/bib/bstj2010.bib Journal of C Language Translation (1989--1995) http://www.math.utah.edu/pub/tex/bib/jclt.bib Usenix conference proceedings and ";login" journal (incomplete) http://www.math.utah.edu/pub/tex/bib/usenix1980.bib http://www.math.utah.edu/pub/tex/bib/usenix1990.bib http://www.math.utah.edu/pub/tex/bib/usenix2000.bib http://www.math.utah.edu/pub/tex/bib/usenix2010.bib The X Resource: A Practical Journal of the X Window System (1991--1994) http://www.math.utah.edu/pub/tex/bib/xres.bib There are also bibliographies of books about Unix, Linux, and the GNU Project: http://www.math.utah.edu/pub/tex/bib/gnu.bib http://www.math.utah.edu/pub/tex/bib/linux.bib http://www.math.utah.edu/pub/tex/bib/unix.bib Finally, there is a small bibliography of the AT&/Princeton lcc compiler: http://www.math.utah.edu/pub/tex/bib/lcc.bib There are more than 800 bibliographies in those archives with about 1.01 million entries. Please mirror them to your site(s): mirror instructions, overviews, and space requirements can be found at the top-level sites http://www.math.utah.edu/pub/tex/bib/ http://www.math.utah.edu/pub/bibnet/ The collections are active, and continuously enhanced and extended, with dozens of files being updated or added weekly. Using rsync for mirroring is easy and fast, so nightly or weekly mirrors pose no problem at either end of the connection. There is also a TUHS mirror in Salt Lake City, Utah: http://www.math.utah.edu/pub/mirrors/minnie.tuhs.org/ It too can be mirrored with rsync. ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah FAX: +1 801 581 4148 - - Department of Mathematics, 110 LCB Internet e-mail: beebe at math.utah.edu - - 155 S 1400 E RM 233 beebe at acm.org beebe at computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - ------------------------------------------------------------------------------- From a.phillip.garcia at gmail.com Sat Jun 14 10:53:49 2014 From: a.phillip.garcia at gmail.com (A. P. Garcia) Date: Fri, 13 Jun 2014 19:53:49 -0500 Subject: [TUHS] UNIX magazines In-Reply-To: References: Message-ID: On Jun 13, 2014 7:43 PM, "Nelson H. F. Beebe" wrote: > > There is a complete bibliography of the journal Computing Systems > (1988--1996) here: > > http://www.math.utah.edu/pub/tex/bib/compsys.bib > [change .bib to .html for a version with hyperlinks] > > Other journals about aspects of Unix include: > > Bell System Technical journal family (complete 1920--date) > http://www.math.utah.edu/pub/tex/bib/bstj1920.bib > http://www.math.utah.edu/pub/tex/bib/bstj1930.bib > http://www.math.utah.edu/pub/tex/bib/bstj1940.bib > http://www.math.utah.edu/pub/tex/bib/bstj1950.bib > http://www.math.utah.edu/pub/tex/bib/bstj1960.bib > http://www.math.utah.edu/pub/tex/bib/bstj1970.bib > http://www.math.utah.edu/pub/tex/bib/bstj1980.bib > http://www.math.utah.edu/pub/tex/bib/bstj1990.bib > http://www.math.utah.edu/pub/tex/bib/bstj2000.bib > http://www.math.utah.edu/pub/tex/bib/bstj2010.bib > > Journal of C Language Translation (1989--1995) > http://www.math.utah.edu/pub/tex/bib/jclt.bib > > Usenix conference proceedings and ";login" journal (incomplete) > http://www.math.utah.edu/pub/tex/bib/usenix1980.bib > http://www.math.utah.edu/pub/tex/bib/usenix1990.bib > http://www.math.utah.edu/pub/tex/bib/usenix2000.bib > http://www.math.utah.edu/pub/tex/bib/usenix2010.bib > > The X Resource: A Practical Journal of the X Window System (1991--1994) > http://www.math.utah.edu/pub/tex/bib/xres.bib > > There are also bibliographies of books about Unix, Linux, and the GNU > Project: > > http://www.math.utah.edu/pub/tex/bib/gnu.bib > http://www.math.utah.edu/pub/tex/bib/linux.bib > http://www.math.utah.edu/pub/tex/bib/unix.bib > > Finally, there is a small bibliography of the AT&/Princeton lcc > compiler: > > http://www.math.utah.edu/pub/tex/bib/lcc.bib > > There are more than 800 bibliographies in those archives with about > 1.01 million entries. Please mirror them to your site(s): mirror > instructions, overviews, and space requirements can be found at the > top-level sites > > http://www.math.utah.edu/pub/tex/bib/ > http://www.math.utah.edu/pub/bibnet/ > > The collections are active, and continuously enhanced and extended, > with dozens of files being updated or added weekly. Using rsync for > mirroring is easy and fast, so nightly or weekly mirrors pose no > problem at either end of the connection. > > There is also a TUHS mirror in Salt Lake City, Utah: > > http://www.math.utah.edu/pub/mirrors/minnie.tuhs.org/ > > It too can be mirrored with rsync. > > ------------------------------------------------------------------------------- > - Nelson H. F. Beebe Tel: +1 801 581 5254 - > - University of Utah FAX: +1 801 581 4148 - > - Department of Mathematics, 110 LCB Internet e-mail: beebe at math.utah.edu - > - 155 S 1400 E RM 233 beebe at acm.org beebe at computer.org - > - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - > ------------------------------------------------------------------------------- ...and those are just the ones that have been baptized. i'm sorry, bad joke. this is a really nice resource. thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wkt at tuhs.org Sat Jun 14 13:30:19 2014 From: wkt at tuhs.org (Warren Toomey) Date: Sat, 14 Jun 2014 13:30:19 +1000 Subject: [TUHS] Archive of old ;login or EUUG newsletters? Message-ID: <20140614033019.GA16666@www.oztivo.net> Speaking of old publications, is there an on-line archive of old ;login: or EUUG newsletters? I did one for the AUUG newsletters here: http://minnie.tuhs.org/Archive/Documentation/AUUGN/ but it would be nice to have an archive for the U.S and Europe. Cheers, Warren From khm at sciops.net Sat Jun 14 13:43:52 2014 From: khm at sciops.net (Kurt H Maier) Date: Sat, 14 Jun 2014 03:43:52 +0000 Subject: [TUHS] Archive of old ;login or EUUG newsletters? In-Reply-To: <20140614033019.GA16666@www.oztivo.net> References: <20140614033019.GA16666@www.oztivo.net> Message-ID: <20140614034352.Horde.O0_m56-ajjnVuE7_2IDHrw4@ssl.eumx.net> Quoting Warren Toomey : > Speaking of old publications, is there an on-line archive of old ;login: > or EUUG newsletters? I did one for the AUUG newsletters here: > > http://minnie.tuhs.org/Archive/Documentation/AUUGN/ > > but it would be nice to have an archive for the U.S and Europe. https://www.usenix.org/publications/login goes back to 1997, but it's all webbed up and not suitable for archival. Between its increasing focus on web nonsense and the inexplicable canning of SAGE, I dropped my USENIX membership a while back. This thread has served to make me look closely as to whether I am getting any actual value out of my ACM membership. khm From dds at aueb.gr Mon Jun 16 00:46:44 2014 From: dds at aueb.gr (Diomidis Spinellis) Date: Sun, 15 Jun 2014 17:46:44 +0300 Subject: [TUHS] Tree of late BSD releases Message-ID: <539DB1D4.3080909@aueb.gr> For reconstructing Unix history on a single repository [1], I'd need to represent the branches, merges, and chronological sequence of the late BSD releases (after 4.3). However, I've found on the internet some conflicting and simplistic information, so I'd welcome your input on how to straighten things up. First, consider this widely reproduced BSD family tree [2]. It has 4.4BSD-Encumbered derive from a line that includes Net/1, which was freely redistributable. Wouldn't it be clearer to create two branches, one with distributions free of AT&T code (4.3 BSD Net/1, 4.3 BSD Net/2, 4.4 BSD Lite1, 4.4 BSD Lite2) and one with full distributions (4.4 BSD, ...)? On which side would Tahoe and Reno stand? Also, the same tree [2] shows 4.4 BSD having as its ancestor 4.3 BSD Net/2, whereas another tree depicted on Wikipedia [3] has shows 4.4 BSD and 4.3 BSD Net/2 having as their ancestor 4.3 BSD Reno. What's the correct genealogy? Finally, I have a conflict with release dates. Wikipedia gives the following dates for Tahoe and Net/1 [4]: 4.3 BSD Tahoe June 1988 4.3 BSD Net/1 June 1989 However, looking at time-stamp of the newest files available under the corresponding directories in the CSRG CD-ROMs [5] I find the opposite order: cd2/net.1/sendmail/src/util.c 1989-01-01 12:15:58 cd2/4.3tahoe/usr/src/sys/tahoevba/vx.c 1989-05-23 13:47:43 What's the actual time sequence, and what's the corresponding genealogy? [1] https://github.com/dspinellis/unix-history-repo [2] http://ftp.netbsd.org/pub/NetBSD/NetBSD-current/src/share/misc/bsd-family-tree [3] https://en.wikipedia.org/wiki/File:Unix_history-simple.svg [4] https://en.wikipedia.org/wiki/Berkeley_Software_Distribution [5] https://www.mckusick.com/csrg/ Many thanks, Diomidis Spinellis PS Thank you all for the help you've provided so far. From norman at oclsc.org Mon Jun 16 04:19:36 2014 From: norman at oclsc.org (Norman Wilson) Date: Sun, 15 Jun 2014 14:19:36 -0400 Subject: [TUHS] Happy birthday, core dumped Message-ID: <1402856379.23321.for-standards-violators@oclsc.org> Jay Forrester, who invented core memory, first described it in a lab notebook 65 years ago today. (Thanks to the Living Computer Museum, through whose Twitter feed I learned this tidbit. It's a place--the real museum, not just the Twitter feed--many on this list might enjoy: among their aged-but-working computers are a Xerox Star and a PDP-7.) Norman Wilson Toronto ON From b4 at gewt.net Mon Jun 16 22:53:59 2014 From: b4 at gewt.net (Cory Smelosky) Date: Mon, 16 Jun 2014 08:53:59 -0400 (EDT) Subject: [TUHS] 4.1BSD Networking Message-ID: Hello all, recent subscriber to this list...but some might recognise me. I'm currently fighting (and mostly succeeding) with getting a pure 4.3BSD-Tahoe install rolling in a VAX simulator (all my tape drives are currently nonfunctional or I'd fire up a real II or III). Still in the middle of compiling (I know there are easier ways...but I like the feeling of doing it purely "from scratch"...feels more historically accurate). Anyways, while waiting for the compile I ended up with a working 4.1c installation and I began poking around its source tree (I also did a little bit of poking at the CSRG discs). I stumbled upon the fact 4.1c supports the DMC (which SIMH git now emulates!) and I see it's also still in src/old on some versions of 4.3 (I wonder if it'll still build...). Looking at the source is immensely confusing...does anyone have any knowledge/notes from the time period/documentation that will help me with my little experiment in archaic networking? I might just be tired...but the berknet configuration doesn't make a whole lot of sense to me. (There's also the fact my grasp of C is minimal). -- Cory Smelosky http://gewt.net Personal stuff http://gimme-sympathy.org Projects From clemc at ccc.com Tue Jun 17 00:28:41 2014 From: clemc at ccc.com (Clem Cole) Date: Mon, 16 Jun 2014 10:28:41 -0400 Subject: [TUHS] 4.1BSD Networking In-Reply-To: References: Message-ID: Hi Cory, We can take this a off list if you like. I warn you the DMR/DMC support was for BSD was rudimentary, and most of us in the UNIX community did not mess with it because we had non-DEC Ethernet controllers from that time. You might have more success seeing if we can dig up a simulation of the Interlan or 3Com Unibus boards which were what may of used. Clem On Mon, Jun 16, 2014 at 8:53 AM, Cory Smelosky wrote: > Hello all, recent subscriber to this list...but some might recognise me. > > I'm currently fighting (and mostly succeeding) with getting a pure > 4.3BSD-Tahoe install rolling in a VAX simulator (all my tape drives are > currently nonfunctional or I'd fire up a real II or III). Still in the > middle of compiling (I know there are easier ways...but I like the feeling > of doing it purely "from scratch"...feels more historically accurate). > > Anyways, while waiting for the compile I ended up with a working 4.1c > installation and I began poking around its source tree (I also did a little > bit of poking at the CSRG discs). I stumbled upon the fact 4.1c supports > the DMC (which SIMH git now emulates!) and I see it's also still in src/old > on some versions of 4.3 (I wonder if it'll still build...). Looking at the > source is immensely confusing...does anyone have any knowledge/notes from > the time period/documentation that will help me with my little experiment > in archaic networking? I might just be tired...but the berknet > configuration doesn't make a whole lot of sense to me. (There's also the > fact my grasp of C is minimal). > > -- > Cory Smelosky > http://gewt.net Personal stuff > http://gimme-sympathy.org Projects > _______________________________________________ > TUHS mailing list > TUHS at minnie.tuhs.org > https://minnie.tuhs.org/mailman/listinfo/tuhs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron at ronnatalie.com Tue Jun 17 02:05:02 2014 From: ron at ronnatalie.com (Ronald Natalie) Date: Mon, 16 Jun 2014 12:05:02 -0400 Subject: [TUHS] 4.1BSD Networking In-Reply-To: References: Message-ID: I'd also warn that 4.1c as originally distriuted has some serious bugs like crashing when it receives ICMP redirects. We had just brought our systems up when they crashed and then it crashed an hour later and the phone rang and it was Louis Mamakos of UofM who was playing with their fuzzballs and pinged our system. From iking at killthewabbit.org Tue Jun 17 02:13:18 2014 From: iking at killthewabbit.org (iking at killthewabbit.org) Date: Mon, 16 Jun 2014 09:13:18 -0700 Subject: [TUHS] Happy birthday, core dumped In-Reply-To: <1402856379.23321.for-standards-violators@oclsc.org> References: <1402856379.23321.for-standards-violators@oclsc.org> Message-ID: <21ae9091-baed-493a-b84f-ec96efc66955.maildroid@localhost> Small correction: not a Star, an Alto. :-) Sent from my android device. -----Original Message----- From: Norman Wilson To: tuhs at minnie.tuhs.org Sent: Sun, 15 Jun 2014 11:19 AM Subject: [TUHS] Happy birthday, core dumped Jay Forrester, who invented core memory, first described it in a lab notebook 65 years ago today. (Thanks to the Living Computer Museum, through whose Twitter feed I learned this tidbit. It's a place--the real museum, not just the Twitter feed--many on this list might enjoy: among their aged-but-working computers are a Xerox Star and a PDP-7.) Norman Wilson Toronto ON _______________________________________________ TUHS mailing list TUHS at minnie.tuhs.org https://minnie.tuhs.org/mailman/listinfo/tuhs -------------- next part -------------- An HTML attachment was scrubbed... URL: From b4 at gewt.net Tue Jun 17 06:37:09 2014 From: b4 at gewt.net (Cory Smelosky) Date: Mon, 16 Jun 2014 16:37:09 -0400 (EDT) Subject: [TUHS] Creating 4.3 skeleton filesystem (was Re: 4.1BSD Networking) In-Reply-To: References: Message-ID: Little bit more sidetracking... How were the skeleton filesystems created when generating a new miniroot and whatnot? Manually? Were the scripts just removed from Tahoe? Thanks! -- Cory Smelosky http://gewt.net Personal stuff http://gimme-sympathy.org Projects From gregg.drwho8 at gmail.com Tue Jun 17 08:01:38 2014 From: gregg.drwho8 at gmail.com (Gregg Levine) Date: Mon, 16 Jun 2014 18:01:38 -0400 Subject: [TUHS] Happy birthday, core dumped In-Reply-To: <21ae9091-baed-493a-b84f-ec96efc66955.maildroid@localhost> References: <1402856379.23321.for-standards-violators@oclsc.org> <21ae9091-baed-493a-b84f-ec96efc66955.maildroid@localhost> Message-ID: Hello! Interesting. I know I've seen the Star system rig before. But the Xerox Alto one is new to me. Wasn't the PDP-7 the fellow where UNIX really got its start on before they moved it to a PDP-11? ----- Gregg C Levine gregg.drwho8 at gmail.com "This signature fought the Time Wars, time and again." On Mon, Jun 16, 2014 at 12:13 PM, wrote: > Small correction: not a Star, an Alto. :-) > > Sent from my android device. > > > -----Original Message----- > From: Norman Wilson > To: tuhs at minnie.tuhs.org > Sent: Sun, 15 Jun 2014 11:19 AM > Subject: [TUHS] Happy birthday, core dumped > > Jay Forrester, who invented core memory, first described it in > a lab notebook 65 years ago today. > > (Thanks to the Living Computer Museum, through whose Twitter > feed I learned this tidbit. It's a place--the real museum, > not just the Twitter feed--many on this list might enjoy: > among their aged-but-working computers are a Xerox Star and > a PDP-7.) > > Norman Wilson > Toronto ON > _______________________________________________ > TUHS mailing list > TUHS at minnie.tuhs.org > https://minnie.tuhs.org/mailman/listinfo/tuhs > > _______________________________________________ > TUHS mailing list > TUHS at minnie.tuhs.org > https://minnie.tuhs.org/mailman/listinfo/tuhs > From cowan at mercury.ccil.org Tue Jun 17 11:38:40 2014 From: cowan at mercury.ccil.org (John Cowan) Date: Mon, 16 Jun 2014 21:38:40 -0400 Subject: [TUHS] Happy birthday, core dumped In-Reply-To: References: <1402856379.23321.for-standards-violators@oclsc.org> <21ae9091-baed-493a-b84f-ec96efc66955.maildroid@localhost> Message-ID: <20140617013840.GB3947@mercury.ccil.org> Gregg Levine scripsit: > I know I've seen the Star system rig before. But the Xerox Alto one is > new to me. Wasn't the PDP-7 the fellow where UNIX really got its start > on before they moved it to a PDP-11? It was. The 18-bit systems were the red-headed stepchild of the DEC world. The PDP-1, PDP-4, and PDP-7 systems had no DEC-supplied operating system, and the PDP-9 only a minimal one, about like OS/8. Not until the terminal 18-bit system, the PDP-15, were PDP-11 class operating systems provided. Consequently, the Bell Labs PDP-7 was essentially useless. -- John Cowan http://www.ccil.org/~cowan cowan at ccil.org Awk!" sed Grep. "A fscking python is perloining my Ruby; let me bash him with a Cshell! Vi didn't I mount it on a troff?" --Francis Turner From grog at lemis.com Tue Jun 17 11:56:35 2014 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Tue, 17 Jun 2014 11:56:35 +1000 Subject: [TUHS] Happy birthday, core dumped In-Reply-To: <20140617013840.GB3947@mercury.ccil.org> References: <1402856379.23321.for-standards-violators@oclsc.org> <21ae9091-baed-493a-b84f-ec96efc66955.maildroid@localhost> <20140617013840.GB3947@mercury.ccil.org> Message-ID: <20140617015635.GB26776@eureka.lemis.com> On Monday, 16 June 2014 at 21:38:40 -0400, John Cowan wrote: > Gregg Levine scripsit: > >> I know I've seen the Star system rig before. But the Xerox Alto one is >> new to me. Wasn't the PDP-7 the fellow where UNIX really got its start >> on before they moved it to a PDP-11? > > It was. The 18-bit systems were the red-headed stepchild of the DEC world. > The PDP-1, PDP-4, and PDP-7 systems had no DEC-supplied operating system, > and the PDP-9 only a minimal one, about like OS/8. Not until the terminal > 18-bit system, the PDP-15, were PDP-11 class operating systems provided. > Consequently, the Bell Labs PDP-7 was essentially useless. Sounds like it was crying out for somebody to write an operating system for it :-) Greg -- Sent from my desktop computer. Finger grog at FreeBSD.org for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft MUA reports problems, please read http://tinyurl.com/broken-mua -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available URL: From iking at killthewabbit.org Tue Jun 17 13:13:05 2014 From: iking at killthewabbit.org (iking at killthewabbit.org) Date: Mon, 16 Jun 2014 20:13:05 -0700 Subject: [TUHS] Happy birthday, core dumped In-Reply-To: <20140617013840.GB3947@mercury.ccil.org> References: <1402856379.23321.for-standards-violators@oclsc.org> <21ae9091-baed-493a-b84f-ec96efc66955.maildroid@localhost> <20140617013840.GB3947@mercury.ccil.org> Message-ID: <9cea91b5-f4ee-46a3-80b3-899b1ee00d69.maildroid@localhost> Well, the University of Oregon might disagree with you about the PDP-7. They ran the DECsys monitor, which ISTR was the first such software product from DEC outside the 36-bit line (the PDP-6 and -7 were introduced in the same year). U of O took delivery of their -7 in 1966 and it saw active service for at least three decades, with over thirty doctorates earned based on research performed on the system. Hardly useless.... It's always been a bit of a mystery to me why Thompson and Ritchie decided they needed to write a new executive - UNICS - rather than use DECsys. True, DECsys isn't anything to shout about and Unix is clearly more useful - but IMHO Spacewar! could have been coded in the DECsys 'environment'. I infer that they saw broader utility and application in a more capable executive - which obviously turned out to be true! The U of O PDP-7 is the one currently residing at the Living Computer Museum (I used to maintain it). And what's wrong with OS/8? Minimal, yes - what do you want, Windows Vista? :-) - Ian Sent from my android device. -----Original Message----- From: John Cowan To: Gregg Levine Cc: tuhs at minnie.tuhs.org Sent: Mon, 16 Jun 2014 6:38 PM Subject: Re: [TUHS] Happy birthday, core dumped Gregg Levine scripsit: > I know I've seen the Star system rig before. But the Xerox Alto one is > new to me. Wasn't the PDP-7 the fellow where UNIX really got its start > on before they moved it to a PDP-11? It was. The 18-bit systems were the red-headed stepchild of the DEC world. The PDP-1, PDP-4, and PDP-7 systems had no DEC-supplied operating system, and the PDP-9 only a minimal one, about like OS/8. Not until the terminal 18-bit system, the PDP-15, were PDP-11 class operating systems provided. Consequently, the Bell Labs PDP-7 was essentially useless. -- John Cowan http://www.ccil.org/~cowan cowan at ccil.org Awk!" sed Grep. "A fscking python is perloining my Ruby; let me bash him with a Cshell! Vi didn't I mount it on a troff?" --Francis Turner _______________________________________________ TUHS mailing list TUHS at minnie.tuhs.org https://minnie.tuhs.org/mailman/listinfo/tuhs -------------- next part -------------- An HTML attachment was scrubbed... URL: From cowan at mercury.ccil.org Tue Jun 17 22:14:19 2014 From: cowan at mercury.ccil.org (John Cowan) Date: Tue, 17 Jun 2014 08:14:19 -0400 Subject: [TUHS] Happy birthday, core dumped In-Reply-To: <9cea91b5-f4ee-46a3-80b3-899b1ee00d69.maildroid@localhost> References: <1402856379.23321.for-standards-violators@oclsc.org> <21ae9091-baed-493a-b84f-ec96efc66955.maildroid@localhost> <20140617013840.GB3947@mercury.ccil.org> <9cea91b5-f4ee-46a3-80b3-899b1ee00d69.maildroid@localhost> Message-ID: <20140617121419.GD3947@mercury.ccil.org> iking at killthewabbit.org scripsit: > Well, the University of Oregon might disagree with you about the PDP-7. > They ran the DECsys monitor, Ah, I didn't know about that. Still, pretty sub-minimal: Fortran II, assembler, editor, period. It made OS/8 look quite rich by comparison. > Hardly useless.... However, according to the manual, DECsys required an 8Kword PDP-7, whereas the "Space Travel" (not "Spacewar!") machine had only 4Kwords. > And what's wrong with OS/8? Nothing. Indeed, I cut my teeth on it on a PDP-8/M with 8K and a single DECtape with the driver in ROM. I was using the term descriptively to indicate the kind of OS available for the PDP-9. A modified version also ran on the '15, it seems. But the native OSes were DOS-15 (roughly RT-11) and RSX-15 (a classic DEC RSX). -- John Cowan http://www.ccil.org/~cowan cowan at ccil.org "Not to know The Smiths is not to know K.X.U." --K.X.U. From doug at cs.dartmouth.edu Wed Jun 18 21:06:54 2014 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Wed, 18 Jun 2014 07:06:54 -0400 Subject: [TUHS] Happy birthday, core dumped Message-ID: <201406181106.s5IB6scu031264@stowe.cs.dartmouth.edu> > It's always been a bit of a mystery to me why Thompson and Ritchie decided they needed to write a new executive - UNICS - rather than use DECsys. It was the other way around. They had conceived a clean, simple, yet powerful, operating system and needed a machine to build it on. A cast-off PDP-7 happened to be at hand. Doug From iking at killthewabbit.org Thu Jun 19 00:43:51 2014 From: iking at killthewabbit.org (iking at killthewabbit.org) Date: Wed, 18 Jun 2014 07:43:51 -0700 Subject: [TUHS] Happy birthday, core dumped In-Reply-To: <201406181106.s5IB6scu031264@stowe.cs.dartmouth.edu> References: <201406181106.s5IB6scu031264@stowe.cs.dartmouth.edu> Message-ID: Interesting - what's your source? It was also my understanding they used the -7 'because it was there' but that they had pitched for a PDP-10, which had TOPS-10. - Ian Sent from my android device. -----Original Message----- From: Doug McIlroy To: tuhs at minnie.tuhs.org Sent: Wed, 18 Jun 2014 4:06 AM Subject: Re: [TUHS] Happy birthday, core dumped > It's always been a bit of a mystery to me why Thompson and Ritchie decided they needed to write a new executive - UNICS - rather than use DECsys. It was the other way around. They had conceived a clean, simple, yet powerful, operating system and needed a machine to build it on. A cast-off PDP-7 happened to be at hand. Doug _______________________________________________ TUHS mailing list TUHS at minnie.tuhs.org https://minnie.tuhs.org/mailman/listinfo/tuhs -------------- next part -------------- An HTML attachment was scrubbed... URL: From crossd at gmail.com Thu Jun 19 00:48:24 2014 From: crossd at gmail.com (Dan Cross) Date: Wed, 18 Jun 2014 10:48:24 -0400 Subject: [TUHS] Happy birthday, core dumped In-Reply-To: References: <201406181106.s5IB6scu031264@stowe.cs.dartmouth.edu> Message-ID: On Wed, Jun 18, 2014 at 10:43 AM, wrote: > Interesting - what's your source? It was also my understanding they used > the -7 'because it was there' but that they had pitched for a PDP-10, which > had TOPS-10. - Ian > *laugh* Doug, weren't you department head at the time, or did that come later? - Dan C. > Sent from my android device. > > -----Original Message----- > From: Doug McIlroy > To: tuhs at minnie.tuhs.org > Sent: Wed, 18 Jun 2014 4:06 AM > Subject: Re: [TUHS] Happy birthday, core dumped > > > It's always been a bit of a mystery to me why Thompson and Ritchie > decided they needed to write a new executive - UNICS - rather than use > DECsys. > > It was the other way around. They had conceived a clean, simple, yet > powerful, operating system and needed a machine to build it on. A > cast-off PDP-7 happened to be at hand. > > Doug > _______________________________________________ > TUHS mailing list > TUHS at minnie.tuhs.org > https://minnie.tuhs.org/mailman/listinfo/tuhs > > _______________________________________________ > TUHS mailing list > TUHS at minnie.tuhs.org > https://minnie.tuhs.org/mailman/listinfo/tuhs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From norman at oclsc.org Thu Jun 19 01:03:56 2014 From: norman at oclsc.org (Norman Wilson) Date: Wed, 18 Jun 2014 11:03:56 -0400 Subject: [TUHS] Happy birthday, core dumped Message-ID: <1403103840.16031.for-standards-violators@oclsc.org> Interesting - what's your source? It was also my understanding they used the -7 'because it was there' but that they had pitched for a PDP-10, which had TOPS-10. ====== I think Doug's source is in the class `personal observation.' He was there at the time; Ken and Dennis's department head, if I've got it right. Remember that Bell Labs had just disengaged itself from the Multics project. The interest in a new OS sprang partly from the desire to have a comfortable multi-user system now that Multics was no longer available. That's why the DEC operating systems of the time, which were (as I understand it) simple single-user monitors, didn't fill the bill. The character of the players matters too: remember that Ken is the guy who one night sat down to write a Fortran compiler because real systems have Fortran, and ended up inventing B instead. I've read that there was indeed a pitch to buy a PDP-10; that there was some complicated plan to lower the effective cost; and that upper management (not Doug) turned it down because `Bell Labs doesn't do business that way.' I think I got that from Dennis's retrospective paper, published in the 1984 all-UNIX issue of the Bell Labs Techical Journal, a must-read (along with the late-1970s all-UNIX issue of BSTJ) for anyone on this list. From lm at mcvoy.com Thu Jun 19 00:00:50 2014 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 18 Jun 2014 07:00:50 -0700 Subject: [TUHS] Happy birthday, core dumped In-Reply-To: <1403103840.16031.for-standards-violators@oclsc.org> References: <1403103840.16031.for-standards-violators@oclsc.org> Message-ID: <20140618140050.GM1580@mcvoy.com> On Wed, Jun 18, 2014 at 11:03:56AM -0400, Norman Wilson wrote: > I think I got that > from Dennis's retrospective paper, published in the 1984 > all-UNIX issue of the Bell Labs Techical Journal, a must-read > (along with the late-1970s all-UNIX issue of BSTJ) for anyone > on this list. Indeed. I just packed up my office, all the books, and the BSTJ were the only things I kept close. Well, that and the Xinu books, I've got a soft spot for those. -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From crossd at gmail.com Thu Jun 19 01:14:34 2014 From: crossd at gmail.com (Dan Cross) Date: Wed, 18 Jun 2014 11:14:34 -0400 Subject: [TUHS] Happy birthday, core dumped In-Reply-To: <1403103840.16031.for-standards-violators@oclsc.org> References: <1403103840.16031.for-standards-violators@oclsc.org> Message-ID: The paper with that quote is still linked from dmr's page: http://cm.bell-labs.com/who/dmr/hist.html On Wed, Jun 18, 2014 at 11:03 AM, Norman Wilson wrote: > Interesting - what's your source? It was also my understanding they > used the -7 'because it was there' but that they had pitched for a > PDP-10, which had TOPS-10. > > ====== > > I think Doug's source is in the class `personal observation.' > He was there at the time; Ken and Dennis's department head, if > I've got it right. > > Remember that Bell Labs had just disengaged itself from the > Multics project. The interest in a new OS sprang partly > from the desire to have a comfortable multi-user system > now that Multics was no longer available. That's why the > DEC operating systems of the time, which were (as I understand > it) simple single-user monitors, didn't fill the bill. > > The character of the players matters too: remember that > Ken is the guy who one night sat down to write a Fortran > compiler because real systems have Fortran, and ended up > inventing B instead. > > I've read that there was indeed a pitch to buy a PDP-10; that > there was some complicated plan to lower the effective cost; > and that upper management (not Doug) turned it down because > `Bell Labs doesn't do business that way.' I think I got that > from Dennis's retrospective paper, published in the 1984 > all-UNIX issue of the Bell Labs Techical Journal, a must-read > (along with the late-1970s all-UNIX issue of BSTJ) for anyone > on this list. > _______________________________________________ > TUHS mailing list > TUHS at minnie.tuhs.org > https://minnie.tuhs.org/mailman/listinfo/tuhs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From iking at killthewabbit.org Thu Jun 19 02:21:38 2014 From: iking at killthewabbit.org (Ian King) Date: Wed, 18 Jun 2014 09:21:38 -0700 Subject: [TUHS] Happy birthday, core dumped In-Reply-To: <20140617121419.GD3947@mercury.ccil.org> References: <1402856379.23321.for-standards-violators@oclsc.org> <21ae9091-baed-493a-b84f-ec96efc66955.maildroid@localhost> <20140617013840.GB3947@mercury.ccil.org> <9cea91b5-f4ee-46a3-80b3-899b1ee00d69.maildroid@localhost> <20140617121419.GD3947@mercury.ccil.org> Message-ID: On Jun 17, 2014, at 5:14 AM, John Cowan wrote: > iking at killthewabbit.org scripsit: > >> Well, the University of Oregon might disagree with you about the >> PDP-7. >> They ran the DECsys monitor, > > Ah, I didn't know about that. Still, pretty sub-minimal: Fortran II, > assembler, editor, period. It made OS/8 look quite rich by > comparison. U of O also had FOCAL running on it, which may have been a local port - I'll have to find out. > >> Hardly useless.... > > However, according to the manual, DECsys required an 8Kword PDP-7, > whereas > the "Space Travel" (not "Spacewar!") machine had only 4Kwords. Yes, thanks for the correction - a slip of the virtual tongue. I didn't realize the Bell Labs machine was so basic - in fact, it was my understanding that the basic machine was 8Kwords. The machine at LCM actually has 16K, with a DEC field mod to allow it to be addressed in PDP-9/15 fashion. >> And what's wrong with OS/8? > > Nothing. Indeed, I cut my teeth on it on a PDP-8/M with 8K and a > single > DECtape with the driver in ROM. I was using the term descriptively to > indicate the kind of OS available for the PDP-9. A modified > version also > ran on the '15, it seems. But the native OSes were DOS-15 (roughly > RT-11) > and RSX-15 (a classic DEC RSX). OK, we're good then. :-) I have a soft spot for the 12-bit machines, if it doesn't show. -- Ian From scj at yaccman.com Thu Jun 19 02:50:38 2014 From: scj at yaccman.com (scj at yaccman.com) Date: Wed, 18 Jun 2014 09:50:38 -0700 Subject: [TUHS] Happy birthday, core dumped In-Reply-To: <1403103840.16031.for-standards-violators@oclsc.org> References: <1403103840.16031.for-standards-violators@oclsc.org> Message-ID: <09fffa6e9f2fdb29ab25825d19594d8e.squirrel@webmail.yaccman.com> Bell Labs' decision to pull out of Multics still ranks in my mind as one of the best management decisions I've ever had close contact with... With respect to Dec's OSs vs Unix, I remember a visit from a Dec repair person who ran "preventive maintenance" on our disc that wiped out the file system! His excuse was that Dec didn't support "permanent storage" on the disc at the time... From b4 at gewt.net Thu Jun 19 02:58:45 2014 From: b4 at gewt.net (Cory Smelosky) Date: Wed, 18 Jun 2014 12:58:45 -0400 Subject: [TUHS] Happy birthday, core dumped In-Reply-To: <20140618140050.GM1580@mcvoy.com> References: <1403103840.16031.for-standards-violators@oclsc.org> <20140618140050.GM1580@mcvoy.com> Message-ID: Sent from my advertising assimilation device > On 18 Jun 2014, at 10:00, Larry McVoy wrote: > >> On Wed, Jun 18, 2014 at 11:03:56AM -0400, Norman Wilson wrote: >> I think I got that >> from Dennis's retrospective paper, published in the 1984 >> all-UNIX issue of the Bell Labs Techical Journal, a must-read >> (along with the late-1970s all-UNIX issue of BSTJ) for anyone >> on this list. > > Indeed. I just packed up my office, all the books, and the BSTJ were the > only things I kept close. Well, that and the Xinu books, I've got a soft > spot for those. Have Xinu media to go with it? It's something I've been trying to track down. ;) > -- > --- > Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm > _______________________________________________ > TUHS mailing list > TUHS at minnie.tuhs.org > https://minnie.tuhs.org/mailman/listinfo/tuhs From lm at mcvoy.com Thu Jun 19 01:55:24 2014 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 18 Jun 2014 08:55:24 -0700 Subject: [TUHS] Happy birthday, core dumped In-Reply-To: References: <1403103840.16031.for-standards-violators@oclsc.org> <20140618140050.GM1580@mcvoy.com> Message-ID: <20140618155524.GR1580@mcvoy.com> On Wed, Jun 18, 2014 at 12:58:45PM -0400, Cory Smelosky wrote: > > > Sent from my advertising assimilation device > > > On 18 Jun 2014, at 10:00, Larry McVoy wrote: > > > >> On Wed, Jun 18, 2014 at 11:03:56AM -0400, Norman Wilson wrote: > >> I think I got that > >> from Dennis's retrospective paper, published in the 1984 > >> all-UNIX issue of the Bell Labs Techical Journal, a must-read > >> (along with the late-1970s all-UNIX issue of BSTJ) for anyone > >> on this list. > > > > Indeed. I just packed up my office, all the books, and the BSTJ were the > > only things I kept close. Well, that and the Xinu books, I've got a soft > > spot for those. > > Have Xinu media to go with it? It's something I've been trying to track down. ;) Have you asked Doug? I've copied him (Hey Doug, you should be on this list, all the long time unix nerds seem to be here, lots of fun with memory lane). Cheers, --lm From a.phillip.garcia at gmail.com Thu Jun 19 04:21:30 2014 From: a.phillip.garcia at gmail.com (A. P. Garcia) Date: Wed, 18 Jun 2014 13:21:30 -0500 Subject: [TUHS] Happy birthday, core dumped In-Reply-To: References: <201406181106.s5IB6scu031264@stowe.cs.dartmouth.edu> Message-ID: On Wed, Jun 18, 2014 at 9:43 AM, wrote: > Interesting - what's your source? :-) that's like asking george martin for his source regarding a beatles song... From cowan at mercury.ccil.org Thu Jun 19 04:43:41 2014 From: cowan at mercury.ccil.org (John Cowan) Date: Wed, 18 Jun 2014 14:43:41 -0400 Subject: [TUHS] Happy birthday, core dumped In-Reply-To: <09fffa6e9f2fdb29ab25825d19594d8e.squirrel@webmail.yaccman.com> References: <1403103840.16031.for-standards-violators@oclsc.org> <09fffa6e9f2fdb29ab25825d19594d8e.squirrel@webmail.yaccman.com> Message-ID: <20140618184341.GC19046@mercury.ccil.org> scj at yaccman.com scripsit: > With respect to Dec's OSs vs Unix, I remember a visit from a Dec repair > person who ran "preventive maintenance" on our disc that wiped out the > file system! His excuse was that Dec didn't support "permanent storage" > on the disc at the time... Next time, mount a scratch monkey. -- John Cowan http://www.ccil.org/~cowan cowan at ccil.org The penguin geeks is happy / As under the waves they lark The closed-source geeks ain't happy / They sad cause they in the dark But geeks in the dark is lucky / They in for a worser treat One day when the Borg go belly-up / Guess who wind up on the street. From jnc at mercury.lcs.mit.edu Thu Jun 19 07:21:38 2014 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Wed, 18 Jun 2014 17:21:38 -0400 (EDT) Subject: [TUHS] Happy birthday, core dumped Message-ID: <20140618212138.03B9218C13A@mercury.lcs.mit.edu> > From: "A. P. Garcia" > that's like asking george martin for his source regarding a beatles > song... Reminds me of the person on Wikipedia who tried to argue with me about the 'History of the Internet' article... :-) > From: John Cowan >> scj at yaccman.com scripsit: >> a Dec repair person who ran "preventive maintenance" on our disc that >> wiped out the file system! His excuse was that Dec didn't support >> "permanent storage" on the disc at the time... > Next time, mount a scratch monkey. It was probably a fixed-head disk (RS11 or RS04); can't exactly stick a different pack in! :-) Probably the DEC OS's only used it for swapping or something, since they were both relatively small - 512KB. (Speaking of RS11's: the first PDP-11 I used - an 11/20 running RSTS - had a grand total disk storage of _one_ RS11!) And speaking of putting file systems on them: I recently wrote this command for V6 called 'si' which allowed me (among many other interesting things) to watch the contents of the disk buffer(s). It turns out that even with other packs mounted, the buffer is almost always completely full of blocks from the root device; it makes plain the value of having the root on a _really_ fast disk. I don't know if that usage pattern is because /bin is there, or because pipes get created on the root, or what. When I get up the energy I'll move /bin to another drive (yeah, yeah, I know - good way to lose and create a systen that won't boot, so I'll actually make a _copy_ of /bin and mount it _over_ the original /bin - probably a host of interesting errors there, e.g. if a process has the old /bin as its current dir), and see what the cache contents look like then. Noel From milov at cs.uwlax.edu Tue Jun 17 08:20:24 2014 From: milov at cs.uwlax.edu (=?utf-8?Q?Milo_Velimirovi=C4=87?=) Date: Mon, 16 Jun 2014 17:20:24 -0500 Subject: [TUHS] pdp11 available Message-ID: Greetings, I have a pdp11/84 and various peripherals available to whomever is willing to take them. I'm in La Crosse, Wisconsin, USA. pdp11/84 RX01 TU80 2 cabs of 2ea RA81 Thanks, Milo -- Milo Velimirović La Crosse, Wisconsin 54601 USA 43 48 48 N 91 13 53 W From comer at cs.purdue.edu Thu Jun 19 03:48:10 2014 From: comer at cs.purdue.edu (Douglas Comer) Date: Wed, 18 Jun 2014 13:48:10 -0400 (EDT) Subject: [TUHS] Happy birthday, core dumped Message-ID: <201406181748.s5IHmAjO011186@lancelot.cs.purdue.edu> > > Have Xinu media to go with it? It's something I've been trying to track down. ;) > > Have you asked Doug? I've copied him I just donated my extra copy of Xinu tapes and floppies to the computer museum (along with first editions of the books). > (Hey Doug, you should be on this list, all the long time unix nerds seem to be > here, lots of fun with memory lane). I'd be happy to join. Doug From wkt at tuhs.org Thu Jun 19 08:23:16 2014 From: wkt at tuhs.org (Warren Toomey) Date: Thu, 19 Jun 2014 08:23:16 +1000 Subject: [TUHS] Xinu In-Reply-To: <201406181748.s5IHmAjO011186@lancelot.cs.purdue.edu> References: <201406181748.s5IHmAjO011186@lancelot.cs.purdue.edu> Message-ID: I should mention that I "ported" Xinu over to the Apple ] [ when I was at uni: I transliterated the C code into assembly and used an external 555 timer to generate the clock ticks. Fun times! Warren -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tim.newsham at gmail.com Thu Jun 19 08:33:15 2014 From: tim.newsham at gmail.com (Tim Newsham) Date: Wed, 18 Jun 2014 12:33:15 -1000 Subject: [TUHS] Xinu In-Reply-To: References: <201406181748.s5IHmAjO011186@lancelot.cs.purdue.edu> Message-ID: is your code available? does it run on any of the modern apple][ emus? On Wed, Jun 18, 2014 at 12:23 PM, Warren Toomey wrote: > I should mention that I "ported" Xinu over to the Apple ] [ when I was at > uni: I transliterated the C code into assembly and used an external 555 > timer to generate the clock ticks. Fun times! > > Warren > -- > Sent from my Android phone with K-9 Mail. Please excuse my brevity. > _______________________________________________ > TUHS mailing list > TUHS at minnie.tuhs.org > https://minnie.tuhs.org/mailman/listinfo/tuhs > -- Tim Newsham | www.thenewsh.com/~newsham | @newshtwit | thenewsh.blogspot.com From lm at mcvoy.com Thu Jun 19 07:17:14 2014 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 18 Jun 2014 14:17:14 -0700 Subject: [TUHS] Xinu In-Reply-To: References: <201406181748.s5IHmAjO011186@lancelot.cs.purdue.edu> Message-ID: <20140618211714.GD17033@mcvoy.com> On Thu, Jun 19, 2014 at 08:23:16AM +1000, Warren Toomey wrote: > I should mention that I "ported" Xinu over to the Apple ] [ when > I was at uni: I transliterated the C code into assembly and used an > external 555 timer to generate the clock ticks. Fun times! I loved Xinu, it was sort of like the legal Lions book with source code. And Comer's coding style is pretty similar to mine, simple obvious stuff for 99% of the code, you only got clever when it was actually important. -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From a.phillip.garcia at gmail.com Thu Jun 19 08:39:20 2014 From: a.phillip.garcia at gmail.com (A. P. Garcia) Date: Wed, 18 Jun 2014 17:39:20 -0500 Subject: [TUHS] Xinu In-Reply-To: References: <201406181748.s5IHmAjO011186@lancelot.cs.purdue.edu> Message-ID: On Jun 18, 2014 5:24 PM, "Warren Toomey" wrote: > > I should mention that I "ported" Xinu over to the Apple ] [ when I was at uni: I transliterated the C code into assembly and used an external 555 timer to generate the clock ticks. Fun times! > > Warren > -- nice! i have the lsi-11 editions (1984) of the xinu approach on my shelf, up through the linksys edition (2012). i've spent a small fortune on his books, second only to tanenbaum, i would think. (not a terribly big stallings fan, but he's certainly prolific.) -------------- next part -------------- An HTML attachment was scrubbed... URL: From b4 at gewt.net Thu Jun 19 08:38:37 2014 From: b4 at gewt.net (Cory Smelosky) Date: Wed, 18 Jun 2014 18:38:37 -0400 (EDT) Subject: [TUHS] Happy birthday, core dumped In-Reply-To: <201406181748.s5IHmAjO011186@lancelot.cs.purdue.edu> References: <201406181748.s5IHmAjO011186@lancelot.cs.purdue.edu> Message-ID: On Wed, 18 Jun 2014, Douglas Comer wrote: > > > Have Xinu media to go with it? It's something I've been trying to track down. ;) > > > > Have you asked Doug? I've copied him > > I just donated my extra copy of Xinu tapes and floppies to the computer museum > (along with first editions of the books). > Ahh! I wonder if they'll be making images and PDFs available? > > (Hey Doug, you should be on this list, all the long time unix nerds seem to be > > here, lots of fun with memory lane). > > I'd be happy to join. > It seems like a place that'll help with my crazy projects, too. > Doug > > -- Cory Smelosky http://gewt.net Personal stuff http://gimme-sympathy.org Projects From wkt at tuhs.org Thu Jun 19 08:42:26 2014 From: wkt at tuhs.org (Warren Toomey) Date: Thu, 19 Jun 2014 08:42:26 +1000 Subject: [TUHS] Xinu In-Reply-To: References: <201406181748.s5IHmAjO011186@lancelot.cs.purdue.edu> Message-ID: <20140618224226.GA9897@www.oztivo.net> > On Wed, Jun 18, 2014 at 12:23 PM, Warren Toomey wrote: > > I should mention that I "ported" Xinu over to the Apple ] [ when I was at > > uni: I transliterated the C code into assembly and used an external 555 > > timer to generate the clock ticks. Fun times! On Wed, Jun 18, 2014 at 12:33:15PM -1000, Tim Newsham wrote: > is your code available? does it run on any of the modern apple][ emus? It's available at ftp://minnie.tuhs.org/pub/apple2/apple2xinu.tar.gz with source code, binaries, floopy images and some documentation. No, it won't run on a real Apple ][ without some work. I actually wrote it for an Apple clone which had bank-switched RAM and I made use of that to hide the BASIC ROM and store the OS in the upper 12K. You would also need to simulate a 10 or 20Hz NMI as well :-) Cheers, Warren From reed at reedmedia.net Thu Jun 19 08:55:05 2014 From: reed at reedmedia.net (Jeremy C. Reed) Date: Wed, 18 Jun 2014 17:55:05 -0500 (CDT) Subject: [TUHS] Tree of late BSD releases In-Reply-To: <539DB1D4.3080909@aueb.gr> References: <539DB1D4.3080909@aueb.gr> Message-ID: On Sun, 15 Jun 2014, Diomidis Spinellis wrote: > First, consider this widely reproduced BSD family tree [2]. It has > 4.4BSD-Encumbered derive from a line that includes Net/1, which was > freely redistributable. Wouldn't it be clearer to create two > branches, one with distributions free of AT&T code (4.3 BSD Net/1, 4.3 > BSD Net/2, 4.4 BSD Lite1, 4.4 BSD Lite2) and one with full > distributions (4.4 BSD, ...)? I don't have any preference on that. > On which side would Tahoe and Reno stand? Tahoe included both the proprietary code and the code which could "be freely redistributed". The same with Reno, which was also "within the usual licensing constraints" (as it still had the proprietary code). > Also, the same tree [2] shows 4.4 BSD having as its ancestor 4.3 BSD > Net/2, whereas another tree depicted on Wikipedia [3] has shows 4.4 > BSD and 4.3 BSD Net/2 having as their ancestor 4.3 BSD Reno. What's > the correct genealogy? Note that Net/2 was not a complete or ready-to-use system, so a better genealogy (than those two) may be like: 4.3BSD Reno | \ | \ | 4.3BSD NET/2 | / | / 4.4BSD Alpha > Finally, I have a conflict with release dates. Wikipedia gives the > following dates for Tahoe and Net/1 [4]: > > 4.3 BSD Tahoe June 1988 Announced in June 1988 (see admin/postings/4BSD/INDEX) but even users outside of Berkeley reported bugs specifically against "Tahoe" source tree as early as at least May 1987 (see admin/bugs/4.3BSD-tahoe/). > 4.3 BSD Net/1 June 1989 That date is in McKusick's open sources chapter, but the "Yesterday, Today and Tomorrow" article says Spring 1988. It was announced in November/December 1988 (see admin/postings/4BSD/V1/73 and the /admin/postings/4BSD/INDEX). (930108.oppose.txt also says was distributed in 1988.) (Two Salus books also mention that it was announced at the BSD Workshop in Nov. 1988 to be available.) As for dates for the files, they were probably still updated even after initially released (which you can see in other releases too). From cowan at mercury.ccil.org Thu Jun 19 08:55:28 2014 From: cowan at mercury.ccil.org (John Cowan) Date: Wed, 18 Jun 2014 18:55:28 -0400 Subject: [TUHS] Happy birthday, core dumped In-Reply-To: <20140618212138.03B9218C13A@mercury.lcs.mit.edu> References: <20140618212138.03B9218C13A@mercury.lcs.mit.edu> Message-ID: <20140618225528.GF19046@mercury.ccil.org> Noel Chiappa scripsit: > Reminds me of the person on Wikipedia who tried to argue with me about the > 'History of the Internet' article... :-) To be fair, Wikipedia is supposed to be based on secondary sources. Your memories are a nullary source. -- John Cowan http://www.ccil.org/~cowan cowan at ccil.org BALIN FUNDINUL UZBAD KHAZADDUMU BALIN SON OF FUNDIN LORD OF KHAZAD-DUM From corey at lod.com Thu Jun 19 08:54:15 2014 From: corey at lod.com (Corey Lindsly) Date: Wed, 18 Jun 2014 15:54:15 -0700 (PDT) Subject: [TUHS] Xinu In-Reply-To: <20140618224226.GA9897@www.oztivo.net> Message-ID: <20140618225415.07A2740F3@lod.com> > No, it won't run on a real Apple ][ without some work. I actually wrote > it for an Apple clone which had bank-switched RAM and I made use of that Franklin Ace? I had one of those. Probably still do, somewhere. --corey From doug at cs.dartmouth.edu Thu Jun 19 11:49:48 2014 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Wed, 18 Jun 2014 21:49:48 -0400 Subject: [TUHS] Happy birthday, core dumped Message-ID: <201406190149.s5J1nmP1004744@stowe.cs.dartmouth.edu> They pitched a PDP-10 for a similar reason--hardware to build a bigger Unix on. When a small pot of end-of-year money appeared, they took a PDP-11 instead--serendipitously, because university folks started proving this elegant system on cheap hardware in many projects in small labs, which they never could have done had the system existed on a PDP-10 mainframe. While upper management did not directly cause Unix to be built, their decisions to abandon Multics and not to buy a PDP-10 were notable causes for its creation and spread. Doug > Date: Wed, 18 Jun 2014 07:43:51 -0700 > From: iking at killthewabbit.org > To: tuhs at minnie.tuhs.org,Doug McIlroy > Subject: Re: [TUHS] Happy birthday, core dumped > Message-ID: > Content-Type: text/plain; charset="utf-8" > > Interesting - what's your source? It was also my understanding they used the -7 'because it was there' but that they had pitched for a PDP-10, which had TOPS-10. - Ian > > Sent from my android device. > > -----Original Message----- > From: Doug McIlroy > To: tuhs at minnie.tuhs.org > Sent: Wed, 18 Jun 2014 4:06 AM > Subject: Re: [TUHS] Happy birthday, core dumped > > > > It's always been a bit of a mystery to me why Thompson and Ritchie decided they needed to write a new executive - UNICS - rather than use DECsys. > > It was the other way around. They had conceived a clean, simple, yet > powerful, operating system and needed a machine to build it on. A > cast-off PDP-7 happened to be at hand. > > Doug From cjsvance at gmail.com Thu Jun 19 14:17:27 2014 From: cjsvance at gmail.com (Christopher Vance) Date: Thu, 19 Jun 2014 14:17:27 +1000 Subject: [TUHS] Xinu In-Reply-To: <20140618225415.07A2740F3@lod.com> References: <20140618224226.GA9897@www.oztivo.net> <20140618225415.07A2740F3@lod.com> Message-ID: I ported Xinu to a Motorola 68000 on VME card. I had the luxury of a working C compiler, so there was very little assembly language required (context switch only, from memory). The main effort was in rewriting device drivers for the relevant hardware. The result was used for teaching Operating Systems. Unfortunately, I no longer have the code. On Thu, Jun 19, 2014 at 8:54 AM, Corey Lindsly wrote: > > > No, it won't run on a real Apple ][ without some work. I actually wrote > > it for an Apple clone which had bank-switched RAM and I made use of that > > Franklin Ace? I had one of those. Probably still do, somewhere. > > --corey > > _______________________________________________ > TUHS mailing list > TUHS at minnie.tuhs.org > https://minnie.tuhs.org/mailman/listinfo/tuhs > -- Christopher Vance -------------- next part -------------- An HTML attachment was scrubbed... URL: From usotsuki at buric.co Thu Jun 19 14:39:48 2014 From: usotsuki at buric.co (Steve Nickolas) Date: Thu, 19 Jun 2014 04:39:48 +0000 (UTC) Subject: [TUHS] Xinu In-Reply-To: <20140618224226.GA9897@www.oztivo.net> References: <201406181748.s5IHmAjO011186@lancelot.cs.purdue.edu> <20140618224226.GA9897@www.oztivo.net> Message-ID: On Thu, 19 Jun 2014, Warren Toomey wrote: >> On Wed, Jun 18, 2014 at 12:23 PM, Warren Toomey wrote: >>> I should mention that I "ported" Xinu over to the Apple ] [ when I was at >>> uni: I transliterated the C code into assembly and used an external 555 >>> timer to generate the clock ticks. Fun times! > > On Wed, Jun 18, 2014 at 12:33:15PM -1000, Tim Newsham wrote: >> is your code available? does it run on any of the modern apple][ emus? > > It's available at ftp://minnie.tuhs.org/pub/apple2/apple2xinu.tar.gz with > source code, binaries, floopy images and some documentation. > > No, it won't run on a real Apple ][ without some work. I actually wrote > it for an Apple clone which had bank-switched RAM and I made use of that > to hide the BASIC ROM and store the OS in the upper 12K. You would also > need to simulate a 10 or 20Hz NMI as well :-) Well, I usually assume an Apple ][ at least has THAT ability (as any with at least 64K will) :P, but the NMI issue would be the problem. :/ -uso. From comer at cs.purdue.edu Fri Jun 20 23:05:34 2014 From: comer at cs.purdue.edu (Douglas Comer) Date: Fri, 20 Jun 2014 09:05:34 -0400 Subject: [TUHS] Happy birthday, core dumped Message-ID: > Ahh! I wonder if they'll be making images and PDFs available? If you want to check, my contact has been: William Harnack Doug From wkt at tuhs.org Sat Jun 28 17:02:06 2014 From: wkt at tuhs.org (Warren Toomey) Date: Sat, 28 Jun 2014 17:02:06 +1000 Subject: [TUHS] 40 years of Unix CACM Article In-Reply-To: References: Message-ID: Just in from an early Unix devotee. Warren -------- Original Message -------- From: Dave Horsfall Sent: 28 June 2014 16:14:18 AEST To: Auug Talk Subject: [AUUG-Talk]: 40 years of Unix Next month sees the 40th anniversary of the article "The Unix Timesharing System" published in Communications of the ACM; I was at UNSW at the time, and we bought the first tape for subsequent distribution. At the time its only competitor was RSTS-11, and to a lesser extent RSX-11D and RSX-11M (all DEC systems). It saw CP/M vanish, MS-DOS come and go, NT tried to challenge it, and even Windows hasn't beaten it. It spawned Linux, which Billy Gates regarded as a serious threat ("any box running Linux is not running Windows") and even tried a smear campaign against it. Unix was a design that "just worked" because K&R simply got it right, right from the start. It'll never go away. -- Dave _______________________________________________ Applix 1616 mailing list Applix-L at object-craft.com.au https://www.object-craft.com.au/cgi-bin/mailman/listinfo/applix-l _______________________________________________ Talk - The AUUG discussion list. Talk at lists.auug.org.au https://lists.auug.org.au/listinfo/talk -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wkt at tuhs.org Sat Jun 28 17:28:11 2014 From: wkt at tuhs.org (Warren Toomey) Date: Sat, 28 Jun 2014 17:28:11 +1000 Subject: [TUHS] 40 years of Unix CACM Article In-Reply-To: <60AED4C0-D500-4666-823C-F61D929BA7B0@ieee.org> References: <60AED4C0-D500-4666-823C-F61D929BA7B0@ieee.org> Message-ID: <20944a6d-6edc-480e-8563-730e5b243cc4@email.android.com> Knowing Dave and his long history with Unix, I suspect it was simply a typo. Just like vi commands are now hardwired into my fingers, I guess K&R is imprinted on his fingers. Cheers, Warren On 28 June 2014 17:12:14 AEST, Armando Stettner wrote: >K&R usually refers to Brian Kernighan and Dennis Ritchie, writers of >the (I think) first book on C. If there were two people to acknowledge >for getting it right, it would be Ken and Dennis. > > aps > > >Begin forwarded message: > >> From: Warren Toomey >> Subject: [TUHS] 40 years of Unix CACM Article >> Date: June 28, 2014 at 12:02:06 AM PDT >> To: tuhs at tuhs.org >> >> Just in from an early Unix devotee. >> Warren >> >> From: Dave Horsfall >> Sent: 28 June 2014 16:14:18 AEST >> To: Auug Talk >> Subject: [AUUG-Talk]: 40 years of Unix >> >> Next month sees the 40th anniversary of the article "The Unix >Timesharing >> System" published in Communications of the ACM; I was at UNSW at the >time, >> and we bought the first tape for subsequent distribution. >> >> At the time its only competitor was RSTS-11, and to a lesser extent >> RSX-11D and RSX-11M (all DEC systems). It saw CP/M vanish, MS-DOS >come >> and go, NT tried to challenge it, and even Windows hasn't beaten it. >> >> It spawned Linux, which Billy Gates regarded as a serious threat >("any box >> running Linux is not running Windows") and even tried a smear >campaign >> against it. >> >> Unix was a design that "just worked" because K&R simply got it right, > >> right from the start. >> >> It'll never go away. >> >> -- Dave >> >> Applix 1616 mailing list >> Applix-L at object-craft.com.au >> https://www.object-craft.com.au/cgi-bin/mailman/listinfo/applix-l >> >> Talk - The AUUG discussion list. >> Talk at lists.auug.org.au >> https://lists.auug.org.au/listinfo/talk >> >> -- >> Sent from my Android phone with K-9 Mail. Please excuse my >brevity._______________________________________________ >> TUHS mailing list >> TUHS at minnie.tuhs.org >> https://minnie.tuhs.org/mailman/listinfo/tuhs -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: