I truly found Enlightenment - at least the early version - ridiculously cumbersome.
Imagine this: you stop your mouse cursor over any UI element and a tooltip about that element appears. Reasonable? Not quite. the desktop is considered an UI element, and if you leave the cursor anywhere over it, it opens a tooltip. With rich borders and description of every single action you can perform by clicking, right-clicking, shift-clicking etc - the tooltip was the size of your average terminal window, and "always on top" meaning it covered a sizable chunk of the screen. You'd have to carefully "park" the cursor over some inactive area, because just leaving it around opened huge tooltips obscuring the content.

There's a problem with this claim. Similarly to file-sharers, they don't *actually* cost the transport companies any money.

1. It assumes they would pay if not the scheme. It doesn't assume they would take alternate transport medium.

2. It assumes all the income is from the tickets. It disregards both tax-funded subsidies (from 'freeloaders' tax money) and the punitive charges income (no matter if paid by given freeloader alone or from 'insurance')

3. It assumes cost scales linearly with the number of passengers.

Let me expand on that. The cost of operating a line is mostly a fixed value - amortization of the bus, salary of the driver, costs of operating the infrastructure. Fuel is only a minor part, and even then, then, take bus weight of 10 tons, passenger weight of 100kg, assuming (falsely) the fuel use increases linearly with number of passengers, the difference in cost between driving an empty bus and one with 1 freeloader would be 1%.

In other words, each freeloader in the absolutely worst case scenario adds 1% to the cost of operating a line. In more realistic scenario, this number will be over an order of magnitude smaller.

As effect - yes, the freeloaders do increase the costs for others. Assuming 10 of them per ride - by about 1%.

And one thing more. If they can't break even on the punitive charges, that means the controls are too infrequent. If $15/month suffices to cover $180/capture, that means one control per 14 months. Seriously? Make the average 1/month (still very little with people riding daily) and the 'insurance' will need to rise to $180/month. With $150/monthly pass, the problem will vanish.

Snow is iresome, making the ride uncomfortable, slower, and more risky.
Even small amounts of ice make the ride practically impossible.
During a turn on a bike there's a significant lateral stress against the tire. On slipery surface you just fall, period. With snow or mud the tire squeezes a track, keeping some traction. On ice it just slips.

Considering the size and mass of these drones, comparing to toughness of other airborne objects, and comparing the amount of emotions they arouse...

why is existence of birds still legal?

