Skip to main content
reword "file-based model" for clarification
Source Link
Jim Nelson
  • 3.8k
  • 1
  • 20
  • 34

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 the traditional file-based model 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.)

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 the traditional file-based model 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.)

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.)

mmap reference
Source Link
Jim Nelson
  • 3.8k
  • 1
  • 20
  • 34

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 the traditional file-based model 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.)

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 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 the traditional file-based model 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.)

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 the traditional file-based model 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.)

Source Link
Jim Nelson
  • 3.8k
  • 1
  • 20
  • 34

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 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 the traditional file-based model 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.)