The UNIX Time-Sharing System (1974) | Hacker News Reader

The UNIX Time-Sharing System (1974)

chsasank.github.io

90 pointschsasank35 comments

Or, alternately:

Introduction and Overview of the Multics System https://multicians.org/fjcc1.html

Thirty Years Later: Lessons from the Multics Security Evaluation https://www.acsac.org/2002/papers/classic-multics.pdf

> There is only one exception to the rule of identical treatment of files on different devices: no link may exist between one file system hierarchy and another. This restriction is enforced so as to avoid the elaborate bookkeeping which would otherwise be required to assure removal of the links when the removable volume is finally dismounted. In particular, in the root directories of all file systems, removable or not, the name .. refers to the directory itself instead of to its parent.

Is this saying that if I had a removable disk mounted at /mnt/foo and issued “cd ..” in that directory, I’d remain in /mnt/foo instead of moving up to /mnt? When did this change to the current behavior?

Great question. I never thought of this!

This reads to me as if the concept of "file system hierarchy" refers to multiple roots, which current unixes cannot have.

That makes so much more sense. I was thinking per-device instead of per-logical-root. Thank you!

i think they mean you can't hardlink across devices. there is a single hierarchy but they have mount points.

The `mount` is overloading /mnt/foo, and in a similar manner also overloading /mnt/foo/.. that's why.

If you examine an unmounted filesystem however, the raw /.. directory entry points to the same place as /. directory entry.

Yes, that is case the early UNIX. it was changed to the current behaviour by the time V7 was released (1979).

That is the current behaviour. And it's not saying what you state.

"no link" literally means no link. It's the straightforward meaning of (an ordinary, not symbolic) "link" in Unix filesystems. They cannot cross devices.

And on disc, ".." in the root is a link to the same directory. (POSIX allows for it to be this, which is the conventional Unix behaviour, or not to exist, which is the case on some non-Unix filesystems and operating systems where conceptually there is stuff "above" the root.)

Executing "cd .." ignores what is on disc at a mount point, and traverses the mount upwards.

Remember that "filesystem" has three meanings: the on-disc format of a DASD volume, the overall tree abstraction presented by the operating system, or what is presented by an FS driver.

I love this paper and always recommend it to engineers I work with who might otherwise not read academic papers. It is a well written paper that introduces still relevant concepts like images, processes, the shell and pipes very succinctly, albeit with some amusing artifacts of the 1970s.

> A “crash” is an unscheduled system reboot or halt. There is about one crash every other day; about two-thirds of them are caused by hardware-related difficulties such as power dips and inexplicable processor interrupts to random locations.

Youch. Was the PDP-11 really so unreliable?

The bigger ones definitely required decent periodic maintenance. Typically you'd contract DEC or a third party to come out semi-annually to vacuum things out, apply field fixes (yes, run wires on boards and the backplane), and run hardware diagnostics.

There were a lot of wire-wrap connections on those things. If they had been done right you were good. Done wrong, and your system was haunted until someone found the loose wire. We had an 11/45 with a flaky Unibus bay that could be "fixed" with a little percussive ablation. Finally got DEC to get serious about the problem, and they spent several days tracking down a bad socket.

I don't miss wire wrap. At all.

We have it good these days. Rack a bunch of servers, run them hard for years with only DIMM replacements or maybe the odd SSD, and recycle them once the bathtub failures start edging up. I don't want to think about the comparable compute power; my wristwatch runs rings around that 11/45. We live in the future.

Here's a wire wrapped PDP10 backplane. You'd see something similar inside a PDP8 and the earlier PDP11s.

https://upload.wikimedia.org/wikipedia/commons/f/f7/PDP-10_1...

Can you imagine trying to fault-find this with just a schematic, a meter, and a scope?

At least one RSTS/E release amusingly came with patch notes that included wire wrap instructions. I distinctly remember a great deal of grumbling when the patch caused issues and the downgrade included undoing the wire wrap patches. If you thought sharing your screen and coding or debugging was high pressure, imagine pulling out one of the drawers holding your computer's guts and dealing with this while a room full of people hovered over your shoulder. https://upload.wikimedia.org/wikipedia/commons/a/ae/PDP-11-3...

I wouldn't know, but a few years ago, I was rather impressed to see that some PDP-10 models featured a knob to manually adjust the supply voltage: https://upload.wikimedia.org/wikipedia/commons/7/71/Digital_...

I guess it's a matter of perspective. By the standards of the decade before that, a computer which could run for 2 - 3 days reliably without hardware glitches would have been remarkably reliable. For such a machine to sell for under $100,000 would have been stunning.

The reliability we think of with modern computers is, I think, mostly a consequence of very high integration. Few solder joints to go wrong.

The PDP-6 predates the integrated circuits of the PDP-11 models, and had a board as part of the ALU path that almost always blew at least one of the 36 boards (one for each bit in the machine word) on a power cycle.

