spencer@ttidcc.UUCP (David Spencer) (10/22/85)
Unix is based on Multics, right? Well, what did Multics have that Unix doesn't have, and what does Unix have that Multics didn't?
gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (10/23/85)
> Unix is based on Multics, right? Not exactly, but some of its ideas were inspired by Multics. > Well, what did Multics have that Unix doesn't have, Organick wrote a book about Multics; look it up. Perhaps the three most noted were protection rings, memory files, and dynamic linking. > and what does Unix have that Multics didn't? Small size (originally), good notation for using pipes, C, troff, popularity, portability.
RSanders.Pascalx@USGS2-MULTICS.ARPA (10/31/85)
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).
Raeburn@MIT-MULTICS.ARPA (Ken Raeburn) (11/04/85)
>Unix is based on Multics, right? Well, what did Multics have that >Unix doesn't have, and what does Unix have that Multics didn't? I'd like to add a few things to what Rex Sanders (RSanders@USGS2-Multics) said on the issue, although they're a bit one-sided. I've had more experience with Multics. ... Temporary files have been one of the issues buzzing around the net lately. Multics eliminates some of the problems of temporary files that have been discussed. Since all of Multics memory is located in the file hierarchy, each user's process is allocated a "process directory" in which various things such as stacks and temporary files are kept. The directory is inaccessible to anyone but yourself or a sufficiently priveleged system maintainer. ... Access control is much more complicated on Multics than on Unix, giving it some advantages and disadvantages. Each user in each login session has an identifier associated with him that tells his name, the project (sort of similar to groups) that he is logged in under, and whether he is logged in interactively, as an absentee job (sort of like a batch job or a Unix "at" job), or a daemon (more explanation on that later). Access is controlled by any or all of these, listed in an Access Control List. ACLs can get extremely long (I'm not sure exactly how long, I've never reached the limit), and therefore can be extremely precise about who gets what access. So you can have yourself, Joe, people on the SysAdmin project, and Larry's absentee jobs able to write to a file, prevent Curly from even reading it, and let everyone else read it at will, simply by setting up the ACL correctly -- which is very easy to do. Multics does not have "setuid" or "setgid" programs. Instead, it uses ring protection. Some processors have two states, a user state and a supervisor state. The hardware Multics runs on goes beyond this. A user's process can be running in any ring from 0 to 7. Users start out in ring 4 generally, and can call "gates" to execute one of a limited set of subroutines in an inner (more priveleged) ring, after which the process returns to the outer ring. This leads to segments called "mailboxes" being protected so that they can be manipulated in ring 1 only, with a number of gate entrypoints to read data out or put it in in particular formats. Mail on Multics is secure. You cannot fake a message from another user without going through the network SMTP handler, which is in itself insecure. (Just telnet to your machine's port number 25 if you're on the arpanet, and talk to your own mailer. If you know what to do, you can easily fake it out.) There is also an access-class attribute, but I don't think anyone outside of the DOD uses it. ... A "process" in Multics is a lot more involved than in Unix. There is no facility for creating a new process of your own or anything like that. Every program that gets run must be run in a process with a userid, project, etc. There is a particular type of process, called a daemon, which gets logged in with no terminal attachment. It's purpose is to run the various programs and servers that you might find in an "/etc/rc" file. This includes any network implementation, unfortuantely. Here at MIT-MULTICS, any TCP connections have to be handled through a daemon (our name for it is "Internet"). This causes problems sometimes. The "PATH" idea is used more in Multics. There are "search rules" used to find programs and subroutines. There are also "search paths" for finding info files, search paths for finding include files, etc. In Unix, if you want to add a directory to be searched by "man", you need a revised program. (**BTW, if anyone has a program that does something similar on Unix, please send it to me. We have a need for something like this here at MIT with some of the software development groups, each having directories for binaries, info, etc, separate from all the others.**) Unix does have some things which I would like to see in Multics. One of these is relatively easy multi-tasking. There is some makeshift software to do this on Multics, but it doesn't quite cut it. (Though there is more in development that we haven't got here at MIT yet.) Another is the ability to temporarily give a user the priveleges of another (via "su"), although that's not such a big issue. I have not had much experience with either system (about a year with both), but so far, I have found Multics easier to use. The user interface, although there's quite a bit of it to get used to, and many people I know don't like it, seems more reasonable to be. Which makes more sense, "accept_messages", or "biff y"? Also, error messages are a lot more helpful. A "linkage_error referencing foo_|bar" is a lot easier to understand and track down (once you understand the format) than "Segmentation fault (core dumped)", is it not? (Yes, I know you could try to get some info out of the core image, but can you resume its execution afterwards?) And while PL/1 may be rather wordy, I can read it an awful lot easier than some of the C code I've seen (no flames, please). -- Ken Raeburn (Raeburn.PDO@MIT-MULTICS) ---------------------------------------------------------------- - - - The opinions above are mine, and might be totally - - unrelated to those of anyone you will ever meet. - - - ----------------------------------------------------------------