Alaric Snell-Pym › Comments

"submitted by reddit to blog." - Alaric Snell-Pym

"I'm a Chicken user. I want to write applications; as I see it, there are Schemes that are good for embedding, and Schemes that are good for learning Scheme on, Schemes that are good for learning to implement Scheme with (eg, write your own tiny one!), and schemes that are good for apps. I've never looked for one that's good for learning on, but from where I stand, Chicken wins for apps, Chibi wins for embedding, and Guile wins when you need both and don't have any problems with the GPL. Why's Chicken good for apps? Well, others have listed the main reasons, but the ones that matter to me are compiling to actual executables, good integration with Unix interfaces, the wide range of eggs available, and the lovely community." - Alaric Snell-Pym

"The fun peer to peer stuff isn't too bothered about well-known ports, though. Bittorrent, N2N (my VPN of choice) and so on all involve the client getting whatever point they can, and advertising that into a registry. Both of them could run fine over SOCKS if it had better support for listening sockets, which is something I propose fixing." - Alaric Snell-Pym

"The fun peer to peer stuff isn't too bothered about well-known ports, though. Bittorrent, N2N (my VPN of choice) and so on all involve the client getting whatever point they can, and advertising that into a registry. Both of them could run fine over SOCKS if it had better support for listening sockets, which is something I propose fixing." - Alaric Snell-Pym

"(original author here) What I'm saying is: * For client access, the NATv4 versus IPv6 fight is still being won by NATv4 - and, I think, always will be. * But NAT sucks due to timeouts and no incoming connections (and a few other minor details). * SOCKS does the same basic job as NAT, but fixes the problems with it, and can help with IPv6 adoption by proxying between v4 and v6 worlds transparently * So, given that we're otherwise stuck with NAT, why not bring SOCKS up to date and get it competing with NAT? As for complexity - SOCKS5 is a dead simple protocol, and even my proposed improvements don't add much complexity. And I think it's simpler to implement, manage, and use than the IPv6 stack. Oh, and SOCKS would make my machines reachable more easily than NAT - SOCKS lets apps ask for listening sockets (although I propose improving its support for that)" - Alaric Snell-Pym

"(original author here) What I'm saying is: * For client access, the NATv4 versus IPv6 fight is still being won by NATv4 - and, I think, always will be. * But NAT sucks due to timeouts and no incoming connections (and a few other minor details). * SOCKS does the same basic job as NAT, but fixes the problems with it, and can help with IPv6 adoption by proxying between v4 and v6 worlds transparently * So, given that we're otherwise stuck with NAT, why not bring SOCKS up to date and get it competing with NAT? As for complexity - SOCKS5 is a dead simple protocol, and even my proposed improvements don't add much complexity. And I think it's simpler to implement, manage, and use than the IPv6 stack. Oh, and SOCKS would make my machines reachable more easily than NAT - SOCKS lets apps ask for listening sockets (although I propose improving its support for that)" - Alaric Snell-Pym

";-)" - Alaric Snell-Pym

";-)" - Alaric Snell-Pym

"Sharding doesn't prevent joining, it just makes it a little harder to do efficiently, as you need to fetch the records you're joining from other servers. A naive implementation is to ignore the sharding, and fetch records from servers as needed, and implement a standard join function on top. This hurts as the remote fetch latency ends up in your inner loops. Or you can be cleverer, and figure out blocks of records you'll need in advance, and fetch them en masse from the servers that hold them. Distributed joins, as they are known, are well studied in CS: http://www.lmgtfy.com/... However, lots of people think that sharding = NO JOINS, because their exposure to sharding has purely been "making your apps talk to lots of MySQL servers based on some binning function" - and of course MySQL doesn't let you join against a table on a remote server unless you set up table federation. But there's more to database sharding than that particular quick hack." - Alaric Snell-Pym

"Sharding doesn't prevent joining, it just makes it a little harder to do efficiently, as you need to fetch the records you're joining from other servers. A naive implementation is to ignore the sharding, and fetch records from servers as needed, and implement a standard join function on top. This hurts as the remote fetch latency ends up in your inner loops. Or you can be cleverer, and figure out blocks of records you'll need in advance, and fetch them en masse from the servers that hold them. Distributed joins, as they are known, are well studied in CS: http://www.lmgtfy.com/... However, lots of people think that sharding = NO JOINS, because their exposure to sharding has purely been "making your apps talk to lots of MySQL servers based on some binning function" - and of course MySQL doesn't let you join against a table on a remote server unless you set up table federation. But there's more to database sharding than that particular quick hack." - Alaric Snell-Pym

