The key is that aggregate performance numbers are easy enough to get, but the ability to actually put those capabilities to effective use is something else. Either the metric is too segmented to easily put to use (e.g. 2 TB of ram in 64 GB chunks, 1M IOPs consisting of chunks of 50k IOPs), or some bottleneck gets in the way (e.g. storage subsystem has great numbers but only accessible by inadequate HCAs. Now a lot of HPC workloads and things like Hadoop manage to effectively use segmented resources, but my point was those numbers are a bit more accessible without thinking in a mainframe context.
I've heard mainframes have high IO thoroughput, but what about their equivalent Cloud solutions and scalability especially?
Depends on the problem.
For a relatively naively constructed algorithm, IO will be measurably worse in any 'cloud' platform popular today, and severely worse than mainframe. However, if you understand how to make your application scale (assuming it theoretically can), you can *in aggregate* match mainframe IO benefit at a much lower acquisition cost (though depending on who you talk to the more fudge-friendly 'TCO' metric may or may not follow). The trick is for many applications, the perceived risk and cost to reach that understanding is higher than just continuing to go with the flow of an IBM mainframe. Of course, some moderately broad areas of problems are getting tooling to more easily do that sort of scaling without too much extra thought. On the other hand, some problem areas no one has constructed a 'proper' approach that would negate the need for mainframe-like architecture.
With respect to the word 'cloud', the overwhelming majority of 'clouds' covered in tech news are EC2 and EC2-workalikes where IO is not particularly optimized. There are also various companies championing a departmental server or two with a few virtual machines on it as a 'cloud', further diluting the message and usually having terrible IO characteristics even with overpriced storage architectures. On the other hand, there are some projects claiming 'cloud' that include arbitration of bare-metal execution that can reasonably compare with a 'boring' scale-out private x86 scale-out solution, but very few people care.
Because updating can be an unexpected burden on your system in terms of performance, because it may require the current application to be closed at a time that the user should get to pick, because an update has an unanticipated effect in an enterprise environment and the IT staff has to spot check it before deployment.
So I'd say that if using Gentoo or Fedora those are believable outcomes. I'd also say if doing 'major' updates to Ubuntu I believe it. If you are running strictly Debian stable, Ubuntu LTS, RHEL/CentOS, or SuSE Enterprise, I've never heard of that going on there. Given Microsoft's technology cycle, the 'enterprise' editions are more comparable in terms of how long they have to get it right. The every-six-month releases do not provide an ample opportunity to get it as polished as the much longer release cycles.
However, amongst Linux enthusiasts (which proportionally is a lot more of the Linux world than Windows) those releases are boring and there are always new and shiny toys that are beyond your reach if you stick to the 'stable' releases. Hence more users trend toward bleeding edge and grumble when the consequences of that bite them.
I use the boring distros in a ton of places and Fedora on my laptop. My laptop does all manner of unfortunate things to me that my actual important servers never do by virtue of my choices. I recognize that as a price I pay to work with the technology.
Here's the thing, the type of people who are satisfied just by "Dave said it has a cool bevel with brushed aluminium finish" are also the ones that advertising is most effective with.
If someone is going to do in-depth research, the ads similarly will have relatively little impact.
That's what it's for, and it works exceedingly well at doing that.
The problem is the attacks where it's useless are far more prevalent than the ones where it does any good.
It only does good if the attacker compromises near the server. This is relatively rare.
If the attack either comes as a IP layer MITM (attacker is providing a router to victim) or DNS poisoining, then *all* servers including OSCP are fair game.
The problem with the rant on soft-fail is it ultimately places the fault on OSCP and not on the *soft* aspect of failing and goes on to recommend a blacklist strategy without a whitelist strategy for security, which is pretty boneheaded in this context.
So I see the practical benefit, trying to reinstate the 'offline' nature so that CA hosting facilities do not become the bottleneck for various things. From a security perspective this seems bad...
CRL relies upon the CA knowing about all the certs that should be revoked. Notably, if someone managed to discretely get a CA's private key, and applies that advantage with any subtlty, then the certificate isn't even known to be issued by the CA, they can't revoke what they don't know about.
Compromising an architecture like OSCP is a little different. A compromise of a CA is necessarily much more blatant if you have to also compromise the OSCP service.
Really, the most practical answer is to go as much toward making a confirmed positive OSCP a requirement for 'secure', and fix the bad practice of 'server temporarily down' as good as 'it says things are ok'. Let market forces punish the CAs unable/unwilling to invest what is required for this to be valid. When you control the browser,it's a strange argument to say it's worthless because your own browser won't strictly enforce OSCP so you throw it out for a much-more-dangerous blacklist approach.
I will say in some of the larger userbases that distributed reputation system to double check the CA results makes sense. I just wouldn't want that to replace a CA situation, as it wouldn't scale to small sites well and there is a more clear mechanism to invalidate bad certificates with CA. Should require a true-positive OSCP and either no or good reputation information to be really secure.
I think a lot of people mistakenly believe ARM's success is because the instruction set is just better. AMD impleminting the ARM instruction set does not, by itself, suddenly make AMD more compelling.
The ARM architecture's licensing has allowed a larger variety of companies to get in the game with their own ideas around implementation. This has led to exceeding low prices compared to the levels the x86 solutions have been willing to go, energy optimized designs to target specifically the mobile device market moreso than Intel and AMD did, and perhaps the most concrete distinction between Intel/AMD efforts to date and the successful ARM bits, system on a chip oriented designs facilitating the previous two points.
Intel seems to have begun to accept the SoC reality with Medfield, though still not willing to price down to ARM level and still not integrating as much as leading ARM implementations, they are getting closer. If AMD could push a compelling ARM archictecture solution, they could probably leverage their license for the x86 instruction set and have an implementation centered around that.
I know many people disparage the x86 instruction set but 95% of them don't even understand the arguments around it. I don't think x86 instructions drive the cost and power to the extent some people presume, it's mostly more general engineering choices.
The problem being that people needing to use CCNA as an indicator of anything have no way of knowing if a candidate did it 'right'. Ideally you can interrogate with a proper skills assessment, but if you can do that then not having a CCNA is no big deal. If you use CCNA as a filter before interviewing, your probably more likely to filter out a good candidate than not.
I have been involved in interviews where we ask someone, so extrapolate a bit on area 'X', and they simply say "As on my resume I have " and then shut up, as if that should settle the question.
So we ask them to discuss a bit of technical detail, perhaps suggesting some focus areas in the discipline. More often than not, they incohereently rattle off pieces of random jargon in nonsensical strings that make no sense (something along the lines of "I VLAN the STP to route the LACP through VTP in order to process the CDP so that I can toggle the link"). The vendors have prostituted the certs out to the point of being completely meaningless.
I feel sorry for people hiring without real existing skill in house, unable to evaluate the skills directly and having nothing better than certifications to vouch for someone's abilitiy set.
It's also hilarious the way some company's have worked their policiies. At one job they had a policy that all IT must be MCSE or they will be fired. They scrambled to pay money to certify the people they knew to be good (though I happened to quit before going through with it). At my next job, I was fired when my new company was bought out by a company with the same policy and I still didn't have MCSE. It's of course particularly amusing since primarily my job responsibilty was Unix systems.
Why is it remotely interesting to use Hyper-V with Openstack even in theory? MS has their own tooling and if you don't want to use it, why would you want Hyper-V over the more spiritually similar Xen or KVM hypervisors? I've been in a few situations where people have mentioned this but aside from an academic concept of 'completeness', I haven't heard an explanation of the practical relevance of the combination instead of leaving the proprietary stacks to their own efforts.
Fedora is batshit insane on updates. Fedora is not RedHat. As much as Fedora people want to claim otherwise, Fedora really is the testing grounds for things before hitting RHEL. This is not necessarily that bad in some ways (first to get new features), but it does carry the burden of never knowing what today's updates are going to bring, even without a 'dist-upgrade' type operation.
Ubuntu has been afflicted by dist-upgrade unpleasantness, even if you go by their strongly guided one-release-at-a-time process. Most capable people get bit by it, figure it out after at most a google search, and forget about it, but they do happen.
Of course, with "smart" ammunition, the rifling would probably be redundant.
Probably not. As the summary points out, this guidance needs a bit of distance in order to acheive course correction. For short-range, not helpful and rifling is required, and even at long range without rifling the shot may hit something unexpected before the bullet can correct. You aren't just making sure it will hit the right place, you also are making sure it doesn't hit anything before then.
It's more like saying the exit signs on a highway guide you to the correct road, which is a perfectly sensible sort of statement. People talk about GPS guidance even though the GPS isn't actually moving the wheels of the car.
The argument that it isn't *necessarily* laser light required is close as you get, but laser guidance seems appropriate since laser light is the only practical light source to pair with this sort of technology.
RedHat can (mostly) handle an in-place upgrade. Sufficient numbers of RH users *cannot* when something 'weird' happens, therefore it is simpler for them to tell everyone to clean install since RH actually has to answer the phone and handhold all the users and can't tell them to go away when they lack the resources to sort it out on their own.
Debian can (mostly) handle an in-place upgrade. When a debian user can't figure out how to make it work again after dist-upgrade breaks it, well tough. Google and forum around, and no one *has* to deal with it, even though usually someone does. If debian were forced to hold the hands of some of the users I've seen, they'd stop talking about dist-upgrade too.
AIX is extermely conservative, moreso than *any* linux distro will ever get away with. Given the scope, conservative development, the expected customer skill level, and the resources behind it, of course they can achieve *both* commercial support *and* robustness of in-place upgrades.
Redhat for instance only has a few percent of the packaged apps of Debian.
To be fair, the 'core' RHEL packages are a bit more thoroughly tested than Debian's universe. There are also add-on repositories, though RHEL doesn't make it quite as trivial to add. An example of it not being so rosy on the debian side, the roundcube webmail package was (still is?) completely unusable as it calls out a php configuration that will not be implemented by the current php packages. An upstream update to roundcube was available to work with the newer php situation, but debian had packaged the newer php and older roundcube, making things *not* 'just work' and indeed forcing you to leave the.dpkg versions behind if you wanted it to work.
The package manager for Redhat is inferior.
I have no qualms about rpm compared to dpkg. With yum, I also have no qualms compared to apt. I will say rpm more elegantly coped with the i386/x86_64 mix than I saw.dpkg based distros achieve.
Upgrades are a non-event with Debian, Redhat recommends a clean install and migrate data for every upgrade.
You *can* upgrade RHEL in pretty much the same way. Just like debian, however, there are some awkward scenarios when you do it that way on occasion. For example, my php install was hosed on my last dist-upgrade. Some stale config files for a formerly external module (IIRC, sqlite) brought all php scripts to a halt. It wasn't difficult for most skilled admins to identify the issue and resolve, but it represents an unknown/unexpected delay and there are many Enterprise IT shops that would actually be stopped in their tracks until someone came and bailed them out.
Their business plan doesn't seem to involve extracting money from the actual users of the product by and large, but rather selling the users as a product. For example, Ubunutu ships (last I checked) with the ability to buy from Amazon MP3 trivially, conveniently with Canonical's referal id. I'm not sure the details, but I believe Google pays them some to be the default search engine. Their ambitious future plans seem to revolve around having an "Ubuntu media store", as well as convincing someone to buy into their platform for set-top/embedded tv usage. My gut reaction is to be skeptical, but then I realize the TV embedded platforms are highly fragmented and seemingly immature and I don't see them as particularly disadvantaged compared to Boxee or Roku in terms of a platform to build upon, though the latter have worked more logistics with commercial content providers.
Whatever the case, they do have a lot of mindshare in the linux server market. Mostly its among those who don't want to pay (or have a mix of support/no-support scnarios to balance) and find the RHEL/CentOS/SL/Fedora landscape to be a bit suboptimal. RedHat might need to stop pretending they are selling an OS and let people easily acquire it for no cost. As it stands if you never call support you actually have a nicer experience with CentOS than RHEL aside from lagging in release cycle.
SuSE's share in Europe still seems pretty strong, so they aren't out of the game just yet.
There is no way Apple is performing a full test on these apps. I would wager the intent is: -Avoiding 'confusion' from intent of app vendor conflicting with Apple intent (nice phrasing for keeping competitors down) -Having a way to prevent and respond to malware or otherwise disruptive technology that does more than just crash itself.
In all truthfulness, the 10-core Xeon's (Westmere architecture still) aren't Intel's shining star of FP performance. Intel's strength is in their 8-core Xeons (Sandy Bridge) that are only recently coming into the market (not lagging Interlagos much at all). HPC has rarely been about the expensive high-end Xeons (massively expensive and generally 'last-gen' compared to the middle-tier Xeons with the main historical benefit of getting you to 4 sockets in one 'system', which is largely a moot point in HPC which generally is fine if split into whatever socket count you want, and *mostly* optimizes for lowest cost per socket, though IO per socket and larger failure domains can play a significant role against high socket systems as well in these environments.
While I agree that Opteron is a suboptimal processor for this nowadays (now lagging Intel equivalent flops and memory), the feat of efficiently putting that scale of processors to productive work is still non-trivial. That's pretty much why Cray has been stuck with Opteron so long, they pinned all their efforts on hypertransport based technology while most competitors pinned it to more processor agnostic infiniband via pci express. They have reaped some benefits (a theoretically better IO architecture initially, now it's dubious; and it just sounds more impressive in some ways), but now they are firmly on the wrong side of the fence. It will be interesting to see what happens next, if they do a QPI effort or start hedging their bets on Infiniband like everyone else. That has historically been for most people marrying yourself to Mellanox instead of the processor vendor, but maybe Intel will inject some vitality into QLogic's lackluster IB implementation (QLogic though probably thought the same thing as they picked up the IB pieces of PathScale and Silverstorm, but maybe third time's a charm?)
Of course, if they are falling down on the job on the software side (filesystem wise) like a few people in this thread have suggested, that's far more dire than Intel v. AMD.
I don't see a lot of evidence one way or another, but if people are coming and *demanding* the N9, but not *demanding* any of their WP7 devices, more is wrong than sales commissions....
The N9 could not have been hamstrung much more than the way Nokia handled it. Anyone in the market for it knows up front that Nokia shot their MeeGo efforts in the head, all of Nokia's positive efforts are behind WP7 now, and yet people are claiming N9 is outperforming their WP7 and no one seems to be challenging that assertion. A device running a confirmed dead-end platform as far as you are concerned should never ever perform better than your flagship endeavors.
That isn't really an indictment of iOS. Any sufficiently popular platform attracts developers that make crappy applications. Fewer crashy WP7 applications by virtue of fewer applications in general. No matter what one may claim about one platform being better than another for making resiliant applications, all platforms with any degree of capability inevitably gives a likely path for developers to drive their software down the drain.
On my Android device, I know Netflix is crashy, but I don't fault HTC or Google for that. I do fault Google for Google Talk occasionally refusing to run (have to disable and re-enable background data to clear the fail state).
Slashdot Mirror
The key is that aggregate performance numbers are easy enough to get, but the ability to actually put those capabilities to effective use is something else. Either the metric is too segmented to easily put to use (e.g. 2 TB of ram in 64 GB chunks, 1M IOPs consisting of chunks of 50k IOPs), or some bottleneck gets in the way (e.g. storage subsystem has great numbers but only accessible by inadequate HCAs. Now a lot of HPC workloads and things like Hadoop manage to effectively use segmented resources, but my point was those numbers are a bit more accessible without thinking in a mainframe context.
I've heard mainframes have high IO thoroughput, but what about their equivalent Cloud solutions and scalability especially?
Depends on the problem.
For a relatively naively constructed algorithm, IO will be measurably worse in any 'cloud' platform popular today, and severely worse than mainframe. However, if you understand how to make your application scale (assuming it theoretically can), you can *in aggregate* match mainframe IO benefit at a much lower acquisition cost (though depending on who you talk to the more fudge-friendly 'TCO' metric may or may not follow). The trick is for many applications, the perceived risk and cost to reach that understanding is higher than just continuing to go with the flow of an IBM mainframe. Of course, some moderately broad areas of problems are getting tooling to more easily do that sort of scaling without too much extra thought. On the other hand, some problem areas no one has constructed a 'proper' approach that would negate the need for mainframe-like architecture.
With respect to the word 'cloud', the overwhelming majority of 'clouds' covered in tech news are EC2 and EC2-workalikes where IO is not particularly optimized. There are also various companies championing a departmental server or two with a few virtual machines on it as a 'cloud', further diluting the message and usually having terrible IO characteristics even with overpriced storage architectures. On the other hand, there are some projects claiming 'cloud' that include arbitration of bare-metal execution that can reasonably compare with a 'boring' scale-out private x86 scale-out solution, but very few people care.
Because updating can be an unexpected burden on your system in terms of performance, because it may require the current application to be closed at a time that the user should get to pick, because an update has an unanticipated effect in an enterprise environment and the IT staff has to spot check it before deployment.
So I'd say that if using Gentoo or Fedora those are believable outcomes. I'd also say if doing 'major' updates to Ubuntu I believe it. If you are running strictly Debian stable, Ubuntu LTS, RHEL/CentOS, or SuSE Enterprise, I've never heard of that going on there. Given Microsoft's technology cycle, the 'enterprise' editions are more comparable in terms of how long they have to get it right. The every-six-month releases do not provide an ample opportunity to get it as polished as the much longer release cycles.
However, amongst Linux enthusiasts (which proportionally is a lot more of the Linux world than Windows) those releases are boring and there are always new and shiny toys that are beyond your reach if you stick to the 'stable' releases. Hence more users trend toward bleeding edge and grumble when the consequences of that bite them.
I use the boring distros in a ton of places and Fedora on my laptop. My laptop does all manner of unfortunate things to me that my actual important servers never do by virtue of my choices. I recognize that as a price I pay to work with the technology.
Here's the thing, the type of people who are satisfied just by "Dave said it has a cool bevel with brushed aluminium finish" are also the ones that advertising is most effective with.
If someone is going to do in-depth research, the ads similarly will have relatively little impact.
That's what it's for, and it works exceedingly well at doing that.
The problem is the attacks where it's useless are far more prevalent than the ones where it does any good.
It only does good if the attacker compromises near the server. This is relatively rare.
If the attack either comes as a IP layer MITM (attacker is providing a router to victim) or DNS poisoining, then *all* servers including OSCP are fair game.
The problem with the rant on soft-fail is it ultimately places the fault on OSCP and not on the *soft* aspect of failing and goes on to recommend a blacklist strategy without a whitelist strategy for security, which is pretty boneheaded in this context.
So I see the practical benefit, trying to reinstate the 'offline' nature so that CA hosting facilities do not become the bottleneck for various things. From a security perspective this seems bad...
CRL relies upon the CA knowing about all the certs that should be revoked. Notably, if someone managed to discretely get a CA's private key, and applies that advantage with any subtlty, then the certificate isn't even known to be issued by the CA, they can't revoke what they don't know about.
Compromising an architecture like OSCP is a little different. A compromise of a CA is necessarily much more blatant if you have to also compromise the OSCP service.
Really, the most practical answer is to go as much toward making a confirmed positive OSCP a requirement for 'secure', and fix the bad practice of 'server temporarily down' as good as 'it says things are ok'. Let market forces punish the CAs unable/unwilling to invest what is required for this to be valid. When you control the browser,it's a strange argument to say it's worthless because your own browser won't strictly enforce OSCP so you throw it out for a much-more-dangerous blacklist approach.
I will say in some of the larger userbases that distributed reputation system to double check the CA results makes sense. I just wouldn't want that to replace a CA situation, as it wouldn't scale to small sites well and there is a more clear mechanism to invalidate bad certificates with CA. Should require a true-positive OSCP and either no or good reputation information to be really secure.
So the answer is the encrypted data is innocuous content and your *real* illicit data is the passphrase itself, brilliant!
Ok, licensing argument sounds interesting, if not blatantly anti-competitive.
I think a lot of people mistakenly believe ARM's success is because the instruction set is just better. AMD impleminting the ARM instruction set does not, by itself, suddenly make AMD more compelling.
The ARM architecture's licensing has allowed a larger variety of companies to get in the game with their own ideas around implementation. This has led to exceeding low prices compared to the levels the x86 solutions have been willing to go, energy optimized designs to target specifically the mobile device market moreso than Intel and AMD did, and perhaps the most concrete distinction between Intel/AMD efforts to date and the successful ARM bits, system on a chip oriented designs facilitating the previous two points.
Intel seems to have begun to accept the SoC reality with Medfield, though still not willing to price down to ARM level and still not integrating as much as leading ARM implementations, they are getting closer. If AMD could push a compelling ARM archictecture solution, they could probably leverage their license for the x86 instruction set and have an implementation centered around that.
I know many people disparage the x86 instruction set but 95% of them don't even understand the arguments around it. I don't think x86 instructions drive the cost and power to the extent some people presume, it's mostly more general engineering choices.
The problem being that people needing to use CCNA as an indicator of anything have no way of knowing if a candidate did it 'right'. Ideally you can interrogate with a proper skills assessment, but if you can do that then not having a CCNA is no big deal. If you use CCNA as a filter before interviewing, your probably more likely to filter out a good candidate than not.
I have been involved in interviews where we ask someone, so extrapolate a bit on area 'X', and they simply say "As on my resume I have " and then shut up, as if that should settle the question.
So we ask them to discuss a bit of technical detail, perhaps suggesting some focus areas in the discipline. More often than not, they incohereently rattle off pieces of random jargon in nonsensical strings that make no sense (something along the lines of "I VLAN the STP to route the LACP through VTP in order to process the CDP so that I can toggle the link"). The vendors have prostituted the certs out to the point of being completely meaningless.
I feel sorry for people hiring without real existing skill in house, unable to evaluate the skills directly and having nothing better than certifications to vouch for someone's abilitiy set.
It's also hilarious the way some company's have worked their policiies. At one job they had a policy that all IT must be MCSE or they will be fired. They scrambled to pay money to certify the people they knew to be good (though I happened to quit before going through with it). At my next job, I was fired when my new company was bought out by a company with the same policy and I still didn't have MCSE. It's of course particularly amusing since primarily my job responsibilty was Unix systems.
Why is it remotely interesting to use Hyper-V with Openstack even in theory? MS has their own tooling and if you don't want to use it, why would you want Hyper-V over the more spiritually similar Xen or KVM hypervisors? I've been in a few situations where people have mentioned this but aside from an academic concept of 'completeness', I haven't heard an explanation of the practical relevance of the combination instead of leaving the proprietary stacks to their own efforts.
Fedora is batshit insane on updates. Fedora is not RedHat. As much as Fedora people want to claim otherwise, Fedora really is the testing grounds for things before hitting RHEL. This is not necessarily that bad in some ways (first to get new features), but it does carry the burden of never knowing what today's updates are going to bring, even without a 'dist-upgrade' type operation.
Ubuntu has been afflicted by dist-upgrade unpleasantness, even if you go by their strongly guided one-release-at-a-time process. Most capable people get bit by it, figure it out after at most a google search, and forget about it, but they do happen.
Of course, with "smart" ammunition, the rifling would probably be redundant.
Probably not. As the summary points out, this guidance needs a bit of distance in order to acheive course correction. For short-range, not helpful and rifling is required, and even at long range without rifling the shot may hit something unexpected before the bullet can correct. You aren't just making sure it will hit the right place, you also are making sure it doesn't hit anything before then.
It's more like saying the exit signs on a highway guide you to the correct road, which is a perfectly sensible sort of statement. People talk about GPS guidance even though the GPS isn't actually moving the wheels of the car.
The argument that it isn't *necessarily* laser light required is close as you get, but laser guidance seems appropriate since laser light is the only practical light source to pair with this sort of technology.
RedHat can (mostly) handle an in-place upgrade. Sufficient numbers of RH users *cannot* when something 'weird' happens, therefore it is simpler for them to tell everyone to clean install since RH actually has to answer the phone and handhold all the users and can't tell them to go away when they lack the resources to sort it out on their own.
Debian can (mostly) handle an in-place upgrade. When a debian user can't figure out how to make it work again after dist-upgrade breaks it, well tough. Google and forum around, and no one *has* to deal with it, even though usually someone does. If debian were forced to hold the hands of some of the users I've seen, they'd stop talking about dist-upgrade too.
AIX is extermely conservative, moreso than *any* linux distro will ever get away with. Given the scope, conservative development, the expected customer skill level, and the resources behind it, of course they can achieve *both* commercial support *and* robustness of in-place upgrades.
Redhat for instance only has a few percent of the packaged apps of Debian.
To be fair, the 'core' RHEL packages are a bit more thoroughly tested than Debian's universe. There are also add-on repositories, though RHEL doesn't make it quite as trivial to add. An example of it not being so rosy on the debian side, the roundcube webmail package was (still is?) completely unusable as it calls out a php configuration that will not be implemented by the current php packages. An upstream update to roundcube was available to work with the newer php situation, but debian had packaged the newer php and older roundcube, making things *not* 'just work' and indeed forcing you to leave the .dpkg versions behind if you wanted it to work.
The package manager for Redhat is inferior.
I have no qualms about rpm compared to dpkg. With yum, I also have no qualms compared to apt. I will say rpm more elegantly coped with the i386/x86_64 mix than I saw .dpkg based distros achieve.
Upgrades are a non-event with Debian, Redhat recommends a clean install and migrate data for every upgrade.
You *can* upgrade RHEL in pretty much the same way. Just like debian, however, there are some awkward scenarios when you do it that way on occasion. For example, my php install was hosed on my last dist-upgrade. Some stale config files for a formerly external module (IIRC, sqlite) brought all php scripts to a halt. It wasn't difficult for most skilled admins to identify the issue and resolve, but it represents an unknown/unexpected delay and there are many Enterprise IT shops that would actually be stopped in their tracks until someone came and bailed them out.
Their business plan doesn't seem to involve extracting money from the actual users of the product by and large, but rather selling the users as a product. For example, Ubunutu ships (last I checked) with the ability to buy from Amazon MP3 trivially, conveniently with Canonical's referal id. I'm not sure the details, but I believe Google pays them some to be the default search engine. Their ambitious future plans seem to revolve around having an "Ubuntu media store", as well as convincing someone to buy into their platform for set-top/embedded tv usage. My gut reaction is to be skeptical, but then I realize the TV embedded platforms are highly fragmented and seemingly immature and I don't see them as particularly disadvantaged compared to Boxee or Roku in terms of a platform to build upon, though the latter have worked more logistics with commercial content providers.
Whatever the case, they do have a lot of mindshare in the linux server market. Mostly its among those who don't want to pay (or have a mix of support/no-support scnarios to balance) and find the RHEL/CentOS/SL/Fedora landscape to be a bit suboptimal. RedHat might need to stop pretending they are selling an OS and let people easily acquire it for no cost. As it stands if you never call support you actually have a nicer experience with CentOS than RHEL aside from lagging in release cycle.
SuSE's share in Europe still seems pretty strong, so they aren't out of the game just yet.
There is no way Apple is performing a full test on these apps. I would wager the intent is:
-Avoiding 'confusion' from intent of app vendor conflicting with Apple intent (nice phrasing for keeping competitors down)
-Having a way to prevent and respond to malware or otherwise disruptive technology that does more than just crash itself.
In all truthfulness, the 10-core Xeon's (Westmere architecture still) aren't Intel's shining star of FP performance. Intel's strength is in their 8-core Xeons (Sandy Bridge) that are only recently coming into the market (not lagging Interlagos much at all). HPC has rarely been about the expensive high-end Xeons (massively expensive and generally 'last-gen' compared to the middle-tier Xeons with the main historical benefit of getting you to 4 sockets in one 'system', which is largely a moot point in HPC which generally is fine if split into whatever socket count you want, and *mostly* optimizes for lowest cost per socket, though IO per socket and larger failure domains can play a significant role against high socket systems as well in these environments.
While I agree that Opteron is a suboptimal processor for this nowadays (now lagging Intel equivalent flops and memory), the feat of efficiently putting that scale of processors to productive work is still non-trivial. That's pretty much why Cray has been stuck with Opteron so long, they pinned all their efforts on hypertransport based technology while most competitors pinned it to more processor agnostic infiniband via pci express. They have reaped some benefits (a theoretically better IO architecture initially, now it's dubious; and it just sounds more impressive in some ways), but now they are firmly on the wrong side of the fence. It will be interesting to see what happens next, if they do a QPI effort or start hedging their bets on Infiniband like everyone else. That has historically been for most people marrying yourself to Mellanox instead of the processor vendor, but maybe Intel will inject some vitality into QLogic's lackluster IB implementation (QLogic though probably thought the same thing as they picked up the IB pieces of PathScale and Silverstorm, but maybe third time's a charm?)
Of course, if they are falling down on the job on the software side (filesystem wise) like a few people in this thread have suggested, that's far more dire than Intel v. AMD.
You can get an 64-bit Rpeak of about one teraflop out of about 4 of nVidia's top-end (C/M2070) GPGPU cards and 4 beefy Intel processors.
You quoted the 32-bit Rpeak, which is not particularly relevant to the discussion. GTX 580 64 bit Rpeak is about 168 Gigaflops.
I don't see a lot of evidence one way or another, but if people are coming and *demanding* the N9, but not *demanding* any of their WP7 devices, more is wrong than sales commissions....
The N9 could not have been hamstrung much more than the way Nokia handled it. Anyone in the market for it knows up front that Nokia shot their MeeGo efforts in the head, all of Nokia's positive efforts are behind WP7 now, and yet people are claiming N9 is outperforming their WP7 and no one seems to be challenging that assertion. A device running a confirmed dead-end platform as far as you are concerned should never ever perform better than your flagship endeavors.
iOS apps crash all the time.
That isn't really an indictment of iOS. Any sufficiently popular platform attracts developers that make crappy applications. Fewer crashy WP7 applications by virtue of fewer applications in general. No matter what one may claim about one platform being better than another for making resiliant applications, all platforms with any degree of capability inevitably gives a likely path for developers to drive their software down the drain.
On my Android device, I know Netflix is crashy, but I don't fault HTC or Google for that. I do fault Google for Google Talk occasionally refusing to run (have to disable and re-enable background data to clear the fail state).