Hello fellow lovers of old UNIX,
After almost 20 y of intermittent development (started in the fall of
2004), I just made the first official release of my version of troff:
https://www.freecalypso.org/pub/UNIX/components/troff/qjtroff-r1.tar.Zhttps://www.freecalypso.org/pub/UNIX/components/troff/qjtroff-r1.tar.gz
(The .Z is the native format; the .gz is for greater accessibility.)
The README file inside the tarball gives the full story, but basically
it is my own derivative from classic V7 troff (not derived from
ditroff, and certainly not groff) that runs under 4.3BSD and emits
PostScript. Only PS output is supported, no non-PS targets of ditroff.
I started it in 2004, but I still use it to this day (on a real
MicroVAX running my "organically grown" 4.3BSD variant) to write
various TPS reports and technical manuals etc, for my other projects
that don't have much of anything to do with Ancient UNIX.
For anyone who loves intricacies of troff and/or PostScript, you might
find the source code quite interesting to study. :)
Some Time Soon I am hoping to put out my PostScript reprint of the
first 3 books of the 4.3BSD manual set (namely, URM, USD and PRM books)
made with this troff. The actual book reformatting job is already done
(for these 3 books, not for the other 3 yet), but I need to write new
colophons to be appended (with pstmerge, a tool from my troff suite)
at the end of each book. (The colophons I wrote for URM and PRM back
in 2012 are in need of corrections and updates, and I didn't have the
USD book done in 2012.)
I will also be responding to BSW's detailed account of V7 PDF reprint
in the other thread shortly - but I wanted to get this troff release
out first, so I won't be in a position of saying "please look at my
creation" when that creation is not publicly accessible.
M~
This isn't directly UNIX related, and yes, the thread is 3 years old. But since it made national news last night, probably due to its proximity to Newark Airport. The enormous fire in Elizabeth, NJ, I recognized in the local news as the old Singer factory. That factory was the catalyst that linked me into finding out more on Fred Grampp, and his ancestry.
Here's a non-paywalled link that also mentions it is indeed the old Singer factory: https://newjersey.news12.com/elizabeth-nj-fire-industrial-building
On Tue, Mar 16, 2021 at 11:12 AM M Douglas McIlroy <m.douglas.mcilroy at dartmouth.edu> wrote:
>
> Serendipitous find! I hadn't realized that Fred had been the third
> generation in the hardware store.
> His father ("Pops") retired to Drayton Island in the St Johns River
> about 60 miles south of Jacksonville.
> Fred often visited him, driving the 19-hour trip in one stint.
>
> Doug
>
> On Mon, Mar 15, 2021 at 6:47 PM Brian Walden <tuhs at cuzuco.com> wrote:
> >
> > Amazing coincidences. A week prior I was researching Topper Toys
> > looking for their old factory ("largest toy factory in the world")
> > As there was litte on it's location and it lead me to find out
> > in 1961 it took over the old Singer Factory in Elizabeth, NJ.
> > So looking up the Singer factory led me to "Elizabeth,
> > New Jersey, Then and Now" by Robert J. Baptista
> >
> > https://ia801304.us.archive.org/11/items/ElizabethNewJerseyThenAndNowSecond…
> >
> > Which had no information on Topper, but had had this paragraph in it's Singer
> > section on page 28 --
> >
> > Boys earned money "rushing the growler" at lunchtime at the Singer plant.
> > German workers lowered their covered beer pails, called growlers, on ropes
> > to the boys waiting below. They earned a nickel by filling them with beer
> > at Grampp's saloon on Trumbull St. One of these boys was Thomas Dunn who
> > later became a long term Mayor. In the early 1920s Frederick Grampp went
> > into the hardware business at the corner of Elizabeth Ave. and Reid St.
> >
> >
> > When I read it I thought funny, as I know the name Fred Grampp. But beleived
> > just a coincidenental same name. After reading the biography post, I went back
> > to the book as it turns out that Fred Grampp is your Fred Grampps's
> > grandfather. You can find more his family and the hardware store and
> > Grampp himself on pages 163-164, and 212.
> >
> > -Brian
> >
>
Rather than increase subject drift on a thread I started
"UNIX on (not quite bare) System/370", here's a new thread.
Since the TUHS archive seems to now include documentation,
I decided to take a look and see if the earliest UNIX manual I have
is in the archive:
It was given to me by a friend at Stevens Tech in Hoboken NJ (c. 1980)
who had graduated, and worked for AT&T.
It's hole punched for a four ring binder
(I found an unused Bell System Project Telstar binder to put it in).
The cover page has:
Upper left corner:
Bell Telephone Laboratories Incorperated
PROGRAM APPLICATION INSTRUCTION
Upper right corner:
PA-1C300-01
Section 1
Issue 1, January 1976
AT&TCo SPCS
Center:
UNIX PROGRAMMER'S MANUAL
Program Generic PG-1C300 Issue 2
Published by the UNIX Support Group
January, 1976
The preface starts with:
This document is published as part of the UNIX Operating System Program Generic,
PG-1C300 Issue 2. The development of the Program Generic is the result of the
efforts of the members of the UNIX Support Group, supervised by J.F. Maranzano
and composed of: R. B. Brant, J. Feder, C. D. Perez. T. M. Raleigh, R. E. Swift,
G. C. Vogel and I. A. Winheim.
and ends with
For corrections and comments please contact C. D. Perez, MH 2C-423, Extension
6041.
Not knowing who else I could ask, I brought it to a Boston Usenix (in
the 90's or oughts), and asked DMR if he could identify it. He said
it was an early supported UNIX, and he signed the preface page for me.
The manual has sections I through VIII; all manual pages start with page -1-
I found https://www.tuhs.org/Archive/Distributions/USDL/unix_program_description_ja…
with cover page:
UNIX PROGRAM DESCRIPTION
Program Generic PG-1C300 Issue 2
Published by the UNIX Support Group
January 1976
contents:
NUMBER ISSUE TITLE
PD-1C301-01 1 Operating System
PD-1C302-01 1 Device Drivers Section 1
PD-1C303-01 1 Device Drivers Section 2
And consists of descriptions of kernel functions.
So it seems likely that my manual is a companion to that.
I have a Brother printer/scanner, but the paper is fragile, so unless
it's of immediate and burning value to someone, it's unlikely to rise
to the top of my ever-static list of documents to scan....
But if someone has specific questions I can look up, let me know....
>> What was the physical form of this book? Was it a "perfect bound"
>> book?
> The HRW copies I have are perfect bound. But I can't remember if they
> were 3-hole punched as well.
The Holt Rinehart edition was 3-hole punched. The original V7
(and its predecessors) were prepared for AT&T standard 4-hole binders, but
distributed in Accopress binders that used only 2 of the 4.
4-hole paper was punched 2" and 3 3/8" from top and bottom of 11" paper.
This reduced the stress concentration that makes the isolated end holes in
3-hole paper vulnerable to tearing out. It was a let-down when AT&T
eventually acceded to a sort of loose-leaf Gresham's law and switched to 3
holes.
Doug
The Plan 9 C compiler must predate Plan 9 and therefore it must
have been created on Research Unix.
The v10 manual doesn't mention them, fair enough, they document
Unix and not Plan 9, but they do say that rc(1) is the Plan 9
shell...
Research Unix of the time ran on VAX. A natural question arises,
was VAX the original target of the Plan 9 compilers? Where is it?
Why isn't it mentioned anywhere?
If VAX was never a target, then what was the original purpose of
these compilers and how were they tested on a target that Research
Unix never ran on?
One might think they might have been used for the Jerq/Blit/DMD-5620,
but no, the Unix manual documents a different compiler used for
these (which is distinct from the main C compiler).
The Plan 9 compilers seems to have appeared out of thin air, but
this certainly can't be the case.
--
Aram Hăvărneanu
Wanted to share this in case anyone is in the market for one. Someone's posted a 3B2/400 to eBay along with many documents and some peripherals and such. Kicker is it's $2,000 altogether...
https://www.ebay.com/itm/186237940947
Way outside what I'm wiling to sink into one, although a 3B2 would be very nice to have around. Anywho, figured I'd spread the word in case someone in the far flung UNIX-verse is seeking one and has the funds to spare.
- Matt G.
Got some exciting stuff in the mail today, and for once it isn't going to amount to sitting in front of a scanner for hours:
https://archive.org/details/5ess-switch-dk5e-cd-1999-05
After the link is the April/May 1999 issue of the 5ESS-Switch DK5E-CD, a collection of documents and schematics concerning the 5ESS-2000 variant of the 5ESS switch, as supported at the time by Lucent-Bell Labs. Of particular UNIX interest is the following:
https://ia601200.us.archive.org/view_archive.php?archive=/12/items/5ess-swi…
This is the November 1998 issue of the 5ESS-2000 Switch UNIX RTR Operating System Reference Manual (235-700-200, Issue 7.00). From the text it appears to be a descendant of the standard UNIX literature, although it only contains the intro, basic info, section 1, as well as a section on administration as well as an EMACS paper. It alludes to a more complete manual although I have not located that in this document collection (granted I'm busy on a work thing right now, just taking the time to upload and spread the word ATM.)
There's probably plenty of other relevant stuff in there, plus plenty of content regarding the 5ESS and 3B20D generally. These CDs were included with a paper binder of installation and identification info. The binder appears to be largely for training programs and I have yet to verify whether its contents are included in these CDs or the two supplement each other. Either way, this should present plenty of leads on more potential sources of 5ESS, 3B20D, and maybe UNIX RTR stuff. Unfortunately the discs only seem to contain documents, there wasn't the holy grail of a snapshot of UNIX RTR in there that I was kinda hoping might be bumping around. Thus the hunt for 3B20 UNIX continues...
- Matt G.
P.S. This is a bit more modern than what I've been dealing with generally, hopefully given the current state of 5ESS and Nokia-Bell Labs seeming to be winding things down, that means this isn't a problem to have put up. I just urge caution on any use of this stuff that even remotely smells of commercial activities, but I probably don't have to tell anyone that. Just covering my bases.
[TUHS bcc, moved to COFF]
On Thursday, January 4th, 2024 at 10:26 AM, Kevin Bowling <kevin.bowling(a)kev009.com> wrote:
> For whatever reason, intel makes it difficult to impossible to remove
> the ME in later generations.
Part of me wonders if the general computing industry is starting to cheat off of the smartphone sector's homework, this phenomenon where whole critical components of a hardware device you literally own are still heavily controlled and provisioned by the vendor unless you do a whole bunch of tinkering to break through their stuff and "root" your device. That I can fully pay for and own a "computer" and I am not granted full root control over that device is one of the key things that keeps "smart" devices besides my work issued mobile at arms length.
For me this smells of the same stuff, they've gotten outside of the lane of *essential to function* design decisions and instead have now put in a "feature" that you are only guaranteed to opt out of by purchasing an entirely different product. In other words, the only guaranteed recourse if a CPU has something like this going on is to not use that CPU, rather than as the device owner having leeway to do what you want. Depends on the vendor really, some give more control than others, but IMO there is only one level of control you give to someone who has bought and paid for a complete device: unlimited. Anything else suggests they do not own the device, it is a permanently leased product that just stops requiring payments after a while, but if I don't get the keys, I don't consider myself to own it, I'm just borrowing it, kinda like how the Bell System used to own your telephone no matter how many decades it had been sitting on your desk.
My two cents, much of this can also be said of BIOS, UEFI, anything else that gets between you and the CPUs reset vector. Is it a nice option to have some vendor provided blob to do your DRAM training, possibly transition out of real mode, enumerate devices, whatever. Absolutely, but it's nice as an *option* that can be turned off should I want to study and commit to doing those things myself. I fear we are approaching an age where the only way you get reset vector is by breadboarding your own thing. I get wanting to protect users from say bricking the most basic firmware on a board, but if I want to risk that, I should be completely free to do so on a device I've fully paid for. For me the key point of contention is choice and consent. I'm fine having this as a selectable option. I'm not fine with it becoming an endemic "requirement." Are we there yet? Can't say, I don't run anything serious on x86-family stuff, not that ARM and RISC-V don't also have weird stuff like this going on. SBI and all that are their own wonderful kettle of fish.
BTW sorry that's pretty rambly, the lack of intimate user control over especially smart devices these days is one of the pillars of my gripes with modern tech. Only time will tell how this plays out. Unfortunately the general public just isn't educated enough (by design, not their own fault) on their rights to really get a big push on a societal scale to change this. People just want I push button I get Netflix, they'll happily throw all their rights in the garbage over bread and circuses....but that ain't new...
- Matt G.
Hi,
I've found myself wondering about partitions inside of BSD disk labels.
Specifically, when and where was the convention that "a" is root, "b" is
swap, etc?
I also understand the "c" partition to be the entire disk, unless it
isn't, at which point it's the entire slice (BIOS / MBR partition)
containing the BSD disklabel and "d" is the entire disk.
I also found something last night that indicated that OpenBSD uses disk
labels somewhat differently than FreeBSD.
Aside: This is one of the dangers of wondering how something curious
came to be and why it came to be when working on 10-15 year old FreeBSD
systems.
--
Grant. . . .
