Mobile Linux Group Releases First Specification

narramissic writes "Google's Android may be getting all the headlines, but the venerable LiPS (Linux Phone Standards Forum), which launched to much fanfare in 2005, is rolling out the specs. The group, comprised of companies including Orange, France Telecom, MontaVista, and Access, announced Monday that it has completed the first release of its mobile Linux specification, adding components including APIs for telephony, messaging, calendar, instant messaging, and presence functions, as well as new user interface components."

Comments

Cool

[Anonymous Coward]

It only took 3 years to get the standards out? Well, it looks like 2012 will be the year of both the linux desktop and the linux phone.

Orange is France Telecom

[Firefalcon]

Orange is a brand of France Telecom, not two separate entities:

http://www.orange.com/english/access/aboutUs.php

Re:Orange is France Telecom

[Yvanhoe]

And, if I may give an opinion on a troll-generating subject, this entity is well know for its repeated abuses of dominant position in the telephone market. I would be very careful about their specification.

Re:Orange is France Telecom

[capnchicken]

I'd be more wary of MS, it seems like they're everywhere ... I mean MontaVista and Access? *shudder*

Too little, too late

[Anonymous Coward]

Google has everyone pumped with their new phone OS.

Good luck making any inroads.

Re:Too little, too late

[AuMatar]

Not really. I'd rather program for linux than some wierd Java API any day of the week. Hell, all they have to do is provide a C++ API and there's a huge pool of developers who'd use it over Android due to language alone.

Re:Too little, too late

[morgan_greywolf]

Well, me... I'm personally holding out for a Python API. Python is really good for RAD work, and well, I gotta tell you, I don't have time for traditional development methods these days. Python is easy and quick. And that's how mobile app development should be -- you should be able to write apps on the go!

Re:Too little, too late

[GodfatherofSoul]

Have you done a lot of development work in C++ and Java? Say what you want about Java performance, but it's a far cleaner syntax than C++ resulting in much cleaner APIs. I don't know the details surrounding Android, but (assuming it is) a Java OS is going to invite quite a lot of developer effort simply because of the lower threshold for becoming competent in the language.

Re:Too little, too late

[GreatBunzinni]

That's funny, as when you write some code using the Qt library things are so clear and concise that you even get the feeling you are using some higher level scripting language. That's not the case with java. Ever.

The C++ programming language may support nice toys like templates and meta programming, which tend to be a headache to deal with and a pain to read. As a consequence, at least to some extent, the same applies to the STL. Nonetheless, who is forced to use all features of a language? No one.

So please don't say silly things. You only end up looking silly.

Re:Too little, too late

[caluml]

And because Java bytecode is compiled to native machine code at runtime, it's pretty snappy too. The tradeoff is the slight delay each time you run something. For a service that runs constantly, and hardly ever restarts, it's not a bad tradeoff.

Re:Too little, too late

[AuMatar]

No, Java isn't a cleaner language, and doesn't provide cleaner APIs. Its a far more complex language, lacking many features, and with a third rate class library. And as a bonus it has low performance with impossible to predict spikes for garbage handling, which makes it an absolutely inane idea for a real time device. I'll take C++ over it any day of the week- you'd have to pay me large amounts of money to even consider doing a job in Java. And I'd never use it for a personal project. Anything that requires me to use Java is a complete non-starter, so Android may as well not exist for me.

Re:Too little, too late

[Hal_Porter]

Python is good for beginners but a bit mainstream for my tastes.

I prefer BrainFuck.

Re:Too little, too late

[Daniel Phillips]

Well, me... I'm personally holding out for a Python API. Python is really good for RAD work, and well, I gotta tell you, I don't have time for traditional development methods these days. Python is easy and quick. And that's how mobile app development should be -- you should be able to write apps on the go! If Python had a decent native code compiler I would consider it for more applications. It is good for rapid development, yes I've experienced that, but it is cryingly, mind numbingly slow, which really hurts in any application that needs to think the slightest bit hard.

Re:Too little, too late

[fbjon]

How is Java, as a higher-level language, more complex than C++? What do you mean third rate class library, lack of functionality? And where do these impossible-to-predict gc spikes come from in a custom-made VM?

