Talk:Incompatible Timesharing System

From Wikipedia, the free encyclopedia

News This page has been cited as a source by a media organization. The citation is in:

[edit] Significant Technical Features

I think it would be valuable to distinguish the features that ITS actually originated. For example, I'm pretty sure that process management by means of tree structures was first implemented in Multics, and was then ported to Unix. As far as I can tell from the research I've done, the first three features mentioned were ITS innovations, while the next three were borrowed and improved. Could someone with ITS expertise comment (or better yet, add to the article)?

For the fourth, it may be that Multics provided the basic capability to do something similar (in terms of inferior process control), but very little use was made of them (see comments below). I don't recall what Multics had in the way of stop-poke-restart for non-preplanned debugging of commands (see below for how most commands worked) - I think there was something where you could interrupt a command and a new "instance" of the command interpreter was pushed onto your process' stack, and you could call the debugger from that.
In ITS, on the other hand, the ability to have inferior processes was extremely widely used (as in Unix), and from the earliest stage the ability to completely and comprehensively control inferior processes was much more "built in". E.g. in v6 Unix you had to start a process under a debugger to be able to control it; if you just started it from the shell, you had almost no control (not even stop-restart, let alone the ability to stop it and poke around in it), except the ability to abort it. So I think ITS was novel in that way.
As to the advanced user interrupt facility, you may be right there. I don't know exactly when this feature appeared in various OS's, someone would have to research it. From what I recall of user interrupts in early Unix, they were fairly primitive, and ITS had much fancier user interrupt stuff at that stage. I don't think I ever knew much about Multics' support of user interrupts. And I don't know enough about TENEX, and other commerical OS's, to have any idea about them.
For the PCLSRing stuff, as far as I know ITS was the only OS that ever had this; for CTSS, Multics and Unix (and probably TENEX too) you could definely "see" processes stopped in the kernel. So I think that one's OK. Noel (talk) 17:43, 13 December 2007 (UTC)
You can read more about the ITS user interrupt system here. It's considerably more powerful than the v6 Unix signal() call. Noel (talk) 21:55, 13 December 2007 (UTC)
I just logged into an ITS (there are a few still there :-) to check an answer, and re-discovered a powerful capability which I'm not sure any other OS had: I'd forgotten the DDT command somewhat, and typed "$$^K" (disown all subsidiary processes) when I meant "$$V" (list all subsidiary processes) after I'd stopped a command to look something up. The sub-process was disowned (i.e. became an independent top-level process); however, there's a command (":UJOB") which allows you to take any process in the system and make it an inferior of your command-interpreter/debugger (at which point you can putz with it all you want - great for debugging daemons :-), which I used to get it back. Pretty cool. Try doing that in Unix! You can also hang up your phone line (or abort your TCP connection) and come back later and join up to whatever you had running when your connection to the machine was broken. Noel (talk) 19:04, 13 December 2007 (UTC)
I'm quite sure process control per se was added to MULTICS quite a bit later. Not only were MULTICS processes so heavyweight that you couldn't afford to have more than one for some time into the '80s (and I remember someone showing off this new MULTICS feature in that timeframe), but I also knew about the person who implemented ITS process control in UNIX and watched its adoption. I'm not familiar with the history outside of ITS of the other three innovations claimed to comment on them. Hga 09:57, 25 October 2007 (UTC)
Yes and no. The original concept for Multics was to have commands execute as separate subsidiary processes (a la Unix). However, Multics processes turned out to be rather expensive (computationally), and so the plan was changed to make commands subroutines, called from the command interpreter. (The ability of Multics to dynamically link to a subroutine in any 'file' in the filesystem was a key thing in making this work - you could compile a new command, and then try it out right away, without having to link up a new version of the command interpreter.) Multics did always have the ability for anyone to start a subsidiary process (I think), but it just wasn't used much. Noel (talk) 17:28, 13 December 2007 (UTC)

The article states that many of these features were later picked up by other operating systems. This is true, of course, in the sense (I think) that these features were perhaps inspired by ITS but independently implemented; I can't find any evidence that ITS directly affected operating design anywhere other than the ill-fated Symbolics, Inc. Symbolics' LISP machines were, I think, the logical end-point of ITS: powerful, stand-alone machines that were designed to meet the need of very, very advanced programmers. And that is one of the (many) reasons Symbolics went broke: There just weren't that many very, very advanced LISP programmers.

