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?)
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.
Facts:
Are you a NT admin or something?
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.
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
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.
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.
Sounds like a sarcasm.
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.
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.
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.
The problem I see with this is that if a company as big as IBM wants to use something like Linux, they're going to want some kind of control of the direction it goes. Companies have been trying to get Linus to loosen his 'control' of the kernel for a while now. No company with smart leadership will drop support for a product that they have complete power over, in favor of an OS where they have little-to-no control over the direction that it takes.
First a caveat: These are my own views and not those of IBM Canada.
Why do you think that IBM needs control of the Linux kernel? It's not necessary. Because the kernel is open source any features that IBM feels are necessary for running Linux on, for example, a 4-way H50 RS/6000 machine can be provided as a patch to the main kernel tree and pre-compiled binaries can be distributed by IBM from one of the web sites. Yes - someone has to keep the patches sane against the latest kernel but it is unlikely in the long run that useful and proven patches would remain out of the kernel tree forever unless they seriously clash with some design decision.
Patch maintenance is a minor headache against a stable kernel series. It only becomes a major problem if you try and keep patches sync'd against a development kernel and IBM is very very unlikely to request customers use such a kernel in a production environment.
And secondly, why do you think that IBM needs total control over everything they use? That's nonsense. Working in the RDMBS world, we all work to published standards. There is no 'total control' exercised by IBM when submitting proposals for new SQL functionality or DRDA protocols. Total control is not the only option for making money out there - being the best at something still makes better business sense. Making sure that the customer support services are actually helping customers makes good financial sense. We have all got really warped by MS's monopoly position and healthy financial situation that it is too easy to forget that it is possible to make a good income by being good in a competitive marketplace.
Cheers,
Toby Haynes
True but I think you are missing some of the point. Even in open standards there are dominant and weaker players. Consider the fight over the next-generation IP. In that case the standards are supposed to be open. However the dominant voices in the process are not developers, not sysadmins, not even universities they are people like Microsoft and Time-Warner. The largest companies that can shout the loudest to get what they want. IBM is the same. IBM is a corporation and to that end they will do what is best for themselves. This is not necessarily driven by malice it is just the state of affairs. If they find it better to move to Linux or at least publicly support it, both to piss off Bill and to make geeks worldwide love them, then they will.
If they move to using and developing Linux they will then be the biggest gorilla at the table. Linus is one person, everyone else who submits patches is one person (for the most part). IBM is hundreds. By sheer force of size and voice they will be able to dominate the direction of Linux. This may be unintentional but their sheer size makes it likely. I doubt seriously whether the CEO of IBM is twisting his handlebar moustache and plotting to wrest control away. If IBM jumps in with both feet though and becomes dependent upon Linux they will need to. At that point it will be necessary for IBM to drive Linux or at least keep it on their desired path as their bottom line will depend upon it. When it comes to the bottom line for a publicly held corporation all else is secondary.
Moreover, what about the public face of Linux? In the computing world among geeks we may know that Linus is the cheiftan. Geeks also know who Ulrich Drepper is. But the rest of the world, the people who just buy machines and use them the end-users, the university purchasers who cut deals for servers and the corporate managers do not. They know brand names and if IBM manages to identify itself with linux they may become "Linux" (or at least it's guardian) in the eyes of the majority of the world. Then this name which is the real public force and property of the Linux movement will become theirs. At that point what Linus wants, or what the early developers want, IBM will be running the show. IBM will be the company rubber stamping distros and by sheer force of weight blocking competition from people such as RedHat and co.
This is a doomesday scenario I know. But keep in mind that the computing world was once known as "IBM and the Seven Little Dwarves." Keep in mind that they also attempted to paint their ads for peace-love-linux all over san-francisco in an effort to ID themselves with the 60's. I don't think Linus and the rest of us should turn our backs on IBM (allthough I'm sure RMS does). But I do we should see them for what they are, a company, and not rush to them like the Manhattan Indians bearing gifts.
No company with smart leadership will drop support for a product that they have complete power over, in favor of an OS where they have little-to-no control over the direction that it takes.
Which is why IBM's PCs all still come preloaded with OS/2 instead of Wi-- oh, wait.
I'm sure IBM does a great deal of validation testing. Why not tell the kernel developers where things come up short? One of the most valuable development prerequisites are good bug reports. IBM could unleash their testing team. Or does politics get in the way -- the testing team manager doesn't approve of the Linux takeover?
Well, I don't have the time to do a search, but I have some "unvalidated thoughts and memories" on the subject.
I think a while back IBM wanted to submitt some patches to the linux kernel that would allow it to play better with the big boys. The patches would enable scaling up to a large number of processors, and efficiently using large amounts of memory. IIRC (doubtful, someone else wanna help me out here), linus didn't want the patches b/c he cared more about linux running on a normal machine well. I hope that they'd just do something like #ifdef _BIG_IRON_. Instead, IBM just kinda backed off, they didn't want to create any sort of resentment from the community, nor did they want to fork the kernel so they could have a version with their patches. I think the willingness of the company to give, and not get upset if its gifts aren't accepted well is a great testiment to its devotion to linux.
I think insertion of those patches, even if on a #ifdef type basis would be a leap in the right direction for IBM to replace AIX with linux.
I'm not 100% sure of the facts, if someone would like to correct me, please do. Of course if someone wants to back me up with links, that'd be ok too
Garc
1. As has already been stated IBM has been on the Linux bandwagon for several years now.
2. This makes perfect sense for IBM. They are mainly a service company and secondly a hardware company. Anyone who has done business with IBM knows that they, like most other large computer companies, make their money on installation and support. If they can cut the expense of developing their own OS they can focus on their core business.
Link. [ibm.com]Irving Wladawsky-Berger, vice president of technology strategy, IBM Server Group, addressed the IBM Technical Developer Conference in San Francisco on Linux and open standards.
They were able to do this since they released micro-code patches which included additional low-level instructions. Which is some cases were nothing but NOP (equivilent) instructions.
By dividing the OS group from the Hardware group it becomes difficult to tie two products together to that degree.
But assuming that GNU/Linux can evolve to an acceptable level (the level of UNIX, in other words), and assuming that the support from IBM, HP, Sun, and Compaq continues, we'll be in a great position. One of the promises of UNIX was portability; if five commercial UNIXs have a common interface, they should be easy to port between, right?
Wrong... years of corporate specialization and AT&T's rightful protection of the system have created a computing culture which is almost as closed as Microsoft's. Now, porting an application from Solaris to HP-UX can potentially take as long as porting from Solaris to NT.
Enter GNU/Linux. Stallman, Torvalds, and the rest of the usual suspects essentially ripped off AT&T. (It's crucial that you understand this. While those developers can be thanked for the GNU/Linux implementation, the design and archiecture is stolen-- albeit modifed -- IP.) GNU/Linux is UNIX-like, but is also completely open. Thus, if Linux can meet these corporate giants' needs, they should adopt it.
IBM's adoption of Linux for the enterprise will mean many things. It will mean that RS/6000 customers like myself will get new software faster, because Linux is always ahead of AIX on software developers' port lists. And if Linux can also run reasonably on Sun and HP hardware, then we could be talking about UNIX's dream of portability, embodied in GNU/Linux: an open, common interface for hardcore RISC systems. This would be a good thing for everybody expect supporters of inferior x86 servers: x86 hardware vendors and Microsoft.
But while GNU/Linux has brought this uptopia one step closer, it isn't here yet. Talk to any knowledgable, experienced developer or sysadmin, and he will tell you that GNU/Linux simply can't touch UNIX for the majority of serious computing tasks. Linux is cheaper, and in some instances is faster, but just can't deliver the same kind of scalable performance and rock-solid availabilty that are the reasons I'm running AIX right now.
This is an interesting point that hasn't been brought up much in this discussion. Linux is much closer to being a lingua franca in the software world than is AIX, so switching to Linux would be like saying, "Okay, we'll speak English now." It may not be the best, but it certainly helps business.
But which kind of English?
Red hat English, SuSE English, Mandrake English? Or perhaps Slackware English, Corel English or Stampede English? Debian English? Ultra English, Yellow Dog English? Caldera OpenEnglish, Storm English, Bastille English, Castle English, LinuxOne English, Mastodon English, OpenShare English or Ocularis English? Phat English, SlackNet English? WinEnglish, Think Blue English, Yggdrasil English?
Or one of the 10s or 100s more dialects available?
Just curious...
I would argue that its appearance in the scientific-computing community wasn't a fluke; in fact, I'll assert that scientific computing was one of Linux's earliest natural "markets."
Scientific organizations typically have
- lots of raw intellectual and technical talent,
- meager funding and tight budgets,
- a "doing it right often means doing it yourself" mind-set, and
- lots of in-house curiosity.
Can you think of a more natural environment for a home-brew OS's ferment?
(I started using and supporting Linux for serious scientific computing in 1993.)
I'm assuming you meant from the ground up, right? If so, then that's not true. AIX is a real, licensed Unix, which means it shares source code with all other SVR4 Unices. In the interview [zdnet.co.uk] with Ransom Love in thisAIX was developed from the group up, by IBM, to kick ass on IBM hardware. GNU/Linux was developed by a diverse group of developers -- each with different goals; some wanted a server OS, some wanted a desktop OS -- for cheapo x86 hardware.
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.
As someone who uses Linux with SCSI every day,
I can confirm that Linux is much less stable with
SCSI devices. Typically an error on the SCSI bus will start an unending sequence of bus resets. Buffer allocation leaks in the st driver error out after a couple of opens (if you are using st, you
basically have to allocate buffers at boot or mod load time; otherwise the buffer issue will kill the device quickly); also the st performance is
awful when configured for reliable writing (unbuffered, synchronous) and the st devices defaults to a useless configuration with a bizarre
mechanism for getting a useful device that means you will never know from one machine to the next if your code will work. SCSI DVD-RAM is recognized but completely unsupported and the sr
maintainer appears to think that DVD-RAM is
similar to CD-RW (not true; CD-RW only does packet
writes, while DVD-RAM can be treated like a hard-drive. It should just be added to the sd
driver.) The sd driver has its own problems,
basically ignoring the drive 10byte command request and using 6byte commands anyway unless
the sector being written is out of the 6-byte command range (6-byte commands don't work at all
with some of the newer SCSI devices). Device ordering is messed up, the OS doesn't correctly
recognize the BIOS settings for SCSI before IDE
so booting such a system adds the chore of manually maintaining BIOS drive numbers. SCSI busses are recognized in a predetermined order defined by their scan names instead of their order
on the PCI bus. As a result Linux often gets the
order incorrect half of the time if two different SCSI controllers are installed (patch the scan order and rebuild the kernel to get past this
problem.) And there are some filesystem partition size limits around 32G and 8G that require patches to get around.
And those are just the problems that I've personally encountered in the last two years
off the top of my head.
It was 3 years ago when the ball dropped on the infamouse (and powerfull) OS/2 solution. (well, someoen over at http://www.ecomstation.com is picking up now).
IBM Changes software and solutions like there is no tommorow. If it isn't Calle E-Gizmo then IBM will change it to that.
IBM Supporting linux is great, hooray! woopie. But don't expect much. It was the users who supported IBM and it was IBM who told the users to shove off. Hopefully that won't happen again.
AIX just sucks so i don't know why they're saying anything about linux competing with AIX. AIX has more patches then you can shake a stick at, java is flaky at best and supported libraries are rare at most.
Oh well.
However, I've seen AIX, and I know that IBM obviously has some pretty decent *nix coders in their stable. You'd think they could take what they have and coble together "AIX/Linux" instead of throwing away a perfectly good OS.
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.
I was using AIX workstations until a couple of years ago. Here are some of the things that drove me up the wall about them:
AIX is so un-UNIXy that the Unix System Administrator Handbook [amazon.com] kept making fun of it throughout its pages as the odd-man-out (it also deals with Solaris, Irix, HP/UX, and others), comments they removed in later editions presumably not to upset AIX users too much.
In defense of AIX workstations and servers, they are very reliable machines, and people who work only in the AIX world and don't deal with other UNIX systems probably never notice and don't care about the idiosyncracies.
Altogether, I see a big culture clash if IBM tries to move AIX users to Linux. And I think that clash may well end up harming Linux if it causes stuff like JFS and LVM to be adopted more widely in Linux. Let's not fall into the Microsoft mindset where everybody must run the same software; there is nothing wrong with having Linux, AIX, Windows, Solaris, and other systems co-exist. We don't need an OS monoculture.
Riches cover a multitude of woes. -- Menander
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)
Parent Share
twitter
facebook
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)