* [TUHS] PWB vs Unix/TS @ 2019-09-09 6:25 Warner Losh 2019-09-09 6:36 ` arnold 2019-09-10 15:16 ` Clem Cole 0 siblings, 2 replies; 85+ messages in thread From: Warner Losh @ 2019-09-09 6:25 UTC (permalink / raw) To: The Eunuchs Hysterical Society [-- Attachment #1: Type: text/plain, Size: 918 bytes --] 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... [-- Attachment #2: Type: text/html, Size: 1116 bytes --] ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: [TUHS] PWB vs Unix/TS 2019-09-09 6:25 [TUHS] PWB vs Unix/TS Warner Losh @ 2019-09-09 6:36 ` arnold 2019-09-10 15:16 ` Clem Cole 1 sibling, 0 replies; 85+ messages in thread From: arnold @ 2019-09-09 6:36 UTC (permalink / raw) To: tuhs, imp 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 <imp@bsdimp.com> 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... ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: [TUHS] PWB vs Unix/TS 2019-09-09 6:25 [TUHS] PWB vs Unix/TS Warner Losh 2019-09-09 6:36 ` arnold @ 2019-09-10 15:16 ` Clem Cole 2019-09-11 0:28 ` Steve Johnson ` (3 more replies) 1 sibling, 4 replies; 85+ messages in thread From: Clem Cole @ 2019-09-10 15:16 UTC (permalink / raw) To: Warner Losh; +Cc: The Eunuchs Hysterical Society [-- Attachment #1: Type: text/plain, Size: 13538 bytes --] 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 <imp@bsdimp.com> 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 [-- Attachment #2: Type: text/html, Size: 27527 bytes --] ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: [TUHS] PWB vs Unix/TS 2019-09-10 15:16 ` Clem Cole @ 2019-09-11 0:28 ` Steve Johnson 2019-09-11 3:53 ` Warner Losh ` (2 subsequent siblings) 3 siblings, 0 replies; 85+ messages in thread From: Steve Johnson @ 2019-09-11 0:28 UTC (permalink / raw) To: Clem Cole, Warner Losh; +Cc: The Eunuchs Hysterical Society [-- Attachment #1: Type: text/plain, Size: 18015 bytes --] 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" <clemc@ccc.com> To: "Warner Losh" <imp@bsdimp.com> Cc: "The Eunuchs Hysterical Society" <tuhs@tuhs.org> 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 <imp@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-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@bsdimp.com [2] https://www.computerhistory.org/atchm/the-asilomar-microcomputer-workshop-and-the-billion-dollar-toilet-seat/ [-- Attachment #2: Type: text/html, Size: 32647 bytes --] ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: [TUHS] PWB vs Unix/TS 2019-09-10 15:16 ` Clem Cole 2019-09-11 0:28 ` Steve Johnson @ 2019-09-11 3:53 ` Warner Losh 2019-09-11 15:36 ` Clem Cole 2019-09-11 16:05 ` [TUHS] PWB vs Unix/TS Paul Winalski 2019-09-14 0:44 ` [TUHS] a book (was Re: PWB vs Unix/TS) reed 3 siblings, 1 reply; 85+ messages in thread From: Warner Losh @ 2019-09-11 3:53 UTC (permalink / raw) To: Clem Cole; +Cc: The Eunuchs Hysterical Society [-- Attachment #1: Type: text/plain, Size: 16060 bytes --] On Tue, Sep 10, 2019 at 9:17 AM Clem Cole <clemc@ccc.com> 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 <imp@bsdimp.com> 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] <https://en.wikipedia.org/wiki/PWB/UNIX#cite_note-Mashey-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 > [-- Attachment #2: Type: text/html, Size: 31275 bytes --] ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: [TUHS] PWB vs Unix/TS 2019-09-11 3:53 ` Warner Losh @ 2019-09-11 15:36 ` Clem Cole 2019-09-11 16:55 ` [TUHS] IBM Unix source licenses [was " Charles H Sauer ` (2 more replies) 0 siblings, 3 replies; 85+ messages in thread From: Clem Cole @ 2019-09-11 15:36 UTC (permalink / raw) To: Warner Losh; +Cc: The Eunuchs Hysterical Society [-- Attachment #1: Type: text/plain, Size: 8732 bytes --] below... On Tue, Sep 10, 2019 at 11:53 PM Warner Losh <imp@bsdimp.com> wrote: > > "The Programmer's Workbench was started in 1973,[2] > <https://en.wikipedia.org/wiki/PWB/UNIX#cite_note-Mashey-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. [-- Attachment #2: Type: text/html, Size: 16240 bytes --] ^ permalink raw reply [flat|nested] 85+ messages in thread
* [TUHS] IBM Unix source licenses [was Re: PWB vs Unix/TS 2019-09-11 15:36 ` Clem Cole @ 2019-09-11 16:55 ` Charles H Sauer 2019-09-12 19:31 ` Kevin Bowling 2019-09-11 17:49 ` [TUHS] " Richard Salz 2019-09-11 18:11 ` Larry McVoy 2 siblings, 1 reply; 85+ messages in thread From: Charles H Sauer @ 2019-09-11 16:55 UTC (permalink / raw) To: tuhs 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@technologists.com fax: +1.512.346.5240 Web: https://technologists.com/sauer/ Facebook/Google/Skype/Twitter: CharlesHSauer ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: [TUHS] IBM Unix source licenses [was Re: PWB vs Unix/TS 2019-09-11 16:55 ` [TUHS] IBM Unix source licenses [was " Charles H Sauer @ 2019-09-12 19:31 ` Kevin Bowling 2019-09-12 20:59 ` Clem Cole 2019-09-12 21:29 ` [TUHS] IBM Unix source licenses [was Re: PWB vs Unix/TS Charles H Sauer 0 siblings, 2 replies; 85+ messages in thread From: Kevin Bowling @ 2019-09-12 19:31 UTC (permalink / raw) To: Charles H Sauer; +Cc: TUHS main list 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 <sauer@technologists.com> 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@technologists.com > fax: +1.512.346.5240 Web: https://technologists.com/sauer/ > Facebook/Google/Skype/Twitter: CharlesHSauer ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: [TUHS] IBM Unix source licenses [was Re: PWB vs Unix/TS 2019-09-12 19:31 ` Kevin Bowling @ 2019-09-12 20:59 ` Clem Cole 2019-09-12 21:09 ` [TUHS] IBM Unix source licenses - Series/1 NUXI Ronald Natalie ` (2 more replies) 2019-09-12 21:29 ` [TUHS] IBM Unix source licenses [was Re: PWB vs Unix/TS Charles H Sauer 1 sibling, 3 replies; 85+ messages in thread From: Clem Cole @ 2019-09-12 20:59 UTC (permalink / raw) To: Kevin Bowling; +Cc: TUHS main list [-- Attachment #1: Type: text/plain, Size: 1767 bytes --] Kevin/Charlie: On Thu, Sep 12, 2019 at 3:31 PM Kevin Bowling <kevin.bowling@kev009.com> 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. [-- Attachment #2: Type: text/html, Size: 3216 bytes --] ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: [TUHS] IBM Unix source licenses - Series/1 NUXI 2019-09-12 20:59 ` Clem Cole @ 2019-09-12 21:09 ` Ronald Natalie 2019-09-12 21:31 ` [TUHS] IBM Unix source licenses [was Re: PWB vs Unix/TS Warner Losh 2019-09-12 22:30 ` jcs 2 siblings, 0 replies; 85+ messages in thread From: Ronald Natalie @ 2019-09-12 21:09 UTC (permalink / raw) To: The Eunuchs Hysterical Society [-- Attachment #1: Type: text/plain, Size: 3192 bytes --] 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 <clemc@ccc.com> wrote: > > Kevin/Charlie: > > On Thu, Sep 12, 2019 at 3:31 PM Kevin Bowling <kevin.bowling@kev009.com <mailto:kevin.bowling@kev009.com>> 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 <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. [-- Attachment #2: Type: text/html, Size: 5479 bytes --] ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: [TUHS] IBM Unix source licenses [was Re: PWB vs Unix/TS 2019-09-12 20:59 ` Clem Cole 2019-09-12 21:09 ` [TUHS] IBM Unix source licenses - Series/1 NUXI Ronald Natalie @ 2019-09-12 21:31 ` Warner Losh 2019-09-12 22:30 ` jcs 2 siblings, 0 replies; 85+ messages in thread From: Warner Losh @ 2019-09-12 21:31 UTC (permalink / raw) To: Clem Cole; +Cc: TUHS main list [-- Attachment #1: Type: text/plain, Size: 2008 bytes --] On Thu, Sep 12, 2019 at 3:01 PM Clem Cole <clemc@ccc.com> wrote: > Kevin/Charlie: > > On Thu, Sep 12, 2019 at 3:31 PM Kevin Bowling <kevin.bowling@kev009.com> > 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 [-- Attachment #2: Type: text/html, Size: 3700 bytes --] ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: [TUHS] IBM Unix source licenses [was Re: PWB vs Unix/TS 2019-09-12 20:59 ` Clem Cole 2019-09-12 21:09 ` [TUHS] IBM Unix source licenses - Series/1 NUXI Ronald Natalie 2019-09-12 21:31 ` [TUHS] IBM Unix source licenses [was Re: PWB vs Unix/TS Warner Losh @ 2019-09-12 22:30 ` jcs 2019-09-12 23:12 ` reed 2019-09-12 23:29 ` [TUHS] IBM Unix source licenses Warren Toomey 2 siblings, 2 replies; 85+ messages in thread From: jcs @ 2019-09-12 22:30 UTC (permalink / raw) To: tuhs Clem Cole <clemc@ccc.com> 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 ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: [TUHS] IBM Unix source licenses [was Re: PWB vs Unix/TS 2019-09-12 22:30 ` jcs @ 2019-09-12 23:12 ` reed 2019-09-12 23:22 ` jcs 2019-09-12 23:29 ` [TUHS] IBM Unix source licenses Warren Toomey 1 sibling, 1 reply; 85+ messages in thread From: reed @ 2019-09-12 23:12 UTC (permalink / raw) To: jcs; +Cc: tuhs On Thu, 12 Sep 2019, jcs wrote: > > Clem Cole <clemc@ccc.com> 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.) ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: [TUHS] IBM Unix source licenses [was Re: PWB vs Unix/TS 2019-09-12 23:12 ` reed @ 2019-09-12 23:22 ` jcs 0 siblings, 0 replies; 85+ messages in thread From: jcs @ 2019-09-12 23:22 UTC (permalink / raw) To: reed; +Cc: tuhs reed@reedmedia.net writes: > On Thu, 12 Sep 2019, jcs wrote: > >> >> Clem Cole <clemc@ccc.com> 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. ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: [TUHS] IBM Unix source licenses 2019-09-12 22:30 ` jcs 2019-09-12 23:12 ` reed @ 2019-09-12 23:29 ` Warren Toomey 2019-09-13 7:06 ` arnold 2019-09-13 8:30 ` SPC 1 sibling, 2 replies; 85+ messages in thread From: Warren Toomey @ 2019-09-12 23:29 UTC (permalink / raw) Cc: tuhs Clem Cole <clemc@ccc.com> 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 ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: [TUHS] IBM Unix source licenses 2019-09-12 23:29 ` [TUHS] IBM Unix source licenses Warren Toomey @ 2019-09-13 7:06 ` arnold 2019-09-13 8:30 ` SPC 1 sibling, 0 replies; 85+ messages in thread From: arnold @ 2019-09-13 7:06 UTC (permalink / raw) To: wkt; +Cc: tuhs Warren Toomey <wkt@tuhs.org> wrote: > Clem Cole <clemc@ccc.com> 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 ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: [TUHS] IBM Unix source licenses 2019-09-12 23:29 ` [TUHS] IBM Unix source licenses Warren Toomey 2019-09-13 7:06 ` arnold @ 2019-09-13 8:30 ` SPC 2019-09-14 18:29 ` Warner Losh 1 sibling, 1 reply; 85+ messages in thread From: SPC @ 2019-09-13 8:30 UTC (permalink / raw) To: Warren Toomey; +Cc: tuhs [-- Attachment #1: Type: text/plain, Size: 696 bytes --] El vie., 13 sept. 2019 a las 1:29, Warren Toomey (<wkt@tuhs.org>) escribió: > Clem Cole <clemc@ccc.com> 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* [-- Attachment #2: Type: text/html, Size: 2647 bytes --] ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: [TUHS] IBM Unix source licenses 2019-09-13 8:30 ` SPC @ 2019-09-14 18:29 ` Warner Losh 0 siblings, 0 replies; 85+ messages in thread From: Warner Losh @ 2019-09-14 18:29 UTC (permalink / raw) To: SPC; +Cc: TUHS main list [-- Attachment #1: Type: text/plain, Size: 876 bytes --] On Fri, Sep 13, 2019, 2:30 AM SPC <spedraja@gmail.com> wrote: > > El vie., 13 sept. 2019 a las 1:29, Warren Toomey (<wkt@tuhs.org>) > escribió: > >> Clem Cole <clemc@ccc.com> 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* > > [-- Attachment #2: Type: text/html, Size: 3490 bytes --] ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: [TUHS] IBM Unix source licenses [was Re: PWB vs Unix/TS 2019-09-12 19:31 ` Kevin Bowling 2019-09-12 20:59 ` Clem Cole @ 2019-09-12 21:29 ` Charles H Sauer 1 sibling, 0 replies; 85+ messages in thread From: Charles H Sauer @ 2019-09-12 21:29 UTC (permalink / raw) To: Kevin Bowling; +Cc: TUHS main list 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@technologists.com fax: +1.512.346.5240 Web: https://technologists.com/sauer/ Facebook/Google/Skype/Twitter: CharlesHSauer ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: [TUHS] PWB vs Unix/TS 2019-09-11 15:36 ` Clem Cole 2019-09-11 16:55 ` [TUHS] IBM Unix source licenses [was " Charles H Sauer @ 2019-09-11 17:49 ` Richard Salz 2019-09-11 17:52 ` ron 2019-09-11 18:11 ` Larry McVoy 2 siblings, 1 reply; 85+ messages in thread From: Richard Salz @ 2019-09-11 17:49 UTC (permalink / raw) To: Clem Cole; +Cc: The Eunuchs Hysterical Society [-- Attachment #1: Type: text/plain, Size: 597 bytes --] > 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. :) [-- Attachment #2: Type: text/html, Size: 1325 bytes --] ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: [TUHS] PWB vs Unix/TS 2019-09-11 17:49 ` [TUHS] " Richard Salz @ 2019-09-11 17:52 ` ron 2019-09-11 21:44 ` Clem Cole 0 siblings, 1 reply; 85+ messages in thread From: ron @ 2019-09-11 17:52 UTC (permalink / raw) To: 'Richard Salz', 'Clem Cole' Cc: 'The Eunuchs Hysterical Society' [-- Attachment #1: Type: text/plain, Size: 1122 bytes --] 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 <tuhs-bounces@minnie.tuhs.org> On Behalf Of Richard Salz Sent: Wednesday, September 11, 2019 1:49 PM To: Clem Cole <clemc@ccc.com> Cc: The Eunuchs Hysterical Society <tuhs@tuhs.org> 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. :) [-- Attachment #2: Type: text/html, Size: 3573 bytes --] ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: [TUHS] PWB vs Unix/TS 2019-09-11 17:52 ` ron @ 2019-09-11 21:44 ` Clem Cole 0 siblings, 0 replies; 85+ messages in thread From: Clem Cole @ 2019-09-11 21:44 UTC (permalink / raw) To: Ronald Natalie; +Cc: The Eunuchs Hysterical Society [-- Attachment #1: Type: text/plain, Size: 808 bytes --] On Wed, Sep 11, 2019 at 1:52 PM <ron@ronnatalie.com> 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 ;-) [-- Attachment #2: Type: text/html, Size: 2203 bytes --] ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: [TUHS] PWB vs Unix/TS 2019-09-11 15:36 ` Clem Cole 2019-09-11 16:55 ` [TUHS] IBM Unix source licenses [was " Charles H Sauer 2019-09-11 17:49 ` [TUHS] " Richard Salz @ 2019-09-11 18:11 ` Larry McVoy 2019-09-11 18:18 ` Richard Salz ` (2 more replies) 2 siblings, 3 replies; 85+ messages in thread From: Larry McVoy @ 2019-09-11 18:11 UTC (permalink / raw) To: Clem Cole; +Cc: The Eunuchs Hysterical Society 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. ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: [TUHS] PWB vs Unix/TS 2019-09-11 18:11 ` Larry McVoy @ 2019-09-11 18:18 ` Richard Salz 2019-09-11 18:54 ` Larry McVoy 2019-09-11 21:59 ` Clem Cole 2019-09-11 21:50 ` Clem Cole 2019-09-11 22:49 ` Dave Horsfall 2 siblings, 2 replies; 85+ messages in thread From: Richard Salz @ 2019-09-11 18:18 UTC (permalink / raw) To: Larry McVoy; +Cc: The Eunuchs Hysterical Society [-- Attachment #1: Type: text/plain, Size: 265 bytes --] > > 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. [-- Attachment #2: Type: text/html, Size: 565 bytes --] ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: [TUHS] PWB vs Unix/TS 2019-09-11 18:18 ` Richard Salz @ 2019-09-11 18:54 ` Larry McVoy 2019-09-11 21:05 ` Steve Johnson ` (2 more replies) 2019-09-11 21:59 ` Clem Cole 1 sibling, 3 replies; 85+ messages in thread From: Larry McVoy @ 2019-09-11 18:54 UTC (permalink / raw) To: Richard Salz; +Cc: The Eunuchs Hysterical Society 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. ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: [TUHS] PWB vs Unix/TS 2019-09-11 18:54 ` Larry McVoy @ 2019-09-11 21:05 ` Steve Johnson 2019-09-11 21:34 ` Steve Johnson 2019-09-11 21:57 ` Clem Cole 2 siblings, 0 replies; 85+ messages in thread From: Steve Johnson @ 2019-09-11 21:05 UTC (permalink / raw) To: Larry McVoy, Richard Salz; +Cc: The Eunuchs Hysterical Society [-- Attachment #1: Type: text/plain, Size: 1664 bytes --] 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" <lm@mcvoy.com> To:"Richard Salz" <rich.salz@gmail.com> Cc:"The Eunuchs Hysterical Society" <tuhs@tuhs.org> 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. [-- Attachment #2: Type: text/html, Size: 2431 bytes --] ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: [TUHS] PWB vs Unix/TS 2019-09-11 18:54 ` Larry McVoy 2019-09-11 21:05 ` Steve Johnson @ 2019-09-11 21:34 ` Steve Johnson 2019-09-11 21:57 ` Clem Cole 2 siblings, 0 replies; 85+ messages in thread From: Steve Johnson @ 2019-09-11 21:34 UTC (permalink / raw) To: Larry McVoy, Richard Salz; +Cc: The Eunuchs Hysterical Society, Brian Kernighan [-- Attachment #1: Type: text/plain, Size: 2012 bytes --] 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" <lm@mcvoy.com> To:"Richard Salz" <rich.salz@gmail.com> Cc:"The Eunuchs Hysterical Society" <tuhs@tuhs.org> 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. [-- Attachment #2: Type: text/html, Size: 2890 bytes --] ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: [TUHS] PWB vs Unix/TS 2019-09-11 18:54 ` Larry McVoy 2019-09-11 21:05 ` Steve Johnson 2019-09-11 21:34 ` Steve Johnson @ 2019-09-11 21:57 ` Clem Cole 2019-09-11 22:50 ` Arthur Krewat 2 siblings, 1 reply; 85+ messages in thread From: Clem Cole @ 2019-09-11 21:57 UTC (permalink / raw) To: Larry McVoy; +Cc: The Eunuchs Hysterical Society [-- Attachment #1: Type: text/plain, Size: 789 bytes --] On Wed, Sep 11, 2019 at 2:54 PM Larry McVoy <lm@mcvoy.com> 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. [-- Attachment #2: Type: text/html, Size: 2076 bytes --] ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: [TUHS] PWB vs Unix/TS 2019-09-11 21:57 ` Clem Cole @ 2019-09-11 22:50 ` Arthur Krewat 0 siblings, 0 replies; 85+ messages in thread From: Arthur Krewat @ 2019-09-11 22:50 UTC (permalink / raw) To: tuhs [-- Attachment #1: Type: text/plain, Size: 1415 bytes --] On 9/11/2019 5:57 PM, Clem Cole wrote: > > > On Wed, Sep 11, 2019 at 2:54 PM Larry McVoy <lm@mcvoy.com > <mailto:lm@mcvoy.com>> 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 [-- Attachment #2: Type: text/html, Size: 2840 bytes --] ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: [TUHS] PWB vs Unix/TS 2019-09-11 18:18 ` Richard Salz 2019-09-11 18:54 ` Larry McVoy @ 2019-09-11 21:59 ` Clem Cole 1 sibling, 0 replies; 85+ messages in thread From: Clem Cole @ 2019-09-11 21:59 UTC (permalink / raw) To: Richard Salz; +Cc: The Eunuchs Hysterical Society [-- Attachment #1: Type: text/plain, Size: 376 bytes --] On Wed, Sep 11, 2019 at 2:18 PM Richard Salz <rich.salz@gmail.com> 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. [-- Attachment #2: Type: text/html, Size: 1088 bytes --] ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: [TUHS] PWB vs Unix/TS 2019-09-11 18:11 ` Larry McVoy 2019-09-11 18:18 ` Richard Salz @ 2019-09-11 21:50 ` Clem Cole 2019-09-11 22:49 ` Dave Horsfall 2 siblings, 0 replies; 85+ messages in thread From: Clem Cole @ 2019-09-11 21:50 UTC (permalink / raw) To: Larry McVoy; +Cc: The Eunuchs Hysterical Society [-- Attachment #1: Type: text/plain, Size: 815 bytes --] On Wed, Sep 11, 2019 at 2:11 PM Larry McVoy <lm@mcvoy.com> 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. [-- Attachment #2: Type: text/html, Size: 1547 bytes --] ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: [TUHS] PWB vs Unix/TS 2019-09-11 18:11 ` Larry McVoy 2019-09-11 18:18 ` Richard Salz 2019-09-11 21:50 ` Clem Cole @ 2019-09-11 22:49 ` Dave Horsfall 2019-09-12 3:43 ` [TUHS] SCCS Larry McVoy 2 siblings, 1 reply; 85+ messages in thread From: Dave Horsfall @ 2019-09-11 22:49 UTC (permalink / raw) To: The Eunuchs Hysterical Society 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 ^ permalink raw reply [flat|nested] 85+ messages in thread
* [TUHS] SCCS 2019-09-11 22:49 ` Dave Horsfall @ 2019-09-12 3:43 ` Larry McVoy 2019-09-12 4:20 ` George Michaelson ` (2 more replies) 0 siblings, 3 replies; 85+ messages in thread From: Larry McVoy @ 2019-09-12 3:43 UTC (permalink / raw) To: Dave Horsfall; +Cc: The Eunuchs Hysterical Society, rick 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 <serial> delete: ^AD <serial> end: ^AE <serial> 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 ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: [TUHS] SCCS 2019-09-12 3:43 ` [TUHS] SCCS Larry McVoy @ 2019-09-12 4:20 ` George Michaelson 2019-09-12 4:31 ` [TUHS] [SPAM] SCCS Larry McVoy 2019-09-12 4:28 ` [TUHS] SCCS Jon Forrest 2019-09-12 20:07 ` Nemo 2 siblings, 1 reply; 85+ messages in thread From: George Michaelson @ 2019-09-12 4:20 UTC (permalink / raw) To: Larry McVoy; +Cc: The Eunuchs Hysterical Society, rick 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 <lm@mcvoy.com> 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 <serial> > delete: ^AD <serial> > end: ^AE <serial> > > 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 ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: [TUHS] [SPAM] Re: SCCS 2019-09-12 4:20 ` George Michaelson @ 2019-09-12 4:31 ` Larry McVoy 2019-09-12 13:44 ` Tony Finch 0 siblings, 1 reply; 85+ messages in thread From: Larry McVoy @ 2019-09-12 4:31 UTC (permalink / raw) To: George Michaelson; +Cc: The Eunuchs Hysterical Society, rick 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 <lm@mcvoy.com> 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 <serial> > > delete: ^AD <serial> > > end: ^AE <serial> > > > > 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 ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: [TUHS] [SPAM] Re: SCCS 2019-09-12 4:31 ` [TUHS] [SPAM] SCCS Larry McVoy @ 2019-09-12 13:44 ` Tony Finch 2019-09-13 4:11 ` Larry McVoy 0 siblings, 1 reply; 85+ messages in thread From: Tony Finch @ 2019-09-12 13:44 UTC (permalink / raw) To: Larry McVoy; +Cc: The Eunuchs Hysterical Society Larry McVoy <lm@mcvoy.com> 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 <dot@dotat.at> 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. ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: [TUHS] [SPAM] Re: SCCS 2019-09-12 13:44 ` Tony Finch @ 2019-09-13 4:11 ` Larry McVoy 2019-09-13 5:54 ` Dave Horsfall 0 siblings, 1 reply; 85+ messages in thread From: Larry McVoy @ 2019-09-13 4:11 UTC (permalink / raw) To: Tony Finch; +Cc: The Eunuchs Hysterical Society On Thu, Sep 12, 2019 at 02:44:45PM +0100, Tony Finch wrote: > Larry McVoy <lm@mcvoy.com> 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 ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: [TUHS] [SPAM] Re: SCCS 2019-09-13 4:11 ` Larry McVoy @ 2019-09-13 5:54 ` Dave Horsfall 2019-09-13 8:00 ` Peter Jeremy 0 siblings, 1 reply; 85+ messages in thread From: Dave Horsfall @ 2019-09-13 5:54 UTC (permalink / raw) To: The Eunuchs Hysterical Society 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 ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: [TUHS] [SPAM] Re: SCCS 2019-09-13 5:54 ` Dave Horsfall @ 2019-09-13 8:00 ` Peter Jeremy 2019-09-13 15:23 ` Larry McVoy 2019-09-13 21:36 ` Dave Horsfall 0 siblings, 2 replies; 85+ messages in thread From: Peter Jeremy @ 2019-09-13 8:00 UTC (permalink / raw) To: Dave Horsfall; +Cc: The Eunuchs Hysterical Society [-- Attachment #1: Type: text/plain, Size: 1027 bytes --] On 2019-Sep-13 15:54:32 +1000, Dave Horsfall <dave@horsfall.org> 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 [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 963 bytes --] ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: [TUHS] [SPAM] Re: SCCS 2019-09-13 8:00 ` Peter Jeremy @ 2019-09-13 15:23 ` Larry McVoy 2019-09-13 21:36 ` Dave Horsfall 1 sibling, 0 replies; 85+ messages in thread From: Larry McVoy @ 2019-09-13 15:23 UTC (permalink / raw) To: Peter Jeremy; +Cc: The Eunuchs Hysterical Society On Fri, Sep 13, 2019 at 06:00:09PM +1000, Peter Jeremy wrote: > On 2019-Sep-13 15:54:32 +1000, Dave Horsfall <dave@horsfall.org> 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. ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: [TUHS] [SPAM] Re: SCCS 2019-09-13 8:00 ` Peter Jeremy 2019-09-13 15:23 ` Larry McVoy @ 2019-09-13 21:36 ` Dave Horsfall 1 sibling, 0 replies; 85+ messages in thread From: Dave Horsfall @ 2019-09-13 21:36 UTC (permalink / raw) To: The Eunuchs Hysterical Society 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 ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: [TUHS] SCCS 2019-09-12 3:43 ` [TUHS] SCCS Larry McVoy 2019-09-12 4:20 ` George Michaelson @ 2019-09-12 4:28 ` Jon Forrest 2019-09-12 4:33 ` Larry McVoy 2019-09-12 16:45 ` Eric Allman 2019-09-12 20:07 ` Nemo 2 siblings, 2 replies; 85+ messages in thread From: Jon Forrest @ 2019-09-12 4:28 UTC (permalink / raw) To: tuhs 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 ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: [TUHS] SCCS 2019-09-12 4:28 ` [TUHS] SCCS Jon Forrest @ 2019-09-12 4:33 ` Larry McVoy 2019-09-12 6:12 ` William Corcoran 2019-09-13 5:22 ` Dave Horsfall 2019-09-12 16:45 ` Eric Allman 1 sibling, 2 replies; 85+ messages in thread From: Larry McVoy @ 2019-09-12 4:33 UTC (permalink / raw) To: Jon Forrest; +Cc: tuhs 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 ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: [TUHS] SCCS 2019-09-12 4:33 ` Larry McVoy @ 2019-09-12 6:12 ` William Corcoran 2019-09-12 14:35 ` Clem Cole 2019-09-13 5:22 ` Dave Horsfall 1 sibling, 1 reply; 85+ messages in thread From: William Corcoran @ 2019-09-12 6:12 UTC (permalink / raw) To: Larry McVoy; +Cc: tuhs 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 <lm@mcvoy.com> 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 ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: [TUHS] SCCS 2019-09-12 6:12 ` William Corcoran @ 2019-09-12 14:35 ` Clem Cole 0 siblings, 0 replies; 85+ messages in thread From: Clem Cole @ 2019-09-12 14:35 UTC (permalink / raw) To: Larry McVoy, tuhs [-- Attachment #1: Type: text/plain, Size: 4592 bytes --] 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. [-- Attachment #2: Type: text/html, Size: 7363 bytes --] ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: [TUHS] SCCS 2019-09-12 4:33 ` Larry McVoy 2019-09-12 6:12 ` William Corcoran @ 2019-09-13 5:22 ` Dave Horsfall 2019-09-13 5:50 ` Bakul Shah 1 sibling, 1 reply; 85+ messages in thread From: Dave Horsfall @ 2019-09-13 5:22 UTC (permalink / raw) To: The Eunuchs Hysterical Society 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 ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: [TUHS] SCCS 2019-09-13 5:22 ` Dave Horsfall @ 2019-09-13 5:50 ` Bakul Shah 0 siblings, 0 replies; 85+ messages in thread From: Bakul Shah @ 2019-09-13 5:50 UTC (permalink / raw) To: The Eunuchs Hysterical Society On Fri, 13 Sep 2019 15:22:58 +1000 Dave Horsfall <dave@horsfall.org> 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. ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: [TUHS] SCCS 2019-09-12 4:28 ` [TUHS] SCCS Jon Forrest 2019-09-12 4:33 ` Larry McVoy @ 2019-09-12 16:45 ` Eric Allman 2019-09-12 17:29 ` Clem Cole 1 sibling, 1 reply; 85+ messages in thread From: Eric Allman @ 2019-09-12 16:45 UTC (permalink / raw) To: Jon Forrest, tuhs 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 ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: [TUHS] SCCS 2019-09-12 16:45 ` Eric Allman @ 2019-09-12 17:29 ` Clem Cole 2019-09-12 17:47 ` Warner Losh 2019-09-13 8:12 ` emanuel stiebler 0 siblings, 2 replies; 85+ messages in thread From: Clem Cole @ 2019-09-12 17:29 UTC (permalink / raw) To: Eric Allman; +Cc: TUHS main list [-- Attachment #1: Type: text/plain, Size: 441 bytes --] On Thu, Sep 12, 2019 at 1:16 PM Eric Allman <tuhs@eric.allman.name> 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 [-- Attachment #2: Type: text/html, Size: 1029 bytes --] ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: [TUHS] SCCS 2019-09-12 17:29 ` Clem Cole @ 2019-09-12 17:47 ` Warner Losh 2019-09-13 8:12 ` emanuel stiebler 1 sibling, 0 replies; 85+ messages in thread From: Warner Losh @ 2019-09-12 17:47 UTC (permalink / raw) To: Clem Cole; +Cc: TUHS main list [-- Attachment #1: Type: text/plain, Size: 920 bytes --] On Thu, Sep 12, 2019, 11:30 AM Clem Cole <clemc@ccc.com> wrote: > > > On Thu, Sep 12, 2019 at 1:16 PM Eric Allman <tuhs@eric.allman.name> 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 > [-- Attachment #2: Type: text/html, Size: 2112 bytes --] ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: [TUHS] SCCS 2019-09-12 17:29 ` Clem Cole 2019-09-12 17:47 ` Warner Losh @ 2019-09-13 8:12 ` emanuel stiebler 2019-09-13 21:11 ` Steffen Nurpmeso 1 sibling, 1 reply; 85+ messages in thread From: emanuel stiebler @ 2019-09-13 8:12 UTC (permalink / raw) To: Clem Cole, Eric Allman; +Cc: TUHS main list On 2019-09-12 19:29, Clem Cole wrote: > > > On Thu, Sep 12, 2019 at 1:16 PM Eric Allman <tuhs@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/ ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: [TUHS] SCCS 2019-09-13 8:12 ` emanuel stiebler @ 2019-09-13 21:11 ` Steffen Nurpmeso 2019-09-13 21:17 ` Larry McVoy 0 siblings, 1 reply; 85+ messages in thread From: Steffen Nurpmeso @ 2019-09-13 21:11 UTC (permalink / raw) To: emanuel stiebler; +Cc: TUHS main list emanuel stiebler wrote in <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 <tuhs@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) ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: [TUHS] SCCS 2019-09-13 21:11 ` Steffen Nurpmeso @ 2019-09-13 21:17 ` Larry McVoy 2019-09-13 21:48 ` Bakul Shah 2019-09-13 23:03 ` Steffen Nurpmeso 0 siblings, 2 replies; 85+ messages in thread From: Larry McVoy @ 2019-09-13 21:17 UTC (permalink / raw) To: emanuel stiebler, Clem Cole, Eric Allman, TUHS main list On Fri, Sep 13, 2019 at 11:11:04PM +0200, Steffen Nurpmeso wrote: > emanuel stiebler wrote in <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 <tuhs@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. I don't know why, BitKeeper does that and is open source under a liberal license (Apache v2). ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: [TUHS] SCCS 2019-09-13 21:17 ` Larry McVoy @ 2019-09-13 21:48 ` Bakul Shah 2019-09-13 23:12 ` Steffen Nurpmeso 2019-09-13 23:03 ` Steffen Nurpmeso 1 sibling, 1 reply; 85+ messages in thread From: Bakul Shah @ 2019-09-13 21:48 UTC (permalink / raw) To: TUHS main list On Fri, 13 Sep 2019 14:17:51 -0700 Larry McVoy <lm@mcvoy.com> 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. ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: [TUHS] SCCS 2019-09-13 21:48 ` Bakul Shah @ 2019-09-13 23:12 ` Steffen Nurpmeso 0 siblings, 0 replies; 85+ messages in thread From: Steffen Nurpmeso @ 2019-09-13 23:12 UTC (permalink / raw) To: Bakul Shah; +Cc: TUHS main list Bakul Shah wrote in <20190913214905.339ED1570CE9@mail.bitblocks.com>: |On Fri, 13 Sep 2019 14:17:51 -0700 Larry McVoy <lm@mcvoy.com> 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) ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: [TUHS] SCCS 2019-09-13 21:17 ` Larry McVoy 2019-09-13 21:48 ` Bakul Shah @ 2019-09-13 23:03 ` Steffen Nurpmeso 2019-09-14 1:55 ` [TUHS] [SPAM] SCCS Larry McVoy 1 sibling, 1 reply; 85+ messages in thread From: Steffen Nurpmeso @ 2019-09-13 23:03 UTC (permalink / raw) To: Larry McVoy; +Cc: Joerg.Schilling, TUHS main list Larry McVoy wrote in <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@e-bbes.c\ |> om>: |>|On 2019-09-12 19:29, Clem Cole wrote: |>|> On Thu, Sep 12, 2019 at 1:16 PM Eric Allman <tuhs@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) ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: [TUHS] [SPAM] Re: SCCS 2019-09-13 23:03 ` Steffen Nurpmeso @ 2019-09-14 1:55 ` Larry McVoy 2019-09-16 17:23 ` [TUHS] SCCS Steffen Nurpmeso 0 siblings, 1 reply; 85+ messages in thread From: Larry McVoy @ 2019-09-14 1:55 UTC (permalink / raw) To: Larry McVoy, emanuel stiebler, Clem Cole, Eric Allman, TUHS main list, Joerg.Schilling 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 ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: [TUHS] SCCS 2019-09-14 1:55 ` [TUHS] [SPAM] SCCS Larry McVoy @ 2019-09-16 17:23 ` Steffen Nurpmeso 2019-09-16 20:31 ` Larry McVoy 2019-09-18 8:48 ` Eric Allman 0 siblings, 2 replies; 85+ messages in thread From: Steffen Nurpmeso @ 2019-09-16 17:23 UTC (permalink / raw) To: Larry McVoy; +Cc: Jörg Schilling, TUHS main list 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@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) ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: [TUHS] SCCS 2019-09-16 17:23 ` [TUHS] SCCS Steffen Nurpmeso @ 2019-09-16 20:31 ` Larry McVoy 2019-09-17 17:57 ` Steffen Nurpmeso 2019-09-18 8:48 ` Eric Allman 1 sibling, 1 reply; 85+ messages in thread From: Larry McVoy @ 2019-09-16 20:31 UTC (permalink / raw) To: Larry McVoy, emanuel stiebler, Clem Cole, Eric Allman, TUHS main list, J??rg Schilling On Mon, Sep 16, 2019 at 07:23:00PM +0200, Steffen Nurpmeso wrote: > Larry McVoy wrote in <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. > > 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 ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: [TUHS] SCCS 2019-09-16 20:31 ` Larry McVoy @ 2019-09-17 17:57 ` Steffen Nurpmeso 0 siblings, 0 replies; 85+ messages in thread From: Steffen Nurpmeso @ 2019-09-17 17:57 UTC (permalink / raw) To: Larry McVoy; +Cc: Jörg Schilling, TUHS main list Larry McVoy wrote in <20190916203152.GB9704@mcvoy.com>: |On Mon, Sep 16, 2019 at 07:23:00PM +0200, Steffen Nurpmeso wrote: |> Larry McVoy wrote in <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. |> |> 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@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) ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: [TUHS] SCCS 2019-09-16 17:23 ` [TUHS] SCCS Steffen Nurpmeso 2019-09-16 20:31 ` Larry McVoy @ 2019-09-18 8:48 ` Eric Allman 2019-09-18 17:33 ` Steffen Nurpmeso 1 sibling, 1 reply; 85+ messages in thread From: Eric Allman @ 2019-09-18 8:48 UTC (permalink / raw) To: TUHS main list 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 ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: [TUHS] SCCS 2019-09-18 8:48 ` Eric Allman @ 2019-09-18 17:33 ` Steffen Nurpmeso 0 siblings, 0 replies; 85+ messages in thread From: Steffen Nurpmeso @ 2019-09-18 17:33 UTC (permalink / raw) To: Eric Allman; +Cc: TUHS main list Eric Allman wrote in <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. 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) ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: [TUHS] SCCS 2019-09-12 3:43 ` [TUHS] SCCS Larry McVoy 2019-09-12 4:20 ` George Michaelson 2019-09-12 4:28 ` [TUHS] SCCS Jon Forrest @ 2019-09-12 20:07 ` Nemo 2 siblings, 0 replies; 85+ messages in thread From: Nemo @ 2019-09-12 20:07 UTC (permalink / raw) To: Larry McVoy; +Cc: The Eunuchs Hysterical Society On 11/09/2019, Larry McVoy <lm@mcvoy.com> 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. ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: [TUHS] PWB vs Unix/TS 2019-09-10 15:16 ` Clem Cole 2019-09-11 0:28 ` Steve Johnson 2019-09-11 3:53 ` Warner Losh @ 2019-09-11 16:05 ` Paul Winalski 2019-09-11 17:14 ` ron 2019-09-14 0:44 ` [TUHS] a book (was Re: PWB vs Unix/TS) reed 3 siblings, 1 reply; 85+ messages in thread From: Paul Winalski @ 2019-09-11 16:05 UTC (permalink / raw) To: Clem Cole; +Cc: The Eunuchs Hysterical Society >On 9/10/19, Clem Cole <clemc@ccc.com> 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. ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: [TUHS] PWB vs Unix/TS 2019-09-11 16:05 ` [TUHS] PWB vs Unix/TS Paul Winalski @ 2019-09-11 17:14 ` ron 0 siblings, 0 replies; 85+ messages in thread From: ron @ 2019-09-11 17:14 UTC (permalink / raw) To: 'The Eunuchs Hysterical Society' 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. ^ permalink raw reply [flat|nested] 85+ messages in thread
* [TUHS] a book (was Re: PWB vs Unix/TS) 2019-09-10 15:16 ` Clem Cole ` (2 preceding siblings ...) 2019-09-11 16:05 ` [TUHS] PWB vs Unix/TS Paul Winalski @ 2019-09-14 0:44 ` reed 2019-09-14 2:53 ` Warner Losh ` (2 more replies) 3 siblings, 3 replies; 85+ messages in thread From: reed @ 2019-09-14 0:44 UTC (permalink / raw) To: The Eunuchs Hysterical Society 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" ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: [TUHS] a book (was Re: PWB vs Unix/TS) 2019-09-14 0:44 ` [TUHS] a book (was Re: PWB vs Unix/TS) reed @ 2019-09-14 2:53 ` Warner Losh 2019-09-15 2:18 ` Jon Steinhart 2019-09-14 22:46 ` Clem cole 2019-09-15 7:43 ` Andy Kosela 2 siblings, 1 reply; 85+ messages in thread From: Warner Losh @ 2019-09-14 2:53 UTC (permalink / raw) To: Jeremy C. Reed; +Cc: The Eunuchs Hysterical Society [-- Attachment #1: Type: text/plain, Size: 3946 bytes --] On Fri, Sep 13, 2019 at 7:31 PM <reed@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. > 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" > [-- Attachment #2: Type: text/html, Size: 5171 bytes --] ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: [TUHS] a book (was Re: PWB vs Unix/TS) 2019-09-14 2:53 ` Warner Losh @ 2019-09-15 2:18 ` Jon Steinhart 2019-09-15 2:39 ` Clem Cole 2019-09-15 3:24 ` Adam Thornton 0 siblings, 2 replies; 85+ messages in thread From: Jon Steinhart @ 2019-09-15 2:18 UTC (permalink / raw) To: The Eunuchs Hysterical Society On Fri, Sep 13, 2019 at 7:31 PM <reed@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. 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 ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: [TUHS] a book (was Re: PWB vs Unix/TS) 2019-09-15 2:18 ` Jon Steinhart @ 2019-09-15 2:39 ` Clem Cole 2019-09-15 3:24 ` Adam Thornton 1 sibling, 0 replies; 85+ messages in thread From: Clem Cole @ 2019-09-15 2:39 UTC (permalink / raw) To: Jon Steinhart; +Cc: The Eunuchs Hysterical Society [-- Attachment #1: Type: text/plain, Size: 1147 bytes --] On Sat, Sep 14, 2019 at 10:19 PM Jon Steinhart <jon@fourwinds.com> wrote: > On Fri, Sep 13, 2019 at 7:31 PM <reed@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. > > 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 [-- Attachment #2: Type: text/html, Size: 1644 bytes --] ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: [TUHS] a book (was Re: PWB vs Unix/TS) 2019-09-15 2:18 ` Jon Steinhart 2019-09-15 2:39 ` Clem Cole @ 2019-09-15 3:24 ` Adam Thornton 1 sibling, 0 replies; 85+ messages in thread From: Adam Thornton @ 2019-09-15 3:24 UTC (permalink / raw) To: The Eunuchs Hysterical Society [-- Attachment #1: Type: text/plain, Size: 1513 bytes --] 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 <jon@fourwinds.com> wrote: > On Fri, Sep 13, 2019 at 7:31 PM <reed@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. > > 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 > [-- Attachment #2: Type: text/html, Size: 2062 bytes --] ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: [TUHS] a book (was Re: PWB vs Unix/TS) 2019-09-14 0:44 ` [TUHS] a book (was Re: PWB vs Unix/TS) reed 2019-09-14 2:53 ` Warner Losh @ 2019-09-14 22:46 ` Clem cole 2019-09-15 0:58 ` Adam Thornton 2019-09-15 7:43 ` Andy Kosela 2 siblings, 1 reply; 85+ messages in thread From: Clem cole @ 2019-09-14 22:46 UTC (permalink / raw) To: reed; +Cc: The Eunuchs Hysterical Society 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@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" ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: [TUHS] a book (was Re: PWB vs Unix/TS) 2019-09-14 22:46 ` Clem cole @ 2019-09-15 0:58 ` Adam Thornton 2019-09-15 3:30 ` Eric Allman 0 siblings, 1 reply; 85+ messages in thread From: Adam Thornton @ 2019-09-15 0:58 UTC (permalink / raw) To: The Eunuchs Hysterical Society [-- Attachment #1: Type: text/plain, Size: 4323 bytes --] 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 <clemc@ccc.com> 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@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" > [-- Attachment #2: Type: text/html, Size: 5309 bytes --] ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: [TUHS] a book (was Re: PWB vs Unix/TS) 2019-09-15 0:58 ` Adam Thornton @ 2019-09-15 3:30 ` Eric Allman 2019-09-15 4:21 ` Larry McVoy 2019-09-15 20:12 ` Clem Cole 0 siblings, 2 replies; 85+ messages in thread From: Eric Allman @ 2019-09-15 3:30 UTC (permalink / raw) To: Adam Thornton, The Eunuchs Hysterical Society 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 ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: [TUHS] a book (was Re: PWB vs Unix/TS) 2019-09-15 3:30 ` Eric Allman @ 2019-09-15 4:21 ` Larry McVoy 2019-09-15 5:17 ` Jon Steinhart 2019-09-15 20:12 ` Clem Cole 1 sibling, 1 reply; 85+ messages in thread From: Larry McVoy @ 2019-09-15 4:21 UTC (permalink / raw) To: Eric Allman; +Cc: The Eunuchs Hysterical Society 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. ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: [TUHS] a book (was Re: PWB vs Unix/TS) 2019-09-15 4:21 ` Larry McVoy @ 2019-09-15 5:17 ` Jon Steinhart 2019-09-15 20:14 ` Clem Cole 0 siblings, 1 reply; 85+ messages in thread From: Jon Steinhart @ 2019-09-15 5:17 UTC (permalink / raw) To: The Eunuchs Hysterical Society 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 ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: [TUHS] a book (was Re: PWB vs Unix/TS) 2019-09-15 5:17 ` Jon Steinhart @ 2019-09-15 20:14 ` Clem Cole 2019-09-15 20:21 ` Jon Steinhart 0 siblings, 1 reply; 85+ messages in thread From: Clem Cole @ 2019-09-15 20:14 UTC (permalink / raw) To: Jon Steinhart; +Cc: The Eunuchs Hysterical Society [-- Attachment #1: Type: text/plain, Size: 386 bytes --] On Sun, Sep 15, 2019 at 1:18 AM Jon Steinhart <jon@fourwinds.com> 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... [-- Attachment #2: Type: text/html, Size: 1359 bytes --] ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: [TUHS] a book (was Re: PWB vs Unix/TS) 2019-09-15 20:14 ` Clem Cole @ 2019-09-15 20:21 ` Jon Steinhart 0 siblings, 0 replies; 85+ messages in thread From: Jon Steinhart @ 2019-09-15 20:21 UTC (permalink / raw) To: The Eunuchs Hysterical Society Clem Cole writes: > > On Sun, Sep 15, 2019 at 1:18 AM Jon Steinhart <jon@fourwinds.com> 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 ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: [TUHS] a book (was Re: PWB vs Unix/TS) 2019-09-15 3:30 ` Eric Allman 2019-09-15 4:21 ` Larry McVoy @ 2019-09-15 20:12 ` Clem Cole 2019-09-15 21:28 ` Dave Horsfall 1 sibling, 1 reply; 85+ messages in thread From: Clem Cole @ 2019-09-15 20:12 UTC (permalink / raw) To: Eric Allman; +Cc: The Eunuchs Hysterical Society [-- Attachment #1: Type: text/plain, Size: 2804 bytes --] On Sun, Sep 15, 2019 at 12:16 AM Eric Allman <tuhs@eric.allman.name> 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. [-- Attachment #2: Type: text/html, Size: 7571 bytes --] ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: [TUHS] a book (was Re: PWB vs Unix/TS) 2019-09-15 20:12 ` Clem Cole @ 2019-09-15 21:28 ` Dave Horsfall 2019-09-15 23:27 ` Clem cole 0 siblings, 1 reply; 85+ messages in thread From: Dave Horsfall @ 2019-09-15 21:28 UTC (permalink / raw) To: The Eunuchs Hysterical Society [-- Attachment #1: Type: text/plain, Size: 734 bytes --] 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 ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: [TUHS] a book (was Re: PWB vs Unix/TS) 2019-09-15 21:28 ` Dave Horsfall @ 2019-09-15 23:27 ` Clem cole 2019-09-15 23:45 ` Richard Salz 0 siblings, 1 reply; 85+ messages in thread From: Clem cole @ 2019-09-15 23:27 UTC (permalink / raw) To: Dave Horsfall; +Cc: The Eunuchs Hysterical Society 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 <dave@horsfall.org> 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 ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: [TUHS] a book (was Re: PWB vs Unix/TS) 2019-09-15 23:27 ` Clem cole @ 2019-09-15 23:45 ` Richard Salz 0 siblings, 0 replies; 85+ messages in thread From: Richard Salz @ 2019-09-15 23:45 UTC (permalink / raw) To: Clem cole; +Cc: The Eunuchs Hysterical Society [-- Attachment #1: Type: text/plain, Size: 395 bytes --] > 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 [-- Attachment #2: Type: text/html, Size: 770 bytes --] ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: [TUHS] a book (was Re: PWB vs Unix/TS) 2019-09-14 0:44 ` [TUHS] a book (was Re: PWB vs Unix/TS) reed 2019-09-14 2:53 ` Warner Losh 2019-09-14 22:46 ` Clem cole @ 2019-09-15 7:43 ` Andy Kosela 2 siblings, 0 replies; 85+ messages in thread From: Andy Kosela @ 2019-09-15 7:43 UTC (permalink / raw) To: reed; +Cc: The Eunuchs Hysterical Society On Saturday, September 14, 2019, <reed@reedmedia.net> 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 ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: [TUHS] SCCS
@ 2019-09-12 4:25 Jon Steinhart
0 siblings, 0 replies; 85+ messages in thread
From: Jon Steinhart @ 2019-09-12 4:25 UTC (permalink / raw)
To: The Eunuchs Hysterical Society
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.
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: [TUHS] SCCS @ 2019-09-13 21:37 Norman Wilson 2019-09-13 21:51 ` Larry McVoy 0 siblings, 1 reply; 85+ messages in thread From: Norman Wilson @ 2019-09-13 21:37 UTC (permalink / raw) To: tuhs 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 ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: [TUHS] SCCS 2019-09-13 21:37 Norman Wilson @ 2019-09-13 21:51 ` Larry McVoy 0 siblings, 0 replies; 85+ messages in thread From: Larry McVoy @ 2019-09-13 21:51 UTC (permalink / raw) To: Norman Wilson; +Cc: tuhs 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. ^ permalink raw reply [flat|nested] 85+ messages in thread
end of thread, other threads:[~2019-09-18 17:33 UTC | newest] Thread overview: 85+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-09-09 6:25 [TUHS] PWB vs Unix/TS Warner Losh 2019-09-09 6:36 ` arnold 2019-09-10 15:16 ` Clem Cole 2019-09-11 0:28 ` Steve Johnson 2019-09-11 3:53 ` Warner Losh 2019-09-11 15:36 ` Clem Cole 2019-09-11 16:55 ` [TUHS] IBM Unix source licenses [was " Charles H Sauer 2019-09-12 19:31 ` Kevin Bowling 2019-09-12 20:59 ` Clem Cole 2019-09-12 21:09 ` [TUHS] IBM Unix source licenses - Series/1 NUXI Ronald Natalie 2019-09-12 21:31 ` [TUHS] IBM Unix source licenses [was Re: PWB vs Unix/TS Warner Losh 2019-09-12 22:30 ` jcs 2019-09-12 23:12 ` reed 2019-09-12 23:22 ` jcs 2019-09-12 23:29 ` [TUHS] IBM Unix source licenses Warren Toomey 2019-09-13 7:06 ` arnold 2019-09-13 8:30 ` SPC 2019-09-14 18:29 ` Warner Losh 2019-09-12 21:29 ` [TUHS] IBM Unix source licenses [was Re: PWB vs Unix/TS Charles H Sauer 2019-09-11 17:49 ` [TUHS] " Richard Salz 2019-09-11 17:52 ` ron 2019-09-11 21:44 ` Clem Cole 2019-09-11 18:11 ` Larry McVoy 2019-09-11 18:18 ` Richard Salz 2019-09-11 18:54 ` Larry McVoy 2019-09-11 21:05 ` Steve Johnson 2019-09-11 21:34 ` Steve Johnson 2019-09-11 21:57 ` Clem Cole 2019-09-11 22:50 ` Arthur Krewat 2019-09-11 21:59 ` Clem Cole 2019-09-11 21:50 ` Clem Cole 2019-09-11 22:49 ` Dave Horsfall 2019-09-12 3:43 ` [TUHS] SCCS Larry McVoy 2019-09-12 4:20 ` George Michaelson 2019-09-12 4:31 ` [TUHS] [SPAM] SCCS Larry McVoy 2019-09-12 13:44 ` Tony Finch 2019-09-13 4:11 ` Larry McVoy 2019-09-13 5:54 ` Dave Horsfall 2019-09-13 8:00 ` Peter Jeremy 2019-09-13 15:23 ` Larry McVoy 2019-09-13 21:36 ` Dave Horsfall 2019-09-12 4:28 ` [TUHS] SCCS Jon Forrest 2019-09-12 4:33 ` Larry McVoy 2019-09-12 6:12 ` William Corcoran 2019-09-12 14:35 ` Clem Cole 2019-09-13 5:22 ` Dave Horsfall 2019-09-13 5:50 ` Bakul Shah 2019-09-12 16:45 ` Eric Allman 2019-09-12 17:29 ` Clem Cole 2019-09-12 17:47 ` Warner Losh 2019-09-13 8:12 ` emanuel stiebler 2019-09-13 21:11 ` Steffen Nurpmeso 2019-09-13 21:17 ` Larry McVoy 2019-09-13 21:48 ` Bakul Shah 2019-09-13 23:12 ` Steffen Nurpmeso 2019-09-13 23:03 ` Steffen Nurpmeso 2019-09-14 1:55 ` [TUHS] [SPAM] SCCS Larry McVoy 2019-09-16 17:23 ` [TUHS] SCCS Steffen Nurpmeso 2019-09-16 20:31 ` Larry McVoy 2019-09-17 17:57 ` Steffen Nurpmeso 2019-09-18 8:48 ` Eric Allman 2019-09-18 17:33 ` Steffen Nurpmeso 2019-09-12 20:07 ` Nemo 2019-09-11 16:05 ` [TUHS] PWB vs Unix/TS Paul Winalski 2019-09-11 17:14 ` ron 2019-09-14 0:44 ` [TUHS] a book (was Re: PWB vs Unix/TS) reed 2019-09-14 2:53 ` Warner Losh 2019-09-15 2:18 ` Jon Steinhart 2019-09-15 2:39 ` Clem Cole 2019-09-15 3:24 ` Adam Thornton 2019-09-14 22:46 ` Clem cole 2019-09-15 0:58 ` Adam Thornton 2019-09-15 3:30 ` Eric Allman 2019-09-15 4:21 ` Larry McVoy 2019-09-15 5:17 ` Jon Steinhart 2019-09-15 20:14 ` Clem Cole 2019-09-15 20:21 ` Jon Steinhart 2019-09-15 20:12 ` Clem Cole 2019-09-15 21:28 ` Dave Horsfall 2019-09-15 23:27 ` Clem cole 2019-09-15 23:45 ` Richard Salz 2019-09-15 7:43 ` Andy Kosela 2019-09-12 4:25 [TUHS] SCCS Jon Steinhart 2019-09-13 21:37 Norman Wilson 2019-09-13 21:51 ` Larry McVoy
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).