Let’s assume you have a physical machine running a Linux system, and you would like to convert this system into a virtual KVM/QEMU machine, keeping everything as close to the original as possible. What follows is my approach.

The first thing we need is a raw image file which mirrors the exact layout of the physical hard drive in our physical server.

In our example scenario, the physical box has one hard drive at /dev/sda with a /boot Partition on /dev/sda2 and a physical LVM volume on /dev/sda3. This LVM volume houses a volume group with two logical volumes, one of them housing the root partition /, and the other one being unused. Also, /dev/sda1 is unused. Grub is installed into the Master Boot Record.

Code review can be a bit of a recipe for drama. There was a large-ish amount of drama in a close project quite recently that stemmed from patch review, and it got me thinking about how we handle this in free software.

In free software code review, along with other practices that we call “agile practices” (such as continuous integration, unit testing, behavior driven design, test driven development) is a relatively new thing in some projects, especially those on the desktop stack.

I love reading git logs! First, because it reveals the people and processes behind software. Software is not just a bunch of code that works (or more commonly, doesn't work...) - it's also a bunch of people crafting something together for a long time. Not only adding features and fixing bugs, but they also refactor, do dirty tasks and ugly workarounds, explaining their motives in the commit messages.

A second, more concrete reason - quick access to git history helps me make better software. It helps me find out when and how exactly a bug was introduced, learn whom to talk to about a certain change or code, or simply find a desired code snippet in a huge repository - even if it was already deleted. Am I stating the obvious here? I guess so! but I do believe that sometimes this tool is underestimated and underused.

Of course, the better we know git's secrets, the more effective use of git history we could make. I'll try to share here some useful tricks I've collected in the recent years... I bet you know some; I believe you may still find some of them useful.