Slashdot Mirror

No. If Apple had developed it, it would not have had any command-line interface except for XML files and the "defaults" program, its interfaces would have been proprietary to Apple,

Yes that's why LLVM, Clang, OpenCL, Zero-Configuration, and WebKit only works on Apple machines.

Wait, what? Where'd all this hostility come from? I've used Macs for 25 years, and I'm using a Mac to type this. I like parts of Apple and MacOS X, but I recognize some of its shortcomings. In my opinion, nothing is perfect.

I didn't say that Apple does not do open source. CUPS, LLVM, Clang, and KHTML (predecessor of WebKit) were not invented at Apple, and Apple complies with the license terms of the original projects. ZeroConf and OpenCL are examples of basic infrastructure that Apple decided would be in their interests if they were widely adopted. Apple has some surprisingly small teams for some projects, and I think of ZeroConf as a Stuart Cheshire project more than a faceless corporate project. Even so, Apple initially did their open-source releases under the Apple Public Source License, which is not compatible with GPL, and the existing OpenCL kernels are all proprietary. Or did you not notice that Mesa had to reimplement OpenCL from scratch?

In contrast, I notice Apple protocols such as AirPlay and AirPrint, the whole Designed for iPhone licensing system, and how Apple is going out of their way to avoid any GPLv3 software such as Samba 3.

CUPS was widely used before Apple bought it. Apple can't turn it into an Apple-like program without causing a user revolt, so it's still very much like how it was before Apple bought it.

Yes Apple is EVIL for not completely changing the software they own to be proprietary and they are also EVIL for forking software they didn't own (WebKit). Face it folks, Apple can do no right.

I don't see how you got that conclusion from what I wrote. I said that CUPS was not developed at Apple, so its peculiarities are not typical to Apple.

As for why this is a good thing, there's a difference between the speed of electrons through copper and silicon vs. the speed of light through translucent plastics and crystals. It should also run cooler.

Ive seen varying numbers that indicate that the difference is not as large as some are supposing.
This wikipedia article seems to indicate that 82% for coax is possible, 72% for plenum cat 5.
From what I've read, and according to google calculations, the speed of light in optical fiber is about 66% of that in a vacuum. ( also supported here, and here, as a reciprocal)

In other words, copper is faster. There are certainly some benefits (removal of the interference factor, possibly running cooler, possibly lower power usage), but I dont believe signal propogation speed is one of them.

On the other hand, Zeroconf was basically invented by Stuart Cheshire, who works for Apple (and invented the tank game Bolo, another good way to waste network bandwidth).

An Apple employee (Stuart Cheshire) is one of the authors of the RFC(s) related to mDNS, etc.

mDNSResponder originated from Apple.

Gah! Where's Bolo??? We're talking serverless multiplayer games at the tail of the 80's. Not exactly P2P, but everything else back then was client-server. Stuart Cheshire got a thesis out of it, no less!

Latency is the bane of all interactive services over IP, and bad enough as it is, without adding more.

It's a bit dated, but Stuart Cheshire's (author of Bolo) "It's the latency, stupid" is still relevant.

Right. Note that ZeroConf is the brainchild of Stuart Cheshire, and he works for Apple, so Rendezvous isn't some hobbled, second-hand implementation of ZeroConf, but from the horse's mouth.

Here's the history of ZeroConf:

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.

Also note that Stuart Cheshire is the brainchild of ZeroConf, and he works for Apple, so Rendezvous isn't some hobbled, second-hand implementation of ZeroConf, but from the horse's mouth.

Here's the history of ZeroConf:

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.

Note that this technology is NOT Apple's. It's the result of the ZerConf Group.

Well, Stuart Cheshire is the brainchild of ZeroConf, and he works for Apple.

Here's the history of ZeroConf:

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.

Get out! Your ZeroConf is run by no other than Stuart Cheshire, the creator of the classic network game of Bolo. Nice.

Get out! Your ZeroConf is run by no other than Stuart Cheshire, the creator of the classic network game of Bolo. Nice.

Read up where ZeroConf came from.

Note though, that Apple does not own ZeroConf. It's now out into the IETF space where anyone can scrutinize, comment, criticise and suggest improvements. And this IMHO is a Good Thing.

...although maybe it would be easier to port the linux clone than the original. too bad the linux version is only available as an executable. if only it were open source. it's gameplay is also a litte rough compaired to the original's. you can still open all your old map files though.

i wish stuart cheshire had not stopped development on the game. it has always been a blast to play. -megli

I used to play AO and now I play Planetside, so I like to think I've tried both sides of the equation.

