The folks at Bell Labs were asked to figure out if Mark Williams had copied Unix directly or via too much knowledge already obtained, or whether it was truly a clean room recreation. I don't remember all the details, but it became clear after a while that it was indeed a reasonably clean rewrite. This was done by looking for corner cases that were an accident of the original implementation and would be unlikely to appear in a version created separately. One detail that did stick with me was the discovery during this process that ppt, the paper tape simulator, mispunched a letter, I think "R", but the Mark Williams version did not. Was that compelling? Not on its own, but it was funny and memorable. -rob On Sun, May 1, 2022 at 9:46 PM Ron Natalie <ron(a)ronnatalie.com> wrote:

On Sun, May 1, 2022 at 10:06 AM Kenneth Goodwin <kennethgoodwin56(a)gmail.com> wrote: Coherent, which was open sourced many years ago by MWC founder Bob Swartz (Aaron's dad), is available at http://www.nesssoftware.com/home/mwc/source.php . You can get Coherent sources, source for the excellent manual, and XYBASIC. Udo Munk (does the CP/M emulators with the fancy front panels) worked at MWC and has been going crazy (re)creating Coherent build systems, older versions (down to 3.2.1?), VMs you can play with and lots more. I also see he recently made available disk images for Coherent 2.3.43 for the 8086. His stuff is at https://www.autometer.de/unix4fun/ . Jim

in terms of rewrites from manuals, while it was not the first, as I understand it, AIX was an example of "read the manual, write the code." Unlike Coherent, it had lots of cases of things not done quite right. One standout in my mind was mkdir -p, which would return an error if the full path existed. oops. But it was pointed out to me that Condor had all kinds of code to handle AIX being different from just about everything else. On Sun, May 1, 2022 at 7:12 AM Kenneth Goodwin <kennethgoodwin56(a)gmail.com> wrote:

I don't know where the fellow got his information, but I was told that AIX started out as AT&T code, but went through not one but two rewrites. On Sun, May 1, 2022 at 11:55 AM Charles H Sauer (he/him) < sauer(a)technologists.com&gt; wrote:

My understanding of AIX was that IBM licensed the System V source code and then proceeded to "make it their own". I had a days experience with it on a POS cash register fixing a client issue. The shocker - they changed all the error messages to error codes with a look at the manual requirement. Not sure if this is true in its entirety or not. But that's what I recall, thst it was not a from scratch rewrite but more along the lines of other vendor UNIX clones of the time. License the source, change the name and then beat it to death. On Sun, May 1, 2022, 2:08 PM ron minnich &lt;rminnich(a)gmail.com&gt; wrote:

I love Barry Shein's snark on AIX (and occasionally paraphrase it for Linux): "AIX - It will remind you of Unix." -r

On Mon, May 2, 2022, 8:22 PM Rich Morin &lt;rdm(a)cfcl.com&gt; wrote: One of my favorites: "SMIT happens." - Dan C.

On Tue, May 10, 2022, 9:32 AM Mary Ann Horton &lt;mah(a)mhorton.net&gt; wrote: The first 8086 port was inside of Bell Labs, but was for a system with a custom MMU. The first commercial one was Venix released in 1983 based on Version 7 with some Berkeley improvements using the MIT compilers of the time, but it had a blue label with a boring stylized V on it. IBM released PC/IX a year later (1984) and marketed heavily. It was a companion to its other unix offerings, and wasn't AIX. That port was based on System III. If anything had the clever Charlie Chaplin marketing materials, it was sure to be PC/IX. Microsoft's Xenix was also in this time frame, but wasn't marketed by IBM (and its earliest version in 1982 predate Venix, but were only for Intel's System 86 machines, and may have required an Intel MMU board (the quick research I did was unclear on this point, other than it was supported). SCO/Microsoft released in late 1983 and early 1984 versions for the commercially available PC and other variants at the time before the IBM-PC became the standardized x86 platform. So my money is on PC/IX. Warner Thanks,

In the early '80s UC Santa Barbara had a general assignment teaching lab full of IBM PC/ATs (i.e. 286s). We convinced the the powers-that-be to let us run Xenix on them for a remote sensing class, which meant we could port an image processing system I'd written under v6 (PDP-11/45) to an actual classroom. Xenix must have been v7 or pretty close, since the port was painless. (The display driver was a bit harder---it was (gasp!) 8-bits deep, first display I didn't have to dither on, but it wasn't memory-mapped, so you had to shovel pixels into it a byte a time. Made for nice dramatic slow reveals...) Thanks for the memories! /James Frew P.S.: Hardware brevis, software longa: https://github.com/USDA-ARS-NWRC/ipw On 2022-05-10 09:08, Warner Losh wrote:

PC/IX ᐧ On Tue, May 10, 2022 at 11:32 AM Mary Ann Horton &lt;mah(a)mhorton.net&gt; wrote:

I mostly defer to Heinz and Clem regarding PC/IX. It is hard to imagine the IBM people in Boca Raton allowing the Chaplin imagery to be used with a secondary product like PC/IX, but I don't remember the packaging. PC/IX was my first hands on experience with Unix. PC/IX was used extensively in the AIX development group while ROMP hardware was scarce. Before I got my own RT/PC, I used PC/IX primarily, until I got a PC/AT and started using some instance of Xenix that supported the 286 MMU. Charlie On 5/10/2022 12:18 PM, Clem Cole wrote: -- voice: +1.512.784.7526 e-mail: sauer(a)technologists.com fax: +1.512.346.5240 Web: https://technologists.com/sauer/ Facebook/Google/Twitter: CharlesHSauer

On Tue, 10 May 2022 at 13:21, Clem Cole &lt;clemc(a)ccc.com&gt; wrote: What was the timeframe on that? As far as I can tell from looking through the Ultrix 2.0 source code, the earliest modifications were in very late '83 and reference imports from 4.2BSD dated at latest fall '83. -Henry

Armando’s plates didn’t say ULTRIX. The ULTRIX plates cae later (some complete marketing disaster at DEC). Armondo’s plate said UNIX. At one USENIX meeting, Armando got up and made an announcement that for many years UNIX and DEC had been synonymous, but DEC had never realized it. He was therefore happy to announce the first UNIX license from DEC and held out up one of the plates. I still have mine. Armondo had a NH vanity plate that said UNIX (like the replicas given away). He also had one of the DEC replicas on his car complete with the state renewal stickers. At one point it went missing. He announced that on the net, which led to a lot of people mentioning that they hadn’t seen it wherever they were. I believe he ultimately did recover it. ------ Original Message ------ To "Henry Bent" &lt;henry.r.bent(a)gmail.com&gt; Cc "TUHS main list" &lt;tuhs(a)minnie.tuhs.org&gt; Date 5/10/2022 9:33:59 PM Subject Re: [TUHS] First Unix-like OSes not derived from AT&T code?

On 5/11/22, James Frew &lt;frew(a)ucsb.edu&gt; wrote: Many have pointed out the irony of the prisoners in New Hampshire state penitentiaries having to spend their days stamping "Live Free or Die" on license plates. Gilbert & Sullivan's Mikado would have been proud. :-) -Paul W.

On Tue, May 10, 2022 at 1:35 PM Richard Salz &lt;rich.salz(a)gmail.com&gt; wrote: At some point, Unix V7M was rebranded as Ultrix-11 and pulled in a lot from the BSD releases (2.9 or 2.10) to get TCP/IP networking onto the PDP-11. I don't think DEC ever shipped pure AT&T binaries. The V7M was a modified version of V7, with most of the modifications in the kernel to fix a few bugs with buffer handling, and also make it run on all the different PDP-11 models. All the sources to V7, V7M and the last Ultrix-11 version are in TUHS for people to peruse... Warner

On 5/10/22, Clem Cole &lt;clemc(a)ccc.com&gt; wrote: Before that, Bill and Armando's engineering group was part of DEC's Telephone Industry Group (TIG) marketing organization. Their charter was to see that Unix and other AT&T software ran well on DEC hardware. Mainly they did device drivers and some kernel mods. DEC was getting increasing demand from those outside Telco who were running Unix to get a DEC-supported Unix on the VAX. And so TIG engineering was split off and did a full port and the result was called Ultrix. This started in 1982 IIRC. That was a very nasty bit of DEC internal politics. As soon as we in DEC's software development tools departments (Technical Languages, Commercial Languages, Methods & Tools) heard about the creation of Ultrix, we began planning ports of the VAX/VMS compilers and other pieces of the tool chain to Ultrix. We got immediate and fierce push-back from the Ultrix engineering group. TIG had had a deeply ingrained culture of resisting innovation. Their job was to make sure Unix ran on DEC hardware, not to enhance Unix. Many of the Ultrix engineers had a religious belief in keeping Unix pure and platform-independent. Things available on only one hardware platform were perceived as "vendor traps" and to be avoided. The biggest fight was over Fortran. VAX Fortran was seen as the gold standard in Fortran compilers by the Fortran R&D community and there was a lot of demand for DEC to make it available on Ultrix. f77, the Unix alternative, was, by comparison, considered a toy that lacked key features. By careful cherry-picking the compiler people in the Ultrix group managed to put together a suite of Fortran benchmarks that hit all the glass jaws in the VAX Fortran optimizer. They claimed that this showed that f77 produced code at least as good, if not better, than VAX Fortran did. The VMS development tools group had better things to do than argue with the Ultrix group, so the whole idea of porting VAX/VMS tools to Ultrix was dropped. Many of the non-standard innovations in VAX Fortran were adopted by IBM and other vendors under pressure from the Fortran community. By 1985 DEC was losing sales to other vendors in the HPTC world due to lack of VAX Fortran features in f77. The Fortran team in Technical Languages and Environments had to do a rush-rush port of VAX Fortran and its runtime library to Ultrix. We were rather teed off since we'd proposed the same thing three years before and now it was a "we need it yesterday" crash project. It was decided that it would take too much time to teach the VAX Fortran code generator to produce a.out object files and so instead we ported the VMS linker to Ultrix and taught it to read and write a.out as well as VMS object files. The result was called lk. As the developer in the software tools organization who best understood linkers and object files (I'd written a link editor in grad school when interning at IBM) I was put in charge of the linker port. I've told that story already here in TUHS. IIRC the 4.1 version of VAX Ultrix was their prototype. I think PDP-11 Ultrix was just one of the existing Unix variants for the PDP-11 with the "Ultrix" marketing label slapped on. We can't have vendor traps, you know.... By the late 1980s the PDP-11/VAX style of CISC architecture had fallen way behind RISC in terms of performance. Alpha wasn't ready yet. To keep a toehold in the Unix marketplace, Ultrix was ported to the MIPS architecture and a MIPS code generator was implemented for the GEM back end so that DEC Fortran would be available. Unix was easier to port to Alpha than VMS was. Score one for writing in a HLL and maintaining platform neutrality. Clem has told that story here. Most of the VMS OS code was in assembler. A VAX MACRO compiler front end had to be written that read VAX assembly code and produced GEM intermediate language. To this day most of OpenVMS is still in VAX MACRO. -Paul W.

On Wed, May 11, 2022 at 12:44:10PM -0400, Paul Winalski wrote: Not unique to DEC, I very much had that attitude at Sun and wasn't alone. As a side effort from making SunOS POSIX compliant, I wrote lint libraries for BSD, Sys III, Sys V, POSIX, and I don't remember what else. The idea was that you could use Sun as a dev platform but lint your code against whatever platform you wanted to target. It was misguided, I bet I can count on one hand the number of people that used any of those, but I hated vendor traps as much as DEC, maybe more.

As good a time as any to thank you for this. Pity you couldn't convince them to put the POSIX sh in /bin/sh and the old sh in /usr/compat or some such, rather than having POSIX only in /usr/xpg4. Adam

What are you talking about? That wasn't a long time ago. It was only... ... ...aw crap. Adam

On Wed, May 11, 2022 at 10:45 AM Paul Winalski &lt;paul.winalski(a)gmail.com&gt; wrote: That's kinda ironic. One of the biggest ticket items in the AUUG newsletters from the early days was how you can get FORTRAN, BASIC or MACRO-11 running under V6 or V7. There were several compatibility shims for RT-11 to accomplish this in a number of different ways. It was a big deal for many folks that needed to run their FORTRAN programs from a DEC OS, but wanted / needed to run Unix.... It's clea*r* they'd forgotten the PDP-11 experience... The macro-11 that was in 2BSD had its own companion linker that was basically the same. It could link in .OBJ files from other DEC tools as well... History repeated itself, eh? Warner

On Thu, May 12, 2022 at 8:07 AM Ron Natalie &lt;ron(a)ronnatalie.com&gt; wrote: That's pretty much what the processor documentation says (in various wordings depending on what manual you look at). EMT is for the "system", TRAP is for the "user". The intention, I think, was that a user-mode program could use TRAP for its own purposes, and the supervisor would keep track of the TRAP vector in low memory associated with a process. Since Unix was a "user program", even though it ran in supervisor mode, the decision was made to use TRAP. Each DEC OS used EMT in a different way. Consequently, when the RSTS/E pseudo-hypervisor (it didn't provide full emulation) was written, hypervisor calls were performed with EMT 377 immediately followed by another EMT. This was unlikely to occur in any user program (at minimum you'd have to set up the registers for the second call). An EMT was acted on by the hypervisor only if it met these conditions (the second EMT was simply examined, not executed), otherwise it was vectored to the guest OS. Similarly, RSX/11-M used only EMT 376 and EMT 377, neither of which were used by RT-11 user programs, making it possible to run a thin RT-11 emulator as a user program that EMTed into RSX to do its work.

Ron Minnich wrote: My memory, from having a "finger" program that tried to display the foreground/active process for each tty/login/utmp entry, is that there it was possible there were multiple code bases (tho it's possible there was just one, and it mutated wildly across major versions), all called "AIX" (and as my old boss, Barry Shein (BZS) at Boston University said, they all "will remind you of Unix"), there were (at least) versions for: RT PC RS/6000 (POWER, PowerPC) PS/2 I never had access to AIX/370, but BZS got a chance to try it out in a VM on the academic computing S/390, and ISTR he said it finished compiles before you hit return. There was also a (pretty clean, ISTR) port of 4.3 BSD to the RT called "ACIS", but it might only have been available to academic sites. My memory is also that IBM had a very broad license for SVR2 and when the Open Software Foundation came together (with people who weren't AT&T or Sun), IBM was able to offer that up as a code base. gether,

in blue On Mon, May 2, 2022 at 2:57 AM Ron Natalie &lt;ron(a)ronnatalie.com&gt; wrote: Correct -- AIX for the 370 ISA and 386 were compiled from the same code base Not quite correct. TCF was based on the ideas from the Locus Distributed OS. But not the same code. The Locus Distributed OS was based on a research (V7) kernel originally on 11/70s; although I believe UCLA added BSDism over time and Vax support (I never saw that personally). But more importantly, AIX and TCF itself were also owned by IBM (*i.e.* it was a work for hire of LCC for IBM). Bruce Walker was the implementation lead for both (and one of Jerry's grad students). Locus TNC (which is what OpenSSI for Linux is based on[1]) - although the website seems to be taken down sadly - it never was ported beyond Linux 2.6 kernel) is a completely new implementation yet. I'm one of the architects of the same. We were 'firewalled' so Bruce and our peers could talk about things, but I was never allowed to actually look at the IBM code base. I could >>use<< it to try things out. After the IBM AIX contract ended, Bruce and the old AIX team at LCC was then given full access to TNC source trees which Locus owned the IP. The big difference between the 3 was the Locus was its own OS, that supported UNIX-like features. Whereas TFC was built into a modified/custom AIX kernel and special FS with ad hoc support for the different issues that allow process migration. One of the cool things as Ron pointed out was the TCF allowed the mixing of binaries from Intel and IBM ISAs and the kernel would use whatever processor it needed. With the 3rd generation TNC, the technology was split into 14 separate 'products' that used structured interfaces in the kernel. For instance, the process support was encapsulated in what we called VPROC (similar to the multiple FS style layers from Research and later Sun -* i.e.* the different VFS) and while it worked better if you used the Locus supplied cluster file system (which supported full Unix semantics), basic process migration within the constraints that NFS placed, also worked (the HP implementation was based on NFS, while DEC, Intel, and SRVR4 implementations used CFS). My personal role was much of CFS and some of the utility functions like the Cluster Management System (CMS). In fact, a small demonstration of TNC was done with OS/2 to show that the OS/2 process semantics and the UNIX process semantics could co-exist, but it was never completed as IBM did not buy it. However, some of the technology landed in the Rochesters AS/400 OS in their Posix emulator which Locus also had a hand in building. One of my favorite demos was at a trade show that had a LAN; our folks would bring a PS/2 with an empty hard disk and load a single floppy. Boot the kernel, and add it to the TCF cluster back at LCC. The system immediately was usable, although since the disk was not populated, all binaries had to come across the LAN/WAN. But the caching would start to take over in the background and slowly populated a local copy of /bin, /lib, and the like. Very cool ... Clem [1] Sadly, when I checked this AM, the OpenSSI website seemed to be taken down. I d not believe OpenSSI was ever beyond Linux 2.6 kernel. IMO: It was a shame that the upstream Linux kernel team had been willing to take the VPROC changes, it would have been a very interesting and exciting system enhancement. As Ron said, anyone that used TCF or TNC was pretty much hooked. I'll have to do some more poking to find out what happened.

On Mon, May 2, 2022 at 10:46 AM tytso &lt;tytso(a)mit.edu&gt; wrote: FWIW: I know that at least 3 people on the OpenSSI team were telling me they were told to go away. I do not know the details of the interchange, but doing some Linux work at the time, I too found the reception to kernel changes to often be a tad cold (it took 10 years to get the core RDMA support up-streamed). It's possible the way the OpenSSI team asked, the prayers offered were not acceptable to those in charge at the time. I don't know, but please be careful here. *They were tried and feel that they were rejected.* *That is history*. I understand that you want to try to say, well there is no evidence of the proper emails/git change, *etc.* But that team ran into blocks. So you can be a lawyer about it, or you can try to accept what actually happened to those of us on the other end with some grace. FWIW: Larry M and I have often disagreed about the 'open-ness' of the traditional UNIX releases from AT&T. I suspect we are both right in our position given the history that we each experienced. Larry's position (which I understand and accept) is that from his standpoint, it just was not *open to him *as the University kept things under lock and key. I always find that strange because I had absolutely the opposite history. I know my friend at MIT had free access, I can only assume you enjoyed that yourself/but I'll not try to speak for you. I believe it was available if you had wanted it, while it was not Larry at UWis. I do not know for sure in the case of the OpenSSI team, I know what they have told me, but my >>guess<< is that something similar is happening here. The issue, which I think was similar to the pushback my teams received with RDMA around the same timeframe --> the core Linux kernel team was still trying to fight to be a desktop war and had not yet started to focus on where it would become a major success (enterprise-class system). RDMA (and I suspect OpenSSI too) was not seen as something that was relevant to the desktop war and the creators were discouraged to continue to pursue it. Taking my own experience here, RDMA only got upstreamed because so many people at Intel started working in the Linux kernel team and people like me at Intel who did care about that support, had to be a tad forceful to get it there. As I said, it took about 10 years before it came out. all clustered Linux systems use it. In my own experience when we started that work in the early/mid-1990s, I personally was quite directly told [IIRC to] 'bugger off' in an email from one of the core Linux kernel folks (not you mind you - but I bet you can guess) - that they were not interested in the feature. The word was something on the order of adding RDMA would only make it hard for the VM system and no one would use it. What is interesting is that it's pretty popular and now a lot of hardware is being designed assuming it is there and the Linux implementation frankly is the most complete. I've also seen a number of distros advertise their support for RDMA HW these days. Back to my core point. Adding support for VPROC was invasive to the kernel itself. There is code to support processes in lots of places (For instance the code to send different signals even makes it into some device drivers). So it means moving all the process code into separate modules (like the file systems) and then making the core kernel call indirectly through that layer. Once that layer and functions are added, it means that different process models (like a distributed one needed for something like TNC) become a loadable module. Kernel's that do need it, just load the traditional process model. The other thing that is cool, IMO, it means you can start to play with other process models. Adding processes that use a different API (*e.g.* my comment about the OS/2 demo we did for IBM). Yes, the changes are invasive to add support, but the power is extraordinary. So .... I also, personally know a number of the folks that worked on the OpenSSI project and I suspect they tried to get the VPROC changes upstreamed too, but were ignored/discouraged, and they finally gave up trying. I know at one point Frank started to put VPROC support into FreeBSD, but I don't think that went anywhere either (although I don't think he finished it). I also know that the *Linux port to 2.6 was complete at one point* (I personally had it running on a cluster here at Intel with RDMA too BTW), but I never tried the FreeBSD codebase. And yes, I do think that is a real shame and that it does not speak well of history. History has probably lost something good because at this point the people involved are just not interested in trying anymore. Clem ᐧ

On Mon, May 02, 2022 at 02:31:00PM -0600, Warner Losh wrote: I don't know where they were told to go away; I can just state that the patches were never sent to LKML, and from a search using lore.kernel.org, I don't see any evidence that they were told to "go away" on the Linux Kernel Mailing List. Could they have been told to "go away" by someone, either with someone "official" or "non-official", on some random mailing list, or at some random bar at some random conference? Sure. It's impossible to say. Yep. And sometimes, even if they are someone official, if they don't necessarily explain the patches well, and/or never send the patches for review on the mailing list, it could be that there was a miscommunication regarding how the patches were described, such that a "no" that happened at a conversation at some random bar at some random Usenix conference might have been a "yes" if there were patches sent to be reviewed on the mailing list. Something which definitely happens is the fear of "drive by contributions". So for example, Clem tells the story of people being hesitant of accepting RDMA / IB patches. I very much doubt it was because people were chasing the Desktop. There were certainly people in the Linux kernel who were chasing the Desktop, but those tended not to be the "gate keepers" for the kernel. Linux kernel developers might use the desktop, but there really was very few "desktop" kernel features. If I had to guess, the main concern was that some random developer would try to get the code upstream --- perhaps because a system integrator like IBM or HP would have something in the procurement contract requiring that the device driver be "upstream" --- but then once the code made it upstream, the developer would disappear, never to be heard from again, and the Linux Kernel developers would be stuck having to support it forever. (Worse, in the early days of IB, IB was $$$, and most kernel developers didn't even have access to IB in their home systems.) So it's helpful to have a company to have multiple engineers, all contributing changes, hopefully to adjacent parts of the kernel other than the specific subsystem which they are trying to shove into the kernel, to demonstrate that they are going to be there for the long haul, and not just try to "drive by" shoehorn code into the kernel, only to be never heard from again. For example, just recently someone from a particular tried to get an NTFS implementation "upstream" into the Linux kernel. They sold a "feature-full" version of that file system for $$$, and there was some suspicion in some quarters that they were only trying to get a stripped-down version of their file system into the Linux kernel for marketing reasons. There were some, including yours truly, who pointed out that they hadn't open sourced userspace utilities, and that the file system regression test when run on their file system was failing tests right and left, and hence wasn't ready for prime-time. They pushed hard, and ultimately, Linus decided to accept their code contribution, because the alternative in-tree file system was pretty crappy, and the belief was that new one was better. Immediately after the merge window closed, the developer went silent, and stopped responding to e-mails. Which left folks debating whether we should remove the code contribution from the tree before users started depending on it, because something worse than one unmaintained, crappy file system in the tree that some users might be trying to use wouldbe *two* unmaintained, crappy file systems in the tree.... That's true, but again, part of that is because of the "drive by contribution" problem. One of the ways which we've tried to solve this problem for device drivers is to have a "staging" part of the tree where new code which is "on probation" can live, and if it turns out that the developers disappear, code in the "staging tree" is documented to be more easily removed uncerimonously if it looks like the code has become abandonware. This doesn't work as well if there needs to be massive code complexification into the core parts of the kernel, where large parts of the kernel needs to be changed, perhaps to add (for example) VPROC support. It's even worse if such "powerful" changes ends up slightly slowing down code which is in the hotpath. We have in the past tried to put file systems into the staging tree. But for example, there was pain when we ultimately decided that Lustre needed to be removed from the Linux tree, because the people who tried to get Lustre into the upstream kernel wasn't actually *improving* that was in the upstream kernel, but instead was working on shipping product in distro kernels: https://www.linuxjournal.com/content/lustre-filesystem-dropped-linux-418-ke… So the "companies / communites" just trying to throw code of varying quality over the wall and not providing a commitment to continuous maintenance and improvement of said code is a real one. And if you wonder why sometimes the Linux kernel community can be a bit "cold" about accepting new code, that very often can be why. Open source is not just about the code, it's about the development community. And if the community hasn't been integrated into the Linux kernel community first, it may be that an important prerequisite step is missing. Cheers, - Ted

Hello! Egads! I remember trying out AIX (On an original RT/PC rig) at a UNIXEXPO years ago. I found that the units were all networked together, and used the telnet command to log into them from the first one. Surprised the heck out of the sales 'droid that was present at their booth. As for AIX/370 I found about it at a different event that same year, And yes I did want a copy to try out under a certain emulator named for a plane and mythological figure. And of course as a guest under VM/370. ----- Gregg C Levine gregg.drwho8(a)gmail.com "This signature fought the Time Wars, time and again." On Mon, May 2, 2022 at 2:57 AM Ron Natalie &lt;ron(a)ronnatalie.com&gt; wrote:

I remember hearing that about Cray. The anecdote was they thought their port of "make" was broken because it kept rebuilding everything. It turned out that the timestamp granularity of one second wasn't good enough. Also that if you wanted your program to stop, you needed three 'halt' instructions to make sure the full pipeline got the message. I'm less sure if that is real.

On Mon, May 02, 2022 at 06:14:54AM -0700, tytso wrote: I'm pretty sure it was UW-Madison that did the NFS port to 4.3, I was a grad student there at the time and remember hearing about it. The RT's were pretty nice machines for the time.

What was delivered as binary was the Advanced Floating-Point Accelerator microcode. At the end of the AOS work circa 1996, most of the kernel was 4.4, except for the network stack which was 4.3-Reno, and the VM system which was still 4.3 (hence no mmap). The compiler was Metaware High C. GCC could not be used to compile the kernel sources unchanged, because one of the locore->trap.c paths was relying upon the stack layout used by the compiler. With that fixed, gcc could be used to build a working kernel. Miod

On 5/2/22 7:14 AM, Miod Vallat wrote: does that kernel source tree survive anywhere?

On 5/2/22 12:13 PM, Al Kossow wrote: I have a copy of the entire source tree. We used it extensively, and I ran it on a castoff RT in my home office for years. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet(a)case.edu http://tiswww.cwru.edu/~chet/

The PC/RT was interesting in hardware design sense, as a "user" I found it well, arguably "over" engineered. Big bold IBM solid feel. Connectors which were 2x chunkier than they needed to be, but then you looked at other systems with bent pins and broken latches and the IBM stuff was grossly over-size, but just didn't break. The screen was good, but somehow small. We had one at the same time as Decstation 2100s and they were greyscale, but deliciously big monitors. The manual set was complete, and covered everything. You had to understand how to walk the IBM structured dewey-decimal model of thing-sub-thing-sub-sub-thing-sub-lettter but if you got to a fictitious FRU-BCP-FRZ-J page, it described everything you needed to know and had paste-overs or insert sheets about the -J variant. It was the heaviest PC chassis I ever had to move. Other people laughed at it, but I enjoyed using it for a year. I felt much the same about the ICL Perq: very very heavy, but Olivetti-good cool design. Just the right shade of Orange and Coffee for its day. getting MBONE working on it was a joy.

Most - if not all - the AOS work was done by Roger Florkowski and Mark Dapoz, and Roger was definitely working for IBM at that time. I think time was limiting factor, but also Roger was not really wanting to port the Mach VM to AOS due to the RT MMU limitations - in particular, there is no way for multiple virtual addresses to point to the same page, so you need to keep evicting/switching mappings when you want a page to be available to the kernel and the currently running userland process. That was fixed in the POWER MMU. I'm afraid that doesn't ring any bell. Miod

Correction: Thoth was written in "Zed", similar to C.

On Mon, May 02, 2022 at 09:16:40AM -0700, Bakul Shah wrote: I was friends with Dan Hildebrandt, one of the 3 people allowed to commit changes to the microkernel in the 1990's. That history seems pretty accurate though Dan told me the commonly used microkernel code fit in 4K of instruction cache, I don't recall what it needed in the data cache. Dan told me they were very careful to not let that bloat, I remember him saying "the instruction cache needs to have space for user code". A refreshing point of view, especially since I was living in "I measured it, it's only 1% slower" AKA "death by a thousand paper cuts".

[I scramble old memories all the time but I seem to remember random facts that are of no use to me :-)] Indeed. These were all research OSes. The thing that distinguished Unix was the collection of tools and composability via pipes and shell that made for a very nice development env. As a grad student I didn't quite appreciate this (not having used Unix) but the moment I used it, I was sold on it! From what I remember, A Thoth "team" was about the same as a Unix "process" and Thoth "process" was a thread in a team. That to me was the most interesting part about it. Unix got threads much later. I remember Sol but by then I had moved on from Pascal.