Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10 5/3/83; site cbosgd.UUCP Path: utzoo!linus!decvax!harpo!eagle!hou5h!hou5a!hou5d!hogpc!houxm!ihnp4!cbosgd!mark From: mark@cbosgd.UUCP Newsgroups: net.followup Subject: Re: Why do you like your OS? Message-ID: <256@cbosgd.UUCP> Date: Tue, 30-Aug-83 15:20:46 EDT Article-I.D.: cbosgd.256 Posted: Tue Aug 30 15:20:46 1983 Date-Received: Thu, 1-Sep-83 05:16:22 EDT References: <1910@ihldt.UUCP> <750@hou5e.UUCP>, <668@mit-eddie.UUCP> Organization: Bell Labs, Columbus Lines: 99 Having used ITS, I feel obliged to respond to this. (Most people on Usenet have never even HEARD of ITS, so don't understand what gumby (who the heck is that, anyway) is talking about.) Briefly, ITS is the Incompatible Timesharing System, which runs on PDP-10's at MIT. There are something like 4 machines in the world running ITS, all at MIT. It's a cute research operating system, but hasn't caught on anywhere else. The major contributions of ITS are (1) EMACS, (2) job control ala 4BSD was first done here, and (3) MACSYMA was developed on an ITS. The attitude of the people who did ITS is best summed up by the following dialog with their FTP server % ftp mit-mc Connected to mit-mc. 220- MIT-MC ITS 1348, FTP server 278 220 Bugs/gripes to BUG-FTP @ MIT-MC Name (mit-mc:mark): foo 230 OK, your user name is FOO ftp> quote pass bar ---> pass bar 230 What makes you think you need a password? ftp> put (local-file) foo (remote-file) users;foo 200 OK, port 1083 150 Socket to me! 226 FINIS - DSK:USERS;FOO 1 30 bytes sent in 0.06 seconds (0.49 Kbytes/s) ftp> get (remote-file) users;foo (local-file) bar 200 OK, port 1084 150 Look out! Here comes DSK:USERS;FOO 1 226 That's all, folks! 30 bytes received in 0.84 seconds (0.035 Kbytes/s) ftp> bye 221 BCNU Anyway, on to the issues at hand. Actually, for mmany applications, you care about memory allocation, and real-time IO. How does unix fare here? pretty badly. Of course, the whole point of UNIX is that if you need real time I/O or HDLC or whatever bizarre thing you decide you need, it's easy to put it in. Umpteen people have done real time for UNIX. As to memory allocation, I have plenty of it on vmunix. I don't know what you want. And it forces you to work a lot harder than I would like to access the CRT. Rather than have a good virtual, job-wide model of what the TTY looks like you have to be careful that somebody's brain-damaged program 1> gives you the info, and B> hasn't completely trashed the tty before returning or passing it on. The ITS model of terminal handling uses virtual terminals - all programs speak control-P codes. Either you get a driver for your terminal put into the kernel (they will refuse to add any more, since they already support about 10 terminals and their kernel's 18 bit address space is full) or put it into a user program called CRTSTY, which contains drivers for several dozen other terminal types, all written in PDP-10 assembly language. (The author of CRTSTY claims he can add a new terminal type as quickly as I can create a new terminfo or termcap description. He must be quite an assembler guru!) The problem with CRTSTY is that it puts a heavy load on their system to use it (in effect, another user is logged in, this user shows up in a who!), and it doesn't have as many terminal types as terminfo (50 or so compared to 200 or so). The problem with virtual terminal models is that they do not convey any information to the user program about limitations of your terminal. Using their EMACS on a terminal without insert/delete line/char is very painful, because on every keystroke your screen is fully up to date, and this can take a long time to redraw. Ever try to run EMACS at 300 baud? Given that you're stuck with 300 baud, vi is a reasonable choice of editor, EMACS is not. Also, they refuse to support terminals that use xon/xoff handshaking, usually invoking flames about losing network protocols that aren't transparent. (Almost all modern terminals use and need xon/xoff, especially bitmapped terminals like the blit and bitgraph.) How many timesharing systems could support vi fully? While letting things run in the background? And how many systems have a command language as rich as even the first Shell? Both Multics and ITS have had these things since the mid-60's. Of course, ITS does not support vi, it supports EMACS. It does have a nice background facility, but their shell is DDT, which is really a debugger that also happens to work as a command interpreter. I don't believe anyone claims that DDT is as powerful as even the V6 shell. You forget the history that led up to the creation of unix. Even unix has only become usable in recent years. Well, excuse me! While it's quite true that ITS is older than UNIX, I see no reason to refuse to buy a 1983 Honda Accord because the 1970 Honda Civic had a motorcycle engine. Certainly it offers you a lot, what with semi-standardised io and a extensible filesystem. But the price you have had to pay is a (until very recently) fragile filesystem, slow scheduler, and mostly klugy software. It's virtually impossible to debug a running unix kernal because all of its datastructures are compiled out of existence. No content, no comment. ITS is a neat system. However, it hasn't changed in about 10 years, and only runs on an 18 bit machine that costs several times as much as a VAX. UNIX is a much more modern system, and runs on $5K hardware. just as well as ITS runs on a PDP-10.