Interview: Lars Wirzenius

Lars Wirzenius will give a talk about "Re-thinking system and distro development" at FOSDEM 2012.

Could you briefly introduce yourself?

I'm a hacker, programmer, software developer. I am 42, originally from Finland, and now live in Manchester, UK. I've been programming computers since 1984. I read the GNU Manifesto in 1986, but didn't really become interested in software freedom until 1988, when I got into university and got access to the Internet, both of which gave me contact with other programmers for the first time.

While at university I got involved in kicking off Linux, co-founding the Linux Documentation Project and writing one of their initial books, co-moderating comp.os.linux.announce, joining the Debian project, generally messing about. Since then, I've worked in a number of places, doing all sorts of hackery kinds of things, such as database engine development, language design and implementation, embedded development, Internet server development, etc. I have had a ton of personal projects, too, some of which have been released. My current personal project is Obnam, a backup program.

The one long-term constant has been my participation in the Debian project as a package maintainer. I've done a bunch of different things for Debian, and generally poked my nose in places. This has given me a good sense of the job of developing and maintaining a large Linux distribution.

I now work for Codethink, in Manchester. We do many kinds of software development for clients. Last year, we started a new embedded systems project, Baserock, in which we try to solve all the problems we see with the way Linux embedded development is currently done.

What will your talk be about, exactly?

I'm still hammering out the scope and details, but essentially, I think Linux distributions and systems development can be improved a lot. In the past fifteen years or so, there's been a remarkable improvement in how good quality software is developed. There is still no silver bullet, but a bunch of good practices have emerged: most importantly, automatic test suites with good coverage, distributed version control, and continuous integration. None of the big Linux distributions are using these in a systematic fashion. There's bits and pieces here and there, but it's not pervasive, and you get a lot more benefit from them if they're pervasive.

What do you hope to accomplish by giving this talk? What do you expect?

I want to raise these issues I see, and get people to discuss them, and to invent solutions. I have some ideas for solutions myself, of course, which I'll be mentioning in the talk, but it would be most important to have a lot of people think about this.

I am not ready to present working code yet. This is going to be at the conceptual level, to provoke people into thinking.

What are the biggest issues of packages as a central concept of Linux distribution development?

Colin Walters has an excellent term for the problem: combinatorial explosion. Debian has over thirty thousand packages now. That means that everyone's life gets harder. Perhaps most importantly, everyone is running an almost unique system: they have a different set of packages, and their versions, installed, and while this usually works fine, it's not good for achieving high quality or for figuring out problems.

In your blog article On the future of Linux distributions you propose to build a complete system from source, which makes it easier to do large changes by branch and merge. This looks similar to the development model the BSDs are using. So would you say Linux distributions should shift from their 'bazaar' model to a more 'cathedral'-like model?

I'm not sure I agree with describing the difference in those terms, but in any case, I don't want a cathedral. Quite the opposite, I want a bazaar where it's easy for anyone to branch the entire system and make any changes they want, and use automatic testing to know things still work. I also want it to be easy to merge those changes back into a main line of development, if they're deemed suitable.

The current model is that everyone works on their own little package, and sometimes on groups of packages, and all changes happen interleaved, meaning that changes often conflict, and it's hard to know what broke, what the cause was, and therefore it's unnecessarily hard to fix things.

In essence, I want to do git branching and merging at the level of the whole distribution, but I want to do it efficiently, because otherwise there's no point in doing it at all.

You're now working for Codethink as part of a team that develops the embedded Linux system Baserock. Could you tell us more about what is special about Baserock's approach?

We'll talk more about Baserock later. For now, it's a platform for me to play with these ideas for systems and distribution development, so that's what special about it right now: it's a chance to experiment without having to carry a big historical burden, which gives us a lot of freedom to try new things.

Were your ideas about the future of Linux distributions influenced by Baserock's design or was it the other way around?

Both, actually. I had already started thinking about these problems before I ever heard of Baserock, and before I started working for Codethink, but the ideas from others at Codethink have greatly affected my own thinking too.