cx01

9 ms·

31.
by cx01 16y ago
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
32.
by cx01 16y ago
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
33.
by cx01 16y ago
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.
34.
by cx01 16y ago
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 handle
35.
by cx01 16y ago
Transactions ARE durable if you use replication.
36.
by cx01 16y ago
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.
37.
by cx01 16y ago
Why do you think it is blogspam? You can also read the H-Store papers if you're interested in the details.
38.
by cx01 16y ago
In-memory doesn't imply "unreliable". If you need high-availability you'll want to use replication anyway.
39.
by cx01 16y ago
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.
40.
VoltDB (highly scalable SQL database) now available for download (GPL)(community.voltdb.com)
12 points by cx01 16y ago|0 comments
41.
by cx01 16y ago
It also took me some time to find the prices. They're on the lower right corner of the frontpage.
42.
by cx01 16y ago
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
43.
by cx01 16y ago
A phpBB-like forum would be great. I think you should just go ahead and start it. I'd use it.
44.
by cx01 16y ago
Keep in mind that VoltDB targets the OLTP market, where datasets tend to be not that large. If you build a small cluster of 50 nodes with 256GB RAM each, you have about 4.3TB of storage (with a replication factor of 3).
45.
by cx01 16y ago
In that case there will need to be some kind of locking, which is probably the reason the whitepaper recommends avoiding transactions that span multiple servers: "For multi-partition transactions, one engine distributes and coordinates work
46.
by cx01 16y ago
It seems that it's single-threaded, so all writes will be serialized, hence no locking.
47.
by cx01 16y ago
From the FAQ: "Durability: VoltDB provides both replication of partitions (known as K-safety) and periodic database snapshots to ensure the availability of the data."
48.
by cx01 16y ago
Agreed. I think this is an area where we're going to see a lot of competition in the next years so prices should go down quickly.
49.
by cx01 16y ago
They don't use quorums. So I guess there will always be 2 replicas and in the case of failure a (Zookeeper-like) master will reconfigure the system.
50.
by cx01 17y ago
The case that I have to retry indefinitely will only occur when the partition is permanent. And in that case an eventually consistent system will not help either, because clients will not see the writes (as long as the partition exists), so
51.
by cx01 17y ago
The problem is: If a node performs a write in an eventually-consistent data-store, the write will not be visible immediately. Alternatively (in a strongly consistent data-store) the node could just retry the write until it succeeds. From th
52.
by cx01 17y ago
Paxos (which you'll probably use to implement a strongly consistent distributed system) allows nodes to reach consensus as long as a majority of them are able to talk to each other. So if a partition includes a majority of nodes, this parti
53.
by cx01 17y ago
You do not copy data to all servers; in practice you may choose a replication degree of 3, so all data is written to 3 servers. In chain replication the first server in the chain will decide on the order of writes (i.e. he will serialize th
54.
by cx01 17y ago
I know. I actually explained this not too long ago here: http://news.ycombinator.com/item?id=1191003 But what I'm saying here is: You cannot have ACID transactions without the C in CAP.
55.
by cx01 17y ago
ACID transactions require consistency (C in CAP) in order to guarantee atomicity. So if you ditch C, you'll just be unable to perform transactions at all. In general, weakening the consistency guarantees is not done to improve scalability,
56.
by cx01 17y ago
There's a link on his twitter that still seems to work: http://blog.cubeofm.com/private/miEcmBmtdd
57.
by cx01 17y ago
If you want to partition (shard) your data, then this will work roughly the same in MySQL and Redis. But this article is only about partition tolerance. Neither MySQL nor Redis are inherently distributed, so it's not possible to generally s
58.
by cx01 17y ago
> Notice it says "... committed transactions are visible to all future transactions (consistent), ..." > This is not correct because the data can be overwritten by a subsequent transaction. It seems the paper is completely wrong her
59.
by cx01 17y ago
Read the comment by "strlen". Partitioning and network partitions are two totally different things.
60.
by cx01 17y ago
> If you're "promoting" slaves in the case of a master failing, you're again back to the case of eventual consistency. I don't think so. If you use asynchronous replication and the master fails directly after acknowledging a new request

More ›