On Tue, Dec 20, 2022 at 4:32 AM segaloco via TUHS <
tuhs@tuhs.org> wrote:
This document also mentions docs for UNIX Real-Time-Reliable on the 3B20D. No doubt a MERT and UNIX/RT descendant.
I'm not so sure it was that direct, actually. This is the work from IH that I have mentioned from Tom Bishop et al. - a very cool system IMO. As I understand from Tom, the team had the earlier docs and code but started over for different reasons (primarily the need for SSI support). I'm not sure how many/if any, of the earlier MERT-specific system functions (see the docs that Heinz got to us on TUHS) were supported. As I understand it, few. The primary target for this system was to control ESS#5, and I don't think Tom and the team were considering codes that at already been released and running in the OC on PDP-11-based MERTs.
3B5 section mentions a "Release 5.3" so before the System V moniker. Farthest I've seen the minor version.
Again -- my point about internal AT&T politics. The 'System x' stuff was the marketing / legal team in North Carolina. System development was in Summit (USG).
You can see two heads of AT&T in this observation of the code base. On the one hand, the traditional TelCo market, in which the 'UNIXness' was important, but on the other hand was Charlie Brown's new directive and being allowed to be in the 'computer business.' The whole thing about the System x stuff was created and pushed from NC as part of the latter. The folks concentrating on the former, the traditional teams in IH, Columbus, etc., already understood their customers (the former OCs, now baby Bells).
Needless to say the system really grew legs in the 80s even inside the Bell.
Exactly - which is why all of this is so confusing years later, particularly to folks that did not live the times. Today (i.e, years after the fact), we can see many technical results as time points, such as releases from different teams. We know the technologies and the people that created/implemented them. But very much lost to time is the content - which is the politics and economics of why things went in specific directions.
As I have said so often, as technologists, we have to try to remember: that simple economics beats sophisticated engineering
Yes, this is sometimes grating for us, as we like to look at things from the technical side. As Larry likes to point out, the new SunVM was excellent but was tossed in favor of the inferior SVR4, or as Rob says, Research went with BSD on the Vax, although they too had what seems in hindsight to have been superior options.
But I will that an experienced >>guess<< both of those were driven, in the end, by reasons other than pure technology (Larry has discussed the Sun situation, for instance). Only someone like Rob or Ken can say why in the end, BSD was picked -- but having lived these types of choices in other places, I'd >>bet just using BSD was because 'pure joy' was 'good enough' to support the Vaxen (which were tools for them) and they had other things to worry about - and/or their research efforts were no longer directed at the VM system, but rather other features such like distributed FS, remote execution and such.