I'll grant you that handling memory management manually on small embedded devices like phones may seem like a good idea, for now. But not for long.

Re:Too little, too late

[Anonymous Coward]

Android is a java engine ON TOP of linux.

Take a look at their SDK - the emulator is the good old qemu, which simulates a complete ARM machine, on top of which runs a very standard linux kernel, and, as a userland application, their java engine.

There's nothing that prevents someone from writing native applications. I think that the user-interface part of that is pure C (I haven't checked that though). The web browser is certainly C++ (webkit). They have started by promoting shit (i.e. java) and will continue with promoting shit, but I don't think that matters in the end, provided there will be FLASHABLE phones for EVERYBODY.

Re:Too little, too late

[morgan_greywolf]

If Python had a decent native code compiler I would consider it for more applications. It is good for rapid development, yes I've experienced that, but it is cryingly, mind numbingly slow, which really hurts in any application that needs to think the slightest bit hard. You're not going to write the latest FPS in Python, no. But it still is good for a lots and lots of things. There are even interfaces to streaming media libraries and the like -- you can even write a media player in Python (in fact, I think someone did). It's also the perfect language for writing GUI frontends to things. Write your backend in C and frontend in Python, and you get the best of both worlds. As far as 'mind numblingly slow' -- well, it's all relative isn't it? Modern CPUs and memory sizes mean that the vast majority of apps can -- and probably should -- be written in interpreted languages. What do you suppose Firefox is? It's a browser written in XUL.

Anyway, I think a Python API would be cool for phones.

Re:Too little, too late

[SnT2k]

Modern CPUs and memory sizes mean that the vast majority of apps can -- and probably should -- be written in interpreted languages.

Anyway, I think a Python API would be cool for phones. For the record, an average phone would have 200 to 400 MHZ and about 64 to 128 RAM (Discounting the slow flash memory). Developers are already thinking of ways to squeeze as much performance out of those devices and here comes an interpreter which hogs a part of the resources (not much, but still significant) and an application which sits on top of the interpreter which hogs MORE resources. Oh, and don't forget the battery too. Python has its place and it's not for mobile phones IMHO. But your statement does have validity though, one can look at Mercurial and say that it's faster than svn even though it's written in python. In this case, they made well use of the apis provided by the language (which uses C in the backend) and did the control statement-intensive parts in C (which is what you suggested). But I would like to point out that Mercurial doesn't have a GUI. What does this mean? It makes combining those two languages a LOT EASIER. You need to know the limits of your Python-frontend before porting a chunk of your was-python-frontend code to C/C++ and the syntax difference makes this very hard. However, it's not hard to imagine that someone will do a framework for ths in the long run. Oh and for the record, studies show that garbage collection reduces performance by as much as 70% when the amount of memory is twice than needed: http://citeseer.ist.psu.edu/hertz05quantifying.html note that these conditions happen very often in embedded development. I believe Google made a wrong choice using Java only as an API. Sure one can say that many mobile games are written in Java... but how about MANY applications running in Java at the same time? One app takes a long time to load and I can only shiver to think of the loading times of the phone. But I'll give them the benefit of the doubt because they're using their own JVM.

Re:Too little, too late

[SnT2k]

