Installing the TensorFlow Docker image for GPUs on Ubuntu 16.04

The process is actually quite easy, but the installation docs don’t provide the right hints. I found some posts online suggesting others had battled with this, so I share this here in case others get tripped up as well.

1. Install Docker. Create a docker group, add yourself to it, then log out and back in. Verify you can run the “hello docker” sample as yourself.
2. Run the TensorFlow GPU image:
$ docker run -it -p 8888:8888 gcr.io/tensorflow/tensorflow:latest-gpu
3. Visit http://172.17.0.1:8888 and verify you can execute the “hello tensorflow” samples. These will run without the GPU–you’ll see errors on the console about not finding the CUDA libraries. Close the docker instance.
4. Install the latest nvidia binary display driver for your system. The simplest way to do this is through the Software & Updates GUI, Additional Drivers. Select “using NVIDIA binary driver,” apply changes and restart. You can verify you’re running the nvidia display driver by running nvidia-settings from the command line.
5. Install CUDA. On 16.04 the easiest way to do this is directly from apt:
$ sudo apt-get install nvidia-cuda-dev nvidia-cuda-toolkit
6. Install cuDNN v4. This needs to be installed manually. See instructions here. (You need to register for an nvidia developer account).
7. Run the TensorFlow GPU image, but this time give it access to the CUDA devices located at /dev/nvidia*. The easiest way to do this is with a script. The one the TensorFlow docs reference doesn’t work with 16.04, so use mine.
8. Visit http://172.17.0.1:8888 again. This time when you run the samples you shouldn’t see any CUDA errors.

Mailing lists considered harmful

I often catch myself telling people how much I hate mailing lists. It’s usually around the point in the conversation when I realize they’re giving me the “you’re a crazy person” look.

Before you give me the same look, hear me out! How often have you said or heard:
  • Who’s on this list?
  • What is this list for?
  • Who should be on this list?
  • Should I be on this list?
  • Can you add me to this list?
  • What should we name this list?
  • Who do I talk to create this list?
  • How do I add someone to this list?
  • Can I get permission to add someone to this list?
  • Who has permission to add someone to this list?

Or the worst: “Sorry you missed that super important email–I assumed you were on that mailing list!”

The social dynamic mailing lists create bothers me the most. The inclusion felt by those on the list, the exclusion felt by those not on the list… Creating mailing lists are quick way to silo an organization.
But it’s not all bad. Mailing lists are nice when you have a very large number of people that you want to broadcast a message too. They’re great for one-way communication like announcements.
Is there a middle ground? I believe if organizations followed some simple guidelines they could derive benefits from mailing lists and avoid most of the negative side effects. If I was so bold as to propose some guidelines for adopting mailing lists, they would be something like the following:
  1. Don’t create mailing lists for small groups. I think a good rule of thumb is about 10 people starts to warrant a mailing list. Anything less than that and you can remember their names. If you can’t remember their names then don’t bother them with an email!
  2. Let anyone join your mailing lists. Don’t do “ask to join” or keep the mailing list a secret. If you’re tempted to share secret stuff on a mailing list you probably should be mailing people directly anyways.
  3. Let anyone read your mailing lists. Maintain a public, searchable archive for all of your mailing lists. If your IT administrator complains tell them it’s the 90’s–web indexes for mailing lists have been in existence since the beginning of the web.