« HAPPY BIRTHDAY DIANE!!! | Main | Dear Anti-Vaccination People »

So in the "You mean you can install stuff remotely" hall of stupid fuckers, we admit our newest entrant!

onOne Software, makers of Genuine Fractals 5 decided not to test their installer with Apple Remote Desktop at the login screen. Because in onOne's world, all installs are done with physical media by the artist.

Wrong.

So for those of you dealing with these idiots, just remember that an unhacked Genuine Fractals 5 installer will create a root Finder session on your machine. Do make sure to send them your love.

To fix, just comment out the osascript section at the end of the postflight script in the installer bundle.

Technorati Tags:
Incompetence, Installers MATTER, Security, Genuine Fractals' Installer

Comments

The tools to build installers are free as part of Xcode. Apple Remote Desktop costs $300 or $500, and is not free to developers.

You're blithely asserting that all installers require testing with a $300 tool that users may never encounter?

Technorati tag: The World Doesn't Revolve Around Bynkii

Posted by: Matt | May 24, 2008 9:48 PM

Yes, in-fucking-fact I am saying that. Because here's the deal. When sysadmins have a choice between products, (and we do *far* more often than you think), and one of them is written by devs who take the extra time and money to make sure that ego, (BEHOLD! THE GLORIOUS CONTENTS OF OUR APPLICATION FOLDER! GAZE AND BE AWED!!!) does not override good sense and installer practice, and one where installer decisions are made by people who can't be bothered to fully test their product, guess who loses, and guess who gets shite word of mouth between people who control the networks?

yeah.

Don't want to test your shit? Stop fucking developing for anyone but yourself. You want to charge real money, then test like a real professional.

Posted by: bynkii | May 24, 2008 11:09 PM

So are these guidelines for what not to do documented anywhere, or does everyone have to buy ARD and a second machine and just test it until they find something?

Posted by: Matt | May 25, 2008 5:30 PM

I don't know what Apple specifically publishes about installer guidelines. I know that any installers i've written, I've tested both in person and remotely first, because that's just what you do when you release software, you test it, even the installers.

I do know that this particular thing has been a very active pain point for a good 5 years now. Apple did something similar with the Quicktime Installer at one point. In every case, it was never a functional requirement, it was some idiot with no brains letting branding override common sense.

However, the answer is, yes, when you write an installer you test it with Apple Remote Desktop. You test it with SSH and the 'installer' command. You maybe download a demo of Casper or LANRev and test it there.

If you can't do that, you ask others, (Maybe you could call them, oh, BETA TESTERS) to test your installer for you.

I have yet to understand why the same people who will bitch up a storm about all sorts of bugs treat installer bugs like they have no meaning. Perhaps they need to have someone walk by a machine they're responsible for when there's a root session open at the login window and totally fuck up their network. That might show them what a shit installer setting can really do.

Posted by: bynkii | May 25, 2008 5:38 PM

And it's not even remotely (no pun intended) possible that they did beta test it, but none of the beta testers used ARD? Or Casper? Or LANRev?

I don't know who "the same people" you talk about are; I never said Installer bugs "have no meaning," and I remember you keeping your eyes open for the Flip4Mac people at WWDC 2006 when you intimated they were coming after you with prison weapons for your comments on the subject. But if this keeps happening, did it occur to you that there ought to be list somewhere of things that installers should not do? And that if these installers are following that list and screw up anyway, that said list should be, I don't know, revised?

I don't know who the strawman about "some people say" is directed at, but your complaints largely seem to me like "People are TEH STOOPID if they don't test with the tools I have to use every day," and that's called "the world doesn't revolve around bynkii."

So what comes next? Do developers have to buy every kind of hard drive and network card and test with them? Do they have to test the installer with and without Adobe Creative Suite already installed? Office 2008? How many different monitor sizes do they have to test? How many routers or wireless access points? How many different permutations of user privileges or ACLs, just in case someone has a system that doesn't work?

