Interview

People behind Debian: Ana Beatriz Guerrero López, member of the Debian KDE team

February 10, 2012 By Raphaël Hertzog 8 Comments

If you met Ana, you’ll easily remember her. She has a great and pronounced Spanish accent… I’m glad that the existence of the Debian Women project helped her to join Debian because she has been doing a great job.

From KDE packaging to publicity/marketing work, her interests shifted over the years but this allowed her to stay very involved. As she explains it very well, Debian is big enough so that you can stop doing something which is no longer fun for you, and still find something new to do in another part of Debian!

Read on to learn more about Ana, the KDE team, Debian’s participation to the Google Summer of Code, and more.

Raphael: Who are you?

Ana: I’m Ana Guerrero López and I’m in my early 30s. I was born and raised in the wonderful city of Sevilla, Spain and I live in Lyon, France. I share my life with another Debian Developer and my paid work is doing Debian support and integration, so you won’t be surprised to read that Debian is a big part of my life.

Raphael: How did you start contributing to Debian?

Ana: Although I knew about the existence of Linux since 1997 or so, I didn’t really start using Linux until the summer 2001 when I finally got a computer on my own and an Internet link at home. In the beginning, I was using Mandrake in a dual boot with Windows and later around 2003, I happily moved to only using Debian and ditching the Windows partition. Once settled as a Debian user, I knew anybody could help improve the distribution but I hesitated to join mostly due to two reasons, my perception of Debian was the one of a very elitist and aggressive club and who wants to join this kind of cult^wproject? And even if I wanted to join, I did not know how to get started.

By the summer of 2004, the Debian Women project started, it made me seeing Debian as a more welcoming project, and I started maintaining my first packages. The following summer 2005, I attended akademy 2005 (the annual KDE conference) where I had the pleasure to meet there some of the people from the KDE team and this really made a difference for me. Christopher Martin and Adeodato Simó, with the help of other people, have started the maintenance of KDE as a team a few months before and by that time most of the KDE modules where under the maintenance umbrella of the team. This was a very good move since it allowed easily to share the KDE maintenance in a more coordinated way and also eased having non-DDs, like me at that time, to join in and help.

The Debian Women project started, it made me seeing Debian as a more welcoming project.

Raphael: You’re part of the Debian KDE team. What’s your role in the team and what are your plans for Wheezy?

Ana: Nowadays, I am not as active in the KDE team as I used to be in the past. The KDE 3 to KDE 4 transition was quite tiring and changes on the KDE side like the successive marketing renames, the shorter 6 months schedule (it used to be at least 9) or the uncoordinated KDE releases mostly burnt me out. Currently, I am mostly working in helping others to get started within the team, some small fixes here and there, and helping with the uploads: an upload of the full KDE suite to the archive requires some building power and upload bandwidth not everybody have.

For Wheezy, with the tentative freeze date in June, the plan is to try to ship the latest possible point release of the KDE 4.8 series. The first release of the series, 4.8.0 was released a couple of weeks ago and while writing these lines, the packaging work for 4.8 hasn’t started yet. The next move for the team is getting 4.7.4 in unstable, currently sitting in experimental.

For Wheezy, […] the plan is to try to ship the latest possible point release of the KDE 4.8 series.

Besides the KDE packages, there is some software which users perceive as KDE, such as amarok, digikam, etc., which are not part of KDE but fall under its umbrella. These other programs have their own maintainers and their updates depend greatly in the availability of them. For the KDE office suite, we have right now KOffice in the archive. KOffice got a fork some time ago named Calligra and we should replace KOffice by Calligra in the archive before the release of Wheezy. Sadly there isn’t yet a final release of Calligra to use.

My personal goal for Wheezy was to finish the removal of all the remaining packages depending on KDE 3 and Qt 3 that Squeeze still contained. The removal of the KDE 3 libraries and all the packages using them was quickly achieved after the release of Squeeze. The removal of Qt 3 soon showed that it was task harder than expected since some popular packages (sometimes not in the Debian archive, e.g. third-party scientific software) depend on it, and also Qt 3 is a requirement for LSB compatibility. Right now, Qt 3 has been orphaned for 9 months and nobody has shown any interest in adopting it.

Raphael: KDE, much like GNOME, has been forked by people who were unhappy by the direction that the project has taken since version 4 (cf Trinity). What’s your personal opinion on KDE 4.x and what’s the position of the Debian KDE team concerning this fork?

Ana: I use KDE 4 on my laptop and I think it is a solid desktop environment and platform. However I am finding it less and less attractive for me. On one side, my usage of the computer has been slightly changing and on the other side, I do not like how the new developments in KDE are evolving, things like plasmoids or activities are not attractive for me. I have switched my other 2 systems to awesome although I continue to use mainly a bunch of KDE applications: dolphin, konsole, kate, juk, kmix, etc. So you might say my desktop environment is an awesome KDE.

Regarding the Trinity project, a lot of users complained very loudly when KDE 3 got replaced by KDE 4 in testing/unstable, so I find quite laudable the decision of some users to act instead and try to continue with a forked development of KDE 3. However the Trinity team seems to be about 3 persons (funny for a project named Trinity ) while KDE 3 is big. In perspective, it does not look that big because KDE 4 is even larger, but it is still too much for such small team. In addition those developers need to maintain Qt3 that has been end-of-lifed years ago by Nokia/Trolltech¹. So my guess is that sooner or later the project will fade away.

Nobody from the KDE team is interested in Trinity and in case someone wants to package it for Debian, they would have to make a new team. For the reasons mentioned above: Qt3 maintenance and reduced upstream group, this would be a bad idea.

My advice if you do not like KDE 4 and you miss KDE 3, would be taking a look at razor-qt based on Qt4 and quite similar to KDE 3.

¹ I read they have plans to port it to Qt4, but frankly that could take some years… same it took to the KDE project for KDE 4.0.0

Raphael: You used to maintain news.debian.net, a WordPress blog dedicated to Debian, but you stopped a while ago. A few months later you started to maintain a Debian page on Google+. Why did you stop the blog and what’s your goal with the Google+ page?

Ana: I blogged about the reasons I started news.debian.net. In short, I thought Debian needed a better system to publish news, something like a blog. I first tried to suggest the idea to the press/publicity team but they weren’t interested, so I started the project alone. IMHO the blog worked quite well and I was feeling like it should be made official. I talked about this with some people but at the time I wasn’t pushing it because I had other priorities and I knew pushing it to become official would need some extra time and energy.

Stefano decided to start the discussion about making news.debian.net official (that’s moving it to a debian.org domain) in its own initiative. After the public discussion and some private exchange of emails with DSA, the situation became frustrating and I decided to close news.debian.net after the release of Squeeze.

Later, during DebConf, an officer from the press team announced they were launching a blog and I asked Stefano if he could try to have a discussion about this to see if it could still somehow fit my ideas, and maybe contributing myself, but nobody from the press team answered Stefano’s email and the blog hasn’t started yet either.

Irony that communication didn’t work when wanting to improve communication.

About the Google+ page, everyday I follow what is going in Debian and quite often I find things I want to share. I do not want to clutter my own profiles with Debian stuff or have people following me because of that, so I decided to create the Debian page when Google+ made them available. I like the fact that people can follow that without having an account in Google+ although they can not comment anonymously. I am not happy about the fact that Google+ is a closed platform but hopefully the data will become easier to export in the near future. Right now, there are some services that provides RSS feeds of Google+ pages if you want to follow the page and you are not in Google+ (or I could setup one if several people ask me).

Raphael: Last year you helped to manage Debian’s participation to the Google Summer of Code. How did it went? Is there something that you can improve for this year?

Ana: I think last year we managed to have people in Debian more aware about what the students were doing. That also helped students to get more feedback and therefore get to know more people in the project and get more integrated. Students were sending periodic public reports available to everybody interested in the status of the projects and some of them also held their own sessions in DebConf.

We still failed to start looking for mentors early enough and to give them information about how the GSoC worked and how they could have a successful project. Having good projects in Debian is harder than in other projects because the GSoC mostly promotes having students started in Open Source *coding* for a project, while Debian is more a project about integrating software and we overall do not have so many parts that has to be coded.

My personal goal for this year is to try getting the projects earlier to attract good students from the very beginning, even if that means we have less projects than in other years.

Raphael: What motivates you to continue to contribute year after year?

Ana: Three things. I like improving the OS I use, I like the friends I have made while working in Debian through the years and because I have fun.

Also Debian is quite a big project, so if you become tired or burn out working in some area, you always can easily find interesting things to do somewhere else.

Raphael: Is there someone in Debian that you admire for their contributions?

Ana: Adeodato Simó, he is now in a long leave from the project, but it is one of those persons who made a difference in the project in his job in the release team some years ago. Aurélien Jarno because of his tireless work in (e)glibc and porting of several architectures.

I also have special admiration for all those people who have been very active in the project for more than 7-8 years because I know it is not always easy to combine it with real life.

Thank you to Ana for the time spent answering my questions. I hope you enjoyed reading her answers as I did. Note that older interviews are indexed on wiki.debian.org/PeopleBehindDebian.

Subscribe to my newsletter to get my monthly summary of the Debian/Ubuntu news and to not miss further interviews. You can also follow along on Identi.ca, Google+, Twitter and Facebook

People Behind Debian: Josselin Mouette, founder of the Debian GNOME team

January 27, 2012 By Raphaël Hertzog 9 Comments

Josselin Mouette is one the leaders of the pkg-gnome team, he takes sound technical decisions and doesn’t fear writing code to work-around upstream issues. He deserves kudos for the work he has put into packaging GNOME over the years. He can also be very sarcastic (sometimes he even enjoys participating to flamewars on debian lists), and there are quite a few topics where we have long agreed to disagree. But this kind of diversity is also what makes Debian a so interesting place…

Read on to learn more about the pkg-gnome team, its plans for Wheezy, Josselin’s opinion on the GNOME 3 switch, and much more.

Raphael: Who are you?

Josselin: I am a 31 years old Linux systems engineer. I started in life with physics, which I studied at the ENS Lyon. I started a thesis on experimental and numerical models for optoelectronics, but when it became clear that research was not for me, I abandoned it and accepted a job at the CEA, which holds the largest computing center in Europe. Working on these machines has been the most awesome job ever (except for it being near Paris). After that I worked a bit on system monitoring technologies.

I am married, currently living in Lyon, and working for EDF (the French historical electricity company) on scientific workstations using Debian. EDF is using Debian on more than a thousand workstations and holds the fastest Debian supercomputer in the world (200 Tflops), which makes it another obvious place for Debian developers.

Raphael: How did you start contributing to Debian?

Josselin: I discovered Debian in 1999 while studying at the ENS, which is one of the biggest nests of Debian developers – while being a small place, it is producing almost one Debian developer per year on average. After wondering for a while what it could be useful for, hacking on a slink snapshot made me think that it was for, well, everything except for gaming. Later, in 2002, when I was working on optoelectronics computing codes, I started to package them for Debian in order to make them easier to install, for us as well as other labs over the world. I started the NM process, and it was going smoothly but also going to take time. However, at that moment, the frozen-bubble game went out and made quite some buzz. Since I knew a guy who knew the game’s developer, he asked me to package it. The package found 3 sponsors in a very short time and was fast-tracked into the archive at a speed that was unseen before. After which the NM process was completed very quickly.

At that time, I was a heavy WindowMaker user, but I didn’t like the direction the project was taking (actually, I wonder if there was one). GNOME was starting to become attractive, but its packaging in Debian was very ineffective, with many inconsistent packages maintained by people who didn’t ever talk to each other – some of them didn’t speak English, and some of them didn’t talk at all. Together with awesome people, among which Jordi Mallach, Gustavo Noronha Silva, JHM Dassen, Ross Burton and Sébastien Bacher, we started the GNOME team in 2003, introducing consistent packaging practices, and initiating synchronized uploads. Releasing a completely integrated GNOME 2.8 in sarge was a considerable achievement; proving (together with the Perl team) that a team was the best way to maintain large package sets changed the way people work on Debian.

“Proving […] that a team was the best way to maintain large package sets changed the way people work on Debian.”

Raphael: You’re one of the most active contributors of the team which is packaging GNOME for Debian. What would you suggest to a new contributor who would like to help the team?

