An Interview with Nick Holloway
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?
Nick Holloway: I was a Ph.D student at the University of Warwick, and I heard about Linux through Usenet around the time of its inception. I immediately subscribed to alt.os.linux so I could read more. In early 1993, I bought a machine specifically for running Linux.
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?
Nick: I had used UNIX (BSD and SunOS) almost exclusively since starting at the University of Warwick in 1985, and was hooked. I wanted a home computer, but I also wanted to be able to run UNIX. It had looked as if my best bet was the BSD port, 386/BSD. However, this was overshadowed by the lawsuit against BSDI.
When Linux became available, it was the obvious choice to me. It had enough to get started and be usable, but there was plenty of scope for being able to contribute to its development.
LJ: What part of Linux were you personally interested in and working on? How are you still involved with Linux development?
Nick: I was interested in the areas that I needed to work for me. I contributed patches to libc4 when I found problems that affected me. I contributed tab expansion for the tty layer in the kernel when I wanted to use a dumb terminal that couldn't handle hardware tabs.
I added the dummy network driver to ease the use of Linux with a dialup connection.
Normally, my involvement is restricted to tracking the Linux kernel mailing list and browsing the patches. I'll submit minor patches from time to time, but I am not a mainstream contributor.
LJ: What was most important to you about Linux? What's the very best thing about Linux?
Nick: I like the model of being able to modify the source to fix a problem or add an enhancement you need. You can then submit it back, and if it is seen as generally good, it gets included.
LJ: How important was the GNU project, and how did the GNU Hurd factor into your thinking? Should Linux be known as GNU/Linux?
Nick: To me, GNU Hurd is an interesting project, but it never appeared to be the way of achieving my ambition of a home UNIX machine. The GNU project was very useful in getting a broad suite of user applications, without which the kernel is not of much use. Most important of these has to be the compiler, gcc. However, while the GNU project should be acknowledged for its part in assisting Linux, I don't agree with having the title "GNU/Linux" applied to all Linux distributions using GNU software.
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?
Nick: To me, it wasn't that revolutionary at the start. I have seen it in action with the various source newsgroups (alt.sources, comp.sources.unix, comp.sources.misc), where I could make changes, submit them back to the author and see them in the next release. Initially, Linux wasn't that different; it was an OS kernel, rather than an application. It just grew to be a much larger scale.
Over time, it has become more amazing. As the size grew and the number of contributors increased, it has been amazing to see the same success. It has been good to see Eric Raymond's writings helping to clarify exactly what the phenomenon is.
LJ: What are you doing with your life now? What's a typical day like in your life? 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?
Nick: My job involves the development of business-to-business e-commerce solutions. This is mainly using NT, or Solaris, but not Linux. This isn't bad, because it allows me to separate work and play in a clean way.
I have to try and spend some time away from the computer, as my wife is not into computing. Pam is very understanding, and understands that playing with computers is a hobby. Away from the computers, we go scuba-diving, hill walking, cycling, and are avid readers.
LJ: Who do you think other than Linus has had the most influence over the Linux community, and why?
Nick: Alan Cox has been the person I have noticed most. He has been involved with major input to various parts of the kernel (networking, SMP, sound). More importantly, in my opinion, he has performed the very valuable job of maintaining the stable branch of the kernel. Although the development branch is where the kernel action is, many people just want a stable kernel for their production machines.
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?
Nick: I think without the popularity, the pace of development would have dwindled by now. I would probably have continued using it, but I think it would have remained a hacker's plaything and dwindled over time.
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?
Nick: I wish anyone well with their efforts to profit from Linux. Overall, the companies are creating a net benefit to the Linux community. For example, Red Hat and SuSE are each in the position to employ important hackers, which means they don't suffer from real work getting in the way of their Linux work. This is one of the hazards of free software development.
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?
Nick: I think there is a place for commercial applications being written for Linux. Just because the OS and many of the standard applications are free doesn't mean they all have to be. If a company has to invest in producing an application for Linux, then they have the right to charge for it.
On the other hand, I don't like proprietary protocols. I think the success of the Internet is largely due to heterogeneous machines sharing common protocols. Having open protocols gives you the opportunity to inter-operate.
LJ: How do you feel about the different licenses? GPL, LGPL, QPL, etc.?
Nick: I recognize that there will never be an open-source solution for every application, so you will never have everything available under the GPL. Without the libc being LGPL, there would never be the range of business applications available for Linux that there currently is.
LJ: Is there a world outside of computers? Are you ever afraid that you'll wake up one day and feel you have wasted your life in front of a computer?
Nick: I don't expect to think I've wasted my life. Even if I unplug myself tomorrow, to pursue my career as a hermit, I've still enjoyed the experience so far.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
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.Register Now!
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Tech Tip: Really Simple HTTP Server with Python
- SuperTuxKart 0.9.2 Released
- Doing for User Space What We Did for Kernel Space
- Parsing an RSS News Feed with a Bash Script
- Google's SwiftShader Released
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