I was thinking about this some more.
IIRC: Peter and I sketched out the protocol for the sockets version on a
whiteboard in our office one night after a beer and pizza run. Rick
Spicklemeir, Tom Quarles, and Jim Kleckner also participated in those bull
sessions. I started writing the program soon after that and had it working
to a point in a couple of hours. I don't remember the issues, but a couple
of them were when I left for the USENIX conference later that week. When I
got back Peter had finished it and put it into RCS. The key is that the
coding was primarily Peter and myself, but Rick, TQ, and Jim all had
contributed in some manner, too,
Although the famous bug of using a vax integer, you can squarely blame me —
and as I said, having worked on networking for several years before my time
at UCB, I should have known better. But did not even think about it. I
failed Henry's ten programming commandments and concluded that the world
was a Vax. Mei culpa.
ᐧ
On Fri, Dec 13, 2024 at 10:03 AM Mark Seiden <mseiden(a)gmail.com> wrote:
> (I know there is a special place in hell for those who explain a joke,
> but, you asked…)
>
> it’s just an allusion to the Black Flag Roach Motel product (still being
> produced)
> which has a trademark on the phrase “Roaches Check in… But they Don’t
> Check Out”.
>
> Yeah, I knew that much. My question to Ken was about what this was saying
about SCCS.
Marc
This is verging on COFF material, and I won't mind if someone
moves the discussion thither:
Clem Cole:
As a satisfied user of SCCS (and later Bitkeeper), it's still my preferred
choice.
====
I have to admit SCCS is one of the many pieces of software
I tried for a week or two > 40 years ago and abandoned because
I couldn't stand it. I don't think I ever tried RCS, because
I could see it didn't what I saw as the underlying problems.
CVS likewise. Subversion was the earliest version-control
system that felt usable to me.
What bugged me so much? The earlier systems were focussed
entirely (or for CVS, almost entirely) on individual files.
There was no way to link changes that affected more than one
file:
-- SCCS and RCS don't (so far as I can tell) understand any
relation between files at all. When I'm working on a real
project of any size, there is almost always more than one
file, and there are often changes that affect multiple files
at once: if an interface changes, the changes to definitions
and uses really all should be a single commit, logged in one
go and reversible as a single coordinated operation; if I
refactor code, moving it between files and perhaps adding
files or removing them, likewise. It is possible to check
in a bunch of files at once and reuse the log message, but
I couldn't find a way to make it a true coordinated single
commit; and neither SCCS nor RCS has a way I could find to
record, as a structured commit, that files are added or
removed from a directory or directory tree.
-- CVS can track adds and deletes and can bundle changes
into a single commit on the command line, but the changes
are still stored individually per file.
-- None of the systems even tries to track file renames,
something I also do occasionally as programs and especially
documentation evolves.
It wasn't until I discovered Subversion that I started using
version control regularly in my own work.
Ironically, a few years after I began using svn for myself,
I ended up working in places that had great compost heaps
of RCS and CVS. This would have made sense in the 1990s,
but it was in the 2010s, and continues in the 2020s.
I now use hg for my personal work, and have been attempting
to drag my workplace into using git if only so new hires
don't have to learn clumsy outdated stuff just to do their
jobs. I expect to retire (not for this reason) before I
really succeed, though.
Norman Wilson
Toronto ON
----- Forwarded message from Rick Smith <rick(a)rbsmith.com> -----
Date: Fri, 13 Dec 2024 18:22:29 -0500
From: Rick Smith <rick(a)rbsmith.com>
To: Larry McVoy <lm(a)mcvoy.com>
Subject: Re: [TUHS] SCCS roach motel
X-Mailer: Apple Mail (2.3826.300.87.4.3)
Hi Larry,
I likely can???t post to TUHS without joining, though I can read it fine.
Anyway, feel free to edit and post:
Marc,
I remember in 1992 driving to the UCSD library to get that issue of TSE and
make make copy of the article. I still have it and wrote about it on HN [1].
The link I posted at the end there is dead (wayback [2]). It is a post
by J??rg Schilling about your post here on TUHS about SCCS.
Yes, we could get lost in the weeds about choice of control-A, lack of
merge bookkeeping and the corner cases with -i and -x when applying strict
order to a partial order when computing the graph-to-set but in the big
picture, the SCCS system is a huge contribution. Congratulations on
writing one of the most influential papers in TSE's first decade!
Certainly is that for me.
Aside, Larry wrote:
> ... He [Rick] did point out that my weave implementation was the only
> one written such that I could have N serial sets in my hand, and do one
> pass through the weave and get N different checked out files. I don't
> think we ever used that but if we did it would be in smerge.c.
The original makepatch() uses it in sccs_getdiffs() which walks the weave
calling changestate() once to track weave structure and printstate() twice,
generating a diff in one pass.
While this is a hats off to Marc, there is also a hats off to Larry
for extending the SCCS work with TeamWare and Bitkeeper. I studied SCCS
(and other engines).
Larry built systems.
[1] https://news.ycombinator.com/item?id=26225001
[2] https://web.archive.org/web/20190403213137/http://sccs.sourceforge.net/sccs…
----- End forwarded message -----
--
---
Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat
I just came across a 1995 post from Gordon Letwin, early Microsoft employee
and lead architect of OS/2, about the history of OS/2. There are a few
paragraphs in it about Microsoft and UNIX. Here's Letwin's post:
https://gunkies.org/wiki/Gordon_Letwin_OS/2_usenet_post
And the UNIX-related paragraphs:
*It's extremely hard to do development work on an operating system when
someone else controls the standard. "Control" in this case is a matter of
public perception. For example, Microsoft was once very big in the Unix
world. In fact, we considered it our candidate for the future desktop
operating system, when machines got powerful enough to run something good.
We were the worlds biggest seller of Unix systems. DOS was, when we first
wrote it, a one-time throw-away product intended to keep IBM happy so that
they'd buy our languages.The UNIX contracts were all done when Bell Labs
was regulated and couldn't sell Unix into the commerical marketplace. So
although they wrote it and were paid royalties, they couldn't develop it in
competition to us. But after a few years that changed. Bell was
degregulated and now they were selling Unix directly, in competition to
us! They might sell it for cheaper than we had to pay them in royalties!
But that wasn't the real killer, the real killer was the Bell now
controlled the standard. If we wrote an API extension that did X, and Bell
wrote an incompatible one that did Y, which one would people write for?
The ISVs know that AT&T was a very big company and that they'd written the
original, so they'd believe that AT&T controlled the standard, not MS, and
that belief would then define reality. So we'd always just be waiting for
what AT&T announced and then frantically trying to duplicate it.Bill Gates
knew, right away, that there was no strong future in Unix for us any more.
Fortunately at that time, DOS was taking off and we were learning, along
with everyone else, about the power of standards. So the primary OS team -
the Unix guys - joined with the secondary OS team - the DOS guys - and the
earliest versions of OS/2 were born. (This was before IBM came on board,
so it wasn't called OS/2!)*
Marc Rochkind
All, I received this detailed e-mail from Yufeng Gao who has done a great
job at analysing some of the DECtapes that Dennis made available to the
Unix Archive. I'm sure many of you would be interested and, possibly, could
provide some feedback on his work. A tarball of his efforts are here:
https://mega.nz/file/1cJFTJxT#BgszYuFc_ebSMaQXAIG5b2NtaGInPWMoaxExPM5Lr9Y
Cheers, Warren
P.S. I have a follow-up e-mail coming ...
----- Forwarded message from Yufeng Gao -----
Subject: UNIX DECtapes from Ritchie
Hi Warren,
I am writing you this email after seeing the DECtapes from Dennis
Ritchie that you put up last year. I found them while playing around
with the early C compilers on Ritchie's site. After some research into
the tapes, I have written a parser to parse them and convert them into
tarballs suitable for preservation. Most importantly, the 'dmr' tape
and 's1' tape are currently not decoded properly.
The biggest issue with the current decoding of the 's1' tape is, well,
there is none. After quickly glancing over the tape, I have concluded
that it is in fact not one of the middle tapes of an rkd(1) backup, but
a copy of UNIX INIT DECtape from a version of UNIX between V1 and V2. I
have extracted its contents:
Mode UID GID Size Date Name
---------- --- --- ----- ------------------- ------------
-rw-rw-rw- 0 0 512 1970-01-01 00:00:00 [vcboot]
-rw-rw-rw- 0 0 2048 1970-01-01 00:00:00 [bos]
-rw-rw-rw- 0 0 12288 1970-01-01 00:00:00 [wunix]
-rw-rw-rw- 0 0 12288 1970-01-01 00:00:00 [cunix]
-rw-rw-rw- 0 0 3072 1970-01-01 00:00:00 [unassigned]
-rwxr-xr-x 1 0 424 1970-01-01 00:00:00 /etc/init
-rwxrwxrwx 3 0 446 1970-01-01 00:00:00 /etc/getty
-rwxr-xr-x 3 0 82 1970-01-01 00:00:00 /bin/chmod
-rwsr-xr-x 0 0 794 1970-01-01 00:00:00 /bin/date
-rwsr-xr-x 0 0 1290 1970-01-01 00:00:00 /bin/login
-rwsr-xr-x 0 0 232 1970-01-01 00:00:00 /bin/mkdir
-rwxr-xr-x 1 0 954 1970-01-01 00:00:00 /bin/sh
-rwsr-xr-x 0 0 3678 1970-01-01 00:00:00 /bin/tap
-rwxr-xr-x 3 0 2010 1970-01-01 00:00:00 /bin/ls
578 blocks, 98 (16.96%) used, 480 (83.04%) free.
B = boot; D = directroy;
. = free; X = file data;
O = bos; W = wunix;
C = cunix; S = rf slack;
U = unassigned program;
|0123456789ABCDEF
--+----------------
00|BOOOOWWWWWWWWWWW
01|WWWWWWWWWWWWWCCC
02|CCCCCCCCCCCCCCCC
03|CCCCCUUUUUUSSSSS
04|SDXDXDXDXXDXXXDX
05|DXXDXXXXXXXXDXXX
06|XD..............
07|................
<...>
What is significant here is it contains the vcboot and bos programs
mentioned in bproc(7), as well as a Warm and a Cold UNIX kernel. This
version of UNIX appears to be between V1 and V2, which I believe is the
earliest to exist in binary form. The reason why I say it's between V1
and V2 is its bos program accepts the following console switches
compared to V1 and V2:
| UNIX V1 | s1 | UNIX V2
----------------------+----------+-------+---------
Warm boot | [1]73700 | ??? | ???
Cold boot | 1 | 1 | 1
Unassigned 3K prog | 2 | 2 |
Dump core & halt | 10 | 10 | 10
Boot from RK | | 20 | 20
Dump core & warm boot | | 40 | 40
Boot from paper tape | 0 | 0 | 0
Load DEC loaders | 57500 | 57500 | 77500
----------------------+----------+-------+---------
UNIX load address | 400 | 400 | 600
----------------------+----------+-------+---------
The boot-from-unassigned-3K-program option was probably in the process
of being depreciated, as the 3K of space is also loaded as a part of
the Cold UNIX despite it not being used by the Cold UNIX kernel. The
list of files on the 's1' tape also appear to be between V1 and V2:
| V1 | s1 | V2
-----------+-----+-----+-----
/etc/init | Yes | Yes | Yes
/etc/getty | No | Yes | Y/N
/bin/chmod | Yes | Yes | Yes
/bin/chown | Yes | No | No
/bin/date | No | Yes | Yes
/bin/login | No | Yes | Yes
/bin/cp | Yes | No | No
/bin/ln | Yes | No | No
/bin/ls | Yes | Yes | Yes
/bin/mkdir | Yes | Yes | Yes
/bin/mv | Yes | No | No
/bin/rm | Yes | No | No
/bin/rmdir | Yes | No | No
/etc/mount | No | No | Yes
/bin/sh | Yes | Yes | Yes
/bin/stat | Yes | No | No
/bin/tap | Yes | Yes | Yes
-----------+-----+-----+-----
Given that the files on this tape are identical to the same files on
the 's2' tape and that the files on the 's2' tape are also sort of
between V1 and V2, and that this tape is named 's1' while the other is
named 's2', they are probably from the same version of UNIX. I have
tried booting the 's1' tape using SIMH, but unfortunately it did not
work and I have not yet attempted to debug it.
Next I'm going to talk about the 'dmr' tape. It’s interesting, most of
it was written by tap(1) running under UNIX V1-V2, but files in the
./paper directory were written by tap(1) running under UNIX V4. When
decoded using the tap(1) program itself, the timestamps and access
modes of those files are garbled. My program corrected the timestamps
and access modes in the converted tar(1) archive. The same goes for the
'nsys' tape.
The tar(1) conversion of 's2'
(/Archive/Distributions/Research/1972_stuff/s2-bits.tar.gz) in the TUHS
archives is missing some files in the /etc directory - compare it with
mine and Ritchie's (Ritchie's has wrong timestamps and access modes,
however). Speaking of timestamps and the 's2' tape, the timestamps
outputted by tap(1) are inaccurate because 1972 is a leap year and the
ctime(3) function hard coded 28 for the number of days in February.
I have attached an archive of my tar(1) conversion of each tape, as
well as tarballs containing all the slack space data and unused blocks
which I dumped for data recovery and forensic analysis purposes. There
are some interesting bits and pieces in the unused blocks of various
tapes, but I have not had time to look into them in detail. Just a very
quick summary:
* The 'config' tape has leftover of a dictionary file.
* The 'dmr' tape has some assembler manual ?roff leftover.
* The 'dmr2' tape has some paper ?roff leftover.
* The 'e-pi' tape has a lot of interesting binary stuff, including
bits and pieces of a B compiler from what I can tell.
* The 'ken' tape has some C source fragments and Thompson’s mail
templates and some UNIX manual ?roff leftover.
* The 'ken-du' tape has some paper ?roff leftover.
* The 'ken-sky' tape has some binary leftover.
* The 'nsys' tape has some source code leftover of what seems to be
the kernel.
* The 's1' tape has some source code leftover of what seems to be
userland programs.
* The 'scratch' tape has some binary and source listing and ?roff
leftover.
* The 'unix' tape has some binary leftover.
I hope that these newly extracted stuff could be put up in the TUHS
archives :). If the attachment in this email somehow doesn't come
through, I have also uploaded the archive [1]here. I have a disassembly
of vcboot and bos from 's1', they may help with the UNIX V1
reconstruction project - let me know if you need them. If you can get
the 's1' kernel to boot, I'd like to also receive an update.
Sincerely,
Yufeng Gao
----- End forwarded message -----
> From: Yufeng Gao
> This version of UNIX appears to be between V1 and V2
It's too bad it's not 'between V2 and V3', since the UNIX kernels V2 and V3
are missing. (V4 is the earlist one that we have, after the V2 and onward gap.)
So, depending on how far from V1 (which we have) it is, it _might_ be worth
dis-assenbling. It would be particularly worth having it if it suppports the
KS11, since almost no documentation of that has survived; code that uses it
would allow re-creation of a programming manual for it.
> From: Lars Brinkhoff
> Is the kernel for a PDP-11/20 or /45?
I don't think it can be the /45; as of V2, the /45 was apparently expected in
the near future, and this was before the V2.
Noel
I was looking at the question of “impact of Unix" and thought that:
initiating (Portable) Open Source Software including the BSD TCP/IP & Berkeley sockets libraries,
the Unix -> Minix -> Linux -> Android sequence
and BSD -> NeXtstep -> OS/X -> iOS sequence,
plus running the Top 500 supercomputers and most of the Top 500 websites,
including the infrastructure for trillion dollars companies, Facebook, Amazon (Netflix uses them), and Google
plus so many embedded Linux / NetBSD based appliances
even going into space - on small experiments or driving SpaceX’s Falcon 9 & presumably Starship,
would be a slam-dunk for “really high impact”
- dominating everywhere important, except Windows desktops.
Unix wasn’t just a ’research project’, it was the result of years of work by a team of very capable, professional programmers,
who weren’t looking for kudos or recognition, nor trying to add every conceivable ‘feature’ possible, but the inverse:
how _small_ could it be and still be enough.
When it left the Labs, Unix wasn’t just “Performant”, it came with a very useful set of tools for creating other tools (‘developing’)
and while the kernel wasn’t perfect (some ‘panic’s), it was of “Production Quality”.
For v6, I believe there were patches for 50-100 bugs circulating, perhaps the first demonstration of “no bug is intractable with ‘many eyeballs’”.
All that in under 5 years of ‘development’, with the “initial release” stable & performant enough for cash-strapped Universities
to gamble their reputations & budgets on running it.
Imagine the grief academics would’ve got if their basic teaching systems failed continuously!
This adoption path pushed Unix through another barrier:
’Security’ - with a lot of bright, bored & curious students banging on it as hard as they could for bragging rights.
How long, in releases or years, did it take for other O/S’s to hit the “very stable” benchmark?
I don’t know enough of Linux to answer that definitively, the *BSD’s grew there through usage and contribution,
while Microsoft NT derivates widely suffered “Blue Screen of Death” for years.
Even now, MS-Windows has serious Security / compromise issues, like the highly visible, global “Crowdstrike” event.
Not a break-in or takeover, but an own-goal from Security perimeter control.
==========
I now think Unix has had a much larger, direct and important impact
- the C language and associated tools & libraries
that begat modern toolchains and endless portability across platforms.
In 1991, Bill Plauger had a year sabbatical at UNSW in Sydney,
and happened to say :
“C is wallpaper - people expect it everywhere”.
C gained formal recognition with the POSIX standard, satisfying conservative users / enterprises that it wasn’t the work of a bunch of Hippies or ill-disciplined Hackers.
Even Microsoft wrote 32-bit Windows NT in C, I presume starting by writing it’s own compiler and toolchain to start.
Borland, Watcom and many others - including Microsoft - offered (Visual) C compile & build environments for Windows,
directly responsible for creating the ’shrink-wrap’ third party software market that drove sales of Windows and x86 machines.
Nobody had seen a market for a billion systems before, nor sold 300M+ CPU’s in a single year.
People don’t buy Silicon Chips or nice Boxes, they buy Applications that solve their problems:
Software drives Sales of Hardware
- something that IBM deeply understood first with first the 1401 line, then 360-series.
The other ’small’ achievement of C and Unix was creating the market for RISC chips.
MIPS in the mid-1980’s was only able to design and build the first commercial RISC chip
because it knew it could port Unix to it and find an immediate market
- not at zero-cost, but a tiny fraction of what every other Vendor had done before
reinventing the wheel from scratch to provide incompatible O/S & tools for their hardware.
Unix on MIPS not only came with a host of proven software, that a large pool of people knew how to use,
but it arrived as “Production Quality” - the porting team had to test their parts - compiler, linker, libraries - hard, but could trust the existing high-quality codebase.
In "A New Golden Age for Computer Architecture”, 2019 by Hennessy & Patterson,
make an aside:
In today's post-PC era, x86 shipments have fallen almost 10% per year since the peak in 2011,
while chips with RISC processors have skyrocketed to 20 billion.
Today, 99% of 32-bit and 64-bit processors are RISC.
i suggest this goes back to PCC followed by the MIPS R2000 - made possible by Dennis’ C language.
The 1977 invention of ‘pcc’ and rewriting of Unix for cross-machine portability was the first time I’m aware of this being done.
( Miller @ UoW did a one-off hack, not to devalue his work, he ported, didn’t invent a multi-target portable compiler )
One of the effects of “portable C” was creating whole new industries for third party software developers
or enabling niche products, like CISCO routers and the many embedded devices.
C and Unix came with the tools to create new languages and new tools.
AWK, sed (!) and shells are obvious examples, with Perl, Python & PHP very big in Internet of 2000.
C was a new class of language - a tool to create tools.
It creates a perfect mechanism to bootstrap any new language, tool or product,
allowing to be refined & used enough to become reliable before being made self-hosting.
Very widely used languages such as Python are written in C.
ORACLE achieved its market dominance by providing ‘portability’ - exactly the same on every platform.
Underpinned by portable C.
The original 1127 team went on to create other systems and languages,
not the least being a new Software Engineering tool, “Go” / golang,
addressing a whole slew of deficiencies in the C/C++ approach and
We’d have no Internet today without Apache written in C and being ported to every environment.
Also, there’s a connection between C and ‘modern’ Software Engineering
- distributed Repositories, automated builds & regression tests, and the many toolchains and tools used.
They tended to be built in C to address problems (Open Source) developers were finding with existing toolchains.
‘make’ arose at Bell Labs to automate builds, along with PWB and Writers Workbench.
There’s two questions / observations about 50 years of C in broad use:
- Just how much C is out there and used ‘in production’?
- C is ‘obviously’ a product of the 1970’s, not reflecting needs of modern hardware, networks, storage and systems,
but _what_ can replace it?
There is simply too much critical code written in C to convert it to another ‘better, modern’ language.
Any new language that is a simple 1:1 rewriting of C cannot address any of the deficiencies,
while any incompatible language requires redesign and reimplementation of everything - an unachievable goal.
The Linux Kernel’s “rust” project shows the extent of the problem
- even with the best team of the best developers, its a mammoth undertaking, with uncertain payoffs, unquantifiable effort & deadlines.
My thesis is that portable, standard C:
- not only co-evolved with other tools & needs to create the Modern Software Engineering environment, the basis for multiple Trillion dollar enterprises (FAANG)
but
- drove the biggest, most profitable software market ever seen (Wintel)
- which drove sales volume of x86 chips (& DRAM, motherboards, LAN, GPU, monitors, peripherals…) over 2-3 decades,
- which drove Silicon Valley, paying for new generations of Fabs and lowering chip prices further & further
- and eventually created the Fabless RISC CPU company,
which in the Post-PC era absolutely dominates chip sales.
No Software, no Silicon…
Gordon Moore, in an early comment on his 1968 startup with Robert Noyce, said:
“we are the real revolutionaries" (vs Hippies & 1967 Summer of Love).
I think Ken & Dennis [ and 1127/ Bell Labs folk ] can say the same.
==========
I’ve written some notes, with links to Programming Languages, especially Jean Sammet’s Histories,
and would like some critiques, suggestions & corrections if people have time and interest.
Unix and C are intimately related - neither was possible or useful without the other.
i think there’s an interesting article in there, but I’m not sure I have what it takes to write it, not in a finite time :)
Very happy to help anyone who does!
Did-C-lang-create-modern-software-industry.txt
<https://drive.google.com/file/d/1k936sgqHc-vHBvfCdLoSxFhdT9NaijU2/view?usp=…>
steve jenkin
04 - dec - 2024
==========
--
Steve Jenkin, IT Systems and Design
0412 786 915 (+61 412 786 915)
PO Box 38, Kippax ACT 2615, AUSTRALIA
mailto:sjenkin@canb.auug.org.au http://members.tip.net.au/~sjenkin
Hello all,
The recent discussion about Xenix has me curious: does any Xenix
distribution for the PDP-11 survive? I've never seen one and it would be a
fascinating historical artifact. That being said, I am not soliciting
copyrighted software; I would be more than happy with a simple answer of,
"yes, one has been archived."
-Henry
