mat@hou5e.UUCP (08/26/83)
Why do I like UNIX? Let me see if I can put it into a few words. Many (most) systems work well if you are doing just exactly what the system designers though you might want to do. Some don't even do that without hassle. By hassle, I mean things like JCL, or like the horrible efficiency and response problems that HP's rather reliable IMAGE database system has. It IS possible to make IMAGE (a trademark of HP, I am sure) run well. You have to know how to do it, and what NOT to do. And IMAGE is built into the OS, and is another case of things being good if you use them just so. UNIX seems to be free of these problems. What is more, things like stty/ioctl give you almost as much control over your terminal (the device that you care about most) as you would have on a stand-alone real-time system. And you don't have to worry about garbage like blocking factors. And temporary vs. permanent file domains. You have indefinately extensible directory trees. How many systems give easy access to shell variables, exporting, etc. And to command line arguments? Some more modern, enlightened systems do. Finally. 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? Much less the Bourne Shell?! DTSS, perhaps. But BASIC isn't as well suited as the shell to the things that the shell does for you. In short, the system gives a lot for the costs involved in using it. Mark Terribile Duke of deNet
gumby@mit-eddie.UUCP (David Vinayak Wallace) (08/29/83)
From: mat@hou5e.UUCP
Subject: Why do you like your OS?
Date: Fri, 26-Aug-83 14:36:29 EDT
Why do I like UNIX? Let me see if I can put it into a few words.
UNIX seems to be free of these problems. What is more, things like
stty/ioctl give you almost as much control over your terminal (the
device that you care about most) as you would have on a stand-alone
real-time system.
Actually, for mmany applications, you care about memory allocation, and
real-time IO. How does unix fare here? pretty badly. 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.
How many systems give easy access to shell variables, exporting, etc.
And to command line arguments? Some more modern, enlightened systems
do. Finally.
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. You forget
the history that led up to the creation of unix. Even unix has only become
usable in recent years. 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.
I should explain that I am biased (as if you couldn't tell). I prefer ITS
on the PDP-10. Yes, it has almost the worst filesystem in existence, and
yes, it's all written in assembler. But it has the most integrated
environment I've ever seen, and allows almost unlimited hacking of any
aspect of the system.
Flames, anyone?mark@cbosgd.UUCP (08/30/83)
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.