Slashdot Mirror
Wired on the 'Breakup' of Distributed.net
binarydreams writes "Wired News has a pretty good article about Adam Beberg leaving Distributed.net. It provides more details about the disparate goals of Beberg and Distributed. Provides much of the background lacking in the two emails sent to the distributed announce list. "
The project itself is slowly dying.. Are they going to continue cracking RC5 with nothing new for ANOTHER 5 years? I joined with the promise that the project would take on more problems, to be expandable with the arrival of the V3 clients.. What are they intending on doing in the future?
-- I'm the root of all that's evil, but you can call me cookie..
I apologize for any perceived vagueness in the original announcment from distributed.net. We all basically felt that a broad and more general treatment of the issue was the most appropriate tack to take in the initial announcement. It was very important to us to ensure that people realize that this divergance was amicable, friendly, and desired by all parties. To dwell too much on the specifics of the difference of opinion might be misinterpreted as drawing lines in the sand or bashing.
While the actual issues are simple, they are fundamental; the difference of opinion between Adam and distributed.net is more related to development philosophies than it is to our respective visions. We are both still striving towards a next-generation, general purpose distributed computing protocol and implementation.
Adam sees Cosm as very much his personal invention, and he wants to see his vision implemented. We are more interested in exploring in the direction of a more open development environment. Trying to co-mingle those two philosophies was difficult and ultimately damaging to the organization.
Open-source is the holy grail of distributed computing and is arguably the single greatest task lying ahead of us. It also makes sense for this task to be the first we tackle as we move forward.
I would say that it is by far the most compelling and desirable goal we've laid out.
The move from our sub-optimal "security through obscurity" model (which was never intended to last as long as it has) to an open source model is not really an issue of just slapping on some "extra security", however. The concept of trusting work performed by untrusted code is the sticky-wicket of distributed computing. Zero-Knowledge Proofs, as treated to date, don't entirely address the issue in a compelling and aesthetic manner.
I'm not sure anyone knows quite the best way to approach this problem, and it is our hope that by encouraging discourse and open development we can, as a group, hone in on the most appropriate choice for our various applications.
Believe me, though, when I tell you not to read anything at all into the fact that we have been closed source to date. This does not imply any loyalty to closed-source or closed development. We are all very committed to solving this dilemma and we always have been.
It has been very difficult for distributed.net, as an entity, to agree upon and convey a common and compelling focus when internally this was not the case. Unfortunately, much of our energy lately has been spent trying to reconcile two distinct and at-odds design philosophies.
Ultimately we all decided that it was no longer prudent to try to come to an agreement and thus the decision followed that Adam and distributed.net should each proceed in their own desired direction.
On a technology front, distributed.net's goals are to utilize a truly open development environment to develop the next generation of distributed computing client and server. We are committed to moving our codebase beyond the ultimately indefensible closed-source model and to an open source codebase. Not open implementation, but truly open development. distributed.net needs to begin living up to its name and distributing not only our client base but our brain trust as well.
On an organizational front, our goals are unchanged. We seek to be the central standard for distributed computing. To continue to grow exponentially and expose as many people as possible to the concept of distributed computing and encourage them to become involved in the group. We wish to be the bar against which all distributed computing efforts are
compared.
SETI@home in the past rejected an offer of help from distributed.net - they were offering to make a core for SETI so that DNET supporters could participate. SETI was not interested for whatever reason, so somehow I kind of doubt that SETI will be interested in Cosm.
Besides, it seems to me SETI's more interested in riding the Paramount/Sun/etc money train so they can keep their funding. Kinda sad, really.
Unlike what the Wired article was looking for, there was no internal conflict that led to the breakup.
It was simply a matter that Cosm and myself have been headed one way, and others in distributed.net want to head another. So we parted ways. It was the Best option for Cosm and distributed.net both.
My goals since long ago have been to build a general purpose architecture for large scale distributed computing. A system that will allow projects all over the world to get done, while maintaining security and data integrity. That is what Cosm is.
All the Cosm information that's available is at http://www.mithral.com/~beberg/cosm/ and more is going up every day.
As has always been the plan, Cosm source will be public, both for development reasons, and security/trust issues. This is due to happen in a few more days (May 1), but could not happen until a design and framework were available to guide the code. A lot of very tough problems have had to be solved during that process. And now it's time to make Phase 1 happen.
- Adam L. Beberg - The Cosm Project - http://www.mithral.com/
2 pts:
1)
Ernst Mayr's belief that SETI is pointless is questionable. There are hundreds of BILLIONS of stars in a galaxy, and hundreds of BILLIONS of galaxies (probably more galaxies in the universe than stars in a galaxy). So there are ~10^12 stars. Even if there are only habitable planets on a tiny fraction of these, and life on a tiny fraction of these, an empty universe is a far fetched thing. Besides, the sun is rather young compared to other stars, so there are many star systems with huge (3 billion year) head starts on getting intelligent life.
Also, SETI isn't necessarily looking for a message. It may be more likely that we pick up the equivilent of a TV broadcast. Recieving a purposely sent signal may be unlikely, but it ONLY took us ~6000 yrs. to go from recording our history (civ. in Japan) to radio. Ever since the first TV broadcast we've been spewing out carrier waves. Coherent signals. So, it's pretty darn likely that there is a signal out there waiting for us to hear.
2)
There isn't much you can do at this time with free processer. There's cracking codes, looking for primes, and SETI. Rendering is out because nobody has set up the proper organization yet (I think).
It would be a better use of tax dollars to give vaccinations or something than to look for alien life. But free computer cycles can't be used for much in the way of socially usefull things. So SETI@home is a good idea. Anyway, alien life is interesting (to the average luser). Mersenne primes are not. SETI@home will get the masses used to the idea of distributed computing. Until that happens, it won't be practically useful.
Besides, I'd give processer time to both.
(Sorry for the LONG comment)
Sounds to me like it wants to be more of an open project type of distributed computing, with the protocol being the backend to handle the passing out of code/data..
Sounds feasible, but with problems.
Say we want to make a program which can work like distributed.net, but with an arbitrary program. The program would still have to be highly parallel, but most computer intensive programs are. We would need:
a) a protocol that can pass the bits of code out to the clients
b) a protocol that can pass data back and forth between the clients
c) a client that can run on several platforms, and execute the code given to it
d) a whole bunch of clients
This is surely possible, but several issues come up. The first one being, why the hell would I run a program on my computer that works for someone else? Where's my compensation?
The easy answer to this is you setup a pay scale. Your main computing center accepts jobs to be put into the system. They get paid for this. They subtract a small (or not so small) fee for their overhead, and the rest gets distributed to the people whose computers are doing all this work. Of course, not every computer is equal, so you have to pay according to work done. This is best accomplished on the servers, by tracking, for example, number of completed blocks received.
Also security becomes a big issue. If this server is sending my computer code to execute, what if that server gets hacked, and the code replaces by malicious (sp?) code? People executing random code on other's machines need to take this into account. Perhaps on client side, you execute your code inside a very well protected environment. Heck, use a stripped down Java VM, or something similar.
Also security on the pay scale side. What's to keep someone from hacking your protocol to send bad completed blocks back, and then get paid for them? If you could check to see that each block was correct, then you wouldn't have to send out each block to be done, would you? So some form of authentication is needed, along with a system of tracking each block done by whom?
Anyway, it's a good idea. I'd particpate in it, if it's done correctly.
- Give a man a fire and he's warm for a day, but set him on fire and he's warm for the rest of his life.