Main Area and Open Discussion > Living Room
Welcome to Hell... iHell that is...
Renegade:
f0dder, I think I should probably outline some of the reasons why I think those are bad ideas. Not all are obvious.
IMHO 2.14 isn't bad, as long as the Xcode packaging technology is sensible; after all, that's what enables a streamlined experience for all apps.
-f0dder (October 24, 2010, 10:27 AM)
--- End quote ---
I seriously doubt that it is. It's probably good for games and "most" programs, but I cannot see Apple making it robust for other software. If they had a robust standard and approved 3rd party installers, that would make more sense.
2.18 is probably sensible; most normal stuff really shouldn't be doing this - and the AppStore isn't intended for specialized stuff? of course once the AppStore becomes the only place to install software from, it's a problem.
-f0dder (October 24, 2010, 10:27 AM)
--- End quote ---
2.18 Apps that install kexts will be rejected
"kext" = Kernel EXTention. Then why are they running BSD? Dunno. It just seems like this is one of those areas that limits or excludes all low-level system utilities. I think a kext to replaced Finder would be wonderful, given how unstable/nightmarish Finder is; Finder makes Windows Explorer seem like Heaven (it's that bad).
2.21 is sensible - one of the things I hate about Windows is that apps have their individual update mechanisms, some requiring always-running crap.
-f0dder (October 24, 2010, 10:27 AM)
--- End quote ---
2.21 Apps may not use update mechanisms outside of the App Store
The always running nonsense like Java and Adobe Reader are certainly annoying, but I seriously doubt that Apple can provide a robust solution to meet the needs out there. Developers will end up hacking stuff up. If Apple provided a robust set of functionality that could be reasonably used, this wouldn't be a problem. They don't. Apple developer tools are entirely substandard.
2.25 is sensible, even if I'm not sure I entirely like it.
-f0dder (October 24, 2010, 10:27 AM)
--- End quote ---
2.25 Apps that do not run on the currently shipping OS will be rejected
Not everyone updates to the latest OS, and there are specialized issues for each one. So why this? It doesn't make sense. In a perfect world, sure.
2.26 is sensible, since it includes the "without user consent".
-f0dder (October 24, 2010, 10:27 AM)
--- End quote ---
2.26 Apps that are set to auto-launch or to have other code automatically run at startup or login without user consent will be rejected
I choked a bit on this one. Then I thought about it again, and thought no - this needs to be there. The reason being that it eliminates all software that uses an agent. This effectively eliminates all enterprise software. It's simply a blanket that's too broad. When you install certain kinds of software, this is implicit. Adding a consent question for the user relies on Apple's installer being robust, and simply asks the question again. For a lot of software though, this should rule them out. But it should not cover agent software, which it does.
2.27 is debatable, but most apps shouldn't be doing this. There are legitimate reasons, though, like doing full-system backups.
-f0dder (October 24, 2010, 10:27 AM)
--- End quote ---
2.27 Apps that request escalation to root privileges or use setuid attributes will be rejected
Exactly. This precludes low-level system utilities, like backup software.
2.29 makes sense, as it keeps apps working even if underlying details are changed. Don't you hate Windows developers who think that "C:\Progra~1" will always refer to the user's program files folder?
-f0dder (October 24, 2010, 10:27 AM)
--- End quote ---
2.29 Apps that do not use the appropriate Mac OS X APIs for modifying user data stored by other apps (e.g bookmarks, Address Book or Calendar entries) will be rejected
I waffled on this one as well. The standardized ways are usually the best, but Apple doesn't make certain things possible. e.g. It was only recently that Apple opened up its video and graphics API enough to allow Adobe access to hardware acceleration needed for Flash. As for "C:\Progra~1"... Sigh... That's just silly when developers do it. i.e. Environment.SpecialFolder is the right way, the easy way, and the robust way. Apple doesn't have a track record for being open or making things easy, so I can't see this as a good thing. What it really says is:
2.29 Apps that modify user data stored by other apps will be rejected unless they stick to our rigid, limiting ways of doing things
Now, for the Addressbook or Calendar, this makes sense. But for a blanket statement across all software, which it is, doesn't make sense.
This precludes the concept of software suites. You can no longer have a suite of software that interoperates with different components of the suite.
Again, useful for a lot of things, but too broad and limiting.
2.30 makes sense as well. Don't you hate Windows apps that think they can write to wherever they want?
-f0dder (October 24, 2010, 10:27 AM)
--- End quote ---
2.30 Apps that do not comply with the Mac OS X File System documentation will be rejected
Again, this is one that I waffle on.
But I still think it's a bad idea. Here's a concrete example...
Mac OS X is simply very bad with external USB storage. It cannot maintain a connection to a device, much less read from them at acceptable levels. The only way to fix this would be to have a low-level fix, which would require access to system resources, and hence, system areas of the computer, which 2.30 excludes. It could/would also require exceptions for 2.15, 2.18, 2.21, 2.24, 2.25, 2.26 and/or 2.27.
But there's a whole boatload of WTF in there.
-f0dder (October 24, 2010, 10:27 AM)
--- End quote ---
Absolutely.
The biggest problem is that they are wide-sweeping generalizations that preclude entire genres of legitimate software. They're throwing the baby out with the bath water.
Now, if Apple were a reasonable company, I'd be much more relaxed about it and count on them to not be morons about it, believing that legitimate system tools, agents, and other legitimate software could be developed for OS X. But Apple has a proven track record of not being reasonable. They've proved themselves to be inflexible and simply irrational again and again and again and again and again and again and again and I'm getting tired of listing so many... We all get the idea.
Basically, I see that list as a weapon for Apple to club developers with, and not a way to protect people from malicious software. The iTunes store has been hacked anyways. Apple isn't looking out for customers. It's looking for ways to stuff more cash in its pockets.
f0dder:
I seriously doubt that it is. It's probably good for games and "most" programs, but I cannot see Apple making it robust for other software. If they had a robust standard and approved 3rd party installers, that would make more sense.-Renegade (October 24, 2010, 04:50 PM)
--- End quote ---
It works for linux distros, doesn't it?
On Windows, I'm pretty annoyed at the various installers that are around - I really don't care for fancy looks for installers, I'd like something lean_and_mean with a sensible, clean interface. On Windows we get the full range from gradient-colored full-screen win9x looking yuck, OK looking installers that don't let you specify install location entirely as you wish, over-the-top crap (game installers... no, I don't want a custom-skinned app showing images or videos, I just want the damn thing to finish ASAP so I can play the thing!), to horribly overcomplex crap (SQL Server 2008, I'm looking at you!). Give me something standardized and clean. Sure, some degree of configurability is needed, and finding the sweet spot is going to be hard... but program installation should definitely not look very different from app to app. Heck, for stuff that doesn't need component selection, make it a one-click experience. Configuration can be done after installation if defaults aren't good enough. For bonus points: support automated installation of a whole bundle of applications, and an option for component selection and initial configuration from user-supplied XML files.
Microsoft has tried steamlining the experience somewhat through the use of MSI... but people are still writing annoying custom installers on top of that, and for some reason MSI installs always seem to be ungodly slow. Sure, I don't want a failed installation to leave junk behind, but ugh.
"kext" = Kernel EXTention. Then why are they running BSD? Dunno. It just seems like this is one of those areas that limits or excludes all low-level system utilities. I think a kext to replaced Finder would be wonderful, given how unstable/nightmarish Finder is; Finder makes Windows Explorer seem like Heaven (it's that bad).-Renegade (October 24, 2010, 04:50 PM)
--- End quote ---
Perhaps I've misunderstood what kexts are, but I thought they're - more or less - equivalent to a Windows driver: code that's going to run ring0 have have full system privileges. You really don't need that for normal apps, and I can't see why you'd need one to replace Finder - a normal ring3 app O_o
Sure, some system level utilities might need drivers, but it's going to be very few. Root privileges is a completely different matter.
The always running nonsense like Java and Adobe Reader are certainly annoying, but I seriously doubt that Apple can provide a robust solution to meet the needs out there. Developers will end up hacking stuff up. If Apple provided a robust set of functionality that could be reasonably used, this wouldn't be a problem. They don't. Apple developer tools are entirely substandard.-Renegade (October 24, 2010, 04:50 PM)
--- End quote ---
The linux repositories can handle it, so why shouldn't Apple be able to? There might be stuff that has to be changed, but imho the idea of centralizing updates is nice... applications might have to be allowed to either set an update interval, or poll themselves, but please rid us of the countless background processes and per-app steps for applying updates.
2.25 is sensible, even if I'm not sure I entirely like it.
-f0dder (October 24, 2010, 10:27 AM)
--- End quote ---
2.25 Apps that do not run on the currently shipping OS will be rejected
Not everyone updates to the latest OS, and there are specialized issues for each one. So why this? It doesn't make sense. In a perfect world, sure.-Renegade (October 24, 2010, 04:50 PM)
--- End quote ---
Requiring that an apps runs on the latest OS doesn't prevent it from running on previous OSes, unless Apple is doing something very fishy... and I assume the AppStore will be OS X only, so we can exclude trying to support both System 9 and OS X :)
Sure, it does mean developers will have to test their stuff on latest-and-greatest - but IMHO that's not really a bad requirement. People tend to get pissed off if they upgrade their OS and it breaks their apps.
2.26 Apps that are set to auto-launch or to have other code automatically run at startup or login without user consent will be rejected
I choked a bit on this one. Then I thought about it again, and thought no - this needs to be there. The reason being that it eliminates all software that uses an agent. This effectively eliminates all enterprise software. It's simply a blanket that's too broad. When you install certain kinds of software, this is implicit. Adding a consent question for the user relies on Apple's installer being robust, and simply asks the question again. For a lot of software though, this should rule them out. But it should not cover agent software, which it does.-Renegade (October 24, 2010, 04:50 PM)
--- End quote ---
If I'm running an app where I don't expect agent software to run, I'd like being prompted about it. If I'm expecting agent software to run, I wouldn't mind ticking off a checkbox and ignoring an EULA. (Hopefully, instead of EULAs it could be a short description of what needs to run... perhaps backed by an EULA to keep the vultures happy).
2.27 Apps that request escalation to root privileges or use setuid attributes will be rejected
Exactly. This precludes low-level system utilities, like backup software.-Renegade (October 24, 2010, 04:50 PM)
--- End quote ---
Yep. But I'm still not 100% sure whether it's an acceptable requirement or not... if the AppStore is going to be the one-and-only source of applications, it's definitely bad. If it's only targetting "normal" apps, it's definitely a legitimate requirement. I'd probable prefer something inbetween, like marking root-requring apps with a big fat warning and requiring the user to tick a checkbox during install.
2.29 Apps that do not use the appropriate Mac OS X APIs for modifying user data stored by other apps (e.g bookmarks, Address Book or Calendar entries) will be rejected
I waffled on this one as well. The standardized ways are usually the best, but Apple doesn't make certain things possible. e.g. It was only recently that Apple opened up its video and graphics API enough to allow Adobe access to hardware acceleration needed for Flash.-Renegade (October 24, 2010, 04:50 PM)
--- End quote ---
What does the graphics API have to do with "user data stored by other apps"? :)
Apple doesn't have a track record for being open or making things easy, so I can't see this as a good thing. What it really says is:
2.29 Apps that modify user data stored by other apps will be rejected unless they stick to our rigid, limiting ways of doing things
Now, for the Addressbook or Calendar, this makes sense. But for a blanket statement across all software, which it is, doesn't make sense.
This precludes the concept of software suites. You can no longer have a suite of software that interoperates with different components of the suite.-Renegade (October 24, 2010, 04:50 PM)
--- End quote ---
OK, perhaps it is too broad... while I doubt it would be used against app suites, it would make application interop between vendors harder. OTOH, the rule says modify, not access, so you should still be able to import data from other apps.
What I'd want is "use the standard locations and APIs, and don't clobber other app's data, you fool!".
2.30 Apps that do not comply with the Mac OS X File System documentation will be rejected
Again, this is one that I waffle on.
But I still think it's a bad idea. Here's a concrete example...
Mac OS X is simply very bad with external USB storage. It cannot maintain a connection to a device, much less read from them at acceptable levels. The only way to fix this would be to have a low-level fix, which would require access to system resources, and hence, system areas of the computer, which 2.30 excludes. It could/would also require exceptions for 2.15, 2.18, 2.21, 2.24, 2.25, 2.26 and/or 2.27.-Renegade (October 24, 2010, 04:50 PM)
--- End quote ---
I don't see how 2.30 has anything to do with flaky USB - unless "File System documentation" means something completely different in Apple-land, it would mean (the mac equivalent of) "stuff binaries in /usr/bin, user data in /home/user, don't spread your crap all over the filesystem".
A fix for handling USB storage badly would mean fixing kernel code, whether it be sloppy architecture or a bad driver. Not something a third-party developer should attempt hacking together as a kext...
The biggest problem is that they are wide-sweeping generalizations that preclude entire genres of legitimate software. They're throwing the baby out with the bath water.-Renegade (October 24, 2010, 04:50 PM)
--- End quote ---
That they're very broad is problematic - from the list I would have assumed it's just an overview, with details for each point being available?
Basically, I see that list as a weapon for Apple to club developers with, and not a way to protect people from malicious software.-Renegade (October 24, 2010, 04:50 PM)
--- End quote ---
And I wouldn't be surprised at all if that's what they're going to do... so yes, in the context of Apple being Apple and the broadness of the rules, the points I've commented on are... problematic. But, at least if narrowed in scope (and perhaps if applied by somebody not Apple :P), I still don't think the requirements are bad.
Shades:
@Fodder:
Every time I see 'Server' in the name of any Microsoft product, I get a headache. Not only do the installation method and installer change per version, their dependencies and the correct order in which these have to be installed (BizzTalk, Exchange 2k7 on Win2008), make me clench the aspirins again...after all the banging head against the wall.
Side note:
One can buy the 1000 milligram pill in sets of ten here at supermarkets for about 1 euro (no placebos), while in Holland you need a doctors prescription to get any aspirin above 500 milligram at licensed drug stores and it costs significantly more.
Eóin:
Conditions 2.16 & 2.17 are what raise alarm bells in my mind. Seem like the first step in another walled garden.
Though as I said before, I don't believe Apple could succeed in locking out 3rd party sources of applications. I'd probably like to see them try however, it'd be nice to see the fanboi reactions.
Renegade:
I still don't think the requirements are bad.
-f0dder (October 24, 2010, 06:25 PM)
--- End quote ---
To be honest, I wouldn't worry about them so much if it weren't Apple. The license and copy protection stuff along with a few others are simply beyond insane, but a lot of the ones I highlighted would be fine in a sane universe.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version