> Sockets (which btw, totally SUCK PUS) were coded into things
> and even (YECHH) made POSIX and IETF spec status. Streams didn't stand
> a chance.
The question that originally pulled me into researching Unix networking 1975-1985 was more or less “how did we end up with sockets?”. That was 7 years or so ago, I now have a basic feel for how it came to be, and I also have better appreciation of the trade offs. What is the most “Unixy” of networking (as in the API and its semantics) is not something with an easy answer.
If I limit myself to the 1975-1985 time frame, I see three approaches:
1. The API used in Arpanet Unix, which was also used by BBN in its first reference implementation of TCP/IP
2. The BSD sockets API, in two flavours: the Joy flavour in BSD4.1a, and the Karels flavour in BSD4.1c and later
3. The Ritchie/Presotto IPC library / API from V8/V9. This evolved into SysV networking, but the original is the clean idea
At a high level of abstraction, there is a lot of similarity; close-up they are quite different. I like all three solutions!
One thing that struck my attention was that the Ritchie/Presotto IPC library has the concept of “calling” a host and the host/network can reply with a response code (“line busy”, “number unknown”, “not authorised”, etc.). BSD sockets do not cover that. I guess it derives from Spider/Datakit having that functionality, and Arpanet / tcp-ip not having that (resorting to a connection ‘reset’ or dead line instead). Sockets have a more elegant solution for connectionless datagrams (imo), and for the same reason I guess.
Sure, sockets has too much of the implementation sticking through the abstractions, but it is IMO not a bad design. That it became dominant I think is in equal measure due to economics and due to being “good enough”.
If someone has a proposal for a network API that is cleaner and better than what was out there, and would have worked with the hardware and use cases of the early 80’s, I’m all ears. But maybe better on COFF...
Paul
Wholeheartedly agree with the observations on forgotten versions, lack of source and a smaller pool of people back in the day.
It is not just the Research versions, also the internal AT&T versions and the base System V versions get little attention. Same reasons I think.
Luckily, these days the sources are available (although in the case of SysV of unclear legal status).
Part of the problem I think is that it is not well known what innovations are in each version. About 2 years ago I did a lot of spelunking through the V8 source and with the help of this list could come up with a list of highlights for V8 (text is now on the TUHS V8 source web page).
Never had the time to do that for V9. I think it was mentioned that it had a new filesystem with a bitmap free list. Also, it seems to have a lot of cleaned-up implementations of things that were new and rough in V8.
No clue what was new in V10.
Similar with Unix 3, Unix 4 and Unix 5. I’m thrilled that the docs for Unix 4 showed up recently. In these doc’s there is no material on IPC. From this I think that the IPC primitives from CB-Unix did not get merged in Unix 4, but only in Unix 5 (in a reworked form).
Personally, I’m still working (off and on) on recreating the Reiser demand paging system. To keep it interesting I’ve now got Sys III running on a small RISC-V board, and when I find another time slot I’ll try to add Reiser paging to it.
So the forgotten versions are only mostly forgotten, not totally forgotten :^)
Maybe make www.tuhs.org a CNAME for tuhs.org?
Surely a site devoted to the history of UNIX should use a
real link, not a symbolic one.
Norman `Old Fart' Wilson
Toronto ON
Hi all, we have a new addition to the Unix Archive at:
https://www.tuhs.org/Archive/Documentation/Manuals/Unix_4.0/
This is the documentation for Unix 4.0 which preceded System V. The
documents were provided by Arnold Robbins and scanned in by Matt Gilmore.
Cheers, Warren
Announcing the Open SIMH project
SIMH is a framework and family of computer simulators, initiated by Bob
Supnik and continued with contributions (large and small) from many others,
with the primary goal of enabling the preservation of knowledge contained
in, and providing the ability to execute/experience, old/historic software
via simulation of the hardware on which it ran. This goal has been
successfully achieved and has for these years created a diverse community
of users and developers.
This has mapped to some core operational principles:
First, preserve the ability to run old/historically significant software.
This means functionally accurate, sometimes bug-compatible, but not
cycle-accurate, simulation.
Second, make it reasonably easy to add new simulators for other hardware
while leveraging common functions between the simulators.
Third, exploit the software nature of simulation and make SIMH convenient
for debugging a simulated system, by adding non-historical features to the
environment.
Fourth, make it convenient for users to explore old system environments,
with as close to historical interfaces, by mapping them to new features
that modern host operating systems provide.
Fifth, be inclusive of people and new technology. It's serious work, but it
should be fun.
Previously, we unfortunately never spent the time to codify how we would
deliver on these concepts. Rather, we have relied on an informal use of
traditional free and open-source principles.
Recently a situation has arisen that compromises some of these principles
and thus the entire status of the project, creating consternation among
many users and contributors.
For this reason, a number of us have stepped up to create a new
organizational structure, which we call "The Open SIMH Project", to be the
keeper and provide formal governance for the SIMH ecosystem going forward.
While details of the structure and how it operates are likely to be refined
over time, what will not change is our commitment to maintaining SIMH as a
free and open-source project, licensed under an MIT-style license as shown
on the "simh" repository page.
It is our desire that all of the past users and contributors will come to
recognize that the new organizational structure is in the best interests of
the community at large and that they will join us in it. However, this
iproject as defined, is where we intend to contribute our expertise and
time going forward. At this point, we have in place the following,
although we foresee other resources being added in the future as we
identify the need and execute against them:
A Github "organization" for the project at https://github.com/open-simh
A Git repository for the simulators themselves at
https://github.com/open-simh/simh
The license for the SIMH simulator code base, found in LICENSE.txt in the
top level of the "simh" repository.
The "SIMH related tools" in https://github.com/open-simh/simtools. This is
also licensed under MIT style or BSD style open source licenses (which are
comparable apart from some minor wording differences).
A "SIMH Steering Group" -- project maintainers and guides.
The conventional git style process is used for code contributions, via pull
request to the project repository. The Steering Group members have approval
authority; this list is likely to change and grow over time.
By formalizing the underlying structure, our operational principles and
guidance can best benefit the community. These are being developed and
formalized, with a plan to publish them soon.
We have used our best judgment in setting up this structure but are open to
discussion and consideration of other ideas, and to making improvements.
Many of us have been part of different projects and understand that past
mistakes are real. We have tried to learn from these experiences and apply
the collected wisdom appropriately. We desire to hear from the community as
we update and refine the operating structure for the Open SIMH project.
We hope for your patience and look forward to your support as we work to
refine the organization and be able to provide this wonderful resource for
anyone to use as we continue to evolve the technology provided by the SIMH
system.
The SIMH Steering Group
Clem Cole
Richard Cornwell
Paul Koning
Timothe Litt
Seth Morabito
Bob Supnik
ᐧ
ᐧ
ᐧ
Hi all, I think it's time to move the (no longer) SIMH discussion over to
the COFF mailing list. The S/N ratio is dropping and we are straying too
far away from the Unix side of things.
Many thanks!
Warren
> https://www.tuhs.org/Archive/Documentation/Manuals/Unix_4.0/Volume_1/C.1.2_…
Since PDF didn't exist in 1981, the document is either a scan or the
result of a recent *roff run on ancient source. If it was made from
source, it's an impressive testimonial to the longevity and stability
of troff. Most probably it's a scan, in which case we owe many thanks
to the public-spirited person who digitized this trove. Was it you,
Arnold?
Doug
On Jun 3, 2022, at 4:48 PM, Larry McVoy <lm(a)mcvoy.com> wrote:
> Um, so there were 3: 386, Net and Free. That's already 2 too many.
My recollection matches what Warner is saying. NetBSD &
FreeBSD got going *because* 386BSD was effectively frozen. It
wasn't dead dead but patches were not being upstreamed (as we
say now), and so on. I do agree with you that even two variants
were 1 too many. But even one would probably not have mattered
as the AT&T lawsuit was a huge cloud on *BSD's popularity. As
well as there were other factors. Linus and Linux had a much
better story, its development was more nimble, with many younger
and much more enthusiastic developers/users etc.
Not that anyone really cares at this point except some graybeards!
The Open SIMH project sounds great!
