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

From what I understand, it's possible to install non-market andoird-apps:
http://www.blogsdna.com/1939/how-to-...d-g1-phone.htm

It's not nearly as straight forward as with maemo, but it is possible.

This may also be worth a browse:
http://www.talkandroid.com/android-sdk-install-guide/

}:^)~

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

Those are the instructions for the google G1 phone which is rooted. Other users will first have to gain root access to their phone which might create other problems for them. For example if your phone is rooted you can't install paid-for applications.

Android is setup to make the marketplace the gateway for applications to your phone. Sure there are various ways around it (for now) but it's an enormous difference and not one I favour. My phone is mine and if there's an easy accessible store of applications, great! But I don't want to be restricted to what Apple, Google or Palm think I should have.

Edit: Or what Nokia thinks I should have!

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

Yup, installing non-market Android apps is as difficult as selecting

Settings -> Applications -> Unknown Sources

Download file, click it.

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

Nonsense, my phone is a HTC Hero, not rooted, I can install whatever I want by doing exactly what I just said. And I have.

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

Yup. No more difficult than it is on Symbian (where you also have to tell it to allow installation of unverified apps). Otherwise, it's just a matter of downloading a file and clicking it.

You're no more tied to the Market on Android than you are to specific repositories on Maemo.

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

Fair enough guys, from my reading of people who have Android phones in locations where the marketplace is not yet available they seemed to have a lot of difficulty getting things onto their phones.

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

Well, they may be having problems buying software without the market. I'm not sure if many developers will sell their stuff directly. But it's not about installing, that option is really all that's needed.

I actually did need a certain software, contacted the developer and said that my country doesn't have the market yet, but I'd really like buy a program from him. He was pretty glad I contacted him and didn't go look for the app elsewhere, gave me his paypal account info, I paid him, he mailed me the installation file and I installing it just like I just said. But this was a one-person team, I'm sure the big companies don't do that.

This is maybe a bit unrelated, but I cannot understand why Google is being so slow in getting the Market to other countries. They should open it everywhere, I see the market as a huge benefit of the Android..and right now it's crippled in many countries. Getting access to the market's paid applications is actually the biggest reason I know why people root their Android phones here (you can change your country when you root your phone, pretend you're from the US, have full market, then just use your own credit card etc. to pay).

Edit: The Market's paid applications, is what I mean there...you can install the free software everywhere. But not buy stuff yet.

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

They open the market when a carrier in that country sells an Android device. It's a fairly arbitrary limitation, something I suspect is there because of the carriers.

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

johnkzin,

I am a gamer, so I love a good d-pad. That was one good thing about the Dash- the d-pad worked well for emulators :)

The Cliq and Droid's d-pads are not good and appear to not function as 8-way like the Dash d-pad does. The Dash's was called "4-way" too, but functioned as an 8-way d-pad. At least Cliq's is on the "correct" side.

I must admit that had the Droid's d-pad been on the left and functioned better, it would be killer for games due to 3430 chipset. I play NeoGeo, Capcom CPS2, MAME, GBA, Genesis, SNES and NES on my G1 and it does a good job when clocked to 528mhz. NeoGeo and Capcom CPS2 should play perfect with sound on the 3430.

Since Android already has very good emulators, it is just a good d-pad and chipset away from being an instant old school game system.

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

It's also a question of complying with a country's laws regarding collecting and remitting VAT or sales tax and complying with corporate tax laws in the country. I would not be surprised if the Markets are legally attached to the carrier in some countries to handle this.

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

Here's a good question for the community... Comparing the executable code strategies for Android and Maemo, which do you think is better? Why?

Android apps (AFAIK) are written in Java with (hopefully) a Java JIT compiler to compile the bytecode, whilst maemo apps are coded in whatever, and compiled to native ARM code. Which is the better strategy? Why?

I'm genuinely interested to hear what you think!

}:^)~

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