Developers can test random combinations of tools and hardware and configurations and see what happens, or there can be guidelines for what they should and should not do, and if staying without those guidelines causes problems, then the guidelines need to be rewritten or the underlying problems need to be fixed.

When you say that anyone who wants to build an installer should test with three or four high-end remote deployment systems that the developers don't need, don't use, and can't afford, it reads to me like you're saying that every time software draws a red rectangle, it has to be tested on every current monitor and printer to make sure it's really red, because apparently, "that's just what you do when you release software, you test it."

This way lies madness. Somewhere there has to be agreement that setting an RGB color of 0xFF0000 and drawing produces red, and if it doesn't, it's not the programmer's fault. If ARD and the "installer" command-line tool are not working correctly with perfectly legal installers, then ARD and the command-line tool are broken. If the installers are flawed, the installers need to be fixed. "Test every possible way someone might do something" is impractical to the way of ridiculousness.

I'm 100% on your side if you can show me some documentation somewhere that says "Note: if you want your installer package to work under ARD or with the 'installer' command, you need to follow these rules," and these people didn't do that. But if I'm writing a $15 shareware program and you're telling me I need $900 worth of remote access software just to test the installer, I'm telling you that you need to take your meds.

Yes, I know Genuine Fractals is not $15 shareware, but really, where does this end? What random products I don't use or need do I have to buy and test with, in your view, before I've done "enough?" Just the stuff you use, or everything in the Top 1000 chart of Mac sales? Where do you draw the line?

Posted by: Matt | May 25, 2008 10:59 PM

And it's not even remotely (no pun intended) possible that they did beta test it, but none of the beta testers used ARD? Or Casper? Or LANRev?

Oh, i'd say it's a guarantee that no one thought about remote/mass installs. Which tells me their testing program has problems.

I don't know who "the same people" you talk about are; I never said Installer bugs "have no meaning," and I remember you keeping your eyes open for the Flip4Mac people at WWDC 2006 when you intimated they were coming after you with prison weapons for your comments on the subject. But if this keeps happening, did it occur to you that there ought to be list somewhere of things that installers should not do? And that if these installers are following that list and screw up anyway, that said list should be, I don't know, revised?

There is Matt, it's called Google, it's called the Mac OS X Admin list. If Developers can't be arsed to do their own homework, then they best be crossing my palms with green, and lots of it, because if I'm going to have to do their thinking for them, Ima get paid and well.

I don't know who the strawman about "some people say" is directed at, but your complaints largely seem to me like "People are TEH STOOPID if they don't test with the tools I have to use every day," and that's called "the world doesn't revolve around bynkii."

That's right. I'm the ONLY PERSON IN THE WORLD WHO DOES REMOTE INSTALLS. Everyone else EVERYWHERE does EVERY INSTALLATION IN PERSON FROM PHYSICAL MEDIA.

No putting the installer on a network. No installing it on multiple machines at the same time. Nope. In fact, not many people know that I'm secretly a billionaire, and paid Apple to put the "installer" utility AND write Apple Remote Desktop, JUST SO I COULD BITCH ABOUT INSTALLERS.

You want to go on a sysadmin list and try that line of crap? Just warn me before you do, because I want to be close enough to the flames so that I don't need a microwave to cook my popcorn.

So what comes next? Do developers have to buy every kind of hard drive and network card and test with them? Do they have to test the installer with and without Adobe Creative Suite already installed? Office 2008? How many different monitor sizes do they have to test? How many routers or wireless access points? How many different permutations of user privileges or ACLs, just in case someone has a system that doesn't work?

Developers can test random combinations of tools and hardware and configurations and see what happens, or there can be guidelines for what they should and should not do, and if staying without those guidelines causes problems, then the guidelines need to be rewritten or the underlying problems need to be fixed.

If only there were guidance from Apple on such things. If only one could search the Apple developer site, and find guidelines called "Installing Your Application on Mac OS X: Guidelines for Developers". If only such a magical document contained a section like this one:Large Scale Deployments

