Modern Geekery

Moving the blog

As part of the New Year, I'm moving my blog to LiveJournal. Despite LJ's well earned reputation for hosting lots of angsty teenagers, I've talked to several people who are pretty satisfied with it. I no longer have the time to mess around with the site admin aspect of running my own Movable Type installation and my hosting provider has gotten a lot stricter on the resources individual users consume, to the point where I'm not sure that it is really feasible to run Movable Type here anymore.

In any case, the new link is here and the redirect page will be changed accordingly.

See you at the new site!

Now -that's- service

As part of my vacation, I spent Thursday morning at a local coffeeshop catching up on some personal projects. When I plugged my laptop's power cord into the wall, the transformer flashed underneath its white plastic housing and let out a sharp crackle. Fortunately, the death of the power supply did not harm the laptop itself. A call to Apple resulted in a new unit arriving the next day. That's service.

MTBE to be removed?

My sources inform me that the Senate passed an amendment to an energy bill that would remove methyl t-butyl ether from the nation's fuel supply. I believe this can only be a good thing. MTBE, while an excellent oxygenator, is responsible for a good deal of groundwater contamination. Ethanol works nearly as well, is cheaper, and has less environmental impact.

And while we're on the subject of ethanol, I've discovered that many gas stations near my workplace carry E85. That is, 85% ethanol, 15% gasoline. And even more amazing, there are many cars on the road here that burn it. While Asheville does have a burgeoning biodiesel supply, it would be nice if the local car dealers and gas stations would add ethanol to the alternative fuel economy of the region

Booklover's geek tool

If you're not familiar with Greasemonkey, it's a Firefox extension that allows you insert user-defined scripts into web content. Its a way of client-side scripting that's pretty clever.

You may wonder, "what on earth do I do with this?" Here's the coolest answer I've seen: Book Burro;. If you're browsing a book page on various book retailers' sites, a simple click will check a list of other book retailers for their current price on the same book. Call it "1-click comparison shopping." Now, that is useful.

To the edge of space

I just read that SpaceShipOne had been dropped and was heading for the edge of space. Woot! Assuming all goes well, this flight will launch the most ambitious program in aeronautical history: the race for the Ansari X-Prize.

Links:
Scaled Composites
SpaceShipOne FAQ
Ansari X-Prize website

Can Trek be saved?

Star Trek is, for many people, the essence of geekery. Many hours of geek lives have been spent watching, discussing, arguing, and pontificating about Trek. And yet, in the hands of its oh-so-careful shepherds at Paramount, Trek has devolved into the standard pabulum of modern entertainment.

No one can claim that Trek didn't have the eye candy. Yeoman Rand, anyone? Counselor Troi? But, the eye candy was just that: decoration. People didn't watch it for the eye candy. And yet, in the two most recent installments in the Trek franchise, the eye candy seems to be what people talk about most. Certainly not the scripts, which for ST:Voyager were almost uniformly bland. I had the extreme misfortune to watch the pilot for ST:Enterprise, and was astounded at how awful the script, the acting, and the editing were, and disgusted at the transparent attempts at mass-market appeal. (The soft-pornesque 'decontamination' scene!)

I have not come to bury Trek, however, but to praise it. I had largely written off any hope of Trek returning to its science fiction roots. (Note for the uninitiated - adding the term 'in space' to a series treatment does not make it science fiction.) I then found out that one of my favorite writers and producers of any genre, Joe Straczynski, had been approached and offered the Executive Producer role for ST:Enterprise.

My jaw hit the floor. Someone over at Paramount has sensed the threat to their franchise that 5 years of gross neglect has caused. Joe, unfortunately for Paramount, declined the position, but said lots of very nice things about Manny Coto, the fellow who was chosen for the job. And let drop that he and Bryce Zabel (The creator of Dark Skies) wrote a treatment for a "Trek revival" series that in Joe's words, would "save ST." Here's hoping that Paramount takes them up on it.

You haven't -seen- rude, have you?

In the ongoing saga of Six Apart's meltdown, Timothy Appnel tore into Mark Pilgrim for his post on the subject, claiming it was rude.

All I can say is that Tim must not have seen Mark's writings during the Atom vs. RSS 2.0 debate. (which I blogged about as well.) That was rude. Mark's comments about Six Apart were frank and well-reasoned. Ben and Mena would do well to listen to Mark and the many others who are saying very clueful things about how they fscked this up.

Postel's Law is not an absolute.

