IBM Wants Linux 464
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?"
Jump on the bandwagon? (Score:3, Informative)
Easy (Score:3, Informative)
If... (Score:2, Informative)
Sounds like a sarcasm.
Re:This sounds like... (Score:5, Informative)
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.
Re:$ is made from HW, not SW (Score:2, Informative)
Wladawsky-Berger on Linux and open standards (Score:2, Informative)
Duh... (Score:2, Informative)
Two more points.
1 - Linux isn't AIX and has a ways to go. Same with OS/400, etc.
2 - IBM doesn't want to control Linux as long as it can do what they need. They got in trouble for giving their OS away before. Giving away somebody else's OS I assume is OK though.
AIX has been planned for canning for over 2 years (Score:1, Informative)
what big iron ? (Score:3, Informative)
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 [slashdot.org]
Kernprof [slashdot.org] (Kernel Profiling)
SGI kGDB [slashdot.org] (Remote host Linux kernel debugger via GDB)
NUMA [slashdot.org] (NUMA support in Linux)
Bigmem [slashdot.org] (Big Memory support for Linux)
Lockmeter [slashdot.org] (Linux kernel lock-metering)
Post/Wait [slashdot.org] (Post/Wait Synchronization)
SGI kdb [slashdot.org] (Linux kernel debugger)
Raw I/O [slashdot.org] (Enhancements to Linux raw I/O capabilities)
POSIX Asynchronous I/O [slashdot.org] (KAIO)
LKCD [slashdot.org] (Linux Kernel Crash Dumps)
STP [slashdot.org] (Scheduled Transfer Protocol)
Re:What are the weakest parts of Linux? (Score:2, Informative)
1. good scalability on large NUMA and SMP systems
2. A proven, full-featured LVM that works
Also, regarding the journaling file systems. How many vendors are selling Linux with them now? IBM, Sun, Veritas, had it for years. So, if you're looking for a proven, scalable, enterprise platform, with good vendor support, applications, etc consider IBM RS/6000 or Sun.
Re:It's about time (Score:2, Informative)
Hey, check your facts before making broad statements like "Sparcs are slow at RC5, so Intels are better". Somewhere in the distributed.net docs is stated that most RISC CPUs lacks an important assembly instruction (n-bit rotations, if I remember correctly), as opposed to x86 and PowerPC. Guess what, that instruction is essential for RC5 cracking, and Sparcs, Alpha and co. are slow. You might want to check DES cracking speeds, where RISC CPUs are flying at unbelievable speeds, leaving common x86s in the dust.
It all depends on the particular application that you are testing.
Sure, there are marginal improvements in total system performance from things like cache, bus speed and so on. They are marginal.
Again, no. They are marginal when you write "Hello, world" programs. But for heavy computing/database and such memory bandwith/latency is crucial. Even in the PC world, just ONE cpu can be stalled by the lack of memory bandwith. Look at the Pentium 4 test at Anandtech [anandtech.com]: in particular applications (mp3 encoding, streaming in general) there's a 30% difference between different chipsets).
Guess what happens when you have 4 CPUs on a single board, all begging memory access to random locations to complete their database lookups...
My $.02 (Score:5, Informative)
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.
Re:It's about time (Score:5, Informative)
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
IBM's Strange Affair With Linux (Score:2, Informative)
Having worked in both places, and ridden both beasts, I can give people a qualified yes when it comes to wether or not IBM wants to very deeply embrace Linux. Why a "qualified yes"? I'll try to explain:
IMHO, for the year or so I worked at IBM as a contractor, Linux sort of went from a curious oddity the engineers tossed around on the floor to something that upper management decided would be good for the company to look into. Although I obviously cant speak for IBM as a whole, or even the division I worked in, it seemed pretty clear to me that IBM was trying to move as fast as possible in Linux' direction...As fast as any company of IBM's size can manage, as it were. My job there was to run-test (heh, or crash-test, depending on your POV) RAID subsystems, writing code basically meant to abuse the array to the point where it failed, and coughed up errors we felt might arise in the feild. We were doing alot of parallel testing on a variety of platforms, Linux included.
Unfortunately, I can tell you from my own personal observations that Linux as of 2.2 wasn't quite ready to handle the sort of stresses that are normally endured successfully by other platforms. Without getting into details (Ay, the spectre of my 6-month NDA looms above) management spent some time trying to determine if Linux was "ready for prime-time", and wasn't finding what it needed..In my little niche, at least. This was a while ago, and I hope that the situation has improved somewhat...but I cant help but get the feeling the same sort of thing was happening elsewhere within the company. It seemed everyone there wants to make inroads towards Linux, to sort of adopt it in a parent-child sort of way, but the Linux picture really hasnt fully gelled yet to where companies like IBM can bet their money on it with total confidence. Nonetheless, the demand is there folks..Customers are asking the company for solutions involving Linux, even on the big iron. IBM wants to embrace Linux, but Linux isn't maturing fast enough in the right areas. It would be wise for us to get hammering on the things that need to be addressed...By the time we actually get around to solidifying whats important (ie. a standardized GUI we can all use instead of two sibling projects who don't want to play in the same sandbox) and hammering out the better known weaknesses in Linux (The handling of SCSI devices, in particular) it may already be too late, unfortunately.
Cheers,
Re:IBM needs Linux (Score:2, Informative)
Was taken from hera [jwz.org]
I realise this is a flame and that I shouldn't answer it but who have said that you can order a distro, have it set up for you for zero cost, give you support for zero cost and everything else for zero cost.
Before talking about free software in terms of the GPL (The licence Linux has) make sure you know [fsf.org]
or at least have a some knowledge in what you are talking about. Browse an hour and you will realise that we are not talking about zero cost but different freedoms they think you should have with software. Of course you may not agree with this but at least you can debate it. [fsf.org]
Re:It's more AS/400 vs RS/6000 (Score:1, Informative)
Besides, RS/6000 is in a completely different market segment than the AS/400 line. Have you ever played with a 400 box? We're talking pretty big iron here. Only thing bigger is the 390. Don't forget that IBM just dumped a bunch of money into a brand new chip for the RS/6000 too. Can't wait to get my hands on a gigahertz Regata station
Re:It's about time (Score:2, Informative)
Facts:
Are you a NT admin or something?
Re:My $.02 (Score:2, Informative)
Re:What are the weakest parts of Linux? (Score:5, Informative)
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.
The answer is simple. (Score:3, Informative)
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.
Re:But they'd probably want more control (Score:1, Informative)
Linus is mainly concerned about his own situation (resonably modern 1-way and 2-way PC stuff). He has a large constituancy of embedded developers and people who use older gear. He has not show significant interest in the 4+ CPU case unless there is ZERO impact on the traditional base of Linux users. That spells fork if people like IBM and SGI are serious about dropping their proprietary unixes.
Where AIX kicks butt (and others need to catch up) (Score:3, Informative)
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.
They are... (Score:3, Informative)
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.