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...

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.

I'm on Win7. Actually I made a slight mistake on my original comment. You get "[" by pressing ALTGR+"8" not ALT+"8". Don't know if it makes a difference.

Whenever I press "[" it actually inserts "8[" into the editor. I use Opera 10.5 and a German keyboard (on the German keyboard layout you get an "[" by pressing ALT+"8", if that's any help).

I think you might want to look at how Opera handles keydown and keypress events in Javascript. I had a similar problem working on my own project a few days ago.

Transactions ARE durable if you use replication.

Why? If a single node fails, you still have the data on 2 other nodes. Nothing is lost. Of course, assuming you have a reliable UPS.

Why do you think it is blogspam? You can also read the H-Store papers if you're interested in the details.

In-memory doesn't imply "unreliable". If you need high-availability you'll want to use replication anyway.

I think Play+Scala should be competitive with Rails in expressiveness, while still being a lot faster. Of course, if you prefer dynamic typing you might disagree with me here.

It also took me some time to find the prices. They're on the lower right corner of the frontpage.

If you do this for every transaction, you'll have more overhead than you'd have if you had just performed distributed consensus. But in principle you're right. It makes sense to put all the primary copies that are often used together on the same node. The problem is that it's hard to decide the ideal placement strategy. VoltDB puts this responsibility into the hands of the developers.

A phpBB-like forum would be great. I think you should just go ahead and start it. I'd use it.