An Interview with Drew Eckhardt
Welcome to the unexpurgated version of Linux Journal's Linux Kernel Who's Who. If you haven't yet seen our June 2000 issue, which features 40 profiles of some of the kernel's pioneers (hackers like Lars Wirzenius, Pauline Middlelink and, of course, Linus Torvalds), make sure you get a copy from your nearest newsstand - or your nearest Linux Journal web site. If you have already read the profiles, then our unexpurgated versions of the original interviews, which were e-mailed to each major contributor to the Linux kernel, may reveal a few surprises, and a lot more detail.
We'll be posting the original interviews here on the Linux Journal web site over the next several weeks. So sit back, and enjoy a few words from some of the folks who helped make Linux possible!
Linux Journal: How did you first learn about Linux? What were you doing in your own life at the time?
Drew Eckhardt: I saw a Usenet posting from Linus along the lines of "I've thrown together this Minix-like system to teach myself about the i86 architecture. You guys might want to check it out ..." I was an 18-year-old student studying computer science at the University of Colorado. One condition attached to my Woz scholarship was working for the university as a jack-of-all-trades system administrator, with Evi Nemeth as my boss. She gave me a login, told me about the man command, explained sudo, and let me loose with root access in the CU-CS undergraduate lab.
It didn't take long for me to decide that UNIX was hacker friendly - "hacker" in the classical meaning of cobbling bits and pieces together in an elegant manner to make them do interesting things.
LJ: What attracted you to it, compared to FreeBSD, proprietary UNIX systems, or lucrative areas such as Windows? What made you want to help with development?
Drew: At that time, the only freely redistributable BSD was the Jolitzes' project. They said that since it was a research system, it didn't matter if it ran on everyone's system, and weren't accepting patches. At the other extreme, Linus accepted my changes to the boot blocks and IDE/WD1003 driver and had new releases out within the day. Since I wanted to have UNIX on my machine without spending rent money on more (supported) hardware, I preferred Linus' approach. Later, Linux ran better on small systems, I had inertia, and the AT&T lawsuit kept me away from the BSDs.
At that time, I'd never run any of the commercial PC Unices. Later, I used SCO in a commercial environment and found it slower and less stable than Linux. Money wasn't really a consideration. I started doing UNIX in my free time because its interfaces and tools were more programmer friendly and elegant than the Microsoft products. Recently, I've discovered that competent people's salaries are more a function of their negotiating skills than the area(s) they've decided to work in.
With regard to development, I wanted to run some free UNIX on my hardware. Since I didn't like what Bill Jolitz was doing, that meant Linux. When I first got it, the boot blocks didn't work on my system (I converted the source to A86 with a Perl script and tweaked them until they worked). After that, the disk driver wouldn't come up when the system had non-IDE/WD1003 drives. Linux worked well on my 45M MFM drive, although I figured it would work better with my 85M SCSI drive.
I was too impatient to wait for someone to fix these problems, and solutions (albeit not necessarily the most correct or elegant) weren't too difficult. Farther on, I continued to contribute to the Linux kernel because it was fun. I did the SCSI-HOWTO to cut down on the number of times I answered the same questions in e-mail or on Usenet.
LJ: What part of Linux were you personally interested in and working on? How are you still involved with Linux development?
Drew: The SCSI subsystem. And, no. As I began playing with more interesting projects professionally, I no longer had a void that needed filling in my spare time. Developing for the Linux kernel and user lands would also be too close to what I do at work (proprietary FreeBSD VFS code and user-land system software). The few UNIX hacks I've thrown together at home have been under FreeBSD because of the more coherent build process.
LJ: What was most important to you about Linux? What's the very best thing about Linux?
Drew: It was an opportunity to play with an interesting non-trivial software project. The best thing about Linux is the size of the community, because of the number of programmers within it who've contributed device drivers and user-land ports.
LJ: How important was the GNU project, and how did the GNU Hurd factor in to your thinking? Should Linux be known as GNU/Linux?
Drew: The GNU project was very important, in two ways. One, it provided a usable, free tool chain which allowed anyone to contribute to the project. Two, it demonstrated that large, distributed software projects were viable. There is a third reason, somewhat. All the workstation vendors (Sun, DEC, HP) had used substantial amounts of BSD code and made minimal contributions back to the freely available sources. The GPL has forced companies to contribute their changes back to the Linux effort and to release their drivers in source form, so that bugs can be fixed even if the company is unwilling to do so.
The motivation behind Linux was a useful system. The HURD seemed like it would be a playground to explore interesting ideas, even if they made for a less practical system. With a 4M 386-33, I preferred the "useful system" approach.
"GNU/Linux" was RMS' attempt to exploit the success of Linux. Tom Christiansen looked at how much of his Linux machine was GNU, X consortium, or BSD. If I recall correctly, he found that less than 20% of our code came from the Free Software Foundation. Other sources each contributed more to the distribution he was using.
LJ: What was it like to be working with others over the Internet at a time when several computer luminaries thought that organizing successful software development over the Internet was difficult, if not impossible? Did you realize how revolutionary this approach was?
Drew: In hindsight, the development effort wasn't too different from commercial environments where developers hide in their offices, work on some subsystem and release the code as certain functions are completed. Unfortunately, both those commercial situations and the Linux kernel lack the design and implementation gatherings (I'm reluctant to invoke the negative connotations attached to "meeting") which provide the multiple viewpoints needed for the cleanest, smallest, fastest and most maintainable implementations.
Linux and some commercial projects also suffer from the lack of formal automated regression testing, making it hard to pin down what changes resulted in bugs or performance degradation. Having never worked on a non-trivial project before Linux, I had no baseline to compare it to. I didn't know what was missing from the development process until I lucked into my third, full-time professional position.
LJ: What are you doing with your life now? What's a typical day like? How do you find time for work and Linux, and how do you balance free software with the need to make a living (or the desire to become rich)? What do you do for fun?
Drew: I'm a software engineer. The company I work for builds digital video servers for the broadcast (commercial spot-playout, news show broadcast, east to west coast time delay) and post-production (computer effects) markets. Our boxes run FreeBSD on custom i86 hardware. I'm still single, alternating between periods of dating and swearing off women as an unneeded frustration.
A typical day? Depending on who I'm working with (people playing with the same subsystem working 9-to-5 hours call for an earlier arrival), machine shortages during prime working hours and whether I'm currently suffering from a bicycling addiction that calls for lunchtime rides, I generally head in to work between 10 a.m. and 2 p.m. Since I'm allergic to commuting, I don't work outside town. Currently, this makes for a 3-mile journey each way by foot, bicycle or motorcycle.
A couple of hours later, I assemble a sandwich or inhale junk food for lunch. Dinner calls for dining out at 7 or 8, with the restaurant selection depending on who's going (I enjoy almost everything except American and European vegetables, although one of my co-worker dining companions can't handle "foofy" garnishes and most foreign food). Assuming no deadlines are coming up, 8-10 hours of work later I go home, feed my fish, and often overdose on pinball.
All said, I make a comfortable living developing in an all free-software environment.
LJ: Who do you think other than Linus has had the most influence over the Linux community, and why?
Drew: Probably Alan Cox, for what he's done with the Linux network code and various other projects.
LJ: What do you think is the most important addition or change needed by Linux in order for it to succeed further? In what direction does Linux development need to go? Where is Linux's future the brightest? What is the #1 biggest threat to Linux today?
Drew: In the server environment, clustering is most important. On the desktop, Microsoft compatibility. As for threats, in the server market, I could say Microsoft because in theory they could produce better server software. On the UNIX desktop, I could say FreeBSD, because its CVS repository makes it much easier to track the latest changes, and its installation is more complete and coherent.
However, there's a lot to be said for inertia. "Everyone knows" Microsoft's operating systems crash often and their server software is insecure and doesn't scale. It will take a lot to overcome that. A lot of people could run one of the BSDs, although they don't offer enough obvious advantages for Joe Average User to switch. Jane Doe is going to install Linux rather than BSD because that's what her friends have and mass media is covering.
LJ: How do you feel about Linux's current popularity? Would you have preferred it stayed contained in the hacker community? Would it have survived on the fringes?
Drew: Sure. Linux would have survived as long as there were developers running it.
LJ: Would it have survived without the IPOs and financial backing? What impact has the commercialization of Linux had? How do you feel about Linux profiteering and the people who make millions off of other people's volunteered efforts?
Drew: Commercialization has given free software credibility, which allowed people to use it in more commercial environments. It's also allowed for a few IPOs, which have enriched a large number of stock portfolios to varying degrees.
With regard to profiteering, I'm a big fan of capitalism. I also tip reasonably when I dine out, and consider tipping the right thing to do. An analog in the Linux community would be more source, service and financial contributions from successful commercial developers.
LJ: How can Linux compete with Microsoft in the desktop sector, and will we be able to hold the commercial sector if we don't take the desktop as well? Can we take the desktop without ruining the spirit of Linux by dumbing it down? Where will our next areas of growth and expansion be?
Drew: Linux can compete with a killer application that doesn't run elsewhere. Historically, platform-specific killer apps have sold many copies of operating systems and the hardware needed to run them. Sonic the Hedgehog sold Sega consoles. Visi-calc sold CP/M and the Z80. Turbo-Tax is the reason many of the most dedicated UNIX users have Microsoft on their machines. Better Windows compatibility or sales of VMware may help too, because they would allow people to run Linux applications without rebooting to run their "needed" Microsoft applications.
Various Unices will remain the choice for dedicated Internet servers as long as the UNIX software is more robust, secure, scalable and faster than Microsoft's offerings. With more solid software from Microsoft, UNIX servers will still remain the choice for some time because of reputation and inertia.
Drool-proofed user interfaces don't preclude expert-friendly interfaces. Apart from AIX, the graphical system administration facilities provided with many workstation Unices still allow you to edit files. Pop-up search boxes can still use regexes. Hieroglyphic icons don't rule out a command line. As long as the UNIX user-land programs aren't replaced, we'll be no worse off, although I'd like to see more flexible (scriptable, regex empowered, etc.) and efficient (educated people can type "find" faster than they can locate a picture that looks a bit like binoculars and click on it) interfaces on new software.
LJ: How do you feel about commercial applications being written for Linux, and proprietary software and protocols in general? Do you run Linux more for philosophical reasons or practical reasons? If something that appeared to be better came along, would people jump ship? Conversely, would we stay with Linux even if it somehow degenerated, took a wrong turn, or stopped progressing?
Drew: Commercial applications for Linux are great. More functionality is good. Free applications would be better, though. In niche markets, we'll always have proprietary software because those markets can't or won't fund new products, and software companies can't guarantee they'll sell the support needed to pay for development after the fact.
In the general consumer market, (proprietary software's) days may be numbered. Legal issues aside, buying shrink-wrapped proprietary software is a bit silly when you can get the same software on a CD for a dollar. I think people pay more to get the packaging, documentation, support and other services available to retail purchasers. Free software formalizes the existing situation and provides benefits to both the software producers (who don't need to develop new products from scratch, allowing for lower labor costs and shorter time to market) and consumers (who can get their bugs fixed and new features developed, even if the original company is willing to do neither).
Proprietary protocols are more likely to have holes which are later exploited by crackers, are a bit immoral and potentially illegal.
LJ: How do you feel about the different licenses? GPL, LGPL, QPL, etc.?
Drew: The GPL has both benefits (it forces companies to distribute derived works under the same terms) and drawbacks (it forces companies to distribute derived works under the same terms).
LJ: Do you think the community should support only open-source/free software? How would the community survive hard times if there were a lag or down time in the continuing success of the open-source methodology? Is the free software philosophy strong enough and with enough adherents to pull us through?
Drew: Even RMS has conceded (through his actions) that the community should support both proprietary and free software. The last time I encountered RMS, his laptop booted using proprietary firmware.
Practical Task Scheduling Deployment
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.View Now!
|The Firebird Project's Firebird Relational Database||Jul 29, 2016|
|Stunnel Security for Oracle||Jul 28, 2016|
|SUSE LLC's SUSE Manager||Jul 21, 2016|
|My +1 Sword of Productivity||Jul 20, 2016|
|Non-Linux FOSS: Caffeine!||Jul 19, 2016|
|Murat Yener and Onur Dundar's Expert Android Studio (Wrox)||Jul 18, 2016|
- The Firebird Project's Firebird Relational Database
- Stunnel Security for Oracle
- My +1 Sword of Productivity
- SUSE LLC's SUSE Manager
- Non-Linux FOSS: Caffeine!
- Managing Linux Using Puppet
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Parsing an RSS News Feed with a Bash Script
- Google's SwiftShader Released
- Doing for User Space What We Did for Kernel Space
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide