[Eugene]

Originally Posted by Brad I Eugene.

Way to ignore the question...

You've been pooping on Haxies for the longest time, so there must be a reason.

[alcimedes]

his first love was a haxxie. she dumped him for a mod. he's been bitter ever since.

[Kickaha]

Originally Posted by Eugene Way to ignore the question... You've been pooping on Haxies for the longest time, so there must be a reason.

So that's why they're shitty.

It's Brad's fault! I *KNEW* it!

[Brad]

I warn people about Haxies for the same reason I warn people about using Norton software or about clicking attachments in Outlook Express for Windows or about having wild sex orgies. You don't have to have a horrible experience first-hand to know that something can lead to trouble. When you've heard enough incidents from other folks, you pick up the hint that maybe you should treat certain things with kid gloves.

Yeah, it's not an air-tight argument that Haxies are the root of all evil, but I don't claim that they are. I'm just saying that there are some things, Haxies in particular, that you should be extra careful about. Even Apple says so:

You may experience unexpected results if you have installed third-party system software modifications, or if you have modified the operating system through other means. This precautionary statement does not apply to the normal installation of application software.

I think that that even you'd agree that the use of Haxies, by their very nature, can not be considered "normal installation of application software." I'm sure a number of people don't realize this, though, and could use a reminder from time to time. Complacency can kill.

I have never had a single quirky update until this one. Even here it's of very minor consequence and isn't destructive in any way. I take some simple steps to minimize the chance that things will go awry and to this day I still have had zero noteworthy problems. Things may change in the future and there may be new factors to take into account, but so far I think I'm par for the course.

[Eugene]

Originally Posted by Brad Even Apple says so:

Ahh, so it's the Kool-Aid. ...But it wasnt a Haxie that caused HDDs to be wiped after people updated iTunes. It was a harmless QuickTime plugin that caused Office X instability. It wasn't a haxie that caused sleeping problems on single processor G5s either.

Saying Haxies may "wreak hellish havoc" on system updates is not par for the course. It's not technically false, but neither is pointing out that system updates may wreak hellish havoc on system updates...

You just seem to have a sanguine disdain for Haxies, and I don't see any good reason for it. Panther labels is an abomination that requires horizontal precision when navigating the menu. Labels X fixes that. Windowshade X is such a natural extension of OS X, I forget it's not installed on every machine. Maybe I'm complacent, but all these Haxies are incredibly useful, stable and inexpensive. I'll take user feedback over generic Apple warnings any day.

I'd still like a concrete example (extra points for an issue that can only be resolved by complete removal of the Haxie.)

[BuonRotto]

Perhaps it would be fair to add, "have you installed any hardware drivers or any software that asked for your admin password?" Haxies can FUBAR a system just as well as anything that alters the System folder. A kernel extension, a piece of the CoreFoundation framework, they're all primary suspects if something apparently affects the system. I think it's fair to throw up that warning right off the bat as a first guess because, while it's a first guess, it's an educated one. They're all talking about changes to the same general area of the system.

[Brad]

No Kool-Aid here. I'm plenty aware of Apple's own flaws with updates. I didn't try to defend Apple in any way; I simply pointed out that they have a warning on the update KBase page not unlike what I'm saying.

I think BuonRotto has the right idea. People need to be informed that if they change the core system, regardless of the method, they risk seriously mucking something up later. Sure, people ran around caring nothing about the sanctity of a clean System Folder back before we had Mac OS X, but those were different days too. To fall back upon those old habits would be to invite all of the weird errors and instabilities back into our relatively problem-free Macs today.

[Eugene]

Apple's warning is generic while your bullet-point singled out Haxies and other APE plugins, which is odd to me. I'm venturing off-topic, but this isn't the first time you've berated Haxies so publicly.

Uninstall (not just disable) any "haxies" and the APE framework. These are known to wreak hellish havoc with system updates. Remove any themes or other global system-modifiers.

This sounds more like a command than a warning.


Something you said a couple of rounds ago:

Funny you mention this, but I take great effort to avoid Unsanity products and discourage others from using them because of the very way that haxies and anything that uses the APE framework work. Sure, Unsanity's developers make glorious claims about testing things thoroughly and how rare it is for people to have problems, but that doesn't change the fact that APE works the same way that extensions worked back in the Classic Mac OS days. APE uses unsupported procedures to violate protected memory, inject its own code into programs at launch time, and arbitrarily execute that code outside of the programs at any time. Please go back and reread that last sentence again.

