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. . . .
[TUHS as Bcc]
I just saw sad news from Bertrand Meyer. Apparently, Niklaus Wirth
passed away on the 1st. :-(
I think it's fair to say that it is nearly impossible to overstate his
influence on modern programming.
- Dan C.
Disk sections (I don't think anyone in Research called them
partitions--certainly the Research manuals didn't) were
originally defined in the device driver, not by data on the
disk. In those days, system management included recompiling
stuff, including the OS kernel, and it was not unusual for
sites to edit hp.c or whatnot to adjust things to local
preference.
There was nothing magic about the mapping between device
names and minor device numbers either; the system came with
certain conventions on the original tape, but it was not
at all uncommon to change them.
By the time I arrived at the first Unix site I ever helped
run, in a physics group at Caltech, we already used a different
naming convention: a BSD-like ddNs, where dd was a driver
name, N the physical drive unit number, s a section letter.
I don't know whether that was borrowed from BSD (it must have
started during the 3BSD era, since I started there in mid-1980
and 4BSD appears to have been released late in that year).
Looking at my archival copy of that much-locally-hacked
source tree, I see that we later moved the definitions of
all the disk-section tables to a single file compiled at
system-configuration time (we used a USG-like scheme that
compiled most of the system into libraries, rather than
compiling every file separately for each target system a
la V7 and BSD). That simplified handling our somewhat-
complicated disk topology: all but system disks were connected
through System Industries 9400 disk controllers, which were
a neat design (each controller could interface to as many as
four hosts and four disks) but in practice were not always
reliable. On one hand, we arranged for one disk to be used
in parts by our main time-sharing VAX and a subsidiary PDP-11/45,
making the 11/45 cheaper to keep around; on the other, the
main VAX had two paths to each of its disks, through different
SI controllers, so when an SI controller conked out we could
run without it until the service guys fixed it. (Each disk
was dual-ported, as was common in the SMD world, hence
connected to two controllers.)
Reliability took rather more work in those days.
A different data point: by the time I moved from California
to New Jersey and joined 1127, Research was also using a
different naming scheme for disk sections. By then the
internal naming convention was e.g. ra17 for physical unit
1, section 7; by further convention 7 (the highest-numbered
section). At some point a little later we added an ioctl
to set the starting block and size of a particular section
on a particular drive, but we never went to having the OS
itself try to find a label and trust its contents (something
that still makes the 1980s part of me feel a little creepy,
though 21st century me has come to terms with it).
Norman Wilson
Certified old fart
Toronto ON
In S.S. Pirzada's 1988 paper[1], page 35, section 3.3.2, he writes:
"Some operating telephone companies and the switching control center system (SCCS) group in Holmdel, NJ decided to use UNIX to collect maintenance data from their switches and for administration purposes. Other departments also started building applications on top of UNIX, some part of turnkey systems licensed by Western Electric (WECo)."
This is describing the situation before the establishment of USG in September 1973. I'm curious, does anyone recall what some of these pre-USG WECo "turnkey systems" were?
The things that come to mind when I think of that phrase don't come about for several years, such as the 5ESS and other work surrounding Bellmac stuff. The SCCS UNIX connection describes what becomes CB-UNIX if I understand the situation correctly, but that stays a bit afield from the more conventional pool that is dipped into for WECo needs. Switching and UNIX all kinda come back together with DMERT on 1A/3B-API and 5ESS, but again that's late 70s R&D, early 80s deployment, not this time period, leaving me terribly curious what WECo would've been bundling UNIX with and shipping out to telcos. The famous early use of UNIX in the Bell System is typography, and WECo did have involvement with Teletype equipment, so perhaps something along those lines?
If it helps set the scene, a binder I recently picked up from ~1972 describing Western Electric test sets distributed to telcos describes the following additional classes of such documents:
Shop Services - Special non-standard products
Public Telephones - System standard public telephone equipment
Data Communications - Teletypewriter and Data Sets
Subscriber Products - System standard PBX's, station equipment and special services
Non-Subscriber Products - Microwave, cable, power equipment, etc.
Non-Bell Equipment Index - Non-Bell System manufactured communication equipment
Unfortunately haven't seen any of the other binders yet but I've been keeping an eye out, one or another might describe something WECo was shipping around that had some UNIX up in it. Nothing in this binder seems computer-y enough to run an operating system, just lots of gauges, dials, and probes. Luckily it is quite clear what data test sets are designed for 103-data set maintenance so I have fodder for seeking Dataphone tools...
Anywho, happy soon to be new year folks, I'm excited to see what turns up next year!
- Matt G.
[1] - https://spiral.imperial.ac.uk/bitstream/10044/1/7942/1/Shamim_Sharfuddin_Pi…
Hi. I am trying to compile cron for the 3b2-400 and 3b2-700
and am apparently missing required libraries. The reason is
on the 3b2-400 after boot up it complains there is corruption
in the crontab for every user lp, sysadm, root and so on.
# make cron
cc -O cron.c -o cron
undefined first referenced
symbol in file
el_add cron.o
el_delete cron.o
el_empty cron.o
el_first cron.o
el_init cron.o
xmalloc cron.o
el_remove cron.o
num cron.o
days_in_mon cron.o
days_btwn cron.o
ld fatal: Symbol referencing errors. No output written to cron
*** Error code 13
Stop.
Does anyone have these libraries? Thanks.
--
WWL 📚
As I messed with making a custom cron in the late 80s,
remembered the the el_ functions are for event list processing.
But you didn't specify the source of your source, by the hardware
it needs to be of System V heritage. And a lot of that source is hard
to offically come by due to licensing. Good way to view old SVR4 is
to look at OpenIndiana, Illumos, or OpenSolaris code bases that you can
find. You're in luck, as TUHS has a copy, see -- https://www.tuhs.org/cgi-bin/utree.pl?file=OpenSolaris_b135/cmd/cron/elm.c
Look at the Makefile for the other files you need to compile into it too.
-Brian
KenUnix wrote:
> Hi. I am trying to compile cron for the 3b2-400 and 3b2-700
> and am apparently missing required libraries. The reason is
> on the 3b2-400 after boot up it complains there is corruption
> in the crontab for every user lp, sysadm, root and so on.
>
> # make cron
> cc -O cron.c -o cron
> undefined first referenced
> symbol in file
> el_add cron.o
> el_delete cron.o
> el_empty cron.o
> el_first cron.o
> el_init cron.o
> xmalloc cron.o
> el_remove cron.o
> num cron.o
> days_in_mon cron.o
> days_btwn cron.o
> ld fatal: Symbol referencing errors. No output written to cron
> *** Error code 13
>
> Stop.
Good time of day folks, I often ponder on people's attachments to pixels on the screen that come about by clicking *this* icon and typing in a box surrounded by blue and with an icon in position <xyz> vs pixels on the screen that come about instead by opening that application that is a black border with a little paper airplane button in the bottom right vs....etc.
To make it more clear, I find myself often confused at people treating email different from SMS different from social media DMs different from forum posts different from some other mechanism that like literally all the others is pixels arranged into glyphs on a screen conveying an approximation of human speech. This difference among these different ways to send said pixels to people has eluded me all my life despite working with technology since I was a tot.
What this has me curious on is if in the early days of UNIX there were attempts at suggesting which provided communication mechanisms were appropriate for what. For instance something that smells of:
It is appropriate to use mail(1) to send a review of a piece of work vs it is appropriate to use write(1) to ask Jim if he wants to take a lunch break before the big meeting. Did this matter to people back then like it seems to now? To me it's just pixels on a screen that are there when I look at them and aren't when I don't.
Truth be told I am hoping to learn something from this because I only do a couple email lists and web forums, my social life generally does not involve SMS, phone calls, nor social media. Where it has become tedious is someone I meet who seems to want to communicate over pixels on screens is then put off when I provide them an email address, usually asking instead if I have a Facebook or whatever the kids are calling Twitters today. The few times I've tried to explain email will be me transmitting you communication as pixel glyphs on a screen just like anything else would be me transmitting you communication as pixel glyphs on the screen, this doesn't diffuse their concerns any, they then just think there is something wrong with me for comparing words as pixels on a screen to words as pixels on a screen. Granted, I've probably avoided plenty of vapid people this way, but it feels like it's becoming more and more expected that "these pixels on the screen in *this* program are only for this and those pixels on the screen in *that* program are only for that".
Is this a recent phenomenon? Has communication over electronic means always had these arbitrary limitations hoisted on it by the humans that use it? Or did people not give a hoot what you sent over what program and actually cared more about the words you're saying than the word you typed at a terminal to then be able to transmit words? I doubt what I learn is going to royally change my approach to allowing technology in my irl social life, but it would be nice to at least have more mental ammo when someone asks to be friends online and then gives me mad sideeye when I go "sure here's my email address!"
- Matt G.
Are there any documented or remembered instances PDP-7 or Interdata 8/32 UNIX being installed on any such machines for use in the Bell System aside from their original hosts? Along similar lines, was the mention of PDP-7 UNIX also supporting the PDP-9 based solely on consistencies in the architecture or did this early version of UNIX actually get bootstrapped on a real PDP-9 at some point?
My understanding of the pre-3B-and-VAX landscape of UNIX in the Bell System is predominantly PDP-11 systems, but there was also work in the late 70s regarding 8086 hosts as evidenced in some BSTJ and other publications, and there is the System/370 work (Holmdel?) which I don't know enough about to say whether it technically starts before or after UNIX touches the VAX.
Thanks for any info!
- Matt G.
Hi All.
This is a bit off-topic, but people here are likely to know the answer.
V7 had a timzone function:
char *timezone(int zone, int dst);
that returned a timezone name. POSIX has a timezone variable which is
the offset in seconds from UTC.
The man pages for all of {Net,Free,Open}BSD seem to indicate that both
are available on those systems.
My question is, how? The declarations for both are given as being in <time.h>.
But don't the symbols in libc.a conflict with each other? How does a programmer
on *BSD choose which version of timezone they will get?
Feel free to reply privately.
Thanks,
Arnold
> Paul -- you left out the other "feature" -- the noise, which was still
deafening even with a model N1 and its cover.
It was indeed loud, but GE out-roared them with a blindingly fast card
reader. The machine had a supposedly gentle touch; it grabbed cards with
vacuum rather than tongs. But the make-and-break pneumatic explosions
sounded like a machine gun. A noise meter I borrowed from the Labs' tool
crib read 90db 6 feet away.
Doug
I have been working with a VAX780 sim running
Unix System V r2 VAX780 and am having strange
issues.
TERM is defined at vt100
When firing up vi at times the cursor is positioned
in the wrong place or when inserting text it over
writes areas on the screen.
I have tried vt100, vt100-am, vt100-nam and none
work as expected.
Any ideas? Thanks
-Ken
Happy holidays
--
WWL 📚
Thanks Ken! I hadn't, even considered the PDP-15. Looks like SimH supports it, that could make for an interesting project...
- Matt G.
On Monday, December 18th, 2023 at 6:12 PM, Ken Thompson <kenbob(a)gmail.com> wrote:
> the pdp-7 was run on the almost compatible
> pdp-9 and pdp-15 computers.
> i dont think that version of unix ever made
> it out of the research department.
>
> On Mon, Dec 18, 2023 at 5:54 PM segaloco via TUHS <tuhs(a)tuhs.org> wrote:
>
>> Are there any documented or remembered instances PDP-7 or Interdata 8/32 UNIX being installed on any such machines for use in the Bell System aside from their original hosts? Along similar lines, was the mention of PDP-7 UNIX also supporting the PDP-9 based solely on consistencies in the architecture or did this early version of UNIX actually get bootstrapped on a real PDP-9 at some point?
>>
>> My understanding of the pre-3B-and-VAX landscape of UNIX in the Bell System is predominantly PDP-11 systems, but there was also work in the late 70s regarding 8086 hosts as evidenced in some BSTJ and other publications, and there is the System/370 work (Holmdel?) which I don't know enough about to say whether it technically starts before or after UNIX touches the VAX.
>>
>> Thanks for any info!
>>
>> - Matt G.
> On 17 Dec 2023, at 13:02, KenUnix <ken.unix.guy(a)gmail.com> wrote:
-8<—
> I have tried vt100, vt100-am, vt100-nam and none
> work as expected.
I have a long-ago recollection that using vt100 had rendering issues with emacs, but vt102 was fine. Maybe worth a shot?
d
Somewhere between UNIX Release 3.0 and Release 4.1, a portion of the User's Manual was split off into a separate Administrator's Manual, leading to a reordering of the sections among other things. In the directories, these pieces would be placed in u_man and a_man respectively.
There may be some evidence of the manual being intact as of 4.0 or at least not completely separated. I've found consistently that references to manpages in the Documents for UNIX Release 4.0 collection follow their pre-split numbering and all refer to the User's Manual. The catch is that all references are to the UNIX User's Manual Release 3.0, so this may not point conclusively to the state of /usr/man on disk at the time. The Release 4.1 Administrator's Manual hasn't turned up yet but the User's Manual reflects the renumbering and is less the a_man pages. To complete the circle, the various Release 5.0 revisions of the documents do refer to the Administrator's Manual where appropriate.
Was the manual getting split up of any great shock or was it to be expected as the software grew? It would come to happen again between SysV and SVR2 with p_man. Out of curiosity I checked how my own manpage set is organized, it seems to be of the research order, with special files in section 4 rather than section 7 for instance. I've never studied how far reaching the different orders are.
- Matt G.
In a BSTJ article[1] it is said "The availability of a simulated UNIX operating system in DMERT allows UNIX programs from other processors to execute on the 3B20D Processor." Does this just mean C programs which are rebuilt or is there some implication DMERT's particular UNIX environment featured some sort of emulation facilities? I may be reading too much into it...
- Matt G.
[1] - https://archive.org/details/bstj62-1-303/page/n11/mode/2up
P.S. I learned I may walk past DMERT and a 3B20D most days, there's a long-operational telephone CO on my usual walk that through referencing public records I've discovered has a WECo 5ESS up in it somewhere. That's all the listing said, dunno if WECo is given as meaning an early model or just a generic name. Either way...so close yet so far, makes me ever so curious what dusty old bookshelves in that building might hold.
> From: Ken Thompson
> someone rewired someones desk lamp. i dont know how that worked out.
Sometimes electrical 'jokes' don't pan out - in a big way.
I was hacking the light switch in Jerry Saltzer's office (I don't recall
exactly what I was planning; IIRC, something mundane and lame like flipping
it upside down), and as I took it out of the box, the hot terminal touched
the side of the box (which was, properly, well grounded).
The entire 5th floor powered down.
What had happened was that the breaker for Jerry's office probably hadn't
been tripped in decades (maybe since it was put in), and it was apparently a
little sticky. Also, the floor had originally been wired back when all that
most people had in their offices, in the way of electrical load, was an
incandescent desk lamp or so. Now, most offices had, not just a couple of
terminals, most also had an Alto - greatly increased overall load. The total
draw for the whole floor was now very close to the rating of the main breaker
for the whole floor - and my slip of the hand had put it over. And that one
_wasn't_ sticky.
The worst part was that when we looked in the 5th floor electrical closet, we
couldn't find anything wrong. An electrician was summoned (luckily, or
unluckily, it was daytime; not having access to a 5th floor master, we'd gone
in while everything was unlocked - daytime), and he finally located the
breaker responsible - in an electrical closet on the 9th floor.
I got carpeted by Jerry, when he got back; I escaped without major
punishment,in part, IIRC, because I pointed out that I'd exposed a
previously-unsuspected issue. (I have this vague memory that the wiring on
the 5th floor was upgraded not long after.)
That wasn't the only historic CS building that has been abandoned. 545
Technology Square, one-time home of the Multics project, the MIT AI Lab,
and much else (including the above story) was exited by MIT some years
ago.
There, too, some history was abandoned - including the hack that allowed
people to call the elevators to their floor from their terminals. (Some
hackers had run some carefully disguised wires up into the elevator
controller - ran them along the back of structural members, carefully hidden
- and thence to the TV-11 that ran all the Knight TV bit-mapped displays
attached to the AI ITS time-sharing machine. So from a Knight TV console, if
you typed 'Escape E', it called the elevator to your floor - the code:
https://github.com/PDP-10/its/blob/master/src/system/tv.147
even has a table - at ELETAB: - giving which floor each console was on, so it
got called to the correct floor. I wonder what happened to that when the
Knight TV system was ditched? Did it get moved to another machine? Actually,
I have a dim memory that the elevator people found it, and it was removed.)
Noel
ken.unix.guy(a)gmail.com:
A company I used to work for was vacating a building. I asked, has anyone
checked under the raised floor tiles?
The answer was no. Well I did and found a lot of history down there. From
component parts from long forgotten
systems to water cooling lines for long gone IBM heavy metal and a ground
window.
===
I bet you didn't find a bowling ball.
Norman Wilson
Toronto ON
After much saying I would and never getting around to it, I've finally started filling out a bit of documentation on the various UNIX manuals I've been tracking down, fleshing out history around, tracing bibliographic references though, etc etc.
https://wiki.tuhs.org/doku.php?id=publications:manuals
Thus far I've got the research and CB pages filled out from available information, and PWB/commercial up through about '85-'86, give or take some things. I apologize in advance if I've omitted your favorite piece of trivia or got something wrong, please suggest corrections in any areas needing them, or even better, a Wiki is a communal resource so with Warren's OK, I'm sure you can also make contributions.
Most of the pictures are from my own library, although I've added a few others from thing around the net. There are links to various documents covered, TUHS content where most appropriate, a few archive.org and bitsavers links here and there. I don't intend to include links to any documents after System V's initial 1983 run, just pictures of covers for ease of identification.
I've already mentioned a few times but I highly encourage contributions. I intend to do another round at this sometime soon and round out at least the BSD stuff and later System V. If anyone else has photographs or documents they think should be in these articles and you don't want to do the Wiki part yourself, feel free to send me stuff and I'll make sure it gets put up there.
Finally, some reflection on the path here. "What was UNIX System IV" was one of those questions that plagued my mind for a long time, much before I knew much else about the history of UNIX. Not a crucial question by any means, but it was one of those little mysteries I always wanted to know more about, which is what then lead me to trying to find Release 4.0 documents and all that. Of course, that then lead to the rabbit hole of continuing to turn stuff up, I never imagined I'd actually be successful in trying to turn up more info on that version, let alone then continuing to find little pieces of history and slot in missing parts of stories. Along the way I've learned more about this darn operating system than I ever intended on learning and now feel net gain in several areas of my study. Plus, all this Bell System proximity is largely responsible for my interests in telephony as of late, and may come full circle in the gear I got for telephone experiments helping me resurrect this poor UNIX PC I've got sitting on the floor right now. I don't know what I would've been doing with so much of my free time the past few years otherwise, especially these colder months.
Hope folks enjoy the commentary!
- Matt G.
P.S. Combing over things for this, I've found a few more pieces of the UNIX/TS puzzle. The details are in the Release 3.0 section of the PWB/Commerial page linked above. Short of it is there are some interesting "leaks" of the name "UNIX/TS" into Release 3.0 documentation, inconsistently between the sources on the UNIX tree and the physical document I recently obtained.
Really sobering is the estimate that it will bring 1000 jobs to New
Brunswick. That's a small fraction of the capacity of Murray Hill. On the
upside is proximity to Rutgers.
Contrary to what the article said, Murray Hill does not date from the Labs'
foundation in 1925. The Labs was in the meat-packing district on West
Street in New York in a building now called Westbeth, said to be the
world's largest artist community. The High Line runs right through it. I
worked there one summer in the penthouse with a fine view of ship traffic
on the Hudson. Murray Hill opened in 1941 and West Street closed in about
1967.
> Goodbye, Unix Room!
The Unix Room was dismantled some time ago, but its quirky contents were
grabbed by the Labs archivist, who had them on display at the Unix50
celebration--pink flamingo, G. R. Emlin, CCW clock and all. I wonder
whether these relics will make the move.
Doug
Spotted this this morning: [https://www.ebay.com/itm/186172178090](https://www.ebay.com/itm/18617217809…
After the link is a "Western Electric 3B2 Model 300 C Programming Language Manual". The manual is from Februrary of 1984 and is of the same visual motif as the System V manuals for the 3B5 as well as DWB documentation released at the time, this motif being a small grey binder with a large orange square in the middle (as opposed to small grey binders with the AT&T death star motif that were contemporary to this time as well.) After these two cover styles, which follow the grid patterns System V original documentation, ATTIS then switches to the red covers that are seen throughout the rest of the 80s until the blue SVR4 books and the kinda criss-crossy grid pattern found on their late 80s stuff (not just UNIX, I've seen a similar motif on documentation shipped with AT&T telephones of the period, but in grey)
Interestingly, despite the date, it is still labeled Western Electric, which is strange because the 3B5 manual I have is from 1983 I'm fairly certain but doesn't have "Western Electric" on the cover. Maybe there were mixed stocks of the professionally printed binder covers from the 1982-1984 timeframe with and without WECo branding at the same time.
In any case, this one is still in the plastic and even has the 5 1/2 floppies with the SGS and other C support bits (and AT&T death star logos.) I don't plan on getting this as it's just a pinch later than where my focus is right now, but figured I'd mention it on list in case someone is looking for something like this. I got everything I needed from the pictures.
- Matt G.
