seems extremely similar to modern unixes, though of course it's only a small subset<p>main differences seem to be<p>- filenames were only 8 bytes instead of 14 or 255<p>- devices were in the root directory instead of /dev: /ppt, /bppt, /rppt, /tty, /ctty, /tty1, /tty2, /rtty, /tap0, /tap1 (magtapes), /disk (the disk), and /system (the kernel memory)<p>- there were no groups, just six permission bits (u+r, u+w, o+r, o+w, a+x, and u+s)<p>- creat is spelled with an e (and evidently you couldn't open() nonexistent files)<p>- instead of lseek you only have seek, with a different argument order and presumably only able to handle offsets of up to 64KiB (less of a problem on a "256K word disk", which is presumably 524288 bytes, according to the note on p. 12 that a 64-word block was 128 bytes), which explains the name of lseek<p>- correspondingly, there were no doubly indirect blocks and so the maximum file size actually was 64 KiB<p>- the tty really was a tty, no video terminals!<p>- "i-number" and "i-node" had hyphens, and the "i" stood for "identification"<p>- the shell prompt was "@", and there was no control flow or pipes in the shell; it's not mentioned but I think that around this time there was a `goto` command which would seek standard input until it found the specified label before returning control to the shell. i/o redirection <i>did</i> exist, and so did argument quoting<p>- `cd` was spelled `chdir` even in the shell, and was the only shell builtin<p>- correspondingly, no standard error yet; the famous phototypesetter error printout had not yet happened because there were no pipes<p>- no shell wildcards<p>- no PATH, because no /usr/bin yet (they hadn't bought the /usr disk yet)<p>- no -o flag; `as` always wrote its output to `a.out` and you had to `mv` it if that wasn't what you wanted<p>- `fork()` returned to a different location in the child process, instead of returning a status value and making you test the return value. this would have saved me great embarrassment at my first sysadmin intern position when i accidentally wrote a fork bomb (by getting the test backwards) and ran it on the departmental nfs server<p>- no `execve`, just `execle` (called `execute`)<p>- no `waitpid()`, `wait3()`, etc., just `wait()`<p>- no `select()` or sockets of course, nor any of the other bsd niceties<p>- traps weren't handleable, so there was no SIGINT yet, just SIGQUIT, with the same ^\ keystroke it has today (but no way to attach a signal handler to it); no concept of tty process group (or indeed process groups at all) so ^\ could kill a random background job. but there was an `intr` system call to disable these breaks (presumably so you didn't kill the shell)<p>- no C yet, just B, but evidently the B compiler was already generating native code instead of stack bytecode as it had a few months before. consequently the system calls are documented in terms of machine registers and assembly instructions<p>- no `rename()` system call; `mv` linked and then unlinked the file<p>- no environment variables<p>- `time()` was still provided in sixtieths of a second since "the start of the current year" (so at the time the Unix epoch was the beginning of 01971, not the beginning of 01970) and was 32 bits (the AC and MQ registers)<p>- symbol tables were written to a separate `n.out` file<p>- no `ptrace()` and so no live debugging support (except for the kernel!), just inspecting core files<p>- `tar` is called `tap` and cannot put its archives in files other than actual physical magtapes<p>sadly page a7 is missing from the scan