Why not? It'll just appear that the user is using too much data. They'll either run out of data, get charged more or the use will figure out that their data/battery is acting unusually and sort it themselves. However you look at it, the problem will take care of itself!

Dear Michael,

The scientific high ground in this matter is to admit that the original peer review process sucked, lacking as it did any reviewer with sufficient statistical expertise to detect subtle methodological errors, and further, to admit that it does not require a PhD in any discipline to point this out (nor, especially, a peer-reviewed paper) if it happens to be true that the paper contained subtle methological errors (which it did).

It's all well and good that the main result itself seems to have held up under additional scrutiny brought to bear once these admittedly small deficiencies were aptly pointed out. This does not change the fact that the original peer review sucked.

(Perhaps you were merely lucky that your result continued to hold water after your subtle statistical errors were properly addressed. This is why a result that merely holds up isn't worth much in a high stakes debate. Proof by hindsight does not strike me as adequate given the magnitude of societal change that effective mitigation seems to require. To me, the stakes seem to be high enough to demand that critical links in the argumentative chain are right in all necessary respects before they are attached to a giant political lever; or, failing to achieve the almost impossible demand of being right in all essential particulars in peer-reviewed published paper V 1.0, that the culture of climate science embrace with a blazing passion the art of the mea culpa bug fix.)

Ordinarily, the peer review process is not expected to be 100% water tight, as the standard pace of science is stately and the stakes are modest. In this example, you paper served as the fulcrum of the biggest political mud fight of the late twentieth century. If climate scientists think that the fate of humanity and the planet lies in the balance, there shouldn't be even an epsilon gap in the quality of the peer review process.

You can't have it both ways without looking like a complete idiot. And it sure doesn't help your cause to look like an idiot when you're being attacked in a thousand illegitimate ways.

Thanks for your attention to this matter. I look forward to the future scientific culture of rock solid peer review in the first instance.

Live long and prosper,
J. Random hockey fan

(By some strange twist of fate, this was the first item to cross my feed after spending thirty minutes flipping through Popper's The Logic of Scientific Discovery which I'm presently reading to discovery why David Deutsch, in particular, praises it so highly.)

No, he's done his work. Now you can search github for yourself.

A funny screed, but in the end just as wrong as what it debunks.

The Mossad does not have a bottomless budget. As a result, they generally fabricate pieces of uranium shaped like cellphones in hundred lots. They have even more expensive intrusions, which they fabricate in lots of ten, and then they have the most expensive intrusion of all, which is fabricated like a James Bond concept car (not the car that Bond actually gets, but the one he might get ten years from now).

It really does matter to edit your SSH configuration file to bump yourself up from 10^-9 cost bracket to the 10^-6 cost bracket.

Mossad is not magically except from the 80-20 law. They still try to use the cheapest effective method, and hope to haul in 80% of the catch for 20% of the effort.

If you're in the 99.999th percentile of pure evilness (backed by a private island gold reserve), it's no longer about casting a wide net, and moreover, you already know for certain that you're facing a Mossad-level adversary and you can proceed directly to paranoid schizophrenia.

If you're only in the 20th percentile of pure evilness (you fib on your tax return and download porn off some Shmoe's open wifi) it might just be true that Mossad-level adversaries filter feed at the cost-effective 10^-9 screening bracket.

They went to all this trouble to subvert NIST not because they couldn't break things otherwise, but because they couldn't afford to break things otherwise at the largest possible scale.

In 2016, the attacks on ??? expand to ???. I'm not betting MY customers' security on the answer.

Good luck with having any customers by the time you whittle away every protocol with a potentially expandable attack surface.

As we don't even have a formal theory of quantum computation yet, but we do know that some things can be computed by quantum methods, I don't think any current protocol is entirely exempt from worrying cracks in the plaster.

Whatever you like to tell your customers, there's just no escaping this hard business of having to make a judgement call about which cracks to worry about and which to ignore.

you will open that door