Josselin: There are several ways to contact the team, but the recommended one has always been IRC. We hang on #debian-gnome on the OFTC network, so just come around and ask for us.¹ The real question is what you want to do in the team. Of course, most new volunteers want to help packaging the latest and greatest version of GNOME into unstable as soon as possible, but unless they already have Debian background, this is not the easiest task. Since there are already people working on this, the “big” packages are usually waiting on dependencies.

I used to direct newcomers towards bug triage, but it is a tedious task and I’m now convinced that our huge bug backlog will never be dealt with. The most useful thing to do for newcomers now is probably to find a GNOME or GNOME-related package that needs improvement or is lagging behind, and simply try to work on it. You can also come and fix the bugs you find annoying. Find a patch on the GNOME bugzilla, or cook it yourself, propose it, and if it’s worthy enough you’ll soon get commit access.

“Our huge bug backlog will never be dealt with.”

¹ At this point I feel worth mentioning that if no one answers in 10 minutes, it doesn’t mean that no one will answer in 2 hours, so please stay on the channel after asking.

Raphael: There’s been some controversy about GNOME 3 and the direction that the project is taking. What’s your personal stance on GNOME 3? And what’s the position of the pkg-gnome team?

Josselin: The controversy is not new to GNOME 3, but the large-scale changes made with it have put it more prominently. The criticism usually boils down to a few categories:

General lack of configurability
Strange design decisions
Red Hat centric development
Hardware requirements
Change resistance

The lack of configuration options has been an ongoing criticism since GNOME 2.0 has decided to rip off most of them. Of course, when the control center was redesigned again for 3.0, there was a surge of horrified exclamations from people who missed their favorite buttons. On this topic, I fully concur with GNOME developers. The configuration option that is useful for you is not necessarily useful for someone else. Of course, sometimes developers go a bit too far, but the general direction is right. At work, we found that only a minority of users actually configure anything on their desktops: they just want something that works to launch their applications. Apple and Google have sold millions of devices by making them the simplest possible and without any configuration.

Design decisions are, on the contrary, individual decisions, and each of them, while having reasons behind it, can be questioned. I remember seeing a lot of complaints when the OK and Cancel buttons were reversed in dialog boxes, something that nobody questions anymore. GNOME Shell is full of such changes; some are easy to get accustomed with, some others just make eyebrows raise. The most obvious example is the user menu in GNOME 3.2, which contains an entry to configure your Google account, but no entry to shutdown the computer. Both decisions were taken independently, each of them with (good or bad) reasons, but the result is simply ridiculous. The default configuration in Debian will contain an extension to make it a bit better, but on the whole we don’t intend to diverge from the upstream design, on which a lot of good work has been done.

“On the whole we don’t intend to diverge from the upstream design, on which a lot of good work has been done.”

Point 3 is more complex. Red Hat being the company spending the most on GNOME, it is obvious that their employees work on making things work for their distribution. An example is the recurring discussions about relying on system services that are currently only implemented by systemd. Since there is a lot of (mostly unjustified) resistance against systemd in Debian, and since it won’t work on kFreeBSD anyway, someone needs to develop an alternative implementation of these services for upstart and sysvinit. Everything is in place for someone else to do the job but it has to be done, and this can be frustrating. Especially since it can also be hard to integrate changes needed for other distributions¹.

Hardware requirements are mostly a consequence of the previous criticism: there’s hardware that most distributions just don’t want to bother supporting. We’ve seen it in squeeze with the introduction of a hard dependency on PulseAudio. The Debian GNOME team (together with the Gentoo maintainers) made this dependency optional, carrying heavy patches, in order to cover the cases where it does not work. Now that it has gained more maturity, making this effort obsolete, the new tendency is to require 3D acceleration. For various reasons, it is not available to everyone². On this matter, the position of the Debian GNOME team has always been to support as much different configurations as possible with reasonable effort. Thanks to efforts from the incredible Vincent Untz, upstream supports a so-called “fallback mode”, which is the GNOME panel from 2.x with a lot of its bugs fixed. We intend to support this mode for as long as reasonably possible in Debian, possibly even after upstream ends up dropping it. However, other applications are going to require 3D because GStreamer is moving to clutter too, affecting video playback performance on non-accelerated systems³. For epiphany this is not a problem; only embedded video will be affected. But for totem, this is a major issue; because of that we will probably keep totem 3.0 in wheezy.

Finally, there is a natural human tendency to dislike change (I have it too), and it applies a lot to desktop users’ habits. Needless to say a change of such a scale as introducing GNOME Shell can trigger reactions. However, I don’t think it is reasonable, because of this resistance, to keep gnome-panel 2.x in Debian. This would be a lot of work on obsolete technology, and would prevent the upcoming removal of a lot of deprecated libraries. This time is much better spent improving gnome-panel 3.x in Debian and keeping the “fallback mode” great. One of the change that was made in Debian was to make it easier to find, being available as “GNOME Classic” directly from the login manager, instead of having to find it in an obscure configuration panel. In all cases, I would recommend to actually try GNOME Shell for a few hours before ditching it. I had never been accustomed to a new environment as quickly ever before.

“In all cases, I would recommend to actually try GNOME Shell for a few hours before ditching it.”

¹ Having seen several of my GDM patches reverted without a warning, I know we are not finished with carrying patches in Debian packages.
² Scientific workstations are a non-trivial example, since there is a measurable effect of using 3D in the window manager on heavy 3D applications.
³ On the other hand, on accelerated systems, this feature should end up improving performance a lot.

Raphael: What are your plans for Debian Wheezy?

Josselin: The first goal of the GNOME team is, of course, to provide again a great desktop environment to work on. For wheezy it will probably be based on GNOME 3.4. There also needs to be some work on package management interfaces. Upstream bases everything on PackageKit, but it is not as featureful as the aptdaemon Ubuntu technology. If I have time, I would also like to improve HTTP proxy support, since currently it is based on a stack of terrible hacks.

Raphael: If you could spend all your time on Debian, what would you work on?

Josselin: Obviously I would like to make GNOME in Debian even better. That would imply working on underneath dependencies (what we now like to call plumbing) to make sure everything is working great. This would also imply working more as GNOME upstream to make it more suitable for our needs.

I would also work on large-scale improvements on the distribution, like conditional recommends which I’d love to see implemented¹, or automatic build-dependency generation. I would also work on the installer to make it better for desktops machines.

¹ The idea is to automatically install language packs, or glues between two packages when both packages are installed.

Raphael: What’s the biggest problem of Debian?

Josselin: The obvious answer is the same as the one most people you interviewed before gave: not enough members in core teams. A lot of developers join Debian to work on a small number of pet packages, and don’t necessarily want to be involved with existing teams. It is probably still not obvious enough that the primary way to start contributing to Debian is to join an existing team.

But if there is one thing that is preventing Debian from gaining more momentum now, it is a completely different one: the too short support timeframe. 3 years is really not enough for corporate users. One year to migrate from one version to another is too short, and it is not possible to skip a release. It is definitely possible to change that with reasonable effort: the long-term support after 3 years doesn’t have to cover the same perimeter as the short-term one. For example, we could upgrade the kernel to the version in the current stable release, and stop fixing all non-remote security holes. The important thing is to cover the most basic needs: companies are ready to take the risk of having less support if it allows skipping a version, but not the risk of having no support at all. And even more important is to say that you do something. Red Hat says they support a release for 10 years, but of course after 5 years the supported perimeter is extremely small.

“3 years [of support] is really not enough for corporate users.”

Long-term support will not magically fix all problems in Debian, but it will bring more corporate users into the picture. And with corporate users come paid Debian developers, who can work on critical pieces of the system. Debian was built on the synergy between individuals and companies, and in recent years – perhaps as a reaction against what happened with Ubuntu – we’ve kind of forgot the latter. A lot of individuals have joined the project, and they are actively working, for example, on shortening the release cycle, which goes against the interest of professionals. We should embrace again such users and developers, and that means adapting to the current needs of larger entities.

Raphael: You’re the maintainer of python-support, a packaging helper that was competing with python-central. Both helpers are now deprecated in favor of dh_python2. Does this mean that the situation of Python in Debian is now sane? Or are there remaining problems?

Josselin: dh_python2 (and the Python3 version, dh_python3) has a sane enough design. It fixes a lot of issues in python-central and also python-support, at the expense of somehow reduced functionality for developers. However, just like the previous tools, it merely works around design mistakes in the Python interpreter. For example it is not possible to split binary modules, pure-Python modules and byte-compiled modules in different directory trees, like Perl does – although PEP 3147 introduces a way to do so. There is still no sane and standardized way to deal with module versions. There is no difference made between the module (which is a part of language semantics) and the file containing it (an information which depends on the implementation). Developers heavily rely on introspection features and make assumptions based on the implementation, that make it impossible to work around problems with module files.

Such problems are not restricted to Python. Those who fought against Ruby gems could tell even worse stories. While introducing GObject introspection packages in Debian (they can be used in JavaScript and Python to provide modules based on GObject libraries), I was pleased to see a clear distinction between file and module, but I was again struck by the fact you are not forced to declare API versions in your Python/JS code. In all cases, there is no reliable way to detect runtime dependencies in a given Python or JavaScript file, which leaves the maintainer to declare them by hand, and of course, often be wrong about them. Add to that the fact that most errors cannot be detected before runtime. For all these reasons, and while still being fond of Python for scripts and prototyping, I’ve become really skeptical of using purely interpreted languages to write real applications. Some GNOME developers are moving away from Python and JavaScript, mostly towards Vala; I can only approve of that move and hope the same happens to other projects.

Raphael: Is there someone in Debian that you admire for their contributions?

Of course there is the never-sleeping, never-stopping, Michael Biebl who can upload a whole GNOME release in a single week-end. But there are a lot of awesome people who make Debian something that simply works. I could talk about Cyril Brulebois from the X strike force, Julien Cristau from the release team, Sjoerd Simons for his sound advice and work on plumbing, Luca Falavigna who is so fast at processing NEW, to quote only a few of those I work with frequently. And of course, Jordi and Sam for their humor.

Thank you to Josselin for the time spent answering my questions. I hope you enjoyed reading his answers as I did. Note that you can find older interviews on http://wiki.debian.org/PeopleBehindDebian.

Subscribe to my newsletter to get my monthly summary of the Debian/Ubuntu news and to not miss further interviews. You can also follow along on Identi.ca, Google+, Twitter and Facebook

Filed Under: Debian News, News Tagged With: Debian, Interview, Josselin Mouette, pkg-gnome, python-support

People Behind Debian: Steve McIntyre, debian-cd maintainer, former Debian Project Leader

January 13, 2012 By Raphaël Hertzog 2 Comments

Steve McIntyre has been contributing to Debian since 1996, 2 years before I joined! But I quickly stumbled upon Steve: in 1999, he was struggling with getting his debian-cd script to produce 2 ISO images (it was the first time that Debian did no longer fit on a single CD), I helped him by rewriting debian-cd with a robust system to split packages on as many ISO images as required.

I remember those times very well because Steve was very supportive of my efforts and it was a real pleasure to get this done. His friendly nature probably also explains why he got elected Debian Project Leader twice!

Anyway, enough history, check out his interview to learn more about the great work he’s doing nowadays. My questions are in bold, the rest is by Steve.

Raphael: Who are you?

Steve: I’m a professional software engineer, 37, living in Cambridge (England) with my new wife Jo. I studied for the EIST degree at the University of Cambridge, then (like many people here, it seems) I just forgot to go home again afterwards and settled here. I spent more of my “study” time playing with Linux than working on my degree, so I guess I’m lucky that it worked and I found a career in that area!

Raphael: How did you start contributing to Debian?

Steve: During my time in college, I started hacking on software in my free time, using Slackware as my first Linux distribution from the middle of 1994. After encountering more and more problems with Slackware, I was encouraged by a number of friends to make the jump over to Debian and in October 1996 I did. The installation process back then was much harder than anything people see today, but after a long weekend I finally had my Debian system up and running.

I was already one of the main upstream developers for the Mikmod music player at that time, so that very same weekend I applied to be a DD so I could maintain it in Debian too. Back then, the NM process was much simpler: I just mailed a key to Bruce and he set me up with an account almost immediately!

