If there is only $100 in the economy, I can still owe you $105. To pay it back, I could start working for you and be paid $1 per hour. Now everytime you pay me $1, I would pay you back this dollar until my debt is zero.
In the real-world, with more than two persons, it would look more like this: I pay you back some amount of the debt, you spend this money and it propagates through the economy, until some part of it reaches me (in the form of a wage), so that I can use it to pay back more of the debt.
The two generals problem doesn't mean distributed transactions are impossible. It just means that you cannot guarantee liveness, i.e. a distributed commit protocol might block if the network fails. But it will never yield an inconsistent state (one node commiting and another node aborting).
Did you even read the Paxos Commit paper? There is no single arbitrator. And what is 'unknown state' intended to mean? The system will obviously always be in a known state. It will just block as long as there is no network connectivity.
The author is wrong. Distributed transactions are possible, for example using the Paxos algorithm. In Paxos, if the network fails, the system will block (i.e. become unavailable) until connectivity is restored. It's not possible for one node to commit and the other node to abort.
For apps sold on the Android market Google takes a 30% transaction fee, which is split between the payment processor and the carriers. Since AFAIK Google Checkout is the only supported payment processor, that should give them some revenue.
> In a true free market scenario with freely floating currencies, currencies in countries like Spain, Italy, Ireland, Greece would have devalued. Germany's currency would have strengthened. This would have made German exports (to other EU countries) much less competitive than they currently are.
Well, even without free-floating currencies, countries like Greece could just lower the wages, which would in turn reduce the price-level of Greek products, making them more competitive.
Regarding point 2, I wonder how much of a benefit Itanium would see from JIT-compiled languages, because the JIT could then dynamically arrange instructions to maximize ILP.
I agree. The US is in a deflation and I don't think the Fed will be able to stop it. So cash should gain in value. Just make sure to put it somewhere safe, as banks may go bankrupt in a deflation and the FDIC will most likely not be able to guarantee all deposits.
Distributed transactions generally use 2 phase-commit (2PC). If message loss happens, the 2PC algorithm will block, i.e. the transaction can neither be committed nor aborted. When the network gets reliable again, the algorithm will finish. So strong consistency isn't really affected by this problem.
A special case would be if the network is broken only in one direction. In that case, the same command may be sent multiple times, but even this is not a problem, since the 2PC commands are idempotent (e.g. receiving the Commit-message multiple times won't hurt, since the receiving node knows that it has already committed the transaction).
ZMQ is much lower-level than AMQP. ZMQ is pretty much a thin layer on top of TCP (or alternatively UDP) which offers basic messaging semantics like Publish/Subscribe. You create ZMQ-sockets on multiple machines and data written to one socket will be forwarded to all machines that have subscribed to this socket. There's several more socket types, for example Request/Response or point-to-point (which is mostly like a traditional TCP connection).
AMQP is much heavier and offers persistence and more advanced routing (and a lot of unncessary cruft). In theory you could build something like RabbitMQ on top of ZMQ (I say 'in theory' because AMQP defines its own wire protocol which is incompatible with ZMQ). AMQP is also server-centric whereas you could use ZMQ in a more decentralized system.
When I go to tryhaskell.org, it still doesn't work. I believe the patch that you've mentioned only applies to when the user presses ALT+TAB, which won't help here.
I'd suggest you either do "if(e.altKey)return;" or "if(e.altKey && e.ctrlKey)return;". Both work for me.
EDIT: Hm, my suggested changes work in Opera, but they break Chrome... This is driving me crazy.
I noticed that Opera sends two keypress events when I press "[". The first event (that generates the erroneous "8") has e.altKey==true.
So a simple solution might be to add the following to the keypress function "if(e.altKey) return;". I've tested this locally and it works for me, but don't know if it might interfere with other keyboard layouts.