Jun 2016


I absolutely love this piece of video art!


May 2016

Scripting in CMD

For those stuck in Windows CMD scripting purgatory, these links might make you feel a little more sane:

Use this mantra too:

Hang in there – you are not alone! This won’t last forever and things will get better. This insanity is not your fault. Life will be good again.

Good luck!

Oct 2015

The Secret Life of Waves

This is the best documentary I have ever seen. Waves are very cool, so I expected this to be very cool. I did NOT expect it to change my view on life and death. It might not have this effect on you.

The Secret Life of Waves

It’s not on iPlayer just now but I’m sure you enterprising folks can manage to watch it somehow. And I think that you should.

Oct 2015

My first techno track

This is called Baby Steps (150BPM) and is my first track. It’s the result of learning how to use my Electribe EMX-1 and experimenting with a few ideas.

It’s also on SoundCloud.

There are many things here that can be improved, but it’s time to move on to other things. I have decided to get over not wanting to let people hear things that aren’t all that great by just publishing everything I make. It’ll also provide a nice timeline of how my music progresses.

Sep 2015

A pint of Bitcoin


Just when I thought my workplace couldn’t get any cooler, the pub on site – The Royal Dick – has started accepting Bitcoin. I didn’t even really want a pint but couldn’t pass up this opportunity.

Very cool.

Sep 2015

Jim Carrey’s graduation speech is one of the best I’ve ever seen

These are the words of an enlightened chap.

It’s all good, but this links to 10 minutes in where it starts to get proper decent.

Jim Carrey graduation speech

Sep 2015

Journey is one of the best pieces of interactive digital art ever

Just had an absolutely lovely experience playing through Journey. What a gorgeous and moving piece of art.


It is faultless to me. Every single aspect of it is utterly wonderful – every single second was pure joy and marvel! The closest thing to a perfect piece of software that I’ve ever seen.

Aug 2015

Stunning juggling performance

This incredible piece of performance art NEEDS to be watched with audio. Watch it to the very end because the entire thing is a fucking masterpiece.

Michael Menes

This is the best juggling performance I have ever seen and it has been a massive influence on my juggling. I saw it about 6 months after really getting into juggling (1999) and it blew my fucking mind. I have finally managed to be able to do all the tricks in it (there’s just one nails trick that has taken 16 years, the rest are doable fairly quickly). Now to try to string them together… See you in another 16 years, I reckon.

Aug 2015

The Magic Flute, EIF 2015

The Magic Flute in the Festival Theatre was absolutely incredible.

The Magic Flute

I didn’t expect it to be so funny (but the story is kind of heavy when you think about it!). Totally my cup of tea.

Aug 2015

InterPlanetary File System (IPFS) and the (potential) future of the internet

I read an article called The Web We Have to Save recently. I really enjoyed it and it provided a lot of food for thought about the current state and future of the internet. I’ve already posted that link on Google+, but it seemed like as a good a time as any to start taking control of my own data on the internet again in the spirit of IndieWebCamp.

Somehow, I got to reading about IPFS (InterPlanetary File System), a new peer-to-peer protocol that looks like a really cool distributed file system. Decentralisation just seems like such a good idea – reduced latency, less centralised control and more much, much more permanence. Interesting and exciting stuff.

Nov 2014

Tear-free Nvidia 770 on Linux

I finally gave up on the nouveau driver for now and have moved to the binary Nvidia one – version 343.22 at the time of writing.

This is mostly for my reference, but in case it’s useful to anyone else, here is a /etc/Xorg.conf.d/20-nvidia.conf that sets my graphics card to full performance when X starts. This gives me tear-free video using two (identical) monitors:

Section "Device"
    Identifier     "Device0"
    Driver         "nvidia"
    VendorName     "NVIDIA Corporation"
    Option         "RegistryDwords" "PowerMizerEnable=0x1; PerfLevelSrc=0x2222; PowerMizerDefaultAC=0x1"

I have an Nvidia GTX 770 and am running Arch Linux without a compositor.

Nov 2013

My first out-of-body experience

This is the email I quickly sent myself immediately afterwards:

I was falling asleep, on and off, on top of my bed fairly early in the evening. It felt like I had woken up and thought I was walking through to the sitting room but something was odd because there was a door on it [there isn’t a door on my sitting room entrance] and it was closed. Somewhat like a lucid dream.

