Dependence vs. Independence. That's the choice.
The matter of Scoble vs. Facebook is not about either. It's about the deeper choice we face in all the relationships we choose on the Net: the choice between dependence and independence.
There will always be dependencies. Working out dependencies is one of the oldest hats in software. But there's a difference between the technical and the personal. It's one thing to make sure Apache's working with Linux and quite another to make sure our social network's working with Facebook.
What matters about Scoble's experience with Facebook (and vice versa) isn't What Happened, or whether either party is being smart or dumb or good or evil. What matters is that Scoble, like millions of others, has put part of his life and those of others to which he is socially connected in a position of dependency on Facebook.
The arguments we should be having are not about how to make that dependency work, but how to make Scoble and the rest of us as independent as possible from every large private concern on the Net, no matter how public the good they produce may be.
Independence is a value that has run like a river, not just through the Open Source movement, but through the Independent Developer movement, the Free Software movement, and through hacker culture for the duration. Its origins are in value systems that recognize the transcendent virtues of personal freedom. Including the freedom of assembly that results in social groupings especially those that are inherently elective. To be free is to opt in, not just out.
Scoble should be able to take his personal data, his social data, and his business, anywhere he likes. Our ability to associate and communicate and work out "social networking" should be independent of Facebook, LinkedIn, or any company's walled garden.
The problem is, we have not framed what we want, and what we invent, sufficiently in terms of independence rather than dependence. We have not started with ourselves and worked outward and otherward from there. Instead we've waited for the Facebooks and Orkuts and Friendsters of the world to prototype our "social networks" for us. Which is fine, as far as it goes. But that's like letting AT&T or Apple some other company contintue to define operating systems for us. With BSD and Linux we stopped doing that, and started making for ourselves.
We need to do the same with social networking.
"Choice", Neo said to the Architect. "The problem is choice".
We can choose to serve as batteries in the Matrix that is Facebook (and every other "social network" that serves as a world-like habitat). Or we can choose to be free. That's it.
[Later...] Speaking of indepencence, here's a bonus link I found by putting "independence" in the Firefox location bar and hitting "enter".
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!
- Paranoid Penguin - Building a Secure Squid Web Proxy, Part IV
- SUSE LLC's SUSE Manager
- Google's SwiftShader Released
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Managing Linux Using Puppet
- My +1 Sword of Productivity
- Non-Linux FOSS: Caffeine!
- SuperTuxKart 0.9.2 Released
- Parsing an RSS News Feed with a Bash Script
- Doing for User Space What We Did for Kernel Space
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