jdonahue

> pay a lot in ATM fees

If you use ATMs with any frequency, you need to get a free checking account and debit card with a bank* that will refund your ATM fees each month. Once you have one, the higher the ATM fee, the better you feel.

(*I use Schwab, particularly because it refunds ATM fees internationally. In general, just about any online bank -- e.g., Ally -- will also refund fees at least domestically. Many credit unions probably do this as well.)

Marketing? A sane password policy doesn't get you to #2 on HN.

I hadn't seen the detailed documentation - thanks so much for the acknowledgments there!

And thanks for correcting me about CCV's support for custom architectures and training -- I'd just assumed that it wasn't supported since it wasn't mentioned in the post, but I guess this was more of a marketing decision as most users are probably just interested in feature extraction/classification from the pretrained net. :) I would argue that GPU support is pretty necessary for training modern network architectures a la Krizhevsky to be remotely practical, though.

I apologize if I came off as overly competitive or derisive, this is obviously very nice work and it seems like an attractive option for many users. Always happy to see deep learning made more accessible and open!

As a user of and contributor to Caffe [1], I have to take the opportunity to plug it here. Like the CCV classifier linked, Caffe is fully open-source [2], has a downloadable state-of-the-art model pre-trained on ImageNet [3], and scripts/documentation that make it very easy to compute features using our pre-trained model or other models [4].

Unlike the linked CCV release (unless I'm misinformed -- haven't actually tried it, please correct me if I say anything inaccurate), Caffe supports completely customizable architectures via a configuration language, fully supports training [5], finetuning [6], and inference (feature extraction/classification) in these customizable architectures, and seamlessly runs on both CPU and GPU.

Caffe is also very fast; twice as fast at CPU feature computation as its predecessor DeCAF, and faster than cuda-convnet at training/testing ImageNet architectures on a Titan/K40 GPU.

