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.
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
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.