Dave Hyatt has finally weighed in on an issue that I have been following and commenting on in various places. The issue at hand is whether requiring valid XML from servers makes sense. Dave is speaking exclusively in terms of how web browsers handle invalid XML. It is also, however, a critical issue for the new(ish) Atom syndication specification.

The issue began as an unwarranted flame by Mark Pilgrim on Brent Simmons' blog, arguing that his decision to require that Atom feeds be valid XML for NetNewsWire to render them was both a violation of Postel's Law and a blatant attempt to undermine the Atom spec.

Before we go on to discuss Postel's Law, which is the point of this rambling, I will point out, as I did on both Brent S. and Mark's weblogs, that requiring Atom feeds to be valid XML is in fact a -favor- to the Atom community, since the draft Atom spec does require that a feed be valid XML. Allowing malformed XML to be rendered starts a long slippery-slope slide into the abyss in which HTML currently dwells. Mark argues that this is necessity. I argue that XML, and thus Atom and RSS are different beasts entirely, and that forcing software that generates XML to be strict makes everyone's life easier. Unlike HTML, very few people write XML by hand.

Postel's Law: "Be liberal in what you accept, and conservative in what you send."

On the face of things, this seems to be good general advice. The truly wise man knows when and why his aphorisms are appropriate. I argue that Postel's Law is a tradeoff, not an absolute. What Postel's Law competes against is actually a generalization of Metcalfe's Law. Defining Metcalfe's term "network" to mean the users of any specification, whether it is TCP/IP, or HTTP/HTML or HTTP/RSS, there is value in ensuring the maximum number of users possible can and will use the specification. If a specification is not a reliable blueprint for engineers to develop applications around, it does not maximise users. Failure to require at least modestly strict interpretation of the spec creates a huge barrier to entry for applications, and ensures confusion on the part of the end user when their applications are not interoperable or are marginally interoperable.

A case in point is the now-ancient incompatibility in Microsoft's TCP stack. In 1997, it was noticed that Solaris webservers served Windows machinese very slowly. The cause of this problem turned out to be due to Microsoft failing to implement a relevant portion of the TCP specification (support for slowstart), compounded with a bad implementation of delayed_ack. (Of course, consipiracy theorists of the time charged that Microsoft was trying to drive sales of Windows-based servers. Hanlon's Razor applies.) Of course, the point is that whether by sins of omission or of commission, Microsoft reduced the utility of the whole Web at the time, by making a partially incompatible implementation of the spec.

It is easy to envision the future of the Atom spec, and of XML in web browsers in general, if this corollary to Metcalfe's Law is not allowed to weigh against the demands of Postel's Law.

As a closing note, I will also point out that such interpretation of Postel's Law as we are seeing applied to this debate place a disproportionately large emphasis on the first half of the law. There is a certain amount of irony in seeing the folks championing the "universal truth" of Postel's Law as an excuse to allow some developers to violate its second half with impunity.

When Titans Collide

Those of you with backgrounds or interest in nanotechnology have probably been following the ongoing debate between uber-nano-geeks, K. Eric Drexler and Richard Smalley. This debate has recently spilled out of the rather narrow nanotech community into the larger scientific community with this article in Chemical and Engineering News, a publication of the American Chemical Society. Drexler and Smalley both have impeccable credentials in the the field: Smalley won the 1996 Nobel Prize in Chemistry for the discovery of fullerenes, and Drexler is a well-known theorist with many publications in the field. Both men were featured in Wired 3.08 (August 1995) in a piece on nanotechnology, along with other nanotech luminaries Robert Birge, J. Storrs Hall, and Donald Brenner. (Full disclosure: I worked as research assistant for Don Brenner while I was at North Carolina State.) The debate at hand is the feasibility of what are common termed "molecular assemblers." Read on for a description of the problem, and my opinion as a former nanotechnology researcher.

Lets talk about molecular assemblers first. The term refers to a class of theoretical devices that essentially build things one atom or a molecule at a time. Think of this as a set of little tiny fingers plunking down atoms in precisely the right spots, and you have the basic idea of what is going on. While molecular assemblers are only a small part of the vast field of nanotechnology, they are the most (over)hyped and most feared. The infamous "grey goo" fear, of rampaging nanotech destroying the word, derives from fears of molecular assemblers gone awry.

The vision of tiny fingers moving atoms around is not a terribly accurate picture of the way molecular assemblers work. This is immediately obvious if you think about the problem of trying to pick up a single atom. What do you hold it with? A physical device, like a pincer, could not hold the atom, since it too must be composed of atoms. Instead, most nanotech luminaries speculate that assemblers will work by using fast-changing specific chemistries to grab, move, and align atoms.

