Incompatible Timesharing System | Hacker News Reader

Incompatible Timesharing System

github.com

71 pointsrbanffy27 comments

ITS was a true hacker OS. The "command shell" (as it would be called today) was the debugger (DDT). So when your program crashed instead of getting a core dump you'd typically end up in the debugger. Hence that same behavior in the lisp machines.

Also it had no security. In fact you didn't even have to log in; all that did really was set your default directory.

I remember studying CTSS, ITS, Multics and some other historical OSs and being amazed at how much of the current OS features/design come from the 60s. Then I learned about Lisps and their history, and remember being amazed at how much current languages are grafting from them. The 50s and 60s hold a very special place in my heart wrt technology. The boldness and beauty of the ideas expressed in those years is something we rarely see these days (I feel).

This might be of interest to you: "Why KeyKOS is fascinating" - https://github.com/void4/notes/issues/41

Wikipedia article on this OS: https://en.wikipedia.org/w/index.php?title=Incompatible_Time...

See also the lesser known west-coast alternative: WAITS (at Stanford): https://en.wikipedia.org/w/index.php?title=WAITS&oldid=99028...

WAITS is a great name for an OS.

Why a permalink?

Probably doesn't matter much here but I try to always use a permalink when linking to Wikipedia, as a matter of policy. This is because:

1. The permalink is the link to the Wikipedia page as I actually saw it (and can sort of vouch for). Without a permalink, when someone visits the Wikipedia page weeks, years, or even minutes later, they may see something entirely different: maybe it has been (temporarily) vandalized, or sections removed or substantially rewritten, or the whole page has been made a redirect to some other page, or worse.

2. Even if the above reasons don't apply (and someone may actually want to see the latest version), it's very easy to go from the permalink to the current version (there's a prominent notice at the top of the page), while it's hard to go in the other direction (find the version at the time my comment was posted). So the permalink version carries "more information" / is less "lossy".

Taken to an extreme, this reasoning would suggest doing the same when linking to any page on the internet: save it on the Wayback Machine and use that URL. (People have suggested this: https://news.ycombinator.com/item?id=24406193) The reason I don't (so far) do that is:

1. On Wikipedia, permalinks are really quick and easy to obtain (it's in the sidebar to the left, and you can even just right-click and copy URL) -- saving something to the Wayback Machine takes several seconds,

2. In the case of Wikipedia, it's clear that the site owner actually intends for the permanent link to be used. (No concerns about losing clicks or whatever.) As a corollary, the permalink URL is guaranteed to work equally well (in terms of uptime, how fast it loads, CSS/JS, etc) as the current version of the page itself. Can't say the same for arbitrary websites.

3. Sites other than Wikipedia don't keep changing all the time, and there's a lower risk of being rewritten as a result of my linking to it, or being replaced by some vandalism or defacement. (Most pages on Wikipedia are very good at reverting vandalism in minutes at most, but still...)

Good point. I only ever use permalinks like that on github (linking to code of a specific commit). One can use 'y' as a shortcut on github to reload the current file with a fixed commit hash URL (instead of current branch or what it is).

How to learn Lisp, ‘82 edition:

https://github.com/PDP-10/its/blob/master/src/teach/lesson.i...

The good times when programming was few orders of magnitudes simpler with less abstraction layers.

... and when you could invite random strangers from the Internet (well, the Arpanet) to play around on your system:

This memo is aimed at users unfamiliar not only with the Emacs editor, but also with the ITS operating system. ... Emacs runs on the ITS machines, AI, ML, MC, and DM. For people coming from an Arpanet TIP, the host numbers are: 134 (AI), 198 (ML), 236 (MC), and 70 (DM). If you don't have a regular username there, ... (use) the WHOIS program: :WHOIS XYZ. If WHOIS didn't find any regular user XYZ, you can use that name. :LOGIN XYZ. You are now talking to DDT, the top-level, monitor program ...

From https://web.archive.org/web/20110723033542/http%3A//www.burl... An Introduction to the Emacs Editor by Eugene Ciccarelli, AI Memo No. 447, January 1978, Artificial Intelligence Laboratory, MIT

Has anyone attempted to port these pre-Unix oses to modern hardware?

Remember ITS was written in assembly language for the PDP-10, a 36-bit machine with an 18-bit address space (yes, it was also intended to run Lisp efficiently). It was a fun machine to program in assembly code, emulatable on a 64-bit machine sure. But not something you would "port" to a different architecture.

I bet you could write a translator to convert PDP-10 code to x86 code or something.

You could also probably rewrite it manually.

I found some here https://www.inwap.com/pdp10/emulators/

> This is the 5,376th access to this page.

Hope we don't hug it too hard

I know about emulators, but I’d think someone would have found porting ITS or Multics to x86 or Arm a fun hobby project

Multics was co-developed with the hardware; that hardware contains Multics specific features that are needed to implement Multics. Segment tables, Rings, Gates and more. enable the memory mapping and protection that that is the basis of Multics.

These hardware features are not found in the current gamut of architectures due to the dominance of the marketing value of being the fasted CPU; these features lower the CPU throughput and also cost valuable silicon space, and the economic value of a secure OS is less then the value of being faster or shinier.

Being fast is hardly a marketing feature. X86 had gates, segment tables and rings (still fully functional in 32 bit mode, so having them is not an hindrance on being fast). They got dropped in 64 bit mode because no software has used them in 25 years.

Having them wasn't a hindrance, luckily for intel. But using them to the full extent was far slower than not. E.g. call gates as a syscall mechanism have a far higher overhead compared to int80. Segments, when used in the intended finer-than-page granularity are also too slow, because changing a segment register often is very costly in terms of cache and TLB flush. That's why everyone just used a few fixed segments that almost never changed and did the interesting stuff with page-based memory management.

> They got dropped in 64 bit mode because no software has used them in 25 years.

I think there was one that used them, but i can't remember its name. Maybe someone here can help.

It was obscure enough that Intel didn't think too much about removing them.

IIRC Segments were used to speed up (para?) virtualization, before built-in support in the ISA.

Segment registers are also used as thread pointer, but that special case is still supported even in 64 bit mode.

I was talking about the rings. I remember something that used them.

I think NT at some point run drvers and some other subsystems in lesser privileged rings than ring 0. Not sure if this was dropped in later versions.

IIRC, NT 4 moved drivers into kernel space for performance. The result was that the system crashed much faster :-P.

Here's hoping that state level and non state actors make a huge mess of everything we have now so everybody can sit in the corner and have a big think.

I'm not sure about that? Chip-level security functions forcing cache flushes seem like they would be ripe for Meltdown/Spectre-style attacks.

This is amazing. I've been wanting to run this for years.

Fantastic piece of computing history.

rms mentions ITS in the movie Revolution OS, I think

Reply on news.ycombinator.com