From clemc at ccc.com Tue Jan 1 00:55:31 2019 From: clemc at ccc.com (Clem Cole) Date: Mon, 31 Dec 2018 09:55:31 -0500 Subject: [TUHS] Upgrading from 11/40 to 11/45 in Unix v6 In-Reply-To: References: <7AEB778A-EBC9-4A89-8E3B-A771FF5FC9B3@ccc.com> Message-ID: On Sun, Dec 30, 2018 at 10:31 PM Will Senn wrote: > > Do you know of some commonly used at the time v6 programs that needed that > much space? > Besides everything that Noel pointed to you too, look at 1BSD - the pascal system needs to be seperate I/D for sure. I believe ex is linked seperate I/D. The C compiler itself can be, the reason to do that it allow the tables to be larger, so you don't run into errors where you run out of space. My experience from the old days, was that once you had seperate I/D, we tended to link most programs that way if we could, as we slowly deprecated the 11/40 class systems. The original Tek Labs machine was an 11/60 (which is a 40 class), and was quickly replaced with an 11/70. The 60 is what I used for the original Able Enable work that Noel referenced, so it have 4M in it for a short period (we borrowed the memory for the development). But within 2 years we had a 11/44 to replace the 11/60, which was seperate I/D system. > > > > After you are booted, a 45 class machine will run 40 class binaries > unchanged. 40 class machines can not run a.outs that are seperate I/D. > > Good to know. > > I read about this in ’Setting up Unix Sixth Edition” and I see the source > comments. It looks pretty straightforward to configure the system for > separate I/D. Is there any material difference between doing it at install > time vs having run on 11/40 for a while and moving the disk over to the > 11/45 later? > Making a system work on both could be done, but it chews up precious address space in code that will not be executed. Remember - what seems 'natural' for the modern user of cramming everything into a single binary, or keeping lots of copies of things, was not done. You lack address space, main memory or disk space. > > On a related note, how difficult is it to copy the system from rk to hp? I > know I can rebuild, but I’m sure there’s a quicker/easier method... > Easiest method is probably grabing the v6tar binary that you described how to make in your v6 for sim6 directionions, then use and dual tar programs***. Other wise, find(1) is your friend. That said, PWD (1.0) was v6 based, so there is a version of cpio on the spencer_pwb.tar.gz tape. That should work. Clem *** Note to Warren. It might be a wise to put copies of v6tar (both seperate I/D and not) binaries and maybe cpio(v6) on the TUHS we site in the V6 directory; maybe, a 'collected_tools' directory. Noel's tools would probably make sense to add there also. I bet people that are downloading and playing might find them helpful. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron at ronnatalie.com Tue Jan 1 01:05:13 2019 From: ron at ronnatalie.com (ron at ronnatalie.com) Date: Mon, 31 Dec 2018 10:05:13 -0500 Subject: [TUHS] Upgrading from 11/40 to 11/45 in Unix v6 In-Reply-To: References: <7AEB778A-EBC9-4A89-8E3B-A771FF5FC9B3@ccc.com> Message-ID: <224401d4a11a$3c30a6b0$b491f410$@ronnatalie.com> Yep, and notwithstanding split I/D, we switched to -n (410 magic) read-only code space. Of course, the kludge nargs() function didn’t work at all in split-I/D mode unless you made a hack to the processor to change the behavior of MFPI. -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.senn at gmail.com Tue Jan 1 01:06:00 2019 From: will.senn at gmail.com (Will Senn) Date: Mon, 31 Dec 2018 09:06:00 -0600 Subject: [TUHS] Upgrading from 11/40 to 11/45 in Unix v6 In-Reply-To: <20181231065125.2A34818C073@mercury.lcs.mit.edu> References: <20181231065125.2A34818C073@mercury.lcs.mit.edu> Message-ID: On 12/31/18 12:51 AM, Noel Chiappa wrote: > > From: Will Senn > > > We are seriously considering upgrading our PDP 11/40 clone (SIMH), to a > > PDP 11/45 (preferably another SIMH) > > Heh! When I saw the subject line, I thought you wanted to upgrade a > _physical_ -11/40 to an -11/45. ('Step 1. Sell the -11/40. Step 2. Buy > an -11/45.' :-) Ha! I have been struggling for a way to convey some questions I have in a way that would lessen the amount of assumptions baked into the answers (Sometimes when I ask questions, what I get back sounds to my ears a lot like, just load the frigglewump into the carbathingamajig and boot normally). Then I thought, how would I have asked the question if it the situation had come up in my real lab. I'm sure the scenario was not period accurate, but apparently it was close enough to spark some very helpful answers. Thanks for not dismissing the thread as frivolity. > > for our Unix v6 installation. > > Why on earth would an organization have such a thing? :-) Well, interestingly enough. I find using v6 to be quite fun and one step closer to some primal tech place :). I'm sure y'all have seen Mills's winning Best in Show IOCCC entry: https://www.ioccc.org/2018/mills/hint.html and the actual 'code': https://www.ioccc.org/2018/mills/prog.c Somehow, this sorta thing just jazzes me. > > > Our CEO was traveling and met a techie in first class (seriously, > > first class?) who told him that we needed one. > > Heh. If said techie knows about the two, he's probably pretty senior (i.e. > eligible for Social Security :-), and thus elegible for first class... :-) > > > It has fairly low utilization - a developer logs in and writes code > > every few days > > Who the *&%^&*(%& is still writing code under V6?! Well... writing code might be a stretch, but certainly playing around in code is fair. The developer'd be me :) > > And how do you all get the bits in and out? (I run mine under Ersatz-11, > which has this nice device which allows it to read files off the host file > system; transfering stuff back and forth is a snap, I do all my editing with > Epsilon on my Windoze box, 'cause I'm too lazy to bring up the V6 Emacs I > have.) > > > 1. Are there any v6 specific concerns about upgrading? > > Not that I know of. Fantastic, I'm prolly gonna try it. > > > 2. Why should we consider taking the leap to the 11/45? Everything > > seems to work fine now. > > You're asking _us_? Oh yeah! > > Some larger applications will only run on an split-I-D machine, is about the > only reason I can think of. > > Oh, also, the floating point instructions on the /45 are the only kind > understood by V6; the C compiler doesn't emit the ones the /40 provides. Any > floating point code run on the /40, the instructions are simulated by a > trap handler (by way of the OS, which has to handle it and reflect it to > the user process). I.e. very slow. Interesting, I had no idea. In the simulator, speed is rarely an issue with the types of programs I've been messing around with so far, so I hadn't noticed it. > > 3. If we jump in and do the upgrade, how can we immediately recognize > > what has changed in the environment? I.e what are some things that we > > can now do that we couldn't do before? > > See above. > > > 4. If we just insert our current diskpacks into the new system, will it > > just boot and work? Or what do we need to before/after booting to > > prepare/respond to the new system? > > Any V6 disk pack can be read/mounted on any V6 machine. Any binaries (the OS, > or user commands) for the -11/40 will run on the -/45. (Which is why the V6 > dist includes binaries for /40 versions of the OS only.) > > To make use of the /45, you need a different copy of the OS binary, built from > a slightly different set of modules. (Replace m40.s with m45.s; and you will > need to re-asssemble l.s, prepending it with data.s.) Both variants can live > on the same pack, under different filenames; select the right one at boot > time. Nice. Definitely a worthy project then. If the instructions in Setting up are as good for the 45 as they are for the 40, I should be able to bring one up relatively painlessly. This is one of those assumptions I was talking about - I knew that I could just add CPU=11/45 in my SIMH ini file and be running an 11/45, and separately, I knew that I could build 11/45 code in Unix v6. But, I didn't get  how this fit together. What it sounds like is that Unix was transitioning from non-I/D land to I/D land and maintaining a measure of backward compatibility not unlike Mac OS from PPC to Intel, or 32bit to 64bit? > > 5. Is 256K enough memory or what configuration do y'all recommend? > > 256KB is all you can have. Neither SIMH nor Ersatz-11 support the Able > ENABLE: > > http://gunkies.org/wiki/Able_ENABLE > > which is what you need to have more than 256KB on a UNIBUS -11. Fascinating. Definitely will keep this in mind and hurry the transition towards the 11/70. > > > > From: Clem Cole > > > You'll probably want to configure a kernel for the 45 class machine. > > Look at the differences in the *.s files in the kernel. > > More importantly, look at the 'run' file in /usr/sys, which has commented > out lines to build the OS image for /45-/70 class machines. Found it already! > > > But either way you should configure the system to use the largest drive > > v6 has. > > This is actually of limited utility, since a V6 file system is restricted to > 65K blocks _max_. So a disk with 350K blocks (like an RP06), you'll have to > split it into like 5 partitions to use it all. Yeah, Cole already mentioned this in a separate thread. I'll file it in the keep in mind drawer. > > > > From: Will Senn > > > Do you know of some commonly used at the time v6 programs that needed > > that much space? > > Heh. Spun up my v6, and did "file * | grep separate" in /bin and /usr/bin, > and then recalled that V6 was distributed in a form suitable for a /40. So, > null set. > > Did the same thing on /bin from the MIT V6+ system, and got: > > a68: separate I&D executable not stripped > a86: separate I&D executable not stripped > bteco: separate I&D executable not stripped > c86: separate I&D executable not stripped > e: separate I&D executable not stripped > emacs: separate I&D executable not stripped > lisp: separate I&D executable not stripped > mail: separate I&D executable not stripped > ndd: separate I&D executable not stripped > s: separate I&D executable not stripped > send: separate I&D executable not stripped > teco: separate I&D executable not stripped > > No idea what the difference is between 'teco' and 'bteco', what 's/send' do, > etc. This is really helpful. Is there a bootable tape of the MIT system extant? > > > Is there any material difference between doing it at install time vs > > having run on 11/40 for a while and moving the disk over to the 11/45 > > later? > > No; like I said, you can have two different OS binaries on the disk, and > select which one you boot. > > > On a related note, how difficult is it to copy the system from rk to > > hp? I know I can rebuild, but I'm sure there's a quicker/easier method... > > Build a system with both, and then copy the files? I'd use 'tar' (I have a V6 > tar, but it uses a modified OS with the smdate() call added back in) to do the > moving (which would retain the last-write dates); 'tp' or 'stp' would also > work. > > The hack _I_ used on simulated systems was to expand the file that held the > 'disk pack', mount it as a different kind of pack (RL or RP), and then go in > and hand-patch the disk size in the root block with 'db', then 'icheck -s' to > re-build the free list. Note: this won't give you more inodes, so you may run > out, but the usual inode allocation is pretty generous. Oh my, what's that you say about frigglewumping the carbathingamajig? :) > > Noel > > PS: Speaking of the last write dates, I have versions of mv/mvall, cp/cpall, > ln, chmod etc which retain them (using smdate()). If there's an actual > community of people using V6, I should upload all the stuff I have. Although > it might be good to establish some central location for exchange of V6 code. > However, I don't and won't (don't even ask) use GitHub or any similar modern > thing. This would be great. Right now, stuff is pretty much pell-mell and difficult to find, much less use. -- GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF From clemc at ccc.com Tue Jan 1 01:50:08 2019 From: clemc at ccc.com (Clem Cole) Date: Mon, 31 Dec 2018 10:50:08 -0500 Subject: [TUHS] Upgrading from 11/40 to 11/45 in Unix v6 In-Reply-To: <20181231065125.2A34818C073@mercury.lcs.mit.edu> References: <20181231065125.2A34818C073@mercury.lcs.mit.edu> Message-ID: On Mon, Dec 31, 2018 at 2:20 AM Noel Chiappa wrote: > > Speaking of the last write dates, I have versions of mv/mvall, cp/cpall, > ln, chmod etc which retain them (using smdate()). Yup - thanks, I snarfed the stuff on gunkies that you had a while back. > If there's an actual community of people using V6, I should upload all > the stuff I have. Of course we all should ;-) > Although it might be good to establish some central location for exchange > of V6 code. I think that if Warren added a 'collected tools' directory next to each of distributions, that would work and I think would make the most sense. As I said, elsewhere your stuff, v6tar, cpio, stp and a smattering of offerings from the old usenix tapes, plus maybe a couple of from 1BSD such as ex might be appropriate. Clem ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Tue Jan 1 01:53:48 2019 From: imp at bsdimp.com (Warner Losh) Date: Mon, 31 Dec 2018 08:53:48 -0700 Subject: [TUHS] Upgrading from 11/40 to 11/45 in Unix v6 In-Reply-To: References: <20181231065125.2A34818C073@mercury.lcs.mit.edu> Message-ID: On Mon, Dec 31, 2018 at 8:51 AM Clem Cole wrote: > > > On Mon, Dec 31, 2018 at 2:20 AM Noel Chiappa > wrote: > >> >> Speaking of the last write dates, I have versions of mv/mvall, cp/cpall, >> ln, chmod etc which retain them (using smdate()). > > Yup - thanks, I snarfed the stuff on gunkies that you had a while back. > > > >> If there's an actual community of people using V6, I should upload all >> the stuff I have. > > Of course we all should ;-) > > > > >> Although it might be good to establish some central location for >> exchange of V6 code. > > I think that if Warren added a 'collected tools' directory next to each of > distributions, that would work and I think would make the most sense. As > I said, elsewhere your stuff, v6tar, cpio, stp and a smattering of > offerings from the old usenix tapes, plus maybe a couple of from 1BSD such > as ex might be appropriate. > Are the usenix tapes online? Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Tue Jan 1 01:53:53 2019 From: clemc at ccc.com (Clem Cole) Date: Mon, 31 Dec 2018 10:53:53 -0500 Subject: [TUHS] Upgrading from 11/40 to 11/45 in Unix v6 In-Reply-To: <224401d4a11a$3c30a6b0$b491f410$@ronnatalie.com> References: <7AEB778A-EBC9-4A89-8E3B-A771FF5FC9B3@ccc.com> <224401d4a11a$3c30a6b0$b491f410$@ronnatalie.com> Message-ID: On Mon, Dec 31, 2018 at 10:05 AM wrote: > Yep, and notwithstanding split I/D, we switched to -n (410 magic) > read-only code space. > Agreed, that was pretty standard and used the sticky bit as needed. IIRC this was to help sharing, but I admit those bits in my brain had not been refreshed in years. > Of course, the kludge nargs() function didn’t work at all in split-I/D > mode unless you made a hack to the processor to change the behavior of MFPI. > Ah yes, I've forgotten that hack. Does simh or any of the other simulators support it? It would need to be an option of course. > > ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Tue Jan 1 01:59:55 2019 From: clemc at ccc.com (Clem Cole) Date: Mon, 31 Dec 2018 10:59:55 -0500 Subject: [TUHS] Upgrading from 11/40 to 11/45 in Unix v6 In-Reply-To: References: <20181231065125.2A34818C073@mercury.lcs.mit.edu> Message-ID: On Mon, Dec 31, 2018 at 10:53 AM Warner Losh wrote: > > Are the usenix tapes online? > I know some of them are (google/duck-duck-go are your friends), but I do not know of one place. When I was USENIX President, I tried to get them added to the archives. It might be worth making another go at that. Clem ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnc at mercury.lcs.mit.edu Tue Jan 1 03:20:08 2019 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Mon, 31 Dec 2018 12:20:08 -0500 (EST) Subject: [TUHS] Upgrading from 11/40 to 11/45 in Unix v6 Message-ID: <20181231172008.2499718C073@mercury.lcs.mit.edu> > From: Will Senn > Thanks for not dismissing the thread as frivolity. Hey, anyone wanting to do things with V6 I take seriously! :-) > I'm sure y'all have seen Mills's winning Best in Show IOCCC entry: > https://www.ioccc.org/2018/mills/hint.html Yes, that was pretty awesome. > Fantastic, I'm prolly gonna try it. OK; if you want to know what it's doing (somehow I figured you probably didn't just want to simply follow the instructions :-) that is different from the /40 (it's quite different, and somewhat complicated), I just wrote this: http://gunkies.org/wiki/Unix_V6_kernel_memory_layout to explain it a bit. Currently, one has to read the source to 'sysfix', and also m45.s, to understand how the /45 version works; that new page is a little crude still, but it hopefully explains the big picture. > If the instructions in Setting up are as good for the 45 as they are for > the 40, I should be able to bring one up relatively painlessly. I just took a look at "Setting up UNIX - Sixth Edition", and it doesn't really say much about the /45; it basically just says 'the /45 is wiered inside' and 'look at sys/run'. It is certainly true that that does cover all one needs to bring V6 up on the /45, but... The coverage of what to do if your '45' has hardware floating point is pretty complete, though. > What it sounds like is that Unix was transitioning from non-I/D land to > I/D land and maintaining a measure of backward compatibility That's pretty accurate. One main advantage of the /45 is that it could have a lot more disk buffers, but I'm not sure that makes much difference for emulation. If you have some application that won't fit well in 64KB, that's big, but that's a user-land difference, not the OS. > Is there a bootable tape of the MIT system extant? Not yet, sorry. I do have a complete dump, but it i) includes all the users' personal files, and ii) is not well organized. It's on my to-do list. Noel From ron at ronnatalie.com Tue Jan 1 03:30:02 2019 From: ron at ronnatalie.com (ron at ronnatalie.com) Date: Mon, 31 Dec 2018 12:30:02 -0500 Subject: [TUHS] Upgrading from 11/40 to 11/45 in Unix v6 In-Reply-To: References: <7AEB778A-EBC9-4A89-8E3B-A771FF5FC9B3@ccc.com> <224401d4a11a$3c30a6b0$b491f410$@ronnatalie.com> Message-ID: <2bc601d4a12e$76ca3d40$645eb7c0$@ronnatalie.com> Yeah, ISVTX only worked on 410 and 411 files. It locked the text segment in swap. It kind of got obsoleted by later versions that could load stuff direct to memory from the disk image. From: Clem Cole Sent: Monday, December 31, 2018 10:54 AM To: Ronald Natalie Cc: Will Senn ; The Eunuchs Hysterical Society Subject: Re: [TUHS] Upgrading from 11/40 to 11/45 in Unix v6 On Mon, Dec 31, 2018 at 10:05 AM > wrote: Yep, and notwithstanding split I/D, we switched to -n (410 magic) read-only code space. Agreed, that was pretty standard and used the sticky bit as needed. IIRC this was to help sharing, but I admit those bits in my brain had not been refreshed in years. Of course, the kludge nargs() function didn’t work at all in split-I/D mode unless you made a hack to the processor to change the behavior of MFPI. Ah yes, I've forgotten that hack. Does simh or any of the other simulators support it? It would need to be an option of course. ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.winalski at gmail.com Tue Jan 1 03:51:05 2019 From: paul.winalski at gmail.com (Paul Winalski) Date: Mon, 31 Dec 2018 12:51:05 -0500 Subject: [TUHS] Deleted lib1 and lib2 in v6, recoverable? In-Reply-To: <401865440.113885.1546214417318.JavaMail.tomcat@india-live-be01> References: <20181229010900.19F6218C074@mercury.lcs.mit.edu> <401865440.113885.1546214417318.JavaMail.tomcat@india-live-be01> Message-ID: On 12/30/18, Donald ODona wrote: > > > At 30 Dec 2018 18:35:22 +0000 (+00:00) from Paul Winalski > : >> >> Sometimes one runs into a situation where a module loaded from lib1.a >> has an undefined symbol that causes a module from lib2.a to be loaded, >> and that module in turn has an undefined symbol that is defined in >> lib1.a. In that case, you have to cause the linker to scan lib1.a >> twice: >> >> ld main.o lib1.a lib2.a lib1.a >> > thats not true, because the M$ and borland linkers of the 80ths under > MSDOS(sic!) already processed indexed libraries. Therefore the multiple > inclusion of libraries wans'nt needed. > No, you still need multiple inclusion in that situation. Consider this situation: main.o has an undefined reference to s1 m1.o in lib1.a defines s1 and has an undefined reference to s2 m3.o in lib1.a defines s3 m2.o in lib2.a defines s2 and has an undefined reference to s3 The command line is: ld main.o lib1.a lib2.a The linker makes one or more passes over the index of lib1.a until no more symbols are resolved. The linker loads m1.o. It does not load m3.o because m3.o doesn't resolve any outstanding undefined references. The linker still has s2 undefined. It now makes one or more passes over the index of lib2.a until no more symbols are resolved. In the process it loads m2.o to resolve s2 and adds s3 to the list of unresolved symbols. After lib2.a is processed, s3 is still undefined, and ld has nothing left to process. ld will issue an "unresolved symbol" error message for s3. You need to specify lib1.a a second time to cause ld to scan it again. -Paul W. From paul.winalski at gmail.com Tue Jan 1 04:20:08 2019 From: paul.winalski at gmail.com (Paul Winalski) Date: Mon, 31 Dec 2018 13:20:08 -0500 Subject: [TUHS] Upgrading from 11/40 to 11/45 in Unix v6 In-Reply-To: <2bc601d4a12e$76ca3d40$645eb7c0$@ronnatalie.com> References: <7AEB778A-EBC9-4A89-8E3B-A771FF5FC9B3@ccc.com> <224401d4a11a$3c30a6b0$b491f410$@ronnatalie.com> <2bc601d4a12e$76ca3d40$645eb7c0$@ronnatalie.com> Message-ID: On 12/31/18, ron at ronnatalie.com wrote: > Yeah, ISVTX only worked on 410 and 411 files. It locked the text segment > in swap. It kind of got obsoleted by later versions that could load stuff > direct to memory from the disk image. > a.out magic number 0410 is OMAGIC (separate read-only instruction and data segments). 0413 is ZMAGIC (demand-paged executable). What is magic number 0411? That one I've never heard of before. -Paul W. From jnc at mercury.lcs.mit.edu Tue Jan 1 04:38:04 2019 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Mon, 31 Dec 2018 13:38:04 -0500 (EST) Subject: [TUHS] Upgrading from 11/40 to 11/45 in Unix v6 Message-ID: <20181231183804.71A6618C073@mercury.lcs.mit.edu> > From: Paul Winalski > What is magic number 0411? That one I've never heard of before. It's a PDP-11-ism. Separate I+D. Noel From imp at bsdimp.com Tue Jan 1 06:06:50 2019 From: imp at bsdimp.com (Warner Losh) Date: Mon, 31 Dec 2018 13:06:50 -0700 Subject: [TUHS] Upgrading from 11/40 to 11/45 in Unix v6 In-Reply-To: <20181231183804.71A6618C073@mercury.lcs.mit.edu> References: <20181231183804.71A6618C073@mercury.lcs.mit.edu> Message-ID: On Mon, Dec 31, 2018, 1:38 PM Noel Chiappa > From: Paul Winalski > > > What is magic number 0411? That one I've never heard of before. > > It's a PDP-11-ism. Separate I+D. > Venix/86, a v7 sys iii hybrid that ran on 8086/286 also uses it for basically the same thing... its compiler was limited to one 64k code segment and one 64k data / stack segment. The syscall interface depends on this quirk as well... Warner > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wkt at tuhs.org Tue Jan 1 09:36:05 2019 From: wkt at tuhs.org (Warren Toomey) Date: Tue, 1 Jan 2019 09:36:05 +1000 Subject: [TUHS] Useful Unix tools + Usenix tapes In-Reply-To: References: <7AEB778A-EBC9-4A89-8E3B-A771FF5FC9B3@ccc.com> Message-ID: <20181231233605.GA1837@minnie.tuhs.org> On Mon, Dec 31, 2018 at 09:55:31AM -0500, Clem Cole wrote: > *** Note to Warren. It might be a wise to put copies of v6tar (both > seperate I/D and not) binaries and maybe cpio(v6) on the TUHS we site > in the V6 directory; maybe, a 'collected_tools' directory. Noel's > tools would probably make sense to add there also. I bet people that > are downloading and playing might find them helpful. In the Unix Archive, there is this location: https://www.tuhs.org/Archive/Tools/ It's separate from the distributions. Pro: it keeps the original files separate from 3rd party things; con: it's a bit harder to find things when you need them. If anybody has other tools or useful utilities to add in here, let me know! There are some Usenix tapes in the archive here: https://www.tuhs.org/Archive/Applications/ Look in Shoppa_Tapes, Spencer_Tapes and Spencer_Tapes. If there are other tape images out there that I could add, let me know as well. Happy New Year, everyone. Cheers, Warren From will.senn at gmail.com Tue Jan 1 10:29:11 2019 From: will.senn at gmail.com (Will Senn) Date: Mon, 31 Dec 2018 18:29:11 -0600 Subject: [TUHS] building world using sh run in /usr/source in v6 Message-ID: <5f8d3f32-3cd1-7dbe-6e59-25b8c577f9f9@gmail.com> The setting up document hints at how to build world so to speak in v6. However, when I log in as bin (most files are owned by bin) and: chdir /usr/source sh run I get a number of failed items along these lines: cp a.out /etc/cron Can't create new file. cp a.out /etc/init Can't create new file. A little digging around points to the problem - some files are owned by daemon, others by root: -rwsrwsr--  1 daemon   3246 Oct 10 12:54 cron -rwxrwxr--  1 root     2054 May 13 23:50 init My question is this, is the system recompiled en-masse using the run script in /usr/source or not? It certainly appears to be the method, as it contains a bunch of chdir somedir; time sh run lines including the /usr/sys/run file... If it's not, what was the method? I gather I can force it by logging in as root and running those sections of the run script pertaining to files owned by root, and the same for daemon, but that seems inefficient and begs the question why didn't they have run scripts for root and daemon that were separate from the ones for bin. Thanks, Will -- GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF From lm at mcvoy.com Tue Jan 1 10:39:16 2019 From: lm at mcvoy.com (Larry McVoy) Date: Mon, 31 Dec 2018 16:39:16 -0800 Subject: [TUHS] building world using sh run in /usr/source in v6 In-Reply-To: <5f8d3f32-3cd1-7dbe-6e59-25b8c577f9f9@gmail.com> References: <5f8d3f32-3cd1-7dbe-6e59-25b8c577f9f9@gmail.com> Message-ID: <20190101003916.GB15969@mcvoy.com> On Mon, Dec 31, 2018 at 06:29:11PM -0600, Will Senn wrote: > cp a.out /etc/init > Can't create new file. > > A little digging around points to the problem - some files are owned by > daemon, others by root: > > -rwsrwsr--?? 1 daemon???? 3246 Oct 10 12:54 cron > -rwxrwxr--?? 1 root???????? 2054 May 13 23:50 init This smells like a file system that is corrupted (I used to hack UFS a few decades back). Can you do a ls -l | od -c because I want to see what those ?? are. And cron is really 3246 bytes? And 2054 for init? Don't those seem too small? Linux's cron is 44472 and that's with shared libs, I'm assuming that v6 didn't have shared libs, it's all static. From will.senn at gmail.com Tue Jan 1 10:48:58 2019 From: will.senn at gmail.com (Will Senn) Date: Mon, 31 Dec 2018 18:48:58 -0600 Subject: [TUHS] building world using sh run in /usr/source in v6 In-Reply-To: <20190101003916.GB15969@mcvoy.com> References: <5f8d3f32-3cd1-7dbe-6e59-25b8c577f9f9@gmail.com> <20190101003916.GB15969@mcvoy.com> Message-ID: <7e9ef70d-dfcf-de1a-7711-c0c2007baf90@gmail.com> On 12/31/18 6:39 PM, Larry McVoy wrote: > On Mon, Dec 31, 2018 at 06:29:11PM -0600, Will Senn wrote: >> cp a.out /etc/init >> Can't create new file. >> >> A little digging around points to the problem - some files are owned by >> daemon, others by root: >> >> -rwsrwsr--?? 1 daemon???? 3246 Oct 10 12:54 cron >> -rwxrwxr--?? 1 root???????? 2054 May 13 23:50 init > This smells like a file system that is corrupted (I used to hack UFS > a few decades back). > > Can you do a > > ls -l | od -c > > because I want to see what those ?? are. > > And cron is really 3246 bytes? And 2054 for init? Don't those seem > too small? Linux's cron is 44472 and that's with shared libs, I'm > assuming that v6 didn't have shared libs, it's all static. Hi Larry, I'm not sure where the ? came from, but I think that's just the email, here is init: ls -l /etc/init|od -c 0000000  -  r  w  x  r  w  x  r  -  -        1     r  o 0000020  o  t                 2  0  5  4     M  a  y 0000040  1  3     2  3  :  5  0     /  e  t  c  /  i  n 0000060  i  t \n \0 0000063 ls -l /etc/init|od 0000000 071055 074167 073562 071170 026455 020040 020061 067562 0000020 072157 020040 020040 031040 032460 020064 060515 020171 0000040 031461 031040 035063 030065 027440 072145 027543 067151 0000060 072151 000012 0000063 As for how big they are, that's just the beauty of v6, everything is super small. Linux is blubbery in comparison. Will -- GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF From clemc at ccc.com Tue Jan 1 11:30:13 2019 From: clemc at ccc.com (Clem cole) Date: Mon, 31 Dec 2018 20:30:13 -0500 Subject: [TUHS] Useful Unix tools + Usenix tapes In-Reply-To: <20181231233605.GA1837@minnie.tuhs.org> References: <7AEB778A-EBC9-4A89-8E3B-A771FF5FC9B3@ccc.com> <20181231233605.GA1837@minnie.tuhs.org> Message-ID: <9CF99401-9244-42C9-8FC5-68D724558974@ccc.com> Warren I understand and thank you. That is surely a possible place to put things. I was thinking something a little different. The directory you have are more general tools that really apply across releases and specific targets. I was thinking when you have tools like the set I mentioned previously that are system specific and you probable want to supply target binaries that you try to keep them in a directory next the system that they relate. Thus in your Research directory - create a v6 specific contributed tool directory. Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. > On Dec 31, 2018, at 6:36 PM, Warren Toomey wrote: > >> On Mon, Dec 31, 2018 at 09:55:31AM -0500, Clem Cole wrote: >> *** Note to Warren. It might be a wise to put copies of v6tar (both >> seperate I/D and not) binaries and maybe cpio(v6) on the TUHS we site >> in the V6 directory; maybe, a 'collected_tools' directory. Noel's >> tools would probably make sense to add there also. I bet people that >> are downloading and playing might find them helpful. > > In the Unix Archive, there is this location: > https://www.tuhs.org/Archive/Tools/ > > It's separate from the distributions. Pro: it keeps the original files > separate from 3rd party things; con: it's a bit harder to find things > when you need them. > > If anybody has other tools or useful utilities to add in here, let me know! > > There are some Usenix tapes in the archive here: > https://www.tuhs.org/Archive/Applications/ > Look in Shoppa_Tapes, Spencer_Tapes and Spencer_Tapes. If there are > other tape images out there that I could add, let me know as well. > > Happy New Year, everyone. > Cheers, Warren From clemc at ccc.com Tue Jan 1 11:58:23 2019 From: clemc at ccc.com (Clem cole) Date: Mon, 31 Dec 2018 20:58:23 -0500 Subject: [TUHS] Useful Unix tools + Usenix tapes In-Reply-To: <20181231233605.GA1837@minnie.tuhs.org> References: <7AEB778A-EBC9-4A89-8E3B-A771FF5FC9B3@ccc.com> <20181231233605.GA1837@minnie.tuhs.org> Message-ID: Warren There are a number of usenix tapes missing in your archives. The first three were called 1 2 and 3 from the mid 70s but where included in the Harvard tape*** from about 76 or 77 which I sort of consider the first usenix tape. Note that This is an stp format distribution. Which IIRC the v6 tp could read or at least read it enough to pull the stp binary off the tape which would then allow you read the whole thing. You will need the v6 ar because the directories inside the tape were archived as files called cont.a And I think I remember that some of those were compressed with pack/unpack tools which were in the wild in those days — probably also on the Harvard tape. As I mentioned the other day the 1BSD tape you have seems to be a conversion from stp to tar. FYI: one of the issues with tp and stp is that the directory for the tape is at the beginning of the tape itself and is fixed in size [this is have DECtape worked]. Because it was fixed in size folks archived directories together so the tp directory needed only the folder and a single file it. FWIW One of the big enhancements tar provided over tp was the threading the directory throughout the archive which eliminated tat issue, but of course if there is a tape error recovery is more difficult. IIRC Harvard had added a second directory to the end of tp in the stp format to help reliability. Ie if you had errors in the tp directory at the front of the tape, you had a chance to recover by using the second copy of it. *** the Harvard tape takes it name from the meeting at Harvard of the Unix News readers. This would become USENIX as an org shortly there after. The earlier tapes (1 2 and 3) were what files had been collected at earlier meetings. Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. > On Dec 31, 2018, at 6:36 PM, Warren Toomey wrote: > >> On Mon, Dec 31, 2018 at 09:55:31AM -0500, Clem Cole wrote: >> *** Note to Warren. It might be a wise to put copies of v6tar (both >> seperate I/D and not) binaries and maybe cpio(v6) on the TUHS we site >> in the V6 directory; maybe, a 'collected_tools' directory. Noel's >> tools would probably make sense to add there also. I bet people that >> are downloading and playing might find them helpful. > > In the Unix Archive, there is this location: > https://www.tuhs.org/Archive/Tools/ > > It's separate from the distributions. Pro: it keeps the original files > separate from 3rd party things; con: it's a bit harder to find things > when you need them. > > If anybody has other tools or useful utilities to add in here, let me know! > > There are some Usenix tapes in the archive here: > https://www.tuhs.org/Archive/Applications/ > Look in Shoppa_Tapes, Spencer_Tapes and Spencer_Tapes. If there are > other tape images out there that I could add, let me know as well. > > Happy New Year, everyone. > Cheers, Warren From clemc at ccc.com Tue Jan 1 12:00:36 2019 From: clemc at ccc.com (Clem cole) Date: Mon, 31 Dec 2018 21:00:36 -0500 Subject: [TUHS] Useful Unix tools + Usenix tapes In-Reply-To: References: <7AEB778A-EBC9-4A89-8E3B-A771FF5FC9B3@ccc.com> <20181231233605.GA1837@minnie.tuhs.org> Message-ID: <61098684-9C0E-444A-AE4E-7681DE7EDDC0@ccc.com> Sounds great. Thanks. Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. > On Dec 31, 2018, at 8:58 PM, Clem cole wrote: > > Warren There are a number of usenix tapes missing in your archives. The first three were called 1 2 and 3 from the mid 70s but where included in the Harvard tape*** from about 76 or 77 which I sort of consider the first usenix tape. Note that This is an stp format distribution. Which IIRC the v6 tp could read or at least read it enough to pull the stp binary off the tape which would then allow you read the whole thing. You will need the v6 ar because the directories inside the tape were archived as files called cont.a And I think I remember that some of those were compressed with pack/unpack tools which were in the wild in those days — probably also on the Harvard tape. As I mentioned the other day the 1BSD tape you have seems to be a conversion from stp to tar. > > FYI: one of the issues with tp and stp is that the directory for the tape is at the beginning of the tape itself and is fixed in size [this is have DECtape worked]. Because it was fixed in size folks archived directories together so the tp directory needed only the folder and a single file it. FWIW One of the big enhancements tar provided over tp was the threading the directory throughout the archive which eliminated tat issue, but of course if there is a tape error recovery is more difficult. IIRC Harvard had added a second directory to the end of tp in the stp format to help reliability. Ie if you had errors in the tp directory at the front of the tape, you had a chance to recover by using the second copy of it. > > > *** the Harvard tape takes it name from the meeting at Harvard of the Unix News readers. This would become USENIX as an org shortly there after. The earlier tapes (1 2 and 3) were what files had been collected at earlier meetings. > > Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. > >>> On Dec 31, 2018, at 6:36 PM, Warren Toomey wrote: >>> >>> On Mon, Dec 31, 2018 at 09:55:31AM -0500, Clem Cole wrote: >>> *** Note to Warren. It might be a wise to put copies of v6tar (both >>> seperate I/D and not) binaries and maybe cpio(v6) on the TUHS we site >>> in the V6 directory; maybe, a 'collected_tools' directory. Noel's >>> tools would probably make sense to add there also. I bet people that >>> are downloading and playing might find them helpful. >> >> In the Unix Archive, there is this location: >> https://www.tuhs.org/Archive/Tools/ >> >> It's separate from the distributions. Pro: it keeps the original files >> separate from 3rd party things; con: it's a bit harder to find things >> when you need them. >> >> If anybody has other tools or useful utilities to add in here, let me know! >> >> There are some Usenix tapes in the archive here: >> https://www.tuhs.org/Archive/Applications/ >> Look in Shoppa_Tapes, Spencer_Tapes and Spencer_Tapes. If there are >> other tape images out there that I could add, let me know as well. >> >> Happy New Year, everyone. >> Cheers, Warren From nw at retrocomputingtasmania.com Tue Jan 1 12:08:19 2019 From: nw at retrocomputingtasmania.com (Nigel Williams) Date: Tue, 1 Jan 2019 13:08:19 +1100 Subject: [TUHS] Useful Unix tools + Usenix tapes In-Reply-To: References: <7AEB778A-EBC9-4A89-8E3B-A771FF5FC9B3@ccc.com> <20181231233605.GA1837@minnie.tuhs.org> Message-ID: Regarding these aggregates (tapes, zips, tars etc) can we consider the option please of having them unpacked into their tree structure so a search-engine can index the content? From wkt at tuhs.org Tue Jan 1 12:17:29 2019 From: wkt at tuhs.org (Warren Toomey) Date: Tue, 1 Jan 2019 12:17:29 +1000 Subject: [TUHS] Useful Unix tools + Usenix tapes In-Reply-To: References: <7AEB778A-EBC9-4A89-8E3B-A771FF5FC9B3@ccc.com> <20181231233605.GA1837@minnie.tuhs.org> Message-ID: <20190101021729.GA30993@minnie.tuhs.org> On Tue, Jan 01, 2019 at 01:08:19PM +1100, Nigel Williams wrote: > Regarding these aggregates (tapes, zips, tars etc) can we consider the > option please of having them unpacked into their tree structure so a > search-engine can index the content? Argh! I'm mindful of the disk space on my system and also on the mirrors. How about I write a script that unpacks and builds a table of contents list for all the tarball and Zip files in the archive. It would run regularly and leave a text file in the Archive root. Cheers, Warren From tuhs at eric.allman.name Tue Jan 1 11:56:16 2019 From: tuhs at eric.allman.name (Eric Allman) Date: Mon, 31 Dec 2018 17:56:16 -0800 Subject: [TUHS] Upgrading from 11/40 to 11/45 in Unix v6 In-Reply-To: <20181231065125.2A34818C073@mercury.lcs.mit.edu> References: <20181231065125.2A34818C073@mercury.lcs.mit.edu> Message-ID: <647c9a7e-31da-9940-ece9-ce355ef36a52@neophilic.com> On 2018-12-30 10:51 PM, Noel Chiappa wrote: > > From: Will Senn > > > Do you know of some commonly used at the time v6 programs that needed > > that much space? The base system probably didn't have any separated I/D space programs for reasons that have already been discussed. But users definitely did. For example, the INGRES database system at Berkeley required separated I/D space (and even then ran in multiple processes). Tom Ferrin at UCSF Computer Graphics Lab needed it as well. Speaking of Tom and the 11/45, there was a quirk in the MFPI (Move From Previous Instruction Space) instruction that broke the nargs() function, which was pretty heavily used at the time. Tom gave an amazing presentation at USENIX in San Francisco where he fixed the problem by cutting a trace on one of the circuit boards. It's described here: https://www.cgl.ucsf.edu/home/tef/pubs/mfpi.pdf. If you're using nargs() then there might be a reason to stick with the 11/40, assuming your implementation doesn't have the Ferrin Fix. eric From wkt at tuhs.org Tue Jan 1 13:31:22 2019 From: wkt at tuhs.org (Warren Toomey) Date: Tue, 1 Jan 2019 13:31:22 +1000 Subject: [TUHS] Idea of Small Curators Group for Unix Archive Message-ID: <20190101033122.GA8802@minnie.tuhs.org> Happy New Year to you all. It's also the year we will celebrate the 50th anniversary of the Unix timesharing system. Just FYI, I hope to be in Los Angeles the week before the 2019 Usenix ATC, to go to the CHM. Then to Seattle before the ATC to visit the LCM+L, then the ATC. Hope to see some of you along the way. I'm feeling the need to get a few other people to help out curate and maintain the Unix Archive. Not that it changes very often, but it might help to have some fresh eyes (and opinions) look at it and add/improve it. So if there is any interest from a few of the long-time TUHS members, please e-mail me. I run Nextcloud on the server, so if you can run a client at your end and have about 4G spare disk space (or less if you are only interested in a specific section), that would be great. I'll be away for about 7 days but I'll try to read/respond to e-mails. Cheers, Warren From dave at horsfall.org Tue Jan 1 13:41:37 2019 From: dave at horsfall.org (Dave Horsfall) Date: Tue, 1 Jan 2019 14:41:37 +1100 (EST) Subject: [TUHS] ARPAnrt, and the Unix epoch Message-ID: According to my notes, the ARPAnet was converted from NCP to TCP on this day in 1983; except for a temporary dispensation for a few hosts, NCP support was switched off. And as every Unix geek knows, today in 1970 is Unix's time epoch. Trivia: I found a web site that thinks that that's my birthday! Not even close; try October 1952 instead... -- Dave From dave at horsfall.org Tue Jan 1 14:01:37 2019 From: dave at horsfall.org (Dave Horsfall) Date: Tue, 1 Jan 2019 15:01:37 +1100 (EST) Subject: [TUHS] Almost forgot: In Memoriam: Grace Hopper Message-ID: We lost Rear Admiral "Amazing" Grace Hopper on this day in 1992; amongst other things she gave us COBOL and ADA, and was allegedly responsible for the term "debugging" when she removed a moth from a relay on the Harvard Mk I. -- Dave From jnc at mercury.lcs.mit.edu Tue Jan 1 14:11:35 2019 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Mon, 31 Dec 2018 23:11:35 -0500 (EST) Subject: [TUHS] building world using sh run in /usr/source in v6 Message-ID: <20190101041135.AC52818C073@mercury.lcs.mit.edu> > From: Larry McVoy > And cron is really 3246 bytes? And 2054 for init? Don't those seem too > small? Linux's cron is 44472 and that's with shared libs No, 3246 is the same as mine, and my init (which has a few changes from stock) is 2064. I'm not surprised the later one is 44KB - that's in part due to the denseness of PDP-11 binary (and the word-size is only 16 bits), but more broadly, I expect that it goes to my complaint about later Unixes - they've lost, IMO, the single most important thing about the PDP-11 Unixes, which is their bang/buck ratio. Noel From wkt at tuhs.org Tue Jan 1 18:18:09 2019 From: wkt at tuhs.org (Warren Toomey) Date: Tue, 1 Jan 2019 18:18:09 +1000 Subject: [TUHS] Useful Unix tools + Usenix tapes In-Reply-To: <20190101021729.GA30993@minnie.tuhs.org> References: <7AEB778A-EBC9-4A89-8E3B-A771FF5FC9B3@ccc.com> <20181231233605.GA1837@minnie.tuhs.org> <20190101021729.GA30993@minnie.tuhs.org> Message-ID: <20190101081809.GA15875@minnie.tuhs.org> On Tue, Jan 01, 2019 at 12:17:29PM +1000, Warren Toomey wrote: > How about I write a script that unpacks and builds a table of contents > list for all the tarball and Zip files in the archive. It would run > regularly and leave a text file in the Archive root. Done. It seems to work, but let me know if there are small issues. The file is generated daily and is at: https://www.tuhs.org/Archive/tarball_tocs.txt.gz Cheers, Warren From jsteve at superglobalmegacorp.com Tue Jan 1 20:41:53 2019 From: jsteve at superglobalmegacorp.com (Jason Stevens) Date: Tue, 1 Jan 2019 10:41:53 +0000 Subject: [TUHS] Idea of Small Curators Group for Unix Archive In-Reply-To: <20190101033122.GA8802@minnie.tuhs.org> References: <20190101033122.GA8802@minnie.tuhs.org> Message-ID: If love to help!! I have TB's of space at home and work, and 100's of gigs online. Get Outlook for Android On Tue, Jan 1, 2019 at 11:32 AM +0800, "Warren Toomey" wrote: Happy New Year to you all. It's also the year we will celebrate the 50th anniversary of the Unix timesharing system. Just FYI, I hope to be in Los Angeles the week before the 2019 Usenix ATC, to go to the CHM. Then to Seattle before the ATC to visit the LCM+L, then the ATC. Hope to see some of you along the way. I'm feeling the need to get a few other people to help out curate and maintain the Unix Archive. Not that it changes very often, but it might help to have some fresh eyes (and opinions) look at it and add/improve it. So if there is any interest from a few of the long-time TUHS members, please e-mail me. I run Nextcloud on the server, so if you can run a client at your end and have about 4G spare disk space (or less if you are only interested in a specific section), that would be great. I'll be away for about 7 days but I'll try to read/respond to e-mails. Cheers, Warren -------------- next part -------------- An HTML attachment was scrubbed... URL: From jsteve at superglobalmegacorp.com Tue Jan 1 21:43:50 2019 From: jsteve at superglobalmegacorp.com (Jason Stevens) Date: Tue, 1 Jan 2019 11:43:50 +0000 Subject: [TUHS] NCC a K&R C compiler for the AMD 64 Message-ID: I found this project online recently.  For those who love K&R and the 64 bit world. https://github.com/gnuless/ncc It outputs to a custom a.out format so it's not immediately usable. It's a dual clause BSD license too! -------------- next part -------------- An HTML attachment was scrubbed... URL: From gtaylor at tnetconsulting.net Wed Jan 2 01:48:00 2019 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Tue, 1 Jan 2019 09:48:00 -0600 Subject: [TUHS] Idea of Small Curators Group for Unix Archive In-Reply-To: References: <20190101033122.GA8802@minnie.tuhs.org> Message-ID: <8A75989D-A158-4346-BCED-F0F2A1EB1602@tnetconsulting.net> I know that I don’t have the expertise. But I have some bandwidth that I can offer as a mirror if desired. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2364 bytes Desc: not available URL: From krewat at kilonet.net Wed Jan 2 03:26:52 2019 From: krewat at kilonet.net (Arthur Krewat) Date: Tue, 1 Jan 2019 12:26:52 -0500 Subject: [TUHS] Idea of Small Curators Group for Unix Archive In-Reply-To: References: <20190101033122.GA8802@minnie.tuhs.org> Message-ID: I too have 10's of TB's of disk space, dedicated gigabit fiber, static IP addresses, and plenty of CPU horsepower in VMware and raw hardware, as well as an unlimited hosting account for external space. Full RAIDZ2 (Solaris), LTO tape backup, offsite backup, etc. Add me to the list ;) thanks! art k. On 1/1/2019 5:41 AM, Jason Stevens wrote: > If love to help!! > > I have TB's of space at home and work, and 100's of gigs online. > > Get Outlook for Android > > > > > On Tue, Jan 1, 2019 at 11:32 AM +0800, "Warren Toomey" > wrote: > > Happy New Year to you all. It's also the year we will celebrate the > 50th anniversary of the Unix timesharing system. Just FYI, I hope to > be in Los Angeles the week before the 2019 Usenix ATC, to go to the > CHM. Then to Seattle before the ATC to visit the LCM+L, then the ATC. > Hope to see some of you along the way. > > I'm feeling the need to get a few other people to help out curate and > maintain the Unix Archive. Not that it changes very often, but it might > help to have some fresh eyes (and opinions) look at it and add/improve it. > > So if there is any interest from a few of the long-time TUHS members, > please e-mail me. I run Nextcloud on the server, so if you can run a > client at your end and have about 4G spare disk space (or less if > you are only interested in a specific section), that would be great. > > I'll be away for about 7 days but I'll try to read/respond to e-mails. > > Cheers, Warren > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dot at dotat.at Wed Jan 2 23:54:15 2019 From: dot at dotat.at (Tony Finch) Date: Wed, 2 Jan 2019 13:54:15 +0000 Subject: [TUHS] Deleted lib1 and lib2 in v6, recoverable? In-Reply-To: <201812310657.wBV6vQuW001885@freefriends.org> References: <1546196832.22954.for-standards-violators@oclsc.org> <201812310657.wBV6vQuW001885@freefriends.org> Message-ID: arnold at skeeve.com wrote: > Norman Wilson wrote: > > > But in practice I don't know anyone who uses ar for anything except > > libraries any more > > I know one person. Brian Kernighan maintains an archive of his awk test > suite using ar. Or rather, he did until recently, when I got him to > move to using tar a few months ago. :-) It's also handy for fiddling around with Debian packages: $ ar t /var/cache/apt/archives/dpkg_1.18.25_amd64.deb debian-binary control.tar.gz data.tar.xz $ Tony. -- f.anthony.n.finch http://dotat.at/ Rattray Head to Berwick upon Tweed: West or northwest 3 or 4, becoming variable 3 or less, becoming west or southwest 3 or 4 later. Rough at first near Rattray Head and Berwick-upon-Tweed, otherwise slight or moderate. Showers at first. Good. From ron at ronnatalie.com Fri Jan 4 01:52:31 2019 From: ron at ronnatalie.com (ron at ronnatalie.com) Date: Thu, 3 Jan 2019 10:52:31 -0500 Subject: [TUHS] ARPAnrt, and the Unix epoch In-Reply-To: References: Message-ID: <051901d4a37c$56a6ef40$03f4cdc0$@ronnatalie.com> Yes, it was a string of changes the network did on January 1. A few years earlier (1980?) they switched to long leaders on the IMPs on Jan 1. This Jan 1 cutover meant that Mike Muuss and his staff (including me) at BRL always had work to do over the holidays. Shutting off NCP support was easy. All NCP control messages traveled on the IMP link 0. IP traveled on link 155. The IMPs were a gentle test for IP. The virtual circuits were reliable and flowed controlled even if the early TCPs were ornery. A good IP implementation did try to deal with the RFNM throttling. The only real issue is the MTU mismatch between Ethernet and the IMP (1008 vs. 1500). A while later, I noticed that the BRL Gateway (an early IP router) was printing out messages that it was receiving link 0 messages. Someone had unblocked link 0, and there was some site out there was still some NCP host trying to contact us (we had moved all our actual hosts OFF the outside imps in favor of a pair of BRL Gateways). Our interior network at that point also comprised a handful of our own class B addressed IMPs. An amusing story there was as they were delivered and uncrated by the BBN guys I was running around connecting up the data trunks and plugging hosts into them. I sent a message to our BBN contact and told them that I had done this and I got a long message back explaining it was impossible. I'm sure glad I didn't know it was impossible when I did it. Later on, Joe Pistritto managed to get the NOC protocol spec out of someone, and we wrote our own NOC for the private IMP network. Still, when they finally split the Arpanet from the Milnet, we got them to do it on the first of the Fiscal Year (October) which fit our time schedule at the labs a lot better. Amusingly, there was one small hitch with the "MAILBRIDGE" gateways that connected the two networks. Apparently, BBN forgot that we had the only IP router that was connected to the MILNET (other than the MAILBRIDGES) and they screwed up that routing. From ron at ronnatalie.com Fri Jan 4 02:04:49 2019 From: ron at ronnatalie.com (ron at ronnatalie.com) Date: Thu, 3 Jan 2019 11:04:49 -0500 Subject: [TUHS] Magic numbers Message-ID: <083c01d4a37e$0e2af4d0$2a80de70$@ronnatalie.com> The issue of a.out magic numbers came up. The a.out header was 16 bytes. The first two bytes was 0407 in the original code. This was followed by 16 bit quantities for text, data, and bss sizes. Then the size of the symbol tables. I'm pretty sure the rest of the fields were blank in V6. Later a start address (previously always assumed to be zero) was added. The number 407 was a neat kludge. It was a (relative) branch instruction on the PDP-11. 0400 was the base op code. 7 referred to jumping ahead 7 words which skipped you over the a.out header (the PC had already been incremented for the branch instruction itself). This allowed you to make a boot block without having to strip off the header. Boot blocks were just one 512 byte block loaded from block zero of the disk into low memory. Later executables used 410 for a write protected text segment and 411 for split-I/D executables. Later versions added more codes (413 was used in BSD to indicate aligned pages followed etc... Even later systems coded the hardware type into the magic number to distinguish between different architectures. Note that the fact that 410 and 411 were also PDP-11 branch instructions wasn't ever really used for anything. From don at donhopkins.com Fri Jan 4 12:34:38 2019 From: don at donhopkins.com (Don Hopkins) Date: Fri, 4 Jan 2019 03:34:38 +0100 Subject: [TUHS] NSA MILNET IMP 57 & Explosive Bolts In-Reply-To: References: Message-ID: <1C76403B-6684-4AA5-BEFF-FDFE19A08229@donhopkins.com> (I originally posted this to hacker news, but I’ll repost it here too.) At the University of Maryland, our network access was through the NSA's "secret" MILNET IMP 57 at Fort Mead. It was pretty obvious that UMD got their network access via NSA, because mimsy.umd.edu had a similar "*.57" IP address as dockmaster, tycho and coins. https://emaillab.jp/dns/hosts/ HOST : 26.0.0.57 : TYCHO : PDP-11/70 : UNIX : TCP/TELNET,TCP/SMTP,TCP/FTP : HOST : 26.0.0.57 : DOCKMASTER.NCSC.MIL,DOCKMASTER.DCA.MIL, DOCKMASTER.ARPA : HONEYWELL-DPS-8/70 : MULTICS : TCP/TELNET,TCP/FTP,TCP/SMTP,TCP/ECHO,TCP/DISCARD,ICMP : HOST : 26.1.0.57 : COINS-GATEWAY,COINS : PLURIBUS : PLI :: HOST : 26.2.0.57, 128.8.0.8 : MARYLAND,MIMSY,UMD-CSD,UMD8,UMCP-CS : VAX-11/780 : UNIX : TCP/TELNET,TCP/FTP,TCP/SMTP,UDP,TCP/ECHO,TCP/FINGER,ICMP : https://multicians.org/site-dockmaster.html Whenever the network went down (which was often), we had to call up a machine room at Fort Mead and ask them to please press the reset button on the box labeled "IMP 57". Sometimes the helpful person who answered the phone had no idea which box I meant, so I had describe to him which box to reset over the phone. ("Nope, that didn't work. Try the other one!" ;) They were even generous enough to issue us (CS department systems staff and undergrad students) our own MILNET TACACS card. On mimsy, you could get a list of NSA employees by typing "grep contact /etc/passwd", because each of their courtesy accounts had "network contact" in the gecos field. Before they rolled out TACACS cards, anyone could dial up an IMP and log in without a password, and connect to any host they wanted to, without even having to murder anyone like on TV: https://www.youtube.com/watch?v=hVth6T3gMa0 I found this handy how-to tutorial guide for "Talking to the Milnet NOC" and resetting the LH/DH, which was useful for guiding the NSA employee on the other end of the phone through fixing their end of the problem. What it doesn't mention is that the key box with the chase key was extremely easy to pick with a paperclip. Who would answer the Milnet NOC's 24-hour phone was hit or miss: Some were more helpful and knowledgeable than others, others were quite uptight. Once I told the guy who answered, "Hi, this is the University of Maryland. Our connection to the NSA IMP seems to be down." He barked back: "You can't say that on the telephone! Are you calling on a blue phone?" (I can't remember the exact color, except that it wasn't red: that I would have remembered). I said, "You can't say NSA??! This is a green phone, but there's a black phone in the other room that I could call you back on, but then I couldn't see the hardware." And he said "No, I mean a voice secure line!" I replied, "You do know that this is a university, don't you? We only have black and green phones.” Date: Thu, 11 Sep 86 13:53:45 EDT From: Steve D. Miller To: staff at mimsy.umd.edu Subject: Talking to the Milnet NOC This message is intended to be a brief tutorial/compendium of information you probably want to know if you need to see about getting the LH/DH thingy (and us) talking to the world. First, you need the following numbers: (1) Our IMP number (57), (2) Mimsy's milnet host address (26.2.0.57), (3) The circuit number for our link to the NSA (DSEP07500-057) (4) The NOC number itself (692-5726). Second, you need to know something about the hardware. There are three pieces of hardware that make up our side of the link: the LH/DH itself, the ECU, and the modem. The LH/DH and the ECU are the things in the vax lab by brillig; the ECU is the thing on top (with the switches), and the LH/DH is the thing on the bottom. The normal state is to have the four red LEDs on the ECU on and the Host Master Ready, HRY, Imp Master Ready, and IRY lights on at the LH/DH. If these lights are not on, something is wrong. If mimsy is down, then we'll only have some of the lights on, but that should fix itself when mimsy comes up. Some interesting buttons or switches on the ECU are: reset - resets something or another stop - stops something or another start - restarts something or another local loopback -- two switches and two leds; you may need to throw one or the other of these if the NOC asks you to. These loopback switches should be distinguished from those on the modem itself. remote loopback -- like local loopback, but does something else. The modem is in the phone room beside the terminal room (rm. 4322, if memory serves). It can be opened with the chase key from the key box...but if someone official and outside of staff asks you that, you probably shouldn't admit to it. It has a switch on it, too; it seems that switch normally rests in the middle, and there's a "LL" setting to the left which I assume puts the modem in local loopback mode. Now that you have some idea of where things are, call the NOC. Identify yourself as from the University of Maryland, and say that we're not talking to the outside world. They will probably ask for our Milnet address or the number of the IMP we're connected to, and will then poke about and see what's happening. They will ask you to do various things; ask if you're not sure what they mean, but the background info above should help in puzzling it out. Hopefully, this will make it easier to find people to fix our net problems in the future; it's still hard to do 'cause we have so little info (no hardware manual, for example), but this should give us a fighting chance. -Steve There were rumored to be "explosive bolts" on the ARPA/MILNET gateways (whether they were metaphorical or not, I don't know). Here's something interesting that Milo Medin wrote about dual homed sites like NSA and NASA, that were on both the ARPANET and MILNET: To: fair at ucbarpa.berkeley.edu (Erik E. Fair) Cc: Hackers_Guild at ucbvax.berkeley.edu, ucdavis!ccohesh at ucbvax.berkeley.edu Subject: Re: a question of definition Date: Thu, 29 Jan 87 15:33:35 PST From: Milo S. Medin (NASA ARC Code ED) Right, the core has many gateways on it now, maybe 20-30. All the LSI's will be stubbed off the core however, and only buttergates will be left after the mailbridges and EGP peers are all converted. Actually, I think DARPA is paying for it all... Ames is *not* getting a mailbridge. You are right of course, that we could use 2 gateways, not just 1 (actually, there will be a prime and backup anyways), and then push routing info appropriately. But that's anything but simple. Firstly, the hosts have to know which gateway to send a packet to a given network, and thus have to pick between the 2. That's a bad idea. It also means that I have to pass all EGP learned info around on the local cable, and if I do that, then I can't have routing info from the local cable pass out via EGP. At least not without violating the current EGP spec. Think about it. It'd be really simple to create a loop that way. Thus, in order to maximize the use of both PSN's, you really need one gateway wired to both PSN's, and just have it advertise a default route inside. Or use a reasonble IGP, of which RIP (aka /etc/routed stuff) is not. I'm hoping to get an RFC out of BBN at this IETF meeting which may go a long way in reducing the use of RIP as an IGP. BTW, NSA is an example of a site on both MILNET and ARPANET but without a mailbridge... There is no restriction that a network can only be on ARPANET or MILNET. That goes against the Internet model of doing things. Our local NASA gatewayed nets will be advertised on both sides. The restriction on BARRNet is that the constituent elements of BARRNet do not all have access to MILNET. NSF has an understanding with DARPA and DCA that NSFnet'd sites can use ARPANET. That does not extend to the MILNET. Thus, Davis can use UCB's or Stanford's, our even NASA's ARPANET gateways, with the approval of the site of course, but not MILNET, even though NASA has MILNET coverage. Thus we are required to restrict BARRNet routing through our MILNET PSN. If we were willing to sponsor UCB's MILNET access, for some requirement which NASA had to implement, then we would turn that on. But BARRNet itself will but cutoff to MILNET (and probably ARPANET too) at Ames, but not cut off to other NASA centers or sites that NASA connects. There is no technical reason that prevents this, in fact, we have to take special measures to prevent it. But those are the rules. Anyways, mailbridge performance should improve after the conversion, so UCB should be in better shape. And you'll certainly be able to talk to us via BARRNnet... I have noticed recently that MILNET<-> ARPANET performance has been particularly poor... Sigh. The DCA folks feel that in case of an emergency they may be forced to use an unsecure network to pass certain info around. The DDN brochure mentions SIOP related data for example. Who knows, if the balloon goes up, the launch order might pass through Evans Hall on its way out to SAC... :-) Milo I dug up an "explosive bolts" reference -- fortunately that brilliant plan didn't get far. (Milo Medin knows this stuff first hand: https://innovation.defense.gov/Media/Biographies/Bio-Display/Article/1395855/milo-medin/ ) To: fair at ucbarpa.berkeley.edu (Erik E. Fair) Cc: ucdavis!ccohesh at ucbvax.berkeley.edu, Hackers_Guild at ucbvax.berkeley.edu Subject: Re: a question of definition Date: Thu, 29 Jan 87 12:29:36 PST From: Milo S. Medin (NASA ARC Code ED) Actually its: SCINET -- Secret Compartmented Information Net (if you don't know what compartmented means, you don't need to ask) DODIIS -- DoD Intelligence Information Net The other stuff I think is right, at least without me looking things up. I probably shouldn't have brought this subject of the secure part of the DDN up. People like being low key about such things... Erik, all the BBN gateways on MILNET and ARPANET currently comprise the core, not just mailbridges. Some are used as site gateways, others as EGP neighbors, etc... And just because you are dual homed doesn't mean you get a mailbridge. And the IETF doesn't deal with low level stuff like that; DCA does all that. In fact, the reason we are getting an ARPANET PSN is because when DCA came out to do a site survey, they liked our site so much they asked if they could put one here! It's amazing how many sites have tried to get ARPANET PSN's the right way and have had to wait much longer than us... BTW, since we are dual homed (probably a gateway with 2 1822 interfaces in it), we are taking steps to be sure that people on ARPANET or MILNET can't use our gateway to bypass the mailbridges. The code will be hacked to drop all packets that aren't going to a locally reachable network. BARRNet, even though its locally reachable, will be excluded from this however, since the current procedural limitations call for not allowing any BARRNet traffic to flow out of BARRNet to MILNET and the reverse. NASA traffic of course can traffic through BARRNet, and even use ARPANET that way (though that's not a big deal when we get our own ARPANET PSN). That's because only NASA is authorized to directly connect to MILNET, not UCB or Stanford, etc... DCA must have the ability to partition the ARPANET and MILNET in case of an "emergency", and having non-DCA controlled paths between the nets prevents that. There was talk some time ago about putting explosive bolts in the mailbridges that would be triggered by destruct packets... That idea didn't get far though... The DDN only includes MILNET,ARPANET,SCINET,etc... Not the attached networks. If it did, you'd need to file a TSR to add a PC to your local cable. A TSR is a monstrous piece of paperwork that needs to be done anytime anything is changed on the DDN... Rick knows all about them don't you Rick? The whole network game is filled with acronyms! I gave up trying to write documents with full explainations in terms long ago... I have yet to see a short and concise (and correct) way of describing DDN X.25 Standard Service for example... That's probably one of the harder things about getting into networking these days. We won't even talk about Etherbunnies and Martians and other Millspeak... Milo '1822' Medin From krewat at kilonet.net Fri Jan 4 12:54:58 2019 From: krewat at kilonet.net (Arthur Krewat) Date: Thu, 3 Jan 2019 21:54:58 -0500 Subject: [TUHS] NSA MILNET IMP 57 & Explosive Bolts In-Reply-To: <1C76403B-6684-4AA5-BEFF-FDFE19A08229@donhopkins.com> References: <1C76403B-6684-4AA5-BEFF-FDFE19A08229@donhopkins.com> Message-ID: <83de09a0-a8ab-0abc-dc99-60127d9fab05@kilonet.net> 415-327-5220 On 1/3/2019 9:34 PM, Don Hopkins wrote: > (I originally posted this to hacker news, but I’ll repost it here too.) > > > > At the University of Maryland, our network access was through the NSA's "secret" MILNET IMP 57 at Fort Mead. It was pretty obvious that UMD got their network access via NSA, because mimsy.umd.edu had a similar "*.57" IP address as dockmaster, tycho and coins. > > https://emaillab.jp/dns/hosts/ > > HOST : 26.0.0.57 : TYCHO : PDP-11/70 : UNIX : TCP/TELNET,TCP/SMTP,TCP/FTP : > HOST : 26.0.0.57 : DOCKMASTER.NCSC.MIL,DOCKMASTER.DCA.MIL, DOCKMASTER.ARPA : HONEYWELL-DPS-8/70 : MULTICS : TCP/TELNET,TCP/FTP,TCP/SMTP,TCP/ECHO,TCP/DISCARD,ICMP : > HOST : 26.1.0.57 : COINS-GATEWAY,COINS : PLURIBUS : PLI :: > HOST : 26.2.0.57, 128.8.0.8 : MARYLAND,MIMSY,UMD-CSD,UMD8,UMCP-CS : VAX-11/780 : UNIX : TCP/TELNET,TCP/FTP,TCP/SMTP,UDP,TCP/ECHO,TCP/FINGER,ICMP : > > https://multicians.org/site-dockmaster.html > > Whenever the network went down (which was often), we had to call up a machine room at Fort Mead and ask them to please press the reset button on the box labeled "IMP 57". Sometimes the helpful person who answered the phone had no idea which box I meant, so I had describe to him which box to reset over the phone. ("Nope, that didn't work. Try the other one!" ;) They were even generous enough to issue us (CS department systems staff and undergrad students) our own MILNET TACACS card. > > On mimsy, you could get a list of NSA employees by typing "grep contact /etc/passwd", because each of their courtesy accounts had "network contact" in the gecos field. > > Before they rolled out TACACS cards, anyone could dial up an IMP and log in without a password, and connect to any host they wanted to, without even having to murder anyone like on TV: > > https://www.youtube.com/watch?v=hVth6T3gMa0 > > > > I found this handy how-to tutorial guide for "Talking to the Milnet NOC" and resetting the LH/DH, which was useful for guiding the NSA employee on the other end of the phone through fixing their end of the problem. What it doesn't mention is that the key box with the chase key was extremely easy to pick with a paperclip. > > Who would answer the Milnet NOC's 24-hour phone was hit or miss: Some were more helpful and knowledgeable than others, others were quite uptight. > > Once I told the guy who answered, "Hi, this is the University of Maryland. Our connection to the NSA IMP seems to be down." He barked back: "You can't say that on the telephone! Are you calling on a blue phone?" (I can't remember the exact color, except that it wasn't red: that I would have remembered). I said, "You can't say NSA??! This is a green phone, but there's a black phone in the other room that I could call you back on, but then I couldn't see the hardware." And he said "No, I mean a voice secure line!" I replied, "You do know that this is a university, don't you? We only have black and green phones.” > > Date: Thu, 11 Sep 86 13:53:45 EDT > From: Steve D. Miller > To: staff at mimsy.umd.edu > Subject: Talking to the Milnet NOC > > This message is intended to be a brief tutorial/compendium of > information you probably want to know if you need to see about > getting the LH/DH thingy (and us) talking to the world. > > First, you need the following numbers: > (1) Our IMP number (57), > (2) Mimsy's milnet host address (26.2.0.57), > (3) The circuit number for our link to the NSA > (DSEP07500-057) > (4) The NOC number itself (692-5726). > > Second, you need to know something about the hardware. There > are three pieces of hardware that make up our side of the link: > the LH/DH itself, the ECU, and the modem. The LH/DH and the > ECU are the things in the vax lab by brillig; the ECU is the > thing on top (with the switches), and the LH/DH is the thing > on the bottom. The normal state is to have the four red LEDs > on the ECU on and the Host Master Ready, HRY, Imp Master Ready, > and IRY lights on at the LH/DH. If these lights are not on, > something is wrong. If mimsy is down, then we'll only have some > of the lights on, but that should fix itself when mimsy comes up. > Some interesting buttons or switches on the ECU are: > reset - resets something or another > stop - stops something or another > start - restarts something or another > local loopback -- two switches and two leds; you may need > to throw one or the other of these if the NOC asks > you to. These loopback switches should be distinguished > from those on the modem itself. > remote loopback -- like local loopback, but does something else. > > The modem is in the phone room beside the terminal room (rm. > 4322, if memory serves). It can be opened with the chase key from > the key box...but if someone official and outside of staff asks > you that, you probably shouldn't admit to it. It has a switch on > it, too; it seems that switch normally rests in the middle, and > there's a "LL" setting to the left which I assume puts the modem in > local loopback mode. > > Now that you have some idea of where things are, call the NOC. > Identify yourself as from the University of Maryland, and say that > we're not talking to the outside world. They will probably ask for > our Milnet address or the number of the IMP we're connected to, > and will then poke about and see what's happening. They will ask > you to do various things; ask if you're not sure what they mean, > but the background info above should help in puzzling it out. > > Hopefully, this will make it easier to find people to fix > our net problems in the future; it's still hard to do 'cause > we have so little info (no hardware manual, for example), > but this should give us a fighting chance. > > -Steve > > > > There were rumored to be "explosive bolts" on the ARPA/MILNET gateways (whether they were metaphorical or not, I don't know). > > Here's something interesting that Milo Medin wrote about dual homed sites like NSA and NASA, that were on both the ARPANET and MILNET: > > To: fair at ucbarpa.berkeley.edu (Erik E. Fair) > Cc: Hackers_Guild at ucbvax.berkeley.edu, ucdavis!ccohesh at ucbvax.berkeley.edu > Subject: Re: a question of definition > Date: Thu, 29 Jan 87 15:33:35 PST > From: Milo S. Medin (NASA ARC Code ED) > > Right, the core has many gateways on it now, maybe 20-30. All the LSI's will > be stubbed off the core however, and only buttergates will be left after > the mailbridges and EGP peers are all converted. Actually, I think DARPA is > paying for it all... > > Ames is *not* getting a mailbridge. You are right of course, that we could > use 2 gateways, not just 1 (actually, there will be a prime and backup anyways), > and then push routing info appropriately. But that's anything but simple. > Firstly, the hosts have to know which gateway to send a packet to a given > network, and thus have to pick between the 2. That's a bad idea. > It also means that I have to pass all EGP learned info around on the > local cable, and if I do that, then I can't have routing info from > the local cable pass out via EGP. At least not without violating > the current EGP spec. Think about it. It'd be really simple to > create a loop that way. Thus, in order to maximize the use of both > PSN's, you really need one gateway wired to both PSN's, and just > have it advertise a default route inside. Or use a reasonble IGP, > of which RIP (aka /etc/routed stuff) is not. I'm hoping to get > an RFC out of BBN at this IETF meeting which may go a long way in > reducing the use of RIP as an IGP. > > BTW, NSA is an example of a site on both MILNET and ARPANET but without > a mailbridge... > > There is no restriction that a network can only be on ARPANET or MILNET. > That goes against the Internet model of doing things. Our local > NASA gatewayed nets will be advertised on both sides. The restriction > on BARRNet is that the constituent elements of BARRNet do not all > have access to MILNET. NSF has an understanding with DARPA and > DCA that NSFnet'd sites can use ARPANET. That does not extend to > the MILNET. Thus, Davis can use UCB's or Stanford's, our even NASA's > ARPANET gateways, with the approval of the site of course, but > not MILNET, even though NASA has MILNET coverage. Thus we are required > to restrict BARRNet routing through our MILNET PSN. If we were willing > to sponsor UCB's MILNET access, for some requirement which NASA > had to implement, then we would turn that on. But BARRNet itself will > but cutoff to MILNET (and probably ARPANET too) at Ames, but not > cut off to other NASA centers or sites that NASA connects. There is > no technical reason that prevents this, in fact, we have to take > special measures to prevent it. But those are the rules. Anyways, > mailbridge performance should improve after the conversion, so > UCB should be in better shape. And you'll certainly be able to > talk to us via BARRNnet... I have noticed recently that MILNET<-> > ARPANET performance has been particularly poor... Sigh. > > The DCA folks feel that in case of an emergency they may be > forced to use an unsecure network to pass certain info around. The > DDN brochure mentions SIOP related data for example. Who knows, > if the balloon goes up, the launch order might pass through Evans > Hall on its way out to SAC... :-) > > > Milo > > > > I dug up an "explosive bolts" reference -- fortunately that brilliant plan didn't get far. > > (Milo Medin knows this stuff first hand: https://innovation.defense.gov/Media/Biographies/Bio-Display/Article/1395855/milo-medin/ ) > > To: fair at ucbarpa.berkeley.edu (Erik E. Fair) > Cc: ucdavis!ccohesh at ucbvax.berkeley.edu, Hackers_Guild at ucbvax.berkeley.edu > Subject: Re: a question of definition > Date: Thu, 29 Jan 87 12:29:36 PST > From: Milo S. Medin (NASA ARC Code ED) > > Actually its: > > SCINET -- Secret Compartmented Information Net (if you don't know what > compartmented means, you don't need to ask) > DODIIS -- DoD Intelligence Information Net > > The other stuff I think is right, at least without me looking things > up. I probably shouldn't have brought this subject of the secure part > of the DDN up. People like being low key about such things... > > Erik, all the BBN gateways on MILNET and ARPANET currently comprise > the core, not just mailbridges. Some are used as site gateways, others > as EGP neighbors, etc... And just because you are dual homed doesn't mean > you get a mailbridge. And the IETF doesn't deal with low level stuff > like that; DCA does all that. In fact, the reason we are getting an > ARPANET PSN is because when DCA came out to do a site survey, they > liked our site so much they asked if they could put one here! It's > amazing how many sites have tried to get ARPANET PSN's the right > way and have had to wait much longer than us... BTW, since we are > dual homed (probably a gateway with 2 1822 interfaces in it), we > are taking steps to be sure that people on ARPANET or MILNET can't > use our gateway to bypass the mailbridges. The code will be hacked > to drop all packets that aren't going to a locally reachable network. > BARRNet, even though its locally reachable, will be excluded > from this however, since the current procedural limitations call for > not allowing any BARRNet traffic to flow out of BARRNet to MILNET > and the reverse. NASA traffic of course can traffic through BARRNet, > and even use ARPANET that way (though that's not a big deal when > we get our own ARPANET PSN). That's because only NASA is authorized > to directly connect to MILNET, not UCB or Stanford, etc... > > DCA must have the ability to partition the ARPANET and MILNET in > case of an "emergency", and having non-DCA controlled paths between > the nets prevents that. There was talk some time ago about putting > explosive bolts in the mailbridges that would be triggered by > destruct packets... That idea didn't get far though... > > The DDN only includes MILNET,ARPANET,SCINET,etc... Not the attached > networks. If it did, you'd need to file a TSR to add a PC to your > local cable. A TSR is a monstrous piece of paperwork that needs to > be done anytime anything is changed on the DDN... Rick knows all > about them don't you Rick? > > The whole network game is filled with acronyms! I gave up trying > to write documents with full explainations in terms long ago... > I have yet to see a short and concise (and correct) way of describing > DDN X.25 Standard Service for example... That's probably one of the > harder things about getting into networking these days. We won't > even talk about Etherbunnies and Martians and other Millspeak... > > Milo '1822' Medin > > > From web at loomcom.com Sat Jan 5 07:07:47 2019 From: web at loomcom.com (Seth J. Morabito) Date: Fri, 04 Jan 2019 13:07:47 -0800 Subject: [TUHS] AT&T / Teletype DMD 5620 Emulator Message-ID: <8736q8xhb0.fsf@loomcom.com> Hello folks, I realized I should mention this here on TUHS, since it is likely of interest to at least some of you! I recently wrote a DMD 5620 emulator, currently available on Linux and Macintosh, with Windows support coming soon. Here's a brief demo of the Mac version: https://www.youtube.com/watch?v=tcSWqBmAMeY I wrote it because DMD 5620s are becoming incredibly rare, and showing them off in person is quite difficult nowadays. This emulator is using ROM version 2.0 (8;7;5) dumped from my personal 5620. If anyone out there has a DMD 5620 with an older ROM, I would be incredibly grateful if you could dump the ROMs. I'd like to find versions of 1.x (8;7;3 or earlier); so far I've had no luck. The main reason I'm interested in older ROMs, besides pure preservation reasons, is that the 'mux' and 'muxterm' system on Research UNIX V8/V9 is hard-coded for the 1.1 ROMs. It doesn't work with the emulator without significant tweaking of the source. It DOES work perfectly well with the DMD Core Utilities package for the AT&T 3B2, however. All the best! -Seth -- Seth Morabito Poulsbo, WA, USA web at loomcom.com From clemc at ccc.com Sat Jan 5 07:50:33 2019 From: clemc at ccc.com (Clem Cole) Date: Fri, 4 Jan 2019 16:50:33 -0500 Subject: [TUHS] AT&T / Teletype DMD 5620 Emulator In-Reply-To: <8736q8xhb0.fsf@loomcom.com> References: <8736q8xhb0.fsf@loomcom.com> Message-ID: Very cool!!! Looking forward to playing with it. ᐧ On Fri, Jan 4, 2019 at 4:18 PM Seth J. Morabito wrote: > > Hello folks, > > I realized I should mention this here on TUHS, since it is likely of > interest to at least some of you! > > I recently wrote a DMD 5620 emulator, currently available on Linux and > Macintosh, with Windows support coming soon. Here's a brief demo of the > Mac version: > > https://www.youtube.com/watch?v=tcSWqBmAMeY > > I wrote it because DMD 5620s are becoming incredibly rare, and showing > them off in person is quite difficult nowadays. > > This emulator is using ROM version 2.0 (8;7;5) dumped from my personal > 5620. If anyone out there has a DMD 5620 with an older ROM, I would be > incredibly grateful if you could dump the ROMs. I'd like to find > versions of 1.x (8;7;3 or earlier); so far I've had no luck. > > The main reason I'm interested in older ROMs, besides pure preservation > reasons, is that the 'mux' and 'muxterm' system on Research UNIX V8/V9 > is hard-coded for the 1.1 ROMs. It doesn't work with the emulator > without significant tweaking of the source. It DOES work perfectly well > with the DMD Core Utilities package for the AT&T 3B2, however. > > All the best! > > -Seth > -- > Seth Morabito > Poulsbo, WA, USA > web at loomcom.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From don at donhopkins.com Sat Jan 5 08:43:58 2019 From: don at donhopkins.com (Don Hopkins) Date: Fri, 4 Jan 2019 23:43:58 +0100 Subject: [TUHS] NSA MILNET IMP 57 & Explosive Bolts In-Reply-To: References: <1C76403B-6684-4AA5-BEFF-FDFE19A08229@donhopkins.com> Message-ID: <0906195E-E904-4D29-8F59-DEFC63B36079@donhopkins.com> On 4 Jan 2019, at 21:46, Clem Cole wrote: >From where did that wonderful clip come? It's clearly a sequence from something else. I've never seen it before. >Thanks, >Clem They were from my email archives of Hackers_Guild and the umd cs department staff mailing list. Does anybody else have any h_g archives sitting around? Here’s some more funny stuff about the NSA! Gotta love how Brian Reid and Rick Adams weigh in. ;) -Don From: yee at dali.berkeley.edu (Peter E. Yee) Subject: For those who missed 997 at lll-crg, here it is Date: 19 November 1985 at 15:58:08 CET To: hackers_guild at ucbvax.berkeley.edu Relay-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site lll-crg.ARpA Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site lll-crg.ARpA Path: lll-crg!bandy From: bandy at lll-crg.ARpA (Andrew Scott Beals) Newsgroups: net.net-people Subject: oh YES the NSA is on the net! Message-ID: <997 at lll-crg.ARpA> Date: 19 Nov 85 07:11:36 GMT Date-Received: 19 Nov 85 07:11:36 GMT References: <324 at ucdavis.UUCP> <2253 at umcp-cs.UUCP> Reply-To: bandy at lll-crg.UUCP (Andrew Scott Beals) Distribution: net Organization: Computation Research Group, Lawrence Livermore Labs Lines: 94 Summary: (let's say) unintentional dis-information corrected In article <2253 at umcp-cs.UUCP> tlr at umcp-cs.UUCP (Terry L. Ridder) writes: I can almost guarantee that the National Security Agency is not on USENET or ARPANET. I can further almost guarantee that very few employees of NSA are even aware that USENET exist. Signed Terry L. Ridder UUCP: seismo!(mimsy.umd.edu|neurad)!bilbo!wiretap!(root|tlr) ^^^^^^^ PHONE: 301-490-2248 (home) 301-859-6642 (work) Right. There used to be a host called "TYCHO" (nickname "NSA") at host zero on imp fifty-seven. (26.0.0.57) (information taken from the old NIC (Network Information Center for Internet) host tables) Now there is a machine called "DOCKMASTER" on that same imp port (TYCHO was an old PDP-11 running version 6 unix (which rumors had flown for quite some time that someone actually proved was secure)). Here is what the NIC has to say about DOCKMASTER: The National Computer Security Center (DOCKMASTER) 820 Elkridge Landing Road Room A1127, Building FANX-II Linthicum, MD 21090 NetAddress: 26.0.0.57 Nicknames: NCSC-MULTICS Host Administrator and Liaison: Aliff, Stephen W. (SWA1) Aliff.DODCSC at MIT-MULTICS (301) 850-5888 Multics, if I remember correctly, was just given some level of certification by the government that it was secure. Interesting, no? Unfortunately, I'm not nearly as much of a Packrat as some might like to think so I don't have a Maryland phone book (I do have my silly putty though), so I can't tell you where this exchange is located (nor where Terry's work number is located). However, looking up Linthicum MD (I was born and raised just north of DC) shows that it's just north of BWI (airport). There is a NASA center right near there and next to that is an un-marked (of course) NSA center. All of this points that imp 57 is still NSA's imp. NIC has this to say about host 1 on imp 57: National Security Agency (COINS-GATEWAY) COINS Network Control Center Fort George G. Meade, MD 20755 NetAddress: 26.1.0.57 Nicknames: COINS Host Administrator and Liaison: Smith, Ronald L. (RLS6) COINS at USC-ISI (301) 688-6375 The NIC generally likes to give a machine the name "-GATEWAY" when that machine is a gateway into another part of the internet. (the machine type of COINS is a Plurbus, which is a multiprocessor gateway machine manufactured by BBN (the folks who do the ARPANET and MILNET hardware). In any case, it seems that Mr Ridder is un-(or mis-?)informed. Side note: at the last (Portland) USENIX, I happened across a gentlemen (very cleancut) whose badge listed him as working for the "Department of Defense, Fort Meade Maryland". I said "Oh, you're one of those NSA guys!" To which he replied "How did you know?!"... "Everyone else in DOD says /which/ part of DOD they work for..." andrew scott beals lawrence livermore national laboratory/university of california Pooh-bah for LLL-CRG.ARPA (415) 423-1948 (work) (533-1948 (FTS)) ps. In case anyone is wondering and before you go giving my name to people that I don't want to talk to (like the Kind Folks at the NSA (but I'm sure they've heard of me or will before I finish up with my current round of paperwork with the DOE/OPM/FBI)), I obtained all of this information through public channels. -- There once was a thing called a V-2, To pilot which you did not need to-- You just pushed a button, And it would leave nuttin' But stiffs and big holes and debris, too. andy beals - bandy at lll-crg.arpa - {seismo,ihnp4!sun,dual}!lll-crg!bandy From: jordan at ucbarpa.berkeley.edu (Jordan Hayes) Subject: Re: ``dockmaster'' Date: 19 November 1985 at 16:27:34 CET To: hackers_guild at ucbvax.berkeley.edu for those so inclined, they should look at what is on port 2 of that imp ... hmmm ... sorta like putting the CIA on port 4 of imp 78 ... /jordan From: Andrew Scott Beals Subject: Re: ``dockmaster'' Date: 19 November 1985 at 18:27:27 CET To: hackers_guild at ucbvax.berkeley.edu, jordan at ucbarpa.berkeley.edu Maryland lets NSA people use mimsy. The NSA is interested in the supercomputer designs that they're working on there... (which is why they have an imp connection) In any case, I just got a long note from Mr Ridder. I'll forward it to you when I'm done reading my mail... andy From: Andrew Scott Beals Subject: message from Mr. Ridder Date: 19 November 1985 at 18:31:44 CET To: hackers_guild at lll-crg.ARPA From tlr at mimsy.umd.edu Tue Nov 19 06:13:44 1985 Date: Tue, 19 Nov 85 09:12:54 EST From: Terry L. Ridder Subject: Your posting Mr. Andrew Scott Beals I am writing to inform you of at least two facts: The computer named "wiretap" belongs to my children, age 9, age 7, age 2. Jennifer, the 7 year old, named the computer. Sarah, the 9 year old, named the other computer "bilbo". Bilbo and wiretap are both private machines. The are owned by my family and I. They are in no way shape or form associated with the NSA. Concerning your posting, I am concerned that you have no regard for the safety of federal employees. Your posting is marked for distribution "net", if you would look at the two previous posting they are marked for distribution 'usa'. Therefore, you probably have just told most of the world the location of what you believe to be an NSA facility. This probably has made the location a target for any of a number of terrorist groups. What if you are wrong? You have place in danger the lifes of innocent people. Just because you may think you know something does not mean that you tell most of the world. I would hope that in the future that you would take the time to think about all the ramifications before making a posting, similiar in nature to the one in question. I would hope that you will send out a cancel message on your posting, before it gets to far. I sincerely hope that you restrict your speculations about my family's association with any federal agency. I hope also that you are mature enough to post an apology for inferring that my computers were associated with the NSA. I do not want to think of what the implications are from that speculation on your part. You may have damaged my family's reputation and my own reputation. Please be a little more responsible in the future. Engage brain before fingers. Signed Terry L. Ridder for the Terry L. Ridder family --------------------- From: fair at ucbarpa.berkeley.edu (Erik E. Fair) Subject: Re: message from Mr. Ridder Date: 19 November 1985 at 18:42:34 CET To: bandy at lll-crg.ARPA Cc: Hackers_Guild at ucbvax.berkeley.edu I wonder if this bozoid has ever read `The Puzzle Palace'? It identifies several `secret' NSA installations, including one out in the wilds of Sonoma, just over the border from Marin County, along the road from Tomales to Petaluma. All from public sources and Freedom Of Information Act suits. Erik E. Fair ucbvax!fair fair at ucbarpa.berkeley.edu P.S. Be sure to waive hello in your Email to the folks at the Maryland Procurement Office... From: Andrew Scott Beals Subject: Re: message from Mr. Ridder Date: 19 November 1985 at 19:11:36 CET To: fair at ucbarpa.berkeley.edu Cc: Hackers_Guild at ucbvax.berkeley.edu [mimsy.umd.edu] Login name: tlr In real life: Terry L. Ridder Office: Laurel MD 20707 Office phone: 859-6642 Home phone: 490-2248 Arpanet Sponsor Directory: /u/tlr Shell: /bin/csh Last login Tue Nov 19 09:17 on tty04 Project: To find a new job, raise three children, and have time for the wife. Plan: To move overseas. ---------------------- Well, this is what it has to say about him. Arpanet sponsor, eh? andy From: fair at ucbarpa.berkeley.edu (Erik E. Fair) Subject: Re: message from Mr. Ridder Date: 19 November 1985 at 19:48:41 CET To: bandy at lll-crg.ARPA Cc: Hackers_Guild at ucbvax.berkeley.edu Ask Chris Torek what an `Arpanet Sponsor' is... Erik From: Andrew Scott Beals Subject: more follies, dt if uninterested Date: 20 November 1985 at 02:10:30 CET To: hackers_guild at lll-crg.ARPA Seems that the gentleman doesn't read his fucking news before going off at the handle. I sent him an "Excuse me, but if you look at article ..." note. LLL General consul? Snicker snicker. Maybe Postmaster or root or usenet will get a nice note from him telling me what a Bad Boy I've been... :-) andy ----------------------- Date: Tue, 19 Nov 85 18:46:28 EST From: Terry L. Ridder Subject: apology is inorder Mr. Andrew Scott Beals I again ask that you act in a mature manner and post an apology concerning your inferring that my private computers are associated with the NSA. If you choose not to, would you be kind enough to inform me what the phone number is for LLL general consul is? Signed Terry L. Ridder From: jordan at ucbarpa.berkeley.edu (Jordan Hayes) Subject: Re: ridder me this ... Date: 20 November 1985 at 02:59:22 CET To: hackers_guild at ucbvax.berkeley.edu Methinks either the man is an idiot or he's not really a force to be reckoned with. If his main mail machine is mimsy, that means he's on the same imp ... since NSA people have accounts at umd, maybe he's FROM the NSA ... hmmm ... /jordan From: Milo S. Medin (NASA ARC Code ED) Subject: Re: message from Mr. Ridder Date: 20 November 1985 at 03:03:55 CET To: Andrew Scott Beals Cc: fair at ucbarpa.berkeley.edu, Hackers_Guild at ucbvax.berkeley.edu LLL general counsel? uh oh..... That means lawyers.... Milo From: Andrew Scott Beals Subject: ridder me this Date: 20 November 1985 at 03:14:56 CET To: hackers_guild at lll-crg.ARPA One of my sources tells me that Mr Ridder is indeed an NSA person. Chris Torek told me that an "Arpanet Sponsor" in their terminology means that he's one of the people who helped them get on the network. andy From: Andrew Scott Beals Subject: Re: Ridder me this (qualification) Date: 20 November 1985 at 03:31:22 CET To: bandy at ll-crg.ARPA, deboor%buddy at ucbvax.berkeley.edu Cc: hackers_guild at ucbvax.berkeley.edu Oh, I already sent him an apology. Here it is: Relay-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site lll-crg.ARpA Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site lll-crg.ARpA Path: lll-crg!bandy From: bandy at lll-crg.ARpA (Andrew Scott Beals) Newsgroups: net.net-people Subject: Apology to Terry Ridder Message-ID: <998 at lll-crg.ARpA> Date: 19 Nov 85 17:37:12 GMT Date-Received: 19 Nov 85 17:37:12 GMT References: <324 at ucdavis.UUCP> <2253 at umcp-cs.UUCP> <997 at lll-crg.ARpA> Reply-To: bandy at lll-crg.UUCP (Andrew Scott Beals) Distribution: net Organization: Computation Research Group, Lawrence Livermore Labs Lines: 15 I would like to take this opportunity to formally extend my apologies to Terry L. Ridder (tlr at mimsy.umd.edu) and his family for insinuating that their home machines (bilbo and wiretap) and any association with any Federal agency (the NSA in this case). andrew scott beals uc/llnl -- There once was a thing called a V-2, To pilot which you did not need to-- You just pushed a button, And it would leave nuttin' But stiffs and big holes and debris, too. andy beals - bandy at lll-crg.arpa - {seismo,ihnp4!sun,dual}!lll-crg!bandy --------------------- What was interesting was that the file was ~news/net/net-people/666 ... Tee hee hee. andy From: Andrew Scott Beals Subject: calling LLL {lawyers,diplomats} Date: 20 November 1985 at 03:38:35 CET To: hackers_guild at lll-crg.ARPA Of course, they'll tell him that "Anything that our employees say is their own opinion unless they are a member of the LLNL Public Information group and are speaking in an official capacity." "Pin-heads. Pin-heads. Roly-poly pin-heads. Pin-heads. Pin-heads. Watch them lose. Yow!" andy From: Andrew Scott Beals Subject: teehee Date: 20 November 1985 at 17:18:25 CET To: hackers_guild at ucbvax.berkeley.edu From reid at glacier Wed Nov 20 06:59:01 1985 Date: Wed, 20 Nov 85 06:57:35 pst From: Brian Reid Subject: Re: Apology to Terry Ridder Newsgroups: net.net-people Organization: Stanford University, Computer Systems Lab Terry Ridder is one of the biggest assholes on earth, and I can't fathom anybody owing him an apology about anything. Oh well. -- Brian Reid decwrl!glacier!reid Stanford reid at SU-Glacier.ARPA From: Andrew Scott Beals Subject: philngai on tlr Date: 21 November 1985 at 07:21:35 CET To: hackers_guild at lll-crg.ARPA From amdcad!phil Wed Nov 20 20:41:58 1985 Date: Wed, 20 Nov 85 20:08:04 pst From: amdcad!phil (Phil Ngai) Subject: Re: message from Mr. Ridder what kind of asshole names a computer wiretap and then complains when others make seemingly reasonable assumptions about it? who should engage their brain, that's what i want to know. -- Raise snails for fun and profit! Race them for amusement! Then eat the losers! Phil Ngai +1 408 749-5720 UUCP: {ucbvax,decwrl,ihnp4,allegra}!amdcad!phil ARPA: amdcad!phil at decwrl.dec.com From: cuuxb!jab at lll-crg.ARPA Subject: Re: message from Mr. Ridder Date: 24 November 1985 at 02:25:13 CET To: lll-crg!sdcsvax.arpa!hutch at lll-crg.ARPA Cc: lll-crg!hackers_guild at ucbvax.berkeley.edu The Ridder guy is a jerk. I would wonder why the ARPANET knows about his private machines, anyhow: sounds like a misuse of government funding. Jeff Bowles Lisle, IL From: Donnalyn Frey Subject: Re: private machines on internet Date: 24 November 1985 at 06:08:34 CET To: cuuxb!jab at lll-crg.ARPA, deboor%buddy at ucbvax.berkeley.edu Cc: hackers_guild at ucbvax.berkeley.edu Ridders machines are NOT on the arpanet. They have uucp links to Uof Maryland. Ridder himself has an account on mimsy.umd.edu. Ridders two machines were named by his children. ONe had just finished reading teh Hobbit (hence bilbo, despite the 2 other known bilbos [not to be confused with certain dildos being discussed]) and the other had finished some spy book, hence wiretap. He is quite pompous and seems to think the world revolves around him. We asked him to rename "bilbo" to not conflict. He replied that the other machines should change because he had already named his machine. By the way, we're talking about toys here (maybe somthing as expensive as an IBM-PC) not the "real" machines you might be led to believe. He is best ignored. ---rick From don at donhopkins.com Sat Jan 5 08:45:27 2019 From: don at donhopkins.com (Don Hopkins) Date: Fri, 4 Jan 2019 23:45:27 +0100 Subject: [TUHS] Jordan Hubbard's rwall of infamy Message-ID: <3D549A7A-EE33-464E-AB0B-5B52CBDF328E@donhopkins.com> From: jkh at violet.Berkeley.EDU (Jordan K. Hubbard) Subject: My Broadcast Date: 2 April 1987 at 21:45:46 CEST To: hackers_guild at ucbvax.Berkeley.EDU, tcp-ip at sri-nic.arpa By now, many of you have heard of (or seen) the broadcast message I sent to the net two days ago. I have since received 743 messages and have replied to every one (either with a form letter, or more personally when questions were asked). The intention behind this effort was to show that I wasn't interested in doing what I did maliciously or in hiding out afterwards and avoiding the repercussions. One of the people who received my message was Dennis Perry, the Inspector General of the ARPAnet (in the Pentagon), and he wasn't exactly pleased. (I hear his Interleaf windows got scribbled on) So now everyone is asking: "Who is this Jordan Hubbard, and why is he on my screen??" I will attempt to explain. I head a small group here at Berkeley called the "Distributed Unix Group". What that essentially means is that I come up with Unix distribution software for workstations on campus. Part of this job entails seeing where some of the novice administrators we're creating will hang themselves, and hopefully prevent them from doing so. Yesterday, I finally got around to looking at the "broadcast" group in /etc/netgroup which was set to "(,,)". It was obvious that this was set up for rwall to use, so I read the documentation on "netgroup" and "rwall". A section of the netgroup man page said: ... Any of three fields can be empty, in which case it signifies a wild card. Thus universal (,,) defines a group to which everyone belongs. Field names that ... ... Now "everyone" here is pretty ambiguous. Reading a bit further down, one sees discussion on yellow-pages domains and might be led to believe that "everyone" was everyone in your domain. I know that rwall uses point-to-point RPC connections, so I didn't feel that this was what they meant, just that it seemed to be the implication. Reading the rwall man page turned up nothing about "broadcasts". It doesn't even specify the communications method used. One might infer that rwall did indeed use actual broadcast packets. Failing to find anything that might suggest that rwall would do anything nasty beyond the bounds of the current domain (or at least up to the IMP), I tried it. I knew that rwall takes awhile to do its stuff, so I left it running and went back to my office. I assumed that anyone who got my message would let me know.. Boy, was I right about that! After the first few mail messages arrived from Purdue and Utexas, I begin to understand what was really going on and killed the rwall. I mean, how often do you expect to run something on your machine and have people from Wisconsin start getting the results of it on their screens? All of this has raised some interesting points and problems. 1. Rwall will walk through your entire hosts file and blare at anyone and everyone if you use the (,,) wildcard group. Whether this is a bug or a feature, I don't know. 2. Since rwall is an RPC service, and RPC doesn't seem to give a damn who you are as long as you're root (which is trivial to be, on a work- station), I have to wonder what other RPC services are open holes. We've managed to do some interesting, unauthorized, things with the YP service here at Berkeley, I wonder what the implications of this are. 3. Having a group called "broadcast" in your netgroup file (which is how it comes from sun) is just begging for some novice admin (or operator with root) to use it in the mistaken belief that he/she is getting to all the users. I am really surprised (as are many others) that this has taken this long to happen. 4. Killing rwall is not going to solve the problem. Any fool can write rwall, and just about any fool can get root priviledge on a Sun workstation. It seems that the place to fix the problem is on the receiving ends. The only other alternative would be to tighten up all the IMP gateways to forward packets only from "trusted" hosts. I don't like that at all, from a standpoint of reduced convenience and productivity. Also, since many places are adding hosts at a phenominal rate (ourselves especially), it would be hard to keep such a database up to date. Many perfectly well- behaved people would suffer for the potential sins of a few. I certainly don't intend to do this again, but I'm very curious as to what will happen as a result. A lot of people got wall'd, and I would think that they would be annoyed that their machine would let someone from the opposite side of the continent do such a thing! Jordan Hubbard jkh at violet.berkeley.edu (ucbvax!jkh) Computer Facilities & Communications. U.C. Berkeley From doug at cs.dartmouth.edu Sat Jan 5 12:26:44 2019 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Fri, 04 Jan 2019 21:26:44 -0500 Subject: [TUHS] Isaacson v Unix Message-ID: <201901050226.x052QigU089781@tahoe.cs.Dartmouth.EDU> I was given a copy of Walter Isaacson's "The Innovators: How a Group of Hackers, Geniuses, and Geeks Created the Digital Revolution". It devotes ten pages to Stallman and Gnu, Torvalds and Linux, even Tannebaum and Minix, but never mentions Thompson and Ritchie. Unix is identified only as a product from Bell Labs from which the others learned something--he doesn't say what. I have heard also that Isaacson's "Idea Factory" (about Bell Labs) barely mentions Unix. Is Isaacson blind, biased, or merely brainwashed? In the case of Steve Jobs, Isaacson tells not just that the Alto system from Xerox inspired him, but also who its star creators were: Lampson, Thacker and Kay. But then he stomps on them: "Once again, the greatest innovation would come not from the people who created the breakthroughs, but from the people who applied them usefully." While he very describes innovation as a continuum from invention through engineering to marketing, he seems to be more impressed by the later stages. Or maybe he just likes to tell stories, and didn't pick up all the good ones about Ken. Isaacson describes spacewar, arguably the first stage of computer-game innovation, at great length. At the same time, all he has to say about early-stage operating systems is a single sentence that credits John McCarthy with leading a time-sharing effort at MIT. (In my recollection, McCarthy proseletized; Corbato led.) He tells how ARPANET, which he says was mainly developed by BB&N, connected time-shared computers, but breathes not a word about Berkeley's work, without which ARPANET would have been an open circuit. "Innovators" won general critical praise. A couple of reviews predicted it would become the standard of the field. However, an evidently knowledgeable review in IEEE Annals of the History of Computing faulted it for peddling familiar potted legends without really digging for deeper insight. Regarding Thompson and Ritchie, it looks more like overt suppression. Doug From ron at ronnatalie.com Sat Jan 5 12:35:53 2019 From: ron at ronnatalie.com (Ronald Natalie) Date: Fri, 4 Jan 2019 21:35:53 -0500 Subject: [TUHS] Isaacson v Unix In-Reply-To: <201901050226.x052QigU089781@tahoe.cs.Dartmouth.EDU> References: <201901050226.x052QigU089781@tahoe.cs.Dartmouth.EDU> Message-ID: <22BA2F17-310F-4396-A35A-23E2D1130018@ronnatalie.com> Yep, it’s pretty superficial when it comes to looking at where we are today. Further, the puppy love over RMS is entirely unjustified. He was in the right place with a rant about the industry but he’s oft unduly credited by a lot of the early GNU hangers on like Len Tower who made the project a success in spite of RMS. If anybody truly knew RMS they’d not tolerate any of this. He’s the most odiferous, objectionable, sexist, pedophile I have ever met (though I’ve not met the President yet). From jnc at mercury.lcs.mit.edu Sat Jan 5 14:20:11 2019 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Fri, 4 Jan 2019 23:20:11 -0500 (EST) Subject: [TUHS] Isaacson v Unix Message-ID: <20190105042011.49D7118C0B2@mercury.lcs.mit.edu> From: Doug McIlroy > I have heard also that Isaacson's "Idea Factory" (about Bell Labs) I was unable to find a book of this title by Isaacson? Did you mean the work of this title by Jon Gertner? (I have yet to pull down my copy to see what it says about Unix - it's in another room, and I'm lazy... :-) > (In my recollection, McCarthy proseletized; Corbato led.) I think that's an accurate 1-sentence summary. > breathes not a word about Berkeley's work, without which ARPANET would > have been an open circuit. Can you elaborate on this point a bit - I'm not sure what it is you're referring to? > A couple of reviews predicted it would become the standard of the > field. Among people who spell 'Internet' with a lower-case 'i', perhaps it will (sadly). Noel From noel.hunt at gmail.com Sat Jan 5 16:04:38 2019 From: noel.hunt at gmail.com (Noel Hunt) Date: Sat, 5 Jan 2019 15:04:38 +0900 Subject: [TUHS] AT&T / Teletype DMD 5620 Emulator In-Reply-To: <8736q8xhb0.fsf@loomcom.com> References: <8736q8xhb0.fsf@loomcom.com> Message-ID: I may be wrong but I thought there was a version of 'pi' for debugging code running on the Blit/Jerq. Does that run in the emulator? On Sat, Jan 5, 2019 at 6:18 AM Seth J. Morabito wrote: > > Hello folks, > > I realized I should mention this here on TUHS, since it is likely of > interest to at least some of you! > > I recently wrote a DMD 5620 emulator, currently available on Linux and > Macintosh, with Windows support coming soon. Here's a brief demo of the > Mac version: > > https://www.youtube.com/watch?v=tcSWqBmAMeY > > I wrote it because DMD 5620s are becoming incredibly rare, and showing > them off in person is quite difficult nowadays. > > This emulator is using ROM version 2.0 (8;7;5) dumped from my personal > 5620. If anyone out there has a DMD 5620 with an older ROM, I would be > incredibly grateful if you could dump the ROMs. I'd like to find > versions of 1.x (8;7;3 or earlier); so far I've had no luck. > > The main reason I'm interested in older ROMs, besides pure preservation > reasons, is that the 'mux' and 'muxterm' system on Research UNIX V8/V9 > is hard-coded for the 1.1 ROMs. It doesn't work with the emulator > without significant tweaking of the source. It DOES work perfectly well > with the DMD Core Utilities package for the AT&T 3B2, however. > > All the best! > > -Seth > -- > Seth Morabito > Poulsbo, WA, USA > web at loomcom.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wlc at jctaylor.com Sat Jan 5 19:08:28 2019 From: wlc at jctaylor.com (William Corcoran) Date: Sat, 5 Jan 2019 09:08:28 +0000 Subject: [TUHS] Isaacson v Unix In-Reply-To: <201901050226.x052QigU089781@tahoe.cs.Dartmouth.EDU> References: <201901050226.x052QigU089781@tahoe.cs.Dartmouth.EDU> Message-ID: <16F2E714-06E8-4BE5-A963-FCE0E11F1507@jctaylor.com> Okay, I will say it: Fake News. The irony is that UNIX through programs like troff/nroff maintained extensive and elaborate mechanisms to support citations. Indeed, there was a time when research required meticulous care of citations. In fact, I would argue that the importance of the great breakthrough UNIX papers by Thompson et al. in combination with the many excellent cites within are as significant of a work product as the UNIX proper. I used to think that the greatest attribute of a digital document was its inability to suffer decay, degrade or otherwise fade away like its analog analog. Yet, digital document decay occurs indirectly as we can see here with Isaacson’s work product: Revisionism by omission. It’s as simple as it is dangerous. Since newer is ALWAYS better, the classic texts will eventually disappear replaced by garbage paradoxically “filled” with omissions. Bill Corcoran “One small step for main; one giant leap for mainkind.” > On Jan 4, 2019, at 9:27 PM, Doug McIlroy wrote: > > I was given a copy of Walter Isaacson's "The Innovators: How a Group of > Hackers, Geniuses, and Geeks Created the Digital Revolution". It devotes > ten pages to Stallman and Gnu, Torvalds and Linux, even Tannebaum and > Minix, but never mentions Thompson and Ritchie. Unix is identified only > as a product from Bell Labs from which the others learned something--he > doesn't say what. I have heard also that Isaacson's "Idea Factory" > (about Bell Labs) barely mentions Unix. Is Isaacson blind, biased, > or merely brainwashed? > > In the case of Steve Jobs, Isaacson tells not just that the Alto system > from Xerox inspired him, but also who its star creators were: Lampson, > Thacker and Kay. But then he stomps on them: "Once again, the greatest > innovation would come not from the people who created the breakthroughs, > but from the people who applied them usefully." While he very describes > innovation as a continuum from invention through engineering to marketing, > he seems to be more impressed by the later stages. > > Or maybe he just likes to tell stories, and didn't pick up all the > good ones about Ken. Isaacson describes spacewar, arguably the first > stage of computer-game innovation, at great length. At the same time, > all he has to say about early-stage operating systems is a single > sentence that credits John McCarthy with leading a time-sharing effort > at MIT. (In my recollection, McCarthy proseletized; Corbato led.) He > tells how ARPANET, which he says was mainly developed by BB&N, connected > time-shared computers, but breathes not a word about Berkeley's work, > without which ARPANET would have been an open circuit. > > "Innovators" won general critical praise. A couple of reviews predicted > it would become the standard of the field. However, an evidently > knowledgeable review in IEEE Annals of the History of Computing faulted > it for peddling familiar potted legends without really digging for > deeper insight. Regarding Thompson and Ritchie, it looks more like > overt suppression. > > Doug From nw at retrocomputingtasmania.com Sat Jan 5 20:05:54 2019 From: nw at retrocomputingtasmania.com (Nigel Williams) Date: Sat, 5 Jan 2019 21:05:54 +1100 Subject: [TUHS] face mail icon for ACSnet Message-ID: Long ago when we were running ACSnet (https://en.wikipedia.org/wiki/MHSnet) we lacked graphical workstations so we never saw the Bell Labs face mail (https://en.wikipedia.org/wiki/Vismon) mechanism in action. I think colleagues who later had Sun workstations might have briefly had X-face in operation. I see on Luca Cardelli's homepage that there was an icon for ACSnet email, of course it is Kangaroo... http://lucacardelli.name/indexArtifacts.html scroll down Original 48x48 bitmaps for "face mail" at Bell Labs. From erc at pobox.com Sat Jan 5 22:09:47 2019 From: erc at pobox.com (Ed Carp) Date: Sat, 5 Jan 2019 05:09:47 -0700 Subject: [TUHS] Isaacson v Unix In-Reply-To: <16F2E714-06E8-4BE5-A963-FCE0E11F1507@jctaylor.com> References: <201901050226.x052QigU089781@tahoe.cs.Dartmouth.EDU> <16F2E714-06E8-4BE5-A963-FCE0E11F1507@jctaylor.com> Message-ID: Nonsense from someone who evidently had some sort of axe to grind. Kerninghan, Ritchie, Pine, Thonpson, Joy, and the rest being excluded is like crediting everything that Sun has done to Scott McNealy. Sounds like the marketers being credited with innovation. On 1/5/19, William Corcoran wrote: > Okay, I will say it: Fake News. > > The irony is that UNIX through programs like troff/nroff maintained > extensive and elaborate mechanisms to support citations. Indeed, there was > a time when research required meticulous care of citations. > > In fact, I would argue that the importance of the great breakthrough UNIX > papers by Thompson et al. in combination with the many excellent cites > within are as significant of a work product as the UNIX proper. > > I used to think that the greatest attribute of a digital document was its > inability to suffer decay, degrade or otherwise fade away like its analog > analog. > > Yet, digital document decay occurs indirectly as we can see here with > Isaacson’s work product: Revisionism by omission. > > It’s as simple as it is dangerous. Since newer is ALWAYS better, the > classic texts will eventually disappear replaced by garbage paradoxically > “filled” with omissions. > > Bill Corcoran > “One small step for main; one giant leap for mainkind.” > > > >> On Jan 4, 2019, at 9:27 PM, Doug McIlroy wrote: >> >> I was given a copy of Walter Isaacson's "The Innovators: How a Group of >> Hackers, Geniuses, and Geeks Created the Digital Revolution". It devotes >> ten pages to Stallman and Gnu, Torvalds and Linux, even Tannebaum and >> Minix, but never mentions Thompson and Ritchie. Unix is identified only >> as a product from Bell Labs from which the others learned something--he >> doesn't say what. I have heard also that Isaacson's "Idea Factory" >> (about Bell Labs) barely mentions Unix. Is Isaacson blind, biased, >> or merely brainwashed? >> >> In the case of Steve Jobs, Isaacson tells not just that the Alto system >> from Xerox inspired him, but also who its star creators were: Lampson, >> Thacker and Kay. But then he stomps on them: "Once again, the greatest >> innovation would come not from the people who created the breakthroughs, >> but from the people who applied them usefully." While he very describes >> innovation as a continuum from invention through engineering to >> marketing, >> he seems to be more impressed by the later stages. >> >> Or maybe he just likes to tell stories, and didn't pick up all the >> good ones about Ken. Isaacson describes spacewar, arguably the first >> stage of computer-game innovation, at great length. At the same time, >> all he has to say about early-stage operating systems is a single >> sentence that credits John McCarthy with leading a time-sharing effort >> at MIT. (In my recollection, McCarthy proseletized; Corbato led.) He >> tells how ARPANET, which he says was mainly developed by BB&N, connected >> time-shared computers, but breathes not a word about Berkeley's work, >> without which ARPANET would have been an open circuit. >> >> "Innovators" won general critical praise. A couple of reviews predicted >> it would become the standard of the field. However, an evidently >> knowledgeable review in IEEE Annals of the History of Computing faulted >> it for peddling familiar potted legends without really digging for >> deeper insight. Regarding Thompson and Ritchie, it looks more like >> overt suppression. >> >> Doug > From paul.winalski at gmail.com Sun Jan 6 00:15:39 2019 From: paul.winalski at gmail.com (Paul Winalski) Date: Sat, 5 Jan 2019 09:15:39 -0500 Subject: [TUHS] Isaacson v Unix In-Reply-To: <201901050226.x052QigU089781@tahoe.cs.Dartmouth.EDU> References: <201901050226.x052QigU089781@tahoe.cs.Dartmouth.EDU> Message-ID: On 1/4/19, Doug McIlroy wrote: > > In the case of Steve Jobs, Isaacson tells not just that the Alto system > from Xerox inspired him, but also who its star creators were: Lampson, > Thacker and Kay. But then he stomps on them: "Once again, the greatest > innovation would come not from the people who created the breakthroughs, > but from the people who applied them usefully." While he very describes > innovation as a continuum from invention through engineering to marketing, > he seems to be more impressed by the later stages. I would argue that Isaacson does have a point here. After Lampson left Xerox PARC he set up a similar outfit at Digital'--the Western Research Lab (WRL). They did a lot of interesting work in the area of software development tools. I was working in the software tools engineering group at the time, and we would have loved to take WRL's work and to incorporate it in our products. But we couldn't. Why? Because they wrote everything in Modula 3, and we were using BLISS. It was too expensive and time-consuming to do the translation. If they had worked in BLISS, we could have just taken their code and run with it. From my perspective it looked as though they were deliberately setting up barriers to prevent us from sullying their research by actually turning it into useful products. In one memo to DEC's engineering staff, Gordon Bell proposed a "Xerox PARC" award to the R&D project that advanced the state-of-the-art the most while simultaneously advancing DEC's bottom line the least. Yes, PARC invented the modern windows-based GUI, but, as with so many PARC innovations, Xerox did nothing with it. Based on how the PARC alumni at WRL behaved at DEC,I would argue that this was the fault of PARC as much as of Xerox management. All that being said, I don't think this argument applies in any way to Bell Labs and Unix. Unix was "applied usefully" long before Stallman and Torvalds came along. Not crediting its inventors is inexcusable. -Paul W. From jnc at mercury.lcs.mit.edu Sun Jan 6 00:30:31 2019 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Sat, 5 Jan 2019 09:30:31 -0500 (EST) Subject: [TUHS] Isaacson v Unix Message-ID: <20190105143031.85F3018C0B6@mercury.lcs.mit.edu> >> From: Doug McIlroy >> I have heard also that Isaacson's "Idea Factory" (about Bell Labs) > Did you mean the work of this title by Jon Gertner? (I have yet to pull > down my copy to see what it says about Unix I looked, and it too says next to nothing about Unix (which it describes as a "programming language" - pg. 346). Oh well. This is really a pretty serious omission, given that the vast majority of mobile devices now run Android, which is a Unix derivative (Linux). So just about everyone has a Unix-derived thing in their pocket. Noel From erc at pobox.com Sun Jan 6 01:01:11 2019 From: erc at pobox.com (Ed Carp) Date: Sat, 5 Jan 2019 08:01:11 -0700 Subject: [TUHS] Isaacson v Unix In-Reply-To: References: <201901050226.x052QigU089781@tahoe.cs.Dartmouth.EDU> Message-ID: > All that being said, I don't think this argument applies in any way to > Bell Labs and Unix. Unix was "applied usefully" long before Stallman > and Torvalds came along. Not crediting its inventors is inexcusable. Completely agree! On 1/5/19, Paul Winalski wrote: > On 1/4/19, Doug McIlroy wrote: >> >> In the case of Steve Jobs, Isaacson tells not just that the Alto system >> from Xerox inspired him, but also who its star creators were: Lampson, >> Thacker and Kay. But then he stomps on them: "Once again, the greatest >> innovation would come not from the people who created the breakthroughs, >> but from the people who applied them usefully." While he very describes >> innovation as a continuum from invention through engineering to >> marketing, >> he seems to be more impressed by the later stages. > > I would argue that Isaacson does have a point here. After Lampson > left Xerox PARC he set up a similar outfit at Digital'--the Western > Research Lab (WRL). They did a lot of interesting work in the area of > software development tools. I was working in the software tools > engineering group at the time, and we would have loved to take WRL's > work and to incorporate it in our products. But we couldn't. Why? > Because they wrote everything in Modula 3, and we were using BLISS. > It was too expensive and time-consuming to do the translation. If > they had worked in BLISS, we could have just taken their code and run > with it. From my perspective it looked as though they were > deliberately setting up barriers to prevent us from sullying their > research by actually turning it into useful products. > > In one memo to DEC's engineering staff, Gordon Bell proposed a "Xerox > PARC" award to the R&D project that advanced the state-of-the-art the > most while simultaneously advancing DEC's bottom line the least. > > Yes, PARC invented the modern windows-based GUI, but, as with so many > PARC innovations, Xerox did nothing with it. Based on how the PARC > alumni at WRL behaved at DEC,I would argue that this was the fault of > PARC as much as of Xerox management. > > All that being said, I don't think this argument applies in any way to > Bell Labs and Unix. Unix was "applied usefully" long before Stallman > and Torvalds came along. Not crediting its inventors is inexcusable. > > -Paul W. > From iain at csp-partnership.co.uk Sat Jan 5 23:09:39 2019 From: iain at csp-partnership.co.uk (Dr Iain Maoileoin) Date: Sat, 5 Jan 2019 13:09:39 +0000 Subject: [TUHS] off topic - capatob - saratov2 computer Russsian pdp8? HELP Message-ID: <193D6345-8E32-49A6-8F16-A30672C222A8@csp-partnership.co.uk> Off topic, but looking for help and wisdom. If you visit https://www.scotnet.co.uk/iain/ saratov you will see some photos of work that I have started on the front panel of a Capatob2. I plan to get the switches and lights running on a blinkenbone board with a PDP8 emulation behind it. (I already have an PDP11/70 front-panel running on the same infrastructure) I have been struggling for over a year to get much info about this saratov computer (circuit diagrams etc). So I have started the reverse engineering on the panel. Does anybody know anything about this computer? online or offline it would be much appreciated. Iain -------------- next part -------------- An HTML attachment was scrubbed... URL: From erc at pobox.com Sun Jan 6 01:04:30 2019 From: erc at pobox.com (Ed Carp) Date: Sat, 5 Jan 2019 08:04:30 -0700 Subject: [TUHS] Isaacson v Unix In-Reply-To: <20190105143031.85F3018C0B6@mercury.lcs.mit.edu> References: <20190105143031.85F3018C0B6@mercury.lcs.mit.edu> Message-ID: > I looked, and it too says next to nothing about Unix (which it describes as a > "programming language" - pg. 346). Oh well. Pretty funny, or sad, depending on your viewpoint! > This is really a pretty serious omission, given that the vast majority of > mobile devices now run Android, which is a Unix derivative (Linux). So just > about everyone has a Unix-derived thing in their pocket. To hear some people talk, everything started with Linux, and Torvalds is a god. Nonsense. Even iOS and MacOS are derived from BSD, I believe. I know that MacOS is (or has been until relatively recently, at any rate) derived from BSD. On 1/5/19, Noel Chiappa wrote: > >> From: Doug McIlroy > > >> I have heard also that Isaacson's "Idea Factory" (about Bell Labs) > > > Did you mean the work of this title by Jon Gertner? (I have yet to > pull > > down my copy to see what it says about Unix > > I looked, and it too says next to nothing about Unix (which it describes as > a > "programming language" - pg. 346). Oh well. > > This is really a pretty serious omission, given that the vast majority of > mobile devices now run Android, which is a Unix derivative (Linux). So just > about everyone has a Unix-derived thing in their pocket. > > Noel > From imp at bsdimp.com Sun Jan 6 01:26:29 2019 From: imp at bsdimp.com (Warner Losh) Date: Sat, 5 Jan 2019 08:26:29 -0700 Subject: [TUHS] Isaacson v Unix In-Reply-To: References: <20190105143031.85F3018C0B6@mercury.lcs.mit.edu> Message-ID: On Sat, Jan 5, 2019 at 8:04 AM Ed Carp wrote: > > I looked, and it too says next to nothing about Unix (which it describes > as a > > "programming language" - pg. 346). Oh well. > > Pretty funny, or sad, depending on your viewpoint! > > > This is really a pretty serious omission, given that the vast majority of > > mobile devices now run Android, which is a Unix derivative (Linux). So > just > > about everyone has a Unix-derived thing in their pocket. > > To hear some people talk, everything started with Linux, and Torvalds > is a god. Nonsense. > > Even iOS and MacOS are derived from BSD, I believe. I know that MacOS > is (or has been until relatively recently, at any rate) derived from > BSD. > MacOS X is derived from BSD + Mach VM, with lots of infusions from BSD and other projects. iOS is derived from MacOS. Warner > On 1/5/19, Noel Chiappa wrote: > > >> From: Doug McIlroy > > > > >> I have heard also that Isaacson's "Idea Factory" (about Bell Labs) > > > > > Did you mean the work of this title by Jon Gertner? (I have yet to > > pull > > > down my copy to see what it says about Unix > > > > I looked, and it too says next to nothing about Unix (which it describes > as > > a > > "programming language" - pg. 346). Oh well. > > > > This is really a pretty serious omission, given that the vast majority of > > mobile devices now run Android, which is a Unix derivative (Linux). So > just > > about everyone has a Unix-derived thing in their pocket. > > > > Noel > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Sun Jan 6 01:31:33 2019 From: lm at mcvoy.com (Larry McVoy) Date: Sat, 5 Jan 2019 07:31:33 -0800 Subject: [TUHS] Isaacson v Unix In-Reply-To: <22BA2F17-310F-4396-A35A-23E2D1130018@ronnatalie.com> References: <201901050226.x052QigU089781@tahoe.cs.Dartmouth.EDU> <22BA2F17-310F-4396-A35A-23E2D1130018@ronnatalie.com> Message-ID: <20190105153133.GA24497@mcvoy.com> +1. RMS always talked big but the real work was done by other people. GCC was Tiemann at Sun and then at Cygnus, groff was James Clark, etc. I think RMS hacked on emacs but not much else. On Fri, Jan 04, 2019 at 09:35:53PM -0500, Ronald Natalie wrote: > Yep, it???s pretty superficial when it comes to looking at where we are today. > Further, the puppy love over RMS is entirely unjustified. He was in the right place with a rant about the industry but he???s oft unduly credited by a lot of the early GNU hangers on like Len Tower who made the project a success in spite > of RMS. > > If anybody truly knew RMS they???d not tolerate any of this. He???s the most odiferous, objectionable, sexist, pedophile I have ever met (though I???ve not met the President yet). -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From ben at cogs.com Sun Jan 6 01:37:36 2019 From: ben at cogs.com (Ben Greenfield) Date: Sat, 5 Jan 2019 10:37:36 -0500 Subject: [TUHS] Isaacson v Unix In-Reply-To: References: <20190105143031.85F3018C0B6@mercury.lcs.mit.edu> Message-ID: <0A800C0E-3D9C-4C76-9A91-BFC3226C42CC@cogs.com> > On Jan 5, 2019, at 10:26 AM, Warner Losh wrote: > > > > On Sat, Jan 5, 2019 at 8:04 AM Ed Carp > wrote: > > I looked, and it too says next to nothing about Unix (which it describes as a > > "programming language" - pg. 346). Oh well. > > Pretty funny, or sad, depending on your viewpoint! > > > This is really a pretty serious omission, given that the vast majority of > > mobile devices now run Android, which is a Unix derivative (Linux). So just > > about everyone has a Unix-derived thing in their pocket. > > To hear some people talk, everything started with Linux, and Torvalds > is a god. Nonsense. > > Even iOS and MacOS are derived from BSD, I believe. I know that MacOS > is (or has been until relatively recently, at any rate) derived from > BSD. > > MacOS X is derived from BSD + Mach VM, with lots of infusions from BSD and other projects. iOS is derived from MacOS. I think that it is more clearly expressed as MacOS X has a BSD interface to the Mach VM. Mach has always had this sort of relationship with BSD and it still exists. iOS… Ben > > Warner > > On 1/5/19, Noel Chiappa > wrote: > > >> From: Doug McIlroy > > > > >> I have heard also that Isaacson's "Idea Factory" (about Bell Labs) > > > > > Did you mean the work of this title by Jon Gertner? (I have yet to > > pull > > > down my copy to see what it says about Unix > > > > I looked, and it too says next to nothing about Unix (which it describes as > > a > > "programming language" - pg. 346). Oh well. > > > > This is really a pretty serious omission, given that the vast majority of > > mobile devices now run Android, which is a Unix derivative (Linux). So just > > about everyone has a Unix-derived thing in their pocket. > > > > Noel > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From a.phillip.garcia at gmail.com Sun Jan 6 03:01:10 2019 From: a.phillip.garcia at gmail.com (A. P. Garcia) Date: Sat, 5 Jan 2019 12:01:10 -0500 Subject: [TUHS] Isaacson v Unix In-Reply-To: <20190105153133.GA24497@mcvoy.com> References: <201901050226.x052QigU089781@tahoe.cs.Dartmouth.EDU> <22BA2F17-310F-4396-A35A-23E2D1130018@ronnatalie.com> <20190105153133.GA24497@mcvoy.com> Message-ID: On Sat, Jan 5, 2019, 10:39 AM Larry McVoy +1. RMS always talked big but the real work was done by other people. > GCC was Tiemann at Sun and then at Cygnus, groff was James Clark, > etc. I think RMS hacked on emacs but not much else. > I'm going to refrain from either praising or disparaging the man. I think the book Hackers by Steven Levy does a good job of describing him and how the idea for the GNU project came about. I'm going to paraphrase what I remember from it, but it's been a long time since I read it. If I recall correctly, stallman graduated summa cum laude with a physics degree from Harvard. He spent many of his undergrad days and nights working at the MIT AI lab. Among his character defects, I've never heard anyone accuse him of being a dumb guy. Awkward, yes, strange, perhaps, but not dumb. At the AI lab he found a place where he fit in. The systems ran ITS, an MIT homegrown operating system. It was an open environment where people debated technical issues over Chinese take-out, an intellectual society in which Stallman felt at home as a rightful citizen. The camaraderie he knew there dissolved as its members struck out to become entrepreneurs. My memory is fuzzy here, but I believe his main nemesis was Symbolics, marketers of a proprietary version of MIT's CADR Lisp machine and operating system. As they released system updates, Stallman would would reverse engineer the changes and add the new features to the MIT system. Around the same time, ITS was being replaced on the computers by proprietary operating systems. Stallman began running into roadblocks, bugs in the OS where the code was not available to fix. To access the code he would have to sign an NDA, which he refused to do. In short, his little utopia collapsed. The lab as he knew it was gone. He wondered to himself whether he could rebuild it somehow, and this was the inception of the GNU project. He chose to re-implement Unix, not because he considered it an ideal operating system but because he considered it adequate. (I am among those on this list who would beg to differ.) He has said many times that he does not agree with the Unix philosophy, but I don't know specifically what he means by this. Building an operating system in and of itself was not so much his goal as building the friendships and community surrounding it. > On Fri, Jan 04, 2019 at 09:35:53PM -0500, Ronald Natalie wrote: > > Yep, it???s pretty superficial when it comes to looking at where we are > today. > > Further, the puppy love over RMS is entirely unjustified. He was in > the right place with a rant about the industry but he???s oft unduly > credited by a lot of the early GNU hangers on like Len Tower who made the > project a success in spite > > of RMS. > > > > If anybody truly knew RMS they???d not tolerate any of this. He???s > the most odiferous, objectionable, sexist, pedophile I have ever met > (though I???ve not met the President yet). > > -- > --- > Larry McVoy lm at mcvoy.com > http://www.mcvoy.com/lm > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mutiny.mutiny at india.com Sun Jan 6 03:07:32 2019 From: mutiny.mutiny at india.com (Donald ODona) Date: Sat, 5 Jan 2019 17:07:32 +0000 (UTC) Subject: [TUHS] Isaacson v Unix In-Reply-To: <20190105153133.GA24497@mcvoy.com> References: <201901050226.x052QigU089781@tahoe.cs.Dartmouth.EDU> <22BA2F17-310F-4396-A35A-23E2D1130018@ronnatalie.com>, <20190105153133.GA24497@mcvoy.com> Message-ID: <1948728932.119177.1546708052740.JavaMail.tomcat@india-live-be04> At 5 Jan 2019 15:40:13 +0000 (+00:00) from Larry McVoy : > +1. RMS always talked big but the real work was done by other people. > GCC was Tiemann at Sun and then at Cygnus, groff was James Clark, > etc. I think RMS hacked on emacs but not much else. RMS hired a programmer for emacs already in the 80ths. He also became the maintainer then. It was the dude lucid hired for xemacs. After he skilled jwz at. al. they fired him. Tragical case. From paul.winalski at gmail.com Sun Jan 6 06:27:42 2019 From: paul.winalski at gmail.com (Paul Winalski) Date: Sat, 5 Jan 2019 15:27:42 -0500 Subject: [TUHS] Isaacson v Unix In-Reply-To: References: <201901050226.x052QigU089781@tahoe.cs.Dartmouth.EDU> <22BA2F17-310F-4396-A35A-23E2D1130018@ronnatalie.com> <20190105153133.GA24497@mcvoy.com> Message-ID: On 1/5/19, A. P. Garcia wrote: [concerning Richard Stallman] > > Building an operating system in and of itself was not so much his goal as > building the friendships and community surrounding it. > The GNU Hurd kernel certainly seems to have gotten nowhere, and with the success of Linux IMO the free software community doesn't need it anymore. But FSF certainly has made a big impact and contribution with the gcc toolchain and the free versions of the Unix shell and utilities. -Paul W. From joe at via.net Sun Jan 6 07:20:10 2019 From: joe at via.net (joe mcguckin) Date: Sat, 5 Jan 2019 13:20:10 -0800 Subject: [TUHS] Isaacson v Unix In-Reply-To: <1948728932.119177.1546708052740.JavaMail.tomcat@india-live-be04> References: <201901050226.x052QigU089781@tahoe.cs.Dartmouth.EDU> <22BA2F17-310F-4396-A35A-23E2D1130018@ronnatalie.com> <20190105153133.GA24497@mcvoy.com> <1948728932.119177.1546708052740.JavaMail.tomcat@india-live-be04> Message-ID: <09A1D9A6-20B4-4924-8E42-B8A75226552B@via.net> Stig? Joe McGuckin ViaNet Communications joe at via.net 650-207-0372 cell 650-213-1302 office 650-969-2124 fax > On Jan 5, 2019, at 9:07 AM, Donald ODona wrote: > > > > At 5 Jan 2019 15:40:13 +0000 (+00:00) from Larry McVoy : >> +1. RMS always talked big but the real work was done by other people. >> GCC was Tiemann at Sun and then at Cygnus, groff was James Clark, >> etc. I think RMS hacked on emacs but not much else. > RMS hired a programmer for emacs already in the 80ths. He also became the maintainer then. It was the dude lucid hired for xemacs. After he skilled jwz at. al. they fired him. Tragical case. From doug at cs.dartmouth.edu Sun Jan 6 07:34:07 2019 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Sat, 05 Jan 2019 16:34:07 -0500 Subject: [TUHS] Isaacson v Unix Message-ID: <201901052134.x05LY7se010991@coolidge.cs.Dartmouth.EDU> >>I have heard also that Isaacson's "Idea Factory" (about Bell Labs) > Did you mean the work of this title by Jon Gertner? Indeed. If should fact-check myself if I'm going to challenge some one else's choice of facts. Thanks for the catch, Doug From a.phillip.garcia at gmail.com Sun Jan 6 07:38:40 2019 From: a.phillip.garcia at gmail.com (A. P. Garcia) Date: Sat, 5 Jan 2019 16:38:40 -0500 Subject: [TUHS] Isaacson v Unix In-Reply-To: References: <201901050226.x052QigU089781@tahoe.cs.Dartmouth.EDU> <22BA2F17-310F-4396-A35A-23E2D1130018@ronnatalie.com> <20190105153133.GA24497@mcvoy.com> Message-ID: On Sat, Jan 5, 2019, 3:27 PM Paul Winalski On 1/5/19, A. P. Garcia wrote: > [concerning Richard Stallman] > > > > Building an operating system in and of itself was not so much his goal as > > building the friendships and community surrounding it. > > > The GNU Hurd kernel certainly seems to have gotten nowhere, and with > the success of Linux IMO the free software community doesn't need it > anymore. But FSF certainly has made a big impact and contribution > with the gcc toolchain and the free versions of the Unix shell and > utilities. > But RMS sort of invented that community, just like Al Gore sort of invented the internet (as we know it today). He was certainly an important catalyst, and his views remain influential to many people. He was wrong about Unix, though. It is not merely an adequate OS. It is ideal. ;-) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robpike at gmail.com Sun Jan 6 07:51:55 2019 From: robpike at gmail.com (Rob Pike) Date: Sun, 6 Jan 2019 08:51:55 +1100 Subject: [TUHS] Isaacson v Unix In-Reply-To: References: <201901050226.x052QigU089781@tahoe.cs.Dartmouth.EDU> <22BA2F17-310F-4396-A35A-23E2D1130018@ronnatalie.com> <20190105153133.GA24497@mcvoy.com> Message-ID: I heard when "The Idea Factory" came out that Gertner left out the computing stuff because he was planning a second book focusing on that topic. Of course that might not be true. -rob From lm at mcvoy.com Sun Jan 6 07:52:17 2019 From: lm at mcvoy.com (Larry McVoy) Date: Sat, 5 Jan 2019 13:52:17 -0800 Subject: [TUHS] Isaacson v Unix In-Reply-To: References: <201901050226.x052QigU089781@tahoe.cs.Dartmouth.EDU> <22BA2F17-310F-4396-A35A-23E2D1130018@ronnatalie.com> <20190105153133.GA24497@mcvoy.com> Message-ID: <20190105215217.GI24497@mcvoy.com> On Sat, Jan 05, 2019 at 04:38:40PM -0500, A. P. Garcia wrote: > On Sat, Jan 5, 2019, 3:27 PM Paul Winalski > > On 1/5/19, A. P. Garcia wrote: > > [concerning Richard Stallman] > > > > > > Building an operating system in and of itself was not so much his goal as > > > building the friendships and community surrounding it. > > > > > The GNU Hurd kernel certainly seems to have gotten nowhere, and with > > the success of Linux IMO the free software community doesn't need it > > anymore. But FSF certainly has made a big impact and contribution > > with the gcc toolchain and the free versions of the Unix shell and > > utilities. > > > > But RMS sort of invented that community, just like Al Gore sort of invented > the internet (as we know it today). He was certainly an important catalyst, > and his views remain influential to many people. I'll remind you all of a story I'm sure I shared here in the past. I was friends with the 3 Cygnus founders and I was having a dinner with them at Gumby's house. (This is an aside but it is important: Gumby was, at that time, married to a very nice German woman named Silka; she still had a pretty strong accent, English was not her first language). Cygnus was pretty much a 100% GPL / LGPL shop. So the discussions were all "RMS this", "RMS that" and went on for a long time (hours). Silka was clearing the table and she pipes up with "Are you saying 'RMS this'?" We say yes, and she responds with "Huh, all this time I heard 'Our mess this', 'Our mess that'". We all looked at each other in silence, sort of replaying everying through that view. And started laughing (and freaking out a little) that every sentence made sense as "Our mess ". I'm clearly not a fan of RMS, yeah, he did some good but in the process he took credit for an enormous body of work in which he didn't write a line of code. As a programmer, that's lieing and I can't stand liars. And that's all I have to say on the RMS topic, it's probably too much as it is. From robpike at gmail.com Sun Jan 6 07:53:00 2019 From: robpike at gmail.com (Rob Pike) Date: Sun, 6 Jan 2019 08:53:00 +1100 Subject: [TUHS] Isaacson v Unix In-Reply-To: References: <201901050226.x052QigU089781@tahoe.cs.Dartmouth.EDU> <22BA2F17-310F-4396-A35A-23E2D1130018@ronnatalie.com> <20190105153133.GA24497@mcvoy.com> Message-ID: By the way, I felt that "The Idea Factory" did a great job of communicating the feeling of working at Bell Labs Research and have recommended it widely. Doug, you might enjoy it. -rob On Sun, Jan 6, 2019 at 8:51 AM Rob Pike wrote: > > I heard when "The Idea Factory" came out that Gertner left out the > computing stuff because he was planning a second book focusing on that > topic. Of course that might not be true. > > -rob From cmhanson at eschatologist.net Sun Jan 6 11:43:43 2019 From: cmhanson at eschatologist.net (Chris Hanson) Date: Sat, 5 Jan 2019 17:43:43 -0800 Subject: [TUHS] Isaacson v Unix In-Reply-To: <20190105153133.GA24497@mcvoy.com> References: <201901050226.x052QigU089781@tahoe.cs.Dartmouth.EDU> <22BA2F17-310F-4396-A35A-23E2D1130018@ronnatalie.com> <20190105153133.GA24497@mcvoy.com> Message-ID: <857E28A8-A1A7-48DD-A60D-05FADD93C6C5@eschatologist.net> On Jan 5, 2019, at 7:31 AM, Larry McVoy wrote: > > +1. RMS always talked big but the real work was done by other people. > GCC was Tiemann at Sun and then at Cygnus, groff was James Clark, > etc. I think RMS hacked on emacs but not much else. Which I thought was originally derived from Unipress emacs (Gosmacs), and was why old source code used to be hard to find. — Chris From cmhanson at eschatologist.net Sun Jan 6 11:50:53 2019 From: cmhanson at eschatologist.net (Chris Hanson) Date: Sat, 5 Jan 2019 17:50:53 -0800 Subject: [TUHS] Isaacson v Unix In-Reply-To: References: <201901050226.x052QigU089781@tahoe.cs.Dartmouth.EDU> <22BA2F17-310F-4396-A35A-23E2D1130018@ronnatalie.com> <20190105153133.GA24497@mcvoy.com> Message-ID: On Jan 5, 2019, at 9:01 AM, A. P. Garcia wrote: > > On Sat, Jan 5, 2019, 10:39 AM Larry McVoy > +1. RMS always talked big but the real work was done by other people. >> GCC was Tiemann at Sun and then at Cygnus, groff was James Clark, >> etc. I think RMS hacked on emacs but not much else. > > > I'm going to refrain from either praising or disparaging the man. I think the book Hackers by Steven Levy does a good job of describing him and how the idea for the GNU project came about. Dan Weinreb, who was in charge of Symbolics at the time, strongly disputed the RMS (and “Hackers”) story of GNU’s inspiration from what Symbolics “did to” the AI Lab. By Weinreb’s account, Symbolics hired relatively few people away from the Lab, and RMS wasn’t simply rewriting Symbolics’ enhancements (which were shared with the Lab, and Symbolics’ customers of course) for the MIT and LMI environments, he was actually caught copying their code directly. — Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From a.phillip.garcia at gmail.com Sun Jan 6 12:18:40 2019 From: a.phillip.garcia at gmail.com (A. P. Garcia) Date: Sat, 5 Jan 2019 21:18:40 -0500 Subject: [TUHS] Isaacson v Unix In-Reply-To: References: <201901050226.x052QigU089781@tahoe.cs.Dartmouth.EDU> <22BA2F17-310F-4396-A35A-23E2D1130018@ronnatalie.com> <20190105153133.GA24497@mcvoy.com> Message-ID: On Sat, Jan 5, 2019, 8:50 PM Chris Hanson On Jan 5, 2019, at 9:01 AM, A. P. Garcia > wrote: > > On Sat, Jan 5, 2019, 10:39 AM Larry McVoy >> +1. RMS always talked big but the real work was done by other people. >> GCC was Tiemann at Sun and then at Cygnus, groff was James Clark, >> etc. I think RMS hacked on emacs but not much else. >> > > I'm going to refrain from either praising or disparaging the man. I think > the book Hackers by Steven Levy does a good job of describing him and how > the idea for the GNU project came about. > > > Dan Weinreb, who was in charge of Symbolics at the time, strongly disputed > the RMS (and “Hackers”) story of GNU’s inspiration from what Symbolics “did > to” the AI Lab. > > By Weinreb’s account, Symbolics hired relatively few people away from the > Lab, and RMS wasn’t simply rewriting Symbolics’ enhancements (which were > shared with the Lab, and Symbolics’ customers of course) for the MIT and > LMI environments, he was actually caught copying their code directly. > A google search turned up a speech by rms that I hadnˋt previously seen, as well as Weinrebˋs rebuttal: https://www.gnu.org/gnu/rms-lisp.en.html http://ergoemacs.org/misc/Daniel_Weinreb_rebuttal_to_rms.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From grog at lemis.com Sun Jan 6 12:40:54 2019 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Sun, 6 Jan 2019 13:40:54 +1100 Subject: [TUHS] Emacs (was: Isaacson v Unix) In-Reply-To: <857E28A8-A1A7-48DD-A60D-05FADD93C6C5@eschatologist.net> References: <201901050226.x052QigU089781@tahoe.cs.Dartmouth.EDU> <22BA2F17-310F-4396-A35A-23E2D1130018@ronnatalie.com> <20190105153133.GA24497@mcvoy.com> <857E28A8-A1A7-48DD-A60D-05FADD93C6C5@eschatologist.net> Message-ID: <20190106024054.GA27103@eureka.lemis.com> On Saturday, 5 January 2019 at 17:43:43 -0800, Chris Hanson wrote: > On Jan 5, 2019, at 7:31 AM, Larry McVoy wrote: >> >> +1. RMS always talked big but the real work was done by other people. >> GCC was Tiemann at Sun and then at Cygnus, groff was James Clark, >> etc. I think RMS hacked on emacs but not much else. > > Which I thought was originally derived from Unipress emacs > (Gosmacs), and was why old source code used to be hard to find. I don't think there's any serious doubt that rms wrote the original Emacs, in TECO. If I understand it correctly, though, he took significant improvements, including screen redisplay, from Gosling Emacs. Greg -- Sent from my desktop computer. Finger grog at lemis.com for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft mail program reports problems, please read http://lemis.com/broken-MUA -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 163 bytes Desc: not available URL: From paul at mcjones.org Sun Jan 6 13:45:56 2019 From: paul at mcjones.org (Paul McJones) Date: Sat, 5 Jan 2019 19:45:56 -0800 Subject: [TUHS] Isaacson v Unix In-Reply-To: References: Message-ID: > On Jan 5, 2019,Paul Winalski wrote: > > ... After Lampson > left Xerox PARC he set up a similar outfit at Digital'--the Western > Research Lab (WRL). Actually, WRL was started by Forest Baskett, formerly of Stanford University. Butler Lampson joined DEC's Systems Research Center (SRC) shortly after it was formed by former PARC manager Bob Taylor. > ... I was working in the software tools > engineering group at the time, and we would have loved to take WRL's > work and to incorporate it in our products. But we couldn't. Why? > Because they wrote everything in Modula 3, and we were using BLISS. SRC used Modula-3, and before that a similar language called Modula-2+. Originally, WRL used Modula-2, and then I think switched to C. Perhaps DEC’s engineering groups should also have switched from Bliss to C. > Yes, PARC invented the modern windows-based GUI, but, as with so many > PARC innovations, Xerox did nothing with it. Based on how the PARC > alumni at WRL behaved at DEC,I would argue that this was the fault of > PARC as much as of Xerox management. Xerox built its Star office automation system based on PARC technology and with lots of support from PARC. Star was of course not a big success. PARC also invented laser printers, and Xerox made quite a bit of money from them. Paul McJones (former Xerox SDD and DEC SRC member — I have been on both sides of the fence) -------------- next part -------------- An HTML attachment was scrubbed... URL: From bakul at bitblocks.com Sun Jan 6 14:35:49 2019 From: bakul at bitblocks.com (Bakul Shah) Date: Sat, 05 Jan 2019 20:35:49 -0800 Subject: [TUHS] Isaacson v Unix In-Reply-To: Your message of "Fri, 04 Jan 2019 21:26:44 -0500." <201901050226.x052QigU089781@tahoe.cs.Dartmouth.EDU> References: <201901050226.x052QigU089781@tahoe.cs.Dartmouth.EDU> Message-ID: <20190106043556.F2DFD156E410@mail.bitblocks.com> > "Innovators" won general critical praise. A couple of reviews predicted > it would become the standard of the field. However, an evidently > knowledgeable review in IEEE Annals of the History of Computing faulted > it for peddling familiar potted legends without really digging for > deeper insight. Regarding Thompson and Ritchie, it looks more like > overt suppression. Why not ask @WalterIsaacson on twitter. He was chairman & CEO of CNN and managing editor of Time among other things so presumably he is/was interested in facts. From bakul at bitblocks.com Sun Jan 6 14:52:34 2019 From: bakul at bitblocks.com (Bakul Shah) Date: Sat, 05 Jan 2019 20:52:34 -0800 Subject: [TUHS] Isaacson v Unix In-Reply-To: Your message of "Sat, 05 Jan 2019 20:35:49 -0800." <20190106043556.F2DFD156E410@mail.bitblocks.com> References: <201901050226.x052QigU089781@tahoe.cs.Dartmouth.EDU> <20190106043556.F2DFD156E410@mail.bitblocks.com> Message-ID: <20190106045241.D436A156E410@mail.bitblocks.com> On Sat, 05 Jan 2019 20:35:49 -0800 Bakul Shah wrote: Bakul Shah writes: > > "Innovators" won general critical praise. A couple of reviews predicted > > it would become the standard of the field. However, an evidently > > knowledgeable review in IEEE Annals of the History of Computing faulted > > it for peddling familiar potted legends without really digging for > > deeper insight. Regarding Thompson and Ritchie, it looks more like > > overt suppression. > > Why not ask @WalterIsaacson on twitter. He was chairman & CEO > of CNN and managing editor of Time among other things so > presumably he is/was interested in facts. And a professor of history at Tulane. I am sure he is interested in getting the history right, right?! From toby at telegraphics.com.au Sun Jan 6 15:00:02 2019 From: toby at telegraphics.com.au (Toby Thain) Date: Sun, 6 Jan 2019 00:00:02 -0500 Subject: [TUHS] Isaacson v Unix In-Reply-To: <20190106043556.F2DFD156E410@mail.bitblocks.com> References: <201901050226.x052QigU089781@tahoe.cs.Dartmouth.EDU> <20190106043556.F2DFD156E410@mail.bitblocks.com> Message-ID: <4df24a75-636c-9c2d-337c-6434a5333e67@telegraphics.com.au> On 2019-01-05 11:35 PM, Bakul Shah wrote: >> "Innovators" won general critical praise. A couple of reviews predicted >> it would become the standard of the field. However, an evidently >> knowledgeable review in IEEE Annals of the History of Computing faulted >> it for peddling familiar potted legends without really digging for >> deeper insight. Regarding Thompson and Ritchie, it looks more like >> overt suppression. > > Why not ask @WalterIsaacson on twitter. He was chairman & CEO > of CNN and managing editor of Time among other things so > presumably he is/was interested in facts. > Dry wit indeed. From mutiny.mutiny at india.com Sun Jan 6 16:01:44 2019 From: mutiny.mutiny at india.com (Donald ODona) Date: Sun, 6 Jan 2019 06:01:44 +0000 (UTC) Subject: [TUHS] Emacs (was: Isaacson v Unix) In-Reply-To: <20190106024054.GA27103@eureka.lemis.com> References: <201901050226.x052QigU089781@tahoe.cs.Dartmouth.EDU> <22BA2F17-310F-4396-A35A-23E2D1130018@ronnatalie.com> <20190105153133.GA24497@mcvoy.com> <857E28A8-A1A7-48DD-A60D-05FADD93C6C5@eschatologist.net>, <20190106024054.GA27103@eureka.lemis.com> Message-ID: <1584792008.119344.1546754504662.JavaMail.tomcat@india-live-be04> teco, a very early (even earlier than qed/ed) character based editor, rather a stream editor in unix terms, was written by the student dan murphy for the pdp-1 in around 1964. In the 70ths two teco macro collections were popular in MIT's AI lab: tmacs&temacs, written by gus steele et al., leaving both packages unmaintained. rms took over maintenance, consolidating and improving them. That's all. He neither written teco nor the teco macro packages. At 6 Jan 2019 02:51:32 +0000 (+00:00) from Greg 'groggy' Lehey : > On Saturday, 5 January 2019 at 17:43:43 -0800, Chris Hanson wrote: > > On Jan 5, 2019, at 7:31 AM, Larry McVoy wrote: > >> > >> +1. RMS always talked big but the real work was done by other people. > >> GCC was Tiemann at Sun and then at Cygnus, groff was James Clark, > >> etc. I think RMS hacked on emacs but not much else. > > > > Which I thought was originally derived from Unipress emacs > > (Gosmacs), and was why old source code used to be hard to find. > > I don't think there's any serious doubt that rms wrote the original > Emacs, in TECO. If I understand it correctly, though, he took > significant improvements, including screen redisplay, from Gosling > Emacs. > > Greg > -- > Sent from my desktop computer. > Finger grog at lemis.com for PGP public key. > See complete headers for address and phone numbers. > This message is digitally signed. If your Microsoft mail program > reports problems, please read http://lemis.com/broken-MUA From lm at mcvoy.com Sun Jan 6 16:03:55 2019 From: lm at mcvoy.com (Larry McVoy) Date: Sat, 5 Jan 2019 22:03:55 -0800 Subject: [TUHS] Emacs (was: Isaacson v Unix) In-Reply-To: <1584792008.119344.1546754504662.JavaMail.tomcat@india-live-be04> References: <201901050226.x052QigU089781@tahoe.cs.Dartmouth.EDU> <22BA2F17-310F-4396-A35A-23E2D1130018@ronnatalie.com> <20190105153133.GA24497@mcvoy.com> <857E28A8-A1A7-48DD-A60D-05FADD93C6C5@eschatologist.net> <20190106024054.GA27103@eureka.lemis.com> <1584792008.119344.1546754504662.JavaMail.tomcat@india-live-be04> Message-ID: <20190106060355.GP24497@mcvoy.com> This is a distraction, but didn't the BDS C guy take some of those interfaces into his editor? On Sun, Jan 06, 2019 at 06:01:44AM +0000, Donald ODona wrote: > teco, a very early (even earlier than qed/ed) character based editor, rather a stream editor in unix terms, was written by the student dan murphy for the pdp-1 in around 1964. In the 70ths two teco macro collections were popular in MIT's AI lab: tmacs&temacs, written by gus steele et al., leaving both packages unmaintained. rms took over maintenance, consolidating and improving them. That's all. He neither written teco nor the teco macro packages. > > > At 6 Jan 2019 02:51:32 +0000 (+00:00) from Greg 'groggy' Lehey : > > On Saturday, 5 January 2019 at 17:43:43 -0800, Chris Hanson wrote: > > > On Jan 5, 2019, at 7:31 AM, Larry McVoy wrote: > > >> > > >> +1. RMS always talked big but the real work was done by other people. > > >> GCC was Tiemann at Sun and then at Cygnus, groff was James Clark, > > >> etc. I think RMS hacked on emacs but not much else. > > > > > > Which I thought was originally derived from Unipress emacs > > > (Gosmacs), and was why old source code used to be hard to find. > > > > I don't think there's any serious doubt that rms wrote the original > > Emacs, in TECO. If I understand it correctly, though, he took > > significant improvements, including screen redisplay, from Gosling > > Emacs. > > > > Greg > > -- > > Sent from my desktop computer. > > Finger grog at lemis.com for PGP public key. > > See complete headers for address and phone numbers. > > This message is digitally signed. If your Microsoft mail program > > reports problems, please read http://lemis.com/broken-MUA -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From cmhanson at eschatologist.net Sun Jan 6 16:26:33 2019 From: cmhanson at eschatologist.net (Chris Hanson) Date: Sat, 5 Jan 2019 22:26:33 -0800 Subject: [TUHS] Emacs (was: Isaacson v Unix) In-Reply-To: <20190106024054.GA27103@eureka.lemis.com> References: <201901050226.x052QigU089781@tahoe.cs.Dartmouth.EDU> <22BA2F17-310F-4396-A35A-23E2D1130018@ronnatalie.com> <20190105153133.GA24497@mcvoy.com> <857E28A8-A1A7-48DD-A60D-05FADD93C6C5@eschatologist.net> <20190106024054.GA27103@eureka.lemis.com> Message-ID: <16571FEB-7E52-44ED-B773-B23E8BE7FAD9@eschatologist.net> On Jan 5, 2019, at 6:40 PM, Greg 'groggy' Lehey wrote: > > On Saturday, 5 January 2019 at 17:43:43 -0800, Chris Hanson wrote: >> On Jan 5, 2019, at 7:31 AM, Larry McVoy wrote: >>> >>> +1. RMS always talked big but the real work was done by other people. >>> GCC was Tiemann at Sun and then at Cygnus, groff was James Clark, >>> etc. I think RMS hacked on emacs but not much else. >> >> Which I thought was originally derived from Unipress emacs >> (Gosmacs), and was why old source code used to be hard to find. > > I don't think there's any serious doubt that rms wrote the original > Emacs, in TECO. That’s not what I’m referring to, I’m referring to GNU emacs. (Also, he didn’t write the original emacs. He took it over.) > If I understand it correctly, though, he took > significant improvements, including screen redisplay, from Gosling > Emacs. GNU emacs is not a descendant of the TECO package. What I’m referring to is that GNU emacs started as a set of hacks on Gosmacs, and the Gosmacs code had to be excised because it wasn’t actually something FSF could redistribute as their own. -- Chris From lars at nocrew.org Sun Jan 6 17:50:57 2019 From: lars at nocrew.org (Lars Brinkhoff) Date: Sun, 06 Jan 2019 07:50:57 +0000 Subject: [TUHS] Emacs In-Reply-To: <20190106024054.GA27103@eureka.lemis.com> (Greg Lehey's message of "Sun, 6 Jan 2019 13:40:54 +1100") References: <201901050226.x052QigU089781@tahoe.cs.Dartmouth.EDU> <22BA2F17-310F-4396-A35A-23E2D1130018@ronnatalie.com> <20190105153133.GA24497@mcvoy.com> <857E28A8-A1A7-48DD-A60D-05FADD93C6C5@eschatologist.net> <20190106024054.GA27103@eureka.lemis.com> Message-ID: <7wef9q8bry.fsf@junk.nocrew.org> Greg 'groggy' Lehey wrote: > I don't think there's any serious doubt that rms wrote the original > Emacs, in TECO. That's an oversimplification. RMS may have done most of the work, but he was not the first. Here's some interesting reading from 1978: https://github.com/PDP-10/its/blob/master/doc/eak/emacs.lore Chris Hanson wrote: > (Also, he didn’t write the original emacs. He took it over.) That's right. RMS is often credited with the ^R real-time display feature, but that too originated earlier by Mikkelsen. >> If I understand it correctly, though, he took significant >> improvements, including screen redisplay, from Gosling Emacs. > > GNU emacs is not a descendant of the TECO package. What I’m referring > to is that GNU emacs started as a set of hacks on Gosmacs, and the > Gosmacs code had to be excised because it wasn’t actually something > FSF could redistribute as their own. Also correct. I found a copy of GNU Emacs 13.8 which I believe is the first version to be distributed. It has the Gosling display code. From lars at nocrew.org Mon Jan 7 00:30:02 2019 From: lars at nocrew.org (Lars Brinkhoff) Date: Sun, 06 Jan 2019 14:30:02 +0000 Subject: [TUHS] Emacs In-Reply-To: (Andrew Luke Nesbit's message of "Sun, 6 Jan 2019 14:23:51 +0000") References: <201901050226.x052QigU089781@tahoe.cs.Dartmouth.EDU> <22BA2F17-310F-4396-A35A-23E2D1130018@ronnatalie.com> <20190105153133.GA24497@mcvoy.com> <857E28A8-A1A7-48DD-A60D-05FADD93C6C5@eschatologist.net> <20190106024054.GA27103@eureka.lemis.com> <7wef9q8bry.fsf@junk.nocrew.org> Message-ID: <7wzhsd7tat.fsf@junk.nocrew.org> Andrew Luke Nesbit wrote: >> I found a copy of GNU Emacs 13.8 which I believe is the first version >> to be distributed. It has the Gosling display code. > Wow! Where did you find this? Online? Yes, on a DECUS tape with VMS software. I'm not sure it runs on VMS, though. This link sometimes works, sometimes doesn't. But I have it mirrored. http://decuslib.com/decus/vax85b/gnuemax/emacs/ > What OS does it run on - ITS? Is it available for something like Unix? I haven't tried to compile it, but my guess would be 4.2 ish BSD. Whatever BSD was contemporary around 1985 I suppose. I did try 16.56 on 4.1BSD, but it wasn't an immediate success. Some things seemed to be missing from BSD. 4.3BSD came with a copy of GNU Emacs 17.61. From ullbeking at andrewnesbit.org Mon Jan 7 00:23:51 2019 From: ullbeking at andrewnesbit.org (Andrew Luke Nesbit) Date: Sun, 6 Jan 2019 14:23:51 +0000 Subject: [TUHS] Emacs In-Reply-To: <7wef9q8bry.fsf@junk.nocrew.org> References: <201901050226.x052QigU089781@tahoe.cs.Dartmouth.EDU> <22BA2F17-310F-4396-A35A-23E2D1130018@ronnatalie.com> <20190105153133.GA24497@mcvoy.com> <857E28A8-A1A7-48DD-A60D-05FADD93C6C5@eschatologist.net> <20190106024054.GA27103@eureka.lemis.com> <7wef9q8bry.fsf@junk.nocrew.org> Message-ID: On 06/01/2019 07:50, Lars Brinkhoff wrote: > I found a copy of GNU Emacs 13.8 which I believe is the > first version to be distributed. It has the Gosling display code. Wow! Where did you find this? Online? What OS does it run on - ITS? Is it available for something like Unix? Andrew -- OpenPGP key: EB28 0338 28B7 19DA DAB0 B193 D21D 996E 883B E5B9 From jon at fourwinds.com Mon Jan 7 09:41:33 2019 From: jon at fourwinds.com (Jon Steinhart) Date: Sun, 06 Jan 2019 15:41:33 -0800 Subject: [TUHS] Isaacson v Unix [really RMS bashing] Message-ID: <201901062341.x06NfXe2021557@darkstar.fourwinds.com> Been wanting to wade into this for a few days but needed to think about how. I think that we're all aware that RMS has atrocious personal habits. But I don't think that this mailing list is the place to discuss them unless it's somehow in the context of UNIX. Many seem to excuse RMS's revisionist view of the history of technology on the grounds that RMS claims that his memory isn't very good. I think that if he knows that he doesn't remember things then he should refrain from talking about them as if he does. As others have said, I don't conflate coding prowess with the ability to design. I've had many an argument with John Gilmore (one of the people who doesn't mind footing the cleaning and repair bill after allowing RMS to stay at his place) where he begins with "When I wrote GNU tar..." I've always responded by saying that writing tar is no big deal; the specification was the hard part. One place where I completely disagree with RMS that I think is in context for this list is his claim that Linux should be called GNU/Linux. I've written tons of software in my life, and I don't preface the name of each one with the parts list. Even if one believed that such an attribution scheme made sense, I would claim that it should be called internet/Linux. I would argue that Linux would not have happened without the internet making it possible for folks around the world to participate. And I think that there's a good chance that the tools would have been created anyway. Of course, I acknowledge that the GNU tools have been ported to Linux. Big deal. I haven't seen RMS arguing for GNU/Windows now that Microsoft has seen the light. Like many of you, Linux is not where I first started using GNU tools; I started using them on my Sun machines after Sun started charging extra for the compiler and included a licensing system that was broken and often interfered with getting work done. Jon From lm at mcvoy.com Mon Jan 7 10:49:29 2019 From: lm at mcvoy.com (Larry McVoy) Date: Sun, 6 Jan 2019 16:49:29 -0800 Subject: [TUHS] Isaacson v Unix [really RMS bashing] Message-ID: <20190107004929.GE24497@mcvoy.com> I think the RMS stuff should go away. It's not because I love the guy, I don't. It's because we have people like Ken and Rob and other heavy hitters and my hunch is they have little patience for this sort of thing (they might correct me if I'm wrong). I'd love to call out RMS on his BS but this isn't the place. This is the place for people who actually did real work on Unix to share those stories. Or so I think, it's up to Warren, not me. From a.phillip.garcia at gmail.com Mon Jan 7 11:29:57 2019 From: a.phillip.garcia at gmail.com (A. P. Garcia) Date: Sun, 6 Jan 2019 20:29:57 -0500 Subject: [TUHS] Isaacson v Unix [really RMS bashing] In-Reply-To: <201901062341.x06NfXe2021557@darkstar.fourwinds.com> References: <201901062341.x06NfXe2021557@darkstar.fourwinds.com> Message-ID: On Sun, Jan 6, 2019, 7:43 PM Jon Steinhart > I would argue that Linux would not have happened without the internet > making it possible for folks around the world to participate. And I think > that there's a good chance that the tools would have been created anyway. > That's more or less how I look at it. Back in the day there was comp.sources.unix for example. In Unix itself, there was /usr/ where tools developed by users other than the core developers belonged, and there was /usr/ucb/ where they put stuff from Berkeley. The culture surrounding Unix has always seemed to encourage outside participation, going back to the lenient licensing of Research Unix, and even before that, when it just existed at Murray Hill. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From toby at telegraphics.com.au Mon Jan 7 11:38:45 2019 From: toby at telegraphics.com.au (Toby Thain) Date: Sun, 6 Jan 2019 20:38:45 -0500 Subject: [TUHS] Isaacson v Unix [really RMS bashing] In-Reply-To: <201901062341.x06NfXe2021557@darkstar.fourwinds.com> References: <201901062341.x06NfXe2021557@darkstar.fourwinds.com> Message-ID: On 2019-01-06 6:41 PM, Jon Steinhart wrote: > ... > As others have said, I don't conflate coding prowess with the ability to > design. I've had many an argument with John Gilmore (one of the people > who doesn't mind footing the cleaning and repair bill after allowing RMS > to stay at his place) where he begins with "When I wrote GNU tar..." I've > always responded by saying that writing tar is no big deal; the specification > was the hard part. > Hear, hear. I'd aver this is very much the case in any typical software-related day job, and _definitely_ mine. --Toby From usotsuki at buric.co Mon Jan 7 11:59:18 2019 From: usotsuki at buric.co (Steve Nickolas) Date: Sun, 6 Jan 2019 20:59:18 -0500 (EST) Subject: [TUHS] Isaacson v Unix [really RMS bashing] In-Reply-To: References: <201901062341.x06NfXe2021557@darkstar.fourwinds.com> Message-ID: On Sun, 6 Jan 2019, A. P. Garcia wrote: > On Sun, Jan 6, 2019, 7:43 PM Jon Steinhart > > >> > I would argue that Linux would not have happened without the internet >> making it possible for folks around the world to participate. And I think >> that there's a good chance that the tools would have been created anyway. >> > > That's more or less how I look at it. Back in the day there was > comp.sources.unix for example. In Unix itself, there was /usr/ where tools > developed by users other than the core developers belonged, and there was > /usr/ucb/ where they put stuff from Berkeley. The culture surrounding Unix > has always seemed to encourage outside participation, going back to the > lenient licensing of Research Unix, and even before that, when it just > existed at Murray Hill. > >> > If not for GNU, Unix would still have been cloned. Net/2 happened in parallel, did it not? -uso. From lm at mcvoy.com Mon Jan 7 12:11:42 2019 From: lm at mcvoy.com (Larry McVoy) Date: Sun, 6 Jan 2019 18:11:42 -0800 Subject: [TUHS] Isaacson v Unix [really RMS bashing] In-Reply-To: References: <201901062341.x06NfXe2021557@darkstar.fourwinds.com> Message-ID: <20190107021142.GF24497@mcvoy.com> On Sun, Jan 06, 2019 at 08:38:45PM -0500, Toby Thain wrote: > On 2019-01-06 6:41 PM, Jon Steinhart wrote: > > ... > > As others have said, I don't conflate coding prowess with the ability to > > design. I've had many an argument with John Gilmore (one of the people > > who doesn't mind footing the cleaning and repair bill after allowing RMS > > to stay at his place) where he begins with "When I wrote GNU tar..." I've > > always responded by saying that writing tar is no big deal; the specification > > was the hard part. > > > > Hear, hear. I'd aver this is very much the case in any typical > software-related day job, and _definitely_ mine. Yep. The spec is hard, the code is easy. That is a pattern. I've been the guy behind decent sized projects, BitKeeper is 2673371 lines of code. Getting to a spec was hard, writing the code was easy. We were a tiny distributed team of about 10 engineers, the hard part was agreeing on a design. Which we did by getting on the phone and talking about what we talked about yesterday. We passed the idea between people and when we could do the pass back and forth and nothing had changed from the previous pass, we had a design. Coding that was just typing. It's very similar to what Udi Manber told me as an under grad, he said writing papers is easy. Not for me. But I came to understand that papers are two things: a big base of knowledge and an outline. If you have those two then the paper is just typing. He was right. From a.phillip.garcia at gmail.com Mon Jan 7 12:31:27 2019 From: a.phillip.garcia at gmail.com (A. P. Garcia) Date: Sun, 6 Jan 2019 21:31:27 -0500 Subject: [TUHS] Isaacson v Unix [really RMS bashing] In-Reply-To: <20190107021142.GF24497@mcvoy.com> References: <201901062341.x06NfXe2021557@darkstar.fourwinds.com> <20190107021142.GF24497@mcvoy.com> Message-ID: On Sun, Jan 6, 2019, 9:12 PM Larry McVoy On Sun, Jan 06, 2019 at 08:38:45PM -0500, Toby Thain wrote: > > On 2019-01-06 6:41 PM, Jon Steinhart wrote: > > > ... > > > As others have said, I don't conflate coding prowess with the ability > to > > > design. I've had many an argument with John Gilmore (one of the people > > > who doesn't mind footing the cleaning and repair bill after allowing > RMS > > > to stay at his place) where he begins with "When I wrote GNU tar..." > I've > > > always responded by saying that writing tar is no big deal; the > specification > > > was the hard part. > > > > > > > Hear, hear. I'd aver this is very much the case in any typical > > software-related day job, and _definitely_ mine. > > Yep. The spec is hard, the code is easy. That is a pattern. > > I've been the guy behind decent sized projects, BitKeeper is 2673371 > lines of code. Getting to a spec was hard, writing the code was easy. > We were a tiny distributed team of about 10 engineers, the hard part was > agreeing on a design. Which we did by getting on the phone and talking > about what we talked about yesterday. We passed the idea between people > and when we could do the pass back and forth and nothing had changed > from the previous pass, we had a design. Coding that was just typing. > > It's very similar to what Udi Manber told me as an under grad, he said > writing papers is easy. Not for me. But I came to understand that > papers are two things: a big base of knowledge and an outline. If you > have those two then the paper is just typing. He was right. > Coming back full circle, maybe the person with the right viewpoint was actually RMS. It's not about the technology. It's not about the code or the spec. Maybe it really is about the freedoms that he talks about. Maybe if bit keeper were FOSS from the start, the world would be using that instead of git. But where would be the value proposition in that? It's a tough question. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Mon Jan 7 12:39:30 2019 From: imp at bsdimp.com (Warner Losh) Date: Sun, 6 Jan 2019 19:39:30 -0700 Subject: [TUHS] Isaacson v Unix [really RMS bashing] In-Reply-To: References: <201901062341.x06NfXe2021557@darkstar.fourwinds.com> Message-ID: On Sun, Jan 6, 2019, 7:06 PM Steve Nickolas On Sun, 6 Jan 2019, A. P. Garcia wrote: > > > On Sun, Jan 6, 2019, 7:43 PM Jon Steinhart > > > > > > >> > > I would argue that Linux would not have happened without the internet > >> making it possible for folks around the world to participate. And I > think > >> that there's a good chance that the tools would have been created > anyway. > >> > > > > That's more or less how I look at it. Back in the day there was > > comp.sources.unix for example. In Unix itself, there was /usr/ where > tools > > developed by users other than the core developers belonged, and there was > > /usr/ucb/ where they put stuff from Berkeley. The culture surrounding > Unix > > has always seemed to encourage outside participation, going back to the > > lenient licensing of Research Unix, and even before that, when it just > > existed at Murray Hill. > > > >> > > > > If not for GNU, Unix would still have been cloned. Net/2 happened in > parallel, did it not? > Berkeley actively rewrote most of unix yes. Net/1 was released about the same time GNU was getting started. Net/2 and later 4.4 BSD continued this trend, where 4.4 was finally a complete system. BSD386 only lagged Linux by about a year and had much stronger networking support, but supported fewer obscure devices than linux... Warner Ps I know this glosses over a lot, and isn't intended to be pedantic as to who got where first. Only they were about the same time... and I'm especially glossing over the AT&T suits, etc. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From a.phillip.garcia at gmail.com Mon Jan 7 12:59:21 2019 From: a.phillip.garcia at gmail.com (A. P. Garcia) Date: Sun, 6 Jan 2019 21:59:21 -0500 Subject: [TUHS] Isaacson v Unix [really RMS bashing] In-Reply-To: References: <201901062341.x06NfXe2021557@darkstar.fourwinds.com> Message-ID: On Sun, Jan 6, 2019, 9:39 PM Warner Losh > > On Sun, Jan 6, 2019, 7:06 PM Steve Nickolas >> On Sun, 6 Jan 2019, A. P. Garcia wrote: >> >> If not for GNU, Unix would still have been cloned. Net/2 happened in >> parallel, did it not? >> > > Berkeley actively rewrote most of unix yes. Net/1 was released about the > same time GNU was getting started. Net/2 and later 4.4 BSD continued this > trend, where 4.4 was finally a complete system. BSD386 only lagged Linux by > about a year and had much stronger networking support, but supported fewer > obscure devices than linux... > > Warner > > Ps I know this glosses over a lot, and isn't intended to be pedantic as to > who got where first. Only they were about the same time... and I'm > especially glossing over the AT&T suits, etc. > It's really hard to say. How would you compile it? Clang didn't come along until 2007. The Amsterdam Compiler Kit, perhaps? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Mon Jan 7 13:32:32 2019 From: imp at bsdimp.com (Warner Losh) Date: Sun, 6 Jan 2019 20:32:32 -0700 Subject: [TUHS] Isaacson v Unix [really RMS bashing] In-Reply-To: References: <201901062341.x06NfXe2021557@darkstar.fourwinds.com> Message-ID: On Sun, Jan 6, 2019, 7:59 PM A. P. Garcia > > On Sun, Jan 6, 2019, 9:39 PM Warner Losh >> >> >> On Sun, Jan 6, 2019, 7:06 PM Steve Nickolas > >>> On Sun, 6 Jan 2019, A. P. Garcia wrote: >>> >>> If not for GNU, Unix would still have been cloned. Net/2 happened in >>> parallel, did it not? >>> >> >> Berkeley actively rewrote most of unix yes. Net/1 was released about the >> same time GNU was getting started. Net/2 and later 4.4 BSD continued this >> trend, where 4.4 was finally a complete system. BSD386 only lagged Linux by >> about a year and had much stronger networking support, but supported fewer >> obscure devices than linux... >> >> Warner >> >> Ps I know this glosses over a lot, and isn't intended to be pedantic as >> to who got where first. Only they were about the same time... and I'm >> especially glossing over the AT&T suits, etc. >> > > It's really hard to say. How would you compile it? Clang didn't come along > until 2007. The Amsterdam Compiler Kit, perhaps? > The portable c compiler PCC was used to bootstrap a lot of this. It kinda sucked, but was decent enough. Early unix vendors used it on a variety of platforms. Here different universities produced different back ends. But there was no central clearing house. Gcc was a bit innovative in that it provided that, which allowed people to cooperate enough to make it better than PCC, at first. Then better or comparable to vendor compilers. Competition with gcc in large measure drove Sun to unbundle its compilers so there was a revenue stream that could be pointed at technology improvements. Somewhere between 4.3 and 4.4 BSD started using gcc over pcc since it was easier to distribute. The gnu project was important, but not because it rewrote the kernel. It provided the enabling compilers for that... Warner > -------------- next part -------------- An HTML attachment was scrubbed... URL: From toby at telegraphics.com.au Mon Jan 7 15:05:27 2019 From: toby at telegraphics.com.au (Toby Thain) Date: Mon, 7 Jan 2019 00:05:27 -0500 Subject: [TUHS] Isaacson v Unix [really RMS bashing] In-Reply-To: References: <201901062341.x06NfXe2021557@darkstar.fourwinds.com> Message-ID: <492f4b7d-82a9-5ea7-0aa7-7303cc72b254@telegraphics.com.au> On 2019-01-06 9:59 PM, A. P. Garcia wrote: > > > On Sun, Jan 6, 2019, 9:39 PM Warner Losh wrote: > > > > On Sun, Jan 6, 2019, 7:06 PM Steve Nickolas wrote: > > On Sun, 6 Jan 2019, A. P. Garcia wrote: > > If not for GNU, Unix would still have been cloned.  Net/2 > happened in > parallel, did it not? > > > Berkeley actively rewrote most of unix yes. Net/1 was released about > the same time GNU was getting started. Net/2 and later 4.4 BSD > continued this trend, where 4.4 was finally a complete system. > BSD386 only lagged Linux by about a year and had much stronger > networking support, but supported fewer obscure devices than linux... > > Warner > > Ps I know this glosses over a lot, and isn't intended to be pedantic > as to who got where first. Only they were about the same time... and > I'm especially glossing over the AT&T suits, etc. > > > It's really hard to say. How would you compile it? Clang didn't come > along until 2007. The Amsterdam Compiler Kit, perhaps? > If you're asking about non-gcc ANSI C compilers? There were dozens; sometimes several per platform. One random example was lcc* (1994). And of course the vendor compilers at which gcc specifically took aim. There were also quite a number of non-GNU C++ compilers. --Toby * - https://en.wikipedia.org/wiki/LCC_(compiler) From akosela at andykosela.com Mon Jan 7 15:36:31 2019 From: akosela at andykosela.com (Andy Kosela) Date: Sun, 6 Jan 2019 23:36:31 -0600 Subject: [TUHS] Isaacson v Unix [really RMS bashing] In-Reply-To: References: <201901062341.x06NfXe2021557@darkstar.fourwinds.com> Message-ID: On Sun, Jan 6, 2019 at 9:01 PM A. P. Garcia wrote: > > > > On Sun, Jan 6, 2019, 9:39 PM Warner Losh > >> >> >> On Sun, Jan 6, 2019, 7:06 PM Steve Nickolas >> >>> On Sun, 6 Jan 2019, A. P. Garcia wrote: >>> >>> If not for GNU, Unix would still have been cloned. Net/2 happened in >>> parallel, did it not? >> >> >> Berkeley actively rewrote most of unix yes. Net/1 was released about the same time GNU was getting started. Net/2 and later 4.4 BSD continued this trend, where 4.4 was finally a complete system. BSD386 only lagged Linux by about a year and had much stronger networking support, but supported fewer obscure devices than linux... >> >> Warner >> >> Ps I know this glosses over a lot, and isn't intended to be pedantic as to who got where first. Only they were about the same time... and I'm especially glossing over the AT&T suits, etc. > > > It's really hard to say. How would you compile it? Clang didn't come along until 2007. The Amsterdam Compiler Kit, perhaps? I find it ironic that BSD people are so quick to bash RMS, yet they have been using his tools (gcc and various utils) for years... By reading this thread it appears there are more people that have personal issues with RMS than technical ones. I find usually there are two sides to each story though. One side is eloquently presented in 2001 movie "Revolution OS"[1] starring RMS amongst others. [1] https://www.youtube.com/watch?v=4vW62KqKJ5A --Andy --Andy From wkt at tuhs.org Mon Jan 7 15:45:28 2019 From: wkt at tuhs.org (Warren Toomey) Date: Mon, 7 Jan 2019 15:45:28 +1000 Subject: [TUHS] Gentle reminder: TUHS is for Unix Message-ID: <20190107054528.GA13473@minnie.tuhs.org> Hi all, back from a few days holiday. Just a reminder that the TUHS list is for things related to Unix. I don't mind a bit of topic drift, but if the topic goes completely away from Unix then the conversation should migrate to the COFF (Computer Old Farts Forum) list, coff at tuhs.org. I'll mark the "Isaacson" thread as closed on TUHS, but feel free to continue it over on COFF. Thanks, Warren From imp at bsdimp.com Tue Jan 8 07:21:00 2019 From: imp at bsdimp.com (Warner Losh) Date: Mon, 7 Jan 2019 14:21:00 -0700 Subject: [TUHS] Origin of the name 'strategy' Message-ID: So what's the origin of the name 'strategy' for the I/O routine in Unix that drivers provide? Everything I've found in the early papers just says that's what the routine is called. Is there a story behind why it was chosen? My own theory is that it's in the sense of 'coping strategy' when the driver needs to service more I/O for the upper layers, but that's just a WAG. Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Tue Jan 8 07:27:58 2019 From: dave at horsfall.org (Dave Horsfall) Date: Tue, 8 Jan 2019 08:27:58 +1100 (EST) Subject: [TUHS] Origin of the name 'strategy' In-Reply-To: References: Message-ID: On Mon, 7 Jan 2019, Warner Losh wrote: > So what's the origin of the name 'strategy'  for the I/O routine in Unix > that drivers provide? Everything I've found in the early papers just > says that's what the routine is called. Is there a story behind why it > was chosen? My own theory is that it's in the sense of 'coping strategy' > when the driver needs to service more I/O for the upper layers, but > that's just a WAG. My guess is that it's supposed to optimise disk access; Ken may know. -- Dave From crossd at gmail.com Tue Jan 8 07:28:42 2019 From: crossd at gmail.com (Dan Cross) Date: Mon, 7 Jan 2019 16:28:42 -0500 Subject: [TUHS] Origin of the name 'strategy' In-Reply-To: References: Message-ID: On Mon, Jan 7, 2019 at 4:22 PM Warner Losh wrote: > So what's the origin of the name 'strategy' for the I/O routine in Unix > that drivers provide? Everything I've found in the early papers just says > that's what the routine is called. Is there a story behind why it was > chosen? My own theory is that it's in the sense of 'coping strategy' when > the driver needs to service more I/O for the upper layers, but that's just > a WAG. > I always thought it had to do with computing the optimal strategy for writing blocks to the disc device.... I wonder where I got that impression from. Perhaps reading Bach? - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From fair-tuhs at netbsd.org Tue Jan 8 08:28:29 2019 From: fair-tuhs at netbsd.org (Erik E. Fair) Date: Mon, 07 Jan 2019 14:28:29 -0800 Subject: [TUHS] Origin of the name 'strategy' In-Reply-To: References: Message-ID: <868.1546900109@cesium.clock.org> >From: Dan Cross >Date: Mon, 7 Jan 2019 16:28:42 -0500 > >I always thought it had to do with computing the optimal strategy for >writing blocks to the disc device.... I wonder where I got that impression >from. Perhaps reading Bach? Perhaps from reading the strategy routines of disk device drivers? That's where disksort() routine to perform HDA seek minimization via elevator sort is called. Still true in NetBSD today, though some of the routine names have changed. That would seem worth of being called a "strategy". Erik Fair From steve at quintile.net Tue Jan 8 20:15:06 2019 From: steve at quintile.net (Steve Simon) Date: Tue, 8 Jan 2019 10:15:06 +0000 Subject: [TUHS] TUHS Digest, Vol 38, Issue 10 In-Reply-To: References: Message-ID: <966501A7-7736-4EB0-841A-C1516C876272@quintile.net> re disk stagey i understood that this implemented the elevator algorithm, and possible rotational latency compensation. re non-gcc compilers there was a time in the early 2000s when some people tried release plan9’s (ken’s) c compiler for use in BSD bsd, sadly (for plan9) this didn't happen. pcc was reanimated instead. From andreas.kahari at abc.se Tue Jan 8 21:00:07 2019 From: andreas.kahari at abc.se (Andreas Kusalananda =?iso-8859-1?B?S+Ro5HJp?=) Date: Tue, 8 Jan 2019 12:00:07 +0100 Subject: [TUHS] TUHS Digest, Vol 38, Issue 10 In-Reply-To: <966501A7-7736-4EB0-841A-C1516C876272@quintile.net> References: <966501A7-7736-4EB0-841A-C1516C876272@quintile.net> Message-ID: <20190108110007.GA42784@eeyore.my.domain> On Tue, Jan 08, 2019 at 10:15:06AM +0000, Steve Simon wrote: > > re disk stagey > i understood that this implemented the elevator algorithm, and possible rotational latency compensation. > > re non-gcc compilers > there was a time in the early 2000s when some people tried release plan9’s (ken’s) c compiler for use in BSD bsd, sadly (for plan9) this didn't happen. pcc was reanimated instead. It is possible that this is related to that second point? http://gsoc.cat-v.org/projects/kencc/ -- Andreas Kusalananda Kähäri, National Bioinformatics Infrastructure Sweden (NBIS), Uppsala University, Sweden. From imp at bsdimp.com Wed Jan 9 00:58:49 2019 From: imp at bsdimp.com (Warner Losh) Date: Tue, 8 Jan 2019 07:58:49 -0700 Subject: [TUHS] TUHS Digest, Vol 38, Issue 10 In-Reply-To: <966501A7-7736-4EB0-841A-C1516C876272@quintile.net> References: <966501A7-7736-4EB0-841A-C1516C876272@quintile.net> Message-ID: On Tue, Jan 8, 2019 at 3:44 AM Steve Simon wrote: > > re disk stagey > i understood that this implemented the elevator algorithm, and possible > rotational latency compensation. > I know what it does. I want to know why that specific name was selected. Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From ca6c at bitmessage.ch Wed Jan 9 02:12:54 2019 From: ca6c at bitmessage.ch (=?UTF-8?Q?C=C3=A1g?=) Date: Tue, 08 Jan 2019 10:12:54 -0600 Subject: [TUHS] off topic - capatob - saratov2 computer Russsian pdp8? HELP In-Reply-To: <193D6345-8E32-49A6-8F16-A30672C222A8@csp-partnership.co.uk> References: <193D6345-8E32-49A6-8F16-A30672C222A8@csp-partnership.co.uk> Message-ID: Dr Iain Maoileoin wrote: > Off topic, but looking for help and wisdom. > > If you visit https://www.scotnet.co.uk/iain/saratov you will see some > photos of work that I have started on the front panel of a Capatob2. > > I plan to get the switches and lights running on a blinkenbone board > with a PDP8 emulation behind it. (I already have an PDP11/70 > front-panel running on the same infrastructure) > > I have been struggling for over a year to get much info about this > saratov computer (circuit diagrams etc). So I have started the > reverse engineering on the panel. > > Does anybody know anything about this computer? online or offline it > would be much appreciated. Hi, It's Saratov, not Capatob (Cyrillic). Since it was made by Russians during the Soviet period, there's no wonder you can't find any documentation regarding it. It was made by CIME -- Central Institute of Measuring Equipment. The company is alive to this day, you can visit the website (in Russian) -- http://www.cime.ru/ or contact them at cime at cime dot ru, maybe you'll have some luck. There's a thread (in Russian) about it: http://www.nedopc.org/forum/viewtopic.php?t=9778 From there I can see that it has FOCAL, Fotran, and assemblers, just like the PDP. On front in the center there are five lights that indicate the step counter. Saratov is a city on Volga where CIME is located -- https://en.wikipedia.org/wiki/Saratov -- caóc From arnold at skeeve.com Wed Jan 9 03:19:51 2019 From: arnold at skeeve.com (Arnold Robbins) Date: Tue, 08 Jan 2019 19:19:51 +0200 Subject: [TUHS] QED archive now available Message-ID: <201901081719.x08HJpdp003869@skeeve.com> Hi All. Back in October I started a discussion about QED sources. A number of people were kind enough to send me tarballs and zip files as well as pointers to other archives. I have finally cobbled it all together and made it available on GitHub: https://github.com/arnoldrobbins/qed-archive I have tried to acknowledge everyone who contributed. Thanks again to all who did send me stuff and email me. Enjoy, Arnold From wkt at tuhs.org Wed Jan 9 10:35:16 2019 From: wkt at tuhs.org (Warren Toomey) Date: Wed, 9 Jan 2019 10:35:16 +1000 Subject: [TUHS] National Inventors Hall of Fame honors creators of Unix Message-ID: <20190109003516.GA30682@minnie.tuhs.org> https://www.engadget.com/2019/01/08/national-inventors-hall-of-fame-class-of-2019/ The National Inventors Hall of Fame (NIHF) joined Engadget on stage today at CES to announce its 2019 class of inductees. [ including ] ... Dennis Ritchie (Posthumous) and Ken Thompson: UNIX Operating System ------------------------------------------------------------------- Thompson and Ritchie's creation of the UNIX operating system and the C programming language were pivotal developments in the progress of computer science. Today, 50 years after its beginnings, UNIX and UNIX-like systems continue to run machinery from supercomputers to smartphones. The UNIX operating system remains the basis of much of the world's computing infrastructure, and C language -- written to simplify the development of UNIX -- is one of the most widely used languages today. Cheers, Warren From jon at fourwinds.com Wed Jan 9 10:38:03 2019 From: jon at fourwinds.com (Jon Steinhart) Date: Tue, 08 Jan 2019 16:38:03 -0800 Subject: [TUHS] National Inventors Hall of Fame honors creators of Unix In-Reply-To: <20190109003516.GA30682@minnie.tuhs.org> References: <20190109003516.GA30682@minnie.tuhs.org> Message-ID: <201901090038.x090c4uB013516@darkstar.fourwinds.com> Warren Toomey writes: > https://www.engadget.com/2019/01/08/national-inventors-hall-of-fame-class-of-2019/ > > The National Inventors Hall of Fame (NIHF) joined Engadget on stage > today at CES to announce its 2019 class of inductees. [ including ] ... > > Dennis Ritchie (Posthumous) and Ken Thompson: UNIX Operating System > ------------------------------------------------------------------- > Thompson and Ritchie's creation of the UNIX operating system and the C > programming language were pivotal developments in the progress of computer > science. Today, 50 years after its beginnings, UNIX and UNIX-like systems > continue to run machinery from supercomputers to smartphones. The UNIX > operating system remains the basis of much of the world's computing > infrastructure, and C language -- written to simplify the development > of UNIX -- is one of the most widely used languages today. > > Cheers, Warren Huh. How can the go off and give awards like this to people that Issacson claims did nothing of value :-) From dave at horsfall.org Wed Jan 9 12:10:18 2019 From: dave at horsfall.org (Dave Horsfall) Date: Wed, 9 Jan 2019 13:10:18 +1100 (EST) Subject: [TUHS] TUHS Digest, Vol 38, Issue 10 In-Reply-To: References: <966501A7-7736-4EB0-841A-C1516C876272@quintile.net> Message-ID: On Tue, 8 Jan 2019, Warner Losh wrote: > i understood that this implemented the elevator algorithm, and > possible rotational latency compensation. > > > I know what it does. I want to know why that specific name was selected. Err, because as I replied in a previous message (did you not see it?), it was up to the programmer to implement an optimal strategy to access the sectors, depending upon the device? I'm not being snarky, but it seems like an obvious choice (if not a hint) to me... Let's see, I need a strategy to optimise access, taking into account seek and rotational latency. I know! I'll call it XXstrategy()! For example, I could envisage a disk where the sectors are deliberately not numbered sequentially i.e. they've taken rotational latency into account for you? Out of interest, what would you have called it? XXaccess(), perhaps? -- Dave From imp at bsdimp.com Wed Jan 9 14:23:54 2019 From: imp at bsdimp.com (Warner Losh) Date: Tue, 8 Jan 2019 21:23:54 -0700 Subject: [TUHS] TUHS Digest, Vol 38, Issue 10 In-Reply-To: References: <966501A7-7736-4EB0-841A-C1516C876272@quintile.net> Message-ID: On Tue, Jan 8, 2019, 7:11 PM Dave Horsfall On Tue, 8 Jan 2019, Warner Losh wrote: > > > i understood that this implemented the elevator algorithm, and > > possible rotational latency compensation. > > > > > > I know what it does. I want to know why that specific name was selected. > > Err, because as I replied in a previous message (did you not see it?), it > was up to the programmer to implement an optimal strategy to access the > sectors, depending upon the device? I'm not being snarky, but it seems > like an obvious choice (if not a hint) to me... > > Let's see, I need a strategy to optimise access, taking into account > seek and rotational latency. I know! I'll call it XXstrategy()! > > For example, I could envisage a disk where the sectors are deliberately > not numbered sequentially i.e. they've taken rotational latency into > account for you? > > Out of interest, what would you have called it? XXaccess(), perhaps? > The name seems obvious because I've seen it for the last 30 years. But I've not seen it used elsewhere, nor have I seen it documented except in relationship to Unix. It could have been called blkio or bufio or bio or even just work or morework and still been as meaningful. VMS uses the FDT table to process the IRPs sent down. RT-11 has a series of entry points that have boring names. Other systems have a start routine (though more often that is a common routine used by both the queue me and isr functions). There is a wide diversity here... Warner > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bakul at bitblocks.com Wed Jan 9 15:19:57 2019 From: bakul at bitblocks.com (Bakul Shah) Date: Tue, 08 Jan 2019 21:19:57 -0800 Subject: [TUHS] TUHS Digest, Vol 38, Issue 10 In-Reply-To: Your message of "Wed, 09 Jan 2019 13:10:18 +1100." References: <966501A7-7736-4EB0-841A-C1516C876272@quintile.net> Message-ID: <20190109052004.9DB6F156E410@mail.bitblocks.com> On Wed, 09 Jan 2019 13:10:18 +1100 Dave Horsfall wrote: Dave Horsfall writes: > On Tue, 8 Jan 2019, Warner Losh wrote: > > > i understood that this implemented the elevator algorithm, and > > possible rotational latency compensation. > > > > > > I know what it does. I want to know why that specific name was selected. > > Err, because as I replied in a previous message (did you not see it?), it > was up to the programmer to implement an optimal strategy to access the > sectors, depending upon the device? I'm not being snarky, but it seems > like an obvious choice (if not a hint) to me... > > Let's see, I need a strategy to optimise access, taking into account > seek and rotational latency. I know! I'll call it XXstrategy()! I too wondered about "strategy" in 1981 when I first worked on unix disk drivers. My guess then was something similar. Anything other than a FIFO strategy would improve throughput or fairness or avoid starvation but was much more complex due to the fact you can't reoder reads & writes. My guess is the original author who named it strategy had this in mind. But these are not exactly dependent on the vagaries of individual disk drivers. At some point I factoroued out code so that each specific disk driver took about 1KB of code and shared about 7KB of common code. > For example, I could envisage a disk where the sectors are deliberately > not numbered sequentially i.e. they've taken rotational latency into > account for you? We did in fact use an interleave factor of more than 1 (skip more than 1 block for consecutively numbered sectors) to improve throughput but that had to do with slow processing. We did discuss "dead reckoning" (invoking the service routine right when the N+1 numbered sector was near the r/w heads) but I don't think we implemented it. From dave at horsfall.org Wed Jan 9 15:42:32 2019 From: dave at horsfall.org (Dave Horsfall) Date: Wed, 9 Jan 2019 16:42:32 +1100 (EST) Subject: [TUHS] Origin of the name 'strategy' Message-ID: On Tue, 8 Jan 2019, Warner Losh wrote: > The name seems obvious because I've seen it for the last 30 years. But > I've not seen it used elsewhere, nor have I seen it documented except in > relationship to Unix. It could have been called blkio or bufio or bio or > even just work or morework and still been as meaningful. VMS uses the > FDT table to process the IRPs sent down. RT-11 has a series of entry > points that have boring names. Other systems have a start routine > (though more often that is a common routine used by both the queue me > and isr functions). There is a wide diversity here... I must admit that this is an interesting thread, just as long as it wasn't called XXoptimize() unless you wanted a backlash from British English speakers :-) In hindsight I suppose that XXstrategy() is obvious, but back then, as you ask? Dunno, but Ken might (if he's reading this thread). One of my favo[u]rites is sched(); some pronounce it as "shed" and others as "sked". Another American/British thing, I think... Wasn't it Mark Twain who said "Two nations divided by a common language"? I no longer have my Lions books on me, sadly enough (lost in a house move) but there certainly were some peculiar names in the kernel... ObGripe: Could anyone replying to the digest version please take the trouble to update the Subject: line accordingly? I've now put the original back as a courtesy to others, but I shouldn't have to; it's as bad as top-posting. -- Dave From imp at bsdimp.com Wed Jan 9 15:45:31 2019 From: imp at bsdimp.com (Warner Losh) Date: Tue, 8 Jan 2019 22:45:31 -0700 Subject: [TUHS] TUHS Digest, Vol 38, Issue 10 In-Reply-To: <20190109052004.9DB6F156E410@mail.bitblocks.com> References: <966501A7-7736-4EB0-841A-C1516C876272@quintile.net> <20190109052004.9DB6F156E410@mail.bitblocks.com> Message-ID: On Tue, Jan 8, 2019 at 10:20 PM Bakul Shah wrote: > On Wed, 09 Jan 2019 13:10:18 +1100 Dave Horsfall > wrote: > Dave Horsfall writes: > > On Tue, 8 Jan 2019, Warner Losh wrote: > > > > > i understood that this implemented the elevator algorithm, and > > > possible rotational latency compensation. > > > > > > > > > I know what it does. I want to know why that specific name was > selected. > > > > Err, because as I replied in a previous message (did you not see it?), > it > > was up to the programmer to implement an optimal strategy to access the > > sectors, depending upon the device? I'm not being snarky, but it seems > > like an obvious choice (if not a hint) to me... > > > > Let's see, I need a strategy to optimise access, taking into account > > seek and rotational latency. I know! I'll call it XXstrategy()! > > I too wondered about "strategy" in 1981 when I first worked on > unix disk drivers. My guess then was something similar. > Anything other than a FIFO strategy would improve throughput > or fairness or avoid starvation but was much more complex due > to the fact you can't reoder reads & writes. My guess is the > original author who named it strategy had this in mind. > Speaking of origins, it's in the V4 nsys (pre V5) sources we have. It's not in the V1 or V0 sources we have. I could find no comments in the V4 stuff or the V5 stuff to give its origin tale. > But these are not exactly dependent on the vagaries of > individual disk drivers. At some point I factoroued out code > so that each specific disk driver took about 1KB of code and > shared about 7KB of common code. > Yes. Many OSes have factored this out so the code can be shared among the (now wide variety) of devices out there, as well as tuned for different work loads. > > For example, I could envisage a disk where the sectors are deliberately > > not numbered sequentially i.e. they've taken rotational latency into > > account for you? > > We did in fact use an interleave factor of more than 1 (skip > more than 1 block for consecutively numbered sectors) to > improve throughput but that had to do with slow processing. > We did discuss "dead reckoning" (invoking the service routine > right when the N+1 numbered sector was near the r/w heads) but > I don't think we implemented it. > For floppy drivers that I've seen the source to in early unixes, this was often the case. One minor device would be to access the 'raw' device, while another would be to access the 'cooked' sector numbers where the mapping was anything but linear. you'd have an interleave of, say, 4 or so, and then a 'slip' from track to track. The interleave factor was based on how much time it took for (a) the disk to rotate and (b) for the OS to process the sector (plus a little) and the 'slip' from track to track was based on rotational time and seek time so that when you were doing a sequential workload the first logical sector in the next track would quickly be under the read head... All of this was done in the floppy driver. But there were some drawbacks to this that became clear as a number of different technologies to access the drive were developed. When you have 6 different floppy controllers, it makes sense to abstract out the bits that are common to all floppies. When you have 200 disk controllers in 20 different drivers, it makes sense to add a disk layer in there. Add to that partitioning schemes that are nested, and you quickly realize you don't want to implement all that in every driver... One of the brilliant decisions in Unix was to leave all this to the driver and not have the OS get in the way.... But it was also one that no modern unix or unix-like system still does due to the extreme diversity of block devices in the market place today. There are thousands, where the original unix had maybe a half dozen different ones if you squinted just right... At least disksort() was abstracted out into a library.. Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnold at skeeve.com Wed Jan 9 19:12:18 2019 From: arnold at skeeve.com (arnold at skeeve.com) Date: Wed, 09 Jan 2019 02:12:18 -0700 Subject: [TUHS] AT&T / Teletype DMD 5620 Emulator In-Reply-To: <8736q8xhb0.fsf@loomcom.com> References: <8736q8xhb0.fsf@loomcom.com> Message-ID: <201901090912.x099CITB027909@freefriends.org> This is pretty cool. Can you post links for this and the 3B2 emulator? I had one for a few years at Georgia Tech and I *loved* the keyboard. It was a huge productivity boost being able to have multiple windows. We used them connected to our Vax 11/780 with 4 Meg of memory running 4.[12] BSD (don't remember which) and having multiple DMD 5620s with multiple windows open on each drove the poor vax to its knees... Arnold "Seth J. Morabito" wrote: > > Hello folks, > > I realized I should mention this here on TUHS, since it is likely of > interest to at least some of you! > > I recently wrote a DMD 5620 emulator, currently available on Linux and > Macintosh, with Windows support coming soon. Here's a brief demo of the > Mac version: > > https://www.youtube.com/watch?v=tcSWqBmAMeY > > I wrote it because DMD 5620s are becoming incredibly rare, and showing > them off in person is quite difficult nowadays. > > This emulator is using ROM version 2.0 (8;7;5) dumped from my personal > 5620. If anyone out there has a DMD 5620 with an older ROM, I would be > incredibly grateful if you could dump the ROMs. I'd like to find > versions of 1.x (8;7;3 or earlier); so far I've had no luck. > > The main reason I'm interested in older ROMs, besides pure preservation > reasons, is that the 'mux' and 'muxterm' system on Research UNIX V8/V9 > is hard-coded for the 1.1 ROMs. It doesn't work with the emulator > without significant tweaking of the source. It DOES work perfectly well > with the DMD Core Utilities package for the AT&T 3B2, however. > > All the best! > > -Seth > -- > Seth Morabito > Poulsbo, WA, USA > web at loomcom.com From spedraja at gmail.com Wed Jan 9 19:35:00 2019 From: spedraja at gmail.com (SPC) Date: Wed, 9 Jan 2019 10:35:00 +0100 Subject: [TUHS] AT&T / Teletype DMD 5620 Emulator In-Reply-To: <8736q8xhb0.fsf@loomcom.com> References: <8736q8xhb0.fsf@loomcom.com> Message-ID: *Great* Work, Seth. Congratulations. Hope to see a public release of all this more than appreciable work (3B2 and DMD emulators) soon. All the Best for you too. Regards - Saludos | Greetings | Freundliche Grüße | Salutations -- *Sergio Pedraja* http://www.linkedin.com/in/sergiopedraja ----- No crea todo lo que ve, ni crea que está viéndolo todo ----- "El estado de una Copia de Seguridad es desconocido hasta que intentas restaurarla" (- nixCraft) ----- El vie., 4 ene. 2019 a las 22:18, Seth J. Morabito () escribió: > > Hello folks, > > I realized I should mention this here on TUHS, since it is likely of > interest to at least some of you! > > I recently wrote a DMD 5620 emulator, currently available on Linux and > Macintosh, with Windows support coming soon. Here's a brief demo of the > Mac version: > > https://www.youtube.com/watch?v=tcSWqBmAMeY > > -- > Seth Morabito > Poulsbo, WA, USA > web at loomcom.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From crossd at gmail.com Wed Jan 9 22:02:51 2019 From: crossd at gmail.com (Dan Cross) Date: Wed, 9 Jan 2019 07:02:51 -0500 Subject: [TUHS] Origin of the name 'strategy' In-Reply-To: References: Message-ID: On Wed, Jan 9, 2019, 12:43 AM Dave Horsfall [snip] > > Wasn't it Mark Twain who said "Two nations divided by a common language"? > Apocryphal, actually, but based on a line from one of George Bernard Shaw's plays. - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From aiju at phicode.de Thu Jan 10 00:54:29 2019 From: aiju at phicode.de (Julius Schmidt) Date: Wed, 9 Jan 2019 15:54:29 +0100 (CET) Subject: [TUHS] AT&T / Teletype DMD 5620 Emulator In-Reply-To: <8736q8xhb0.fsf@loomcom.com> References: <8736q8xhb0.fsf@loomcom.com> Message-ID: Neat! I wrote an emulator for the original 68K jerq/blit two years ago. The original Plan 9 version is at http://code.9front.org/hg/plan9front/file/tip/sys/src/games/blit A Javascript version is available at http://blit.aiju.de/ It connects to a public research unix V8 installation. Please play nice :) aiju On Fri, 4 Jan 2019, Seth J. Morabito wrote: > > Hello folks, > > I realized I should mention this here on TUHS, since it is likely of > interest to at least some of you! > > I recently wrote a DMD 5620 emulator, currently available on Linux and > Macintosh, with Windows support coming soon. Here's a brief demo of the > Mac version: > > https://www.youtube.com/watch?v=tcSWqBmAMeY > > I wrote it because DMD 5620s are becoming incredibly rare, and showing > them off in person is quite difficult nowadays. > > This emulator is using ROM version 2.0 (8;7;5) dumped from my personal > 5620. If anyone out there has a DMD 5620 with an older ROM, I would be > incredibly grateful if you could dump the ROMs. I'd like to find > versions of 1.x (8;7;3 or earlier); so far I've had no luck. > > The main reason I'm interested in older ROMs, besides pure preservation > reasons, is that the 'mux' and 'muxterm' system on Research UNIX V8/V9 > is hard-coded for the 1.1 ROMs. It doesn't work with the emulator > without significant tweaking of the source. It DOES work perfectly well > with the DMD Core Utilities package for the AT&T 3B2, however. > > All the best! > > -Seth > -- > Seth Morabito > Poulsbo, WA, USA > web at loomcom.com > From bakul at bitblocks.com Thu Jan 10 01:09:55 2019 From: bakul at bitblocks.com (Bakul Shah) Date: Wed, 09 Jan 2019 07:09:55 -0800 Subject: [TUHS] TUHS Digest, Vol 38, Issue 10 In-Reply-To: Your message of "Tue, 08 Jan 2019 22:45:31 -0700." References: <966501A7-7736-4EB0-841A-C1516C876272@quintile.net> <20190109052004.9DB6F156E410@mail.bitblocks.com> Message-ID: <20190109151002.E94D2156E41B@mail.bitblocks.com> On Tue, 08 Jan 2019 22:45:31 -0700 Warner Losh wrote: > > > > > For example, I could envisage a disk where the sectors are deliberately > > > not numbered sequentially i.e. they've taken rotational latency into > > > account for you? > > > > We did in fact use an interleave factor of more than 1 (skip > > more than 1 block for consecutively numbered sectors) to > > improve throughput but that had to do with slow processing. > > We did discuss "dead reckoning" (invoking the service routine > > right when the N+1 numbered sector was near the r/w heads) but > > I don't think we implemented it. > > > > For floppy drivers that I've seen the source to in early unixes, this was > often the case. One minor device would be to access the 'raw' device, while > another would be to access the 'cooked' sector numbers where the mapping > was anything but linear. you'd have an interleave of, say, 4 or so, and > then a 'slip' from track to track. The interleave factor was based on how We used interleaving on the hard disk because a 5Mbps ST412 drive could stream data faster than typical user program could handle (on a 5.6Mhz bus machine). We used h/w support as the machine was already too slow to do any s/w interleaving! Example: for an interleave of 1, at the time formatting the disk, sector ids would be written in this sequence: 1 8 2 9 3 A 4 B 5 C 6 D 7 E We picked the interleave number based on some typical use cases at the time. The floppy driver was was a completely separate driver for various reasons. From bakul at bitblocks.com Thu Jan 10 01:12:36 2019 From: bakul at bitblocks.com (Bakul Shah) Date: Wed, 09 Jan 2019 07:12:36 -0800 Subject: [TUHS] Lions book (not Origin of the name 'strategy' In-Reply-To: Your message of "Wed, 09 Jan 2019 16:42:32 +1100." References: Message-ID: <20190109151243.71EA7156E410@mail.bitblocks.com> On Wed, 09 Jan 2019 16:42:32 +1100 Dave Horsfall wrote: > > I no longer have my Lions books on me, sadly enough (lost in a house move) > but there certainly were some peculiar names in the kernel... https://github.com/kanner/lions-book From imp at bsdimp.com Thu Jan 10 02:09:16 2019 From: imp at bsdimp.com (Warner Losh) Date: Wed, 9 Jan 2019 09:09:16 -0700 Subject: [TUHS] Lions book (not Origin of the name 'strategy' In-Reply-To: <20190109151243.71EA7156E410@mail.bitblocks.com> References: <20190109151243.71EA7156E410@mail.bitblocks.com> Message-ID: On Wed, Jan 9, 2019 at 8:13 AM Bakul Shah wrote: > On Wed, 09 Jan 2019 16:42:32 +1100 Dave Horsfall > wrote: > > > > I no longer have my Lions books on me, sadly enough (lost in a house > move) > > but there certainly were some peculiar names in the kernel... > > https://github.com/kanner/lions-book Cool! I have two copies: one bootleg photocopy from the 80's and one copy of the paper that has the picture of the geeks on the cover photocopying something... This is a lot easier to grep :) Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Thu Jan 10 02:20:28 2019 From: clemc at ccc.com (Clem Cole) Date: Wed, 9 Jan 2019 11:20:28 -0500 Subject: [TUHS] Lions book (not Origin of the name 'strategy' In-Reply-To: References: <20190109151243.71EA7156E410@mail.bitblocks.com> Message-ID: Ditto, (actually I have three -- two copies of the new one to show some of the younger engineers at work). Having the text is wonderful, but it does seems like a heretical act to be grepping through sources as Tex files; when the original was in roff. I wonder if the author as well as Dennis are both chuckling somewhere at all of us ;-) ᐧ On Wed, Jan 9, 2019 at 11:10 AM Warner Losh wrote: > > > On Wed, Jan 9, 2019 at 8:13 AM Bakul Shah wrote: > >> On Wed, 09 Jan 2019 16:42:32 +1100 Dave Horsfall >> wrote: >> > >> > I no longer have my Lions books on me, sadly enough (lost in a house >> move) >> > but there certainly were some peculiar names in the kernel... >> >> https://github.com/kanner/lions-book > > > Cool! I have two copies: one bootleg photocopy from the 80's and one copy > of the paper that has the picture of the geeks on the cover photocopying > something... This is a lot easier to grep :) > > Warner > -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Thu Jan 10 02:50:20 2019 From: imp at bsdimp.com (Warner Losh) Date: Wed, 9 Jan 2019 09:50:20 -0700 Subject: [TUHS] Lions book (not Origin of the name 'strategy' In-Reply-To: References: <20190109151243.71EA7156E410@mail.bitblocks.com> Message-ID: What was amusing was seeing what I thought was a copy tucked away on the shelves of Kirk McKusick's library, next to weird things with odd labels like "BSD 4.5" (really something between what we know as BSD 4.0 and BSD 4.1 when the notion was the next BSD release tape would be called BSD5) next to more mundane ones like "V6" and "V32" etc. It's definitely a piece of folklore that turns up in the oddest places... Warner On Wed, Jan 9, 2019 at 9:20 AM Clem Cole wrote: > Ditto, (actually I have three -- two copies of the new one to show some of > the younger engineers at work). Having the text is wonderful, but it does > seems like a heretical act to be grepping through sources as Tex files; > when the original was in roff. > > I wonder if the author as well as Dennis are both chuckling somewhere at > all of us ;-) > ᐧ > > On Wed, Jan 9, 2019 at 11:10 AM Warner Losh wrote: > >> >> >> On Wed, Jan 9, 2019 at 8:13 AM Bakul Shah wrote: >> >>> On Wed, 09 Jan 2019 16:42:32 +1100 Dave Horsfall >>> wrote: >>> > >>> > I no longer have my Lions books on me, sadly enough (lost in a house >>> move) >>> > but there certainly were some peculiar names in the kernel... >>> >>> https://github.com/kanner/lions-book >> >> >> Cool! I have two copies: one bootleg photocopy from the 80's and one copy >> of the paper that has the picture of the geeks on the cover photocopying >> something... This is a lot easier to grep :) >> >> Warner >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From akosela at andykosela.com Thu Jan 10 03:20:14 2019 From: akosela at andykosela.com (Andy Kosela) Date: Wed, 9 Jan 2019 11:20:14 -0600 Subject: [TUHS] Lions book (not Origin of the name 'strategy' In-Reply-To: References: <20190109151243.71EA7156E410@mail.bitblocks.com> Message-ID: On Wednesday, January 9, 2019, Warner Losh wrote: > > > On Wed, Jan 9, 2019 at 8:13 AM Bakul Shah wrote: > >> On Wed, 09 Jan 2019 16:42:32 +1100 Dave Horsfall >> wrote: >> > >> > I no longer have my Lions books on me, sadly enough (lost in a house >> move) >> > but there certainly were some peculiar names in the kernel... >> >> https://github.com/kanner/lions-book > > > Cool! I have two copies: one bootleg photocopy from the 80's and one copy > of the paper that has the picture of the geeks on the cover photocopying > something... This is a lot easier to grep :) > > > That one with hackers on the cover is still available on Amazon[1]. It was published in 1996. —Andy [1] https://www.amazon.com/Lions-Commentary-Unix-John/dp/1573980137/ref=sr_1_1?ie=UTF8&qid=1547054228&sr=8-1&keywords=john+lion+unix+6 -------------- next part -------------- An HTML attachment was scrubbed... URL: From bakul at bitblocks.com Thu Jan 10 03:50:00 2019 From: bakul at bitblocks.com (Bakul Shah) Date: Wed, 09 Jan 2019 09:50:00 -0800 Subject: [TUHS] Lions book (not Origin of the name 'strategy' In-Reply-To: Your message of "Wed, 09 Jan 2019 11:20:28 -0500." References: <20190109151243.71EA7156E410@mail.bitblocks.com> Message-ID: <20190109175007.662E5156E41B@mail.bitblocks.com> On Wed, 09 Jan 2019 11:20:28 -0500 Clem Cole wrote: > > Ditto, (actually I have three -- two copies of the new one to show some of > the younger engineers at work). Having the text is wonderful, but it does > seems like a heretical act to be grepping through sources as Tex files; > when the original was in roff. >From the preface: The co-operation of the ``nroff'' program must also be mentioned. Without it, these notes could never have been produced in this form. However it has yielded some of its more enigmatic secrets so reluctantly, that the author's gratitude is indeed mixed. :-) At any rate use of the CM fonts is a bit jarring. Everyone who downloaded these sources for grepping has bought a paper copy of the Lions book, right? From imp at bsdimp.com Thu Jan 10 03:55:54 2019 From: imp at bsdimp.com (Warner Losh) Date: Wed, 9 Jan 2019 10:55:54 -0700 Subject: [TUHS] Lions book (not Origin of the name 'strategy' In-Reply-To: <20190109175007.662E5156E41B@mail.bitblocks.com> References: <20190109151243.71EA7156E410@mail.bitblocks.com> <20190109175007.662E5156E41B@mail.bitblocks.com> Message-ID: On Wed, Jan 9, 2019 at 10:50 AM Bakul Shah wrote: > On Wed, 09 Jan 2019 11:20:28 -0500 Clem Cole wrote: > > > > Ditto, (actually I have three -- two copies of the new one to show some > of > > the younger engineers at work). Having the text is wonderful, but it does > > seems like a heretical act to be grepping through sources as Tex files; > > when the original was in roff. > > From the preface: > The co-operation of the ``nroff'' program > must also be mentioned. Without it, > these notes could never have been produced in this form. However it has > yielded some of its more enigmatic > secrets so reluctantly, that the > author's gratitude is indeed mixed. > > :-) > > At any rate use of the CM fonts is a bit jarring. > > Everyone who downloaded these sources for grepping has bought > a paper copy of the Lions book, right? > Yea. But the github version doesn't have the 'appendix' that the Amazon version has with the listing with the line numbers as corresponding to the book... :( Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From bch at online.de Thu Jan 10 05:13:19 2019 From: bch at online.de (Christian Barthel) Date: Wed, 09 Jan 2019 20:13:19 +0100 Subject: [TUHS] TUHS Digest, Vol 38, Issue 10 In-Reply-To: (Warner Losh's message of "Tue, 8 Jan 2019 21:23:54 -0700") References: <966501A7-7736-4EB0-841A-C1516C876272@quintile.net> Message-ID: <875zux8x0w.fsf@x230.onfire.org> Warner Losh writes: > The name seems obvious because I've seen it for the last 30 years. But I've > not seen it used elsewhere, nor have I seen it documented except in > relationship to Unix. [....] It is also used by Erich Gamma's famous book "Design Pattern": The Strategy Pattern. Is it somehow related to Unix (due to the reason that the Unix device interface is designed in an object oriented fashion)? Apart from that, U. Vahalia describes the strategy entry point in the book "UNIX Internals: The new Frontiers" (ISBN 978-0131019089) as: | d_strategy() - Common point for read and write requests to a block | device. So named since the driver may use some strategy to reorder | pending requests to optimize performance. Operates asynchronously - if | the device is busy, the routine merely queues the request and returns. | When the I/O completes, the interrupt handler will dequeue the next | request and start the next I/O. -- Christian Barthel From clemc at ccc.com Thu Jan 10 06:51:48 2019 From: clemc at ccc.com (Clem Cole) Date: Wed, 9 Jan 2019 15:51:48 -0500 Subject: [TUHS] Origin of the name 'strategy' In-Reply-To: References: Message-ID: below.... On Mon, Jan 7, 2019 at 4:22 PM Warner Losh wrote: > So what's the origin of the name 'strategy' for the I/O routine in Unix > that drivers provide? Everything I've found in the early papers just says > that's what the routine is called. Is there a story behind why it was > chosen? My own theory is that it's in the sense of 'coping strategy' when > the driver needs to service more I/O for the upper layers, but that's just > a WAG. > FWIW: Warren has a scan of the 1976 USG document: "UNIX Program Description" Program Generic PG-1C300 Issue 2 >From the section called: BIO01 - Block I/O, on the 5th page I think there seems to be a hint of why it was called strategy. Under the description of the breada routine are the words: *Read ahead is a technique whereby an attempt is made to anticipate where the next read request on a device will be and to preread that data. In this manner, the program requesting the read will not be subjected to positional and rotational latency or device queuing, if read ahead is completed before the next block is requested. There are different strategies that can be used for-doing read ahead. On UNIX, all reads (not including physical I/O) result in a full 512 byte block being read from· the device. Smaller amounts of data could be read if a program requested it, however, since disks transfer times are small in comparison to positional and rotational latency times, any extra transfer is inconsequential. Also, most DEC disks are designed around a 512 byte sector and while fewer than 512 bytes may be specified, the disk controller is busy until a full sector has been transferred. By reading the full 512 bytes, any subsequent read or write which references data within that block will not have to be lead (if the block does not leave the system). Besides the advantage gained by reading a minimum of 512 bytes instead of the desired quantities, the next block is anticipated and read under certain conditions. Thus, one request will spawn several read requests to bring data into the system. A routine for finding a block that is already in memory (bio.c/incore) must be available to determine whether any reads need be done and the read ahead strategy must be capable of determining when read ahead should be discontinued so that superfluous reads are not generated.* *The strategy adopted under UNIX is to pursue read ahead as long as a process is reading (512 byte blocks) sequentially through a file or a device. When the first non sequential read is requested, read ahead is discontinued and is not restarted until sequential accesses begin again. * *Bio.c/breada carries out the read ahead operation. Starting and stopping read ahead and determining which block number in a file or on a device is the read ahead block ("rablkno") is done by the higher level function rdwri.c/readi. * *In implementing the read ahead strategy, bio.c/breada makes use of bio.c/incore to determine whether a block is already in memory. For the desired block "blkno", the bio.c/breada function behaves exactly like bio.c/bread. That is, a synchronous read is performed and the process requesting the read is roadblocked until it is completed. Since the desired block may already be within system. bio.c/incore is called to look for that block among the buffers on the freelist (bfreelist"). If the block is already in memory. bio.c/bread is called to get the buffer. If the desired biock has not already been read by a previous read operation then bio.c/getblk is called to see if the block is possibly on a device queue waiting for its turn to be read. If that is not the case, a buffer is allocated for the read and the appropriate device strategy routine is called. * *Bio.c/breada does not wait (yet) for the read to complete. Rather, it goes through a similar operation for the read ahead block "rablkno". Bio.c/incore is called to search the free list of buffers ("bfreelist") to see if the block was read in a previous read operation. Nothing will be done, of course, if the read ahead block is in memory. If it is not in memory, bio.c/getblk is called to search the device queue for it or to allocate a block so that it may be read. The device strategy module is called to read the read ahead block, however, the buffer will be marked (B_ASYNC in "b_flags") so that when the read completes the buffer is returned to the pool of available buffers. Bio.c/breada then waits for the read of the the desired block to complete. It does not wait for the read ahead block . * *An external variable "raflg" is available for turning off all read ahead on alldevices. "Raflg" is initialized to one, however, by changing it to zero read ahead is eliminated. As with bio.c/bread any error detection is done as a result of the interrupt handler indicating an error to bio.c/lncore and a system error (in "u_error") being posted. These errors are of no concern to bio.c/breada or bio.c/bread and are used only at higher levels of software to return errors to the user. * ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Thu Jan 10 08:24:37 2019 From: dave at horsfall.org (Dave Horsfall) Date: Thu, 10 Jan 2019 09:24:37 +1100 (EST) Subject: [TUHS] Lions book (not Origin of the name 'strategy' In-Reply-To: <20190109151243.71EA7156E410@mail.bitblocks.com> References: <20190109151243.71EA7156E410@mail.bitblocks.com> Message-ID: On Wed, 9 Jan 2019, Bakul Shah wrote: >> I no longer have my Lions books on me, sadly enough (lost in a house move) >> but there certainly were some peculiar names in the kernel... > > https://github.com/kanner/lions-book Wow - many thanks! The most photocopied book in the world, as I recall... -- Dave From dave at horsfall.org Thu Jan 10 08:53:54 2019 From: dave at horsfall.org (Dave Horsfall) Date: Thu, 10 Jan 2019 09:53:54 +1100 (EST) Subject: [TUHS] Lions book (not Origin of the name 'strategy' In-Reply-To: References: <20190109151243.71EA7156E410@mail.bitblocks.com> Message-ID: Silly idea: is there any way that the original books (red and orange) can be legally reprinted somehow? Surely the original nroff sources must be somewhere... Yeah, I know about the Copyright Act, but permission from his estate? -- Dave From dave at horsfall.org Thu Jan 10 09:30:07 2019 From: dave at horsfall.org (Dave Horsfall) Date: Thu, 10 Jan 2019 10:30:07 +1100 (EST) Subject: [TUHS] Origin of the name 'strategy' In-Reply-To: References: Message-ID: Is it just me, or do others here also think of bread() when writing "bread" on a shopping list? I've been using Unix since it first appeared in Australia, so I guess I'm now permanently damaged :-) Then again, during a late-night session at work getting a pair of Telebit NetBlazers to work, $BOSS asked me to order a pizza for us, so I picked up the phone and started dialling an IP address... And according to aus.net (I think) I was not the only one to do that :-) Oh, and I got to stay overnight in a nearby motel on his sixpence, because I was simply too buggered to make the 70km drive back home... -- Dave From ca6c at bitmessage.ch Thu Jan 10 09:09:54 2019 From: ca6c at bitmessage.ch (=?UTF-8?Q?C=C3=A1g?=) Date: Wed, 09 Jan 2019 17:09:54 -0600 Subject: [TUHS] Lions book (not Origin of the name 'strategy' In-Reply-To: <20190109151243.71EA7156E410@mail.bitblocks.com> References: <20190109151243.71EA7156E410@mail.bitblocks.com> Message-ID: <50b7d5e86dd89af2ab328f4038cb6ede@bitmessage.ch> Bakul Shah wrote: >> I no longer have my Lions books on me, sadly enough (lost in a house >> move) >> but there certainly were some peculiar names in the kernel... > https://github.com/kanner/lions-book Something to be printed and read once again. I remember I had a couple of handmade copies of bwk's C tutorial from '74, printed from the converted to LaTeX documents... -- caóc From dave at horsfall.org Thu Jan 10 10:19:05 2019 From: dave at horsfall.org (Dave Horsfall) Date: Thu, 10 Jan 2019 11:19:05 +1100 (EST) Subject: [TUHS] Knuth and Unix Message-ID: Time for a new thread :-) As today is Knuth's birthday (posted over in COFF), I was wondering (in the cesspool that is my mind) how much of Unix would have been influenced by Knuth? We have qsort() of course (which Hoare actually wrote, based on one of Knuth's algorithms), but I'm guessing that Ken and Dennis would have been familiar with his work? Or am I spreading fake news again? :-) Look, I love being corrected if I make a mistake on a technical mailing list, so fire at will if need be... -- Dave From ecashin at noserose.net Thu Jan 10 10:54:43 2019 From: ecashin at noserose.net (Ed Cashin) Date: Wed, 9 Jan 2019 19:54:43 -0500 Subject: [TUHS] Knuth and Unix In-Reply-To: References: Message-ID: Knuth is great, and I too am interested to know about his influence on UNIX, but Hoare is credited with the quicksort algorithm by the authorities I've encountered. (A little Googling suggests I'm not misremembering.) On Wed, Jan 9, 2019 at 7:19 PM Dave Horsfall wrote: > > Time for a new thread :-) > > As today is Knuth's birthday (posted over in COFF), I was wondering (in > the cesspool that is my mind) how much of Unix would have been influenced > by Knuth? We have qsort() of course (which Hoare actually wrote, based on > one of Knuth's algorithms), but I'm guessing that Ken and Dennis would > have been familiar with his work? > > Or am I spreading fake news again? :-) Look, I love being corrected if I > make a mistake on a technical mailing list, so fire at will if need be... > > -- Dave -- Ed Cashin From jcapp at anteil.com Thu Jan 10 13:14:12 2019 From: jcapp at anteil.com (Jim Capp) Date: Wed, 9 Jan 2019 22:14:12 -0500 (EST) Subject: [TUHS] Knuth and Unix In-Reply-To: Message-ID: <3692663.5421.1547090052538.JavaMail.root@zimbraanteil> I learned about Knuth from reading Unix man pages. I was intrigued enough to purchase his 3 volume set "Art of Computer Programming". From: "Dave Horsfall" To: "The Eunuchs Hysterical Society" Sent: Wednesday, January 9, 2019 7:19:05 PM Subject: [TUHS] Knuth and Unix Time for a new thread :-) As today is Knuth's birthday (posted over in COFF), I was wondering (in the cesspool that is my mind) how much of Unix would have been influenced by Knuth? We have qsort() of course (which Hoare actually wrote, based on one of Knuth's algorithms), but I'm guessing that Ken and Dennis would have been familiar with his work? Or am I spreading fake news again? :-) Look, I love being corrected if I make a mistake on a technical mailing list, so fire at will if need be... -- Dave -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnold at skeeve.com Thu Jan 10 17:39:28 2019 From: arnold at skeeve.com (arnold at skeeve.com) Date: Thu, 10 Jan 2019 00:39:28 -0700 Subject: [TUHS] Knuth and Unix In-Reply-To: References: Message-ID: <201901100739.x0A7dSfJ012307@freefriends.org> Ed Cashin wrote: > Knuth is great, and I too am interested to know about his influence on > UNIX, but Hoare is credited with the quicksort algorithm by the > authorities I've encountered. Hoare did indeed invent it. He describes the history, IIRC, in his Turing Award lecture. (I know I read it, written by him, somewhere.) Arnold From pnr at planet.nl Fri Jan 11 09:12:29 2019 From: pnr at planet.nl (Paul Ruizendaal) Date: Fri, 11 Jan 2019 00:12:29 +0100 Subject: [TUHS] V6 networking & alarm syscall Message-ID: <39F862F7-7C4B-4A09-B838-942BE0FD2626@planet.nl> I'm still happily experimenting with my combination of a V6 kernel with the 1981 tcp/ip stack from BBN, for example figuring out how one would write something like 'ping' using that API. That brought me to pondering the origins of the 'alarm()' sys call and how some things were done on the Spider network. These are my observations: 1. First of all: I understand that early Unix version numbers and dates mostly refer to the manual editions, and that core users had more frequent snapshots of a constantly evolving code base. 2. If I read the TUHS archive correctly, alarm() apparently did not exist in the original V6 edition of mid-1975. On the same basis, it was definitely there by the time of the V7 edition of early '79 (with sleep() removed) - so alarm() would seem to have appeared somewhere in the '75-'78 time frame. 3. The network enhanced NCP Unix versions in the TUHS archive have alarm() appear next to sleep(). Although the surviving tapes date from '79, it would seem to suggest that alarm() may have originated in the earlier part of the '75-'78 time frame. 4. The Spider network file store program 'nfs' (source here: http://chiselapp.com/user/pnr/repository/Spider/dir?mtime=0&type=flat&udc=1&ci=tip) uses idioms like the below to avoid getting hung on a dead server/network: signal(14,timeout); alarm(30); if((read(fn,rply,100)) < 0) trouble(); alarm(0); The 'nfs' program certainly was available in the 5th edition, maybe even in the 4th edition (the surviving 4th edition source code includes a Spider device driver). However, the surviving source for 'nfs' is from 1979 as well, so it may include later additions to the original design. 5. Replacing sleep() with alarm() and a user space library routine seems to have happened only some time after alarm() appeared, so it would seem that this was an optimization that alarm() enabled, and not its raison d'être. So here are some questions that the old hands may be able to shed some light on: - When/where did alarm() appear? Was network programming driving its inception? - Did Spider programs use a precursor to alarm() before that? (similar to V5 including 'snstat' in its libc - a precursor to ioctl). Paul From dave at horsfall.org Fri Jan 11 09:52:12 2019 From: dave at horsfall.org (Dave Horsfall) Date: Fri, 11 Jan 2019 10:52:12 +1100 (EST) Subject: [TUHS] Happy birthday, C.A.R. Hoare! Message-ID: [Not sure whether this is more appropriate for COFF instead, so it's here; advice (apart from STFU) gratefully accepted.) Sir Charles Antony Richard Hoare FRS FREng was born on this day in 1934; a computer pioneer (one of the greats) he gave us things like the quicksort algorithm (which became qsort() in Unix) and ALGOLW (a neat language). -- Dave From ksspiers at gmail.com Fri Jan 11 09:58:18 2019 From: ksspiers at gmail.com (Kyle Spiers) Date: Thu, 10 Jan 2019 15:58:18 -0800 Subject: [TUHS] Happy birthday, C.A.R. Hoare! In-Reply-To: References: Message-ID: Do you have these birthday posts in a google calendar I can add? On Thu, Jan 10, 2019, 15:52 Dave Horsfall wrote: > [Not sure whether this is more appropriate for COFF instead, so it's > here; advice (apart from STFU) gratefully accepted.) > > Sir Charles Antony Richard Hoare FRS FREng was born on this day in 1934; a > computer pioneer (one of the greats) he gave us things like the quicksort > algorithm (which became qsort() in Unix) and ALGOLW (a neat language). > > -- Dave > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Fri Jan 11 10:06:08 2019 From: clemc at ccc.com (Clem cole) Date: Thu, 10 Jan 2019 19:06:08 -0500 Subject: [TUHS] Happy birthday, C.A.R. Hoare! In-Reply-To: References: Message-ID: Dave. The w in Algolw was Wirth. He was at Stanford at the time. It was written in PL/360 btw. The sources are googlable. FWIW Pascal was done a couple of years later with lessons learned from Algolw and reaction to Algol68. Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. > On Jan 10, 2019, at 6:52 PM, Dave Horsfall wrote: > > [Not sure whether this is more appropriate for COFF instead, so it's here; advice (apart from STFU) gratefully accepted.) > > Sir Charles Antony Richard Hoare FRS FREng was born on this day in 1934; a computer pioneer (one of the greats) he gave us things like the quicksort algorithm (which became qsort() in Unix) and ALGOLW (a neat language). > > -- Dave From clemc at ccc.com Fri Jan 11 10:17:37 2019 From: clemc at ccc.com (Clem cole) Date: Thu, 10 Jan 2019 19:17:37 -0500 Subject: [TUHS] V6 networking & alarm syscall In-Reply-To: <39F862F7-7C4B-4A09-B838-942BE0FD2626@planet.nl> References: <39F862F7-7C4B-4A09-B838-942BE0FD2626@planet.nl> Message-ID: <2E4B2C1E-16A8-4990-8F05-2C8D0A1CB66D@ccc.com> Paul. alarm was introduced as part of Unix/TS would become most of kernel for the V7 system As for networking driving it I can not say. But the need for alarm to be broken from sleep was there for many other types of programs particularly if there was an interactive component or you needed to deal with hw at the user level. Look at the ‘expect’ code in uucico (which would later begat the whole expect tool from NIST). Alarm was just easier to do that with than sleep. Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. > On Jan 10, 2019, at 6:12 PM, Paul Ruizendaal wrote: > > > I'm still happily experimenting with my combination of a V6 kernel with the 1981 tcp/ip stack from BBN, for example figuring out how one would write something like 'ping' using that API. That brought me to pondering the origins of the 'alarm()' sys call and how some things were done on the Spider network. > > These are my observations: > > 1. First of all: I understand that early Unix version numbers and dates mostly refer to the manual editions, and that core users had more frequent snapshots of a constantly evolving code base. > > 2. If I read the TUHS archive correctly, alarm() apparently did not exist in the original V6 edition of mid-1975. On the same basis, it was definitely there by the time of the V7 edition of early '79 (with sleep() removed) - so alarm() would seem to have appeared somewhere in the '75-'78 time frame. > > 3. The network enhanced NCP Unix versions in the TUHS archive have alarm() appear next to sleep(). Although the surviving tapes date from '79, it would seem to suggest that alarm() may have originated in the earlier part of the '75-'78 time frame. > > 4. The Spider network file store program 'nfs' (source here: http://chiselapp.com/user/pnr/repository/Spider/dir?mtime=0&type=flat&udc=1&ci=tip) uses idioms like the below to avoid getting hung on a dead server/network: > > signal(14,timeout); alarm(30); > if((read(fn,rply,100)) < 0) trouble(); > alarm(0); > > The 'nfs' program certainly was available in the 5th edition, maybe even in the 4th edition (the surviving 4th edition source code includes a Spider device driver). However, the surviving source for 'nfs' is from 1979 as well, so it may include later additions to the original design. > > 5. Replacing sleep() with alarm() and a user space library routine seems to have happened only some time after alarm() appeared, so it would seem that this was an optimization that alarm() enabled, and not its raison d'être. > > So here are some questions that the old hands may be able to shed some light on: > > - When/where did alarm() appear? Was network programming driving its inception? > > - Did Spider programs use a precursor to alarm() before that? (similar to V5 including 'snstat' in its libc - a precursor to ioctl). > > Paul > From paul at mcjones.org Fri Jan 11 14:29:17 2019 From: paul at mcjones.org (Paul McJones) Date: Thu, 10 Jan 2019 20:29:17 -0800 Subject: [TUHS] Happy birthday, C.A.R. Hoare! In-Reply-To: References: Message-ID: <920BC45C-B744-4DA9-9A27-28BFE3176424@mcjones.org> In the June 1966 CACM [1], Wirth and Hoare published "A contribution to the development of ALGOL”, which describes a language very similar to Algol W. In Wirth’s Turing Award lecture (published in the Feb 1985 CACM [2]) "From programming language design to computer construction”, he noted: “The Working Group assumed the task of proposing a successor and soon split into two camps. On one side were the ambitious who wanted to erect another milestone in language design, and, on the other, those who felt that time was pressing and that an adequately extended ALGOL 60 would be a productive endeavor. I belonged to this second party and submitted a proposal that lost the election. Thereafter, the proposal was improved with contributions from Tony Hoare (a member of the same group) and implemented on Stanford University's first IBM 360. The language later became known as ALGOL W and was used in several universities for teaching purposes.” In particular, Hoare’s work on “Record Handling” (see [3]) had a strong impact on Algol W and Wirth’s later languages. [1] http://doi.acm.org/10.1145/365696.3657022 [2] http://doi.acm.org/10.1145/2786.2789 [3] http://www.softwarepreservation.org/projects/ALGOL/standards/. > On Jan 10, 2019, at 7:06 PM, clemc at ccc.com wrote: > > From: Clem cole > > To: Dave Horsfall > > Cc: The Eunuchs Hysterical Society > > > Dave. The w in Algolw was Wirth. He was at Stanford at the time. It was written in PL/360 btw. The sources are googlable. FWIW Pascal was done a couple of years later with lessons learned from Algolw and reaction to Algol68. > > Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. > >> On Jan 10, 2019, at 6:52 PM, Dave Horsfall > wrote: >> >> [Not sure whether this is more appropriate for COFF instead, so it's here; advice (apart from STFU) gratefully accepted.) >> >> Sir Charles Antony Richard Hoare FRS FREng was born on this day in 1934; a computer pioneer (one of the greats) he gave us things like the quicksort algorithm (which became qsort() in Unix) and ALGOLW (a neat language). >> >> -- Dave > -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul at mcjones.org Fri Jan 11 14:32:43 2019 From: paul at mcjones.org (Paul McJones) Date: Thu, 10 Jan 2019 20:32:43 -0800 Subject: [TUHS] Happy birthday, C.A.R. Hoare! In-Reply-To: <920BC45C-B744-4DA9-9A27-28BFE3176424@mcjones.org> References: <920BC45C-B744-4DA9-9A27-28BFE3176424@mcjones.org> Message-ID: Reference [1] in my previous message should have been: https://doi.org/10.1145/365696.365702 > [1] http://doi.acm.org/10.1145/365696.3657022 > [2] http://doi.acm.org/10.1145/2786.2789 > [3] http://www.softwarepreservation.org/projects/ALGOL/standards/ . -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron at ronnatalie.com Sat Jan 12 01:33:26 2019 From: ron at ronnatalie.com (ron at ronnatalie.com) Date: Fri, 11 Jan 2019 10:33:26 -0500 Subject: [TUHS] V6 networking & alarm syscall In-Reply-To: <39F862F7-7C4B-4A09-B838-942BE0FD2626@planet.nl> References: <39F862F7-7C4B-4A09-B838-942BE0FD2626@planet.nl> Message-ID: <1581c01d4a9c2$ffed5340$ffc7f9c0$@ronnatalie.com> > > 1. First of all: I understand that early Unix version numbers and dates mostly > refer to the manual editions, and that core users had more frequent > snapshots of a constantly evolving code base. Eh? They primarily refer to the distributions (Research V6, V7, PWB, the various BSD tapes). I'm not sure what "core users" are referring to. Most of us had many versions as we hacked and merged the stock releasesx. As Clem mentions, V7 had alarm (but simulated sleep in user mode). PWB predated that slightly and had both sleep() and alarm() as system calls. This propagated through to System III and V. I suspect this all is the result of the philosophy of the guys responsible for those separate kernel developments rather than an evolution of one or the other. As he mentions, I'm fairly sure this has nothing to do with networking directly. Just too handy not to have. A bigger networking issue was select() (or the like). It used to be an interesting kludge of running two processes inorder to do simoultaneous read/write before that. From clemc at ccc.com Sat Jan 12 04:45:39 2019 From: clemc at ccc.com (Clem Cole) Date: Fri, 11 Jan 2019 13:45:39 -0500 Subject: [TUHS] V6 networking & alarm syscall In-Reply-To: <1581c01d4a9c2$ffed5340$ffc7f9c0$@ronnatalie.com> References: <39F862F7-7C4B-4A09-B838-942BE0FD2626@planet.nl> <1581c01d4a9c2$ffed5340$ffc7f9c0$@ronnatalie.com> Message-ID: On Fri, Jan 11, 2019 at 10:34 AM wrote: > A bigger networking issue was select() (or the like). It used to be an > interesting kludge of running two processes inorder to do simoultaneous > read/write before that. > Right and select(2) was created by Sam and wnj during the 4.2 development. I've forgotten which sub-version (it was in 4.1c, but it might have been in b or a before that). There was a lot of arguing at the time about it's need; the multiple process solution was considered more 'Unix-like.' I remember one time have a few beers in my apartment with Sam while watching a football game and arguing about its usefulness. Adding select(2) was an example of where CSRG was adding things to UNIX for the DARPA community. IIRC: previous PDP-10 system had something like it and of course VMS had qio() which did not block; some of the users at an advisors meeting had wanted some alaong. I also remember after it ws prototyped, some people complaining that with select(2) people would start to right code that looped and waste cycles. BTW: sure enough, about a year or two later, X-Windows appears with its keyboard/mouse loop. The argument on a workstation (personal computer) was it did not matter. The argument on a vax or other typeshared machine, was that the CPU was being wasted and any type polling loop in users space was a bad idea. FWIW: a few years later, System V (I think SRV3, but I've forgotten) introduced poll(2) as a reaction to BSD's select(2). [IMO: That was NIH if I ever saw it - similar but different because they could]. Clem ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From david at kdbarto.org Sat Jan 12 05:06:20 2019 From: david at kdbarto.org (David) Date: Fri, 11 Jan 2019 11:06:20 -0800 Subject: [TUHS] V6 networking & alarm syscall In-Reply-To: References: <39F862F7-7C4B-4A09-B838-942BE0FD2626@planet.nl> <1581c01d4a9c2$ffed5340$ffc7f9c0$@ronnatalie.com> Message-ID: > On Jan 11, 2019, at 10:45 AM, Clem Cole wrote: > FWIW: a few years later, System V (I think SRV3, but I've forgotten) introduced poll(2) as a reaction to BSD's select(2). [IMO: That was NIH if I ever saw it - similar but different because they could]. > > Clem > ᐧ I remember having to support software than was on both SVR4 and BSD and writing an API that would mask the difference between poll and select. I’ve seen it done many times sense. David -------------- next part -------------- An HTML attachment was scrubbed... URL: From reed at reedmedia.net Sat Jan 12 08:08:25 2019 From: reed at reedmedia.net (reed at reedmedia.net) Date: Fri, 11 Jan 2019 16:08:25 -0600 (CST) Subject: [TUHS] V6 networking & alarm syscall In-Reply-To: References: <39F862F7-7C4B-4A09-B838-942BE0FD2626@planet.nl> <1581c01d4a9c2$ffed5340$ffc7f9c0$@ronnatalie.com> Message-ID: On Fri, 11 Jan 2019, Clem Cole wrote: > Right and select(2) was created by Sam and wnj during the 4.2 development.? > I've forgotten which sub-version (it was in 4.1c, but it might have been in > b or a before that).? There was a lot of arguing at the time about it's need;? > the multiple process solution was considered more 'Unix-like.' ... I search through the SCCS code in 4.1c. There is a reference to it by name for 4.1a in syscalls.c (82/11/13) to answer your comment. "#38 -- 4.1a select", /* 38 = nosys */ The select system call was added in 81/02/07 with no comment. Commit history shows in 81/10/17: "cleanup (mpx removal, old tty removal, beginnings of select)" and in 81/10/11 "first boot with select()" which includes lots of changes like replace lots of tty code and use selwakeup(). But I don't see any of the select code itself until a new file kern_descrip.c was introduced in 82/07/15. Soon after the #38 select became obsoleted oselect and a new syscall number #93 was assigned. (In 4.2 the select code was in sys_generic.c.) Can someone tell me about SCCS behaviour when renaming/moving or deleting files? In particular, I think the select() code prior to 82/07/15 had different source filenames that no longer exist and the SCCS history was lost. Anyone else have ideas about this? I have noticed this with other SCCS spelunking where code was removed and then corresponding "s" files were missing -- but maybe that is just the way the systems that our current snapshots (McKusick discs) of this history were made from. Maybe sccs didn't checkout the history of deleted files by default (that is my guess). From web at loomcom.com Sat Jan 12 08:16:05 2019 From: web at loomcom.com (Seth Morabito) Date: Fri, 11 Jan 2019 17:16:05 -0500 Subject: [TUHS] AT&T / Teletype DMD 5620 Emulator In-Reply-To: References: <8736q8xhb0.fsf@loomcom.com> Message-ID: On Fri, Jan 4, 2019, at 10:05 PM, Noel Hunt wrote: > I may be wrong but I thought there was a version of 'pi' for debugging > code running on the Blit/Jerq. Does that run in the emulator? > Hello Noel, I'm actually not familiar with 'pi'. Thomas Cargill described a debugger called 'joff' that targed the MC68000 Blit in a 1985 paper titled "Implementation of the Blit Debugger", but as for the 5620, I'm not sure what existed. I will have a look through the TUHS archives to see if there's anything in the V10 dumps, perhaps. -Seth -- Seth Morabito Poulsbo, WA web at loomcom.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Sat Jan 12 08:18:53 2019 From: lm at mcvoy.com (Larry McVoy) Date: Fri, 11 Jan 2019 14:18:53 -0800 Subject: [TUHS] V6 networking & alarm syscall In-Reply-To: References: <39F862F7-7C4B-4A09-B838-942BE0FD2626@planet.nl> <1581c01d4a9c2$ffed5340$ffc7f9c0$@ronnatalie.com> Message-ID: <20190111221853.GB7733@mcvoy.com> On Fri, Jan 11, 2019 at 04:08:25PM -0600, reed at reedmedia.net wrote: > Can someone tell me about SCCS behaviour when renaming/moving or > deleting files? In particular, I think the select() code prior to > 82/07/15 had different source filenames that no longer exist and the > SCCS history was lost. Anyone else have ideas about this? I have > noticed this with other SCCS spelunking where code was removed and then > corresponding "s" files were missing -- but maybe that is just the way > the systems that our current snapshots (McKusick discs) of this history > were made from. Maybe sccs didn't checkout the history of deleted files > by default (that is my guess). Ah, SCCS is my jam (I rewrote it from scratch as part of BitKeeper). SCCS didn't know about renames, it was strictly checkin/checkout. BitKeeper added the concept of "inode" to SCCS though it was not an integer like an inode in Unix, it was what we called a "key" and it looked like user at host|pathname|time_t|SCCS_chksum|64bits_of_dev_random There was a key for each delta and the name of the file was an attribute of the delta just as the contents were. So internally we worked in keys but externally you used file names and it was trivial to see where the file had lived. Anyhoo, I digress, that's all BitKeeper, not SCCS. If you have the SCCS history somewhere where I can get it I might be able to find the file you want. Just point me at (I know I have that set somewhere but no idea where they are). -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From web at loomcom.com Sat Jan 12 08:20:31 2019 From: web at loomcom.com (Seth Morabito) Date: Fri, 11 Jan 2019 17:20:31 -0500 Subject: [TUHS] AT&T / Teletype DMD 5620 Emulator In-Reply-To: <201901090912.x099CITB027909@freefriends.org> References: <8736q8xhb0.fsf@loomcom.com> <201901090912.x099CITB027909@freefriends.org> Message-ID: On Wed, Jan 9, 2019, at 1:12 AM, arnold at skeeve.com wrote: > This is pretty cool. Can you post links for this and the 3B2 emulator? Hello Arnold, Absolutely, I'd be happy to. The 3B2 emulator is described in more detail here: - https://loomcom.com/3b2/emulator.html The DMD 5620 emulator is documented here: - https://loomcom.com/3b2/dmd5620_emulator.html > I had one for a few years at Georgia Tech and I *loved* the keyboard. > It was a huge productivity boost being able to have multiple windows. > > We used them connected to our Vax 11/780 with 4 Meg of memory running > 4.[12] BSD (don't remember which) and having multiple DMD 5620s > with multiple windows open on each drove the poor vax to its knees... I can imagine! The multiplexing code running on the host could get pretty expensive pretty fast, especially with multiple layers per terminal. -- Seth Morabito Poulsbo, WA web at loomcom.com From web at loomcom.com Sat Jan 12 08:26:23 2019 From: web at loomcom.com (Seth Morabito) Date: Fri, 11 Jan 2019 17:26:23 -0500 Subject: [TUHS] AT&T / Teletype DMD 5620 Emulator In-Reply-To: References: <8736q8xhb0.fsf@loomcom.com> Message-ID: On Wed, Jan 9, 2019, at 7:02 AM, Julius Schmidt wrote: > Neat! > > I wrote an emulator for the original 68K jerq/blit two years > ago. > > The original Plan 9 version is at > http://code.9front.org/hg/plan9front/file/tip/sys/src/games/blit > > A Javascript version is available at > http://blit.aiju.de/ Hello Julius, I am familiar with your work, I was very inspired by it. I'm really glad that the MC68000 Blit is so well emulated! I'd love to see a real Blit or jerq in person some day, but I don't even know where I'd find one (it looks like even the Computer History Museum in Mountain View, CA doesn't have a 68K Blit -- it only has a DMD 5620) All the best! > aiju -Seth -- Seth Morabito Poulsbo, WA web at loomcom.com From clemc at ccc.com Sat Jan 12 08:47:31 2019 From: clemc at ccc.com (Clem Cole) Date: Fri, 11 Jan 2019 17:47:31 -0500 Subject: [TUHS] V6 networking & alarm syscall In-Reply-To: References: <39F862F7-7C4B-4A09-B838-942BE0FD2626@planet.nl> <1581c01d4a9c2$ffed5340$ffc7f9c0$@ronnatalie.com> Message-ID: On Fri, Jan 11, 2019 at 5:09 PM wrote: > > The select system call was added in 81/02/07 with no comment. Commit > history shows in 81/10/17: "cleanup (mpx removal, old tty removal, > beginnings of select)" and in 81/10/11 "first boot with select()" which > includes lots of changes like replace lots of tty code and use > selwakeup(). Actually, that is a nice memory jog. Chesson wrote mpx(2) for DataKit for UNIX/TS. IIRC: It was not originally part of v7, but he sent copies of out to a number of folks. Somwhere I might even have the email when he sent it to me at CMU in the late 1970s. The point is that it was in the wild as it were at a lot of places; certainly at UCB by 4.1. Sam and Joy had seen and messed with mpx(2) before select(2) was concieved. To Paul's question - mpx(2) was done for networking. Clem ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at eric.allman.name Sat Jan 12 08:55:31 2019 From: tuhs at eric.allman.name (Eric Allman) Date: Fri, 11 Jan 2019 14:55:31 -0800 Subject: [TUHS] V6 networking & alarm syscall In-Reply-To: References: <39F862F7-7C4B-4A09-B838-942BE0FD2626@planet.nl> <1581c01d4a9c2$ffed5340$ffc7f9c0$@ronnatalie.com> Message-ID: On 2019-01-11 2:47 PM, Clem Cole wrote: > To Paul's question - mpx(2) was done for networking. Trivia point: I used mpx(2) for the very first implementation of syslog. eric From pnr at planet.nl Sat Jan 12 09:27:59 2019 From: pnr at planet.nl (Paul Ruizendaal) Date: Sat, 12 Jan 2019 00:27:59 +0100 Subject: [TUHS] V6 networking & alarm syscall Message-ID: <37D0F710-9705-497B-BC4B-51B6E1D5FA1C@planet.nl> Clem, Ron, Thanks for the explanations! Some comments below. >> 1. First of all: I understand that early Unix version numbers and dates >> mostly refer to the manual editions, and that core users had more >> frequent snapshots of a constantly evolving code base. > > Eh? They primarily refer to the distributions (Research V6, V7, PWB, the > various BSD tapes). > I'm not sure what "core users" are referring to. Most of us had many > versions as we hacked and merged the stock releasesx. I was too brief. I was referring just to the pre-V7 versions, and I had the implicit assumption that alarm() originated at the labs. My understanding was that the labels 5th, 6th and 7th edition had little meaning inside the labs, as there just was a continuously developing code base. Maybe this is a mis-understanding. > "alarm was introduced as part of Unix/TS" "PWB [..] had both sleep() and alarm() as system calls" Thanks for those pointers! I'm not sure I fully grasp the lineage of Unix/TS and PWB, but the TUHS wiki has a page about it: https://wiki.tuhs.org/doku.php?id=misc:snippets:mert1 From that, and from the TUHS Unix Tree web page I get that PWB1.0 from mid 1977 was probably the root source of alarm() for people outside AT&T. As PWB apparently got started much before that, it is possible that alarm() goes back much further as well. > A bigger networking issue was select() (or the like). It used to be an > interesting kludge of running two processes inorder to do simoultaneous > read/write before that. Yes: the NCP Unix team (Grossman/Holmgren/Bunch) also mentioned that as the big issue/annoyance that they ran into in 1975. As discussed in this list before, 3 years elapsed before Jack Haverty came up with await() for V6. I was told that there was a lot of discussion in the 4.1x/4.2 BSD steering group in 1981/2 whether this functionality should be stateful (like await) or stateless (like select). Looking at the implementations for both, I can see why stateless carried the day. > Right and select(2) was created by Sam and wnj during the 4.2 development. I've forgotten which sub-version (it was in 4.1c, but it might have been in b or a before that). There was a lot of arguing at the time about it's need; the multiple process solution was considered more 'Unix-like.' That is an interesting point, and it got me wondering about another related feature that could have been in Unix in the 1975-1980 time frame, being both useful and practical even on a 11/40 class machine, but for some reason wasn't: It would not seem terribly complex to add non-blocking i/o capability to V6. It could have been implemented as a TTY flag and it is not a big conceptual leap from EINTR to EAGAIN. Adding a 'capacity' field to the sgtty interface would not have been a big leap either. This would have allowed user processes to scan a number of tty lines e.g. once a second in a loop and do processing as needed. In NCP Unix this would not have been hard to extend to network pipes. The NCP Unix / Arpanet crowd certainly had a need for it, it would have been very useful for Spider/Datakit connections and probably for uucp as well. And from there it is not a million miles to replace the timed user loop with something like select(). Yet non-blocking I/O and select() only appear in 1982. Maybe in the 1975-1980 time frame this was not felt to be 'how Unix does it'? From imp at bsdimp.com Sat Jan 12 09:32:54 2019 From: imp at bsdimp.com (Warner Losh) Date: Fri, 11 Jan 2019 16:32:54 -0700 Subject: [TUHS] V6 networking & alarm syscall In-Reply-To: References: <39F862F7-7C4B-4A09-B838-942BE0FD2626@planet.nl> <1581c01d4a9c2$ffed5340$ffc7f9c0$@ronnatalie.com> Message-ID: On Fri, Jan 11, 2019 at 3:48 PM Clem Cole wrote: > > > On Fri, Jan 11, 2019 at 5:09 PM wrote: > >> >> The select system call was added in 81/02/07 with no comment. Commit >> history shows in 81/10/17: "cleanup (mpx removal, old tty removal, >> beginnings of select)" and in 81/10/11 "first boot with select()" which >> includes lots of changes like replace lots of tty code and use >> selwakeup(). > > > Actually, that is a nice memory jog. Chesson wrote mpx(2) for DataKit > for UNIX/TS. IIRC: It was not originally part of v7, but he sent copies > of out to a number of folks. Somwhere I might even have the email when > he sent it to me at CMU in the late 1970s. The point is that it was in > the wild as it were at a lot of places; certainly at UCB by 4.1. Sam and > Joy had seen and messed with mpx(2) before select(2) was concieved. > > To Paul's question - mpx(2) was done for networking. > How is that different than the pk driver that was in v7? Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnc at mercury.lcs.mit.edu Sat Jan 12 11:24:39 2019 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Fri, 11 Jan 2019 20:24:39 -0500 (EST) Subject: [TUHS] V6 networking & alarm syscall Message-ID: <20190112012439.7D56A18C073@mercury.lcs.mit.edu> > From: Paul Ruizendaal > It would not seem terribly complex to add non-blocking i/o capability to > V6. ... Adding a 'capacity' field to the sgtty interface would not > have been a big leap either. ... > Maybe in the 1975-1980 time frame this was not felt to be 'how Unix does > it'? This point interested me, so I went and had a look at how the MIT V6+/PWB TCP/IP did it. I looked at user TELNET, which should be pretty simple (server would probably be more complicated, due to PTY stuff). It's totally different - although that's in part because in the MIT system, TCP is in the user process, along with the application. In the user process, there's a common non-premptive 'tasking' package which both the TCP and TELNET code use. When there are no tasks ready to run, the process uses the sleep() system call to wait for a fixed, limited quantum (interrupts, i.e. signals, will usually wake it before the quantum runs out); note this comment: / uses the system sleep call rather than the standard C library / sleep (sleep (III)) because there is a critical race in the / C library implementation which could result in the process / pausing forever. This is a horrible bug in the UNIX process / control mechanism. Quoted without comment from me! There are 3 TCP tasks - send, receive and timer. The process receives an 'asynchronous I/O complete' signal when a packet arrives, and that wakes up the process, and then one of the tasks therein, to do packet processing (incoming data, acks, etc). There appears to be a single TELNET task, which reads from the user's keyboard, and sends data to the network. (It looks like processing of incoming data is handled in the context of one of the TCP tasks.) Its main loop starts with this: ioctl (0, FIONREAD, &nch); if (nch == 0) { tk_yield (); continue; } } if ((c = getchar()) == EOF) { so that ioctl() must look to see if there is any data waiting in the terminal input buffer (I'm too lazy to go see what FIONREAD does, right at the moment). Noel From dave at horsfall.org Sat Jan 12 11:58:28 2019 From: dave at horsfall.org (Dave Horsfall) Date: Sat, 12 Jan 2019 12:58:28 +1100 (EST) Subject: [TUHS] V6 networking & alarm syscall In-Reply-To: <20190112012439.7D56A18C073@mercury.lcs.mit.edu> References: <20190112012439.7D56A18C073@mercury.lcs.mit.edu> Message-ID: On Fri, 11 Jan 2019, Noel Chiappa wrote: [ ... ] > ioctl (0, FIONREAD, &nch); > if (nch == 0) { > tk_yield (); > continue; > } > } > if ((c = getchar()) == EOF) { > > so that ioctl() must look to see if there is any data waiting in the > terminal input buffer (I'm too lazy to go see what FIONREAD does, right > at the moment). As I dimly recall (because I'm too sick/lazy to look it up), it returns the number of characters in the input queue (at that time) so that you won't block (and time out, if you wrote it thus). It was quite useful, if you didn't like the horrible semantics of select(), or, for that matter, SysV poll() (?) which was only slightly better. Of course, FIONREAD wasn't always reliable, because by the time you got to using it the keyboard (l)user could have deleted some characters etc, and you *could* be left there hanging on a timeout (with signals, which for some reason I hate with a passion, as I've posted here before, as they are just too brutal). No doubt someone here will tell me that Plan9 did it right :-) I really must run it up some time, before I finally kark it (I'm in my late 60s). -- Dave From imp at bsdimp.com Sat Jan 12 12:33:10 2019 From: imp at bsdimp.com (Warner Losh) Date: Fri, 11 Jan 2019 19:33:10 -0700 Subject: [TUHS] V6 networking & alarm syscall In-Reply-To: References: <20190112012439.7D56A18C073@mercury.lcs.mit.edu> Message-ID: On Fri, Jan 11, 2019 at 6:59 PM Dave Horsfall wrote: > On Fri, 11 Jan 2019, Noel Chiappa wrote: > > [ ... ] > > > ioctl (0, FIONREAD, &nch); > > if (nch == 0) { > > tk_yield (); > > continue; > > } > > } > > if ((c = getchar()) == EOF) { > > > > so that ioctl() must look to see if there is any data waiting in the > > terminal input buffer (I'm too lazy to go see what FIONREAD does, right > > at the moment). > > As I dimly recall (because I'm too sick/lazy to look it up), it returns > the number of characters in the input queue (at that time) so that you > won't block (and time out, if you wrote it thus). > > It was quite useful, if you didn't like the horrible semantics of > select(), or, for that matter, SysV poll() (?) which was only slightly > better. > > Of course, FIONREAD wasn't always reliable, because by the time you got to > using it the keyboard (l)user could have deleted some characters etc, and > you *could* be left there hanging on a timeout (with signals, which for > some reason I hate with a passion, as I've posted here before, as they > are just too brutal). > This is why RAW mode was born, but then you're duplicating the kernel cooking code in your ap :( > No doubt someone here will tell me that Plan9 did it right :-) I really > must run it up some time, before I finally kark it (I'm in my late 60s). > No doubt... Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnc at mercury.lcs.mit.edu Sat Jan 12 14:14:01 2019 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Fri, 11 Jan 2019 23:14:01 -0500 (EST) Subject: [TUHS] V6 networking & alarm syscall Message-ID: <20190112041401.A672D18C073@mercury.lcs.mit.edu> > From: Dave Horsfall > As I dimly recall ... it returns the number of characters in the input > queue (at that time) Well, remember, this is the MIT V6 PDP-11 system, which had a tty driver which had been completely re-written at MIT years before, so you'd really have to check the MIT V6 sources to see exactly what it did. I suspect they borrowed the name, and basic semantics, from Berkeley, but everything else - who knows. This user telnet is from 1982 (originally), but I was looking at the final version, which is from 1984; the use of the ioctl was apparently a later addition. I haven't checked to see what it did originally for reading from the user's terminal (although the earlier version also used the 'tasking' package). Noel From pnr at planet.nl Sat Jan 12 21:13:24 2019 From: pnr at planet.nl (Paul Ruizendaal) Date: Sat, 12 Jan 2019 12:13:24 +0100 Subject: [TUHS] V6 networking & alarm syscall In-Reply-To: References: Message-ID: > / uses the system sleep call rather than the standard C library > / sleep (sleep (III)) because there is a critical race in the > / C library implementation which could result in the process > / pausing forever. This is a horrible bug in the UNIX process > / control mechanism. > > Quoted without comment from me! Intriguing comment. I think your v6+ system probably has a lot of PWB stuff in there. The libc source for sleep() in stock V6 is: .globl _sleep sleep = 35. _sleep: mov r5,-(sp) mov sp,r5 mov 4(r5),r0 sys sleep mov (sp)+,r5 rts pc The PWB version uses something alarm/pause based, but apparently gets it wrong: .globl _sleep alarm = 27. pause = 29. rti = 2 _sleep: mov r5,-(sp) mov sp,r5 sys signal; 14.; 1f mov 4(r5),r0 sys alarm sys pause clr r0 sys alarm mov (sp)+,r5 rts pc 1: rti I think the race occurs when an interrupt arrives between the sys alarm and the sys pause lines, and the handler calls sleep again. sleep() in the V7 libc is a much more elaborate C routine. When I first read the race condition comment, I thought the issue would be like that of write: _write: mov r5,-(sp) mov sp,r5 mov 4(r5),r0 mov 6(r5),0f mov 8(r5),0f+2 sys 0; 9f bec 1f jmp cerror 1: mov (sp)+,r5 rts pc .data 9: sys write; 0:..; .. This pattern appears in several V6 sys call routines, and would not be safe when used in a context with signal based multi- threading. From reed at reedmedia.net Sat Jan 12 22:04:27 2019 From: reed at reedmedia.net (reed at reedmedia.net) Date: Sat, 12 Jan 2019 06:04:27 -0600 (CST) Subject: [TUHS] V6 networking & alarm syscall In-Reply-To: <20190111221853.GB7733@mcvoy.com> References: <39F862F7-7C4B-4A09-B838-942BE0FD2626@planet.nl> <1581c01d4a9c2$ffed5340$ffc7f9c0$@ronnatalie.com> <20190111221853.GB7733@mcvoy.com> Message-ID: On Fri, 11 Jan 2019, Larry McVoy wrote: > On Fri, Jan 11, 2019 at 04:08:25PM -0600, reed at reedmedia.net wrote: > > Can someone tell me about SCCS behaviour when renaming/moving or > > deleting files? ... > SCCS didn't know about renames, it was strictly checkin/checkout. ... > Anyhoo, I digress, that's all BitKeeper, not SCCS. If you have > the SCCS history somewhere where I can get it I might be able to > find the file you want. Just point me at (I know I have that > set somewhere but no idea where they are). I was surprised that I didn't see the files at the TUHS archives. I put the SCCS and s. files into http://reedmedia.net/~reed/tmp/4.1c1-sccs.tar.gz 1.4MB 408 files I was looking for the early select() code from ~1981. The earliest I found was kern_descrip.c from 82/07/15. I think the original source file got deleted or the file was renamed and lost its history (and the original SCCS s. file was lost). Thanks From clemc at ccc.com Sun Jan 13 03:20:46 2019 From: clemc at ccc.com (Clem Cole) Date: Sat, 12 Jan 2019 12:20:46 -0500 Subject: [TUHS] V6 networking & alarm syscall In-Reply-To: References: <39F862F7-7C4B-4A09-B838-942BE0FD2626@planet.nl> <1581c01d4a9c2$ffed5340$ffc7f9c0$@ronnatalie.com> <20190111221853.GB7733@mcvoy.com> Message-ID: Paul, I can date it a little I suspect, although not as precisely as you might like. I arrived at UCB in late August/Early September '81 to be a grad student. Sam had arrived earlier that spring to work for wnj in the CSRG team. I had known Sam before I went to UCB. [We actually had played rugby against each other in eastern PA many years before he went off to Case and me to CMU]. Anyway, when I arrived Sam was one of the people I already knew and we socialized a lot together in that fall in particular. We also know the first 'Alpha' kit of 4.1a was not a thing until the next summer. Plus, during the winter was the arguments with ARPA steering committee about the features that needed to be added. The key item is that vestigial select(2) does not show up until at least 6-9 months after I arrived and it seems like it was part of 4.1a. As I said, I have memories of discussing all of the networking interfaces, CMU Accent, et al with Sam in particular during that time. So, I would bet Joy did the basic work winter/spring of 82; but I can not be more precise than that. FWIW: Since I had been working networking at both CMU and Tek before I came to UCB, one of the first things I did when I arrived in fall '81 was to install the Gurwitz BBN IP/TCP stack on 4.1 so we could run Ethernet between the 3 CAD machines in Cory Hall to replace the use of BerkNet over 9600 baud serial links (IIRC Eric Cooper, was involved with that hack also). When I had arrived, few machines at UCB were on LANS and the need for ARPAnet style networking >>besides<< email was still limited. The way people connected to systems was their terminal was to connect over serial links and we had a giant 'plugboard' that allowed you patch your terminal into one of the systems [I wonder if there are pictures of these somewhere in the UCB archives - it was quite something]. We had three 780s in the CAD group in Cory and really did not like the plugboard scheme. From my previous experience, I wanted something like telnet or supdup, like we had been messing with at CMU and Tek. Hence my push to put the BBN code on the CAD systems and use an ethernet. Eric, please fill me in. You must have been running the BBN code then also, since Ing70 and then IngVax were the ArpaNet connection (via a VHDH to the LBL IMP - UCB did not yet have its own IMP). But I know the CAD systems 4.1 networking stuff was done by me. Its a little fuzzy now, but memory is that Bob Kriddle had run a Xerox 3 Meg cable in Cory, from my machine room over to the Ingres machine room also; but I've forgotten the details. BerkNet (i.e. serial links) allowed email to flow on campus, but I'm thinking we were trying to make that both more efficient and allow telnet/ftp [which might not have happened until after the C/30 IMP was installed in Evan later). [Since all ARPAnet email followed through IngVax, Eric's history of dealing with the header file format of the month in the old delivermail program would force his writing sendmail - said history has been repeated here and elsewhere previously]. But this thread got me thinking a little bit. I've forgotten actual LAN topology we had a UCB now. I know from the CAD hosts, we could talk to the other hosts in our lab in Cory for sure, I want to say we could talk to a few other hosts in Evans and Cory; as I know Sam would give me code usually via some type of network connection, although sneaker-net with 9-track tapes used a great deal too. I want to say the connection was over Kriddle's 3M Xerox cable (Eric do you remember what you had in IngVax in those days). I know we also a had real 10Meg cable in floor our lab in Cory, plus at least one Xerox board on one of the systems, another had a DEC interface in it, and Interlan boards in at least two others another. We must have even had a 3Com board in the third system; as I remember hacking both the Interlan and 3Com drivers (I had written a 3Com driver at Tek previous for VMS. The Interlan board was new, as was the DEC board; but I've forgotten what we got when). The original CAD 780 ('Coke') must have had multiple interfaces in it, but I really don't remember. FWIW: I spent a good bit of time with Sam in those days. CSRG was using 750s for most of their development, and the couple of 780's in Evan's had a lot of non-DEC equipment in them. But we had the one large undoctored and max configuration VAX 785 ('Pepsi'), that was fully tricked out with a real DEC I/O equipment in it† So when CRSG (*i.e.* Sam) wanted to test things on a 'pure DEC' system with things like TU78's, real RP07's, RMxx drives; he would give me something and I would debug it late at night on it. Once it was stable, it might become the system we ran. While I can not date select(2) more precisely. I can date routed(2) as being that spring, but after 4.1a's alpha code. Sam has seen the Xerox routed system at PARC. The BBN code was a not friendly to sub-nets and we had already started to proliferate them between Evans and Cory Hall. He decided to create something like the Xerox code for us (as well as the r* commands). routed was created in a couple of weeks after Sam got the idea from Xerox and first place it ran was on the 10 Meg LAN in the CAD group. Hope this helps, Clem † That specific system ('Pepsi') had been used as a demo machine for DEC at Summer Comdex. It was the famous "forklift'' system and we actually had in a back room the panel with the forklift holes. It had been donated by Al Hanover of DEC's CAD team to the UCB CAD group; after Prof. Rich Newton had convinced >>HP<< to fund the purchasing of an earlier 780 for us [this is all a different story]. Also, that system had the big 64-bit array processor I was working on for my thesis too; because it was the only system we had with enough I/O bandwidth to support it. ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at eric.allman.name Sun Jan 13 04:16:02 2019 From: tuhs at eric.allman.name (Eric Allman) Date: Sat, 12 Jan 2019 10:16:02 -0800 Subject: [TUHS] V6 networking & alarm syscall In-Reply-To: References: <39F862F7-7C4B-4A09-B838-942BE0FD2626@planet.nl> <1581c01d4a9c2$ffed5340$ffc7f9c0$@ronnatalie.com> <20190111221853.GB7733@mcvoy.com> Message-ID: <054ff0fa-2581-89a7-3bbd-5fe95affa8ea@neophilic.com> > Eric, please fill me in. I have to admit that my memories are a bit fuzzy, but I'll try to fill in what I can. On 2019-01-12 9:20 AM, Clem Cole wrote: ... > FWIW: Since I had been working networking at both CMU and Tek before I > came to UCB, one of the first things I did when I arrived in fall '81 > was to install the Gurwitz BBN IP/TCP stack on 4.1 so we could run > Ethernet between the 3 CAD machines in Cory Hall to replace the use of > BerkNet over 9600 baud serial links (IIRC Eric Cooper, was involved with > that hack also).   When I had arrived, few machines at UCB were on LANS > and the need for ARPAnet style networking >>besides<< email was still > limited.  The way people connected to systems was their terminal was to > connect over serial links and we had a giant 'plugboard' that allowed > you patch your terminal into one of the systems [I wonder if there are > pictures of these somewhere in the UCB archives - it was quite something]. That it was. When the INGRES group got our ARPAnet connection (VDH to LBL, as you mentioned) it was the only long-haul connection to campus that I know of. Eric Schmidt had done BerkNET, but that was local mail and file copy only, and BerkNET mail didn't connect to ARPAnet mail, so there were "plugboard wars" over who got one of the two RS232 connections we had available for outside users (this was out of a grand total of 16 connections on a DH-11, each at about $1000/port, iirc). I was nominally responsible for the ARPAnet connection, so I had senior faculty on my case about how they all "needed" dedicated connections to their office (but of course they didn't want to pay for them). This was the original inspiration for delivermail, which later became sendmail. > We had three 780s in the CAD group in Cory and really did not like the > plugboard scheme. From my previous experience, I wanted something like > telnet or supdup, like we had been messing with at CMU and Tek.  Hence > my push to put the BBN code on the CAD systems and use an ethernet.    > Eric, please fill me in.   You must have been running the BBN code then > also, since Ing70 and then IngVax were the ArpaNet connection (via > a VHDH to the LBL IMP - UCB did not yet have its own IMP).   But I know > the CAD systems 4.1 networking stuff was done by me. As I recall IngVax never had any ARPAnet service, and Ing70 was running the NCP code from San Diego, which could well have originated at BB&N, but I can't confirm that from memory. Conversely, Ing70 was never on any "modern" networking technology such as 3Mbit ethernet (I don't think there were even NICs at that time). > Its a little fuzzy now, but memory is that Bob Kriddle had run a Xerox 3 > Meg cable in Cory, from my machine room over to the Ingres machine room > also; but I've forgotten the details.  BerkNet (i.e. serial links) > allowed email to flow on campus, but I'm thinking we were trying to make > that both more efficient and allow telnet/ftp [which might not have > happened until after the C/30 IMP was installed in Evan later).   [Since > all ARPAnet email followed through IngVax, Eric's history of dealing > with the header file format of the month in the old delivermail program > would force his writing sendmail - said history has been repeated here > and elsewhere previously]. Yes, modulo it being Ing70, not IngVax. > But this thread got me thinking a little bit.   I've forgotten actual > LAN topology we had a UCB now. I know from the CAD hosts, we could talk > to the other hosts in our lab in Cory for sure, I want to say we could > talk to a few other hosts in Evans and Cory; as I know Sam would give me > code usually via some type of network connection, although sneaker-net > with 9-track tapes used a great deal too.   I want to say the connection > was over Kriddle's 3M Xerox cable (Eric do you remember what you had in > IngVax in those days).  I know we also a had real 10Meg cable in floor > our lab in Cory, plus at least one Xerox board on one of the systems, > another had a DEC interface in it, and Interlan boards in at least two > others another.   We must have even had a 3Com board in the third > system; as I remember hacking both the Interlan and 3Com drivers (I had > written a 3Com driver at Tek previous for VMS.  The Interlan board was > new, as was the DEC board; but I've forgotten what we got when).     The > original CAD 780 ('Coke')  must have had multiple interfaces in it, but > I really don't remember. You would think I would remember more of the network situation around the INGRES project given that we had someone working on distributed databases (Ken Birman, now at Cornell I think, did something called COCANET). However, I have no recollection at all about what the connection actually was. It might be possible to pull some of Ken's old papers (late 70s/early 80s) and get more information there. eric From b4 at gewt.net Sun Jan 13 11:16:32 2019 From: b4 at gewt.net (Madeline Autumn-Rose) Date: Sat, 12 Jan 2019 17:16:32 -0800 Subject: [TUHS] V6 networking & alarm syscall In-Reply-To: <054ff0fa-2581-89a7-3bbd-5fe95affa8ea@neophilic.com> References: <39F862F7-7C4B-4A09-B838-942BE0FD2626@planet.nl> <1581c01d4a9c2$ffed5340$ffc7f9c0$@ronnatalie.com> <20190111221853.GB7733@mcvoy.com> <054ff0fa-2581-89a7-3bbd-5fe95affa8ea@neophilic.com> Message-ID: Where did you find the BBN TCP/IP stack? Sent from my iPhone On Jan 12, 2019, at 10:16, Eric Allman wrote: >> Eric, please fill me in. > > I have to admit that my memories are a bit fuzzy, but I'll try to fill > in what I can. > >> On 2019-01-12 9:20 AM, Clem Cole wrote: >> ... >> FWIW: Since I had been working networking at both CMU and Tek before I >> came to UCB, one of the first things I did when I arrived in fall '81 >> was to install the Gurwitz BBN IP/TCP stack on 4.1 so we could run >> Ethernet between the 3 CAD machines in Cory Hall to replace the use of >> BerkNet over 9600 baud serial links (IIRC Eric Cooper, was involved with >> that hack also). When I had arrived, few machines at UCB were on LANS >> and the need for ARPAnet style networking >>besides<< email was still >> limited. The way people connected to systems was their terminal was to >> connect over serial links and we had a giant 'plugboard' that allowed >> you patch your terminal into one of the systems [I wonder if there are >> pictures of these somewhere in the UCB archives - it was quite something]. > > That it was. When the INGRES group got our ARPAnet connection (VDH to > LBL, as you mentioned) it was the only long-haul connection to campus > that I know of. Eric Schmidt had done BerkNET, but that was local mail > and file copy only, and BerkNET mail didn't connect to ARPAnet mail, so > there were "plugboard wars" over who got one of the two RS232 > connections we had available for outside users (this was out of a grand > total of 16 connections on a DH-11, each at about $1000/port, iirc). I > was nominally responsible for the ARPAnet connection, so I had senior > faculty on my case about how they all "needed" dedicated connections to > their office (but of course they didn't want to pay for them). This was > the original inspiration for delivermail, which later became sendmail. > >> We had three 780s in the CAD group in Cory and really did not like the >> plugboard scheme. From my previous experience, I wanted something like >> telnet or supdup, like we had been messing with at CMU and Tek. Hence >> my push to put the BBN code on the CAD systems and use an ethernet. >> Eric, please fill me in. You must have been running the BBN code then >> also, since Ing70 and then IngVax were the ArpaNet connection (via >> a VHDH to the LBL IMP - UCB did not yet have its own IMP). But I know >> the CAD systems 4.1 networking stuff was done by me. > > As I recall IngVax never had any ARPAnet service, and Ing70 was running > the NCP code from San Diego, which could well have originated at BB&N, > but I can't confirm that from memory. Conversely, Ing70 was never on > any "modern" networking technology such as 3Mbit ethernet (I don't think > there were even NICs at that time). > >> Its a little fuzzy now, but memory is that Bob Kriddle had run a Xerox 3 >> Meg cable in Cory, from my machine room over to the Ingres machine room >> also; but I've forgotten the details. BerkNet (i.e. serial links) >> allowed email to flow on campus, but I'm thinking we were trying to make >> that both more efficient and allow telnet/ftp [which might not have >> happened until after the C/30 IMP was installed in Evan later). [Since >> all ARPAnet email followed through IngVax, Eric's history of dealing >> with the header file format of the month in the old delivermail program >> would force his writing sendmail - said history has been repeated here >> and elsewhere previously]. > > Yes, modulo it being Ing70, not IngVax. > >> But this thread got me thinking a little bit. I've forgotten actual >> LAN topology we had a UCB now. I know from the CAD hosts, we could talk >> to the other hosts in our lab in Cory for sure, I want to say we could >> talk to a few other hosts in Evans and Cory; as I know Sam would give me >> code usually via some type of network connection, although sneaker-net >> with 9-track tapes used a great deal too. I want to say the connection >> was over Kriddle's 3M Xerox cable (Eric do you remember what you had in >> IngVax in those days). I know we also a had real 10Meg cable in floor >> our lab in Cory, plus at least one Xerox board on one of the systems, >> another had a DEC interface in it, and Interlan boards in at least two >> others another. We must have even had a 3Com board in the third >> system; as I remember hacking both the Interlan and 3Com drivers (I had >> written a 3Com driver at Tek previous for VMS. The Interlan board was >> new, as was the DEC board; but I've forgotten what we got when). The >> original CAD 780 ('Coke') must have had multiple interfaces in it, but >> I really don't remember. > > You would think I would remember more of the network situation around > the INGRES project given that we had someone working on distributed > databases (Ken Birman, now at Cornell I think, did something called > COCANET). However, I have no recollection at all about what the > connection actually was. It might be possible to pull some of Ken's old > papers (late 70s/early 80s) and get more information there. > > eric From nw at retrocomputingtasmania.com Sun Jan 13 12:19:36 2019 From: nw at retrocomputingtasmania.com (Nigel Williams) Date: Sun, 13 Jan 2019 13:19:36 +1100 Subject: [TUHS] practice of aliasing C compiler with occ? Message-ID: We've been recovering a 1980s programming language implemented using a mix of Pascal and C that ran on 4.1 BSD on VAX. The Makefile distributed to around 20+ sites included these lines for the C compiler. CC= occ CFLAGS= -g It seems there was a (common?) practice of keeping around the old C compiler when updating a BSD system and occ was used to reference it. Anyone care to comment on this observation? was it specific to BSD-land? how was the aliasing effected, a side-by-side copy of the compiler pieces? As at 4.1 BSD the C compiler components were in /lib (Pascal though was in /usr/lib). # ls -l /lib total 467 -rwxr-xr-x 1 root 25600 Jul 9 1981 c2 -rwxr-xr-x 1 root 89088 Jul 9 1981 ccom -rwxr-xr-x 1 root 19456 Jul 9 1981 cpp -rwxr-xr-x 1 root 199 Mar 15 1981 crt0.o -rwxr-xr-x 1 root 40960 Jul 9 1981 f1 -rwxr-xr-x 1 root 62138 Jul 9 1981 libc.a -rwxr-xr-x 1 root 582 Mar 15 1981 mcrt0.o From scj at yaccman.com Sun Jan 13 13:41:26 2019 From: scj at yaccman.com (Steve Johnson) Date: Sat, 12 Jan 2019 19:41:26 -0800 Subject: [TUHS] Knuth and Unix In-Reply-To: <201901100739.x0A7dSfJ012307@freefriends.org> Message-ID: One connection Knuth had to Unix was inventing LALR parsing, the basic algorithm used in Yacc.  I added some things (notably, the precedence mechanism) and had to do a lot of engineering to be able to handle large grammars (e.g. F77) on a PDP-11.  But the underlying algorithm (taught to my be Al Aho) was all Knuth. I seem to recall also that a lot of us at that time were underwhelmed by The Art of Computer Programming, especially the use of MIX.  Perhaps it just meant that Knuth was doing things bottom up, while we were doing amazing things in small spaces with B and C. Steve ----- Original Message ----- From: arnold at skeeve.com To:, Cc: Sent:Thu, 10 Jan 2019 00:39:28 -0700 Subject:Re: [TUHS] Knuth and Unix Ed Cashin wrote: > Knuth is great, and I too am interested to know about his influence on > UNIX, but Hoare is credited with the quicksort algorithm by the > authorities I've encountered. Hoare did indeed invent it. He describes the history, IIRC, in his Turing Award lecture. (I know I read it, written by him, somewhere.) Arnold -------------- next part -------------- An HTML attachment was scrubbed... URL: From bakul at bitblocks.com Sun Jan 13 14:40:11 2019 From: bakul at bitblocks.com (Bakul Shah) Date: Sat, 12 Jan 2019 20:40:11 -0800 Subject: [TUHS] Knuth and Unix In-Reply-To: Your message of "Sat, 12 Jan 2019 19:41:26 -0800." References: Message-ID: <20190113044018.B235E156E410@mail.bitblocks.com> On Sat, 12 Jan 2019 19:41:26 -0800 "Steve Johnson" wrote: > One connection Knuth had to Unix was inventing LALR parsing, the basic > algorithm used in Yacc. I added some things (notably, the precedence > mechanism) and had to do a lot of engineering to be able to handle large > grammars (e.g. F77) on a PDP-11. But the underlying algorithm (taught to > my be Al Aho) was all Knuth. Knuth invented LR parsing but IIRC it was DeRemer who came up with LALR parsing. In 78-79 I was implementing a LALR(1) parser generator in Pascal on strength of which I got my first real job. At that job I used DeRemer and Pennello's 1979 paper to reimplement the parser generator. From pnr at planet.nl Sun Jan 13 20:52:19 2019 From: pnr at planet.nl (Paul Ruizendaal) Date: Sun, 13 Jan 2019 11:52:19 +0100 Subject: [TUHS] V6 networking & alarm syscall Message-ID: <921E58F1-1631-4390-8CCD-52EE0238B241@planet.nl> > Where did you find the BBN TCP/IP stack? Easiest place to find it is the TUHS Unix Tree page: https://www.tuhs.org//cgi-bin/utree.pl?file=BBN-Vax-TCP Several tapes of it survived in the CSRG archives, currently held by the Bancroft Library at Berkeley. A late version of the tcp/ip routines survived at the Stanford SAIL archives, currently online here: https://www.saildart.org/[IP,SYS]/ (mixed in with sources for WAITS). A much evolved version is in the BSD SCCS history: https://github.com/weiss/original-bsd/tree/master/sys/deprecated/bbnnet Note that the location ‘deprecated’ is where the code ended up. Back in 1985 it would have been in the normal build path, but SCCS does not preserve that. Paul From doug at cs.dartmouth.edu Sun Jan 13 23:53:34 2019 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Sun, 13 Jan 2019 08:53:34 -0500 Subject: [TUHS] RE AT&T 5620 emulator Message-ID: <201901131353.x0DDrYtw042062@tahoe.cs.Dartmouth.EDU> > I'd love to see a real Blit or jerq in person some day, but I don't even know where I'd find one The Living Computer Museum in Seattle has one. Ad like most things there, you can play with it. Doug From norman at oclsc.org Mon Jan 14 01:00:38 2019 From: norman at oclsc.org (Norman Wilson) Date: Sun, 13 Jan 2019 10:00:38 -0500 (EST) Subject: [TUHS] RE AT&T 5620 emulator Message-ID: <20190113150038.0573F4422F@lignose.oclsc.org> Seth Morabito: I'd love to see a real Blit or jerq in person some day, but I don't even know where I'd find one (it looks like even the Computer History Museum in Mountain View, CA doesn't have a 68K Blit -- it only has a DMD 5620) Doug McIlroy: The Living Computer Museum in Seattle has one. Ad like most things there, you can play with it. === It's a couple of years since I was last in Seattle, but I remember only a DMD 5620 (aka Jerq); no 68000-based Blit. Though of course they are always getting new acquisitions, and have far more in storage than on display. (On one of my visits I was lucky enough to get a tour of the upper floor where things are stored and worked on.) Whether they have a Blit or only a Jerq, it's a wonderful place, and I expect any member of this list would enjoy a visit. I plan to drop in again this July, when I'm in town for USENIX ATC (in suburban Renton). Norman Wilson Toronto ON From imp at bsdimp.com Mon Jan 14 01:39:05 2019 From: imp at bsdimp.com (Warner Losh) Date: Sun, 13 Jan 2019 08:39:05 -0700 Subject: [TUHS] V6 networking & alarm syscall In-Reply-To: <921E58F1-1631-4390-8CCD-52EE0238B241@planet.nl> References: <921E58F1-1631-4390-8CCD-52EE0238B241@planet.nl> Message-ID: On Sun, Jan 13, 2019 at 3:53 AM Paul Ruizendaal wrote: > > Where did you find the BBN TCP/IP stack? > > Easiest place to find it is the TUHS Unix Tree page: > https://www.tuhs.org//cgi-bin/utree.pl?file=BBN-Vax-TCP And was the BBN V6 version ever ported to V7? Several tapes of it survived in the CSRG archives, currently held by the > Bancroft Library at Berkeley. > Are those online? Or an index? Google is failing me (or my google skillz aren't mad this morning). > A late version of the tcp/ip routines survived at the Stanford SAIL > archives, currently online here: > https://www.saildart.org/[IP,SYS]/ > (mixed in with sources for WAITS). > Now that's quite interesting. There's even a C compiler in [C,SYS]. > A much evolved version is in the BSD SCCS history: > https://github.com/weiss/original-bsd/tree/master/sys/deprecated/bbnnet > Note that the location ‘deprecated’ is where the code ended up. Back in > 1985 it would have been in the normal build path, but SCCS does not > preserve that. > I wonder if anybody has gone to the trouble of trying to recreate the movement of these sys/deprecated things into real moves to deprecated coupled with the commit that removed them from the files files, or if any work has been done to make the tree buildable with these obscure things... Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From doug at cs.dartmouth.edu Tue Jan 15 08:25:25 2019 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Mon, 14 Jan 2019 17:25:25 -0500 Subject: [TUHS] RE AT&T 5620 emulator Message-ID: <201901142225.x0EMPP3Q002067@coolidge.cs.Dartmouth.EDU> Norman is right. The Seattle museum has a 5620. Having seen "5620" in the subject line, I completely overlooked the operative words "real blit or jerq" in Seth's posting. Doug From scj at yaccman.com Wed Jan 16 08:32:16 2019 From: scj at yaccman.com (Steve Johnson) Date: Tue, 15 Jan 2019 14:32:16 -0800 Subject: [TUHS] Knuth and Unix In-Reply-To: <20190113044018.B235E156E410@mail.bitblocks.com> Message-ID: I remember reading Knuth's paper, and certainly heard DeRemer's name, but it didn't affect much of what I did.  There was a paper out of Stanford about that time that influenced me greatly -- it was about pattern matching languages, and proposed separating two ideas: 1.  "Here are the patterns that match this tree".  And 2.  "If more than one pattern matches, here's how to decide which one to use."   Given the constraints of size on the PDP 11, anything but LR(1) was infeasable.  But using ambiguous grammars and broadening the shift/reduce test to trest operator precedence fit right into that pattern.   Another thing that I think was unique to Yacc at the time was introducing symbols that matched the empty string whose reduction caused program actions.  Many similar parser systems at the time could not deal with these "empty" symbols. Steve ----- Original Message ----- From: "Bakul Shah" To:"Steve Johnson" Cc:, , , Sent:Sat, 12 Jan 2019 20:40:11 -0800 Subject:Re: [TUHS] Knuth and Unix On Sat, 12 Jan 2019 19:41:26 -0800 "Steve Johnson" wrote: > One connection Knuth had to Unix was inventing LALR parsing, the basic > algorithm used in Yacc. I added some things (notably, the precedence > mechanism) and had to do a lot of engineering to be able to handle large > grammars (e.g. F77) on a PDP-11. But the underlying algorithm (taught to > my be Al Aho) was all Knuth. Knuth invented LR parsing but IIRC it was DeRemer who came up with LALR parsing. In 78-79 I was implementing a LALR(1) parser generator in Pascal on strength of which I got my first real job. At that job I used DeRemer and Pennello's 1979 paper to reimplement the parser generator. -------------- next part -------------- An HTML attachment was scrubbed... URL: From robpike at gmail.com Wed Jan 16 12:53:33 2019 From: robpike at gmail.com (Rob Pike) Date: Wed, 16 Jan 2019 13:53:33 +1100 Subject: [TUHS] Knuth and Unix In-Reply-To: References: <20190113044018.B235E156E410@mail.bitblocks.com> Message-ID: So you're the reason (Plan 9) awk has 83 reduce-reduce conflicts (and 42 shift-reduce). -rob On Wed, Jan 16, 2019 at 9:39 AM Steve Johnson wrote: > > I remember reading Knuth's paper, and certainly heard DeRemer's name, but it didn't affect much of what I did. There was a paper out of Stanford about that time that influenced me greatly -- it was about pattern matching languages, and proposed separating two ideas: 1. "Here are the patterns that match this tree". And 2. "If more than one pattern matches, here's how to decide which one to use." Given the constraints of size on the PDP 11, anything but LR(1) was infeasable. But using ambiguous grammars and broadening the shift/reduce test to trest operator precedence fit right into that pattern. Another thing that I think was unique to Yacc at the time was introducing symbols that matched the empty string whose reduction caused program actions. Many similar parser systems at the time could not deal with these "empty" symbols. > > Steve > > > > ----- Original Message ----- > From: "Bakul Shah" > To:"Steve Johnson" > Cc:, , , > Sent:Sat, 12 Jan 2019 20:40:11 -0800 > Subject:Re: [TUHS] Knuth and Unix > > > On Sat, 12 Jan 2019 19:41:26 -0800 "Steve Johnson" wrote: > > One connection Knuth had to Unix was inventing LALR parsing, the basic > > algorithm used in Yacc. I added some things (notably, the precedence > > mechanism) and had to do a lot of engineering to be able to handle large > > grammars (e.g. F77) on a PDP-11. But the underlying algorithm (taught to > > my be Al Aho) was all Knuth. > > Knuth invented LR parsing but IIRC it was DeRemer who came up > with LALR parsing. In 78-79 I was implementing a LALR(1) > parser generator in Pascal on strength of which I got my first > real job. At that job I used DeRemer and Pennello's 1979 > paper to reimplement the parser generator. > From alan at alanlee.org Wed Jan 16 13:49:19 2019 From: alan at alanlee.org (alan at alanlee.org) Date: Tue, 15 Jan 2019 22:49:19 -0500 Subject: [TUHS] The John Snow's of the UNIX family Message-ID: I've been on a Data General Aviion restoration binge lately and re-familiarizing myself with DG/UX. In my case 5.4R3.1 running on a MC88100 based AV/300 and MC88110 dual core AV/5500. The more I experience, the more I am impressed. There are a few things about the system that seem impressive. - Despite coming from a System V core, there is a lot of BSD influx - especially on the networking side. This is a personal taste issue as other ports have tried to mix the best of both worlds. But after a prior month-long Sun/Solaris restoration binge of similar era hardware (Super/Hyper/Ultra SPARC) and software (SunOS 4 through Solaris 9), DG/UX is a welcome and refreshing change! Especially out of the box. - It has a system of file security that seems unique for that era - at least in my experience - of explicit and implicit directory tags with inheritance. There is even a high security extended version of the OS. - It has a built-in logical volume manager supporting multiple virtual to physical disk mappings, striping, mirroring, and even archiving - something several entire sub-industries were created for in other ports. I am guessing this contributed to EMC's purchase of Data General for the Clariion disk storage product lines. - It leveraged open-source tools early. The default m88k compiler installed with the system is GNU C 2.xx. - It was among the earliest of operating systems to support NUMA aware affinity on MP versions of the MC88110. (IRIX, Solaris, BSD, Linux, and Windows support all came much later). - Many others. It does have it's quirks. However I get the overall impression the folks working at DG were on their game and were a leader in the industry in many areas. It is unfortunate a) the fate of the Motorola 88K was tied to Data General's place in the UNIX world, and b) by the time they migrated to IA86, enterprise business was more interested in Microsoft NT & SQL server or Linux than an expensive vendor's UNIX port. That being said, I don't see DG/UX mentioned much in UNIX history. In fact, I am researching an exhibit I'm putting together for the Vintage Computer Festival Southeast 7.0, and DG/UX isn't mentioned on any of the 'UNIX Family Tree' diagrams I can find so far. It doesn't even make Wikipedia's 'UNIX Variants' page. It's own Wikipedia page is also rather sparse. Like John Snow in season 1, there is a junk of missing and plot impacting history here - centered around the people involved. To a lesser degree, IRIX is also a red-headed step-child. It's omitted from half the lists I can find. It just seems the importance, even if it's an importance by being the 'first' rather than # of users, of these ports are pretty significant. Just curious of others' thoughts. And I wondering if anyone has first-hand knowledge of Data General's efforts or knows of others that can illuminate the shadows of what I'm discovering is a pretty exciting corner of the UNIX world. Thanks, -Alan H. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ggm at algebras.org Wed Jan 16 14:07:59 2019 From: ggm at algebras.org (George Michaelson) Date: Wed, 16 Jan 2019 14:07:59 +1000 Subject: [TUHS] The John Snow's of the UNIX family In-Reply-To: References: Message-ID: In my opinion, the popularity of a UNIX platform is tightly tied to the availability of the platform at university. If DG was available to tinker on, to run ROFF, to write small programs for other reasons, to introspect and familiarise yourself with, Then for those students, it became the logical choice. If they ignored the tertiary education market, sold into industry, they could have established a huge loyal fanbase in E.G. Finance and Insurance. Or in the decision support systems in Oil. Or shoe makers inventory control. But if you don't have a cohort of students who recognize your brand, your flavour of UNIX, and you then face these students flexing muscles at purchase time, Instead of "lets buy the upgrade option from DG" you get "why don't we buy Sun, and then get cheap kids to run it" TL;DR DG did not have significant presence in the tertiary education systems I played in (York, Leeds, UCL, UQ) and by my visibility, almost any tertiary education facility I have seen. They didn't feed the beast. From henry.r.bent at gmail.com Wed Jan 16 14:47:57 2019 From: henry.r.bent at gmail.com (Henry Bent) Date: Tue, 15 Jan 2019 23:47:57 -0500 Subject: [TUHS] The John Snow's of the UNIX family In-Reply-To: References: Message-ID: On Tue, 15 Jan 2019 at 23:08, George Michaelson wrote: > In my opinion, the popularity of a UNIX platform is tightly tied to > the availability of the platform at university. > That's a very good point. But going too far in that direction may have been a problem too. My understanding is that Omron's Luna 88K line was very closely tied to the education market. It ran a customized version of Mach, so in some sense I suppose they were tied to CMU from the get-go, and my understanding is that they courted the education market heavily. Oberlin College was given, outright, a four processor 88K Luna. Today I'm not sure you could find a running Luna if you wanted to. -Henry -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Wed Jan 16 16:05:48 2019 From: imp at bsdimp.com (Warner Losh) Date: Tue, 15 Jan 2019 23:05:48 -0700 Subject: [TUHS] The John Snow's of the UNIX family In-Reply-To: References: Message-ID: On Tue, Jan 15, 2019, 9:48 PM Henry Bent > On Tue, 15 Jan 2019 at 23:08, George Michaelson wrote: > >> In my opinion, the popularity of a UNIX platform is tightly tied to >> the availability of the platform at university. >> > > That's a very good point. But going too far in that direction may have > been a problem too. My understanding is that Omron's Luna 88K line was > very closely tied to the education market. It ran a customized version of > Mach, so in some sense I suppose they were tied to CMU from the get-go, and > my understanding is that they courted the education market heavily. > Oberlin College was given, outright, a four processor 88K Luna. Today I'm > not sure you could find a running Luna if you wanted to. > https://dmesgd.nycbug.org/index.cgi?do=view&id=4501 Claims to be running OpenBSD as of a few months ago. There are also reports of NetBSD as well. There appear to be maybe 6 different machines listed here. Not sure this really disproves your point though. Warner > -------------- next part -------------- An HTML attachment was scrubbed... URL: From crossd at gmail.com Thu Jan 17 00:24:54 2019 From: crossd at gmail.com (Dan Cross) Date: Wed, 16 Jan 2019 09:24:54 -0500 Subject: [TUHS] The John Snow's of the UNIX family In-Reply-To: References: Message-ID: On Tue, Jan 15, 2019 at 11:08 PM George Michaelson wrote: > In my opinion, the popularity of a UNIX platform is tightly tied to > the availability of the platform at university. > > If DG was available to tinker on, to run ROFF, to write small programs > for other reasons, to introspect and familiarise yourself with, Then > for those students, it became the logical choice. > > If they ignored the tertiary education market, sold into industry, > they could have established a huge loyal fanbase in E.G. Finance and > Insurance. Or in the decision support systems in Oil. Or shoe makers > inventory control. But if you don't have a cohort of students who > recognize your brand, your flavour of UNIX, and you then face these > students flexing muscles at purchase time, Instead of "lets buy the > upgrade option from DG" you get "why don't we buy Sun, and then get > cheap kids to run it" > > TL;DR DG did not have significant presence in the tertiary education > systems I played in (York, Leeds, UCL, UQ) and by my visibility, > almost any tertiary education facility I have seen. They didn't feed > the beast. > Interesting. When I was in high school in central Pennsylvania and begging, borrowing (and yeah a little stealing) computer time from Penn State systems, there was a CS professor who'd made his bones building something called UREP: Unix RSCS Emulation Program. I can't remember the fellow's name; something "Roberts" maybe. He was known for being somewhat acerbic (he'd call students "stupid" in class, was known to be nasty on USENET, etc) and he wasn't a healthy man. He died of a heart attack when I was in my late teens. Anyway.... What's notable about that, to me, was that he wrote UREP for DG/UX and was known to be fond of Data General machines. This let him talk to the university's mainframe, which was run by the computer center, ran VM, and was the major compute engine on campus at the time outside of specially purchased machines supporting research. There was a Cray somewhere on campus, for example, but that was purchased out of research funds and wasn't generally accessible. It also let Unix machines participate on BITNET, which was a big deal locally at the time (probably because of the close association with mainframes). But this was well before the AViiON series; probably around the time of the Eagle. So maybe just after the "Soul of a New Machine" era in DG's history. Anyway, the point is that they did have a footprint in the academic market. I suspect their lack of success had more to do with them as a company and their foibles in the market than anything else. Like many of the "Route 128" minicomputer companies of the early 70s, I get the impression that they ran themselves into the ground chasing the minicomputer market and missing the shift to microprocessors, workstations and PCs. By the time they could try and turn things around with the storage kit, they were a bit player in the server market. The storage thing only set them apart and kept them afloat long enough to get bought out. - Dan C. (PS: I worked for a startup in NYC in the very late 1990s and early 2000; one of those "dot com" companies [all the stories are true, though in my defense I had no idea just how much drama was happening around me at the time]. We picked up some kind of engineering director guy via some merger with another dot com startup-y sort of thing based in Boston and that guy had come from Data General. Of course, he wanted to move everything to Boston/Cambridge and thought us New Yorkers were a bunch of dullards. It stuck out to me because I don't think I've ever worked with an emptier suit, though I've seen a few that gave him a run for his money.... If DG management was anything like him, no wonder they died an inglorious death.) -------------- next part -------------- An HTML attachment was scrubbed... URL: From nobozo at gmail.com Thu Jan 17 00:40:02 2019 From: nobozo at gmail.com (Jon Forrest) Date: Wed, 16 Jan 2019 06:40:02 -0800 Subject: [TUHS] The John Snow's of the UNIX family In-Reply-To: References: Message-ID: On 1/16/2019 6:24 AM, Dan Cross wrote: > On Tue, Jan 15, 2019 at 11:08 PM George Michaelson > wrote: > > In my opinion, the popularity of a UNIX platform is tightly tied to > the availability of the platform at university. I was in the CS Department at UC Berkeley for most of the 90s. Looking at the presence of various Unix workstations was like looking at the rings of a large tree. At various times, various Unix workstation vendors would donate hardware in order to help promote their version of Unix and/or their hardware. There were the Sun years, the HP years, the DEC years, and the Intel-based PC years. Jon Forrest From kevin.bowling at kev009.com Thu Jan 17 00:40:41 2019 From: kevin.bowling at kev009.com (Kevin Bowling) Date: Wed, 16 Jan 2019 15:40:41 +0100 Subject: [TUHS] The John Snow's of the UNIX family In-Reply-To: References: Message-ID: I’ve heard and personally seen a lot of technical arrogance and incompetence out of the Masshole area. Was DEC inflicted? In “Showstopper” Cutler fled to the west coast to get away from this kind of thing. On Wed, Jan 16, 2019 at 2:26 PM Dan Cross wrote: > On Tue, Jan 15, 2019 at 11:08 PM George Michaelson > wrote: > >> In my opinion, the popularity of a UNIX platform is tightly tied to >> the availability of the platform at university. >> >> If DG was available to tinker on, to run ROFF, to write small programs >> for other reasons, to introspect and familiarise yourself with, Then >> for those students, it became the logical choice. >> >> If they ignored the tertiary education market, sold into industry, >> they could have established a huge loyal fanbase in E.G. Finance and >> Insurance. Or in the decision support systems in Oil. Or shoe makers >> inventory control. But if you don't have a cohort of students who >> recognize your brand, your flavour of UNIX, and you then face these >> students flexing muscles at purchase time, Instead of "lets buy the >> upgrade option from DG" you get "why don't we buy Sun, and then get >> cheap kids to run it" >> >> TL;DR DG did not have significant presence in the tertiary education >> systems I played in (York, Leeds, UCL, UQ) and by my visibility, >> almost any tertiary education facility I have seen. They didn't feed >> the beast. >> > > Interesting. When I was in high school in central Pennsylvania and > begging, borrowing (and yeah a little stealing) computer time from Penn > State systems, there was a CS professor who'd made his bones building > something called UREP: Unix RSCS Emulation Program. I can't remember the > fellow's name; something "Roberts" maybe. He was known for being somewhat > acerbic (he'd call students "stupid" in class, was known to be nasty on > USENET, etc) and he wasn't a healthy man. He died of a heart attack when I > was in my late teens. Anyway.... > > What's notable about that, to me, was that he wrote UREP for DG/UX and was > known to be fond of Data General machines. This let him talk to the > university's mainframe, which was run by the computer center, ran VM, and > was the major compute engine on campus at the time outside of specially > purchased machines supporting research. There was a Cray somewhere on > campus, for example, but that was purchased out of research funds and > wasn't generally accessible. It also let Unix machines participate on > BITNET, which was a big deal locally at the time (probably because of the > close association with mainframes). But this was well before the AViiON > series; probably around the time of the Eagle. So maybe just after the > "Soul of a New Machine" era in DG's history. > > Anyway, the point is that they did have a footprint in the academic > market. I suspect their lack of success had more to do with them as a > company and their foibles in the market than anything else. Like many of > the "Route 128" minicomputer companies of the early 70s, I get the > impression that they ran themselves into the ground chasing the > minicomputer market and missing the shift to microprocessors, workstations > and PCs. By the time they could try and turn things around with the storage > kit, they were a bit player in the server market. The storage thing only > set them apart and kept them afloat long enough to get bought out. > > - Dan C. > > (PS: I worked for a startup in NYC in the very late 1990s and early 2000; > one of those "dot com" companies [all the stories are true, though in my > defense I had no idea just how much drama was happening around me at the > time]. We picked up some kind of engineering director guy via some merger > with another dot com startup-y sort of thing based in Boston and that guy > had come from Data General. Of course, he wanted to move everything to > Boston/Cambridge and thought us New Yorkers were a bunch of dullards. It > stuck out to me because I don't think I've ever worked with an emptier > suit, though I've seen a few that gave him a run for his money.... If DG > management was anything like him, no wonder they died an inglorious death.) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chet.ramey at case.edu Thu Jan 17 00:51:21 2019 From: chet.ramey at case.edu (Chet Ramey) Date: Wed, 16 Jan 2019 09:51:21 -0500 Subject: [TUHS] The John Snow's of the UNIX family In-Reply-To: References: Message-ID: On 1/16/19 9:24 AM, Dan Cross wrote: > Anyway, the point is that they did have a footprint in the academic market. > I suspect their lack of success had more to do with them as a company and > their foibles in the market than anything else. We (CWRU) got a donated MV10000 from DG in the mid-80s. It was pretty easy to get an account on it, as opposed to the "official" VAX, but everyone hated working on it. It was just painful, especially if you tried to get free software working. DG tried, but, at least in our case, they just weren't up to it. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet at case.edu http://tiswww.cwru.edu/~chet/ From crossd at gmail.com Thu Jan 17 00:58:08 2019 From: crossd at gmail.com (Dan Cross) Date: Wed, 16 Jan 2019 09:58:08 -0500 Subject: [TUHS] The John Snow's of the UNIX family In-Reply-To: References: Message-ID: >From what I've heard, "Technical arrogance" and "Cutler" in the same paragraph is redundant. :-) I work with a bunch of former Microsofties, most of whom were in the Windows kernel group. None of them have nice things to say about him. They acknowledged that Gates could be an insensitive jerk, but at least there was a method behind his madness (he'd be trying to get the the bottom of something he wanted to understand and he wanted to be sure other people understood it too, for example). Cutler on the other hand was just cruel. One guy said his mother was visiting and was standing in the lobby of a Microsoft building while Cutler berated someone for some minor fault. "She learned new words and phrases she hadn't known could exist." Ironically, despite being totally unwilling to move to Boston in 2000, I find myself in exile here in the outer provinces of Massachusetts now. It's kind of amazing to see how many survivors of the minicomputer heydays seem to be waiting for DEC, Data General, etc, to rise from the ashes and take over the datacenter again. "Lisp Machines will rise again!" - Dan C. On Wed, Jan 16, 2019 at 9:40 AM Kevin Bowling wrote: > I’ve heard and personally seen a lot of technical arrogance and > incompetence out of the Masshole area. Was DEC inflicted? In > “Showstopper” Cutler fled to the west coast to get away from this kind of > thing. > > On Wed, Jan 16, 2019 at 2:26 PM Dan Cross wrote: > >> On Tue, Jan 15, 2019 at 11:08 PM George Michaelson >> wrote: >> >>> In my opinion, the popularity of a UNIX platform is tightly tied to >>> the availability of the platform at university. >>> >>> If DG was available to tinker on, to run ROFF, to write small programs >>> for other reasons, to introspect and familiarise yourself with, Then >>> for those students, it became the logical choice. >>> >>> If they ignored the tertiary education market, sold into industry, >>> they could have established a huge loyal fanbase in E.G. Finance and >>> Insurance. Or in the decision support systems in Oil. Or shoe makers >>> inventory control. But if you don't have a cohort of students who >>> recognize your brand, your flavour of UNIX, and you then face these >>> students flexing muscles at purchase time, Instead of "lets buy the >>> upgrade option from DG" you get "why don't we buy Sun, and then get >>> cheap kids to run it" >>> >>> TL;DR DG did not have significant presence in the tertiary education >>> systems I played in (York, Leeds, UCL, UQ) and by my visibility, >>> almost any tertiary education facility I have seen. They didn't feed >>> the beast. >>> >> >> Interesting. When I was in high school in central Pennsylvania and >> begging, borrowing (and yeah a little stealing) computer time from Penn >> State systems, there was a CS professor who'd made his bones building >> something called UREP: Unix RSCS Emulation Program. I can't remember the >> fellow's name; something "Roberts" maybe. He was known for being somewhat >> acerbic (he'd call students "stupid" in class, was known to be nasty on >> USENET, etc) and he wasn't a healthy man. He died of a heart attack when I >> was in my late teens. Anyway.... >> >> What's notable about that, to me, was that he wrote UREP for DG/UX and >> was known to be fond of Data General machines. This let him talk to the >> university's mainframe, which was run by the computer center, ran VM, and >> was the major compute engine on campus at the time outside of specially >> purchased machines supporting research. There was a Cray somewhere on >> campus, for example, but that was purchased out of research funds and >> wasn't generally accessible. It also let Unix machines participate on >> BITNET, which was a big deal locally at the time (probably because of the >> close association with mainframes). But this was well before the AViiON >> series; probably around the time of the Eagle. So maybe just after the >> "Soul of a New Machine" era in DG's history. >> >> Anyway, the point is that they did have a footprint in the academic >> market. I suspect their lack of success had more to do with them as a >> company and their foibles in the market than anything else. Like many of >> the "Route 128" minicomputer companies of the early 70s, I get the >> impression that they ran themselves into the ground chasing the >> minicomputer market and missing the shift to microprocessors, workstations >> and PCs. By the time they could try and turn things around with the storage >> kit, they were a bit player in the server market. The storage thing only >> set them apart and kept them afloat long enough to get bought out. >> >> - Dan C. >> >> (PS: I worked for a startup in NYC in the very late 1990s and early 2000; >> one of those "dot com" companies [all the stories are true, though in my >> defense I had no idea just how much drama was happening around me at the >> time]. We picked up some kind of engineering director guy via some merger >> with another dot com startup-y sort of thing based in Boston and that guy >> had come from Data General. Of course, he wanted to move everything to >> Boston/Cambridge and thought us New Yorkers were a bunch of dullards. It >> stuck out to me because I don't think I've ever worked with an emptier >> suit, though I've seen a few that gave him a run for his money.... If DG >> management was anything like him, no wonder they died an inglorious death.) >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lars at nocrew.org Thu Jan 17 01:10:19 2019 From: lars at nocrew.org (Lars Brinkhoff) Date: Wed, 16 Jan 2019 15:10:19 +0000 Subject: [TUHS] The John Snow's of the UNIX family In-Reply-To: (Dan Cross's message of "Wed, 16 Jan 2019 09:58:08 -0500") References: Message-ID: <7wk1j4zlic.fsf@junk.nocrew.org> Dan Cross wrote: > "Lisp Machines will rise again!" I heard Grenblatt is working on something new. From clemc at ccc.com Thu Jan 17 01:44:08 2019 From: clemc at ccc.com (Clem Cole) Date: Wed, 16 Jan 2019 10:44:08 -0500 Subject: [TUHS] The John Snow's of the UNIX family In-Reply-To: References: Message-ID: Let me see if I can illuminate from a little I was aware. I know some of the histories from my time at Locus when DG was a customer of ours. Although, I'm going to show my old f*rt, cultural illiteracy (not a TV person) by having no idea who 'John Snow' is, so I can not comment on that reference ;-) I think you are right that some of the histories tend to tided to people's experience at their college or universities and I'm not sure how well DG sold in those markets. Plus they bet on Moto, who fumbled with the 68000 replacement (88k), compared to IBM's PPC and later Intel's remarkable recovery with the 386. Since they joined the losing side of the chip war, I suspect that also hurt them, even though the system was actually well done. At one time I had access to the sources of DG/UX and yes you are correct it was very clean and easy to understand (and fairly well documented). At the time, we (LCC) had the sources to DG/UX, Ultrix, Tru64, OSF/1, SunOS, Solaris, HP-UX, AIX, Prime, as well as all of the AT&T releases. (The management at Locus used to say we were the Swiss of the UNIX industry - we sold arms to all the sides of the war). As for DG/UX, their kernel seemed like it was a rewrite (I never knew how much of it was the SW folks in NC (who had been building their failed "Fountainhead" system that the Soul-Of-The-New-Machine book talks about, and how much was the MA folks that did Clarion later on). It was definitely the sanest of all of the UNIX kernels we had access and had the least amount of cruft in it of the commercial systems. The locking scheme was the one of the cleanest, I ever saw (Stellar's Stellix was the only one that was as good, IMO). The memory system was really impressive. I remember when we were doing the TNC distributed FS work that what would become the TruCluster FS for DEC at the same time. The DG/UX version was the simplest (and the HP/UX version the most twisted confused). I'm now mixing up the differences in my mind, but I think I remember DG/UX had some sort of file system stacking scheme at the inode level. I'm not sure if it ever shipped, but we worked on a Union file system for them; that I remember was very cool (Plan9ish in splicing file system namespaces together). I seem to remember it was all made possible because of the lower level memory scheme. But I might be mixing that up with one of the systems we were hacking (it was definately not OSF/1 or its child Tru64). As you said, the user space API was basically System V, but DG did support a lot of BSDism also; so bringing networking code from 4.2/4.3 was not terrible; although since it was not fish or fowl, you had to be careful. The big issue when it came out, is that SunOS (and later Solaris) had become the defacto system at most universities, where much 'free software' was being produced. Since it was more System V user API at the heart (which was good for DG's targetted ISVs), it did suffer from the porting issues. Since it was an 88K and SunOS had been 68K, the Endian issues of the free SW was less of a problem, but not only was not a VAX, but it was not BSD. Clem > ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ats at offog.org Thu Jan 17 01:05:51 2019 From: ats at offog.org (Adam Sampson) Date: Wed, 16 Jan 2019 15:05:51 +0000 Subject: [TUHS] The John Snow's of the UNIX family In-Reply-To: (Dan Cross's message of "Wed, 16 Jan 2019 09:24:54 -0500") References: Message-ID: Dan Cross writes: > I can't remember the fellow's name; something "Roberts" maybe. [...] > What's notable about that, to me, was that he wrote UREP for DG/UX and > was known to be fond of Data General machines. Robert Michael Owens -- in the utzoo Usenet archives there are very early posts from him as psuvax!bear. He passed away in 1997; see the biography here: http://sips2016.rice.edu/bob-owens/ A 1983 post to net.unix-wizards from Bruce Crabill says: > The Unix version of the RSCS emulator is called UREP (Unix RSCS > Emulation Program) and is available from Pennsylvania State > University. It was written by Robert Owens and Joseph Boykin. More > information on it can be obtained from Robert Owens (BITNET: > OWENS at PSUVAX1). The VMS version was written by Craig Watkins (BITNET: > CRW at PSUVMS1). I have talked to both versions from BITNET and found > them to be very good emulations of RSCS (which is IBM's Remote > Spooling Communications Subsystem/Networking). -- Adam Sampson From clemc at ccc.com Thu Jan 17 01:50:31 2019 From: clemc at ccc.com (Clem Cole) Date: Wed, 16 Jan 2019 10:50:31 -0500 Subject: [TUHS] The John Snow's of the UNIX family In-Reply-To: References: Message-ID: On Wed, Jan 16, 2019 at 9:41 AM Kevin Bowling wrote: > In “Showstopper” Cutler fled to the west coast to get away from this kind > of thing. > Be careful of popularized history. DC went to the left coast for reasons that had nothing to do with MA culture. As people that knew him and worked with him can attest, he was in fact as a chain smoker and ex-Marine (sorry Dan), he was and is much more 'east-coast' than 'mellow left coaster.' [He kept his cigarrettes rolled up in his tee shirt just like James Dean BTW]. There is even a ESPN highlight real of him rolling his car in an NASCAR race, which Ihave lost the URL too (I took a quick look and could not find it). ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From doug at cs.dartmouth.edu Thu Jan 17 01:57:29 2019 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Wed, 16 Jan 2019 10:57:29 -0500 Subject: [TUHS] Knuth and Unix Message-ID: <201901161557.x0GFvT6l029710@tahoe.cs.Dartmouth.EDU> Tsort was a direct reference to Knuth's recognition and christening of topological sort as a worthy software component. This is a typical example of the interweaving of R and D which characterized the culture of Bell Labs. Builders and thinkers were acutely aware of each other, and often were two faces of one person. Grander examples may be seen in the roles that automata theory and formal languages played in Unix. (Alas, these are the subjects of projected Knuthian volumes that are still over the horizon.) Doug From paul.winalski at gmail.com Thu Jan 17 02:55:03 2019 From: paul.winalski at gmail.com (Paul Winalski) Date: Wed, 16 Jan 2019 11:55:03 -0500 Subject: [TUHS] DEC and Dave Cutler (was Re: The John Snow's of the UNIX family) Message-ID: On 1/16/19, Kevin Bowling wrote: > I’ve heard and personally seen a lot of technical arrogance and > incompetence out of the Masshole area. Was DEC inflicted? In > “Showstopper” Cutler fled to the west coast to get away from this kind of > thing. > Having worked at DEC from February 1980 until after the Compaq takeover, I would say that DEC may have exhibited technical arrogance from time to time, but certainly never technical incompetence. DEC's downfall was a total lack of skill at marketing. Ken Olsen believed firmly in a "build it and they will come" philosophy. Contrast this with AT&T's brilliant "Unix - consider it a standard" ad campaign. DEC also suffered from organizational paralysis. KO believed in decisions by consensus. This is fine if you can reach a consensus, but if you can't it leads to perpetually revisiting decisions and to obstructionist behavior. There was a saying in DEC engineering that any decision worth making was worth making 10 times. As opposed to the "lead, follow, or get out of the way" philosophy at Sun. Or Intel's concept of disagree and commit. DEC did move towards a "designated responsible individual" approach where a single person got to make the ultimate decision, but the old consensus approach never really died. Dave Cutler was the epitome of arrogance. On the technical side, he got away with it because his way (which he considered to be the only way) was usually at least good enough for Version 1, if not the best design. Cutler excelled in getting V1 of something out the door. He never stayed around for V2 of anything. He had a tendency to leave messes behind him. A Cutler product reminded me of the intro to "The Peabodys" segment of Rocky & Bullwinkle. A big elaborate procession, followed by someone cleaning up the mess with a broom. Cutler believed in a "my way or the highway" approach to software design. His move to the west coast was to place himself far enough away that those who wanted to revisit all his decisions would have a tough time doing so. On the personal side, he went out of his way to be nasty to people, as pointed out elsewhere in this thread. Although he was admired technically, nobody liked him. -Paul W. From paul.winalski at gmail.com Thu Jan 17 03:03:09 2019 From: paul.winalski at gmail.com (Paul Winalski) Date: Wed, 16 Jan 2019 12:03:09 -0500 Subject: [TUHS] DEC and Dave Cutler Message-ID: Forgive me if this is a duplicate. My original message appears to have bounced. On 1/16/19, Kevin Bowling wrote: > I’ve heard and personally seen a lot of technical arrogance and > incompetence out of the Masshole area. Was DEC inflicted? In > “Showstopper” Cutler fled to the west coast to get away from this kind of > thing. > Having worked at DEC from February 1980 until after the Compaq takeover, I would say that DEC may have exhibited technical arrogance from time to time, but certainly never technical incompetence. DEC's downfall was a total lack of skill at marketing. Ken Olsen believed firmly in a "build it and they will come" philosophy. Contrast this with AT&T's brilliant "Unix - consider it a standard" ad campaign. DEC also suffered from organizational paralysis. KO believed in decisions by consensus. This is fine if you can reach a consensus, but if you can't it leads to perpetually revisiting decisions and to obstructionist behavior. There was a saying in DEC engineering that any decision worth making was worth making 10 times. As opposed to the "lead, follow, or get out of the way" philosophy at Sun. Or Intel's concept of disagree and commit. DEC did move towards a "designated responsible individual" approach where a single person got to make the ultimate decision, but the old consensus approach never really died. Dave Cutler was the epitome of arrogance. On the technical side, he got away with it because his way (which he considered to be the only way) was usually at least good enough for Version 1, if not the best design. Cutler excelled in getting V1 of something out the door. He never stayed around for V2 of anything. He had a tendency to leave messes behind him. A Cutler product reminded me of the intro to "The Peabodys" segment of Rocky & Bullwinkle. A big elaborate procession, followed by someone cleaning up the mess with a broom. Cutler believed in a "my way or the highway" approach to software design. His move to the west coast was to place himself far enough away that those who wanted to revisit all his decisions would have a tough time doing so. On the personal side, he went out of his way to be nasty to people, as pointed out elsewhere in this thread. Although he was admired technically, nobody liked him. -Paul W. From clemc at ccc.com Thu Jan 17 03:14:30 2019 From: clemc at ccc.com (Clem Cole) Date: Wed, 16 Jan 2019 12:14:30 -0500 Subject: [TUHS] DEC and Dave Cutler (was Re: The John Snow's of the UNIX family) In-Reply-To: References: Message-ID: On Wed, Jan 16, 2019 at 11:55 AM Paul Winalski wrote: > ... Cutler excelled in getting V1 of something out the door. He never > stayed around for V2 of anything. He had a tendency to leave > messes behind him. A Cutler product reminded me of the intro to "The Peabodys" > segment of Rocky & Bullwinkle. A big elaborate procession, > followed by someone cleaning up the mess with a broom. > One of the first times I met him, was during an argument that Fossil remarked to something like: 'Dave, why do you care. You'll be doing something else and these guys have to make it work.' I've never forgotten the look DC gave Roger. He was (is) just not good at listening. And that is to me, the best example of his arrogance. He was quick to point out other's bad ideas; but I don't think he ever looked back and said -- "We'll that was a bad idea *I made*. *I (even we) called that one wrong*." That said, to Dave's credit by the time of Tru64 and he had left for MSFT, everything at DEC had to be 'perfect' before it would ship. And thus things were late or never made it out the door. DC's magic was getting to the nut of the problem and getting what people cared about implemented quickly and out for users to try it. The problem was his scheme, was that he was never part of the team that fixed it later. I think I would have had more respect if he had quickly gotten the product out and then said, 'ok, we took these short cuts. Let's fix them' But as you pointed out, Dave never seems to see them as short cuts. He was 'done.' And when I think about engineers that I really respect, are the ones that can get the first version out the door with that want matters, then work as to polish it and make them better. This means listening to the users and other developers and really taking input from other people. i.e. listening. Clem ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Thu Jan 17 03:29:50 2019 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 16 Jan 2019 09:29:50 -0800 Subject: [TUHS] DEC and Dave Cutler (was Re: The John Snow's of the UNIX family) In-Reply-To: References: Message-ID: <20190116172950.GL7733@mcvoy.com> On Wed, Jan 16, 2019 at 11:55:03AM -0500, Paul Winalski wrote: > DEC's downfall was a total lack of skill at marketing. I have a different view, having been at Sun when Sun was eating DEC's lunch. Sun made stuff that was just as good as what DEC built but they were cheaper. DEC couldn't adapt to decent machines that didn't cost a big pile. History repeats itself, Sun couldn't wean itself off $20,000 workstations when you could get an almost as fast PC for 1/4th or less of that price point. I think perhaps the problem is that companies like that get big revenue and can afford to do crazy amounts of engineering. Then the market shifts and they can't really shift with it, they tell themselves they don't want to ship junk. From lm at mcvoy.com Thu Jan 17 03:33:41 2019 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 16 Jan 2019 09:33:41 -0800 Subject: [TUHS] DEC and Dave Cutler (was Re: The John Snow's of the UNIX family) In-Reply-To: References: Message-ID: <20190116173341.GM7733@mcvoy.com> On Wed, Jan 16, 2019 at 12:14:30PM -0500, Clem Cole wrote: > DC's magic was getting to the > nut of the problem and getting what people cared about implemented quickly > and out for users to try it. The problem was his scheme, was that he was > never part of the team that fixed it later. I think I would have had > more respect if he had quickly gotten the product out and then said, 'ok, > we took these short cuts. Let's fix them' But as you pointed out, Dave > never seems to see them as short cuts. He was 'done.' Ah, yes, the 1.0 person. That's a nice gig if you can get it, but it is rare that a company will put up with it. The fact that DEC did sort of indicates a broken engineering culture. Sun, at least when I was there, would never put up with that. If you pushed something out the door you were expected to stick around and do the dot dot releases that fixed it before you got to move on to the next thing. That was just part of the culture when I was there, I sort of thought they over did it and people sort of polished the turd forever. I escaped that by focussing on performance, that let me bounce all over the place, which was fun. --lm From clemc at ccc.com Thu Jan 17 04:13:30 2019 From: clemc at ccc.com (Clem Cole) Date: Wed, 16 Jan 2019 13:13:30 -0500 Subject: [TUHS] DEC and Dave Cutler (was Re: The John Snow's of the UNIX family) In-Reply-To: <20190116172950.GL7733@mcvoy.com> References: <20190116172950.GL7733@mcvoy.com> Message-ID: On Wed, Jan 16, 2019 at 12:30 PM Larry McVoy wrote: > On Wed, Jan 16, 2019 at 11:55:03AM -0500, Paul Winalski wrote: > > DEC's downfall was a total lack of skill at marketing. > > Sun made stuff that was just as good as what DEC built but they were > cheaper. DEC couldn't adapt to decent machines that didn't cost a big > pile. > > History repeats itself, Sun couldn't wean itself off $20,000 workstations when > you could get an almost as fast PC for 1/4th or less of that price point. I think you are both right actually and in some ways saying the same thing. I refer to this as the economic of solution argument. It's right out of Clay Christensen 's book The Innovator's Dilemma The problem as Larry point out, is that when some one else does something that is economically a better solution, it is marketing jobs to understand that. and help lead the company with products that work. The problem is that marketing rarely says, "We need to eat out own lunch/children ... etc." Instead they talk to customers who tell them make XXX for their futhure more specialized and higher end system, which of course has higher margins. I worked with a VP that once said: "I'd rather sell a $100K system then a $10K one, because the cost of sale is the same." What he did not realize is that Sun was selling 20 systems for $10k, while DEC (or Masscomp) sold one at $10k. Clem ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnold at skeeve.com Thu Jan 17 04:22:48 2019 From: arnold at skeeve.com (arnold at skeeve.com) Date: Wed, 16 Jan 2019 11:22:48 -0700 Subject: [TUHS] Knuth and Unix In-Reply-To: References: <20190113044018.B235E156E410@mail.bitblocks.com> Message-ID: <201901161822.x0GIMmQW026812@freefriends.org> You can't lay the blame for that on Steve. The GNU Awk grammar has only 36 shift-reduce conflicts and no reduce-reduce conflicts. The mawk 1.3.4 grammar has an amazing count of only *four* shift-reduce conflicts. (But then, Mike Brennan is an amazing programmer.) I have no idea what happens if you run the POSIX awk grammar through yacc / bison, but it'd be an interesting experiment. Arnold Rob Pike wrote: > So you're the reason (Plan 9) awk has 83 reduce-reduce conflicts (and > 42 shift-reduce). > > -rob > > On Wed, Jan 16, 2019 at 9:39 AM Steve Johnson wrote: > > > > I remember reading Knuth's paper, and certainly heard DeRemer's name, but it didn't affect much of what I did. There was a paper out of Stanford about that time that influenced me greatly -- it was about pattern matching languages, and proposed separating two ideas: 1. "Here are the patterns that match this tree". And 2. "If more than one pattern matches, here's how to decide which one to use." Given the constraints of size on the PDP 11, anything but LR(1) was infeasable. But using ambiguous grammars and broadening the shift/reduce test to trest operator precedence fit right into that pattern. Another thing that I think was unique to Yacc at the time was introducing symbols that matched the empty string whose reduction caused program actions. Many similar parser systems at the time could not deal with these "empty" symbols. > > > > Steve > > > > > > > > ----- Original Message ----- > > From: "Bakul Shah" > > To:"Steve Johnson" > > Cc:, , , > > Sent:Sat, 12 Jan 2019 20:40:11 -0800 > > Subject:Re: [TUHS] Knuth and Unix > > > > > > On Sat, 12 Jan 2019 19:41:26 -0800 "Steve Johnson" wrote: > > > One connection Knuth had to Unix was inventing LALR parsing, the basic > > > algorithm used in Yacc. I added some things (notably, the precedence > > > mechanism) and had to do a lot of engineering to be able to handle large > > > grammars (e.g. F77) on a PDP-11. But the underlying algorithm (taught to > > > my be Al Aho) was all Knuth. > > > > Knuth invented LR parsing but IIRC it was DeRemer who came up > > with LALR parsing. In 78-79 I was implementing a LALR(1) > > parser generator in Pascal on strength of which I got my first > > real job. At that job I used DeRemer and Pennello's 1979 > > paper to reimplement the parser generator. > > From lm at mcvoy.com Thu Jan 17 04:24:26 2019 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 16 Jan 2019 10:24:26 -0800 Subject: [TUHS] DEC and Dave Cutler (was Re: The John Snow's of the UNIX family) In-Reply-To: References: <20190116172950.GL7733@mcvoy.com> Message-ID: <20190116182426.GQ7733@mcvoy.com> On Wed, Jan 16, 2019 at 01:13:30PM -0500, Clem Cole wrote: > The problem as Larry point out, is that when some one else does something > that is economically a better solution, it is marketing jobs to understand > that. and help lead the company with products that work. I'm sure I'm not alone in being an engineer that was interally very critical of our own products (didn't matter which company). It is a HUGE mistake to let engineers even hear their own marketing. Marketing is, if not outright lieing, a lot like a first date. You put the best version of you possible forward, you leave all the other crud in the closet. Engineers need to be running benchmarks, seeing how hard/easy it is to build X11, they need to be looking for the places their products are weak instead of listening to marketing talking about the places where the product is strong. I took no end of shit for doing exactly that, people thought I was disloyal. Which is rubbish, you can't fix your crap until you face it. Doesn't matter, seems like all engineering orgs fall into the trap of believing their own marketing. If I were still looking for work that would be a red flag. Getting back to TUHS, it's interesting to note that Unix has prevailed, in spite of many companies doing their best to "improve" it out of existence. Yeah, HPUX/IRIX/AIX/Solaris/etc are all dead so far as I know, but the basic Unix model lives on in Linux. I wish one of the decent Unix variants was still vibrant just so Linux doesn't get complacent. From krewat at kilonet.net Thu Jan 17 04:32:18 2019 From: krewat at kilonet.net (Arthur Krewat) Date: Wed, 16 Jan 2019 13:32:18 -0500 Subject: [TUHS] DEC and Dave Cutler (was Re: The John Snow's of the UNIX family) In-Reply-To: <20190116182426.GQ7733@mcvoy.com> References: <20190116172950.GL7733@mcvoy.com> <20190116182426.GQ7733@mcvoy.com> Message-ID: <9b8b8e5b-2cbd-65d3-c66c-2e94eaecacf2@kilonet.net> On 1/16/2019 1:24 PM, Larry McVoy wrote: > Yeah, HPUX/IRIX/AIX/Solaris/etc are all dead so far as I know, but > the basic Unix model lives on in Linux. I wish one of the decent Unix > variants was still vibrant just so Linux doesn't get complacent. My biggest fear, to be honest. From robpike at gmail.com Thu Jan 17 06:10:58 2019 From: robpike at gmail.com (Rob Pike) Date: Thu, 17 Jan 2019 07:10:58 +1100 Subject: [TUHS] Knuth and Unix In-Reply-To: <201901161822.x0GIMmQW026812@freefriends.org> References: <20190113044018.B235E156E410@mail.bitblocks.com> <201901161822.x0GIMmQW026812@freefriends.org> Message-ID: I was speaking in jest... But the (official) awk grammar has been an eye-opener for years. -rob On Thu, Jan 17, 2019 at 5:22 AM wrote: > > You can't lay the blame for that on Steve. > > The GNU Awk grammar has only 36 shift-reduce conflicts and no > reduce-reduce conflicts. > > The mawk 1.3.4 grammar has an amazing count of only *four* shift-reduce > conflicts. (But then, Mike Brennan is an amazing programmer.) > > I have no idea what happens if you run the POSIX awk grammar through > yacc / bison, but it'd be an interesting experiment. > > Arnold > > Rob Pike wrote: > > > So you're the reason (Plan 9) awk has 83 reduce-reduce conflicts (and > > 42 shift-reduce). > > > > -rob > > > > On Wed, Jan 16, 2019 at 9:39 AM Steve Johnson wrote: > > > > > > I remember reading Knuth's paper, and certainly heard DeRemer's name, but it didn't affect much of what I did. There was a paper out of Stanford about that time that influenced me greatly -- it was about pattern matching languages, and proposed separating two ideas: 1. "Here are the patterns that match this tree". And 2. "If more than one pattern matches, here's how to decide which one to use." Given the constraints of size on the PDP 11, anything but LR(1) was infeasable. But using ambiguous grammars and broadening the shift/reduce test to trest operator precedence fit right into that pattern. Another thing that I think was unique to Yacc at the time was introducing symbols that matched the empty string whose reduction caused program actions. Many similar parser systems at the time could not deal with these "empty" symbols. > > > > > > Steve > > > > > > > > > > > > ----- Original Message ----- > > > From: "Bakul Shah" > > > To:"Steve Johnson" > > > Cc:, , , > > > Sent:Sat, 12 Jan 2019 20:40:11 -0800 > > > Subject:Re: [TUHS] Knuth and Unix > > > > > > > > > On Sat, 12 Jan 2019 19:41:26 -0800 "Steve Johnson" wrote: > > > > One connection Knuth had to Unix was inventing LALR parsing, the basic > > > > algorithm used in Yacc. I added some things (notably, the precedence > > > > mechanism) and had to do a lot of engineering to be able to handle large > > > > grammars (e.g. F77) on a PDP-11. But the underlying algorithm (taught to > > > > my be Al Aho) was all Knuth. > > > > > > Knuth invented LR parsing but IIRC it was DeRemer who came up > > > with LALR parsing. In 78-79 I was implementing a LALR(1) > > > parser generator in Pascal on strength of which I got my first > > > real job. At that job I used DeRemer and Pennello's 1979 > > > paper to reimplement the parser generator. > > > From bakul at bitblocks.com Thu Jan 17 06:50:35 2019 From: bakul at bitblocks.com (Bakul Shah) Date: Wed, 16 Jan 2019 12:50:35 -0800 Subject: [TUHS] Knuth and Unix In-Reply-To: Your message of "Tue, 15 Jan 2019 14:32:16 -0800." References: Message-ID: <20190116205043.21C22156E410@mail.bitblocks.com> On Tue, 15 Jan 2019 14:32:16 -0800 "Steve Johnson" wrote: > I remember reading Knuth's paper, and certainly heard > DeRemer's name, but it didn't affect much of what I did. > There was a paper out of Stanford about that time that > influenced me greatly -- it was about pattern matching > languages, and proposed separating two ideas: 1. "Here are > the patterns that match this tree". And 2. "If more than one > pattern matches, here's how to decide which one to use." > Given the constraints of size on the PDP 11, anything but > LR(1) was infeasable. But using ambiguous grammars and > broadening the shift/reduce test to trest operator precedence > fit right into that pattern. Another thing that I think was > unique to Yacc at the time was introducing symbols that > matched the empty string whose reduction caused program > actions. Many similar parser systems at the time could not > deal with these "empty" symbols. Good to know all this. The Stanford paper you refer, would that be "fast pattern matching" by Knuth, Morris & Pratt? I remember struggling with empty strings and I also missed other yacc tricks. In my formulation I had two kinds of rules: set rules and sequence rules. Set rules avoided unnecessary reductions in rules such as foo: bar|... For example: // sets expr = relexpr | expr1 expr1 = addexpr | expr2 expr2 = mulexpr | expr3 ... // sequences relexpr: expr1 RELOP expr1 addexpr: expr1 ('+'|'-') expr2 mulexpr: expr2 ('*'|'/') expr3 ... Basically I completely avoided empty symbols -- even an empty file has an EOF! [I didn't try it on anything more complicated than (extended) Pascal so no idea how it would have fared on complexificated lanuages] From tytso at mit.edu Thu Jan 17 08:09:32 2019 From: tytso at mit.edu (Theodore Y. Ts'o) Date: Wed, 16 Jan 2019 17:09:32 -0500 Subject: [TUHS] DEC and Dave Cutler (was Re: The John Snow's of the UNIX family) In-Reply-To: <20190116172950.GL7733@mcvoy.com> References: <20190116172950.GL7733@mcvoy.com> Message-ID: <20190116220932.GB9343@mit.edu> On Wed, Jan 16, 2019 at 09:29:50AM -0800, Larry McVoy wrote: > > I have a different view, having been at Sun when Sun was eating DEC's > lunch. Sun made stuff that was just as good as what DEC built but they > were cheaper. DEC couldn't adapt to decent machines that didn't cost > a big pile. > > History repeats itself, Sun couldn't wean itself off $20,000 workstations > when you could get an almost as fast PC for 1/4th or less of that price > point. This is applicable in the Open Source world as well, and there it's a much more clearly an example of the "Better is Worse", "New Jersey Style" vs. "The MIT Approach"/"The Right Thing" debate. Example: Linux had PCMCIA support before the *BSD variants, and even when the BSD's had PCMCIA support, the PCMCIA card (most commonly, for WiFi) had to be plugged when the system was booted. Where as for years ahead of *BSD, Linux had hot-plug PCMCIA support --- but if you ejected the card, there was a 30-50% chance the system would crash. (Which could be lowered if you carefully shutdown the network, and waited until all open/pending TCP connections that couldn't be closed had timed out, etc.) Eventually, the *BSD's pulled ahead of Linux, and had rock-solid PC Card support, and it took a lot longer for Linux's hot-eject support to be fully stable. For most users, of couse, hot-pluggable PCMCIA was way more important than stability problems when you ejected the card, especially when it usually worked (especially if you were careful). And if you have more users, you are much more likely to get bug reports, and more likely to recruit developers (which in the open source world, are more likely to stick around if you are willing to accept less-than-perfect patches, as opposed to insisting that they be picture-perfect before they can be committed). There's a downside with this approach, of course, which is that it may take a lot longer to get the code cleaned up after the 1.0 "launch" of the feature. - Ted From pnr at planet.nl Thu Jan 17 09:13:24 2019 From: pnr at planet.nl (Paul Ruizendaal) Date: Thu, 17 Jan 2019 00:13:24 +0100 Subject: [TUHS] Old Unix source code DVD [was: V6 networking & alarm syscall] References: <921E58F1-1631-4390-8CCD-52EE0238B241@planet.nl> Message-ID: <31335EFC-09CE-4286-9358-87B5F74D2004@planet.nl> >> Where did you find the BBN TCP/IP stack? > Several tapes of it survived in the CSRG archives, currently held by the Bancroft Library at Berkeley. I just discovered that Kirk McKusick has made a new DVD that covers a much broader set of software than his earlier 4 CD set: https://www.mckusick.com/csrg/ (see bottom of the page, one but last paragraph). This new DVD includes the surviving BBN VAX TCP source code; it is not on the earlier 4 CD set. Paul Begin forwarded message: > From: Paul Ruizendaal > Subject: Re: [TUHS] V6 networking & alarm syscall > Date: 13 January 2019 11:52:19 GMT+01:00 > To: TUHS main list > >> Where did you find the BBN TCP/IP stack? > > Easiest place to find it is the TUHS Unix Tree page: > https://www.tuhs.org//cgi-bin/utree.pl?file=BBN-Vax-TCP > > Several tapes of it survived in the CSRG archives, currently held by the Bancroft Library at Berkeley. > > A late version of the tcp/ip routines survived at the Stanford SAIL archives, currently online here: > https://www.saildart.org/[IP,SYS]/ > (mixed in with sources for WAITS). > > A much evolved version is in the BSD SCCS history: > https://github.com/weiss/original-bsd/tree/master/sys/deprecated/bbnnet > Note that the location ‘deprecated’ is where the code ended up. Back in 1985 it would have been in the normal build path, but SCCS does not preserve that. > > Paul From wkt at tuhs.org Thu Jan 17 16:17:47 2019 From: wkt at tuhs.org (Warren Toomey) Date: Thu, 17 Jan 2019 16:17:47 +1000 Subject: [TUHS] Extra Two CDs in CSRG CD-ROM Set Message-ID: <20190117061747.GA8415@minnie.tuhs.org> All, I just found out in the past few days that Kirk McKusick has added another two CDs in his set of CSRG Archives CD-ROM set. Some details of these CDs can be found here: https://www.mckusick.com/csrg/index.html I've purchased the two additional CDs, and I've put a file listing and set of checksums for all files on all six CDs here: https://www.tuhs.org/Archive/Documentation/CSRG_CDs/ Cheers, Warren From arnold at skeeve.com Thu Jan 17 16:53:02 2019 From: arnold at skeeve.com (arnold at skeeve.com) Date: Wed, 16 Jan 2019 23:53:02 -0700 Subject: [TUHS] UREP - Unix RSCS Emulation Program In-Reply-To: References: Message-ID: <201901170653.x0H6r24f017203@freefriends.org> Dan Cross wrote: > Interesting. When I was in high school in central Pennsylvania and begging, > borrowing (and yeah a little stealing) computer time from Penn State > systems, there was a CS professor who'd made his bones building something > called UREP: Unix RSCS Emulation Program. ... > > What's notable about that, to me, was that he wrote UREP for DG/UX and was > known to be fond of Data General machines. This let him talk to the > university's mainframe, which was run by the computer center, ran VM, and > was the major compute engine on campus at the time outside of specially > purchased machines supporting research. There was a Cray somewhere on > campus, for example, but that was purchased out of research funds and > wasn't generally accessible. It also let Unix machines participate on > BITNET, which was a big deal locally at the time (probably because of the > close association with mainframes). .... In the mid-1980s I was a sys admin at the Emory U Computing Center and we ran UREP on our vaxen in order to be able to send and receive BITNET mail. It was kind of cute to watch your messages traveling the world, as you got an interactive message back for each site it traversed on its way to its final destination. BUT, the code was miserable. I had to make some changes to it (don't remember why), but EVERY time I had to dive into it, I hated it. I used to say that I felt like I needed a shower afterwards. Arnold From arnold at skeeve.com Thu Jan 17 17:02:53 2019 From: arnold at skeeve.com (arnold at skeeve.com) Date: Thu, 17 Jan 2019 00:02:53 -0700 Subject: [TUHS] Extra Two CDs in CSRG CD-ROM Set In-Reply-To: <20190117061747.GA8415@minnie.tuhs.org> References: <20190117061747.GA8415@minnie.tuhs.org> Message-ID: <201901170702.x0H72r9P017996@freefriends.org> Warren Toomey wrote: > All, I just found out in the past few days that Kirk McKusick has added another > two CDs in his set of CSRG Archives CD-ROM set. Some details of these CDs > can be found here: > > https://www.mckusick.com/csrg/index.html > > I've purchased the two additional CDs, and I've put a file listing and > set of checksums for all files on all six CDs here: > > https://www.tuhs.org/Archive/Documentation/CSRG_CDs/ > > Cheers, Warren What's the link to get the additional CDs? I didn't see it on that page (but maybe I missed it). Thanks, Arnold From arnold at skeeve.com Thu Jan 17 16:58:18 2019 From: arnold at skeeve.com (arnold at skeeve.com) Date: Wed, 16 Jan 2019 23:58:18 -0700 Subject: [TUHS] Knuth and Unix In-Reply-To: References: <20190113044018.B235E156E410@mail.bitblocks.com> <201901161822.x0GIMmQW026812@freefriends.org> Message-ID: <201901170658.x0H6wILO017413@freefriends.org> Rob Pike wrote: > I was speaking in jest... Yes, but ... > But the (official) awk grammar has been an eye-opener for years. Indeed. I wonder who actually wrote the grammar? I know that Brian won't touch it these days. :-) Thanks, Arnold From b4 at gewt.net Thu Jan 17 17:45:43 2019 From: b4 at gewt.net (Madeline Autumn-Rose) Date: Wed, 16 Jan 2019 23:45:43 -0800 Subject: [TUHS] Extra Two CDs in CSRG CD-ROM Set In-Reply-To: <20190117061747.GA8415@minnie.tuhs.org> References: <20190117061747.GA8415@minnie.tuhs.org> Message-ID: <1547711143.3394050.1636872248.491116F7@webmail.messagingengine.com> On Wed, Jan 16, 2019, at 22:17, Warren Toomey wrote: > All, I just found out in the past few days that Kirk McKusick has added another > two CDs in his set of CSRG Archives CD-ROM set. Some details of these CDs > can be found here: > > https://www.mckusick.com/csrg/index.html > > I've purchased the two additional CDs, and I've put a file listing and > set of checksums for all files on all six CDs here: > > https://www.tuhs.org/Archive/Documentation/CSRG_CDs/ > > Cheers, Warren What's on the additional 2 discs? -- Madeline Autumn-Rose b4 at gewt.net From wkt at tuhs.org Thu Jan 17 18:22:10 2019 From: wkt at tuhs.org (Warren Toomey) Date: Thu, 17 Jan 2019 18:22:10 +1000 Subject: [TUHS] Extra Two CDs in CSRG CD-ROM Set In-Reply-To: <1547711143.3394050.1636872248.491116F7@webmail.messagingengine.com> References: <20190117061747.GA8415@minnie.tuhs.org> <1547711143.3394050.1636872248.491116F7@webmail.messagingengine.com> Message-ID: <20190117082210.GA25768@minnie.tuhs.org> > On Wed, Jan 16, 2019, at 22:17, Warren Toomey wrote: > > All, I just found out that Kirk McKusick has added another > > two CDs in his set of CSRG Archives CD-ROM set. On Wed, Jan 16, 2019 at 11:45:43PM -0800, Madeline Autumn-Rose wrote: > What's on the additional 2 discs? Here's a top-level list. Cheers, Warren CSRG/disk1/1bsd CD-ROM #1 - Berkeley Systems 1978 - 1986 CSRG/disk1/2.10 CSRG/disk1/2.79 CSRG/disk1/2.8 CSRG/disk1/2.9 CSRG/disk1/2.9pucc CSRG/disk1/2bsd CSRG/disk1/3bsd CSRG/disk1/4.0 CSRG/disk1/4.1 CSRG/disk1/4.1.snap CSRG/disk1/4.1a CSRG/disk1/4.1c.1 CSRG/disk1/4.1c.2 CSRG/disk1/4.2 CSRG/disk1/4.2buglist CSRG/disk1/4.3 CSRG/disk1/VM.snapshot.1 CSRG/disk1/pascal.2.0 CSRG/disk1/pascal.2.10 CSRG/disk1/rr_moved CSRG/disk2/4.3reno CD-ROM #2 - Berkeley Systems 1987 - 1993 CSRG/disk2/4.3tahoe CSRG/disk2/4.4BSD-Lite1 CSRG/disk2/VM.snapshot.2 CSRG/disk2/net.1 CSRG/disk2/net.2 CSRG/disk2/rr_moved CSRG/disk3/4.4 CD-ROM #3 - Final Berkeley Releases CSRG/disk3/4.4BSD-Lite2 CSRG/disk3/rr_moved CSRG/disk4/Contrib CD-ROM #4 - Final /usr/src including SCCS files CSRG/disk4/Makefile CSRG/disk4/README CSRG/disk4/SCCS CSRG/disk4/admin CSRG/disk4/bin CSRG/disk4/contrib CSRG/disk4/etc CSRG/disk4/games CSRG/disk4/include CSRG/disk4/lib CSRG/disk4/libexec CSRG/disk4/local CSRG/disk4/old CSRG/disk4/rr_moved CSRG/disk4/sbin CSRG/disk4/share CSRG/disk4/sys CSRG/disk4/usr.bin CSRG/disk4/usr.sbin CSRG/historic1/32v Various historic UNIX distributions CSRG/historic1/630src not from Berkeley CSRG/historic1/S3 CSRG/historic1/S5_1 CSRG/historic1/S5_1.purdue CSRG/historic1/S5_2.0 CSRG/historic1/S5_3.0 CSRG/historic1/S5_3.2 CSRG/historic1/S5_4.0 CSRG/historic1/TOOLS CSRG/historic1/Vax.Toy CSRG/historic1/brl.pdp11 CSRG/historic1/cpio CSRG/historic1/cpio.contrib CSRG/historic1/dmd CSRG/historic1/dwb CSRG/historic1/pdp.archive CSRG/historic1/pwb.1 CSRG/historic1/pwb.2 CSRG/historic1/pwb.3 CSRG/historic1/rr_moved CSRG/historic1/sccscmds CSRG/historic1/terminfo CSRG/historic1/toolchest CSRG/historic1/u3g CSRG/historic1/ultrix11 CSRG/historic1/unisis CSRG/historic1/usenix CSRG/historic1/v5 CSRG/historic1/v6 CSRG/historic1/v6.compat CSRG/historic1/v7 CSRG/historic1/v7add CSRG/historic1/v7m CSRG/historic2/CP Programs and other operating systems that CSRG/historic2/IBM-PCTS shipped on or influenced BSD CSRG/historic2/NIST-PCTS CSRG/historic2/NeWS CSRG/historic2/afio CSRG/historic2/apl CSRG/historic2/appletalk CSRG/historic2/arch.81 CSRG/historic2/autochanger CSRG/historic2/bib CSRG/historic2/bind CSRG/historic2/brunhoff.rfs CSRG/historic2/cci CSRG/historic2/cis111 CSRG/historic2/coherent CSRG/historic2/convex.stripe CSRG/historic2/courier CSRG/historic2/cpm CSRG/historic2/csh CSRG/historic2/decvax CSRG/historic2/dfs CSRG/historic2/document CSRG/historic2/drivers CSRG/historic2/dsh CSRG/historic2/dual.purdue CSRG/historic2/egp CSRG/historic2/enet CSRG/historic2/fortran CSRG/historic2/harris CSRG/historic2/hawley.db CSRG/historic2/help CSRG/historic2/hyper CSRG/historic2/icon CSRG/historic2/kermit.6.85 CSRG/historic2/lincs CSRG/historic2/local.cmd CSRG/historic2/lpr.basic CSRG/historic2/mach CSRG/historic2/mh CSRG/historic2/minix CSRG/historic2/mmdf CSRG/historic2/mon CSRG/historic2/multiflow CSRG/historic2/nachos CSRG/historic2/named CSRG/historic2/net.driver CSRG/historic2/netfs CSRG/historic2/news CSRG/historic2/nqs CSRG/historic2/occam CSRG/historic2/proc.control CSRG/historic2/prolog.tahoe CSRG/historic2/pup CSRG/historic2/rand CSRG/historic2/rcs-V4 CSRG/historic2/rdb.debug CSRG/historic2/rogue3.6 CSRG/historic2/rr_moved CSRG/historic2/soft.tool.mail CSRG/historic2/spms CSRG/historic2/sprite CSRG/historic2/sprite-1.096 CSRG/historic2/srogue CSRG/historic2/sumacc CSRG/historic2/sup CSRG/historic2/tcp.bbn CSRG/historic2/tcp.sri CSRG/historic2/text CSRG/historic2/umodem CSRG/historic2/usl.lawsuit CSRG/historic2/vaxima CSRG/historic2/versatec CSRG/historic2/vims CSRG/historic2/warp CSRG/historic2/worm CSRG/historic2/xinu CSRG/svnrepo/COPYRIGHT A copy of John Baldwin's conversion of the CSRG/svnrepo/README SCCS database contained on the original disk4 CSRG/svnrepo/svn to a Subversion repository CSRG/Admin/Missing SCCS login IDs with unknown user name CSRG/Admin/Names the mapping from SCCS login ID to user name CSRG/Admin/README CSRG/Admin/USL_Agreement Feb 1994 agreement between USL and UCB CSRG/Admin/mkiso the script for building this DVD image From reed at reedmedia.net Thu Jan 17 23:19:06 2019 From: reed at reedmedia.net (reed at reedmedia.net) Date: Thu, 17 Jan 2019 07:19:06 -0600 (CST) Subject: [TUHS] Old Unix source code DVD [was: V6 networking & alarm syscall] In-Reply-To: <31335EFC-09CE-4286-9358-87B5F74D2004@planet.nl> References: <921E58F1-1631-4390-8CCD-52EE0238B241@planet.nl> <31335EFC-09CE-4286-9358-87B5F74D2004@planet.nl> Message-ID: On Thu, 17 Jan 2019, Paul Ruizendaal wrote: > I just discovered that Kirk McKusick has made a new DVD that covers a > much broader set of software than his earlier 4 CD set: > https://www.mckusick.com/csrg/ > (see bottom of the page, one but last paragraph). > > This new DVD includes the surviving BBN VAX TCP source code; it is not > on the earlier 4 CD set. Is there a list of the DVD's contents? I didn't see any details of this on the webpage. (I have the four CD-ROM set which does have some of the BBN code.) From clemc at ccc.com Fri Jan 18 00:38:14 2019 From: clemc at ccc.com (Clem Cole) Date: Thu, 17 Jan 2019 09:38:14 -0500 Subject: [TUHS] Old Unix source code DVD [was: V6 networking & alarm syscall] In-Reply-To: References: <921E58F1-1631-4390-8CCD-52EE0238B241@planet.nl> <31335EFC-09CE-4286-9358-87B5F74D2004@planet.nl> Message-ID: Jeremy, A few of us are trying to unravel some of the mysteries of what is what. The original 4 CD's has an early version of the TCP stack from BBN (although the provenance of same is not exactly clear). That is the code that Warren has in the archives. Since he originally published the CD Kirk obtained some other things (as Paul mentioned). Paul and I are both trying to sift through what Kirk has, although again provenance is unfortunately not as clean as we would like. The bad news is that Rob Gurwitz (was the original author of the BBN IP/TCP stack) does not seem to have tapes himself and has pointed Paul and I at Kirk's archives for now. The question is can we figure out what it what. Paul has done a great job of looking at some old DARPA qtr reports that BBN sent to ARPA that helps to put some structure around some of this. Then using dates from there and some of the files, plus the memory of some of the protagonists involved, we can try to sort it out. We'll let you all know what we learn ASAP. FWIW: Folks have been helping Warren get it right in his pages. For instance, his old page on the BBN TCP, had some wording that was easy to misconstrue. That data is being clarified so the reader does not in-advertently rewrite history. We'll continue to do that when we can. I do hope that when the dust settles, we see the historical archives as complete and correct as possible. Clem ᐧ On Thu, Jan 17, 2019 at 8:20 AM wrote: > On Thu, 17 Jan 2019, Paul Ruizendaal wrote: > > > I just discovered that Kirk McKusick has made a new DVD that covers a > > much broader set of software than his earlier 4 CD set: > > https://www.mckusick.com/csrg/ > > (see bottom of the page, one but last paragraph). > > > > This new DVD includes the surviving BBN VAX TCP source code; it is not > > on the earlier 4 CD set. > > Is there a list of the DVD's contents? I didn't see any details of this > on the webpage. (I have the four CD-ROM set which does have some of > the BBN code.) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wkt at tuhs.org Fri Jan 18 05:33:36 2019 From: wkt at tuhs.org (Warren Toomey) Date: Fri, 18 Jan 2019 05:33:36 +1000 Subject: [TUHS] Old Unix source code DVD [was: V6 networking & alarm syscall] In-Reply-To: References: <921E58F1-1631-4390-8CCD-52EE0238B241@planet.nl> <31335EFC-09CE-4286-9358-87B5F74D2004@planet.nl> Message-ID: <20190117193336.GA4668@minnie.tuhs.org> > On Thu, 17 Jan 2019, Paul Ruizendaal wrote: > > I just discovered that Kirk McKusick has made a new DVD that covers a > > much broader set of software than his earlier 4 CD set: On Thu, Jan 17, 2019 at 07:19:06AM -0600, reed at reedmedia.net wrote: > Is there a list of the DVD's contents? I didn't see any details of this > on the webpage. (I have the four CD-ROM set which does have some of > the BBN code.) Have a look here: https://www.tuhs.org/Archive/Documentation/CSRG_CDs/ Cheers, Warren From reed at reedmedia.net Fri Jan 18 06:00:01 2019 From: reed at reedmedia.net (reed at reedmedia.net) Date: Thu, 17 Jan 2019 14:00:01 -0600 (CST) Subject: [TUHS] Old Unix source code DVD [was: V6 networking & alarm syscall] In-Reply-To: <20190117193336.GA4668@minnie.tuhs.org> References: <921E58F1-1631-4390-8CCD-52EE0238B241@planet.nl> <31335EFC-09CE-4286-9358-87B5F74D2004@planet.nl> <20190117193336.GA4668@minnie.tuhs.org> Message-ID: On Fri, 18 Jan 2019, Warren Toomey wrote: > On Thu, Jan 17, 2019 at 07:19:06AM -0600, reed at reedmedia.net wrote: > > Is there a list of the DVD's contents? I didn't see any details of this > > on the webpage. (I have the four CD-ROM set which does have some of > > the BBN code.) > > Have a look here: > https://www.tuhs.org/Archive/Documentation/CSRG_CDs/ Thanks! Sorry I sent my question before reading other threads :) I see there is a discount if already purchased the older set. Thanks for info From scj at yaccman.com Fri Jan 18 10:55:43 2019 From: scj at yaccman.com (Steve Johnson) Date: Thu, 17 Jan 2019 16:55:43 -0800 Subject: [TUHS] Knuth and Unix In-Reply-To: Message-ID: <3afa277677b7d3d9f90382bec46541fbf17aed83@webmail.yaccman.com> As I remember, the original EQN grammar had >300 S/R conflicts and 50 or so RR conflicts.  But it mostly did what you wanted.  I think Al Aho got faint when he looked it it, though...  (It got better when precedence was added...) Steve ----- Original Message ----- From: "Rob Pike" To: Cc:, Sent:Thu, 17 Jan 2019 07:10:58 +1100 Subject:Re: [TUHS] Knuth and Unix I was speaking in jest... But the (official) awk grammar has been an eye-opener for years. -rob On Thu, Jan 17, 2019 at 5:22 AM wrote: > > You can't lay the blame for that on Steve. > > The GNU Awk grammar has only 36 shift-reduce conflicts and no > reduce-reduce conflicts. > > The mawk 1.3.4 grammar has an amazing count of only *four* shift-reduce > conflicts. (But then, Mike Brennan is an amazing programmer.) > > I have no idea what happens if you run the POSIX awk grammar through > yacc / bison, but it'd be an interesting experiment. > > Arnold > > Rob Pike wrote: > > > So you're the reason (Plan 9) awk has 83 reduce-reduce conflicts (and > > 42 shift-reduce). > > > > -rob > > > > On Wed, Jan 16, 2019 at 9:39 AM Steve Johnson wrote: > > > > > > I remember reading Knuth's paper, and certainly heard DeRemer's name, but it didn't affect much of what I did. There was a paper out of Stanford about that time that influenced me greatly -- it was about pattern matching languages, and proposed separating two ideas: 1. "Here are the patterns that match this tree". And 2. "If more than one pattern matches, here's how to decide which one to use." Given the constraints of size on the PDP 11, anything but LR(1) was infeasable. But using ambiguous grammars and broadening the shift/reduce test to trest operator precedence fit right into that pattern. Another thing that I think was unique to Yacc at the time was introducing symbols that matched the empty string whose reduction caused program actions. Many similar parser systems at the time could not deal with these "empty" symbols. > > > > > > Steve > > > > > > > > > > > > ----- Original Message ----- > > > From: "Bakul Shah" > > > To:"Steve Johnson" > > > Cc:, , , > > > Sent:Sat, 12 Jan 2019 20:40:11 -0800 > > > Subject:Re: [TUHS] Knuth and Unix > > > > > > > > > On Sat, 12 Jan 2019 19:41:26 -0800 "Steve Johnson" wrote: > > > > One connection Knuth had to Unix was inventing LALR parsing, the basic > > > > algorithm used in Yacc. I added some things (notably, the precedence > > > > mechanism) and had to do a lot of engineering to be able to handle large > > > > grammars (e.g. F77) on a PDP-11. But the underlying algorithm (taught to > > > > my be Al Aho) was all Knuth. > > > > > > Knuth invented LR parsing but IIRC it was DeRemer who came up > > > with LALR parsing. In 78-79 I was implementing a LALR(1) > > > parser generator in Pascal on strength of which I got my first > > > real job. At that job I used DeRemer and Pennello's 1979 > > > paper to reimplement the parser generator. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From web at loomcom.com Sat Jan 19 02:20:24 2019 From: web at loomcom.com (Seth J. Morabito) Date: Fri, 18 Jan 2019 08:20:24 -0800 Subject: [TUHS] Wanted: AT&T System V Release 3.2.{1,2,3} Source Code Message-ID: <87lg3iey47.fsf@loomcom.com> [Cross-posted from the 3B2 mailing list] Hi folks, I'm in search of source code for AT&T's System V Release 3.2.1, 3.2.2, and/or 3.2.3 for the 3B2. Does this exist? Has anyone ever seen it? Note that I'm not looking for the System V Release 3.2 Source Code Provision for the 3B2 /310 and /400 -- I already have that. It was absolutely invaluable when I was writing my 3B2/400 emulator. The reason I'm so keen on getting access is that I have ROM images from a 3B2/1000, and I'd like to add support for it to my 3B2 emulator. The system board memory map seems a bit different than the /300, /310, and /400. These max out at SVR 3.2. I can't imagine trying to add 3B2/1000 support without the 3.2.x source code. I imagine there's some tape image somewhere that's a delta of files that take you from 3.2 to 3.2.1, 3.2.2 or 3.2.3? -Seth -- Seth Morabito Poulsbo, WA, USA web at loomcom.com From scj at yaccman.com Sat Jan 19 07:57:04 2019 From: scj at yaccman.com (Steve Johnson) Date: Fri, 18 Jan 2019 13:57:04 -0800 Subject: [TUHS] Knuth and Unix In-Reply-To: <20190116205043.21C22156E410@mail.bitblocks.com> Message-ID: <30735aec554140bc4c98c14fe18be5b7ac1fff66@webmail.yaccman.com> The paper  was called "The Competence/Performance Dichotomy" by Pratt.  He borrowed an idea from Chompsky and distinguished between being able to understand something and being able to produce it.  The idea I took from it was to recognize grammar rules even if the parse was ambiguous and then use other mechanisms (e.g., Shift/Reduce, precedence) to decide what to do. About empty productions: one of the most useful versions of this was in handling scopes in programming languages, especially in C where xyz could be a variable in one scope and a typedef in an inner one, or vice versa.  The empty production could get called at the right moment to make the appropriate symbol table fixes, where otherwise we would have had a syntax error. Steve ----- Original Message ----- From: "Bakul Shah" To:"Steve Johnson" Cc:, , , Sent:Wed, 16 Jan 2019 12:50:35 -0800 Subject:Re: [TUHS] Knuth and Unix On Tue, 15 Jan 2019 14:32:16 -0800 "Steve Johnson" wrote: > I remember reading Knuth's paper, and certainly heard > DeRemer's name, but it didn't affect much of what I did. > There was a paper out of Stanford about that time that > influenced me greatly -- it was about pattern matching > languages, and proposed separating two ideas: 1. "Here are > the patterns that match this tree". And 2. "If more than one > pattern matches, here's how to decide which one to use." > Given the constraints of size on the PDP 11, anything but > LR(1) was infeasable. But using ambiguous grammars and > broadening the shift/reduce test to trest operator precedence > fit right into that pattern. Another thing that I think was > unique to Yacc at the time was introducing symbols that > matched the empty string whose reduction caused program > actions. Many similar parser systems at the time could not > deal with these "empty" symbols. Good to know all this. The Stanford paper you refer, would that be "fast pattern matching" by Knuth, Morris & Pratt? I remember struggling with empty strings and I also missed other yacc tricks. In my formulation I had two kinds of rules: set rules and sequence rules. Set rules avoided unnecessary reductions in rules such as foo: bar|... For example: // sets expr = relexpr | expr1 expr1 = addexpr | expr2 expr2 = mulexpr | expr3 ... // sequences relexpr: expr1 RELOP expr1 addexpr: expr1 ('+'|'-') expr2 mulexpr: expr2 ('*'|'/') expr3 ... Basically I completely avoided empty symbols -- even an empty file has an EOF! [I didn't try it on anything more complicated than (extended) Pascal so no idea how it would have fared on complexificated lanuages] -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.bowling at kev009.com Sun Jan 20 00:09:56 2019 From: kevin.bowling at kev009.com (Kevin Bowling) Date: Sat, 19 Jan 2019 07:09:56 -0700 Subject: [TUHS] Wanted: AT&T System V Release 3.2.{1,2,3} Source Code In-Reply-To: <87lg3iey47.fsf@loomcom.com> References: <87lg3iey47.fsf@loomcom.com> Message-ID: I believe there is a sysvr4 source dump floating around with the 3b2 base On Fri, Jan 18, 2019 at 9:21 AM Seth J. Morabito wrote: > > [Cross-posted from the 3B2 mailing list] > > Hi folks, > > I'm in search of source code for AT&T's System V Release 3.2.1, 3.2.2, > and/or 3.2.3 for the 3B2. Does this exist? Has anyone ever seen it? > > Note that I'm not looking for the System V Release 3.2 Source Code > Provision for the 3B2 /310 and /400 -- I already have that. It was > absolutely invaluable when I was writing my 3B2/400 emulator. > > The reason I'm so keen on getting access is that I have ROM images from > a 3B2/1000, and I'd like to add support for it to my 3B2 emulator. The > system board memory map seems a bit different than the /300, /310, and > /400. These max out at SVR 3.2. > > I can't imagine trying to add 3B2/1000 support without the 3.2.x source > code. > > I imagine there's some tape image somewhere that's a delta of files that > take you from 3.2 to 3.2.1, 3.2.2 or 3.2.3? > > -Seth > -- > Seth Morabito > Poulsbo, WA, USA > web at loomcom.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From web at loomcom.com Sun Jan 20 10:08:43 2019 From: web at loomcom.com (Seth J. Morabito) Date: Sat, 19 Jan 2019 16:08:43 -0800 Subject: [TUHS] Wanted: AT&T System V Release 3.2.{1,2,3} Source Code In-Reply-To: References: <87lg3iey47.fsf@loomcom.com> Message-ID: <87va2kdwc4.fsf@loomcom.com> Kevin Bowling writes: > I believe there is a sysvr4 source dump floating around with the 3b2 > base It turns out, you're quite right! I originally had an SVR4 dump from who knows where that did not contain the /usr/src/uts/3b2 directory, but I recently was the benefactor of *another* dump. This time, it looks like the real deal. /usr/src/uts/3b2 is there in all its glory. This is probably all I need to get going. All the best, -Seth -- Seth Morabito Poulsbo, WA, USA web at loomcom.com From kevin.bowling at kev009.com Sun Jan 20 19:01:25 2019 From: kevin.bowling at kev009.com (Kevin Bowling) Date: Sun, 20 Jan 2019 02:01:25 -0700 Subject: [TUHS] Wanted: AT&T System V Release 3.2.{1,2,3} Source Code In-Reply-To: <87va2kdwc4.fsf@loomcom.com> References: <87lg3iey47.fsf@loomcom.com> <87va2kdwc4.fsf@loomcom.com> Message-ID: As far as I could find, the binary distribution is not readily available (and maybe /was/ not readily available, this seemed to be late enough to just be a code dump for source licensees). It would be fun to try and build this into a useable release, but I have not yet determined if everything is there as well as if a 3.2 system can hoist the build. On Sat, Jan 19, 2019 at 5:15 PM Seth J. Morabito wrote: > > Kevin Bowling writes: > > > I believe there is a sysvr4 source dump floating around with the 3b2 > > base > > It turns out, you're quite right! > > I originally had an SVR4 dump from who knows where that did not contain > the /usr/src/uts/3b2 directory, but I recently was the benefactor of > *another* dump. This time, it looks like the real deal. /usr/src/uts/3b2 > is there in all its glory. > > This is probably all I need to get going. > > All the best, > > -Seth > -- > Seth Morabito > Poulsbo, WA, USA > web at loomcom.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnold at skeeve.com Mon Jan 21 00:35:46 2019 From: arnold at skeeve.com (arnold at skeeve.com) Date: Sun, 20 Jan 2019 07:35:46 -0700 Subject: [TUHS] Wanted: AT&T System V Release 3.2.{1,2,3} Source Code In-Reply-To: References: <87lg3iey47.fsf@loomcom.com> <87va2kdwc4.fsf@loomcom.com> Message-ID: <201901201435.x0KEZkbj009115@freefriends.org> If it'd be possible to run SVr4 on the 3B2 emulator, that'd be really cool, particularly if there's a C compiler available. That would give us long filenames and the possible ability to bootstrap some version of GCC for C89 compatibility, and from there, maybe, to more modern tools. Otherwise, I can't imagine (anymore) trying to do anything on a system with only 14 character filenames. Arnold Kevin Bowling wrote: > As far as I could find, the binary distribution is not readily available > (and maybe /was/ not readily available, this seemed to be late enough to > just be a code dump for source licensees). > > It would be fun to try and build this into a useable release, but I have > not yet determined if everything is there as well as if a 3.2 system can > hoist the build. > > On Sat, Jan 19, 2019 at 5:15 PM Seth J. Morabito wrote: > > > > > Kevin Bowling writes: > > > > > I believe there is a sysvr4 source dump floating around with the 3b2 > > > base > > > > It turns out, you're quite right! > > > > I originally had an SVR4 dump from who knows where that did not contain > > the /usr/src/uts/3b2 directory, but I recently was the benefactor of > > *another* dump. This time, it looks like the real deal. /usr/src/uts/3b2 > > is there in all its glory. > > > > This is probably all I need to get going. > > > > All the best, > > > > -Seth > > -- > > Seth Morabito > > Poulsbo, WA, USA > > web at loomcom.com > > From arnold at skeeve.com Thu Jan 31 02:22:51 2019 From: arnold at skeeve.com (arnold at skeeve.com) Date: Wed, 30 Jan 2019 09:22:51 -0700 Subject: [TUHS] qed-archive - please reclone Message-ID: <201901301622.x0UGMpP0028555@freefriends.org> Hi All. I had a bad commit message in the qed-archive I mentioned here a few weeks ago. I fixed it with a 'git push --force' (even though that's not recommended) since I expect it to be a read-only archive going forward, and I wanted it to be right. In short, if you cloned it, please remove your copy and reclone. Thanks! Arnold From mutiny.mutiny at india.com Thu Jan 31 05:14:56 2019 From: mutiny.mutiny at india.com (Donald ODona) Date: Wed, 30 Jan 2019 19:14:56 +0000 (UTC) Subject: [TUHS] qed-archive - please reclone In-Reply-To: <201901301622.x0UGMpP0028555@freefriends.org> References: <201901301622.x0UGMpP0028555@freefriends.org> Message-ID: <1193928668.145015.1548875695952.JavaMail.tomcat@india-live-be04> At 30 Jan 2019 16:24:09 +0000 (+00:00) from arnold at skeeve.com: > Hi All. > > I had a bad commit message in the qed-archive I mentioned here a few weeks > > Arnold I cloned & tar'ed it. If any trouble (broken source or something), just mail me. From steffen at sdaoden.eu Thu Jan 31 05:16:34 2019 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Wed, 30 Jan 2019 20:16:34 +0100 Subject: [TUHS] qed-archive - please reclone In-Reply-To: <201901301622.x0UGMpP0028555@freefriends.org> References: <201901301622.x0UGMpP0028555@freefriends.org> Message-ID: <20190130191634.ExRH-%steffen@sdaoden.eu> arnold at skeeve.com wrote in <201901301622.x0UGMpP0028555 at freefriends.org>: |Hi All. | |I had a bad commit message in the qed-archive I mentioned here a few weeks |ago. I fixed it with a 'git push --force' (even though that's not |recommended) since I expect it to be a read-only archive going forward, |and I wanted it to be right. | |In short, if you cloned it, please remove your copy and reclone. Just "fetch -f" over your "push -f" commits, no need to reclone. --End of <201901301622.x0UGMpP0028555 at freefriends.org> --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 rich.salz at gmail.com Thu Jan 31 05:51:02 2019 From: rich.salz at gmail.com (Richard Salz) Date: Wed, 30 Jan 2019 11:51:02 -0800 Subject: [TUHS] Archeology: AberMUD, BCPL, ec. Message-ID: Some folks are trying to figure out how to get AberMud source online and working; see https://twitter.com/larsbrinkhoff/status/1056823314272960512 Sample code at https://raw.githubusercontent.com/larsbrinkhoff/abermud/master/abermud1/text/timelock.b -------------- next part -------------- An HTML attachment was scrubbed... URL: From alec.muffett at gmail.com Thu Jan 31 17:15:36 2019 From: alec.muffett at gmail.com (Alec Muffett) Date: Thu, 31 Jan 2019 07:15:36 +0000 Subject: [TUHS] Archeology: AberMUD, BCPL, ec. In-Reply-To: References: Message-ID: Has anyone ever attempted to OCR a video, perhaps by breaking into frames and then aggregating the results, using multiple frames to correct each other? On Wed, 30 Jan 2019, 19:51 Richard Salz Some folks are trying to figure out how to get AberMud source online and > working; see https://twitter.com/larsbrinkhoff/status/1056823314272960512 > > Sample code at > https://raw.githubusercontent.com/larsbrinkhoff/abermud/master/abermud1/text/timelock.b > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lars at nocrew.org Thu Jan 31 17:28:09 2019 From: lars at nocrew.org (Lars Brinkhoff) Date: Thu, 31 Jan 2019 07:28:09 +0000 Subject: [TUHS] Archeology: AberMUD, BCPL, ec. In-Reply-To: (Alec Muffett's message of "Thu, 31 Jan 2019 07:15:36 +0000") References: Message-ID: <7w36p9uvzq.fsf@junk.nocrew.org> Alec Muffett wrote: > Has anyone ever attempted to OCR a video, perhaps by breaking into > frames and then aggregating the results, using multiple frames to > correct each other? I had in mind to just manually pick a good frame for each page and type it in by hand. I have tried to OCR program listings before, with rather poor results.