I've been having a great week: no rain, the arguments the rocks I'm working with put up have nothing to do with IT, and lots of gratifying news floating in.
I didn't notice at the time, but apparently away back in July the London Stock Exchange got some serious press attention for cleaning its executive stables and following that by tossing the infamous TradEelect system to the wolves.
Regular readers will of course remember my comment on Microsoft's use of the TradElect contract with LSE to hype its technologies over Linux: basically that the decision had nothing to do with Linux, that the subsequent trading shutdowns reflected bad management more than poor technology, and that the people involved should be tossed out along with the software.
All kind of obvious really, but of course this generated a certain amount of off topic fury from the wintel committed - for example, deadwood1 had this to say:
Problem had nothing to do with .net or TradElectYou should do some research before you leap gleefully at any attempt to blame MS technology. The failure was due to LSE attempting to do an upgrade themselves that they screwed up. It had nothing to do with .NET not performing or a failure of the application. You lose credibility when you let your personal prejudices overshadow your journalistic integrity.
Then this week SCO finally got its chance to face Novell in court - and since that whole issue is both an absolute no brainer and the key to either forcing a settlement on IBM or eventually getting the actual claim into court, people like "Wolf_z", who wrote the comment excerpted below in response to my my comment on the Novell issue are going to be leaving their expertise on the law off their resumes:
You (conveniently) overlook a few things.5. Paul has some inexplicable need for SCO to win, perhaps he owns SCO stock. happy SCO had no case, never did have a case, and chose the wrong tiger to poke with a stick.
7. SCO isn't a threat now, and in reality never was. If there's anything left of SCO once they are forced into chapter 7 (which shouldn't take too much longer) IBM's counterstrike will leave SCO a smoking crater.
Given all this, I feel very comfortable making the following predictions:
1. The judgement against SCO will stand, the appeals court will find Judge Kimball decided correctly.
2. SCO will enter chapter 7 involuntarily before the end of the year.
3. It's my understanding liquidation of SCO won't stop IBM's countersuits, so the smoking crater might be filled in with salt. happy IBM probably *will* choose to continue in the face of SCO's liquidation. IBM will want to make very sure no one else is stupid enough to repeat SCO's mistake in the future.
And, of course, lots of people, including one Guy Smiley, vent their expertise on threading models and Intel's halfway house approach to hyper-threading with stuff like this:
Your'e hilarious Murph...So 1 HBA is bad because you get no parallelism, but 2 NICs is bad because you get bus contention. Riiiiight.
Your problem, Murph, is that you assume what you're trying to prove. Instead of analyzing anything objectively, you just look for the quickest way to reach the conclusion that Windows sucks. The result is that your arguments contradict each other, ignore the facts, and generally don't make any logical sense.
So what did AMD do this week? Announce a "new" form of multi threading for its "Bulldozer" x86 cores that's learned from Sun, optimized for Unix (including Linux), but has backwards compatibility features to support the Windows model.
But, of course, the number one subject on which I have received hate mail (due, I think, to an organized campaign by some data processing people) has long been my position that running Linux on a mainframe IFL rarely makes sense for both cost and performance reasons. So what happened last week? IBM cut its IFL and related pricing by up to 40% - and the redoubtable Timothy Morgan, a man whose editors have not, I believe, been threatened with the loss of IBM's ad dollars, wrote a remarkable article for the register in which he looks at the cost of the IFL approach.
For this article he postulates that it's possible to see just how many Intel Nehalem chips IBM thinks each IFL can replace by costing out the IBM approach and then seeing how many x86 Nehalems that same money would buy - an approach that lets him report the numbers without being even the least tiny bit critical of IBM.
The entire article is well worth reading - here's a longish extract encapsulating the key bit I'm interested in here:
When you do the math, that works out to $323,204 for a five-processor Linux machine with no memory, no disk, and no systems software, including z/VM or Linux. Because there is a big disparity between the cost of Linux on the mainframe and Linux on x64 boxes - excuse me, I forgot to speak perfectly GNUbie there: the disparity is between Linux support costs, since Linux is not an operating system and even if it were, it is free - let's add Linux to this barebones mainframe.Given the discounts that Novell has cooked up and its 80 per cent market share on the mainframe, let's slap some SUSE Linux Enterprise Server 11 on the System z BC box. It costs $10,200 per engine, with discounts for a one-year standard support contract for SLES 11 on mainframes, so that adds another $51,000. (At list price, this would cost $75,000.)
If customers want to pre-pay for five years of support, they can get a support contract for $37,499, or $7,499 per engine per year. That's a big price drop, so let's be generous and do the comparison over five years. The bare System z machine with Linux and five years of support costs $510,699.
Let's now look at how many Xeon 5500 boxes with Linux and support that gets you, not including memory, disk, or hypervisor costs, as fairly as we can, given the lack of information about mainframe pricing. We'll take IBM's own System x servers, and use the System x3550 M2 rack server, the cheapest of IBM's Nehalem EP boxes. With two of Intel's four-core, top-end Xeon X5570 processors, the x3550 M2 costs $6,681. Main memory for this x64 box costs $109 per GB, and there is no way IBM is not charging a lot more for main memory on mainframes.
Now, toss on SLES 11, which is priced per machine, not per processor core, on x64 machinery. It costs $799 per box per year, or $3,995 per box for five years of support. So that comes to $10,676 for a bare-bones x64 Linux image.
What these system prices imply is that a fully-engined System z BC with five 3.2 GHz engines should be able to support the same number of Linux images as 48 of those System x3550 M2 rack servers, which have a total of 384 Nehalem cores running at 2.93 GHz.
As in, "Ya - you know, like he said" - pricing parity means either that any performance discrepancies between the 16Ghz delivered by the five IFL engines and the 1,125GHz delivered by the x86 boxes are purely imaginary, or that the mainframe approach is a trifle over-priced.
But hey, what am I doing about it? Nothing - I'm going out to argue with another couple rocks.