they didn't "hack" the machine using heat!

they gained control of both machines ahead of time, and THEN used heat (etc) to exfil data.

they didn't gain control of an otherwise stock computer using heat over air gap. stop saying "hack".

I'm afraid you don't understand the meaning of the word "hack" in this context. It does not always mean "gain control/privileges on a computer system in excess of your authorization". In this context, it means "defeat a method used to guarantee a particular security property".

Property: No control/data flow shall pass from the outside world into this computer
Method: Air-gapping that computer
Hack: Defeating that property and passing data between the machines

Let me give you another example.

Property: Computers in different classrooms shall not be able to talk directly to each other despite being on the same physical network
Method: Assign each classroom a VLAN and enforce that at the switch
Hack: By Double tagging certain ethernet frames you can defeat the property.

Now you are going to sperg because no one gained control of anything (even the switch). But of course it's still a hack -- you have shown that the switch + VLAN configuration is not capable (in its current configuration) of providing that guaranteed property of non-communciation between VLANs. In some sense this is actually a more elegant hack than taking control of the switch for obvious reasons.

TL;DR Version: "Hack" means to gain advantage or defeat a security property. Sometimes that involves traditional exploits/privilege escalation, other times it involves other methods.

Or it makes the developer's intimately aware of all the different places it can break and the places you need to make changes. And since they wrote large portions of it they grok the flow from a high-level ...

That is to say, you can make the code more maintainable without changing a single line. Another example is documentation changes or environment/setup like dev instances.

You really don't think he understands the irony of his request?
You really don't think he understands (or was explained) the flimsy legal basis for his request?
You really don't think he knew that the headline "Man who violated privacy upset about privacy violation" was going to spread like crack?

Please do not feed the trolls
Please do not reward the media whores.

The point about offending Canada isn't about whether he allows it or not, it's about the convoluted and interminable process that they have gone through to find out whether it is allowed. Realistically, they cannot start entertaining other (more costly) options, until the final rejection is received.

If there's one thing I hope could unite people that disagree on whether it should be completed or not is that the process should have a deterministic end point where a final decision is reached. It doesn't have to be quick -- it ought to take as long as necessary to thoroughly develop the factual record -- but there should never be a process that goes on indefinitely.

From a technical standpoint, it seems like the ideal solution is to have some programmable ROM that users can blow to indicate that they have accepted any harm that comes from clocking it beyond what the design (heat/voltage/lifetime) allows. That ROM would have to be queryable via a tamper-proof BIOS or EFI hook so that stores could verify that it is intact before accepting returns.

Ultimately, user freedom to do what they want with their own hardware has to come with user responsibility over the consequences -- and for that to happen there has to be auditable tracing of what software was run. In other words, freedom to tinker comes with an obligation to be accountable.

Of course, from a marketing/deployment standpoint we can't do this. The monkey at Best Buy can barely work the register, let alone query some low-level EFI hook. And that's the common denominator we have to work with.

Use a single generic cleanup that only cleans up what it has to clean up. That way you don't have a difference between the regular code path and the exception path. Also keep track explicitly on what you have allocated and what you haven't.

int func(void)
{
    int something = E_NORESOURCES;
    ResourceHandle handle1 = NULL;
    ResourceHandle handle2 = NULL;
    ResourceHandle handle3 = NULL;

    handle1 = GetResource1();
    if ( ! handle1 ) goto out;

    handle2 = GetResource2();
    if ( ! handle2 ) goto out;

    handle3 = GetResource3();
    if ( ! handle3 ) goto out;

    something = DoSomething(handle1, handle2, handle3);

out:
    if ( handle1 ) Release(handle1);
    if ( handle2 ) Release(handle2);
    if ( handle3 ) Release(handle3);

    return something;
}

That's fantastic, as an engineering solution but is very capital-intensive. Right now nuclear is being hobbled by huge up-front costs (and the cost of financing them over a large amortization schedule), so it's not the best business solution, even if it's right from a technical perspective.

Sad but true ...

What if it didn't matter how the fruits of labor were distributed so long as the number of fruits grew faster for each individual? That is, what if society was not a zero-sum game involving distribution of a set supply but a question of setting up the rules for maximum growth of the total?

I, for one, would rather consume 50-units in a community of individuals making 100 each then just getting 25 in a community making 25, even if the latter was distributed more equitably. To be fair, this is a point that a lot of people differ on - I've had some people earnestly believe that the disparately of consumption is itself an evil that's worth paying the price of making everyone worse off on an absolute scale.

