Last week’s release of MeeGo v1 is an effort by US chip maker Intel and European cellular giant Nokia to enter the mobile OS arena. Will it be able to compete? While Apple and Google vie for market dominance, MeeGo offers itself as a 3rd choice with strong Linux roots.
Merged Linux Projects
MeeGo is a combination of Intel’s Moblin project and Nokia’s Maemo 5, both of which aimed to create friendly Linux-based mobile systems.
Maemo was created in 2005 as Nokia’s attempt at a modern smartphone OS. Though its Symbian OS still holds about 50% of the global mobile OS share, begun nearly 30 years ago, the system is showing its age.
Maemo has so far proven popular with developers due to its Debian Linux roots. Because availabilty has been limited to only a handful of Nokia devices, though, it has so far not been allowed to grow outside its niche technical user group.
The Moblin project, which drew heavily from the Red Hat family of Linux, has already been adopted by a handful of device manufacturers, though has also remained relatively low-key.
As isolated projects both of these operating systems lost ground to Android and the iPhoneOS.
MeeGo hopes to spark interest with a largely pure Linux kernel at its core and a range of developers and manufacturers will be encouraged to create apps and a community around the OS much like a typical Linux distribution.
Android, Google’s freely usable and Linux-based smartphone OS, still contains restricted features and 3rd-party software that hold it back from being a fully open and interoperable platform. The iPhoneOS, has also much received criticism for being too tightly controlled by Apple.
Hardware and Software
Maemo made large strides in usability, but the Moblin project brings its optimization for Intel’s Atom low-energy processors to MeeGo.
Many manufacturers have already started incorporating the Atom chips into mobile devices, but both Asus and Nokia are expected to release a line of next-generation netbooks and Internet tablets paired with both Atom processors and the MeeGo OS.
Though MeeGo will be able to combine the best parts from both projects, this has already caused a rift in the community. Former Maemo project and application developers are timid to fully embrace MeeGo, mainly because the newer system has chosen to use Moblin’s Red Hat-derived RPM package manager over the Maemo Debian apt-get software manager.
Apt-get application packages will still be installable in the RPM environment, but the fear is that the move will cause the large Debian-family development community to lose interest in the MeeGo project.
What Matters The Most
Though both containing a multitude of new apps, Apple’s and Google’s app stores leave something to be desired. Apple is at times too controlling, and Android’s app store has been called “the wild west”, where developers can expect regulations and compatibilities to change at any moment.
MeeGo’s focus on a wide range of devices will mean that users could be given a choice in sources for applications: netbook users will likely use Intel’s AppUp store while mobile phone MeeGo systems will use Nokia’s Ovi marketplace. Each of these marketplaces offer device-specialized applications.
Early-bird consumers should be cautious not to expect a large offering of applications for MeeGo just yet. While the system promises to be a stable developing environment, neither the Maemo nor the Moblin project had large app stores to begin with.
It is be possible translate vast amounts of native Linux applications to run on MeeGo, but this will take time.
Will it successfully maneuver to become a third choice, or will it end up content in 3rd place? Only time will tell if MeeGo can mature responsively enough to compete globally as a leading mobile device operating system.
Meaningful? No
Mediocre? No way.
MeeGo is a lot like android in the sense that they needed to get a 1.0 out the door, but my no means is it mind blowing. 2.0 on the other hand is going to be great! just remember, Moblin used to be GTK based While Nokia backed (and bought) QT. 2.0 will show what MeeGo is really made of, 1.0 was just to get their foot in the door. if they had waited to release until it was super feature rich and polished then it would have been too late…
What is interesting about Meego is QT. Writing apps in QT means you can port easily those apps to all platforms supported by QT…there is not software development plataform that can do that today across all mobile devices.
Yes, and no. Code using QT APIs is portable enough, but QT may not be the only API you’re using.
If your Meego application uses the webcam, for example, I’m guessing Qt doesn’t provide cross-platform APIs to do that. Which means using platform-native APIs, meaning your app isn’t quite so portable afterall.
It certainly *helps* that QT works on a variety of platforms, but it won’t magically make your code 100% portable. Nor will it solve problems of fundamentally different interfaces – a UI built for a mouse may run on a touchscreen, but may not actually be usable by a typical fat-fingered user.
Actually, it wouldn’t surprise me if webcams are to be accessed via the in-development QtMultimedia module designed to abstract away low-level multimedia I/O.
Qt has quite the growing collection of abstractions for common mobile device functionality.
Edited 2010-06-03 23:03 UTC
Perhaps, but that’s just an example. The point is, using Qt helps with portability, but no matter how much it grows to cover, not all applications can be built using nothing but Qt. And as soon as you have to use something else, you have to worry about the portability of whatever that “something else” is.
It just happens to be that UI widgets, threading, multimedia, and to a lesser extend networking are among things that happen to be most platform-bound. And Qt abstracts the platform away there. Sure, there are some holes, but many other libraries that you’ll usually include are not highly platform dependent.
A more serious problem is incompatibility between libraries. There are many C++ libraries for, say unicode string handling or linear algebra. It would be nicer if we can standardize on a common base (such as Qt), so that at least things like passing around strings is easier. Of course, this will not happen, except if one set of libraries (either Qt or Glib/Gtk+) conquer a significant of the market. Discussion will never pick a standard here.
Take a look at QT Mobility project.
It will give you a portable way to access mobile phone sensors (Acceleration, Position…), camera, contacts, calendar, SMS/MMS …
When all this will be release quality it will cover over 90% of the needs of phone app developers.
So you could write a program and compile for everything, all in ANSI C++ and QT (close to java’s write once, run everywhere).
Unfortunately IPhone and Android will not be supported anytime soon.
Qt is adding standard APIs for all sorts of hardware. There is indeed a camera API, for example, that is in Beta at this moment, but is expected to go mainstream in H2 2010.
yay, i can fulfill my dream of running my apps on MeeGo and eComStation
(people who don’t often read my posts think I am joking)
(…people who do follow and read my posts know I am serious, and probably think I need professional help…)
w00t!
Edited 2010-06-03 23:09 UTC
OS/2 used to have a 30-step program for guys like you! (I never had the CD version, just swappin’ floppies!)
(…people who do follow and read my posts know I am serious, and probably think I need professional help…)
I usually read your comments as they’re usually intriguing, even though sometimes very much off-topic… And I gotta say, you DO need professional help
🙂
That is almost my exact solution for PIM apps on my N810. GPE calendar, contacts, tasks on the mobile device. After mucking about for a while with various converters like OpenSync; I just installed GPE calendar, contacts and tasks on my desktop and carried on happily. An “rsync -e ssh” moves the updated data files in the applicable direction.
Programs that run across multiple platforms will always win out over single platform apps for my needs.
Qt’s development flexibility is definitely a plus, but I think I’ll wait for a mobile device (not necessarily a phone since Canadian wireless data rates are worse than some developing nations) open enough that it can run a distro of my own choice… maybe a MeeGo fork that’s been rebased back to APT.
It’s an atom-based toshiba… intel graphics but not GMA500… we shall see.
So far so good. And it isn’t dropping my network connection constantly, like Moblin did.
However… evolution crashes constantly. My gmail imap folder is pretty large. I am pushing out crash logs to the devs.
Tried it on my Aspire 1410 and was almost induced to seizures due to a graphics driver bug. Moblin 2.1 worked fine so go figure. Eagerly awaiting 1.1 this fall.
You are exaggerating this matter. There was a short period after announcement when it caused some controversy, not nobody cares anymore.
What matters is that you can open terminal and type dpkg/rpm/apt/yum there, and execute advanced commands, really. Many current Maemo developers probably dislike apt quite a bit, because debian packaging is a mess.
I’ll take a more educated opinion than my own; is rpm package management that much better or was it just implemented far better in Moblin then Red Hat or Mandriva?
My basis mostly revolves around the last time I tried to find a broken rpm and reinstall it. On Debian, it’s a simple quickly command to identify changes since a package was installed where no such thing existed on Mandriva.
People thinking of installing 1.0 might find this interesting:
http://www.allaboutmaemo.com/news/item/11619_MeeGo_carries_forward_…
(it’s about SUSE et. al. releasing distros based on MeeGo 1.0 platform)
Personally, I’ll probably slap one of these on my netbook. Current MeeGo 1.0 is not really meant for end users.
I wish somebody would use MeeGo as a base to build something with GNUstep or Étoilé on top.
I do not have much hope in the future of GTK and Qt as APIs (tried them both).
After all, have we seen any complex professional application built with them after all those years? The NextStep API has proven itself capable.
What about Adobe Photoshop or Opera?
Photoshop never used Qt. A previous Adobe photo management application called Photoshop Album was written using Qt, but except the name it never had any relation to Photoshop.
Opera used Qt only for “Open File” windows and such under X11 platform and used a home grown toolkit for the rest. Opera since then ditched Qt.
Modern applications that actually use Qt are:
Google Earth
Skype for Linux
according to Wikipedia (no idea if it’s true or not) Autodesk Maya also uses Qt
Don’t KDE & related apps count as all?
Also, take a look at Qt Creator. That’s a pretty modern application by all standards.
I’m waiting for someone to make a Scheme based UI layer. It’s time that this C/C++ fad came to an end, nothing good ever came out of it.
Errr… Sounds a little bit like a troll. Especially considering that Scheme’s syntax is inherited from LISP’s one, and that nothing serious *ever* came out of Scheme afaik, contrary to C/C++ which were used to make a very large part of yesterday’s and today’s software…
Edited 2010-06-04 10:10 UTC
Exactly. Now re-read the grandparent post.
Oh ! Sorry, didn’t sleep enough tonight ^^’
Yes let’s do that!
<sarcasm>Objective-C/Cocoa: the portability of C#, the safety of C, and the terseness of Java.</sarcasm>
It has the performance almost of C and a flexibility that is unmatched by C++ – and of course C. And that is a major reason why Apple gives the rest of the crowd a run for their money, especially on mobile devices.
No, this is not a major reason.
My sarcasm detector is being mended, are you joking or should I create a list with professional gtk and qt apps?
Actually they can expect that indeed. Applications are being ported from other linux distro instantly. You get VLC, Wesnoth and everything just yet.
The rpm vs deb debate has never existed. It exists only in articles that seek traffic and controversy. Nobody actually care it’s deb or rpm. They are functionally and technically equivalent. If you look for a real controversy, you should investigate if they chose vi or emacs as default editor.
It would appear that Banshee has been selected as the default media player for Meego.
http://abock.org/2010/05/26/banshee-for-meego
This means that Meego will require Mono.
http://banshee-project.org/about/
This is a particularly confusing decision for Meego, considering that there are other capable media players (from very lightweight through to as feature-laden as you could imagine) for Linux, which have native Qt interfaces:
http://qmmp.ylsoftware.com/index_en.php
http://www.videolan.org/vlc/features.php?cat=intf
http://smplayer.sourceforge.net/
http://www.dragonplayer.net/
http://kaffeine.kde.org/
http://developer.kde.org/~wheeler/juk.html
http://amarok.kde.org/
None of those rquire Mono, or indeed other GNOME libs either.
Comments from the King of Canada regarding this decision can be found here:
http://www.pwnage.ca/?p=683
Edited 2010-06-04 06:54 UTC
I don’t know why they picked banshee (for the *netbook* profile), but I guess it’s ok because
– Banshee is a nice media player
– It’s actively developer (by paid guys?)
– Someone did the MeeGo integration work. I don’t think other media players have done this.?
– If Mono becomes illegal/untouchable again, you just switch the media player. No biggie.
So are many of those that have Qt interfaces.
So too are many of those that have Qt interfaces.
A number of the other media players don’t need integration work with Meego, they are already Qt applications.
What part of “you now need additional GNOME and Mono libraries along with Meego just to support Banshee” did you miss the significance of? Meego already includes Qt.
Isn’t Meego supposed to be “lightweight” in order to be used on mobile platforms?
Nobody ever said MeeGo Handset UX would include Banshee or Mono.
EDIT: btw, if you depend on kdelibs you don’t have a pure Qt program. It’s a rather heavy dependency.
Edited 2010-06-04 09:44 UTC
True. This is why I said only some of the media players wouldn’t require integration with Meego. This is because only some had pure Qt interfaces.
The media players with pure Qt interfaces, and hence have no kdelibs dependency, are these:
http://qmmp.ylsoftware.com/index_en.php
http://www.videolan.org/vlc/
http://smplayer.sourceforge.net/
There is also Rosegarden, which is not a media player but rather a digital audio workstation program.
http://en.wikipedia.org/wiki/Rosegarden
All of these use only Qt, and not kdelibs. Not only do they not require kdelibs, they also do not require any GNOME libs, nor Mono libs.
This makes them (apart from Rosegarden) hugely more suitable candidates than Banshee to be the default media player for Meego.
Edited 2010-06-04 10:13 UTC
I guess Banshee is just better tested and more suitable for the purpose. The alternatives are either less popular (thus tested) or not the right purpose (smplayer and VLC are just media players, they don’t include the same support for a media library).
It’s direct competitor would be Amarok I suppose, but if the integration (in the sense of UI) is better, and already there for Banshee, it kind of makes sense, I think.
It doesn’t appear to have any GNOME dependency, just GTK and GStreamer (and GStreamer is already in MeeGo, I’m not sure about GTK).
Don’t make me laugh any harder than I am already.
The main problem with MeeGo is that it’s (as of today at least) not really coordinated.
MeeGo Netbook is mostly managed by Intel and Novell, while MeeGo Handset is managed by Nokia.
Intel mainly works on Core Platform of the OS and doesn’t really care about the rest. That’s why the Moblin UI was simply inherited and only slightly tweaked since Moblin 2.
Novell is more interested in the GUI parts of MeeGo, but (at least currently) focuses more on integrating MeeGo and SUSE technologies. For example MeeGo also uses SUSE’s Build Service, but MeeGo’s requirements to Build Service are slightly different than SUSE’s. That’s why Novell works on that a lot.
AFAIK Banshee was available for Moblin as well and since Intel is (currently) not interested in that sort of stuff, the Moblin music player was ditched and Banshee simply included.
Nokia is currently (so it seems, at least) more focused in actually rewriting everything in Qt for the Handset UX, but doesn’t cooperate much with the Netbook staff.
Maybe that’ll change once the Handset UX is out the door and Nokia can concentrate on unifying all back-ends.
Any idea if Canola is to be ported to Meego? I’ve used nothing but with Maemo so far.
My 2 favourites are:
Anders Hejlsberg used to “corrupt” the Java standard
and playing the overused patent card.
Goodbye Meego. Application development coherence was one thing they needed with this, and they’ve just blown that away.
And how is availability of either Mono or Banshee going to hurt app development coherence? It’s not like Mono is being actively pushed as a development platform – and for smaller devices, it might not be available at all.
Meego is suppoed to be Intel/Nokia’s response to Android, and as such you’re supposed to be able to develop lots of neat applications for it – as I read it anyway. The applications you install on it should, if it is any kind of respectable platform, have a coherent way of integrating with each other, and integrate with any default applications specifically. That includes the default media player. However, nobody seems to think about this when they start pushing default shit in your average Linux distribution.
If Qt is their development path for doing this, as they say, then trying to do this with Banshee is going to be close to impossible at worst and hideously unreliable at best, because you’re on your own basically.
Meego fails already. Developers, developers, developers, developers. You’d think people would know what this means. Most don’t.
Meego is a platform, therefore everything pre-installed on it has to be a part of that platform and it would be nice if even Meego followed its own development guidelines.
Edited 2010-06-06 23:38 UTC
I don’t think so. Meego is about building synergies between Maemo (which predates Android) and Moblin (also predates Android)
You seem to think all the market is trying to catch up to Android or something like that. I believe it is the other way around.
Official stance (according to the dev mailing list) is that only Qt is the preferred app development method. GTK (and Mono) is only included with the Netbook Edition for legacy reasons, they say.
Native KeepassX will be welcome. the QT KeepassX on GTK maemo cludge mostly works but not nearly as well as the password manager works everywhere else.
I think Meego is too complicated for average user at the moment. So I see 2 paths:
1) Nokia messes things too much and alienates old users when try to make it more userfriendly.
2) Nokia doesn’t do nothing, Meego stays as niche product, gets axed after few years when Nokia reorganize again.
Why so negative view, because Nokia is mess at the moment. There is no clear view or battleplan how to execute that view. Nokia is going to go yet another reorganizing in few years and they are going to axe either Symbian or Meego. Also project has huge problem since Nokia is intrested on getting back to mobile business but Intel is more intrested on tablet business. Again clear view which way project should be moving is unclear.
3) MeeGo evolves to become a great mobile-media OS. In the mean time, developers flee Apple due to their draconian policies while users switch from Apple to something cheaper that is “good enough”. Android has now reached version 5.8 (codenamed Carrot cake) but still feels beta, and the battery only lasts 4 hours…
[disclaimer: I am a Symbian and Android user]
Correction: you have no clear view about what Nokia is doing. You are confused because Nokia is doing many things at the same time. This is perfectly normal. They have 130 000 employees, 40 000 of them being in R&D.
I think you are mistaken…
Intel is ALREADY in the tablet market. The chips that they produce can be easily deployed in tablets as seen by the very short time they have delivered working tablets with MeeGo on it already. The smarthphone market is another thing. This is ARM’s territory and Intel is now trying to break that.
With Nokia over complicating stuff for the end users, how do you know this? They are not even out with the product yet. Have you used any of the other Maemo enabled-devices yet?
I think that you have a over simplistic view of how Nokia is doing things. They have pretty much said “if you want a normal phone, buy symbian, if you want the latest technology in smarthphone/tablet/etc go with MeeGo”
Nokia does not need to “axe” the MeeGo division since what they will essentially do is to build on top of it, maybe with the Qt move they can even implement the entire UI for both MeeGo and Symbian.
Of course there is and it’s all centered around Qt. Anybody who is remotely interested in smartphone tech and who doesn’t live under a rock knows that since 2008 when Nokia bought Trolltech.
And it won’t matter at all, because then all development is centered around Qt anyway.
Application developers don’t need to know which kernel works at the core: Symbian or Linux/MeeGo.
Just recompile an app in Qt Creator and all’s set.
Again: You have no clue.
Intel is very interested in the smartphone business. That’s why Intel is developing Mooretown and successive CPU generations.
Now that’s what meego really need:
– a *** new name. seriously, meego? the name’s a reason alone for many people not to buy. Yeah, we’re that superficial.
– a good phone. the n900 won’t be officially supported and it’s too big. Something like the N8 with meego on top, and it’s sold.
Think about it:
Which of us “geeks” would get an iPhone with the need to jailbreak and all the restrictions? Unless you’re an Apple fan, you won’t really want one all that much.
Which of us really wants an android phone? You need to root it, just like the jailbreak, and then it’s not really the Linux you’re used to. The “appstore” has more sane rules yes, but the phone isn’t all that fun and still restricted.
Now.. a phone that compromises *nothing* and runs a “real” Linux with full access (like a N8 with meego on top), how would we resist?
Not only you get all the regular functionality with a sexy interface, but you can run any of your X programs (granted that they’re recompiled for ARM) or throw in some code in minutes. And there’s no restrictions.
You like python, ruby, qt, C, whatever, just go ahead. No restrictions.
ps: blatantly omitting “feu” webos
Officially being the keyword here. It is ‘semi-official’. By this I mean that while Nokia is not officially going to support it, and provide Tech support for MeeGo on the N900, they are paying developers to port it to the N900. Nokia has also provided the closed source bits to the project, so that MeeGo will run without hardware compatibilities.
So really, if you think about it, they just aren’t providing tech support. Which means…. well nothing to most of the people that would be dual-booting Maemo and MeeGo on their N900s.
Either way, the N900 is awesome. Though it would have been killer if the N8 ran MeeGo rather than Symbian^3.
Having cut my teeth and grown up on RPM based distributions.. I don’t wanna go back! apt-get/aptitude management of deb packages is so much better from install/uninstall/resolution on through to orphan hunting, integrity validation and broken package identification/repare. The stuff that can’t be done or done easily with RPM is easily accomplished in the rare cases when one needs to resolve issues with more than an “aptitude reinstall package.deb”.
“The best of both distributions” sure doesn’t refer to package management and distribution.
The package management decision in addition to the new branding and architecture has completely stalled my plans to buy an N900 until after confirming what Maemo5 apps will be ported along with if I can still run my usual suite of tools (ruby, metasploit, scappy, kismet, aircrack and several other utilities). I could be reasonably sure that they’d come to Maemo5 but with the Meego merge, there is a lot up in the air.
I honestly hope Nokia can keep the community together but time will tell.
You just confirmed that you have absolutely no clue at all, because you are confusing package formats with package managers.
First of all, you obviously never actually used zypper, because zypper has most features of apt/aptitude and many more. For example zypper allows package installation via BitTorrent (it uses aria2c as download manager).
Secondly, there is also apt4rpm.
“You just confirmed that you have absolutely no clue at all”
You needn’t be insulting. If you where a little slower on the trigger, you’d have noticed that I have enough of a clue to realize others know more about the package file formats than I do.
http://www.osnews.com/thread?428212
So, now that you’ve gotten the egotistical insult out of the way.. did you want to respond with some technical details regarding the two package formats and related tools? What technical details make the rpm package format better than deb packages? Has it been confirmed that the rpm management tools will be as robust or more so than apt-get or that apt-get/aptitude will be included with rpm support?
Actually there is nothing that makes apt-get better than yum or deb better than rpm. They are functionally equivalent. You had a bad experience with Red Hat or Mandriva because their QA was not on par with Debian’s. What makes package management robust is not the deb format or apt-get, it’s the gigantic work Debian developers do on QA. If they didn’t do all this work, the experience would suck just as much. So they choosing rpm does tell nothing about their QA. They can fuck up either with deb or rpm, or they can have something just as strong as debian if their QA is that good.
I can see the basis for that. Simply going from old Red Hat’s RPM manager to Mandriva’s urpmi wrapper shows the difference implementation can make. rhell was so bad back in the day that I’d simply download the src.rpm and try compiling it to confirm that all dependencies where in place; Mandriva’s wrapper managed dependencies taking away the src.rpm compilation testing step. I can’t even remember what Mandriva version I started in on but it wasn’t named by year at the time.
Recently what brought it all back for me was trying to help someone in other forums. They’d had a system crash that left VMs with damaged “hard drives”. I was shocked to discover that there wasn’t simply an rpmsums that displayed changed or damaged package installs. When recreating the issue, to some degree, with a Debian vm I simply ran debsums and reinstalled the damaged packages.
My understanding was also that the .deb format managed prerun, postrun and package contents better but that is a technical detail I’m open to correction on.
(now if Debian/VMware would only compile my flitchen vsock kernel module.. that’s a separate source of grief I’m banging my head against the last few days though. Damn VMs.. once you live with ’em.. you can’t live without.)
Anyhow.. if I get VMware Server functioning on this machine again I’ll have to do a PCLinuxOS install as I understand it mixes up the management tools using apt-get to manage an rpm based distro.
No, they are functionaly and technicaly equivalent. There are other different package managers, like portage or conary and we can discuss if they are better or not but deb and rpm are equivalent. You can do the same stuff and you can convert them with alien.
And you will find that rpm or apt-get has nothing to do with the distro quality.
http://www.rpm.org/max-rpm/ch-rpm-verify.html
I was sure we looked at the -V switch as my first check would have been an rpm –help and man rpm. I’m passing that link on though encase the particular geek still has the borked VM image laying around.
Just reading the comments section makes me wonder why any developer in their right mind would want to jump into these pedantic “my favorite media player/Qt lib/Mono/whatever is better than yours” mess and develop for this platform. Too many arguments about which platform is which, too many libraries and random interdependencies, and too many combinations. It forces developers (and users) to care about things that we really don’t want to care about. Add this to the potential for multiple hardware platforms, and it’s a mess.
Little things are enough to turn off a developer. “Mono? Well, I refuse to develop for the platform”.
What the hell is Nokia thinking? They sell a ton of phones, but that market is shrinking. They’ve lost momentum, and every day that goes by, they lose a tiny bit of relevance. Now they’re behind even Microsoft on that market.
A Linux-based platform like WebOS and Android have it right. A coherent set of APIs, a development platform that makes sense, no one is freaking out if some media player needs mono (because they don’t, and even if they did, it’s hidden and the point is moot) and all you have to worry about is the variety of hardware.
QT, QT, QT. It’s all about QT. Other platforms have their problems too. Android doesn’t run mono, it’s only java.
Did you miss the part about Qt being the only recommended way to develop programs for MeeGo?
Nope. So how is one supposed to get applications to communicate and integrate with one another when default applications are written with a completely different development technology and Meego isn’t even following its own guidelines?
Let’s see what happens.
I fully agree that the current situation is kinda messy and not really coordinated.
“MeeGo 1.0 Netbook” is nothing more than Moblin 2.2 that happens to ship Qt libraries.
It gets interesting once Nokia releases its Handset environment. It will bring many additional Qt-based back-end technologies that can be used by application developers.
I think the real test how honest Intel is with Qt (Nokia is obviously honest about trying to push Qt,because it’s its own) is the new Tablet UX: http://www.youtube.com/watch?v=iVIKYF7MOzU&fmt=35
It was demonstrated by Intel just a few days ago.
With the Netbook UX Intel could say “This is our legacy technology. Tweaking it is less work than rewriting everything in Qt.”
If the Tablet UX is written in Qt, then Intel’s “legacy” comments are believable. However, if Intel uses Clutter/MX for that, MeeGo fragmentation is unavoidable and Google and Apple will laugh their ass of, because sloppy competition only helps Android and iPad.
I think the tablet demo was built using QML.
If this slew of comments is any indication of how well Linux users and devs get along, is it any wonder that we’re still waiting for a suitable Linux desktop distro to gain some significant market share? I’ve rarely seen this much bitching and whining outside of a Mac vs Windows thread or an old Amiga vs Mac vs Windows thread. q.v. the PS3 vs Xbox 360 or vi vs emacs idiots, etc. I highly recommend that you all either put up or shut up by joining the Meego fora to contribute something positive to the community or go about your business and haunt some dusty corner of Usenet where trolls and curmudgeons are de rigeur.