Slashdot Mirror
Qantas Ditches Linux for AIX
An anonymous reader writes "Australia's No. 1 airline Qantas will shift their underlying platform running its internal finance systems from Linux to IBM's AIX next month as part of a wide-ranging technology transformation project. 'We're moving from a Linux platform to an IBM AIX environment — we did that to address some stability issues we were having', said Suzanne Young, Qantas group general manager for finance improvement and segmentation. The decision was made last year, as part of the planning for the rollout."
AIX is really old, mature, and definitely still maintained. It's a very good system.
I expect it will eventually be retired and replaced with Linux, but that's still years down the road. Right now, it offers some advantages, particularly on minicomputer class hardware.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Friends don't let friends enable ecmascript.
> Wait, who's Quantas?
Qantas is one of the world's oldest Airlines, and Australia's biggest airline. It also has one, if not the best, aviation safety record of any airline, ever.
AIX is hardly obsolete. Over half of our clients with large server systems use IBM hardware and AIX. IBM hardware tends to be cheaper than other vendors, and AIX itself is a very stable operating system and easy to configure and maintain via SMIT. There are many advantages to AIX: cheaper hardware, powerful POWER5 architecture to run on (IBM hardware scales quite nicely), decent support, and it is maintained by one of the oldest technology companies in America. Compared to Solaris and HP-UX, it's one of the best UNIX flavors out there, and doesn't have the stability problems seen with Linux. Linux is stable, but still quirky.
IBM still maintains AIX. It's not reaching end of support like Tru64 or OpenVMS, and with POWER6 and POWER7 coming in the future, will likely enjoy a long, long support future.
Besides mainframe and midrange systems, that's what you'd call "big iron".
They are also currently embroiled in a AU$11.1 billion (US$9.18 billion) takeover bid by private equity - which I have seen first-hand to make for interesting managerial decisions, particularly in I.T.
If successful (latest news today suggests it won't be...) it would be one of the biggest takeovers in Australian history.
Agreed x2.
.Net or even [relatively-mature] VB6 for them (the guy who interviewed me had a severe dislike for Microsoft - they tried them and got burned once). They wanted something that worked like a piston and never stopped.
companies need that stability to run. I went for a job interview in Oz for a company that processes sugar cane (CRS). When they're crushing the cane to get the sugary goodness out of it, they're running several plants 24/7 for several months. Furthermore these plants are spread over about 1000 km as the crow flies (indeed they use a plane to get between plants in emergencies). In their quest for stability, they use C and Fortran ("What?" I hear some of you young critters say) on VAX to run their automated weighing machines.
No fancy
Good on Qantas. Their in-flight meals aren't too bad either (I flew over from New Zealand - the country that sells Dells in shops).
Couldn't stand the weather
Not even remotely true. There are at least a dozen airlines with better records. Qantas benefits from it's small number of flights, and as soon as there's one crash, their safety record will instantly go through the floor.
I think I'd give the honor of best safety record to Southwest, who has flown 6-7 times more flights than Qantas, while still having zero accidents.
http://www.planecrashinfo.com/rates.htm
Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
For the record it is spelt Q without the U, QANTAS is an acronym for "Queensland and Northern Territory Aerial Services."
To AIX's credit, it has a lot of features which are still relatively immature by comparison on Linux. Logical volume management and RAID integration is the first that springs to mind; others include "stable as a 20-ton block of concrete".
On AIX, every volume is an LVM-managed one. Even the root volume. The logical volume manager is more like EVMS2 than LVM. (IIRC IBM developed EVMS2, which might explain that).
Well, A) We were going from Solaris to AIX, and B) Some people actually use applications they buy as a product, not as source code. And some managers aren't happy when you tell them "We need to rebuy this really expensive software now", and some are REALLY not happy when you tell them "I told you this months before we moved to AIX. In fact here's an Email trail showing me telling you that about 50 times in the past 6 months."
In the land of the blind, the one-eyed man is kinky.
NFS is not really a high point of Linux. I think the protocol itself probably isn't that suitable for modern needs, but the only network filesystem with a comparable installed base is CIFS/SMB... I suspect that to get over the installed base inertia, a better version of the same feature set will not be enough. I think the next jump in network filesystems will probably come from the need for clustered/distributed filesystems.
That's Winnie Blues to you mate.
Well, by far, most accidents occur during take-off and landing, so number of "flights" isn't a bad statistic to use. If you've got a better source for accident statistics by airline, by all means, cite it.
If there's anything to learn from this thread, it should be that most people's impressions and opinions are simply baseless and wrong... I strongly suggest finding hard numbers (as to average flight lengths) before jumping to such conclusions. You may well find the actual figures to be quite the opposite of what you believe they should be...
Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
Since you say the machines are locking up, I'm assuming it's not an application thing. I'm talking about things that cause kernel panics or worse, here. I'm also assuming the hardware is not defective, RAM is good, etc.
Easiest things first: Whenever I find a Linux install is unstable on hardware that I haven't used before, there are a few kernel commandline options I like to try. "noapic" solves a ton of interrupt/SMP issues, "noacpi" can also help stability, and "nomce" fixes (well, ignores) a lot of bogus MCE errors-- errors that always came up on hardware that was otherwise totally stable. MCE support seems to be much more accurate with recent kernels and hardware, though. Bonus option, "nommconf" can help if a PCI device, say a Myrinet card or RAID controller, isn't seen by the kernel, even as an unknown device in lspci.
Also, since you mention Redhat, I've found situations in which last couple of RHEL4 kernels tend to crash within a few days (maxing load on 4 cores, disk, and network the whole time). I don't know if installing a non-RHEL kernel is an option for your company. If you're running RHEL3, a vanilla kernel.org kernel might be pretty painful due to some things like SELinux. On RHEL4, kernel.org kernels are very easy to install in practical terms but may not be allowed by policy. If it's an option, I've been having no problems with 2.6.19.5. That's probably rather new for a company wide deployment, but if your crashes are repeatable/testable, and that does fix it, it could at least point the way.
Southwest have NOT had zero accidents. They've had at least two runway overruns in the last three or four years (one of them with fatalities, and the other was just a few yards from being fatal since the aircraft nearly hit a gas station).
Oolite: Elite-like game. For Mac, Linux and Windows
"Isn't IBM AIX really old, not really developed any longer and largely obsolete? How can moving from linux to that be a good idea?"
AIX is mature, it is stable, it is well maintained, and it is not obsolete. AIX hardware and software are more much more reliable and stable than Linux and the hardware that it runs on. AIX will be supported for a very long time. Linux is very good in smaller, less demanding environments; AIX, HPUX, and Solaris are the gold standard of large enterprise level systems.
10 years ago, I jumped onto the Linux bandwagon. Last year, I started brushing up my Solaris skills and I'm now working to add some Sun certs to my RHCE.
:)) and forsake many useful updates and features in tools like Samba and then you'll get your stable API / ABI. Or you can go with a bleeding edge distro and never have ISV support for your products. Neither of these is a great choice for us, we'd like something in the middle, but I can't find a commercial vendor providing this today.
Linux just is NOT ready for the enterprise. Red Hat, the 'biggest' Linux company out there just hasn't learnt to run with the big dogs yet.
Technical issues about the OS aside, Red Hat just don't present as a professional company. After dealing with Sun and MS for years, dealing with RH is a bit of a joke. £300k doesn't even buy you any media! A visit to their head office in North Carolina sees the presentation done from a projector on a desk, with bits of cardboard to stop it wobbling. Trial versions of the software to keep your skills up to date ? Don't be silly - you have to use CentOS for the free tools and you're SOL for their closed source tools like Satellite or RHN Proxy.
Once you go from there to the support issues, RH take an even bigger beating. 'Just reboot it' is NOT the first (and for 3 hours, only) option I want to hear when I have a production server locked up. And 3 hours to escalate to second line is NOT good enough for a platinum contract (Premium in RH terms?). If I wanted that kind of solution and support, I'd go back to sending my cheques to Redmond.
At a technical level, Linux is NOT keeping up and is barely fit for datacentre purposes. Only recently has the LVM stuff got to a useful level where we can do multipathing (with IO on both paths) without needing third party software. It's not great yet, and the tools to maintain it are badly documented, but since we just can't get Veritas for 64bit RHEL4 (or couldn't when I checked a few months back), it's the only choice we have.
The constant changes to the API and ABI are a total PITA for ISVs. You can either go with RHEL / SLES (or CentOS if you're broke like me
Lastly, the tools. I'd really rather not get started on the issues with the tools that RH provides to manage systems. Suffice to say, not being able to do LVM setup using the text installer came as a bit of a shock. And when confronting RH on the severe deficiencies in their text-based admin tools, I was just told to spend 8k on a closed source RH product to resolve these... How much MORE like MS can you be? Yeah, we know the base product is a bit broken, but that part isn't really our focus - here, try this expensive fix.
Documentation is in a similar state with some stuff being very well documented and other stuff, poorly if at all.
In the end, Sun still have a better understanding of what the enterprise needs, both from a support and an OS point of view.
Yes, you are right. I have seen large BSD deployments and they are extremely stable. Personally, I am a big proponent of FreeBSD and OpenBSD. They are very stable which might explain why there is less bleeding edge hardware support. I am actually not surprised at all.
Linux/x86 has forced IBM, Sun and HP to be competitive with much cheaper hardware and support and when pricing servers with 32GB+ of ram, there isn't much difference between Linux/x86/support and AIX/HPUX/Solaris and when you do TCO analysis, they are all very similar.
There has been a major drop in the high end *nix distributed computing environment pricing brought on by Linux, to the point where it isn't that much of a cost savings switching between Linux and HPUX/AIX/Solaris (or the other way). I don't agree that AIX is more stable than Linux, but AIX isn't that much more expensive anymore.
Ok, so here goes.
./ account number is 5 digits(as well as my ICN number, yeah who cares). I am also in school working with HPC(High performance computing) building, programming and maintaining beowulf clusters. My point is this, I have more experience with Linux than most.
.debian.org/msg17434.html
Big Freaking Disclaimer, I work for IBM in support...
That being said, I use Linux as my primary desktop both at work(thank you IBM) and at home. Debian on both, though I do have to say, I just built a MythTV box and used Ubuntu(faster updates/multimedia/interface acceptable to the female counterpart) and I am VERY impressed with Fiesty Fawn 7.0.4. I have been running Linux since the pre-1.0 kernels and it has been my desktop of choice since 98 and my
Being that I work at IBM, I also have alot of experience with AIX. While personally, I hate AIX(any UNIX that cannot be administered via vi is shit in my book, take that any way you like), AIX is EXTREMELY stable, and IBM makes sure of it. I have seen the testing they do to both the hardware and software(OS level at least) and it is centered around stability/reliability first and foremost, followed closely by serviceability(tracing facilities, error reporting/recording), performance and then ease of use. Now, this order is not true of all commercial UNIXs, Solaris is used more in scientific applications/number crunching and tends to focus a bit more on performance over serviceability(surely) and possibly even stability. I have seen more Solaris machines bite it than AIX machines, but this is more likely hardware related that OS related. In either case, they are inherently more stable than Linux.
Yeah, I said it, and its true. While Linux is a WONDERFUL and EXCITING desktop OS, and makes a damn fine department server, the OS itself, and not even so much the OS, the kernel is pretty darn stable(dont believe me, boot up a Linux machine and dont do anything, it will run until something harware/power related dies). It is the surrounding libraries and applications that are not quite up to snuff. We in support see this a number of times. Here is an example:
Currently today, right now, PDKSH that is available on http://web.cs.mun.ca/~michael/pdksh/ is completely broken when it comes to job control. Now most of you have no clue what I mean by that, but a quick explanation is placing jobs into the background with a '&' at the end of the command line. Now programmatically, there are a number of way to do this from the shell and on PDKSH, they are completely broken. I tracked this down back in 2002 and a bug report was submitted to the developer of PDKSH. Every major Linux disribution shipped this binary in 2002, so we actually had to package and ship our own version of pdksh to make things work. Redhat later switched to AT&T's ksh, because pdksh was too broken to fix for the most part. Roll forward to 2004, we ran into a really strange problem with one of the products I support(Tivoli) and worked it for 2 months, tracing calls/checking stack traces/and general debugging and in the end, it worked right back around to this bug in pdksh. The customer had installed our pdksh, but later, had replaced it with SuSE's, which at that time was still broken. A colleague of mine finally sat down, on IBM's dime mind you, and took the time to report this bug to all the major distributions, here is the one from Debian:
http://www.mail-archive.com/debian-bugs-dist@lists
This is just one package. There are a thousand stories out there that are the same. I know we regularly submit libc patches as well because we find stuff that is borked in there.
So all in all, its not really the kernel, so much as it is the rest of the building blocks that one must use within Linux. You could use your own compiler and libraries, but then are you really using
Speaking as someone with both a RCHE and an AIX cert, I have to disagree.
First, HACMP is an outdated technology.
HACMP setup/configuration is definitely not for the faint of heart nor untrained, but version 5.3 (I haven't used 5.4 yet) is a very polished and stable product. The only issues I have ever have with a HACMP cluster event were directly related to the application or admin error.
Second, the ODM is a piece of crud...Give me a proprietary db that I can't see, and I'll throw my hands up.
odmget, odmput? Not elegant, but the point is that you rarely should have to directly interact with the ODM.
Lack of a 'true' single user level.
In 10 years I have yet to see a need to do this on an AIX server.
LVM is less than adequate. Yep, I paid $1M (US) for a big honking machine, but can't figure out how to convert PP to Mb. ouch.
lsvg vgname, get PP size in MB, multiply or divide as needed
system tuning/kernel is a bit archaic.
Can't argue too much with this one (as far as ease of tuning), but with the assistance of SarCheck you can wring every bit of performance out of AIX.
Ignore anything I said above, I actually agree with everything you believe - mod accordingly.
Page zero on AIX is mapped read-only and guaranteed zero.
So writes through a NULL pointer crash just fine.
Reads through a NULL pointer read zero.
There's a reason for this. It's a performance optimization; remember, AIX 2 and up run on superscalar pipelined CPUs, which everything is today, but it was a bigger deal in the RT PC and first-generation RS/6000 days. Well, the biggest deal on the RT PC was keeping a fire extinguisher close at hand, the RS/6000 was rather better.
What that means is, say you have C code like this:
On AIX, the compiler can generate pseudo code like this (not valid syntax or opcodes):
The important part being, the load through (*somewhere) has been started before the pointer is verified as valid. This allows the compiler to avoid issuing a no-op; the optimizer knows load gr3,(0) is safe (== won't fault), so it doesn't have to wait for the test to complete. Actually, on POWER, it doesn't have to put a no-op in, the processor will just stall the pipeline if it sees a set and use of a register too close together.
Also, AIX guarantees that uninitialized storage (BSS) is zeroed before being given to the process; newly allocated pages are also zero. (This is at the brk(2) level.) In fact, if you aren't using the C memory routines or derivatives (malloc/free), the fastest way to get blocks of zero on AIX is to disclaim(2) the memory and then brk(2) it back in.
As another poster said, this is to prevent information leakage between processes.
And yes, assumption that "all OSes are like this OS" is the mother of all porting nightmares. Just try and get an "everything is Solaris" program working on a non-ELF based system. Apple's actually done a fair job of allowing that to work; but most other non-ELF systems are a big pain for people who assume the Solaris (and therefore Linux) dynamic linker will fix their mess--like their violations of the ANSI C++ One Definition Rule.
Having done the same move (Tru64 to Linux) and had similar teething problems I can state the following as fact.
The stability issues we had were all down to HP's drivers for their 6404 Raid cards and the Insight Agents.
If we removed the agents (or switched them off if I remember right) the system became solid as a rock.
A few months of working "with" HP on the issues had bugs fixed in the next version of the drivers and the Insight Agents.
I left that company a few years ago now - their big Linux machines haven't fallen over since then. Downtime only for CPU upgrade and extra RAM. How do I know? I still get SMS alerts from HP SIM when these machines go down (or don't as the case may be).
I'll never argue against using Tru64. Those machines were as solid as it got. But the cost of hardware was too much. Moving to Linux gave us much better bang for buck and (eventually) machines that were every bit as reliable as the Tru64 Alphas.
Cheers
D