[ Note that none of this suggests that unbridled capitalism is the best at growing the average consumption power. The history of capitalism is full of crony deals and other market perversities that ended up making everyone poorer on the whole (even as it made some individuals rich). Ultimately this is distinction that I think we need to abide -- are people getting rich by making everyone better off (e.g. by giving people things they actually want at a price they are willing to pay) or are they getting rich at the expense of others. ]

Half the time these injunctions are issued they apply to some ancient product anyway, because the suit was initially brought 18 months ago. So then they fight over whether they can add new products to the suit, the defendant argues against it, and the whole thing drags another 12 months until the original product is no longer being sold and the injunction is moot anyway.

I'm not a huge fan of patent law in general, but it strikes me as absurd that the legal system does not consolidate these sorts of claims into a general "Company X is infringing patent Y with products Z, Z2, Z2S, ZPLUS and any further evolutions of the Z-line that contain this technology. And this applies even if it's not called 'Z'"

Otherwise it's just nominalism -- you slap a new name on it and release it for a new year and suddenly it's not part of the same controversy?

This is old hat in the CS world that gets re-discovered fairly often: you can increase throughput at the cost of ravaging your latency. For some tasks, this is an acceptable tradeoff -- for others (especially anything interactive) it's completely unacceptable. Moreover, any synchronization point in the program converts the worst-case latency of the previous tasks into limits on throughput, e.g. the time it takes to join a set of N threads is equal to the maximum latency of any single thread in the list.

The best analogy is an elevator (sorry car folks): you can optimize your elevator for throughput by having it always select the closest floor with an active call. The cost, obviously, is that if people are shuffling between floors 1 & 5 a lot, then the poor guy up on 30 might wait a really long time. The throughput is still maximized though, since the elevator can do more operations per unit time by avoiding the long trip to and from floor 30.

In some cases this is fine, in the vast majority of cases you want to ensure that all tasks complete in a more bounded amount of time, even if that reduces the total number of tasks completed per unit time.

No, that's a zeroth approximation. To a first approximation, 65Mhz of spectrum gets you capacity linearly proportional to the frequency.

Of course, in reality there's a few more nasty surprises -- higher frequencies can carry more capacity but have much worse penetration through obstacles. Lower frequencies give better coverage at the cost of capacity. That's why shoving T-Mobile and Sprint up in the 1800+ nosebleeds means they will never get the coverage range of VZ and ATT down in the 700-800 range.

I'm no Windows fanboy, but this is just factually incorrect.

(1) All those operations require elevation, so unless the user has lowered UAC from the default, they will require authentication. I suppose a malicious installer could do that, but it is emphatically incorrect that any running code can effect that change.

(2) Since 7, when Windows elevates it completely suspends the old 'Desktop' and creates a brand new one for the elevation prompt. If you look closely, you'll realize that all the other 'windows' are actually just a static screenshot of what happened on the unprivileged desktop at the point where the elevation prompt was created.

So "from a security point of view", on Windows you have a specific privilege required to change the SS that is mediated through a privileged interface where it cannot be snooped/intercepted by unprivileged processes.

[ Of course, this comparison is also patently unfair -- Windows 7 was written in the 2000s, X11 was written in the 1980s. Expecting them to be comparable in terms of security is pretty ridiculous. ]

Reading posts in context is pretty key. For instance, I was replying to a post with the claim:

When now (taking your info) it should specify that you check a box and pay more for registration and your insurance costs more.

So you are right, and the guy to which I was responding was wrong. Doubly wrong for using "simply" for something that wasn't simply that.

Mostly (a). For instance, most registration can be done online but comercial still requires an in-person trip to the DMV. The fees are also higher for no perceptible reason, but (c) is off the mark since we are talking about commercial vehicle registration, not commercial driver licensing.

As to the last question, I don't think it matters. If the State wants to impose a uniform insurance requirement (details tbd) on all taxis and similar ride services, they can go ahead and do that directly and clearly. There's no need to tie it to registration or any other thing -- just go ahead and plainly say that you need such-and-such insurance if you give rides in exchange for money.

[ Of course, that would increase the cost of traditional taxis just as much as Uber, which is (IMHO) a feature of a fair set of regulations. They are supposed to protect the customers by providing insurance/inspection/training requirements, not pick favorites among competitors. ]

If it was just a matter of ticking off a different check box, why wouldn't every Uber drive just go ahead and do that when registering? In fact, if checking an additional box gave you more privileges, why wouldn't everyone do it all the time?

In practice, of course, it's not at all "just checking the box" but rather a red-tape nightmare of confusing and contradictory regulations. The process needs to be cleaned up and the regulations (which I'm sure the content of which are mostly fine) need to be stated clearly and applied uniformly. That's not too much to ask.