Posts

Solving a Rubik's Cube

We bought a Rubik's Cube while away on our summer holiday this year and spent some time playing around with it and then learning to solve it.  We've returned to it over the Christmas break.  The solve we're learning is based on a very detailed video (below) from Wired Magazine.  I'm at the stage where I can remember most of the solve shown in the video but haven't memorised the final few steps involving the algorithms to position the final corner pieces in the top layer.



Since the video is so long and detailed, when you're at the stage of being able to remember most of the solve, you just need a quick memory jogger rather than wading through the video (even though it has some nice chapter markings).  Hence, this post is my quick reference guide for the future.  I'll walk through the whole solve very briefly (use the video for the detail)...

Introduction

Learn the right trigger and left trigger moves (involves holding the cube correctly)

Learn cube notation (rotate the appropriate face clockwise from the point of view of you looking straight onto that face)

  • F = Front Face

  • B = Back

  • L = Left

  • R = Right Face

  • D = Downward Face

  • U = Upward Face

  • ‘ = Spin anti clockwise e.g. F’ = Front Face anti clockwise

  • 2 Spin twice e.g. F2 = Front Face rotates by 180 degrees (spun twice)

 

Solve the bottom layer

Video Link
  1. Make the daisy
    1. Position white edge pieces around the yellow centre
  2. Make a white cross on the bottom face
    1. Line up white edge stickers on the top face with their middle colour on the side face, rotate the twice to move the white sticker from the top face to the bottom face
    2. The white face should remain pointing down for the rest of the solve
  3. Position the bottom row corners
    1. Search for corner pieces in the top layer that have a white piece
      1. If found, match the non-white colour of the corner piece in the top layer (ignore the top face) with the coloured center.
      2. With the non-white coloured center facing you observe whether the white sticker is on the left or right side of the cube. If left, perform the left trigger; if right, perform the right trigger.
    2. If there are no white pieces in the top layer but you have one in the bottom layer. Determine if the white piece in the bottom layer is on the left or right and with the white piece facing you, perform the left or right trigger (depending on whether the white piece is on the left or right side of the cube). The white piece will now be on the top of the cube.
    3. If there are no white pieces in the top layer but you have one on the top face. Rotate the top face such that the white sticker is not opposite a white sticker on the bottom face i.e. the white sticker on the top face should be opposite a coloured sticker on the bottom face. Then reposition the sticker so it’s in the top layer.
      1. Perform the left or right trigger twice in succession if depending on whether the white sticker on the top face is on the left or right side of the cube.  Now refer to 3.1 to place the corner correctly onto the bottom face.

 

