From kevin.bowling at kev009.com Tue Nov 1 04:21:40 2022 From: kevin.bowling at kev009.com (Kevin Bowling) Date: Mon, 31 Oct 2022 11:21:40 -0700 Subject: [TUHS] Four windowing systems on SunOS Message-ID: Cameron Kaiser has written up a nice survey on some windowing systems that can run under OS/MP or SunOS https://oldvcr.blogspot.com/2022/10/if-one-guis-not-enough-for-your-sparc.html From lm at mcvoy.com Tue Nov 1 05:14:01 2022 From: lm at mcvoy.com (Larry McVoy) Date: Mon, 31 Oct 2022 12:14:01 -0700 Subject: [TUHS] Four windowing systems on SunOS In-Reply-To: References: Message-ID: <20221031191401.GN22806@mcvoy.com> Sunview was a toolkit - a really nice one in my opinion, every api had a set of defaults and a key, so you could call sv_whatever(SV_DONE) and did whatever with the default values. But you could override the defaults like so sv_whatever(SV_SOMEKEY, some_value, SV_DONE). It kept the system from being very verbose. People like Sunview's api enough that there was an Xview toolkit which was Sunview ported to X10/X11. On Mon, Oct 31, 2022 at 11:21:40AM -0700, Kevin Bowling wrote: > Cameron Kaiser has written up a nice survey on some windowing systems > that can run under OS/MP or SunOS > https://oldvcr.blogspot.com/2022/10/if-one-guis-not-enough-for-your-sparc.html -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From jon at fourwinds.com Tue Nov 1 05:17:59 2022 From: jon at fourwinds.com (Jon Steinhart) Date: Mon, 31 Oct 2022 12:17:59 -0700 Subject: [TUHS] Four windowing systems on SunOS In-Reply-To: <20221031191401.GN22806@mcvoy.com> References: <20221031191401.GN22806@mcvoy.com> Message-ID: <202210311917.29VJHxe6110870@darkstar.fourwinds.com> Larry McVoy writes: > Sunview was a toolkit - a really nice one in my opinion, every api had > a set of defaults and a key, so you could call sv_whatever(SV_DONE) > and did whatever with the default values. But you could override the > defaults like so sv_whatever(SV_SOMEKEY, some_value, SV_DONE). It > kept the system from being very verbose. > > People like Sunview's api enough that there was an Xview toolkit which > was Sunview ported to X10/X11. Yeah, but it had its own issues. I did an emergency late night and weekend consulting contract with Sun because Xview kept crashing. Turns out that the code had some very suspect pointer dereferencing that worked until the SPARC processors came along and barfed at unaligned accesses. Jon From crossd at gmail.com Tue Nov 1 05:21:56 2022 From: crossd at gmail.com (Dan Cross) Date: Mon, 31 Oct 2022 15:21:56 -0400 Subject: [TUHS] Four windowing systems on SunOS In-Reply-To: <202210311917.29VJHxe6110870@darkstar.fourwinds.com> References: <20221031191401.GN22806@mcvoy.com> <202210311917.29VJHxe6110870@darkstar.fourwinds.com> Message-ID: On Mon, Oct 31, 2022 at 3:18 PM Jon Steinhart wrote: > Larry McVoy writes: > > Sunview was a toolkit - a really nice one in my opinion, every api had > > a set of defaults and a key, so you could call sv_whatever(SV_DONE) > > and did whatever with the default values. But you could override the > > defaults like so sv_whatever(SV_SOMEKEY, some_value, SV_DONE). It > > kept the system from being very verbose. > > > > People like Sunview's api enough that there was an Xview toolkit which > > was Sunview ported to X10/X11. > > Yeah, but it had its own issues. I did an emergency late night and weekend > consulting contract with Sun because Xview kept crashing. Turns out that > the code had some very suspect pointer dereferencing that worked until the > SPARC processors came along and barfed at unaligned accesses. That sounds like a ton of codebases, though. I remember trying to port an APL interpreter to 64-bit, and giving up; too much type puning of pointers through int's. - Dan C. From lm at mcvoy.com Tue Nov 1 05:26:44 2022 From: lm at mcvoy.com (Larry McVoy) Date: Mon, 31 Oct 2022 12:26:44 -0700 Subject: [TUHS] Four windowing systems on SunOS In-Reply-To: <202210311917.29VJHxe6110870@darkstar.fourwinds.com> References: <20221031191401.GN22806@mcvoy.com> <202210311917.29VJHxe6110870@darkstar.fourwinds.com> Message-ID: <20221031192644.GO22806@mcvoy.com> On Mon, Oct 31, 2022 at 12:17:59PM -0700, Jon Steinhart wrote: > Larry McVoy writes: > > Sunview was a toolkit - a really nice one in my opinion, every api had > > a set of defaults and a key, so you could call sv_whatever(SV_DONE) > > and did whatever with the default values. But you could override the > > defaults like so sv_whatever(SV_SOMEKEY, some_value, SV_DONE). It > > kept the system from being very verbose. > > > > People like Sunview's api enough that there was an Xview toolkit which > > was Sunview ported to X10/X11. > > Yeah, but it had its own issues. I did an emergency late night and weekend > consulting contract with Sun because Xview kept crashing. Turns out that > the code had some very suspect pointer dereferencing that worked until the > SPARC processors came along and barfed at unaligned accesses. Oh yeah, been there, fixed that. From beebe at math.utah.edu Tue Nov 1 05:33:28 2022 From: beebe at math.utah.edu (Nelson H. F. Beebe) Date: Mon, 31 Oct 2022 13:33:28 -0600 Subject: [TUHS] Four windowing systems on SunOS Message-ID: Larry McVoy reports today: >> People like Sunview's api enough that there was an Xview toolkit which >> was Sunview ported to X10/X11. The interface was nicely documented in three editions of a book (I have no entry for the second edition): @String{pub-ORA = "O'Reilly \& {Associates, Inc.}"} @String{pub-ORA:adr = "981 Chestnut Street, Newton, MA 02164, USA"} @Book{Heller:1990:XPM, author = "Dan Heller", title = "{XView} Programming Manual", volume = "7", publisher = pub-ORA, address = pub-ORA:adr, pages = "xxviii + 557", year = "1990", ISBN = "0-937175-38-2", ISBN-13 = "978-0-937175-38-5", LCCN = "QA76.76.W56 D44 v.7 1990", bibdate = "Tue Dec 14 22:55:18 1993", bibsource = "http://www.math.utah.edu/pub/tex/bib/master.bib", acknowledgement = ack-nhfb, } @Book{Heller:1991:XPM, author = "Dan Heller", title = "{XView} Programming Manual", volume = "7A", publisher = pub-ORA, address = pub-ORA:adr, edition = "Third", pages = "xxxvii + 729", month = sep, year = "1991", ISBN = "0-937175-87-0", ISBN-13 = "978-0-937175-87-3", LCCN = "QA76.76.W56 H447 1990", bibdate = "Mon Jan 3 17:55:53 1994", bibsource = "http://www.math.utah.edu/pub/tex/bib/master.bib", series = "The Definitive guides to the X Window System", acknowledgement = ack-nhfb, } I have the first edition on a shelf near my campus office chair, and continue to use olvwm as my window manager on multiple O/Ses, for 30+ years. Every window manager designed since seems to fail to understand the importance of user customizable, and pinnable, menus, which I exploit to the hilt. The menu customization goes into a single, easy to edit, text file, $HOME/.openwin-menu. Compare that to the Gnome desktop, with hundreds of files, many of them binary, stored in hidden directories under $HOME, and for which any corruption breaks the window system, and prevents login (except via a GUI console). Also. olvwm does not litter a default desktop with icons for applications that many of use would never use: just a simple blank desktop, with menu popups bound to mouse buttons. With olvwm, you can have any number of virtual desktops, not just the 2 or 4 offered by more modern window manaugers, and unlike some of those, windows can be dragged between desktops. ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah - - 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 ron at ronnatalie.com Tue Nov 1 05:59:44 2022 From: ron at ronnatalie.com (Ronald Natalie) Date: Mon, 31 Oct 2022 19:59:44 +0000 Subject: [TUHS] Four windowing systems on SunOS In-Reply-To: <20221031192644.GO22806@mcvoy.com> References: <20221031191401.GN22806@mcvoy.com> <202210311917.29VJHxe6110870@darkstar.fourwinds.com> <20221031192644.GO22806@mcvoy.com> Message-ID: My favorite SunView story was the day I was working in the Pentagon (I was ron at hq.af.mil for a while). One of the Sun workstations had a Sunview screen lock running and the guy I was visiting was on the phone. I told him I’d just unlock the thing myself. I promptly set forth to do so and got it open. He quickly said, “I have to hang up and go check on something,” and came over and asked how I’d done that. The screen lock was just a very large window forced to the top of everything on the screen. If you hit the hot key to iconify it, you had a fraction of a second to interact before it reasserted itself. So you keep hitting iconify and maybe getting a letter or two typed into one of the one terminal windows at a time. You run ps, find the pid of the screen lock process, and kill it. -Ron From tuhs at tuhs.org Tue Nov 1 07:52:03 2022 From: tuhs at tuhs.org (Grant Taylor via TUHS) Date: Mon, 31 Oct 2022 15:52:03 -0600 Subject: [TUHS] Four windowing systems on SunOS In-Reply-To: References: <20221031191401.GN22806@mcvoy.com> <202210311917.29VJHxe6110870@darkstar.fourwinds.com> Message-ID: <16d7a543-8c34-3663-f0d7-14b588683d6c@spamtrap.tnetconsulting.net> On 10/31/22 1:21 PM, Dan Cross wrote: > That sounds like a ton of codebases, though. I remember trying to port > an APL interpreter to 64-bit, and giving up; too much type puning of > pointers through int's. This reminds me of the stories I've heard about Microsoft's inability to port Pinball to /their/ 64-bit processor, the Itanium. No, not their copy of /AMD/'s 64-bit extension on Intel's x86 architecture. ;-) -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4017 bytes Desc: S/MIME Cryptographic Signature URL: From rtomek at ceti.pl Tue Nov 1 13:25:19 2022 From: rtomek at ceti.pl (Tomasz Rola) Date: Tue, 1 Nov 2022 04:25:19 +0100 Subject: [TUHS] Four windowing systems on SunOS In-Reply-To: References: Message-ID: On Mon, Oct 31, 2022 at 01:33:28PM -0600, Nelson H. F. Beebe wrote: > Larry McVoy reports today: > > >> People like Sunview's api enough that there was an Xview toolkit which > >> was Sunview ported to X10/X11. > > The interface was nicely documented in three editions of a book (I > have no entry for the second edition): [...] > > I have the first edition on a shelf near my campus office chair, and > continue to use olvwm as my window manager on multiple O/Ses, for 30+ > years. I think (that was so long ago) I had tried each of the guis mentioned in the blog post, some of them for few hours only. X11 was the best for me, and then I played with olwm. And then I discovered olvwm and the concept of virtual desktop - yay, that was really great. Later I was moved to another SunOS workstation which only had olwm and they would not install anything when lowly life form asked for it. So I ftp-ed it from previous workstation and tried, and it occurred that binary was compatible and ran well... yay, again. A bit later I had installed my first Linux (Slackware it was) and with it came olvwm, so I was thrilled to have "emulated" workstation at home. After that point, I gradually replaced every element of my desktop environment with other stuff - csh became sh became bash, olvwm became fvwm with even more virtual desktops, some text editor became emacs and so on. > Every window manager designed since seems to fail to understand the > importance of user customizable, and pinnable, menus, which I exploit > to the hilt. The menu customization goes into a single, easy to edit, > text file, $HOME/.openwin-menu. I am not sure menus are that much important in my life. I liked fvwm more, because I could more or less easily customize the key shortcuts for various windows operations (maximize, iconify, resize, resize back etc), sometimes in combination with mouse button. This and quickly moving between desktops, arranging windows so neighbouring desktops contain parts of the workflow. Nowadays I prefer to run stuff from the terminal, via proper commands. If it goes wonky, I can see what happened. This makes me a bit more mess with more terminals but hey, iconify and hooray. I only very rarely use menus. > Compare that to the Gnome desktop, with hundreds of files, many of > them binary, stored in hidden directories under $HOME, and for which > any corruption breaks the window system, and prevents login (except > via a GUI console). Ah, Gnome and KDE, both are - for me at least - too big and too hard to manage if something goes wrong. Once I started KDE after upgrade (ok, that was decade and some years ago, it must have improved by now), and it went blank at once and started to do 100% cpu and God knows what (because I could not locate any messages about what it was doing). Never solved this problem, never was willing to spend time on it, switched back to fvwm and moved on. From preliminary diagnostics, I suspect it had something to do with enormous number of html files buried somewhere on my disc. The lousy thing tried to catalogue it and probably went into O(n^k) loop. Those environments are nice to the eye but cannot cope when something is beyound recognition of their developers. But they are indispensable when one installs Linux for someone who really is not going to program their desktop, or edit config files. For me, in such cases xfce is the nice mix of usability and acceptable looks. -- Regards, Tomasz Rola -- ** A C programmer asked whether computer had Buddha's nature. ** ** As the answer, master did "rm -rif" on the programmer's home ** ** directory. And then the C programmer became enlightened... ** ** ** ** Tomasz Rola mailto:tomasz_rola at bigfoot.com ** From lproven at gmail.com Tue Nov 1 21:02:59 2022 From: lproven at gmail.com (Liam Proven) Date: Tue, 1 Nov 2022 12:02:59 +0100 Subject: [TUHS] Four windowing systems on SunOS In-Reply-To: <16d7a543-8c34-3663-f0d7-14b588683d6c@spamtrap.tnetconsulting.net> References: <20221031191401.GN22806@mcvoy.com> <202210311917.29VJHxe6110870@darkstar.fourwinds.com> <16d7a543-8c34-3663-f0d7-14b588683d6c@spamtrap.tnetconsulting.net> Message-ID: On Mon, 31 Oct 2022 at 22:55, Grant Taylor via TUHS wrote: > > This reminds me of the stories I've heard about Microsoft's inability to > port Pinball to /their/ 64-bit processor, the Itanium. (?) Itanium was Intel's, not Microsoft's. > No, not their copy of /AMD/'s 64-bit extension on Intel's x86 > architecture. ;-) Again, not MICROS~1: Intel. MS is the reason Intel supports x86-64. When it saw that Itanium was failing, just like i860, just like iAPX-32, Intel built its own 64-bit extension to x86-32, to compete with AMD64. MS told Intel: look, we are already supporting *one* deadbeat unprofitable 64-bit arch of yours (i.e. Itanic.) We're not supporting *two*. No. You make it compatible with AMD's, because we're doing just one 64-bit x86 and we're already working on it. -- Liam Proven ~ Profile: https://about.me/liamproven Email: lproven at cix.co.uk ~ gMail/gTalk/FB: lproven at gmail.com Twitter/LinkedIn: lproven ~ Skype: liamproven UK: (+44) 7939-087884 ~ Czech [+ WhatsApp/Telegram/Signal]: (+420) 702-829-053 From sjenkin at canb.auug.org.au Wed Nov 2 12:36:34 2022 From: sjenkin at canb.auug.org.au (steve jenkin) Date: Wed, 2 Nov 2022 13:36:34 +1100 Subject: [TUHS] Early Unix and Keyboard Skills Message-ID: I’m re-reading Brian Kernighan’s book on Early Unix (‘Unix: A History & Memoir’) and he mentions the (on disk) documentation that came with Unix - something that made it stand out, even for some decades. Doug McIlroy has commented on v2-v3 (1972-73?) being an extremely productive year for Ken & Dennis. But as well, they wrote papers and man pages, probably more. I’ve never heard anyone mention keyboard skills with the people of the CSRC - doesn’t anyone know? There’s at least one Internet meme that highly productive coders necessarily have good keyboard skills, which leads to also producing documentation or, at least, not avoiding it entirely, as often happens commercially. Underlying this is something I once caught as a random comment: The commonality of skills between Writing & Coding. Does anyone has any good refs for this crossover? Is it a real effect or a biased view. That great programmers are also “good writers”: takes time & focus, clarity of vision, deliberate intent and many revisions, chopping away the cruft that’s isn’t “the thing” and “polishing”, not rushing it out the door. Ken is famous for his brevity and succinct statements. Not sure if that’s a personal preference, a mastered skill or “economy in everything”. steve j ========= A Research UNIX Reader: Annotated Excerpts from the Programmer's Manual, 1971-1986 M.D. McIlroy pg 10 3.4. Languages CC (v2 page 52) V2 saw a burst of languages: a new TMG, a B that worked in both core-resident and software-paged versions, the completion of Fortran IV (Thompson and Ritchie), and Ritchie's first C, conceived as B with data types. In that furiously productive year Thompson and Ritchie together wrote and debugged about 100,000 lines of production code. ========= Programming's Dirtiest Little Secret Wednesday, September 10, 2008 It's just simple arithmetic. If you spend more time hammering out code, then in order to keep up, you need to spend less time doing something else. But when it comes to programming, there are only so many things you can sacrifice! You can cut down on your documentation. You can cut down on commenting your code. You can cut down on email conversations and participation in online discussions, preferring group discussions and hallway conversations. And... well, that's about it. So guess what non-touch-typists sacrifice? All of it, man. They sacrifice all of it. Touch typists can spot an illtyperate programmer from a mile away. They don't even have to be in the same room. For starters, non-typists are almost invisible. They don't leave a footprint in our online community. ========= -- Steve Jenkin, IT Systems and Design 0412 786 915 (+61 412 786 915) PO Box 38, Kippax ACT 2615, AUSTRALIA mailto:sjenkin at canb.auug.org.au http://members.tip.net.au/~sjenkin From rdm at cfcl.com Wed Nov 2 13:46:09 2022 From: rdm at cfcl.com (Rich Morin) Date: Tue, 1 Nov 2022 20:46:09 -0700 Subject: [TUHS] early Unix papers, from Jim Joyce Message-ID: <28C0C8F2-3FA0-4CE1-AA41-6E8CD42D8C34@cfcl.com> Some of you may recall my friend Jim Joyce, who was an early proponent of Unix. IIRC, he taught the first course on Unix at UCB. Later on, he started and ran mail-order bookstores and seminars specializing in Unix-related topics, helped to found Unix Review, etc. In any event, I have about a cubic foot of early Unix papers, saved from Jim's files after his death. It's quite likely that all of these papers are already available in collections, but I'd like to make sure that any exceptions don't get lost. Also, the printed copies may have some independent historical merit. Suggestions? -r From jnc at mercury.lcs.mit.edu Wed Nov 2 16:07:30 2022 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Wed, 2 Nov 2022 02:07:30 -0400 (EDT) Subject: [TUHS] early Unix papers, from Jim Joyce Message-ID: <20221102060730.A114A18C08A@mercury.lcs.mit.edu> > From: Rich Morin > Suggestions? Step #0: make a list of what's there, and post it here. That's crucial input to any recommendation. Noel From e5655f30a07f at ewoof.net Wed Nov 2 16:53:25 2022 From: e5655f30a07f at ewoof.net (Michael =?utf-8?B?S2rDtnJsaW5n?=) Date: Wed, 2 Nov 2022 06:53:25 +0000 Subject: [TUHS] Early Unix and Keyboard Skills In-Reply-To: References: Message-ID: On 2 Nov 2022 13:36 +1100, from sjenkin at canb.auug.org.au (steve jenkin): > There’s at least one Internet meme that highly productive coders > necessarily have good keyboard skills, which leads to also producing > documentation or, at least, not avoiding it entirely, as often > happens commercially. I wouldn't be so sure that this necessarily follows. Good keyboard skills definitely help with the mechanics of typing code as well as text, I'll certainly grant that; but someone can be a good typist yet write complete gibberish, or be a poor/slow typist and _by necessity_ need to consider each word that they use because typing an extra sentence takes them so long. If it takes you ten seconds to type out a normal sentence, revising becomes less of an issue than if typing out the same sentence takes a minute or a minute and a half. Also, certainly in my case and I doubt that I'm alone, a lot of my time "coding" isn't spent doing the mechanics of "writing code", but rather considering possible solutions to a problem, and what the consequences would be of different choices. That part of the software development process is essentially unaffected by how good one is as a typist, and I expect that the effect would be even more pronounced for someone using something like an ASR-33 and edlin, than a modern computer and visual editor. Again, the longer it takes to revise something, the more it makes sense to get it right on the first attempt, even if that means some preparatory work up-front. Writing documentation is probably more an issue of mindset and being allowed the time, than it is a question of how good one is as a typist. -- 🪶 Michael Kjörling 🏡 https://michael.kjorling.se “Remember when, on the Internet, nobody cared that you were a dog?” From robpike at gmail.com Wed Nov 2 17:11:26 2022 From: robpike at gmail.com (Rob Pike) Date: Wed, 2 Nov 2022 18:11:26 +1100 Subject: [TUHS] Early Unix and Keyboard Skills In-Reply-To: References: Message-ID: Neither ken nor dmr were impressive typists. In fact few programmers were then, at least of my acquaintance. In the 1970s Bell Labs created the Getset - think of it as an early wired smartphone, or a Minitel, with a little screen and keyboard. It cost quite a bit but was a cool gadget so the executives all got one. But, in fascinating contrast to the Blackberry a generation later, no one would touch it - literally - because it had a keyboard, and keyboards were for (female) secretaries, not (male) executives. The product, although well ahead of its time, was a complete failure due to the cultural bias then. There may be a good sociology paper in there somewhere. I'm not saying K&D shared this blinkered view, not at all, just that typing skills were not de facto back then. Some of the folks were even two-finger jabbers. I was a little younger and a faster typist than most of the others, and I am not a good typist by any modern standard. bwk was one who could smash out the text faster than many. His having learned on a teletype, the keyboard would resound with the impact of his forceful keystrokes. -rob On Wed, Nov 2, 2022 at 5:53 PM Michael Kjörling wrote: > On 2 Nov 2022 13:36 +1100, from sjenkin at canb.auug.org.au (steve jenkin): > > There’s at least one Internet meme that highly productive coders > > necessarily have good keyboard skills, which leads to also producing > > documentation or, at least, not avoiding it entirely, as often > > happens commercially. > > I wouldn't be so sure that this necessarily follows. Good keyboard > skills definitely help with the mechanics of typing code as well as > text, I'll certainly grant that; but someone can be a good typist yet > write complete gibberish, or be a poor/slow typist and _by necessity_ > need to consider each word that they use because typing an extra > sentence takes them so long. If it takes you ten seconds to type out a > normal sentence, revising becomes less of an issue than if typing out > the same sentence takes a minute or a minute and a half. > > Also, certainly in my case and I doubt that I'm alone, a lot of my > time "coding" isn't spent doing the mechanics of "writing code", but > rather considering possible solutions to a problem, and what the > consequences would be of different choices. That part of the software > development process is essentially unaffected by how good one is as a > typist, and I expect that the effect would be even more pronounced for > someone using something like an ASR-33 and edlin, than a modern > computer and visual editor. Again, the longer it takes to revise > something, the more it makes sense to get it right on the first > attempt, even if that means some preparatory work up-front. > > Writing documentation is probably more an issue of mindset and being > allowed the time, than it is a question of how good one is as a > typist. > > -- > 🪶 Michael Kjörling 🏡 https://michael.kjorling.se > “Remember when, on the Internet, nobody cared that you were a dog?” > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From e5655f30a07f at ewoof.net Wed Nov 2 17:32:45 2022 From: e5655f30a07f at ewoof.net (Michael =?utf-8?B?S2rDtnJsaW5n?=) Date: Wed, 2 Nov 2022 07:32:45 +0000 Subject: [TUHS] early Unix papers, from jim Joyce In-Reply-To: <20221102060730.A114A18C08A@mercury.lcs.mit.edu> References: <28C0C8F2-3FA0-4CE1-AA41-6E8CD42D8C34@cfcl.com> <20221102060730.A114A18C08A@mercury.lcs.mit.edu> Message-ID: On 2 Nov 2022 02:07 -0400, from jnc at mercury.lcs.mit.edu (Noel Chiappa): >> Suggestions? > > Step #0: make a list of what's there, and post it here. That's crucial input > to any recommendation. Agreed. Also, step #1: Before sending them off somewhere or tossing them, consider whether some place like the Computer History Museum might be interested in them. -- 🪶 Michael Kjörling 🏡 https://michael.kjorling.se “Remember when, on the Internet, nobody cared that you were a dog?” From michael at casadevall.pro Wed Nov 2 18:55:20 2022 From: michael at casadevall.pro (Michael Casadevall) Date: Wed, 2 Nov 2022 04:55:20 -0400 Subject: [TUHS] Four windowing systems on SunOS In-Reply-To: <16d7a543-8c34-3663-f0d7-14b588683d6c@spamtrap.tnetconsulting.net> References: <20221031191401.GN22806@mcvoy.com> <202210311917.29VJHxe6110870@darkstar.fourwinds.com> <16d7a543-8c34-3663-f0d7-14b588683d6c@spamtrap.tnetconsulting.net> Message-ID: I extensively researched this; there are infact copies of Pinball for 64-bit platforms: https://www.youtube.com/watch?v=3EPTfOTC4Jw&t=47s Pinball had problems relating to 64-bit FPU precision (and this can actually be reproduced by fiddling with FPU flags), but it did ship in Windows XP x64 Professional. Michael On Mon, Oct 31, 2022 at 5:55 PM Grant Taylor via TUHS wrote: > On 10/31/22 1:21 PM, Dan Cross wrote: > > That sounds like a ton of codebases, though. I remember trying to port > > an APL interpreter to 64-bit, and giving up; too much type puning of > > pointers through int's. > > This reminds me of the stories I've heard about Microsoft's inability to > port Pinball to /their/ 64-bit processor, the Itanium. > > No, not their copy of /AMD/'s 64-bit extension on Intel's x86 > architecture. ;-) > > > > -- > Grant. . . . > unix || die > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From steffen at sdaoden.eu Wed Nov 2 22:13:52 2022 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Wed, 02 Nov 2022 13:13:52 +0100 Subject: [TUHS] Early Unix and Keyboard Skills In-Reply-To: References: Message-ID: <20221102121352.MhcLw%steffen@sdaoden.eu> steve jenkin wrote in : ... |I’ve never heard anyone mention keyboard skills with the people of \ |the CSRC - doesn’t anyone know? What i personally find more fascinating (given that -- in the right condition -- i type pretty fast even in total darkness but darkest possible monitor brightness) is the multitaskability some show, in respect to combination of mouse and keyboard (or even dual-mouse if i remember a message of Rob Pike right). I once watched a video on the google tube of Russ Cox dancing acme doing go testing, could be it is [1]. When he starts to actually work a bit (late on iirc), that is thrilling, i could never select / paste (kill snarf yank what do i know) that fast. [1] https://www.youtube.com/watch?v=dP1xVpMPn8M --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From douglas.mcilroy at dartmouth.edu Wed Nov 2 22:16:41 2022 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Wed, 2 Nov 2022 08:16:41 -0400 Subject: [TUHS] Early Unix and Keyboard Skills Message-ID: > Touch typists can spot an illtyperate programmer from a mile away. > They don't even have to be in the same room. I once thought of touch typing as employment of all fingers. Then I met Fred Grampp. Using only four fingers, he typed as fast as most good programmers. He knew where to hit, with a kinesthetic sense that had progressed beyond dependence on "home keys". It was an athletic performance, astonishing to watch. Doug From steffen at sdaoden.eu Wed Nov 2 22:24:32 2022 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Wed, 02 Nov 2022 13:24:32 +0100 Subject: [TUHS] Early Unix and Keyboard Skills In-Reply-To: <20221102121352.MhcLw%steffen@sdaoden.eu> References: <20221102121352.MhcLw%steffen@sdaoden.eu> Message-ID: <20221102122432.og3EI%steffen@sdaoden.eu> Steffen Nurpmeso wrote in <20221102121352.MhcLw%steffen at sdaoden.eu>: |steve jenkin wrote in | : | ... ||I’ve never heard anyone mention keyboard skills with the people of \ ||the CSRC - doesn’t anyone know? | |What i personally find more fascinating (given that -- in the |right condition -- i type pretty fast even in total darkness but |darkest possible monitor brightness) is the multitaskability some |show, in respect to combination of mouse and keyboard (or even |dual-mouse if i remember a message of Rob Pike right). I once ... I once had a very small infrared / PS/2 keyboard with a track ball at the upper right corner, and the buttons on the upper left) where middle finger and forefinger only had to be moved a bit, but the heel of hand(s) could remain (only twisted a bit). That allowed for pretty good precision and speed. But i think it was still not that of Russ Cox and acme and external mouse/mice. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From jpl.jpl at gmail.com Wed Nov 2 22:26:35 2022 From: jpl.jpl at gmail.com (John P. Linderman) Date: Wed, 2 Nov 2022 08:26:35 -0400 Subject: [TUHS] Early Unix and Keyboard Skills In-Reply-To: <20221102121352.MhcLw%steffen@sdaoden.eu> References: <20221102121352.MhcLw%steffen@sdaoden.eu> Message-ID: When I was in high school (in the early sixties) I tried to sign up for typing, which was taught on manual typewriters. I was told that the class was for girls only, and I was turned away. I never did develop good typing skills. I'm pretty much a two-fingered typist. Ironically, I have probably done more typing than 90% of the female classmates who were allowed to take the class. Precision figured mightily in those days, which may also have pre-dated white-out. Eliminating an error was a big deal. Now it's dead easy, and auto-correct has already fixed several errors in this message. On Wed, Nov 2, 2022 at 8:14 AM Steffen Nurpmeso wrote: > steve jenkin wrote in > : > ... > |I’ve never heard anyone mention keyboard skills with the people of \ > |the CSRC - doesn’t anyone know? > > What i personally find more fascinating (given that -- in the > right condition -- i type pretty fast even in total darkness but > darkest possible monitor brightness) is the multitaskability some > show, in respect to combination of mouse and keyboard (or even > dual-mouse if i remember a message of Rob Pike right). I once > watched a video on the google tube of Russ Cox dancing acme doing > go testing, could be it is [1]. When he starts to actually work > a bit (late on iirc), that is thrilling, i could never select / > paste (kill snarf yank what do i know) that fast. > > [1] https://www.youtube.com/watch?v=dP1xVpMPn8M > > --steffen > | > |Der Kragenbaer, The moon bear, > |der holt sich munter he cheerfully and one by one > |einen nach dem anderen runter wa.ks himself off > |(By Robert Gernhardt) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stewart at serissa.com Wed Nov 2 23:07:31 2022 From: stewart at serissa.com (Larry Stewart) Date: Wed, 2 Nov 2022 09:07:31 -0400 Subject: [TUHS] Early Unix and Keyboard Skills In-Reply-To: References: Message-ID: <7A8AFF11-5383-4FD3-8FA4-D262B30DC6A1@serissa.com> In 1969 at the end of 9 th grade I got a foot injury that kept me on crutches for the summer so I took summer school typing. very worthwhile. I think 90% of the class were young women. My parents encouraged it mostly because it would make writing term papers much easier, which it did, but of course it had many computing benefits as well. the ancient typewriters had really heavy keys with long strokes. Much like teletypes. > On Nov 2, 2022, at 8:27 AM, John P. Linderman wrote: > >  > When I was in high school (in the early sixties) I tried to sign up for typing, which was taught on manual typewriters. I was told that the class was for girls only, and I was turned away. I never did develop good typing skills. I'm pretty much a two-fingered typist. Ironically, I have probably done more typing than 90% of the female classmates who were allowed to take the class. > > Precision figured mightily in those days, which may also have pre-dated white-out. Eliminating an error was a big deal. Now it's dead easy, and auto-correct has already fixed several errors in this message. > >> On Wed, Nov 2, 2022 at 8:14 AM Steffen Nurpmeso wrote: >> steve jenkin wrote in >> : >> ... >> |I’ve never heard anyone mention keyboard skills with the people of \ >> |the CSRC - doesn’t anyone know? >> >> What i personally find more fascinating (given that -- in the >> right condition -- i type pretty fast even in total darkness but >> darkest possible monitor brightness) is the multitaskability some >> show, in respect to combination of mouse and keyboard (or even >> dual-mouse if i remember a message of Rob Pike right). I once >> watched a video on the google tube of Russ Cox dancing acme doing >> go testing, could be it is [1]. When he starts to actually work >> a bit (late on iirc), that is thrilling, i could never select / >> paste (kill snarf yank what do i know) that fast. >> >> [1] https://www.youtube.com/watch?v=dP1xVpMPn8M >> >> --steffen >> | >> |Der Kragenbaer, The moon bear, >> |der holt sich munter he cheerfully and one by one >> |einen nach dem anderen runter wa.ks himself off >> |(By Robert Gernhardt) -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Wed Nov 2 23:16:34 2022 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 2 Nov 2022 06:16:34 -0700 Subject: [TUHS] Early Unix and Keyboard Skills In-Reply-To: <7A8AFF11-5383-4FD3-8FA4-D262B30DC6A1@serissa.com> References: <7A8AFF11-5383-4FD3-8FA4-D262B30DC6A1@serissa.com> Message-ID: <20221102131634.GF26791@mcvoy.com> Self taught touch typer here. I frequently compare typing to running my excavator. If I don't think about what I'm doing, everything works, I can type in the dark (doing that right now) but as soon as I start thinking about where the keys are (or what the joysticks on the excavator do) it all goes to shit. And getting back to writing, I personally feel like if you write the man page first, it settles my messy brain into a good space, the code comes easier after writing docs. I view writing docs as sort of the first pass of thinking about how to write the code. Doesn't always work but it is pleasant when it does. On Wed, Nov 02, 2022 at 09:07:31AM -0400, Larry Stewart wrote: > In 1969 at the end of 9 th grade I got a foot injury that kept me on crutches for the summer so I took summer school typing. very worthwhile. I think 90% of the class were young women. My parents encouraged it mostly because it would make writing term papers much easier, which it did, but of course it had many computing benefits as well. > the ancient typewriters had really heavy keys with long strokes. Much like teletypes. > > > On Nov 2, 2022, at 8:27 AM, John P. Linderman wrote: > > > > ??? > > When I was in high school (in the early sixties) I tried to sign up for typing, which was taught on manual typewriters. I was told that the class was for girls only, and I was turned away. I never did develop good typing skills. I'm pretty much a two-fingered typist. Ironically, I have probably done more typing than 90% of the female classmates who were allowed to take the class. > > > > Precision figured mightily in those days, which may also have pre-dated white-out. Eliminating an error was a big deal. Now it's dead easy, and auto-correct has already fixed several errors in this message. > > > >> On Wed, Nov 2, 2022 at 8:14 AM Steffen Nurpmeso wrote: > >> steve jenkin wrote in > >> : > >> ... > >> |I???ve never heard anyone mention keyboard skills with the people of \ > >> |the CSRC - doesn???t anyone know? > >> > >> What i personally find more fascinating (given that -- in the > >> right condition -- i type pretty fast even in total darkness but > >> darkest possible monitor brightness) is the multitaskability some > >> show, in respect to combination of mouse and keyboard (or even > >> dual-mouse if i remember a message of Rob Pike right). I once > >> watched a video on the google tube of Russ Cox dancing acme doing > >> go testing, could be it is [1]. When he starts to actually work > >> a bit (late on iirc), that is thrilling, i could never select / > >> paste (kill snarf yank what do i know) that fast. > >> > >> [1] https://www.youtube.com/watch?v=dP1xVpMPn8M > >> > >> --steffen > >> | > >> |Der Kragenbaer, The moon bear, > >> |der holt sich munter he cheerfully and one by one > >> |einen nach dem anderen runter wa.ks himself off > >> |(By Robert Gernhardt) -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From steffen at sdaoden.eu Wed Nov 2 23:27:34 2022 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Wed, 02 Nov 2022 14:27:34 +0100 Subject: [TUHS] Early Unix and Keyboard Skills In-Reply-To: References: <20221102121352.MhcLw%steffen@sdaoden.eu> Message-ID: <20221102132734.PwCRX%steffen@sdaoden.eu> John P. Linderman wrote in : |When I was in high school (in the early sixties) I tried to sign up for |typing, which was taught on manual typewriters. I was told that the class |was for girls only, and I was turned away. I never did develop good typing |skills. I'm pretty much a two-fingered typist. Ironically, I have probably This can be a winner: https://www.youtube.com/watch?v=G4nX0Xrn-wo (The classic.) |done more typing than 90% of the female classmates who were allowed to take |the class. These machine-gunners are in another league per se from my modest point of view. Ten finger thunderstorms. |Precision figured mightily in those days, which may also have pre-dated |white-out. Eliminating an error was a big deal. Now it's dead easy, and |auto-correct has already fixed several errors in this message. Since i now own a (used!!) smartphone i unfortunately have to live with such things when doing my little bit of SMS messaging. It is terrible. Ooften do i have to delete the word entirely to unlock the screen. Ach! for the Asians who commit suicide because they messed up a calligraphical painting. It seems to me TUHS has lost its Sender: message header btw, which longs for fixing as it is SHOULD in RFC 5322 in this ML case (except for Warren himself, maybe). --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From clemc at ccc.com Wed Nov 2 23:28:38 2022 From: clemc at ccc.com (Clem Cole) Date: Wed, 2 Nov 2022 09:28:38 -0400 Subject: [TUHS] Early Unix and Keyboard Skills In-Reply-To: References: Message-ID: On Wed, Nov 2, 2022 at 3:13 AM Rob Pike wrote > bwk was one who could smash out the text faster than many. His having > learned on a teletype, the keyboard would resound with the impact of his > forceful keystrokes. > Funny, I remember the first time I got to use something other than an ASR33 or an ASR28 sometime time in the early 1970s I think. IIRC It was a Tek 4010, but the memory at the time of being amazed that I did not need so much energy to push the keys and how quiet it was. Before then I had equated computing with the feel, sounds, and machine oil smells of Teletype products. That said, when the VT52 came out in the mid-70s the DEC keyboard on it was far from the feel of the IBM Selectric III - which was considered the 'touch typist standard' ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Thu Nov 3 01:32:38 2022 From: tuhs at tuhs.org (Grant Taylor via TUHS) Date: Wed, 2 Nov 2022 09:32:38 -0600 Subject: [TUHS] early Unix papers, from Jim Joyce In-Reply-To: <20221102060730.A114A18C08A@mercury.lcs.mit.edu> References: <20221102060730.A114A18C08A@mercury.lcs.mit.edu> Message-ID: <74b464ac-2799-badd-9eae-a65acbe08bd7@spamtrap.tnetconsulting.net> On 11/2/22 12:07 AM, Noel Chiappa wrote: > Step #0: make a list of what's there, and post it here. That's crucial input > to any recommendation. If at all possible, include the date and venue associated with the items. I've found a few different papers by the same title that have been different based on date and / or venue. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4017 bytes Desc: S/MIME Cryptographic Signature URL: From tuhs at tuhs.org Thu Nov 3 01:34:42 2022 From: tuhs at tuhs.org (Grant Taylor via TUHS) Date: Wed, 2 Nov 2022 09:34:42 -0600 Subject: [TUHS] Four windowing systems on SunOS In-Reply-To: References: <20221031191401.GN22806@mcvoy.com> <202210311917.29VJHxe6110870@darkstar.fourwinds.com> <16d7a543-8c34-3663-f0d7-14b588683d6c@spamtrap.tnetconsulting.net> Message-ID: <15edc92b-983f-2bf4-c265-75384b5a76c5@spamtrap.tnetconsulting.net> On 11/2/22 2:55 AM, Michael Casadevall wrote: > I extensively researched this; there are infact copies of Pinball for > 64-bit platforms: https://www.youtube.com/watch?v=3EPTfOTC4Jw&t=47s Which 64-bit platforms? 64-bit x86 and / or 64-bit Itanium? I've not watched the video yet (today). > Pinball had problems relating to 64-bit FPU precision (and this can > actually be reproduced by fiddling with FPU flags), but it did ship in > Windows XP x64 Professional. My understanding is that Windows XP x64 Professional is 64-bit x86 and not Itanium. There is also a chance that I'm misremembering things. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4017 bytes Desc: S/MIME Cryptographic Signature URL: From e5655f30a07f at ewoof.net Thu Nov 3 01:44:38 2022 From: e5655f30a07f at ewoof.net (Michael =?utf-8?B?S2rDtnJsaW5n?=) Date: Wed, 2 Nov 2022 15:44:38 +0000 Subject: [TUHS] Four windowing systems on SunOS In-Reply-To: <15edc92b-983f-2bf4-c265-75384b5a76c5@spamtrap.tnetconsulting.net> References: <20221031191401.GN22806@mcvoy.com> <202210311917.29VJHxe6110870@darkstar.fourwinds.com> <16d7a543-8c34-3663-f0d7-14b588683d6c@spamtrap.tnetconsulting.net> <15edc92b-983f-2bf4-c265-75384b5a76c5@spamtrap.tnetconsulting.net> Message-ID: <8e87638d-ad51-4ea3-8c6b-9955c9bac996@home.arpa> On 2 Nov 2022 09:34 -0600, from tuhs at tuhs.org (Grant Taylor via TUHS): >> Pinball had problems relating to 64-bit FPU precision (and this can >> actually be reproduced by fiddling with FPU flags), but it did ship in >> Windows XP x64 Professional. > > My understanding is that Windows XP x64 Professional is 64-bit x86 and not > Itanium. Per Wikipedia, "Windows XP 64-Bit Edition" was for Intel's Itanium IA-64 architecture; whereas "Windows XP Professional x64 Edition" was for AMD's x86-64 architecture. https://en.wikipedia.org/wiki/Windows_XP#Editions You've just got to love it when two wildly distinct, yet highly similar, things are named almost, but not quite, the same. -- 🪶 Michael Kjörling 🏡 https://michael.kjorling.se “Remember when, on the Internet, nobody cared that you were a dog?” From jason-tuhs at shalott.net Thu Nov 3 05:01:29 2022 From: jason-tuhs at shalott.net (jason-tuhs at shalott.net) Date: Wed, 2 Nov 2022 12:01:29 -0700 (PDT) Subject: [TUHS] Early Unix and Keyboard Skills In-Reply-To: References: Message-ID: > I’ve never heard anyone mention keyboard skills with the people of the > CSRC - doesn’t anyone know? https://www.tuhs.org/Archive/Documentation/AUUGN/AUUGN-V05.4.pdf (p23) > History tells us that the guys who designed [UNIX] did their own typing > into the machine. It seems to me that because of this, the main reason > that UNIX enjoys/suffers from terse input and output is not through any > intellectual design decisions made at some early stage but because the > UNIX designers were just bad typists working on slow peripherals. -Jason From jpl.jpl at gmail.com Thu Nov 3 05:20:12 2022 From: jpl.jpl at gmail.com (John P. Linderman) Date: Wed, 2 Nov 2022 15:20:12 -0400 Subject: [TUHS] Early Unix and Keyboard Skills In-Reply-To: References: Message-ID: On Wed, Nov 2, 2022 at 3:02 PM wrote: > > > I’ve never heard anyone mention keyboard skills with the people of the > > CSRC - doesn’t anyone know? > > > https://www.tuhs.org/Archive/Documentation/AUUGN/AUUGN-V05.4.pdf (p23) > > > History tells us that the guys who designed [UNIX] did their own typing > > into the machine. It seems to me that because of this, the main reason > > that UNIX enjoys/suffers from terse input and output is not through any > > intellectual design decisions made at some early stage but because the > > UNIX designers were just bad typists working on slow peripherals. > > > -Jason > Mostly rampant speculation on my part, but with 110 baud modems, 10 characters per second right?, and added delays for carriage returns, it was the peripherals that encouraged brevity. Code would be viewed multiple times, but entered roughly once. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron at ronnatalie.com Thu Nov 3 06:35:10 2022 From: ron at ronnatalie.com (Ron Natalie) Date: Wed, 2 Nov 2022 13:35:10 -0700 Subject: [TUHS] Early Unix and Keyboard Skills In-Reply-To: <20221102122432.og3EI%steffen@sdaoden.eu> References: <20221102122432.og3EI%steffen@sdaoden.eu> Message-ID: <608A2539-B777-4243-B8A4-483B98297FAC@ronnatalie.com> My elementary school teacher recommended to my mother that she buy me a typewriter and I took typing in summer school. Little did we know being able to type 60wpm would end up being. > On Nov 2, 2022, at 05:24, Steffen Nurpmeso wrote: > > Steffen Nurpmeso wrote in > <20221102121352.MhcLw%steffen at sdaoden.eu>: > |steve jenkin wrote in > | : > | ... > ||I’ve never heard anyone mention keyboard skills with the people of \ > ||the CSRC - doesn’t anyone know? > | > |What i personally find more fascinating (given that -- in the > |right condition -- i type pretty fast even in total darkness but > |darkest possible monitor brightness) is the multitaskability some > |show, in respect to combination of mouse and keyboard (or even > |dual-mouse if i remember a message of Rob Pike right). I once > ... > > I once had a very small infrared / PS/2 keyboard with a track ball > at the upper right corner, and the buttons on the upper left) > where middle finger and forefinger only had to be moved a bit, but > the heel of hand(s) could remain (only twisted a bit). That > allowed for pretty good precision and speed. But i think it was > still not that of Russ Cox and acme and external mouse/mice. > > --steffen > | > |Der Kragenbaer, The moon bear, > |der holt sich munter he cheerfully and one by one > |einen nach dem anderen runter wa.ks himself off > |(By Robert Gernhardt) From ron at ronnatalie.com Thu Nov 3 11:47:19 2022 From: ron at ronnatalie.com (Ronald Natalie) Date: Thu, 03 Nov 2022 01:47:19 +0000 Subject: [TUHS] Early Unix and Keyboard Skills In-Reply-To: References: Message-ID: I’m not sure the model 33 required a carriage return delay. At 110 baud it had plenty of time to move the carriage. back. Other printers (especially faster ones) weren’t so lucky, but the LA36 decwriter had a catchup mode to print the backlog after a return. The LA120 was boustrophedonic so returns weren’t as much of an issue. ------ Original Message ------ >From "John P. Linderman" To jason-tuhs at shalott.net Cc "steve jenkin" ; "TUHS" Date 11/2/2022 12:20:12 PM Subject [TUHS] Re: Early Unix and Keyboard Skills > > >On Wed, Nov 2, 2022 at 3:02 PM wrote: >> >> > I’ve never heard anyone mention keyboard skills with the people of >>the >> > CSRC - doesn’t anyone know? >> >> >>https://www.tuhs.org/Archive/Documentation/AUUGN/AUUGN-V05.4.pdf (p23) >> >> > History tells us that the guys who designed [UNIX] did their own >>typing >> > into the machine. It seems to me that because of this, the main >>reason >> > that UNIX enjoys/suffers from terse input and output is not through >>any >> > intellectual design decisions made at some early stage but because >>the >> > UNIX designers were just bad typists working on slow peripherals. >> >> >> -Jason > >Mostly rampant speculation on my part, but with 110 baud modems, 10 >characters per second right?, >and added delays for carriage returns, it was the peripherals that >encouraged brevity. Code would be >viewed multiple times, but entered roughly once. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Thu Nov 3 11:48:36 2022 From: tuhs at tuhs.org (Warren Toomey via TUHS) Date: Thu, 3 Nov 2022 11:48:36 +1000 Subject: [TUHS] [OT] Usenix Conference in Sydney - anybody else? Message-ID: Hi all, I'll be attending the Usenix SREcon22 Asia/Pacific Conference which is being held in Sydney, Australia on the 7-9 December. Is anybody else attending? If so, it'd be nice to catch up with some other TUHSers :-) https://www.usenix.org/conference/srecon22apac/program Cheers, Warren From dave at horsfall.org Thu Nov 3 11:59:23 2022 From: dave at horsfall.org (Dave Horsfall) Date: Thu, 3 Nov 2022 12:59:23 +1100 (EST) Subject: [TUHS] Early Unix and Keyboard Skills In-Reply-To: References: Message-ID: On Thu, 3 Nov 2022, Ronald Natalie wrote: [...] > Other printers (especially faster ones) weren’t so lucky, but the LA36 > decwriter had a catchup mode to print the backlog after a return. Yep; the head went twice as fast to catch up. Wasn't there a method of locking it into that mode, but then requiring flow control? > The LA120 was boustrophedonic so returns weren’t as much of an issue. ISTR that it required a driver to utilise that mode. -- Dave From clemc at ccc.com Thu Nov 3 13:01:29 2022 From: clemc at ccc.com (Clem Cole) Date: Wed, 2 Nov 2022 23:01:29 -0400 Subject: [TUHS] Early Unix and Keyboard Skills In-Reply-To: References: Message-ID: The 33 and 28 needed at least two null chars after the or it would lose chars as there was no buffering. The Unix driver has the CR delay modes to support it. It’s UART as it were was mechanical and a real work of art. I remember spending a few hours trying to figure out how it worked. As for the LA120 yeah you really needed to use real flow control which could be a problem on DL11s and DZs ports. SW flow was less than prefect. However, the Able version of the DH supported flow in hardware (RTS/CTS style) so you could set them to interface with the host at 960cps and then print as fast as possible swiping back and forth on the paper as the local microprocessor in the decwritter buffered everything. On Wed, Nov 2, 2022 at 9:48 PM Ronald Natalie wrote: > I’m not sure the model 33 required a carriage return delay. At 110 baud > it had plenty of time to move the carriage. back. > Other printers (especially faster ones) weren’t so lucky, but the LA36 > decwriter had a catchup mode to print the backlog after a return. > The LA120 was boustrophedonic so returns weren’t as much of an issue. > > ------ Original Message ------ > From "John P. Linderman" > To jason-tuhs at shalott.net > Cc "steve jenkin" ; "TUHS" > Date 11/2/2022 12:20:12 PM > Subject [TUHS] Re: Early Unix and Keyboard Skills > > > > On Wed, Nov 2, 2022 at 3:02 PM wrote: > >> >> > I’ve never heard anyone mention keyboard skills with the people of the >> > CSRC - doesn’t anyone know? >> >> >> https://www.tuhs.org/Archive/Documentation/AUUGN/AUUGN-V05.4.pdf (p23) >> >> > History tells us that the guys who designed [UNIX] did their own typing >> > into the machine. It seems to me that because of this, the main reason >> > that UNIX enjoys/suffers from terse input and output is not through any >> > intellectual design decisions made at some early stage but because the >> > UNIX designers were just bad typists working on slow peripherals. >> >> >> -Jason >> > > Mostly rampant speculation on my part, but with 110 baud modems, 10 > characters per second right?, > and added delays for carriage returns, it was the peripherals that > encouraged brevity. Code would be > viewed multiple times, but entered roughly once. > > -- Sent from a handheld expect more typos than usual -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.winalski at gmail.com Fri Nov 4 01:17:38 2022 From: paul.winalski at gmail.com (Paul Winalski) Date: Thu, 3 Nov 2022 11:17:38 -0400 Subject: [TUHS] Early Unix and Keyboard Skills In-Reply-To: References: Message-ID: On 11/2/22, Ronald Natalie wrote: > I’m not sure the model 33 required a carriage return delay. At 110 > baud it had plenty of time to move the carriage. back. > Other printers (especially faster ones) weren’t so lucky, but the LA36 > decwriter had a catchup mode to print the backlog after a return. > The LA120 was boustrophedonic so returns weren’t as much of an issue. The model 33 had a very fast and powerful carriage return mechanism, good for cracking walnuts, but it took up to two character times to complete a CR. If you didn't send two non-printing characters (such as NUL), you risked having your character struck somewhere in the middle of the line. The LA36 DECwriter had a rather slow carriage return. It would buffer characters while a return was in progress and then print the buffered characters at 60 characters/second, slowing down to the normal 30 cps when caught up. There was a company that sold modified LA36 controller boards that were hacked so that the LA36 always thought it was in catch-up mode and could thus be run at double speed, provided that you inserted NUL padding after a CR. But that greatly reduced the longevity of the print mechanism. -Paul W. From clemc at ccc.com Fri Nov 4 02:18:22 2022 From: clemc at ccc.com (Clem Cole) Date: Thu, 3 Nov 2022 12:18:22 -0400 Subject: [TUHS] Early Unix and Keyboard Skills In-Reply-To: References: Message-ID: On Thu, Nov 3, 2022 at 11:19 AM Paul Winalski wrote: > The LA36 DECwriter had a rather slow carriage return. It would buffer > characters while a return was in progress and then print the buffered > characters at 60 characters/second, slowing down to the normal 30 cps > when caught up. > The key point here is that with the DEC Writer (LA36) DEC started to split the print speed (*in cps*) from the line interface speed (*in baud* as it was larger than an often character as it would have at least one start bit, one or more stop bits, and maybe a parity bit too). Herein also lies another problem, the mechanical interface, be it how fast the carriage moved, or the head was positioned, etc, could be much longer than the single character transfer time. As Paul mentioned on some mechanical devices without any buffering, the print might be random as the carriage moved the head. Teletype made an amazing mechanical device that had a minimum amount of electronics in it. By the time of the LA36, you start to see the microprocessor revolution and the use of cheap transistors to replace mechanical things to make faster/better devices with new features (like buffering and being able to have different speeds for data transfer and printing). But you also start to see the distinction between the mechanics (the keyboard/printer) and things like the communications scheme become even more obvious and terminology starts to be used to address the specific part of the problem. ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From cowan at ccil.org Fri Nov 4 03:02:31 2022 From: cowan at ccil.org (John Cowan) Date: Thu, 3 Nov 2022 13:02:31 -0400 Subject: [TUHS] Early Unix and Keyboard Skills In-Reply-To: References: Message-ID: On Thu, Nov 3, 2022 at 11:19 AM Paul Winalski wrote: > The model 33 had a very fast and powerful carriage return mechanism, > good for cracking walnuts, but it took up to two character times to > complete a CR. If you didn't send two non-printing characters (such > as NUL), you risked having your character struck somewhere in the > middle of the line. > That was not my experience. I cut my teeth on a PDP-8/M running OS/8 with an ASR-33 attached and directly programming the KE8E controller without any additional time-delay loops. Outputting additional NULs would have screwed up binary paper tape output, so that can't have been how it was done. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rdm at cfcl.com Fri Nov 4 05:36:45 2022 From: rdm at cfcl.com (Rich Morin) Date: Thu, 3 Nov 2022 12:36:45 -0700 Subject: [TUHS] Early Unix and Keyboard Skills In-Reply-To: References: Message-ID: <188181D2-1198-49EF-B4F1-BB3617CCC215@cfcl.com> > On Thu, Nov 3, 2022 at 11:19 AM Paul Winalski wrote: > > The model 33 had a very fast and powerful carriage return mechanism, > good for cracking walnuts ... In 1968, San Francisco State College (now yclept "University") set up a "computer lab", based on a few IBM 2741 terminals. These were hooked by leased lines to Stanford's Wylbur system and allowed us to do line-based editing, interactive Lisp, etc. Anyway, the terminals were based on the I/O Selectric, and the ball impacts were powered by a spinning bar with pretty much infinite torque. One day, an insufficiently cautious TA got her long, straight hair wound onto the bar. Each character that was printed pulled her head closer to the terminal. Fortunately, someone hit the OFF switch in time to avoid bloodshed. Then, we were able to carefully unwind her hair and free her from the terminal. IIRC, we didn't even have to cut any of her hair in the process... -r From dds at aueb.gr Fri Nov 4 05:43:44 2022 From: dds at aueb.gr (Diomidis Spinellis) Date: Thu, 3 Nov 2022 21:43:44 +0200 Subject: [TUHS] vi in cooked mode? Message-ID: <7b249e68-de74-2c81-32b0-18ecb74a85ec@aueb.gr> I remember being told back in the 1980s that vi would set the terminal to "cooked mode" when vi was in "insert mode", so as to reduce expensive context switching for each character typed. Only vi's "command mode" would set the terminal to "raw mode" so as to provide immediate feedback on each (command) character typed. This would be a clever system performance optimization, and would also explain designing vi around distinct insert and command modes. However, I can't find such evidence even as far back as BSD 1. It seems that in insert mode ESC was processed like any other character. https://github.com/dspinellis/unix-history-repo/blob/BSD-1-Snapshot-Development/ex-1.1/ex_vops.c#L507 Cooked mode was only entered when scrolling in order to receive interrupts. https://github.com/dspinellis/unix-history-repo/blob/BSD-1-Snapshot-Development/ex-1.1/ex_vadjust.c#L180 Also, for this scheme to work ESC would need to be mapped to an interrupt key, so as to allow exiting the cooked mode through the corresponding signal handler. Again, grepping for ESC, did not show me any such code. I also remember being told that this optimization was what allowed twenty students to concurrently perform interactive editing on a VAX 11/780 (running 4.2BSD and then 4.3BSD), and that Emacs was not provided to students because it was always operating in raw mode. Was I misled? Was there perhaps a hacked version of vi that worked in this way? -Diomidis From sauer at technologists.com Fri Nov 4 06:01:04 2022 From: sauer at technologists.com (Charles H Sauer (he/him)) Date: Thu, 3 Nov 2022 15:01:04 -0500 Subject: [TUHS] Early Unix and Keyboard Skills In-Reply-To: <188181D2-1198-49EF-B4F1-BB3617CCC215@cfcl.com> References: <188181D2-1198-49EF-B4F1-BB3617CCC215@cfcl.com> Message-ID: <3d93609e-973f-38af-9557-fd388e911d09@technologists.com> On 11/3/2022 2:36 PM, Rich Morin wrote: >> On Thu, Nov 3, 2022 at 11:19 AM Paul Winalski wrote: >> >> The model 33 had a very fast and powerful carriage return mechanism, >> good for cracking walnuts ... > > In 1968, San Francisco State College (now yclept "University") set up a "computer lab", based on a few IBM 2741 terminals. These were hooked by leased lines to Stanford's Wylbur system and allowed us to do line-based editing, interactive Lisp, etc. > > Anyway, the terminals were based on the I/O Selectric, and the ball impacts were powered by a spinning bar with pretty much infinite torque. One day, an insufficiently cautious TA got her long, straight hair wound onto the bar. Each character that was printed pulled her head closer to the terminal. > > Fortunately, someone hit the OFF switch in time to avoid bloodshed. Then, we were able to carefully unwind her hair and free her from the terminal. IIRC, we didn't even have to cut any of her hair in the process... I was nominally a music major at S.F. State at that time, in the midst of my self-imposed avoidance of computers, that started with disdain from my initial exposure to Fortran on IBM 1620 at U of MO-Columbia in 1964 and ended with semi-abandoning my rock and roll pursuits in early 1971 and starting C.S. studies at UT-Austin. I also took math courses at S.F. State in 1968 but was unaware of the above cited "lab". Regarding keyboarding skills, I took touch-typing in summer school after 9th grade, got a SCM portable electric typewriter that I might still have, and am still grateful for QWERTY facility that has served me ever since, on card punch, 2741, 3270, Displaywriter, and more obscure and more modern keyboards. CHS -- voice: +1.512.784.7526 e-mail: sauer at technologists.com fax: +1.512.346.5240 Web: https://technologists.com/sauer/ Facebook/Google/Twitter: CharlesHSauer From jnc at mercury.lcs.mit.edu Fri Nov 4 06:17:31 2022 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Thu, 3 Nov 2022 16:17:31 -0400 (EDT) Subject: [TUHS] vi in cooked mode? Message-ID: <20221103201731.7380A18C09C@mercury.lcs.mit.edu> > From: Diomidis Spinellis > I remember being told back in the 1980s that vi would set the terminal > to "cooked mode" when vi was in "insert mode", so as to reduce expensive > context switching for each character typed. > ... > However, I can't find such evidence even as far back as BSD 1. Maybe you're thinking of Multics Emacs, which had such a capability: https://multicians.org/mepap.html Noel From clemc at ccc.com Fri Nov 4 06:26:03 2022 From: clemc at ccc.com (Clem Cole) Date: Thu, 3 Nov 2022 16:26:03 -0400 Subject: [TUHS] vi in cooked mode? In-Reply-To: <7b249e68-de74-2c81-32b0-18ecb74a85ec@aueb.gr> References: <7b249e68-de74-2c81-32b0-18ecb74a85ec@aueb.gr> Message-ID: On Thu, Nov 3, 2022 at 3:44 PM Diomidis Spinellis wrote: > Was I misled? Was there perhaps a hacked version of vi that worked in this > way? > I think you may be mixing a few stories ... and features ... v6 vs v7 PDP-11 vs Vax much less vi vs emacs. Some thoughts ... 1.) Emacs came from CMU and only a few years later after the Vax had was stable (post 4.1BSD) 2.) emacs was not so much prohibited as it was slow, it needed megabytes of memory -- that was limit. 3.) By the time emacs comes on the scene, workstations are showing up, so you did not have 20 students on a vax to UCB. 4.) Raw mode was a V6 feature for PDP-11, by the time of the Vax the TTY was using V7 using CBREAK (1/2 cooked) which still allows canonicalization ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Fri Nov 4 06:27:45 2022 From: clemc at ccc.com (Clem Cole) Date: Thu, 3 Nov 2022 16:27:45 -0400 Subject: [TUHS] vi in cooked mode? In-Reply-To: References: <7b249e68-de74-2c81-32b0-18ecb74a85ec@aueb.gr> Message-ID: I should say -- UNIX (Gosling) EMACS came from CMU .... ᐧ On Thu, Nov 3, 2022 at 4:26 PM Clem Cole wrote: > > > On Thu, Nov 3, 2022 at 3:44 PM Diomidis Spinellis wrote: > >> Was I misled? Was there perhaps a hacked version of vi that worked in this >> way? >> > I think you may be mixing a few stories ... and features ... > > > v6 vs v7 PDP-11 vs Vax much less vi vs emacs. > Some thoughts ... > > 1.) Emacs came from CMU and only a few years later after the Vax had was > stable (post 4.1BSD) > 2.) emacs was not so much prohibited as it was slow, it needed megabytes > of memory -- that was limit. > 3.) By the time emacs comes on the scene, workstations are showing up, so > you did not have 20 students on a vax to UCB. > 4.) Raw mode was a V6 feature for PDP-11, by the time of the Vax the TTY > was using V7 using CBREAK (1/2 cooked) which still allows canonicalization > > ᐧ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Fri Nov 4 06:55:20 2022 From: imp at bsdimp.com (Warner Losh) Date: Thu, 3 Nov 2022 14:55:20 -0600 Subject: [TUHS] vi in cooked mode? In-Reply-To: References: <7b249e68-de74-2c81-32b0-18ecb74a85ec@aueb.gr> Message-ID: On Thu, Nov 3, 2022, 2:28 PM Clem Cole wrote: > > > On Thu, Nov 3, 2022 at 3:44 PM Diomidis Spinellis wrote: > >> Was I misled? Was there perhaps a hacked version of vi that worked in this >> way? >> > I think you may be mixing a few stories ... and features ... > > > v6 vs v7 PDP-11 vs Vax much less vi vs emacs. > Some thoughts ... > > 1.) Emacs came from CMU and only a few years later after the Vax had was > stable (post 4.1BSD) > There were a diversity of emacs clones for unix as well... 2.) emacs was not so much prohibited as it was slow, it needed megabytes of > memory -- that was limit. > The VAX 11/750 with 1MB we had at nmt ran emacs, but not gnu emacs. It was something special off the internet that was less featureful so took less memory. We had to have it since EMACS was popular on the DECsystem 20s we had.. The Vax could handle 15 students on each of the 15 terminals connected to it plus 5 or so coming in via telnet doing emacs compilein 100-500 line CS programs without being too insanely bogged down... < 10 and you didn't notice. 3.) By the time emacs comes on the scene, workstations are showing up, so > you did not have 20 students on a vax to UCB. > Emacs of different flavors predated workstations by a few years though. GNU Emacs 18 dates to when VAXstations, Suns and others were shipping on volume. 4.) Raw mode was a V6 feature for PDP-11, by the time of the Vax the TTY > was using V7 using CBREAK (1/2 cooked) which still allows canonicalization > All the oddball quirks in tty behavior can be dated to the early 80s to optimize somebody's use case... Warner > ᐧ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Fri Nov 4 07:34:59 2022 From: clemc at ccc.com (Clem Cole) Date: Thu, 3 Nov 2022 17:34:59 -0400 Subject: [TUHS] vi in cooked mode? In-Reply-To: References: <7b249e68-de74-2c81-32b0-18ecb74a85ec@aueb.gr> Message-ID: On Thu, Nov 3, 2022 at 4:55 PM Warner Losh wrote: > > There were a diversity of emacs clones for unix as well... > Absolutely... But the first in wide used in the UNIX world was Gosling EMACS which appeared outside of CMU soon after UCB dropped 4.1 in early 1980, probably the next was Zimmerman (*a.k.a.* CCA) EMACS, then GNU hacked Gosling's version (that strange trip has been discussed elsewhere and I'll not add it here). Zimmer's version was 'truer' to the original MIT/PDP-10 version from ITS than Gosling but Steve had built it when he worked for CCA so it was licensed (which we had a Masscomp and made available to our customers). To my knowledge Gosling's version never fit on any PDP-11 nor Gnu, I'm not sure if Steve ever got his to work on a split I/D [Noel might know]. I do know some of my MIT friends used to grouse about the differences between CMU EMACS and ITS EMACS. That said, there was also at least one microemacs which was originally for CPM and MSDOS IIRC, that got moved a number of the UNIX boxes which may be what you are referring. I seem to remember that was released on netnews and was a lot smaller. I never messed with it, because by then I had the address space of and I could run Gosling or Zimmerman. ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From stuff at riddermarkfarm.ca Fri Nov 4 07:51:44 2022 From: stuff at riddermarkfarm.ca (Stuff Received) Date: Thu, 3 Nov 2022 17:51:44 -0400 Subject: [TUHS] Early Unix and Keyboard Skills In-Reply-To: References: Message-ID: On 2022-11-02 03:11, Rob Pike wrote: > Neither ken nor dmr were impressive typists. In fact few programmers > were then, at least of my acquaintance. > > In the 1970s Bell Labs created the Getset - think of it as an early > wired smartphone, or a Minitel, with a little screen and keyboard. It > cost quite a bit but was a cool gadget so the executives all got one. > But, in fascinating contrast to the Blackberry a generation later, no > one would touch it - literally - because it had a keyboard, and > keyboards were for (female) secretaries, not (male) executives. The > product, although well ahead of its time, was a complete failure due > to the cultural bias then. > > There may be a good sociology paper in there somewhere. I remember the dep't administrators having colour terminals connected to the mainframe, and all they did was look up the occasional telephone number, whilst the "secretaries" (as they were called then) being given b&w terminals for work. > I'm not saying K&D shared this blinkered view, not at all, just that > typing skills were not de facto back then. Some of the folks were even > two-finger jabbers. I was a little younger and a faster typist than > most of the others, and I am not a good typist by any modern standard. > > bwk was one who could smash out the text faster than many. His having > learned on a teletype, the keyboard would resound with the impact of > his forceful keystrokes. I learnt in high school on a manual typewriter so I can appreciate that.  (Learning on a manual really builds up the muscles on one's little fingers. #6-) N. > > -rob > > [...] From imp at bsdimp.com Fri Nov 4 08:28:23 2022 From: imp at bsdimp.com (Warner Losh) Date: Thu, 3 Nov 2022 16:28:23 -0600 Subject: [TUHS] vi in cooked mode? In-Reply-To: References: <7b249e68-de74-2c81-32b0-18ecb74a85ec@aueb.gr> Message-ID: On Thu, Nov 3, 2022 at 3:35 PM Clem Cole wrote: > > > On Thu, Nov 3, 2022 at 4:55 PM Warner Losh wrote: > >> >> There were a diversity of emacs clones for unix as well... >> > Absolutely... > > But the first in wide used in the UNIX world was Gosling EMACS which > appeared outside of CMU soon after UCB dropped 4.1 in early 1980, probably > the next was Zimmerman (*a.k.a.* CCA) EMACS, then GNU hacked Gosling's > version (that strange trip has been discussed elsewhere and I'll not add it > here). Zimmer's version was 'truer' to the original MIT/PDP-10 version > from ITS than Gosling but Steve had built it when he worked for CCA so it > was licensed (which we had a Masscomp and made available to our > customers). To my knowledge Gosling's version never fit on any PDP-11 nor > Gnu, I'm not sure if Steve ever got his to work on a split I/D [Noel might > know]. I do know some of my MIT friends used to grouse about the > differences between CMU EMACS and ITS EMACS. That said, there was also at > least one microemacs which was originally for CPM and MSDOS IIRC, that got > moved a number of the UNIX boxes which may be what you are referring. I > seem to remember that was released on netnews and was a lot smaller. I > never messed with it, because by then I had the address space of and I > could run Gosling or Zimmerman. > IIRC, it was one of the microemacs from netnews (there were a few different ones) that had been back-ported to BSD (or maybe the early ones just worked there). It was funky, but it worked with the HP terminals that were attached to the VAX and was somewhat less that the other, larger emacs in terms of what it could do beyond just editing. Warner > ᐧsadf > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron at ronnatalie.com Fri Nov 4 08:52:38 2022 From: ron at ronnatalie.com (Ron Natalie) Date: Thu, 03 Nov 2022 22:52:38 +0000 Subject: [TUHS] vi in cooked mode? In-Reply-To: References: <7b249e68-de74-2c81-32b0-18ecb74a85ec@aueb.gr> Message-ID: We used Montgomery’s EMACS and then JOVE on the PDP-11 UNIXes. I did a short stint working at Unipress on Gosling’s Emacs while their lead developer was off on another project (I was between jobs at the time). -------------- next part -------------- An HTML attachment was scrubbed... URL: From lars at nocrew.org Fri Nov 4 16:43:09 2022 From: lars at nocrew.org (Lars Brinkhoff) Date: Fri, 04 Nov 2022 06:43:09 +0000 Subject: [TUHS] vi in cooked mode? In-Reply-To: (Clem Cole's message of "Thu, 3 Nov 2022 17:34:59 -0400") References: <7b249e68-de74-2c81-32b0-18ecb74a85ec@aueb.gr> Message-ID: <7wv8nv1apu.fsf@junk.nocrew.org> Clem Cole wrote: > probably the next was Zimmerman (a.k.a. CCA) EMACS, then GNU hacked > Gosling's version (that strange trip has been discussed elsewhere and > I'll not add it here). Zimmer's version was 'truer' to the original > MIT/PDP-10 version from ITS than Gosling but Steve had built it when > he worked for CCA so it was licensed (which we had a Masscomp and made > available to our customers). I recently found a copy of CCA Emacs. It's from 1983 and does not yet have the Elisp extension language. CCA was bought by Rocket Software, so they own it now. I asked permission to put it online, but unfortunately they said no. Ron Natalie wrote: > We used Montgomery’s EMACS and then JOVE on the PDP-11 UNIXes. Montgomery kindly agreed to putting a copy of his editor here, and wrote about its history: https://github.com/larsbrinkhoff/emacs-history/tree/sources/ana-3.lcs.mit.edu/%7Ejnc/tech/unix/emacs https://github.com/larsbrinkhoff/emacs-history/blob/sources/docs/Montgomery%20Emacs%20History.txt From crossd at gmail.com Sat Nov 5 01:18:15 2022 From: crossd at gmail.com (Dan Cross) Date: Fri, 4 Nov 2022 11:18:15 -0400 Subject: [TUHS] vi in cooked mode? In-Reply-To: <7wv8nv1apu.fsf@junk.nocrew.org> References: <7b249e68-de74-2c81-32b0-18ecb74a85ec@aueb.gr> <7wv8nv1apu.fsf@junk.nocrew.org> Message-ID: On Fri, Nov 4, 2022 at 2:43 AM Lars Brinkhoff wrote: > Clem Cole wrote: > > probably the next was Zimmerman (a.k.a. CCA) EMACS, then GNU hacked > > Gosling's version (that strange trip has been discussed elsewhere and > > I'll not add it here). Zimmer's version was 'truer' to the original > > MIT/PDP-10 version from ITS than Gosling but Steve had built it when > > he worked for CCA so it was licensed (which we had a Masscomp and made > > available to our customers). > > I recently found a copy of CCA Emacs. It's from 1983 and does not yet > have the Elisp extension language. CCA was bought by Rocket Software, > so they own it now. I asked permission to put it online, but > unfortunately they said no. Out of curiosity, did they say why? It's hard to imagine it holds much commercial value now. Was it some kind of IP ownership thing? - Dan C. From lars at nocrew.org Sat Nov 5 03:54:07 2022 From: lars at nocrew.org (Lars Brinkhoff) Date: Fri, 04 Nov 2022 17:54:07 +0000 Subject: [TUHS] vi in cooked mode? In-Reply-To: (Dan Cross's message of "Fri, 4 Nov 2022 11:18:15 -0400") References: <7b249e68-de74-2c81-32b0-18ecb74a85ec@aueb.gr> <7wv8nv1apu.fsf@junk.nocrew.org> Message-ID: <7w7d0a1u80.fsf@junk.nocrew.org> Dan Cross wrote: >> CCA was bought by Rocket Software, so they own [CCA Emacs] now. I >> asked permission to put it online, but unfortunately they said no. > Out of curiosity, did they say why? It's hard to imagine it holds much > commercial value now. Was it some kind of IP ownership thing? I aked through an intermediary who had an inside connection at Rocket Software, so I don't know why. From ron at ronnatalie.com Sat Nov 5 04:33:34 2022 From: ron at ronnatalie.com (Ron Natalie) Date: Fri, 04 Nov 2022 18:33:34 +0000 Subject: [TUHS] vi in cooked mode? In-Reply-To: References: <7b249e68-de74-2c81-32b0-18ecb74a85ec@aueb.gr> Message-ID: > >v6 vs v7 PDP-11 vs Vax much less vi vs emacs. > Amusingly, as weith many of us, I got my start with "ed." I never actually learned vi. By the time I was ready to move up to screen editors, the emacs-ish things were available to me. I did a small stint using INed (Rand-editor variant) at one job. My employees always found it amusing that if I was stuck on a machine that didn't have some emacs-ish thing, I just used ed. They marvelled at my ability to complex substitutions with the s/// regular expressions. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mah at mhorton.net Sat Nov 5 08:13:17 2022 From: mah at mhorton.net (Mary Ann Horton) Date: Fri, 4 Nov 2022 15:13:17 -0700 Subject: [TUHS] vi in cooked mode? In-Reply-To: <7b249e68-de74-2c81-32b0-18ecb74a85ec@aueb.gr> References: <7b249e68-de74-2c81-32b0-18ecb74a85ec@aueb.gr> Message-ID: <53541ab4-6cec-59b9-075b-bfb9bc949f94@mhorton.net> I don't think vi would work correctly in cooked mode. It has to redraw (some of) the screen, inserting a character on each keystroke, and repainting the rest of the line. As Clem points out, in V6 it used raw, in V7 it used cbreak, which is "half cooked" and allows interrupts. It certainly affected performance when lots of students were using it, especially if they all had their own copies of the binary, which was typical on non-BSD systems. What really helped there was ensuring that the official vi binary was in /usr/ucb (or another standard directory) so that only one copy of the instruction space would be in memory, shared among all the users. Bell Labs, which typically ran internal versions of UNIX that didn't have vi, created the exptools package with most of the Berkeley tools and certain others, such as Montgomery's EMACS. This was partly to address the performance issue, and to get people to stop installing their own personal copies of everything. Thanks, /Mary Ann Horton/ (she/her/ma'am) maryannhorton.com "This is a great book" - Monica Helms "Brave and Important" - Laura L. Engel       Available on Amazon and bn.com! On 11/3/22 12:43, Diomidis Spinellis wrote: > I remember being told back in the 1980s that vi would set the terminal > to "cooked mode" when vi was in "insert mode", so as to reduce > expensive context switching for each character typed.  Only vi's > "command mode" would set the terminal to "raw mode" so as to provide > immediate feedback on each (command) character typed. This would be a > clever system performance optimization, and would also explain > designing vi around distinct insert and command modes. > > However, I can't find such evidence even as far back as BSD 1.  It > seems that in insert mode ESC was processed like any other character. > > https://github.com/dspinellis/unix-history-repo/blob/BSD-1-Snapshot-Development/ex-1.1/ex_vops.c#L507 > > > Cooked mode was only entered when scrolling in order to receive > interrupts. > > https://github.com/dspinellis/unix-history-repo/blob/BSD-1-Snapshot-Development/ex-1.1/ex_vadjust.c#L180 > > > Also, for this scheme to work ESC would need to be mapped to an > interrupt key, so as to allow exiting the cooked mode through the > corresponding signal handler.  Again, grepping for ESC, did not show > me any such code. > > I also remember being told that this optimization was what allowed > twenty students to concurrently perform interactive editing on a VAX > 11/780 (running 4.2BSD and then 4.3BSD), and that Emacs was not > provided to students because it was always operating in raw mode. > > Was I misled?  Was there perhaps a hacked version of vi that worked in > this way? > > -Diomidis -------------- next part -------------- An HTML attachment was scrubbed... URL: From tytso at mit.edu Sat Nov 5 09:42:15 2022 From: tytso at mit.edu (Theodore Ts'o) Date: Fri, 4 Nov 2022 19:42:15 -0400 Subject: [TUHS] vi in cooked mode? In-Reply-To: References: <7b249e68-de74-2c81-32b0-18ecb74a85ec@aueb.gr> Message-ID: On Fri, Nov 04, 2022 at 06:33:34PM +0000, Ron Natalie wrote: > > > > v6 vs v7 PDP-11 vs Vax much less vi vs emacs. > > Amusingly, as weith many of us, I got my start with "ed." I never actually > learned vi. By the time I was ready to move up to screen editors, the > emacs-ish things were available to me. Yeah, same here, although my start was with the editor that came with the PDP-8 disk operating system (using an ASR-35), the PDP-15's foreground/background system (using a KSR-33), and the PDP-11's RT-11 running under TSX-plus (using VT-100's and DECwriter for the console). So when I finally got a chance to use Unix when I got to college, /bin/ed was so similar to the line oriented editors I had used on the various Digital systems I had a chance to use while growing up and in high school, I never bothered to use vi. It was either ed or emacs, depending on how loaded the time-sharing systems I was using my freshman year. Of course, once I had a chance to use a Vaxstation or the IBM PC/RT all to myself, I jumped over to emacs and never looked back --- except when I was recovering a system in single user mode, of course. - Ted From dave at horsfall.org Sat Nov 5 10:45:26 2022 From: dave at horsfall.org (Dave Horsfall) Date: Sat, 5 Nov 2022 11:45:26 +1100 (EST) Subject: [TUHS] vi in cooked mode? In-Reply-To: References: <7b249e68-de74-2c81-32b0-18ecb74a85ec@aueb.gr> Message-ID: On Fri, 4 Nov 2022, Theodore Ts'o wrote: > Yeah, same here, although my start was with the editor that came with > the PDP-8 disk operating system (using an ASR-35), the PDP-15's > foreground/background system (using a KSR-33), and the PDP-11's RT-11 > running under TSX-plus (using VT-100's and DECwriter for the console). I started off with TECO on RT-11; talk about cryptic... > So when I finally got a chance to use Unix when I got to college, > /bin/ed was so similar to the line oriented editors I had used on the > various Digital systems I had a chance to use while growing up and in > high school, I never bothered to use vi. It was either ed or emacs, > depending on how loaded the time-sharing systems I was using in my > freshman year. Shortly after I switched to "ed" on the 11/40 someone brought out "em" (editor for mortals) which was sort of a screen editor: I recall saying "what a stupid command name" as it was only a fumble away from "rm" :-( > Of course, once I had a chance to use a Vaxstation or the IBM PC/RT all > to myself, I jumped over to emacs and never looked back --- except when > I was recovering a system in single user mode, of course. A boss of mine insisted that everyone had to learned "ed", because after a system crash it might be the only editor available; that, or having to dial in over a slow modem. -- Dave From lm at mcvoy.com Sat Nov 5 11:02:47 2022 From: lm at mcvoy.com (Larry McVoy) Date: Fri, 4 Nov 2022 18:02:47 -0700 Subject: [TUHS] vi in cooked mode? In-Reply-To: References: <7b249e68-de74-2c81-32b0-18ecb74a85ec@aueb.gr> Message-ID: <20221105010247.GG29525@mcvoy.com> On Sat, Nov 05, 2022 at 11:45:26AM +1100, Dave Horsfall wrote: > A boss of mine insisted that everyone had to learned "ed", because after a > system crash it might be the only editor available; that, or having to > dial in over a slow modem. Same. Though vi in ex mode was also good. I also got a little corrupted by whatever editor came with BDS C, my .exrc looks like this: map # :.,$ map @ :1,. Those came from that editor, # says do whatever to the end of the file, @ says do whatever from the top of the file to here. map , !}fmt This came from Udi Manber, , runs your paragraph through fmt map!   I set shiftwidth to 4 spaces because when you have code like if ((this big thing == that big thing) && (this other big thing) && (yet another big thing)) { I use 4 spaces for what I call the continuation line. I used ^A to write that example, why I don't like ^T is lost to me. And yeah, I paren stuff that doesn't need to have parens, it just makes the code more obvious. set redraw ai aw terse redraw I think is left over from modems, autoident because duh, autowrite because who doesn't hack, hack, hack, ^Z, !cc? terse because I'm not a newbie. set sections=uhshSHNH set paragraphs=PSPETSTEFSFEKSKECSCERSREDSDEIPNPLPPPTLABAIAELIB1B2HH Troff. set ts=8 sw=4 set shell=/bin/sh set showmode set textwidth=1000 set vb Etc. I've been carrying around that .exrc for around 40 years. Sheesh, I'm old. From bakul at iitbombay.org Sat Nov 5 11:25:03 2022 From: bakul at iitbombay.org (Bakul Shah) Date: Fri, 4 Nov 2022 18:25:03 -0700 Subject: [TUHS] vi in cooked mode? In-Reply-To: <20221105010247.GG29525@mcvoy.com> References: <7b249e68-de74-2c81-32b0-18ecb74a85ec@aueb.gr> <20221105010247.GG29525@mcvoy.com> Message-ID: On Nov 4, 2022, at 6:02 PM, Larry McVoy wrote: > > I also got a little corrupted by whatever editor came with BDS C I think that was wordstar. I had to retrain my fingers when I switched to vi! I used SOS, edt(?) on Tops-10, edit(?) on CMS, teco (on ITS), wordstar (on CP/M), ed, vi, rand editor, acme. Now I stick to nvi & acme. And cat for small programs/files. From bakul at iitbombay.org Sat Nov 5 11:25:03 2022 From: bakul at iitbombay.org (Bakul Shah) Date: Fri, 4 Nov 2022 18:25:03 -0700 Subject: [TUHS] vi in cooked mode? In-Reply-To: <20221105010247.GG29525@mcvoy.com> References: <7b249e68-de74-2c81-32b0-18ecb74a85ec@aueb.gr> <20221105010247.GG29525@mcvoy.com> Message-ID: On Nov 4, 2022, at 6:02 PM, Larry McVoy wrote: > > I also got a little corrupted by whatever editor came with BDS C I think that was wordstar. I had to retrain my fingers when I switched to vi! I used SOS, edt(?) on Tops-10, edit(?) on CMS, teco (on ITS), wordstar (on CP/M), ed, vi, rand editor, acme. Now I stick to nvi & acme. And cat for small programs/files. From lm at mcvoy.com Sat Nov 5 11:40:29 2022 From: lm at mcvoy.com (Larry McVoy) Date: Fri, 4 Nov 2022 18:40:29 -0700 Subject: [TUHS] vi in cooked mode? In-Reply-To: References: <7b249e68-de74-2c81-32b0-18ecb74a85ec@aueb.gr> <20221105010247.GG29525@mcvoy.com> Message-ID: <20221105014029.GH29525@mcvoy.com> On Fri, Nov 04, 2022 at 06:25:03PM -0700, Bakul Shah wrote: > On Nov 4, 2022, at 6:02 PM, Larry McVoy wrote: > > > > I also got a little corrupted by whatever editor came with BDS C > > I think that was wordstar. I had to retrain my fingers when I > switched to vi! I used SOS, edt(?) on Tops-10, edit(?) on CMS, > teco (on ITS), wordstar (on CP/M), ed, vi, rand editor, acme. > Now I stick to nvi & acme. And cat for small programs/files. I used wordstar but I think BDS C had their own thing. Wordstar was different. -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From rich.salz at gmail.com Sat Nov 5 12:31:19 2022 From: rich.salz at gmail.com (Rich Salz) Date: Fri, 4 Nov 2022 22:31:19 -0400 Subject: [TUHS] vi in cooked mode? In-Reply-To: <20221105014029.GH29525@mcvoy.com> References: <7b249e68-de74-2c81-32b0-18ecb74a85ec@aueb.gr> <20221105010247.GG29525@mcvoy.com> <20221105014029.GH29525@mcvoy.com> Message-ID: I don't recall BDS C having an editor but I could be wrong. They pushed Mark of the Unicorn's MINCE (mince is not complete emacs) and scribble, a scribe mini-clone. BDS was a one man shop, it stood for brain-damaged software. On Fri, Nov 4, 2022, 9:40 PM Larry McVoy wrote: > On Fri, Nov 04, 2022 at 06:25:03PM -0700, Bakul Shah wrote: > > On Nov 4, 2022, at 6:02 PM, Larry McVoy wrote: > > > > > > I also got a little corrupted by whatever editor came with BDS C > > > > I think that was wordstar. I had to retrain my fingers when I > > switched to vi! I used SOS, edt(?) on Tops-10, edit(?) on CMS, > > teco (on ITS), wordstar (on CP/M), ed, vi, rand editor, acme. > > Now I stick to nvi & acme. And cat for small programs/files. > > I used wordstar but I think BDS C had their own thing. Wordstar > was different. > -- > --- > Larry McVoy Retired to fishing > http://www.mcvoy.com/lm/boat > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bakul at iitbombay.org Sat Nov 5 13:44:22 2022 From: bakul at iitbombay.org (Bakul Shah) Date: Fri, 4 Nov 2022 20:44:22 -0700 Subject: [TUHS] vi in cooked mode? In-Reply-To: References: <7b249e68-de74-2c81-32b0-18ecb74a85ec@aueb.gr> <20221105010247.GG29525@mcvoy.com> <20221105014029.GH29525@mcvoy.com> Message-ID: Wordstar came out in 1978, BDS C in 1979. MINCE was written in BDS C so it probably didn't come with BDS C (but BDS C came with MINCE)! In 1981/82 I ported Gosling Emacs to the Fortune box. It was slow as molasses. My memory is that was due to it using bitfields, for which our C compiler produced pretty bad code. But I didn't really investigate it in any detail. In contrast vi & e (Rand editor as further hacked on by Dave Yost) were so much better, especially on a 60 line Ann Arbor Ambassador. > On Nov 4, 2022, at 7:31 PM, Rich Salz wrote: > > I don't recall BDS C having an editor but I could be wrong. They pushed Mark of the Unicorn's MINCE (mince is not complete emacs) and scribble, a scribe mini-clone. BDS was a one man shop, it stood for brain-damaged software. > > On Fri, Nov 4, 2022, 9:40 PM Larry McVoy wrote: > On Fri, Nov 04, 2022 at 06:25:03PM -0700, Bakul Shah wrote: > > On Nov 4, 2022, at 6:02 PM, Larry McVoy wrote: > > > > > > I also got a little corrupted by whatever editor came with BDS C > > > > I think that was wordstar. I had to retrain my fingers when I > > switched to vi! I used SOS, edt(?) on Tops-10, edit(?) on CMS, > > teco (on ITS), wordstar (on CP/M), ed, vi, rand editor, acme. > > Now I stick to nvi & acme. And cat for small programs/files. > > I used wordstar but I think BDS C had their own thing. Wordstar > was different. > -- > --- > Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From tuhs at tuhs.org Sat Nov 5 19:29:42 2022 From: tuhs at tuhs.org (Otto Moerbeek via TUHS) Date: Sat, 5 Nov 2022 10:29:42 +0100 Subject: [TUHS] vi in cooked mode? In-Reply-To: <20221105010247.GG29525@mcvoy.com> References: <7b249e68-de74-2c81-32b0-18ecb74a85ec@aueb.gr> <20221105010247.GG29525@mcvoy.com> Message-ID: On Fri, Nov 04, 2022 at 06:02:47PM -0700, Larry McVoy wrote: > On Sat, Nov 05, 2022 at 11:45:26AM +1100, Dave Horsfall wrote: > > A boss of mine insisted that everyone had to learned "ed", because after a > > system crash it might be the only editor available; that, or having to > > dial in over a slow modem. > > Same. Though vi in ex mode was also good. Yep, the computer lab I had to use had 30 or so terminals connected to a VAX 11/750 running BSD. To get work done it was often neccesary to switch to ex mode in vi. Later I was a teacher's assistent with night access to the lab and I could use it on my own or with only a few fellow TA's. -Otto > > I also got a little corrupted by whatever editor came with BDS C, my > .exrc looks like this: > > > map # :.,$ > map @ :1,. > > Those came from that editor, # says do whatever to the end of the file, > @ says do whatever from the top of the file to here. > > map , !}fmt > > This came from Udi Manber, , runs your paragraph through fmt > > map!   > > I set shiftwidth to 4 spaces because when you have code like > > if ((this big thing == that big thing) && (this other big thing) && > (yet another big thing)) { > > I use 4 spaces for what I call the continuation line. I used ^A to write > that example, why I don't like ^T is lost to me. > > And yeah, I paren stuff that doesn't need to have parens, it just makes > the code more obvious. > > set redraw ai aw terse > > redraw I think is left over from modems, autoident because duh, > autowrite because who doesn't hack, hack, hack, ^Z, !cc? terse > because I'm not a newbie. > > set sections=uhshSHNH > set paragraphs=PSPETSTEFSFEKSKECSCERSREDSDEIPNPLPPPTLABAIAELIB1B2HH > > Troff. > > set ts=8 sw=4 > set shell=/bin/sh > set showmode > set textwidth=1000 > set vb > > Etc. > > I've been carrying around that .exrc for around 40 years. Sheesh, I'm old. From michael at casadevall.pro Sat Nov 5 20:38:22 2022 From: michael at casadevall.pro (Michael Casadevall) Date: Sat, 5 Nov 2022 06:38:22 -0400 Subject: [TUHS] Four windowing systems on SunOS In-Reply-To: <15edc92b-983f-2bf4-c265-75384b5a76c5@spamtrap.tnetconsulting.net> References: <20221031191401.GN22806@mcvoy.com> <202210311917.29VJHxe6110870@darkstar.fourwinds.com> <16d7a543-8c34-3663-f0d7-14b588683d6c@spamtrap.tnetconsulting.net> <15edc92b-983f-2bf4-c265-75384b5a76c5@spamtrap.tnetconsulting.net> Message-ID: On Wed, Nov 2, 2022 at 11:37 AM Grant Taylor via TUHS wrote: > On 11/2/22 2:55 AM, Michael Casadevall wrote: > > I extensively researched this; there are infact copies of Pinball for > > 64-bit platforms: https://www.youtube.com/watch?v=3EPTfOTC4Jw&t=47s > > Which 64-bit platforms? 64-bit x86 and / or 64-bit Itanium? > > I've not watched the video yet (today). > > Both actually, since Microsoft included pinball.exe on the Itanium install disk. Works too (although there are complications) > > Pinball had problems relating to 64-bit FPU precision (and this can > > actually be reproduced by fiddling with FPU flags), but it did ship in > > Windows XP x64 Professional. > > My understanding is that Windows XP x64 Professional is 64-bit x86 and > not Itanium. > > There is also a chance that I'm misremembering things. > > > No, its just the worst product naming scheme known to man. > > -- > Grant. . . . > unix || die > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lproven at gmail.com Sat Nov 5 21:21:49 2022 From: lproven at gmail.com (Liam Proven) Date: Sat, 5 Nov 2022 12:21:49 +0100 Subject: [TUHS] Four windowing systems on SunOS In-Reply-To: References: <20221031191401.GN22806@mcvoy.com> <202210311917.29VJHxe6110870@darkstar.fourwinds.com> <16d7a543-8c34-3663-f0d7-14b588683d6c@spamtrap.tnetconsulting.net> <15edc92b-983f-2bf4-c265-75384b5a76c5@spamtrap.tnetconsulting.net> Message-ID: On Sat, 5 Nov 2022 at 11:38, Michael Casadevall wrote: > > No, its just the worst product naming scheme known to man. To be fair -- something I rarely feel in connection with MICROS~1 -- when XP came out in 2002, AMD Sledgehammer did not exist yet. There was no x86-64 and the only Intel 64-bit architecture was Itanium. So I feel that they have some excuse. We should actually give MS _some_ credit on this, because it's only thanks to MS that Intel didn't do a totally separate incompatible 64-bit x86 extension. -- Liam Proven ~ Profile: https://about.me/liamproven Email: lproven at cix.co.uk ~ gMail/gTalk/FB: lproven at gmail.com Twitter/LinkedIn: lproven ~ Skype: liamproven UK: (+44) 7939-087884 ~ Czech [+ WhatsApp/Telegram/Signal]: (+420) 702-829-053 From tytso at mit.edu Sun Nov 6 04:34:51 2022 From: tytso at mit.edu (Theodore Ts'o) Date: Sat, 5 Nov 2022 14:34:51 -0400 Subject: [TUHS] vi in cooked mode? In-Reply-To: <20221105014029.GH29525@mcvoy.com> References: <7b249e68-de74-2c81-32b0-18ecb74a85ec@aueb.gr> <20221105010247.GG29525@mcvoy.com> <20221105014029.GH29525@mcvoy.com> Message-ID: On Fri, Nov 04, 2022 at 06:40:29PM -0700, Larry McVoy wrote: > On Fri, Nov 04, 2022 at 06:25:03PM -0700, Bakul Shah wrote: > > On Nov 4, 2022, at 6:02 PM, Larry McVoy wrote: > > > > > > I also got a little corrupted by whatever editor came with BDS C > > > > I think that was wordstar. I had to retrain my fingers when I > > switched to vi! I used SOS, edt(?) on Tops-10, edit(?) on CMS, > > teco (on ITS), wordstar (on CP/M), ed, vi, rand editor, acme. > > Now I stick to nvi & acme. And cat for small programs/files. > > I used wordstar but I think BDS C had their own thing. Wordstar > was different. There was also Turbo Pascal, which also had a very Wordstar-like editor. - Ted From rdm at cfcl.com Mon Nov 7 09:56:47 2022 From: rdm at cfcl.com (Rich Morin) Date: Sun, 6 Nov 2022 15:56:47 -0800 Subject: [TUHS] early Unix papers, from Jim Joyce In-Reply-To: <74b464ac-2799-badd-9eae-a65acbe08bd7@spamtrap.tnetconsulting.net> References: <20221102060730.A114A18C08A@mercury.lcs.mit.edu> <74b464ac-2799-badd-9eae-a65acbe08bd7@spamtrap.tnetconsulting.net> Message-ID: <86F17F7B-4775-4B15-BC83-0E7FEC974786@cfcl.com> I'd like to begin by thanking folks for their suggestions. I'd also like to express my awe and appreciation for Nelson Beebe's bibliographic work. That said, I am not now (and will likely never be) in a position to do anything similar for the documents in question, let alone scan and OCR them, etc. If someone wants to take on such a project, please let me know. However, as a small step along the way, I opened up the box and produced a rough list of the contents (see below). When I noticed version or date information, I noted it, but many of the documents are missing that sort of thing. So, YMMV. It appears that most of the items are copies of Unix Version 7 documents, printed at UC Berkeley (UCB). Some of the rest are a mix of photocopied articles from magazines (e.g., BSTJ, BYTE, Comm. ACM, Software--Practice and Experience). I assume that most of this content is readily available, but some may not be. In any case, the bibliographic info might be useful. Finally, there are assorted documents that were edited or produced at UCB. Some of these (especially the ones marked DRAFT) may be of historical interest. Anyway, please let me know if any of this sounds like it might be worth passing along... -r P.S. Careful Reader may notice a strong emphasis on text processing in this collection. Jim's research interests included the use of computers to analyze Middle English poetry. For example, the rhyme schemes allowed him to clarify the pronunciation of certain words. # Notes The documents are currently stored in manilla folders in a cardboard box. Folders are separated by bars (---) in the List. Folders are listed below in the order found in the box. Dates and "UNX x.y.z" notations are transcribed, when available. These notations appear to relate to UCB's "UNIX Documentation Guide". # List "The Programmer's Workbench -- A Machine for Software Development" Evan L. Ivie Comm. ACM; October, 1977 --- "Lint, a C Program Checker" S. C. Johnson UNX 12.2.3 July 26, 1978 --- "A Tour Through the Portable C Compiler" S. C. Johnson UNX 13.2.7 --- "UNIX Programming -- Second Edition" Brian W. Kernighan, Dennis M. Ritchie UNX 2.2.3 November 12, 1978 --- "Some Applications of Inverted Indexes on the UNIX System" M. E. Lesk UNX 12.2.2 --- "Why Pascal is Not My Favorite Programming Language" Brian W. Kernighan July 18, 1981 --- "A TROFF Tutorial" Brian W. Kernighan --- "RATFOR -- A Preprocessor for a Rational Fortran" Brian W. Kernighan UNX 12.2.6 --- "Advanced Editing on UNIX" Brian W. Kernighan UNX 3.3.3 October 17, 1980 --- "Nroff / Troff User's Manual" Joseph F. Ossanna --- "A Typesetter-independent TROFF" Brian W. Kernighan --- "A Tutorial Introduction to the UNIX Text Editor" B. W. Kernighan --- "PIC -- A Graphics Language for Typesetting" "User Manual" Brian W. Kernighan Revised Edition; March, 1982 "PIC -- A Graphics Language for Typesetting" "User Manual" Brian W. Kernighan --- "Typesetting Mathematics -- User's Guide (Second Edition)" Brian W. Kernighan and Lorinda L. Cherry May 30, 1977 --- "A System for Typesetting Mathematics" Brian W. Kernighan and Lorinda L. Cherry Comm. ACM; March, 1975 --- "The PIC Graphics Language" --- "LEARN -- Computer-Aided Instruction on UNIX (Second Edition)" Brian W. Kernighan, Michael E. Lesk UNX 12.2.1 January 30, 1979 --- "UNIX Programming -- Second Edition" Brian W. Kernighan, Dennis M. Ritchie November 12, 1978 --- "FSCK -- The Unix File System Check Program" T. J. Kowalski --- "Typing Documents on UNIX and GCOS: the -ms Macros for Nroff and Troff" M. E. Lesk October 8, 1976 "A Revised Version of -ms" (DRAFT) Bill Tuthill UNX 4.42 12/6/82 also includes a line printer listing ??? --- "Combining Data Bases: National and Cartographic Files" Michael E. Lesk October 26, 1981 --- "Lex - A Lexical Analyzer Generator" M. E. Lesk and E. Schmidt UNX 12.2.5 --- SED -- A Non-interactive Text Editor" Lee E. McMahon UNX 12.2.8 August 15, 1978 --- "Statistical Text Processing" L. E. McMahon, L. L. Cherry, and R. Morris BSTJ Vol. 57, No. 6; July-August, 1978 --- "A Tutorial Introduction to ADB" J. F. Maranzano, S. R. Bourne UNX 11.3.1 May 5, 1977 --- "The UNIX (tm) system: making computers easier to use" Samuel P. Morgan Bell Laboratories Record; December, 1978 --- "Password Security: A Case History" Robert Morris, Ken Thompson UNX 13.2.10 April 3, 1978 --- Uucp Implementation Description UNX 13.2.9 D. A. Nowitz UNX 13.2.9 October 31, 1978 --- "C Reference Manual" Dennis M. Ritchie --- "The Standard I/O Library" D. M. Ritchie E. M. Gould (local editing) March 27, 1978 --- "Classes: An Abstract Data Type Facility for the C Language" Bjarne Stroustrup Bell Labs CSTR No. 84 April 3, 1980 Revised August 14, 1981 --- "A Set of C Classes for Co-routine Style Programming" Bjarne Stroustrup Bell Labs CSTR No. 90 November 18, 1980 --- "UNIX Implementation" K. Thompson UNX 13.2.4 --- "UNIX Documentation Guide" Computing Services, UC Berkeley --- "Berkeley Software for UNIX on the VAX" "4.1bsd version of May, 1981" --- "Ex/Edit Command Summary (Version 2.0)" Computing Services, UC Berkeley August 29, 1979 --- "-ms Command Summary" (DRAFT 2 May 78) --- "UNIX Command Summary" Computer Center, UC Berkeley January 18, 1978 --- "Ex Reference Manual" "Version 1.1 -- November, 1977" William N. Joy CSD, EECS, USB November 26, 1977 --- "Experiences with the UNIX Time-sharing System" John Lions Software--Practice and Experience, Vol. 9, 702-709 (1979) --- "Writing Papers with NROFF using -ME" Eric P. Allman Electronics Research Laboratory, UCB May 13, 1978 --- "-ME Reference Manual" Eric P. Allman Electronics Research Laboratory, UCB May 13, 1978 --- "Writing NROFF Terminal Descriptions" Eric Allman Britton-Lee, Inc. --- "Bell's Lettres" Natalie Angier Discover; July, 1981 --- "Screen Updating and Cursor Management Optimization: A Library Package" Kenneth C. R. C. Arnold CSD, EECS, UCB 4th Berkeley Distribution --- "Design and Implementation of the Berkeley Virtual Memory Extensions to the UNIX Operating System" Ozalp Babaoglu, William Joy, Juan Porcar CSD, EECS, UCB December 2, 1979 --- "Data Structures Added in the Berkeley Virtual Memory Extensions to the UNIX Operating System" Ozalp Babaoglu, William Joy CSD, EECS, UCB November 23, 1979 --- "UNIX with Satellite Processors" Amnon B. Barak and Amos Shapir Software--Practice and Experience, Vol. 10, 383-392 (1980) --- "Development system interface expedited software design" Jim Bessemer Electronics Design; September 2, 1982 --- "LocalNet and UNIX" K. J. Biba, S. J. Leffler Sytek, Inc.; June, 1981 --- "Edit: A Tutorial" Ricki Blau, James Joyce Computing Services, UCB UNX 3.3.1 September, 1981 "Edit: A Tutorial" Ricki Blau, James Joyce Computing Services Division, Computing Affairs, UCB January, 1978 "Text Editing with UNIX" --- "Communicating with UNIX" Ricki Blau Computing Services, UCB UNX 1.3.1 September, 1981 --- "UNIX on a Micro" Cornelia Boldyreff SIGSMALL Newsletter, Vol. 7, No. 1; February, 1981 --- "Extending the Interprocess Communication Facility of UNIX for a Distributed Operating System" Sheng-Yang Chiu Bolt, Beranek and Newman, Inc. 27 July 1981 Revised: 31 July 1981 Request for Comments: DOS-8 --- "DEAFNET: A Distributed Communications Service for the Deaf" Earl Craighill SRI International May, 1980 --- Programmer's Workbench Papers Second International Conference on Software Engineering T. A. Dolotta, J. R. Mashey, D. W. Smith, M. H. Bianchi, J. L. Wood October 13-15, 1976 --- "The Programmer's Workbench" T. A. Dolotta, R. C. Haight, J. R. Mashey BSTJ; July-August, 1978 --- "A Comparison of the Programming Languages C and Pascal" Alan R. Feuer, Narain H. Gehani ACM Computing Surveys, Vol. 14, No. 1; March 1982 --- "A Dual Processor VAX 11/780" George H. Goble, Michael H. Marsh School of EE, Purdue TR-EE 81-31; September, 1981 --- "The UNIX Operating System and the XENIX Standard Operating Environment" Robert B. Greenberg BYTE; June, 1981 --- "Growing, Pruning and Climbing Binary Trees with tiny-c" Les Hancock Dr. Dobb's Journal No. 36, Vol. 4, Issue 6; June/July 1979 --- "Implementing a tiny interpreter with a CP/M-flavored C" Les Hancock Dr. Dobb's Journal No. 41 --- "A Portable File Directory System" David R. Hanson Software--Practice and Experience, Vol. 10, 623-634 (1980) --- "Getting Acquainted with Ex: An Aid for Humanities Users" A Publication of The Old English Colloquium's Unix Project A. Hernandez January 1, 1979 --- "Some Facts and Fallacies about UNIX" Jim Isaak FORUM, Computer System News; January 18, 1982 --- "Operating systems confer new degree of sophistication on microprocessors" R. Colin Johnson Electronics; March 24, 1981 --- "UNIX - New Avenues in Research and Development" Robert E. Jones Hardcopy; February, 1982 --- "An Architecture for Interprocess Communication in UNIX" William Joy and Robert Fabry CSRG, EECS, UCB DRAFT of June 22, 1981 "Proposals for enhancement of UNIX on the VAX" William Joy and Robert Fabry CSRG, EECS, UCB July 21, 1981; Revised August 31, 1981 --- "4.2BSD System Manual" William Joy, Eric Cooper, Robert Fabry, Samuel Leffler and Kirk McKusick CSRG, EECS, UCB Draft of February 14, 1982 --- "An Introduction to Display Editing with Vi" William Joy CSRG, EECS, UCB April 2, 1979 --- "Berkeley Pascal User's Manual" William N. Joy, Susan L. Graham, Charles B. Haley CSD, EECS, UCB Version 1.1 - April, 1979 --- "Installing and Operating 4.1bsd" William N. Joy CSRG, EECS, UCB May 18, 1981 --- "Berkeley Pascal PX Implementation Notes" Version 1.1 - April, 1979 William N. Joy CSD, EECS, UCB March 30, 1979 "Berkeley Pascal PX Implementation Notes" Version 2.0 - January, 1979 William N. Joy, M. Kirk McKusick CSD, EECS, UCB April 9, 1981 --- "Berkeley Pascal PXP Implementation Notes" Version 1.1 - April, 1979 William N. Joy CSD, EECS, UCB April 10, 1981 --- "UNIX Aids for English Composition Courses" James Joyce Computing in the Humanities; 1982 --- "PIC -- A Crude Graphics Language for Typesetting" Brian W. Kernighan Bell Labs CSTR No. 85 January 24, 1981 also published in: Software--Practice and Experience, Vol. 12, 1-21 (1982) --- "Printf for the C Function Library" Christopher Kern BTYE; May, 1981 --- "The BDS C Compiler" Christopher Kern BYTE; June, 1981 --- "The Unix Programming Environment" Brian W. Kernighan, John R. Mashey IEEE Computer; April, 1981 --- "Hints on Configuring VAX Systems for UNIX" Revised: May 4, 1981 Bob Kridle, Bill Joy CSRG, UCB --- "Unix Text Formatting for Beginners" Gordon P. Leffadinger Computing Services, UCB May 10, 1982 (DRAFT) --- "The UNIX Operating System" "A Sophisticated and Portable Multiuser Operating System" Bob Marsh, Grant Munsey, Kip Myers, Craig Forney Microcomputer Operating Systems, in Microcomputer Applications, (c) 1981 --- "Data Stream Linkage Mechanism" J. P. Morrison IBM Syst J, Vol. 17, No. 4; 1978 --- "Unix-like software runs on mini- and microcomputers" P. J. Plauger and M. S. Krieger Electronics; March 24, 1981 --- "An Inter-Process Communication Facility for UNIX" Richard F. Rashid CMU-CS-80-124 February 4, 1980 Revised: 11 June 1980 "An Inter-Process Communication Facility for UNIX" Richard F. Rashid February 4, 1980 Revised: 2 April 1981 --- "Thoughts on 'An Architecture for Interprocess Communication' by William Joy and Robert Fabry" DRAFT -- DO NOT CIRCULATE' A Personal Commentary Richard F. Rashid printed 29-Jul-81 --- "An Introduction to the Berkeley Network" Eric Schmidt CSD, EECS, UCB May, 1979 (revised March, 1980) --- "The UNIXperience for the Unexpert" Wurster Computer Center "The UNIXperience for Unexperts was prepared with the UNIX system by Claire E. Taylor, a real beginner, in the Spring of 1979, for the computer graphics course taught by Aaron Marcus" --- "LIST -- A Source-Listing Program for the C Language" Jeff Taylor BYTE; June, 1981 --- "The -mx Macro Package: A Revised Version of -ms" Bill Tuthill Computing Services, UCB (DRAFT) --- "Literary Text Processing by Computer" William Tuthill Comparative literature Dept., UCB 15 January 1981 also, man pages for assorted commands in the HUM section: cedilla, cfreq, dict, dissolve, ... --- "The Unix Word Processing Facilities" Vance Vaughan June 1, 1977 --- "Adapting Unix to a 16-bit microcomputer" Bruce Weiner and Douglas Swartz Electronics; March 24, 1981 --- "Productivity Engineering in the UNIX Environment" EECS & ERL, UCB This appears to be a grant proposal: "The proposed contract will be a continuation of contract N00039-80-K-0649, ARPA Order Number 4031, April 1980 to present." --- (not in a folder) "Writing Distributed Programs with Courier" Eric C. Cooper CSD, EECS, UCB "gprof: A Call Graph Execution Profiler" Susan L. Graham, Peter B. Kessler, Marshall K. McKusick CSD, EECS, UCB Proc. ACM SIGPLAN -82 Symp. on Compiler Construction "VAX/VMS Performance and Configuration" Hank Levy Advanced-11 Engineering August 15, 1978 --- "A Fast File System for UNIX" DRAFT of September 6, 1982 Marshall Kirk McKusick, William N. Joy, Samuel J. Leffler, Robert S. Fabry CSRG, CSD, EECS, UCB "Refer -- A Bibliography System" Bill Tuthill Computing Services, UCB October 1, 1982 "Refer -- A Bibliography System" Bill Tuthill Humanities Computing Service, UCB September 6, 1982 "The Cambridge Ring and UNIX" R. P. A. Collinson Software--Practice and Experience, Vol. 12, 583-594 (1982) "Description of a Menu Creation and Interpretation System" Michael J. Heffler Software--Practice and Experience, Vol. 12, 269-281 (1982) "A Programmable Text Editor" Christopher W. Fraser Software--Practice and Experience, Vol. 12, 241-250 (1982) "The Syntax of Interactive Command Languages: A Framework for Design" I. Trotter Hardy, Jr. Software--Practice and Experience, Vol. 12, 67-75 (1982) "Why Pascal is Not My Favorite Programming Language" Brian W. Kernighan CSTR No. 100 July 18, 1981 "A High-Level Approach to Computer Document Formatting" Brian K. Reid 1980 ACM 0-89791-011-7 "How Users Search: A Comparison of Menu and Attribute Retrieval Systems on a Library Catalog" V. J. Geller M. E. Lesk Bell Labs September 27, 1981 "Porting the Unix Operating System" Robert Erickson, Peter Tom HHB-SOFTRON (describes porting of UNIX/v7 to the SIEMENS R30) --- "A Walk Through AWK" Leon S. Levy Bell Labs SIGPLAN Notices, V18 #12; December, 1983 --- "Setting Up Unix - Seventh Edition" Charles B. Haley, Dennis M. Ritchie Bell Labs UNX 13.2.2 --- "PARTS - A System for Assigning Word Classes to English Text" L. L. Cherry Bell Labs, CSTR No. 81 --- "Writing Tools - The STYLE and DICTION Programs L. L. Cherry, W. Vesterman February, 1981 "Writing Tools - The STYLE and DICTION Programs L. L. Cherry, W. Vesterman November 22, 1980 Letter from Jim Joyce to Lorinda Cherry, inviting her to speak at the 1983 meeting of the Association for Literary and Linguistic Computing "The Seybold Report on Word Processing" Vol. 4, No. 1, January 1981 ISSN: 0160-9572 --- "Route Finding in Street Maps by Computers and People" R. J. Elliott, M. E. Lesk Bell Labs --- "Regenerating System Software" Charles B. Haley, Dennis M. Ritchie Bell Labs UNX 13.2.3 --- "Make - A Program for Maintaining Computer Programs" S. I. Feldman Bell Labs --- --- From imp at bsdimp.com Tue Nov 8 03:50:33 2022 From: imp at bsdimp.com (Warner Losh) Date: Mon, 7 Nov 2022 10:50:33 -0700 Subject: [TUHS] LOC [was Re: Re: Re.: Princeton's "Unix: An Oral History": who was in the team in "The Attic"? In-Reply-To: <0db171e4-7efe-8c00-bb30-a6f914cf9911@technologists.com> References: <992562BA-E21F-4542-A50B-6CFE8F7ACE86@planet.nl> <20221011134842.GA11780@mcvoy.com> <20221011195447.GI11780@mcvoy.com> <8583490b-c7cc-4633-b506-2f16335fd3e2@home.arpa> <20221011201025.GJ11780@mcvoy.com> <513e8a46-bd31-420a-bfdf-b59451f89c8d@home.arpa> <0db171e4-7efe-8c00-bb30-a6f914cf9911@technologists.com> Message-ID: On Tue, Oct 11, 2022 at 2:34 PM Charles H Sauer (he/him) < sauer at technologists.com> wrote: > On 10/11/2022 3:14 PM, Michael Kjörling wrote: > > On 11 Oct 2022 13:10 -0700, from lm at mcvoy.com (Larry McVoy): > >>> Isn't it relatively well established, though, that IBM culture at > >>> least for a very long time put heavy emphasis on counting lines of > >>> source code, and that more SLOC was considered to be better? > >> > >> That's just stupid. > > > > You're getting no argument from me there. > > > > It was likely true that some parts of IBM put heavy emphasis on LOC, but > as Marc points out, that wasn't true in Research. I don't remember heavy > LOC emphasis in AIX groups, and I suspect even in Boca (OS/2) there was > not "heavy" emphasis. > Speaking of "just stupid" Word on the street is that Elon Musk stack ranked the engineers by lines of code over the last year (source: https://ma.nu/blog/bye-twitter) and layed off the bottom performers in terms of LoC... Not 100% sure this is legit, since some tweets about it have been deleted. Warners -------------- next part -------------- An HTML attachment was scrubbed... URL: From bakul at iitbombay.org Tue Nov 8 05:57:20 2022 From: bakul at iitbombay.org (Bakul Shah) Date: Mon, 7 Nov 2022 11:57:20 -0800 Subject: [TUHS] LOC [was Re: Re: Re.: Princeton's "Unix: An Oral History": who was in the team in "The Attic"? In-Reply-To: References: Message-ID: <26FA85DD-7316-4F7F-A6F9-24FE6E723674@iitbombay.org> On Nov 7, 2022, at 9:52 AM, Warner Losh wrote: > > Speaking of "just stupid" > > Word on the street is that Elon Musk stack ranked the engineers by lines of code > over the last year (source: https://ma.nu/blog/bye-twitter) and layed off the bottom > performers in terms of LoC... Just LoCo! -------------- next part -------------- An HTML attachment was scrubbed... URL: From crossd at gmail.com Tue Nov 8 06:11:39 2022 From: crossd at gmail.com (Dan Cross) Date: Mon, 7 Nov 2022 15:11:39 -0500 Subject: [TUHS] LOC [was Re: Re: Re.: Princeton's "Unix: An Oral History": who was in the team in "The Attic"? In-Reply-To: References: <992562BA-E21F-4542-A50B-6CFE8F7ACE86@planet.nl> <20221011134842.GA11780@mcvoy.com> <20221011195447.GI11780@mcvoy.com> <8583490b-c7cc-4633-b506-2f16335fd3e2@home.arpa> <20221011201025.GJ11780@mcvoy.com> <513e8a46-bd31-420a-bfdf-b59451f89c8d@home.arpa> <0db171e4-7efe-8c00-bb30-a6f914cf9911@technologists.com> Message-ID: On Mon, Nov 7, 2022 at 12:52 PM Warner Losh wrote: > On Tue, Oct 11, 2022 at 2:34 PM Charles H Sauer (he/him) wrote: >> On 10/11/2022 3:14 PM, Michael Kjörling wrote: >> > On 11 Oct 2022 13:10 -0700, from lm at mcvoy.com (Larry McVoy): >> >>> Isn't it relatively well established, though, that IBM culture at >> >>> least for a very long time put heavy emphasis on counting lines of >> >>> source code, and that more SLOC was considered to be better? >> >> >> >> That's just stupid. >> > >> > You're getting no argument from me there. >> >> It was likely true that some parts of IBM put heavy emphasis on LOC, but >> as Marc points out, that wasn't true in Research. I don't remember heavy >> LOC emphasis in AIX groups, and I suspect even in Boca (OS/2) there was >> not "heavy" emphasis. > > Speaking of "just stupid" > > Word on the street is that Elon Musk stack ranked the engineers by lines of code > over the last year (source: https://ma.nu/blog/bye-twitter) and layed off the bottom > performers in terms of LoC... Well, if I ever go to work for Twitter, I know how I'm initializing large arrays. > Not 100% sure this is legit, since some tweets about it have been deleted. I suspect it was slightly more nuanced, having more to do with "total output" measured as some combination of number of changes and their total size. It sure is dumb, though. - Dan C. From tuhs at tuhs.org Tue Nov 8 08:16:24 2022 From: tuhs at tuhs.org (Grant Taylor via TUHS) Date: Mon, 7 Nov 2022 15:16:24 -0700 Subject: [TUHS] early Unix papers, from Jim Joyce In-Reply-To: <86F17F7B-4775-4B15-BC83-0E7FEC974786@cfcl.com> References: <20221102060730.A114A18C08A@mercury.lcs.mit.edu> <74b464ac-2799-badd-9eae-a65acbe08bd7@spamtrap.tnetconsulting.net> <86F17F7B-4775-4B15-BC83-0E7FEC974786@cfcl.com> Message-ID: <332950bf-f61c-0c76-63fa-caa33911ced3@spamtrap.tnetconsulting.net> On 11/6/22 4:56 PM, Rich Morin wrote: > However, as a small step along the way, I opened up the box and > produced a rough list of the contents (see below). When I noticed > version or date information, I noted it, but many of the documents > are missing that sort of thing. So, YMMV. Thank you very much for the list. The provided details and your care to separate things is appreciated. > P.S. Careful Reader may notice a strong emphasis on text processing > in this collection. Jim's research interests included the use of > computers to analyze Middle English poetry. For example, the rhyme > schemes allowed him to clarify the pronunciation of certain words. I noticed that. I also noticed that I would very much like to spend some (upcoming) cold winter days with tea reading many of these papers. I'd be happy to help contribute to get these papers somewhere to be scanned & shared. Sadly I don't know how to go about doing the scanning myself. I'll contribute at least $10 toward getting these papers somewhere to be scanned. My efforts to scan front & back covers of my books doesn't scale to scanning, much less OCRing, books. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4017 bytes Desc: S/MIME Cryptographic Signature URL: From tuhs at tuhs.org Tue Nov 8 09:12:40 2022 From: tuhs at tuhs.org (segaloco via TUHS) Date: Mon, 07 Nov 2022 23:12:40 +0000 Subject: [TUHS] early Unix papers, from Jim Joyce In-Reply-To: <332950bf-f61c-0c76-63fa-caa33911ced3@spamtrap.tnetconsulting.net> References: <20221102060730.A114A18C08A@mercury.lcs.mit.edu> <74b464ac-2799-badd-9eae-a65acbe08bd7@spamtrap.tnetconsulting.net> <86F17F7B-4775-4B15-BC83-0E7FEC974786@cfcl.com> <332950bf-f61c-0c76-63fa-caa33911ced3@spamtrap.tnetconsulting.net> Message-ID: <18Dhvwn9Aec6LXGA5dkWkgVdxkprEOxlu7by1jOzuRHRz4Dd6095utKlbod1TRPI8R25Z06CXqkQO3ID9o6p4Cef7NvjI90-nrJsdH7ngy0=@protonmail.com> The following papers stick out to me as papers that haven't surfaced in any of the research I've done (not exhaustive, but what stuck out to me): The Programmer's Workbench - A Machine for Software Development - Is this distinct from the Mashey papers? Why Pascal is Not My Favorite Programming Language - This sounds fun, not hard UNIX info, but fun A Typesetter-Independent TROFF - A ditroff-specific paper? Can't say I've seen such a thing, would be interested in this one. I know someone (can't recall name/email) in the GROFF mailing list seemed particularly excited about ditroff information that could be gleaned from the UNIX/TS 4.0 docs, this may be their golden carrot. PIC - A Graphics Language for Typesetting - The list mentions a March 1982 revision. This would post-date the UNIX/TS 4.0 version, although there is the Research V10 version of the paper. However, an initial flip through the V10 Volume 2 manual reveals no specific last-modify date. That would ultimately trace back to https://minnie.tuhs.org/cgi-bin/utree.pl?file=V8/usr/doc/pic . I can't find the roff sources for V9 or V10 of this paper though, I've just got the physical book for V10. The PIC Graphics Language - Another PIC paper? FSCK - The Unix File System Check Program - This paper shows up in UNIX/TS document sets but not research. I'd be curious of the specific date on this one, the latest one we have afaik is 1981, UNIX/TS 4.0. Combining Data Bases: National and Cartographic Files - Not explicitly UNIX perhaps? Either way, I like maps, I'd be curious what is going on here The UNIX System: Making Computers Easier To Use - Perhaps a transcript of https://www.youtube.com/watch?v=XvDZLjaCJuw ? C Reference Manual - Curious on the date, there are many revisions scanned UNIX Documentation Guide - BSD "Documentation Roadmap" perhaps? I have a 4BSD paper compilation from some university in Australia, seems to just be a subset of C and Fortran related papers though, I wonder if there's correlation between this and the intro paper in that set... The Unix Programming Environment - Kernighan and Mashey? Does this bear any relation to the book authored with Rob Pike? I feel like I've seen this title in passing but am definitely curious. A Walk Through AWK - Somewhere between the original AWK paper and the AWK book? PARTS - A System for Assigning Word Classes to English Text - Probably the paper underlying descriptions of parts in later WWB literature. Writing Tools - The STYLE and DICTION Programs - Ditto, I'd be curious how much of what became trade-book WWB/DWB documentation started as Bell memoranda and if a full manual could be compiled from just memoranda. Route Finding in Street Maps by Computers and People - More maps work by Bell, didn't know they did stuff in this area I would absolutely be interested in throwing my hat in the ring on preservation, can pay for shipping to and fro and scanning would be gratis. That said, if someone expects a certain DPI, OCR, etc. then you can pay someone, I volunteer my resources at the capacity I can volunteer them. If someone else can do the whole package, I'll also happily donate towards that. - Matt G. ------- Original Message ------- On Monday, November 7th, 2022 at 2:16 PM, Grant Taylor via TUHS wrote: > On 11/6/22 4:56 PM, Rich Morin wrote: > > > However, as a small step along the way, I opened up the box and > > produced a rough list of the contents (see below). When I noticed > > version or date information, I noted it, but many of the documents > > are missing that sort of thing. So, YMMV. > > > Thank you very much for the list. The provided details and your care to > separate things is appreciated. > > > P.S. Careful Reader may notice a strong emphasis on text processing > > in this collection. Jim's research interests included the use of > > computers to analyze Middle English poetry. For example, the rhyme > > schemes allowed him to clarify the pronunciation of certain words. > > > I noticed that. > > I also noticed that I would very much like to spend some (upcoming) cold > winter days with tea reading many of these papers. > > I'd be happy to help contribute to get these papers somewhere to be > scanned & shared. Sadly I don't know how to go about doing the scanning > myself. > > I'll contribute at least $10 toward getting these papers somewhere to be > scanned. > > My efforts to scan front & back covers of my books doesn't scale to > scanning, much less OCRing, books. > > > > -- > Grant. . . . > unix || die From arnold at skeeve.com Tue Nov 8 16:30:42 2022 From: arnold at skeeve.com (arnold at skeeve.com) Date: Mon, 07 Nov 2022 23:30:42 -0700 Subject: [TUHS] early Unix papers, from Jim Joyce In-Reply-To: <18Dhvwn9Aec6LXGA5dkWkgVdxkprEOxlu7by1jOzuRHRz4Dd6095utKlbod1TRPI8R25Z06CXqkQO3ID9o6p4Cef7NvjI90-nrJsdH7ngy0=@protonmail.com> References: <20221102060730.A114A18C08A@mercury.lcs.mit.edu> <74b464ac-2799-badd-9eae-a65acbe08bd7@spamtrap.tnetconsulting.net> <86F17F7B-4775-4B15-BC83-0E7FEC974786@cfcl.com> <332950bf-f61c-0c76-63fa-caa33911ced3@spamtrap.tnetconsulting.net> <18Dhvwn9Aec6LXGA5dkWkgVdxkprEOxlu7by1jOzuRHRz4Dd6095utKlbod1TRPI8R25Z06CXqkQO3ID9o6p4Cef7NvjI90-nrJsdH7ngy0=@protonmail.com> Message-ID: <202211080630.2A86Ugc6004710@freefriends.org> Hi. > Why Pascal is Not My Favorite Programming Language > - This sounds fun, not hard UNIX info, but fun It's been around for a long time. A while back, I reconstituted it, see https://www.github.com/arnoldrobbins/cstr100. > A Typesetter-Independent TROFF > - A ditroff-specific paper? Can't say I've seen such a thing, would > be interested in this one. I know someone (can't recall name/email) > in the GROFF mailing list seemed particularly excited about ditroff > information that could be gleaned from the UNIX/TS 4.0 docs, this may > be their golden carrot. This is also around on the Internet. If there's interest, I might could wheedle the original out of BWK. > A Walk Through AWK > - Somewhere between the original AWK paper and the AWK book? I missed this in the original list. I'd love to have a copy of it! Arnold From g.branden.robinson at gmail.com Wed Nov 9 02:42:20 2022 From: g.branden.robinson at gmail.com (G. Branden Robinson) Date: Tue, 8 Nov 2022 10:42:20 -0600 Subject: [TUHS] early Unix papers, from Jim Joyce In-Reply-To: <18Dhvwn9Aec6LXGA5dkWkgVdxkprEOxlu7by1jOzuRHRz4Dd6095utKlbod1TRPI8R25Z06CXqkQO3ID9o6p4Cef7NvjI90-nrJsdH7ngy0=@protonmail.com> References: <20221102060730.A114A18C08A@mercury.lcs.mit.edu> <74b464ac-2799-badd-9eae-a65acbe08bd7@spamtrap.tnetconsulting.net> <86F17F7B-4775-4B15-BC83-0E7FEC974786@cfcl.com> <332950bf-f61c-0c76-63fa-caa33911ced3@spamtrap.tnetconsulting.net> <18Dhvwn9Aec6LXGA5dkWkgVdxkprEOxlu7by1jOzuRHRz4Dd6095utKlbod1TRPI8R25Z06CXqkQO3ID9o6p4Cef7NvjI90-nrJsdH7ngy0=@protonmail.com> Message-ID: <20221108164220.q5dmgmckl6haenn6@illithid> At 2022-11-07T23:12:40+0000, segaloco via TUHS wrote: > The following papers stick out to me as papers that haven't surfaced > in any of the research I've done (not exhaustive, but what stuck out > to me): > > Why Pascal is Not My Favorite Programming Language > - This sounds fun, not hard UNIX info, but fun The infamous CSTR #100. :D It has been in circulation as a while, though the copy I have has been stripped of its CSTR identifier and the header margin is suspiciously short for an ms(7) paper. > A Typesetter-Independent TROFF > - A ditroff-specific paper? Can't say I've seen such a thing, > would be interested in this one. That's CSTR #97, also well-known, albeit not as well known as it should be by people who regard CSTR #54 (1992 revision) as Torah. #97 is surely Taldmudic. > I know someone (can't recall name/email) in the GROFF mailing list > seemed particularly excited about ditroff information that could be > gleaned from the UNIX/TS 4.0 docs, this may be their golden carrot. That was me. The golden carrot would be the [nt]roff source from that release. Someone pointed me in the direction of McKusick's CSRG CD-ROM archives for that, but I haven't made the time to chase it down. I'm trying to eat my vegetables first and get a groff release out. We're closing in on 400 bugs fixed since 1.22.4... > PIC - A Graphics Language for Typesetting > - The list mentions a March 1982 revision. This would post-date > the UNIX/TS 4.0 version, although there is the Research V10 > version of the paper. However, an initial flip through the V10 > Volume 2 manual reveals no specific last-modify date. That would > ultimately trace back to > https://minnie.tuhs.org/cgi-bin/utree.pl?file=V8/usr/doc/pic . I > can't find the roff sources for V9 or V10 of this paper though, > I've just got the physical book for V10. I'm envious, if you have both bound volumes of the V10 manuals. groff's pic.ms document (identifying Eric Raymond as author, although I believe it understates its debt to the above document, CSTR #116) muses about a "pre-ditroff" version of pic, but I have never encountered any evidence that any such thing existed. The \D drawing command escape sequences did not exist in Ossanna's troff; see the line 601 switch() in . > The PIC Graphics Language > - Another PIC paper? I'm curious to see any variant documentation of pic, particularly its early versions. > Writing Tools - The STYLE and DICTION Programs > - Ditto, I'd be curious how much of what became trade-book WWB/DWB > documentation started as Bell memoranda and if a full manual could > be compiled from just memoranda. I share your interest in WWB-related documents. In case there's anyone who's not already aware of this, the Internet Archive has a very nice cache of documents formerly hosted at cs.bell-labs.com. https://web.archive.org/web/20080509085821/http://www.cs.bell-labs.com/cm/cs/cstr.html I find the refer(1) database of _all_ CSTR document numbers to be of particular interest. https://web.archive.org/web/20080509085821/http://www.cs.bell-labs.com/cm/cs/cstr/bib Regards, Branden -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From marc.donner at gmail.com Wed Nov 9 04:55:36 2022 From: marc.donner at gmail.com (Marc Donner) Date: Tue, 8 Nov 2022 13:55:36 -0500 Subject: [TUHS] LOC [was Re: Re: Re.: Princeton's "Unix: An Oral History": who was in the team in "The Attic"? In-Reply-To: References: <992562BA-E21F-4542-A50B-6CFE8F7ACE86@planet.nl> <20221011134842.GA11780@mcvoy.com> <20221011195447.GI11780@mcvoy.com> <8583490b-c7cc-4633-b506-2f16335fd3e2@home.arpa> <20221011201025.GJ11780@mcvoy.com> <513e8a46-bd31-420a-bfdf-b59451f89c8d@home.arpa> <0db171e4-7efe-8c00-bb30-a6f914cf9911@technologists.com> Message-ID: My buds in the SRE community confirm that Twitter laid off the entire SRE team, since of course they didn't write enough code. Good luck with keeping the system up. ===== nygeek.net mindthegapdialogs.com/home On Mon, Nov 7, 2022 at 12:52 PM Warner Losh wrote: > > > On Tue, Oct 11, 2022 at 2:34 PM Charles H Sauer (he/him) < > sauer at technologists.com> wrote: > >> On 10/11/2022 3:14 PM, Michael Kjörling wrote: >> > On 11 Oct 2022 13:10 -0700, from lm at mcvoy.com (Larry McVoy): >> >>> Isn't it relatively well established, though, that IBM culture at >> >>> least for a very long time put heavy emphasis on counting lines of >> >>> source code, and that more SLOC was considered to be better? >> >> >> >> That's just stupid. >> > >> > You're getting no argument from me there. >> > >> >> It was likely true that some parts of IBM put heavy emphasis on LOC, but >> as Marc points out, that wasn't true in Research. I don't remember heavy >> LOC emphasis in AIX groups, and I suspect even in Boca (OS/2) there was >> not "heavy" emphasis. >> > > Speaking of "just stupid" > > Word on the street is that Elon Musk stack ranked the engineers by lines > of code > over the last year (source: https://ma.nu/blog/bye-twitter) and layed off > the bottom > performers in terms of LoC... > > Not 100% sure this is legit, since some tweets about it have been deleted. > > Warners > -------------- next part -------------- An HTML attachment was scrubbed... URL: From frew at ucsb.edu Wed Nov 9 08:56:10 2022 From: frew at ucsb.edu (James Frew) Date: Tue, 8 Nov 2022 14:56:10 -0800 Subject: [TUHS] early Unix papers, from Jim Joyce In-Reply-To: <202211080630.2A86Ugc6004710@freefriends.org> References: <20221102060730.A114A18C08A@mercury.lcs.mit.edu> <74b464ac-2799-badd-9eae-a65acbe08bd7@spamtrap.tnetconsulting.net> <86F17F7B-4775-4B15-BC83-0E7FEC974786@cfcl.com> <332950bf-f61c-0c76-63fa-caa33911ced3@spamtrap.tnetconsulting.net> <18Dhvwn9Aec6LXGA5dkWkgVdxkprEOxlu7by1jOzuRHRz4Dd6095utKlbod1TRPI8R25Z06CXqkQO3ID9o6p4Cef7NvjI90-nrJsdH7ngy0=@protonmail.com> <202211080630.2A86Ugc6004710@freefriends.org> Message-ID: <903541bf-7136-6b4a-e144-9281f04a560c@ucsb.edu> On 2022-11-07 22:30, arnold at skeeve.com wrote: >> A Walk Through AWK >> - Somewhere between the original AWK paper and the AWK book? > I missed this in the original list. I'd love to have a copy of it! doi.org/10.1145/988193.988201 Enjoy, /Frew -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.bowling at kev009.com Wed Nov 9 12:02:25 2022 From: kevin.bowling at kev009.com (Kevin Bowling) Date: Tue, 8 Nov 2022 19:02:25 -0700 Subject: [TUHS] Keynote Language - Tim Thompson Message-ID: Does anyone know if this made it outside the labs? https://www.usenix.org/legacy/publications/compsystems/1990/spr_thompson.pdf I have a rack of outboard synths and samplers, it would be entertaining to run them with an awk-analogue. From fjarlq at gmail.com Wed Nov 9 17:46:44 2022 From: fjarlq at gmail.com (Matt Day) Date: Wed, 9 Nov 2022 00:46:44 -0700 Subject: [TUHS] Keynote Language - Tim Thompson In-Reply-To: References: Message-ID: Yes, it became KeyKit: https://github.com/nosuchtim/keykit Tim recorded a demo video of Keynote in 1994: https://www.youtube.com/watch?v=-c-O57J9W-E His website: https://timthompson.com/tjt/ On Tue, Nov 8, 2022 at 7:03 PM Kevin Bowling wrote: > Does anyone know if this made it outside the labs? > > https://www.usenix.org/legacy/publications/compsystems/1990/spr_thompson.pdf > > I have a rack of outboard synths and samplers, it would be > entertaining to run them with an awk-analogue. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From crossd at gmail.com Wed Nov 9 18:41:24 2022 From: crossd at gmail.com (Dan Cross) Date: Wed, 9 Nov 2022 03:41:24 -0500 Subject: [TUHS] LOC [was Re: Re: Re.: Princeton's "Unix: An Oral History": who was in the team in "The Attic"? In-Reply-To: References: <992562BA-E21F-4542-A50B-6CFE8F7ACE86@planet.nl> <20221011134842.GA11780@mcvoy.com> <20221011195447.GI11780@mcvoy.com> <8583490b-c7cc-4633-b506-2f16335fd3e2@home.arpa> <20221011201025.GJ11780@mcvoy.com> <513e8a46-bd31-420a-bfdf-b59451f89c8d@home.arpa> <0db171e4-7efe-8c00-bb30-a6f914cf9911@technologists.com> Message-ID: On Tue, Nov 8, 2022, 1:57 PM Marc Donner wrote: > My buds in the SRE community confirm that Twitter laid off the entire SRE > team, since of course they didn't write enough code. Good luck with > keeping the system up. > It's ok. I'm sure users can just fax problem reports to Elon. To tie this back to TUHS a little bit...when did being a "sysadmin" become a thing unto itself? And is it just me, or has that largely been superceded by SRE (which I think of as what one used to, perhaps, call a "system programmer") and DevOps, which feels like a more traditional Unix-y kind of thing? - Dan C. ===== > nygeek.net > mindthegapdialogs.com/home > > > On Mon, Nov 7, 2022 at 12:52 PM Warner Losh wrote: > >> >> >> On Tue, Oct 11, 2022 at 2:34 PM Charles H Sauer (he/him) < >> sauer at technologists.com> wrote: >> >>> On 10/11/2022 3:14 PM, Michael Kjörling wrote: >>> > On 11 Oct 2022 13:10 -0700, from lm at mcvoy.com (Larry McVoy): >>> >>> Isn't it relatively well established, though, that IBM culture at >>> >>> least for a very long time put heavy emphasis on counting lines of >>> >>> source code, and that more SLOC was considered to be better? >>> >> >>> >> That's just stupid. >>> > >>> > You're getting no argument from me there. >>> > >>> >>> It was likely true that some parts of IBM put heavy emphasis on LOC, but >>> as Marc points out, that wasn't true in Research. I don't remember heavy >>> LOC emphasis in AIX groups, and I suspect even in Boca (OS/2) there was >>> not "heavy" emphasis. >>> >> >> Speaking of "just stupid" >> >> Word on the street is that Elon Musk stack ranked the engineers by lines >> of code >> over the last year (source: https://ma.nu/blog/bye-twitter) and layed >> off the bottom >> performers in terms of LoC... >> >> Not 100% sure this is legit, since some tweets about it have been deleted. >> >> Warners >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnold at skeeve.com Wed Nov 9 18:49:21 2022 From: arnold at skeeve.com (arnold at skeeve.com) Date: Wed, 09 Nov 2022 01:49:21 -0700 Subject: [TUHS] LOC [was Re: Re: Re.: Princeton's "Unix: An Oral History": who was in the team in "The Attic"? In-Reply-To: References: <992562BA-E21F-4542-A50B-6CFE8F7ACE86@planet.nl> <20221011134842.GA11780@mcvoy.com> <20221011195447.GI11780@mcvoy.com> <8583490b-c7cc-4633-b506-2f16335fd3e2@home.arpa> <20221011201025.GJ11780@mcvoy.com> <513e8a46-bd31-420a-bfdf-b59451f89c8d@home.arpa> <0db171e4-7efe-8c00-bb30-a6f914cf9911@technologists.com> Message-ID: <202211090849.2A98nLRe006143@freefriends.org> Dan Cross wrote: > To tie this back to TUHS a little bit...when did being a "sysadmin" become > a thing unto itself? And is it just me, or has that largely been superceded > by SRE (which I think of as what one used to, perhaps, call a "system > programmer") and DevOps, which feels like a more traditional Unix-y kind of > thing? > > - Dan C. Sys admin was a thing in the mid-80s already; I worked as one at the Emory U Computing Center for several years, ~ 1985 - 1990. Around then USENIX started the LISA (Large Installation System Administratin) workshops. Clem can undoubtedly tell us exactly when. And yes, SRE + dev ops seem to have displaced that, with SRE focusing more on keeping the bazillions of systems up and running, and DevOps on things like build and CI/CD systems. Personally, I'm glad to have gained the sys admin experience, but I don't want to do it for a living; it's much more fun building product and letting someone else have the headaches. :-) Arnold From sjenkin at canb.auug.org.au Wed Nov 9 19:01:25 2022 From: sjenkin at canb.auug.org.au (steve jenkin) Date: Wed, 9 Nov 2022 20:01:25 +1100 Subject: [TUHS] LOC [was Re: Re: Re.: Princeton's "Unix: An Oral History": who was in the team in "The Attic"? In-Reply-To: References: <992562BA-E21F-4542-A50B-6CFE8F7ACE86@planet.nl> <20221011134842.GA11780@mcvoy.com> <20221011195447.GI11780@mcvoy.com> <8583490b-c7cc-4633-b506-2f16335fd3e2@home.arpa> <20221011201025.GJ11780@mcvoy.com> <513e8a46-bd31-420a-bfdf-b59451f89c8d@home.arpa> <0db171e4-7efe-8c00-bb30-a6f914cf9911@technologists.com> Message-ID: <29942374-F162-43EE-9F65-D51C79B4D7B4@canb.auug.org.au> > On 9 Nov 2022, at 19:41, Dan Cross wrote: > > To tie this back to TUHS a little bit...when did being a "sysadmin" become a thing unto itself? And is it just me, or has that largely been superceded by SRE (which I think of as what one used to, perhaps, call a "system programmer") and DevOps, which feels like a more traditional Unix-y kind of thing? > > - Dan C. In The Beginning, We were All Programmers… Machines were smaller, programs simpler and we were closer to the hardware. Literally, like the “Unix Room”, in the Attic at Bell Labs. Admin & Operations weren’t too onerous and “Maintenance” was done by the people doing the kernel & systems software, at a guess. And maybe hardware was fixed by the Vendor, or super-programmers did the plug and play themselves. As sites got bigger, work became multi-person project ’teams’ and admin problems got tricker, while ‘certain people’ did the work. When Unix became properly commercial - multiple vendors, big manuals, support contracts, and a plethora of Unix variants - some Bright People created “Unix Training” courses, in many topiocs. Somewhere around this time, courses and job titles for “System Admin” appeared. Sadly, all this happened without any distinctions in capability & ‘levels’, or actual problem solving testing (cf CISCO’s CCIE: 2 days of testing, 1st day quizzes on a PC, 2nd day is by invitation. Lab session: “fix the broken network in the allotted time”) SAGE - System Admin Guild, part of USENIX - put together a bunch of small books on (Unix) System Admin Topics and tried to guide the development of the field. After 10 years, I was out of the loop and hadn’t seen anything positive in the workplace. SRE roles & as a discipline has developed, alongside DevOps, into managing & fault finding in large clusters of physical and virtual machines. Never done it myself, but it’d seem the potential for screw-ups is now infinite and unlimited in time :) -- Steve Jenkin, IT Systems and Design 0412 786 915 (+61 412 786 915) PO Box 38, Kippax ACT 2615, AUSTRALIA mailto:sjenkin at canb.auug.org.au http://members.tip.net.au/~sjenkin From brad at anduin.eldar.org Wed Nov 9 20:55:42 2022 From: brad at anduin.eldar.org (Brad Spencer) Date: Wed, 09 Nov 2022 05:55:42 -0500 Subject: [TUHS] LOC [was Re: Re: Re.: Princeton's "Unix: An Oral History": who was in the team in "The Attic"? In-Reply-To: <29942374-F162-43EE-9F65-D51C79B4D7B4@canb.auug.org.au> (message from steve jenkin on Wed, 9 Nov 2022 20:01:25 +1100) Message-ID: steve jenkin writes: [snip] > SRE roles & as a discipline has developed, alongside DevOps, into managing & fault finding in large clusters of physical and virtual machines. > > Never done it myself, but it’d seem the potential for screw-ups is now infinite and unlimited in time :) My final $DAYJOB was more DevOps / SRE than system admin which I had been doing for a long time. And, Very Much Yes, the "potential for screw-ups" is very much infinite. It seems like that there are a lot of people messing in areas that they are ill prepared to deal with and tend to do it poorly at times. Very often they will invent structure that is just a reinvention of something that already exists because they lack the background to know what was really available. > -- > Steve Jenkin, IT Systems and Design > 0412 786 915 (+61 412 786 915) > PO Box 38, Kippax ACT 2615, AUSTRALIA > > mailto:sjenkin at canb.auug.org.au http://members.tip.net.au/~sjenkin -- Brad Spencer - brad at anduin.eldar.org - KC8VKS - http://anduin.eldar.org From stu at remphrey.net Wed Nov 9 21:56:39 2022 From: stu at remphrey.net (Stuart Remphrey) Date: Wed, 9 Nov 2022 19:56:39 +0800 Subject: [TUHS] LOC [was Re: Re: Re.: Princeton's "Unix: An Oral History": who was in the team in "The Attic"? In-Reply-To: <29942374-F162-43EE-9F65-D51C79B4D7B4@canb.auug.org.au> References: <992562BA-E21F-4542-A50B-6CFE8F7ACE86@planet.nl> <20221011134842.GA11780@mcvoy.com> <20221011195447.GI11780@mcvoy.com> <8583490b-c7cc-4633-b506-2f16335fd3e2@home.arpa> <20221011201025.GJ11780@mcvoy.com> <513e8a46-bd31-420a-bfdf-b59451f89c8d@home.arpa> <0db171e4-7efe-8c00-bb30-a6f914cf9911@technologists.com> <29942374-F162-43EE-9F65-D51C79B4D7B4@canb.auug.org.au> Message-ID: > Never done it myself, but it’d seem the potential for screw-ups is now infinite and unlimited in time :) Indeed! USENIX SREcon generally releases presentations a short while after each conference. Some interesting experiences there... https://www.usenix.org/conferences/byname/925 https://www.usenix.org/srecon -- Stuart. On Wed, 9 Nov 2022 at 17:03, steve jenkin wrote: > > > On 9 Nov 2022, at 19:41, Dan Cross wrote: > > > > To tie this back to TUHS a little bit...when did being a "sysadmin" > become a thing unto itself? And is it just me, or has that largely been > superceded by SRE (which I think of as what one used to, perhaps, call a > "system programmer") and DevOps, which feels like a more traditional Unix-y > kind of thing? > > > > - Dan C. > > In The Beginning, We were All Programmers… > > Machines were smaller, programs simpler and we were closer to the hardware. > Literally, like the “Unix Room”, in the Attic at Bell Labs. > > Admin & Operations weren’t too onerous and “Maintenance” was done by the > people doing the kernel & systems software, at a guess. > And maybe hardware was fixed by the Vendor, or super-programmers did the > plug and play themselves. > > As sites got bigger, work became multi-person project ’teams’ and admin > problems got tricker, while ‘certain people’ did the work. > > When Unix became properly commercial - multiple vendors, big manuals, > support contracts, and a plethora of Unix variants - some Bright People > created “Unix Training” courses, in many topiocs. > > Somewhere around this time, courses and job titles for “System Admin” > appeared. > > Sadly, all this happened without any distinctions in capability & > ‘levels’, or actual problem solving testing (cf CISCO’s CCIE: 2 days of > testing, 1st day quizzes on a PC, 2nd day is by invitation. Lab session: > “fix the broken network in the allotted time”) > > SAGE - System Admin Guild, part of USENIX - put together a bunch of small > books on (Unix) System Admin Topics and tried to guide the development of > the field. > After 10 years, I was out of the loop and hadn’t seen anything positive in > the workplace. > > SRE roles & as a discipline has developed, alongside DevOps, into managing > & fault finding in large clusters of physical and virtual machines. > > Never done it myself, but it’d seem the potential for screw-ups is now > infinite and unlimited in time :) > > -- > Steve Jenkin, IT Systems and Design > 0412 786 915 (+61 412 786 915) > PO Box 38, Kippax ACT 2615, AUSTRALIA > > mailto:sjenkin at canb.auug.org.au http://members.tip.net.au/~sjenkin > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Thu Nov 10 06:17:23 2022 From: dave at horsfall.org (Dave Horsfall) Date: Thu, 10 Nov 2022 07:17:23 +1100 (EST) Subject: [TUHS] LOC [was Re: Re: Re.: Princeton's "Unix: An Oral History": who was in the team in "The Attic"? In-Reply-To: <202211090849.2A98nLRe006143@freefriends.org> References: <992562BA-E21F-4542-A50B-6CFE8F7ACE86@planet.nl> <20221011134842.GA11780@mcvoy.com> <20221011195447.GI11780@mcvoy.com> <8583490b-c7cc-4633-b506-2f16335fd3e2@home.arpa> <20221011201025.GJ11780@mcvoy.com> <513e8a46-bd31-420a-bfdf-b59451f89c8d@home.arpa> <0db171e4-7efe-8c00-bb30-a6f914cf9911@technologists.com> <202211090849.2A98nLRe006143@freefriends.org> Message-ID: On Wed, 9 Nov 2022, arnold at skeeve.com wrote: > Sys admin was a thing in the mid-80s already; I worked as one at the > Emory U Computing Center for several years, ~ 1985 - 1990. Around then > USENIX started the LISA (Large Installation System Administratin) > workshops. Clem can undoubtedly tell us exactly when. It was a thing in the 70s, when I was maintaining Edition 6 on a lot of 11/40s (and a few 11/23s etc) for UNSW; it's all in AUUGN. -- Dave From sjenkin at canb.auug.org.au Thu Nov 10 08:01:42 2022 From: sjenkin at canb.auug.org.au (steve jenkin) Date: Thu, 10 Nov 2022 09:01:42 +1100 Subject: [TUHS] [OT?] 1993 'Sourceware' paper anniversary. What was right & any surprises? Message-ID: I’ve only recently stumbled across this paper. It gives the answer to one question I’ve had: Why did Linux become more popular than everything that came before it? There were surprises. The “Dot Boom” then “Dot Bust” along with Y2K. Microsoft developed an architecture, Active Directory, designed to support Enterprise scale deployments. Everything Good in A.D. is Old (LDAP, Kerberos, DNS) everything badly done is New (replicated DB’s & ???). Other surprises is the rise of “Internet Scale” datacentres, Social Media and Smartphones & Tablets. All of which are dominated by Linux or Unix derived solutions. And Virtual Machines on Intel. IA-64 was in the far future :( And ARM CPU’s made a big comeback. ========== The Sourceware Operating System Proposal 9 November 1993 Revision: 1.8 ========== -- Steve Jenkin, IT Systems and Design 0412 786 915 (+61 412 786 915) PO Box 38, Kippax ACT 2615, AUSTRALIA mailto:sjenkin at canb.auug.org.au http://members.tip.net.au/~sjenkin From lm at mcvoy.com Thu Nov 10 08:16:48 2022 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 9 Nov 2022 14:16:48 -0800 Subject: [TUHS] [OT?] 1993 'Sourceware' paper anniversary. What was right & any surprises? In-Reply-To: References: Message-ID: <20221109221648.GS6203@mcvoy.com> On Thu, Nov 10, 2022 at 09:01:42AM +1100, steve jenkin wrote: > I???ve only recently stumbled across this paper. > > It gives the answer to one question I???ve had: > > Why did Linux become more popular than everything that came before it? Yeah, that was a difficult time. My boss, Ken Okin (SVP of all server hardware) didn't like the switch from SunOS to SVR4 any more than I did. He paid me to go argue with the execs for 6 months. That paper was the result. It obviously went nowhere and Linux won. Big surprise. The one thing I learned in that 6 months was respect for the execs. As an engineer, I had the luxury of taking the time to solve a problem and know that I solved it correctly. The execs didn't have that. They had to make decisions essentially with their gut, they couldn't afford the time to figure out the right answer, they had to come up with the right answer on the fly. I don't think I could do that. From clemc at ccc.com Thu Nov 10 08:24:05 2022 From: clemc at ccc.com (Clem Cole) Date: Wed, 9 Nov 2022 17:24:05 -0500 Subject: [TUHS] [OT?] 1993 'Sourceware' paper anniversary. What was right & any surprises? In-Reply-To: <20221109221648.GS6203@mcvoy.com> References: <20221109221648.GS6203@mcvoy.com> Message-ID: On Wed, Nov 9, 2022 at 5:16 PM Larry McVoy wrote: > Yeah, that was a difficult time. > Amen bro ... Corporate pride -- but you were right. In the end, it comes down to: Simple Economics matters more the Sophisticated Engineering but corporate pride wanted to believe my cool engineering is going to crush the competition. ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From joseph at josephholsten.com Thu Nov 10 08:51:53 2022 From: joseph at josephholsten.com (Joseph Holsten) Date: Wed, 09 Nov 2022 14:51:53 -0800 Subject: [TUHS] [OT?] 1993 'Sourceware' paper anniversary. What was right & any surprises? In-Reply-To: <20221109221648.GS6203@mcvoy.com> References: <20221109221648.GS6203@mcvoy.com> Message-ID: <314617d9-2e2b-4f88-bce3-ec82e4fb378e@app.fastmail.com> On Wed, Nov 9, 2022, at 14:16, Larry McVoy wrote: > On Thu, Nov 10, 2022 at 09:01:42AM +1100, steve jenkin wrote: >> I???ve only recently stumbled across this paper. >> >> It gives the answer to one question I???ve had: >> >> Why did Linux become more popular than everything that came before it? > > Yeah, that was a difficult time. My boss, Ken Okin (SVP of all server > hardware) didn't like the switch from SunOS to SVR4 any more than I did. > He paid me to go argue with the execs for 6 months. That paper was > the result. > > It obviously went nowhere and Linux won. Big surprise. > > The one thing I learned in that 6 months was respect for the execs. > As an engineer, I had the luxury of taking the time to solve a problem and > know that I solved it correctly. The execs didn't have that. They had > to make decisions essentially with their gut, they couldn't afford the > time to figure out the right answer, they had to come up with the right > answer on the fly. I don't think I could do that. It’s painful to look at where (Open)Solaris was when Oracle acquired it and where it is now. SMF, Zones, ZFS, dtrace, mdb. Oracle Cloud doesn’t use Solaris for anything. I can’t recall hearing anyone using dtrace or ZFS around the place. Meanwhile, illumos derivs have actually done interesting things. Not that NexenStor or SmartOS have made a big dent, but at least they’ve had more recent ideas to copy. -- Joseph Holsten http://josephholsten.com mailto:joseph at josephholsten.com tel:+1-360-927-7234 From tuhs at tuhs.org Thu Nov 10 10:47:37 2022 From: tuhs at tuhs.org (segaloco via TUHS) Date: Thu, 10 Nov 2022 00:47:37 +0000 Subject: [TUHS] [OT?] 1993 'Sourceware' paper anniversary. What was right & any surprises? In-Reply-To: <314617d9-2e2b-4f88-bce3-ec82e4fb378e@app.fastmail.com> References: <20221109221648.GS6203@mcvoy.com> <314617d9-2e2b-4f88-bce3-ec82e4fb378e@app.fastmail.com> Message-ID: What I find incredibly interesting any time the concept of fragmentation comes up is how did several versions of UNIX with slightly differing interfaces create such a headache for UNIX vendors and users in the day, but now we've got a Linux/BSD landscape out there with still pretty significant differences between distributions and UNIX's progeny seem to be doing just fine. Were users looking for different things from their computers in the 90s vs today? Have folks just gotten more used to variability in computing environments and just accept it as part of the plan? What comes to mind for me is the different init systems, desktop environments, networking tools, user management tools, and basically that anything that isn't lore in POSIX seems to be up in the air these days. However, you go back to when SVR4 derivatives were king, they all had the same init, the same useradd, the same /etc/passwd, the same ifconfig. Maybe some of the snazzier new features were pretty variable, but the most basic stuff like starting your system, creating a user, seeing if you were connected to a network, essential administrative functions, were relatively consistent. Nowadays I have to wonder if my init system is runlevel based or some systemd monstrosity. I have to question whether I can rely on useradd or some other tool being present or if I should forgo it all and just edit the /etc files directly. Heck, I couldn't say which but I seem to recall a distro I played around with in the past year where this actually didn't work, I had to research whatever arcane user management tools they shipped with that one because whatever they chose broke with convention so much. I have to pray it has ifconfig or else go look up the docs for iproute2 and iw because nobody can make up their mind on what to replace ifconfig with, just that it has to go and replacing it haphazardly and non-universally is better than fixing/modernizing it. Not looking to start some great debate over which of these components is ideal of course, just remarking at the fact that in the early 90s, if you were on a contemporary UNIX system, you'd probably have no trouble modifying system init, adding users, networks, etc., but today I sit down at an unknown Linux machine and I have no confidence that the particular flavor of system administration that I'm used to will be even remotely represented in the subset of tools that particular distro ships. Luckily, it's free, so perhaps that is what has made the difference, folks are more willing to deal with variability when they aren't paying for what should be a consistent experience, but regardless, the fragmentation in Linux world today feels like it is much more severe than UNIX was in the past, but that's also looking through a lens upon a time I certainly wasn't cognizant of this stuff in. Anywho, that was definitely an informative read, thanks for the share. As someone who is constantly trying to dial in my own personal Linux distro, the questions of standardization and uniformity feature in my mind often. - Matt G. ------- Original Message ------- On Wednesday, November 9th, 2022 at 2:51 PM, Joseph Holsten wrote: > On Wed, Nov 9, 2022, at 14:16, Larry McVoy wrote: > > > On Thu, Nov 10, 2022 at 09:01:42AM +1100, steve jenkin wrote: > > > > > I???ve only recently stumbled across this paper. > > > > > > It gives the answer to one question I???ve had: > > > > > > Why did Linux become more popular than everything that came before it? > > > > Yeah, that was a difficult time. My boss, Ken Okin (SVP of all server > > hardware) didn't like the switch from SunOS to SVR4 any more than I did. > > He paid me to go argue with the execs for 6 months. That paper was > > the result. > > > > It obviously went nowhere and Linux won. Big surprise. > > > > The one thing I learned in that 6 months was respect for the execs. > > As an engineer, I had the luxury of taking the time to solve a problem and > > know that I solved it correctly. The execs didn't have that. They had > > to make decisions essentially with their gut, they couldn't afford the > > time to figure out the right answer, they had to come up with the right > > answer on the fly. I don't think I could do that. > > > It’s painful to look at where (Open)Solaris was when Oracle acquired it and where it is now. SMF, Zones, ZFS, dtrace, mdb. Oracle Cloud doesn’t use Solaris for anything. I can’t recall hearing anyone using dtrace or ZFS around the place. > > Meanwhile, illumos derivs have actually done interesting things. Not that NexenStor or SmartOS have made a big dent, but at least they’ve had more recent ideas to copy. > > -- > Joseph Holsten > http://josephholsten.com > mailto:joseph at josephholsten.com > tel:+1-360-927-7234 From joseph at josephholsten.com Thu Nov 10 10:54:02 2022 From: joseph at josephholsten.com (Joseph Holsten) Date: Wed, 09 Nov 2022 16:54:02 -0800 Subject: [TUHS] [OT?] 1993 'Sourceware' paper anniversary. What was right & any surprises? In-Reply-To: References: <20221109221648.GS6203@mcvoy.com> <314617d9-2e2b-4f88-bce3-ec82e4fb378e@app.fastmail.com> Message-ID: <824c5873-bde9-4cf7-b33a-0f7e352e786d@app.fastmail.com> On Wed, Nov 9, 2022, at 16:47, segaloco wrote: > Nowadays I have to wonder if my init system is runlevel based or some > systemd monstrosity. Ah, the good old days when we just got annoyed at sysvinit vs bsdinit. -- Joseph Holsten http://josephholsten.com mailto:joseph at josephholsten.com tel:+1-360-927-7234 From davida at pobox.com Thu Nov 10 11:28:49 2022 From: davida at pobox.com (David Arnold) Date: Thu, 10 Nov 2022 12:28:49 +1100 Subject: [TUHS] [OT?] 1993 'Sourceware' paper anniversary. What was right & any surprises? In-Reply-To: References: <20221109221648.GS6203@mcvoy.com> <314617d9-2e2b-4f88-bce3-ec82e4fb378e@app.fastmail.com> Message-ID: > On 10 Nov 2022, at 11:47, segaloco via TUHS wrote: > > What I find incredibly interesting any time the concept of fragmentation comes up is how did several versions of UNIX with slightly differing interfaces create such a headache for UNIX vendors and users in the day, but now we've got a Linux/BSD landscape out there with still pretty significant differences between distributions and UNIX's progeny seem to be doing just fine. > > Were users looking for different things from their computers in the 90s vs today? Have folks just gotten more used to variability in computing environments and just accept it as part of the plan? Two things, I think: a) Today most identifiably Unix software is “sourceware”, and so the differences between Linuxes, *BSD, and macOS are fairly easily taken care of (eg. with autotools). b) A lot of Unix software is now distributed (more or less) by the OS vendor. Packaging has hidden the portability problem from the end user. > What comes to mind for me is the different init systems, desktop environments, networking tools, user management tools, and basically that anything that isn't lore in POSIX seems to be up in the air these days. However, you go back to when SVR4 derivatives were king, they all had the same init, the same useradd, the same /etc/passwd, the same ifconfig. Maybe some of the snazzier new features were pretty variable, but the most basic stuff like starting your system, creating a user, seeing if you were connected to a network, essential administrative functions, were relatively consistent. > > Nowadays I have to wonder if my init system is runlevel based or some systemd monstrosity. I have to question whether I can rely on useradd or some other tool being present or if I should forgo it all and just edit the /etc files directly. Heck, I couldn't say which but I seem to recall a distro I played around with in the past year where this actually didn't work, I had to research whatever arcane user management tools they shipped with that one because whatever they chose broke with convention so much. I have to pray it has ifconfig or else go look up the docs for iproute2 and iw because nobody can make up their mind on what to replace ifconfig with, just that it has to go and replacing it haphazardly and non-universally is better than fixing/modernizing it. > > Not looking to start some great debate over which of these components is ideal of course, just remarking at the fact that in the early 90s, if you were on a contemporary UNIX system, you'd probably have no trouble modifying system init, adding users, networks, etc., but today I sit down at an unknown Linux machine and I have no confidence that the particular flavor of system administration that I'm used to will be even remotely represented in the subset of tools that particular distro ships. Luckily, it's free, so perhaps that is what has made the difference, folks are more willing to deal with variability when they aren't paying for what should be a consistent experience, but regardless, the fragmentation in Linux world today feels like it is much more severe than UNIX was in the past, but that's also looking through a lens upon a time I certainly wasn't cognizant of this stuff in. iOS and Android are the most popular end-user Unix systems. None of these concerns matter there — they’ve got two completely incompatible layered APIs that hide the fact they’re Unix from applications and users. Even if you restrict the discussion to non-mobile systems, macOS and ChromeOS probably top the list for end-user systems. Again, none of these concerns matter. I mention this to make the point that “Unix” is not what it once was, both in technical terms, and in commercial success. d From lm at mcvoy.com Thu Nov 10 11:42:35 2022 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 9 Nov 2022 17:42:35 -0800 Subject: [TUHS] [OT?] 1993 'Sourceware' paper anniversary. What was right & any surprises? In-Reply-To: References: <20221109221648.GS6203@mcvoy.com> <314617d9-2e2b-4f88-bce3-ec82e4fb378e@app.fastmail.com> Message-ID: <20221110014235.GE31250@mcvoy.com> On Thu, Nov 10, 2022 at 12:47:37AM +0000, segaloco via TUHS wrote: > What comes to mind for me is the different init systems, desktop > environments, networking tools, user management tools, and basically that > anything that isn't lore in POSIX seems to be up in the air these days. > However, you go back to when SVR4 derivatives were king, they all had the > same init, the same useradd, the same /etc/passwd, the same ifconfig. > Maybe some of the snazzier new features were pretty variable, but the > most basic stuff like starting your system, creating a user, seeing if > you were connected to a network, essential administrative functions, > were relatively consistent. This is sooooo not true. I was supporting BitKeeper on all Unix variations as well as MacOS and Windows from about 2000 to 2018ish. At the very least you had BSD based systems and Sys5 based systems but the Sys5 systems had all diverged. AIX had smit for admin, other systems would let you edit the /etc files but they were in different locations. ifconfig was most definitely not compatible across all the systems, nor was ps. There were tons and tons of differences. We ended up pulling in NetBSDs libc so we at least had one libc (we didn't use the native libc, yep, you read that right, even that was incompatible). Even /etc/passwd wasn't consist, some places had /etc/shadow that had the passwords (I think, it's all getting blurry), and I think there was one, probably AIX, that had /etc/shadow but not in /etc/shadow. The best way I can explain all of this is a lack of a dictator over all the versions. You need someone who is pushing back on changes and is making everything consistent. That's hard to do within a single organization and impossible over multiple organizations. POSIX tried but it wasn't enough. It helped a little. If it had worked, we wouldn't have needed to ship our own libc. From kevin.bowling at kev009.com Thu Nov 10 14:00:23 2022 From: kevin.bowling at kev009.com (Kevin Bowling) Date: Wed, 9 Nov 2022 21:00:23 -0700 Subject: [TUHS] Keynote Language - Tim Thompson In-Reply-To: References: Message-ID: On Wed, Nov 9, 2022 at 12:47 AM Matt Day wrote: > Yes, it became KeyKit: https://github.com/nosuchtim/keykit > > Tim recorded a demo video of Keynote in 1994: > https://www.youtube.com/watch?v=-c-O57J9W-E > > His website: https://timthompson.com/tjt/ > Brilliant, thank you! > On Tue, Nov 8, 2022 at 7:03 PM Kevin Bowling > wrote: > >> Does anyone know if this made it outside the labs? >> >> https://www.usenix.org/legacy/publications/compsystems/1990/spr_thompson.pdf >> >> I have a rack of outboard synths and samplers, it would be >> entertaining to run them with an awk-analogue. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tytso at mit.edu Thu Nov 10 16:14:35 2022 From: tytso at mit.edu (Theodore Ts'o) Date: Thu, 10 Nov 2022 01:14:35 -0500 Subject: [TUHS] [OT?] 1993 'Sourceware' paper anniversary. What was right & any surprises? In-Reply-To: References: <20221109221648.GS6203@mcvoy.com> <314617d9-2e2b-4f88-bce3-ec82e4fb378e@app.fastmail.com> Message-ID: On Thu, Nov 10, 2022 at 12:28:49PM +1100, David Arnold wrote: > > On 10 Nov 2022, at 11:47, segaloco via TUHS wrote: > > > > What I find incredibly interesting any time the concept of > > fragmentation comes up is how did several versions of UNIX with > > slightly differing interfaces create such a headache for UNIX > > vendors and users in the day, but now we've got a Linux/BSD > > landscape out there with still pretty significant differences > > between distributions and UNIX's progeny seem to be doing just > > fine. > > > > Were users looking for different things from their computers in > > the 90s vs today? Have folks just gotten more used to variability > > in computing environments and just accept it as part of the plan? > > Two things, I think: > > a) Today most identifiably Unix software is “sourceware”, and so the > > differences between Linuxes, *BSD, and macOS are fairly easily > > taken care of (eg. with autotools). I'd also argue that (a) the differences between the Linuxes aren't as big some people would make it out to be --- especially compared to the differences between AIX and Solaris and HPUX, and (b) *BSD and macOS has their ports and homebrew systems which also ease any pai that isn't handled by autoconf and friends. > b) A lot of Unix software is now distributed (more or less) by the > OS vendor. Packaging has hidden the portability problem from the > end user. In addition to that, a lot of user-desired functionality is made available via dynamic web "appliances" (e.g., GMail, Concur for those people who need to submit travel reports) as opposed to compiled binaries. I'm talking about pure web applications, of course, not Java web apps. My horror store from when I was working at IBM was that their expense reporting tool was written in Java, but it only worked with the Sun JRE. But if you needed to use to configure an IBM Bladeserver, that only worked with the IBM JRE. So if I needed to submit an expense report, I had to kill the browser, set the environment variables to point at the Sun JRE, and then restart the browser and do the travel report. And then when I needed to go back to messing with a Blade Server chasis, I had to kill the browser, and reset the environment variables, and then restart the browser. Ah, Java.... write once, debug everywhere. :-) - Ted From davida at pobox.com Thu Nov 10 19:12:32 2022 From: davida at pobox.com (David Arnold) Date: Thu, 10 Nov 2022 20:12:32 +1100 Subject: [TUHS] [OT?] 1993 'Sourceware' paper anniversary. What was right & any surprises? In-Reply-To: References: <20221109221648.GS6203@mcvoy.com> <314617d9-2e2b-4f88-bce3-ec82e4fb378e@app.fastmail.com> Message-ID: > On 10 Nov 2022, at 17:14, Theodore Ts'o wrote: > On Thu, Nov 10, 2022 at 12:28:49PM +1100, David Arnold wrote: >> a) Today most identifiably Unix software is “sourceware”, and so the >> differences between Linuxes, *BSD, and macOS are fairly easily >> taken care of (eg. with autotools). > > I'd also argue that (a) the differences between the Linuxes aren't as > big some people would make it out to be --- especially compared to the > differences between AIX and Solaris and HPUX, and (b) *BSD and macOS > has their ports and homebrew systems which also ease any pai that > isn't handled by autoconf and friends. I agree. The differences between desktop/server Linux distributions are largely invisible to application code. THe most obvious exceptions are locations for files. I’ve found it’s basically easier to deal with that dynamically (in the application code), rather than doing an autoconf-based distro switch. Init script vs. units, etc, are minor issues too. Sometimes I’ve found a particular platform doesn’t have a package for eg. the right SSL library, or the right version of something, but that’s fairly rare, and mostly able to be worked around by being conservative in dependency choices. Alpine’s use of musl rather than glibc was a bigger problem, but musl is increasingly glibc compatible. Other libc versions used by embedded platforms, create more problems, but then those applications tend to be fairly narrowly targeted anyway. But all that said … it’s a heap easier than making source code compile across every common Unix in the mid-to-late 90’s. d -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Thu Nov 10 23:27:29 2022 From: tuhs at tuhs.org (Tom Ivar Helbekkmo via TUHS) Date: Thu, 10 Nov 2022 14:27:29 +0100 Subject: [TUHS] [OT?] 1993 'Sourceware' paper anniversary. What was right & any surprises? In-Reply-To: (David Arnold's message of "Thu, 10 Nov 2022 20:12:32 +1100") References: <20221109221648.GS6203@mcvoy.com> <314617d9-2e2b-4f88-bce3-ec82e4fb378e@app.fastmail.com> Message-ID: David Arnold writes: > But all that said … it’s a heap easier than making source code compile > across every common Unix in the mid-to-late 90’s. "Congratulations! You're not running Eunice." :) -tih -- Most people who graduate with CS degrees don't understand the significance of Lisp. Lisp is the most important idea in computer science. --Alan Kay From clemc at ccc.com Fri Nov 11 01:33:13 2022 From: clemc at ccc.com (Clem Cole) Date: Thu, 10 Nov 2022 10:33:13 -0500 Subject: [TUHS] [OT?] 1993 'Sourceware' paper anniversary. What was right & any surprises? In-Reply-To: References: <20221109221648.GS6203@mcvoy.com> <314617d9-2e2b-4f88-bce3-ec82e4fb378e@app.fastmail.com> Message-ID: On Thu, Nov 10, 2022 at 1:14 AM Theodore Ts'o wrote: > I'd also argue that (a) the differences between the Linuxes aren't as big > some people would make it out to be > It's all a matter of degree and what things bite you. This is why we had to develop the cluster checker because Linux is all over the place >>still<< -- one famous ISV had 144 possible differences between 'standard' Linux cluster configurations they needed to test. BTW: that had been a developer during the UNIX wars and pure Fortran on VMS/IBM etc days. I suspect they would claim it was not much better for them. Is it better in some areas? Sure, in another no. It depends if it's something that bites you and you care about. Things like the "systemd wars" did not help which I would contend was not much less glorious that the Unix wars -- just different players. In the end, it's all about who is making the call of what is different/what is changing. I'm too old to get too religious about this. The 'sameness' is because of UNIX not because of Linux. Ken and Dennis's core ideas created an industry and set of systems that are all 'close enough that we all can get work done. In the end, at any given time, one group or any other will have the incentive to have their way lead the market - and the hard part for many of us to accept is that the incentive is most often *economic not technical*. Larry's old paper nailed the basic issue. It was use the core ideas of Ken and Dennis - (call it anything you want) - and make it freely available to remove the economic barriers. This is what Linux exploited, and that is what made it successful. I'm pleased to say, that Larry's 'Sourceware' came about --> today its in the form of Linux. But the ideas (the core IP) is called UNIX. And yes there are specific differences. But in general; they are close enough. ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Sun Nov 13 01:54:16 2022 From: clemc at ccc.com (Clem Cole) Date: Sat, 12 Nov 2022 10:54:16 -0500 Subject: [TUHS] DG UNIX History Message-ID: This recent activity on the simh mailing list WRT to DG Nova and Ecpilse got me wondering. At Locus in the 80s and 90s, we did a lot of work with DG and DG-UX with their later MP-based ports using commercially available microprocessors (which I have reported was a very nicely done system, easy to work on, the locks tended to scale well, e*tc*.). But I am trying to remember if C or UNIX was on a Nova or an Eclipse. This could be my failed memory, given that so many people ported V7 in the late 1970s (the infamous 'NUIX' bug from the Series/1 port probably being my favorite tale). So to the hive mind, did anyone (DG themselves or a University) ever build 16 or 32-bit tools for the DG architectures and do a UNIX port, and if so, does anyone know what became of those efforts? Is this something that needs to be in the TUHS archives also? Clem ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Sun Nov 13 02:09:40 2022 From: lm at mcvoy.com (Larry McVoy) Date: Sat, 12 Nov 2022 08:09:40 -0800 Subject: [TUHS] DG UNIX History In-Reply-To: References: Message-ID: <20221112160940.GI652@mcvoy.com> I dunno. I've heard DG did a pretty much from the ground up rewrite of Unix to make it scale well on SMP machines. I've never seen the source or used DG-UX, so it's all heresay. If anyone has more info than what Clem said, I'm all ears. The reason I'm interested is the original model of disabling interrupts really isn't pleasant on an SMP but people tried to evolve it towards something that scaled. It seems like DG went at it starting over, designing SMP in from the start. Be interesting to understand what they did. Sequent as well. On Sat, Nov 12, 2022 at 10:54:16AM -0500, Clem Cole wrote: > This recent activity on the simh mailing list WRT to DG Nova and > Ecpilse got me wondering. At Locus in the 80s and 90s, we did a lot of > work with DG and DG-UX with their later MP-based ports using commercially > available microprocessors (which I have reported was a very nicely done > system, easy to work on, the locks tended to scale well, e*tc*.). > > But I am trying to remember if C or UNIX was on a Nova or an Eclipse. This > could be my failed memory, given that so many people ported V7 in the late > 1970s (the infamous 'NUIX' bug from the Series/1 port probably being my > favorite tale). So to the hive mind, did anyone (DG themselves or a > University) ever build 16 or 32-bit tools for the DG architectures and do a > UNIX port, and if so, does anyone know what became of those efforts? Is > this something that needs to be in the TUHS archives also? > > Clem > ??? -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From arnold at skeeve.com Sun Nov 13 02:52:05 2022 From: arnold at skeeve.com (arnold at skeeve.com) Date: Sat, 12 Nov 2022 09:52:05 -0700 Subject: [TUHS] DG UNIX History In-Reply-To: References: Message-ID: <202211121652.2ACGq6Pf015000@freefriends.org> I'm pretty sure that DG never ported DG-UX to the Nova. There was a native port to the Eclipse (32 bit). There was also a Eunice-style Unix environment that sat on top of their native OS, whatever it was called. When I was working there, DG gave the Georgia Tech School of Information and Computer Science an Eclipse running their native OS in the early mid-80s. I didn't do much with it, and I suspect that nobody else there did either. I'm bcc-ing Scott Lee, who was the admin for that machine at the time; maybe he remembers more. There was a guy who worked at DG and contributed a lot of the Motorola 88000 code to GCC whose name I don't remember, although I met him at a USENIX. If someone else remembers who this is, maybe he can be tracked down for more info. DG-UX was a pretty generic SVR3 (and later SVR4) system, IIRC. In any case, DG-UX on the Eclipse preceded it on the 88000. I hope this helps, Arnold P.S. For the youngsters here who've never heard of it, I highly recommend Tracy Kidder's "The Soul of a New Machine" about the development of the Eclipse. (https://www.amazon.com/Soul-New-Machine-Tracy-Kidder/dp/0316491977/ref=sr_1_1?keywords=the+soul+of+a+new+machine+by+tracy+kidder&qid=1668271720&sprefix=the+soul+of+a+new%2Caps%2C233&sr=8-1). It was originally written in 1982 - 40 years ago! Clem Cole wrote: > This recent activity on the simh mailing list WRT to DG Nova and > Ecpilse got me wondering. At Locus in the 80s and 90s, we did a lot of > work with DG and DG-UX with their later MP-based ports using commercially > available microprocessors (which I have reported was a very nicely done > system, easy to work on, the locks tended to scale well, e*tc*.). > > But I am trying to remember if C or UNIX was on a Nova or an Eclipse. This > could be my failed memory, given that so many people ported V7 in the late > 1970s (the infamous 'NUIX' bug from the Series/1 port probably being my > favorite tale). So to the hive mind, did anyone (DG themselves or a > University) ever build 16 or 32-bit tools for the DG architectures and do a > UNIX port, and if so, does anyone know what became of those efforts? Is > this something that needs to be in the TUHS archives also? > > Clem > ??? From lm at mcvoy.com Sun Nov 13 03:05:03 2022 From: lm at mcvoy.com (Larry McVoy) Date: Sat, 12 Nov 2022 09:05:03 -0800 Subject: [TUHS] DG UNIX History In-Reply-To: <202211121652.2ACGq6Pf015000@freefriends.org> References: <202211121652.2ACGq6Pf015000@freefriends.org> Message-ID: <20221112170503.GL652@mcvoy.com> On Sat, Nov 12, 2022 at 09:52:05AM -0700, arnold at skeeve.com wrote: > P.S. For the youngsters here who've never heard of it, I highly > recommend Tracy Kidder's "The Soul of a New Machine" about the > development of the Eclipse. (https://www.amazon.com/Soul-New-Machine-Tracy-Kidder/dp/0316491977/ref=sr_1_1?keywords=the+soul+of+a+new+machine+by+tracy+kidder&qid=1668271720&sprefix=the+soul+of+a+new%2Caps%2C233&sr=8-1). > > It was originally written in 1982 - 40 years ago! That's a great read, +1. From miod at online.fr Sun Nov 13 03:09:32 2022 From: miod at online.fr (Miod Vallat) Date: Sat, 12 Nov 2022 17:09:32 +0000 Subject: [TUHS] DG UNIX History In-Reply-To: <202211121652.2ACGq6Pf015000@freefriends.org> References: <202211121652.2ACGq6Pf015000@freefriends.org> Message-ID: > There was a guy who worked at DG and contributed a lot of the Motorola > 88000 code to GCC whose name I don't remember, although I met him > at a USENIX. If someone else remembers who this is, maybe he can > be tracked down for more info. I suppose you're referring to Tom Wood here? > P.S. For the youngsters here who've never heard of it, I highly > recommend Tracy Kidder's "The Soul of a New Machine" about the > development of the Eclipse. (https://www.amazon.com/Soul-New-Machine-Tracy-Kidder/dp/0316491977/ref=sr_1_1?keywords=the+soul+of+a+new+machine+by+tracy+kidder&qid=1668271720&sprefix=the+soul+of+a+new%2Caps%2C233&sr=8-1). > > It was originally written in 1982 - 40 years ago! Seconded - definitely a must read; even if technology has evolved a lot since then, management and human factors have not. Miod From david at kdbarto.org Sun Nov 13 03:13:09 2022 From: david at kdbarto.org (David Barto) Date: Sat, 12 Nov 2022 09:13:09 -0800 Subject: [TUHS] DG UNIX History In-Reply-To: <202211121652.2ACGq6Pf015000@freefriends.org> References: <202211121652.2ACGq6Pf015000@freefriends.org> Message-ID: I worked on the DG-UX software porting device drivers to it. It wasn’t a Unix port, it was a complete re-write from the ground up. The interfaces to the drivers was different and the internal locking mechanisms were unique to the OS. I’d never seen anything like it before, or after. David > On Nov 12, 2022, at 8:52 AM, arnold at skeeve.com wrote: > > I'm pretty sure that DG never ported DG-UX to the Nova. There was > a native port to the Eclipse (32 bit). There was also a Eunice-style > Unix environment that sat on top of their native OS, whatever it was > called. > > When I was working there, DG gave the Georgia Tech School of Information > and Computer Science an Eclipse running their native OS in the early > mid-80s. I didn't do much with it, and I suspect that nobody else there > did either. > > I'm bcc-ing Scott Lee, who was the admin for that machine at the time; > maybe he remembers more. > > There was a guy who worked at DG and contributed a lot of the Motorola > 88000 code to GCC whose name I don't remember, although I met him > at a USENIX. If someone else remembers who this is, maybe he can > be tracked down for more info. > > DG-UX was a pretty generic SVR3 (and later SVR4) system, IIRC. > > In any case, DG-UX on the Eclipse preceded it on the 88000. > > I hope this helps, > > Arnold > > P.S. For the youngsters here who've never heard of it, I highly > recommend Tracy Kidder's "The Soul of a New Machine" about the > development of the Eclipse. (https://www.amazon.com/Soul-New-Machine-Tracy-Kidder/dp/0316491977/ref=sr_1_1?keywords=the+soul+of+a+new+machine+by+tracy+kidder&qid=1668271720&sprefix=the+soul+of+a+new%2Caps%2C233&sr=8-1). > > It was originally written in 1982 - 40 years ago! > > Clem Cole wrote: > >> This recent activity on the simh mailing list WRT to DG Nova and >> Ecpilse got me wondering. At Locus in the 80s and 90s, we did a lot of >> work with DG and DG-UX with their later MP-based ports using commercially >> available microprocessors (which I have reported was a very nicely done >> system, easy to work on, the locks tended to scale well, e*tc*.). >> >> But I am trying to remember if C or UNIX was on a Nova or an Eclipse. This >> could be my failed memory, given that so many people ported V7 in the late >> 1970s (the infamous 'NUIX' bug from the Series/1 port probably being my >> favorite tale). So to the hive mind, did anyone (DG themselves or a >> University) ever build 16 or 32-bit tools for the DG architectures and do a >> UNIX port, and if so, does anyone know what became of those efforts? Is >> this something that needs to be in the TUHS archives also? >> >> Clem >> ??? From imp at bsdimp.com Sun Nov 13 03:12:54 2022 From: imp at bsdimp.com (Warner Losh) Date: Sat, 12 Nov 2022 10:12:54 -0700 Subject: [TUHS] DG UNIX History In-Reply-To: References: <202211121652.2ACGq6Pf015000@freefriends.org> Message-ID: On Sat, Nov 12, 2022, 10:10 AM Miod Vallat wrote: > > There was a guy who worked at DG and contributed a lot of the Motorola > > 88000 code to GCC whose name I don't remember, although I met him > > at a USENIX. If someone else remembers who this is, maybe he can > > be tracked down for more info. > > I suppose you're referring to Tom Wood here? > > > P.S. For the youngsters here who've never heard of it, I highly > > recommend Tracy Kidder's "The Soul of a New Machine" about the > > development of the Eclipse. ( > https://www.amazon.com/Soul-New-Machine-Tracy-Kidder/dp/0316491977/ref=sr_1_1?keywords=the+soul+of+a+new+machine+by+tracy+kidder&qid=1668271720&sprefix=the+soul+of+a+new%2Caps%2C233&sr=8-1 > ). > > > > It was originally written in 1982 - 40 years ago! > > Seconded - definitely a must read; even if technology has evolved a lot > since then, management and human factors have not. > Bring them in, burn them out, sweat every hour out of them... call it excellence. Bah Warner > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad at anduin.eldar.org Sun Nov 13 03:37:52 2022 From: brad at anduin.eldar.org (Brad Spencer) Date: Sat, 12 Nov 2022 12:37:52 -0500 Subject: [TUHS] DG UNIX History In-Reply-To: <202211121652.2ACGq6Pf015000@freefriends.org> (arnold@skeeve.com) Message-ID: arnold at skeeve.com writes: > I'm pretty sure that DG never ported DG-UX to the Nova. There was > a native port to the Eclipse (32 bit). There was also a Eunice-style > Unix environment that sat on top of their native OS, whatever it was > called. AOS and then AOS/VS for the Eclipse. In the late 1980s and early 1990s I messed a whole lot with AOS/VS at the university I was at. It was very much Not Unix. Towards the end of my time there, a number of programs that traditionally would be on a Unix system, things like sendmail, ftpd, and etc.. were natively ported to AOS/VS. The ports were probably done as best as they could have been, but they lacked a whole lot of ability if I remember things correctly. After I left, the university acquired a DG of some sort that ran DG-UX (or DGUX). [snip] > > Arnold -- Brad Spencer - brad at anduin.eldar.org - KC8VKS - http://anduin.eldar.org From arnold at skeeve.com Sun Nov 13 03:39:58 2022 From: arnold at skeeve.com (arnold at skeeve.com) Date: Sat, 12 Nov 2022 10:39:58 -0700 Subject: [TUHS] DG UNIX History In-Reply-To: References: <202211121652.2ACGq6Pf015000@freefriends.org> Message-ID: <202211121739.2ACHdww1020587@freefriends.org> Miod Vallat wrote: > > There was a guy who worked at DG and contributed a lot of the Motorola > > 88000 code to GCC whose name I don't remember, although I met him > > at a USENIX. If someone else remembers who this is, maybe he can > > be tracked down for more info. > > I suppose you're referring to Tom Wood here? That doesn't sound right... I wish I could remember. :-( Arnold From clemc at ccc.com Sun Nov 13 04:04:30 2022 From: clemc at ccc.com (Clem Cole) Date: Sat, 12 Nov 2022 13:04:30 -0500 Subject: [TUHS] DG UNIX History In-Reply-To: <202211121652.2ACGq6Pf015000@freefriends.org> References: <202211121652.2ACGq6Pf015000@freefriends.org> Message-ID: On Sat, Nov 12, 2022 at 11:52 AM wrote: > > > DG-UX was a pretty generic SVR3 > User space was generic. But the SVR3/88K kernel was a heavy rewrite. LCC did a lot of work with DG adding stuff too it -- it was very well done by the DG team in NC. The memory and FS was well integrated. Of all the UNIX kernels we did work, it was pretty much the easiest to learn and modify. ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Sun Nov 13 04:36:23 2022 From: lm at mcvoy.com (Larry McVoy) Date: Sat, 12 Nov 2022 10:36:23 -0800 Subject: [TUHS] DG UNIX History In-Reply-To: References: <202211121652.2ACGq6Pf015000@freefriends.org> Message-ID: <20221112183623.GO652@mcvoy.com> On Sat, Nov 12, 2022 at 01:04:30PM -0500, Clem Cole wrote: > On Sat, Nov 12, 2022 at 11:52 AM wrote: > > DG-UX was a pretty generic SVR3 > > > User space was generic. But the SVR3/88K kernel was a heavy rewrite. > LCC did a lot of work with DG adding stuff too it -- it was very well done > by the DG team in NC. The memory and FS was well integrated. So read()/write()/mmap() all shared the same cache like SunOS? In SunOS the only things not in the page cache were directories and inodes. All data pages had one, and only one, place to be (ZFS broke this in Solaris, which has always blown my mind). -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From arnold at skeeve.com Sun Nov 13 04:51:46 2022 From: arnold at skeeve.com (Arnold Robbins) Date: Sat, 12 Nov 2022 20:51:46 +0200 Subject: [TUHS] the rise of discmaster.textfiles.com Message-ID: http://blog.archive.org/2022/10/24/the-rise-of-discmaster/ There seems to be lots of different vendor unix stuff here, as well as many other things. Arnold From dave at horsfall.org Sun Nov 13 05:16:44 2022 From: dave at horsfall.org (Dave Horsfall) Date: Sun, 13 Nov 2022 06:16:44 +1100 (EST) Subject: [TUHS] DG UNIX History In-Reply-To: References: Message-ID: On Sat, 12 Nov 2022, Clem Cole wrote: [ ... ] > (the infamous 'NUIX' bug from the Series/1 port probably being my > favorite tale). That would be the "NUXI" bug (byte-swapped words). > So to the hive mind, did anyone (DG themselves or a University) ever > build 16 or 32-bit tools for the DG architectures and do a UNIX port, > and if so, does anyone know what became of those efforts?  Is this > something that needs to be in the TUHS archives also? I remember Tracey Kidder's "The Soul of a New Machine"... It ran some proprietary system, though. -- Dave From clemc at ccc.com Sun Nov 13 05:31:38 2022 From: clemc at ccc.com (Clem Cole) Date: Sat, 12 Nov 2022 14:31:38 -0500 Subject: [TUHS] DG UNIX History In-Reply-To: References: Message-ID: On Sat, Nov 12, 2022 at 2:16 PM Dave Horsfall wrote: > > > That would be the "NUXI" bug (byte-swapped words). > Yep -- the reversal in my email was typo and then dyslexia on my part. ;-) FYI: I was there when the guy from Cleveland State gave the paper. It was a riot. ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Sun Nov 13 05:36:05 2022 From: clemc at ccc.com (Clem Cole) Date: Sat, 12 Nov 2022 14:36:05 -0500 Subject: [TUHS] DG UNIX History In-Reply-To: <20221112183623.GO652@mcvoy.com> References: <202211121652.2ACGq6Pf015000@freefriends.org> <20221112183623.GO652@mcvoy.com> Message-ID: To be honest, I've forgotten many (most) of the details. But that sounds about right. As I remember it, it was like SunOS. The key point was that the kernel only had one view of the memory system period, no FS buffer cache etc...which was a departure from many of the traditional UNIX implementations. IIRC they did not support BSD's mmap -- but check the SVR3 docs to be sure -- they had the SVR3 user interfaces but none of the BSD ones. They did support the System V shared memory, however. I do seem to remember there was something funny in the driver interfaces, it was just like UNIX only different, and that causes some heartache - but it was fairly straightforward to move a DMA driver like getting a VME Xylogics tape controller to work, but it took a little tweaking. I've forgotten exactly why that was -- it's been a long time ago. Clem ᐧ On Sat, Nov 12, 2022 at 1:36 PM Larry McVoy wrote: > On Sat, Nov 12, 2022 at 01:04:30PM -0500, Clem Cole wrote: > > On Sat, Nov 12, 2022 at 11:52 AM wrote: > > > DG-UX was a pretty generic SVR3 > > > > > User space was generic. But the SVR3/88K kernel was a heavy rewrite. > > LCC did a lot of work with DG adding stuff too it -- it was very well > done > > by the DG team in NC. The memory and FS was well integrated. > > So read()/write()/mmap() all shared the same cache like SunOS? In SunOS > the > only things not in the page cache were directories and inodes. All data > pages had one, and only one, place to be (ZFS broke this in Solaris, > which has always blown my mind). > -- > --- > Larry McVoy Retired to fishing > http://www.mcvoy.com/lm/boat > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Sun Nov 13 06:17:33 2022 From: tuhs at tuhs.org (Grant Taylor via TUHS) Date: Sat, 12 Nov 2022 13:17:33 -0700 Subject: [TUHS] the rise of discmaster.textfiles.com In-Reply-To: References: Message-ID: <256db5fa-dda2-8ab7-1a86-5b84bd52fe70@spamtrap.tnetconsulting.net> On 11/12/22 11:51 AM, Arnold Robbins wrote: > http://blog.archive.org/2022/10/24/the-rise-of-discmaster/ DiscMaster is EXTREMELY interesting. I've been really enjoying it for two to three weeks. -- I think I saw it within it's first week of official release. I'm subscribing to the RSS feed of what's added on a near daily basis. N.B. DiscMaster is indexing disk images found on Internet Archive. DiscMaster is a different type of search engine / gateway to Internet Archive contents. > There seems to be lots of different vendor unix stuff here, as well > as many other things. Yep. There has been a LOT of vendor unix stuff on Internet Archive for a long time. It was just a lot harder to find than it is via DiscMaster's index thereof. I've seen a lot of SGI Irix stuff as of late. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4017 bytes Desc: S/MIME Cryptographic Signature URL: From dave at horsfall.org Sun Nov 13 10:02:05 2022 From: dave at horsfall.org (Dave Horsfall) Date: Sun, 13 Nov 2022 11:02:05 +1100 (EST) Subject: [TUHS] Book: "You Are Not Expected to Understand This" Message-ID: I spotted this when glancing through a book catalogue; well, with a title like that how could I miss it? Subtitled "How 26 Lines of Code Changed the World", edited by Torie Bosch and illustrated by Kelly Chudler (can't say that I've heard of them). Summary: ``Programming is behind so much of life today, and this book draws together a group of distinguished thinkers and technologists to reveal the stories and people behind the computer coding that shapes our world. From how university's [sic] databases were set up to recognise only two genders to the first computer worm and the first pop-up ad, the diverse topics reveal the consequences of historical decisions and their long-lasting, profound implications. Pb $34.99'' Lines of code, eh? :-) Abbey's Bookshop: www.abbeys.com.au Disclaimer: I have no connection with them, but I'll likely buy it. -- Dave From kennethgoodwin56 at gmail.com Sun Nov 13 10:25:07 2022 From: kennethgoodwin56 at gmail.com (Kenneth Goodwin) Date: Sat, 12 Nov 2022 19:25:07 -0500 Subject: [TUHS] Book: "You Are Not Expected to Understand This" In-Reply-To: References: Message-ID: Maybe it is just me, but I don't recognize any of the contributors listed either at the bottom On Sat, Nov 12, 2022, 7:20 PM Dave Horsfall wrote: > I spotted this when glancing through a book catalogue; well, with a title > like that how could I miss it? > > Subtitled "How 26 Lines of Code Changed the World", edited by Torie Bosch > and illustrated by Kelly Chudler (can't say that I've heard of them). > > Summary: > > ``Programming is behind so much of life today, and this book draws together > a group of distinguished thinkers and technologists to reveal the > stories and people behind the computer coding that shapes our > world. From how university's [sic] databases were set up to > recognise only two genders to the first computer worm and the > first pop-up ad, the diverse topics reveal the consequences of > historical decisions and their long-lasting, profound implications. > Pb $34.99'' > > Lines of code, eh? :-) > > Abbey's Bookshop: www.abbeys.com.au > > Disclaimer: I have no connection with them, but I'll likely buy it. > > -- Dave > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stuff at riddermarkfarm.ca Sun Nov 13 11:12:02 2022 From: stuff at riddermarkfarm.ca (Stuff Received) Date: Sat, 12 Nov 2022 20:12:02 -0500 Subject: [TUHS] Book: "You Are Not Expected to Understand This" In-Reply-To: References: Message-ID: On 2022-11-12 19:02, Dave Horsfall wrote: > I spotted this when glancing through a book catalogue; well, with a title > like that how could I miss it? > > Subtitled "How 26 Lines of Code Changed the World", edited by Torie Bosch > and illustrated by Kelly Chudler (can't say that I've heard of them). > > Summary: > > ``Programming is behind so much of life today, and this book draws together > a group of distinguished thinkers and technologists to reveal the > stories and people behind the computer coding that shapes our > world. From how university's [sic] databases were set up to > recognise only two genders to the first computer worm and the > first pop-up ad, the diverse topics reveal the consequences of > historical decisions and their long-lasting, profound implications. > Pb $34.99'' > > Lines of code, eh? :-) > > Abbey's Bookshop: www.abbeys.com.au > > Disclaimer: I have no connection with them, but I'll likely buy it. > > -- Dave Does subscribe to COFF anymore?  I mentioned this a few weeks ago on COFF (https://minnie.tuhs.org/pipermail/coff/2022-October/001315.html) with only one reply. N. From robpike at gmail.com Sun Nov 13 11:12:32 2022 From: robpike at gmail.com (Rob Pike) Date: Sun, 13 Nov 2022 12:12:32 +1100 Subject: [TUHS] Book: "You Are Not Expected to Understand This" In-Reply-To: References: Message-ID: I find it fascinating how, just a few years after the difficulty of stack switching required a commented challenge in the Unix source, we were using setjmp and longjmp to do this with no fuss at all. Once the problem is solved, the solution can simplify dramatically. See https://github.com/plan9foundation/plan9/blob/main/sys/src/9/port/proc.c for instance - almost all of sched is bookkeeping and a comment about locks. The little burst at the bottom, starting around line 163, that does the work is so compact. (setlabel and gotolabel are setjmp and longjmp.) Insight. -rob On Sun, Nov 13, 2022 at 11:26 AM Kenneth Goodwin wrote: > Maybe it is just me, but I don't recognize any of the contributors listed > either at the bottom > > On Sat, Nov 12, 2022, 7:20 PM Dave Horsfall wrote: > >> I spotted this when glancing through a book catalogue; well, with a title >> like that how could I miss it? >> >> Subtitled "How 26 Lines of Code Changed the World", edited by Torie Bosch >> and illustrated by Kelly Chudler (can't say that I've heard of them). >> >> Summary: >> >> ``Programming is behind so much of life today, and this book draws >> together >> a group of distinguished thinkers and technologists to reveal the >> stories and people behind the computer coding that shapes our >> world. From how university's [sic] databases were set up to >> recognise only two genders to the first computer worm and the >> first pop-up ad, the diverse topics reveal the consequences of >> historical decisions and their long-lasting, profound implications. >> Pb $34.99'' >> >> Lines of code, eh? :-) >> >> Abbey's Bookshop: www.abbeys.com.au >> >> Disclaimer: I have no connection with them, but I'll likely buy it. >> >> -- Dave >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Sun Nov 13 11:52:59 2022 From: lm at mcvoy.com (Larry McVoy) Date: Sat, 12 Nov 2022 17:52:59 -0800 Subject: [TUHS] Book: "You Are Not Expected to Understand This" In-Reply-To: References: Message-ID: <20221113015259.GJ9823@mcvoy.com> On Sun, Nov 13, 2022 at 12:12:32PM +1100, Rob Pike wrote: > See https://github.com/plan9foundation/plan9/blob/main/sys/src/9/port/proc.c > for instance - almost all of sched is bookkeeping and a comment about > locks. The little burst at the bottom, starting around line 163, that does > the work is so compact. (setlabel and gotolabel are setjmp and longjmp.) This reminds me of code I did for Udi Manber as a grad (or undergrad) student. He wanted a user space threads library so I wrote one. It's where I learned how to write swtch() where you enter as one thread and exit as another one. 99% of the code was C that did all the stuff you could do in C and then a small amount of assembler that did the flip. I had heard that swtch() was hard but it really isn't that bad. The assembler makes you learn that stuff but you need to know that stuff anyway. I do agree with people who say you aren't a kernel engineer if you haven't written, or at least understood, that code. From lm at mcvoy.com Sun Nov 13 11:56:24 2022 From: lm at mcvoy.com (Larry McVoy) Date: Sat, 12 Nov 2022 17:56:24 -0800 Subject: [TUHS] DG UNIX History In-Reply-To: References: <202211121652.2ACGq6Pf015000@freefriends.org> <20221112183623.GO652@mcvoy.com> Message-ID: <20221113015624.GM9823@mcvoy.com> On Sat, Nov 12, 2022 at 02:36:05PM -0500, Clem Cole wrote: > To be honest, I've forgotten many (most) of the details. But that sounds > about right. As I remember it, it was like SunOS. The key point was that > the kernel only had one view of the memory system period, no FS > buffer cache etc...which was a departure from many of the traditional UNIX > implementations. IIRC they did not support BSD's mmap -- but check the It sounds like they could have supported mmap() easily. I'd love to see this kernel, it sounds to me like it was SunOS with nicely done SMP support. The guy that said he'd never seen anything like it before or since, just makes me want to see it more. I know someone who was friends with one of the kernel guys, haven't talked to her in years but I'll see if I can find anything. From dave at horsfall.org Mon Nov 14 07:58:14 2022 From: dave at horsfall.org (Dave Horsfall) Date: Mon, 14 Nov 2022 08:58:14 +1100 (EST) Subject: [TUHS] Book: "You Are Not Expected to Understand This" In-Reply-To: References: Message-ID: On Sat, 12 Nov 2022, Stuff Received wrote: > Does subscribe to COFF anymore?  I mentioned this a few weeks ago on > COFF (https://minnie.tuhs.org/pipermail/coff/2022-October/001315.html) > with only one reply. Haven't seen anything from COFF for some weeks now; anyway I figured that is was more "historical Unix" than "old geezer" stuff, hence TUHS. -- Dave From arnold at skeeve.com Mon Nov 14 21:44:11 2022 From: arnold at skeeve.com (arnold at skeeve.com) Date: Mon, 14 Nov 2022 04:44:11 -0700 Subject: [TUHS] DG UNIX History Message-ID: <202211141144.2AEBiB1h017576@freefriends.org> This is what Scott Lee, who ran the Eclipse at Georgia Tech recalls. He has given permission for me to forward it, with the caveat that it was long ago and that "memories are malleable". Arnold > Date: Mon, 14 Nov 2022 05:35:51 -0500 > Subject: Re: [TUHS] DG UNIX History > From: scott at thelees.org > To: arnold at skeeve.com > > > I'm pretty sure that DG never ported DG-UX to the Nova. There was > > a native port to the Eclipse (32 bit). There was also a Eunice-style > > Unix environment that sat on top of their native OS, whatever it was > > called. > > Yeh, that was an MV-10000 that we received. As I remember it, we also got > a copy of DG-UX, which was a port of SYS Vr2, not r3 as mentioned. I > think that it may have also had a directory with UCB versions of a bunch > of the utilities ported over so you could run either SysV tools or UCB > tools. > > LeBlanc was going to use it to teach ADA, so I was building some tools to > create/maintain user accounts, but I believe that I left just before they > were actually getting around to that. > > I was also playing with it on the side, when no one else was using it, to > build a small OS on it. I found that it followed a lot of the Nova > behavior, so I figured out how to write code onto a tape and bootstrap it > into the machine. Wrote a tape driver and a console driver and was > working on a disk driver. Targeting putting a small OS on it. > > Wow... I had almost forgotten that it even existed until I saw this. > > Enjoy, > Scott From douglas.mcilroy at dartmouth.edu Tue Nov 15 00:14:28 2022 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Mon, 14 Nov 2022 09:14:28 -0500 Subject: [TUHS] Book: "You Are Not Expected to Understand This" Message-ID: >> To be honest, I've forgotten many (most) of the details. But that sounds >> about right. As I remember it, it was like SunOS. The key point was that >> the kernel only had one view of the memory system period, no FS >> buffer cache etc...which was a departure from many of the traditional UNIX >> implementations. IIRC they did not support BSD's mmap -- but check the > It sounds like they could have supported mmap() easily. I'd love to see > this kernel, it sounds to me like it was SunOS with nicely done SMP > support. The guy that said he'd never seen anything like it before or > since, just makes me want to see it more. "One view of the memory, period." That describes Multics. Doug From clemc at ccc.com Tue Nov 15 01:50:29 2022 From: clemc at ccc.com (Clem Cole) Date: Mon, 14 Nov 2022 10:50:29 -0500 Subject: [TUHS] Book: "You Are Not Expected to Understand This" In-Reply-To: References: Message-ID: On Mon, Nov 14, 2022 at 9:16 AM Douglas McIlroy < douglas.mcilroy at dartmouth.edu> wrote: > "One view of the memory, period." That describes Multics. > Yep -- but not surprising. There were a bunch of folks at DG that had worked on a single-level store system (Project Fountain-Head) that had failed [some of that story is described in Kidder's book]. They had studied Multics extensively, and that system supposedly had taken a great deal from it. I never completely knew what happened other than something went south and it end up getting canceled. I later got to know of a number of the MV10000 folks (who later joined us in the HW team at Stellar). But I believe a bit issue with Fountain Head was both new HW and SW, whereas the MV10000 allowed Nova /Eclipse code to 'just work.' [Kidder makes a big deal out of this in the book]. The lessons and relevance to TUHS I think are a couple of things: 1.) When they did DG-UX, the SW folks had previously developed a kernel with that view, so it's not surprising. 2.) Cost of >>solution development<< is the real end-customer/deployer driver (economics beats architecture). Clem ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From norman at oclsc.org Tue Nov 15 02:58:36 2022 From: norman at oclsc.org (Norman Wilson) Date: Mon, 14 Nov 2022 11:58:36 -0500 (EST) Subject: [TUHS] Book: "You Are Not Expected to Understand This" Message-ID: <221091F111EBACF012E50DDA19871666.for-standards-violators@oclsc.org> Clem Cole: Yep -- but not surprising. There were a bunch of folks at DG that had worked on a single-level store system (Project Fountain-Head) that had failed [some of that story is described in Kidder's book]. ==== Are you sure? I thought Fountainhead was a Rand project. Norman Wilson Toronto ON PS: if you don't get it, consider yourself fortunate. From lm at mcvoy.com Tue Nov 15 05:17:39 2022 From: lm at mcvoy.com (Larry McVoy) Date: Mon, 14 Nov 2022 11:17:39 -0800 Subject: [TUHS] Book: "You Are Not Expected to Understand This" In-Reply-To: <221091F111EBACF012E50DDA19871666.for-standards-violators@oclsc.org> References: <221091F111EBACF012E50DDA19871666.for-standards-violators@oclsc.org> Message-ID: <20221114191739.GG16293@mcvoy.com> On Mon, Nov 14, 2022 at 11:58:36AM -0500, Norman Wilson wrote: > Clem Cole: > > Yep -- but not surprising. There were a bunch of folks at DG that had > worked on a single-level store system (Project Fountain-Head) that had > failed [some of that story is described in Kidder's book]. > > ==== > > Are you sure? I thought Fountainhead was a Rand project. > > Norman Wilson > Toronto ON > > PS: if you don't get it, consider yourself fortunate. I get it. Teenage me thought Rand was a genius, adult me changed his mind. -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From dave at horsfall.org Tue Nov 15 05:50:11 2022 From: dave at horsfall.org (Dave Horsfall) Date: Tue, 15 Nov 2022 06:50:11 +1100 (EST) Subject: [TUHS] Book: "You Are Not Expected to Understand This" In-Reply-To: <20221114191739.GG16293@mcvoy.com> References: <221091F111EBACF012E50DDA19871666.for-standards-violators@oclsc.org> <20221114191739.GG16293@mcvoy.com> Message-ID: On Mon, 14 Nov 2022, Larry McVoy wrote: > > Are you sure? I thought Fountainhead was a Rand project. > > > > PS: if you don't get it, consider yourself fortunate. > > I get it. Teenage me thought Rand was a genius, adult me changed his > mind. I certainly had to think about it for a while... -- Dave, getting off-topic From pnr at planet.nl Tue Nov 15 08:11:36 2022 From: pnr at planet.nl (Paul Ruizendaal) Date: Mon, 14 Nov 2022 23:11:36 +0100 Subject: [TUHS] DG UNIX History Message-ID: <832D1854-6395-4866-8640-18FAD3BD6ADF@planet.nl> > Date: Sat, 12 Nov 2022 17:56:24 -0800 > From: Larry McVoy > Subject: [TUHS] Re: DG UNIX History > > It sounds like they could have supported mmap() easily. I'd love to see > this kernel, it sounds to me like it was SunOS with nicely done SMP > support. The guy that said he'd never seen anything like it before or > since, just makes me want to see it more. > I know someone who was friends with one of the kernel guys, haven't talked > to her in years but I'll see if I can find anything. Following on from the exchange on TUHS about DG-UX, it would seem to me that the (Unix) unified cache was invented at least three times for Unix: - John Reiser at AT&T - At Sun - At DG As to the latter I could find two leads that might help you finding out more. It would seem that this unique Unix is specifically DG-UX version 4: https://web.archive.org/web/20070930212358/http://www.accessmylibrary.com/coms2/summary_0286-9202012_ITM and Michael H. Kelly and Andrew R. Huber, "Engineering a (Multiprocessor) Unix Kernel", Proceedings of the Autumn 1989 EUUG Conference, European Unix Systems User Group, Vienna, Austria, 1989, pp. 7- 19. The unified cache isn’t mentioned, but it would seem that the multiprocessor redesign might have included it. Maybe the author names are helpful. I could not find the paper online, but there was a web page suggesting that a paper copy still exists in a (university?) library in Sweden. ===== Publication: DG Review Publication Date: 01-NOV-88 Author: Huber, Andrew R. DG-UX 4.00: DG's redesigned kernel lays the foundation for future UNIX systems. (includes related article on DG-UX 4.00's file system and an excerpt from Judith S. Hurwitz's 'Data General's UNIX strategy: an evaluation' report) COPYRIGHT 1988 New Media Publications DG/UX 4.00 Revision 4.00 of Data General's native UNIX operating system siginificantly enhances the product and adds unique capabilities not found in other UNIX implementations. This article reviews the goals of DG/UX 4.00 and discusses some of its features. When DG released DG/UX 1.00 in March, 1985, it was based on AT&T's System V Release 2 and incorporated the Berkeley UNIX file system and networking. As DG/UX grew, it continued to incorporate functions of the major standard UNIX systems, as illustrated in the following timeline: * DG/UX 1.00 March, 1985 Based on System V Release 2 and Berkely 4.1. Included Berkely 4.2 file system and TCP/IP (LAN). * DG/UX 2.00, September, 1985 Added Berkeley 4.2 system calls. * DG/UX 3.00, April 1986 Added support for new DG hardware. * DG/UX 3.10 March, 1987 Added Sun Microsystem's Network File System.sup.(R) Added X Windows. * DG/UX 4.00, August, 1988 Re-designed and re-implemented kernel and file system. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: separator.gif Type: image/gif Size: 43 bytes Desc: not available URL: From clemc at ccc.com Tue Nov 15 08:31:52 2022 From: clemc at ccc.com (Clem Cole) Date: Mon, 14 Nov 2022 17:31:52 -0500 Subject: [TUHS] DG UNIX History In-Reply-To: <832D1854-6395-4866-8640-18FAD3BD6ADF@planet.nl> References: <832D1854-6395-4866-8640-18FAD3BD6ADF@planet.nl> Message-ID: On Mon, Nov 14, 2022 at 5:12 PM Paul Ruizendaal wrote: > Following on from the exchange on TUHS about DG-UX, it would seem to me > that the (Unix) unified cache was invented at least three times for Unix: > Not to quibble too much, but s/cache/memory/ I think is a fairer way of saying that. > - John Reiser at AT&T > - At Sun > - At DG > - At CMU (Mach) The interesting thing again, is that while they while all of these implementations seem to have been technologically 'better' - only Mach lived on from the original developers. And in the case of Mach, by the time it was mainstream (macOS) the original implementation had been replaced a few times - so while the concepts are there, I don't think much of the Original CMU code is left in XNU/Darwin [or for that matter in the OSF flavors -- Tru64 rewrote it but it died and the OSF/RI kernel never went anywhere either]. As I said, the lesson to TUHS -- as much as I'm a techie and I am interested in the 'proper' way of doing things ... "good enough" is often what rules. It's too bad none of the good memory implementations made it into >>systems<< that lasted. Clem ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Tue Nov 15 08:48:13 2022 From: dave at horsfall.org (Dave Horsfall) Date: Tue, 15 Nov 2022 09:48:13 +1100 (EST) Subject: [TUHS] Book: "You Are Not Expected to Understand This" In-Reply-To: References: Message-ID: On Sun, 13 Nov 2022, Dave Horsfall wrote: > Disclaimer: I have no connection with them, but I'll likely buy it. The book just arrived (that was fast!); I'll review it when I get a chance, as I'm flat out like a lizard drinking right now. -- Dave From imp at bsdimp.com Tue Nov 15 09:54:54 2022 From: imp at bsdimp.com (Warner Losh) Date: Mon, 14 Nov 2022 16:54:54 -0700 Subject: [TUHS] DG UNIX History In-Reply-To: References: <832D1854-6395-4866-8640-18FAD3BD6ADF@planet.nl> Message-ID: On Mon, Nov 14, 2022 at 3:33 PM Clem Cole wrote: > > > On Mon, Nov 14, 2022 at 5:12 PM Paul Ruizendaal wrote: > >> Following on from the exchange on TUHS about DG-UX, it would seem to me >> that the (Unix) unified cache was invented at least three times for Unix: >> > Not to quibble too much, but s/cache/memory/ I think is a fairer way of > saying that. > > >> - John Reiser at AT&T >> - At Sun >> - At DG >> > - At CMU (Mach) > > The interesting thing again, is that while they while all of these > implementations seem to have been technologically 'better' - only Mach > lived on from the original developers. And in the case of Mach, by the > time it was mainstream (macOS) the original implementation had been > replaced a few times - so while the concepts are there, I don't think much > of the Original CMU code is left in XNU/Darwin [or for that matter in the > OSF flavors -- Tru64 rewrote it but it died and the OSF/RI kernel never > went anywhere either]. > Both FreeBSD and NetBSD re-wrote the vm layer. FreeBSD incrementally, and NetBSD with a new uvm. At least for FreeBSD, this is when the buffer cache was fully (or more fully?) unified because it wasn't quite complete in 4.4BSD as shipped IIRC (or maybe it was that it was really buggy, it's been so long ago now that I've forgotten). Neither are, imho, as good as Sun's in this respect, but both have been better tuned to scale better than SunOS. IIRC from OS/MP days, the buffer cache lock contention started to get bad around 8 or so CPUs (to be fair: SunOS was never MP, these were Solbourne's locking modifications that weren't super-fine grained). > As I said, the lesson to TUHS -- as much as I'm a techie and I am > interested in the 'proper' way of doing things ... "good enough" is often > what rules. > Good enough, and a little more polish to make it even better :) > It's too bad none of the good memory implementations made it into > >>systems<< that lasted.ᐧ > Yea... Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From stuff at riddermarkfarm.ca Tue Nov 15 11:21:19 2022 From: stuff at riddermarkfarm.ca (Stuff Received) Date: Mon, 14 Nov 2022 20:21:19 -0500 Subject: [TUHS] DG UNIX History In-Reply-To: References: <832D1854-6395-4866-8640-18FAD3BD6ADF@planet.nl> Message-ID: <46715e7b-b0ae-e160-4ac1-7f7c5ea2b467@riddermarkfarm.ca> On 2022-11-14 17:31, Clem Cole wrote: > On Mon, Nov 14, 2022 at 5:12 PM Paul Ruizendaal wrote: > > Following on from the exchange on TUHS about DG-UX, it would seem > to me that the (Unix) unified cache was invented at least three > times for Unix: > > Not to quibble too much, but s/cache/memory/  I think is a fairer way > of saying that. > > - John Reiser at AT&T > - At Sun > - At DG > > - At CMU (Mach) > > The interesting thing again, is that while they while all of these > implementations seem to have been technologically 'better' - only Mach > lived on from the original developers.  And in the case of Mach, by > the time it was mainstream (macOS) the original implementation had > been replaced a few times - so while the concepts are there, I don't > think much of the Original CMU code is left in XNU/Darwin [or for that > matter in the OSF flavors -- Tru64 rewrote it but it died and the > OSF/RI kernel never went anywhere either]. The CMU copyrights are still there (https://github.com/apple-opensource/xnu/tree/master/osfmk/mach). Perhaps someone far more knowledgeable than me could spelunk. > > As I said, the lesson to TUHS -- as much as I'm a techie and I am > interested in the 'proper' way of doing things ... "good enough" is > often what rules. Indeed. > > It's too bad none of the good memory implementations made it into > >>systems<< that lasted. > > Clem > ᐧ From tytso at mit.edu Tue Nov 15 16:03:05 2022 From: tytso at mit.edu (Theodore Ts'o) Date: Tue, 15 Nov 2022 01:03:05 -0500 Subject: [TUHS] DG UNIX History In-Reply-To: References: <832D1854-6395-4866-8640-18FAD3BD6ADF@planet.nl> Message-ID: On Mon, Nov 14, 2022 at 04:54:54PM -0700, Warner Losh wrote: > > The interesting thing again, is that while they while all of these > > implementations seem to have been technologically 'better' - only Mach > > lived on from the original developers. And in the case of Mach, by the > > time it was mainstream (macOS) the original implementation had been > > replaced a few times - so while the concepts are there, I don't think much > > of the Original CMU code is left in XNU/Darwin [or for that matter in the > > OSF flavors -- Tru64 rewrote it but it died and the OSF/RI kernel never > > went anywhere either]. > > Both FreeBSD and NetBSD re-wrote the vm layer. FreeBSD incrementally, and > NetBSD with a new uvm. At least for FreeBSD, this is when the buffer cache > was fully (or more fully?) unified because it wasn't quite complete in > 4.4BSD as shipped IIRC (or maybe it was that it was really buggy, it's been > so long ago now that I've forgotten). FWIW, Linux also has a (mostly) unified page cache. Which is to say, for all of the major file systems, there is only a single unified page cache for file data. There are some legacy file systems in Linux (e.g., befs, qnx4, qnx6, minix, vfat, etc.) that still use the buffer cache, but the buffer cache is implemented in terms of the page cache infrastructure, and that's mainly because no one has really bothered to update those file systems to use the unified page cache. After all, you're using vfat to read and write for super-slow USB thumb drive, who cares if data is getting copied from the USB thumb drive, to the buffer cache, and then to the page cache? :-) > > As I said, the lesson to TUHS -- as much as I'm a techie and I am > > interested in the 'proper' way of doing things ... "good enough" is often > > what rules. > > Good enough, and a little more polish to make it even better :) Good enough, and backwards compatibility, sure. But for the file systems where performance is an issue, having a unified page is the only way to go. :-) > > It's too bad none of the good memory implementations made it into > > >>systems<< that lasted.ᐧ At least in my book, it's not the implementations, but the ideas that matter. And sometimes implementations are constrained by hardware limitations (example: clists), and for less contrained hardware, sometimes you're better re-evaluating whether the ideas in use, and if that means that you need to reimplement the ideas that still make sense, there's nothing wrong with that. - Ted P.S. I remember back in the day when I was engaging in a friendly competition with a FreeBSD hacker on improving the serial driver for the 8250 chip (with no FIFO's!), and I shared with him my idea of using a pair of ring buffers that would get flipped back and forth between the interrupt handler and the tty "bottom-half" (read: software interrupt) handler, and I was told that clists were handed down from Olympus by the AT&T/Unix Gods and he could never get that kind of change into the FreeBSD tty layer. Of course, I was free to make all of the radical changes to Linux's tty layer --- and I did, all in the name of the number of 115kbaud connections that could be handled on a single 40 MHz 386 processor... From lm at mcvoy.com Wed Nov 16 01:11:33 2022 From: lm at mcvoy.com (Larry McVoy) Date: Tue, 15 Nov 2022 07:11:33 -0800 Subject: [TUHS] DG UNIX History In-Reply-To: References: <832D1854-6395-4866-8640-18FAD3BD6ADF@planet.nl> Message-ID: <20221115151133.GL16293@mcvoy.com> On Tue, Nov 15, 2022 at 01:03:05AM -0500, Theodore Ts'o wrote: > P.S. I remember back in the day when I was engaging in a friendly > competition with a FreeBSD hacker on improving the serial driver for > the 8250 chip (with no FIFO's!), and I shared with him my idea of > using a pair of ring buffers that would get flipped back and forth > between the interrupt handler and the tty "bottom-half" (read: > software interrupt) handler, and I was told that clists were handed > down from Olympus by the AT&T/Unix Gods and he could never get that > kind of change into the FreeBSD tty layer. Of course, I was free to > make all of the radical changes to Linux's tty layer --- and I did, > all in the name of the number of 115kbaud connections that could be > handled on a single 40 MHz 386 processor... I remember being pleasantly surprised that Linus/Linux was open to that sort of change. I get why the traditional Unix shops resisted be wacks like that but they went too far and it prevented good work. Linux seemed far more willing to realize that they had it wrong and there was a better way. That was refreshing. Of course they got beat up for it with "Linux is stable/compatible". -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From bakul at iitbombay.org Wed Nov 16 01:48:23 2022 From: bakul at iitbombay.org (Bakul Shah) Date: Tue, 15 Nov 2022 07:48:23 -0800 Subject: [TUHS] DG UNIX History In-Reply-To: <20221115151133.GL16293@mcvoy.com> References: <832D1854-6395-4866-8640-18FAD3BD6ADF@planet.nl> <20221115151133.GL16293@mcvoy.com> Message-ID: On Nov 15, 2022, at 7:11 AM, Larry McVoy wrote: > > On Tue, Nov 15, 2022 at 01:03:05AM -0500, Theodore Ts'o wrote: >> P.S. I remember back in the day when I was engaging in a friendly >> competition with a FreeBSD hacker on improving the serial driver for >> the 8250 chip (with no FIFO's!), and I shared with him my idea of >> using a pair of ring buffers that would get flipped back and forth >> between the interrupt handler and the tty "bottom-half" (read: >> software interrupt) handler, and I was told that clists were handed >> down from Olympus by the AT&T/Unix Gods and he could never get that >> kind of change into the FreeBSD tty layer. Of course, I was free to >> make all of the radical changes to Linux's tty layer --- and I did, >> all in the name of the number of 115kbaud connections that could be >> handled on a single 40 MHz 386 processor... > > I remember being pleasantly surprised that Linus/Linux was open to > that sort of change. I get why the traditional Unix shops resisted > be wacks like that but they went too far and it prevented good work. > > Linux seemed far more willing to realize that they had it wrong and > there was a better way. That was refreshing. > > Of course they got beat up for it with "Linux is stable/compatible". At Fortune Systems Dave Yost was able to achieve full-duplex 9600 baud speed on up to 5 ports in V7 Unix without changing the clist design. This on a 5.6Mhz machine (with 4 cycle memory). The trick was to specialize interrupt handlers for each port. From imp at bsdimp.com Wed Nov 16 03:47:20 2022 From: imp at bsdimp.com (Warner Losh) Date: Tue, 15 Nov 2022 10:47:20 -0700 Subject: [TUHS] DG UNIX History In-Reply-To: References: <832D1854-6395-4866-8640-18FAD3BD6ADF@planet.nl> Message-ID: On Mon, Nov 14, 2022 at 11:03 PM Theodore Ts'o wrote: > On Mon, Nov 14, 2022 at 04:54:54PM -0700, Warner Losh wrote: > > > The interesting thing again, is that while they while all of these > > > implementations seem to have been technologically 'better' - only Mach > > > lived on from the original developers. And in the case of Mach, by the > > > time it was mainstream (macOS) the original implementation had been > > > replaced a few times - so while the concepts are there, I don't think > much > > > of the Original CMU code is left in XNU/Darwin [or for that matter in > the > > > OSF flavors -- Tru64 rewrote it but it died and the OSF/RI kernel never > > > went anywhere either]. > > > > Both FreeBSD and NetBSD re-wrote the vm layer. FreeBSD incrementally, and > > NetBSD with a new uvm. At least for FreeBSD, this is when the buffer > cache > > was fully (or more fully?) unified because it wasn't quite complete in > > 4.4BSD as shipped IIRC (or maybe it was that it was really buggy, it's > been > > so long ago now that I've forgotten). > > FWIW, Linux also has a (mostly) unified page cache. Which is to say, > for all of the major file systems, there is only a single unified page > cache for file data. > > There are some legacy file systems in Linux (e.g., befs, qnx4, qnx6, > minix, vfat, etc.) that still use the buffer cache, but the buffer > cache is implemented in terms of the page cache infrastructure, and > that's mainly because no one has really bothered to update those file > systems to use the unified page cache. After all, you're using vfat > to read and write for super-slow USB thumb drive, who cares if data is > getting copied from the USB thumb drive, to the buffer cache, and then > to the page cache? :-) > > > > As I said, the lesson to TUHS -- as much as I'm a techie and I am > > > interested in the 'proper' way of doing things ... "good enough" is > often > > > what rules. > > > > Good enough, and a little more polish to make it even better :) > > Good enough, and backwards compatibility, sure. But for the file > systems where performance is an issue, having a unified page is the > only way to go. :-) > > > > It's too bad none of the good memory implementations made it into > > > >>systems<< that lasted.ᐧ > > At least in my book, it's not the implementations, but the ideas that > matter. And sometimes implementations are constrained by hardware > limitations (example: clists), and for less contrained hardware, > sometimes you're better re-evaluating whether the ideas in use, and if > that means that you need to reimplement the ideas that still make > sense, there's nothing wrong with that. > > - Ted > > P.S. I remember back in the day when I was engaging in a friendly > competition with a FreeBSD hacker on improving the serial driver for > the 8250 chip (with no FIFO's!), and I shared with him my idea of > using a pair of ring buffers that would get flipped back and forth > between the interrupt handler and the tty "bottom-half" (read: > software interrupt) handler, and I was told that clists were handed > down from Olympus by the AT&T/Unix Gods and he could never get that > kind of change into the FreeBSD tty layer. Of course, I was free to > make all of the radical changes to Linux's tty layer --- and I did, > all in the name of the number of 115kbaud connections that could be > handled on a single 40 MHz 386 processor... > Thankfully, clists have been gone forever from the FreeBSD tty layer (since FreeBSD 2 or 3 if memory serves). The soft interrupt stuff had to wait to be replaced until the SMPng efforts to make FreeBSD scale on multicore. Some cruft remains in the tty layer, to be sure, but it's somewhat better than before. Bruce was quite active in FreeBSD and did drive much change in our thinking, though mostly through getting others to rewrite it in the right way after the main proponents of that dogma left the project and we could grow beyond that past. It was a mistake in the earliest days to think anything from AT&T was sacrosanct and the project is much healthier for it... We'd never been able to scale with the old AT&T inherited design on many many things. Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From fariborz.t at gmail.com Wed Nov 16 09:43:36 2022 From: fariborz.t at gmail.com (Skip Tavakkolian) Date: Tue, 15 Nov 2022 15:43:36 -0800 Subject: [TUHS] seeking answers to really old unix questions Message-ID: Some of you might get a chuckle out of this; note the backdated reply. https://groups.google.com/g/comp.unix.questions/c/W-0VR4Hfpbk Pointed out by @taviso here: https://mastodon.sdf.org/@taviso/109331922494730428 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rdm at cfcl.com Fri Nov 18 06:42:54 2022 From: rdm at cfcl.com (Rich Morin) Date: Thu, 17 Nov 2022 12:42:54 -0800 Subject: [TUHS] early Unix papers, from Jim Joyce Message-ID: <7058E5D4-59AE-4967-9F6B-ADD0A32D1A77@cfcl.com> Well, I got a lot of interesting responses, but the box of papers is still sitting here. Is anyone willing to take on the collection? -r From norman at oclsc.org Mon Nov 21 13:11:30 2022 From: norman at oclsc.org (Norman Wilson) Date: Sun, 20 Nov 2022 22:11:30 -0500 (EST) Subject: [TUHS] /usr/mdec Message-ID: <27941134744AD184AC73F12C29DE3471.for-standards-violators@oclsc.org> I'm curious about the origin of the directory name /usr/mdec. (I am reminded of it because I've noticed that it lives on in at least one of the BSDs.) I had a vague notion that it meant `DEC maintenance' but that seems a bit clumsy to describe a place holding boot blocks. A random web board suggests it meant `magnetic DECtape.' That's certainly not true by the time I came along, when it contained the master copy of the disk boot block(s). But I suppose it could have meant that early on and the name just carried forward. A quick skim of the V1-V7 manuals doesn't explain the name. Anyone have any clearer memories than I do? Doug or Ken or anyone who was there when it was coined, do you still recall? Norman Wilson Toronto ON From dave at horsfall.org Mon Nov 21 14:25:43 2022 From: dave at horsfall.org (Dave Horsfall) Date: Mon, 21 Nov 2022 15:25:43 +1100 (EST) Subject: [TUHS] /usr/mdec In-Reply-To: <27941134744AD184AC73F12C29DE3471.for-standards-violators@oclsc.org> References: <27941134744AD184AC73F12C29DE3471.for-standards-violators@oclsc.org> Message-ID: On Sun, 20 Nov 2022, Norman Wilson wrote: > I'm curious about the origin of the directory name /usr/mdec. (I am > reminded of it because I've noticed that it lives on in at least one of > the BSDs.) > > I had a vague notion that it meant `DEC maintenance' but that seems a > bit clumsy to describe a place holding boot blocks. As far as I know, that's right; MAINDEC was certainly on all of their standalone diagnostic media (a beauty was DECEX, which thrashed the PDP-11 and uncovered a bug in our RK-11 controller; it screwed up on overlapped seeks which RSX didn't use but Harvard(?) did, so DEC's view was that it was obviously a Unix problem). -- Dave From aap at papnet.eu Mon Nov 21 19:56:29 2022 From: aap at papnet.eu (Angelo Papenhoff) Date: Mon, 21 Nov 2022 10:56:29 +0100 Subject: [TUHS] /usr/mdec In-Reply-To: <27941134744AD184AC73F12C29DE3471.for-standards-violators@oclsc.org> References: <27941134744AD184AC73F12C29DE3471.for-standards-violators@oclsc.org> Message-ID: I was also wondering! My theory was that it stands for Magtape & DECtape, but not sure. Perhaps ken remembers? aap On 20/11/22, Norman Wilson wrote: > I'm curious about the origin of the directory name /usr/mdec. > (I am reminded of it because I've noticed that it lives on in > at least one of the BSDs.) > > I had a vague notion that it meant `DEC maintenance' but that > seems a bit clumsy to describe a place holding boot blocks. > > A random web board suggests it meant `magnetic DECtape.' > That's certainly not true by the time I came along, when it > contained the master copy of the disk boot block(s). > But I suppose it could have meant that early on and > the name just carried forward. > > A quick skim of the V1-V7 manuals doesn't explain the name. > > Anyone have any clearer memories than I do? Doug or Ken or > anyone who was there when it was coined, do you still recall? > > Norman Wilson > Toronto ON From jnc at mercury.lcs.mit.edu Tue Nov 22 04:43:48 2022 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Mon, 21 Nov 2022 13:43:48 -0500 (EST) Subject: [TUHS] /usr/mdec Message-ID: <20221121184348.33A7118C087@mercury.lcs.mit.edu> > From: Dave Horsfall > MAINDEC was certainly on all of their standalone diagnostic media Actually, it was the name for all their diagnostics (usually stand-alone), dating back to the paper tape days - when that was the only form they were distributed in. So it makes sense that it's a short form of 'MAINDEC'. Noel From dave at horsfall.org Tue Nov 22 07:11:36 2022 From: dave at horsfall.org (Dave Horsfall) Date: Tue, 22 Nov 2022 08:11:36 +1100 (EST) Subject: [TUHS] /usr/mdec In-Reply-To: <20221121184348.33A7118C087@mercury.lcs.mit.edu> References: <20221121184348.33A7118C087@mercury.lcs.mit.edu> Message-ID: On Mon, 21 Nov 2022, Noel Chiappa wrote: > > MAINDEC was certainly on all of their standalone diagnostic media > > Actually, it was the name for all their diagnostics (usually > stand-alone), dating back to the paper tape days - when that was the > only form they were distributed in. So it makes sense that it's a short > form of 'MAINDEC'. Yep. We had heaps of paper tape diags (along with a tape and an RK-05) with "MAINDEC" on the label, so it was just as well that we had a PC-11 (the only one on campus)... -- Dave From joseph at josephholsten.com Sat Nov 26 05:55:14 2022 From: joseph at josephholsten.com (Joseph Holsten) Date: Fri, 25 Nov 2022 11:55:14 -0800 Subject: [TUHS] Archive search down? Message-ID: Is the search page supposed to be down at https://minnie.tuhs.org/cgi-bin/mailman/tuhs.cgi? -- Joseph Holsten http://josephholsten.com mailto:joseph at josephholsten.com tel:+1-360-927-7234 From web at loomcom.com Sun Nov 27 04:46:33 2022 From: web at loomcom.com (Seth Morabito) Date: Sat, 26 Nov 2022 10:46:33 -0800 Subject: [TUHS] Reaction to the 3B2 at Bell Labs Message-ID: <8f278bf8-de57-4e77-a3b8-d007d7c3a446@app.fastmail.com> Hello all, I'm giving a presentation on the AT&T 3B2 at a local makerspace next month, and while I've been preparing the talk I became curious about an aspect that I don't know has been discussed elsewhere. I'm well aware that the 3B2 was something of a market failure with not much penetration into the wider commercial UNIX space, but I'm very curious to know more about what the reaction was at Bell Labs. When AT&T entered the computer hardware market after the 1984 breakup, I get the impression that there wasn't very much interest in any of it at Bell Labs, is that true? Can anyone recall what the general mood was regarding the 3B2 (and the 7300 and the 6300, I suppose!) -Seth -- Seth Morabito Poulsbo, WA web at loomcom.com From lm at mcvoy.com Sun Nov 27 05:18:27 2022 From: lm at mcvoy.com (Larry McVoy) Date: Sat, 26 Nov 2022 11:18:27 -0800 Subject: [TUHS] Reaction to the 3B2 at Bell Labs In-Reply-To: <8f278bf8-de57-4e77-a3b8-d007d7c3a446@app.fastmail.com> References: <8f278bf8-de57-4e77-a3b8-d007d7c3a446@app.fastmail.com> Message-ID: <20221126191827.GV18011@mcvoy.com> On Sat, Nov 26, 2022 at 10:46:33AM -0800, Seth Morabito wrote: > Can anyone recall what the general mood was regarding the 3B2 (and the 7300 and the 6300, I suppose!) If the 7300 was the 3B1, M68K, I had one of those and a good friend also had one. It was a huge step up from a CP/M machine which was my previous machine. I liked it a lot. But I wasn't at Bell Labs so perhaps this isn't the info you want. I got the sense that the 3B2 was not very popular anywhere. From douglas.mcilroy at dartmouth.edu Sun Nov 27 05:21:27 2022 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Sat, 26 Nov 2022 14:21:27 -0500 Subject: [TUHS] Reaction to the 3B2 at Bell Labs In-Reply-To: <8f278bf8-de57-4e77-a3b8-d007d7c3a446@app.fastmail.com> References: <8f278bf8-de57-4e77-a3b8-d007d7c3a446@app.fastmail.com> Message-ID: All I can say is that the only 3B2 I can remember was in the Living Computer Museum in Seattle. Doug On Sat, Nov 26, 2022 at 1:47 PM Seth Morabito wrote: > > Hello all, > > I'm giving a presentation on the AT&T 3B2 at a local makerspace next month, and while I've been preparing the talk I became curious about an aspect that I don't know has been discussed elsewhere. > > I'm well aware that the 3B2 was something of a market failure with not much penetration into the wider commercial UNIX space, but I'm very curious to know more about what the reaction was at Bell Labs. When AT&T entered the computer hardware market after the 1984 breakup, I get the impression that there wasn't very much interest in any of it at Bell Labs, is that true? > > Can anyone recall what the general mood was regarding the 3B2 (and the 7300 and the 6300, I suppose!) > > -Seth > -- > Seth Morabito > Poulsbo, WA > web at loomcom.com From web at loomcom.com Sun Nov 27 06:04:11 2022 From: web at loomcom.com (Seth Morabito) Date: Sat, 26 Nov 2022 12:04:11 -0800 Subject: [TUHS] Reaction to the 3B2 at Bell Labs In-Reply-To: <20221126191827.GV18011@mcvoy.com> References: <8f278bf8-de57-4e77-a3b8-d007d7c3a446@app.fastmail.com> <20221126191827.GV18011@mcvoy.com> Message-ID: <764dda08-f358-4c74-8056-ef8fc80bcaac@app.fastmail.com> On Sat, Nov 26, 2022, at 11:18 AM, Larry McVoy wrote: > On Sat, Nov 26, 2022 at 10:46:33AM -0800, Seth Morabito wrote: >> Can anyone recall what the general mood was regarding the 3B2 (and the 7300 and the 6300, I suppose!) > > If the 7300 was the 3B1, M68K, I had one of those and a good friend also > had one. It was a huge step up from a CP/M machine which was my > previous machine. I liked it a lot. > > But I wasn't at Bell Labs so perhaps this isn't the info you want. I got > the sense that the 3B2 was not very popular anywhere. It was definitely a weird beast. I'm only "fond" of it in the loosest possible sense because I spent so much time trying to understand its internals. It was the perfect combination of too slow, too low specs, and too expensive! I think one of my slides will simply say "IT WAS BAD AT BEING A COMPUTER" -Seth -- Seth Morabito Poulsbo, WA web at loomcom.com From robpike at gmail.com Sun Nov 27 06:42:38 2022 From: robpike at gmail.com (Rob Pike) Date: Sun, 27 Nov 2022 07:42:38 +1100 Subject: [TUHS] Reaction to the 3B2 at Bell Labs In-Reply-To: <764dda08-f358-4c74-8056-ef8fc80bcaac@app.fastmail.com> References: <8f278bf8-de57-4e77-a3b8-d007d7c3a446@app.fastmail.com> <20221126191827.GV18011@mcvoy.com> <764dda08-f358-4c74-8056-ef8fc80bcaac@app.fastmail.com> Message-ID: It was not popular with CS Research, and we were not popular with them. We were using VAXes, which the 3B series were attempting to compete against. The VAX was not exactly graceful, architecturally, but the 3B series was clumsier and less cost-effective. We weren't interested, despite frequently applied pressure. And, although a different topic, there was the way the commercialization of the Blit forced the 68000 to be replaced by the BELLMAC-32 by essentially the same people, or at least the same boss (Scanlon), which was a poor decision on every dimension. The idea was to get BELLMACs out there to drive up production, but the chip was far less suitable, and each one cost about what a full Blit with a 68000 instead would have. A loss leader, bad financially and bad technically. On the other hand, as I resullt of I did port an OS and other software to the BELLMAC-32 as a result of this work, and learned how badly it did things like memory management and the interrupt vector setup, and how buggy it was. So there were not many warm feelings between 1127 and the computer division. -rob On Sun, Nov 27, 2022 at 7:05 AM Seth Morabito wrote: > On Sat, Nov 26, 2022, at 11:18 AM, Larry McVoy wrote: > > On Sat, Nov 26, 2022 at 10:46:33AM -0800, Seth Morabito wrote: > >> Can anyone recall what the general mood was regarding the 3B2 (and the > 7300 and the 6300, I suppose!) > > > > If the 7300 was the 3B1, M68K, I had one of those and a good friend also > > had one. It was a huge step up from a CP/M machine which was my > > previous machine. I liked it a lot. > > > > But I wasn't at Bell Labs so perhaps this isn't the info you want. I got > > the sense that the 3B2 was not very popular anywhere. > > It was definitely a weird beast. I'm only "fond" of it in the loosest > possible sense because I spent so much time trying to understand its > internals. It was the perfect combination of too slow, too low specs, and > too expensive! > > I think one of my slides will simply say "IT WAS BAD AT BEING A COMPUTER" > > -Seth > -- > Seth Morabito > Poulsbo, WA > web at loomcom.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Sun Nov 27 07:46:47 2022 From: clemc at ccc.com (Clem Cole) Date: Sat, 26 Nov 2022 16:46:47 -0500 Subject: [TUHS] Reaction to the 3B2 at Bell Labs In-Reply-To: References: <8f278bf8-de57-4e77-a3b8-d007d7c3a446@app.fastmail.com> <20221126191827.GV18011@mcvoy.com> <764dda08-f358-4c74-8056-ef8fc80bcaac@app.fastmail.com> Message-ID: Seth, I've often said the only reason they sold any of them was that AT&T required you to buy one as the reference system for SVR3 - so anyone that wanted to port it tended to buy one 3B2 just to have it as the reference box. Rob's comment about the BELLMAC-32 was interesting. I could never quite understand why AT&T wanted to create its own microprocessor and associated ISA and try to sell it against the other merchant microprocessors (just as I never could understand why HP and IBM did either - but they were already formally in the computer business). Selling chips to other people to use for their designs is a difficult business that needs a sophisticated sales and marketing team. Even if AT&T could create a technically competitive device and get the manufacturing cost structure in line with Moto or Intel so that the street price could be competitive, the previous sales and marketing scheme of abandoning UNIX on your doorstep was not going to work, and it was having a new technical sales support team to match Intel and Moto was just not going to happen any time soon. Supporting the operating companies is a different beast than supporting, say, a start-up trying to build a hot new device -> that company's product. While I suspect Rob and Bart built their own tools for the redox of the Blit, Rob I ask you -- truly if you have been outside of AT&T, could you imagine trying to use that device? I can't. I've told the details of the story elsewhere, and they don't really matter here. But I remember being at Masscomp and finding a bug in the new FP chip for the 68020 - which was causing a 'stop shop' on our newest product - when one of the factory exercisers/diags started to fail. We were paying a premium at the time and Moto's local folks did not want to listen at first. Our head of HW came to me because he knew that I knew a bit about the application program they were using as a test from my grad school days. With the end help of the Fortran compiler back-end guys in a few hours of debugging, I was able to isolate the chip failure. Then I wrote a new 10-line Fortran example and associated assembler code, which we faxed to Moto. Moto had a 'Technical Consulting Engineer' on the line from Austin, and indeed it was validated as a problem, and less than 12 hrs later their team had figured out what was going on in the chip. I bring this up because I just don't see AT&T has been able to react that way, although, in the end, we had to solve it once Moto figure out what the cause of the error was (a slow charge circuit was wiping out the exponent in R/R instructions under certain conditions - so we changed the compiler not generate the sequence so we should still ship). ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.donner at gmail.com Sun Nov 27 09:00:38 2022 From: marc.donner at gmail.com (Marc Donner) Date: Sat, 26 Nov 2022 18:00:38 -0500 Subject: [TUHS] Reaction to the 3B2 at Bell Labs In-Reply-To: References: <8f278bf8-de57-4e77-a3b8-d007d7c3a446@app.fastmail.com> <20221126191827.GV18011@mcvoy.com> <764dda08-f358-4c74-8056-ef8fc80bcaac@app.fastmail.com> Message-ID: My chronology may be borked, but what I remember from that era is that IBM was selling the AS/400 very effectively against the VAX by then and was vacuuming up the market. The problem was that DEC's theory of sales was to have engineers sell to engineers, while IBM sold basement servers to chain stores. The chains bought these things by the bushel basket. The HW and OS were both weird (as seen by the computer scientists at Watson) but remarkably reliable. As near as I can tell, this was what ultimately put DEC under ... I think the 3B2 was collateral damage ... I presume that AT&T did not really have time to learn how to sell machines to the commercial market, particularly to the folks who were buying them in numbers ending in ,000. What I learned while watching from the sidelines is that I (and by extension everyone on this list) was not the target audience. ===== nygeek.net mindthegapdialogs.com/home On Sat, Nov 26, 2022 at 4:48 PM Clem Cole wrote: > Seth, I've often said the only reason they sold any of them was that AT&T > required you to buy one as the reference system for SVR3 - so anyone that > wanted to port it tended to buy one 3B2 just to have it as the reference > box. > > Rob's comment about the BELLMAC-32 was interesting. I could never quite > understand why AT&T wanted to create its own microprocessor and associated > ISA and try to sell it against the other merchant microprocessors (just as > I never could understand why HP and IBM did either - but they were already > formally in the computer business). Selling chips to other people to use > for their designs is a difficult business that needs a sophisticated sales > and marketing team. Even if AT&T could create a technically > competitive device and get the manufacturing cost structure in line > with Moto or Intel so that the street price could be competitive, the > previous sales and marketing scheme of abandoning UNIX on your doorstep was > not going to work, and it was having a new technical sales support team to > match Intel and Moto was just not going to happen any time soon. > > Supporting the operating companies is a different beast than supporting, > say, a start-up trying to build a hot new device -> that company's > product. While I suspect Rob and Bart built their own tools for the > redox of the Blit, Rob I ask you -- truly if you have been outside of AT&T, > could you imagine trying to use that device? I can't. > > I've told the details of the story elsewhere, and they don't really matter > here. But I remember being at Masscomp and finding a bug in the new FP chip > for the 68020 - which was causing a 'stop shop' on our newest product - > when one of the factory exercisers/diags started to fail. We were paying > a premium at the time and Moto's local folks did not want to listen at > first. Our head of HW came to me because he knew that I knew a bit about > the application program they were using as a test from my grad school > days. With the end help of the Fortran compiler back-end guys in a few > hours of debugging, I was able to isolate the chip failure. Then I wrote a > new 10-line Fortran example and associated assembler code, which we faxed > to Moto. Moto had a 'Technical Consulting Engineer' on the line from > Austin, and indeed it was validated as a problem, and less than 12 hrs > later their team had figured out what was going on in the chip. > > I bring this up because I just don't see AT&T has been able to react that > way, although, in the end, we had to solve it once Moto figure out what the > cause of the error was (a slow charge circuit was wiping out the exponent > in R/R instructions under certain conditions - so we changed the compiler > not generate the sequence so we should still ship). > ᐧ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Sun Nov 27 09:23:23 2022 From: lm at mcvoy.com (Larry McVoy) Date: Sat, 26 Nov 2022 15:23:23 -0800 Subject: [TUHS] Reaction to the 3B2 at Bell Labs In-Reply-To: References: <8f278bf8-de57-4e77-a3b8-d007d7c3a446@app.fastmail.com> <20221126191827.GV18011@mcvoy.com> <764dda08-f358-4c74-8056-ef8fc80bcaac@app.fastmail.com> Message-ID: <20221126232323.GX18011@mcvoy.com> On Sat, Nov 26, 2022 at 06:00:38PM -0500, Marc Donner wrote: > remarkably reliable. As near as I can tell, this was what ultimately put > DEC under ... Sun Microsystems has entered the chat... They very much competed with DEC and ate their lunch. From crossd at gmail.com Sun Nov 27 09:47:52 2022 From: crossd at gmail.com (Dan Cross) Date: Sat, 26 Nov 2022 18:47:52 -0500 Subject: [TUHS] Reaction to the 3B2 at Bell Labs In-Reply-To: <20221126232323.GX18011@mcvoy.com> References: <8f278bf8-de57-4e77-a3b8-d007d7c3a446@app.fastmail.com> <20221126191827.GV18011@mcvoy.com> <764dda08-f358-4c74-8056-ef8fc80bcaac@app.fastmail.com> <20221126232323.GX18011@mcvoy.com> Message-ID: On Sat, Nov 26, 2022, 6:23 PM Larry McVoy wrote: > On Sat, Nov 26, 2022 at 06:00:38PM -0500, Marc Donner wrote: > > remarkably reliable. As near as I can tell, this was what ultimately put > > DEC under ... > > Sun Microsystems has entered the chat... They very much competed with > DEC and ate their lunch. > I think ultimately DEC ate DEC's own lunch. They bet on re VAX 9000 and that wasn't a wise gamble. - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Sun Nov 27 10:17:14 2022 From: lm at mcvoy.com (Larry McVoy) Date: Sat, 26 Nov 2022 16:17:14 -0800 Subject: [TUHS] Reaction to the 3B2 at Bell Labs In-Reply-To: References: <8f278bf8-de57-4e77-a3b8-d007d7c3a446@app.fastmail.com> <20221126191827.GV18011@mcvoy.com> <764dda08-f358-4c74-8056-ef8fc80bcaac@app.fastmail.com> <20221126232323.GX18011@mcvoy.com> Message-ID: <20221127001714.GY18011@mcvoy.com> On Sat, Nov 26, 2022 at 06:47:52PM -0500, Dan Cross wrote: > On Sat, Nov 26, 2022, 6:23 PM Larry McVoy wrote: > > > On Sat, Nov 26, 2022 at 06:00:38PM -0500, Marc Donner wrote: > > > remarkably reliable. As near as I can tell, this was what ultimately put > > > DEC under ... > > > > Sun Microsystems has entered the chat... They very much competed with > > DEC and ate their lunch. > > > > I think ultimately DEC ate DEC's own lunch. They bet on re VAX 9000 and > that wasn't a wise gamble. I read the Wikipedia page on the 9000. It's sad that the 9000 wasn't cancelled when they had better alternatives. It reminds me of a CPU I got cancelled at SGI. It was in the mid 1990's and the project was code named "Beast". It could do tons of data movement, to make that happen, the packaging had pin recepters on all sides, top, bottom, and all 4 sides. The packaging, at volume, was going to cost $1,200 each. No CPU, just the packaging. On top of that, SGI did a flip/flop design cycle, flip focussed on integer performance, databases, while flop focussed on floating point and catered to the super computing market. This was when almost all of the processor architects were talking to me because I had written LMbench which was a set of microbenchmarks that measured bandwidth and latency of everything. The architects loved them because they were small and could be run on a simulator. So I had a pretty good idea what Sun was coming up with (I had left Sun for SGI), knew what Intel was doing, HP yep, DEC less so but had some idea about the Alpha roadmap, IBM was the one place that I didn't have good intel. I looked at what Beast was claiming, looked at the past predictions of MIPS chips and when they shipped vs when they would claim to ship, and looked at the exploding internet / database market and gulped. Beast was the wrong answer and we were gonna get crushed. I started shopping my theory around, eventually got a meeting with Wei Yen (who was someone high enough up). I went over all the info I had, Wei Yen was super impressed and asked me if this was my job and I said "oh, no, this is just a hobby I play around with" and he replied "Keep playing, you play nicely" and went off and cancelled Beast. DEC needed someone with that sort of data. I had actual performance results from every processor in the mainstream and they were no bullshit results, anyone could reproduce them. Then I had some idea of almost everyone's roadmap. Without the data, they would have wasted a ton of money on Beast. In the end, it didn't really matter, x86 killed SGI just like Sun and IBM killed DEC. And x86 killed Sun as well. -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From rudi.j.blom at gmail.com Sun Nov 27 12:22:52 2022 From: rudi.j.blom at gmail.com (Rudi Blom) Date: Sun, 27 Nov 2022 09:22:52 +0700 Subject: [TUHS] /usr/mdec Message-ID: On DEC's TRU64 UNIX it was /mdec Making a system image with mkisofs I'd follow with disklabel -rw -f ${UTMP}/${NAME_ISO} /mdec/rzboot.cdfs /mdec/bootrz.cdfs Cheers, uncle rubl -- The more I learn the better I understand I know nothing. -------------- next part -------------- An HTML attachment was scrubbed... URL: From phil at ultimate.com Sun Nov 27 14:43:50 2022 From: phil at ultimate.com (Phil Budne) Date: Sat, 26 Nov 2022 23:43:50 -0500 Subject: [TUHS] Reaction to the 3B2 at Bell Labs In-Reply-To: <20221127001714.GY18011@mcvoy.com> References: <8f278bf8-de57-4e77-a3b8-d007d7c3a446@app.fastmail.com> <20221126191827.GV18011@mcvoy.com> <764dda08-f358-4c74-8056-ef8fc80bcaac@app.fastmail.com> <20221126232323.GX18011@mcvoy.com> <20221127001714.GY18011@mcvoy.com> Message-ID: <202211270443.2AR4hofO067295@ultimate.com> Larry McVoy wrote: > I read the Wikipedia page on the 9000. It's sad that the 9000 > wasn't cancelled when they had better alternatives. In an oral history Bob Supnik described Ken Olsen couldn't get his head around the fact that the NVAX chip could equal the 9000: @2:59:45 in https://www.youtube.com/watch?v=T3tcCBHRIfU In part 2, Bob described how then DEC VP Gordon Bell having earlier predicted when the microprocessor performance curve would cross over minis and mainframes: @1:51:45 in https://www.youtube.com/watch?v=T3tcCBHRIfU He also talks about how the company couldn't command the bsame gross margins as it did in the VAX era. From jpl.jpl at gmail.com Sun Nov 27 22:10:28 2022 From: jpl.jpl at gmail.com (John P. Linderman) Date: Sun, 27 Nov 2022 07:10:28 -0500 Subject: [TUHS] Fred Brooks died Message-ID: We all probably read, and profited from, "The Mythical Man Month". https://www.nytimes.com/2022/11/23/technology/frederick-p-brooks-jr-dead.html?unlocked_article_code=pcmLspOt6G4B9uXm5cFfTdnHU_KllQB4tCOPPQjVK-YHPpYu1lN4XC-bcbbqYl8saM739PC7FOZWBcMt4uEx7sm0HcLJoaW_izaro6Bapm_JDQqLaOYSlU1wB3iHBjgRbAPJETHRdN_xBFvQ7yZJAt5BfvIVYjzE5UnJys7LzzT5UWkpa4IfYoDjC0YNcQb6QrCzKEoDq0R5Mxpojt4XMSWJs27ruoh86qxqVZ42NItiuF6c_bDFDwnVEgoeUIPRFF6sROunTT8VSYDqokH-HzWQj_9_odmINFB-rOdB3HI913fYLBMuet4A8V_VvVnkmILZ8N81ssia4_fN7poEIJdQzHYjGQ&smid=share-url -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron at ronnatalie.com Sun Nov 27 23:46:06 2022 From: ron at ronnatalie.com (Ron Natalie) Date: Sun, 27 Nov 2022 13:46:06 +0000 Subject: [TUHS] Fred Brooks died In-Reply-To: References: Message-ID: The man who made Research Triangle. When IBM came to throw some money into computer science research, he told them to give equal shares to UNC, State, and Duke. ------ Original Message ------ >From "John P. Linderman" To "The Eunuchs Hysterical Society" Date 11/27/2022 7:10:28 AM Subject [TUHS] Fred Brooks died >We all probably read, and profited from, "The Mythical Man Month". > >https://www.nytimes.com/2022/11/23/technology/frederick-p-brooks-jr-dead.html?unlocked_article_code=pcmLspOt6G4B9uXm5cFfTdnHU_KllQB4tCOPPQjVK-YHPpYu1lN4XC-bcbbqYl8saM739PC7FOZWBcMt4uEx7sm0HcLJoaW_izaro6Bapm_JDQqLaOYSlU1wB3iHBjgRbAPJETHRdN_xBFvQ7yZJAt5BfvIVYjzE5UnJys7LzzT5UWkpa4IfYoDjC0YNcQb6QrCzKEoDq0R5Mxpojt4XMSWJs27ruoh86qxqVZ42NItiuF6c_bDFDwnVEgoeUIPRFF6sROunTT8VSYDqokH-HzWQj_9_odmINFB-rOdB3HI913fYLBMuet4A8V_VvVnkmILZ8N81ssia4_fN7poEIJdQzHYjGQ&smid=share-url -------------- next part -------------- An HTML attachment was scrubbed... URL: From jpl.jpl at gmail.com Mon Nov 28 00:51:25 2022 From: jpl.jpl at gmail.com (John P. Linderman) Date: Sun, 27 Nov 2022 09:51:25 -0500 Subject: [TUHS] Reaction to the 3B2 at Bell Labs In-Reply-To: <202211270443.2AR4hofO067295@ultimate.com> References: <8f278bf8-de57-4e77-a3b8-d007d7c3a446@app.fastmail.com> <20221126191827.GV18011@mcvoy.com> <764dda08-f358-4c74-8056-ef8fc80bcaac@app.fastmail.com> <20221126232323.GX18011@mcvoy.com> <20221127001714.GY18011@mcvoy.com> <202211270443.2AR4hofO067295@ultimate.com> Message-ID: We were "gifted" a 3B2, as in "take this and use it!". I ran a "ps" command in single user mode, and it took 20 seconds to run. Our machine names were themed around bird names, so we christened the 3B2 "junco". Our director said we had to get along, so we renamed it "jay". But everyone knew what the J stood for. The 3B2 served as a doorstop. On Sat, Nov 26, 2022 at 11:44 PM Phil Budne wrote: > Larry McVoy wrote: > > I read the Wikipedia page on the 9000. It's sad that the 9000 > > wasn't cancelled when they had better alternatives. > > In an oral history Bob Supnik described Ken Olsen couldn't get his > head around the fact that the NVAX chip could equal the 9000: > > @2:59:45 in https://www.youtube.com/watch?v=T3tcCBHRIfU > > In part 2, Bob described how then DEC VP Gordon Bell having earlier > predicted when the microprocessor performance curve would cross over > minis and mainframes: > > @1:51:45 in https://www.youtube.com/watch?v=T3tcCBHRIfU > > He also talks about how the company couldn't command the bsame gross > margins as it did in the VAX era. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Mon Nov 28 00:53:42 2022 From: lm at mcvoy.com (Larry McVoy) Date: Sun, 27 Nov 2022 06:53:42 -0800 Subject: [TUHS] Reaction to the 3B2 at Bell Labs In-Reply-To: <202211270443.2AR4hofO067295@ultimate.com> References: <8f278bf8-de57-4e77-a3b8-d007d7c3a446@app.fastmail.com> <20221126191827.GV18011@mcvoy.com> <764dda08-f358-4c74-8056-ef8fc80bcaac@app.fastmail.com> <20221126232323.GX18011@mcvoy.com> <20221127001714.GY18011@mcvoy.com> <202211270443.2AR4hofO067295@ultimate.com> Message-ID: <20221127145342.GC18011@mcvoy.com> On Sat, Nov 26, 2022 at 11:43:50PM -0500, Phil Budne wrote: > Larry McVoy wrote: > > I read the Wikipedia page on the 9000. It's sad that the 9000 > > wasn't cancelled when they had better alternatives. > > In an oral history Bob Supnik described Ken Olsen couldn't get his > head around the fact that the NVAX chip could equal the 9000: > > @2:59:45 in https://www.youtube.com/watch?v=T3tcCBHRIfU > > In part 2, Bob described how then DEC VP Gordon Bell having earlier > predicted when the microprocessor performance curve would cross over > minis and mainframes: > > @1:51:45 in https://www.youtube.com/watch?v=T3tcCBHRIfU > > He also talks about how the company couldn't command the bsame gross > margins as it did in the VAX era. Hence the need for hard reproducible data. I'm sure I would have suffered the same fate at SGI if I had no data. -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From arnold at skeeve.com Mon Nov 28 01:29:47 2022 From: arnold at skeeve.com (arnold at skeeve.com) Date: Sun, 27 Nov 2022 08:29:47 -0700 Subject: [TUHS] Reaction to the 3B2 at Bell Labs In-Reply-To: References: <8f278bf8-de57-4e77-a3b8-d007d7c3a446@app.fastmail.com> <20221126191827.GV18011@mcvoy.com> <764dda08-f358-4c74-8056-ef8fc80bcaac@app.fastmail.com> <20221126232323.GX18011@mcvoy.com> <20221127001714.GY18011@mcvoy.com> <202211270443.2AR4hofO067295@ultimate.com> Message-ID: <202211271529.2ARFTlef022914@freefriends.org> Many schools were similarly gifted; I had them both at Georgia Tech and at Emory. They didn't see a lot of real use. The one more-or-less cool thing they had was a soft power switch; pushing it started an orderly Unix shutdown (usually). Once in a while one had to yank the cord from the wall to shut it down. Arnold "John P. Linderman" wrote: > We were "gifted" a 3B2, as in "take this and use it!". I ran a "ps" command > in single user mode, and it took 20 seconds to run. > Our machine names were themed around bird names, so we christened the 3B2 > "junco". Our director said we had to get along, > so we renamed it "jay". But everyone knew what the J stood for. The 3B2 > served as a doorstop. > > On Sat, Nov 26, 2022 at 11:44 PM Phil Budne wrote: > > > Larry McVoy wrote: > > > I read the Wikipedia page on the 9000. It's sad that the 9000 > > > wasn't cancelled when they had better alternatives. > > > > In an oral history Bob Supnik described Ken Olsen couldn't get his > > head around the fact that the NVAX chip could equal the 9000: > > > > @2:59:45 in https://www.youtube.com/watch?v=T3tcCBHRIfU > > > > In part 2, Bob described how then DEC VP Gordon Bell having earlier > > predicted when the microprocessor performance curve would cross over > > minis and mainframes: > > > > @1:51:45 in https://www.youtube.com/watch?v=T3tcCBHRIfU > > > > He also talks about how the company couldn't command the bsame gross > > margins as it did in the VAX era. > > From ron at ronnatalie.com Mon Nov 28 02:11:34 2022 From: ron at ronnatalie.com (Ron Natalie) Date: Sun, 27 Nov 2022 16:11:34 +0000 Subject: [TUHS] Reaction to the 3B2 at Bell Labs In-Reply-To: References: <8f278bf8-de57-4e77-a3b8-d007d7c3a446@app.fastmail.com> <20221126191827.GV18011@mcvoy.com> <764dda08-f358-4c74-8056-ef8fc80bcaac@app.fastmail.com> <20221126232323.GX18011@mcvoy.com> <20221127001714.GY18011@mcvoy.com> <202211270443.2AR4hofO067295@ultimate.com> Message-ID: >. But everyone knew what the J stood for. The 3B2 served as a doorstop. Shades of the jerq terminal. The J prefix persiste in the code long after the nickname was quashed. Being in charge of the Rutgers computer center, we were gifted a lot of ATT hardware. We had one 3B20 (now that was a pure piece of phone equipment, you shut it down by turning a switch inside and holding the button down until it twanged. Just like putting an old 303 modem into loop back). We also got three 3B5's (noted for the one installed in the New Brunswick computing room that got completely drenched when a pipe burst and kept on running) and countless of the 3B2s. I chortled in that unless you were logged in as root, you couldn't work the power switch. Yanking the cord out of the wall was still and option. -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Mon Nov 28 02:59:10 2022 From: imp at bsdimp.com (Warner Losh) Date: Sun, 27 Nov 2022 09:59:10 -0700 Subject: [TUHS] Reaction to the 3B2 at Bell Labs In-Reply-To: References: <8f278bf8-de57-4e77-a3b8-d007d7c3a446@app.fastmail.com> <20221126191827.GV18011@mcvoy.com> <764dda08-f358-4c74-8056-ef8fc80bcaac@app.fastmail.com> <20221126232323.GX18011@mcvoy.com> <20221127001714.GY18011@mcvoy.com> <202211270443.2AR4hofO067295@ultimate.com> Message-ID: On Sun, Nov 27, 2022, 9:11 AM Ron Natalie wrote: > > . But everyone knew what the J stood for. The 3B2 served as a doorstop. > > > Shades of the jerq terminal. The J prefix persiste in the code long > after the nickname was quashed. > > > Being in charge of the Rutgers computer center, we were gifted a lot of > ATT hardware. We had one 3B20 (now that was a pure piece of phone > equipment, you shut it down by turning a switch inside and holding the > button down until it twanged. Just like putting an old 303 modem into > loop back). We also got three 3B5's (noted for the one installed in the > New Brunswick computing room that got completely drenched when a pipe burst > and kept on running) and countless of the 3B2s. I chortled in that > unless you were logged in as root, you couldn't work the power switch. > Yanking the cord out of the wall was still and option. > When I worked for The Wollongong Group, we had a 3b2, 3b5 and 3b20 for all the networking products we had. The 3b20 was nice. The 3b5 wasn't terrible.... the 3b2 was the only machine I've seen that I could visibly see the characters appear one at a time over the telnet session for some, but not all, programs. Those programs, iirc, used stdio, but the stdio on the 3b2 didn't have buffering turned on... Warner > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnold at skeeve.com Mon Nov 28 04:59:20 2022 From: arnold at skeeve.com (arnold at skeeve.com) Date: Sun, 27 Nov 2022 11:59:20 -0700 Subject: [TUHS] Reaction to the 3B2 at Bell Labs In-Reply-To: References: <8f278bf8-de57-4e77-a3b8-d007d7c3a446@app.fastmail.com> <20221126191827.GV18011@mcvoy.com> <764dda08-f358-4c74-8056-ef8fc80bcaac@app.fastmail.com> <20221126232323.GX18011@mcvoy.com> <20221127001714.GY18011@mcvoy.com> <202211270443.2AR4hofO067295@ultimate.com> Message-ID: <202211271859.2ARIxKqL016933@freefriends.org> Georgia Tech got two 3B20s. They did very little more than consume electricity and look impressive. I wanted to port 4.2BSD to them, but that never got off the ground. "Ron Natalie" wrote: > > >. But everyone knew what the J stood for. The 3B2 served as a doorstop. > > Shades of the jerq terminal. The J prefix persiste in the code long > after the nickname was quashed. > > > Being in charge of the Rutgers computer center, we were gifted a lot of > ATT hardware. We had one 3B20 (now that was a pure piece of phone > equipment, you shut it down by turning a switch inside and holding the > button down until it twanged. Just like putting an old 303 modem into > loop back). We also got three 3B5's (noted for the one installed in > the New Brunswick computing room that got completely drenched when a > pipe burst and kept on running) and countless of the 3B2s. I chortled > in that unless you were logged in as root, you couldn't work the power > switch. Yanking the cord out of the wall was still and option. From dave at horsfall.org Mon Nov 28 06:19:09 2022 From: dave at horsfall.org (Dave Horsfall) Date: Mon, 28 Nov 2022 07:19:09 +1100 (EST) Subject: [TUHS] Fred Brooks died In-Reply-To: References: Message-ID: On Sun, 27 Nov 2022, John P. Linderman wrote: > We all probably read, and profited from, "The Mythical Man Month". Posted to COFF a week ago, as I didn't think that it was Unix-y... -- Dave From norman at oclsc.org Mon Nov 28 06:32:47 2022 From: norman at oclsc.org (Norman Wilson) Date: Sun, 27 Nov 2022 15:32:47 -0500 (EST) Subject: [TUHS] Fred Brooks died Message-ID: An appreciation from someone who knew Fred personally: https://www.cs.columbia.edu/~smb/blog/2022-11/2022-11-18.html Norman Wilson (who knows Steve personally) Toronto ON From robpike at gmail.com Mon Nov 28 06:45:49 2022 From: robpike at gmail.com (Rob Pike) Date: Mon, 28 Nov 2022 07:45:49 +1100 Subject: [TUHS] Reaction to the 3B2 at Bell Labs In-Reply-To: <202211271859.2ARIxKqL016933@freefriends.org> References: <8f278bf8-de57-4e77-a3b8-d007d7c3a446@app.fastmail.com> <20221126191827.GV18011@mcvoy.com> <764dda08-f358-4c74-8056-ef8fc80bcaac@app.fastmail.com> <20221126232323.GX18011@mcvoy.com> <20221127001714.GY18011@mcvoy.com> <202211270443.2AR4hofO067295@ultimate.com> <202211271859.2ARIxKqL016933@freefriends.org> Message-ID: But to shut down the dual 3B20 used in switching, you pulled long copper rod, about 3cm in diameter, from a receptacle between the two machines. It was attached with a braided conductor to the frame. And then you slid the rod into another receptacle to short out the power supply for certain. -rob On Mon, Nov 28, 2022 at 5:59 AM wrote: > Georgia Tech got two 3B20s. They did very little more than consume > electricity and look impressive. I wanted to port 4.2BSD to them, > but that never got off the ground. > > "Ron Natalie" wrote: > > > > > >. But everyone knew what the J stood for. The 3B2 served as a doorstop. > > > > Shades of the jerq terminal. The J prefix persiste in the code long > > after the nickname was quashed. > > > > > > Being in charge of the Rutgers computer center, we were gifted a lot of > > ATT hardware. We had one 3B20 (now that was a pure piece of phone > > equipment, you shut it down by turning a switch inside and holding the > > button down until it twanged. Just like putting an old 303 modem into > > loop back). We also got three 3B5's (noted for the one installed in > > the New Brunswick computing room that got completely drenched when a > > pipe burst and kept on running) and countless of the 3B2s. I chortled > > in that unless you were logged in as root, you couldn't work the power > > switch. Yanking the cord out of the wall was still and option. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Mon Nov 28 06:52:36 2022 From: clemc at ccc.com (Clem Cole) Date: Sun, 27 Nov 2022 15:52:36 -0500 Subject: [TUHS] Fred Brooks died In-Reply-To: References: Message-ID: He was a Unix (and UUCP) fan and also an early Masscomp customer. Let's say I was a tad in awe when I was answering his questions when he came on a factory visit. But he was cool when I asked him if I could go back to my office and get his book so he could sign it. I think he was pleased to see a then young professional have it in his office. ᐧ On Sun, Nov 27, 2022 at 3:19 PM Dave Horsfall wrote: > On Sun, 27 Nov 2022, John P. Linderman wrote: > > > We all probably read, and profited from, "The Mythical Man Month". > > Posted to COFF a week ago, as I didn't think that it was Unix-y... > > -- Dave > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnold at skeeve.com Mon Nov 28 07:00:00 2022 From: arnold at skeeve.com (arnold at skeeve.com) Date: Sun, 27 Nov 2022 14:00:00 -0700 Subject: [TUHS] Fred Brooks died In-Reply-To: References: Message-ID: <202211272100.2ARL00ua032601@freefriends.org> I found two typos in the 25th anniversary edition of the book. I used finger to find his postal address and sent him a letter. He replied with a nice thank you email. One of them had been in the book since it was first published! Clem Cole wrote: > He was a Unix (and UUCP) fan and also an early Masscomp customer. Let's > say I was a tad in awe when I was answering his questions when he came on > a factory visit. But he was cool when I asked him if I could go back to my > office and get his book so he could sign it. I think he was pleased to see > a then young professional have it in his office. > ᐧ > > On Sun, Nov 27, 2022 at 3:19 PM Dave Horsfall wrote: > > > On Sun, 27 Nov 2022, John P. Linderman wrote: > > > > > We all probably read, and profited from, "The Mythical Man Month". > > > > Posted to COFF a week ago, as I didn't think that it was Unix-y... > > > > -- Dave > > From marc.donner at gmail.com Mon Nov 28 21:39:48 2022 From: marc.donner at gmail.com (Marc Donner) Date: Mon, 28 Nov 2022 06:39:48 -0500 Subject: [TUHS] Fred Brooks died In-Reply-To: <202211272100.2ARL00ua032601@freefriends.org> References: <202211272100.2ARL00ua032601@freefriends.org> Message-ID: In 1980 I applied to grad schools, including UNC. I had read "The Mythical Man-Month" by then, so I was floored one day sitting in my office when the phone rang and I heard, "This is Fred Brooks." I visited UNC where I saw the famous row of clocks that Steve Bellovin mentions in his memorial post. The "System 360 Principles of Operation" remains one of the most important pieces of writing in computer history, in my opinion, because it dominated the hardware and established the principle that an architecture ensures software execution. ===== nygeek.net mindthegapdialogs.com/home On Sun, Nov 27, 2022 at 4:00 PM wrote: > I found two typos in the 25th anniversary edition of the book. I used > finger to find his postal address and sent him a letter. He replied with > a nice thank you email. One of them had been in the book since it was > first published! > > > Clem Cole wrote: > > > He was a Unix (and UUCP) fan and also an early Masscomp customer. Let's > > say I was a tad in awe when I was answering his questions when he came on > > a factory visit. But he was cool when I asked him if I could go back to > my > > office and get his book so he could sign it. I think he was pleased to > see > > a then young professional have it in his office. > > ᐧ > > > > On Sun, Nov 27, 2022 at 3:19 PM Dave Horsfall wrote: > > > > > On Sun, 27 Nov 2022, John P. Linderman wrote: > > > > > > > We all probably read, and profited from, "The Mythical Man Month". > > > > > > Posted to COFF a week ago, as I didn't think that it was Unix-y... > > > > > > -- Dave > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pnr at planet.nl Mon Nov 28 23:24:52 2022 From: pnr at planet.nl (Paul Ruizendaal) Date: Mon, 28 Nov 2022 14:24:52 +0100 Subject: [TUHS] Early multiprocessor Unix Message-ID: <7C8CADAB-65AA-4841-AFA1-569A9651E56D@planet.nl> The discussion about the 3B2 triggered another question in my head: what were the earliest multi-processor versions of Unix and how did they relate? My current understanding is that the earliest one is a dual-CPU VAX system with a modified 4BSD done at Purdue. This would have been late 1981, early 1982. I think one CPU was acting as master and had exclusive kernel access, the other CPU would only run user mode code. Then I understand that Keith Kelleman spent a lot of effort to make Unix run on the 3B2 in a SMP setup, essentially going through the source and finding all critical sections and surrounding those with spinlocks. This would be around 1983, and became part of SVr3. I suppose that the “spl()” calls only protected critical sections that were shared between the main thread and interrupt sequences, so that a manual review was necessary to consider each kernel data structure for parallel access issues in the case of 2 CPU’s. Any other notable work in this area prior to 1985? How was the SMP implementation in SVr3 judged back in its day? Paul From stewart at serissa.com Mon Nov 28 23:42:34 2022 From: stewart at serissa.com (Larry Stewart) Date: Mon, 28 Nov 2022 08:42:34 -0500 Subject: [TUHS] Early multiprocessor Unix In-Reply-To: <7C8CADAB-65AA-4841-AFA1-569A9651E56D@planet.nl> References: <7C8CADAB-65AA-4841-AFA1-569A9651E56D@planet.nl> Message-ID: <84EC9581-FABE-48FC-81E8-6559A5239755@serissa.com> There's a 1975 paper about an MP Unix at the Naval Postgraduate School by Hawley and Meyer. https://calhoun.nps.edu/handle/10945/20959 > On Nov 28, 2022, at 8:28 AM, Paul Ruizendaal wrote: > > The discussion about the 3B2 triggered another question in my head: what were the earliest multi-processor versions of Unix and how did they relate? > > My current understanding is that the earliest one is a dual-CPU VAX system with a modified 4BSD done at Purdue. This would have been late 1981, early 1982. I think one CPU was acting as master and had exclusive kernel access, the other CPU would only run user mode code. > > Then I understand that Keith Kelleman spent a lot of effort to make Unix run on the 3B2 in a SMP setup, essentially going through the source and finding all critical sections and surrounding those with spinlocks. This would be around 1983, and became part of SVr3. I suppose that the “spl()” calls only protected critical sections that were shared between the main thread and interrupt sequences, so that a manual review was necessary to consider each kernel data structure for parallel access issues in the case of 2 CPU’s. > > Any other notable work in this area prior to 1985? > > How was the SMP implementation in SVr3 judged back in its day? > > Paul -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Tue Nov 29 00:05:57 2022 From: clemc at ccc.com (Clem Cole) Date: Mon, 28 Nov 2022 09:05:57 -0500 Subject: [TUHS] Early multiprocessor Unix In-Reply-To: <7C8CADAB-65AA-4841-AFA1-569A9651E56D@planet.nl> References: <7C8CADAB-65AA-4841-AFA1-569A9651E56D@planet.nl> Message-ID: As far as I know, the first non-commercial work was done at the Naval Post Grad school with V6. I have never seen the code for it, only a paper, so I don't know too much about it to comment. A few years later (1980), Goble's work became the Purdue Vax [ https://en.wikipedia.org/wiki/George_H._Goble] - which used a master-slave configuration. He spliced a second 780 CPU onto the SMB and, with some interesting work, allowed the second CPU to run user code. This was extremely effective for their usage case -- timesharing of students. If we don't have the code on TUHS, we should probably dig it up, as it was widely distributed. The other thing he did was splice an 11/40 onto the UBA of the same system for debugging - which was a pretty cool hack. He found a couple of interesting BSD kernel issues, including a famous CVE using his real-time monitor -- there is a USENIX paper on that tool that is work checking out. The first commercial MP Unix was the Masscomp MC500/MP, which was originally developed as Goble-style Master/Slave and released in RTU 2.0. A year later, with RTU 3.0 and the release of the MC5000 family, it was fully SMP. After that, several SMP UNIX started to appear. Each uses its own lock scheme. If you are interested, I recommend getting a copy of Schimmel's book: 'Unix on Modern Processors' which discusses many (most) of the challenges. ᐧ On Mon, Nov 28, 2022 at 8:25 AM Paul Ruizendaal wrote: > The discussion about the 3B2 triggered another question in my head: what > were the earliest multi-processor versions of Unix and how did they relate? > > My current understanding is that the earliest one is a dual-CPU VAX system > with a modified 4BSD done at Purdue. This would have been late 1981, early > 1982. I think one CPU was acting as master and had exclusive kernel access, > the other CPU would only run user mode code. > > Then I understand that Keith Kelleman spent a lot of effort to make Unix > run on the 3B2 in a SMP setup, essentially going through the source and > finding all critical sections and surrounding those with spinlocks. This > would be around 1983, and became part of SVr3. I suppose that the “spl()” > calls only protected critical sections that were shared between the main > thread and interrupt sequences, so that a manual review was necessary to > consider each kernel data structure for parallel access issues in the case > of 2 CPU’s. > > Any other notable work in this area prior to 1985? > > How was the SMP implementation in SVr3 judged back in its day? > > Paul -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Tue Nov 29 00:13:31 2022 From: clemc at ccc.com (Clem Cole) Date: Mon, 28 Nov 2022 09:13:31 -0500 Subject: [TUHS] Early multiprocessor Unix In-Reply-To: References: <7C8CADAB-65AA-4841-AFA1-569A9651E56D@planet.nl> Message-ID: Paul, the other thing I should point out -- ghg's work was widely distributed amount the BSD licenses. I somewhat wonder why the Naval Post Grad school's work was not. My guess is that USENIX was still in its formative stages when the latter did their work, whereas, by the time of George's hack, BSD/Vaxen was being used for teaching as University timesharing systems so his 'upgrade' was a cheap solution. ᐧ On Mon, Nov 28, 2022 at 9:05 AM Clem Cole wrote: > As far as I know, the first non-commercial work was done at the Naval Post > Grad school with V6. I have never seen the code for it, only a paper, so I > don't know too much about it to comment. > > A few years later (1980), Goble's work became the Purdue Vax [ > https://en.wikipedia.org/wiki/George_H._Goble] - which used a > master-slave configuration. He spliced a second 780 CPU onto the SMB and, > with some interesting work, allowed the second CPU to run user code. This > was extremely effective for their usage case -- timesharing of students. > If we don't have the code on TUHS, we should probably dig it up, as it was > widely distributed. The other thing he did was splice an 11/40 onto the UBA > of the same system for debugging - which was a pretty cool hack. He found > a couple of interesting BSD kernel issues, including a famous CVE using his > real-time monitor -- there is a USENIX paper on that tool that is work > checking out. > > The first commercial MP Unix was the Masscomp MC500/MP, which was > originally developed as Goble-style Master/Slave and released in RTU 2.0. > A year later, with RTU 3.0 and the release of the MC5000 family, it was > fully SMP. > > After that, several SMP UNIX started to appear. Each uses its own lock > scheme. If you are interested, I recommend getting a copy of Schimmel's > book: 'Unix on Modern Processors' which discusses many (most) of the > challenges. > > > ᐧ > > On Mon, Nov 28, 2022 at 8:25 AM Paul Ruizendaal wrote: > >> The discussion about the 3B2 triggered another question in my head: what >> were the earliest multi-processor versions of Unix and how did they relate? >> >> My current understanding is that the earliest one is a dual-CPU VAX >> system with a modified 4BSD done at Purdue. This would have been late 1981, >> early 1982. I think one CPU was acting as master and had exclusive kernel >> access, the other CPU would only run user mode code. >> >> Then I understand that Keith Kelleman spent a lot of effort to make Unix >> run on the 3B2 in a SMP setup, essentially going through the source and >> finding all critical sections and surrounding those with spinlocks. This >> would be around 1983, and became part of SVr3. I suppose that the “spl()” >> calls only protected critical sections that were shared between the main >> thread and interrupt sequences, so that a manual review was necessary to >> consider each kernel data structure for parallel access issues in the case >> of 2 CPU’s. >> >> Any other notable work in this area prior to 1985? >> >> How was the SMP implementation in SVr3 judged back in its day? >> >> Paul > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Tue Nov 29 00:16:11 2022 From: imp at bsdimp.com (Warner Losh) Date: Mon, 28 Nov 2022 07:16:11 -0700 Subject: [TUHS] Early multiprocessor Unix In-Reply-To: References: <7C8CADAB-65AA-4841-AFA1-569A9651E56D@planet.nl> Message-ID: On Mon, Nov 28, 2022, 7:07 AM Clem Cole wrote: > As far as I know, the first non-commercial work was done at the Naval Post > Grad school with V6. I have never seen the code for it, only a paper, so I > don't know too much about it to comment. > I tried to find the code a couple of years ago, but no joy. And the timing suggested he may have started with/used V5, since the paper is dated June 75 and V6 was released in May 75. Warner A few years later (1980), Goble's work became the Purdue Vax [ > https://en.wikipedia.org/wiki/George_H._Goble] - which used a > master-slave configuration. He spliced a second 780 CPU onto the SMB and, > with some interesting work, allowed the second CPU to run user code. This > was extremely effective for their usage case -- timesharing of students. > If we don't have the code on TUHS, we should probably dig it up, as it was > widely distributed. The other thing he did was splice an 11/40 onto the UBA > of the same system for debugging - which was a pretty cool hack. He found > a couple of interesting BSD kernel issues, including a famous CVE using his > real-time monitor -- there is a USENIX paper on that tool that is work > checking out. > > The first commercial MP Unix was the Masscomp MC500/MP, which was > originally developed as Goble-style Master/Slave and released in RTU 2.0. > A year later, with RTU 3.0 and the release of the MC5000 family, it was > fully SMP. > > After that, several SMP UNIX started to appear. Each uses its own lock > scheme. If you are interested, I recommend getting a copy of Schimmel's > book: 'Unix on Modern Processors' which discusses many (most) of the > challenges. > > > ᐧ > > On Mon, Nov 28, 2022 at 8:25 AM Paul Ruizendaal wrote: > >> The discussion about the 3B2 triggered another question in my head: what >> were the earliest multi-processor versions of Unix and how did they relate? >> >> My current understanding is that the earliest one is a dual-CPU VAX >> system with a modified 4BSD done at Purdue. This would have been late 1981, >> early 1982. I think one CPU was acting as master and had exclusive kernel >> access, the other CPU would only run user mode code. >> >> Then I understand that Keith Kelleman spent a lot of effort to make Unix >> run on the 3B2 in a SMP setup, essentially going through the source and >> finding all critical sections and surrounding those with spinlocks. This >> would be around 1983, and became part of SVr3. I suppose that the “spl()” >> calls only protected critical sections that were shared between the main >> thread and interrupt sequences, so that a manual review was necessary to >> consider each kernel data structure for parallel access issues in the case >> of 2 CPU’s. >> >> Any other notable work in this area prior to 1985? >> >> How was the SMP implementation in SVr3 judged back in its day? >> >> Paul > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Tue Nov 29 00:19:03 2022 From: imp at bsdimp.com (Warner Losh) Date: Mon, 28 Nov 2022 07:19:03 -0700 Subject: [TUHS] Early multiprocessor Unix In-Reply-To: References: <7C8CADAB-65AA-4841-AFA1-569A9651E56D@planet.nl> Message-ID: On Mon, Nov 28, 2022, 7:15 AM Clem Cole wrote: > Paul, the other thing I should point out -- ghg's work was > widely distributed amount the BSD licenses. I somewhat wonder why the Naval > Post Grad school's work was not. My guess is that USENIX was still in its > formative stages when the latter did their work, whereas, by the time of > George's hack, BSD/Vaxen was being used for teaching as University > timesharing systems so his 'upgrade' was a cheap solution. > ᐧ > I know the Perdue work on Kirk's DVD collection.... Warner Warner On Mon, Nov 28, 2022 at 9:05 AM Clem Cole wrote: > >> As far as I know, the first non-commercial work was done at the Naval >> Post Grad school with V6. I have never seen the code for it, only a paper, >> so I don't know too much about it to comment. >> >> A few years later (1980), Goble's work became the Purdue Vax [ >> https://en.wikipedia.org/wiki/George_H._Goble] - which used a >> master-slave configuration. He spliced a second 780 CPU onto the SMB and, >> with some interesting work, allowed the second CPU to run user code. This >> was extremely effective for their usage case -- timesharing of students. >> If we don't have the code on TUHS, we should probably dig it up, as it was >> widely distributed. The other thing he did was splice an 11/40 onto the UBA >> of the same system for debugging - which was a pretty cool hack. He found >> a couple of interesting BSD kernel issues, including a famous CVE using his >> real-time monitor -- there is a USENIX paper on that tool that is work >> checking out. >> >> The first commercial MP Unix was the Masscomp MC500/MP, which was >> originally developed as Goble-style Master/Slave and released in RTU 2.0. >> A year later, with RTU 3.0 and the release of the MC5000 family, it was >> fully SMP. >> >> After that, several SMP UNIX started to appear. Each uses its own lock >> scheme. If you are interested, I recommend getting a copy of Schimmel's >> book: 'Unix on Modern Processors' which discusses many (most) of the >> challenges. >> >> >> ᐧ >> >> On Mon, Nov 28, 2022 at 8:25 AM Paul Ruizendaal wrote: >> >>> The discussion about the 3B2 triggered another question in my head: what >>> were the earliest multi-processor versions of Unix and how did they relate? >>> >>> My current understanding is that the earliest one is a dual-CPU VAX >>> system with a modified 4BSD done at Purdue. This would have been late 1981, >>> early 1982. I think one CPU was acting as master and had exclusive kernel >>> access, the other CPU would only run user mode code. >>> >>> Then I understand that Keith Kelleman spent a lot of effort to make Unix >>> run on the 3B2 in a SMP setup, essentially going through the source and >>> finding all critical sections and surrounding those with spinlocks. This >>> would be around 1983, and became part of SVr3. I suppose that the “spl()” >>> calls only protected critical sections that were shared between the main >>> thread and interrupt sequences, so that a manual review was necessary to >>> consider each kernel data structure for parallel access issues in the case >>> of 2 CPU’s. >>> >>> Any other notable work in this area prior to 1985? >>> >>> How was the SMP implementation in SVr3 judged back in its day? >>> >>> Paul >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Tue Nov 29 00:50:33 2022 From: clemc at ccc.com (Clem Cole) Date: Mon, 28 Nov 2022 09:50:33 -0500 Subject: [TUHS] Early multiprocessor Unix In-Reply-To: References: <7C8CADAB-65AA-4841-AFA1-569A9651E56D@planet.nl> Message-ID: On Mon, Nov 28, 2022 at 9:16 AM Warner Losh wrote: > > > On Mon, Nov 28, 2022, 7:07 AM Clem Cole wrote: > >> As far as I know, the first non-commercial work was done at the Naval >> Post Grad school with V6. I have never seen the code for it, only a paper, >> so I don't know too much about it to comment. >> > > I tried to find the code a couple of years ago, but no joy. And the timing > suggested he may have started with/used V5, since the paper is dated June > 75 and V6 was released in May 75. > Thanks - that makes sense. As I said, I never saw the code, and again, it agrees with my observation that this was 'pre-USENIX,' particularly since I believe that those folks are in CA and the original USENIX people were in NYC and Boston folks, so they would have been less likely to be a part. ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.winalski at gmail.com Tue Nov 29 02:30:25 2022 From: paul.winalski at gmail.com (Paul Winalski) Date: Mon, 28 Nov 2022 11:30:25 -0500 Subject: [TUHS] Early multiprocessor Unix In-Reply-To: References: <7C8CADAB-65AA-4841-AFA1-569A9651E56D@planet.nl> Message-ID: On 11/28/22, Clem Cole wrote: > > A few years later (1980), Goble's work became the Purdue Vax [ > https://en.wikipedia.org/wiki/George_H._Goble] - which used a master-slave > configuration. He spliced a second 780 CPU onto the SMB SBI (Synchronous Backplane Interconnect), the data bus for the 11/780. The KA780 CPU plugged into it, as did the memory controller, the UBA (UNIBUS adapter), the MBA (MASSBUS adapter), and the CI (Computer Interconnect, the high-speed network used for VAXcluster communication). > and, with some > interesting work, allowed the second CPU to run user code. This was > extremely effective for their usage case -- timesharing of students. Normally only one KA780 CPU was attached to the SBI, but there was nothing physical or electronic to prevent plugging in a second one. IIRC there were a couple of places in the 11/780 microcode that assumed there was only one CPU on the SBI, but that was easily tweaked. DEC productized the two-processor asymmetric multiprocessor configuration as the VAX-11/782. The software development tools group that I worked in was one of the two beta test sites for the 782 (the other was MIT). I was the system manager for that machine. Ours ran VMS, of course, not Unix, but with the same idea that only user mode code was scheduled to run on the second processor. All I/O and kernel mode code was done on the primary. It scaled pretty well for compute-intensive loads. It actually ran slower than a single processor under high I/O loads, though, and it gave no advantage to real-time workloads. I don't know if Ultrix ever supported the 11/782. The product had a rather short lifetime, as it was soon superseded by VAX models that were designed for symmetric multiprocessing from the ground up, and full SMP support had been implemented in VMS and Ultrix. -Paul W. From athornton at gmail.com Tue Nov 29 02:42:26 2022 From: athornton at gmail.com (Adam Thornton) Date: Mon, 28 Nov 2022 09:42:26 -0700 Subject: [TUHS] Fred Brooks died In-Reply-To: References: <202211272100.2ARL00ua032601@freefriends.org> Message-ID: <67054FFB-258B-48BA-AE2D-0B86002B7AD3@gmail.com> > On Nov 28, 2022, at 4:39 AM, Marc Donner wrote: > > In 1980 I applied to grad schools, including UNC. I had read "The Mythical Man-Month" by then, so I was floored one day sitting in my office when the phone rang and I heard, "This is Fred Brooks." I visited UNC where I saw the famous row of clocks that Steve Bellovin mentions in his memorial post. The only direct interaction I ever had with him, alas, is that he politely declined to come address the Engineering Problem Solving class I was teaching at Duke's TIP one summer. Adam -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Tue Nov 29 02:49:57 2022 From: clemc at ccc.com (Clem Cole) Date: Mon, 28 Nov 2022 11:49:57 -0500 Subject: [TUHS] Early multiprocessor Unix In-Reply-To: References: <7C8CADAB-65AA-4841-AFA1-569A9651E56D@planet.nl> Message-ID: On Mon, Nov 28, 2022 at 11:30 AM Paul Winalski wrote: > > configuration. He spliced a second 780 CPU onto the SMB > > SBI (Synchronous Backplane Interconnect), > right SBI -- thanks, Paul -- too many TLAs - bad cache refill. > > I don't know if Ultrix ever supported the 11/782. > no - the Ultrix group never bothered. ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jsg at jsg.id.au Tue Nov 29 02:52:17 2022 From: jsg at jsg.id.au (Jonathan Gray) Date: Tue, 29 Nov 2022 03:52:17 +1100 Subject: [TUHS] Early multiprocessor Unix In-Reply-To: <7C8CADAB-65AA-4841-AFA1-569A9651E56D@planet.nl> References: <7C8CADAB-65AA-4841-AFA1-569A9651E56D@planet.nl> Message-ID: On Mon, Nov 28, 2022 at 02:24:52PM +0100, Paul Ruizendaal wrote: > The discussion about the 3B2 triggered another question in my head: what were the earliest multi-processor versions of Unix and how did they relate? > > My current understanding is that the earliest one is a dual-CPU VAX system with a modified 4BSD done at Purdue. This would have been late 1981, early 1982. I think one CPU was acting as master and had exclusive kernel access, the other CPU would only run user mode code. > > Then I understand that Keith Kelleman spent a lot of effort to make Unix run on the 3B2 in a SMP setup, essentially going through the source and finding all critical sections and surrounding those with spinlocks. This would be around 1983, and became part of SVr3. I suppose that the “spl()” calls only protected critical sections that were shared between the main thread and interrupt sequences, so that a manual review was necessary to consider each kernel data structure for parallel access issues in the case of 2 CPU’s. > > Any other notable work in this area prior to 1985? HP-UX on FOCUS/series 500? https://www.openpa.net/systems/hp-9000_520.html https://www.tuhs.org/Archive/Documentation/AUUGN/AUUGN-V05.3.pdf Jeff Lindberg A Layered Implementation of the UNIX Kernel on the HP9000 Series 500 Computer "The HP9000 Series 500 computers are based on a proprietary 32 bit microprocessor chip set with stack architecture. It has user-transparent multi-CPU support, for which they included semaphores and a very carefully worked out scheduler. HP-UX is based on top of an operating system called SUN (no relation to Sun Microsystems Inc.). The SUN operating system was intended to be a modern operating system to support HP's desktop BASIC system. As designed, though, it turns out to be language independent, and had several other features that made it attractive as a base upon which to build a UNIX implementation." https://archive.org/details/1983-proceedings-unicom-san-diego/page/119/mode/2up Frederick W. Clegg Hewlett-Packard’s Entry into the UNIX Community "Several motivations prompted this somewhat unconventional implementation of the HP-UX kernel on the HP 9000. It should be understood that much of the low- level, machine-dependent software for the HP 9000 was complete before a final commitment was made to offer UNIX on this product line. Thus reinvention of device and interface drivers, low-level memory management routines, power-up code, and architecturally-dependent utility routines was avoided by this approach. Additionally, this approach permitted leverage of software developed to support graphics and database management from the BASIC environment. Additionally, SUN has a number of features which are not present in AT&T UNIX. These provide opportunities for HP-UX to make a contribution above and beyond other UNIX implementations. Such features include real-time performance in the area of interrupt response time and process switching, support for multiple processors, and reliability in the face of system errors." some more details in https://www.hpl.hp.com/hpjournal/pdfs/IssuePDFs/1984-03.pdf HP Journal, March 1984, Volume 35, Number 3 From wlc at jctaylor.com Tue Nov 29 04:53:12 2022 From: wlc at jctaylor.com (William Corcoran) Date: Mon, 28 Nov 2022 18:53:12 +0000 Subject: [TUHS] Reaction to the 3B2 at Bell Labs In-Reply-To: References: <8f278bf8-de57-4e77-a3b8-d007d7c3a446@app.fastmail.com> <20221126191827.GV18011@mcvoy.com> <764dda08-f358-4c74-8056-ef8fc80bcaac@app.fastmail.com> <20221126232323.GX18011@mcvoy.com> <20221127001714.GY18011@mcvoy.com> <202211270443.2AR4hofO067295@ultimate.com> Message-ID: <0EB50C1F-D226-40BF-8F42-43CB988B036E@jctaylor.com> I have a 3b2/300. Anytime you run a command that is compute bound, like factoring a large prime number, the CPU buzzes! Bill Corcoran On Nov 27, 2022, at 9:52 AM, John P. Linderman wrote:  [EXTERNAL] We were "gifted" a 3B2, as in "take this and use it!". I ran a "ps" command in single user mode, and it took 20 seconds to run. Our machine names were themed around bird names, so we christened the 3B2 "junco". Our director said we had to get along, so we renamed it "jay". But everyone knew what the J stood for. The 3B2 served as a doorstop. On Sat, Nov 26, 2022 at 11:44 PM Phil Budne > wrote: Larry McVoy wrote: > I read the Wikipedia page on the 9000. It's sad that the 9000 > wasn't cancelled when they had better alternatives. In an oral history Bob Supnik described Ken Olsen couldn't get his head around the fact that the NVAX chip could equal the 9000: @2:59:45 in https://www.youtube.com/watch?v=T3tcCBHRIfU In part 2, Bob described how then DEC VP Gordon Bell having earlier predicted when the microprocessor performance curve would cross over minis and mainframes: @1:51:45 in https://www.youtube.com/watch?v=T3tcCBHRIfU He also talks about how the company couldn't command the bsame gross margins as it did in the VAX era. THIS IS AN EXTERNAL EMAIL -- This email was sent from someone OUTSIDE of the NSM Insurance Group email system. PLEASE USE CAUTION WHEN REVIEWING THIS EMAIL. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kennethgoodwin56 at gmail.com Tue Nov 29 06:59:50 2022 From: kennethgoodwin56 at gmail.com (Kenneth Goodwin) Date: Mon, 28 Nov 2022 15:59:50 -0500 Subject: [TUHS] Reaction to the 3B2 at Bell Labs In-Reply-To: <0EB50C1F-D226-40BF-8F42-43CB988B036E@jctaylor.com> References: <8f278bf8-de57-4e77-a3b8-d007d7c3a446@app.fastmail.com> <20221126191827.GV18011@mcvoy.com> <764dda08-f358-4c74-8056-ef8fc80bcaac@app.fastmail.com> <20221126232323.GX18011@mcvoy.com> <20221127001714.GY18011@mcvoy.com> <202211270443.2AR4hofO067295@ultimate.com> <0EB50C1F-D226-40BF-8F42-43CB988B036E@jctaylor.com> Message-ID: That must be the 300 B superhive model CPU On Mon, Nov 28, 2022, 1:54 PM William Corcoran wrote: > I have a 3b2/300. Anytime you run a command that is compute bound, like > factoring a large prime number, the CPU buzzes! > > > > Bill Corcoran > > > > > > On Nov 27, 2022, at 9:52 AM, John P. Linderman wrote: > >  > > [EXTERNAL] > > > We were "gifted" a 3B2, as in "take this and use it!". I ran a "ps" > command in single user mode, and it took 20 seconds to run. > Our machine names were themed around bird names, so we christened the 3B2 > "junco". Our director said we had to get along, > so we renamed it "jay". But everyone knew what the J stood for. The 3B2 > served as a doorstop. > > On Sat, Nov 26, 2022 at 11:44 PM Phil Budne wrote: > >> Larry McVoy wrote: >> > I read the Wikipedia page on the 9000. It's sad that the 9000 >> > wasn't cancelled when they had better alternatives. >> >> In an oral history Bob Supnik described Ken Olsen couldn't get his >> head around the fact that the NVAX chip could equal the 9000: >> >> @2:59:45 in https://www.youtube.com/watch?v=T3tcCBHRIfU >> >> In part 2, Bob described how then DEC VP Gordon Bell having earlier >> predicted when the microprocessor performance curve would cross over >> minis and mainframes: >> >> @1:51:45 in https://www.youtube.com/watch?v=T3tcCBHRIfU >> >> He also talks about how the company couldn't command the bsame gross >> margins as it did in the VAX era. >> > > > THIS IS AN EXTERNAL EMAIL -- This email was sent from someone OUTSIDE of > the NSM Insurance Group email system. PLEASE USE CAUTION WHEN REVIEWING > THIS EMAIL. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rminnich at gmail.com Tue Nov 29 08:33:12 2022 From: rminnich at gmail.com (ron minnich) Date: Mon, 28 Nov 2022 14:33:12 -0800 Subject: [TUHS] Reaction to the 3B2 at Bell Labs In-Reply-To: References: <8f278bf8-de57-4e77-a3b8-d007d7c3a446@app.fastmail.com> <20221126191827.GV18011@mcvoy.com> <764dda08-f358-4c74-8056-ef8fc80bcaac@app.fastmail.com> <20221126232323.GX18011@mcvoy.com> <20221127001714.GY18011@mcvoy.com> <202211270443.2AR4hofO067295@ultimate.com> <0EB50C1F-D226-40BF-8F42-43CB988B036E@jctaylor.com> Message-ID: I was visiting Holmdel in 1981, and there was a tradeshow for the BellMAC CPUs there, filling ground floor of the central atrium. There was some swag, which I had for a few years, including refrigerator magnets. The one I remember: "Don't be alone, call MACphone!" I remember reading an article in the early 80s pointing out that, due to the scale of the Bell System, the center of the universe of semiconductor fabrication at that time was ... Allentown, PA. Western Electric had an ad, along the lines of, "who will create the 256 Kb memory part? WE will" -- WE as in Western Electric.Those parts would have been fabbed in Allentown IIRC. It is a bit hard to recall, much less believe. but PA, land of dead still mills, the Molly Maguires, and underground coal mine fires that will burn for centuries, also had silicon. On Mon, Nov 28, 2022 at 1:01 PM Kenneth Goodwin wrote: > That must be the 300 B superhive model CPU > > On Mon, Nov 28, 2022, 1:54 PM William Corcoran wrote: > >> I have a 3b2/300. Anytime you run a command that is compute bound, like >> factoring a large prime number, the CPU buzzes! >> >> >> >> Bill Corcoran >> >> >> >> >> >> On Nov 27, 2022, at 9:52 AM, John P. Linderman wrote: >> >>  >> >> [EXTERNAL] >> >> >> We were "gifted" a 3B2, as in "take this and use it!". I ran a "ps" >> command in single user mode, and it took 20 seconds to run. >> Our machine names were themed around bird names, so we christened the 3B2 >> "junco". Our director said we had to get along, >> so we renamed it "jay". But everyone knew what the J stood for. The 3B2 >> served as a doorstop. >> >> On Sat, Nov 26, 2022 at 11:44 PM Phil Budne wrote: >> >>> Larry McVoy wrote: >>> > I read the Wikipedia page on the 9000. It's sad that the 9000 >>> > wasn't cancelled when they had better alternatives. >>> >>> In an oral history Bob Supnik described Ken Olsen couldn't get his >>> head around the fact that the NVAX chip could equal the 9000: >>> >>> @2:59:45 in https://www.youtube.com/watch?v=T3tcCBHRIfU >>> >>> In part 2, Bob described how then DEC VP Gordon Bell having earlier >>> predicted when the microprocessor performance curve would cross over >>> minis and mainframes: >>> >>> @1:51:45 in https://www.youtube.com/watch?v=T3tcCBHRIfU >>> >>> He also talks about how the company couldn't command the bsame gross >>> margins as it did in the VAX era. >>> >> >> >> THIS IS AN EXTERNAL EMAIL -- This email was sent from someone OUTSIDE of >> the NSM Insurance Group email system. PLEASE USE CAUTION WHEN REVIEWING >> THIS EMAIL. >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.donner at gmail.com Tue Nov 29 08:43:30 2022 From: marc.donner at gmail.com (Marc Donner) Date: Mon, 28 Nov 2022 17:43:30 -0500 Subject: [TUHS] Reaction to the 3B2 at Bell Labs In-Reply-To: References: <8f278bf8-de57-4e77-a3b8-d007d7c3a446@app.fastmail.com> <20221126191827.GV18011@mcvoy.com> <764dda08-f358-4c74-8056-ef8fc80bcaac@app.fastmail.com> <20221126232323.GX18011@mcvoy.com> <20221127001714.GY18011@mcvoy.com> <202211270443.2AR4hofO067295@ultimate.com> <0EB50C1F-D226-40BF-8F42-43CB988B036E@jctaylor.com> Message-ID: IBM built a major semiconductor fab up in Fishkill, NY. About two hours drive north of NYC. At one point (mid-1980s) it was the biggest fab in the world according to some metric. On Mon, Nov 28, 2022, 17:35 ron minnich wrote: > I was visiting Holmdel in 1981, and there was a tradeshow for the BellMAC > CPUs there, filling ground floor of the central atrium. There was some > swag, which I had for a few years, including refrigerator magnets. The one > I remember: > "Don't be alone, call MACphone!" > > I remember reading an article in the early 80s pointing out that, due to > the scale of the Bell System, the center of the universe of semiconductor > fabrication at that time was ... Allentown, PA. Western Electric had an ad, > along the lines of, "who will create the 256 Kb memory part? WE will" -- WE > as in Western Electric.Those parts would have been fabbed in Allentown > IIRC. > > It is a bit hard to recall, much less believe. but PA, land of dead still > mills, the Molly Maguires, and underground coal mine fires that will burn > for centuries, also had silicon. > > > > > On Mon, Nov 28, 2022 at 1:01 PM Kenneth Goodwin < > kennethgoodwin56 at gmail.com> wrote: > >> That must be the 300 B superhive model CPU >> >> On Mon, Nov 28, 2022, 1:54 PM William Corcoran wrote: >> >>> I have a 3b2/300. Anytime you run a command that is compute bound, like >>> factoring a large prime number, the CPU buzzes! >>> >>> >>> >>> Bill Corcoran >>> >>> >>> >>> >>> >>> On Nov 27, 2022, at 9:52 AM, John P. Linderman >>> wrote: >>> >>>  >>> >>> [EXTERNAL] >>> >>> >>> We were "gifted" a 3B2, as in "take this and use it!". I ran a "ps" >>> command in single user mode, and it took 20 seconds to run. >>> Our machine names were themed around bird names, so we christened the >>> 3B2 "junco". Our director said we had to get along, >>> so we renamed it "jay". But everyone knew what the J stood for. The 3B2 >>> served as a doorstop. >>> >>> On Sat, Nov 26, 2022 at 11:44 PM Phil Budne wrote: >>> >>>> Larry McVoy wrote: >>>> > I read the Wikipedia page on the 9000. It's sad that the 9000 >>>> > wasn't cancelled when they had better alternatives. >>>> >>>> In an oral history Bob Supnik described Ken Olsen couldn't get his >>>> head around the fact that the NVAX chip could equal the 9000: >>>> >>>> @2:59:45 in https://www.youtube.com/watch?v=T3tcCBHRIfU >>>> >>>> In part 2, Bob described how then DEC VP Gordon Bell having earlier >>>> predicted when the microprocessor performance curve would cross over >>>> minis and mainframes: >>>> >>>> @1:51:45 in https://www.youtube.com/watch?v=T3tcCBHRIfU >>>> >>>> He also talks about how the company couldn't command the bsame gross >>>> margins as it did in the VAX era. >>>> >>> >>> >>> THIS IS AN EXTERNAL EMAIL -- This email was sent from someone OUTSIDE of >>> the NSM Insurance Group email system. PLEASE USE CAUTION WHEN REVIEWING >>> THIS EMAIL. >>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From alanglasser at gmail.com Tue Nov 29 11:49:23 2022 From: alanglasser at gmail.com (Alan Glasser) Date: Mon, 28 Nov 2022 20:49:23 -0500 Subject: [TUHS] Reaction to the 3B2 at Bell Labs In-Reply-To: References: <8f278bf8-de57-4e77-a3b8-d007d7c3a446@app.fastmail.com> <20221126191827.GV18011@mcvoy.com> <764dda08-f358-4c74-8056-ef8fc80bcaac@app.fastmail.com> <20221126232323.GX18011@mcvoy.com> <20221127001714.GY18011@mcvoy.com> <202211270443.2AR4hofO067295@ultimate.com> <0EB50C1F-D226-40BF-8F42-43CB988B036E@jctaylor.com> Message-ID: A few 3B2 stories... In the late 1970's there were no 3B2's (yet), but there was the MAC 8 processor. The name "MAC 8" was problematic to me and my coworkers: it stood for Microprocessor Advisory Committee. It was a processor designed by a committee! It was slow and more problematically, it was not hardware compatible with Intel 8080 support chips. I don't remember all of the details but it was an edge versus level set of problems. It was fun to program. There was an evaluation box (called a MacTutor) that you connected to an RS-232 line to connect it with a PDP-11 UNIX system for cross-assembly/cross-compiling (the assembler language was as close to C as an assembler language could get). The MacTutor was a fun toy. The MAC 8 in production hardware (at least in Holmdel) was a disaster. See https://archive.org/details/bitsavers_westernEleC8TUTORJul79_3968770/mode/2up In the early 1980's, I was a Bell Labs technical supervisor in a number of different development (in contrast to research) organizations. There was considerable pressure on my management (and me) to utilize 3B2's instead of DEC hardware; a little later (about 1986) there was pressure to use 6300's and later 6386's (which ran UNIX). My first experience with an original 3B2 (one without a model number) was identical to that of John P Linderman's. Compiling a modest C program took forever. A little later they gave that one a model number of 300 and came out with a 400, which was almost reasonable and a 310 which, I believe, had the same processor and clock as a 400 with less expansion slots. Later came the 600 and 700, which were pretty reasonable and we used them for a number of products (DEFINITY Manager 3 for administering a large PBX was one I brought to market with my team). In October, 1996 I was promoted to development department head of Global Messaging Services (GMS) which was better known as AT&T Mail. It was a hectic time to be joining the organization as the job I took had been being filled temporarily by another person (who was a friend of mine and, like me, was new to the organization) and they were in the final throes of development of a significant new release, about to go into system test (in another department). One of the first things I learned is that the service ran on many 3b2/600's mostly in two locations in the US, but had many small worldwide locations (Hong Kong, Tokyo, Sydney, Tel Aviv, London, Moscow, and some others I don't remember) all connected by DataKit. The US systems had been running for many years and could not be powered off, because the disk drives would seize and not spin up due to an absence of lubricant (as I was told). This presented some challenges, as I liked to power cycle systems I worked on and could not do this here. The release was deployed on Valentine's Day, 1997. It was the worst deployment in the service's history. Most everything broke. System test hadn't found these very many latent bugs that were deployed. It was all hands on deck, working all hours 7x24 with two conference calls a day with the Operations organization (running the servers) and the Customer Care organization (fielding customer complaints) until things quieted down towards the end of March. It was then that I was able to pay more attention to future plans, which were to replace the 3B2's with Stratus hardware running their fault tolerant unix (FTX). We had a number of their dual processor systems in lab test and had just taken delivery of a four processor system, which is what my predecessor had specified for purchase to replace all of the US based 3B2's. A group of 3 engineers (one of whom I had hired in 1980) worked on running benchmarks of GMS workloads on the Stratus systems and working with Stratus engineers to get fixes to problems in their code when they arose. They presented the first set of quad processor benchmarks to me and they were all slower than the "twin" (or 2 processor) benchmarks. I requested daily updates on the status of this as it was bizarre and indeed a disaster for our plans. This culminated in my requesting that Stratus send a small group of their FTX engineers to my location for (what I called) a formal architecture review of the Quad and FTX. The review was scheduled for a week. After the first morning, I told them that they should go back to Stratus and that we'd be in touch. I wrote the following in an email to my boss, my product manager peer and a handful of others: Yesterday, 4/15/97, Stratus engineers from their hardware development, FTX (UNIX) development and performance and design groups met with members of GMS R&D and AT&T Labs to share information about the Stratus and GMS architectures. Executive summary: the Quad will never work for GMS. The Stratus 1225 (aka "Twin"), is a true SMP (symmetric multi-processor). The two CPUs each have a one megabyte instruction cache and a one megabyte data cache, and they both share a memory system of 512 megabytes. Cache coherency is maintained by a pair of custom chips (ASICs). When data is in a processor's cache, there is no contention possible. When data is in the memory system, there is an additional penalty of between 250-390 nanoseconds. Input and output take place on a slower bus. The Stratus 1245 (aka "Quad") consists of two twin boards that communicate via the I/O (i.e., slow) bus. This is not symmetric, hence not SMP. Each board contains 512MB of memory. All of the Unix kernel data resides on one board (the boot board). When a processor on the non-boot board needs to access memory on the boot board, the cost is 1700 nanoseconds (a penalty of 4.4 to 6.8 times worse). Since all Unix kernel data resides on the boot board, any software that makes significant use of Unix system calls (e.g., GMS) will pay a high penalty when running on the non-boot board. Further, if a program (e.g., the GMS User Agent) is simultaneously running on both boards, its instructions will reside in the memory of only one of the boards, thus incurring significant overhead to access instructions for some processes. It appears that the hardware designers never consulted with the Unix designers. They are located in different locations (Massachusetts and California), which can't help. They claim they've seen between 1.4 and 1.6 times improvement in going from Twin to Quad for other customers. They do note, however, that an optimal application for the Quad is one which needs to execute application user-mode instructions and make very few system calls (e.g., a graphics rendering application). GMS, in its current architecture, assumes free and easy access to system calls. GMS can never run well on a Quad. We should immediately abandon any efforts aimed at deploying Quads and focus all of our attention on extracting compensatory Twins from Stratus. Needless to say, we were able to get an appropriate number of Twins and retired all of our 3B2s. Alan On Mon, Nov 28, 2022 at 5:45 PM Marc Donner wrote: > IBM built a major semiconductor fab up in Fishkill, NY. About two hours > drive north of NYC. At one point (mid-1980s) it was the biggest fab in the > world according to some metric. > > On Mon, Nov 28, 2022, 17:35 ron minnich wrote: > >> I was visiting Holmdel in 1981, and there was a tradeshow for the BellMAC >> CPUs there, filling ground floor of the central atrium. There was some >> swag, which I had for a few years, including refrigerator magnets. The one >> I remember: >> "Don't be alone, call MACphone!" >> >> I remember reading an article in the early 80s pointing out that, due to >> the scale of the Bell System, the center of the universe of semiconductor >> fabrication at that time was ... Allentown, PA. Western Electric had an ad, >> along the lines of, "who will create the 256 Kb memory part? WE will" -- WE >> as in Western Electric.Those parts would have been fabbed in Allentown >> IIRC. >> >> It is a bit hard to recall, much less believe. but PA, land of dead >> still mills, the Molly Maguires, and underground coal mine fires that will >> burn for centuries, also had silicon. >> >> >> >> >> On Mon, Nov 28, 2022 at 1:01 PM Kenneth Goodwin < >> kennethgoodwin56 at gmail.com> wrote: >> >>> That must be the 300 B superhive model CPU >>> >>> On Mon, Nov 28, 2022, 1:54 PM William Corcoran wrote: >>> >>>> I have a 3b2/300. Anytime you run a command that is compute bound, >>>> like factoring a large prime number, the CPU buzzes! >>>> >>>> >>>> >>>> Bill Corcoran >>>> >>>> >>>> >>>> >>>> >>>> On Nov 27, 2022, at 9:52 AM, John P. Linderman >>>> wrote: >>>> >>>>  >>>> >>>> [EXTERNAL] >>>> >>>> >>>> We were "gifted" a 3B2, as in "take this and use it!". I ran a "ps" >>>> command in single user mode, and it took 20 seconds to run. >>>> Our machine names were themed around bird names, so we christened the >>>> 3B2 "junco". Our director said we had to get along, >>>> so we renamed it "jay". But everyone knew what the J stood for. The 3B2 >>>> served as a doorstop. >>>> >>>> On Sat, Nov 26, 2022 at 11:44 PM Phil Budne wrote: >>>> >>>>> Larry McVoy wrote: >>>>> > I read the Wikipedia page on the 9000. It's sad that the 9000 >>>>> > wasn't cancelled when they had better alternatives. >>>>> >>>>> In an oral history Bob Supnik described Ken Olsen couldn't get his >>>>> head around the fact that the NVAX chip could equal the 9000: >>>>> >>>>> @2:59:45 in https://www.youtube.com/watch?v=T3tcCBHRIfU >>>>> >>>>> In part 2, Bob described how then DEC VP Gordon Bell having earlier >>>>> predicted when the microprocessor performance curve would cross over >>>>> minis and mainframes: >>>>> >>>>> @1:51:45 in https://www.youtube.com/watch?v=T3tcCBHRIfU >>>>> >>>>> He also talks about how the company couldn't command the bsame gross >>>>> margins as it did in the VAX era. >>>>> >>>> >>>> >>>> THIS IS AN EXTERNAL EMAIL -- This email was sent from someone OUTSIDE >>>> of the NSM Insurance Group email system. PLEASE USE CAUTION WHEN REVIEWING >>>> THIS EMAIL. >>>> >>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From joseph at josephholsten.com Tue Nov 29 17:31:15 2022 From: joseph at josephholsten.com (Joseph Holsten) Date: Mon, 28 Nov 2022 23:31:15 -0800 Subject: [TUHS] Re.: Princeton's "Unix: An Oral History": who was in the team in "The Attic"? In-Reply-To: <202210120659.29C6xDvY007440@freefriends.org> References: <992562BA-E21F-4542-A50B-6CFE8F7ACE86@planet.nl> <20221011134842.GA11780@mcvoy.com> <20221011195447.GI11780@mcvoy.com> <8583490b-c7cc-4633-b506-2f16335fd3e2@home.arpa> <202210120659.29C6xDvY007440@freefriends.org> Message-ID: <04c68d82-1ed1-4958-9c46-067400e3b7cd@app.fastmail.com> On Tue, Oct 11, 2022, at 23:59, arnold at skeeve.com wrote: > Rob Pike wrote: > >> I think it is (used to be?) a common pattern. > > Clearly, the metric in both cases should have been the absolute > value of the number of lines of code changed... > > Both stories are rather sad; one hopes that today's world is > a better place. I do hope the anecdotes of twitter’s firings based on LoC end up being mistaken. But I’m also reading Machiavelli’s Discourses on Livy while catching up on TUHS, I’m not sure I believe in better places any more. And it reminds me of the Pascal quote, “I have made this longer than usual because I have not had time to make it shorter.” https://quoteinvestigator.com/2012/04/28/shorter-letter/ -- Joseph Holsten From jsg at jsg.id.au Tue Nov 29 19:39:47 2022 From: jsg at jsg.id.au (Jonathan Gray) Date: Tue, 29 Nov 2022 20:39:47 +1100 Subject: [TUHS] Early multiprocessor Unix In-Reply-To: <7C8CADAB-65AA-4841-AFA1-569A9651E56D@planet.nl> References: <7C8CADAB-65AA-4841-AFA1-569A9651E56D@planet.nl> Message-ID: On Mon, Nov 28, 2022 at 02:24:52PM +0100, Paul Ruizendaal wrote: > The discussion about the 3B2 triggered another question in my head: what were the earliest multi-processor versions of Unix and how did they relate? > > My current understanding is that the earliest one is a dual-CPU VAX system with a modified 4BSD done at Purdue. This would have been late 1981, early 1982. I think one CPU was acting as master and had exclusive kernel access, the other CPU would only run user mode code. > > Then I understand that Keith Kelleman spent a lot of effort to make Unix run on the 3B2 in a SMP setup, essentially going through the source and finding all critical sections and surrounding those with spinlocks. This would be around 1983, and became part of SVr3. I suppose that the “spl()” calls only protected critical sections that were shared between the main thread and interrupt sequences, so that a manual review was necessary to consider each kernel data structure for parallel access issues in the case of 2 CPU’s. > > Any other notable work in this area prior to 1985? Sequent Balance 8000 from 1984 had up to 12 National NS32000 processors and ran the 4.2BSD derived DYNIX. Bob Beck, Bob Kasten VLSI Assist in Building a Multiprocessor UNIX System USENIX 1985 Summer Conference Proceedings https://archive.org/details/1985-proceedings-summer-portland/page/254/mode/2up National had their own 4.1BSD derived GENIX. I can't find any references to it running on multiprocessor machines. Gould PowerNode 9080, a dual processor machine was announced in 1984 and ran a 4.2BSD derived UTX/32. https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=1659257 Pyramid Technology, 90Mx dual processor early 1985, 98x late 1985 https://archive.org/details/sim_systems-software_1985-02_4_2/page/n37/mode/2up Systems & Software 1985-02: Vol 4 Iss 2 "The new 90Mx, the first dual-processor machine from Pyramid, can support up to 256 users. It has a maximum of 32 megabytes of main memory, and comes in one single-cabinet and three dual-cabinet configurations. The 90x, first shipped in October 1983, is limited to 128 users and 16 megabyte of main memory as a single processor machine. Like the 90x, the 90Mx uses the reduced instruction set computer architecture (RISC)." "OSx is Pyramid's dual-port, multi-processor implementation of Unix System V from AT&T and 4.2BSD from the University of California, Berkeley." https://archive.org/details/Unix_Review_1985_Aug.pdf/page/n9/mode/2up Unix Review Magazine Aug 1985 "One of the more impressive machines making its debut at the National Computer Conference in Chicago July 16 was Pyramid Technology Corp’s 98x, a super minicomputer built with the idea of equal opportunity for equal microprocessors. Pyramid calls the 98x an "isoprocessor" system; there are two 32-bit RISC (reduced instruction set computer) processors working as equal partners." "The idea behind isoprocessing comes from Purdue’s dual processor implementation, Krahling said. CPU balance is achieved through the use of a proprietary semaphore system that protects critical sequences of code and controls simultaneous access to kernel data structures." "90Mx has a master-slave multiprocessor environment." From alan at alanlee.org Tue Nov 29 21:33:19 2022 From: alan at alanlee.org (alan at alanlee.org) Date: Tue, 29 Nov 2022 06:33:19 -0500 Subject: [TUHS] Reaction to the 3B2 at Bell Labs In-Reply-To: <8f278bf8-de57-4e77-a3b8-d007d7c3a446@app.fastmail.com> References: <8f278bf8-de57-4e77-a3b8-d007d7c3a446@app.fastmail.com> Message-ID: It would be nice to get more technical information on the 3B2s. As late as 2016, I had reached out to Ed Eckart the archivist at Alcatel-Lucent and Seth had contacted William Caughlin at AT&T archives for more information. Both seemed to indicate the systems were still in use at some customer sites and thus detailed technical info (eg. schematics, theory of operation docs, etc) could not be shared with the public. But that sort of information was preserved and safe. If anyone has contacts into either organization, a gentile nudge would be appreciated! :) -Alan On 2022-11-26 13:46, Seth Morabito wrote: > Hello all, > > I'm giving a presentation on the AT&T 3B2 at a local makerspace next > month, and while I've been preparing the talk I became curious about > an aspect that I don't know has been discussed elsewhere. > > I'm well aware that the 3B2 was something of a market failure with not > much penetration into the wider commercial UNIX space, but I'm very > curious to know more about what the reaction was at Bell Labs. When > AT&T entered the computer hardware market after the 1984 breakup, I > get the impression that there wasn't very much interest in any of it > at Bell Labs, is that true? > > Can anyone recall what the general mood was regarding the 3B2 (and the > 7300 and the 6300, I suppose!) > > -Seth From ron at ronnatalie.com Wed Nov 30 01:54:45 2022 From: ron at ronnatalie.com (Ron Natalie) Date: Tue, 29 Nov 2022 15:54:45 +0000 Subject: [TUHS] First supercomputer UNIX: The Denelcor HEP (was Early multiprocessor Unix) In-Reply-To: References: <7C8CADAB-65AA-4841-AFA1-569A9651E56D@planet.nl> Message-ID: In 1982, I returned to BRL (having spent a year working for Martin Marietta on project involving a dual process RSX-11M system. I did spend some time setting up the PWB UNIX tools with the QA guys while there). BRL had commissioned the Denver Electronics Corporation (i.e., Denelcor) to build a MIMD system called the HEP, ostensibly to do fluid dynamics problems. It was looking like the manufacturer wasn’t going to have a useful OS for it so Mike Muss did his usual thing and suggested he could put UNIX on it (he had done this twice previously with orphaned machines: some 11/34 graphics stations that were supposed to be connected to the CDC7600 and converting the University of Illinois Arpanet Terminal Server (ANTS) to a host that could support long leaders. I was part of Mike’s team. We split up various aspects of the project. Mike ported PCC. I ported ld, and F77 (as we figured the “scientists” would probably want that). Mike did the core of the kernel. I handled all the I/O system because I was the “device driver” guy at JHU and continued on with this at BRL. Our initial work was done by traveling out to Denelcor’s facility where our machine was assembled on their floor. They had started their operating system work (not UNIX), so we took the machine after hours. Amusingly, at BRL in the room the HEP was going in, the cabinet layout was taped out on the floor around a central pillar. The tape marked with the component that went there. Out in the Denver machine room, the equipment was there but there was a square taped out that said “BRL post” so they knew not to put/route anything there. The software being ported was 4BSD. I believe we started with the George Gobels mods of the dual VAX (BRL already had built one of these). In working on that I found there was a rather serious portability problem. The kernel did what I refer to as “conversion by union” where they stuck a pointer of one type into one element of the union and retrieved it by a different pointer type union element. Well, such is all well and good on the VAX, but the HEP encoded the partial word size into the low order bits of the pointer. This meant that you ended up with pointers that would access the wrong size operand. I spent a few days chasing down all these things and fixing them. The HEP had an 11/34 as a control processor that allowed you to configure the switch system that interconnected the memory in the processors. It did this via a special feature called (aptly) “The Low Speed Bus” (more on that later). But once running, everything was self contained on the HEP hardware itself. Other amusing things about the HEP is it had a lot of registers. It also had this stuff called “table memory” which essentially were read-only registers. You could but a variety of constants there (we had all the integers from 0-255 and then powers of two after that). The rest of the memory had an extra bit per 64-bit word called the “full empty” bit. While the thing was capable of running the equivalent of 32 UNIX processes simultaneously, it also had the ability within each of those to hardware schedule threads. Many instructions had features that used the extra bit like “WAIT FULL, READ, SET EMPTY” or “WRITE, SET FULL”. The whole thing was built out of Motorola 10800 ECL. All hand assembled. Quite impressive. After we got the system up, and Mike tried to port his ray tracing software to it, we found the I/O system was beastly slow. The I/O system was a cute device. It had a bunch traditional memory (no full/empty bits) connected to the main memory via the switch but also to 32 individual UNIBUSes. The only problem was that in order to whack the registers on the UNIBUS you had to do it through the “Low Speed Bus.” This was the performance bottleneck. The original designer of this thing, Burton Smith and I sat down at the Golden Corral Steakhouse in Aberdeen and worked on a new plan. The key was to allow the kernel tasks to talk directly to the UNIBUS registers via the regular memory switch. Fortunately, we had an extra switch node in spare parts. We did however need software and another PDP-11 to control the thing. Fortunately, I had spares from my building of the early internet router: BRL-GATEWAY. I also used the little OS on it (LOS) to write the control software. In a couple of days, we had rebuilt the I/O system out of essentially spare parts and it flew. Amusingly, this was the first of two UNIX ports I worked on that didn’t use the standard ISR thing that most of the kernels those days did. After the device driver on the HEP had started the IO up, that thread just ended. When the UNIBUS interrupt came in, a new thread was created to service it. I later did a similar strategy with the message passing coprocessor on the Multibus II. This was a fun waste of about a year. By the time we got this ready for prime time, the Army had decided they didn’t have any supercomputers (other than HEP) and immediately used defense priority to snag the next Cray X/MP off the assembly line (which had been slated for Apple). Mike got one run of his raytracer to make a movie: The artillery shell’s view of collision with a tank. The HEP could generate the frames about 60:1 (took a minute to make one second of movie time) faster than anything else we had in the day. Of course, it pales compared to your modern video games. After that, the HEP was dismantled (Denelcor had gone out of business) to make room for the Cray. I recently just found pictures of us all sitting on the “seats” of the Cray and one of me peering out from the core of the machine. The Army went on for plans for multiple Cray 2 purchases. After a lot of amusing “systems engineering” work that originally slated for all of them to go in Oak Ridge Tennessee, and then all of them to go at BRL, they decided to spread them around the country (what I told them they should do in the first place). My last months at BRL, I signed my name to the $25 million dollar Cray 2 procurement, but it got delivered after I left (I visited it a few years later). Somewhere I still have the name plates for the Denelcor HEP H1000. They, in fact, were never actually installed on the machine, From jon at fourwinds.com Wed Nov 30 03:00:01 2022 From: jon at fourwinds.com (Jon Steinhart) Date: Tue, 29 Nov 2022 09:00:01 -0800 Subject: [TUHS] First supercomputer UNIX: The Denelcor HEP (was Early multiprocessor Unix) In-Reply-To: References: <7C8CADAB-65AA-4841-AFA1-569A9651E56D@planet.nl> Message-ID: <202211291700.2ATH01H82562743@darkstar.fourwinds.com> Ron Natalie writes: > > BRL had commissioned the Denver Electronics Corporation (i.e., Denelcor) > to build a MIMD system called the HEP, ostensibly to do fluid dynamics I remember the presentation on this at Usenix. My thought at the time was that the HEP was a lot like what I saw when people started selling their expensive California homes and moving to Oregon to spend that money on mini-mansions. Well, in California I could only afford two columns, one dormer, and a one-car garage but now I can have 8 columns, 6 dormers, a 10 car garage, and so on. I remember thinking at the time that the HEP seemed like every piece of available hardware at the time glommed together. I'm sure that more thought went in to it than that, but that was my impression at the time. Jon From sjenkin at canb.auug.org.au Wed Nov 30 06:53:52 2022 From: sjenkin at canb.auug.org.au (steve jenkin) Date: Wed, 30 Nov 2022 07:53:52 +1100 Subject: [TUHS] First supercomputer UNIX: The Denelcor HEP (was Early multiprocessor Unix) In-Reply-To: References: <7C8CADAB-65AA-4841-AFA1-569A9651E56D@planet.nl> Message-ID: <6B2EF7CF-5264-4B83-B69F-BC09256138EA@canb.auug.org.au> Bitsavers has some files on the HEP, if anyone is interested. The research papers are a collection of undated, probably published pieces. > On 30 Nov 2022, at 02:54, Ron Natalie wrote: > > BRL had commissioned the Denver Electronics Corporation (i.e., Denelcor) to build a MIMD system called the HEP, ostensibly to do fluid dynamics problems. It was looking like the manufacturer wasn’t going to have a useful OS for it so Mike Muss did his usual thing and suggested he could put UNIX on it (he had done this twice previously with orphaned machines: some 11/34 graphics stations that were supposed to be connected to the CDC7600 and converting the University of Illinois Arpanet Terminal Server (ANTS) to a host that could support long leaders. -- Steve Jenkin, IT Systems and Design 0412 786 915 (+61 412 786 915) PO Box 38, Kippax ACT 2615, AUSTRALIA mailto:sjenkin at canb.auug.org.au http://members.tip.net.au/~sjenkin From mah at mhorton.net Wed Nov 30 12:50:14 2022 From: mah at mhorton.net (Mary Ann Horton) Date: Tue, 29 Nov 2022 18:50:14 -0800 Subject: [TUHS] Reaction to the 3B2 at Bell Labs In-Reply-To: <8f278bf8-de57-4e77-a3b8-d007d7c3a446@app.fastmail.com> References: <8f278bf8-de57-4e77-a3b8-d007d7c3a446@app.fastmail.com> Message-ID: <29be0075-e06e-0db9-1537-b8939fa019ed@mhorton.net> You asked for the reaction of people in Bell Labs. I've seen reaction from Research, but there was also the Development part of the labs. I was in Columbus with a lot of OSS projects. Ours (Medis) was typical in our reaction. The 3B20 Duplex was designed for Telco central offices. It ran on 48V and had Delco car batteries as a UPS. That was fine for the telcos. The 3B20 Simplex was a less fault tolerant version, intended to compete with the Vax 11/780. Nobody wanted it. The 3B15 was chest freezer size, cheaper, to compete with the Vax 11/750. Nobody wanted it. The 3B2 in its various sizes was a desktop micro, intended to compete with a Sun server. It had possibilities. It had Datakit, and later TCP/IP. You could connect a Blit to it, and later the 5620. We were told to use it. "Eat your own dog food."  None of us liked it, but we made do. I was delighted when I transferred to the computer center and got to order Suns for desktop use. We still ordered 3B2s for our "att" email gateways. Incidently, I won a 3B1 in a raffle in 1986. That was a different beast, 68K based, the UNIX PC built by Convergent. I used it for Stargate and the UUCP Zone. It had a GUI but the screen and resolution were too small to really be useful. I still have one in my garage. Thanks, /Mary Ann Horton/ (she/her/ma'am) maryannhorton.com "This is a great book" - Monica Helms "Brave and Important" - Laura L. Engel       Available on Amazon and bn.com! On 11/26/22 10:46, Seth Morabito wrote: > Hello all, > > I'm giving a presentation on the AT&T 3B2 at a local makerspace next month, and while I've been preparing the talk I became curious about an aspect that I don't know has been discussed elsewhere. > > I'm well aware that the 3B2 was something of a market failure with not much penetration into the wider commercial UNIX space, but I'm very curious to know more about what the reaction was at Bell Labs. When AT&T entered the computer hardware market after the 1984 breakup, I get the impression that there wasn't very much interest in any of it at Bell Labs, is that true? > > Can anyone recall what the general mood was regarding the 3B2 (and the 7300 and the 6300, I suppose!) > > -Seth -------------- next part -------------- An HTML attachment was scrubbed... URL: From rudi.j.blom at gmail.com Wed Nov 30 12:55:20 2022 From: rudi.j.blom at gmail.com (Rudi Blom) Date: Wed, 30 Nov 2022 09:55:20 +0700 Subject: [TUHS] Early multiprocessor Unix Message-ID: Around 1985 the computer division of Philips Electronics had a Moterola 68010 based server running MPX (Multi Processor Unix) based on System 5.3 with modification. The 'Multi' part was related to the intelligent LAN and WAN controllers each with their own 68010 processor and memory. A separate system image would be downloaded at server boot-time. Truly Multi-Processor :-) Here an announcement of the latest (probably last) model, from 1988. https://techmonitor.ai/technology/philips_ready_with_68030_models_for_its_p9000_unix_workstation_family -- The more I learn the better I understand I know nothing. -------------- next part -------------- An HTML attachment was scrubbed... URL: