Multics

Multics (Multiplexed Information and Computing Sservice) It was one of the first timesharing operating systems and had a great influence on the development of subsequent operating systems.

Description

Initial plans and development of Multics began in 1964. Originally, it was a cooperative project led by American scientist Fernando J. Corbató of MIT, with the participation of General Electric Corporation and Bell Laboratories. Bell Laboratories left the project in 1969, and in 1970 General Electric's computing business, including Multics, was acquired by Honeywell.

Multics was conceived as a commercial product by General Electric, and achieved this feat for Honeywell, but was not a huge success. However, he had a great impact on the field of computing thanks to his many new and valuable ideas. Although he received much criticism in his day [1], history has shown that they were unfounded.

A large number of features were intended to provide high availability, so that computing service would match telephone services and the electrical grid. To achieve this achievement, a modular structure was used in both software and hardware, and the system could grow simply by adding more resources - computing power, main memory, disk storage, etc. Access control lists on each file provided a flexible method of sharing information, in addition to the required privacy. It contained different standard mechanisms to allow engineers to analyze system performance, as well as various mechanisms for performance optimization.

MULTICS contributions

Multics was one of the first operating systems in which a single storage level for data access was implemented, doing away with the clear distinction between files (called segments in Multics) and processes in memory.

Until then, a process's memory consisted only of segments that were allocated in its address space; to read or write to them, the process simply used normal CPU instructions, and the operating system took care to ensure that all modifications were saved to disk.

In the terminology of the POSIX standard, it was as if each file was allocated; however, in Multics there was no concept of process memory, separate from the memory used to hold maps to files, as Unix does. All of system memory was part of some segment, which appeared in the file system; including process temporary memory, kernel stack, etc. This was a practical drawback, given the particularities of the hardware architecture of the machines it ran on, and not the basic concept, it was that the size of the segments was limited to 256K 36-bit words, roughly equal to the current 1MB., and therefore extra code had to be used to work with files larger than this, called multi-segment files. In the days before large databases, and later large bitmap graphics, this limitation was not often encountered.

Another contribution from Multics was the concept of dynamic binding, through which a running process can request that other segments be added to its address space. These segments can include code that can be executed. With this feature available, applications automatically used the latest version of any external routines they called, these routines were in other segments, which were dynamically linked only when a process attempted to execute them. Since different processes, belonging to different users, could use different search rules, different users could automatically end up using different versions of the external routines.

Equally important, with proper configuration of the Multics security features, was that code in the other segment could gain access to data structures held in a different process.

Thus, to interact with an application running partly as a daemon (in another process) a user process simply makes a normal procedure call to a segment of code that it was dynamically linked to (a segment of code that implements some operation associated with this daemon). The code in this segment can then modify the data held and used by the daemon. When the action necessary to start the request is complete, a simple process return instruction returns control of the user process to user code.

These two ideas are still used in most operating systems, regardless of the rapid and enormous advancement made in the field of computing since the 1960s.

Multics also supported very aggressive online reconfiguration; CPUs, memory banks, disk drives, etc. they could be added and removed as the system continued to function; entering service, or being removed when necessary. It was common practice in the MIT system, where most of the early software development was done, to split the system; that it was a multiprocessor system; into two separate systems, by removing enough components to form a second system, leaving the rest still running the logged in users. Checks on the developed software could be performed on the second machine; when the tests were finished, the components of the second system were added back into the main system, without having to shut it down at any time. Since multiple CPUs were supported, it was one of the first multiprocessor systems.

Multics was also notable for its innovative emphasis on its design for computer security, and was possibly the first operating system designed as a secure system from its inception. Regardless of this, early versions of Multics were exposed, not once, but repeatedly.

This led to more work to improve security that mapped out modern security techniques, and made systems much more secure; With the adoption of second generation hardware, with hardware support for security rings (a multi-level refinement of the master mode concept), intrusions became very rare.

In addition to being the first operating system to provide a hierarchical file system, file names could be almost of arbitrary length and syntax; given a file or directory it could have several names (typically one long and one short); symbolic links between directories were also supported.

He was the first to use the concept, now a standard feature, of having one stack per process in the kernel, with a separate stack for each security ring. It was also one of the first systems written in a high-level language called PL/1, although the Burroughs B5000 system, which used ALGOL, preceded Multics.

History of the project

Multics was initially developed for the General Electric GE-645 mainframe computer, a 36-bit system; it was later supported by the Honeywell 6180 series of machines.

