Betting on Darwin
Doc: You've been trying to establish an object model built around IIOP (Internet Inter-ORB Protocol) and CORBA (Common Object Request Broker Architecture), versus Microsoft's DCOM (Distributed Common Object Model). Does this Open Source release play in that at all?
Marc: Good question. Tom, we took the ORB (Object Request Broker) out, didn't we?
Tom: I don't think it's there.
Marc: That's interesting. [We] made the client ORB-free in source form.
Tom: It's going to have an ORB; I can't tell you exactly when. I don't think the world is going to tolerate a vacuum in this space for very long. I've seen a few proposals. All the existing popular options have some kind of fatal flaw in the eyes of part of the community. The DCOM guys have a problem with this part of an ORB. And this CORBA group has a fundamental problem with the portability or interoperability of some part of DCOM. There are just wave after wave of these concerns. We've had arguments within Netscape about the best way to address the question. I'm looking for Darwin taking over on this one, too. I think it might be a spirited debate, and educational for me. I am not an objects guy.
Doc: I was talking to Phil Hughes about this and he said the same thing. But he added that it all depends on your generation—when you grew up.
Tom: It's true.
Doc: He said, if you go to the schools now, everybody's talking objects. Maybe not so for the older guys.
Tom: Some of those older guys have evolved into objects people. Their arguments are very interesting. I follow them, but I can't generate them. In any case, I think it's going to be interesting to get this out in the open.
Marc: I bet we'll have native IIOP built into Mozilla in source code form within a year. From somewhere.
Doc: Meanwhile, there seems to be faith that the world is going to be made of objects, and there will be an enormous conversation in objects between clients and servers all over the world. I don't know to what extent evolution toward that state is constrained by the presence of two rival object models.
Marc: As an issue, it's not pragmatically useful or important to enough people yet. The results may be what you describe, but the object people get confused between the way the world's going to look in N years versus what it's actually going to take for interest to pick up and carry us there. This is why it was so hard to time the adoption of LANs. In retrospect, it took time for all this technology to connect before it made more sense to print over the LAN as opposed to carrying floppy disks. To get to the current state of the Internet, we had to get technology to a point where folks wanted e-mail accounts in order to write to their kids in college. I think this applies to programmers too. What's the trip-over point where all of a sudden it really matters? Personally, I think it's going to happen when people build more sophisticated multi-tier applications. Then they're going to need smarter communication between clients and servers than they're able to get today. And they're already going to be developing a lot of their logic on the server in the form of objects because they're using C++ or Java, and also off the client. And so, they're just naturally going to start to interconnect those two.
Doc: Directory service is going to play in a really huge way here. You've got a directory server.
Marc: A damn good one.
Doc: That seems to be optimized for this. Would you tweak it to match what's going on in the outside world? Let's say you put the ORB in the browser, watch what happens, see who's trafficking in objects, how it looks and who needs a directory.
Marc: Absolutely. A lot of what we do in the servers will be influenced by what happens with Mozilla. It's sort of always been that way. Fundamentally, there's a chicken and egg problem with some of these things that involve all kinds of servers, and it usually requires you to get some amount of user action or adoption going on before lots of stuff starts to happen on the server. I'll bet that's exactly what's going to happen in this case.
Doc: I like your faith. But your critics have said “It's a desperate move, and they didn't have any other choice.”
Tom: That's driving me crazy. Any business decision is going to look vague when the costs and risks versus the opportunities and benefits are highly balanced. The teeter-totter teeters. In this case, the cost of releasing the source to the Navigator plummeted in the last nine months or so. Now, it's a no-brainer—time to pursue a new opportunity.
Marc: The flip-over point was when we made the binaries free. After that, releasing the source made perfect sense.
Tom: The benefits and opportunities have always been strong. It's just that the costs have been high. Well, they have not always been strong. I have to be fair. In 1994, there weren't many developers out there who “got” the Web—whose heads operated in that space. And if you invited everybody to come and play, the signal-to-noise ratio would have been zero. Since then everybody has come to know about the Web, and they have attitude and interest and ideas, so for some time the opportunities and benefits have been on the strong side. But when the costs plummeted, then suddenly it was a lot easier decision to make, regardless.
Marc: Those statements usually come from people who are typically not involved in businesses. Or at least not businesses of scope. There's a natural decision-making process businesses go through to try to maximize their economic opportunity.
Doc: I liked the way Jim Barksdale put it when he said, “We had to get revenues low enough, so we could make this choice.”
Marc: Right! We had to walk it all the way down to zero. Along the way, we used that revenue to subsidize all these other products and services that now generate revenue.
Doc: Change goes on all the time anyway. All products have a life. Either they change completely in order to live, or they die.
Doc: That's true of Windows, of browsers, of all kinds of things.
Marc: Which is why it's ridiculous to criticize a company for changing.
Tom: The criticism is, we're in power and we have competitors, so we've got to be desperate to give all this power to our competitors.
Marc: To some people it's “Aw, they're desperate.” And it's obvious they haven't even thought it through any more than that. It's a pointless comment. Jim Barksdale abbreviates this to “They haven't ever run a hot dog stand. What do they know?”
Doc: The problem with the press is that when you're running a sportscast, you have to fill the air with sounds of competition even when there's nothing going on.
Tom: You're really right about them using war terminology, using that chest of war words, and when things don't fit that model, the brains break. The stunning thing is their unwillingness to put that box away and break out a new box.
Marc: It's especially interesting when you think about it, because there are so many different sources of media now—so many different voices out there, striving for unique coverage and unique angles. You've got an inherent unwillingness by a large number of them to actually do anything unique.
Doc: Part of it is time pressure: you have to say something. Another is the story principle. Stories are the fundamental unit of consciousness. Conflict is interesting, and most stories are about conflict. No story starts with “And they lived happily ever after.” What keeps them turning pages is the conflict that's going on, and it will still be going on after they turn the page. That is inherently interesting to human beings. The Great Harmony is not interesting. A bunch of people hacking on something for the pure fun of it and for peer review is not as interesting to the press as the “Great Browser War”.
Doc: Eric Raymond told me today that you're not a hacker unless somebody else says you're a hacker.
Marc: That's true. He's absolutely right.
Doc: There is also a peerage among the Dilberts of the world that is invisible to those further up the corporate hierarchy.
Marc: That's true.
Doc: So there is all this interesting stuff going on, but it doesn't involve conflict so it isn't that interesting to the press.
Marc: Now there are more people in the technologist community than there ever have been. More people are comfortable with technology now at every level than there were five to ten years ago—just a huge number more.
Doc: Anything else you want to add before we wrap this up?
Marc: I think over the next six months we'll have an explosion of activity. What pops out of this new system will be interesting. You can view it as an amazingly complex system or organism or computational device on a large scale, with its own set of rules and organizing principles. Stuff is bound to pop out. By definition, what pops out will be the right set of stuff. It will be self-fulfilling.
Doc: This brings to mind John Seemly Brown's matrix, where he puts social computing in context. He says there are some things that only we know. They emerge in the social space, rather than the personal. And most of the shared knowledge is tacit rather than explicit. Tapping into this tacit dimension is what you have in mind, I think.
Tom: Domestically, among the people here at Netscape, I've been explicit, saying, “Look, I'm not going to explain to the Open Source world how open source works. Build it; they will come.” If they need to be sold, they're too much work for me anyway. As long as I believe there is a large community out there—that will come, based on tacit communication—I'm in business. And the rest of the people can learn how this thing works. For some people, however, I have to be clear: “I'm expecting this behavior.” This allowed Mozilla to say, “We're just kind of doing this,” and expect Open Source behavior to run with it. Yeah, absolutely. At the tacit level, the Open Source people totally get what's going on.
Doc: In a way, you're saying “We have built it, now they'll come and rebuild it.”
Tom: Oh yeah. We build the place where source lives, and give them an opportunity to get in there and get their fingers dirty, and no one will be able to keep them away.
Doc: Like a free Home Depot for developers.
Marc: Right. We've got a few things we think we can stock it with on top of Mozilla. I'd like to see what the community does with Electrical Fire.
Tom: The list of things like Electrical Fire is about seven, eight, nine, ten items long, all of which are majorly interesting. So, we've got some stuff. We can set some fires.
Doc Searls is Senior Editor of Linux Journal
Practical Task Scheduling Deployment
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.View Now!
|The Firebird Project's Firebird Relational Database||Jul 29, 2016|
|Stunnel Security for Oracle||Jul 28, 2016|
|SUSE LLC's SUSE Manager||Jul 21, 2016|
|My +1 Sword of Productivity||Jul 20, 2016|
|Non-Linux FOSS: Caffeine!||Jul 19, 2016|
|Murat Yener and Onur Dundar's Expert Android Studio (Wrox)||Jul 18, 2016|
- The Firebird Project's Firebird Relational Database
- Stunnel Security for Oracle
- My +1 Sword of Productivity
- SUSE LLC's SUSE Manager
- Non-Linux FOSS: Caffeine!
- Managing Linux Using Puppet
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Parsing an RSS News Feed with a Bash Script
- Google's SwiftShader Released
- 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