Depends on if you consider Hedge Funds and High-Frequency Trading firms that makes 200% profit margins "Enterprises" or not. I mean really, what positive thing are they doing for the economy? Maybe Ubuntu is used by economic parasites more than Enterprises, even if they are businesses that make lots of profit.
Exactly what is not binary compatible in SL6? SL6 even ships with extra YUM repos, of which I've installed MANY things. The only problem I had was with the Remi repos, where I had to modify the remi.repo file to hard to version to "6" instead of "6.0" but no binary incompatibilities anywhere.
Perhaps you have a ready example to illustrate your point? I was actually beginning to think CentOS was dead it took them so long to release CentOS6, meanwhile, I've been using SL6 with much success for months.
And you've left out the most obvious Enterprise support option: get 1 RHEL license on a "support server" for reproducing bugs, and then create your own Yum repos to serve the RHEL6 RPMs. Hella simple, being doing it in big Enterprising since RHEL4 when I had to manually install Yum to replace up2date. Anyway, methinks you're wrong.
I do not trust the government to tell the truth on matters this large. While I doubt bin Laden is alive, I doubt the official version of his death even more.
Exactly, they claim it was a "capture" mission, but clearly it was a "kill every male in sight" mission: http://www.ibtimes.com/articles/141342/20110504/osama-dead-new-photos-inside-the-compound.htm
I highly disapprove of killing unarmed, non-combatants. It's quite obvious they were interested in covering up any potential "intel" these guys could have provided. If they were prepared to capture them, they would have captured them. It's not hard to fire knock-out gas through windows. Obama may have given a "capture" mission, but the order that eventually made it to these SEALs through the chain-of-command was definitely, "Kill all males, no capture."
Higher performance = higher maintenance = less reliability.
It had all these nifty features, but one in three of them crashed during mission. I hope they take the secrets and use them so their shit will start crashing too. Gratz on unreliably high-performance.
And if some monied interests don't like something legit you're doing, then what? You can't trust the gov't to not abuse this information and capability for immoral and illegal ends.
It helps control the population is what it does because then you can just pick off the dissidents one-by-one at your leisure.
People aren't giving him enough credit. He isn't ashamed of what his company did, he just wants to minimize damage the interview would have to his company's publicly traded stock value. He doesn't have "shame" like you or I, to him this is a bottom line issue. He's only trying to maximize share price while looking for an exit strategy as his company tanks. He wouldn't have even given the interview if his company wasn't tanking and marginalized in the market by Android and iOS to begin with.
Honest Question: Why in this day and age do we still have to chase down a black box? More and more airliners now provide in-flight internet connections. Couldn't they just transmit it as well as record it to the black box? TFA says this search is costing them $12.5 million. That would pay for a lot of upgrades and support for this.
And how often does your in-flight Internet or TV stations cut in and out? You gotta have what is likely a directional antenna pointing at certain satellites. There are any number of conditions that make getting that to work reliably quite hard.
...So until we get the public over its irrational fear of anything radioactive...
Worst-case with Nuclear plants is far worse than any other power generation. While 1/100,000 may seem like a remote chance to you, it still comes up. To call fear of radioactive things irrational is naive at best.
...we will never see nuclear technological advancements applied.
Good.
...we still have to address the *real* problems of Nuclear: What to do with the waste.
You use it as fuel in LFTR reactors...
and how to stop cheap bastard energy corporations from cutting safety corners in the name of profits.
You can't. Nor can you cure human incompetence or greed. All reasons we should not use terrestrial radioactive power generation. Show me a LFTR style design that won't leak radiation if a bomb hit it, and then I'll approve of a new Nuclear plant.
The odds of a Nuclear incident coinciding with some other catastrophe are very high, and that's the problem. You don't just get fucked, you get double fucked. Like Japan.
So there's two easy and common ways to load-balance SSL:
1. Use an upfront appliance--like a BIGIP F5 LB--that does the SSL encryption and load balancing across your back-end servers. 2. Give a separate cert to all your front-end servers, different IP, different subdomain (ie www1.yourcompany.tld, www2.yourcompany.tld, wwwX.yourcompany.tld). If you session data is especially large such that you don't share session between application/front-end servers, this would be appropriate. On your main SSL site, you redirect clients to one of the http://wwwX.yourcompany.tld servers based on current load and the user remains "bound" to that server for the entirety of the session.
This is not a hard problem, it's been thoroughly studied with established design patterns to solve it.
While SSL/TLS should prevent proxy caches, it in no way prevents load-balancing. If you're having problems load-balancing SSL traffic then you don't know what you're doing.
The performance overhead of SSL/TLS is an easily solvable problem, that's not really the issue. Modern Intel processors now have AES-NI instructions which can be used to accelerate SSL/TLS traffic with modern OpenSSL, plus there's always crypto-cards.
Cost of maintaining certificates aside, you need a 1-to-1 mapping with IPs. You can load balance SSL connections across a pool of servers, but for each domain under SSL/TLS, you need an unique IP address that reverse to the proper DNS name. You can not host more than 1 of virtual host across SSL on the same IP address, that is the real challenge.
If every site were on SSL, you'd run outa public IPs quicker.
That's for SD. Quoteth the article: "For high definition movies, the average encoding bitrate is around 3200Kbps and one user would transfer about 3GB of data."
You apparently didn't use any Direct3D version prior to 7. 10-15 years ago, all DirectX was crap in particular Direct3D. I was playing Quake before glQuake came out. Maybe you don't remember that.
Oh I'm absolutely sure they'll use another PowerPC architecture with the VMX128 ISA extension. At this point, both PS3 and XBox360 are running that. After a significant investment in their toolchain, and a now established base of Xbox360 games that would be trivially forward compatible with the new console, it makes sense to stick with this architecture. PPC w/ VMX128 is just a really, really good ISA for this type of computational work. Unless they license a MIPS core, which I doubt they will due to all the software development retooling and lack of an established 128-register SIMD engine.
I think the bigger question is one of how many cores, what clock speed, how much cache, will their be an internal ring bus to L3, will it be an in-order or out-of-order processor, what are the various latencies going to be like, or how will it be interconnected with graphics, memory, and storage. Also, how integrated are the GPU and CPU dies going to be? The only way I could see ARM is if Microsoft went with an integrated nVidia solution, but again, ARM doesn't have the same strong SIMD support as PPC.
So there are a couple philosophies on backing up your systems. If you can tightly control the imaging process and automate it so that it only takes 10-20 minutes, re-imaging may actually be not only a viable solution but an elegant solution. Especially when dealing with clouds where instances are essentially newly provisioned images. If you're logging to a centralized system and storing persistent data elsewhere, re-imaging may be OK. However, it doesn't replace engineering (define/design/implement/test cycle) a good imaging process. If there's a problem across all your machines, you'll obviously need to resolve that in the imaging process. I expect typically imaging processes to be complete with automated application deployment and configuration as well.
Zombie process are typically the faults that result from software errors. In this case, there is an error in the kernel implementation of NFS. This is indicative that you need to patch your kernel/install a new one.
Slashdot Mirror
I myself prefer debian on servers over ubuntu.
Yea, marginally better, they are both affected by the same huge gaping security holes.
Depends on if you consider Hedge Funds and High-Frequency Trading firms that makes 200% profit margins "Enterprises" or not. I mean really, what positive thing are they doing for the economy? Maybe Ubuntu is used by economic parasites more than Enterprises, even if they are businesses that make lots of profit.
If you're running CentOS in an embedded system, you're doing it all wrong.
Exactly what is not binary compatible in SL6? SL6 even ships with extra YUM repos, of which I've installed MANY things. The only problem I had was with the Remi repos, where I had to modify the remi.repo file to hard to version to "6" instead of "6.0" but no binary incompatibilities anywhere.
Perhaps you have a ready example to illustrate your point? I was actually beginning to think CentOS was dead it took them so long to release CentOS6, meanwhile, I've been using SL6 with much success for months.
And you've left out the most obvious Enterprise support option: get 1 RHEL license on a "support server" for reproducing bugs, and then create your own Yum repos to serve the RHEL6 RPMs. Hella simple, being doing it in big Enterprising since RHEL4 when I had to manually install Yum to replace up2date. Anyway, methinks you're wrong.
Scientific Linux 6 FTW! Took the CentOS guys long enough! Surprised they didn't skip to 6.1.
There's only one error message listed, and it's not very original!
I do not trust the government to tell the truth on matters this large. While I doubt bin Laden is alive, I doubt the official version of his death even more.
Exactly, they claim it was a "capture" mission, but clearly it was a "kill every male in sight" mission: http://www.ibtimes.com/articles/141342/20110504/osama-dead-new-photos-inside-the-compound.htm
I highly disapprove of killing unarmed, non-combatants. It's quite obvious they were interested in covering up any potential "intel" these guys could have provided. If they were prepared to capture them, they would have captured them. It's not hard to fire knock-out gas through windows. Obama may have given a "capture" mission, but the order that eventually made it to these SEALs through the chain-of-command was definitely, "Kill all males, no capture."
Higher performance = higher maintenance = less reliability.
It had all these nifty features, but one in three of them crashed during mission. I hope they take the secrets and use them so their shit will start crashing too. Gratz on unreliably high-performance.
I'd call that "relatively cheap equipment" personally.
And if some monied interests don't like something legit you're doing, then what? You can't trust the gov't to not abuse this information and capability for immoral and illegal ends.
It helps control the population is what it does because then you can just pick off the dissidents one-by-one at your leisure.
Pretty fluffy clouds...
People aren't giving him enough credit. He isn't ashamed of what his company did, he just wants to minimize damage the interview would have to his company's publicly traded stock value. He doesn't have "shame" like you or I, to him this is a bottom line issue. He's only trying to maximize share price while looking for an exit strategy as his company tanks. He wouldn't have even given the interview if his company wasn't tanking and marginalized in the market by Android and iOS to begin with.
Honest Question: Why in this day and age do we still have to chase down a black box? More and more airliners now provide in-flight internet connections. Couldn't they just transmit it as well as record it to the black box? TFA says this search is costing them $12.5 million. That would pay for a lot of upgrades and support for this.
And how often does your in-flight Internet or TV stations cut in and out? You gotta have what is likely a directional antenna pointing at certain satellites. There are any number of conditions that make getting that to work reliably quite hard.
...So until we get the public over its irrational fear of anything radioactive...
Worst-case with Nuclear plants is far worse than any other power generation. While 1/100,000 may seem like a remote chance to you, it still comes up. To call fear of radioactive things irrational is naive at best.
...we will never see nuclear technological advancements applied.
Good.
...we still have to address the *real* problems of Nuclear: What to do with the waste.
You use it as fuel in LFTR reactors...
and how to stop cheap bastard energy corporations from cutting safety corners in the name of profits.
You can't. Nor can you cure human incompetence or greed. All reasons we should not use terrestrial radioactive power generation. Show me a LFTR style design that won't leak radiation if a bomb hit it, and then I'll approve of a new Nuclear plant.
The odds of a Nuclear incident coinciding with some other catastrophe are very high, and that's the problem. You don't just get fucked, you get double fucked. Like Japan.
So there's two easy and common ways to load-balance SSL:
1. Use an upfront appliance--like a BIGIP F5 LB--that does the SSL encryption and load balancing across your back-end servers.
2. Give a separate cert to all your front-end servers, different IP, different subdomain (ie www1.yourcompany.tld, www2.yourcompany.tld, wwwX.yourcompany.tld). If you session data is especially large such that you don't share session between application/front-end servers, this would be appropriate. On your main SSL site, you redirect clients to one of the http://wwwX.yourcompany.tld servers based on current load and the user remains "bound" to that server for the entirety of the session.
This is not a hard problem, it's been thoroughly studied with established design patterns to solve it.
While SSL/TLS should prevent proxy caches, it in no way prevents load-balancing. If you're having problems load-balancing SSL traffic then you don't know what you're doing.
The performance overhead of SSL/TLS is an easily solvable problem, that's not really the issue. Modern Intel processors now have AES-NI instructions which can be used to accelerate SSL/TLS traffic with modern OpenSSL, plus there's always crypto-cards.
Cost of maintaining certificates aside, you need a 1-to-1 mapping with IPs. You can load balance SSL connections across a pool of servers, but for each domain under SSL/TLS, you need an unique IP address that reverse to the proper DNS name. You can not host more than 1 of virtual host across SSL on the same IP address, that is the real challenge.
If every site were on SSL, you'd run outa public IPs quicker.
So I take it "par for the course" = "quality of what one OK video editor could produce after a couple hours." Adding overlays => not that hard.
You, sir, are easily impressed.
What's news equivalent of the Razzies?
That's for SD. Quoteth the article: "For high definition movies, the average encoding bitrate is around 3200Kbps and one user would transfer about 3GB of data."
You apparently didn't use any Direct3D version prior to 7. 10-15 years ago, all DirectX was crap in particular Direct3D. I was playing Quake before glQuake came out. Maybe you don't remember that.
Oh I'm absolutely sure they'll use another PowerPC architecture with the VMX128 ISA extension. At this point, both PS3 and XBox360 are running that. After a significant investment in their toolchain, and a now established base of Xbox360 games that would be trivially forward compatible with the new console, it makes sense to stick with this architecture. PPC w/ VMX128 is just a really, really good ISA for this type of computational work. Unless they license a MIPS core, which I doubt they will due to all the software development retooling and lack of an established 128-register SIMD engine.
I think the bigger question is one of how many cores, what clock speed, how much cache, will their be an internal ring bus to L3, will it be an in-order or out-of-order processor, what are the various latencies going to be like, or how will it be interconnected with graphics, memory, and storage. Also, how integrated are the GPU and CPU dies going to be? The only way I could see ARM is if Microsoft went with an integrated nVidia solution, but again, ARM doesn't have the same strong SIMD support as PPC.
So there are a couple philosophies on backing up your systems. If you can tightly control the imaging process and automate it so that it only takes 10-20 minutes, re-imaging may actually be not only a viable solution but an elegant solution. Especially when dealing with clouds where instances are essentially newly provisioned images. If you're logging to a centralized system and storing persistent data elsewhere, re-imaging may be OK. However, it doesn't replace engineering (define/design/implement/test cycle) a good imaging process. If there's a problem across all your machines, you'll obviously need to resolve that in the imaging process. I expect typically imaging processes to be complete with automated application deployment and configuration as well.
...there are tools to compromise its keychain in a few minutes?
Zombie process are typically the faults that result from software errors. In this case, there is an error in the kernel implementation of NFS. This is indicative that you need to patch your kernel/install a new one.