These are better than UNIX, but still worse than Multics. The way it works in Multics is that there is no swap. Instead, each segment is associated with a named file. This file can grow or shrink and has access permissions. All segments have at least one name, including code and stack segments. A process is just a collection of mapped segments. This promotes binary data structures and using ordinary machine instructions to get and set variables instead of having to parse text. Segments also contain pointers, so you can have an actual tree with pointers instead of text formats like XML, or even a garbage collected heap. Under a real virtual memory system, millions of lines of UNIX bullshit do not need to exist and actually get in the way and reduce productivity. This technique is possible on 16/32-bit x86 protected modes and was the way Intel intended it to be used.
https://multicians.org/daley-dennis.html
>A segment is treated as procedure if it is intended to be accessed for instruction fetch by a processor. Other segments (including e.g. a source program file) are considered to be data. Instruction fetch references to procedure segments are allowed, as are internal data reads. Writing into a procedure segment is normally considered invalid and is prohibited by the system. (In certain cases, reading of a procedure segment by another procedure may also be prohibited while execution is allowed.) Thus procedure segments are non-self-modifying or pure procedures. Instruction fetches from data segments are invalid, and any data segment may be write protected. The overall design of Multics protection mechanisms is discussed by Graham.[7]
>The Multics directory structure [2] is a hierarchical arrangement of directories that associates at least one symbolic name (but perhaps many) with each segment. These names have meaning that is invariant over all processes in existence. Figure 1 portrays the Multics concept of a process as a virtual memory made up of segments selected from the directory structure.
https://multicians.org/multics-vm.html
>As experience with use of on-line operating systems has grown, the need to share information among system users has become increasingly apparent. Many contemporary systems permit some degree of sharing. Usually, sharing is accomplished by allowing several users to share data via input and output of information stored in files kept in secondary storage. Through the use of segmentation, however, Multics provides direct hardware addressing by user and system programs of all information, independent of its physical storage location. Information is stored in segments each of which is potentially sharable and carries its own independent attributes of size and access privilege.
>The fundamental advantage of direct addressability is that information copying is no longer mandatory. Since all instructions and data items in the system are processor-addressable, duplication of procedures and data is unnecessary. This means, for example, that core images of programs need not be prepared by loading and binding together copies of procedures before execution; instead, the original procedures may be used directly in a computation. Also, partial copies of data files need not be read, via requests to an I/O system, into core buffers for subsequent use and then returned, by means of another I/O request, to their original locations; instead the central processor executing a computation can directly address just those required data items in the original version of the file. This kind of access to information promises a very attractive reduction in program complexity for the programmer.
Raise your hand if you remember when file systems
had version numbers.
Don't. The paranoiac weenies in charge of Unix
proselytizing will shoot you dead. They don't like
people who know the truth.
Heck, I remember when the filesystem was mapped into the
address space! I even re<BANG!>
