Original and Instant
At the first break on the first day of Jabbercon, four members of the development team made their way over to say hi. The first to arrive was Eliot Landrum who told me how much he liked the new Linux Journal design changes, for which I thanked him. Then Julian Missig, Justin Mecham and Schuyler Heath followed. They looked like a high-school chess team, but by now I've learned never to let looks deceive me. These guys were short in the tooth but long on programming skills, and they helped make Jabber something worthy of its first conference.
I asked them how they described Jabber to people who never heard of it before. “Distributed open-source instant messaging”, Eliot said. The others kind of nodded along, but their expressions said “whatever”. Which is kind of true, too.
In fact, they were far more curious than opinionated. Eliot said something like, “We've been sending out these messages into space, and we want to see what bounces back from other civilizations.” Among the civilizations he's talking about are businesses excited about what he and his cohorts have created. On the attendee list I saw emissaries from Intel, Earthlink, Disney, PeoplePC, Swiscom and a bunch of less familiar companies, some of which were reportedly doing some very interesting stuff. One with a lot of buzz was Nuance, which lets you use your cell phone as an IM (instant-messaging) client in a real-time, speech-to-text-and-back-again conversation over a Jabber transport. Another was Oracom, which uses Jabber for worldwide network management in real time.
Both of these are examples are of what we might call “embedded IM” if that label didn't seem to exclude XML routing and presence management—to name a couple other virtues that make Jabber easily embeddable and so far outside the AOL-defined meaning of IM that it begs a whole new label.
“Platform” isn't it. As with embedded Linux, Jabber is deeply structural, yet too dedicated to arcane purposes to justify the “platform” label, which now more legitimately belongs to the Net than to any operating system. Jabber's job is not to make its own presence known (or in dot-com parlance, to “brand” itself) but to add presence and data routing (by XML) to the growing roster of fundamental and ubiquitous internet services.
So I look at these guys and ask a rude question: “How old are you?” “Nineteen”, says one. “Seventeen”, says another. “Nineteen.” “Twenty-one.”
“How old is Jeremie?” I ask. Jeremie Miller is the Linus of Jabber, the programmer whose itch Jabber first scratched. “He has two kids. What is he, 26?” “Twenty-four, I think.”
I realize that I'm older than any three of them put together (giving new meaning to the title senior editor), but I don't bring it up. Nor do I bring up the observation that Jabber is, like its creators, still much closer to ground zero than to whatever it ultimately will become. In their “look, we can do this” quality, the presentations I saw at the show sent my mind back 20 years to when the PC was brand new, and everything you could do with it was novel and fun, yet still just prototypes for stuff that ultimately would become indispensable.
Like approximately everybody, I knew nothing about Jabber in early 1999. That was when my friend Perry Evans (who is perhaps best known as the founder of MapQuest) told me about it and wondered what I thought. He said Jabber was the quiet brainchild of a quiet 22-year-old programmer who hacked in the quiet farm country of Iowa. As instant messaging went, it had the same relation to AOL's system as the Internet had to, well, AOL. It was open source. It was XML. It let anybody deploy their own IM server just like they deploy an open-source web or mail server. And, because it was essentially an XML router, it had all kinds of interesting implications for just about everything.
Perry wanted to pump my brain for some thinking about how to support Jabber open-source development with some kind of business that would make money by selling Jabber-based products and services. I had ideas, but I knew Eric Raymond would have a lot more, so I invited him to join the conversation. Eventually Perry and his company, Webb Interactive Services, created Jabber, Inc., and I joined its advisory board (now rebranded the Open Board), as did Eric and other familiar folks from the Open Source community.
So here I was at Jabbercon, wearing three hats: Linux Journal editor, Jabber, Inc. Open Board member and speaker/panelist. When it came time to deliver the goods in that third capacity, I had to admit that after more than two years of trying to figure it out, nobody had the surefire formula for dealing with what Craig Burton, speaking at the same conference, called the “Infrastructure Paradox”, which is “balancing the business of generating shareholder value while fostering global ubiquity.”
But, there was some hope in his next remarks: “The market is constantly in the process of correcting itself toward construction modularity. This correction process causes alignment in architecture design and redistribution of competency.” Needless to say, this has been the story of Linux's success, especially as an embedded OS.
But it seemed to me that “redistribution of competency” is an overly commodified way of describing what was really going on here. Instead we had both obsoleting of irrelevance and origination of competency. What these guys were making with Jabber was not only highly original stuff, but stuff that was good for a lot more origination as well. Could it be that this was because these guys were not too far from having been originated themselves?
I don't think it's a coincidence that Linus Torvalds and Jeremie Miller were both around 21 when they introduced their inventions to the world, or that they've made it possible for the rest of us to do the maximum range of original work. The fact that both Linux and Jabber are still so young only makes them that much more indispensable.
Doc Searls is senior editor of Linux Journal and coauthor of The Cluetrain Manifesto. His next book will be Real Markets: What They Are and How They Work.
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!
- Stunnel Security for Oracle
- SourceClear Open
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Google's SwiftShader Released
- Parsing an RSS News Feed with a Bash Script
- Non-Linux FOSS: Caffeine!
- SuperTuxKart 0.9.2 Released
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