Job control (suspend, ^Z, same as on ITS, etc.) was put into BSD by an ITS hacker visiting Berkeley, for one thing. —Preceding unsigned comment added by 76.119.209.95 (talk) 08:35, 3 April 2008 (UTC)

Well, it all depends on your definition of "directly".
AFAIK, the actual code was not used "directly" almost anywhere. E.g. almost all of the LISP machine code (not that the LISP machine OS was much like ITS anyway) was 're-implementation' because almost all the ITS code was PDP-10 assembler, or something else, and basically all the LISP machine code was written from scratch. There were a very few ITS applications written in LISP (e.g. maybe the MACLISP compiler), and some of that may have been ported, but it wouldn't have been anything more than trivial bits and pieces.
But lots of people in the ARPA community (and outside) knew about ITS' features, and so I'm sure that it did "inspire" other people who worked on other OS's - which is what the article means when it says "picked up by other OS's".
E.g. I was never an ITS hacker (I never wrote a single line of PDP-10 code on ITS), but I knew all about how it worked. For sure, many of the Multics people (e.g. Bernie Greenberg) knew all about ITS (and about many other OS's too), and I expect it influenced them in the evolution of Multics (although Multics was so 'sui generis' that it didn't borrow a lot). In particular, every early window editor I know about (including Multics EMACS and UNIX EMACS) was directly inspired by the ITS one, even though they were all re-implementations from scratch (i.e. not translating code, but writing new code from scratch).
I don't know about device-independent displays (e.g. termcap on Unix); clearly, it was done in a whole different way, but whether it was "inspired" by ITS, hard to say. So much of this is so hard to pin down in retrospect; even if you find the person who wrote the stuff, they probably don't remember exactly what they did and didn't know about when, and may not remember exactly what they did and did not draw on to do it. Subliminal memories, comments from colleagues - there's no way to tell for sure.
I think all you can really do is say 'was this feature present in OS X before it was in OS Y', and let it go at that; sort of like 'first to publish'. Noel (talk) 18:07, 13 December 2007 (UTC)

But I DO think that ITS affected future software. The more I think about ITS, the more I think it was actually the first wiki.

Consider this:

  • Transparent access to all user-created files with every user having read/write privileges on every file
  • No password or logon needed to alter files
  • System kill command made available to anonymous users as an expression of trust in newcomers
  • Scrutiny of anonymous users via the "spy" feature and the use of "moral suasion" (as Donald Eastlake put it) to limit damage and to socialize them into the community
  • Logons are optional and considered a courtesy to other users
  • "Tourists" who started out attacking the system get recruited and become major contributors
  • Point of the system is collaboration (two, three, or more hackers would sit down next to each other at terminals, or share a terminal, in 30-hour marathon sessions)

I would be very interested to hear any reactions to this idea. Of course, there's more to the wiki story, but I'm convinced that ITS laid the foundation. Regards, Bryan 16:28, 21 November 2005 (UTC)

