Cycles and Simplicities
Om Malik calls this "dave winer's best post of the year". I can't recall a better one, but ranking isn't what matters here. What matters is perspective and experience, and Dave has plenty of both. What he says is,
We're now reaching the end of a cycle, we're seeing feature wars. That's what's going on between Facebook and Google, both perfectly timing the rollouts of their developer proposition to coincide with the others' -- on the very same day! I don't even have to look at them and I am sure that they're too complicated. Because I've been around this loop so many times. The solution to the problem these guys are supposedly working on won't come in this generation, it can only come when people start over. They are too mired in the complexities of the past to solve this one. Both companies are getting ready to shrink. It's the last gasp of this generation of technology.
It's strange to think of Google and Facebook as old, but Dave's right. They are. Search is old. Advertising is old. Online social communities in a big walled garden is old. You can look at it this way: Google fixed Lycos's problem. (And Infoseek's, and Hotbot's, and AltaVista's.) And then it fixed the yellow pages' and classified advertising's problems. And it used the proceeds from both to start fixing many other problems too. Credit where due -- and there's lots of appreciation to spread in their direction. Meanwhile, Facebook fixed AOL's and Compuserve's problem. (I know the latter was dead. But for them that's a problem too.)
But advertising itself has a problem. So do walled gardens. Google and Facebook are in poor positions to fix those, because they have to defend their old positions. They have Innovator's Dilemma. Their businesses have huge underbellies, ripe for disruption. And that disruption won't come from them. Nor are they in the best position to ride the disruptive tide and spread it in all directions.
Railroads were in a lousy position to run the automobile business. But automobiles solved the problem of mechanized rail-less tranport. The "horseless carriage" never needed a horse.
Phone and cable companies today are in a lousy position to run the Internet business. Telephony and Cable TV are railroads and steamships. They "carry" the Net as a "service", but the Net isn't essentially a service. It's just a way to connect things. Connectivity is what matters. Not "broadband", much as it appeals within the context of phone and cable companies' limited offerings and imaginations. Who will imagine what can be done when connectivity is freed up? Phone and cable companies? I'd rather bet on the people leaving those companies.
Here's a question: What comes after automobiles? That's another huge underbelly, as we've been reminded by hearings in Congress over the last few days.
Where does Linux fit into all this? Simple: as abundant building material just like the rest of the FOSS portfolio, nearly all of which is built to serve functional purposes, more than commercial ones. Thanks to the Because Effect (you make more money because of it than with it), FOSS building materials commodities all, but so free there isn't a commodities market for them prove very handy for building an endless variety of stuff.
Anyway, the one place I differ with Dave (and perhaps only slightly) is in expecting young people alone to do the disrupting. That's because I'm working on disruption myself, with a growing community of hackers, businessfolk and other pioneers, of many ages. And learning new lessons every day.
This is the business our work will most disrupt, by the way. Like the railroads, it won't fail. In fact, I think we'll help them succeed beyond anything they've experienced so far in their (I'm guessing) $10 billion/year lives. But I dunno. We'll see.
What I learned from Dave this morning is that we've got to be simple. That's the key.
Doc Searls is Senior Editor of Linux Journal
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.
Sponsored by AMD
If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.
Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.
Sponsored by ActiveState
| Non-Linux FOSS: libnotify, OS X Style | Jun 18, 2013 |
| Containers—Not Virtual Machines—Are the Future Cloud | Jun 17, 2013 |
| Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer | Jun 12, 2013 |
| Weechat, Irssi's Little Brother | Jun 11, 2013 |
| One Tail Just Isn't Enough | Jun 07, 2013 |
| Introduction to MapReduce with Hadoop on Linux | Jun 05, 2013 |
- Containers—Not Virtual Machines—Are the Future Cloud
- Non-Linux FOSS: libnotify, OS X Style
- Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer
- Linux Systems Administrator
- Validate an E-Mail Address with PHP, the Right Way
- Introduction to MapReduce with Hadoop on Linux
- RSS Feeds
- Weechat, Irssi's Little Brother
- New Products
- Developer Poll
- Reply to comment | Linux Journal
2 min 22 sec ago - Reply to comment | Linux Journal
47 min 37 sec ago - Didn't read
57 min 57 sec ago - Reply to comment | Linux Journal
1 hour 2 min ago - Poul-Henning Kamp: welcome to
3 hours 13 min ago - This has already been done
3 hours 14 min ago - Reply to comment | Linux Journal
3 hours 59 min ago - Welcome to 1998
4 hours 47 min ago - notifier shortcomings
5 hours 11 min ago - heroku?
6 hours 48 min ago
Featured Jobs
| Linux Systems Administrator | Houston and Austin, Texas | Host Gator |
| Senior Perl Developer | Austin, Texas | Host Gator |
| Technical Support Rep | Houston and Austin, Texas | Host Gator |
| UX Designer | Austin, Texas | Host Gator |
| Web & UI Developer (JavaScript & j Query) | Austin, Texas | Host Gator |
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?



Comments
thanks
hey friend i read you every time for learning english so thank you
Google Kayıt
what is google kayıt
im disaggre!
google - is elementary evil!
-----
get you free ringtones here
[QUOTE]In fact what happened
[QUOTE]In fact what happened was we threw away a simple, efficient system and replaced it with a complex, hugely redundant, ridiculously expensive and grossly inefficient infrastructure that is now falling apart around us because we simply cannot afford to subsidize it any longer.[/QUOTE]
I'll assume you're talking about automobiles v/s rail? I'd like to know exactly how are private automobiles subsidised when almost every aspect of owning or running them is taxed? And how exactly is it inefficient? If one can reach one's destination faster and cheaper than rail by using one's own private automobile, what exact metrics do you use to reach at this conclusion?
Presumably you're from the United States of America. Which might explain why you're unaware of other places where rail is the grossly inefficient, highly subsidised, and impermeably complex infrastructure.
I'm not arguing that private automobiles are the solution to the worlds transport woes. What I'm doing is simply stating that public, shared transportation has it's limitations and has an equal if not worse record than private transportation.
You've shown a fundamental misunderstanding of communications
The telephone company wasn't always the telephone company. That's why AT&T is American Telephone & Telegraph. The phone company has always understood the product is connectivity, the services being connected are are irrelevent. That's why they protected their wildly lucrative private wire services and made their shared path services look like private wire (ISDN and others).
The cable company seem closer to your view, but I've never been in that business. I don't know and I'm not afraaid to say so.
The cluelesstrain manifesto
But automobiles solved the problem of mechanized rail-less tranport.
"Solved"? That's an interesting choice of words. In fact what happened was we threw away a simple, efficient system and replaced it with a complex, hugely redundant, ridiculously expensive and grossly inefficient infrastructure that is now falling apart around us because we simply cannot afford to subsidize it any longer. Unfortunately it appears to me that something similar is happening in computer technology these days. Things are being made far more complicated than they need to be, and that complexity is touted as something to be somehow proud of.
The fact is, "innovation" on top of bad ideas is still bad, and "innovation" on top of bad ideas at a higher rate of speed doesn't make them any better.
I'll take an IBM or Microsoft investing in pure fundamental research and development over the "fixed problems" of Facebook or Yahoo any day. Real problems are solved over the course of decades, not months or years.
"...What comes after
"...What comes after automobiles? "
If the big three get a bailout, and are not forced to restructure as a condition of getting all that cash, the floodgates will open like we've never seen. I just read the big three television networks are waiting to see what happens and will all claim the standard "We're too big to fail" fear mongering line to get their bail out money.
Then all the big newspapers, the credit card companies, the major retailers, on and on...