81 karma · joined August 21, 2011
Databases have inherent locking problems that takes more resources to resolve with more machines, more so in some database systems than others. When scaling you often hit a point where you get down to macro logistics, so imagine a car highway: You can get more throughput by adding more lanes. But what that all cars are going to merge to one lane at some point in the middle of the trip (because of a tunnel, bridge or something: it's impossible to have more than one lane at that point)? Now you won't get any throughput benefits of the multiple lanes after all! Just more latency because you get queues up until the single lane and because of the queues all cars are going slow and need to accelerate on the single lane, so the average speed is low too. You are also having too much resources after the single lane because you can never fill all those lanes. It might be better to have one beefed-up single-lane road all the way that people can go fast on. Basically: Remove locks and you get better overall performance.
Yes, this is on the expense of HA. Yes, the costs of scaling up grows asymptotically faster than the costs of scaling out. So this is definitely a trade-off in some sense.
I still believe I'm with the 25% that didn't prefer asynchronous messaging.
The number of significant digits on the Castille version is ridiculous compared to the others. Could it be that Castille still uses this unit and therefore have such a specific translation value?
I learned a lot by reading the source code for Python dicts (which also comes with a lengthy motivation for why it was implemented that way) and any Haskell library (Hackage links from the manual page directly to the source code for the respective function, which makes it very easy to see what is happening).
Tampering with the data, however, is not OK at all. In the U.S. I believe it may make the ISP exempt from for example the safe harbor clauses in the DMCA.
Are you sure? What if there's an infinite amount of tries to get to a certain number? You can of course reason about the average case, but maybe the worst case (when there's an input number which is never found by the PRNG) does never halt.
> O(rand)
For sorting algorithms we usually compare in the number of input elements. You can reason about the average case where the numbers are found in average time so you can consider the number of iterations to find the correct number a constant (a very large constant but a constant nonetheless).
But this web framework is much newer than PHP, isn't it? And this does not look better or easier than PHP: https://wiki.python.org/moin/CgiScripts
I'm not discussing headaches, I do nit particularly like PHP. My point is just that Python is not very easy to get started with for beginners.
Six days to take down the websites and start bugfixing is a lot of time for this kind of vulnerability.
How easy is it to make a safe client-side solution?
Do not do this.
I agree that the price was high, but not higher than for other phones in the same market segment (comparable hardware and such). The problem with the price is that it wasn't very attractive either. A new, untested phone 9 months from now, for the same price and with comparable hardware to currently existing phones.