That's what I call being selectively paranoid. Do you have third-party QuickTime plugins installed? Do you have WireTap installed? Do you have other third-party kernel extensions installed? Did the Unsanity developers eat your first-born?

I'm guess part of the problem is you just can't get over the term "Haxie."

[Kickaha]

Actually, I'm not quite as gungho against haxies as Brad, but their very nature on how they work means that they have the opportunity to do Very Bad Things.

QT plugins? WireTap? 3rd party kernel extensions? They all use established APIs provided by Apple for the purpose of extending functionality. APE puts it's hands deep into the guts of the system and mucks directly with things that Apple didn't intend to be mucked with.

That's the difference, and that's why APE is problematic, and can be horrendously so... Apple isn't going to test against it, while they *will* test for ensuring that API-supported extensions will continue to work and not do disastrous things by accident.

[Eugene]

Originally Posted by Kickaha A ... WireTap? 3rd party kernel extensions? They all use established APIs provided by Apple for the purpose of extending functionality.

Have you audited Ambrosia's WireTap source? You seem so sure. Clearly plugins derived from established APIs are immune to instability problems...

That's the difference, and that's why APE is problematic, and can be horrendously so... Apple isn't going to test against it, while they *will* test for ensuring that API-supported extensions will continue to work and not do disastrous things by accident.

Just because something has the .kext suffix, doesn't mean it stays strictly within the bounds of an Apple API. Sure, APE is theoretically dangerous...what isn't? I'm still waiting for hard evidence of a Haxie doing something, anything even mildly annoying to an Apple software update. If anybody has proof APE plugins are more trouble than they're worth, lay it out on the table.

[Kickaha]

WireTap uses CoreAudio.

.kexts aren't loaded at a time when they can step into the Core* libraries like APE does.

APIs are there for a reason. APE does something rather cool, from a techie standpoint, but it also means that the smallest bug in any APE extension can bring down your entire system. No other extensions can do that, with the exception of .kexts that are loaded directly into the kernel, and even those are subject to many restrictions.

APE is essentially a throwback to the old Mac Classic extensions model... dive in and start mucking directly with things that weren't designed to be. When those things behind the scenes get updated/changed/modified, results are unpredictable at best.

Flip it around - prove that APE plugins are worth more than their trouble. I've had a mixed experience with them. Couple of them I liked, but I had unexplained instabilities that went away when I uninstalled APE. *shrug*

Like I said, I don't have Brad's position on haxies, but I also am 110% positive that from a strictly factual technical point of view, they are much *more likely* to cause problems than any other kind of extension that uses Apple APIs. Period.

[Eugene]

Originally Posted by Kickaha WireTap uses CoreAudio. .kexts aren't loaded at a time when they can step into the Core* libraries like APE does.

Yup, because Wiretap steps in right away...

As you mention here:

No other extensions can do that, with the exception of .kexts that are loaded directly into the kernel, and even those are subject to many restrictions.

So restrictions directly translate into stability?

Flip it around - prove that APE plugins are worth more than their trouble. I've had a mixed experience with them. Couple of them I liked, but I had unexplained instabilities that went away when I uninstalled APE. *shrug*

Ah, so we have phantom instability...probably not reproducible. That's convenient and of course impossible disprove. I find Windowshade X fills a void. Labels X helps me avoid the abomination that is Panther labels. Audio Hijack is far more extensible than Wiretap.

Like I said, I don't have Brad's position on haxies, but I also am 110% positive that from a strictly factual technical point of view, they are much *more likely* to cause problems than any other kind of extension that uses Apple APIs. Period.

Given no prior experience with Haxies, I might be inclined to agree with that assumption, but the complete lack of any concrete evidence suggests Haxies are better tested against changes to system software than less "suspicious" culprits.

[BarracksSi]

Originally Posted by Kickaha ... but I had unexplained instabilities that went away when I uninstalled APE. *shrug*

So did I, actually. I had only one or two things going through APE, but there were a few things that behaved a little oddly. So, I got rid of it, and everything went back to normal.