I turned away from the door and suddenly I was back lying on my bed again, still feeling I was awake, but I could sense someone behind me, spooning me. I was only able to turn around very slowly (and could never quite see my face), but I soon realised it was me, dressed exactly like I was and in exactly the same position as me. After what felt like a minute or so of this, I woke up.

Very cool and very much like sleep paralysis but not scary at all.

Apr 2013

Enabling keyboard mouse emulation out with Gnome/KDE

Gnome calls it “Mouse Keys” and it allows you to use something like xmodmap -e 'keycode 135 = Pointer_Button2' to make a key operate as a middle mouse button. If you don’t run Gnome/KDE though, you need to first turn on keyboard mouse emulation yourself by running:

xkbset m
xkbset exp =m

Goodbye gnome-settings-daemon, I won’t miss you.

Apr 2013

User suspend/resume service scripts for systemd

I’m using Arch Linux these days, still with xmonad, and am trying to get away from as much Gnome stuff as possible. I have written these suspend and resume services for systemd to allow unprivileged users to suspend and lock the screen (using slock) and ensure that xmodmap runs on resume. They were adapted from the very useful Arch systemd wiki page and might come in handy for you too.


Description=User suspend actions




Description=User resume actions

ExecStart=/usr/bin/sleep 1 ; /usr/bin/xmodmap /home/%u/.Xmodmap


I’m not sure why I need to add the /usr/bin/sleep 1 in the resume service.

Don’t forget to enable them with systemctl enable suspend@yourusername.service and systemctl enable resume@yourusername.service as well as run systemctl --system daemon-reload whenever you change those files and something stuff like systemctl status resume@yourusername.service to help you debug them.

To suspend, run systemctl suspend as your unprivileged user. Zzz….

Feb 2013

Tarvit Street carrom rules I

Mike and I came up with our own rules for two different games of carrom. This post covers the most traditional carrom-like game. It doesn’t have a name. When playing, the rules feel really nicely fleshed out and we think it’s a lot more fun than traditional carrom. I’ve probably missed some notes that cover odd corner cases here – I’ll add them as I remember them.

Aim and rules

The aim is to pot all pieces of your colour, followed by the red.

Set the pieces up in the standard layout. The player who breaks is always white. Two pieces must fully exit the centre circle or it is a foul.

You play most shots from your baseline, with the striker touching both lines and within the bounds of the diagonals. Unlike some Carrom rules, there is no foul for parts of your body being out with the bounds of the diagonals.

You can strike a piece of any colour at any time. However, you can only play up the table. Specifically, you cannot directly strike a piece that is touching or behind your own baseline. Potting a piece of your own colour means that you play again. Potting the red too early, means that you lose the game.

When all of the pieces of your own colour are down, you play every shot (unless your opponent fouls) from where your opponent’s striker comes to rest.


If a player commits a foul, the opponent is always awarded a vortex. A vortex gives you the option of playing a shot from either your own baseline or one of the four circles on the board (the vortexes). If playing from a vortex, the striker must fit entirely inside the vortex and you can play in any direction.

Missing all pieces on the board is a soft foul, meaning that only a vortex is awarded. All other fouls are hard fouls where a vortex is awarded and your opponent also gets to place one of your potted pieces anywhere in the centre circle. If, while committing a foul, you also potted one of your pieces, it is also removed and placed by your opponent in the centre circle. Hard fouls:

  • Potting a piece of the wrong colour
  • Potting the striker (other than the bonus below)
  • Playing backwards


When striking the red piece first, some bonuses are available:

  • Potting a piece of your own colour (via planting, cannons…) earns a vortex
  • Potting the striker earns a vortex and allows you to remove a piece from the board

Happy pinging!

Jan 2013

Falling over sneezing

I just about fell over sneezing – which is less ridiculous, but just as strange as it sounds.

For about a year after I broke my back, I would, from time to time, have these crazy nerve spaz outs down the front of my legs. They would only last a second or so but, because they were basically like very short-term paralysis, could make me fall over when they were really bad. I always worried it would happen when I was crossing the road!

They diminished over time and after a year or so they had more or less stopped altogether, but I do sometimes get a little glimpse of them when I sneeze or squeeze out a jobby. Today was the first time for years that it has been really strong. Pretty strange and would probably be cool if the implications weren’t so freaky.