Dalvik (Android's runtime) isn't really Java. It's an optimized subset of Java (they eliminated things that would slow it down).

I'm not sure you can really say which is better. Each one makes it choice based on larger issues than just executable code speed.

Android is designed to run on multiple hardware platforms (the multiple ARM variants, MIPS, x86, etc.). For that to work, while still providing a single user experience, native code just wasn't an option. And, this approach is probably a factor in why we're seeing Android pop-up on so many different devices (official, and unofficial). Why bother if you can't run any apps on it? or if you have to get vendors to port their apps to N different CPUs.

Maemo, on the other hand, only runs on a single specific hardware design. It doesn't need that support for multiple platforms. On the other hand, that also means it doesn't have the benefit of running on multiple platforms from multiple vendors. And, its approach would be awkward at best (for the consumer market) if it was deployed on those same platforms as Android.

So, one approach gets you CPU flexibility/independence and proliferation. The other approach gets you speed and maximum hardware utilization. Each one fits the higher goals of the people who made that platform. You can't really say which is better without addressing which of those higher level goals is better ... which, IMO, isn't an answerable question. It depends on what you/they want.

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

I didn't mean that I don't see the point of the d-pad in and of itself. You quoted me out of context. People seem to love to do that on this forum. Quote someone out of context, make them appear to say something they didn't say, and then respond to the thing they didn't say. What's the point?

Anyway, I said I didn't see the point of the d-pad, given that the scrunched up keyboard on the Droid is supposed to suck. So is the benefit of the d-pad worth the trade off of having a keyboard that sucks so badly some reviewers are reporting it's better to just give up and use the onscreen keyboard? There are obviously a lot of touch based phones out there now without d-pads that people are happy with. If both a d-pad and a decent keyboard couldn't be squished together into the Droid's form factor, I would have far preferred a good keyboard.

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

Android's trading compatibility and speed for portability. An unwise compromise to make with mobile devices, in my opinion.

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

Running at a slower but acceptable speed on more devices versus running at a faster speed on fewer devices makes the latter strategy much more device dependent. If you're the device manufacturer, you can control that but Google must rely on a number of manufacturers using their OS and apps.

Plus, don't forget Moore's law. With faster CPUs the relative speed advantage decreases.

I'm old enough to remember writing in assembler language. If you want the absolute fastest program, it's still the way to go but very few people think it's worth the trouble.

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

@johnkzin,

An incredibly insightful and eloquent explanation. Thank you for that (especially the Dalvik bit, which is exciting news to me). But I'm really curious to hear *your* personal commentary regarding the architectural choices upon which each platform is engineered.

PS. Do you know of any dalvik benchmarks that compare execution timings to java/C/etc?

}:^)~

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

There are also java bytecode assemblers out there! Though I would imagine that any optimization would have to be time tested on the target platform(s) as the interpreter/JIT could yield very different results across architectures. Still, interesting for eeking out a bit more performance here and there.

}:^)~

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

Here's an interesting read on Dalvik. The 'iphone hate' in the last paragraph made me laugh out loud as it comes out of nowhere!
http://www.betaversion.org/~stefano/linotype/news/110/

And here's a link to the wikipedia entry on Dalvik:
http://en.wikipedia.org/wiki/Dalvik_virtual_machine

A good read!

Here's a talk by the creator of Dalvik:
http://sites.google.com/site/io/dalvik-vm-internals

}:^)~

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

Dalvik is two things -- a class library (analogous to a J2SE or J2ME implementation -- and Dalvik's doesn't match either), which is where your statement holds true, and the bytecode interpreter, which differs in less clear-cut ways.

The bytecode interpreter differs from many Java implementations because it _is_ a pure interpreter, not a JIT compiler. Also, and most significantly IMO, it's a register-based (instead of stack-based) VM. For those not familiar with this architecture debate, think of RISC/CISC, and don't ask "which is better" unless you like flamewars. :D

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

I don't consider it to be an "either-or". I think the best approach is "both".

If I were to win the lottery tomorrow, I'd hire a couple of engineers to take an Android dist. and add something like Cygwin to it (so it uses the Android display model, and not X, but provides API and ABI compatibility with X based applications), and then port GTK+ and Qt to that. I'd add bin-utils, shells, some other programming/development stuff (Sun Java, Python, Perl, Tk, maybe Tcl and Ruby), and a vt100 compatible "droid-terminal". Then I'd port a few common things to it (firefox, thunderbird, mplayer, a few others), and add a "me" account to it. I'd also look into adding the debian style package management to it, for the non-Dalvik apps (and the Ubuntu graphical counterpart, whose name I forget.. starts with an S I think).

