Megalextoria: Computer Folklore

Home » Digital Archaeology » Computer Arcana » Computer Folklore » Multics vs Unix

Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend

Multics vs Unix [message #425868]

Tue, 17 December 2024 15:41

Anonymous

Karma:

Originally posted by: Lawrence D'Oliveiro

I was reading the introductory “Multics Concepts and Utilization” book
< http://bitsavers.trailing-edge.com/pdf/honeywell/large_syste ms/multics/F01_multicsIntroCourseOct78.pdf>
over at Bitsavers. Multics (the “MULTiplexed Information and Computing
Service”) was, for its time, an extremely ambitious operating system
project. It was first introduced in 1965, in the form of a series of
papers at the AFIPS Fall Joint Computer Conference of that year
< https://www.computer.org/csdl/proceedings/1965/afips/12OmNzS h1au>.

Of course, it took far too long (7 years) to reach production quality.
In that time, a small group of researchers at AT&T Bell Labs grew
tired of waiting, and decided to create their own, less ambitious
system, which they called “UNIX” as a tongue-in-cheek homage to
“Multics”. And the rest, as they say, is history.

But, nevertheless, Multics remained an influential system. There are
even some present-day fans of it gathered at
<https://multicians.org/>. Apparently they have got the OS booting on
an emulator of the original GE 645 hardware. Though it was mostly
written in a high-level language (PL/I), Multics was never a portable
OS; to support its advanced virtual-memory and security features, it
required special processor hardware support which was not common in
those days.

Even today, Multics has some features which can be considered
innovative and uncommon. It may be true that, for example, SELinux can
match all of its security capabilities and more. But some aspects of
its file-protection system seem, to me, to make sharing of data
between users a bit easier than your typical Linux/POSIX-type system.

For a start, there seems to be no concept of file “ownership” as such.
Or even of POSIX-style file protection modes (read/write/execute for
owner/group/world). Instead, all file and directory access is
controlled via access-control lists (ACLs). Directories have a
permission called “modify”, which effectively gives a matching entity
(user, group, process) owner-type rights over that directory; except
that more than one entity can have that permission at once. Thus, a
group of users working on a common project can all be given this
“modify” access to a shared directory for that project, allowing them
all to put data there, read it back again, control access to it,
delete it etc on a completely equal basis. Contrast this with
POSIX/Linux, where every file has to have exactly one owner; even if
they create that file in a shared directory, it still gives the
creating user a special status over that file, that others with write
access to the containing directory do not have.

(Multics also offers a separate “append” permission, that allows the
possessor to create an item in a directory, without having the ability
to remove an item once it’s there.)

One radical idea introduced in Unix was its profligate use of multiple
processes. Every new command you executed (except for the ones built
into the shell) required the creation of a new process, often several
processes. Other OSes tended to look askance at this; it seemed
somehow wasteful, perhaps even sinful to spawn so many processes so
readily and discard them so casually. The more conventional approach
was to create a single process at user login, and execute nearly all
commands within the context of that. There were special commands for
explicitly creating additional processes (e.g. for background command
execution), but such process creation did not simply happen as a
matter of course.

Gradually, over time, the limitations of the single-process approach
became too much to ignore, and the versatility of the Unix approach
won over (nearly) everybody. Multics, however, is of the old school.
More than that, the process even preserves global state, including
static storage, in-between runs of programs, and this applies across
different programs, not just reruns of the same one. For example, in
FORTRAN, there is the concept of a “common block”. If you run two
different programs that both refer to the same common block, then the
second one will see values left in the block by the first one. To
completely reinitialize everything, you need to invoke the “new_proc”
command, which effectively deletes your process and gives you a fresh
one.

One common irritation I find on POSIX/Linux systems is the convention
that every directory has to have an entry called “.”, pointing to
itself, and one called “..”, pointing to its parent. This way these
names can be used in relative pathnames to reach any point in the
directory hierarchy. But surely it is unnecessary to have explicit
entries for these names cluttering up every directory; why not just
build their recognition as a special case into the pathname-parsing
logic in the kernel, once and for all? That way, directory-traversal
routines in user programs don’t have to be specially coded to look
for, and skip these entries, every single time.

Multics doesn’t seem to have this problem. An absolute pathname begins
with “>” (which is the separator for pathname components, equivalent
to POSIX “/”), while a relative pathname doesn’t. Furthermore, a
relative pathname can begin with one or more “<” characters,
indicating the corresponding number of steps up from the current
working directory. Unlike POSIX “..”, you can’t have “<” characters in
the middle of the pathname, which is probably not a big loss.

It is interesting to see other features which are nearly, but not
quite, the same as, corresponding features in Unix. For example, there
is a search path for executables, to save you typing the entire
pathname to run the program. However, this does not seem as flexible
as the $PATH environment-variable convention observed by Unix/POSIX
shells. In particular, it does not seem possible to remove the current
directory from the search path, which we now know can be a security
risk.

Another one is the concept of “active functions” and “active strings”.
These allow you to perform substitutions of dynamically-computed
values into a command line. However, they are not as general as the
Unix/POSIX concept of “command substitution”, where an entire shell
command can supply its output to be interpolated into another command.
Instead of having a completely separate vocabulary of “active
functions” which can only be used for such substitutions, Unix/POSIX
unifies this with the standard set of commands, any of which can be
used in this way.

There are other features of Multics that others more familiar with it
might want to see mentioned (the single-level store concept, where
“everything is a memory segment”, versus Unix “everything is a file”?
I/O redirection based on “switches”—symbolic references to files,
versus Unix integer “file descriptors”?). But then, this long-winded
essay would become even longer-winded :). So if you are interested in
this particular piece of computing history, feel free to follow up the
links above.

In summary, Multics is very much a museum piece, not something you
would want to use today for regular work—not in its original form. But
I think there are still one or two ideas there that we could usefully
copy and adapt to a present-day OS, particularly a versatile one like
Linux.