Yeah Safari has it's own "fast javascript engine." It's treated me well, though I could see Google's money making v8 the king of the Hill for both browsers in the long run.
I grok the technical implications of what you gentlemen are saying. They're real. I wanted to diverge a bit though.
I don't think the technical issues come primarily from a real security perspective: I believe that the biggest barriers to many of the things we want to do (in particular, compile code on the device) stem from Apple's *desire for control of the distribution channel*.
John, I've been wondering: Is this the main reason I cannot purchase your Squeak VM on the App Store? I dig my wiki server, but I'd really really like to be able to Squeak on my phone without voiding the warranty.
On Thu, Oct 22, 2009 at 3:11 PM, Eliot Miranda eliot.miranda@gmail.com wrote:
On Thu, Oct 22, 2009 at 2:08 PM, John M McIntosh johnmci@smalltalkconsulting.com wrote:
On 2009-10-22, at 1:41 PM, Eliot Miranda wrote:
Its OK if you're Apple, right? JavaScript is V8 (a JIT) on the iPhone isn't it?
At least on Safari it is "Nitro". So I guess Mobile Safari doesn't contain V8 either.
And if Java is on the iPhone its probably a JIT too.
Er yes, well it's your operating system, your hardware, your legal documents. One can do what one wants, as long as one can keep the other guy out of your playpen. So who does hand executable pages to V8? Good question...
Java is NOT on the iPhone. Neither is Flash. *cough* well interpreted flash, Adobe has some static compiled version they make or something now. Grind Flash thru some process, makes iphone app.
--
John M. McIntosh johnmci@smalltalkconsulting.com Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
2009/10/23 Ronald Spengler ron.spengler@gmail.com:
Yeah Safari has it's own "fast javascript engine." It's treated me well, though I could see Google's money making v8 the king of the Hill for both browsers in the long run.
I grok the technical implications of what you gentlemen are saying. They're real. I wanted to diverge a bit though.
I don't think the technical issues come primarily from a real security perspective: I believe that the biggest barriers to many of the things we want to do (in particular, compile code on the device) stem from Apple's *desire for control of the distribution channel*.
+1 once one can compile own code on their devices, he won't need App Store since then :) And allowing or disallowing native execution for memory page has nothing to do with real security, this is just a myth.
John, I've been wondering: Is this the main reason I cannot purchase your Squeak VM on the App Store? I dig my wiki server, but I'd really really like to be able to Squeak on my phone without voiding the warranty.
Even without JIT, we're not allowed in. There's a rule against interpreting code too; clearly this is a very flexible rule, as I can't think of a game company that uses any variant of C for in-game scripting, not to mention that we have apps running Squeak. My guess is they'll let you do it as long as you don't let end users do it. Hence, not a security concern.
I am uncertain whether it's presently okay or not okay (it's been both okay and not okay at different times) to reproduce any part of the SDK agreement, so I'll just point at section 3.3.2.
On Thu, Oct 22, 2009 at 8:42 PM, Igor Stasenko siguctua@gmail.com wrote:
2009/10/23 Ronald Spengler ron.spengler@gmail.com:
Yeah Safari has it's own "fast javascript engine." It's treated me well, though I could see Google's money making v8 the king of the Hill for both browsers in the long run.
I grok the technical implications of what you gentlemen are saying. They're real. I wanted to diverge a bit though.
I don't think the technical issues come primarily from a real security perspective: I believe that the biggest barriers to many of the things we want to do (in particular, compile code on the device) stem from Apple's *desire for control of the distribution channel*.
+1 once one can compile own code on their devices, he won't need App Store since then :) And allowing or disallowing native execution for memory page has nothing to do with real security, this is just a myth.
John, I've been wondering: Is this the main reason I cannot purchase your Squeak VM on the App Store? I dig my wiki server, but I'd really really like to be able to Squeak on my phone without voiding the warranty.
-- Best regards, Igor Stasenko AKA sig.
On Oct 22, 2009, at 8:47 PM, Ronald Spengler wrote:
I am uncertain whether it's presently okay or not okay (it's been both okay and not okay at different times) to reproduce any part of the SDK agreement, so I'll just point at section 3.3.2.
3.3.2 An Application may not itself install or launch other executable code by any means, including without limitation through the use of a plug-in architecture, calling other frameworks, other APIs or otherwise. No interpreted code may be downloaded and used in an Application except for code that is interpreted and run by Apple's Published APIs and built- in interpreter(s).
On 23.10.2009, at 05:58, Ian Piumarta wrote:
On Oct 22, 2009, at 8:47 PM, Ronald Spengler wrote:
I am uncertain whether it's presently okay or not okay (it's been both okay and not okay at different times) to reproduce any part of the SDK agreement, so I'll just point at section 3.3.2.
3.3.2 An Application may not itself install or launch other executable code by any means, including without limitation through the use of a plug-in architecture, calling other frameworks, other APIs or otherwise. No interpreted code may be downloaded and used in an Application except for code that is interpreted and run by Apple's Published APIs and built- in interpreter(s).
Yep - emphasis on *downloaded* code. As long as all the interpreted code ships with the app and there is no way to download additional code except through the App Store, Apple is fine. So you can make Squeak apps available through Apple, that's just what John did.
- Bert -
Hi all!
Some interesting points:
On Android you can install an app just by clicking on it in the web browser and bam, it will install. AND it can contain native libraries in C or whatever BUT AFAICT it needs to "be" a Dalvik Java app around it.
For example, someone just published Quake wrapped in a very thin Java/Dalvik layer around Quake as a C lib working using OpenGL ES.
THUS... Android is MUCH more fun for Squeak. There is no central bottleneck like the App store.
Secondly, there are TONS of Android phones coming out the next few months. The one that most waits for is "The Droid" from Motorola (Motorola is going "all in" on Android):
They take iPhone head on :)
Note also that the Mono folks are all over Android now, the mono JIT seems to run fine, see below.
Finally, some links:
http://www.koushikdutta.com/2009/01/dalvik-vs-mono.html
Note that Dan Bernstein (designer of Dalvik?) comments it below.
regards, Göran
2009/10/23 Göran Krampe goran@krampe.se
Hi all!
Some interesting points:
On Android you can install an app just by clicking on it in the web browser and bam, it will install. AND it can contain native libraries in C or whatever BUT AFAICT it needs to "be" a Dalvik Java app around it.
For example, someone just published Quake wrapped in a very thin Java/Dalvik layer around Quake as a C lib working using OpenGL ES.
THUS... Android is MUCH more fun for Squeak. There is no central bottleneck like the App store.
Secondly, there are TONS of Android phones coming out the next few months. The one that most waits for is "The Droid" from Motorola (Motorola is going "all in" on Android):
http://droiddoes.comThey take iPhone head on :)
Note also that the Mono folks are all over Android now, the mono JIT seems to run fine, see below.
Finally, some links:
Goran, thanks for this link. In particular this is a neat idea:
Anonymous said...
I believe you didn't understand Dan's presentation after all.
The Android security model imposes that each application runs in its own isolated process, which forces you to implement one-whole-VM per process runtime model. In case you don't realize this, this is different from AppDomain because it allows, among other things, your application to run arbitrary native code without risking compromising the system's security.
Dalvik is thus designed to share as much code *and* data as possible between processes. That's why there is an initial "zygote" process that loads a very large number of system classes at boot time (where loading each class requires running code and allocating objects in the heap), which is later forked with copy-on-write semantics when a new application needs to start. Consequently, this speeds up the startup of new applications significantly.
I don't think Mono supports any of that.
Finally, Dalvik design doesn't preclude a JIT, it's just that this is not necessary for a large number of applications and that having a really good interpreter was more important to ship a 1.0 device. January 6, 2009 2:15 AMhttp://www.koushikdutta.com/2009/01/dalvik-vs-mono.html#comment-2227105061610620173
Note that Dan Bernstein (designer of Dalvik?) comments it below.
regards, Göran
ok just to help Ron here, developers who sign the contract with apple can not talk about the contents of the contact. This is the current view which was confirmed to us by a call from apple legal three weeks back to have us remove two words from one of our iTunes store app decriptions
On 10/22/09, Ronald Spengler ron.spengler@gmail.com
I am uncertain whether it's presently okay or not okay (it's been both okay and not okay at different times) to reproduce any part of the SDK agreement, so I'll just point at section 3.3.
vm-dev@lists.squeakfoundation.org
-
Bert Freudenberg -
Eliot Miranda -
Göran Krampe -
Ian Piumarta -
Igor Stasenko -
John McIntosh -
Ronald Spengler