In some environments software gets installed on more than one machine at a time, possibly using specialized tools. Apple Remote Desktop provides such a solution: it allows a system administrator to install software from a central location to multiple Macintosh computers on a network. In such large scale deployments, user interaction should be minimized. The problems start when an installer makes assumptions about where and how the software is being installed. For example, not everyone who installs software watches the process from start to finish. Lab administrators often must update hundreds of machines. It is convenient for an administrator to be able to start the installation from a single computer, let it run, and check back later for a status update. You should take this into account if there is any possibility that your software will be used in a school or business campus setting. An installation process that requires physical access to each machine, or continual intervention during the installation (perhaps to provide a serial number), is not a good idea in such a setting.

If only such a magical document, and other similar ones were available from Apple for free, what a bright shiny world we'd live in.

When you say that anyone who wants to build an installer should test with three or four high-end remote deployment systems that the developers don't need, don't use, and can't afford, it reads to me like you're saying that every time software draws a red rectangle, it has to be tested on every current monitor and printer to make sure it's really red, because apparently, "that's just what you do when you release software, you test it."

So you're saying it's perfectly fine to write an installer that, unless you install it in person with physical media, that creating huge security holes is just fine, because obviously, the dev can't be bothered with testing their installer in what is a common, normal situation for any network with over about ten machines?

You act like this is the exclusive domain of Fortune 100 companies. It's not. Remote/Managed installs are not only common, they're considered best practice by any sysadmin with more than a *very* small number of machines and any design on their sanity.

Yet somehow, it's beyond the pale to expect that devs realize that no, not every Mac is a solo flight.

I'm 100% on your side if you can show me some documentation somewhere that says "Note: if you want your installer package to work under ARD or with the 'installer' command, you need to follow these rules," and these people didn't do that. But if I'm writing a $15 shareware program and you're telling me I need $900 worth of remote access software just to test the installer, I'm telling you that you need to take your meds.

Then when your installer creates massive problems on a large scale, and you get the well-deserved hate mail calling you six kinds of a moron, the proper response on your part is "Suck it up Princess". You want to make assumptions about how your software is installed, that's your right. Your responsibility however, is to suck it up when those assumptions come home to roost.

Yes, I know Genuine Fractals is not $15 shareware, but really, where does this end? What random products I don't use or need do I have to buy and test with, in your view, before I've done "enough?" Just the stuff you use, or everything in the Top 1000 chart of Mac sales? Where do you draw the line?

the amusing thing is, by and large, shareware has the least amount of problems with shit installers. It takes a marketing department and meetings with nice shoes and no brains to decide that the most important thing in the world is to OPEN A FINDER WINDOW so that we can all GAZE UPON TEH GLOREE OF UR XAKYOOTABLE.

Every time I've ever seen this, and it's been still less than a handful, the answer to "What fucking idiot thought this was a good idea" is an arrow to a marketing department.

I don't care what you, or anyone else thinks about my evil idea that installers should not create root finder sessions at the login window. What this does mean is that this is the last version of this software I'll be recommending for a very long time, and I'll have more than a few sysadmins agreeing with me on this.

Unless you're going to advocate that security testing is bullshit, then the only vaguely valid gripe you have is that "ARD is not cheap". No, it's not. But neither is your application becoming the unbought poster child for bad installers.

Posted by: bynkii | May 26, 2008 12:09 AM

It only took you four comments to come up with the start of guidelines that I asked for in the beginning. What the frack took you so long?

Look, everything has bugs, everything has unintended consequences. To a degree, yes, suck it up, princess. All I asked you for is a simple list of things that a remote installer should not do. So far, you've provided me with a paragraph from Apple about philosophy, an instruction to google an entire mailing list, and a broad sense of entitlement that everyone should know exactly what to avoid when you can't seem to point me to a list of exactly what everyone should avoid.

"JUST READ MY MIND," cries bynkii, "AND ALL MY MAILING LISTS AND MY POSTS OR THE SYSADMINS WILL HURRRRRRT U!!!"

