...if you have a valid policy set up for SELinux to enforce. This can be very difficult to construct, especially when you're trying to control the behavior of something like a VM.
For a student lab environment, this is likely to be overkill; if you have students in grades 9 thru 12 finding and exploiting holes in a VMM, you've got much bigger problems.
However I disagree that COBOL scales cheaply or efficiently. You could practically build a datacenter for the price of IBM's mainframes.
True...assuming you don't already have an IBM mainframe.
Most standardized tests where a graphing calculator would be useful, in fact require such a calculator. The current set of AP tests require/recommend a TI-84 or TI-85. The SAT itself highly recommends a graphic calculator.
Cool story. The SAT specifically does not allow calculators with a QWERTY keyboard. The TI-92 (the original one with the symbolic algebra solving system) had one and was, therefore, not allowed for the SAT. So, TI came out with the TI-89, which runs almost the exact same software as the TI-92, specifically so one could use an SAS-equipped calculator on the SAT. This is why the TI-89 is such an odd beast and somewhat harder to work with; the software was not really designed for that form-factor.
I'll always register a new account (usually easy enough) if I really want - too worried about such sites snooping my passwords.
When you use a federated single-sign-on capability like this, your password is NEVER sent to the service provider (the one you're logging in to using you Yahoo/Facebook/Google/etc account). It is only sent to the authenticating service (the identity provider), who already has it, and then that provider generates a signed message in a specific format (OpenID, SAML, etc) that vouches for your identity to the other site. In this model, your password is actually exposed LESS than if you create an account at the site in question.
basic security 101 just says that you don't trust another site with the keys to your kingdom... especially with zero assurance that it might even work.
If the other site can handle proper authentication of the user, secure storage of credentials using a suitable hash algorithm and a good amount of salt, and generally follows all of the best practices associated with these functions, and can provided federated single-sign-on using a mature, tested, and generally accepted protocol like OpenID or OAuth, then you absolutely says that you can trust another site to provide your authentication function for you. Well, maybe you can, depending on your business model and risk tolerance. Whatever you decided, I *highly* doubt that you can securely and safely store your users' credential information in a more secure manner than Facebook can.