Raphaël Hertzog: People Behind Debian: Steve McIntyre, debian-cd maintainer, former Debian Project Leader
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! 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.
- 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.
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.
One comment Liked this article? Click here. My blog is Flattr-enabled.
I just got confirmed my flight bookings for
So, in 2002 I attended my first
I had a bit of an adventure yesterday, which would have taken some
explaining if the police had gotten involved. It went a little something
like this...
My friend and former co-worker Sara was in the US Virgin Islands for the
holidays. Her boyfriend, Karl, flew there separately for the tail end of her
time there.
Yesterday, I received a phone call from Sara, saying that Karl had managed
to fly out to the Virgin Islands without his passport. Apparently you can
get there without one, but to get back into the mainland US, you need one.
She wanted to know if I could get one of my lock-picking co-workers to break
into their apartment and retrieve Karl's passport and mail it them. Karl was
supposed to fly out the next day. Attempts by Sara to contact her landlord
had failed, so they didn't have many other options (apart from mailing me a
key, which would have cost them another day).
I asked one of my co-workers, Jason, who I knew was into lock picking, if he
was up for it, and he offered to put me in touch with another guy who had
dominated the recent lock picking night that he'd run.
So now I'm talking to David, who's on board with the mission, but doesn't
have his lock picking gear on him. No problem, Jason says he'll lend me his,
which was at work with him. So we have a plan.
Our friends Ian and Melinda are currently in Australia. They've lent us
their car because it's leased, and they have some minimum mileage they're
supposed to do and they're under it, so I've been driving to work in their
car some days. As it happens, I drove to work in it yesterday.
So now David and I set out in a car that neither of us own, with a lock
picking set that belongs to another person, to break into an apartment of
someone who's in the Virgin Islands. What could possibly go wrong?
I'm told that it's not illegal to own a lock picking set, but if you're
caught with one on your person and you're not a locksmith, you can get into
all sorts of trouble. On top of that I'd have a hard time explaining the car
I'm driving.
We get to Sara and Karl's condo complex. It has a common gate that visitors
would normal get buzzed through. Turns out it's not that hard to climb over.
It's got some benign-looking spiky things on top, but I could get a leg
over from the left hand side of the gate and jump over without impaling
myself. Then I let David in and we proceeded upstairs to Sara and Karl's
apartment door, where David set to work.
Sara said that just the dead bolt was locked. David started at it with
Jason's tools, trying to be as discreet as possible. It was about 3:30pm and
there was no one around, but we could hear some noises from the neighbouring
apartment (the two front doors were right next to each other).
After what felt like about half an hour without success (the last pin of the
lock was particularly tricky apparently) David was having to resort to more
noisy techniques with the lock, so I decided to take the up-front approach
and just inform the next door neighbour what we were doing in case he/she (I
think it was a she) decided to call the cops on us. I told her through the
door why we were there and what we were doing. She didn't seem to care too
much.
David then proceeded to start "raking" the lock, essentially brute forcing
the pins with a lot of jiggling, and finally managed to pick it and we were
in. I quickly found Karl's passport where it was suspected to be, and then
we pondered how we were going to lock the door again.
We could have just locked the door knob instead of the deadbolt and closed
the door behind us, but we weren't sure if Sara and Karl had a key to the
doorknob (Sara said they always just locked the deadbolt). Sara was fine
with leaving the door unlocked until they got home, but weren't so keen on
leaving our fingerprints all over the place and then leaving the door
unlocked.
David tried to re-pick the deadbolt so that he could lock it via the same
means as opened it, and I scouted around for a key. I managed to find a key
that locked both the deadbolt and the doorknob, so I took that with us and
locked up their apartment. In David's defense, the deadbolt was a bit stiff
to lock even with the key.
I dropped David back at work, collected my stuff (it was now about 4:30pm)
and headed to the UPS Store to ship Karl's passport to him as fast as
humanly possible. I just made the 5pm pick up.
Today I received an SMS from Sara informing me that they had received the
passport. I was very impressed with how fast it got to them.
So that was all a bit of an adventure. I'm not sure how much longer Karl is
going to have to stay in the Virgin Islands as a result. I'm going to
suggest that Sara and Karl leave a spare key with someone in future.
Since I am currently working on a Windows machine at work I am looking for ways to make this thing work in a sane way. The latest insane thing is the fact that I wasn't able to log on a CVS server at work from WinCVS (which uses CVSNT) with my regular credentials, while the cached password in Cygwin did work with the Cygwin CVS.
Part of our work to make it possible to use UEFI Secure Boot on Linux has been to improve our EFI variable support code. Right now this has a hardcoded assumption that variables are 1024 bytes or smaller, which was true in pre-1.0 versions of the EFI spec. Modern implementations allow the maximum variable size to be determined by the hardware, and with implementations using large key sizes and hashes 1024 bytes isn't really going to cut it. My first attempt at this was a little ugly but also fell foul of the fact that sysfs only allows writes of up to the size of a page - so 4KB on most of the platforms we're caring about. So I've now reimplemented it as a filesystem[1], which is trickier but avoids this problem nicely.
So there should be 


I am the happy owner of a new netbook with an
In 