Well, for one thing, Apple makes a point of having their new OS releases run on older hardware. You can run the latest OSX release on an original iMac, which is 5 years old. Try running XP on a PC that you bought 5 years ago simply by inserting the CD and clicking "install"... That means that an older machine is more useful because it can run up-to-date software (kind of like why old PC's are still useful if you run Linux of BSD on 'em:)
Chicago is certainly not a waste of time (well, if you like Broadway musicals, anyway). They stayed with the original plot line and music and didn't try something silly like trying to rewrite music and lyrics. Even the people I know who are actors/actresses and do live musicals liked it...
I think this *is* different in that the people who decided to go for launch with Challenger were the upper managers while the engineers were saying "no, this is a bad idea". What appears to have happened here was that everyone agreed that the damage wasn't a flight safety risk, including the engineers. While I can believe that someone who never met the crew might decide that it was "worth the risk", I can't imagine engineers who worked with these people on a daily basis doing it.
They are then left with a descision as to what is the lower risk to the crew (and to any possible rescue crew): continue flying with a normal reentry in a situation that the people involved thought (perhaps incorrectly) that they understood or attempt a risky rescue mission with little to no evidence that it was necessary.
Your claim that NASA knew what happened when tiles were damaged is true. They knew (or thought they knew) that tiles get damaged on almost every launch and that the shuttle has always (except for Challenger which was a different problem) landed safely. They also thought that there was no significant risk to the flight crew's safety. Perhaps someone will come forward and say that they were concerned about this and were ignored but so far, nobody has.
As for launching the second shuttle - which do you think is more dangerous: having Columbia do a normal return to Earth given that your engineers are telling you that at worst, you're going to have to replace some parts when it gets back, or rapidly training people to replace tiles in space, which has never been done before, skipping a lot of the usual launch safety checks, which has never been done before, and launching another shuttle in less than a month, which has never been done before, having the two shuttles in the air at the same time and meet in space (neither have been done before), attempting a previously un-attempted repair, and then having both shuttles land?
Given the choice, the latter option, ignoring cost, still seems far more risky.
If NASA had evidence that the landing wasn't going to be safe, you can bet they would have done *something*. Or are you suggesting that these people are so calous that they'd let their friends die rather than admit an error?
So, of course I meant Farenheit and of course you knew that. But since you wanna be pedantic, 60 degrees Celsius translates to 140 degrees F which is not hot enough to scald your skin or even come close (though it's pretty warm).
Only two Crays have ever been submerged (the Cray 2 and the Cray T90). They are submerged in a synthetic fluid (originally designed as fake blood plasms, IIRC) called Fluorinert. The Flourinert is held at around 60 degrees by heat exchanging with chilled water. The Cray 1 and the Cray X-MP were cooled by a cold plate chilled with freon. The Y-MP, C-90, T3D, and T3E used cold plates chilled by Flourinert. The X1 uses spray-on flourinert (it gets sprayed onto the chips continuously while the machine is running). The EL series, J-90, SV1, and SuperServer all used air cooling.
There are several advantages in having a 64 bit processor. First, the largest number that can be represented in 32 bits is ~4billion (or 4 gigabytes, if you are dealing in memory or hard drive space). That means if you want to do math on numbers larger than that, you can't do it in a single instruction on a 32 bit processor. More instructions is more time, hence you'll get a speed improvement when doing the math necessary for disk access.
In addition, if you run something like Photoshop or Protools or some other software that chews through RAM like there's no tomorrow, you may want more than 4 gigabytes of RAM in your machine. If you do, you're going to need a processor that has more than 32 bits in order to address it (there are ways of working around this, but I'm not going to go into them here).
Finally, if you are doing, say, nuclear physics and want to simulate something in high precision, you'll want 64 bits in your floating point numbers to get a more accurate representation of what's going on.
So the advantages are a) modest speedup in code dealing with disk access, b) ability to put in more than 4GB of RAM, and c) higher precision floating point arithmetic. Most people, however, really don't need a 64 bit processor on their desktops.
If you don't agree with the license then why would you agree to its terms? If GM had such a clause (if you use this car to commit a crime we'll reposess it) in their contract of sale, it'd be perfectly legal. You, however, would have the right to not buy their car. I don't see how this is different.
To put it another way, what if I took GPL'd software and used it in a commercial product and didn't distribute the source. Pretend that I happen to disagree with that clause in the GPL. Do I have a right to do that? I think not.
The original version of this was developed using an SDK (software development kit) for iTunes. The SDK provided an interface to an Apple Proprietary API. As I understand it, the API was intended (and licensed) only to be used to provide support for new hardware, not new software. He used them to provide software support and was thus in violation of the license on the SDK.
Both AppleEvents and Rendezvous have published API's that don't have (to my knowledge) restrictions on their use.
You probably don't need a computer that's even half as fast as the one you typed that message on either, but....
There is a massive quality difference between a $70 mic and a $500 mic. You may not hear it on some things, but any classical stringed instrument will sound a whole lot better with a $500 mic than a $70 one. In between you can get a whole spectrum of good and bad and ok. I cease to be able to hear much difference on most things after about the $500 threshold, but classical instruments I can still hear the difference.
I do live sound and most mics that you'd use onstage live are $500 and under (not including wireless mics that cost a lot for the xmit/recv units).
That said, some people buy $1000+ sand bags to put their amplifiers on because they claim that the amp sounds better if it has vibration dampening. These decisions aren't always rational and in any case, the price of the sound console, which *does* make a difference in what features you get, quality of the AD converters, how many channels, etc, makes the cost of the mics look small.
Yeah, but the money the studio pays for the equipment has to come from someplace and it's going to come from the band using the studio and probably at a steep markup... Remember the studio is going to want to make a nice profit as well...
Your point about the servers is a very good one though.
It's sort of a one time cost. It'll last for years, but not indefinetly. The boards get replaced more often and are an order of magnitude more expensive. Factor in 7 or 8 of those mics that they'll have around and you're talking a large amount of money. So it's not disposable, but for a studio, it's a high ongoing cost which they will pass on to the people renting time there.
This really isn't true. You could take the best opera stars in the world, who are most certainly capable of not needing any microphones to sound good live, and they'll need a decent producer. Once you run someone through a microphone, you have to get the result sounding like the original. This isn't amazingly difficult, but it's not automatic either. For one thing, you need a good microphone. Studio mics aren't cheap. Some run as much as $20,000. You also need digital production boards and effects. These can easily be in the multiple hundreds of thousands of dollars range and have to be constantly kept up to date with the latest technology.
So, add that cost (the studio time) to the cost paying the producer, to the cost of paying the band plus any studio musicians you need to providing catering and a top notch band could easily cost the record lable a bundle.
An unknown band probably costs at least an order of magnitude less than $500k to $1.5 million, but then, they don't get the top notch stuff. Sometimes, they'll come up with something phenomenal with midrange equipment. Sometimes they won't. But the ones who come up with the really good stuff are going to want the high end equipment next time around:)
I think you're confusing NUMA with message passing. NUMA stands for
Non-Uniform Memory Access (actually, this machine is cc-NUMA - Cache
Coherent NUMA, but I digress). NUMA means that when I do a standard
memory reference it will go faster or slower depending on where in memory
that reference goes. This is accomplished by having a group of processors
and a group of RAM DIMMs tied to each other with a memory controller that
is also a router. If you want someone else's memory, you go over the
router to the other memory controller and it returns the answer. That
takes longer than your local memory (longer vs. shorter is not uniform),
hence the machine is NUMA. IIRC, this machine is NUMA after 2 processors
up to the max system size. Despite running multiple Linux kernels, all
the memory is visible to all the processors even outside your own
kernel. It seems they've picked 64p as the maximum useful size for a
single kernel.
What is your quad P4? That's SMP - symetric multiprocessing. Symetric
means that all memory accesses take the "same" amount of time since there
is only one pool of memory for all the processor and no processor is
closer to it than any other. SMP systems larger than around 32 processors
are rare since your single memory subsystem needs to feed *all* theprocessors.
So what is a Beowulf cluster then? A typical Beowulf cluster (well, just
a cluster in general) is a group of nodes which can't directly address
each other's memory and hence have to send a message to the other guy to
read/write his memory. Cards like Myrinet exist to try to get some form
of shared memory between the nodes in the cluster to varying
success. Compared with this, they are low bandwidth and high
latency. (Of course compared with a Cray X1, this machine is low
bandwidth, but I'm biased:)
There have been a variety of NUMA machines released over the
years. Highlights other than this thing include the Thinking Machines
boxes, the Cray T3D and T3E, the SGI Origin series, and the Cray X1.
...and you thought you were joking. "Lego Hardware" was an internal code name for this machine, and the Origin systems at one point. Rumor was that they wanted to use it publicly but LEGO(tm) objected. Not sure if the rumor had any truth to it, though, since the name was dropped before I started working for SGI/Cray.
Well, I'm not terribly familiar with this particular implementation, but that's not quite the same as MOL. MOL basically allows you to boot MacOS (X or Classic) in a "virtual Mac" that runs under Linux/BSD/whatever. The COMPAT stuff allows the NetBSD kernel to replace the normal OS kernel. So, only a single kernel is running, which means that all your devices and filesystems should be identical under OSX as under NetBSD whereas with MOL, you have the standard BSD or Linux kernel plus the Classic or OSX kernel on top of it.
Under most versions of Unix, there is a very similar interface between the user application and the kernel. Basically, the COMPAT stuff just says "Well, this program is a MacOS X program so when it makes a call that looks like A, it really means B under NetBSD so go do that and I'll reformat the results back to what the binary is expecting". The result is that the OSX binary is really running natively under NetBSD so any device supported by the NetBSD kernel *should* be supported by OSX. It looks like their present state is trying to get enough of the OSX device interface working for that to happen.
They won't, at least if it's as good as the other COMPAT stuff in NetBSD. You can boot (and I have done so - don't ask why, you don't wanna know) a Sun 3 with a full SunOS install with a NetBSD kernel instead of a kernel from Sun. You can even run (once again, don't ask but I've done this) SunOS binaries on a pre-PPC Mac running NetBSD.
Basically, what the COMPAT stuff emulates is not the somewhat ill-defined layer between libraries and applications in Windows, but the very well defined (and open-sourced) layer between the kernel and user-land. In order to make it useful, I'd suspect you'd need almost a full OSX installation.
Re:So will they blame terrorists...
on
Droning On
·
· Score: 2
...and thinking pilots are also the reason that more planes don't crash. When that DC-10 had a blown out engine and all the hydraulics failed and the guy had to do all motion control with the two remaining working engines instead of the control surfaces, I'd much rather have him than a computer that somebody didn't program for that 'cause it "can't" happen. What happened on that plane was supposed to be impossible. Because there were people flying it instead of a machine, half the people on the plane survived as opposed to none. In fact, most of the recent air crashes I can remeber were blamed on mechanical failure and/or maintenance (which is still going to be done by a human), not pilot error.
There will always be crashes caused by pilot error as long as there are pilots, but I'd be willing to bet that if you put the computer in charge, the total number of crashes would go up due to the computer not being able to do something it wasn't programmed for. Nobody can envision the entire list of possible failure scenarios and I, for one, trust human intelligence more than some AI thing to cope with an unforseen failure.
Anyhow, there are a variety of reasons why they may have chosen to implement their own system which could range from conflicting code licenses to not understanding the language that it was coded in. Their site is now/.'d so I can't check, but much research code at CMU is written in a language called SML. Conversion from SML to, say, Perl (or even C) is non-obvious as SML is a functional language. The only SML code I've ever heard of in production is the ACAP server that is part of Cyrus (I'm sure someone will chime in with other code).
Err, so from what I understand (my brother worked on this project briefly) this is basically an academic research project, that has some commercial uses. As such, CMU's CS department is interested in publishing papers, not code. The code for projects like this gets written more as a proof of concept than as a production ready set of code. So, if you want to use their code, it's going to be harder than just typing "make install". Remeber, this is code coming from the CS research department at CMU (which is quite good, I might add!), not the people who do Andrew (the academic computing environment that is more like "production code" - see the Cyrus mail system as an example of their code).
Ah, ok, just found this and it looks like vector instruction support on Power4 is fairly new. Also looks like a very nice chip.
In any case, there are two things that you worry about on interprocessor communication: speed and latency. Obviously, the dual-gig-E + triple Firewire is going to be faster than a single Myrinet card in terms of bandwidth (though I'd be surprised if a Mac or PC could come even close to driving all that gear at full speed), but it may not be in terms of latency. Depending on the application, this can have a huge impact on performance.
320k only beats 6 million if it's good enough to get the job you need done at the speed you need it done at. For some jobs, the $320k machine will work fine. For other jobs it won't. This is why there's still a market for big-iron Cray's, SGI's, Sun's, etc.
As for large address spaces and inter-processor communication speed, they are most certainly both necessary if you have a monster NUMA or SMP machine.
Right. So, the Cray X1 already has more bandwidth than 10-gig-E. According to our marketing numbers ( See slide #14) the processor to memory bandwidth is 38 gigabytes/sec (note bytes, not bits). Off node bandwidth is 3.2 gigabytes per second per processor for 16 processors on the node. 10-gig-E is at most 1.2 gigabytes per second.
So if we're shaking in our boots (I haven't really noticed anyone shaking due to anything other than cold, myself), it certainly isn't because of memory bandwidth... (Whoops, just reread your comment and realized you were probably kidding - didn't get my coffee today:) )
Err, to my knowledge, Power4 doesn't include Altivec (in fact, I think at one point IBM stated that they wouldn't include Altivec in PPC and so Apple went with Motorola - I am not clear on the exact details of this, though).
As for why one would use Power4 instead of PowerPC, Power4 is 64 bit and PowerPC is 32 bit. You run out of address bits really fast in 32 bit mode since some people want more than 4 gigs of memory per processor and then if you have to add bits to globally address memory.....
I couldn't tell from the articles, which were thin on technical details, but straight PCI I/O off of a commodity mobo is likely not fast enough either if you are trying to build a "real" supercomputer.
If that implementation of / strikes you as bad, you don't know a whole lot about processor design. Integer division burns a whole lot fewer transistors than floating point division and also guarantees acuracy to the left of the decimal point. If you care about precision, you shouldn't be dividing integers anyway. In order to round correctly, you'd need to get the first digit past the decimal point and then add it in. While getting the digit isn't too bad, the "add it in" step is going to require a trip through an adder which is going to add clocks per instruction and transistors since it has to happen after the divide step is through.
So, while it's confusing the first time you see it, integer division is the "div" operator that everyone learns at some point (about the time they learn about "mod"). It was hardly a choice which was made arbitrarily.
There are a large number of reasons going back to stupid internal politics (the offenders have either quit or been fired by now - see Rocket Rick as an example), but it basically came down to two basic reasons: 1) A conscious descision was made at some point (early '90's maybe?) that Irix wouldn't be ported to a radically different (*cough* little endian) architecture and so a port would be really hard (though not impossible) and probably more important 2) Linux for this thing can run any application that is written for IA64/Linux (which presumably will be at least a few) whereas Irix couldn't. You could add a Linux syscall layer, like the BSD's have done, but then you have to track changes to GPL'd software into something that SGI couldn't GPL even if they wanted to (as Irix contains source from some other vendors). So basically, it's a) difficulty of the port from a technical standpoint and b) application capture. Presumably, IBM had similar considerations for using Linux instead of AIX.
Well, for one thing, Apple makes a point of having their new OS releases run on older hardware. You can run the latest OSX release on an original iMac, which is 5 years old. Try running XP on a PC that you bought 5 years ago simply by inserting the CD and clicking "install"... That means that an older machine is more useful because it can run up-to-date software (kind of like why old PC's are still useful if you run Linux of BSD on 'em :)
Chicago is certainly not a waste of time (well, if you like Broadway musicals, anyway). They stayed with the original plot line and music and didn't try something silly like trying to rewrite music and lyrics. Even the people I know who are actors/actresses and do live musicals liked it...
They are then left with a descision as to what is the lower risk to the crew (and to any possible rescue crew): continue flying with a normal reentry in a situation that the people involved thought (perhaps incorrectly) that they understood or attempt a risky rescue mission with little to no evidence that it was necessary.
As for launching the second shuttle - which do you think is more dangerous: having Columbia do a normal return to Earth given that your engineers are telling you that at worst, you're going to have to replace some parts when it gets back, or rapidly training people to replace tiles in space, which has never been done before, skipping a lot of the usual launch safety checks, which has never been done before, and launching another shuttle in less than a month, which has never been done before, having the two shuttles in the air at the same time and meet in space (neither have been done before), attempting a previously un-attempted repair, and then having both shuttles land?
Given the choice, the latter option, ignoring cost, still seems far more risky.
If NASA had evidence that the landing wasn't going to be safe, you can bet they would have done *something*. Or are you suggesting that these people are so calous that they'd let their friends die rather than admit an error?
So, of course I meant Farenheit and of course you knew that. But since you wanna be pedantic, 60 degrees Celsius translates to 140 degrees F which is not hot enough to scald your skin or even come close (though it's pretty warm).
Only two Crays have ever been submerged (the Cray 2 and the Cray T90). They are submerged in a synthetic fluid (originally designed as fake blood plasms, IIRC) called Fluorinert. The Flourinert is held at around 60 degrees by heat exchanging with chilled water. The Cray 1 and the Cray X-MP were cooled by a cold plate chilled with freon. The Y-MP, C-90, T3D, and T3E used cold plates chilled by Flourinert. The X1 uses spray-on flourinert (it gets sprayed onto the chips continuously while the machine is running). The EL series, J-90, SV1, and SuperServer all used air cooling.
In addition, if you run something like Photoshop or Protools or some other software that chews through RAM like there's no tomorrow, you may want more than 4 gigabytes of RAM in your machine. If you do, you're going to need a processor that has more than 32 bits in order to address it (there are ways of working around this, but I'm not going to go into them here).
Finally, if you are doing, say, nuclear physics and want to simulate something in high precision, you'll want 64 bits in your floating point numbers to get a more accurate representation of what's going on.
So the advantages are a) modest speedup in code dealing with disk access, b) ability to put in more than 4GB of RAM, and c) higher precision floating point arithmetic. Most people, however, really don't need a 64 bit processor on their desktops.
To put it another way, what if I took GPL'd software and used it in a commercial product and didn't distribute the source. Pretend that I happen to disagree with that clause in the GPL. Do I have a right to do that? I think not.
Both AppleEvents and Rendezvous have published API's that don't have (to my knowledge) restrictions on their use.
There is a massive quality difference between a $70 mic and a $500 mic. You may not hear it on some things, but any classical stringed instrument will sound a whole lot better with a $500 mic than a $70 one. In between you can get a whole spectrum of good and bad and ok. I cease to be able to hear much difference on most things after about the $500 threshold, but classical instruments I can still hear the difference.
I do live sound and most mics that you'd use onstage live are $500 and under (not including wireless mics that cost a lot for the xmit/recv units).
That said, some people buy $1000+ sand bags to put their amplifiers on because they claim that the amp sounds better if it has vibration dampening. These decisions aren't always rational and in any case, the price of the sound console, which *does* make a difference in what features you get, quality of the AD converters, how many channels, etc, makes the cost of the mics look small.
Your point about the servers is a very good one though.
It's sort of a one time cost. It'll last for years, but not indefinetly. The boards get replaced more often and are an order of magnitude more expensive. Factor in 7 or 8 of those mics that they'll have around and you're talking a large amount of money. So it's not disposable, but for a studio, it's a high ongoing cost which they will pass on to the people renting time there.
So, add that cost (the studio time) to the cost paying the producer, to the cost of paying the band plus any studio musicians you need to providing catering and a top notch band could easily cost the record lable a bundle.
An unknown band probably costs at least an order of magnitude less than $500k to $1.5 million, but then, they don't get the top notch stuff. Sometimes, they'll come up with something phenomenal with midrange equipment. Sometimes they won't. But the ones who come up with the really good stuff are going to want the high end equipment next time around
What is your quad P4? That's SMP - symetric multiprocessing. Symetric means that all memory accesses take the "same" amount of time since there is only one pool of memory for all the processor and no processor is closer to it than any other. SMP systems larger than around 32 processors are rare since your single memory subsystem needs to feed *all* theprocessors.
So what is a Beowulf cluster then? A typical Beowulf cluster (well, just a cluster in general) is a group of nodes which can't directly address each other's memory and hence have to send a message to the other guy to read/write his memory. Cards like Myrinet exist to try to get some form of shared memory between the nodes in the cluster to varying success. Compared with this, they are low bandwidth and high latency. (Of course compared with a Cray X1, this machine is low bandwidth, but I'm biased :)
There have been a variety of NUMA machines released over the years. Highlights other than this thing include the Thinking Machines boxes, the Cray T3D and T3E, the SGI Origin series, and the Cray X1.
...and you thought you were joking. "Lego Hardware" was an internal code name for this machine, and the Origin systems at one point. Rumor was that they wanted to use it publicly but LEGO(tm) objected. Not sure if the rumor had any truth to it, though, since the name was dropped before I started working for SGI/Cray.
Under most versions of Unix, there is a very similar interface between the user application and the kernel. Basically, the COMPAT stuff just says "Well, this program is a MacOS X program so when it makes a call that looks like A, it really means B under NetBSD so go do that and I'll reformat the results back to what the binary is expecting". The result is that the OSX binary is really running natively under NetBSD so any device supported by the NetBSD kernel *should* be supported by OSX. It looks like their present state is trying to get enough of the OSX device interface working for that to happen.
Basically, what the COMPAT stuff emulates is not the somewhat ill-defined layer between libraries and applications in Windows, but the very well defined (and open-sourced) layer between the kernel and user-land. In order to make it useful, I'd suspect you'd need almost a full OSX installation.
There will always be crashes caused by pilot error as long as there are pilots, but I'd be willing to bet that if you put the computer in charge, the total number of crashes would go up due to the computer not being able to do something it wasn't programmed for. Nobody can envision the entire list of possible failure scenarios and I, for one, trust human intelligence more than some AI thing to cope with an unforseen failure.
Anyhow, there are a variety of reasons why they may have chosen to implement their own system which could range from conflicting code licenses to not understanding the language that it was coded in. Their site is now
Err, so from what I understand (my brother worked on this project briefly) this is basically an academic research project, that has some commercial uses. As such, CMU's CS department is interested in publishing papers, not code. The code for projects like this gets written more as a proof of concept than as a production ready set of code. So, if you want to use their code, it's going to be harder than just typing "make install". Remeber, this is code coming from the CS research department at CMU (which is quite good, I might add!), not the people who do Andrew (the academic computing environment that is more like "production code" - see the Cyrus mail system as an example of their code).
and it looks like vector instruction support on Power4 is fairly new. Also looks like a very nice chip.
In any case, there are two things that you worry about on interprocessor communication: speed and latency. Obviously, the dual-gig-E + triple Firewire is going to be faster than a single Myrinet card in terms of bandwidth (though I'd be surprised if a Mac or PC could come even close to driving all that gear at full speed), but it may not be in terms of latency. Depending on the application, this can have a huge impact on performance.
320k only beats 6 million if it's good enough to get the job you need done at the speed you need it done at. For some jobs, the $320k machine will work fine. For other jobs it won't. This is why there's still a market for big-iron Cray's, SGI's, Sun's, etc.
As for large address spaces and inter-processor communication speed, they are most certainly both necessary if you have a monster NUMA or SMP machine.
See slide #14) the processor to memory bandwidth is 38 gigabytes/sec (note bytes, not bits). Off node bandwidth is 3.2 gigabytes per second per processor for 16 processors on the node. 10-gig-E is at most 1.2 gigabytes per second.
So if we're shaking in our boots (I haven't really noticed anyone shaking due to anything other than cold, myself), it certainly isn't because of memory bandwidth... (Whoops, just reread your comment and realized you were probably kidding - didn't get my coffee today
As for why one would use Power4 instead of PowerPC, Power4 is 64 bit and PowerPC is 32 bit. You run out of address bits really fast in 32 bit mode since some people want more than 4 gigs of memory per processor and then if you have to add bits to globally address memory.....
I couldn't tell from the articles, which were thin on technical details, but straight PCI I/O off of a commodity mobo is likely not fast enough either if you are trying to build a "real" supercomputer.
So, while it's confusing the first time you see it, integer division is the "div" operator that everyone learns at some point (about the time they learn about "mod"). It was hardly a choice which was made arbitrarily.
There are a large number of reasons going back to stupid internal politics (the offenders have either quit or been fired by now - see Rocket Rick as an example), but it basically came down to two basic reasons: 1) A conscious descision was made at some point (early '90's maybe?) that Irix wouldn't be ported to a radically different (*cough* little endian) architecture and so a port would be really hard (though not impossible) and probably more important 2) Linux for this thing can run any application that is written for IA64/Linux (which presumably will be at least a few) whereas Irix couldn't. You could add a Linux syscall layer, like the BSD's have done, but then you have to track changes to GPL'd software into something that SGI couldn't GPL even if they wanted to (as Irix contains source from some other vendors). So basically, it's a) difficulty of the port from a technical standpoint and b) application capture. Presumably, IBM had similar considerations for using Linux instead of AIX.