Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site brl-tgr.ARPA Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!genrad!panda!talcott!harvard!seismo!brl-tgr!tgr!RSanders.Pascalx@USGS2-MULTICS.ARPA From: RSanders.Pascalx@USGS2-MULTICS.ARPA Newsgroups: net.unix-wizards Subject: re: Unix & Multics Message-ID: <2660@brl-tgr.ARPA> Date: Thu, 31-Oct-85 11:59:34 EST Article-I.D.: brl-tgr.2660 Posted: Thu Oct 31 11:59:34 1985 Date-Received: Sat, 2-Nov-85 07:37:57 EST Sender: news@brl-tgr.ARPA Lines: 67 re: Unix & Multics Having hacked first Multics, then Unix, for about 3 years each, I have some strong opinions. Please don't refer to Multics in the past tense; there are still a few running, and Honeywell (miraculously) manages to leave them on loading docks once in a while (they sure don't try to sell them!) The things I miss most from Multics: --- Clean, well-documented, layered, modularized, [fill in the blank with good words] source code. Unix sucks in this area, compared to Multics. This is my single biggest gripe about Unix. --- A consistent user interface. Multics is much more consistent than Unix ( -brief or -bf means less verbose output for *every* Multics command). There's no way Unix, in the hands of hackers worldwide, lacking user interface and internal programming standards, can approach Multics in these 2 areas. I think it's too late for AT&T to do anything about Unix in these areas now. --- Dynamic linking. On Multics, a program that calls subroutine libraries compiles to just the program. When a library subroutine is called the first time, Multics looks in a standard set of directories (like Unix shell path), and puts a pointer to the subroutine in a static area. From then on, that subroutine call is nearly as fast as a compiled-in-same-unit subroutine call. I've been wanting this capability in Unix for years. No flames about drawbacks from people who haven't used this. I'm not about to switch from Unix back to Multics (can't anyway). What I like about Unix compared to Multics: The list is long - I'll skip details on obvious things like I/O redirection, portability, and a dynamic user community - these were all correctable faults of Multics. PL/1 is to Multics as C is to Unix. Some deeper differences: --- The use of pipes in Unix, and the way pipes shaped command output is incredibly valuable for building new tools (shell scripts) without C hacking. To do something new on Multics almost requires PL/1 hacking. --- In Multics, each login is one gigantic process. Running a command is almost *exactly* like calling a subroutine. The presence of (conceptually) zillions of static variables leads to outrageous, baffling side effects - irreproducible results are quite common. Standard advice to users with mysterious bugs is "newproc and try again" (newproc zaps all the static variables). Unfortunately, extensive use of environment variables, tty states, etc. in Unix is heading down that path. Sorry this went on so long, but Unix hackers seem to refuse to learn things from other operating systems. BTW, this diatribe was prepared on a VAX/4.2 BSD Unix, then transmitted to Multics (my ARPAnet connection) for blasting off to you-all. Of course, these opinions never existed anywhere else. -- Rex RSanders @ USGS2-Multics Historical note: Primos (Prime minicomputer operating system) is supposed to be a re-implementation of Multics (I've never used Primos).