4 ms·

It sounded to me his main beef with Android is that it doesn't let you do native code, hence you can't do fast, 3d games. His second beef was that, the way the

It sounded to me his main beef with Android is that it doesn't let you do native code, hence you can't do fast, 3d games. His second beef was that, the way they don't manage the marketplace very much, it's very insecure.

mrj 16y ago
Which is weird, because you can do native code. The whole thing reads like a rant from two years ago.
- openfly 16y ago
  I think you are completely missing the point. Either you should be doing everything in the VM, or everything bare metal. Allowing all the apps to execute on either bare metal or the VM at discretion is a resource / security / policy management nightmare. Dalvik however really only functions currently with Java. So effectively you end up with having to provide other languages hooks into Dalvik, or getting rid of Dalvik entirely. Most of these comments really are completely off base. Did anyone actually take the time to read this before posting?
  - teilo 16y ago
    Yes. Painfully, I read the whole thing. Which is why I could summarize the rambling non-arguments of the article.
- jcl 16y ago
  Well, he acknowledges that you can do native code, but then he argues that native code is actually bad because the marketplace isn't screened, so people can easily post malware that relies on native code exploits. His unspoken assumption is that Apple's manual review process would somehow reject an app that contains a native code exploit -- which is baseless. It's not like they have people reading the source code. As far as I can tell, the reviewers just run the apps to look for content and branding problems, and sometimes they don't even catch those. And an exploit relies on a flaw that the system designers don't know about -- the reviewers wouldn't know what to look for even if they wanted to prevent exploits.
  - famfam 16y ago
    You don't even submit the source code. So it would be hard for them to have people reading it.
ryoshu 16y ago
http://cache.gawkerassets.com/assets/images/17/2010/06/smartphone_stats.jpg http://cache.gawkerassets.com/assets/images/17/2010/06/smart... I would think that 90 million triangles/sec (3x that of iPhone 4) would be enough to do fast, 3d games.
CitizenKane 16y ago
Except there is the NDK (http://developer.android.com/sdk/ndk/index.html http://developer.android.com/sdk/ndk/index.html) which he points out. It seems like he fails to understand how it works though. It allows parts of the application to be written in C or C++ and hook into the top layer of Java. It isn't "running inside the VM" it's running outside of it and communicating with it. Further, the android platform restrictions are enforced at the kernel level so C and C++ code runs under the same restrictions as those in the VM. It simply allows you to do manual memory management for high performance code.

mrj 16y ago

Which is weird, because you can do native code. The whole thing reads like a rant from two years ago.

openfly 16y ago
I think you are completely missing the point. Either you should be doing everything in the VM, or everything bare metal. Allowing all the apps to execute on either bare metal or the VM at discretion is a resource / security / policy management nightmare. Dalvik however really only functions currently with Java. So effectively you end up with having to provide other languages hooks into Dalvik, or getting rid of Dalvik entirely. Most of these comments really are completely off base. Did anyone actually take the time to read this before posting?
- teilo 16y ago
  Yes. Painfully, I read the whole thing. Which is why I could summarize the rambling non-arguments of the article.
jcl 16y ago
Well, he acknowledges that you can do native code, but then he argues that native code is actually bad because the marketplace isn't screened, so people can easily post malware that relies on native code exploits. His unspoken assumption is that Apple's manual review process would somehow reject an app that contains a native code exploit -- which is baseless. It's not like they have people reading the source code. As far as I can tell, the reviewers just run the apps to look for content and branding problems, and sometimes they don't even catch those. And an exploit relies on a flaw that the system designers don't know about -- the reviewers wouldn't know what to look for even if they wanted to prevent exploits.
- famfam 16y ago
  You don't even submit the source code. So it would be hard for them to have people reading it.

ryoshu 16y ago

http://cache.gawkerassets.com/assets/images/17/2010/06/smartphone_stats.jpg http://cache.gawkerassets.com/assets/images/17/2010/06/smart... I would think that 90 million triangles/sec (3x that of iPhone 4) would be enough to do fast, 3d games.

CitizenKane 16y ago

Except there is the NDK (http://developer.android.com/sdk/ndk/index.html http://developer.android.com/sdk/ndk/index.html) which he points out. It seems like he fails to understand how it works though. It allows parts of the application to be written in C or C++ and hook into the top layer of Java. It isn't "running inside the VM" it's running outside of it and communicating with it. Further, the android platform restrictions are enforced at the kernel level so C and C++ code runs under the same restrictions as those in the VM. It simply allows you to do manual memory management for high performance code.