Slashdot Log In
Apple Plans To Release Rendezvous As Open Source
Posted by
timothy
on Thu Aug 29, 2002 08:39 PM
from the so-it-won't-be-a-secret-rendezvous dept.
from the so-it-won't-be-a-secret-rendezvous dept.
Snuffub writes "According to MacCentral, Apple announced during an interview today that they would be releasing Rendezvous, their implementation of the zeroconf standard, under an open source license. I can't see this as being anything but great news for everyone involved -- the community gets a mature implementation of an emerging technology, and Apple benefits as more devices are created to support Rendezvous. For everyone interested, you'll be able to download the source from Apple's site in a couple weeks." uglyhead69 adds: "The article is light on details and doesn't mention what license will be used, but it's probably safe to assume that it's the APSL."
This discussion has been archived.
No new comments can be posted.
Apple Plans To Release Rendezvous As Open Source
|
Log In/Create an Account
| Top
| 348 comments
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
uPnP (Score:4, Insightful)
Make Rendezvous Open Source! (Score:5, Funny)
oh wait. they already have?
Re:Make Rendezvous Open Source! (Score:4, Insightful)
Apple have adopted open standards in just about everything they've done without trying to damage them a la M$ & Kerberos. I've seen plenty of Embrace but absolutely no Extend nor Extinguish. Please point some out ...
They've based their entire OS core on BSD/Mach and then went on to release the sources, including those of the usual services. I just downloaded bootpd a minute ago, BTW.
Cheshire Interview about Rendevous (Score:5, Informative)
w00t! (Score:2, Insightful)
I can see where developers could use this to create thousands of cool applications for little tasks here and there, but what is the advantage outside of this? And how would it help the Rendezvous program grow?
what is it good for? (Score:5, Informative)
Lots of processes running on an array of machines. Say for example you have a data center full of racks of 1U servers, and each one is cranking away on some part of the application code. You have redundant processes scattered around too, so if one machine takes a dive, you want the whole application to stay up and running anyway.
Imagine you're the administrator of this system. How do you tell each little process in the system what IP address and TCP port to use so that every other process in the system knows where to find it?
Without Rendezvous, you have several options-- all of them unappealing. You might start with some kind of application specific configuration file format and a cobbled-together system for distributing such data around to all the hosts in the system. You might instead store such network configuration in some directory server on the network, like DNS or LDAP or some kind of custom front end to some kind of evil database backend.
Either way, you quickly encounter what we veterans like to call "the cache coherency problem," i.e. the information in the directory must be consistent at all times with the actual state of the processes in the system. Whenever processes start, stop, migrate or change their profile, you have to update the directory. Solving this problem with existing technology can be expensive. If you don't solve it, then single-point failure modes proliferate and the system becomes exponentially more difficult to manage the larger it gets.
With Rendezvous, the network itself is the directory service. Since all the little processes in the system are responsible for their own advertisements, there is no cache coherency problem. You don't have to assign addresses and ports to all your processes because the application can simply assign itself a set of abstract service names and discover all the instances of those services on the network with Rendezvous service discovery. No configuration files to keep updated. No dynamic updates to LDAP or DNS servers that might get overloaded, or may not be running or in the right place when they need to be.
Of course, there are alternatives to consider. You might think to use SLP (RFC 2608-2610), which you can download now from www.openslp.org, but strangely... SLP hasn't managed to get much traction in industry. Some say that's because it's too unwieldy to use effectively.
You should compare Rendezvous with OpenSLP and see which one you think is better.
--
Re:what is it good for? (Score:4, Insightful)
You know, it is funny you mention that, because I've been wondering if/when Apple might introduce automatic clustering. The way I understand it, the threading implementation in Darwin is such that threads can not only be transferred between processors, but also between computers too. Rendezvous could let you find all the other computers on the network that will let you run code (in a sandbox, perhaps) and automatically throw threads to them if it will help.
Imagine the Photoshop benchmarks if everything was spread across a rack of XServes!
<DUCKS>
Re:what is it good for? (Score:4, Informative)
Re:what is it good for? (Score:4, Insightful)
> What's wrong with TFTP or NFS or any other network filesystem?
Ever tried to deploy a distributed NFS server? By that I mean: if the primary NFS server goes down, a secondary automatically and transparently serves as a replacement without the NFS client ever having to be redirected? Such things exist. None of them are cheap.
> Then what do you call it? Because using a database sounds like a very good
> way to maintain cache coherency. You would rather state be strewn across the network?
You *already* have state strewn across the network, i.e. the availability states of the various processes that comprise the distributed system. Why try to maintain a cache of that state in a database when the processes can use the network to discover and locate one another directly?
Have you every tried to deploy a replicated database manager? Every transaction on the database must be ACID for this to work with high reliability. (ACID is an acronym, stands for Atomic Consistent Independent and Durable.) Easy to do with a monolithic database manager. Much harder to do with a replicated system. Again, such things exist. None of them are cheap.
My point: distributed systems with more single points of failure provide less reliability than systems with fewer. Rendezvous eliminates an important single point failure mode.
--
Peripherals! (Score:5, Interesting)
Many, many possibilities here.
Smart business move (Score:5, Interesting)
From Apple's point of view, anything that puts Microsoft outside a large pool of functionality is good. Essentially, it's an attempt to conduct a reverse embrace and extend. Take something that was already there, improve it, then give it back.
Apple isn't doing this out of selfless motives. But the fact is, they're doing it. Pretty cool indeed. I've been using 10.2 since the public release, and I'm impressed by Rendezvous, and I can't wait to use it with Linux as well.
My implementation (Score:5, Interesting)
It is in no way a complete implementation, but got me an 'A' grade
Apple didn't really have a choice... (Score:3, Interesting)
Autoconfiguration is Scary (Score:2, Insightful)
It will be nice when they do release some source for this, and make all of the technical documents available. I'd like something to look over about all of this autoconfiguration software.
I mean, am I the only person this scares? Microsoft Outlook had (has) the autoexecute feature that allows virii authors to introduce new and inventive ways to drop rootkits into IIS servers.
Linux has their own little features that have to be guarded against as well. In the basis of security very few of my companies Linux boxes are running any form of FTP. Way too many security alerts, and 90% of the boxes don't need to do file transfers anyway.
Now Apple offers us a really cool and interesting technology that will allow a computer to automatically find a printer. How long before one of these virii authors writes himself an object that allows his PowerBook G4 to introduce itself to a Rendevous network and take control of several machines at once.
Here you go, a really sweet streaming virus.
I for one, hope that there isn't just a way to turn this off, but delete it entirely from a running system. Because as of right now, I'm a little more worried about this than anything new from Redmond about automatically updating my systems.
We use all *NIX on the outside anyway, so that doesn't really apply to any sensitive systems ^_^
discovery != access (Score:4, Informative)
Re:Autoconfiguration is Scary (Score:5, Informative)
This means you don't need to know IP addresses and well known ports, or run port scanners to discover services. If your machine doesn't want to be found by Rendezvous, don't advertise your services with it.
One key thing that makes it smarter than UDDI and the like is that it is service-centric, not device-centric. You don't have to find a machine and try to open special ports to see if it has a webserver or SLP printer or SMTP relay or whatever, instead, you ask for a service that you already know the protocol for, and you find out if any devices that implement it are available.
What I'd like to see... (Score:4, Insightful)
Ping.
iBook, OS 10.2, anyone around?
It'd be like combining Wardriving with those weird "Beep if someone you'll consider hot is nearby." things they were selling in Japan a while ago.
I forsee a hiccup... (Score:4, Interesting)
If Apple uses the APSL [apple.com], then the source code could not be used in Linux [kernel.org]. I'm uncertain if Debian [debian.org] would accept any APSL submissions.
The issue to my mind is that Rendezvous needs popular adoption, and rapid acceptance would be best. If Apple has it in mind to emphasis Windows' network reliablity, then a GPL license would allow the technology to be integrated into Linux, and percolate into FreeBSD via ports. If Apple wants the most rapid adoption a source license can provide, the BSD license would be best, but then Microsoft would be free to embrace & extend.
This is why I root for the GPL in this case. Rendezvous is very cool technology, so Microsoft would either have to ignore it, attack its mindshare, impliment its own version, or bend knee to the GPL. Their own implimentation would be inferior for a time, and due to demand and early deployment, Microsoft would be unfairly judged as having an incompotent implimentation, rather than a primitive one. This would add pressure to move to non-Microsoft platforms. This is good for Apple, because non-Microsoft means Unix, and in many cases, that means MacOS X.
That's aside, however. I'm afraid that an APSL license would cause the source to stagnate except for the eyes of a few Wizards that learn from the implimentation and then develop their own (L)GPLed version.
I think I'm rambling.
Re:I forsee a hiccup... (Score:4, Informative)
The APSL is not compatible with the GPL. This means that you could not link the APSL code directly into GPLed code such as the linux kernel. However, i do not see why the rendezvous code would need to actually be in the kernel. It seems preferable to me that a linux implementation of rendezvous would be just a daemon or something, like inetd or any other number of things are, in which case it would just be a normal program and could be under any license at all.
If for some reason i can't forsee it is somehow necessary for the rendezvous implementation to be in the kernel, it could just be done as a kernel module; there is some dispute [tux.org] as to whether it is okay for linux kernel modules to be non-GPL, but a lot of people, including Linus Tourvalds, interpret the GPL such that OS kernel modules do not have to be GPLed.
I'm uncertain if Debian [debian.org] would accept any APSL submissions.
The GNU foundation doesn't like the APSL. [gnu.org] However, debian is more aligned with OSI [opensource.org] than they are with the GNU foundation. (Correct me if this is incorrect.) Anyway, in order for Debian to include software in its core distribution, that software must fit the Debian Free Software Guidelines [debian.org]. The APSL is on the OSI approved license list [slashdot.org] meaning it fits the DFSG and APSL code could be included in Debian's main codebase, no problem.
Incidentally, Debian does maintain [debian.org] a non-free portion to their distribution, it is just that this portion is not considered "part of the main distribution", and it is not always included with the install discs (it depends on how you obtain your copy of debian, as far as i can tell). But that's irrelivant here because the APSL is OSI certified!
The only reason Apple's decision not to use the GPL would be a problem, as far as i can tell, is that some people don't like to release code under non-GPL licenses, and those people may decide not to contribute to a rendezvous implementation. But other than a few offended people, that's about the extent of the problems the APSL presents.
Problems with GPL and APSL... (Score:4, Insightful)
OTOH, I seem to have picked up a flaw in the GPL, which may be the reason corporations have been slow to take up software released under the GPL. If as you say, proprietary or APSL and other less open licensed software was not permissable within GPL software, many companies would not want to take up that software. The reason being is many companies develop their own private modifications to software. For example, I worked for a time at a well know power company which shall remain nameless. This company had a software suit which they had purchased which provided for the creation and movement of troubleshooting "tickets". The software in it's basic form was useable, but the company had other needs. They wrote modifications to the software (with the original creators permission) to run within their networks and throughout the company. If under a GPL license the company would have had to opensource their modifications and release them under the GPL, the company would not have taken up the GPL software.
Freedom is a good thing, but forcing people to open their code is almost as bad as the closed code is.
how ya doin? (Score:5, Insightful)
Automatic Bolo server finder? (Score:2, Funny)
Bolo and WinBolo [winbolo.com] rock!
Cheers
VikingBrad
NOW you tell me! (Score:3, Interesting)
But seriously, Sharp has already embedded this technology in thier printers, so it's not just Epson, HP, and Lexmark that will be supporting this standard.
Conceptual iPod Rendezvous Use (Score:1)
check out CFNetServices (Score:2, Informative)
Imagine a Beowolf clust... No, seriously. (Score:3, Insightful)
zeroconf is not a standard yet, and has problems (Score:3, Informative)
zeroconf breaks applications in several ways, for instance:
zeroconf will be really nice when we figure out how to make it work well without breaking apps. It's unfortunate that Apple is trying to deploy a technology widely that has several serious known flaws and claim that it is a standard before those flaws are fixed.
Latest IETF Draft (Score:2)
http://www.ietf.org/internet-drafts/draft-ietf-ze
I Have a Question! (Score:2, Troll)
To me, there seem to be no big differences, so why do people have such a problem wiht the APSL
It Would be Nice... (Score:5, Insightful)
Endless iterations of the same traditional Unix toolset, tools for the server side, and attempts to mimic Office and the Windows interface, won't cut it. Be imaginative.
When I've tried to explain Linux to people who make corporate buying decisions, their questions boil down to: Why buy a cheap knock-off when the real thing is available?
(Please try to refrain from the usual
Money Making (Score:4, Insightful)
This might be a bit redundant, but it seems to me that the most interesting thing about all this is that Apple seems to have hit on a business model that actually makes money off open source software. First came OSX, which isn't really much more of a modifed PPC port of FreeBSD (Darwin) with a wicked nice (and nicely engineered) GUI (Aqua) slapped on top. Now we have Rendezvous, where Apple is making their implementation of an open standard open source, in hopes that its broad adoption will encourage people to buy Apple's software. Imagine what these guys could do with Ogg. . .
So maybe the moral of the story is this:
Of course, you can't attribute all (or even most) of Apple's financial success to their OSS endeavours, but (and I speak from personal experience here) OSX has changed Macs from cute little toys to a viable and intiguing alternative to x86 hardware. And if Rendezvous takes off, not only will it be a boon for the community, but Apple could do quite nicely as well. In the end though, Apple might be a pretty unique case: Apple is primarily a hadware vendor, and Apple's involvement with OSS primarily adds value to the hardware it sells (I'll buy a TiBook because it's the only game in town for running OSX), and there aren't a heck of a lot of hardware vendors who are in a position to duplicate what Apple is doing.
News, news and more news... (Score:1)
not open source (Score:1)
Been there... (Score:2)
Autoconfig DVD player? (Score:2, Funny)
Apple: The Community Company? (Score:1)
Quicktime is the only software that Apple makes that an average non-Mac user cares about, so until they port it to other platforms which people regularly use, I won't see them as a 'community friendly' company (ie a potential Microsoft.)
If they care anything for the community, they would have ported Quicktime to Unix platforms. They're pushing websites to use their platform (Quicktime mov), but they don't provide players for any platform that doesn't have huge marketshare, thereby furthering monopoly-like status of Windows and MacOS. Hell, even Real ported to Unix when they were pushing to be the dominant steamed video platform back in the day...
As a matter of fact, there's a RealOne beta port for Unix.
Let the OS vendors do OSes and leave the multimedia to a 3rd party, please.
I can't blame them for doing what big corporations do (further their market share) but I don't have to like it or support it.
Long live Ogg!
Hope they dual-license it (Score:2)
Code to implement this stuff would logically be made available as a library, but if it's released under a GPL-incompatible license, it will complicate the job of using it to add support for Redezvous to Linux desktop programs, other libaries, or the kernel. This problem can be avoided if a dual-licensing approach is used, that is, terms are either GPL or whatever terms Apple prefers.
Typical Slashdotter reaction to this kind of news (Score:2)
Now, if __insert_company_name__ had released it in such a way that it directly benefited me and my work... well, then they would have been champions of freedom and respectful of me as a human being.
Oh, great. Next is "War-Peeling" (Score:1)
Re:Obvilusly not the GNU Liesince (Score:1)
Umm. (Score:1, Informative)
It was released last week, and my copy just arrived in the mail. I am going to install it just as soon as i've glanced through slashdot. I will be running it within the hour.
Is this what you call "vaporware"? Because that is not what it seems like to me.
Perhaps you should clarify yourself.
Re:Obvilusly not the GNU Liesince (Score:2)
Re:Well this is kinda dumb considering... (Score:5, Informative)
Rendezvous is the ITEF standard "zeroconf". It is not uPNP. It might have some things in common, but it is very much a different standard.
Re:Rendevouz is a sham (Score:1, Flamebait)
Re:Well this is kinda dumb considering... (Score:2)
Re:Well this is kinda dumb considering... (Score:2)
As for your Moral of the Story. If that is true, then Apple did develop the standard because Apple worked with TI in creating the IEEE 1394 technology.
Re:x86...barff (Score:5, Funny)
The Floppy Drive, no we had that first
The home computer, no we had that first too
The mouse, no we had that one first
The GUI, no Xerox had that but didn't want it, we got it and made it good.
Oh I know SCSI, no wait, that was another first for us.
You must mean USB, well yeah Intel developed that first, but they just sat on it, Apple ran with it and wow, now look where it is.
Oh you mean 64 bit processors for consumers, no wait that was us too.
You must mean M$ programs, no wait we had those first too.
Oh well
Rendezvous has network effect (Score:3, Insightful)
Does that also include using the dmca? (Score:2)
Re:Does that also include using the dmca? (Score:5, Informative)
> According to news.com [com.com]apple is using
> the dmca
Yesterday, I wrote a posting "First version of this story did *not* mention DMCA" (read it at http://slashdot.org/comments.pl?sid=38907&cid=416
> to make sure its itools software does not work
> with any other dvd player but there own internal
> ones
This has nothing to do with iTools (which kinda indicates that you might not have read the article you are refering to). Apple created *iDVD* to sell their SuperDrive equipped Macs. OWC was trying to warp iDVD so they could use it to sell OWC's own DVD drives. OWC was stealing Apple's work, against Apple's license, in order to compete with Apple in the DVD drive market. Apple is the victim here.
> Apple does not care about the opensource
> community
Ha! They have released Darwin and Quick Time Streaming Server (and next month Rendevous) as open source.
OS X includes such well loved open source and free software as GCC, Emacs, Apache, and Perl.
They provide documentation on using open source, such as this page (http://developer.apple.com/internet/macosx/osdb.
And Apple ships with Macs (compressed on the hard drive but available and free for install) and in the OS X retail boxes a free copy of their development suite (which now includes GCC 3.1). Upgrades are free for the download, or $20 for a FedEx-ed CD. This enables any Mac user that wants to, to develop as much open source as their little heart desires, without having to pay for development tools.
> like Enron care about profits above all else.
Companies have to care about their profits because their first duty is to their shareholders. But in order to get those profits (and they have to be real, not cooked books), they have to care about their customers and keeping them happy.
Apple does care about their customers, their shareholders, and even tries to benefit the industry as a whole (Firewire, Rendevous). In contrast, Microsoft takes their customers for granted, uses them, manipulates them, treats them like criminals. Microsoft also doesn't pay shareholders dividends, and their stock prices are no longer going up and up. Microsoft acquired more congresscritters than Enron, because they donated three times what Enron did in the 2000 elections. You can compare one of these two companies to Enron. The one isn't Apple.
BTW, thank you Apple, for gifting Rendevous to the open source community. It was an unexpected, and most pleasant surprise.
Yatta Jaguar!
"It's a miracle! The sea water has once again created new life."
Moll, "Rebirth of Mothra 2"
Re:open source? yeah right... (Score:1, Troll)
As I see it, there's no real difference there.
Re:How beneficial will this be? (Score:1)
Apple has proposed Zeroconf has an internet standard. It's still only in draft form: http://www.zeroconf.org/ [zeroconf.org]
If you're pushing for an Internet standard, it certainly helps to have an open source implementation of the standard. Check out the RFC describing the Internet Standards Process [ietf.org]. You'll note that a proposed standard: A Proposed Standard specification is generally stable, has resolved known design choices, is believed to be well-understood, has received significant community review, and appears to enjoy enough community interest to be considered valuable.
This doesn't state that you have to release open source, but it helps the case when you want to can get other people to look at your code and see what you've done.
Also note that a draft standard requires: A specification from which at least two independent and interoperable implementations from different code bases have been developed, and for which sufficient successful operational experience has been obtained, may be elevated to the "Draft Standard" level. Yes, they are independent implementations, but it can help other people develop theirs if they can see your source code. When my implementation doesn't interoperate with Apple's, I can actually figure out why, and whose fault it is.
So yes, releasing the source code is good if Apple wants this to become a standard.
-alain
And interview with Stuart Cheshire creator of Zero (Score:1, Informative)
http://www.gaeldesign.com/ib/mw0702_stuart.php
Now the ZEROCONF Working Group that is part of the IETF is responsible for developing and maintaining the open-standard Zeroconf networking protocols, dubbed Rendezvous by Apple. Can you give us a brief overview of these protocols and the history behind them?
The initial seeds of Zeroconf started in a Macintosh network programmers' mailing list called net-thinkers, back in 1997 when I was still a PhD student at Stanford. We were discussing the poor state of ease-of-use for IP networking, particularly the lack of any equivalent to the old AppleTalk Chooser for browsing for services. I proposed that part of the solution might be simply to layer the existing AppleTalk Name Binding Protocol (NBP) over UDP Multicast.
Re:How beneficial will this be? (Score:2)
I think the key difference is the word Abandonware. In the case of OpenPlay Apple took an old basically dead piece of software they no longer cared about & weren't really using themselves and realesed it as open source. "Who knows" they figured, "maybe somebody will find a use for it."
Rendezvous on the other hand is a new technology that they use themselves and will continue to develop for their own uses whether the open source community picks it up or not. They intend to push it to third party developers & peripheral manufacturers in a way they didn't bother with OpenPlay.