6 ms·

I am curious, for people who are familiar with AIX and Linux, what are the main differences day to day?

chologrande 4y ago
Storage, Virtualization, and general UX are just completely different. Standard unix utilities are either not available or just different enough to make life hard.
- johnklos 4y ago
  The standard Unix utilities on AIX are a pain as well.
envp 4y ago
Best summarized by this quote from a coworker: “AIX is what you’d get if aliens implemented a UNIX.” Utilities exist, but they tend to be different. There’s also oddities like the compiler (xlC) emitting code that is able to dereference null pointers, with the zero page. It’s a valid but odd choice of undefined behavior. [1] [1]: https://groups.google.com/g/comp.lang.c/c/OJwY1pWFYhE https://groups.google.com/g/comp.lang.c/c/OJwY1pWFYhE
- sllabres 4y ago
  This is a old quote and IIRC was e.g. for the way AIX handles services (SRC / System Resource Controller) and stores configuration data (ODM / Object Data Manager). It felt 'alien' for admins used to use rc scripts (which are possible too) and files in /etc (used in aix too). Now, nearly three decades later, we have even more automated and integrated mechanism 'systemd' and I think that there would be still features worth adopting from AIX. Not the first time i have such thoughts with an OS slowly vanishing.
- skissane 4y ago
  > “AIX is what you’d get if aliens implemented a UNIX.” The first version of AIX, for the IBM RT PC, actually ran on top of a microkernel written in PL/I, called VRM - how’s that for alien. Subsequent versions moved closer to the Unix mainstream by dropping the PL/I microkernel.
Tor3 4y ago
Yes, storage and virtualisation, as was said, but that sounds less different than it actually is. It feels more like a mini vs mainframe difference. AIX is vastly larger in that respect on AIX 7 than on AIX 5L, for example. IBM seems to have invested a lot of effort into making AIX huge in VM, clustering, storage, and more . AIX 7 is much more into this than e.g. AIX 5L. As for standard Unix tools - or rather "Linux" or OSS tools these days - they are not that difficult to find and are for the most part readily available. IBM used to supply a lot of that directly, but these can be found elsewhere and for myself I work on AIX more or less as I would on Linux. When that's said, if you don't actually need the AIX-specific features you can as well run Linux. But if what that site indicates is correct then I'm a bit surprised - IBM seems to have invested a lot in those "differences" the last couple of decades and it's strange if they're abandoning that, or planning to - yes, you can run Linux on IBM hardware, but then.. why? Sounds to me they'll lose HW sales if they abandon AIX. Their strategy has been to make the system more and more Linux-like in many ways (compiler has gcc-compatible options, as one example), but at the same time add large-scale features which Linux doesn't have. Which is clearly why AIX has survived while none of the others have (IRIX, Solaris, Tru64..) - those Unix systems didn't really bring anything more than a Linux system could. AIX does.
- sllabres 4y ago
  > you can run Linux on IBM hardware, but then.. why? Don't know if this counts, but you get much memory with fewer cores. For software where licensing is coupled to cores this quickly gets cheaper. And for what I see in production the hardware is more reliable in comparison to two large x86 vendors. This is of course based on a small number of systems (n~100)
bitcharmer 4y ago
Complete lack of standard tooling and GNU utilities. Even the tools that seem to have been "ported", like ps looked like work in progress rather than something intended for production use. AIX was a steaming pile of shite for a Linux or Free BSD power user.
pjmlp 4y ago
A big difference is that toolchain is somehow related to how Windows works as they are both COFF based. So you also get shared libraries with private by default and import libraries for example. It also supports lazy loading of dynamic libraries, where the OS implicitly loads dynamic libraries when it hits an import stub.
skissane 4y ago
I remember years ago having to port some C code I wrote to AIX. Hit this really weird bug - on AIX, errno is not thread-safe by default! Solution is simple: add -D_THREAD_SAFE or -D_THREAD_SAFE_ERRNO to CFLAGS. Took me a few hours of scratching my head before I worked it out though.
- lelanthran 4y ago
  > Hit this really weird bug - on AIX, errno is not thread-safe by default! Isn't that a conforming implementation? (IIRC[1], errno is thread-local, not necessarily race-safe. i.e. it's visible to interrupts, which could change it) [1] No doubt someone will correct me if that is wrong.
  - jabl 4y ago
    Many old-school unixes were developed in the single-thread days. When they added support for threads they were an opt-in feature, like the above macro definitions, and using libraries like libc_r.so instead of libc.so, and so on. AIX even had compiler wrappers like xlc_r which set the relevant preprocessor macros and linked in the correct runtime libraries. When the Linux glibc 2.x/NPTL ABI was taken into use, it was clear that threads were not a passing fad and stuff was made multi-thread (to the extent the API can enable that, of course) by default, so there was no need for carrying around both a single-thread ABI and a multi-thread ABI.
  - skissane 4y ago
    > IIRC[1], errno is thread-local, not necessarily race-safe. i.e. it's visible to interrupts, which could change it) On AIX, errno is not thread-local by default, it is a global variable shared by all threads. Only if you set one of those two defines, does it become a thread-local variable. On every other platform I’ve ever written code for, errno is thread-local by default and no special define is needed to make it so. Hence, when you port to AIX, if you don’t know about those defines, you can get all these weird race condition bugs related to error handling, because suddenly errno isn’t thread-local any more