I then found that Joey Hess had beaten me to it and already packaged Mikmod. Grrr!

Raphael: What’s your biggest achievement within Debian?

Steve: Without a doubt, my proudest achievement within Debian is being elected Project Leader for 2 years by the other developers. It’s a great feeling to have earned the trust of your friends and peers, and also a great responsibility to go and help Debian where needed: talking to the press about Debian, assisting wherever problems crop up, etc. The DPL job is certainly a lot of hard work, and I have nothing but respect for anybody who volunteers for it.

“It’s a great feeling to have earned the trust of your friends and peers.”

Elsewhere, I’ve been leading the Debian CD team for years too, both doing most of the maintenance of the debian-cd package and producing and testing the regular installation CDs and DVDs that we ship to the world. Again, this is a time-consuming job but it needs doing and it’s worthwhile.

Raphael: You’re currently employed by ARM. What are you working on and are they supportive of your Debian involvement?

Steve: The situation within ARM is very interesting; I’m employed in PDSW (Processor Division, SoftWare), a new group founded just a couple of years back to help improve the state of software on ARM. Most of the people in the group are working on Free Software at this stage (e.g. toolchains, browsers, Linux kernel), which is lovely. Some of the engineers have also been seconded into a new non-profit company Linaro, which is a collaboration between ARM and a number of other companies investing in core Linux software and tools for ARM-based CPUs. I’m one of the ARM engineers in Linaro, and I’m a Technical Architect in the Office of the CTO. My role includes looking at future projects for Linaro to help with (e.g. ARM servers), but for the last few months I’ve been concentrating on the new armhf “architecture” in Debian, Ubuntu and elsewhere.

armhf is a new “architecture” in Debian and Ubuntu terms, but it’s not strictly a new type of hardware. Instead, it’s a new ABI. We have two reasons for doing this work:

It targets the latest version of 32-bit ARM CPUs (v7) and makes better use of the hardware, for better performance. Compare targetting i686 instead of i386, for example. We’ll still support the older “armel” port for the foreseeable future for users with older hardware that can’t run armhf.
More importantly: we are standardising on the ABI / compiler options / hardware support for future users.

In the past, there has been a huge amount of specialisation (aka fragmentation) in the ARM Linux environment, and that worked OK for specialised devices that only ever ran the software shipped with them. ARM CPUs are now becoming more and more mainstream, so people will expect to be able to install generic software on their machines. That gives a requirement for a standard base platform, and armhf (arm-linux-gnueabihf in GNU triplet terms) is that standard that we are pushing in the community. Debian, Ubuntu, Fedora, Suse and others are all going to use this, making compatibility possible.

I’ve been working with a small team of people to make armhf happen, helping where needed: putting together build machines; patching Debian packages directly; discussing and fixing toolchain issues with Ubuntu folks; agreeing ABI specifications with people from Fedora; advising people from other distros bootstrapping their new ARM ports.

ARM and Linaro are very supportive of this work, and it’s been lovely being sponsored to work directly on Free Software like this. It’s work that will directly benefit ARM and its partners (of course!), but it’s also helping out more generally too: Debian QA work, cross-build support, bootstrapping efforts, multi-arch. More and more of the ARM market is driven by Free Software, and companies are acknowledging that. I should probably also mention that we’re hiring…!

Raphael: What are your plans for Debian Wheezy?

Steve: There are three main tracks here.

Obviously, I’m interested in seeing armhf release with Wheezy. We’ve just been added to Testing last weekend, so that’s going well. We’ve got over 90% of the archive built now, and we’re mopping up the remaining issues.

I’m the primary maintainer of cdrkit at this point, but I’d prefer to have it go away. Xorriso and the associated software in libisoburn is almost capable of replacing all the aging cdrtools-derived software that we have in Debian, The only missing feature that I’m aware of is creating the HFS hybrid filesystems that we use for installations on Mac systems. I’ve been talking with the upstream folks about this for some time already, and I’m hoping we can finish this soon enough that we can get it into Wheezy.

Finally, I’ve got the ever-growing wishlist of things for debian-cd. We’ve got the beginnings of an automated test suite that Martín Ferrari has written, but it needs integrating and improving. I want to help get regular weekly/daily/release debian-live builds running on the main CD build machine. There’s work needed if we want to make good installation media for the new multi-arch world, too. The Emdebian people are asking for help making CD images… The list goes on

Raphael: The ARM community seems to be very interested in multi-arch. Can you explain why?

Steve: There are a number of reasons for ARM people to be interested in multi-arch; two really stand out for me:

With the historical issues around the plethora of ARM ABIs in the wild, multi-arch will allow us to potentially support multiple ABIs cleanly on one system. That allows users to have (for example) an up-to-date system that makes the most of their current hardware, yet also run legacy programs that might use an older ABI. There’s also a new 64-bit architecture coming (ARMv8) which will run older 32-bit software; again, multi-arch makes mixed installation of old and new software reasonable.
ARM has traditionally been a common target for cross-compilation, and I’d expect that to remain the case for a long time to come yet. For a lot of embedded developers, using a big fast i386/amd64 machine to compile is much faster than using a limited-power small ARM CPU. However, setting up sane cross-compilation environments has long been a bugbear for developers. Getting the toolchain and all the cross-architecture libraries to work together correctly can be like black magic. This is potentially the “killer app” for multi-arch: simply install the libraries for the target architecture directly on your development machine. Install a simple cross-gcc package and (maybe) qemu, and you’re all set.

“This is potentially the “killer app” for multi-arch: simply install the libraries for the target architecture […], install a simple cross-gcc package […] and you’re all set.”

Raphael: What’s the biggest problem of Debian?

Steve: For me, Debian’s biggest problem has been the same for a long time: we are forever short of enough people to do the work that we’re trying to do. That might sound like a weird thing to claim when Debian is one of the largest Free Software projects on the planet, but it’s more a statement of just how huge our goals are. Many of the largest things in Debian are developed or controlled by very small teams working very hard, and there’s always a risk of losing people due to burnout in those situations.

“We are forever short of enough people to do the work that we’re trying to do.”

Some of the tasks that should be easy given our large membership (e.g. large-scale packaging transitions) can often instead take a very long time. We are fortunate to have more people wanting to join in Debian’s work all the time, but we also need to be careful to keep on promoting what we’re doing and recruiting new contributors, encouraging them to get more and more involved in core work. Debian gets ever bigger in terms of the size and the number of packages we distribute; we’re not currently matching that growth rate elsewhere.

Raphael: What motivates you to continue to contribute year after year?

Steve: This one is much easier to answer! The thing that first attracted me to Debian was the fact that I could help to develop it, help to decide how things could and should be done within it. Instead of being forced to accept what some corporation decided I could do with my computer, I could change the software to suit my needs and preferences. Alongside that, I could get involved with a strong community of similar people all over the world, all with their own strong opinions about how software should work.

I joined in and found it was great fun and very rewarding. That hasn’t changed for me in the intervening years, and that’s why I’m still around. I work on Debian because it helps me to get the OS that I want to use. It seems that lots of people around the world find it useful too, and that’s awesome.

Raphael: Do you believe that Stefano Zacchiroli will be the first DPL who managed to stay 3 consecutive years on the seat? Would you like him to candidate again?

Steve: To be honest, I would be very surprised if Zack stood again for DPL this year. He told me himself that he wasn’t planning on it, and I can understand that decision. He’s been an awesome DPL in my opinion, and I’m glad that he took the job. But: it is also a very difficult and time-consuming task that would be enough to wear down anybody. If Zack does decide to stand again, I would support him 100%. But I know that we also have lots of other good people in Debian who would be ready to take up the challenge next.

Raphael: Is there someone in Debian that you admire for their contributions?

Steve: There are lots of people I admire in Debian, so many so that I almost don’t want to list individuals here for fear of missing people out. But…

Bdale Garbee has been an inspiration to many of us, for many years. He’s technically excellent, a great friend to many of us, an endless source of sage advice and (last but not least) he has some wonderful stories to tell about his experiences over the years. On top of that, he’s just cool.

Christian Perrier is another exceptional developer, in my eyes – he’s great at co-ordinating people in translations, working tirelessly to make this very important part of Debian work better and better with every release. He’s also a really nice guy and we all love him.

I also have to mention Joey Hess here, whether he likes it or not. *grin* He’s been responsible for so many good things in Debian over the years, even if he did steal my first package…

Finally, the teams of people who make sure that Debian is always working: the security team and DSA. The rest of us can choose to take time off from Debian to go and do other things, but these people need to cover things every day. That’s a major responsibility, and I salute them for taking on that challenge.

Thank you to Steve for the time spent answering my questions. I hope you enjoyed reading his answers as I did. Note that you can find older interviews on http://wiki.debian.org/PeopleBehindDebian.

Subscribe to my newsletter to get my monthly summary of the Debian/Ubuntu news and to not miss further interviews. You can also follow along on Identi.ca, Google+, Twitter and Facebook

Filed Under: Debian News, News Tagged With: ARM, armhf, Debian, debian-cd, Interview, Linaro, Multiarch, Steve McIntyre

People behind Debian: Ben Hutchings, member of the kernel team

December 13, 2011 By Raphaël Hertzog 5 Comments

Ben Hutchings, photo by Andrew Mc Millan, license CC-BY-2.0

Ben Hutchings is a rather unassuming guy… but hiding behind his hat, there’s a real kernel hacker who backports new drivers for the kernel in Debian stable so that our flagship release supports very recent hardware.

Read on to learn more about Ben and the kernel team’s projects for Debian Wheezy!

Raphael: Who are you?

Ben: I’m a professional programmer, living in Cambridge, England with my long-suffering wife Nattie. In Debian, I mostly work on the Linux kernel and related packages.

Raphael: How did you start contributing to Debian?

Ben: I started using Debian in 1998 and at some point I subscribed to Debian Weekly News. So in 2003 I heard about the planned Debian 10th birthday party in Cambridge, and thought I would like to go to that. Somehow I persuaded Nattie that we should go, even though it was on the day of our wedding anniversary! We both enjoyed it; we made new friends and met some old ones (small world). From then on we have
both been socially involved in Debian UK.

In 2004 there was a bug-squashing party in Cambridge, and we attended that as well. That’s where I really started contributing – fixing bugs and learning about Debian packaging. Then in 2005 I made my first package (sgt-puzzles), attended DebConf, and was persuaded to enter the New Maintainer process.

NM involved a lot of waiting, but by the time I was given questions and tasks to do I had learned enough to get through quite quickly. In April 2006 I was approved as a Debian Developer.

Meanwhile, I looked at the videos from DebConf 5 and thought that it would be useful to distribute them on a DVD. That led me to start writing video software and to get involved in the video team for the next year’s DebConf.

Raphael: You have been one the main driver behind the removal of non-free firmwares from the kernel. Explain us what you did and what’s the status nowadays?

Ben: That’s giving me a bit more credit than I deserve.

For a long time the easy way for drivers to load ‘firmware’ programs was to include them as a ‘blob’ in their static data, but more recently the kernel has included a simple method for drivers to request a named blob at run-time. These requests are normally handled by udev by reading from files on disk, although there is a build-time option to include blobs in the kernel. Several upstream and distribution developers worked to convert the older drivers to use this method. I converted the last few of these drivers that Debian included in its binary packages.

In the upstream Linux source, those blobs have not actually been removed; they have been moved to a ‘firmware’ subdirectory. The long-term plan is to remove this while still allowing the inclusion of blobs at build-time from the separate ‘linux-firmware’ repository. For now, the Debian source package excludes this subdirectory from the upstream tarball, so it is all free software.

There are still a few drivers that have not been converted, and in Debian we just exclude the firmware from them (so they cannot be built). And from time to time a driver will be added to the ‘staging’ section of Linux that includes firmware in the old way. But it’s understood in the kernel community that it’s one of the bugs that will have to be fixed before the driver can move out of ‘staging’.

Raphael: Do you believe that Debian has done enough to make it easy for users to install the non-free firmwares that they need?

Ben: The installer, the Linux binary packages and initramfs-tools will warn about specific files that may be needed but are missing. Users who have enabled the non-free section should then be able to find the necessary package with apt-cache search, because each of the
binaries built from the firmware-nonfree source package includes driver and file names within its description. For the installer, there is a single tarball that provides everything.

