Welcome to Hell... iHell that is...

[Darwin]

Wow! As Apple threads go - on DC or elsewhere - this one seems very tame to me. I'm surprised that justice and wraith are having such an adverse reaction to the discourse. If we're taking into account other Apple-related threads on DC, then I suppose the attitude could be defined as antagonisitc. However, I don't see the problem m'self... Personally, I like Apple products but loathe the company and the zealotry. I'm not a big Steven Jobs fan, either (yes, I think he is a genius - particularly at picking the "next big thing", producing it, and marketing his products - but that doesn't mean I have to like him  ).

Anyway, I'm not sure what's being objected to here. If voicing any dissenting view about Apple is "attitudinal" then label me as attitudinal! Overall, I"m a bit concerned about the undertone of censorship that I detect. I mean, c'mon - I'll recycle an analogy already used in this thread and put it to a different purpose: if we were slagging off Microsoft, would anyone raise a voice of dissent about it?

FWIW I own both Windows and OSX PCs along with an iPod Classic and an iPod Touch 4th Gen. Doesn't mean I have to drink the Kool-Aid, though.

[app103]

But as soon as there's big financial interest involved, and considering censorship and the license terms Apple enforces on the iPhone App store - ugh. And there's rumors that apple might be removing Flash and Java support for OS X...

-f0dder (October 22, 2010, 02:48 PM)

Nah, they're simply not bundling them with Lion, so if you want any of those two, you're on your own. It's not the brightest idea Apple ever had as, unlike the iPhone, you need Flash on desktop computers, and Oracle does not yet have a Java runtime for OS X, which it's in their best interest to get resolved soon, considering the number of Java developers working with Macs. In the end, it's just another step towards Apple absolute control over their own products.

-Lashiec (October 22, 2010, 03:16 PM)

I don't see a problem with this. Windows doesn't come with Flash and Java pre-installed either. Some OEMs do install it, but Windows itself doesn't come with it. What Apple would be doing is not something that represents having any more control than they did before. If anything, they are giving their users a little more control, protecting them (and themselves).

I can only speak here from the perspective of the Windows world when it comes to the effect that OEMs preinstalling Flash and Java has had.

By the time a user gets a new PC, often the pre-installed Flash and Java stuff is already outdated. And typical user behavior is not to upgrade stuff if whatever they want to do still works. So as long as the flash games on Facebook work and they can watch Youtube videos, they will keep the older version of Flash. The problem is that older versions of Flash and Java contain security vulnerabilities that are being exploited in the wild. There is a whole lot of malware getting on to users PC's because of this.

And really old versions of Java have an additional issue: upgrading it doesn't remove the older exploitable versions. Sure, they have improved this slightly and the latest installers do remove some of the older versions, but there is a point at which it stops and doesn't remove really ancient versions...the highly vulnerable and widely exploited 1.4 that so many OEMs still pre-install gets left on the machine to continue to be a security threat.

If OEMs didn't pre-install this stuff, then the user wouldn't likely have java or Flash on their machines unless they needed it and installed it themselves, and if/when they do, it will be the latest version and not something already outdated. Even if they are the typical user that doesn't update stuff unless they have a problem with it, they would still be better off starting with an up to date version rather than something pre-installed by the OEM.

If Apple's Macs become more popular, then it will be very important to their users experience not to have this old stuff on their systems. The more popular their OS becomes, the bigger target their users become, and the more malware we will see targeting them and the software they run. It would be a wise move for Apple not to repeat the mistakes made by OEMs in the PC world. And it would also be wise not to repeat the mistakes of Microsoft. (Does anyone remember what happened to MSJVM?)

[Darwin]

Hmm... interesting points, app. My understanding of the brouhaha over Apple and Flash was that Apple devices like the iPad and iPhone not only do not ship with Flash but their OS's don't support Flash, rendering the choice over whether to install it or not, moot?

[app103]

Hmm... interesting points, app. My understanding of the brouhaha over Apple and Flash was that Apple devices like the iPad and iPhone not only do not ship with Flash but their OS's don't support Flash, rendering the choice over whether to install it or not, moot?

-Darwin (October 23, 2010, 04:23 PM)

This doesn't refer to iPhone/iPad...it's about OSX, their desktop OS.

[Lashiec]

From an user's perspective, it may not change much, but for developers it's another thing. Apple did not bundle Sun's JVM with OS X, they developed its own version, just like Microsoft did, and would continue to do if they didn't ruin the whole thing. What's more, at one point Apple officially supported Java as a language suitable for developing OS X applications. Not anymore. Developers using Java now have to wait for Oracle to come up with a version of its own, which may or not suck more than Apple's own.