Jun 2012

Booting F17 without an initramfs

I prefer not to use an initramfs with my laptop these days – it helps get my boot time down to just over 3 seconds (zooooom – check out these optimisations for more information). Here’s how I configured grub so that I don’t have to edit my grub config every time there is a kernel update. I made sure /etc/grub2/default has these lines:

GRUB_CMDLINE_LINUX="rootfstype=ext4 quiet libahci.ignore_sss=1 raid=noautodetect rd.lvm=0 rd.dm=0 SYSFONT=True KEYTABLE=uk rd.luks=0 LANG=en_US.UTF-8 rhgb quiet"

This isn’t yet quite enough, since I need to point grub at the correct root device. As things stand, grub2-mkconfig doesn’t seem to know about /dev/root.

Also, because kernel updates automatically provide an initramfs and /etc/grub.d/10_linux checks for the presence of that when generating config, I need to run a small script after each kernel update:

Here is /root/bin/move-initramfs-from-boot:

ln -s /dev/sda3 /dev/root && mv /boot/initramfs* ~/initramfs/ && grub2-mkconfig -o /boot/grub2/grub.cfg

UPDATE: my friend Graham has pointed out a nicer way to run scripts after install. Copy his method, I have!

May 2012

$HOME/.ssh/ directory permissions

Because I always forget what permissions SSH needs to make public key authentication work:

