Originally Posted by MountainX

I would love to try this...
It would also counter the argument that Maemo isn't really free because it only runs on one device.

Originally Posted by detronizator

Man, I was thinking of receiving a comment like that to that sentence.

Honestly, I technologically agree with you. They are not features (and indeed, I didn't call them so).
But I'm in this business for enough time now to say that there is no Mass Market without those "funtionalities". And, yes, they are there more to make the interest of the Companies then to make the interest of the Consumers.

BUT, to have a massive success, a large base of installation, something "of the iPhone size", you need to have a secure, solid platform. And for now PlatSec, in all it's different forms, has been the only way to deliver it.

My favourite? The Android one. Is still open enough that you can install anything from anyone if you want, but it's at least creating the filtering and giving the user the informations "to make him/her aware of what he/she is doing". Symbian PlatSec, on the other hand, is the example to avoid.

DRM is going to be required until all Media-producer will make their mind and stop bothering us. Once we see that happening (and you have iTunes of example of where this ALREADY HAPPENED), it will be a better world

Originally Posted by wmarone

The main issue would be the bootloader.

Originally Posted by johnkzin

No, the main issue would be Nokia's legal department dropping a ton of bricks on you.

Originally Posted by msa

but but but.... i thought maemo is open and free and everyone can do with it what he wants :<

Originally Posted by Capt'n Corrupt

@john

Building on your wonderful idea of a multi-platform binary:

It would be interesting to meld the cross-platform characteristics of a bytecode language with the performance of natively compiled code (with the exception of assembly). How? Read on, my good friend!

The bytecode (eg. register-based dalvik) would be compiled (not a new concept at all, I am well aware!) to native code.

But this raises a very large problem. Doing a JIT on large applications or spread across many libraries could eat into performance and memory, especially in a constrained device like a low-power phone running on a 1999 architechture.

The solution is simple: caching. By caching natively compiled code, you gain a large benefit: that you needn't re-compile code for each run. The VM can do a quick check, a quick load, and an update to its offset tables upon execution, and you have the benefit of native execution speed derived from once-was interpreted bytecode.

But there's still a problem! Caching a complete application will invariably result in ~2x the storage requirements of a single app. This especially unnacceptable on a contsrtained device. But there is a solution to this as well!

A special class could be inherited when building an 'to-be-compiled' sub-classes. For these classes, although byte-code would be generated by the compiler, upon execution of the interpreter, a JIT compiler would recognize the class as 'to-be-compiled', compile to native code which would then be cached somewhere on the FS, and stored in memory for the duration of that process. The class could be empty, only its namespace as significant information, and thus be safely passed over by non-compiling interpreters.

The use of a special inherited class is key, as it allows the developer granular control over the code that would be natively compiled and run, which is adequate for speed critical portions of code (ie. inner-loops). Thus the interpreter would flag this code for cached-compilation, leaving the other code for regular vanilla interpretation. This prevents the code-bloat and potential performance losses associated with compiling the entire process bytecode for each instance and only focuses on the areas that are deemed necessary-to-optomize by the developer. The special class (or some similar mechanism) is used by the VM to differentiate code. Also, it maintains 100% backward compatibility with older bytecode that does implement have the special 'compile-flag' class.

This scenario requires a tiny bit of modification from the developers perspective, but could be made easy enough. The benefit though is huge: native execution speed from a universal bytecode.

It's of interest that Googles V8 javascript engine compiles Javascript directly to native code, completely bypassing the need for an interpreter, and increasing the speed of execution *significantly*. Considering that Javascript is a dynamic-typed language, a native compiled static-typed language like Dalvik bytecode should achieve even higher levels of performance, and there's little reason why it cannot match the performance of natively compiled C.

}:^)~