Fantastic read

There are some interesting points where current design is almost exactly the same, only slightly developed. Stderr was missing in this paper, for example.

I guess I can't really appreciate the benefit they describe here, because I'd need to know the alternatives and prior art:

> Another important aspect of programming convenience is that there are no “control blocks” with a complicated structure partially maintained by and depended on by the file system or other system calls.

stderr is not missing.

> The discussion of I/O in §3 above seems to imply that every file used by a program must be opened or created by the program in order to get a file descriptor for the file. Programs executed by the Shell, however, start off with two open files which have file descriptors 0 and 1. As such a program begins execution, file 1 is open for writing, and is best understood as the standard output file. Except under circumstances indicated below, this file is the user’s typewriter. Thus programs which wish to write informative or diagnostic information ordinarily use file descriptor 1. Conversely, file 0 starts off open for reading, and programs which wish to read messages typed by the user usually read this file.

Thats stdin & stdout. stderr is file descriptor 2.

you're right! thanks for clarifying!

> Our goals throughout the effort, when articulated at all, have

> always concerned themselves with building a comfortable relationship

> with the machine and with exploring ideas and inventions in

> operating systems. We have not been faced with the need to satisfy

> someone else's requirements, and for this freedom we are grateful.

> Dennis M. Ritchie and Ken Thompson (1974)

>"The PDP-11/45 on which our UNIX installation is implemented is a 16-bit word (8-bit byte) computer with 144 Kbytes of core memory;

UNIX occupies 42K bytes."

Compare that to Ubuntu's requirements in 2020:

https://help.ubuntu.com/community/Installation/SystemRequire...

>"Ubuntu Desktop Edition

o 2 GHz dual core processor

o 4 GB RAM (system memory)

o 25 GB of hard-drive space (or USB stick, memory card or external drive but see LiveCD for an alternative approach)

o VGA capable of 1024x768 screen resolution

o Either a CD/DVD drive or a USB port for the installer media

o Internet access is helpful"

I doubt a PDP-11 will handle an AMD graphics card upgrade then.

It hardly makes a difference to running CLI with screen, bash and vim.

The real overhead now is in interfacing: your CLI screen still needs to output (probably) VGA graphics, you'll need USB host support, wired and wireless networking, more sophisticated file systems...

From my point of view that is still kind of catching up with big iron UNIX and mainframes, revienting many of their ideas that were already a thing in the late 90's.

For example, my first experience with containers was with HP-UX Vault, likewise for most fancy filesystems that GNU/Linux might be getting.

Linux distributions might be a lot smaller if a) the kernel only included drivers for a single hardware platform, single file system, text terminals, and no network devices or protocols, b) /usr/lib only included libc, and c) everything was still 32-bit.

There are certainly examples of very compact Unix-like OSes that nonetheless offer memory protection, paging/virtual memory, preemptive multitasking, and a system call interface.

> Linux distributions might be a lot smaller if a) the kernel only included drivers for a single hardware platform, single file system, text terminals, and no network devices or protocols, b) /usr/lib only included libc, and c) everything was still 32-bit.

As for that last: The PDP-11 was a 16-bit architecture, which got somewhat interesting to work with when software began to grow functionality beyond what would comfortably fit in that address space. The 32-bit PDP-11 was going to be called the Virtual Address Extension, or the VAX; instead, the VAX was turned into a machine rather more elaborate than a "better PDP-11".

better comparison would be ubuntu server edition (no gui) 1 GHz CPU 512 MB RAM (system memory) 2.5 GB hard drive

Now try comparing the capabilities of UNIX on PDP to Ubuntu on a modern desktop as well

It hardly makes a difference, given how many seem to enjoy tailoring their octa core laptop with HiDPI screen to look like a PDP developer experience.

The elephant in the room is more, like, the conceptual simplicity, interface stability, and portability compared to the never-ending proliferation of Linux kludges ^H^H^H innovations turning out to bring as much problems as they're trying to solve, or more eg https://lwn.net/Articles/679786/

Perhaps something like this is closer in functionality:

"Sufficient Flash to accommodate OpenWrt firmware image

* 4MB min (won't be able to install GUI (LuCI))

* 8MB better (will fit GUI and some other applications)

Sufficient RAM for stable operation

* 32MB min, 64MB better"

(Directly from https://openwrt.org/supported_devices)

Still a few magnitudes more than the PDP-11/45, though.

The submitted title ("Classic Paper: The Unix Time-Sharing System. Highly Readable and Relevant") broke the site guideline against editorializing. If you'd please review https://news.ycombinator.com/newsguidelines.html and follow the rules, we'd appreciate it.

"Please use the original title, unless it is misleading or linkbait; don't editorialize."

Ok somebody changed the title. That is awesome. thanks!

Reply on news.ycombinator.com