The New Beginning
The word, in the end, is the only system of encoding thoughts—the only medium—that is not fungible, that refuses to dissolve in the devouring torrent of electronic media. --Neal Stephenson, In the Beginning Was the Command Line
Jokes beginning “If operating systems ran airlines” first appeared on the Web around 1995. Linux wasn't mentioned back then, but it is now, like in this set published in the September 1999 Linux Gazette and condensed here:
UNIX Airways: everyone brings one piece of the plane along when they come to the airport. They all go out on the runway and put the plane together piece by piece, arguing non-stop about what kind of plane they are supposed to be building.
Mac Airlines: all the airline personnel look and act exactly the same. Every time you ask questions about details, you are gently but firmly told that you don't need to know, don't want to know, and everything will be done for you without your ever having to know, so just shut up.
Windows Air: the terminal is pretty and colorful, with friendly stewards, easy baggage check and boarding and a smooth take-off. After about 10 minutes in the air, the plane explodes with no warning whatsoever.
Windows NT Air: just like Windows Air, but costs more, uses much bigger planes, and takes out all other aircraft within a 40-mile radius when it explodes. (The 1995 version—everyone marches out on the runway, says the password in unison, and forms the outline of an airplane. Then they all sit down and make a whooshing sound like they're flying.)
Linux Air: disgruntled employees of all the other OS airlines decide to start their own airline. They build the planes, ticket counters and pave the runways themselves. They charge a small fee to cover the cost of printing the ticket, but you can also download and print the ticket yourself. When you board the plane, you are given a seat, four bolts, a wrench and a copy of the Seat-HOWTO.html. Once settled, the fully adjustable seat is very comfortable, the plane leaves and arrives on time without a problem and the in-flight meal is wonderful. You try to tell customers of the other airlines about the great trip, but all they can say is, “You had to do what with the seat?”
I'd change that last one to open with “UNIX geeks who finally figured out what kind of plane they were supposed to be building ...” And I'd end it with, “After a while, nearly everyone flew Linux Air, whether they knew it or not.”
To the extent that flying with computers happens mostly over the Net, the Linux takeover is already underway. The recent surge in Apache's dominance owes to the growing adoption not just of Linux, but of the BSDs and other UNIX breeds that share Linux' virtues.
But there's still that problem with the seats. I witnessed it at PC Forum in March, where attendees were given Net access (and everything else they could figure out) through dozens of VA Linux systems running GNOME. This was candy for the technical types, but it was like chewing on rubber bands for everybody else. Under normal conditions, I'm about the last guy you'd want to call for tech support, but I found myself walking around explaining things to venture capitalists, dot-com zillionaires and other smart guys who looked as lost as moths in lampshades, flummoxed by a user interface that produced cryptic pop-out menus and windows that iconized to locations other than the bottom of the screen.
“How can I open a Word file?” one guy asked. Another looked for “Excel or something like it”. We found ways to help some of these folks, but the lack of obvious “office” applications did not sell Linux as a desktop OS. I asked more than a dozen of these guys if they were tempted in any way by their experience with Linux at the show. Without exception, the answer was no (but a few open-minded tech types had kind words for GNOME).
The break-out session didn't help, either. Despite valiant efforts by the VA guys, it was too easy for the majority to dismiss the evidence: some Mozilla innovations (still a no-show), a nice little open-source presentation program (with jaggy screen fonts) and new banner-blocking software (old hat on Windows). Afterwards, a veteran PC Magazine editor told me they really like Linux and want to give it positive coverage, but in the absence of productivity applications, there's almost nothing other than the usual sports coverage of server-vs.-server games.
Nobody is more aware of the situation than Larry Augustin, the founder, President and CEO of VA Linux. In February, Larry and I were both on an open-source panel put on by the New York New Media Association. There, he made the surprising point that so far, open-source developers haven't understood the significance of Microsoft Office, which—far more than Windows—is at the core of Microsoft's appeal. After we got back, I asked him to run that one by me again to make sure I got it right. He replied:
Open-source developers understand UNIX. This is part of what made it possible to create a better UNIX—Linux. In order to create a better MS Office, open-source developers need to understand MS Office in as much detail as they understood UNIX. My fear is that the open-source developer community doesn't understand Office. It can't create what it doesn't understand. What we need are more developers using Windows and Office.
Tall order. Most open-source developers I know would rather not stain their retinas with light from Microsoft pixels. So we live with office suites (including fractions of suites) from Sun (StarOffice), Applix and Corel. All three are closed source. In the absence of source code, there's little for developers to work with, so the problem persists.
Maybe we should come at it from a different angle. Airlines are kind of a server-like metaphor. Let's try a metaphor that works better for clients: cars. That's what Neal Stephenson does in his outstanding new book, In the Beginning was the Command Line. Best known for his bestsellers Snow Crash and Cryptonomicon, Stephenson is (like me) a convert to Linux from the MacOS. To frame his context, he offers an automobile metaphor:
Microsoft—Started out selling three-speed bikes (MS-DOS). These were not perfect, but they worked, and when they broke, you could easily fix them. Eventually, they came out with a colossal station wagon (Windows 95). It had all the aesthetic appeal of a Soviet worker housing block, it leaked oil and blew gaskets, and it was an enormous success. NT was an off-road version: no more beautiful than the station wagon, and only a little more reliable. Apple—another bike dealership that one day began selling motorized vehicles, expensive but attractively styled cars with their innards hermetically sealed, so that how they worked was something of a mystery.
Be—a dealership selling fully operational “batmobiles”. These were more beautiful and stylish than the Euro-sedans, better designed, more technically advanced, and at least as reliable as anything else on the market—and yet cheaper than the others.
Linux—not a business at all. It's a bunch of RVs, yurts, tepees and geodesic domes set up in a field and organized by consensus. The people who live there are making tanks. No ordinary tanks, these. They've been modified in such a way that they never, ever break down, are light and maneuverable enough to use on ordinary streets... Best of all, these tanks are being cranked out, on the spot, at a terrific pace, and a vast number of them are lined up along the edge of the road with the keys in the ignition. Anyone who wants to can simply climb into one and drive it away for free. These are sold by volunteer hackers with bullhorns: “Save your money! Accept one of our free tanks!... We will send volunteers to your house to fix it for free while you sleep!” The buyers reply, “Stay away from my house, you freak!” and “Can't you see that everyone is buying station wagons?”
The question is, for how long? I see an answer in the original Volkswagen Beetle. Ugly, uncomfortable, noisy and lacking conveniences like AC and automatic anything, VW bugs became a sensation in the early sixties for three simple reasons: they were cheap, reliable and easy to fix. In fact, they were so easy to fix that I remember a day when a buddy and I took out an engine and put it back three times. I'm not even sure we were sober.
On the server side, we have something of a VW Bug in the Cobalt Qube, a cute little appliance that's handy for the SOHO (home office) market. On the client side, we'll soon see appliances from Intel and others. But there's a big problem with the appliance concept: they're closed as bricks, almost by definition. That disqualifies them as VW Bugs.
The real equivalent of a VW Bug is a cheap and charmingly ugly client box that can run a stripped-down open-source office suite and bring up a bash shell. While that may sound scary to GUI-<\#252>ber-alles bigots (like Neal Stephenson and I used to be), consider this item: even though Apple will still have heaps of closed stuff running on top of their OS-X kernel (Mach inside a custom version of BSD—all open source), the OS will be accessible where it counts, through shells and a command-line interface. This is a far more interesting and useful innovation than the pixel job Apple is giving its old interface. Why? Because its market includes mechanics as well as drivers. No mechanics—no market.
Today, Microsoft is to operating systems what Detroit was to automobiles in 1963. They're way too comfortable making unreliable chrome-encrusted land yachts that people buy out of habit and fear. All it's going to take to break those habits is a box that both drivers and mechanics would love. Remember, never underestimate the fear-reducing powers of a first-rate mechanic—especially when it's yourself.
Doc Searls is Senior Editor of Linux Journal
|Designing Electronics with Linux||May 22, 2013|
|Dynamic DNS—an Object Lesson in Problem Solving||May 21, 2013|
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
- Linux Systems Administrator
- New Products
- Senior Perl Developer
- Technical Support Rep
- UX Designer
- Designing Electronics with Linux
- Dynamic DNS—an Object Lesson in Problem Solving
- Using Salt Stack and Vagrant for Drupal Development
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Have you tried Boxen? It's a
3 hours 54 min ago
- seo services in india
8 hours 26 min ago
- For KDE install kio-mtp
8 hours 26 min ago
- Evernote is much more...
10 hours 26 min ago
- Reply to comment | Linux Journal
19 hours 12 min ago
- Dynamic DNS
19 hours 46 min ago
- Reply to comment | Linux Journal
20 hours 44 min ago
- Reply to comment | Linux Journal
21 hours 35 min ago
- Not free anymore
1 day 1 hour ago
1 day 5 hours ago
Enter to Win an Adafruit Pi Cobbler Breakout Kit for Raspberry Pi
It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Pi Cobbler Breakout Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- 5-21-13, Prototyping Pi Plate Kit: Philip Kirby
- Next winner announced on 5-27-13!
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?