With Apple's security track record, non-bundling Flash and Java doesn't automatically make them invulnerable, they only have potentially fewer holes, but not many. And I say "potentially", because Flash had been autoupdating itself for a while and the JVM is updated via Apple Software Update, so in one case the infection window lasts at most a whole week, and in the second case, it's a matter of Apple to change its policies.

And finally, did you know the review guidelines for Apple's new App Store reject (among others) Java apps?

Who knows, in the end, it may not mean much, after all Microsoft used to bundle both Flash and their own JVM, and Windows hasn't become a less open platform that it was before, but Apple's control tendencies cannot be understated in things like this. In principle it's a good thing for Mac users that developers make good use of OS X features when developing applications, but in the long term you may be precluding them from using 3rd party tools which would make things easier for them, and we already saw a glimpse of such future with the abandoned iPhone app guidelines.

[Renegade]

And finally, did you know the review guidelines for Apple's new App Store reject (among others) Java apps?

-Lashiec (October 23, 2010, 05:24 PM)

Huh? Really?    I didn't see any guidelines so I didn't know.

They're excluding Java software? 

Sigh...

Just when you think it can't get any worse, it does.

I don't program in Java, but I certainly can't see excluding a major language as a good thing. Choice is good.

This is really what I'm worried about. I'm worried that Apple has gotten too powerful and their control-freakishness may infect other companies. I'm worried that down the road we may have our desktops, phones, laptops, TVs, cameras, and eventually homes all locked down into someone else's vision of what's good for us. (I include homes because home automation and the "digital home" is coming.)

Computers are being integrated into everything, and locking down and excluding people is simply NOT a good thing. This is what the FSF is all about. This is why there's a GPL. This is in part why organizations like the EFF exist.

But it doesn't matter... We are all throwing our money at the slavers, begging for bigger, better shackles.

If I'm guilty of starting a witch-hunt, I think it's for good reason. There are metaphorical witches out there, and they're not like Wendy.

Apple is pretty much THE leader out there. Asking which direction they are leading us in is, well... I suppose people have different opinions on that.

[Lashiec]

Huh? Really?     I didn't see any guidelines so I didn't know.

They're excluding Java software?  

Sigh...

Just when you think it can't get any worse, it does.

-Renegade (October 23, 2010, 07:34 PM)

And it gets much worse. I tell you, long-time OS X developers are not happy about it, for this and a myriad of other reasons.

On the other side, the sizable group of Java developers who settled on a Mac to set up their development environment are not only unhappy, but also a bit afraid with the Java decision, even though most, if not all of them, work on server-side Java products, not client applications. According to John Gruber even Apple uses Java for their web services.

This is really what I'm worried about. I'm worried that Apple has gotten too powerful and their control-freakishness may infect other companies. I'm worried that down the road we may have our desktops, phones, laptops, TVs, cameras, and eventually homes all locked down into someone else's vision of what's good for us. (I include homes because home automation and the "digital home" is coming.)

Oh, but we have been going down that road for a while. The thing is, one way or another, we will not reach the destination, as the market does not accept dumb boxes. What we don't know is how many locks it will accept.

[Renegade]

You're right.

But to be honest, I never thought Apple would be going this far.

Basically, if you want to develop for the Mac, you're nothing more than an unpaid employee a slave.

You cannot have copy protection.
You cannot use license keys.
You cannot use installer software, except for theirs.
You cannot have bugs. (All software has bugs.)
You cannot have placeholder text. (This is common to setup for future upgrades.)

WTF?


Here's some from the horse's mouth. I'm highlighting some ridiculous ones:

