Talk:Haxie

From Wikipedia, the free encyclopedia

	This article is part of WikiProject Macintosh. This means that the WikiProject has identified it as an article pertaining to the Macintosh, but is not currently working to improve it. WikiProject Macintosh itself is an attempt to improve, grow, standardize, and attain featured status for Wikipedia's articles related to Macintosh and Apple Inc. We need all your help, so join in today!
???	This article has not yet received a rating on the assessment scale.

If someone wants to discuss the security issues involved (real or imagined), then please make it relevant to the current discussion or create a new section on it. Don't just add something about task_for_pid() which hasn't been shown to apply to Application Enhancer-based Haxies and can't apply to InputManager-based ones. The task_for_pid() change in 10.4.4 hasn't even been shown to be related to security at all since InputManagers still work and the "Haxie" moniker if often incorrectly attributed to InputManagers like Saft as well.

Remember, APE-based Haxies do not use mach_inject or any piece of mach_star.

• Even if APE does not use the injection mechanism broken by 10.4.4 (which I doubt very much), as the article already says "haxies" has become a generic term for Mac OS X hacks and that certainly includes the mach_ variety. How do we go about getting conflict resolution here? (I apologize for that last revert; I didn't realize you'd opened up Talk on this). My thinking here is primarily that Apple has weighed in on the practice of patching code on Mac OS X; they dislike it enough that they have disabled one of the main systems used for it. I really feel this should be reflected somehow in the article, especially given the now-generic meaning of haxie. --Steven Fisher 22:07, 19 April 2006 (UTC)

If you expand haxie to mean everything, that would include InputManager hacks as well, which task_for_pid() definitely does not apply to. This makes it even harder to add to the general article as-is. The other issue is the placement for such a statement. Originally it was placed directly after a statement about APE when the task_for_pid() isn't necessarily related to APE. The close proximity implies the two statements are related.

Additionally, what evidence directly supports the idea that task_for_pid() was disabled due to such injection methods? Yes, task_for_pid() had restrictions placed on it. Yes, some methods (but not all) for injecting use task_for_pid(). Are these two facts at all related? Or is it easier to believe that apple went overboard in making sure the x86 side of things were locked down due to an inherent problem in the x86 security? For instance, Apple enforces the NX/XD bit on x86, it enforces a non-executable stack, and it's restricted task_for_pid(). Yet none of these are enforced on the PPC side of things. The task_for_pid() "lockdown" could be completely unrelated to injecting without actual documented reasoning as to why Apple did it from someone at Apple that made the decision to restrict the call. --68.15.179.160 12:27, 21 April 2006 (UTC)

• You've convinced me. --Steven Fisher 16:02, 21 April 2006 (UTC)

• The latest revision by Gary that tries to be vendor neutral appears to fail miserably by making the article irrelevant to today's usage. There was no citation to show an example of the term "Haxie" being used for computing utilities before Unsanity coined the term. In fact, searching Google shows a page full of references to Unsanity and pages using the Unsanity definition. Even PC Mag's definition of the term is identical to Unsanity's. I've yet to find any reference to Unix/VAX on these sites. Removing the vendor names from the controversy section makes the section seem irrelevant to the current use of the term "haxie". Furthermore, Control Panels, System Extensions, and ResEdit were never referred to as haxies before Unsanity coined the term. Even afterwards, this was the first time I had ever seen "haxie" refer to those. 68.15.179.160 02:39, 3 May 2006 (UTC)

[edit] Wikipedia is not an advertisment for Unsanity

It seems to me that someone is inserting ad copy for Unsanity here. There is a statement that people who say that haxies cause problems have deficiencies in their logic and are simply succumbing to the correlation implies causation (cum hoc ergo propter hoc) fallacy. This exact phrase is straight from Unsanity's FAQ here and is a spurious statement. I'm not familiar with the technical issues involved, but Wikipedia should not state that people who think that haxies cause problems are using poor logic when it may be a matter of opinion or of the differing knowledge of people. I'm going to remove that.

It already says "POSSIBLE cause" (my caps) of problems so I'm removing "whether they are or not" wording.

The "Intel-based Macintoshes" section also looks a bit like an ad for Unsanity products, but I might wait for someone else to comment before I remove it.

There are comments linked to about a Divx bug. First Divx people say there are crash reports, and "in the meantime" that Divx is incompatible with one haxie. Then there's a comment that they've fixed some crashing problems, but nothing at all that says it has anything to do with the haxie issue, nor do they retract the statement that the haxie is incompatible. I'm removing that. Also it's one example of one bug, which isn't really something for Wikipedia. --Howdybob 04:55, 20 June 2006 (UTC)

If you're not familiar with the technical issues, then why are you editing this page to remove examples of DivX using haxies as a scapegoat for a bug in their code? They also deleted their forum posts about the issue and Version Tracker was the only remaining place of them publicly blaming haxies and then retracting it later which was the reason I chose those two links. Conversely, do you have any examples of haxies being an actual cause of a problem? --TheWhiteCrowsShadow 23:59, 27 June 2006 (UTC)

[edit] Stupidest Term Ever

"Haxie" is such a lame word to use for "Mac OS X hack" and the article pretty much admits it's mostly just Unsanity that uses the term. So far the term has NOT caught on, and I just hope it never does. (Corby 05:12, 13 August 2006 (UTC))

Well, there aren't very many Mac OS X hacks. So far, all the software-based ones I've seen are called haxies, and the hardware-related ones are called hacks. --M1ss1ontomars2k4 ^{(T | C | @)} 04:50, 19 December 2006 (UTC)

I agree with Corby; it is not universally used. I've reworked the text slightly to emphasize that it's Unsanity's term. 68.34.156.186 03:31, 25 March 2007 (UTC)