Well, ya know what, buster? If you want programmers to stop doing certain things, make a list of things they shouldn't do. I don't care if it comes from Apple or from you or a sysadmin mailing list or from Ben Stein in a documentary, but if you want to call people TEH STOOPID for not following guidelines to make remote installers work, then find some guidelines. One paragraph from Apple about philosophy and instructions to google an entire mailing list doesn't cut it, bucko. These people have things to do just like you do, not troll the internets endlessly for any hint that something they've done may be wrong.

For starters, you can file a bug with Apple noting that the paragraph about using the installer command-line utility is insufficient: if Genuine Fractals tried that, it probably worked just fine, because they were doing it within a login session. You'd have to do it over SSH to a machine sitting at the login window to expose the problem you never quite clearly state in this entire diatribe, namely, "sending an Apple event to the Finder to show your application in a window will cause Finder to launch behind loginwindow, owned by root, giving anyone with physical access to the machine complete access to every file on it."

So if I'm a developer and wonder if opening a Finder window is a bad idea, I google "installer open Finder window," and I get no results talking about how to do it or why not to do it.

(And you can fix it even without commenting out an osascript line; you can rewrite the script to only send the event to the Finder if it's already running. This, of course, then generates complaints from the people who use Path Finder, but that's one of those unintended consequences.)

I know how much fun you have stoking your white-hot rage over these things, but if you actually want them to stop happening in the future, you need something for developers beyond "think about large-scale deployments" and "test it with the command-line utility in your own login session." There need to be guidelines. As long as there aren't, I feel your pain but don't exactly know what you expect developers to do about it.

Oh, other than buying tons of unneeded products and googling huge mailing lists and generally trying to read your mind. And I'm not really saying anything you attribute to me in "so you're saying," but thanks for the effort. I'm saying that you're expecting developers to somehow know how to make installers that work on "any network with over about ten machines" even if they don't have a network with over, about, or under ten machines.

So we're back to "buy random hardware and products and hope bynkii doesn't yell at me." I prefer a slightly more deterministic procedure, and as someone who regularly extols science in these pages, I would hope you would too.

Posted by: Matt | May 26, 2008 10:28 PM

It only took you four comments to come up with the start of guidelines that I asked for in the beginning. What the frack took you so long?

Ex-cuse me? What, were your hands broke? Were you somehow rendered insensate this whole time? Someone scare you in your sleep with a picture of Steve Jobs, and now you can't go the fuck on Apple's developer site and fucking look it up your own damned self? What the fuck took ME so long? Did someone change the law and now I'm your motherfucking butler? I just checked, and my name still ain't fucking "Cadbury", so you best be dialin' that shit back just a tish.

What the fuck took me so long. Honkey please, you ain't payin' shit here, so you can just suck it up on how long it takes me to do a GOD-damned thing.

Look, everything has bugs, everything has unintended consequences. To a degree, yes, suck it up, princess. All I asked you for is a simple list of things that a remote installer should not do. So far, you've provided me with a paragraph from Apple about philosophy, an instruction to google an entire mailing list, and a broad sense of entitlement that everyone should know exactly what to avoid when you can't seem to point me to a list of exactly what everyone should avoid.

Oh, I'm sorry, I missed the announcement of "International John's fucking Job to do everyone's fucking homework for them Year". And for someone slinging that "entitlement" accusation around, you better check yo' OWN damned self there Mr. WAAAH, IT'S TOO HARD TO USE GOOOOOOOOOOOOGLE ALL BY YSELF! IT'S TOO HAAAAARD TO EXPECT PEOPLE TO READ THE APPLE GUIDELINES. WAAAH.

Entitlement indeed, look in the fucking mirror.

For starters, you can file a bug with Apple noting that the paragraph about using the installer command-line utility is insufficient: if Genuine Fractals tried that, it probably worked just fine, because they were doing it within a login session. You'd have to do it over SSH to a machine sitting at the login window to expose the problem you never quite clearly state in this entire diatribe, namely, "sending an Apple event to the Finder to show your application in a window will cause Finder to launch behind loginwindow, owned by root, giving anyone with physical access to the machine complete access to every file on it."

