Why not say that manufacturers get a cut of every resale of a car?
That is a good question. When you purchase a car, you are not buying the physical object, you are purchasing the rights to use the manufacturer's branding and limited access to their patent portfolio under the lifespan of the given vehicle. Who is to say that those licences are transferable?
I don't know if anyone is working on it directly, but indirectly they are. UMEKit is a Cocoa port of UIKit. Cocotron is a Linux (and Windows) port of Cocoa. Combined, you have the basis of your iPhone simulator and the basic tools necessary to conduct the development process.
Video overlay is up to the browser, but compositing is certainly possible.
3) Audio
Support is there. Including the ability to generate audio from code. Which lacking feature do you feel is necessary?
4) Language with optional typing
If you are talking about the development of the viewer, Javascript can run anything that LLVM can spit out. That includes Objective-C and even ActionScript in the optionally typed language category.
If you are talking about the Flash content itself, why wouldn't you be using ActionScript? There is no reason why a Javascript app cannot interpret it.
You're probably got me on performance, but that does not stop one from implementing said features.
Which feature of Flash is impossible to re-implement? Using the front-facing camera on the iPhone 4 is the only one I can think of, and even that is being worked on and should be quickly resolved in the near future.
Heck, they've even ported Quake to HTML5. That is quite a bit more advanced program than most Flash apps.
There are severalimplementations of Flash that run in iOS Safari without the need for jailbreaking or violating any agreements with Apple. There is absolutely nothing stopping Adobe from bringing Flash to Safari on iOS, though this announcement gives them even less reason to do so.
We do want to point out that Apple's restriction on Flash content running in the browser on iOS devices remains in place.
This is outright false. Apple places no restrictions on playing Flash content within the browser. It is true that you must use WebKit technologies (Javascript, HTML5, etc.) instead of a plugin to implement your Flash player, but that is an implementation detail only.
Someone already did bring Flash to jailbroken iPhones. The SDK agreement places no restrictions on Safari. As demonstrated in my link above, Safari is more than capable of playing Flash on its own, if someone wants to implement it.
I believe that was their intention. Many companies use university degrees to filter out 90% of their potential application base, but 37Signals have stated on many occasions that they do not hold a degree to any kind of standard (it is not good to have one, and it is not bad to have one, it just doesn't matter). Therefore, they need to find some other way to scare off people who are not really serious about the job, so to speak.
Actually, the iPhone can already play Strong Bad. There is nothing really stopping someone from bringing Flash to the iPhone, SDK agreements included. However, since Adobe is not committed, it is going to take someone else to put forth the effort to make it happen.
The iPod I can understand, but why does a cell phone need an FM receiver? It already provides an internet connection that gives you access to virtually every FM station on the entire planet.
NoSQL is not really about scalability, it is about modelling your data the same way your application does.
There is a strong disconnect between the way SQL represents data and the way traditional programming languages do. While we've come up with some clever solutions like ORM to alleviate the problem, why not just store the data directly without any mapping?
I am not suggesting that SQL is never the right tool for the job, but it most certainly is not the right tool for every job. It is good to have many different kinds of hammers, and perhaps even a screwdriver or two.
Perhaps my wording was poor, but I was not suggesting that every single household back some dirt road had access to every provider. If you are in the right area, however, you can get service from most of the providers through their own infrastructure. Keep in mind that the infrastructure extends beyond copper. The fibre rollout has begun and wireless service is available across the region.
I would argue that competition is strong in this rural region of Ontario. We have a handful of independent telephone companies, a couple of cable companies, not to mention the big players all duking it out. Everyone has their own infrastructure so we do not have problems with the alternative ISPs having to use Bell's last mile, for example.
I do prefer to drive over a bridge that is well designed, but if that bridge is found to have design flaws, I prefer to have them fixed right away. I do not want to wait for the crew to build a second identical bridge next door in order to test their patches.
Except a hash is a derivative work, and therefore is subject to the same copyright laws as the original. Without permission from the copyright holder, one cannot, without permission, use that method to protect future uploads.
Except using a language and "knowing" a language are worlds apart. As an example, I don't know how many times I have seen variations on the following Ruby code on Refactor My Code:
result = [] array.each do |element|
result << element * 2 end result
It works, but it makes reading the code much more difficult than it needs to be. Code that is difficult to read is difficult to maintain. Code that is difficult to maintain is code I, if I were an employer, would not want to pay someone to write. It is code that will come to haunt my business in the future.
It is true that a skilled programmer probably can pick up a new language, such as PHP, in a couple of hours, but can that programmer write good code of the given language in that timeframe?
The fact that you are care about the topic enough to say that you couldn't care less demonstrates that you really could care less. Saying "I could care less" is at least being honest.
You did not hear about it because it already failed in the minds of early adopters. You did not hear about it because they were not talking about it, because they were not using it. If Wave was the next Gmail, you would have heard of it before now.
I'm not furious at anyone. Apple needed H.264 because of hardware constraints. Mozilla needed anything but H.264 because of licensing restrictions. I understand both points of view, and neither are wrong. It is still unfortunate that no one standard satisfies everyone's needs.
Javascript is okay. Cappuccino has shown us you can have a full desktop-class GUI toolkit implemented in Javascript. The question to me is why does the browser not allow Javascript to access lower level system resources (such as drawing routines) so that one does not need to implement those systems on top of HTML and CSS? Granted, browsers should implement byte code interpreters, not just Javascript interpreters.
Not yet. However, unlike previous HTML specifications, HTML5 is attempting to define which formats are required to be supported by media tags. Microsoft and Apple want it to be H.264. Mozilla says they won't support it leaving the specification at a standstill.
Slashdot Mirror
That is a good question. When you purchase a car, you are not buying the physical object, you are purchasing the rights to use the manufacturer's branding and limited access to their patent portfolio under the lifespan of the given vehicle. Who is to say that those licences are transferable?
Not official from Google, but Android x86 exists.
While Jobs can certainly say whatever he wants, Wired reported about the iPad in 1999.
I don't know if anyone is working on it directly, but indirectly they are. UMEKit is a Cocoa port of UIKit. Cocotron is a Linux (and Windows) port of Cocoa. Combined, you have the basis of your iPhone simulator and the basic tools necessary to conduct the development process.
Video overlay is up to the browser, but compositing is certainly possible.
Support is there. Including the ability to generate audio from code. Which lacking feature do you feel is necessary?
If you are talking about the development of the viewer, Javascript can run anything that LLVM can spit out. That includes Objective-C and even ActionScript in the optionally typed language category.
If you are talking about the Flash content itself, why wouldn't you be using ActionScript? There is no reason why a Javascript app cannot interpret it.
You're probably got me on performance, but that does not stop one from implementing said features.
Which feature of Flash is impossible to re-implement? Using the front-facing camera on the iPhone 4 is the only one I can think of, and even that is being worked on and should be quickly resolved in the near future.
Heck, they've even ported Quake to HTML5. That is quite a bit more advanced program than most Flash apps.
There are several implementations of Flash that run in iOS Safari without the need for jailbreaking or violating any agreements with Apple. There is absolutely nothing stopping Adobe from bringing Flash to Safari on iOS, though this announcement gives them even less reason to do so.
This is outright false. Apple places no restrictions on playing Flash content within the browser. It is true that you must use WebKit technologies (Javascript, HTML5, etc.) instead of a plugin to implement your Flash player, but that is an implementation detail only.
Someone already did bring Flash to jailbroken iPhones. The SDK agreement places no restrictions on Safari. As demonstrated in my link above, Safari is more than capable of playing Flash on its own, if someone wants to implement it.
I believe that was their intention. Many companies use university degrees to filter out 90% of their potential application base, but 37Signals have stated on many occasions that they do not hold a degree to any kind of standard (it is not good to have one, and it is not bad to have one, it just doesn't matter). Therefore, they need to find some other way to scare off people who are not really serious about the job, so to speak.
Actually, the iPhone can already play Strong Bad. There is nothing really stopping someone from bringing Flash to the iPhone, SDK agreements included. However, since Adobe is not committed, it is going to take someone else to put forth the effort to make it happen.
The iPod I can understand, but why does a cell phone need an FM receiver? It already provides an internet connection that gives you access to virtually every FM station on the entire planet.
NoSQL is not really about scalability, it is about modelling your data the same way your application does.
There is a strong disconnect between the way SQL represents data and the way traditional programming languages do. While we've come up with some clever solutions like ORM to alleviate the problem, why not just store the data directly without any mapping?
I am not suggesting that SQL is never the right tool for the job, but it most certainly is not the right tool for every job. It is good to have many different kinds of hammers, and perhaps even a screwdriver or two.
Perhaps my wording was poor, but I was not suggesting that every single household back some dirt road had access to every provider. If you are in the right area, however, you can get service from most of the providers through their own infrastructure. Keep in mind that the infrastructure extends beyond copper. The fibre rollout has begun and wireless service is available across the region.
I would argue that competition is strong in this rural region of Ontario. We have a handful of independent telephone companies, a couple of cable companies, not to mention the big players all duking it out. Everyone has their own infrastructure so we do not have problems with the alternative ISPs having to use Bell's last mile, for example.
I do prefer to drive over a bridge that is well designed, but if that bridge is found to have design flaws, I prefer to have them fixed right away. I do not want to wait for the crew to build a second identical bridge next door in order to test their patches.
Except a hash is a derivative work, and therefore is subject to the same copyright laws as the original. Without permission from the copyright holder, one cannot, without permission, use that method to protect future uploads.
Except using a language and "knowing" a language are worlds apart. As an example, I don't know how many times I have seen variations on the following Ruby code on Refactor My Code:
It works, but it makes reading the code much more difficult than it needs to be. Code that is difficult to read is difficult to maintain. Code that is difficult to maintain is code I, if I were an employer, would not want to pay someone to write. It is code that will come to haunt my business in the future.
It is true that a skilled programmer probably can pick up a new language, such as PHP, in a couple of hours, but can that programmer write good code of the given language in that timeframe?
The fact that you are care about the topic enough to say that you couldn't care less demonstrates that you really could care less. Saying "I could care less" is at least being honest.
No, you would be fined $100 if caught.
You did not hear about it because it already failed in the minds of early adopters. You did not hear about it because they were not talking about it, because they were not using it. If Wave was the next Gmail, you would have heard of it before now.
I'm not furious at anyone. Apple needed H.264 because of hardware constraints. Mozilla needed anything but H.264 because of licensing restrictions. I understand both points of view, and neither are wrong. It is still unfortunate that no one standard satisfies everyone's needs.
Javascript is okay. Cappuccino has shown us you can have a full desktop-class GUI toolkit implemented in Javascript. The question to me is why does the browser not allow Javascript to access lower level system resources (such as drawing routines) so that one does not need to implement those systems on top of HTML and CSS? Granted, browsers should implement byte code interpreters, not just Javascript interpreters.
Not yet. However, unlike previous HTML specifications, HTML5 is attempting to define which formats are required to be supported by media tags. Microsoft and Apple want it to be H.264. Mozilla says they won't support it leaving the specification at a standstill.
Apparently all of those stories about iPhone owners having to give Steve Jobs a blowjob were true.