35% off Dell's Most Popular Laptops
Crashing (especially Safari)? Remove Input Managers first!
[Published Friday, July 6th]
A recent cartoon in The New Yorker shows a doctor telling his patient: "Sure, it's a routine procedure, if you routinely have someone slice you open with sharp instruments and then fiddle with your insides." Pretty funny, eh? Who would "routinely" permit that? Yet MacFixIt readers do routinely do something analogous to applications that they depend on - and then they wonder why those applications are behaving oddly.
We here at a MacFixIt continue to receive email from people who are disregarding our advice about Input Managers. How many times do we have to say it? We've told you in the past here (for example), and recently here and here. And we have repeatedly referred to this article, which explains what Input Managers do. They reach right into an application and alter its code! This puts the behavior of the affected application outside the control and responsibility of its developers.
To permit that kind of thing is to revert to the confusion of Mac OS 9 and before, with its conflicting INITs and Extensions that were so difficult to manage and caused all kinds of incomprehensible crashes. If an application doesn't have a feature that you want, place a feature request with the developers, or use a different application. Don't modify the application behind the developers' back.
At their worst, Input Managers can be a massive and frightening security hole. Remember, one of these puppies can make your applications do things they were never intended to do. That's what the Oompa-Loompa trojan was all about, remember? The trojan was itself just a proof of concept, and didn't make your application's misbehave in any drastic way; but it could have, and that was the point.
Just today we received this email:
Dear Sirs:
Safari 2.0.4 freezes on Mac OS X 10.4.10 while surfing Internet. Console says:
2007-07-06 08:07:28.023 Console[1117] *** -[NSBundle load]: Error loading code /Library/InputManagers/Menu Extra Enabler/Menu Extra Enabler.bundle/Contents/MacOS/Menu Extra Enabler for bundle /Library/InputManagers/Menu Extra Enabler/Menu Extra Enabler.bundle, error code 2 (link edit error code 0, error number 0 ())
I am puzzled.
Well, stop being puzzled and try the advice we have given again and again. Stop using Input Managers. Just stop it! Locate your InputManagers folders (in your user Library directory and in the top-level /Library directory), empty them, and restart the computer. Yes, you'll lose some cute customization, but you'll gain a computer that operates with more of the stability and predictability that you expect from Mac OS X.
Resources
?%20Remove%20Input%20Managers%20first!%20%7C%20MacFixIt%20-%20CNET%20Reviews&srcUrl=http://reviews.cnet.com/8301-13727_7-10328725-263.html){kind=small}
This MacFixIt is thread is against the very essence of Mac, and essentially says, "Hey, be safe, and just use Apple software." Even Apple wouldn't condone that! Wake up MacFixIt.
Hear, hear!
I find SafariPlus cookie management indispensable.
---
Bob graham
Finally MacFixit is saying what experienced users have known all along. The VAST majority of the third party hacks are, well, hacks. They modify the software via unpublished and/or unsupported entry points or hooks. They almost always break with every update. But who do the users blame? Why the update of course. "My software worked before the update, now it doesn't." Therefore the update is at fault in their eyes. Then we get the inevitable "Doesn't Apple test their updates before they release them?!" rants, expecting Apple to make their software work with every goofy hack out there, many of which the user has long forgotten they installed.
I was also pleased to see frustration with absolutely clueless users finally vented. As a friend of mine always laments, "You can buy 'em books but all they do is tear the pages." Some people need a two-by-four smack between the eyes before they'll listen.
You've got to be kidding. Many, if not most, Input Managers are not hacks, and the hooks and methods they typically use are neither undocumented, nor unsupported. If this was the case, then Apple would not even support the implementation of an Input Manager folder to begin with. Those of you that think that Apple has provided all the functionality that you could ever want or need in it's applications as delivered are missing out on so much productivity and efficiency potential. There is absolutely nothing wrong with utilizing Input Managers, so long as you know how to use them and uninstall them as needed.
And the brutal surgical metaphor? Hardly apropos. How about a metaphor of adding a new intake or supercharger to your hot rod? IM's complement and enhance system functionality, not rip into code like a mad doctor with a chain saw. (I apologize if my automotive metaphor is difficult for these nay-sayers to understand.)
So settle down. Relax. Stop toeing the line of the arrogant and condescending Mac know-it-all zealot. Input Managers have their place, so long as they are employed with care and caution.
Apple is in fact so relax about Input Managers that they will not be supported anymore in Leopard. Because Apple knows from all the whining that those pesky Input Managers have, on a whole, a negative impact on the user experience. And Apple is tired of getting all the blame !
(Besides, Input Managers are a major security risk allowing for code injection anywhere in a software execution.)
Input Managers are supported in Leopard. I hate to break this news to you.
They will be ASKED to user "Do you want Input Manager Functionality or NOT" since it happens that Input Manager hating type of people have also coded couple of trojans to prove their point. :)
It will be just like "Startup Permissions" dialogue. There are screenshots all over the web.
Also what if they disable the input manager function? Oh well, that means we will be back to 1985 on Apple and I will happily use my Tiger OS until it is completely unsupported and move to Windows which does have TASKBAR, a horrible copy of MacOS menu extra implementation. At least it exists anyway.
How about the metaphor of adding a supercharger to your engine that is improperly sized and designed and blows the engine! It is not that superchargers or turbochargers are bad per. se. but improper engineering can be destructive to the entire engine. Not to mention the cumulative effects of users that pile modification on modification. A supercharger feeding into a turbocharger for instance. Even if they are individually well designed the combination could be lethal to the health of the system.
The same is true with input managers, they are not bad per se, but improperly designed they can cause more harm than good. All too often the designers of these products are not that good and very few if any have anywhere near the resources available that are necessary for thorough testing. And not even Microsoft (ptooey) has the resources for testing all possible combinations of hardware and software modifications.
---
____________
[color:#009999] joemikeb [/color]: MacFixit Forums Moderator
"You've got to be kidding. Many, if not most, Input Managers are not hacks, and the hooks and methods they typically use are neither undocumented, nor unsupported. If this was the case, then Apple would not even support the implementation of an Input Manager folder to begin with."
How many Input Managers on your system are actually extending the text input capabilities of Mac OS X?
Yeah, I thought so.
If the Input Manager is not providing you enhanced text input capabilites, it's a hack (so almost all Input Managers are hacks; I know of only one legitimate Input Manager that actually extends the Cocoa text input system). At best, these hacks are misusing a supported hook to load their code into various apps (or other parts of the OS), where they then use unsupported and/or undocumented hooks to change the behavior of the app or the OS.
In this sense, almost all Input Managers are trojan horses; they appear to be one thing (an extension to the text input system) so that the OS loads the code, but inside, once loaded, the hacks are a very different and potentially dangerous thing (something that modifies other parts of the OS or applications in unsupported and unexpected ways).
http://www.opensource.apple.com/darwinsource/
There, Darwin. It doesn't have such "cute" things, it is plain Mach with FreeBSD layer.
I think that is what some of us really wants. They should use that with X11 and enjoy the rock solid, nerd OS and leave Apple Macintosh Experience to end users which made the OS X the most successful Unix-like Desktop operating system ever.
Apple will never code a nerd OS. They are coding for average people and their solution to input manager problem (!) is this: "Are you sure you want to enable Menu Extra functions?" prompt. No, Unsanity people or other Input manager coders aren't going to jail I am afraid!
Also to "technical" people who tries to get rid of menu extras by coding trojans, trying lame campaigns such as Versiontracker comment trolling, misinformation distributing, helping MOAB guys: Get a life will you?
In fact we shouldn't change our wallpaper too. It may effect OS stability since we are downloading new pictures, Wallpaper caches created etc. :)
This MacFixIt is thread is against the very essence of Mac, and essentially says, "Hey, be safe, and just use Apple software." Even Apple wouldn't condone that! Wake up MacFixIt.
No. This advice does not say "just use Apple software." The advice does not tell you not to use third-party software; it tells you not to use a special kind of third-party software that modifies Apple programs in unpredictable and sometimes unsupported ways. There's a difference.
I have no problem with input managers per se, as long as the users who like them take responsibility. The problem here is a problem of responsibility.
People have an unfortunate habit of not thinking about what they do. They install hacks that modify Apple system software in weird, unsupported ways, then they get hysterical and blame Apple when changes to the system software makes things break. That's the issue.
If you want to use input managers or other unsupported software hacks, hey, that's your business. Hack your computer all you want! But don't scream and cry and bellyache when you hack your computer sixteen ways from Sunday, then Apple releases a software update and all your hacks quit working. If you hack your system, take responsibility for it. Don't run off and blame Apple for problems. That's all.
Egg-zacktly!
Pay attention to what you're doing/installing, end-users!!!
In Safari I have installed, SAFT, SafariStand, AcidSearch, PithHelmet, PicLens and Safari Plus. Each adds excellent features to Safari making it much more functional than the Apple Base version. And there is no adverse effect on Safari's operation. If Apple would add some energy toward improving the base features along the lines provided by the InputManagers, then this would not be an issue.
When Safari moved to Beta, the InputManagers needed to be updated for compatibility purposes. Anyone trying to open the Beta without updating these items will see Safari crash. That's a no-brainer. Would serve users more for Mac Fixit to encourage readers to read reviews about the particular plug-in, and "update" where appropriate instead of their suggested delete all approach.
For months I had regular crashes when trying to right-click and get new tabs
Eventually I removed Safari Extender and all was OK
Case proven - if you have Safarai crashes - try removing input magaers
Acid Search seems to be OK
SIMBL OK too
SmartCrash Reports OK
Concierge OK
MEE OK
Pith Helmet OK (but causes hassle with NetNewsWire)
A journey back through time and the MacFixit archives will reveal instances where virtually every one of your listed input managers has been diagnosed as the cause of everything from performance issues to complete failure of Safari to launch. Thus the advice to remove the input managers when there is a problem makes a lot of sense and solves a lot of inexplicable problems.
---
____________
[color:#009999] joemikeb [/color]: MacFixit Forums Moderator
Doesn't that then make it an "explicable" problem? :)
Each adds excellent features to Safari making it much more functional than the Apple Base version. And there is no adverse effect on Safari's operation.
If you want to add excellent features to your browser to make it more functional than Apple's base version without adversely affecting its operation, use Firefox.
Seriously. I understand why plain vanilla net surfers stick with a plain vanilla browser like Safari, but those who have enough initiative to download and install Input Managers really ought to be running Firefox. It's purely a matter of extensibility: Safari has none.
Probably the best approach is not to tell people not to install things, but to have a built-in troubleshooting in Safari or Mac OS X to tell the user that the crash was due to a particular application and how to report or remove it.
But again, many times the user get no feedback except the crash and even for users knowing about Console (most Mac users do not know that such a thing even exists!), it is usually so cryptic as to mean nothing about what the culprit is, let alone what to do to prevent the issue.
Perhaps we need a Conflict Catcher reborn after all in Mac OS X.
My two cents.
I remember the NEED for conflict catcher in Mac OS 9, 8, etc. One of the reasons why apple needed a more modern operating system back then, was the deadly conflicts encountered by interdependencies between various programs in an unprotected memory environment. With each system update one of the biggest conflict causers, was the INIT's (even installing simply another program within a specific Mac OS version often resulted in an INIT conflict). Although the Input Managers do not 100% mirror the problems caused by INIT's in an unprotected memory environment, they are nonetheless similar beasts. They purposely change programming code within an area of protected memory. If the correct area of protected memory is changed in a wrong way (via a badly written Input Manager, a System Update, or a Program Update) within this part of protected memory the results will be:
a: a misbehaving program
b: a program crash or failure to launch
c: or in extreme cases a Kernal Panic or failure to boot.
I am not against Input Managers, but certainly anyone wishing to use them MUST be aware that they reintroduce similar stability problems, that were once common place on the Mac Platform before Mac OS X. I remember all too well the jokes back then over the Mac's ability to crash, and crash, and crash. By the way I am not anti-Mac. It was and is my personal choice since 1984. Input Managers add both very useful features and fluff. Use them with CAUTION!
Distorted persective you say? Hooo boy... I dunno about that, if you got the volume of email I'm sure they do I doubt you'd have the same opinion. I'd say it was distorted if they said all input managers should be removed no matter what. Instead they recommend if you're crashing to try removing input managers first. Which is helpful advice too many people have ignored, they're not saying "you should never customize your mac" by any stretch of the imagination.
Bottom line: customization is fine, but suspect modifications first when problems appear rather than the update itself.
- by terryk July 6, 2007 10:06 AM PDT
- Hmmmm. Now here's an interesting thought: If everyone followed MacFixIt's advice on this particular topic to it's ultimate conclusion, removed all non-Apple modifications and software, submitted feature requests and bug reports to Apple and patiently, faithfully waited for them to produce a response...there'd be no more need for MacFixIt and their "Troubleshooting Solutions for the Macintosh" to exist. That would decrease the frustrating workload of the MacFixIt staff to...well, nothing! Quite the timesaver.
- Like this Reply to this comment
-
Showing 1 of 2 pages (36 Comments)