Wait, so it's APPLE'S JOB to make up for someone's shit test program? And MY JOB TOO? What the FUCK? Dude, I've been writing about this now, and filing fucking bugs about it too since 2006. I'd tell you what the results were from both Apple and the original perpetrators of this bullshit, but fuckit, you've already made up your mind about shit, so look it up your own fucking self.

What I learned from it was this: That whole "Oh, file a bug and people will rush to fix it" shit is just that. Shit. Marketing decisions do not now, nor will they ever get overrridden by mere technical issues. However, bad PR? Oh yeah, THAT gets listened to.

But I guess it's easier to assume that I'd never even tried the right way. Heaven knows, it's so fucking hard to ask.

So if I'm a developer and wonder if opening a Finder window is a bad idea, I google "installer open Finder window," and I get no results talking about how to do it or why not to do it.

"Hmm...Apple's installer guidelines talk about this ARD thing and installing software remotely. Maybe I should look into that, so that my installer works correctly there too"

NAH, THAT'S CRAZY TALK.

(And you can fix it even without commenting out an osascript line; you can rewrite the script to only send the event to the Finder if it's already running. This, of course, then generates complaints from the people who use Path Finder, but that's one of those unintended consequences.)

You'll find that as a group, sysadmins don't want stupid to work better, we want stupid to GO AWAY. That "opening the enclosing folder" shit? That's stupid. We don't want it to "work correctly", we don't want it there at all. That's a far more reliable fix and one we don't have to test but once. "Yep, installed fine without that bullshit". Your method means we now have to re-test that installer mod constantly for a non-critical function. Mmm...no.

I know how much fun you have stoking your white-hot rage over these things, but if you actually want them to stop happening in the future, you need something for developers beyond "think about large-scale deployments" and "test it with the command-line utility in your own login session." There need to be guidelines. As long as there aren't, I feel your pain but don't exactly know what you expect developers to do about it.

Oh gods yes, so much fun. Nothing like running back to my office at a dead run to furiously reboot machines so that root sessions are killed. It's what I live for.

But, since you asked, here's a paragraph I wrote on it:

For the love of god, don't make assumptions about your installer. They're probably going to be wrong. Talk to sysadmins who don't work for or with you. Find out about the vagaries of installing in a lab, in a corporate environment, in a higher ed environment. If you can't test, then ask for testers. We'll help you out. We tend to be assholes, but if we think we can help someone to not make our life suck, well, Booyah! Seriously, a badly written installer is just infuriating. One that does things that make it harder to use via Apple Remote Desktop or SSH make us want to find any other program but yours to use. When you're talking about installers, remember, less is more. Chances are, we're only ever going to double click install your work of art once. On our machine. Something that's popping dialogs, and borking the install with stupid questions, (by "Stupid", I mean "Any"), or any other behavior that hoses our ability to blast it on to 300 or 3000 machines at once will earn you our ire in great amounts. If you don't think this is a real issue, then please, install your software manually. 3000 times. While people are yelling at you about other random crap. Let me know how that works out for you. If you can't test the installer on a wide range of systems, ask for help. We would much rather spend time we don't have making our lives easier down the road than spend time we don't have dealing with crap that shouldn't be there. Oh yes, one other thing. Stop using VISE and InstallerMaker. They suck on the Mac if you're a sysadmin. If you must, i.e. gun at your head, whatever, then do one of two things: Create a way to remotely install your stuff, i.e. the "silent" install for Adobe CS 2, or create detailed log files so we can repackage your lame installer in something we can actually use, i.e. Microsoft updates. Don't just leave us with those nasty piles du feces, and expect us to be happy with them.

Ruh-roh. What do I do next, hold it for them and beg them to do the right thing THIS TIME? At what point do your poor, overworked developers have to do their own fucking work and think with their own fucking brains?

