PowerPC Solaris on the RS/6000
virtuallyfun.com
virtuallyfun.com
If I may, a quick anecdote: back in MPK17 (now Facebook!) my office was next to that of Mike Sullivan, who was one of the lead engineers on on297, our internal name for Solaris 2.6. As part of his nature of running latest bits on everything around him, Mike had in his office (among many other things) a laptop. Over my years of working in Menlo Park, I can remember exactly one theft: one night, that laptop of Mike's -- and the laptop alone -- was stolen. The funny thing (and the reason this story made me think of it): it was a ThinkPad 850, an IBM PReP laptop running an internal build of on297 (to my knowledge the only one that ever existed) -- and I have often wished I could be there when the thief tried to unload what was surely the world's most arcane laptop, if not its most useless...
https://en.wikipedia.org/wiki/IBM_POWER_instruction_set_arch...
I recall wheeling an archaic 4ft tall tower format disk enclosure I found in a server room corner to my desk and connecting it to either the x86 dual CPU desktop I used (which had since lost all its side panels before I inherited it) or an ultra 30 I had there, I forget which.
I then set up the internal s10 build with ZFS and playing around with it. That's when I first become confident in the benefits of Solaris over anything else out there at the time. Used Solaris 10 as my main desktop for nearly 4 years
We even had intel itanium desktops for testing. Always referred to as the "itanics".
Getting GCC running on barely-produced prototype hardware system, on an ancient version of Solaris which itself was a particular pain to install, whilst entertaining and informing the reader about the history of the PowerPC migration circa 1994, is no mean feat.
What were the desirable/sexy features of OpenFirmware anyway? I remember typing occasional commands into it on old Macs (especially a Beige G3 running Mac OS 9 and, later, with varying degrees of grumpiness, OS X), mostly with the fear of god of bricking my system.
There was also that separate "crash" shell you could bring up once the machine had booted with a magic key combination involving the power button, and pressing something like 'R' would reboot it. I wish Apple was a bit more open about these programming interfaces – a bit like Solaris.
But my interaction with it was mostly like yours.
(shrug)
I know what EFI and UEFI are, but I've never heard of SSBA before, and I can't find anything about it on Google. What is SSBA?
It's basically UEFI for 64bit ARM:
https://en.wikipedia.org/wiki/Server_Base_System_Architectur...
Keep in mind the PC BIOS was and is a complete tire fire, and uses something like this https://en.wikipedia.org/wiki/Option_ROM to approximate support for the above. UEFI is a bit of improvement but massive and obtuse in comparison to OpenFirmware.
and x86, and ARM, and CPUs not even invented yet. Performance wouldn’t be optimal compared to native drivers, but decent enough to boot a workable system.
When I was admining Solaris boxes, it had useful boot-from-net options, both RARP and later DHCP-based JumpStart: this was many years before PXE. When I started using Mac OS X, during the pre-Intel days, all the various Mac hardware used OpenFirmware as well so that knowledge transferred over. OF was also used on IBM's POWER systems, and the OLPC "XO" computer used it with x86 chips.
If ARM ever wanted a common 'BIOS' system for their ecosystem, the OF could be a good choice (there are BSD-licensed options):
* https://www.openfirmware.info/Open_Firmware
UEFI is the other main pre-OS system out there.
More generally OpenFirmware allowed for platform-independent device drivers:
When I was in school, the astronomy dept. used a remote telescope in Wyoming. I guess there was dial-up to send commands to open the dome if the weather looked nice, to send coordinates to aim the scope, and to set exposure times for the CCD. The connectivity wasn't enough to download lots of data, so there was a data collection box; a 16mhz Sun IPC workstation in the "lunchbox" form factor, roughly 10"x10"x5". Someone had written a program in OpenFirmware Forth to read data off of whatever storage was on the scope via the IPC's serial port, and write it to the internal SCSI drive. After every observing run, a collaborator would put the IPC in a backpack and jog it up the mountain, so it could be plugged into a scope & terminal, and run the collector code to pull the data. A friend's first real job was maintaining that forth code; he still has nightmares about it.
Having system firmware that is that flexible is pretty nice, but really hard to write marketing copy for.
It makes my current GCC thing look laughable at best, but yeah the future is awesome!
$ qemu-system-ppc64 -m 1024 -serial stdio
[.. lots of boot messages ..]
E3407: Load failed
Type 'boot' and press return to continue booting the system.
Type 'reset-all' and press return to reboot the system.
Ready!
0 >Imagine a Unix that got an IBM working-over. When the RS/6000 workstations first came out, AIX was a big contrast to the more seat-of-pants workstation Unix of SunOS 4 (this was before Solaris 2).
Some of the AIX changes weren't only enterprise-y server management OS abstractions, but fun: AIX included a nice GUI hypertext browser for its documentation, in 1990 (possibly earlier).
AIX uses a database called the ODM for kernel and userspace configuration. This can be thought of something like 'nvlist' in FreeBSD and Solaris (https://github.com/fudosecurity/nvlist) but it has a more extensive object type system that is used almost everywhere in the system. This is in turn used to pass complex typed data between the kernel, userspace commands (like say logical volume management), and even an advanced daemon manager not unlike SMF or upstart or even systemd.
None of the above probably sounds particularly ground breaking in 2020 with systemd-ified Linux, but keep in mind most of this was in place 30 years earlier in the early 1990s with AIX 3.0. This was a time when, for instance, hardware support in other UNIX and clones still might mean custom compiling a kernel or at least invoking a linker to produce a new binary kernel.
Novice AIX users see smit and think "yuck I have to use a TUI to configure the system" but it is easy to do everything from the shell or automation. smit is just a rather gentle tool inspired by other IBM projects such as OS/400 and ISPF for menu driven user interfaces. Keep in mind systems like SCO also sported TUIs like this as it was a fad at the time to make UNIX seem more familiar to PC and minicomputer users.
One thing that is super bizarre, the kernel is also fully pagable. I suppose that made sense in the early '90s for diskless workstations where RAM might also be limited but it seems like unnecessary extravagance and complexity these days.
Having a test machine that took ~20 minutest to panic and reboot made the process extra fun.
It was one of the more annoying systems to develop drivers for that I've ever used. And I've done drivers for various BSDs, Linux, MacOS, ESX, Solaris, and even Tru64.
Back when I was in that game, we had an AIX guru spend a week or two teaching our kernel devs how things actually worked and at the end everyone was "even if I don't agree with how you did things, I understand how to make things work". We saw lot of folks try and shoehorn their view of Unix into AIX and it never ended well.
I did end up liking it a lot, and I wish I had more of them. Once you set aside your expectations about what a unix should act like, it was kinda fun.
AIX is Unix that a bunch of really smart folks with a mainframe mentality said "we can improve this...".
I'm wondering what kind of diskless workstations or thin clients IBM might've had in mind. Bottom-end engineering workstations would have at least a 100MB drive by the time the first RS/6000 models came out. But there were X terminals (usually diskless, sometimes with only 4MB RAM), and what I'll call "sub-workstations" that were compatible miniature engineering workstations (like the SPARCstation SLC at the time, which might've booted diskless, though hopefully you had 8MB RAM). Sun might've already been working on thin clients then (and had the slogan "the network is the computer"). IBM did have a few decades of experience inventing its own enterprise thin clients and terminals, so that theory seems plausible to me.
I've never been particularly negative about AIX at all, but I've been burned before by some of its ugly warts [1]. In particular, the fact that (unlike other platforms) errno isn't thread-local by default, and you have to -D_THREAD_SAFE_ERRNO to get a thread-safe errno.
You have to do the open-source work, though, because the vendor side is as close to abandonware as you can come. The OS is basically not touched unless they have to. For example, they gave up trying to actually fix their system headers to have C++ include guards, so they just hacked the compiler to extern C all system headers —- a terrible hack that GCC actually adopted as well to stay compatible. There’s no versioning of user-space library additions or changes, so you can’t easily make code forwards/backwards compat in the preprocessor. They gave up trying to follow modern C++ and pulled in a Clang front-end. User binaries remained broken for years until anyone complained about them. There are people there doing the bare minimum to add support for some new POSIX interface that comes out, but the headers are not “clean” in the same way that the Solaris ones are. Solaris headers and man pages are some of the best I’ve ever seen. They could constantly improve the system, but they don’t. They do what customers ask for and no more.
It might be great at taking some Fortran simulation and cranking the nodes up, but it’s not great at coming anywhere close to competing with Linux for general computing use.
If you want a dumpster fire for development work, I'd highly recommend HP-UX. HP-UX's stdio wasn't very std back in 1990s. What I remember is a bunch of syscalls seemingly existing but not actually working despite being OK with the same code on Solaris and Linux.
Somewhere around 2003-4, it appears all development basically consists of security patches and new Itanium hardware enablement, and aCC barely supported anything C++ related; its more like trying to use Borland C++, and GCC was really iffy, although it had the advantage that post PA-RISC, HP did adopt ELF.
The worst part is that the AIX compatibility layer IBM created for i is closer to Unix normalcy than AIX itself.
What's perhaps unknown to many is that the Linux volume manager was/is a straight clone of AIX's, with IBM terminology like logical volumes, physical volumes, and so on (the terminology itself being an extension of IBM's naming scheme on z/OS aka MVS, eg "logical/physical partition" for VMs with reserved channel bandwidth etc). Whereas FreeBSD's vinum was a clone of Veritas (in vinum veritas).
One thing that surprised me, but also made me feel quite at home, was that originally Aix adopted the same model for shared libraries as Windows, including import files.
As far as I can tell, this has been superseded by the traditional UNIX ELF model, although they are still supported.
As a retro computing and alternative architectures enthusiast I am visciously annoyed by how IBM treats enthusiasts. How in the world am I supposed test out, learn and be inspired towards such a closed ecosystem. I even owned an IBM RS/6000, but IBM wouldn't sell me the screen. Anyhow, even with financial means I cannot enter the world of IBM, as they hold OS closely guarded. Can I try AIX on emulator? No. Can I try it on hardware I own, yes/no. Can I learn Mainframe stuff? No. sigh Have I let my disdain for IBM's behavior frame my buying in various mega corps I advise? Yes.
It gave you a menu for everything you need to do on the system, but it would also give the command that it run. That was if you forgot how to do something, just fire up smitty, and get the command for future reference. It was very handy when writing scripts.
AIX was also, hand in hand with the SRC, one of the earliest Unices to do away with run levels. With the SRC present, there was only the one run level. Everything else became reserved.
Some people erroneously think things to be novelties that AIX was doing 30 years ago.
* http://jdebp.uk./FGA/unix-service-access-facility.html
And even port to IBM z/VM ("Sirius"): https://www.theregister.co.uk/2008/10/17/solaris_on_mainfram...
Unfortunately that died, because Oracle stopped being willing to cooperate with the port [1]. Of course, I understand why they might not see it as being in their commercial interests to support porting their OS to a competitor's hardware; but, I think their turn away from openness with Solaris accelerated its decline rather than delaying it.
[1] https://www.theregister.co.uk/2010/03/29/oracle_solaris_z_ib...
(Disclaimer: ex-Oracle employee, but I was never working on Solaris directly, just on higher-level middleware stuff which sometimes ran on Solaris, and I really don't know anything about this topic beyond what has been reported in the media.)
It even managed to run some x86 windows stuff - incredibly slowly (this was ~2005)
And it ran the windows 2000 shell preview as well! - though I may have installed NT 4 by then.
It ended up running Debian and being a mono test bench until it was retired to being an MP3 player for the home office.
Alas it was accidentally recycled along with a host of other stuff I was avoiding to deal with. Still it was fun to play with at the time!
Getting this running on ppc64(le) would be no small undertaking, but hey.