As one who works with these currently, I can confirm.
The main CPU has its software written in such a way, that you can't force green on two conflicting directions. Simply, the traffic program won't allow them, not through some emergency modes but just not starting a conflicting green until the prior one is lit and sufficient time after it went off was elapsed.
You could try to override it, say, redefining signal color definitions, "green is the new red", or even try to short-circuit the wires. But that is detected by the hardware and then the supervising CPU kicks in and simply trips the contactor disabling power to the signal lights. No 'emergency mode' which could still light up green in case of short circuit, no trying to make output modules not to output any signals in case a triac is fried, just general power off through a mechanical switch. (also, any output module that reports some kind of fault and doesn't get a reply within 300ms, it trips the same contact.)

What the attacker -could- do is change the traffic program - redefine assignments of signal groups, change the collision matrix - making both processor simply not see two groups as colliding. But to do so, they would need access to some highly specialized software for generating traffic programs, or painstakingly reverse-engineer the file already present in the controller, not a small feat.

They *can*. But they *don't*.

While not pushed by quotas, they are tempted by personal incomes directly proportional to in-game sales. Ther is always the incentive to grab more money, whatever it is.
And single-player games can be (and frequently are) made equally hopeless money sinks in pursuit of progress in game, as opposed to advantage over other players. When a game requires you to spend three years to accumulate enough valuables through "free means" to avoid that one $30 payment required to progress (actual example), and this after you've invested about a month of your time to arrive at that point, this is no longer "pay if you want to gain advantage", this is "pay or GTFO."

Once again, this is not about what game companies may do to make these games competetive and fun. This is about the ugly reality of what they actually do, with few very rare exceptions. So, no wonder if a player sees a game announced as F2P, automatically labels it a scam. Because usually it is a scam.

Fact versus Belief.
Even though giving it away would not affect CostCo's income adversely, the management is likely to believe the opposite would be the case. Even worse if *some* managers deemed the prior statements a valid risk, one that gave a "go ahead" to distribution would get in trouble. "Better safe than sorry", even though the actual risk was non-existent, the very likehood of belief for it to be real made it serious enough.

Fill up the ATM with propane gas through the money slot.
Set up a fuse.
Pick up money and run.
Some photos.

Quite impressive, though the success ratio isn't too high.

"Please enter the amount."

700

"The amount entered is not divisible by 0. Please select:
[650]
[750]
[other]
[cancel]"

I choose "Cancel" just in case it applies similar mathematics to my actual payout.

Actually, that sounds like info muggers would find pretty valuable.

Any transaction can be refused if the parties don't agree on method of payment. You technically could demand Rai Stones for the dinner in a self-service bar where you pay at the counter upon receiving your meal. Of course you won't get many customers and some may be outraged but legally you're in the clear.

OTOH, you can't refuse dollars for debt. If someone comes to your restaurant, order a dinner, eat it, and you bring a bill for 4 Rai Stones, they may pay you in dollars instead. They got their meal, they ate it, they owe you money - they are in debt. You can't refuse paying that debt in dollars.

Airlines can refuse cash when you request a ticket. But if you were to pay upon arrival, after the flight, they would be unable to refuse cash. Service done, you owe money - it's a debt.

You could already bump the "success if lost" number for Bitcoin. After recent hack of Bitcurex.com, Bitcurex returned all stolen assets to the customers (using own reserve). I must say they dealt with the hack quite gracefully.

So, there's this bar, with "No Blacks Allowed" sign.

The owner takes down that sign. Everyone's welcome.

"Oh no! You're banning whites! You bastards!"

Formal proof of design correctness doesn't preclude technical flukes.
On the contrary, do you know the technological process to produce CPUs with varied speed and varied number of cores in the same family?
Make a single design. Manufacture exactly the same wafers. Test the built CPUs, stress-test their capacity to perform at varied speeds.
Surprise: the results vary wildly from chip to chip, made with exactly the same design, machine, process.
These made with less contaminants will perform better and be labelled higher speeds, these speeds tagged in firmware. These where all 4 cores work flawlessly will be sold as quad-core. These where 2 cores are definitely underperforming, will have them disabled in firmware and be sold as dual core. You can often make your CPU triple-core by enabling one of cores disabled by factory.
And the bottom line is the process of testing depends on luck - on the fact that the fault surfaces during the tests, and not later. That it's frequent enough to be noticed by the QA. That it doesn't appear in conditions obscure enough to be overlooked in test cases.
As result you receive a product that will perform correctly most of the time in conditions not too varied from test conditions. But it's full of potential faults, and bugs for which no software solutions exist - because they are unique to your singular issue of the CPU.

Of course there are bug-free CPUs. Manufactured with extreme redundancy, in a process suitable for CPUs of a thousandfold higher complexity. Except they are trivial too, each of the parts testable thoroughly. Modern Intels with byzanthine complexity of super-efficient optimizers built in, simply utilize every last nanometer of chip to fit more cache, more pipelines - they won't sacrifice half of the volume to features that will be used only during testing, to triple-check every single transistor.

Luckily, in this game the pasture is calculated in such a way, that the moment you introduce more cows than all neighbors combined, all cows die, including your own, and another neighbor introducing yet another cow actually improves the quality of the pasture.

Note this is not a blind theory. People who manufacture ASIC devices *sell* them for bitcoin already. They *could* run them themselves and would probably earn more BTC. But as result they would weaken bitcoin and the earned BTC would get cheaper in the long run! In essence, they take care so that the computational power is distributed.

Dumb miners *could* theoretically screw up like that. But achieving 51% is a very difficult task. To achieve 51% you need to be pretty smart - probably smart enough to understand achieving 51% would be self-destructive.

One exception: an institution bound on destroying bitcoin - say, the World Bank - could do this, precisely in order to destroy it.