cx01

All of Pooter's posts have five hyphens on the last line. So maybe this triggers the spam filter.

I found the following article: http://hiwaay.net/~becraft/FRS-myth.htm#hd25

Apparently the Fed's revenue is not 'destroyed' but transferred to the Treasury.

No, I wanted to point out that the total amount of debt can be larger than the total amount of (physical) money.

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 client would declare all locks upfront

But if the client crashes after acquiring the locks, wouldn't your system be deadlocked?

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.

There is even a paper about using Paxos specifically for distributed commit: http://research.microsoft.com/apps/pubs/default.aspx?id=6463...

There's a set of video lectures, which seem to be pretty up-to-date: http://gryllus.net/Blender/3D.html

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.

I would be skeptical of Schiff's investment advice. Look here for a rebuttal of his claims: http://globaleconomicanalysis.blogspot.com/2009/01/peter-sch...

No. The WebSockets API in Javascript only allows acting as a client, not as a server.

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.

Take a close look at the img-tag in the source code...