←back to thread

55 points todsacerdoti | 8 comments | | HN request time: 0.416s | source | bottom
1. neilv ◴[] No.26595984[source]
Apollo Domain/OS was great, innovative, and opinionated. It wasn't just another BSD or System V, and they rethought a lot of things.

Apollo's heyday was a bit before my time, but my first real job was working on technical software at a company who was a big-ticket technical software developer on Apollos (and I even once saw marketing brochure with our badge on an Apollo workstation). As an intern, I set up a pair of them for porting (though we preferred SPARCstations), and later, when I moved to headquarters, HQ was still doing the master SCM and (what's now called) CI, for all platforms, on Apollo DN10k pedestals. We got the DSEE descendant Atria ClearCase on non-Apollo workstations, in a new-tech R&D group I was in. I bought a couple retired Apollo workstations just to play with them at home.

Apollo did a lot of innovative stuff in Domain, and it's one of the few platforms I'm sometimes tempted to buy again, just to play with it and understand more of how they approached things.

When it had been years since I'd seen or heard of Apollo anywhere, I bumped into someone from there, who mentioned that Boeing had done some documentation using Apollos, and part of their very serious configuration management process involved them physically archiving an entire Domain network. (I'm guessing they used the very nice Interleaf software, which seemed to be popular on Apollo, and, by that time, had long also been available on other platforms.) It was appealing to think of an Apollo Domain network preserved in stasis, should humanity ever need to call up Apollo for duty again.

replies(3): >>26597283 #>>26598177 #>>26599667 #
2. dn3500 ◴[] No.26597283[source]
There is an emulator built in to MESS in case you ever want to play with it again. You do need to find a disk image somewhere.
replies(1): >>26597794 #
3. neilv ◴[] No.26597794[source]
Thanks! In case anyone else is interested, three of the links I just found:

https://wiki.mamedev.org/index.php/Driver:Apollo

http://mess.redump.net/howto/apollo

https://jim.rees.org/apollo-archive/

4. breput ◴[] No.26598177[source]
"It wasn't just another BSD or System V, and they rethought a lot of things."

It was also a huge PITA to get any 3rd party Unix software to compile on Domain/OS. I went to a college that had exclusively Apollo workstations and you had to get really creative with Makefiles, #ifdef, #include, and writing compatibility layers to make it play in the SunOS/Solaris/SCO world of the time.

Eventually we started getting "HP Apollo" HPUX systems, which weren't that great either, but at least they were closer to mainstream Unix.

replies(1): >>26599691 #
5. ncmncm ◴[] No.26599667[source]
Domain/OS, later "Domain/IX" (we were told the "IX" meant "9", but weren't fooled; everyone called it "domainix") inherited from Aegis a powerfully useful feature still missing in Unix and Linux: environment variable references could appear in symbolic link text, and be expanded when the link was followed.

Dragonfly BSD has adopted a similar but rather clumsier version of the feature.

People always think at first that this would introduce security problems, but I have not heard of a plausible one.

(As an aside, corporate marketing departments were always coming up with reasons why "their" unix mustn't be called unix. People not fooled just stuck "-ix" on the end. E.g., Sun promoted their "Solaris", thus "solarix". That is why Apple's thing is still called "macosix" by those of us who know better; similarly, Windows is pronounced "windos".)

replies(1): >>26600967 #
6. ncmncm ◴[] No.26599691[source]
It was a huge PITA to get any 3rd party Unix software to build anywhere, what with BSDs, SysV, SunOS, Ultrix, AIX, Irix, Xenix, A/UX, ... We ended up with "configure" scripts, and then autoconf scripts to generate configure, and automake to generate makefiles, and libtool and libiberty. (Xenix actually had "#define remove unlink" in a system header file!)

They were horrendous, and now are unnecessary, but we have CMake and it is getting to be a problem of its own. Things now mostly just need to build on linux, windos, and macosix, and everything is little-endian.

replies(1): >>26601029 #
7. neilv ◴[] No.26600967[source]
AT&T didn't share Unix as well as would be modern commercial open source convention, but there was also a culture of non-commercial sharing at the time. So, besides not wanting to step on the trademark or copyrights, and hear from lawyers, there was also a sense of fighting back against AT&T, even in marketing. (Also, Berkeley counterculture might've helped, I suppose.)

GNU = GNU's Not Unix

mt Xinu <= UNIX(tm)

https://ia601002.us.archive.org/3/items/Mt_Xinu_Mach_386_920...

8. neilv ◴[] No.26601029{3}[source]
Exactly. There was a time, circa 1990, where it seemed the majority of open source (though we didn't call it that) software on the Internet seemed to build easiest on a SunOS 4 SPARC, and that was one reason to prefer that.

I did write code portable to all of the workstation platforms (and VAXstations running VMS), and my approach was not to use separate scripts, but to write in a particular slightly-subset of K&R C (with portability macros to reintroduce some features), deal with compiler/architecture/library differences, and go through the docs and `cpp` output looking for preprocessor symbols that could help distinguish a particular platform (and you couldn't even use `#if`; it had to be `#ifdef`). For some purposes, cpp alone wouldn't be enough, and employer, which ran on all the workstations, had to develop its own portable graphics and GUI layers, IPC abstractions, etc. Makefiles were still heck for varying behavior between platforms, and you couldn't even use all the GNU Make features (though, in hindsight, maybe we should've, even when we had to keep using the vendor compiler toolchain), so complicated projects wouldn't necessarily be able to use a single Makefile alone.