Hi.
I'm hoping some of the BSD people here may know.
I've been keeping a git mirror of the PCC Revived project, but in the
past month or so it's gone dark. The website is no longer there, the
CVS repos don't answer, and an email to the mailing list went unanswered.
Does anyone know anything about it? Did it move to somewhere else?
I use pcc for testing, it's much faster than GCC and clang.
And in general, I think it's a cool thing. :-)
Thanks,
Arnold
Brian's tribute to the brilliant regex mechanism that awk borrowed
from egrep spurred memories.
For more than forty years I claimed credit for stimulating Ken to
liberate grep from ed. Then, thanks to TUHS, I learned that I had
merely caused Ken to spring from the closet a program he had already
made for his own use.
There's a related story for egrep. Al Aho made a deterministic
regular-expression recognizer as a faster replacement for the
non-deterministic recognizer in grep. He also extended the domain of
patterns to full regular expressions, including alternation; thus the
"e" in egrep.
About the same time, I built on Norm Shryer's personal calendar
utility. I wanted to generalize Norm's strict syntax for dates to
cover most any (American) representation of dates, and to warn about
tomorrow's calendar as well as today's--where "tomorrow" could extend
across a weekend or holiday.
Egrep was just the tool I needed for picking the dates out of a
free-form calendar file. I wrote a little program that built an egrep
pattern based on today's date. The following mouthful for Saturday,
August 20 covers Sunday and Monday, too. (Note that, in egrep, newline
is a synonym for |, the alternation operator.)
(^|[ (,;])(([Aa]ug[^ ]* *|(08|8)/)0*20)([^0123456789]|$)
(^|[ (,;])(([Aa]ug[^ ]* *|(08|8)/)0*21)([^0123456789]|$)
(^|[ (,;])(([Aa]ug[^ ]* *|(08|8)/)0*22)([^0123456789]|$)
It worked like a charm, except that it took a good part of a minute to
handle even a tiny calendar file. The reason: the state count of the
deterministic automaton was exponentially larger than the regular
regular expression; and egrep had to build the automaton before it
could run it. Al was mortified that an early serious use of egrep
should be such a turkey.
But Al was undaunted. He replaced the automaton construction with an
equivalent lazy algorithm that constructed a state only when the
recognizer was about to visit it. This made egrep into the brilliant
tool that Brian praised.
What I don't know is whether the calendar program stimulated the idea
of lazy implementation, or whether Al, like Ken before him with grep,
already had the idea up his sleeve.
Doug
https://www.youtube.com/watch?v=GNyQxXw_oMQ
Not quite 30 minutes long. Mostly about the history of awk but some
other stuff, including a nice plug for TUHS at the end.
Arnold
Hello everyone! I’ve been digging into text editor history, and I found:
“This provided another huge step forward in usability and allowed us to
maintain our modeless approach to screen editing, which was, we feel,
superior to the Vi approach.” from https://www.coulouris.net/cs_history/em_story/
This makes me want to know em’s history outside the usual precursor-to-vi narrative. Does anyone know much about the timeline of em from 1971 (QMC Unix installation) to 1976 (Intro to W M Joy @ UCB)? And does anyone know of developments to it after 1976-04-29? That’s the last date within text in the https://www.coulouris.net/cs_history/em_story/emsource/ files. (Also grumble grumble broken touch feature detection in that shar, which indicates last mod of 1996-02-18).
Anyone other than Coulouris used em in the last 45 years?
--
Joseph Holsten
http://josephholsten.com
mailto:joseph@josephholsten.com
tel:+1-360-927-7234
> Message: 4
> Date: Wed, 10 Aug 2022 12:29:24 +0200
> From: Holger Veit <hveit01(a)web.de>
> Subject: [TUHS] PCS Munix kernel source
>
> Hi all,
>
> I have uploaded the kernel source of 32 bit PCS MUNIX 1.2 to
> https://github.com/hveit01/pcs-munix.
Thank you for sharing this work, most impressive!
> MUNIX was an AT&T SVR3.x implementation ...
Are you sure? Could it perhaps be SVR2? (I don’t see any STREAMS stuff that one would expect for R3).
> The interesting feature of this kernel is the integration of the
> Newcastle Connection network
One of my interests is Unix (packet) networking 1975-1985 and that includes Newcastle Connection. I’ve so far not dived deep into this, but your work may be the trigger for some further investigation.
My understanding so far (from reading the paper a few years ago) is that Newcastle Connection works at the level of libc, substituting system calls like open() and exec() with library routines that scan the path, and if it is a network path invokes user mode routines that use remote procedure calls to give the illusion of a networked kernel. I’ve briefly looked at the Git repo, but I do not see that structure in the code. Could you elaborate a bit more on how Newcastle Connection operates in this kernel? Happy to communicate off-list if it goes in too much detail.
I note that the repo Readme says that the kernel only does some basic IP networking as a carrier, but I also see some files in the tree that seem to implement a form of tcp (and that seem unrelated to the early Unix tcp/ip’s that I have seen so far). Or am I reading too much into these files?
===
Re-reading the Newcastle Connection paper also brought up some citations from Bell Labs work that seems to have been lost. There is a reference to “RIDE” which appears to be a system similar to Newcastle Connection. The RIDE paper is from 1979 and it mentions that RIDE is a Datakit re-implementation of earlier an earlier system that ran on Spider. Any recollections about these things among the TUHS readership?
The other citation is for J. C. Kaufeld and D. L. Russell, "Distributed UNIX System", in Workshop on Fundamental Issues in Distributed Computing, ACM SIGOPS and SIGPLAN (15-17 Dec. 1980). It seems contemporaneous with the Luderer/Marshall/Chu work on S/F-Unix. I could not find this paper so far. Here, too, any recollections about this distributed Unix among the TUHS readership?
> And I've received the documents! This is a pastebin with the rough contents of the documentation package.
>
> https://pastebin.com/jAqqBXA4 <https://pastebin.com/jAqqBXA4>
>
> Now for some analysis:
I’m interested in the journey of SysV IPC. So far I have established that these originated in CBUnix, with a lot of thinking on how to optimize these around the time that Unix 3.0/4.0/5.0 happened. They did not appear in Unix 3.0 / SysIII, and from the Unix 4.0 documentation I gather that it was not included there either.
This would make Unix 5.0 / SysV R1 the first release with what is now known as SysV IPC. The PDP11 version of R1 has the CBUnix version of shared memory, as the VAX version did not make sense in the limited address space of the PDP11.
From the pastebin summary, it would seem that IPC is not in this documentation either? That would be surprising, and reopens the possibility that IPC was part of Unix 4.0
Paul
> I've always believed that pic was so well designed
> because it took a day to get the print out (back then),
I'm afraid this belief is urban legend. Credit for pic is due 100% to
Kernighan, not to the contemporary pace of computing practice.
Even in the 1950s, we had one-hour turnaround at Bell Labs. And the
leap from batch processing had happened well before pic. Turnaround on
modest Unix source files and tests has changed little in the past
fifty years.
Doug
Thread fork as we're drifting from documentation research specifically.
One matter that keeps coming to mind for me is the formal history of the runlevel-based init system. It isn't in Research obviously, nor was it in PWB. The first time it shows up in the wild is System III, but this version is slightly different than what was in CB-UNIX at the time, which is what eventually wound up in System V.
The pressing question is whether the version in System III represents an earlier borrowing from CB or if perhaps the runlevel init started in USG, got bumped over to CB and improved, then that improved version came back to supported UNIX in 5.0.
As for the notable differences:
SysIII init allows for runlevels 1-9. It will call /etc/rc with the current state, the prior state, and the number of times the current state has been entered. If the script is called for instance due to a powerfailure, then the current state is passed suffixed with an 'x'. The inittab entries are in a different format:
state:id:flags:process
Where state is the runlevel, id is a two-character identifier, flags can be either 'c' (like respawn) or 'o' (like off I think). No flag then indicates to run once. Flags 't' or 'k' will terminate or kill a process before it is started again if a given runlevel is entered and it is already running.
This of course is in contrast to SysV init which instead offers runlevels 0-6 as well as a, b, and c. Init itself can be called with runlevels S|s or Q|q additionally and these act as calls to enter single user mode or rerun the current init state if I'm understanding correctly. Neither S nor Q options appear to be valid for the inittab runlevel. Init tab entries here are:
id:rstate:action:process
Where id and rstate are essentially just the same fields from SysIII swapped. Action replaces the flags field with the more well known respawn, wait, once, initdefault, etc. behaviors.
All in all, different enough that inittabs between the two wouldn't be compatible. SysV also includes the telinit command which appears to be able to handle those a, b, and c runlevels.
Anywho, that's my understanding of the init changes, with the pertinent question remaining whether the SysIII-style init ultimately started from the same place as SysV, or if the general design idea was there between USG and CB, and they got to a similar answer from different directions. Colon-delimited /etc files aren't uncommon, so while unlikely, it could be entirely possible the two inittab formats arose relatively independently, but the truth remains obscure in my mind at least. I don't really blame Research for not picking up this init system, it seems like there were a few parallel streams of development around the turn of the 80s, and the easier answer was probably to just stay the course. I seem to recall reading in a thread somewhere Rob Pike discussing the resistance in the Research group regarding sucking up each and every little feature USG tried to promulgate as standard, and this init system got specific mention.
- Matt G.
And I've received the documents! This is a pastebin with the rough contents of the documentation package.
https://pastebin.com/jAqqBXA4
Now for some analysis:
The User's Manual is branded System V but also displays a Western Electric Bell logo. I've seen Release 5.0 manuals displaying the Bell logo and System V manuals without, but never a System V with. That implies the publication of the manual had to change a few times, one to switch from internal Release 5.0 to commercial System V and another time to remove the Bell logo due to divestiture. I would have to wonder if similar transition can be seen with different revisions of these documents?
The Release Description manual has a list of System V relevant documents and they all appear to be accounted for here, so this should represent the wealth of documentation available to a user of System V Gold in 1983.
Most documents are traceable to documents in the Unix 4.0 collection. I've suffixed various documents here with the coordinate to the same in the 4.0 collection. Changes of note:
- The System V documentation includes instructions for 3B20S machines as well as the instructions for DEC equipment. PDP-11 and VAX guidance have been combined into a single document.
- The System V documentation adds documents concerning an "Auto Call" feature. Didn't see this anywhere in 4.0, so should be new circa System V.
- This documentation refers to the last version as System III rather than making any mention of 4.0. Given that the specific documents mentioning this are System V-branded, and there are comparable documents that are Release 5.0 branded, this implies there may be a document floating around out there somewhere equivalent to the Release Description manual but that actually covers the transition from 4.0 to 5.0.
- The documentation package drops the updated CACM paper, likely because it's available all sorts of other places.
- The summary and documentation roadmap documents appear to have been synthesized and combined into the Release Description.
- Snyder and Mashey's shell tutorial was either dropped or combined with Bourne's shell introduction
- No evidence of an MM foldout like was distributed with 4.0 (and before, there are sources around implying these foldouts started with the PWB group, may have been printed as early as 1977)
- Either the original EQN paper is dropped or relevant bits mashed together with the user's guide
- EFL documentation seems to be dropped, or is merged into one of the other Fortran documents somewhere down in there. The processor is still in the man pages though.
- ADB documentation seems to be dropped, likewise still in the manuals, listed as DEC only. Since System V seems to treat DEC as PDP-11+VAX, does this imply there was a VAX ADB? My understanding is SDB started on 32V and was *the* debugger for VAX.
- Unix Virtual Protocol papers are dropped, they were marked as 3.0 only in the 4.0 manuals anyhow, so probably not relevant.
- The Standalone I/O Library and SASH (Shell) paper is dropped
- None of the internals nor security papers seem to have made it, so no Unix Implemention, I/O Implementation, PDP and Portable C Compiler Tours, Assembler Manual, PDP-11/23 and 11/34, or Password Security papers.
These will likely be a slower burn than the 4.0 documents since I purchased them myself and am not in a hurry to get them shipped back to someone. That said, if there's anything in the above pastebin that particularly piques any interest, I can try to move those to the top of the stack and get scans done sooner rather than later. I'll also be doing some analysis between these and the 4.0 docs to try and better determine authorship of various documents, my hope is to have a pretty clear picture of whos work went into each manual by the time I'm done with it all.
- Matt G.
> From: Rob Pike
> I still marvel at the productivity and precision of his generatio
We noticed the same thing happening in the IETF, as the number of people
working on networking went up. The explanation is really quite simple, once
you think about it a bit.
If you have a very small group, it is quite possible to have a very high
level. (Not if it's selected randomly, of course; there has to be some
sorting function.) However, as the group gets much larger, it is
_necessarily_ much more 'average' in the skill/etc level of its members.
This rule applies to any group - which includes the members of TUHS,
of course.
Noel
