alxv

The 35mm format is rather amazing balance of design trade-offs. No wonder it is so enduring.

It's large enough for the double-Gauss lens (a.k.a. normal prime lens) to have a nice shallow deep of field wide open. f/1.2 is close to the limit of a typical SLR mount. So a normal 50mm f/1.2 lens gets us 42mm of aperture. This means we can get the same depth of field and angle of view as a 6x7 medium format with a 110mm f/2.8 lens or a 4x5 large format with a 180mm f/4.5 (but with a much smaller system!) And we get a faster lens as a bonus.

Smaller formats lose some of that versatility of composition. The focal length of the normal lens on APS-C is 32mm. We would need f/0.8 lens to the same DOF. That's not possible on an SLR mount. Mirrorless systems with their shorter flange distances could get us there. But even then there are limits to how short the flange can be because image sensors become much less efficient as the angle of incidence of the light hitting them increases.

You only need 2 processors, since each cores gives you 2 vCPUs. "For the n1 series of machine types, a virtual CPU is implemented as a single hardware hyper-thread" --https://cloud.google.com/compute/docs/machine-types

You are missing a crucial piece here to have consistent hashing: you also need hash the names of the servers. With consistent hashing you hash both the names of the requests and of the servers, then you assign the request to the server with closest hash (under the modulus). With this scheme, you only need to remap 1/n of the keys (where n is the number of servers).

There is a proof shown in this handout: https://people.eecs.berkeley.edu/~sinclair/cs271/n15.pdf

It's hard to understand why this technique works so well without digging deep in the math. Roughly speaking, if you throw n balls in n bins at random, the maximum of number balls in any bins will grow surprisingly quickly (because of the birthday paradox). However, if we allow ourselves to choose between two random bins instead of one, and put the ball in the one with the fewest balls in it, the maximum number of balls in any bins grow much more slowly (i.e., O(ln ln n)). Hence, having that one extra random choice allows us to get surprisingly close to the optimal approach of comparing all bins (which would give us O(1)), without doing all that work.

The method is called "Power of Two Random Choices" (http://www.eecs.harvard.edu/~michaelm/postscripts/handbook20...). And the two-choices paradigm is widely applicable beyond load balancing. In particular, it applies to hash table design (e.g. cuckoo hashing) and cache eviction schemes (https://danluu.com/2choices-eviction/).

What happens when the number of servers changes? The cache hit rate would likely drop to zero until it warms up again, which is a good way to accidentally overload your systems.

Load balancing based on consistent hashing is the better way to implement this.

If your employer 401k plan allows it, you can roll over after-tax 401k contributions to a Roth IRA (a.k.a. mega-backdoor Roth IRA).

Sorry, it turns that was misunderstanding from my part. It turns out we cannot solve a board row by row without revisiting the previous rows. The board below is a counterexample:

  101
  010
  100

  solution #1:
  110
  100
  000

  solution #2:
  110
  110
  000

The move matrix M for all boards of size 3n + 2 appears to be singular. This means these boards may have no solution or a large number of solutions.

For every boards are two chessboard patterns we can solve for. For example, for a 3x3 board we can have:

  101        010
  010   or   101
  101        010

We can represent any N×N board as a N² vector. So, we can represent one of the chessboard pattern as:

  010
  101 = 010101010 = y
  010

  110
  111 = 110111010 = y0
  010

  (y - y0) = Mx

  1 + 1 = 0 (mod 2)
  0 + 1 = 1 (mod 2)

  110110000

  110110000
  111111000
  011011000
  110110110
  111111111 = M
  011011011
  000110110
  000111111
  000011011

  (y - y0) = Mx
  (010101010 - 110111010) = Mx
  100010000 = Mx
  111100100 = x   (by Gaussian elimination)

  111
  100
  100

Like Lights Out, this game can be solved using Gaussian elimination over Z/2 (integers modulo 2). This means the order of the tiles you press do not matter, and that you can solve the board by forming the desired pattern row by row.

During the winter, most fresh vegetables in Canada are imported from Mexico and the US. These are mostly breed for shelf life and usually bland. In the summer, local fruit and vegetable can be quite tasty if you know where to shop. The public markets of Montreal are very good (http://www.marchespublics-mtl.com/). You can also subscribe to get weekly organic baskets from local farms during the harvest season (http://www.paniersbio.org/en/).

On the other hand, the bland stuff doesn't poison you as much with lead.

http://www.environmentalhealthnews.org/ehs/news/lead-in-vine...

In the U.S., Californian olive oils are your best bet. Otherwise, Costco Kirkland Signature olive oil (which is now Greek oil [1]) is another good choice.

Outside of Italy, it's difficult to find Italian olive oils that are not blended. The 2014 and 2015 harvest seasons have been terrible due a bacterial blight [2] that crippled many olive farms in Southern Italy.

[1] http://www.seattletimes.com/business/retail/costco-embraces-...

[2] https://en.wikipedia.org/wiki/Xylella_fastidiosa

Previous discussion: https://news.ycombinator.com/item?id=10330280

"Don't be evil" is still included in Google's code of conduct.

https://investor.google.com/corporate/google-code-of-conduct...

There is a very succinct implementation of Algorithm X in Python that uses a variation of the Dancing Links approach.

http://www.cs.mcgill.ca/~aassaf9/python/algorithm_x.html

http://www.cs.mcgill.ca/~aassaf9/python/sudoku.txt

Google runs a company-wide disaster recovery testing event every year. Earthquakes are among the numerous scenarios simulated.

https://queue.acm.org/detail.cfm?id=2371516

That's with resources cached. HTTP Status 304 means the resource was not modified, and thus can be retrieved from the local cache.

A/A tests (also known as Null tests) are useful to validate that users are assigned to the control and experiment groups without bias.

Offline resampling methods, like bootstrapping, are better if you're looking to robustly estimate the variance of the experiment.

You can read the article if you come from a Google search.

http://www.google.com/url?q=http%3A%2F%2Fwww.medscape.com%2F...

By that logic, why consumers should pay anything to ISPs? ISPs don't have obligations to sign free peering agreements to CDNs or other large network owners, like Netflix, if it isn't advantageous to them.

Large network owners agree to peer without charges when it is mutually beneficial. That usually boils down to whether the traffic exchanged between the two networks will be roughly balanced and managed reliably.

One of the issue here is that Netflix doesn't operate an Internet backbone. Therefore, ISPs can't use Netflix's network to exchange traffic across the wider Internet. So this leaves the ISPs two choices here:

1) Agree to a free peering agreement with Netflix and build more capacity in their network at the ISP's expense to support Netflix's egress traffic; 2) Request Netflix to sign a paid peering agreement to support the construction and maintenance of the needed extra network capacity.

