Cooking with Linux: Linux Leadership
All right, maybe this isn't the best way to expound my crackpot political views, but this ethical question is a good way to present the specific case of Linux.
I'm no political scientist, but it seems fairly obvious that almost any group of people working together needs leadership of some kind. More often than not, that leadership comes from a single person—that person makes the “final” decisions, no matter how intertwined the chain of command appears to be. Sometimes you have organizations that are relatively flat, where everyone is on equal ground—yet, invariably, there is a leader somewhere in the pack. More frequently you find conglomerates that are arranged in a thick mesh of hierarchy, more complex than any ISO standard. In such cases there are many leaders, each at different levels of the proverbial ladder. (Those readers who tuned in last month will remember this being discussed in some detail.)
But let's not repeat ourselves. Compared to most other organizations, the Linux community is as flat as a cracker (or nuttier than a fruitcake, depending on how you look at it). How could a system as complex, muddled, and technically fragile as a Unix kernel emerge from this hoi polloi? Good question.
The funny thing is, a Unix kernel did emerge, like it or not. Unfortunately, more and more people are starting to realize that Linux got where it is today without a central organization, without any kind of development hierarchy, without any rules or defined structure --without any thousand-page-long standards documents. And -this is the kicker—without a single penny of profit to back it all up. It's enough to gray a capitalist's hair.
Am I contradicting myself? Didn't I say that Linux did have some kind of organizational hierarchy? Well, that point is still in dispute. There are certainly no rules or defining factors which force the community to organize in any way. The software is freely distributable. If John Doe wanted, John Doe could start his own development effort, completely detached from, but based on, Linux. What's stopping people from doing just this?
The fact is that the Linux development hierarchy, if there is one, is a contribution-based organization, as discussed last month. A technocracy, if you will. But the primary drive is not control, or fame, and it sure isn't money. The thrust behind the whole thing is the desire to hack. Yes, there are many people in the “Linux community” who don't share these motivations—specifically, those who are aiding the project by selling the software commercially. But that has its place as well—would Linux be where it is today without some kind of commercial support? Probably not.
Of course, that statement depends on how you define “where Linux is today”. Many members of the development community would not consider commercial success to be one of the goals of Linux. Although it has the nice side-effect of increasing the distribution and the installed user base, that's not what Linux is about, fundamentally. Creating a free Unix system shouldn't require commercial success in order to be widely distributed; that's a kind of oxymoron.
Nevertheless, people are beginning to observe that Linux is successful (however you define the term) without any kind of conventional development structure. So, they think, “Shouldn't Linux development be organized centrally?” The lack of central support is seen as some kind of misfeature of the system: something that Linux should have, but doesn't. It is automatically assumed that applying a robust and well-tested hierarchy—beefing up the chain of command, as it were—will make things work better. Hey, it works for Microsoft, why can't it work for us?
In recent months, a number of proposals have come forward in an attempt to centralize the Linux development community. In fact, I supported one of these proposals—it does seem that Linux would benefit from the formation of an organization, somewhat similar to the Free Software Foundation, that would act as an entity to take credit for the software. This organization could own the copyrights, sell the T-shirts, and take the blame—making the legal issues surrounding the marketing and development of the system slightly less messy.
However, it has become quite clear that this kind of structure would be completely foreign to the concept of Linux, as it stands today, as well as to the developers who have brought it this far. Linus and others don't want to deal with logistics—they just want to hack. It takes enough time and energy to program and debug Linux as it is; the last thing that they need to deal with is more administrivia. Some fear that the avoidance of hierarchy may limit Linux in some way—that in order to really hit a home run in the software world, we will need to pay more attention to meta development. If that's the case, so be it. Linux doesn't need to debunk Microsoft or IBM in order to win with hackers. We're not here to obsolesce Windows NT. Although it is a fun thing to think about.
If nothing else, Linux is about doing things in a new way. (All right, so why are we implementing Unix? Another good question.) Capitalism and commercialism are alive and well, and honestly don't need any help from the Linux community. The approach that the Linux development is taking is a new—or perhaps a very old-fashioned—one, in which technical excellence is valued over market return. Now, everyone admits that Linux has various technical problems, but who says that Linux should berated by the same standards as commercial Unix implementations? I'd rather work with a system that is constantly undergoing development than a large commercial Unix package that I don't even have the source code for. The point of Linux is to develop it—there is no specific “final goal” where development will come to a standstill.
Linux is hard proof that there are alternatives to the corporate and economic systems that make the world go `round. Even so, who's to say? In five years, or maybe a month, the Linux community could fall apart, providing a textbook example of “what not to do” for future generations of software developers to heed.
Many of the primary Linux developers aren't very interested in regrouping themselves into a more structured clan. Unfortunately, this leaves open the possibility of some third party stepping in, forming such a group, and claiming to be the official sponsor of Linux. “Official” by whose mandate? I claim that the only group with the power to claim any kind of officialdom when it comes to Linux is the developers themselves -the ones responsible for bringing us the software in the first place. Happily, nothing of the sort has happened so far. Yet, the clock ticks ever onward: because the developers have been too shy to step forward and claim their title as the official arbiters of operating-systems heraldry, some impostor may attempt to seize the prize instead.
The bottom line is that the Linux development cabal should do what's necessary to protect their own right to the software which they have produced. The GNU General Public License does this by requiring the software to be explicitly copyrighted by the author. However, it seems that much of the credit for Linux has been implicitly defined—it's not immediately clear who's responsible for what. (When asked, I imagine, most of the developers would point in either direction and say, “It's their fault!”) In order to clear up the copyright fog, a compendium of credits for the development effort is currently being produced. Another way of achieving the same goal would be to form some kind of abstract entity calling itself “The Linux Development Organization”.
This organization may not do anything differently than what is done today. In fact, it could be virtually substance-free: “The set of all Linux hackers” without a rigid definition of the set's members (excepting, of course, the man who started it all—for Linus Torvalds, there's no backing out now.) Either that, or someone could sell inexpensive memberships to the foundation which would go to support Linux and free software in general.
Such a group would give the Linux development effort the appearance of congelation—as if it really had its act together. Such a group would give the rest of the world someone to point to—either in admiration or in scorn.
But some of us just like the sound of “The Linux Foundation”.
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
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- SUSE LLC's SUSE Manager
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Non-Linux FOSS: Caffeine!
- Doing for User Space What We Did for Kernel Space
- Google's SwiftShader Released
- Parsing an RSS News Feed with a Bash Script
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