Subscribe to
Posts
Comments
NSLog(); Header Image

On Drunken Haxies

The fellow over at "business on the mac" sums up my thoughts on haxies quite well. While I too generally respect the Drunken Comic Book Figure, I too disagreed vehemently with him on this topic. As the author there says, "DB's obviously never developed, sold and supported a consumer software product…"

I still run a haxie-free system because I don't care for the odd crashes it generates. Were I not a developer, I too might attribute them to the software I happened to be using at the time and not the haxie. But I know better…

P.S. Yes, BBEdit's dialog could be written in a friendlier fashion. But if that's honestly DB's only concern, he has not represented it well at all.

7 Responses to "On Drunken Haxies"

  1. I think the point that everyone is missing is that occasionally haxies EXPOSE a bug in another product. This bug may only appear when you are running haxies, but that doesn't make it a haxie bug! If this is the case, telling a user to just disable haxies appears to solve the problem, but actually just masks it.

    I would rather both groups work together to find the issue before assigning blame.

  2. Haxies don't expose jack shit. If a bug does not occur without a haxie present, it's not a bug. Haxies alter the OS and the way in which an application uses resources, the OS, frameworks, network connections, etc. It doesn't "expose" anything, nor does it exacerbate anything. Code that has no bugs can fail due to a haxie.

    You're wrong, and people aren't missing the point.

  3. I should apologize about the statement "may only appear when you are running haxies". I meant to say, "may appear more frequently when running haxies".

    I would swear I saw DB state an issue that was exacerbated with a haxie, but where the actual issue was a product issue, not a haxie bug. That is the case I am talking about. Aha, I found it:

    For the most part, ShapeShifter just swaps graphics with no slowdown (sometimes feels faster), however if something is a custom view (like the labels field in the Finders contextual menu) there can be a miniscule hit -- as in imperceptible unless you counting milliseconds while profiling. It just shouldn't have been happening, so it was weird, so I was curious.I contacted the author, which didn't go well at first once he heard APE was involved, but a few samples later and a bug was found in the date formatting code. This bug wasn't a huge deal on its own, but ShapeShifter was exacerbating it to the point where it was extremely noticeable. The author passed on version 1.3.3b5, which fixed the issue, and I'm going to assume that version 1.3.3 which is online now has the fix in for it.

    In this particular case, there was a bug in GyzaMail that was made worse by the presence of a haxie (ShapeShifter). So, the bug was NOT in ShapeShifter, it only appeared that way.

    That is really my only point. And I do agree with this statement of yours:

    Code that has no bugs can fail due to a haxie.

    The corollary to that is: Code that has bugs may fail only when using a haxie, due to the nature of the bug. Fix the bug and the app + haxie may work much better.

  4. Based upon my own experience, the instances in which an existing bug is "made worse" by a haxie and when there is no bug but only a crash due entirely to the presence of the haxie, the latter outnumbers the former by a magnitude of three or more.

    In your example, you're not talking about a crashing bug, merely a slowdown. A bug, sure, but basically one caused because the code that causes the slowdown is negatively affected by the haxie.

  5. As long as you are 100% positive that the crash is a bug in a haxie and not just "made worse" by the presence of a haxie, I completely agree with you.

  6. Additionally, a bug - even in the application itself - that does not exist without the haxie but which appears with the haxie is not really a bug, either, nor is it worth any of the developer's time.

    And don't get me started on the ability of APE to allow for rampant (and easy) piracy.

  7. Although without APE, there is still mach_inject (http://rentzsch.com/mach_inject/)