ISPs who opt for the first choice believe that improving their access to Netflix will make their customers happy and thus allow them grow their business. The other ISPs who opt for the latter choice believe, on the other hands, don't see the free peering as an investment; they want rather to extract more money from their existing customers. So, it is not that surprising to see the incumbent ISPs, who have locked-in their users already and killed-off most of the competition, going against free peering.

That said, I just can't wait to see Google Fiber kick the behinds of these greedy fools.

Oh right... because putting your critical secret information into a huge, buggy, extensible, unaudited, complex, and constantly changing operating system is so much better!

Space would be a terrible environment for building a datacenter. The main goals of a datacenter is to make computation as cheap, as fast and as reliable as possible. Having the datacenter orbit around Earth would not help us accomplish any of these goals.

First off, building a datacenter in space would not be cheap. It costs around $25,000 to send a kilogram of equipment into a geostationary orbit. [1] So let assume we were to use Dell PowerEdge C1100. Each server costs $14,000 and weights 18kg. [2] This means for each server sent in orbit, you could buy 32 extra ones on Earth.

Then, there is the issue of cooling. Although outer space is really cold, its vacuum prevents the heat generated by the machines from being dissipated quickly. Controlling the temperature of a such datacenter would be a very interesting engineering challenge.

And then how would you power this datacenter? Converting the excess heat back into electricity could be an interesting option. But most likely, it would need a lot of solar panels. This would make the datacenter cheap to run once built, but the upfront costs would be enormous.

And we haven't talked about speed and reliability yet. Since the signal would need to travel about 35,000 km from the geostationary orbit to reach us, communications between Earth and the datacenter would have significant delays. Even at the speed of light, the minimum round trip time would be about 250 milliseconds if we ignore all other possible sources of delay.

The hostile space weather would also make it pretty hard to run servers reliability. Radiations would destroy electronics, caused bit to flip randomly and do all bunch of fun stuff to the equipment.

But... anyhow! Let's assume anyway that by some magical work of science and Google engineering, we figure ways to manufacture a datacenter directly space for almost nothing by mining the Moon, discover some amazing thermoelectric generators with near 100% efficiency and space shields that blocks almost all radiations.

So back our previous example, a high performance PowerEdge gives us up to about 300 GFLOPS of computing power, 192 GB of RAM and 12 TB of storage.

Now if we were to convert the total mass of the Moon (7.34767309 × 10²² kg) into one monstrous datacenter, this would give us about 4.0 × 10²¹ servers. It would gives us a whooping 1.2 billions YottaFLOPS (or put differently, 1.2 × 10³³ FLOPS) of compute madness, 0.8 billions YottaBytes and 49 billions YottaBytes of storage. This monster would consume about the equivalent of 1% of the Sun's total power output.

[1] http://www.futron.com/upload/wysiwyg/Resources/Whitepapers/S... [2]: http://www.dell.com/us/enterprise/p/poweredge-c1100/pd#TechS...

His query took 65 milliseconds, not 65 seconds, which is totally reasonable.

There is a way to harden pickle to protect it against the most basic exploits: http://docs.python.org/py3k/library/pickle.html#restricting-...

It is not a complete solution, as an attacker could still DoS your service by making pickle allocate a huge amount of memory, but at least that's better than allowing arbitrary code execution.

> Somebody said once the ultimate app would help people get laid.

I've first heard that from an old jwz rant.

http://www.jwz.org/doc/groupware.html

> Create a random board configuration. Exhaustively explore the search space to find whether this is a win +1, lose -1, or draw 0 for Player 1

Given that the search space can grow O(4^mn), this can be done only for endgame configurations. Further, not knowing any bounds on the board size makes the input representation difficult to define for a such machine learning approach. And, your target should probably be the weights of an evaluation function, rather than the exact game outcome.

As for the learning algorithm, I know TD-learning was found to be a good approach in various chess programs.

> For each possible move, use the neural network to predict the outcome of that move. Pick the move with highest expected outcome.

You would likely still want to run an alpha-beta search to pick the move to minimize the prediction error.

But how do you get the malware on the servers? Most malware spread by tricking unsophisticated users into install them. It is much harder to trick a system administrator to so. Exploiting a vulnerable public facing service is the alternative. However, that option is out of reach to all but the most dedicated attackers, assuming you keep the system updated.

I've found the video of him saying that at StartupSchool

http://www.justin.tv/startupschool/b/298808358

Seek at 9:30.

Well, they are probabilistic machines then! ;-)