For its time, though, AIX was highly innovative and was perhaps the first UNIX that bundled a LVM and a journaling file system into the standard system distribution (and not as separately purchased commercial products). It also has a single set of .a libraries which are both used as dynamic AND static libraries (courtesy of the XCOFF object file format). It also has uniform and very tidy naming conventions for command line utilities, e.g. anything that can create something (e.g. a user account, a user group, a logical volume etc) is prefixed with mk-, mutating commands are prefixed with ch-, destructive operations have the rm- prefix.
Pervasive performance metrics and counters across the entire system are also cool.
Lots of other small niceties I have forgotten about.
AIX configuration was opaque with a windows registry style setup.
All the standard utilities like sed, awk, etc., were versions from 1970. It was incredibly frustrating to use. They did supply some gnu software (IBM called it "linux" software), but it was managed through a second, separate, package manager, bare rpm.
Decade(s) after every other nix had snapshots, the way to get a consistent backup on AIX was to break your boot disk mirror and backup the orphaned disk (while praying you didn't have a disk failure).
Everything was spawned directly out of inittab. No sys-v/rc/etc. scripts.
A hard down could break the journal on their filesystem rather than having the filesystem journal save your data. An fsck would not fix the journal.
Most free software did not "just build and run" on AIX. Just about anything using autoconf required a custom wrapper around AIX's malloc to prevent it from segfaulting when being run, or fixing autoconf scripts to not mis-detect missing capabilities in AIX.
AIX was not a first tier system for many vendors. I had to spend time in a debugger providing info to our SAN vendor on issues with their agent for AIX (we never had issues with their software for Solaris, Linux, or Windows).
The hardware was funky. They did "neat" things like sharing a single CDROM drive between an entire rack of servers. But, to re-assign the CD drive, the IDE bus had to be re-assigned, as well as the PCI bus. And, invariably something would be blocking this, so "neat" in practice became a PITA.
On the positives, AIX was stable once everything was dialed in, just like any other NIX. It was also trivial to create a bootable DR restore ISO for a system. And, their debugger was pleasant to use when diagnosing core dumps.
"It used to be said that AIX looks like one space alien discovered Unix, and described it to another different space alien who then implemented AIX. But their universal translators were broken and they'd had to gesture a lot." -- Paul Tomblin
Not suggesting you didn't experience these things though of course.
Also, the RS/6000 and/or AIX was noticeably fast at some things. I remember a Systems Engineer being amazed that you could invoke a shell window (aixterm, IIRC), and it snapped instantly onto the screen, no lag.) The workstation vendors were often leapfrogging each other, but on that one metric, 0 perceptible time was new. I don't remember how compiles compared.
If you can pick up an RS/6000 on eBay, with licenses and install media, it might be a little fun to play with. And maybe either check that GCC will work, or that you're getting license and media for the compiler.
Today, though, there's so much neat stuff to play with atop Linux alone, that you could never get through it all. And, if you haven't already made your fortune and retired from paid work, things atop Linux are also more likely to be more directly relevant to paid jobs for current production environments, or at least to be better for resume keyword-matching.
The main selling point AFAICT was that it was on POWER, which has always been a pretty competitive set of processors, often faster than x86/64 in some (no doubt carefully massaged) metrics.
I think, like a lot of IBM systems and a lot of commercial unix, at that point it was ahead of the game in its system-paritioning capabilities, having LPARs much like z/OS (and Solaris Zones I guess).
I don't know if it has any other major unique selling points, as a C programmer I tended to focus on commonalities rather than differences!
Generally however with IBM’s rampant offshoring of support leading to a tremendous loss of institutional knowledge and rapid turnover of the offshore support teams, I’ve found unless you’re signing 7-9 figure renewal checks and paying for enhanced support, the support experience is way worse than it was around the 1990’s but still marginally better than other vendors.
My usage was circa 2000-2005. I loved smit and smitty, and would start new interns and juniors on AIX because the command lines to perform tasks would be generated and allow them to become productive quickly.
The jfs journaling filesystem was much better than ufs until sun got zfs into the formal distribution
I develop applications (c) on AIX and it is a bit different, I find it rather close to the BSDs. There are minor oddities, but I think it is rather good, and I personally like it.
As time goes forward, I think RHEL is going to be the direction.
It is a bit sad to see these proprietary UNIXs fall by the wayside, but most of the reason is their fault for the restrictive licenses they have.
Command options you take for granted aren't there in AIX.
Search on Unix stack exchange and there's always a more complicated "here's how you do it in AIX."
It definitely had a weird feel to it though!
That was a godsend when trying to move between half a dozen commercial unix systems 15 years ago.
This is misleading at best.
AIX didn't exist for IBM to purchase. IBM collaborated with Interactive Systems Corporation under contract to develop AIX in 1985 and released AIX Version 1 in 1986. IBM collaborated with Locus Computing Corporation, again under contract, to release Version 2 in 1992. Since the mid-1980's, IBM has poured massive development into AIX, which got so stable and feature-rich that when IBM tried to switch to Linux prematurely in 2005, its customers' and their systems administrators complained until IBM's Linux deployment was shelved for nearly a decade in deference to AIX (5, 6 & 7), and never really went away; AIX is still under active development.
(edit: I misremembered the project/time frame)
Is the CPU architecture so complicated? Is it so undocumented? I would think that projects like MAME have in the past reverse-engineered and emulated much more complicated and undocumented systems (some of which were even encrypted).
So why don't we have any Itanium emulators yet?
MAME emulates a host of odd things because fun games run on those odd things and people would like to play those without having the hardware. You can run AIX on lots of hardware, so running it on emulated Itanium wouldn't be very fun.
There is actually some work on adding ia64 emulation support to qemu, see:
Ten rendered irrelevant by their own competitor, AMD releasing "AMD64" (x86_64) a few years later
Now fast forward 20~ years into the future and we're building emulators for Intel's dead 64-bit platform to run atop effectively AMD's 64-bit answer to it
(and yes, while Linux was then the (much) preferred choice, we had prior experience with other *nixes)
i also remember a weird gui for administering everything. i assume that was the result of ibm's big investments.
It had a dedicated 1U server you had to buy too lol, what a grift
I rather doubt binutils supports that particular combination of items
*** Configuration ia64-ibm-aix is obsolete.
*** Specify --enable-obsolete to build it anyway.
*** Support will be REMOVED in the next major release of BINUTILS,
*** unless a maintainer comes forward.When AIX went multiprocessor around v.3.[45], they used a single kernel lock. Version 4 was a near complete rewrite to get rid of the single lock. I missed that fun, as I was no longer working for IBM, but I was sysadmining some AIX boxen during the 3.5-4 era.
Version 3.5 had a bug. mmap()-ing a file plus some extra space and then writing to the unbacked space would extend the file on JFS (in fact, that was how write() worked in the FS), but on NFS it would corrupt a FS-level lock so that any process that touched that FS would deadlock. Including the automounter. Which was itself single-threaded. UTCS's system programming class meant daily reboots for a while. 8-) AIX v4 fixed the problem.
AIX, like most Unixes, would happily allocate memory until you ran out of address space, completely unrelated to how much memory you had, because sparse matrices. The X server used this facility, for one thing. A process could tell the system not to kill it by handling a particular signal, but most of the system software didn't handle the signal. Including inetd. Which was usually the first thing killed when you ran out of memory, so you couldn't log into the system remotely.
https://en.wikipedia.org/wiki/IBM_RT_PC
People would telnet in to it from DOS machines on the campus network but it was great sitting in front of the machine with a huge 17" color monitor and multiple terminals.