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.
Early '00s for the malloc issue with things that used autoconf. I first ran into this when attempting to build AIDE + deps on AIX. Creating a wrapper around AIX malloc and linking it in was easier than re-working a bunch of autoconf scripts.
I haven't touched AIX since the late mid-00s. My comparisons were to the state of its contemporaries, at the time.
Yes, nothing is perfect, but AIX was the wartiest, and experience from other NIX transferred the least, of the commercial NIXs that I've used (IMO, Solaris was the nicest of the commercial offerings [pre-Oracle]). But, it looks like AIX was liked/loved by quite a few folks per this comment section-- I wish we'd had some of these folks on staff at the job with AIX boxes, so those of us less enthusiastic about the platform wouldn't have had to deal with it.
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!
I'm guessing these lpars all have separate kernels.
lpar - VM or domU or such
wpar - zone or jail or container or such
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."
But it's the same for every language. Something that's a stupid hard problem that takes a huge effort to solve is suddenly a one-liner in the next release.
That was a godsend when trying to move between half a dozen commercial unix systems 15 years ago.
It definitely had a weird feel to it though!