Slashdot Mirror
ArsTechnica Posts Mac OS X 10.2 Review
hype7 writes "ArsTechnica have posted their review on Mac OS X 10.2. John Siracusa has been writing the reviews of Mac OS X since way back with the developer previews, and in my experience they've been the most thorough, thoughtful and unbiased reviews of Mac OS X on the web. Well worth a read." He does do a fine job; so if you needed one last fix of looks at Jaguar, here you go.
Nice review of Rendezvous:
Rendezvous is Apple's brand name for a technology that is hard to explain to the average computer user, and potentially even harder to market. I'm going to come at it from a few different angles. First, here is the (mildly) technical side of the story.
Technology
Rendezvous supports four important services.
1. IP interface auto-configuration.
2. Translation between host names and IP addresses.
3. Service discovery.
4. IP multicast address allocation.
The first two items sound like services you probably already have. Your network interfaces might automatically configure themselves by contacting a DHCP server. Translation between host names and IP addresses is done with the help of one or more DNS servers (possible also configured by your DHCP server). Service discovery sounds like something that's already handled by one of the many directory services that exist today (e.g. Active Directory on Windows.) The last item in the list sounds kind of esoteric. So who really needs these services?
The picture starts to become a bit clearer when the list of services is rewritten in terms of existing technologies in the same areas. How does this slightly revised list strike you?
1. Allocate addresses without a DHCP server.
2. Translate between names and IP addresses without a DNS server.
3. Find services, like printers, without a directory server.
4. Allocate IP Multicast addresses without a MADCAP server.
Suddenly we've gone from a list of seemingly uninteresting services to a set of capabilities that sound like magic! The last one still sounds a bit uninteresting, but it's actually a strong hint about how the whole system works.
Put simply, Rendezvous enables a local network of devices to configure themselves without the aid of any centralized servers. The key word here is "local", because Rendezvous only applies to a limited network domain. Rendezvous is not designed to scale to support the entire Internet. It is meant for small to medium sized networks.
All the magic happens through cooperation. Participating devices talk amongst themselves to sort out who has what address and what hostname, etc. This communication is done through the use of multicast IP addresses.
In order to bootstrap, all participating devices initially communicate using a "well-known" (i.e. pre-defined) multicast address. The first step is for each device to assign a unique IP address to all of its network interfaces. These so-called "self-assigned" addresses are taken from a special address block reserved for this purpose: 169.254/16.
(This address range may look familiar to those of you who have seen a machine fail to get an address from a DHCP server and then fall back by assigning itself (thus "self-assigned") an address in this range.)
Before continuing, it's important to note that these self-assigned addresses may be (and probably will be) assigned in addition to a device's "normal" Internet IP address. Remember that a single network interface can support multiple IP addresses.
Of course, the trick to self-assigned IP addresses is ensuring that no two hosts assign themselves the same one. To resolve these conflicts, Rendezvous-enabled hosts are able to "ask" simple questions (again, using well-known multicast IP addresses) such as "does anyone else have this address?" Address conflict resolution is actually done dynamically on an ongoing basis, rather than only once when a device is initially configured. This is possible because all Rendezvous services share the same dynamic configuration policy.
Take service number two, for example: translation between host names and IP addresses. Since IP addresses may change at any time due to the ongoing dynamic address conflict resolution, so too must hostname assignment and lookups be done dynamically on an ongoing basis. Again, well-known multicast IP addresses are used to ask questions such as "is anyone else using this hostname?" and "what IP address currently corresponds to the hostname 'foo'?"
Remember that there is no central server, so the answers to these types of questions come from the only authoritative source: the other hosts themselves. Each host is responsible for responding to questions about itself--questions that only it can answer with certainty.
Note that these Rendezvous hostnames only have meaning within the current network and exist in addition to any "normal" Internet hostnames that may be associated with the device.
Given this ad-hoc network of devices, the third item, "service discovery", is straightforward. Devices ask the network at large, "is anyone providing the service 'foo'?" Any device on the network that is providing the requested service will respond, saying "I am providing that service."
Finally we get to the last item in the list: IP multicast address allocation. This service is used to dynamically allocate application-specific multicast IP addresses. Rather than using "well known" multicast addresses (which every device is listening on) for all communications, devices can request the use of a private multicast address for a given network scope. As you'd expect by now, all participating devices cooperate to share the finite pool of multicast addresses pulled from the address block reserved for this purpose.
In truth, these services have all been provided by earlier technologies like AppleTalk, NetBIOS, and IPX. The first thing that makes Rendezvous different is that it is an open standard. Rendezvous is merely Apple's name for its implementation of the technologies proposed by the Zero Configuration Networking (Zeroconf) workgroup of the Internet Engineering Task Force (IETF). Apple does not "own" the technology any more than it owns IP networking or any other Internet standard.
The second thing that makes Rendezvous different is that it is built using existing IP networking technology. It communicates using standard IP networking. It uses standard DNS request packets for name resolution. Device and multicast addresses are allocated from address blocks explicitly reserved for this purpose. There is nothing proprietary or vendor-specific about it, and it is designed to work on existing IP networks without requiring any changes to them and without causing interference of any kind.
Network administrators reading all of this may have reservations as they envision network broadcast storms and other unfriendly behaviors that were exhibited by earlier proprietary protocols. The Zeroconf specification was written with this in mind, however, and there are restrictions on such behavior. It remains to be seen exactly how much less "chatty" the first implementations of Zeroconf really are, but the use of existing packet formats and addressing techniques will certainly give it a big head start on proprietary protocols that need to have each of their proprietary packets "wrapped" in standard IP packets before transmission.
History
A look at the history of Rendezvous is also instructive. As mentioned earlier, Rendezvous is Apple's brand name for its implementation of the Zeroconf standard. Zeroconf, in turn, traces its roots back to a discussion on a Macintosh network programmers' mailing list in 1997. The idea was to give IP networks the same ease of use enjoyed by AppleTalk networks.
Since 1997, Apple itself has made a transition from AppleTalk to IP networking, and in the process it has lost some of its historic ease of use. So it is not surprising that a standard designed to make IP networking more friendly was originated and eventually ended up in use at Apple.
With each foray into the world of standards, Apple is improving both its behavior and its success rate. The Bad Old Apple suffered from a severe case of Not Invented Here syndrome, insisting on inventing its own proprietary standards for just about everything. This often allowed Apple to leapfrong existing technologies, especially in the area most important to Apple: ease of use. AppleTalk is a great example of this. It provided a very friendly networking experience to the masses long before ease of use was even a consideration for most other networking standards.
The disadvantage of proprietary standards is that it's very difficult to get them adopted by the rest of the industry. No one wants to tie part of their business to a technology owned and controlled by a competitor. A standard that does not get adopted by the rest of the industry suffers in several ways. First, the entire cost of development must continue to be shouldered by a single company, rather than shared across the entire industry. Second, a smaller market means lower volumes, higher prices, and fewer choices. Finally, inevitably, industry-wide open standards eventually catch up with the proprietary technology, rendering it an island of interoperability.
AppleTalk suffered all of these fates. Apple's choice to move away from AppleTalk and towards IP networking was unavoidable, largely due to the explosion of the Internet. But this change met with some resistance because IP networking had not yet caught up to AppleTalk in terms of ease of use. Rendezvous finally closes the gap, providing the few remaining AppleTalk-like services that IP networking lacked.
More importantly, Apple has accomplished this not by defining a new, proprietary Apple-only extension to IP networking, but by working "within the system" to help define an open standard that is compatible with existing networks.
It's certainly a lot easier (and quicker) to unilaterally create a new proprietary standard. This interview with Stuart Cheshire, the chairman of the Zeroconf working group and an Apple employee, gives some insight into the difficulties of convincing the IETF that "ease of use" was even an important quality for IP networking to have. Here's what he had to say on the topic:
The IETF is generally populated by people who care very little for ease-of-use [...] Even today, it remains a something of a minority view in the IETF. Most IETF people work for router vendors, ISPs, backbone providers, telephone companies, etc., and their focus is wide-area networking. If you work for a company that makes routers, you've not going to be very excited about technology that lets computers communicate directly, without needing a router. If you work for a company that sells a DHCP server, you've not going to be very excited about technology that lets computers communicate without needing a DHCP server. If you work for a company that sells DNS servers, you've not going to be very excited about technology that lets computers communicate without needing a DNS server. I'm sure you get the point.
But ease of use is incredibly important to the end user, and will only become more important as more potentially networkable products are introduced. So, finally, let's look at Rendezvous from the perspective of the consumer.
John's review lacked thoroughness. He missed the fact that this version of OS X has been let out without it's pants being cuffed. Read this from one of Apple's Developer lists:
... let's get down to the
nitty gritty.
Jaguar marks
the first public release of these APIs, and there are several fairly
big known problems and issues already that we want you to be aware of.
The largest number of issues are in the filesystem generation code.
First things first
Known issues in 6C115:
(1) [Content] ISO-9660/Joliet broken - there are problems in the ISO/Joliet structures written to disc which make files deeper than the root directory unreadable on Windows 2000 and XP. (Specifically, the parent directory pointers in the path table are incorrect.) Some ISO-9660/Joliet implementations can read these discs successfully, but you should not rely upon them to work everywhere.
(2) [Content] Virtual filesystem hierarchies broken - the APIs to create and burn virtual hierarchies (DRFile.h, DRFolder.h, DRContentFile.h, and DRContentFolder.h) do not work. You will get an error when burning, and in some cases may crash due to a bad pointer reference inside the filesystem generator.
(3) [Content] HFS+ CDs report a (harmless) "bitmap needs minor repair" when run through Disk First Aid.
(4) [CoreEngine, DiscRecUI] Certain notifications having to do with the drive tray state may not be sent. When a disc is ejected via the keyboard eject button, or when the tray is opened via the front panel eject button on the drive, you are supposed to get a device status changed notification, but won't. This is visible in the DiscRecording UI components as well; we're waiting on a bugfix and an additional feature from IOKit before this will work.
(5) [Content] Virtual links (symlinks, aliases) are mostly untested and may not work correctly.
(6) [Content] UDF is not yet available in the first release.
(7) [DiscRecUI] Carbon/C APIs to the UI components are not yet available in the first release.
That's all I have on my notepad at the moment. The good news is, the first three have been fixed already and scheduled for release with the first Jaguar update. I don't have timeframes available for when, other than "soon". The remainder are being worked on but I don't have timeframes available for those either.
============
When these and others are fixed, it will be appropriate to review. John may know this, but he wanted to be first to the party, and now many readers will take what he says without knowing the facts.