2.1   Apps that crash will be rejected
2.2   Apps that exhibit bugs will be rejected
2.3   Apps that do not perform as advertised by the developer will be rejected
2.4   Apps that include undocumented or hidden features inconsistent with the description of the app will be rejected
2.5   Apps that use non-public APIs will be rejected
2.6   Apps that are "beta", "demo", "trial", or "test" versions will be rejected
2.7   Apps that duplicate apps already in the App Store may be rejected, particularly if there are many of them
2.8   Apps that are not very useful or do not provide any lasting entertainment value may be rejected
2.9   Apps that are primarily marketing materials or advertisements will be rejected
2.10   Apps that are intended to provide trick or fake functionality that are not clearly marked as such will be rejected
2.11   Apps that encourage excessive consumption of alcohol or illegal substances, or encourage minors to consume alcohol or smoke cigarettes, will be rejected
2.12   Apps that provide incorrect diagnostic or other inaccurate device data will be rejected
2.13   Developers "spamming" the App Store with many versions of similar apps will be removed from the Mac Developer Program
2.14   Apps must be packaged and submitted using Apple's packaging technologies included in Xcode - no third party installers allowed
2.15   Apps must be self-contained, single application installation bundles, and cannot install code or resources in shared locations
2.16   Apps that download or install additional code or resources to add functionality or change their primary purpose will be rejected
2.17   Apps that download other standalone apps will be rejected
2.18   Apps that install kexts will be rejected
2.19   Apps that require license keys or implement their own copy protection will be rejected
2.20   Apps that present a license screen at launch will be rejected
2.21   Apps may not use update mechanisms outside of the App Store
2.22   Apps must contain all language support in a single app bundle (single binary multiple language)
2.23   Apps that spawn processes that continue to run after a user has quit the app without user consent will be rejected
2.24   Apps that use deprecated or optionally installed technologies (e.g., Java, Rosetta) will be rejected
2.25   Apps that do not run on the currently shipping OS will be rejected
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
2.27   Apps that request escalation to root privileges or use setuid attributes will be rejected
2.28   Apps that add their icons to the Dock or leave short cuts on the user desktop will be rejected
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
2.30   Apps that do not comply with the Mac OS X File System documentation will be rejected



Some are reasonable.

Most are not.

I think 2.5 is idiotic, but it's not "pure evil". There are legitimate reasons for that, though I doubt those are Apple's motivations. Microsoft discourages this, but doesn't ban it. The Microsoft reason is because their private APIs are basically ones that they've not completely made up their minds on, and they want to reserve it for later when they finalize details enough to make it public. This is nothing surprising if you've ever dealt with developing platforms.

Their use of "without user consent" is simply wrong. Take 2.26 for example. It's logical for some software to automatically launch at startup, and this would be the default correct behavior. Apple wants to stop that? It basically stops software from becoming useful.

2.15 is simply ridiculous. WTF are they thinking?

2.24 Yet another WTF moment. This is really very, very sinister. That list is massive. The implications are immense.

2.27 So, in other words, no system utility software? Right.

2.29 "Appropriate" APIs from Apple? Ahem... And what about hiring leprechauns to do our coding too? For those that are unaware, Apple APIs are extremely restrictive. They do not present ways to let you do things as other platforms do; they present ways to stop you from doing things. I cannot begin to express just how piss poor Apple is here. ----- On another note, this essentially stops having multiple applications that work together.

etc. etc. etc. etc.

There are simply too many cases for legitimate software that they have ruled out.

I'm simply stunned. This is far worse than the iOS 3.3.1 debacle.

Evil. Simply evil.

[Darwin]

Hmm... interesting points, app. My understanding of the brouhaha over Apple and Flash was that Apple devices like the iPad and iPhone not only do not ship with Flash but their OS's don't support Flash, rendering the choice over whether to install it or not, moot?

-Darwin (October 23, 2010, 04:23 PM)

This doesn't refer to iPhone/iPad...it's about OSX, their desktop OS.

-app103 (October 23, 2010, 04:45 PM)

Yes, I understood that. My point was that some posters here seemed to be under the impression that this would apply to the new version of OSX (Lion); I was trying (apparently unsuccessfully) to point out that this issue relates to the iPad/iPhone, not OSX.

[f0dder]

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.

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.

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.

2.25 is sensible, even if I'm not sure I entirely like it.

2.26 is sensible, since it includes the "without user consent".

2.27 is debatable, but most apps shouldn't be doing this. There are legitimate reasons, though, like doing full-system backups.

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?

2.30 makes sense as well. Don't you hate Windows apps that think they can write to wherever they want?

But there's a whole boatload of WTF in there.

[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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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 ), 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)

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.

[Eóin]

I'm sure though Apple want to manage the copy protection themselves, and that's why they're disallowing 3rd party solutions. I don't think that is an insane idea, but I don't like it myself either. Of couse I also hate DRM, some maybe banning it is a good thing?

As for presenting a license, I'm kinda with them on this one in that no one ever reads those things anyway + it's dubious if they'd ever really stand up in court. On the otherhand, if software is free I think it's very important that developers can clearly state

The software is provided "as is", without warranty of any kind, express or implied, including but not limited to the warranties of merchantability, fitness for a particular purpose... etc

There's a big difference between SQL Server going belly up and costing your business a fortune, versus MySQL doing so. And that difference is based around wether the supplier is for or non-profit. Companies shouldn't be able to "shirk-wrap agreement" themselves out of responsibility.