Every time you boot a CD or DVD, thank Peter Anvin for making it possible. And, as a key Linux contributor that's not all Peter has done in his long Linux career.
H. Peter Anvin is one of the "old geeks" of Linux, and has been a key contributor since 1992, specializing in low level hardware. Currently he is co-maintainer of the unified x86 Linux kernel tree. Peter has contributed to numerous Linux kernel subsystems, and is the author and/or maintainer of several Open Source projects, including the Syslinux boot loader suite, the Netwide Assembler (NASM), klibc, and tftp-hpa. He founded The Linux Kernel Organization, which maintains the kernel.org servers around the globe.
Peter lives in San Jose, California, working for Intel's Open Source Technology Center. He has previously worked as an architect and technical director at Transmeta, working on CPU architecture and Code Morphing Software, at Orion Multisystems, designing personal supercomputers and at rPath, working on Linux software appliances. In his spare time, he enjoys hacking programmable logic, scuba diving, fuzzy bunnies, psychotic cats and historical reenactment. He is married to Dr. Suzi Anvin, and is the proud father of almost brand-new baby Erik.
I always wonder how people end up doing what they do, and Peter was kind enough to answer a few nosy questions.
You've been a key Linux contributor from the beginning, and have written and maintained key Linux subsystems that don't get attention like glamorous desktop environments. But they provide essential functionality that we take for granted. What are you working on now?
Anvin: These days I work for Intel's Open Source Technology Center, and my job is to make sure Linux works great on the x86 architecture, and also to make sure the x86 architecture is great for Linux. I was into low-level bits and bytes x86 hacking long before Linux existed, and have always enjoyed working very close to the hardware-software boundary, so for me this is a very exciting place to be.
I believe that the biggest weakness in Free Software is the lack of energy and resources being directed into developing and supporting open hardware. We're dead in the water without open hardware. Of course the barrier to entry is a lot higher than software; it's expensive and not something we can just sit down and type into existence. Do you have any ideas on how to improve this situation?
Anvin: The real problem with "open hardware" is that it inherently means something different than the "open" in "Open Source". At the bottom there is always a piece of hyper-purified silicon that someone has meticulously modified to turn into millions or billions of transistors, and then soldered down with other components to a manufactured circuit board. None of that is generic; even with technologies like FPGAs (field-programmable gate array, programmable silicon chips) you have to have the physical FPGA manufactured, and you would be lucky to get one-tenth of the performance of the state of the art hard silicon technology. That being said, FPGA hacking is a lot of fun.
On the other hand, look at how Linux originally appeared: a college student in Finland took an off-the-shelf commercial product and turned it into something completely different. This was not because the design itself was open, but because it was standards-based technology that could be repurposed. I don't even know what manufacturer made Linus' original PC, and it doesn't even matter -- the key was that it was built to the ISA specification which was the standard at the time; a lot of manufacturers did so and it helped push the prices way down. This is the essence of what separates a piece of hardware from a platform; the PC today is very different from the PC from 31 years ago, but there is a contiguous heritage carried forth by standards and compatibility.
The most successful open hardware projects, like Arduino, seem to have been the ones that step into a niche not where there is nothing available, but rather there is a hopeless fragmentation problem (exactly how many microcontroller development boards are there out there?) Such a market is desperate for something to become the standard platform of choice, and being an "open hardware project" gives at least a perception that there might be additional longevity over the competition. Since this is largely a self-fulfilling prophecy the openness begets the platform.
You and Suzi both have a lot of interests, and you've accomplished a lot in a short amount of time. How do you do everything you do, have you figured out a way to live without sleep?
Anvin: I don't think it is as short of a time as you think... I got started on computers very very early. The platform I learned to program on was a Swedish Z80-based computer called the ABC80. It had a whopping 16 kilobytes of RAM; my current PC has 16 gigabytes. My family was at the time in a somewhat hard financial situation, which meant I never actually owned this machine; I borrowed access to it when I could. It also meant I spent a lot of time thinking about the design long before I sat at the computer; I ended up being the weird kid sitting on the playground writing programs in machine code on pieces of paper. Eventually I ended up writing an assembler since I couldn't afford buying one and there wasn't a free one for that platform.
However, there is no question that we live very busy lives, and I often get to hear that I work way too much. A big key to making it work at all is the relative flexibility of the work environment in the modern technology industry -- elective telecommuting, flexible hours, IRC and so on; features which are pretty much necessary anyway if you are going to interact with a global development community on which the sun never sets. At the same time, it puts a big onus on the individual worker to find a sane balance with other life commitments.
One important skill is to know when to let a project go. For example, autofs has now been maintained by Ian Kent for a long time, and Cyrill Gorcunov does much more work than I do on the Netwide Assembler these days, even if I am still in charge of that project. This can be very hard if there isn't an obvious person that you can trust to hand over to, however. This is sometimes worth thinking about when a project grows from a one-man-band to a real community.
As the Linux world matures it is attracting a broader diversity of contributors and users. We need coders, designers, bugfixers, documentation writers, artists, musicians, distributors, community managers, marketers, OEMs -- it takes a large variety of skills and roles to get Linux out the door and to keep improving it. Many Linux contributors have children, but it seems that there is little energy directed towards drawing in children, and creating good child-oriented teaching tools. So where are the next generations of these essential contributors coming from?
Anvin: I actually think that there are some excellent child-oriented teaching tools out there! Kids love things where they can see the impact they are having directly, so things like LEGO Mindstorms, Arduino, the Blockly programming language, and even Minecraft are certainly things that should attract children. Some of these may not be Open Source all the way down, but I'm not convinced that matters so much at that stage; what matters is that it can be programmed, and that it provides a platform for sharing.
In the 1980s what made the early home computers approachable was the fact that they came with BASIC interpreters; they were horribly slow compared to assembly programming, but they lowered the barrier to accomplish something down to very little. I used Microsoft QuickBASIC for some trivial hacking projects well into the mid-1990s when I otherwise was using Linux and C. I could hammer out a quick hack complete with pretty graphics in half an hour. I think it's the only Microsoft product that I actually miss.
Do you have any thoughts on what sort of technical education kids should be receiving in school? What skills do they need, how young should they start?
Anvin: Kids need to learn to explore. I have always found that the big problem with most school-based technical education is that it is a single path from A to B; that doesn't give any opportunity for exploration, and without exploration you have no room for creativity. Imagine an art class where every project is paint-by-numbers!
As for how young... I don't think there is a lower limit, and I definitely don't believe in protecting kids from things that are too "advanced" for them. The key is to find the spark of curiosity and let them run with it.