Happy New Year!
Happy New Year.
Not much more to say really :-)
November 2006 | Main | January 2007
Happy New Year.
Not much more to say really :-)
Merry Christmas, everyone.
Hope you’re all having a good time, wherever you are.
I just had someone suggest that we should take part in a scheme like MacHeist, but where we don’t get paid at all!
The cheek of it!
We’re expected to provide technical support (a significant drain on our time—and therefore a significant cost—as we sell disk utility software), and users will expect discounts on future upgrades.
Oh, and let’s not forget the 250MB+ bootable CD template images that each of these users would want to download. Quite a significant bandwidth cost, that; we already transfer hundreds of GBs a month, without thousands of people suddenly hitting us for free copies.
What’s even worse, the people in question weren’t sure whether they were organising one “heist” or many, and don’t really seem to know how many people they’re going to give the software away to. In fact, they haven’t really thought about it at all.
About the only saving grace is that they claim they won’t be making any money out of it.
Who are they? I’m not going to give them any publicity by saying. But I’d advise other developers to stay well away from this kind of deal. If you want publicity, go buy some advertising. It may look expensive but it’ll be cheaper in the long run, plus you’ll attract people who will actually pay for your apps.
I’ve been reading with some interest John Gruber’s comments about MacHeist and MacZot, as well as Gus Mueller's take on the situation.
JG’s analysis is, I think, spot on. MacHeist and MacZot are basically mechanisms for fleecing independent developers. I have no idea why anyone would agree to sell their app for a week for a fixed price rather than a percentage, especially when the organisers of the promotion are taking a percentage cut. It seems like bad business to me, especially when the developers will have to deal with the additional support that all of those users create.
And as for the argument that MacHeist and MacZot are in any way similar to a proper distributor, let me tell you: our Japanese distributor does way more work, including:
And they don’t ask for the kind of share of the profits that MacHeist are reportedly taking!
It’s patently ridiculous to argue that there is any benefit here to the apps’ developers. For the most part they aren’t going to get significant upgrade sales, and for many of the apps it isn’t even as if they need significant extra publicity in the marketplace.
There are some similarly silly arguments about how $5,000 is a lot of money for a single week’s sales. It actually isn’t, particularly when you consider that this isn’t ordinary sales; it’s a promotion. If it works properly, it should result in a lot of sales over a short period, and might actually cause a “sales drought” for a period thereafter (when you do these kinds of things, you, of course, hope to attract business that you wouldn’t otherwise have got… but many of these apps are already very competitively priced so I don’t see that happening here).
Someone even tried to compare it to conventional advertising, remarking “When was the last time you were paid to place an ad?” and commenting that:
“The people against MacHeist and similar things have never tried to buy exposure or ads or build a brand using traditional methods. MacHeist is not a new concept by any means, its [sic] just new to the Mac dev community who have, apparently, be [sic] squirreled away from the big bad world of real business.”
Hmmm. Well I’ll correct one thing straight up. I’m against MacHeist and MacZot, and I have bought ads—in fact, I recently spent thousands of dollars on an ad. campaign. I’m also involved with proper distributors who stick things in boxes on shelves, so I’m indirectly paying for “proper” advertising there too.
Anyway, the idea that MacHeist or MacZot are an ad. campaign is simply nonsense. When was the last time Jaguar ran an advertising campaign where they gave their cars away at an 80% discount to everyone who asked? <sarcasm>What’s that? They haven’t. Oh. I wonder why, I mean, it’s such an effective idea, right? And someone will even pay them $5,000 to do it for a week! That’s cheap advertising, right? I mean, it costs tens of thousands at least for a full-page advert in a broadsheet.</sarcasm>
If you believe that kind of tripe, you really don’t have a clue about business (ironically the person who wrote it finished their remarks by calling someone else’s business strategy “cr#p”). Advertising is advertising and promotions are promotions. MacHeist and MacZot are promotions, and—for the developers involved—assuming JG’s figures are right, bad ones.
One of the more unpleasant things that I’m cursed with is migraines. In my case they aren’t always hugely painful (they do hurt, though), but the thing that really upsets me is the “visual disturbance” that accompanies them (usually preceding the actual headache part). Worse, during the visual disturbance, I sometimes feel confused, which—for someone like me—is very frustrating indeed.
I have one going on at the moment, which is making it very difficult to write this post (I can hardly read it), and pretty much impossible to work :-(
lmh had posted not one, but two advisories about dmg related vulnerabilities in Mac OS X.
The first I’ve already dealt with, but since some people had combined the two issues into a single overall advisory, I thought I’d address the second one (CVE-2006-6062) as well.
This is much simpler than the first, which in a way makes it even less excusable to claim memory corruption when it doesn’t exist. However, in this case lmh didn’t claim that it allowed arbitrary code execution or make similar exaggerations. So, what is wrong here?
Well, what he’s done is he’s corrupted the Catalog File, which is a critical piece of filesystem metadata that tells HFS+ where things are on the disk. And the corruption in question means that it can’t find the root folder’s record. So whilst the call to VFS_MOUNT() in the mount() system call will succeed, when checkdirs() is subsequently called and tries to get a vnode for the filesystem root, VFS_ROOT() returns ENOENT, which triggers a kernel panic with the reason “mount: lost mount”.
Interestingly this particular problem is probably specific to HFS+, as most other filesystems wouldn’t be able to lose their root folder so easily.
So again, I don’t see any memory corruption. All you can do is trigger a kernel panic.
Let me be clear though; lmh didn’t claim that this was as serious as the other one. One thing he didn’t mention, however, about this bug (because he didn’t investigate it properly) is that it doesn’t just affect UDTO disk images… this is bug will trigger with suitably corrupted filesystems on any type of media, which could be annoying for an end user if it happens on their hard disk.
It seems I was wrong to blame Secunia for stating that they had verified or confirmed the dmg problem. So, my apologies to Secunia for that.
In my defence, the articles on which I based that remark (particularly the neowin.net post) look like and read like press releases, and until I pointed it out to them, I didn’t see any denial of the “validation” from Secunia, which is a shame.
Anyway, they have now denied having validated or confirmed the exploit and would like to point out that they did not, in fact, issue a press release about the issue.