TOPS20 ==> UNIX (unix philosophy)

[JTW%mit-xx at sri-unix.UUCP]

From:  John T. Wroclawski <JTW at mit-xx>

In answer to BRITT's question and ZORNIG's letter: We've got a 20 and two 
750's running 4.1. I find I can write code significantly faster on the 20,
and it's almost always "better" code (metrics: efficiency and/or ease of use),
too. The rest of this comments on why I think this is true, with specifics
in answer to ZORNIG's note, and (just a little...) generally.

	I can see that anyone who thinks that command completion and online
	help is the principal measure of an operating system or programming
	environment would love TOPS-20.

Though it's beside the real point of this letter, I suspect there are
more "just users" than programmers, and that real user friendliness is
one good measure for an OS. I think it would be quite nice to be able
to find some obscure option to ls by typing a ? at it.

	On the other hand, anyone who really uses the system, system calls and
	all, could get real tired of TOPS-20 and BLISS.  I did.

I wish you'd said why.

	If you want to see the difference, try writing your favorite UNIX
	utilities in BLISS or MACRO-10 using TOPS-20 system calls and (echh..)
	byte pointers.

Although I don't think it would be particularly hard, I don't have to. I
just compile 'em up with my TOPS-20 C compiler and UNIX emulation
package. On the other hand, I suspect it would be a little harder to
write a TOPS-20 emulator for UNIX - there seem to be a few basic
functions missing from the kernel:

 * Real virtual memory support, including the ability to map portions 
   of a file or another processes address space in to an arbitrary area 
   of mine, for reading, debugging, super-efficient IPC for closely cooperating
   processes, etc. Default sharing of as much memory as possible.

 * A decent system for starting and manipulating child processes, 
   including such things as obtaining their status at any point, 
   dynamically splicing a debugging tool into a running process,
   and much more.

 * Ability to prioritize handling of asynchronous events (interrupts),
   and ability to pass them up a process tree if the first process doesn't
   want to handle them. (How do I implement something that types the
   current system load and the name  and  symbolic PC of the running 
   process when I hit ^T in UNIX without hacking the kernel TTY driver?).

 * A nice filesystem. Long names, ability to recover accidentally deleted
   files, version numbers if you like them (If you don't you can effectively
   turn them off). Doesn't break if the machine should crash, either.

 * Decent scheduler, paging, IPC (4.2 is better), etc. etc.

	... and be sure to include
	the precious command completion and "?" functions.

Can't (cheaply). The UNIX TTY driver doesn't know how to break on wake up
on arbitrary characters, or interrupt on a particular character, or any
similar function. You could always run in raw mode, I suppose.

The point is this. There is nothing wrong with UNIX in the context for
which it was first created, a simple, small OS for small machines. It 
certainly gets my vote for best current microcomputer OS. However, it
is not wise to confuse "simple and elegant" with lack of useful 
functionality. Lots of OS's made everything complicated. A few managed
to make simple things simple, and still support complex things. UNIX
only got half of that equation, and now that machines are getting
more powerful and people are trying to do harder things, it's really 
beginning to show.

				-john
-------