"Not really... what have joins got to do with replication? If you have full replication, then you can do any conceivable query - joins or whatever - on a local replica. That query won't be made magically faster, but you can do more of those queries at once by spreading them across the servers, which is what matters in a Web OLTP environment. Sharding is a little trickier, sure - but that just makes it more interesting. It's the updates that are the harder part. "UPDATE foo SET bar = bar + 1 WHERE ..." is an awkward kind of update to get right in a distributed system. There are two approaches to providing it: 1) Provide less. Subset SQL. Support all of SELECT, but limit UPDATE to have WHERE clauses of the form "<unique key> = <value>", or limit the SET clauses to "<field> = <constant expression>", or both, depending on your limits. 2) Use clever algorithms like optimistic transactions. Which may be tricky to understand and implement - but that's the job of the database developer, who is..." - Alaric Snell-Pym

"Not really... what have joins got to do with replication? If you have full replication, then you can do any conceivable query - joins or whatever - on a local replica. That query won't be made magically faster, but you can do more of those queries at once by spreading them across the servers, which is what matters in a Web OLTP environment. Sharding is a little trickier, sure - but that just makes it more interesting. It's the updates that are the harder part. "UPDATE foo SET bar = bar + 1 WHERE ..." is an awkward kind of update to get right in a distributed system. There are two approaches to providing it: 1) Provide less. Subset SQL. Support all of SELECT, but limit UPDATE to have WHERE clauses of the form "<unique key> = <value>", or limit the SET clauses to "<field> = <constant expression>", or both, depending on your limits. 2) Use clever algorithms like optimistic transactions. Which may be tricky to understand and implement - but that's the job of the database developer, who is..." - Alaric Snell-Pym

"Hilarious!" - Alaric Snell-Pym

"Hilarious!" - Alaric Snell-Pym

"Hilarious!" - Alaric Snell-Pym

"Hilarious!" - Alaric Snell-Pym

"Try finding the shortest paths from your least favourite politicians to your most favourite derogatory terms!" - Alaric Snell-Pym

"Try finding the shortest paths from your least favourite politicians to your most favourite derogatory terms!" - Alaric Snell-Pym

"Try finding the shortest paths from your least favourite politicians to your most favourite derogatory terms!" - Alaric Snell-Pym

"Try finding the shortest paths from your least favourite politicians to your most favourite derogatory terms!" - Alaric Snell-Pym

"Another use that came up as a comment on the blog post is that you could use it to enforce a *stricter* dialect of SQL, in particular by ensuring that SELECTs with no specific sort order defined return things in truly random order, so that you can catch subtle bugs in queries that will work most of the time but make an invalid assumption." - Alaric Snell-Pym

"Another use that came up as a comment on the blog post is that you could use it to enforce a *stricter* dialect of SQL, in particular by ensuring that SELECTs with no specific sort order defined return things in truly random order, so that you can catch subtle bugs in queries that will work most of the time but make an invalid assumption." - Alaric Snell-Pym

"Another use that came up as a comment on the blog post is that you could use it to enforce a *stricter* dialect of SQL, in particular by ensuring that SELECTs with no specific sort order defined return things in truly random order, so that you can catch subtle bugs in queries that will work most of the time but make an invalid assumption." - Alaric Snell-Pym

"Another use that came up as a comment on the blog post is that you could use it to enforce a *stricter* dialect of SQL, in particular by ensuring that SELECTs with no specific sort order defined return things in truly random order, so that you can catch subtle bugs in queries that will work most of the time but make an invalid assumption." - Alaric Snell-Pym

"Another use that came up as a comment on the blog post is that you could use it to enforce a *stricter* dialect of SQL, in particular by ensuring that SELECTs with no specific sort order defined return things in truly random order, so that you can catch subtle bugs in queries that will work most of the time but make an invalid assumption." - Alaric Snell-Pym