#ifdef linux

It's a well known principle of software engineering that the earlier bugs can be caught, the lower the overall cost. As such, testing needs to happen at every level. Once your project is at the coding stage, the earliest form of testing is on the code itself , not on the binaries the compiler produces. We run a variety of tools over critical codebases such as Upstart and Whoopsie regularly to identify issues well before they "escape into the wild". These tools include Coverity Scan  (see the list of projects already using it ). If you really care about your code and you are involved with a C, C++ or Java project, I'd strongly encourage you to take a look at this awesome tool. If you aren't directly involved in such projects, try contacting those running them and suggesting they use Coverity. The Coverity Scan service is entirely free for OSS projects. You will need to register to obtain an account and then download the client analysis tool. Once setup, a...

What changed? Sometimes, when using VCS systems such as bazaar, there is a tendency to forget to perform the necessary 'book-keeping' for those not using it because you get so focused on the tooling itself. Most VCS systems expect the author to provide a brief explanatory message per commit. This log is invaluable since it (hopefully!) provides insightful context into the programmers intentions. However, that meta-data is only available to those with a copy of the branch/checkout/stream/view or whatever your VCS calls it. But what about those who only come into contact with the project via release tarballs for example? I'm thinking specifically of changelogs. Debian and Ubuntu provide the incredibly useful ' dch ' (aka debchange ) tool which synchronises the VCS commit message with the latest ' debian/changelog ' file entry. But what if you're not working on a Debian project? When you're working on a fast-paced project, or just working at a...

Introduction The NIH Utility Library ( libnih ) is a small, efficient and most importantly safe library of general purpose routines. It was written by Keybuk so you can be assured that it is extremely elegant, well-designed, well-tested (includes 2863 tests currently!) and well-written. NIH is used by Upstart, the event-based init daemon which is used by: Ubuntu Desktop Ubuntu Server Ubuntu Cloud RedHats RHEL 6 Chromium OS  (and Chrome OS) That's a lot of deployments of Upstart and NIH around the world!! (And we're not even including mobile device operating systems in that list). But why not just use glib I hear you ask? Well, glib is a very large library whereas NIH is small and designed for low-level daemons and systems which may be resource-constrained. Also, lets not forget that NIH, like Upstart , comes with a very comprehensive test suite so bugs are rare. Other reasons to use NIH: It handles garbage collection for you That's rig...

Yesterday, whilst hacking on a particularly large Upstart C file in the awesome vim editor, I inadvertently 'put' a huge amount of data, caused by my mis-specifying the marks when I had originally yanked the text. Still unaware of the problem, I then compounded the problem nicely by continuing to make further changes to the file and dug myself an even bigger hole by saving the file and exiting vim. Attempting to compile the now totally invalid code resulted in a seething mass of mocking gcc warnings until it eventually gave up in disgust. Thankfully, I was taking regular backups with rsnapshot and I had the bzr branch history to fall back on. But it still took some time to perform the 3-way diff and get back to my latest changes. Later on, we had our weekly IRC meeting in #ubuntu-meeting . I use irssi and as I pasted my weekly status update, since I was pasting more than a single line, irssi gave me a helpful warning and the option to either proceed, or abort the mult...