The Proper Image for Linux
Finally, I wanted to know if the contributors were “doing Linux” in their careers. Eighty-two said their current employment was based on their computer skills. It was interesting to note that over a third reported their current employment supported or relied on their Linux development efforts. Sadly, two reported they were currently unemployed, but one of those also noted that he was “voluntarily unemployed to have time to put my life in better order.”
Perhaps one significant difference between Linux development and academic or commercial development is the duration of personal interest. In an academic setting, a student typically has one term, or at most one year, to work on any given program. When programmers leave a company, support is picked up by someone who has no sense of what has gone before. There is greater continuity in the Linux community because of the nature of submission and distribution. No matter what is happening at school or where one works day to day, contributors can keep in touch with progress on their piece of the puzzle. One person noted, “Personally, I did start my code in school, but that does not stop me from maintaining it now.”
There are some other issues which weren't addressed by my survey. Although it might not seem relevant to quality and performance, a person's interest has a great deal to do with the outcome—it leads to a distinction between “craftsmanship” and “work product”. Another person noted:
“Intent” is what I think all of these debates are about. In the commercial world there is only one true answer to “Why are you helping develop Linux?”—“To make a living.” In the Linux community I'm quite certain the answer would be more closely aligned to “For me to use.” The Linux community tends to be self-driven and self-motivated, and that is what leads to the successes and the apparent failures in our development environment.
We are not a company; we don't have any one person, or group of people, setting the direction Linux will take. That direction is set by those with the energy to actually do something.
Another motive, akin to what pushed me to first join the effort, was shared by another respondent who said, “When I wrote [my code] for the Linux kernel I was working at [my former employer]. Linux use there was extensive, and I wanted to give something back.”
Motivation leads to the final and most significant issue—one which cannot be examined by a developer survey.
In a world driven by marketing, image is the basis for purchasing decisions. Even if a good image could be established for Linux by listing credentials or tabulating years of experience, I'd be reluctant to shift to that level. I'd much rather see acceptance and popularity for Linux based on quality and performance.
Even though I hadn't asked specific questions on this topic, a few people offered comments. One note seemed to identify, however obliquely, what may be the key to Linux's success.
In general, my experience is that most software I have seen which was developed by students is not of the professional quality I would like to see. On the other hand, much of the commercial software I have seen, which was developed by professional software development companies, is also not of the professional quality I would like to see. The difference is most people do not get to see the internals of commercial software.
Developing on this theme, another wrote:
The reason Linux is stable and usable is not because of its student programmers [or lack thereof]. It is because of the overwhelming feedback that alpha and beta testers provide. When you read the Linux kernel, you will find many parts are poorly structured, poorly written and poorly documented. However, people dared to test it and report their problems; Linus and friends respected the error reports and went ahead to fix them. That is why it works so well.
In addition, psychology sometimes causes weird effects. If a user discovers a bug in his system, reports the bug and sees it fixed eventually, that user is happy because he was treated with respect. Most likely, he is even happier than he would be in the bug-free case.
Peter H. Salus reports the UNIX philosophy in A Quarter Century of UNIX as:
Write programs to work together.
Write programs that handle text streams, because that is a universal interface.
I'd like to close by adding another entry, suggested by UNIX and dominant in Linux:
Write programs you enjoy.
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
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Doing for User Space What We Did for Kernel Space
- SuperTuxKart 0.9.2 Released
- Google's SwiftShader Released
- Parsing an RSS News Feed with a Bash Script
- Rogue Wave Software's Zend Server
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