The problem is not "centralized trust". The problem is a mix of x509 evolving but not mandating behavior (in the web context, CRL should be completely sunset and OSCP should be mandatory) and half-assing implementations today in the name of convenience (OSCP implementations are likely to ignore errors instead of failing validation, treating only an explicit 'invalid' as evidence of a problem. The root of the problem is a third party authority is used frequently without checking in with that authority. A system *more* distributed than x509 without changing any other characteristic would be trivial to suffer this sort of attack.
No 2-3 second waiting for a resume. A tablet's responsiveness is generally very snappy compared to the netbook.
By convention of Windows/Linux behavior, not due to form factor (incidentally, not without a tradeoff, those slow to resume devices get much more sleep life in them).
No 2-3 second waiting for a resume. A tablet's responsiveness is generally very snappy compared to the netbook.
Depends. I've never meant someone who thinks text entry is easier with screen vs. keyboard, the debate would be if it is *worth* it, which varies greatly with use case.
The form-factor is more convenient
This really really depends. Sure, if you are standing then the Tablet will be more convenient. If you are sitting,without some sort of prop stand you are having to support the weight with your hands while a laptop/notebook has a table or your lap holding the wieght flat and a hinge holding the screen at a suitable angle. Also, redundant with previous point, you can do text entry without blocking the screen or looking at your fingers.
Polishing touches such as smart covers.
While I don't think saving the user a power button press is no big deal, I do think the cover doubling as a propstand greatly mitigates the issue of discomfort on a table (though not lap).
Consumers (not the people on/.) generally care about what you can do with a product, and care less about specs.
True, *but* what you *can* do is significantly influenced by specs. All the ecosystem in the world won't make a tablet without expansion or GPS give you reasonable directions, and conversely a tablet with massive specs is useless without software to use them.
although wireless bluetooth keyboards help,
See, this is even *less* convenient to tote around and set up than a laptop.
Let's see, crappy resolution, crappy touch interface, 1 quarter of the memory of most contemporary android devices, ancient ARM core. That's just what can be derived from the spec sheet, viewing angle, build quality, all those likely to be subpar.
Not that I'm much into a tablet at all, but the difference between random cheapo tablet and something that a major brand is willing to embrace is (hopefully) night and day. That sometimes doesn't pan out with execs start blindly milking a brand value to sell crap, but at this point I don't think Amazon or Lenovo is there right now.
Their Android client is flaky as anything. PS3 client works ok (though their UI redesign is atrocious). When it does handle network traffic at all, it tends to handle it well (though I wish it could be configured to wait for better quality from the get go instead of starting crappy and then upping the quality). They have been afflicted by EC2 outages more than I would like.
Opportunity cost. Not *just* about exclusivity. If I can stream a movie from netflix witch confidence of continued availability, I'm never going to buy a disc copy. If netflix gives me everything I want for $8/month, I am not going to be feeding money into a cable company. Starz may have seen a significant decline in cable subscriber revenue more than the amount they considered likely to get from Netflix. Their choices are either change Netflix's behavior to mimic the cable revenue or make an effort to prop up the more profitable cable model they have going on and keep people from unsubscribing.
I say this not because I think it's just peachy keen, but watch for the reluctance of providers to impact Netflix more and more as well as any effort by Apple, Amazon, or anyone else to pull off all-you-can-eat ad-free streaming plans for third-party content.
The cry against cable providers is 'arggg, give me a la carte, I don't want to pay for all the crap'
But the prospect of that becoming a reality 'tiered pricing' is met with equal amounts of rage.
Yes, the obvious difference is in the former, cable overcharges by a ton and in the latter it means a price hike, but it seems amusing.
I presume it can't be as simple as "They were willing to pay $300 Million for continued access. Starz wanted them to use tiered pricing". Starz probably wouldn't accept $300 million and proposed tiered pricing as a recovery mechanism for netflix to afford whatever Starz wanted, or Starz was willing to assume the risk for the chance of that extra revenue topping $300 million.
OCSP forces the CA to know and remember all certificates it had issued, this way even if the private key was used to create a rogue subCA it won't be valid as OCSP won't give the "yes it's valid" response. The DigiNotary case shows this is a real problem, they don't know which or how many certificates have been created. With OCSP validation model they are useless.
So I'm a little naive on the underlying tech, but should OSCP, being a whitelist, require only that valid certs be remembered, and revoked/invalid certs could be forgetten? Or is it that DigiNotary didn't retain database info even for valid certs, which would be another damning indication of their general ineptitude as a CA?
But from what I've read, I'd consider that a failing of how OSCP is *implemented*, not how it is architected. First pass was returning 'tryLater' which looked innocuous enough and lo and behold it was treated as innocuous (I would think that should count as a validation error if implemented properly). Second time around it was shown that most browsers would even treat a 500 error as 'close enough'. In all these cases, the problem is not that OSCP is incapable, it's that the browsers erred on the side of convenience and made 'no news is good news' the policy. I'd anticipate DNSSEC errors to be treated similarly because its the mindset of the client developers and not the core technology that is the issue.
I have to retract a bit, OSCP actually does a fair amount to address the issue of revocation, it's just that it isn't universal. Someone will have to explain how DNSSEC would be fundamentally any better than x509 with ubiquitous OSCP.
How long until we collectively admit that centralized SSL certs are actually causing more problems than they solve?
A bit harsh, but the model has some issues due to obsolete objectives.
The SSH model works great
Only if you habitually visit the same place does it provide any significant reduction in risk, so if you see a product you want on an as-yet unvisited storefront, you have zero protection against MITM. Maybe they can't keep it up for days, but a single visit is sufficient to mess you up. If the server's key is compromised? You are pretty well screwed, as not fixing the problem *looks* more secure than if they fixed it (e.g. the big debacle when debian openssh botched the host keys and every box in the damn world had to regenerate keys). By itself, this is just self-signed certificates. It fixes none of the problems, it makes more.
In other words, just make self-signed certs less scary, and CA-signed certs more scary... Which would accurately reflect the actual level of security you're getting:
But that's just not the case, self-signed certs *shouldn't* be any less scary than at least some semblance of a CA with a diligent client pulling CRLs.
Only pop up the BIG SCARY WARNING when the cert changes, even if it's signed by the CA.
See, this discourages organizations from ever changing keys even if they think there is a *chance* they were compromised. If they realized a key was world-readable for a couple of days, in models that allow trusted key change they will change it as it isn't a terrible burden on the user and better safe than sorry. In this model, they'd conclude it is unlikely that a user got the key and assume the risk because to avoid subjecting users to scary message, inconveniencing them, and reducing their confidence in your ability to keep your credentials safe.
The problem with x509 is not with third party attestation with pre-trusted keys. The problem is the goal of operating completely detached from the authorities resulting in obscenely long validity of keys with a clumsy revocation model. DNSSEC at least addresses this by doing away with the assumption authorities must not be bothered and a public key is signed only so long as the DNS record wouldn't expire, and forces the client to talk to the authority every day (at a small incremental cost over existing DNS traffic). SSHFP records already can go in DNSSEC. If you replaced certificates with a pointer to a CA server that had to sign it every time, that would work too, but surprisingly DNS already solved the problems associated with this sort of data distribution at internet scale, so piggy-backing makes a lot of sense.
It's true that in DNSSEC, it is potentially a huge logistical nightmare if a party entitled to 'bless' public keys as yours is persistently compromised (basically, an unprecedented display of ongoing incompetence to always be open to hijack).
However, on the flip side, the relatively long lifetime of certificates incurs the nastiness of CRLs and some amount of faith that CRLs make it to the right place at the right time. If a DNSSEC authority is compromised and fixes it in an hour, all signs of the compromise evaporate in less than a day. If a CA is compromised, you could potentially have years of potential threats if a hapless client doesn't get a CRL update. That's the biggest problem with x509 at internet scale, long term risk to existing credentials because of the relatively outdated goal of avoiding frequent communication with an authority.
Well, assuming there *was* money to be made in airplane sales by a new brand *and* Ford was remotely tooled to produce airplanes, sure, Ford could try to make airplanes with maybe only a hint of investor punishment for spending money on a dubious endeavor. If Ford announced today they were discontinuing car production *right now* because they *think* that one day *in the future* they will be selling airplanes and achieving healthier financials that way instead, that would be batshit crazy, and what HP is talking about doing.
When IBM shed it's PC division, it was already a somewhat modest chunk of their revenue (less than 10% of their revenue), lost money three years in a row, and represented less than 5% of the PC market. There was some non-trivial impact to IBM's x86 server business, but generally speaking the PC division didn't give IBM good financials and the x86 server business learned to continue without PC division there.
Now let's look at HP. Their PSG represents a good third of their revenue. That division operates with a positive margin (though some feel 5% is insufficient, I think it's healthy enough, particularly compared with negative numbers at the time of the IBM sell). It also represents a very very strong share in the desktop/laptop space (even if people say that market is dead, I don't think it would be 'horse and buggy' dead, it's going to plateau and sit there at worst). Considering how much mindshare they have and how that influences server sales, and how much volume of equipment they push through PSG and what that means to procurement, this poses the significant risk of shooting their server hardware business in the head. The Apotheker leadership says the focus should be on software and services, and while the EDS acquisition has secured services as a strong chunk of services income, their software picture today comprises less than 3% of their total revenue (20% margin may sound nice, but when it's on one tenth the revenue that PSG pulls in, the raw numbers are pretty dismal). So immediately they ditch a third of their revenue, and de-emphasize another 2 thirds of their revenue (servers and printing), and declare an intent to bet the farm on the last third of their revenue.
There was a time when IBM looked more like HP, where hardware was king. When they first chased services and software, they did not ditch their hardware business to do so. They hedged their bets, continuing to take in revenue the way they knew how while growing their business in the ways that looked promising. Only *after* establishing a healthy software and services stream and reputation did they ditch PC division. HP on the other hand is already betting on success that hasn't been proven yet. There is a mindset that 'so long as you make software, you'll get more revenue', but as the person in the article says, not every company can be a successful software company and to assume so is irresponsible.
After a lot of time in the 'enterprise' space, I'm about convinced they have a requirement of 'software must be crappy' before they'll ever consider buying it. Show them a straightforward, robust piece of software that can be managed by one or two people and a massive mess of software that requires a matrix-managed team of operators from a few dozen departments... They'll go for the latter almost every time.
In the tech industry, there is a lot to see here of interest.
First, notably, a lot of the financial commentators are praising the dump of PSG because of the relatively weak ~5% margin. It is clear that a lot of the vocal members of that circle tear into the numbers piece by piece without consideration of how it relates to the whole. For example, dumping PSG means a lot of big contracts (like the NASA deal they were touting so heavily not so long ago) are going to be at high risk for cancellation. That means not only are they losing the PC piece of that pie, it means they are forfeiting some amount of server sales. The ability to sell all a company's IT needs from datacenter to desktop was actually a non-trivial advantage over IBM for a lot of procurement situations, this means they will forfeit that advantage going forward and lose server sales. There is also the reputation damage associated with companies that bet their business on the consistency of HP to potentially lose the bet. This last part will depend heavily upon how they handle existing contracts and make things right. Another consequence is on HP buying components. When you ship a whole lot of PCs, component vendors will be aggressive on margin and make it up in volume. If you are ordering only parts for servers, expect a hit to server base material cost due to lower purchase volumes. This applies to common components, but more critically distinct components sourced from the same suppliers even if they wouldn't fit in a laptop.
The whole palm acquisition handling demonstrated a complete lack of strategic direction, regardless of your opinion of WebOS. Either there was no market opportunity in the first place, meaning HP bet a couple billion based on poor marketing skills, Palm's team was a lost cause from the start, which HP should have figured out before the 1.2 billion dollar check, whatever capability was there was destroyed by HP mismanagement, or it would've worked but they canned it before even really trying. Of course, it's a combination of all of the above, but I do recall a mass exodus of nearly every single 'visionary' person who could take credit for the features about WebOS that garnered any praise, meaning HP either booted them out or at least failed to retain them, which reeks of mismanagement. Launching after the iPad2 at price parity with 0 mind share was absolutely insane.
Another thought I have is around their declared intent to move to software and services instead of PC industry. A lot of people describe this as IBM like, but IBM was *very* firmly entrenched in the software industry before they exited. HP is not nearly so robust in the software industry, and while they may be making moves in the name of getting there, they should be hedging their bets before betting those efforts will bear fruit. I do wonder if the Apotheker leadership is a bit biased from his SAP experience and assuming the answer to any company regardless of current positioning just just become a software development company. I wouldn't be surprised to see the guy handed CEO of McDonald's and tell them to shutter their fast food business and start coding.
In general, they lost 20% of their company value because 1 year ago, they said 'we want to be just like apple' and threw billions at the problem to say in only one year "we want to be nothing at all like apple". They've been showing more and more shortsightedness in their spending in the last couple of years, spending on the magnitude that demands long-term engagement and then changing their minds on short-term timescales.
Everything about this seems a bit dramatic, misguided and haphazard. I have no doubt they would forfeit such a contract at this point on a weakly supported whim. The buisness leadership clearly thinks hardware=bad, software/services/good, and so expect for HP hardware to get the shaft until finally killed off.
Cisco, Dell and IBM have a lot of reason to celebrate today, regardless of whether the server business is tied up in this.
They did drop 1.2 Billion on Palm and not more than a month after the first attempt at a product launch, they killed it dead. I can appreciate not throwing good money after bad, but it does show they are kinda directionless and could very well completely give up on hardware even 5 months after throwing money at something like that (and 3com for that matter).
That said, I would say HP laptops/desktops will go away, but I doubt they'll leave server business. This is fantastic news for Dell and IBM though. IBM couldn't compete on total contracts and so now HP will be on even ground with them, and now Dell is the only one willing to play the total stack... for now. I would, however, be very concerned if I was in the HP server division. They mentioned explicitly leaving the PC business to focus on services (EDS) and software, but didn't say anything on servers explicitly. They may stay in, but it sounds like perhaps it's not their priority. Apothker did come from the software side, so...
Only time that ever happens is when a FC adapter goes nuts on the SAN during POST. Unless you are doing boot from san, disable FC adapter boot rom/uefi driver.
Your math is off. As a disclaimer, taking the article provided numbers at face value is probably a bad idea (wayyyy to good to be true), but let's do that for a moment.
About 4*10^11grams, allegedly equivalent to about 3*10^15 *gallons* of gasoline.2007 saw about 142,349,298,000 of gasoline used (a bit higher than other years, but let's round up to 150 billion gallons for the sake of simplicity). In this case, that would be just shy of 20 thousand years at an average of 150 billion gallons a year.
If you ask me if a product I've worked on is 'secure', my immediate thought is 'what is your criteria?'. There are 'degrees' of secure and the line where someone says 'it's secure' shifts according to whose making the call. Some may say they 'secured' their unattended installer data because they base64 encoded the administrator password (looking at you, microsoft). They would argue they did enough to protect from over the shoulder (visual exposure only, with no opportunity to transcribe it to paper). The attacker couldn't remember the base64 string long enough to put it into a base64 decode. In theory they could have taken it a step farther (like kickstart and autoyast for example), and stored the NTLMv2 hash in the file instead of password. More would say 'secure', but then some would say 'NTLMv2 hashes are trivially broken by rainbow table, so it's not appreciably better'. Let's say they even went so far as to redo their local account store to use something as well salted as modern/etc/shadow entries. Some would still say it's insecure because even with the cipher text pretty well protected against practical rainbow tables, GPUs can crunch through the problem space too quickly.
Then when faced with the continuum between 'wide open' and 'uselessly secure', there are tradeoffs. For example, ssh keys are widely used for convenience (and frequently can be fairly considered 'more' secure). When used for convenience, they are often stored without a passphrase. This means some will say it's less secure because they fear an offline attack or other attack that compromises the key. So you slap a passphrase on and have to type it everytime. You are back to the same level of inconvenience of password every time. ssh-agent mitigates this and things like gnome-keyring mitigate it further, but I'm sure some would call the 'attack surface' larger and therefore less secure somehow.
Some tasks can be rendered impossible by 'perfect' security. Like auto-deploy of new equipment being enabled by well-known default credentials being very convenient, but we all know how 'default credentials' can be considered very very bad if a piece of equipment is popular and installers are lazy.
Okay, but statistical analysis like that isn't particularly computationally-intensive.
You might as well decrypt the data on the client device and calculate it there. Even javascript execution of the associated arithmetic on a 3-year old iphone is going to be sufficient for the given use cases. The volume of data to transfer all the data versus just the results could be interesting in some problems, but in general I just think the horrible inefficiency and inherent limitations make this an academic-only exercise at this point.
Android devices "just work" if you pretend it is as locked down as an iPhone and don't go exploring possibilities that you wouldn't have had anyway. In so many cases something that has sensible defaults but lot's of power under the hood if you want it is decried as 'too complicated' even though without popping the hood you can't even tell the difference.
Slashdot Mirror
The problem is not "centralized trust". The problem is a mix of x509 evolving but not mandating behavior (in the web context, CRL should be completely sunset and OSCP should be mandatory) and half-assing implementations today in the name of convenience (OSCP implementations are likely to ignore errors instead of failing validation, treating only an explicit 'invalid' as evidence of a problem. The root of the problem is a third party authority is used frequently without checking in with that authority. A system *more* distributed than x509 without changing any other characteristic would be trivial to suffer this sort of attack.
No 2-3 second waiting for a resume. A tablet's responsiveness is generally very snappy compared to the netbook.
By convention of Windows/Linux behavior, not due to form factor (incidentally, not without a tradeoff, those slow to resume devices get much more sleep life in them).
No 2-3 second waiting for a resume. A tablet's responsiveness is generally very snappy compared to the netbook.
Depends. I've never meant someone who thinks text entry is easier with screen vs. keyboard, the debate would be if it is *worth* it, which varies greatly with use case.
The form-factor is more convenient
This really really depends. Sure, if you are standing then the Tablet will be more convenient. If you are sitting,without some sort of prop stand you are having to support the weight with your hands while a laptop/notebook has a table or your lap holding the wieght flat and a hinge holding the screen at a suitable angle. Also, redundant with previous point, you can do text entry without blocking the screen or looking at your fingers.
Polishing touches such as smart covers.
While I don't think saving the user a power button press is no big deal, I do think the cover doubling as a propstand greatly mitigates the issue of discomfort on a table (though not lap).
Consumers (not the people on /.) generally care about what you can do with a product, and care less about specs.
True, *but* what you *can* do is significantly influenced by specs. All the ecosystem in the world won't make a tablet without expansion or GPS give you reasonable directions, and conversely a tablet with massive specs is useless without software to use them.
although wireless bluetooth keyboards help,
See, this is even *less* convenient to tote around and set up than a laptop.
Let's see, crappy resolution, crappy touch interface, 1 quarter of the memory of most contemporary android devices, ancient ARM core. That's just what can be derived from the spec sheet, viewing angle, build quality, all those likely to be subpar.
Not that I'm much into a tablet at all, but the difference between random cheapo tablet and something that a major brand is willing to embrace is (hopefully) night and day. That sometimes doesn't pan out with execs start blindly milking a brand value to sell crap, but at this point I don't think Amazon or Lenovo is there right now.
Their Android client is flaky as anything. PS3 client works ok (though their UI redesign is atrocious). When it does handle network traffic at all, it tends to handle it well (though I wish it could be configured to wait for better quality from the get go instead of starting crappy and then upping the quality). They have been afflicted by EC2 outages more than I would like.
No one is losing money on Netflix.
Opportunity cost. Not *just* about exclusivity. If I can stream a movie from netflix witch confidence of continued availability, I'm never going to buy a disc copy. If netflix gives me everything I want for $8/month, I am not going to be feeding money into a cable company. Starz may have seen a significant decline in cable subscriber revenue more than the amount they considered likely to get from Netflix. Their choices are either change Netflix's behavior to mimic the cable revenue or make an effort to prop up the more profitable cable model they have going on and keep people from unsubscribing.
I say this not because I think it's just peachy keen, but watch for the reluctance of providers to impact Netflix more and more as well as any effort by Apple, Amazon, or anyone else to pull off all-you-can-eat ad-free streaming plans for third-party content.
The cry against cable providers is 'arggg, give me a la carte, I don't want to pay for all the crap'
But the prospect of that becoming a reality 'tiered pricing' is met with equal amounts of rage.
Yes, the obvious difference is in the former, cable overcharges by a ton and in the latter it means a price hike, but it seems amusing.
I presume it can't be as simple as "They were willing to pay $300 Million for continued access. Starz wanted them to use tiered pricing". Starz probably wouldn't accept $300 million and proposed tiered pricing as a recovery mechanism for netflix to afford whatever Starz wanted, or Starz was willing to assume the risk for the chance of that extra revenue topping $300 million.
OCSP forces the CA to know and remember all certificates it had issued, this way even if the private key was used to create a rogue subCA it won't be valid as OCSP won't give the "yes it's valid" response. The DigiNotary case shows this is a real problem, they don't know which or how many certificates have been created. With OCSP validation model they are useless.
So I'm a little naive on the underlying tech, but should OSCP, being a whitelist, require only that valid certs be remembered, and revoked/invalid certs could be forgetten? Or is it that DigiNotary didn't retain database info even for valid certs, which would be another damning indication of their general ineptitude as a CA?
But from what I've read, I'd consider that a failing of how OSCP is *implemented*, not how it is architected. First pass was returning 'tryLater' which looked innocuous enough and lo and behold it was treated as innocuous (I would think that should count as a validation error if implemented properly). Second time around it was shown that most browsers would even treat a 500 error as 'close enough'. In all these cases, the problem is not that OSCP is incapable, it's that the browsers erred on the side of convenience and made 'no news is good news' the policy. I'd anticipate DNSSEC errors to be treated similarly because its the mindset of the client developers and not the core technology that is the issue.
I have to add that OSCP really does a lot to address the x509 issues...
I have to retract a bit, OSCP actually does a fair amount to address the issue of revocation, it's just that it isn't universal. Someone will have to explain how DNSSEC would be fundamentally any better than x509 with ubiquitous OSCP.
How long until we collectively admit that centralized SSL certs are actually causing more problems than they solve?
A bit harsh, but the model has some issues due to obsolete objectives.
The SSH model works great
Only if you habitually visit the same place does it provide any significant reduction in risk, so if you see a product you want on an as-yet unvisited storefront, you have zero protection against MITM. Maybe they can't keep it up for days, but a single visit is sufficient to mess you up. If the server's key is compromised? You are pretty well screwed, as not fixing the problem *looks* more secure than if they fixed it (e.g. the big debacle when debian openssh botched the host keys and every box in the damn world had to regenerate keys). By itself, this is just self-signed certificates. It fixes none of the problems, it makes more.
In other words, just make self-signed certs less scary, and CA-signed certs more scary... Which would accurately reflect the actual level of security you're getting:
But that's just not the case, self-signed certs *shouldn't* be any less scary than at least some semblance of a CA with a diligent client pulling CRLs.
Only pop up the BIG SCARY WARNING when the cert changes, even if it's signed by the CA.
See, this discourages organizations from ever changing keys even if they think there is a *chance* they were compromised. If they realized a key was world-readable for a couple of days, in models that allow trusted key change they will change it as it isn't a terrible burden on the user and better safe than sorry. In this model, they'd conclude it is unlikely that a user got the key and assume the risk because to avoid subjecting users to scary message, inconveniencing them, and reducing their confidence in your ability to keep your credentials safe.
The problem with x509 is not with third party attestation with pre-trusted keys. The problem is the goal of operating completely detached from the authorities resulting in obscenely long validity of keys with a clumsy revocation model. DNSSEC at least addresses this by doing away with the assumption authorities must not be bothered and a public key is signed only so long as the DNS record wouldn't expire, and forces the client to talk to the authority every day (at a small incremental cost over existing DNS traffic). SSHFP records already can go in DNSSEC. If you replaced certificates with a pointer to a CA server that had to sign it every time, that would work too, but surprisingly DNS already solved the problems associated with this sort of data distribution at internet scale, so piggy-backing makes a lot of sense.
It's true that in DNSSEC, it is potentially a huge logistical nightmare if a party entitled to 'bless' public keys as yours is persistently compromised (basically, an unprecedented display of ongoing incompetence to always be open to hijack).
However, on the flip side, the relatively long lifetime of certificates incurs the nastiness of CRLs and some amount of faith that CRLs make it to the right place at the right time. If a DNSSEC authority is compromised and fixes it in an hour, all signs of the compromise evaporate in less than a day. If a CA is compromised, you could potentially have years of potential threats if a hapless client doesn't get a CRL update. That's the biggest problem with x509 at internet scale, long term risk to existing credentials because of the relatively outdated goal of avoiding frequent communication with an authority.
Well, assuming there *was* money to be made in airplane sales by a new brand *and* Ford was remotely tooled to produce airplanes, sure, Ford could try to make airplanes with maybe only a hint of investor punishment for spending money on a dubious endeavor. If Ford announced today they were discontinuing car production *right now* because they *think* that one day *in the future* they will be selling airplanes and achieving healthier financials that way instead, that would be batshit crazy, and what HP is talking about doing.
When IBM shed it's PC division, it was already a somewhat modest chunk of their revenue (less than 10% of their revenue), lost money three years in a row, and represented less than 5% of the PC market. There was some non-trivial impact to IBM's x86 server business, but generally speaking the PC division didn't give IBM good financials and the x86 server business learned to continue without PC division there.
Now let's look at HP. Their PSG represents a good third of their revenue. That division operates with a positive margin (though some feel 5% is insufficient, I think it's healthy enough, particularly compared with negative numbers at the time of the IBM sell). It also represents a very very strong share in the desktop/laptop space (even if people say that market is dead, I don't think it would be 'horse and buggy' dead, it's going to plateau and sit there at worst). Considering how much mindshare they have and how that influences server sales, and how much volume of equipment they push through PSG and what that means to procurement, this poses the significant risk of shooting their server hardware business in the head. The Apotheker leadership says the focus should be on software and services, and while the EDS acquisition has secured services as a strong chunk of services income, their software picture today comprises less than 3% of their total revenue (20% margin may sound nice, but when it's on one tenth the revenue that PSG pulls in, the raw numbers are pretty dismal). So immediately they ditch a third of their revenue, and de-emphasize another 2 thirds of their revenue (servers and printing), and declare an intent to bet the farm on the last third of their revenue.
There was a time when IBM looked more like HP, where hardware was king. When they first chased services and software, they did not ditch their hardware business to do so. They hedged their bets, continuing to take in revenue the way they knew how while growing their business in the ways that looked promising. Only *after* establishing a healthy software and services stream and reputation did they ditch PC division. HP on the other hand is already betting on success that hasn't been proven yet. There is a mindset that 'so long as you make software, you'll get more revenue', but as the person in the article says, not every company can be a successful software company and to assume so is irresponsible.
After a lot of time in the 'enterprise' space, I'm about convinced they have a requirement of 'software must be crappy' before they'll ever consider buying it. Show them a straightforward, robust piece of software that can be managed by one or two people and a massive mess of software that requires a matrix-managed team of operators from a few dozen departments... They'll go for the latter almost every time.
IBM and Cisco are still very much there in the x86 server space. So is HP for that matter.
In the tech industry, there is a lot to see here of interest.
First, notably, a lot of the financial commentators are praising the dump of PSG because of the relatively weak ~5% margin. It is clear that a lot of the vocal members of that circle tear into the numbers piece by piece without consideration of how it relates to the whole. For example, dumping PSG means a lot of big contracts (like the NASA deal they were touting so heavily not so long ago) are going to be at high risk for cancellation. That means not only are they losing the PC piece of that pie, it means they are forfeiting some amount of server sales. The ability to sell all a company's IT needs from datacenter to desktop was actually a non-trivial advantage over IBM for a lot of procurement situations, this means they will forfeit that advantage going forward and lose server sales. There is also the reputation damage associated with companies that bet their business on the consistency of HP to potentially lose the bet. This last part will depend heavily upon how they handle existing contracts and make things right. Another consequence is on HP buying components. When you ship a whole lot of PCs, component vendors will be aggressive on margin and make it up in volume. If you are ordering only parts for servers, expect a hit to server base material cost due to lower purchase volumes. This applies to common components, but more critically distinct components sourced from the same suppliers even if they wouldn't fit in a laptop.
The whole palm acquisition handling demonstrated a complete lack of strategic direction, regardless of your opinion of WebOS. Either there was no market opportunity in the first place, meaning HP bet a couple billion based on poor marketing skills, Palm's team was a lost cause from the start, which HP should have figured out before the 1.2 billion dollar check, whatever capability was there was destroyed by HP mismanagement, or it would've worked but they canned it before even really trying. Of course, it's a combination of all of the above, but I do recall a mass exodus of nearly every single 'visionary' person who could take credit for the features about WebOS that garnered any praise, meaning HP either booted them out or at least failed to retain them, which reeks of mismanagement. Launching after the iPad2 at price parity with 0 mind share was absolutely insane.
Another thought I have is around their declared intent to move to software and services instead of PC industry. A lot of people describe this as IBM like, but IBM was *very* firmly entrenched in the software industry before they exited. HP is not nearly so robust in the software industry, and while they may be making moves in the name of getting there, they should be hedging their bets before betting those efforts will bear fruit. I do wonder if the Apotheker leadership is a bit biased from his SAP experience and assuming the answer to any company regardless of current positioning just just become a software development company. I wouldn't be surprised to see the guy handed CEO of McDonald's and tell them to shutter their fast food business and start coding.
In general, they lost 20% of their company value because 1 year ago, they said 'we want to be just like apple' and threw billions at the problem to say in only one year "we want to be nothing at all like apple". They've been showing more and more shortsightedness in their spending in the last couple of years, spending on the magnitude that demands long-term engagement and then changing their minds on short-term timescales.
As someone subjected to a server that was entirely Intel's design, I agree 1000% percent.
Everything about this seems a bit dramatic, misguided and haphazard. I have no doubt they would forfeit such a contract at this point on a weakly supported whim. The buisness leadership clearly thinks hardware=bad, software/services/good, and so expect for HP hardware to get the shaft until finally killed off.
Cisco, Dell and IBM have a lot of reason to celebrate today, regardless of whether the server business is tied up in this.
They did drop 1.2 Billion on Palm and not more than a month after the first attempt at a product launch, they killed it dead. I can appreciate not throwing good money after bad, but it does show they are kinda directionless and could very well completely give up on hardware even 5 months after throwing money at something like that (and 3com for that matter).
That said, I would say HP laptops/desktops will go away, but I doubt they'll leave server business. This is fantastic news for Dell and IBM though. IBM couldn't compete on total contracts and so now HP will be on even ground with them, and now Dell is the only one willing to play the total stack... for now. I would, however, be very concerned if I was in the HP server division. They mentioned explicitly leaving the PC business to focus on services (EDS) and software, but didn't say anything on servers explicitly. They may stay in, but it sounds like perhaps it's not their priority. Apothker did come from the software side, so...
Only time that ever happens is when a FC adapter goes nuts on the SAN during POST. Unless you are doing boot from san, disable FC adapter boot rom/uefi driver.
Your math is off. As a disclaimer, taking the article provided numbers at face value is probably a bad idea (wayyyy to good to be true), but let's do that for a moment.
About 4*10^11grams, allegedly equivalent to about 3*10^15 *gallons* of gasoline.2007 saw about 142,349,298,000 of gasoline used (a bit higher than other years, but let's round up to 150 billion gallons for the sake of simplicity). In this case, that would be just shy of 20 thousand years at an average of 150 billion gallons a year.
If you ask me if a product I've worked on is 'secure', my immediate thought is 'what is your criteria?'. There are 'degrees' of secure and the line where someone says 'it's secure' shifts according to whose making the call. Some may say they 'secured' their unattended installer data because they base64 encoded the administrator password (looking at you, microsoft). They would argue they did enough to protect from over the shoulder (visual exposure only, with no opportunity to transcribe it to paper). The attacker couldn't remember the base64 string long enough to put it into a base64 decode. In theory they could have taken it a step farther (like kickstart and autoyast for example), and stored the NTLMv2 hash in the file instead of password. More would say 'secure', but then some would say 'NTLMv2 hashes are trivially broken by rainbow table, so it's not appreciably better'. Let's say they even went so far as to redo their local account store to use something as well salted as modern /etc/shadow entries. Some would still say it's insecure because even with the cipher text pretty well protected against practical rainbow tables, GPUs can crunch through the problem space too quickly.
Then when faced with the continuum between 'wide open' and 'uselessly secure', there are tradeoffs. For example, ssh keys are widely used for convenience (and frequently can be fairly considered 'more' secure). When used for convenience, they are often stored without a passphrase. This means some will say it's less secure because they fear an offline attack or other attack that compromises the key. So you slap a passphrase on and have to type it everytime. You are back to the same level of inconvenience of password every time. ssh-agent mitigates this and things like gnome-keyring mitigate it further, but I'm sure some would call the 'attack surface' larger and therefore less secure somehow.
Some tasks can be rendered impossible by 'perfect' security. Like auto-deploy of new equipment being enabled by well-known default credentials being very convenient, but we all know how 'default credentials' can be considered very very bad if a piece of equipment is popular and installers are lazy.
This brings us back to:
Okay, but statistical analysis like that isn't particularly computationally-intensive.
You might as well decrypt the data on the client device and calculate it there. Even javascript execution of the associated arithmetic on a 3-year old iphone is going to be sufficient for the given use cases. The volume of data to transfer all the data versus just the results could be interesting in some problems, but in general I just think the horrible inefficiency and inherent limitations make this an academic-only exercise at this point.
Android devices "just work" if you pretend it is as locked down as an iPhone and don't go exploring possibilities that you wouldn't have had anyway. In so many cases something that has sensible defaults but lot's of power under the hood if you want it is decried as 'too complicated' even though without popping the hood you can't even tell the difference.