Of BareBones and bias (aka, "Ho, please.")
The other day, the CEO of BareBones offered an amusing "clarification" of the alert I mentioned in Unintended Interactions. The simple gist is that my unstated bias is leading me to misinterpret the dialogue I referenced in , which is a simple troubleshooting step because they've seen a lot of problems with haxies and their products. We'll take this piece by piece...
To backtrack for the sake of clarity, let's look at what I said:
I.E., the first email back was "Sorry, nothing I can do, APE affects Cocoa below my program.", but it's worth not giving up on, unless the company is an extreme example like BareBones (who throws up an alert saying they see APE is installed, and to uninstall it before calling support), which I always thought was exceedingly lame for just this reason. Basically, if this had been a BareBones product, they'd probably still have that bug in there. There's an implied arrogance behind that error message I can't get behind.
Mr. Siegel had a problem with this, and let me know via my inbox (after asking if I'd even seen the dialogue, which insinuated things I'm not going to tackle in this post) that he believed my bias was causing me to read things into the alert that weren't there. And then he blogged it...
As written, drunkenbatman's statement is factually incorrect. I couldn't understand the origin of his remarks, and it did occur to me that they might be the result of an unstated bias......This is not an effort to discourage these customers from contacting support. The quality of our technical support is a big factor in our success, and discouraging customers from writing to us would break the cycle of feedback and improvement that we rely on to make a better product.
The error message in question would be below, which I first saw when I had a GUI lockup due to something unrelated (the official Bittorrent client is evil that way, and I was trying to figure out what was going on). After rebooting, I fired up TextWrangler, which I'd been taking some notage with, and saw:
It's easy to duplicate yourself -- If you have any APE modules installed (I use ShapeShifter and DesktopSweeper), and force-quit a BareBones app, you'll see it. Doesn't matter if code is even being injected (I was curious enough that I tried it with it in the master exclude list), they're just setting a bit somewhere and looking for it and throwing that up.
It's lame, and only in bizarro-world would that be taken as a simple troubleshooting step. Point blank, that dialogue is a pre-condition for calling support -- remove anything that doesn't come with the system, and if you still have the problem, then contact them. If you don't see it (which in many cases is meaningless if you can't pin down where the problem is), you're on your own.
A few people have decided to rear their heads, and I'm always amused by statements such as "I don't ship or develop software, but if I did I would tell anyone running xyz to take a hike...", because thank god you don't develop software. You don't have the genes, and should be looking into an MBA instead. Users are going to install things, and they're going to change the parameters under which your app is running -- whether it's a kernel extension for something Apple ships or a mouse driver.
That's why it's called a personal computer, and not an appliance or a console. I don't absolve haxie authors from responsibility, because it's their software that's interacting with the other thing I want to run -- and when I find a problem I contact both parties so they can better figure out what's going on while asking what they need from me to help resolve it. If a developer isn't interested in tracking down what may be a problem with their software -- even if that bug is only coming to the foreground because of a haxie -- I have little interest in using their software.
Now, if someone is doing tech support, someone is going to want to know the conditions under which the problem is occurring -- the version of the OS, etc., That's just common sense, because that's the only way to have meaningful statistics. That isn't what that dialogue is about, and if that is what that dialogue is supposed to be about, it's worded incredibly poorly.
In the interest of full disclosure, I forgot to mention something in that original post that may or may not have any bearing -- when I contacted the developer of GyazMail about the issue, I also CC'd the Unsanity guys.
That I'm aware of, I've only had a problem with haxies twice (I ran without them for ages, only after I'd ascertained that 10.4 was so buggy nothing I'd add would change it any) -- the GyazMail issue I mentioned in the original post, and an interaction between ShapeShifter and DesktopSweeper that was causing the Finder to not want to come to the foreground via command+tab. After retracing my email steps, I realized that I'd left out that I'd also pinged Jason at ShapeShifter regarding the original GyazMail issue (CC'd), which I mention only because I don't assume the bug isn't in something they're doing. I just don't assume the opposite either, and I don't think any dev who cares about the state of their code would.
I also don't expect herculean efforts from a developer to find and fix a problem, and as mentioned, when there was a bug in 10.3 that made dealing with crash reports that had APE installed a nightmare (symbols were being stripped) I knew a lot of devs that I respected that were just throwing them into their own pile and they'd only dig into them when they saw a preponderance of similarities between them, because it was a bunch of work. Bygones, because in that case, I held Apple responsible.
If a developer is unwilling to do that, that's their decision and good luck with it, but I'm not going to get behind it.
I find this part of his post particularly amusing, especially after his claim that my bias is leading me to see things that aren't there:
So, there you have it. We don't have anything against Unsanity, their products, or their customers. We just want to make sure that our mutual customers have the information they need to troubleshoot their problem quickly and accurately, so they can get back to work.
Contrast this to say, what he said earlier this year...
So if your haxies are messing up your system, we're the last ones you should expect help from, since there's nothing we can do about it at a software level.
Gee, I can't imagine where anyone would have gotten the idea behind what I originally said. Suffice to say, I'm sticking to what's in my original post, because widespread anecdotes aside, it's just known that BareBones isn't down with haxies -- obviously they had to have thought through that their dialogue alert would pop up when there was no possible way a haxie could have been involved, but there it is.
In the link I reference above, this is also said...
Haxies are particularly pernicious, since they violate the boundaries of Mac OS X protected memory space by injecting code and data into running applications that are not there at the request of either the application -or- the OS. In past versions of haxies, the developers wrongly thought they knew more about the workings of the OS than the OS developers, and consequently attempted to "fix" or "work around" OS behaviors that they saw as "incorrect". This, naturally, led to all kinds of havoc with correctly written applications.
To an extent, he's right, but it's highly misleading and -- dare I say -- somewhat biased towards the code base he's having to push. There are different types of haxies, and what say, FruitMenu or MenuMaster is doing is wildly different from what DesktopManager or ShapeShifter or DesktopSweeper is doing. Specifically, we'll talk about that correctly written applications part.
I don't think it'd come as a surprise if I told you that all application code bases are not created equal, and all APIs are not created equal. There's a reason why say, Cocoa apps started getting a reputation for being better behaved and much more stable than Carbon apps. While it's a stereotype, and stereotypes are dangerous because people let themselves be ruled by them, stereotypes have a habit of existing because they're often based on something real somewhere.
In software, there are conditions called edge cases. Edge cases are fickle and often exasperating things. To give an analogy, consider you've designed a website, and it shows up fine in Safari and Internet Explorer -- but then after it's launched you hear from users that it's breaking when viewed in Firefox. After some debugging, you come to find there's a structural error in how you're coding the app, but the other two browsers are being much more forgiving and are displaying it anyways, while Firefox sticks to the spec and it breaks. Additionally, because you didn't catch this bug early, going through and changing it could cause problems elsewhere -- a serious time sink.
The developer in this case is faced with a choice. The problem is in their program, where it is basically skating by most of the time, although it probably shouldn't be, but it only crops up when someone is using the site with a minority browser. In many cases, they may well choose to just not want to deal with it, but it doesn't mean the problem isn't there -- if the other browsers stop being more forgiving, it'll break eventually.
That's probably a lousy analogy for edge cases, but It's my opinion that if there is a seriously above-the-norm issue for BareBones when it comes to haxies to where they feel they have to go installing some lame-o alert box while no other developer does, it's because they have more edge cases lurking about in their code than they care to deal with. If you're guarding a house of cards, you're probably going to wig out more than most when someone walks around it.
That whole unstated bias thing really got up my craw, not because I'm not biased. I believe everyone to be, because we can't help having who we are and what we care about affect what we take in. No, I primarily have a problem with it because I find the claim nonsensical in conjunction with the link I've given above, other past statements, or just reading the damned alert box for yourself.
However, if you did want to assume I was incapable of looking past my bias and being objective, in the interest of full disclosure I'll list all the factors in my head I'm aware of in regards to the situation...
- Brent knows and worked with Rich Siegel, which goes a long way with me, and started him off with high karma.
- I depend on two haxies to make OS X more usable -- one to do away with all traces of metal, and one that keeps my icons from turning my desktop into a horror show when I take screenshots. Obviously, I'm going to be biased towards applications not borking when I use them.
- BBEdit is the premier native text editor for the Mac. If someone comes to me from Windows or Linux and asks me what best matches the feature set of the premier editors they were used to on their platforms, I point them to BBEdit. It's the only native engine I'm aware of that can handle large amounts of text without screwing up on the platform, it does what it says on the box, and the box has a lot of bullet points.
- While I do point people towards BBEdit, more and more I'm pointing them towards newer editors which may do what they specifically need for a fraction of the cost. Editors like SubEthaEdit, TextMate, Eclipse or jEdit are coming to mind.
- I've seen a haxie author naked. Twice. I wish I was making this up, and mention it for thoroughness because I've never seen Mr. Siegel naked. Considering I'm unaware of any female haxie authors, I'm going to call this one a win for Rich's side of my head.
- If you used BBEdit 5+ years ago, there'd be few surprises in store if you picked it up today. It's like they just hit OS X, added some things for shell scripters and those who want to pass things via the CLI and considered their app done.
- Saying their software's interfaces are a little... long in the tooth... probably doesn't do the situation justice. Its preference panels make KDE distros look clean, and while you can learn where things are over time, it's all straight out of the 7.5 CodeWarrior days.
- BareBones offers TextWrangler free of charge, which is a great and capable text editor. I point people towards it often.
- The free BBEdit Lite was discontinued, while TextWrangler was introduced for $50, and then TextWrangler was released for free. The stated reasoning behind the back-and-forth never really made a whole lot of sense to me, and just got annoying.
- Everyone and their mother knows that Mailsmith is one whacked-out product, held together with baling wire, spit, and luck. Hitting this app was a brick-wall for me, and certainly colored my head when it comes to their products -- I.E., it let me know that they weren't above shipping something that was rife with bugs, and didn't do what it said on the box. I've mentioned this before, but suffice to say at best this is an app that "needs attention". At worst, it's a client only 1994 could love, and when its bug-count and features are contrasted with its price, it approaches being an embarrassment on the platform.
- Mailsmith integrates Spamsieve, which is hands-down the best anti-spam solution available for the Mac today, which is cool. While you can purchase it and add it onto Mail.app, Apple should be bundling this, so it's cool someone is.
- I've only interacted with Rich on three occasions that I'm aware of. I can't talk about the first, but suffice to say there were no problems on my end regarding the interaction. The two times after that have involved him emailing me regarding something I'd said that he didn't like, and were just kind of weird and contained insinuations or claims about something or other, and when I'd shoot one down, he'd throw back another.
I don't really get upset by someone having a beef with me, because depending on the day I can rub people the wrong way, and someone having a beef with me isn't a prerequisite for my having a beef with them. However, that's when I'm pinging them, not when they're stepping into my inbox. I'll admit I roll my eyes when I see his name in my inbox now, but it's not a big deal.
- I associate the word arrogant with Rich Siegel after reading this quote at MacWorld/MacCentral, regarding why TextWrangler would now be released for free:
So why give away an otherwise successful product after just releasing a major update? Bare Bones Software said they wanted to raise the bar for other developers thinking of making a text editor.
"These overnight text editors don't reflect well on the genre or the platform," Bare Bones Software President Rich Siegel, told MacCentral. "We are raising the bar, elevating the standard."
Considering some of the seriously cool things these overnight text editors were doing, and how... stagnant... their product line had become, I was just floored when I read that last quote. I actually had to ask around on this one, because I almost couldn't believe it came out of his mouth or what the hell he was thinking -- you just don't do that.
Either he was just clueless about where people's heads were, something else was going on or, um, both. I'm told Mr. Seigel had some serious beef with some of the marketing and/or hype around TextMate. I don't recall and couldn't pull up the specifics, and it didn't really matter because whatever his beef with TextMate, he'd used the plural form of editor, and apps like SubethaEdit and such are gems of innovation on the platform.
Some of the above regarding bias is tongue-in-cheek, but the simple gist is that Mr. Siegel and the bias horse he rode in on can bite me.
Posted by drunkenbatmanNovember 28, 2005, at 01:05 PM
Comments (67)
Posted by: John at November 28, 2005 01:39 PM
"You don't have genes, and should be looking into an MBA instead."
Missing a "the" in there?
Posted by: Shnorf Fehrman at November 28, 2005 01:54 PM
That's a very long blog entry over something fairly simple. Haxie developers are doing things that are specifically unsupported by the operating system. If I was that developer I certainly wouldn't want to be bothered every time a haxie made my application crash. That attitude would be shared by most developers in my experience. And, to boot, you decided to get rather personal about it. There wasn't much content here anyway, but it was sometimes amusing when you weren't getting ugly with people. I'm sure I can find a blog to amuse me that isn't long, ugly, boring and wrong.
Posted by: mikeash at November 28, 2005 02:14 PM
Way to go DBM. In contrast with all of these "if I actually made software" people, I actually do make software, and I'm behind you all the way.
Posted by: Chris Biagini at November 28, 2005 02:20 PM
This is fantastic, DB. Really, truly, fantastic. It's like you wrote this from inside my head.
Posted by: Ben at November 28, 2005 02:37 PM
Dude never explained why what you'd said was "factually incorrect". I hate that. He just said it, and then acted as if it was trivial for the reader to figure it out. And it isn't. Maybe something you said in that entire article could be factually incorrect, but the stuff you originally said about BBEdit was brief. So WTF was the incorrect fact? I can't smell it, and I tend to disagree with your take on haxies. Totally not the issue here.
And that makes it totally impossible to interpret wtf he thinks he's saying you're biased by. If that made any sense.
Posted by: Mike at November 28, 2005 02:46 PM
The comment I posted to Rich's blog is a valid response here as well...
Which is to say, both "sides" have good points.
As a user, I have seval haxies installed because, frankly, they make my day to day use of my computer much more efficient and enjoyable. For me, the user, WindowShade behavior is BETTER then having windows minimized to the dock. Having a hierarchical and customizeable Apple menu is BETTER then Apple's lame OS X default Apple menu.
But, as someone who does software QA for a living, I am also quite aware that Haxies introduce an unaccounted for variable and Bare Bones' dialog is an acceptable way to handle the situation and try to eliminate a variable for their customers and support people. There's nothing wrong with asking users to turn off "add-ons" like APE when troubleshooting.
To summarize, it is OK to run Haxies if they improve your Mac experience, and it is also OK for support and engineering to insist that any bugs be reproduced with the Haxies turned off, as a standard troubleshooting step.
Fair?
Posted by: Jesper at November 28, 2005 02:46 PM
One claim I've seen about APE is while it's not above causing problems with clean code, it can actually help uncover so-so code that would otherwise go unnoticed in certain cases, and it certainly rings true. To take one example, writing a string in completely the wrong place in memory, but which is zeroed by default, would not be likely to truncate it, but if a haxie had some stuff there it could mess shit up.
Of course the net result of adding haxies is that they mess with the foundation, but given the above, there's no reason in claiming that it's *just* someone else's code spitting in your water tank.
I'd also like to add that I didn't believe what I was reading when I read the last bullet on DB's list either (or before that, because I'm the one who sent him that). BBEdit is an awesome product and there's no denying that. But there's absolutely no excuse to get bitchy about up-and-comers lowering the standards, unless Bare Bones conveniently have managed to steer clear of SubEthaEdit, TextMate and the numerous ingenious CSS and HTML-specific editors, leaving only the real (and few) RealBASIC overnight projects.
BB makes it sound like BBEdit is the only gold nugget in a turd of PerversionTracker-ware, and that's just not true in any way.
Posted by: John Pannell at November 28, 2005 03:23 PM
The emotions seem to run high in these posts (your initial post, his reply, and this reply), and in the end this seems to be more about attitude than applications. BBEdit is an excellent text editor and quite popular - it's a good app. There are other good editors out there too. You and Rich seem to have an issue with each other on Haxie-friendliness, which you are entitled to have, I guess. I'd hate to see your disagreement affect his sales, or your cred with developers, however.
That said, here's some more anecdotal fun... my shareware app has a couple thousand registered users, and about 3000 downloads a month, on average. I work really hard to ensure the app doesn't crash (it is embarrassing!), and I've gotten 13 crash logs in the past year, all of which I've followed up on. Ten of these had APE involved. Fortunately, my users are very kind and patient, because I have yet to successfully debug any of the APE related ones! It is not clear how to figure out whether APE is exercising an edge-case bug of mine, or if APE is doing something bad. Of course, I can't see what APE is doing behind the scenes, as well.
I'm glad my users put up with the "I can't figure this out" approach. I'd rather look like a moron than lame :-)
Posted by: Mat at November 28, 2005 03:52 PM
You may have noticed that from 10.2 to 10.3 the Mac OS X crash reports started containing all libraries and resources linked against. Not only did this help out with regular debugging but it enabled Apple to bulk delete any crash report with APE linked against it.
If I remember correctly at one point they were seeing 40% of their crash reports for core Mac OS X apps (Mail, System Preferences, Address Book, etc.) being caused by APE in some way. They spent thousands of man hours tracking down bugs that didn't exist.
I personally know that I have seen crashes that cannot be explained except by APE. It's frustrating having something invade my memory without my permission and having customers get upset with me when my code crashes because my memory has been overwritten by something else.
Posted by: Mark Hoeler at November 28, 2005 03:57 PM
Ugh, Rich should have just said he doesn't want to support other people's code affecting his applications. The double-talk is not becoming of a CEO.
Posted by: Pascale Soleil at November 28, 2005 04:29 PM
From the department of Excessive Typographical Obsessiveness:
There's no apostrophe in the plural of "ego."
We now return you to your regularly scheduled debate.
Posted by: ssp at November 28, 2005 04:35 PM
Hmmmm... ShapeShifter just to get rid of the metal. Isn't that using quite a big tool for a small task?
If you said 'I like customisable/flashy/... window styles' it'd sound much more reasonable to me...
Posted by: drunkenbatman at November 28, 2005 04:43 PM
There's no apostrophe in the plural of "ego."
Not on my album. :p
If you said 'I like customisable/flashy/... window styles' it'd sound much more reasonable to me...
Well, not exactly going to go through and reset the .nibs on every app I use. However, fair enough, I should add to remove pinstripes. I hate pinstripes -- Aqua does not age well.
Posted by: Charles Bucket at November 28, 2005 05:36 PM
fuck off, drunken butthole.
what the hell has been your contribution to the mac software world? you suck big dick.
rick is perfectly correct in his attitude toward the unstable haxies. and releasing TextWrangler as a free product is a welcomed gesture.
Posted by: Cameron Hayne at November 28, 2005 05:37 PM
I don't understand the furor about Rich Siegel's "raising the bar" quote. First off, he spoke about those who were "thinking of making a text editor" - that implies future tense (developers who have not yet made a text editor).
And the "raising the bar" stuff made perfect sense to me. I took it merely as stating that any one who wants to make a text editor had better make it at least as functional as TextWrangler - since TextWrangler is free (as in beer), there is no point in making a lesser text editor. By the way, note that SubEthaEdit is not free except for non-commercial use.
And the BBEdit/TextWrangler dialog about APE seems to me to be merely stating the quite reasonable position that BBEdit does not support the use of their product in the non-standard environment resulting from the presence of APE.
Each different environment that a developer supports costs them time and effort. Not supporting APE is like not supporting Jaguar or even Panther. Many people might be using it, but a developer can decide that it isn't worth their while to deal with the extra work it entails.
And the discussion about edge-cases and latent bugs being revealed by APE is analogous to a car that becomes dangerously unstable when out-sized tires are installed. The base cause might be a "bug" in the car's design, but it works well with the standard tires and nothing else is supported.
Posted by: Peter da Silva at November 28, 2005 06:04 PM
Personally, I like "milk", about the *un*flashiest window style out there. It's Apple forcing flash on us that's the problem.
Anyway...
And the discussion about edge-cases and latent bugs being revealed by APE is analogous to a car that becomes dangerously unstable when out-sized tires are installed.
If you live in a part of the world where there's heavy snow on a regular basis, outsized tires may be an annual requirement, not a "flashy" option. If the car becomes dangerously unstable when equipped with oversized tires the dealer may not be able to duck responsibility.
On top of that, there's all kinds of interfaces that *are* supported that can change the environment in your application in unexpected ways. And software is a lot less predictable than automobiles: if your program crashes because of the equivalent of oversized tires, it may also crash because of the equivalent of a third party stereo, or a Jack In The Box antennaball. Edge cases are just plain "edgier" in software.
Posted by: JustinB at November 28, 2005 06:05 PM
ssp:
I'm very much a believer in the "do one thing and do it well" approach to applications, but in this case the arguments against it are convincing.
Metallifizer has been on the wane since 10.3 and SS came out. Unsanity has released the source, so we may see an updated version in the future; but as in life, there are no guarantees. As it stands, the last official release isn't certified for Tiger (probably still works), and also can't demetal Carbon windows. Building from source may or may not help you out here, I think the carbon de-metalling code was disabled due to bugginess.
Unifier (http://www.chatelp.org/index.php?id=48 ) is a free, closed source app designed to bring everything up to the "smooth plastic, unified toolbar" look. It's more Tiger-friendly than Metallifizer, but still has no Carbon mojo.
De-metalling Cocoa apps is easy, if a little tedious without an app to help you apply it across the whole system. Like DB said, it's just a matter of opening the nib in IB and tweaking one value. De-metalling a Carbon app is a much bigger deal, since you have to replace images within the resource fork. Shapeshifter is the only app, in my experience, that gets it right.
Even if all you want it for is de-metalling windows, ShapeShifter still performs the job better than the (free) competition and the primary features easily justify the fact that you have to pay for it.
-justinb
Posted by: Chucky at November 28, 2005 06:16 PM
"It's lame, and only in bizarro-world would that be taken as a simple troubleshooting step."
Dead wrong. So utterly dead wrong.
If I'm troubleshooting a Mac, one of the first handful of steps I'd take is disabling APE if it's installed. Once again, for emphasis:
Disabling APE is a simple and basic troubleshooting step.
What's wrong with a third party developer being blunt about conveying that info to its customers?
Posted by: JustinB at November 28, 2005 06:19 PM
Charlie Bucket - I'm waiting for links to all the macintosh software you have developed. Is there anything you could name that I might be using right now? Anything I might have even heard of? I'll wait.
DB arranged for 10 of the best mac developers in the field to sit down at the same table(s) and share their thoughts on cocoa, the future of mac development, and how to hack it as an indie mac developer. His seat in heaven is assured.
Now, about YOUR contributions. All I could find was 5 or so posts to other mac-related blogs, with the same kind of snarky comments, adding jack and shit to the discussion. But I'm sure you're just about to reply to this and link to some of your software credits. I'll wait...
-justinb
Posted by: Cameron Hayne at November 28, 2005 06:24 PM
If you live in a part of the world where there's heavy snow on a regular basis, outsized tires may be an annual requirement, not a "flashy" option. If the car becomes dangerously unstable when equipped with oversized tires the dealer may not be able to duck responsibility.
No - if special tires are a "requirement" for you, and these tires don't work well with the car that I make, then you'll have to choose some other car.
The dealer/manufacturer can choose what they support and what they don't.
Of course, if the government steps in and says that car manufacturers must support the use of whatever tires a consumer installs, then that is analogous to Apple saying that APE-like modifications of application space are an expected part of OS X behaviour, and in that case, developers will need to do the extra work (development & testing) to ensure their apps work in these new conditions.
Posted by: ssp at November 28, 2005 06:41 PM
drunk / justin:
This may not be widely used approach. But the one I use to kill the metal ever since Demetallifiser stopped working (ages ago IIRC) and I hated the metal enough to look into it is the very basic one of removing the metal graphics from the system.
It's a solution that's as simple and dumb as it is effective. A System file has to be changed for it to work, but that's about it. The patch is done in a few seconds and there are no worries about bad code or anything later on.
Admittedly, the result isn't as pretty as it can be with specialised themes, but I quite like a simple grey and somehow my thirst for exciting theming ended after the demise of the Drawing Board...
I suspect the same technique can be used to kill the pinstripes but as I quite like them, I didn't bother to look into that.
I wrote up how to do that patch in five convenient command line steps this summer in case you're interested.
Posted by: Jed at November 28, 2005 06:57 PM
JustinB - could it possibly be that Charlie Bucket developed BBEdit, TextWrangler, MailSmith and is a pseudonym for...?
;-)
Sorry for stirring.
Posted by: drunkenbatman at November 28, 2005 07:20 PM
"It's lame, and only in bizarro-world would that be taken as a simple troubleshooting step."Dead wrong. So utterly dead wrong.
If I'm troubleshooting a Mac, one of the first handful of steps I'd take is disabling APE if it's installed. Once again, for emphasis:
You've got your wires crossed, as of course it is, I've said so, and you're applying what I said to something else entirely and the saying it's wrong. Please reread, as what I'm saying is that that alert box is not part of a troubleshooting step, it is a brick wall saying to go away.
Posted by: Tonio Loewald at November 28, 2005 07:22 PM
Having read both DB and RS's posts and being generally sympathetic to DB's take on many things, I have to side with Rich on this.
To begin with, Rich at least kept personalities out of his blog entry, and didn't even snidely allude to dreading seeing someone's name in his inbox or anything.
1) Disabling random third party crap is standard practice for dealing with any tech issue. It's not like BBEdit throws up the dialog gratuitously (e.g. the way Windows 95 beta did for Borland-compiled apps).
2) This is all over an "enhancer" that has no useful effect; it's just cosmetic.
3) Is having written a shipping piece of Mac software some kind of pre-requisite for posting an opinion here? If you don't like someone's post (e.g. because they're rude or incoherent or illiterate) then attack what was said or how it was said, not the person who said it. Even people who haven't shipped apps can have valid opinions. That said, anyone whose post starts "fuck off, drunken butthole" deserves what he (?) gets.
In general, where DB errs it is on the side of thinking his personal issues are of far greater significance than they are. (1) folks who use haxies are a minority, (2) folks who use haxies and aren't willing to switch them off to see if they're causing a problem are an even smaller minority, (3) folks who use haxies and get their knickers in a twist over the wording of dialog boxes that come up when an application is forced to quit might need medication.
Posted by: ray_gadson at November 28, 2005 07:29 PM
I'm not trying to be obtuse here, but if I'm reading this correctly:
1) Something in BBEdit works if you aren't using APE.
2) If you use APE, it breaks.
3) This is BBEdit's fault.
Something about this logic confounds me. You said if anything, Bare Bones should be happy that APE 'exposed' the bug and brought it to light. But if it's a bug that *only* happens when you use APE, how exactly is it the fault of Bare Bones? This bug *only* manifests itself in the presence of APE, yes?
And, just to be clear, APE *is* a hack, yes? It's doing things with the OS that are explicitly not supported by Apple, while BBEdit is following all the rules for a proper app, yes?
In what universe is this Bare Bones' fault?
Posted by: ray_gadson at November 28, 2005 07:31 PM
One more thing: the CEO of Bare Bones may indeed be a quadruple asshat, but if you chose products based on the reasonableness and decorum of their CEOs, you wouldn't be using an Apple product in the first place. The personal behavior of Mr. Siegel does little to change the facts of which application authors are following the rules Apple has made for their OS, and which ones aren't.
Posted by: Peter da Silva at November 28, 2005 07:32 PM
Disabling APE is a simple and basic troubleshooting step.
Agreed.
My gripes are twofold: first, comments suggesting an app should simply refuse to run if APE is installed; and second, the assumption that if disabling APE fixes the problem the problem should be ignored.
No - if special tires are a "requirement" for you, and these tires don't work well with the car that I make, then you'll have to choose some other car.
In the analogy-world where APE and the hypothetical APE-blocking application are the tires and the cars respectively, I agree that I'll have to choose some other car. I was just pointing out the analogy was invalid... in the real world you typically buy a car near where you live, and regardless of other laws the implied warrant of merchantibility would nail the car company if they sold cars that couldn't handle snow tires in alaska.
In the world of this discussion, the more important point is that if a program crashes because an APE is running it's likely to be less stable when you have other system extensions... including Apple-approved ones like input managers that ALSO run in your application context.
Posted by: matt roberts at November 28, 2005 08:10 PM
Thankyou for giving your personal opinion.
And to everyone else - stop trying to pick holes in it. It is an OPINION.
Posted by: Poleski at November 28, 2005 08:14 PM
Something about this logic confounds me. You said if anything, Bare Bones should be happy that APE 'exposed' the bug and brought it to light. But if it's a bug that *only* happens when you use APE, how exactly is it the fault of Bare Bones? This bug *only* manifests itself in the presence of APE, yes?
Ray,
DB didn't do the greatest at explaining edge cases, his example is far too simple. It is possible to have bugs that have a 10% chance of occuring (1 in ten times it crashes or exhibits aberrant behavior), making it difficult to diagnose. With a haxie moving memory around, it could increase the chances to 50% or even 100%. Those bugs do exist, however I think Haxie authors do have more bugs in their application than they admit to.
As a developer (rarely for OS X, now back in school = Java) haxies can be a burden, because you are given little to track down the bug. It can be very time consuming.
I do wish BareBones had kept the discussion to the above where I would be sympathetic. Instead we have Rich claiming DB is misreading the dialogue box (he isn't) and a red herring about bias. My suspicion is he came up with the troubleshooting step as damage control, and got DB's dander up needlessly. Irony! Interesting debate, at least.
Posted by: Watts at November 28, 2005 08:25 PM
The issue here as I understand it isn't whether third-party extensions can cause problems, nor is it whether it's reasonable to ask people to disable those extensions as part of the normal debugging process. It's whether it's necessary, let alone user-friendly, for an application to check for those extensions on startup and get grumpy if they exist. I've seen BBEdit's complaining dialog several times and not once has it been from a crash that APE has caused.
If as a user I ask for troubleshooting help, tell me then. If you have a bug report tool built into your application, check then. But don't go through a stupid syllogism of, "I terminated unexpectedly on last run, you are running 'Haxies,' I must stop everything to warn you that haxies may cause crashes." I may not be an experienced developer, but I find the implied proposition that running ShapeShifter caused my PowerBook battery latch to break somewhat dubious.
The bottom line, I think, is: whining at the user is not part of the debugging process.
Posted by: Pascale Soleil at November 28, 2005 08:34 PM
Not on my album. :p
Wouldn't be the first time I was insufficiently hip to recognize a cultural reference...
Which album?
Posted by: Tom Robson at November 28, 2005 08:57 PM
Hey Mike, "then" and "than" are two different words ...
Posted by: Cameron Hayne at November 28, 2005 08:58 PM
My gripes are twofold: first, comments suggesting an app should simply refuse to run if APE is installed; and second, the assumption that if disabling APE fixes the problem the problem should be ignored.
As I've said above, I think application developers can decide what they "should" do - based on maximizing their return on investment, or on any other criterion they choose. A developer may well choose to invest the extra effort to ensure that their app will work with APE and the more common haxies - if they think it is worth their while in terms of added sales or just good karma.
And consumers "should" be able to assume that apps will work well in the standard OS X environment. What this discussion centers on is what can be considered "standard".
At the moment, Apple doesn't consider APE to be part of the standard environment. And even though InputManagers are an accepted part of the standard environment, it seems to me that many of them are being used in ways that would not be approved of by Apple - i.e. they are being used to change the behaviour of apps instead of merely changing the way that text input is handled. Thus another standard troubleshooting step is to remove all InputManagers.
In my car analogy, snow tires are an accepted part of the standard environment in most northern regions. My reference to "outsized tires" was intended to refer to tires that were grossly outside the operating limits defined by the car manufacturer.
Posted by: Chucky at November 28, 2005 09:09 PM
"Please reread, as what I'm saying is that that alert box is not part of a troubleshooting step, it is a brick wall saying to go away."
Siegel is perhaps being overly prickly in his style of communication, but it's not "a brick wall saying to go away." It's a brick wall saying to you, drunkenbatman, to go away because you want support for a configuration they are upfront in telling you they won't support.
Imagine if a user emailed you complaining your site doesn't look right in CyberDog. If you emailed them back, you'd say something to the effect that you didn't support their browser. Siegel is saying something quite similar in a more prickly fashion: run a supported configuration if you want technical assistance.
Posted by: Marcus at November 28, 2005 09:36 PM
Siegel is perhaps being overly prickly in his style of communication, but it's not "a brick wall saying to go away." It's a brick wall saying to you, drunkenbatman, to go away because you want support for a configuration they are upfront in telling you they won't support.
Am I missing something? I think the issue is that they are NOT saying that. I have to agree you do not seem to be reading this or the linked blog posting.
1. Drunken Batman says BareBones blah blah
2. BareBones says this is not the case, they just have that dialogue to help troubleshoot and have no problem with haxies. They only want to know whether it occurs without the haxie before they troubleshoot.
3. Drunken Batman says this is revisionist and not the case blah blah blah.
4. Chucky agrees with Drunken Batman, but thinks he is wrong anyways.
5. Profit????
Congrats DB, you are now slashdot!
Posted by: Colin Barrett at November 28, 2005 09:36 PM
Regarding APE and troubleshooting:
Asking your customers to disable APE is a perfectly reasonable troubleshooting step. But the way that dialog is worded implies that Bare Bones doesn't support Haxified systems. "Troubleshooting step" is a long way from "unsupported."
I know I ask people who send in Adium bug reports if they have Haxies installed when weird behavior is reported. Actually, I just ask them to describe anything non-standard about their system. We had a problem with UFS users a while back, and have had some problems with Case-Sensitive filesystems. We worked out the problems though, and now they seem to be working smoothly.
That's a troubleshooting step. That dialog Bare Bones displays sounds to me like "if you have Haxies enabled, we can't support you. Turn them off first." That's not troubleshooting, that's implying that you don't support Haxies at all. What does that mean? That means that when the haxie is turned off, and the bug goes away, Bare Bones isn't going to support you. At least, that's the impression I get.
Posted by: at November 28, 2005 10:16 PM
DB I love you and lots of what you do but your hyper sensitive and off on a tangent on this one, and I gota say I take the Bear Bones angel.
As I say to the designers I have to look after (yes that's part of my day job) when I gave it to you it was a production machine set up (and tested) to do a job. You put shit on your machines it and breaks! Don't come crying to me if I pull that S*it off.
Haxies are nice pretty etc but if they do stuff to the os.. and some times make it unstable (which sucks! and is bad for all of us) I say good on barebones for putting it in writing
(don't get me wrong I read wolf's blog saw the adler thing he looks a straight up kool sort of guy).
But ...cause apple has enough bugs for all of us. (and yes I do write software!) what does the developer do have to manage apple's bugs and also the undocumented haxies bugs? Do we realy have time for all that? ... come on it's an os mess with it fine, but take responsibility for that ....
Posted by: Chucky at November 28, 2005 10:27 PM
"Chucky agrees with Drunken Batman, but thinks he is wrong anyways."
I wasn't saying there was nothing in db's post I agree with. This whole situation is replete with shades of grey.
But I still think db was dead wrong in the specific passage I originally quoted.
And more broadly, I do have much more sympathy for the BareBones position than db does. I think the majority of developers out there would not take responsibility for support in a situation where their software fails with APE, but works perfectly without APE. And I find BareBones bluntness about that stance to be worthy of a certain respect.
Posted by: John Röthlisberger at November 28, 2005 11:09 PM
Hi DB,
I have nothing but respect for you mate (and a healthy amount of fear), but I think you are taking this the wrong way.
Theoretical situation: I have APE and TextWrangler on my machine, and TextWrangler keeps crashing and I can't figure out why!! In this case, the dialogue box is simply offering a clue: Disable APE, and if TextWrangler still crashes, we would like to hear from you to attempt to resolve the issue. Seems perfectly above board to me.
If I am so bleeding-edge that I still want APE and TextWrangler --and I don't mind the crashing-- then why should a dialogue box bother me?
PS. Your font makes it *really* hard to distinguish between commas and periods.
Posted by: robert at November 28, 2005 11:24 PM
I got 2/3rds of the way through the article, to the point where you talk about edge cases, and immediately I thought of Richard Feynman debunking the Nasa Managers over the o-ring issues that caused the Challenger disaster. He used a glass of ice water to demonstrate that if its cold, they don't work.
So no, db, you are not Feynman in this analogy...
Posted by: erikh at November 29, 2005 12:19 AM
Been reading for a while, but this just isn't a very mature way of handling things.
Summary: "BareBones doesn't agree with me and questioned my integrity. Therefore, I'm going to validate their claims by providing hyperbole about their products."
Posted by: slava at November 29, 2005 04:07 AM
Once again: you're a developer, you have crash logs or user reports and think APE is involved, email us: urgent@unsanity.com. We will look into each crash log and try to debug each problem. That's our responsibility and our job.
Now, I'll go back to my snowy street with bears all over it to drink some vodka and eat borscht.
Posted by: foob at November 29, 2005 04:25 AM
DB said:
"A few people have decided to rear their heads, and I'm always amused by statements such as "I don't ship or develop software, but if I did I would tell anyone running xyz to take a hike...", because thank god you don't develop software. You don't have the genes, and should be looking into an MBA instead. Users are going to install things, and they're going to change the parameters under which your app is running -- whether it's a kernel extension for something Apple ships or a mouse driver."
This is particularly amusing considering that you do not develop software. How can you have such confidence that you're right? I suggest you ask Jon Rentzsch and Brent Simmons what they think about this issue.
There's a big difference between mouse drivers and kernel extensions and a hack. The changes made by a (good) mouse driver or kernel extension are _supported_. Developers are not supposed to rely on anything that a kext should be changing. For example, our interfaces to events are abstracted - put whatever mouse driver you want under us, if it works then our apps will (okay, should) work too.
You're really doing users a disservice by glossing over the distinction between a hack and a normal app. A hack changes the operating environment in a way that developers were never asked to prepare for. They only work because of the ingenuity of the hacker in pre-mapping all possible consequences and accounting for them. Sometimes the hacker will not foresee a situation, and then you have a problem.
"Ah", but you say, "you forget that I want this to work". That's great, file a bug report with Apple, but if you cannot make it work via a supported mechanism, then you're going to be losing support. I'd like my car to be faster too, but if I dump something other than gas into my gas tank, then I'm not going to be surprised if my mechanic looks at me funny when I ask him to make my engine stop stalling when I use drier-lint-fuel.
A mac developer doesn't publish software for 'computers', he publishes software for, say "Mac OS X, 10.4 or later". This has parameters defined by Apple. There's a certain flexibility there - does that include MS Office? MS Office moved to an unusual place on the drive? Maybe. Does that include system calls that do not behave the way the documentation guarantees? No.
The thing is, most users do not know enough to put their computers into unsupported configurations, so it usually works out. The hackers are (and must be) the same as the power users who can do more of their own support. You're just going to get other users in over their heads by making them think that using a hack does not demand greater responsibility on the part of the user.
If someone is using some general greasemonkey hack, and it breaks your page layout, are you going to go out of your way to deal with it? No, you have no idea what they're doing, and if they're going so far as to restructure your page, then they're going to need to deal with that themselves or get help from the script author. If the script author comes back and says "ugh, don't do that hacky javascript thing there, that keeps my script from working", will you fix your site? Maybe, but if you still have a real layout bug that affects unhacked people, I bet that'll get higher priority. You should remember that most software of reasonable size has unfixed known bugs most of the time.
And I do develop software. It appears that many of the people who disagree with you on this develop software. I don't think you have enough information to tell us to be MBAs instead.
Posted by: foob at November 29, 2005 04:52 AM
By the way, DB, compare what you're saying to what slava is saying.
db:
"If a developer isn't interested in tracking down what may be a problem with their software -- even if that bug is only coming to the foreground because of a haxie -- I have little interest in using their software."
slava:
"Once again: you're a developer, you have crash logs or user reports and think APE is involved, email us: urgent@unsanity.com. We will look into each crash log and try to debug each problem. That's our responsibility and our job."
I have a lot of respect for Unsanity, and I'd probably run APE if I really wanted one of the hacks it enables. I do run other kinds of hacks. But notice that what you are claiming is *not* what Unsanity claims. They say that if an APE hack brings out a problem, then they'll take responsibility for tracking it down, which is great. What you're saying runs the risk of increasing anti-Unsanity sentiment, if anyone takes your position reflective of Unsanity's.
Posted by: foob at November 29, 2005 05:10 AM
"It's easy to duplicate yourself -- If you have any APE modules installed (I use ShapeShifter and DesktopSweeper), and force-quit a BareBones app, you'll see it. Doesn't matter if code is even being injected (I was curious enough that I tried it with it in the master exclude list), they're just setting a bit somewhere and looking for it and throwing that up."
Last I knew, APE is injected into every process, regardless of whether any APE modules are loaded. Ask a developer to fact check your posts.
Posted by: ssp at November 29, 2005 05:58 AM
OMG, this 'debate' looks rather f*cked up to me.
For a change it would be interesting to hear some actual facts about the whole APE situation. I don't doubt that problems with APE modules can occur. But how common are they? I have yet to see one happen myself (I have neither seen applications crash because of APE, nor have I received bug reports about my applications that could be blamed on APE) after years of using things like IceCoffee and FruitMenu – both of which I consider to be essential and more than just cosmetic improvements of the MacOS.
Has anybody actually seen any numbers on real-life problems? (Unsanity?) What kind of problems do application run into? (BareBones? Other developers?) Are these problems more of the kind that DB suggests, i.e. actual bugs that are only exposed by APE or problems that are introduced by APE? How often do they happen? Which applications do they happen with? And so on...
I feel that without answers to these questions it's pretty hard to reasonably discuss the topic. As it's not clear to me whether BareBones have a point with a rudely (and poorly) written error message attached to it or whether they're just upset at Unsanity.
Posted by: Davide Benini at November 29, 2005 06:35 AM
I just want to add that that alert message employs the jargon and habits of M$ windows: "hey, we really want to let you know there is an issue, even though this panel in a pain in the arse, we had to let you know." This is what drives me crazy when I have to use Windows.
I also agree to the fact that the GUI of BBedit is... (insert bad adjective here), it just has nothing to do at all with Mac Os X.
Davide
Posted by: mikeash at November 29, 2005 06:38 AM
1) Something in BBEdit works if you aren't using APE.2) If you use APE, it breaks.
3) This is BBEdit's fault.
Something about this logic confounds me.
Nobody is saying it's necessarily BBEdit's fault. However, it's not necessarily APE's fault either. Concluding fault after this simple test is extremely premature, and if a programmer from either side does it, then you know they're either very bad at debugging problems, or they are trying to weasel out of possibly fixing a problem of theirs.
Let me explain by discussing a similar thing that happened to me. I had a program that worked fine for most people, but for some people it just returned an error whenever they tried to open a new window. I was pretty confounded for quite a while, but finally discovered a common thread between all of the affected users: FileVault. Every user with this problem was using FileVault. Nobody without FileVault was affected, and disabling FileVault fixed the problem.
Now, who was at fault here? It was obviously me. The problem, for those wondering, is that I was storing a suid root helper tool in ~/Library/Application Support, but FileVault doesn't support suid root inside the home directory. I changed my app to store the suid root helper tool in /Library instead, and all was well. Do I blame Apple for breaking my app? Certainly not, I blame myself for not following Apple's guidelines, which say to put suid root helper tools in /Library.
Now, take my story, replace "FileVault" with "APE", and half the people posting comments to this story would instantly blame Unsanity.
The thing is, there's really two kinds of responsibility here, theoretical and practical.
In the theoretical sense, an application should follow only the published API behaviors documented by Apple. Any APE (or anything else, let's not kid ourselves by thinking that APE is the only technology that can break apps by playing in their memory) whose modifications are within that API contract is absolved of blame. If its change breaks the app, then the app was relying on something that it was not allowed to rely on anyway. It could have broken at any time, with even a minor system update, but the APE got to it first. Here, the APE is not the cause, it is merely the catalyst.
On the other hand, if an APE modifies something that falls outside of the API contract, even if it doesn't break any apps, it is in the wrong. Those apps could break at any moment, and the APE needs to be fixed, even if there are no broken apps now.
But from a practical sense, apps rely on undocumented behavior all the time. If an APE maker wants to make money, it is in his best interest to fix problems which aren't, in the theoretical sense, his fault. But app authors shouldn't be instantly dismissive either, because as I pointed out, it could be their app's problem, and wouldn't you rather fix it now than discover it the day before the Liger launch, when you notice that it's broken under the Liger Golden Master?
In the case of BBEdit, it's doing things that are way beyond the API contract. It crashed anyway, but APE exacerbated the problem and made it crash far more often. What does this mean? It means the user gets a crash, turns off APE as requested, no longer gets a crash, and BareBones tells them to go stuff it (but undoubtedly more politely). Yet, the bug was very much in BBEdit's court, and BBEdit could have broken horribly with (again) any new system update or new hardware. They were just lucky, and their dislike of APE led them to dismiss reports of a serious bug simply because they don't want to deal with it.
Now, it is certainly their right, or anybody's right, to ignore bug reports with APE in the name. But anyone who does this should expect some amount of customer backlash (who do your customers like more, you, or Unsanity?), and you should also expect to occasionally miss reports of a serious but hard-to-find bug.
So in conclusion, Unsanity should try very hard not to break apps (and they do), but app makers shouldn't just ignore crash reports with APE in them out of hand (and most of them don't). If they want to, that is their right, but they shouldn't be surprised when drunkenpeople post nasty stories about them to their blogs.
Posted by: Chucky at November 29, 2005 07:33 AM
"Now, I'll go back to my snowy street with bears all over it to drink some vodka and eat borscht."
Can you please wear one of those cool rabbit fur hats with the earflaps while you do so?
Posted by: aaron at November 29, 2005 08:51 AM
I am lead on a team that wrote a web app . .. . we CLEARLY state that it runs on the company standard platform. But we get bug reports all the time for issues when running on non-supported paltforms.
You know what we do? We bust ass to try to fix the issue. Why? We want our clients to be happy.
If I were BB in this case . . . I'd change teh alert window to read more as "try to run my app without haxies, see how that works. But send me the [haxie enabled] crash log anyway, we'll take a look and see what we can do. No promises, but hey man, we love you guys. You are the guys that push us to go that extra step and build a better product. Thanks! And hey . . . let's be careful out there."
Posted by: Roar at Jamie at November 29, 2005 12:34 PM
> Which album?
"2001" from Dr. Dre... good album but not in the top playlist of most geeks. :) Listening to the songs with the entry is hysterical, and changes the tone of the entry dramatically.
Posted by: Peter da Silva at November 29, 2005 02:55 PM
Oh man.
Let's see...
I think application developers can decide what they "should" do - based on maximizing their return on investment, or on any other criterion they choose. A developer may well choose to invest the extra effort to ensure that their app will work with APE and the more common haxies - if they think it is worth their while in terms of added sales or just good karma.
I'm an application developer, and when my application does something unexpected I still check to see if it's doing that because I did something wrong. If I can't find anything, then I may file it under "it doesn't work with 'foo'", but I'm still going to look at it. That's what "the assumption that if disabling APE fixes the problem the problem should be ignored." refers to. That doesn't mean I'm going to expect the developer to fix problems caused by APE, it means I expect the developer will make sure the problems are actually caused by APE.
And even though InputManagers are an accepted part of the standard environment, it seems to me that many of them are being used in ways that would not be approved of by Apple - i.e. they are being used to change the behaviour of apps instead of merely changing the way that text input is handled. Thus another standard troubleshooting step is to remove all InputManagers.
I'm not sure what you're getting at here. I didn't say that removing APE wasn't a valid troubleshooting technique, I said that removing APE should not be a requirement for the application to run.
And, yes, input managers are being used to do many of the same things as Haxies. I claim that point for my side: it's not APE that's the problem, if itdidn't exist people would simply duplicate it through supported but no safer interfaces.
Another writer...
I suggest you ask Jon Rentzsch and Brent Simmons what they think about this issue.
Jon Rentzsch has published and documented code to do the same kind of code injection that APE and haxies use. Some of the users.
And...
But notice that what you are claiming is *not* what Unsanity claims. They say that if an APE hack brings out a problem, then they'll take responsibility for tracking it down, which is great.
Yep, but the fact that they're willing to take responsibility for tracking the problem down doesn't mean the developer of the other product shouldn't also accept responsibility for determining whether they have a problem, nor that Unsanity may be able to fix the problem themselves.
And here's something I consider disturbing...
The problem, for those wondering, is that I was storing a suid root helper tool in ~/Library/Application Support, but FileVault doesn't support suid root inside the home directory.
If the file system Apple is using inside Filevault doesn't support setuid, that's a problem with Filevault. It's bad enough that HFS can bypass the UNIX security model as it is.
If I was ever tempted to use Failvault, you've just convinced me otherwise.
I blame myself for not following Apple's guidelines, which say to put suid root helper tools in /Library.
I generally end up, in my own computer, with setuid scripts in /Local/sbin, with /private/usr/local symlinked to /Local. this is the sanest way I've found to get standard UNIX tools working well with Mac OS X. If I'd Filevaulted /Local this would have broken, and it would have been Apple's fault. It would have been my responsibility to fix it, but Apple should not stick a file system that breaks standard UNIX semantics on a UNIX system.
But app authors shouldn't be instantly dismissive either, because as I pointed out, it could be their app's problem, and wouldn't you rather fix it now than discover it the day before the Liger launch, when you notice that it's broken under the Liger Golden Master?
Thank you for putting that so succinctly.
And I realise that I'm in the same boat, except that Apple seems to care about staying UNIX... and if Apple so badly breaks the standard UNIX environment on the Liger golden master, they can kiss their XServe market bye-bye.
Posted by: mikeash at November 29, 2005 03:43 PM
Standard UNIX semantics usually involves disabling the suid bit (using mount's nosuid option) for removable drives. FileVault is implemented using a virtual removable drive. Putting home directories on removable drives is nothing new in the UNIX world, and neither is disabling suid root binaries in home directories. Since FileVault does nothing outside of a user's home directory, it breaks no standard UNIX semantics, nor could it possibly break your /Local system.
FileVault is a scary, scary system for lots of reasons, but "breaks standard UNIX semantics" is not one of them.
Posted by: Cameron Hayne at November 29, 2005 06:54 PM
Peter da Silva wrote:
I'm not sure what you're getting at here. I didn't say that removing APE wasn't a valid troubleshooting technique, I said that removing APE should not be a requirement for the application to run.
And, yes, input managers are being used to do many of the same things as Haxies. I claim that point for my side: it's not APE that's the problem, if itdidn't exist people would simply duplicate it through supported but no safer interfaces.
You persist in using that word "should" without seeming to understand that what I am saying is that it is up to the application developers to decide their own behaviour and the behaviour of their apps.
Sure, I can agree that in an ideal world, application developers should make their apps bullet proof. But in the real world, I think we want to allow developers the freedom to produce apps that work in the standard environment and to specify that they don't support anything other than that. It isn't ideal, but I think even more restrictive conditions could be specified if the developer thinks it is necessary - e.g. they could specify that their app only works in English (if they discover bugs due to some strange interaction with non-latin text input or whatever).
Similarly, if some InputManager is discovered to cause problems that the application developer doesn't want to deal with (i.e. that cost more than the sales would warrant), I see nothing wrong with the developer specifying that the use of their app with this InputManager (or even all non-Apple InputManagers) is not supported.
Posted by: foob at November 30, 2005 05:10 AM
There's nothing unsupported about a kext or an InputManager, it's just that both (along with APE) are springboards from which one can perform actions that _are_ unsupported.
There do exist legitimate InputManagers.
Posted by: James Bailey at November 30, 2005 04:02 PM
Not much to add to this but that won't stop me. Rich Siegel is mostly right on this issue and DB is mostly wrong in my opinion.
The API is a contract of sorts. Developers spend long hours understanding where the API diverts from the written descriptions. Testing and debugging only to find out that the API doesn't quite work the way it is documented or that there is a bug that has a workaround that requires you to modify your code. Developers are used to this because they deal with it every day. On a platform as new as OS X these problems are exacerbated by the fact that OS X isn't done yet. Apple is adding APIs and whole subsystems at a furious pace and sometimes the documentation lags.
Now enter haxies that change the API contract. The long hours of study of frameworks and the OS are now less useful. The developer already spends way too much of his day doing tech support and then some unknown programmer has "injected" code into his application so that it no longer works. This is bound to make the developer at least a little unhappy Of course in an ideal world, the customer is always right. But the reality is that it is expensive to create and support software. Brent Simmons was ecstatic that he could stop doing support and start programming again when he bought NewsGator. He isn't alone. Tech support is the bane of all small development houses.
As for the edge case issue. There is no doubt that any and all software has bugs. But if you look at a company like Bare Bones that has been developing excellent software for the Mac for years v. a haxie author who is probably a relative newcomer to programming the Mac, I have to say that the odds of a haxie driving an edge case is much lower than the likelihood that the haxie is just flat out broken. Still, it behooves developers to work together and try to discover the problem. And it is entirely possible that even a mature application like BBEdit has an edge case problem that was previously unknown but the majority of the task has to go to the haxie developer. I think any reasonable analysis of haxies has to conclude that the majority of the problems are with the haxies and not an previously undiscovered edge case.
On the text of the dialog. Bare Bones may be overstating the case of what kind of help they can or can't provide but remember they aren't talking to you or me, they are talking to the average customer. If you've ever done any tech support you know what I mean. Trying to give people parameters of when they can or can't expect support for a third party hack is not really possible for most users. If a user really really wants a particular haxie to work, they almost certainly will follow up despite the dire warnings of a dialog box. I doubt that a seriously affected user will see it as a brick wall--after all they are paying for the software in most cases. But what Bare Bones has done is make the user do their own triage.
Ultimately though, DB is correct on one important point which is that the dialog box might discourage legitimate tech support cases. And to that, I say that Bare Bones ought to revise the dialog. Or probably better supply a weblink in the dialog to allow the user to click through and read a more thorough description of what options are available.
Oh, and not that it matters, I do develop software for a living. Most recently in Cocoa but not something you would have heard of. (since it isn't released.)
Posted by: Peter da Silva at December 1, 2005 03:48 PM
Similarly, if some InputManager is discovered to cause problems that the application developer doesn't want to deal with (i.e. that cost more than the sales would warrant), I see nothing wrong with the developer specifying that the use of their app with this InputManager (or even all non-Apple InputManagers) is not supported.
Read for content.
I have not argued that you must not do that. Or even that you should not do that.
In fact I said that this was a perfectly legitimate thing to do.
What I said was that if on top of this you didn't allow your application to run with some plug-in or extension, you better either make damn clear to the customer that you're doing it, or give them a full refund when they find out you're doing it after the fact.
That's the "social contract". Your software, your rules, my computer, my rules. If I'm going to pay for your software, your software better follow my rules. And if I'm going to expect you to support your software, I better follow your rules. It's pretty simple, you win, I win, what's the bleeding problem?
Now enter haxies that change the API contract.
If a Haxie changes the API, then it's got a bug. But that brings up another point, I'll get to that in a minute...
Standard UNIX semantics usually involves disabling the suid bit (using mount's nosuid option) for removable drives.
The security implicitions for external media do make abandoning standard UNIX filesystem semanics a worthwhile tradeoff, and so it's become the default on personal computer versions of UNIX. Similarly, CD-ROM media don't allow writing... there's good technical reasons for dropping that capability (though CD-booted systems often support a writable overlay file system to restore it). But where those reasons don't apply (as in the case of Filevault), then this doesn't apply.
That Apple's chosen not to do this right is Apple's problem.
The real problem is that you weren't programming portably and definsively. If you do that, you're unlikely to be bothered by Haxies or system upgrades or new environments. You chose to put setuid-root executables in a user's directory in the first place. That's bad practice for security reasons, and you should have put them in a system directory to start with. The setuid executables in a user's directory would typically be setuid to that user, not root... but I'll bet that Apple has simply mounted the filevault directory nosuid rather than distinguishing these two cases properly.
Unfortunately, that kind of programming isn't common in developers on PC operating systems because they think they have some kind of contract with the API, when in fact the API is subject to subtle changes all the time... and every OS update is accompanied by a regular stream of complaints about the software that's been broken this time around. Not to mention the complaints from users who find software that doesn't run on a localized system, or on unusual screen sizes, or if they're just using an unexpectedly large or small default font.
In the UNIX world you quickly learn the kinds of things to watch for, so when you find a program you wrote 25 years ago on a PDP-11 running v7 UNIX... and you compile it on a Mac running OSX... it runs.
Posted by: Jon H at December 3, 2005 04:55 AM
"But where those reasons don't apply (as in the case of Filevault), then this doesn't apply"
Er, why doesn't it apply in the case of FileVault? The risk is presumably that someone will drop an unauthorized suid program on a removable disk, mount it on another system, and run riot.
The same risk ought to exist with a mountable disk *image*, correct?
And if a FileVault volume is essentially a disk image, then the same risk applies. Perhaps a user could replace their FileVault image with one they created on another computer on which they have root access, and which contains suid root software.
Posted by: slava at December 3, 2005 05:44 AM
But if you look at a company like Bare Bones that has been developing excellent software for the Mac for years v. a haxie author who is probably a relative newcomer to programming the Mac, I have to say that the odds of a haxie driving an edge case is much lower than the likelihood that the haxie is just flat out broken.
Please don't get into the game of assumptions that any person or company making system enhancements such as haxies are 'kids' who are new to the system and scene. Most of us have been programming for Mac as long as, for example, BareBones. Take a look at St. Clair Software, for example. Default Folder and Default Folder X has been around for quite a while. Granted, maybe not as many years as Rich & Doesn't Suck Co, but still a respectable amount of time. The nature of the products don't mean it's done by incompetent programmers who don't understand the potential risks or issues associated with this kind of products.
Quite the contrary, most of the products of this kind are made by experienced programmers who understand what they are doing. This includes me, heh. ;)
Posted by: Peter da Silva at December 3, 2005 05:59 PM
Jon H: It doesn't apply in the case of Filevault because Filevault lives on the local disk and access to it is subject to the local security model. It can be given permissions such that the user can only modify it through Filevault itself, and so can't replace it with a boobytrapped copy. In that case, if a user can modify it and replace it with a bandit copy, then they have already broken security and don't need to.
Posted by: John M. at December 4, 2005 08:18 PM
I think asking developers to code around a system that has had its innermost functionality modified by something like APE would be well and fine *if* either source code was available or if there were good documentation for the changed functionality.
Are either of those things available for APE? I think they need to do something to help other developers if their app causes changes in the system that can affect other applications. Perhaps DB is mistaken in his assessment of who needs to clean up their edge case coding.
Posted by: John Welch at December 5, 2005 10:36 AM
So this really has nothing to do with Rich wanting people to try to replicate the bug sans APE...
It has to do with a badly written dialog box.
Because there seriously cannot be a problem with trying to ascertain if APE and the like are causing the bug OR causing it to happen more often. That's just sense.
There also can't seriously be a problem with a developer deciding that a bug that only causes problems when APE is used has less priority than a bug that is hitting people with a 'standard' OS config. Because that's triage. You have to do that.
So basically, this is DB and Rich snarking at each other over a badly written dialog.
oy
vey
What I'd like to know is why DB insists that his articles be only 3" wide, and make you scroll to the 4th layer of hell to read the whole thing. Maddox was right about that: http://www.thebestpageintheuniverse.net/c.cgi?u=banish
Posted by: Peter da Silva at December 5, 2005 11:23 AM
I think asking developers to code around a system that has had its innermost functionality modified by something like APE would be well and fine *if* either source code was available or if there were good documentation for the changed functionality.
If there's any changed functionality visible to a program that obeys it's side of the infamous "API Contract" then the Haxie has a bug in it. Conversely, if a program actually follows the documented interfaces there shouldn't BE any changed functionality.
So, really, Apple's documentation describes the functionality already, and documenting where it doesn't would actually mean documenting bugs. Most people would prefer they get fixed instead.
Posted by: James Bailey at December 5, 2005 07:45 PM
>If there's any changed functionality visible to a program that
>obeys it's side of the infamous "API Contract" then the Haxie has a
>bug in it.
Huh? Isn't that the point?
The claim is that most haxies that cause errors in applications that don't happen without the haxie is a bug. I'm not sure this adds much to the conversation.
Posted by: James Bailey at December 5, 2005 07:51 PM
>Please don't get into the game of assumptions that any
>person or company making system enhancements such
>as haxies are 'kids' who are new to the system and scene.
It was a generalization that may be unfounded for many haxie authors. But that kind of misses the point. Is there a mechanism for Bare Bones to vet certain haxies? If there is then you have a point and I did say in my post that it is a good thing for developers to cooperate. But if it isn't possible for an application to determine what haxies are installed (without a hack itself) then how can Bare Bones know if the code "injected" into their applications is written by experts?
I would still make a strong generalization that Bare Bones is much less likely to have an edge case driven by a haxie than for a haxie to have a bug itself that crashes the application.
Posted by: Peter da Silva at December 6, 2005 09:25 AM
James: if "most haxies" cause errors in an application, and most haxies don't cause errors in "most applications" (and, no, they don't) the odds are that the bugs aren't in the "most haxies".
And I would make a generalization that the odds are good that any Mac application that's been around more than a few years has all KINDS of edge cases simply because of its heritage. The classic Mac OS was such a nightmare design that you have to treat ported applications as if they'd been abused in childhood. They've got the emotional trauma of that experience indelibly baked into their psyche.
Finder, of course, is the poster boy for this problem.
Yeah, I was wondering if you'd have a response for his post.
For me the real kicker is that you found a bug that wouldn't have been found if you'd played by BareBones' rules (and it had been a BB bug). In some ways it doesn't matter whether you have a 'bias' or not, because the bottom line is that their way can cause real bugs to not be found, and that just seems like poor design to me.