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.
Heh, yea I was sorely disappointed when I switched from primarily admining AIX to Linux for work. While I had played with Linux long before I got started with AIX, I had only ever used it on desktop workstations and such. Lots of things like ethernet channel bonding that worked fine out of the box on AIX took endless hours of fiddling to get it to sort of work under Linux.
As an AIX admin since 3.2.5 and someone who personally owns AIX hardware, when it comes to device support in AIX it either works perfectly or not at all.
You were not remotely alone. Dissatisfaction with Linux by professionals at the time (surrounding 2005) was more than enough to counter Linux's growing popularity, verve and momentum. Hard to believe that they actually caused Big Blue to act immediately and stop their premature global Linux deployment and their massive Linux marketing campaign cold. This proved to me, at least, that IBM was still alive, and did, in fact, if surprisingly, listen to their customers.
Hmmh? It's pretty well documented in Documentation/networking/bonding.txt in the Linux kernel source tree I thought. I needed our Linux boxes to do bonding somewhere in the 2011-2012 time frame. I don't recall much of a headache.
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.
There was an infamous memory leak with TCP sockets in 4.1.4. I came in one day in 1998 to find the kernel had killed everything off in an effort to save itself. It was successful. Fortunately that got fixed quickly.
Back when I dealt with AIX (1997-2001) it was common to deride it on usenet as “UNIX by and for drunk aliens” but I myself enjoyed its very regular naming conventions and extremely low footprint whilst under intensive memory load, which was common back then when RAM was stratospherically expensive. Excellent NUMA support too.
I think binary configuration files requiring specialized editors weren't all that popular. We had a RS6000 box in the lab, originally acquired to assure compatibility of our enterprise NAS appliance with AIX. Nobody liked that box and as Linux won the Unix wars, we were relieved that we didn't have to deal with it.
(and yes, while Linux was then the (much) preferred choice, we had prior experience with other *nixes)
I used to get a kick out of how the lil 'running man' in SMIT would fall over if a command failed :-P More sense of humour then I gave IBM credit for :-D
yeah it was actually a TUI. the screenshot looks right but the name "smit" doesn't sound familiar. i want to say it had a three letter name (this was circa 1996).
IBM sells (sold?) a thing called the HMC that manages multiple AIX machines, and their LPAR/WPARs. It was a web interface, maybe that is what you remember?
It had a dedicated 1U server you had to buy too lol, what a grift
Yeah, that's what started turning me off modern systems. None of my earlier hardware required it, but my POWER6 did. You can do some things in ASMI but if you want to reconfigure an LPAR or (horrors) add one, then you're digging out the HMC. It was just an off the shelf IBM x86 system running Linux, so I should image it and see if I can make a VM out of it instead of lugging it out of storage now and then.
The real grift was Capacity on Demand, which requires access keys to unlock hardware only IBM provides. That was a lot of "fun" when the system planar died and the new one didn't give me all my processors back. It took nearly a week to iron it out with IBM directly; even the VAR couldn't fix it.
I run my HMC in a VM running in libvirtd. IIRC, IBM provided the image as a VMware appliance, but it was quite simple to convert to something open source (at the cost of being an unsupported configuration, but it's not as if I could afford an IBM sorry contact to start with), and the result works great with my single POWER7 machine (8233-E8B)
My first experience with Unix was when I went to a new high school in 1991 and they had an IBM RT running AIX. This used the ROMP CPU before the POWER architecture.
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.
there was an AIX setup at UC Berkeley campus around 1987 with that big monitor.. a glimpse of the future in a way; thinking of it now, maybe primary authors were in contact with the grad advisors or something .. networking was more specific in those days, so hard to tell from the outside what the deals were..
I still wonder why neither qemu nor any other (open-source) emulator ever tackled Itanium emulation.
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).
I'd guess there's no motivation for an Itanium emulator, because there's no exciting application or system that was exclusively for Itanium.
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.
Part of the reason is that Itanium hardware has always been expensive. You need the full hardware to compare against (not just CPU but also to test firmware and OS). A number of years ago I was interested in kickstarting QEMU development for it by building on the existing work and adding a new virtual platform. But HP Itanium hardware in Europe is still prohibitively expensive for me and disappears quickly.
There is something deeply amusing about Itanium setting out to be Intel's new flagship 64-bit architecture before sinking under its own weight into niche use by effectively just HP
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
It doesn’t really run anything interesting, I’d guess. PA-RISC HPUX can be run on qemu already, if you want the ancient crappy HP flavored UNIX experience for some reason.
*** 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.
I didn't have much exposure to AIX as opposed to Linux and BSD but I did not enjoy working with it at all.
There are many others like me and I always attributed this to GNU's popularity. Every task that was simple on Linux involved reading manuals and looking up informational on AIX.
It's very interesting to think AIX was ported to such a foreign architecture as it was so deeply tied to the R/S 6000 hardware. IBM Austin is where AIX was developed in the 90s.
Not particularly. Any influence or overlap between them was in a strictly general sense. There are front end similarities but the internals are rather different, as would be expected for a rapidly evolving OS with lots of different authors. AIX didn't start to gel until around the 3.x or 4.x days.
It is hard to say about now, for most of the interesting AIX features are tightly coupled to the IBM hardware (e.g. dynamic CPU re-/allocation across LPAR's and a gazillion of other things), and the hardware is rare to come by nowadays.
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.
Oh, yeah, AIX is perhaps the only UNIX kernel out there that can preempt itself out of RAM into a swap space in nearly its entirety under a heavy memory shortage pressure, with the exception of the disk interrupt handler – to swap itself back in later, thanks to its peculiar VM subsystem design. It is no longer a material feature to have but is cool nevertheless.
I'm surprised at all the positive things being said about AIX in this thread. I thought it was pretty terrible (my priors were SunOS, Solaris, HP/UX, IRIX, Linux, BSD). Personally, I preferred any of the above over AIX.
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
Sounds like perhaps like most of your experiences were with pre-AIX version 4? No system is perfect for sure. By the time I started using AIX it was with version 4 and was moving to 5 and I can't say any of the problems you've described were things I had encountered with it. Certainly I had lots of problems though.
Not suggesting you didn't experience these things though of course.
I don't recall versions, but the broken journal was whatever version was current in the early mid '00s. The symptom was as if a hard shutdown (on an fs without a journal) even after a clean OS shutdown-- i.e., have to run fsck on every startup (deleting/creating new journal fixed issues; just notable to me since I've never observed similar fs corruption on any other platform).
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.
When the RS/6000 launched, AIX had some neat system management OS features and hypertext documentation that was better than any of the other workstation vendors at the time.
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.
I mean ... I used to write software in C that targeted AIX as well as HPUX, Solaris etc back in the 00s. It was fine. Posix compliant, had a C compiler, debugging was OK with dbx (IIRC you could get ddd to use dbx as its subordinate debugger, which was helpful).
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!
Correct, LPARs are akin to hardware partitions. Even my single-instance personal box has an LPAR and doesn't run on the metal (it just gets everything that's installed).
If you have a pressing business need for near-mainframe security and/or resilience for monoserver applications, and are willing to spend the money for it, its hardware, staffing, and the platinum IBM Support and training, in some cases it is still cheaper than rolling your own under Linux. IBM packages a one-stop shop for a RAS experience [1] that would need a deep bench of engineering talent to reproduce were you to roll your own equivalent in Linux. So some customers would rather pay IBM than try to build such an organization and for them, AIX is worth it.
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.
I really enjoyed it, although Solaris was easier as the user base was bigger.
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.
There's no sysctl, but there are definitely tunables and there's a whole subculture of jackbooted thug AIX admins who spend all day messing with them for peak performance. I'm not one of them, but I remember tweaking the network stack a bit on my 4.1 system back in the day.
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.
I disagree. I used to be an AIX administrator for well over a decade, got certified in basically everything related to AIX being on the side hard core FreeBSD user (still have some servers). In my opinion AIX is indeed different, but rock solid and fun to work with.
I've been since AIX v3. Moving to linux 10 years ago was like coming out of the stone ages.
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.
AIX pioneered technologies, like logical volume management, journaled file systems, etc. way before they were available in other Unixes. LVM existed for Solaris, but was an expensive third party add-on (Veritas Volume Manager, etc.)
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.