sys_64738 4y ago
AIX command line was so cryptic that everybody used SMIT to figure out the commands. You then copied/pasted from there. Linux never had such a tool.

Storage, Virtualization, and general UX are just completely different. Standard unix utilities are either not available or just different enough to make life hard.

johnklos 4y ago
The standard Unix utilities on AIX are a pain as well.

envp 4y ago

Best summarized by this quote from a coworker: “AIX is what you’d get if aliens implemented a UNIX.” Utilities exist, but they tend to be different. There’s also oddities like the compiler (xlC) emitting code that is able to dereference null pointers, with the zero page. It’s a valid but odd choice of undefined behavior. [1] [1]: https://groups.google.com/g/comp.lang.c/c/OJwY1pWFYhE https://groups.google.com/g/comp.lang.c/c/OJwY1pWFYhE

sllabres 4y ago
This is a old quote and IIRC was e.g. for the way AIX handles services (SRC / System Resource Controller) and stores configuration data (ODM / Object Data Manager). It felt 'alien' for admins used to use rc scripts (which are possible too) and files in /etc (used in aix too). Now, nearly three decades later, we have even more automated and integrated mechanism 'systemd' and I think that there would be still features worth adopting from AIX. Not the first time i have such thoughts with an OS slowly vanishing.
skissane 4y ago
> “AIX is what you’d get if aliens implemented a UNIX.” The first version of AIX, for the IBM RT PC, actually ran on top of a microkernel written in PL/I, called VRM - how’s that for alien. Subsequent versions moved closer to the Unix mainstream by dropping the PL/I microkernel.

Tor3 4y ago

Yes, storage and virtualisation, as was said, but that sounds less different than it actually is. It feels more like a mini vs mainframe difference. AIX is vastly larger in that respect on AIX 7 than on AIX 5L, for example. IBM seems to have invested a lot of effort into making AIX huge in VM, clustering, storage, and more . AIX 7 is much more into this than e.g. AIX 5L. As for standard Unix tools - or rather "Linux" or OSS tools these days - they are not that difficult to find and are for the most part readily available. IBM used to supply a lot of that directly, but these can be found elsewhere and for myself I work on AIX more or less as I would on Linux. When that's said, if you don't actually need the AIX-specific features you can as well run Linux. But if what that site indicates is correct then I'm a bit surprised - IBM seems to have invested a lot in those "differences" the last couple of decades and it's strange if they're abandoning that, or planning to - yes, you can run Linux on IBM hardware, but then.. why? Sounds to me they'll lose HW sales if they abandon AIX. Their strategy has been to make the system more and more Linux-like in many ways (compiler has gcc-compatible options, as one example), but at the same time add large-scale features which Linux doesn't have. Which is clearly why AIX has survived while none of the others have (IRIX, Solaris, Tru64..) - those Unix systems didn't really bring anything more than a Linux system could. AIX does.

sllabres 4y ago
> you can run Linux on IBM hardware, but then.. why? Don't know if this counts, but you get much memory with fewer cores. For software where licensing is coupled to cores this quickly gets cheaper. And for what I see in production the hardware is more reliable in comparison to two large x86 vendors. This is of course based on a small number of systems (n~100)

bitcharmer 4y ago

Complete lack of standard tooling and GNU utilities. Even the tools that seem to have been "ported", like ps looked like work in progress rather than something intended for production use. AIX was a steaming pile of shite for a Linux or Free BSD power user.

pjmlp 4y ago

A big difference is that toolchain is somehow related to how Windows works as they are both COFF based. So you also get shared libraries with private by default and import libraries for example. It also supports lazy loading of dynamic libraries, where the OS implicitly loads dynamic libraries when it hits an import stub.

skissane 4y ago

I remember years ago having to port some C code I wrote to AIX. Hit this really weird bug - on AIX, errno is not thread-safe by default! Solution is simple: add -D_THREAD_SAFE or -D_THREAD_SAFE_ERRNO to CFLAGS. Took me a few hours of scratching my head before I worked it out though.

lelanthran 4y ago
> Hit this really weird bug - on AIX, errno is not thread-safe by default! Isn't that a conforming implementation? (IIRC[1], errno is thread-local, not necessarily race-safe. i.e. it's visible to interrupts, which could change it) [1] No doubt someone will correct me if that is wrong.
- jabl 4y ago
  Many old-school unixes were developed in the single-thread days. When they added support for threads they were an opt-in feature, like the above macro definitions, and using libraries like libc_r.so instead of libc.so, and so on. AIX even had compiler wrappers like xlc_r which set the relevant preprocessor macros and linked in the correct runtime libraries. When the Linux glibc 2.x/NPTL ABI was taken into use, it was clear that threads were not a passing fad and stuff was made multi-thread (to the extent the API can enable that, of course) by default, so there was no need for carrying around both a single-thread ABI and a multi-thread ABI.
- skissane 4y ago
  > IIRC[1], errno is thread-local, not necessarily race-safe. i.e. it's visible to interrupts, which could change it) On AIX, errno is not thread-local by default, it is a global variable shared by all threads. Only if you set one of those two defines, does it become a thread-local variable. On every other platform I’ve ever written code for, errno is thread-local by default and no special define is needed to make it so. Hence, when you port to AIX, if you don’t know about those defines, you can get all these weird race condition bugs related to error handling, because suddenly errno isn’t thread-local any more

sys_64738 4y ago

AIX command line was so cryptic that everybody used SMIT to figure out the commands. You then copied/pasted from there. Linux never had such a tool.