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" &lt;clemc(a)ccc.com&gt; To: "Warner Losh" &lt;imp(a)bsdimp.com&gt; Cc: "The Eunuchs Hysterical Society" &lt;tuhs(a)tuhs.org&gt; 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 &lt;imp(a)bsdimp.com [1]> 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-a… [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@bsdimp.com [2] https://www.computerhistory.org/atchm/the-asilomar-microcomputer-workshop-a…

below... On Tue, Sep 10, 2019 at 11:53 PM Warner Losh &lt;imp(a)bsdimp.com&gt; wrote: 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. 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. 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. 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. 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, Interesting... as I said, let me look at what he says and see what I can add. It's possible, the first I saw any of the results was on top of V6, when Ted brought some of it to CMU. 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.

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 &lt;sauer(a)technologists.com&gt; wrote:

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.

Clem Cole &lt;clemc(a)ccc.com&gt; writes: http://delivery.acm.org/10.1145/360000/358504/p1066-jalics.pdf

reed(a)reedmedia.net writes: 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.

Warren Toomey &lt;wkt(a)tuhs.org&gt; wrote: 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

On Fri, Sep 13, 2019, 2:30 AM SPC &lt;spedraja(a)gmail.com&gt; wrote: And my perennial question: are the sources extant? Warnet Also available at:

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. :)

On Wed, Sep 11, 2019 at 1:52 PM &lt;ron(a)ronnatalie.com&gt; wrote: 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 ;-)

Interesting to speculate if that would have sped up the creation of OSF or delayed/prevented it. I think the former.

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" &lt;lm(a)mcvoy.com&gt; To:"Richard Salz" &lt;rich.salz(a)gmail.com&gt; Cc:"The Eunuchs Hysterical Society" &lt;tuhs(a)tuhs.org&gt; 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: then OSF or 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.

On Wed, Sep 11, 2019 at 2:54 PM Larry McVoy &lt;lm(a)mcvoy.com&gt; wrote: 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. Maybe -- as I said, i386 would have been the key. I agree, that might have worked. And then if they wanted to be in the HW biz, let the FOSS world deal with Intel.

On Wed, Sep 11, 2019 at 2:18 PM Richard Salz &lt;rich.salz(a)gmail.com&gt; wrote: 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.

On Wed, 11 Sep 2019, Larry McVoy wrote: Agreed; I used it for years, then was forced to use RCS in my next job :-( -- Dave

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 &lt;lm(a)mcvoy.com&gt; wrote:

Larry McVoy &lt;lm(a)mcvoy.com&gt; wrote: 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 &lt;dot(a)dotat.at&gt; 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.

On Thu, 12 Sep 2019, Larry McVoy wrote: Giggle... I found I could actually *edit* an SCCS file, provided I reset the checksum to zero (it was then recalculated). I believe that NFS is much more reliable now (yes, it used to be awful). -- Dave

On Fri, Sep 13, 2019 at 06:00:09PM +1000, Peter Jeremy wrote: bk admin -z file.c and I'm pretty sure that is sccs compat. Living dangerously.

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

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 Wed, 11 Sep 2019, Larry McVoy wrote: 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

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:

On Thu, Sep 12, 2019, 11:30 AM Clem Cole &lt;clemc(a)ccc.com&gt; wrote: 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

emanuel stiebler wrote in &lt;8db2e89c-ce50-a453-e38a-ecdfe69a746c(a)e-bbes.com&gt;om>: |On 2019-09-12 19:29, Clem Cole wrote: |> On Thu, Sep 12, 2019 at 1:16 PM Eric Allman &lt;tuhs(a)eric.allman.name |> <mailto:tuhs@eric.allman.name>> 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)

On Fri, 13 Sep 2019 14:17:51 -0700 Larry McVoy &lt;lm(a)mcvoy.com&gt; wrote: 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.

Larry McVoy wrote in &lt;20190913211751.GF2046(a)mcvoy.com&gt;om>: |On Fri, Sep 13, 2019 at 11:11:04PM +0200, Steffen Nurpmeso wrote: |> emanuel stiebler wrote in &lt;8db2e89c-ce50-a453-e38a-ecdfe69a746c(a)e-bbes.c\ |> om>: |>|On 2019-09-12 19:29, Clem Cole wrote: |>|> On Thu, Sep 12, 2019 at 1:16 PM Eric Allman &lt;tuhs(a)eric.allman.name |>|> <mailto:tuhs@eric.allman.name>> 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)

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 &lt;20190914015517.GD12480(a)mcvoy.com&gt;om>: |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)

Larry McVoy wrote in &lt;20190916203152.GB9704(a)mcvoy.com&gt;om>: |On Mon, Sep 16, 2019 at 07:23:00PM +0200, Steffen Nurpmeso wrote: |> Larry McVoy wrote in &lt;20190914015517.GD12480(a)mcvoy.com&gt;om>: |>|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 &lt;20190916203152.GB9704(a)mcvoy.com&gt; --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)

Eric Allman wrote in &lt;94341a28-723a-f177-f658-0c827b35591b(a)neophilic.com&gt;om>: |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)

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.

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"

On Fri, Sep 13, 2019 at 7:31 PM &lt;reed(a)reedmedia.net&gt; wrote: 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

JonSteinhart said: 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 &lt;jon(a)fourwinds.com&gt; wrote:

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 &lt;clemc(a)ccc.com&gt; wrote:

On Sat, Sep 14, 2019 at 08:30:38PM -0700, Eric Allman wrote: As roff guy I couldn't agree more.

On Sun, Sep 15, 2019 at 1:18 AM Jon Steinhart &lt;jon(a)fourwinds.com&gt; wrote: We did the same thing at Masscomp. Then Danny Klein wrote a very cool Mac program that spit out pic (before xfig existed). Right...

On Sun, Sep 15, 2019 at 12:16 AM Eric Allman &lt;tuhs(a)eric.allman.name&gt; wrote: +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. 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. 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 *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 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 up to do this larger history (much of which happened after Peter's dates) before we all die off. +1 A louder *amen*.... I agree - as much as I offered some additions and corrections it is well done -- thank you, Warner. Indeed.

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 Saturday, September 14, 2019, &lt;reed(a)reedmedia.net&gt; wrote: 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