Cooking with Linux...
We live in a society of hierarchies, organizations, and structures. Virtually every aspect of our lives is structured in some way, be it socially, politically, religiously—you name it. Rules are hard and fast. Everything has a proper place.
This is especially true of the computing community, no doubt because computers themselves are highly structured, deterministic beasts. Large software development corporations employ scores of programmers into hierarchies so deep that the lowest-level employees are often lost in the carpeting. Every position has one or more obscure titles ranging from “Manager” to “Submanager” to “Peon”, often including secret code-names for the particular project at hand, to thwart the copycat tendencies of competing corporations.
This organization extends well beyond the physical and social world, as well—electronic files, networking protocols, and even USENET newsgroups are arranged into hierarchies. Hierarchies can be real, virtual, or purely imaginary. They're everywhere. And this is all intended, I'm sure, to teach us a very good lesson: Nothing in the Real World gets done without a strong sense of teamwork and strict organization. Nothing!
Well, almost nothing. The Linux development community is a seemingly unstructured, amorphous conglomerate. There is no single leader, or nucleus, for the organization. No single entity can claim responsibility for Linux. Each of the many parts of the Linux system, from individual kernel source files to entire distributions, are copyrighted by different individuals. In fact, it looks like a big mess. Or is the Linux development cabal as disorganized as it seems?
The Linux development community grew, like crystals, around a solitary kernel (no pun intended). Linus Torvalds was, in the beginning, singly responsible for the kernel development, back when the kernel itself was thought of as the entirety of Linux. In more recent times, however, Linus claims he authored less than 50% of the current kernel code. So, while Linus may be the “father” of this rapidly growing amoeba, very few people would assign him the title of “leader”—all due respect, of course.
But that's ancient history. It's more instructive, I think, to look at how the Linux community appears to work now. The community seems to be essentially a huge network of individuals, all working towards a single goal (or many goals, as the case may be). In fact, Linux development is not unlike guerrilla warfare, wherein every member of a small, seemingly disorganized political faction has more or less the same idea of what the overall goal is, but each individual may have his or her own ideas about how to go about it.
Within this gargantuan bee colony, it is difficult to make out any direct or intentional hierarchy among the developers, but there does seem to be a metaphysical hierarchy of sorts—a “caste” system which isn't enforced externally, but instead stems from within the community itself. This hierarchy is more a handy convention than a definite rule. Guerrilla troops are tied together by a similarly complex system of blood ties, tenure, and the occasional vendetta. But the driving force behind it all is a shared vision of the world (or the operating system) to become. Basic human natures fills in the rest.
What is this hierarchy? Most members of the Linux community observe a straightforward split between “developers” and “non-developers”. It's not always clear who is a developer and who isn't, and what gives someone the right to call themselves a developer is equally as muddy. But it seems obvious that some kind of ladder does exist. Finding the rungs is another matter altogether.
On the lowest level, it would seem, is the myriad of Linux users. These range from the extremely intelligent to the utterly clueless, but on the whole, the “users” don't contribute to the growth of Linux, beyond the occasional bug report or helping hand to another of their kind. Of course, such a claim is purely bogus—in fact, Linux users contribute to the expansion of Linux just by using it. The more popular and widespread the system is, the more flexible it has to be. Nevertheless this is an indirect effect of propagation, and while individual users may not be able to directly shape the system, the user community as a whole contributes an essential aspect of Linux just through its existence. (Waxing philosophical again, am I? Don't say we didn't warn you.)
On the highest level of this quasi-taxonomy are the “developers” who actually program and support the system. They make the most noticeable direct influence on the furtherance of Linux itself, but as is the case with the user community described above, the wide disarray of differing development goals lends itself to another form of “meta-development”. The seemingly uncontrollable patchwork of many independent development efforts, all reduced and squeezed into a single package, gives Linux a kind of spirit and—I'm not afraid to use the word—charm not found in other operating systems.
Whereas commercial UNIX systems smack of being “developed by committee”, Linux actually resembles software that has been developed by a madhouse. UNIX kernel development is deluged with black magic, obfuscation, obsolescence, and such sheer complexity that it's a wonder that programmers who, for the most part, have never met face-to-face can get anything done at all. Not to mention the obvious troubles arising from the language barrier and the inherent limitations of electronic mail.
Yet, at the core (no pun intended) of this crazy mishmash of conflicting programming models and conventions a pearl has emerged. Not only has Linux managed to survive the rough seas of early development, but it has snowballed into a colossal collaborative development effort by people from all walks of life. Everyone has the chance to contribute, no matter how insignificantly. Linux is developed by and for its users, not for some arbitrary third-party target market that commercial UNIX vendors attempt to cater to. If Linux reeks of hackishness that is because its users (and thus its developers) are hackers. Of course, non-hackers are eager to jump onto the bandwagon as well, and the first to do so have the opportunity to steer it in that direction for others to follow.
So it doesn't seem to make much sense to classify the Linux community into some kind of ladder or scale, even with Linus at the top and J. Random User at the bottom. Each member of the community has his or her own personal niche and potential for contribution. The only difference is the amount of effort that each person puts in. (For some, it takes a great deal of effort not to hack Linux, but that's another story.) Age, race, sex, and planetary origin are completely irrelevant. It's attitude that matters—and everyone has their own attitude.
What this all comes down to is this: You can look at the Linux community in any way that you please. Some prefer to see it as a ladder by ranking the members based on knowledge, aptitude, contribution, or other such intangible qualities for which there are more exceptions than rules. Others envision a flat hierarchy in which everyone is equal in a utopian technocratic society. Others, like myself, visualize a giant cocktail party gone madly awry. Who are you going to believe?
One thing is for certain, however. The Linux development guerrilla troops are effecting their programming and political aims no matter how disorganized they may appear to be. Linux is spreading like wildfire in the dry, ready-to-burn forests of the commercial UNIX market, determined to devastate anything in its path. §
We came. We saw. We hacked.
Matt Welsh is a systems programmer, student, and extreme Linux geek at Cornell University. He coordinates the Linux Documentation Project, an effort to produce a canonical set of manuals for Linux.
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
- My +1 Sword of Productivity
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Interview with Patrick Volkerding
- SuperTuxKart 0.9.2 Released
- Parsing an RSS News Feed with a Bash Script
- 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