* Re: [TUHS] [SPAM] Re: SCCS
@ 2019-09-13 22:01 Norman Wilson
2019-09-13 22:30 ` Dave Horsfall
2019-09-16 12:11 ` Leah Neukirchen
0 siblings, 2 replies; 14+ messages in thread
From: Norman Wilson @ 2019-09-13 22:01 UTC (permalink / raw)
To: tuhs
Peter Jeremy:
> NFS ran much faster when you turned off the UDP checksums as well.
> (Though there was still the Ethernet CRC32).
Dave Horsfall:
Blerk... That just tells you that the packet came across the wire more or
less OK.
=====
UDP (and TCP) checksums are nearly useless against
the sort of corruption Larry described. Since they
are a simple addition with carry wraparound, you
can insert or remove any number of word-aligned pairs
of zero octets without the checksum changing.
I discovered this the hard way, while tracking down
a kernel bug that caused exactly that sort of corruption.
Does IPv6 require a meaningful checksum, or just the
useless old ritual one?
Norman Wilson
Toronto ON
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [TUHS] [SPAM] Re: SCCS 2019-09-13 22:01 [TUHS] [SPAM] Re: SCCS Norman Wilson @ 2019-09-13 22:30 ` Dave Horsfall 2019-09-16 10:59 ` Tony Finch 2019-09-16 12:11 ` Leah Neukirchen 1 sibling, 1 reply; 14+ messages in thread From: Dave Horsfall @ 2019-09-13 22:30 UTC (permalink / raw) To: The Eunuchs Hysterical Society On Fri, 13 Sep 2019, Norman Wilson wrote: > UDP (and TCP) checksums are nearly useless against the sort of > corruption Larry described. Since they are a simple addition with carry > wraparound, you can insert or remove any number of word-aligned pairs of > zero octets without the checksum changing. I was thinking of an intermediate router (probably one that you never knew about) corrupting the checksum-less UDP packet, recalculating the Ethernet checksum, and your kernel happily accepting it; you now have an application that fails for some unknown reason. Never seen it in practice, but I've heard of it happening. -- Dave ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [TUHS] [SPAM] Re: SCCS 2019-09-13 22:30 ` Dave Horsfall @ 2019-09-16 10:59 ` Tony Finch 0 siblings, 0 replies; 14+ messages in thread From: Tony Finch @ 2019-09-16 10:59 UTC (permalink / raw) To: Dave Horsfall; +Cc: The Eunuchs Hysterical Society Dave Horsfall <dave@horsfall.org> wrote: > > I was thinking of an intermediate router (probably one that you never knew > about) corrupting the checksum-less UDP packet, recalculating the Ethernet > checksum, and your kernel happily accepting it; you now have an application > that fails for some unknown reason. > > Never seen it in practice, but I've heard of it happening. This paper has some examples: http://conferences.sigcomm.org/sigcomm/2000/conf/paper/sigcomm2000-9-1.pdf Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/ Forth, Tyne, West Dogger: Westerly 3 to 5 veering northwesterly 4 to 6. Slight or moderate, becoming moderate or rough except in west Forth. Mainly fair. Good. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [TUHS] [SPAM] Re: SCCS 2019-09-13 22:01 [TUHS] [SPAM] Re: SCCS Norman Wilson 2019-09-13 22:30 ` Dave Horsfall @ 2019-09-16 12:11 ` Leah Neukirchen 2019-09-16 21:45 ` Dave Horsfall 1 sibling, 1 reply; 14+ messages in thread From: Leah Neukirchen @ 2019-09-16 12:11 UTC (permalink / raw) To: Norman Wilson; +Cc: tuhs Norman Wilson <norman@oclsc.org> writes: > Does IPv6 require a meaningful checksum, or just the > useless old ritual one? IPv6 has no checksum at all (for the header), and TCPv6 uses the same checksum algorithm. -- Leah Neukirchen <leah@vuxu.org> https://leahneukirchen.org/ ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [TUHS] [SPAM] Re: SCCS 2019-09-16 12:11 ` Leah Neukirchen @ 2019-09-16 21:45 ` Dave Horsfall 2019-09-16 22:21 ` George Michaelson 0 siblings, 1 reply; 14+ messages in thread From: Dave Horsfall @ 2019-09-16 21:45 UTC (permalink / raw) To: The Eunuchs Hysterical Society On Mon, 16 Sep 2019, Leah Neukirchen wrote: > IPv6 has no checksum at all (for the header), and TCPv6 uses the same > checksum algorithm. Every time I've tried to read the IPv6 spec my eyes glazed over; it was plainly designed by a committee i.e. everybody wanted their mark on it. -- Dave ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [TUHS] [SPAM] Re: SCCS 2019-09-16 21:45 ` Dave Horsfall @ 2019-09-16 22:21 ` George Michaelson 0 siblings, 0 replies; 14+ messages in thread From: George Michaelson @ 2019-09-16 22:21 UTC (permalink / raw) To: Dave Horsfall; +Cc: The Eunuchs Hysterical Society Third mistake ever was host-only fragmentation and re-assembly. The lack of pragmatism tells here, because it means intermediate systems have no choice but to drop. Second biggest mistake was keeping the order SRC, DST when if the DST is first you can latch it into a buffer and do forwarding decisions while the rest of the packet is in processing. First biggest mistake was ignoring TUBA. -G On Tue, Sep 17, 2019 at 7:46 AM Dave Horsfall <dave@horsfall.org> wrote: > > On Mon, 16 Sep 2019, Leah Neukirchen wrote: > > > IPv6 has no checksum at all (for the header), and TCPv6 uses the same > > checksum algorithm. > > Every time I've tried to read the IPv6 spec my eyes glazed over; it was > plainly designed by a committee i.e. everybody wanted their mark on it. > > -- Dave ^ permalink raw reply [flat|nested] 14+ messages in thread
* [TUHS] PWB vs Unix/TS @ 2019-09-09 6:25 Warner Losh 2019-09-10 15:16 ` Clem Cole 0 siblings, 1 reply; 14+ 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] 14+ messages in thread
* Re: [TUHS] PWB vs Unix/TS 2019-09-09 6:25 [TUHS] PWB vs Unix/TS Warner Losh @ 2019-09-10 15:16 ` Clem Cole 2019-09-11 3:53 ` Warner Losh 0 siblings, 1 reply; 14+ 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] 14+ messages in thread
* Re: [TUHS] PWB vs Unix/TS 2019-09-10 15:16 ` Clem Cole @ 2019-09-11 3:53 ` Warner Losh 2019-09-11 15:36 ` Clem Cole 0 siblings, 1 reply; 14+ 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] 14+ 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 18:11 ` Larry McVoy 0 siblings, 1 reply; 14+ 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] 14+ messages in thread
* Re: [TUHS] PWB vs Unix/TS 2019-09-11 15:36 ` Clem Cole @ 2019-09-11 18:11 ` Larry McVoy 2019-09-11 22:49 ` Dave Horsfall 0 siblings, 1 reply; 14+ 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] 14+ messages in thread
* Re: [TUHS] PWB vs Unix/TS 2019-09-11 18:11 ` Larry McVoy @ 2019-09-11 22:49 ` Dave Horsfall 2019-09-12 3:43 ` [TUHS] SCCS Larry McVoy 0 siblings, 1 reply; 14+ 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] 14+ 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 2019-09-12 4:28 ` [TUHS] SCCS Jon Forrest 0 siblings, 2 replies; 14+ 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] 14+ 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 1 sibling, 1 reply; 14+ 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] 14+ 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; 14+ 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] 14+ 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; 14+ 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] 14+ 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; 14+ 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] 14+ 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; 14+ 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] 14+ 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; 14+ 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] 14+ 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; 14+ 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] 14+ 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; 14+ 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] 14+ 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 16:45 ` Eric Allman 1 sibling, 1 reply; 14+ 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] 14+ messages in thread
* Re: [TUHS] SCCS 2019-09-12 4:28 ` [TUHS] SCCS Jon Forrest @ 2019-09-12 16:45 ` Eric Allman 2019-09-12 17:29 ` Clem Cole 0 siblings, 1 reply; 14+ 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] 14+ messages in thread
* Re: [TUHS] SCCS 2019-09-12 16:45 ` Eric Allman @ 2019-09-12 17:29 ` Clem Cole 2019-09-13 8:12 ` emanuel stiebler 0 siblings, 1 reply; 14+ 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] 14+ messages in thread
* Re: [TUHS] SCCS 2019-09-12 17:29 ` Clem Cole @ 2019-09-13 8:12 ` emanuel stiebler 2019-09-13 21:11 ` Steffen Nurpmeso 0 siblings, 1 reply; 14+ 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] 14+ 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; 14+ 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] 14+ messages in thread
* Re: [TUHS] SCCS 2019-09-13 21:11 ` Steffen Nurpmeso @ 2019-09-13 21:17 ` Larry McVoy 2019-09-13 23:03 ` Steffen Nurpmeso 0 siblings, 1 reply; 14+ 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] 14+ messages in thread
* Re: [TUHS] SCCS 2019-09-13 21:17 ` Larry McVoy @ 2019-09-13 23:03 ` Steffen Nurpmeso 2019-09-14 1:55 ` [TUHS] [SPAM] SCCS Larry McVoy 0 siblings, 1 reply; 14+ 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] 14+ messages in thread
* Re: [TUHS] [SPAM] Re: SCCS 2019-09-13 23:03 ` Steffen Nurpmeso @ 2019-09-14 1:55 ` Larry McVoy 0 siblings, 0 replies; 14+ 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] 14+ messages in thread
end of thread, other threads:[~2019-09-16 22:21 UTC | newest] Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-09-13 22:01 [TUHS] [SPAM] Re: SCCS Norman Wilson 2019-09-13 22:30 ` Dave Horsfall 2019-09-16 10:59 ` Tony Finch 2019-09-16 12:11 ` Leah Neukirchen 2019-09-16 21:45 ` Dave Horsfall 2019-09-16 22:21 ` George Michaelson -- strict thread matches above, loose matches on Subject: below -- 2019-09-09 6:25 [TUHS] PWB vs Unix/TS Warner Losh 2019-09-10 15:16 ` Clem Cole 2019-09-11 3:53 ` Warner Losh 2019-09-11 15:36 ` Clem Cole 2019-09-11 18:11 ` Larry McVoy 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 16:45 ` Eric Allman 2019-09-12 17:29 ` Clem Cole 2019-09-13 8:12 ` emanuel stiebler 2019-09-13 21:11 ` Steffen Nurpmeso 2019-09-13 21:17 ` Larry McVoy 2019-09-13 23:03 ` Steffen Nurpmeso 2019-09-14 1:55 ` [TUHS] [SPAM] SCCS 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).