We could make this easier, but I think we have gone about as far as we can while following the Debian Social Contract and Debian policy.

Raphael: At some point in the past, the Debian kernel team was not working very well. Did the situation improve?

Ben: Back in 2008 when I started working on the Linux kernel package to sort out the firmware issues, I think there were some problems of communication and coordination, and quite possibly some members were burned-out.

Since then, many of the most active kernel team members have been able to meet face-to-face to discuss future plans at LPC 2009 in Portland and the 2010 mini-DebConf in Paris. We generally seem to have productive discussions on the debian-kernel mailing list and elsewhere, and I think the team is working quite well. Several new contributors have joined after me.

I would say our biggest problem today is that we just don’t have enough time to do all we want to. Certainly, almost all my Debian time is now taken up with integrating upstream kernel releases and handling some fraction of the incoming bug reports. Occasionally I can take the time to work on actual features or the other packages I’m neglecting!

“Our biggest problem today is that we just don’t have enough time to do all we want to.”

Raphael: It is widely known that Linux is maintained in a git repository. But the Debian kernel team is using Subversion. I believe a switch is planned. Why was not git used from the start?

Ben: The linux-2.6 source package dates from the time when Linus made his first release using git. I wasn’t part of the team back then so I don’t know for sure why it was imported to Subversion. However, at that time hardly anyone knew how to use git, no-one had experience hosting public git repositories, and Alioth certainly didn’t offer that option.

Today there are no real blockers: everyone on the kernel team is familiar with using git; Alioth is ready to host it; we don’t have per-architecture patches that would require large numbers of branches. But it still takes time to plan such a conversion for what is a relatively complex source package (actually a small set of related source packages).

Raphael: What are your plans for Debian Wheezy?

Ben: Something I’ve already done, in conjunction with the installer team, is to start generating udebs from the linux-2.6 source package. The kernel and modules have to be repacked into lots of little udebs to avoid using too much memory during installation. The configuration for this used to be in a bunch of separate source packages; these could get out of step with the kernel build configuration and this would only be noticed some time later. Now we can update them both at the same time, they are effectively cross-checked on every upload, and the installer can always be built from the latest kernel version in testing or unstable.

I think that we should be encouraging PC users to install the 64-bit build (amd64), but many users will still use 32-bit (i386) for backward compatibility or out of habit. On i386, we’ve slightly reduced the variety of kernel flavours by getting rid of ’686′ and making ’686-pae’ the default (previously this was called ’686-bigmem’). This means that the NX security feature will be used on all systems that support it. It should also mean that the first i386 CD can have suitable kernel packages for all systems.

I have been trying to work on providing a full choice of Linux Security Modules (LSMs). Despite their name, they cannot be built as kernel modules, so every enabled LSM is a waste of memory on the systems that don’t use it. This is a significant concern for smaller Debian systems. My intent is to allow all unused LSMs to be freed at boot time so that we can happily enable all of them.

I recently proposed to drop support for older x86 systems, starting with 486-class processors in wheezy. In general, this would allow the use of more compiler optimisations throughout userland and the kernel. However it seems that there isn’t that much to be gained unless we also drop 586-class processors, and there are still quite a few of those in use. So I think this will have to wait.

Uwe Kleine-König has been working to include real-time support (also known as PREEMPT_RT). This can provide low and very predictable I/O latency, which is useful for live audio synthesis, for example. It still requires a number of patches and a build configuration change, resulting in a separate binary package. We’re currently only building that for 64-bit PCs. (You may notice this is missing for Linux 3.1, because the real-time developers skipped this release.)

Raphael: What’s the biggest problem of Debian?

Ben: I think we try too hard to accommodate every possible option, without regard for the cost to developers and users in general. As an example, we now have sysvinit, file-rc, upstart and systemd all in testing. Daemon maintainers can’t rely on any advanced features of upstart or systemd because we refuse to choose between them. And the decision to support the FreeBSD kernel means that we cannot choose upstart or systemd as the only option. So all daemon maintainers will have to maintain those baroque init scripts for the indefinite future. We really should be able to decide as a distribution that when one option is technically good and popular then it can be made the only option. But no-one really has the authority to do that, so we muddle along with the pretence that all the options are equally valid and functional, while none of them is supported as well as they should be.

“We try too hard to accommodate every possible option, without regard for the cost to developers and users in general.”

We also try to build every package on every architecture, in general. I’m quite sure there are many (package, architecture) combinations that have no users, ever. But if at some point that combination FTBFS, developers will waste time investigating and fixing that – time that could have been spent working on bugs and features that users actually care about. Yes, sure, portability is good but you can’t prove portability just by making a package compile on every architecture. This also applies to the selection of drivers for the kernel, by the way.

Raphael: Is there someone in Debian that you admire for their contributions?

Well, there are many people, but I will pick out just a few:

Steve McIntyre, for his work as DPL to improve communication with the various Debian derivatives and to bring fresh blood into various core teams. Also for being a generous host for countless Debian social and bug-squashing events.

Stefano Zacchiroli, for improving further on communications with both downstream and upstream projects, and for regularly exercising his power to lead discussions to the benefit of the project.

Julien Cristau, for maintaining good humour while not only fighting against the tide of graphics driver regressions in X and the Linux kernel but also working on release management.

Jonathan Nieder, for taking on the unglamorous and frustrating task of kernel bug triage as a non-maintainer and developing it to a fine art.

Thank you to Ben for the time spent answering my questions. I hope you enjoyed reading his answers as I did.

Subscribe to my newsletter to get my monthly summary of the Debian/Ubuntu news and to not miss further interviews. You can also follow along on Identi.ca, Google+, Twitter and Facebook

Filed Under: Debian News, News Tagged With: Ben Hutchings, Debian, Interview, Kernel, Linux

People behind Debian: Stefano Zacchiroli, Debian Project Leader

November 22, 2011 By Raphaël Hertzog 7 Comments

picture by Tiago Bortoletto Vaz, CC BY-NC-SA 2.0

It’s been one year since the first People behind Debian interview. For this special occasion, I wanted a special guest… and I’m happy that our Debian Project Leader (DPL)—Stefano Zacchiroli—accepted my invitation.

He has a difficult role in the community, but he’s doing a really great job of it. He’s a great mediator in difficult situations, but he’s also opinionated and can push a discussion towards a conclusion.

Read on to learn how he became a Debian developer and later DPL, what he’s excited about in the next Debian release, and much more.

Raphael: Who are you?

Stefano: I’m Stefano Zacchiroli, but I prefer to be called Zack, both on the Internet and in real life. I’m 32, Italian, emigrated to France about 4 years ago. I live in Paris, and I find it to be one of the most gorgeous and exciting cities in the world.

As my day job I’m a Computer Science researcher and teacher at University Paris Diderot and IRILL. In my copious free time™ I contribute to Debian, and I’m firmly convinced that doing so is an effective way to help the cause of Free Software. Besides, I find it to be a lot of fun!

Raphael: How did you start contributing to Debian?

Stefano: Flash back to 1999, when I was a 2nd year student in Computer Science at the University of Bologna. Back then in Italy it was uncommon for young geeks to get exposed to Free Software: Internet was way less pervasive than today and most computer magazines didn’t pay much attention to GNU/Linux. Luckily for me, the professor in charge of the student lab was a Free Software enthusiast and all students machines there were running Debian. Not only that, but there was also a student program that allowed volunteers to become sysadmins after having shown their skills and convinced the director they were trustworthy. Becoming one of those volunteer Debian admins quickly became one of my top objectives for the year, and that is were I’ve learned using Debian.

The year after that, I got in touch with a research group that was to become the happy bunch of hackers with whom I would have done both my master and PhD theses. They were designing a new proof assistant. Most of the development was in OCaml and happened on Debian. OCaml was available in Debian, but many of the libraries we needed were not. So I approached the Debian OCaml Team offering to help. Before I realize what was going on I was (co-)maintainer of tens of OCaml-related packages. At some point I got told “I think you should apply as a Debian Developer”. So I did and in a couple of months I went through the New Member (NM) process, that was back then in its infancy. I still remember my happiness while reading the “account created” mail, the day after my 22nd birthday.

I know the NM process went through some bad publicity in the past, but I’m happy to see that nowadays the process can be as swift as it has been for me 10 years ago.

Raphael: It’s your second year as Debian Project Leader (DPL). Are you feeling more productive in the role? Do you fear to burn out?

Stefano: I’m feeling way more productive, no doubts.

The task of the Debian Project Leader is not necessarily difficult, but it is a complex and scarcely documented one. It is also profoundly different from any other task that Debian people usually work on, so that experience doesn’t help much in getting started. Before becoming effective as DPL one needs to get to know many people and mechanisms he is not familiar with. More importantly, one needs to set up a personal work-flow that allows to keep up with day-to-day DPL tasks (which are aplenty) as well as with urgencies (that tend to pop-up in the leader@debian.org INBOX at the least convenient time). Finally, one also needs to do proper “traffic shaping” and always retain enough “motivation bandwidth” to keep the Project informed about what is going on in DPL-land.

Finding the right balance among all these ingredients can take some time. Once one is past it, everything goes way more smoothly.

The above is why I’m constantly encouraging people interested in running for DPL in the future to reach out to me and work on some tasks of the current DPL’s TODO list. I swear it is not just a cheap attempt at slavery!. It is rather an attempt at DPL mentoring that could be beneficial: both to give future candidates more awareness of the task, and to reduce the potential downtime when handing over from one DPL to the next.

Regarding burn out, I don’t feel prone to its risk these days. If I look back, I can say that my contributions as DPL have been pretty constant in volume over time; my enthusiasm for the task, if anything, is on the rise. The effectiveness of my contributions as DPL are, on the other hand, not mine to judge.

Raphael: If you had to single out two achievements where you were involved as DPL, what would they be?

Stefano: I’d go for the following two, in no particular order:

Dialogue with derivatives. When I became DPL ~1.5 years ago the situation on that front was pretty dire. In the specific case of Ubuntu, by far the most successful and customized of all Debian derivatives, I remember being scared of raising the topic of collaboration with them on mailing lists. More generally, we had no specific initiatives to foster technical collaboration with and among derivatives. A huge potential of (forwarded) contributions to Debian was being wasted.

Today things look much better, as I’ve documented in recent talks at DebConf11 and UDS-P. The amount of forwarded patches we receive from downstream is at its maximum and many people who apply to become Debian Developers come from derivatives. Conflict situations still exist, for good reasons that we still have to either fix or figure out entirely. But I’m positive we’re on the right track.

“The amount of forwarded patches we receive from downstream is at its maximum”

This is by far not an achievement of mine alone. In particular, many of the activity of the Derivatives Front Desk have been organized by other enthusiastic volunteers. But I’ve done my part, especially in breaking the ice and in proposing a vision of Free Software distribution where all distros play a role and are welcome to join the game, as long as they give back and give credit to their respective upstreams.
Process membership. I’m proud of having promoted the general resolution (GR) that has clarified (and advertised to the world) that Debian welcomes all kind of contributions, and that they all equally matter to become proper members of the Project. I notice only now while writing this that the GR title, traditionally chosen by the secretary, was “Debian Project Members”. That choice harmonically closes the circle with the recent renaming of the NM process to “New Member” process.

Today, we have several project members (AKA “Debian Developers”) that are active citizen of Debian with voting rights, even though they take care of tasks other than packaging. Anyone can become a Debian citizen, as long as they are ready to abide by Debian’s values, have a track record of verifiable contributions to Debian, and are committed to keep them coming in the future.

“We have several project members that […] take care of tasks other than packaging.”

Once gain, this is by far not an achievement of mine alone, very little project-wide achievements are. DAM has helped a lot and support from the project as a whole has been immense.

OK, let me cheat and add a third one… I’m also proud of having been able to report to the Project my whereabouts as DPL, thoroughly and periodically, since the very beginning is first term. People annoyed by my reporting logorrhea now have all my sympathies.

Raphael: Among the possible new features of Debian Wheezy, which one gets you excited most?

Stefano: It’s multi-arch, no doubt. Even though it is not a directly user visible change, it’s a very far reaching one. It is also one of those changes that make me feel that moment of truth of coders, when you realize you are finally doing the right thing and ditching piles of ugly hacks.

