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)
Re:Jump on the bandwagon? (Score:2)
The problem is that the largest expense of software manufacturing is paying for development (R&D). This cost has to be passed on to customers and remains fixed regardless of how many units are sold. This means that there is cost associated with each unit sold which goes down as more units are sold and up as less (Embodied R and D = total R and D / total units sold). This is what has made Microsoft successful in many areas of the market, and it is a failing point for most versions of UNIX. This means that if you buy an NT server, it has less embodied R&D than if you buy an AIX machine.
If Linux could be up to the challenge, it would diffuse the R&D costs by diffusing the R&D, thus making any company who adopted it more competitive. IBM is making the right choices here from a business perspective and (with the exception of CPRM development) becoming more of a present ally for open source.
and the answer is? (Score:2, Interesting)
Re:and the answer is? (Score:3, Funny)
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:My $.02 (Score:2, Informative)
Re:My $.02 (Score:2)
If you are doing custom device drivers then
AIX is a very nice operating system to develop
for. As a micro kernel your drivers are running
in ring 1 so it is difficult to kill ring 0.
Even with modules it is much easier for device drivers in Linux to panic the kernel, and in Linux you don't get a core dump of the panic'd kernel to debug.
Also for those who aren't familiar with AIX, 'smit' is the system administration tool developed for AIX by IBM. There are about a thousand little commands to modify individual configuration files in AIX, that are nearly impossible to remember. Personally I prefer 'vi' and text based configuration. On the other hand AIX commands are scriptable (I suppose text files can be as well
with a bit of Perl, but text is easier to get
AFU'd), and smit provides a nice GUI interface for checking parameter completeness.
$0.01 more... (Score:2, Interesting)
The ODM is real drag though. It make AIX administration so different from every other Unix, that only the extreme usefulness of SMIT makes administering the system tolerable.
IBM's jfs/lvm are great too.
But you forgot one really great thing about about AIX. You never need to rebuild the kernel! (well, hardly ever. The authors of the O'Reilly Unix admin book mention one case.) Kernel parameters are self-adjusting for the most part.
Linux doesn't have the kernel parameter hell of System V (driver hell instead), but it does have kernel parameters, and if you are working at the high end, you _will_ need to tune them. And what's worst is that there is no one central place to find them all. Some are in
Re:My $.02 (Score:2)
LVM = linux's is shitty, and has a habit of toasting disks
HA = linux equivants are a joke. Ever work with an SP cluster?
SMIT = linuxconf is a toy, and a bad one at that
ODM = can be argued both ways
AFS = OpenAFS is not ready for primetime
NFS = remember not to try using version 3!
I suggest trying OS's that you bash.
Literacy (Score:3, Funny)
Um... All your base?
Easy (Score:3, Informative)
Re:Easy (Score:4, Insightful)
I think when IBM says they'll use linux if it "matures so that it can handle the most demanding tasks," they don't mean "you guys need to build pretty little admin GUIs, and make sure linux is consistent looking." I'm thinking that they're more looking for the ability to scale to a large number of processors, and high amounts of RAM.
On that subject, does anyone know if IBM's Big Iron patches ever made it on to the main kernel tree?
Garc
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 big iron ? (Score:2)
Linux Scalability [sgi.com]
Kernprof [sgi.com] (Kernel Profiling)
SGI kGDB [sgi.com] (Remote host Linux kernel debugger via GDB)
NUMA [sgi.com] (NUMA support in Linux)
Bigmem [sgi.com] (Big Memory support for Linux)
Lockmeter [sgi.com] (Linux kernel lock-metering)
Post/Wait [sgi.com] (Post/Wait Synchronization)
SGI kdb [sgi.com] (Linux kernel debugger)
Raw I/O [sgi.com] (Enhancements to Linux raw I/O capabilities)
POSIX Asynchronous I/O [sgi.com] (KAIO)
LKCD [sgi.com] (Linux Kernel Crash Dumps)
STP [sgi.com] (Scheduled Transfer Protocol)
Re:Easy (Score:2)
Of all the unixen I have played with AIX is one of the worst. Only Conrol data's unix and NCR was worse.
Clearly, you never used NeXTStep. Now there was a screwed-up *nix variant... (BTW, anyone wanna buy a color turbo nextstation?)
It's about time (Score:3, Interesting)
Now if only all of the other vendors realized that they were selling hardware instead of UNIX, they'd be happy to switch to Linux.
Actually, they probably all have some kind of "ditch-our-crappy-UNIX-for-Linux" roadmap. Some are much further away than others. But it'd be nice if it actually happened.
Re:It's about time (Score:2, Interesting)
Sure, there are marginal improvements in total system performance from things like cache, bus speed and so on. They are marginal.
For anything up to 8 CPU's, Intel hardware will be better most of the time. That covers all small servers, departmental servers, web servers, small/medium database servers and a stack of other stuff. Sure, 8 CPU intel machine's aren't great, but then 4 CPU ones go as fast as 8 CPU Suns.
Look at distributed.net CPU speed tables. The fasted risc CPU of any kind (UltrasparcIII @ 800Mhz) is less than half the speed of a Pentium III doing 1.2Ghz (for RC5 cracking).
And as for those 16, 32 CPU boxes? Some applications do indeed benefit from that, but increasingly few (latest MS SQL server runs distributed on separate machines very well - no need to SMP (MS flames to
No, what Sun et al. provide is not good hardware. They have operating systems marginally better than linux (better disk stuff (filesystems, software raid and volume management etc), better threading, and a few other things). But, what they do provide is support and service. Lots and lots and lots of it. And they provide guarantees.
But, even that isn't what they really provide.
What they _really_ provide, is the only alternative to Microsoft that your boss will consider.
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...
Re:It's about time (Score:2, Informative)
Facts:
Are you a NT admin or something?
Re:It's about time (Score:2)
maannn, you don't have any clue what you are talking about, are you? At least don't classify by the number of cpus. This is absolute bull...
IBM's S390 goes from 1 to 12 CPUs and that 41000+ linux instances they had running on one of that beasts was on a relativly small one - later david boyes had 97,943 instances of linux running on 12 CPUs (and 16 Gig). Show me any i386 based system capable of that.
This is not about raw processing power, but even there you have to look at the problem size because memory bandwidth can be pretty relevant there.
Oh, btw. you know who developed some innovative technologies for cpus like SOI and copper - where is intel in that game?
Read for instance
Microdesign Resources [mdronline.com], I cite:
But POWER4 is not just about CMP. Both of POWER4's two cores are 64-bit, five-issue, superscalar processors that will operate at more than 1 GHz, making each one more powerful than any single CPU in existence today. And unlike most companies that just moan and complain about the problems of memory latency and bandwidth, IBM did something about them. POWER4's two cores share a large on-chip L2 cache with 100 GB/s of combined bandwidth. The chip also provides 45 GB/s of off-chip bandwidth to other POWER4 chips, memory, and I/O. These bandwidths are an order of magnitude higher than found on typical processors today. IBM used wave pipelining to allow POWER4's wide expansion bus to operate at 500 MHz over long distances with good signal integrity.
And more about that here:
http://mdronline.com/mpr/h/2000/1120/144703.htm
an indepth view about the new ibm puppies.
Intel is as far away from that territory as mssql from oracle on an e10000.
Re:It's about time (Score:2, Interesting)
Solaris is much more stable than Linux is, and I have never had a Solaris box hang or crash on me. If Sun were to ditch Solaris for Linux, they wouldn't sell any boxes (Because without solaris their boxes are just run of the mill Multi-Processor RISC boxes). On the other hand some flavors of UNIX suck! Take SGI IRIX, they should kill it, and switch to Linux, because SGI has proven that they don't have the dedication it takes to keep up an operating system....
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
What are the weakest parts of Linux? (Score:2, Interesting)
I know that real-time applications are one issue, as well as multi-processor performance. But how much work has to be done, and what are the prospects?
Thanks in advance for not flaming the newbie.
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: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.
Re:What are the weakest parts of Linux? (Score:2)
A couple of areas come to mind (I'm sure there are more), but AIX in particular has:
1) "smit", which is a great system management tool. All of the linux config tools (*cough*linuxconf*cough*) are complete garbage. The great thing about smit is that you can do very complex admin tasks, but you can display the command line it will use to do them at any time.
2) Volume management. This rocks under AIX. You can create, destroy and extend filesystems on the fly. You can move them across physical devices -- on the fly. They can span physical devices. Mirroring. Journaling. This is the biggest thing I miss in Linux.
3) sysback. This will automatically create a bootable tape under AIX. System crash? No problem -- just boot off the tape and it automatically restores the whole system, filesystems and all. Want to duplicate a system? Same deal. It has a few limitations (everything has to be under the same volume group), but it's awesome.
If... (Score:2, Informative)
Sounds like a sarcasm.
$ is made from HW, not SW (Score:4, Interesting)
Well IBM was wrong at the time in that statement but it might finally be the truth.
It also makes sense for IBM from a financial perspective. Instead of having a building full of programmers/managers and other overhead that eats up corporate profits just to support AIX, why not outsource that dependency to the open-source users of the world. Big blue then reduces their expenses, increases their income and the open-source community gets a juggernaut pulling for their team. A win-win situation if I've ever heard one.
p.s. - These are my opinions and not my employers who happens to be discussed in this thread.
$ is made from support contracts! (Score:3, Interesting)
Do you honestly think that if IBM were to ditch AIX for linux that this would happen? The value of running IBM hardware and software is that IBM is there to fix it right away. Find a bug in AIX? IBM gets on it in a timely fashion. If anything, I would wager that IBM will fork their own version of Linux if they decide to forgo AIX. Large corporations like the track history and reputation of IBM and are frightened by the lack of the same for Linux. IMHO that seems to be what stops large-scale deployment of Linux in the corporate world - who is going to take ownership of this problem and provide us with patches?
BTW - from what I have seen, (as an IBM'er) the revenue and profits come from annual support and maintenance contracts, not from hardware and software sales per se.
Re:$ is made from support contracts! (Score:2)
This is spot on. Every tech company I've worked for (typically very large ones, not small and idealistic ones) has made support and maintenance their primary source of income; Software or hardware sales are simply how they set up the need for support.
Re:$ is made from support contracts! (Score:2)
Fork (Score:3, Interesting)
Now IBM would probably only sell their distribution to those who bought their hardware, but they might well be willing to sell maintenance contracts (which might [optionally?] include their distribution) to anyone. Just as Red Hat prefers to support customers who are running Red Hat Linux, because it cuts down on the variety of problems that they have to deal with, so it increases their profits without increasing their expenses.
Re:$ is made from HW, not SW (Score:2)
Because the devil you know is better than the devil you don't. IBM will almost certainly retain their AIX infrastructure, and instead of dropping it to use Linux they'll use it to maintain and tweak their own fork.
IBM is a solid company, and it's unlikely that they're idealistic about switching everything over to a hippie OS like Linux. Quite the contrary, they'll take a hardcore cynical position about it, and they'll fork it and make it their own as necessary so that they can trust it.
Don't forget the services market either (Score:2)
I dunno how much money IBM makes or loses off this, but they've been pushing their various management and consulting services pretty hard. Or, least that's what I remember from a few years ago when I was directly exposed it. Going with Linux like this opens the markets they already have their foot into. AIX, I suspect, is a dead end, and IBM knows it. Not too many people use it these days, and everyone seems to be going into Linux on the server side at least.
Re:$ is made from HW, not SW (Score:3, Interesting)
>Valley" where Gates and company were sitting
>down to negotiate with IBM and it was
>said, "Everybody knows that the real money is
>made in hardware, not software".
>
>Well IBM was wrong at the time in that statement
>but it might finally be the truth.
Actually, it was right at the time, but rapidly stopped being so. And now the pendulum's swinging back the other way.
Everything is a service industry. Manufacturing is a service; "products" are an effect often confused with a cause.
Hardware became commoditized. Interchangeable parts available from multiple vendors. Competing on price and functionality, but with transparency and compatability as the entry fee.
One vendor's software beat the other vendor's software because the hardware fought all its battles for it. IBM's PC didn't hurt apple, the PC -CLONES- drove IBM itself from the field, along with apple. Microsoft beat apple because the hardware fought all its battles for it. All it had to do was maintain a monopoly lock on the PC hardware platform and hang on for the ride.
Now commodity software is coming into fashion. It was called free software until it got marketing, and the marketers called it Open Source. Commoditization is the natural thing to happen to any mature market. A Linux system is made from interchangeable parts available from multiple sources, freely downloadable, transparent and compatable.
Red Hat, SuSE and TurboLinux are just like Dell, Compaq, and Gateway. They assemble commodity parts into a finished product, stamp a brand name on it, and sell it with a warantee. But you can put your own box together (or go to linuxfromscratch.com and assemble your own linux distribution). Most people choose not to, they start with an assembled system and customize it from there.
IBM lost its position in the PC market when it tried to close it up with the proprietary PS/2. It has had ten years to learn from its mistakes (and it has a new brain, Lou Gerstner's, to comprehend the blindlingly obvious with). It sees Linux, it comprehends "commodity software", and it's trying darn hard to play the game on the game's terms this time.
And so far, I think it's doing a decent job of it.
Rob