Linux for Suits - The Usefulness Paradigm
I don't write code, but I do write prose. It's different, but there are similarities and overlaps. Code writers have also supplied me with a useful cache of metaphors. For example, I can explain my writing method as a debugging and patching process—and not just because those are metaphors for editing. Rather, it's because I regard most of my writing less as finished work than as useful information that is always subject to improvement. I'm not just here to express. I'm here to help. (Okay, sometimes I just joke around, but that's different.)
My model is the most useful tome I've ever read, The Elements of Style, by William Strunk Jr. and E. B. White. Better known just as “Strunk and White”, the book's 1.0 version (en.wikisource.org/wiki/The_Elements_of_Style) was written in 1918 by Strunk alone, when he was a professor of English at Cornell University. It was privately published and only 43 pages long. It began:
This book is intended for use in English courses in which the practice of composition is combined with the study of literature. It aims to give in brief space the principal requirements of plain English style. It aims to lighten the task of instructor and student by concentrating attention (in Chapters II and III) on a few essentials, the rules of usage and principles of composition most commonly violated. The numbers of the sections may be used as references in correcting manuscripts.
The book is a model of brevity and pith. The paragraph above is first of the five that make up Chapter I, which fits on a single page. Here is Strunk's outline for Chapters II and III:
II. Elementary Rules of Usage
1. Form the possessive singular of nouns with 's.
2. In a series of three or more terms with a single conjunction, use a comma after each term except the last.
3. Enclose parenthetic expressions between commas.
4. Place a comma before and or but introducing an independent clause.
5. Do not join independent clauses by a comma.
6. Do not break sentences in two.
7. A participial phrase at the beginning of a sentence must refer to the grammatical subject.
8. Divide words at line-ends, in accordance with their formation and pronunciation.
III. Elementary Principles of Composition
9. Make the paragraph the unit of composition: one paragraph to each topic.
10. As a rule, begin each paragraph with a topic sentence; end it in conformity with the beginning.
11. Use the active voice.
12. Put statements in positive form.
13. Omit needless words.
14. Avoid a succession of loose sentences.
15. Express co-ordinate ideas in similar form.
16. Keep related words together.
17. In summaries, keep to one tense.
18. Place the emphatic words of a sentence at the end.
Just reading that outline makes you a better writer. Digging deeper has the same effect. Take #13 from Chapter III: “Omit needless words.” It begins:
Vigorous writing is concise. A sentence should contain no unnecessary words, a paragraph no unnecessary sentences, for the same reason that a drawing should have no unnecessary lines and a machine no unnecessary parts. This requires not that the writer make all his sentences short, or that he avoid all detail and treat his subjects only in outline, but that every word tell.
Familiar? Seems to me the same principle applies to writing code. One difference is that writers of prose generally need to be instructed on the value of brevity while writers of code do not. That may seem a harsh or inaccurate statement, but I make it because code is purposeful in ways prose does not have to be. In fact, blather is sometimes the very purpose of prose. Garrison Keillor once called English “the preacher's language” because “it allows you to talk until you think of what to say.”
I suppose you can blather in code too. Back in the late 1990s, I was sitting in the office of Phil Hughes, Linux Journal's founder and publisher. He had just come from an argumentative session with a group of geeks in another room. Imagining I would know what he was talking about, he threw a pile of code printout onto his desk. “Look at that!”, he said. “Six pages of Perl! I could have done the same thing in one page of awk!”
I'm not saying Perl is blather, by the way (though Phil might). I am saying that omitting needless words is a code-writing value for which prose writers require help from the likes of William Strunk.
Version 1.5 of Strunk and White came with a 1935 revision by Edward A. Kenny titled The Elements and Practice of Composition. Strunk died in 1946. Far as I know, his book didn't change until 1957, when the writer E. B. White, once a student of Strunk's, came again upon “the little book” and set about improving it with two short additional chapters and a return to the original title. This first edition of what came to be called “Strunk and White” was version 2.0 of what began as Strunk's alone. In the 86-page 1979 edition, White explained:
A second edition of the book was published in 1972. I have now completed a third revision. Chapter IV has been refurbished with words and expressions of a recent vintage; four rules of usage have been added to Chapter I. Fresh examples have been added to some of the rules and principles, amplification has reared its head in a few places in the text where I felt an assault could successfully be made on the bastions of its brevity, and in general the book has received a thorough overhaul—to correct errors, delete bewhiskered entries, and enliven the argument.
White died in 1985. The 1999 fourth edition of the book has a forward by White's stepson, Roger Angell, plus an index, a brief afterward by Charles Osgood and a glossary by Robert DiYanni. The current entry in Wikipedia notes, “An anonymous editor modified the text of this 1999 edition. Among other changes, he or she removed White's spirited defense of 'he' for nouns embracing both genders. See the 'they' entry in Chapter IV and also gender-specific pronouns.” In his forward, Angell puts it more gently, “This edition has been modestly updated...with a light redistribution of genders to permit a feminine pronoun or female farmer to take their places among the males who once innocently served him. Sylvia Plath has knocked Keats out of the box, and I notice that 'America' has become 'this country' in a sample text, to forestall a subsequent and possibly demeaning 'she' in the same paragraph.”
Astute readers of Strunk, White and Linux Journal will observe that we violate one of the former pair's original commands by putting our punctuation outside our closing quotation marks, unless it is part of the quotation. This complies with a Linux Journal copy-editing policy established by Phil Hughes in 1994, in compliance with what had already become geek vernacular. One of my first arguments with Phil was over this very practice. I lost.
Today if you look for The Elements of Style at Amazon.com, you'll find three different books: The 1999 fourth edition, Strunk's original edition and The Elements of Style Illustrated, which (Wikipedia tells us) is the fourth edition plus illustrations by Maira Kalman. Somehow I can't help regarding the three as “distributions” of Strunk's patched kernel, each useful in its own way.
It's also interesting to read and compare the discussion and history pages behind the Wikipedia entry for The Elements of Style. The former calls to mind the Linux-Kernel Mailing List (LKML), while the latter serves as a kind of code repository. These analogies are far from precise, but there is a common purpose in usefulness.
What brought me to this fresh appreciation of usefulness was a blog post by Alan Mitchell titled “Beyond the persuasion paradigm” (rightsideup.blogs.com/my_weblog/2007/08/beyond-the-pers.html). He writes:
Our modern commercial setup is organised around a persuasion paradigm, where the driving force in commerce is companies and their attempts to persuade individuals—so-called consumers—to buy their products or services (and not those of their rivals).
We are, however, groping our way towards a personal decision-making paradigm, whose centre of gravity is helping individuals make and implement better decisions at lower cost (where “cost” includes time and hassle cost, as well as money cost). This is being made possible by an information age: our increasing ability to search for, gather, store, filter, edit, slice and dice, analyze, share the information we need to for our decision-making.
Better personal decision-making (and implementation) is an era-defining shift for two simple reasons: it shifts the focus of value creation from companies and their goals to individuals and their goals, and it encompasses all aspects of production, distribution and exchange (and a whole lot more)....
There is in this a declaration of independence for individuals, in heed of the need to equip human beings with better ways to learn, to make choices and to exercise their autonomy. What's not clear, and needs to be, is the role played by programmers in equipping everybody with the freedom to escape the old persuasion paradigm, and a value system in which the dependencies that matter most are ones where buyers rely entirely on sellers.
Free and open-source code does not only express the free choices of its authors, but it provides practical ways to expand the freedoms of those who use and depend on that code. Before I read Alan's piece, I didn't see the connection between proprietary code and a larger paradigm anchored in persuasion. The problem with proprietary code in many cases begins with motivation. It's not just about making secret bits and driving up sale value by making those bits scarce. It's about controlling the customer. The persuasion paradigm puts a premium on captive, dependent customers. Worse, it restricts the usefulness of products to just what works for the seller. This usually involves limiting choices for customers.
What Alan calls the personal decision-making paradigm has been supported from Day Zero in the Free and Open Source Development world. What we have here, I submit, is a usefulness paradigm—one that has had a quiet and transformative influence on all it supports. Today, that includes Linux, the Internet and countless other useful goods, all of which support far more economic vitality and growth than we ever enjoyed from the persuasion paradigm. (With due credit for all it did achieve in its day.)
I share that observation with the intent that it will prove useful. If it's not, we'll patch it, discard it or rewrite it. If it is, any of us are still free to improve it.
Doc Searls is Senior Editor of Linux Journal. He is also a Visiting Scholar at the University of California at Santa Barbara and a Fellow with the Berkman Center for Internet and Society at Harvard University.
Doc Searls is Senior Editor of Linux Journal
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