With LiMo’s recent announcement that Verizon had hopped onto their Board of Directors, things are starting to heat up between the LiMo platform and Google’s competing product, Android. Both are open-source Linux-based platforms, and both are aiming to rock the handset market sometime in the next year or so.
LiMo is Linux-based. Android is Linux-based. But they’re far from the same. Below, I’ll try to explain some of the key differences without going too heavy on the tech jargon. (Fiiine. It gets a bit heavy for a paragraph or two. But I’ll avoid it where possible.)
1) Backers/Funding
LiMo: The LiMo platform is backed by the LiMo Foundation, which was founded by Motorola, NEC, NTT DoCoMo, Orange, Panasonic, Samsung, and Vodafone, and has since added 34 other members to the list. In membership fees alone ($400k a year for each of the 9 “Core” members, and $40k a year for each of the 25 “Associate” members) , the foundation has raised at least 4.6 million before adding in whatever funds the founding members pitched in at the start.
Android: Android is backed by the Open Handset Alliance (OHA). OHA has 33 founding members besides Google, including 3 of the LiMo Foundation’s 7 founders (namely Samsung, Motorola, and NTT DoCoMo). No word on Android’s budget so far. While the way Google flashes cash with things like the $10 Million Dollar Android Developer Challenge doesn’t absolutely prove that their budget is larger, it certainly implies it.
In other words: Both platforms have massive companies as partners, and presumably a good amount of money behind them. Android is largely touted as a Google project, where LiMo isn’t really pushed as being under the wing of a single company.
2) Dev Status
LiMo: LiMo was announced in January of 2007, the first handsets hit in early 2008, the API (Application Program Interface, a set of pre-defined routines for developers to utilize) is available now , and their software development kit (programming tools and documentation for developing and testing applications) is set to release in the second half of 2008.
Android: Android was announced on November 5th of 2007, and an early version of their SDK was released within a week. The first Android handsets are planned for the end of 2008.
In other words: LiMo has devices on the market and an API available, but no SDK. Android isn’t available on any handsets yet, but already has an SDK in the hands of developers. Before anyone has really began working on LiMo applications, we’re already seeing Android apps being demoed.
3) Applications
LiMo: LiMo applications can be written in C/C++, allowing them to run natively.
Android: Android applications are written in Java, so all applications will be running in a Virtual Machine. Virtual Machines mean CPU overhead, meaning applications that may not be as efficient as if they were running native. However, it almost absolutely guarantees a standard application environment across Android devices.
In other words: LiMo applications are running in a language the operating system (OS) inherently understands, while Android applications are running in a virtual environment on top of the operating system. More importantly – you can write a Java virtual machine in C or C++, so while it could be possible to run Android applications on LiMo be it someone wrote a compatible virtual machine, it is far less likely to see LiMo’s C/C++ applications somehow emulated in Java. I was wrong – Android apps aren’t running in a Java VM, they’re running in a Dalvik VM. As such, portability in either direction is unlikely.
4) Handsets/Carriers
LiMo: There are a number of LiMo based handsets on the market, from Panasonic, NEC, Motorola, Purple Labs, LG, or Aplix. Current carrier partners are Vodafone and NTT DoCoMo, and Verizon has announced plans to offer LiMo devices in 2009.
Android: HTC has mentioned that they’re working on at least 2-3 Android handsets for 2008, and LG is working on at least one for 2009. The other handset manufacturers registered as Open Handset Alliance members are Motorola and Samsung. Current carrier partners are Sprint Nextel, T-Mobile, China Mobile, Telefonica and Telecom Italia.
5) Hype
LiMo: Fairly low. There just isn’t much chatter about LiMo, besides articles summarizing press releases. I couldn’t find any LiMo enthusiasts, or communities focused around LiMo devices.
Android: High, largely because of Google’s involvement and all the speculation that went on before it was announced. I found a number of opinion articles on Android, and a handful of budding fan forums.
6) Design Aspects
LiMo: Middleware only, meaning LiMo only handles things that are tucked below what the user actually sees. User experience items, such as the interface, are the responsibility of those developing the device.
Android: Android is a full software stack, meaning it consists of an operating system, middleware, user interface, and applications. Android will have a standard user interface, but as it is open source, the carrier/manufacture, and potentially the end user, are free to change it.
In other words: LiMo is only part of the software package that goes on a device, while Android is pretty much the whole package. If those developing the device are looking to start with a complete software solution, they’d probably go with Android. If they’re looking to write their user experience layer from scratch, they’d go with LiMo.
So who will win?
That’s a hard question to answer, as they both offer a totally different solution. Google offers a complete solution, which can be remolded from the top down. LiMo’s solution provides a foundation, on which developers can build the user experience from the ground up.
In terms of adoption, I’m willing to bet Android will reign victorious in the end. The crowds are already buzzing about it, and a number of developers are already cracking out code for it. Thanks to Google’s name being beside it at all times, it’s the first time I’ve ever heard a mobile operating system discussed amongst my non-gadget-obsessed friends (Even though it was just another “OMG! Is this going to be better than what’s on the iPhone?!?!” conversation,) and it hasn’t even hit the market yet.
Your graphic is incorrect. The last item, Full-stack software, Android is the full stack, LiMo is middleware only, according to item #6 above.
I had not heard of LiMo until I read this article, so thank you for bring up the level of awareness about it. I agree that Android will reign in the end, mainly because of Google’s halo effect.
Oh jeez – Thanks Jim, I’ll fix that right now.
(Update: Fixed)
Hi,
First of all, very nice comparison. Some points I would like to highlight,
LiMo concentrates only on the middleware thus reducing application conflicts.
There are handsets in the market that are running on the LiMo platform. I dont agree with Android reigning as LiMo uses technologies that are widely accepted and some of its members have full LiMo compliant software stacks ready. They do gain an edge over Android in this area. Do let me know what do you think
Thanks!!!
Excellent article. I did not know very well what Limo was, not I do.
Thanks!
We’re probably the largest Android site on the internet for anyone who wants to follow it. We also cover anything related to the Open Handset Alliance.
Updated daily with news, rumor, opinion, etc. We’ve got great flagship content and reader interaction.
Feel free to check us out!
http://androidguys.com
Where does the Symbian mobile OS fit in all of this?
About JVM, ARM processors have something to accelerate Java bytecode called Jazelle (www.arm.com/products/esd/jazelle_home.html) there by making it very fast and less overhead
Android is not Java based, thats a common misconception. It is based on a Google specific VM that is very different from Java. The Java bytecode gets translated after compilation to the google Dalvik VM, this obviously means that solutions such as Jazelle (which are problematic to begin with read Mark Lam’s blog) won’t work with Dalvik.
This has another issue where all applications need to be coded specifically for Android since the API’s are incompatible and deployment is hard. Its a big issue for Java developers since one of the biggest selling points of Java is easy deployment and Android isn’t “quite” Java.
About VM overhead this is actually a non-issue… With current Java VM’s (I have no idea if Dalvik is as good as a Java VM since the source is not yet open) MVM allows us to have one VM instance in memory for multiple applications.
Since a VM application takes less memory (Java bytecode is smaller than native ARM code roughly 4 to 1) usage of handset RAM/Flash is greatly reduced. Furthermore, CPU is better utilized due to on-device optimization (again read Mark Lam’s blog for full details).
Even though this article and this comment is ages old, dalvik isn’t different from the java vm except that’s its a full rewrite, but none the less its essentially the same thing (check out for example http://www.betaversion.org/~stefano/linotype/news/110/)
Shai,
Do you know of android VM optimization using ThumbEE for ARM.
I prefer LiMo :p
I recommended all LiMo Motoralla phones to my friends and my fiance, most bought it. Going to buy a new Moto myself to replace my old ROKR E1, of course LiMo too.
If you ask me, LiMo will give us more choice since Android apps can be run in LiMo IF someone will write it, but Android can’t run LiMo apps. I call that choice and freedom. I hate getting locked-out or not being able to use something that I prefer. ;)
But either way, I support both LiMo and Android, coz they’re both “Open” and Linux-based – FLOSS.
Sorry I have no idea if Android is optimized to ThumbEE, you can check out the Android internals discussion group maybe they know.
@John: Android applications won’t run on LiMo its again part of the confusion produced by Googles unique use of Java. Android applications are not portable and are deeply tied to the Linux OS underneath. They rely on a Google specific LIBC implementation and rely on very unique OS behavior. Every “intent” (Androids equivalent of a lightweight process) spawns a new Linux user to provide OS level security. This is a very imaginative approach that would probably make a layer on top of LiMo not very feasible technically.
ANDROID IS NOT JAVA! Research please. KTHXBAI
There are indeed significant differences between the work the LiMo Foundation (of which ACCESS, my employer, is a member) and the efforts of Google on Android.
LiMo is truly a collaborative effort among companies who’ve shown a demonstrated ability to produce not only cell phones, but Linux-based cell phones. Android from all appearances, and the OHA membership notwithstanding, seems to be entirely driven by Google (to the point where the license you agree to in order to get the Android SDK is with Google rather than the OHA).
SDKs for LiMo devices are currently being developed–I’m a member of the group working on the native SDK–and we hope to have something available for developers in the near future.
However, I want to stress the most important point here: for the largest part, the APIs used to develop code for LiMo devices are the same ones that developers currently use on Linux-based desktop systems.
LiMo devices are based on mainstream, community-supported components, such as GTK+, Gstreamer, BlueZ, D-Bus and the like. Android represents not only an entirely idiosyncratic development environment, but also a significant learning curve for developers, since it’s a) Java-only, and b) uses Java within an “application framework” which is substantially different than anything anyone’s ever seen before.
The point here is that existing code can be repurposed, with relative ease, to run on LiMo devices. Code must be pretty completely rewritten from scratch to run on Android. Similarly, developers don’t need to learn an entirely new development and design paradigm to write code for LiMo devices.
Google has said, many times, that the current efforts of the open source community weren’t good enough for them to use, and that they were thus obligated to essentially rewrite the entire system from the ground up. I don’t believe–and the other members of LiMo don’t believe–that this is actually the case. Certainly the mainstream open source development community doesn’t believe this is the case, either.
The members of LiMo believe,in contrast with Android, that we can make better progress and produce better devices by working _with_ the open source community than by going back to square one and independently reinventing wheels where perfectly good ones already exist.
David “Lefty” Schlesinger
Director, Open Source Technologies
ACCESS Co., Ltd.
I belive that Android will be winner, because the Google wish the control of the mobile marketing market.
What matters most is not the competition between LiMo and Android, but open platforms vs proprietary and patent-encumbered platforms such as Symbian, Windows Mobile, and the Apple iPhone.
Android and LiMo will have equivalent full stack and SDK functionality by early 2009. While the market is large enough for both to be successful (esp. given some degree of interoperability), I think LiMo will win more deals for one simple reason: the top mobile operators worldwide will have an alternative to handing practically everything but the pipes to Google.
It is gonna be like HD-dVD vs BlueRay!
LiMo is based on open source but it is not completely open. You need to be a member of the club to be allowed to play with the toys but I’m not sure how open Android is either.
This is not Linux vs Linux. I think this is more of a struggle of the carriers trying to keep control of some of the revenue source. The carriers fear becoming just a pipe. They are being forced to open their networks more in order to compete. When the networks are open then the Yahoos and Googles take most of the revenue. Compare Google’s market cap with any of the internet service providers. The handset makers are looking to keep their slice as well with Symbian.
I vote against Android. I like their approach to develop software, but I unlike their platform.
As developer and user, I want interoperability between my PC, notebook, subnotebook, PDA, (smart)phone, portable-media-player, TV, etc.
I want to use one, really open platform across all digital devices I own.
Actually, Linux as used by Google is nothing more but just engine for “dumb Java-enabled dialer”.However since there is no QT or GTK used, there is no any benefits for Linux vs proprietary OS and apps are just java crap.So no, you will not have Pidgin or Mplayer or other great and free app on Android without efforts.Actually, you can buy any java-enabled “dumb dialer” today without Google at pretty low prices.And who cares about Linux if you can’t make any real use of it anyway?So, Google reinvented a wheel.Cool, yep.But I’m preferring full-speed and full-deatured C\C++ apps.This what really makes phone SMART.Come on, code something comparable to Pidgin :)
> About VM overhead this is actually a non-issue…
The issue will be that
1) There is no real apps for this crap and no, you can’t just take Linux app, adopt to screen size, recompile and voila, you have featured decent app with minimum efforts.You’ll have to “enjoy” some shitty pocket crapware instead which is even not really exists today.
2) When system is multi-tasked and lots of featured apps, speed and RAM is what matters.And C\C++ code uses less resources anyway.Ever seen some heavy parts on Java?Maybe, OGG codec on Java?C version just uses some 5-10% CPU on my n800.How much will eat Java version?Just several times more?Argh, it has other tasks to do while I’m listening to music :)
3) When talking about openness, there is not much differences if we compare Android and phones with proprietary OSes.For programmer there is Java anyway and virtually no use of lower-level sub-engine.So who cares which OS it runs?Nobody will code apps using just plain syscalls and direct graphic without libs like QT or GTK anyway.I see no clue in Android.Yet another dumb Java phone.You can buy a bunch of these without google today.
Forgot: dalvik is not yet open source AFAIK.So, what about opennes?
JSmith,
obviously you like Linux and I do too. Also please don’t mistake me for an Android fan, I don’t think Android is a good platform. The problem is that it has “issues” in some operator deployments:
> 1) There is no real apps for this crap and no, you can’t just take Linux app…
You are correct. However don’t forget that most Linux desktop applications are of little use for a cell phone. The input is completely different and screen semantics (windowing behavior/desktop integration) just don’t fit as well. Pidgin will have issues with it.
MPlayer has a whole other issue, it doesn’t pay codec license fees and somewhat relies on ia86.
> 2) When system is multi-tasked and
> lots of featured apps, speed and RAM
> is what matters…
That is why Java is important, no you will not implement a codec in Java you will implement it in assembler.
Java ME is not Java SE its designed for small size and ARM specifically. Don’t forget this is a mobile phone and security/OTA also matters.
Furthermore remember the 90-10 rule a codec falls under the 10 where most of the system should probably be written with a system better suitable for security/reliability.
I suggest you read this and the followups Mark can help with some of your misconceptions about Java:
http://weblogs.java.net/blog/mlam/archive/2007/04/why_choose_java.html
> 3) When talking about openness…
Again Android is not Java, it is Dalvik which is a huge part of its problem.
I agree with you that Googles reinvention of “everything” was dumb, but not just dumb… Difficult.
Linux programmers can’t leverage their Linux skills and Java developers can’t leverage theirs since Android is not Java. At least not “proper” Java.
> However don’t forget that most Linux desktop applications
> are of little use for a cell phone
This simply not true :).Actually after small adaptation they are ok.I own n800 and I’m like how Pidgin works, as well as Mplayer, Xchat and bunch of other decent full-featured apps.No need for pocket-sized crapware when I can run REAL apps in my pocket.As a phone I have Symbian based Nokia.Yeah, it’s proprietary but it can run both slow and resource hog Java crap AND fast and lightweight native code apps.Therefore beating Google’s moron platform at the very start.And who cares of Linux if you can’t make any real use of it anyway?Linux has benefits that huge code base with liberal licenses is available for this system.With Google’s dumb platform this bebefit is not used.Actually, this is dumbest Linux use I ever seen so far.At least Google’s platform can be a way better.But google taken strange decisions.Ok, let’s see what they’ll acheive.Fortunately, there is a bunch of competitors so I do not have to stick to slow, boring and feature-limited java-based stuff.
> MPlayer has a whole other issue, it doesn’t pay codec license fees
From user side I don’t really care.In my country software patents are nothing, so it is absolutely legal for me to use Mplayer for free anyway.As well as I believe that if vendor of my device has payed royalties for codecs already, I do not have to re-pay them one more time just because I using mplayer instead of lame, dumb and slow built-in player.
> and somewhat relies on ia86.
Strange, but it runs quite decently on my ARM-based n800 and I like it a way more than built-in player which is too picky in file formats it can parse and f..kingly slow in playback compared to Mplayer.
> Java ME is not Java SE its designed for small
> size and ARM specifically.
Yep, and there is already plenty of such phones.Without Linux but who cares?
> Don’t forget this is a mobile phone
> and security/OTA also matters.
And again, there is bunch of “secure” phones running Java already.As from security view I have to admit that there is pretty much “classic” phones you can pwn to run plain binary code with direct access to GSM stack, so all this security stuff is actually idiocy intended to allow cell operators to choose which apps you can run.Surely these you’ve paid for.If someone will need to hack GSM\3G network, he will come on and break in as long as network is not secured.This idiocy with restricting users from running real apps will not prevent this.It will only restrict users.And well, there is bunch of smart phones anyway where GSM\3G is reduced to a modem IC and Linux just dials a number (something that any PC+phone can do for years) so it is quite safe(at least PC+phone bunch is a way more powerful toy for hackers).
As from security and OTA… er, I do not like idea that someone can update my device remotely without my request.It rises privacy, security and freedom concerns.After all it is I am who payed for device.Let’s it be me who decides how to use it, then.Why should allow someone else to make decisions instead for my moneys?This looks pretty strange.
>> MPlayer has a whole other issue, it doesn’t pay codec license fees
> From user side I don’t really care.In my country software patents are
> nothing
We aren’t talking about the user perspective… Operators and manufacturers are those who decide what goes on our phones, they have a complex status quo and they really wouldn’t like the complexities of the GPL to get in the way (which is why Android is not GPL above the Kernel).
They also don’t like getting sued and they all have strong presence in the most lucrative cell phone markets: US, Japan and EU where they can and do get sued over codecs.
> > and somewhat relies on ia86.
>Strange, but it runs quite decently on > my ARM-based n800
Yes, it also ran on my old powermac but many of the better codecs are just Windows codecs which were bundled in. Without them many videos just couldn’t play in the past. Haven’t tried the version without the codec pack in years though.
> so all this security stuff is
> actually idiocy intended to allow
> cell operators to choose which apps
> you can run.
Steve Jobs said that you can bring down the network with a hacked iPhone, you calling him a liar ;-)
Control of the GSM stack won’t bring down anything although its useful for very specific use cases. Java allows you access to SMS, MMS, networking etc… Android unlike Java goes even deeper.
Security isn’t stupid, but yes part of the reason is to hold control over the phone. It is still important since there is a very real fear of device based viruses. Writing a virus in Java would be impossible unless you find a really big hole and its been years since the last one (and all of them were very hard to exploit).
> As from security and OTA… er, I do
> not like idea that someone can update
OTA is Over The Air and is usually initiated by the user. This can be done with native applications too but its hard when you download an application from an untrusted web site.
>> However don’t forget that most Linux
>> desktop applications
>> are of little use for a cell phone
> This simply not true :).
You are not a typical everyday user… I would love an N800 too once they can actually make it into a phone, but we aren’t the target market of these devices.
We can compile applications and if the keyboard navigation doesn’t behave quite right and the softkey behavior isn’t what we expect its no big deal. For production level user experience, Linux on N800 is a far way off which is probably why Nokia never built it into phones. Which is a shame it does seem better than Symbian at least for my needs.
I also said “most” Linux has MANY applications and a very small subset of them are even practical on a cell phone. Can you imagine kdevelop on a cell phone ;-)
> Operators and manufacturers are those
> who decide what goes on our phones,
Actually, not everywhere.For example in Russia you can buy phone and sim card with contract separately.Actually GSM was intended to allow this scenario.And it works.So you can choose contract and phone independently, fitting better to your needs.And from user and developer point of view, this is their f**king problems that they can’t secure their networks and resort to moron restrictions which are harming USERS.And surely those who is skilled enough to mess up with cell networks hacking will just use phone which does have poor security subsystem.There is lots of such phones.And once you can exchange SIM cards and (in hardcore cases) forge IMEI, nothing will prevent network from being hacked.So, actually this is moron idiocy with “security”.Rather intended to limit user choice.Can you imagine than your server will be secure just because you forbid to use it with anything but only one type of browser?Pretty unlikely.Hackers will just forge browser identification in their tools.You have to audit your server for security, fix bugs in timely manner and so on.Same true everywhere.Attempt to play like an ostrich has nothing to do with a real security.
> Yes, it also ran on my old powermac
At least, Mplayer beats built-in n800’s player to the hell both in speed and wider understanding of MP4 subflavours, partially corrupted or bugged files, etc.Where built-in player fails, mplayer just works.And I’m actually using Mplayer on my x64 Kubuntu Linux desktop without any Windows stuff.Works pretty nice for me and handles virtually any codecs I can encounter.At very least, it’s great for all kinds of MP4 based stuff.Virtually no any built-in mobile players can compare in parsing bugged or semi-corrupted files.Very few can stream video over HTTP or FTP without downloading whole file.Mplayer can.
> Steve Jobs said that you can bring
> down the network with a hacked
> iPhone, you calling him a liar ;-)
At first, I have n800 with unrestricted apps and GSM phone attached via Bluetooth as modem.Is this enough?I can craft any IP packet.Or even mess with PPP layer.If this is not enough and you have to mess with GSM stack itself, only quite few people on this planet can bring network down.And even if iPhone is secure enough there is dozens of other phones which are not.So, such hacker can take a reasonable decision to hack not an iPhone but other phone.
Actually looks like Jobs just has it’s own interest in restricting users.And well, there is already dozens of jailbreaked iPhones in the world anyway and iPhone one of the most quickly hacked phones.You can install apache, MySQL, gain full root access or whatever else.So actually hackers are not affected by this crappy security idiocy.The only those who are in loss is just an usual users.Who is not interested in hacking at all so can’t jailbreak and enjoy with ALL features.And fair developers can’t develop fully-featured apps.So, as usually when security used in moron way, hackers can do everything, only fair and legitimate users are in loss.Surely, good idea how to grow even more hackers rather than turn them into a developers and network security experts.
> Writing a virus in Java would be impossible
Even in very old and defective Symbian you must install virus manually and confirm several times to allow it to run.Actually, system is not insecure.It is user who launched this stuff.So the only way to go is to educate users that they should not run each and every crap.There is no virus on Java?Huh.At first, I’m tired updating Java on desktop.It jailbreaked dozens of times.At second I’m aware that some guys are using Java midlets to break into the phones and run native code, bypassing even such paranoid things as secure bootloaders and firmware digital signatures (really funny, yeah?).And well, there is trojans written on Java already.These are fooling users to send SMS or MMS to special number, then user is charged for using this number some funny $2 per message or so.So this “secure” java is not so secure.And hackers were always able to mess with GSM stuff and always will be able.Moron things like restricting users are ineffective and restricting fair users only.Only those who hadn’t malicious intentions anyway.To make users really secured you have to educate them not to run each and every crap encoundered.No other way.
> This can be done with native applications
> too but its hard
Hmm, actually not so hard task, solved already.Just take a look how for example usual Debian or Ubuntu package management system works.It install apps from trusted sources (repositories).Apps are signed with digital signatures and installer will refuse to update or install apps if package signature failed check or key is not known as trusted, indicating that it is not a really package crafted by system maintainers or just package became corrupted\tampered with.Yes, user can add 3rd party keys and repositories if he trusts to certain vendor but this requires some sort of special action, effectively making things pretty secure while user is not restricted and can install even own apps(just add own key to trusted keys list and then sign package with your key).This scheme ensures that only packages signed by system maintainers (and optionally, trusted 3rd parties) are auto-updated.It is pretty hard to distribute virus in such manner since you can’t sign packages as system vendor without having private key and requesting user to add new public key to trusted list is rare and noticeable action which is hard to be done just occasionally by user without a good reason.If user is willing to go so far in shooting his own legs, nothing will save him anyway since he can be fooled by mentioned Java trojans as well (and it happens, so users should be educated not to run all stuff they see anyway).
> which is probably why Nokia never built it into phones.
Actually looks liks Nokia 770 was a try targeted to hardcore geeks and developers.Then, n800 has been a more wide try targeted to everyone who is a bit familiar with internet.Looks like all this succeeded and n810 looks pretty mainstream for me.Actually as for me it looks like Nokia actually silently tests new mobile platform of future and gives it first wide run on mass market.I will not be surprised if at some point they will abandon Symbian in favor of Linux-based systems.Why they acquired Trolltech, after all?;).Actually, if you reduce GSM stack and modem to one IC so it will appear to Linux as a modem on UART, Linux will just use this exactly as n800 uses GPRS enabled phone over bluetooth.In this way Linux can run on a real smart phones allowing to run any apps but without allowing to mess with lowest level of GSM stuff though (and everything else can be done from phone+notebook bunch for example anyway).
A couple of comments:
The chart showing no Java apps on LiMo phones is incorrect–there’s in fact a Java Working Group in LiMo, and there’s no reason whatsoever that a phone based on the LiMo platform could not support Java and support it quite well. (We’ve already noted that Android supports Google’s version of Java, not the Java Community version: Shai’s comment, above, is spot-on here.)
Also, there’s no reason that desktop Linux apps can’t be readily adapted to run on mainstream Linux-based mobile devices. ACCESS demonstrated a port of GPaint, a pretty classic open source app, on an ARM development board at LinuxWorld last year. All we did was cross compile it for ARM, no code changes were required. Laying out the screen differently made it look better, but it ran perfectly well, completely unaltered.
Google’s insistence that everything be reinvented from scratch, using a peculiar and hitherto-unseen application development model, and no other language but their own special version of Java, is an unfortunate choice. It completely discounts the potential contributions of the tens of thousands of open source developers who already know how to write code for mainstream Linux-based systems. Too bad for Android, but ultimately good for the manufacturers and carriers who will be shipping phones based on the work being done under the auspices of the LiMo Foundation.
>> Operators and manufacturers are those
>> who decide what goes on our phones,
>Actually, not everywhere
Russia is a special case ;-)
In Europe and most of the world we can do the same but still well over 90% of the people buy the locked down phones from the operators and sign the contracts.
> There is no virus on Java?Huh.At first, I’m tired updating Java on desktop.
There are security issues and there were proof of concept exploits these are not viruses. Trojans exist in all forms but you still get prompted with quite a few scary warning dialogs, I never meant to imply either Linux or Symbian had security issues… All I was saying is that Java provides more security on top of that. There was also a hole in quicktime which due to an Apple bug was exploitable through Java. Overall Java is very secure by its nature and design. Linux is pretty good too which is why Java running on Linux is even more secure. Every security layer is breakable, I like to use the onion analogy so when you break one layer another one should come in between.
> Actually as for me it looks like Nokia actually silently tests new
> mobile platform of future and gives it first wide run on mass market
This is probably true, although the purchase of Trolltech probably signifies their direction most of all…
The carriers/operators like control – always have, always will. LiMo gives them control over aspects like the UI, Android limits control.
The real question, thus, as the carriers/operators ultimately control the point of sale, comes down to whether or not the carriers are willing to ultimately give up the control that Adroid asks them to give up…
Here I go, again… some conclusions:
1) LiMo is actually Java + Linux.So, more features.After all.Android is just Java.Linux is unused as engine so is pretty useless IMHO.
2) iPhone… I taken a look on it’s design, after all.It has been designed as a “smart phone” (though without ability to run user’s native apps it is not so smart up to date, such features downgrade is pretty virtual and due to marketing, though).It has GSM stack in separate S-Gold based CPU with own memories and separate “applications” processor with own memories.More expensive design but ensures that application engine and it’s OS just runs in “usual” conditions and does not have to deal with a hard realtime stuff for example (offloaded to dedicated processor and proprietary GSM stack firmware which can cope with this) and that OS apps can’t do low level GSM hacking.So no, jailbreaking MacOS on iPhone is not a big security breach to network.Anyone with any GPRS-capable phone and for example notebook attached over bluetooth is exactly same “security breach” as well.So, if I can’t do something with iPhone I can always resort to notebook+iPhone (or any other GPRS-capable phone as a modem) and can do all things jailbreaked iPhone can.So, yes, Steve is a liar.Or he is just covers his ass and protects their defective business model.How typical for Apple.They are always trying to make quick moneys.Now by restricting who can make full-featured apps and selling right to write such apps to certain people only.Potentially trashing their future:their step will limit amount of apps available and will in long term hurt their platform so it could be outperformed by competitors who will have more [and even FREE] apps on their platforms.Something that Nokia is already has figured out.
3) Yeah, Nokia.Now it is official… they’re going Linux.
4) And a bit on S-Gold … this is good chip set and Siemens took a really lots of steps to prevent it’s hacking.But actually, all such efforts are pretty useless: it still can be pwned is you’re really want to and going to spend some efforts on it. So, if you’re really want to pwn everything you just have come on, break-in and have fun by pwning iPhone on layer even below app processor – whole GSM stack and it’s CPU can be yours!So you can try to bring network down by doing things which you can’t do with notebook over GPRS by executing low-level GSM\GPRS tricks.Actually, Nokia’s smart phones are more securely designed.Though I know they were pwned too to execute arbitrary code on GSM\3G CPU (though for nokias this hack is very hard one but still possible AFAIK).But actually most of single-CPU phones (except Nokia, again) are poorly protected so anyone with enough skills can play a tricks at the lowest levels of GSM stack.
5) Conclusion:
- For cell op’s it will be better to secure and audit their networks or they’ll be hacked, no matter what restrictions are put at user’s software.
- All this moron is just about who will control who can run apps.However in long terms such control just puts platform into strong disadvantage due to very few apps developed and available.
- Nokia apparently figured out that it is better to give rights to run a real code but limit access to GSM part so people can code and have fun rather than deal with hacks which are often motivated by attempts to mod UI and run native code.Yeah, there is S-Gold based phones from Siemens.And they were hacked to the hell exactly due to same reasons.Yes, thay’re a way more hacked than it’s needed to remove lame operator locks stuff.Up to building native ICQ client, MP3 player (x65 series lacks MP3 playback…), etc.
P.S. And after all, special f…off to nasty cell op’s who is covering their lame asses with security mumblings but actually are only restricting fair users, who is not willing to hack anything anyway.Just to be able to squeeze more moneys from ‘em for crappy apps from selected vendors.Definitely limiting people’s freedom of choice.It’s a real fun: someone still pays for … restrictions!What a moron.And how democratic.USA has so much laws protecting various rights.And so much evil corporations which are using a dozens of nasty tricks to force people to give up their rights.Funny.Huh.
Android all the way baby!
I don’t know Android might have a better chance of standing not because Google having being involved, but the server side written using Java.
Thank you for this article and thanks for users for all the insight comments :)
Well i know this post’s getting old by now, but i would like to know which, if any of the platforms discussed (LiMO , android) can run on VERY resource limited mobiles…i mean something in the class of the nokia 1661 or 2600. I ask this because android for one is classed as a platform for ’smartphones’…i dont know much about LiMO….thanks in advance