Smalley, some time ago, began to lecture on the impossibility of this approach. He carefully and clearly labelled his two problems with assemblers as the "fat fingers" problem and the "sticky fingers" problem. (Scientific American, Sept. 2001) The essence of each argument is that it is impossible to control the chemistry of a reaction by purely mechanical means. The "fat fingers" argument states that for a manipulator to be sufficiently complex to maneuver single atoms, the number of atoms necessary to build it would make the manipulator too large on the chemical scale (in Smalley's definition, 1 cubic nanometer). The "sticky fingers" argument is somewhat simpler, stating merely that there is no way to control the chemistry between the manipulator and the atom being manipulated.

When Smalley advanced this thesis in SciAm, a careful rebuttal was made by Drexler and several others, including J. Storrs Hall. The rebuttal gave specific counterexamples (including one from a research paper by Don Brenner that inspired a followup project that I worked on.) The debate continued outside of forums monitored by the general community until recently. Both Smalley and Drexler have valid objections to the other's arguments. Smalley points out that Drexler's purely mechanical, in vacuo approach is naive in regards to the complexities of chemistry. Drexler points out that current theory and experimental evidence indicate that his approach will work, and that Smalley is misrepresenting the scale of what is required to accomplish nanoscale manipulation of molecules.

After reading the point-counterpoint, and thinking about it in terms of the research I have done in the field, I think I understand the key of this debate. This is still an active field of research, so one of Smalley's objections, that Drexler did not have all the answers for how to control the interactions mechanically, doesn't ring true. If he had the answers, there'd be no need for the research; it would be a development problem. Smalley accurately has identified what Drexler and his colleagues should be researching.

Smalley's statements seem to indicate that he distrusts the theories currently advanced by the computational scientists, both those doing density functional (DF) calculations and molecular dynamics (MD) calculations. It has only been recently that the problem of chaperone molecules and solvents have been approached in a systematic, large scale way. Some of the research in this field is being done by my former colleagues at LSU (now at USC).

However, the results for an "in vacuo" approach have been shown time and again to be reasonably accurate, and as yet, no predictions made from these results have turned out to be invalid. My own doctoral dissertation showed that the relative hardnesses for ceramics can be predicted by computational means.

While Smalley is correct when he says that

Much like you can't make a boy and a girl fall in love with each other simply by pushing them together, you cannot make precise chemistry occur as desired between two molecular objects with simple mechanical motion along a few degrees of freedom in the assembler-fixed frame of reference. Chemistry, like love, is more subtle than that. You need to guide the reactants down a particular reaction coordinate, and this coordinate treads through a many-dimensional hyperspace. ... Chemistry of the complexity, richness, and precision needed to come anywhere close to making a molecular assembler--let alone a self-replicating assembler--cannot be done simply by mushing two molecular objects together.

He neglects the fact that Drexler and his colleagues can accurately predict which of these "hyperspace trajectories" (those of us in the field refer to them as phase-space trajectories) will yield the desired product using MD and DF techniques. This will allow those people trying to construct the assemblers to winnow out unproductive geometries quickly.

Further, Drexler makes an excellent point that he does not expound on, which is that mimicking biological processes may give us unexpected leaps in the construction of assemblers. Ribosomes are almost exactly "what the doctor ordered" in this regard, building proteins according to instructions given by a strand of RNA. Smalley points out that this complicates the chemistry immensely. He is correct, but neglects to point out that by stealing ideas from Nature, we may be able to make it work without necessarily understanding all of the complexities.

My personal feeling is that we will not have to steal much from Nature, other than ideas. While Drexler does not come out and say this, his simplifying approach of trying to work outside of the complex water-solvent chemistry is simply what all physicists learn: the best way to solve a problem is to eliminate unnecessary complexity first. While it may turn out that some of this complexity is unavoidable, the divide-and-conquer strategy will usually beat out a more wholistic approach.

One thing about Smalley's objections puzzles me: in the aforementioned article in Wired magazine, each of the nanotech gurus made date predictions on certain aspects of nanotech. Smalley was the most optimistic about the production of a molecular assembler, predicting that it would be created by the year 2000. Something happened since then to change Smalley's opinion, apparently. My guess is that the "grey goo" hysteria about nanotech, and the desire by certain groups of uneducated, reactionary activists to regulate nanotech out of existence before it ever arrives, has led Smalley to agitate against funding projects that are attackable in this way. By funding more esoteric nanotech research, it might be possible to sneak under the regulators' radar.

This is a very cynical thought on my part, and one I desperately hope is not the case. While science and politics have always been uneasy bedfellows, bringing such Machiavellian tactics into the scientific debate can only cheapen the field.

What's wrong with Spring

I was quite disappointed to hear that Robb Beal was not going to be spending as much time on Spring as he has been. I think Spring is an important step in the evolution of the computer interface, as we continue the path that the folks at Xerox PARC put us on when they invented the GUI.

It is not unsurprising, however, that Spring has failed to gain a large following outside the technorati. Spring has some serious deficiencies that I believe must be corrected before it can have any hope of wider acceptance in the Macintosh freeware market.

The first problem, and the most superficial, is the astoundingly spotty documentation. There are more examples than you can shake a stick at, which is usually a plus in software documentation. Unfortunately, there are very few actual instructions on establishing workflow. Some guides to establishing a process for use would be incredibly helpful.

There is also nearly no documentation explaining the limitations of the interface. I spent a maddening few minutes trying to figure out why the Me object I created did not carry the picture I had included in the Me dialog. Instead, I had to drag a picture on the object from outside spring, which worked fine.

Spring also has some frustrating and puzzling limitations on the apps that it considers "blessed" for interaction with Spring. As stated in the Spring Quickstart guide, "AOL Instant Messenger (AIM) is an integral part of the Spring experience." But what if you don't use AIM? What if you prefer Yahoo Messenger? Or Jabber? What if you don't want to support AOL for ethical reasons? This statement is strong enough to warrant putting Spring into the Trash Can without any further ado. One might even ask why a strong independent developer is giving free marketing to a multi-billion dollar company.

This leads to a deeper question of why there are so few ways to share objects between users. Why not Rendezvous sharing on local networks? By embedding Jabber client code, canvases could talk to themselves directly, using SSL even. Every Mac comes with an Apache distribution. This too, could be leveraged. Imagine Spring starting an instance of the Apache server running with user privs, bound to a non-prived port to avoid ISP port blocking, and using a custom configuration. Canvas and object sharing could then be done via http requests. The possibilities are endless. Yet, we are stuck with AIM?

There are more examples of this. Watson, for instance. For as much use as I give it, Sherlock is more than sufficient for my needs. I've tried the Watson demo several times and never felt that it was worth the amount Dan charges for it. That's a personal choice, not a reflection of the quality of Watson; I simply don't feel that it puts me out to visit the websites. Certainly not enough to pay US$30 for the nice interface. Its a really cool toy, but its a toy, and with the new baby, my pocketbook is not deep enough for toys. (Note that I feel the same way about Spring itself.) Were Spring to support even basic interaction with Sherlock, things might be different. I might spend US$30 on Watson, or US$21 on Spring, if either one of them made my life easier, but I'm really not likely to buy both.

The essential problem here is that by making these somewhat arbitrary choices of "complementary applications," Robb has limited the bulk of Spring users to the intersection of the set of AIM and Watson (and etc.) users. Limiting an already small userbase is not a recipe for success.

Of course, were Spring's methods for creating objects not crippled in such unusual fashions, this might not be an issue. The Spring website claims that Spring supports stock quote objects. It does. However, if you want to add your own (without Watson, I assume), you get to edit a template XML file included in the Spring distribution. This is not a stellar example of "user-centric" behavior.

I recognize that much of this represents a huge workload for a single developer. The time honored way of dealing with such bottlenecks is for the developer to write a plug-in API. And this is what I think is the key to Spring's woes are. If you are writing something to revolutionize the user experience, you have to have functionally infinite resources in order to get into every nook and cranny of the old user experience. And Spring is in this camp. I'll take a line from one of its pop-up menus as proof of the statement: Suggest an action.

In my current Desktop Canvas, about half of the possible object-object interactions currently consist of that one line. Suggest! Suggest, my foot! Give me the ability to write my own freaking actions! Give me the ability to write my own sharing protocol. Make it possible for the technorati like us, who love the app, to turn it into something more than a toy. Someone will write playlist object that lets you add live-updating "Currently listening to:" field to one's sharable user object. Then, I can bring up Spring, right-click on Robb's icon, see that he's listening to a band I've never heard of before. I know I like Robb's taste in music, so I drag to the iTMS store object, and iTunes pops up with all of that artist's albums. That is the kind of interaction Spring is about.

If Steve Gehrman is reading this, he's probably chuckling, because I wrote a similar rant to him in a private email in the days right before SNAX became Path Finder. I don't know if anyone else had also emailed him, or if I'd anticipated Steve's own design strategy, but Path Finder gained a plug-in API, and is infinitely cooler for it. (And I didn't even have to write the plug-in I really needed, the Image Converter, cause Steve made it one of the examples! How's that for service?) I think Spring would similarly benefit from a component architecture. With NSBundle (or CFBundle for the Carbon folks), there is precious little reason not to consider creating a plug-in API. The costs are so minimal compared to the potential rewards. Ranier Brockerhoff had a wonderful session and tutorial on using NSBundle at MacHack 2002. The notes for that may even be available on his website somewhere.

Panther's Network Connect: Will they ever get it right?

I'm sitting here, trying to figure out why my laptop is still trying to reconnect to the office fileserver. I connected to the machine on Thursday, and forgot to disconnect before leaving the office. Silly me.

It gave me the little warning and asked me if I wanted to disconnect. Fine. Except now, its spamming my logs with "Trying to reconnect" statements. Both console and system.log, once every 3 seconds. No problem, I think. I figure when I get back on the office network, the problem will be solved.

Oh no. It -still- fails to reconnect, only now, in the Network folder, I can't "eject" the mounted server, which means I can't -remount- it either. I'd love to know what is going on. This is the third time this has happened since installing Panther.

Browser happiness

I have not been happy with my browser situation in a long time. For a while, OmniWeb was my browser of choice, until its legendary quirkiness in rendering many CSS2 pages finally caused me to give it the boot.

I used Chimera/Camino for a while. Eventually, for reasons I can no longer remember, I gave it up as well. I moved to Mozilla 1.3, then 1.4, and finally 1.5. I kept Safari in my Dock, for certain special tasks - browsing the Apple developer docs, for instance, and for previewing changes to the websites I might be working on.

I was always irritated that Mozilla could not match Safari's speed and low memory footprint. I was unwilling to migrate to Safari, however, for several reasons, the most prominent of which was Safari's lack of an "Ask me" option for cookies.

In my efforts to cure myself of the browser blues, I tried Mozilla Firebird. I started with 0.6. My first impression was: what a piece of crap. The (in)famous XML bug in 0.7 reinforced that opinion. I really didn't think that the bug would get fixed with any sort of alacrity, considering that the OS X Firebird "nightlies" were more like "monthlies."

To my surprise, Version Tracker reported to me that Firebird 0.7.1 was available and had the fix. I downloaded, and haven't been happier in a long time. If you haven't tried Firebird, you should. After 2 days, i've been completely satisfied with it as my default browser. It is both faster and more lightweight than the Mozilla Suite, and with the help of a few plug-ins and some time copying over my MIME settings, it has scratched all of my web browsing itches thus far.

Since when is litigation a growth industry?

This is the quote of the day:

"BayStar Capital looks to invest in growth-oriented firms with strong management, substantial market opportunity and solid, comprehensive business plans, and we believe that all of those fundamentals are in place for SCO to succeed," said Lawrence Goldfarb, a BayStar general partner.

This is apparently Goldfarb's justification for funding SCO's strategy of litigating everyone who uses Unix.

Mr. Goldfarb: You must be a lawyer, otherwise you would understand that lawyers do not create products. Lawsuits do not generate revenue for companies, nor do they increase marketshare. They do not make a company's products better. They, in short, do not contribute in any way to a growing healthy economy.

Lawsuits are used to redress wrongs, and to establish a company's rights to do certain things. SCO has no marketshare, no sales, and no product worth buying, nor do they, as has been amply proven with the evidence shown thus far, have any wrongs to redress. For you to say that they are "growth-oriented" and "have a strong business plan," is tantamount to saying, "We believe that we can profit from SCO's strategy of litigating other market players."

You, Mr. Goldfarb, are a thus a parasite. You are not investing your clients' money in order to provide capital to a growth business; you are engaged in risky speculation on the outcome of several lawsuits, any one of which could put your clients' $50M in the hands of IBM, RedHat or a later comer to the field if SCO loses. Sooner or later, you will be called to account for that. If I were one of your clients, it would be sooner.

In my Dock...

As usual, I'm a bit behind on the times. I'm just getting around to my response to the O'Reilly "What's on your Dock?" question.

Before I go down the list here, I'll confess that I have a love-hate relationship with the Dock. It is terribly useful in some ways, and terribly broken in others. After years of thought on the subject (I've used OS X regularly since the PB days), I've come to the conclusion that the Dock is only broken for power users. Therefore, the Dock's design choices were well made. The poor design decision came in not providing an "Advanced Dock" for the rest of us.

