[TUHS] advent of "modern" Unix OS

[Clem Cole via TUHS]

below.

On Sat, Apr 25, 2026 at 1:44 PM John Cowan via TUHS <tuhs at tuhs.org> wrote:

> On Sat, Apr 25, 2026 at 12:51 PM Larry McVoy via TUHS <tuhs at tuhs.org
> <https://mail.google.com/mail/?view=cm&fs=1&tf=1&to=tuhs@tuhs.org>> wrote:
>
> > On Sat, Apr 25, 2026 at 04:32:35PM +0000, Andrew Lynch via TUHS wrote:
> >
> > > HiI've been watching the conversation on the various Unix and
> Unix-like operating systems and began to wonder.?? Is there such thing as
> an era of "modern" Unix OS?????
>
Maybe, maybe not.  It really depends on what you value.

>
> "Modern" is a slippery adjective. Its meaning depends on who you are,
> where you are, and what you are doing, and can almost never be pinned
> down to a specific era.  Modern times began around 1800 in Europe and
> North America, later elsewhere; modern art begins around 1863 in
> France, later elsewhere.  And so on.
>
This is an excellent point.  The key is that we have added many different
features over time (some swiped from other systems, some much more
"UNIX-like" than others). Each of them has contributed to the
"improvement."

In the late 1970s and early 1980s, John Mashey, as part of the ACM National
Lecture series, gave a series of talks called "*Small is Beautiful*."  It's
really too bad so much of what he said got lost, but the big thing he
observed was what we were calling the "Unix Philosophy" of *many small
programs that did one thing well*.   Rob Pike made a similar point with his
"*cat -v considered harmful"* paper.   But the point here is that, because
of the PDP-11's address limits, large systems had to be decomposed into
small, specialized tools that worked together.

Before I go further, I need to remind folks of some key facts that are
often forgotten, particularly in "modern times:"

   - As Turning points out, any computation can, in theory, be done with
   something as simple as a Turing Machine.
   - All VM provides is a hardware mechanism to allow the overlay burden to
   move from the application programmer to the OS,"