Back in OS9, Kaleidoscope never worked as smoothly as I would have liked, either. I'm pretty much done with hacks & modifications like that, and I don't feel like I'm missing anything.

[Kickaha]

Originally Posted by Eugene Yup, because Wiretap steps in right away...

Using an established API for the purpose...

So restrictions directly translate into stability?

No, restrictions mean fewer things to possibly be an error source.

Ah, so we have phantom instability...probably not reproducible. That's convenient and of course impossible (to) disprove.

You and Brad are the only two involved in a prove/disprove war, bud. Leave me out of that.

I find Windowshade X fills a void. Labels X helps me avoid the abomination that is Panther labels. Audio Hijack is far more extensible than Wiretap.

Good for you. Glad you find them useful.

Given no prior experience with Haxies, I might be inclined to agree with that assumption, but the complete lack of any concrete evidence suggests Haxies are better tested against changes to system software than less "suspicious" culprits.

It's not an assumption, it's a fact of the engineering realities, sorry. Apple can test their APIs against a plethora of apps that use those APIs. They cannot, and should not, be testing against apps that are running through the backdoor to flip switches behind their backs. The Unsanity folks keep APE running, and that's great for them and their users, but the fact is that if a developer sticks with the established APIs, they gain a huge amount of testing of code direct from Apple. If they go their own route, they are the sole testing body, as is the case with APE. The probabilities are simply against them, and their users. Bully for you if they've gone your way.

You want to argue absolutes, take it up with someone else.

[Eugene]

Originally Posted by Kickaha You want to argue absolutes, take it up with someone else.

I want to argue reality, not some textbook "what-if." Let me tell you, I would love to believe there's some magic Apple API that can be leveraged as little or as much as you want to create immaculately stable software. To me software isn't demonstrably stable just because it contains Apple sanctioned code snippets (Which I'm sure even Unsanity's stuff does) among thousands of other lines of code. Likewise it isn't unstable just because it rubs people the wrong way.

I could probably just blame my crashes on any piece of closed software...

[Kickaha]

You're still not getting it.

Apple API code is tested for external use. That's its entire purpose in life.

Internals are not tested for external use. They aren't supposed to be.

Calling the latter directly is inherently riskier than the former, even if the calling code is 100% correct. Apple can change the internals all they want, and the calling code will break, wreak havoc, or just plain go haywire, and that is utterly and completely not Apple's fault.

An API is a contract: "Use this API, and we will ensure that it works. Step outside this code, and you're on your own." Unsanity goes outside that contract, and consequently has to deal with a much larger testing problem... one that they as a small company simply aren't really set up for, since they can't possibly be testing it against Apple's internal code. The best they can do is poke at it repeatedly and see if they can find any anomalies. The technical term for this is 'ass-backwards'.

It's simply a matter of probabilities: code that uses Apple's APIs will leverage Apple's testing of those APIs. The developer doesn't have to test the internals of that code, Apple has done it. Code that steps around that API to muck with internals directly has to test against *all* the internals of the code... which is a task larger than a small shop like Unsanity is set up for. The chances of something being a bit off and being missed by their testing is greater simply because the amount of testing is greater. How is this not clear?

Not to mention that updates don't alter APIs without a lot of forewarning, but they can change the internals in multiple and subtle ways at a whim... suddenly that testing job gets expanded manyfold.

Haxies are, by their very nature, riskier code to run because they simply cannot be as thoroughly tested as counterparts that use Apple APIs. The developer doesn't have the code to the internals they're accessing to test directly, so the best they can do is the 'wait and see' approach. That's the reality, not a textbook 'what-if'.

Now, to all of that, add the fact that a bug in code that calls Apple APIs is firewalled from the internals of the system - there are only so many ways one can inject bad data back to the system, and Apple can monitor each of those, adding tests to ensure good data or reject bad. Haxies short-circuit that, and can toss bad data directly into the machinery of your system. A bug in a haxie can suddenly cause a much larger problem than the same bug in API-calling code.

Is it an absolute that it will? No. Is it an absolute that it will not? No. Are the odds greater that a bug can happen, and if it does, can cause bad problems deep in the system that will be extremely hard to diagnose? You bet. That's my only assertion here, and it's one I can back up with technical data.

