[TUHS] advent of "modern" Unix OS

[Clem Cole via TUHS]

Typo/autocorrect issue:  s/Toth/Thoth/

Sent from a handheld expect more typos than usual


On Sun, Apr 26, 2026 at 5:39 PM Clem Cole <clemc at ccc.com> wrote:

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