The Connectivity Infrastructure
Craig Burton says it's the nature of infrastructure to commoditize itself and that it's the nature of commodities to ubiquitize as well. That's why he believes every company playing the infrastructure game in the computer and networking business needs an open-source strategy. If you want to drive ubiquity, open source is hard to beat. Just look at Linux. (He also points out that driving shareholder value is an orthogonal concern.)
A couple of days ago Kevin Marks pointed to the natural division between transport and protocols. But the more important distinction is between infrastructure (comprised of transport and protocols) and the stuff that depends on it, such as applications, "content" and companies in those businesses.
Toward that end is one of Kevin's links: Bob Frankston's Connectivity: What it is and why it is so important. (Background: Bob co-invented the spreadsheet with Dan Bricklin.)It's a good piece that has many provocative and important things to say. But one paragraph stands out for me as a locus of trouble:
We can now treat telephony and television as applications built upon any available connectivity. We are already used to the idea that we access any Internet service from any provider.
"We" are still a minority, to the advantage of AOL, Microsoft and entertainment industry heavies who want to leverage their application and content mass against lower layers of the infrastructure stack.
Not that they have it easy. Microsoft has successfully leveraged its monopoly position in operating systems to sell lots of mail and Web servers, but the company is still not in a position to change the underlying protocols on which those mail and Web services depend (though they're trying, with .Net). In the case of the entertainment industry, the only leverage they have is legality. They've had some success with the DMCA and similar efforts but only with controlling behavior, not with the evolution of network infrastructure. And in the case of AOL's instant messaging, there are no lower layers to be concerned about, which is why it's hard to conceive of a server-side instant messaging infrastructure, much less a business to build on it. (All due credit to Jabber, it ain't here yet -- but in time it will be).
That infrastructure is essentially an underlying condition that's easily conceived as a place. Bob calls the condition "connectivity". Larry Lessig calls it the Net's "end to end" architecture. Craig Burton has my favorite description for the place itself: a hollow sphere in which every point is visible to every other point across an empty space in the middle -- a vacuum where the virtual distances are zero. Fittingly, we conceive of the Net in place-like terms. We have "sites" and "locations" with "addresses" that are "on" the Net.
But here's the problem: what Bob and Larry and Craig talk about is obvious to us, but not to the majority of netizens to whom the Net is a remote place one "visits" by "dialing" there. The place-like nature of the Net is also not obvious to the telecom and cable backbone companies that still think of the whole thing as a distribution system -- a concept they share with the entertainment business (and, regrettably, many lawmakers).
Some broadband providers are no help, either. I was recently pleased to hear that a low-tech friend finally got DSL; but when I visited her home I found that the provider was SBC, which uses a goofy PPPOE client to bypass the PC's networking control panel, and therefore the Net could only be accessed by, of all things, "dialing up." Yes, the speed was faster, but the concept of a remote place one only visits was maintained. The idea that her PC is as connected to the Net as it is to the electric grid remained alien to her.
Of course, using PPPOE to maintain the dial-up model of the Net makes sense for SBC, which is still essentially a telephone company. Here's Bob again:
If we turn from the exciting reality of the Internet back to the other reality of Telecommunications we experience culture shock.
But for those who live within the complex world of telecom regulation day in and day out, the idea of going back to first principles isn't shocking, it's simply inconceivable. It represents a degree of reengineering that is dismissed as naïve and politically unrealistic. Once you accept the premises of the regulatory framework, all of its intricacies seem reasonable and necessary.
But not to every corporate creature that inhabits the regulatory jungle. The big ISP where I live is Cox Communications, which is the opposite of SBC in its attitude about customer connectivity. Right now Cox is rolling hundreds of thousands of cable-connected customers over to a new backbone with new servers that require new surnames for e-mail addresses and web site URLs. And it is actually simplifying connectivity by eliminating DHCP IDs and allowing customers to hook up simply with straight DHCP. The tech support guys even seem to enjoy hearing that our connection gets split to seven or more computers through a router, two Ethernet hubs and two 802.11b wireless base stations. They suspect I might be expert enough to help other customers. Which I do.
But this week I spent almost four days off the air after Cox threw the switch to the new system (from Excite@Home, which was bankrupt and going out of business). Why? Because Cox sent out fancy conversion kits that failed to explain in plain terms that the Net was now actually easier to access, even though everybody who used a Cox e-mail address or had a Cox-hosted web site would need to make some adjustments. The kit spent most of its glossy energies on those issues rather than simple connectivity.
Worse, the kits failed to explain was that in many cases the cable modem would need to be turned off for up to several hours, so that its semi-volatile memory would forget the old settings while the customer's account was being "reprovisioned."
Worst of all, the kit came with a CD that installs new copies of Microsoft Internet Explorer and Outlook Express (on PCs and Macs -- forget about Linux) and explains that e-mail addresses and web sites can only be changed if the user runs special scripts initiated by unique codes that come with the kit and can only be implemented using IE5 on Windows.
The net effect was to confound every customer, regardless of platform or technical competence. It also did nothing to improve popular understanding of what the Net is all about. A major lost opportunity.
I still believe that conceiving the Net as a distribution system will ultimately fail, regardless of how much legal and market leverage the AOLs, SBCs and RIAAs of the exert to maintain it. In the long run the concept will simply become irrelevant.
But we can hasten its demise by explaining, as often and as forcefully as we can, the difference between terminal distribution-oriented business models and ubiquitous commodity infrastructures that are good for every kind of business. Or, as Bob puts it:
Once we see that connectivity is the basic resource and that telephony and television are simply applications built on connectivity we can seize the opportunity to replace complex regulation with the power of the marketplace.
Doc Searls is Senior Editor of Linux Journal.
Doc Searls is Senior Editor of Linux Journal
|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|
|Non-Linux FOSS: Seashore||May 10, 2013|
- Dynamic DNS—an Object Lesson in Problem Solving
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Using Salt Stack and Vagrant for Drupal Development
- New Products
- A Topic for Discussion - Open Source Feature-Richness?
- Drupal Is a Framework: Why Everyone Needs to Understand This
- Validate an E-Mail Address with PHP, the Right Way
- RSS Feeds
- Readers' Choice Awards
- Tech Tip: Really Simple HTTP Server with Python
- BASH script to log IPs on public web server
52 min 12 sec ago
4 hours 28 min ago
- Reply to comment | Linux Journal
5 hours 22 sec ago
- All the articles you talked
7 hours 23 min ago
- All the articles you talked
7 hours 27 min ago
- All the articles you talked
7 hours 28 min ago
11 hours 53 min ago
- Keeping track of IP address
13 hours 44 min ago
- Roll your own dynamic dns
18 hours 57 min ago
- Please correct the URL for Salt Stack's web site
22 hours 9 min 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?