Many developers have tried to provide just that replacement. I've tried most of them. They all suck. End of story. Drop Drawers was probably the nicest of them all, but suffered some strange limitations with the UI. DragThing was a fscking nightmare - I spent half my time fighting its obtuse theming system and a preferences pane that was designed by the Marquis himself.

Since Steve Gehrman added a shelf to Path Finder, I've used that exclusively. It can't really replace the Dock, but it works well to shore up some of the Dock's deficiencies. Its an odd sort of workflow environment, but it works for me.

But I digress. On to the Dock. I prefer Dock on the right, always shown, with bottom pinning. So, from top to bottom, we have Finder, Path Finder, Terminal, Mailsmith, iCal, Address Book, Mozilla 1.5, Safari, NetNewsWire Lite, BBEdit 7, iTunes, System Preferences, Fire, WeatherMan X, OmniOutliner, Photoshop 7, Codewarrior, and SpamSieve.

I'll talk more about each of these below.

So lets go through these in detail.

Path Finder 3: Absolutely essential. With the exception of few issues, mainly relating to the new Terminal code added for version 3, and the handling of AFP mounted servers, Steve has covered most of the glaring problems in PF 2. He's very responsive to feedback, and timely in getting updates out. I didn't realize how much I relied on PF until I sat down at Sarah's computer (which is sans PF).

