Retrocomputing Asked on August 25, 2021
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):
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.)
Correct answer by Jim Nelson on August 25, 2021
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
Answered by Chris Dodd on August 25, 2021
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).
Answered by Stuck on August 25, 2021
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.
Answered by gdixon on August 25, 2021
A couple other significant differences between Multics and early Unix systems in the security area:
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.
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).
Answered by eswenson on August 25, 2021
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.
Answered by John Doty on August 25, 2021
Get help from others!
Recent Questions
Recent Answers
© 2024 TransWikia.com. All rights reserved. Sites we Love: PCI Database, UKBizDB, Menu Kuliner, Sharing RPP