Am 11.08.2022 um 08:04 schrieb Paul Ruizendaal: It is a hybrid system. I found files and similarities in R1, R2 as well as R3 - the C compiler (in my queue) for instance is likely derived (and heavily modified) from a R1 origin, but in this version itself linked with a C library where parts are newer, namely from a later released version (in the update 3-3.1 in tape IS0463P) which I'll add in the future. I am sure that the kernel libs will then reveal the missing streams stuff. I think it was a rolling release which also still contains parts of the older 16 bit MUNIX for a 68010 with Motorolas FFP lib - the kernel still contains an obsolete module named m68341 which emulates an incompatible floating point lib. The 32 bit system here demands a 68020/68881 combination. There are also several QBUS I/O drivers which seem to stem from the 16 bit systems which likely do no longer access real existing hardware because the newer systems used a communication controller board named ICC with an own 68010 processor and a highly stripped down tailored UNIX (?) on it. This is also on my to-do list. @readers of TUHS: can anyone say something about m68341? There are Motorola FFP libs elsewhere on the net, but this appears to be a complete copro emulation which intercepts the line-F interrupt which I could not locate so far. Internally, it is pretty much optimized - I doubt it was cooked at PCS itself, so it is likely a Motorola product. And no, it has absolutely nothing to do with the embedded controller MC68341. Currently I am dissecting the also rather unique a68 assembler which is a modified Trix/Mical assembler; after that, I'll look into the IS0463P update. Maybe the original NC did so, but here there are numerous additions to the kernel, including a new syscall uipacket() which is the gateway into the MUNET/NC implementation. Stuff is in /usr/sys/munet, the low level networking is in uipacket.c and uiswtch.c which will process RPC open/close/read/write/exec etc. calls, as well support master and diskless nodes). The OS code is full of "if (master) {...} else {...}' code which then redirects detected access to remote paths to the network handler. Good to mention this. I am interested in such stuff as well. Regards Holger

I came across a later paper for Unix United / Newcastle Connection. It seems to consider moving parts of the code into the kernel, to combat executable bloat (the relevant libc code would be copied into every executable, prior to shared libraries): https://www.researchgate.net/publication/2997714_The_architecture_of_UNIX_u… I found a summary of that ACM SIGOPS workshop. There is a half page summary about David Russels presentation on “Distributed Unix”: ==== 2.4 David Russell: Distributed UNIX Distributed UNIX is an experimental system consisting of a collection of machines running a modified version of UNIX. Communication among processors is performed by a packet switching network built on Datakit hardware. The network has a capacity of roughly 7.5 megabits, shared among several channels. Addressing is done by channel, not by target processor. Messages are received in the order sent. To the user, communication takes the form of a virtual circuit, a logical full-duplex connection between processors. A virtual circuit can be modeled as a box with four ends: DIN and DOUT control data transmission, and CIN and COUT control transmission of control information. Circuits can be spliced together, or attached to devices. Circuits can also be joined into groups. A virtual circuit is set up in the following way: a socket is created with a globally unique name, and processes then request connections to the named socket. Routing information is implicit. Virtual circuits support location transparency, since sockets can move, but not replication transparency. If a circuit breaks, it is set up again, although it is up to the user to handle recovery of state information. Machine failure will destroy a virtual circuit. A transparent distributed file system was set up. When a remote file is accessed, a socket name is generated, which is used to establish a connection with a daemon at the file server processor. The daemon carries out the file access on behalf of the remote user. In conclusion, offloading of tasks was found to work well. The path manager maintains very little state. The splice interface between virtual circuits was found to be very efficient, although UNIX scheduling was not appropriate for fast setup of circuits. ==== The modeling of virtual circuits sounds like a mid-point between Chesson’s multiplexed files and Ritchie’s streams. The file system actually sounds like it could be the RIDE system. Maybe this Distributed Unix and RIDE are one and the same thing. (although the original Newcastle Connection paper suggests they are not: https://inis.iaea.org/collection/NCLCollectionStore/_Public/16/081/16081910…)r=1). Paul