“It’s multi-arch […] you realize you are finally doing the right thing and ditching piles of ugly hacks.”

Raphael: If you were not DPL and could spend all your time on Debian, what project would you do?

Stefano: I would sit down and do software development for Debian.

It’s impressive how many important and beneficial changes for Debian could be delivered by specific software improvements in various parts of our infrastructure. We tend to attract many packagers, but not so many people willing to maintain Debian infrastructure softwares like dak, britney, debbugs, the PTS, etc. Their maintenance burden then falls on the shoulders of the respective teams which are generally very busy with other important tasks.

As a project, we seem to be more appealing to packagers than to software developers. That is a pity given the amount of exciting coding tasks that are everywhere in Debian. Part of the reason we are not appealing to developers is that we are not particularly good at collecting coding tasks in a place where interested developers could easily pick them up. It also takes quite a bit of inside knowledge to spot infrastructure bugs and understand how to fix them.

I long for some spare hacking time to check if I’m still good enough of a coder to hunt down longstanding bugs in our infrastructure, which have ended up being my pet peeves.

I’d also love to dive again into RCBW. It’s less committing than package maintenance, more diverse and challenging, and also an immensely useful activity to get Debian releases done.

Raphael: Martin Michlmayr is worried that there is so few paid opportunities around Debian. Do you agree with his sentiment, and if yes do you have ideas on how to improve this situation?

Stefano: The idealistic me wishes Debian to be a community made only of volunteers that devote their free time to the Project. Oh, and that me also wishes Debian to be competitive with similar projects, no matter how many full-time employees others have! That is coherent with a view of society where everyone has a day job, but also engages in volunteering activities ensuring that public interest is pursued by people motivated by interests other than profit.

But I do realize that for Free Software to succeed companies, employees, and salaries should all have a role. I admire projects that strike a good balance between volunteer and paid work. The Linux kernel is emblematic in that respect: many developers are paid by companies that have a commercial or strategic interest in Linux. Nevertheless volunteers contributions are aplenty and the Linux community gives a convincing impression that choices are driven by the community itself (or by its benevolent dictator) without money-driven impositions.

“I do realize that for Free Software to succeed companies, employees, and salaries should all have a role.”

Such an ecosystem does not exist around Debian. We do have a partner program that allows for it to happen, but we have very few partners with an interest in doing distribution development work. Like Martin, I’m worried by this state of affairs, because it de facto means we lag behind in terms of available people power. In a community of volunteers, that might frustrate people and that is not good.

To improve over the status quo the first step is to federate together small and medium companies that have a strategic interest in Debian and listen to their needs. I’m already in touch with representatives of such companies that, in many cases, already employ Debian Developers to do some distribution work in Debian. We will be soon sending out a call to reach out to more such companies, but since we are discussing this, why waiting? If some of our readers here are representative of such companies, I encourage them to get in touch with me about this.

Raphael: You know that the fundraising campaign for the Debian Administrator’s Handbook is on good track but the liberation of the book is not yet assured. What do you think of this project?

Stefano: I’m happy about the project, to the point that I’ve accepted writing a testimonial for it . I’m sad about the scarce availability of up to date and high quality (DFSG-)Free books about Debian and I welcome any initiative that might help closing that gap.

“I’m sad about the scarce availability of up to date and high quality (DFSG-)Free books about Debian.”

Free Culture is a great offspring of Free Software and I’m convinced we need to stand up against double standards in the two camps. Letting aside software-specific licensing details, the basic freedoms to be defended are the same. They are those freedoms that ensure that a reader is in full control of his book, pretty much as they ensure that a computer user is in full control of the software that runs on it. I’m therefore proud that Debian has long resolved that the Debian Free Software Guidelines (DFSG) apply not only to software but also to books and other pieces of documentation.

But the status quo implies that not only we have very few up to date, high quality books about Debian. It also implies that, at present, we have no such book that we can distribute in the Debian archive, showing off the Free Software (and Free Culture!) values we stand for.
Crowdfunding is considered to be a good mate for Free Culture, where the services model that applies to Free Software is more difficult to exploit. I so wish any luck to yours and Roland’s initiative.

A different matter is whether Debian, as a project, should endorse the initiative and actively campaign for it. As you know, I think it should not. While we do advertise general project donations, we don’t do mission-specific fundraising campaign for Debian itself. Coherently with that, I don’t think we should relay crowdfunding campaigns for 3rd parties, even when the result would be beneficial to Debian.

Raphael: Is there someone in Debian that you admire for their contributions?

Stefano: There are two classes of people that I particularly admire in Debian:

Those with an uncanny ability to guide discussions towards constructive conclusions. We are lucky to have many in Debian and I admire all of them. Having to single out one I’d name Russ Allbery, in honor of whom I hereby propose the periodic “Russ Allbery’s Distinguished Flametamer Award”.
People stepping up for responsibility roles, especially when the responsibility put them in tough spots. Release teams, ftp-masters, DSA, DAM, as well as past and present members of teams with similarly “hot” seats have all my admiration.

Thank you to Zack for the time spent answering my questions. I hope you enjoyed reading his answers as I did.

Subscribe to my newsletter to get my monthly summary of the Debian/Ubuntu news and to not miss further interviews. You can also follow along on Identi.ca, Google+, Twitter and Facebook

Filed Under: Debian News, News Tagged With: Debian, DPL, Interview, NM, Ocaml, Stefano Zacchiroli

People Behind Debian: Mark Shuttleworth, Ubuntu’s founder

November 17, 2011 By Raphaël Hertzog 37 Comments