The thing about AO was that you had a character to upgrade and advance in a multitude of (albeit tiny, almost meaningless) ways to get an overall better character. This persistent character can then go around and have fun in the world, killing monsters and gaining levels. There was permanence, my characters cool stuff stayed with him, and if you took over a section of Notum mining you kept it and the bonuses.

But you still had to play for hundreds of hours for all those tiny, meaningless improvements to mean anything, and to do anything really cool.

This is the same idea in EQ, you gain levels to use the burny swords and the glowy armor.

On the opposite side of the field, you've got Planetside. In just a few hours, a player can any equipment in the game, and blow up the people that have played the game since the beginning. This is the point, of course, and one of the reasons the game is so much fun.

But nothing ever CHANGES. You capture the same base night after night, fire the same guns, get killed by the same enemies guns, and get run over by the same vehicles, every day. It's not a level treadmill so much as it's building sand castles in front of the rising tide. No matter how much progress you make during the night, it will all evaporate guaranteed. Being a high level doesn't mean anything, save that you don't have to log out and log back in to play with different toys in-game.

Now, I don't think it'd be possible in the AO/EQ/DAOC style of gameplay to make lower level characters worthwhile, they are designed against it.

But I'd love to see higher level characters given new toys/a different paradigm of gameplay in Planetside, and the inevitable games like it. I think making even beginning players worthwhile to a conflict in an MMORPG is vital to making it fun, but at the same time, gaining levels should reward the player with more/better/different ways of playing.

Actually, after I wrote that, I realized that someone already wrote an article to that effect, though about a different era of online games. But his point remains the same: Gamers of all dedication/skill level/hours of free time available should have fun things to do, that at least they percieve as worthwhile.

yes, that email at the bottom is my 15 year old self.

skye

Actually it all started with games.

Specifically a Mac game named Bolo based on a serverless ring topology and written by a fellow named Stuart Cheshire. He also happens to be a "Wizard without Portfolio" at Apple and the Co-chairman of the IETF Zeroconf Working Group.

You can still play it. Watch out - it can get pretty addicting.

Any network scale distributed processing is going to be limited to large scale world maintenance stuff, not rendering (latency issues kill that crack pipe dream stone cold). Unfortunately many people (in and outside of Sony) are confusing this with cell processing, which is really about having multiple cores on the same chip.

Rendezvous is great and all, but I doubt it will ever consume more of the poster's time than did Cheshire's most important contribution: the network tank game Bolo *g*

Yeah, a Google search would have told you that it's the same guy.

There was a Mac Appletalk starmode driver (MetriTalk) written years ago. The problem is that it appears only to work with the old MacTCP stack, not with Open Transport.

However, if you get it running under MacTCP, you should be able to use Appletalk and MacIP over it.

The driver details are here.

You'll have to do a search on one of the Mac software archive mirrors to find the actual binary though - the link on Stuart's page is broken.

It's the ATM paradox:
ATM's big feature is guaranteed quality of service. When you set up a TCP/IP connection, the Internet does not reserve network bandwidth for you to guarantee that your data will not suffer network congestion or loss. ATM does offer guaranteed reserved bandwidth. This is its big advantage.

Or is it? If you reserve bandwidth for one user, then you have to refuse to let anyone else use that bandwidth. Everyone always talks about reservations in the context that you are the one who gets the bandwidth and it is everyone who is refused. What about when you are the one being refused? Reservations suddenly doesn't seem so wonderful any more, do they? The only way to make sure no one is refused service is to engineer your network so that you have enough bandwidth for everyone -- but if you have enough for everyone then why do they have to keep making reservations? That's the ATM paradox.

More here and here.

As for streaming the same video to lots of people at once, there is a fine answer already, called multicast. But corporations foolishly don't turn it on on thier networks.

It's the ATM paradox:
ATM's big feature is guaranteed quality of service. When you set up a TCP/IP connection, the Internet does not reserve network bandwidth for you to guarantee that your data will not suffer network congestion or loss. ATM does offer guaranteed reserved bandwidth. This is its big advantage.

Or is it? If you reserve bandwidth for one user, then you have to refuse to let anyone else use that bandwidth. Everyone always talks about reservations in the context that you are the one who gets the bandwidth and it is everyone who is refused. What about when you are the one being refused? Reservations suddenly doesn't seem so wonderful any more, do they? The only way to make sure no one is refused service is to engineer your network so that you have enough bandwidth for everyone -- but if you have enough for everyone then why do they have to keep making reservations? That's the ATM paradox.

More here and here.

As for streaming the same video to lots of people at once, there is a fine answer already, called multicast. But corporations foolishly don't turn it on on thier networks.