Solve the middle layer

  1. Search the top layer for edge pieces that do not have any yellow stickers (either on the edge face or the top face).  Then once found move that piece to the second layer.
    1. Rotate the top layer such that the sticker on the edge face is colour matched with its centre sticker.
    2. Examine the colour of the sticker on the top face of the edge piece you're moving, it should match the left or right centre stickers.
      1. If it matches the left then rotate the top face anti clockwise by 90 degrees (a U' in notation form) then perform a left trigger
      2. If it matches the right then rotate the top face clockwise by 90 degrees (a U in notation form) then perform a right trigger
    3. You've now displaced one of the white stickers.  It will be in the top row so simply place it back to the bottom face using the same method as when solving the bottom layer.
  2. Repeat the above until there are no more non-yellow stickers on the top face.
  3. You may occasionally find a situation where there are no edge pieces in the top layer without yellow stickers but the second layer is not complete.  If this happens:
    1. Examine the middle layer for the piece that is not right.  With that piece facing you, examine if it's on the left or right of the cube.  Perform either the left or right trigger according to which side its on.
    2. Fix the displaced white piece.
    3. There will now be an edge piece in the top layer that doesn't have a yellow sticker so continue solving as per the first step of the middle layer.
 

Create a Yellow Cross (top face)

Required Algorithm: F U R U' R' F'

  1. Repeat these steps depending on the number of yellow edge pieces (on the top face):
    1. If there are no yellow edge pieces (on the top face), perform the algorithm.
    2. If there are two yellow edge pieces in a line, orient the line so it faces up/down, perform the algorithm.
    3. If there are two yellow edge pieces next to each other, place them in the 12 and 9 position on the top face, perform the algorithm.
 

Solve the Yellow Face


Required Algorithm: R U R' U R U2 R'
  1. Look at the top (yellow) face and repeat these steps depending on the number of yellow corner pieces (on the top face):
    1. If there are zero or two yellow corner stickers, rotate the top face until there is a yellow sticker in the top right position of the left face, perform the algorithm.
    2. If there is one yellow corner sticker, rotate the top face until the corner sticker is in the bottom right position, perform the algorithm.
 

Position the Top Layer Corners

 
Required Algorithm: L' U R U' L U R' R U R' U R U2 R'

  1. Look at the top corner pieces of the top layer, repeat these steps:
    1. If there are no matching corner pieces, perform the algorithm.
    2. If one of the faces has matching corner pieces, place that face in the left hand so it's pointing left, perform the algorithm.
  2. When all of the corner pieces match, rotate the upper face so the corner pieces on each face match up with their centre colour.

Position the Top Layer Edges


Required Algorithm (Clockwise) i: F2 U R' L F2 L' R U F2
 
Required Algorithm (Anticlockwise) ii: F2 U' R' L F2 L' R U' F2

  1. If one of the sides is solved, face it away from you then look at the edge pieces on the remaining unsolved 3 sides
    1. Swap the edges clockwise, perform algorithm i
    2. Swap the edges anticlockwise, perform algorithm ii
  2. If none of the sides are solved, perform algorithm ii, reposition the cube to face the solved face away from you and then perform algorithm ii again.

Post a Comment
Read more

IoT Christmas Tree Tech

In my previous post where I was showing off my IoT Christmas Trees, I described the project and what the trees are intended to do.  This post features the inside track information about how I put the project together.  So the first post is supposed to be non-technical if you will and this post details the info more of interest to those interested in the technical make-up of the project.  Since this is effectively a recipe for how to create one of my IoT Christmas Trees, we'll start with the list of things needed.

Ingredients

For the Tree

Bits you need to make one tree:
  • Wood
  • Paint
  • Arduino ESP32
  • Micro USB Cable
  • Veroboard
  • LED String
  • Buttons

Server and Connection Requirements

These are Internet connected of course so needed here are:
  • An MQTT Broker
  • An HTTP Server
  • WiFi with Internet Connection
  • Another WiFi capable device

Other Useful Bits

Probably staple provisions of any maker's tool box:
  • Glue Gun
  • Soldering Iron and Solder
  • Heat Shrink Tubing
  • Wire (22AWG Solid Core)

 

Putting it all together

 


The wooden bits

You need enough wood in whatever design you prefer.  I made a point of making each of my trees in a different style.  It caused more work that way of course but there's something nice about each tree being unique.  My designs are all between about 25cm and 40cm tall without much thought put into why.  However, this sort of size seems to work well with the light string I chose.  Given the light string is 5 metres long and I used half a string for each tree I needed to hang 2.5m of string around each tree (containing 25 lights per tree).  Therefore, you need to size the wooden structure appropriately for the length of string or number of lights you intend to hang.

Painting

I decided to use spray paint to try and achieve a really smooth and high quality finish.  I selected Montana paints as they provided all the types of paint I wanted to use (primer, metallic top coat, glitter and varnish).  I went with 4 of their colours, Aztec Gold, Avocado Green, Titanium, Red; and glitter effects in Silver and Dusty Gold.  Everything came from Graff City.

A couple of coats of primer were needed followed by a couple of coats of metallic.  The glitter paint goes on as a varnish layer with particles of coloured glitter in it and they recommend a top coat of varnish is used to seal the glitter coat and prevent and loose glitter falling off.  The result is a really nice layered effect where the fairly reflective metallic coating is set off against a subtle glitter effect and everything is finished off with the sheen of varnish.

Electronics

The main driver of the project, electronically, is an ESP32 board.  The board I chose is a knock off of the Lolin D32 simply because it has everything I needed (including having the pins not soldered) and much cheaper than locally available boards in the UK.  While the board was cheaper, I did discover some of the drawbacks in as much as it doesn't have built-in pull up resistors on its GPIO pins and as such I had a lot more soldering to do to work in a 10kΩ resistor into a little veroboard circuit to wire in the buttons I chose.

The string of LED lights looks very cool with some quite presentable wiring between the lights when compared to an LED strip.  They're completely WS2812/NeoPixel compatible so they're easy to programme and there's some nifty libraries out there already available.  They are, however, fairly hellish to solder since the wires are coated with some very thin plastic insulation which is either difficult to remove or otherwise burn through with your solder.

Finally, the whole thing is powered via Micro USB so I ordered a pile 3m long USB-A to Micro-USB cables so the trees can be sited a reasonable distance from a power socket and I didn't have to worry about batteries or charging although battery powering these units would definitely be possible.

Firmware

The firmware is a fairly standard Arduino implementation for the main loop and using WifiManager to configure the ESP32 WiFi to connect to an SSID.  It wont come as any surprise to find the messaging component I'm using is based on MQTT and so I'm using Nick's pubsubclient library on the client side.

One of the more interesting things I've done with the firmware is to attempt to make it as remotely configurable as possible without the need to rely on over-the-air updates for the firmware.  To this end, I'm using the inih library and the firmware downloads its configuration as an ini formatted file from a remote location that allows me to configure as much as possible, currently: mqtt hostname:port, username, password, SSL settings, publish and subscribe topics, device name; and then configurations for the lights for things like which colours to cycle around, how long the "Merry Christmas" setting is maintained before reverting to the previous setting.  The ini file format also allows an easy "global" configuration to apply across each tree while also allowing a per-tree customisation.  Should the WiFi connection not be available or the configuration file not be available then the tree reverts to a sensible set of defaults.

Once running, WiFi connected, MQTT connected and the configuration has been downloaded and applied there's some basic login there to cycle between the different light configurations when the left button on the tree is pressed.  This is all done locally on each tree.  The right button, when pressed, sends a (configurable) message to the other trees that tells them what to do.  So it would be possible for each tree to have its own specific "Merry Christmas" pattern so you could, for example, work out who had sent you the message by the pattern/colour of the light flashes on the receiving tree.

I have also built in a simple command protocol to further take advantage of the MQTT connectivity.  This allows me to send a "ping" to each tree to see which are currently alive, connected and working properly.  The second command I have is a "reload" command that will cause the tree to download and re-apply the configuration from its remote location, noting of course that the configuration could have changed and so I can cause a tree to remotely update its configuration.  Finally, there is a "reconnect" command that will cause the tree to disconnect and connect to its configured MQTT broker.  This is useful in the rare circumstance where the IP address of the broker may have changed in which case I can update the configuration, have the tree read a new configuration, then have the tree disconnect from the current broker and connect to a new broker.

MQTT Broker

The MQTT broker is provided courtesy of my still relatively new Pi4 home server and the rather excellent Mosquitto MQTT broker.  Since I'm running this all myself and not using a cloud based MQTT service I've screwed it all down as far as I can from a security perspective but there's nothing like running your own services to make you feel vulnerable!

Post a Comment
Read more

IoT Christmas Trees

My latest maker project has been running for a good chunk of the year and has been a really cool thing to do to keep me occupied during lockdown since I'm not really one to binge watch box sets.  I've been making Internet connected Christmas trees as gifts for close family.  They're designed to be ambient ornamental decorative pieces with a funky twist of interactivity.  The video I produced probably explains them best...


As you can see from the video, each tree is deliberately different.  I thought it would be more interesting to have a completely different wooden design for each.  My dad did the woodwork which saved me quite a lot of time and allowed me to concentrate on writing the software and doing the electronics not to mention building and painting each tree.  There's a good few hours work in each of these things.

Operation of the trees is pretty simple with the most complicated bit, like with most of these things, being the initial set up to get them onto your WiFi network.  For that, and to explain the basics of how they work along with a bit of troubleshooting information, I wrote a little user manual to go with them.  After all, it will be our closest family members that receive one of these and so I can always help out remotely (and potentially fix any issues that arise).  The left button on each tree cycles round a set of pre-defined colour schemes.  However, these can be changed on a per tree basis should someone want a different colour or configuration.  Similarly, the trees can be operated remotely but I've yet to write a decent interface to do so.  The right button on each tree is where the fun is, causing all the other trees to change light pattern for some period of time.  Again, this is all configurable per tree but by default they all cause the same green and red frenzied light pattern which should be very noticeable in the corner of your room should it occur.

Finally, big thanks to James Sutton and his original iotree project was in no small amount an inspiration for my work here.  Although, the implementations are different both physically and in software there's still a huge amount of overlap.  James was also responsible for running an IoT hackathon at work (we're colleagues) introducing a lot of the technology I would need in order to perform this build.  Thanks again, James!

