The best comments I've seen have explained why a particular string hashing algorithm was used; the algorithm used is not obvious. Or rather it's so obvious that programmers tend to think "it can't be that simple!" and go off and use a different one. Which has the same sorts of weaknesses and is slower, or avoids the weaknesses at a massive performance cost in normal deployments; the comment explains that this has already been tried and warns future programmers that repeating this particular blunder isn't worth it. (And yes, I didn't believe it the first time I read it, but I was cautious enough to performance check the code against all the "industry best practice" hashing algorithms I could find; they really are slower on our typical sample data and have the same sorts of problems.)

Another great comment I saw was just a reference to the academic paper that the implemented algorithm had been cribbed from. Some algorithms in multi-precision arithmetic and image processing are sufficiently complicated to be things that properly qualify as Non-Obvious; you need to read the literature to comprehend what's going on.

X has cruft that nobody sane uses except in pre-defined canned forms. Do you know what the system of visuals and colormaps does? Do you think that you should know? I've got something of an idea, and nobody's needed such a thing for at least 10 years now; hardware is such that everyone can support full color displays at any resolution you might need without any problems.

Speaking as a part-time maintainer of a toolkit library.

So they're responsible for the North Anatolian Fault? Much is explained.

A fair point, but a significant minority don't seem to be wired that way, for whatever reason. If some of the jackasses keep themselves under control for personal financial gain, that's still better than nothing.

That's not really much of an argument-winning technique unless you give the other side an opportunity to agree to the redefinition and to refine their arguments before significantly claiming that you "won". Also known as a No True Scots(wo)man fallacy.

In Turing's case, there'd also been an official apology previously, and so there was no official reason to issue an apology along with the pardon. (There won't be a declaration of innocence because he admitted committing what was a crime at the time. The myriad problems with the case weren't with the law as such, so much as everything else around it.)

It's a good thing that the law in this area was changed, even if it was changed later than some might have wished for.

This sort of thing is why commercial apps try to avoid using system shared libraries where practical. The issue is that you just never know what sort of crappy system you're going to be dropped into. Bundling as much as you can limits the pain a lot, and the cost is just space (and time when downloading, if relevant).

Of course, if nobody ever shipped buggy updates and never broke backward compatibility, you wouldn't need this sort of thing. But on Planet Earth... <sigh>

There are rather more disciplines than that. Theoretical CS is definitely towards the math side of things, but that's really at one end of the spectrum. The study of how people and computers interact is definitely part of CS, but isn't either engineering or math; it's closer to psychology. On the other hand, Computer Engineering is definitely an engineering discipline (as you'd expect with anything doing construction of physical objects on a mass scale).

Software Engineering is unusual though, as the costs of things there are very different to when you're working with the physical. For example, the cost of mass production is functionally zero and it is actually possible to modify things in service, so there's much more of a focus on the production of market-ready prototypes. (That would never work with physical entities, of course.) Applying the same level of control regulation to software systems as in physical systems is possible, but pushes up the cost so much that hardly anyone working that way can turn a profit.

Just when you start to think that all the parties are as bad as each other, the other lot gets in and proves that no, they're even worse. Rinse (preferably with disinfectant) and repeat.

Well, that sort of argument by itself will just get you into deep trouble. (Taking the piss with a court is a good way to get into trouble, and your argument is hardly plausible in the first place.) Steganography might work, but then you've got the problem of distributing the baselines so that the other party can decrypt; sending lots of visually-identical-but-not-bit-identical copies of the same image would usually be a dead giveaway that you're using steganography.

Or that you use Google+; I keep seeing the same old shit resent there.

It's far better to ask why the AG Hates Australian Business, given that he's trying to make all online commerce impossible. Or that he hates medical privacy because he's making it impossible to securely transfer patient records between doctors and hospitals. Find things that show why encryption is an important basic part of doing things online that is used for nefariousness only because it is used for masses of other things too. ("Cars are used to commit smash-and-grab raids! Ban them at once!")

The reason why radians are what they are is because then the length of the arc (of a unit circle) that subtends the angle R is exactly R. That's really convenient. (You could use diameter, but in real work you've got the radius far more often than the diameter.)

And any other ratio (especially tau!) doesn't satisfy the Eulerian identity, so can't be nearly so beautiful.

Compared with the startup time reported (90s!) even a 10x speedup would leave it being SLOW.

Actually, it sounds like something is critically misconfigured; I can't imagine any situation where a 90s startup is acceptable. Well, not in the last 20 years. (I remember using LispWorks when I started waaay back, and that had that sort of startup time. I dropped that commercial system for a lightweight open source solution and never looked back.)

I came across this password strength detector the other day. It really cheered me up, as it uses a scientifically-justifiable approach (information entropy FTW!) and it laughs in the face of a number of tricks that many people recommend despite them being actually weak (replacing "o" with "0" only really adds one bit of security, which is nearly nothing, whereas adding another word adds far more despite being easier to remember).

Anything that's actually fair should be proportional to the damage caused to the roads by the vehicle, so that's approximately the first power of the distance traveled and the fourth power of the axle weight. (I think.) Expect the road haulage industry to be utterly against any form of fairness, despite the fact that they objectively cause the majority of problems (due to miles travelled and weight moved).

No, it's just more than you can currently envisage using. What about streaming 3D interactive entertainment? The bandwidth requirements of such things are rather high, beyond what is practical now (and we also don't have all the other hardware required yet) but it's still reasonable to consider how to provide that.

Expanding capacity has an additional benefit in urban areas: sharing of capacity between multiple users becomes easier. Maybe you live out in the sticks, but lots of people don't, and lots of them want fast internet.