Terminal: Who doesn't need Terminal. The Terminal is your friend. I'd use Path Finder's terminal, but the terminal emulation is bad fscked, something Steve tells me is a function of the code he borrowed to write it. He says it'll get better soon. I believe him.

Mailsmith 2: Until a month ago, this slot was occupied by Eudora. My trials and travails with finding the perfect email client is the subject for another post, but Eudora was fast beginning to not cut the mustard. Mailsmith was the only serious contender, but my fear of storing my mail in a database and my amusingly frustrating experiences with Mailsmith 1.5 kept me away for some time. While Bare Bones has made a lot of improvements in Mailsmith 2.0, you're still stuck with a huge database for your mail (although Rich Siegel is quick to point out that there is one database per mailbox), and the damned thing is still as slow as molasses, especially with large mailboxes. The promise of a higher degree of automation lured me in, and thus far I've been reasonably pleased with it. The tech support is good, and I expect that Bare Bones will continue to make leaps and bounds in their progress on Mailsmith, whereas Eudora's development has been largely stagnant for two years.

iCal and Address Book: I use them because Palm Desktop sucks. (And Mailsmith integrates with the Address Book) End of story.

Mozilla: Really wish I could use Firebird. There is a really annoying bug that kills Firebird's usefulness on the Mac. That, and the nightly builds for Firebird stopped in July. WTF?

