[DjDarkman]

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.

[pavlov]

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

[DjDarkman]

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

[semanticist]

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.

[viraptor]

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.

[natmaster]

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

[bsk]

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

[tomjen3]

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

[fragmede]

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.

[philips]

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

[plq]

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)