The iPad has a pretty nice Microsoft Remote Desktop client that I use when I need to quickly build a Windows project, or view logs from one of our Windows servers. Not really a complete solution, as obviously the standard bandwidth limits apply. If I'm on 3G or slow wifi it's borderline unusable. Still nice to have the option I suppose.
"Unlike employees, students don't need occasional access to random websites. Teachers know weeks in advance what their classes will entail, and can forward desired openings to the IT dept."
In a perfect world, yes. But you would not believe how many teachers make 0 hour requests for things to be opened with the backing of the principal. But yes, we did liberally use white lists.
This still does not solve the issues of games, local servers running over our constrained wifi, or porn brought in from outside. Or viruses brought in from outside.
We tried allowing students to bring in their own laptops. It simply never worked. It just ended up causing arguments with parents (try telling a parent they need to buy a $1000 copy of CS5 for the design class they enrolled their kid into, and then try explaining to them that GIMP is not part of the curriculum, nor will the teacher be teaching to GIMP. And the software is mandated by state accreditation for the classes.) In addition, these laptops were frequently the cause of security intrusions into our network, and were also often used as gaming machines at school. We would also have to spend unnecessary time rigging up outside machines with our ldap database, our printers (which were not postscript), our wifi (we used 802.11a, not exactly standard), and our file servers.
It just isn't worth the thousands of dollars in tax payer money spent configuring a machine for someone because they're offended by our choice in operating system. I understand that people would like to use the laptops they already have, but when you're looking at spending at least a few hundred dollars for the software we use, assuming that the software is even available for your platform of choice, plus the thousands of dollars that will be spent by taxpayers maintaining your system, it's simply not sustainable.
"I don't think a laptop is a right, nor should it be a babysitter to substitute for instruction. Also I'm sure people will steal/break/etc. them on purpose. Every school has the bully, the criminal, the drug addict, basically all sorts of scum.... A laptop would fetch good drug money for the addict. Even if I had said laptop when I was 16 or 17, I wouldn't want to bring it to school."
I don't think anyone sees the laptop as a babysitter, or a substitute for good teachers, much as no one sees a calculator as a babysitter in a math class.
It's a teaching aide, and in theory, it aides students in organizing their work, and saves schools money for buying things such as textbooks (digital books are cheaper and require no upkeep.)
"What will happen is that the school will go on a censorship binge after catching people looking at porn, downloading music, etc.. Then kids will get in trouble who would have been fine if they never had the laptop in the first place.... Then people will circumvent/resent the filters, the administration will race to get more security, and even less work will get done..."
True, but in working in the industry, the kids who get in trouble for this sort of thing are always the kids who would have caused trouble in a different way, but now you've given them a different tool to cause issues. It's not like you handed them a laptop and it suddenly make them decide to do bad things, they already were troubled before they got the laptop.
Honestly, we weren't worried very much about software side abuse, but we did want the ability to regain control if we needed to, hence the hooks into everyone's machines. If a parent wanted something done, we needed the ability to make it happen without making the 5 o'clock news.
(And no, we didn't have runaway software that took pictures of the students. That's just abuse.)
"But according to the article, these would be privately-owned laptops. Meaning that the IT staff at the school couldn't reasonably expect to SSH and stop unauthorized use, since they would have no reasonable expectation of knowing the laptop's su password. I know if my child's school required this, I would make damn sure that I locked it down to where the school couldn't do anything on it. The loaners are a different story, but then they should be locked down anyway to prevent abuse."
And this is the exact problem. If your child is running Bittorrent at school, and we have no way of controlling this, then your child's laptop cannot be allowed onto school grounds.
I know you see the school district not being allowed administrative access into a laptop as a good thing, but we can't allow equipment onto school grounds that could subvert our network or school policy. Just as if you were running IT for a company, you wouldn't let people bring in whatever they wanted and plug it into the network.
The biggest problem, as far as behavior goes, is that when you simply hand a kid a laptop, they think it's a right, not a privilege. They abuse the hardware, they abuse the usage... They void the warranty and then are shocked, SHOCKED, when the damage they caused is not covered for free.
Really, the only way these programs will work is if the students/parents are held more responsible. Maybe if they want to take it home they should be required to make a very significant deposit on the laptop.
But in a way, you have a good point. It's just sad because I have seen some kids, when given the laptop, do really amazing things on it. Maybe most teenagers just can't handle the responsibility.
Because the school likes dealing with one set of software and one set of file formats.
iLife may have an equivalent piece of software on Windows, but it does no good if the teacher doesn't know the software and can't work with the student on it, the software has slightly different features, or has different file formats.
I used to work on a one to one program, and while I sympathized with people who came to me in this position, it simply wasn't worth the thousands of dollars in tax payer money to run back and forth and resolve the problems that came up, in addition to us not being able to administer personal laptops. (How do we stop kids from viewing porn or playing games on personal laptops? Or downloading torrents sapping our bandwidth? We can't. On our machines we just track down the machine, log in with SSH, and put a stop to it.)
"Nothing except officially blessed Quicktime components could do H.264 acceleration on OSX until now despite Apple's claims. Even other plugins working through the Quicktime framework were denied access. "
I'm pretty sure that's just what I said... QTKit is the QuickTime X API, and CoreAnimation works on top of that...
Both of which would have been perfectly suitable for Adobe to use. QTKit can play into an OpenGL context.
The worst part about this is Apple already had two APIs, QTKit and CoreAnimation, that could both do hardware accelerated H.264. Adobe bitched and moaned until they got low level access for no apparent reason.
It seriously pissed me off every time Adobe whined about "no 3rd party H.264 support" on Mac. Apple even had several sessions at WWDC in years prior about how to enable it in your apps.
"Uh, no. Google is crying "Foul!" because Apple is banning developers from using Google's ad platform in their apps."
Apple isn't banning Google's ad platform. They're blocking Google from collecting equipment stats with said data, because Google isn't a dedicated ad company.
Something is weird with either MS's UEFI implementation, or Apple's. On my Macbook Pro, EFI sees Windows 7 64 as a valid EFI boot, but when I attempt to boot into it, it just hangs.
So, needless to say, I've had issues getting Win7 to EFI boot.
It was odd seeing a Mozilla dev talking about them fully supporting HTML5. They may support almost as many features, but they all run like ass. Seriously, most HTML5 demos I see on Firefox aren't unusable because some feature isn't implement, but that they are just far too slow.
Safari's and Chrome's JavaScript engines are running circles around Firefox right now. I don't know why anyone interesting in HTML5 would even bother with Firefox. WebKit is eating their lunch.
iPhone however does have KVO, KVN, and dynamically generated keys (valueForKey, setValueForKey), all of which doesn't work with linking by address.
You are supposed to write your network code using CFNetwork and BSD sockets. This is as intended. This is also why Cocoa sockets are actually just loosely wrapped CoreFoundation sockets.
Obj-C is like a screwdriver. You're trying to use a screwdriver like a hammer, and then loudly complaining about it. I'm telling you it's a screwdriver, not a hammer, and that's how it's intended.
Obj-C is a language for quickly building GUIs. It's not a language for programming the logic. Apple recommends you use C for logic. Apple codes Cocoa itself in C and C++. Obj-C was in no way and shape build for performance situations. That doesn't mean it's a bad language. The things you regard as deficiencies actually make it an extremely strong language for GUI construction. This is also why Apple doesn't try to force you to use ONLY Obj-C.
Storing objects by name is an EXTREMELY important feature in Obj-C. Yes, it's slow, but as I've said, don't use Obj-C for performance code.
"There is nothing there that a table of functions pointers along with compiler generated indices for methods/properties, linker/loader address bindings and on rare occasions OS APIs that provide access to these function pointer tables (Windows has such capabilities), cannot accomplish 300-500 times faster (yep, I had single stepped through their method calls & getters/setters, KVO/KVC processing,... and watched tasks that any decent compiler turns into one or two instructions explode into many hundreds of instructions through their runtime interpreter every time you invoke the "feature")."
Again, you're not understanding the language.
Using things like KVO/Bindings and distributed objects REQUIRES that the functions be addressed by name, not by address.
Honestly, if you're using Obj-C as a performance language, you're an idiot. Notice how Objective C has no low level primitives? No basic math functions? No OpenGL abstraction? It's mean to be used as a GUI binding language. This is why in Objective C you are supposed to use C code for your logic (or C++ code if you're so inclined) and then Objective C for your GUI. Objective C was in no shape or form designed for low level logic. This is not a deficiency. This is because it makes a damn good language for doing GUIs.
The reason there is no linking by address is because a GUI needs to dynamically bind against different sections of code by NAME, not by address. In addition, Objective C supports dynamically adding and removing key values at runtime, which again, goes completely against linking by address.
You clearly don't know what you are talking about, which is probably why you were shut down on the Apple forum. Learn some KVO and bindings on the Mac, understand what Obj-C is for, and then you'll understand why Apple made the design decisions they did.
"Even though it is nominally a compiled language, all the calls to methods as well as accesses to class properties are interpreted -- the name of the method & its args (args have names) is looked up in a hash table by runtime interpreter to find the address, then to push args and call it, every time you invoke it or access a property."
Learn KVO and bindings. Then you'll understand why this is done.
Not understanding the purpose of a language feature is no excuse to bash it.
Except that the users do not have the freedom to exercise their rights under the GPL, which include being able to redistribute modified versions of the software without limits or royalty payments. For a user of this application to modify it and redistribute the modified version to an unlimited number of persons, they would have to pay the developer fee that Apple demands, which at the very least is not in keeping with the spirit of the GPL, and may very well be a violation in and of itself.
Not entirely true. For distribution, they can jailbreak, which is warrantee voiding, but legal, and can be done by anyone who owns an iDevice.
And those Terms of Service only apply to the binary version. Hence my question, because if the source code is freely available, you can load it on as many devices as you want.
I honestly don't know if having just the source code available fulfills the license, hence my question.
Is Apple redistributing the Program or a derivative thereof? What's more they're relicensing it with a noncompliant license. I think we got a legitimate problem here... If Apple wants to redistribute, they must provide a license to the consumer telling them how to obtain the source and notifying the consumer that they are free to copy, distribute or modify said Program (of course by the GPLv2 rules).
As an app store developer, I can tell you Apple lets the developer supply the license, and it's embedded in the app store for your product.
Because the developer supplies the license for the app store, this is really the developers issue again.
Nothing about the app store means that you can't freely share the code and load it on your own devices. Nothing legally stops you from jailbreaking the device, and loading on the source yourself.
However, it seems that the argument is that anything that falls under the GPL in binary form must be redistributed without restriction, regardless of the availability of the source code. I'm not so sure on this. It seems to me that if the source code is available freely, than the license terms are fulfilled, but what do I know, I'm not a lawyer...
I would take the X264 dev's opinion over the company that originally designed the format... The X264 dev also posted screenshots of their results, and VP8 did not turn out very impressive.
Not to mention, On2 (who again, designed VP8) offers no technical analysis, while the X264 dev did a code level analysis.
I'm not saying the X264 folks won't have bias, but at least they're more neutral and did a spec level review.
They don't seem that impressed. It is less robust than H.264, in some places seems to outright copy it. Google is offering no patent indemnification (from the article: "this is a patent time-bomb waiting to happen.")
They give it credit for being the best open source format out there, but they fault it generally in every other category.
I'm afraid that's not all. Adobe did consider the obvious solution (export Flash to XCode), but that was shot down for the reason above - the code wouldn't have been originally written in ObjC.
How seriously? I asked them for XCode export during beta and the response was No. The reason being is that it would have broken everything. They basically implemented their own byte code, and shoehorned on LLVM to run it on the fly. It's the reason they got up and running so quick on Android. They basically created their own virtual machine.
Of course static libraries are allowed (they're just a collection of object files after all, so it wouldn't make any sense to forbid them -- and moreover, static libraries are the only kind of libraries you can write yourself, since you cannot include self-written dynamic libraries in an iPhone app), but cross-platform layers (in library or any other form) that call any iPhone SDK APIs are no longer allowed by the new SDK agreement.
That said, will Apple be able to detect that you use such a library? Probably not unless you start shouting it from the rooftops. Are you nevertheless violating the new SDK agreement? Probably, yes. Should you care? As an individual developer probably not. Should a company that intends to offer such a framework to other developers care? Probably yes, because if they get called out all of their customers are also in the cold.
Huh? Of course you can't include dynamic libraries, what would be the point? The point of dynamic libraries are that you share the binary between apps, which makes no sense for sandboxed apps... But more to the point, I've distributed binary static libraries, and the source. (I'm not going to name the project, but it does some abstraction of a certain kind of graphics via OpenGL.) Again, no problem. And I know that the type of analysis that Apple does on the apps, and I know that they can see these static libraries in their apps. I have never had an issue. (I have had issues with them with some even less visible things, down to function calls. I know if they can see the function calls I'm making, they know I'm including static libs.)
Apple is ok with abstraction libraries as long as developers can opt out of that abstraction when they wish in order to support specific new features that might ship with new OS's, or even current features of their choosing. There are plenty of abstraction libraries totally supported on the iPhone. Flash and Revolution both do not allow this. You cannot add Obj-C code to your projects with either solution, and you can't work in XCode. This was explicitly cited by Steve as the issue. If Flash was just implemented as a library people could use in their apps, there likely wouldn't be much of a problem (especially if there was a swf -> Obj C preprocessor.)
FYI: I am disappointed that Revolution got locked out, especially in since I loved Hypercard back in the day. It would have been a good app. But the rules have been pretty clear.
If you're exporting to an XCode project with a C/Obj C static library, and your code cross compiled to Obj-C, what's the difference?
All Apple cares about is that the developer has full control over their code to be able to add Obj-C features later. This is the problem Adobe ran into.
Just write pre-processors. Or write abstraction libraries so that you can do your work entirely in XCode.
Slashdot Mirror
The iPad has a pretty nice Microsoft Remote Desktop client that I use when I need to quickly build a Windows project, or view logs from one of our Windows servers. Not really a complete solution, as obviously the standard bandwidth limits apply. If I'm on 3G or slow wifi it's borderline unusable. Still nice to have the option I suppose.
"Unlike employees, students don't need occasional access to random websites. Teachers know weeks in advance what their classes will entail, and can forward desired openings to the IT dept."
In a perfect world, yes. But you would not believe how many teachers make 0 hour requests for things to be opened with the backing of the principal. But yes, we did liberally use white lists.
This still does not solve the issues of games, local servers running over our constrained wifi, or porn brought in from outside. Or viruses brought in from outside.
We tried allowing students to bring in their own laptops. It simply never worked. It just ended up causing arguments with parents (try telling a parent they need to buy a $1000 copy of CS5 for the design class they enrolled their kid into, and then try explaining to them that GIMP is not part of the curriculum, nor will the teacher be teaching to GIMP. And the software is mandated by state accreditation for the classes.) In addition, these laptops were frequently the cause of security intrusions into our network, and were also often used as gaming machines at school. We would also have to spend unnecessary time rigging up outside machines with our ldap database, our printers (which were not postscript), our wifi (we used 802.11a, not exactly standard), and our file servers.
It just isn't worth the thousands of dollars in tax payer money spent configuring a machine for someone because they're offended by our choice in operating system. I understand that people would like to use the laptops they already have, but when you're looking at spending at least a few hundred dollars for the software we use, assuming that the software is even available for your platform of choice, plus the thousands of dollars that will be spent by taxpayers maintaining your system, it's simply not sustainable.
"I don't think a laptop is a right, nor should it be a babysitter to substitute for instruction. Also I'm sure people will steal/break/etc. them on purpose. Every school has the bully, the criminal, the drug addict, basically all sorts of scum.... A laptop would fetch good drug money for the addict. Even if I had said laptop when I was 16 or 17, I wouldn't want to bring it to school."
I don't think anyone sees the laptop as a babysitter, or a substitute for good teachers, much as no one sees a calculator as a babysitter in a math class.
It's a teaching aide, and in theory, it aides students in organizing their work, and saves schools money for buying things such as textbooks (digital books are cheaper and require no upkeep.)
"What will happen is that the school will go on a censorship binge after catching people looking at porn, downloading music, etc.. Then kids will get in trouble who would have been fine if they never had the laptop in the first place.... Then people will circumvent/resent the filters, the administration will race to get more security, and even less work will get done..."
True, but in working in the industry, the kids who get in trouble for this sort of thing are always the kids who would have caused trouble in a different way, but now you've given them a different tool to cause issues. It's not like you handed them a laptop and it suddenly make them decide to do bad things, they already were troubled before they got the laptop.
Honestly, we weren't worried very much about software side abuse, but we did want the ability to regain control if we needed to, hence the hooks into everyone's machines. If a parent wanted something done, we needed the ability to make it happen without making the 5 o'clock news.
(And no, we didn't have runaway software that took pictures of the students. That's just abuse.)
"But according to the article, these would be privately-owned laptops. Meaning that the IT staff at the school couldn't reasonably expect to SSH and stop unauthorized use, since they would have no reasonable expectation of knowing the laptop's su password. I know if my child's school required this, I would make damn sure that I locked it down to where the school couldn't do anything on it. The loaners are a different story, but then they should be locked down anyway to prevent abuse."
And this is the exact problem. If your child is running Bittorrent at school, and we have no way of controlling this, then your child's laptop cannot be allowed onto school grounds.
I know you see the school district not being allowed administrative access into a laptop as a good thing, but we can't allow equipment onto school grounds that could subvert our network or school policy. Just as if you were running IT for a company, you wouldn't let people bring in whatever they wanted and plug it into the network.
Having worked in that environment... maybe...
The biggest problem, as far as behavior goes, is that when you simply hand a kid a laptop, they think it's a right, not a privilege. They abuse the hardware, they abuse the usage... They void the warranty and then are shocked, SHOCKED, when the damage they caused is not covered for free.
Really, the only way these programs will work is if the students/parents are held more responsible. Maybe if they want to take it home they should be required to make a very significant deposit on the laptop.
But in a way, you have a good point. It's just sad because I have seen some kids, when given the laptop, do really amazing things on it. Maybe most teenagers just can't handle the responsibility.
Because the school likes dealing with one set of software and one set of file formats.
iLife may have an equivalent piece of software on Windows, but it does no good if the teacher doesn't know the software and can't work with the student on it, the software has slightly different features, or has different file formats.
I used to work on a one to one program, and while I sympathized with people who came to me in this position, it simply wasn't worth the thousands of dollars in tax payer money to run back and forth and resolve the problems that came up, in addition to us not being able to administer personal laptops. (How do we stop kids from viewing porn or playing games on personal laptops? Or downloading torrents sapping our bandwidth? We can't. On our machines we just track down the machine, log in with SSH, and put a stop to it.)
"Nothing except officially blessed Quicktime components could do H.264 acceleration on OSX until now despite Apple's claims. Even other plugins working through the Quicktime framework were denied access. "
I'm pretty sure that's just what I said... QTKit is the QuickTime X API, and CoreAnimation works on top of that...
Both of which would have been perfectly suitable for Adobe to use. QTKit can play into an OpenGL context.
The worst part about this is Apple already had two APIs, QTKit and CoreAnimation, that could both do hardware accelerated H.264. Adobe bitched and moaned until they got low level access for no apparent reason.
It seriously pissed me off every time Adobe whined about "no 3rd party H.264 support" on Mac. Apple even had several sessions at WWDC in years prior about how to enable it in your apps.
"Uh, no. Google is crying "Foul!" because Apple is banning developers from using Google's ad platform in their apps."
Apple isn't banning Google's ad platform. They're blocking Google from collecting equipment stats with said data, because Google isn't a dedicated ad company.
Something is weird with either MS's UEFI implementation, or Apple's. On my Macbook Pro, EFI sees Windows 7 64 as a valid EFI boot, but when I attempt to boot into it, it just hangs.
So, needless to say, I've had issues getting Win7 to EFI boot.
It was odd seeing a Mozilla dev talking about them fully supporting HTML5. They may support almost as many features, but they all run like ass. Seriously, most HTML5 demos I see on Firefox aren't unusable because some feature isn't implement, but that they are just far too slow.
Safari's and Chrome's JavaScript engines are running circles around Firefox right now. I don't know why anyone interesting in HTML5 would even bother with Firefox. WebKit is eating their lunch.
iPhone however does have KVO, KVN, and dynamically generated keys (valueForKey, setValueForKey), all of which doesn't work with linking by address.
You are supposed to write your network code using CFNetwork and BSD sockets. This is as intended. This is also why Cocoa sockets are actually just loosely wrapped CoreFoundation sockets.
Obj-C is like a screwdriver. You're trying to use a screwdriver like a hammer, and then loudly complaining about it. I'm telling you it's a screwdriver, not a hammer, and that's how it's intended.
Obj-C is a language for quickly building GUIs. It's not a language for programming the logic. Apple recommends you use C for logic. Apple codes Cocoa itself in C and C++. Obj-C was in no way and shape build for performance situations. That doesn't mean it's a bad language. The things you regard as deficiencies actually make it an extremely strong language for GUI construction. This is also why Apple doesn't try to force you to use ONLY Obj-C.
Storing objects by name is an EXTREMELY important feature in Obj-C. Yes, it's slow, but as I've said, don't use Obj-C for performance code.
"There is nothing there that a table of functions pointers along with compiler generated indices for methods/properties, linker/loader address bindings and on rare occasions OS APIs that provide access to these function pointer tables (Windows has such capabilities), cannot accomplish 300-500 times faster (yep, I had single stepped through their method calls & getters/setters, KVO/KVC processing,... and watched tasks that any decent compiler turns into one or two instructions explode into many hundreds of instructions through their runtime interpreter every time you invoke the "feature")."
Again, you're not understanding the language.
Using things like KVO/Bindings and distributed objects REQUIRES that the functions be addressed by name, not by address.
Honestly, if you're using Obj-C as a performance language, you're an idiot. Notice how Objective C has no low level primitives? No basic math functions? No OpenGL abstraction? It's mean to be used as a GUI binding language. This is why in Objective C you are supposed to use C code for your logic (or C++ code if you're so inclined) and then Objective C for your GUI. Objective C was in no shape or form designed for low level logic. This is not a deficiency. This is because it makes a damn good language for doing GUIs.
The reason there is no linking by address is because a GUI needs to dynamically bind against different sections of code by NAME, not by address. In addition, Objective C supports dynamically adding and removing key values at runtime, which again, goes completely against linking by address.
You clearly don't know what you are talking about, which is probably why you were shut down on the Apple forum. Learn some KVO and bindings on the Mac, understand what Obj-C is for, and then you'll understand why Apple made the design decisions they did.
"Even though it is nominally a compiled language, all the calls to methods as well as accesses to class properties are interpreted -- the name of the method & its args (args have names) is looked up in a hash table by runtime interpreter to find the address, then to push args and call it, every time you invoke it or access a property."
Learn KVO and bindings. Then you'll understand why this is done.
Not understanding the purpose of a language feature is no excuse to bash it.
This is running like a dream on my Mac running Safari, but I tried it on a co-workers Mac running Firefox, and it crawled...
Just for reference if you're trying this on Firefox.
Except that the users do not have the freedom to exercise their rights under the GPL, which include being able to redistribute modified versions of the software without limits or royalty payments. For a user of this application to modify it and redistribute the modified version to an unlimited number of persons, they would have to pay the developer fee that Apple demands, which at the very least is not in keeping with the spirit of the GPL, and may very well be a violation in and of itself.
Not entirely true. For distribution, they can jailbreak, which is warrantee voiding, but legal, and can be done by anyone who owns an iDevice.
Modification does not require a fee.
And those Terms of Service only apply to the binary version. Hence my question, because if the source code is freely available, you can load it on as many devices as you want.
I honestly don't know if having just the source code available fulfills the license, hence my question.
Is Apple redistributing the Program or a derivative thereof? What's more they're relicensing it with a noncompliant license. I think we got a legitimate problem here ... If Apple wants to redistribute, they must provide a license to the consumer telling them how to obtain the source and notifying the consumer that they are free to copy, distribute or modify said Program (of course by the GPLv2 rules).
As an app store developer, I can tell you Apple lets the developer supply the license, and it's embedded in the app store for your product.
Because the developer supplies the license for the app store, this is really the developers issue again.
Nothing about the app store means that you can't freely share the code and load it on your own devices. Nothing legally stops you from jailbreaking the device, and loading on the source yourself.
However, it seems that the argument is that anything that falls under the GPL in binary form must be redistributed without restriction, regardless of the availability of the source code. I'm not so sure on this. It seems to me that if the source code is available freely, than the license terms are fulfilled, but what do I know, I'm not a lawyer...
I would take the X264 dev's opinion over the company that originally designed the format... The X264 dev also posted screenshots of their results, and VP8 did not turn out very impressive.
Not to mention, On2 (who again, designed VP8) offers no technical analysis, while the X264 dev did a code level analysis.
I'm not saying the X264 folks won't have bias, but at least they're more neutral and did a spec level review.
Keyword(s);
"when the user has installed a VP8 codec on Windows."
They've already said they'll support any codec installed on the machine. But they're only going to bundle H.264.
http://x264dev.multimedia.cx/?p=377
They don't seem that impressed. It is less robust than H.264, in some places seems to outright copy it. Google is offering no patent indemnification (from the article: "this is a patent time-bomb waiting to happen.")
They give it credit for being the best open source format out there, but they fault it generally in every other category.
I'm afraid that's not all. Adobe did consider the obvious solution (export Flash to XCode), but that was shot down for the reason above - the code wouldn't have been originally written in ObjC.
How seriously? I asked them for XCode export during beta and the response was No. The reason being is that it would have broken everything. They basically implemented their own byte code, and shoehorned on LLVM to run it on the fly. It's the reason they got up and running so quick on Android. They basically created their own virtual machine.
Of course static libraries are allowed (they're just a collection of object files after all, so it wouldn't make any sense to forbid them -- and moreover, static libraries are the only kind of libraries you can write yourself, since you cannot include self-written dynamic libraries in an iPhone app), but cross-platform layers (in library or any other form) that call any iPhone SDK APIs are no longer allowed by the new SDK agreement.
That said, will Apple be able to detect that you use such a library? Probably not unless you start shouting it from the rooftops. Are you nevertheless violating the new SDK agreement? Probably, yes. Should you care? As an individual developer probably not. Should a company that intends to offer such a framework to other developers care? Probably yes, because if they get called out all of their customers are also in the cold.
Huh? Of course you can't include dynamic libraries, what would be the point? The point of dynamic libraries are that you share the binary between apps, which makes no sense for sandboxed apps... But more to the point, I've distributed binary static libraries, and the source. (I'm not going to name the project, but it does some abstraction of a certain kind of graphics via OpenGL.) Again, no problem. And I know that the type of analysis that Apple does on the apps, and I know that they can see these static libraries in their apps. I have never had an issue. (I have had issues with them with some even less visible things, down to function calls. I know if they can see the function calls I'm making, they know I'm including static libs.)
Apple is ok with abstraction libraries as long as developers can opt out of that abstraction when they wish in order to support specific new features that might ship with new OS's, or even current features of their choosing. There are plenty of abstraction libraries totally supported on the iPhone. Flash and Revolution both do not allow this. You cannot add Obj-C code to your projects with either solution, and you can't work in XCode. This was explicitly cited by Steve as the issue. If Flash was just implemented as a library people could use in their apps, there likely wouldn't be much of a problem (especially if there was a swf -> Obj C preprocessor.)
FYI: I am disappointed that Revolution got locked out, especially in since I loved Hypercard back in the day. It would have been a good app. But the rules have been pretty clear.
If you're exporting to an XCode project with a C/Obj C static library, and your code cross compiled to Obj-C, what's the difference?
All Apple cares about is that the developer has full control over their code to be able to add Obj-C features later. This is the problem Adobe ran into.
Just write pre-processors. Or write abstraction libraries so that you can do your work entirely in XCode.