Rixstep
	`About \| ACP \| Buy \| Industry Watch \| Learning Curve \| News \| Products \| Search \| Substack`

Home » Learning Curve

Don't Let APE Monkey with Your System

Keep your hands off the drivers.
- Ken Thompson
Keep your hands off my operating system, motherfucker.
- Steve Jobs
APE has caused a boatload of problems within the user community.
- Bill Bumgarner

Get It

Try It

Computers and humans: it's a layered approach. At the bottom is the computer hardware and the peripherals. Then driver writers are called in to write the programmatic interface with these devices: running the hard drive, the video display, and so forth. Then comes the kernel. This kernel interfaces with the device drivers, instructing them to display things on the monitor, read and write data to the hard drive, and so forth. Another gang of programmers comes in to write the kernel. The kernel simultaneously offers an 'application programming interface' for - you guessed it - the application programmers. Who are now called in to write the applications to run on the system. Then you're ready to rock. And all you need now is the user. You. There's an implicit golden rule in creating the code for each layer in the system: you keep your hands off everybody else's code. It's just not done and any seasoned programmer with sufficient experience and wisdom knows it implicitly. It's just not done. It's tantamount to opening Pandora's box. Microsoft tried bending the rules during the browser wars. Obsessed with proving their browser was faster than Netscape they put in code that went straight past the kernel and into driver land. Strange things happened as a result. Early beta testers of IE4 noticed that if you appended a period ('.') to the end of any URL your entire system crashed. BSOD. Blue screen of death. And not on a dinky Windows 95 system either - on bulletproof Windows NT. It's not easy to bring down Windows NT - at least it wasn't back in those days - and the only way was to muck with the actual device drivers. Microsoft tried it - and paid the price. OS X is not a 'MacOS' and there are a lot of graybeards out there who just won't accept that fact. They want to be still sitting at cute harmless beige boxes that say 'hello'. But they're not cute little beige boxes anymore and they don't say 'hello' anymore and they're not harmless anymore. They're industrial grade boxes and they run a real operating system. Ken Thompson set the record straight years ago with his quote from above. If Unix represents one good thing - which it doesn't as it represents many good things - it's that each part of a system must do one and only one thing and all the other parts of the system must leave it alone. Unix has survived as long as it has and become the mainstay and the backbone of the Internet we use today for precisely this reason. Unix wouldn't work - the Internet itself wouldn't work - if its design were in the hands of the people at Unsanity. Unsanity 'software' attempts the impossible - the 'illegal' - for precisely one reason: to sell. No system has ever profited by an Unsanity product. The name itself is a complete giveaway. Unsanity products are not 'PRODUCTive' - they add doodads at a cost no one wants to pay. If Apple and Steve Jobs thought it was OK for Unsanity software to run on their systems they'd have made it easier. If Apple and Steve wanted users to be able to do the weird things Unsanity attempt to do they'd have exposed APIs for that purpose. But Apple and Steve do not want you running Unsanity products - for your own good. Unsanity bridge several layers of the system and do so in a promiscuous way. They have code at the application layer, the kernel layer, and the driver layer. They have ordinary framework code supporting their 'enhancers' and then they have a daemon running at system level. Bridging things in this fashion is never good and inserting code into a system at those low levels is strictly verboten - for reasons any qualified system engineer understands intuitively. You keep your hands off the drivers. Not all Unsanity users are aware of what they're doing and not all Unsanity users are even aware they're actually using Unsanity products. Unsanity licence their framework to other developers - who coincidentally skip telling their customers what's really going on. The situation is exacerbated by virtue of this fact: suddenly you're not dealing with a single monkey corrupting your system - you're dealing with a whole barrel of them. And it's 'outsourced security' too: Unsanity neither can nor want to guarantee the viability of any other products that use their APE framework. The power of this framework however is such that any dimwit can use it and completely corrupt your system. And what will Unsanity say? Amid much fanfare they will declare how much they've tested their framework. But they haven't tested the other APE applications. They can't test them. And they don't want to test them. They want to sell their APE and their own doodad apps. That's all. For you who long for yesteryear when your beard wasn't quite as gray it can be an alluring proposition. It's also a fatal mistake. One of the biggest most telling blunders in recent memory was when Landon 'Osama bin' Fuller decided to 'save' Apple from under the merciless attack of the Month of Apple Bugs - by using Unsanity's Application Enhancer Framework. Naturally the authors of the Month of Apple Bugs were amused - and it turned out they knew more about Unsanity than the programmers at Unsanity themselves did. It turned out Unsanity's Application Enhancer Framework was a booby trap land mine of substantial proportions: it was vulnerable to a child's play root exploit. The programmers at Unsanity, no doubt only today beginning to understand they're not running 'MacOS' anymore, completely missed the point that you can't have a SUID root executable on disk that's going to be reset all the time and that can be overwritten by malfeasant code. Bug 8 from the Month of Apple Bugs was a sore embarrassment for Unsanity - and should have been a wake up call for Unsanity users everywhere. The chaos on Apple's discussion boards subsequent to the release of OS X 10.5 Leopard shows this isn't the case. Instead one finds Unsanity users actually blaming Apple for Unsanity's unforgivable actions. And once again when something really bad happens the likes of Slava Rosnya and Jason are not far behind. Unsanity published an explanation on 27 October of what everybody else already knows. Slava has the word.

I'd like to note that the problems some people were experiencing while doing the Mac OS X upgrade and being unable to boot due to Application Enhancer installed may have been caused by the 'old' versions of Application Enhancer not properly recognizing the system version. The latest 2.0.3, released on 13 March, is properly detecting the upgrade and refuses to load so you should not have any issues with installing Leopard over it.

Right. So if you don't run Usanity's APE at all it works perfectly.

For this reason we recommend you upgrading to 2.0.3 before upgrading your Mac OS X. It will properly detect the system version and deactivate itself.

Ah. So you upgrade so it won't work anymore. Clever workaround.

crucial parts of the system that Application Enhancer depend on were severly broken until... (drum roll) the GM build!

Aha. So basically Unsanity are peddling a system that's dependent on warping another system (Apple's Leopard) and that simultaneously is so wobbly any changes in that other system can break both your system and that other system. To the point both systems become irrevocably inoperable and your best course of action is to reinstall that other system all over again. That sounds like a great idea.

Stay tuned, and please accept our sincere apologies for all the trouble that was caused. We have underestimated the number of people running 'outdated' versions of our software. Of course, that's not an excuse... and thanks!

Garble. Gobbledegook. Garbage.

'APE is synonymous with the extensions mechanism found in MacOS 9 and prior. They both provide a way to modify the system in just about any way desired at the cost of stability and consistency of operation. APE has been a constant source - directly and indirectly - of system instability, app crashes, and other problems. APE has caused a boatload of problems within the user community.' - Bill Bumgarner