Which works just fine when it is cloudy (like it is quite a lot in the Netherlands). Oh, wait...

You ask the browser vendors, who respond by asking some very pointed questions about how trusted you are. These sorts of questions include "do you have regular audits to ensure that you're managing your keys correctly?" and "what policies do you have in place for dealing with a security breach that compromises one of the keys you've signed?" Convince enough people that you're really trustworthy, and congratulations, you're a root CA. At least until the next time they ask those questions. It's only really recommended that you seek to become a root CA if you really like acting bureaucratically.

You can also become a root CA for a particular browser by just installing a self-signed certificate in its list of trust roots. This is disappointingly common, and often a marker of an untrustworthy organisation, as the main reason for doing this is to enable SSL sniffing. Not recommended at all (and totally does not make your site trustworthy to anyone else, which is the usual point of having HTTPS set up). It does work better for specialist applications.

Becoming a non-root CA is much easier. Just pay another CA enough money (or know the right people).

Doesn't matter. If anyone or any organisation insists on doing things beyond their financial means, they've got a problem. If they keep on doing it, they've got a serious problem. Sometimes you've got to be unkind to someone and say "no" because otherwise you'll go bankrupt and get to do nothing at all with anyone. Being able to say "no" on the grounds that what people seek to do is too far away from your mission is a critical life skill. (It's why having an actual mission is important!)

Sure, sometimes you can restructure your finances to be able to do more, taking on more debt in the hope of being able to generate more income in the future to pay it off. Sometimes that even works. If you're going to take on significant debt though, you need to be darn sure about how it is going to improve your ability to get income. There's no room for wishy-washy thinking here, as getting debt wrong can really screw you over.

All of the above is without looking at the details of what the GNOME Foundation were supposed to do or actually trying to do. It applies to them and to everyone else.

That's almost certainly the fault of using shitty access points. Anyone doing large-scale WiFi deployments is going to have to cope with lots of different client systems connecting all at once; there's no excuse for getting it wrong. Consumer grade stuff is definitely worse, but it only really hits home once there's a lot of devices loading everything up.

That depends on how many capacitor banks you've got, yes? Or possibly the sustained power output of the generators, though that's perhaps more of an issue for sustained firing. (Naval ships are pretty big; you can fit a lot of capacitors and generators in there.)

What I'm impressed at is that they can fire the railgun multiple times instead of needing to strip it down and rebuild it each time. That was always the problem with the early railguns; they'd be fine firing once but after that would be so burned up from the currents that they'd be unable to take a second shot on any reasonable timescale. They were cool, but not practical weapons. I'm guessing that that must've been solved, and the result is that pure kinetic weaponry starts to make sense again for ship-level encounters.

Mod parent up; it's very informative and worth reading.

Whether you get anything truly interesting out of the attack is a separate matter. Fortunately, the attacker can't control where the read is from (just its length) so you're more likely to get the session key (which the attacker will have anyway) than the private key from this sort of poking around around.

Beware memcpy()! If you don't know exactly where you're reading from and writing to and that you've got big enough memory chunks at both ends, you've got trouble. (OK, beware with memmove(), strcpy(), etc. too.)

It shouldn't be a sales tax. It should be a tax that is required to be paid at the point where the request to trade goes in, even if it is subsequently cancelled. That stops anyone from doing tricks like trying to probe what's going on using phantom trades. It wouldn't even need to be much of a tax to discourage the bad behaviour; like that it wouldn't deter anyone who's actually interested in holding the instrument for any substantial period of time.

What makes you say this? Is it just because you don't notice them?

The stability only really came with SP1 if I remember right; there were a few core problems (especially with networking) prior to that.

It's not like it's impossible to have toolkits for making active interception nearly trivial to do (provided you've got the hardware to run it on) and if you're thinking about ISPs or governments as the attackers, they've got access to the sorts of hardware which can run active interception on a massive scale.

Your main defence against them is that your life is very boring and ordinary and they don't give a shit about you. It's the other major group of attackers — plain old criminals who want to steal your money or your identity — who you're really protecting against.

You virtually always hit the noise limit before you get to the point where you have to worry about the fundamental discreteness of matter and energy. The majority of quantum experiments involve a lot of cooling and isolating of systems with very good reason!

But we've got lots more bandwidth and storage than we used to have, at least in some applications. We shouldn't worry unduly about key sizes (except for infinite ones, of course, which really require you to stay up fretting about them all night </snark>).

You mean you're not working with them already?

What's tricky about it? If they're so stupid that they're willing to put their children in that sort of danger, the children are likely to have inherited the lack of basic intelligence and foresight. Good Darwinian principles suggests that culling the herd in that sort of situation is reasonable; no action is needed beyond telling the parents "I told you so" after the fact if they survive, before suggesting that this indicates that they'd be best off getting sterilised for the good of the rest of humanity.

Go on, rub it in.

No, they don't. There are far too many variations in API and SQL dialects (let alone actual functionality) for two DBs to be considered to be plug-compatible. Instead you have whole layers of goop (err, ORM frameworks) on top to hide the differences. Those layers are, of course, usually incompatible with each other...

Outlawing the carrying of drivers would help more.