Oh, other than buying tons of unneeded products and googling huge mailing lists and generally trying to read your mind. And I'm not really saying anything you attribute to me in "so you're saying," but thanks for the effort. I'm saying that you're expecting developers to somehow know how to make installers that work on "any network with over about ten machines" even if they don't have a network with over, about, or under ten machines.

Unless a developer is really young, i.e. Ten, or never left the house, they've been around a network. A network with many programs installed. At some point, they need to think about such things, because I am fucking tired of thinking of such things for them. At some point THEY need to think about how you can install things, read Apple's guidelines and start asking about remote/mass installs. Because I tried the nice way a few times. Got ignored. When the carrot didn't work, I used the stick. You know what? The stick? The stick works REAL good. I am all about the effectiveness of a method, and if method a gets me ignored and method b gets results, I am going to stick with method b.

So we're back to "buy random hardware and products and hope bynkii doesn't yell at me." I prefer a slightly more deterministic procedure, and as someone who regularly extols science in these pages, I would hope you would too.

Real-world testing has indicated that bug reports about installer issues that don't actually prevent the product from being physically installed get ignored, whereas calling people out in public for doing stupid shit, and posting warnings about said stupid shit on select mailing lists do NOT get ignored.

Therefore, based on the results of my testing, my hypothesis that "Stupid Marketing Decisions don't get fixed unless you create bad PR about them" is holding up quite well.

I would remind you there is corollary about this for getting Apple off its ass about certain security issues. Just because the more effective method, (and by "more", I mean "only") isn't one you like doesn't invalidate it.

Posted by: bynkii | May 27, 2008 6:42 AM

So the positions here seem pretty clear:

You: "Everyone who makes an installer needs to test it with Apple Remote Desktop and maybe a few other remote installation tools. It matters not if these tools set them back $1000 or more and that they do not need or want them, they must purchase them and test with them. Or give the product free to people who do have these tools so they can test with them.:

Me: "Developers can't possibly test with all possible deployment combinations. That's why there need to be clear and specific guidelines saying what not to do, and there aren't. If you're actually interested in changing this, you should try to get such guidelines written and made easily findable. 'Test with all my shiznit' ain't gonna cut it, and you should know this."

You: "I don't care. I've written about it before, and making developer guidelines ain't my job, bum-ticker boy. Plus, I've written enough about it here and on other mailing lists that developers can find it all if they'll just use the damn google for a few hours on this issue. And if they have to do that on every issue, that's not my problem either."

I agree it shouldn't be your job, but if you actually want it to change, someone's going to have to write a list of do's and don'ts, and it's going to have to be someone who's experienced the "don'ts" and knows what to include for sure.