I probably don’t have to present Mark Shuttleworth… he was already a Debian developer when he became millionaire after having sold Thawte to Verisign in 1999. Then in 2002 he became the first African (and first Debian developer) in space. 2 years later, he found another grandiose project to pursue: bring the Microsoft monopoly to an end with a new alternative operating system named Ubuntu (see bug #1).

I have met Mark during Debconf 6 in Oaxtepec (Mexico), we were both trying to find ways to enhance the collaboration between Debian and Ubuntu. The least I can say is that Mark is opinionated but any leader usually is, and in particular the self-appointed ones!

Read on to discover his view on the Ubuntu-Debian relationship and much more.

Raphael: Who are you?

Mark: At heart I’m an explorer, inventor and strategist. Change in technology, society and business is what fascinates me, and I devote almost all of my time and wealth to the catalysis of change in a direction that I hope improves society and the environment.

I’m 38, studied information systems and finance at the University of Cape Town. My ‘hearts home’ is Cape Town, and I’ve lived there and in Star City and in London, now I live in the Isle of Man with my girlfriend Claire and 14 precocious ducks. I joined Debian in around 1995 because I was helping to setup web servers for as many groups as possible, and I thought Debian’s approach to packaging was very sensible but there was no package for Apache. In those days, the NM process was a little easier

Raphael: What was your initial motivation when you decided to create Ubuntu 7 years ago?

Mark: Ubuntu is designed to fulfill a dream of change; a belief that the potential of free software was to have a profound impact on the economics of software as well as its technology. It’s obvious that the technology world is enormously influenced by Linux, GNU and the free software ecosystem, but the economics of software are still essentially unchanged.

Before Ubuntu, we have a two-tier world of Linux: there’s the community world (Debian, Fedora, Arch, Gentoo) where you support yourself, and the restricted, commercial world of RHEL and SLES/SLED. While the community distributions are wonderful in many regards, they don’t and can’t meet the needs of the whole of society; one can’t find them pre-installed, one can’t get certified and build a career around them, one can’t expect a school to deploy at scale a platform which is not blessed by a wide range of institutions. And the community distributions cannot create the institutions that would fix that.

Ubuntu brings those two worlds together, into one whole, with a commercial-grade release (inheriting the goodness of Debian) that is freely available but also backed by an institution.

The key to that dream is economics, and as always, a change in economics; it was clear to me that the flow of money around personal software would change from licensing (“buying Windows”) to services (“paying for your Ubuntu ONE storage”). If that change was coming, then there might be room for a truly free, free software distribution, with an institution that could make all the commitments needed to match the commercial Linux world. And that would be the achievement of a lifetime. So I decided to dedicate a chunk of my lifetime to the attempt, and found a number of wonderful people who shared that vision to help with the attempt.

It made sense to me to include Debian in that vision; I knew it well as both a user and insider, and believed that it would always be the most rigorous of the community distributions. I share Debian’s values and those values are compatible with those we set for Ubuntu.

“Debian would always be the most rigorous of the community distributions.”

Debian on its own, as an institution, could not be a partner for industry or enterprise. The bits are brilliant, but the design of an institution for independence implies making it difficult to be decisive counterparty, or contractual provider. It would be essentially impossible to achieve the goals of pre-installation, certification and support for third-party hardware and software inside an institution that is designed for neutrality, impartiality and independence.

However, two complementary institutions could cover both sides of this coin.

So Ubuntu is the second half of a complete Debian-Ubuntu ecosystem. Debian’s strengths complement Ubuntu’s, Ubuntu can achieve things that Debian cannot (not because its members are not capable, but because the institution has chosen other priorities) and conversely, Debian delivers things which Ubuntu cannot, not because its members are not capable, but because it chooses other priorities as an institution.

Many people are starting to understand this: Ubuntu is Debian’s arrow, Debian is Ubuntu’s bow. Neither instrument is particularly useful on its own, except in a museum of anthropology

“Ubuntu is Debian’s arrow, Debian is Ubuntu’s bow.”

So the worst and most frustrating attitude comes from those who think Debian and Ubuntu compete. If you care about Debian, and want it to compete on every level with Ubuntu, you are going to be rather miserable; you will want Debian to lose some of its best qualities and change some of its most important practices. However, if you see the Ubuntu-Debian ecosystem as a coherent whole, you will celebrate the strengths and accomplishments of both, and more importantly, work to make Debian a better Debian and Ubuntu a better Ubuntu, as opposed to wishing Ubuntu was more like Debian and vice versa.

Raphael: The Ubuntu-Debian relationship was rather hectic at the start, it took several years to “mature”. If you had to start over, would you do some things differently?

Mark: Yes, there are lessons learned, but none of them are fundamental. Some of the tension was based on human factors that cannot really be altered: some of the harshest DD critics of Canonical and Ubuntu are folk who applied for but were not selected for positions at Canonical. I can’t change that, and wouldn’t change that, and would understand the consequences are, emotionally, what they are.

Nevertheless, it would have been good to be wiser about the way people would react to some approaches. We famously went to DebConf 5 in Porto Allegre and hacked in a room at the conference. It had an open door, and many people popped a head in, but I think the not-a-cabal collection of people in there was intimidating and the story became one of exclusion. If we’d wanted to be exclusive, we would have gone somewhere else! So I would have worked harder to make that clear at the time if I’d known how many times that story would be used to paint Canonical in a bad light.

As for engagement with Debian, I think the situation is one of highs and lows. As a high, it is generally possible to collaborate with any given maintainer in Debian on a problem in which there is mutual interest. There are exceptions, but those exceptions are as problematic within Debian as between Debian and outsiders. As a low, it is impossible to collaborate with Debian as an institution, because of the design of the institution.

“It is generally possible to collaborate with any given maintainer […] [but] it is impossible to collaborate with Debian as an institution.”

In order to collaborate, two parties must make and keep commitments. So while one Debian developer and one Ubuntu developer can make personal commitments to each other, Debian cannot make commitments to Ubuntu, because there is no person or body that can make such commitments on behalf of the institution, on any sort of agile basis. A GR is not agile . I don’t say this as a critique of Debian; remember, I think Debian has made some very important choices, one of those is the complete independence of its developers, which means they are under no obligation to follow a decision made by anyone else.

It’s also important to understand the difference between collaboration and teamwork. When two people have exactly the same goal and produce the same output, that’s just teamwork. When two people have different goals and produce different product, but still find ways to improve one anothers product, that’s collaboration.

So in order to have great collaboration between Ubuntu and Debian, we need to start with mutual recognition of the value and importance of the differences in our approach. When someone criticises Ubuntu because it exists, or because it does not do things the same way as Debian, or because it does not structure every process with the primary goal of improving Debian, it’s sad. The differences between us are valuable: Ubuntu can take Debian places Debian cannot go, and Debian’s debianness brings a whole raft of goodness for Ubuntu.

Raphael: What’s the biggest problem of Debian?

Mark: Internal tension about the vision and goals of Debian make it difficult to create a harmonious environment, which is compounded by an unwillingness to censure destructive behaviour.

Does Debian measure its success by the number of installs? The number of maintainers? The number of flamewars? The number of packages? The number of messages to mailing lists? The quality of Debian Policy? The quality of packages? The “freshness” of packages? The length and quality of maintenance of releases? The frequency or infrequency of releases? The breadth of derivatives?

Many of these metrics are in direct tension with one another; as a consequence, the fact that different DD’s prioritise all of these (and other goals) differently makes for… interesting debate. The sort of debate that goes on and on because there is no way to choose between the goals when everyone has different ones. You know the sort of debate I mean

Raphael: Do you think that the Debian community improved in the last 7 years? If yes, do you think that the coopetition with Ubuntu partly explains it?

Mark: Yes, I think some of the areas that concern me have improved. Much of this is to do with time giving people the opportunity to consider a thought from different perspectives, perhaps with the benefit of maturity. Time also allows ideas to flow and and of course introduces new people into the mix. There are plenty of DD’s now who became DD’s after Ubuntu existed, so it’s not as if this new supernova has suddenly gone off in their galactic neighbourhood. And many of them became DD’s because of Ubuntu. So at least from the perspective of the Ubuntu-Debian relationship, things are much healthier.

We could do much better. Now that we are on track for four consecutive Ubuntu LTS releases, on a two-year cadence, it’s clear we could collaborate beautifully if we shared a freeze date. Canonical offered to help with Squeeze on that basis, but institutional commitment phobia reared its head and scotched it. And with the proposal to put Debian’s first planned freeze exactly in the middle of Ubuntu’s LTS cycle, our alignment in interests will be at a minimum, not a maximum. Pure <facepalm />.

Raphael: What would you suggest to people (like me) who do not feel like joining Canonical and would like to be paid to work on improving Debian?

Mark: We share the problem; I would like to be paid to work on improving Ubuntu, but that’s also a long term dream

Raphael: What about using the earnings of the dormant Ubuntu Foundation to fund some Debian projects?

Mark: The Foundation is there in the event of Canonical’s failure to ensure that commitments, like LTS maintenance, are met. It will hopefully be dormant for good

Raphael: The crowdfunding campaign for the Debian Administrator’s Handbook is still going on and I briefly envisioned the possibility to create the Ubuntu Administrator’s Handbook. What do you think of this project?

Mark: Crowdfunding is a great match for free software and open content, so I hope this works out very well for you. I also think you’d find a bigger market for an Ubuntu book, not because Ubuntu is any more important than Debian but because it is likely to appeal to people who are more inclined to buy or download a book than to dive into the source.

Again, this is about understanding the difference in audiences, not judging the projects or the products.

Raphael: Is there someone in Debian that you admire for their contributions?

Mark: Zack is the best DPL since 1995; it’s an impossible job which he handles with grace and distinction. I hope praise from me doesn’t tarnish his reputation in the project!

Thank you to Mark for the time spent answering my questions. I hope you enjoyed reading his answers as I did.

Subscribe to my newsletter to get my monthly summary of the Debian/Ubuntu news and to not miss further interviews. You can also follow along on Identi.ca, Google+, Twitter and Facebook

Filed Under: Debian News, News, Ubuntu News Tagged With: Debian, Interview, Mark Shuttleworth, sabdfl, Ubuntu

People behind Debian: Peter Palfrader, Debian System Administrator

August 18, 2011 By Raphaël Hertzog 2 Comments

You might not know who Peter is because he’s not very visible on Debian mailing lists. He’s very active however and in particular on IRC. He was an admin of the OFTC IRC network at the time Debian switched from Freenode to OFTC. Nowadays he’s a member of the Debian System Administration team who runs all the debian.org servers.

If you went to a Debconf you probably met him since he’s always looking for new signatures of his GPG key. He owns the best connected key in the PGP web of trust. He also wrote caff a popular GPG key signing tool.

Raphael: Who are you?

Peter: I’m Peter Palfrader, also known as weasel. I’m in my early 30s, born and raised in Innsbruck, Austria and am now living and working in Salzburg, Austria. In my copious free time, other than help running Debian’s servers I also help maintaining the Tor project‘s infrastructure.

Away from the computer I enjoy reading fiction (mostly English language Science Fiction and Fantasy), playing board games and going to the movies. Weather permitting, I also occasionally do some cycling.

Raphael: How did you start contributing to Debian?

Peter: I installed my first Debian the week slink came out. That was Debian 2.1 for the youngsters, in early 1999. The one thing I immediately liked about slink was that Debian’s pppd supported RAS authentication which my university’s dial-up system required. No way I’d go back to SuSE 5.3 when I had working Internet with my Debian box.

During that year I started getting involved in the German language Debian channel on IRCnet which got me in contact with some DDs. Christian Kurz (<shorty>) was working on Debian QA at the time and he asked my help in writing a couple of scripts. Some of that work, debcheck, still produces parts of the qa.d.o website, tho the relevance of that nowadays is probably negligible.

While trying to learn more Perl earlier, I had written a program to produce syntax highlighted HTML for code snippets in various languages. I didn’t really know what I was doing but it kinda worked, and probably still does since I still get mail from users every now and then. I figured that it would be really nice if people could just get my software together with Debian. According to code2html‘s Debian changelog the initial release of the package was done on a weekday at 2:30 in the morning early in 2000, and if my memory serves me correctly, shorty uploaded it shortly afterwards.

I started packaging a couple of other piece of software and in the same year I sent my mail to the debian account managers to register my intent to become a DD. No new developers where being accepted at that time since the DAMs wanted to overhaul the entire process so I wasn’t surprised to not get any immediate reply. Of course what the silence also meant was that the mail had been lost, but I only learned of that later when I took all my courage to ask DAM about the status of application a couple months later. Once that was sorted out I was assigned an AM, did the usual dance, and got my account late in November 2000.

Raphael: Four years ago, the Debian System Administration team was a real bottleneck for the project and personal conflicts made it almost impossible to find solutions. You were eager to help and at some point you got dropped as a new member in that team. Can you share your story and how you managed the transition in the difficult climate at that time?

Peter: Ah, that was quite the surprise for an awful lot of people, me included.

Branden Robinson, who was our DPL for the 2005-2006 term, tried to get some new blood added to DSA who were at the time quite divided. He briefly talked to me on IRC some time in summer 2005, telling me I had come “recommended for a role on the sysadmin team”. In the course of these 15 minutes he outlined some of the issues he thought a new member of DSA would face and asked me if I thought I could help. My reply was cautiously positive, saying that I didn’t want to step on anybody’s toes but maybe I could be of some assistance.

And that was the first and last of it, until some fine November day two years later I got an email from Phil Hands saying “I’ve just added you to the “adm” group, and added you to the debian-admin@d.o alias.” and “welcome on board“. *blink* What!?

My teammates at the time were James Troup (elmo), Phil Hands (fil), Martin ‘Joey’ Schulze and Ryan Murray (neuro).

The old team, while apparently not on good terms with one another, was however still around to do heavy lifting when required. I still remember when on my first or second day on the team two disks failed in the raid5 of ftp-master.debian.org aka ries. Neuro did the reinstall once new disks had arrived at Brown University. I’m sure I’d have been way out of my league had this job fallen to me.

Fortunately my teammates were all willing and able to help me find whatever pieces of information existed that might help me learn how debian.org does its stuff. Unfortunately a lot of it only existed in various heads, or when lucky, in one of the huge mbox archives of the debian-admin alias or list. Anyway, soon I was able to get my hands dirty with upgrading from sarge to etch, which had been released about half a year earlier.

Raphael: I know the DSA team has accomplished a lot over the last few years. Can you share some interesting figures?

Peter: Indeed we have accomplished a lot. In my opinion the most important of these accomplishment is that we’re actually once again a team nowadays. A team where people talk to one another and where nobody should be a SPoF.

Since this year’s debconf we are six people in the admin team: Tollef Fog Heen (Mithrandir) and Faidon Liambotis (paravoid) joined the existing members: Luca Filipozzi, Stephen Gran, Martin Zobel-Helas, and myself. Growing a core team, especially one where membership comes with uid0 on all machines, is not easy and that’s why I’m very glad we managed to actually do this step.

I also think the infrastructure and our workflows have matured well over the last four years.

We now have essential monitoring as a matter of course: Nagios not only checks whether all daemons that should be running are in fact running, but it also monitors hardware health of disks, fans, etc. where possible. We are alerted of outstanding security updates that need to be installed and of changes made to our systems that weren’t then explicitly acked by one of us.

We have set up a centralized configuration system, puppet, for some of our configuration that is the same, or at least similar, on all our machines.

Most, if not all, pieces of software, scripts and helpers that we use on debian.org infrastructure is in publicly accessible git repositories.

We have good communication with other teams in Debian that need our support, like the ftp folks or the buildd people.

As for figures, I don’t think there’s anything spectacular. As of the time of our BoF at this year’s DebConf, we take care of approximately 135 systems, about 100 of them being real iron, the other virtual machines (KVM). They are hosted at over 30 different locations, tho we are trying to cut down on that number, but that’s a long and difficult process.

We don’t really collect a lot of other figures like web hits on www.debian.org or downloads from the ftp archive. The web team might do the former and the latter is pretty much impossible due to the distributed nature of our mirrors, as you well know.

Raphael: The DSA team has a policy of eating its own dog food, i.e. you’re trying to rely only on what’s available in Debian. How does that work out and what are the remaining gaps?

Peter: Mostly Debian, the OS, just meets our needs. Sure, the update frequency is a bit high, we probably wouldn’t mind a longer release cycle. But on the other hand most software is recent enough. And when it’s not, that’s easy to fix with backports. If they aren’t on backports.debian.org already, we’ll just put them there (or ask somebody else to prepare a backport for us) and so everybody else benefits from that work too.

Some things we need just don’t, and probably won’t, exist in Debian. These are mainly proprietary hardware health checks like HP’s tools for their servers, or various vendors’ programs to query their raid controller. HP actually makes packages for their stuff which is very nice, but other things we just put into /usr/local, or if we really need it on a number of machines, package ourselves.

The push to cripple our installers and kernels by removing firmware was quite annoying, since it made installing from the official media next to impossible in some cases. Support for working around these limitations has improved with squeeze so that’s probably ok now.

One of the other problems is that especially on embedded platforms most of the buildd work happens on some variation of development boards, usually due to increased memory and hard disk requirements than the intended market audience. This often implies that the kernel shipped with Debian won’t be usable on our own debian.org machines. This makes keeping up with security and other kernel fixes way more error prone and time intensive. We keep annoying the right people in Debian to add kernel flavors that actually boot on our machines, and things are getting better, so maybe in the future this will no longer be a problem.

Raphael: If you could spend all your time on Debian, what would you work on?

Peter: One of the things that I think is a bit annoying for admins that maintain machines all over the globe is mirror selection. I shouldn’t have to care where my packages come from, apt-get should just fetch them from a mirror, any mirror, that is close by, fast and recent. I don’t need to know which one it was.

We have deployed geodns for security.debian.org a while ago, and it seems to work quite well for the coarse granularity we desired for that setup, but geodns is an ugly hack (I think it is a layer violation), it might not scale to hundreds or thousands of mirrors, and it doesn’t play well with DNSSEC.

What I’d really like to see is Debian support apt’s mirror method that — I think (and I apologize if I’m wronging somebody) — Michael Vogt implemented recently. The basic idea is that you simply add deb mirror://mirror.debian.org/ or something like that to your sources.list, and apt goes and asks that server for a list of mirrors it should use right now.

The client code exists, but I don’t know how well tested it is. What is missing is the server part. One that gives clients a mirror, or list of mirrors, that are close to them, current, and carry their architecture.

It’s probably not a huge amount of work, but at the same time it’s also not entirely trivial. If I had more time on my hands this is something that I’d try to do. Hopefully somebody will pick it up.

Raphael: What motivates you to continue to contribute year after year?

Peter: It’s fun, mostly. Sure, there are things that need to be done regularly that are boring or become so after a while, but as a sysadmin you tend to do things once or twice and then seek to automate it.

DSA’s users, i.e. DDs, constantly want to play with new services or approaches to make Debian better and often they need our support or help in their endeavors. So that’s a constant flow of interesting challenges.

Another reason is that Debian is simply where some of my friends are. Working on Debian with them is interacting with friends.

I not only use Debian at debian.org. I use it at work, I use it on my own machines, on the servers of the Tor project. When I was with OFTC Debian is what we put on our machines. Being a part of Debian is one way to ensure what Debian releases is actually usable to me, professionally and with other projects.

Raphael: Is there someone in Debian that you admire for their contributions?

Peter: That’s a hard one. There are certainly people who I respect greatly for their technical or other contributions to Debian, but I don’t want to single anybody out in particular. I think we all, everyone who ever contributed to Debian with code, support or a bug report, can be very proud of what we are producing — one of the best operating systems out there.

Thank you to Peter for the time spent answering my questions. I hope you enjoyed reading his answers as I did. Subscribe to my newsletter to get my monthly summary of the Debian/Ubuntu news and to not miss further interviews. You can also follow along on Identi.ca, Twitter and Facebook.

Filed Under: Debian News, News Tagged With: Debian, DSA, Interview, Peter Palfrader, Tor, weasel

People behind Debian: Margarita Manterola, Debian Women member

August 7, 2011 By Raphaël Hertzog 14 Comments

Photograph taken by Julia Palandri

When I think about Margarita, I always remember her as a friendly and welcoming person. Like most of the Debian Women members by the way. But she likes to spread some love and organized a Debian Appreciation Day for example.

I think I met her in real life for the first time at Debconf 6 in Oaxtepec (Mexico). She deeply cares about Debian in general. She has proven it multiple times with her DPL candidacy and by giving talks like Making Debian rule again.

One last thing, Debconf11 is just over and you will see that Debconf4 has had a big influence on Marga. My advice is simple: next time there’s a Debconf on your continent, make sure to take a few days off and come to meet us! It really gives another picture of the Debian community. Now let’s proceed with the interview.

Raphael: Who are you?

Margarita: I’m Margarita Manterola, a Software Developer from Argentina. I work developing software in Python in a Debian-friendly company during the day, and teach programming at a local university during the evenings.

I’m married to Maximiliano Curia who is also a Debian Developer, most of our Free Software work has been done together.

I only maintain a handful of packages in Debian, I’m more interested in fixing bugs than in packaging new software.

I’ve also been a part of the organizing team of many of the previous Debian Conferences. One of the biggest commitments and the biggest success of my participation in Debian was being part of the organizing team of DebConf8, in Argentina.

Raphael: How did you start contributing to Debian?

Margarita: I started using Debian around 2000. Soon after we had learned the grips of general GNU/Linux usage, Maxy and I started giving an introductory course at our local university, and became quite involved with the local LUG.

At some point in 2002/2003 I became a “Debian Bug Reporter”: most of my friends would report bugs to me, and I would then write them in the proper form to the BTS. I would also be very attentive about reporting any bugs that I might encounter myself trying to create good bug reports.

The turning point in my participation in Debian was DebConf4 in Porto Alegre, Brazil. Being so close to Argentina meant that we felt specially invited to be there, and Maxy and I decided to go to DebConf for our honeymoon. We didn’t really know much about DebConf dynamics, but we were really eager to learn more about Debian and become more involved.

What happened was that meeting with DDs from all over the world transformed our lives, we became part of the “Debian family” and wanted to be more and more involved. Soon after that we both started maintaining packages and not long after that, applied to become Developers.

The Debian Women project also meant a lot to me. I felt encouraged all along the way, encouraged to learn, to ask questions and to lose the fear of making mistakes.

I became a Debian Developer on November 2005. Since then, Debian has always been one of the most important things I do in my life.

Raphael There was a Debian Women BoF during debconf. What are the plans for Debian Women in the upcoming months?

Margarita: I was not there in person, but thanks to the awesome work of the video team, and of Christian Perrier’s typing efforts when something failed, I was able to experience much of what was discussed.

One of the many points that came up during the BOF is that many people “Want to help” but don’t know where to start or how to go about it. It’s a challenge for the Debian Women project to find a way to allow these people to become involved in Debian through “Mini projects” or something like that.

Another of the subjects that was brought up was the Debian Women mentoring project, which has been going on for quite a while now, but lacks enough publicity. So, we need to reach more people about it, and maybe also improve it with some templates, similar to the New Maintainer templates, so that mentees that don’t know where to start have some sort of general path to follow.

Raphael: You created very useful diagrams documenting how package maintainer scripts are invoked by dpkg. How did you do it and was that a useful experience?

Margarita: I did those diagrams to be able to answer one of the questions in the NM templates, regarding the order of the maintainer script execution.

Answering the question in text was basically copying and pasting the part of the Debian Policy that explained it, which wasn’t really too clear for me, so I decided to go and make a diagram of it, so that I could really understand it.

I did it by the best of all debugging techniques: adding prints to each of the maintainer scripts, and testing them in all the different orders that I could think of.

It was a useful experience at the time, because I learned a lot of how maintainers scripts work. I didn’t expect the diagrams to become so famous, though, I only did them to answer one NM question, that I assumed most other people had already answered before

Raphael: You participated in a DPL election. This is a big commitment to make. What were your motivations?

Margarita: As I said, I was part of the organizing team of DebConf8, in Argentina. Which was quite a success, a lot of people enjoyed it and praised the good work that had been done by the local team.

During said DebConf8, I had a dream (it was almost a nightmare, actually): I woke up and just like that, I was the DPL. I spoke to some people about this dream and to my complete surprise many said that I should actually do it.

After giving that possibility a year and a half of thoughts, during the 2010 campaign I was talked into participating myself as a candidate, and it was a very interesting experience. However, I’m very glad that Zack got elected and not me, I think he makes a much better DPL that I would have made.

Raphael: What’s the biggest problem of Debian?

Margarita: I think the main problem that we have is our communication, both inside the project and outside the project. Most of us are very technical people, our skills lay in the technical part of Debian (preparing packages, fixing bugs, writing software, administering systems) not in the social part. And thus, we lack a general empathy that is quite needed when interacting with people from all over the world.

Raphael: Do you have wishes for Debian Wheezy?

Margarita: Not particularly. I do want it to be a great release with good quality, stable software. I would also like to keep making Debian more and more “universal” with each release, making it more user friendly, more accessible, and more robust than any other previous release.

Raphael: Is there someone in Debian that you admire for their contributions?

Margarita: I admire a lot of people in Debian. There’s a lot of people that contribute a lot of time to Debian, amounts of time that I can’t begin to understand how they can afford.

I admire Stefano Zacchiroli, our current project leader. And Steve McIntyre, the project leader before him. Also Bdale Garbee, who’s also been a DPL in the past. Making this list I realize that Debian has been blessed by quite a number of great leaders in the past.

I admire Holger Levsen, for his contributions to the DebConf video team, that have made it possible year after year for the whole project to participate in DebConf remotely.

I admire Steve Langasek and Andreas Barth (etch is still my favourite release). I admire Christian Perrier for his work on internationalization. I admire Joerg Jaspert for the incredible amounts of time that he puts into Debian.

And actually, I could go on admiring people all night long. I admire so many people that this interview could become a very boring list of names. I guess it’s better to leave it at saying that Debian is lucky to have quite a lot of excellent hackers around.

Thank you to Marga for the time spent answering my questions. I hope you enjoyed reading her answers as I did. Subscribe to my newsletter to get my monthly summary of the Debian/Ubuntu news and to not miss further interviews. You can also follow along on Identi.ca, Twitter and Facebook.

Filed Under: Debian News, News Tagged With: Debconf, Debian, debian-women, Interview, Margarita Manterola

People behind Debian: Martin Michlmayr, former Debian Project Leader

July 21, 2011 By Raphaël Hertzog 8 Comments

Martin Michlmayr is a Debian developer since 2000 and I share quite a few things with him, starting with his age and involvement in the quality assurance team. He managed to be elected Debian Project Leader in 2003 and 2004.

He’s no longer as active as he used to be but his input is always very valuable and he continues to do very interesting things in particular concerning the support of NAS devices. Read on for the details.

Raphael: Who are you?

Martin: I’m Martin Michlmayr. I’m 32, originally from Austria, and currently living in the UK.

I’ve contributed to various free software projects over the years but Debian is without doubt the one I’m most passionate about. I joined Debian in 2000 when I was a student. I worked on Debian more or less full time for a few years while I was pretending to study. Later I started a PhD to do research about quality and management aspects of volunteer free software projects. I investigated the release process in several free software projects, in particular looking at time-based releases. After finishing my PhD in 2007, I joined Hewlett-Packard. I’m part of HP’s Open Source Program Office and work on various free software and open source activities, both internally and within the community.

Raphael: How did you start contributing to Debian?

Martin: I first used Debian in the days of 0.93R6, some time around the end of 1995. The 0.93R6 release was still based on a.out but I needed an ELF-based system for some application, so I moved to Slackware. I then quickly moved to Red Hat Linux where I stayed for several years. I rediscovered Debian in 2000 and quickly decided to join the project. I cannot recall how I rediscovered Debian but when I did, it was clear to me that Debian was the ideal project for me: I could identify with its philosophy, I liked the volunteer nature of the project, and I found the size and diversity of Debian interesting since a large project offers a lot of different challenges and opportunities.

I remember how many new things there were to learn and back then the documentation and other resources for new contributors were nowhere as good as they are today. My application manager, Julian Gilbey, was a great help… he was incredibly friendly and passionate about Debian. I also remember meeting up with Peter Palfrader (weasel) for key signing when we were both in the New Maintainer queue. I was incredibly lucky with my New Maintainer process and soon became an official Debian Developer. Because there was a shortage of application managers, my first major contribution in Debian was to become an application manager myself and help other people join the project.

Debian is a large project with a long history and a rich culture, so new contributors should expect that it will take some time to become familiar with everything. Fortunately, there are many resources, such as documentation and the debian-mentors list, for new contributors. Another great way to become familiar with the way things are done in Debian is to subscribe to various Debian mailing lists and ideally to read some mailing list archives. It’s also a great idea to attend the Debian Conference or other conferences since meeting people in real life is a great way to integrate. I remember attending Debian Conference 1 in Bordeaux where I gave my first public talk.

Finally, new contributors should find an area where they can make a unique contribution. Most people in Debian maintain packages but there are so many other ways to contribute. For example, most of my contributions were not technical but were about coordination and other organizational activities.

Raphael: What’s your biggest achievement within Debian?

Martin: I’m particularly proud of a number of achievements:

New Maintainer: I helped a lot of people join Debian. It’s great to help someone join the project and then see how they contribute. Of course, some people join Debian and then quickly become inactive or retire… you never know in advance how it will work out. But I had the pleasure to help some truly outstanding contributors to join Debian.
Quality Assurance: I helped improve QA processes within Debian. In particular, I realized a few years ago that a lot of packages had maintainers who were inactive and that nobody did anything about it. I started to write to those maintainers to see what could be done. It’s hard because you don’t know the circumstance of someone… they may be inactive because of an illness or for other good reasons… so you have to be friendly, but yet persistent. Fortunately, most maintainers I contacted were truly inactive and so they couldn’t complain when I took their packages away.
DPL: I acted as the Debian Project Leader for two years. I’m particularly proud of this because Debian is a great project and it was an honour to represent it. I performed important organizational and coordination tasks. I also traveled to a lot of conferences and had the pleasure to meet many Debian Developers as well as users of Debian. It’s very motivating to meet users and to hear how they use Debian and how we can further improve it.
Debian on NAS: Debian is without the doubt the Linux distro with the best support for NAS (Network Attached Storage) devices. I was always impressed by what the OpenWRT folks have done to support wireless routers and wanted to do something similar for Debian. Unfortunately, wireless routers just don’t have enough storage for a full distro. But then NAS devices came along and they obviously have enough space since they are meant for storage.

Raphael: Speaking about NAS devices: what exactly are you doing on this topic and how can people help?

Martin: There are plenty of instructions on the Internet to install Linux distributions on NAS or various embedded devices by connecting a serial console and then typing in hundreds of commands. What I found is that such instructions significantly limit the user base because they are way too complicated for most users. There are just too many steps that can go wrong.

So instead, in Debian, we provide a solution that just works: usually, you download a firmware image for your NAS device from Debian and when you upgrade you get the Debian installer. You connect to the installer via SSH and perform a normal installation. The installer knows about the device and will prepare everything for you automatically… for example, it knows if the device has requirements for the partition layout and it will install the kernel where the device expects to find it; unfortunately, NAS devices are not like PCs, so the requirements are different for almost every device and therefore you need special code to support a new device. Finally, there are detailed installation guides and we provide help on our mailing lists.

There are a number of technical areas for improvement. The installation could be made even easier, and it would be nice to support new platforms and devices.

A bigger problem is that while we’ve implemented a great solution for NAS devices, we haven’t really extended this work to support other classes of devices. For example, tablets and mobile phones are getting incredibly popular and we don’t have a compelling solution for such devices, mostly because of the lack of an appropriate GUI.

Raphael: What are your plans for Debian Wheezy?

Martin: I’ve recently been asked by Stefano Zacchiroli, our current Debian Project Leader, to coordinate the care-taking of Debian finances. Debian, as a volunteer project, relies on donations and in-kind gifts (e.g. hardware) to maintain its infrastructure and to support various development efforts, such as funding sprints and other developer gatherings. Debian’s money and other assets are held by affiliate organizations around the world.

My responsibility will be to keep track of money and other assets (e.g. hardware and trademarks), work with the DPL to establish procedures related to the use of Debian’s assets, and make sure that the procedures are followed. Finally, we want to publish public statements so our donors know how we use their donations to further improve Debian. I just started working on this and this will be my main activity in Debian in the coming months.

Raphael: Speaking of money, I plan to run a fundraising to get the Debian book I wrote with Roland Mas translated (cf. http://debian-handbook.info). Is this something Debian should support?

Martin: First of all, I should make it clear that I don’t decide how Debian spends its money. This is up to the DPL to decide together with the project at a whole. I’ll just make sure that procedures are followed and expenses tracked and reported properly.

Having said that, in my opinion, it’s unlikely that Debian as a project will fund this effort. It would be inconsistent with the position of the project not to fund work directly (only some related expenses, such as travel costs to allow Debian teams to organize face-to-face meetings). Whether Debian should support the fundraising effort by helping to promote it is another question and that’s probably not as clear cut. It looks like a worthwhile effort, but on the other hand it would be unfair for authors of other Debian books for Debian to put its weight behind one… and there are many other efforts that are worth promoting… if you promote one, where do you stop? So while it sounds worthwhile, it’s probably better for Debian to stay out of it.

But somehow related to this, I sometimes worry about the fact that there are so few paid opportunities around Debian. If you contribute to the Linux kernel for a while, you have an excellent chance to get hired by someone and to work on the kernel full time. The kernel may be an extreme example but there are a lot of projects that have more paid opportunities than Debian, e.g. Mono, GNOME, OpenOffice/LibreOffice and KDE.

Obviously, there are some Debian Developers who can spend some time on Debian as part of their job. I know that some Canonical employees contribute to Debian, that support companies like credativ improve Debian as part of their work, and that system administrators fix bugs or package new software as they deploy Debian. But I think this is a minority of contributors and even they don’t work full time on Debian. Instead what I see is that a lot of people leave university, get a job and then no longer have time for Debian… or people start a family and no longer have time. I can take myself as an example since I don’t have nearly as much time as I did in the past when I was a student.

I guess there are different ways to deal with this problem… one would be to create more paid opportunities around Debian outside the project, another one might be to make it easier for new volunteers to join the project. I don’t have the answers to these questions… but it’s something I wonder about, and I also wonder whether pure volunteer projects can still keep up with projects with a lot of full time contributors.

Raphael: What motivates you to continue to contribute year after year?

Martin: Debian is a great project with a great mission, goals and people. I contribute to make Debian a better solution and to promote the free software philosophy. Finally, the community around Debian provides a lot of motivation. It’s amazing how much I’ve learned about other cultures because of my involvement in Debian and how many friends I’ve made over the years all around the world.

Raphael: Do you have wishes for Debian Wheezy?

Martin: Not really. I’m pretty happy with the way things are going at the moment. We have made a lot of organizational changes in the last few years from which the project has greatly benefited. I’m particularly pleased about the plans to adopt a time-based freeze.

Raphael: Is there someone in Debian that you admire for their contributions?

Martin: There are many people I admire greatly. I’d like to mention Joey Hess because he’s a great example to follow. He doesn’t get involved in politics, is easy to work with and does great technical work. In fact, he has made not one but several contributions that have completely changed Debian (debconf, debhelper, and debian-installer). Furthermore, Debian has a lot of contributors who have done great work over the years but who are not very vocal about it. People like Colin Watson or Peter Palfrader. Debian has many unique contributors and the list of people I admire is much longer than the few people I just mentioned.

Thank you to Martin for the time spent answering my questions. I hope you enjoyed reading his answers as I did. He raised some interesting questions.

Subscribe to my newsletter to get my monthly summary of the Debian/Ubuntu news and to not miss further interviews. You can also follow along on Identi.ca, Twitter and Facebook.

Filed Under: Debian News, News Tagged With: Debian, DPL, Funding, Interview, Martin Michlmayr, NAS, New Maintainer

People behind Debian: Sam Hartman, Kerberos package maintainer

June 24, 2011 By Raphaël Hertzog

Sam Hartman is a Debian developer since 2000. He has never taken any sort of official role within Debian (that is besides package maintainer), yet I know him for his very thoughtful contributions to discussions both on mailing lists and IRL during Debconf.

Until I met him at Debconf, I didn’t know that he was blind, and the first reaction was to be impressed because it must be some tremendous effort to read the volume of information that Debian generates on mailing lists. In truth he’s at ease with his computer much like I am although he uses it in a completely different way. Read on to learn more, my questions are in bold, the rest is by Sam.

Raphael: Who are you?

Sam: I’m Sam Hartman. I’m a 35-year-old software engineer. I am a principal consultant and co-owner of a small consulting company, called Painless Security. I started using Debian in the mid 1990′s around the time of the bo release. I ended up deciding to join the project as a developer in 2000.

Raphael: You’re blind and yet you’re using your computer as effectively as I am. Can you explain us how you setup your computer ?

Sam: I gave a talk at Debconf9 on how my computer is set up; you can watch the video for full details.

My main laptop runs Debian. I use the gnome-orca package as my primary screen reader. It speaks the Gnome desktop. It does a relatively good job of speaking Iceweasel/Firefox and Libreoffice.

While it does speak gnome-terminal, it’s not really good enough at speaking terminal programs that I am comfortable using it. So, I run Emacs with the Emacspeak package. Within that, I run the Emacs terminal emulator, and within that, I tend to run Screen. For added fun, I often run additional instances of Emacs within the inner screens.

Raphael: Are there important problems in Debian in terms of accessibility to blind people?

KDE documentation talks a lot about accessibility, but at least for blind users, the code completely fails to deliver. That means there are a lot of good packages a blind user cannot use.

The non-free Adobe Flash player has some accessibility, but it could be a lot better. The free alternatives have none.

The free PDF readers have basically no accessibility. You can use pdftotext, but you cannot actually read a PDF in a graphical application.

It’s way too easy for a misbehaving program to lock up the entire accessibility infrastructure. Gnash is a big culprit here: if my Iceweasel starts Gnash, there’s a good chance that either Iceweasel or the entire desktop will appear to hang from an accessibility standpoint. Other programs, including gksu tend to fail in this way.

Some of the more dynamic website features like pop up menus or selection lists are really difficult to find and click without causing them to disappear. This gets better and worse over time as the accessibility support in Iceweasel changes and as websites change.

Raphael: What’s your biggest achievement within Debian?

Sam: I decided to be a Debian developer because I thought that in 2000, Debian support for using enterprise security and infrastructure software was lacking. Back then, any software that included crypto functionality was segregated into a special non-us archive. Some of the software was missing; I started by packaging MIT Kerberos for Debian. Other software had security or enterprise features disabled in the packages. At the height of working on this, I was maintaining krb5, some SASL modules, PAM, some PAM modules,OpenAFS, a version of and Ssh with Kerberos support.

I was also involved in the effort to resolve the legal issues so that we could move security software into the main archive. I think this work has been a huge success. In fact, it’s been such a success that other people are now doing most of the work. I still maintain the krb5 package. When I started I felt like I was pushing against the flow trying to get people to add patches, sometimes even having to fork a package. However, now, I can maintain just one component and there are enough others who shared my original goal that the work continues.

These days, I’m working on something that’s an evolution of this enterprise security work. I’m packaging Project Moonshot for Debian and Ubuntu. Project Moonshot is a response to the wide variety of identity management systems such as OpenID, Oauth, SAML, and the like. Moonshot works to create an identity management approach that works well both for the web and for client-server and other applications.

The project is a lot of fun, but the role of Debian in the project is also interesting. One of the things we want to show with Moonshot is how our technology can be effective when it is integrated throughout a platform. To really show the potential it needs to work with as many applications in a given platform as possible.

The open and collaborative nature of the Debian community makes it possible to introduce a new technology and have that technology evaluated based on its merits. We don’t need huge business relationships or marketing deals to integrate our technology: we need some combination of doing the work ourselves and showing others the benefits of working with us. For someone trying to do innovative work, the Debian model is powerful.

Raphael: If you could spend all your time on Debian, what would you work on?

Sam: I’d really love to work with the embedded Debian folks. The vision of a single source base that could be the stack from devices from small embedded devices all the way up to high-end servers is very appealing. Doing that with Debian involves a number of challenges. However with the right people working on meeting these challenges full-time, I think we could offer something promising. I’d also love to have the time to contribute to project infrastructure: working on the release team, helping ftpmaster, that sort of thing. However I don’t. I’m just happy that so much of my consulting practice involves working on open-source software.

Raphael: What’s the biggest problem of Debian?

Sam: There’s something really not right about how we transition libraries from unstable to testing. Every time I get involved in a library transition I’m shocked at how complicated it is and how disruptive it is both to testing and unstable. We need to look at technology and processes to break up the dependency snarles. For example we don’t have good archive tools for keeping old versions of libraries around to ease transitions.

If you haven’t thought about this issue you’ll probably say that I’m being overly picky and this can’t be the major problem for Debian. However, if you think about how much this impacts our ability to introduce things into unstable around the times of the freeze or about how much it slows the release process, you may begin to appreciate how big of an issue this is.

Raphael: Is there someone in Debian that you admire for their contributions?

Sam: There are a number of people who have been role models for me over the years. Anthony Towns really helped me understand a lot of what drives free-software projects and what needs to be true for positive motivation. Joey Hess showed us all that sometimes, social problems do have technical solutions. If the tools are so good that doing the right thing is far easier than any other course of action, quality improves.

Thank you to Sam for the time spent answering my questions. I hope you enjoyed reading his answers as I did. Subscribe to my newsletter to get my monthly summary of the Debian/Ubuntu news and to not miss further interviews. You can also follow along on Identi.ca, Twitter and Facebook.

Filed Under: Debian News, News Tagged With: Accessibility, Blind, Crypto, Interview, Kerberos, Sam Hartman

People behind Debian: Ana Beatriz Guerrero López, member of the Debian KDE team

People Behind Debian: Josselin Mouette, founder of the Debian GNOME team

People Behind Debian: Steve McIntyre, debian-cd maintainer, former Debian Project Leader

People behind Debian: Ben Hutchings, member of the kernel team

People behind Debian: Stefano Zacchiroli, Debian Project Leader

People Behind Debian: Mark Shuttleworth, Ubuntu’s founder

People behind Debian: Peter Palfrader, Debian System Administrator

People behind Debian: Margarita Manterola, Debian Women member

People behind Debian: Martin Michlmayr, former Debian Project Leader

People behind Debian: Sam Hartman, Kerberos package maintainer

Liberate the Debian Handbook

How to thank me

Email newsletter

Debian DVD with firmware

Follow me

Discover my French book

Advertisement

Archives

Planets

Recent Posts

Liberate the Debian Handbook

How to thank me

Email newsletter

Debian DVD with firmware

Follow me

Discover my French book

Advertisement

Archives

Planets

Recent Posts

Tags