melt downs like Fukushima, Chernobyl, and Three Mile Island — would be virtually impossible at sea."

And the Titanic was an unsinkable ship.

Fundamental inescapable facts:

(1) Anything fragile can break, no matter how many backup systems and safeties you install, because

(2) Everything that can fail will eventually fail, and,

(3) When you have multiple things that can fail, eventually, they will all fail at the same time or the least opportune moment, and

(4) At sea, there is no such thing as a large man-made structure or boat that is not fragile.

This is why we need to switch to LFTRs

No pressure vessel to worry about.

If there's anything that a consultant craves, it's billable hours...

Not billable hours at the cost of doing a crappy job, and most certainly going to get blamed, when the customer blames his company; when the failures caused by consultant's CAB causes downtime.

That particular outage cost several million given what the server did.

The problem is not the admin actions it's "what the server did"

The application the business was dependant on to generate millions of dollars was designed in such a fragile way, that it could fail as a result of whatever happened to just one server....

You see... this is bad architecture. Servers are prone to failure, even when designed with redundant components.

It is improper for a business application that generates revenue to be sensitive to a single or double server failure. Critical applications should be architected with a level of robustness that reflects their level of importance.

The auditor does not care if the patch may cause a work stoppage, if they are not fully patched, they are not in compliance, if they are not in compliance they get written up

Sounds like they need to fire and hire new auditors.

like this will just make you look stupid and change averse to your employer.

No... it's obviously just aversity to excessive, unnecessary and crippling micromanagement. It's obviously some idiots in suits who are change averse and feel they need to justify their existence by "approving" or "disapproving" of each and every required security update or patch or system admin action.

Which involves real costs. With this kind of bullshit, they need to hire additional system admins for systems to approach proper management just to deal with the reduced time efficiency and increased waste caused by bureaucracy.

No one can do that reliably. It's luck.

That's not true. There are people who can do that. You need enough money to be allowed to freely invest in private firms and such though.

And you need to have not so much money, as well. Too little money OR too much money, and you cannot make good returns. It is not as if your potential return is independent from the amount of money you have, there, so it is a bit meaningless to throw around numbers such as 18%.

If you have too little money -- then you don't get access to investments (except ones that have already become public companies, which suck) ---- if you have too much money, then you actually exhaust what good options are available.

which is stopping people feel sympathy towards people living on the street as it's easier to have 'less feelings when you're typing something' than looking at them in the eye"

If you are not looking them in the eye, then you are not experiencing the Identifiable Victim effect.

An amazing annual return is considered > 10%.

This is true: only until you have access to accredited investor status and hedge funds.

It looks like you skipped over the part, "that doesn't rely primarily on luck".

It doesn't depend primarily on luck. It depends on your ability to select a sequence of investments that will have an average payout of more than twice what they cost. You don't know the outcome of any one investment (success or failure), but your ability to pick a sequence of investments that are expected to offset each other's random risks and have sufficient average payout when taken together (expected total gain minus loss averaged more than twice cost), is one of skill, and it relies on decision making abilities.

Good luck is when the average payout turns out to be twice as much as expected and happens less than 1% of the time. Bad luck is when the payout is half or less, and happens less than 1% of the time.

This is assuming a skilled selection.

When we say "high risk"; we do not mean visiting a casino and placing bets, where you have an expected loss of 10% due to the house edge, (assuming you had infinite cash and placed bets forever).

Sure becoming a multimillionaire is (theoretically) easy. But nothing I do will make me a billionaire that doesn't rely primarily on luck

You just need to become a millionaire and then double your money 10 times.

Once you have the millions, there are plenty of high-risk investments to pick from that are likely to do just that.

Mark Karpeles will not be attending the bankruptcy court hearing in the United States scheduled for April 17th.

Extradite him. He's probably not coming to the US for the hearing, because he could be arrested on the spot.

I would be fed up with FedUp... if I were you

Wake me, when there's a RHELUp available to go from RHEL5 to RHEL6.

More seriously.... I don't run production systems on Fedora, and I don't think anyone should.

Fedora is more of a developer desktop OS; that gives an idea of what the future version of RHEL might look like in the future.

Safer != Perfect

Open Source is not perfect. It also does not help when you have large commercial institutions RELYING on the source code in a security critical role under constant attack by well-funded adversaries, AND the developers of said open source code are so pitifully underfunded, AND the commercial proprietors that cause said open source library to become a high-value target are only willing to invest in features, and not improvements that would lead to better quality and lesser likelihood of serious bugs.

I never saw a C program with a remote file inclusion bug or a C code injection bug caused by an eval().

Pretty much all the errors caused by C fall into two buckets: reading an improper memory location and writing an improper memory location (including double-free'ing an invalid memory address).

As long as you can be certain to avoid those two conditions, C is just as safe as other languages. There are ways you can design your C programs, and rules you can follow which make it unlikely for you to include such errors.

For non-trivial programs, there are plenty of advantages of managing your own memory: which you cannot do in other languages such as Python or Java.

The other languages' use of garbage collection results in great space and runtime inefficiencies.