MeeGo vs Android | Hacker News Reader

MeeGo vs Android

wiki.meego.com

42 pointspapercutter15 comments

I am interested in how can MeeGo support multiply architectures without requiring the developer to build against all of them... Last time I checked MeeGo apps were native code.

Also the in my opinion the fragmentation problem is due to the handset manufacturer's politics. I have a HTC Tattoo with Android 1.6 I could flash a 2.2 on it but then some hardware components wouldn't work, because it seems that it wasn't in HTC's interest to give back those drivers.

I am interested how will MeeGo tackle this.

>>it seems that it wasn't in HTC's interest to give back those drivers

You're probably wrong, last time I checked HTC had all their Android firmware sources available for download.

The linux kernel is GPLed, so they would have to make the sources for those drivers public, wouldn't they?

Not necessarily. There are a number of ways to interact with hardware from userspace: uio[1], libusb[2], spidev[3] and etc.

[1] http://lwn.net/Articles/232575 [2] http://libusb.org [3] http://www.kernel.org/doc/Documentation/spi/spidev

And AFAIK, they did - http://developer.htc.com/

HTC Tattoo - Donut - 2.6.29 kernel source code - http://dl3.htc.com/RomCode/Source_and_Binaries/click-656120....

The difference; HTC pays a group of people who's job it is to make things work. The fact that that 2.2 has even an minimal port for the Tattoo is testament to the open source community.

the driver interfaces are exempt from gpl. that's how e.g. nvidia can publish closed-source drivers.

however;

1) those interfaces are in constant flux (a situation officially supported by linus himself) which makes it more difficult to maintain proprietary drivers. if you open-source your module and it becomes part of the mainline, it's migrated to the new interface by the dev who introduces that change.

2) once you load a proprietary driver, the kernel is considered to be 'tainted'. this means people are much less willing to listen to you when you report problems. (try dmesg | grep -i taint if you're using a proprietary driver)

Most Maemo (Meego compatible) apps I use on my N900 are written in python.

If by architecture you mean arm / intel / ..., it's just a case of recompilation. You can crosscompile to another architecture quite easily if you have a well configured environment provided from upstream. Since the system is the same, there shouldn't be many problems.

If you mean architecture as in screen size, etc. - you just need to test for what's available.

Android's software is being pushed by Google, and the hardware - and so device drivers - by a few mobile device manufacturers including HTC.

MeeGo's software is being pushed by Nokia, and Nokia will also be the biggest provider of mobile phone hardware.

If Nokia are committed to MeeGo (and they've been making Maemo devices for years now and have done more-or-less right by that community) then I don't think device drivers are going to be an issue.

If other mobile phone manufacturers pick up MeeGo then there might be issues, but I imagine that no one will be interested until at least Nokia have shown that it's a viable platform.

It looks like Nokia now expects [1] most MeeGo apps to be written using Qt Quick:

http://qt.nokia.com/products/qt-quick/

Qt Quick is a very high-level toolkit for touchscreen UI design. Instead of native C++ code, Qt Quick apps are written in JavaScript and QML, a declarative UI language.

This solves the problem of supporting multiple architectures without needing a recompile -- at least for those apps which are simple enough to not require a C++ component.

QML is actually pretty cool. IMHO it's lightyears ahead of the clunky XML widget declaration specifications like the one used by Android, for instance.

[1] Nokia recently announced that Qt Quick is going to be their preferred toolkit for both internal development and 3rd parties, on both Symbian and MeeGo. (They were heading for some seriously silly internal fragmentation by having incompatible Qt-based toolkits on the two platforms, so standardizing on Qt Quick is a relief.)

Well this seems to be a lot more sensible than Android, though in my opinion they should have used full featured JavaScript.

Going defensive so early in the game isn't a good sign for MeeGo

This is a link to the meego wiki. It's more of a brainstorm.

Indeed. That page now clarifies:

  THIS PAGE IS A DRAFT AND DOESN'T REFLECT OFFICIAL OPINIONS OF THE MEEGO PROJECT

(Sorry for the caps. I just copied the literal text.)

MeeGo is competing with less than free (Android) and at a significant disadvantage. It's worth trying; the stakes are sky high. But man is the deck stacked against them right now.

Reply on news.ycombinator.com