I started enjoying Netflix more when I realized I shouldn't be looking for stuff I knew of from elsewhere, but rather explore titles, rate, and help their algorithm to suggest things to me. Has been working out well so far - I got into an area I didn't think I was interested so far (superhero series).

Likely they're holding their cards close to the chest as it's a competitive market.

Historically they've been very open about their tools, though, even open-sourcing a lot of them.

Not to say this can't be the exception, just that it does seem a little out of character.

That makes no sense. ML agos are not something that you can steal from the competition, much less copy it by reading a blog post.

My 2 cents: many file systems do not have a file locking feature that can enforce file locking. In unix-like systems, file locks (e.g., lockf(3)) are "advisory" rather than mandatory, meaning it's up to the higher-layer apps to check whether another program has locked a file and voluntarily stop.

Any apps that do implement this feature likely do so by making the original file read-only and having the first app that opens the file work on a copy. However, I think Windows may have a mandatory file locking mechanism.

Congrats Navneet, Mehul, & team!

Speed is one concern but far from the main reason. You couldn't use a typical-length RSA key to encrypt a large chunk of data because there's a max input size for any given RSA key size. Standard block/stream cipher modes of operation are defined only for symmetric key ciphers.

You can certainly use RSA as a block cypher, you are just limited in the size of the blocks.

The max input size is for one message. It's effectively the "block size" for RSA. You can send multiple messages using a single RSA key (and in fact pretty much everyone does that, otherwise you'd need a new public key for every message). RSA is a complete crypto system, you don't need any additional ciphers. You do need randomiziation (e.g. random padding).

For the sake of completeness, one such construction where RSA is used as a cipher is OAEP (Optimal Asymmetric Encryption Padding). Beyond being slow it has some other inefficiencies but that's another story.

alt+. does the same thing as well, and is slightly easier to type.

Speaking for the Bay area, public transportation here is shockingly bad, even for something as routine as getting to the airport. For someone living in the valley to get to SFO (about 40 miles), a taxi can cost anywhere from $50-$80, and the public transportation alternative takes anything between 2-2.5 hours, 1 bus, 3 trains, some distance walking with your luggage, and about 15 bucks. Oh, I forgot to mention that trains are once an hour, and there are a total of 3 distinct operators for the bus and train systems who are totally uncoordinated with each other.

Not surprisingly, most people who value their time prefer making a 35-minute drive at their convenience, and paying about $12-$18 per day of parking.

For HTTP clients and servers, I've not had too much trouble with cpp-netlib. It's heavily boost-based, and it uses Boost::Asio for concurrency and SSL handling, but if you're familiar with Boost, you can be up and running in no time. IIRC, this library is considered for official inclusion to Boost as well. I use cpp-netlib + RapidJSON for my REST API handling needs.

http://cpp-netlib.org/0.9.4/index.html

https://code.google.com/p/rapidjson/

I have no recommendations for writing REST services, however.

Looking at the source, it looks like this lib uses boost:asio on non windows platforms.

Which book did you get? Curious to find out what's in it.

> ... so disadvantageous in an evolutionary sense? Environmental factors (such as staring at a computer screen...)

Well if you're arguing that it's a nurture thing, there are plenty of us who had bad vision at childhood, right from before the dawn of the computer age. You could say that it was not computer screens but books that caused it, but how far back can you make this argument? Any sources for this claim?

Well, I did too--I started wearing glasses at around age 4. Books and TV would certainly contribute as well--as I understand it, "nearpoint stress" is the main cause of myopia. The eyes are tuned for scanning the horizon for faraway threats; we're naturally more far-sighted. Focusing your eyes closely causes strain, where your eye muscles must contract the lens constantly. Your eyes accomodate this stress by keeping the lens in a contracted position, and by lengthening the eye.

Oops--I forgot the book. It was this: http://www.amazon.com/Improve-Vision-Without-Glasses-Contact...

(though mine has a more modern looking cover, I guess I have a newer edition?)

> I wonder if the C implementation is much faster

Very likely -- Run this on your machine and see if it improves things http://stackoverflow.com/a/9781943. I got about 18.6s for your python code while this one with a 16 byte salt and 250k iterations runs in 0.6s.

OWASP recommends over 100k iterations too: https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet...

True, looks like it's important to use a C module if available:

In [13]: from M2Crypto.EVP import pbkdf2

In [14]: %time pbkdf2('mypassword', open('/dev/urandom').read(16), 250000, 32) CPU times: user 1.16 s, sys: 0.02 s, total: 1.18 s Wall time: 1.18 s

I may not understand the whole context, but if you're using PBKDF2 for key derivation, you don't want to use something that works "fast". You want whatever algorithm/iteration combination that is as slow as possible [1], but not too slow that it annoys the user.

[1] on modern hardware, that is.

The kdf should be as slow as possible for an attacker but fast enough for you. If you're using python and the attacker is using C, you can increase security with no usability loss by switching to C and raising the iteration count.

Using a slow implementation of PBKDF2 is not going to slow down attackers who use a fast implementation.

Correct. I didn't mean slow implementation, I meant slow enough on modern hardware using the fastest implementaiton.