If you saw my last post Random inputs in unit testing you’ll remember that I was advocating the benefits of using random test data in your unit tests.
One of the bits of feedback that I had (and seems to be the main complaint of most people who are against this) is that you need reliable test input so that you can recreate failures.
I recently had an upstream reviewer telling me that I should not randomise my test input because “randomness does not provide a useful input to the test and sets a bad example of practices for writing tests”.
I am going to explain here why this is wrong and it’s actually good practice to randomise inputs. Let me start by saying that random test failures are not the same thing as spurious test failures. I’ll come back to that later.
The latest Phantom 4 video shot at Glen Rock State Forest in South East Queensland’s Scenic Rim.
Enjoy the spectacular scenery of the Sunshine Coast Hinterland.
While I was dropping my mother at the airport tonight, I thought I’d try to get a nice shot of the “super moon”. I wasn’t too disappointed with this result!
It’s hard to convey just how bright the moon is. I processed this shot so the detail stands out, but in real life it’s a glowing white ball.
I tried to do some colour grading here. The range is spot on now, but I think I could increase the saturation a bit. Next time.
I was recently trying to get LXD working on my Linode server, but was getting this error:
$ lxc launch ubuntu:16.04 wordpress
Creating wordpress
Starting wordpress
error: Error calling 'lxd forkstart wordpress /var/lib/lxd/containers /var/log/lxd/wordpress/lxc.conf': err='exit status 1'
lxc 20161010203338.247 ERROR lxc_seccomp - seccomp.c:get_new_ctx:224 - Seccomp error -17 (File exists) adding arch: 2
lxc 20161010203338.247 ERROR lxc_start - start.c:lxc_init:430 - failed loading seccomp policy
lxc 20161010203338.247 ERROR lxc_start - start.c:__lxc_start:1313 - failed to initialize the container
The fantastic Stéphane Graber helped me to work out that the default Linode kernel doesn’t have the right bits compiled into it, and I should be using an Ubuntu kernel instead.
So, following the guide at https://www.linode.com/docs/tools-reference/custom-kernels-distros/run-a-distribution-supplied-kernel-with-kvm to upgrade my kernel, it now works.
My second drone video! A bit longer, and has a special appearance by my dog at the end.
I went and bought myself a DJI Phantom 4. Holy crap, I’m impressed. 12MP images and 4k video. Not to mention all the other bells and whistles like collision avoidance, auto return to home and when you put it in speed mode, it does 70km/h!
Here’s the first of a couple of videos I put together for it:
If you read my previous post WebEx in Ubuntu LXC containers you’ll have learned how to get Cisco’s Webex running on Ubuntu in a 12.04 container.
I figured it was time to work out how to get it running in the newer LXD containers available in 16.04, here’s how I did it.
apt-get install lxd sudo lxd init
When it asks you about networking, use the existing lxcbr0 bridge, do not let it use a new bridge as by default it will create lxdbr0. We need to stay on lxcbr0 so that networking continues to work in the old containers.
lxd init ubuntu:precise webex
This will download a new 12.04 template if you don’t already have one, it will take a while depending on your Internet connection.
I’m not going to rebuild my rootfs from scratch, the old one is perfectly usable! So as root, we can copy it from the old LXC area:
cp -rp /var/lib/lxc/webex/rootfs /var/lib/lxd/containers/webex/
The old container rootfs was a privileged container so we need to do the same on this LXD copy:
lxd config set webex security.privileged true
To make the sound device available you need to set up the sound device in the container. Here I am adding all the devices under /dev/snd/ on my own host, note that yours may differ so edit the commands accordingly:
lxc config device add webex /dev/snd/controlC0 unix-char path=/dev/snd/controlC0 lxc config device add webex /dev/snd/hwC0D0 unix-char path=/dev/snd/hwC0D0 lxc config device add webex /dev/snd/hwC0D3 unix-char path=/dev/snd/hwC0D3 lxc config device add webex /dev/snd/pcmC0D0p unix-char path=/dev/snd/pcmC0D0p lxc config device add webex /dev/snd/pcmC0D3p unix-char path=/dev/snd/pcmC0D3p lxc config device add webex /dev/snd/seq unix-char path=/dev/snd/seq lxc config device add webex /dev/snd/timer unix-char path=/dev/snd/timer
You may remember I was using ssh X forwarding in the old container. We don’t need to do that any more as we can get direct access to the video from the container by using this config:
lxc config device add webex /dev/dri/card0 unix-char path=/dev/dri/card0 lxc config device add webex /dev/dri/controlD64 unix-char path=/dev/dri/controlD64 lxc config device add webex /dev/dri/renderD128 unix-char path=/dev/dri/renderD128 lxc config device add webex /dev/dri/fb0 unix-char path=/dev/fb0 lxc config device add webex /dev/video0 unix-char path=/dev/video0 lxc config device add webex X11 disk source=/tmp/.X11-unix path=/tmp/.X11-unix
Again your devices under /dev/dri may differ a little to mine, change accordingly.
Now, start the container and start a bash shell in it:
lxc start webex lxc exec webex bash
You’ll now have a root prompt in the container. You can test that sound is working by doing something like:
sudo -u ubuntu aplay /usr/share/sounds/alsa/Front_Center.wav
In root’s home we need to make a script to start firefox for us, it looks like this:
root@webex:~# cat webex.sh  #!/bin/bash DISPLAY=:0 su -c firefox - ubuntu
Make sure to chmod +x webex.sh
Now, all things being good, you can do this to launch Firefox:
lxc exec webex ./webex.sh
Launch Webex as you normally would and verify that it works. If it’s OK, you can remove the old SSH service as it’s not needed any more.
apt-get remove openssh-server
In my next post, I’ll explain how to convert the configuration into a more handy LXD profile that you can use for any container.