If your disk contains a larger number of large files with the names entropy$N (of which, the vast majority are actually full of entropy) the ability of the judge to distinguish a door from a wall declines to epsilon, at which point the judge might elect to sweat it out of you nevertheless (you're entirely screwed in this eventuality once you have no more passwords to divulge), but then so is the judge who gives a shit (some do) about the logical justification for his abuse of power (he can't actually know you're being willingly non-compliant—even more so if the file exercise_in_civil_liberty.c is found on your system containing code capable of having created those N-k entropy files).

[Yes, I'm aware that any stray disk subsystem metadata must support this story to the nth degree.]

Self reply:

I see in my post that IDLV mutated into IDVL and I mangled an mdash entity into a real mdash in one sentence. Pardon my sloppiness, but I didn't want to miss this opportunty despite feeling a bit rushed.

Alex: I regard my first encounter with the STL (very shortly after its first public release) as one of the great eye-opening moments in my software development career. Unfortunately, as I'm sure you well know, quality of implementation issues in compiler support for the C++ template idiom cultified (i.e. made cult-like) the deeper principles for at least five (if not ten) years thereafter.

GotW #50

I've long regarded the criticism against vector[bool]—I'm not going to fugger with angle brace entitiesâ"not being a container were misguided. Of course, it *must* be a container for reasons of sanity, but to portray the problem as a standardization committee brain fart seems to miss the main point.

Just as STL introduced a hierarchy of iterator potency (that was the main technical innovation behind the STL, was it not?) one could likewise introduce a hierarchy of container potency. The container we ended up returns interators which promise a dereference operator returning an lvalue (it's been a long time since I've used this terminology) which is why the following statement from the linked discussed is expected to work:

typename T::value_type* p2 = &*t.begin();

But actually, of all the uses of containers found in the wild, I highly doubt that more than a small percentage (potentially a very small percentage) exploit the property that interator dereference returns an lvalue rather than an rvalue.

The net effect is that the standard containers promise us a potency we rarely exploit, yet the burden of this potency is universal. Forsake it in even the smallest way, and you'll be shouted out of the room for non-containerhood.

We could have handled vector[bool] by changing the standard container to not promise IDLV (container iterators dereference to lvalue). In cases where the programmer goes ahead and tries to do this, he or she obtains a simple syntax error (ha ha ha) and knows to either reformulate the algorithm to not require this property or to go back and add a specification override to the container setting the IDVL property to true.

With IDVL set, vector[bool] does not specialize.

With IDVL unset, vector[bool] will specialize.

Problem solved, except for the language overhead of introducing (and managing) a container strength hierarchy.

But instead, Herb Sutter decides to write this:

Besides, it's mostly redundant: std::bitset was designed for this kind of thing.

Doesn't that attitude make you want to pound your head upon a table somewhere? Seriously, if one repeats that remark 1000 times, we could almost make the entire STL go away (and return to the world we would have had instead had the STL not rescued us from parsimony mass produced.)

Clearly, there was enough of a pain point in the C++ standarization effort around iterators that the STL gained traction exceedingly quickly (and very late in the day), yet the C++ community is also extremely hidebound about minor pain points, as evidenced by Sutter's explanatory tack.

Obviously, there were some advantages in demonstrating that the STL approach could achieve performance comparable to C (and in some cases, better than C) in proving that the STL was not just another abstraction gained at the expense of runtime overhead (which all looks fine until five or ten different runtime overheads—however small each of these appears in isolation—begin to interact adversely).

But very quickly, the initial quality of implementation issues and the quirky (to be extremely kind) limitations of the C++ template mechanisms threw up some major walls in pursuing the underlying ideas behind the STL more extensively.

So, my question is this, more or less: in retrospect, was the early victory with C++ worth it (it's extremely easy to understimate the value of having a good idea noticed at all), or does the eternal puberty of the C++ STL continue to grate?

It was specifically designed to target tablets, because there was already a perfectly good ui for the desktop, but which was not considered suitable for tablets (and phones). So they created one which was equally unsuitable for desktop, phone or tablet. It's quite telling that you question whether they even attempted this; Google for yourself if you don't believe me.

They believe that they're going after regular computer users rather than traditional Linux users, but nobodies heard of unity or Ubuntu outside of the Linux community and, in the uk ar least, there's zero marketing that I'm aware of for Ubuntu phones/tablets, if any devices actually exist, so canonical have next to nothing to show for this 5 year experiment apart from a massive exodus of previously happy Ubuntu users to mint.

But windows has a better interface than Unity. And it's trivial to surf the Mint site and choose which ui is for you. No sane person would chose unity over any of them, and I'm at a loss as to what canonical was thinking when they imposed it on all the previously happy in l Ubuntu users without any option to revert back if they didn't like it.

Unity is nothing like classic windows otherwise I'd not have dumped it for Linux mint like everyone else. It's looks like a mac user's attempt to do a tablet friendly version but on a device without a touch screen, which is retarded. Plus they released it while it was unfinished.

I'd use one of my android phones or tablets to help but the functionality keeps completely changing so as soon as I relearn how to run a program or get on the internet they change it again, and I'm unable to do so. But one day they'll slip up and leave it long enough between completely changing the functionality for me to figure it out, at which point I'll be right with you.

Yeah, big Linux fan but they all suck for one reason or another. I'd actually rather like a windows xp/7 interface over Linux. But really I'd take anything stable and where all the apps look sane under it.

Why does that matter? I don't run marathons for the labor involved.

Among the people I run with are contractors, police officers, EMTs, etc. They run the whole gamut of professions from those who do a lot of manual work to those who do very little.

Well I know of two guys who did run marathons who built houses for a living. One of them has since sold his business but that's what he did. It may be true that those of perform manual labor are not as likely to run but they are there.