Though I imagine like an online community or game it can't really be recreated since it depended on its users at MIT and elsewhere, and its specific time and place in history.
You could login either using terminal through ARPAnet dial-in support, or later over network, and over time there was added a more concrete "tourist" policy.
DonHopkins seems to have an interesting writeup https://donhopkins.medium.com/mit-ai-lab-tourist-policy-f73b...
and of course there's PDP-10 org and its gather docs on github: https://github.com/PDP-10/its
I disagree. I disagree wholeheartedly, based on both practical projects and the retrocomputing world.
For example:
https://github.com/PDP-10/its/
This is a repo for the Incompatible Timesharing System operating system, ITS to its friends. ITS ran on 36-bit mainframe hardware from Digital Equipment Corporation (DEC) which went out of production in the 1980s. DEC was acquired by Compaq in 1998, and Compaq ceased to exist as a company in 2002. Commercially, ITS is dead. It is dead-dead. It is old-university-project-with-no-grants dead. Doornails evince more metabolic activity than ITS, at least in the commercial world. Developing on ITS means reading and writing assembly language, TECO, and a Lisp dialect that only runs on ITS and a few other OSes of similar vintage and commercial utility. However, it is still under active development because people are interested in it.
Besides: Digging into a codebase to fix a dumbass printer? People will do that out of spite. People will do that for the blog post and Hacker News thread.
https://news.ycombinator.com/item?id=23115608
DonHopkins on May 8, 2020 | parent | context | favorite | on: Zork source code, 1977
Zork definitely has some puzzles that are practically impossible to figure out, without some help. The ITS operating system that Zork was developed on was a extremely open, with very little security, but lots of obscurity.
ITS was like the original "social network," where users would hang out and socialize, with lots of visibility and awareness of each other and what they're doing, where everybody could see each other's files and read each other's email, with programs like "INQUIR" for telling other people about yourself, "WHOIS" and "FINGER" for finding out about other people, "WHOJ" to see who's on and what they're doing, "SEND" and "REPLY" for sending immediate messages back and forth, "UNTALK" for multi-window chatting, "MAIL" for sending email, "RMAIL" and "BABYL" for reading email, etc.
And (important to Zork) also "OS" (Output Spy) to spy on other people's sessions over their shoulders!
Only two people could play Zork at once on DM, and only after east coast business hours. Usually there were a few other people just hanging out, spying on the two lucky people playing, chit chatting with each other and the players by sending messages and email, etc.
It was considered perfectly normal and inoffensive behavior for people to spy on each other and learn about running Lisp, hacking Emacs, or playing Zork. (As long as you're not creepy or obnoxious about it, but people tended to be polite and follow the Tourist Policy, and people liked to help each other learn. And if you liked creepy obnoxious stuff, you could subscribe to REM-DIARY-READERS!)
https://medium.com/@donhopkins/mit-ai-lab-tourist-policy-f73...
>TOURIST POLICY AND RULES FOR TOURIST USE OF ITS MACHINES
>It has been a long standing tradition at both the Laboratory for Computer Science and the Artificial Intelligence Laboratory at MIT to allow non-laboratory people to use the laboratories’ computers during off hours. During the early days of the laboratories’ existence a non-laboratory person (such people have come to be called tourists) could gain access to one of the computers by direct personal contact with a laboratory member. Furthermore, tourist access was controlled because access to the laboratories’ computers was de facto achieved through on site terminals. A tourist sponsored by a laboratory member would generally receive some guidance and tutelage concerning acceptable behavior, proper design techniques for hardware and software, proper programming techniques, etc. The expectation on the laboratories’ part was that a large percentage would become educated in the use of the advanced computing techniques developed and used in our laboratories and thereby greatly facilitate the technology transfer process. A second expectation was that some percentage would become interested and expert enough to contribute significantly to our research efforts. Tourists in this latter group would at some point in time graduate out of the tourist class and become laboratory members. In actual fact a number of former and present staff members and faculty earned their computational wings in just this fashion. [...]
MIT-DM was the Dynamic Modeling Lab's PDP-10 running a slightly different version of ITS, and it was the only ITS machine that had any form of file protection, which was primarily used to hide the Zork source code. But even that was essentially only security through obscurity, which was why the source was eventually leaked.
Zork had its own end-game, but getting an account on MIT-DM was like the pre-game, and logging into MIT-DM itself was like the Zork Lobby where you'd hang out waiting for your turn and socializing.
You could get an account on most of the ITS machines just by asking nicely and using the right magic words, like mentioning Lisp on MIT-AI, or Macsyma on MIT-MC, or SomewhatBasic on MIT-ML. But Zork was so sought after that DM was one of the harder ITS machines to get an account on -- you couldn't just say you wanted to play Zork or hack Lisp: you had to say you were interested in MDL for some plausible sounding mumbo jumbo like "algebraic applications". But they still knew you just wanted to play Zork, though.
PDP-10/its: Incompatible Timesharing System (github.com)
Sometimes I wonder, if you wanted to create an operating system like ITS for more modern platforms, what it would look like?
ITS is written in PDP-10 assembly, what if someone wrote a compiler which read in PDP-10 assembly language and spit out C code? Could that be a first step to porting it?
It is surely a lot more complicated than that. It contains self-modifying code, which would obviously break that translation strategy. A lot of hardware-specific code would have to be rewritten. 6 character filenames without nested directories might have been acceptable in the 1970s, but few could endure it today. A multi-user system with a near-total absence of security was acceptable back then, obviously not in today's very different world.
ITS does have some interesting features contemporary systems don't:
A process can submit commands to be run by the shell that spawned it – actually MS-DOS COMMAND.COM also had that feature (INT 2E), but I haven't seen anything else with it. A Unix shell could implement this by creating a Unix domain socket, and passing its path to subprocesses via an environment variable–but I've never seen that done.
Another was that a program being debugged could call an API to run commands in its own debugger – I've never seen that in any other debugger, although I suppose you could write a GDB plugin to implement it (have a magic do-nothing function, then a GDB Python script sets a breakpoint on that function, and interprets its argument as commands for GDB.) Actually, in ITS these two features were the exact same feature, since the debugger was used as the command shell.
Another was that a program had named subprocesses (by default the subprocess name was the same as the executable name, but it didn't have to be.) Compare that to most Unix shells, where it is easy to forget what you are running as background jobs 1, 2 or 3.