I'm having a great time visiting my brother Phil. Phil and Jackie have shown me great hospitality. Last night, Phil and I spent an hour or two downloading the digital pictures from the picnic, poring over them, and building an album suitable for posting on the web.

icky.jpg

Phil wanted to try out the picture-book-making capabilities of iPhoto, so we did that first. We were a bit disappointed when we found that it was carefully constructed to not allow you to get the content out any other way than by buying a book (for >$50). For example, the "Preview" button, which in any other Apple application will build a PDF file and open it in the Preview application, instead led to a special-purpose previewing tool within iPhoto with no export capabilities. Oh, well -- that kind of crippled behavior is typical for commercial software. Phil pointed out that iPhoto had also been crippled by Apple after it was initially released when they made it more difficult to associate keywords with images and then quickly extract lists of images that matched keywords. We had almost finished building a webpage for the pictures when it was time for dinner.

After dinner we watched the first episode of Buffy. I've never watched a Buffy before. It was pretty good -- Almost as good as Medabots (Warning: Flash). We're going to go to the store this evening and I'll see if I can get a Medabots DVD for us to watch.

iPhoto and iTunes are nifty, but the real problem with Apple's approach is the idea that clients ought to be servers. It's just crazy for every computer in the house to serve out its own collection of files. The idea is typified by an entry in this FAQ by Stuart Cheshire, who titles himself "Wizard without Portfolio at Apple".

Should I turn off Rendezvous to improve security?

Turning off Rendezvous to improve security is like having a company policy that every employee will be hit in the face with a baseball bat every day when they come to work in the morning, to discourage thieves. All this achieves is to make life unpleasant for the legitimate employees, while the thieves continue to come in through the back door and steal stuff anyway. Initiatives like this may give management the illusion that decisive steps are being taken to combat theft, but it's really just making legitimate employees' lives unpleasant without doing anything to solve the real problem. The correct answer is to lock the doors and windows, not to beat on the innocent employees coming in through the front entrance.

I don't think he's drawing the correct analogy here. His response seems to be that bad guys are going to break in, so it doesn't matter how many doors or windows you have and how well secured they are. That's just crazy. If you have people breaking in through doors and windows, the only sensible thing to do is make everyone come through the front door, even if that's a little inconvenient, because then you can have professional security guards secure and watch the entrance. If your security guards take too long, or are too officious, that's a human resources issue: you need to get more guards or get nicer ones -- not have every employee cut their own holes in the fence. With Zeroconf, every machine becomes its own DNS server, provides its own services, and then each machine ends up with an idiosyncratic collection of files, most of which should never be made public. If you set up a server and make it easy for people to post stuff there, even if the machine gets compromised, all of the stuff on the server is public stuff, that was meant to be posted anyway. Furthermore, if the stuff is all on a single server, it's generally a lot easier to find, update, maintain, backup, etc..

There are a bunch of other reasons not to run services on your desktop machine too. You probably will want to be able to reboot your desktop machine whenever you want: if you update the software or want to install hardware or because its become unstable. If the service is unreliable -- even just only 95% reliable -- it won't really be useful. Services don't require a lot of horsepower, but if a bunch of people hit your service at the same time, and that happens to be the 5 minute period you're trying to finish rendering an important graphic, the loss of performance can be really annoying.

Zeroconf also just doesn't work in a lot of contexts. In our building, we have multiple subnets running over the same physical network. Zeroconf machines notify each other using multicast, so you can see services listed. But if you try to connect to machines that are on a different subnet, you can't talk to them. So it works a lot of the time, but it doesn't work sometimes and most people don't have the technical know-how to debug the problems. The result is that a lot of people think its easier to just provide the services themselves, but then get bitten when it isn't really reliable enough to be more than a gimmick. And that undermines people's confidence in the ability of the network to be useful for real work.

In the Biology Department, we have a great technical staff that works hard to make things work for people the way they want them to work. If people need to run a service, they try really hard to convince them to run it on one of the servers and to get input from the technical staff to make sure it meets all of the user's needs and is both realiable and secured properly. This has created a self-reinforcing positive loop with most people, who are willing to invest the effort necessary to set up electronic resources because they know they will work and will be available when they need them. A lot of other departments never set up a server and, as a consequence, many of them think that the network is really only useful for email and surfing the web.

About 10 years ago, I went to a BioQUEST conference and I remember people laughing at me when I predicted that before too long everyone would have their own computer. When I went 5 years ago, that had already pretty much come to pass. At that one, I made the prediction that before too long everyone would have two computers: a portable or desktop computer and a server, with the server managing essentially all of the resources and services that someone wants to have. This hasn't really happened yet, but I think it still may. Airport Basestations are almost servers already: all they really need is a big hard-drive.


Yesterday, I linked to an article that described the dynamics of blog discussions and I discussed how they constrasted with threaded discussions. Today Joseph Duemer had a link to this article which takes the discussion much farther and has snazzy graphics to boot.


After I wrote for a while this morning, I took a walk by Kaufman Lake and saw an aphid giving birth. Aphids tend to go through two reproductive stages: In the first stage, they reproduce parthenogenically giving birth to other little clones of themselves. As the plant they're on is used up, they metamorphose into a winged stage that reproduces sexually and lays eggs. These were big, red aphids on a compass plant. I could see there were two big aphids and a whole bunch of little aphids, so I suspected this is what would be going on. While I watched, a little aphid came out of the big aphid's you-know-what. Maybe Phil and I will walk over there later this afternoon and see if we can get a picture.

I'm enjoying my vacation a lot: peace and quiet, comradaerie and good conversation, plus good food and exercise. It doesn't get much better than this.


StevenBrewer