We Talk to Everybody
For some, Linux represented the on-ramp to a life of hacking on the open-source operating system. For others, Linux represented a momentary opportunity to explore interesting, non-trivial software development work. It was in this latter group that Drew Eckhardt found himself as an 18-year-old CS student at the University of Colorado. Like other Linux hackers, Drew was not satisfied with Bill Jolitz's BSD work, and the attraction to a freely redistributable UNIX system proved irresistible. He told me,
I wanted to run some free UNIX on my hardware. Since I didn't like what Bill Jolitz was doing, that meant Linux.
Drew's first problems with his new Linux system led to his first contribution to Linux development. “I was too impatient to wait for someone to fix these problems (boot blocks that didn't work, disk driver problems), and solutions ... weren't too difficult,” he says. “Farther on, I continued to contribute to the Linux kernel because it was fun.”
Drew spent most of his time as a “Linux developer” working on the SCSI subsystem. But he is no longer involved in the development end of Linux. “Developing for the Linux kernel and user lands would be too close to what I do at work,” he says. The little UNIX hacking Drew has done on his own recently has tended to be FreeBSD.
While Drew emphasizes that the size of the Linux community of hackers was one of the best things about it, he doesn't think there is anything too revolutionary about the way Linux was developed. He suggests,
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.
Drew may not play much of a role in future Linux development (he is a software engineer for a company that builds digital video servers for broadcast and post-production). But his thoughts on the future of proprietary software vs. open-source systems do reveal a future for Linux. He says,
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, its days may be numbered ... buying shrink-wrapped proprietary software is a bit silly when you can get the same software on a CD-Recordable for a dollar.
Drew Eckhardt's e-mail address is email@example.com.
Some people find Linux, stay for awhile and then part ways. And others? Well, for some, when it comes to Linux, once you hack, you'll never go back.
Rik Faith is currently working with Precision Insight and, as such, gets to spend all of his work time “using and improving” Linux. Says Rik,
The popularity of Linux and the willingness of vendors to pay for Linux improvements (both in the kernel and in user space) have enabled me to find what is very nearly my ideal job: I can work at home, use Linux all the time, and get paid for improving Linux and XFree86.
Rik first discovered Linux while toiling away in graduate school. He had been working on his Ph.D when he heard “rumors about a free UNIX” in late 1991. All the same, it wasn't until spring of the following year that Rik actually downloaded the source code and booted it up. As Rik remembers, “it booted fine from floppy and was able to see my old 40MB drive, but it didn't support my Future Domain SCSI controller.”
And this is when Rik Faith's inner penguin started singing.
I ordered a manual for the Future Domain chip set, and as soon as finals were over, I started to write a SCSI device driver. After about three days, I was convinced that this was too difficult for me. But on the fourth day, I had a working SCSI driver!
And by the end of the month, Rik's hack was fully interrupt-driven and ready for Linux 0.97.
In addition to his work on the Future Domain SCSI driver, Rik also worked on the APM driver, and later did kernel work on the Direct Rendering Interface (DRI) as an engineer with Precision Insight. And like some of the other original kernel hackers, Rik has been involved in a number of non-kernel Linux projects. These include maintenance of the util-linux collection and coordination of the man page project—both of which have since been taken over by Andries Brouwer, another of the original Linux hackers. Rik even worked on his own Linux distribution, BOGUS Linux, with colleagues Kevin Martin and Doug Hoffman. “The BOGUS Linux release was the first Linux distribution to use the `pristine source plus patches' paradigm that is now familiar to all RPM users,” Rik notes.
All this nonstop Linux work has kept Rik exceptionally busy over the years. In fact, he says,
I found that I had to cut back on my Linux work for a few years while I finished my Ph.D and started a family—my wife, Melissa, and I have two daughters, Rhiannon (4 years) and Selena (7 months) ... For fun, I spend time with my wife, play with my kids, and work on free software to format, search and serve human-language dictionaries.
Rik Faith's e-mail address is firstname.lastname@example.org. Visit his work with “human-language dictionaries” at http://www.dict.org/.
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!
- SUSE LLC's SUSE Manager
- Google's SwiftShader Released
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- SuperTuxKart 0.9.2 Released
- Parsing an RSS News Feed with a Bash Script
- Rogue Wave Software's Zend Server
- 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