There's a whole bru-ha-ha going on right now on various blogs regarding
Unsanity's "
Haxies" and whether or not developers of user applications should be responsible for problems that occur for people running the haxies.
It all started apparently on
DrunkenBlog in a post entitled "
Of unintended interactions." In it, he took
BareBones, makers of
BBEdit and
TextWranger to task, mentioning that they go so far as to post a dialog essentially saying that if you are running APE and their app crashes, you're SOL. While the dialog that BareBones throws up is an interesting way to handle things, they do have a point. It's hard enough being responsible for your own code, considering the limited resources of most Mac developers, without having to worry about the system being hacked under you. Despite the cute name, "haxies" are hacks. They change the default way that the system works, in ways that can have unexpected results.
DB says at one point:
"Developers don't like debugging other's code, and are often going to be sensitive when it comes to dealing with other's software and how it may be interacting with their own"
I think that really oversimplifies the issue. It's not so much that we don't like it, it's that it's nie-impossible to debug other people's code, especially code of the nature of something that changes the base functionality of the system. Additionally, it can take a lot of time away from work on new features and real bugs, for the other probably 95% of users.
After a bit of back and forth between Rich Siegel of BareBones and DB, this followup was posted, "
Of BareBones and bias (aka, "Ho, please.")."
Again, the statement he makes:
Users are going to install things, and they're going to change the parameters under which your app is running -- whether it's a kernel extension for something Apple ships or a mouse driver.
oversimplifies things I think. Haxies aren't a matter of simply installing a mouse driver or kernel extension necessarily. Haxies can effect the the basic and fundamental usage of the system, and can effect things in ways that are hard to diagnose. Installing a mouse driver will not usually effect how, say, system windows are drawn. Trying to write code that works around these potential issues can be frustrating at best.
On the other hand, I do know what he means when he refers to "edge cases." Not all code is the cleanest of code, and shortcuts are sometimes taken, or there can be a bit of laziness on the part of developers where the code isn't 100% correct to begin with. In these cases, APE can overwrite memory that probably SHOULD be available, but isn't. In this case the issue is probably with the application developer, but still, if the system hadn't been hacked in the first place... Regardless, users do the damnedest things sometimes, and as developers we try very hard to take that into account and work with them when they have problems. He says in the post that started this whole thing that "Software interactions are a bitch, and the improbable should be checked, because it's still possible" which is true. It's always worth investigating. Sometimes though, and I think this is why BareBones does what they do, all we can do is kind of drop back and punt. I guess I can see his frustration at the dialog though, cause he sees it as BareBones almost saying "it's not us man" immediately without entertaining the possibility of it being their bug.
On the THIRD hand, I'm also guessing that BareBones has seen enough issues with interactions involving APE that they immediately assume it's NOT their problem.
Finally, "Business on the Mac" offers a
pretty good take on the whole controversy. I do like his analogy of chipping a car. If you do this, and the chip you install exceeds the built-in tolerances designed into the car, there is no WAY Audi, or BMW, etc. is going to claim responsibility for the damage done by your change. I think the same thing applies to system hacks. If an application relies on functionality as released by Apple in their APIs for something, and something else is installed that gets in the way, how can you accept responsibility for the problems?
Digg This | 
Post to del.icio.us
Because last year people asked for it, 
There are a lot of changes being worked on for future versions of MacGourmet, some of which could be significant. I'm looking for a bunch of people to join a team that can be available to test things first, and give feedback on prototypes for potential changes. There are only a couple of requirements. The first is that members 
