It's a fundamental truth that, the more of the system you have to comprehend to truly understand it, the harder it is to debug. Syntax problems? Trivial. Global liveness checking? Much harder. (There's just so many ways to screw up.)

Having bought the Economist in various places around the world, you should be aware that the apparent focus of the magazine is different in different places. The content is formally the same, the articles are identical, but the ordering is not; this changes surprisingly strongly how one feels it is centric towards one place or another. Always buy in the US? It will be US centric. It's quite different in France.

Yeah, but good quality might well correspond to some sort of measurable anyway. Provided you've got the right measure. Maybe some sort of measure of the degree of interconnectedness of the code? The more things are isolated from each other, across lots of levels (in a fractal dimension sense, perhaps) the better things are likely to be.

Maybe that would only apply to a larger project, and I'm not sure what effect system libraries (and other externals) would have. Yet the fact that it might be a scale-invariant approach makes me a bit more hopeful, as it wouldn't be so susceptible to the "ravioli code" problem, where the code's nicely packaged up into little pieces, but the pieces interconnect in a horrible mess of higher-level spaghetti code. Worked on a large project? You'll have probably seen it in the wild. (Yeah, I've had people argue to me that their code didn't use goto and so it had no spaghetti code problems, despite the fact that everything was so nastily interconnected that nobody else could understand it. If that's not indicative of a problem, what is?)

Yeah, there's all these mad asshole gun-freaks in the USA that are seeking to export their crazy to everywhere else. Keep it at home, jerks!

So... automatic conscription is basically in place already? Only needs a minor step, calling on militia members to formally defend their country, and you've got a fully-fledged military police state. Nice one, sheeple.

And that's why having bills cover lots of things at once (rather than being automatically restricted to the principal subject area of the bill) is a truly awful practice. It's beyond corrupt as it specifically enables effectively sidestepping oversight of the legislative process. The pork-barrel politics the practice enables are merely the most visible and least harmful parts of this.

Major public holidays (e.g., Christmas) are much worse, as there's a really good chance nobody will even look at the warning, and may decide that their family time trumps fixing security problems.

April 1 is just the worst day to announce a major breakthrough or groundbreaking new product.

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?