In fact, the DEC team in MKO-based TIG [well, Fred Cantor primarily, but I
think Bill Shannon, Armando Stettner, and Jerry Brenner helped him]
developed and DEC gave away as part of the V7M [
https://www.tuhs.org/Archive/Distributions/DEC/Jean_Huens_v7m/], support
for overlays - allowing programs later the 64K to run on any PDP-11
(separate I/D of the 45/70 class machines only made it easier).  Fred's
work would enable 2.8BSD and later releases to start moving programs from
the 32-bit Vax-based 3BSD and later releases back to the 16-bit PDP-11.

Frankly, once VM was introduced to UNIX, the "small is beautiful" ideas quickly
were forgotten.

So the introduction of large address spaces made programming >>some<< tools
more straightforward, although, since it >>was<< easy, little thought was
given to alternatives (and I add, that "feature" of so-called "modern"
systems is often not a win.

So is "modern" about removing the need for the programmer of user-mode
programs to use overlays?

As Larry suggested, how the VM was implemented and what features it offered
(mmap and friends) also demarcate more "modern" UNIX implementations.
Instead of saying more, I'll point you to  "UNIX Systems for Modern
Architectures: Symmetric Multiprocessing and Caching for Kernel
Programmers" by Curt Schimmel [ISBN-13: 978-0-201-63338-2].    The point
here is that it was not just VM that was being added.

Is modern defined as when more than one execution core is available to the
programmer?

For a bit of brevity, one of the other threads going on directly in the
UNIX community, from the mid-70s to the early 1980s, was physical file
systems and features that support everything from redundancy to adding
storage on the fly, *etc*.   The point being that these "modern ideas" go back
a long time, and UNIX also had implementations of them.
Does modern UNIX require these FS features?

Clearly, another important addition was the Networking Stack.   The first
formal network stack I knew about for UNIX was from V6.  The UoI NCP was
first [https://www.rfc-editor.org/rfc/rfc681.html and
https://www.tuhs.org/Archive/Distributions/Early_Networking/NOSC].  Note:
Steve Holmgren published RFC681 on the 14-May-75.  The UoI NCP was also
used elsewhere, including by Rand and NOSC (from which this copy comes).
The important thing is that Steve's NCP implementation used traditional
Unix file system semantics to open a connection [the example in the
IllinoisNCP.nr in the tarball, takes an example of opening a connection to
the MIT Multics system by opening "/dev/multics."  As expressed in Kelley,
Balocca, Kravitz paper:* "A Network Unix System for  the ARPANET: Volume 1
- The Network Control Program"* [
https://ia800707.us.archive.org/17/items/networkunixsyste243kell/networkunixsyste243kell.pdf
]

   - user interfaces to the NCP are clean and simple (only one system call
   added(sendins) and one system call (open) expanded)

It should be noted that folks at Rand added a new communication paradigm to
UNIX during this period: "Rand Pipes" [FIFOs, which System V picked up
years later]. This feature introduced the idea of "Named Pipes," which
addressed a key limitation of the original "anonymous" pipes: the inability
for unrelated processes to communicate. The Rand developers extended the
kernel to allow pipes to have a name in the filesystem. Thus, permitted any
two unrelated processes with the right permissions to "meet" at a named
pipe and exchange data.

Around the same time, MIT added ChaosNet to its UNIX implementations: [
https://gunkies.org/wiki/Chaosnet ]. Sadly, I can't point to
implementations, but if we can find them, I'll try to get them added to the
"Early_Networking" part of the TUHS archives.

In November of 1980 3COM descrtibed there first product, UNET, a complete
TCP/IP implementation for Research Seventh Edition [
http://bitsavers.informatik.uni-stuttgart.de/communications/3Com/3Com_UNET_Nov80
.pdf ].   Somewhere in my archives, I have the mailing envelope for its
first customer shipment: Dec 32, 1980, to me in Tek Labs [note the date -
they had funding tied to meeting FCS by the end of 1980].  Sadly, we seem
to have lost the source to time, but if you look at the presentation, you
will see the same core architecture as the V6, NCP stack from UoI.

A few months later, in the summer of 1981, under a DARPA Contract, BBN would
add TCP/IP to 4.1BSD, which had only been released in June. [
https://www.tuhs.org/Archive/Distributions/Early_Networking/BBN].

So is modern UNIX defined by a networking stack?   Or is it a specific
protocol or networking interface?

Looking deeper here, when CMU released Accent in December 1981 [which was
itself heavily based on ideas from the earlier RIG system at the University
of Rochester, as well as Mike Malcom's Toth System at Waterloo], better
interprocess communication was being considered.   Accent and Mach called
them "ports," but the key point is that they are a new kernel subsystem
that hands out a way for processes to communicate.  Bill Joy does the same
thing with his idea, "sockets", but does at least somewhat make them
UNIX-like in allowing traditional read/write to work on them,

By 1982-1983, the development time frame for BSD 4.1a, 4.1b, 4.c, and
finally 4.2BSD in August of 83, little in that release from Networking to
its File System or even its new messaging scheme is actually new to the
community, but is now bundled together for the first time.  And in Henry's
famous words: "4.2 is just like UNIX, only different."    Instead of using
traditional UNIX I/O semantics, a new idea was added: the UNIX socket.

Yet another vector in the "Modern" UNIX is the user interface?   Windowing
was added to UNIX in a number of different ways.  So does "modern UNIX"
start when X-Windows become ubiquitous?

One last thread - does "Modern UNIX" mean it has to be reimplemented?
Another thread has been hashing out the many different times and ways that
ideas Ken, Dennis, and the team in MH put together into something called
UNIX have been re-envisioned or simply recreated using new code.

So to close this down.   I'm not sure there is anything as a modern Unix
that can be uniformly agreed.  Any one of the items I described, and there
are no doubt many others that I did not, was important in moving Unix
"forward" in some manner.  But depending on how you value any one feature, be
it memory system, interprocess communications, network stack, user
interface, or whatever, you then have to consider the implementation of
that feature.

Clem