Another update regarding the use of GitHub Flavored Markdown on GitHub Pages. GitHub Pages has updated its Jekyll version to 3.0 on the first of February 2016.
This update includes a switch to kramdown as its Markdown parser as well as only supporting Rouge as syntax highlighter. This means we’re effectively back to the original setup from 2013 but because all of these components have received some updates in the meantime everything is now supported out of the box.

Warning: This is all fairly new stuff, my machine locked up if I had run a Virtualbox machine prior to starting an xhyve machine. Don’t say I didn’t warn you ;)

Xhyve is a new hypervisor in the vein of KVM on Linux and bhyve on BSD. It’s actually a port of BSD’s bhyve to OS X.
It’s more similar to KVM than to Virtualbox in that it’s minimal and commandline only which makes it a good fit for an always running virtual machine like boot2docker on OS X.
This post documents the steps to get boot2docker running within xhyve and contains some quick benchmarks as well to compare xhyve’s performance with Virtualbox.

Update: As of the first of February 2016 GitHub Pages handles GFM, footnotes and syntax highlighting out of the box, no configuration required.
See this new post for more details.

In contrast to what I wrote 1,5 years ago it’s now possible to use all of GitHub Flavored Markdown’s features combined with footnotes and syntax highlighting on your Jekyll site whilst still having GitHub Pages build your site for you.
Building your site locally and then pushing the resulting HTML is a thing of the past! :)

After I decided to switch this blog over from Jekyll to Nikola the first thing to do was to configure Nikola to my liking.
Nikola offers plenty of options to configure, as of this writing it has more than 100 settings for all of its options! Since I want something as lean as possible some tweaking and workarounds were necessary to make it work the way I wanted to. This post will cover the way I configured Nikola.

One of the most useful features of a Linux shell I often use is sourcing of files. Sourcing a file basically means that the file’s code is run as if you typed it in yourself. Everything the code in the file does is applied to the shell you’re currently using and all its global variables are added to your current shell. It’s also possible to do this in Python, with the function execfile.

LXC (LinuX Containers) offers a lot of the advantages of (para)virtualisation with the added benefits that it can run on any kind of hardware (it doesn’t need hardware support for virtualisation) with lower overhead than virtualisation.
The virtual environments that LXC provides are comparable to a chroot but LXC adds control over the virtual environments resources like CPU-time and network-usage and offers more isolation.
This also means it’s only possible to run the same “family” of guest operating systems as the host. I.e. it’s not possible to run Windows using LXC, but it is possible to run different Linux distributions like a Debian and Fedora guest on an Arch Linux host.
Note that if you need a really secure environment LXC isn’t the right choice, stick with paravirtualisation like KVM or XEN instead.

Just quick heads-up in case someone is wondering why his or hers <h1> isn’t looking like they expect.
Modern browsers apply different styling for <h1> elements inside a <div> vs inside one of the new semantic elements like <article>, <aside>, <nav> or <section>.
This is because these new semantic elements influence the document outline and the modern browsers try to show that to you in a graphical way.

Update: As of Jekyll 2.0.0 it’s possible to have our GitHub Pages cake and eat it :)
See this new post for more details.

Jekyll uses redcarpet as its default Markdown parser for newly generated sites as of version v1.1.0. It does so by setting markdown: redcarpet in _config.yml.
Redcarpet is the markdown parser used by GitHub, but in its default config it actually doesn’t parse using the GitHub Flavored Markdown (GFM) rules.