Graham White: My Notes

<update on Sept 13th 2019>
I have written another post on how to install (rather than build) Tensorflow GPU for Fedora that uses a different and much simpler method.  See Installing Tensorflow GPU on Fedora Linux.
</update>

First off, let's say that there are easy ways of configuring Tensorflow for GPU usage such as using one of the docker images.  However, I'm a bit old school for some things and having always done so I've recently got Tensorflow going on my machine using my GPU.  Tensorflow CPU support is quite easy to do and generally works quite nicely using the pip install method.  GPU support, I've always found, is quite a bit more difficult as there are a whole bunch of things that need to be at just the right level for everything to work i.e. it's quite brittle!

What follows are my notes (it's in the name of the blog) for how to build Tensorflow from scratch to enable GPU support and I do this on Fedora Linux.  If you want to know why it's worth bothering going to this effort, I've tested the Keras MNIST CNN example as a bench mark.  It takes:

• 11 minutes 7 seconds on my CPU
• 2 minutes 55 seconds on my GPU

That's just over 3.8 as fast on my GPU as per my CPU so for large jobs this will be huge!

Some info on my machine and config:

• Lenovo P50 Laptop
• Intel Core i7-6820HQ CPU @ 2.70GHz (4 core with hyper threading)
• 32GB RAM
• Nvidia Quadro M1000M (CUDA compute capability 5.0)
• Fedora 28 running kernel 4.18.18-200.fc28.x86_64

Install Required Nvidia RPMs
You need to get everything Nvidia and CUDA installed on your machine first.   I quite like the Negativo17 repository for Nvidia on Fedora Linux and so I use this but you could also go with RPM Fusion or even download everything directly from Nvidia.  For me, right now, I have this little lot installed:
cuda-9.2.148.1-2.fc28.x86_64
cuda-cli-tools-9.2.148.1-2.fc28.x86_64
cuda-cublas-9.2.148.1-2.fc28.x86_64
cuda-cublas-devel-9.2.148.1-2.fc28.x86_64
cuda-cudart-9.2.148.1-2.fc28.x86_64
cuda-cudart-devel-9.2.148.1-2.fc28.x86_64
cuda-cudnn-7.2.1.38-1.fc28.x86_64
cuda-cudnn-devel-7.2.1.38-1.fc28.x86_64
cuda-cufft-9.2.148.1-2.fc28.x86_64
cuda-cufft-devel-9.2.148.1-2.fc28.x86_64
cuda-cupti-9.2.148.1-2.fc28.x86_64
cuda-cupti-devel-9.2.148.1-2.fc28.x86_64
cuda-curand-9.2.148.1-2.fc28.x86_64
cuda-curand-devel-9.2.148.1-2.fc28.x86_64
cuda-cusolver-9.2.148.1-2.fc28.x86_64
cuda-cusolver-devel-9.2.148.1-2.fc28.x86_64
cuda-cusparse-9.2.148.1-2.fc28.x86_64
cuda-cusparse-devel-9.2.148.1-2.fc28.x86_64
cuda-devel-9.2.148.1-2.fc28.x86_64
cuda-docs-9.2.148.1-2.fc28.noarch
cuda-gcc-7.3.0-1.fc28.x86_64
cuda-gcc-c++-7.3.0-1.fc28.x86_64
cuda-gcc-gfortran-7.3.0-1.fc28.x86_64
cuda-libs-9.2.148.1-2.fc28.x86_64
cuda-npp-9.2.148.1-2.fc28.x86_64
cuda-npp-devel-9.2.148.1-2.fc28.x86_64
cuda-nvgraph-9.2.148.1-2.fc28.x86_64
cuda-nvgraph-devel-9.2.148.1-2.fc28.x86_64
cuda-nvml-devel-9.2.148.1-2.fc28.x86_64
cuda-nvrtc-9.2.148.1-2.fc28.x86_64
cuda-nvrtc-devel-9.2.148.1-2.fc28.x86_64
cuda-nvtx-9.2.148.1-2.fc28.x86_64
cuda-nvtx-devel-9.2.148.1-2.fc28.x86_64
nvidia-driver-cuda-libs-410.73-4.fc28.x86_64

You might wonder about some of the above, particularly why you might need a back level version of GCC.  When Fedora 28 has a quite capable GCC version 8 why on earth would you want version 7?  The answer lies in my comment about things being difficult or brittle, it's quite simply that CUDA doesn't yet support GCC 8 so you do need a back level compiler for this

Install NVidia NCCL
This library isn't available through an RPM installation or the Negativo17 repository and so you must:

• Go to the Nvidia NCCL home page 
• Click the link to download NCCL (requires an Nvidia developer login account)
• Agree to the Terms and Conditions
• Download the NCCL zipped tar file that matches your CUDA version (9.2 for this blog post)

At the time of writing the file required is nccl_2.3.7-1+cuda9.2_x86_64.txz

I simply untar this file into /usr/local and create a symbolic link as follows:

• cd /usr/local
• sudo tar -xf /path/to/file/nccl_2.3.7-1+cuda9.2_x86_64.txz
• sudo ln -s nccl_2.3.7-1+cuda9.2_x86_64.txz nccl

Install the Bazel Build Tool
You're going to need a build tool called Bazel which isn't directly available in the Fedora repositories (that I know of at least) but fortunately there's a version in a copr repository you can use as documented run the following commands:

•  dnf copr enable vbatts/bazel
•  dnf install bazel

Get a Copy of Tensorflow Source
For this it's just as easy to use git as it is anything else.  You can directly clone the 1.12 release of Tensorflow into a new directory by running:

• git clone --single-branch -b r1.12 https://github.com/tensorflow/tensorflow tensorflow-r1.12
• cd tensorflow-r1.12

Simply replace r1.12 in the above commands if you want to use a different Tensorflow release.

Run the Tensorflow Configure Script
This step is actually quite simple but you'll need the answers to some questions to hand, simply run:

• ./configure

I accept all the default options with the exception of:

• "location of python" set to /usr/bin/python3 since Fedora still uses Python 2.7 as the default version at /usr/bin/python
• "build TensorFlow with CUDA support" set to Yes
• "CUDA SDK version" set to 9.2 (this value should match the cuda version you have installed and at the time of writing 9.2 is the current version from the Negativo17 repository)
• "location where CUDA 9.2 toolkit is installed" set to /usr
• "cuDNN version" set to 7.2 (similar to the cuda version above, this value should match the cuda-cudnn package version and 7.2 is the current version from the Negativo17 repository)
• "NCCL version" set to 2.3
• "location where NCCL 2 library is installed" set to /usr/local/nccl
• "Cuda compute capabilities you want to build with" set to 5.0 (but this value should match the CUDA compute capability of the GPU in the machine you're building for)
• "which gcc" set to /usr/bin/cuda-gcc (to use the back level GCC version 7)

I was recently working on a project in VueJS that needed an authorisation layer added to it.  It turns out there aren't any existing examples of how to do this anywhere, unusually not even on Stack Overflow.  So I set about writing one and thought I would share it.  My work was based upon some other useful examples and information, particularly a blog post from the IBM Cloud blog.

Before I go any further, the code samples are available and documented on GitHub as follows:

1. IBM App ID API Server
2. App ID VueJS Client

The code is deliberately split into two such that:

1. the API Server is used to demonstrate how to secure an API on the server side.  This is done with the WebAppStrategy of App ID which is simply an implementation of a strategy package for passportjs.  The code here isn't anything particularly new over existing examples you can find on the web but it's necessary in order to fully demonstrate the capabilities of the client code.
2. the VueJS Client is used to demonstrate two things:
1. how to secure a VueJS route for which I can currently find no example implementations on the web
2. how to call an API that has been secured by App ID by passing credentials through from the client application to the API server

The API Server should be relatively trivial to get up and running as it's a standard NodeJS API implementation using Express.  If you refer to the WebAppStrategy and the blog post I mention above then you'll see the sample code I've come up with is broadly the same i.e. an amalgamation of the two.

The VueJS Client code can be simple to get up and running as well but it's probably more important to understand how it was created such that you can apply the same principles in your own application(s).  For this then, the explanation is a little longer...

Start by running the VueJS command line client (cli) to create a bare project and for the sample to make sense you will need to add VueX and Router components using the tool:

vue create vue-client

Then understand the 3 modifications you need to make in order to have a working set of authenticated routes.

1. A store for state. 
It doesn't really matter how you achieve this in VueJS, you can use any form of local state storage.  The example code I have come up with uses VueX and a modification to the store.js code you get from the client above.  The idea of this is such that the client application can cache whether the user has already authenticated themselves.  If they have not then the client must request authentication via the server.  If they have, then all the credentials required for making an authenticated call to a server-side API are already available in the browser.  Essentially, this is a speed-up mechanism that stops the client from requesting client credentials on each API call since the session store for the authentication actually lives on the server side when using App ID.

2. A new VueJS Component
This is the component whose route is to be protected via authentication.  In the case of the example code below the standard vue cli "About" component has been used and modified slightly to include an authenticated call to the server API.  The thing to note here is that the credentials from the client side must be sent over to the server with each API call.  Using the fetch API as per the below to implement your GET request means you have to add the credentials: 'include' parameter.

<template>
  <div class="about">
    <h1>This is a protected page</h1>
    <h2>hello: {{ hello }}</h2>
  </div>
</template>

<script>
export default {
  data: function () {
    return {
      hello: undefined
    }
  },
  computed: {
    user () {
      return this.$store.state.user
    }
  },
  methods: {
    getProtectedAPI () {
      fetch('http://localhost:3000/protected/get-some-info',{
            credentials: 'include',
          }).then(res => res.text())
          .then(body => {
            console.dir(body)
            this.hello = JSON.parse(body).hello
          })
    },
  },
  created() {
    this.getProtectedAPI()
  }
} 

</script>

3. A VueJS Navigation Guard
You need to write a function that will be added as a VueJS middleware upon each route change.  The middleware is inserted automatically by the VueJS route code when using the beforeEnter call on a route.  This is known in VueJS as a Navigation Guard.

function requireAuth(to, from, next) {
  // Testing authentication state of the user
  if (!store.state.user.logged) {
    // Not sure if user is logged in yet, testing their login
    const isLoggedUrl = "http://localhost:3000/auth/logged"
    fetch(isLoggedUrl, {credentials: 'include'}).then(res => res.json()).then(isLogged => {
      if (isLogged.logged) {
        // User is already logged in, storing
        store.commit("setUser", isLogged)
        next()
      } else {
        // User is not logged in, redirecting to App ID
        window.location.href=`http://localhost:3000/auth/login?redirect=${to.fullPath}`
      }
    }).catch(e => {
      // TODO: do something sensible here so the user sees their login has failed
      console.log("Testing user login failed - D'oh!")
    })
  } else {
    // User already logged in
    next()
  }
}

The requireAuth function does the following in plain English:

1. Using the VueJS client side cache, test if the user is already logged in
2. If they are not. then ask the server if the user is already logged in
1. If they are not, then redirect them to the server login page
2. If they are, then cache the information and load the next piece of middleware
3. If they are, then simply load the next piece of middleware

Each route you want to protect with the above function must have a beforeEnter: requireAuth parameter specified on the route.  When this is done, VueJS will call the requireAuth function before the component specified by the route is loaded.

{
  path: '/protected',
  name: 'protected',
  beforeEnter: requireAuth,
  component: Protected
}

Note: there are methods by which you don't have do call window.location.href to redirect the user to the login page (which does seem like a bit of a nasty hack.  However, these methods require the modification of the webpack configuration and so were kept out of scope of this example for the purposes of being simple.

I've just finished a pretty extraordinary journey, both physically and mentally, here's the story...

The Short Version - 100 Miles, 4 Days, 2 Charities

This bit of the blog post is a summary for the TL;DR brigade...

• Starting in Eastbourne on 31st May
• More or less 4 marathons in 4 days
• Finishing in Winchester on 3rd June
• Raising funds for:
• The National Eczema Society
• Parkinson's UK
• You can still donate (please do):
• https://uk.virginmoneygiving.com/team/DadsbeingLads
• We raised over £4500 (more than £5500 including gift aid)

The Longer Version

My best mate decided he wanted to challenge himself as a consequence of coming to terms with his 40th birthday.  He called a few of us to the pub a few months back.  We settled on the idea of walking the South Downs Way in 4 days for 2 charities.  I was nuts enough to go along with this idea and I'm writing the morning after successfully finishing the entire route with him.

In the car on the way to get started...

...all done and in the restaurant at the finish

Much like moving bank account, it's not very often I move mobile network.  I tend to favour staying with the same provider unless they provide me with a good reason to leave.  My current network, TalkMobile, have just done so by completely shutting down their PAYG service and so are only able to offer me a contract (that I don't want) or a rubbish deal to move to Vodafone (they're a Vodafone MVNO).

I thought I'd write a similar post about my experience moving to the giffgaff network today to the one I wrote about Moving to TalkMobile back in 2012.  You'll see from that link that joining TalkMobile was extremely painful.  However, I'm happy to report I found the network very solid and reliable with what I can only presume is good coverage (there's always black spots, right?) on the Vodafone network.  Getting them to do anything was always painful as there's little option for self-service so it's more or less always a call to their support staff.  The staff are very polite and extremely helpful but the processes and presumably the systems they have to use seem somewhat antiquated today.

So in comparison to my previous blog post about moving to TalkMobile, moving to giffgaff went a bit like this:

Day 1 (yesterday)

1. Register a giffgaff SIM a friend gave me and create a new giffgaff account all in one simple guided wizard on the giffgaff web site
2. Request a PAC from TalkMobile
3. Go through the number transfer process via another simple wizard on the giffgaff web site

Day 2 (today)

1. Observe a short outage in mobile service as my number was transferred just after lunch
2. Happy customer

So now I'm looking forward to years of good service from giffgaff until they provide me with a good reason to leave some time in the future.

By the way, if you want to grab a giffgaff SIM then feel free to register via my referral link as we'll both get a free £5 credit if you do.

It's been a while, but true to our 4 year hardware refresh cycle, I've just received my latest laptop - a Lenovo P50.  I've been installing it with Fedora 25 since Friday and configuring and copying data over this weekend ready to swap laptops first thing this week.  I'm looking forward to trying out the new machine although I'm not quite sure why as the specs are barely different from the machine I was given 4 years ago.  It's certainly the best indication yet I've personally experienced of Moore's Law coming to a complete halt as well as many of the other specifications not improving a huge amount either.  The two most noticeable differences are likely to be the more powerful graphics chip and the inclusion of an SSD.  That said, there is twice as much RAM in this machine and I had upgraded my previous machine with an SSD as well so that particular upgrade isn't going to be noticeable for me at least.

My previous machine was a W530 and the one I had before that was a T61p (with a T41p before that) and so I'm well used to this particular line of Thinkpad laptops.

Here's the specifications of the machine I've got, as ever there are variants of the P50 so if you have one or are thinking of getting one the specifications could be a little different but will be broadly similar to this:

• Intel(R) Core(TM) i7-6820HQ CPU @ 2.70GHz (5433.79 bogomips in Linux)
• 32GB DDR4 2133MHz
• Samsung MZNLN512 (PM871) 512GB SSD
• 15.6" 1920 x 1080 IPS (non-touch)
• 6 Cell Battery
• Wireless A/C
• NVIDIA Quadro M1000M 4 GB
• Front Facing Web Cam, Mini Display Port, HDMI Out, Headphone, 4x USB3, Smart Card Reader, GBit Ethernet, Thunderbold, Fingerprint Reader

So looking at those and comparing in more detail to what I had before it seems my gut feeling was pretty good.  The CPU benchmarks are more-or-less exactly the same and certainly within tolerances of error as well as other performance increases that will effect the benchmarks such as the memory clock speed.  Here's the comparison between the W530 CPU and the P50 CPU:

The same can't be said of the GPU benchmarks though so it looks like GPUs are continuing to gain in power even when CPU speed increases have run out of steam:

Those of you that know me well will know I like Linux.  Don't get me wrong, there's a lot wrong with it and the community can be a pretty harsh place where more or less everyone has an opinion they think is the right one.  I don't get a lot of chance to contribute for various reasons but earlier this year I was (finally) accepted to be a package maintainer for the Fedora project.

Since I like Linux I do tend to use it on the desktop both at home and at work.  I do more or less everything with Linux and Open Source software including photo editing with GIMP.  It bugged me that Fedora ship a library called lensfun which is a library of lens correction data but the only piece of software using it within Fedora was Digikam.  Preferring GIMP I decided to set about packaging and supporting gimp-lensfun for Fedora.

Becoming a Fedora Package Maintainer is a well documented process as there are joining instructions and package review guidelines for the packaging guidelines.  Whilst well documented, there's a heck of a lot of stuff you have to read through and comply with before you can submit your first package review request.  This is further complicated by not yet having any reputation within the Fedora community and so you have to build this up in other ways before your package will be recognised and one of the senior community members agrees to sponsor you as a package maintainer.

I eventually raised my first package review request for gimp-lensfun in April 2013.  Over a period of a few weeks people throw rocks at what you've done according to the various guidelines that you either didn't see or forgot about.  This is actually really good and helpful as it ensures quality and consistency between all the new packages being accepted into Fedora.

What I wasn't prepared for was the length of the wait.  I know this isn't an earth shattering change to Fedora but it took me over 2 years to get noticed enough for my package to be accepted and for me to be sponsored as a Fedora packager.  I think I'd probably still be waiting now but I bugged a few people on IRC to point out my review request had been sitting there for so long.

Finally! My first package was released into the wild for Fedora 21 and 22 and I've been given the chance to give just a little back to the community.

I recently had the need to Wi-Fi enable a Raspberry Pi and so bought a D-Link DWA-131 Wireless USB Adapter.  I knew from something I'd read that it was a bit of a gamble in terms of whether it would be supported by the Pi under Raspian.  It turns out there are currently 3 revs of this adapter with different chipsets in each.  The one I got was the latest E1 version identified with the USB Device ID 2001:3319 that requires the realtek 8192eu driver.

Here's how to get it working under the September 2015 Raspian Jessie running Kernel 4.1.7+ for which I found some similar instructions a helpful starter:

1.  Get up to date and ready for compilation

sudo apt-get update
sudo apt-get upgrade
sudo apt-get install build-essential git


2. Grab the Driver Source

git clone https://github.com/romcyncynatus/rtl8192eu.git

or from

http://support.dlink.com.au/download/download.aspx?product=DWA-131


3. Patch the driver source for Kernel 4.x

cd rtl8192eu
Apply the following patch to rtw_android.c

diff --git a/os_dep/linux/rtw_android.c b/os_dep/linux/rtw_android.c
index 40ddf07..f7c496e 100755
--- a/os_dep/linux/rtw_android.c
+++ b/os_dep/linux/rtw_android.c
@@ -342,7 +342,11 @@ int rtw_android_cmdstr_to_num(char *cmdstr)
 {
        int cmd_num;
        for(cmd_num=0 ; cmd_num<ANDROID_WIFI_CMD_MAX; cmd_num++)
+#if (LINUX_VERSION_CODE >= KERNEL_VERSION(4,0,0))
+               if(0 == strncasecmp(cmdstr , android_wifi_cmd_str[cmd_num], strlen(android_wifi_cmd_str[cmd_num])) )
+#else
                if(0 == strnicmp(cmdstr , android_wifi_cmd_str[cmd_num], strlen(android_wifi_cmd_str[cmd_num])) )
+#endif
                        break;

        return cmd_num;


4. Grab the rpi-source tool (to download the Pi kernel source)

wget https://raw.githubusercontent.com/notro/rpi-source/master/rpi-source 
chmod +x rpi-source
sudo mv rpi-source   /usr/bin/
sudo rpi-source -q --tag-update


5. Install the Pi kernel

sudo rpi-source --skip-gcc


6. Build and install the driver

make ARCH=arm
sudo make ARCH=arm install
sudo bash -c 'echo "options 8192eu rtw_power_mgnt=0 rtw_enusbss=0" > /etc/modprobe.d/8192eu.conf'
modprobe 8192eu

For a recent Hack Day at work I spent some time working with one of my colleagues, Adrian Lee, on a little side project to see if we could detect cancer cells in a biopsy image.  We've only spent a couple of days on this so far but already the results are looking very promising with each of us working on a distinctly different part of the overall idea.

We held an open day in our department at work last month and I gave a lightening talk on the subject which you can see on YouTube:


There were a whole load of other talks given on the day that can be seen in the summary blog post over on the ETS (Emerging Technology Services) site.

A slight departure from my usual sort of posts but these are "my notes" so what the heck.

Last Christmas I treated myself (or strictly speaking was treated to) a new snooker cue.  I've always dabbled with snooker, not particularly good, but I can do enough to get by.  My old cue (18th birthday present) was getting a bit tired.  I decided to go with a really nice English make, Peradon, from Liverpool.  They are reasonably priced but the real treat is the quality of the craftsmanship and since I'm quite keen on making things from wood I really appreciate that side of the cue as much as anything else - it's clearly one that's far above the level to which I actually play the game.  I eventually settled on the Ascot ¾ cue.

With such a nice piece of wood I was surprised to see a complete lack of advice on how to care for and maintain it.  I wrote to Peradon for some help and what follows is their advice, and hence the reason for keeping it on my blog so I'll stand a chance of finding it again in the future...

The method is quite simple:

1. Rub down with a very fine steel wool (I use Liberon 0000) and wipe away any residue
2. Apply raw linseed oil (I use Liberon Raw Linseed Oil) with a lint free cloth and leave for 20-30 minutes
3. Buff the cue with a lint free cloth
4. Repeat if necessary (you can also heat or dilute the linseed oil for multiple coats)

It seems to work very well.  Peradon recommended I do this every couple of weeks which seems to be to be rather on the excessive side so I'll probably opt for "every now and then" and since this is the first time I've done it, it looks to be an annual event although I may do it more often now I've got all the gear.