I think it's a testament to the ability of the folks at Unsanity that their products are as stable as they are - they've gone outside the bounds of what most developers will attempt, and pulled it off admirably... but that doesn't change the reality that a haxie is riskier code to run. No one's perfect, and by taking the path they have, they've made the possible consequences of their most minor errors much larger in magnitude.

There is no magic API. There is no magic code. Stop making silly statements to create strawmen. You want a holy war, find another target, I'm done.

[Eugene]

Of course you're done. You're predicating everything on the outside chance of something happening, even though there are tons of other ways to render your system unusable. If a Haxie really is responsible for a system software update snafu, I'll be the first to know. I'll revert to my latest back-up an dbe on my merry way.

Until then you're basically engaging in scare tactics, but yes, you're less caught up in it than Brad...

[Kickaha]

Originally Posted by Eugene Of course you're done. You're predicating everything on the outside chance of something happening, even though there are tons of other ways to render your system unusable.

I can only assume you've never done any risk analysis or, for that matter, programming. Whatever. Your logic is flawed, Eugene, and you're still completely missing the point, so I give up. There's a reason I used the phrase 'holy war'. You have a rather extreme belief built entirely on faith, and no room for countering facts or even probabilities. I may as well try and discuss evolution with a creationist at this point. You and Brad have fun.

[Eugene]

Originally Posted by Kickaha I can only assume you've never done any risk analysis or, for that matter, programming. Whatever. Your logic is flawed, Eugene, and you're still completely missing the point, so I give up. There's a reason I used the phrase 'holy war'. You have a belief built entirely on faith, and no facts or basis in even probabilities. I may as well try and discuss evolution with a creationist at this point. You and Brad have fun.

I have no more faith in Haxies than I do in any software I haven't audited. You seem to have faith in Apple and other developers to write bug-free code as long as they adhere to all the self-imposed rules. Unsanity's track record is pretty damned clean right now, and when my installation does spontaneously shit itself after an update, I'll revert back to my back-up and raise you a pint. That's not faith.

I thought you were done.

[alcimedes]

WTF are you guys talking about?

i would say that APE can cause problems, much like any software. however, since it's making undocumented calls, it's a hell of a lot harder to troubleshoot/prove. all you'll get is anecdotal evidence i guess. some people who have had no problems vs. people who've been burned.

however, i would say that people (like myself) who work supporting Mac users are more likely to see the possible outcomes of installing various hacks to the OS and the GUI than any one individual user.

if one of my users is having a stability problem, my experience has taught me to look into APE problems first (assuming no RAM has been added to the system recently). i swear between APE and bad RAM, i could account for over 75% of kernal panics i've seen on OSX.

[Eugene]

Originally Posted by alcimedes if one of my users is having a stability problem, my experience has taught me to look into APE problems first (assuming no RAM has been added to the system recently). i swear between APE and bad RAM, i could account for over 75% of kernal panics i've seen on OSX.

For kernel panics, the panic.log usually tells you juicy stuff.

I tend to look at the installer receipts second, to see what was installed most recently (with particular interest in kernel extensions and unix daemons). But yes, I also look at APE and its plugins too because they're so ridiculously easy to 1) disable and 2) uninstall.

My live panic.log . Notice Ambrosia's Wiretap KExt is the culprit in the last couple of kernel panics. I have never once seen aped in a kernel backtrace. I invite everybody to share their up-to-date panic.logs. It'll be interesting and fun to see what software bites us in the ass the most as a group. I've had 5 since installing Panther. The first three were directly related to M-Audio's sound card drivers, the last two occurred while using Snapz Pro X 2. We can also crown the person with the most panics since upgrading to Panther the KP King!

The last time a Haxie did adversely affect my set-up, WindowShade X 2.1 caused Toast Titanium 5.1.4 to crash immediately. It was fixed as fast as it was discovered. That was eons ago, and of course it is not a damnable offense such as wiping your mounted volumes clean due to shoddy shell scripting or other various programming offenses.

[curiousuburb]

