31

From the naming of operating system only i.e Unix = Uniplexed Information and Computing Service vs Multics = Multiplexed Information and Computing Service, I was first having a misconception that the prime difference between Multics and Unix should be - Multics was Multi access to multi users by multi-programming whereas Unix is multi-* replaced by single. But later on I found that the coining of term Unix was just a pun on Multics. Actually both Multics and Unix can be considered as evolution of the early Time Sharing Systems.

I know that Ken Thompson and Dennis Ritchie started to write a simple system as an alternative to Multics in order to make it possible to run the system with lower hardware resources, which then become Unix.

I think talking about all differences between Multics and Unix would be too broad question. So, I would like to know the major significant technical difference between Multics and Unix.

Clarification (considering comments):

  • By Unix, I mean the orginal Unix of 70s, not modern Unix or BSD
  • Yes, the main difference is simplicity of Unix and I want to know what makes Unix simpler as compared to Multics
  • If differentiating systems is broad, limit the difference between system kernels
Improve this question
14
  • 2
    Still way too broad. These are basically different systems for similar usages one having superficial peeked on the other. There is no coherent and useful answer, so the question will just attract opinions..
    – Raffzahn
    Jul 20, 2020 at 13:27
  • 2
    @Raffzahn how about limiting question to kernels rather than operating systems?
    – Pandya
    Jul 20, 2020 at 13:27
  • 2
    The basic difference is what you already stated - Multics is complex while Unix is simpler. That complexity slowed down development.
    – Brian
    Jul 20, 2020 at 13:35
  • 7
    Good primers on Multics: multicians.org/history.html and multicians.org/features.html A rounded (if perhaps biased) rebuttal to the myths surrounding Multics: multicians.org/myths.html
    – Jim Nelson
    Jul 20, 2020 at 17:09
  • 4
    (I'm not up to writing an answer at this time, sorry) Multics was intended to be a computing utility - the first/a prototype. As a utility it demanded certain features in an extremely robust way: Two such features were reliability (availability) and security. Considering security: Multics had an extremely robust security model, enforced with special hardware features (rings). This made Multics the only system in its time - or for many years after! - certified by the US govt for running multiple security classification levels simultaneously. Unix was not as secure nor was it a focus.
    – davidbak
    Jul 21, 2020 at 14:32

6 Answers 6

Reset to default
35

From this list of Multics features, almost all are recognizable in modern UNIX-style systems in one form or another. Looking for distinctions between is two is made difficult due to the longevity of UNIX and the proliferation of its children.

For me, the most interesting distinction between Multics and UNIX (and most operating systems to follow) was Multics' concept of segments. In Multics, all memory belonged to a segment, whether in core or on disk, and segments could be paged in from and out to disk on-demand. Distinctions between files and RAM are less pronounced than in the UNIX model. Individual segments could be named and assigned attributes.

It's often said that in Multics, it's as if all files are memory-mapped via mmap rather than accessed via fopen/fread/fwrite/fclose. Once a segment was opened or allocated, the program accessed it via memory addressing. This model worked for code and data, and was the basis for Multics' dynamic linking.

From the link above:

A basic motivation behind segmentation is the desire to permit information sharing in a more automatic and general manner than provided by non-segmented systems. Sharing must be accomplished without duplication of information and access to the shared information must be controlled not only in secondary memory but also in main memory.

This meant a single permissions model could be employed for sharing code and data, both in memory and on disk. Segments unified a number of mechanisms that later operating systems would "re-invent" for in-memory vs. on-disk blocks.

Whether this is superior to traditional file primitives (open/read/write/close) is a separate question. And certainly UNIX came to support memory-mapped files, demand paging, shared memory, and dynamic linking. But because Multics blurred the differences between files and RAM from the start, and designed for segments from the ground up, segments were not an optional or advanced feature, they were a fundamental storage paradigm.

(Confession: I've never written for Multics, so I'm only speaking from sources I've read.)

Improve this answer
12
  • 2
    re: it's as if all files are memory-mapped Not 'as if' - they are. Storage is addressed through virtual memory. If you really have to, you can build 'read' and 'write' routines on top of that.
    – another-dave
    Jul 20, 2020 at 21:14
  • 2
    re: Whether this is superior to the traditional file-based model … Multics has a file system; in fact it invented the hierarchical file system. The debate is rather between read/write primitives and memory mapping. Memory mapping is attractive, but it seems to me your file size has to fit in your address space. If it won't, then you (the system designer) have to invent some way to move a 'window' of address space through the file, and suddenly it's not as clean as it was.
    – another-dave
    Jul 20, 2020 at 21:20
  • 3
    By "as if" I meant with w/ mmap() or equivalent; I've clarified that. I never said Multics lacked a file system, and the links I provided indicate it was the first with an HFS. By "file-based model" I meant accessing disk via open/read/write/close primitives rather than memory addressing. (I would think that's clear enough considering the context.) "The debate is rather between read/write primitives and memory mapping" is, in my opinion, only rewording what I said above.
    – Jim Nelson
    Jul 20, 2020 at 22:27
  • 2
    @another-dave - Multics' hardware used 36-bit addresses and words, but unfortunately those 36-bit addresses are split into 18-bit segment number and 18-bit offset, which means the segment size limit is 2^18 words or 1.25MiB. As you suggest, this is too small for practical memory mapped operations; if the processor had been designed with segments as a separate part of the address, allowing a full 36 bits of offset, this would have been fine for any plausible application at the time, but it seems like the need to retrofit segmentation onto a preexisting 36-bit processor crippled the design.
    – occipita
    Jul 21, 2020 at 3:56
  • 4
    @occipita In those days, the segment size was extremely large. Hardly anybody wrote code using megabyte contiguous data structures: only a handful of big machines had that much memory.
    – John Doty
    Jul 21, 2020 at 17:55
16

In Multics, not only was all data mapped into memory, but all binary executables were what we now call DLLs. There was no natural "main program" concept: every binary executable was a compiled function. Processes were extremely "heavy": you got one when you logged in, and everything you ran was a DLL linked into that process. This messed up imported code that assumed static initialization happened every time the "main program" was run.

Unix, with a separate process for each command using standard I/O streams, naturally supported pipelines, an excellent way to factor complex jobs into simple chunks. Pipelines were not technically impossible on Multics, but they were unnatural and difficult to set up.

Improve this answer
8
  • not only was there not a 'main function' but any procedure in a segment could be given a name in the file system - then when you used that name at the command prompt that procedure in that segment was run! (I think the procedure 'signature' needed to make sense...) And that's also the way "linking" worked - you just referred to a name - and it was found in a segment - and the OS "linked" it dynamically ...
    – davidbak
    Jul 21, 2020 at 19:54
  • 3
    @davidbak Signatures weren't checked: as long as the segment contained linkage information, it would run. Experienced multicians put trailing underscores on names of functions not intended to be called from command level to avoid confusion. This provoked resistance from more casual users: "Why is the function sin_() rather than sin()?"
    – John Doty
    Jul 21, 2020 at 20:21
  • Did that also mean, that something the user run could also ruin the whole userspace, which was single process?
    – lvd
    Jul 22, 2020 at 16:04
  • 1
    @lvd The individual user's userspace, yes. And PL/I tended to encourage sloppy pointer usage. When things seem knackered, type "new_proc" and go make yourself a cup of tea while it builds a clean process for you.
    – John Doty
    Jul 22, 2020 at 16:15
  • 2
    "we now call DLLs" Surely you meant "SO".
    – Déjà vu
    Feb 9, 2021 at 7:40
10

A couple other significant differences between Multics and early Unix systems in the security area:

  1. Multics had rings (8 in commercial versions), whereas Unix only had two effective rings -- supervisor and user. This allowed privileged subsystems to be created that would run in process, but be protected from tampering by user (ring) manipulation. This was used for the message system, the mail system, data management, etc. It was not necessary to move these privileged subsystems to the "kernel" (ring-0) because of the additional rings.

  2. Multics had Mandatory Access Control (MAC), in addition to its Discretionary Access Control system based on ACLs. MAC prevented writing "down" from higher privileged levels to lower privileged levels, and reading higher privileged levels from lower ones. It was successfully deployed by the US government to allow users cleared to only Secret to run alongside users cleared to Top Secret, while ensuring that no improper access occurred. It also had a robust system auditing mechanism that ensured audit records for any security-relevant events (such as covert channels, or attempts to write down or read up).

Improve this answer
9

Another significant difference between Multics and Unix was the size of the virtual memory accessible to a process.

It is true that each Multics segment was limited to 255K 36-bit words in length. But each process mapped more than 300 such segments into its address space. About 1/2 of these segments belonged to kernel and inner-ring programming environments. [Yes, the kernel was memory-mapped into each user's process; and its pages were shared among all users of the system.]

160 or more segments were therefore available to the user. Each could contain programs or data. And all of this program memory space was available for use in each process: a total size of more than 40 GB of virtual memory as upper limit on process working set size. Dynamic linking and a flexible segmented pointer register mechanism allowed programs running in many segments to work together as a large subsystem; and to share huge pools of data as well.

There are many operating systems that cannot match that programmable memory space even today. Certainly the early Unix was limited to much less than that amount of space (1- or 2-GB or less). So were processes on IBM OS/370 systems.

Improve this answer
6
  • But this huge virtual memory space was not backed by much physical memory. In 1970, MIT had two Multics machines, a 384 kword machine for users, and a 256 kword machine for developers. A page was a kword, so if the user machine had 20 people logged in, there were <20 pages per user. 20 pages isn't a lot. Call a function? Well, its code probably isn't in the same page as the caller, and its linkage/static data is elsewhere. It calls another function, same problem. Stack and heap are in different segments. Easy to have >20 pages active. Even small, simple programs thrashed.
    – John Doty
    Jul 22, 2020 at 16:59
  • @JohnDoty RAM was expensive in those days. In 1980 MIT-Multics was upgraded to 2.5 MW
    – Barmar
    Jul 23, 2020 at 13:05
  • 1
    Most systems of the 1970s had little physical memory backing the virtual memory subsystem. However, the Multics virtual memory architecture had the advantage of being able to share publicly read-only and read-execute-only pages among all processes on the system. So pages containing commonly accessed subroutines remained in memory for instant use by any running process. This included not only kernel pages (most of which were not wired into physical memory, but paged in when accessed); but also user-ring routines (Multics shell; shared object code snippets - aka pl1_operators_; terminal I/O).
    – gdixon
    Jul 23, 2020 at 13:40
  • "In theory, theory and practice are the same. In practice, they're different." Sharing pages only helps if they have a substantial residence time. I knew a guy whose strategy for logging in to Multics was to attempt to log in from every free terminal in the terminal room, thus creating enough demand that the pages involved would actually be in memory. This reduced login time considerably during peak hours.
    – John Doty
    Jul 23, 2020 at 17:01
  • One revelation came in 1974, when I ported Kildall's PL/M compiler to Multics. It was written in portable Fortran, and not intended for virtual memory or dynamic linking. But once I'd dealt with the static initialization problem, it worked great! A compact, statically linked binary with few calls to DLLs was very quick and responsive. Avoiding page faults and linkage faults was a winning strategy. So, exactly what was virtual memory and dynamic linking doing for the user, at 1970s scale, anyway?
    – John Doty
    Jul 23, 2020 at 17:11
8

All these answers accurately describe the most salient features of Multics. One of the main consequences was that it could only run on specialized hardware.

From a programmer's standpoint, dynamic links had a fantastic use: when debugging a program, you could pause on a breakpoint, fix your code, recompile it, update the link and continue execution (if you use an interpreted language, this may sound trivial, but for compiled languages, this was paradise).

The ring-based protection system was also very nice. It allowed multiple organizations to have projects on the same machine, and each organization to manage the protection of their own projects. Having said that, UNIX' set_uid bit was a wonderful invention (if I had to rate the nicest features of UNIX, I would certainly place it in the top 3).

Improve this answer
1
  • Well, yes, "Multics" as it was implemented could only run on one type of processor, but there's nothing fundamental preventing a very similarly designed operating system from being written for Intel 386; and indeed it would even be theoretically possible to port Multics to a 386. It may even be possible to do something approaching multics-like on a flat address space machine, especialy if it has a sufficiently flexible MMU.
    – Greg A. Woods
    Feb 4, 2021 at 21:13
6

Perhaps the best way of thinking about it is that Unix basically is a minimal implementation of Multics (the ideas in it a least) with absolutely everything that was not strictly necessary to bring up the system stripped out. So segmenting and virtual memory are not really needed (at least to get started). Complex permissions, ACLs or protection rings, quotas, mandatory access controls, ... -- all gone. The idea being to have an absolutely minimal system that could run on minimal hardware, and could be implemented by one person (or a minimal team).

Since a lot of the philosophy behind Unix is the same as Multics, over time pretty much all the features of Multics have made their way into Unix, though some of the "minimalist" philosophy has survived. So one can argue that the only difference between Unix and Multics is that minimalist philosophy

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .