The government, since it does not have a profit motive, but obviously should not operate at a loss per launch, either, should be as competitive if not more so than the private company
Well regardless of what "should" be the case, SpaceX builds rockets much more cheaply than NASA does according to NASA itself.
Chances are the insurance, liability, that is would be less for the government for two reasons. First, it's launch sites tend to be over the ocean or the middle of the desert, so there is less chance of damage to others if a catastrophe occurs
Currently, SpaceX launches from Cape Carnaveral. That's also where NASA launches. These are the same. But clearly SpaceX could build their launch site anywhere it wanted to, and if it was paying for insurance it would surely choose a location to minimize its liability.
Second, and probably more importantly, the government is large enough that it can safely self insure itself against the risk.
If the government is so good at insurance, why doesn't it offer insurance to its contractors? In any case, the choice of insurance is independent of the choice whether to build your rocket yourself or have someone else do it for you.
So the question would remain, with all other costs being equal, why should the taxpayer take on the risk of a private launch vehicle so somebody else can receive the profit from the launch?
As I've said, it is much cheaper for the government to contract out SpaceX than to launch its own rockets, that's why everybody is so excited about SpaceX.
If it really is true that they're considering making it a choice between private contractors + private insurance OR a public launch with free government-provided insurance, that's pretty much horrible policy and it would make me very sad. But TFA seems to focus more on foreign competitors using this to undercut SpaceX pricewise.
This Ruby/Python thing has gone on long enough. Here we have two languages with identical use cases, identical advantages/disadvantages, and (in the grand scheme of things) almost identical properties in every way. The practical differences between them stem almost entirely from the fact that they happen to be used by different communities, so certain modules in each are much better developed than in the other.
The fact that they both exist has split development effort to the detriment of both. For example, the people that made this package for Ruby are just reimplementing NumPy, providing no advantage whatsoever over NumPy except for the ability to import Ruby packages. Which Ruby packages these people want to import for their scientific computing project that don't have Python equivalents, I have no idea, but maybe they should have implemented or improved those in Python?
Likewise, mod me troll, but I'm guessing Django wouldn't exist if Rails was a Python module. Tons of effort was duplicated there.
Can we just friggin' pick one and leave the other one to die? I don't care which, I'm not taking sides, it just seems to be a really silly duopoly.
Link to Original Source
Seriously, if someone has your password hash, it's game over anyway and it doesn't matter if it takes 2 weeks or 2 months to guess the passwords...
The whole point of a hash is that it's supposed to offer last-ditch security if it's compromised. Otherwise why not just store in plaintext? I don't want any sysadmin near a server holding my information if they take the attitude that the server will never be compromised. Assume the server will be compromised, and take measures to minimize the damage when that unholy day comes.
I use 12-character passwords. http://howsecureismypassword.net/ estimates that my root password would take 25 million years to hack. I'll put the hash right here: f1593fdf843f6161b377d5d8adf7ad03
Breeder reactors are not a mature technology and have not been put to widespread commercial use, so the field is pretty much wide open as far as which design should be adopted on a large scale. As far as I can tell, they are simply pushing this particular design as a way to get the ball rolling on wider adoption of breeder technology.