Originally Posted by babbage from Alcimedes 'talking' link above: Skim the first dozen or so hits on Google for a string like '/Library/Frameworks/ApplicationEnhancer.framework' and most of them will be crash log reports. Actually, of the top 17 hits this string currently returns, at least a dozen seem to be crash reports -- either KERN_INVALID_ADDRESS or KERN_PROTECTION_FAILURE, which is supposedly "impossible", and yet there it is -- and every single one ends the report with a call to /Library/Frameworks/ApplicationEnhancer.framework/Versions/A/ApplicationEnhancer. All these people are desperately trying to figure out what's wrong with their software: Apple Remote Desktop, Mozilla, VooDooPad, Inquisitor, Books, hudakX2.3.0, Camino (two different people reporting errors), ThemePark (two people again), Safari, NeoOfficeJ (two people yet again), XDarwin, etc. Of course, nothing is wrong with these applications: the problem in every case is that the person has ApplicationEnhancer installed. Don't take my word for it -- search Google for yourself and see.

*checks Google*

[DMBand0026]

For what it's worth, 10.3.6 installed on my 12" PB. It's still as dreamy as the day I brought OS X home so many years ago.

[Eugene]

Originally Posted by curiousuburb *checks Google*

You do realize that anybody who has installed APE will have that line appear near the bottom of any crash report regardless of whether the crash was caused by the framework or not. The only reason why it appears last is because that's when it's loaded when you start up the app.

Case in point, on a machine with Haxies installed, load http://cbs.sportsline.com/nfl in Safari. It will crash. Now load it again on a machine without Haxies installed. Check the crash logs and it'll show the APE framework at the bottom of one report (or a DivX support file if you have that installed) , but not the other.

So was APE responsible for one crash but not the other? I don't know about you, but I'm pretty sure the crash was caused by something else. For those of you who have never had any Haxies installed, do a "grep -r KERN_PROTECTION_FAILURE ~/Library/Logs/CrashReporter/" It appears all the time, regardless of whether you have Haxies installed or not. It's precisely Babbage's moronic 'evidence' that I want to squelch.

[curiousuburb]

For the first time in ages, I've been chasing a bug that seems to be popping up for a few weeks on 10.3.6. (On an old iBook500 w/384MB RAM if you're wondering.)

Mail would bork with error messages of 'server unreachable on port 110'.
Safari would start reporting site not found. One minute fine, the next unreachable.

Further research showed my DHCP getting reassigned to an internal 169.xxx.xxx.xxx range after a few minutes of operation... repeatable problem at intermittent intervals, sometimes with no activity between success and subsequent failure.

Reboot. Fine for a minute or two, mail sends/receives fine... AN opens... then whap... DHCP thinks its 169.xxx.xxx.xxx

Replaced my cablemodem. Changed wall sockets in case low voltage caused it to wig out. Releasing and renewing DHCP lease would more often than not get me a self-assigned 169 range rather than the 24 range from my cable ISP...

After nearly tearing out more hair, finally got onto Apple's discussion lists and discovered at least 6 threads detailing similar 'DHCP reset' or 'IP reset' or 'Mail losing SMTP'...

Various machines, some from sleep, some from restart, some from no visible cause, but the symptoms seem to centre around a common theme...

Everybody who seems to be reporting these symptoms has at least _10.3.5 and applied the 9/30 security update_. 10.3.4 users and those without the security update seem not to have reported these problems.

One of the techs I talked to suggested that a workaround was to fill in the optional "DHCP client id" box in the network panel, which apparently solved a similar issue in Jaguar.

Not sure if anybody else has similar issues with their cablemodem's DHCP, but thought it might be worth adding to the infostream as it may alter the "number of updates since something got worse".

First time I've seriously considered downgrading OS X.
10.3.4 or 10.3.5 (but without the 9/30 SecUpdate) may be recommended.

Anybody else had these issues?

[No Haxies, either.]

[kafelatte]

Originally Posted by curiousuburb For the first time in ages, I've been chasing a bug that seems to be popping up for a few weeks on 10.3.6

You are not by any chance running VPN software? I found I had the same problem after the previous OS update, and armed with the string from my log, found a post on slash.dot pointing me right to my VPN software (Apani). Updated that, and all those symptoms (much the same as yours) disappeared.

I so miss the days of being able to kill all third party extensions with ease.

[Kickaha]

Just like in 9, hold down Shift on boot. Voila. Just the core OS gets loaded.