That's how I'd approach it ... but I have an anti-X bias that says "it's better to start with the non-X platform and work toward the middle, than to start with the X platform". If I was Nokia, I'd start at the other end of that bias (due to the investment in an X based platform). I'd leverage the work the one guy at Canonical did (porting Dalvik to Ubuntu), and get Dalvik working on Maemo.

Though, the other thing I'd probably do, is see about supporting/leveraging fat binaries (1 executable file with multiple executable segments, each for a different platform). If I could work it into the native tools, it would be the default, with an option to allow developers to narrow it down if they feel it's strictly necessary. That would add some degree of flexibility to the native code developers, as well.

In general, I don't think it's reasonable to make developers or users choose between the two approaches (whether you're talking about Dalvik specifically, or Java generically). Evolution will determine if bytecode apps will do well enough to thrive alongside native apps (and visa-versa). Let the developers gamble, and the users decide. IMO, the OS platform designers job is to enable those two groups, not pigeon hole them.

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

Aah. I didn't realize Dalvik's VM was that different. I thought that, like the libraries, it was also a subset. (and, yes, I understand register based vs stack based ... I cut my assembly teeth on VAX-11 assembler ... and, RISC vs CISC isn't exactly register vs stack ... there were pre-RISC stack based architectures, and I think (but am not sure) that there are register based RISC architectures, as well)

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

Did people see that the Milestone (German version of the Droid) has multitouch, even though the Droid doesn't: http://www.engadgetmobile.com/2009/1...what-droidont/

What's up with that? For entertainment value I like the conspiracy theory that Engadget refers to, that Apple somehow killed it in the U.S., but that doesn't really seem believable. The Milestone is also GSM, with 850/1900/2100 UMTS, so I guess people on AT&T could grab an unlocked one, if they become available.

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

It is also kind of a PITA that these android phones require some type of web based account to even 'activate' them. With the G1 you had to either use an existing google account or create one. Not sure how it will be with the droid, but I am sure it is similar if not worse.

Same with the 'motoblur' it is just as much of a service as it is an interface design.

Nokia, I guess, is kind of starting to do this too with Ovi, but at least with their devices you don't HAVE to use the manufacturers or the OS providers web based services just to use the phone.

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

Isn't the key purpose for the byte code in Android is so multiple chipsets can be supported? If native, the apps would lose that portability. The apps would probably be more hardware efficient as native, but more specific coding to support multiple chipsets. Lots of splintering. Correct?

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

Yeah, I figured you knew that -- edited above for clarity.

Sorry, I just meant to give an analogous, but better known, architecture dispute that was similarly long-running and unwinnable and to avoid people wondering "but which is better", not to suggest they were the same dispute.

And yes, there are register RISCs; you probably have one in your pocket (ARM). ;)

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

@john,

Very interesting vision!

My primary goal with the original post was to get interesting feedback as to their predictions of the future of handsets from a architectural perspective, and even more interestingly, what they would do moving forward; in short to put the members of this forum in the role of the OS designer. The 'which do you think is better' is succinct, but too ambiguous and misleading, and more than likely to start a flame war. :p . I will choose more careful wording next time. From this perspective it is nothing more than interesting conversation.

But I appreciate your vision, and your would-be actions given extreme resources.

An interesting side bite:
From what I understand there are provisions for running native code from dalvik (two)bytecode, for increased performance or access to system facilities. This comes in the form of native libs as well as general JNI support. Android actually uses quite a bit of native code throughout (eg. webkit, opengl, freetype, etc), though it may be a bit tricky to install such libraries given the android app/install manger -- which I know nothing about!


@ben,

I'm interested to hear your thoughts!


}:^)~

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

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

}:^)~

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

I seriously hope we get Dalvik for Maemo... Daelvik? Maelvik? Dalmo? It would be wonderful to have that kind of cross-platform compatibility :)

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