The linked CCV release does mention Caffe, but quickly dismisses it due to the license. It's true that our pre-trained model [3] is licensed only for non-commercial use, but ALL of the Caffe code is BSD-licensed, including the exact script we used to train said model. So if you're a commercial entity, using Caffe for feature extraction/classification from a state-of-the-art network is a matter of purchasing a $1000 GPU (NVIDIA Titan -- I'm assuming you own a computer), downloading the ImageNet dataset, and waiting about a week for training to converge. This will buy you the ability to adapt the classifier to YOUR visual classification problem by finetuning [6], rather than being stuck with the particular 1000 categories the pre-trained model knows about.

[1] http://caffe.berkeleyvision.org/

[2] https://github.com/BVLC/caffe

[3] http://caffe.berkeleyvision.org/getting_pretrained_models.ht...

[4] http://nbviewer.ipython.org/github/BVLC/caffe/blob/master/ex...

[5] http://caffe.berkeleyvision.org/imagenet_training.html

[6] http://caffe.berkeleyvision.org/caffe-presentation.pdf (see page 14)

Thanks for the DeCAF plug! Here's a demo of the classifier with the pre-trained ImageNet weights in action: http://decaf.berkeleyvision.org/

I also have to take the opportunity to plug Caffe [1] - Yangqing's replacement for DeCAF which he actually open sourced just a few hours ago. All the heavy processing (e.g., forward/backprop) can be run either on your (CUDA-enabled) GPU or on the CPU, and the GPU implementation is actually a bit faster than cuda-convnet. The entire core is (imo) very well-engineered and written in clean lovely C++, but it also comes with Python and Matlab wrappers. I've personally been hacking around inside the core for about a month and it has really been a pleasure to work with.

[1] http://daggerfs.com/caffe/

> The passphrase can be brute-forced significantly more easily than breaking the encryption itself. Furthermore, as xkcd so accurately pointed out, a hostile government will throw you in prison (or, worse, hit you repeatedly with a wrench) until you divulge your passphrase and data.

Not to detract from the point of your post, but for anyone interested, that's what TrueCrypt's 'plausible deniability' feature [1] is for. It can be used to create a hidden volume on your hard drive with a different password from your main volume, so if you're ever forced to give up the disk passphrase by a government agency or anyone else, you can give them the password to the hidden volume, and (in theory) you'll appear to be fully cooperating. It is impossible (short of cracking the main volume passphrase through brute force) to prove, given only the passphrase to the hidden volume, that the main volume exists. Ideally, you'd probably want to put something "embarrassing" but legal on the hidden volume (e.g., gay porn), to make the "plausible deniability" for using full disk encryption more "plausible".

[1] http://www.truecrypt.org/docs/?s=plausible-deniability

I don't know about a "few minutes", but spending a couple hours putting together some type of system for automatically installing your system configuration is SO worth it - probably one of the most frustration-saving investments of your time imaginable as a developer, if you haven't done it already.

After years of being frustrated at my configuration being different on every system because I was too lazy to invest a little bit of time into doing something like this, I wrote a small Python script that creates all the config files I use (zshrc, tmux.conf, etc.) - it concatenates the 'generic' piece of each config file with an OS-specific part (for Linux/Mac-specific setup) and a host-specific part (for system-specific setup) and writes the concatenated file to my home directory. There are probably much better solutions out there than rolling your own script to do this, but I like it because I know exactly what it does and how to add features myself when I need them.

Now when I start using a new system, I just do 'git pull' and 'make all'. It's extremely satisfying how with this type of setup, in seconds, a brand new system feels exactly like the ones I've been using for months/years.

Ah, providing it at the terminal level does make more sense (that was probably obvious to anyone with any familiarity with the basics of Unix terminals, sorry), and now that I hear it I'm not surprised it already exists :)

In that case, I guess this functionality would be implemented similarly to the example you mentioned of stopping the client from sending every keystroke at a password prompt, right? It seems like it would be strange for ssh to send the 'toggle echo' signals to the client, but not the 'toggle canonical mode' signals (which the client could also handle in a useful way).

I think it would be neat if SSH provided an API or a set of special characters so that the remote shell could tell SSH to switch back and forth between remote and local echo. For example, bash could tell SSH to begin local echo mode after it finishes printing the prompt, and end local echo mode when the user enters a key sequence that requires remote processing, like Tab or Return. vim could enter local echo mode when the user enters insert mode and leave when the user presses the Esc or Return, etc.

Perhaps this extra complexity would lead to all sorts of strange bugs though.

> I don't. I simply play the first result that youtube returns.

I had thought of a similar idea to what this website does (using song metadata from a cleaned source like Spotify and then play the song through YouTube).

The way I'd imagined doing the song to YouTube mapping was through crowdsourcing - you could rank the YouTube results for each song based on number of listens and votes on your website. By default you would play the top ranked video for a song, but allow users to see alternate video links (probably hidden behind menus) and play those instead if they want (or if they have accounts, you could allow users to individually mark a video as being their preference for a particular song, etc.), probably also incorporating these plays into your ranking. You could also use crowdsourcing for further metadata about the video - e.g., some music videos have long intros/outros that you wouldn't necessarily want to hear when you're just listening to music, so you could allow people to submit and vote on start/end times for the 'song' part of the music video.

Anyway, I really like the interface! It's much cleaner than any other attempt at this I've seen.

Edit: I missed your mention of crowdsourcing at the end of your post, whoops - sounds like you've probably already thought of most/all the ideas in this post :)

Why? What you copy-pasted makes no claim of causation (e.g., it does not say anything like "if you sleep 6.5 to 7.5 hours a night, you will be happier"); you just chose to read it that way.

Agreed. And this might be just me, but I greatly prefer talking on a computer (laptop or desktop) to holding a phone in my hand up to my ear. Especially for long personal calls or calls to businesses where I know I'll probably be on hold forever (e.g. Comcast) - it is INSANELY handy for that. Speaker phone would probably accomplish something similar but the audio quality in and out is lower on my phone than on my laptop, and it also (like you said) uses minutes. The calls are also more reliable in my experience - I've never had a call dropped or had the audio cut out over Gmail on a good WiFi connection.

From a 'security' perspective, this seems like an objectively good thing to me. If having this data publicly available is a good thing, then this map is a good thing - the more exposure, the better. If it's a bad thing, then the higher exposure resulting from this makes it more likely that a change in policy will happen.

The status quo (prior to the publication of this map) was that the information is publicly available but only a few people were aware of it. I can't imagine any argument for that being the optimal situation.

> As a Netflix subscriber, I'd rather see them signing more non-exclusive deals than fewer exclusive deals.

It seems like a deal like this would be more intended to attract customers of competing services than appease current subscribers (many of whom are overwhelmingly likely to resubscribe by default month after month). I could easily imagine people switching from <Amazon/Hulu/some 2016 subscription service> to Netflix because the former no longer has Disney content and the latter does.

I agree with you on Disney though - I don't really see the logic in it on their part, unless they foresee Netflix being enough of a monopoly in 2016 (possibly due in significant part to this deal itself - maybe they even expect other media titans to join in) that the sales from all competing services combined over whatever time period the deal covers would be less than the lump sum Netflix offered.