The Proper Image for Linux
I get mail from folks about my book, the device driver I wrote for Linux, and about articles I've written for Linux Journal. A few months ago I got one which said, in part:
My boss is a great guy to work for ...[but he] is of the opinion that Linux is the work of “college punks” and will not consider it for serious work.
He had a nightmare with the MINIX file system and is permanently convinced that UNIX simply cannot be trusted and that Linux is the work of pimply-faced sophomores with time on their hands. I got a good laugh out of that while looking at your picture and reading your bio.
I had suspicions that Linux contributors are a bright, experienced and well-educated bunch of folks. The discussions in the various Linux newsgroups and mailing lists aren't lightweight, nor is the resulting operating system. My “feel” of the operating system is that it's based on a lot of mature judgments and there is some theoretical grounding in what's being done.
I gathered up a list of contributors (from /usr/src/linux/CREDITS) and sent off 241 notes. Partial text of this note is shown in the sidebar, “Letter to Contributors”. I sent my notes with some trepidation—I didn't want to bother folks while they were working on important projects, and I feared a lack of response.
I needn't have worried. So far I've received 103 replies, many of which have included a few words of encouragement. It seems that I wasn't the only one who wanted to respond to unjustified complaints about Linux. (Another 29 notes were returned with address errors. I hope to see corrections to the CREDITS file.)
The level of response was the first piece of good news. The second was that I've been stunned by how strong the development team is with regards to both credentials and experience.
From these replies I found:
1 had completed just basic public education (high school)
15 had attended college or technical school
23 had an undergraduate degree (B.S., B.A., etc.)
19 had attended graduate school
15 had a graduate degree (M.S., M.A., etc.)
9 had done further graduate work
19 had a terminal degree (Ph.D., M.D., etc.)
That's got to totally demolish the image of college hackers—at least the sophomore part of it. I figured I was an exception when I started working on the Cyclades driver while avoiding rewriting my dissertation. I thought, once folks were awarded a Ph.D., they would be busy with research, teaching or some other interest. I guess Linux development may be the doctor's favorite hobby.
When I offered an earlier summary of these results, my correspondent reported that his boss wisely intoned, “those folks are all academia and none of them have ever tried to run a business.”
I had sort of expected a comment along those lines and fortunately asked a few more questions in my survey. One hundred of the replies also reported the number of years spent programming or doing system design.
4 had 1 year
10 had 2-4 years
31 had 5-9 years
40 had 10-20 years
16 had 20+ years
More than a few of us were programming before the integrated circuit came into general use. (Perhaps a mixed blessing—some of us may still suffer from post-FORTRAN syndrome.)
As I noted earlier, I have also felt that Linux has benefitted from a broad experience in its developer base. Linux may be a first operating system for a lucky few, but almost everyone (all but three) claimed to be at least a skilled user of another operating system. Eighty-three were skilled users of several other operating systems.
Nor was their contribution to the Linux kernel the first of that sort. Twenty have contributed to another operating system and another twenty-two have contributed to several other operating systems. One reported:
Speaking for myself, I had the same idea Linus did, but he beat me to it. (I've heard others say this as well.) I knew how to build a UNIX-like system from the ground up, and there was a need for it for PCs. (Vendors were charging exorbitant amounts for poor products in those days, and there was no good 32-bit development system for 386s.) I just didn't have the time. I had been playing with MINIX when Linus showed up on the MINIX newsgroups, and it took off from there. I can tell you that though I was a student at the time, I'd been a professional systems programmer for many years before. So, I and many others knew what professional quality software was, as well as how to produce it. I think it turned out pretty well.
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|
- Stunnel Security for Oracle
- The Firebird Project's Firebird Relational Database
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- SUSE LLC's SUSE Manager
- Managing Linux Using Puppet
- My +1 Sword of Productivity
- Non-Linux FOSS: Caffeine!
- Google's SwiftShader Released
- Doing for User Space What We Did for Kernel Space
- SuperTuxKart 0.9.2 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