For the record, the Dalvik VM (Google's Java VM) is NOT JIT-ing: http://code.google.com/android/reference/glossary.html

The Dalvik VM is an interpreter-only virtual machine that executes files in the Dalvik Executable (.dex) format Trade-offs? Well, for starters, they don't recommend you to create objects: http://code.google.com/android/toolbox/performance.html Wait, were're talking about Java here and most of Java programs pretty much abuse the GC. For starters, try to code the Extended GCD/Bezout-Lemma function, or any function which returns more than one trivial value, without allocating any objects at least on the heap. (honestly, this is a bad example, but just to illustrate my point).

Re:Too little, too late

[caluml]

Aaah, interesting. I didn't know that about Dalvik.

Re:Too little, too late

[Daniel Phillips]

If Python had a decent native code compiler I would consider it for more applications. It is good for rapid development, yes I've experienced that, but it is cryingly, mind numbingly slow, which really hurts in any application that needs to think the slightest bit hard. Troll? How is living in dreamland? It is a fact that Python is dirt slow. Of the popular interpreters, bash is slower and that is about it. Please do not kid yourself.

That said, I like Python a lot. I just will not use it for many applications because of performance problems. Pity.

Compared to Google's Open Handset Alliance?

[Eric Smith]

Is it competing, or are they complementary?

Re:Compared to Google's Open Handset Alliance?

[Eric Smith]

Found an answer of sorts in a PDF file on their web site: LiPS and Android Q&A. They appear to be competing. LiPS claims as advantages a formal standardization process and wider license compatability, i.e., someone could build a LiPS phone using proprietary software components, while OHA is based on shared code using the Apache 2.0 license.

I haven't looked at the actual standards, but perhaps it would be possible to extend the OHA code to add LiPS support, to produce a phone that can run apps developed for either.

rolling out specs?

[asserted]

the tone of the summary seems to suggest that while android is still vapor in terms of real devices, some other group is actually rolling out something.

except that something they are "rolling out" are specs.

which android also has plenty of. plus IDE. plus emulator.

so, well... huh?

No, no

[morgan_greywolf]

I think 2012 is already slated to be the Year of Linux on the Toaster Oven. Linux on the Phone will be probably have to wait until 2014.

Re:No, no

[TwistedOne151]

Linux on the Toaster Oven? Is that anything like Linux on a dead badger?

OK, so I didn't read TFA...

[cp.tar]

... but does this have any relation to OpenMoko?

Or will the OpenMoko guys have to play catch-up?

Re:OK, so I didn't read TFA...

[DECS]

OpenMoko is a Chinese manufacturer's plan to outsource software usinghe FOSS community. [1]

LiPS is a partnership between PalmSource/ACCESS and MontaVista Linux to collaborate on Linux phone development. Open Source Development Labs (OSDL, Slashdot's mom) began its own Mobile Linux Initiative in 2005, involving MontaVista, Wind River, and PalmSource. LiPS seemed to be an outgrowth of that. Trolltech introduced its own Greenphone platform based on Qt last fall. Earlier this year, NTT DoCoMo and Vodafone formed their own group called LiMo to develop Linux standards for mobiles. The majority of Linux phones are built by Motorola, which uses MontaVista's Linux. They are sold to the Chinese market and are not open in any sense. [2]

Google's Android is an Apache-like collaboration that shares Google's plans and implementation rather than forming a group to develop some. [3]

Apple's iPhone is based around its Mach+BSD+Cocoa architecture, but is just as closed as most Linux phones. It appears Apple will open development in the sense of releasing an SDK that allows commercial development, but it's not yet known how much access developers will have. [4][5]

One significant difference between Linux on a PC and Linux on a mobile is that it is illegal to expose the core baseband processor architecture to open software, because that would make it trivial to create network destroying devices. So "Linux-based mobiles" are really just mobile phones that have some extra environment to run the user interface and higher level functions. They are not freedom/open/GPL untainted by Big Brother/Capitalism/Corporations.

That makes it valid to be interested in mobile Linux because of familiarity with the architecture, the availability of low cost software, and a desire to expand the market for Linux based products, but there is little real political GPL-freedom argument for pursuing mobile Linux.

Google appears to initially be targeting Windows Mobile [6], and offers an alternative to the increasingly creaky Symbian [7]. Some amount of Google's Android seems complementary with efforts to use Linux on the lower levels, but it also competes against the higher level plans of LiPS, Greenphone, LiMo, and OpenMoko, none of which appear to have a very significant future.

[1] Apple iPhone vs the FIC Neo1973 OpenMoko Linux Smartphone
[2] The Standard Soup Prepared by Linux Mobile's Many Chefs
[3] The Great Google gPhone Myth
[4] Steve Jobs Ends iPhone SDK Panic
[5] Leopard, Vista and the iPhone OS X Architecture
[6] The Spectacular Failure of WinCE and Windows Mobile
[7] Origins: Why the iPhone is ARM, and isn't Symbian

Re:OK, so I didn't read TFA...

[pavon]

One significant difference between Linux on a PC and Linux on a mobile is that it is illegal to expose the core baseband processor architecture to open software, ..
That makes it valid to be interested in mobile Linux because of familiarity with the architecture, the availability of low cost software, and a desire to expand the market for Linux based products, but there is little real political GPL-freedom argument for pursuing mobile Linux. I don't see how that is different from any other hardware that has open Linux drivers but closed firmware (apart from it being mandated by law rather than being a choice made by the developer). Especially when it comes to things like video chipsets and high performance radio / data acquisition cards, who really do have an entirely separate processor running on them that is not directly accessible to the OS on the main processor(s).

Furthermore, the fact that all the applications running on my computer are Free software has just as much, if not more, "political" value to me as a user and developer as having direct access to the hardware would, because my applications are what stores my data, the most valuable part of any computing system.

My grandmother can't use Linux

[Malevolent Tester]

Admittedly, the fact that she's been dead 15 years probably doesn't help.

Linux mobile phones

[darrinallen]

Several companies already have linux Operating systems. I think motorola makes several that use the linux operating system

So where are the handset companies?

[bn0p]

Reviewing the member list at the Linux Phone Standards Forum (LiPS) web site I noticed that none of the major handset companies joined this organization. The Open Handset Alliance on the other hand has HTC, LG, Motorola and Samsung as members.

Having a standard is all well and good, but it only matters if someone puts it into a phone.

Also, how many development platforms can survive in the cell phone market anyway? Besides Android and LiPS (we'll ignore Microsoft for now), there are Symbian, the LiMo Foundation and a la Mobile - all Linux-based. The first two or three to get accepted will attract the developers and dominate the market (unless they *really* bring something new to the game).


Never let reality temper imagination

Re:So where are the handset companies?

[Orange Crush]

The more the merrier, in my opinion. To survive, a platform must attract device manufacturers, software developers and end users (and keep them). I don't see the market getting crowded--the losers will fade away fairly quickly, especially with how fast end users go through phones. God forbid we wind up with another stagnant monoculture like we got with PCs.

Re:So where are the handset companies?

[DECS]

Your comment makes it sound like Symbian is Linux based. It is, of course, not related at all. Symbian is based on the EPOC OS used by Psion for its PDAs. It's backed by Nokia and Sony Ericsson in the EU and DoCoMo in Japan, although each uses a flavor of Symbian that is really a different platform. Symbian's backers like to group them all together because that gives Symbian an overwhelming share (~70%) of the smartphone market.

In reality, Nokia's S60, and Sony Ericsson UIQ, and DoCoMo's FOMA are about as similar as Mac OS X, Linux, AIX, Solaris, SCO Unix, etc. Imagine if the Unix vendors described their share of the desktop/server market the way Symbian does.

Origins: Why the iPhone is ARM, and isn't Symbian
Smartphones: iPhone and the Big Fat Mobile Industry

The nice thing about ..

[renoX]

The nice thing about standard^Wspecification/API is that there are so many to choose from :-(

OpenMoko, Android, LiPS,.. there's going to be a selection quite soon: there aren't that many phone manufacturers who wants to develop their own applications..

Android will win

[realdodgeman]

OpenMoko and LiSP are too little, too late. Android is in the works, and they got it all: Branding, a prototype GUI, and the right members (Open Handset Alliance Project).

Android will be the Linux on mobile phones, and it will be great.

Re:Android will win

[zullnero]

As a mobile developer, your comment is hilarious. I'd mod it +5 funny, but few non-mobile software developers would get the joke. "Will be great"?

EVERYONE says that about their new upcoming mobile OS. Then it gets released, and we discover something seriously flawed about it. No APIs for custom hardware. Difficult path for porting pre-existing applications from other platforms over to it. Poor performance. Security flaws. Vendor lock-in. Insufficient API. Nonstandard. If you've ever seriously written an enterprise mobile app, you'd have a clue about this already. You frequently have to work with very custom hardware and software solutions, requiring a very major amount of flexibility and language/API maturity. So, if Google does it, that means everyone will just drop everything they're doing and furiously work to be compatible with it? Ha. Everyone will rewrite their application that their customers have been using for years because Google made a mobile OS? Nope...every company I've worked for in the past couple years decided when getting me to work on their project that Windows Mobile "might be worth investing the time into". It takes a heck of a long time to catch on, and an even longer time to get companies to devote resources into developing for it. If you aren't following an open standard with plenty of information readily available, it takes even longer.

That's most likely the road that Android is going to take. Just because Google is behind it doesn't mean that it will be used by anyone. Lots of Google's side projects end up by the wayside. And just because it comes from Google doesn't mean it'll be "great", either. Maybe Android will end up on Blackberries in a couple years or so.

Re:Android will win

[realdodgeman]

If you did some research you would know that Android is all about the APIs, and that it is open source. It also has an interesting scheduler that I look forward to seeing in action. There are some introduction videos floating around, but I can't remember where.

playing catchup

[SuperBanana]

Google's Android may be getting all the headlines, but the venerable LiPS (Linux Phone Standards Forum), which launched to much fanfare in 2005, is rolling out the specs.

From what I understand, the LiPS had been "stuck in committee" with no real progress until Google announced Android. Then all of the sudden, there was a flurry of activity.

Specs are nice, and it's good to see progress, but the slashdot summary seems to have a distinct "look at LiPS, it's better, it has SPECS!". That's great, but..here's a prototype device running Android, and let's not forget the OpenMoko people, which have not only got a so-close-you-can-taste it physical device, they've got a pretty sorted software package as well, which runs on a couple of existing phone/pda widgets. The OpenMoko stuff and the Palm/HP/etc PDA stuff (I forget the proper project names, sorry!) is quite open and documented. The Linux-on-handheld boys have had working software out there for *years*.

Welcome to the party, boys. Beer's been had, chips are gone- there's some frosting left on the cake platter, though. Same thing to Google- it's nice that they have shiny prototypes, but if they're so open-source, why couldn't they work with any of the existing groups? Ah, I love the open source world: why help someone else, when you can re-invent your own wheel (anyone remember the days of Freshmeat's front page being literally FILLED with mp3 players software?)

Re:playing catchup

[RAMMS EIN]

``Ah, I love the open source world: why help someone else, when you can re-invent your own wheel''

That's not unique to the open-source world, though. However, in the world of proprietary software

1. You _can't_ help somebody else, even if you want to
2. You may or may not have access to the specs without paying through your nose
3. One or a few big players will push everyone else out of the market

By contrast, with open source, you know that

1. You can not only use, but also contribute; you can fix the bugs and add features yourself
2. There may or may not be documentation, but there is always source code
3. The project is only dead when the last contributor quits

Access Screwed Up Linux on Palm Phone

[Doc Ruby]

Talk about LiPService: Access (of Japan) was the company that basically bought the PalmOS away from Palm. They claimed (in 2005) that they were going to roll out mobile phones running Linux, with PalmOS GUI and binary compatibility. Where are they? Just now putting out just specs, right as Google and the rest of the world blot them out of existence. Nearly certainly taking chances of a Linux mobile with Palm compatibility (and its library of apps and developers) to zero.

With that attitude

[headbulb]

Anything that at first runs slow would be a complete non-starter. Some things take time to become mature.

Java in the past has been really slow. But Java on a mobile device. Is actually pretty fast. At least on my phone.

Android really just uses the Java language then takes the class files and converts them to it's own interpreted machine language (like rim does with their devices)

Sure Java has it's downfalls but then every single language does. The problem isn't with Java. It's where the language should be used thats the problem. Also if you check anything that is being processed in real time is either done in hardware or on top of the linux os. (either in kernel or userspace) not on top of the dalvik interpreter.

Java on a mobile device, where app's stay small is a pretty good choice. Sure c++ would work but java is fine too. Now perl would be a bad choice for a phone.

With all that said when was the last time you really looked into java? With a good jvm or compiled directly?

MOD PARENT UP

[evanjfraser]

please? He/she makes some great points.

What law is that?

[Ungrounded Lightning]

One significant difference between Linux on a PC and Linux on a mobile is that it is illegal to expose the core baseband processor architecture to open software, because that would make it trivial to create network destroying devices.

I've heard that preventing such tampering was the reason much of the firmware is closed, but this is the first time I've seen the assertion of an actual law or regulation requiring the firmware internals be kept secret.

Can you (or someone) give us a pointer to the law and/or regulation in question?

Google's Open Source Mobile Platform

[softdevs]

I excited for that!!! Java Outsource