Having used Puppet for several years, and Ansible for about 3, given the choice I'd chose Ansible over puppet every time. Much faster and easier to learn, write, deploy, update, maintain and scale. Puppet infrastructure when you scale up to thousands of systems over distributed DCs is a nightmare to get right. When your catalogues mysteriously decide to take several+ minutes to compile you'll lose lots of hair trying to figure out where in the sprawling spread of Load Balancers, Puppetmasters, CA Server(s), Puppet DB servers (and Postgres DB servers) the bottleneck is coming from. Or perhaps the ENC is having an issue pulling from your CMDB. Plus you'll stand no chance what so ever of keeping up with puppet releases. Upgrading the infrastructure and code is such a ball ache you'll always be behind. In fact every place I've seen so far ends up creating new duplicate Infrastructure for later versions and slowly migrating across. At my current place of employment we have THREE of these and haven't even got to Puppet 4 yet. And don't get me started on Certificate management headaches. Puppet consumes a stupid amount of man hours to keep running. Avoid !!
132 posts • joined 2 Jun 2007
Re: You can't fork Android
"I don't want any Google shite apps on the phone"
I have the opposite problem. I've a Samsung S6 Edge and they are constantly installing/updating Samsung versions of Google apps that I don't want and can't get rid of. Sick to death of it. Samsung make excellent hardware, but I won't buy them again because of this experience. That and the OS updates have dried up. I'm hanging on till October and am looking forward to a native Android experience on a Pixel 3.
Re: lowest common denominator
"It's still crapware mostly written for a mobile phone though. In the enterprise people generally want proper computers, not close to useless toys."
An ignorant comment from someone who's obviously never used one. But if you really have to have native apps then you won't have to wait long:
Besides, if your workflow isn't mostly browser based (+extensions) then you're still stuck in the 90's and I feel sorry for you.
Re: Ansible & Salt
Present circumstances are different to the past. That risk is well understood and has been tackled by the current team. We could re-write in puppet but why not look at what else is on offer? Alternative designs might suit us better. If the world followed your philosophy we'd all still be learning COBOL.
Ansible & Salt
We're a big puppet shop at the moment, but our code base has been badly managed for years, is bloated, old and in need of a complete overhaul. Before we embark on this and an upgrade to newer versions we decided to have a look at the competition: Chef, Ansible and Salt. Chef is no longer in the running, it doesn't offer any clear advantage over Puppet. Also feedback we've had from contacts in the know say that it encourages messy unreadable code, exactly what we want to avoid. We'll be trying out Ansible and Salt in the coming weeks to see how they stack up.
Re: 256 socket Xeon
I have never worked with IBM kit so had to quickly learn what this architecture looked like.
That's not SMP. Processors only have direct access to local memory and I/O within their own "Processor Book". The books are then linked together using an "SMP Fabric". SMP in this context is a creative marketing phrase. That design, if you ignore the proprietary language and marketing, looks just like NUMA.
You won't find 32 processor systems that are true SMP because true SMP doesn't scale to that many processors without hitting serious performance bottlenecks. Read the "basic concept" section in this wiki. It explains the problem NUMA was designed to solve very well.
Re: 256 socket Xeon
"...But Linux scaled awfully bad on 64 cpus...."
That used to be the case several years ago, but is not the case today. That's old FUD.
"...BTW, the SGI Altix and SU servers are clusters. They are using NUMA. And NUMA is regarded as a cluster. NUMA is the same thing as Cluster. Read here if you dont believe me:..."
No it's not. When the author of that article says "One can view NUMA as a tightly coupled form of cluster computing" he's making an analogy. He's not saying the two are the same. In a cluster, each system runs its own instance of an operating system and can boot / shutdown separately to the others. That's the litmus test.
Re: 256 socket Xeon
"...But earlier SPARC servers was also SMP, for instance the Sun M9000 with 64 cpus. So, yes, I know the difference between SMP and NUMA, I am talking about it, am I not?..."
Yes you're talking about it, but no I'm afraid you don't know the difference between SMP and NUMA. Lets drill a bit deeper into your example, the M9000.
Actually, we can start with the diagram on page 22 of the M5000, and the following sentence that says:
"SPARC Enterprise M8000 and M9000 servers feature multiple system boards that connect to a common crossbar."
If you have a design where sockets on a system board only have access to limited local memory, and must traverse an interconnect, like a crossbar, to access memory on another system board, then that is a NUMA, or NUMA derived design. It's most certainly not SMP. An SMP design is where all CPUs have equal access to to all memory. The problem with that is it doesn't scale well, hence the reason why NUMA was invented.
Re: 256 socket Xeon
It's not a cluster, it's a single system image (SSI) server. i.e. it is running just one copy of the Linux kernel. Read the overview properly.
You also need to learn the difference between NUMA and SMP. You won't find anything anywhere that's SMP at 32 sockets, they are all ( various flavours of ) NUMA. Current SMP designs hit a brick wall at 8 sockets and the M6 is no exception, as this article clearly states.
Re: my list
If you're going to learn puppet or chef then you should invest your time to learn ruby instead of python. It's mandatory anyway for chef, and puppet is written with it. Puppet templates can contain embedded ruby, and its also useful when writing your own (facter) facts. It's incredibly easy and quick to use for general purpose scripting tasks too.
I would agree with that assessment. If Asus had just used "Transformer" on its own they could have got away with this, as they could (rightly) argue that "transformer" is a verb - a doing word that describes an action or state. But "Transformer Prime" evokes a very different mental image. Hasbro have got every right to get pissed off about this.
I'm surprised too. I have one (3G) and get loads of use out of it. I check email, catch up on news (MobileRSS) and read books & PDFs on the way into work in the morning; use OmniFocus heavily during the work day to manage my projects and work load; and it's perfect for a bit of light browsing, catching up on FaceBook and the occasional game when I get a spare hour or so in the evenings (N.O.V.A, GroundEffect, Nanosaur 2, RiseOfGlory, etc). It's even handy for calming down my son when he gets a bit hyper .. he loves SoundTouch and AlphaBaby. It's size, weight, portability and (best of all) amazing battery life make it a must have item for me. My other computers hardly get a look in these days,
Agree with JimmyPage
Except that we went to Comet et al first to eyeball the products we were interested in and get their prices; then went home and researched online to compare specs and find the cheapest online places to buy from. We replaced our fridge, washing machine and added a tumble drier (with all Miele products) purchased online and saved over £500 from the street price. No problems and no complaints.
Comet are just too expensive now compared to buying from the Internet. They need to lower their costs and drive down their prices to tempt their customers back.
Actually, Compaq had already stated their intent to drop Alpha and move to Itanium prior to the HP buy out. At the point of sale Tru64 had already been successfully ported to Itanium and was running in the labs. HP could have used it, or portions of it. AdvFS, the cam scsi layer and TruCluster were all offered. In the end it came down to numbers. At the time there were ~600K Tru64 customers world wide .vs. 1.6M for HP-UX. Dropping the Veritas filesystem and cluster suite to foist something new and unknown on the HP-UX customer base was considered too risky. A customer poll indicated they didn't want it, and Veritas offered some sweeteners to make sure the decision went their way. So it had nothing to do with technology benefits/limitations; it was a business decision.
Re: Why buy Red Hat?
TPM regularly throws this suggestion around and I suspected he's just trolling. It's nonsense; completely undervalues what Red Hat is all about and would be a terrible move for Red Hat customers (like my employer). One of the reasons we dumped our proprietary unix systems and moved everything onto Red Hat was platform neutrality.
Mythical plan or not
It doesn't matter. Every time this story airs it plants or re-enforces doubt in Itanium's future. This will damage HP's Itanium business, and its customer list isn't that big in the first place. As you've pointed out previously Matt, HP gets more $$'s per Itanium sale than your average server, so even a small dent in their installed base is going to smart. After that, it's a rolling stone gathering moss.
It's all about the apps
I used to be involved in quite a few Itanium installations years ago. With the exception of one customer build, all the others either ran an Oracle product, or JBoss. HP-UX is no longer listed as a certified operating system for JBoss and now Oracle has pulled the plug. It doesn't matter what noises Intel and HP make at this point. I fail to see how they're going to generate enough customer interest in Itanium from this point to justify continued investment in the future. If I were a betting man I'd wager that Poulson will be the last hurrah for Itanium, and Kittson will never see the light of day. By 2015 the relentless pace of Xeon performance and RAS development will make Itanium look even less attractive.
Red Hat + HP = bad
HP buying Red Hat would be the death of Red Hat as we know it. Red Hat Linux thrives in part because, like Microsoft, it's a hardware vendor neutral platform. That's a big part of its appeal; an insurance policy against the machinations and/or failure of any one of the big hardware vendors. If it were owned by HP, IBM and Dell would cease certifying their hardware for Red Hat; sales would drop off and a significant slice of their subscription revenue would disappear along with it. No one who uses Red Hat - except for a few journalist rooting for the next story - want this to happen; certainly not Red Hat customers, employees and share holders. It would also send a very negative message to HP-UX customers and send ripples of confusion through HP's sales force, who've had it drilled into them to push HP-UX and Itanium over competing solutions at every opportunity.
--"That's our decision to go with CentOS justified. It works very well at the barginous price of free"--
Depends on what you're using it for. If you put critical systems into production with no support and down the line things go wrong, who are you going to turn to? The CentOS guys will doubtless offer free advise when they have a spare minute, but often problems require code changes to fix. Who's going to do that for you, in a timely manner, when your customers are taking their business elsewhere and your senior management are demanding a fix? Maybe you've never had to use a Red Hat hotfix kernel to get you out of a jam. I have, and in those circumstances they earn every penny they're paid.
CentOS is a fantastic resource, and is good for many use cases. But it's the wrong choice if your business depends on it. I don't think even the CentOS guys would argue with that.
I think you're right
Shuttleworth is no fool: he's already looking ahead to a future where desktop PCs are less and less relevant. Apple have announced they're doing a facelift on OS X for 10.7 next year to blend it with the iOS interface. Plus ex-Microsoft Chief Software Architect, Ray Ozzie, warned as he walked out the door that Microsoft need to close their eyes, think hard about what the post PC future is going to look like, and the kind of devices and interfaces their competitors will be using. Shuttleworth gets this, and is aiming to position Ubuntu so it's a class leader for the future. The GNOME Shell developers, for all the good work they're doing, are really just re-inventing the wheel instead of designing something that doesn't need wheels. Of cause many Gnome die-hards who just want a better wheel today will whine loudly about this. But it's Shuttleworth's job to have longer vision than that and to plan for where he thinks we'll need be 3-5 years from now. Even some people in the Fedora project have recently started talking about shifting focus away from the Desktop and more to building a platform that people can better use to build cloud and web apps with. The writing is on the wall people.
It's about time they did this. I've seen lots of places running Oracle DBs on Linux, and always on Red Hat. There has never been a really compelling reason not to. Now they're diffrenciating themselves from Red Hat while still leveraging the established skills base in Red Hat Linux technology. They might actually sell more OEL licenses and support now. It'll be interesting to revisit this in 12 months to see what difference its made, if any, and how Red Hat respond to it.
I like it
I used it for the first time last night on the train in an area where 3G reception is spotty and loading web pages is typically slow. It's very quick, easy to use and makes much better use of available bandwidth because it cuts out most of the HTML cruft. Back home, I found I can now see embedded video clips that I would not normally have access to due to lack of flash on iOS. So it gets a big thumbs up from me. I will be using this regularly from now on. Thanks Auntie!
Re: hp-ux on x64?
--"Wrong! There are a wealth of common applications for all three on Itanium, such as Oracle or SAP applications"--
Not as many proprietary vendor apps for RHEL on Itanium as HP-UX. Plus, most top vendor apps on RHEL x86 are Tier 1, that was never the same situation for RHEL IA64. There was just no incentive for vendors to invest in it. A classic chicken and egg situation.
--"I have benched solutions on Superdome using all three OS so that the board could see which offered the best performance and bang-for-the-buck with a particular app stack"--
Is that supposed to fill us with a sense of even handedness and fair competition? You are after all potentially the UKs biggest HP-UX fanboi ;)
--"So the idea that hp pushed out RH and MS on Itanium by just pushing hp-ux solutions misses the fact that hp weren't leading the sale on most deals, it was the resellers"--
I have a long history of mixing it with resellers, and my experience has _always_ been that when a reseller pitches an Itanium solution they _always_ pitch HP-UX unless the customer specifies otherwise. There is always more money in it for them, and you don't bite the hand that feeds you. You're being deliberately disingenuous Matt.
--"This is where hp-ux beat RHEL on Itanium - hp was simply able to fund more developers and thus gave us customers more app options at an earlier date"--
Ah, so at last you agree with me: that there was never a truly competitive market on IA64 between RHEL and HP-UX, because HP stacked the application deck in their favour by funding more development themselves. RH don't do this -- their pockets are not deep enough to spend money like that chasing proprietary apps on a platform where there are hardly any players representing their interests in front of the customer. HP had to because for their Unix business it was a matter of survival.
--"Webserving and fileserving, whch is not really an hp-ux on Itanium market"--
Rubbish. I know of several large $1M+ bids involving Telco, Biotech and Finance customers where proprietary Unix on proprietary hardware have lost out to RHEL x86. I only see a tiny fraction of what's going on out there, but there are lots of big business success stories for RH.
--"and if they decided there was money there for hp-ux on x64 then you can be sure they would be using hp's rep, marketing clout and cash to push hp-ux in a manner RH or Novell can't match."--
You forget two things. 1) RH don't have that hill to climb, they've already done it. hp-ux on x86 would have a competitor that is already in its prime. 2) Do you seriously think any amount of marketing money is going to make a proprietary unix with the licensing costs HP-UX is encumbered with competitive with RHEL? HP would have to completely rethink how they finance development and expect to retain a profit. Seriously, proprietary unix only makes business sense on proprietary hardware sold at proprietary prices to rich customers prepared to buy into the belief that they are getting something special. It cannot survive in the commodity system market. Sun tried and failed to make a profit despite having a bigger customer base than HP-UX and more ISVs in their pocket. HP-UX would do no better.
--"I agree in that hp really doesn't want to go head-to-head with Linux on x64 "--
So what are you arguing for then? ;)
--"As I've said before, the real crunch could be if UNIX goes 128-bit"--
There's no market or reason for that to happen in our working life time. The move from 32bit to 64bit was a no brainer as the 4GB limit is easy to hit. But there's a ton of leg room left in 64bit.
RE: HP-UX on x86
--"For a start, hp-ux has always been in direct competiton with Linux on Itanium"--
Correction: Red Hat was only ported to Itanium in the first place because like everyone else at the time Red Hat believed Intel's marketing message that Itanium was going to be the volume server chip in the 64bit space. Microsoft also believed this message and did the same. Neither Red Hat or Windows have ever been in real competition with HP-UX on Itanium for the simple reason that the majority of Itanium systems sales over the years come in proprietary packages to enterprise customers via proprietary vendors. The majority share of those sales come from HP, so by default are HP-UX solutions. The customer has to explicitly ask for something else (OpenVMS, Non-Stop, Windows, Red Hat) or (s)he gets HP-UX, and you know as well as I that most customers will take what HP recommends. So don't try and pretend there has ever been a competitive marketplace on Itanium, because we all know that's rubbish.
--"The problem for Macka here is that us customers chose hp-ux over Linux to such a degree that companies like Red Hat gave up and went back to x86/64"--
Correction: Red Hat gave up on Itanium because like Microsoft they made a sound business decision not to throw good money after bad and waste resources propping up an architecture that does not return a profit (for them). SGI was probably the only good reason for Red Hat to continue and when they abandoned Itanium and moved to an x86 roadmap what was the point? None.
--"And Macka has this strange idea that it hp-ux couldn't face Linux on x86 due to "a wealth of apps" - one of the reasons I had such a hard time getting management to look at Red Hat on Itanium was because hp-ux had a much better range of fully-supported applications"--
Nice try at obfuscation, but I'm not comparing Red Hat apps to HP-UX apps on Itanium, I'm talking about the x86 market. If HP-UX were ported to x86 its starting app portfolio would be zip, nada, nothing. I'm sure I don't have to tell you that none of its IA64 apps would run without a port and recompile, or perhaps a Transitive style emulation wrapper. What app vendor in their right mind is going to waste time and money on that unless HP paid them to do it. Solaris on x86 had a much better chance at cracking the x86 market and taking on Linux, but hasn't been a big success, and certainly hasn't slowed the Linux juggernaut one jot.
--"Moan about M$ all you like"--
Are you trying to put words in my mouth? I haven't moaned about MS or even mentioned them. They're the biggest player in the x86 game, what else is there to say.
--"If hp did port hp-ux to x64, their biggest opponent would be Windows, not Linux"--
Maybe. Some of the previously loyal HP-UX customers would use the opportunity of an architecture change to switch to MS, but look at the history of Linux: where has it gained most of its market share from? Some of is has been at the expense of MS, but it's been far more damaging to proprietary Unix. Either way, your point just re-enforces my point: whether its competition from MS or Linux, an HP-UX port to x86 will never be in HP's best interests for HP-UX or Itanium.
--"Whilst it's always good fun having a laugh at Macka's anti-hp FUD"--
Just to put you straight I'm not anti-HP, I really like their products and the company. I'm just a realist. I don't see any performance, cost or productivity advantage in choosing an HP-UX Itanium solution over Red Hat and x86. Quite the opposite in fact, as Red Hat on x86 is cheaper, faster and offers customers a larger choice of solutions. Plus if I were to bet which one has the best chance of still being actively developed in 5 years I know where I'd put my money.
HP-UX on x86
--"Pity HP-UX doesn't run on x64 iron, though"--
It's a good job it doesn't. Apart from tempting some of it's customer base off Itanium, which would be very bad for HP, that would bring it into direct competition with Linux and the BSDs where it would get eaten alive. Red Hat for example is already a far more capable o/s with a wealth of apps and vendor support that no proprietary unix can match today. And the gap is soon to get even wider with RHEL6. HP need HP-UX Itanium exclusivity to promote it's Itanium sales message.
Kubuntu is niche
Ubuntu is main stream, kubuntu is niche. Seems like an obvious and sensible choice to me. And it sounds to me like you've not looked at Gnome in some time. It used to be the case that KDE was streets ahead of Gnome years ago but that's not the case now. I switched and tried using KDE 4.3 for a whole month to give myself plenty of time to get to grips with it, but was glad to go back to Gnome at the end. It's just too buggy, I don't like the look and feel, and I hated using Amarok, kmail and Dolphin.
You need to take your blinkers off. Amarok is bloody awful. It has the worst playlist implementation I've ever seen; the way controls and options are layed out is very unintuitive, and it's design wastes lots of screen real estate. Kmail (like most things KDE) doesn't bother to differentiate between ordinary functions people use every day and advanced functions, and just packs its menus full of crap that would fill an 'ordinary' PC user with confusion and fear. It doesn't integrate all that well with gmail (a must for me) and mail account setup is way too complicated for a non-techie to grasp. If you want to see an MUA done right, take a look at Thunderbird. Setup is a breeze. For example just give it a gmail/yahoo/hotmail email address and it knows what needs to be done.
I like to use multi-column views for file management where it's available, and navigate around using the keypad more than the mouse. Implemented properly its a fast way to work. Dolphin is badly broken here and doesn't work the same as every other file manager I've ever used. It was just impossible for me to be productive with it. Nautilus just blows it out of the water.
So in summary, you can keep your KDE. If it works for you then I'm happy for you, and maybe The Reg authors will do an article for you one day. In the mean time this series is for the rest of us, and I look forward to the next one.
--"The Galaxy S is rated at 576 hours of 3G standby while the iPhone 4 is rated at 300 hours"--
This was said in the context of comparing the AMOLED screen on the Galaxy to the iPhone 4, but what has the standby time got to do with screen power consumption? Standby time is when the device is inactive, not being used, it has nothing at all to do with screen power efficiency. The only thing we can deduce from this statement is that the Galaxy will have a bigger battery than the iPhone, so it will probably be a bigger and heavier device. I'm sure Apple could build a bigger phone with a longer battery life if they wanted to, but they don't because they always look to balance form with function. Making a new phone thats 24% thinner than it's predecessor is something they're proud of.
The first thing to note is that this isn't a virus it's a Trojan; and you're right, any OS can get infected with one of these. The real story here is not that someone's written a nasty Trojan, but its method of delivery. If Intego are to be believed then Softpedia, MacUpdate, and VersionTracker are inserting malware into downloads of otherwise sane and safe software. So either they've been hacked, or they have become hives of scum and villainy who will sell your systems down the river for a silver penny or three from a dodgy sponsor. THAT is the real story. Not that Intego want you to think about that, they just want you to get frightened into buying their product.
Re: Upgrad path for 3.0?
Yes it does. You upgrade to FC 4, then 5, 6, etc until you get to the release you want. Or did you want to do that in one hit? Name me one operating system that allows you to upgrade 10 major versions in a single upgrade. No, how about 5 versions, or maybe 3? Still no? Well what does that tell you then!
It's your own stupid fault for letting your system fall so behind. Never ever let important systems that you rely on get that out of date again. An FC 3 build in this day and age must have more security holes than a Swiss cheese.
If you absolutely have to keep this, then how about using your head and going for a sensible solution. Your ancient FC 3 build that you left to languish must be running on very old hardware by now. I assume you're running something you just can't transplant onto a more modern build (can't imagine what). So do what everyone else does that need a modern supported OS and hardware platform: go virtual. Get a nice fast modern system and run your FC 3 build inside a VM.
Honestly I can't believe the number of ignorant twits and trolls that have crawled out from under their rocks to throw mud at this article.
Re: H.264's undeserved bad rep
--"We hoped that we were producing a standard that would be so good that it would kill off the proprietary codecs that were emerging at that time "--
Getting rid of the different proprietary codecs to consolidate around one was/is a laudable goal.
--"Perhaps the most strange thing for me is the notion that H.264 was the work of some exclusive and unholy alliance of the big companies"--
Why do you find that so strange? 300 experts from 100+ companies may have given their time and expertise, but who do you think owned the patents for the IP that got pooled to create MPEG-4 AVC? And did you really think they were just going to let go of that?
Competing for business
Canonical have a choice: do they want to compete head on with Microsoft and Apple, or be an "also ran". If they want Ubuntu to appeal to regular Microsoft and Apple users then they have to give them the same 'first class' web and multimedia experience that Microsoft and Apple do, out of the box. So really, being totally pragmatic about this, they have no other choice.
Red Hat silliness
--"And wouldn't it be far easier if HP just bought Red Hat and asked its HP-UX customers to make just one more port and compile, to RHEL running on x64 iron?"--
No no no no NO, get this silly notion out of your head. That would be a disaster for Red Hat: they need to stay vendor neutral in order to deploy on as wide a variety of vendor hardware as possible.
And anyway, why would HP spend billions buying Red Hat to get a distro of their own when they can copy what CentOS and Oracle have done? They can have their own HP branded Linux any time at a fraction of the cost and share the development going forward with Red Hat and Oracle.
--"Novell would be cheaper to acquire and still supports Itanium with its SLES Linux, and that would also do"--
No disrespect to the guys at Novell, but they have all the tools, IP and products to really make it in this business. If they can't make it work well given what they have then maybe they do need a change of management. I can't see HP going for them though as the bulk of their linux customers want Red Hat.
Nowt so gullible as folk
--"Bit unfair to imply that because he has his laptop nicked, that a department that in future he MAY be heading will continue to suffer serious data losses"--
Where have you been hiding recently? Don't you know an election is on and smear season has been declared open? Here's how it works. Take two unrelated facts; bend time and space to create an otherwise impossible link between the pair of them; then point a finger at your hapless victim and shout your slush from the top of the nearest roof top. Finally, stand back and watch the brainless lemmings suck it up like it was gospel. Job done.
You forgot one
I'm pretty sure you can add the announcement of the DL580 G7 to that list as well. That's the 4 socket Proliant with the Nehalem-EX chip. I can't absolutely confirm that, but I've heard a rumor through the grapevine. Also HP slipped slightly with their recent publication of the LSF V7.0.6 Overview document here:
It lists both the DL580 G7 and the DL980 G7 in the hardware support section. It would make sense for them to announce both the DL980 and the new DL580 at the same time. Not everyone is going to want a beast the size of a DL980.
RE: Umm ..
Stripping out all the ad homenim and dot to dot Disney Land logic from your argument, what you're basicly trying to sell is that because the unit price of an Itanium sale is higher than the rest (which I never disputed) then this "obviously" means (by magic) that these sales must be to more prestigious customers. What an ego. And that by association (or some dimension bending osmosis) the accompanying sales opportunities (storage, consultancy, etc) are bountiful rivers of flowing gold. And that these lucky customers, with bottomless money wells and orchards of lush fruiting money trees, are falling over themselves to buy the more expensive Itanium solutions because, well, it's Itanium. That's an interesting world you live on. Does your emperor wear any clothes? Meanwhile, where the rest of us live customers are more pragmatic, more discerning, and want the best value for their hard earned and (these days) scarce cash.
--"Whilst you're busy writhing, let's get to the fun bit - show me the money"-- and --"So your argument that IBM made massively more money than hp simply because IBM sold more units overall is likely to be very wrong due to IBM not making as much money on each server sold, either through margin at the time of purchase or pull-through during its lifetime. This is the prime reason Sun went steeply into decline whilst still shifting a high number of (low-end) units."--
What you percieve as wriggling is me dancing all over your arguments. Let me just point out the magnitude of your mathematical folly using your own numbers. If you make 38% more per sale than I do (and lets assume that's for everything) but I make 100% more sales than you (as per the article you quote) who comes out on top? Let's keep this simple and use 100 as a base line: 100+38=138 .vs. 100+100=200. Oh, dear. You also pointed out that you budget 5 x the purchase cost for the lifetime of the servers, so lets do a simple test there too: 138*5=690 .vs. 200*5=1000. Oh dear oh dear, you loose out again too.
--"hp Integrity has won that high-end despite the Itanium delays and despite the latest versions only being dual-core to Power's four-core offerings"--
Dude, Power 7 has 8 cores, not 4. I thought you would have known that. Well lets just wait and see how the benchmark results stack up when Tukwilla eventually makes it into some real systems.
--"If you forgot to read the figures in the Gratner article as reported here on the Reg (http://www.theregister.co.uk/2010/02/24/gartner_q4_2009_servers/), hp seem to be doing quite fine in the high-end. In fact, given the average server shipment value as discussed in the comments off the same article, hp are selling more top-end servers than IBM and much more than Soreacle"--
That's kind of bending the numbers to fit your world view isn't it. So HP are getting more value per Itanium server than IBM or Sun/Oracle are from theirs. That's good, but from the figures quoted IBM still made much more money from bare metal P7 sales than HP did from Itanium. Plus Sun/Oracle got nearly three time as much tin on the ground and IBM twice as much. I'd bet that when you factor in support contracts and consultancy fees, and peripheral kit sold along with all those deals, that HP get bumped into a distant 3rd place on total sale value.
You know you can sex this up as much as you like, but Itanium is not delivering what was promised for HP any more. That's not HP's fault, it's Intel's for letting their Itanium road map milestone slip and slip and slip. Remember that in 2005, when all Intel had were single-core Madison Itaniums, Intel was saying that Montecito would be out in 2005, Montvale would follow fast on its heels in 2006, and Tukwila would debut in 2007. As it turned out Montvale came out in 2007 and we've had to wait 3 fecking years for Tukwilla. If we have to wait another 3 years for Poulson to take Itanium to 8 cores, well what's the bloody point. It will be irrelevant by then.
bloat killing battery?
Maybe it's the bloat of running Windows 7 - an OS designed for something a lot bigger - that's the main reason for the Slate's poor battery life. iPhone OS may have its short comings, but it's designed to run on a small handheld and is optimized for those resources. People are reporting real world battery life tests on the iPad of up to 12 hours. Maybe HP would be better off putting the Windows Phone 7 on the Slate to get the most out of the hardware.
As for performance, I think Apple have sized the iPad A4 chip and Memory to be able to run iPhone OS apps so that it's visibly smooth and fast. So I agree with you: raw numbers don't mean anything here. It's the user's experience that counts.