🚀 go-pugleaf

These Multics interchanges are enchanting; such a delightful
combination of thinly-veiled envy, nostalgia, and the occasional
gloriously stupid claim.

About three years ago there was another such discussion, and I wrote
a short essay on what people were saying then.  I can't remember
if I ever posted it; probably not, since it sort of trails off
without ending in much of a conclusion.  Perhaps it's time to trot
it out now and get some (more?) use out of it.

	Dennis Ritchie
	dmr@research.att.com
	att!research!dmr

Subject: who needs Multics?  [written early 1987]

I've been following the Multics discussions with considerable interest.
I was involved in Multics at an early stage and retain strong, though
by now sightly fuzzy impressions of it.  Obviously, they have been
influenced by subsequent heavy involvement in Unix.

One might characterize Multics as a system that tried to do everything,
that had a grand conception of a new order for the world, and then
had to contract considerably as various realities intruded.  Ultimately,
it seems, it has had to contract into nothing, although during its
lifetime, it did achieve a great many of its design goals.  And it
has been quite influential.

Unix, by contrast, started with a modest but exceedingly well-conceived
design that has, so far at least, been able to accommodate enormous
expansion in various directions, only some of which aim towards
the most characteristic features of Multics.

We have always been assiduous in acknowledging a strong debt to
Multics and its immediate predecessor (CTSS); still, many components
of this connection are by now so thoroughly assimilated into the
culture that it is hard even to see them.  Hugh LaMaster mentions
TSS, IBM's answer to Multics.  TSS did emulate some aspects of Multics;
in particular it approximated the single-level store discussed below,
but in other, crucial aspects it utterly missed the point.  For example, TSS
poisoned the user (and program) interface with JCLish, IBMish DD cards
describing all sorts of wretched, irrelevant facts about files, instead
of doing the job properly.

The most characteristic feature of Multics, the design aspect that
strikes one most strongly, is indeed the single-level store: the
notion that files (in a directory hierarchy) are identified with segments
(parts of the address space).  Other systems have done this since
and perhaps even before, but Multics is the system that tried most
publicly and boldly.  I think the effort was admirable, was worth
trying, and may still hold life, but seems now to be flawed.

Even though the underlying mechanisms were unified, there are really
two separate aspects to the single-level store: program and data.

The program aspect is the dynamic linking facilities that have
been discussed (and envied) in this forum.  Briefly, it means that
use of a name in call-position `func()' causes the system to
search, at runtime, in specifiable places, for a file containing the
appropriate entry point, to attach the file to the address space,
and to complete the linkage to the function.  This is slow the first
time, rapid thereafter.

All in all, this was made to work well, and the effect is more
elegant, transparent, and general than the `shared libraries'
that one finds in many systems.  It was however never fast enough in
practice to be the universal mechanism for linking; very early
in the game, the `binder' had to be introduced that bundled
together libraries and commands in advance, to avoid the overhead of
doing it every time the command was executed.

At least in the early days, another, and important, Multics compromise
had especially evil consequences.  The original design called for each
command to be executed in a new process, as is done in Unix.  This was
much too slow, largely owing to dynamic linking.  (I remember the time
to start a new process going from perhaps 20 CPU minutes, to a few
seconds at the time we left the project.)  Therefore, in Multics all
one's commands execute in the same process, and use the same address
space.  This was fine so long as you were not changing any of the
programs you were running.  Say you recompiled the sine routine and ran
your test program again.  At best, the program would continue to use
the old sine because that version was already linked into your address
space (this was merely confusing); at worst, the test program would
jump into the wrong place in the new sine routine (the segment
contents were replaced but the old offset remained in the linkage
table).  This effect was known as "the KST problem" (KST= Known Segment
Table) and the result was called "being KSTed."  I am certain that it
was papered over in later versions of the system, and modern Multics
users may not even be aware of the problem, but it was a real pain for
us.  (Our general fix was to type hcs_$newproc and go get a cup of
coffee.)

In spite of the problems (they were eventually alleviated) the
dynamic linking of programs probably can be counted a success.
I don't thing the same is true of data.  It is generally a pleasant,
and almost universally applicable abstraction to imagine
other programs appearing, and thereafter statically living in your
own program's address space.  The same abstraction simply fails
in the case of data.

Other people have pointed out the problems already; I'll reiterate:
1) Much data comes from devices that cannot convincingly be mapped
   (terminals, tapes, raw disks, pipes)
2) In the state of technology, even plain files cannot be mapped
   properly, because they are too big
(I might need some correction on the second point, but I don't
see how the Multics machine could deal transparently with
segments larger than 256KW.)

What actually happened was that, for the most part, people
avoided the "single-level store" for data and used sequential
IO via read and write calls.  The Multics IO system was quite
snazzy, and one of the first things we did with it was to write
the "fsim"-- the file system interface module, that initiated your
segment and put/got bytes in it, and did all the
grotty but necessary things like set_bit_count.  In other words,
as a "feature," occasional use of data file mapping was convenient,
but as an organizing principle, as a way of life, it was a bust;
it was something that had to be programmed around.