Oracle loses appeal in HP row over Itanium Oracle's last-ditch effort to wriggle out of a judgment requiring it to continue support for HP's Itanium-based servers has failed, leaving only the issue of damages to be resolved. In August 2012, a San Jose, California court ruled that Oracle had violated the terms of its contract with HP when it announced that it would no …
"What you consider an epic fail the rest of the computer industry considers the norm"
You seem to think those two are mutually exclusive. Massively distributed computing is the norm... and it is a massive failure. Client/server is widely considered to be a technologically inferior architecture and a huge, huge headache/administrative time vampire. The promise was that client/server would be so much more agile and allow for rapid deployments, which, at the time, was true. Client/server could roll out apps faster than a centralized mainframe. That was primarily because bureaucracy had been built around mainframe access whereas any business unit could buy a MS servers or Groupware or a Domino server or a mini and start working on stuff outside of the mainframe. All of client/server started as a skunkworks operation. Like all other skunkworks operations though, the problem was not in deployment, it was in management. Before long, there were servers and data floating around everywhere. There was no way to manage it and there was no way to control the data. This resulted in huge, bloated Windows admin staffs, and other early client/server OSs, as well as no "single source of the truth." Many different departments all had their own customer table, revenue table, so forth. You can look at the last 20 years as an effort to try to put the mainframe architecture back together again. Scaling up first Unix and then x86-Windows, virtualizing the platforms, adding system management software which has been present in mainframe for 40 years, etc. Moving from massively distributed back to centralized while using distributed servers in a cluster with web-access and as little as possible on the client side (web apps, thin clients). The modern x86 architecture is a make-shift, ad hoc, best effort at recreating the mainframe. You don't see many true client/server apps any more, with the processing split between the client and the server. It is all server with a terminal.... some call it the "cloud", but it is just the centralized, mainframe-terminal architecture.
".....Massively distributed computing is the norm... and it is a massive failure....." You speak so much contradictory rubbish it's like someone wrote a program to generate stupidity. Companies, especially large corporations, do not invest in failures, they invest in systems that they believe, after careful analysis, give them the best business performance for the least cost. That is why mainframe is dying.
".....It is all server with a terminal.... some call it the "cloud" but it is just the centralized, mainframe-terminal architecture...." Rubbish. In the classic mainframe-terminal environment, all the processing and computation takes place on the mainframe and the terminal is just a data entry and direction device. With modern cloud the terminal also often does computational work - it might call on cloud applications for data or to calculations, but the core does not do all the work.
".....Companies commonly invest in failures....." Your mother obviously never told you that if you don't have anything sensible to say it's better to keep schtum. Every time a company makes a failed investment in a wrong technology the word spreads.
"......Hugely cost ineffective environment....." GET OUT OF THE MAINFRAME BUBBLE!
"Companies, especially large corporations, do not invest in failures, they invest in systems that they believe, after careful analysis, give them the best business performance for the least cost. That is why mainframe is dying."
Companies commonly invest in failures. The client/server environments did not start as well thought out investments. They started as the marketing department buying a few servers to run some app, and some factory buying some apps to manage their replacement parts, etc, etc. IT departments were, and largely still are, helpless to stop the lines of business from doing whatever they feel like. After awhile the IT department asked if they could at least centralize/consolidate all of these little servers scattered all of over the place, which basically brings us to present day. It was a skunkworks operation that IT just decided to pretend was their idea and took responsibility for over the years. Hugely cost ineffective environment. As everyone knows, hardware costs are a drop in the bucket of overall IT costs. The major cost is staffing and client/server drove that through the roof.
"With modern cloud the terminal also often does computational work - it might call on cloud applications for data or to calculations, but the core does not do all the work."
If you have noticed, the client side does less and less work all the time. Basically the only thing the client needs to do today is open an internet browser and run the IP adapter drivers. The OS is really not necessary. It is getting very similar to the mainframe. Everything is developed on the server. The only thing the client is there for is to connect to the server.
".....First, you can manage an incredibly large mainframe environment with a handful of people, thousands of virtual servers. It would take a hundred people to do the admin for that workload on Windows... just to handle Patch Tuesday. ...." Oh dear, once again all you are doing is exposing your lack of experience and knowledge outside the mainframe bubble. Patch management has been automated for years, large corporations regularly patch thousands of systems with a few clicks of a mouse. Tools for managing very large Wintel/Lintel farms have been around for donkey's years, I would suggest you go read up on VMware for a start, but that would only be a start as your knowledge is so obviously twenty years out-of-date. As an opener, all your reply did was ensure that the rest of your post should be ignored do to your colossal ignorance.
"".....First, you can manage an incredibly large mainframe environment with a handful of people, thousands of virtual servers. It would take a hundred people to do the admin for that workload on Windows... just to handle Patch Tuesday. ...." Oh dear, once again all you are doing is exposing your lack of experience and knowledge outside the mainframe bubble. Patch management has been automated for years, large corporations regularly patch thousands of systems with a few clicks of a mouse. Tools for managing very large Wintel/Lintel farms have been around for donkey's years, I would suggest you go read up on VMware for a start, but that would only be a start as your knowledge is so obviously twenty years out-of-date. As an opener, all your reply did was ensure that the rest of your post should be ignored do to your colossal ignorance."
Matt. Rather than spout off, just go into any site and look at the mainframe v Windows support people and the size of the estate they support. Yes, patching etc. has been automated for years (when it works), but you'll still see the Windows support teams are huge in size compared to the mainframe teams. You can argue what they do, but the size difference is obvious. Which is the most cost-effective model is questionable though, as the larger number of Windows people are, individually, far cheaper. So, total costs needs to be looked at. But, from a count of people, AC is absolutely right.
".....you'll still see the Windows support teams are huge in size compared to the mainframe teams......" If there is a larger Windows team it is because they are doing so many different parts of the stack that mainframe does not get considered for. Most companies with mainframes do not have massive implimentations, they have one or two legacy apps still on mainframe, doing things like the warehouse and stock management, whilst the Windows teams are doing not only the desktop but also email, departmental applications, VMware farms, security, etc., etc. You only have to look at hosting companies to see which is the preferred platform - not mainframe. And if mainframe was "the most efficient" as you contend then hosting companies would offer nothing else as they live on offerring the best service they can for the minimal outlay. And when you want to compare the two IT teams, you should also look at the management layer above - whilst the mainframe dinosaurs are stuck going nowhere it is usually the Windows guys that get promoted up through the IT management layer to the CIO roles.
"Most companies with mainframes do not have massive implimentations, they have one or two legacy apps still on mainframe, doing things like the warehouse and stock management, whilst the Windows teams are doing not only the desktop but also email, departmental applications, VMware farms, security, etc., etc."
Now who's not been about much? Go and actually look at some mainframe sites and learn the truth. The vast majority of mainframe MIPs sold today are not even for z/OS. It is for Linux on z/IFLs. Indeed. there is a hosting company in Sweden that purchased a mainframe for hosting thousands of Linux servers. It was actually a HOSTING company!! Now, I'm not going to deny that mainframes aren't used for hosting Windows, but that's largely because Windows is so poorly dispatched, it can't displatch properly on processors.
Haven't looked recently, but have VMWare solved the asynchronous processor dispatch issue that results in huge amounts of seemingly used processor actually being wasted? I doubt if you even know what this is!! After all, if you can't dispatch a virtual machines processors asynchronously and have to dispatch them all synchronously, you'll have processors waiting around or short processors everywhere. In the latest missive I've got from VMWare, synchronous dispatch is sold as a benefit!! Yeah....right. Mainframe solved being able to asynchronously dispatch processors nearly 20 years ago!!
"And when you want to compare the two IT teams, you should also look at the management layer above - whilst the mainframe dinosaurs are stuck going nowhere it is usually the Windows guys that get promoted up through the IT management layer to the CIO roles.
House Rules"
I wouldn't deny that more managers are from a Windows background, but that's partly because there are more of them. Also, that doesn't mean it's a better management team. In a lot of sites I've been to or worked at, the management have been heavily Windows based, but when shown how much a decent mainframe or Unix implementation could save them, have rather changed tunes. That's not to say Windows isn't right for some things, it is. It's just that different platforms have different advantages for different applications. Horses for courses; no one correct. And yes, even the mainframe has some apps it is best for. Just look at the major banks and see how many run their critical applications there and that's not because they're legacy. I know of several that have within the last 10 years completely rewritten their banking systems to run there.
".....It was actually a HOSTING company!!...." One mainframe hosting company - yeah, a real industry standard offering then - not! Such a desperate fail, please go and look at the number of Wintel/lintel hosters out there.
".....It is for Linux on z/IFLs. ...." LOL! The whole Linux on mainframe jaunt is a desperate defensive ploy by IBM trying to stop them being gutted by x64 Linux kit. It is not new customers, it is highly-subsidised old mainframe customers being persuaded not to dump the mainframe because IBM know that the majority of IBM mainframe replacements are not going on IBM servers.
You can argue your mainframe sales pitch until you're blue in the face, it matters little as mainframe is a declining market and the only one you're fooling with your dribbling is yourself. Enjoy!
"You can argue your mainframe sales pitch until you're blue in the face, it matters little as mainframe is a declining market and the only one you're fooling with your dribbling is yourself. Enjoy!"
And yet, you still refuse to take my bet that mainframe will be around long after the Itanium has gone the way of the dodo. You really don't believe what you spout do you!!
"....you still refuse to take my bet that mainframe will be around long after the Itanium has gone the way of the dodo...." I gave a couple of very good reasons why I wasn't interested. I could add that my consience would be pricked by taking advantage of someone so incapable.
"....You really don't believe what you spout do you!!" The really amusing bit is you obviously are so deluded you actually belief all the easuly debunked twaddle you post. And then carry on believing even after it has been so easily debunked! Seriously - seek help.
"Oh dear, once again all you are doing is exposing your lack of experience and knowledge outside the mainframe bubble. Patch management has been automated for years, large corporations regularly patch thousands of systems with a few clicks of a mouse."
Yes, I have read the BMC/CA/Tivoli marketing literature too, but it never works out that way. You have prod_02 which cannot upgraded to patch level xyz because of some application dependency which requires a different level. You have cluster 4 which will have an incompatible adapter level if you upgrade, so that can't be done.... There are tons of variables (due to all of the component OEMs and ISVs in the x86 world), server to server, workload to workload, in x86. Even if the magic button did exist, you still can't just hit that button to install a new patch level or firmware level across across 200 servers because you will knock half of them offline and have to roll back. Not to mention, you generally need to recycle the servers during updates/grades, which is not something you want to do all at once, across the board. Theoretically you could VMotion the workload off to some HA server, upgrade, and VMotion them back to the server in an automated manner.... I have heard that said many times, never actually seen it happen due to the above.
Mainframes do not get patched nearly as often, like once every three months. Patches are considered "product defects" in the mainframe world. When you need to apply a patch or upgrade, there are far fewer variables to consider in the logic path (you don't have to worry about syncing your VMware and MS levels or Q-Logic and VMware levels) and are generally live updates without any downtime.
".....I have read the BMC/CA/Tivoli marketing literature too...." The problem is reading about modern x64 is the only reference point you have, you simply have no experience outside the mainframe bubble. Even then, you're trying to deny many of the problems you mentioned don't exist for mainframe. Application dependency conflicts happen on mainframe as well, or are you gong to pretend only IBM writes all mainframe software and has complete and total control? Complete male bovine manure. True, the number of mainframe-only ISVs is declining all the time.
As for you not being able to apply a patchset to a mix of systems, that is why we have standard builds. They have been around for a very long time (I can remember being paid to write and test them in the Eighties!), so long I'd have thought even mainframers would have heard about them by now, but evidently not. Forget getting laid (it would probably kill you anyway), you lot just need to get out more.
".....you still can't just hit that button to install a new patch level or firmware level across across 200 servers ...." See, this is where you just show how little you know. After I have tested my patch set, I can set profiles for my servers and deploy to schedules, then it really is one click to ensure that the session gets run in such a manner that the business does not see any outages. Forget x64, I've been able to do that on UNIX for years! Where the fudge have you been keeping? Seriously, ask Ginni Rometty to swallow some manuals so you guys can catch up on the reading you've missed in the last twenty years.
"The problem is reading about modern x64 is the only reference point you have, you simply have no experience outside the mainframe bubble. Even then, you're trying to deny many of the problems you mentioned don't exist for mainframe. Application dependency conflicts happen on mainframe as well, or are you gong to pretend only IBM writes all mainframe software and has complete and total control? Complete male bovine manure. True, the number of mainframe-only ISVs is declining all the time."
I wouldn't deny that some dependency conflicts don't occur, but generally they are far less. This is because the various layers of the code stack are far more separated and standardised on the mainframe. Yes, it happens, but nowhere near as much as other platforms, including Unix.
"As for you not being able to apply a patchset to a mix of systems, that is why we have standard builds. They have been around for a very long time (I can remember being paid to write and test them in the Eighties!), so long I'd have thought even mainframers would have heard about them by now, but evidently not."
Yep. And mainframes have had standard builds for decades beyond Windows. Where do you reckon the idea came from!! The issue is normally around the number of standard builds you need. For Windows, you need different ones for all the types of servers/desktops you have. In mainframe you normally have.....one!! Granted, there's been a lot of work done recently to reduce the number of builds required, but maybe you'd like to enlighten us on how many Windows builds your current estate has? As I said, mainframe should only have one (or maybe two during O/S version upgrades.....old and new), so any advance on that is additional overhead!!
"See, this is where you just show how little you know. After I have tested my patch set, I can set profiles for my servers and deploy to schedules, then it really is one click to ensure that the session gets run in such a manner that the business does not see any outages. Forget x64, I've been able to do that on UNIX for years! Where the fudge have you been keeping? Seriously, ask Ginni Rometty to swallow some manuals so you guys can catch up on the reading you've missed in the last twenty years."
Yep; great theory. A majority will work without issue. However, there is always a failure rate. So, what's your failure rate? And don't say zero, that's just being silly. For Windows servers and desktops this is. And why are you suddenly mentioning Unix here. The whole thread before this was talking about patching Windows servers, not Unix. I would be the last person to say HP-UX didn't have a decent patching mechanism and regime, just like other Unix O/Ss.
P.S.
The patch issue on Windows isn't so much an issue with Windows, but the vast array of slightly different hardware it can run on. The secret to removing the patch issue is not so much running good software to do it for you, but to limit the hardware differences. The same applies to Linux on x86 to a great extent as well. It's no secret that controlling the hardware stack is the key. That's why Apple software is so much more stable and easier to upgrade and more stable than Windows. They have complete control over the hardware stack and can dictate. Either way you pay the price; in purchase price or maintenance costs.
P.P.S.
If you say you don't get any failures, people will just laugh at you. I remember when working at a major bank, the desktop patch failure rate was about 2% for cleaners taking the plugs out of sockets for the desktops to plug in their vacuum cleaners!! No amount of education ever got around it!! You don't normally get that issue with Unix or mainframes!!
".....I wouldn't deny that some dependency conflicts don't occur, but generally they are far less....." So you have to admit that the problem y claimed only happened on x64 actually occurs in the mainframe world. So nice to see you admitting yr own arguments are unadulterated male bovine manure. Shame you then go on for several ranting paragraphs trying to deny what you just admitted. The reason they a "far less" on mainframe is there are far less mainframes running far less applications from far less ISVs than x64.
"......However, there is always a failure rate. So, what's your failure rate? And don't say zero, that's just being silly...." Zero. It's called testing, in some cases over a six month schedule. Try it some time. Well, if you get a chance before you get retired.
"......Either way you pay the price; in purchase price or maintenance costs....." The simple fact that mainframes are being ripped out and replaced by x64 systems all over the World primarily on the basis of COST-SAVINGS exposes that complete fantasy. Mainframe is not Apple. And Apple is also MORE EXPENSIVE, as shown by their complete failure to gain any desktop share compared to Wintel. As I said earlier, you are not equipped for this debate, you simply don't have the knowledge.
".....If you say you don't get any failures, people will just laugh at you....." Did I say I never get any failures? But I have heard of mainframe hardware failures taking down a complete mainframe, something you dinosaurs insist can never happen.
"So you have to admit that the problem y claimed only happened on x64 actually occurs in the mainframe world. So nice to see you admitting yr own arguments are unadulterated male bovine manure. Shame you then go on for several ranting paragraphs trying to deny what you just admitted. The reason they a "far less" on mainframe is there are far less mainframes running far less applications from far less ISVs than x64."
I think you'll find it wasn't me that said anything about this problem initially and I have never said it doesn't occur on mainframe. Perhaps you should reread the thread like you failed to do last time and I had to point out.
"Zero. It's called testing, in some cases over a six month schedule. Try it some time. Well, if you get a chance before you get retired."
That noise you're hearing is the sound of every IT professional laughing at you for such a silly comment.
"The simple fact that mainframes are being ripped out and replaced by x64 systems all over the World primarily on the basis of COST-SAVINGS exposes that complete fantasy. Mainframe is not Apple. And Apple is also MORE EXPENSIVE, as shown by their complete failure to gain any desktop share compared to Wintel. As I said earlier, you are not equipped for this debate, you simply don't have the knowledge."
As I said before, different hardware is better for different scenarios. Sometimes x86 is cheaper, sometimes not. And by the way, Apple does have a desktop market and a reasonable one. In certain sectors (you see, horses for courses again), like say design, Apply own them, not x86. Also, they pretty much own the tablet marketplace with Android much to Microsofts (and presumably your) disgust. And, as for phones. Don't even get me started there, much like Microsoft has never got started either!!
"Did I say I never get any failures? But I have heard of mainframe hardware failures taking down a complete mainframe, something you dinosaurs insist can never happen."
Now you can't even read the same post correctly!! Look two paragraphs up and you'll see you have said you get zero failures!!
"....That noise you're hearing is the sound of every IT professional laughing at you for such a silly comment....." Hey, I can't help it if you don't know how to test a patch release. Some of us can.
"....different hardware is better for different scenarios...." The only scenario mainframe is better is "we have a f*cking old mainframe app we can't port because all the developers of the ancient code died of old age and we haven't a clue how to get the data out of it". No other case for mainframe exists, period.
"....Sometimes x86 is cheaper...." The only time mainframe is cheaper is when the associated cost of getting off the old mainframe apps is too much or too risky. I have seen companies completely abandoning old apps and data just to get off mainframes, and data is the last thing you ever want to ditch.
"Application dependency conflicts happen on mainframe as well, or are you gong to pretend only IBM writes all mainframe software and has complete and total control?"
I am not saying that there is absolutely no application dependencies with mainframe. I am saying they are tremendously less prevalent than on x86. With mainframe, as you mention, most applications are custom developed... so no issues there. The vast majority of the stack is developed by IBM specifically for the mainframe, so the software is closely aligned with the hardware upgrades... hand in glove. There are third party ISVs, such as CA, BMC and some industry specific customer app providers (FS especially), but they follow z/OS, z/VM religiously and are in close contact with IBM.... It is totally different on x86 where you have ISVs which are intentionally trying to undermine each other, such as Oracle and VMware, Oracle and RHEL, Microsoft and everyone other than Microsoft, etc. They have no interest in integration. Oracle, for instance, wants to make it impossible to use VMware or Hyper-V... so you will use OVM. There is also the hardware side of the equation. How many NIC providers are out there for x86? I have no idea, but a ton... each with their own firmware. Mainframe has a few very well tested options that work closely with IBM. How many storage arrays and HBAs for x86? No one probably knows, but hundreds. With mainframe, you have DS8, VMAX and HDS. Even if all of the x86 stack vendors were close partners and wanted to integrate their gear tightly with everyone elses, which is certainly not the case, it is practically impossible for VMware, for instance, to thoroughly test all of the storage arrays on the market. IBM controls the mainframe ecosystem. If you want to play, you play by their rules. x86 is a total free for all, which is not ideal if you want no bugs and high uptime.
"See, this is where you just show how little you know. After I have tested my patch set, I can set profiles for my servers and deploy to schedules"
Are you reading what you are writing? "After I test my patch set"... exactly what I just wrote you have to do with x86 and testing the patch set for a large environment is no five minute task. I think the issue is that you assume things like "testing the patch set" are just how computers work and mainframe must be the same way. That is not how computers work, that is how distributed architectures work.
".....most applications are custom developed... The vast majority of the stack is developed by IBM specifically for the mainframe......There are third party ISVs, such as CA, BMC and some industry specific customer app providers (FS especially), but they follow z/OS, z/VM religiously and are in close contact with IBM.... How many NIC providers are out there for x86? I have no idea, but a ton... Mainframe has a few very well tested options that work closely with IBM. How many storage arrays and HBAs for x86?....." I always get a good laugh when the mainframers try spinning their lack of choice as some sort of advantage! Like no ISV ever works closely with any other OS provider - what claptrap!
"I always get a good laugh when the mainframers try spinning their lack of choice as some sort of advantage! Like no ISV ever works closely with any other OS provider - what claptrap!"
If you look at the marketplace at the moment, you'll notice a fair chunk of people being willing to pay the extra money and tolerate the lack of choice for products that just work. It's called Apple. And pretty damned successful and rich they're becoming out of it. End users are simply fed up with Windows failing all over the place. They don't want to know how to run it, create builds etc.etc. They just want a device that works and Apple is giving them this. And they're willing to pay extra for it, including lack of choice. So, this is a valid choice and a valid marketing and business strategy.
"....If you look at the marketplace at the moment, you'll notice a fair chunk of people being willing to pay the extra money and tolerate the lack of choice for products that just work...." There are a fair number of companies still using Slowaris on SPARC because they are stuck on it. I even hear there are companies stuck with VAX systems for the same reason. You are simply confusing the result of bad previous business decisions with desireability.
".....End users are simply fed up with Windows failing all over the place...." Really? If that was true then Microsoft would have gone bust by now, instead of being the owner of teh most populous desktop, office application software, and server software. Stick to the little you know and leave real IT to the rest of us.
"I always get a good laugh when the mainframers try spinning their lack of choice as some sort of advantage! Like no ISV ever works closely with any other OS provider - what claptrap!"
It is not as though the ISVs/OEMs don't want access to the mainframe. Many ISVs/OEMs want to sell their wares into the most mission critical and cost flexible (no one goes with the low bid because it is the low bid on their core transactional systems) environment on the planet. For instance, EMC pays IBM a shed load for access to z and i IP. Oracle created their own MAA architecture for zLinux and offers pretty attractive Oracle DB pricing for zLinux. Oracle traditionally doesn't work with anyone on anything (they create a port, the OS/OEM optimizes it), but they have for z at their own cost... because it is a lucrative market, IBM told them they had to, and, if they didn't, people would just use DB2. The difference is that IBM controls the mainframe ecosystem. They are not going to grant access to any random OEM/ISV if they do not agree to test it thoroughly with the mainframe. They are fine with competition, e.g. Oracle, BMC, or CA, but they are not going to let them do whatever they feel like, whenever they feel like, and decide not to integrate because it serves some competitive purpose. Totally the opposite on x86, anyone can do anything whenever they feel like it. If Oracle decides that they don't like the majority share hypervisor, they are free to undercut it. If VMware feels like testing Q-Logic, but not so much on Hitachi, who is to stop them... and how are you to know that one is preferred and the other is tolerated?
The point is not that SOME ISVs work closely with OS/OEM in x86 because it suits their competitive purposes for a period of time, it is that it is a complete luck of the draw, subject to change at any moment. If they decide they are no longer friends, Red Hat and Oracle... or Microsoft and VMware... or Cisco and VMware/EMC, nothing you can do about it and no way to predict it. If you buy anything with is supported for mainframe, you can rest assured that it has been tested 34 ways towards the weekend.
"It is not as though the ISVs/OEMs don't want access to the mainframe...." Of course, it's the best scam going! Customers are locked in by the poor application choice and the cost of getting off the sinking ship. From the ISVs' viewpoint it's a great market as they can charge an arm and a leg and blame it all on IBM!
"....people would just use DB2...." So your point is DB2 was so crap that Oracle took all ther mainframe DB customers? LOL!
"....Totally the opposite on x86, anyone can do anything whenever they feel like it. If Oracle decides that they don't like the majority share hypervisor, they are free to undercut it. If VMware feels like testing Q-Logic, but not so much on Hitachi, who is to stop them...." What you are trying to knock is the effectiveness of an open market model. If say Hitachi come along with a good product then the customers put pressure on Microsoft to work with Hitachi or they will go to the OS vendor that does. In the mainframe case it is the opposite - if IBM don't like the product because it will reduce their revenues, despite the benefit to the customer (PSI and Hercules are great examples), then IBM simply kills the product. And you want to describe that as good!?!?!? I'm not surprised you are not in a position to dictate startegy or make purchasing decisions.
"....You seem to know more about me by analysis of a simple posting than a truth teller...." But that's the whole sorry point, every post you make on any thread is simply a bleating of opinion, and when you are challenged by a conflicting opinion backed up by proveable statements, you don't try and argue your case, you just go off on a rant. The topic could be anything, from Stars Wars movies through politics, and all you can muster is sad ranting. If anyone does anything to expose the silliness of your non-arguments it is you. I guess it really upsets you that Larry didn't manage to kill Itanium, despite all those posts you have made assuring us it would. I think you really need a hobby.
IBM does have details about Power8 in its public roadmap and has for two years.
there is a tool called google to find info.
there is also a site called wikipedia which has the details.
curious when Itanium will have hardware virtulization?
Except for larry pissing on itanium already do you think $500M will just piss him off more or make a difference in the business for customers?
e99
Alli, nothing exposes the silliness of YOUR posts too than their content. ".....curious when Itanium will have hardware virtulization?....." Go read up on npars, available from back in the days of PA-RISC, and which IBM cannot match with Power. That is real, electrically-isolated hardware, something IBM just cannot do, even with the "legendary" mainframe. You can find plenty of info on npars if you use that Google tool you mentioned....
".....or make a difference in the business for customers?" Well, let's see - first there is the reassurance of hp taking Oracle to court, showign their commtiment, and then there is the cast-iron guarantee that they will have availabilty of Oracle software on hp Integrity servers. Now, think carefuly - is there any guarantee that IBM can give to their customers that Power and AIX will have Oracle support beyond even tomorrow, should Larry decide he wants to take it away? In fact, Itanium is now the ONLY enterprise CPU with guaranteed availability fo products like Oracle Database, RAC, etc. Not Power, not Tx, not Xeon, not SPARC64. Gee, that might make a slight difference with customers. Duh!
'Alli, nothing exposes the silliness of YOUR posts too than their content. ".....curious when Itanium will have hardware virtulization?....." Go read up on npars, available from back in the days of PA-RISC, and which IBM cannot match with Power. That is real, electrically-isolated hardware, something IBM just cannot do, even with the "legendary" mainframe. You can find plenty of info on npars if you use that Google tool you mentioned....'
All completely irrelevant. If you want electrical isolation, go buy seperate servers. Effectively, all you've got are several server stuck together with gaffer tape with nPARs. Completely pointless. And for your information, mainframes used to be able to run electrically isolated partitions. Effectively, the machine was simply cut up into several. However, IBM (and most of the others) have realised that electrically separated partitions might sound good on paper, but they're economically not viable. My company evaluated Integrity some time ago and nPARs counted for nothing. They were, from a practicality point of view, utterly useless. vPARs are a different matter, but then, they're not electrically isolated, so not the same thing.
If you think electrically isolated partitions are the way forward, you are really living in another world. Oracle have exactly the same issue with domains on their M-series servers. Total lack of flexibility and resource sharing, which is the only way of getting good bang per buck on your servers these days.
Mike, there is a lot more to being mad than just not knowing anything about the topic in hand. Please re-label yourself Ill-educated Mike, it would be more fitting.
".....All completely irrelevant....." Really? Is that because IBM and Oracle can't do it?
".....If you want electrical isolation, go buy seperate servers....." But then the image sizes are constrained by the boundaries of the individual servers. The hp npar technology allows you to make smaller or larger partitions withint eh same frame. On the Superdome2 the size of an npar is based on the multiples of the four-socket cellboard, and you can alter them as requirements change. You simply can't do that with individual servers.
"....Effectively, all you've got are several server stuck together with gaffer tape with nPARs...." I suggest you go back to troll school and actually learn about the hp tech before you make yourself look any more ignorant.
"....mainframes used to be able to run electrically isolated partitions....." No they couldn't, they had common electrical components that meant an electrical issue on one partition of a mainframe could take down another partition. I suggest you read something other than the IBM FUD guide.
"....but they're economically not viable....." Because IBM couldn't do them? It seems hp made them both technically viable and sold plenty of them, which suggest your just mouthing off sour grapes because IBM didn't manage it.
".....vPARs are a different matter, but then, they're not electrically isolated, so not the same thing...." Wow, you actually said something factual! Even if it doesn't have anything to do with npars. I see you also forgot about IVM and hp9000 Containers, but then expecting you to know anything more than the IBM FUD soundbites about hp's tech is obviously a bit too much.
"....If you think electrically isolated partitions are the way forward, you are really living in another world....." I evidently am. In mine, I work on enterprise systems that require real processing power. You seem to only work on IBM mainframe sales pitches, and using very old FUD for that. I suggest you ask Jesper for help, he at least knows something exists outside the IBM bubble.
"Really? Is that because IBM and Oracle can't do it?"
Nope. Because nobody in their right minds runs electrical isolation anymore unless something like military. It simply isn't necessary and isn't economic. By the way......nPARs aren't really fully electrically isolated as some components are still shared. Not many I'll grant. Oracle can actually do it as Domains on their current m-Series are electrically isolated as much as nPARs are. However, that's why Oracle are moving away from them. They simply don't make sense anymore.
"But then the image sizes are constrained by the boundaries of the individual servers. The hp npar technology allows you to make smaller or larger partitions withint eh same frame. On the Superdome2 the size of an npar is based on the multiples of the four-socket cellboard, and you can alter them as requirements change. You simply can't do that with individual servers."
I agree. But then, if you're that bad at sizing your servers and predicting future growth, you deserve the extra cost and aggravation. The very fact that nPARs are based around multiples of 4 processors (potentially 32 cores) is one reason they're useless. Even in my FTSE 30 company, that is simply too big. The granularity is hopeless.
"I suggest you go back to troll school and actually learn about the hp tech before you make yourself look any more ignorant."
Standard from someone who can't answer the points. Simply insult the intelligence of someone with arguments and claim their 'knowledge' is poor. Absolute rubbish.
"No they couldn't, they had common electrical components that meant an electrical issue on one partition of a mainframe could take down another partition. I suggest you read something other than the IBM FUD guide."
For your information, I used to work on a mainframe that was (at one point) divided into two electrically isolated partitions. We're talking around the 1986-88 timeframe. It was actually a Hitachi MVS mainframe called a XL70 I think (if memory working). Suggest you go look it up.
"Because IBM couldn't do them? It seems hp made them both technically viable and sold plenty of them, which suggest your just mouthing off sour grapes because IBM didn't manage it."
No, because they are not granular enough and cannot donate processor to another partition when this nPAR doesn't want it. If you want to run with the utilisation levels of a windows x86 server, then fine, but you'll be paying well over the odds. HP may have made them technically work, but I've spoken with HP salesmen about this and very few companies actually used them. Most prefered vPARs or IVMs. This was also reflected at a series of seminars I attended in Bracknell. So, very few actually wanted nPARs.
"Wow, you actually said something factual! Even if it doesn't have anything to do with npars. I see you also forgot about IVM and hp9000 Containers, but then expecting you to know anything more than the IBM FUD soundbites about hp's tech is obviously a bit too much."
Slagging off again, showing no argument to make. For your information, I know plenty about Integrity as I've done in-depth technical analysis of ALL Unix vendors for my company.
"I evidently am. In mine, I work on enterprise systems that require real processing power. You seem to only work on IBM mainframe sales pitches, and using very old FUD for that. I suggest you ask Jesper for help, he at least knows something exists outside the IBM bubble."
Well, either you're a troll (probably true) or your employer is wasting one hell of a lot of money. I work for a FTSE 30 company that requires enterprise scale Unix computing and nobody round here would ever touch nPARs. They are simply too inflexible. I'm perfectly aware of stuff outside the IBM bubble and we run Solaris as well. Of course, that will just feed your rants as your insistence nobody knows anything outside of IBM or Oracle and your continual slagging of these companies and people using them hides your apparent poor choice in the past. We're running big end p-Series servers at 80-90% continual utilisation. We've had them running at 100% for extended periods before without any issues. That's real bang per buck. What's the best you've achieved with nPARs? Bet you struggle to get above 20-30%. All that wasted processing power......now that's efficient!!
".....Because nobody in their right minds runs electrical isolation anymore unless something like military. It simply isn't necessary and isn't economic....." Ah, I see that your madness goes beyond just a Napoleon complex, you actually believe you have worked in all industries! I can assure you npars are still used, we use them and we're not military, and that they came in cheaper than the equivalent IBM solution. I am tempted to suggest that in fact you have never worked on anything other than mainframe, hence your blinkered view of the rest of the computing world.
".....Oracle can actually do it as Domains on their current m-Series are electrically isolated as much as nPARs are....." No they can't and they don't even try claiming they can. Please try and keep at least one foot in reality, it would help.
".....The very fact that nPARs are based around multiples of 4 processors (potentially 32 cores) is one reason they're useless. Even in my FTSE 30 company, that is simply too big. The granularity is hopeless....." Apart from the obvious fact other customers disagree, maybe you should have stopped to think that IBM's modular P-series are based on 4-socket boxes - duh!
".....No, because they are not granular enough and cannot donate processor to another partition when this nPAR doesn't want it....." All you are showing is that you really don't know anything about the hp partitioning technologies. If I want to use a single CPU as the granularity I can do that inside an npar with vpars, or go sub-CPU with Integrity Virtual Machines or resource scheduling via PRM.
Look, you go do a lot more reading and then come back with a coherent argument that won't get you laughed at, OK?
npar is just partitioning not virtualization. Apparently there is no plan to provide real virtualization in the hardware.
nice....take the disaster of Larry paid back for hurd and try to position it as a competitive advantage. Don't keep your head in the sand too long you will get burned. Everyone is circling the dead itanium carcass and having an unoptimized port will not help hp. At least IBM's Power systems has DB2 to keep Oracle motivated.
e99
"npar is just partitioning not virtualization...." So nothing is "virtualisation" unless IBM can do it? Very open mind you have there - NOT! And hp descirbe it as part of their partitioning offering, not virtualisation. IBM don't describe it outside of FUD as they can't do it.
"....take the disaster of Larry paid back for hurd and try to position it as a competitive advantage..." OK, let's do a simple comparison. Let's pretend I'm a customer asking about software support for my new platform - if I ask the IBM rep can he guarantee that Oracle DB will be available next year for a P795, can the IBM rep guarantee it 100%? The hp rep selling a Superdome2 can guarantee it, the IBM rep can't. If you don't think that is an advantage then it is because your IBM blinkers mean you do not want to admit it is one.
"OK, let's do a simple comparison. Let's pretend I'm a customer asking about software support for my new platform - if I ask the IBM rep can he guarantee that Oracle DB will be available next year for a P795, can the IBM rep guarantee it 100%? The hp rep selling a Superdome2 can guarantee it, the IBM rep can't. If you don't think that is an advantage then it is because your IBM blinkers mean you do not want to admit it is one."
How simplistic you are. Nobody can ever guarantee any software support for any period of time. All sorts of things could happen that cause the support to disappear. In the real world, Oracle would love to pull Oracle support from p-Series. They'd love everyone to use their products; of course they would. However, the revenue that Oracle pull in from p-Series is so large (and is likely to remain so) that pulling support is simply not going to happen. So, your argument is spurious.
Also, don't overplay the judgement handed down. Yes, it says they must continue to support their software on Itanium for as long as Itanium exists. Well, it's well know that software vendors have different versions of the same product for different architectures, often with different features. The judgement doesn't say anything about that. So, Oracle can functionally stabilise the Itanium version of the software (whilst maintaining support), but continue development on the others. This is certain to kill it just as much as anything else. Once the functionality gap is big enough, people simply won't run Oracle on Itanium except for legacy apps that don't require it. Then, Itanium becomes the new mainframe!! And, this is entirely in accordance with the judgement handed down. The judgement never said they had to enhance the software!!
".....How simplistic you are...." Yeah I'm pretty simple - I read stuff, absorb the demonstrateable facts, then apply them. So much simpler than your self-delusional fantasy world!
".....Nobody can ever guarantee any software support for any period of time....." LOL! It is so amusing that you are so desperate to deny even that simple case! I bet you can see Ginni Rommetty's tonsils from there every time she swallows.
".... Yes, it says they must continue to support their software on Itanium for as long as Itanium exists. Well, it's well know that software vendors have different versions of the same product for different architectures, often with different features....." Hp have existing agreements that already tie Oracle to giving equal treatment to hp-ux as Solaris, all covered by the "business as usual" contract. Read it and weep, dinosaur.
Oh Matt, you're really funny. You really need to get out more, but the guards would need to unlock the doors!! It's really great that they install computers in secure wards for you to use. Must help while away the hours!!
"Hp have existing agreements that already tie Oracle to giving equal treatment to hp-ux as Solaris, all covered by the "business as usual" contract. Read it and weep, dinosaur."
P.S.
I'll just reply on this one point. I was talking with someone very senior at Oracle the other day. They are intending to put accelerators in their Sparc chips to help various Oracle products perform better. That will be a feature available on Sparc only. They already do it with Exadata, which has a particular compression mechanism only available on Exadata. So, 'fraid reality has already shown you don't know what you're talking about!!
"....I was talking with someone very senior at Oracle the other day...." Yeah right, like anyone here believes you talk to anyone outside of IBM marketing.
".....They are intending to put accelerators in their Sparc chips to help various Oracle products perform better....." The hp-Oracle agreement is for software, so putting hardware features into SPARC that accelerate existing software is not in breach of the agreement. In essence, if you add cache to a CPU it is an "accellerator", and the existing SPARC designs need all the help they can get to try and close the performance gap with Itanium. You do understand the difference between software and hardware, right? Maybe you should get a real techie to explain it to you.
So, rather than answer my point, you simply name call again. Very mature.
Yes, to a point you're correct. Adding cache to a processor is a sort of accelerator. However, what the guy was referring to is specialist execution units and instructions for Oracle software. These would not be available anywhere else and never would be. It was how they are going to persuade people Oracle hardware is the place to go. Very closed shop, but not the first to do it. So, there will be features (as there are currently in Exadata, a point I notice you ignored) that will never be available on Itanium (or other platforms for that matter). So, do enough of this and whether support exists for Itanium or not, it isn't price competitive. There is absolutely no requirement for Oracle to introduce any new features (or old features not available in the Itanium version at the time of the judgement) into the software. It's quite common for companies to have different versions of software for different platforms with feature differences. Nobody has ever suggested that what comes in one must come in the other, not even this judge.
So, rather than cherry pick the points you would like to respond to, why not respond to them all, including the harder ones. It'll give your brain a work out.
P.S.
If I needed a real techie, I wouldn't be talking to you. I've written operating system code for over 20 years. Yeah, deep down stuff as well, right in the nucleus of MVS (or z/OS if you would prefer). I now do Unix stuff. None of this was for IBM, all for FTSE 100 companies.
".....as there are currently in Exadata....." There was no specialist "accelerators" in Exadata, it was originally built around bog-standard hp Proliants because hp designed the hardware for the stack for Oracle. You are again confusing hardware configuration of standard items such as flash with some "superspecial" fantasy hardware. This is not unusual amongst mainframers, they all seem to think that IBM use ground-up unicorn horn in their kit alone, and refuse to believe it is the same tech as the rest of the industry just assembled in a different way and with a different software stack. The sad bit is you accept the unicorn horn myth and pay out so much for mainframe because you don't know any better.
".....rather than cherry pick the points you would like to respond to...." The problem is you post so many laughable inaccuracies and so much male bovine manure I'd need a whole lifetime of doing nothing other than trying to correct the deficiencies in your knowledge! Sorry, you can't afford me, go get help elsewhere. Besides, my expertise does not extend to helping the self-deluded and educationally-deficient, I work in enterprise IT. It is very obvious you do not.
"There was no specialist "accelerators" in Exadata, it was originally built around bog-standard hp Proliants because hp designed the hardware for the stack for Oracle. You are again confusing hardware configuration of standard items such as flash with some "superspecial" fantasy hardware. This is not unusual amongst mainframers, they all seem to think that IBM use ground-up unicorn horn in their kit alone, and refuse to believe it is the same tech as the rest of the industry just assembled in a different way and with a different software stack. The sad bit is you accept the unicorn horn myth and pay out so much for mainframe because you don't know any better."
Again, missing the point. I never said there were specialist accelerators in Exadata. I said Exadata has certain 'functions' available nowhere else. If you bother to read the manuals on anything other than Integrity, you would know that 'Smart Flash Cache' and 'Hybrid Columnar Compression' are available only on the Exadata. Yes, it's not hardware assisted, but a function unique to one platform, somthing you said they couldn't do. To quote you, you said whatever features existed on another platform had to appear on Itanium and I've just proven you completely wrong.
Your other points. Just simple abuse again. You seem to think abusing people is a substitute for facts and logical argument...........
".....but a function unique to one platform, somthing you said they couldn't do....." It really is like dealing with the mentally-deficient! Does your mommie know you're using the Internet? Exadata is NOT an Itanium product, it is a bundle of Oracle software based on some applications that are available on Itanium, rolled up with some specific software, tuned for a specific hardware stack. It is not covered by the hp agreement as it is not a product offered by Oracle for any Itanium server, hp or otherwise (or for mainframe or AIX for that matter). You introduced it into the conversation because you wanted to pretend it affects this hp-Oracle software judgement when it is a completely different product line. Please go get a clue, maybe talk your boss into buying you one of your own, as you appear to be time-sharing what little intellect you have with a lot of other IBM trolls.
"It really is like dealing with the mentally-deficient! Does your mommie know you're using the Internet? Exadata is NOT an Itanium product, it is a bundle of Oracle software based on some applications that are available on Itanium, rolled up with some specific software, tuned for a specific hardware stack. It is not covered by the hp agreement as it is not a product offered by Oracle for any Itanium server, hp or otherwise (or for mainframe or AIX for that matter). You introduced it into the conversation because you wanted to pretend it affects this hp-Oracle software judgement when it is a completely different product line. Please go get a clue, maybe talk your boss into buying you one of your own, as you appear to be time-sharing what little intellect you have with a lot of other IBM trolls."
You really have trouble keeping a thead going in your mind. Please show me where I ever said it was based on Itanium, because I never have. The reason I mentioned it was because you insisted that all versions of say Oracle DB have to have the same functions etc.etc. and I said that wasn't true citing the Exadata only functions as an example. They are unique to the Exadata. Again, you simply insult when everyone following this thread can see you aren't even following the thread correctly.
I do hope Matt Bryant isn't your real name, as if you work in IT, you're pretty much unemployable by now. If it isn't, but there is someone in IT called Matt Byant, he'd better speak up now otherwise he'll be unfairly tarnished.
".....The reason I mentioned it was because you insisted that all versions of say Oracle DB have to have the same functions....." Exadata is an APPLIANCE you fool, not just a version of the Oracle DB! You mentioned it because you have no other argument worth a damn and know nothing other than mainframe. Seriously, give up, you're just making a complete idiot of yourself. We really need a "I pity the fool" icon for posters like you.
"Exadata is an APPLIANCE you fool, not just a version of the Oracle DB! You mentioned it because you have no other argument worth a damn and know nothing other than mainframe. Seriously, give up, you're just making a complete idiot of yourself. We really need a "I pity the fool" icon for posters like you."
I believe the phrase Oracle would use is 'engineered system', but then you'd know that if you spoke with them. Yes, they like to call it that, but it's really a bunch of x86 servers with a special version of Oracle DB. So, yet again, you're dodging my point with abuse because you have no answer.
"....I believe the phrase Oracle would use is 'engineered system', but then you'd know that if you spoke with them....." So now you want to argue whether Exadata is an appliance or not? You seriously are a few buns short of a bakery. Whatever, it looks like your life is really so trivial you would argue that water is not really wet, just overly damp. Just man up, admit you were wrong, the readers might think more of you for it. At this point it would be hard to see them thinking any less of you!
"So I'm sure HP will take that 500 million and pay that to Intel to produce Itaniums beyond the current 2017 date that current payout requires them too."
HP will take the payout, wash their hands of Itanium (probably HP-UX too), and buy some software company with the cash... or their own shares.
By the way, the latest release of the Intel Itanium 9500 processor is showing between 2.5 to3 times the performance of the previous generation (9300). I wonder if IBM';s Power release will show anything close to that level of performance?? IBM does make good products, but I am not sure that they can keep up to this level of performance gain.
finally getting to 8 cores / chip after everyone else is not something to brag about, but somehow people will be fooled into thinking 2.5X is actually more than a chip fab enhancement thanks to xeon.
so if a 4 core chip is lets say 400 units (100/core)
an 8 core ship is 2.5x that its 1000 units but only a 25% improvement per core.
IBM has been about 3x the performance of itanium cores and looks like HP is falling even further behind on the per core and also software license measure.
e99
Oh Alli, you know that IBM's daft performance claims simply don't reflect reality. They like to FUD about single-core performance, neatly hiding the fact that the only way they can achieve it is to switch off half the cores in the system (but still leave you paying Oracle licences for all the cores switched off), or even worse by switching off all the cores but one so they can use all the cache from all the cores (but still leaving you paying for ALL the licences). So what you are shrieking about is actually IBM being unable to perform at eight cores, meaning they are indeed last to the game. The truth is shown whenever IBM have to go to a shoot-out against Itanium, they hate it as it exposes their benchmark lies for exactly what they are. If that wasn't true then no-one would have bought anything but Power chips for the last twenty years, and since that very obviously didn't happen it simply shows how much marketing hogwash the whole 2.5x claim and all the other IBM performance claims are. The fact you still constantly repeat the same FUD long after it has been debunked is simply tragic, can't IBM afford to buy their cheerleaders some new FUD?
"Oh Alli, you know that IBM's daft performance claims simply don't reflect reality. They like to FUD about single-core performance, neatly hiding the fact that the only way they can achieve it is to switch off half the cores in the system (but still leave you paying Oracle licences for all the cores switched off), or even worse by switching off all the cores but one so they can use all the cache from all the cores (but still leaving you paying for ALL the licences). So what you are shrieking about is actually IBM being unable to perform at eight cores, meaning they are indeed last to the game. The truth is shown whenever IBM have to go to a shoot-out against Itanium, they hate it as it exposes their benchmark lies for exactly what they are. If that wasn't true then no-one would have bought anything but Power chips for the last twenty years, and since that very obviously didn't happen it simply shows how much marketing hogwash the whole 2.5x claim and all the other IBM performance claims are. The fact you still constantly repeat the same FUD long after it has been debunked is simply tragic, can't IBM afford to buy their cheerleaders some new FUD?"
So, now you're slagging off the ability to disable some cores for higher performance. Is that because Itanium can't do it? Maybe you'd like to slag off dynamically adjustable SMT? Is that because Itanium can't do it? If you look on TPC-C and SpecInt, you'll notice that it's IBM that always leads the field and normally gets way more done for the same number of cores. I also haven't noticed any of the benchmarks using only a single core per processor or even TurboCore mode (although I haven't looked in the last couple of months). People haven't brought anything but Power chips for the last 20 years for the same reason that Intel haven't got 100% market dominance using x86 or AMD or anyone else for that matter. Given your 'expert' opinion on Itanium, how come Itaniums haven't got 100% market dominance?
I checked on TPC-C the other day and haven't even found any new Itanium benchmarks listed. Don't know about SpecINT. So, who's running from the benchmark wars?
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
