Good evening, while I'm still waiting on the full uploads to progress (it's like there's a rule any >100MB upload to archive.org for me has to fail like 5 times before it'll finally go...) I decided to scrape out the UNIX RTR manual from a recent trove of 5ESS materials I received and tossed it up in a separate upload:
https://archive.org/details/5ess-switch-unix-rtr-operating-system-reference…
This time around I've got Issue 10 from December 2001. The last issue of this particular manual I found on another 5ESS disc is Issue 7 from 1998 which I shared previously (https://ia601200.us.archive.org/view_archive.php?archive=%2F12%2Fitems%2F5e…)
The manual is in "DynaText" format on the CD in question, unlike Issue 7 which was already a PDF on its respective CD. I used print-to-PDF to generate the above linked copy. Given that the CD itself is from 2007, this may point to UNIX RTR having no significant user-visible changes from 2001 to 2007 that would've necessitated manual revisions.
In any case, I intend to upload bin/cue images of all 7 of the CDs I've received which span from 1999 to 2007, and mostly concern the 5ESS-2000 switch from the administrative and maintenance points of view. Once I get archive.org to choke these files down I also intend to go back around to the discs I've already archived and reupload them as proper bin/cue rips. I was in a hurry the last time around and simply zipped the contents from the discs, but aside from just being good archive practice, I think bin/cue is necessary for the other discs as they seem to have control information in the disc header that is required by the interactive documentation viewers therein.
All that to say, the first pass will result in bin/cues which aren't easily readable through archive.org's interface, but I intend to also swing back around on these new discs and provide zips of the contents as well to ensure the archives are both correct (bin/cue) and easily navigable (zip).
As always, if you have any such documentation or leads on where any may be awaiting archival, I'm happy to take on the work!
- Matt G.
Doug McIlroy kindly sent me contact information for John Chambers,
co-author of the cited book about the S system. I have just heard
back from John, who offered a link to his summary paper from the
2020 HOPL conference proceedings
S, R, and data science
https://doi.org/10.1145/3386334
and reported that S was licensed to AT&T Unix customers only in binary
form, and that the original source code may no longer exist.
That is a definitive answer, even if not the one that I was hoping to
find.
-------------------------------------------------------------------------------
- Nelson H. F. Beebe Tel: +1 801 581 5254 -
- University of Utah -
- Department of Mathematics, 110 LCB Internet e-mail: beebe(a)math.utah.edu -
- 155 S 1400 E RM 233 beebe(a)acm.org beebe(a)computer.org -
- Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------
Eloquently put. Amen!
doug
> Unix brought automation to the forefront of possibilities. Using Unix,
> anyone could do it - even that kid in Jurassic Park. Today, everything
> is GUI and nothing can be automated easily or, most of the time,
> not at all.
> Unix is an ever shrinking oasis in a desert of non-automation and
complexity.
> It is the loss of automation possibilities that frustrates me the most
Hi folks,
Reiser and London's paper documenting their preparation of UNIX/32V, a
port of Seventh Edition Unix to the VAX-11/780, is an important
milestone in Unix development--as much I think for its frank critique of
C as "portable assembly" as for the status of the system documented: the
last common ancestor of the BSD and System V branches of development.
Because the only version I've ever seen of this paper is a scan of,
possibly, a photocopy several generations removed from the original, I
thought I'd throw an OCR tool at it and see about reconstructing it, not
just for posterity but to put the groff implementation of mm to the
test. So even if someone has a beautiful scan of this document
elsewhere, this exercise remains worthwhile to me for what it has
shown me about Documenter's Workbench mm and groff's mostly compatible
reimplementation thereof.
Please find attached my first draft of the reconstruction as an mm
document as well as a PDF rendered by bleeding edge groff.
I did not attempt to fix _any_ typos, solecisms, or non-idiomatic *roff
usage (like the employment of hyphens as arithmetic signs or operators)
in this document. I may have introduced errors, however, due to human
fallibility or incorrect inferences about what lay beneath scanning
artifacts. Hence its draft status. I welcome review.
Assuming this reconstruction survives peer scrutiny, I aim to put it up
on GitHub as I did Kernighan & Cherry's "Typesetting Mathematics"
paper.[1]
For the casual reader, I extract my documentary annotations below.
For groff list subscribers, I will add, because people are accustomed to
me venturing radical suggestions for reforms of macro packages, I
suggest that we can get rid of groff mm's "MOVE" and "PGFORM"
extensions. They're buggy (as the man page has long conceded), and I
don't think anyone ever mastered them, not even their author. I rewrote
"0.MT", essential to rendering of this document, without requiring them
at all. I _tried_ to use them, but "MOVE" in particular introduced
baffling errors in vertical spacing. When I threw it aside to attack
head-on the layout problems facing me, things got easier. Further,
simple caching and restoration of `.i` and `.l` register values (when
multiple changes were being made to them within a macro) obviated
`PGFORM`. I'm not sure that it is tractable to idiot-proof
manipulations of basic layout parameters like these, as these macros
seem to have tried to do. If a document author wants to seize control
of page layout from a full-service macro package and reach deep into the
guts of the formatter, they should glove up and put things back where
they found them. My opinion.
.\" London & Reiser's UNIX/32V porting paper
.\"
.\" Reconstruction in groff mm (but DWB 3.3 mm compatible)
.\" from scanned/OCRed text by G. Branden Robinson, June 2024
.\"
.\" The original scan shows no evidence of superscript usage, except on
.\" the cover sheet where "TM" superscripts "UNIX".
.\"
.\" Some differences may arise due to changes in the mm macro package
.\" itself from its PWB incarnation (ca. 1978) and DWB 3.3 (July 1992).
.\" Thanks to Dan Plassche for the history.
.\" https://www.tuhs.org/pipermail/tuhs/2022-March/025545.html
.\"
.\" The groff reimplementation of mm was undertaken mostly from
.\" 1991-1999 (by Juergen Haegg), based on the DWB documentation. It
.\" added features but also parameterized many aspects of package
.\" behavior, for example to facilitate easy localization. Later,
.\" Werner Lemberg and G. Branden Robinson contributed enhancements, bug
.\" fixes, and improvements to the groff_mm(7) man page.
.\"
.\" I anticipate adding further parameters to groff mm to better
.\" emulate the old version of mm used by this paper. (For example, the
.\" format of the caption applied to the reference page differs between
.\" PWB mm and DWB 3.3.) Where this document exercises such extensions,
.\" they should be prefixed with a `do` request so that AT&T troff will
.\" ignore them.
.\" Override: "By default, ... bold stand-alone headings are printed
.\" in a size one point smaller than the body."
.\" XXX: The cover "page" (more like a header block) is a mess when
.\" typeset with groff mm, and outright horrific in nroff mode. GBR has
.\" fixes for these pending for push to GNU Savannah's Git repository.
.\"
.\" XXX: Original scan capitalizes "Subject:"; DWB 3.3 renders it in
.\" full lowercase.
.\"
.\" XXX: Original scan bears a "TM:" heading for the technical
.\" memorandum number(s). DWB 3.3 lacks this.
.\"
.\" Memorandum captions may have changed from PWB to DWB 3.3 mm. groff
.\" mm has changed in Git (June 2024) to use the captions documented in
.\" the DWB 3.3 manual. We override the default for authenticity.
.\" XXX: Original scan sets reference marks as a typewriter might, at
.\" normal size on the baseline between square brackets. DWB 3.3
.\" converts them to superscripts but keeps the brackets(!). groff mm
.\" should add a "Rfstyle" register to control this.
.\" 0 = auto (nroff/troff); 1 = bracket; 2 = superscript; 3 = both. (?)
\" straight quotes in original
.ns \" XXX: Hack to keep `VL` from adding pre-list vertical space.
\" recte: *(\-\-p+i)
\" bad ellipsis spacing in original
\" - missing; error in text or scanner fubar?
\" recte: \-1
\" sic
.\" Either `AL` worked differently in 1978 mm, or didn't exist, or
.\" somebody wanted this list _just so_.
.\"AL "" 5
.\" XXX: Scan has signatures set farther to the right, not centered as
.\" DWB 3.3 mm sets them. groff mm follows DWB here.
.\"
.\" XXX: PWB and DWB 3.3 put the signature names in bold; groff mm sets
.\" them at normal weight. Bug.
.\"
.\" XXX: Scan has a couple of vees between the signature line and the
.\" flush left secretarial annotation. groff mm sets the annotation on
.\" the same line as the last author but also puts its information in
.\" the cover page header as DWB 3.3 does, described next. DWB 3.3: (1)
.\" omits the secretarial annotation altogether, putting it up in the
.\" cover page header under the authors' names; (2) does not use author
.\" initials (in the cover header) for this memorandum type; (3) puts
.\" the department number after "Org." on the line under the author
.\" name; (4) puts the abbreviated AT&T site name below that. Should we
.\" consider a `Sgstyle` register for groff mm?
.\"
.\" XXX: groff mm organizes the department and site name differently
.\" from DWB 3.3 in the cover head, and I don't see any reason for it
.\" to. Fix this.
.\" XXX: Scan only breaks between notations; DWB 3.3 and groff put 1v
.\" between them. Should we consider an `Nss` register for groff mm?
.\" XXX: Scan has references caption set flush left, in mixed case and
.\" bold (just like `HU`). DWB 3.3 and groff center it and set it in
.\" full caps in italics (at normal weight). If there were a way to
.\" dump the accumulated reference list independently of rendering the
.\" caption, that would give the author much more flexibility.
.\"
.\" XXX: The numbered reference list does not look like one produced
.\" with `RL` nor with `AL`. The numeric tag is left-aligned within the
.\" paragraph indentation. groff mm aligns it to the right.
.\"
.\" DWB 3.3 and Heirloom mm don't seem to honor `.RP 2` as the DWB
.\" manual documents. They start the table immediately after the
.\" reference list and go haywire boxing the table. Bug.
Regards,
Branden
[1] https://github.com/g-branden-robinson/retypesetting-mathematics
All,
There's an interesting dive into PID 0 linked to from osnews:
https://blog.dave.tf/post/linux-pid0/
In the article, the author delves into the history of the scheduler a
bit - going back to Unix v4 (his assembly language skills don't go to
PDP variants).
I like the article for two reasons - 1) it's clarity 2) it points out
the self-reinforcing nature of our search ecosystem.
I'm left with the question - how did scheduling work in v0-v4? and the
observation that search really sucks these days.
Later,
Will
Hi
Out of curiosity, what would be considered the most direct descendent of Unix available today? Yes, there are many descendants, but they've all gone down their own evolutionary paths.
Is it FreeBSD or NetBSD? Something else? I don't think it would be Minix or Linux because I remember when they came along, and it was well after various Unix versions were around.
Does such a thing even exist anymore? I remember using AT&T Unix System V and various BSD variants back in college in the 1980's. System V was the "new thing" back then but was eventually sold and seems to have faded. Maybe it is only available commercially, but it does not seem as prominent as it once was.
Any thoughts?
Thanks, Andrew Lynch
The book ``S: An Interactive Environment for Data Analysis and
Graphics'' (Wadsworth, 1984), by Richard A. Becker and John
M. Chambers, and an earlier Bell Labs report in 1981, introduced the
S statistical software system that later evolved into the commercial
S-Plus system (now defunct, I think), and the vibrant and active R
system (https://cran.r-project.org/) that we use at Utah in our
statistics courses.
Almost 21,000 open-source packages for R are available, and they
appear to be the dominant form of statistical software package
publication, based on extensive evidence in our bibliography archives
that completely cover numerous journals in probability and statistics.
I'm interested in looking into the early S source code, if possible,
to see how some statistical software that I am freshly implementing
for high-precision computation was handled at Bell Labs more than four
decades ago.
Does anyone on this list know whether the original S system was ever
distributed in source code to commercial sites, and academic sites,
that licensed Unix from Bell Labs in the 1980s? Does that code still
exist (and is openly accessible), or has it been lost?
As with the B, C, D, and R programming languages, it is rather hard
for Web search engines to find things that are known only by a single
letter of the alphabet.
-------------------------------------------------------------------------------
- Nelson H. F. Beebe Tel: +1 801 581 5254 -
- University of Utah -
- Department of Mathematics, 110 LCB Internet e-mail: beebe(a)math.utah.edu -
- 155 S 1400 E RM 233 beebe(a)acm.org beebe(a)computer.org -
- Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------
Well, I really dove into using vi by way of nvi this past week and I
have to say... the water's fine. It turns out that vi is a much simpler
editor to understand and use (but no less powerful) than it's great
grandchild, vim. To be fair, vim is an interesting editor and having
used it off and on since the mid '90s, it's very familiar... but its
powers? difficult to attain.
vim stands as an excellent example of just how far you can take a
product that works, keeping its core, but expanding it in all
directions. No matter how much I tried to grasp its essence, it alluded
me. The online help files seemed inscrutable to me, mixing environment
settings, ex commands, ex mode commands, vi motions, insert mode
commands in ways that seemed quite confusing to me. I know that I'm
probably among a select few vim users that love it without really having
a clue as to how it works. My best resource has been the web and search,
but of late I've been wanting more. That's what drove me on this quest
to really dig in to how things used to work and nvi is the best
surrogate of the old ways that I could find (well, excluding heirloom
vi, the traditional vi, which I've confirmed works pretty much the same
way as nvi, with lisp support and without a few nice-to-haves nvi has).
Anyway, here's something I worked out, after much travail - vi appears
to be all about modes, movement, counts, operators, registers, and
screens (which I found very weird at first, but simple in retrospect)...
with these fundamentals down, it seems like you can do anything and I
mean anything... and all of the other functions are just bolted on for
the purpose of making their specific tasks work.
Getting this out of the existing documentation was a mess. Thankfully
the nvi docs (based on the 4.4 docs) are much slimmer and better
organized. Even so, they make assumptions of the reader that I don't
seem to fit. Take motions as prolly the most glaring example - all of
the docs I've ever seen organize these by logical units of text (words,
paras, etc), personally and apparently persistently, I think of motion
as directed, so it took me a lot of experimentation, head scratching,
and writing things out several times in several different ways to
realize I could represent the idea on a single notecard as (some
commands appear in multiple lines):
Leftward motions - [[, {, (, 0, ^|_, B, b, h|^H
Rightward Movement - l|SP, e, E, w, W, $, ), }, ]]
Upward motions - 1G, ^B, H, ^U, -, k | ^P
Downward motions - G, ^F, L, ^D, ^M | +, j | ^J | ^N
Absolute - | G
Relative - %, H, M, L
Marks - m, ', `, '', ``
Keeping in mind that movements left-to-right are - section, para,
sentence, line, text, word and endword (big, and small), and letter. And
up and down are - file, screen, in screen (HML), half-screen,
chars-in-line, and line. For me, this inversion from units of motion to
direction of motion put forty some-odd commands in much closer reach for
me. Looking back at the vim documentation, I see how its sheer volume
and the way it is organized got in the way of my seeing the forest.
Thankfully, in nvi, there are two incredibly useful ex commands to help
- exu[sage] and viu[sage]. I simply printed these out and worked with
them making the experimental assumption that they would serve as a
baseline that represented the full capabilities of vi... and sure
enough, after working and working with them, I am pretty confident they
are sufficient for any editing task. Wow, who knew? I loved vi, but
now, I'm starting to really appreciate it's simplicity?! I can't believe
those words are coming out of my mouth. I never thought of it as
simple... those movement commands were far too numerous as I understood
them.
Are there things I miss from vim? Sure, I miss command line completion
in ex mode, I want my help text to appear in a window where I can
search, I would like better window control. But, I think I'll stick with
nvi a while until I really nail it down. Then all of the cool stuff that
vim offers, or neovim, will seem like icing on the cake that is vi.
Thanks to Ken Thompson for writing a work of art that serves as the true
core of this editor, to Bill Joy for his great work in extending it,
again to Bill Joy for bringing vi to life, and to Mary Ann for the
macros and making it accessible to the rest of us, and others who
contributed. It's 2024 and I still can't find a better terminal editor
than vi... as it existed in the late '80s or as it exists today as
nvi/vim/neovim. Amazing piece of software.
Off to figure out tags!! Arg, seems like it oughtta be really useful in
my work with source code, why can't I figure it out?! Sheesh.
Will
A small reflection on the marvels of ancient writing...
Today, I went to the local Unix user group to see what that was like. I
was pleasantly surprised to find it quite rewarding. Learned some new
stuff... and won the door prize, a copy of a book entitled "Introducing
the UNIX System" by Henry McGilton and Rachel Morgan. I accepted the
prize, but said I'd just read it and recycle it for some other deserving
unix-phile. As it turns out, I'm not giving it back, I'll contribute
another Unix book. I thought it was just some intro unix text and
figured I might learn a thing or two and let someone else who needs it
more have it after I read it, but it's a V7 book! I haven't seem many of
those around and so, I started digging into it and do I ever wish I'd
had it when I was first trying to figure stuff out! Great book, never
heard of it, or its authors, but hey, I've only read a few thousand tech
books.
What was really fun, was where I went from there - the authors mentioned
some bit about permuted indexes and the programmer's manual... So, I
went and grabbed my copy off the shelf and lo and behold, my copy either
doesn't have a permuted index or I'm not finding it, I was crushed. But,
while I was digging around the manual, I came across Section 9 - Quick
UNIX Reference! Are you kidding me?!! How many years has it taken me to
gain what knowledge I have? and here, in 20 pages is the most concise
reference manual I've ever seen.
Just the SH, TROFF and NROFF sections are worth the effort of digging up
this 40 year old text.
Anyhow, following on the heels of a recent dive into v7 and Ritchie's
setting up unix v7 documentation, I was yet again reminded of the golden
age of well written technical documents. Oh and I guess my recent
perusal of more modern "heavy weight" texts (heavy by weight, not
content, and many hundreds of pages long) might have made me more
appreciative of concision - I long for the days of 300 page and shorter
technical books :). In case you think I overstate - just got through a
pair of TCL/TK books together clocking in at 1565 pages.
Thank you Henry McGilton, Rachel Morgan, and Dennis Ritchie and Steve
Bourne and other folks of the '70s and '80s for keeping it concise. As a
late to the party unix enthusiast, I greatly value your work and am
really thankful you didn't write like they do now...
Later,
Will