Well, as Steve Levy documented in his book "Hackers", ITS was an important part of the early hacker culture, so to the degree that that mindset brought us things like open/free software (where the link is explicit, through RMS), yeah, it was probably an influence. More below... Noel (talk) 18:21, 13 December 2007 (UTC)
That's an interesting theory indeed; it would be strengthened if you could find evidence of more canonical wiki features, like hypertext, reverts of some kind, and collaboration on files beyond normal program development. --Maru (talk) Contribs 19:07, 21 November 2005 (UTC)
Well, I overstated the case, but I do think that ITS is an important predecessor. I don't think there was any notion of hypertext. Because ITS could be crashed so easily, there MUST have been some kind of file reversion. I assume that some documents were collaboratively written using Emacs. Can anyone confirm any of these?Bryan 13:18, 27 November 2005 (UTC)
ROTFL! All of ITS was written collaboratively, not just the documentation. There was no protection, and so anyone could go in and work on anything - and did - just like here!
The difference was that there was no automatic full tracking/databasing of who had done what when. The file system did support 'version numbers', so if you were working on a version-numbered file (not all files were VN'd), and you wrote out a new copy, it would show as a separate file, with a new version number, and the date/time that version was written. (It may have recorded the ID of the writer in the file system somewhere, but it didn't show.) The thing was that the versions were separate files, and any could be deleted - and old/intermediate versions usually were (although they'd be on a backup tape somewhere) because disk space back then was really short. (The ITS machines all had about 6 50MB drives, IIRC - i.e. only 300MB total shared between all the dozens and dozens of users.)
One thing that was done was manual - there'd be a header in the file, and so you'd write 'Version X - Bug foo fixed - JNC', or something like that.
Coordination was either via email, or usually just running into people - most of the ITS people were in one building, it wasn't a widely geographically distributed user community. Sure, some would move (e.g. to Stanford) and come in over the ARPANet, but it was a small enough community that everyone knew everyone else.
Like I said above, philosophically I think you can see it as an antecedent of wikis, just as philosophically it's an antecedent of open software. Noel (talk) 18:21, 13 December 2007 (UTC)
ITS supported versions on a file-system level, couldn't that be thought of as a primitive system of file reversion? Athas 07:30, 13 December 2005 (UTC)
It apparently had a hypertext system, as "Info" was originally developed on it..
"Info" may have been developed on it, but it wasn't that significant part of the general software and human use of the system. I can see possible roots here, but you'd probably need to ask the creators of the original wiki, and you might need to trace back where they got the ethos for it.
And independent discovery/creation is very possible and maybe even likely, the payoff of these combined technical and social systems is so high, and little more than some imagination and willingness to not be in complete control is required to implement them, that I can see that. Hga 09:57, 25 October 2007 (UTC)

[edit] Just Curious

Just curious, the article says "A command was implemented which anyone could run which caused the system to crash". Did anyone ever try to disable this capability? Hypereides 17:32, 24 October 2007 (UTC)

To my knowledge, no more than the commands to have a program grab pretty much all the CPU (vital for running some AI programs/demos), kill other people's processes, delete system files ("Packs not Bartonized?" :-), read anyone's files including email (the mailbox of Joel Moses was particularly fascinating), etc. etc. etc. were disabled (no one ever told me the halt the system command, but then again I never asked).
The command was ":LOCK", which had a bunch of specialized sub-commands, such as killing any process in the system, reset all network connections, etc. One of them was 'shut down the system in N minutes', where N was a parameter. It was never disabled - we needed it! If a turist was jerking around, and scheduled a shutdown, we voided it and told him off. Noel (talk) 18:57, 13 December 2007 (UTC)
Sanity was maintained by social pressure (Mr. Barton never did entirely live down his MACLISP file wild card mistake, but he wasn't shunned or banned, rather he and everyone else were doubly careful afterwards), security through obscurity implemented by the apprentice method (you couldn't find out these dangerous commands unless someone told you them, or you learned how to read PDP-10 assembler and found the source code), required login accounts and the "flushing of lusers" (turning off the accounts of abusers, this was I think implemented later as more and more people got ARPANET access---and characteristically you only got access to the PANDA user control system if and when someone decided to tell you about it and its password, but there was no formal system for that), logging of the more destructive actions, including to a printer, and backups.
The really obscure and undocumented commands were the ones to create a new directory (you printed the filename '<newdirname>;NEW DIR', or something like that), and the one to enable you to patch the running OS from your debugger/command-interpreter (they were the same thing in ITS), which was... well, let's not bandy that about, eh? :-) Noel (talk) 18:57, 13 December 2007 (UTC)
It was a very special community, and understanding it is to some degree necessary if you want to understand a lot of the attitudes of RMS, he prefers systems (computer and social) that work like ITS did for very good reasons such as productivity (someone wasn't awake? maybe their email could tell you want you needed to know to fix something) and meritocracy.
There was also :FINGER, which told you who all was logged in, and how recently their console had been active, and which terminal they were logged in from (room number). A lot of the early OS's had that, though - privacy wasn't as big an issue. Noel (talk) 18:57, 13 December 2007 (UTC)
If you think about what a relatively small number of people accomplished with PDP-10 assembler and ITS TECO in a 1MB address space system, without a central project manager, all this plus the 4 systems being intimately linked through the ARPANET (you could e.g. access any file by just putting "AI:" or DM, MC, or ML in front of it), well, it was influential beyond what you might expect, and in more than just a feature list. Hga 09:39, 25 October 2007 (UTC)