3 ms·

> Not a very nice Unix experience, analogous to HP-UX it was complex, and a bugger to configure C code on if you came from BSD land (Ultrix, SunOS/Solaris) Apo

by neilv 2y ago

> Not a very nice Unix experience, analogous to HP-UX it was complex, and a bugger to configure C code on if you came from BSD land (Ultrix, SunOS/Solaris) Apollo DomainOS (Aegis) was technically better than Unix. At some point (before my time), marketing must've decided they needed to be more Unix-compatible, and they did some clever things to also give it multiple Unix personalities (both SysV and BSD), while still keeping their original better personality. One place you'd feel pain around then, on most any Unix platform, is in downloading "portable" code off the Internet. Even for code already made portable in some sense, you'd probably have at least modify the Makefile, if not at least one C file, to select what portability you wanted, or to work around flaws in their portability. (SunOS 4 was my favorite for awhile, and at least half the reason was that code I'd grab from an FTP site was usually easy to get running, because it was probably developed on either SunOS or at least another BSD. Ultrix was also OK.) As a teen, I managed a porting lab, so I got to sysadmin and own-time develop on all of them. Writing portable C code for the different Unix workstations, I'd have to do it in a subset of K&R C, plus a portability mechanism that I built as I went (for architecture differences, library differences, C compiler differences). I do recall the Apollos being one of the more annoying Unix workstation platforms for C. I think they preferred safer languages for systems programming (again, they were ahead of their time), and maybe they didn't go all-in on developer ergonomics for C. Also, I guess the compiler probably predated ANSI C.

Pet_Ant 2y ago
I've seen the term in passing, but what are "Unix personalities"? Is it just different optional command line arguments to the common utilities? TAR vs Gnu TAR?
- Zach_the_Lizard 2y ago
  It's a bunch of small things: command line flags, whether a command line tool is even present at all, compiler built-ins / differences in behavior, headers possibly being in different places, compiler support for various language standards and more. Even to this day, it's not uncommon to find libraries that won't compile with one of GCC, clang, etc. or even the same compiler but Linux vs MacOS. It was even worse in ye olde times before package managers, I'm assuming. EDIT: I forgot to mention that System V and BSD are two of the major families. Both influenced Unix-like OSes far and wide, such as SysV style init scripts in certain Linux distros, MacOS being derived partly from BSD, Solaris being a continuation of SysV IIRC, and more. There was a rough standardization in where certain things could be found, command line flags, etc.
  - sillywalk 2y ago
    From an Apollo Domain OS Design document[0]: "In order to provide maximum portability of software from Domain/ as to other Berkeley or System V UNIX systems, Apollo provides two complete and separate UNIX environments, rather than a hybrid of the two. Any workstation can have one or both UNIX environments installed, and users can select which environment to use on a per-process basis. Two key mechanisms support this facility. First, every program can have a stamp applied that says what UNIX environment it should run in. The default value for this stamp is the environment in which it was compiled. When the program is loaded, the system sets an internal run-time switch to either berkeley or att, depending on the value of the stamp. Some of the UNIX system calls use this run-time switch to resolve conflicts when the same system call has different semantics in the two environments. The other mechanism is a modification of the pathname resolution process, such that pathname text contains environment variable ex- pansions. [...] When UNIX software is installed on a node, the standard trees (/bin, /usr) are installed under directories called bsd4.3 and sysS.3. The names /bin and /usr are actually symbolic links dependent on the value of an environment variable named SYSTYPE. That is, /bin is a symbolic link to /$(SYSTYPE)/bin. When the program loader loads a stamped program, it sets the value of SYSTYPE to either bsd4.3 or sys3.3, according to the value of the program stamp. Therefore, a program that refers to a name in one of the standard directories will access the correct version for its environment." [0] https://bitsavers.org/pdf/apollo/014962-A00_Domain_OS_Design_Principles_Jan89.pdf https://bitsavers.org/pdf/apollo/014962-A00_Domain_OS_Design...

by neilv 2y ago

Pet_Ant 2y ago

I've seen the term in passing, but what are "Unix personalities"? Is it just different optional command line arguments to the common utilities? TAR vs Gnu TAR?

Zach_the_Lizard 2y ago
It's a bunch of small things: command line flags, whether a command line tool is even present at all, compiler built-ins / differences in behavior, headers possibly being in different places, compiler support for various language standards and more. Even to this day, it's not uncommon to find libraries that won't compile with one of GCC, clang, etc. or even the same compiler but Linux vs MacOS. It was even worse in ye olde times before package managers, I'm assuming. EDIT: I forgot to mention that System V and BSD are two of the major families. Both influenced Unix-like OSes far and wide, such as SysV style init scripts in certain Linux distros, MacOS being derived partly from BSD, Solaris being a continuation of SysV IIRC, and more. There was a rough standardization in where certain things could be found, command line flags, etc.
- sillywalk 2y ago
  From an Apollo Domain OS Design document[0]: "In order to provide maximum portability of software from Domain/ as to other Berkeley or System V UNIX systems, Apollo provides two complete and separate UNIX environments, rather than a hybrid of the two. Any workstation can have one or both UNIX environments installed, and users can select which environment to use on a per-process basis. Two key mechanisms support this facility. First, every program can have a stamp applied that says what UNIX environment it should run in. The default value for this stamp is the environment in which it was compiled. When the program is loaded, the system sets an internal run-time switch to either berkeley or att, depending on the value of the stamp. Some of the UNIX system calls use this run-time switch to resolve conflicts when the same system call has different semantics in the two environments. The other mechanism is a modification of the pathname resolution process, such that pathname text contains environment variable ex- pansions. [...] When UNIX software is installed on a node, the standard trees (/bin, /usr) are installed under directories called bsd4.3 and sysS.3. The names /bin and /usr are actually symbolic links dependent on the value of an environment variable named SYSTYPE. That is, /bin is a symbolic link to /$(SYSTYPE)/bin. When the program loader loads a stamped program, it sets the value of SYSTYPE to either bsd4.3 or sys3.3, according to the value of the program stamp. Therefore, a program that refers to a name in one of the standard directories will access the correct version for its environment." [0] https://bitsavers.org/pdf/apollo/014962-A00_Domain_OS_Design_Principles_Jan89.pdf https://bitsavers.org/pdf/apollo/014962-A00_Domain_OS_Design...