If you are not willing to spend the 30 minutes it takes to set up your own CA and and deploy that cert on your own desktop, please hand in you "network admin" card immediately and seek alternative employment.
What's the morality of saving one hostage taken now if that leads to 10 more kidnappings laters? Just because those hostages are nameless and faceless (until they get taken hostage and possibly become headless) does not mean that their moral interests are any less real.
And, of course, the current hostage now was a hypothetical hostage in the previous iteration. Back then, he would have said "bomb them so they don't have an incentive to kidnap me later". Now he says "pay them $10M so I go free" even if that money goes to funding a kidnapping later, whereas the victim of that future kidnapping would prefer otherwise.
If kidnapping Westerners and keeping them within 50 feet of you grants you immunity from airstrikes, that increases the incentive to kidnap westerners.
There's no winning the hostage game -- if you ignore the hostages you lose the PR war, if you play to the hostages then you encourage future kidnappings. It's a lose-lose game. The same is seen for the millions of Euro paid by various European nations as ransom -- some of that money goes right back into funding more hostage-taking missions.
There is no way to time-consistent way reconcile the interests of the current hostage in not getting bombed/beheaded with the interests of future hostages in not being kidnapped in the first instance. It's a repeating game, we cannot evaluate each iteration separately but at the same time we cannot evaluate them all together.
For a fixed dimension phone, smaller circuit board means more volume free for the battery pack.
No, they don't even allow customization of IDEs there's no way to get vertical alignment on continuations. For example, consider you want to align multiple parameters of a function that's split among multiple lines. Spaces don't work because you have to eat up an amount of horizontal space equal to the initial indentation by tabs. Tabs don't work because you also need to eat up horizontal space equal to the number of characters before the alignment. The only thing that preserves the proper formatting is a mix of tabs and spaces like:
\tvoid SendNow(ConnectionHandle handle,
\t\x20\x20\x20 DataObject data,
\t\x20\x20\x20 DataPolicy policy,
\t\x20\x20\x20 Callback callback,
\t\x20\x20\x20 CallbackContext context);
And that is worse than forcing everyone to chose one or the other.
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 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);
if ( handle1 ) Release(handle1);
if ( handle2 ) Release(handle2);
if ( handle3 ) Release(handle3);
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
How many failed capitalist experiments are we going to be subjected to before corporations are no longer people, and the fruits of labor are distributed much more equitably here in the US?
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.