Instead we have something that is faster-than-dialup, and faster-than-it-used-to-be; but is not The Net. Instead it is the part of the Net that's left in a pipe that's optimized for television, for one-way few-to-many "content delivery" and for locking users into client roles, while servers labor somewhere else.
I just had FTTH (fiber to the home) installed. And, while it's way cool in some ways, it's also uncool in the way it prevents far more business than it generates for itself. It would be great if the carriers made it easy for businesses to grow on the Net, and then suppoted those businesses with services that helped those businesses thrive and grow. But the carriers would rather serve "content" to mass quantities of "consumers" while chaging prohibitive prices for "business-class" services. Hey, it's a mass media mentality, and they have every right to it.
With the rise in network-intensive gaming, of bittorrent traffic, of the need to share big files (e.g. photos and videos), heavy users of the Net will inevitably chafe loudly at legacy asymmetries in the Net subset provided by carriers, at least here in the U.S.
So some of us (mostly on email list backchannels) have been thinking about how we need to rejigger this thing somehow. Either we work with the carriers, or we work around them.
I favor the latter, mostly because the flywheels in carrier methods and mentalities are too large and biassed to spin forever right where they are. They'll move eventually; but it will take competition to do it. (Let's leave "net neutrality" and other legislative options out of this.) That's what I'm suggesting here.
Among the workarounds I've long fantasized about is what some of us call "fenceline" build-out, from house to house and apartment to apartment, finding their way to aggregated buying power sufficient to pay for connections along poles to backbones, where the cost of connectivity could be split enough ways to become affordable to everybody.
I don't think that will happen without some business selling the service that does the connecting and the support after the connecting is done. That business would provide pure Net connectivity, rather than the customary crippled sort (e.g. port 80 and 25 blockages) we get from the carriers. it would provide that connectivity over cabling (preferably fiber), wireless (something more sturdy than wi-fi) or both. Let's call that business a 'netco' — something that works as an alternative to the telco and the cableco.
To succeed the netco (or the netco industry and its companions) would need to characterize what they provide as pure internet, and what the cablecos and telcos provide as a crippled sort. You know how the anti-abortion people characterized their cause as "right to life"? Changed the whole game. (Not saying that move was right or wrong, just that it was effective. It was galvanaizing.)
Anyway, I'm thinking out loud here about this because the Linux movement grew to a large degree around Web server deployment. As the Net grew, Linux grew. And vice versa. In fact, the Net and Linux grew to the point where, frankly, we won.
That leaves us at a long Now What? moment. Too long, in fact. Linux search queries are down. Apache market share is falling. We need a fresh issue to drive the Linux conversation into a new old cause: enabling true freedom for connected users. Is this that cause?
Here are some questions...
1) Can we see a new business a netco be built to work around carriers that insist on providing only crippled Internet? (How? When? By whom?)
2) What would be some clever characterizations of pure uncrippled Internet?
There are models for such a company, by the way. One is Indienet.dk in Denmark, which I wrote about in the January 2007 issue of Linux Journal. Denmark is different, yes; but it's good to know a model exists.
Meanwhile, think about what will happen when ordinary customers those consumers who are now also producers get fed up with assymetry and Net crippling here in North America. It will happen, and when it does there will be a lot of business in filling demand for uncrippled connectivity.
Or so it seems to me. How about you?
Suggested reading: Everything by Bob Frankston.
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
1 hour 25 min ago
5 hours 1 min ago
- Reply to comment | Linux Journal
5 hours 33 min ago
- All the articles you talked
7 hours 57 min ago
- All the articles you talked
8 hours 40 sec ago
- All the articles you talked
8 hours 2 min ago
12 hours 26 min ago
- Keeping track of IP address
14 hours 17 min ago
- Roll your own dynamic dns
19 hours 31 min ago
- Please correct the URL for Salt Stack's web site
22 hours 42 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
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?