maemo.org - Talk - Can someone tell me why N900 and not Android?

maemo.org - Talk (https://talk.maemo.org/index.php)

- Competitors (https://talk.maemo.org/forumdisplay.php?f=4)

- - Can someone tell me why N900 and not Android? (https://talk.maemo.org/showthread.php?t=33685)

Re: Can someone tell me why N900 and not Android?

Quote:

Originally Posted by MountainX (Post 380122)

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.

Which is an eminently poor argument, because it'll run on any platform that the Linux kernel has been ported to (within storage limits.) Technically, any system that runs on top of Linux could do so as well.

However, only Maemo is based on existing open source tech that the community has an actual say in, whereas Android is very much a top-down, one-way deal.

Usability arguments are one thing, open-ness is something Maemo wins hands down (openmoko not withstanding, but also not very useful.)

Re: Can someone tell me why N900 and not Android?

Quote:

Originally Posted by detronizator (Post 380110)

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 ;)

As long as DRM exists, there will be people who break DRM. The more popular the platform, the faster it happens. That is unless they provide an outlet to spread apart the people who want to do things like do homebrew and boot Linux off random things from the people who want to break the DRM to distribute applications and get things for free. Combined they are a deadly force. A system that makes you choose between the two (what Maemo 6 appears to be doing) might help but I can't imagine it'll be ideal (e.g. a DRM mode and a DRM-free mode).

Re: Can someone tell me why N900 and not Android?

Quote:

Originally Posted by wmarone (Post 380120)

The main issue would be the bootloader.

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

Re: Can someone tell me why N900 and not Android?

Quote:

Originally Posted by johnkzin (Post 380245)

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

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

Re: Can someone tell me why N900 and not Android?

Quote:

Originally Posted by msa (Post 396559)

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

Linux is free, the gnu bin-utils are free, X is free, GTK+ is free, GNOME is free, many/most of the remaining software components of Maemo are free.

But, some components aren't free. And, most importantly, Maemo is a trademark. Even if you duplicate all of the closed components, replace the trademarked images, and port the non-generic components to other hardware ... you still wont have "Maemo". You'll have "your own version of linux/gnu-bin-untils/x/gtk+/gnome on ARM". And, you'll also discover that you've duplicated a lot of the work that is already being done for "Mer" (the open/community project aimed at producing, basically, the same thing).

But, Mer is not Maemo, and neither would your version of it be Maemo.

Re: Can someone tell me why N900 and not Android?

Multitasking of Maemo and Andriod cannot provides

Re: Can someone tell me why N900 and not Android?

Quote:

Originally Posted by Capt'n Corrupt (Post 364854)

@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.

}:^)~

Well for this method to be universal one should be able to handle self-modifying code.

The static translator you seem to suggest is not able to detect or translate self-modifying code or dynamic generation of code (i.e compiler). A dynamic translator could detect modified code but the overhead associated with repeated scanning & translation might not be worth it.

But of cause one could flag code modifying classes for dynamic translation.

-I'd love to see some code.

Re: Can someone tell me why N900 and not Android?

One way to address would be/could be:

1) distribute the byte-code as the central distribution point, with optional native code segments.
2) when _installing_ the application (part of the platform's installation wizard), offer to do a native compile of the byte-code, and add it to the package's native code segments.
3) at run time, using a user-preference, do #2 when the code is being loaded. User preferences would include "always do it, if the native code isn't available", "never do it", "ask", "only ask the first time I run this app".

That gives you the flexibility of smallest possible footprint (both for the distribution stream, and for what you store locally), and native code performance (if desired).

If you care about speed more than storage consumption, you have your preferences set to always native-compile. If you care about storage more than speed, you have it set to never native compile.

Or, lets say you have your common apps installed on your mobile device. There, you care about code performance a lot (because the CPU is slower), so you go ahead and do the native compile for ARM, but not for x86. When you charge your mobile device via USB, hooked up to your desktop computer, you can run the same exact app (if you have your mobile device's storage exported via USB storage mode) ... but since you have more CPU horsepower there, you decide you can accept the less efficient speed of bytecode. Meanwhile, you get a middle-ground in storage consumption, because you only have 2 code segments (bytecode and ARM) instead of 3 code segments (bytecode, ARM, and x86). And if you also run on other architectures (PPC, Power2, MIPS, etc.), you can make similar decisions about storage space vs speed, all while using 1 application installation.

You can also apply that to "applications kept in NFS/CIFS/etc." type network storage repositories. You pick which ones you want/need native code speed for, and do the bytecode->native compile for those ... and rely upon bytecode for the others. But, you can use that one installation instance everywhere that supports that bytecode engine.

Re: Can someone tell me why N900 and not Android?

What a heated discussion, so many comments. For me it simple - real Linux, total control.

Re: Can someone tell me why N900 and not Android?

If you have to ask that question...get an Android device.