I've also written more details on the technical implementation.  But, I'll sign this post off with a closer look at each tree in pictures...








 

Post a Comment
Read more

Yet Another New Home Server

This year has seen me doing more in the way of little tech projects at home than I have done for a while, perhaps due to covid lock downs so if that's the case then I'll take this small positive from an otherwise rubbish situation.  Typically for me, these projects have focused around open source projects and some IoT.  More on those in some separate blog posts when I get around to writing them up.  But for now, I wanted to make some notes on my new home server set up.

I've had an array of different low powered home servers of the years that I've previously written about, namely the NSLU2, TinyTuxBox, Joggler and for the past many years a simple ReadyNAS box that I specifically bought for the Intel processor as it made compiling different bits and pieces a whole lot easier back in the day.  However, I have recently relegated the ReadyNAS box from home serving duties, keeping it only for its native NAS services because using it for other things has become increasingly difficult without updating the entire base OS (which is possible by I'm reluctant to do) due to down level software libraries like an ancient version of openssl.

In with the new then and I moved away from Intel architecture as it's now so much easier to compile for Arm chips and went with the, wait for it, drum roll, rather obvious choice of a Raspberry Pi 4.  Specifically, a Pi 4 Model B, 4GB.  I've paired it with the official Pi case power supply, micro HDMI cable and shoved in an A2  SanDisk Extreme 64GB SDXC card.

And so to the notes, my initial target for this new box would be as follows:

The Lounge

IRC might be a bit old hat but tons of open source project still use it for their more synchronous communications.  ZNC is the choice of old for staying connected to your IRC channels.  For those not familiar, it acts as a relay to the IRC servers you want to connect to.  Effectively, it connects as your IRC client to the servers and presents your local IRC client with an endpoint through which you can connect.  This allows you never to miss any messages and see the IRC conversation even when you're not actually online.  Matrix seems to be taking some of the old IRC community's attention with various projects setting up bridges between Matrix and IRC.  However, the relative newcomer project called The Lounge shows just how far web technologies and web sockets have come.  It's a darned site (pun intended) easier to install configure and use than ZNC so I'm a massive convert and big fan of the project.

The project is relatively stable in the master branch and doesn't release particularly often so I've open for the run from source approach to take advantage of all the latest development.  Other than that, I've only made 3 changes to the default configuration prior to starting up my The Lounge server:
  1. host: "127.0.0.1"
  2. reverseProxy: true
  3. theme: "morning"
As you can see, these are all pretty simple and somewhat trivial changes.  The host setting binds the listener to the localhost interface, thus making it suitable for use with a reverse proxy and not exposing the service outside of the Pi 4.  The reverseProxy setting tells the server it's expecting to run behind a reverse proxy (the clue is in the name I guess).  Finally, I've switched to using a dark mode theme rather than the default light mode.  That's it, the remainder of the configuration is all about which IRC servers and channels to connect to along with the usual IRC bits of registering your nick and logging into the nick server.

Mosquitto

This is even simpler to get going than The Lounge due to the fact it's bundled with Raspbian so you can just apt-get install it.  I've created a configuration based on the bundled example config file but changing:
  1. pid_file (probably just because I'm old fashioned like that)
  2. user (to drop privileges)
  3. listener (to specify a port number)
  4. certfile and keyfile (for SSL)
  5. log_dest (create a specific log file for the broker)
  6. clientid_prefixes (a bit of added security to only allow certain client IDs to connect to the broker)
  7. allow_anonymous (quite an important one!)
  8. password_file (so that connections are authenticated)
Hopefully, that gives me something secure as well as providing me with the broker functionality that I need.

Node Red

Again, simple to install as it's bundled with Raspbian.  It does like to run under the default "pi" user though, which is a bit of a shame security wise.  All I've done to the configuration is ensure it's listening only on the local interface and enable the adminAuth section such that I'm required to enter a user name and password to access the user interface.

NGINX
 
Another simple install due to using the bundled version that comes with Raspbian.  However, this time around there's a lot more configuration to do since I'm using it to front a reverse proxy onto The Lounge and Node Red.  This gives me a few advantages such as being able to restart NGINX in order to load new SSL certificates without interrupting the underlying services i.e. something like IRC can stay connected even though new certs are loaded.  Both The Lounge and Node Red support SSL in their configuration so this also means I only need to configure certificates in one place and have a single route through which I can access all my home services.  The idea and bulk of the configuration for doing this comes directly from one of the guides available for The Lounge.

server {
    # redirect HTTP traffic to HTTPS
    listen 80 default_server;
    listen [::]:80 default_server;
    server_name _;
    return 301 https://$host$request_uri;
}

server {
    # SSL configuration
    #
    listen 443 ssl default_server;
    listen [::]:443 ssl default_server;
    ssl_certificate /path/to/your/server.crt;
    ssl_certificate_key /path/to/your/server.key;

    server_name your.server.name.com;
 
    # Add this if you want to do web serving as well
    root /var/www/html;
    index index.html index.htm; 
    location / {
        # First attempt to serve request as file, then
        # as directory, then fall back to displaying a 404.
        try_files $uri $uri/ =404;
    }
 
    # Configure reverse proxy for The Lounge
    location ^~ /YOUR_PREFERRED_IRC_URL_GOES_HERE/ {
        proxy_pass http://127.0.0.1:9000/;
        proxy_http_version 1.1;
        proxy_set_header Connection "upgrade";
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header X-Forwarded-For $remote_addr;
        proxy_set_header X-Forwarded-Proto $scheme;

        # by default nginx times out connections in one minute
        proxy_read_timeout 1d;
    }

    # Configure reverse proxy for Node Red
    location ^~ /YOUR_PREFERRED_NODERED_URL_GOES_HERE/ {
        proxy_pass http://127.0.0.1:1880/;
        proxy_http_version 1.1;
        proxy_set_header Connection "upgrade";
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header X-Forwarded-For $remote_addr;
        proxy_set_header X-Forwarded-Proto $scheme;

        # by default nginx times out connections in one minute
        proxy_read_timeout 1d;
    }
}
 
Let's Encrypt
From Wikipedia: "Let's Encrypt is a non-profit certificate authority run by Internet Security Research Group that provides X.509 certificates for Transport Layer Security encryption at no charge."

The model for using letsencrypt is pretty simple.  They sign your SSL certificates, free of charge, but their signing expires within 90 days.  Hence, they're encouraging a high turnover of certificates by regular renewals.  This means that realistically you need to automate the process of certificate signing.  To do this I'm using the getssl script which makes life extremely easy when coupled with a cron job to kick off the script on a regular basis.  I'm running it every day and the script decides whether to replace my existing certificates.  It all sits there quite nicely running in the background and doesn't get in the way at all, restarting NGINX only when a new certificate is put in place.  Due to the fact that NGINX is decoupled from the services it is proxying the other services aren't interrupted.
Post a Comment
Read more

Open Sourcing a NetworkManager VPN Plugin

It's not every day I find myself publishing a new project to open source and even less so when that requires release approval at work.  I hope, over the years, I've written some useful bits and pieces and this time around I was keen to publish my work on the Internet rather than internally within the company.  This requires following due process of course and seeking the relevant approval for the publication to take place.

Fortunately, in the right circumstances, IBM are very amenable to releasing code to open source.  I was convinced enough that a NetworkManager plugin to add to the existing list of VPN plugins would not conflict with the business that an open source approval would be fairly trivial.  Happily, I was correct, and going through the process wasn't too arduous with a few forms to fill in.  These were, of course, designed much more for bigger releases than I planned so vastly over-engineered for this particular release but at least due diligence was applied.

On to the project and the code.  It's not a world-changer but a small VPN plugin for NetworkManager to drive Cisco AnyConnect and made available as NetworkManager-anyconnect on GitHub.  So I now know more than I'd care to mention about the inner workings of NetworkManager VPN plugins.  They're not very well documented (hardly documented at all in fact) so they're quite hard work to produce by looking over existing code in available plugins.  I started off from the OpenVPN plugin which turned out to be a mistake as the code base is vastly bigger than that required for a plugin as simple as the one I wanted to write.  Were I to start again, I would recommend starting from the SSH VPN plugin instead as this is actually very nicely set out and doesn't include a lot of the shared bloat that comes with other plugins that are formally a part of NetworkManager.


Post a Comment
Read more

Installing Tensorflow GPU on Fedora Linux

Following on from my previous notes on building Tensorflow for a GPU on Fedora, I find myself back at it again.  I recently upgraded my GPU at home and time has moved on too so this is my current set of notes for what I'm doing with Tensorflow on Fedora.  This method, however, differs from my previous notes in as much as I'm using the pre-built Tensorflow rather than building my own.  I've found that Tensorflow is so brittle during the build process it's much easier to work with pre-built binaries and set up my system to match their build.

In my previous blog post I benchmarked the CPU versus GPU using the Keras MNIST CNN example and so I thought it would be interesting to offer the same for this new install on my home machine.  The results are  :
  • 12 minutes and 14 seconds on my CPU
  • 1 minutes and 14 seconds on my GPU
That's just over 9.9 as fast on my GPU as my CPU!

 Some info on my machine and config:
  • Custom Built Home PC
  • Intel Core i5-3570K CPU @ 3.40GHz (4 cores)
  • 16GB RAM
  • NVidia GeForce GTX 1660 (CUDA Compute Capability 7.5)
  • Fedora 30 Workstation running kernel 5.2.9-200.fc30.x86_64
Background Information for NVidia Drivers
Previously, I've always used the Negativo17 repository for all my NVidia driver and CUDA needs.  However, the software versions available there are too up-to-date to allow Tensorflow GPU to be installed in a way that works.  This repository provides CUDA 10.1 where as Tensorflow, currently at version 1.14, only supports CUDA 10.0.  So we must use another source for the NVidia software that provides back-level versions.  Fortunately, there is an official NVidia repository providing drivers and CUDA for Linux, so let's use that since it also works quite nicely with the RPM Fusion repositories as well.  Hence, this method relies purely on RPM Fusion and the official NVidia repository and does not require or use the Negativo17 repository (although it would be possible to do so).

Install Required NVidia Driver
The RPM Fusion NVidia instructions can be used here for more detail, but in brief simply install the display drivers:
  • dnf install xorg-x11-drv-nvidia akmod-nvidia xorg-x11-drv-nvidia-cuda
There are some other bits you might want from this repository as well such as:
    • dnf install vdpauinfo libva-vdpau-driver libva-utils nvidia-modprobe
    Wait for the driver to build and reboot to get things up and running.

    Install Required NVidia CUDA and Machine Learning Libraries
    This step relies on using the official nvidia repositories with a little more information available in the RPM Fusion CUDA instructions.

    First of all, add a new yum configuration file.  Copy the following to /etc/yum.repos.d/nvidia.repo:

    [nvidia-cuda]
    name=nvidia-cuda
    enabled=1
    gpgcheck=1
    gpgkey=http://developer.download.nvidia.com/compute/cuda/repos/fedora27/x86_64/7fa2af80.pub
    exclude=akmod-nvidia*,kmod-nvidia*,*nvidia*,nvidia-*,cuda-nvidia-kmod-common,dkms-nvidia,nvidia-libXNVCtrl

     [nvidia-machine-learning]
    name=nvidia-machine-learning
    baseurl=http://developer.download.nvidia.com/compute/machine-learning/repos/rhel7/x86_64/
    enabled=1
    gpgcheck=1
    gpgkey=http://developer.download.nvidia.com/compute/machine-learning/repos/rhel7/x86_64/7fa2af80.pub
    exclude=libcudnn7*.cuda10.1,libnccl*.cuda10.1



    Note that the configuration above deliberately targets the fedora27 repository from NVidia.  This is because it is the location at which we can find CUDA 10.0 compatible libraries rather than CUDA 10.1 libraries that will be found in later repositories.  So the configuration above is likely to need to change over time but essentially the message here is that we can match the version of CUDA required by targeting the appropriate repository from NVidia.  These libraries will be binary compatible with future versions of Fedora so this action should be safe to do for some time yet.



    With the following configuration in place we can now install CUDA 10.0 and the machine learning libraries required for Tensorflow GPU support and all of the libraries get installed in the correct places that Tensorflow expects.

    To install, run:
    • dnf install cuda libcudnn7 libnccl

    Install Tensorflow GPU
    The final piece of the puzzle is to install Tensorflow GPU which is now as easy as:
    • pip3 install tensorflow-gpu
    8 comments
    Read more

    Migrating to Gnome 3

    I'm a massive laggard in the move to a Gnome 3 desktop.  Colleagues and friends have been using it for years and to be honest, I've never been comfortable using it.  But, that changed recently and I've actually grown to quite like the new desktop environment I find myself working in on a daily basis.  So I've made a full-blooded leap to a modern desktop.

    Way-back when I started using Linux as a serious desktop alternative to Windows (in about 2000-2001 ish) I was running Gnome.  I migrated away from that to KDE 3 and switched to Gnome 2 when KDE 4 was released as I didn't like the changes they had made and the new KDE 4 desktop was horribly buggy and unstable in my experience.  (Maybe there's something about brand new desktops and my not taking a liking to them?)  When Gnome released Gnome 3 I absolutely hated the user experience and used XFCE for a while before settling on the MATE desktop which I've been using for quite a few years now.

    Trying out Gnome 3 again recently and I was pleasantly surprised that the desktop has progressed significantly since those first few releases I couldn't get along with.  But it's the addition of extensions that are the final straw in my move as I've found with just the right mix I can craft a desktop that gives me a nice balance between the new world and the old, much more familiar, world.

    (final update 24th April 2024) Note: there is an updated list of the extensions I use in my newer Gnome Extensions blog post.

    So, the real purpose of this post is to share the extensions I've discovered.  I'll document these below in brief but would also be interested to find others that are useful:

    Applications Menu (updated 5th Feb 2021 - no longer in use, see below)
    This was right at the very top of my list of requirements for Gnome 3 usability.  It simply puts an old school applications menu in the top bar, a bit like your old fashioned Windows start menu or similar from other desktops.  I am, however, finding I use this very little now as the search hot-key in Gnome 3 does seem to be a quicker way of finding and starting programs.

    Frippery Bottom Panel
    This is another of my top requirements for Gnome 3 usability.  It gives you a panel at the bottom of the screen (D'uh) that allows you to switch easily between applications you have running.  It also has a small workspace switcher which is why I like the Frippery version of this type of extension versus some of the others that don't have a workspace switcher capability.

    Top Icons Plus (update 5th Feb 2021 - no longer in use, replaced with AppIndicator, see below)
    Either the Top Icons or the Top Icons Plus extension that I'm using here seem so ubiquitous for Gnome 3 users I wonder why on earth they're not a default option, aside from the fact the Gnome 3 developers do seem to retain their keen vision on what a modern desktop should look like and "old" system tray icons are not part of that outlook.  This extension, if you're not already using it, allows you to see system tray icons such as the ones used by Virt Manager or Slack, for example.

    GPaste (update 4th Nov 2021 - no longer in use, too difficult to configure and doesn't always work the way I expected, replaced with Clipboard Indicator, updated again 8th Mar 2023, replaced with Pano Clipboard Manager)
    A clipboard management system that has a nice integration with the Gnome 3 panel.  I was previously using apps like ClipIt or Parcelite that do pretty much the same job.

    Lock Screen (update 5th Feb 2021 - no longer in use, I wasn't using this as I just hit Win+L to lock)
    This adds a button to the gnome panel that, when clicked, locks your desktop.  This would be the same as pressing Win+L on the keyboard.  I was in the habit of using a graphical button on MATE so having this back in Gnome 3 gives me the experience I'm used to.

    No TopLeft Hot Corner (update 5th Feb 2021 - no longer in use, Gnome Tweaks as a toggle for "Activities Overview Hot Corner" from the Top Bar options.
    I find the Gnome 3 facility to show activities when you mouse to the top left corner really annoying and it detracts from my productivity when it happens automatically.  Fortunately, this extension disables that feature.  It does make it more awkward to reach activities with the mouse (I'd have to click the applications menu first then select "Activities Overview") but I more or less always use the Windows key anyway.

    Places Status Indicator (update 8th Mar 2023 - no longer in use, I wasn't using it so have stopped installing it)
    This adds the old Gnome 2 style places menu to the Gnome 3 panel.  I find I flip between using this menu to start navigating directories and just starting Gnome Files and going from there.  Any which way, having this menu back on my desktop just makes it feel a bit more familiar and comfortable.

    Remove Dropdown Arrows (update 5th Feb 2021 - no longer in use, Gnome seems to have gotten rid of most of these by default)
    The Gnome 3 panel insists on having an arrow indicator to show items that pull down a menu when clicked.  These menus seem obvious to me and the arrows look rubbish and take up space, so this extension gets rid of them completely.  Happy days.

    Suspend Button (update 5th Feb 2021 - no longer in use, Gnome now has a built-in suspend button)
    I run from a laptop most of the time and use the suspend feature every time I "shut down" my laptop.  Bizarrely, there's no graphical facility (that I can find) in Gnome to suspend my machine.  This extension adds a nice button to the status menu that immediately suspends my machine.  Perfect.

    System Monitor
    Adds little graphs to the Gnome panel that show resource usage.  The extension is pretty configurable but I have it showing CPU, memory and network utilisation.  This allows me to keep an easy eye on my machine and how loaded it is at the current time.  Extremely useful for spotting those occasional rogue apps that start eating an entire core of my CPU.

    Media Keys (update 5th Feb 2021 - no longer in use, Gnome has media controls built-in)
    I haven't decided how useful this one is going to be yet and it's currently turned off.  However, when listening to Music through services like Amazon Music from a web browser it's nice to be able to control the audio without having to revert back to the browser ever time.  This extension simply adds a few buttons to the Gnome panel to control your media.  Handy if you haven't got the physical buttons on your keyboard too.

    Do Not Disturb Button (update 5th Feb 2021 - no longer in use, Gnome has the button built-in)
    I generally leave this extension disabled but it's useful to have installed and running when presenting or screen sharing.  It saves any embarrassing situations of people being able to read your notifications while they're looking at your screen.  Basically, it simply stops notifications being displayed, they're still received so you can go read them later.


    Blog edited with more extensions added on 28th August 2019:
    Frippery Panel Favourites
    I'm not quite sure how I missed this from my original list as it's an extension I've been using more or less since day one in Gnome 3.  It takes your favourite menu and adds this as a set of icons to the top of the Gnome Panel.  Makes for extra quick access to your commonly used apps.

    Some more extensions have been brought to my attention since writing the list above.  I've tried out all of the ones mentioned to me but these additions (below) are the ones that seem to have stuck.

    Caffeine (update 5th Feb 2021 - no longer in use, using Gnome's built-in do not disturb button instead)
    This extension sits fairly well alongside the Do Not Disturb Button extension in my original list.  This one simply disables the screen saver and auto suspend.  Hence, in conjunction with Do Not Disturb, will make a good presentation or screen sharing environment.

    GTile
    This is a genius little extension that allows you to easily resize your windows in order to tile them across your display.  I love the side-snapping in Gnome 3 that allows you to size a window to half the screen size.  In my older desktops I also had corner snapping to size a window to a quarter of the screen, Gnome 3 doesn't have this by default.  However, GTile adds an icon to your Gnome Panel that, when clicked, allows you to size to any area of your screen across a pre-defined grid - you can even change the grid size.  Brilliant for usability with lots of on-screen windows at the same time.


    Blog edited to update the list of extensions I'm using on 5th February 2021:

    Applications Menu
    Just a note to say that after using Gnome 3 for quite some time now, I rarely (if ever) use the Applications Menu any longer.  I tend to start applications either by pressing the Gnome hot key (Windows Key by default) and type in the search box, or by clicking on one of the favourites in the panel via the "Panel Favourites" extension.

    While the free desktop standard continues to specify the classic "icon tray" that was supported by extensions such as TopIcons, in reality few of the modern desktops (I'm referring to Gnome and KDE) support them.  The modern take on the tray icon is an AppIndicator icon and many modern applications are written to use this standard (and perhaps fall back to a tray icon).

    Blog edited to update the list of extensions I'm using on 8th March 2023:
    It's interesting to see how much use of extensions has changed over time.  I'm using considerably fewer now than I was when I first started using Gnome 3.  I put this down to two things: (1) Gnome is better at operating the way user's expect by removing the need for extensions such as the Suspend Button in the list above; and (2) I've become more institutionalised to the way that Gnome works, I'm much more familiar with it and have grown to like much of the way it works.
    Post a Comment
    Read more

    Helping Disabled Passengers Travel with Confidence

    This is a reproduction of a blog post originally made on the IBM Emerging Technology blog at https://www.ibm.com/blogs/emerging-technology/helping-disabled-passengers-travel-with-confidence/ (link now dead).  Original article published on 3rd April 2019, re-publication to this blog was on 11th June 2021.

    Introduction

    Disabled or disadvantaged passengers have every right to fear travelling with multiple high profile cases of unfair and appalling levels of service evident in the media, particularly for rail passengers. Our team have been tackling this problem recently in collaboration with the IBM Travel and Transport team and 50% funding through Innovate UK’s call for Accelerating Innovation in Rail (round 4). The project was the brain child of Sam Hopkins and won the internal IBM Hybrid Hackathon event in 2016.

    The Problem

     The rail industry in the UK is a complex one and travelling on our railways can be a difficult experience for anybody. If you’re disabled then the experience can be difficult at best and demeaning or impossible at worst. Depending on the type and severity of their disability, disabled travellers need to plan for eventualities such as whether a station is fully accessible, whether and when staff are available to help, when and where they might be able to use a toilet, how and where to board and alight the train, the list is as long as the wide range of issues people may have. Today, assistance is on offer, but this is complex due to the nature of our fragmented system and passengers (or their carers) may need to contact multiple companies 24 hours in advance of travel when planning their journey. This process of organising their journey is extremely time consuming and can be as much of a frustration as the journey itself.

    The Challenges 

    The UK rail industry is highly fragmented with different parts of the operation split among different companies. For example, Network Rail oversee the infrastructure such as maintaining tracks and signalling; Rolling Stock Operating Companies (ROSCOs) own the trains; and Train Operating Companies (TOCs) operate the trains and run passenger services in different regions around the UK. In order for a disabled passenger to make a journey, the Train Operating Companies are legally obliged to provide support both off the train at the station and on board the train during the journey. However, a passenger may be travelling through a large number of regions and across services provides and hence need to understand which company will be responsible for their journey at any given stage. Understanding this takes quite a bit of research and can be difficult, it also requires that everything they require on their journey lines up across the network they’re travelling on and this is certainly not guaranteed on our network today.

    Our Solution

    We have created a mobile application for disabled passengers, supported by an enterprise grade back end architecture. During the project we established a principle that the disabled passenger should always be connected to a member of staff. This connection provides continuous support available whenever required by the passenger and is designed to help

    alleviate the anxiety felt by this group of passengers when travelling. The connection comes in the form of a chat application similar to how passengers may already use common applications such as WhatsApp or Facebook Messenger. The passenger can type anything they want to the member of staff they’re connected to and get a human-level response to their query from staff local to their situation. During their journey, the passenger is handed over between staff members such that they’re always connected with a local staff member who can offer physical assistance if required.

    A typical journey story starts with the user programming their journey in a similar way to how they might on existing rail applications. They search for their departure and destination stations and select a time and route they wish to travel. Some time later, they embark upon their journey. When they arrive at the station, they either press a button to start the process or the app uses geolocation to detect their arrival at the station. They are connected to a member of the station staff who can answer questions and provide physical assistance to board their first train. Once boarded, the station staff hand the passenger over to a member of staff on board the train. This hand-over process is transparent to the user and they will simply see a new greeting from the next member of staff in the chain once they have been connected. The process continues with the on train staff handing over to station staff at the destination station in order to provide assistance alighting the train. This process can repeat as many times as necessary until the final destination is reached.

    Technical Implementation 

    Our solution has a strong server-side implementation with an MVP level front end to exercise the APIs provided.

    We base the solution entirely within the IBM Cloud, using a Cloudant instance for database hosting, App ID for authentication services, Message Sight for highly reliable messaging built on top of the MQTT protocol, and NodeJS for writing our APIs on top of the Express framework and where necessary calling out to other APIs such as the Transport API. Security and privacy have been key concerns in the design to ensure chat messages are securely delivered only to their intended recipient. The application itself is authenticated at each of its routes and all of the server-side APIs also use the same App ID authentication. Novel to this solution is the capability of third-party authentication from Message Sight to App ID, a first-of-a-kind implementation.

    The front end application is currently written in VueJS. This has been designed with accessibility in mind given the intended audience. It is a simple interface conforming to web accessibility standards that is compatible with screen readers. This component was never intended to be the final solution and we see another interface being developed in the future that is likely to build upon the current one. For example, a fully native solution or perhaps one written to be more native-like using technologies such as Native Script.

    Moving Forward 

    The solution is complete and ready, subject to customisation, to be adopted by the UK train operating companies. However, we do see the need for an improved user interface to be developed before the solution is truly ready to be used in the wild.

    Further to the current solution for the rail industry, we recognise the issues faced by disabled travellers don’t stop with the UK rail system. Similar issues are faced when using our road network, taxi services, ferries and of course our airports. The principle established within this project of alleviating anxiety through the connection to a supporting human member of staff is likely to remain. We hope this is extended into the other areas we’re considering with the next most obvious choice to tackle being the airport use case.

    Post a Comment
    Read more

    Self-Signing SSL/TLS Certificates

    Things have changed a bit since I last looked into setting up a Certificate Authority (CA) and using that to self-sign my own certificates, not least that the use of the Common Name (CN) field appears to have changed. Chrome in particular seems to insist on the use of the Subject Alternative Names (SAN) extension rather than (or in addition to) using the CN field. So these are my notes on how to set up your own CA and use that to sign certificates. I'm conscious this is bound to go out of date so at the time of writing I'm working with Firefox 64, Chrome 71 and OpenSSL 1.1.1.

     Setup
    First of all, create a config file along the lines of the following and call it anything you like but for these notes I'm going to call it ssl.conf.  Note, if you want to you can start with a different template or look at your own openssl.cnf file which on Linux is commonly found at /etc/pki/tls/openssl.cnf.

    [ req ]
default_bits       = 4096
distinguished_name = req_distinguished_name
req_extensions     = req_ext

[ req_distinguished_name ]
countryName                 = Country Name (2 letter code)
countryName_default         = GB
stateOrProvinceName         = State or Province Name (full name)
stateOrProvinceName_default = England
localityName                = Locality Name (eg, city)
localityName_default        = MyCity
organizationName            = Organization Name (eg, company)
organizationName_default    = MyOrg
commonName                  = Common Name (e.g. server FQDN or YOUR name)
commonName_max              = 64
commonName_default          = localhost

[ req_ext ]
subjectAltName = @alt_names

[alt_names]
DNS.1 = localhost

    You can change any of this template and indeed you'll need to change the common name for the certificates you're generating. The CN can be changed either on the command line during certificate creation or by changing the default in ssl.conf. You will also need to change the list of names under the "alt_names" section, this list should contain one line for each host name your machine might be known as. The list starts at DNS.1 for the first entry, then you can add DNS.2 for the second entry and so on.

    NOTE: the specification and a lot of the documents available in this space indicate that an IP address can be used in the CN.  My testing seems to indicate that while this is the case, certificates produced in this way will be rejected by modern browsers.  Hence, you should list only hostnames as the CN but IP addresses still appear to be acceptable in as "alt_names".

    Create a Certificate Authority
    You'll need a certificate and key file to act as your own CA:

    openssl genrsa -out RootCA.key 4096
openssl req -x509 -new -nodes -key RootCA.key -sha256 -days 3650 -out RootCA.pem -config ssl.conf

    You can inspect the certificate with:
    openssl x509 -in RootCA.pem -text -noout

    Create a Certificate Signing Request (CSR)
    Now you have a CA you can create a CSR that can be used with your CA certificate to generate a client certificate:

    openssl genrsa -out server.key 4096
openssl req -new -key server.key -out server.csr -config ssl.conf

    You can inspect the certificate with:
    openssl req -text -noout -verify -in server.csr

    This time it's really important to ensure your host names are listed under the "X509v3 Subject Alternative Name" section of the certificate.

    Generate a Signed Certificate
    You can now use the CSR to create a signed certificate that can be used to serve up content over a secure connection:

    openssl x509 -req -in server.csr -CA RootCA.pem -CAkey RootCA.key -CAcreateserial -out server.pem -days 3650 -sha256 -extensions req_ext -extfile ssl.conf

    Note: if you want to create a different format of certificate here you can simply replace server.pem in the above command with something like server.crt, for example.

    You can inspect the certificate with:
    openssl x509 -in server.pem -text -noout

    Again, it's really important to ensure your host names are listed under the "X509v3 Subject Alternative Name" section of the certificate.

    Use the Certificate Server Side
    You can now put your server.pem and server.keyfiles to work and serve up content over a secure connection.  There's too many ways to do that to list here but it could be used with a web server to serve HTTPS or a websockets server to serve some sort of socket connection as a couple of examples.

    If you want to inspect the certificate that's being used on the server, replace <hostname> and <port> in the command below:

    openssl s_client -connect <hostname>:<port> | openssl x509 -noout -text

    Use the Certificate Client Side
    My use case here is with a web browser and so you'll want to import your <i>RootCA.pem</i> into your browser environment.  There are two main ways of achieving this, you can either:
    1. Import directly to the browser
    2. Import to the key store on your operating system
    It's quicker and easier to import directly to the browser but this will of course only cover that one browser on your system whereas if you use the operating system method then any application that consults the OS for certificates will see your CA certificate.

    For Firefox, go to "View Certificates" in the preferences; click the "Authorities" tab and then the "Import" button; select your <i>RootCA.pem</i> file and click OK.

    For Chrome, go to "Manage Certificates" in the settings; click the "Authorities" tab and then the "Import" button; select your <i>RootCA.pem</i> file; click the check boxes to trust the certificate and click OK.
    Post a Comment
    Read more

    Building Tensorflow GPU on Fedora Linux

    <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)


    Fix Bazel Config
    The above config command writes a file but the location isn't compatible with the latest version of Bazel.  Presumably this issue will be fixed at some point in the future, it's not an issue with Bazel 0.18 and below as far as I'm aware, but has just become an issue on 0.19.  Simply copy the config to the correct place:
    • cat tools/bazel.rc >> .tf_configure.bazelrc
    Build Tensorflow with GPU Support
    This took around an hour to complete on my machine:
    • bazel build --config=opt --config=cuda //tensorflow/tools/pip_package:build_pip_package
    • bazel-bin/tensorflow/tools/pip_package/build_pip_package /tmp/tensorflow_pkg
    The first step is the long one for the build, the second simply builds the python wheel file.

    Install Tensorflow with GPU Support
    You've got your wheel file so simply install and enjoy:
    • pip3 install tensorflow-1.12.0-cp36-cp36m-linux_x86_64.whl 
    Run Some Code
    The first time I attempted to run some code to test I got an error:
    • failed call to cuInit: CUDA_ERROR_UNKNOWN
    This can be solved by making sure you have the nvidia-modprobe package installed.  Alternatively, you can run the little script below the following explanation.

    This seems to be some sort of permissions issue and running the following simple script to output the GPUs available on my machine but as root seems to have fixed the above issue i.e. put the following into a script, run that script as root, then any time you want to run code as an unprivileged user the above issue is fixed and the code will work:
    from keras import backend as K
    K.tensorflow_backend._get_available_gpus()

    If the above works then you can try out the Keras MNIST CNN example code.
    10 comments
    Read more