The staff at Bell Laboratories left the project in 1969. Some of the people who had worked on its development went on to create the UNIX operating system. Although in a superficial way, UNIX shows the influence of Multics in many areas, including the name of the commands. However, the design philosophy was very different, focusing on keeping the system as small and simple as possible, thereby correcting what was seen as a deficiency of Multics. The name "Unix" (originally "Uniks", for "UNIplexed information and Computing Service" instead of "MULTIplexed Computer and Information Service") is a hack of "Multics" 3. 4;. The U in UNIX is rumored to stand for "Uniplexed" in opposition to the concept "Multiplexed" of Multics, highlighting the intention of the designers to reject the complexity of Multics in favor of a more direct practical approach.

The American company Honeywell bought the computing division of General Electric, launched an improved hardware base, and continued development of the system until 1985. Some 80 installations worth several million dollars were made, in universities, industries, and administrations. The French university system had several installations in the early 1980s. After Honeywell dropped support for Multics, users migrated to other systems, including other UNIX distributions. The last machine to use Multics was shut down on October 31, 2000, at the Canadian Ministry of Defense.

Currently, the Multics source code has been released by MIT and can be downloaded from their page.

Influence on other projects

Unix

The design and features of Multics slightly influenced the Unix operating system, which was originally written by two Multics programmers, Ken Thompson and Dennis Ritchie. Multics' superficial influence on Unix is evident in many areas, including the names of some commands. But the internal design philosophy was quite different, focusing on keeping the system small and simple, thus correcting some perceived shortcomings of Multics due to its high resource demands on the limited computer hardware of the day.

The name Unix (originally Unics) is a pun on Multics. The U of Unix is rumored to stand for uniplexed as opposed to the multiplexed of Multics, further underscoring the designers' rejection of the complexity of Multics in favor of a simpler approach feasible for smaller computers. (Garfinkel and Abelson cite an alternate origin: Peter Neumann at Bell Laboratories, seeing a demonstration of the prototype, suggested the pun UNICS - pronounced "eunuchs" - as a "castrated Multics", although Dennis Ritchie is said to have denied this.)

Ken Thompson, in a 2007 transcribed interview with Peter Seibel, refers to Multics as "overdesigned and overbuilt and over everything. It was almost unusable. They [Massachusetts Institute of Technology] keep saying it's a monster hit, but it clearly wasn't. On the influence of Multics on Unix, Thompson stated that "the things I liked enough (of Multics) to stick with were the hierarchical file system and the shell - a separate process that can be substituted for another. process".

Dennis Ritchie wrote that UNIX design was influenced by CTSS

Other operating systems

The Prime Computer operating system, PRIMOS, was called "Multics in a Shoebox" by William Poduska, one of the company's founders. Poduska later went on to found Apollo Computer, whose operating systems AEGIS and later Domain/OS, sometimes called "Multics in a Matchbox," extended the design of Multics into a graphical workstation environment. strongly networked.

The Stratus VOS operating system from Stratus Computer (now Stratus Technologies) was heavily influenced by Multics, and both its external user interface and internal structure bear many similarities to the previous project. Multics' high reliability, availability and security features have been extended in Stratus VOS to support a new line of fault-tolerant computing systems that support secure and reliable transaction processing. Stratus VOS is the most directly related descendant of Multics that is still in active development and production use today.

The Multics protection architecture, which restricts the ability of code at one system level to access resources at another, was adopted as the basis for ICL's VME operating system security features.

Commands

The following is a list of programs and commands for common computing tasks that are supported by the Multics command line interface."Multics commands". </ref>

• apl
• ceil
• change_wdir (cwd)
• Cobol
• copy (cp)
• I
• emacs
• floor
• fortran (ft)
• gcos (gc)
• help
• home_dir (hd)
• if
• list (ls)
• login (l)
• logout
• ltrim
• e-mail (ml)
• pascal
• pl1
• print (pr)
• print_wdir (pwd)
• runoff (rf)
• rtrim
• draw
• Teco
• trunc
• where (wh)
• who
• working_dir (wd)

Retrospective

It is more than surprising to discover that the kernel of this multi-processor mainframe operating system, which was criticized in its early days for its size and complexity, took up 135 kB of code. The first MIT GE-645 had 512K words of memory (2 MB), so the kernel used only a small portion of Multics' main memory.

Measured another way, the entire system, including not only the operating system, but also the complex PL/I compiler, user commands, and subroutine libraries, contained approximately 1500 source code modules with a length They each averaged about 200 lines of source code, and were compiled to produce approximately 4.5 MB of procedural code, which, although it may seem small today, was very large by the standards of the time.

Multics compilers generally optimized code density rather than execution speed, for example small subroutines called operators were used for frequent code sequences, making direct comparisons with object sizes code on most modern systems does not make sense. The high code density was a good optimization option for a multi-user system with expensive main memory, such as Multics.