Does anyone know if there are any surviving examples of SVR2 for the PDP-11? Various SVR2 manuals still make mention of the assembler, linker, etc. and the pdp11 variable is present in machid(1)*. And on the note of the later years of the PDP-11, was there any hope for SVR3 on the PDP? I presume the introduction of demand paging was the end of things but I would be curious for anyone's recollections on the final years of System V on the PDP-11.
- Matt G.
P.S. *interesting little 3B5 side note, found as I was checking references that machid(1) in the "System V" branded manual from the initial System V commercial release mentions the pdp11, vax, and u3b machines, the latter being the 3B20S. However, the "Release 5.0" branded manuals also make mention of the u3b5 machine, the 3B5. The System V manuals are from January 1983 and the Release 5.0 manuals are June 1982. There isn't an earlier reference to cite as machid(1) was introduced in Release 5.0, at least from the literature I have available. The 4.x series ran on at least the PDP-11, VAX, and 3B20S computers at least, matching those listed in the System V manual. From what I have available initial 3B5 literature was distributed in the form of small binders a little different from the grey-on-black 1984 DEC Processor SVR2 binders, possibly right on the cusp of the split of p_man from u_man as this 3B5 User's Manual that I have contains sections 1-6 rather than just 1 and 6. They're dark grey with a large orange square in the middle (I believe I've sent a photograph of the manual before).
As a longtime user and lover of ed/ex/vi, I don't know much about emacs,
but lately I've been using it more (as it seems like any self-respecting
lisper, has to at least have a passing acquaintance with it). I recently
went off and got MACLISP running in ITS. As part of that exploration, I
used EMACS, but not just any old emacs, emacs in it's first incarnation
as a set of TECO macros. To me, it just seemed like EMACS. I won't bore
you with the details - imagine lots of control and escape sequences,
many of which are the same today as then. This was late 70's stuff.
My question for the group is - when did emacs arrive in unix and was it
a full fledged text editor when it came or was it sitting on top of some
other subssystem in unix? Was TECO ever on unix?
Will
> From: Clem Cole
> A new hire in 1976, Jeff Mitchell supposedly had a bet with Bill
> Strecker that he could implement an 11 on a single"hex high" CPU board
> if he got rid of the lights and switches. He ran out of room to
> implement seperate I/D, so it became an 11/40 class [and it has an
> 8008-1 that runs the front panel].
I don't know about the Strecker story, but the first PDP-11 CPU on a single
card (a hex card) was the KD11-D:
https://gunkies.org/wiki/KD11-D_CPU
of the -11/04. It didn't have _any_ memory management, though (or a front
panel; to get that, you had to use the KY"11-LB:
https://gunkies.org/wiki/KY11-LB_Programmer%27s_Console
which added another quad card). The first -11 CPU i) on a single card and
ii) with memory management was the FDF11-A:
https://gunkies.org/wiki/KDF11-A_CPU
The first -11 CPU i) on a single card and ii) with split I+D memory
management was the KDJ11-A.
> It was not until 11/44 that DEC was able to make a hex height
> implementation of the 11 that managed to cram a full 11/70 into that
> system.
I'm not sure what your point is here? The KD11-Z CPU of the -11/44:
https://gunkies.org/wiki/KD11-Z_CPU
was a _minimum_ of five hex boards; a little smaller than a KB11-B (15 hex
cards). Floating point was an extra card; CIS was 2 more.
> if you look at the link line of sys/run the 45 does not have -i
Split I+D for the kernel was not supported by the linker in V6; a combination
of 'sysfix' (a special post-processor, which took as input a relocatable
linked image) and code in m45.s was needed.
https://gunkies.org/wiki/Upgrading_UNIX_Sixth_Editionhttps://gunkies.org/wiki/UNIX_V6_memory_layout
The code in m45.s to handle split I+D in the kernel:
https://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/sys/conf/m45.s
starts at 'start:' and is adequately commented to tell you what it's doing
when it plays around with kernel memory.
> From: Will Senn
> with I/D, you can use 64k for I and 64k for D. Was that it, or were
> there other tricks to get even more allocated
I have this vague memory that someone (Berkeley, I think?) added support for
automatic code overlays in user processes. The programmer had to decide which
modules went in which overlays, but after that it was all automagic. There
was a 4xx code allocated to them.
I think the support for that (in e.g. the linker) was somehow involved with
the use of overlays in the kernel, but I don't know the details (nothing
after V6 is at all interesting to me).
> didn't the 11 max out at 256k)?
You need to distinguish between i) the amount of memory the machine could
handle, and ii) the amount of memory that running code could 'see' at any
instant. The latter was always either 64KB, or 64KB+64KB (with split I+D
turned on, on CPUs which supported it).
The former, it's complicated. Mostly, on UNIBUS only machines, it was 256KB.
(Although there was the Able ENABLE:
https://gunkies.org/wiki/Able_ENABLE
which added an Extended UNIBUS, and could take them up to 4MB.) The -11/70,
as mentioned, had a Main Memory Bus, and could handle up to 4MB. The -11/44
had an Extended UNIBUS, and could also handle up to 4MB (but only after the
MS11-P became available; there were only 4 main memory slots in the
backplane, and MS11-M cards were only 256KB.) On QBUS achines, after the
KB11-A (Revision A), which only suppported 256 KB, all later revisions and
CPUs could also handle up to 4MB.
Noel
not quite split i and d but i do have a memory of some code which could run in three parts as overlays.
this could have been through exec’ing the next overlay with an appropriate argv and a pipe or file of data, or, perhaps there was some kernel support for overlays in early unix.
anyone seen evidence of this?
sadly i cannot remember where i saw it, i want to say it was a versatex printer driver but i am pretty sure that is rubbish.
-Steve
> From: Will Senn
> Does unix (v7) know about the PDP-11 45's split I/D space through
> configuration or is it convention and programmer's responsibility to
> know and manage what's actually available?
There are two different cases: i) support of split I+D in the kernel, and
ii) support of split I+D in user processes. Both arrived with V6; the
V5 source:
https://minnie.tuhs.org/cgi-bin/utree.pl?file=V5/usr/sys/conf/mch.shttps://minnie.tuhs.org/cgi-bin/utree.pl?file=V5/usr/sys/ken/main.c
(former for kernel; later for users) shows no sign of it.
> From: Kenneth Goodwin <kennethgoodwin56(a)gmail.com>
> 1. I don't think the 11/45 had split I & d.
> But I could be wrong.
> That did not appear until the 11/70
You are wrong.
The chief differences between the KB11-A&-D of the -11/45 and the -B&-C of
the -11/70 were i) the latter had a cache, and ii) the latter used the 32-bit
wide Main Memory Bus, which also allowed up to 4 Mbytes of main memory.
Detail here:
https://gunkies.org/wiki/PDP-11/70
along with a couple of lesser differences.
> From: "Ronald Natalie"
> with only 8 segment registers combined for code, data, and stack
I think you meant for code, data, and user block.
> The 55 (just a tweaked 45)
The /50 and /55 had the identical KB11-A&-D of the /45; the difference was
that they came pre-configured with Fastbus memory.
> In addition the 23/24/J-11 and those derived processors did.
No; the F-11 processors did not support I&D, the J-11 did.
Noel
> And I think even V7 make supported what you described, as well as implicit rules for compiling .c into a .o or into a binary.
>
> Warner Losh
You're right, I just tried it out. Been avoiding that pattern for years because I swear some make implementation I used at one point was very unhappy with that, but if V7 does it, then whatever implementation that was is probably not what I want to be using anyway.
Also shows how little I've used specifics of BSD, I've never made a Makefile using bsd.prog.mk, although I have this desire for a write-once-build-everywhere Makefile that the preponderance of build systems that generate them imply is an exercise in futility...
On that note, one quirk I've found with the implicit .c.o rule on older UNIX, just tested on V7 and System III, is that they render:
cc -c $<
rather than
cc -c -o $@ $<
If you have an object list with objects in several different directories, it spits them all out in the CWD, causing problems if you have similarly named files in multiple directories, and then outright failing on the final compilation if it's something like $(CC) -o $(BIN) $(OBJS) because $(OBJS) is a string of object pathnames with the full nested path, not just the resulting *.o files.
Granted, I could be anti-patterning here for all I know, I haven't worked closely with a whole lot of Make-based projects that aren't my own. Maybe I just haven't read these darn papers I'm always hunting down enough.
- Matt G.
"Lessons learned" overlooked the Morris worm, which exploited not only
the unpardonable gets interface, but also the unpardonable back door
that Allman built into sendmail.
This reminds me of how I agonized over Mike Lesk's refusal to remove
remote execution from uucp. (Like Eric, Mike created the feature to
help fix the myriad trouble reports these communication facilities
stimulated.) It seemed irresponsible to distribute v7 with the feature
present, yet the rest of uucp provided an almost indispensable
service. The fig leaf for allowing uucp in the distribution was that
remote execution was described in the manual. If you didn't like it
you could delete or fix uucp. (Sendmail's Trojan horse was
undocumented, though visible in the code.)
Doug
Hi All,
I got some questions recently about getting v7 working, so I fired up
OBS to create a video walkthrough of the install process and first steps
(it's basically following my v7 note, but hey some folks dig video). The
video is totally amateur hour, but it was fun. I never get tired of
logging in as dmr, writing hello.c, running cc, running hello and watch
the magic of
hello, world
appear on "screen".
As a reminder - the note (and thus, the video) walks the user through
installing OpenSIMH (including pdp11), building a tape image, installing
to disk from tape, booting off the disk, building and using a DZ-11 as a
telnet listener on 16 lines, adding a user, running learn, and piddly
stuff like setting baud, delays, and such. Not a lot of hand-holding,
but some.
When I get around to it, I'll probably update the note to add additional
test environments (I'm pretty sure it works anywhere OpenSIMH does, but
some folks like to see there system or one kinda like it in the list of
tested systems). I'm running LMDE5 and Debian 12 Bookworm these days, so
I know they work there in addition to pretty much any Linux Mint, MX
Linux, FreeBSD, Mac OS, etc.
I'm still in awe of Hayle and Ritchie's Setting Up Unix - Seventh
Edition as the basis of my note - 44 y.o. and counting... for holding up
so well.
The blog:
https://decuser.github.io
The blog post:
https://decuser.github.io/unix/research-unix/v7/videos/2023/07/14/installin…
The note blog post:
https://decuser.github.io/unix/research-unix/v7/2022/10/28/installing-and-u…
Later,
Will
Good day all, I'm emailing to offer a duplicate UNIX document I picked up free of charge to whoever speaks for it first, I'll even cover the shipping. What I've got is a second copy of the Document Processing Guide shipped with the initial System V version, code 341-920, from 1983.
Now for the caveat: I ordered this second copy as it was in much rougher shape than the one I currently have. I intend to chop the spine off so I can get quality scans of the pages rather than having to deal with creasing the hell out of the binding on my other copy (unlike the manuals and some of the other guides, this one is a typical paperback glue binding.) Once I'm done with the scans I'm just going to put all of the pages in a binder (as they're already Bell-style 7-hole punched.) That to say, I'm not ready to ship it right now, just got it today, still need to do the scans.
As for contents, this contains the System V-era versions of the following papers (titles paraphrased):
- Advanced Editing on UNIX
- Sed
- NROFF/TROFF User's Manual
- TROFF Tutorial
- Tbl
- Eqn
- MM Macros Manual
- View Graphs and Slide Macros
Anywho, figured I'd see if anyone was interested in this after I'm done with it. Otherwise I'll just see if a library around here is interested.
- Matt G.
Hello, I received in the mail today a USOC listing from the NY Bell division listing various standardized service codes in 1982. I wasn't particularly expecting to see anything relevant to UNIX in there, but flipping through the pages, it did have me curious on one point. Prior to divestiture, one of the conditions placed on Bell was that they could not support UNIX. Sure, tapes could find their way to individuals for service costs or under particular agreements, but this provision of "service" seemed to be right out and not allowed under their then-terms. This is presumably why there is nothing resembling UNIX in this manual, nor can I find anything implying 3B20(D/S) services.
So after 1983 when the cat is out of the bag and AT&T begins aggressive marketing, what sorts of "services" were they then providing to UNIX customers that they couldn't before? One item I've got that further complicates my understanding, a class listing from Western Electric Corporate Education from July, 1983[1]. Did offering classes like this not constitute "support", or was there a little window between 1982 and 1984 where AT&T could start their true marketing and support in earnest while still not being absolutely complete with the divestiture of the Western Electric business? In any case, if WECo was out the door as part of the legal settlement, it does strike me as a bit odd they'd put any work into spinning up the WECo Corporate Education machine on this for the space of just part of a year in 1983, only to then rebrand it all for ATTIS when Jan 1st passes. An additional time-frame indicator is while this foldout does list WECo, it is devoid of Bell system logos, consistent with the date as that was one of the conditions that started to take effect that summer.
Anywho, I'm sure some of the general information what services they provided in addition to licensing and distributing for UNIX license holders lives in documentation out there, so I'll be reading up too, but figured it'd be good to ask if nothing else to figure out what was going on in the early 80s, because that WECo training document certainly has me a bit curious on the timeframe vs what they could and couldn't do throughout the Bell System breakup years.
- Matt G.
[1] -https://imgur.com/a/xbEOGZn
Note, I intend to do a proper scan on glass with this after I get through some IBM stuff I'm working on, so don't worry, I don't intend these photos to be historical record.
A friend found this doc which as far as I can tell is not online anywhere
yet. Preliminary sketch for the UNIX/370 effort at Bell based on TSS/370.
Apparently started at Holmdel, I had always thought Indian Hill.
https://drive.google.com/file/d/1zrnKJ7fT1yrt_9r8QJHtZm7cI9EQEw76/view?usp=…
Please archive!
This is perhaps the first significant document I wrote at Amdahl. Although
undated, I believe this was written in August 1979, after I had attended a
2 week class at IBM Chicago about VM//370(CP) internals and performance.
The paper makes reference to V7 UNIX being "on order", so this is when the
V6 UNIX system was in use. IIRC, V7 UNIX was released in Nov. of 1979.
https://drive.google.com/file/d/1cB2eqTwmicj1AQOiULDZjED5Rq-_V4N4/view?usp=…
Huge thanks to my friend Karl D. for hanging on to this for 44 years.
> From: Henry Bent
> there will be a lengthy addendum shortly.
The most useful thing is probably this:
https://minnie.tuhs.org/cgi-bin/utree.pl?file=V4/nsys/ken/low.s
which lists exactly what was there; not only the types, but how many of each
there are. This is from 'nsys', which is slightly before the actual V4, so
it's quite early. 'low.s' is inherently machine-specific; i.e. different
machines would share most kernel files identically, but _not_ this one -
unless they had _absolutely identical_ device sets. So this one is _probably_
the one from the /45 in picture.
It shows:
RK11
RF11
PC11
TC11
TM11
1xKL11
12xDC11
1xDP11 (synchronous serial)
1xDN11 (dial-out asynch control)
1xDR11C (parallel port to -11/20)
2xDC11 (Screw Works voice synthesizer)
1xDR11A (voice response unit)
1xDR11C (C/A/T typesetter)
(Line printer, card reader and RP11 are commented out; more about the RP11
in a later message.
There's also this:
https://minnie.tuhs.org/cgi-bin/utree.pl?file=V4/nsys/ken/11-45
which is a bit hard to interpret, but I think might list what's in each rack:
the TC11, RK11 (early ones), RF11 and TM11 (early ones) were large custom
wire-wrapped backplanes which bolted into the front or back of a 19 inch
rack; this:
https://gunkies.org/wiki/RK11-C_disk_controller
has an image of such an RK11. The "MOS 16-24" is probably a reference to an
MS11:
https://gunkies.org/wiki/MS11_Semiconductor_Memory_System
which had to mount in the CPU backplane. The "MM" entries are likely core
memory units; probably MM11-K's:
https://gunkies.org/wiki/MM11-K_core_memory
since they seem to be 4KW each. (Maybe MM11-E's or 'F's, though; those are
also 4KW each.) I'm not sure what they "PL"s are - probably Plessey core?
Anyway,it looks like the machine had 104KB total.
This file:
https://minnie.tuhs.org/cgi-bin/utree.pl?file=V4/nsys/ken/conf.c
lists all the types of devices on the machine. One oddity is that it lists
two RK11's; but if you look at the RK11 driver:
https://minnie.tuhs.org/cgi-bin/utree.pl?file=V4/nsys/dmr/rk.c
it's only set up to handle one physical controller. But there is this:
#define JRK 1 /* temp */
if (bp->b_dev.d_major==JRK)
d = bp->b_dev.d_minor;
else
d = bp->b_blkno%3;
so the two different major device entries appear to handle the same disks in
different ways ("d = bp->b_blkno%3" will spread a virtual drive across three
physical drives).
Memory, it would have been hard to say (UNIX even then sized memory at start
up) but then I found that '11-45' file. I also found a copy of the CACM
version of the UNIX paper:
https://people.eecs.berkeley.edu/~brewer/cs262/unix.pdf
which says the machine had 144KB (so they had added 40KB more at that point).
(I seem to recall someone had scanned the SOSP version; I didn't save the
pointer, but if someone knows where it is, it would be interesting to look,
and see what it says - they seemed to update this paper on a regular basis -
the copy included with V6 talks about the -11/70.)
The system at that point had "a 1M byte fixed-head disk .. four moving-head
disk drives which each provide 2.5M bytes on removable disk cartridges, and
a single moving-head disk drive which uses removable 40M byte disk packs"
The RS11 disks for the RF11 were 512KB, so either they'd added a second one,
or switched to an RS04 (but that's a MASSBUS device). The big disk was an
RP03 so they had added an RP11, which wasn't present earlier.
Noel
Hello all,
I asked this question in a different thread but it may have been bogged
down in other discussion so I figured it was worth asking again.
What was the hardware configuration of the 11/45 that Research used to
implement early UNIX? This would be circa late 1972/earlty 1973. I have
found numerous references to it being an early production 11/45, and I
assume that it had an RK05, but I cannot find any details about things like
memory size and other peripherals.
Since the only extant sources are for V1, which was as I understand only
run on a singular 11/20, and V5 by which time UNIX had spread it doesn't
seem possible to infer a hardware configuration from existing code.
-Henry
> From: Henry Bent
> What was the hardware configuration of the 11/45 that Research used to
> implement early UNIX? .. I have found numerous references to it being
> an early production 11/45, and I assume that it had an RK05, but I
> cannot find any details about things like memory size and other
> peripherals.
A good source is the Ken+Dennis picture:
https://www.bell-labs.com/usr/dmr/www/picture.html
and the caption which Dennis wrote for it.
The image is not quite definitive, because there are two machines in that
bank of racks: a PDP-11/20, and a PDP-11/45 (mostly hidden behind the
right-hand Teletype), and it's not possible to say which of the two machines
the various peripherals are attached to.
But it seems to have had two RK03's (and an RK11 somewhere to drive them) and
an RF11 (no idea how many RS11 drives it had at that point),; a TU56 (and a
TC11 somewhere to drive that), and a PC05 (with PC11 controller boards).
(There are pages for all these things here:
https://gunkies.org/wiki/Category:UNIBUS_Peripherals
which include links to the DEC documentation on them.)
I'm doing more searching, through documents I recall having additional
crumbs; let me go ahead and send this, and there will be a lengthy addendum
shortly.
Noel
All, way back when, Dennis sent me some DECtape images to look after. I've
put some of them in the Unix Archive (the s1 and s2 tapes) as they contained
Unix source code or binaries. The others I kept aside as they didn't contain
Unix code, or they were potentially sensitive.
Anyway, Angelo Papenhoff asked for any old tapes from the Labs that might
contain fragments of B source code or B binaries. I passed the extra tapes
on to him, and he has found some very interesting nuggets from the time
period when B -> NB -> C.
So, to help provide the context around Angelo's work, I've decided to put
all the tapes that Dennis gave me here:
https://www.tuhs.org/Archive/Applications/Dennis_Tapes/
Cheers, Warren
> Reading through [1], there are documents offered by AT&T for the "Level II COBOL" system, which some further research indicates is a product from Convergent (same folks as the UNIX PC.) There's also the LPI-COBOL which appears to be a Language Processor Inc. product.
Ryan-McFarland comes to mind: in my recollection they were the leading Cobol on small machines in the early 80’s. Ryan-McFarland’s predecessor company Digitek was contracted to do the PL/I compiler for Multics, but failed. It seems they later did Bell Labs PL/I (says https://en.wikipedia.org/wiki/Digitek) I think they did a Unix version of their Cobol in the mid/late 80’s as well.
A few years ago I tried to find out more about RM-Cobol as it existed in the late 70’s and early 80’s, but with little success. As a product it survived till the present day under the ownership of Micro-Focus and most web mentions are for more recent versions.
It would seem to me that compilers on machines with small memories and word sizes in the 60’s, 70’s and even 80’s tended to compile to a virtual machine / intermediate code -- sometimes with the option to compile to native from there. Think BCPL and o-code, Pascal and p-code, the Amsterdam Compiler Kit and m-code, the Microsoft “revenue bomb” p-code C compiler, etc. According to the above Wikipedia article RM-Cobol used the same approach. I did once see the source for another 80’s Cobol compiler and it compiled to a virtual machine with 60-bit words.
By the way, I loved the recent posts on B and NB. THUS at its best!
Reading through [1], there are documents offered by AT&T for the "Level II COBOL" system, which some further research indicates is a product from Convergent (same folks as the UNIX PC.) There's also the LPI-COBOL which appears to be a Language Processor Inc. product.
Are these the earliest AT&T endorsed COBOL solutions for UNIX or were there other efforts either promoted by Bell or even perhaps developed locally that were in any use before this version? Or otherwise is there any other family of ubiquitous UNIX COBOL tools that was in use in the 70s and early 80s, before the timeframe of this document?
Additionally is anyone aware of any surviving code or binaries of either of these or other, earlier efforts at COBOL on UNIX? I have no goal for this information in mind yet, but just gathering details at this point. Thanks all!
- Matt G.
[1] - http://bitsavers.org/pdf/att/000-111_ATT_Documentation_Guide_Nov87.pdf
So there's been quite a bit of talk about B recently (mostly from my
side) and right now I feel that I've reach an interesting enough
milestone to warrant a separate thread for this here.
First of all, I want to stress that this is still WIP,
but everything can be found here now:
https://github.com/aap/b/tree/master/unix1_bdir
In this repo you will find the following:
- bc and ba that can build themselves
(I've included .s files so everything can be bootstrapped
easily).
- libb and bilib in source form from object/library and binary files of
the s2 tape
- brt1 and brt2 restored from binary files of the s2 tape
- olibb, obilib and obrt1, older versions of the above
- a version of ba that does not generate threaded code but an
interpreted code more like the pdp-7 code.
ken told me such a thing existed at one point and indeed it is
the only way to fit the compiler into 8kb/4kw
- an implementation of this interpreted code. With this bc and ba
fit into 8kb
Note I have only tested this under apout so far. The version I used [1]
needed two tweaks, but see my README.
With this I was able to build the recently reversed B programs [2] and
produce exact matches to the originals (modulo assembler differences).
In that process I found a few mistakes I made, now the programs are
exact.
I want to thank everyone who was of help in this endeavour in one way or
another:
Ken Thompson, Phil Budne, Robert Swierczek, Steve Johnson, Warren Toomey
What's left to do now is to actually run this under UNIX v1 proper,
preferably even on a real machine. I've been too lazy for that so far.
Also there are inaccuracies and unknowns in the compiler and assembler.
Right now the intermediate code is a binary code that's easy to generate
and to parse, but if I understood ken correctly the intermediate code
was more like something the PDP-7 assembler could deal with.
I'm also rather unsure how to handle the conditional ?: operator. The
printf.o file shows that it produces labels that are in line with all
the other labels. Now the C compiler uses labels starting at L10000
for the ones generated in the second pass. So it *feels* like the
conditional should be generated by bc directly and not by ba but this
leads to other problems, which I won't go into detail now.
Finally the code should probably be a bit closer to the C compiler than
it currently is.
Cheers,
Angelo
[1] https://github.com/philbudne/pdp11-B/tree/pb/tools/apout
[2] http://squoze.net/B/programs/
> From: Diomidis Spinellis <dds(a)aueb.gr>
> I seem to recall reading that the power of Unix stems from the wise
> choice of a few design principles rather than the endless accumulation
> of special cases. However, I cannot find where this is stated.
I think you're thinking of something in the CACM paper:
https://www.bell-labs.com/usr/dmr/www/cacm.html
"The success of Unix lies not so much in new inventions but rather in the
full exploitation of a carefully selected set of fertile ideas"
Noel
I seem to recall reading that the power of Unix stems from the wise
choice of a few design principles rather than the endless accumulation
of special cases. However, I cannot find where this is stated. I tried
a Google web and a Google Scholar search using the terms "unix endless
accumulation special cases", and I also asked ChatGPT for a publication
associated with this phrase. I also searched for "special" in
D.M.Ritchie's "The Evolution of the Unix Time-sharing System" and "The
UNIX Time-sharing System A Retrospective". (Amazingly, both have
several parts that still highly relevant.)
Can anyone help? Am I misremembering something?
Howdy folks, I just wanted to pass on word that there is currently a stack of 1983 System V documents on eBay, here's a link to the User's Manual: https://www.ebay.com/itm/225659365754
The same seller has these documents available in their shop (as well as a bunch of other old computing documents and magazines):
- User's Manual
- Administrator's Manual
- Error Message Manual
- Operator's Guide
- Graphics Guide
- Transition Aids
- Release Description
So not the whole lot, but a nice spread nonetheless. I've already got all of these and they're already all scanned in some fashion or another, or I'd have scooped em up already.
Anywho, figured that might pique folks' curiosity. The pricing is very agreeable might I add, sometimes I see single volumes from this set going for over $100.
- Matt G.
I have a copy of Lions's "A Commentary on the UNIX Operating System" It is
an n-th generation photocopy that I've had for some number of decades. It
also has the source code, as I guess all of those copies did back in the
day. I could just recycle the paper -- it's yellowed with age -- but I'd
rather pay it forward and ship it to someone who promises to make copies
for others who want it. This is also on bitsavers, so you're only doing
this to preserve the sense of history in passing photocopies around.
I'll take bids on how many copies you'll provide. I'll post the winning bid
(without their address), so that the community can pressureXXXXXX ensure
they meet their commitment. I'll send it out by the end of the week.
I will give preference to US/Canada domestic addresses since that is easier
for me. How much preference is left to my discretion. :)
I hope this doesn't make me sound like a jerk; it's intended to be
lighthearted community service.