I also hope that there's an android layer built on top of maemo. It would be awesome to open maemo up to the growing library of android apps, and further empower maemo.

}:^)~

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

Maemo + Android > Android

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

I'm not sure how it's possible to say that when you've got the counterexample of Debian, currently available on twelve architectures, all in native code. It's entirely possible to write code to an API that's available across architectures and then have it build on all of them instead of insisting on a cross architecture ABI.

You just don't need portable binaries in order to be portable.

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

Debian wasn't the first to do this.

Nextstep/Openstep (now "Cocoa"/OS X) did it, with transparency (fat binaries that were automatically built unless you told the compiler not to). But even the best, most carefully designed, and anally debugged environment for it, still had the problem that you still had to individually debug each platform. If you didn't, you'd get subtle variations in user experience, even subtle bugs. It was a great idea, but even the staunchest Nextstep advocates admitted that it had issues.

Even the anal retentive, overbearing, demanding taskmaster mentality that Steve Jobs brings to everything he oversees, couldn't make it 100% transparent to the developer. It's no coincidence that when Sun licensed Openstep, in the hope of the same goal ... it had to instead evolve in to Java.

What Debian does is a few steps less integrated than Nextstep/Openstep ... which means a few more steps of effort are required.

Interpreted environments (including bytecode type virtual machines) work that out in the interpreter. So the provider of the interpreter does that effort, not the application developer.

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

There's no conspiracy theory. Apple does have a multi-touch gestures patent in America. Though they haven't tried enforcing it (Palm Pre has it for example). Not to mention there's a debate of whether

