This is amazingly cool and clearly deserves more attention, so we've changed the title and re-upped the submission to give more people a chance to see it.
(Submitted title was 'DMR Unix “Edition Zero” Manual Unearthed (restoration in progress)'.)
Is it just me or are the comments here missing the point?
This is the original writeup of Unix. It's amazingly well written and pretty complete for when it was done. This is v0 of Unix, it's barely started.
You could, and people did, write a lot of code with just that doc as documentation.
Maybe it's because I'm a Bell Labs fanboy, I find this doc impressive.
"The most important role for UNIX is to provide a file system."
I looked up TGM which is mentioned in this manual (TGML). Apparently this was what Thompson used to write the B compiler.
Anyway, I ended up on the Multicians site. Some online accounts of computing history suggest UNIX was an alternative to the Multics project.
On the Multicians site it suggests Multics had a very different concept of "files", which could also be "segments". There was apparently potential ambiguity regarding the term "file".
Here's my question for anyone who was there:
Today we often see the phrase "Everything is a file" being cited when introducing people to UNIX. But I have never seen anyone attempt to explain why. What was the context in the 1970's?
Was the UNIX notion of "files" a reaction to the approach taken by Multics?
Again, this early manual says: "The most important role for UNIX is to provide a file system."
"On the Multicians site it suggests Multics had a very different concept of "files", which could also be "segments". There was apparently potential ambiguity regarding the term "file"."
Segments are a hardware mechanism often used then for accessing or protecting things in memory due to simplicity & speed of mechanism. Several modern techniques in INFOSEC use segments to protect programs.
Here's how the MULTICs filesystem worked, though. Gist of it seems like MULTICS came up with all the key concepts I recognize for hierarchical, filesystems.
Both predate UNIX with Thompson and Ritchie actually using MULTIC before writing UNIX. So, it's probably main influence.
"Today we often see the phrase "Everything is a file" being cited when introducing people to UNIX. But I have never seen anyone attempt to explain why. What was the context in the 1970's?"
"Again, this early manual says: "The most important role for UNIX is to provide a file system.""
Ritchie was clear in other writings that there wasn't a single goal for UNIX at all other than to be usable and more than what they were working with. It was designed to be efficient and enable programmers rather than hold them back. The rest fell into place from there.
I can appreciate the response from "alvin" in the superuser comments.
Too bad networking was not part of early UNIX; sockets could perhaps have been part of the "carefully selected set of fertile ideas" that could be "keys to the implementation of a _small_ yet powerful operating system."
"carefully selected" (i.e., things are deliberately left out)
"small" (i.e., smaller than the alternatives)
These are ideas in programming that seem to have been lost over time.
Yeah, it's unfortunate. There were a number of systems in the past that got very clever with networking and it made everything easier for developers/users. Mostly happened in the 1990's. Most are aware of Plan 9. More interesting were Amoeba distributed OS and Convergent's CTOS. The CTOS was a commercial, alternative to mainframes that distributed the system among cheaper computers. Had a lot of take-up before it was canned by Unisys after an acquisition. Couldn't have innovative products threatening their mainframe profits. ;)
Amoeba was mentioned toward the end of the Hanson paper you cited above. I have read about Convergent in the past, but had not read the Hanson paper. Thank you for that.
Indeed, Multics segments were mapped into your address space on demand, and the standard way to access them was as memory. As a '60s architecture, they had a maximum size of 1 MiB (of 9 bit bytes), and by the time I showed up on the scene there was a "multi-segment file" abstraction for those with data that fit into that model that was bigger than 1 MiB.
Makes sense. Yeah, people doing the comparison should keep the timeline in mind: MULTICS 1960's concepts; UNICS (err, UNIX) 1970's concepts including takeaways from MULTICS. Back then, OS & architecture innovation was moving fast with significant changes in how things were done in that short span. Not to mention UNIX targeted a minicomputer.
Why does this supposedly old file contain UTF-8 encoded characters? (The apostrophe in “search in the user’s current directory” is U+2019, RIGHT SINGLE QUOTATION MARK.)
It's not an old file. It's a new file resulting from running OCR on a PDF of a physical manual. Clipping off the filename in the original URL, you'll find a directory [1] with an explanation in the README [2]
Indeed, and it's a good illustration of a flaw in the HN comment ranking algorithm: this "critical piece of context" is at the bottom -- and likely will stay there -- because it's the child of a heavily downvoted comment.
Reading this manual describe concepts without the use of computer jargon as brand new concepts makes the language sound really old-fashioned, like reading Jonathon Swift or Thomas Paine. Part of that, I'm sure, is that this document is now 45 years old. It kind of makes me want to go back and read the instruction manual that would have come with the first TVs and such.
"The third and last process control system call used by the Shell is
processid, status = wait()
This primitive causes its caller to suspend execution until one
of its children has completed execution. Then wait returns the
processid of the terminated process and a status value indicating
how the process died. (Processes which are never waited for die
unnoticed and presumably unmourned)."
A lost opportunity to give C multiple return values.
This should put to rest the persistent, pedantic hypercorrection that the "cat" command is so named because it "catenates" files as opposed to concatenating them.
OK, but at that point it's equally possible that it stands for "catharsis" and represents a file, previously being kept inwardly on disk, being released to standard output. The command doesn't predate UNIX, so it's a very narrow window of time for Ritchie to have gotten it wrong. And I have not seen any claims from the 1970s or 1980s that the command stands for "catenate".
This made me do my own investigating. The `csh` manual in 2BSD said "catenate" earlier in '79. Even before that, a comment in the ex (vi) 1.1 source code in 1BSD (1978) says "catenate".
So it looks like Bill Joy made the mistake! (and the Bell Labs people thought it funny?)
'OK, but at that point it's equally possible that it stands for "catharsis" and represents a file, previously being kept inwardly on disk, being released to standard output.'
Catenate and concatenate mean basically the same thing, it's trivially easy to see people confusing the two - they might even hear one for the other if they're only familiar with one. That's not going to happen with catharsis.
The use of a semicolon in the preceding sentence is what I thought might be the joke. Read the sentence again, Dennis's use of a semicolon is a rather strange way to punctuate the sentence.
CREAT(2) BSD System Calls Manual CREAT(2)
NAME
creat -- create a new file
LIBRARY
Standard C Library (libc, -lc)
SYNOPSIS
#include <fcntl.h>
int
creat(const char *path, mode_t mode);
DESCRIPTION
This interface is made obsolete by: open(2).
The creat() function is the same as:
open(path, O_CREAT | O_TRUNC | O_WRONLY, mode);
SEE ALSO
open(2)
HISTORY
The creat() function appeared in Version 6 AT&T UNIX.
BSD June 2, 1993 BSD
http://www.tuhs.org/Archive/PDP-11/Distributions/research/Mc...
This is amazingly cool and clearly deserves more attention, so we've changed the title and re-upped the submission to give more people a chance to see it.
(Submitted title was 'DMR Unix “Edition Zero” Manual Unearthed (restoration in progress)'.)