8 ms·

The UNIX Time-Sharing System (1974)

90 points by chsasank 6y ago

peter_d_sherman 6y ago
>"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/SystemRequirements 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"
- tannhaeuser 6y ago
  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/ https://lwn.net/Articles/679786/
- Waterluvian 6y ago
  I doubt a PDP-11 will handle an AMD graphics card upgrade then.
  - pjmlp 6y ago
    It hardly makes a difference to running CLI with screen, bash and vim.
    - spongeb00b 6y ago
      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...
      - pjmlp 6y ago
        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.
- musicale 6y ago
  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.
  - msla 6y ago
    > 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".
- mushufasa 6y ago
  better comparison would be ubuntu server edition (no gui) 1 GHz CPU 512 MB RAM (system memory) 2.5 GB hard drive
- deleted 6y ago
  [deleted]
- zaptheimpaler 6y ago
  Now try comparing the capabilities of UNIX on PDP to Ubuntu on a modern desktop as well
  - pjmlp 6y ago
    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.
- taneliv 6y ago
  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 https://openwrt.org/supported_devices) Still a few magnitudes more than the PDP-11/45, though.
musicale 6y ago
Or, alternately: Introduction and Overview of the Multics System https://multicians.org/fjcc1.html https://multicians.org/fjcc1.html Thirty Years Later: Lessons from the Multics Security Evaluation https://www.acsac.org/2002/papers/classic-multics.pdf https://www.acsac.org/2002/papers/classic-multics.pdf
mlaux 6y ago
> 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?
- chsasank 6y ago
  Great question. I never thought of this!
- LeoPanthera 6y ago
  This reads to me as if the concept of "file system hierarchy" refers to multiple roots, which current unixes cannot have.
  - mlaux 6y ago
    That makes so much more sense. I was thinking per-device instead of per-logical-root. Thank you!
  - joshu 6y ago
    i think they mean you can't hardlink across devices. there is a single hierarchy but they have mount points.
- kubanczyk 6y ago
  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.
- aap_ 6y ago
  Yes, that is case the early UNIX. it was changed to the current behaviour by the time V7 was released (1979).
jrhouston 6y ago
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.
dang 6y ago
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 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."
- chsasank 6y ago
  Ok somebody changed the title. That is awesome. thanks!
kzrdude 6y ago
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.
- chsasank 6y ago
  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.
  - rwbhn 6y ago
    Thats stdin & stdout. stderr is file descriptor 2.
    - chsasank 6y ago
      you're right! thanks for clarifying!
mct 6y ago
> 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?
- kabdib 6y ago
  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.
  - TheOtherHobbes 6y ago
    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_1090_Backplane.jpg 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?
  - technofiend 6y ago
    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-34_wirewrap.jpg https://upload.wikimedia.org/wikipedia/commons/a/ae/PDP-11-3...
harrigan 6y ago
> 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)

90 points by chsasank 6y ago

>"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/SystemRequirements 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"

tannhaeuser 6y ago
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/ https://lwn.net/Articles/679786/
Waterluvian 6y ago
I doubt a PDP-11 will handle an AMD graphics card upgrade then.
- pjmlp 6y ago
  It hardly makes a difference to running CLI with screen, bash and vim.
  - spongeb00b 6y ago
    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...
    - pjmlp 6y ago
      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.
musicale 6y ago
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.
- msla 6y ago
  > 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".
mushufasa 6y ago
better comparison would be ubuntu server edition (no gui) 1 GHz CPU 512 MB RAM (system memory) 2.5 GB hard drive
deleted 6y ago
[deleted]
zaptheimpaler 6y ago
Now try comparing the capabilities of UNIX on PDP to Ubuntu on a modern desktop as well
- pjmlp 6y ago
  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.
taneliv 6y ago
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 https://openwrt.org/supported_devices) Still a few magnitudes more than the PDP-11/45, though.

musicale 6y ago

Or, alternately: Introduction and Overview of the Multics System https://multicians.org/fjcc1.html https://multicians.org/fjcc1.html Thirty Years Later: Lessons from the Multics Security Evaluation https://www.acsac.org/2002/papers/classic-multics.pdf https://www.acsac.org/2002/papers/classic-multics.pdf

mlaux 6y ago

> 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?

chsasank 6y ago
Great question. I never thought of this!
LeoPanthera 6y ago
This reads to me as if the concept of "file system hierarchy" refers to multiple roots, which current unixes cannot have.
- mlaux 6y ago
  That makes so much more sense. I was thinking per-device instead of per-logical-root. Thank you!
- joshu 6y ago
  i think they mean you can't hardlink across devices. there is a single hierarchy but they have mount points.
kubanczyk 6y ago
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.
aap_ 6y ago
Yes, that is case the early UNIX. it was changed to the current behaviour by the time V7 was released (1979).

jrhouston 6y ago

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.

dang 6y ago

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 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."

chsasank 6y ago
Ok somebody changed the title. That is awesome. thanks!

kzrdude 6y ago

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.

chsasank 6y ago
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.
- rwbhn 6y ago
  Thats stdin & stdout. stderr is file descriptor 2.
  - chsasank 6y ago
    you're right! thanks for clarifying!

mct 6y ago

> 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?

kabdib 6y ago
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.
- TheOtherHobbes 6y ago
  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_1090_Backplane.jpg 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?
- technofiend 6y ago
  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-34_wirewrap.jpg https://upload.wikimedia.org/wikipedia/commons/a/ae/PDP-11-3...

harrigan 6y ago

> 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)