a) it can really be patentable
b) prior work (there's a company in Asia that had been doing it for a while.. last I heard they were suing Apple about it).

But Google has pretty much determined that it would not support multi-touch gestures officially in America at least.

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

Yeah, I thought about it some more, but I don't know if I buy it. Apple is on really shaky ground with its patents. More so than you point out.

When Apple started making waves about the Pre having multi-touch, I read some pretty in-depth analyses that said Apple's patents are really very specific and don't pertain to much of what you see on the Pre. And, as you mention, Apple themselves is getting sued by Elan Microelectronics from Taiwan, for supposedly infringing Elan's own prior multi-touch patents. Apple is also infringing all kinds of patents that Palm holds (like syncing data from a cradle). Nokia is suing Apple now for infringing patents that have to do with just basic cell phone technology. So if Apple really wants to make waves in the cell phone industry over patents, they could get creamed (apparently businesses tend to use patents as weapons against each other, in a sort of mutually assured destruction logic).

And again, as you touch on, if Apple really went to court over these patents there's a not small possibility that Apple could get its patents revoked. Closer examination would probably show that Apple's patents actually violate other people's intellectual property, as well as being bogus based on prior art (publically known information from before the patents, making the ideas not patentable). In fact, this article is really interesting: http://www.rcrwireless.com/article/2...pabilities-is# It explains that now that multi-touch is taking off in the commercial sector and there's a lot of money in it, sooner or later the universities that really own the intellectual property on multi-touch are probably going to sue Apple. Basically the patent office is not very thorough and Apple probably shouldn't have gottent these patents to begin with.

So I think with Apple it's just a bunch of bluster. They don't want to go the legal route because it's bad news for them.

Also the stories about Apple nixing multi-touch in Android are hightly rumor based. Really there was one unnamed source back in February (http://digital.venturebeat.com/2009/...ogle-complied/) and then that one story got repeated a bazillion times online until it became the truth.

If it does have something to do with Apple, it really seems to be more becasue Google wants to play nice with Apple and continue to have Google services and applications work well on the iPhone/iPod Touch, in Safari, and other Apple products. But that said, the idea of Apple being able to nix multi-touch in Android doesn't make much sense to me. Google is in direct competition with Apple, pitting Android against the iPhone. If Google wanted to be nice to Apple, why would Google give in on just one feature? Especially since Google has shown lately that if it wants to go head to head with Apple, it's happy to sick the FCC on them for blocking Google Voice on the iPhone. And unlike Palm, Google has definitely got the money to go to court with Apple, over patents that Google has got to know are probably going to be a losing battle for Apple. It just seems like Google holds the cards, why bend to Apple's will?

Still, all that said, the lack of multi-touch only on the U.S. version of the Droid is curious, but I'm skeptical that Apple really forced it down Google's throat somehow.

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

Look up Droid's camera.. it might be 5mpxl, but it's image quality sucks. Thats my deal breaker. Since n900 has a great GPS in it, i'm just waiting for the navigation software to catch up. (only a matter of time)

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

FYI:

From: http://lwn.net/Articles/360343/

[1] http://laforge.gnumonks.org/weblog/2...id_mythbusters
[2] http://tree.celinuxforum.org/CelfPub...rs_Android.pdf

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

I think it's more Google just doesn't want to bother with a lawsuit and rather let someone else smack Apple upside the head. I don't think it's a google service issue because it's Apple that loses out if iphone users can't use gmail or gmaps with an application.

But true about the patent office, they also have quotas to meet a month and rejecting a patent doesn't count, only accepting.

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

Don't forget, Google just programs the OS, and they program it for general applicability. I don't know the mechanics of multi-touch but I have to think it is not something that could be implemented strictly in the software. Google may have decided that its programming efforts would only have benefited a few Android phones and that their development hours would be better spent elsewhere.

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

Yes, but recall that what prompted this dicussion is that on the exact same device (Droid/Milestone) multi-touch works in Europe and not in the U.S. So whatever technical explanations could be offered for not having multi-touch can't really make sense in this circumstance. In your example, if it's not worth the development hours, then it wouldn't be on the European version of the Droid either.

I guess part of my point in my post was that Apple's patent is so tenuous and everyone in the industry knows this, that the threat of a lawsuit isn't credible. So I just can't imagine Google getting pushed around by Apple. I mean, Apple wasn't even able to push around Palm, despite it being cash strapped and struggling to continue to exist. And Google can see that Apple actually hasn't sued Palm, after it's initial sabber rattling. So I don't see why Google should even bat an eye at any threat from Apple over multi-touch patents.

And multi-touch seems like a feature the average conusmer really wants. It has become sort of a hallmark of quality in a touch device. So it's worth Google bothering. Leaving it out of Android device, especially the U.S. Droid seems like something that could have a substantive effect on sales. (Although I have seen a few reviewers question whether multi-touch is actually that useful or is more of just a gee-whiz feature--but that's neither here nor there as far as public perceptions and sales go.)

Google and Apple of course have been very cozy. So maybe they did just come to some sort of agreement. I don't know. I don't really find any of the explanations so far very compelling. Some of them seem sensible, superficially, but I don't think they hold up to further consideration. It's just odd to me, to see it in the European Droid, but not the U.S. one. And it's not a hidden feature on the Milestone. It's a feature that Motorola is making a big point about.

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

Here's an nice more in-depth review of the multi-touch situation with the Droid and Apple's tenuous and not entirely existent patents:

http://www.engadget.com/2009/11/04/s...nd-multitouch/

Engadget points out, as they did with the Pre, that Apple does not actually appear to have a patent on the pinch-to-zoom multi-touch capability. So it's pretty unlikely it has anything to do with why this feature is available in the European Droid and not the U.S. one. They also point out that Windows 7 and the HD Zune have pinch-to-zoom enabled. And Apple has not said a word, further suggesting that there's nothing Apple can do about it (because if they could why would they let arch enemy Microsoft "steal" the feature?). They also point out that if Apple had a patent claim, Google would already be in violation since multi-touch support is built into Android 2.0 (even if it's not implemented). So they just don't buy that Google is worried at all about Apple and multi-touch.

Engadget says there are some claims that the pinch-to-zoom feature on the European Droid was implemented by Motorola. And Google implied it was Verizon's decision to leave it out on the U.S. Droid. And Engadget thinks what's most likely is that Google just hasn't finished developing multi-touch yet, but that it will be on future devices. Still they conclude, as I do, that the whole situation is just weird and doesn't really have a good explanation, given what's known.