And at the risk of more white-hot nerdrage at the idea of an installer opening a window showing the program: you've never sat on the other side of this issue, when customers buy a program and then call/E-mail for tech support because after the installer was done, "nothing is happening." The program doesn't launch, they don't get instructions on how to launch the program, they're not told where the program is placed (/Applications seems obvious to us, but not to several of the family/friends for whom I'm Mac tech support), and they don't know what to do. It's a 50-50 bet they just try installing again, thinking they did something wrong.

You may not think others have to worry about the line between "insulting the pros and bumfuzzling the newbies," but actual developers do, and if you charge in with both barrels not realizing this, they'll likely ignore you.

So, hellboy, we agree there's a problem and that you shouldn't have to fix it. I'm just saying someone who has your kind of experience with it is going to have to start the do's and don'ts list, or it's not going to happen, and you'll be calling out more and more people here for making installers you hate.

Might I at least suggest that you visit the Installer session at WWDC this year and use the opportunity to ask with your trademark tact and delicacy exactly what Apple is going to do to stop this wholesale needless slaughter of sysadmin free time?

Posted by: Matt | May 27, 2008 2:28 PM

Me: "Developers can't possibly test with all possible deployment combinations. That's why there need to be clear and specific guidelines saying what not to do, and there aren't. If you're actually interested in changing this, you should try to get such guidelines written and made easily findable. 'Test with all my shiznit' ain't gonna cut it, and you should know this."

There are less than 5 products that aren't free that need to be tested with.

To be honest, there's only 2 that really count, because all the others are going to use the same procedure:

Apple Remote Desktop

ssh and the installer command-line utility.

ARD is not free, SSH is.

The fact that ARD is not cheap? Honestly, I don't care. My time is not cheap. It's not even close. But every time someone releases an installer that isn't properly tested, whose time do you think gets eaten at a prodigious rate? The developers?

No.

Mine and other sysadmins. Because when sysadmins report this bug back to them, the general rule is going to be "This friggin' line in postflight? It's evil and stupid, and stop it. It's causing root sessions at loginwindow."

That's assuming they are going to change it, and not say "We don't support remote installs, sucks to be you." Don't laugh, i've had that be a response.

If the dev cannot bother to live in the modern world, why the fuck should I do anything other than whereever possible, use a different product?

And at the risk of more white-hot nerdrage at the idea of an installer opening a window showing the program: you've never sat on the other side of this issue, when customers buy a program and then call/E-mail for tech support because after the installer was done, "nothing is happening." The program doesn't launch, they don't get instructions on how to launch the program, they're not told where the program is placed (/Applications seems obvious to us, but not to several of the family/friends for whom I'm Mac tech support), and they don't know what to do. It's a 50-50 bet they just try installing again, thinking they did something wrong.

You're telling me I've never done tech support for install issues?

Bullshit, you are not saying that.

I've done it, and in more environments than most. However, that still doesn't excuse opening security holes. As you pointed out, it is trivial, and I mean TRIVIAL to verify that the FInder is running. It's also trivial to verify that the Finder is running as the same user that started the installer application, so that you're doubly sure that you're not about to do something stupid.

Again, why is their not testing something I have to fix. There are guidelines. What they don't do is talk to you like you're fucking six and have to be told in explicit detail how to do anything. If Apple is going to do that, why have a dev program at all, because at that point, they're doing all the work anyway.

You may not think others have to worry about the line between "insulting the pros and bumfuzzling the newbies," but actual developers do, and if you charge in with both barrels not realizing this, they'll likely ignore you.

Like i give a fuck. I can delete their shit and ban it from the network for security reasons, and find an alternative. Validated security holes give me all the reason I need to ban software or hardware. Really.

I'm tired of playing this game over and over. Apple has sessions and information up on writing installers. There are tons of resources out there to tell you what not to do. The fact that they aren't delivered to devs along with a puppy and a kiss is not my problem in the least. I've tried reporting it with specifics, and got blown off once too often. So they can deal with a loss of sales and flames from now on. Really.

Might I at least suggest that you visit the Installer session at WWDC this year and use the opportunity to ask with your trademark tact and delicacy exactly what Apple is going to do to stop this wholesale needless slaughter of sysadmin free time?

I don't know what's more insulting, the fact that you think it's everyone BUT the developer's job to test their installers, or that Apple has to figure out a magic way to prevent installers from ever doing anything stupid no matter how determined the idiot making the attempt.

I talked to Apple, and they said that at a certain level, they cannot stop certain things from working, because if they do, it breaks all kinds of other things NOT caused by stupidity.

Posted by: John C. Welch | May 27, 2008 2:51 PM

"App doesn't do networked installs" equates to "app should be banned by any half-decent sysadmin".

Anyone wanting to sell that app is either happy that they will never sell to a networked environment, or they're working on getting it to install correctly. There are no other options that aren't based in utter stupidity.

It's interesting that the sales web site talks about volume licensing for their software. Well, not so much interesting as "So how are companies meant to install 50 copies of this?"

If it were shareware, I'd cut the dev some slack. It's not though. This is professional grade software with a hobbyist grade installer. That's just weak.

Posted by: GaryPatterson | May 29, 2008 8:26 AM

Post a comment

Thanks for signing in, . Now you can comment. (sign out)

(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)

URL:
Remember me? YesNo

Comments: