Thanking the Longbeards
This piece resulted from discussions at David "The Rise of the Stupid Network" Isenberg's BigHook Conference last fall http://www.isen.com I presented it there and have edited it to reflect some of what I learned from BigHook's spirited (the word "asshole" was used at least twice) discussion of it. --David Weinberger
Because the infrastructure of the Internet was designed by humans, it represents particular human values. For example, the Net could have been architected to ensure that intellectual property is protected, that all interactions are tagged so they can be traced to individuals, or so that some packets have priority and thus can be sold to those with cash to burn. (Actually, for the last apparently there is an unexploited Net capability.) But it wasn't architected that way. Someone decided otherwise.
Who? Ultimately, it was the Internet "long beards" who share some characteristics: generally white, male, Western, and all highly technical. These are the folks who (again, in general) continue to make decisions about the Net's technical future. Certainly there are organized opportunities for others to comment, but even though this lets in a somewhat more varied group, inevitably those whose comments count are also technically-minded.
Just as journalists tend to favor free speech, artists value creativity, and beauty queens like make-up, engineers tend to share some values. Engineers, for reasons rooted in what they found pleasurable about engineering in the first place, tend to value open communication, to listen to opinions that are fact-based, and to respect people for what they know and contribute rather than for what their business cards say. It's no coincidence that the network they built enables the open, uncontrolled sharing of information.
How explicit are the political values of the Internet? I had a chance to talk about this with Scott Bradner, a literal Internet long beard, at BigHook. While Scott admitted that the infrastructure is loaded with values, he maintains they are first and foremost not political values. The designers set out to build a system that doesn't require modification to be extended and configured for particular uses. The designers' aim was to move packets along briskly while enabling you to add your layers of censorship or IP protection or multimedia streaming or pornographic body suits without requiring the Internet infrastructure to be rearchitected.
But, as Tom Lehrer has taught us, there's no avoiding the political values of science and technology. Lehrer--our finest lyricist until Eminem--wrote a song about Werner Von Braun, the German scientist who built rockets for the Nazis during WWII and for the US after the War: "Once they go up, who cares where they come down? That's not my department, says Werner von Braun." Lehrer's question holds for people doing AIDS research as well as for Nazis; it has nothing to do with the content of the politics.
To achieve the engineering aim of being capable of being extended without requiring changes to the core infrastructure, the long beards built a system with no built--in checks on the data being carried. Value free? Ask China or the Taliban or orthodox Jews or many Christian communities, all of whom see value in protecting their communities from "assault" by temptations and other bad influences. "For engineering reasons," the long beards in effect are saying "we've built a system that will provide open access to ideas and images you consider corrosive. Ok?" To many communities, the answer is a definite "No, it'snot ok."
It only seemed ok to the long beards because the engineering principles that led to the Net's design were consistent with the basic free-speech libertarianism of its designers. If the Net subverts the plans of the Taliban, the Internet long beards will by and large cheer (as of course will I, but that is precisely not the point) while maintaining that the design of the Net was based on engineering, not political, principles. But the political principles are in fact in part responsible for the decision to build the Net in the first place. Had the engineers designing the Internet been members of the Taliban, they would not have found the idea of building an open, uncontrolled system any more appealing than most Western engineers find the idea of building a gun that can turn any material into an armor-piercing bullet "without requiring any redesign of the gun's fundamental architecture." The design values implicit in the architecture of the Net simultaneously instantiate a set of political values generally shared by the engineering community; that was part of the appeal of working on the Net project in the first place. The most important "unintended consequences" of the Net--a permission-free environment for creating and sharing information--are in fact predictable, foreseen and--one way or another--intended.
Two consequences follow from this. First, technical, architectural discussions always ought to occur within the context of the human and political values that inevitably guide them. Second, those of us who think that the values the Internet instantiates are good values ought to thank the long beards not just for their technical skill but for making the world a better place.
So: Thank you.
 Please keep in mind that generalizations are true if they are generally true; a generalization is generally not true in each and every case. Pointing out exceptions does not prove the generalization false.
 See note #1
 That is, please don't write to tell me that the designers of the Internet aren't Nazis.
 I'm using "libertarian" in its original John Stuart Mill sense, not the Ayn Rand "Selfishness is good" sense. Before flaming me, please read Mill's On Liberty and include a book report in a nice binder. (Stapled submissions will be lowered one half grade.)
 If you haven't read Lawrence Lessig's Code, consider it a class assignment.
Doc Searls is Senior Editor of Linux Journal
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
- My +1 Sword of Productivity
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Non-Linux FOSS: Caffeine!
- Managing Linux Using Puppet
- SuperTuxKart 0.9.2 Released
- Doing for User Space What We Did for Kernel Space
- 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