From steffen at sdaoden.eu Sun Sep 1 01:14:10 2019 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Sat, 31 Aug 2019 17:14:10 +0200 Subject: [TUHS] If not Linux, then what? In-Reply-To: References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net> <20190828231952.GA536@mit.edu> <3173aba3-b6c3-43db-6374-b600f3217f13@kilonet.net> <004ec49789583b190ca7c302db9fbb31@firemail.de> <20190829191943.BfJ86%steffen@sdaoden.eu> Message-ID: <20190831151410.uywnr%steffen@sdaoden.eu> Hello. Dave Horsfall wrote in : |On Thu, 29 Aug 2019, Steffen Nurpmeso wrote: |>|Today however not in the 80ths. Inn those days all 4 cars were Richie \ |>|Rich cars. |> |> And only the Mazda had that wonderful smooth engine which replaces |> pounding pistons with nice chuckling triangles. | |[ Getting OT... ] Yes, sorry for that. |Too bad about the seals, though... They had this habit of wearing out. I do not think this is actually true. I think it was "not false" for the first series of the NSU Ro80 at the beginning of the 70s, but materials engineering is what made such unbelievable progress ever since, it always leaves me just speechless. "Not false" in that it likely was dependent on the way of driving even back then. I definitely have heard stories of people still driving Ro80 first series, original. And for later ones, say Mazda RX-8, i think it is a problem of the past, anyway. I just looked, and Mazda finally gave 100000 Miles guarantee for the seals. I mean, in the end these are industry products which compete in a surrounding market, and i do not mean this positively. For example, the Lenovo laptop i bought this year grants itself a four year lifetime (states the manual for the Russian market, for which such statements seem to be required). The problem of the Wankelmotor is the form of the combustion chamber, which is even worse than for the Otto (or Diesel) piston engine, even less spherical. Modern injection systems and electronical management can overcome this a bit. You know, i will never forget the IAA (car exhibition in Frankfurt/Main Germany) either at the end of the 80s or the beginning of the 90s, where Toyota shewed high-speed videos of the combustion process. It was rather trial-and-error before, with a lot of things tried (piston forms, multiple spark plugs, electronical spark control), but Toyota came up with diet mix engines at that time, and started to use direct injection (iirc). This is not new, i think we had that already for fighter plane engines in WWII, but it was trial and error. With those videos and better gauges the combustion process was better understood, and resulted in improved efficiency and exhaustion behaviour. I was surprised that the Atkinson engine which drives at least the Honda and Toyota Hybrid cars does not use direct injection, but rather the suction line one again, but it is the end of decades of science and exploration, right. Some Atkinson engines use a mixed injection that also includes direct injection it seems (Lexus?). --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From clemc at ccc.com Sun Sep 1 01:41:40 2019 From: clemc at ccc.com (Clem Cole) Date: Sat, 31 Aug 2019 11:41:40 -0400 Subject: [TUHS] dmr streams & networking [was: Re: If not Linux, then what?] In-Reply-To: References: Message-ID: It's the Mentant implementation that HP originally bought. At LCC we had to hacked on it a bit when we put Transparent Network Computing (TNC) stuff in HP-UX [we had full process migration working BTW -- A real shame that never shipped]. On Sat, Aug 31, 2019 at 5:44 AM Rudi Blom wrote: > Whenever I hear UNIX, networking and streams I have to think about this > scheme. > > Still using this, even on HP-UX 11.31 on Itanium rx-servers > > Cheers, > uncle rubl > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rminnich at gmail.com Sun Sep 1 02:00:24 2019 From: rminnich at gmail.com (ron minnich) Date: Sat, 31 Aug 2019 09:00:24 -0700 Subject: [TUHS] early vm systems In-Reply-To: References: Message-ID: On Sat, Aug 31, 2019 at 5:05 AM Thomas Paulsen wrote: > > > --- Ursprüngliche Nachricht --- > Von: Steve Simon > Datum: 31.08.2019 11:44:22 > An: tuhs at minnie.tuhs.org > Betreff: [TUHS] early vm systems > > > hi > > > > the other early vm system not mentioned yet is the one Charles Forsyth wrote > > at the university of york for sunos. i never used it as i was learning v7 > > on an interdata 30 miles away at the time but i read his excellent paper > > on it. > did you mean: https://www.researchgate.net/publication/2411547_The_Mether_System_Distributed_Shared_Memory_for_SunOS_40 no, that was me :-) charles' excellent paper, "More Taste: Less Greed? or Sending UNIX to the Fat Farm", http://www.terzarima.net/doc/taste.pdf is a good read, as is everything he writes. From cbbrowne at gmail.com Sun Sep 1 02:58:00 2019 From: cbbrowne at gmail.com (Christopher Browne) Date: Sat, 31 Aug 2019 12:58:00 -0400 Subject: [TUHS] If not Linux, then what? In-Reply-To: <20190828231952.GA536@mit.edu> References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net> <20190828231952.GA536@mit.edu> Message-ID: On Wed, 28 Aug 2019 at 19:19, Theodore Y. Ts'o wrote: > On Wed, Aug 28, 2019 at 04:07:39PM -0400, Christopher Browne wrote: > > > > - Hurd was imagined to be the next thing... > > > > To borrow from my cookie file... > > > > "I am aware of the benefits of a micro kernel approach. However, the > > fact remains that Linux is here, and GNU isn't --- and people have > > been working on Hurd for a lot longer than Linus has been working on > > Linux." -- Ted T'so, 1992. > > That's "Ts'o" :-), and that quote wasn't my arguing that Hurd would be > the next thing. It was people had been working on the Hurd for > *years* (starting 1984) and it still wasn't real. If it wasn't going > to be real after eight years, another eighty probably wouldn't have > helped. > Thanks, patched! :-) And yes, I agree that you weren't arguing for the impending relevance of Hurd. Nevertheless, at the time, there were people making the argument that Hurd would Real Soon Now make Linux irrelevant. > And a lot of this was because was because RMS was hard to work with, > and he was a purist. Pretty much very *definition* of the perfect > should always be the enemy of the "good enough". > > In fact, at one point Thomas Bushnell, one of the senior Hurd > developers pushed to have the Hurd switch to using BSD 4.4-Lite, and > Stallman refused[1]. > > “RMS was a very strong believer, wrongly, I think, in a very greedy > algorithm approach to code reuse issues,” Thomas Bushnell later > remembered. > > “My first choice was to take the BSD 4.4-Lite release and make a > kernel. I knew the code, I knew how to do it. It is now perfectly > obvious to me that this would have succeeded splendidly and the > world would be a very different place today. RMS wanted to work together with people from Berkeley on such an effort. Some of them > were interested, but some seem to have been deliberately dragging > their feet: and the reason now seems to be that they had the goal > of spinning off BSDI. A GNU based on 4.4-Lite would undercut BSDI.” > > As Bushnell describes it, Stallman came to the conclusion that > “Mach is a working kernel. 4.4-Lite is only partial. We will go > with Mach.” > > [1] > https://web.archive.org/web/20121228225905/http://www.linuxuser.co.uk/features/whatever-happened-to-the-hurd-the-story-of-the-gnu-os I haven't seen reference to Bushnell in a long time; looks like he has shifted to ecclesiastical matters. He was up to some interesting software things, once upon a time. The tales of Stallman being stubborn are not rare. It's interesting that perhaps BSDI was a reason for GNU avoiding 4.4-Lite. That points to why the "what might have been" is very troublesome to track down. Alternatives always interact with one another... > That's probably one of the other things that may have hampered BSD. > The BSD license made it easier (or at least made easier business > models) for monetizing BSD, and some of the most talented people went > off to make a buck off of BSD. BSDI, Sun, NetApp, Wasabi Systems, etc. > > Nothing wrong with that of course, and if people like Bill Joy were > able to make bank based on BSD, more power to them. But it probably > removed from the leadership pool people who might have had better > leadership, and technical architect skills who might have led one of > the *BSD's to greater success. > > The GPL makes it harder to monetize Linux --- although, as we've seen, > certainly not impossible --- and if you take a look at the most of the > senior technical people at Linux, none of us have made off as well as, > say, Bill Joy. I'm still a working stiff, and don't have enough to > retire. (That's OK; I'm perfectly happy being part of the 99%. :-) > > > Anyway, Hurd *might* have been a "next thing," and I don't think the > > popularity of Linux was enough to have completely taken wind out of its > > sails, given that there's the dozens of "Unix homages" out there. > > Given who called the shots (and it wasn't the key people actually > doing most of the technical work, such as Bushnell) I actually think > it's not very likely Hurd could have succeeded. RMS actually tried to > recruit me to work on the Hurd as well, and I refused, because of > project leadership concerns. (Again, feel free to hate on Linus's > management style, but there were far worse ones in the open source OS > world at the time.) > > - Ted > Yeah, there's dysfunction everywhere :-). Over the years, I have heard BSD folk blasting Linux over Linus' occasional lack of tact; that is very much a road MORE travelled by a great many projects. Hurd's challenges starved it of staff, definitely unhelpful. BSD had both amicable as well as ridiculously non-amicable forks. It's not at trivial to get the right balance and plenty easy for missteps to lead to disaster. As vast overgeneralizations of the extremes, pure diplomats don't get anything done, whilst jerks don't get enough help to support upgrading to the next generation of motherboards/disk drives/graphics cards. Successful systems fall somewhere in between. -- When confronted by a difficult problem, solve it by reducing it to the question, "How would the Lone Ranger handle this?" -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Sun Sep 1 04:27:33 2019 From: imp at bsdimp.com (Warner Losh) Date: Sat, 31 Aug 2019 12:27:33 -0600 Subject: [TUHS] early vm systems In-Reply-To: References: Message-ID: On Sat, Aug 31, 2019 at 10:01 AM ron minnich wrote: > On Sat, Aug 31, 2019 at 5:05 AM Thomas Paulsen > wrote: > > > > > > --- Ursprüngliche Nachricht --- > > Von: Steve Simon > > Datum: 31.08.2019 11:44:22 > > An: tuhs at minnie.tuhs.org > > Betreff: [TUHS] early vm systems > > > > > hi > > > > > > the other early vm system not mentioned yet is the one Charles Forsyth > wrote > > > at the university of york for sunos. i never used it as i was learning > v7 > > > on an interdata 30 miles away at the time but i read his excellent > paper > > > on it. > > did you mean: > https://www.researchgate.net/publication/2411547_The_Mether_System_Distributed_Shared_Memory_for_SunOS_40 > > > no, that was me :-) > > charles' excellent paper, > "More Taste: Less Greed? > or > Sending UNIX to the Fat Farm", http://www.terzarima.net/doc/taste.pdf > > is a good read, as is everything he writes. > It is a good read... Is Charles Forsyth's code available? Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Sun Sep 1 05:03:46 2019 From: clemc at ccc.com (Clem Cole) Date: Sat, 31 Aug 2019 15:03:46 -0400 Subject: [TUHS] dmr streams & networking [was: Re: If not Linux, then what?] In-Reply-To: References: <1567196510.21824.for-standards-violators@oclsc.org> <20190830215202.GA974@mcvoy.com> <20190831011359.E9F491570CE9@mail.bitblocks.com> <88242A0D-D08E-47EB-84DC-A7205780A417@ccc.com> Message-ID: On Sat, Aug 31, 2019 at 1:38 AM Dave Horsfall wrote: > Yep, that certainly rings a bell. ISTR that Sun had a board with the two > CPUs, one keeping an eye on the other. Interesting, I was under the belief that Sun never even tried the trick (at least as a product). The original Stanford University Network (SUN) CPU was built for an Intel Multibus (electrically and mechanically) but using a single 68000 instead of an Intel processor. The 'SUN' was designed by one of Forest's graduate students (Andy Bechtolsheim ); and the University licensed the design extremely cheaply throughout the valley (VLSI Tech, *a.k.a.* Sun Microsystems, was only one of the licensees. But for instance the original Cisco AGS and the Imagen Laser printers both used CPU's licensed from the Unversity). FWIW: I knew Andy at CMU previously, he had designed a similar board for the CMU front-end as I was leaving for Tektronix - when I was there we used LSI-11s and Andy replaced that with an 8085 (then 8086) based Multibus [IIRC, Phil Karn may have mixed up in all that too - he was hacking on what would become KA9Q TCP on his Z80 and then the 8085. We had all taken the graduate realtime course from Steely Dan as lab partners and our big project was based on hacks to that hardware]. That said, it was Forest that proposed the executor/fixer trick (as I say he gave a paper at an Asilomar Microprocessor Conference which I have sadly misplaced). It is certainly possible that Andy tried building it, but the only two firms that I know of that built processors using the idea were Apollo and Masscomp (neither who used or licensed the SUN CPU design from Stanford) although all of them used a flavor of the Multibus as their first bus. I don't know what Apollo did. The multibus mechanically had two connectors, but the Intel-defined I/O bus was on the lower (larger connector). At, Masscomp the MC-500 a private (synchronous) memory bus, that was very similar to the BI in its protocol (because Dave designed both of course). It was built on the unused/undefined header and ran much faster than the I/O bus since memory fetches occurred. Also, the Masscomp >>card cage<< was larger than Multibus (I think Apollo was also). The shorter boards fit into the backplane, the larger size allowed for more 'chips to fit.' IIRC, with the original memory chips being used at the time, one reason why the Masscomp was so much faster than the Sun-1 (and 2) was it had larger memory capacity on its boards and the memory transaction were quicker. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tytso at mit.edu Sun Sep 1 07:20:31 2019 From: tytso at mit.edu (Theodore Y. Ts'o) Date: Sat, 31 Aug 2019 17:20:31 -0400 Subject: [TUHS] If not Linux, then what? In-Reply-To: References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net> <20190828231952.GA536@mit.edu> Message-ID: <20190831212031.GB3367@mit.edu> On Sat, Aug 31, 2019 at 12:58:00PM -0400, Christopher Browne wrote: > > I haven't seen reference to Bushnell in a long time; looks like he has > shifted to ecclesiastical matters. He was up to some interesting > software things, once upon a time. Thomas has been working for Google for a number of years. (Brothers of Saint Gregory are expected to support themselves, and so they tend to have lay jobs in addition to their eccleiastical service.) Thomas was working on supporting the Linux desktop for Google engineers[1][2]. (At the time, Google was using Ubuntu LTS; these days, Google desktops are using Debian testing[3].) [1] https://www.youtube.com/watch?v=oGUzhiJu_Jg [2] https://events.static.linuxfound.org/images/stories/pdf/lcna_co2012_bushnell.pdf [3] https://www.ghacks.net/2018/01/24/google-switches-from-ubuntu-to-debian-as-base-for-their-in-house-os/ - Ted From gtaylor at tnetconsulting.net Sun Sep 1 09:38:41 2019 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Sat, 31 Aug 2019 17:38:41 -0600 Subject: [TUHS] ISO, OSI, and DECnet (was Re: If not Linux, then what?) In-Reply-To: <1d3d8c9a-7006-4666-b32e-8fa4fc5e9f7c@PU1APC01FT039.eop-APC01.prod.protection.outlook.com> References: <20190828172451.GX13570@mcvoy.com> <20190828181727.GA82704@wopr> <1d3d8c9a-7006-4666-b32e-8fa4fc5e9f7c@PU1APC01FT039.eop-APC01.prod.protection.outlook.com> Message-ID: <118e62ef-db53-29e4-aa1b-72f8f8126f9e@spamtrap.tnetconsulting.net> On 8/29/19 8:54 AM, Jason Stevens wrote: > Although I never have seen OSI in the wild, it was the one great thing > about ‘Winsock’ is that it worked over TCP/IP , IPX/SPX, AppletTalk and > Decnet.  It was fun to convert a BBS from being telnet to some ‘telnet > over decnet’ monster I built. TUHS might not be the place, perhaps COFF is, but I'd be curious to hear more about your monster. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4008 bytes Desc: S/MIME Cryptographic Signature URL: From rudi.j.blom at gmail.com Sun Sep 1 12:16:39 2019 From: rudi.j.blom at gmail.com (Rudi Blom) Date: Sun, 1 Sep 2019 09:16:39 +0700 Subject: [TUHS] dmr streams & networking [was: Re: If not Linux, then what?] Message-ID: I don't remember from where I got the scheme, so it might be general, DigitalUnix, or HP-UX related. Checking the "HP 9000 networking XTI programmer's guide" from 1995 there's no diagram. The application which was initially developed on a SystemV derived UNIX the Computer division of Philips Electronics had bought, used TLI. Taken over by DEC we moved to SCO UNIX still using TLI, moving to XLI on Alpha/Digital Unix. The nice thing of TLI/XLI is the poll(). A multi-client server can check a list of file descriptors AND indicate a timeout value for the poll(). Like in ret_cd = poll(tep->CEPlist, tep->CEPnumb, timeout); BTW putting in a bit of OSI, on SCO UNIX I use a DEC package which offers a TLI interface to an OSI TP4/IP stack. Even worked using X.25 as WAN. OSI TP4 and NetBIOS originally bought from Retix. >Date: Sat, 31 Aug 2019 11:41:40 -0400 >From: Clem Cole >To: Rudi Blom >Cc: tuhs >Subject: Re: [TUHS] dmr streams & networking [was: Re: If not Linux,then what?] >Message-ID: > >Content-Type: text/plain; charset="utf-8" > >It's the Mentant implementation that HP originally bought. At LCC we had >to hacked on it a bit when we put Transparent Network Computing (TNC) stuff >in HP-UX [we had full process migration working BTW -- A real shame that >never shipped]. >On Sat, Aug 31, 2019 at 5:44 AM Rudi Blom wrote: >> Whenever I hear UNIX, networking and streams I have to think about this >> scheme. >> >> Still using this, even on HP-UX 11.31 on Itanium rx-servers >> >> Cheers, >> uncle rubl From rudi.j.blom at gmail.com Sun Sep 1 12:36:33 2019 From: rudi.j.blom at gmail.com (Rudi Blom) Date: Sun, 1 Sep 2019 09:36:33 +0700 Subject: [TUHS] dmr streams & networking [was: Re: If not Linux, then what? Message-ID: Just to be precise and because I dislike loose ends :-) Found the XTI to TCP/IP diagram. It's even online! https://www.cs.auckland.ac.nz/references/unix/digital/APS2WDTE/TITLE.HTM Network Programmer's Guide © Digital Equipment Corporation 1994, 1995, 1996 All Rights Reserved. Product Version: Digital UNIX Version 4.0 or higher March 1996 From ggm at algebras.org Mon Sep 2 10:13:54 2019 From: ggm at algebras.org (George Michaelson) Date: Mon, 2 Sep 2019 10:13:54 +1000 Subject: [TUHS] systime In-Reply-To: <20190830125739.9891418C0D3@mercury.lcs.mit.edu> References: <20190830125739.9891418C0D3@mercury.lcs.mit.edu> Message-ID: Best works canteen *ever* . steak and chips for nothing. Also, magstripes on the floor for "robot" porters to carry stuff around the office. John Bondi ran the research lab. He was the son of Hermann Bondi. He, and Fred Hoyle promoted the "steady state" theory of the universe. Nice guy. put up with me, anyway. -G On Fri, Aug 30, 2019 at 10:58 PM Noel Chiappa wrote: > > > From: Steve Simon > > > i went for a student placement there but didnt get it - i guess my long > > hair (then) didn't fit as the interview seemed good. > > Maybe you seemed too honest! :-) > > Noel From peter at rulingia.com Mon Sep 2 18:28:28 2019 From: peter at rulingia.com (Peter Jeremy) Date: Mon, 2 Sep 2019 18:28:28 +1000 Subject: [TUHS] dmr streams & networking [was: Re: If not Linux, then what?] In-Reply-To: References: <1567196510.21824.for-standards-violators@oclsc.org> <20190830215202.GA974@mcvoy.com> <20190831011359.E9F491570CE9@mail.bitblocks.com> <88242A0D-D08E-47EB-84DC-A7205780A417@ccc.com> Message-ID: <20190902082828.GL75146@server.rulingia.com> On 2019-Aug-31 15:37:32 +1000, Dave Horsfall wrote: >Ah, those were the days :-) Now, we just have to put up with Intel, >although I believe the ARM is much better. Well, https://www.youtube.com/watch?v=_6sh097Dk5k paints a less rosy picture of ARM. Maybe RISC-V will succeed. It's a bit dated and very off topic but http://www.cpushack.com/CPU/cpu.html makes interesting reading. -- Peter Jeremy -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 963 bytes Desc: not available URL: From dave at horsfall.org Tue Sep 3 09:26:29 2019 From: dave at horsfall.org (Dave Horsfall) Date: Tue, 3 Sep 2019 09:26:29 +1000 (EST) Subject: [TUHS] dmr streams & networking [was: Re: If not Linux, then what?] In-Reply-To: <20190902082828.GL75146@server.rulingia.com> References: <1567196510.21824.for-standards-violators@oclsc.org> <20190830215202.GA974@mcvoy.com> <20190831011359.E9F491570CE9@mail.bitblocks.com> <88242A0D-D08E-47EB-84DC-A7205780A417@ccc.com> <20190902082828.GL75146@server.rulingia.com> Message-ID: On Mon, 2 Sep 2019, Peter Jeremy wrote: > Well, https://www.youtube.com/watch?v=_6sh097Dk5k paints a less rosy > picture of ARM. Maybe RISC-V will succeed. > > It's a bit dated and very off topic but http://www.cpushack.com/CPU/cpu.html > makes interesting reading. Most interesting; thanks. -- Dave From aek at bitsavers.org Thu Sep 5 15:11:34 2019 From: aek at bitsavers.org (Al Kossow) Date: Wed, 4 Sep 2019 22:11:34 -0700 Subject: [TUHS] dmr streams & networking [was: Re: If not Linux, then what?] In-Reply-To: References: <1567196510.21824.for-standards-violators@oclsc.org> <20190830215202.GA974@mcvoy.com> <20190831011359.E9F491570CE9@mail.bitblocks.com> <88242A0D-D08E-47EB-84DC-A7205780A417@ccc.com> Message-ID: <5ee4518e-7e37-2896-3b25-f0a77c34e67b@bitsavers.org> On 8/31/19 12:03 PM, Clem Cole wrote: > > > I was under the belief that Sun never even tried the trick Correct. The original pre-BSD Sun-1 used the Stanford CPU, ran Unisoft and used the stack probe hack in the compiler. SunOS 1 required a 68010 'brain transplant' From imp at bsdimp.com Mon Sep 9 16:25:05 2019 From: imp at bsdimp.com (Warner Losh) Date: Mon, 9 Sep 2019 00:25:05 -0600 Subject: [TUHS] PWB vs Unix/TS Message-ID: OK. I'm totally confused, and I see contradictory information around. So I thought I'd ask here. PWB was started to support unix time sharing at bell labs in 1973 (around V4 time). PWB 1.0 was released just after V6 "based on" it. PWB 2.0 was released just after V7, also "based on it". Later Unix TS 3.0 would become System III. We know there was no System I or System II. But was there a Unix TS 1.0 and 2.0? And were they the same thing as PWB 1.0 and 2.0, or somehow just closely related? And I've seen both Unix/TS and Unix TS. Is there a preferred spelling? Thanks for all your help with this topic and sorting things out. It's been quite helpful for my talk in a few weeks. Warner P.S. Would it be inappropriate to solicit feedback on an early version of my talk from this group? I'm sure they would be rather keener on catching errors in my understanding of Unix history than just about any other forum... -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnold at skeeve.com Mon Sep 9 16:36:19 2019 From: arnold at skeeve.com (arnold at skeeve.com) Date: Mon, 09 Sep 2019 00:36:19 -0600 Subject: [TUHS] PWB vs Unix/TS In-Reply-To: References: Message-ID: <201909090636.x896aK1A001747@freefriends.org> I can't answer your question, but I can tell you that there was a UNIX 4.0 inside the Bell System. The policy at the time (1983) was to release externally one release behind the current internal release. That changed with UNIX 5.0 which was released internally and externally at the same time, becoming System V. Then the marketing people got involved, and didn't want System VI as the next release, so they went to System V Release 2, 3, and 4. As to previewing your talk, why not? Arnold Warner Losh wrote: > OK. I'm totally confused, and I see contradictory information around. So I > thought I'd ask here. > > PWB was started to support unix time sharing at bell labs in 1973 (around > V4 time). > PWB 1.0 was released just after V6 "based on" it. PWB 2.0 was released just > after V7, also "based on it". Later Unix TS 3.0 would become System III. We > know there was no System I or System II. But was there a Unix TS 1.0 and > 2.0? And were they the same thing as PWB 1.0 and 2.0, or somehow just > closely related? And I've seen both Unix/TS and Unix TS. Is there a > preferred spelling? > > Thanks for all your help with this topic and sorting things out. It's been > quite helpful for my talk in a few weeks. > > Warner > > P.S. Would it be inappropriate to solicit feedback on an early version of > my talk from this group? I'm sure they would be rather keener on catching > errors in my understanding of Unix history than just about any other > forum... From clemc at ccc.com Wed Sep 11 01:16:34 2019 From: clemc at ccc.com (Clem Cole) Date: Tue, 10 Sep 2019 11:16:34 -0400 Subject: [TUHS] PWB vs Unix/TS In-Reply-To: References: Message-ID: Below ... from memory - Someone like APS was a little closer to some of this than I was, so I might have a few things wrong. I don't think so, but it's been quite a few beers On Mon, Sep 9, 2019 at 2:26 AM Warner Losh wrote: > OK. I'm totally confused, and I see contradictory information around. So I > thought I'd ask here. > > PWB was started to support unix time sharing at bell labs in 1973 (around > V4 time). > No... that is not quite right. PWB was Mashey's project to build an RJE system to front end SW development for the IBM systems, which AT&T had a number [IIRC Call Accounting and lot of the 'business' part of the Bell System was mainframe based]. I think Dick Haight was also involved. I've forgotten the site there were at. It might have been Holmdel or Whippany. But it was not MH or Summit. > PWB 1.0 was released just after V6 "based on" it. > Well not so much "right after", but it was based on V6. There are differences. IIRC this was the first attempt at redoing how groups worked. The biggest additions were an IBM RJE support, SCCS and a different set of backup utilities; including some disk to disk (volcpy) and the original binary formatted program for 9-tracks (cpio) to replace Ken's assembler based tp. SCCS was important and the RJE support was important because that was the system being used and it made a huge impression on AT&T staff. A terminal to a UNIX box was way cheaper and to the IBM and people were so much more productive. Also remember, that tp(1) was written in assembler had been originally targeted to DECtape in a very early version of Research UNIX. The DECtape nature is why the directory was on the front of the tape. Ken moved it 9-track but used the same tape format. I don't remember who wrote stp (super-tp - in C), [?? Harvard ?? it's on the Harvard tape and is how I got it]. But better peripheral support was really important in Mashey's setting. In that world, the production computer system was being put in the raised floor computer rooms next to a mainframe and they had 'operators' so John and team started to think more about what was needed to admin the system. IMHO: this was the first heavy use of shell scripts, while I saw them in MH, it was Mashey's guys that cause me personally to have an ah-ha moment about them. Interestingly enough, and I have talked to Bourne and Mashey about it, John's use of the V6 was definitely one of the groups that were asking for a new shell, which Bourne set out to solve; but that is not yet available. At some point (and here is where we need Steve Johnson, aps, and I wish the late Ted Kowalski) to fill in details I can not. USG/Summit was chartered to "support UNIX for the Bell System." As I understand it, the genesis for their system was a kernel from MH that was moving towards V7s but not there yet, the 'Typesetter C' and a bunch of other utilities that Summit had collected/developed, but which I do not know. I think fsdb was around by that time. The new Bourne Shell and adb were being developed although how complete I'm not sure. But accept for the new shell and updated compiler, I remember the system 'felt' like V6 (Thompson shell) and thinking how much 'better' different v7 (Bourne Shell was) when we finally got it. This earlier system is the one Ted brought to CMU in the fall 1977 (I think that is the right date) to update the V6 system were then running. Anyway, Ted always referred to this as a UNIX/TS kernel. Another thing we did not have SCCS or the RJE stuff. What I'm not sure of is if there was a formally release of what ted had. So it may have been that TS had them and sent the release to Mashey, although I don't think there were such releases originally in TS. FWIW: I believe that in our (CMU) case,Ted would just grab things as they appeared that he thought we needed at CMU and he pushed things back (like CMU's fsck as he found things we had that he thought we would like). Interestingly enough, RJE and SCCS was needed for the IBM support and while Ted (and his undergrad roommate, Bill Joy) had worked on the MTS system on the IBM's at UMich, I always felt like Ted looked down on the mainframes (which was were I had also emerged but from CMU's TSS team). Also, Ted was a die-hard original cpio user and I liked the user interface to stp, which I remember was a difference/source of argument. Tar did not yet exist. TS had some of the PWB tools like volcpy; but we were using DOS-11's similar but different backup scheme (I've forgotten the name of the format; but the tapes were boot-able, which volcpy tapes were not). FWIW: cu(1) did not yet exist. I wrote a program (that I tended to prefer in some ways for many years) called connect(1cmu) that did the same thing. We used it to download images to the Microprocessors like the KIM-1. It was originally written with the v6 portable C library, which is also what the original fsck used (it's what we had on v6). Ted introduced me to what would become stdio and one of my first tasks was using it with connect(1cmu). The other thing I remember about that program is it was the first time I wrote something that used two separate processes on a UNIX system that cooperated with each other and found it so much easier than on the PDP-10. Also, Dennis' stand-alone system for V7 was not yet available BTW. If I think of anything else about that system I can remember, I'll send an update PWB 2.0 was released just after V7, also "based on it". > I think the confusion is that TS and V7 were done sort of at the same time and while the folks working on them talked to each other, it has never been clear to me who was behind TS. For instance, I would learn that Bourne was the 'project leader' for Seventh, in that he was the person that collected everything for it. I never heard of someone having the same role for TS, which is why I sometimes think it was a name inside of Summit, but never actually saw the light of day as a formal release. I really am not sure and would love to learn more details (I wish Ted were still alive to fill us in). As for V7 itself, Ken wrote tar(1) in response to cpio (preferring an ASCII based header, but 'threading' it like cpio did, but keeping the user interface that tp/stp had). As I understand it, Dennis built up did the standalone toolkit stuff. Ken changed groups and messed with the file system in the kernel. Lots of new peripheral support, which is why he also added lseek() as disks overflowed a 16-bit integer for the seek position. Plus there were a number of other small changes between v6 and v7. Some of this stuff from PWB and Summit went back to MH (fsck as an example), but not everything (like cpio/volcpy/SCCS). I kind of think of the kernel and Typesetter C going from MH to Summit and the PWB teams. @Steve Johnson, I need your help here.... at some point PCC was created in MH (along with lint). Didn't that start on V6 but was not complete until V7? And when did you move to Summit to lead the compiler effort there? My impressions that was yet to happen, but I'm fuzzy on dates. Remember, there are a number of teams at BTL hacking on UNIX by then. Dale's team in Columbus, the crew in Indiana Hill, folks at Western Electric (the Teletype folks ported the Ritchie C to the Z80 at some point for instance), *etc.* Again, I don't remember the politics but like any big company, you can imagine it was not all that clean and crisp. PWB 2.0 & 3.0 definitely picked up features from other UNIX systems. As I remember, Dale's shared memory hacks would beget System V Shared Mem, Semaphores and IPC (they are different, but they started in Columbus). The other thing I'm not clear on is when the PWB team was folded into USG (Unix Support Group) in Summit. *I believe* that was after PWB 2.0 was released. But at some point, Mashey's team and the USG got interwoven. I really don't know/remember many of those details as I watched them from the outside and only knew the results. The key point is the PWB 2.0 would eventually be released as the internal, but official UNIX for the Bell System. It was supposed to bring together the needed from the different labs; but it was not >>officially<< released *outside of the Bell System* (it was an internal product, remember at this point, AT&T is not allowed to have computer products, etc...) So PWB 2.0 is basically internal, and a melding of V7, TS, PWB 1.0 and starting to take things from different labs with in BTL -- different from all of them but mostly a superset. > Later Unix TS 3.0 would become System III. > No --I do not think this is a true statement... not sure where you got that, more in a minute We know there was no System I or System II. > Correct. But was there a Unix TS 1.0 and 2.0? > This is where it gets sticky. I don't think so. TS was the original work by USG. What I do not know is if it ever was 'packaged' as PWB had been. *I do not believe it was*. I think a little like the way Research 'bled' out a little a time, pieces of TS made their way to MIT, CMU, *etc*. but never as a formal release. > And were they the same thing as PWB 1.0 and 2.0, or somehow just closely > related? > See above... I'll explain how PWB 3.0 became System III in a minute. > And I've seen both Unix/TS and Unix TS. Is there a preferred spelling? > Don't know. I remember Ted always called it UNIX/TS all caps. The thing you left out is how PWB 3.0 became System III. Two important issues. First with V7, AT&T (Al Arms) wrote the first binary system redistribution license. The commercial folks were happy to have a redistribution license, but the terms were not what they really needed. Much of the issue was that AT&T was not the computer hardware or software business and really did not understand the issues that the vendors had. Professor Dennis Allison of Stanford, was consulting for almost all of us in the computer industry at the time (for those that don't know Dennis, around the same time he founded what is now called the Asilomar Microprocessor Workshop (check out: https://www.computerhistory.org/atchm/the-asilomar-microcomputer-workshop-and-the-billion-dollar-toilet-seat/ ). Dennis arranged for a big meeting at Ricki's Hyatt in Palo Alto and invited Al Arms and team, plus a representatives from his clients. I was the techie with a lawyer from Tektronix in the room (as I have said in other emails this it is only time I have been in a meeting with Bill Gates). The folks I remember who were there: was Bill Munson and team from DEC; Fred Clegg and Team from HP; Bob MetCalfe from 3Com; Gates and the MSFT crew; folks from SCO and DG. There were some others, about 10 firms in total; although I think if remember correctly, IBM was not among them [This is the meeting where Gates famously exclaimed: "*You guys don't get it. The only thing that matters in the software industry is volume*."]. BTW: The bits we were discussing was the upcoming release from USG, to be called PWB 3.0 and they were for the PDP-11 only (which was fine, that was what we all had been licensing already. We could still use things from other places, because that is what those other places were all licensed to have -- all was good in UNIX-land). Thus began a series of negotiations for a new license agreement that would allow the HW vendors to better ship UNIX as a binary product: FWIW: Gates wanted to pay $25/copy. The DEC, HP and DG folks laughed. $1K/copy was fine by them, since their HW was typically $50-150K/system. Either shortly after or maybe during the negotiations time, Judge Green ruled and AT&T got broken up. One of the things that occured is that AT&T was now allowed to sell SW and more importantly their new 3B20 as a product (against IBM and DEC). From a SW standpoint, AT&T Marketing did not like the 'Programmers' moniker, feeling that it would limit who they could sell too. So they rebranded the new software product 'System III.' Note the printing of the manuals had already begun, which is why the cover of the manuals say System III, but the title pages say PWB 3.0. As other have said a few years later, another PWB release came out for the Bell System, *a.k.a.* PWB 4.0; but this was not licensed outside. At some point later, negotiations had restarted on yet another license with the System III licensees and AT&T. By the time that completed, yet another release had been finished by USG. The biggest change was the addition support for HW besides the PDP-11. In particular, the official USG support for the VAX and the 3B20. What I forget, but I think in that license you had to declare a system type and most licensees picked the VAX. By the time of release and finalization of the license, AT&T Marketing which had already started the '*Consider it Standard*' campaign, called the new release "System V." AT&T Marketing would stay with System V moniker from then on and we know have SVR2, SVR3, SVR4, SVR5 in later years. > Thanks for all your help with this topic and sorting things out. It's been > quite helpful for my talk in a few weeks. > > Warner > > P.S. Would it be inappropriate to solicit feedback on an early version of > my talk from this group? > I would suggest sending a pointer to this group to the slides and ask for people to send you comments privately. > I'm sure they would be rather keener on catching errors in my > understanding of Unix history than just about any other forum... > Indeed - happy to help. Clem -------------- next part -------------- An HTML attachment was scrubbed... URL: From scj at yaccman.com Wed Sep 11 10:28:41 2019 From: scj at yaccman.com (Steve Johnson) Date: Tue, 10 Sep 2019 17:28:41 -0700 Subject: [TUHS] PWB vs Unix/TS In-Reply-To: Message-ID: <99b89a5f55b82dcf67f7bebe92b752a5b0e0a72d@webmail.yaccman.com> Well, I can share a bit of the piece of the elephant(s) I saw. While most of the Unix folks were PDP-11 only (after MULTICS), I had spent a couple of years helping to run the MH comp center.   The system for the IBM 7094 was among the best anywhere -- card decks were staged to tape and the overhead of changing from one job to the next was minimized.  Most modest-sized job submissions were finished in roughly an hour.   When MULTICS started, the 7094 went away and it was a huge jolt.  There were some amazing programs (e.g., a LISP compiler written in MACRO FAP that would go 250 levels deep to produce good code).  There were acoustic simulation programs that were way ahead of their time.  And they were all lost. With MULTICS still way in the future and no more 7094, a software package was put together to allow the MULTICS machines to run the commercial GCOS system (the software was called the K package, K standing for kluge.  It was well named...)   Anyhow, they needed help, and asked me to help, and I did so for a couple of years, largely supporting FORTRAN.   Meanwhile, Dennis was inventing B, and there was a limping version for the GE.  He may have actually used it as part of a bootstrap of the language -- I'm not sure.  So I discovered it, and started to use it to write some system admin programs.  I soon ran into some limitations, and started to lobby Dennis for some changes.  He listened politely, and then said "Why don't you fix it.  The compiler is just a program, after all..."   So I put some things into B, including support for the GE native 6-bit character set.  This eventually found its way into C and CPP.  Decades later, if you wrote `abc` in the DEC C compiler, it produced GE strings...   I also made it possible to call FORTRAN from C (the other way was a bit harder...). Eventually they set up an organization to formally own running the comp center, and I was invited to return to Research and I did.   But I had gained a lot of sensitivity to the needs of Engineers and Scientists just wanting to get their work done. Years later, when I was asked to come over to Summit and head the System V language department, V7 was behind us, and the Interdata port had taught us a lot about portability.  PCC had proved itself on a half dozen machines and had been well received.  But most of the Bell System was using 16-bit DEC machines and Dennis' compiler.  C++ was under develpment and looked like a clear winner, but it needed a lot of work.  The debugging of C++ was horrible -- a program, Cfront, converted C++ to C, but in the process screwed up the line numbers and names so that using a debugger was almost impossible.   My three goals in going to Summit were to make C++ commercially available, to provide a debugging technology that could handle not just C++ and C but FORTRAN and ADA and PASCAL, and to base the code generation on the PCC2 model to gain portability.  Although AT&T's computer business was pretty much a disaster, I felt that I had met these goals  -- Elf and Dwarf, C++ debugging, and the first commercial C++ product happened on my watch.  I also had a lot of fun working with a bright and diverse group of talented people. Sadly, as the AT&T computer business collapsed, I realized that I loved doing advanced development, but not at ATT.  My final straw was when an excellent QA team leader at another location was fired for telling the truth about how lousy one of the machines performed.  So it was off to Silicon Valley for me. Steve ----- Original Message ----- From: "Clem Cole" To: "Warner Losh" Cc: "The Eunuchs Hysterical Society" Sent: Tue, 10 Sep 2019 11:16:34 -0400 Subject: Re: [TUHS] PWB vs Unix/TS Below ... from memory - Someone like APS was a little closer to some of this than I was, so I might have a few things wrong.  I don't think so, but it's been quite a few beers On Mon, Sep 9, 2019 at 2:26 AM Warner Losh wrote: OK. I'm totally confused, and I see contradictory information around. So I thought I'd ask here. PWB was started to support unix time sharing at bell labs in 1973 (around V4 time). No...  that is not quite right.  PWB was Mashey's project to build an RJE system to front end SW development for the IBM systems, which AT&T had a number [IIRC Call Accounting and lot of the 'business' part of the Bell System was mainframe based].  I think Dick Haight was also involved.  I've forgotten the site there were at.  It might have been Holmdel or Whippany. But it was not MH or Summit.   PWB 1.0 was released just after V6 "based on" it. Well not so much "right after", but it was based on V6.  There are differences.  IIRC this was the first attempt at redoing how groups worked.  The biggest  additions were an IBM RJE support, SCCS and a different set of backup utilities; including some disk to disk (volcpy)  and the original binary formatted program for 9-tracks ( cpio) to replace Ken's assembler based tp. SCCS was important and the RJE support was important because that was the system being used and it made a huge impression on AT&T staff.   A terminal to a UNIX box was way cheaper and to the IBM and people were so much more productive. Also remember, that tp(1) was written in assembler had been originally targeted to DECtape in a very early version of Research UNIX.  The DECtape nature is why the directory was on the front of the tape.  Ken moved it 9-track but used the same tape format.   I don't remember who wrote stp (super-tp - in C), [?? Harvard ?? it's on the Harvard tape and is how I got it].    But better peripheral support was really important in Mashey's setting.  In that world, the production computer system was being put in the raised floor computer rooms next to a mainframe and they had 'operators' so John and team started to think more about what was needed to admin the system.   IMHO: this was the first heavy use of shell scripts, while I saw them in MH, it was Mashey's guys that cause me personally to have an ah-ha moment about them. Interestingly enough, and I have talked to Bourne and Mashey about it, John's use of the V6 was definitely one of the groups that were asking for a new shell, which Bourne set out to solve; but that is not yet available. At some point (and here is where we need Steve Johnson, aps, and I wish the late Ted Kowalski) to fill in details I can not.  USG/Summit was chartered to "support UNIX for the Bell System."   As I understand it, the genesis for their system was a kernel from MH that was moving towards V7s but not there yet, the 'Typesetter C' and a bunch of other utilities that Summit had collected/developed, but which I do not know.  I think fsdb was around by that time. The new Bourne Shell and adb were being developed although how complete I'm not sure. But accept for the new shell and updated compiler, I remember the system 'felt' like V6 (Thompson shell) and thinking how much 'better' different v7 (Bourne Shell was) when we finally got it. This earlier system is the one Ted brought to CMU in the fall 1977 (I think that is the right date) to update the V6 system were then running.  Anyway, Ted always referred to this as a UNIX/TS kernel. Another thing we did not have SCCS or the RJE stuff.   What I'm not sure of is if there was a formally release of what ted had .  So it may have been that TS had them and sent the release to Mashey, although I don't think there were such releases originally in TS.  FWIW:  I believe that in our (CMU) case, Ted  would just grab things as they appeared that he thought we needed at CMU and he pushed things back (like CMU's fsck as he found things we had that he thought we would like).  Interestingly enough, RJE and SCCS was needed for the IBM support and while Ted (and his undergrad roommate, Bill Joy) had worked on the MTS system on the IBM's at UMich, I always felt like Ted looked down on the mainframes (which was were I had also emerged but from CMU's TSS team). Also, Ted was a die-hard original cpio user and I liked the user interface to stp, which I remember was a difference/source of argument .   Tar did not yet exist. TS had some of the PWB tools like volcpy; but we were using DOS- 11's similar but different backup scheme (I've forgotten the name of the format; but the tapes were boot-able, which volcpy tapes were not). FWIW:  cu(1) did not yet exist.  I wrote a program (that I tended to prefer in some ways for many years) called connect(1cmu) that did the same thing.  We used it to download images to the Microprocessors like the KIM-1.   It was originally written with the v6 portable C library, which is also what the original fsck used (it's what we had on v6).   Ted introduced me to what would become stdio and one of my first tasks was using it with connect(1cmu).  The other thing I remember about that program is it was the first time I wrote something that used two separate processes on a UNIX system that cooperated with each other and found it so much easier than on the PDP-10. Also, Dennis' stand-alone system for V7 was not yet available BTW.   If I think of anything else about that system I can remember, I'll send an update PWB 2.0 was released just after V7, also "based on it". I think the confusion is that TS and V7 were done sort of at the same time and while the folks working on them talked to each other, it has never been clear to me who was behind TS. For instance, I would learn that Bourne was the 'project leader' for Seventh, in that he was the person that collected everything for it.  I never heard of someone having the same role for TS, which is why I sometimes think it was a name inside of Summit, but never actually saw the light of day as a formal release.   I really am not sure and would love to learn more details (I wish Ted were still alive to fill us in). As for V7 itself, Ken wrote tar(1) in response to cpio (preferring an ASCII based header, but 'threading' it like cpio did, but keeping the user interface that tp/stp had).  As I understand it, Dennis built up did the standalone toolkit stuff.  Ken changed groups and messed with the file system in the kernel.  Lo ts of new peripheral support, which is why he also added lseek() as disks overflowed a 16-bit integer for the seek position .  Plus there were a number of other small changes between v6 and v7.  Some of this stuff from PWB and Summit went back to MH (fsck as an example), but not everything (like cpio/volcpy/SCCS).  I kind of think of the kernel and Typesetter C going from MH to Summit and the PWB teams. @Steve Johnson, I need your help here.... at some point PCC was created in MH (along with lint).  Didn't that start on V6 but was not complete until V7? And when did you move to Summit to lead the compiler effort there?  My impressions that was yet to happen, but I'm fuzzy on dates. Remember, there are a number of teams at BTL hacking on UNIX by then.  Dale's team in Columbus, the crew in Indiana Hill,  folks at Western Electric (the Teletype folks ported the Ritchie C to the Z80 at some point for instance), _etc._ Again, I don't remember the politics but like any big company, you can imagine it was not all that clean and crisp.   PWB 2.0 & 3.0 definitely picked up features from other UNIX systems.  As I remember, Dale's shared memory hacks would beget System V Shared Mem, Semaphores and IPC (they are different, but they started in Columbus). The other thing I'm not clear on is when the PWB team was folded into USG ( Unix Support Group)  in Summit.  _I believe_ that was after PWB 2.0 was released.   But at some point, Mashey's team and the USG got interwoven.  I really don't know/remember many of those details as I watched them from the outside and only knew the results.  The key point is the PWB 2.0 would eventually be released as the internal, but  official UNIX for the Bell System.   It was supposed to bring together the needed from the different labs; but it was not >> officially << released _outside of the Bell System_ (it was an internal product, remember at this point, AT&T is not allowed  to have computer products, etc...)  So PWB 2.0 is basically internal, and a melding of V7, TS, PWB 1.0 and starting to take things from different labs with in BTL -- different from all of them but mostly a superset.   Later Unix TS 3.0 would become System III. No --I do not think this is a true statement... not sure where you got that, m ore in a minute We know there was no System I or System II. Correct.  But was there a Unix TS 1.0 and 2.0? This is where it gets sticky.  I don't think so.   TS was the original work by USG.   What I do not know is if it ever was 'packaged' as PWB had been. _I do not believe it was_.   I think a little like the way Research 'bled' out a little a time, pieces of TS made their way to MIT, CMU, _etc_. but never as a formal release.   And were they the same thing as PWB 1.0 and 2.0, or somehow just closely related? See above... I'll explain how PWB 3.0 became System III in a minute.   And I've seen both Unix/TS and Unix TS. Is there a preferred spelling? Don't know.  I remember Ted always called it UNIX/TS all caps. The thing you left out is how PWB 3.0 became System III. Two important issues.  First with V7, AT&T (Al Arms) wrote the first binary system redistribution license.  The commercial folks were happy to have a redistribution license, but the terms were not what they really needed.  Much of the issue was that AT&T was not the computer hardware or software business and really did not understand the issues that the vendors had.  Professor Dennis Allison of Stanford, was consulting for almost all of us in the computer industry at the time (for those that don't know Dennis, around the same time he founded what is now called the Asilomar Microprocessor Workshop (check out:  https://www.computerhistory.org/atchm/the-asilomar-microcomputer-workshop-and-the-billion-dollar-toilet-seat/ [2]). Dennis arranged for a big meeting at Ricki's Hyatt in Palo Alto and invited Al Arms and team, plus a representatives from his clients. I was the techie with a lawyer from Tektronix in the room (as I have said in other emails this it is only time I have been in a meeting with Bill Gates).  The folks I remember who were there: was Bill Munson and team from DEC; Fred Clegg and Team from HP; Bob MetCalfe from 3Com; Gates and the MSFT crew; folks from SCO and DG.   There were some others, about 10 firms in total; although I think if remember correctly, IBM was not among them [This is the meeting where Gates famously exclaimed: "_You guys don't get it.  The only thing that matters in the software industry is volume_."]. BTW: The bits we were discussing was the upcoming release from USG, to be called PWB 3.0 and they were for the PDP-11 only (which was fine, that was what we all had been licensing already.  We could still use things from other places, because that is what those other places were all licensed to have -- all was good in UNIX-land). Thus began a series of negotiations for a new license agreement that would allow the HW vendors to better ship UNIX as a binary product:  FWIW: Gates wanted to pay $25/copy.   The DEC, HP and DG folks laughed.  $1K/copy was fine by them, since their HW was typically $50-150K/system. Either shortly after or maybe during the negotiations time, Judge Green ruled and AT&T got broken up.   One of the things that occured is that AT&T was now allowed to sell SW and more importantly their new 3B20 as a product (against IBM and DEC).  From a SW standpoint, AT&T Marketing did not like the 'Programmers' moniker, feeling that it would limit who they could sell too.  So they rebranded the new software product 'System III.' Note the printing of the manuals had already begun, which is why the cover of the manuals say System III, but the title pages say PWB 3.0. As other have said a few years later, another PWB release came out for the Bell System, _a.k.a._ PWB 4.0; but this was not licensed outside. At some point later, negotiations had restarted on yet another license with the System III licensees and AT&T.   By the time that completed, yet another release had been finished by USG.  The biggest change was the addition support for HW besides the PDP-11. In particular, the official USG support for the VAX and the 3B20.  What I forget, but I think in that license you had to declare a system type and most licensees picked the VAX. By the time of release and finalization of the license, AT&T Marketing which had already started the '_Consider it Standard_' campaign, called the new release "System V." AT&T Marketing would stay with System V moniker from then on and we know have SVR2, SVR3, SVR4, SVR5 in later years. Thanks for all your help with this topic and sorting things out. It's been quite helpful for my talk in a few weeks. Warner P.S. Would it be inappropriate to solicit feedback on an early version of my talk from this group? I would suggest sending a pointer to this group to the slides and ask for people to send you comments privately.   I'm sure they would be rather keener on catching errors in my understanding of Unix history than just about any other forum... Indeed - happy to help. Clem   Links: ------ [1] mailto:imp at bsdimp.com [2] https://www.computerhistory.org/atchm/the-asilomar-microcomputer-workshop-and-the-billion-dollar-toilet-seat/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Wed Sep 11 13:53:19 2019 From: imp at bsdimp.com (Warner Losh) Date: Tue, 10 Sep 2019 21:53:19 -0600 Subject: [TUHS] PWB vs Unix/TS In-Reply-To: References: Message-ID: On Tue, Sep 10, 2019 at 9:17 AM Clem Cole wrote: > Below ... from memory - Someone like APS was a little closer to some of > this than I was, so I might have a few things wrong. I don't think so, but > it's been quite a few beers > > On Mon, Sep 9, 2019 at 2:26 AM Warner Losh wrote: > >> OK. I'm totally confused, and I see contradictory information around. So >> I thought I'd ask here. >> >> PWB was started to support unix time sharing at bell labs in 1973 (around >> V4 time). >> > No... that is not quite right. PWB was Mashey's project to build an RJE > system to front end SW development for the IBM systems, which AT&T had a > number [IIRC Call Accounting and lot of the 'business' part of the Bell > System was mainframe based]. I think Dick Haight was also involved. I've > forgotten the site there were at. It might have been Holmdel or Whippany. > But it was not MH or Summit. > "The Programmer's Workbench was started in 1973,[2] by Evan Ivie and Rudd Canaday to support a computer center for a 1000-employee Bell Labs division" is what wikipedia says, though that reference is in a acm queue article by Mashey... PWB 1.0 was released just after V6 "based on" it. >> > Well not so much "right after", but it was based on V6. There are > differences. IIRC this was the first attempt at redoing how groups > worked. The biggest additions were an IBM RJE support, SCCS and a > different set of backup utilities; including some disk to disk (volcpy) and > the original binary formatted program for 9-tracks (cpio) to replace > Ken's assembler based tp. > Yes. PWB had their own collection of add-ons. I believe, but can't find the reference, that there were frequent imports of Research Unix into PWB as I saw references to UNIX/TS and CB-UNIX never getting too far away from Research Unix, so that's kinda speculative... I imagine that SCCS was a boon for keeping it all straight, but I've never actually used SCCS. > SCCS was important and the RJE support was important because that was the > system being used and it made a huge impression on AT&T staff. A terminal > to a UNIX box was way cheaper and to the IBM and people were so much more > productive. > > Also remember, that tp(1) was written in assembler had been originally > targeted to DECtape in a very early version of Research UNIX. The DECtape > nature is why the directory was on the front of the tape. Ken moved it > 9-track but used the same tape format. I don't remember who wrote stp > (super-tp - in C), [?? Harvard ?? it's on the Harvard tape and is how I got > it]. But better peripheral support was really important in Mashey's > setting. In that world, the production computer system was being put in > the raised floor computer rooms next to a mainframe and they had > 'operators' so John and team started to think more about what was needed to > admin the system. IMHO: this was the first heavy use of shell scripts, > while I saw them in MH, it was Mashey's guys that cause me personally to > have an ah-ha moment about them. > > Interestingly enough, and I have talked to Bourne and Mashey about it, > John's use of the V6 was definitely one of the groups that were asking for > a new shell, which Bourne set out to solve; but that is not yet available. > > At some point (and here is where we need Steve Johnson, aps, and I wish > the late Ted Kowalski) to fill in details I can not. USG/Summit was > chartered to "support UNIX for the Bell System." As I understand it, the > genesis for their system was a kernel from MH that was moving towards V7s > but not there yet, the 'Typesetter C' and a bunch of other utilities that > Summit had collected/developed, but which I do not know. I think fsdb was > around by that time. The new Bourne Shell and adb were being developed > although how complete I'm not sure. > > But accept for the new shell and updated compiler, I remember the system > 'felt' like V6 (Thompson shell) and thinking how much 'better' different v7 > (Bourne Shell was) when we finally got it. This earlier system is the one > Ted brought to CMU in the fall 1977 (I think that is the right date) to > update the V6 system were then running. Anyway, Ted always referred to > this as a UNIX/TS kernel. > > Another thing we did not have SCCS or the RJE stuff. What I'm not sure > of is if there was a formally release of what ted had. So it may have > been that TS had them and sent the release to Mashey, although I don't > think there were such releases originally in TS. FWIW: I believe that in > our (CMU) case,Ted would just grab things as they appeared that he > thought we needed at CMU and he pushed things back (like CMU's fsck as he > found things we had that he thought we would like). Interestingly > enough, RJE and SCCS was needed for the IBM support and while Ted (and his > undergrad roommate, Bill Joy) had worked on the MTS system on the IBM's at > UMich, I always felt like Ted looked down on the mainframes (which was were > I had also emerged but from CMU's TSS team). > > Also, Ted was a die-hard original cpio user and I liked the user > interface to stp, which I remember was a difference/source of argument. > Tar did not yet exist. TS had some of the PWB tools like volcpy; but we > were using DOS-11's similar but different backup scheme (I've forgotten > the name of the format; but the tapes were boot-able, which volcpy tapes > were not). > > FWIW: cu(1) did not yet exist. I wrote a program (that I tended to > prefer in some ways for many years) called connect(1cmu) that did the same > thing. We used it to download images to the Microprocessors like the > KIM-1. It was originally written with the v6 portable C library, which is > also what the original fsck used (it's what we had on v6). Ted introduced > me to what would become stdio and one of my first tasks was using it with > connect(1cmu). The other thing I remember about that program is it was the > first time I wrote something that used two separate processes on a UNIX > system that cooperated with each other and found it so much easier than on > the PDP-10. > > Also, Dennis' stand-alone system for V7 was not yet available BTW. If I > think of anything else about that system I can remember, I'll send an update > > PWB 2.0 was released just after V7, also "based on it". >> > I think the confusion is that TS and V7 were done sort of at the same time > and while the folks working on them talked to each other, it has never been > clear to me who was behind TS. For instance, I would learn that Bourne was > the 'project leader' for Seventh, in that he was the person that collected > everything for it. I never heard of someone having the same role for TS, > which is why I sometimes think it was a name inside of Summit, but never > actually saw the light of day as a formal release. I really am not sure > and would love to learn more details (I wish Ted were still alive to fill > us in). > Several timelines have, without references, Unix/TS or some variant of that going back to the V4 time frame. It's at best murky. There's some references in https://wiki.tuhs.org/doku.php?id=misc:snippets:mert1 including the post by Dan DeJegar which I had trouble parsing the ins and outs of. > As for V7 itself, Ken wrote tar(1) in response to cpio (preferring an > ASCII based header, but 'threading' it like cpio did, but keeping the user > interface that tp/stp had). As I understand it, Dennis built up did the > standalone toolkit stuff. Ken changed groups and messed with the file system > in the kernel. Lots of new peripheral support, which is why he also > added lseek() as disks overflowed a 16-bit integer for the seek position. > Plus there were a number of other small changes between v6 and v7. Some of > this stuff from PWB and Summit went back to MH (fsck as an example), but > not everything (like cpio/volcpy/SCCS). I kind of think of the kernel and > Typesetter C going from MH to Summit and the PWB teams. > > @Steve Johnson, I need your help here.... at some point PCC was created in > MH (along with lint). Didn't that start on V6 but was not complete until > V7? And when did you move to Summit to lead the compiler effort there? My > impressions that was yet to happen, but I'm fuzzy on dates. > > Remember, there are a number of teams at BTL hacking on UNIX by then. > Dale's team in Columbus, the crew in Indiana Hill, folks at Western > Electric (the Teletype folks ported the Ritchie C to the Z80 at some point > for instance), *etc.* > Yea, the Columbus crew added a lot to the different versions, and merged from them, according to the above link and a few other sources. > Again, I don't remember the politics but like any big company, you can > imagine it was not all that clean and crisp. PWB 2.0 & 3.0 definitely > picked up features from other UNIX systems. As I remember, Dale's shared > memory hacks would beget System V Shared Mem, Semaphores and IPC (they are > different, but they started in Columbus). > This jives with other information that says the basis of system V share memory, semaphores and ipc were derived from CB-Unix... > The other thing I'm not clear on is when the PWB team was folded into USG (Unix > Support Group) in Summit. *I believe* that was after PWB 2.0 was > released. But at some point, Mashey's team and the USG got interwoven. > I really don't know/remember many of those details as I watched them from > the outside and only knew the results. The key point is the PWB 2.0 would > eventually be released as the internal, but official UNIX for the Bell > System. It was supposed to bring together the needed from the different > labs; but it was not >>officially<< released *outside of the Bell System* > (it was an internal product, remember at this point, AT&T is not allowed to > have computer products, etc...) > Yes. There's some confusion as PWB and UNIX/TS become a USG thing that turns into System III and then the influx of CB-UNIX that's added before System V. How all that relates to USG, I'm quite unclear on still... > So PWB 2.0 is basically internal, and a melding of V7, TS, PWB 1.0 and > starting to take things from different labs with in BTL -- different from > all of them but mostly a superset. > > > > >> Later Unix TS 3.0 would become System III. >> > No --I do not think this is a true statement... not sure where you got > that, more in a minute > >From the above recollection of Dan DeJAger... > We know there was no System I or System II. >> > Correct. > > But was there a Unix TS 1.0 and 2.0? >> > This is where it gets sticky. I don't think so. TS was the original > work by USG. What I do not know is if it ever was 'packaged' as PWB had > been. *I do not believe it was*. I think a little like the way Research > 'bled' out a little a time, pieces of TS made their way to MIT, CMU, *etc*. > but never as a formal release. > I've seen lots of references to UNIX/TS, but no versions, so this makes some sense... And it appears they go back further than V6... > And were they the same thing as PWB 1.0 and 2.0, or somehow just closely >> related? >> > See above... I'll explain how PWB 3.0 became System III in a minute. > > >> And I've seen both Unix/TS and Unix TS. Is there a preferred spelling? >> > Don't know. I remember Ted always called it UNIX/TS all caps. > > The thing you left out is how PWB 3.0 became System III. > > Two important issues. First with V7, AT&T (Al Arms) wrote the first > binary system redistribution license. The commercial folks were happy to > have a redistribution license, but the terms were not what they really > needed. Much of the issue was that AT&T was not the computer hardware or > software business and really did not understand the issues that the vendors > had. Professor Dennis Allison of Stanford, was consulting for almost all > of us in the computer industry at the time (for those that don't know > Dennis, around the same time he founded what is now called the Asilomar > Microprocessor Workshop (check out: > https://www.computerhistory.org/atchm/the-asilomar-microcomputer-workshop-and-the-billion-dollar-toilet-seat/ > ). > > Dennis arranged for a big meeting at Ricki's Hyatt in Palo Alto and > invited Al Arms and team, plus a representatives from his clients. I was > the techie with a lawyer from Tektronix in the room (as I have said in > other emails this it is only time I have been in a meeting with Bill > Gates). The folks I remember who were there: was Bill Munson and team from > DEC; Fred Clegg and Team from HP; Bob MetCalfe from 3Com; Gates and the > MSFT crew; folks from SCO and DG. There were some others, about 10 firms > in total; although I think if remember correctly, IBM was not among them > [This is the meeting where Gates famously exclaimed: "*You guys don't get > it. The only thing that matters in the software industry is volume*."]. > > BTW: The bits we were discussing was the upcoming release from USG, to be > called PWB 3.0 and they were for the PDP-11 only (which was fine, that was > what we all had been licensing already. We could still use things from > other places, because that is what those other places were all licensed to > have -- all was good in UNIX-land). > > Thus began a series of negotiations for a new license agreement that would > allow the HW vendors to better ship UNIX as a binary product: FWIW: Gates > wanted to pay $25/copy. The DEC, HP and DG folks laughed. $1K/copy was > fine by them, since their HW was typically $50-150K/system. > > Either shortly after or maybe during the negotiations time, Judge Green > ruled and AT&T got broken up. One of the things that occured is that AT&T > was now allowed to sell SW and more importantly their new 3B20 as a product > (against IBM and DEC). From a SW standpoint, AT&T Marketing did not like > the 'Programmers' moniker, feeling that it would limit who they could sell > too. So they rebranded the new software product 'System III.' > > Note the printing of the manuals had already begun, which is why the cover > of the manuals say System III, but the title pages say PWB 3.0. > > As other have said a few years later, another PWB release came out for the > Bell System, *a.k.a.* PWB 4.0; but this was not licensed outside. > > At some point later, negotiations had restarted on yet another license > with the System III licensees and AT&T. By the time that completed, yet > another release had been finished by USG. The biggest change was the > addition support for HW besides the PDP-11. In particular, the official USG > support for the VAX and the 3B20. What I forget, but I think in that > license you had to declare a system type and most licensees picked the VAX. > > By the time of release and finalization of the license, AT&T Marketing > which had already started the '*Consider it Standard*' campaign, called > the new release "System V." > > AT&T Marketing would stay with System V moniker from then on and we know > have SVR2, SVR3, SVR4, SVR5 in later years. > Yea, the detailed part of my history ends with the progeny of V7 (and I only have room for some, I've found maybe 3 dozen different systems that started out with V7 and then merge in System III or System V code for later versions or some variation on this theme). > >> Thanks for all your help with this topic and sorting things out. It's >> been quite helpful for my talk in a few weeks. >> >> Warner >> >> P.S. Would it be inappropriate to solicit feedback on an early version of >> my talk from this group? >> > I would suggest sending a pointer to this group to the slides and ask for > people to send you comments privately. > Works for me. Let me update based on this and Steve's email. > > >> I'm sure they would be rather keener on catching errors in my >> understanding of Unix history than just about any other forum... >> > Indeed - happy to help. > I am so very grateful for the help. > Clem > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Thu Sep 12 01:36:32 2019 From: clemc at ccc.com (Clem Cole) Date: Wed, 11 Sep 2019 11:36:32 -0400 Subject: [TUHS] PWB vs Unix/TS In-Reply-To: References: Message-ID: below... On Tue, Sep 10, 2019 at 11:53 PM Warner Losh wrote: > > "The Programmer's Workbench was started in 1973,[2] > by Evan Ivie > and Rudd Canaday to support a computer center for a 1000-employee Bell Labs > division" is what wikipedia says, though that reference is in a acm queue > article by Mashey... > That syncs and if Mash wrote the dates, I believe them I thought it was a year or two later by the time they were done. But it is what I said. PWB was done to support the mainframe shops. > but I've never actually used SCCS. > That's a shame - I still use it for simple things. Lots less overhead than things like git. Somebody rewrote it in C++ and you can google it. Larry's been trying to get me to switch to bitkeeper and I probably should, but I admit SCCS has been good enough for a long time and the commands are screwed in the roms in my fingers. > > Several timelines have, without references, Unix/TS or some variant of > that going back to the V4 time frame. It's at best murky. There's some > references in https://wiki.tuhs.org/doku.php?id=misc:snippets:mert1 including > the post by Dan DeJegar which I had trouble parsing the ins and outs of. > As I said, aps or Ted are more likely to be the sources. They were part of the original USG team. Steve just said he did not go over there until System V time (which was what I was afraid). And thanks for refreshing the bits in my brain... Dan DeJagar not Dale.... I'll look at this and see if I can parse it for you in any way. > Yea, the Columbus crew added a lot to the different versions, and merged > from them, according to the above link and a few other sources. > Yeah, Phil Karn and Mary Ann both talked about that -- Mary Ann is on this list she may be able to add some of the missing details. I was never 100% sure where Columbus fit into the puzzle, but that team did a lot of cool stuff. Real-Time was their thing. The Indiana Hill crew (Tom Bishop) did the 3B4000 and all of the SSI work linked to the support the ESS development. > Yes. There's some confusion as PWB and UNIX/TS become a USG thing that > turns into System III and then the influx of CB-UNIX that's added before > System V. How all that relates to USG, I'm quite unclear on still... > As I said, aps or Ted lived it from the USG side. I'll try to dig up Armando and see what he can tell you, > > From the above recollection of Dan DeJAger... > Interesting... as I said, let me look at what he says and see what I can add. > I've seen lots of references to UNIX/TS, but no versions, so this makes > some sense... And it appears they go back further than V6... > It's possible, the first I saw any of the results was on top of V6, when Ted brought some of it to CMU. > Yea, the detailed part of my history ends with the progeny of V7 (and I > only have room for some, I've found maybe 3 dozen different systems that > started out with V7 and then merge in System III or System V code for later > versions or some variation on this theme). > That's because that was what the external (commercial) licenses allowed. Each license subsumed the previous one. So if you had started a product based on V7 (like DEC, HP, and Microsoft) you could ship with the System III license (I remember that was >>huge<< issue with the vendors, which AT&T was not super happy to accept - again this is the start of the 'consider it standard' stuff and they wanted everyone to use the bits from Summit as the basis of their products, which was a problem because each vendor had its own value add. Later when OSF was created, this is part of the genesis of the 'Stable License Terms' in OSF's founding principles. So if you were a new company (say Masscomp or Stellar) from a legal standpoint you started with the latest release (System III for the former, SVR2 the later). BTW, Sun is an interesting case, which I get too in a minute. DEC/HP/MSFT had started their engineering development for Ultrix/HP-UX/Xenix on the original V7 license, so by the time of the System III negotiation complete that had already been shipping some amount of systems using V7 and their original licenses. What the System III license did was change the terms in some ways to help them. But since the engineering was solidly underweight for Ultrix, DEC kept their V7/BSD kernel, MSFT switched Xenix to System III based (and then sold the whole mess to SCO). HP kept the V7/BSD kernel, but added all the System III differences so it looked like System III the running program and used the System III command system for a user. At Masscomp, since we need to be on a 68K, we started with a V7/BSD kernel from MIT's RTS labs, called NU (which TI and Apple both used also BTW). The command system was originally basically System III based but added BSD commands as needed. I joined to start the VM work and we folded the RTU (real-time) stuff we had worked on with NU into 4.1 then 4.1C to be the kernel, added MP support and we shipped (and it is what Larry originally used). The company quickly got sucked in the AT&T vs BSD fight, since the AT&T and UCB command system were similar but different and about 1/3 of our customers were University (BSD) types and the other 1/2 US Gov/Commercial (att) and rest did not care. Like HP, at first we tried add switches and create a super set of commands (RTU 1.x). This was a losing battle for a small company so, we gave up, and our solution was "universes". I created something I called 'conditionally dependant symbolic links' (CDSL - which I would resurrect in Tru64 for the Cluster work) and we added the 'att' and 'ucb' commands to set a variable in the kernel. We then had two sets of commands (/usr/att and /usr/ucb). Of course, this caused a new set of problems of trying to do bug fixes in the two command streams [BTW: Pyramid would try the Universe trick also as did a couple of other folks; but I don't know how they implemented it - as I say, I did it with CDSL]. A couple of years later at Stellar we took a different tact. We started with the licensed kernel (SVR2) and hacked in what it was missing (SMP support, sockets, a new/parallel FS) and added any BSD commands that were not there, but left it as an otherwise System V system. As I say, Sun was interesting. They started as a firm after Masscomp, but shipped their first systems (Stanford Sun Terminal boards running UNIX) using Asa Romberger's V7 license (Unisoft). When they got their own UNIX license, it would have been a System III license like Masscomp the other folks at that point. From a technical stand point, they of course had BSD; but I think they also had some of the MIT/NU stuff (like Jack Test's C compiler and Tom Teixeria's 68k assembler). So SunOS was based on BSD while they shipped off an AT&T System III license (which was an anathema to AT&T marketing, although it was allowed in that license). Larry can tell us how much pressure they felt with the V7/BSD command systems in the market; but certainly since they originally sold to the Vax replacement market - it did not seem like it mattered (until later). When the SVR3 License came out, that was the 'best' from the licensee's standpoint. AT&T had finally backed off some of the more onerous terms, but if you were not grandfathered into with an original V7 license, you had to officially use their code -- although how strict and how/if they tried to enforce I don't know. (HP-UX was and still is a 'BSD' kernel from a structural standpoint, but the user would never know. I know IBM switch to the SVr3 license (in fact bought it out) and I believe both HP and DEC switched to using it to ship also (DEC was grandfathered to V7, so it was terms switch for them. I think at some point HP also bought out it licenses, although I do not believe DEC ever did, Sun was another story altogether). OSF would eventually use the IBM SVR3 license as its base [which makes me believe IBM must have had a V7 redistribution license too. Somebody like Charlie Saurer might know]. Anyway, IBM, DEC and HP all shipped OSF 'licensed' systems although only DEC would switch to an OSF/1 based kernel. The quick story on Sun is that as Larry has pointed out there was a deal at the CEO level that brought SunOS and SVR4 together to create what would eventually would become Solaris 2.0 (I'll let Larry can fill in those details, as it was not truly SVR4 nor SunOS when it was done). AT&T, ney Novell, ney SCO would eventually create SVR5 which was different yet. Chorus was working on what was to be SVR6 to compete with the OSF RI's Mach4 based system, but I don't think that ever shipped. -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.winalski at gmail.com Thu Sep 12 02:05:37 2019 From: paul.winalski at gmail.com (Paul Winalski) Date: Wed, 11 Sep 2019 12:05:37 -0400 Subject: [TUHS] PWB vs Unix/TS In-Reply-To: References: Message-ID: >On 9/10/19, Clem Cole wrote: > > SCCS was important and the RJE support was important because that was the > system being used and it made a huge impression on AT&T staff. A terminal > to a UNIX box was way cheaper and to the IBM and people were so much more > productive. IBM RJE stations were card-based, with a card reader, card punch, and line printer. Communication with the mainframe was via half-duplex bisync. Certainly editing programs on a UNIX terminal would be WAY more productive than punch cards! -Paul W. From sauer at technologists.com Thu Sep 12 02:55:00 2019 From: sauer at technologists.com (Charles H Sauer) Date: Wed, 11 Sep 2019 11:55:00 -0500 Subject: [TUHS] IBM Unix source licenses [was Re: PWB vs Unix/TS In-Reply-To: References: Message-ID: On 9/11/2019 10:36 AM, Clem Cole wrote: ... > OSF would eventually use the IBM SVR3 license as its base [which > makes me believe IBM must have had a V7 redistribution license too. > Somebody like Charlie Saurer might know].  Anyway, IBM, DEC and HP all > shipped OSF 'licensed' systems although only DEC would switch to an > OSF/1 based kernel. "Sauer" idk. As far as I know, IBM Austin did not get source licenses until System V. Before Clay Cipione became the AIX development manager in the AFWS -> RT transition, Austin did not have source licenses, as far as I know. Clay insisted that we have source. It is plausible that Don Rozenberg had V7 license at Yorktown and/or ACIS had V7 license for BSD stuff. I'm blind copying Clay and another AIX alumnus that might know for sure. Charlie -- voice: +1.512.784.7526 e-mail: sauer at technologists.com fax: +1.512.346.5240 Web: https://technologists.com/sauer/ Facebook/Google/Skype/Twitter: CharlesHSauer From ron at ronnatalie.com Thu Sep 12 03:14:42 2019 From: ron at ronnatalie.com (ron at ronnatalie.com) Date: Wed, 11 Sep 2019 13:14:42 -0400 Subject: [TUHS] PWB vs Unix/TS In-Reply-To: References: Message-ID: <009801d568c4$6ad6abf0$408403d0$@ronnatalie.com> And SCCS was way easier than anything you could do with cards. My first experience with PWB was maintaining the source code and QA for a project that was targeted at RSX-11M. Amusingly, it as my job twice at different facilities (BRL and Rutgers) to get rid of all the card processing equipment. I finally offered to move the Cyber RJE station and its accompanying keypunch machine into the office of the last person using it. He finally decided he'd make the jump to timesharing. Amusingly, nobody figured out how to make CyberRJE work from a PDP-11. The labs had purchased a half dozen PDP-11/34s with a optical card reader, line printer, and graphical display (Vector General) and a DQ-11 and 56K (them was fast in those days) short haul modem. Of course, in Mike Muuss's typical style, he said we could use them. They all got recycled into graphics workstations. Mike wrote a driver for the Vector General and the first ersatz "BRL CAD" package. We still used the card reader to read in old "COMGEO" graphic model decks which CAD could edit. UNIX for the 11/34 (a hybrid V6 kernel), we installed overlays. When TCP/IP came around which needed another segment register for mbufs, we just couldn't make it work anymore on a non-split-I/D machine. The VGs got moved over to the 11/70's and I recycled the 34's into internet routers. We actually used the DQ's and modems for internal communciations for a while until we subsequently bought IMPs and later Proteon rings. From rich.salz at gmail.com Thu Sep 12 03:49:27 2019 From: rich.salz at gmail.com (Richard Salz) Date: Wed, 11 Sep 2019 13:49:27 -0400 Subject: [TUHS] PWB vs Unix/TS In-Reply-To: References: Message-ID: > course, this caused a new set of problems of trying to do bug fixes in the two command streams [BTW: Pyramid would try the Universe trick also as did a couple of other folks; but I don't know how they implemented it - as I say, I did it with CDSL]. Yes, /bin was a CDSL to /.attbin or /.ucbbin depending on a flag in the proc structure. The "universe" command queried/set the bit. The Pyramid kernel was a BSD kernel with the missing ATT syscalls added. The boot mechanism, at least at first, was BSD. I did things like "rm -rf" /.attbin, /usr/.attinclude, etc., and the system was fine. :) -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron at ronnatalie.com Thu Sep 12 03:52:28 2019 From: ron at ronnatalie.com (ron at ronnatalie.com) Date: Wed, 11 Sep 2019 13:52:28 -0400 Subject: [TUHS] PWB vs Unix/TS In-Reply-To: References: Message-ID: <009e01d568c9$afd2ca40$0f785ec0$@ronnatalie.com> The Pyramid OS used “conditional symlinks” if I recalled to implement switching the bin directories. The UCLA LOCUS/IBM Transparent Computing Facility switched versions of executables by using a “magic” directory that was conditional on the cpu type. From: TUHS On Behalf Of Richard Salz Sent: Wednesday, September 11, 2019 1:49 PM To: Clem Cole Cc: The Eunuchs Hysterical Society Subject: Re: [TUHS] PWB vs Unix/TS > course, this caused a new set of problems of trying to do bug fixes in the two command streams [BTW: Pyramid would try the Universe trick also as did a couple of other folks; but I don't know how they implemented it - as I say, I did it with CDSL]. Yes, /bin was a CDSL to /.attbin or /.ucbbin depending on a flag in the proc structure. The "universe" command queried/set the bit. The Pyramid kernel was a BSD kernel with the missing ATT syscalls added. The boot mechanism, at least at first, was BSD. I did things like "rm -rf" /.attbin, /usr/.attinclude, etc., and the system was fine. :) -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Thu Sep 12 04:11:01 2019 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 11 Sep 2019 11:11:01 -0700 Subject: [TUHS] PWB vs Unix/TS In-Reply-To: References: Message-ID: <20190911181101.GF3143@mcvoy.com> On Wed, Sep 11, 2019 at 11:36:32AM -0400, Clem Cole wrote: > > but I've never actually used SCCS. > > > That's a shame - I still use it for simple things. Lots less overhead than > things like git. Somebody rewrote it in C++ and you can google it. > Larry's been trying to get me to switch to bitkeeper and I probably should, > but I admit SCCS has been good enough for a long time and the commands are > screwed in the roms in my fingers. SCCS is awesome, I'll post why in a different thread. It is light years better than RCS, Tichy lied. > As I say, Sun was interesting. They started as a firm after Masscomp, but > shipped their first systems (Stanford Sun Terminal boards running UNIX) > using Asa Romberger's V7 license (Unisoft). When they got their own UNIX > license, it would have been a System III license like Masscomp the other > folks at that point. From a technical stand point, they of course had > BSD; but I think they also had some of the MIT/NU stuff (like Jack Test's C > compiler and Tom Teixeria's 68k assembler). So SunOS was based on BSD > while they shipped off an AT&T System III license (which was an anathema to > AT&T marketing, although it was allowed in that license). Larry can tell > us how much pressure they felt with the V7/BSD command systems in the > market; but certainly since they originally sold to the Vax replacement > market - it did not seem like it mattered (until later). So I'm not sure that I can add that much. I never used SunOS 1.x, the first version I used was SunOS 2.x and that was brief. SunOS 3.x was much better, it was the one where people started calling SunOS "a bug fixed BSD" I believe. I always talk up the glory days of Sun but one thing they got wrong, in my opinion, was this incessant desire to not ship X11 as the windowing system. In those days you ran sunview, which was a decent enough window system but it wasn't X11. Like pretty much everyone else, I got the X10 and later X11 sources and did a "make world". Because I wasn't just running on Suns, there were the IBM RTs, there were microvaxes, there were Masscomps, etc. You wanted to be able to have the same startup files on all of the machines and that meant X windows. Building X was a lesson in reality. The graphics drivers were never as good as the ones that Sun shipped, the code didn't always build so you got a lesson in #ifdef DOESNT_WORK_SUNOS_35, you learned that you should just try stuff and see if the code that didn't compile was even used, mostly it wasn't. I didn't get to Sun until 4.0 had come out, that was the release that had the new VM system, vnodes, vfs layer, etc. Vnodes might have been in the 3.x tree, not sure. > The quick story on Sun is that as Larry has pointed out there was a deal at > the CEO level that brought SunOS and SVR4 together to create what would > eventually would become Solaris 2.0 (I'll let Larry can fill in those > details, as it was not truly SVR4 nor SunOS when it was done). Yeah, that happened about 5 years after I got there. The terms of the deal were very hush hush, my boss was the VP in charge of all server hardware and he paid me for 6 months to go argue with Scooter, Raduchel, basically everyone in the top floor of PAL-1, all the execs. So even he didn't know. The problem was that Sun was in financial hot water and AT&T wanted SVR4 to be the industry standard. At the time, there was no question that SunOS 4.x was the industry standard. Pretty much anything you found on comp.sources or elsewhere, just compiled on SunOS. AT&T didn't like that, thought they were going to get rich from SVR4, so they cut a deal with Sun. They bought $200M of Sun stock at 35% above market and in return Sun agreed to dump SunOS and go with SVR4. Which was, in my opinion, the beginning of the end for Sun. It's close to 30 years later and I'm still butthurt over that. It would have been much better if Sun had licensed their source base to AT&T and then AT&T could have leveraged the industry standard. Shoulda, coulda, woulda. From rich.salz at gmail.com Thu Sep 12 04:18:08 2019 From: rich.salz at gmail.com (Richard Salz) Date: Wed, 11 Sep 2019 14:18:08 -0400 Subject: [TUHS] PWB vs Unix/TS In-Reply-To: <20190911181101.GF3143@mcvoy.com> References: <20190911181101.GF3143@mcvoy.com> Message-ID: > > It would have been > much better if Sun had licensed their source base to AT&T and then > AT&T could have leveraged the industry standard. Interesting to speculate if that would have sped up the creation of OSF or delayed/prevented it. I think the former. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Thu Sep 12 04:54:18 2019 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 11 Sep 2019 11:54:18 -0700 Subject: [TUHS] PWB vs Unix/TS In-Reply-To: References: <20190911181101.GF3143@mcvoy.com> Message-ID: <20190911185418.GA2046@mcvoy.com> On Wed, Sep 11, 2019 at 02:18:08PM -0400, Richard Salz wrote: > > > > It would have been > > much better if Sun had licensed their source base to AT&T and then > > AT&T could have leveraged the industry standard. > > > Interesting to speculate if that would have sped up the creation of OSF or > delayed/prevented it. I think the former. You're probably right but it wouldn't have mattered. SunOS was very popular and had a good VM system with a working mmap. Once it became official AT&T source everyone would have moved to it over time. Sort of obvious in retrospect. Nobody, that I know of, considered it at the time. I proposed open sourcing it. From scj at yaccman.com Thu Sep 12 07:05:34 2019 From: scj at yaccman.com (Steve Johnson) Date: Wed, 11 Sep 2019 14:05:34 -0700 Subject: [TUHS] PWB vs Unix/TS In-Reply-To: <20190911185418.GA2046@mcvoy.com> Message-ID: I tried very hard to get the front end of pcc released to open source (we didn't call it then) because after K&R was printed, everyone and their cat started writing C compilers based on the appendix.  I had strong management support for this move, but the lawyers were still in their "lets study this for 10 years and then it will be clear what we should have done" mode.  So we ended up with far pointers and ten years of standards committee agony.  It's so obvious to me now, as then, that such specs should be executable (although not necessarily product-quality in speed or things like error messages).  But it's also obvious that the desire to compete by adding glitter and icing runs strong nontheless. Steve ----- Original Message ----- From: "Larry McVoy" To:"Richard Salz" Cc:"The Eunuchs Hysterical Society" Sent:Wed, 11 Sep 2019 11:54:18 -0700 Subject:Re: [TUHS] PWB vs Unix/TS On Wed, Sep 11, 2019 at 02:18:08PM -0400, Richard Salz wrote: > > > > It would have been > > much better if Sun had licensed their source base to AT&T and then > > AT&T could have leveraged the industry standard. > > > Interesting to speculate if that would have sped up the creation of OSF or > delayed/prevented it. I think the former. You're probably right but it wouldn't have mattered. SunOS was very popular and had a good VM system with a working mmap. Once it became official AT&T source everyone would have moved to it over time. Sort of obvious in retrospect. Nobody, that I know of, considered it at the time. I proposed open sourcing it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From scj at yaccman.com Thu Sep 12 07:34:46 2019 From: scj at yaccman.com (Steve Johnson) Date: Wed, 11 Sep 2019 14:34:46 -0700 Subject: [TUHS] PWB vs Unix/TS In-Reply-To: <20190911185418.GA2046@mcvoy.com> Message-ID: <04b40f1648473af7350ff61e45aacecba6eba49d@webmail.yaccman.com> One of my co-workers, Serge Vakulenko,  just gave me a small gift -- a 1 x 2 inch computer chip that runs a version of BSD Unix, complete with compilers and editors.  It's powered by the USB port and you connect with it at 115200 baud (10,000 x faster than a model 33 TTY!).  It has a surprisingly big file system and 128K of RAM, half of which is given to the system.  There are lots of BSD games, including a game of Go Fish that I wrote for my son over 50 years ago.   It was interesting to me to look at that early C code.  I was surprised at the nonzero number of gotos (5). The source is on https://github.com/RetroBSD/retrobsd/blob/master/src/games/fish.c if you are interested... For extra credit, see if you can find the bug that Serge found in this 50-year-old code, and figure out how the program seems to work OK anyway  (Hint: type mismatch).  There clearly was a good reason to invent Lint and declarations and header files... Steve PS: if you'd like a look at the chip, google PIC32-RETROBSD.  The CPU is a MIPS microcontroller. ----- Original Message ----- From: "Larry McVoy" To:"Richard Salz" Cc:"The Eunuchs Hysterical Society" Sent:Wed, 11 Sep 2019 11:54:18 -0700 Subject:Re: [TUHS] PWB vs Unix/TS On Wed, Sep 11, 2019 at 02:18:08PM -0400, Richard Salz wrote: > > > > It would have been > > much better if Sun had licensed their source base to AT&T and then > > AT&T could have leveraged the industry standard. > > > Interesting to speculate if that would have sped up the creation of OSF or > delayed/prevented it. I think the former. You're probably right but it wouldn't have mattered. SunOS was very popular and had a good VM system with a working mmap. Once it became official AT&T source everyone would have moved to it over time. Sort of obvious in retrospect. Nobody, that I know of, considered it at the time. I proposed open sourcing it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Thu Sep 12 07:44:15 2019 From: clemc at ccc.com (Clem Cole) Date: Wed, 11 Sep 2019 17:44:15 -0400 Subject: [TUHS] PWB vs Unix/TS In-Reply-To: <009e01d568c9$afd2ca40$0f785ec0$@ronnatalie.com> References: <009e01d568c9$afd2ca40$0f785ec0$@ronnatalie.com> Message-ID: On Wed, Sep 11, 2019 at 1:52 PM wrote: > The Pyramid OS used “conditional symlinks” if I recalled to implement > switching the bin directories. > > The UCLA LOCUS/IBM Transparent Computing Facility switched versions of > executables by using a “magic” directory that was conditional on the cpu > type. > Right, TCF did that (Bruce built them IIRC). As I said, I resurrected CSDL's from Masscomp at Locus for TNC which was more general and lost less intrusive (which is how they landed in Tru64 when we sold the TNC to DEC to become TruClusters and I would join them). As for CDSL, I had generalized it for LCC from what I did at Masscomp years before. FWIW: I still think they are a cute idea and solve a number of problems, but alas they are no longer ;-) -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Thu Sep 12 07:50:59 2019 From: clemc at ccc.com (Clem Cole) Date: Wed, 11 Sep 2019 17:50:59 -0400 Subject: [TUHS] PWB vs Unix/TS In-Reply-To: <20190911181101.GF3143@mcvoy.com> References: <20190911181101.GF3143@mcvoy.com> Message-ID: On Wed, Sep 11, 2019 at 2:11 PM Larry McVoy wrote: > The problem was that Sun was in financial hot water and AT&T wanted SVR4 > to be the industry standard. ... It would have been > much better if Sun had licensed their source base to AT&T and then > AT&T could have leveraged the industry standard. I think those two statements say everything. Sun was not in a position to negotiate and AT&T desperately wanted SVR4 to be the standard - I think it was corporate pride. (which I also think was mixed up the BSDi/UCB case too - if they had let it go it would have been a darned site smarter). If AT&T could have swallowed and excepted somebody other than them having the 'high order bit' it might have worked. As you say, leveraged the industry standard. Instead is just added to the fighting. -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Thu Sep 12 07:57:51 2019 From: clemc at ccc.com (Clem Cole) Date: Wed, 11 Sep 2019 17:57:51 -0400 Subject: [TUHS] PWB vs Unix/TS In-Reply-To: <20190911185418.GA2046@mcvoy.com> References: <20190911181101.GF3143@mcvoy.com> <20190911185418.GA2046@mcvoy.com> Message-ID: On Wed, Sep 11, 2019 at 2:54 PM Larry McVoy wrote: > You're probably right but it wouldn't have mattered. SunOS was very popular > and had a good VM system with a working mmap. Once it became official > AT&T source everyone would have moved to it over time. > But Sun would have to accept the economics of Intel processor sooner. Which is funny because RoadRunner was a pretty neat machine. They had Solaris/386 but was way too little too late. Sparc was a blind spot I fear. > > Sort of obvious in retrospect. Nobody, that I know of, considered it at the > time. Maybe -- as I said, i386 would have been the key. > I proposed open sourcing it. I agree, that might have worked. And then if they wanted to be in the HW biz, let the FOSS world deal with Intel. -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Thu Sep 12 07:59:55 2019 From: clemc at ccc.com (Clem Cole) Date: Wed, 11 Sep 2019 17:59:55 -0400 Subject: [TUHS] PWB vs Unix/TS In-Reply-To: References: <20190911181101.GF3143@mcvoy.com> Message-ID: On Wed, Sep 11, 2019 at 2:18 PM Richard Salz wrote: > Interesting to speculate if that would have sped up the creation of OSF or > delayed/prevented it. I think the former. > It would have been created either way. The codebase was not the issue. The license terms and how the industry was going to play out (*i.e.* the economics) is what created OSF. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Thu Sep 12 08:49:35 2019 From: dave at horsfall.org (Dave Horsfall) Date: Thu, 12 Sep 2019 08:49:35 +1000 (EST) Subject: [TUHS] PWB vs Unix/TS In-Reply-To: <20190911181101.GF3143@mcvoy.com> References: <20190911181101.GF3143@mcvoy.com> Message-ID: On Wed, 11 Sep 2019, Larry McVoy wrote: > SCCS is awesome, I'll post why in a different thread. It is light years > better than RCS, Tichy lied. Agreed; I used it for years, then was forced to use RCS in my next job :-( -- Dave From krewat at kilonet.net Thu Sep 12 08:50:42 2019 From: krewat at kilonet.net (Arthur Krewat) Date: Wed, 11 Sep 2019 18:50:42 -0400 Subject: [TUHS] PWB vs Unix/TS In-Reply-To: References: <20190911181101.GF3143@mcvoy.com> <20190911185418.GA2046@mcvoy.com> Message-ID: On 9/11/2019 5:57 PM, Clem Cole wrote: > > > On Wed, Sep 11, 2019 at 2:54 PM Larry McVoy > wrote: > > You're probably right but it wouldn't have mattered. SunOS was > very popular > and had a good VM system with a working mmap.  Once it became official > AT&T source everyone would have moved to it over time. > > But Sun would have to accept the economics of Intel processor sooner.  > Which is funny because RoadRunner was a pretty neat machine.  They had > Solaris/386 but was way too little too late.   Sparc was a blind spot > I fear. > One of the reasons I went into Solaris whole-hog during the SunOS->Solaris thing was the availability of a version that ran on Intel. I ran an Intel SVR4.2 (Consensys) BBS in the early 90's, with USENET/NEWS, using a SunOS IPX as a back-end file server. Of course, a few of my customers who did CAD were using Sun workstations, and everything moved to Solaris, so there was also that. Once Solaris X86 came out, I jumped at the chance. I'm still administering PeopleSoft and Oracle on Solaris 11 X86. But sadly, time to move on. Although, Oracle says Solaris support is continuing out until 2031, with extended support to 2034, with Solaris Cluster 4.x following suit. But at $1000/socket for support just for the OS, that pricing is a hard to take when it comes to CentOS/Redhat/Oracle Linux. ak -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Thu Sep 12 13:43:46 2019 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 11 Sep 2019 20:43:46 -0700 Subject: [TUHS] SCCS In-Reply-To: References: <20190911181101.GF3143@mcvoy.com> Message-ID: <20190912034346.GJ2046@mcvoy.com> On Thu, Sep 12, 2019 at 08:49:35AM +1000, Dave Horsfall wrote: > On Wed, 11 Sep 2019, Larry McVoy wrote: > > >SCCS is awesome, I'll post why in a different thread. It is light years > >better than RCS, Tichy lied. > > Agreed; I used it for years, then was forced to use RCS in my next job :-( Marc Rochkind is on the list, I believe I invited him, but he can spell check what I'm about to say. SCCS is awesome. People have no idea how good it is as a version control system because Walter Tichy got his PhD for writing RCS and claiming it was better (don't get me started on how wrong that was). Let me start with how RCS works. You all know about diff and patch, someone does a diff, produces a patch, and Larry Wall wrote patch(1) that takes the patch and file and applies it. In a straight line history here is how RCS works. The most recent version of the file is stored in whole, the delta behind that is a reverse patch to get to that, same for the next delta behind that and so on. Branches in RCS are forward patches. Sort of. You start with the whole file that is the most recent version, reverse patch your way back to the branch point, and then forward patch your way down to the most recent version on the branch. Yeah, branches in RCS suck, very expensive. So why is SCCS awesome? It is an entirely different approach. SCCS is a set based system, for any version, there is a set of deltas that are in that version and you apply them to the file part of the data. Huh? What does that mean? OK, you've all seen SCCS revisions, 1.1, 1.2, 1.3, 1.3.1.1, etc. Yeah, that's for humans (and truth be told those revs are not that great). For SCCS internally there are serial numbers. All those are are a monotonically increasing number, doesn't matter if you are on the trunk or on a branch, each time you add a delta the internal number, or serial, is the last serial plus 1. When you go to check out a version of the file, that's the set. It's the set of serials that make up that file. If you wanted 1.3 and there are no branches, the set is the serial of 1.3 (3) and the parent of 1.3 which is 1.2 (2) and 1.1 (1). So your set is 1,2,3. Here is the awesome part. The way the data is stored in SCCS is nothing like patches, it's what we call a weave. All versions of the file are woven together in the following way. There are 3 operators: insert: ^AI delete: ^AD end: ^AE So if you checked in a file that looked like I love TUHS The weave would be ^AI 1 I love TUHS ^AE 1 Lets say that Clem changed that to I really love TUHS The new weave would look like: ^AI 1 I ^AI 2 really ^AE 2 love TUHS ^AE 1 and if I changed it to I *really* love TUHS the weave looks like ^AI 1 I ^AD 3 ^AI 2 really ^AE 2 ^AE 3 ^AI 3 *really* ^AE 3 love TUHS ^AE 1 So a checkout is 2 things, build up the set of serials that need to be active for this checkout, and walk the weave. For each serial you see you are either in this set and I need to do what it says, or this is not in my set and I need to do the opposite of what it says. So that is really really fast compared to RCS. RCS reads the whole file and has to do compute, SCCS reads the whole file and does a very tiny fraction of that compute, so tiny that you can't measure it compared to reading the file. But wait, it gets better, much better. Lets talk about branches and merges. RCS is copy by value across a merge, SCCS is copy by reference. Marc thought about the set stuff enough to realize wouldn't be cool if you could manipulate the set. He added include and exclude operators. Imagine if you and I were having an argument about some video being checked in. You checked it in, I deleted it, you checked it in, I deleted it. Suppose that was a 1GB video. In RCS, each time we argued that is another GB, we did that 4 times, there 4GB of diffs in the history. In SCCS, you could do that with includes and excludes, those 4 times would be about 30 bytes because all they are doing is saying "In the set", "Not in the set". Cool I guess but what is the real life win? Merges. In a weave based system like SCCS you can add 1GB on a branch and I can merge that onto the trunk and all I did was say "include your serials". I didn't copy your work, I referenced it. Tiny meta data to do so. That has more implications than you might think. Think annotations. git blame, know that? It shows who did what? Yeah, well git is copy by value just like RCS. It's not just about the space used, it is also about who did what. If bwk did one thing and dmr did another thing and little old lm merged dmr's stuff into the bwk trunk, in a copy by value system, all of dmr's work will look like I wrote it in bwk's trunk. SCCS avoids that. If I merged dmr's work into bwk's tree, if it all automerged, annotations would show it all as dmr's work, yeah, I did the merge but I didn't do anything so I don't show up in annotations. If there was a conflict and I had to resolve that conflict, then that, and that alone, would show up as my work. For Marc, I worked with Rick Smith, he found me after I had done a reimplentation of SCCS. He has forgotten more about weaves than I will ever know. But he was really impressed with my code (which you can go see at bitkeeper.org, and it is not my code, it is my teams code, Rick bugfixed all my mistakes) because I embraced the set thing and the way I wrote the code you could have N of my data structures and pulled out N versions of the file in one pass. He had not seen that before, to me it just seemed the most natural way to do it. SCCS is awesome, Marc should be held up as a hero for that. Most people have no idea how much better it is as a format, to this day people still do it wrong. The hg people at facebook sort of got it, they did an import of SCCS (it was BitKeeper which is SCCS on super steriods). But it is rare that someone gets it. I wanted Marc to know we got it. --lm From ggm at algebras.org Thu Sep 12 14:20:08 2019 From: ggm at algebras.org (George Michaelson) Date: Thu, 12 Sep 2019 11:20:08 +0700 Subject: [TUHS] SCCS In-Reply-To: <20190912034346.GJ2046@mcvoy.com> References: <20190911181101.GF3143@mcvoy.com> <20190912034346.GJ2046@mcvoy.com> Message-ID: If you want to be trendy, call this an event stream, and say its eventually consistent. What Larry and the other RCS haters forget is that back in the day, when we all had more hair, RCS was --->FAST<--- and SCCS was S.L.O.W. because running forward edits on a base state of 1000 edits is slow. Since the majority action is increment +1 on the head state the RCS model, whilst broken in many ways was FAST -G On Thu, Sep 12, 2019 at 10:44 AM Larry McVoy wrote: > > On Thu, Sep 12, 2019 at 08:49:35AM +1000, Dave Horsfall wrote: > > On Wed, 11 Sep 2019, Larry McVoy wrote: > > > > >SCCS is awesome, I'll post why in a different thread. It is light years > > >better than RCS, Tichy lied. > > > > Agreed; I used it for years, then was forced to use RCS in my next job :-( > > Marc Rochkind is on the list, I believe I invited him, but he can spell > check what I'm about to say. > > SCCS is awesome. People have no idea how good it is as a version control > system because Walter Tichy got his PhD for writing RCS and claiming it > was better (don't get me started on how wrong that was). > > Let me start with how RCS works. You all know about diff and patch, > someone does a diff, produces a patch, and Larry Wall wrote patch(1) > that takes the patch and file and applies it. In a straight line > history here is how RCS works. The most recent version of the file > is stored in whole, the delta behind that is a reverse patch to get > to that, same for the next delta behind that and so on. > > Branches in RCS are forward patches. Sort of. You start with the > whole file that is the most recent version, reverse patch your way > back to the branch point, and then forward patch your way down to > the most recent version on the branch. > > Yeah, branches in RCS suck, very expensive. > > So why is SCCS awesome? It is an entirely different approach. > SCCS is a set based system, for any version, there is a set > of deltas that are in that version and you apply them to the > file part of the data. > > Huh? What does that mean? OK, you've all seen SCCS revisions, 1.1, > 1.2, 1.3, 1.3.1.1, etc. Yeah, that's for humans (and truth be told those > revs are not that great). For SCCS internally there are serial numbers. > All those are are a monotonically increasing number, doesn't matter > if you are on the trunk or on a branch, each time you add a delta the > internal number, or serial, is the last serial plus 1. > > When you go to check out a version of the file, that's the set. > It's the set of serials that make up that file. If you wanted > 1.3 and there are no branches, the set is the serial of 1.3 (3) > and the parent of 1.3 which is 1.2 (2) and 1.1 (1). So your set > is 1,2,3. > > Here is the awesome part. The way the data is stored in SCCS > is nothing like patches, it's what we call a weave. All versions > of the file are woven together in the following way. There are > 3 operators: > > insert: ^AI > delete: ^AD > end: ^AE > > So if you checked in a file that looked like > > I > love > TUHS > > The weave would be > > ^AI 1 > I > love > TUHS > ^AE 1 > > Lets say that Clem changed that to > > I > really > love > TUHS > > The new weave would look like: > > ^AI 1 > I > ^AI 2 > really > ^AE 2 > love > TUHS > ^AE 1 > > and if I changed it to > > I > *really* > love > TUHS > > the weave looks like > > ^AI 1 > I > ^AD 3 > ^AI 2 > really > ^AE 2 > ^AE 3 > ^AI 3 > *really* > ^AE 3 > love > TUHS > ^AE 1 > > So a checkout is 2 things, build up the set of serials that need to be > active for this checkout, and walk the weave. For each serial you see > you are either in this set and I need to do what it says, or this is > not in my set and I need to do the opposite of what it says. > > So that is really really fast compared to RCS. RCS reads the whole > file and has to do compute, SCCS reads the whole file and does a > very tiny fraction of that compute, so tiny that you can't measure > it compared to reading the file. > > But wait, it gets better, much better. Lets talk about branches > and merges. RCS is copy by value across a merge, SCCS is copy by > reference. Marc thought about the set stuff enough to realize > wouldn't be cool if you could manipulate the set. He added include > and exclude operators. > > Imagine if you and I were having an argument about some video being > checked in. You checked it in, I deleted it, you checked it in, I deleted > it. Suppose that was a 1GB video. In RCS, each time we argued that is > another GB, we did that 4 times, there 4GB of diffs in the history. > > In SCCS, you could do that with includes and excludes, those 4 times > would be about 30 bytes because all they are doing is saying "In the > set", "Not in the set". > > Cool I guess but what is the real life win? Merges. In a weave based > system like SCCS you can add 1GB on a branch and I can merge that onto > the trunk and all I did was say "include your serials". I didn't copy > your work, I referenced it. Tiny meta data to do so. > > That has more implications than you might think. Think annotations. > git blame, know that? It shows who did what? Yeah, well git is > copy by value just like RCS. It's not just about the space used, > it is also about who did what. If bwk did one thing and dmr did > another thing and little old lm merged dmr's stuff into the bwk > trunk, in a copy by value system, all of dmr's work will look like > I wrote it in bwk's trunk. > > SCCS avoids that. If I merged dmr's work into bwk's tree, if it > all automerged, annotations would show it all as dmr's work, yeah, > I did the merge but I didn't do anything so I don't show up in > annotations. If there was a conflict and I had to resolve that > conflict, then that, and that alone, would show up as my work. > > For Marc, I worked with Rick Smith, he found me after I had done a > reimplentation of SCCS. He has forgotten more about weaves than I will > ever know. But he was really impressed with my code (which you can > go see at bitkeeper.org, and it is not my code, it is my teams code, > Rick bugfixed all my mistakes) because I embraced the set thing and the > way I wrote the code you could have N of my data structures and pulled > out N versions of the file in one pass. He had not seen that before, > to me it just seemed the most natural way to do it. > > SCCS is awesome, Marc should be held up as a hero for that. Most people > have no idea how much better it is as a format, to this day people still > do it wrong. The hg people at facebook sort of got it, they did an > import of SCCS (it was BitKeeper which is SCCS on super steriods). > But it is rare that someone gets it. I wanted Marc to know we got it. > > --lm From nobozo at gmail.com Thu Sep 12 14:28:25 2019 From: nobozo at gmail.com (Jon Forrest) Date: Wed, 11 Sep 2019 21:28:25 -0700 Subject: [TUHS] SCCS In-Reply-To: <20190912034346.GJ2046@mcvoy.com> References: <20190911181101.GF3143@mcvoy.com> <20190912034346.GJ2046@mcvoy.com> Message-ID: I used both RCS and SCCS in the early days (e.g. 1985 - 1991). RCS was what we used at Britton-Lee in the group that Eric Allman was part of. SCCS is what we used at Sybase as it was gaining popularity. This was so long ago that I don't remember all the details but I found that RCS was much easier to use, especially in an environment that didn't do much merging. Instead we used labels (or tags, I forget what they were called) to mark which files were part of which release. Doing this was much harder in SCCS, which contributed to the mess that was Sybase software engineering. Of course, all this could be explained by Eric's deep knowledge of RCS, and the lack of somebody with Eric's knowledge at Sybase. But, to me, an early adopter of source code control who wasn't overly interested in speed, RCS was much easier to use. Jon From lm at mcvoy.com Thu Sep 12 14:31:45 2019 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 11 Sep 2019 21:31:45 -0700 Subject: [TUHS] [SPAM] Re: SCCS In-Reply-To: References: <20190911181101.GF3143@mcvoy.com> <20190912034346.GJ2046@mcvoy.com> Message-ID: <20190912043145.GA12480@mcvoy.com> If you have actual data that shows RCS to be faster I would like to see that. RCS read the whole file. It could have been faster, it could have put the offset into the file where the most recent version begain. But it didn't. It read the entire file. RCS was not faster and I am happy to go get the code and prove that. "because running forward edits on a base state of 1000 edits is slow." means you don't get how SCCS works. On Thu, Sep 12, 2019 at 11:20:08AM +0700, George Michaelson wrote: > If you want to be trendy, call this an event stream, and say its > eventually consistent. > > What Larry and the other RCS haters forget is that back in the day, > when we all had more hair, RCS was --->FAST<--- and SCCS was S.L.O.W. > > because running forward edits on a base state of 1000 edits is slow. > Since the majority action is increment +1 on the head state the RCS > model, whilst broken in many ways > was FAST > > -G > > On Thu, Sep 12, 2019 at 10:44 AM Larry McVoy wrote: > > > > On Thu, Sep 12, 2019 at 08:49:35AM +1000, Dave Horsfall wrote: > > > On Wed, 11 Sep 2019, Larry McVoy wrote: > > > > > > >SCCS is awesome, I'll post why in a different thread. It is light years > > > >better than RCS, Tichy lied. > > > > > > Agreed; I used it for years, then was forced to use RCS in my next job :-( > > > > Marc Rochkind is on the list, I believe I invited him, but he can spell > > check what I'm about to say. > > > > SCCS is awesome. People have no idea how good it is as a version control > > system because Walter Tichy got his PhD for writing RCS and claiming it > > was better (don't get me started on how wrong that was). > > > > Let me start with how RCS works. You all know about diff and patch, > > someone does a diff, produces a patch, and Larry Wall wrote patch(1) > > that takes the patch and file and applies it. In a straight line > > history here is how RCS works. The most recent version of the file > > is stored in whole, the delta behind that is a reverse patch to get > > to that, same for the next delta behind that and so on. > > > > Branches in RCS are forward patches. Sort of. You start with the > > whole file that is the most recent version, reverse patch your way > > back to the branch point, and then forward patch your way down to > > the most recent version on the branch. > > > > Yeah, branches in RCS suck, very expensive. > > > > So why is SCCS awesome? It is an entirely different approach. > > SCCS is a set based system, for any version, there is a set > > of deltas that are in that version and you apply them to the > > file part of the data. > > > > Huh? What does that mean? OK, you've all seen SCCS revisions, 1.1, > > 1.2, 1.3, 1.3.1.1, etc. Yeah, that's for humans (and truth be told those > > revs are not that great). For SCCS internally there are serial numbers. > > All those are are a monotonically increasing number, doesn't matter > > if you are on the trunk or on a branch, each time you add a delta the > > internal number, or serial, is the last serial plus 1. > > > > When you go to check out a version of the file, that's the set. > > It's the set of serials that make up that file. If you wanted > > 1.3 and there are no branches, the set is the serial of 1.3 (3) > > and the parent of 1.3 which is 1.2 (2) and 1.1 (1). So your set > > is 1,2,3. > > > > Here is the awesome part. The way the data is stored in SCCS > > is nothing like patches, it's what we call a weave. All versions > > of the file are woven together in the following way. There are > > 3 operators: > > > > insert: ^AI > > delete: ^AD > > end: ^AE > > > > So if you checked in a file that looked like > > > > I > > love > > TUHS > > > > The weave would be > > > > ^AI 1 > > I > > love > > TUHS > > ^AE 1 > > > > Lets say that Clem changed that to > > > > I > > really > > love > > TUHS > > > > The new weave would look like: > > > > ^AI 1 > > I > > ^AI 2 > > really > > ^AE 2 > > love > > TUHS > > ^AE 1 > > > > and if I changed it to > > > > I > > *really* > > love > > TUHS > > > > the weave looks like > > > > ^AI 1 > > I > > ^AD 3 > > ^AI 2 > > really > > ^AE 2 > > ^AE 3 > > ^AI 3 > > *really* > > ^AE 3 > > love > > TUHS > > ^AE 1 > > > > So a checkout is 2 things, build up the set of serials that need to be > > active for this checkout, and walk the weave. For each serial you see > > you are either in this set and I need to do what it says, or this is > > not in my set and I need to do the opposite of what it says. > > > > So that is really really fast compared to RCS. RCS reads the whole > > file and has to do compute, SCCS reads the whole file and does a > > very tiny fraction of that compute, so tiny that you can't measure > > it compared to reading the file. > > > > But wait, it gets better, much better. Lets talk about branches > > and merges. RCS is copy by value across a merge, SCCS is copy by > > reference. Marc thought about the set stuff enough to realize > > wouldn't be cool if you could manipulate the set. He added include > > and exclude operators. > > > > Imagine if you and I were having an argument about some video being > > checked in. You checked it in, I deleted it, you checked it in, I deleted > > it. Suppose that was a 1GB video. In RCS, each time we argued that is > > another GB, we did that 4 times, there 4GB of diffs in the history. > > > > In SCCS, you could do that with includes and excludes, those 4 times > > would be about 30 bytes because all they are doing is saying "In the > > set", "Not in the set". > > > > Cool I guess but what is the real life win? Merges. In a weave based > > system like SCCS you can add 1GB on a branch and I can merge that onto > > the trunk and all I did was say "include your serials". I didn't copy > > your work, I referenced it. Tiny meta data to do so. > > > > That has more implications than you might think. Think annotations. > > git blame, know that? It shows who did what? Yeah, well git is > > copy by value just like RCS. It's not just about the space used, > > it is also about who did what. If bwk did one thing and dmr did > > another thing and little old lm merged dmr's stuff into the bwk > > trunk, in a copy by value system, all of dmr's work will look like > > I wrote it in bwk's trunk. > > > > SCCS avoids that. If I merged dmr's work into bwk's tree, if it > > all automerged, annotations would show it all as dmr's work, yeah, > > I did the merge but I didn't do anything so I don't show up in > > annotations. If there was a conflict and I had to resolve that > > conflict, then that, and that alone, would show up as my work. > > > > For Marc, I worked with Rick Smith, he found me after I had done a > > reimplentation of SCCS. He has forgotten more about weaves than I will > > ever know. But he was really impressed with my code (which you can > > go see at bitkeeper.org, and it is not my code, it is my teams code, > > Rick bugfixed all my mistakes) because I embraced the set thing and the > > way I wrote the code you could have N of my data structures and pulled > > out N versions of the file in one pass. He had not seen that before, > > to me it just seemed the most natural way to do it. > > > > SCCS is awesome, Marc should be held up as a hero for that. Most people > > have no idea how much better it is as a format, to this day people still > > do it wrong. The hg people at facebook sort of got it, they did an > > import of SCCS (it was BitKeeper which is SCCS on super steriods). > > But it is rare that someone gets it. I wanted Marc to know we got it. > > > > --lm -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From lm at mcvoy.com Thu Sep 12 14:33:08 2019 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 11 Sep 2019 21:33:08 -0700 Subject: [TUHS] SCCS In-Reply-To: References: <20190911181101.GF3143@mcvoy.com> <20190912034346.GJ2046@mcvoy.com> Message-ID: <20190912043308.GL2046@mcvoy.com> Yeah, this was one of things that BitKeeper addressed. It was easier to use and every commit was a tag. On Wed, Sep 11, 2019 at 09:28:25PM -0700, Jon Forrest wrote: > > > I used both RCS and SCCS in the early days (e.g. 1985 - 1991). RCS was > what we used at Britton-Lee in the group that Eric Allman was part of. > SCCS is what we used at Sybase as it was gaining popularity. This was > so long ago that I don't remember all the details but I found that > RCS was much easier to use, especially in an environment that didn't > do much merging. Instead we used labels (or tags, I forget what they > were called) to mark which files were part of which release. Doing > this was much harder in SCCS, which contributed to the mess that > was Sybase software engineering. > > Of course, all this could be explained by Eric's deep knowledge > of RCS, and the lack of somebody with Eric's knowledge at Sybase. > But, to me, an early adopter of source code control who wasn't > overly interested in speed, RCS was much easier to use. > > Jon -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From jon at fourwinds.com Thu Sep 12 14:25:04 2019 From: jon at fourwinds.com (Jon Steinhart) Date: Wed, 11 Sep 2019 21:25:04 -0700 Subject: [TUHS] SCCS Message-ID: <201909120425.x8C4P4e2009186@darkstar.fourwinds.com> George Michaelson writes: > What Larry and the other RCS haters forget is that back in the day, > when we all had more hair, RCS was --->FAST<--- and SCCS was S.L.O.W. > > because running forward edits on a base state of 1000 edits is slow. > Since the majority action is increment +1 on the head state the RCS > model, whilst broken in many ways > was FAST > > -G And also that RCS had a much friendlier interface. From wlc at jctaylor.com Thu Sep 12 16:12:10 2019 From: wlc at jctaylor.com (William Corcoran) Date: Thu, 12 Sep 2019 06:12:10 +0000 Subject: [TUHS] SCCS In-Reply-To: <20190912043308.GL2046@mcvoy.com> References: <20190911181101.GF3143@mcvoy.com> <20190912034346.GJ2046@mcvoy.com> , <20190912043308.GL2046@mcvoy.com> Message-ID: <03956472-B6A1-4E83-B2F1-0FE855C75C15@jctaylor.com> Okay, while on the subject of SCCS and UNIX: Is there a UNIX (post SCCS) like System III or System V that still has all of the original SCCS entries intact? Would only production ready code be entered as an SCCS delta? Or, would SCCS be used as a checkpoint tool to store unofficial versions (even broken versions) of the UNIX codebase as development progressed on the system as a whole? I would love to see all of the prs for the kernel and commands. Truly, Bill Corcoran > On Sep 12, 2019, at 12:33 AM, Larry McVoy wrote: > > Yeah, this was one of things that BitKeeper addressed. It was easier > to use and every commit was a tag. > >> On Wed, Sep 11, 2019 at 09:28:25PM -0700, Jon Forrest wrote: >> >> >> I used both RCS and SCCS in the early days (e.g. 1985 - 1991). RCS was >> what we used at Britton-Lee in the group that Eric Allman was part of. >> SCCS is what we used at Sybase as it was gaining popularity. This was >> so long ago that I don't remember all the details but I found that >> RCS was much easier to use, especially in an environment that didn't >> do much merging. Instead we used labels (or tags, I forget what they >> were called) to mark which files were part of which release. Doing >> this was much harder in SCCS, which contributed to the mess that >> was Sybase software engineering. >> >> Of course, all this could be explained by Eric's deep knowledge >> of RCS, and the lack of somebody with Eric's knowledge at Sybase. >> But, to me, an early adopter of source code control who wasn't >> overly interested in speed, RCS was much easier to use. >> >> Jon > > -- > --- > Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From dot at dotat.at Thu Sep 12 23:44:45 2019 From: dot at dotat.at (Tony Finch) Date: Thu, 12 Sep 2019 14:44:45 +0100 Subject: [TUHS] [SPAM] Re: SCCS In-Reply-To: <20190912043145.GA12480@mcvoy.com> References: <20190911181101.GF3143@mcvoy.com> <20190912034346.GJ2046@mcvoy.com> <20190912043145.GA12480@mcvoy.com> Message-ID: Larry McVoy wrote: > If you have actual data that shows RCS to be faster I would like to > see that. RCS read the whole file. It could have been faster, it could > have put the offset into the file where the most recent version begain. > But it didn't. It read the entire file. In RCS the most recent version of the file is near the start of the ,v file after a list of revisions, so it doesn't have to read the deltas for the common case of checking out the current version of a file. I think there must be a similar optimization to copy the deltas without processing them when committing a new revision. But yes, as soon as you get away from working on the latest revision of the main branch, RCS becomes quadratically slow. A few years ago I converted a decades-old SCCS working tree to git. Because there are very good tools for converting from CVS to git, I decided to convert SCCS to RCS (which is mostly a trivial file-at-a-time format conversion, in the absence of branches and tags) to CVS (which is just moving the RCS files to the right place) to git. The most annoying part of this was the accidentally quadratic process of dealing with all the old revisions in RCS files. I could mostly avoid slowness if I arranged never to check out old revisions, aiming to treat RCS as append-only until the final cvs-fast-export stage. This kept things acceptably fast (closer to linear in the size of the file rather than quadratic) even for that one very large frequently updated file. Detailed write-up at https://fanf.dreamwidth.org/105694.html (I subsequently re-used a lot of the machinery for converting another much smaller SCCS repository. It was a lot easier the second time!) [ PS. https://accidentallyquadratic.tumblr.com is great ] Tony. -- f.anthony.n.finch http://dotat.at/ Lough Foyle to Carlingford Lough: Southwesterly at first in southeast, otherwise westerly or northwesterly 4 or 5, occasionally 6 at first. Moderate or rough in north, otherwise slight or moderate, becoming smooth or slight in east. Rain at first. Moderate or poor, becoming good. From clemc at ccc.com Fri Sep 13 00:35:32 2019 From: clemc at ccc.com (Clem Cole) Date: Thu, 12 Sep 2019 10:35:32 -0400 Subject: [TUHS] SCCS In-Reply-To: <03956472-B6A1-4E83-B2F1-0FE855C75C15@jctaylor.com> References: <20190911181101.GF3143@mcvoy.com> <20190912034346.GJ2046@mcvoy.com> <20190912043308.GL2046@mcvoy.com> <03956472-B6A1-4E83-B2F1-0FE855C75C15@jctaylor.com> Message-ID: Like most things in life, what you value tends to make one thing more important than another when you consider any object. This is why programs like editors; programming languages; and in this case, file revision management software, gets such visceral responses from so many of us. And like many programs and subsystems, as deficiencies become more obvious/acute with a program, when and how they are addressed also play into that value. Thus, I think it comes back to *use case* for everyone. What am I protecting with this subsystem and how does it affect me? Frankly, the high order bit for me, is usually protection from my own silliness (most important), how easy/natural it is to use/fit into my workflow(next in importance); followed by accidental/on-purpose changes happening by my friends/coworkers 'behind my back'(important); how merges are handled when I'm in a group setting; and IF AND ONLY IF I'm using the tool kit to protect IP for a 'product', how easy it is to support 'releases' past/current/in-development at the same time. The truth is, when I'm leading product development, that last one moves up a few places, although I know that if the 'fit' or ease of using the tool is not nearly #1, some members of the team will not use said tool in the planned and expected manner - so I think I will tend to value 'ease of use' as the most important attribute for me. Truth is SCCS and from what I know of BitKeeper, has always met my criteria, certainly for simple programs and even for documents like papers and books. As I said, its what I use day to day (thank you Marc and team). While I learned the direct get/admin/delta/prs commands, calling them via Eric's "sccs(ucb)" front-end 'fixed' the harder to use part of things. Frankly, I have aliases 'get' to be 'sccs get' and the like. I was at Tektronix and like many when Tichey released RCS by itself, Eric's sccs(ucb) command was not available to me, so it seemed simpler and I was attracted to it. But I quickly went to UCB and was re-introduced to SCCS using Eric's front-end and I found the difference was a nit. SCCS was what we used, so that became my go-to and has been for a long time. SCCS was our systems at Masscomp, Stellar and later DEC (although DEC for OSF/1 switched to another system whose name I forget which came from OSF). At LCC, we used what the customer used, so we got to see a lot of them ;-) That said, when Thinking Machines released CVS-II (on top of RCS) it did seem like the cvs merge management and production tags tended to be the easier/a good thing. When we used that system for an HP project at LCC, I will say, the Thinking Machine crew had fixed the two issues I had struggles with SCCS**. I used cvs again for a few other projects including two start-ups later. Since that time, I have been given Mercurial, SVN, and git. I'll ignore the first two as they seem to have fallen from grace. I personally, find git extremely heavyweight and only deal with it because I have too thanks so linux pushing it into so many FOSS projects. I can and do have to use it, but my experience is that we fight the tool constantly and I wonder if we are ahead or behind. The git system supposed to be great for merges and so-called 'pull requests' and I can see if what you value is being able to grab something from someone else - *i.e.* what Linus does daily (merge lots of peoples 'suggestions') and it probably does make it easier for Linus. But .... I can say in a product setting, I have observed it is messy to keep track of specific versions of things that make up a 'product. For instance, I would like to be able to query, get me all the sources that make of the 'Intel Parallel Studio, Cluster Edition' (I don't think it can be done!! At least at DEC, when we released Ultrix, we put a tag into the DB and keep a DB around for every file we used for the build. There was a script that could be run, that get do an 'sccs get' against every file and we could rebuild everything (VAX or PMAX) and it even included some of the 'layered products' that the OS team controlled. So, my observation at Intel, is we have more people wasting backed time on 'maintaining our common pools' here than we ever did at DEC or at any of start-ups. As a sr person, I must say hmmmmm Anyway - that's my 2 cents. ** Although, I'll believe Larry when he says he fixed said SCCS deficiencies in Bitkeeper. I will say after a quick examination of doc and his emails, it does sound like he picked up some of the good ideas from other systems, but I can not say I have tried it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at eric.allman.name Fri Sep 13 02:45:30 2019 From: tuhs at eric.allman.name (Eric Allman) Date: Thu, 12 Sep 2019 09:45:30 -0700 Subject: [TUHS] SCCS In-Reply-To: References: <20190911181101.GF3143@mcvoy.com> <20190912034346.GJ2046@mcvoy.com> Message-ID: <1457a2d6-2f17-482d-e4f7-ace439d34ca8@neophilic.com> Actually I preferred SCCS for all the reasons that Larry has described. But SCCS was encumbered --- usable at the university, but not in a commercial environment --- so it wasn't available at Britton-Lee at a price we could afford, and RCS was pretty much the only other game in town. Tichy was comparing against SCCS version 1, as described in the paper "The source code control system" (Marc Rochkind, IEEE Transactions on Software Engineering 1, 4, December 1975), which used forward deltas --- very slow as your history got big. I spent considerable time trying to convince him that the version of SCCS in current production was as Larry described, where any version could be read in linear time, but he wasn't hearing anything that went against his beliefs. So far as I know, he never even looked at or measured the system he was comparing RCS to. Today I probably wouldn't use SCCS, mostly because of the atomic update problem (which was still broken in RCS, but fixed in CVS). At this point I'm using git because, well, all the cool kids are doing it, and since I work at the university I have to go with the flow sometimes. And git has some nice properties. On the other hand, I have shot myself in the foot with git more times than the sum of all other screwups with all other source management systems combined. eric On 2019-09-11 21:28, Jon Forrest wrote: > > > I used both RCS and SCCS in the early days (e.g. 1985 - 1991). RCS was > what we used at Britton-Lee in the group that Eric Allman was part of. > SCCS is what we used at Sybase as it was gaining popularity. This was > so long ago that I don't remember all the details but I found that > RCS was much easier to use, especially in an environment that didn't > do much merging. Instead we used labels (or tags, I forget what they > were called) to mark which files were part of which release. Doing > this was much harder in SCCS, which contributed to the mess that > was Sybase software engineering. > > Of course, all this could be explained by Eric's deep knowledge > of RCS, and the lack of somebody with Eric's knowledge at Sybase. > But, to me, an early adopter of source code control who wasn't > overly interested in speed, RCS was much easier to use. > > Jon From clemc at ccc.com Fri Sep 13 03:29:27 2019 From: clemc at ccc.com (Clem Cole) Date: Thu, 12 Sep 2019 13:29:27 -0400 Subject: [TUHS] SCCS In-Reply-To: <1457a2d6-2f17-482d-e4f7-ace439d34ca8@neophilic.com> References: <20190911181101.GF3143@mcvoy.com> <20190912034346.GJ2046@mcvoy.com> <1457a2d6-2f17-482d-e4f7-ace439d34ca8@neophilic.com> Message-ID: On Thu, Sep 12, 2019 at 1:16 PM Eric Allman wrote: > At this point I'm using git because, well, all the cool kids are doing > it, and > since I work at the university I have to go with the flow sometimes. > And git has some nice properties. On the other hand, I have shot myself > in the foot with git more times than the sum of all other screwups with > all other source management systems combined. > > eric +1 -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Fri Sep 13 03:47:36 2019 From: imp at bsdimp.com (Warner Losh) Date: Thu, 12 Sep 2019 11:47:36 -0600 Subject: [TUHS] SCCS In-Reply-To: References: <20190911181101.GF3143@mcvoy.com> <20190912034346.GJ2046@mcvoy.com> <1457a2d6-2f17-482d-e4f7-ace439d34ca8@neophilic.com> Message-ID: On Thu, Sep 12, 2019, 11:30 AM Clem Cole wrote: > > > On Thu, Sep 12, 2019 at 1:16 PM Eric Allman wrote: > >> At this point I'm using git because, well, all the cool kids are doing >> it, and >> since I work at the university I have to go with the flow sometimes. >> And git has some nice properties. On the other hand, I have shot myself >> in the foot with git more times than the sum of all other screwups with >> all other source management systems combined. >> >> eric > > +1 > Mercurial still holds that honor for me. I've screwed up so bad I had to reclone and lost work. Dozens of times. :(. Git is just as easy to screw up. And were it not for the extensive "hole in foot first aid" feature git has, I'd be there too... I hate the cli because it seems overtly hostile to orthogonality, consistency and logic. But learn the warts and it gets the job done. Warner > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnold at skeeve.com Fri Sep 13 04:16:57 2019 From: arnold at skeeve.com (Arnold Robbins) Date: Thu, 12 Sep 2019 21:16:57 +0300 Subject: [TUHS] Livermore software tools dist Message-ID: <201909121816.x8CIGvKY006528@skeeve.com> See https://drive.google.com/file/d/0ByJs3HoO8aRVd1JlOGJWRlJhTDg/view which seems to be stuff from 1984 and 1988. I have no idea where it came from or anything else; I stumbled across it while looking for some other things. Thanks, Arnold From kevin.bowling at kev009.com Fri Sep 13 05:31:13 2019 From: kevin.bowling at kev009.com (Kevin Bowling) Date: Thu, 12 Sep 2019 12:31:13 -0700 Subject: [TUHS] IBM Unix source licenses [was Re: PWB vs Unix/TS In-Reply-To: References: Message-ID: Charlie, there is some interesting history of the pre-RS/6000 AIX stuff here (you give a quote :)). Particularly page 41 gives a chronology of UNIX at IBM: https://amaus.net/static/S100/IBM/RTPC/AIX%20Family%20Definition%201989.pdf Prior to AIX the Series/1 had a UNIX port in the early '80s. I think that work happened in Boca Raton. There are some bizarre anecdotes from Craig Newmark on the above https://craigconnects.org/2014/12/29/knowing-when-to-keep-your-mouth-shut/. The S/1 was a PDP competitor (or at least very squarely in the PLC, interfacing and real time worlds) and IBM was driving much more successful product lines, especially the PC, and later AT and RT, that were better suited for competing in the UNIX space. I don't remember where I read this, but I recently came across someone claiming that AT&T tried to sell UNIX to IBM outright in the early 1980s. I'm guessing '81-'82 because the '83 divestment opened up the direct commercialization by AT&T as System III/V. Regards, Kevin On Wed, Sep 11, 2019 at 9:55 AM Charles H Sauer wrote: > > On 9/11/2019 10:36 AM, Clem Cole wrote: > ... > > OSF would eventually use the IBM SVR3 license as its base [which > > makes me believe IBM must have had a V7 redistribution license too. > > Somebody like Charlie Saurer might know]. Anyway, IBM, DEC and HP all > > shipped OSF 'licensed' systems although only DEC would switch to an > > OSF/1 based kernel. > > "Sauer" > > idk. As far as I know, IBM Austin did not get source licenses until > System V. Before Clay Cipione became the AIX development manager in the > AFWS -> RT transition, Austin did not have source licenses, as far as I > know. Clay insisted that we have source. > > It is plausible that Don Rozenberg had V7 license at Yorktown and/or > ACIS had V7 license for BSD stuff. > > I'm blind copying Clay and another AIX alumnus that might know for sure. > > Charlie > -- > voice: +1.512.784.7526 e-mail: sauer at technologists.com > fax: +1.512.346.5240 Web: https://technologists.com/sauer/ > Facebook/Google/Skype/Twitter: CharlesHSauer From cym224 at gmail.com Fri Sep 13 06:07:39 2019 From: cym224 at gmail.com (Nemo) Date: Thu, 12 Sep 2019 16:07:39 -0400 Subject: [TUHS] SCCS In-Reply-To: <20190912034346.GJ2046@mcvoy.com> References: <20190911181101.GF3143@mcvoy.com> <20190912034346.GJ2046@mcvoy.com> Message-ID: On 11/09/2019, Larry McVoy wrote: > On Thu, Sep 12, 2019 at 08:49:35AM +1000, Dave Horsfall wrote: >> On Wed, 11 Sep 2019, Larry McVoy wrote: >> >> >SCCS is awesome, I'll post why in a different thread. It is light years >> >better than RCS, Tichy lied. >> >> Agreed; I used it for years, then was forced to use RCS in my next job >> :-( > > Marc Rochkind is on the list, I believe I invited him, but he can spell > check what I'm about to say. > > SCCS is awesome. I just learnt that Schily maintains source at http://sccs.sourceforge.net/ (Of course, I have it on my Solaris boxen and may now try it on others.) N. From clemc at ccc.com Fri Sep 13 06:59:48 2019 From: clemc at ccc.com (Clem Cole) Date: Thu, 12 Sep 2019 16:59:48 -0400 Subject: [TUHS] IBM Unix source licenses [was Re: PWB vs Unix/TS In-Reply-To: References: Message-ID: Kevin/Charlie: On Thu, Sep 12, 2019 at 3:31 PM Kevin Bowling wrote: > Charlie, there is some interesting history of the pre-RS/6000 AIX > stuff here (you give a quote :)). Particularly page 41 gives a > chronology of UNIX at IBM: > https://amaus.net/static/S100/IBM/RTPC/AIX%20Family%20Definition%201989.pdf Awesome - thank you, > > > Prior to AIX the Series/1 had a UNIX port in the early '80s. I think > that work happened in Boca Raton. > FYI: the original S/1 port was done at Cleveland State with the Seventh Edition - the name of the Prof that led it I can not say I remember nor his HW configuration, but I do remember his presentation. It is where the term 'NUXI' was coined. I want to say in 1979 or 1980, they gave a wonderful talk about it. They had some help from folks at Case as they did not have a PDP-11 of their own and never seen UNIX before (*i.e.* they arranged to borrowed time on a PDP-11 at the EE Dept at Case. They wrote a new back end for the Ritchie C compiler, and recompiled everything, wrote new drivers for the S/1 HW and rewrote m40.s as needed. Then they wrote the disks, then drove the packs back to Cleveland State. IIRC it took a summer of work to complete). FWIW: The PDP-11 has an interesting way it does byte-swapping and when they first booted the system, the first message was NUXI which was how the S/1 saw the strings. The term was used from then on in the community to describe byte-swapping issues. I remember all of us in the audience howling with laughter when they described their work. Unfortunately, this was before USENIX kept conference proceedings so I'm not sure if the talk and paper were archived. And the truth is, I wish we had that port in the TUHS archives. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron at ronnatalie.com Fri Sep 13 07:09:35 2019 From: ron at ronnatalie.com (Ronald Natalie) Date: Thu, 12 Sep 2019 17:09:35 -0400 Subject: [TUHS] IBM Unix source licenses - Series/1 NUXI In-Reply-To: References: Message-ID: <0342AEA8-FAEA-47C4-A518-CC33C5BA1D6A@ronnatalie.com> Indeed, I remember this. It was either at the UDEL or UToronto meeting if I recall I also remember a talk from a fledgling Microsoft group (when all Microsoft was known for at the time was BASIC). It was also at the UDel conference where MIke Muuss got booed for announcing he was from the Army’s lead laboratory in Vulnerability and Lethality analysis. I also remember this guy getting booed off the stage for making a commercial sales pitch. Years later I’m having dinner with Mark Krieger (then of UniPress) and it dawned on me: You were the one who got booed at UDel. He said he had been half of Whitesmiths. I laughed. I recounted when I saw their VMS C compiler came with a license “stamp” you were supposed to stick on your machine. I wanted to know if that was so when the Whitesmith’s police came by they’d know we were licensed. He said he was gone by that point and that was how he knew Plauger had gone over the edge. I was working at Rutgers at the time and on a visit to a site on the Newark canvas I found someone actually stuck one of these stamps on the CPU there. I carefully peeled it off and gave it to Mark for sentimental reasons. > On Sep 12, 2019, at 4:59 PM, Clem Cole wrote: > > Kevin/Charlie: > > On Thu, Sep 12, 2019 at 3:31 PM Kevin Bowling > wrote: > Charlie, there is some interesting history of the pre-RS/6000 AIX > stuff here (you give a quote :)). Particularly page 41 gives a > chronology of UNIX at IBM: > https://amaus.net/static/S100/IBM/RTPC/AIX%20Family%20Definition%201989.pdf > Awesome - thank you, > > > > > Prior to AIX the Series/1 had a UNIX port in the early '80s. I think > that work happened in Boca Raton. > FYI: the original S/1 port was done at Cleveland State with the Seventh Edition - the name of the Prof that led it I can not say I remember nor his HW configuration, but I do remember his presentation. It is where the term 'NUXI' was coined. I want to say in 1979 or 1980, they gave a wonderful talk about it. They had some help from folks at Case as they did not have a PDP-11 of their own and never seen UNIX before (i.e. they arranged to borrowed time on a PDP-11 at the EE Dept at Case. They wrote a new back end for the Ritchie C compiler, and recompiled everything, wrote new drivers for the S/1 HW and rewrote m40.s as needed. Then they wrote the disks, then drove the packs back to Cleveland State. IIRC it took a summer of work to complete). > > FWIW: The PDP-11 has an interesting way it does byte-swapping and when they first booted the system, the first message was NUXI which was how the S/1 saw the strings. The term was used from then on in the community to describe byte-swapping issues. > > I remember all of us in the audience howling with laughter when they described their work. Unfortunately, this was before USENIX kept conference proceedings so I'm not sure if the talk and paper were archived. > > And the truth is, I wish we had that port in the TUHS archives. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sauer at technologists.com Fri Sep 13 07:29:34 2019 From: sauer at technologists.com (Charles H Sauer) Date: Thu, 12 Sep 2019 16:29:34 -0500 Subject: [TUHS] IBM Unix source licenses [was Re: PWB vs Unix/TS In-Reply-To: References: Message-ID: <8f2cc8f5-3a1d-335a-e6f4-70dfe366f5ca@technologists.com> On 9/12/2019 2:31 PM, Kevin Bowling wrote: > Charlie, there is some interesting history of the pre-RS/6000 AIX > stuff here (you give a quote :)). Particularly page 41 gives a > chronology of UNIX at IBM: > https://amaus.net/static/S100/IBM/RTPC/AIX%20Family%20Definition%201989.pdf I wasn't aware of this doc or this site. Thanks. Just glancing at the doc, I find lots of things to question, but won't do so, at least not now. They're quoting Larry Loucks, while attributing the VRM to him and me, which was revisionist at the time vs. all the others deserving of that attribution. I'm surprised I was referenced at all in a 1989 publication -- I was mostly purged from AIX literature in process after I left for Dell 5/2/89. Also ironic that they emphasized Larry. He deserved the credit, but had been coerced to leave AIX to work on OS/2. CHS -- voice: +1.512.784.7526 e-mail: sauer at technologists.com fax: +1.512.346.5240 Web: https://technologists.com/sauer/ Facebook/Google/Skype/Twitter: CharlesHSauer From imp at bsdimp.com Fri Sep 13 07:31:08 2019 From: imp at bsdimp.com (Warner Losh) Date: Thu, 12 Sep 2019 15:31:08 -0600 Subject: [TUHS] IBM Unix source licenses [was Re: PWB vs Unix/TS In-Reply-To: References: Message-ID: On Thu, Sep 12, 2019 at 3:01 PM Clem Cole wrote: > Kevin/Charlie: > > On Thu, Sep 12, 2019 at 3:31 PM Kevin Bowling > wrote: > >> Charlie, there is some interesting history of the pre-RS/6000 AIX >> stuff here (you give a quote :)). Particularly page 41 gives a >> chronology of UNIX at IBM: >> >> https://amaus.net/static/S100/IBM/RTPC/AIX%20Family%20Definition%201989.pdf > > Awesome - thank you, > > > >> >> >> Prior to AIX the Series/1 had a UNIX port in the early '80s. I think >> that work happened in Boca Raton. >> > FYI: the original S/1 port was done at Cleveland State with the Seventh > Edition - the name of the Prof that led it I can not say I remember nor his > HW configuration, but I do remember his presentation. It is where the term > 'NUXI' was coined. I want to say in 1979 or 1980, they gave a wonderful > talk about it. They had some help from folks at Case as they did not have > a PDP-11 of their own and never seen UNIX before (*i.e.* they arranged to > borrowed time on a PDP-11 at the EE Dept at Case. They wrote a new back > end for the Ritchie C compiler, and recompiled everything, wrote new > drivers for the S/1 HW and rewrote m40.s as needed. Then they wrote the > disks, then drove the packs back to Cleveland State. IIRC it took a summer > of work to complete). > > FWIW: The PDP-11 has an interesting way it does byte-swapping and when > they first booted the system, the first message was NUXI which was how the > S/1 saw the strings. The term was used from then on in the community to > describe byte-swapping issues. > > I remember all of us in the audience howling with laughter when they > described their work. Unfortunately, this was before USENIX kept > conference proceedings so I'm not sure if the talk and paper were archived. > > And the truth is, I wish we had that port in the TUHS archives. > Me too. This is a port I had no clue about.... I'll have to put it in my slides as "S/1 NUXI" :) Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists at irreal.org Fri Sep 13 08:30:52 2019 From: lists at irreal.org (jcs) Date: Thu, 12 Sep 2019 18:30:52 -0400 Subject: [TUHS] IBM Unix source licenses [was Re: PWB vs Unix/TS In-Reply-To: References: Message-ID: Clem Cole writes: > FYI: the original S/1 port was done at Cleveland State with the > Seventh > Edition - the name of the Prof that led it I can not say I > remember nor his > HW configuration... http://delivery.acm.org/10.1145/360000/358504/p1066-jalics.pdf From reed at reedmedia.net Fri Sep 13 09:12:24 2019 From: reed at reedmedia.net (reed at reedmedia.net) Date: Thu, 12 Sep 2019 18:12:24 -0500 (CDT) Subject: [TUHS] IBM Unix source licenses [was Re: PWB vs Unix/TS In-Reply-To: References: Message-ID: On Thu, 12 Sep 2019, jcs wrote: > > Clem Cole writes: > > > FYI: the original S/1 port was done at Cleveland State with the Seventh > > Edition - the name of the Prof that led it I can not say I remember nor his > > HW configuration... > > http://delivery.acm.org/10.1145/360000/358504/p1066-jalics.pdf Can you share an abstract or summary for that? (I get an error I assume because I don't have a login.) From wkt at tuhs.org Fri Sep 13 09:29:09 2019 From: wkt at tuhs.org (Warren Toomey) Date: Fri, 13 Sep 2019 09:29:09 +1000 Subject: [TUHS] IBM Unix source licenses In-Reply-To: References: Message-ID: <20190912232909.GA15734@minnie.tuhs.org> Clem Cole writes: > > > FYI: the original S/1 port was done at Cleveland State with the Seventh > > Edition - the name of the Prof that led it I can not say I remember nor > > his > > HW configuration... On Thu, Sep 12, 2019 at 06:30:52PM -0400, jcs wrote: > http://delivery.acm.org/10.1145/360000/358504/p1066-jalics.pdf Also available at: https://zero.sci-hub.se/3252/016657c71a46a2d7110d87b4f720847e/jalics1983.pdf Warren From lists at irreal.org Fri Sep 13 09:22:56 2019 From: lists at irreal.org (jcs) Date: Thu, 12 Sep 2019 19:22:56 -0400 Subject: [TUHS] IBM Unix source licenses [was Re: PWB vs Unix/TS In-Reply-To: References: Message-ID: reed at reedmedia.net writes: > On Thu, 12 Sep 2019, jcs wrote: > >> >> Clem Cole writes: >> >> > FYI: the original S/1 port was done at Cleveland State with >> > the Seventh >> > Edition - the name of the Prof that led it I can not say I >> > remember nor his >> > HW configuration... >> >> http://delivery.acm.org/10.1145/360000/358504/p1066-jalics.pdf > > Can you share an abstract or summary for that? > > (I get an error I assume because I don't have a login.) Oops, sorry. Here's the metadata: https://dl.acm.org/citation.cfm?doid=358476.358504 The paper, _Transporting a portable operating system: UNIX to an IBM minicomputer_, is also available from Sci-Hub if you don't mind that. From imp at bsdimp.com Fri Sep 13 13:20:20 2019 From: imp at bsdimp.com (Warner Losh) Date: Thu, 12 Sep 2019 21:20:20 -0600 Subject: [TUHS] My EuroBSDcon talk (preview for commentary) Message-ID: OK. I've shared my slides for the talk. Some of the family trees are simplified (V7 doesn't have room for all its ports, for example) Some of it is a little cheeseball since I'm also trying to be witty and entertaining (we'll see how that goes). Please don't share them around until after my talk on the September 20th I'd like feedback on the bits I got wrong. Or left out. Or if you're in this and don't want to be, etc. All the slides after the Questions slide won't be presented and will likely be deleted. https://docs.google.com/presentation/d/177KxOif5oHARyIdZHDq-OO67_GVtMkzIAlDX-cHxgb4/edit?usp=sharing Please be kind (but if it sucks, please do tell). I've turned on commenting on the slides. Probably best if you comment there. I have a video of me giving this talk, but it's too rough to share... Thanks for any help you can give me. Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Fri Sep 13 14:11:17 2019 From: lm at mcvoy.com (Larry McVoy) Date: Thu, 12 Sep 2019 21:11:17 -0700 Subject: [TUHS] [SPAM] Re: SCCS In-Reply-To: References: <20190911181101.GF3143@mcvoy.com> <20190912034346.GJ2046@mcvoy.com> <20190912043145.GA12480@mcvoy.com> Message-ID: <20190913041117.GR2046@mcvoy.com> On Thu, Sep 12, 2019 at 02:44:45PM +0100, Tony Finch wrote: > Larry McVoy wrote: > > > If you have actual data that shows RCS to be faster I would like to > > see that. RCS read the whole file. It could have been faster, it could > > have put the offset into the file where the most recent version begain. > > But it didn't. It read the entire file. > > In RCS the most recent version of the file is near the start of the ,v > file after a list of revisions, so it doesn't have to read the deltas for > the common case of checking out the current version of a file. I think > there must be a similar optimization to copy the deltas without processing > them when committing a new revision. But yes, as soon as you get away from > working on the latest revision of the main branch, RCS becomes > quadratically slow. Yeah, you are right. The most recent version should be fast. SCCS reads the whole file and RCS does not in the common case. But here is an SCCS win. SCCS has a 16 bit ignore the carry bit checksum over the whole file. RCS has none of that. You can argue that a 16 bit checksum is not good enough in this day of md5sums, sha1 hashes, crcs, etc. There are two places where it is great. A) Memory errors. Memory chips errors are none, parity, or ECC. Parity has gone the way of the doodoo bird so we have none or ECC. I can pretty much promise you that the machine you are reading this on has no error detection or correction. Only high end servers have ECC. That SCCS checksum is awesome because we can print out what the checksum should be and what we got. If it differs in a power of two then it is a single bit error and that is your memory sucks. I can't tell you how many times customers said something was wrong and I made them run a memory check and it was their memory. 100's is too small, 1000's at least. B) NFS errors. So all NFS implementations, Suns included, had a bad habit of returning a block of nulls. I dunno why but that is a thing. The SCCS checksum would detect that. RCS and CVS did not have a checksum so when NFS returned garbage, they were happy to return that to you. It's really surprising how well the SCCS checksum has worked. When we went to a binary format we did CRC on each block and XOR so we could put stuff back together. I still have a lot of respect for that little checksum. It served us well. --lm From dave at horsfall.org Fri Sep 13 15:22:58 2019 From: dave at horsfall.org (Dave Horsfall) Date: Fri, 13 Sep 2019 15:22:58 +1000 (EST) Subject: [TUHS] SCCS In-Reply-To: <20190912043308.GL2046@mcvoy.com> References: <20190911181101.GF3143@mcvoy.com> <20190912034346.GJ2046@mcvoy.com> <20190912043308.GL2046@mcvoy.com> Message-ID: On Wed, 11 Sep 2019, Larry McVoy wrote: > Yeah, this was one of things that BitKeeper addressed. It was easier to > use and every commit was a tag. That reminds me: I really must take another look at BK for my stuff. At the moment I'm using say "fred.c-" for the previous version etc (and "fred.c+" for something finished but not quite ready to install). I've also renamed entire directory trees to sub-tree under "OLD" etc :-) SCCS/RCS are history as far as I'm concerned; I never quite got the hang of CVS (which OpenLDAP uses); and I've heard all sorts of horror stories about GIT to keep me away from it... -- Dave From bakul at bitblocks.com Fri Sep 13 15:50:12 2019 From: bakul at bitblocks.com (Bakul Shah) Date: Thu, 12 Sep 2019 22:50:12 -0700 Subject: [TUHS] SCCS In-Reply-To: Your message of "Fri, 13 Sep 2019 15:22:58 +1000." References: <20190911181101.GF3143@mcvoy.com> <20190912034346.GJ2046@mcvoy.com> <20190912043308.GL2046@mcvoy.com> Message-ID: <20190913055019.B92151570CE9@mail.bitblocks.com> On Fri, 13 Sep 2019 15:22:58 +1000 Dave Horsfall wrote: > On Wed, 11 Sep 2019, Larry McVoy wrote: > > > Yeah, this was one of things that BitKeeper addressed. It was easier to > > use and every commit was a tag. > > That reminds me: I really must take another look at BK for my stuff. > > At the moment I'm using say "fred.c-" for the previous version etc (and > "fred.c+" for something finished but not quite ready to install). > > I've also renamed entire directory trees to sub-tree under "OLD" etc :-) > > SCCS/RCS are history as far as I'm concerned; I never quite got the hang > of CVS (which OpenLDAP uses); and I've heard all sorts of horror stories > about GIT to keep me away from it... I used to know CVS quite well. Then I switched to mercurial (for my own projects). Then to git. git has its problems but it has worked well enough. With just a few commands you can get a lot done with it. If you rely on/ contribute to any open source projects, you pretty much have to know it these days. From dave at horsfall.org Fri Sep 13 15:54:32 2019 From: dave at horsfall.org (Dave Horsfall) Date: Fri, 13 Sep 2019 15:54:32 +1000 (EST) Subject: [TUHS] [SPAM] Re: SCCS In-Reply-To: <20190913041117.GR2046@mcvoy.com> References: <20190911181101.GF3143@mcvoy.com> <20190912034346.GJ2046@mcvoy.com> <20190912043145.GA12480@mcvoy.com> <20190913041117.GR2046@mcvoy.com> Message-ID: On Thu, 12 Sep 2019, Larry McVoy wrote: > But here is an SCCS win. SCCS has a 16 bit ignore the carry bit > checksum over the whole file. RCS has none of that. Giggle... I found I could actually *edit* an SCCS file, provided I reset the checksum to zero (it was then recalculated). > B) NFS errors. So all NFS implementations, Suns included, had a bad > habit of returning a block of nulls. I dunno why but that is a thing. > The SCCS checksum would detect that. RCS and CVS did not have a > checksum so when NFS returned garbage, they were happy to return that to > you. I believe that NFS is much more reliable now (yes, it used to be awful). -- Dave From arnold at skeeve.com Fri Sep 13 17:06:50 2019 From: arnold at skeeve.com (arnold at skeeve.com) Date: Fri, 13 Sep 2019 01:06:50 -0600 Subject: [TUHS] IBM Unix source licenses In-Reply-To: <20190912232909.GA15734@minnie.tuhs.org> References: <20190912232909.GA15734@minnie.tuhs.org> Message-ID: <201909130706.x8D76o74010750@freefriends.org> Warren Toomey wrote: > Clem Cole writes: > > > > > FYI: the original S/1 port was done at Cleveland State with the Seventh > > > Edition - the name of the Prof that led it I can not say I remember nor > > > his > > > HW configuration... > > On Thu, Sep 12, 2019 at 06:30:52PM -0400, jcs wrote: > > http://delivery.acm.org/10.1145/360000/358504/p1066-jalics.pdf > > Also available at: > https://zero.sci-hub.se/3252/016657c71a46a2d7110d87b4f720847e/jalics1983.pdf > > Warren Awesome, thanks for the link. I'd heard about that port (we had a few Series/1s at GT, but not much was done with them) but didn't know much about it otherwise. Arnold From peter at rulingia.com Fri Sep 13 18:00:09 2019 From: peter at rulingia.com (Peter Jeremy) Date: Fri, 13 Sep 2019 18:00:09 +1000 Subject: [TUHS] [SPAM] Re: SCCS In-Reply-To: References: <20190911181101.GF3143@mcvoy.com> <20190912034346.GJ2046@mcvoy.com> <20190912043145.GA12480@mcvoy.com> <20190913041117.GR2046@mcvoy.com> Message-ID: <20190913080009.GG88690@server.rulingia.com> On 2019-Sep-13 15:54:32 +1000, Dave Horsfall wrote: >On Thu, 12 Sep 2019, Larry McVoy wrote: >> But here is an SCCS win. SCCS has a 16 bit ignore the carry bit >> checksum over the whole file. RCS has none of that. > >Giggle... I found I could actually *edit* an SCCS file, provided I reset >the checksum to zero (it was then recalculated). I think that was deliberate. ISTR editing SCCS files and repairing the checksum as well, though I don't recally exactly how. >> B) NFS errors. So all NFS implementations, Suns included, had a bad >> habit of returning a block of nulls. I dunno why but that is a thing. >> The SCCS checksum would detect that. RCS and CVS did not have a >> checksum so when NFS returned garbage, they were happy to return that to >> you. > >I believe that NFS is much more reliable now (yes, it used to be awful). NFS ran much faster when you turned off the UDP checksums as well. (Though there was still the Ethernet CRC32). -- Peter Jeremy -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 963 bytes Desc: not available URL: From spedraja at gmail.com Fri Sep 13 18:30:17 2019 From: spedraja at gmail.com (SPC) Date: Fri, 13 Sep 2019 10:30:17 +0200 Subject: [TUHS] IBM Unix source licenses In-Reply-To: <20190912232909.GA15734@minnie.tuhs.org> References: <20190912232909.GA15734@minnie.tuhs.org> Message-ID: El vie., 13 sept. 2019 a las 1:29, Warren Toomey () escribió: > Clem Cole writes: > > > > > FYI: the original S/1 port was done at Cleveland State with the Seventh > > > Edition > Very interesting. We got one Series/1 in our work involved in one electronic speech project which sadly died soon. On the other hand... Was this other portability project succesfully finished? The Jalics paper don't make it all clear. Also available at: > > https://zero.sci-hub.se/3252/016657c71a46a2d7110d87b4f720847e/jalics1983.pdf > > Warren > Gracias | Regards - Saludos | Greetings | Freundliche Grüße | Salutations -- *Sergio Pedraja* -------------- next part -------------- An HTML attachment was scrubbed... URL: From emu at e-bbes.com Fri Sep 13 18:12:39 2019 From: emu at e-bbes.com (emanuel stiebler) Date: Fri, 13 Sep 2019 10:12:39 +0200 Subject: [TUHS] SCCS In-Reply-To: References: <20190911181101.GF3143@mcvoy.com> <20190912034346.GJ2046@mcvoy.com> <1457a2d6-2f17-482d-e4f7-ace439d34ca8@neophilic.com> Message-ID: <8db2e89c-ce50-a453-e38a-ecdfe69a746c@e-bbes.com> On 2019-09-12 19:29, Clem Cole wrote: > > > On Thu, Sep 12, 2019 at 1:16 PM Eric Allman > wrote: > >  At thispoint I'm using git because, well, all the cool kids are > doing it, and > since I work at the university I have to go with the flow sometimes. > And git has some nice properties.  On the other hand, I have shot myself > in the foot with git more times than the sum of all other screwups with > all other source management systems combined. > > eric > > +1  I have this one on the waqll in the office: https://xkcd.com/1597/ From g.branden.robinson at gmail.com Fri Sep 13 19:03:01 2019 From: g.branden.robinson at gmail.com (Branden Robinson) Date: Fri, 13 Sep 2019 19:03:01 +1000 Subject: [TUHS] My EuroBSDcon talk (preview for commentary) In-Reply-To: References: Message-ID: Hi Warner, Just a few minor corrections. 1. slide 21: s/Murrey Hill/Murray Hill/ 2. slide 18: s/IOCC/&C/ 3. slide 28: s/strippe down/stripped down/; s/IOCC/&C/ Now I know why the domain name is ioccc.org and not iocc.org. Well-crafted obfuscated C is nothing if not...unorthodox. I hadn't even heard of VENIX before--great archeology! As you lusted for that OS back in the '80s, I lusted after the Rainbow 100 itself, and found it cool for the same reasons you did. The flexibility of the system was appealing, keeping a bridge to my Z80 origins and the x86 juggernaut. As it happened I wound up with a 6809 machine running OS/9, and got Unix-like exposure without even knowing it (the text editor, T/S Edit, was a vi clone, and the "word processor", T/S Word, a *roff clone). And best of all, that machine taught me how to store multibyte integers correctly. x86's worst-ever implementation of memory segmentation put me off of assembly programming for years. When I finally saw sensible segmentation combined with hardware memory protection, the universe made sense again. You have a wealth of great material here and I think you will surprise some people. Regards, Branden On Fri, Sep 13, 2019 at 1:21 PM Warner Losh wrote: > OK. I've shared my slides for the talk. > > Some of the family trees are simplified (V7 doesn't have room for all its > ports, for example) > Some of it is a little cheeseball since I'm also trying to be witty and > entertaining (we'll see how that goes). > Please don't share them around until after my talk on the September 20th > > I'd like feedback on the bits I got wrong. Or left out. Or if you're in > this and don't want to be, etc. > > All the slides after the Questions slide won't be presented and will > likely be deleted. > > > https://docs.google.com/presentation/d/177KxOif5oHARyIdZHDq-OO67_GVtMkzIAlDX-cHxgb4/edit?usp=sharing > > Please be kind (but if it sucks, please do tell). I've turned on > commenting on the slides. Probably best if you comment there. > > I have a video of me giving this talk, but it's too rough to share... > > Thanks for any help you can give me. > > Warner > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Sat Sep 14 01:23:45 2019 From: lm at mcvoy.com (Larry McVoy) Date: Fri, 13 Sep 2019 08:23:45 -0700 Subject: [TUHS] [SPAM] Re: SCCS In-Reply-To: <20190913080009.GG88690@server.rulingia.com> References: <20190911181101.GF3143@mcvoy.com> <20190912034346.GJ2046@mcvoy.com> <20190912043145.GA12480@mcvoy.com> <20190913041117.GR2046@mcvoy.com> <20190913080009.GG88690@server.rulingia.com> Message-ID: <20190913152344.GW2046@mcvoy.com> On Fri, Sep 13, 2019 at 06:00:09PM +1000, Peter Jeremy wrote: > On 2019-Sep-13 15:54:32 +1000, Dave Horsfall wrote: > >On Thu, 12 Sep 2019, Larry McVoy wrote: > >> But here is an SCCS win. SCCS has a 16 bit ignore the carry bit > >> checksum over the whole file. RCS has none of that. > > > >Giggle... I found I could actually *edit* an SCCS file, provided I reset > >the checksum to zero (it was then recalculated). > > I think that was deliberate. ISTR editing SCCS files and repairing the > checksum as well, though I don't recally exactly how. bk admin -z file.c and I'm pretty sure that is sccs compat. > >> B) NFS errors. So all NFS implementations, Suns included, had a bad > >> habit of returning a block of nulls. I dunno why but that is a thing. > >> The SCCS checksum would detect that. RCS and CVS did not have a > >> checksum so when NFS returned garbage, they were happy to return that to > >> you. > > > >I believe that NFS is much more reliable now (yes, it used to be awful). > > NFS ran much faster when you turned off the UDP checksums as well. > (Though there was still the Ethernet CRC32). Living dangerously. From clemc at ccc.com Sat Sep 14 05:47:08 2019 From: clemc at ccc.com (Clem Cole) Date: Fri, 13 Sep 2019 15:47:08 -0400 Subject: [TUHS] My EuroBSDcon talk (preview for commentary) In-Reply-To: References: Message-ID: slide 4 -- All of HP-UX, Ultrix and Digital UNIX/Tru64 are BSD kernels. HP-UP and Tru64 support System V calls. BTW: DG-UX and Stratus built their own kernels, but used System V command systems and System Call definitions - which are not listed. Slide 6 - if you want it I have another picture of the GE system from some of their literature has a view of all of the components. Send me email if you want it. Slide 8 - Sets out to write version of Fortran came up with B. Uses B to write Assembler Slide 9 - Wrong DEC logo. Should be the Blue one. The maroon version does not show up until the 1990s with Bob Palmer (and has bad memories for some of us). Slide 17 - Ken write PDP-11 assembler on PDP-7 in B. , Dennis starts to rewrite B compiler to output PDP-11 code. Slide 18 - B begins to become different enough that Dennis starts to call it nb [new B], eventually deviates enough to become new language Slide 19 - 4th Edition release outside of the BTL. Lou Katz becomes 'user zero' Slide 20 -- We need to get you the site and group name from Mash. It was not in Summit, it was not USG - but was in NJ. I thought it was Homdel but I that is purely speculation. Also the role of Columbus team needs to be defined. Ask Mary Ann. Slide 21 -- I'm not going to argue - but I would ask you to add a disclaimer. This is what you could reconstruct, but there is some question of some of the arrows. Heinz might be able to help, but as Stienhart and I have said, its believed to be in LA; but no one has tracked him down as he has been pursuing non-computer interests. Slide 22 --4th Edition went to Katz that this is wrong, who sometimes reads this mailing list. If not, send me a note, I'll reintroduce you. He might be able to give you a data. Check with Warren, my >>memory<< is that some of userland is still in C although a lot assembler is still there. Slide 23 -- ??widespread?? -- I'm not sure I would use that. Not even 100 sites yet. Also there were not "commercial version" this was the first "commercial license" -- big difference [contact me if you want explanation]. IIRC fee was 15K per CPU. Commercial redistribution doesn't occur until after 7th is released and was a separate license. I would add, Mike Lesk's portable C library is starting to be used, but most C program do their own I/O with read/write First real install man page and Dennis build tape installation system. Earlier version released as RK05 disk copies. Also numerous new peripherals. IIRC Support for the 11/40 starts here, 4th & 5th needed a 45 class, and earlier used the 20 with the CSS MMU. Slide 24 -- CMU uses it to teaches OS class. makes student in class sign a sub-license. Slide 25 - missing the first USENIX tapes. which include Harvard and the like. Warren and I can probably help a little here. Slide 26 - new licenses. Commercial license fees change to 20K for 1st CPU/5K for each CPU afterward. CMU buys first commercial license to use UNIX to make money [after Cole and Klein go on strike]. Case Western follows suit 6month later. AT&T agrees for the Universities that they only had to declare one CPU as commercial and could intermix otherwise and notifies all the universities that if they were using it for commercial purposes, then needed a license. AT&T creates first redistribution license. Needed at least one $20K commercial CPU and then $150k for the rights to redistribute. Originally $1K per binary CPU. Slide 27 -- missing Purdue Dual Vax and CMU Mach Slide 28 - APS had NH which was the model the DEC plate you show. Maddog has it now on his Jeep when aps moved to CA (he also has the NH Linux plate but I don't remember the car -- you can ask him). I have had the Massachusetts UNIX plate since 1983 (it's on my model S of course). ghg has indiana from around the same time (I think on a pickup). wnj had the CA vmunix on his Ferrari, but I don't know if he still has it or what its on. Slide 29 - Look in HenrySpencer-TUHS.org -- you'll find tail but not head. Slide 31 - Job Control can from Europe via MIT. Jim Kulp wrote it. Noel and I can give you the story if you want it. It was on the PDP-11 there. Joy modified csh and added it to 4.1 Slide 32 -- JC was not from UCB. Joy got it from MIT -- Dennis create ENV and it was first distributed in V7. Slide 33 -- No Bourne supported ENV in the new shell -- see me earlier email for how all this went down or ask Steve yourself. Slide 34 -- PCC was included, but the Ritchie Compiler (a.k.a. Typesetter C) was the default compiler. You are missing a step BTW -- typesetter C was released between V6 and V7. As is the first draft of the White Book. The new compiler had stdio but targets V6. Also mpx was part of DataKit support. Slide 35 -- Not sure that is true. I thought Microsoft's Xenix ships before Venix. Particularly since you made the comment about System III The original 8086 Xenix was a pure V7 port, with a few additions Gordon brought with him from Purdue (i.e. ghg hacks). Slide 52/53/54/55 -- wrong logo (see above) On Thu, Sep 12, 2019 at 11:21 PM Warner Losh wrote: > OK. I've shared my slides for the talk. > > Some of the family trees are simplified (V7 doesn't have room for all its > ports, for example) > Some of it is a little cheeseball since I'm also trying to be witty and > entertaining (we'll see how that goes). > Please don't share them around until after my talk on the September 20th > > I'd like feedback on the bits I got wrong. Or left out. Or if you're in > this and don't want to be, etc. > > All the slides after the Questions slide won't be presented and will > likely be deleted. > > > https://docs.google.com/presentation/d/177KxOif5oHARyIdZHDq-OO67_GVtMkzIAlDX-cHxgb4/edit?usp=sharing > > Please be kind (but if it sucks, please do tell). I've turned on > commenting on the slides. Probably best if you comment there. > > I have a video of me giving this talk, but it's too rough to share... > > Thanks for any help you can give me. > > Warner > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Sat Sep 14 06:02:30 2019 From: clemc at ccc.com (Clem Cole) Date: Fri, 13 Sep 2019 16:02:30 -0400 Subject: [TUHS] My EuroBSDcon talk (preview for commentary) In-Reply-To: References: Message-ID: BTW: I just thought of something else.... one of the b*tched about the commercial redistribution license from V7 in 1979, that was not fixed until the SVR3 licensing the mid-late 1980s was AT&T's source policy. As I said, a commercial source license was $20K for the first CPU and 5K for each additional one. Later (System V) it went to $50K for the first and $10K for each additional. But what really ticked off the vendors like DEC, Masscomp, Sun et al, was that each system that sources on was supposed to one of the 'second CPU licenses' - the binary license was not good enough. What most of us did, was make sure any system that was a 'source control' or 'master' system at any 'site' had a full source license, but we were all in violation of the source agreement on our personal workstations. The argument was the sources on people's machines was ephemeral and not 'stored' there. But it was definitely contentious. On Fri, Sep 13, 2019 at 3:47 PM Clem Cole wrote: > slide 4 -- All of HP-UX, Ultrix and Digital UNIX/Tru64 are BSD kernels. > HP-UP and Tru64 support System V calls. > > BTW: DG-UX and Stratus built their own kernels, but used System V command > systems and System Call definitions - which are not listed. > > Slide 6 - if you want it I have another picture of the GE system from some > of their literature has a view of all of the components. Send me email if > you want it. > > Slide 8 - Sets out to write version of Fortran came up with B. Uses B to > write Assembler > > Slide 9 - Wrong DEC logo. Should be the Blue one. The maroon version > does not show up until the 1990s with Bob Palmer (and has bad memories for > some of us). > > Slide 17 - Ken write PDP-11 assembler on PDP-7 in B. , Dennis starts to > rewrite B compiler to output PDP-11 code. > > Slide 18 - B begins to become different enough that Dennis starts to call > it nb [new B], eventually deviates enough to become new language > > Slide 19 - 4th Edition release outside of the BTL. Lou Katz becomes 'user > zero' > > Slide 20 -- We need to get you the site and group name from Mash. It was > not in Summit, it was not USG - but was in NJ. I thought it was Homdel but > I that is purely speculation. > Also the role of Columbus team needs to be defined. > Ask Mary Ann. > > Slide 21 -- I'm not going to argue - but I would ask you to add a > disclaimer. This is what you could reconstruct, but there is some > question of some of the arrows. Heinz might be able to help, but as > Stienhart and I have said, its believed to be in LA; but no one has tracked > him down as he has been pursuing non-computer interests. > > Slide 22 --4th Edition went to Katz that this is wrong, who sometimes > reads this mailing list. If not, send me a note, I'll reintroduce you. He > might be able to give you a data. Check with Warren, my >>memory<< is that > some of userland is still in C although a lot assembler is still there. > > Slide 23 -- ??widespread?? -- I'm not sure I would use that. Not even > 100 sites yet. Also there were not "commercial version" this was the > first "commercial license" -- big difference [contact me if you want > explanation]. IIRC fee was 15K per CPU. Commercial redistribution doesn't > occur until after 7th is released and was a separate license. I would > add, Mike Lesk's portable C library is starting to be used, but most C > program do their own I/O with read/write > > First real install man page and Dennis build tape installation > system. Earlier version released as RK05 disk copies. > Also numerous new peripherals. IIRC Support for the 11/40 > starts here, 4th & 5th needed a 45 class, and earlier used the 20 with the > CSS MMU. > > Slide 24 -- CMU uses it to teaches OS class. makes student in class sign > a sub-license. > > Slide 25 - missing the first USENIX tapes. which include Harvard and the > like. Warren and I can probably help a little here. > > Slide 26 - new licenses. Commercial license fees change to 20K for 1st > CPU/5K for each CPU afterward. CMU buys first commercial license to use > UNIX to make money [after Cole and Klein go on strike]. Case Western > follows suit 6month later. AT&T agrees for the Universities that they > only had to declare one CPU as commercial and could intermix otherwise and > notifies all the universities that if they were using it for commercial > purposes, then needed a license. > > AT&T creates first redistribution license. Needed at least one $20K > commercial CPU and then $150k for the rights to redistribute. Originally > $1K per binary CPU. > > Slide 27 -- missing Purdue Dual Vax and CMU Mach > > Slide 28 - APS had NH which was the model the DEC plate you show. Maddog > has it now on his Jeep when aps moved to CA (he also has the NH Linux plate > but I don't remember the car -- you can ask him). I have had the > Massachusetts UNIX plate since 1983 (it's on my model S of course). ghg > has indiana from around the same time (I think on a pickup). wnj had the > CA vmunix on his Ferrari, but I don't know if he still has it or what its > on. > > Slide 29 - Look in HenrySpencer-TUHS.org -- you'll find tail but not head. > > Slide 31 - Job Control can from Europe via MIT. Jim Kulp wrote it. Noel > and I can give you the story if you want it. It was on the PDP-11 there. > Joy modified csh and added it to 4.1 > > Slide 32 -- JC was not from UCB. Joy got it from MIT -- Dennis create > ENV and it was first distributed in V7. > > Slide 33 -- No Bourne supported ENV in the new shell -- see me earlier > email for how all this went down or ask Steve yourself. > > Slide 34 -- PCC was included, but the Ritchie Compiler (a.k.a. Typesetter > C) was the default compiler. You are missing a step BTW -- typesetter C > was released between V6 and V7. As is the first draft of the White Book. > The new compiler had stdio but targets V6. > Also mpx was part of DataKit support. > > Slide 35 -- Not sure that is true. I thought Microsoft's Xenix ships > before Venix. Particularly since you made the comment about System III > The original 8086 Xenix was a pure V7 port, with a few additions Gordon > brought with him from Purdue (i.e. ghg hacks). > > Slide 52/53/54/55 -- wrong logo (see above) > > > > > > > > > > > On Thu, Sep 12, 2019 at 11:21 PM Warner Losh wrote: > >> OK. I've shared my slides for the talk. >> >> Some of the family trees are simplified (V7 doesn't have room for all its >> ports, for example) >> Some of it is a little cheeseball since I'm also trying to be witty and >> entertaining (we'll see how that goes). >> Please don't share them around until after my talk on the September 20th >> >> I'd like feedback on the bits I got wrong. Or left out. Or if you're in >> this and don't want to be, etc. >> >> All the slides after the Questions slide won't be presented and will >> likely be deleted. >> >> >> https://docs.google.com/presentation/d/177KxOif5oHARyIdZHDq-OO67_GVtMkzIAlDX-cHxgb4/edit?usp=sharing >> >> Please be kind (but if it sucks, please do tell). I've turned on >> commenting on the slides. Probably best if you comment there. >> >> I have a video of me giving this talk, but it's too rough to share... >> >> Thanks for any help you can give me. >> >> Warner >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Sat Sep 14 06:06:59 2019 From: lm at mcvoy.com (Larry McVoy) Date: Fri, 13 Sep 2019 13:06:59 -0700 Subject: [TUHS] My EuroBSDcon talk (preview for commentary) In-Reply-To: References: Message-ID: <20190913200659.GB2046@mcvoy.com> Sun had all their sources on one machine. Spent many a happy hour there reading. On Fri, Sep 13, 2019 at 04:02:30PM -0400, Clem Cole wrote: > BTW: I just thought of something else.... one of the b*tched about the > commercial redistribution license from V7 in 1979, that was not fixed until > the SVR3 licensing the mid-late 1980s was AT&T's source policy. As I > said, a commercial source license was $20K for the first CPU and 5K for > each additional one. Later (System V) it went to $50K for the first and > $10K for each additional. But what really ticked off the vendors like > DEC, Masscomp, Sun et al, was that each system that sources on was supposed > to one of the 'second CPU licenses' - the binary license was not good > enough. > > What most of us did, was make sure any system that was a 'source control' > or 'master' system at any 'site' had a full source license, but we were all > in violation of the source agreement on our personal workstations. The > argument was the sources on people's machines was ephemeral and not > 'stored' there. But it was definitely contentious. > > > > On Fri, Sep 13, 2019 at 3:47 PM Clem Cole wrote: > > > slide 4 -- All of HP-UX, Ultrix and Digital UNIX/Tru64 are BSD kernels. > > HP-UP and Tru64 support System V calls. > > > > BTW: DG-UX and Stratus built their own kernels, but used System V command > > systems and System Call definitions - which are not listed. > > > > Slide 6 - if you want it I have another picture of the GE system from some > > of their literature has a view of all of the components. Send me email if > > you want it. > > > > Slide 8 - Sets out to write version of Fortran came up with B. Uses B to > > write Assembler > > > > Slide 9 - Wrong DEC logo. Should be the Blue one. The maroon version > > does not show up until the 1990s with Bob Palmer (and has bad memories for > > some of us). > > > > Slide 17 - Ken write PDP-11 assembler on PDP-7 in B. , Dennis starts to > > rewrite B compiler to output PDP-11 code. > > > > Slide 18 - B begins to become different enough that Dennis starts to call > > it nb [new B], eventually deviates enough to become new language > > > > Slide 19 - 4th Edition release outside of the BTL. Lou Katz becomes 'user > > zero' > > > > Slide 20 -- We need to get you the site and group name from Mash. It was > > not in Summit, it was not USG - but was in NJ. I thought it was Homdel but > > I that is purely speculation. > > Also the role of Columbus team needs to be defined. > > Ask Mary Ann. > > > > Slide 21 -- I'm not going to argue - but I would ask you to add a > > disclaimer. This is what you could reconstruct, but there is some > > question of some of the arrows. Heinz might be able to help, but as > > Stienhart and I have said, its believed to be in LA; but no one has tracked > > him down as he has been pursuing non-computer interests. > > > > Slide 22 --4th Edition went to Katz that this is wrong, who sometimes > > reads this mailing list. If not, send me a note, I'll reintroduce you. He > > might be able to give you a data. Check with Warren, my >>memory<< is that > > some of userland is still in C although a lot assembler is still there. > > > > Slide 23 -- ??widespread?? -- I'm not sure I would use that. Not even > > 100 sites yet. Also there were not "commercial version" this was the > > first "commercial license" -- big difference [contact me if you want > > explanation]. IIRC fee was 15K per CPU. Commercial redistribution doesn't > > occur until after 7th is released and was a separate license. I would > > add, Mike Lesk's portable C library is starting to be used, but most C > > program do their own I/O with read/write > > > > First real install man page and Dennis build tape installation > > system. Earlier version released as RK05 disk copies. > > Also numerous new peripherals. IIRC Support for the 11/40 > > starts here, 4th & 5th needed a 45 class, and earlier used the 20 with the > > CSS MMU. > > > > Slide 24 -- CMU uses it to teaches OS class. makes student in class sign > > a sub-license. > > > > Slide 25 - missing the first USENIX tapes. which include Harvard and the > > like. Warren and I can probably help a little here. > > > > Slide 26 - new licenses. Commercial license fees change to 20K for 1st > > CPU/5K for each CPU afterward. CMU buys first commercial license to use > > UNIX to make money [after Cole and Klein go on strike]. Case Western > > follows suit 6month later. AT&T agrees for the Universities that they > > only had to declare one CPU as commercial and could intermix otherwise and > > notifies all the universities that if they were using it for commercial > > purposes, then needed a license. > > > > AT&T creates first redistribution license. Needed at least one $20K > > commercial CPU and then $150k for the rights to redistribute. Originally > > $1K per binary CPU. > > > > Slide 27 -- missing Purdue Dual Vax and CMU Mach > > > > Slide 28 - APS had NH which was the model the DEC plate you show. Maddog > > has it now on his Jeep when aps moved to CA (he also has the NH Linux plate > > but I don't remember the car -- you can ask him). I have had the > > Massachusetts UNIX plate since 1983 (it's on my model S of course). ghg > > has indiana from around the same time (I think on a pickup). wnj had the > > CA vmunix on his Ferrari, but I don't know if he still has it or what its > > on. > > > > Slide 29 - Look in HenrySpencer-TUHS.org -- you'll find tail but not head. > > > > Slide 31 - Job Control can from Europe via MIT. Jim Kulp wrote it. Noel > > and I can give you the story if you want it. It was on the PDP-11 there. > > Joy modified csh and added it to 4.1 > > > > Slide 32 -- JC was not from UCB. Joy got it from MIT -- Dennis create > > ENV and it was first distributed in V7. > > > > Slide 33 -- No Bourne supported ENV in the new shell -- see me earlier > > email for how all this went down or ask Steve yourself. > > > > Slide 34 -- PCC was included, but the Ritchie Compiler (a.k.a. Typesetter > > C) was the default compiler. You are missing a step BTW -- typesetter C > > was released between V6 and V7. As is the first draft of the White Book. > > The new compiler had stdio but targets V6. > > Also mpx was part of DataKit support. > > > > Slide 35 -- Not sure that is true. I thought Microsoft's Xenix ships > > before Venix. Particularly since you made the comment about System III > > The original 8086 Xenix was a pure V7 port, with a few additions Gordon > > brought with him from Purdue (i.e. ghg hacks). > > > > Slide 52/53/54/55 -- wrong logo (see above) > > > > > > > > > > > > > > > > > > > > > > On Thu, Sep 12, 2019 at 11:21 PM Warner Losh wrote: > > > >> OK. I've shared my slides for the talk. > >> > >> Some of the family trees are simplified (V7 doesn't have room for all its > >> ports, for example) > >> Some of it is a little cheeseball since I'm also trying to be witty and > >> entertaining (we'll see how that goes). > >> Please don't share them around until after my talk on the September 20th > >> > >> I'd like feedback on the bits I got wrong. Or left out. Or if you're in > >> this and don't want to be, etc. > >> > >> All the slides after the Questions slide won't be presented and will > >> likely be deleted. > >> > >> > >> https://docs.google.com/presentation/d/177KxOif5oHARyIdZHDq-OO67_GVtMkzIAlDX-cHxgb4/edit?usp=sharing > >> > >> Please be kind (but if it sucks, please do tell). I've turned on > >> commenting on the slides. Probably best if you comment there. > >> > >> I have a video of me giving this talk, but it's too rough to share... > >> > >> Thanks for any help you can give me. > >> > >> Warner > >> > > -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From clemc at ccc.com Sat Sep 14 06:06:52 2019 From: clemc at ccc.com (Clem Cole) Date: Fri, 13 Sep 2019 16:06:52 -0400 Subject: [TUHS] My EuroBSDcon talk (preview for commentary) In-Reply-To: References: Message-ID: Another thought -- the first commercial licensee was Rand. Hired some former Harvard students who brought UNIX with them. You probably need to add things like Rand Ports (a.k.a. named pipes) which came from there. Also Chesson and Co did the original ArpaNET NCP at University of Ill with some help from the Rand folks. That was done on a V6 system ~ 1978 You also need need Ken's famous V6 'patch' tape -- that 'leaked' On Fri, Sep 13, 2019 at 4:02 PM Clem Cole wrote: > BTW: I just thought of something else.... one of the b*tched about the > commercial redistribution license from V7 in 1979, that was not fixed until > the SVR3 licensing the mid-late 1980s was AT&T's source policy. As I > said, a commercial source license was $20K for the first CPU and 5K for > each additional one. Later (System V) it went to $50K for the first and > $10K for each additional. But what really ticked off the vendors like > DEC, Masscomp, Sun et al, was that each system that sources on was supposed > to one of the 'second CPU licenses' - the binary license was not good > enough. > > What most of us did, was make sure any system that was a 'source control' > or 'master' system at any 'site' had a full source license, but we were all > in violation of the source agreement on our personal workstations. The > argument was the sources on people's machines was ephemeral and not > 'stored' there. But it was definitely contentious. > > > > On Fri, Sep 13, 2019 at 3:47 PM Clem Cole wrote: > >> slide 4 -- All of HP-UX, Ultrix and Digital UNIX/Tru64 are BSD kernels. >> HP-UP and Tru64 support System V calls. >> >> BTW: DG-UX and Stratus built their own kernels, but used System V >> command systems and System Call definitions - which are not listed. >> >> Slide 6 - if you want it I have another picture of the GE system from >> some of their literature has a view of all of the components. Send me >> email if you want it. >> >> Slide 8 - Sets out to write version of Fortran came up with B. Uses B to >> write Assembler >> >> Slide 9 - Wrong DEC logo. Should be the Blue one. The maroon version >> does not show up until the 1990s with Bob Palmer (and has bad memories for >> some of us). >> >> Slide 17 - Ken write PDP-11 assembler on PDP-7 in B. , Dennis starts to >> rewrite B compiler to output PDP-11 code. >> >> Slide 18 - B begins to become different enough that Dennis starts to call >> it nb [new B], eventually deviates enough to become new language >> >> Slide 19 - 4th Edition release outside of the BTL. Lou Katz >> becomes 'user zero' >> >> Slide 20 -- We need to get you the site and group name from Mash. It was >> not in Summit, it was not USG - but was in NJ. I thought it was Homdel but >> I that is purely speculation. >> Also the role of Columbus team needs to be defined. >> Ask Mary Ann. >> >> Slide 21 -- I'm not going to argue - but I would ask you to add a >> disclaimer. This is what you could reconstruct, but there is some >> question of some of the arrows. Heinz might be able to help, but as >> Stienhart and I have said, its believed to be in LA; but no one has tracked >> him down as he has been pursuing non-computer interests. >> >> Slide 22 --4th Edition went to Katz that this is wrong, who sometimes >> reads this mailing list. If not, send me a note, I'll reintroduce you. He >> might be able to give you a data. Check with Warren, my >>memory<< is that >> some of userland is still in C although a lot assembler is still there. >> >> Slide 23 -- ??widespread?? -- I'm not sure I would use that. Not even >> 100 sites yet. Also there were not "commercial version" this was the >> first "commercial license" -- big difference [contact me if you want >> explanation]. IIRC fee was 15K per CPU. Commercial redistribution doesn't >> occur until after 7th is released and was a separate license. I would >> add, Mike Lesk's portable C library is starting to be used, but most C >> program do their own I/O with read/write >> >> First real install man page and Dennis build tape installation >> system. Earlier version released as RK05 disk copies. >> Also numerous new peripherals. IIRC Support for the 11/40 >> starts here, 4th & 5th needed a 45 class, and earlier used the 20 with the >> CSS MMU. >> >> Slide 24 -- CMU uses it to teaches OS class. makes student in class sign >> a sub-license. >> >> Slide 25 - missing the first USENIX tapes. which include Harvard and the >> like. Warren and I can probably help a little here. >> >> Slide 26 - new licenses. Commercial license fees change to 20K for 1st >> CPU/5K for each CPU afterward. CMU buys first commercial license to use >> UNIX to make money [after Cole and Klein go on strike]. Case Western >> follows suit 6month later. AT&T agrees for the Universities that they >> only had to declare one CPU as commercial and could intermix otherwise and >> notifies all the universities that if they were using it for commercial >> purposes, then needed a license. >> >> AT&T creates first redistribution license. Needed at least one $20K >> commercial CPU and then $150k for the rights to redistribute. Originally >> $1K per binary CPU. >> >> Slide 27 -- missing Purdue Dual Vax and CMU Mach >> >> Slide 28 - APS had NH which was the model the DEC plate you show. >> Maddog has it now on his Jeep when aps moved to CA (he also has the NH >> Linux plate but I don't remember the car -- you can ask him). I have had >> the Massachusetts UNIX plate since 1983 (it's on my model S of course). >> ghg has indiana from around the same time (I think on a pickup). wnj had >> the CA vmunix on his Ferrari, but I don't know if he still has it or what >> its on. >> >> Slide 29 - Look in HenrySpencer-TUHS.org -- you'll find tail but not head. >> >> Slide 31 - Job Control can from Europe via MIT. Jim Kulp wrote it. >> Noel and I can give you the story if you want it. It was on the PDP-11 >> there. Joy modified csh and added it to 4.1 >> >> Slide 32 -- JC was not from UCB. Joy got it from MIT -- Dennis create >> ENV and it was first distributed in V7. >> >> Slide 33 -- No Bourne supported ENV in the new shell -- see me earlier >> email for how all this went down or ask Steve yourself. >> >> Slide 34 -- PCC was included, but the Ritchie Compiler (a.k.a. Typesetter >> C) was the default compiler. You are missing a step BTW -- typesetter C >> was released between V6 and V7. As is the first draft of the White Book. >> The new compiler had stdio but targets V6. >> Also mpx was part of DataKit support. >> >> Slide 35 -- Not sure that is true. I thought Microsoft's Xenix ships >> before Venix. Particularly since you made the comment about System III >> The original 8086 Xenix was a pure V7 port, with a few additions Gordon >> brought with him from Purdue (i.e. ghg hacks). >> >> Slide 52/53/54/55 -- wrong logo (see above) >> >> >> >> >> >> >> >> >> >> >> On Thu, Sep 12, 2019 at 11:21 PM Warner Losh wrote: >> >>> OK. I've shared my slides for the talk. >>> >>> Some of the family trees are simplified (V7 doesn't have room for all >>> its ports, for example) >>> Some of it is a little cheeseball since I'm also trying to be witty and >>> entertaining (we'll see how that goes). >>> Please don't share them around until after my talk on the September 20th >>> >>> I'd like feedback on the bits I got wrong. Or left out. Or if you're in >>> this and don't want to be, etc. >>> >>> All the slides after the Questions slide won't be presented and will >>> likely be deleted. >>> >>> >>> https://docs.google.com/presentation/d/177KxOif5oHARyIdZHDq-OO67_GVtMkzIAlDX-cHxgb4/edit?usp=sharing >>> >>> Please be kind (but if it sucks, please do tell). I've turned on >>> commenting on the slides. Probably best if you comment there. >>> >>> I have a video of me giving this talk, but it's too rough to share... >>> >>> Thanks for any help you can give me. >>> >>> Warner >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon at fourwinds.com Sat Sep 14 06:24:37 2019 From: jon at fourwinds.com (Jon Steinhart) Date: Fri, 13 Sep 2019 13:24:37 -0700 Subject: [TUHS] My EuroBSDcon talk (preview for commentary) In-Reply-To: References: Message-ID: <201909132024.x8DKObEP013266@darkstar.fourwinds.com> Not sure about the last bullet on slide 18. I think that it would be more correct to say "format" instead of "typeset" since I don't think that the C/A/T came out until 1972. I guess it all comes down to whether or not you consider nroff on an ASR-37 to be typesetting. Jon From clemc at ccc.com Sat Sep 14 06:43:42 2019 From: clemc at ccc.com (Clem Cole) Date: Fri, 13 Sep 2019 16:43:42 -0400 Subject: [TUHS] My EuroBSDcon talk (preview for commentary) In-Reply-To: <201909132024.x8DKObEP013266@darkstar.fourwinds.com> References: <201909132024.x8DKObEP013266@darkstar.fourwinds.com> Message-ID: Jon - Good catch and that is a good reminder. Warner - You need to add troff and the C/A/T to your timeline. They were too important. What I don't remember, although Doug or Steve might, was the original troff 4th or 5th edition? bwk did ditroff, later with the addition of the APS5. FWIW: It was for 6th edition and post 1BSD that Tom Ferin did the original vcat(1) work at UCSF's PDP-11. It would get spread later to the world as part of one of the BSDs, but the original emulation of a C/A/T4 with a plotter support came from Tom, his graphics lab and the earlier work with the Hershey fonts that CMU and Stanford had done to support the XGP for the PDP-10s. But that was super important for why people wanted UNIX early on. On Fri, Sep 13, 2019 at 4:24 PM Jon Steinhart wrote: > Not sure about the last bullet on slide 18. I think that it would be more > correct to say "format" instead of "typeset" since I don't think that the > C/A/T came out until 1972. I guess it all comes down to whether or not you > consider nroff on an ASR-37 to be typesetting. > > Jon > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dds at aueb.gr Sat Sep 14 06:53:05 2019 From: dds at aueb.gr (Diomidis Spinellis) Date: Fri, 13 Sep 2019 23:53:05 +0300 Subject: [TUHS] My EuroBSDcon talk (preview for commentary) In-Reply-To: References: <201909132024.x8DKObEP013266@darkstar.fourwinds.com> Message-ID: <463d5cc4-9bef-9ac3-a680-a5161d664dc1@aueb.gr> The Fourth Edition manual was typeset in troff: https://dspinellis.github.io/unix-v4man/v4man.pdf https://github.com/dspinellis/unix-v4man The Third Edition was nroff: https://dspinellis.github.io/unix-v3man/v3man.pdf https://github.com/dspinellis/unix-v3man On 13-Sep-19 23:43, Clem Cole wrote: > Jon - Good catch and that is a good reminder. > Warner - You need to add troff and the C/A/T to your timeline.  They > were too important.   What I don't remember, although Doug or Steve > might, was the original troff 4th or 5th edition?  bwk did > ditroff, later with the addition of the APS5. From steffen at sdaoden.eu Sat Sep 14 07:11:04 2019 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Fri, 13 Sep 2019 23:11:04 +0200 Subject: [TUHS] SCCS In-Reply-To: <8db2e89c-ce50-a453-e38a-ecdfe69a746c@e-bbes.com> References: <20190911181101.GF3143@mcvoy.com> <20190912034346.GJ2046@mcvoy.com> <1457a2d6-2f17-482d-e4f7-ace439d34ca8@neophilic.com> <8db2e89c-ce50-a453-e38a-ecdfe69a746c@e-bbes.com> Message-ID: <20190913211104.aMZXy%steffen@sdaoden.eu> emanuel stiebler wrote in <8db2e89c-ce50-a453-e38a-ecdfe69a746c at e-bbes.com>: |On 2019-09-12 19:29, Clem Cole wrote: |> On Thu, Sep 12, 2019 at 1:16 PM Eric Allman > wrote: |> |>  At thispoint I'm using git because, well, all the cool kids are |> doing it, and |> since I work at the university I have to go with the flow sometimes. |> And git has some nice properties.  On the other hand, I have \ |> shot myself |> in the foot with git more times than the sum of all other screwups \ |> with |> all other source management systems combined. |> |> eric |> |> +1  | |I have this one on the waqll in the office: |https://xkcd.com/1597/ I for one am so happy to have git that i cannot tell you how much that is. I have used rcs, cvs, subversion, back to cvs, mercurial over the years,, and for some small things also sccs. All of it has been a pain here or there. Yes, the weave. Schily wants to provide real changeset support for sccs (tagging is real problem), i think. No, stashing, simply commiting something half-ready, amending, rebasing, and, very important, proper garbage collection of thrown away or otherwise useless stuff, i will never miss again. The only bad aspects is the lack of an automatically expanded, human readable version number that can be included in files, and that you cannot simply checkout, say, one directory, but only the entire repository. Its capability to work with shallow repositories has improved over the years, however. Nonetheless, i claim that for the maintainer of one or two ports/packages it is much nicer to use cvs, and only check out what really is of interest to you; than to checkout thousands of things that is. A nice weekend from Germany i wish, --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 lm at mcvoy.com Sat Sep 14 07:17:51 2019 From: lm at mcvoy.com (Larry McVoy) Date: Fri, 13 Sep 2019 14:17:51 -0700 Subject: [TUHS] SCCS In-Reply-To: <20190913211104.aMZXy%steffen@sdaoden.eu> References: <20190911181101.GF3143@mcvoy.com> <20190912034346.GJ2046@mcvoy.com> <1457a2d6-2f17-482d-e4f7-ace439d34ca8@neophilic.com> <8db2e89c-ce50-a453-e38a-ecdfe69a746c@e-bbes.com> <20190913211104.aMZXy%steffen@sdaoden.eu> Message-ID: <20190913211751.GF2046@mcvoy.com> On Fri, Sep 13, 2019 at 11:11:04PM +0200, Steffen Nurpmeso wrote: > emanuel stiebler wrote in <8db2e89c-ce50-a453-e38a-ecdfe69a746c at e-bbes.com>: > |On 2019-09-12 19:29, Clem Cole wrote: > |> On Thu, Sep 12, 2019 at 1:16 PM Eric Allman |> > wrote: > |> > |> ??At thispoint I'm using git because, well, all the cool kids are > |> doing it, and > |> since I work at the university I have to go with the flow sometimes. > |> And git has some nice properties.?? On the other hand, I have \ > |> shot myself > |> in the foot with git more times than the sum of all other screwups \ > |> with > |> all other source management systems combined. > |> > |> eric > |> > |> +1?? > | > |I have this one on the waqll in the office: > |https://xkcd.com/1597/ > > I for one am so happy to have git that i cannot tell you how much > that is. I have used rcs, cvs, subversion, back to cvs, > mercurial over the years,, and for some small things also sccs. > All of it has been a pain here or there. Yes, the weave. Schily > wants to provide real changeset support for sccs (tagging is real > problem), i think. I don't know why, BitKeeper does that and is open source under a liberal license (Apache v2). From clemc at ccc.com Sat Sep 14 07:31:17 2019 From: clemc at ccc.com (Clem Cole) Date: Fri, 13 Sep 2019 17:31:17 -0400 Subject: [TUHS] My EuroBSDcon talk (preview for commentary) In-Reply-To: References: Message-ID: BTW: I just found my PWB 1.0 manual. The date is May 1977, authors are T. (Ted) Dolotta, R. (Dick) Haight and E. Piskorik and it lists the site as 'Piscataway' as the site on the acknowlegements page. On Fri, Sep 13, 2019 at 4:06 PM Clem Cole wrote: > Another thought -- the first commercial licensee was Rand. Hired some > former Harvard students who brought UNIX with them. You probably need to > add things like Rand Ports (a.k.a. named pipes) which came from there. > Also Chesson and Co did the original ArpaNET NCP at University of Ill > with some help from the Rand folks. That was done on a V6 system ~ 1978 > > You also need need Ken's famous V6 'patch' tape -- that 'leaked' > > > On Fri, Sep 13, 2019 at 4:02 PM Clem Cole wrote: > >> BTW: I just thought of something else.... one of the b*tched about the >> commercial redistribution license from V7 in 1979, that was not fixed until >> the SVR3 licensing the mid-late 1980s was AT&T's source policy. As I >> said, a commercial source license was $20K for the first CPU and 5K for >> each additional one. Later (System V) it went to $50K for the first and >> $10K for each additional. But what really ticked off the vendors like >> DEC, Masscomp, Sun et al, was that each system that sources on was supposed >> to one of the 'second CPU licenses' - the binary license was not good >> enough. >> >> What most of us did, was make sure any system that was a 'source control' >> or 'master' system at any 'site' had a full source license, but we were all >> in violation of the source agreement on our personal workstations. The >> argument was the sources on people's machines was ephemeral and not >> 'stored' there. But it was definitely contentious. >> >> >> >> On Fri, Sep 13, 2019 at 3:47 PM Clem Cole wrote: >> >>> slide 4 -- All of HP-UX, Ultrix and Digital UNIX/Tru64 are BSD >>> kernels. HP-UP and Tru64 support System V calls. >>> >>> BTW: DG-UX and Stratus built their own kernels, but used System V >>> command systems and System Call definitions - which are not listed. >>> >>> Slide 6 - if you want it I have another picture of the GE system from >>> some of their literature has a view of all of the components. Send me >>> email if you want it. >>> >>> Slide 8 - Sets out to write version of Fortran came up with B. Uses B >>> to write Assembler >>> >>> Slide 9 - Wrong DEC logo. Should be the Blue one. The maroon version >>> does not show up until the 1990s with Bob Palmer (and has bad memories for >>> some of us). >>> >>> Slide 17 - Ken write PDP-11 assembler on PDP-7 in B. , Dennis starts to >>> rewrite B compiler to output PDP-11 code. >>> >>> Slide 18 - B begins to become different enough that Dennis starts to >>> call it nb [new B], eventually deviates enough to become new language >>> >>> Slide 19 - 4th Edition release outside of the BTL. Lou Katz >>> becomes 'user zero' >>> >>> Slide 20 -- We need to get you the site and group name from Mash. It >>> was not in Summit, it was not USG - but was in NJ. I thought it was Homdel >>> but I that is purely speculation. >>> Also the role of Columbus team needs to be defined. >>> Ask Mary Ann. >>> >>> Slide 21 -- I'm not going to argue - but I would ask you to add a >>> disclaimer. This is what you could reconstruct, but there is some >>> question of some of the arrows. Heinz might be able to help, but as >>> Stienhart and I have said, its believed to be in LA; but no one has tracked >>> him down as he has been pursuing non-computer interests. >>> >>> Slide 22 --4th Edition went to Katz that this is wrong, who sometimes >>> reads this mailing list. If not, send me a note, I'll reintroduce you. He >>> might be able to give you a data. Check with Warren, my >>memory<< is that >>> some of userland is still in C although a lot assembler is still there. >>> >>> Slide 23 -- ??widespread?? -- I'm not sure I would use that. Not even >>> 100 sites yet. Also there were not "commercial version" this was the >>> first "commercial license" -- big difference [contact me if you want >>> explanation]. IIRC fee was 15K per CPU. Commercial redistribution doesn't >>> occur until after 7th is released and was a separate license. I would >>> add, Mike Lesk's portable C library is starting to be used, but most C >>> program do their own I/O with read/write >>> >>> First real install man page and Dennis build tape installation >>> system. Earlier version released as RK05 disk copies. >>> Also numerous new peripherals. IIRC Support for the 11/40 >>> starts here, 4th & 5th needed a 45 class, and earlier used the 20 with the >>> CSS MMU. >>> >>> Slide 24 -- CMU uses it to teaches OS class. makes student in class >>> sign a sub-license. >>> >>> Slide 25 - missing the first USENIX tapes. which include Harvard and the >>> like. Warren and I can probably help a little here. >>> >>> Slide 26 - new licenses. Commercial license fees change to 20K for 1st >>> CPU/5K for each CPU afterward. CMU buys first commercial license to use >>> UNIX to make money [after Cole and Klein go on strike]. Case Western >>> follows suit 6month later. AT&T agrees for the Universities that they >>> only had to declare one CPU as commercial and could intermix otherwise and >>> notifies all the universities that if they were using it for commercial >>> purposes, then needed a license. >>> >>> AT&T creates first redistribution license. Needed at least one $20K >>> commercial CPU and then $150k for the rights to redistribute. Originally >>> $1K per binary CPU. >>> >>> Slide 27 -- missing Purdue Dual Vax and CMU Mach >>> >>> Slide 28 - APS had NH which was the model the DEC plate you show. >>> Maddog has it now on his Jeep when aps moved to CA (he also has the NH >>> Linux plate but I don't remember the car -- you can ask him). I have had >>> the Massachusetts UNIX plate since 1983 (it's on my model S of course). >>> ghg has indiana from around the same time (I think on a pickup). wnj had >>> the CA vmunix on his Ferrari, but I don't know if he still has it or what >>> its on. >>> >>> Slide 29 - Look in HenrySpencer-TUHS.org -- you'll find tail but not >>> head. >>> >>> Slide 31 - Job Control can from Europe via MIT. Jim Kulp wrote it. >>> Noel and I can give you the story if you want it. It was on the PDP-11 >>> there. Joy modified csh and added it to 4.1 >>> >>> Slide 32 -- JC was not from UCB. Joy got it from MIT -- Dennis >>> create ENV and it was first distributed in V7. >>> >>> Slide 33 -- No Bourne supported ENV in the new shell -- see me earlier >>> email for how all this went down or ask Steve yourself. >>> >>> Slide 34 -- PCC was included, but the Ritchie Compiler (a.k.a. >>> Typesetter C) was the default compiler. You are missing a step BTW -- >>> typesetter C was released between V6 and V7. As is the first draft of the >>> White Book. The new compiler had stdio but targets V6. >>> Also mpx was part of DataKit support. >>> >>> Slide 35 -- Not sure that is true. I thought Microsoft's Xenix ships >>> before Venix. Particularly since you made the comment about System III >>> The original 8086 Xenix was a pure V7 port, with a few additions Gordon >>> brought with him from Purdue (i.e. ghg hacks). >>> >>> Slide 52/53/54/55 -- wrong logo (see above) >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On Thu, Sep 12, 2019 at 11:21 PM Warner Losh wrote: >>> >>>> OK. I've shared my slides for the talk. >>>> >>>> Some of the family trees are simplified (V7 doesn't have room for all >>>> its ports, for example) >>>> Some of it is a little cheeseball since I'm also trying to be witty and >>>> entertaining (we'll see how that goes). >>>> Please don't share them around until after my talk on the September 20th >>>> >>>> I'd like feedback on the bits I got wrong. Or left out. Or if you're in >>>> this and don't want to be, etc. >>>> >>>> All the slides after the Questions slide won't be presented and will >>>> likely be deleted. >>>> >>>> >>>> https://docs.google.com/presentation/d/177KxOif5oHARyIdZHDq-OO67_GVtMkzIAlDX-cHxgb4/edit?usp=sharing >>>> >>>> Please be kind (but if it sucks, please do tell). I've turned on >>>> commenting on the slides. Probably best if you comment there. >>>> >>>> I have a video of me giving this talk, but it's too rough to share... >>>> >>>> Thanks for any help you can give me. >>>> >>>> Warner >>>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Sat Sep 14 07:36:32 2019 From: dave at horsfall.org (Dave Horsfall) Date: Sat, 14 Sep 2019 07:36:32 +1000 (EST) Subject: [TUHS] [SPAM] Re: SCCS In-Reply-To: <20190913080009.GG88690@server.rulingia.com> References: <20190911181101.GF3143@mcvoy.com> <20190912034346.GJ2046@mcvoy.com> <20190912043145.GA12480@mcvoy.com> <20190913041117.GR2046@mcvoy.com> <20190913080009.GG88690@server.rulingia.com> Message-ID: On Fri, 13 Sep 2019, Peter Jeremy wrote: >> Giggle... I found I could actually *edit* an SCCS file, provided I reset >> the checksum to zero (it was then recalculated). > > I think that was deliberate. ISTR editing SCCS files and repairing the > checksum as well, though I don't recally exactly how. I don't recall why I had to edit the SCCS file (this was decades ago) but it was just a plain ASCII file, with the checksum as a string of digits up near the front somewhere. It *may* be because I screwed up an update, and didn't want to own up to it :-) I don't recall whether SCCS allowed updates to be backed out. >> I believe that NFS is much more reliable now (yes, it used to be awful). > > NFS ran much faster when you turned off the UDP checksums as well. > (Though there was still the Ethernet CRC32). Blerk... That just tells you that the packet came across the wire more or less OK. -- Dave From norman at oclsc.org Sat Sep 14 07:37:12 2019 From: norman at oclsc.org (Norman Wilson) Date: Fri, 13 Sep 2019 17:37:12 -0400 Subject: [TUHS] SCCS Message-ID: <1568410636.21547.for-standards-violators@oclsc.org> Well, if we're going to get into editor, erm, version-control wars, I'll state my unpopular opinion that SCCS and RCS were no good at all and CVS only pretended to be any good. Subversion was the first system I could stand using. The actual basis for that opinion (and it's just my opinion but it's not pulled out of hyperspace) is that the older systems think only about one file at a time, not collections of files. To me that's useless for any but the most-trivial programming (and wasn't non-trivial programming what spurred such systems?). When I am working on a non-trivial program, there's almost always more than one source file, and to keep things clean often means refactoring: splitting one file into several, merging different files, removing files that contain no-longer-useful junk, adding files that implement new things, renaming files. A revision-control system that thinks only about one file at a time can't keep track of those changes. To me that makes it worse than useless; not only can it not record a single commit with a single message and version number when files are split and combined, it requires extra work to keep all those files under version control at all. CVS makes an attempt to handle those things, but the effect is clunky in practice compared to successors like svn. One shouldn't underestimate the importance of a non-clunky interface. In retrospect it seems stupid that we didn't have some sort of revision control discipline in Research UNIX, but given the clunkiness of SCCS and RCS and CVS, there's no way most of us would have put up with it. Given that we often had different people playing with the same program concurrently, it would have taken at least CVS to meet our needs anyway. Norman `recidivist' Wilson Toronto ON From clemc at ccc.com Sat Sep 14 07:45:51 2019 From: clemc at ccc.com (Clem Cole) Date: Fri, 13 Sep 2019 17:45:51 -0400 Subject: [TUHS] My EuroBSDcon talk (preview for commentary) In-Reply-To: <463d5cc4-9bef-9ac3-a680-a5161d664dc1@aueb.gr> References: <201909132024.x8DKObEP013266@darkstar.fourwinds.com> <463d5cc4-9bef-9ac3-a680-a5161d664dc1@aueb.gr> Message-ID: Awesome -- great way to figure it out, although I'm not sure 3rd edition was nroff, I think it might have been roff. I think a smart test is to check to see if those sources used a macro package or not. If not macro package, I think that tells us that the likely formatting program was roff. It does leave us an interesting question, when did the original roff(1) show up and when did nroff(1). The original, roff(1), was early, and of course not until after the original PDP-11/20 port. But was it as early as first edition? roff was the first formatting program. nroff replaced it later on, although roff lived through the 6th edition (I do not believe it is on the v7 tape). I was under the impression that the order is this ... roff was written for either v1 or v2 in 1970 or 71; I thought originally by Ken to be similar to the runoff that ran on the GE systems. At some point the team recieved the /C/A/T and Joseph Ossanna wrote a new program to support it, *a.k.a. *troff, that was similar to roff but troff was not a superset of the original program. nroff was then written after troff came into being to parrot the behavior of troff using an ASR-37; but I do not know who was the author (it might have been Ossanna). But it was a third program, that used the same macro packages as troff that started to appear for Ossanna's program and the input language was changed so that a document author could know what was the output target. As I said, nroff and roff were in the v6 distribution, although not troff if I remember it correctly; although troff was part of PWB 1.0. The inclusion of both roff and nroff was because some of the Unix papers/documentation used roff for formatting, not the troff/nroff input syntax. That said, the PWB man pages have the roff manpage, as well as a single man page for both nroff and troff with sections later that say 'nroff only' and 'troff only.' Also I do not remember having any macro packages for roff(1), but their might have been some, although I just checked the PWB man page and it does not list a .so command to read in macros, there is no mention of a macro switch on the command line and in the files section the only external file it used was the hyphenation tables. Finally, Ossanna tragically died and some time later the new APS/5 was obtained. So, bwk wrote a new program yet, that used post processors and some front end tables, to allow the 'typesetter' portion to work regardless of the output device (*i.e.* device independent troff or ditroff). With the idea only a single program would be needed to be supported. By this point nothing in the Research 'releases' required the original roff program and since it was in assembler, I believe that it was dropped from all further support. Clem On Fri, Sep 13, 2019 at 4:53 PM Diomidis Spinellis wrote: > The Fourth Edition manual was typeset in troff: > https://dspinellis.github.io/unix-v4man/v4man.pdf > https://github.com/dspinellis/unix-v4man > > The Third Edition was nroff: > https://dspinellis.github.io/unix-v3man/v3man.pdf > https://github.com/dspinellis/unix-v3man > > On 13-Sep-19 23:43, Clem Cole wrote: > > Jon - Good catch and that is a good reminder. > > Warner - You need to add troff and the C/A/T to your timeline. They > > were too important. What I don't remember, although Doug or Steve > > might, was the original troff 4th or 5th edition? bwk did > > ditroff, later with the addition of the APS5. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bakul at bitblocks.com Sat Sep 14 07:48:58 2019 From: bakul at bitblocks.com (Bakul Shah) Date: Fri, 13 Sep 2019 14:48:58 -0700 Subject: [TUHS] SCCS In-Reply-To: Your message of "Fri, 13 Sep 2019 14:17:51 -0700." <20190913211751.GF2046@mcvoy.com> References: <20190911181101.GF3143@mcvoy.com> <20190912034346.GJ2046@mcvoy.com> <1457a2d6-2f17-482d-e4f7-ace439d34ca8@neophilic.com> <8db2e89c-ce50-a453-e38a-ecdfe69a746c@e-bbes.com> <20190913211104.aMZXy%steffen@sdaoden.eu> <20190913211751.GF2046@mcvoy.com> Message-ID: <20190913214905.339ED1570CE9@mail.bitblocks.com> On Fri, 13 Sep 2019 14:17:51 -0700 Larry McVoy wrote: > On Fri, Sep 13, 2019 at 11:11:04PM +0200, Steffen Nurpmeso wrote: > > > > I for one am so happy to have git that i cannot tell you how much > > that is. I have used rcs, cvs, subversion, back to cvs, > > mercurial over the years,, and for some small things also sccs. > > All of it has been a pain here or there. Yes, the weave. Schily > > wants to provide real changeset support for sccs (tagging is real > > problem), i think. > > I don't know why, BitKeeper does that and is open source under > a liberal license (Apache v2). This is because in git the "id" of a changeset is its sha1 checksum. Given that, you can only reference it in a subsequent changeset. This is a problem in that there is no git built-in way to correlate a built binary with a particular changeset id of its sources but you end up using your own convention. E.g. set env. var VERSION or some such to the id during the compile step but it is a bother. From lm at mcvoy.com Sat Sep 14 07:51:27 2019 From: lm at mcvoy.com (Larry McVoy) Date: Fri, 13 Sep 2019 14:51:27 -0700 Subject: [TUHS] SCCS In-Reply-To: <1568410636.21547.for-standards-violators@oclsc.org> References: <1568410636.21547.for-standards-violators@oclsc.org> Message-ID: <20190913215127.GG2046@mcvoy.com> On Fri, Sep 13, 2019 at 05:37:12PM -0400, Norman Wilson wrote: > The actual basis for that opinion (and it's just my opinion but it's > not pulled out of hyperspace) is that the older systems think only > about one file at a time, not collections of files. Yep. That's the problem that BitKeeper solved first, correctly, with atomic commits, full rename tracking, etc. If you googled "changeset" back in 1996 before BitKeeper started happening there were 6 hits (mostly for a really weird system called Aide De Camp). If you googled it 5 years later there were millions of hits, almost 100% BitKeeper related. One of the selling points of BK back in the day was "remember when you forgot to tag the tree in CVS and you couldn't get back to where you wanted to be? Yeah, every commit in BK is a tag, you can roll back to anywhere." So I agree with you Norm that exact problem was part of why BitKeeper was invented. When I was going on about SCCS, I was admiring the weave, it's a neat way to do things. But I wouldn't suggest anyone use just SCCS today, that's nuts. From wkt at tuhs.org Sat Sep 14 08:13:45 2019 From: wkt at tuhs.org (Warren Toomey) Date: Sat, 14 Sep 2019 08:13:45 +1000 Subject: [TUHS] earliest Unix roff In-Reply-To: References: <201909132024.x8DKObEP013266@darkstar.fourwinds.com> <463d5cc4-9bef-9ac3-a680-a5161d664dc1@aueb.gr> Message-ID: <20190913221345.GA16129@minnie.tuhs.org> On Fri, Sep 13, 2019 at 05:45:51PM -0400, Clem Cole wrote: > It does leave us an interesting question, when did the original roff(1) > show up and when did nroff(1). The original, roff(1), was early, and > of course not until after the original PDP-11/20 port. But was it as > early as first edition? roff was the first formatting program. nroff > replaced it later on, although roff lived through the 6th edition (I do > not believe it is on the v7 tape). There was a roff on PDP-7 Unix: By the spring of 1971, it was generally agreed that no one had the slightest interest in scrapping Unix. Therefore, we transliterated the roff text formatter into PDP-11 assembler language, starting from the PDP-7 version that had been transliterated from McIlroy’s BCPL version on Multics, which had in turn been inspired by J. Saltzer’s runoff program on CTSS. >From "The Evolution of the Unix Time-sharing System" http://www.read.seas.harvard.edu/~kohler/class/aosref/ritchie84evolution.pdf Cheers, Warren From norman at oclsc.org Sat Sep 14 08:01:14 2019 From: norman at oclsc.org (Norman Wilson) Date: Fri, 13 Sep 2019 18:01:14 -0400 Subject: [TUHS] [SPAM] Re: SCCS Message-ID: <1568412078.22454.for-standards-violators@oclsc.org> Peter Jeremy: > NFS ran much faster when you turned off the UDP checksums as well. > (Though there was still the Ethernet CRC32). Dave Horsfall: Blerk... That just tells you that the packet came across the wire more or less OK. ===== UDP (and TCP) checksums are nearly useless against the sort of corruption Larry described. Since they are a simple addition with carry wraparound, you can insert or remove any number of word-aligned pairs of zero octets without the checksum changing. I discovered this the hard way, while tracking down a kernel bug that caused exactly that sort of corruption. Does IPv6 require a meaningful checksum, or just the useless old ritual one? Norman Wilson Toronto ON From dave at horsfall.org Sat Sep 14 08:30:42 2019 From: dave at horsfall.org (Dave Horsfall) Date: Sat, 14 Sep 2019 08:30:42 +1000 (EST) Subject: [TUHS] [SPAM] Re: SCCS In-Reply-To: <1568412078.22454.for-standards-violators@oclsc.org> References: <1568412078.22454.for-standards-violators@oclsc.org> Message-ID: On Fri, 13 Sep 2019, Norman Wilson wrote: > UDP (and TCP) checksums are nearly useless against the sort of > corruption Larry described. Since they are a simple addition with carry > wraparound, you can insert or remove any number of word-aligned pairs of > zero octets without the checksum changing. I was thinking of an intermediate router (probably one that you never knew about) corrupting the checksum-less UDP packet, recalculating the Ethernet checksum, and your kernel happily accepting it; you now have an application that fails for some unknown reason. Never seen it in practice, but I've heard of it happening. -- Dave From clemc at ccc.com Sat Sep 14 08:55:24 2019 From: clemc at ccc.com (Clem Cole) Date: Fri, 13 Sep 2019 18:55:24 -0400 Subject: [TUHS] earliest Unix roff In-Reply-To: <20190913221345.GA16129@minnie.tuhs.org> References: <201909132024.x8DKObEP013266@darkstar.fourwinds.com> <463d5cc4-9bef-9ac3-a680-a5161d664dc1@aueb.gr> <20190913221345.GA16129@minnie.tuhs.org> Message-ID: Thanks. So we have a date that explains the pdp-11 assembler version - it was there at v1. On Fri, Sep 13, 2019 at 6:14 PM Warren Toomey wrote: > On Fri, Sep 13, 2019 at 05:45:51PM -0400, Clem Cole wrote: > > It does leave us an interesting question, when did the original > roff(1) > > show up and when did nroff(1). The original, roff(1), was early, and > > of course not until after the original PDP-11/20 port. But was it as > > early as first edition? roff was the first formatting program. > nroff > > replaced it later on, although roff lived through the 6th edition (I > do > > not believe it is on the v7 tape). > > There was a roff on PDP-7 Unix: > > By the spring of 1971, it was generally agreed that no one had the > slightest interest in scrapping Unix. Therefore, we transliterated > the roff text formatter into PDP-11 assembler language, starting from > the PDP-7 version that had been transliterated from McIlroy’s BCPL > version on Multics, which had in turn been inspired by J. Saltzer’s > runoff program on CTSS. > > From "The Evolution of the Unix Time-sharing System" > > > http://www.read.seas.harvard.edu/~kohler/class/aosref/ritchie84evolution.pdf > > Cheers, Warren > -- Sent from a handheld expect more typos than usual -------------- next part -------------- An HTML attachment was scrubbed... URL: From steffen at sdaoden.eu Sat Sep 14 09:03:12 2019 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Sat, 14 Sep 2019 01:03:12 +0200 Subject: [TUHS] SCCS In-Reply-To: <20190913211751.GF2046@mcvoy.com> References: <20190911181101.GF3143@mcvoy.com> <20190912034346.GJ2046@mcvoy.com> <1457a2d6-2f17-482d-e4f7-ace439d34ca8@neophilic.com> <8db2e89c-ce50-a453-e38a-ecdfe69a746c@e-bbes.com> <20190913211104.aMZXy%steffen@sdaoden.eu> <20190913211751.GF2046@mcvoy.com> Message-ID: <20190913230312.XaeCQ%steffen@sdaoden.eu> Larry McVoy wrote in <20190913211751.GF2046 at mcvoy.com>: |On Fri, Sep 13, 2019 at 11:11:04PM +0200, Steffen Nurpmeso wrote: |> emanuel stiebler wrote in <8db2e89c-ce50-a453-e38a-ecdfe69a746c at e-bbes.c\ |> om>: |>|On 2019-09-12 19:29, Clem Cole wrote: |>|> On Thu, Sep 12, 2019 at 1:16 PM Eric Allman |> > wrote: |>|> |>|> ??At thispoint I'm using git because, well, all the cool kids are |>|> doing it, and |>|> since I work at the university I have to go with the flow sometimes\ |>|> . |>|> And git has some nice properties.?? On the other hand, I have \ |>|> shot myself |>|> in the foot with git more times than the sum of all other screwups \ |>|> \ |>|> with |>|> all other source management systems combined. |>|> |>|> eric |>|> |>|> +1?? |>| |>|I have this one on the waqll in the office: |>|https://xkcd.com/1597/ |> |> I for one am so happy to have git that i cannot tell you how much |> that is. I have used rcs, cvs, subversion, back to cvs, ... |> All of it has been a pain here or there. Yes, the weave. Schily |> wants to provide real changeset support for sccs (tagging is real |> problem), i think. | |I don't know why, BitKeeper does that and is open source under |a liberal license (Apache v2). Diversity is something good i would say. With the constraint that it is real diversity, as nature produces, not as in modern times where the supermarket has two dozen sorts of margarine, and in the end it comes from Kraft or Nestle, which bought together a sortiment, and that is basically it, which (i bore you) has to result in save effects which dilutes recipes or ingredients. (I am the happy eater of Alsan-S, and are paying not getting paid for it. But that is ok.) So in fact this diversity rather is BitKeeper and Sun SCCS only. Yet two hears are better than one, sang Frank Sinatra. He is as convinced from SCCS and its interleaved deltas as you are, but he works on extending the plain original SCCS, which is pretty smaller; his presentation from the "Chemnitzer Linux Tage 2012" (linux days of former Karl-Marx-Stadt) [1] talks about this and also prominently mentions BitKeeper: . All modern distributed OSS version control systems base upon BitKeeper in the end. . BitKeeper bases upon the ideas of TeamWare. . TeamWare bases upon the ideas of NSE. . NSE is a frontend to SCCS. . Therewith all modern systems ultimately base upon SCCS. . Distributed operate TeamWare, BitKeeper, git, Mercurial. This logic convinces me. First, we take Manhattan, then we take Berlin. His SCCS is not a competitor to the BitKeeper suite, of course. But it roots in the original Sun code, just as Heirloom SCCS. [1] http://sccs.sourceforge.net/SCCS-Chemnitz-2012.pdf --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From steffen at sdaoden.eu Sat Sep 14 09:12:21 2019 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Sat, 14 Sep 2019 01:12:21 +0200 Subject: [TUHS] SCCS In-Reply-To: <20190913214905.339ED1570CE9@mail.bitblocks.com> References: <20190911181101.GF3143@mcvoy.com> <20190912034346.GJ2046@mcvoy.com> <1457a2d6-2f17-482d-e4f7-ace439d34ca8@neophilic.com> <8db2e89c-ce50-a453-e38a-ecdfe69a746c@e-bbes.com> <20190913211104.aMZXy%steffen@sdaoden.eu> <20190913211751.GF2046@mcvoy.com> <20190913214905.339ED1570CE9@mail.bitblocks.com> Message-ID: <20190913231221.-skm3%steffen@sdaoden.eu> Bakul Shah wrote in <20190913214905.339ED1570CE9 at mail.bitblocks.com>: |On Fri, 13 Sep 2019 14:17:51 -0700 Larry McVoy wrote: |> On Fri, Sep 13, 2019 at 11:11:04PM +0200, Steffen Nurpmeso wrote: |>> |>> I for one am so happy to have git that i cannot tell you how much |>> that is. I have used rcs, cvs, subversion, back to cvs, |>> mercurial over the years,, and for some small things also sccs. |>> All of it has been a pain here or there. Yes, the weave. Schily |>> wants to provide real changeset support for sccs (tagging is real |>> problem), i think. |> |> I don't know why, BitKeeper does that and is open source under |> a liberal license (Apache v2). | |This is because in git the "id" of a changeset is its sha1 |checksum. Given that, you can only reference it in a |subsequent changeset. This is a problem in that there is no |git built-in way to correlate a built binary with a particular |changeset id of its sources but you end up using your own |convention. E.g. set env. var VERSION or some such to the id |during the compile step but it is a bother. Linus Torvalds wrote an interesting message on that many years ago, which someone pointed me at ditto. Do not ask. git cannot generate human readable things by design, with branching and merging, and due to the distributed nature. I have a little (git pre-commit) script which keeps my SCCS IDs alive for my web pages, even after i converted them to git. But i think for code bases like NetBSD in particular this is a total show stopper (they really keep the "original" file preamble alive, do they?), but it also is for OpenBSD i think, and for FreeBSD i know that having a human readible sequentially increasing version number was a main reason to go for subversion. Even though there seems to be a growing number of people who want to switch to git, yes i think Warner Losh just said something like "when we will have switched to git, that will xy", this week? --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 reed at reedmedia.net Sat Sep 14 10:44:25 2019 From: reed at reedmedia.net (reed at reedmedia.net) Date: Fri, 13 Sep 2019 19:44:25 -0500 (CDT) Subject: [TUHS] a book (was Re: PWB vs Unix/TS) In-Reply-To: References: Message-ID: There needs to be a book with stuff like this. There is no Unix history book that I have ever seen with the depth of information in threads like this and others on TUHS. It would be a huge project and hard to tell if there would me more than just recognition and intrinsic rewards for the effort -- but maybe that is enough. (As an example, I have spent hundreds if not thousands of hours researching a small subset: Berkeley Unix history. Attempted to contact hundreds of historical participants. Interviewed near 100 people; most by email, but some in person or by phone -- even postal mail! Building a massive collection of historical data. Read over 30 physical books covering very small parts of the story. Watched many videos (and notes). Getting documents scanned and sent to me. It is a very detailed effort -- such as a single long chapter on the Virtual Vax/UNIX / London/Reiser / Babaoglu story with 168 citations or the single chapters on the official unofficial patchkits, lawsuit, etc. -- and there is nothing in this field to compare it too. I have over 243 bibtex entries already and 215 citations left to add to my .bib file. During that time, I have published six other books, some written from scratch. Some have suggested I use Kickstarter or similar as a financial incentive to finish it off.) Since the Unix story is so huge, a first volume could be up through System III, for example, but maybe that is too much. Anyone know of anyone writing a thorough Unix history book? Does it make sense to use a kickstarter? I may bring up in a different thread, but I am presenting about Unix history at Dallas Ft. Worth UNIX Users Group soon. They are planning to have two meetings (different months) dedicated to the history (50th anniversary). Jeremy C. Reed p.s. Sorry to mention this, but time is running out: $ grep -i decease /home/reed/book/bsd-history/PEOPLE | wc -l 17 pps. My other chapters: beginning.tex:\chapter{In the beginning ...} 2bsd.tex:\chapter{Second Berkeley Software Tape} 3bsd.tex:\chapter{Welcome to Virtual Vax/UNIX} 2bsd-part2.tex:\chapter{2BSD becomes an operating system} 4bsd.tex:\chapter{4BSD} 43bsd.tex:\chapter{4.3BSD -- The Internet Server} 2bsd-part3.tex:\chapter{The 16-bit 2BSD continues} 43bsd-part2.tex:\chapter{To open source BSD} commercial.tex:\chapter{Commercial Unixes using BSD} 44bsd.tex:\chapter{4.4BSD} bsdi.tex:\chapter{BSDI} 386bsd.tex:\chapter{386BSD Part 1} lawsuit.tex:\chapter{Lawsuit} patchkit.tex:\chapter{The official unofficial patchkits} netbsd.tex:\chapter{NetBSD} freebsd.tex:\chapter{FreeBSD} 386bsd-part3.tex:\chapter{386BSD Part 2} bsdi-part2.tex:\chapter{BSDI part 2} openbsd.tex:\chapter{OpenBSD} netbsd-part2.tex:\chapter{NetBSD -- Part 2} dragonfly.tex:\chapter{DragonFly BSD} 3bsd-license.tex:\chapter{3BSD Software Agreement (1979)} 4bsd-license.tex:\chapter{4BSD Software Agreement (1980)} ----------------------- echo Ohl zl obbx uggc://errqzrqvn.arg/obbxf/csfrafr/ | \ tr "Onoqrsuvxzabcefghl" "Babdefhikmnoprstuy" From lm at mcvoy.com Sat Sep 14 11:55:17 2019 From: lm at mcvoy.com (Larry McVoy) Date: Fri, 13 Sep 2019 18:55:17 -0700 Subject: [TUHS] [SPAM] Re: SCCS In-Reply-To: <20190913230312.XaeCQ%steffen@sdaoden.eu> References: <20190911181101.GF3143@mcvoy.com> <20190912034346.GJ2046@mcvoy.com> <1457a2d6-2f17-482d-e4f7-ace439d34ca8@neophilic.com> <8db2e89c-ce50-a453-e38a-ecdfe69a746c@e-bbes.com> <20190913211104.aMZXy%steffen@sdaoden.eu> <20190913211751.GF2046@mcvoy.com> <20190913230312.XaeCQ%steffen@sdaoden.eu> Message-ID: <20190914015517.GD12480@mcvoy.com> On Sat, Sep 14, 2019 at 01:03:12AM +0200, Steffen Nurpmeso wrote: > He is as convinced from SCCS and its interleaved deltas as you > are, but he works on extending the plain original SCCS, which is > pretty smaller; his presentation from the "Chemnitzer Linux Tage > 2012" (linux days of former Karl-Marx-Stadt) [1] talks about this > and also prominently mentions BitKeeper: > > . All modern distributed OSS version control systems base upon > BitKeeper in the end. Sort of. Monotone, Darcs, and one other one I can't remember did not draw from BitKeeper. Mercurial, Git, and the Australian one that I can't remember definitely do. > . BitKeeper bases upon the ideas of TeamWare. Only in that I am the primary author of both. It does support the idea that SCCS is the basis for both, though Teamware used the real SCCS and I rewrote SCCS from scratch and then extended it quite a bit. BitKeeper's SCCS tracks a lot more than SCCS does, pathnames, permissions, hostnames, etc. > . TeamWare bases upon the ideas of NSE. That's absolutely false. TeamWare, which is the productized version of NSElite, which I wrote all of, was a reaction to how absolute shiite NSE was. I had friends in the Sun kernel group that quit because they were forced to use NSE. It was awful. I got into source management because I was well known at Sun as the guy that could fix performance problems so I was asked to look at NSE. One look told me that I couldn't fix NSE but the source management problem space needed some help. > . NSE is a frontend to SCCS. That's true. > . Therewith all modern systems ultimately base upon SCCS. That is a big stretch, it's just not true. I love the SCCS file format but to say all modern systems are based on SCCS is 100% false. BitKeeper is. That's it. > . Distributed operate TeamWare, BitKeeper, git, Mercurial. Git and Mercurial were going for append only data structures. That's not SCCS. All this comes from Jorg, isn't he the guy who has a track record of being on the outside of Sun and trying to argue with me about what Sun was doing when I was a well known guy in the most important group at Sun, the kernel group. If so, I'd salt his stuff heavily. I think he means well but is a little out there. Though some people might say the same about me. --lm From lm at mcvoy.com Sat Sep 14 12:02:40 2019 From: lm at mcvoy.com (Larry McVoy) Date: Fri, 13 Sep 2019 19:02:40 -0700 Subject: [TUHS] earliest Unix roff In-Reply-To: References: <201909132024.x8DKObEP013266@darkstar.fourwinds.com> <463d5cc4-9bef-9ac3-a680-a5161d664dc1@aueb.gr> <20190913221345.GA16129@minnie.tuhs.org> Message-ID: <20190914020240.GO2046@mcvoy.com> > > slightest interest in scrapping Unix. Therefore, we transliterated > > the roff text formatter into PDP-11 assembler language, starting from > > the PDP-7 version that had been transliterated from McIlroy???s BCPL > > version on Multics, which had in turn been inspired by J. Saltzer???s > > runoff program on CTSS. As a *roff guy to the core, to this day, I'd love to see any docs on the Multics version and/or the CTSS version. Roff has some pretty sophisticated stuff (environments come to mind) that I think 99.9% of the CS world doesn't understand (sort of like my rant on SCCS, most people didn't look hard enough to get it. I'm not sure that I get roff environments to this day but I kinda do). I'd love to see the docs on that early stuff and see if Joe Ossanna added in his own magic or was he carrying forward earlier magic. --lm P.S. I love this list for this stuff, I'm an old retired guy that wishes he could have helped birth Unix. Hanging out with the people who were there is super fun. From wkt at tuhs.org Sat Sep 14 12:44:33 2019 From: wkt at tuhs.org (Warren Toomey) Date: Sat, 14 Sep 2019 12:44:33 +1000 Subject: [TUHS] earliest Unix roff In-Reply-To: <20190914020240.GO2046@mcvoy.com> References: <201909132024.x8DKObEP013266@darkstar.fourwinds.com> <463d5cc4-9bef-9ac3-a680-a5161d664dc1@aueb.gr> <20190913221345.GA16129@minnie.tuhs.org> <20190914020240.GO2046@mcvoy.com> Message-ID: <20190914024433.GA19193@minnie.tuhs.org> On Fri, Sep 13, 2019 at 07:02:40PM -0700, Larry McVoy wrote: > Roff has some pretty sophisticated stuff (environments come to mind) that > I think 99.9% of the CS world doesn't understand (sort of like my rant > on SCCS, most people didn't look hard enough to get it. I'm not sure > that I get roff environments to this day but I kinda do). > > I'd love to see the docs on that early stuff and see if Joe Ossanna > added in his own magic or was he carrying forward earlier magic. Here's a good page on the history: https://manpages.bsd.lv/history.html > P.S. I love this list for this stuff, I'm an old retired guy that > wishes he could have helped birth Unix. Hanging out with the people > who were there is super fun. Hell yeah to both! Cheers, Warren From imp at bsdimp.com Sat Sep 14 12:53:34 2019 From: imp at bsdimp.com (Warner Losh) Date: Fri, 13 Sep 2019 20:53:34 -0600 Subject: [TUHS] a book (was Re: PWB vs Unix/TS) In-Reply-To: References: Message-ID: On Fri, Sep 13, 2019 at 7:31 PM wrote: > There needs to be a book with stuff like this. There is no Unix history > book that I have ever seen with the depth of information in threads like > this and others on TUHS. It would be a huge project and hard to tell if > there would me more than just recognition and intrinsic rewards for the > effort -- but maybe that is enough. > I think it would be cool, but we need better data visualization. There's a lot of rich history here that people like me try to boil down to a few ovals and arrows, but the real answer is much more complicated. We need the equivalent to Mindard's analysis of Napoleon's march to Moscow and back to show how things like awk entered, and where, and different 'sub editions' and different lines of code maintained outside the overly simple narrative of V1 -> V2 ... -> V7 -> 32V -> chaos. :) > (As an example, I have spent hundreds if not thousands of hours > researching a small subset: Berkeley Unix history. Attempted to contact > hundreds of historical participants. Interviewed near 100 people; most > by email, but some in person or by phone -- even postal mail! Building a > massive collection of historical data. Read over 30 physical books > covering very small parts of the story. Watched many videos (and notes). > Getting documents scanned and sent to me. It is a very detailed effort > -- such as a single long chapter on the Virtual Vax/UNIX / London/Reiser > / Babaoglu story with 168 citations or the single chapters on the > official unofficial patchkits, lawsuit, etc. -- and there is nothing in > this field to compare it too. I have over 243 bibtex entries already and > 215 citations left to add to my .bib file. During that time, I have > published six other books, some written from scratch. Some have > suggested I use Kickstarter or similar as a financial incentive to > finish it off.) > > Since the Unix story is so huge, a first volume could be up through > System III, for example, but maybe that is too much. > > Anyone know of anyone writing a thorough Unix history book? > I'd be keen to write up what I've found. > Does it make sense to use a kickstarter? > > I may bring up in a different thread, but I am presenting about Unix > history at Dallas Ft. Worth UNIX Users Group soon. They are planning to > have two meetings (different months) dedicated to the history (50th > anniversary). > If they are large enough, I could be persuaded to reprise my EuroBSDcon talk at them, assuming people are happy with how it turns out.... Warner > Jeremy C. Reed > > p.s. Sorry to mention this, but time is running out: > > $ grep -i decease /home/reed/book/bsd-history/PEOPLE | wc -l > 17 > > pps. My other chapters: > > beginning.tex:\chapter{In the beginning ...} > > 2bsd.tex:\chapter{Second Berkeley Software Tape} > > 3bsd.tex:\chapter{Welcome to Virtual Vax/UNIX} > > 2bsd-part2.tex:\chapter{2BSD becomes an operating system} > > 4bsd.tex:\chapter{4BSD} > > 43bsd.tex:\chapter{4.3BSD -- The Internet Server} > > 2bsd-part3.tex:\chapter{The 16-bit 2BSD continues} > > 43bsd-part2.tex:\chapter{To open source BSD} > > commercial.tex:\chapter{Commercial Unixes using BSD} > > 44bsd.tex:\chapter{4.4BSD} > > bsdi.tex:\chapter{BSDI} > > 386bsd.tex:\chapter{386BSD Part 1} > > lawsuit.tex:\chapter{Lawsuit} > > patchkit.tex:\chapter{The official unofficial patchkits} > > netbsd.tex:\chapter{NetBSD} > > freebsd.tex:\chapter{FreeBSD} > > 386bsd-part3.tex:\chapter{386BSD Part 2} > > bsdi-part2.tex:\chapter{BSDI part 2} > > openbsd.tex:\chapter{OpenBSD} > > netbsd-part2.tex:\chapter{NetBSD -- Part 2} > > dragonfly.tex:\chapter{DragonFly BSD} > > 3bsd-license.tex:\chapter{3BSD Software Agreement (1979)} > > 4bsd-license.tex:\chapter{4BSD Software Agreement (1980)} > > > > ----------------------- > > echo Ohl zl obbx uggc://errqzrqvn.arg/obbxf/csfrafr/ | \ > tr "Onoqrsuvxzabcefghl" "Babdefhikmnoprstuy" > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wobblygong at gmail.com Sat Sep 14 16:13:28 2019 From: wobblygong at gmail.com (Wesley Parish) Date: Sat, 14 Sep 2019 18:13:28 +1200 Subject: [TUHS] My EuroBSDcon talk (preview for commentary) In-Reply-To: References: Message-ID: I had the pleasure to play on both a DEC Rainbow and an early Sony PC (both running MS DOS 2.x though the Rainbow also ran CP/M) in the early 90s. They could have been described as being only relatively "IBM clones", as their BIOS did not fully reimplement the IBM PC BIOS. That was the Phoenix BIOS's achievement. Consequently Microsoft's Xenix would have come in several different flavours, according to who the OEM was. I don't know how long this state of affairs went on for; I do know several computer books dating from the late 80s I looked at in the early 90s regarded this a standard, though regrettable, problem. Do we have any Microsoft Xenix guys on this list? Anyone who'd be able to fill in these gaps in our knowledge? Or does anyone know anyone formerly of Microsoft or the original Santa Cruz Operation who we could ask? Wesley Parish On 9/14/19, Clem Cole wrote: > > Slide 35 -- Not sure that is true. I thought Microsoft's Xenix ships > before Venix. Particularly since you made the comment about System III > The original 8086 Xenix was a pure V7 port, with a few additions Gordon > brought with him from Purdue (i.e. ghg hacks). > From dds at aueb.gr Sat Sep 14 17:35:22 2019 From: dds at aueb.gr (Diomidis Spinellis) Date: Sat, 14 Sep 2019 10:35:22 +0300 Subject: [TUHS] My EuroBSDcon talk (preview for commentary) In-Reply-To: References: <201909132024.x8DKObEP013266@darkstar.fourwinds.com> <463d5cc4-9bef-9ac3-a680-a5161d664dc1@aueb.gr> Message-ID: <88e1328b-f543-7c36-6a82-13159816b3ad@aueb.gr> Correct! I formatted the Third Edition manual with nroff rather than troff, but, as you write, it could have been roff. Only one man page file contains macro definitions: https://github.com/dspinellis/unix-history-repo/blob/Research-V3/man/manx/asmt.x#L9 and the man source files also contain the formatted output corresponding to that file: https://github.com/dspinellis/unix-history-repo/blob/Research-V3/man/manx/asmt.cat Furthermore, this file (and the others in the same directory — manx) does not appear in the original Third Edition manual. So most likely the man pages were formatted with roff, although nroff existed and was documented at the time. https://github.com/dspinellis/unix-history-repo/blob/Research-V3/man/man1/nroff.1 http://bitsavers.trailing-edge.com/pdf/att/unix/3rd_Edition/UNIX_Programmers_Manual_Third_Edition_Feb73.pdf#page=98 On 14-Sep-19 0:45, Clem Cole wrote: > Awesome -- great way to figure it out, although I'm not sure 3rd edition > was nroff, I think it might have been roff.  I think a smart test is to > check to see if those sources used a macro package or not.  If not macro > package, I think that tells us that the likely formatting program was roff. From imp at bsdimp.com Sun Sep 15 03:51:09 2019 From: imp at bsdimp.com (Warner Losh) Date: Sat, 14 Sep 2019 11:51:09 -0600 Subject: [TUHS] CB-UNIX tapes? Message-ID: I found the following in the archive: To: cbunix23 at yahoo.com Cc: Warren at plan9.bell-labs.com, Toomey at plan9.bell-labs.com, Subject: Re: cb/unix tapes From: Dennis Ritchie Date: Tue, 15 Jul 2003 21:23:37 -0400 They've arrived on my doorstep; thanks, Larry. 9-track drives seem thin on the ground, but we'll see. Dennis Does anybody know what became of those tapes? I know it was 13 years ago, but it's one of the few sitings of CB-Unix tapes I could find... Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Sun Sep 15 04:29:49 2019 From: imp at bsdimp.com (Warner Losh) Date: Sat, 14 Sep 2019 12:29:49 -0600 Subject: [TUHS] IBM Unix source licenses In-Reply-To: References: <20190912232909.GA15734@minnie.tuhs.org> Message-ID: On Fri, Sep 13, 2019, 2:30 AM SPC wrote: > > El vie., 13 sept. 2019 a las 1:29, Warren Toomey () > escribió: > >> Clem Cole writes: >> > >> > > FYI: the original S/1 port was done at Cleveland State with the >> Seventh >> > > Edition >> > > Very interesting. We got one Series/1 in our work involved in one > electronic speech project which sadly died soon. > > On the other hand... Was this other portability project succesfully > finished? The Jalics paper don't make it all clear. > And my perennial question: are the sources extant? Warnet Also available at: > >> >> https://zero.sci-hub.se/3252/016657c71a46a2d7110d87b4f720847e/jalics1983.pdf >> >> Warren >> > > Gracias | Regards - Saludos | Greetings | Freundliche Grüße | Salutations > -- > *Sergio Pedraja* > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Sun Sep 15 08:46:25 2019 From: clemc at ccc.com (Clem cole) Date: Sat, 14 Sep 2019 18:46:25 -0400 Subject: [TUHS] a book (was Re: PWB vs Unix/TS) In-Reply-To: References: Message-ID: Peter Salus’s book is pretty good and what he has actuate. Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. > On Sep 13, 2019, at 8:44 PM, reed at reedmedia.net wrote: > > There needs to be a book with stuff like this. There is no Unix history > book that I have ever seen with the depth of information in threads like > this and others on TUHS. It would be a huge project and hard to tell if > there would me more than just recognition and intrinsic rewards for the > effort -- but maybe that is enough. > > (As an example, I have spent hundreds if not thousands of hours > researching a small subset: Berkeley Unix history. Attempted to contact > hundreds of historical participants. Interviewed near 100 people; most > by email, but some in person or by phone -- even postal mail! Building a > massive collection of historical data. Read over 30 physical books > covering very small parts of the story. Watched many videos (and notes). > Getting documents scanned and sent to me. It is a very detailed effort > -- such as a single long chapter on the Virtual Vax/UNIX / London/Reiser > / Babaoglu story with 168 citations or the single chapters on the > official unofficial patchkits, lawsuit, etc. -- and there is nothing in > this field to compare it too. I have over 243 bibtex entries already and > 215 citations left to add to my .bib file. During that time, I have > published six other books, some written from scratch. Some have > suggested I use Kickstarter or similar as a financial incentive to > finish it off.) > > Since the Unix story is so huge, a first volume could be up through > System III, for example, but maybe that is too much. > > Anyone know of anyone writing a thorough Unix history book? > > Does it make sense to use a kickstarter? > > I may bring up in a different thread, but I am presenting about Unix > history at Dallas Ft. Worth UNIX Users Group soon. They are planning to > have two meetings (different months) dedicated to the history (50th > anniversary). > > Jeremy C. Reed > > p.s. Sorry to mention this, but time is running out: > > $ grep -i decease /home/reed/book/bsd-history/PEOPLE | wc -l > 17 > > pps. My other chapters: > > beginning.tex:\chapter{In the beginning ...} > > 2bsd.tex:\chapter{Second Berkeley Software Tape} > > 3bsd.tex:\chapter{Welcome to Virtual Vax/UNIX} > > 2bsd-part2.tex:\chapter{2BSD becomes an operating system} > > 4bsd.tex:\chapter{4BSD} > > 43bsd.tex:\chapter{4.3BSD -- The Internet Server} > > 2bsd-part3.tex:\chapter{The 16-bit 2BSD continues} > > 43bsd-part2.tex:\chapter{To open source BSD} > > commercial.tex:\chapter{Commercial Unixes using BSD} > > 44bsd.tex:\chapter{4.4BSD} > > bsdi.tex:\chapter{BSDI} > > 386bsd.tex:\chapter{386BSD Part 1} > > lawsuit.tex:\chapter{Lawsuit} > > patchkit.tex:\chapter{The official unofficial patchkits} > > netbsd.tex:\chapter{NetBSD} > > freebsd.tex:\chapter{FreeBSD} > > 386bsd-part3.tex:\chapter{386BSD Part 2} > > bsdi-part2.tex:\chapter{BSDI part 2} > > openbsd.tex:\chapter{OpenBSD} > > netbsd-part2.tex:\chapter{NetBSD -- Part 2} > > dragonfly.tex:\chapter{DragonFly BSD} > > 3bsd-license.tex:\chapter{3BSD Software Agreement (1979)} > > 4bsd-license.tex:\chapter{4BSD Software Agreement (1980)} > > > > ----------------------- > > echo Ohl zl obbx uggc://errqzrqvn.arg/obbxf/csfrafr/ | \ > tr "Onoqrsuvxzabcefghl" "Babdefhikmnoprstuy" From athornton at gmail.com Sun Sep 15 10:58:21 2019 From: athornton at gmail.com (Adam Thornton) Date: Sat, 14 Sep 2019 17:58:21 -0700 Subject: [TUHS] a book (was Re: PWB vs Unix/TS) In-Reply-To: References: Message-ID: I...have never been all that impressed with Salus's work. It's not _bad_ but it's also not terribly insightful. I'm not volunteering to do better, though. At least not until after I find out whose job it is to be the NOAO/NCOA archivist, shout and scream until that answer is at least "someone," and get people poking and prodding the first-generation LSST crowd for memoirs and interviews in that golden period after they retire and no longer have careers to worry about, and before they die. Maybe for the seventy-fifth anniversary. On Sat, Sep 14, 2019 at 3:47 PM Clem cole wrote: > Peter Salus’s book is pretty good and what he has actuate. > > Sent from my PDP-7 Running UNIX V0 expect things to be almost but not > quite. > > > On Sep 13, 2019, at 8:44 PM, reed at reedmedia.net wrote: > > > > There needs to be a book with stuff like this. There is no Unix history > > book that I have ever seen with the depth of information in threads like > > this and others on TUHS. It would be a huge project and hard to tell if > > there would me more than just recognition and intrinsic rewards for the > > effort -- but maybe that is enough. > > > > (As an example, I have spent hundreds if not thousands of hours > > researching a small subset: Berkeley Unix history. Attempted to contact > > hundreds of historical participants. Interviewed near 100 people; most > > by email, but some in person or by phone -- even postal mail! Building a > > massive collection of historical data. Read over 30 physical books > > covering very small parts of the story. Watched many videos (and notes). > > Getting documents scanned and sent to me. It is a very detailed effort > > -- such as a single long chapter on the Virtual Vax/UNIX / London/Reiser > > / Babaoglu story with 168 citations or the single chapters on the > > official unofficial patchkits, lawsuit, etc. -- and there is nothing in > > this field to compare it too. I have over 243 bibtex entries already and > > 215 citations left to add to my .bib file. During that time, I have > > published six other books, some written from scratch. Some have > > suggested I use Kickstarter or similar as a financial incentive to > > finish it off.) > > > > Since the Unix story is so huge, a first volume could be up through > > System III, for example, but maybe that is too much. > > > > Anyone know of anyone writing a thorough Unix history book? > > > > Does it make sense to use a kickstarter? > > > > I may bring up in a different thread, but I am presenting about Unix > > history at Dallas Ft. Worth UNIX Users Group soon. They are planning to > > have two meetings (different months) dedicated to the history (50th > > anniversary). > > > > Jeremy C. Reed > > > > p.s. Sorry to mention this, but time is running out: > > > > $ grep -i decease /home/reed/book/bsd-history/PEOPLE | wc -l > > 17 > > > > pps. My other chapters: > > > > beginning.tex:\chapter{In the beginning ...} > > > > 2bsd.tex:\chapter{Second Berkeley Software Tape} > > > > 3bsd.tex:\chapter{Welcome to Virtual Vax/UNIX} > > > > 2bsd-part2.tex:\chapter{2BSD becomes an operating system} > > > > 4bsd.tex:\chapter{4BSD} > > > > 43bsd.tex:\chapter{4.3BSD -- The Internet Server} > > > > 2bsd-part3.tex:\chapter{The 16-bit 2BSD continues} > > > > 43bsd-part2.tex:\chapter{To open source BSD} > > > > commercial.tex:\chapter{Commercial Unixes using BSD} > > > > 44bsd.tex:\chapter{4.4BSD} > > > > bsdi.tex:\chapter{BSDI} > > > > 386bsd.tex:\chapter{386BSD Part 1} > > > > lawsuit.tex:\chapter{Lawsuit} > > > > patchkit.tex:\chapter{The official unofficial patchkits} > > > > netbsd.tex:\chapter{NetBSD} > > > > freebsd.tex:\chapter{FreeBSD} > > > > 386bsd-part3.tex:\chapter{386BSD Part 2} > > > > bsdi-part2.tex:\chapter{BSDI part 2} > > > > openbsd.tex:\chapter{OpenBSD} > > > > netbsd-part2.tex:\chapter{NetBSD -- Part 2} > > > > dragonfly.tex:\chapter{DragonFly BSD} > > > > 3bsd-license.tex:\chapter{3BSD Software Agreement (1979)} > > > > 4bsd-license.tex:\chapter{4BSD Software Agreement (1980)} > > > > > > > > ----------------------- > > > > echo Ohl zl obbx uggc://errqzrqvn.arg/obbxf/csfrafr/ | \ > > tr "Onoqrsuvxzabcefghl" "Babdefhikmnoprstuy" > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon at fourwinds.com Sun Sep 15 12:18:37 2019 From: jon at fourwinds.com (Jon Steinhart) Date: Sat, 14 Sep 2019 19:18:37 -0700 Subject: [TUHS] a book (was Re: PWB vs Unix/TS) In-Reply-To: References: Message-ID: <201909150218.x8F2Iba3018530@darkstar.fourwinds.com> On Fri, Sep 13, 2019 at 7:31 PM wrote: > There needs to be a book with stuff like this. There is no Unix history > book that I have ever seen with the depth of information in threads like > this and others on TUHS. It would be a huge project and hard to tell if > there would me more than just recognition and intrinsic rewards for the > effort -- but maybe that is enough. So having just finished a book project and therefore having a bit of a clue as to what it would take, I'd be willing to take a stab at coordinating a project like this. But it's not clear to me what the audience should be. Many of the folks on this list are obsessive with details that matter to, well, only people on this list. To make a good book I think that it would have to trace the major paths, innovations, and people. In any case, this would be easy - just write whatever you want and wait for Clem to correct you and fill in the details :-) Jon From clemc at ccc.com Sun Sep 15 12:39:48 2019 From: clemc at ccc.com (Clem Cole) Date: Sat, 14 Sep 2019 22:39:48 -0400 Subject: [TUHS] a book (was Re: PWB vs Unix/TS) In-Reply-To: <201909150218.x8F2Iba3018530@darkstar.fourwinds.com> References: <201909150218.x8F2Iba3018530@darkstar.fourwinds.com> Message-ID: On Sat, Sep 14, 2019 at 10:19 PM Jon Steinhart wrote: > On Fri, Sep 13, 2019 at 7:31 PM wrote: > > > There needs to be a book with stuff like this. There is no Unix history > > book that I have ever seen with the depth of information in threads like > > this and others on TUHS. It would be a huge project and hard to tell if > > there would me more than just recognition and intrinsic rewards for the > > effort -- but maybe that is enough. > > So having just finished a book project and therefore having a bit of a clue > as to what it would take, I'd be willing to take a stab at coordinating a > project like this. But it's not clear to me what the audience should be. > Many of the folks on this list are obsessive with details that matter to, > well, only people on this list. To make a good book I think that it would > have to trace the major paths, innovations, and people. In any case, this > would be easy - just write whatever you want and wait for Clem to correct > you and fill in the details :-) > > Jon > With friends like Jon ... -- Sent from a handheld expect more typos than usual -------------- next part -------------- An HTML attachment was scrubbed... URL: From doug at cs.dartmouth.edu Sun Sep 15 12:45:17 2019 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Sat, 14 Sep 2019 22:45:17 -0400 Subject: [TUHS] earliest Unix roff Message-ID: <201909150245.x8F2jHIp093980@tahoe.cs.Dartmouth.EDU> > I'd love to see the docs on that early stuff and see if Joe Ossanna > added in his own magic or was he carrying forward earlier magic. Here are scans of non-unix roff in 1971: https://www.cs.dartmouth.edu/~doug/roff71/roff71 I also have 1969, but it's bedtime and that will have to wait. Relative numbers (+n), roman numerals, .ti, top and bottom margin settings, .po, running titles, tab settings, hyphenation and footnotes were not in Saltzer's runoff. Most other features were. Doug From doug at cs.dartmouth.edu Sun Sep 15 12:47:08 2019 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Sat, 14 Sep 2019 22:47:08 -0400 Subject: [TUHS] earliest Unix roff [correction] Message-ID: <201909150247.x8F2l8Vp094001@tahoe.cs.Dartmouth.EDU> The URL for roff71 scans is https://www.cs.dartmouth.edu/~doug/roff71/ From clemc at ccc.com Sun Sep 15 13:02:29 2019 From: clemc at ccc.com (Clem Cole) Date: Sat, 14 Sep 2019 23:02:29 -0400 Subject: [TUHS] earliest Unix roff [correction] In-Reply-To: <201909150247.x8F2l8Vp094001@tahoe.cs.Dartmouth.EDU> References: <201909150247.x8F2l8Vp094001@tahoe.cs.Dartmouth.EDU> Message-ID: Doug Thank you On Sat, Sep 14, 2019 at 10:47 PM Doug McIlroy wrote: > The URL for roff71 scans is https://www.cs.dartmouth.edu/~doug/roff71/ > -- Sent from a handheld expect more typos than usual -------------- next part -------------- An HTML attachment was scrubbed... URL: From ullbeking at andrewnesbit.org Sun Sep 15 12:56:54 2019 From: ullbeking at andrewnesbit.org (U'll Be King of the Stars) Date: Sun, 15 Sep 2019 03:56:54 +0100 Subject: [TUHS] earliest Unix roff In-Reply-To: <20190914024433.GA19193@minnie.tuhs.org> References: <201909132024.x8DKObEP013266@darkstar.fourwinds.com> <463d5cc4-9bef-9ac3-a680-a5161d664dc1@aueb.gr> <20190913221345.GA16129@minnie.tuhs.org> <20190914020240.GO2046@mcvoy.com> <20190914024433.GA19193@minnie.tuhs.org> Message-ID: <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org> On 14/09/2019 03:44, Warren Toomey wrote: > On Fri, Sep 13, 2019 at 07:02:40PM -0700, Larry McVoy wrote: >> Roff has some pretty sophisticated stuff (environments come to mind) that >> I think 99.9% of the CS world doesn't understand This thread about *roff echoes something that I have been thinking about recently. I've been wondering whether it is possible and worthwhile to use *roff for complex technical documentation. I've always loved the aesthetic that books produced using *roff have but there are other reasons too. As far as _markup_ is concerned we have DocBook for example. I am also looking into this. (Also, I understand it's not a typesetting system.) Getting back to *roff, does anybody know if there is a (hopefully rich) repository of macros, or any other resources, for my use case? (La)TeX has this but I'd like to try something else. What do people think? Kind regards, Andrew -- OpenPGP key: EB28 0338 28B7 19DA DAB0 B193 D21D 996E 883B E5B9 From athornton at gmail.com Sun Sep 15 13:24:46 2019 From: athornton at gmail.com (Adam Thornton) Date: Sat, 14 Sep 2019 20:24:46 -0700 Subject: [TUHS] a book (was Re: PWB vs Unix/TS) In-Reply-To: <201909150218.x8F2Iba3018530@darkstar.fourwinds.com> References: <201909150218.x8F2Iba3018530@darkstar.fourwinds.com> Message-ID: JonSteinhart said: > just write whatever you want and wait for Clem to correct you and fill in the details Thanks for giving away my deepest secret for being a contributor to Open Source projects. The trick is, you write _something_ that does what you need, no matter how horrid, and put it out there, and wait for the screams to roll in and then someone who knows what they're doing to implement it correctly. Works almost every time. Adam On Sat, Sep 14, 2019 at 7:19 PM Jon Steinhart wrote: > On Fri, Sep 13, 2019 at 7:31 PM wrote: > > > There needs to be a book with stuff like this. There is no Unix history > > book that I have ever seen with the depth of information in threads like > > this and others on TUHS. It would be a huge project and hard to tell if > > there would me more than just recognition and intrinsic rewards for the > > effort -- but maybe that is enough. > > So having just finished a book project and therefore having a bit of a clue > as to what it would take, I'd be willing to take a stab at coordinating a > project like this. But it's not clear to me what the audience should be. > Many of the folks on this list are obsessive with details that matter to, > well, only people on this list. To make a good book I think that it would > have to trace the major paths, innovations, and people. In any case, this > would be easy - just write whatever you want and wait for Clem to correct > you and fill in the details :-) > > Jon > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at eric.allman.name Sun Sep 15 13:30:38 2019 From: tuhs at eric.allman.name (Eric Allman) Date: Sat, 14 Sep 2019 20:30:38 -0700 Subject: [TUHS] a book (was Re: PWB vs Unix/TS) In-Reply-To: References: Message-ID: On 2019-09-14 17:58, Adam Thornton wrote: > I...have never been all that impressed with Salus's work. It's not _bad_ but it's also not terribly insightful. I think Peter's work was an amazing effort to collect and disseminate facts, and despite a few gaps (inevitable) he did a great job. But Peter's works were more collections of facts than attempts to interpret, contextualize, or otherwise put the facts into a larger narrative. Honest historians can disagree on the role of written histories. A pure "just the facts ma'am" history avoids context and interpretation but tends to be fairly dry. This was Peter's approach. But it's impossible to completely avoid bias because you have to pick and choose the facts you include. Contextualizing history inevitably leads to interpretation which leads to some amount of bias, but interesting or even gripping histories read like a novel that unfolds before you. I've believed for a long time that when the definitive history of Unix is written, Peter's books will be a major (albeit not "primary", in the technical sense) source material. I salute him for all his hard (and early) work. I hope that someone will step up to do this larger history (much of which happened after Peter's publication dates) before we all die off. And I have to say, It looks like Warner's research (with all the abundant help from this group) the last week or two is amazing. I've learned tons of stuff I didn't know, some of which didn't match my memory, e.g., about generations of *roff. As the author of the -me macro package, I'm probably one of the handful of people in the world who have ever used every feature in [nt]roff, many of which looked crazy until I needed them, when they suddenly seemed to be genius. I deeply regret that I never had an opportunity to meet Joe Ossanna. eric From lm at mcvoy.com Sun Sep 15 14:21:17 2019 From: lm at mcvoy.com (Larry McVoy) Date: Sat, 14 Sep 2019 21:21:17 -0700 Subject: [TUHS] a book (was Re: PWB vs Unix/TS) In-Reply-To: References: Message-ID: <20190915042117.GW2046@mcvoy.com> On Sat, Sep 14, 2019 at 08:30:38PM -0700, Eric Allman wrote: > I deeply > regret that I never had an opportunity to meet Joe Ossanna. As roff guy I couldn't agree more. From jon at fourwinds.com Sun Sep 15 15:17:21 2019 From: jon at fourwinds.com (Jon Steinhart) Date: Sat, 14 Sep 2019 22:17:21 -0700 Subject: [TUHS] a book (was Re: PWB vs Unix/TS) In-Reply-To: <20190915042117.GW2046@mcvoy.com> References: <20190915042117.GW2046@mcvoy.com> Message-ID: <201909150517.x8F5HLfa009023@darkstar.fourwinds.com> Larry McVoy writes: > On Sat, Sep 14, 2019 at 08:30:38PM -0700, Eric Allman wrote: > > I deeply > > regret that I never had an opportunity to meet Joe Ossanna. > > As roff guy I couldn't agree more. I feel worse. I probably did meet him but was a kid and didn't know he would be special. BTW, I still use troff for lots of stuff. I know that tex is more capable, but troff is burned into my dna. I started with roff when I wrote my first BTL technical memorandum and later moved to nroff. Never actually used the C/A/T at BTL but I remember the smell of the developer and pages hanging out to dry. I find the tex language a bit ugly, but that's just my taste. I have piles of crufty packages cobbled together around it, but they're not really fit for use by others. I like to write in troff because it allows me to think about what I want to say without worrying about how I want it to look until later. Probably the ugliest tool is the one that I used to convert my book from troff into office because my publisher wouldn't take troff. Converted everything into openoffice xml format. Extracted all of the diagrams and tables, ran them through separately, then through ps2pdf then pdf2svg, and then inkscape for cropping to generate svg images for all of the art since they're the only scalable image format understood by office. Way back in the 80s when scheduling was new I wrote tools that generated pert and gantt charts via pic. The power of little and languages and composability lives on! Jon From arnold at skeeve.com Sun Sep 15 16:54:12 2019 From: arnold at skeeve.com (arnold at skeeve.com) Date: Sun, 15 Sep 2019 00:54:12 -0600 Subject: [TUHS] earliest Unix roff In-Reply-To: <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org> References: <201909132024.x8DKObEP013266@darkstar.fourwinds.com> <463d5cc4-9bef-9ac3-a680-a5161d664dc1@aueb.gr> <20190913221345.GA16129@minnie.tuhs.org> <20190914020240.GO2046@mcvoy.com> <20190914024433.GA19193@minnie.tuhs.org> <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org> Message-ID: <201909150654.x8F6sChG021185@freefriends.org> "U'll Be King of the Stars" wrote: > On 14/09/2019 03:44, Warren Toomey wrote: > > On Fri, Sep 13, 2019 at 07:02:40PM -0700, Larry McVoy wrote: > >> Roff has some pretty sophisticated stuff (environments come to mind) that > >> I think 99.9% of the CS world doesn't understand > > This thread about *roff echoes something that I have been thinking about > recently. > > I've been wondering whether it is possible and worthwhile to use *roff > for complex technical documentation. I've always loved the aesthetic > that books produced using *roff have but there are other reasons too. > > As far as _markup_ is concerned we have DocBook for example. I am also > looking into this. (Also, I understand it's not a typesetting system.) Unless you use a WYSIWYG tool that generates DocBook, you should avoid it. Your fingers will kill you. I have written books in troff, DocBook and Texinfo. Texinfo is *by far* the superior markup language. Using Texinfo can generate DocBook which your publisher can turn into PDF. (I have done this, three times at least.) But working directly in DocBook just plain hurts. > Getting back to *roff, does anybody know if there is a (hopefully rich) > repository of macros, or any other resources, for my use case? (La)TeX > has this but I'd like to try something else. What do people think? The MM macros are the most capable of the standard sets that are out there, although possibly the MOM macros distributed with groff are even more so; I have not investigated fully. My own wish for the next genie in a lamp that I come across would be for a texinfo --> troff translator. Arnold From dave at horsfall.org Sun Sep 15 17:01:15 2019 From: dave at horsfall.org (Dave Horsfall) Date: Sun, 15 Sep 2019 17:01:15 +1000 (EST) Subject: [TUHS] earliest Unix roff In-Reply-To: <201909150654.x8F6sChG021185@freefriends.org> References: <201909132024.x8DKObEP013266@darkstar.fourwinds.com> <463d5cc4-9bef-9ac3-a680-a5161d664dc1@aueb.gr> <20190913221345.GA16129@minnie.tuhs.org> <20190914020240.GO2046@mcvoy.com> <20190914024433.GA19193@minnie.tuhs.org> <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org> <201909150654.x8F6sChG021185@freefriends.org> Message-ID: On Sun, 15 Sep 2019, arnold at skeeve.com wrote: > The MM macros are the most capable of the standard sets that are out > there, although possibly the MOM macros distributed with groff are even > more so; I have not investigated fully. For some reason I prefer the MS macros, probably because I learnt them first and I find it difficult to use MM. -- Dave From ullbeking at andrewnesbit.org Sun Sep 15 17:32:25 2019 From: ullbeking at andrewnesbit.org (U'll Be King of the Stars) Date: Sun, 15 Sep 2019 08:32:25 +0100 Subject: [TUHS] earliest Unix roff In-Reply-To: <201909150654.x8F6sChG021185@freefriends.org> References: <201909132024.x8DKObEP013266@darkstar.fourwinds.com> <463d5cc4-9bef-9ac3-a680-a5161d664dc1@aueb.gr> <20190913221345.GA16129@minnie.tuhs.org> <20190914020240.GO2046@mcvoy.com> <20190914024433.GA19193@minnie.tuhs.org> <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org> <201909150654.x8F6sChG021185@freefriends.org> Message-ID: <27f52737-3e3b-1198-7ed4-6b97a5f19938@andrewnesbit.org> On 15/09/2019 07:54, arnold at skeeve.com wrote: > "U'll Be King of the Stars" wrote: >> I've been wondering whether it is possible and worthwhile to use *roff >> for complex technical documentation. I've always loved the aesthetic >> that books produced using *roff have but there are other reasons too. >> >> As far as _markup_ is concerned we have DocBook for example. I am also >> looking into this. (Also, I understand it's not a typesetting system.) > > Unless you use a WYSIWYG tool that generates DocBook, you should avoid it. > Your fingers will kill you. Oh, I'm not looking for WYSIWIG or even really WYSIMIM. I'm well used to writing in structural markup and presentation markup languages, e.g., LaTeX (which I think is extremely complicated, and since I left the university environment I do not miss it). AS for authoring DocBook I was depending on GNU Emacs to do a lot of the heavy XML stuff for me. Wishful thinking perhaps. > I have written books in troff, DocBook > and Texinfo. Texinfo is *by far* the superior markup language. I've had a feeling that Texinfo has been getting brushed to the side. Are you suggesting that Info is a good as a rendered documentation format? Or just that Texinfo is good for proto-documents that are to be authored in a parseable and meaningful format? I've been a long-time GNU Emacs user so reading Info files is OK for me. But we've never had a _nice_ Info reader, which is why it didn't take off I think. A lot of people REALLY hate the Info UI. Moreover it was (is?) very difficult to generate good contents and index pages with the official tools that I used at the time. I started working on improving this about 20 years ago but back then it felt as though the GNU Info and GNU Emacs projects had other things on their minds. > Using Texinfo can generate DocBook which your publisher can turn into PDF. > (I have done this, three times at least.) But working directly in > DocBook just plain hurts. OK, so you are suggesting Texinfo as a prototypical markup language, not necessarily something that will end up as Info files? I have read the Texinfo documentation and I agree that it seemed like a rich markup language. >> Getting back to *roff, does anybody know if there is a (hopefully rich) >> repository of macros, or any other resources, for my use case? (La)TeX >> has this but I'd like to try something else. What do people think? > > The MM macros are the most capable of the standard sets that are > out there, although possibly the MOM macros distributed with groff > are even more so; I have not investigated fully. Thank you for the heads up. I never heard of MOM but MM is more familiar. *I haven't really looked at eqn beyond browsing docs and I'm not sure how much I should expect from it.* TeX is (still?) the king of mathematical expression typesetting. > My own wish for the next genie in a lamp that I come across would be > for a texinfo --> troff translator. Have you looked at Pandoc? I don't know if it will do this but it's worth checking out. Andrew -- OpenPGP key: EB28 0338 28B7 19DA DAB0 B193 D21D 996E 883B E5B9 From akosela at andykosela.com Sun Sep 15 17:43:16 2019 From: akosela at andykosela.com (Andy Kosela) Date: Sun, 15 Sep 2019 09:43:16 +0200 Subject: [TUHS] a book (was Re: PWB vs Unix/TS) In-Reply-To: References: Message-ID: On Saturday, September 14, 2019, wrote: > > There needs to be a book with stuff like this. The book would be great indeed, but what about a documentary with interviews with the greatest UNIX minds. I remember two very good documentaries about Linux from 2001 -- Revolution OS and The Code and I consider them a definite resource about history of Linux in the late 90s. A time capsule. Really fascinating stuff. Jason Scott's documentaries about BBS culture of the 80s and text adventure games phenomenon are also of very high quality. Imagine such documentary about UNIX of the 70s and 80s! --Andy From arnold at skeeve.com Sun Sep 15 17:46:45 2019 From: arnold at skeeve.com (arnold at skeeve.com) Date: Sun, 15 Sep 2019 01:46:45 -0600 Subject: [TUHS] earliest Unix roff In-Reply-To: <27f52737-3e3b-1198-7ed4-6b97a5f19938@andrewnesbit.org> References: <201909132024.x8DKObEP013266@darkstar.fourwinds.com> <463d5cc4-9bef-9ac3-a680-a5161d664dc1@aueb.gr> <20190913221345.GA16129@minnie.tuhs.org> <20190914020240.GO2046@mcvoy.com> <20190914024433.GA19193@minnie.tuhs.org> <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org> <201909150654.x8F6sChG021185@freefriends.org> <27f52737-3e3b-1198-7ed4-6b97a5f19938@andrewnesbit.org> Message-ID: <201909150746.x8F7kjsq023119@freefriends.org> Hi. "U'll Be King of the Stars" wrote: > AS for authoring DocBook I was depending on GNU Emacs to do a lot of the > heavy XML stuff for me. Wishful thinking perhaps. Possibly. I use gvim. :-) And, no, I won't start _that_ discussion. To each his own, live and let live. > > I have written books in troff, DocBook > > and Texinfo. Texinfo is *by far* the superior markup language. > > I've had a feeling that Texinfo has been getting brushed to the side. It is actively maintained and developed. > Are you suggesting that Info is a good as a rendered documentation > format? Or just that Texinfo is good for proto-documents that are to be > authored in a parseable and meaningful format? The latter. > Moreover it was (is?) very difficult to generate good contents and index > pages with the official tools that I used at the time. For _printed_ matter, the current texinfo does fine at table of contents. The upcoming version of texinfo (in prerelease now) has new indexing capabilities that bring it on par with what you see in commercial publishing: multilevel indexing, as well as "see" and "see also" entries. I agree that Info isn't lovely; I prefer to read the generated HTML from makeinfo, or the PDF from texi2pdf. > I have read the Texinfo documentation and I agree that it seemed like a > rich markup language. Much of the growth in the markup language has been at my urging over the years. :-) > *I haven't really looked at eqn beyond browsing docs and I'm not sure > how much I should expect from it.* eqn is the inspiration for math mode in TeX. That's very clear, and Knuth was also aware of tbl. > > My own wish for the next genie in a lamp that I come across would be > > for a texinfo --> troff translator. > > Have you looked at Pandoc? I don't know if it will do this but it's > worth checking out. Thanks for that pointer. I'll have to take a look at it. Arnold From doug at cs.dartmouth.edu Mon Sep 16 02:17:52 2019 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Sun, 15 Sep 2019 12:17:52 -0400 Subject: [TUHS] user-level v1 Message-ID: <201909151617.x8FGHqGu100607@tahoe.cs.Dartmouth.EDU> The TUHS archive does not include /usr/src for v1. Does it exist anywhere? doug From jon at fourwinds.com Mon Sep 16 02:17:56 2019 From: jon at fourwinds.com (Jon Steinhart) Date: Sun, 15 Sep 2019 09:17:56 -0700 Subject: [TUHS] earliest Unix roff In-Reply-To: References: <201909132024.x8DKObEP013266@darkstar.fourwinds.com> <463d5cc4-9bef-9ac3-a680-a5161d664dc1@aueb.gr> <20190913221345.GA16129@minnie.tuhs.org> <20190914020240.GO2046@mcvoy.com> <20190914024433.GA19193@minnie.tuhs.org> <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org> <201909150654.x8F6sChG021185@freefriends.org> Message-ID: <201909151617.x8FGHusM008290@darkstar.fourwinds.com> Dave Horsfall writes: > On Sun, 15 Sep 2019, arnold at skeeve.com wrote: > > > The MM macros are the most capable of the standard sets that are out > > there, although possibly the MOM macros distributed with groff are even > > more so; I have not investigated fully. > > For some reason I prefer the MS macros, probably because I learnt them > first and I find it difficult to use MM. > > -- Dave I am also a MS fan. Tektronix did their own version of MS that added a ton of really nice features. Would be nice if someone could share that since Tek is long gone and probably doesn't care. Jon From ron at ronnatalie.com Mon Sep 16 03:23:30 2019 From: ron at ronnatalie.com (Ronald Natalie) Date: Sun, 15 Sep 2019 13:23:30 -0400 Subject: [TUHS] earliest Unix roff In-Reply-To: <201909151617.x8FGHusM008290@darkstar.fourwinds.com> References: <201909132024.x8DKObEP013266@darkstar.fourwinds.com> <463d5cc4-9bef-9ac3-a680-a5161d664dc1@aueb.gr> <20190913221345.GA16129@minnie.tuhs.org> <20190914020240.GO2046@mcvoy.com> <20190914024433.GA19193@minnie.tuhs.org> <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org> <201909150654.x8F6sChG021185@freefriends.org> <201909151617.x8FGHusM008290@darkstar.fourwinds.com> Message-ID: ROFF is the simplest of the runoff programs but is utterly frozen. I started with the -ms macro package so I had fondness for it, but switched to -mm over time. I had done some work (after not being able to pry a version Dennis Mumaugh had written out of the agency) on putting classification marking and formatting in it. I had restyled it to make the output look like the standard IBM formatting when we were doing UNIX work under contract for IBM. At Hopkins, we had a small furor when Mike (Michael John) Muuss wrote his own macro package and installed it as tmac.jm (invoked by the -mjm option). This led to lots of jokes about renaming programs and options after various users. From clemc at ccc.com Mon Sep 16 05:27:10 2019 From: clemc at ccc.com (Clem Cole) Date: Sun, 15 Sep 2019 15:27:10 -0400 Subject: [TUHS] earliest Unix roff In-Reply-To: <20190914024433.GA19193@minnie.tuhs.org> References: <201909132024.x8DKObEP013266@darkstar.fourwinds.com> <463d5cc4-9bef-9ac3-a680-a5161d664dc1@aueb.gr> <20190913221345.GA16129@minnie.tuhs.org> <20190914020240.GO2046@mcvoy.com> <20190914024433.GA19193@minnie.tuhs.org> Message-ID: Warren, On Fri, Sep 13, 2019 at 10:44 PM Warren Toomey wrote: > > Here's a good page on the history: > https://manpages.bsd.lv/history.html Excellent - thanks for the pointer. This shows nroff before troff. FWIW: I guess I was miss informed, but I had been under the impression that was the other way around. i.e. nroff was done to be compliant with the new troff, replacing roff, although the suggestion here is that he wrote it add macros to roff. I'll note that either way, the dates are all possible of course because the U/L case ASR 37 was introduced 1968 so by the early 1970's they would have been around the labs. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon at fourwinds.com Mon Sep 16 05:31:53 2019 From: jon at fourwinds.com (Jon Steinhart) Date: Sun, 15 Sep 2019 12:31:53 -0700 Subject: [TUHS] earliest Unix roff In-Reply-To: References: <201909132024.x8DKObEP013266@darkstar.fourwinds.com> <463d5cc4-9bef-9ac3-a680-a5161d664dc1@aueb.gr> <20190913221345.GA16129@minnie.tuhs.org> <20190914020240.GO2046@mcvoy.com> <20190914024433.GA19193@minnie.tuhs.org> Message-ID: <201909151931.x8FJVrPH011881@darkstar.fourwinds.com> Clem Cole writes: > Excellent - thanks for the pointer. This shows nroff before troff. > FWIW: I guess I was miss informed, but I had been under the impression > that was the other way around. i.e. nroff was done to be compliant with > the new troff, replacing roff, although the suggestion here is that he > wrote it add macros to roff. I'll note that either way, the dates are all > possible of course because the U/L case ASR 37 was introduced 1968 so by > the early 1970's they would have been around the labs. Yes, we had ASR 37s, used one myself. Not only did the do upper and lower case, but they also did Greek and math characters, had bracket building characters, and so on. Biggest problem was line noise since these were mostly on dial-up. One could be having a nice day and all of a sudden a burst of line noise would trigger a shift-out and everything would be gibberish. From clemc at ccc.com Mon Sep 16 05:35:52 2019 From: clemc at ccc.com (Clem Cole) Date: Sun, 15 Sep 2019 15:35:52 -0400 Subject: [TUHS] earliest Unix roff In-Reply-To: <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org> References: <201909132024.x8DKObEP013266@darkstar.fourwinds.com> <463d5cc4-9bef-9ac3-a680-a5161d664dc1@aueb.gr> <20190913221345.GA16129@minnie.tuhs.org> <20190914020240.GO2046@mcvoy.com> <20190914024433.GA19193@minnie.tuhs.org> <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org> Message-ID: On Sat, Sep 14, 2019 at 11:03 PM U'll Be King of the Stars < ullbeking at andrewnesbit.org> wrote: > > I've been wondering whether it is possible and worthwhile to use *roff > for complex technical documentation. I've always loved the aesthetic > that books produced using *roff have but there are other reasons too. > Ditto. The books that used roff can look clean and within a series are usually consistent, but what I've like is that they are different. The Prentiss-Hall series and the ORA books both were produced using troff and different versions of ms, but the results are different. One of my complained with LaTex books is they all seem to look the same. > Getting back to *roff, does anybody know if there is a (hopefully rich) > repository of macros, or any other resources, for my use case? > I've never seen one. As far as I knew it, publishers sometimes seeded authors. ORA used the Masscomp/Tektronix derived version of ms (-mS) that Steve Talbot created (and Rick LeFaivre originally created from the original Lesk V7 set). Rich Steven's has his own additions to the version of ms that came with groff which I have also seen. -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Mon Sep 16 05:37:39 2019 From: clemc at ccc.com (Clem Cole) Date: Sun, 15 Sep 2019 15:37:39 -0400 Subject: [TUHS] earliest Unix roff In-Reply-To: <201909150654.x8F6sChG021185@freefriends.org> References: <201909132024.x8DKObEP013266@darkstar.fourwinds.com> <463d5cc4-9bef-9ac3-a680-a5161d664dc1@aueb.gr> <20190913221345.GA16129@minnie.tuhs.org> <20190914020240.GO2046@mcvoy.com> <20190914024433.GA19193@minnie.tuhs.org> <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org> <201909150654.x8F6sChG021185@freefriends.org> Message-ID: On Sun, Sep 15, 2019 at 2:55 AM wrote: > Texinfo is *by far* the superior markup language. > I'll take your work for it, but my complaint is it requires emacs to use as the pager on my screen. If you live in emacs, that makes sense; but most people, even in the GNU/Linux world, don't. -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Mon Sep 16 05:48:05 2019 From: clemc at ccc.com (Clem Cole) Date: Sun, 15 Sep 2019 15:48:05 -0400 Subject: [TUHS] earliest Unix roff In-Reply-To: References: <201909132024.x8DKObEP013266@darkstar.fourwinds.com> <463d5cc4-9bef-9ac3-a680-a5161d664dc1@aueb.gr> <20190913221345.GA16129@minnie.tuhs.org> <20190914020240.GO2046@mcvoy.com> <20190914024433.GA19193@minnie.tuhs.org> <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org> <201909150654.x8F6sChG021185@freefriends.org> Message-ID: I learn runoff from the IBM and the TOPS, then PUB then Scribe before I saw the nroff/troff family. I have fond memories of using Scribe (which was sort of the model for the LaTex macros when it got tied up in the legal entanglements of CMU). So UNIX was what I had and became adept at it. Like Larry, it's still my goto today and even prefer to Word for anything over a single page. On Sun, Sep 15, 2019 at 3:01 AM Dave Horsfall wrote: > For some reason I prefer the MS macros, probably because I learnt them > first and I find it difficult to use MM. > The order I learned them was -mm {PWB}, -ms {V7}, -man {V7}, -ms {Tek}, -me {UCB}, -mS {MSCP}, -man {UCB version}. I feel into -ms with a couple of macros from -mS (.Li/Le for lists which were similar to MM's) for big documents, and the UCB -man for really simple things. It becomes a 'less is more' sort of thing - -mm and too complicated and I was not writing BTL tech memos, and after I did not my thesis, I did not need Eric's work (which was perfect for a UCB thesis). -------------- next part -------------- An HTML attachment was scrubbed... URL: From wkt at tuhs.org Mon Sep 16 06:11:03 2019 From: wkt at tuhs.org (Warren Toomey) Date: Mon, 16 Sep 2019 06:11:03 +1000 Subject: [TUHS] user-level v1 In-Reply-To: <201909151617.x8FGHqGu100607@tahoe.cs.Dartmouth.EDU> References: <201909151617.x8FGHqGu100607@tahoe.cs.Dartmouth.EDU> Message-ID: <20190915201103.GA25340@minnie.tuhs.org> On Sun, Sep 15, 2019 at 12:17:52PM -0400, Doug McIlroy wrote: > The TUHS archive does not include /usr/src for v1. Does it > exist anywhere? We've not been able to find it, no :-( Cheers Doug, Warren From clemc at ccc.com Mon Sep 16 06:12:17 2019 From: clemc at ccc.com (Clem Cole) Date: Sun, 15 Sep 2019 16:12:17 -0400 Subject: [TUHS] a book (was Re: PWB vs Unix/TS) In-Reply-To: References: Message-ID: On Sun, Sep 15, 2019 at 12:16 AM Eric Allman wrote: > On 2019-09-14 17:58, Adam Thornton wrote: > > I...have never been all that impressed with Salus's work. It's not > _bad_ but it's also not terribly insightful. > I think Peter's work was an amazing effort to collect and disseminate > facts, and despite a few gaps (inevitable) he did a great job. But > Peter's works were more collections of facts than attempts to interpret, > contextualize, or otherwise put the facts into a larger narrative. +1 Amen, bro. For many of us that lived the time he covered, which was the first 25 years, it's awesome and frankly, I don't look for it for insights, as that was to me not what he was after doing. He was trying to create a narrative that documented what happened. Yes, he left things out, but pretty much go it right. > Honest historians can disagree on the role of written histories. A pure > "just the facts ma'am" history avoids context and interpretation but > tends to be fairly dry. This was Peter's approach. I agree. Moreover, as Jon points out, I'm not sure even if was made widely available, other than people like those on this list, I'm not sure it will be really that interesting. > But it's impossible to completely avoid bias because you have to pick and choose the facts you include. And this is the biggest issue. And I have observed (maybe I'm wrong - but it seems to me ...) that the people that I know today, that dislike Peter's work dislike that Linux is not huge part of it. Or more importantly that it was the emergence of the *Internet and UNIX that were enablers for Linux*. As Jon has suggested, it should not be Gnu/Linux but rather Internet/Linux. Contextualizing history inevitably leads to interpretation > which leads to some amount of bias, but interesting or even gripping > histories read like a novel that unfolds before you. *i.e.* Peter is not David McCullough and we don't seem to have David coming to us to write his next book. I've believed for a long time that when the definitive history of Unix > is written, Peter's books will be a major (albeit not "primary", in the > technical sense) source material. Absolutely. It needs to be the place where a historian starts. I salute him for all his hard (and early) work. I hope that someone will > step up to do this larger history (much of which happened after Peter's > publication dates) before we all die off. +1 A louder *amen*.... > And I have to say, It looks like Warner's research (with all the > abundant help from this group) the last week or two is amazing. I agree - as much as I offered some additions and corrections it is well done -- thank you, Warner. > .... I deeply regret that I never had an opportunity to meet Joe Ossanna. Indeed. -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Mon Sep 16 06:14:58 2019 From: clemc at ccc.com (Clem Cole) Date: Sun, 15 Sep 2019 16:14:58 -0400 Subject: [TUHS] a book (was Re: PWB vs Unix/TS) In-Reply-To: <201909150517.x8F5HLfa009023@darkstar.fourwinds.com> References: <20190915042117.GW2046@mcvoy.com> <201909150517.x8F5HLfa009023@darkstar.fourwinds.com> Message-ID: On Sun, Sep 15, 2019 at 1:18 AM Jon Steinhart wrote: > Way back in the 80s when scheduling was new I wrote tools that generated > pert and gantt charts via pic. > We did the same thing at Masscomp. Then Danny Klein wrote a very cool Mac program that spit out pic (before xfig existed). > > The power of little and languages and composability lives on! Right... -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon at fourwinds.com Mon Sep 16 06:21:00 2019 From: jon at fourwinds.com (Jon Steinhart) Date: Sun, 15 Sep 2019 13:21:00 -0700 Subject: [TUHS] a book (was Re: PWB vs Unix/TS) In-Reply-To: References: <20190915042117.GW2046@mcvoy.com> <201909150517.x8F5HLfa009023@darkstar.fourwinds.com> Message-ID: <201909152021.x8FKL0nM019888@darkstar.fourwinds.com> Clem Cole writes: > > On Sun, Sep 15, 2019 at 1:18 AM Jon Steinhart wrote: > > > Way back in the 80s when scheduling was new I wrote tools that generated > > pert and gantt charts via pic. > > > We did the same thing at Masscomp. > Then Danny Klein wrote a very cool Mac program that spit out pic (before > xfig existed). The big problem with xfig (and fig befoe that) is that it didn't utilize what to me is one of the most important features of pic which is invisible elements. When I do a complicated diagram, I start with an invisible box and hang the diagram on it. That way, if I run out of space or need to make other adjustments I can just change the size of that invisible box scaffold. Sure beats stuff done in absolute coordinates by (x)fig or even many other modern drawing programs where everything has to be manually moved around and scaled. Jon From ullbeking at andrewnesbit.org Mon Sep 16 06:49:37 2019 From: ullbeking at andrewnesbit.org (U'll Be King of the Stars) Date: Sun, 15 Sep 2019 21:49:37 +0100 Subject: [TUHS] earliest Unix roff In-Reply-To: References: <201909132024.x8DKObEP013266@darkstar.fourwinds.com> <463d5cc4-9bef-9ac3-a680-a5161d664dc1@aueb.gr> <20190913221345.GA16129@minnie.tuhs.org> <20190914020240.GO2046@mcvoy.com> <20190914024433.GA19193@minnie.tuhs.org> <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org> Message-ID: <069494b2-ec5b-91e7-8618-2d111e0e5aa2@andrewnesbit.org> On 15/09/2019 20:35, Clem Cole wrote: > > > On Sat, Sep 14, 2019 at 11:03 PM U'll Be King of the Stars > > wrote: > > > I've been wondering whether it is possible and worthwhile to use *roff > for complex technical documentation.  I've always loved the aesthetic > that books produced using *roff have but there are other reasons too. > > Ditto.  The books that used roff can look clean and within a series are > usually consistent, but what I've like is that they are different. Yes, they look clean but different to each other. I'm guessing that the reason might be that it is easier to exercise *roff's capabilities than it is to push LaTeX to get good results without spending a huge amount of time. > The Prentiss-Hall series and the ORA books both were produced using > troff and different versions of ms, but the results are different. I wonder if Prentice-Hall and O'Reilly & Associates might be willing to share their *roff macro sets in an open source way. > One of my complained with LaTex books is they all seem to look the same. Don't they ever?! It has gotten to the point that Computer Modern actually makes me feel *fatigued* when I encounter it when reading, say, a mathematics monograph. On the other hand it's the perfect typeface for résumés and CV's for computer scientists. Like a secret handshake. Perhaps the reason that the CM typeface is so common is that changing typefaces in LaTeX is complicated and difficult so authors leave it alone. At least this has been my experience. > Getting back to *roff, does anybody know if there is a (hopefully rich) > repository of macros, or any other resources, for my use case? > > I've never seen one.   As far as I knew it, publishers sometimes seeded > authors.  ORA used the Masscomp/Tektronix derived version of ms (-mS) > that Steve Talbot created (and Rick LeFaivre originally created from the > original Lesk V7 set).   Rich Steven's has his own additions to the > version of ms that came with groff which I have also seen. This is fascinating insider information, and it leads me full circle to several reasons why I want to try to use *roff in the first place: 1. Do you think there is any chance of obtaining these macro packages? Either from authors who haven't passed away, or from the publishing houses themselves? 2. I get the impression that writing a macro package or editing an existing is relatively straightforward. Would you agree? Or, at least, that it makes some kind of sense. I could never make head or tail of LaTeX's macro extensions. I certainly didn't want to spend my life trying to figure it out. I still remember the sinking feeling in my stomach when I realized that the five (or so) books that make up the de facto canon of LaTeX user documentation (published by Addison-Wesley) are thousands of pages in total. I did not want to engage with that. I have no particular intention to speak ill of LaTeX. Rather, it is my only point of reference for publishing-grade typesetting and unfortunately I don't have fond memories of it. Kind regards, Andrew -- OpenPGP key: EB28 0338 28B7 19DA DAB0 B193 D21D 996E 883B E5B9 From dave at horsfall.org Mon Sep 16 07:16:48 2019 From: dave at horsfall.org (Dave Horsfall) Date: Mon, 16 Sep 2019 07:16:48 +1000 (EST) Subject: [TUHS] earliest Unix roff In-Reply-To: References: <201909132024.x8DKObEP013266@darkstar.fourwinds.com> <463d5cc4-9bef-9ac3-a680-a5161d664dc1@aueb.gr> <20190913221345.GA16129@minnie.tuhs.org> <20190914020240.GO2046@mcvoy.com> <20190914024433.GA19193@minnie.tuhs.org> <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org> <201909150654.x8F6sChG021185@freefriends.org> Message-ID: On Sun, 15 Sep 2019, Clem Cole wrote: > The order I learned them was -mm {PWB}, -ms {V7}, -man {V7}, -ms {Tek}, > -me {UCB}, -mS {MSCP}, -man {UCB version}.   I feel into -ms with a > couple of macros from -mS (.Li/Le for lists which were similar to MM's) > for big documents, and the UCB -man for really simple things.   It > becomes a 'less is more' sort of thing - -mm and too complicated and I > was not writing BTL tech memos, and after I did not my thesis, I did not > need Eric's work (which was perfect for a UCB thesis). For me it was ROFF (V5), -man (V6), -ms (V6). These days I don't need markup any more; the most complicated things I write are letters using TextEdit on the Mac, and C/Perl/etc with VI :-) Actually on the odd occasion I need markup it's "groff -ms -Tps" on the FreeBSD box. -- Dave From dave at horsfall.org Mon Sep 16 07:28:08 2019 From: dave at horsfall.org (Dave Horsfall) Date: Mon, 16 Sep 2019 07:28:08 +1000 (EST) Subject: [TUHS] a book (was Re: PWB vs Unix/TS) In-Reply-To: References: Message-ID: On Sun, 15 Sep 2019, Clem Cole wrote: > And this is the biggest issue.  And I have observed (maybe I'm wrong - > but it seems to me ...) that the people that I know today, that dislike > Peter's work dislike that Linux is not huge part of it.   Or more > importantly that it was the emergence of the Internet and UNIX that were > enablers for Linux.   As Jon has suggested, it should not be Gnu/Linux > but rather Internet/Linux. Indeed, and not a few Linux users hate it being pointed out that Unix was first. If it was not for Unix, we would not have Linux (because you had to pay for Unix). And my pet theory is that if it was not for Unix, we would all be running some version of Windoze, and loving it... -- Dave From clemc at ccc.com Mon Sep 16 07:46:42 2019 From: clemc at ccc.com (Clem Cole) Date: Sun, 15 Sep 2019 17:46:42 -0400 Subject: [TUHS] My EuroBSDcon talk (preview for commentary) In-Reply-To: References: Message-ID: Funny the things you think about at 3 in the AM. There are two other things missing from Warner's timeline that I think are important. A little about the clones and also about the commercial efforts (which turns out to be related as one might expect). The first UNIX clone that I know about was a V6 version by Whitesmiths, called Idris, I want to say in 1977/78. I believe that Michel's Gien's Pascal clone that he talked about a year later started out as V6, but morphed to V7 before he was done (and then later morphed again to become Chorus in a C++ rewrote). Mike Malcolm's Thoth (which "Thucks" by the way, my wife threw out my tee-shirt years ago;-) was a pseudo V6 clone. I don't think he tried to recompile V6 code, like he would with his later QNX efforts (and he wrote it in B, not C), but the model was V6 and he had seen and/or run V6 at Waterloo. By the time of V7, the clones do start showing up. Minux which everyone agreed was original, as well as Mark William's Coherent, which in the end AT&T backed off. But as Dennis said at the time something to the effect, that it was not clear they had directly used AT&T sources to build it, as much as the authors clearly had *seen/had access to UNIX operating and used it to build Coherent, plus they probably had seen the UNIX sources* at some point (this was important later when AT&T would make 'Trade Secret' claims). Idris is interesting in that when Plauger built it, he did get in trouble at the UDel USENIX when he tried to 'hawk it' and basically was booed (how he did was as much of a problem as that fact that he did it). But by that point, there was another commercial UNIX available. What's interesting is that there was not an official V6 redistribution license like there was for V7; so I'm not 100% sure I know how it was done and I would love to enlightened. I know this much of the story. As I mentioned before the first commercial user of UNIX was Rand Corporation in LA. Al Arms of AT&T legal wrote the original $15K/CPU license for them. I don't know how many of those licenses were made available, but I've always been under the impression it was under 10. Like a lot of people at the time, this was when the 'glass tty' was just showing up in force and Rand updated/wrote a version of ed(1) called the rand(1) editor [IIRC, its still available as the 'grand editor' from Dave Yost]. Shortly thereafter, Peter Weiner and Heinz would create a company in Santa Monica called, Interactive Systems Corp (ISC) and they provided v6 and copy of the Rand editor for some commercial folks (FYI - ISC would later do the original 386/UNIX port for AT&T, IBM and Intel but that's a different story, and eventually Sun would buy them years later). In fact, one of the things the folks at ISC did at the beginning was that they had worked with Perkin-Elmer and created a version of PE's 'Fox' terminal with modified ROMs that ran part of the Rand Editor in it [the Fox has a Motorola 6800 processor in it. CMU had a lot of the standard ones because they were $750 in 1978 which was very inexpensive]. Anyway, what would eventually become the 68000 development team in Austin (Les Crudele, Nick Trudenick, Tom Grunner et al) used the ISC system and those modified Foxes as their development system. What I don't know is how that license worked. I think what happened was ISC was selling 'support.' Motorola (or one of their customers) got a commercial license from AT&T and then got a support license from ISC with their additions. But frankly, I don't know. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From doug at cs.dartmouth.edu Mon Sep 16 08:07:11 2019 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Sun, 15 Sep 2019 18:07:11 -0400 Subject: [TUHS] earliest Unix roff Message-ID: <201909152207.x8FM7BiA017274@tahoe.cs.Dartmouth.EDU> > Excellent - thanks for the pointer. This shows nroff before troff. > FWIW: I guess I was miss informed, but I had been under the impression > that was the other way around. i.e. nroff was done to be compliant with > the new troff, replacing roff, although the suggestion here is that he > wrote it add macros to roff. I'll note that either way, the dates are all > possible of course because the U/L case ASR 37 was introduced 1968 so by > the early 1970's they would have been around the labs. nroff was in v2; troff appeared in v4, which incidentally was typeset in troff. Because of Joe Ossanna's role in designing the model 37, we had 37's in the Labs and even in our homes right from the start of production. But when they went obsolete, they were a chore to get rid of. As Labs property, they had to be returned; and picking them up was nobody's priority. Andy Hall had one on his back porch for a year. Doug From dave at horsfall.org Mon Sep 16 08:09:03 2019 From: dave at horsfall.org (Dave Horsfall) Date: Mon, 16 Sep 2019 08:09:03 +1000 (EST) Subject: [TUHS] user-level v1 In-Reply-To: <20190915201103.GA25340@minnie.tuhs.org> References: <201909151617.x8FGHqGu100607@tahoe.cs.Dartmouth.EDU> <20190915201103.GA25340@minnie.tuhs.org> Message-ID: On Mon, 16 Sep 2019, Warren Toomey wrote: >> The TUHS archive does not include /usr/src for v1. Does it exist >> anywhere? > > We've not been able to find it, no :-( Speaking of which, I heard that the curses library was simply ripped out of VI and made stand-alone; a rumour goes that the best test suite for curses was the game "rogue" :-) I still play it from time to time, but cannot get rog-o-matic to compile on the Mac. -- Dave From clemc at ccc.com Mon Sep 16 09:15:51 2019 From: clemc at ccc.com (Clem cole) Date: Sun, 15 Sep 2019 19:15:51 -0400 Subject: [TUHS] user-level v1 In-Reply-To: References: <201909151617.x8FGHqGu100607@tahoe.cs.Dartmouth.EDU> <20190915201103.GA25340@minnie.tuhs.org> Message-ID: Yes, Ken Arnold did both Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. > On Sep 15, 2019, at 6:09 PM, Dave Horsfall wrote: > > On Mon, 16 Sep 2019, Warren Toomey wrote: > >>> The TUHS archive does not include /usr/src for v1. Does it exist anywhere? >> >> We've not been able to find it, no :-( > > Speaking of which, I heard that the curses library was simply ripped out of VI and made stand-alone; a rumour goes that the best test suite for curses was the game "rogue" :-) I still play it from time to time, but cannot get rog-o-matic to compile on the Mac. > > -- Dave From bakul at bitblocks.com Mon Sep 16 09:25:17 2019 From: bakul at bitblocks.com (Bakul Shah) Date: Sun, 15 Sep 2019 16:25:17 -0700 Subject: [TUHS] My EuroBSDcon talk (preview for commentary) In-Reply-To: Your message of "Sun, 15 Sep 2019 17:46:42 -0400." References: Message-ID: <20190915232524.9A5491570CE9@mail.bitblocks.com> On Sun, 15 Sep 2019 17:46:42 -0400 Clem Cole wrote: > > The first UNIX clone that I know about was a V6 version by Whitesmiths, > called Idris, I want to say in 1977/78. I believe that Michel's Gien's > Pascal clone that he talked about a year later started out as V6, but > morphed to V7 before he was done (and then later morphed again to become > Chorus in a C++ rewrote). Mike Malcolm's Thoth (which "Thucks" by the way, > my wife threw out my tee-shirt years ago;-) was a pseudo V6 clone. I Acc. to a paper[1] by Cheriton, Malcom and Melen did the original small run time executive called Thoth. Cheriton rewrote it to form the kernel of the system described in the Feb 1979 CACM article. It used memory mapping, swapping. etc. They also added a filesystem. Thoth could not have been a clone of v6. It used message passing. More RPC than pipes. And it had "teams", where a "team" is roughly the same as a Unix process (separate address space) and a Thoth "process" was a thread in that address space. root was "*" (instead of "/") and current dir was "@" (instead "."). A bigger difference was that it had *nodes* or files and any file can have sub nodes. There was no separation between files and directories. It was an interesting system and a lot of different things were tried in it. In 1980-81 timeframe AMD forked off a separate company called AMC to build microcomputers. They chose Thoth. I almost worked there but in the end decided I'd rather do unix and joined Fortune and soon after AMD came to its senses and shut AMC down. [1] https://cs.uwaterloo.ca/research/tr/1979/CS-79-19.pdf > As I mentioned before the first commercial user of UNIX was Rand > Corporation in LA. Al Arms of AT&T legal wrote the original $15K/CPU > license for them. I don't know how many of those licenses were made > available, but I've always been under the impression it was under 10. Like > a lot of people at the time, this was when the 'glass tty' was just showing > up in force and Rand updated/wrote a version of ed(1) called the rand(1) > editor [IIRC, its still available as the 'grand editor' from Dave Yost]. The Rand editor e had nothing in common with ed(1). e descended from NED, a 2D editor, invented by Ned Irons in 1967 and described in "A CRT editing system" CACM Jan 1972. The "Grand editor", derived from e19 is long gone. Even Dave gave up on it long ago. Though you can find a separate version on the 'Net, also derived from e19. e with its multiple windows was a joy to use on a 60 line Ann Arbor Ambassador terminal. I use acme because it too is a tiling editor like e. It has some goodies not in e but overall e was a better experience. http://www.bitsavers.org/pdf/rand/R-2176-ARPA_The_CRT_Text_Editor_NED_Dec77.pdf From clemc at ccc.com Mon Sep 16 09:27:57 2019 From: clemc at ccc.com (Clem cole) Date: Sun, 15 Sep 2019 19:27:57 -0400 Subject: [TUHS] a book (was Re: PWB vs Unix/TS) In-Reply-To: References: Message-ID: Actually the thing that some (maybe many) of the folks you mentioned seem to have the hardest time accepting the Linux is just the modern implementation of Unix. which i think is sad. I think Linux is a wonderful piece of work but the developers do need to recognize we’re it came. There is a famous line which I wish I knew who said that to paraphrase becomes: “In science we stand on the shoulders of the great people that came before us, but in computer science we try to step on their toes.” Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. > On Sep 15, 2019, at 5:28 PM, Dave Horsfall wrote: > >> On Sun, 15 Sep 2019, Clem Cole wrote: >> >> And this is the biggest issue. And I have observed (maybe I'm wrong - but it seems to me ...) that the people that I know today, that dislike Peter's work dislike that Linux is not huge part of it. Or more importantly that it was the emergence of the Internet and UNIX that were enablers for Linux. As Jon has suggested, it should not be Gnu/Linux but rather Internet/Linux. > > Indeed, and not a few Linux users hate it being pointed out that Unix was first. If it was not for Unix, we would not have Linux (because you had > to pay for Unix). > > And my pet theory is that if it was not for Unix, we would all be running > some version of Windoze, and loving it... > > -- Dave From clemc at ccc.com Mon Sep 16 09:35:06 2019 From: clemc at ccc.com (Clem cole) Date: Sun, 15 Sep 2019 19:35:06 -0400 Subject: [TUHS] My EuroBSDcon talk (preview for commentary) In-Reply-To: <20190915232524.9A5491570CE9@mail.bitblocks.com> References: <20190915232524.9A5491570CE9@mail.bitblocks.com> Message-ID: I’m very aware it was message passing. I’ve run it. I’ve spoken to mike about it. They definitely had seen v6. But as I said I’m not so sure it was a clone. Again they used B which was popular at Waterloo at the time. Thanks for the update on the relationship between Ned and rand’s e. I had thought they used Ed as part of it. I saw Dave earlier this summer btw and he said he still gets asked about it. Although he’s working a new hw architecture to fill his days. Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. > On Sep 15, 2019, at 7:25 PM, Bakul Shah wrote: > >> On Sun, 15 Sep 2019 17:46:42 -0400 Clem Cole wrote: >> >> The first UNIX clone that I know about was a V6 version by Whitesmiths, >> called Idris, I want to say in 1977/78. I believe that Michel's Gien's >> Pascal clone that he talked about a year later started out as V6, but >> morphed to V7 before he was done (and then later morphed again to become >> Chorus in a C++ rewrote). Mike Malcolm's Thoth (which "Thucks" by the way, >> my wife threw out my tee-shirt years ago;-) was a pseudo V6 clone. I > > Acc. to a paper[1] by Cheriton, Malcom and Melen did the > original small run time executive called Thoth. Cheriton > rewrote it to form the kernel of the system described in the > Feb 1979 CACM article. It used memory mapping, swapping. etc. > They also added a filesystem. > > Thoth could not have been a clone of v6. It used message > passing. More RPC than pipes. And it had "teams", where a > "team" is roughly the same as a Unix process (separate address > space) and a Thoth "process" was a thread in that address > space. root was "*" (instead of "/") and current dir was "@" > (instead "."). A bigger difference was that it had *nodes* or > files and any file can have sub nodes. There was no > separation between files and directories. > > It was an interesting system and a lot of different things > were tried in it. In 1980-81 timeframe AMD forked off a > separate company called AMC to build microcomputers. They > chose Thoth. I almost worked there but in the end decided I'd > rather do unix and joined Fortune and soon after AMD came to > its senses and shut AMC down. > > [1] https://cs.uwaterloo.ca/research/tr/1979/CS-79-19.pdf > >> As I mentioned before the first commercial user of UNIX was Rand >> Corporation in LA. Al Arms of AT&T legal wrote the original $15K/CPU >> license for them. I don't know how many of those licenses were made >> available, but I've always been under the impression it was under 10. Like >> a lot of people at the time, this was when the 'glass tty' was just showing >> up in force and Rand updated/wrote a version of ed(1) called the rand(1) >> editor [IIRC, its still available as the 'grand editor' from Dave Yost]. > > The Rand editor e had nothing in common with ed(1). e > descended from NED, a 2D editor, invented by Ned Irons in 1967 > and described in "A CRT editing system" CACM Jan 1972. > > The "Grand editor", derived from e19 is long gone. Even Dave > gave up on it long ago. Though you can find a separate > version on the 'Net, also derived from e19. e with its > multiple windows was a joy to use on a 60 line Ann Arbor > Ambassador terminal. I use acme because it too is a tiling > editor like e. It has some goodies not in e but overall e > was a better experience. > > http://www.bitsavers.org/pdf/rand/R-2176-ARPA_The_CRT_Text_Editor_NED_Dec77.pdf From rich.salz at gmail.com Mon Sep 16 09:45:01 2019 From: rich.salz at gmail.com (Richard Salz) Date: Sun, 15 Sep 2019 19:45:01 -0400 Subject: [TUHS] a book (was Re: PWB vs Unix/TS) In-Reply-To: References: Message-ID: > There is a famous line which I wish I knew who said that to paraphrase > becomes: “In science we stand on the shoulders of the great people that > came before us, but in computer science we try to step on their toes.” > Brian Reid's gloss on Isaac Newton: http://www.anvari.org/fortune/Miscellaneous_Collections/131870_in-computer-science-we-stand-on-each-others-feet-brian-k.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From pechter at gmail.com Mon Sep 16 11:31:28 2019 From: pechter at gmail.com (William Pechter) Date: Sun, 15 Sep 2019 21:31:28 -0400 Subject: [TUHS] My EuroBSDcon talk (preview for commentary) In-Reply-To: References: Message-ID: <71a17612-a62f-66a6-4799-9a3cc0cdd8c5@gmail.com> On 9/15/19 5:46 PM, Clem Cole wrote: > Funny the things you think about at 3 in the AM. > > Idris is interesting in that when Plauger built it, he did get in > trouble at the UDel USENIX when he tried to 'hawk it' and basically > was booed (how he did was as much of a problem as that fact that he > did it).  But by that point, there was another commercial UNIX > available.   What's interesting is that there was not an official V6 > redistribution license like there was for V7; so I'm not 100% sure I > know how it was done and I would love to enlightened. > Interesting... I was at Concurrent messing around with a couple of truckloads of 7350 boxes they were trashing.  They were still being built (or supported) by Concurrent in 87 or so (I think that's when the Masscomp merger happened)... They were an 8mhz 68000 running either Uniplus+ (Sys III) or Idris (IIRC) or MicroXelos System V (which I think is a rebadged Uniplus SysV renamed to match the Concurrent 3200 Xelos systems). They used them internal around '83 when they went to a Rand Editor and  some *Roff based formatting for their office automation.  The motto for the IT move to desktop Unix was "Paper Free in '83." Soon PC's and laser printers killed any hope of "paper free" as the staff spent way too much time chosing fonts for BS memos. Here's some info on the very slow 68k I ran a newsfeed on: http://www.1000bit.it/ad/bro/perkin/PerkinElmer7350.pdf > I know this much of the story. > > As I mentioned before the first commercial user of UNIX was Rand > Corporation in LA.  Al Arms of AT&T legal wrote the original $15K/CPU > license for them.   I don't know how many of those licenses were made > available, but I've always been under the impression it was under 10.  > Like a lot of people at the time, this was when the 'glass tty' was > just showing up in force and Rand updated/wrote a version of ed(1) > called the rand(1) editor [IIRC, its still available as the 'grand > editor' from Dave Yost]. > Perkin-Elmer had a port of the Rand Editor "E" which worked on both the block mode and text terminals and they were using this for their office automation stuff internal on the desktops until they went Windows and Microsoft around 86 or so. I rescued a bunch of the trash bound 7350's and set up a small Cnews relay around Monmouth and Ocean counties in NJ.  For a while I upgraded to an AT&T6300 with Xenix-86 on it which outran the 6 or 8 mhz 68k in the Perkin-Elmer box. Cheap RLL disks and higher speed serial ports were to obsolete everything below a 386 for the news feed so I upgraded it. One of the great things about the editor on the box was the Rand Editor version allowed block copy of column data -- which I could only do on my CP/M box under Wordstar. I kept the boxes around until a Trenton Computer Festival.  When I couldn't unload them in the 90-91 time frame I used the free dumpsters there to finish the destruction that Concurrent had planned. I wiped and reused the ton of Uniplus disks I had at the time as scratch floppies.  I wish I had a copy left for historical reasons.  I kept the full manual set until I had a full *BSD 4.2,4.3 set and a full SysV set so I dumped the Idris and SysIII stuff. My original degree was history and I never found an old computer or doc I didn't try to save. Bill -- Digital had it then. Don't you wish you could buy it now! pechter-at-gmail.com http://xkcd.com/705/ From imp at bsdimp.com Mon Sep 16 11:42:23 2019 From: imp at bsdimp.com (Warner Losh) Date: Mon, 16 Sep 2019 02:42:23 +0100 Subject: [TUHS] My EuroBSDcon talk (preview for commentary) In-Reply-To: <20190915232524.9A5491570CE9@mail.bitblocks.com> References: <20190915232524.9A5491570CE9@mail.bitblocks.com> Message-ID: On Mon, Sep 16, 2019, 12:25 AM Bakul Shah wrote: > On Sun, 15 Sep 2019 17:46:42 -0400 Clem Cole wrote: > > > > The first UNIX clone that I know about was a V6 version by Whitesmiths, > > called Idris, I want to say in 1977/78. I believe that Michel's Gien's > > Pascal clone that he talked about a year later started out as V6, but > > morphed to V7 before he was done (and then later morphed again to become > > Chorus in a C++ rewrote). Mike Malcolm's Thoth (which "Thucks" by the > way, > > my wife threw out my tee-shirt years ago;-) was a pseudo V6 clone. I > > Acc. to a paper[1] by Cheriton, Malcom and Melen did the > original small run time executive called Thoth. Cheriton > rewrote it to form the kernel of the system described in the > Feb 1979 CACM article. It used memory mapping, swapping. etc. > They also added a filesystem. > Cataloguing all the clones was out of scope for my talk... there are a huge number that are known, and many more that aren't... I likely could do a whole talk on just that... Warner Thoth could not have been a clone of v6. It used message > passing. More RPC than pipes. And it had "teams", where a > "team" is roughly the same as a Unix process (separate address > space) and a Thoth "process" was a thread in that address > space. root was "*" (instead of "/") and current dir was "@" > (instead "."). A bigger difference was that it had *nodes* or > files and any file can have sub nodes. There was no > separation between files and directories. > > It was an interesting system and a lot of different things > were tried in it. In 1980-81 timeframe AMD forked off a > separate company called AMC to build microcomputers. They > chose Thoth. I almost worked there but in the end decided I'd > rather do unix and joined Fortune and soon after AMD came to > its senses and shut AMC down. > > [1] https://cs.uwaterloo.ca/research/tr/1979/CS-79-19.pdf > > > As I mentioned before the first commercial user of UNIX was Rand > > Corporation in LA. Al Arms of AT&T legal wrote the original $15K/CPU > > license for them. I don't know how many of those licenses were made > > available, but I've always been under the impression it was under 10. > Like > > a lot of people at the time, this was when the 'glass tty' was just > showing > > up in force and Rand updated/wrote a version of ed(1) called the rand(1) > > editor [IIRC, its still available as the 'grand editor' from Dave Yost]. > > The Rand editor e had nothing in common with ed(1). e > descended from NED, a 2D editor, invented by Ned Irons in 1967 > and described in "A CRT editing system" CACM Jan 1972. > > The "Grand editor", derived from e19 is long gone. Even Dave > gave up on it long ago. Though you can find a separate > version on the 'Net, also derived from e19. e with its > multiple windows was a joy to use on a 60 line Ann Arbor > Ambassador terminal. I use acme because it too is a tiling > editor like e. It has some goodies not in e but overall e > was a better experience. > > > http://www.bitsavers.org/pdf/rand/R-2176-ARPA_The_CRT_Text_Editor_NED_Dec77.pdf > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Mon Sep 16 11:48:57 2019 From: clemc at ccc.com (Clem cole) Date: Sun, 15 Sep 2019 21:48:57 -0400 Subject: [TUHS] My EuroBSDcon talk (preview for commentary) In-Reply-To: <71a17612-a62f-66a6-4799-9a3cc0cdd8c5@gmail.com> References: <71a17612-a62f-66a6-4799-9a3cc0cdd8c5@gmail.com> Message-ID: Becareful. The Idris name was also used later by someone else for a 68000 system a few years after the Whitesmiths demise and they had stopped trying to sell there clone. I do not believe the two products were in any way related. Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. > On Sep 15, 2019, at 9:31 PM, William Pechter wrote: > > >> On 9/15/19 5:46 PM, Clem Cole wrote: >> Funny the things you think about at 3 in the AM. >> >> Idris is interesting in that when Plauger built it, he did get in trouble at the UDel USENIX when he tried to 'hawk it' and basically was booed (how he did was as much of a problem as that fact that he did it). But by that point, there was another commercial UNIX available. What's interesting is that there was not an official V6 redistribution license like there was for V7; so I'm not 100% sure I know how it was done and I would love to enlightened. >> > Interesting... I was at Concurrent messing around with a couple of truckloads of 7350 boxes they were trashing. They were still being built (or supported) by Concurrent in 87 or so (I think that's when the Masscomp merger happened)... They were an 8mhz 68000 running either Uniplus+ (Sys III) or Idris (IIRC) or MicroXelos System V (which I think is a rebadged Uniplus SysV renamed to match the Concurrent 3200 Xelos systems). > > They used them internal around '83 when they went to a Rand Editor and some *Roff based formatting for their office automation. The motto for the IT move to desktop Unix was "Paper Free in '83." > > Soon PC's and laser printers killed any hope of "paper free" as the staff spent way too much time chosing fonts for BS memos. > > Here's some info on the very slow 68k I ran a newsfeed on: http://www.1000bit.it/ad/bro/perkin/PerkinElmer7350.pdf > >> I know this much of the story. >> >> As I mentioned before the first commercial user of UNIX was Rand Corporation in LA. Al Arms of AT&T legal wrote the original $15K/CPU license for them. I don't know how many of those licenses were made available, but I've always been under the impression it was under 10. Like a lot of people at the time, this was when the 'glass tty' was just showing up in force and Rand updated/wrote a version of ed(1) called the rand(1) editor [IIRC, its still available as the 'grand editor' from Dave Yost]. >> > Perkin-Elmer had a port of the Rand Editor "E" which worked on both the block mode and text terminals and they were using this for their office automation stuff internal on the desktops until they went Windows and Microsoft around 86 or so. > > I rescued a bunch of the trash bound 7350's and set up a small Cnews relay around Monmouth and Ocean counties in NJ. For a while I upgraded to an AT&T6300 with Xenix-86 on it which outran the 6 or 8 mhz 68k in the Perkin-Elmer box. > > Cheap RLL disks and higher speed serial ports were to obsolete everything below a 386 for the news feed so I upgraded it. > > One of the great things about the editor on the box was the Rand Editor version allowed block copy of column data -- which I could only do on my CP/M box under Wordstar. > > I kept the boxes around until a Trenton Computer Festival. When I couldn't unload them in the 90-91 time frame I used the free dumpsters there to finish the destruction that Concurrent had planned. > > I wiped and reused the ton of Uniplus disks I had at the time as scratch floppies. I wish I had a copy left for historical reasons. I kept the full manual set until I had a full *BSD 4.2,4.3 set and a full SysV set so I dumped the Idris and SysIII stuff. > > My original degree was history and I never found an old computer or doc I didn't try to save. > > > Bill > > > > -- > Digital had it then. Don't you wish you could buy it now! > pechter-at-gmail.com http://xkcd.com/705/ > From clemc at ccc.com Mon Sep 16 11:52:33 2019 From: clemc at ccc.com (Clem cole) Date: Sun, 15 Sep 2019 21:52:33 -0400 Subject: [TUHS] My EuroBSDcon talk (preview for commentary) In-Reply-To: References: <20190915232524.9A5491570CE9@mail.bitblocks.com> Message-ID: <7F62BF6B-8FEA-4C43-9E35-05BDE9BF04EA@ccc.com> Fair enough. But the original v6 Whitesmiths Idris was important and should be part of your v6 slide. It establishes that some people were beginning to take a commercial version of Unix seriously even if AT&T was not allowed too. Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. > On Sep 15, 2019, at 9:42 PM, Warner Losh wrote: > > > >> On Mon, Sep 16, 2019, 12:25 AM Bakul Shah wrote: >> On Sun, 15 Sep 2019 17:46:42 -0400 Clem Cole wrote: >> > >> > The first UNIX clone that I know about was a V6 version by Whitesmiths, >> > called Idris, I want to say in 1977/78. I believe that Michel's Gien's >> > Pascal clone that he talked about a year later started out as V6, but >> > morphed to V7 before he was done (and then later morphed again to become >> > Chorus in a C++ rewrote). Mike Malcolm's Thoth (which "Thucks" by the way, >> > my wife threw out my tee-shirt years ago;-) was a pseudo V6 clone. I >> >> Acc. to a paper[1] by Cheriton, Malcom and Melen did the >> original small run time executive called Thoth. Cheriton >> rewrote it to form the kernel of the system described in the >> Feb 1979 CACM article. It used memory mapping, swapping. etc. >> They also added a filesystem. > > > > Cataloguing all the clones was out of scope for my talk... there are a huge number that are known, and many more that aren't... > > I likely could do a whole talk on just that... > > Warner > > >> Thoth could not have been a clone of v6. It used message >> passing. More RPC than pipes. And it had "teams", where a >> "team" is roughly the same as a Unix process (separate address >> space) and a Thoth "process" was a thread in that address >> space. root was "*" (instead of "/") and current dir was "@" >> (instead "."). A bigger difference was that it had *nodes* or >> files and any file can have sub nodes. There was no >> separation between files and directories. >> >> It was an interesting system and a lot of different things >> were tried in it. In 1980-81 timeframe AMD forked off a >> separate company called AMC to build microcomputers. They >> chose Thoth. I almost worked there but in the end decided I'd >> rather do unix and joined Fortune and soon after AMD came to >> its senses and shut AMC down. >> >> [1] https://cs.uwaterloo.ca/research/tr/1979/CS-79-19.pdf >> >> > As I mentioned before the first commercial user of UNIX was Rand >> > Corporation in LA. Al Arms of AT&T legal wrote the original $15K/CPU >> > license for them. I don't know how many of those licenses were made >> > available, but I've always been under the impression it was under 10. Like >> > a lot of people at the time, this was when the 'glass tty' was just showing >> > up in force and Rand updated/wrote a version of ed(1) called the rand(1) >> > editor [IIRC, its still available as the 'grand editor' from Dave Yost]. >> >> The Rand editor e had nothing in common with ed(1). e >> descended from NED, a 2D editor, invented by Ned Irons in 1967 >> and described in "A CRT editing system" CACM Jan 1972. >> >> The "Grand editor", derived from e19 is long gone. Even Dave >> gave up on it long ago. Though you can find a separate >> version on the 'Net, also derived from e19. e with its >> multiple windows was a joy to use on a 60 line Ann Arbor >> Ambassador terminal. I use acme because it too is a tiling >> editor like e. It has some goodies not in e but overall e >> was a better experience. >> >> http://www.bitsavers.org/pdf/rand/R-2176-ARPA_The_CRT_Text_Editor_NED_Dec77.pdf -------------- next part -------------- An HTML attachment was scrubbed... URL: From ggm at algebras.org Mon Sep 16 12:05:24 2019 From: ggm at algebras.org (George Michaelson) Date: Mon, 16 Sep 2019 12:05:24 +1000 Subject: [TUHS] My EuroBSDcon talk (preview for commentary) In-Reply-To: <7F62BF6B-8FEA-4C43-9E35-05BDE9BF04EA@ccc.com> References: <20190915232524.9A5491570CE9@mail.bitblocks.com> <7F62BF6B-8FEA-4C43-9E35-05BDE9BF04EA@ccc.com> Message-ID: The "block copy in an editor" thing is something which has intrigued me for years. poor old ed/ex/vi just couldn't do it, and for the life of me, I could not understand why this was "deprecated" by the people writing that family of editors. I seem to recall the various lightweight emacs which proceeded GNU had it, in some cases, and GNU had it. (Goslings emacs?) It was pretty much "you could do this with awk or sed" or "I wrote a SPITBAL program to do that" for most things. -As if columnar state, or a region of a screen was not something it even made sense to pick up into a buffer and put down somewhere else. Later on I theorised that the internal edit sequence log structure might make this quite hard to conceptualise and implement. But, I think its also possible the editor authors in question just didn't see a use value for this up-front. I think anyone who used WordStar or a half-duplex terminal saw a potential use for this almost immediately. And, the people using the early newspaper edit terminals almost certainly had a use for it because even at low-charcount they routinely seemed to work in newspaper columns, and so a "story" was about columnar paragraph structured data. Similarly the 'repeat this sequence of commands' thing which emacs had, as a "start keystroke" "end keystroke" and then @run that thing. Yes you could @run VI buffers, but you had to program them into a state, you couldn't tell the editor to "watch what you did, and re-do it on successive lines" I also suspect, that "do the thing you just did" and "block copy" were a bit low: people who did these kind of things were not clever. Clever people held the state of the lines in their head, and were mentally writing the ed/ex/vi or Teco sequences to change the letters in a line. Dumb people like me were thinking of editing as "cut the words out with rounded -end scissors and ask mummy for the clag gluepaste" Many fine hours were spent doing rote edits to fix post-formatted NROFF and RUNOFF text by me. Dumb, but doable. (runoff on the Dec-10 was good. I am glad I'd done it, it made the transition to nroff far easier. I didn't realize it was a cross-port from CTSS) -G On Mon, Sep 16, 2019 at 11:52 AM Clem cole wrote: > > Fair enough. But the original v6 Whitesmiths Idris was important and should be part of your v6 slide. It establishes that some people were beginning to take a commercial version of Unix seriously even if AT&T was not allowed too. > > Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. > > On Sep 15, 2019, at 9:42 PM, Warner Losh wrote: > > > > On Mon, Sep 16, 2019, 12:25 AM Bakul Shah wrote: >> >> On Sun, 15 Sep 2019 17:46:42 -0400 Clem Cole wrote: >> > >> > The first UNIX clone that I know about was a V6 version by Whitesmiths, >> > called Idris, I want to say in 1977/78. I believe that Michel's Gien's >> > Pascal clone that he talked about a year later started out as V6, but >> > morphed to V7 before he was done (and then later morphed again to become >> > Chorus in a C++ rewrote). Mike Malcolm's Thoth (which "Thucks" by the way, >> > my wife threw out my tee-shirt years ago;-) was a pseudo V6 clone. I >> >> Acc. to a paper[1] by Cheriton, Malcom and Melen did the >> original small run time executive called Thoth. Cheriton >> rewrote it to form the kernel of the system described in the >> Feb 1979 CACM article. It used memory mapping, swapping. etc. >> They also added a filesystem. > > > > Cataloguing all the clones was out of scope for my talk... there are a huge number that are known, and many more that aren't... > > I likely could do a whole talk on just that... > > Warner > > >> Thoth could not have been a clone of v6. It used message >> passing. More RPC than pipes. And it had "teams", where a >> "team" is roughly the same as a Unix process (separate address >> space) and a Thoth "process" was a thread in that address >> space. root was "*" (instead of "/") and current dir was "@" >> (instead "."). A bigger difference was that it had *nodes* or >> files and any file can have sub nodes. There was no >> separation between files and directories. >> >> It was an interesting system and a lot of different things >> were tried in it. In 1980-81 timeframe AMD forked off a >> separate company called AMC to build microcomputers. They >> chose Thoth. I almost worked there but in the end decided I'd >> rather do unix and joined Fortune and soon after AMD came to >> its senses and shut AMC down. >> >> [1] https://cs.uwaterloo.ca/research/tr/1979/CS-79-19.pdf >> >> > As I mentioned before the first commercial user of UNIX was Rand >> > Corporation in LA. Al Arms of AT&T legal wrote the original $15K/CPU >> > license for them. I don't know how many of those licenses were made >> > available, but I've always been under the impression it was under 10. Like >> > a lot of people at the time, this was when the 'glass tty' was just showing >> > up in force and Rand updated/wrote a version of ed(1) called the rand(1) >> > editor [IIRC, its still available as the 'grand editor' from Dave Yost]. >> >> The Rand editor e had nothing in common with ed(1). e >> descended from NED, a 2D editor, invented by Ned Irons in 1967 >> and described in "A CRT editing system" CACM Jan 1972. >> >> The "Grand editor", derived from e19 is long gone. Even Dave >> gave up on it long ago. Though you can find a separate >> version on the 'Net, also derived from e19. e with its >> multiple windows was a joy to use on a 60 line Ann Arbor >> Ambassador terminal. I use acme because it too is a tiling >> editor like e. It has some goodies not in e but overall e >> was a better experience. >> >> http://www.bitsavers.org/pdf/rand/R-2176-ARPA_The_CRT_Text_Editor_NED_Dec77.pdf From dave at horsfall.org Mon Sep 16 12:24:13 2019 From: dave at horsfall.org (Dave Horsfall) Date: Mon, 16 Sep 2019 12:24:13 +1000 (EST) Subject: [TUHS] My EuroBSDcon talk (preview for commentary) In-Reply-To: <71a17612-a62f-66a6-4799-9a3cc0cdd8c5@gmail.com> References: <71a17612-a62f-66a6-4799-9a3cc0cdd8c5@gmail.com> Message-ID: On Sun, 15 Sep 2019, William Pechter wrote: > They used them internal around '83 when they went to a Rand Editor and  > some *Roff based formatting for their office automation.  The motto for > the IT move to desktop Unix was "Paper Free in '83." > > Soon PC's and laser printers killed any hope of "paper free" as the > staff spent way too much time chosing fonts for BS memos. There was a saying many years ago, from someone whom I've long forgotten: "I'll believe in the paper-less office when I see the paper-less toilet". -- Dave From bakul at bitblocks.com Mon Sep 16 12:37:31 2019 From: bakul at bitblocks.com (Bakul Shah) Date: Sun, 15 Sep 2019 19:37:31 -0700 Subject: [TUHS] My EuroBSDcon talk (preview for commentary) In-Reply-To: Your message of "Mon, 16 Sep 2019 12:05:24 +1000." References: <20190915232524.9A5491570CE9@mail.bitblocks.com> <7F62BF6B-8FEA-4C43-9E35-05BDE9BF04EA@ccc.com> Message-ID: <20190916023738.F34E81570CE9@mail.bitblocks.com> On Mon, 16 Sep 2019 12:05:24 +1000 George Michaelson wrote: > The "block copy in an editor" thing is something which has intrigued > me for years. poor old ed/ex/vi just couldn't do it, and for the life > of me, I could not understand why this was "deprecated" by the people > writing that family of editors. I seem to recall the various > lightweight emacs which proceeded GNU had it, in some cases, and GNU > had it. (Goslings emacs?) I think this is because vi grew out of ex which grew out of ed, all of which were "line" editors, while the Rand Editor (and the original NED) assumed a quarter plane model. e had commands such as box (to draw a box), blank (or was it cut?) to wipe out all nonblank chars from a rectangle, replace, overlay (nonblank chars from the copy buffer overwrote data), underlay (nonblank chars from the copy buffer didn't overwrite nonblank chars) and so on. It even had justfy, fill and center commands. It was basically an editor for producing documents in monspaced fonts! From toby at telegraphics.com.au Mon Sep 16 12:31:48 2019 From: toby at telegraphics.com.au (Toby Thain) Date: Sun, 15 Sep 2019 22:31:48 -0400 Subject: [TUHS] My EuroBSDcon talk (preview for commentary) In-Reply-To: References: <71a17612-a62f-66a6-4799-9a3cc0cdd8c5@gmail.com> Message-ID: <7100ae29-9a00-d73d-b677-623341175d2b@telegraphics.com.au> On 2019-09-15 10:24 p.m., Dave Horsfall wrote: > On Sun, 15 Sep 2019, William Pechter wrote: > >> They used them internal around '83 when they went to a Rand Editor >> and  some *Roff based formatting for their office automation.  The >> motto for the IT move to desktop Unix was "Paper Free in '83." >> >> Soon PC's and laser printers killed any hope of "paper free" as the >> staff spent way too much time chosing fonts for BS memos. > > There was a saying many years ago, from someone whom I've long > forgotten: "I'll believe in the paper-less office when I see the > paper-less toilet". I am forced to observe that not only are paperless toilets quite common outside North America, they're also more hygienic... --Toby > > -- Dave From sauer at technologists.com Mon Sep 16 13:29:02 2019 From: sauer at technologists.com (Charles H. Sauer) Date: Sun, 15 Sep 2019 22:29:02 -0500 Subject: [TUHS] INed/Rand Editor/Ned [was Re: My EuroBSDcon talk (preview for commentary) In-Reply-To: <20190916023738.F34E81570CE9@mail.bitblocks.com> References: <20190915232524.9A5491570CE9@mail.bitblocks.com> <7F62BF6B-8FEA-4C43-9E35-05BDE9BF04EA@ccc.com> <20190916023738.F34E81570CE9@mail.bitblocks.com> Message-ID: The first Unix I used was PC/ix on an XT. I don’t know it even had vi, but it had INed, which I assume was the ISC evolution of NED & Rand Editor. (I think I first started using vi on Xenix on an AT before I got my own RT??) Anyway, I had been very productive with half-duplex editing on 3270 on CMS up to that point, and INed seemed very natural to me. Totally unrelated to Unix, when I came to IBM Austin from Yorktown, real 3270s were scarce/shared. I got a DisplayWriter with a 3270 card and emulator in my office. That was better than a real 3270 to my tastes, even with the 8” diskettes. 3270 emulation on PC was ok, but not as good as the real thing, certainly not as good as the DW emulation. > On Sep 15, 2019, at 9:37 PM, Bakul Shah wrote: > > On Mon, 16 Sep 2019 12:05:24 +1000 George Michaelson wrote: >> The "block copy in an editor" thing is something which has intrigued >> me for years. poor old ed/ex/vi just couldn't do it, and for the life >> of me, I could not understand why this was "deprecated" by the people >> writing that family of editors. I seem to recall the various >> lightweight emacs which proceeded GNU had it, in some cases, and GNU >> had it. (Goslings emacs?) > > I think this is because vi grew out of ex which grew out of > ed, all of which were "line" editors, while the Rand Editor > (and the original NED) assumed a quarter plane model. e had > commands such as box (to draw a box), blank (or was it cut?) > to wipe out all nonblank chars from a rectangle, replace, > overlay (nonblank chars from the copy buffer overwrote data), > underlay (nonblank chars from the copy buffer didn't overwrite > nonblank chars) and so on. It even had justfy, fill and center > commands. It was basically an editor for producing documents > in monspaced fonts! -- voice: +1.512.784.7526 e-mail: sauer at technologists.com fax: +1.512.346.5240 web: https://technologists.com/sauer/ Facebook/Google/Skype/Twitter: CharlesHSauer -------------- next part -------------- An HTML attachment was scrubbed... URL: From tytso at mit.edu Mon Sep 16 13:36:18 2019 From: tytso at mit.edu (Theodore Y. Ts'o) Date: Sun, 15 Sep 2019 23:36:18 -0400 Subject: [TUHS] My EuroBSDcon talk (preview for commentary) In-Reply-To: References: Message-ID: <20190916033618.GC22035@mit.edu> On Sun, Sep 15, 2019 at 05:46:42PM -0400, Clem Cole wrote: > By the time of V7, the clones do start showing up. Minux which everyone > agreed was original, as well as Mark William's Coherent, which in the end > AT&T backed off. But as Dennis said at the time something to the effect, > that it was not clear they had directly used AT&T sources to build it, as > much as the authors clearly had *seen/had access to UNIX operating and used > it to build Coherent, plus they probably had seen the UNIX sources* at some > point (this was important later when AT&T would make 'Trade Secret' claims). One really interesting anecdote about the "Trade Secret" claims, is that the MIT Unix license never had the "methods and concepts" clause in it. The MIT Administration/Lawyers considered in unconscionable the brains of MIT students might get encumbered by AT&T, and outright rejected that clause. Apparently MIT had a lot more clout (and probably alumni in high places at AT&T), so MIT was able to make the "no methods and concepts" clause stick. For each new version of Unix from AT&T, this issue would come up, and eventually, the Unix license would get included in Grant contracts where AT&T really, really wanted MIT to do research in some area, and apparently MIT had enough leverage to get successive Unix license updates, all without the infamous "methods and concepts" clause. At one point, even though MIT had the necessary licenses so it could be allowed to receive Ultrix or OSF/1 sources, AT&T's licensing division refused to confirm (or deny) whether or not MIT had a valid Unix source license, and so this caused problems for MIT to be able to get an official version of Ultrix or OSF/1 sources. No matter, MIT had even more alumni and connections which Digital, so when a tape was eventually installed in Project Athena's AFS cell, it was apparently an active source tree from some engineering directory, completely with core dumps and editor backup files.... So while I have looked at BSD 4.3 sources when I was a student systems programmer, I have it on good authority from people who were staff members on Project Athena at the time, that my brain was not owned by AT&T due to that nasty "methods and concepts" clause --- because the MIT Unix source license didn't have that nonsense. - Ted From arnold at skeeve.com Mon Sep 16 15:52:11 2019 From: arnold at skeeve.com (arnold at skeeve.com) Date: Sun, 15 Sep 2019 23:52:11 -0600 Subject: [TUHS] earliest Unix roff In-Reply-To: References: <201909132024.x8DKObEP013266@darkstar.fourwinds.com> <463d5cc4-9bef-9ac3-a680-a5161d664dc1@aueb.gr> <20190913221345.GA16129@minnie.tuhs.org> <20190914020240.GO2046@mcvoy.com> <20190914024433.GA19193@minnie.tuhs.org> <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org> <201909150654.x8F6sChG021185@freefriends.org> Message-ID: <201909160552.x8G5qBYK025195@freefriends.org> Clem Cole wrote: > On Sun, Sep 15, 2019 at 2:55 AM wrote: > > > Texinfo is *by far* the superior markup language. > > > I'll take your work for it, but my complaint is it requires emacs to use as > the pager on my screen. If you live in emacs, that makes sense; but most > people, even in the GNU/Linux world, don't. Not true at all. I don't use Emacs, never have, and likely never will. I use the standalone Info reader (named info) if I want to look at the Info output. But as I mentioned already, I usually look at the Texinfo documentation I'm working on via PDF or HTML. And gvim has very nice syntax highlighting for Texinfo input files. Arnold From arnold at skeeve.com Mon Sep 16 16:03:07 2019 From: arnold at skeeve.com (arnold at skeeve.com) Date: Mon, 16 Sep 2019 00:03:07 -0600 Subject: [TUHS] user-level v1 In-Reply-To: References: <201909151617.x8FGHqGu100607@tahoe.cs.Dartmouth.EDU> <20190915201103.GA25340@minnie.tuhs.org> Message-ID: <201909160603.x8G637QQ026140@freefriends.org> No, Bill Joy did vi. Ken Arnold did curses. The vi code did all it's stuff directly with the termlib library calls. (Use The Source, Luke!) Curses provided a library explicitly for screen oriented stuff that worked at a higher level. Mary Anne can and should tell the story of the progression of curses to System V and terminfo. Arnold Clem cole wrote: > Yes, Ken Arnold did both > > Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. > > > On Sep 15, 2019, at 6:09 PM, Dave Horsfall wrote: > > > > On Mon, 16 Sep 2019, Warren Toomey wrote: > > > >>> The TUHS archive does not include /usr/src for v1. Does it exist anywhere? > >> > >> We've not been able to find it, no :-( > > > > Speaking of which, I heard that the curses library was simply ripped out of VI and made stand-alone; a rumour goes that the best test suite for curses was the game "rogue" :-) I still play it from time to time, but cannot get rog-o-matic to compile on the Mac. > > > > -- Dave From arnold at skeeve.com Mon Sep 16 16:20:46 2019 From: arnold at skeeve.com (arnold at skeeve.com) Date: Mon, 16 Sep 2019 00:20:46 -0600 Subject: [TUHS] earliest Unix roff In-Reply-To: <069494b2-ec5b-91e7-8618-2d111e0e5aa2@andrewnesbit.org> References: <201909132024.x8DKObEP013266@darkstar.fourwinds.com> <463d5cc4-9bef-9ac3-a680-a5161d664dc1@aueb.gr> <20190913221345.GA16129@minnie.tuhs.org> <20190914020240.GO2046@mcvoy.com> <20190914024433.GA19193@minnie.tuhs.org> <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org> <069494b2-ec5b-91e7-8618-2d111e0e5aa2@andrewnesbit.org> Message-ID: <201909160620.x8G6KkJq026850@freefriends.org> "U'll Be King of the Stars" wrote: > This is fascinating insider information, and it leads me full circle to > several reasons why I want to try to use *roff in the first place: > > 1. Do you think there is any chance of obtaining these macro packages? > Either from authors who haven't passed away, or from the publishing > houses themselves? O'Reilly probably would. I can ask someone there, if there's serious interest here. They haven't used troff for book production for well over a decade. I'm not sure that Prentice-Hall had its own macros. Rather, the books from Bell Labs were all set on the same research Unix systems. > 2. I get the impression that writing a macro package or editing an > existing is relatively straightforward. Would you agree? Possibly straightforward, but very much like working in assembly language. The commands and escape sequences (in standard troff) are all very short, and thus cryptic, and the extra levels of backslashes needed inside macro bodies don't help. GNU troff has additional features that probably help a lot; my experience has been in grunging around in traditional packages. My two cents, Arnodl From dot at dotat.at Mon Sep 16 20:59:35 2019 From: dot at dotat.at (Tony Finch) Date: Mon, 16 Sep 2019 11:59:35 +0100 Subject: [TUHS] [SPAM] Re: SCCS In-Reply-To: References: <1568412078.22454.for-standards-violators@oclsc.org> Message-ID: Dave Horsfall wrote: > > I was thinking of an intermediate router (probably one that you never knew > about) corrupting the checksum-less UDP packet, recalculating the Ethernet > checksum, and your kernel happily accepting it; you now have an application > that fails for some unknown reason. > > Never seen it in practice, but I've heard of it happening. This paper has some examples: http://conferences.sigcomm.org/sigcomm/2000/conf/paper/sigcomm2000-9-1.pdf Tony. -- f.anthony.n.finch http://dotat.at/ Forth, Tyne, West Dogger: Westerly 3 to 5 veering northwesterly 4 to 6. Slight or moderate, becoming moderate or rough except in west Forth. Mainly fair. Good. From clemc at ccc.com Mon Sep 16 22:10:48 2019 From: clemc at ccc.com (Clem Cole) Date: Mon, 16 Sep 2019 08:10:48 -0400 Subject: [TUHS] earliest Unix roff In-Reply-To: <201909160552.x8G5qBYK025195@freefriends.org> References: <201909132024.x8DKObEP013266@darkstar.fourwinds.com> <463d5cc4-9bef-9ac3-a680-a5161d664dc1@aueb.gr> <20190913221345.GA16129@minnie.tuhs.org> <20190914020240.GO2046@mcvoy.com> <20190914024433.GA19193@minnie.tuhs.org> <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org> <201909150654.x8F6sChG021185@freefriends.org> <201909160552.x8G5qBYK025195@freefriends.org> Message-ID: On Mon, Sep 16, 2019 at 1:52 AM wrote: > I use the standalone Info reader (named info) if I want to look at the > Info output. > Fair enough, but be careful, while I admit I have not looked in a while, info(gnu) relies on emacs keybindings and a number of very emacs'ish things. Every time I have tried to deal with it, I have unprogram my fingers and reset them to emacs. If it would have used more(1) [or even less(1)] then I would not be as annoyed. Unix had fine tools [man(1), more(1), et al] and rms and friends felt the need to replace them with ITS-like programs. -------------- next part -------------- An HTML attachment was scrubbed... URL: From leah at vuxu.org Mon Sep 16 22:11:32 2019 From: leah at vuxu.org (Leah Neukirchen) Date: Mon, 16 Sep 2019 14:11:32 +0200 Subject: [TUHS] [SPAM] Re: SCCS In-Reply-To: <1568412078.22454.for-standards-violators@oclsc.org> (Norman Wilson's message of "Fri, 13 Sep 2019 18:01:14 -0400") References: <1568412078.22454.for-standards-violators@oclsc.org> Message-ID: <878sqosaob.fsf@vuxu.org> Norman Wilson writes: > Does IPv6 require a meaningful checksum, or just the > useless old ritual one? IPv6 has no checksum at all (for the header), and TCPv6 uses the same checksum algorithm. -- Leah Neukirchen https://leahneukirchen.org/ From clemc at ccc.com Mon Sep 16 22:13:55 2019 From: clemc at ccc.com (Clem Cole) Date: Mon, 16 Sep 2019 08:13:55 -0400 Subject: [TUHS] earliest Unix roff In-Reply-To: <201909160620.x8G6KkJq026850@freefriends.org> References: <201909132024.x8DKObEP013266@darkstar.fourwinds.com> <463d5cc4-9bef-9ac3-a680-a5161d664dc1@aueb.gr> <20190913221345.GA16129@minnie.tuhs.org> <20190914020240.GO2046@mcvoy.com> <20190914024433.GA19193@minnie.tuhs.org> <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org> <069494b2-ec5b-91e7-8618-2d111e0e5aa2@andrewnesbit.org> <201909160620.x8G6KkJq026850@freefriends.org> Message-ID: On Mon, Sep 16, 2019 at 2:21 AM wrote: > I'm not sure that Prentice-Hall had its own macros. Rather, the > books from Bell Labs were all set on the same research Unix systems. > That's might be true for bwk's and Pike's stuff, but not Rich Steven's or Comer's books. I know for fact that Rich had a set of macro's (based originally on -ms) and a set of integrated makefiles to build his texts. I was under the impression he passed them to a number of people, not just people like me. -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnold at skeeve.com Mon Sep 16 22:34:04 2019 From: arnold at skeeve.com (arnold at skeeve.com) Date: Mon, 16 Sep 2019 06:34:04 -0600 Subject: [TUHS] earliest Unix roff In-Reply-To: References: <201909132024.x8DKObEP013266@darkstar.fourwinds.com> <463d5cc4-9bef-9ac3-a680-a5161d664dc1@aueb.gr> <20190913221345.GA16129@minnie.tuhs.org> <20190914020240.GO2046@mcvoy.com> <20190914024433.GA19193@minnie.tuhs.org> <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org> <069494b2-ec5b-91e7-8618-2d111e0e5aa2@andrewnesbit.org> <201909160620.x8G6KkJq026850@freefriends.org> Message-ID: <201909161234.x8GCY40W005833@freefriends.org> Clem Cole wrote: > On Mon, Sep 16, 2019 at 2:21 AM wrote: > > > I'm not sure that Prentice-Hall had its own macros. Rather, the > > books from Bell Labs were all set on the same research Unix systems. > > > That's might be true for bwk's and Pike's stuff, but not Rich Steven's or > Comer's books. I know for fact that Rich had a set of macro's (based > originally on -ms) and a set of integrated makefiles to build his texts. I > was under the impression he passed them to a number of people, not just > people like me. Don't know, but you could try http://www.unixnetworkprogramming.com/contact.html for the Unix Network Programming book which was updated after Richard Stevens passed away. Arnold From lars at nocrew.org Mon Sep 16 22:26:31 2019 From: lars at nocrew.org (Lars Brinkhoff) Date: Mon, 16 Sep 2019 12:26:31 +0000 Subject: [TUHS] earliest Unix roff In-Reply-To: (Clem Cole's message of "Mon, 16 Sep 2019 08:10:48 -0400") References: <201909132024.x8DKObEP013266@darkstar.fourwinds.com> <463d5cc4-9bef-9ac3-a680-a5161d664dc1@aueb.gr> <20190913221345.GA16129@minnie.tuhs.org> <20190914020240.GO2046@mcvoy.com> <20190914024433.GA19193@minnie.tuhs.org> <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org> <201909150654.x8F6sChG021185@freefriends.org> <201909160552.x8G5qBYK025195@freefriends.org> Message-ID: <7wd0g0o2a0.fsf@junk.nocrew.org> Clem Cole wrote: > Unix had fine tools [man(1), more(1), et al] and rms and friends felt > the need to replace them with ITS-like programs. Emacs and Info are rather blatantly are not anywhere near the Unix philosophy. (Maybe they can be useful anyway.) However, please note that more(1) also was inspired by, almost copied from, ITS. Certainly the prompt --More-- is. From chet.ramey at case.edu Mon Sep 16 23:13:23 2019 From: chet.ramey at case.edu (Chet Ramey) Date: Mon, 16 Sep 2019 09:13:23 -0400 Subject: [TUHS] earliest Unix roff In-Reply-To: References: <201909132024.x8DKObEP013266@darkstar.fourwinds.com> <463d5cc4-9bef-9ac3-a680-a5161d664dc1@aueb.gr> <20190913221345.GA16129@minnie.tuhs.org> <20190914020240.GO2046@mcvoy.com> <20190914024433.GA19193@minnie.tuhs.org> <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org> <201909150654.x8F6sChG021185@freefriends.org> <201909160552.x8G5qBYK025195@freefriends.org> Message-ID: <95916cf9-9aa1-f949-0f37-0ae466e38aa2@case.edu> On 9/16/19 8:10 AM, Clem Cole wrote: > I use the standalone Info reader (named info) if I want to look at the > Info output.  > > Fair enough, but be careful, while I admit I have not looked in a while, > info(gnu) relies on emacs keybindings and a number of very emacs'ish things. > Every time I have tried to deal with it, I have unprogram my fingers and > reset them to emacs. > > If it would have used more(1) [or even less(1)] then I would not be as annoyed. It seems to me that the strength of info (the file format and program) is the navigation of a menu-driven hierarchical document containing what are essentially selectable links between sections. Something like more or less is poorly suited to take advantage of those features. You need a way to position the cursor with more flexibility than more gives you. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet at case.edu http://tiswww.cwru.edu/~chet/ From clemc at ccc.com Mon Sep 16 23:42:56 2019 From: clemc at ccc.com (Clem Cole) Date: Mon, 16 Sep 2019 09:42:56 -0400 Subject: [TUHS] earliest Unix roff In-Reply-To: <7wd0g0o2a0.fsf@junk.nocrew.org> References: <201909132024.x8DKObEP013266@darkstar.fourwinds.com> <463d5cc4-9bef-9ac3-a680-a5161d664dc1@aueb.gr> <20190913221345.GA16129@minnie.tuhs.org> <20190914020240.GO2046@mcvoy.com> <20190914024433.GA19193@minnie.tuhs.org> <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org> <201909150654.x8F6sChG021185@freefriends.org> <201909160552.x8G5qBYK025195@freefriends.org> <7wd0g0o2a0.fsf@junk.nocrew.org> Message-ID: On Mon, Sep 16, 2019 at 8:26 AM Lars Brinkhoff wrote: > However, please note that more(1) also was inspired by, almost copied > from, ITS. Certainly the prompt --More-- is. > Absolutely. A friend of mine/fellow UCB grad student, Eric Shienbrood, wrote it. He was a MIT undergrad. And Eric happily said it was modeled from ITS. And before, Eric wrote it, UNIX lacked anything like it. Which to me is fine, t*aking an idea from another system to add a new feature that is lacking.* What irks me is the blatant force-feeding of any system to the users, be it ITS, UNIX or Windows into another. It's ok to offer an alternative interface, but when the system has a mechanism, your tools need to be *socially compliant* with it, not try to make 'those users become like me.' Frankly, that is a pretty arrogant behavior. Yes, I know the argument is two fold. GNU is not UNIX and we wrote it (he who has the gold, gets to rule). BTW: If it makes you feel better, I've been fighting this attitude at a number of places, particularly Intel, for years. For instance, our dev tools folks wrote their own Installer 'because it was easier for them and they could use it everywhere'). That's a no-no. If you have Windows product, you must use Microsoft's installer, if you have a Mac, you use what Apple gives you, if you have VMS, you used the (wretched) setld, or in this case, for Linux its rpm/yum et al.; etc. But they had their own 'installer group' and it was easier for >>them<< than for the users. I think the rule of 'least astonishment' is what needs to be the high order bit when building tools for people. Again, offering emacs (or any other ITS tool) is fine, but when the new tool is installed on Windows/UNIX/Mac et.. it needs to behave itself with the rest of the system, particularly if there is already a mechanism in place to do a support function. Simply, I would not mind info(gnu) and texinfo(gnu) if there was a way to created man pages (or Windows / Mac help). But having a man page that basically says, see figure one is not cool. my 2 cents from a grumpy old guy.... Clem -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Tue Sep 17 00:40:09 2019 From: clemc at ccc.com (Clem Cole) Date: Mon, 16 Sep 2019 10:40:09 -0400 Subject: [TUHS] user-level v1 In-Reply-To: <201909160603.x8G637QQ026140@freefriends.org> References: <201909151617.x8FGHqGu100607@tahoe.cs.Dartmouth.EDU> <20190915201103.GA25340@minnie.tuhs.org> <201909160603.x8G637QQ026140@freefriends.org> Message-ID: On Mon, Sep 16, 2019 at 2:03 AM wrote: > No, Bill Joy did vi. Ken Arnold did curses. The vi code did all it's > stuff directly with the termlib library calls. > Both of those statements are true. But the other truth is that Ken took the code from vi to create the original curses library. You are correct, vi did not use curses as a library. It was hard coded. Similarly, termcap started out the same way. In fact, I know Cornell's fred and I thought a number of other early Unix screen editors like the original Rand e, were hardcoded for specific terminals (I personally put the code for the Lsi and Fox into Fred which was what we mostly had at CMU). As UCB got more and more different displays, the routines for terminal control also got pulled out and put into a separate library. Mary Ann eventually became the main person behind it and I'll let her add the details of who did what (I'm under the impression, wnj did the first cut of termlib and then Mary Ann overhauled it). -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Tue Sep 17 00:51:22 2019 From: lm at mcvoy.com (Larry McVoy) Date: Mon, 16 Sep 2019 07:51:22 -0700 Subject: [TUHS] earliest Unix roff In-Reply-To: References: <20190913221345.GA16129@minnie.tuhs.org> <20190914020240.GO2046@mcvoy.com> <20190914024433.GA19193@minnie.tuhs.org> <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org> <201909150654.x8F6sChG021185@freefriends.org> <201909160552.x8G5qBYK025195@freefriends.org> Message-ID: <20190916145122.GH2046@mcvoy.com> On Mon, Sep 16, 2019 at 08:10:48AM -0400, Clem Cole wrote: > On Mon, Sep 16, 2019 at 1:52 AM wrote: > > > I use the standalone Info reader (named info) if I want to look at the > > Info output. > > > Fair enough, but be careful, while I admit I have not looked in a while, > info(gnu) relies on emacs keybindings and a number of very emacs'ish things. > Every time I have tried to deal with it, I have unprogram my fingers and > reset them to emacs. > > If it would have used more(1) [or even less(1)] then I would not be as > annoyed. > Unix had fine tools [man(1), more(1), et al] and rms and friends felt the > need to replace them with ITS-like programs. I hate texinfo and friends. I get why it is better than man, but man was good enough, more than good enough, and the GNU project took everything it could find and destroyed the man pages. If you have something like perl that needs a zillion sub pages, info makes sense. For just a man page, info is horrible. From lm at mcvoy.com Tue Sep 17 00:52:12 2019 From: lm at mcvoy.com (Larry McVoy) Date: Mon, 16 Sep 2019 07:52:12 -0700 Subject: [TUHS] earliest Unix roff In-Reply-To: References: <20190913221345.GA16129@minnie.tuhs.org> <20190914020240.GO2046@mcvoy.com> <20190914024433.GA19193@minnie.tuhs.org> <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org> <069494b2-ec5b-91e7-8618-2d111e0e5aa2@andrewnesbit.org> <201909160620.x8G6KkJq026850@freefriends.org> Message-ID: <20190916145212.GI2046@mcvoy.com> On Mon, Sep 16, 2019 at 08:13:55AM -0400, Clem Cole wrote: > On Mon, Sep 16, 2019 at 2:21 AM wrote: > > > I'm not sure that Prentice-Hall had its own macros. Rather, the > > books from Bell Labs were all set on the same research Unix systems. > > > That's might be true for bwk's and Pike's stuff, but not Rich Steven's or > Comer's books. I know for fact that Rich had a set of macro's (based > originally on -ms) and a set of integrated makefiles to build his texts. I > was under the impression he passed them to a number of people, not just > people like me. I don't have them but he and I had many discussions about troff, tbl, pic, etc. We had a shared love for pic. From clemc at ccc.com Tue Sep 17 00:53:09 2019 From: clemc at ccc.com (Clem Cole) Date: Mon, 16 Sep 2019 10:53:09 -0400 Subject: [TUHS] INed/Rand Editor/Ned [was Re: My EuroBSDcon talk (preview for commentary) In-Reply-To: References: <20190915232524.9A5491570CE9@mail.bitblocks.com> <7F62BF6B-8FEA-4C43-9E35-05BDE9BF04EA@ccc.com> <20190916023738.F34E81570CE9@mail.bitblocks.com> Message-ID: On Sun, Sep 15, 2019 at 11:37 PM Charles H. Sauer wrote: > The first Unix I used was PC/ix on an XT. I don’t know it even had vi, but > it had INed, which I assume was the ISC evolution of NED & Rand Editor. > Yes, that is correct. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Tue Sep 17 00:54:28 2019 From: lm at mcvoy.com (Larry McVoy) Date: Mon, 16 Sep 2019 07:54:28 -0700 Subject: [TUHS] earliest Unix roff In-Reply-To: References: <20190914020240.GO2046@mcvoy.com> <20190914024433.GA19193@minnie.tuhs.org> <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org> <201909150654.x8F6sChG021185@freefriends.org> <201909160552.x8G5qBYK025195@freefriends.org> <7wd0g0o2a0.fsf@junk.nocrew.org> Message-ID: <20190916145428.GJ2046@mcvoy.com> Holy smokes, Clem, you are me and I am you. I couldn't agree more with this post, especially 'least astonishment'. On Mon, Sep 16, 2019 at 09:42:56AM -0400, Clem Cole wrote: > What irks me is the blatant force-feeding of any system to the users, be it > ITS, UNIX or Windows into another. It's ok to offer an alternative > interface, but when the system has a mechanism, your tools need to be *socially > compliant* with it, not try to make 'those users become like me.' > Frankly, that is a pretty arrogant behavior. Yes, I know the argument is > two fold. GNU is not UNIX and we wrote it (he who has the gold, gets to > rule). > > BTW: If it makes you feel better, I've been fighting this attitude at a > number of places, particularly Intel, for years. For instance, our dev > tools folks wrote their own Installer 'because it was easier for them and > they could use it everywhere'). That's a no-no. If you have Windows > product, you must use Microsoft's installer, if you have a Mac, you use > what Apple gives you, if you have VMS, you used the (wretched) setld, or in > this case, for Linux its rpm/yum et al.; etc. But they had their own > 'installer group' and it was easier for >>them<< than for the users. > > I think the rule of 'least astonishment' is what needs to be the high order > bit when building tools for people. Again, offering emacs (or any other > ITS tool) is fine, but when the new tool is installed on Windows/UNIX/Mac > et.. it needs to behave itself with the rest of the system, particularly if > there is already a mechanism in place to do a support function. > > Simply, I would not mind info(gnu) and texinfo(gnu) if there was a way to > created man pages (or Windows / Mac help). But having a man page that > basically says, see figure one > is not cool. > > my 2 cents from a grumpy old guy.... > Clem -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From clemc at ccc.com Tue Sep 17 00:57:43 2019 From: clemc at ccc.com (Clem Cole) Date: Mon, 16 Sep 2019 10:57:43 -0400 Subject: [TUHS] earliest Unix roff In-Reply-To: <20190916145122.GH2046@mcvoy.com> References: <20190913221345.GA16129@minnie.tuhs.org> <20190914020240.GO2046@mcvoy.com> <20190914024433.GA19193@minnie.tuhs.org> <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org> <201909150654.x8F6sChG021185@freefriends.org> <201909160552.x8G5qBYK025195@freefriends.org> <20190916145122.GH2046@mcvoy.com> Message-ID: On Mon, Sep 16, 2019 at 10:51 AM Larry McVoy wrote: > I hate texinfo and friends. I get why it is better than man, but man was > good enough, more than good enough, and the GNU project took everything > it could find and destroyed the man pages. > Amen, bro. As I said, it was not 'social compliant' which was really a not very nice thing to do. It's arrogant to say in effect "your way is wrong, I'm going to try to kill it off." > > If you have something like perl that needs a zillion sub pages, info > makes sense. For just a man page, info is horrible. I'm not even sure, I like that, to be honest. I'm 'old school' enough to rather use a book from ORA or the like. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rich.salz at gmail.com Tue Sep 17 01:14:25 2019 From: rich.salz at gmail.com (Richard Salz) Date: Mon, 16 Sep 2019 11:14:25 -0400 Subject: [TUHS] earliest Unix roff In-Reply-To: References: <20190913221345.GA16129@minnie.tuhs.org> <20190914020240.GO2046@mcvoy.com> <20190914024433.GA19193@minnie.tuhs.org> <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org> <201909150654.x8F6sChG021185@freefriends.org> <201909160552.x8G5qBYK025195@freefriends.org> <20190916145122.GH2046@mcvoy.com> Message-ID: Is it any surprise that the early GNU effort was really trying to recreate ITS? Can you really blame them? I'm grateful that they made `info` be a standalone program. Putting the concept of "cursor position" into the existing pagers (more/less/etc) and doing jump/xref/back would be more than a stretch, IMO. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron at ronnatalie.com Tue Sep 17 01:48:34 2019 From: ron at ronnatalie.com (Ronald Natalie) Date: Mon, 16 Sep 2019 11:48:34 -0400 Subject: [TUHS] earliest Unix roff In-Reply-To: References: <20190913221345.GA16129@minnie.tuhs.org> <20190914020240.GO2046@mcvoy.com> <20190914024433.GA19193@minnie.tuhs.org> <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org> <201909150654.x8F6sChG021185@freefriends.org> <201909160552.x8G5qBYK025195@freefriends.org> <20190916145122.GH2046@mcvoy.com> Message-ID: > On Sep 16, 2019, at 11:14 AM, Richard Salz wrote: > > Is it any surprise that the early GNU effort was really trying to recreate ITS? Can you really blame them? I'm grateful that they made `info` be a standalone program. Putting the concept of "cursor position" into the existing pagers (more/less/etc) and doing jump/xref/back would be more than a stretch, IMO. > Having been an early UNIX Emacs adoptee (I never really learned VI, if there was no emacs, I just used ed. A tendency that my employees always found amusing), I could never tolerate INFO in any of its forms (either ITS or on UNIX). It was far too cumbersome for the features it claimed to add to the mix. As for formatters, my biggest gripe with many of them is that I should not be able to tell what the formatter is by looking at the output. This is where Tex fails. It’s ugly style always seems to telegraph through. The only thing that is worse is those odd little bumps on the top of pic-framed tbl output. From paul.winalski at gmail.com Tue Sep 17 02:09:35 2019 From: paul.winalski at gmail.com (Paul Winalski) Date: Mon, 16 Sep 2019 12:09:35 -0400 Subject: [TUHS] earliest Unix roff In-Reply-To: References: <201909132024.x8DKObEP013266@darkstar.fourwinds.com> <463d5cc4-9bef-9ac3-a680-a5161d664dc1@aueb.gr> <20190913221345.GA16129@minnie.tuhs.org> <20190914020240.GO2046@mcvoy.com> <20190914024433.GA19193@minnie.tuhs.org> <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org> <201909150654.x8F6sChG021185@freefriends.org> <201909160552.x8G5qBYK025195@freefriends.org> <7wd0g0o2a0.fsf@junk.nocrew.org> Message-ID: On 9/16/19, Clem Cole wrote: > On Mon, Sep 16, 2019 at 8:26 AM Lars Brinkhoff wrote: > > What irks me is the blatant force-feeding of any system to the users, be it > ITS, UNIX or Windows into another. It's ok to offer an alternative > interface, but when the system has a mechanism, your tools need to be > *socially > compliant* with it, not try to make 'those users become like me.' > Frankly, that is a pretty arrogant behavior. Yes, I know the argument is > two fold. GNU is not UNIX and we wrote it (he who has the gold, gets to > rule). Amen to that! As the old saying goes, "when in Rome, do as the Romans do". On UNIX, tools are expected to send output to stdout. On Windows, users expect text selection and ^C/^V copy-and-paste to work. On VMS, you use the CLI interface to parse the command line. And so on. The principle of least astonishment should always be foremost in user interaction design. > BTW: If it makes you feel better, I've been fighting this attitude at a > number of places, particularly Intel, for years. For instance, our dev > tools folks wrote their own Installer 'because it was easier for them and > they could use it everywhere'). That's a no-no. If you have Windows > product, you must use Microsoft's installer, if you have a Mac, you use > what Apple gives you, if you have VMS, you used the (wretched) setld, or in > this case, for Linux its rpm/yum et al.; etc. But they had their own > 'installer group' and it was easier for >>them<< than for the users. I used to work in that organization. The installer situation is one of the worst cases of not-invented-here syndrome that I've ever seen. Or maybe it was just empire building by some ambitious manager. The "it's easier for us and we can use it everywhere" argument is pure BS. Any savings that they got from having the a common code base for the installer was wiped out by all the extra development effort needed to track the release-to-release changes that the various platforms made to their software deployment setup. Their installer was always a step or two behind the curve, late in supporting new platform features, and full of subtle bugs and mis-implemented edge conditions. It wasn't really "easier for them" in the long run after all. It was a maintenance nightmare. -Paul W. From lm at mcvoy.com Tue Sep 17 02:10:40 2019 From: lm at mcvoy.com (Larry McVoy) Date: Mon, 16 Sep 2019 09:10:40 -0700 Subject: [TUHS] earliest Unix roff In-Reply-To: References: <20190914020240.GO2046@mcvoy.com> <20190914024433.GA19193@minnie.tuhs.org> <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org> <201909150654.x8F6sChG021185@freefriends.org> <201909160552.x8G5qBYK025195@freefriends.org> <20190916145122.GH2046@mcvoy.com> Message-ID: <20190916161040.GM2046@mcvoy.com> On Mon, Sep 16, 2019 at 11:14:25AM -0400, Richard Salz wrote: > Is it any surprise that the early GNU effort was really trying to recreate > ITS? Can you really blame them? I'm grateful that they made `info` be a > standalone program. Putting the concept of "cursor position" into the > existing pagers (more/less/etc) and doing jump/xref/back would be more than > a stretch, IMO. It's what Clem said. You should acclimate yourself to your environment. Pushing info into man environment is a lot like being an immigrant and wanting to bring your laws into your new homeland. That isn't a thing and shouldn't be a thing. Doesn't matter that people think ITS is better, they are in Unix. If you think ITS is better, go live there. When in Rome.... From jon at fourwinds.com Tue Sep 17 02:16:03 2019 From: jon at fourwinds.com (Jon Steinhart) Date: Mon, 16 Sep 2019 09:16:03 -0700 Subject: [TUHS] earliest Unix roff In-Reply-To: <20190916161040.GM2046@mcvoy.com> References: <20190914020240.GO2046@mcvoy.com> <20190914024433.GA19193@minnie.tuhs.org> <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org> <201909150654.x8F6sChG021185@freefriends.org> <201909160552.x8G5qBYK025195@freefriends.org> <20190916145122.GH2046@mcvoy.com> <20190916161040.GM2046@mcvoy.com> Message-ID: <201909161616.x8GGG4Fb020760@darkstar.fourwinds.com> Larry McVoy writes: > On Mon, Sep 16, 2019 at 11:14:25AM -0400, Richard Salz wrote: > > Is it any surprise that the early GNU effort was really trying to recreate > > ITS? Can you really blame them? I'm grateful that they made `info` be a > > standalone program. Putting the concept of "cursor position" into the > > existing pagers (more/less/etc) and doing jump/xref/back would be more than > > a stretch, IMO. > > It's what Clem said. You should acclimate yourself to your environment. > Pushing info into man environment is a lot like being an immigrant and > wanting to bring your laws into your new homeland. That isn't a thing > and shouldn't be a thing. Doesn't matter that people think ITS is better, > they are in Unix. If you think ITS is better, go live there. > > When in Rome.... Well, in the shameless department, I can quote from my book: Mucking up the ecosystem into which you release code does not add value. Many developers behave as if they’re stereotypical Americans vacationing in another country, or for that matter my father-in-law visiting — the “I just came to your place, so do things my way” attitude. For example, UNIX systems have a command that displays manual pages for programs. You can type man foo and it’ll show you the page for the foo command. There’s also a convention that really complex commands, such as yacc , have both a manual page and a longer, more in-depth document that describes the program in more detail. When the GNU project (which I’ll discuss shortly) added commands to UNIX, it used its own texinfo system for manuals, which wasn’t compatible with the man system. The result was that users would have to try both the man and info commands to find documentation. Even if, as some believe, the GNU approach was superior, any possible benefits were outweighed by the UNIX community’s huge loss of productivity that resulted from the fragmented ecosystem. From imp at bsdimp.com Tue Sep 17 02:16:12 2019 From: imp at bsdimp.com (Warner Losh) Date: Mon, 16 Sep 2019 17:16:12 +0100 Subject: [TUHS] INed/Rand Editor/Ned [was Re: My EuroBSDcon talk (preview for commentary) In-Reply-To: References: <20190915232524.9A5491570CE9@mail.bitblocks.com> <7F62BF6B-8FEA-4C43-9E35-05BDE9BF04EA@ccc.com> <20190916023738.F34E81570CE9@mail.bitblocks.com> Message-ID: On Mon, Sep 16, 2019, 3:53 PM Clem Cole wrote: > > > On Sun, Sep 15, 2019 at 11:37 PM Charles H. Sauer > wrote: > >> The first Unix I used was PC/ix on an XT. I don’t know it even had vi, >> but it had INed, which I assume was the ISC evolution of NED & Rand Editor. >> > Yes, that is correct. > Venix had vi. At least 2.0 pulled that in from Berkeley... I got to look at the source to a few other editors of the era. All has the terminal codes hard coded into them... it was common to do that before things like termcap... Warner > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Tue Sep 17 02:26:14 2019 From: lm at mcvoy.com (Larry McVoy) Date: Mon, 16 Sep 2019 09:26:14 -0700 Subject: [TUHS] earliest Unix roff In-Reply-To: <201909161616.x8GGG4Fb020760@darkstar.fourwinds.com> References: <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org> <201909150654.x8F6sChG021185@freefriends.org> <201909160552.x8G5qBYK025195@freefriends.org> <20190916145122.GH2046@mcvoy.com> <20190916161040.GM2046@mcvoy.com> <201909161616.x8GGG4Fb020760@darkstar.fourwinds.com> Message-ID: <20190916162614.GO2046@mcvoy.com> +1 On Mon, Sep 16, 2019 at 09:16:03AM -0700, Jon Steinhart wrote: > Larry McVoy writes: > > On Mon, Sep 16, 2019 at 11:14:25AM -0400, Richard Salz wrote: > > > Is it any surprise that the early GNU effort was really trying to recreate > > > ITS? Can you really blame them? I'm grateful that they made `info` be a > > > standalone program. Putting the concept of "cursor position" into the > > > existing pagers (more/less/etc) and doing jump/xref/back would be more than > > > a stretch, IMO. > > > > It's what Clem said. You should acclimate yourself to your environment. > > Pushing info into man environment is a lot like being an immigrant and > > wanting to bring your laws into your new homeland. That isn't a thing > > and shouldn't be a thing. Doesn't matter that people think ITS is better, > > they are in Unix. If you think ITS is better, go live there. > > > > When in Rome.... > > Well, in the shameless department, I can quote from my book: > > Mucking up the ecosystem into which you release code does not > add value. Many developers behave as if they???re stereotypical > Americans vacationing in another country, or for that matter my > father-in-law visiting ??? the ???I just came to your place, so do > things my way??? attitude. > > For example, UNIX systems have a command that displays manual pages > for programs. You can type man foo and it???ll show you the page > for the foo command. There???s also a convention that really complex > commands, such as yacc , have both a manual page and a longer, more > in-depth document that describes the program in more detail. When > the GNU project (which I???ll discuss shortly) added commands to > UNIX, it used its own texinfo system for manuals, which wasn???t > compatible with the man system. The result was that users would have > to try both the man and info commands to find documentation. Even > if, as some believe, the GNU approach was superior, any possible > benefits were outweighed by the UNIX community???s huge loss of > productivity that resulted from the fragmented ecosystem. -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From rich.salz at gmail.com Tue Sep 17 02:31:13 2019 From: rich.salz at gmail.com (Richard Salz) Date: Mon, 16 Sep 2019 12:31:13 -0400 Subject: [TUHS] earliest Unix roff In-Reply-To: <20190916162614.GO2046@mcvoy.com> References: <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org> <201909150654.x8F6sChG021185@freefriends.org> <201909160552.x8G5qBYK025195@freefriends.org> <20190916145122.GH2046@mcvoy.com> <20190916161040.GM2046@mcvoy.com> <201909161616.x8GGG4Fb020760@darkstar.fourwinds.com> <20190916162614.GO2046@mcvoy.com> Message-ID: I don't think it's totally GNU's fault that it became Linux. They weren't trying to be tourists in Rome, they were trying to create a new city of their own. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Tue Sep 17 02:45:02 2019 From: lm at mcvoy.com (Larry McVoy) Date: Mon, 16 Sep 2019 09:45:02 -0700 Subject: [TUHS] earliest Unix roff In-Reply-To: References: <201909160552.x8G5qBYK025195@freefriends.org> <20190916145122.GH2046@mcvoy.com> <20190916161040.GM2046@mcvoy.com> <201909161616.x8GGG4Fb020760@darkstar.fourwinds.com> <20190916162614.GO2046@mcvoy.com> Message-ID: <20190916164502.GQ2046@mcvoy.com> On Mon, Sep 16, 2019 at 12:31:13PM -0400, Richard Salz wrote: > I don't think it's totally GNU's fault that it became Linux. They weren't > trying to be tourists in Rome, they were trying to create a new city of > their own. Yeah, except they didn't create their own city, they pooped all over a different one. There is no defense for what they did. If they did the right thing they would have created a markup language that could have produced info files and man files. It's not that hard, I wrote something called webroff that took -ms format input and produced a website complete with the navigation tree, it defaulted to showing you a page (each .NH) at time but it also had a site map where you could see the entire document as a single page, or each major section (.NH 1) as a page. For more than a decade this was BitMover's home page. I can't tell you how many sales calls I've been on and I've seen the entire web site printed out on the manager's desk. The reality is there was absolutely no need for a new format for info files, they could have parsed man input and produced info files and that's what they should have done. Those who defend the choice of info over man just aren't real Unix people. And that's fine, Unix isn't the only choice, they can go run some other OS and be happy. But it's just rude to thrust info into a Unix system. And lame because they could have parsed man pages into info docs and then they are adopting the Unix way of doing things and actually adding value. From clemc at ccc.com Tue Sep 17 03:00:24 2019 From: clemc at ccc.com (Clem Cole) Date: Mon, 16 Sep 2019 13:00:24 -0400 Subject: [TUHS] earliest Unix roff In-Reply-To: References: <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org> <201909150654.x8F6sChG021185@freefriends.org> <201909160552.x8G5qBYK025195@freefriends.org> <20190916145122.GH2046@mcvoy.com> <20190916161040.GM2046@mcvoy.com> <201909161616.x8GGG4Fb020760@darkstar.fourwinds.com> <20190916162614.GO2046@mcvoy.com> Message-ID: I note that it wasn't "GNI" it was GNU or he would have started with LISP. The fact is rms started by wanting to hack/rewrite Gosling EMACS as it had been released and some of the other C versions were at the same time a little less open to him as a starting point. Since it was not in LISP, he needed to write a C Compiler (which I still think is the #1 positive thing from the Gnu project and in the end, I believe that it was others that really made the compiler the success, not rms other than he tirelessly championed it). The reality is that the Gnu team quick set out to rewrite the UNIX tools and used Trix (a UNIX clone) as the original OS. Hurd did not come until later and in the Linux became the kernel it lived upon (as Jon says, it's Internet/Linux not Gnu/Linux). Sorry, IMO, rms tried to 'pee on Unix to make it smell like ITS' - not surprising as you say. But pretty darned arrogant none-the less. The results makes using many of the tools "astonishing" to everyone else. +1 to Jon's comments. "Even if, as some believe, the GNU approach was superior, any possible benefits were outweighed by the UNIX community’s huge loss of productivity that resulted from the fragmented ecosystem." Amen brother Jon, and this week's free will offering will be sponsoring .... On Mon, Sep 16, 2019 at 12:31 PM Richard Salz wrote: > I don't think it's totally GNU's fault that it became Linux. They weren't > trying to be tourists in Rome, they were trying to create a new city of > their own. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From steffen at sdaoden.eu Tue Sep 17 03:23:00 2019 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Mon, 16 Sep 2019 19:23:00 +0200 Subject: [TUHS] SCCS In-Reply-To: <20190914015517.GD12480@mcvoy.com> References: <20190911181101.GF3143@mcvoy.com> <20190912034346.GJ2046@mcvoy.com> <1457a2d6-2f17-482d-e4f7-ace439d34ca8@neophilic.com> <8db2e89c-ce50-a453-e38a-ecdfe69a746c@e-bbes.com> <20190913211104.aMZXy%steffen@sdaoden.eu> <20190913211751.GF2046@mcvoy.com> <20190913230312.XaeCQ%steffen@sdaoden.eu> <20190914015517.GD12480@mcvoy.com> Message-ID: <20190916172300.cjlkf%steffen@sdaoden.eu> Hello. Please excuse the late reply, your message (and many more) landed in the spam folder, i have adjusted the subject again. Larry McVoy wrote in <20190914015517.GD12480 at mcvoy.com>: |On Sat, Sep 14, 2019 at 01:03:12AM +0200, Steffen Nurpmeso wrote: |> He is as convinced from SCCS and its interleaved deltas as you |> are, but he works on extending the plain original SCCS, which is |> pretty smaller; his presentation from the "Chemnitzer Linux Tage |> 2012" (linux days of former Karl-Marx-Stadt) [1] talks about this |> and also prominently mentions BitKeeper: |> |> . All modern distributed OSS version control systems base upon |> BitKeeper in the end. | |Sort of. Monotone, Darcs, and one other one I can't remember did not |draw from BitKeeper. Mercurial, Git, and the Australian one that I |can't remember definitely do. | |> . BitKeeper bases upon the ideas of TeamWare. | |Only in that I am the primary author of both. It does support the idea |that SCCS is the basis for both, though Teamware used the real SCCS and |I rewrote SCCS from scratch and then extended it quite a bit. BitKeeper's |SCCS tracks a lot more than SCCS does, pathnames, permissions, hostnames, |etc. Regarding the technical background Jörg mentions US Patent 5481722 on merging deltas of source code control for computer software development that Glenn Skinner of Sun holds. |> . TeamWare bases upon the ideas of NSE. | |That's absolutely false. TeamWare, which is the productized version |of NSElite, which I wrote all of, was a reaction to how absolute shiite |NSE was. I had friends in the Sun kernel group that quit because they |were forced to use NSE. It was awful. I got into source management |because I was well known at Sun as the guy that could fix performance |problems so I was asked to look at NSE. One look told me that I couldn't |fix NSE but the source management problem space needed some help. | |> . NSE is a frontend to SCCS. | |That's true. | |> . Therewith all modern systems ultimately base upon SCCS. | |That is a big stretch, it's just not true. I love the SCCS file |format but to say all modern systems are based on SCCS is 100% |false. BitKeeper is. That's it. | |> . Distributed operate TeamWare, BitKeeper, git, Mercurial. | |Git and Mercurial were going for append only data structures. |That's not SCCS. | |All this comes from Jorg, isn't he the guy who has a track record of |being on the outside of Sun and trying to argue with me about what Sun |was doing when I was a well known guy in the most important group at Sun, |the kernel group. If so, I'd salt his stuff heavily. This is the Jörg Schilling with whom you have had a dispute on this list, yes. But i do not share this track record of yours. To me he is a person who distributed parts of my free software infrastructure when that was much smaller than today, and enabled me to burn CDs, which was a thing in the ninetees. And to the best of my knowledge he was an actor behind the berliOS open source hub, which lost its financial support alongside other German software projects (afaik) in the second half of the 2000's, and therefore rebased its users to Sourceforge. And more. I do not know about Sun let alone its internals, but i know for sure he worked with Sun code already in the 80s, and it seems he worked for a company who was working with Sun code very tightly. Since he is from Berlin where all the friendly communicative people come from it seems not unlikely that he got good hooks here and there, so why not. One thing he says, and which is an interesting part of this thread, is Die Behauptung von Eric Allman Tichy hätte SCCS Version 1 verwendet kann ich nicht glauben, denn die Veröffentlichungen von Tichy sind von 1982 und SCCS war seit Februar 1977 auf der Version 4. SCCS Version 3 hatte übrigens noch ein binäres Historyformat. The statement of Eric Allman that Tichy used SCCS version 1 i cannot believe, because Tichy's releases are from 1982, and SCCS version 4 was released as earyl as February 1977. SCCS version 3 used a binary history format, by the way. That should have addressed Eric Allman, but the longer i use email in the public space the more i like that pub-like feeling. (And not going to add that it reminds me of my childhood, where i was a boy under elder seasoned men _also_.) |I think he means well but is a little out there. Though some people |might say the same about me. I also think he means well. The rest i do not know about, Larry McVoy. I am a Buddhist also, and the Austrian Emperor even wanted to pardon also a woman who i think tortured and killed her own child, and the death penalty came back only due to massive pressure from the population. Jörg in turn says, i cite (and translate a bit loose), "Larry is good, but regarding himself a little bit too offensive". Without meaning any harm i think this can well be said, and is a key for making it in New York, without ever having been there. Bob Dylan even went electric! --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 lm at mcvoy.com Tue Sep 17 03:24:22 2019 From: lm at mcvoy.com (Larry McVoy) Date: Mon, 16 Sep 2019 10:24:22 -0700 Subject: [TUHS] earliest Unix roff In-Reply-To: <20190916171905.piituc2qdh46kejt@unixfarts.net> References: <20190916145122.GH2046@mcvoy.com> <20190916161040.GM2046@mcvoy.com> <201909161616.x8GGG4Fb020760@darkstar.fourwinds.com> <20190916162614.GO2046@mcvoy.com> <20190916164502.GQ2046@mcvoy.com> <20190916171905.piituc2qdh46kejt@unixfarts.net> Message-ID: <20190916172422.GS2046@mcvoy.com> On Mon, Sep 16, 2019 at 07:19:05PM +0200, KatolaZ wrote: > On Mon, Sep 16, 2019 at 09:45:02AM -0700, Larry McVoy wrote: > > [cut] > > > > > Those who defend the choice of info over man just aren't real Unix > > people. And that's fine, Unix isn't the only choice, they can go > > run some other OS and be happy. But it's just rude to thrust info > > into a Unix system. And lame because they could have parsed man > > pages into info docs and then they are adopting the Unix way of > > doing things and actually adding value. > > Sorry, but I totally don't see the point here. Jon put it well, the point is people expect to be able to say man foo and have that work. Until GNU came along, that's the way it was. GNU pushed a different system into the mix. The secondary point is they could have *added* to Unix by making a man2info command, I know they could have because I've done something similar, parsing man or -ms pages is trivial. GNU choose not to do that and I can't begin to express how wrong that was. GNU is not Unix for sure. From clemc at ccc.com Tue Sep 17 03:24:23 2019 From: clemc at ccc.com (Clem Cole) Date: Mon, 16 Sep 2019 13:24:23 -0400 Subject: [TUHS] earliest Unix roff In-Reply-To: <20190916164502.GQ2046@mcvoy.com> References: <201909160552.x8G5qBYK025195@freefriends.org> <20190916145122.GH2046@mcvoy.com> <20190916161040.GM2046@mcvoy.com> <201909161616.x8GGG4Fb020760@darkstar.fourwinds.com> <20190916162614.GO2046@mcvoy.com> <20190916164502.GQ2046@mcvoy.com> Message-ID: On Mon, Sep 16, 2019 at 12:45 PM Larry McVoy wrote: > Yeah, except they didn't create their own city, they pooped all over a > different one. peed *vs.* pooped - one is marking territory while the other is destroying it. It is interesting that both analogs work here, however. There is no defense for what they did. If they did the > right thing they would have created a markup language that could have > produced info files and man files. > +1 and that's why it is even more difficult to understand. Being polite and 'fitting in' would really not been any harder than being like Jon's father-in-law. > .... > Those who defend the choice of info over man just aren't real Unix people. I'd maybe say it as they don't want to be real Unix people and fit it with the rest. > And that's fine, Unix isn't the only choice, they can go > run some other OS and be happy. Frankly, trying to turn a Lisp Machine into a "Unix box" would have been as much of sin, in my eyes. Hey, I'm thrilled to see rms and his friends can build and purchase as many LMI box as he would like (But I do observe, the 'technically superior system,' in the end, wasn't very economical). I really don't mind bringing things over (like more, or job control, or command/filename completion that all came from other systems). That is really adding value to the new system (UNIX in this case). But it's just rude to thrust info > into a Unix system. And lame because they could have parsed man > pages into info docs and then they are adopting the Unix way of > doing things and actually adding value. touché As Larry and Jon have said better than I, it was the seemly effect of trying to replace man with info that I just don't understand. As Larry has said if they had made a way go from texinfo to man, even if it had been a little rough on the edges, I might have grumbled, but I would have tried to use it. The truth is today, like many other Unix hacker I know, if I am offered a new tool but using it means that I am being led down a path to use info/texinfo, I rethink if I want to use that new tool or not. It's a big turn off for me to want to learn to use such a tool since I know the authors have made no attempt to integrate it into a traditional UNIX workflow if they have not built proper man pages, much less written traditional docs. -------------- next part -------------- An HTML attachment was scrubbed... URL: From katolaz at freaknet.org Tue Sep 17 03:19:05 2019 From: katolaz at freaknet.org (KatolaZ) Date: Mon, 16 Sep 2019 19:19:05 +0200 Subject: [TUHS] earliest Unix roff In-Reply-To: <20190916164502.GQ2046@mcvoy.com> References: <201909160552.x8G5qBYK025195@freefriends.org> <20190916145122.GH2046@mcvoy.com> <20190916161040.GM2046@mcvoy.com> <201909161616.x8GGG4Fb020760@darkstar.fourwinds.com> <20190916162614.GO2046@mcvoy.com> <20190916164502.GQ2046@mcvoy.com> Message-ID: <20190916171905.piituc2qdh46kejt@unixfarts.net> On Mon, Sep 16, 2019 at 09:45:02AM -0700, Larry McVoy wrote: [cut] > > Those who defend the choice of info over man just aren't real Unix > people. And that's fine, Unix isn't the only choice, they can go > run some other OS and be happy. But it's just rude to thrust info > into a Unix system. And lame because they could have parsed man > pages into info docs and then they are adopting the Unix way of > doing things and actually adding value. Sorry, but I totally don't see the point here. The problem is not the technology, but the adopters. I personally don't like info at all, and still swear whenever a software comes without a proper manpage, but info has not been shovelled down your throat (or anybody else's, for that matter). The adopters have decided that info was fine for their use case. They could have written manpages and send patches over, and in many cases they didn't. There is plenty of software coming from the GNU project that has comprehensive and clear manpages (just to cite a single example, bash(1) comes with manpages, and no info doc). At the same time, there is tons of "Unix" software around that comes without any documentation *at all*, or with scant text files covering the bare basics. Unfortunately this trend is only getting worse, and we have far too many notaable examples here, not all of them coming from the GNU project, or from the "ITS tradition", whatever it means for you. I agree that whoever does not produce a readily usable documentaion for their software has not really understood much of the Unix philosophy. But that's not at all a matter of formats, rather of culture. Then, if you just want to vomit on info, or you prefer to use info as another excuse to vomit on the GNU project, well go ahead. But the actual issue is elsewhere (the lack of respect for the users, and the tendency to hide stuff under the carpet), and has not been introduced by the GNU project, at all. My2Cents Enzo Nicosia -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: not available URL: From jon at fourwinds.com Tue Sep 17 03:32:15 2019 From: jon at fourwinds.com (Jon Steinhart) Date: Mon, 16 Sep 2019 10:32:15 -0700 Subject: [TUHS] earliest Unix roff In-Reply-To: <20190916172422.GS2046@mcvoy.com> References: <20190916145122.GH2046@mcvoy.com> <20190916161040.GM2046@mcvoy.com> <201909161616.x8GGG4Fb020760@darkstar.fourwinds.com> <20190916162614.GO2046@mcvoy.com> <20190916164502.GQ2046@mcvoy.com> <20190916171905.piituc2qdh46kejt@unixfarts.net> <20190916172422.GS2046@mcvoy.com> Message-ID: <201909161732.x8GHWFjS007598@darkstar.fourwinds.com> Larry McVoy writes: > On Mon, Sep 16, 2019 at 07:19:05PM +0200, KatolaZ wrote: > > On Mon, Sep 16, 2019 at 09:45:02AM -0700, Larry McVoy wrote: > > > > [cut] > > > > > > > > Those who defend the choice of info over man just aren't real Unix > > > people. And that's fine, Unix isn't the only choice, they can go > > > run some other OS and be happy. But it's just rude to thrust info > > > into a Unix system. And lame because they could have parsed man > > > pages into info docs and then they are adopting the Unix way of > > > doing things and actually adding value. > > > > Sorry, but I totally don't see the point here. > > Jon put it well, the point is people expect to be able to say > > man foo > > and have that work. Until GNU came along, that's the way it was. > GNU pushed a different system into the mix. > > The secondary point is they could have *added* to Unix by making a > man2info command, I know they could have because I've done something > similar, parsing man or -ms pages is trivial. > > GNU choose not to do that and I can't begin to express how wrong > that was. GNU is not Unix for sure. So I'm not really trying to be all that shameless, it's just that I've already written down my opinions on this sort of stuff and don't need to retype it all. >From a section entitled "The Value Proposition": There's an overarching question that you should keep in mind when working on a project: "Am I adding value?" I'm not talking about the intrinsic value of accomplishing some task here; I'm talking about increasing productivity. If you're programming for a living, you need to meet whatever goals your employer has set. But, of course, there's more than one way to meet those goals. You could just do what you need to do to get by. Or, you could put a little thought into things that might not have occurred to management. For example, you might realize that your code would be useful in another project and structure it so it's easily reusable. Or, you might sense that you were tasked to implement a special case of a more general problem and solve that general problem instead, paving the way for future enhancements. Of course, you should talk about this with management so that they're not surprised. You can add value to yourself by making sure that you're proficient in a variety of technologies. Side projects are a common way to get experience; it's equivalent to doing homework but more fun. One classic way in which people attempt to add value is by creating tools. This is trickier than it seems because sometimes adding value for yourself reduces value for others. People often create new tools because some feature that they think they need is missing from existing ones. A good example is the make utility (invented by Stuart Feldman at Bell Labs in 1976), which is used to build large software packages. As time went on, new features were needed. Some of these were added to make, but in many other cases, people created well-intentioned but incompatible new utilities that performed similar functions. (For example, I consulted for a company once that wrote their own solely because they didn't bother to completely read the make documentation and were unaware that it would do exactly what they needed.) Now there's make, cmake, dmake, imake, pick-a-letter-make, and other programs that all do similar things in incompatible ways. The result is that practitioners like you need to learn multiple tools in each category. It makes everyone's life harder, not easier. It doesn't add value—it detracts. Figure 15-1 sums up the situation nicely. [ Figure 15-1 is the xkcd how standards proliferate cartoon ] From clemc at ccc.com Tue Sep 17 03:35:36 2019 From: clemc at ccc.com (Clem Cole) Date: Mon, 16 Sep 2019 13:35:36 -0400 Subject: [TUHS] earliest Unix roff In-Reply-To: <20190916172422.GS2046@mcvoy.com> References: <20190916145122.GH2046@mcvoy.com> <20190916161040.GM2046@mcvoy.com> <201909161616.x8GGG4Fb020760@darkstar.fourwinds.com> <20190916162614.GO2046@mcvoy.com> <20190916164502.GQ2046@mcvoy.com> <20190916171905.piituc2qdh46kejt@unixfarts.net> <20190916172422.GS2046@mcvoy.com> Message-ID: On Mon, Sep 16, 2019 at 1:24 PM Larry McVoy wrote: > The secondary point is they could have *added* to Unix by making a > man2info command > Exactly!!!! That's what Eric did when he wrote more(ucb) - he *added to Unix*. The funny part was that USG thought more(ucb) was a good idea and then wrote their own, pg(att); which was just as arrogant as the info behavior from the Gnu folks!!! Later, Less(internet) replaced more, but only as a superset, building on the foundation and eventually USB chose to ship more also as so many people wanted it. As I said yesterday, standing on the shoulders, not on their toes. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon at fourwinds.com Tue Sep 17 03:37:03 2019 From: jon at fourwinds.com (Jon Steinhart) Date: Mon, 16 Sep 2019 10:37:03 -0700 Subject: [TUHS] earliest Unix roff In-Reply-To: <20190916171905.piituc2qdh46kejt@unixfarts.net> References: <201909160552.x8G5qBYK025195@freefriends.org> <20190916145122.GH2046@mcvoy.com> <20190916161040.GM2046@mcvoy.com> <201909161616.x8GGG4Fb020760@darkstar.fourwinds.com> <20190916162614.GO2046@mcvoy.com> <20190916164502.GQ2046@mcvoy.com> <20190916171905.piituc2qdh46kejt@unixfarts.net> Message-ID: <201909161737.x8GHb3SG008244@darkstar.fourwinds.com> KatolaZ writes: > Sorry, but I totally don't see the point here. The problem is not the > technology, but the adopters. I personally don't like info at all, and > still swear whenever a software comes without a proper manpage, but > info has not been shovelled down your throat (or anybody else's, for > that matter). The adopters have decided that info was fine for their > use case. They could have written manpages and send patches over, and > in many cases they didn't. > > There is plenty of software coming from the GNU project that has > comprehensive and clear manpages (just to cite a single example, > bash(1) comes with manpages, and no info doc). At the same time, there > is tons of "Unix" software around that comes without any documentation > *at all*, or with scant text files covering the bare basics. > > Unfortunately this trend is only getting worse, and we have far too > many notaable examples here, not all of them coming from the GNU > project, or from the "ITS tradition", whatever it means for you. > > I agree that whoever does not produce a readily usable documentaion > for their software has not really understood much of the Unix > philosophy. But that's not at all a matter of formats, rather of > culture. > > Then, if you just want to vomit on info, or you prefer to use info as > another excuse to vomit on the GNU project, well go ahead. But the > actual issue is elsewhere (the lack of respect for the users, and the > tendency to hide stuff under the carpet), and has not been introduced > by the GNU project, at all. > > My2Cents > > Enzo Nicosia It seems to me that you're missing the point here. It's not a question of whether or not GNU programs have good documentation. It's the fact that GNU made it hard to find documentation because they took one pile and split it into two with no guide to what was in each pile. It's not that their documentation was good or bad, it's that they made it hard to find any documentation. Maybe it's because I'm a child of the 60s, but I'm with Arlo Guthrie on this one (from Alice's Restaurant): "And we decided that one big pile is better than two little piles, and rather than bring that one up we decided to throw ours down." Jon From chet.ramey at case.edu Tue Sep 17 04:04:00 2019 From: chet.ramey at case.edu (Chet Ramey) Date: Mon, 16 Sep 2019 14:04:00 -0400 Subject: [TUHS] earliest Unix roff In-Reply-To: <20190916171905.piituc2qdh46kejt@unixfarts.net> References: <201909160552.x8G5qBYK025195@freefriends.org> <20190916145122.GH2046@mcvoy.com> <20190916161040.GM2046@mcvoy.com> <201909161616.x8GGG4Fb020760@darkstar.fourwinds.com> <20190916162614.GO2046@mcvoy.com> <20190916164502.GQ2046@mcvoy.com> <20190916171905.piituc2qdh46kejt@unixfarts.net> Message-ID: <2d65ed3d-87a6-e3f4-7917-9611b631a100@case.edu> On 9/16/19 1:19 PM, KatolaZ wrote: > There is plenty of software coming from the GNU project that has > comprehensive and clear manpages (just to cite a single example, > bash(1) comes with manpages, and no info doc). Bash comes with both a large man page and an extensive info doc. -- ``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/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: OpenPGP digital signature URL: From katolaz at freaknet.org Tue Sep 17 04:09:43 2019 From: katolaz at freaknet.org (KatolaZ) Date: Mon, 16 Sep 2019 20:09:43 +0200 Subject: [TUHS] [OT] Re: earliest Unix roff In-Reply-To: <201909161737.x8GHb3SG008244@darkstar.fourwinds.com> References: <20190916145122.GH2046@mcvoy.com> <20190916161040.GM2046@mcvoy.com> <201909161616.x8GGG4Fb020760@darkstar.fourwinds.com> <20190916162614.GO2046@mcvoy.com> <20190916164502.GQ2046@mcvoy.com> <20190916171905.piituc2qdh46kejt@unixfarts.net> <201909161737.x8GHb3SG008244@darkstar.fourwinds.com> Message-ID: <20190916180942.qlipaxn4hq7of3kd@unixfarts.net> On Mon, Sep 16, 2019 at 10:37:03AM -0700, Jon Steinhart wrote: [cut] > > It seems to me that you're missing the point here. It's not a question of > whether or not GNU programs have good documentation. It's the fact that > GNU made it hard to find documentation because they took one pile and split > it into two with no guide to what was in each pile. It's not that their > documentation was good or bad, it's that they made it hard to find any > documentation. > > Maybe it's because I'm a child of the 60s, but I'm with Arlo Guthrie on this > one (from Alice's Restaurant): "And we decided that one big pile is better > than two little piles, and rather than bring that one up we decided to throw > ours down." > Dear Jon, I am a child of the 70s, so I know the drill ;) What I am saying is that the vast majority of the software from the GNU project actually has a good-quality manpage acoompanying it. And it also has the same documentation in info format. Hence I see no point in vomiting on info (which I mostly dislike anyway, as I said), as on any other document format, as long as the same information is made available via manpages as well, as it is the case for most of the software present in current Unix systems, wherever it comes from. The split caused by the introduction of info has mainly been cured by the community, maybe too late, but still. We can discuss whether the split was necessary or "right" in the first instance, as we could discuss whether it was good or not for cat(1) to leave Murray Hill in 1979 with no options and come back from Berkley with a source code doubled in size and 9 options in 1982. We could do that, but perhaps we shouldn't get too partisan, since the history of Unix is not a simple single-threaded and linear one, as the many insightful contributions posted in this ML show. It's a continuum, where it is difficult to find any single element which is totally right or totally wrong. I honestly see more danger in the recent trend that avoids documentation altogether, except for a scant README.md file at the top of the sources. There is an entire generation of developers who see little value in producing (and using) online documentation, where by online I mean manpage-like or info-like docs. For the simple reason that the main way in which documentation is produced and distributed has changed a lot in the last 25 years. Now it's all about googling the right words, unfortunately. We can keep blaming RMS, info, or the GNU project, but indeed blaming them for the Web would be a bit too much ;) And this is perhaps becoming OT anyway. HND Enzo Nicosia -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: not available URL: From jon at fourwinds.com Tue Sep 17 04:19:09 2019 From: jon at fourwinds.com (Jon Steinhart) Date: Mon, 16 Sep 2019 11:19:09 -0700 Subject: [TUHS] [OT] Re: earliest Unix roff In-Reply-To: <20190916180942.qlipaxn4hq7of3kd@unixfarts.net> References: <20190916145122.GH2046@mcvoy.com> <20190916161040.GM2046@mcvoy.com> <201909161616.x8GGG4Fb020760@darkstar.fourwinds.com> <20190916162614.GO2046@mcvoy.com> <20190916164502.GQ2046@mcvoy.com> <20190916171905.piituc2qdh46kejt@unixfarts.net> <201909161737.x8GHb3SG008244@darkstar.fourwinds.com> <20190916180942.qlipaxn4hq7of3kd@unixfarts.net> Message-ID: <201909161819.x8GIJ9Om014429@darkstar.fourwinds.com> KatolaZ writes: > Dear Jon, I am a child of the 70s, so I know the drill ;) > > What I am saying is that the vast majority of the software from the > GNU project actually has a good-quality manpage acoompanying it. And > it also has the same documentation in info format. Hence I see no > point in vomiting on info (which I mostly dislike anyway, as I said), > as on any other document format, as long as the same information is > made available via manpages as well, as it is the case for most of the > software present in current Unix systems, wherever it comes from. The > split caused by the introduction of info has mainly been cured by the > community, maybe too late, but still. > > We can discuss whether the split was necessary or "right" in the first > instance, as we could discuss whether it was good or not for cat(1) to > leave Murray Hill in 1979 with no options and come back from Berkley > with a source code doubled in size and 9 options in 1982. We could do > that, but perhaps we shouldn't get too partisan, since the history of > Unix is not a simple single-threaded and linear one, as the many > insightful contributions posted in this ML show. It's a continuum, > where it is difficult to find any single element which is totally > right or totally wrong. > > I honestly see more danger in the recent trend that avoids > documentation altogether, except for a scant README.md file at the top > of the sources. There is an entire generation of developers who see > little value in producing (and using) online documentation, where by > online I mean manpage-like or info-like docs. For the simple reason > that the main way in which documentation is produced and distributed > has changed a lot in the last 25 years. Now it's all about googling > the right words, unfortunately. > > We can keep blaming RMS, info, or the GNU project, but indeed blaming > them for the Web would be a bit too much ;) > > And this is perhaps becoming OT anyway. > > HND > > Enzo Nicosia Well, maybe we're just violently agreeing. Again, while I think that info is klunky-feeling, my issue is the ecosystem fragmentation. I think that it's not our place to discuss cat as Rob is on the list and he owns that :-) I do agree that the utter lack of any documentation is a bigger problem. Or worse, the document that says how to download, build, and install a package without ever saying what it does or how to use it. I'm not blaming RMS or GNU, I'm just using them as examples of a way of doing things that I don't like. I certainly don't blame them for the web. Please let's not get started on that! Jon From katolaz at freaknet.org Tue Sep 17 04:19:50 2019 From: katolaz at freaknet.org (KatolaZ) Date: Mon, 16 Sep 2019 20:19:50 +0200 Subject: [TUHS] earliest Unix roff In-Reply-To: <2d65ed3d-87a6-e3f4-7917-9611b631a100@case.edu> References: <20190916145122.GH2046@mcvoy.com> <20190916161040.GM2046@mcvoy.com> <201909161616.x8GGG4Fb020760@darkstar.fourwinds.com> <20190916162614.GO2046@mcvoy.com> <20190916164502.GQ2046@mcvoy.com> <20190916171905.piituc2qdh46kejt@unixfarts.net> <2d65ed3d-87a6-e3f4-7917-9611b631a100@case.edu> Message-ID: <20190916181949.uhzg2gipcqfinhol@unixfarts.net> On Mon, Sep 16, 2019 at 02:04:00PM -0400, Chet Ramey wrote: > On 9/16/19 1:19 PM, KatolaZ wrote: > > > There is plenty of software coming from the GNU project that has > > comprehensive and clear manpages (just to cite a single example, > > bash(1) comes with manpages, and no info doc). > > Bash comes with both a large man page and an extensive info doc. > Yep, sorry! I meant "and not only an info doc". And they are both of very good quality, IMHO. HND Enzo Nicosia -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: not available URL: From steffen at sdaoden.eu Tue Sep 17 05:13:44 2019 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Mon, 16 Sep 2019 21:13:44 +0200 Subject: [TUHS] earliest Unix roff In-Reply-To: References: <20190913221345.GA16129@minnie.tuhs.org> <20190914020240.GO2046@mcvoy.com> <20190914024433.GA19193@minnie.tuhs.org> <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org> <201909150654.x8F6sChG021185@freefriends.org> <201909160552.x8G5qBYK025195@freefriends.org> <20190916145122.GH2046@mcvoy.com> Message-ID: <20190916191344.yjsVn%steffen@sdaoden.eu> Richard Salz wrote in : |Is it any surprise that the early GNU effort was really trying to recreate \ |ITS?  Can you really blame them?  I'm grateful that they made `info` \ |be a standalone program.  Putting the concept of "cursor |position" into the existing pagers (more/less/etc) and doing jump/xref/b\ |ack would be more than a stretch, IMO. So that is actually not true, really. --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 bakul at bitblocks.com Tue Sep 17 05:31:30 2019 From: bakul at bitblocks.com (Bakul Shah) Date: Mon, 16 Sep 2019 12:31:30 -0700 Subject: [TUHS] earliest Unix roff In-Reply-To: References: <20190913221345.GA16129@minnie.tuhs.org> <20190914020240.GO2046@mcvoy.com> <20190914024433.GA19193@minnie.tuhs.org> <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org> <201909150654.x8F6sChG021185@freefriends.org> <201909160552.x8G5qBYK025195@freefriends.org> <20190916145122.GH2046@mcvoy.com> Message-ID: <28BD5CAE-F826-4A38-8587-A90C0235A484@bitblocks.com> The way Rob solved the problem in acme(1) is much nicer. Right click on |open(2)| and its man page opens up in a new window. You can do the same on any manpage mentioned in the SEE ALSO section or anywhere else and you can see their man page without any side-effect on the original window. He didn't throw out any old documentation but added a a new tool to make navigation easier (and it is more general in that you can define right click actions). There was already cursor positioning available in vi. It would not have been a real stretch to hack in acme like support in less or vi (clumsier without a mouse but still). In fact tag support in vi already did something like it with ^] and ^^ for jump/back. > On Sep 16, 2019, at 8:14 AM, Richard Salz wrote: > > Is it any surprise that the early GNU effort was really trying to recreate ITS? Can you really blame them? I'm grateful that they made `info` be a standalone program. Putting the concept of "cursor position" into the existing pagers (more/less/etc) and doing jump/xref/back would be more than a stretch, IMO. > From steffen at sdaoden.eu Tue Sep 17 05:32:29 2019 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Mon, 16 Sep 2019 21:32:29 +0200 Subject: [TUHS] earliest Unix roff [correction] In-Reply-To: <201909150247.x8F2l8Vp094001@tahoe.cs.Dartmouth.EDU> References: <201909150247.x8F2l8Vp094001@tahoe.cs.Dartmouth.EDU> Message-ID: <20190916193229.zaC9X%steffen@sdaoden.eu> Doug McIlroy wrote in <201909150247.x8F2l8Vp094001 at tahoe.cs.Dartmouth.EDU>: |The URL for roff71 scans is https://www.cs.dartmouth.edu/~doug/roff71/ Thank you very much. Also for "Happy Roffing" in general, Mr. McIlroy! --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From steffen at sdaoden.eu Tue Sep 17 05:56:18 2019 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Mon, 16 Sep 2019 21:56:18 +0200 Subject: [TUHS] Fwd: Re: earliest Unix roff Message-ID: <20190916195618.06nlI%steffen@sdaoden.eu> Sorry, i said "yes" to the false question. --- Forwarded from Steffen Nurpmeso --- Date: Mon, 16 Sep 2019 21:12:28 +0200 From: Steffen Nurpmeso To: chet.ramey at case.edu Subject: Re: [TUHS] earliest Unix roff Message-ID: <20190916191228.1YQHs%steffen at sdaoden.eu> OpenPGP: id=EE19E1C1F2F7054F8D3954D8308964B51883A0DD; url=https://ftp.sdaoden.eu/steffen.asc; preference=signencrypt Chet Ramey wrote in <95916cf9-9aa1-f949-0f37-0ae466e38aa2 at case.edu>: |On 9/16/19 8:10 AM, Clem Cole wrote: |> I use the standalone Info reader (named info) if I want to look \ |> at the |> Info output.  |> |> Fair enough, but be careful, while I admit I have not looked in a while, |> info(gnu) relies on emacs keybindings and a number of very emacs'ish th\ |> ings. |> Every time I have tried to deal with it, I have unprogram my fingers and |> reset them to emacs. |> |> If it would have used more(1) [or even less(1)] then I would not \ |> be as annoyed. | |It seems to me that the strength of info (the file format and program) is |the navigation of a menu-driven hierarchical document containing what are |essentially selectable links between sections. Something like more or less |is poorly suited to take advantage of those features. But you can do that in man macros with a normal pager like less(1), too. I mean, i may bore people, but yes i have written a macro extension for the mdoc macros which can be used to generate a TOC, and which generates document local as well as links to external manual pages. This works for all output formats, but particularly well for those which support links themselves, HTML, PDF as well as grotty, the TTY output device of groff. There was a feature request, but it has not been included yet. (My own port of roff where it will ship out of the box i just do not find time for, but i said to myself that after having banged my head a thousand times against the wall of a totally f....d up software code base, if i maintain yet another free software project then this time i do not release anything until i can say i am ready.) You can see the manual page online if you want to, it is at [1] (and itself the HTML output of a manual which uses the macro). Nothing magic, it is just that the grotty device then uses backspace escape sequences not only to embolden or otherwise format text, but also to invisibly embed content information. And a patched less(1) can search for these specially crafted backspace sequences easily, in fact i use that each and every time when i look at the manual page of the MUA i maintain, which is even longer than the bash manual. The patch for less is pretty small, even though it cares for less conventions: #?0|kent:less.tar_bomb_git$ git diff master..mdocmx|wc -l 413 [1] https://www.sdaoden.eu/code-mdocmx.html It has the deficite of not being able to dig macros as part of headers, e.g. "HISTORY ON less(1)" where less(1) would be an external link, this cannot work out the way the mdoc macros are implemented in groff. They would need to become rewritten, but no time for that yet. Other than that it works just fine for half a decade, for development i have mdoc() ( MDOCMX_ENABLE=1 \export MDOCMX_ENABLE \: ${MDOCMXFLAGS:=-dmx-toc-force=tree} \mdocmx.sh "${1}" | \s-roff -Tutf8 -mdoc ${MDOCMXFLAGS} | LESS= \s-less --RAW-CONTROL-CHARS --ignore-case --no-init ) where s-roff and s-less are the patched version. This is the development version, the nice property of mdocmx is that the preprocessing step can be shipped, in fact it is for half a decade, too. For such manuals you only need grotty/less to be patched. So then in in less i hit ^A and will be asked [anchor]: then i enter the number and it scrolls into view. And ' will scroll back to where you have been before following the internal link. Likewise, if the entered number links an external manual page you first see Read external manual: !man 1 sh and if you hit return, you go there, temporarily suspending the current less. (This external thing is actually a compile time option.) So this is all i need, and it would be very nice to have this possibility much more often. Well. The mandoc project has an option to generate links for manual pages on best guess, too. This works surprisingly well, and does not need a patch for less as it generates the usual tag files that you all know about. It cannot support exact anchor support, of course, and TOC generation it does not have too, i think. But anyway: it is possible. |You need a way to position the cursor with more flexibility than more gives |you. --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) -- End forward <20190916191228.1YQHs%steffen at sdaoden.eu> --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 g.branden.robinson at gmail.com Tue Sep 17 06:21:56 2019 From: g.branden.robinson at gmail.com (G. Branden Robinson) Date: Tue, 17 Sep 2019 06:21:56 +1000 Subject: [TUHS] INed/Rand Editor/Ned [was Re: My EuroBSDcon talk (preview for commentary) In-Reply-To: References: <20190915232524.9A5491570CE9@mail.bitblocks.com> <7F62BF6B-8FEA-4C43-9E35-05BDE9BF04EA@ccc.com> <20190916023738.F34E81570CE9@mail.bitblocks.com> Message-ID: <20190916202153.wbpzx3jn3a7rs6kb@localhost.localdomain> At 2019-09-16T17:16:12+0100, Warner Losh wrote: > I got to look at the source to a few other editors of the era. All has > the terminal codes hard coded into them... it was common to do that > before things like termcap... It's still common today. Everything the developer cares to think about, let alone test on, interprets EMCA-48 SGR escape sequences. My favorite recent example is "spectre-meltdown-checker", which has such edifying lines as: _info_nol "> \033[46m\033[30mSTATUS:\033[0m " Why write something portable when you can be "close to the metal"? :-/ I gently steer people to better ways when the occasion presents itself. Regards, Branden -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From lm at mcvoy.com Tue Sep 17 06:31:52 2019 From: lm at mcvoy.com (Larry McVoy) Date: Mon, 16 Sep 2019 13:31:52 -0700 Subject: [TUHS] SCCS In-Reply-To: <20190916172300.cjlkf%steffen@sdaoden.eu> References: <20190912034346.GJ2046@mcvoy.com> <1457a2d6-2f17-482d-e4f7-ace439d34ca8@neophilic.com> <8db2e89c-ce50-a453-e38a-ecdfe69a746c@e-bbes.com> <20190913211104.aMZXy%steffen@sdaoden.eu> <20190913211751.GF2046@mcvoy.com> <20190913230312.XaeCQ%steffen@sdaoden.eu> <20190914015517.GD12480@mcvoy.com> <20190916172300.cjlkf%steffen@sdaoden.eu> Message-ID: <20190916203152.GB9704@mcvoy.com> On Mon, Sep 16, 2019 at 07:23:00PM +0200, Steffen Nurpmeso wrote: > Larry McVoy wrote in <20190914015517.GD12480 at mcvoy.com>: > |On Sat, Sep 14, 2019 at 01:03:12AM +0200, Steffen Nurpmeso wrote: > |> He is as convinced from SCCS and its interleaved deltas as you > |> are, but he works on extending the plain original SCCS, which is > |> pretty smaller; his presentation from the "Chemnitzer Linux Tage > |> 2012" (linux days of former Karl-Marx-Stadt) [1] talks about this > |> and also prominently mentions BitKeeper: > |> > |> . All modern distributed OSS version control systems base upon > |> BitKeeper in the end. > | > |Sort of. Monotone, Darcs, and one other one I can't remember did not > |draw from BitKeeper. Mercurial, Git, and the Australian one that I > |can't remember definitely do. > | > |> . BitKeeper bases upon the ideas of TeamWare. > | > |Only in that I am the primary author of both. It does support the idea > |that SCCS is the basis for both, though Teamware used the real SCCS and > |I rewrote SCCS from scratch and then extended it quite a bit. BitKeeper's > |SCCS tracks a lot more than SCCS does, pathnames, permissions, hostnames, > |etc. > > Regarding the technical background J??rg mentions US Patent 5481722 > on merging deltas of source code control for computer software > development that Glenn Skinner of Sun holds. Yeah, it's nuts that Glenn got that patent. It's true it was his idea to do the graph that way, and he had an implementation that created the graph through multiple calls to stripdel, get, and delta. It was excruciatingly slow. 100% of the code that implemented the one pass "zipper"-ing of 2 diverged SCCS files was designed and written by me. At the very least, I should have been coauthor of the patent but Sun politics got in the way [1]. > |> . TeamWare bases upon the ideas of NSE. > | > |That's absolutely false. TeamWare, which is the productized version > |of NSElite, which I wrote all of, was a reaction to how absolute shiite > |NSE was. I had friends in the Sun kernel group that quit because they > |were forced to use NSE. It was awful. I got into source management > |because I was well known at Sun as the guy that could fix performance > |problems so I was asked to look at NSE. One look told me that I couldn't > |fix NSE but the source management problem space needed some help. [1] The politics had to do with Teamware. I wrote all the code in NSElite, including smoosh(1) which was what the patent covered (though the patent happened later). Everyone in the kernel group were using NSElite because NSE sucked so hard. But it wasn't sanctioned code, it was a Larry project. Bill Shannon would walk around and tell people that they couldn't use NSElite but they ignored him because it worked and it was light years faster than NSE. They couldn't kill NSElite so they decided to toss it to an 8 person team in the tools group. They told me if I wanted to work on tools I had to go join the tools group. Yeah, right, I'm in the kernel group and I'm going to take the 3 step downgrade to tools? I don't think so. I just kept on supporting and developing NSElite, which was 90% perl4 and a xview graphical program to view history and smoosh (both C). Because I was coding most of the stuff in (very stylized perl, I rewrote it 3 times until I had code I could have a hope of maintaining), I was much faster at rolling out new stuff. In fact, the 8 people choose to rewrite everything in C++ which meant I was coding circles around them. Hence the politics, one guy, in his spare time, while doing a full time job hacking the kernel, was making 8 guys look like idiots. Evan later wrote a paper about what a bad choice C++ was. Something had to give and Jon Kannegaard, who was the VP of the tools group, walked into my office and said "I've got Scott's (McNealy, CEO) approval on this. If you make one more release of NSElite you are fired." Nice, eh? Not everything was perfect at Sun. So I stopped, I left the kernel group and went over and did SPARC Clusters for Ken Okin. Glenn filed the patent after I left. It was a shame because NSElite didn't have changesets, it wasn't really a distributed system (relied on NFS to get at remote repos), if I had kept going it would have evolved into what BitKeeper bacame. Oh, yeah, the politics were so bad that when Evan took smoosh.c he didn't take any of the SCCS history, he checked it in so it looked like he wrote it. Even Shannon called that dirty pool. > |> . NSE is a frontend to SCCS. > | > |That's true. > | > |> . Therewith all modern systems ultimately base upon SCCS. > | > |That is a big stretch, it's just not true. I love the SCCS file > |format but to say all modern systems are based on SCCS is 100% > |false. BitKeeper is. That's it. > | > |> . Distributed operate TeamWare, BitKeeper, git, Mercurial. > | > |Git and Mercurial were going for append only data structures. > |That's not SCCS. > | > |All this comes from Jorg, isn't he the guy who has a track record of > |being on the outside of Sun and trying to argue with me about what Sun > |was doing when I was a well known guy in the most important group at Sun, > |the kernel group. If so, I'd salt his stuff heavily. > > This is the J??rg Schilling with whom you have had a dispute on > this list, yes. But i do not share this track record of yours. OK, I'm happy you like him, I liked him just fine until he started making statements that aren't true. Statements that were about what Sun was doing and why they were doing it. Statements about the content and direction of the kernel development, that I knew to be false because I was in the Sun kernel group during the time he was referencing. Kinda hard to be any closer to it than I was so unless I've gone completely senile in my old age, I'm probably more likely to be right about that information than he is. I was there, he was not. > One thing he says, and which is an interesting part of this > thread, is > > Die Behauptung von Eric Allman Tichy h??tte SCCS Version > 1 verwendet kann ich nicht glauben, denn die Ver??ffentlichungen > von Tichy sind von 1982 und SCCS war seit Februar 1977 auf der > Version 4. SCCS Version 3 hatte ??brigens noch ein bin??res > Historyformat. > > The statement of Eric Allman that Tichy used SCCS version > 1 i cannot believe, because Tichy's releases are from 1982, and > SCCS version 4 was released as earyl as February 1977. SCCS > version 3 used a binary history format, by the way. Before my time so I don't know. I was an undergrad Art History major at that time :) --lm From jon at fourwinds.com Tue Sep 17 06:47:27 2019 From: jon at fourwinds.com (Jon Steinhart) Date: Mon, 16 Sep 2019 13:47:27 -0700 Subject: [TUHS] INed/Rand Editor/Ned [was Re: My EuroBSDcon talk (preview for commentary) In-Reply-To: <20190916202153.wbpzx3jn3a7rs6kb@localhost.localdomain> References: <20190915232524.9A5491570CE9@mail.bitblocks.com> <7F62BF6B-8FEA-4C43-9E35-05BDE9BF04EA@ccc.com> <20190916023738.F34E81570CE9@mail.bitblocks.com> <20190916202153.wbpzx3jn3a7rs6kb@localhost.localdomain> Message-ID: <201909162047.x8GKlSbX001635@darkstar.fourwinds.com> G. Branden Robinson writes: > > At 2019-09-16T17:16:12+0100, Warner Losh wrote: > > I got to look at the source to a few other editors of the era. All has > > the terminal codes hard coded into them... it was common to do that > > before things like termcap... > > It's still common today. Everything the developer cares to think about, > let alone test on, interprets EMCA-48 SGR escape sequences. My favorite > recent example is "spectre-meltdown-checker", which has such edifying > lines as: > > _info_nol "> \033[46m\033[30mSTATUS:\033[0m " > > Why write something portable when you can be "close to the metal"? :-/ > > I gently steer people to better ways when the occasion presents itself. > > Regards, > Branden We can have an interesting discussion of the definition of "better ways". I see termcap as a great solution for the days in which there was little standardization. But it's probably pretty hard to find a non-conforming terminal nowadays so I think that it's better to avoid obfuscation. Were it me I would have a comment that referenced the page and section number in the standard. Since we like debating the merits of old technology, somebody can kick off a termcap versus terminfo discussion :-) Jon From dave at horsfall.org Tue Sep 17 07:42:28 2019 From: dave at horsfall.org (Dave Horsfall) Date: Tue, 17 Sep 2019 07:42:28 +1000 (EST) Subject: [TUHS] earliest Unix roff In-Reply-To: References: <201909132024.x8DKObEP013266@darkstar.fourwinds.com> <463d5cc4-9bef-9ac3-a680-a5161d664dc1@aueb.gr> <20190913221345.GA16129@minnie.tuhs.org> <20190914020240.GO2046@mcvoy.com> <20190914024433.GA19193@minnie.tuhs.org> <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org> <201909150654.x8F6sChG021185@freefriends.org> <201909160552.x8G5qBYK025195@freefriends.org> Message-ID: On Mon, 16 Sep 2019, Clem Cole wrote: > Fair enough, but be careful, while I admit I have not looked in a while, > info(gnu) relies on emacs keybindings and a number of very > emacs'ish things. Every time I have tried to deal with it, I have > unprogram my fingers and reset them to emacs. Yep, which is why I like "info" as much as I like EMACS i.e. not at all. What exactly is wrong with the manpage format? It tells you everything you need to know, and tells you where to find further information. -- Dave From dave at horsfall.org Tue Sep 17 07:45:51 2019 From: dave at horsfall.org (Dave Horsfall) Date: Tue, 17 Sep 2019 07:45:51 +1000 (EST) Subject: [TUHS] [SPAM] Re: SCCS In-Reply-To: <878sqosaob.fsf@vuxu.org> References: <1568412078.22454.for-standards-violators@oclsc.org> <878sqosaob.fsf@vuxu.org> Message-ID: On Mon, 16 Sep 2019, Leah Neukirchen wrote: > IPv6 has no checksum at all (for the header), and TCPv6 uses the same > checksum algorithm. Every time I've tried to read the IPv6 spec my eyes glazed over; it was plainly designed by a committee i.e. everybody wanted their mark on it. -- Dave From lm at mcvoy.com Tue Sep 17 07:48:32 2019 From: lm at mcvoy.com (Larry McVoy) Date: Mon, 16 Sep 2019 14:48:32 -0700 Subject: [TUHS] earliest Unix roff In-Reply-To: References: <20190913221345.GA16129@minnie.tuhs.org> <20190914020240.GO2046@mcvoy.com> <20190914024433.GA19193@minnie.tuhs.org> <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org> <201909150654.x8F6sChG021185@freefriends.org> <201909160552.x8G5qBYK025195@freefriends.org> Message-ID: <20190916214832.GW2046@mcvoy.com> On Tue, Sep 17, 2019 at 07:42:28AM +1000, Dave Horsfall wrote: > On Mon, 16 Sep 2019, Clem Cole wrote: > > >Fair enough, but be careful, while I admit I have not looked in a while, > >info(gnu) relies on emacs keybindings and a number of very > >emacs'ish??things. Every time I have tried to deal with it, I have > >unprogram my fingers and reset them to emacs. > > Yep, which is why I like "info" as much as I like EMACS i.e. not at all. > > What exactly is wrong with the manpage format? It tells you everything you > need to know, and tells you where to find further information. I think, someone correct me if I'm wrong, the info stuff was designed to handle larger, more complex stuff, with a table of contents, etc. Something like perl could fit in one info doc but the perl man page is not a thing, it's just a series of pointers to more man pages. From jon at fourwinds.com Tue Sep 17 07:54:49 2019 From: jon at fourwinds.com (Jon Steinhart) Date: Mon, 16 Sep 2019 14:54:49 -0700 Subject: [TUHS] earliest Unix roff In-Reply-To: <20190916214832.GW2046@mcvoy.com> References: <20190913221345.GA16129@minnie.tuhs.org> <20190914020240.GO2046@mcvoy.com> <20190914024433.GA19193@minnie.tuhs.org> <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org> <201909150654.x8F6sChG021185@freefriends.org> <201909160552.x8G5qBYK025195@freefriends.org> <20190916214832.GW2046@mcvoy.com> Message-ID: <201909162154.x8GLsnOs011718@darkstar.fourwinds.com> Larry McVoy writes: > > I think, someone correct me if I'm wrong, the info stuff was designed > to handle larger, more complex stuff, with a table of contents, etc. > Something like perl could fit in one info doc but the perl man page is > not a thing, it's just a series of pointers to more man pages. Can't answer you directly on this one, but I prefer the old system of having man pages and separate documents for longer things. I still have old notebooks full of papers on lex, yacc, and so on. One of the problems with using info for something like perl is that it doesn't have a useful organization. There's a difference to me between a reference manual and a user's guide. Most of the stuff referenced by the main perl page is user's guide stuff to me, it's not a reference. Probably someone knows more than me about all this. I have always been under the impression that one read the user's guide to learn about complicated stuff. The manual pages were there so that you could find the right options when you forgot. Putting every detail about a complex program into a manual page doesn't feel right to me. Jon From beebe at math.utah.edu Tue Sep 17 07:48:36 2019 From: beebe at math.utah.edu (Nelson H. F. Beebe) Date: Mon, 16 Sep 2019 15:48:36 -0600 Subject: [TUHS] [tuhs] Computer history preservation Message-ID: A major topic on this list has been the preservation of computer history, through museums that collect and operate old hardware, software emulation of past hardware and software systems, and data recovery from newly discovered, but previously thought to be lost, archives. I came across an article today about another major industry that has been exceedingly careless about preserving its history: Wipe Out: When the BBC Kept Erasing Its Own History https://getpocket.com/explore/item/wipe-out-when-the-bbc-kept-erasing-its-own-history It is a must-read for Dr Who fans on this list. ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah FAX: +1 801 581 4148 - - Department of Mathematics, 110 LCB Internet e-mail: beebe at math.utah.edu - - 155 S 1400 E RM 233 beebe at acm.org beebe at computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - ------------------------------------------------------------------------------- From lm at mcvoy.com Tue Sep 17 07:59:17 2019 From: lm at mcvoy.com (Larry McVoy) Date: Mon, 16 Sep 2019 14:59:17 -0700 Subject: [TUHS] earliest Unix roff In-Reply-To: <201909162154.x8GLsnOs011718@darkstar.fourwinds.com> References: <20190914020240.GO2046@mcvoy.com> <20190914024433.GA19193@minnie.tuhs.org> <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org> <201909150654.x8F6sChG021185@freefriends.org> <201909160552.x8G5qBYK025195@freefriends.org> <20190916214832.GW2046@mcvoy.com> <201909162154.x8GLsnOs011718@darkstar.fourwinds.com> Message-ID: <20190916215917.GX2046@mcvoy.com> On Mon, Sep 16, 2019 at 02:54:49PM -0700, Jon Steinhart wrote: > Larry McVoy writes: > > > > I think, someone correct me if I'm wrong, the info stuff was designed > > to handle larger, more complex stuff, with a table of contents, etc. > > Something like perl could fit in one info doc but the perl man page is > > not a thing, it's just a series of pointers to more man pages. > > Can't answer you directly on this one, but I prefer the old system of > having man pages and separate documents for longer things. I still > have old notebooks full of papers on lex, yacc, and so on. > > One of the problems with using info for something like perl is that it > doesn't have a useful organization. We are 100% on the same page. My complaint about wikis is it is impossible to find anything without a search engine. I like tables of contents and indices. My comment on the info stuff was just my understand of why it came to be. From dave at horsfall.org Tue Sep 17 08:05:53 2019 From: dave at horsfall.org (Dave Horsfall) Date: Tue, 17 Sep 2019 08:05:53 +1000 (EST) Subject: [TUHS] earliest Unix roff In-Reply-To: References: <201909132024.x8DKObEP013266@darkstar.fourwinds.com> <463d5cc4-9bef-9ac3-a680-a5161d664dc1@aueb.gr> <20190913221345.GA16129@minnie.tuhs.org> <20190914020240.GO2046@mcvoy.com> <20190914024433.GA19193@minnie.tuhs.org> <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org> <201909150654.x8F6sChG021185@freefriends.org> <201909160552.x8G5qBYK025195@freefriends.org> <7wd0g0o2a0.fsf@junk.nocrew.org> Message-ID: On Mon, 16 Sep 2019, Clem Cole wrote: > > However, please note that more(1) also was inspired by, almost > > copied from, ITS.  Certainly the prompt --More-- is. > > Absolutely.  A friend of mine/fellow UCB grad student, Eric Shienbrood, > wrote it.  He was a MIT undergrad. And Eric happily said it was modeled > from ITS. And before, Eric wrote it, UNIX lacked anything like it.  >  Which to me is fine, taking an idea from another system to add a new > feature that is lacking. Am I the only one who remembers the old "pg" program? It seems to have disappeared. -- Dave From bakul at bitblocks.com Tue Sep 17 08:10:24 2019 From: bakul at bitblocks.com (Bakul Shah) Date: Mon, 16 Sep 2019 15:10:24 -0700 Subject: [TUHS] earliest Unix roff In-Reply-To: Your message of "Mon, 16 Sep 2019 14:54:49 -0700." <201909162154.x8GLsnOs011718@darkstar.fourwinds.com> References: <20190913221345.GA16129@minnie.tuhs.org> <20190914020240.GO2046@mcvoy.com> <20190914024433.GA19193@minnie.tuhs.org> <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org> <201909150654.x8F6sChG021185@freefriends.org> <201909160552.x8G5qBYK025195@freefriends.org> <20190916214832.GW2046@mcvoy.com> <201909162154.x8GLsnOs011718@darkstar.fourwinds.com> Message-ID: <20190916221031.5E55C1570CE9@mail.bitblocks.com> On Mon, 16 Sep 2019 14:54:49 -0700 Jon Steinhart wrote: > Larry McVoy writes: > > > > I think, someone correct me if I'm wrong, the info stuff was designed > > to handle larger, more complex stuff, with a table of contents, etc. > > Something like perl could fit in one info doc but the perl man page is > > not a thing, it's just a series of pointers to more man pages. > > Can't answer you directly on this one, but I prefer the old system of > having man pages and separate documents for longer things. I still > have old notebooks full of papers on lex, yacc, and so on. > > One of the problems with using info for something like perl is that it > doesn't have a useful organization. There's a difference to me between > a reference manual and a user's guide. Most of the stuff referenced by > the main perl page is user's guide stuff to me, it's not a reference. > > Probably someone knows more than me about all this. I have always been > under the impression that one read the user's guide to learn about > complicated stuff. The manual pages were there so that you could find > the right options when you forgot. Putting every detail about a complex > program into a manual page doesn't feel right to me. A typical manpage had just the right length. Reading man pages and experimenting is how I initially learned all about unix commands. Keeping a manpage short also limited what you as the implementer would be tempted to add to the command. Manpages work best for programs that follow the unix mantra of do one thing and do it well. But not for kitchensink programs. When you need a multipage reference manual (for *experts*) with a TOC and program to "navigate", you're much more likely to give into the temptation of adding more features than partition functionality into separate programs that work well together. Not to mention it is harder to get something right that has many more features. From ggm at algebras.org Tue Sep 17 08:21:04 2019 From: ggm at algebras.org (George Michaelson) Date: Tue, 17 Sep 2019 08:21:04 +1000 Subject: [TUHS] [SPAM] Re: SCCS In-Reply-To: References: <1568412078.22454.for-standards-violators@oclsc.org> <878sqosaob.fsf@vuxu.org> Message-ID: Third mistake ever was host-only fragmentation and re-assembly. The lack of pragmatism tells here, because it means intermediate systems have no choice but to drop. Second biggest mistake was keeping the order SRC, DST when if the DST is first you can latch it into a buffer and do forwarding decisions while the rest of the packet is in processing. First biggest mistake was ignoring TUBA. -G On Tue, Sep 17, 2019 at 7:46 AM Dave Horsfall wrote: > > On Mon, 16 Sep 2019, Leah Neukirchen wrote: > > > IPv6 has no checksum at all (for the header), and TCPv6 uses the same > > checksum algorithm. > > Every time I've tried to read the IPv6 spec my eyes glazed over; it was > plainly designed by a committee i.e. everybody wanted their mark on it. > > -- Dave From gregg.drwho8 at gmail.com Tue Sep 17 08:24:39 2019 From: gregg.drwho8 at gmail.com (Gregg Levine) Date: Mon, 16 Sep 2019 18:24:39 -0400 Subject: [TUHS] [tuhs] Computer history preservation In-Reply-To: References: Message-ID: Hello! Thank you Nelson. That confirms largely what I've largely already known from other sources. Suffice to say a lot of the Doctor Who episodes confirmed are being restored, just not the way we wanted..... However everything from Third down to the latest is available. ----- Gregg C Levine gregg.drwho8 at gmail.com "This signature fought the Time Wars, time and again." On Mon, Sep 16, 2019 at 5:56 PM Nelson H. F. Beebe wrote: > > A major topic on this list has been the preservation of computer > history, through museums that collect and operate old hardware, > software emulation of past hardware and software systems, and data > recovery from newly discovered, but previously thought to be lost, > archives. > > I came across an article today about another major industry that has > been exceedingly careless about preserving its history: > > Wipe Out: When the BBC Kept Erasing Its Own History > https://getpocket.com/explore/item/wipe-out-when-the-bbc-kept-erasing-its-own-history > > It is a must-read for Dr Who fans on this list. > > ------------------------------------------------------------------------------- > - Nelson H. F. Beebe Tel: +1 801 581 5254 - > - University of Utah FAX: +1 801 581 4148 - > - Department of Mathematics, 110 LCB Internet e-mail: beebe at math.utah.edu - > - 155 S 1400 E RM 233 beebe at acm.org beebe at computer.org - > - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - > ------------------------------------------------------------------------------- From ggm at algebras.org Tue Sep 17 08:33:29 2019 From: ggm at algebras.org (George Michaelson) Date: Tue, 17 Sep 2019 08:33:29 +1000 Subject: [TUHS] INed/Rand Editor/Ned [was Re: My EuroBSDcon talk (preview for commentary) In-Reply-To: <201909162047.x8GKlSbX001635@darkstar.fourwinds.com> References: <20190915232524.9A5491570CE9@mail.bitblocks.com> <7F62BF6B-8FEA-4C43-9E35-05BDE9BF04EA@ccc.com> <20190916023738.F34E81570CE9@mail.bitblocks.com> <20190916202153.wbpzx3jn3a7rs6kb@localhost.localdomain> <201909162047.x8GKlSbX001635@darkstar.fourwinds.com> Message-ID: On Tue, Sep 17, 2019 at 6:47 AM Jon Steinhart wrote: > > Since we like debating the merits of old technology, somebody can kick off > a termcap versus terminfo discussion :-) > Felt like of-its-time NIH. Since the codes to drive an ADM5 were the same in either source, and since the intent was the same, it was just a giant *why* for me. I didn't get why binary file either. If the cost of reading the termcap DB was a significant hit on your program, I think you just proved you were a robot and would be defeated by a captcha. Having to compile things is a drag. It was probably a side effect of the sequence of universities and institutions I worked at (York, Leeds, York, UCL, CSIRO, UQ) that they were almost exclusively v7->32V->BSD->SunOS shops and so the emergence of SYSV was basically occluded to me, and so SYSV-isms (with the exception of RFS and the pre-gnu getopt() which leaked into UUCP newsgroups I read somehow). Terminfo just didn't feel very *relevant* From reed at reedmedia.net Tue Sep 17 08:33:58 2019 From: reed at reedmedia.net (reed at reedmedia.net) Date: Mon, 16 Sep 2019 17:33:58 -0500 (CDT) Subject: [TUHS] earliest Unix roff In-Reply-To: References: <201909132024.x8DKObEP013266@darkstar.fourwinds.com> <463d5cc4-9bef-9ac3-a680-a5161d664dc1@aueb.gr> <20190913221345.GA16129@minnie.tuhs.org> <20190914020240.GO2046@mcvoy.com> <20190914024433.GA19193@minnie.tuhs.org> <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org> <201909150654.x8F6sChG021185@freefriends.org> <201909160552.x8G5qBYK025195@freefriends.org> <7wd0g0o2a0.fsf@junk.nocrew.org> Message-ID: > Am I the only one who remembers the old "pg" program? It seems to have > disappeared. I see two different pg. One in the 32V sources and the other first Usenix delaware collection. (Both in TUHS archives) Another pager "cr3" is in 1BSD collection (which was replaced by Halbert's more in 3BSD). From dave at horsfall.org Tue Sep 17 08:35:46 2019 From: dave at horsfall.org (Dave Horsfall) Date: Tue, 17 Sep 2019 08:35:46 +1000 (EST) Subject: [TUHS] earliest Unix roff In-Reply-To: References: <20190913221345.GA16129@minnie.tuhs.org> <20190914020240.GO2046@mcvoy.com> <20190914024433.GA19193@minnie.tuhs.org> <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org> <201909150654.x8F6sChG021185@freefriends.org> <201909160552.x8G5qBYK025195@freefriends.org> <20190916145122.GH2046@mcvoy.com> Message-ID: On Mon, 16 Sep 2019, Clem Cole wrote: > > If you have something like perl that needs a zillion sub pages, > > info makes sense.  For just a man page, info is horrible. > > I'm not even sure, I like that, to be honest. I'm 'old school' enough to > rather use a book from ORA or the like.  Or use www.perltutorial.org which is a good resource; I often get stuck on the finer points of Perl, such as the OO stuff. -- Dave From g.branden.robinson at gmail.com Tue Sep 17 08:48:28 2019 From: g.branden.robinson at gmail.com (G. Branden Robinson) Date: Tue, 17 Sep 2019 08:48:28 +1000 Subject: [TUHS] better ways and termcap vs. terminfo for commentary) In-Reply-To: <201909162047.x8GKlSbX001635@darkstar.fourwinds.com> References: <20190915232524.9A5491570CE9@mail.bitblocks.com> <7F62BF6B-8FEA-4C43-9E35-05BDE9BF04EA@ccc.com> <20190916023738.F34E81570CE9@mail.bitblocks.com> <20190916202153.wbpzx3jn3a7rs6kb@localhost.localdomain> <201909162047.x8GKlSbX001635@darkstar.fourwinds.com> Message-ID: <20190916224825.keswxb7sh224tpky@localhost.localdomain> At 2019-09-16T13:47:27-0700, Jon Steinhart wrote: > G. Branden Robinson writes: > > _info_nol "> \033[46m\033[30mSTATUS:\033[0m " > > > > Why write something portable when you can be "close to the metal"? :-/ > > > > I gently steer people to better ways when the occasion presents itself. [...] > > We can have an interesting discussion of the definition of "better ways". Here I think we have a layering violation. Why on earth would a CPU microarchitectural flaw detector need to know or care about the details terminal control sequences? _Anything_ that provides an abstraction of the terminal is an improvement on the above. > I see termcap as a great solution for the days in which there was > little standardization. Setting aside the specificity of "termcap", sure. Something was needed to gather up the absurd efflorescence of implementation details among hardware terminals and present programmers (and users struggling to interact with the system) something simpler and more intention-oriented. You want "bold, if the device can do it", not a giant switch statement encompassing '\033[1m', '\033ya', '\033yA', '\033<', '\2331m', '\033[1m' with a parameter after it, '\033[7m', \033[=15F', ... And if the device _can't_ do bold, you want to be able to decide for yourself whether you don't care if the boldness is left out, or be able to query that interface layer about it and program your own fallback (use indentation, full capitalization, an "IMPORTANT:" prefix, etc.) in the event the capability is absent. > But it's probably pretty hard to find a non-conforming terminal > nowadays so I think that it's better to avoid obfuscation. I've attached an example of the sort of thing I do. It has a lot of comments, so is inappropriate for inlining on a list full of Unix grognards. ;-) > Were it me I would have a comment that referenced the page and section > number in the standard. This is a good idea, but its benefit can be limited for ISO standards, which are often paywalled. In this case the controlling standard is ISO 6429. Fortunately it's largely parallel to ECMA-48 which is freely available. In this case you want ECMA-48, pp. 61-63[1]. > Since we like debating the merits of old technology, somebody can kick > off a termcap versus terminfo discussion :-) terminfo is better than termcap in the same way that Fortran 77 is better than Microsoft BASIC for 8-bit microcomputers--identifier length. Fortran 77, 6 characters. MS BASIC, 2. termcap, 2. terminfo, 5. Of course, that argument could be turned around rather precisely for those who prize "terseness". I reckon one of the reasons that function names in the Unix kernel were allowed to grow as long as they did--while still being limited to 6 characters for linkage reasons--was because the precious space of 1- and 2-letter external identifiers was held sacrosanct for user programs. There but for that grace would 'swtch()' have gone as 'sw()', and 'creat()' as 'cr()', perhaps. No such considerations availed in the namespace for executable programs. ;-) Regards, Branden [1] https://www.ecma-international.org/publications/files/ECMA-ST/Ecma-048.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: example.sh Type: application/x-sh Size: 1962 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From g.branden.robinson at gmail.com Tue Sep 17 09:14:02 2019 From: g.branden.robinson at gmail.com (G. Branden Robinson) Date: Tue, 17 Sep 2019 09:14:02 +1000 Subject: [TUHS] INed/Rand Editor/Ned [was Re: My EuroBSDcon talk (preview for commentary) In-Reply-To: References: <7F62BF6B-8FEA-4C43-9E35-05BDE9BF04EA@ccc.com> <20190916023738.F34E81570CE9@mail.bitblocks.com> <20190916202153.wbpzx3jn3a7rs6kb@localhost.localdomain> <201909162047.x8GKlSbX001635@darkstar.fourwinds.com> Message-ID: <20190916231359.bnbefaceyvecglwc@localhost.localdomain> At 2019-09-17T08:33:29+1000, George Michaelson wrote: > On Tue, Sep 17, 2019 at 6:47 AM Jon Steinhart wrote: > > > > Since we like debating the merits of old technology, somebody can kick off > > a termcap versus terminfo discussion :-) > > > > Felt like of-its-time NIH. I certainly would not defend USG on those grounds. Many poor decisions seem to have been taken in the name of attempting to gain a commercial advantage, or of an effort to present the industry with a fait accompli that you just HAD to go along with and therefore HAD to fork over a license fee. This is only my impression from reading histories and retrospectives; I came of age just as the Unix wars were winding down and Microsoft showed that they were the most competitive at being anti-competitive. > Since the codes to drive an ADM5 were the same in either source, and > since the intent was the same, it was just a giant *why* for me. For me, the mnemonic value of the capability names is important, though terminfo didn't leverage that advantage nearly as much as they could and should have. 5 characters was better than 2 but still too short. And in many cases they just reused the termcap capability names as-is, e.g., 'am', 'll'. But one example is enough to point up the advantage. By what name do you look up the "bold" capability? In terminfo, it's called...'bold'. In termcap, what's your bet? 'bd'? Nope. 'bo'? Nope. 'md'. > I didn't get why binary file either. If the cost of reading the > termcap DB was a significant hit on your program, I think you just > proved you were a robot and would be defeated by a captcha. Having to > compile things is a drag. This is an implementation detail that _should_ have been transparent to the user. No one should have needed to care what the on-disk or in-memory representation of the terminal capability list was. But...it was the '80s. My guess is that encapsulation to that degree smacked of object-orientation, possibly, and therefore was always going to be a performance disaster, the same way no one was ever going to need more than 640KiB or how microkernels were always going to be slow at context-switching. Or maybe it just came down to lazy implementation. > It was probably a side effect of the sequence of universities and > institutions I worked at (York, Leeds, York, UCL, CSIRO, UQ) that they > were almost exclusively v7->32V->BSD->SunOS shops and so the emergence > of SYSV was basically occluded to me, and so SYSV-isms (with the > exception of RFS and the pre-gnu getopt() which leaked into UUCP > newsgroups I read somehow). > > Terminfo just didn't feel very *relevant* Yes--what good ideas AT&T commercial Unix had, they seemed determined to ensure people never found out about except via capture of standards bodies followed by mandatory licensing. To me this would explain the reasoning behind the Sun/AT&T corrupt bargain that led to Solaris (of which Larry has written here). People were enthusiastic about SunOS. Obviously the thing to do with such an enthusiastic user base is buy access to it and force them to eat whatever you feed them. They will remin your thralls and sing your praises for free, because all consumer preferences are ultimately mindless questions of fashion. Worked brilliantly, didn't it? It can. If you're Steve Jobs. Regards, Branden -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From dave at horsfall.org Tue Sep 17 09:24:40 2019 From: dave at horsfall.org (Dave Horsfall) Date: Tue, 17 Sep 2019 09:24:40 +1000 (EST) Subject: [TUHS] earliest Unix roff In-Reply-To: <2d65ed3d-87a6-e3f4-7917-9611b631a100@case.edu> References: <201909160552.x8G5qBYK025195@freefriends.org> <20190916145122.GH2046@mcvoy.com> <20190916161040.GM2046@mcvoy.com> <201909161616.x8GGG4Fb020760@darkstar.fourwinds.com> <20190916162614.GO2046@mcvoy.com> <20190916164502.GQ2046@mcvoy.com> <20190916171905.piituc2qdh46kejt@unixfarts.net> <2d65ed3d-87a6-e3f4-7917-9611b631a100@case.edu> Message-ID: On Mon, 16 Sep 2019, Chet Ramey wrote: > Bash comes with both a large man page and an extensive info doc. On my (obsolete) FreeBSD box: aneurin% man bash | wc -l 5947 Now there's a manpage that should have been split up... On the same box: aneurin% man zsh | wc -l 346 That's because it's got sub-pages, each describing a particular feature (I've been using ZSH for years). -- Dave From dave at horsfall.org Tue Sep 17 09:44:03 2019 From: dave at horsfall.org (Dave Horsfall) Date: Tue, 17 Sep 2019 09:44:03 +1000 (EST) Subject: [TUHS] [tuhs] Computer history preservation In-Reply-To: References: Message-ID: On Mon, 16 Sep 2019, Nelson H. F. Beebe wrote: [...] > I came across an article today about another major industry that has > been exceedingly careless about preserving its history: > > Wipe Out: When the BBC Kept Erasing Its Own History > https://getpocket.com/explore/item/wipe-out-when-the-bbc-kept-erasing-its-own-history > > It is a must-read for Dr Who fans on this list. Indeed; quite shameful, really. -- Dave From cym224 at gmail.com Tue Sep 17 10:02:57 2019 From: cym224 at gmail.com (Nemo Nusquam) Date: Mon, 16 Sep 2019 20:02:57 -0400 Subject: [TUHS] earliest Unix roff In-Reply-To: References: <201909132024.x8DKObEP013266@darkstar.fourwinds.com> <463d5cc4-9bef-9ac3-a680-a5161d664dc1@aueb.gr> <20190913221345.GA16129@minnie.tuhs.org> <20190914020240.GO2046@mcvoy.com> <20190914024433.GA19193@minnie.tuhs.org> <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org> <201909150654.x8F6sChG021185@freefriends.org> <201909160552.x8G5qBYK025195@freefriends.org> <7wd0g0o2a0.fsf@junk.nocrew.org> Message-ID: On 09/16/19 18:05, Dave Horsfall wrote: > Am I the only one who remembers the old "pg" program? It seems to have > disappeared. Still ships with Solaris (in /usr/bin). N. From dave at horsfall.org Tue Sep 17 10:11:20 2019 From: dave at horsfall.org (Dave Horsfall) Date: Tue, 17 Sep 2019 10:11:20 +1000 (EST) Subject: [TUHS] earliest Unix roff In-Reply-To: References: <463d5cc4-9bef-9ac3-a680-a5161d664dc1@aueb.gr> <20190913221345.GA16129@minnie.tuhs.org> <20190914020240.GO2046@mcvoy.com> <20190914024433.GA19193@minnie.tuhs.org> <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org> <201909150654.x8F6sChG021185@freefriends.org> <201909160552.x8G5qBYK025195@freefriends.org> <7wd0g0o2a0.fsf@junk.nocrew.org> Message-ID: On Mon, 16 Sep 2019, reed at reedmedia.net wrote: >> Am I the only one who remembers the old "pg" program? It seems to have >> disappeared. > > I see two different pg. One in the 32V sources and the other first > Usenix delaware collection. (Both in TUHS archives) We never ran 32V; our Vaxen - called "vaxa" and "vaxb" - ran VMS... I was only in charge of the Unix PDP-11/40s sprinkled around the place (and the odd /34 and /23). -- Dave From grog at lemis.com Tue Sep 17 10:10:56 2019 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Tue, 17 Sep 2019 10:10:56 +1000 Subject: [TUHS] O'Reilly groff macros (was: earliest Unix roff) In-Reply-To: <201909160620.x8G6KkJq026850@freefriends.org> References: <463d5cc4-9bef-9ac3-a680-a5161d664dc1@aueb.gr> <20190913221345.GA16129@minnie.tuhs.org> <20190914020240.GO2046@mcvoy.com> <20190914024433.GA19193@minnie.tuhs.org> <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org> <069494b2-ec5b-91e7-8618-2d111e0e5aa2@andrewnesbit.org> <201909160620.x8G6KkJq026850@freefriends.org> Message-ID: <20190917001056.GD31311@eureka.lemis.com> On Monday, 16 September 2019 at 0:20:46 -0600, arnold at skeeve.com wrote: >> 1. Do you think there is any chance of obtaining these macro packages? >> Either from authors who haven't passed away, or from the publishing >> houses themselves? > > O'Reilly probably would. I can ask someone there, if there's serious > interest here. They haven't used troff for book production for well > over a decade. The O'Reilly macro package was derived from the macros described in Dougherty and O'Reilly "UNIX Text Processing" (Hayden 1988). I received a copy round 1993 for my book "Porting UNIX Software" (didn't we shout in those days?), and when we released the book under Creative Commons in 2005 or so, the macros were released with it. It's available online as http://www.lemis.com/grog/Documentation/PUS/tmac.Gbignuts.G In passing I should mention that they required me to use those macros. At the time I wanted to use TeX, but they were "unwilling". I used groff, and I've never used TeX since: a dead baby duck. Greg -- Sent from my desktop computer. Finger grog at lemis.com for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft mail program reports problems, please read http://lemis.com/broken-MUA -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 163 bytes Desc: not available URL: From grog at lemis.com Tue Sep 17 10:16:55 2019 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Tue, 17 Sep 2019 10:16:55 +1000 Subject: [TUHS] earliest Unix roff In-Reply-To: References: <20190913221345.GA16129@minnie.tuhs.org> <20190914020240.GO2046@mcvoy.com> <20190914024433.GA19193@minnie.tuhs.org> <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org> <201909150654.x8F6sChG021185@freefriends.org> <201909160552.x8G5qBYK025195@freefriends.org> Message-ID: <20190917001655.GE31311@eureka.lemis.com> On Tuesday, 17 September 2019 at 7:42:28 +1000, Dave Horsfall wrote: > On Mon, 16 Sep 2019, Clem Cole wrote: > >> Fair enough, but be careful, while I admit I have not looked in a while, >> info(gnu) relies on emacs keybindings and a number of very >> emacs'ish things. Every time I have tried to deal with it, I have >> unprogram my fingers and reset them to emacs. > > Yep, which is why I like "info" as much as I like EMACS i.e. not at > all. Maybe I've missed something, but I'm in the intermediate camp. Emacs is in my fingertips, and I wouldn't want to live without it, but I'd far rather see info go away. In some ways it anticipated HTML, but I find navigation particularly painful. > What exactly is wrong with the manpage format? It's linear. > It tells you everything you need to know, and tells you where to > find further information. Yes, but you need to follow the link manually. Theoretically a good HTML document would be better, but it's nice to have a linear form that you can search. For an extreme case of man pages, look at something like mplayer(1) or mpv(1): $ man mplayer|wc -l 9435 $ man mpv|wc -l 13939 That doesn't make them easy to read. 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 doug at cs.dartmouth.edu Tue Sep 17 10:20:32 2019 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Mon, 16 Sep 2019 20:20:32 -0400 Subject: [TUHS] block operations in editors, was My EuroBSDcon talk Message-ID: <201909170020.x8H0KWC6037690@tahoe.cs.Dartmouth.EDU> > The "block copy in an editor" thing is something which has intrigued > me for years. poor old ed/ex/vi just couldn't do it, and for the life > of me, I could not understand why this was "deprecated" by the people > writing that family of editors. One might trace it to the founding tenet that a file is a stream of bytes, reinforced by the absence of multidemensional arrays in C. But it goes deeper than that. Ed imposes a structure, making a (finite) file into an array, aka list, of lines. It's easy to define block moves and copies in a list. But what are the semantics of a block move, wherein one treats the list as a ragged-right 2D array? What gets pushed aside? In what direction? How does a block move into column that not all destination rows reach? How do you cope when the bottom gets ragged? How about the top? Can one move blocks of tab-separated fields? I think everyone has rued the lack of block operations at one time or another. But implementing them in any degree of generality is a stumbling block. What should the semantics be? > Similarly the 'repeat this sequence of commands' thing which emacs had. Ed's g command does that, except the sequence can't contain another g. Sam, barely harder than ed to learn, cures that deficiency and generalizes in other ways, too--but has no block operations. Doug From krewat at kilonet.net Tue Sep 17 10:21:43 2019 From: krewat at kilonet.net (Arthur Krewat) Date: Mon, 16 Sep 2019 20:21:43 -0400 Subject: [TUHS] earliest Unix roff In-Reply-To: References: <463d5cc4-9bef-9ac3-a680-a5161d664dc1@aueb.gr> <20190913221345.GA16129@minnie.tuhs.org> <20190914020240.GO2046@mcvoy.com> <20190914024433.GA19193@minnie.tuhs.org> <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org> <201909150654.x8F6sChG021185@freefriends.org> <201909160552.x8G5qBYK025195@freefriends.org> <7wd0g0o2a0.fsf@junk.nocrew.org> Message-ID: <32b57278-31c8-0dd2-38fb-87d80ee990a2@kilonet.net> On 9/16/2019 8:02 PM, Nemo Nusquam wrote: > On 09/16/19 18:05, Dave Horsfall wrote: >> Am I the only one who remembers the old "pg" program? It seems to have >> disappeared. > > Still ships with Solaris (in /usr/bin). Now you've gone and said a bad word... ;) art k. From peter at rulingia.com Tue Sep 17 10:28:25 2019 From: peter at rulingia.com (Peter Jeremy) Date: Tue, 17 Sep 2019 10:28:25 +1000 Subject: [TUHS] [tuhs] Computer history preservation In-Reply-To: References: Message-ID: <20190917002825.GA15016@server.rulingia.com> On 2019-Sep-16 15:48:36 -0600, "Nelson H. F. Beebe" wrote: >I came across an article today about another major industry that has >been exceedingly careless about preserving its history: > > Wipe Out: When the BBC Kept Erasing Its Own History > https://getpocket.com/explore/item/wipe-out-when-the-bbc-kept-erasing-its-own-history > >It is a must-read for Dr Who fans on this list. It didn't only affect TV, much of The Goons originals were also destroyed (at least one episode now sold by the BBC is an off-air recording by a fan because that's the best extant copy). And NASA destroyed the tapes holding the original Apollo 11 moonwalk (https://en.wikipedia.org/wiki/Apollo_11_missing_tapes). -- Peter Jeremy -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 963 bytes Desc: not available URL: From scj at yaccman.com Tue Sep 17 10:20:12 2019 From: scj at yaccman.com (Steve Johnson) Date: Mon, 16 Sep 2019 17:20:12 -0700 Subject: [TUHS] earliest Unix roff In-Reply-To: <201909152207.x8FM7BiA017274@tahoe.cs.Dartmouth.EDU> Message-ID: Dennis had a model 37 on his sunporch for years.  The innards were nearly all mechanical -- cams and levers, etc.  And as the years went by, wear and tear made the thing shake when it was being used.   From time to time, it would shake so much that a space would be added into whatever you were typing. I think Dennis finally retired it after he typed the command "rm *.o"  (a common command in those days of small discs), and got the respnse ".o not found" The model37 used fan-fold paper, that we got by the box.  It was an art to arrange the paper flow so that the output didn't pile up inside the box of blank paper, but rather ended up in a pile on the floor. In this era, Unix would, from time to time, crash unexpectedly, causing you to lose all the edits you hadn't written out yet.  The drill in that case was to gather up the paper with all your typing on it, and, with a highlighter, highlight the stuff you needed to retype when the system came up. One day I had been furiously editing a long program file for about an hour and a half when I was called away to lunch, and, being hungry, didn't save my file.  When I got back to the terminal an hour later, I discovered two things -- the system had crashed, and our cat had decided that the pile of paper on the floor made a great litter box.  After a few choice words, I sighed and picked up my highliter... Steve ----- Original Message ----- From: "Doug McIlroy" To: Cc: Sent:Sun, 15 Sep 2019 18:07:11 -0400 Subject:Re: [TUHS] earliest Unix roff > Excellent - thanks for the pointer. This shows nroff before troff. > FWIW: I guess I was miss informed, but I had been under the impression > that was the other way around. i.e. nroff was done to be compliant with > the new troff, replacing roff, although the suggestion here is that he > wrote it add macros to roff. I'll note that either way, the dates are all > possible of course because the U/L case ASR 37 was introduced 1968 so by > the early 1970's they would have been around the labs. nroff was in v2; troff appeared in v4, which incidentally was typeset in troff. Because of Joe Ossanna's role in designing the model 37, we had 37's in the Labs and even in our homes right from the start of production. But when they went obsolete, they were a chore to get rid of. As Labs property, they had to be returned; and picking them up was nobody's priority. Andy Hall had one on his back porch for a year. Doug -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon at fourwinds.com Tue Sep 17 10:31:33 2019 From: jon at fourwinds.com (Jon Steinhart) Date: Mon, 16 Sep 2019 17:31:33 -0700 Subject: [TUHS] earliest Unix roff In-Reply-To: <20190917001655.GE31311@eureka.lemis.com> References: <20190913221345.GA16129@minnie.tuhs.org> <20190914020240.GO2046@mcvoy.com> <20190914024433.GA19193@minnie.tuhs.org> <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org> <201909150654.x8F6sChG021185@freefriends.org> <201909160552.x8G5qBYK025195@freefriends.org> <20190917001655.GE31311@eureka.lemis.com> Message-ID: <201909170031.x8H0VcYE032303@darkstar.fourwinds.com> Greg 'groggy' Lehey writes: > > Yes, but you need to follow the link manually. Theoretically a good > HTML document would be better, but it's nice to have a linear form > that you can search. Isn't "good HTML document" an oxymoron? From g.branden.robinson at gmail.com Tue Sep 17 10:42:36 2019 From: g.branden.robinson at gmail.com (G. Branden Robinson) Date: Tue, 17 Sep 2019 10:42:36 +1000 Subject: [TUHS] block operations in editors, was My EuroBSDcon talk In-Reply-To: <201909170020.x8H0KWC6037690@tahoe.cs.Dartmouth.EDU> References: <201909170020.x8H0KWC6037690@tahoe.cs.Dartmouth.EDU> Message-ID: <20190917004233.4cgn6vabnmgwl5q5@localhost.localdomain> At 2019-09-16T20:20:32-0400, Doug McIlroy wrote: > Ed imposes a structure, making a (finite) file into an array, aka > list, of lines. It's easy to define block moves and copies in a list. > But what are the semantics of a block move, wherein one treats the > list as a ragged-right 2D array? What gets pushed aside? In what > direction? How does a block move into column that not all destination > rows reach? How do you cope when the bottom gets ragged? How about the > top? Can one move blocks of tab-separated fields? > > I think everyone has rued the lack of block operations at one time or > another. But implementing them in any degree of generality is a > stumbling block. What should the semantics be? Just in case anyone didn't know, Vim has what it calls "visual block" highlighting and operations. CTRL-V begins one and you use the usual movement keys to shape and size it, then an operator like (y)ank or (d)elete. It won't always work as one expects because of the very questions that Doug raises above. Vim also has characterwise blocks (begin with 'v') and linewise blocks (begin with 'V'). The last is, more than any other single factor, what pulled me over from traditional vi (really nvi in my case). It was a big win over line-counting with ":.,+n" expressions. In retrospect I should have been smarter and just typed ":.,/pattern/", using as /pattern/ some short string that did not appear in any of the lines I wanted to operate on. Though the vi clone with the best name was, indisputably, elvis. Regards, Branden -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From clemc at ccc.com Tue Sep 17 10:46:20 2019 From: clemc at ccc.com (Clem Cole) Date: Mon, 16 Sep 2019 20:46:20 -0400 Subject: [TUHS] earliest Unix roff In-Reply-To: References: <201909132024.x8DKObEP013266@darkstar.fourwinds.com> <463d5cc4-9bef-9ac3-a680-a5161d664dc1@aueb.gr> <20190913221345.GA16129@minnie.tuhs.org> <20190914020240.GO2046@mcvoy.com> <20190914024433.GA19193@minnie.tuhs.org> <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org> <201909150654.x8F6sChG021185@freefriends.org> <201909160552.x8G5qBYK025195@freefriends.org> <7wd0g0o2a0.fsf@junk.nocrew.org> Message-ID: The USG pg program was created after UCB released more. Btw this was before vi or csh was distributed. But too many BTL folks had seen BSD during there OYOC year and either demanded it or had brought what was in effect 2BSD back with them. On Mon, Sep 16, 2019 at 6:06 PM Dave Horsfall wrote: > On Mon, 16 Sep 2019, Clem Cole wrote: > > > > However, please note that more(1) also was inspired by, almost > > > copied from, ITS. Certainly the prompt --More-- is. > > > > Absolutely. A friend of mine/fellow UCB grad student, Eric Shienbrood, > > wrote it. He was a MIT undergrad. And Eric happily said it was modeled > > from ITS. And before, Eric wrote it, UNIX lacked anything like it. > > Which to me is fine, taking an idea from another system to add a new > > feature that is lacking. > > Am I the only one who remembers the old "pg" program? It seems to have > disappeared. > > -- Dave -- Sent from a handheld expect more typos than usual -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Tue Sep 17 10:51:54 2019 From: clemc at ccc.com (Clem Cole) Date: Mon, 16 Sep 2019 20:51:54 -0400 Subject: [TUHS] O'Reilly groff macros (was: earliest Unix roff) In-Reply-To: <20190917001056.GD31311@eureka.lemis.com> References: <463d5cc4-9bef-9ac3-a680-a5161d664dc1@aueb.gr> <20190913221345.GA16129@minnie.tuhs.org> <20190914020240.GO2046@mcvoy.com> <20190914024433.GA19193@minnie.tuhs.org> <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org> <069494b2-ec5b-91e7-8618-2d111e0e5aa2@andrewnesbit.org> <201909160620.x8G6KkJq026850@freefriends.org> <20190917001056.GD31311@eureka.lemis.com> Message-ID: FYI Which Dale and Tim used at Masscomp 4 years earlier. That book was originally modeled from Janet Eagans style guide which I still have. On Mon, Sep 16, 2019 at 8:11 PM Greg 'groggy' Lehey wrote: > On Monday, 16 September 2019 at 0:20:46 -0600, arnold at skeeve.com wrote: > >> 1. Do you think there is any chance of obtaining these macro packages? > >> Either from authors who haven't passed away, or from the publishing > >> houses themselves? > > > > O'Reilly probably would. I can ask someone there, if there's serious > > interest here. They haven't used troff for book production for well > > over a decade. > > The O'Reilly macro package was derived from the macros described in > Dougherty and O'Reilly "UNIX Text Processing" (Hayden 1988). I > received a copy round 1993 for my book "Porting UNIX Software" (didn't > we shout in those days?), and when we released the book under Creative > Commons in 2005 or so, the macros were released with it. It's > available online as > http://www.lemis.com/grog/Documentation/PUS/tmac.Gbignuts.G > > In passing I should mention that they required me to use those > macros. At the time I wanted to use TeX, but they were "unwilling". > I used groff, and I've never used TeX since: a dead baby duck. > > 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 > -- Sent from a handheld expect more typos than usual -------------- next part -------------- An HTML attachment was scrubbed... URL: From ullbeking at andrewnesbit.org Tue Sep 17 10:54:21 2019 From: ullbeking at andrewnesbit.org (U'll Be King of the Stars) Date: Tue, 17 Sep 2019 01:54:21 +0100 Subject: [TUHS] O'Reilly groff macros In-Reply-To: References: <463d5cc4-9bef-9ac3-a680-a5161d664dc1@aueb.gr> <20190913221345.GA16129@minnie.tuhs.org> <20190914020240.GO2046@mcvoy.com> <20190914024433.GA19193@minnie.tuhs.org> <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org> <069494b2-ec5b-91e7-8618-2d111e0e5aa2@andrewnesbit.org> <201909160620.x8G6KkJq026850@freefriends.org> <20190917001056.GD31311@eureka.lemis.com> Message-ID: <498796af-156b-65e0-374d-38afd95c0968@andrewnesbit.org> On 17/09/2019 01:51, Clem Cole wrote: > FYI Which Dale and Tim used at Masscomp  4 years earlier.  That book was > originally modeled from Janet Eagans style guide which I still have. I LOVE style guides. I have a bit of a thing for them. Was the Eagans guide published? (Andrew shuffles off to Amazon.) Andrew -- OpenPGP key: EB28 0338 28B7 19DA DAB0 B193 D21D 996E 883B E5B9 From clemc at ccc.com Tue Sep 17 11:03:40 2019 From: clemc at ccc.com (Clem Cole) Date: Mon, 16 Sep 2019 21:03:40 -0400 Subject: [TUHS] O'Reilly groff macros In-Reply-To: <498796af-156b-65e0-374d-38afd95c0968@andrewnesbit.org> References: <463d5cc4-9bef-9ac3-a680-a5161d664dc1@aueb.gr> <20190913221345.GA16129@minnie.tuhs.org> <20190914020240.GO2046@mcvoy.com> <20190914024433.GA19193@minnie.tuhs.org> <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org> <069494b2-ec5b-91e7-8618-2d111e0e5aa2@andrewnesbit.org> <201909160620.x8G6KkJq026850@freefriends.org> <20190917001056.GD31311@eureka.lemis.com> <498796af-156b-65e0-374d-38afd95c0968@andrewnesbit.org> Message-ID: No. It was given to all the Masscomp writers and of course all of Tims at the beginning since we were his primary client in those days. He had not yet done the X11 books which was what made Tim’s business. On Mon, Sep 16, 2019 at 8:54 PM U'll Be King of the Stars < ullbeking at andrewnesbit.org> wrote: > On 17/09/2019 01:51, Clem Cole wrote: > > FYI Which Dale and Tim used at Masscomp 4 years earlier. That book was > > originally modeled from Janet Eagans style guide which I still have. > > I LOVE style guides. I have a bit of a thing for them. > > Was the Eagans guide published? (Andrew shuffles off to Amazon.) > > Andrew > -- > OpenPGP key: EB28 0338 28B7 19DA DAB0 B193 D21D 996E 883B E5B9 > -- Sent from a handheld expect more typos than usual -------------- next part -------------- An HTML attachment was scrubbed... URL: From krewat at kilonet.net Tue Sep 17 11:11:17 2019 From: krewat at kilonet.net (Arthur Krewat) Date: Mon, 16 Sep 2019 21:11:17 -0400 Subject: [TUHS] earliest Unix roff In-Reply-To: References: Message-ID: <0bc0d10f-d17c-24df-2a7f-8f154eefd318@kilonet.net> On 9/16/2019 8:20 PM, Steve Johnson wrote: > One day I had been furiously editing a long program file for about an > hour and a half when I was called away to lunch, and, being hungry, > didn't save > my file.  When I got back to the terminal an hour later, I discovered > two things -- the system had crashed, and our cat had decided that the > pile of paper > on the floor made a great litter box.  After a few choice words, I > sighed and picked up my highliter... This should be engraved on a plaque somewhere. Only because I had almost the same thing happen to me, without the cat though. I had a printout of a "mail" program I had written on TOPS-10 at high school. I had to retype the entire thing after the file got corrupted. Yay MACRO-10 From ron at ronnatalie.com Tue Sep 17 11:11:59 2019 From: ron at ronnatalie.com (Ronald Natalie) Date: Mon, 16 Sep 2019 21:11:59 -0400 Subject: [TUHS] Model 37's In-Reply-To: References: Message-ID: <77060A04-696A-4789-A63A-D7A725B5AA63@ronnatalie.com> Hopkins had a KSR37 in a small office (or perhaps closet) on the second floor. It was also fitted with a modem I built (a Pennywhistle, an absolutely abhorrant design). It had the greek box and we used it for many a nroff term paper or the like. It was also our way of getting on the Arpanet. The university had a “tie line” that let us call the DC metro area so we could get into the Pentagon TIP. However, Mike Muuss also convinced the operator once to place a collect call. “It’s a computer we are calling,” he told her. “If it beeps, it accepts the charges.” (This was perhaps one of the boldest operator hacks until Brian Redman and Peter Langston were screwing around with a phone switch and programmed it to answer the phone: “Bell Communications Research” (long pause) “Yes, Operator! I’ll accept the charges.” After I graduated from JHU, I found an ASR 37 in a surplus sale. I had it for years in my apartment kitchen. Not only did it handle all the nroff ESC-8/ESC-9 stuff and the like without need for an output filter, it had a giant NEWLINE key on the right side and was perhaps the only terminal I ever used that didn’t need the unix NL->CRLF mapping turned on. Amusingly, the thing sat there idle until DSR came up on the modem and then its motors would start. When CD came on a bright green PROCEED light illuminated on the front of it. I used it for years until modems got up to the 9600 baud range and decided a CRT would be nicer than the printing terminal. I gave mine to RS who I think used it to block in someone’s car at one of the nacent long distance data carriers (was either Sprint or MCI). From lm at mcvoy.com Tue Sep 17 11:17:52 2019 From: lm at mcvoy.com (Larry McVoy) Date: Mon, 16 Sep 2019 18:17:52 -0700 Subject: [TUHS] earliest Unix roff In-Reply-To: <0bc0d10f-d17c-24df-2a7f-8f154eefd318@kilonet.net> References: <0bc0d10f-d17c-24df-2a7f-8f154eefd318@kilonet.net> Message-ID: <20190917011752.GY2046@mcvoy.com> On Mon, Sep 16, 2019 at 09:11:17PM -0400, Arthur Krewat wrote: > On 9/16/2019 8:20 PM, Steve Johnson wrote: > >One day I had been furiously editing a long program file for about an hour > >and a half when I was called away to lunch, and, being hungry, didn't save > >my file.?? When I got back to the terminal an hour later, I discovered two > >things -- the system had crashed, and our cat had decided that the pile of > >paper > >on the floor made a great litter box.?? After a few choice words, I sighed > >and picked up my highliter... > > This should be engraved on a plaque somewhere. Only because I had almost the > same thing happen to me, without the cat though. I had a printout of a > "mail" program I had written on TOPS-10 at high school. I had to retype the > entire thing after the file got corrupted. I think we have all been there. Something always goes wrong. I wrote a paper about how to restore a Masscomp because I did rm -rf . in /. I believe we had roots home as / because /usr was a different partition. Clem, did Masscomp make roots home / or was that us? Anyway, I did a cd something and somehow deleted the something and then did rm -rf . Much fun was had, I was up all night putting things back together. This was probably around 1984 or 1985, I was pretty green. From bakul at bitblocks.com Tue Sep 17 11:19:15 2019 From: bakul at bitblocks.com (Bakul Shah) Date: Mon, 16 Sep 2019 18:19:15 -0700 Subject: [TUHS] earliest Unix roff In-Reply-To: References: Message-ID: <9E4D392E-DB0B-45E6-9B97-02469DCCC590@bitblocks.com> The one time you didn't want any cat output.... > On Sep 16, 2019, at 5:20 PM, Steve Johnson wrote: > > One day I had been furiously editing a long program file for about an hour and a half when I was called away to lunch, and, being hungry, didn't save > my file. When I got back to the terminal an hour later, I discovered two things -- the system had crashed, and our cat had decided that the pile of paper > on the floor made a great litter box. After a few choice words, I sighed and picked up my highliter... > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bakul at bitblocks.com Tue Sep 17 11:25:39 2019 From: bakul at bitblocks.com (Bakul Shah) Date: Mon, 16 Sep 2019 18:25:39 -0700 Subject: [TUHS] block operations in editors, was My EuroBSDcon talk In-Reply-To: Your message of "Mon, 16 Sep 2019 20:20:32 -0400." <201909170020.x8H0KWC6037690@tahoe.cs.Dartmouth.EDU> References: <201909170020.x8H0KWC6037690@tahoe.cs.Dartmouth.EDU> Message-ID: <20190917012546.392E51570CE9@mail.bitblocks.com> On Mon, 16 Sep 2019 20:20:32 -0400 Doug McIlroy wrote: Doug McIlroy writes: > > The "block copy in an editor" thing is something which has intrigued > > me for years. poor old ed/ex/vi just couldn't do it, and for the life > > of me, I could not understand why this was "deprecated" by the people > > writing that family of editors. > > One might trace it to the founding tenet that a file is a stream of bytes, > reinforced by the absence of multidemensional arrays in C. But it goes > deeper than that. > > Ed imposes a structure, making a (finite) file into an array, aka list, > of lines. It's easy to define block moves and copies in a list. But > what are the semantics of a block move, wherein one treats the list > as a ragged-right 2D array? What gets pushed aside? In what direction? > How does a block move into column that not all destination rows > reach? How do you cope when the bottom gets ragged? How about the > top? Can one move blocks of tab-separated fields? > > I think everyone has rued the lack of block operations at one time > or another. But implementing them in any degree of generality is a > stumbling block. What should the semantics be? The Rand editor e handled all this reasonably well. A file was treated as a virtual quarter plane, with 0,0 as the start of the file (you could move a cursor anywhere including a non-existant line or column. Extra blanks or lines were added only if you actually typed something there). In the command line (like vi's exmode) for many commands you can specify an area of operation which can be n lines, n paragraphs or a rectangle, starting at the cursor position. Or you can select a rectangular area with the "mark" command. If you move the cursor straight down, N lines would be chosen. To pick nx1 rectangle, you move cursor right one place after marking. open would open up a blank area, pushing text left as necessary. close would close up an area, pushing text right if necessary. erase would blank out an area (erase text but leave text outside alone). run command replaced the contents with the output of a shell command. feed was like run except it kept the original and inserted new data at the cursor. Tabs were not separators but stood for specific columns. By default every 8 columns but you could change them to whatever. picking a rectangle handled them appropriately. IIRC. You stored non standard tab positions in a separate file. From clemc at ccc.com Tue Sep 17 11:26:34 2019 From: clemc at ccc.com (Clem cole) Date: Mon, 16 Sep 2019 21:26:34 -0400 Subject: [TUHS] earliest Unix roff In-Reply-To: <20190917011752.GY2046@mcvoy.com> References: <0bc0d10f-d17c-24df-2a7f-8f154eefd318@kilonet.net> <20190917011752.GY2046@mcvoy.com> Message-ID: <60761215-5B0E-41E9-A333-8799C6FAADD3@ccc.com> I’ve forgotten but it could have been early on. Having /root as the super users home directory was on later systems. I thought Masscomp did that but I might be thinking Stellar by then. Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. > On Sep 16, 2019, at 9:17 PM, Larry McVoy wrote: > >> On Mon, Sep 16, 2019 at 09:11:17PM -0400, Arthur Krewat wrote: >>> On 9/16/2019 8:20 PM, Steve Johnson wrote: >>> One day I had been furiously editing a long program file for about an hour >>> and a half when I was called away to lunch, and, being hungry, didn't save >>> my file.?? When I got back to the terminal an hour later, I discovered two >>> things -- the system had crashed, and our cat had decided that the pile of >>> paper >>> on the floor made a great litter box.?? After a few choice words, I sighed >>> and picked up my highliter... >> >> This should be engraved on a plaque somewhere. Only because I had almost the >> same thing happen to me, without the cat though. I had a printout of a >> "mail" program I had written on TOPS-10 at high school. I had to retype the >> entire thing after the file got corrupted. > > I think we have all been there. Something always goes wrong. I wrote > a paper about how to restore a Masscomp because I did rm -rf . in /. > I believe we had roots home as / because /usr was a different partition. > Clem, did Masscomp make roots home / or was that us? Anyway, I did a > cd something > and somehow deleted the something and then did rm -rf . > Much fun was had, I was up all night putting things back together. > This was probably around 1984 or 1985, I was pretty green. From lm at mcvoy.com Tue Sep 17 11:33:57 2019 From: lm at mcvoy.com (Larry McVoy) Date: Mon, 16 Sep 2019 18:33:57 -0700 Subject: [TUHS] earliest Unix roff In-Reply-To: <60761215-5B0E-41E9-A333-8799C6FAADD3@ccc.com> References: <0bc0d10f-d17c-24df-2a7f-8f154eefd318@kilonet.net> <20190917011752.GY2046@mcvoy.com> <60761215-5B0E-41E9-A333-8799C6FAADD3@ccc.com> Message-ID: <20190917013357.GA2046@mcvoy.com> In retrospect having / be roots home is a super bad idea but I think it was fairly common practice, /root became a thing as idiots like me messed things up :) On Mon, Sep 16, 2019 at 09:26:34PM -0400, Clem cole wrote: > I???ve forgotten but it could have been early on. Having /root as the super users home directory was on later systems. I thought Masscomp did that but I might be thinking Stellar by then. > > Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. > > > On Sep 16, 2019, at 9:17 PM, Larry McVoy wrote: > > > >> On Mon, Sep 16, 2019 at 09:11:17PM -0400, Arthur Krewat wrote: > >>> On 9/16/2019 8:20 PM, Steve Johnson wrote: > >>> One day I had been furiously editing a long program file for about an hour > >>> and a half when I was called away to lunch, and, being hungry, didn't save > >>> my file.?? When I got back to the terminal an hour later, I discovered two > >>> things -- the system had crashed, and our cat had decided that the pile of > >>> paper > >>> on the floor made a great litter box.?? After a few choice words, I sighed > >>> and picked up my highliter... > >> > >> This should be engraved on a plaque somewhere. Only because I had almost the > >> same thing happen to me, without the cat though. I had a printout of a > >> "mail" program I had written on TOPS-10 at high school. I had to retype the > >> entire thing after the file got corrupted. > > > > I think we have all been there. Something always goes wrong. I wrote > > a paper about how to restore a Masscomp because I did rm -rf . in /. > > I believe we had roots home as / because /usr was a different partition. > > Clem, did Masscomp make roots home / or was that us? Anyway, I did a > > cd something > > and somehow deleted the something and then did rm -rf . > > Much fun was had, I was up all night putting things back together. > > This was probably around 1984 or 1985, I was pretty green. -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From clemc at ccc.com Tue Sep 17 11:36:40 2019 From: clemc at ccc.com (Clem cole) Date: Mon, 16 Sep 2019 21:36:40 -0400 Subject: [TUHS] wizards test [was roff] In-Reply-To: <20190917011752.GY2046@mcvoy.com> References: <0bc0d10f-d17c-24df-2a7f-8f154eefd318@kilonet.net> <20190917011752.GY2046@mcvoy.com> Message-ID: <1583C418-2F6E-45D8-93C2-B93032E6CFFC@ccc.com> Btw. This was some I used as a wizards test. You have a working system next to a system that is still running so you have the console and its shell but had the rm -fr / done to it. You have lost all of bin dev etc and lib by the time he hit ^C. So you have some of /usr inc but much of /usr/bin is still there. No compiler or assembler on the broken machine since that was in bin and lib. It’s possible to fix it using the other system to help. Just don’t turn the damaged system off 🍺 Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. > On Sep 16, 2019, at 9:17 PM, Larry McVoy wrote: > >> On Mon, Sep 16, 2019 at 09:11:17PM -0400, Arthur Krewat wrote: >>> On 9/16/2019 8:20 PM, Steve Johnson wrote: >>> One day I had been furiously editing a long program file for about an hour >>> and a half when I was called away to lunch, and, being hungry, didn't save >>> my file.?? When I got back to the terminal an hour later, I discovered two >>> things -- the system had crashed, and our cat had decided that the pile of >>> paper >>> on the floor made a great litter box.?? After a few choice words, I sighed >>> and picked up my highliter... >> >> This should be engraved on a plaque somewhere. Only because I had almost the >> same thing happen to me, without the cat though. I had a printout of a >> "mail" program I had written on TOPS-10 at high school. I had to retype the >> entire thing after the file got corrupted. > > I think we have all been there. Something always goes wrong. I wrote > a paper about how to restore a Masscomp because I did rm -rf . in /. > I believe we had roots home as / because /usr was a different partition. > Clem, did Masscomp make roots home / or was that us? Anyway, I did a > cd something > and somehow deleted the something and then did rm -rf . > Much fun was had, I was up all night putting things back together. > This was probably around 1984 or 1985, I was pretty green. From rich.salz at gmail.com Tue Sep 17 11:36:40 2019 From: rich.salz at gmail.com (Richard Salz) Date: Mon, 16 Sep 2019 21:36:40 -0400 Subject: [TUHS] earliest Unix roff In-Reply-To: <60761215-5B0E-41E9-A333-8799C6FAADD3@ccc.com> References: <0bc0d10f-d17c-24df-2a7f-8f154eefd318@kilonet.net> <20190917011752.GY2046@mcvoy.com> <60761215-5B0E-41E9-A333-8799C6FAADD3@ccc.com> Message-ID: We've all been there. I won a Unix "most egregious use of Unix tools" award from Usenix for this small script trap 'ls | wc' 1 2 3 15 echo Reflex test. Type control-c ls | wc rm * Because I also did "rm * .o" I still have the ugly little warthog, anatomically correct, on my desk. -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Tue Sep 17 11:38:19 2019 From: clemc at ccc.com (Clem cole) Date: Mon, 16 Sep 2019 21:38:19 -0400 Subject: [TUHS] wizards test [was roff] In-Reply-To: <1583C418-2F6E-45D8-93C2-B93032E6CFFC@ccc.com> References: <0bc0d10f-d17c-24df-2a7f-8f154eefd318@kilonet.net> <20190917011752.GY2046@mcvoy.com> <1583C418-2F6E-45D8-93C2-B93032E6CFFC@ccc.com> Message-ID: I should say you have a root shell on the broken system which why it killed every thing. Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. > On Sep 16, 2019, at 9:36 PM, Clem cole wrote: > > Btw. This was some I used as a wizards test. > > You have a working system next to a system that is still running so you have the console and its shell but had the rm -fr / done to it. You have lost all of bin dev etc and lib by the time he hit ^C. So you have some of /usr inc but much of /usr/bin is still there. No compiler or assembler on the broken machine since that was in bin and lib. > > It’s possible to fix it using the other system to help. Just don’t turn the damaged system off 🍺 > > Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. > >>> On Sep 16, 2019, at 9:17 PM, Larry McVoy wrote: >>> >>>> On Mon, Sep 16, 2019 at 09:11:17PM -0400, Arthur Krewat wrote: >>>> On 9/16/2019 8:20 PM, Steve Johnson wrote: >>>> One day I had been furiously editing a long program file for about an hour >>>> and a half when I was called away to lunch, and, being hungry, didn't save >>>> my file.?? When I got back to the terminal an hour later, I discovered two >>>> things -- the system had crashed, and our cat had decided that the pile of >>>> paper >>>> on the floor made a great litter box.?? After a few choice words, I sighed >>>> and picked up my highliter... >>> >>> This should be engraved on a plaque somewhere. Only because I had almost the >>> same thing happen to me, without the cat though. I had a printout of a >>> "mail" program I had written on TOPS-10 at high school. I had to retype the >>> entire thing after the file got corrupted. >> >> I think we have all been there. Something always goes wrong. I wrote >> a paper about how to restore a Masscomp because I did rm -rf . in /. >> I believe we had roots home as / because /usr was a different partition. >> Clem, did Masscomp make roots home / or was that us? Anyway, I did a >> cd something >> and somehow deleted the something and then did rm -rf . >> Much fun was had, I was up all night putting things back together. >> This was probably around 1984 or 1985, I was pretty green. From grog at lemis.com Tue Sep 17 11:41:08 2019 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Tue, 17 Sep 2019 11:41:08 +1000 Subject: [TUHS] O'Reilly groff macros In-Reply-To: <498796af-156b-65e0-374d-38afd95c0968@andrewnesbit.org> References: <20190914020240.GO2046@mcvoy.com> <20190914024433.GA19193@minnie.tuhs.org> <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org> <069494b2-ec5b-91e7-8618-2d111e0e5aa2@andrewnesbit.org> <201909160620.x8G6KkJq026850@freefriends.org> <20190917001056.GD31311@eureka.lemis.com> <498796af-156b-65e0-374d-38afd95c0968@andrewnesbit.org> Message-ID: <20190917014108.GF31311@eureka.lemis.com> On Tuesday, 17 September 2019 at 1:54:21 +0100, U'll Be King of the Stars wrote: > On 17/09/2019 01:51, Clem Cole wrote: >> FYI Which Dale and Tim used at Masscomp  4 years earlier.  That book was >> originally modeled from Janet Eagans style guide which I still have. > > I LOVE style guides. I have a bit of a thing for them. > > Was the Eagans guide published? (Andrew shuffles off to Amazon.) I didn't get it when I signed up with O'Reilly. Instead they pointed me at the Chicago Manual of Style, which got me interested in the idea of style as well. It's fascinating how much the individual guides differ. 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 bakul at bitblocks.com Tue Sep 17 11:57:24 2019 From: bakul at bitblocks.com (Bakul Shah) Date: Mon, 16 Sep 2019 18:57:24 -0700 Subject: [TUHS] earliest Unix roff In-Reply-To: Your message of "Mon, 16 Sep 2019 18:17:52 -0700." <20190917011752.GY2046@mcvoy.com> References: <0bc0d10f-d17c-24df-2a7f-8f154eefd318@kilonet.net> <20190917011752.GY2046@mcvoy.com> Message-ID: <20190917015731.7758D1570CE9@mail.bitblocks.com> On Mon, 16 Sep 2019 18:17:52 -0700 Larry McVoy wrote: > On Mon, Sep 16, 2019 at 09:11:17PM -0400, Arthur Krewat wrote: > > On 9/16/2019 8:20 PM, Steve Johnson wrote: > > >One day I had been furiously editing a long program file for about an hour > > >and a half when I was called away to lunch, and, being hungry, didn't save > > >my file.?? When I got back to the terminal an hour later, I discovered two > > >things -- the system had crashed, and our cat had decided that the pile of > > >paper > > >on the floor made a great litter box.?? After a few choice words, I sighed > > >and picked up my highliter... > > > > This should be engraved on a plaque somewhere. Only because I had almost th > e > > same thing happen to me, without the cat though. I had a printout of a > > "mail" program I had written on TOPS-10 at high school. I had to retype the > > entire thing after the file got corrupted. > > I think we have all been there. Something always goes wrong. I wrote > a paper about how to restore a Masscomp because I did rm -rf . in /. > I believe we had roots home as / because /usr was a different partition. > Clem, did Masscomp make roots home / or was that us? Anyway, I did a > cd something > and somehow deleted the something and then did rm -rf . > Much fun was had, I was up all night putting things back together. > This was probably around 1984 or 1985, I was pretty green. I may have mentioned restoring root directory using peek/poke commands of a primitive boot loader. Right before Comdex (fall 1981) someone accidentally wiped out the root dir. IIRC we had just two systems that actually worked. The other person was copying the floppy to the second system when something went wrong. The backup didn't work. And this was a Comdex special filesystem (with demos for the show painstakingly put together and no time to recreate it all from scratch). I happened to remember inode & block numbers of the first few things so I fixed up the root dir enough for the system to come up & run fsck. Luckily very little was lost and we were able to repair the demos and run them at Comdex! From clemc at ccc.com Tue Sep 17 11:58:40 2019 From: clemc at ccc.com (Clem cole) Date: Mon, 16 Sep 2019 21:58:40 -0400 Subject: [TUHS] O'Reilly groff macros In-Reply-To: <20190917014108.GF31311@eureka.lemis.com> References: <20190914020240.GO2046@mcvoy.com> <20190914024433.GA19193@minnie.tuhs.org> <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org> <069494b2-ec5b-91e7-8618-2d111e0e5aa2@andrewnesbit.org> <201909160620.x8G6KkJq026850@freefriends.org> <20190917001056.GD31311@eureka.lemis.com> <498796af-156b-65e0-374d-38afd95c0968@andrewnesbit.org> <20190917014108.GF31311@eureka.lemis.com> Message-ID: If I was not clear, Janet’s document was for Masscomp. But the a number of Ora folks all had it like Talbot, Dale, Tim and Cindy After the merger ( I had left by then as had Janet) a large number of Janet’s original team followed Tim and became his original core in Cambridge. Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. > On Sep 16, 2019, at 9:41 PM, Greg 'groggy' Lehey wrote: > >> On Tuesday, 17 September 2019 at 1:54:21 +0100, U'll Be King of the Stars wrote: >>> On 17/09/2019 01:51, Clem Cole wrote: >>> FYI Which Dale and Tim used at Masscomp 4 years earlier. That book was >>> originally modeled from Janet Eagans style guide which I still have. >> >> I LOVE style guides. I have a bit of a thing for them. >> >> Was the Eagans guide published? (Andrew shuffles off to Amazon.) > > I didn't get it when I signed up with O'Reilly. Instead they pointed > me at the Chicago Manual of Style, which got me interested in the idea > of style as well. It's fascinating how much the individual guides > differ. > > 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 ggm at algebras.org Tue Sep 17 12:02:49 2019 From: ggm at algebras.org (George Michaelson) Date: Tue, 17 Sep 2019 12:02:49 +1000 Subject: [TUHS] block operations in editors, was My EuroBSDcon talk In-Reply-To: <20190917004233.4cgn6vabnmgwl5q5@localhost.localdomain> References: <201909170020.x8H0KWC6037690@tahoe.cs.Dartmouth.EDU> <20190917004233.4cgn6vabnmgwl5q5@localhost.localdomain> Message-ID: I also went vim, wanting nvi to be there but Keith Bostic lost impetus or motivation. I am not in love with vim, I still feel like its got a lot of glitter, but with the keystrokes for homekeys burned into my brain it was the best choice. I use ed periodically to remind myself what reductionism in editors means. I used atom and visual basic, they're ok for what they are. Vim also gave me syntax colouring. again, I was suprised how quickly I came to use it, having decried it. I guess like food, in matters of (editor) taste there is no good disputation. Sam didn't get into my frontal lobes quickly enough. I think if 8th and plan9 had been only TWO years earlier out the door, a lot of the world would look different. I look at kubernetes now, I live in it actually, and I feel like inferno was leading me there but I got there via very twisty paths. Really, what I think UNIX missed the most, was the plumber. GTK and KDE and the like dance around the problem of cut-paste between processes in ways which I am led to believe the plumber fixed long ago. Another thing which had it been only two years earlier, might have got us to a more cohered space. "first, kill all the lawyers" is probably the subtitle of a UNIX book. Counterfactuals. -G On Tue, Sep 17, 2019 at 10:42 AM G. Branden Robinson wrote: > > At 2019-09-16T20:20:32-0400, Doug McIlroy wrote: > > Ed imposes a structure, making a (finite) file into an array, aka > > list, of lines. It's easy to define block moves and copies in a list. > > But what are the semantics of a block move, wherein one treats the > > list as a ragged-right 2D array? What gets pushed aside? In what > > direction? How does a block move into column that not all destination > > rows reach? How do you cope when the bottom gets ragged? How about the > > top? Can one move blocks of tab-separated fields? > > > > I think everyone has rued the lack of block operations at one time or > > another. But implementing them in any degree of generality is a > > stumbling block. What should the semantics be? > > Just in case anyone didn't know, Vim has what it calls "visual block" > highlighting and operations. CTRL-V begins one and you use the usual > movement keys to shape and size it, then an operator like (y)ank or > (d)elete. > > It won't always work as one expects because of the very questions that > Doug raises above. > > Vim also has characterwise blocks (begin with 'v') and linewise blocks > (begin with 'V'). > > The last is, more than any other single factor, what pulled me over from > traditional vi (really nvi in my case). It was a big win over > line-counting with ":.,+n" expressions. In retrospect I should have > been smarter and just typed ":.,/pattern/", using as /pattern/ some > short string that did not appear in any of the lines I wanted to operate > on. > > Though the vi clone with the best name was, indisputably, elvis. > > Regards, > Branden From lm at mcvoy.com Tue Sep 17 12:34:52 2019 From: lm at mcvoy.com (Larry McVoy) Date: Mon, 16 Sep 2019 19:34:52 -0700 Subject: [TUHS] wizards test [was roff] In-Reply-To: <1583C418-2F6E-45D8-93C2-B93032E6CFFC@ccc.com> References: <0bc0d10f-d17c-24df-2a7f-8f154eefd318@kilonet.net> <20190917011752.GY2046@mcvoy.com> <1583C418-2F6E-45D8-93C2-B93032E6CFFC@ccc.com> Message-ID: <20190917023452.GB2046@mcvoy.com> That was exactly the situation I had and I had a tough time so I wrote a little paper about it. Lemme see if I can find it. Yep, found it. It was when I was messing with roff -me. http://mcvoy.com/lm/papers/restor.e http://mcvoy.com/lm/papers/restor.pdf I was apparently channeling creat(2) because it was too much work for me (or Ken) to add the trailing e. I'm sort of impressed that I wrote that in 1985 because I got to undergrad in 1980, I was an accounting major because my coach in high school was my accounting teacher, you don't disappoint your coach so I did great at accounting, got to college, no coach and accounting was *not* my thing, wandered around for a year or so taking STEM classes, took some Art History and declared that as a major, did that for 2 years (and got really good at it, as in I have corrected errors in a textbook about Greek pottery [1]) only to have my advisor tell me there are no jobs, so I switched to computer science in 1984. Going from nothing to being a sys admin that had to do a full restore in a year or so is kinda neat. But Unix was kinda neat and I was hooked, it's easy to get good when you really like something (ask me about fly fishing :) Doug, I still have the nroff/troff/tlb/eqn/pic (sadly no grap but I wrote my own in pic later) printed out docs that I got from the UW-Madison Computer Science department. I used those to write that little memo. [1] A little rant about art and how hard and how easy it can be. You guys know Picasso? How about Piet Modrian? Most people know both but don't know that they know Piet. They are very similar, Piet painted trees, here is one: http://1.bp.blogspot.com/-KwU6EePgmxk/T8FixzAZxBI/AAAAAAAAB0s/xUKRQc23MNk/s1600/mondrian.jpg Yep, that's a tree. WTF you say? So all great artist start out doing the simple stuff. Picasso, if you go back far enough, did still lifes of a bowl of fruit. Piet did essentially photographs of trees. But then they get weird, they get more abstract. And more abstract. To the point that you look at that link above and you go "how is that a tree? That's not a tree". You need to see their work in chronological order. You see the stuff that looks like a photograph and then it is a little different, a little different, and you get to the end and you go wow, that actually is a tree. It makes no sense if you just look at one after it gets abstract, it makes total sense if you see it order. I had the good fortune to see an exhibit at New Yorks MOMA of Picasso in chronological order. Holy moly did that snap him into focus. So that's a very long way of saying that it was easy for me to be good at Greek pottery because I already knew that if you put someones work in chronological order it would make sense. The correction I did that I'm proud of is to Janson's history of art (which is the benchmark for art history), there was a Greek artist who did a series of pots and Janson had two pots backwards, the earlier one was the later one. Janson was dead but the book carried on and they took my fix. On Mon, Sep 16, 2019 at 09:36:40PM -0400, Clem cole wrote: > Btw. This was some I used as a wizards test. > > You have a working system next to a system that is still running so you have the console and its shell but had the rm -fr / done to it. You have lost all of bin dev etc and lib by the time he hit ^C. So you have some of /usr inc but much of /usr/bin is still there. No compiler or assembler on the broken machine since that was in bin and lib. > > It???s possible to fix it using the other system to help. Just don???t turn the damaged system off ???? > > Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. > > > On Sep 16, 2019, at 9:17 PM, Larry McVoy wrote: > > > >> On Mon, Sep 16, 2019 at 09:11:17PM -0400, Arthur Krewat wrote: > >>> On 9/16/2019 8:20 PM, Steve Johnson wrote: > >>> One day I had been furiously editing a long program file for about an hour > >>> and a half when I was called away to lunch, and, being hungry, didn't save > >>> my file.?? When I got back to the terminal an hour later, I discovered two > >>> things -- the system had crashed, and our cat had decided that the pile of > >>> paper > >>> on the floor made a great litter box.?? After a few choice words, I sighed > >>> and picked up my highliter... > >> > >> This should be engraved on a plaque somewhere. Only because I had almost the > >> same thing happen to me, without the cat though. I had a printout of a > >> "mail" program I had written on TOPS-10 at high school. I had to retype the > >> entire thing after the file got corrupted. > > > > I think we have all been there. Something always goes wrong. I wrote > > a paper about how to restore a Masscomp because I did rm -rf . in /. > > I believe we had roots home as / because /usr was a different partition. > > Clem, did Masscomp make roots home / or was that us? Anyway, I did a > > cd something > > and somehow deleted the something and then did rm -rf . > > Much fun was had, I was up all night putting things back together. > > This was probably around 1984 or 1985, I was pretty green. -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From athornton at gmail.com Tue Sep 17 12:51:30 2019 From: athornton at gmail.com (Adam Thornton) Date: Mon, 16 Sep 2019 19:51:30 -0700 Subject: [TUHS] PiDP-11 in action! Message-ID: https://share.icloud.com/photos/0MKJjk8pRBvkZAEzaobjfOyPQ I start v7 Unix and play "Hunt The Wumpus". (I finally got it put together this weekend, and fixed the last couple dodgy joints tonight). Adam -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Tue Sep 17 13:06:36 2019 From: lm at mcvoy.com (Larry McVoy) Date: Mon, 16 Sep 2019 20:06:36 -0700 Subject: [TUHS] PiDP-11 in action! In-Reply-To: References: Message-ID: <20190917030636.GE2046@mcvoy.com> Go you. PDP-11 will always be my favorite assembler, there is an octal dump for a reason and that reason is the PDP-11. Or maybe PDPs in general. I had a TA in Uni that could read octal like it was PDP assembler. On Mon, Sep 16, 2019 at 07:51:30PM -0700, Adam Thornton wrote: > https://share.icloud.com/photos/0MKJjk8pRBvkZAEzaobjfOyPQ > > I start v7 Unix and play "Hunt The Wumpus". > > (I finally got it put together this weekend, and fixed the last couple > dodgy joints tonight). > > Adam -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From blstuart at bellsouth.net Tue Sep 17 13:19:32 2019 From: blstuart at bellsouth.net (Brian L. Stuart) Date: Tue, 17 Sep 2019 03:19:32 +0000 (UTC) Subject: [TUHS] PiDP-11 in action! In-Reply-To: References: Message-ID: <1847226767.5590783.1568690372673@mail.yahoo.com> On Monday, September 16, 2019, 10:51:59 PM EDT, Adam Thornton wrote: > I start v7 Unix and play "Hunt The Wumpus". > > (I finally got it put together this weekend, and fixed the last couple dodgy joints tonight). > > Adam Congrats. Those are so much fun. I had mine running 6th Ed at the Vintage Computer Festival Southeast last spring in Atlanta. A serious blast from the past. BLS -------------- next part -------------- An HTML attachment was scrubbed... URL: From lars at nocrew.org Tue Sep 17 15:07:33 2019 From: lars at nocrew.org (Lars Brinkhoff) Date: Tue, 17 Sep 2019 05:07:33 +0000 Subject: [TUHS] earliest Unix roff In-Reply-To: <20190916215917.GX2046@mcvoy.com> (Larry McVoy's message of "Mon, 16 Sep 2019 14:59:17 -0700") References: <20190914020240.GO2046@mcvoy.com> <20190914024433.GA19193@minnie.tuhs.org> <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org> <201909150654.x8F6sChG021185@freefriends.org> <201909160552.x8G5qBYK025195@freefriends.org> <20190916214832.GW2046@mcvoy.com> <201909162154.x8GLsnOs011718@darkstar.fourwinds.com> <20190916215917.GX2046@mcvoy.com> Message-ID: <7wblvjmrxm.fsf@junk.nocrew.org> Larry McVoy wrote: > My comment on the info stuff was just my understand of why it came to be. Probably no one knows any more. Quick history recap: - First there was the old plain text INFO which was more like Unix' man. - Then there was the new hypertext INFO built on EMACS. - GNU info copied ITS' INFO. When I ask ITS people about this old plain text INFO, they don't even remember it. I think it's reasonable to assume they thought the new hypertext format with links was more intriguing technology than plain text files. From lars at nocrew.org Tue Sep 17 15:21:06 2019 From: lars at nocrew.org (Lars Brinkhoff) Date: Tue, 17 Sep 2019 05:21:06 +0000 Subject: [TUHS] [tuhs] Computer history preservation In-Reply-To: (Nelson H. F. Beebe's message of "Mon, 16 Sep 2019 15:48:36 -0600") References: Message-ID: <7w7e67mrb1.fsf@junk.nocrew.org> "Nelson H. F. Beebe" writes: > I came across an article today about another major industry that has > been exceedingly careless about preserving its history It's an extenssion of the hype cycle. It starts like this: 1. Technology Trigger 2. Peak of Inflated Expectations 3. Trough of Disillusionment 4. Slope of Enlightenment 5. Plateau of Productivity What is usually not pictured is the rest of the curve: 6. Dip of Sunset Technology. 7. Valley of Obsolete Stuff. 8. Throwing Away of Old Junk. 9. Resurge of Nostalgia. 10. Frantic Search on Ebay. 11. The Even Higher Peak of Collector's Holy Grail. From emu at e-bbes.com Tue Sep 17 16:01:15 2019 From: emu at e-bbes.com (emanuel stiebler) Date: Tue, 17 Sep 2019 08:01:15 +0200 Subject: [TUHS] PiDP-11 in action! In-Reply-To: References: Message-ID: On 2019-09-17 04:51, Adam Thornton wrote: > https://share.icloud.com/photos/0MKJjk8pRBvkZAEzaobjfOyPQ > > I start v7 Unix and play "Hunt The Wumpus". > > (I finally got it put together this weekend, and fixed the last couple > dodgy joints tonight). IBM keyboard on a vt520? From usotsuki at buric.co Tue Sep 17 17:46:15 2019 From: usotsuki at buric.co (Steve Nickolas) Date: Tue, 17 Sep 2019 03:46:15 -0400 (EDT) Subject: [TUHS] [tuhs] Computer history preservation In-Reply-To: <20190917002825.GA15016@server.rulingia.com> References: <20190917002825.GA15016@server.rulingia.com> Message-ID: On Tue, 17 Sep 2019, Peter Jeremy wrote: > On 2019-Sep-16 15:48:36 -0600, "Nelson H. F. Beebe" wrote: >> I came across an article today about another major industry that has >> been exceedingly careless about preserving its history: >> >> Wipe Out: When the BBC Kept Erasing Its Own History >> https://getpocket.com/explore/item/wipe-out-when-the-bbc-kept-erasing-its-own-history >> >> It is a must-read for Dr Who fans on this list. > > It didn't only affect TV, much of The Goons originals were also destroyed (at least > one episode now sold by the BBC is an off-air recording by a fan because that's the > best extant copy). > > And NASA destroyed the tapes holding the original Apollo 11 moonwalk > (https://en.wikipedia.org/wiki/Apollo_11_missing_tapes). Toei Animation wiped the audio masters for Dragon Ball and Dragon Ball Z. What remains is low-quality optical audio from film prints. (They did the same for Dragon Ball GT but some TV stations managed to preserve the audio, so it's not as much of a problem as it is for the previous series.) -uso. From arnold at skeeve.com Tue Sep 17 17:53:07 2019 From: arnold at skeeve.com (arnold at skeeve.com) Date: Tue, 17 Sep 2019 01:53:07 -0600 Subject: [TUHS] earliest Unix roff In-Reply-To: <20190916145122.GH2046@mcvoy.com> References: <20190913221345.GA16129@minnie.tuhs.org> <20190914020240.GO2046@mcvoy.com> <20190914024433.GA19193@minnie.tuhs.org> <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org> <201909150654.x8F6sChG021185@freefriends.org> <201909160552.x8G5qBYK025195@freefriends.org> <20190916145122.GH2046@mcvoy.com> Message-ID: <201909170753.x8H7r8oT004491@freefriends.org> It is like clockwork. Whenever I say something about Texinfo *as a markup language* for use in *writing books*, the discussion inevitably degenerates into a hate rant against Info and RMS's (failed) attempt to replace man pages. Totally missing the point too. This is a trend on TUHS. The same discussions, the same rants, often the same misinformation, over and over and over again. I start to wonder if I should continue to subscribe. Arnold Larry McVoy wrote: > On Mon, Sep 16, 2019 at 08:10:48AM -0400, Clem Cole wrote: > > On Mon, Sep 16, 2019 at 1:52 AM wrote: > > > > > I use the standalone Info reader (named info) if I want to look at the > > > Info output. > > > > > Fair enough, but be careful, while I admit I have not looked in a while, > > info(gnu) relies on emacs keybindings and a number of very emacs'ish things. > > Every time I have tried to deal with it, I have unprogram my fingers and > > reset them to emacs. > > > > If it would have used more(1) [or even less(1)] then I would not be as > > annoyed. > > Unix had fine tools [man(1), more(1), et al] and rms and friends felt the > > need to replace them with ITS-like programs. > > I hate texinfo and friends. I get why it is better than man, but man was > good enough, more than good enough, and the GNU project took everything > it could find and destroyed the man pages. > > If you have something like perl that needs a zillion sub pages, info > makes sense. For just a man page, info is horrible. From wkt at tuhs.org Tue Sep 17 19:54:35 2019 From: wkt at tuhs.org (Warren Toomey) Date: Tue, 17 Sep 2019 19:54:35 +1000 Subject: [TUHS] A Couple of New Unix Artifacts Message-ID: <20190917095435.GA16333@minnie.tuhs.org> I fear we're drifting a bit here and the S/N ratio is dropping a bit w.r.t the actual history of Unix. Please no more on the relative merits of version control systems or alternative text processing systems. So I'll try to distract you by saying this. I'm sitting on two artifacts that have recently been given to me: + by two large organisations + of great significance to Unix history + who want me to keep "mum" about them + as they are going to make announcements about them soon * and I am going slowly crazy as I wait for them to be offically released. Now you have a new topic to talk about :-) Cheers, Warren * for some definition of "soon" From spedraja at gmail.com Tue Sep 17 19:58:51 2019 From: spedraja at gmail.com (SPC) Date: Tue, 17 Sep 2019 11:58:51 +0200 Subject: [TUHS] A Couple of New Unix Artifacts In-Reply-To: <20190917095435.GA16333@minnie.tuhs.org> References: <20190917095435.GA16333@minnie.tuhs.org> Message-ID: Agreed. And of course you have completely caught my attention about this... 8-) Cordiales saludos / Kind Regards. Gracias | Regards - Saludos | Greetings | Freundliche Grüße | Salutations -- *Sergio Pedraja* -- http://www.linkedin.com/in/sergiopedraja ----- El mar., 17 sept. 2019 a las 11:55, Warren Toomey () escribió: > I fear we're drifting a bit here and the S/N ratio is dropping a bit w.r.t > the actual history of Unix. Please no more on the relative merits of > version control systems or alternative text processing systems. > > So I'll try to distract you by saying this. I'm sitting on two artifacts > that have recently been given to me: > > + by two large organisations > + of great significance to Unix history > + who want me to keep "mum" about them > + as they are going to make announcements about them soon * > > and I am going slowly crazy as I wait for them to be offically released. > > Now you have a new topic to talk about :-) > > Cheers, Warren > > * for some definition of "soon" > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aap at papnet.eu Tue Sep 17 20:45:18 2019 From: aap at papnet.eu (Angelo Papenhoff) Date: Tue, 17 Sep 2019 12:45:18 +0200 Subject: [TUHS] A Couple of New Unix Artifacts In-Reply-To: <20190917095435.GA16333@minnie.tuhs.org> References: <20190917095435.GA16333@minnie.tuhs.org> Message-ID: <20190917104518.GA96058@indra.papnet.eu> On 17/09/19, Warren Toomey wrote: > I fear we're drifting a bit here and the S/N ratio is dropping a bit w.r.t > the actual history of Unix. Please no more on the relative merits of > version control systems or alternative text processing systems. > > So I'll try to distract you by saying this. I'm sitting on two artifacts > that have recently been given to me: > > + by two large organisations > + of great significance to Unix history > + who want me to keep "mum" about them > + as they are going to make announcements about them soon * > > and I am going slowly crazy as I wait for them to be offically released. > > Now you have a new topic to talk about :-) That sounds exciting! I wish we had more stuff of the v0-v4 era, but I don't know how likely that is to even still exist. Also the things that were documented in the manual but weren't in the distribution...old troff is something that comes to mind. We still have the source filenames in deleted directory entries in the v6 distribution. From thomas.paulsen at firemail.de Tue Sep 17 21:12:54 2019 From: thomas.paulsen at firemail.de (Thomas Paulsen) Date: Tue, 17 Sep 2019 13:12:54 +0200 Subject: [TUHS] earliest Unix roff In-Reply-To: References: <20190914024433.GA19193@minnie.tuhs.org> <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org> <201909150654.x8F6sChG021185@freefriends.org> <201909160552.x8G5qBYK025195@freefriends.org> <7wd0g0o2a0.fsf@junk.nocrew.org> Message-ID: <00285de87973bc46c5249bfdedac6bd0@firemail.de> Nemo Nusquam wrote: > On 09/16/19 18:05, Dave Horsfall wrote: > > Am I the only one who remembers the old "pg" program? It seems > to have disappeared. > > Still ships with Solaris (in /usr/bin). the sources can be found at Jorg Schillings sourceforge site. From thomas.paulsen at firemail.de Tue Sep 17 21:20:15 2019 From: thomas.paulsen at firemail.de (Thomas Paulsen) Date: Tue, 17 Sep 2019 13:20:15 +0200 Subject: [TUHS] earliest Unix roff In-Reply-To: <20190916161040.GM2046@mcvoy.com> References: <20190914024433.GA19193@minnie.tuhs.org> <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org> <201909150654.x8F6sChG021185@freefriends.org> <201909160552.x8G5qBYK025195@freefriends.org> <20190916145122.GH2046@mcvoy.com> <20190916161040.GM2046@mcvoy.com> Message-ID: <3f48679ee3ee432e47c1fba9d70da37a@firemail.de> Larry McVoy wrote: > > It's what Clem said. You should acclimate yourself to your environment. > Pushing info into man environment is a lot like being an immigrant and > wanting to bring your laws into your new homeland. That isn't a thing > and shouldn't be a thing. Doesn't matter that people think ITS is better, > they are in Unix. If you think ITS is better, go live there. > When in Rome.... > info failed (as well as texinfo). Hardly anybody using it, beside notorious emacs maniacs like me. Rome doesn't like it. From thomas.paulsen at firemail.de Tue Sep 17 21:01:47 2019 From: thomas.paulsen at firemail.de (Thomas Paulsen) Date: Tue, 17 Sep 2019 13:01:47 +0200 Subject: [TUHS] block operations in editors, was My EuroBSDcon talk In-Reply-To: <20190917004233.4cgn6vabnmgwl5q5@localhost.localdomain> References: <201909170020.x8H0KWC6037690@tahoe.cs.Dartmouth.EDU> <20190917004233.4cgn6vabnmgwl5q5@localhost.localdomain> Message-ID: <5eeb9c1609d2324672ecae9538f3f880@firemail.de> --------------------------------- > > Though the vi clone with the best name was, indisputably, elvis. > unfortunately unmaintained. elvis has a smaller memory footprint, and a more pleasant (nroff later html) based help support than vim. There are no plugin, vimscript feature sas well as no python/perl support. I'm interested in a vi with syntax coloring and help support, however I don't need scripting features. Therefore I hope someone will take over maintenance, as I'm too old for that. From thomas.paulsen at firemail.de Tue Sep 17 21:34:05 2019 From: thomas.paulsen at firemail.de (Thomas Paulsen) Date: Tue, 17 Sep 2019 13:34:05 +0200 Subject: [TUHS] block operations in editors, was My EuroBSDcon talk Message-ID: --------------------------------- > > Though the vi clone with the best name was, indisputably, elvis. > unfortunately unmaintained. elvis has a smaller memory footprint, and a more pleasant (nroff later html) based help support than vim. There are no plugin, vimscript feature sas well as no python/perl support. I'm interested in a vi with syntax coloring and help support, however I don't need scripting features. Therefore I hope someone will take over maintenance, as I'm too old for tha From tytso at mit.edu Tue Sep 17 21:46:02 2019 From: tytso at mit.edu (Theodore Y. Ts'o) Date: Tue, 17 Sep 2019 07:46:02 -0400 Subject: [TUHS] INed/Rand Editor/Ned [was Re: My EuroBSDcon talk (preview for commentary) In-Reply-To: <20190916202153.wbpzx3jn3a7rs6kb@localhost.localdomain> References: <20190915232524.9A5491570CE9@mail.bitblocks.com> <7F62BF6B-8FEA-4C43-9E35-05BDE9BF04EA@ccc.com> <20190916023738.F34E81570CE9@mail.bitblocks.com> <20190916202153.wbpzx3jn3a7rs6kb@localhost.localdomain> Message-ID: <20190917114602.GB6762@mit.edu> On Tue, Sep 17, 2019 at 06:21:56AM +1000, G. Branden Robinson wrote: > It's still common today. Everything the developer cares to think about, > let alone test on, interprets EMCA-48 SGR escape sequences. My favorite > recent example is "spectre-meltdown-checker", which has such edifying > lines as: > > _info_nol "> \033[46m\033[30mSTATUS:\033[0m " > > Why write something portable when you can be "close to the metal"? :-/ To be fair, spectre-multdown-checker is a shell script, and while you can use tput, that's not super-portable (some versions take termcap names, some take terminfo names, and the only thing that has been standardized is "init", "clear", and "reset"), and said script was designed to work on Linux and *BSD systems. - Ted From david at kdbarto.org Tue Sep 17 22:20:00 2019 From: david at kdbarto.org (David) Date: Tue, 17 Sep 2019 05:20:00 -0700 Subject: [TUHS] earliest Unix roff In-Reply-To: <20190917001655.GE31311@eureka.lemis.com> References: <20190913221345.GA16129@minnie.tuhs.org> <20190914020240.GO2046@mcvoy.com> <20190914024433.GA19193@minnie.tuhs.org> <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org> <201909150654.x8F6sChG021185@freefriends.org> <201909160552.x8G5qBYK025195@freefriends.org> <20190917001655.GE31311@eureka.lemis.com> Message-ID: > On Sep 16, 2019, at 5:16 PM, Greg 'groggy' Lehey wrote: > > For an extreme case of man pages, look at something like mplayer(1) or > mpv(1): > > $ man mplayer|wc -l > 9435 > $ man mpv|wc -l > 13939 > Those aren’t man pages, they are novellas. David From g.branden.robinson at gmail.com Tue Sep 17 22:52:24 2019 From: g.branden.robinson at gmail.com (G. Branden Robinson) Date: Tue, 17 Sep 2019 22:52:24 +1000 Subject: [TUHS] INed/Rand Editor/Ned [was Re: My EuroBSDcon talk (preview for commentary) In-Reply-To: <20190917114602.GB6762@mit.edu> References: <20190915232524.9A5491570CE9@mail.bitblocks.com> <7F62BF6B-8FEA-4C43-9E35-05BDE9BF04EA@ccc.com> <20190916023738.F34E81570CE9@mail.bitblocks.com> <20190916202153.wbpzx3jn3a7rs6kb@localhost.localdomain> <20190917114602.GB6762@mit.edu> Message-ID: <20190917125222.zpavtknp7f6v2hhx@localhost.localdomain> At 2019-09-17T07:46:02-0400, Theodore Y. Ts'o wrote: > To be fair, spectre-multdown-checker is a shell script, and while you > can use tput, that's not super-portable (some versions take termcap > names, some take terminfo names, and the only thing that has been > standardized is "init", "clear", and "reset"), Now that you mention it I do remember Thomas Dickey saying that at some point. > and said script was designed to work on Linux and *BSD systems. In that case I'd query tput through a function that got defined differently based on the output of uname, or tput's own version string output if it could be coaxed into giving me one (Dickey's ncurses tput supports -V for this purpose; I don't know about the BSDs). The thrust is to get that egregious noise out of the output strings as written in the source file so as to preserve their human-readability. Better this: echo "${fg_black}${bg_cyan}STATUS:${normal}" Than: echo "\033[30m\033[43mSTATUS\033[m" ...in which am I more likely to notice typos? Given an editor that lexically analyzes your shell script[1], which is more likely to integrate well with a spell-checker? Regards, Branden [1] Okay, so that turns out to be nearly impossible, at least if you want to recognize every possible construct[2]. [2] https://hal.archives-ouvertes.fr/hal-01890044/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From clemc at ccc.com Wed Sep 18 00:21:20 2019 From: clemc at ccc.com (Clem Cole) Date: Tue, 17 Sep 2019 10:21:20 -0400 Subject: [TUHS] earliest Unix roff In-Reply-To: <201909170753.x8H7r8oT004491@freefriends.org> References: <20190913221345.GA16129@minnie.tuhs.org> <20190914020240.GO2046@mcvoy.com> <20190914024433.GA19193@minnie.tuhs.org> <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org> <201909150654.x8F6sChG021185@freefriends.org> <201909160552.x8G5qBYK025195@freefriends.org> <20190916145122.GH2046@mcvoy.com> <201909170753.x8H7r8oT004491@freefriends.org> Message-ID: Fair enough. Mei culpa from one of those that was vocal. That said, maybe a trick is to stay away from texinfo/info and the man page discussion on this list since its a hot button that causes much trama for some with a more traditional UNIX view. Please don't leave, your voice is important and I generally agree with you and always like to hear you out. But even if I do not agree, I still want to listen. You have come to your conclusions in a different manner than some of us, and where each of us puts the MSB tends to color our views. Diversity of opinion is a good thing. Respectfully, Clem ᐧ On Tue, Sep 17, 2019 at 3:53 AM wrote: > It is like clockwork. > > Whenever I say something about Texinfo *as a markup language* for use > in *writing books*, the discussion inevitably degenerates into a hate > rant against Info and RMS's (failed) attempt to replace man pages. > Totally missing the point too. > > This is a trend on TUHS. The same discussions, the same rants, often > the same misinformation, over and over and over again. > > I start to wonder if I should continue to subscribe. > > Arnold > > Larry McVoy wrote: > > > On Mon, Sep 16, 2019 at 08:10:48AM -0400, Clem Cole wrote: > > > On Mon, Sep 16, 2019 at 1:52 AM wrote: > > > > > > > I use the standalone Info reader (named info) if I want to look at > the > > > > Info output. > > > > > > > Fair enough, but be careful, while I admit I have not looked in a > while, > > > info(gnu) relies on emacs keybindings and a number of very emacs'ish > things. > > > Every time I have tried to deal with it, I have unprogram my fingers > and > > > reset them to emacs. > > > > > > If it would have used more(1) [or even less(1)] then I would not be as > > > annoyed. > > > Unix had fine tools [man(1), more(1), et al] and rms and friends felt > the > > > need to replace them with ITS-like programs. > > > > I hate texinfo and friends. I get why it is better than man, but man was > > good enough, more than good enough, and the GNU project took everything > > it could find and destroyed the man pages. > > > > If you have something like perl that needs a zillion sub pages, info > > makes sense. For just a man page, info is horrible. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Wed Sep 18 00:28:20 2019 From: clemc at ccc.com (Clem Cole) Date: Tue, 17 Sep 2019 10:28:20 -0400 Subject: [TUHS] PiDP-11 in action! In-Reply-To: References: Message-ID: +1 ᐧ On Mon, Sep 16, 2019 at 10:52 PM Adam Thornton wrote: > https://share.icloud.com/photos/0MKJjk8pRBvkZAEzaobjfOyPQ > > I start v7 Unix and play "Hunt The Wumpus". > > (I finally got it put together this weekend, and fixed the last couple > dodgy joints tonight). > > Adam > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnold at skeeve.com Wed Sep 18 01:03:41 2019 From: arnold at skeeve.com (arnold at skeeve.com) Date: Tue, 17 Sep 2019 09:03:41 -0600 Subject: [TUHS] earliest Unix roff In-Reply-To: References: <20190913221345.GA16129@minnie.tuhs.org> <20190914020240.GO2046@mcvoy.com> <20190914024433.GA19193@minnie.tuhs.org> <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org> <201909150654.x8F6sChG021185@freefriends.org> <201909160552.x8G5qBYK025195@freefriends.org> <20190916145122.GH2046@mcvoy.com> <201909170753.x8H7r8oT004491@freefriends.org> Message-ID: <201909171503.x8HF3fRX016265@freefriends.org> Yes, I think the next time anyone says anything about markup languages, I'll just use private mail. Thanks, Arnold Clem Cole wrote: > Fair enough. Mei culpa from one of those that was vocal. That said, maybe > a trick is to stay away from texinfo/info and the man page discussion on > this list since its a hot button that causes much trama for some with a > more traditional UNIX view. > > Please don't leave, your voice is important and I generally agree with you > and always like to hear you out. But even if I do not agree, I still want > to listen. You have come to your conclusions in a different manner than > some of us, and where each of us puts the MSB tends to color our views. > Diversity of opinion is a good thing. > > Respectfully, > Clem > ᐧ > > On Tue, Sep 17, 2019 at 3:53 AM wrote: > > > It is like clockwork. > > > > Whenever I say something about Texinfo *as a markup language* for use > > in *writing books*, the discussion inevitably degenerates into a hate > > rant against Info and RMS's (failed) attempt to replace man pages. > > Totally missing the point too. > > > > This is a trend on TUHS. The same discussions, the same rants, often > > the same misinformation, over and over and over again. > > > > I start to wonder if I should continue to subscribe. > > > > Arnold > > > > Larry McVoy wrote: > > > > > On Mon, Sep 16, 2019 at 08:10:48AM -0400, Clem Cole wrote: > > > > On Mon, Sep 16, 2019 at 1:52 AM wrote: > > > > > > > > > I use the standalone Info reader (named info) if I want to look at > > the > > > > > Info output. > > > > > > > > > Fair enough, but be careful, while I admit I have not looked in a > > while, > > > > info(gnu) relies on emacs keybindings and a number of very emacs'ish > > things. > > > > Every time I have tried to deal with it, I have unprogram my fingers > > and > > > > reset them to emacs. > > > > > > > > If it would have used more(1) [or even less(1)] then I would not be as > > > > annoyed. > > > > Unix had fine tools [man(1), more(1), et al] and rms and friends felt > > the > > > > need to replace them with ITS-like programs. > > > > > > I hate texinfo and friends. I get why it is better than man, but man was > > > good enough, more than good enough, and the GNU project took everything > > > it could find and destroyed the man pages. > > > > > > If you have something like perl that needs a zillion sub pages, info > > > makes sense. For just a man page, info is horrible. > > From clemc at ccc.com Wed Sep 18 01:33:42 2019 From: clemc at ccc.com (Clem Cole) Date: Tue, 17 Sep 2019 11:33:42 -0400 Subject: [TUHS] [tuhs] Computer history preservation In-Reply-To: <7w7e67mrb1.fsf@junk.nocrew.org> References: <7w7e67mrb1.fsf@junk.nocrew.org> Message-ID: Lars - I love it. I've never seen that part of the curve spelled out and labeled before. ᐧ On Tue, Sep 17, 2019 at 1:21 AM Lars Brinkhoff wrote: > "Nelson H. F. Beebe" writes: > > I came across an article today about another major industry that has > > been exceedingly careless about preserving its history > > It's an extenssion of the hype cycle. It starts like this: > > 1. Technology Trigger > 2. Peak of Inflated Expectations > 3. Trough of Disillusionment > 4. Slope of Enlightenment > 5. Plateau of Productivity > > What is usually not pictured is the rest of the curve: > > 6. Dip of Sunset Technology. > 7. Valley of Obsolete Stuff. > 8. Throwing Away of Old Junk. > 9. Resurge of Nostalgia. > 10. Frantic Search on Ebay. > 11. The Even Higher Peak of Collector's Holy Grail. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnc at mercury.lcs.mit.edu Wed Sep 18 01:36:38 2019 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Tue, 17 Sep 2019 11:36:38 -0400 (EDT) Subject: [TUHS] block operations in editors, was My EuroBSDcon talk Message-ID: <20190917153638.79BDC18C098@mercury.lcs.mit.edu> > From: Doug McIlroy > the absence of multidemensional arrays in C. ?? From the 'C Reference Manual' (no date, but circa 'Typesetter C'), pg. 11: "If the unadorned declarator D would specify an n-dimensional array .. then the declarator D[in+1] yields an (n+1)-dimensional array" I'm not sure if I've _ever_ used one, but they are there. Noel From cbbrowne at gmail.com Wed Sep 18 01:58:20 2019 From: cbbrowne at gmail.com (Christopher Browne) Date: Tue, 17 Sep 2019 11:58:20 -0400 Subject: [TUHS] earliest Unix roff In-Reply-To: <201909170753.x8H7r8oT004491@freefriends.org> References: <20190913221345.GA16129@minnie.tuhs.org> <20190914020240.GO2046@mcvoy.com> <20190914024433.GA19193@minnie.tuhs.org> <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org> <201909150654.x8F6sChG021185@freefriends.org> <201909160552.x8G5qBYK025195@freefriends.org> <20190916145122.GH2046@mcvoy.com> <201909170753.x8H7r8oT004491@freefriends.org> Message-ID: On Tue, Sep 17, 2019, 3:54 AM wrote: > It is like clockwork. > > Whenever I say something about Texinfo *as a markup language* for use > in *writing books*, the discussion inevitably degenerates into a hate > rant against Info and RMS's (failed) attempt to replace man pages. > Totally missing the point too. > Yeah, that is a pain in the neck. I had the other reaction to this... I have been managing my web presence via DocBook SGML for a goodly long time. It is, as mentioned upthread, pretty wordy what with all the verbose tagging. It would be worth something to be able to edit it in TeXinfo form, with the lesser amount of tagging required. (And I'd kinda like to get off of DocBook/SGML one of these days as the toolset is clearly mouldering away pretty badly.) So my reaction to your comments was to look into the usability of TeXinfo... I did a wee experiment yesterday, attempting to use docbook2x to get to something else. Alas, it seems to want to use xsltproc on the XML form, and the transformation to XML is apparently a separate pain in the neck. I thought I accomplished it, but the XSLT for generating TeXinfo throws up on it, so there must be more to the matter. I'll take a further poke at it later; thank you for offering a bit of inspiration on possible approaches to change. I know I can turn DocBook into s-expressions, and then write some transformation in CL after that; it would be nice if there were something already written. For sophisticated material, TeXinfo is of use, notwithstanding notions to make everything into brief man pages. Bashing RMS for wanting things from ITS (and probably Multics too) (as I see elsewhere in the thread) is unnecessarily unkind. A dogmatic attitude of "must be short man pages" shifts us to a different Procrustean bed that fails in a different set of cases. I for one was kinda hoping for Project Xanadu someday, to throw a different perspective on that. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From crossd at gmail.com Wed Sep 18 02:29:53 2019 From: crossd at gmail.com (Dan Cross) Date: Tue, 17 Sep 2019 12:29:53 -0400 Subject: [TUHS] PiDP-11 in action! In-Reply-To: References: Message-ID: On Tue, Sep 17, 2019 at 2:23 AM emanuel stiebler wrote: > On 2019-09-17 04:51, Adam Thornton wrote: > > https://share.icloud.com/photos/0MKJjk8pRBvkZAEzaobjfOyPQ > > > > I start v7 Unix and play "Hunt The Wumpus". > > > > (I finally got it put together this weekend, and fixed the last couple > > dodgy joints tonight). > > IBM keyboard on a vt520? > Huh; apparently the VT520 had (well, has...) a PS/2 compatible 6-pin mini-DIN connector: http://web.mit.edu/dosathena/doc/www/ek-vt520-rm.pdf I'm most familiar with the earlier VT models that use MMJ connectors for the keyboard (and RS-232). That's kinda nifty, though. - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pechter at gmail.com Wed Sep 18 02:54:08 2019 From: pechter at gmail.com (William Pechter) Date: Tue, 17 Sep 2019 12:54:08 -0400 Subject: [TUHS] PiDP-11 in action! In-Reply-To: References: Message-ID: Actually... IIRC the RJ11 was used on the VT2xx and 3xx series terminals. The MMJ was only on the RS232 port. I would check, but I gave away my last non VT180 DEC terminal. Bill Sent from pechter at gmail.com -----Original Message----- From: Dan Cross To: emanuel stiebler Cc: The Eunuchs Hysterical Society Sent: Tue, 17 Sep 2019 12:31 Subject: Re: [TUHS] PiDP-11 in action! On Tue, Sep 17, 2019 at 2:23 AM emanuel stiebler wrote: > On 2019-09-17 04:51, Adam Thornton wrote: > > https://share.icloud.com/photos/0MKJjk8pRBvkZAEzaobjfOyPQ > > > > I start v7 Unix and play "Hunt The Wumpus". > > > > (I finally got it put together this weekend, and fixed the last couple > > dodgy joints tonight). > > IBM keyboard on a vt520? > Huh; apparently the VT520 had (well, has...) a PS/2 compatible 6-pin mini-DIN connector: http://web.mit.edu/dosathena/doc/www/ek-vt520-rm.pdf I'm most familiar with the earlier VT models that use MMJ connectors for the keyboard (and RS-232). That's kinda nifty, though. - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Wed Sep 18 03:12:37 2019 From: clemc at ccc.com (Clem Cole) Date: Tue, 17 Sep 2019 13:12:37 -0400 Subject: [TUHS] PiDP-11 in action! In-Reply-To: References: Message-ID: A PITA, but I actually have the block to crimp them and some MMJ stock in my basement. Lego Mindstorms use it also as a way to try to keep people from by options from other folks. I never thought it was nifty mind you. ᐧ On Tue, Sep 17, 2019 at 12:31 PM Dan Cross wrote: > On Tue, Sep 17, 2019 at 2:23 AM emanuel stiebler wrote: > >> On 2019-09-17 04:51, Adam Thornton wrote: >> > https://share.icloud.com/photos/0MKJjk8pRBvkZAEzaobjfOyPQ >> > >> > I start v7 Unix and play "Hunt The Wumpus". >> > >> > (I finally got it put together this weekend, and fixed the last couple >> > dodgy joints tonight). >> >> IBM keyboard on a vt520? >> > > Huh; apparently the VT520 had (well, has...) a PS/2 compatible 6-pin > mini-DIN connector: http://web.mit.edu/dosathena/doc/www/ek-vt520-rm.pdf > > I'm most familiar with the earlier VT models that use MMJ connectors for > the keyboard (and RS-232). That's kinda nifty, though. > > - Dan C. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From doug at cs.dartmouth.edu Wed Sep 18 03:31:52 2019 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Tue, 17 Sep 2019 13:31:52 -0400 Subject: [TUHS] block operations in editors, was My EuroBSDcon talk Message-ID: <201909171731.x8HHVq2L096688@tahoe.cs.Dartmouth.EDU> Noel Chiappa wrote: > > From: Doug McIlroy > > > the absence of multidemensional arrays in C. > >?? From the 'C Reference Manual' (no date, but circa 'Typesetter C'), pg. 11: > > "If the unadorned declarator D would specify an n-dimensional array .. then > the declarator D[in+1] yields an (n+1)-dimensional array" > > >I'm not sure if I've _ever_ used one, but they are there. Yes, C allows arrays of arrays, and I've used them aplenty. However an "n-dimensional array" has one favored dimension, out of which you can slice an array of lower dimension. For example, you can pass a row of a 2D array to a function of a 1D variable, but you can't pass a column. That asymmetry underlies my assertion. In Python, by contrast, n-dimensional arrays can be sliced on any dimension. Doug From crossd at gmail.com Wed Sep 18 03:48:12 2019 From: crossd at gmail.com (Dan Cross) Date: Tue, 17 Sep 2019 13:48:12 -0400 Subject: [TUHS] PiDP-11 in action! In-Reply-To: References: Message-ID: On Tue, Sep 17, 2019 at 12:54 PM William Pechter wrote: > Actually... IIRC the RJ11 was used on the VT2xx and 3xx series > terminals. The MMJ was only on the RS232 port. > > I would check, but I gave away my last non VT180 DEC terminal. > I stand corrected. I keep a VT420 on my desk with an LK421 (the "Unix" keyboard), connected to my workstation (now via a USB serial adapter). I just popped the keyboard and it is, indeed, an RJ11 for the keyboard. Serial is MMJ, which connects to an MMJ<->DB9 converter which connects to a mini null-modem to the USB adapter. So simple. - Dan C. -----Original Message----- > From: Dan Cross > To: emanuel stiebler > Cc: The Eunuchs Hysterical Society > Sent: Tue, 17 Sep 2019 12:31 > Subject: Re: [TUHS] PiDP-11 in action! > > On Tue, Sep 17, 2019 at 2:23 AM emanuel stiebler wrote: > >> On 2019-09-17 04:51, Adam Thornton wrote: >> > https://share.icloud.com/photos/0MKJjk8pRBvkZAEzaobjfOyPQ >> > >> > I start v7 Unix and play "Hunt The Wumpus". >> > >> > (I finally got it put together this weekend, and fixed the last couple >> > dodgy joints tonight). >> >> IBM keyboard on a vt520? >> > > Huh; apparently the VT520 had (well, has...) a PS/2 compatible 6-pin > mini-DIN connector: http://web.mit.edu/dosathena/doc/www/ek-vt520-rm.pdf > > I'm most familiar with the earlier VT models that use MMJ connectors for > the keyboard (and RS-232). That's kinda nifty, though. > > - Dan C. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From steffen at sdaoden.eu Wed Sep 18 03:57:59 2019 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Tue, 17 Sep 2019 19:57:59 +0200 Subject: [TUHS] SCCS In-Reply-To: <20190916203152.GB9704@mcvoy.com> References: <20190912034346.GJ2046@mcvoy.com> <1457a2d6-2f17-482d-e4f7-ace439d34ca8@neophilic.com> <8db2e89c-ce50-a453-e38a-ecdfe69a746c@e-bbes.com> <20190913211104.aMZXy%steffen@sdaoden.eu> <20190913211751.GF2046@mcvoy.com> <20190913230312.XaeCQ%steffen@sdaoden.eu> <20190914015517.GD12480@mcvoy.com> <20190916172300.cjlkf%steffen@sdaoden.eu> <20190916203152.GB9704@mcvoy.com> Message-ID: <20190917175759.bUdCC%steffen@sdaoden.eu> Larry McVoy wrote in <20190916203152.GB9704 at mcvoy.com>: |On Mon, Sep 16, 2019 at 07:23:00PM +0200, Steffen Nurpmeso wrote: |> Larry McVoy wrote in <20190914015517.GD12480 at mcvoy.com>: |>|On Sat, Sep 14, 2019 at 01:03:12AM +0200, Steffen Nurpmeso wrote: |>|> He is as convinced from SCCS and its interleaved deltas as you |>|> are, but he works on extending the plain original SCCS, which is |>|> pretty smaller; his presentation from the "Chemnitzer Linux Tage |>|> 2012" (linux days of former Karl-Marx-Stadt) [1] talks about this |>|> and also prominently mentions BitKeeper: |>|> |>|> . All modern distributed OSS version control systems base upon |>|> BitKeeper in the end. |>| |>|Sort of. Monotone, Darcs, and one other one I can't remember did not |>|draw from BitKeeper. Mercurial, Git, and the Australian one that I |>|can't remember definitely do. |>| |>|> . BitKeeper bases upon the ideas of TeamWare. |>| |>|Only in that I am the primary author of both. It does support the idea |>|that SCCS is the basis for both, though Teamware used the real SCCS and |>|I rewrote SCCS from scratch and then extended it quite a bit. BitKeeper\ |>|'s |>|SCCS tracks a lot more than SCCS does, pathnames, permissions, hostnames, |>|etc. |> |> Regarding the technical background J??rg mentions US Patent 5481722 |> on merging deltas of source code control for computer software |> development that Glenn Skinner of Sun holds. | |Yeah, it's nuts that Glenn got that patent. It's true it was his idea |to do the graph that way, and he had an implementation that created |the graph through multiple calls to stripdel, get, and delta. It was |excruciatingly slow. | |100% of the code that implemented the one pass "zipper"-ing of 2 |diverged SCCS files was designed and written by me. At the very |least, I should have been coauthor of the patent but Sun politics |got in the way [1]. | |>|> . TeamWare bases upon the ideas of NSE. |>| |>|That's absolutely false. TeamWare, which is the productized version |>|of NSElite, which I wrote all of, was a reaction to how absolute shiite |>|NSE was. I had friends in the Sun kernel group that quit because they |>|were forced to use NSE. It was awful. I got into source management |>|because I was well known at Sun as the guy that could fix performance |>|problems so I was asked to look at NSE. One look told me that I couldn't |>|fix NSE but the source management problem space needed some help. | |[1] The politics had to do with Teamware. I wrote all the code in |NSElite, including smoosh(1) which was what the patent covered (though |the patent happened later). Everyone in the kernel group were using |NSElite because NSE sucked so hard. But it wasn't sanctioned code, |it was a Larry project. Bill Shannon would walk around and tell people |that they couldn't use NSElite but they ignored him because it worked |and it was light years faster than NSE. | |They couldn't kill NSElite so they decided to toss it to an 8 person |team in the tools group. They told me if I wanted to work on tools I |had to go join the tools group. Yeah, right, I'm in the kernel group |and I'm going to take the 3 step downgrade to tools? I don't think so. | |I just kept on supporting and developing NSElite, which was 90% perl4 |and a xview graphical program to view history and smoosh (both C). |Because I was coding most of the stuff in (very stylized perl, I rewrote |it 3 times until I had code I could have a hope of maintaining), I was |much faster at rolling out new stuff. In fact, the 8 people choose to |rewrite everything in C++ which meant I was coding circles around them. |Hence the politics, one guy, in his spare time, while doing a full time |job hacking the kernel, was making 8 guys look like idiots. Evan later |wrote a paper about what a bad choice C++ was. | |Something had to give and Jon Kannegaard, who was the VP of the tools |group, walked into my office and said "I've got Scott's (McNealy, CEO) |approval on this. If you make one more release of NSElite you are |fired." Nice, eh? Not everything was perfect at Sun. | |So I stopped, I left the kernel group and went over and did SPARC Clusters |for Ken Okin. Glenn filed the patent after I left. | |It was a shame because NSElite didn't have changesets, it wasn't really |a distributed system (relied on NFS to get at remote repos), if I had |kept going it would have evolved into what BitKeeper bacame. | |Oh, yeah, the politics were so bad that when Evan took smoosh.c he |didn't take any of the SCCS history, he checked it in so it looked like |he wrote it. Even Shannon called that dirty pool. Thank you for this look into the Sun internals, the above sounds manlike, and that in High-Tech! |>|> . NSE is a frontend to SCCS. |>| |>|That's true. |>| |>|> . Therewith all modern systems ultimately base upon SCCS. |>| |>|That is a big stretch, it's just not true. I love the SCCS file |>|format but to say all modern systems are based on SCCS is 100% |>|false. BitKeeper is. That's it. |>| |>|> . Distributed operate TeamWare, BitKeeper, git, Mercurial. |>| |>|Git and Mercurial were going for append only data structures. |>|That's not SCCS. |>| |>|All this comes from Jorg, isn't he the guy who has a track record of |>|being on the outside of Sun and trying to argue with me about what Sun |>|was doing when I was a well known guy in the most important group at Sun, |>|the kernel group. If so, I'd salt his stuff heavily. |> |> This is the J??rg Schilling with whom you have had a dispute on |> this list, yes. But i do not share this track record of yours. | |OK, I'm happy you like him, I liked him just fine until he started |making statements that aren't true. Statements that were about |what Sun was doing and why they were doing it. Statements about |the content and direction of the kernel development, that I knew |to be false because I was in the Sun kernel group during the time |he was referencing. Kinda hard to be any closer to it than I was |so unless I've gone completely senile in my old age, I'm probably |more likely to be right about that information than he is. I was |there, he was not. Hm, he started running into this list for sure. Since you guys are there for several decades, who can tell in between the line fluxes, me not. All i know is that if you interview multiple people on the same topic, then you will hear multiple stories, practically always. Transporting history by hearsay is what made us great, wa. I will never forget documentation of some natives in the Indonesian djungle, the kings envoy only said that he is exactly that, was scanned by many eyes, .. and accepted. So even if Jörg has a hearsay account on the Sun internals in question, i cannot blame him for standing upon that ground. |> One thing he says, and which is an interesting part of this |> thread, is |> |> Die Behauptung von Eric Allman Tichy h??tte SCCS Version |> 1 verwendet kann ich nicht glauben, denn die Ver??ffentlichungen |> von Tichy sind von 1982 und SCCS war seit Februar 1977 auf der |> Version 4. SCCS Version 3 hatte ??brigens noch ein bin??res |> Historyformat. |> |> The statement of Eric Allman that Tichy used SCCS version |> 1 i cannot believe, because Tichy's releases are from 1982, and |> SCCS version 4 was released as earyl as February 1977. SCCS |> version 3 used a binary history format, by the way. | |Before my time so I don't know. I was an undergrad Art History major |at that time :) | |--lm --End of <20190916203152.GB9704 at mcvoy.com> --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 arnold at skeeve.com Wed Sep 18 04:15:40 2019 From: arnold at skeeve.com (arnold at skeeve.com) Date: Tue, 17 Sep 2019 12:15:40 -0600 Subject: [TUHS] earliest Unix roff In-Reply-To: References: <20190913221345.GA16129@minnie.tuhs.org> <20190914020240.GO2046@mcvoy.com> <20190914024433.GA19193@minnie.tuhs.org> <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org> <201909150654.x8F6sChG021185@freefriends.org> <201909160552.x8G5qBYK025195@freefriends.org> <20190916145122.GH2046@mcvoy.com> <201909170753.x8H7r8oT004491@freefriends.org> Message-ID: <201909171815.x8HIFfKS022066@freefriends.org> Hi. Christopher Browne wrote: > I had the other reaction to this... > > I have been managing my web presence via DocBook SGML for a goodly long > time. It is, as mentioned upthread, pretty wordy what with all the verbose > tagging. > > It would be worth something to be able to edit it in TeXinfo form, with the > lesser amount of tagging required. (And I'd kinda like to get off of > DocBook/SGML one of these days as the toolset is clearly mouldering away > pretty badly.) Looks like pandoc will go from DocBook to Texinfo. Me, I'd probably write a giant awk script to do the grunt work. :-) > For sophisticated material, TeXinfo is of use, notwithstanding notions to > make everything into brief man pages. As I've been saying, I use it for books. Good luck, Arnold From imp at bsdimp.com Wed Sep 18 04:32:34 2019 From: imp at bsdimp.com (Warner Losh) Date: Tue, 17 Sep 2019 12:32:34 -0600 Subject: [TUHS] earliest Unix roff In-Reply-To: <201909171815.x8HIFfKS022066@freefriends.org> References: <20190913221345.GA16129@minnie.tuhs.org> <20190914020240.GO2046@mcvoy.com> <20190914024433.GA19193@minnie.tuhs.org> <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org> <201909150654.x8F6sChG021185@freefriends.org> <201909160552.x8G5qBYK025195@freefriends.org> <20190916145122.GH2046@mcvoy.com> <201909170753.x8H7r8oT004491@freefriends.org> <201909171815.x8HIFfKS022066@freefriends.org> Message-ID: On Tue, Sep 17, 2019 at 12:16 PM wrote: > Hi. > > Christopher Browne wrote: > > I had the other reaction to this... > > > > I have been managing my web presence via DocBook SGML for a goodly long > > time. It is, as mentioned upthread, pretty wordy what with all the > verbose > > tagging. > > > > It would be worth something to be able to edit it in TeXinfo form, with > the > > lesser amount of tagging required. (And I'd kinda like to get off of > > DocBook/SGML one of these days as the toolset is clearly mouldering away > > pretty badly.) > > Looks like pandoc will go from DocBook to Texinfo. > > Me, I'd probably write a giant awk script to do the grunt work. :-) > FreeBSD likely is moving out DocBook stuff to markdown. Docbook is too hard to find people to work on :( Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Wed Sep 18 05:18:16 2019 From: imp at bsdimp.com (Warner Losh) Date: Tue, 17 Sep 2019 13:18:16 -0600 Subject: [TUHS] My EuroBSDcon talk (preview for commentary) In-Reply-To: References: Message-ID: On Fri, Sep 13, 2019 at 2:07 PM Clem Cole wrote: > Another thought -- the first commercial licensee was Rand. Hired some > former Harvard students who brought UNIX with them. You probably need to > add things like Rand Ports (a.k.a. named pipes) which came from there. > Also Chesson and Co did the original ArpaNET NCP at University of Ill > with some help from the Rand folks. That was done on a V6 system ~ 1978 > When I worked at The Wollongong Group they were quite specific that they had their license from V6 days, that it was a one-off that has unusually favorable terms, and that it was the first licensee. But that may be the first license to redistribute, rather than the first commercial user to be licensed... I think for an expanded version of my talk, I'd include the other details, since there's both the NCP work and some TCP work with v7 in our archive these days. I'll add a bullet point for these things. V6/V7 is the time that derivatives and add-ons really start to appear in relative abundance. You also need need Ken's famous V6 'patch' tape -- that 'leaked' > I'll see if I can work that in.. Is that the famous '50 patches' or is that something else? On Fri, Sep 13, 2019 at 4:02 PM Clem Cole wrote: > >> BTW: I just thought of something else.... one of the b*tched about the >> commercial redistribution license from V7 in 1979, that was not fixed until >> the SVR3 licensing the mid-late 1980s was AT&T's source policy. As I >> said, a commercial source license was $20K for the first CPU and 5K for >> each additional one. Later (System V) it went to $50K for the first and >> $10K for each additional. But what really ticked off the vendors like >> DEC, Masscomp, Sun et al, was that each system that sources on was supposed >> to one of the 'second CPU licenses' - the binary license was not good >> enough. >> >> What most of us did, was make sure any system that was a 'source control' >> or 'master' system at any 'site' had a full source license, but we were all >> in violation of the source agreement on our personal workstations. The >> argument was the sources on people's machines was ephemeral and not >> 'stored' there. But it was definitely contentious. >> > Yea, I think that all these details are (a) interesting but (b) not quite right for this talk... Warner > On Fri, Sep 13, 2019 at 3:47 PM Clem Cole wrote: >> >>> slide 4 -- All of HP-UX, Ultrix and Digital UNIX/Tru64 are BSD >>> kernels. HP-UP and Tru64 support System V calls. >>> >>> BTW: DG-UX and Stratus built their own kernels, but used System V >>> command systems and System Call definitions - which are not listed. >>> >>> Slide 6 - if you want it I have another picture of the GE system from >>> some of their literature has a view of all of the components. Send me >>> email if you want it. >>> >>> Slide 8 - Sets out to write version of Fortran came up with B. Uses B >>> to write Assembler >>> >>> Slide 9 - Wrong DEC logo. Should be the Blue one. The maroon version >>> does not show up until the 1990s with Bob Palmer (and has bad memories for >>> some of us). >>> >>> Slide 17 - Ken write PDP-11 assembler on PDP-7 in B. , Dennis starts to >>> rewrite B compiler to output PDP-11 code. >>> >>> Slide 18 - B begins to become different enough that Dennis starts to >>> call it nb [new B], eventually deviates enough to become new language >>> >>> Slide 19 - 4th Edition release outside of the BTL. Lou Katz >>> becomes 'user zero' >>> >>> Slide 20 -- We need to get you the site and group name from Mash. It >>> was not in Summit, it was not USG - but was in NJ. I thought it was Homdel >>> but I that is purely speculation. >>> Also the role of Columbus team needs to be defined. >>> Ask Mary Ann. >>> >>> Slide 21 -- I'm not going to argue - but I would ask you to add a >>> disclaimer. This is what you could reconstruct, but there is some >>> question of some of the arrows. Heinz might be able to help, but as >>> Stienhart and I have said, its believed to be in LA; but no one has tracked >>> him down as he has been pursuing non-computer interests. >>> >>> Slide 22 --4th Edition went to Katz that this is wrong, who sometimes >>> reads this mailing list. If not, send me a note, I'll reintroduce you. He >>> might be able to give you a data. Check with Warren, my >>memory<< is that >>> some of userland is still in C although a lot assembler is still there. >>> >>> Slide 23 -- ??widespread?? -- I'm not sure I would use that. Not even >>> 100 sites yet. Also there were not "commercial version" this was the >>> first "commercial license" -- big difference [contact me if you want >>> explanation]. IIRC fee was 15K per CPU. Commercial redistribution doesn't >>> occur until after 7th is released and was a separate license. I would >>> add, Mike Lesk's portable C library is starting to be used, but most C >>> program do their own I/O with read/write >>> >>> First real install man page and Dennis build tape installation >>> system. Earlier version released as RK05 disk copies. >>> Also numerous new peripherals. IIRC Support for the 11/40 >>> starts here, 4th & 5th needed a 45 class, and earlier used the 20 with the >>> CSS MMU. >>> >>> Slide 24 -- CMU uses it to teaches OS class. makes student in class >>> sign a sub-license. >>> >>> Slide 25 - missing the first USENIX tapes. which include Harvard and the >>> like. Warren and I can probably help a little here. >>> >>> Slide 26 - new licenses. Commercial license fees change to 20K for 1st >>> CPU/5K for each CPU afterward. CMU buys first commercial license to use >>> UNIX to make money [after Cole and Klein go on strike]. Case Western >>> follows suit 6month later. AT&T agrees for the Universities that they >>> only had to declare one CPU as commercial and could intermix otherwise and >>> notifies all the universities that if they were using it for commercial >>> purposes, then needed a license. >>> >>> AT&T creates first redistribution license. Needed at least one $20K >>> commercial CPU and then $150k for the rights to redistribute. Originally >>> $1K per binary CPU. >>> >>> Slide 27 -- missing Purdue Dual Vax and CMU Mach >>> >>> Slide 28 - APS had NH which was the model the DEC plate you show. >>> Maddog has it now on his Jeep when aps moved to CA (he also has the NH >>> Linux plate but I don't remember the car -- you can ask him). I have had >>> the Massachusetts UNIX plate since 1983 (it's on my model S of course). >>> ghg has indiana from around the same time (I think on a pickup). wnj had >>> the CA vmunix on his Ferrari, but I don't know if he still has it or what >>> its on. >>> >>> Slide 29 - Look in HenrySpencer-TUHS.org -- you'll find tail but not >>> head. >>> >>> Slide 31 - Job Control can from Europe via MIT. Jim Kulp wrote it. >>> Noel and I can give you the story if you want it. It was on the PDP-11 >>> there. Joy modified csh and added it to 4.1 >>> >>> Slide 32 -- JC was not from UCB. Joy got it from MIT -- Dennis >>> create ENV and it was first distributed in V7. >>> >>> Slide 33 -- No Bourne supported ENV in the new shell -- see me earlier >>> email for how all this went down or ask Steve yourself. >>> >>> Slide 34 -- PCC was included, but the Ritchie Compiler (a.k.a. >>> Typesetter C) was the default compiler. You are missing a step BTW -- >>> typesetter C was released between V6 and V7. As is the first draft of the >>> White Book. The new compiler had stdio but targets V6. >>> Also mpx was part of DataKit support. >>> >>> Slide 35 -- Not sure that is true. I thought Microsoft's Xenix ships >>> before Venix. Particularly since you made the comment about System III >>> The original 8086 Xenix was a pure V7 port, with a few additions Gordon >>> brought with him from Purdue (i.e. ghg hacks). >>> >>> Slide 52/53/54/55 -- wrong logo (see above) >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On Thu, Sep 12, 2019 at 11:21 PM Warner Losh wrote: >>> >>>> OK. I've shared my slides for the talk. >>>> >>>> Some of the family trees are simplified (V7 doesn't have room for all >>>> its ports, for example) >>>> Some of it is a little cheeseball since I'm also trying to be witty and >>>> entertaining (we'll see how that goes). >>>> Please don't share them around until after my talk on the September 20th >>>> >>>> I'd like feedback on the bits I got wrong. Or left out. Or if you're in >>>> this and don't want to be, etc. >>>> >>>> All the slides after the Questions slide won't be presented and will >>>> likely be deleted. >>>> >>>> >>>> https://docs.google.com/presentation/d/177KxOif5oHARyIdZHDq-OO67_GVtMkzIAlDX-cHxgb4/edit?usp=sharing >>>> >>>> Please be kind (but if it sucks, please do tell). I've turned on >>>> commenting on the slides. Probably best if you comment there. >>>> >>>> I have a video of me giving this talk, but it's too rough to share... >>>> >>>> Thanks for any help you can give me. >>>> >>>> Warner >>>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Wed Sep 18 05:29:04 2019 From: imp at bsdimp.com (Warner Losh) Date: Tue, 17 Sep 2019 13:29:04 -0600 Subject: [TUHS] My EuroBSDcon talk (preview for commentary) In-Reply-To: References: Message-ID: On Fri, Sep 13, 2019 at 3:31 PM Clem Cole wrote: > BTW: I just found my PWB 1.0 manual. The date is May 1977, authors are > T. (Ted) Dolotta, R. (Dick) Haight and E. Piskorik > and it lists the site as 'Piscataway' as the site on the > acknowlegements page. > Yes. That's the first release of PWB. However, they took delivery of their first PDP-11 in 1973, which is when the PWB efforts began as part of the BIS or BISP business unit (I have conflicting sources on the exact name). After my talk is complete, I'd planned on going back and trying to piece together release timelines as well, since although efforts happened starting in 73, releases, as such, don't seem to start for another couple of years. I suspect that when the number of groups being supported was small, the overhead of a formal release cycle likely wasn't worth the benefits (but have no documentation from the early days to prove that). Warner > On Fri, Sep 13, 2019 at 4:06 PM Clem Cole wrote: > >> Another thought -- the first commercial licensee was Rand. Hired some >> former Harvard students who brought UNIX with them. You probably need to >> add things like Rand Ports (a.k.a. named pipes) which came from there. >> Also Chesson and Co did the original ArpaNET NCP at University of Ill >> with some help from the Rand folks. That was done on a V6 system ~ 1978 >> >> You also need need Ken's famous V6 'patch' tape -- that 'leaked' >> >> >> On Fri, Sep 13, 2019 at 4:02 PM Clem Cole wrote: >> >>> BTW: I just thought of something else.... one of the b*tched about the >>> commercial redistribution license from V7 in 1979, that was not fixed until >>> the SVR3 licensing the mid-late 1980s was AT&T's source policy. As I >>> said, a commercial source license was $20K for the first CPU and 5K for >>> each additional one. Later (System V) it went to $50K for the first and >>> $10K for each additional. But what really ticked off the vendors like >>> DEC, Masscomp, Sun et al, was that each system that sources on was supposed >>> to one of the 'second CPU licenses' - the binary license was not good >>> enough. >>> >>> What most of us did, was make sure any system that was a 'source >>> control' or 'master' system at any 'site' had a full source license, but we >>> were all in violation of the source agreement on our personal >>> workstations. The argument was the sources on people's machines was >>> ephemeral and not 'stored' there. But it was definitely contentious. >>> >>> >>> >>> On Fri, Sep 13, 2019 at 3:47 PM Clem Cole wrote: >>> >>>> slide 4 -- All of HP-UX, Ultrix and Digital UNIX/Tru64 are BSD >>>> kernels. HP-UP and Tru64 support System V calls. >>>> >>>> BTW: DG-UX and Stratus built their own kernels, but used System V >>>> command systems and System Call definitions - which are not listed. >>>> >>>> Slide 6 - if you want it I have another picture of the GE system from >>>> some of their literature has a view of all of the components. Send me >>>> email if you want it. >>>> >>>> Slide 8 - Sets out to write version of Fortran came up with B. Uses B >>>> to write Assembler >>>> >>>> Slide 9 - Wrong DEC logo. Should be the Blue one. The maroon version >>>> does not show up until the 1990s with Bob Palmer (and has bad memories for >>>> some of us). >>>> >>>> Slide 17 - Ken write PDP-11 assembler on PDP-7 in B. , Dennis starts to >>>> rewrite B compiler to output PDP-11 code. >>>> >>>> Slide 18 - B begins to become different enough that Dennis starts to >>>> call it nb [new B], eventually deviates enough to become new language >>>> >>>> Slide 19 - 4th Edition release outside of the BTL. Lou Katz >>>> becomes 'user zero' >>>> >>>> Slide 20 -- We need to get you the site and group name from Mash. It >>>> was not in Summit, it was not USG - but was in NJ. I thought it was Homdel >>>> but I that is purely speculation. >>>> Also the role of Columbus team needs to be defined. >>>> Ask Mary Ann. >>>> >>>> Slide 21 -- I'm not going to argue - but I would ask you to add a >>>> disclaimer. This is what you could reconstruct, but there is some >>>> question of some of the arrows. Heinz might be able to help, but as >>>> Stienhart and I have said, its believed to be in LA; but no one has tracked >>>> him down as he has been pursuing non-computer interests. >>>> >>>> Slide 22 --4th Edition went to Katz that this is wrong, who sometimes >>>> reads this mailing list. If not, send me a note, I'll reintroduce you. He >>>> might be able to give you a data. Check with Warren, my >>memory<< is that >>>> some of userland is still in C although a lot assembler is still there. >>>> >>>> Slide 23 -- ??widespread?? -- I'm not sure I would use that. Not even >>>> 100 sites yet. Also there were not "commercial version" this was the >>>> first "commercial license" -- big difference [contact me if you want >>>> explanation]. IIRC fee was 15K per CPU. Commercial redistribution doesn't >>>> occur until after 7th is released and was a separate license. I would >>>> add, Mike Lesk's portable C library is starting to be used, but most C >>>> program do their own I/O with read/write >>>> >>>> First real install man page and Dennis build tape >>>> installation system. Earlier version released as RK05 disk copies. >>>> Also numerous new peripherals. IIRC Support for the 11/40 >>>> starts here, 4th & 5th needed a 45 class, and earlier used the 20 with the >>>> CSS MMU. >>>> >>>> Slide 24 -- CMU uses it to teaches OS class. makes student in class >>>> sign a sub-license. >>>> >>>> Slide 25 - missing the first USENIX tapes. which include Harvard and >>>> the like. Warren and I can probably help a little here. >>>> >>>> Slide 26 - new licenses. Commercial license fees change to 20K for 1st >>>> CPU/5K for each CPU afterward. CMU buys first commercial license to use >>>> UNIX to make money [after Cole and Klein go on strike]. Case Western >>>> follows suit 6month later. AT&T agrees for the Universities that they >>>> only had to declare one CPU as commercial and could intermix otherwise and >>>> notifies all the universities that if they were using it for commercial >>>> purposes, then needed a license. >>>> >>>> AT&T creates first redistribution license. Needed at least one $20K >>>> commercial CPU and then $150k for the rights to redistribute. Originally >>>> $1K per binary CPU. >>>> >>>> Slide 27 -- missing Purdue Dual Vax and CMU Mach >>>> >>>> Slide 28 - APS had NH which was the model the DEC plate you show. >>>> Maddog has it now on his Jeep when aps moved to CA (he also has the NH >>>> Linux plate but I don't remember the car -- you can ask him). I have had >>>> the Massachusetts UNIX plate since 1983 (it's on my model S of course). >>>> ghg has indiana from around the same time (I think on a pickup). wnj had >>>> the CA vmunix on his Ferrari, but I don't know if he still has it or what >>>> its on. >>>> >>>> Slide 29 - Look in HenrySpencer-TUHS.org -- you'll find tail but not >>>> head. >>>> >>>> Slide 31 - Job Control can from Europe via MIT. Jim Kulp wrote it. >>>> Noel and I can give you the story if you want it. It was on the PDP-11 >>>> there. Joy modified csh and added it to 4.1 >>>> >>>> Slide 32 -- JC was not from UCB. Joy got it from MIT -- Dennis >>>> create ENV and it was first distributed in V7. >>>> >>>> Slide 33 -- No Bourne supported ENV in the new shell -- see me earlier >>>> email for how all this went down or ask Steve yourself. >>>> >>>> Slide 34 -- PCC was included, but the Ritchie Compiler (a.k.a. >>>> Typesetter C) was the default compiler. You are missing a step BTW -- >>>> typesetter C was released between V6 and V7. As is the first draft of the >>>> White Book. The new compiler had stdio but targets V6. >>>> Also mpx was part of DataKit support. >>>> >>>> Slide 35 -- Not sure that is true. I thought Microsoft's Xenix >>>> ships before Venix. Particularly since you made the comment about System >>>> III >>>> The original 8086 Xenix was a pure V7 port, with a few additions Gordon >>>> brought with him from Purdue (i.e. ghg hacks). >>>> >>>> Slide 52/53/54/55 -- wrong logo (see above) >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Thu, Sep 12, 2019 at 11:21 PM Warner Losh wrote: >>>> >>>>> OK. I've shared my slides for the talk. >>>>> >>>>> Some of the family trees are simplified (V7 doesn't have room for all >>>>> its ports, for example) >>>>> Some of it is a little cheeseball since I'm also trying to be witty >>>>> and entertaining (we'll see how that goes). >>>>> Please don't share them around until after my talk on the September >>>>> 20th >>>>> >>>>> I'd like feedback on the bits I got wrong. Or left out. Or if you're >>>>> in this and don't want to be, etc. >>>>> >>>>> All the slides after the Questions slide won't be presented and will >>>>> likely be deleted. >>>>> >>>>> >>>>> https://docs.google.com/presentation/d/177KxOif5oHARyIdZHDq-OO67_GVtMkzIAlDX-cHxgb4/edit?usp=sharing >>>>> >>>>> Please be kind (but if it sucks, please do tell). I've turned on >>>>> commenting on the slides. Probably best if you comment there. >>>>> >>>>> I have a video of me giving this talk, but it's too rough to share... >>>>> >>>>> Thanks for any help you can give me. >>>>> >>>>> Warner >>>>> >>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Wed Sep 18 06:13:30 2019 From: clemc at ccc.com (Clem Cole) Date: Tue, 17 Sep 2019 16:13:30 -0400 Subject: [TUHS] My EuroBSDcon talk (preview for commentary) In-Reply-To: References: Message-ID: On Tue, Sep 17, 2019 at 3:18 PM Warner Losh wrote: > > When I worked at The Wollongong Group they were quite specific that they > had their license from V6 days, that it was a one-off that has unusually > favorable terms, and that it was the first licensee. But that may be the > first license to redistribute, rather than the first commercial user to be > licensed... > Possible - as I said ISC might have something also. But V7 was the first generally available redistrbution license. It might have had a few tunable things, but generally it was what everyone had. The per CPU terms was set thinking a computer cost $150K-500K, not $1-2K. > > > I'll see if I can work that in.. Is that the famous '50 patches' or is > that something else? > Yes - the patch tape or 50 changes. > ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Wed Sep 18 06:17:34 2019 From: clemc at ccc.com (Clem Cole) Date: Tue, 17 Sep 2019 16:17:34 -0400 Subject: [TUHS] My EuroBSDcon talk (preview for commentary) In-Reply-To: References: Message-ID: On Tue, Sep 17, 2019 at 3:29 PM Warner Losh wrote: > Yes. That's the first release of PWB. However, they took delivery of their > first PDP-11 in 1973, which is when the PWB efforts began > Hmmm... I'd believe the efforts start then, but the idea if going outside of that group was later. Mashey is the person to ask. Send me email off line and I'll introduce you. > as part of the BIS or BISP business unit (I have conflicting sources on > the exact name). > Yeah that sounds like something I remember. Ask Mash. > ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Wed Sep 18 08:39:46 2019 From: dave at horsfall.org (Dave Horsfall) Date: Wed, 18 Sep 2019 08:39:46 +1000 (EST) Subject: [TUHS] earliest Unix roff In-Reply-To: <20190917013357.GA2046@mcvoy.com> References: <0bc0d10f-d17c-24df-2a7f-8f154eefd318@kilonet.net> <20190917011752.GY2046@mcvoy.com> <60761215-5B0E-41E9-A333-8799C6FAADD3@ccc.com> <20190917013357.GA2046@mcvoy.com> Message-ID: On Mon, 16 Sep 2019, Larry McVoy wrote: > In retrospect having / be roots home is a super bad idea but I think it > was fairly common practice, /root became a thing as idiots like me > messed things up :) After my similar fsckup, I made /etc root's home directory (it was much easier to recover, and was available at boot time). -- Dave From dave at horsfall.org Wed Sep 18 09:12:21 2019 From: dave at horsfall.org (Dave Horsfall) Date: Wed, 18 Sep 2019 09:12:21 +1000 (EST) Subject: [TUHS] A Couple of New Unix Artifacts In-Reply-To: <20190917095435.GA16333@minnie.tuhs.org> References: <20190917095435.GA16333@minnie.tuhs.org> Message-ID: On Tue, 17 Sep 2019, Warren Toomey wrote: [...] > Now you have a new topic to talk about :-) The infamous plaster cast of certain genitals (if it actually existed; the cast I mean)? -- Dave From krewat at kilonet.net Wed Sep 18 09:25:00 2019 From: krewat at kilonet.net (Arthur Krewat) Date: Tue, 17 Sep 2019 19:25:00 -0400 Subject: [TUHS] A Couple of New Unix Artifacts In-Reply-To: References: <20190917095435.GA16333@minnie.tuhs.org> Message-ID: My wish list is: - Oracle (or some other licensee) coughed up SunOS. Legally. - AT&T or some other derivative coughed up SVR4(.2) Ok, that's all I got ;) But yes, I'm insane enough to want: Oracle coughing up Solaris 11.x(4?) - legally. And I don't mean OpenSolaris. BTW - I know a certain institution I know, I'm pretty sure used V6 for a graphics workstation. I'm pretty sure they had a source license, but I could be wrong. What's the reality when it came to V6 being used commercially in a product? This would be around the early 80's timeframe. And certain law enforcement agencies actually used at least one workstation for whatever reason.  It would have run on MIcro-11's, and MIcro-Vaxen. On 9/17/2019 7:12 PM, Dave Horsfall wrote: > On Tue, 17 Sep 2019, Warren Toomey wrote: > > [...] > >> Now you have a new topic to talk about :-) > > The infamous plaster cast of certain genitals (if it actually existed; > the cast I mean)? > > -- Dave > From athornton at gmail.com Wed Sep 18 10:38:38 2019 From: athornton at gmail.com (Adam Thornton) Date: Tue, 17 Sep 2019 17:38:38 -0700 Subject: [TUHS] PiDP-11 in action! In-Reply-To: References: Message-ID: Busted EPROMs certainly would fit the symptoms. What EPROM does a MicroVAX 3100 use, and does simh have the requisite binary image? I've got a ROM burner.... On Tue, Sep 17, 2019 at 7:28 AM Clem Cole wrote: > +1 > ᐧ > > On Mon, Sep 16, 2019 at 10:52 PM Adam Thornton > wrote: > >> https://share.icloud.com/photos/0MKJjk8pRBvkZAEzaobjfOyPQ >> >> I start v7 Unix and play "Hunt The Wumpus". >> >> (I finally got it put together this weekend, and fixed the last couple >> dodgy joints tonight). >> >> Adam >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From athornton at gmail.com Wed Sep 18 10:42:56 2019 From: athornton at gmail.com (Adam Thornton) Date: Tue, 17 Sep 2019 17:42:56 -0700 Subject: [TUHS] earliest Unix roff In-Reply-To: <201909171815.x8HIFfKS022066@freefriends.org> References: <20190913221345.GA16129@minnie.tuhs.org> <20190914020240.GO2046@mcvoy.com> <20190914024433.GA19193@minnie.tuhs.org> <2e84c4d0-5239-b223-856d-00aacf8d3028@andrewnesbit.org> <201909150654.x8F6sChG021185@freefriends.org> <201909160552.x8G5qBYK025195@freefriends.org> <20190916145122.GH2046@mcvoy.com> <201909170753.x8H7r8oT004491@freefriends.org> <201909171815.x8HIFfKS022066@freefriends.org> Message-ID: I always rather liked the IBM Bookmaster flavor of GML. I wrote some good-looking (and perhaps even useful) things in it. Adam On Tue, Sep 17, 2019 at 11:16 AM wrote: > Hi. > > Christopher Browne wrote: > > I had the other reaction to this... > > > > I have been managing my web presence via DocBook SGML for a goodly long > > time. It is, as mentioned upthread, pretty wordy what with all the > verbose > > tagging. > > > > It would be worth something to be able to edit it in TeXinfo form, with > the > > lesser amount of tagging required. (And I'd kinda like to get off of > > DocBook/SGML one of these days as the toolset is clearly mouldering away > > pretty badly.) > > Looks like pandoc will go from DocBook to Texinfo. > > Me, I'd probably write a giant awk script to do the grunt work. :-) > > > For sophisticated material, TeXinfo is of use, notwithstanding notions to > > make everything into brief man pages. > > As I've been saying, I use it for books. > > Good luck, > > Arnold > -------------- next part -------------- An HTML attachment was scrubbed... URL: From athornton at gmail.com Wed Sep 18 10:47:40 2019 From: athornton at gmail.com (Adam Thornton) Date: Tue, 17 Sep 2019 17:47:40 -0700 Subject: [TUHS] A Couple of New Unix Artifacts In-Reply-To: References: <20190917095435.GA16333@minnie.tuhs.org> Message-ID: We at Sine Nomine Associates read the entrails wrong. We did a port of OpenSolaris to the zSeries architecture (although we required z/VM; much like Linux, there's no point running it otherwise). By "we" I mean mostly Neale Ferguson for the heavy lifting and me for most of the userland apps and toolchain stuff (although I did write most of the disk device driver, which went through z/VM DIAGs rather than talking directly to the hardware, but from the OpenSolaris perspective it was just a device driver). Both we and IBM thought IBM was going to buy Sun. I'm sure that's why IBM agreed to give us a couple extra DIAGs in z/VM to make the thing run a good deal more efficiently. And then IBM pushed too hard on price, apparently not knowing Sun was also sitting on an offer from Larry Ellison. My career would have been very different if that acquisition had happened. Adam On Tue, Sep 17, 2019 at 4:25 PM Arthur Krewat wrote: > My wish list is: > > - Oracle (or some other licensee) coughed up SunOS. Legally. > - AT&T or some other derivative coughed up SVR4(.2) > > Ok, that's all I got ;) > > But yes, I'm insane enough to want: Oracle coughing up Solaris 11.x(4?) > - legally. And I don't mean OpenSolaris. > > BTW - I know a certain institution I know, I'm pretty sure used V6 for a > graphics workstation. I'm pretty sure they had a source license, but I > could be wrong. What's the reality when it came to V6 being used > commercially in a product? This would be around the early 80's > timeframe. And certain law enforcement agencies actually used at least > one workstation for whatever reason. It would have run on MIcro-11's, > and MIcro-Vaxen. > > > On 9/17/2019 7:12 PM, Dave Horsfall wrote: > > On Tue, 17 Sep 2019, Warren Toomey wrote: > > > > [...] > > > >> Now you have a new topic to talk about :-) > > > > The infamous plaster cast of certain genitals (if it actually existed; > > the cast I mean)? > > > > -- Dave > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From krewat at kilonet.net Wed Sep 18 10:54:02 2019 From: krewat at kilonet.net (Arthur Krewat) Date: Tue, 17 Sep 2019 20:54:02 -0400 Subject: [TUHS] A Couple of New Unix Artifacts In-Reply-To: References: <20190917095435.GA16333@minnie.tuhs.org> Message-ID: On 9/17/2019 8:47 PM, Adam Thornton wrote: > > And then IBM pushed too hard on price, apparently not knowing Sun was > also sitting on an offer from Larry Ellison. > > My career would have been very different if that acquisition had happened. Another factoid added to the gestalt in my head. art k. From athornton at gmail.com Wed Sep 18 11:03:45 2019 From: athornton at gmail.com (Adam Thornton) Date: Tue, 17 Sep 2019 18:03:45 -0700 Subject: [TUHS] A Couple of New Unix Artifacts In-Reply-To: References: <20190917095435.GA16333@minnie.tuhs.org> Message-ID: Well, take it with a grain of salt. I have no actual knowledge of what IBM was attempting or what really happened. But from where I sat the evidence was pretty compelling: they wanted an OpenSolaris port enough to give us some hypervisor changes we asked for (which certainly must have had substantial engineering costs for them), and it was pretty clear to me at the time that Sun was looking for a buyer and that IBM would be a natural entity to buy them. On Tue, Sep 17, 2019 at 5:54 PM Arthur Krewat wrote: > On 9/17/2019 8:47 PM, Adam Thornton wrote: > > > > And then IBM pushed too hard on price, apparently not knowing Sun was > > also sitting on an offer from Larry Ellison. > > > > My career would have been very different if that acquisition had > happened. > > Another factoid added to the gestalt in my head. > > > art k. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wlc at jctaylor.com Wed Sep 18 11:40:52 2019 From: wlc at jctaylor.com (William Corcoran) Date: Wed, 18 Sep 2019 01:40:52 +0000 Subject: [TUHS] cathode Message-ID: <009D825B-EF35-4310-8008-48EEB2D34D4B@jctaylor.com> Hello TUHS on Tues., Warren Toomey suggested I let the group know about a utility that exists at least for iMacs and IOS devices. It’s called “cathode” and you can find it on the Apple App Store. Please forgive me if this has already been mentioned. This utility provides for an xterm window that looks like the display an old *tube. You can set the curvature of the glass, the glow, various scan techniques, 9600 speed, and so on. It adds that extra dimension to give the look and feel of working on early UNIX with a tube. I would love to see profiles created that match actual ttys. My favorite tube is the Wyse 50. Another, one I remember is a Codex model with “slowopen” set in vi. Remember how early UNIX terminals behaved with slowopen, right? The characters would overtype during insert mode in vi, but when you hit escape, the line you just clobbered reappears shifting the remaining text as appropriate to the right. Cathode adds a little spice, albeit artificially, to the experience of early UNIX. Truly, Bill Corcoran (*) For the uninitiated, we used to call the tty terminal a “tube.” For example, you might hear my boss say, “Corcoran, that cheese you hacked yesterday launched a runaway that’s now soaking the client’s CPU. Go jump on a free tube and fix it now!” From lars at nocrew.org Wed Sep 18 13:27:53 2019 From: lars at nocrew.org (Lars Brinkhoff) Date: Wed, 18 Sep 2019 03:27:53 +0000 Subject: [TUHS] cathode In-Reply-To: <009D825B-EF35-4310-8008-48EEB2D34D4B@jctaylor.com> (William Corcoran's message of "Wed, 18 Sep 2019 01:40:52 +0000") References: <009D825B-EF35-4310-8008-48EEB2D34D4B@jctaylor.com> Message-ID: <7wr24ejnba.fsf@junk.nocrew.org> William Corcoran wrote: > I would love to see profiles created that match actual ttys. I would love it if they matched actual teletypes. But that's for another program. From scj at yaccman.com Wed Sep 18 14:47:47 2019 From: scj at yaccman.com (Steve Johnson) Date: Tue, 17 Sep 2019 21:47:47 -0700 Subject: [TUHS] block operations in editors, was My EuroBSDcon talk In-Reply-To: <201909171731.x8HHVq2L096688@tahoe.cs.Dartmouth.EDU> Message-ID: <2af4396e3f1133dfb93c2a92722e6f0e850ade55@webmail.yaccman.com> This is one of my pet peeves.  "Random Access" memory is far from random when you look at the time it takes to do the accesses.  With modern memories, accessing a column can be 20 to 40x slower than accessing a row.  This is particularly irritating when doing AI training, where training reuses 4-d tensors transposed, a very painful operation. In FORTRAN days, I once used a vector package in which you described a vector by giving the first element, the second element, and a count.  So you could describe rows, columns, a matrix diagonal, and even rows and columns from back to front.  Fortran passed arguments by address, which made the whole thing easy and fast. Steve ----- Original Message ----- From: "Doug McIlroy" To:, Cc: Sent:Tue, 17 Sep 2019 13:31:52 -0400 Subject:Re: [TUHS] block operations in editors, was My EuroBSDcon talk Noel Chiappa wrote: > > From: Doug McIlroy > > > the absence of multidemensional arrays in C. > >?? From the 'C Reference Manual' (no date, but circa 'Typesetter C'), pg. 11: > > "If the unadorned declarator D would specify an n-dimensional array .. then > the declarator D[in+1] yields an (n+1)-dimensional array" > > >I'm not sure if I've _ever_ used one, but they are there. Yes, C allows arrays of arrays, and I've used them aplenty. However an "n-dimensional array" has one favored dimension, out of which you can slice an array of lower dimension. For example, you can pass a row of a 2D array to a function of a 1D variable, but you can't pass a column. That asymmetry underlies my assertion. In Python, by contrast, n-dimensional arrays can be sliced on any dimension. Doug -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon at fourwinds.com Wed Sep 18 14:52:24 2019 From: jon at fourwinds.com (Jon Steinhart) Date: Tue, 17 Sep 2019 21:52:24 -0700 Subject: [TUHS] block operations in editors, was My EuroBSDcon talk In-Reply-To: <2af4396e3f1133dfb93c2a92722e6f0e850ade55@webmail.yaccman.com> References: <2af4396e3f1133dfb93c2a92722e6f0e850ade55@webmail.yaccman.com> Message-ID: <201909180452.x8I4qOiO002491@darkstar.fourwinds.com> Steve Johnson writes: > This is one of my pet peeves.  "Random Access" memory is far from random when > you look at the time it takes to do the accesses.  With modern memories, > accessing a column can be 20 to 40x slower than accessing a row.  This is > particularly irritating when doing AI training, where training reuses 4-d > tensors transposed, a very painful operation. > > In FORTRAN days, I once used a vector package in which you described a vector > by giving the first element, the second element, and a count.  So you could > describe rows, columns, a matrix diagonal, and even rows and columns from back > to front.  Fortran passed arguments by address, which made the whole thing easy > and fast. > > Steve Remember the words of that great performance pioneer Jimmy Durante: ras-a-ma-cas. From aap at papnet.eu Wed Sep 18 18:31:33 2019 From: aap at papnet.eu (Angelo Papenhoff) Date: Wed, 18 Sep 2019 10:31:33 +0200 Subject: [TUHS] cathode In-Reply-To: <009D825B-EF35-4310-8008-48EEB2D34D4B@jctaylor.com> References: <009D825B-EF35-4310-8008-48EEB2D34D4B@jctaylor.com> Message-ID: <20190918083133.GA47585@indra.papnet.eu> On 18/09/19, William Corcoran wrote: > Hello TUHS on Tues., > > Warren Toomey suggested I let the group know about a utility that exists at least for iMacs and IOS devices. > > It’s called “cathode” and you can find it on the Apple App Store. Please forgive me if this has already been mentioned. > > This utility provides for an xterm window that looks like the display an old *tube. You can set the curvature of the glass, the glow, various scan techniques, 9600 speed, and so on. For the non-OS Xers there's cool-retro-term: https://github.com/Swordfish90/cool-retro-term Personally I think it could look more realistic. Looks like they went for more of a movie-terminal look, but it's not easy to emulate a CRT convincingly. And I agree with Lars, I want cool-retro-asr33 (or 37) aap From tuhs at eric.allman.name Wed Sep 18 18:48:26 2019 From: tuhs at eric.allman.name (Eric Allman) Date: Wed, 18 Sep 2019 10:48:26 +0200 Subject: [TUHS] SCCS In-Reply-To: <20190916172300.cjlkf%steffen@sdaoden.eu> References: <20190911181101.GF3143@mcvoy.com> <20190912034346.GJ2046@mcvoy.com> <1457a2d6-2f17-482d-e4f7-ace439d34ca8@neophilic.com> <8db2e89c-ce50-a453-e38a-ecdfe69a746c@e-bbes.com> <20190913211104.aMZXy%steffen@sdaoden.eu> <20190913211751.GF2046@mcvoy.com> <20190913230312.XaeCQ%steffen@sdaoden.eu> <20190914015517.GD12480@mcvoy.com> <20190916172300.cjlkf%steffen@sdaoden.eu> Message-ID: <94341a28-723a-f177-f658-0c827b35591b@neophilic.com> On 2019-09-16 19:23 , Steffen Nurpmeso wrote: > One thing he says, and which is an interesting part of this > thread, is > > The statement of Eric Allman that Tichy used SCCS version > 1 i cannot believe, because Tichy's releases are from 1982, and > SCCS version 4 was released as earyl as February 1977. SCCS > version 3 used a binary history format, by the way. > > That should have addressed Eric Allman, but the longer i use email > in the public space the more i like that pub-like feeling. (And > not going to add that it reminds me of my childhood, where i was > a boy under elder seasoned men _also_.) I did not claim that Tichy used SCCS v1. It's worse than that. He only read the IEEE paper, which pre-dated RCS --- so far as I know he never even tried SCCS release 4 (current at the time Tichy published), which fixed the obvious problem in the release 1 design as originally published. Despite careful descriptions of the changes, he refused to stop slandering SCCS. He was truly standing on toes, not shoulders. eric From akosela at andykosela.com Wed Sep 18 19:05:54 2019 From: akosela at andykosela.com (Andy Kosela) Date: Wed, 18 Sep 2019 11:05:54 +0200 Subject: [TUHS] cathode In-Reply-To: <009D825B-EF35-4310-8008-48EEB2D34D4B@jctaylor.com> References: <009D825B-EF35-4310-8008-48EEB2D34D4B@jctaylor.com> Message-ID: On 9/18/19, William Corcoran wrote: > Hello TUHS on Tues., > > Warren Toomey suggested I let the group know about a utility that exists at > least for iMacs and IOS devices. > > It’s called “cathode” and you can find it on the Apple App Store. Please > forgive me if this has already been mentioned. > > This utility provides for an xterm window that looks like the display an old > *tube. You can set the curvature of the glass, the glow, various scan > techniques, 9600 speed, and so on. > > It adds that extra dimension to give the look and feel of working on early > UNIX with a tube. I used to run it, but I noticed it sucks battery like crazy. In the end I compromised on running X with good ol xterm on my MacBook. It is much more lightweight. Plus it is impossible to create a realistic CRT experience on LCD, especially in widescreen. All terminals were 4:3 and rather small from today point of view, but the sizes were just perfect for full screen text modes. I have tons of old terminals and CRT VGA monitors just so I can work on a real thing. There is something magical about the glow of phosphor on those old tubes. --Andy From wobblygong at gmail.com Wed Sep 18 19:06:54 2019 From: wobblygong at gmail.com (Wesley Parish) Date: Wed, 18 Sep 2019 21:06:54 +1200 Subject: [TUHS] A Couple of New Unix Artifacts In-Reply-To: References: <20190917095435.GA16333@minnie.tuhs.org> Message-ID: These are parts of my wish list: Larry McVoy's Sourceware tape is discovered; IBM donates the source and binaries for its obsolete Unixes; HP donates the source and binaries of the Intel port of Unixware; some of the late eighties/early nineties Unix CAD software gets donated. Dreams are free, of course. I'm not holding my breath ... :) Wesley Parish On 9/18/19, Arthur Krewat wrote: > My wish list is: > > - Oracle (or some other licensee) coughed up SunOS. Legally. > - AT&T or some other derivative coughed up SVR4(.2) > > Ok, that's all I got ;) > > But yes, I'm insane enough to want: Oracle coughing up Solaris 11.x(4?) > - legally. And I don't mean OpenSolaris. > > BTW - I know a certain institution I know, I'm pretty sure used V6 for a > graphics workstation. I'm pretty sure they had a source license, but I > could be wrong. What's the reality when it came to V6 being used > commercially in a product? This would be around the early 80's > timeframe. And certain law enforcement agencies actually used at least > one workstation for whatever reason. It would have run on MIcro-11's, > and MIcro-Vaxen. > > > On 9/17/2019 7:12 PM, Dave Horsfall wrote: >> On Tue, 17 Sep 2019, Warren Toomey wrote: >> >> [...] >> >>> Now you have a new topic to talk about :-) >> >> The infamous plaster cast of certain genitals (if it actually existed; >> the cast I mean)? >> >> -- Dave >> > > From usotsuki at buric.co Wed Sep 18 19:12:38 2019 From: usotsuki at buric.co (Steve Nickolas) Date: Wed, 18 Sep 2019 05:12:38 -0400 (EDT) Subject: [TUHS] cathode In-Reply-To: References: <009D825B-EF35-4310-8008-48EEB2D34D4B@jctaylor.com> Message-ID: On Wed, 18 Sep 2019, Andy Kosela wrote: > Plus it is impossible to create a realistic CRT experience on LCD, > especially in widescreen. All terminals were 4:3 and rather small > from today point of view, but the sizes were just perfect for full > screen text modes. > > I have tons of old terminals and CRT VGA monitors just so I can work > on a real thing. There is something magical about the glow of > phosphor on those old tubes. Nothing like the real thing. Man, I'd kill for another 5151 monitor (and something to use it with). Second to that I'd settle for an Apple monochrome display (either the Monitor ][ or the Monitor ///). -uso. From emu at e-bbes.com Wed Sep 18 18:49:03 2019 From: emu at e-bbes.com (emanuel stiebler) Date: Wed, 18 Sep 2019 10:49:03 +0200 Subject: [TUHS] PiDP-11 in action! In-Reply-To: References: Message-ID: <9999dcdf-34dd-2ad7-dfe0-d6cb0825b05b@e-bbes.com> On 2019-09-18 02:38, Adam Thornton wrote: > Busted EPROMs certainly would fit the symptoms.  What EPROM does a > MicroVAX 3100 use, and does simh have the requisite binary image?  I've > got a ROM burner.... Which model? Look at the label in the back ... From hpyle at cabezal.com Wed Sep 18 20:24:20 2019 From: hpyle at cabezal.com (Hugh Pyle) Date: Wed, 18 Sep 2019 06:24:20 -0400 Subject: [TUHS] cathode In-Reply-To: <20190918083133.GA47585@indra.papnet.eu> References: <009D825B-EF35-4310-8008-48EEB2D34D4B@jctaylor.com> <20190918083133.GA47585@indra.papnet.eu> Message-ID: > And I agree with Lars, I want cool-retro-asr33 (or 37) There's a nice 33 emulator here, with 10cps speed, overstrike, and other features https://github.com/Random832/ttyemu If you have the Teletype fonts installed, use my fork https://github.com/hughpyle/ttyemu Sound and smell are not yet implemented. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Thu Sep 19 00:01:07 2019 From: clemc at ccc.com (Clem Cole) Date: Wed, 18 Sep 2019 10:01:07 -0400 Subject: [TUHS] cathode In-Reply-To: <7wr24ejnba.fsf@junk.nocrew.org> References: <009D825B-EF35-4310-8008-48EEB2D34D4B@jctaylor.com> <7wr24ejnba.fsf@junk.nocrew.org> Message-ID: Lars, I agree but, you can't get the distinct smell of machine oil without something like 'smell-a-vision ' Bill, I've had Cathode since it first released it to try to demonstrate to some the younger set a little what it was like. I set up a Wyse-60, an H19 and my Mac running Cathode and let them play on a my simh based PiDP-11 running v6. Clem On Tue, Sep 17, 2019 at 11:28 PM Lars Brinkhoff wrote: > William Corcoran wrote: > > I would love to see profiles created that match actual ttys. > > I would love it if they matched actual teletypes. But that's for > another program. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Thu Sep 19 00:40:12 2019 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 18 Sep 2019 07:40:12 -0700 Subject: [TUHS] A Couple of New Unix Artifacts In-Reply-To: References: <20190917095435.GA16333@minnie.tuhs.org> Message-ID: <20190918144012.GV2046@mcvoy.com> On Wed, Sep 18, 2019 at 09:06:54PM +1200, Wesley Parish wrote: > These are parts of my wish list: > > Larry McVoy's Sourceware tape is discovered; That's unlikely to happen, I didn't keep a copy when it became clear that Sun wasn't going to do it. It would not be that hard to recreate it if SunOS 4.x were released. As I recall, it was A) Remove the STREAMS stuff. B) Go find the BSD tty driver and put it back. C) Remove RFS. D) Maybe a syscall or two that were there for RFS. From paul.winalski at gmail.com Thu Sep 19 01:35:37 2019 From: paul.winalski at gmail.com (Paul Winalski) Date: Wed, 18 Sep 2019 11:35:37 -0400 Subject: [TUHS] cathode In-Reply-To: <009D825B-EF35-4310-8008-48EEB2D34D4B@jctaylor.com> References: <009D825B-EF35-4310-8008-48EEB2D34D4B@jctaylor.com> Message-ID: On 9/17/19, William Corcoran wrote: > > I would love to see profiles created that match actual ttys. Can they duplicate that distinctive "raspberry" sound that the VT52 had for its bell? -Paul W. From athornton at gmail.com Thu Sep 19 01:39:11 2019 From: athornton at gmail.com (Adam Thornton) Date: Wed, 18 Sep 2019 08:39:11 -0700 Subject: [TUHS] PiDP-11 in action! In-Reply-To: <9999dcdf-34dd-2ad7-dfe0-d6cb0825b05b@e-bbes.com> References: <9999dcdf-34dd-2ad7-dfe0-d6cb0825b05b@e-bbes.com> Message-ID: > On Sep 18, 2019, at 1:49 AM, emanuel stiebler wrote: > > On 2019-09-18 02:38, Adam Thornton wrote: >> Busted EPROMs certainly would fit the symptoms. What EPROM does a >> MicroVAX 3100 use, and does simh have the requisite binary image? I've >> got a ROM burner.... > > Which model? Look at the label in the back ... VS43A-BD Adam From athornton at gmail.com Thu Sep 19 01:45:11 2019 From: athornton at gmail.com (Adam Thornton) Date: Wed, 18 Sep 2019 08:45:11 -0700 Subject: [TUHS] cathode In-Reply-To: References: <009D825B-EF35-4310-8008-48EEB2D34D4B@jctaylor.com> Message-ID: <9F4B368B-EA41-4E8D-879A-1CB8181D615F@gmail.com> > On Sep 18, 2019, at 2:05 AM, Andy Kosela wrote: > I used to run it, but I noticed it sucks battery like crazy. In the > end I compromised on running X with good ol xterm on my MacBook. It > is much more lightweight. I’m a big fan of iTerm2 (if I don’t need X). It doesn’t do any CRT emulation stuff, but it’s very configurable, Python-scriptable, has built-in tmux, very configurable mouse and wheel support, decent contextual highlighting, et cetera. Adam From web at loomcom.com Thu Sep 19 02:33:37 2019 From: web at loomcom.com (Seth Morabito) Date: Wed, 18 Sep 2019 09:33:37 -0700 Subject: [TUHS] A Couple of New Unix Artifacts In-Reply-To: <20190917095435.GA16333@minnie.tuhs.org> References: <20190917095435.GA16333@minnie.tuhs.org> Message-ID: On Tue, Sep 17, 2019, at 2:54 AM, Warren Toomey wrote: > > and I am going slowly crazy as I wait for them to be offically released. > And you just had to share the pain, eh? :^) I look forward to the announcements with bated breath! I do secretly hope one is related to System V, since I've been working with SVR2/3/4 in such a grey area for so long, but I will be glad to see them no matter what they are. -Seth -- Seth Morabito Poulsbo, WA web at loomcom.com From steffen at sdaoden.eu Thu Sep 19 03:33:18 2019 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Wed, 18 Sep 2019 19:33:18 +0200 Subject: [TUHS] SCCS In-Reply-To: <94341a28-723a-f177-f658-0c827b35591b@neophilic.com> References: <20190911181101.GF3143@mcvoy.com> <20190912034346.GJ2046@mcvoy.com> <1457a2d6-2f17-482d-e4f7-ace439d34ca8@neophilic.com> <8db2e89c-ce50-a453-e38a-ecdfe69a746c@e-bbes.com> <20190913211104.aMZXy%steffen@sdaoden.eu> <20190913211751.GF2046@mcvoy.com> <20190913230312.XaeCQ%steffen@sdaoden.eu> <20190914015517.GD12480@mcvoy.com> <20190916172300.cjlkf%steffen@sdaoden.eu> <94341a28-723a-f177-f658-0c827b35591b@neophilic.com> Message-ID: <20190918173318.o9sxO%steffen@sdaoden.eu> Eric Allman wrote in <94341a28-723a-f177-f658-0c827b35591b at neophilic.com>: |On 2019-09-16 19:23 , Steffen Nurpmeso wrote: |> One thing he says, and which is an interesting part of this |> thread, is |> |> The statement of Eric Allman that Tichy used SCCS version |> 1 i cannot believe, because Tichy's releases are from 1982, and |> SCCS version 4 was released as earyl as February 1977. SCCS |> version 3 used a binary history format, by the way. |> |> That should have addressed Eric Allman, but the longer i use email |> in the public space the more i like that pub-like feeling. (And |> not going to add that it reminds me of my childhood, where i was |> a boy under elder seasoned men _also_.) | |I did not claim that Tichy used SCCS v1. It's worse than that. He only |read the IEEE paper, which pre-dated RCS --- so far as I know he never |even tried SCCS release 4 (current at the time Tichy published), which |fixed the obvious problem in the release 1 design as originally |published. Despite careful descriptions of the changes, he refused to |stop slandering SCCS. He was truly standing on toes, not shoulders. Thank you. I will forward your response to Jörg. --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 a.phillip.garcia at gmail.com Thu Sep 19 07:17:29 2019 From: a.phillip.garcia at gmail.com (A. P. Garcia) Date: Wed, 18 Sep 2019 17:17:29 -0400 Subject: [TUHS] A Couple of New Unix Artifacts In-Reply-To: References: <20190917095435.GA16333@minnie.tuhs.org> Message-ID: On Wed, Sep 18, 2019 at 12:41 PM Seth Morabito wrote: > > > > On Tue, Sep 17, 2019, at 2:54 AM, Warren Toomey wrote: > > > > and I am going slowly crazy as I wait for them to be offically released. > > > > And you just had to share the pain, eh? :^) > > I look forward to the announcements with bated breath! I do secretly hope one is related to System V, since I've been working with SVR2/3/4 in such a grey area for so long, but I will be glad to see them no matter what they are. > > -Seth > -- > Seth Morabito > Poulsbo, WA > web at loomcom.com It's not what I was expecting, and probably not what Warren was referring to, but Microsoft open sourced their C++ Standard Library. I would say that's nontrivial, at least. https://github.com/microsoft/STL From sergioag at qmailhosting.net Thu Sep 19 09:05:32 2019 From: sergioag at qmailhosting.net (Sergio Aguayo) Date: Thu, 19 Sep 2019 01:05:32 +0200 (CEST) Subject: [TUHS] A Couple of New Unix Artifacts In-Reply-To: <20190917095435.GA16333@minnie.tuhs.org> References: <20190917095435.GA16333@minnie.tuhs.org> Message-ID: <1045827859.49123.1568847932946.JavaMail.zimbra@qmailhosting.net> May I ask about the definition of "soon"? From: "Warren Toomey" To: tuhs at tuhs.org Sent: Tuesday, September 17, 2019 4:54:35 AM Subject: [TUHS] A Couple of New Unix Artifacts I fear we're drifting a bit here and the S/N ratio is dropping a bit w.r.t the actual history of Unix. Please no more on the relative merits of version control systems or alternative text processing systems. So I'll try to distract you by saying this. I'm sitting on two artifacts that have recently been given to me: + by two large organisations + of great significance to Unix history + who want me to keep "mum" about them + as they are going to make announcements about them soon * and I am going slowly crazy as I wait for them to be offically released. Now you have a new topic to talk about :-) Cheers, Warren * for some definition of "soon" -------------- next part -------------- An HTML attachment was scrubbed... URL: From wkt at tuhs.org Thu Sep 19 09:25:41 2019 From: wkt at tuhs.org (Warren Toomey) Date: Thu, 19 Sep 2019 09:25:41 +1000 Subject: [TUHS] A Couple of New Unix Artifacts In-Reply-To: <1045827859.49123.1568847932946.JavaMail.zimbra@qmailhosting.net> References: <20190917095435.GA16333@minnie.tuhs.org> <1045827859.49123.1568847932946.JavaMail.zimbra@qmailhosting.net> Message-ID: <20190918232541.GA8434@minnie.tuhs.org> On Thu, Sep 19, 2019 at 01:05:32AM +0200, Sergio Aguayo via TUHS wrote: > May I ask about the definition of "soon"? Yes, I asked that question too :-) The answer is to coincide with the Unix 50th anniversary events that are scheduled for this year. Warren From nw at retrocomputingtasmania.com Thu Sep 19 10:42:14 2019 From: nw at retrocomputingtasmania.com (Nigel Williams) Date: Thu, 19 Sep 2019 10:42:14 +1000 Subject: [TUHS] A Couple of New Unix Artifacts In-Reply-To: <20190918232541.GA8434@minnie.tuhs.org> References: <20190917095435.GA16333@minnie.tuhs.org> <1045827859.49123.1568847932946.JavaMail.zimbra@qmailhosting.net> <20190918232541.GA8434@minnie.tuhs.org> Message-ID: IBM open-sourcing AIX? Apple releases A/UX source? Personally I would like PRIMIX (UNIX overlay for PRIMOS) to be found, but I appreciate that is the narrowest of niches :-) From gregg.drwho8 at gmail.com Thu Sep 19 11:35:21 2019 From: gregg.drwho8 at gmail.com (Gregg Levine) Date: Wed, 18 Sep 2019 21:35:21 -0400 Subject: [TUHS] A Couple of New Unix Artifacts In-Reply-To: References: <20190917095435.GA16333@minnie.tuhs.org> <1045827859.49123.1568847932946.JavaMail.zimbra@qmailhosting.net> <20190918232541.GA8434@minnie.tuhs.org> Message-ID: Hello! I'll add to that. The entire set of XENIX stuff. And a release of the SunOs stuff., But let us be patient. Warren will advise us when the time comes. ----- Gregg C Levine gregg.drwho8 at gmail.com "This signature fought the Time Wars, time and again." On Wed, Sep 18, 2019 at 8:43 PM Nigel Williams wrote: > > IBM open-sourcing AIX? > Apple releases A/UX source? > > Personally I would like PRIMIX (UNIX overlay for PRIMOS) to be found, > but I appreciate that is the narrowest of niches :-) From lars at nocrew.org Thu Sep 19 15:06:02 2019 From: lars at nocrew.org (Lars Brinkhoff) Date: Thu, 19 Sep 2019 05:06:02 +0000 Subject: [TUHS] A Couple of New Unix Artifacts In-Reply-To: (Gregg Levine's message of "Wed, 18 Sep 2019 21:35:21 -0400") References: <20190917095435.GA16333@minnie.tuhs.org> <1045827859.49123.1568847932946.JavaMail.zimbra@qmailhosting.net> <20190918232541.GA8434@minnie.tuhs.org> Message-ID: <7w4l18j2o5.fsf@junk.nocrew.org> Is this the place to send Christmas wish lists? I would like to see Space Travel. There's a PDP-7 ready to do. From norman at oclsc.org Fri Sep 20 04:10:45 2019 From: norman at oclsc.org (Norman Wilson) Date: Thu, 19 Sep 2019 14:10:45 -0400 Subject: [TUHS] earliest Unix roff Message-ID: <1568916649.17313.for-standards-violators@oclsc.org> Larry McVoy: If you have something like perl that needs a zillion sub pages, info makes sense. For just a man page, info is horrible. ===== This pokes me in one of my longest-standing complaints: Manual entries, as printed by man and once upon a time in the Programmers' Manual Volume 1, should be concise references. They are not a place for tutorials or long-winded descriptions or even long lists of hundreds of options (let alone descriptions of why the developer thinks this is the neatest thing since sliced bread and what bread he had in his sandwiches that day). For many programs, one or two pages of concise reference is all the documentation that's needed; no one needs a ten-page tutorial on how to use cat or rm or ls, for example. But some programs really do deserve a longer treatment, either a tutorial or an extended reference with more detail or both. Those belong in separate documents, and are why the Programmers' Manual had a second volume. Nowadays people think nothing of writing 68-page-long manual entries (real example from something I'm working with right now) that are long, chatty lists of options or configuration-file directives with tutorial information interspersed. The result makes the developer feel good--look at all the documentation I've written!!--but it's useless for someone trying to figure out how to write a configuration file for the first time, and not so great even for someone trying to edit an existing one. Even the Research system didn't always get this right; some manual entries ran on and on and on when what was really needed was a concise list of something and a longer accompanying document. (The Tenth Edition manual was much better about that, mostly because of all the work Doug put in. I doubt there has ever been a better editor for technical text than Doug.) But it's far worse now in most systems, because there's rarely any editor at all; the manuals are just an accreted clump. And that's a shame, though I have no suggestions on how to fix it. Norman Wilson Toronto ON From clemc at ccc.com Fri Sep 20 04:37:05 2019 From: clemc at ccc.com (Clem Cole) Date: Thu, 19 Sep 2019 14:37:05 -0400 Subject: [TUHS] earliest Unix roff In-Reply-To: <1568916649.17313.for-standards-violators@oclsc.org> References: <1568916649.17313.for-standards-violators@oclsc.org> Message-ID: On Thu, Sep 19, 2019 at 2:11 PM Norman Wilson wrote: > Manual entries, as printed by man and once upon a time in > the Programmers' Manual Volume 1, should be concise references. > They are not a place for tutorials or long-winded descriptions > or even long lists of hundreds of options (let alone descriptions > of why the developer thinks this is the neatest thing since > sliced bread and what bread he had in his sandwiches that day). > > For many programs, one or two pages of concise reference is > all the documentation that's needed; no one needs a ten-page > tutorial on how to use cat or rm or ls, for example. But some > programs really do deserve a longer treatment, either a tutorial > or an extended reference with more detail or both. Those belong > in separate documents, and are why the Programmers' Manual had > a second volume. > > Nowadays people think nothing of writing 68-page-long manual > entries (real example from something I'm working with right now) > that are long, chatty lists of options or configuration-file > directives with tutorial information interspersed. The result > makes the developer feel good--look at all the documentation > I've written!!--but it's useless for someone trying to figure > out how to write a configuration file for the first time, and > not so great even for someone trying to edit an existing one. > > Even the Research system didn't always get this right; some > manual entries ran on and on and on when what was really > needed was a concise list of something and a longer accompanying > document. (The Tenth Edition manual was much better about > that, mostly because of all the work Doug put in. I doubt > there has ever been a better editor for technical text than > Doug.) But it's far worse now in most systems, because > there's rarely any editor at all; the manuals are just an > accreted clump. > > And that's a shame, though I have no suggestions on how > to fix it. > > +1 -------------- next part -------------- An HTML attachment was scrubbed... URL: From norman at oclsc.org Fri Sep 20 04:42:58 2019 From: norman at oclsc.org (Norman Wilson) Date: Thu, 19 Sep 2019 14:42:58 -0400 Subject: [TUHS] earliest Unix roff Message-ID: <1568918582.18253.for-standards-violators@oclsc.org> Clem Cole: Exactly!!!! That's what Eric did when he wrote more(ucb) - he *added to Unix*. The funny part was that USG thought more(ucb) was a good idea and then wrote their own, pg(att); which was just as arrogant as the info behavior from the Gnu folks!!! ====== And others wrote their own too, of course. The one I know best is p(1), written by Rob Pike in the late 1970s at the University of Toronto. I encountered at Caltech on the system Rob had set up before leaving for Bell Labs (and which I cared for and hacked on for the next four years before following him). By the time I reached BTL it was a normal part of the Research system; I believe it's in all of the Eighth, Ninth, and Tenth Edition manuals. p is interesting because it's so much lighter-weight, and because it has rather a different interior design: Rather than doing termcappy things, p just prints 22 lines (or the number specified in an option), then doesn't print the newline after the 22nd line. Hit return and it will print the next 22 lines, and so on. The resulting text just flows up the glass-tty screen without any fuss, cbreak, or anything. (I believe the first version predated V7 and therefore cbreak.) Why 22 lines instead of 24, the common height of glass ttys back then? Partly because that means you keep a line or two of context when advancing pages, making reading simpler. But also because in those days, a standard page destined for a printer (e.g. from pr or nroff, and therefore from man) was 66 lines long. 22 evenly divides 66, so man something | p never gives you a screen spanning pages. p was able to back up: type - (and return) instead of just return, and it reprints the previous 22-line page; -- (return) the 22 lines before that; and so on. This was implemented in an interesting and clever way: a wrapper around the standard I/O library which kept a circular buffer of some fixed number of characters (8KiB in early versions, I think), and a new call that, in effect, backed up the file pointer by one character and returned the character just backed over. That made it easy to back over the previous N lines: just make that call until you've seen N newlines, then discard the newline you've just backed over, and you're at the beginning the first line you want to reprint. As I vaguely recall, more was able to back up, but only when reading from a real file, not a pipeline. p could do (limited but sufficient) backup from a pipeline too. As a creature of its pre-window-system era, you could also type !command when p paused as well. I remember being quite interested in that wrapper as a possible library for use in other things, though I never found a use for it. I also remember a wonderful Elements-of-Programming-Style adventure with Rob's code. I discovered it had a bug under some specific case when read returned less than a full bufferful. I read the code carefully and couldn't see what was wrong. So I wrote my own replacement for the problematic subroutine from scratch, tested it carefully in corner cases, then with listings of Rob's code and mine side-by-side walked through each with the problem case and found the bug. I still carry my own version of p (rewritten from scratch mainly to make it more portable--Rob's code was old enough to be too clever in some details) wherever I go; ironically, even back to U of T where I have been on and off for the past 30 years. more and less and pg and the like are certainly useful programs; for various reasons they're not to my taste, but I don't scorn them. But I can't help being particular fond of p because it taught me a few things about programming too. Norman Wilson Toronto ON From jon at fourwinds.com Fri Sep 20 04:44:34 2019 From: jon at fourwinds.com (Jon Steinhart) Date: Thu, 19 Sep 2019 11:44:34 -0700 Subject: [TUHS] earliest Unix roff In-Reply-To: References: <1568916649.17313.for-standards-violators@oclsc.org> Message-ID: <201909191844.x8JIiYoP018979@darkstar.fourwinds.com> Clem Cole writes: > > On Thu, Sep 19, 2019 at 2:11 PM Norman Wilson wrote: > > > Manual entries, as printed by man and once upon a time in > > the Programmers' Manual Volume 1, should be concise references. > > They are not a place for tutorials or long-winded descriptions > > or even long lists of hundreds of options (let alone descriptions > > of why the developer thinks this is the neatest thing since > > sliced bread and what bread he had in his sandwiches that day). > > > > For many programs, one or two pages of concise reference is > > all the documentation that's needed; no one needs a ten-page > > tutorial on how to use cat or rm or ls, for example. But some > > programs really do deserve a longer treatment, either a tutorial > > or an extended reference with more detail or both. Those belong > > in separate documents, and are why the Programmers' Manual had > > a second volume. > > > > Nowadays people think nothing of writing 68-page-long manual > > entries (real example from something I'm working with right now) > > that are long, chatty lists of options or configuration-file > > directives with tutorial information interspersed. The result > > makes the developer feel good--look at all the documentation > > I've written!!--but it's useless for someone trying to figure > > out how to write a configuration file for the first time, and > > not so great even for someone trying to edit an existing one. > > > > Even the Research system didn't always get this right; some > > manual entries ran on and on and on when what was really > > needed was a concise list of something and a longer accompanying > > document. (The Tenth Edition manual was much better about > > that, mostly because of all the work Doug put in. I doubt > > there has ever been a better editor for technical text than > > Doug.) But it's far worse now in most systems, because > > there's rarely any editor at all; the manuals are just an > > accreted clump. > > > > And that's a shame, though I have no suggestions on how > > to fix it. > > > > +1 This is sort of my late in life mission. Here's a description of a session that I've proposed for an upcoming conference. Once upon a time there was Budweiser. Then, along came craft beer which started a movement. Now, one can find a whole range of offerings from craft cheese to artisanal baking soda. Hard to find is craft programming. What’s called "programming technology" today seems to be the art of minimizing the damage that can be done by monkeys at keyboards. Since we can no longer purchase even a toothpick that doesn’t contain a processor and a blue LED, we depend on code. How can we revive the art of programming? How do we foster the creation of good code instead of spending energy minimizing the damage that can be done by bad code? Our lives depend on it. My two cents is that craft programmers know how to write good documentation. Probably one of the things that made BTL so wonderful was the breadth of knowledge that people had. Ken was recently telling me about Lee McMahon who was a classically trained monk in addition to writing qsort for V3. From norman at oclsc.org Fri Sep 20 04:50:26 2019 From: norman at oclsc.org (Norman Wilson) Date: Thu, 19 Sep 2019 14:50:26 -0400 Subject: [TUHS] [OT] Re: earliest Unix roff Message-ID: <1568919029.18595.for-standards-violators@oclsc.org> KatolaZ: > We can discuss whether the split was necessary or "right" in the first > instance, as we could discuss whether it was good or not for cat(1) to > leave Murray Hill in 1979 with no options and come back from Berkley > with a source code doubled in size and 9 options in 1982. We needn't discuss that (though of course there are opinions and mine are the correct ones), but in the interest of historic accuracy, I should point out by 1979 (V7) cat had developed a single option -u to turn off stdio buffering. Sometime before 1984 or so, that option was removed, and cat was simplified to just while ((n = read(fd, buf, sizeof(buf))) > 0) write(1, buf, n) (error checking elided for clarity) which worked just fine for the rest of the life of the Research system. So it's true that BSD added needless (in my humble but correct opinion) options, but not that it had none before they touched it. Unless all those other programs were stuffed into cat in an earlier Berkeley system, but I don't think they were. Norman Wilson Toronto ON (Three cats, no options) From cym224 at gmail.com Fri Sep 20 05:00:16 2019 From: cym224 at gmail.com (Nemo Nusquam) Date: Thu, 19 Sep 2019 15:00:16 -0400 Subject: [TUHS] [OT] Re: earliest Unix roff In-Reply-To: <1568919029.18595.for-standards-violators@oclsc.org> References: <1568919029.18595.for-standards-violators@oclsc.org> Message-ID: On 09/19/19 14:50, Norman Wilson wrote (in part): > So it's true that BSD added needless (in my humble but correct > opinion) options, but not that it had none before they touched it. > Unless all those other programs were stuffed into cat in an earlier > Berkeley system, but I don't think they were. Who said "Cat came back from Berkeley waving flags."? N. > Norman Wilson > Toronto ON > (Three cats, no options) From steffen at sdaoden.eu Fri Sep 20 05:44:15 2019 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Thu, 19 Sep 2019 21:44:15 +0200 Subject: [TUHS] earliest Unix roff In-Reply-To: <1568916649.17313.for-standards-violators@oclsc.org> References: <1568916649.17313.for-standards-violators@oclsc.org> Message-ID: <20190919194415.Tp6NO%steffen@sdaoden.eu> Norman Wilson wrote in <1568916649.17313.for-standards-violators at oclsc.org>: |Larry McVoy: | | If you have something like perl that needs a zillion sub pages, info | makes sense. For just a man page, info is horrible. | |===== | |This pokes me in one of my longest-standing complaints: | |Manual entries, as printed by man and once upon a time in |the Programmers' Manual Volume 1, should be concise references. |They are not a place for tutorials or long-winded descriptions |or even long lists of hundreds of options (let alone descriptions |of why the developer thinks this is the neatest thing since |sliced bread and what bread he had in his sandwiches that day). | |For many programs, one or two pages of concise reference is |all the documentation that's needed; no one needs a ten-page |tutorial on how to use cat or rm or ls, for example. But some |programs really do deserve a longer treatment, either a tutorial |or an extended reference with more detail or both. Those belong |in separate documents, and are why the Programmers' Manual had |a second volume. | |Nowadays people think nothing of writing 68-page-long manual |entries (real example from something I'm working with right now) |that are long, chatty lists of options or configuration-file |directives with tutorial information interspersed. The result |makes the developer feel good--look at all the documentation |I've written!!--but it's useless for someone trying to figure |out how to write a configuration file for the first time, and |not so great even for someone trying to edit an existing one. | |Even the Research system didn't always get this right; some I totally disagree with you. Whereas i even admire McIlroy's "concise", and really love reading Plan9 manual pages, and that not only because one can imagine _who_ put their fingers on those, i think manual pages should enable people to work with a program. And not only intellectual elite, the absolute top of the pops gathered together in this cave and grooving with a pict, but "everybody" to the extend possible. If i would have a lot of money in spare i could hire teams of three people each which rotate through the develop / test / documentation cycle, and around each others work. But that is not how it goes here, you add a feature and write down the docs, you extend one and patch in doc where you think it belongs, yet get infos from someone and patch in doc to clarify something. You do all that short on time, and finally you have a rag rug. So what you would need then is time to step back, let time pass, come back with fresh eyes, reread the entire documentation once, reflect, and work it all over. Add the complications of not being a native speaker. For some projects, add many translations done by volunteers, which you leave behind if you adhere to this work cycle. (But do not if you just patch up.) You could of course split the manual into several subsections, but which one to split, which not. Duplicate several, for example command line options, which can initiate complicate tasks, which need a lengthy text to become understandable? Who is going to do all that work? Who is the one who will spend the time and strength necessary to keep all the individual parts in sync? For example, this week (at least the latter commit) on FreeBSD the ZFS filesystem, thus a crucial part of the infrastructure of FreeBSD (no Hammer or BTRFS support), the i guess second largest free software environment, with quite some people getting paid for working on the code base, was extended (i do not use ZFS), but even the help string of the managing tool was not updated until a follow up commit several days later fixed that! So for me this is not feasible. I have the manual, and i have the help string output for -h / --help, and a longer (long option) one with --long-help. If you want a quick shot, use -h. If you need documentation, use the manual. #?0|kent:mk$ man -l ../nail.1|wc -l troff: :14382: name expected (got '\c'): treated as missing 8172 Without TOC and anchors. bug in groff mdoc macros in 1.22.3, by the way (.Lk i guessed). #?0|kent:mk$ mdoc ../nail.1|wc -l 8307 With TOC and hundreds of internal and external anchors. #?0|kent:mk$ /tmp/y/s-nail -h|wc -l 24 #?0|kent:mk$ /tmp/y/s-nail --long-help|wc -l 57 |manual entries ran on and on and on when what was really |needed was a concise list of something and a longer accompanying |document. (The Tenth Edition manual was much better about |that, mostly because of all the work Doug put in. I doubt |there has ever been a better editor for technical text than |Doug.) But it's far worse now in most systems, because |there's rarely any editor at all; the manuals are just an |accreted clump. | |And that's a shame, though I have no suggestions on how |to fix it. I do not know either. The car industry has the many pictures but no content (for people who spend money), a repair manual for underpaid mechanics, and detailed spare part foils for those people working in the dusty spare parts depot. That at least thirty years ago when i snuffled into that industry. |Norman Wilson |Toronto ON --End of <1568916649.17313.for-standards-violators at oclsc.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 lm at mcvoy.com Fri Sep 20 06:18:33 2019 From: lm at mcvoy.com (Larry McVoy) Date: Thu, 19 Sep 2019 13:18:33 -0700 Subject: [TUHS] [OT] Re: earliest Unix roff In-Reply-To: References: <1568919029.18595.for-standards-violators@oclsc.org> Message-ID: <20190919201833.GN2046@mcvoy.com> On Thu, Sep 19, 2019 at 03:00:16PM -0400, Nemo Nusquam wrote: > On 09/19/19 14:50, Norman Wilson wrote (in part): > >So it's true that BSD added needless (in my humble but correct > >opinion) options, but not that it had none before they touched it. > >Unless all those other programs were stuffed into cat in an earlier > >Berkeley system, but I don't think they were. > > Who said "Cat came back from Berkeley waving flags."? Rob Pike From krewat at kilonet.net Fri Sep 20 06:33:56 2019 From: krewat at kilonet.net (Arthur Krewat) Date: Thu, 19 Sep 2019 16:33:56 -0400 Subject: [TUHS] [OT] Re: earliest Unix roff In-Reply-To: <20190919201833.GN2046@mcvoy.com> References: <1568919029.18595.for-standards-violators@oclsc.org> <20190919201833.GN2046@mcvoy.com> Message-ID: <19f9233f-6f54-46eb-116f-990660ca2a76@kilonet.net> Serious question: Which is better, creating a whole new binary to put in /usr/bin to do a single task, or add a flag to cat? Which is better, a proliferation of binaries w/standalone source code, or a single code tree that can handle slightly different tasks and save space? :) art k. PS: Using argv[0] (as in a symbolic link) to alter a program's behavior instead of using flags is cheating on the above test. On 9/19/2019 4:18 PM, Larry McVoy wrote: > On Thu, Sep 19, 2019 at 03:00:16PM -0400, Nemo Nusquam wrote: >> On 09/19/19 14:50, Norman Wilson wrote (in part): >>> So it's true that BSD added needless (in my humble but correct >>> opinion) options, but not that it had none before they touched it. >>> Unless all those other programs were stuffed into cat in an earlier >>> Berkeley system, but I don't think they were. >> Who said "Cat came back from Berkeley waving flags."? > Rob Pike > From jpl.jpl at gmail.com Fri Sep 20 06:38:51 2019 From: jpl.jpl at gmail.com (John P. Linderman) Date: Thu, 19 Sep 2019 16:38:51 -0400 Subject: [TUHS] earliest Unix roff In-Reply-To: <20190919194415.Tp6NO%steffen@sdaoden.eu> References: <1568916649.17313.for-standards-violators@oclsc.org> <20190919194415.Tp6NO%steffen@sdaoden.eu> Message-ID: In the early 70's, Marc Rochkind recommended re-reading the entire UNIX manual yearly. Back then, it was doable. Now it is probably growing faster than I can read. There is a place for a *concise* description of each command, and a separate place for tutorials and conference papers. On Thu, Sep 19, 2019 at 3:44 PM Steffen Nurpmeso wrote: > Norman Wilson wrote in <1568916649.17313.for-standards-violators at oclsc.org > >: > |Larry McVoy: > | > | If you have something like perl that needs a zillion sub pages, info > | makes sense. For just a man page, info is horrible. > | > |===== > | > |This pokes me in one of my longest-standing complaints: > | > |Manual entries, as printed by man and once upon a time in > |the Programmers' Manual Volume 1, should be concise references. > |They are not a place for tutorials or long-winded descriptions > |or even long lists of hundreds of options (let alone descriptions > |of why the developer thinks this is the neatest thing since > |sliced bread and what bread he had in his sandwiches that day). > | > |For many programs, one or two pages of concise reference is > |all the documentation that's needed; no one needs a ten-page > |tutorial on how to use cat or rm or ls, for example. But some > |programs really do deserve a longer treatment, either a tutorial > |or an extended reference with more detail or both. Those belong > |in separate documents, and are why the Programmers' Manual had > |a second volume. > | > |Nowadays people think nothing of writing 68-page-long manual > |entries (real example from something I'm working with right now) > |that are long, chatty lists of options or configuration-file > |directives with tutorial information interspersed. The result > |makes the developer feel good--look at all the documentation > |I've written!!--but it's useless for someone trying to figure > |out how to write a configuration file for the first time, and > |not so great even for someone trying to edit an existing one. > | > |Even the Research system didn't always get this right; some > > I totally disagree with you. Whereas i even admire McIlroy's > "concise", and really love reading Plan9 manual pages, and that > not only because one can imagine _who_ put their fingers on those, > i think manual pages should enable people to work with a program. > And not only intellectual elite, the absolute top of the pops > gathered together in this cave and grooving with a pict, but > "everybody" to the extend possible. > > If i would have a lot of money in spare i could hire teams of > three people each which rotate through the develop / test > / documentation cycle, and around each others work. But that is > not how it goes here, you add a feature and write down the docs, > you extend one and patch in doc where you think it belongs, yet > get infos from someone and patch in doc to clarify something. You > do all that short on time, and finally you have a rag rug. > > So what you would need then is time to step back, let time pass, > come back with fresh eyes, reread the entire documentation once, > reflect, and work it all over. > > Add the complications of not being a native speaker. > For some projects, add many translations done by volunteers, which > you leave behind if you adhere to this work cycle. (But do not if > you just patch up.) > > You could of course split the manual into several subsections, but > which one to split, which not. Duplicate several, for example > command line options, which can initiate complicate tasks, which > need a lengthy text to become understandable? > > Who is going to do all that work? Who is the one who will spend > the time and strength necessary to keep all the individual parts > in sync? For example, this week (at least the latter commit) on > FreeBSD the ZFS filesystem, thus a crucial part of the > infrastructure of FreeBSD (no Hammer or BTRFS support), the > i guess second largest free software environment, with quite some > people getting paid for working on the code base, was extended (i > do not use ZFS), but even the help string of the managing tool was > not updated until a follow up commit several days later fixed > that! > > So for me this is not feasible. I have the manual, and i have the > help string output for -h / --help, and a longer (long option) one > with --long-help. If you want a quick shot, use -h. If you need > documentation, use the manual. > > #?0|kent:mk$ man -l ../nail.1|wc -l > troff: :14382: name expected (got '\c'): treated as > missing > 8172 > > Without TOC and anchors. > bug in groff mdoc macros in 1.22.3, by the way (.Lk i guessed). > > #?0|kent:mk$ mdoc ../nail.1|wc -l > 8307 > > With TOC and hundreds of internal and external anchors. > > #?0|kent:mk$ /tmp/y/s-nail -h|wc -l > 24 > #?0|kent:mk$ /tmp/y/s-nail --long-help|wc -l > 57 > > |manual entries ran on and on and on when what was really > |needed was a concise list of something and a longer accompanying > |document. (The Tenth Edition manual was much better about > |that, mostly because of all the work Doug put in. I doubt > |there has ever been a better editor for technical text than > |Doug.) But it's far worse now in most systems, because > |there's rarely any editor at all; the manuals are just an > |accreted clump. > | > |And that's a shame, though I have no suggestions on how > |to fix it. > > I do not know either. The car industry has the many pictures but > no content (for people who spend money), a repair manual for > underpaid mechanics, and detailed spare part foils for those > people working in the dusty spare parts depot. That at least > thirty years ago when i snuffled into that industry. > > |Norman Wilson > |Toronto ON > --End of <1568916649.17313.for-standards-violators at oclsc.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) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon at fourwinds.com Fri Sep 20 06:39:31 2019 From: jon at fourwinds.com (Jon Steinhart) Date: Thu, 19 Sep 2019 13:39:31 -0700 Subject: [TUHS] [OT] Re: earliest Unix roff In-Reply-To: <19f9233f-6f54-46eb-116f-990660ca2a76@kilonet.net> References: <1568919029.18595.for-standards-violators@oclsc.org> <20190919201833.GN2046@mcvoy.com> <19f9233f-6f54-46eb-116f-990660ca2a76@kilonet.net> Message-ID: <201909192039.x8JKdVtQ003479@darkstar.fourwinds.com> Arthur Krewat writes: > Serious question: > > Which is better, creating a whole new binary to put in /usr/bin to do a > single task, or add a flag to cat? > > Which is better, a proliferation of binaries w/standalone source code, > or a single code tree that can handle slightly different tasks and save > space? > > :) > > art k. > > PS: Using argv[0] (as in a symbolic link) to alter a program's behavior > instead of using flags is cheating on the above test. I would argue the first. In the case of current linux cat, I would make a separate utility to number lines, a separate utility to squeeze out repeated empty blank lines, a separate utility to show non printing characters that might have an option to select the characters that would encompass -T. All of these are useful utilities by themselves. Someone using a particular combo of options a lot can always write their own scripts or use aliases. That's the beauty of composability. Jon From akosela at andykosela.com Fri Sep 20 06:42:56 2019 From: akosela at andykosela.com (Andy Kosela) Date: Thu, 19 Sep 2019 22:42:56 +0200 Subject: [TUHS] earliest Unix roff In-Reply-To: <20190919201833.GN2046@mcvoy.com> References: <1568919029.18595.for-standards-violators@oclsc.org> <20190919201833.GN2046@mcvoy.com> Message-ID: On Thursday, September 19, 2019, Larry McVoy wrote: > On Thu, Sep 19, 2019 at 03:00:16PM -0400, Nemo Nusquam wrote: > > On 09/19/19 14:50, Norman Wilson wrote (in part): > > >So it's true that BSD added needless (in my humble but correct > > >opinion) options, but not that it had none before they touched it. > > >Unless all those other programs were stuffed into cat in an earlier > > >Berkeley system, but I don't think they were. > > > > Who said "Cat came back from Berkeley waving flags."? > > Rob Pike > http://harmful.cat-v.org/cat-v/ --Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From bakul at bitblocks.com Fri Sep 20 06:53:19 2019 From: bakul at bitblocks.com (Bakul Shah) Date: Thu, 19 Sep 2019 13:53:19 -0700 Subject: [TUHS] earliest Unix roff In-Reply-To: <1568916649.17313.for-standards-violators@oclsc.org> References: <1568916649.17313.for-standards-violators@oclsc.org> Message-ID: <7864DEA0-E980-4AAA-B5C0-059B6548C7DA@bitblocks.com> On Sep 19, 2019, at 11:10 AM, Norman Wilson wrote: > > This pokes me in one of my longest-standing complaints: > > Manual entries, as printed by man and once upon a time in > the Programmers' Manual Volume 1, should be concise references. > They are not a place for tutorials or long-winded descriptions > or even long lists of hundreds of options (let alone descriptions > of why the developer thinks this is the neatest thing since > sliced bread and what bread he had in his sandwiches that day). > > For many programs, one or two pages of concise reference is > all the documentation that's needed; no one needs a ten-page > tutorial on how to use cat or rm or ls, for example. But some > programs really do deserve a longer treatment, either a tutorial > or an extended reference with more detail or both. Those belong > in separate documents, and are why the Programmers' Manual had > a second volume. > > Nowadays people think nothing of writing 68-page-long manual > entries (real example from something I'm working with right now) > that are long, chatty lists of options or configuration-file > directives with tutorial information interspersed. The result > makes the developer feel good--look at all the documentation > I've written!!--but it's useless for someone trying to figure > out how to write a configuration file for the first time, and > not so great even for someone trying to edit an existing one. > > Even the Research system didn't always get this right; some > manual entries ran on and on and on when what was really > needed was a concise list of something and a longer accompanying > document. (The Tenth Edition manual was much better about > that, mostly because of all the work Doug put in. I doubt > there has ever been a better editor for technical text than > Doug.) But it's far worse now in most systems, because > there's rarely any editor at all; the manuals are just an > accreted clump. > > And that's a shame, though I have no suggestions on how > to fix it. Agree 100%. But I think what we are really complaining about is more recent program design & interface. Why do programs have so many options. Why is their functionality partitioned better. From norman at oclsc.org Fri Sep 20 07:19:56 2019 From: norman at oclsc.org (Norman Wilson) Date: Thu, 19 Sep 2019 17:19:56 -0400 Subject: [TUHS] [OT] Re: earliest Unix roff Message-ID: <1568927999.21637.for-standards-violators@oclsc.org> Arthur Krewat: Which is better, creating a whole new binary to put in /usr/bin to do a single task, or add a flag to cat? Which is better, a proliferation of binaries w/standalone source code, or a single code tree that can handle slightly different tasks and save space? ====== Which is simpler to write correctly, to debug, and to maintain: a simple program that does a single task, or a huge single program with lots of tasks mashed together? Which is easier to understand and use, individual programs each with a few options specialized to a particular task, or a monolith with many more options some of which apply only to one task or another, others to all? What are you trying to optimize for? The speed with which programmers can churn out yet another featureful utility full of bugs and corner cases, or the ease with which the end-user can figure out what tool to use and how to use it? Norman Wilson Toronto ON From usotsuki at buric.co Fri Sep 20 07:46:13 2019 From: usotsuki at buric.co (Steve Nickolas) Date: Thu, 19 Sep 2019 17:46:13 -0400 (EDT) Subject: [TUHS] [OT] Re: earliest Unix roff In-Reply-To: <19f9233f-6f54-46eb-116f-990660ca2a76@kilonet.net> References: <1568919029.18595.for-standards-violators@oclsc.org> <20190919201833.GN2046@mcvoy.com> <19f9233f-6f54-46eb-116f-990660ca2a76@kilonet.net> Message-ID: On Thu, 19 Sep 2019, Arthur Krewat wrote: > Serious question: > > Which is better, creating a whole new binary to put in /usr/bin to do a > single task, or add a flag to cat? > > Which is better, a proliferation of binaries w/standalone source code, or a > single code tree that can handle slightly different tasks and save space? > > :) > > art k. I would argue that the more "Unix" way to do it is have the multiple binaries. One job, one tool, and chain them together to make bigger tools. -uso. From lm at mcvoy.com Fri Sep 20 07:51:07 2019 From: lm at mcvoy.com (Larry McVoy) Date: Thu, 19 Sep 2019 14:51:07 -0700 Subject: [TUHS] [OT] Re: earliest Unix roff In-Reply-To: References: <1568919029.18595.for-standards-violators@oclsc.org> <20190919201833.GN2046@mcvoy.com> <19f9233f-6f54-46eb-116f-990660ca2a76@kilonet.net> Message-ID: <20190919215107.GA27727@mcvoy.com> On Thu, Sep 19, 2019 at 05:46:13PM -0400, Steve Nickolas wrote: > On Thu, 19 Sep 2019, Arthur Krewat wrote: > > >Serious question: > > > >Which is better, creating a whole new binary to put in /usr/bin to do a > >single task, or add a flag to cat? > > > >Which is better, a proliferation of binaries w/standalone source code, or > >a single code tree that can handle slightly different tasks and save > >space? > > > >:) > > > >art k. > > I would argue that the more "Unix" way to do it is have the multiple > binaries. One job, one tool, and chain them together to make bigger tools. That worked when we were running on 64K machines. Modern machines do a lot more and the problem space is not always a pipeline. You aren't going to write a web server by spawning cat | encrypt | http_servlet That doesn't scale. At all. From robpike at gmail.com Fri Sep 20 08:42:08 2019 From: robpike at gmail.com (Rob Pike) Date: Fri, 20 Sep 2019 08:42:08 +1000 Subject: [TUHS] earliest Unix roff In-Reply-To: <1568918582.18253.for-standards-violators@oclsc.org> References: <1568918582.18253.for-standards-violators@oclsc.org> Message-ID: Here is the complete Plan 9 man page for p: % 9 man p P(1) P(1) NAME p - paginate SYNOPSIS p [ -number ] [ file ... ] DESCRIPTION P copies its standard input, or the named files if given, to its standard output, stopping at the end of every 22nd line, and between files, to wait for a newline from the user. The option sets the number of lines on a page. While waiting for a newline, p interprets the commands: ! Pass the rest of the line to the shell as a command. q Quit. SOURCE /usr/local/plan9/src/cmd/p.c Page 1 Plan 9 (printed 9/20/19) On Fri, Sep 20, 2019 at 4:43 AM Norman Wilson wrote: > Clem Cole: > > Exactly!!!! That's what Eric did when he wrote more(ucb) - he *added > to > Unix*. The funny part was that USG thought more(ucb) was a good idea > and > then wrote their own, pg(att); which was just as arrogant as the info > behavior from the Gnu folks!!! > > ====== > > And others wrote their own too, of course. The one I know > best is p(1), written by Rob Pike in the late 1970s at the > University of Toronto. I encountered at Caltech on the > system Rob had set up before leaving for Bell Labs (and > which I cared for and hacked on for the next four years > before following him). By the time I reached BTL it was > a normal part of the Research system; I believe it's in > all of the Eighth, Ninth, and Tenth Edition manuals. > > p is interesting because it's so much lighter-weight, and > because it has rather a different interior design: > > Rather than doing termcappy things, p just prints 22 lines > (or the number specified in an option), then doesn't print > the newline after the 22nd line. Hit return and it will > print the next 22 lines, and so on. The resulting text just > flows up the glass-tty screen without any fuss, cbreak, or > anything. (I believe the first version predated V7 and > therefore cbreak.) > > Why 22 lines instead of 24, the common height of glass ttys > back then? Partly because that means you keep a line or two > of context when advancing pages, making reading simpler. > But also because in those days, a standard page destined for > a printer (e.g. from pr or nroff, and therefore from man) was > 66 lines long. 22 evenly divides 66, so man something | p > never gives you a screen spanning pages. > > p was able to back up: type - (and return) instead of just > return, and it reprints the previous 22-line page; -- (return) > the 22 lines before that; and so on. This was implemented > in an interesting and clever way: a wrapper around the standard > I/O library which kept a circular buffer of some fixed number > of characters (8KiB in early versions, I think), and a new > call that, in effect, backed up the file pointer by one character > and returned the character just backed over. That made it easy > to back over the previous N lines: just make that call until > you've seen N newlines, then discard the newline you've just > backed over, and you're at the beginning the first line you want > to reprint. > > As I vaguely recall, more was able to back up, but only when > reading from a real file, not a pipeline. p could do (limited > but sufficient) backup from a pipeline too. > > As a creature of its pre-window-system era, you could also type > !command when p paused as well. > > I remember being quite interested in that wrapper as a > possible library for use in other things, though I never > found a use for it. > > I also remember a wonderful Elements-of-Programming-Style > adventure with Rob's code. I discovered it had a bug under some > specific case when read returned less than a full bufferful. > I read the code carefully and couldn't see what was wrong. > So I wrote my own replacement for the problematic subroutine > from scratch, tested it carefully in corner cases, then with > listings of Rob's code and mine side-by-side walked through > each with the problem case and found the bug. > > I still carry my own version of p (rewritten from scratch mainly > to make it more portable--Rob's code was old enough to be too > clever in some details) wherever I go; ironically, even back to > U of T where I have been on and off for the past 30 years. > more and less and pg and the like are certainly useful programs; > for various reasons they're not to my taste, but I don't scorn > them. But I can't help being particular fond of p because it > taught me a few things about programming too. > > Norman Wilson > Toronto ON > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robpike at gmail.com Fri Sep 20 08:44:44 2019 From: robpike at gmail.com (Rob Pike) Date: Fri, 20 Sep 2019 08:44:44 +1000 Subject: [TUHS] [OT] Re: earliest Unix roff In-Reply-To: <1568919029.18595.for-standards-violators@oclsc.org> References: <1568919029.18595.for-standards-violators@oclsc.org> Message-ID: This was my fault, and it happened because I confronted DMR about the -u flag for cat. He said it was there because it seemed important that cat be writable in stdio, which was new at the time. I agreed but said the point had been made and avoiding unnecessary flags was a higher goal. So cat was simplified to do what it said, no more and no less, with read and write and no nonsense. -rob On Fri, Sep 20, 2019 at 4:51 AM Norman Wilson wrote: > KatolaZ: > > We can discuss whether the split was necessary or "right" in the first > > instance, as we could discuss whether it was good or not for cat(1) to > > leave Murray Hill in 1979 with no options and come back from Berkley > > with a source code doubled in size and 9 options in 1982. > > We needn't discuss that (though of course there are opinions and > mine are the correct ones), but in the interest of historic accuracy, > I should point out by 1979 (V7) cat had developed a single option -u > to turn off stdio buffering. > > Sometime before 1984 or so, that option was removed, and cat was > simplified to just > while ((n = read(fd, buf, sizeof(buf))) > 0) > write(1, buf, n) > (error checking elided for clarity) > which worked just fine for the rest of the life of the Research > system. > > So it's true that BSD added needless (in my humble but correct > opinion) options, but not that it had none before they touched it. > Unless all those other programs were stuffed into cat in an earlier > Berkeley system, but I don't think they were. > > Norman Wilson > Toronto ON > (Three cats, no options) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bakul at bitblocks.com Fri Sep 20 08:55:22 2019 From: bakul at bitblocks.com (Bakul Shah) Date: Thu, 19 Sep 2019 15:55:22 -0700 Subject: [TUHS] earliest Unix roff In-Reply-To: Your message of "Fri, 20 Sep 2019 08:42:08 +1000." References: <1568918582.18253.for-standards-violators@oclsc.org> Message-ID: <20190919225529.ADCDD156E427@mail.bitblocks.com> Re: more/less/p At Fortune Systems Dave Yost added page mode to the tty driver when his serial io optimizations made scrolling at 9600 blazing fast. He also added an ioctl for page size. By setting it to something smaller than the tty number of rows you can see some context as well. This worked pretty well. From alec at sensi.org Fri Sep 20 18:59:31 2019 From: alec at sensi.org (Alexander Voropay) Date: Fri, 20 Sep 2019 11:59:31 +0300 Subject: [TUHS] OpenSolaris Git ? Message-ID: Hi! Is there a public OpenSolaris Git/CVS/SVN ? The openloaris.org site is down. AFIK the first sources set (not complete) was published around June 2005. The latest available sources were b135 March 2010 (available at TUHS) https://www.tuhs.org/cgi-bin/utree.pl?file=OpenSolaris_b135 It would be interesting to see an evolution of "pure" SysV R4. -- -=AV=- -------------- next part -------------- An HTML attachment was scrubbed... URL: From angus at fairhaven.za.net Fri Sep 20 19:06:20 2019 From: angus at fairhaven.za.net (Angus Robinson) Date: Fri, 20 Sep 2019 11:06:20 +0200 Subject: [TUHS] OpenSolaris Git ? In-Reply-To: References: Message-ID: Would this help? https://repo.or.cz/opensolaris.git On Fri, 20 Sep 2019, 11:00 Alexander Voropay, wrote: > Hi! > > Is there a public OpenSolaris Git/CVS/SVN ? > > The openloaris.org site is down. > > AFIK the first sources set (not complete) was published around June 2005. > The latest available sources were b135 March 2010 > (available at TUHS) > https://www.tuhs.org/cgi-bin/utree.pl?file=OpenSolaris_b135 > > It would be interesting to see an evolution of "pure" SysV R4. > > > > -- > -=AV=- > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alec at sensi.org Fri Sep 20 19:56:25 2019 From: alec at sensi.org (Alexander Voropay) Date: Fri, 20 Sep 2019 12:56:25 +0300 Subject: [TUHS] OpenSolaris Git ? In-Reply-To: References: Message-ID: Thank you! This repository updates was stopped at Mar 2009 (but seems started from the beginning at Jun 2005). P.S. Some commands i.e. `date` are very stable :) https://repo.or.cz/opensolaris.git/history/HEAD:/usr/src/cmd/date/date.c No changes from the first release (and partial AT&T copyright inside)! пт, 20 сент. 2019 г. в 12:06, Angus Robinson : > Would this help? > > https://repo.or.cz/opensolaris.git > > On Fri, 20 Sep 2019, 11:00 Alexander Voropay, wrote: > >> Hi! >> >> Is there a public OpenSolaris Git/CVS/SVN ? >> >> The openloaris.org site is down. >> >> AFIK the first sources set (not complete) was published around June 2005. >> The latest available sources were b135 March 2010 >> (available at TUHS) >> https://www.tuhs.org/cgi-bin/utree.pl?file=OpenSolaris_b135 >> >> It would be interesting to see an evolution of "pure" SysV R4. >> >> >> >> -- >> -=AV=- >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From rosenfeld at grumpf.hope-2000.org Fri Sep 20 20:20:11 2019 From: rosenfeld at grumpf.hope-2000.org (Hans Rosenfeld) Date: Fri, 20 Sep 2019 12:20:11 +0200 Subject: [TUHS] OpenSolaris Git ? In-Reply-To: References: Message-ID: <20190920102011.GF3209@grumpf.hope-2000.org> On Fri, Sep 20, 2019 at 11:59:31AM +0300, Alexander Voropay wrote: > Is there a public OpenSolaris Git/CVS/SVN ? > > The openloaris.org site is down. > > AFIK the first sources set (not complete) was published around June 2005. > The latest available sources were b135 March 2010 > (available at TUHS) > https://www.tuhs.org/cgi-bin/utree.pl?file=OpenSolaris_b135 > > It would be interesting to see an evolution of "pure" SysV R4. The illumos project and the various distributions based on it continue the development of what once was OpenSolaris. https://illumos.org/ https://github.com/illumos/illumos-gate Hans -- %SYSTEM-F-ANARCHISM, The operating system has been overthrown From alec at sensi.org Fri Sep 20 23:19:23 2019 From: alec at sensi.org (Alexander Voropay) Date: Fri, 20 Sep 2019 16:19:23 +0300 Subject: [TUHS] OpenSolaris Git ? In-Reply-To: <20190920102011.GF3209@grumpf.hope-2000.org> References: <20190920102011.GF3209@grumpf.hope-2000.org> Message-ID: Thank you! The first illumos commit: >0 parents commit 7c478bd95313f5f23a4c958a745db2134aa03244 >committed on 14 Jun 2005 The illumos project and the various distributions based on it continue > the development of what once was OpenSolaris. > > https://illumos.org/ > https://github.com/illumos/illumos-gate > -------------- next part -------------- An HTML attachment was scrubbed... URL: From steffen at sdaoden.eu Fri Sep 20 23:41:37 2019 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Fri, 20 Sep 2019 15:41:37 +0200 Subject: [TUHS] earliest Unix roff In-Reply-To: References: <1568916649.17313.for-standards-violators@oclsc.org> <20190919194415.Tp6NO%steffen@sdaoden.eu> Message-ID: <20190920134137.DXBTo%steffen@sdaoden.eu> John P. Linderman wrote in : |In the early 70's, Marc Rochkind recommended re-reading the entire \ |UNIX manual yearly. Back then, it was doable. Now it is probably growing \ |faster than I can read. It is however astonishing by how much even the POSIX standard changes, as a lowest common denominator. The IETF produces an overwhelming amount of drafts and RFCs, which need to or should be adhered to, affecting functionality and documentation. So much more time would be needed, for so many things. |There is a place for a concise description of each command, and a separate \ |place for tutorials and conference papers. Unfortunately not except in FreeBSD and NetBSD, which carry some in /usr/share/doc, like the BSD mail manual. You need to find it here, and i wonder how many of those who have grown up in the Linux world would find them at all. (Or even do a search.) They are not really updated in addition. Though FreeBSD added a clang entry, the time when developers invented ideas and implementations, and documented those under /usr/share/doc are over even there. This is really sad. Infrequently and getting rarer i reread those, for example "Rethinking /dev and devices in the UNIX kernel" about the introduction of devfs, which i still find great. It is great to hear you who is responsible that the "load of options reached 17 in v9", whereas i maintain a fork of the program which causes "old UNIX hands [to] groan at the monstrous headers that come from latter-day mailers and at the fatness of their manuals" (citing A Research UNIX Reader). To offer a solution i could add another layer in between -h output and full reference manual, and create a heavily minimized version of the manual, renaming that one to -reference.1 maybe, and prominently mention the reference. Also, easy it is to concisely document that -n chooses a numeric sort, and -r reverses the result order, but -b addr, --bcc=.. Send a blind carbon copy to recipient addr. can result in dead-end or otherwise misunderstood situations unless you really know that particular manual is stripped down, and the reference manual makes this -b addr, --bcc=.. Send a blind carbon copy to recipient addr, if the set[268]ting of expandaddr[408], one of the INTERNAL VARIABLES[29], allows; the ‘shquote’ expandaddr[408] flag is supported. The option may be used multiple times. Also see the section On sending mail, and non-interactive mode[7]. (Here, expandaddr has not been invented by me.) But if you have the reference a bit present in your head, then #?0|kent:nail$ .obj/s-nail -h|grep -- -b [:-a attachment:] [:-b bcc-addr:] [:-c cc-addr:] . -b, -c, -r, -T, to-addr: ex at am.ple or '(Lovely) Ex ' should also be sufficient. Blasting the concise complexity of a mathematical formula, -a file[=input-charset[#output-charset]], --attach=.. Attach file to the message (for compose mode opportunities refer to ~@[317] and ~^[319]). needs to backed as -a file[=input-charset[#output-charset]], --attach=.. Attach file to the message (for compose mode opportunities refer to ~@[317] and ~^[319]). Filename transformations[26] (also see file[193]) will be performed, except that shell variables are not expanded. Shall file not be accessible but contain a ‘=’ charac‐ ter, then anything before the last ‘=’ will be used as the file‐ name, anything thereafter as a character set specification. If an input character set is specified, but no output character set, then the given input character set is fixed as-is, and no conversion will be applied; giving the empty string or the special string hyphen-minus ‘-’ will be treated as if ttycharset[590] has been specified (the default). If an output character set has also been given then the conversion will be performed exactly as specified and on-the-fly, not consid‐ ering the file type and content. As an exception the empty string or hyphen-minus ‘-’, select the default conversion algorithm (see Character sets[14]): no conversion is performed on-the-fly, file and its contents will be MIME-classified (HTML mail and MIME attachments[9], The mime.types files[35]); Only this mode is sup‐ ported without support for character set conversions (features[411] does not mention ‘+iconv’). for people to get at least enough of the picture to use the option. (Note the actual algorithm is documented somewhere else.) #?0|kent:nail$ .obj/s-nail -h|grep -- '-a ' [:-a attachment:] [:-b bcc-addr:] [:-c cc-addr:] . -a attachment[=input-charset[#output-charset]] But normally, all you say is "-a file" and the thing is fine by default without just doing anything at all. That is how it should be. Dear John P. Linderman, be warned that the above output of -b is new, it was "-[bcrT]:" before, for which to understand regular expressions or file patterns are implied. I have given you credit for the change. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) -------------- next part -------------- An embedded message was scrubbed... From: "John P. Linderman" Subject: Re: [TUHS] earliest Unix roff Date: Thu, 19 Sep 2019 16:38:51 -0400 Size: 16566 URL: From krewat at kilonet.net Sat Sep 21 00:37:51 2019 From: krewat at kilonet.net (Arthur Krewat) Date: Fri, 20 Sep 2019 10:37:51 -0400 Subject: [TUHS] OpenSolaris Git ? In-Reply-To: References: <20190920102011.GF3209@grumpf.hope-2000.org> Message-ID: And interestingly enough, last year, using Illumos, I could actually run Oracle Database 11g on it - I never tried anything newer. On 9/20/2019 9:19 AM, Alexander Voropay wrote: > Thank you! > > The first illumos commit: > >0 parents commit 7c478bd95313f5f23a4c958a745db2134aa03244 > >committed on 14 Jun 2005 > > > > The illumos project and the various distributions based on it continue > the development of what once was OpenSolaris. > > https://illumos.org/ > https://github.com/illumos/illumos-gate > -------------- next part -------------- An HTML attachment was scrubbed... URL: From steffen at sdaoden.eu Sat Sep 21 01:03:14 2019 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Fri, 20 Sep 2019 17:03:14 +0200 Subject: [TUHS] earliest Unix roff In-Reply-To: <20190920134137.DXBTo%steffen@sdaoden.eu> References: <1568916649.17313.for-standards-violators@oclsc.org> <20190919194415.Tp6NO%steffen@sdaoden.eu> <20190920134137.DXBTo%steffen@sdaoden.eu> Message-ID: <20190920150314.3iquv%steffen@sdaoden.eu> Steffen Nurpmeso wrote in <20190920134137.DXBTo%steffen at sdaoden.eu>: |John P. Linderman wrote in : ... ||There is a place for a concise description of each command, and a \ ||separate \ ||place for tutorials and conference papers. ... |Also, easy it is to concisely document that -n chooses a numeric |sort, and -r reverses the result order, but | | -b addr, --bcc=.. | Send a blind carbon copy to recipient addr. | |can result in dead-end or otherwise misunderstood situations |unless you really know that particular manual is stripped down, |and the reference manual makes this ... And i want to clarify that we talk about a program which does not behave the way a user would normally expect, where normally is that the mail is sent to all recipients. In an academic or a lab environment you can ask someone, or go over and say "Hi Ken" or "Hi Kurt", "your program misbehaves". But in the wild people will simply start to mistrust a program, or stop using it right away. In 99 percent you will not even get a bug report or hear just about anything. (Except maybe for the most popular and widely used programs.) And then all the work, the blood sweat and tears have been for nothing. --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 athornton at gmail.com Sat Sep 21 03:51:26 2019 From: athornton at gmail.com (Adam Thornton) Date: Fri, 20 Sep 2019 10:51:26 -0700 Subject: [TUHS] OpenSolaris Git ? In-Reply-To: References: <20190920102011.GF3209@grumpf.hope-2000.org> Message-ID: OpenSolaris was the only large project I ever contributed to that used Mercurial as its source control system. I am bad at git but I *really* never wrapped my head around hg. On Fri, Sep 20, 2019 at 7:38 AM Arthur Krewat wrote: > And interestingly enough, last year, using Illumos, I could actually run > Oracle Database 11g on it - I never tried anything newer. > > > > On 9/20/2019 9:19 AM, Alexander Voropay wrote: > > Thank you! > > The first illumos commit: > >0 parents commit 7c478bd95313f5f23a4c958a745db2134aa03244 > >committed on 14 Jun 2005 > > > > The illumos project and the various distributions based on it continue >> the development of what once was OpenSolaris. >> >> https://illumos.org/ >> https://github.com/illumos/illumos-gate >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fuz at fuz.su Sat Sep 21 08:53:50 2019 From: fuz at fuz.su (Robert Clausecker) Date: Sat, 21 Sep 2019 00:53:50 +0200 Subject: [TUHS] 8bc -- a B compiler for the PDP-8 Message-ID: <20190920225350.GA26132@fuz.su> Greetings! As a project for our university's seminar on the PDP-8 I wrote a compiler for the B language targeting it. It's a bit rough around the edges and the runtime code needs some work (division and remainder are missing), but it does compile B code correctly, generating acceptable code (for my taste, though the function call sequence could be better). I hope some of you enjoy this compiler for an important historical language for an important historical computer (makes me wonder why the two weren't married before). https://github.com/fuzxxl/8bc Yours, Robert Clausecker -- () ascii ribbon campaign - for an 8-bit clean world /\ - against html email - against proprietary attachments From imp at bsdimp.com Sat Sep 21 20:47:19 2019 From: imp at bsdimp.com (Warner Losh) Date: Sat, 21 Sep 2019 12:47:19 +0200 Subject: [TUHS] My talk today 2019-09-20 at UTC 1230 Message-ID: https://2019.eurobsdcon.org/livestream-soria-moria/ Has a live stream. My talk is at 1230 UTC or just under 2 hours. There will be a recording I think that I'll be able to share with you in a day or three. Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From wkt at tuhs.org Sat Sep 21 20:49:08 2019 From: wkt at tuhs.org (Warren Toomey) Date: Sat, 21 Sep 2019 20:49:08 +1000 Subject: [TUHS] My talk today 2019-09-20 at UTC 1230 In-Reply-To: References: Message-ID: Best of luck with it Warner. Cheers, Warren On 21 September 2019 8:47:19 pm AEST, Warner Losh wrote: >https://2019.eurobsdcon.org/livestream-soria-moria/ > >Has a live stream. My talk is at 1230 UTC or just under 2 hours. There >will >be a recording I think that I'll be able to share with you in a day or >three. > >Warner -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From spedraja at gmail.com Sat Sep 21 21:26:14 2019 From: spedraja at gmail.com (SPC) Date: Sat, 21 Sep 2019 13:26:14 +0200 Subject: [TUHS] My talk today 2019-09-20 at UTC 1230 In-Reply-To: References: Message-ID: Best Wishes and Good Luck! Cordiales saludos / Best Regards / Salutations / Freundliche Grüße ----- Sergio Pedraja Skype: spedraja at gmail.com ----- Senior Technician in Computer Science, Systems Administration, and Information Security. MBA. Qualified occupational trainer. El sáb., 21 sept. 2019 12:49, Warren Toomey escribió: > Best of luck with it Warner. > Cheers, Warren > > On 21 September 2019 8:47:19 pm AEST, Warner Losh wrote: >> >> https://2019.eurobsdcon.org/livestream-soria-moria/ >> >> Has a live stream. My talk is at 1230 UTC or just under 2 hours. There >> will be a recording I think that I'll be able to share with you in a day or >> three. >> >> Warner >> > > -- > Sent from my Android phone with K-9 Mail. Please excuse my brevity. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Sat Sep 21 21:51:28 2019 From: clemc at ccc.com (Clem cole) Date: Sat, 21 Sep 2019 07:51:28 -0400 Subject: [TUHS] My talk today 2019-09-20 at UTC 1230 In-Reply-To: References: Message-ID: <26F0B811-E6E4-4CD8-B8ED-801F2C5FBB19@ccc.com> Indeed and have fun Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. > On Sep 21, 2019, at 6:47 AM, Warner Losh wrote: > > https://2019.eurobsdcon.org/livestream-soria-moria/ > > Has a live stream. My talk is at 1230 UTC or just under 2 hours. There will be a recording I think that I'll be able to share with you in a day or three. > > Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at eric.allman.name Sat Sep 21 23:32:51 2019 From: tuhs at eric.allman.name (Eric Allman) Date: Sat, 21 Sep 2019 15:32:51 +0200 Subject: [TUHS] congratulations to Warner on a great talk Message-ID: Warner's talk just finished --- it was excellent. Those of you who didn't see it live might well want to see the recording when it comes out. eric From tuhs at eric.allman.name Sun Sep 22 00:44:34 2019 From: tuhs at eric.allman.name (Eric Allman) Date: Sat, 21 Sep 2019 16:44:34 +0200 Subject: [TUHS] congratulations to Warner on a great talk In-Reply-To: <49C268A5-42E6-41E2-95F9-0A8043DFC9F3@alchemistowl.org> References: <49C268A5-42E6-41E2-95F9-0A8043DFC9F3@alchemistowl.org> Message-ID: <65187b33-08f1-88ca-5729-eb40cdb5ced7@neophilic.com> > That’s high praise! Let us know when it is out and where, please. Word this morning was that the recordings will be up in "a couple of days". Keep an eye on https://2019.eurobsdcon.org/ — at the moment there's a "livestream" pull-down, which I predict will be replaced with a pointer to the recordings (although they could end up elsewhere; I have no inside information). eric From arrigo at alchemistowl.org Sun Sep 22 00:08:05 2019 From: arrigo at alchemistowl.org (Arrigo Triulzi) Date: Sat, 21 Sep 2019 16:08:05 +0200 Subject: [TUHS] congratulations to Warner on a great talk In-Reply-To: References: Message-ID: <49C268A5-42E6-41E2-95F9-0A8043DFC9F3@alchemistowl.org> On 21 Sep 2019, at 15:33, Eric Allman wrote: > > Warner's talk just finished --- it was excellent. Those of you who > didn't see it live might well want to see the recording when it comes out. That’s high praise! Let us know when it is out and where, please. Arrigo > > eric From clemc at ccc.com Sun Sep 22 02:39:35 2019 From: clemc at ccc.com (Clem Cole) Date: Sat, 21 Sep 2019 12:39:35 -0400 Subject: [TUHS] congratulations to Warner on a great talk In-Reply-To: References: Message-ID: Wonderful On Sat, Sep 21, 2019 at 9:33 AM Eric Allman wrote: > Warner's talk just finished --- it was excellent. Those of you who > didn't see it live might well want to see the recording when it comes out. > > eric > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Tue Sep 24 03:25:40 2019 From: clemc at ccc.com (Clem Cole) Date: Mon, 23 Sep 2019 13:25:40 -0400 Subject: [TUHS] 8bc -- a B compiler for the PDP-8 In-Reply-To: <20190920225350.GA26132@fuz.su> References: <20190920225350.GA26132@fuz.su> Message-ID: below... On Fri, Sep 20, 2019 at 7:08 PM Robert Clausecker wrote: > Greetings! > > As a project for our university's seminar on the PDP-8 I wrote a > compiler for the B language targeting it. Very cool. > It's a bit rough around > the edges and the runtime code needs some work (division and > remainder are missing), but it does compile B code correctly, > generating acceptable code (for my taste, though the function call > sequence could be better). > A suggestion, Load TSS/8 on to your simh system with its Algol compiler and look at how it generated code. I would suspect you can use Algol's calling conventions and probably some of its runtime. Google is your friend. I had it running a while back, but do not have it active at the moment - the key is all the pieces should be findable in the wild,. > > I hope some of you enjoy this compiler for an important historical > language for an important historical computer (makes me wonder why > the two weren't married before). > Might have been, although when Ken created B for the PDP-7, BCPL was his model and there were already implementations of BCPL around for a number of processors. I would not be surprised if there was a BCPL/8. I would check in the DECUS library, much of which I think can be found online these days ??bit savers??. FWIW: IIRC, the Grenoble Algol, a DEC Fortran and DEC Focal (plus assembler) were the languages I remember on TSS/8. I came late and short lived to the PDP-8 world and did not do much with it. So there could have been/unlikely were more. The 8 Gordon Bell and his students had used to write it, was in the EE Dept at the time and most unused because we hard started to collect PDP-11s. But I do have a fondness for the TSS/8, because on a bet, one summer weekend in about 1976 I think, a couple of us hacked on it to make it swap to paper tape - you got about 2-4K of storage max (the read is destructive and much more than that the tape ripped/got tangled). But it worked enough we got the beers and pizza and we claimed success for proving it could be done. Sadly I have long ago lost that code for that hack. The PDP-8 we used was a very early 8 that CMU had and at one point was in donated to Boston Computer Museum/was on display until the museum closed. -------------- next part -------------- An HTML attachment was scrubbed... URL: From henry.r.bent at gmail.com Tue Sep 24 04:01:25 2019 From: henry.r.bent at gmail.com (Henry Bent) Date: Mon, 23 Sep 2019 14:01:25 -0400 Subject: [TUHS] 8bc -- a B compiler for the PDP-8 In-Reply-To: References: <20190920225350.GA26132@fuz.su> Message-ID: On Mon, 23 Sep 2019 at 13:27, Clem Cole wrote: > below... > > On Fri, Sep 20, 2019 at 7:08 PM Robert Clausecker wrote: > >> It's a bit rough around >> the edges and the runtime code needs some work (division and >> remainder are missing), but it does compile B code correctly, >> generating acceptable code (for my taste, though the function call >> sequence could be better). >> > A suggestion, Load TSS/8 on to your simh system with its Algol compiler > and look at how it generated code. I would suspect you can use Algol's > calling conventions and probably some of its runtime. Google is your > friend. I had it running a while back, but do not have it active at the > moment - the key is all the pieces should be findable in the wild,. > > >> >> I hope some of you enjoy this compiler for an important historical >> language for an important historical computer (makes me wonder why >> the two weren't married before). >> > Might have been, although when Ken created B for the PDP-7, BCPL was his > model and there were already implementations of BCPL around for a number of > processors. I would not be surprised if there was a BCPL/8. I would check > in the DECUS library, much of which I think can be found online these days > ??bit savers??. > I checked here: http://so-much-stuff.com/pdp8/software/decus.php but did not immediately see anything BCPL related. 8-330 is TSS/8 ALGOL. -Henry -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnold at skeeve.com Wed Sep 25 03:10:37 2019 From: arnold at skeeve.com (arnold at skeeve.com) Date: Tue, 24 Sep 2019 11:10:37 -0600 Subject: [TUHS] Revived! The 10 Edition spell program! Message-ID: <201909241710.x8OHAbF8014895@freefriends.org> Hello All. I have revived the 10th edition spell(1) program, allowing it to compile and run on "modern" systems. See https://github.com/arnoldrobbins/v10spell ; the README.md gives an overview of what was done. Enjoy! Arnold From clemc at ccc.com Wed Sep 25 03:15:31 2019 From: clemc at ccc.com (Clem Cole) Date: Tue, 24 Sep 2019 13:15:31 -0400 Subject: [TUHS] Revived! The 10 Edition spell program! In-Reply-To: <201909241710.x8OHAbF8014895@freefriends.org> References: <201909241710.x8OHAbF8014895@freefriends.org> Message-ID: Very cool. Thank you On Tue, Sep 24, 2019 at 1:11 PM wrote: > Hello All. > > I have revived the 10th edition spell(1) program, allowing it to compile > and run on "modern" systems. > > See https://github.com/arnoldrobbins/v10spell ; the README.md gives > an overview of what was done. > > Enjoy! > > Arnold > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnold at skeeve.com Wed Sep 25 03:30:43 2019 From: arnold at skeeve.com (arnold at skeeve.com) Date: Tue, 24 Sep 2019 11:30:43 -0600 Subject: [TUHS] Revived! The 10 Edition spell program! In-Reply-To: References: <201909241710.x8OHAbF8014895@freefriends.org> Message-ID: <201909241730.x8OHUhvT015578@freefriends.org> You're welcome. Yet Another Labor of Love. :-) Clem Cole wrote: > Very cool. Thank you > > On Tue, Sep 24, 2019 at 1:11 PM wrote: > > > Hello All. > > > > I have revived the 10th edition spell(1) program, allowing it to compile > > and run on "modern" systems. > > > > See https://github.com/arnoldrobbins/v10spell ; the README.md gives > > an overview of what was done. > > > > Enjoy! > > > > Arnold > > From khm at sciops.net Wed Sep 25 05:42:13 2019 From: khm at sciops.net (Kurt H Maier) Date: Tue, 24 Sep 2019 12:42:13 -0700 Subject: [TUHS] Revived! The 10 Edition spell program! In-Reply-To: <201909241710.x8OHAbF8014895@freefriends.org> References: <201909241710.x8OHAbF8014895@freefriends.org> Message-ID: <20190924194213.GA74746@wopr> On Tue, Sep 24, 2019 at 11:10:37AM -0600, arnold at skeeve.com wrote: > Hello All. > > I have revived the 10th edition spell(1) program, allowing it to compile > and run on "modern" systems. Great! I've been using this extensively on my writing, but I've been using the version that comes with plan9port. It'll be nice to have a standalone version. Thanks! khm From lm at mcvoy.com Wed Sep 25 05:58:35 2019 From: lm at mcvoy.com (Larry McVoy) Date: Tue, 24 Sep 2019 12:58:35 -0700 Subject: [TUHS] Revived! The 10 Edition spell program! In-Reply-To: <20190924194213.GA74746@wopr> References: <201909241710.x8OHAbF8014895@freefriends.org> <20190924194213.GA74746@wopr> Message-ID: <20190924195835.GB21722@mcvoy.com> On Tue, Sep 24, 2019 at 12:42:13PM -0700, Kurt H Maier wrote: > On Tue, Sep 24, 2019 at 11:10:37AM -0600, arnold at skeeve.com wrote: > > Hello All. > > > > I have revived the 10th edition spell(1) program, allowing it to compile > > and run on "modern" systems. > > Great! I've been using this extensively on my writing, but I've been > using the version that comes with plan9port. It'll be nice to have a > standalone version. How is this better than spell(1) on Linux? From arnold at skeeve.com Wed Sep 25 05:45:29 2019 From: arnold at skeeve.com (Arnold Robbins) Date: Tue, 24 Sep 2019 22:45:29 +0300 Subject: [TUHS] Recovered!!! The Georgia Tech Software Tools Subystem for Prime Computers Message-ID: <201909241945.x8OJjTCX032294@skeeve.com> Hello All. Believed lost in the mists of time for over 30 years, the Georgia Tech Software Tools Subsystem for Prime Computers, along with the Georgia Tech C Compiler for Prime Computers, have been recovered! The source code and documentation (and binary files) are available in a Github repo: https://github.com/arnoldrobbins/gt-swt. The README.md there provides some brief history and credits with respect to the recovery, and w.r.t. the subsystem and C compilers themselves. Credit to Scott Lee for making and keeping the tapes and driving the recovery process, and to Dennis Boone and yours truly for contributing financially. I set up the repo. For anyone who used and/or contributed to this software, we hope you'll enjoy this trip down memory lane. Feel free to forward this note to interested parties. Enjoy, Arnold Robbins (On behalf of the swt recovery team. :-) From khm at sciops.net Wed Sep 25 06:30:52 2019 From: khm at sciops.net (Kurt H Maier) Date: Tue, 24 Sep 2019 13:30:52 -0700 Subject: [TUHS] Revived! The 10 Edition spell program! In-Reply-To: <20190924195835.GB21722@mcvoy.com> References: <201909241710.x8OHAbF8014895@freefriends.org> <20190924194213.GA74746@wopr> <20190924195835.GB21722@mcvoy.com> Message-ID: <20190924203052.GB74746@wopr> On Tue, Sep 24, 2019 at 12:58:35PM -0700, Larry McVoy wrote: > > How is this better than spell(1) on Linux? Assuming you're talking about GNU spell, it suffers from feature creep (localization stuff, hard-coded markup filters, etc) which makes the code less pleasant to work with. I'm not sure why my spellchecker needs curses support, but GNU spell has it. Also I don't like having to worry about licensing cruft when I e.g. copy a binary over to a system at work. If I can do my work with 5% the source code, that's generally my plan. khm From dscherrer at solar.stanford.edu Wed Sep 25 07:29:36 2019 From: dscherrer at solar.stanford.edu (Deborah Scherrer) Date: Tue, 24 Sep 2019 14:29:36 -0700 Subject: [TUHS] Recovered!!! The Georgia Tech Software Tools Subystem for Prime Computers In-Reply-To: <201909241945.x8OJjTCX032294@skeeve.com> References: <201909241945.x8OJjTCX032294@skeeve.com> Message-ID: Awesome!!! Arnold, you're a saint!!!! D On 9/24/19 12:45 PM, Arnold Robbins wrote: > Hello All. > > Believed lost in the mists of time for over 30 years, the Georgia Tech > Software Tools Subsystem for Prime Computers, along with the Georgia Tech > C Compiler for Prime Computers, have been recovered! > > The source code and documentation (and binary files) are available in a > Github repo: https://github.com/arnoldrobbins/gt-swt. > > The README.md there provides some brief history and credits with respect > to the recovery, and w.r.t. the subsystem and C compilers themselves. > > Credit to Scott Lee for making and keeping the tapes and driving the > recovery process, and to Dennis Boone and yours truly for contributing > financially. I set up the repo. > > For anyone who used and/or contributed to this software, we hope you'll > enjoy this trip down memory lane. > > Feel free to forward this note to interested parties. > > Enjoy, > > Arnold Robbins > (On behalf of the swt recovery team. :-) From arnold at skeeve.com Wed Sep 25 16:15:50 2019 From: arnold at skeeve.com (arnold at skeeve.com) Date: Wed, 25 Sep 2019 00:15:50 -0600 Subject: [TUHS] Revived! The 10 Edition spell program! In-Reply-To: <20190924203052.GB74746@wopr> References: <201909241710.x8OHAbF8014895@freefriends.org> <20190924194213.GA74746@wopr> <20190924195835.GB21722@mcvoy.com> <20190924203052.GB74746@wopr> Message-ID: <201909250615.x8P6FoWX006682@freefriends.org> Kurt H Maier wrote: > On Tue, Sep 24, 2019 at 12:58:35PM -0700, Larry McVoy wrote: > > > > How is this better than spell(1) on Linux? > > Assuming you're talking about GNU spell, it suffers from feature creep > (localization stuff, hard-coded markup filters, etc) which makes the > code less pleasant to work with. I'm not sure why my spellchecker needs > curses support, but GNU spell has it. Also I don't like having to worry > about licensing cruft when I e.g. copy a binary over to a system at > work. If I can do my work with 5% the source code, that's generally my > plan. > > > khm It's not clear what 'spell' is --- it differs from distro to distro, often based on aspell. Whatever is on Ubuntu doesn't even know how to use 'sort -u' on its output. For myself, I don't claim that v10spell is better or worse than anything else out there; it simply provides another option, especially for fans of the original Unix code. :-) Arnold From arnold at skeeve.com Wed Sep 25 16:17:12 2019 From: arnold at skeeve.com (arnold at skeeve.com) Date: Wed, 25 Sep 2019 00:17:12 -0600 Subject: [TUHS] Recovered!!! The Georgia Tech Software Tools Subystem for Prime Computers In-Reply-To: References: <201909241945.x8OJjTCX032294@skeeve.com> Message-ID: <201909250617.x8P6HCrB006753@freefriends.org> Thanks Deborah. But if you want to send flowers, send them to Scott Lee; he's the one who had the tapes and drove getting them recovered. "All" I did was get things usable for github. :-) Arnold Deborah Scherrer wrote: > Awesome!!! Arnold, you're a saint!!!! > D > > On 9/24/19 12:45 PM, Arnold Robbins wrote: > > Hello All. > > > > Believed lost in the mists of time for over 30 years, the Georgia Tech > > Software Tools Subsystem for Prime Computers, along with the Georgia Tech > > C Compiler for Prime Computers, have been recovered! > > > > The source code and documentation (and binary files) are available in a > > Github repo: https://github.com/arnoldrobbins/gt-swt. > > > > The README.md there provides some brief history and credits with respect > > to the recovery, and w.r.t. the subsystem and C compilers themselves. > > > > Credit to Scott Lee for making and keeping the tapes and driving the > > recovery process, and to Dennis Boone and yours truly for contributing > > financially. I set up the repo. > > > > For anyone who used and/or contributed to this software, we hope you'll > > enjoy this trip down memory lane. > > > > Feel free to forward this note to interested parties. > > > > Enjoy, > > > > Arnold Robbins > > (On behalf of the swt recovery team. :-) From arrigo at alchemistowl.org Thu Sep 26 00:41:18 2019 From: arrigo at alchemistowl.org (Arrigo Triulzi) Date: Wed, 25 Sep 2019 16:41:18 +0200 Subject: [TUHS] congratulations to Warner on a great talk In-Reply-To: <65187b33-08f1-88ca-5729-eb40cdb5ced7@neophilic.com> References: <49C268A5-42E6-41E2-95F9-0A8043DFC9F3@alchemistowl.org> <65187b33-08f1-88ca-5729-eb40cdb5ced7@neophilic.com> Message-ID: On 21 Sep 2019, at 16:44, Eric Allman wrote: > Word this morning was that the recordings will be up in "a couple of > days". Keep an eye on https://2019.eurobsdcon.org/ — at the moment > there's a "livestream" pull-down, which I predict will be replaced with > a pointer to the recordings (although they could end up elsewhere; I > have no inside information). None of the talks appear to be published and, even more sadly, neither have slides appeared with the exception of the keynote on silly Slideshare. I really hope they don’t disappear without trace. Arrigo From imp at bsdimp.com Thu Sep 26 01:09:08 2019 From: imp at bsdimp.com (Warner Losh) Date: Wed, 25 Sep 2019 09:09:08 -0600 Subject: [TUHS] congratulations to Warner on a great talk In-Reply-To: References: <49C268A5-42E6-41E2-95F9-0A8043DFC9F3@alchemistowl.org> <65187b33-08f1-88ca-5729-eb40cdb5ced7@neophilic.com> Message-ID: On Wed, Sep 25, 2019 at 8:43 AM Arrigo Triulzi wrote: > On 21 Sep 2019, at 16:44, Eric Allman wrote: > > Word this morning was that the recordings will be up in "a couple of > > days". Keep an eye on https://2019.eurobsdcon.org/ — at the moment > > there's a "livestream" pull-down, which I predict will be replaced with > > a pointer to the recordings (although they could end up elsewhere; I > > have no inside information). > > None of the talks appear to be published and, even more sadly, neither > have slides appeared with the exception of the keynote on silly Slideshare. > > I really hope they don’t disappear without trace. > Slides have been published, though maybe not through the EuroBSDCon site. I wasn't aware that I could publish them there. https://docs.google.com/presentation/d/177KxOif5oHARyIdZHDq-OO67_GVtMkzIAlDX-cHxgb4/edit?usp=sharing I'm told it will be a small number of weeks before the bsdtv folks that taped everything can edit the talks down from the raw footage and post them to youtube. They have the raw livestream, but a small number of tweaks need to be made to each talk. I'll be writing a followup paper, as well as an article for the FreeBSD Journal. There's a number of small technical errors in the talk owing to two factors: (1) I couldn't see my speaker notes during the talk so I think I misspoke or neglected to include a clarifying sentence or two that I'd planned and (2) I found more original material that helped to clarify timelines (eg: PWB 1.0 was distributed outside of bell labs: it was V6 + the "50 changes" based, but still retained features like the V6 TTY driver. This was in 1978, about a year before V7 was released. PWB 2.0 was fully V7 based and included updates to the tools PWB added, exact details TBD). I did talk a little about the ambiguity between UNIX/TS and PWB/UNIX 3.0 in the talk, but the details of that need to be ironed out a bit. I hope to go through more original sources to figure all that out as different people remember things slightly differently, and sometimes contemporary documentation or scholarly papers contradicts the remembrance so I need to sort that out better, as well as where I can run diffs between supposed sources of things to find as much of the truth around this that I can. I hope to give this talk again, with some tweaks, since it was well received. It's been a while since my talks have provoked that much enthusiastic energy in the room. Maybe FOSDEM, BSDCan and something Linux oriented / related in the US. Warner Warner Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Thu Sep 26 01:15:21 2019 From: imp at bsdimp.com (Warner Losh) Date: Wed, 25 Sep 2019 09:15:21 -0600 Subject: [TUHS] UNIX NEWS, volumes 1-7 out there? Message-ID: I'm looking for complete compies of UNIX NEWS volumes 1-7. 8 and newer are available on the USENIX site, or on archive.org, but older ones are not. A few excerpts are published in newer login issues, but nothing complete. Reading the AUUGN issues, especially the early ones, are quite enlightening and help one judge the relative merits of later accounts with better contemporary context. I was hoping to get the same from UNIX NEWS (later login) and any other news letters that may exist from the time (I think I spotted references to one from the UK in AUUGN). It's really quite enlightening. Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From arrigo at alchemistowl.org Thu Sep 26 01:17:04 2019 From: arrigo at alchemistowl.org (Arrigo Triulzi) Date: Wed, 25 Sep 2019 17:17:04 +0200 Subject: [TUHS] congratulations to Warner on a great talk In-Reply-To: References: <49C268A5-42E6-41E2-95F9-0A8043DFC9F3@alchemistowl.org> <65187b33-08f1-88ca-5729-eb40cdb5ced7@neophilic.com> Message-ID: <34674811-F25A-4CE8-9A54-249930AC7916@alchemistowl.org> On 25 Sep 2019, at 17:09, Warner Losh wrote: > Slides have been published, though maybe not through the EuroBSDCon site. I wasn't aware that I could publish them there. I was under the mistaken impression that recordings of the talks would be made available on the site - I generally find it rather useful when conferences have slides, papers and recordings available on the web pages of past conferences, e.g. Usenix. > https://docs.google.com/presentation/d/177KxOif5oHARyIdZHDq-OO67_GVtMkzIAlDX-cHxgb4/edit?usp=sharing Ah, that’s the final version of what we got a preview of? > I'm told it will be a small number of weeks before the bsdtv folks that taped everything can edit the talks down from the raw footage and post them to youtube. They have the raw livestream, but a small number of tweaks need to be made to each talk. Right, that makes sense. I would like to see the “colour” which goes with the slides, i.e. all that isn’t written down.. > I'll be writing a followup paper, as well as an article for the FreeBSD Journal. There's a number of small technical errors in the talk owing to two factors: (1) I couldn't see my speaker notes during the talk so I think I misspoke or neglected to include a clarifying sentence or two that I'd planned and (2) I found more original material that helped to clarify timelines (eg: PWB 1.0 was distributed outside of bell labs: it was V6 + the "50 changes" based, but still retained features like the V6 TTY driver. This was in 1978, about a year before V7 was released. PWB 2.0 was fully V7 based and included updates to the tools PWB added, exact details TBD). I did talk a little about the ambiguity between UNIX/TS and PWB/UNIX 3.0 in the talk, but the details of that need to be ironed out a bit. I hope to go through more original sources to figure all that out as different people remember things slightly differently, and sometimes contemporary documentation or scholarly papers contradicts the remembrance so I need to sort that out better, as well as where I can run diffs between supposed sources of things to find as much of the truth around this that I can. That is wonderful! I have been desperately trying to find the Unix tapes which made it to the University of Milan “Cybernetics” department back in the 70s but have failed miserably. Most of the people who were there at the time are sadly no longer with us and my dad can’t remember who had them. All that I have left is the photocopied Unix manual with the cover printed by the department in Italian, an nth copy Lions and then other bits and pieces. All the rest is gone forever (or, more likely, in some Italian state warehouse since the bureaucracy necessary to throw anything away, or donate it, was so daunting it was just stuck somewhere). Unfortunately there were three physical moves of the department so chances are the cellars were cleaned out by workers. Thank you again for the talk! Arrigo From imp at bsdimp.com Thu Sep 26 01:26:07 2019 From: imp at bsdimp.com (Warner Losh) Date: Wed, 25 Sep 2019 09:26:07 -0600 Subject: [TUHS] congratulations to Warner on a great talk In-Reply-To: <34674811-F25A-4CE8-9A54-249930AC7916@alchemistowl.org> References: <49C268A5-42E6-41E2-95F9-0A8043DFC9F3@alchemistowl.org> <65187b33-08f1-88ca-5729-eb40cdb5ced7@neophilic.com> <34674811-F25A-4CE8-9A54-249930AC7916@alchemistowl.org> Message-ID: On Wed, Sep 25, 2019 at 9:17 AM Arrigo Triulzi wrote: > On 25 Sep 2019, at 17:09, Warner Losh wrote: > > Slides have been published, though maybe not through the EuroBSDCon > site. I wasn't aware that I could publish them there. > > I was under the mistaken impression that recordings of the talks would be > made available on the site - I generally find it rather useful when > conferences have slides, papers and recordings available on the web pages > of past conferences, e.g. Usenix. > I think that links to the talks will be there, but they will be uploaded to youtube. Most conferences give some instructions to speakers for uploading talk related materials, but I've not seen anything from EuroBSDcon. Most likely it is in a spam folder :( > > > https://docs.google.com/presentation/d/177KxOif5oHARyIdZHDq-OO67_GVtMkzIAlDX-cHxgb4/edit?usp=sharing > > Ah, that’s the final version of what we got a preview of? > Yes. > > I'm told it will be a small number of weeks before the bsdtv folks that > taped everything can edit the talks down from the raw footage and post them > to youtube. They have the raw livestream, but a small number of tweaks need > to be made to each talk. > > Right, that makes sense. I would like to see the “colour” which goes with > the slides, i.e. all that isn’t written down.. > I hope it will be there as well. I quite enjoyed giving the talk, though the audience was small. > > I'll be writing a followup paper, as well as an article for the FreeBSD > Journal. There's a number of small technical errors in the talk owing to > two factors: (1) I couldn't see my speaker notes during the talk so I think > I misspoke or neglected to include a clarifying sentence or two that I'd > planned and (2) I found more original material that helped to clarify > timelines (eg: PWB 1.0 was distributed outside of bell labs: it was V6 + > the "50 changes" based, but still retained features like the V6 TTY driver. > This was in 1978, about a year before V7 was released. PWB 2.0 was fully V7 > based and included updates to the tools PWB added, exact details TBD). I > did talk a little about the ambiguity between UNIX/TS and PWB/UNIX 3.0 in > the talk, but the details of that need to be ironed out a bit. I hope to go > through more original sources to figure all that out as different people > remember things slightly differently, and sometimes contemporary > documentation or scholarly papers contradicts the remembrance so I need to > sort that out better, as well as where I can run diffs between supposed > sources of things to find as much of the truth around this that I can. > > That is wonderful! I have been desperately trying to find the Unix tapes > which made it to the University of Milan “Cybernetics” department back in > the 70s but have failed miserably. Most of the people who were there at the > time are sadly no longer with us and my dad can’t remember who had them. > All that I have left is the photocopied Unix manual with the cover printed > by the department in Italian, an nth copy Lions and then other bits and > pieces. All the rest is gone forever (or, more likely, in some Italian > state warehouse since the bureaucracy necessary to throw anything away, or > donate it, was so daunting it was just stuck somewhere). Unfortunately > there were three physical moves of the department so chances are the > cellars were cleaned out by workers. > I would love to find that as well... At least one person came up to me after the talk and told me about a set of Onyx Z8000 System III manuals he had that we're making arrangements to find a good home (like maybe mine). Future versions of this talk will likely include a plea for people to contact me with historic artifacts so I might be able to copy them... Warner > Thank you again for the talk! > > Arrigo > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Thu Sep 26 01:30:47 2019 From: clemc at ccc.com (Clem Cole) Date: Wed, 25 Sep 2019 11:30:47 -0400 Subject: [TUHS] UNIX NEWS, volumes 1-7 out there? In-Reply-To: References: Message-ID: FYI: the folks at USENIX has been looking for these for a number of years. Let me know if you find copies of them and I will get them pushed back to the USENIX archives. Clem On Wed, Sep 25, 2019 at 11:16 AM Warner Losh wrote: > I'm looking for complete compies of UNIX NEWS volumes 1-7. 8 and newer are > available on the USENIX site, or on archive.org, but older ones are not. > A few excerpts are published in newer login issues, but nothing complete. > Reading the AUUGN issues, especially the early ones, are quite enlightening > and help one judge the relative merits of later accounts with better > contemporary context. I was hoping to get the same from UNIX NEWS (later > login) and any other news letters that may exist from the time (I think I > spotted references to one from the UK in AUUGN). It's really quite > enlightening. > > Warner > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arrigo at alchemistowl.org Thu Sep 26 01:32:24 2019 From: arrigo at alchemistowl.org (Arrigo Triulzi) Date: Wed, 25 Sep 2019 17:32:24 +0200 Subject: [TUHS] congratulations to Warner on a great talk In-Reply-To: References: <49C268A5-42E6-41E2-95F9-0A8043DFC9F3@alchemistowl.org> <65187b33-08f1-88ca-5729-eb40cdb5ced7@neophilic.com> <34674811-F25A-4CE8-9A54-249930AC7916@alchemistowl.org> Message-ID: <2BD243C6-BE68-4865-AC15-2AFD09919185@alchemistowl.org> On 25 Sep 2019, at 17:26, Warner Losh wrote: > I would love to find that as well... At least one person came up to me after the talk and told me about a set of Onyx Z8000 System III manuals he had that we're making arrangements to find a good home (like maybe mine). Future versions of this talk will likely include a plea for people to contact me with historic artifacts so I might be able to copy them… Wait! I /have/ those: that’s the first Unix system we had at home (as opposed to having to dial into the university). It used to sit on its pedestal under my uncle’s home office table (how he worked with that noise I have no idea), I need to dig them up from my dad’s cellar but I am certain we have them, probably also some tapes. The machine is, sadly, long gone. I have fond memories of vi & C on that machine typing on my very own Italian ADM 3A clone instead of having to share dad’s TTY and modem. Arrigo From tuhs at eric.allman.name Thu Sep 26 02:48:02 2019 From: tuhs at eric.allman.name (Eric Allman) Date: Wed, 25 Sep 2019 18:48:02 +0200 Subject: [TUHS] congratulations to Warner on a great talk In-Reply-To: References: <49C268A5-42E6-41E2-95F9-0A8043DFC9F3@alchemistowl.org> <65187b33-08f1-88ca-5729-eb40cdb5ced7@neophilic.com> Message-ID: <14e53cec-6c59-cf5b-68af-b34d758e89d6@neophilic.com> I just got word from the EuroBSDcon crew requesting that authors submit PDF of their slides for publication and mentioning that the recordings will be available "in two to three months". I was under the impression that it would be a matter of days or maybe weeks instead of months --- my fault entirely. I'm pretty sure they are not going to disappear though. The A/V crew was very professional this year and it looks like the source material should be excellent. eric On 2019-09-25 16:41 , Arrigo Triulzi wrote: > On 21 Sep 2019, at 16:44, Eric Allman wrote: >> Word this morning was that the recordings will be up in "a couple of >> days". Keep an eye on https://2019.eurobsdcon.org/ — at the moment >> there's a "livestream" pull-down, which I predict will be replaced with >> a pointer to the recordings (although they could end up elsewhere; I >> have no inside information). > > None of the talks appear to be published and, even more sadly, neither have slides appeared with the exception of the keynote on silly Slideshare. > > I really hope they don’t disappear without trace. > > Arrigo > From khm at sciops.net Thu Sep 26 12:54:37 2019 From: khm at sciops.net (Kurt H Maier) Date: Wed, 25 Sep 2019 19:54:37 -0700 Subject: [TUHS] UNIX NEWS, volumes 1-7 out there? In-Reply-To: References: Message-ID: <20190926025437.GC19436@wopr> On Wed, Sep 25, 2019 at 11:30:47AM -0400, Clem Cole wrote: > On Wed, Sep 25, 2019 at 11:16 AM Warner Losh wrote: > > > I'm looking for complete compies of UNIX NEWS volumes 1-7. 8 and newer are > > FYI: the folks at USENIX has been looking for these for a number of years. > Let me know if you find copies of them and I will get them pushed back to > the USENIX archives. I have a large swath of #4, dated 19 March 1976, if we're talking about the same thing. I've scanned it in at 600 dpi: http://sciops.net/images/unix-news/1976-03-19/ khm From jsteve at superglobalmegacorp.com Thu Sep 26 15:59:41 2019 From: jsteve at superglobalmegacorp.com (Jason Stevens) Date: Thu, 26 Sep 2019 13:59:41 +0800 Subject: [TUHS] Recovered!!! The Georgia Tech Software Tools Subystemfor Prime Computers In-Reply-To: References: <201909241945.x8OJjTCX032294@skeeve.com> Message-ID: I see mention of an emulator in the GitHub repo, but I don’t see any emulator that is available. Am I reading this wrong? All that is mentioned is a telnet address to something that just drops. From: Deborah Scherrer Sent: Wednesday, September 25, 2019 5:46 AM To: tuhs at minnie.tuhs.org Subject: Re: [TUHS] Recovered!!! The Georgia Tech Software Tools Subystemfor Prime Computers Awesome!!! Arnold, you're a saint!!!! D On 9/24/19 12:45 PM, Arnold Robbins wrote: > Hello All. > > Believed lost in the mists of time for over 30 years, the Georgia Tech > Software Tools Subsystem for Prime Computers, along with the Georgia Tech > C Compiler for Prime Computers, have been recovered! > > The source code and documentation (and binary files) are available in a > Github repo: https://github.com/arnoldrobbins/gt-swt. > > The README.md there provides some brief history and credits with respect > to the recovery, and w.r.t. the subsystem and C compilers themselves. > > Credit to Scott Lee for making and keeping the tapes and driving the > recovery process, and to Dennis Boone and yours truly for contributing > financially. I set up the repo. > > For anyone who used and/or contributed to this software, we hope you'll > enjoy this trip down memory lane. > > Feel free to forward this note to interested parties. > > Enjoy, > > Arnold Robbins > (On behalf of the swt recovery team. :-) -------------- next part -------------- An HTML attachment was scrubbed... URL: From lars at nocrew.org Thu Sep 26 16:03:49 2019 From: lars at nocrew.org (Lars Brinkhoff) Date: Thu, 26 Sep 2019 06:03:49 +0000 Subject: [TUHS] Recovered!!! The Georgia Tech Software Tools Subystemfor Prime Computers In-Reply-To: (Jason Stevens's message of "Thu, 26 Sep 2019 13:59:41 +0800") References: <201909241945.x8OJjTCX032294@skeeve.com> Message-ID: <7wo8z7zj96.fsf@junk.nocrew.org> > I see mention of an emulator in the GitHub repo, but I don’t see any > emulator that is available. I see this: Welcome to the Prime Computer 50-series emulator, running Primos rev 24.0! Login as user guest, password pr1me Hit a few returns and Ctrl-q if it appears "stuck"; some bots are hitting the emulator After logging in, use the Prime HELP command for assistance. You are welcome to create a directory under GUEST for your files. The emacs terminal type is xterm The line erase character is ? There are other Primos revs running on ports 8001-8007 Prime manuals at: http://yagi.h-net.msu.edu/prime_manuals/prirun_scans To report bugs or contact the author, send email to prirun at gmail.com Enjoy your time travels! -Jim Wilcoxson aka JIMMY Login please. login guest Password? GUEST (user 2) logged in Thursday, 26 Sep 19 02:03:08. Welcome to PRIMOS version 24.0.0.r15 Copyright (c) Computervision, Corp. 1993. Last login Tuesday, 24 Sep 19 19:58:08. Warning! There was 1 failed attempt to login under this id since the last successful login. OK, From jsteve at superglobalmegacorp.com Thu Sep 26 16:08:01 2019 From: jsteve at superglobalmegacorp.com (Jason Stevens) Date: Thu, 26 Sep 2019 14:08:01 +0800 Subject: [TUHS] Recovered!!! The Georgia Tech Software Tools Subystemfor Prime Computers In-Reply-To: <7wo8z7zj96.fsf@junk.nocrew.org> References: <201909241945.x8OJjTCX032294@skeeve.com> <7wo8z7zj96.fsf@junk.nocrew.org> Message-ID: <0c66d8e5-ef8b-4682-b8a0-281c5c7c0359@PU1APC01FT115.eop-APC01.prod.protection.outlook.com> I now get this: All available connections are in use. Connection to host lost. I guess progress. Oh well, I guess it’s not possible to distribute the emulator? From: Lars Brinkhoff Sent: Thursday, September 26, 2019 2:03 PM To: Jason Stevens Cc: tuhs at minnie.tuhs.org Subject: Re: [TUHS] Recovered!!! The Georgia Tech Software Tools Subystemfor Prime Computers > I see mention of an emulator in the GitHub repo, but I don’t see any > emulator that is available. I see this: Welcome to the Prime Computer 50-series emulator, running Primos rev 24.0! Login as user guest, password pr1me Hit a few returns and Ctrl-q if it appears "stuck"; some bots are hitting the emulator After logging in, use the Prime HELP command for assistance. You are welcome to create a directory under GUEST for your files. The emacs terminal type is xterm The line erase character is ? There are other Primos revs running on ports 8001-8007 Prime manuals at: http://yagi.h-net.msu.edu/prime_manuals/prirun_scans To report bugs or contact the author, send email to prirun at gmail.com Enjoy your time travels! -Jim Wilcoxson aka JIMMY Login please. login guest Password? GUEST (user 2) logged in Thursday, 26 Sep 19 02:03:08. Welcome to PRIMOS version 24.0.0.r15 Copyright (c) Computervision, Corp. 1993. Last login Tuesday, 24 Sep 19 19:58:08. Warning! There was 1 failed attempt to login under this id since the last successful login. OK, -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnold at skeeve.com Thu Sep 26 16:09:48 2019 From: arnold at skeeve.com (arnold at skeeve.com) Date: Thu, 26 Sep 2019 00:09:48 -0600 Subject: [TUHS] Recovered!!! The Georgia Tech Software Tools Subystemfor Prime Computers In-Reply-To: References: <201909241945.x8OJjTCX032294@skeeve.com> Message-ID: <201909260609.x8Q69mUP017447@freefriends.org> It has always worked for me, or I wouldn't have put it in the README. Sounds like a network issue on your end. (Now, why someone would go out of their way to work on Primos is another question. I *never* used it directly, but only via the SWT subsystem. At Georgia Tech, we logged straigt into SWT.) Arnold Jason Stevens wrote: > I see mention of an emulator in the GitHub repo, but I don’t see any emulator that is available. > > Am I reading this wrong? > > All that is mentioned is a telnet address to something that just drops. > > From: Deborah Scherrer > Sent: Wednesday, September 25, 2019 5:46 AM > To: tuhs at minnie.tuhs.org > Subject: Re: [TUHS] Recovered!!! The Georgia Tech Software Tools Subystemfor Prime Computers > > Awesome!!! Arnold, you're a saint!!!! > D > > On 9/24/19 12:45 PM, Arnold Robbins wrote: > > Hello All. > > > > Believed lost in the mists of time for over 30 years, the Georgia Tech > > Software Tools Subsystem for Prime Computers, along with the Georgia Tech > > C Compiler for Prime Computers, have been recovered! > > > > The source code and documentation (and binary files) are available in a > > Github repo: https://github.com/arnoldrobbins/gt-swt. > > > > The README.md there provides some brief history and credits with respect > > to the recovery, and w.r.t. the subsystem and C compilers themselves. > > > > Credit to Scott Lee for making and keeping the tapes and driving the > > recovery process, and to Dennis Boone and yours truly for contributing > > financially. I set up the repo. > > > > For anyone who used and/or contributed to this software, we hope you'll > > enjoy this trip down memory lane. > > > > Feel free to forward this note to interested parties. > > > > Enjoy, > > > > Arnold Robbins > > (On behalf of the swt recovery team. :-) > From arnold at skeeve.com Thu Sep 26 16:13:29 2019 From: arnold at skeeve.com (arnold at skeeve.com) Date: Thu, 26 Sep 2019 00:13:29 -0600 Subject: [TUHS] Recovered!!! The Georgia Tech Software Tools Subystemfor Prime Computers In-Reply-To: <0c66d8e5-ef8b-4682-b8a0-281c5c7c0359@PU1APC01FT115.eop-APC01.prod.protection.outlook.com> References: <201909241945.x8OJjTCX032294@skeeve.com> <7wo8z7zj96.fsf@junk.nocrew.org> <0c66d8e5-ef8b-4682-b8a0-281c5c7c0359@PU1APC01FT115.eop-APC01.prod.protection.outlook.com> Message-ID: <201909260613.x8Q6DT4u017544@freefriends.org> Hi. The emulator is not at all related to GT-SWT. You can contact the guy who did it --- read the full message Lars quotes below. Arnold Jason Stevens wrote: > I now get this: > > All available connections are in use. > > Connection to host lost. > > > I guess progress. > > Oh well, I guess it’s not possible to distribute the emulator? > > > From: Lars Brinkhoff > Sent: Thursday, September 26, 2019 2:03 PM > To: Jason Stevens > Cc: tuhs at minnie.tuhs.org > Subject: Re: [TUHS] Recovered!!! The Georgia Tech Software Tools Subystemfor Prime Computers > > > I see mention of an emulator in the GitHub repo, but I don’t see any > > emulator that is available. > > I see this: > > Welcome to the Prime Computer 50-series emulator, running Primos rev 24.0! > > Login as user guest, password pr1me > Hit a few returns and Ctrl-q if it appears "stuck"; some bots are hitting the emulator > After logging in, use the Prime HELP command for assistance. > You are welcome to create a directory under GUEST for your files. > The emacs terminal type is xterm > The line erase character is ? > There are other Primos revs running on ports 8001-8007 > Prime manuals at: http://yagi.h-net.msu.edu/prime_manuals/prirun_scans > To report bugs or contact the author, send email to prirun at gmail.com > > Enjoy your time travels! -Jim Wilcoxson aka JIMMY > > Login please. > > login guest > Password? > > GUEST (user 2) logged in Thursday, 26 Sep 19 02:03:08. > Welcome to PRIMOS version 24.0.0.r15 > Copyright (c) Computervision, Corp. 1993. > Last login Tuesday, 24 Sep 19 19:58:08. > > > Warning! There was 1 failed attempt to login under this id since the > last successful login. > > OK, > From lars at nocrew.org Thu Sep 26 16:23:07 2019 From: lars at nocrew.org (Lars Brinkhoff) Date: Thu, 26 Sep 2019 06:23:07 +0000 Subject: [TUHS] Recovered!!! The Georgia Tech Software Tools Subystemfor Prime Computers In-Reply-To: <0c66d8e5-ef8b-4682-b8a0-281c5c7c0359@PU1APC01FT115.eop-APC01.prod.protection.outlook.com> (Jason Stevens's message of "Thu, 26 Sep 2019 14:08:01 +0800") References: <201909241945.x8OJjTCX032294@skeeve.com> <7wo8z7zj96.fsf@junk.nocrew.org> <0c66d8e5-ef8b-4682-b8a0-281c5c7c0359@PU1APC01FT115.eop-APC01.prod.protection.outlook.com> Message-ID: <7wblv7zid0.fsf@junk.nocrew.org> Jason Stevens wrote: > Oh well, I guess it’s not possible to distribute the emulator? >From what I hear, the main problem is that it's not possible to distribute PRIMOS. Which is a shame; it does have Emacs so it must be a nice operating system. This this thread is branching off topic anyway, I'll just quickly mention that I'm currently working on "Small ITS". An ITS-like operating system for the MIT Logo group PDP-11/45. "PDP-11" <- see, almost back on topic. Sorry, those who are curious may contact me privately. From arnold at skeeve.com Thu Sep 26 16:27:34 2019 From: arnold at skeeve.com (arnold at skeeve.com) Date: Thu, 26 Sep 2019 00:27:34 -0600 Subject: [TUHS] Recovered!!! The Georgia Tech Software Tools Subystemfor Prime Computers In-Reply-To: <7wblv7zid0.fsf@junk.nocrew.org> References: <201909241945.x8OJjTCX032294@skeeve.com> <7wo8z7zj96.fsf@junk.nocrew.org> <0c66d8e5-ef8b-4682-b8a0-281c5c7c0359@PU1APC01FT115.eop-APC01.prod.protection.outlook.com> <7wblv7zid0.fsf@junk.nocrew.org> Message-ID: <201909260627.x8Q6RYGq017933@freefriends.org> Lars Brinkhoff wrote: > Jason Stevens wrote: > > Oh well, I guess it’s not possible to distribute the emulator? > > From what I hear, the main problem is that it's not possible to > distribute PRIMOS. Which is a shame; it does have Emacs so it must be a > nice operating system. Hahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahaha. It was bizarre and ugly. The only thing that made it anywhere near usable were the Software Tools. There's a reason Prime died pretty quickly once Unix started to spread. The architecture also was strange; the characters used mark parity (8th bit always on). My 2 cents. Arnold From cym224 at gmail.com Thu Sep 26 23:28:39 2019 From: cym224 at gmail.com (Nemo) Date: Thu, 26 Sep 2019 09:28:39 -0400 Subject: [TUHS] Recovered!!! The Georgia Tech Software Tools Subystemfor Prime Computers In-Reply-To: References: <201909241945.x8OJjTCX032294@skeeve.com> Message-ID: On 26/09/2019, Jason Stevens wrote (in part): > All that is mentioned is a telnet address to something that just drops. Some home routers drop incoming telnet. N. From clemc at ccc.com Thu Sep 26 23:28:15 2019 From: clemc at ccc.com (Clem Cole) Date: Thu, 26 Sep 2019 09:28:15 -0400 Subject: [TUHS] [COFF] [was TUHS] Pr1me and GT-SWT In-Reply-To: <201909260627.x8Q6RYGq017933@freefriends.org> References: <201909241945.x8OJjTCX032294@skeeve.com> <7wo8z7zj96.fsf@junk.nocrew.org> <0c66d8e5-ef8b-4682-b8a0-281c5c7c0359@PU1APC01FT115.eop-APC01.prod.protection.outlook.com> <7wblv7zid0.fsf@junk.nocrew.org> <201909260627.x8Q6RYGq017933@freefriends.org> Message-ID: At the risk of this drifting, it probably should move over to the COFF mailing list, which I have CC'ed. I'll do this one last one here so people not yet on COFF that want to follow up can see it. On Thu, Sep 26, 2019 at 2:27 AM wrote: > It was bizarre and ugly. The only thing that made it anywhere > near usable were the Software Tools. > Amen... (more in a minute) > > There's a reason Prime died pretty quickly once Unix started to > spread. The architecture also was strange; the characters used > mark parity (8th bit always on). > Yeah, it was an interesting box. Fast and cost-effective for its time and an excellent Fortran system which why they did as well as they did. > > My 2 cents. > > Arnold > You probably know this but you folks had a huge influence on the Pr1mates. So much so when Bill P, Paul L, and Michael S. left Pr1me to create Apollo, the used your version of the SWT as their first command system for Aegis (*a.k.a.* DOMAIN OS). They did not quite get it that they needed a real UNIX, so they roped tjt and myself from Masscomp went we all formed Belmont (*a.k.a.* Stellar in a later renaming). But they did recognize it was useful and people wanted to use that style of interface, not something dreamed up specific to that machine. I remember trying to explain to Bill the difference - he's a vision guy, but primarily a hardware type, although one of the most amazing people I have ever known. IMO: Leach never really understood the Unix ideas of being simple (which is one of the reasons why Windows has that forsaken registry sin from Aegis, he brought it with him from Apollo to MSFT). I used to argue with him about it in the 1980s (he hated/thought ASCII text files were terrible and he should control everything in some framework or privileged API). -------------- next part -------------- An HTML attachment was scrubbed... URL: From spedraja at gmail.com Fri Sep 27 00:54:31 2019 From: spedraja at gmail.com (SPC) Date: Thu, 26 Sep 2019 16:54:31 +0200 Subject: [TUHS] Recovered!!! The Georgia Tech Software Tools Subystemfor Prime Computers In-Reply-To: References: <201909241945.x8OJjTCX032294@skeeve.com> Message-ID: El jue., 26 sept. 2019 15:29, Nemo escribió: > On 26/09/2019, Jason Stevens wrote (in > part): > > All that is mentioned is a telnet address to something that just drops. > > Some home routers drop incoming telnet. > I got connected without problem a coupoe of days ago. REMEMBER that you *must* telnet to "em.prirun.com:《port_number》", being the port to use one of the series from 8001 to 8007. There is one different version of PRIMOS running at everyone of these ip ports. Cordiales saludos / Best Regards / Salutations / Freundliche Grüße ----- Sergio Pedraja Skype: spedraja at gmail.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jsteve at superglobalmegacorp.com Fri Sep 27 01:48:07 2019 From: jsteve at superglobalmegacorp.com (Jason Stevens) Date: Thu, 26 Sep 2019 15:48:07 +0000 (UTC) Subject: [TUHS] Recovered!!! The Georgia Tech Software Tools Subystemfor Prime Computers In-Reply-To: References: <201909241945.x8OJjTCX032294@skeeve.com> Message-ID: I did use the port number.  It didn't work as it was either full or just dropping. It's too off topic anyways, I guess it'll be some other obscure thing with a C compiler, I guess. I guess the excitement is that it's written in Fortran?  I assume it's like those Unix emulation packages for VMS.  Although I've never seen one of those either. On Thu, Sep 26, 2019 at 10:54 PM +0800, "SPC" wrote: El jue., 26 sept. 2019 15:29, Nemo escribió: On 26/09/2019, Jason Stevens wrote (in part): > All that is mentioned is a telnet address to something that just drops. Some home routers drop incoming telnet. I got connected without problem a coupoe of days ago. REMEMBER that you *must* telnet to "em.prirun.com:«port_number»", being the port to use one of the series from 8001 to 8007. There is one different version of PRIMOS running at everyone of these ip ports. Cordiales saludos / Best Regards / Salutations / Freundliche Grüße ----- Sergio Pedraja Skype: spedraja at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From sauer at technologists.com Fri Sep 27 03:12:30 2019 From: sauer at technologists.com (Charles H Sauer) Date: Thu, 26 Sep 2019 12:12:30 -0500 Subject: [TUHS] multi-booting four *nix plus 3 Win editions plus OS/2 on 1992 Dell 486D/50 Message-ID: <28630762-1d91-0013-8d0d-e5f95a294674@technologists.com> tl;dr multibooting a 1992 Dell 486D/50 WFW3.11+Win95+Win2K+DellSVR4+NEXTSTEP+RedHat5.2+OS/2 3.0+OpenBSD2.5 https://www.youtube.com/watch?v=GgKjSXI7HOI (Maybe it should be tl;dw — didn’t watch — the video is long.) This post is intended to both be more accessible summary and provide details that are not in the video. https://notes.technologists.com/notes/2019/09/26/koko-welcome-to-eight-jurassic-o-s-on-1992-dell-486d-50/ Charlie -- voice: +1.512.784.7526 e-mail: sauer at technologists.com fax: +1.512.346.5240 Web: https://technologists.com/sauer/ Facebook/Google/Skype/Twitter: CharlesHSauer From imp at bsdimp.com Fri Sep 27 07:14:28 2019 From: imp at bsdimp.com (Warner Losh) Date: Thu, 26 Sep 2019 15:14:28 -0600 Subject: [TUHS] UNIX NEWS, volumes 1-7 out there? In-Reply-To: <20190926025437.GC19436@wopr> References: <20190926025437.GC19436@wopr> Message-ID: On Wed, Sep 25, 2019 at 8:54 PM Kurt H Maier wrote: > On Wed, Sep 25, 2019 at 11:30:47AM -0400, Clem Cole wrote: > > On Wed, Sep 25, 2019 at 11:16 AM Warner Losh wrote: > > > > > I'm looking for complete compies of UNIX NEWS volumes 1-7. 8 and newer > are > > > > FYI: the folks at USENIX has been looking for these for a number of > years. > > Let me know if you find copies of them and I will get them pushed back > to > > the USENIX archives. > > I have a large swath of #4, dated 19 March 1976, if we're talking about > the same thing. I've scanned it in at 600 dpi: > http://sciops.net/images/unix-news/1976-03-19/ Awesome... Yes. That sort of thing. I'm trying to pull together things like this... I fear Clem may be right, but I sure hope he's wrong.... History suggests I'd be unwise to bet too much against him... If he's wrong, it will be only in the small... Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Fri Sep 27 07:35:27 2019 From: clemc at ccc.com (Clem Cole) Date: Thu, 26 Sep 2019 17:35:27 -0400 Subject: [TUHS] UNIX NEWS, volumes 1-7 out there? In-Reply-To: References: <20190926025437.GC19436@wopr> Message-ID: On Thu, Sep 26, 2019 at 5:14 PM Warner Losh wrote: > > > On Wed, Sep 25, 2019 at 8:54 PM Kurt H Maier wrote: > >> On Wed, Sep 25, 2019 at 11:30:47AM -0400, Clem Cole wrote: >> > On Wed, Sep 25, 2019 at 11:16 AM Warner Losh wrote: >> > >> > > I'm looking for complete compies of UNIX NEWS volumes 1-7. 8 and >> newer are >> > >> > FYI: the folks at USENIX has been looking for these for a number of >> years. >> > Let me know if you find copies of them and I will get them pushed back >> to >> > the USENIX archives. >> >> I have a large swath of #4, dated 19 March 1976, if we're talking about >> the same thing. I've scanned it in at 600 dpi: >> http://sciops.net/images/unix-news/1976-03-19/ > > > Awesome... Yes. That sort of thing. I'm trying to pull together things > like this... > > I fear Clem may be right, but I sure hope he's wrong.... > I would *love* to be proven otherwise. I'm thrilled to see what Kurt has found!!! -------------- next part -------------- An HTML attachment was scrubbed... URL: From wkt at tuhs.org Sat Sep 28 12:02:30 2019 From: wkt at tuhs.org (Warren Toomey) Date: Sat, 28 Sep 2019 12:02:30 +1000 Subject: [TUHS] Poll: good location for Unix documentation? Message-ID: <20190928020230.GB18235@minnie.tuhs.org> All, I'm just musing where is the best place to store Unix documentation. My Unix Archive is really just a filesystem, so it's not so good to capture and search metadata. Is anybody using archive.org, gunkies or something else, and have recommendations? Cheers, Warren From wkt at tuhs.org Sat Sep 28 12:10:46 2019 From: wkt at tuhs.org (Warren Toomey) Date: Sat, 28 Sep 2019 12:10:46 +1000 Subject: [TUHS] Poll: good location for Unix documentation? In-Reply-To: <20190928020230.GB18235@minnie.tuhs.org> References: <20190928020230.GB18235@minnie.tuhs.org> Message-ID: <20190928021046.GA20696@minnie.tuhs.org> On Sat, Sep 28, 2019 at 12:02:30PM +1000, Warren Toomey wrote: > Is anybody using archive.org, gunkies or something else, and have > recommendations? Argh, bitsavers too, sorry Al, I forgot! Warren From athornton at gmail.com Sat Sep 28 12:38:05 2019 From: athornton at gmail.com (Adam Thornton) Date: Fri, 27 Sep 2019 19:38:05 -0700 Subject: [TUHS] Poll: good location for Unix documentation? In-Reply-To: <20190928020230.GB18235@minnie.tuhs.org> References: <20190928020230.GB18235@minnie.tuhs.org> Message-ID: <1AE27AAC-A1BB-4484-8518-769E849BBB6C@gmail.com> > On Sep 27, 2019, at 7:02 PM, Warren Toomey wrote: > > All, I'm just musing where is the best place to store Unix documentation. > My Unix Archive is really just a filesystem, so it's not so good to > capture and search metadata. > > Is anybody using archive.org, gunkies or something else, and have > recommendations? I know Jason Scott at archive.org and I trust him. Bitsavers is also, obviously, known to be good. I don’t know who’s behind gunkies but it seems like they have good stuff. I would say: it’s not YOUR job to organize the metadata, it’s the search engines’. Just hosting the docs and making them available for index is probably a lot of the battle. Adam -------------- next part -------------- An HTML attachment was scrubbed... URL: From lars at nocrew.org Sat Sep 28 14:56:35 2019 From: lars at nocrew.org (Lars Brinkhoff) Date: Sat, 28 Sep 2019 04:56:35 +0000 Subject: [TUHS] Poll: good location for Unix documentation? In-Reply-To: <20190928021046.GA20696@minnie.tuhs.org> (Warren Toomey's message of "Sat, 28 Sep 2019 12:10:46 +1000") References: <20190928020230.GB18235@minnie.tuhs.org> <20190928021046.GA20696@minnie.tuhs.org> Message-ID: <7wk19tt3wc.fsf@junk.nocrew.org> I like bitsavers. Gunikes is a wiki, maybe not appropriate for uploading documents? From jsteve at superglobalmegacorp.com Sun Sep 29 18:25:20 2019 From: jsteve at superglobalmegacorp.com (Jason Stevens) Date: Sun, 29 Sep 2019 08:25:20 +0000 (UTC) Subject: [TUHS] Poll: good location for Unix documentation? In-Reply-To: <20190928020230.GB18235@minnie.tuhs.org> References: <20190928020230.GB18235@minnie.tuhs.org> Message-ID: Gunkies.org is a wiki that is really good for pointing to stuff, and things like tutorials, indexes and other non original stuff. Archive.org is a great dumping ground for stuff, although it's easy to get lost in the shuffle. I'm not an admin on gunkies.org but I do get my email at least answered, so if you have no luck trying to create an account I'll bug the owner to make it happen. When I had more spare time I tried to seed gunkies with as much as I could. Get Outlook for Android On Sat, Sep 28, 2019 at 11:03 AM +0900, "Warren Toomey" wrote: All, I'm just musing where is the best place to store Unix documentation. My Unix Archive is really just a filesystem, so it's not so good to capture and search metadata. Is anybody using archive.org, gunkies or something else, and have recommendations? Cheers, Warren -------------- next part -------------- An HTML attachment was scrubbed... URL: From spedraja at gmail.com Sun Sep 29 18:52:50 2019 From: spedraja at gmail.com (SPC) Date: Sun, 29 Sep 2019 10:52:50 +0200 Subject: [TUHS] Poll: good location for Unix documentation? In-Reply-To: <20190928020230.GB18235@minnie.tuhs.org> References: <20190928020230.GB18235@minnie.tuhs.org> Message-ID: El sáb., 28 sept. 2019 4:03, Warren Toomey escribió: > > Is anybody using archive.org, gunkies or something else, and have > recommendations? > I use archive.org *a lot* of times in relation with a wide number of topics. Iam very happy with the results but I must admit that it's huge and sometimes a bit confused. On the other hand a diverse kind of files can be stored, mostly multimedia and pdf/ps/text. I think binary files too but not as EXE. ISO images or similar are more usual. Cordiales saludos / Best Regards / Salutations / Freundliche Grüße ----- Sergio Pedraja > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wkt at tuhs.org Sun Sep 29 19:21:58 2019 From: wkt at tuhs.org (Warren Toomey) Date: Sun, 29 Sep 2019 19:21:58 +1000 Subject: [TUHS] OT: compiler back-end bug Message-ID: <20190929092158.GA27566@minnie.tuhs.org> All, very off-topic for TUHS but you have a bounty of experience. If any of you have Intel ia64 skills and/or fixing compiler back-end bugs, could you contact me off-list? I'm writing a back-end for the SubC compiler and I have 'one last bug'™ before it can compile itself, and I'm stuck. Details at: https://minnie.tuhs.org/wktcloud/index.php/s/QdKZAqcBytoFBkQ/download?path=%2F&files=help.txt Thanks, Warren From ralph at inputplus.co.uk Sun Sep 29 19:47:26 2019 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Sun, 29 Sep 2019 10:47:26 +0100 Subject: [TUHS] OT: compiler back-end bug In-Reply-To: <20190929092158.GA27566@minnie.tuhs.org> References: <20190929092158.GA27566@minnie.tuhs.org> Message-ID: <20190929094726.6488620154@orac.inputplus.co.uk> Hi Warren, > If any of you have Intel ia64 skills and/or fixing compiler back-end > bugs, could you contact me off-list? Sorry, on list, but it may help the willing eyeballs if > To see the original compiler's assembly version of fwrite(): > > $ ./scc0 -S lib/fwrite.c > > To see my compiler's [faulty] assembly version of fwrite(): > > $ ./myscc -S lib/fwrite.c these two were made easily available, e.g. a pastebin like curl -sSF 'f:1=<-' ix.io At present, my compiler fwrite() code is passing bogus arguments to > memcpy() where it crashes with a segfault. wouldn't involve downloads, make, etc., that make it easy to think one doesn't have the time to look. :-) -- Cheers, Ralph. From wkt at tuhs.org Sun Sep 29 20:03:36 2019 From: wkt at tuhs.org (Warren Toomey) Date: Sun, 29 Sep 2019 20:03:36 +1000 Subject: [TUHS] OT: compiler back-end bug In-Reply-To: <20190929094726.6488620154@orac.inputplus.co.uk> References: <20190929092158.GA27566@minnie.tuhs.org> <20190929094726.6488620154@orac.inputplus.co.uk> Message-ID: <20190929100336.GA2390@minnie.tuhs.org> On Sun, Sep 29, 2019 at 10:47:26AM +0100, Ralph Corderoy wrote: > these two were made easily available, e.g. a pastebin like > wouldn't involve downloads, make, etc., that make it easy to think one > doesn't have the time to look. :-) Good point Ralph: https://minnie.tuhs.org/wktcloud/index.php/s/HQjsggHb4i6wdWM?path=%2FSfiles Thanks! Warren From ralph at inputplus.co.uk Sun Sep 29 20:50:16 2019 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Sun, 29 Sep 2019 11:50:16 +0100 Subject: [TUHS] OT: compiler back-end bug In-Reply-To: <20190929100336.GA2390@minnie.tuhs.org> References: <20190929092158.GA27566@minnie.tuhs.org> <20190929094726.6488620154@orac.inputplus.co.uk> <20190929100336.GA2390@minnie.tuhs.org> Message-ID: <20190929105016.92665200AB@orac.inputplus.co.uk> Hi Warren, > Good point Ralph: > https://minnie.tuhs.org/wktcloud/index.php/s/HQjsggHb4i6wdWM?path=%2FSfiles I've always tried to avoid x86 and friends for ARM, so I may be wrong, but the run up to the first of the two memcpy() calls looks the same to me. Here's the assembler, values given an RBP of 100, and the stack contents. Good version first, bad second. rbp = 100 L29: movq -8(%rbp),%rax rax = *92 pushq %rax *92 movq 16(%rbp),%rax rax = *116 pushq %rax *92 *116 movq $64,%rax rax = 64 pushq %rax *92 *116 64 movq 32(%rbp),%rax rax = *132 popq %rcx rcx = 64 *92 *116 addq %rcx,%rax rcx = 64+*132 movq (%rax),%rax rax = *(64+*132) pushq %rax *92 *116 *(64+*132) movq $40,%rax rax = 40 pushq %rax *92 *116 *(64+*132) 40 movq 32(%rbp),%rax rax = *132 popq %rcx rcx = 40 *92 *116 *(64+*132) addq %rcx,%rax rax = 40+*132 movq (%rax),%rax rax = *(40+*132) popq %rcx rcx = *(64+*132) *92 *116 addq %rcx,%rax rax = *(64+*132)+*(40+*132) pushq %rax *92 *116 *(64+*132)+*(40+*132) call Cmemcpy rbp = 100 L29: movq -8(%rbp),%r8 r8 = *92 pushq %r8 *92 movq 16(%rbp),%r8 r8 = *116 pushq %r8 *92 *116 movq $64,%r8 r8 = 64 movq 32(%rbp),%r9 r9 = *132 addq %r9,%r8 r8 = *132+64 movq (%r8),%r8 r8 = *(*132+64) movq $40,%r9 r9 = 40 movq 32(%rbp),%r10 r10 = *132 addq %r10,%r9 r9 = *132+40 movq (%r9),%r9 r9 = *(*132+40) addq %r9,%r8 r8 = *(*132+64)+*(*132+40) pushq %r8 *92 *116 *(*132+64)+*(*132+40) call Cmemcpy A glance at the second memcpy() call look equivalent too. So perhaps it's not calculating the parameters to memcpy() that's wrong, but the inputs into those calculations being faulty? I'd use gdb(1) to break at particular instructions, examine memory, etc., to work backwards through the bad version until spotting where good data becomes bad. -- Cheers, Ralph. From jnc at mercury.lcs.mit.edu Mon Sep 30 04:53:20 2019 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Sun, 29 Sep 2019 14:53:20 -0400 (EDT) Subject: [TUHS] Poll: good location for Unix documentation? Message-ID: <20190929185320.5902C18C088@mercury.lcs.mit.edu> > From: Warren Toomey > All, I'm just musing where is the best place to store Unix > documentation. My Unix Archive is really just a filesystem, so it's not > so good to capture and search metadata. > Is anybody using archive.org, gunkies or something else BitSavers seems to be the canonical location for old computer documentation. The CHWiki (gunkies.org) isn't really the best place to put original documentation, but that's where I'd recommend putting meta-data. As for searching meta-data, are you speaking of something more powerful than Google? Noel PS: Speaking of old Unix documentation, I recently acquired a paper copy of the PDP-11 V6 Unix manual. Is that something I should scan? I don't know if you already have it (I know where to find sources in the archives, but I don't know where documentation scans live.) From blstuart at bellsouth.net Mon Sep 30 06:11:52 2019 From: blstuart at bellsouth.net (Brian L. Stuart) Date: Sun, 29 Sep 2019 20:11:52 +0000 (UTC) Subject: [TUHS] Poll: good location for Unix documentation? In-Reply-To: <20190929185320.5902C18C088@mercury.lcs.mit.edu> References: <20190929185320.5902C18C088@mercury.lcs.mit.edu> Message-ID: <643282730.657492.1569787912823@mail.yahoo.com> On Sunday, September 29, 2019, 2:53:52 PM EDT, Noel Chiappa wrote: > PS: Speaking of old Unix documentation, I recently acquired a paper copy of the > PDP-11 V6 Unix manual. Is that something I should scan? I don't know if you > already have it (I know where to find sources in the archives, but I don't > know where documentation scans live.) I was looking for a copy of that for my exhibit at VCF southeast this year, but I never could find a complete copy. There's a mostly complete scan on archive.org, but there are some bits missing. I'd have to do a little digging to say just which bits, though. (The tmg doc was one I remember not being there.) BLS -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Mon Sep 30 06:23:24 2019 From: clemc at ccc.com (Clem Cole) Date: Sun, 29 Sep 2019 16:23:24 -0400 Subject: [TUHS] Poll: good location for Unix documentation? In-Reply-To: <20190929185320.5902C18C088@mercury.lcs.mit.edu> References: <20190929185320.5902C18C088@mercury.lcs.mit.edu> Message-ID: On Sun, Sep 29, 2019 at 2:54 PM Noel Chiappa wrote: > > From: Warren Toomey > > > All, I'm just musing where is the best place to store Unix > > documentation. My Unix Archive is really just a filesystem, so it's > not > > so good to capture and search metadata. > > Is anybody using archive.org, gunkies or something else > > BitSavers seems to be the canonical location for old computer > documentation. > I agree +1 BitSavers, but Warren you should keep your stuff. One-stop shopping for UNIX archives is a good thing. > > The CHWiki (gunkies.org) isn't really the best place to put original > documentation, > but that's where I'd recommend putting meta-data. As for searching > meta-data, are > you speaking of something more powerful than Google? > > Noel > > PS: Speaking of old Unix documentation, I recently acquired a paper copy > of the > PDP-11 V6 Unix manual. Is that something I should scan? I don't know if you > already have it (I know where to find sources in the archives, but I don't > know where documentation scans live.) > What I personally have is impure, and I have not seen a complete one elsewhere, so if you have a real manual, that is a good thing IMHO. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wkt at tuhs.org Mon Sep 30 07:34:46 2019 From: wkt at tuhs.org (Warren Toomey) Date: Mon, 30 Sep 2019 07:34:46 +1000 Subject: [TUHS] Poll: good location for Unix documentation? In-Reply-To: <20190929185320.5902C18C088@mercury.lcs.mit.edu> References: <20190929185320.5902C18C088@mercury.lcs.mit.edu> Message-ID: <20190929213446.GA30379@minnie.tuhs.org> On Sun, Sep 29, 2019 at 02:53:20PM -0400, Noel Chiappa wrote: > BitSavers seems to be the canonical location for old computer documentation. Looks like BitSavers is the recommendation. Can someone point me at the docs that outline the procedure to get documents to Al (others as well?) for consideration. I might put things in both bitsavers.org and archive.org. Cheers, Warren From jnc at mercury.lcs.mit.edu Mon Sep 30 07:54:20 2019 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Sun, 29 Sep 2019 17:54:20 -0400 (EDT) Subject: [TUHS] Poll: good location for Unix documentation? Message-ID: <20190929215420.567C018C092@mercury.lcs.mit.edu> > From: "Brian L. Stuart" > (The tmg doc was one I remember not being there.) Err, TMG(VI) is 1/2 page long. Is that really what you were looking for? (I _did_ specify the 'UPM'.) I do happen to have the V6-era TMG _manual_, if that's what you're looking for. Noel From dave at horsfall.org Mon Sep 30 08:40:24 2019 From: dave at horsfall.org (Dave Horsfall) Date: Mon, 30 Sep 2019 08:40:24 +1000 (EST) Subject: [TUHS] Poll: good location for Unix documentation? In-Reply-To: <20190929213446.GA30379@minnie.tuhs.org> References: <20190929185320.5902C18C088@mercury.lcs.mit.edu> <20190929213446.GA30379@minnie.tuhs.org> Message-ID: On Mon, 30 Sep 2019, Warren Toomey wrote: > I might put things in both bitsavers.org and archive.org. A bit of redundancy won't hurt... -- Dave From earl.baugh at gmail.com Mon Sep 30 09:02:45 2019 From: earl.baugh at gmail.com (Earl Baugh) Date: Sun, 29 Sep 2019 19:02:45 -0400 Subject: [TUHS] Poll: good location for Unix documentation? In-Reply-To: <20190929213446.GA30379@minnie.tuhs.org> References: <20190929213446.GA30379@minnie.tuhs.org> Message-ID: I really would suggest first and foremost just getting stuff scanned. Archive.org does pull from bitsavers ( according to Jason when I talked to him ) so posting there should hit both. Redundancy is good. So keeping it on your site as well doesn’t hurt. And having TUHS as a place to look at to start makes a lot of sense to me. Earl Sent from my iPhone > On Sep 29, 2019, at 5:35 PM, Warren Toomey wrote: > > On Sun, Sep 29, 2019 at 02:53:20PM -0400, Noel Chiappa wrote: >> BitSavers seems to be the canonical location for old computer documentation. > > Looks like BitSavers is the recommendation. Can someone point me at the > docs that outline the procedure to get documents to Al (others as well?) for > consideration. > > I might put things in both bitsavers.org and archive.org. > > Cheers, Warren From blstuart at bellsouth.net Mon Sep 30 09:03:05 2019 From: blstuart at bellsouth.net (Brian L. Stuart) Date: Sun, 29 Sep 2019 23:03:05 +0000 (UTC) Subject: [TUHS] Poll: good location for Unix documentation? In-Reply-To: <20190929215420.567C018C092@mercury.lcs.mit.edu> References: <20190929215420.567C018C092@mercury.lcs.mit.edu> Message-ID: <1281188580.691065.1569798185056@mail.yahoo.com> On Sunday, September 29, 2019, 5:54:24 PM EDT, Noel Chiappa wrote: > > From: "Brian L. Stuart" > > (The tmg doc was one I remember not being there.) > > Err, TMG(VI) is 1/2 page long. Is that really what you were looking for? > (I _did_ specify the 'UPM'.) My bad. I missed that part. Wishful thinking had me thinking it included the docs as well as the man pages. > I do happen to have the V6-era TMG _manual_, if that's what you're looking > for. It's one of the items I haven't yet found from the 6th ed docs. The M6 manual is another one that I didn't find. So far, I haven't found a scan of the docs that WE shipped with the tape. BLS -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Mon Sep 30 11:13:28 2019 From: imp at bsdimp.com (Warner Losh) Date: Sun, 29 Sep 2019 19:13:28 -0600 Subject: [TUHS] Poll: good location for Unix documentation? In-Reply-To: <1281188580.691065.1569798185056@mail.yahoo.com> References: <20190929215420.567C018C092@mercury.lcs.mit.edu> <1281188580.691065.1569798185056@mail.yahoo.com> Message-ID: On Sun, Sep 29, 2019, 6:12 PM Brian L. Stuart wrote: > On Sunday, September 29, 2019, 5:54:24 PM EDT, Noel Chiappa < > jnc at mercury.lcs.mit.edu> wrote: > > > From: "Brian L. Stuart" > > > (The tmg doc was one I remember not being there.) > > > > Err, TMG(VI) is 1/2 page long. Is that really what you were looking for? > > (I _did_ specify the 'UPM'.) > > My bad. I missed that part. Wishful thinking had me > thinking it included the docs as well as the man pages. > > > I do happen to have the V6-era TMG _manual_, if that's what you're > looking > > for. > > It's one of the items I haven't yet found from the 6th ed > docs. > https://www.tuhs.org/Archive/Distributions/Research/1972_stuff/tmg.pdf has an earlier version. The M6 manual is another one that I didn't find. > So far, I haven't found a scan of the docs > Ebay number 113713199572 might be of interest. Warner BLS > -------------- next part -------------- An HTML attachment was scrubbed... URL: