...was the use of the word "atmosphere" so important as this instance.
The problem is that without accurate measurements of power consumption to support capacity and availability management data centers aren't able to do this as effectively as they could.
Companies such as nlyte and Modius do have solutions that address some of these issues. CA has a complete suite that address the entire DCIM space: ecoGovernance, which is a data aggregator / analyzer / reporter; ecoMeter, which provides accurate measurements of data center resources (including CRAC units, etc.) for the purposes of availability management; and ecoDesktop, a poorly named solution that ensures optimal usage of desktops and development / test servers by understanding usage patterns and using auto-shutdown / wake-on-LAN to shut down and startup machines when they are not being used to conserve electricity and ultimately save money.
Disclaimer: I am a CA employee, but I'm speaking from the perspective of one who was in IT for 18 years. This stuff is quite good.
I call bullshit on the first statement. I work in a sales related capacity (after spending 18 years in IT) and I don't exaggerate to make a sale.
Ask for financial metrics or calculate them yourself: what is the percentage reduction based on historical data of determining root cause of problems with Red Hat support vs. without? Multiply that by the going FTE for your industry / geographical region and you have hard dollar cost savings. Use a 20% discount rate (aggressive) to calculate future discounted cash flows (and determine Net Present Value). Solve for n% discount such that NPV = 0 and you have the Internal Rate of Return (IRR).
Then ask the CFO / Controller what the Hurdle Rate is and see if the IRR > Hurdle Rate. If so the investment is sound assuming the data on % savings for root cause analysis is sound.
With AES256 being a government standard for 10 years, why would anyone recommend CBC (which was considered weak long before AES was denoted the standard) as an encryption method?
You could use Diffie-Hellman key exchanges (http://en.wikipedia.org/wiki/Key_exchange#Diffie.E2.80.93Hellman_key_exchange) to strengthen this, but that wouldn't necessarily prevent the attack that was used in the demonstration.
"Welcome to hell, kid." - Wally (of Dilbert fame)
...and I'll even try to remember to check back in case people respond.
Assumption: the trading application being critiqued is the same one that was there when I was an IT consultant at Morgan Stanley. I left in August 2000.
I know the application well. It was developed by a department headed up by Vinny (whose name is withheld because...I'm senile and don't remember it). I worked in the department that wrote the messaging infrastructure that was used by every application on the sell side of the firm.
If the application is the same one then the mere fact that it was still in use when Mr. Fried left is a testament to the application's effectiveness. Would they do it better now if they were writing it from scratch? Of course. But Morgan Stanley has 3,000-4,000 IT staff in its ranks so they could easily do so if the application were as bad as he says. And the messaging infrastructure...well, I have no love for the original authors (no hard feelings Steve and Arthur...I'm lying of course), but that subsystem was extremely robust, predated TIBCO and Talarian, and provided more functionality that those two products until after they were on the market for several years.
The game is currently in development and the goal is to release it in downloadable form for consoles and PC/Mac. There is no announced date and platform yet. There is no publicly released demo at this point. There will be one when the game is released though, so please be patient
I guess the demo is somewhere in the 4th dimension...
And save electricity by not allowing the use of boldface, underline or strikethrough fonts.
"There is no statute of limitations on stupidity." -- Randomly produced by a computer program called Markov3.