Safari: Great browser, except for the fact that it doesn't even match IE for cookie management. WTF?

NetNewsWire Lite: Tried the full version. Kept crapping out with XML-RPC randomly when trying to access my blogs. I'll probably send Brent Simmons some money, just because I feel his pain about email clients (and because I posted with just my first name to his comments. Doh.)

BBEdit: Because it doesn't suck. Enough said. Though I wish I could get it integrated with Project Builder better.

iTunes: Cause there is no other choice. (Is Audion even around anymore?)

System Preferences: Because I spazzed the last time I tried to not have it in my Dock.

Fire: Despite a UI that only a mother could love, it still rocks. I still owe Nick Kocharhook some code to make Fire respect IC's prefs.

WeatherMan X: Honestly, I don't know why I bother. It sucks, hard. The author is unresponsive. It spams my logs with RealBasic debug messages. The only reason its still there is because Meteorologist is a dead project and WeatherPop clutters my menubar. I realize most people would prefer it there, but I'm lacking menubar real estate right now.

OmniOutliner: Keeps me organized. Well worth the paltry sum for it.

Photoshop: Because it keeps me fed

Codewarrior: I should probably move this into my Path Finder shelf along next to Project Builder. I no longer remember why its in the Dock.

SpamSieve: Because Michael Tsai is my hero. (99% accuracy. Woot!)

Other apps I use regularly that sit in my PF shelf instead of the Dock: OmniGraffle, Project/Interface Builder, Acrobat Reader, XChat, OpenOffice, X11, Stuffit Expander, HexEdit, PGP, and GraphicConverter.

I think that's enough for now. I may get on a tear later about how all email clients suck. I may not.