Slashdot Mirror
IBM Wants Linux
jsse writes "In a news conference IBM's senior vice president Steve Mills said 'the company will gladly drop its version of Unix from servers and replace it with Linux if the software matures so that it can handle the most demanding tasks.' Now the Giant, along with many other companies, jump to Linux bandwagon. The question is wether this bandwagon is capable of carrying a Giant that huge. Or the question is: can Linux beats AIX?"
IBM has just jumped on the bandwagon?? They've been there for a while buddy. You can already buy most of IBM's software for Linux. They've been investing in Linux like crazy for the last 2 years
The (Hopefully) Great Slashdot Blackout Apr 21-27
Of all the unixen I have played with AIX is one of the worst. Only Conrol data's unix and NCR was worse. Their smit admin tool is pretty cool, but everything else looks like nothing else, and porting stuff to AIX is no fun.
-- Another senseless waste of fine bytes.
Perhaps the Open Source Community is up to the challenge, but AIX performs admirably in exactly the machines and situations in which Linux does the worst: multi-processor non-intel boxes with 4+ gigs of RAM. Right now, a person would be nuts to run linux in production on an RS/6000. The package stability on that hardware is sketchy, at best.
IBM's also spent a lot of time doing little things like graphics acceleration for their workstations that Linux can't yet strongly match.
As much as I'd like to see the death of AIX and dance on SMIT's grave, I think we're seeing the same story at the enterprise level as we always have: Operating Systems designed for enterprise hardware tend to be better on that hardware than Operating Systems designed for low-end microcomputers. If IBM dumped a hundred developers into pushing linux on its Power-based hardware, then we might see something to compete with AIX; as it is, there isn't a large enough install base for linux development to acheive critical mass.
IMHO, natch.
IBM did umm the patch to run on S390
(evil clock ticks evil interupts muhhaha)
so what do you mean ?
regards
john jones
p.s. list of kernel work from SGI looks like big iron in many ways I cant find a IBM page anywhere or heard of any of their work beyond the NGPthreads and s390 patchs
(oh yeah and the PowerPC port which IBM does a good job of helping out)
Linux Scalability
Kernprof (Kernel Profiling)
SGI kGDB (Remote host Linux kernel debugger via GDB)
NUMA (NUMA support in Linux)
Bigmem (Big Memory support for Linux)
Lockmeter (Linux kernel lock-metering)
Post/Wait (Post/Wait Synchronization)
SGI kdb (Linux kernel debugger)
Raw I/O (Enhancements to Linux raw I/O capabilities)
POSIX Asynchronous I/O (KAIO)
LKCD (Linux Kernel Crash Dumps)
STP (Scheduled Transfer Protocol)
well, will those quite familiar with aix please enlighten us with what linux could be missing? it's got xfs, lvm, ppc support. and that's about the end of what i know aix and linux now share.
Well, as a SysAdmin who manages 50 AIX servers and 20 Solaris servers I can try to offer some info.
As has been written in a couple of posts already, AIX is designed to run on enterprise-level hardware. The bonus is that since the OS and hardware all come from IBM, there is a single point of contact for those problems. There are some really cool things that separate AIX from other UNIX's:
* Most of the critical OS functions can be controlled via the SMIT interface.
* Unlike other flavours of UNIX, AIX does not use flat files to define parameters for daemons. AIX has all the relevant information stored in an internal database (The ODM).
* AIX ships with a journaled file system and file systems can be grown on the fly.
* AIX gives way more control over disk management than other flavours of UNIX. It is easy to implement the various type sof RAID. AIX also lets you control where certain files can be physically located on your disk, and during off-peak hours the system can move files around to re-organize the disks.
* It is trivial to create a complete image of the system on a bootable tape, so disaster recovery is a snap.
There are some downsides to AIX:
* AIX takes >5 minutes to boot.
* If the ODM gets corrupted, your system can be toast.
* Sometimes it is necessary to modify the ODM directly, and this can be a bit risky (see above)
* Third-party support for AIX is sketchy. It is better to use IBM applications where possible.
* IBM hardware is more expensive than the alternatives. You pay a premium for Big Blue.
Of the downsides, the last is the most significant. Not many non-IBM vendors write applications for it, and even if they do, Solaris, and Linux get more attention.
Sorry for sounding like a commercial for IBM, but I like AIX. It does some things very well, and is quite stable. My team manages a lot of mission-critical servers and AIX is nice to work with. We have talked briefly about Linux, the perception is that Linux is not yet ready for enterprise-class workload.
*** Where are we going? And what's with this handbasket?
Now if only all of the other vendors realized that they were selling hardware instead of UNIX
... they are in serious trouble because there is no money in hardware. If IBM thinks it can make money from Linux, then it will do so by putting the full weight of their name behind the product and selling professional services around its implementation.
It's time to analyse the facts: IBM, Sun, HP, and Unisys who are the main players in the high-end market (if we forget NCR, Hitachi, and Compaq for the moment) do not make their money from selling hardware, though I'm sure someone must have made a few $$$s from the two Sun E10Ks my last client invested in *grin*
They make their real revenue from the services which they provide to turn their hardware into fully-functioning enterprise-class systems which deliver real business benefit which affects the buyers bottom line.
I've never saw a client sue a manufacturer when something goes wrong (like not being able to sync two E10Ks in a failover cluster), but struggle on and on until the problem is fixed, happy in the knowledge that it will get fixed.
Remember this is Red Hats approach: the added value of their product is the service they provide. They don't earn large revenue's from selling boxed "7.2" distros on Amazon.
Remember what happened to all those "Linux" hardware companies trying to make money shifting boxes
Linux doesn't have STREAMS or TLI support; this means that device drivers are significantly different from the rest of the (commercial) UNIX(TM) world. There are third party patches, but STREAMS will never make it into the source tree, because Linus has explicitly rejected it.
Linux doesn't (AFAIK -- correct me if I am wrong!) have run-time tunable quanta (timeslices) for scheduling. The 'jiffy' (minimum unit of time measurement) is still tied to a 100 Hz clock (except on Alpha, where it is 1024Hz). Other run-time tunable parameters include features like page replacement algorithms (when to replace pages in memory). Solaris has a 'two-handed clock sweep' algorithm, and runtime tunable parameters include the 'spread' between the 'hands' and the speed of the 'clock rotation' (cf. Stallings, William. Operating Systems)
This isn't a linux problem per se, but the gcc toolkit doesn't make the best object code on any target other than x86. That's why solaris distributes gcc with solaris8 but remains confident you're going to get /opt/SUNWpro compilers. Same goes with Tru64, etc. etc. Since most commercial Unices run on non-Intel platforms (Solaris, AIX, Tru64, Mac OS X, HP-UX, IRIX) it generally means that you're not going to get the best executables if you use gcc (exceptions include Mac OS X)
As others have said, NUMA doesn't scale well. Linux proper doesn't have good 'processor affinity' (ie, tying a process to a specific processor).
Linux doesn't have good capabilities support or support for ACLs. While some capabilities exist (eg, CAP_DAC_OVERRIDE for embedded systems without filesystems, or the capability to bind to ports < 1024 without being root), a lot of big-iron systems need capabilities more approaching that of VMS or Windows NT kernel (note I said kernel, not Win32). You can get some capabilities with LIDS, but that's generally related to the CAP_DAC and CAP_MAC set, without much more. As for ACLs, you *can* find some patches, but they're most certainly not standard. Moreover, VFS isn't quite set for things like LVM, much less filesystem plug-ins (witness the hullaballoo in putting ReiserFS in the system because it didn't conform to VFS conventions).
Linux failover and high-availability generally applies to clustering solutions; I've yet to see things like hot-swappable CPUs or multiple backplane support in Linux.
This isn't to say Linux isn't great. I use it along with OpenStep and FreeBSD as my main operating systems. Most people don't need the above, or the penalties for uniprocessor x86 hardware are high (who wants STREAMS on an IBM PC-compatible?). But for commercial UNIX (TM), the above is pretty relied upon.
Three Step Plan:
1. Take over the world.
2. Get a lot of cookies.
3. Eat the cookies.
My work on the FOLK project (IMHO) demonstrates that all the technology needed to support highly-scalable Linux systems, with all the capabilities any corporation would expect from a top-of-the-line OS.
HOWEVER, the patches necessary to get Linux to that point are NOT yet part of the mainstream kernel, and in some cases, maintenance is...
This leads to the "not obvious" answer -- IBM has to do it's OWN "FOLK-style" project, to include the necessary capabilities, essentially forking the patches to keep them in line with the kernel.
IBM would ALSO have to do a thorough kernel audit. For for the FOLK project, we're looking at reverse-engineering the specification, fixing that, and then fixing the code to match. (The reason for using that approach is that specs are generally easier to debug, and are generally a LOT shorter, making it practical for one or two people to do.)
The argument about Linux "not scaling" is true -and- false. SGI showed that part of the problem was in the scheduling. HP has an excellent scheduler plug-in system, so you can have schedulers that are optimal for any given configuration, if you really want.
There's also a problem of latency, but the low-latency patches deal with many of those issues.
Of course, not all clusters are going to be simple arrays of processors. You might have nodes on a VME bus. No problem - the VME patch takes care of that.
Then, you have local-area and wide-area clusters. MOSIX and bproc deal with those issues, too.
For those still using transputers, there is an excellent b.004/b.008 link driver, out there.
Software base too limited? There's an ABI patch, which gives you support for a wide range of UNIX OS' binaries. The WINE patch is pretty decent, too.
All in all, if IBM play their cards right, and pull Linux out of the quagmire its been in, this could benefit both IBM and Linux enormously.
(Quagmire? What quagmire? The Linux kernel's rate of development has not been impressive, in the 2.[34] arena, even though development of Linux kernel code is as fast as it has ever been. Linus has wanted to slow down, but I worry that it has become -too- slow, and risks getting stuck in pure-and-simple human inertia. The IPv6 stack, for example, is now WAAAY behind the USAGI version, despite the fact that the Linux IPv6 has had many more years in which to develop and grow.)
I really and truly hope that this is the Miracle Grow for Linux, and not the Strimmer. I guess we'll have to wait and see.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
A few years ago (1995-1997) I actively maintained several AIX boxes as part of my job as a Unix sysadmin, and thus got to know the nasty beast first-hand. Granted, AIX is twisted and mutant, but there are a couple of areas where it does rock.
/etc/inittab -- it will happily let you edit /etc/inittab and do whatever you want with it, but it will quietly go behind your back and undo all the changes you made. To change /etc/inittab, you have to go through certain AIX commands that I have forgotten. There actually was a reason for this, but the details have slipped away.
/, because then you had to make sure to make the new disk bootable (and generally every AIX sysadmin would screw this up the first time and destroy the system as a result, but see the second point below). The volume manager lets you create and delete and resize filesystems on the fly; it wasn't so good at shrinking filesystems back in 1995 but I'm sure it's gotten better since then. My sysadmin style between Solaris and AIX was totally different: on AIX I'd create filesystems exactly as large as I needed them at the time, and would only grow them when they got to 99% full or so, whereas on Solaris w/o Veritas I'd simply slice up the disk into as few filesystems as possible and allocate all the disks at system install. The AIX way was lots more flexible, though it did involve the loss of the traditional BSD-style disk slice partitioning.
First let me pass along an analogy told to me (alas I don't know its origin). There were these two intelligent alien races. They didn't know each other's language, but they did have a universal translator that could translate between them; however it was somewhat buggy and didn't always do a terribly good job, but it was good enough most of the time. The first alien race had BSD Unix, and knowledge of System V Unix, and told it to the second alien race through the broken universal translator. The second race, thus enlightened, went off and wrote: AIX.
Humor aside, my AIX experience was something like "SUCKS" "SUCKS" "SUCKS" "oh wait, this is cool" "SUCKS", heh. What the open source community needs to do is identify the cool parts and add them to our own OSen. An example of what NOT to add would be the way AIX plays fast and loose with
Ok, on to the actual cool things about AIX. For those of you that have used Solaris + Veritas, you already know how useful it can be, and what a pain in the ass it can be as well. AIX has had a volume manager for longer than any other Unix, and does it quite a bit better. In 1995, it was no problem at all to take all the data/filesystems on one disk and migrate them all to another disk transparently without taking the OS down or even degrading performance very much. Well, except if you were moving
The other thing that AIX totally rocked on was its backup command, mksysb. This created a bootable tape with the entirety of the root volume on it (generally you'd have a root volume with all the system filesystems, and a data volume for your big-ass database etc.) Literally all you had to do to restore your system was change the keyswitch into 'Service' mode, pop the tape into the tape drive, and power the system on. It would boot off the bootable tape, find all the backup info, and restore the entire system to what it was at the time of the backup. No muss, no fuss, it just worked. It saved my bacon a couple of times, and it certainly made for less frazzled sysadmin nerves, knowing that no matter how badly you hosed the system, you could go to the last backup and you wouldn't have to even think to restore the thing, just pop in the tape, boot it up, let it do its thing, and go have a beer.
Anyways, these were the two brightest shining points of sysadminning AIX when I was doing it. I'd love to have either/both of these features on any OS I'm responsible for, and I'm sure that these are the kinds of things that IBM wants from Linux.
At least mafia-owned pizzarias make excellent pizza. Compare to Bill Gates.
They never put me under an NDA, so I assume this is public:
They are actually doing quite a bit of work porting linux to the iSeries (AS/400) and pSeries (RS/3000 et al). They are writing libraries that allow Linux applications to run on AIX.
One of their biggest projects is helping to fix/improve SMP support in Linux, and hopefully make it reach the point where it can handle the 24 processor systems they want to put it on. This includes improving I/O, and memory management, and handling large numbers of simultaneous processes.
These are things that Linux does okay on, but the power, resources and money that IBM is willing to put into it will help poor Open Source developers quite a bit.
The best part: They are releasing the code they write back to the community. They are actually helping. I think this is what you wanted to here. IBM is on our side. (in this case)
Source: I interviewed for one of the positions which would be porting Linux to the AS/400, now sadly named the iSeries. I didn't take it though. Don't be mad at me.