chmod go-w $HOME/
chmod 700 $HOME/.ssh/
chmod 600 $HOME/.ssh/*

May 2012

Our Git development workflow

Over the last couple of years we’ve been tweaking our development workflow and it has been really successful for us. It certainly isn’t revolutionary (it is heavily based on the Linux kernel), but it has worked so well and our code quality has improved so considerably that I feel it’s worth writing about. We are a very small team – typically 2 or 3 developers per-project – but I imagine this workflow will only get better at scale. A happy side-effect is that all of our projects are completely setup for remote working. I’m really loving this workflow.

Each project has a maintainer, who is also a developer. This role is simply to be the gatekeeper of origin/master of the Git repo. The maintainer is responsible for checking that a patch has the appropriate tags and is ready for inclusion (see the requirements in point 6 below). These concrete rules (which we do break, occasionally) force us to code review. Contrary to my expectations, I really enjoy the constant review process, from both sides.

We create a new local branch for every feature or bugfix. The workflow of a project is focussed around a PROJECT-devel mailling list. This is where all the patches are posted, reviewed and commented on before being pushed. The reviews are without doubt the biggest win here. We have adopted a strict “no change too small” policy – even a misplaced comma in a comment should be picked up on. This can feel pretty harsh at first, but I’ve found that we soon stop being precious and end up writing much better code anyway. Also, because we’re absolutely sure our commit messages will be read before even touching the repository, they have become a lot more detailed and actually useful.

For the nitty-gritty details, here’s the commit documentation from our projects in full:


Commit workflow

This project is run in a similar vein to the Linux kernel. You will need to
subscribe to <PROJECT-devel@lists.example.com>.

The project is currently maintained by Mark Somerville <mark@example.com>.

The origin/master branch should _always_ be in a deployable state (and almost
certainly be what is actually deployed).

Some notes

* Most code changes should come with appropriate accompanying tests. This
  obviously doesn't apply to things like typo's and there are some other things
  where testing doesn't make sense.


Patches should come appropriately tagged. There are various tags that _should_
be used and others which aren't always required/appropriate.

* Signed-off-by: is the main one. There should be at least one of these on all
  patches by at least the author. Anyone else who handled or was involved in
  the patch or was in its delivery path should also add their Signed-off-by:
  e.g the committer.

  Signing-off a patch is an explicit acknowledgement that you know where it
  came from and that it is, to the best of your knowledge, eligible for
  inclusion in the project.

  The tag would look like:

  Signed-off-by: Mark Somerville <mark@example.com>

* Reviewed-by: says that the reviewer has performed a code review and that the
  changes make sense, look sane and are generally appropriate for inclusion.

  The tag would look like:

  Reviewed-by: Mark Somerville <mark@example.com>

* Tested-by: says that the tester has applied the patch and at least run all of
  the tests using whatever testing makes sense for the given context - it could
  be running `rake` or looking at it in a browser. More thorough tests can be
  performed, of course (and probably should be in some cases). The tag should
  relevant software and versions. For example, it will often include the Ruby
  interpreter and version used.

  We want to support at least MRI (Matz's Ruby Interpreter, the "standard"
  Ruby), version 1.8.7. Some interpreters are below:

  * MRI 1.9.3
  * MRI 1.8.7
  * RBX 1.8.7
  * JRuby 1.9.2

  The tag would look something like:

  Tested-by: Mark Somerville <mark@example.com> [MRI 1.9.3, RBX 1.8.7]
  Tested-by: Mark Somerville <mark@example.com> [RHEL5, MRI 1.9.3, Rails 3.0.11]

* Co-authored-by: is applied to patches that were written by more than one
  author. One example is pair-programming, where the code was created on one
  workstation. In this case the Git Author metadata is set to the owner of the
  workstation and this author would add a Signed-of-by tag, as usual. The other
  developer would add both a Co-authored-by and a Signed-off-by tag.

  The tag would look like:

  Co-authored-by: Mark Somerville <mark@example.com>

Tag ordering

Developers can and should add multiple tags to patches. The basic rule is that
a single developer's Signed-off-by tag should come after his others. If other
developers add tags to the patch, they should be added below.

Example: Mark was the author and Euan was the maintainer at the time:

  Tested-by: Mark Somerville <mark@example.com> [MRI 1.9.3]
  Signed-off-by: Mark Somerville <mark@example.com>
  Tested-by: Mike Lauder <mike@example.com> [MRI 1.8.7]
  Reviewed-by: Julia Allison <julia@example.com>
  Signed-off-by: Euan Maxwell <euan@example.com>

Example: Mark and Julia co-authored the patch on Mark's workstation and Euan was
the maintainer at the time:

  Tested-by: Mark Somerville <mark@example.com> [MRI 1.9.3]
  Signed-off-by: Mark Somerville <mark@example.com>
  Co-authored-by: Julia Allison <julia@example.com>
  Signed-off-by: Julia Allison <julia@example.com>
  Tested-by: Mike Lauder <mike@example.com> [MRI 1.8.7]
  Signed-off-by: Euan Maxwell <euan@example.com>

An exception to the Signed-off-by tag being at the end of a developer's tags
but above some others is when the author is also the project maintainer. In
this case, the author's Signed-off-by is the final tag, because he was the last
person to touch the patch (by committing it).

Example: Mark authored the patch and was also the maintainer at the time:

  Tested-by: Mark Somerville <mark@example.com> [MRI 1.9.3]
  Reviewed-by: Julia Allison <julia@example.com>
  Tested-by: Mike Lauder <mike@example.com> [MRI 1.8.7]
  Signed-off-by: Mark Somerville <mark@example.com>

Tag comments

On occasion, a comment should be added to a tag. Probably the most common use
of this is when the maintainer is ready to push the patch, but wants to perform
some minor tidy-up first (whitespace fixes, commit message alterations).
Because the change is minor this is easier than re-posting to the list.

The comments should be above the tag that is commented on and be of the form:

  [ mark@example.com: just a wee comment, probably no more than a line ]

An example:

  Tested-by: Julia Allison <julia@example.com> [MRI 1.9.3]
  Signed-off-by: Julia Allison <julia@example.com>
  Tested-by: Mark Somerville <mark@example.com> [MRI 1.9.3]
  [ mark@example.com: whitespace and refactored to idomatic Rails ]
  Signed-off-by: Mark Somerville <mark@example.com>

Merging a change

1. When you have made a change that you are happy with, you should commit it to
   your local Git repo with a Signed-off-by tag (see notes above). For commits
   involving code, you probably want to attach a Tested-by tag too.

   This is a good note about commit messages:


2. Generate a patch, probably using `git-format-patch` (or `git-send-email`

3. Email the patch to the PROJECT-devel mailing list (git-send-email is good
   for this) with the subject: "[PATCH] First line of commit"
   (`git-format-patch` will do this for you).

4. When your feature/fix spans multiple commits, you should probably email a
   patchset. This consists of a summary email with a subject like:

     "[PATCH 0/N] Add a teleporting time machine"

   with the commit patches as separate emails in reply to the summary.
   `git-send-email --compose` is very useful for this.

5. Developers comment on the patch(set). Sometimes this will be as simple as
   adding some tags to the commit. Multiple tags by different developers are
   fine (and welcomed).

   Other times, some changes will be needed before the team agree the patch is
   acceptable. If this is the case, you should incorporate the changes and go
   back to stage 2. The difference this time around is that when posting the
   patch during stage 3, the start of the subject should be changed to
   [PATCH v2] to indicate that this is the new version of the patch to review
   and test.

   You should also update the patch changelog. This versioning belongs below
   the commit message and above the diff stat (just below the ---). An example:

     Wrote pseudo-code algorithm for predicting lottery numbers

     Signed-off-by: Mark Somerville <mark@example.com>
     Co-authored-by: Euan Maxwell <euan@example.com>
     Signed-off-by: Euan Maxwell <euan@example.com>
      v2 - Added better comments clarifying the algorithm

      doc/lottery_number_prediction | 154 +++++++++++++++++++++++---------------
      1 files changed, 125 insertions(+), 29 deletions(-)

   When sending this v2 patch, be sure to email the patch as a reply to the
   appropriate patch thread, using the Message-ID you want to reply to.

6. To be acceptable for pushing to master, a commit must have at least one
   Signed-off-by tag (the author) and one or more Reviewed-by/Co-authored-by
   tags. There must also be at least one Tested-by tag that is by someone other
   than the original author (this is to protect against things only working due
   to a quirk of a single development or testing machine). Tested-by tags can
   be omitted for commits that don't need any testing or where it doesn't make
   sense, like documentation changes.

7. Once the patch is acceptable, it is the maintainers responsibility to apply,
   amend the commit to add the extra tags and push it to origin.

Apr 2012

Limiting IRB output

Below is a snippet from my .irbrc file on our production servers, which we access over SSH. It has saved so much frustration by truncating IRB output to 3000 characters. It will, of course, potentially break any code using printf…

module Colours
  Reset = "\e[0m"
  Red = "\e[0;31m"
  Green = "\e[0;32m"
  Yellow = "\e[0;33m"
  Blue = "\e[0;34m"
  Magenta = "\e[0;35m"
  Cyan = "\e[0;36m"
  White = "\e[0;37m"
  BrightRed = "\e[1;31m"
  BrightGreen = "\e[1;32m"
  BrightYellow = "\e[1;33m"
  BrightBlue = "\e[1;34m"
  BrightMagenta = "\e[1;35m"
  BrightCyan = "\e[1;36m"
  BrightWhite = "\e[1;37m"

# Only print the first 3000 characters using printf().
# It would be nicer to only do this for instances of IRB::Irb, but I can't work
# out how to do that in .irbrc or files required there.
module Kernel
  alias_method :old_printf, :printf

  def printf(*args)
    if args.last.length > 3000
      args.last.slice! 3000...args.last.length
      args.last << "#{Colours::BrightCyan} ...\n  ... etc#{Colours::Reset}"
    old_printf *args

I don't understand why something like the snippet below isn't the default:

require "bigdecimal"

class BigDecimal
  def inspect
    "#{Colours::BrightMagenta}#{to_s}#{Colours::Reset} (BD)"

Mar 2012

Finally fixing bufferbloat

I got a new server for the flat to replace my old, and long dead, Mini-ITX machine. It’s setup for various networking duties, the most important of which is the network routing. Now that I’ve got a real machine doing the routing I’ve been able to do some traffic shaping to mitigate the bufferbloat problem in the flat – something I’ve been wanting to do for a long time now.

While the general routing stuff was pretty straightforward, the traffic shaping stuff in Linux scared me. Fortunately, Wonder Shaper exists and saves me trying to wrap my head around tc. It really is rather nice – simply alter a few variables and latency stays not-shit, even when the connection is under heavy load. Ah… :)

My ping times to some Google server on an empty connection are about 18ms. Once another machine saturates the uplink, by uploading a large file, that rises to around 320ms! With traffic shaping, they only rise by a few ms.

EDIT: Take note of Dave Täht’s comments below (he is a lot more knowledgeable than me on these matters), highlighting problems with Wonder Shaper.

For my own benefit as much as anything else, here is my “just got it working” routing script:

# /etc/rc.d/rc.nat:

iptables -F
iptables -F -t nat
iptables -P INPUT ACCEPT

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

Now for the traffic shaping:

# /etc/rc.d/rc.bufferbloat
# Wonder Shaper
# please read the README before filling out these values 
# Set the following values to somewhat less than your actual download
# and uplink speed. In kilobits. Also set the device that is to be shaped.

# Modem reports:
# DOWNLINK=21494
# UPLINK=2463



# low priority OUTGOING traffic - you can leave this blank if you want
# low priority source netmasks

# low priority destination netmasks

# low priority source ports

# low priority destination ports

# Now remove the following two lines :-)

#echo Please read the documentation in 'README' first

if [ "$1" = "status" ]
	tc -s qdisc ls dev $DEV
	tc -s class ls dev $DEV

# clean existing down- and uplink qdiscs, hide errors
tc qdisc del dev $DEV root    2> /dev/null > /dev/null
tc qdisc del dev $DEV ingress 2> /dev/null > /dev/null

if [ "$1" = "stop" ] 

###### uplink

# install root HTB, point default traffic to 1:20:

tc qdisc add dev $DEV root handle 1: htb default 20

# shape everything at $UPLINK speed - this prevents huge queues in your
# DSL modem which destroy latency:

tc class add dev $DEV parent 1: classid 1:1 htb rate ${UPLINK}kbit burst 6k

# From server to internel network

tc class add dev $DEV parent 1:1 classid 1:5 htb rate 100000kbit \
   burst 6k prio 1

# high prio class 1:10:

tc class add dev $DEV parent 1:1 classid 1:10 htb rate ${UPLINK}kbit \
   burst 6k prio 1

# bulk & default class 1:20 - gets slightly less traffic, 
# and a lower priority:

tc class add dev $DEV parent 1:1 classid 1:20 htb rate $[9*$UPLINK/10]kbit \
   burst 6k prio 2

tc class add dev $DEV parent 1:1 classid 1:30 htb rate $[8*$UPLINK/10]kbit \
   burst 6k prio 2

# all get Stochastic Fairness:
tc qdisc add dev $DEV parent 1:10 handle 10: sfq perturb 10
tc qdisc add dev $DEV parent 1:20 handle 20: sfq perturb 10
tc qdisc add dev $DEV parent 1:30 handle 30: sfq perturb 10

# From server to internel network

tc filter add dev $DEV parent 1:0 protocol ip prio 10 u32 \
      match ip dst $IIP flowid 1:5

# TOS Minimum Delay (ssh, NOT scp) in 1:10:

tc filter add dev $DEV parent 1:0 protocol ip prio 10 u32 \
      match ip tos 0x10 0xfc flowid 1:10

# ICMP (ip protocol 1) in the interactive class 1:10 so we 
# can do measurements & impress our friends:
tc filter add dev $DEV parent 1:0 protocol ip prio 10 u32 \
        match ip protocol 1 0xff flowid 1:10

# To speed up downloads while an upload is going on, put ACK packets in
# the interactive class:

tc filter add dev $DEV parent 1: protocol ip prio 10 u32 \
   match ip protocol 6 0xff \
   match u8 0x05 0x0f at 0 \
   match u16 0x0000 0xffc0 at 2 \
   match u8 0x10 0xff at 33 \
   flowid 1:10

# rest is 'non-interactive' ie 'bulk' and ends up in 1:20

# some traffic however suffers a worse fate
	tc filter add dev $DEV parent 1: protocol ip prio 14 u32 \
	   match ip dport $a 0xffff flowid 1:30

 	tc filter add dev $DEV parent 1: protocol ip prio 15 u32 \
	   match ip sport $a 0xffff flowid 1:30

 	tc filter add dev $DEV parent 1: protocol ip prio 16 u32 \
	   match ip src $a flowid 1:30

 	tc filter add dev $DEV parent 1: protocol ip prio 17 u32 \
	   match ip dst $a flowid 1:30

# rest is 'non-interactive' ie 'bulk' and ends up in 1:20

tc filter add dev $DEV parent 1: protocol ip prio 18 u32 \
   match ip dst flowid 1:20

########## downlink #############
# slow downloads down to somewhat less than the real speed  to prevent 
# queuing at our ISP. Tune to see how high you can set it.
# ISPs tend to have *huge* queues to make sure big downloads are fast
# attach ingress policer:

tc qdisc add dev $DEV handle ffff: ingress

# filter everything _from_ the Internet, drop everything that's
# coming in too fast:

tc filter add dev $DEV parent ffff: protocol ip prio 50 u32 match ip dst \
   $EIP police rate ${DOWNLINK}kbit burst 10k drop flowid :1

# This reduces the queues in the driver buffer:
/sbin/ethtool -G eth0 tx 20
/sbin/ip link set dev eth0 qlen 4

Dec 2011

Compiling 32bit Ruby on a 64bit machine

We achieved a reasonable improvement in out test suite run time (~10%) by running a 32bit Ruby 1.8.7 rather than 64bit. I’m not sure why. These instructions are for F16.

You need some 32bit libraries:

yum install glibc-devel.i686 openssl-devel.i686 zlib-devel.i686

Unfortunately, Ruby 1.8.7-p352 doesn’t seem to enjoy to being cross-compiled (at least on my setup). The patch for bug #5108 fixes this problem for me.

Next, configure the build. The most basic configure command that you need is probably something like this:

CFLAGS="-m32 -O2" LDFLAGS="-m32" CXXFLAGS="-m32" ./configure --prefix=/usr/local/ruby-1.8.7 --target=i686-unknown-linux-gnu

After building and installing, you will probably want to install RubyGems again and will need to rebuild any C extensions you use. Of course, building them will require any associated 32bit libraries. The mysql gem is slightly trickier than some:

yum install mysql-devel.i686
gem install mysql -- --with-mysql-config=/usr/lib/mysql/mysql_config

Aug 2011

Waking up from spinal surgery

I was talking about pain this evening with someone and hours later a memory popped into my head that I don’t want to forget. By coincidence, this memory is very close to being exactly 8 years old. Here it is:

My memory of the theatre is only a snapshot, but it is vivid. Upon waking up from my long and quite complicated spinal surgery, I was, despite still being fairly anaesthetized, immediately struck by a pain that was indescribably intense (second only to breaking my back – and even then, only just). I screamed “CUUUUNNNT! THAT IS SO FUCKING SORE!” and at the same time opened my eyes.

My brain wasn’t really keeping up with all the input. There seemed to be about 12 people around me, which was reassuring and made me feel safer, but also highlighted how serious this was. “AARRGGHH – MAKE IT FUCKING STOP!“. A couple of them were holding me down, someone was giving me morphine, a couple of nurses were telling me that everything was fine and that I was alright and the others just seemed to be really busy doing something to help. Then I assume the morphine started to work – my screams faded to shouts and then only words: “FUCK that hurts, fuck, fuck, fuck, oh shit, holy fuck that is sore, oh man… fuck…” and my memory ends.

It was pretty mental.

Jan 2011

Deleting tracks from within Rhythmbox

I was having trouble removing tracks in Rhythmbox (right-click “Move to trash”). Running the application with debugging enabled didn’t do too much help, but the many bug reports of similar problems did.

I have my music stored on a separate EXT4 partition rather than the commonly reported NTFS, so the fix was as simple as creating a .trash-{uid} directory in the root of the mounted partition with the correct ownership and permissions, of course.

Dec 2010

Urchin 0.1.0 released

A few months ago I wanted to teach myself some new shell tricks. One thing led to another and I ended up writing my own interactive shell in Ruby. Urchin exists mostly just for the sake of it, but I’m looking forward to experimenting and implementing some things that aren’t found in other shells.

Urchin does not aim to be POSIX compliant. Finding POSIX shell scripting pretty nasty was one reason I started this project. However, I generally really like the existing standard shells, so many things work in a way you would expect: pipelines, redirections, job control, globbing, environment variables, aliases and tilde expansion are all there. Documentation, not so much!

Urchin recently passed my criteria for a first release – “run as my login shell for a week without crashing or annoying me”. For sure, there are some problems (tab-completion, quoting and escaping issues spring to mind), but I had to draw a line somewhere and just release something.

Trying it out

This still feels very much like a beta release. The chances are you don’t use a shell exactly like me and this isn’t yet a viable Bash/Zsh replacement.

I’ve only tested this release on Linux with GNU Readline. I’d love to hear how it runs on other platforms. Future versions will be tested on more platforms.

Warning: I’d advise testing it out for a while before you get too trigger happy and chsh!

If I haven’t managed to put you off yet, follow the instructions on the Urchin homepage to try it out.