MeeGo 1.2 on the N900
As discussed last week, the ongoing absence of a mass-market handheld device running MeeGo remains a thorn in the project's side. While the set-top box and in-vehicle platforms have signed on major OEM adopters, the general consumer market remains focused on smartphones. Several rumors were circulating around MeeGo Conference San Francisco last month, hinting that Nokia had intended to launch its long-planned MeeGo-based phone at the event, but had been forced to push back the release date again (the stories conflict as to why). Nevertheless, a community effort exists to develop a user-ready MeeGo distribution for the N900 handset, and that team did make a release at the conference.
The project is known as the MeeGo Developer Edition (DE) for N900, and its latest release is named MeeGoConf/SF in honor of its unveiling at the conference. The SF release is based on MeeGo 1.2, but includes a lengthy set of customizations that have been shared back upstream with the MeeGo Handset user experience (UX) project (although not all of the changes are destined to be merged into the official MeeGo releases). The MeeGo DE software is currently in a working and remarkably stable state, though the developers caution that it still should not be used as a daily replacement for the N900's default Maemo OS — there are the to-be-expected bugs, plus the loss of warranty protection. Still, the team has set very user-oriented goals for the project, and it is a pleasant surprise to see just how well some of them work.
Inside the Developer Edition
![[Jukka Eklund]](https://static.lwn.net/images/2011/meego-eklund-sm.jpg)
Jukka Eklund led a panel session presentation about the MeeGo DE release on the final day of the conference. In it, he outlined four use-cases that the team established as its goals: working cellular calls, working SMS messages, a working camera, and a browser working over WiFi. The camera goal was added to the list along the way, he noted, because the camera code was working so well.
In addition to that core functionality, the team decided to include certain add-ons on top of the base MeeGo Handset distribution, including additional applications (the Firefox For Mobile browser, Peregrine instant messenger, the QmlReddit news reader, etc.), improvements to core MeeGo Handset applications (such as a heavily patched and ported-to-QML dialer, and improved volume-control), and some entirely new functionality. The new functionality includes USB modes not yet supported upstream, plus the ability to lock and unlock a SIM card with a PIN code — including a user interface to do so.
Although the MeeGo DE project works entirely in the open, within the existing MeeGo project infrastructure (IRC, mailing lists, and bug tracker), Eklund described its mindset as working like a "virtual vendor
", following the same product management life-cycle as a commercial hardware/software supplier would — but sharing the experience in the open, and providing its changes back to the community.
That is a novel and interesting approach: the Linux Foundation makes much out of MeeGo's ability to shorten product-development times and costs, but typically with real-world examples where a product emerges only at the end. The WeTab team was on hand during the MeeGo Conference keynote to say that their MeeGo-based tablet went from design to production in a scant four months, for example. There is certainly no reason to doubt those numbers, but actually seeing the process documented is even better.
On top of that, Nokia has long defended its right to keep its own UX layer proprietary because it is the only way to "differentiate
" its MeeGo products in the market. That mindset, it seems, has led partly to the project's current UX strategy, where MeeGo releases drop with a set of "reference quality" UXes that vary considerably in usability and polish. It is to the MeeGo DE team's credit that they have improved on the reference UX and sent their patches upstream. Some (such as the dialer) have already been merged; others (such as the theme and UI layer) have a less-than-clear fate awaiting them.
Eklund covered the current status of the SF release, gave some time for fellow panelists Makoto Sugano, Harri Hakulinen, Marko Saukko, and Carsten Munk to make comments, then proceeded to demonstrate the new code running on an N900. The demonstration included the revamped dialer, which he used to call Tom Swindell — the developer who ported the dialer to QML — there in the audience. He also showed off the basic application set, and demonstrated the N900's ability to run the MeeGo Tablet UX (although the tablet interface is not quite usable, as it assumes larger screen real estate).
Testing
![[N900]](https://static.lwn.net/images/2011/meego-n900-sm.jpg)
As nice as the demo was, I decided that I must try out the code on my own N900 in order to get the full experience. Installation instructions are on the MeeGo wiki, which proved to be the only challenging part of the process — not insurmountable, but probably due for a cleanup. The wiki spreads out download, flashing, memory card preparation, and installation instructions over a large number of pages, some of which are not properly updated to reflect the current state of the release and show signs of multiple editors crossing paths.
For example, the "Install image" table lists two separate processes as the "recommended way
" to install MeeGo DE, and the most-recommended-process is listed as "Dual-boot install," which is a separate entry from "MMC Installation" even though it in fact requires installing MeeGo DE to the phone's MMC card. In addition, there are a few places where the instructions say that a 2GB memory card is sufficient, but this is no longer true as of the SF release, which takes at least 4GB of storage.
The simplest option is to install the uBoot bootloader on the phone (which necessitates activating the unstable Maemo Extras-devel repository first, at least long enough to add uBoot), then to write the raw MeeGo DE image to an un-mounted microSD card. On the SF release download page, this is the large .raw.bz2 file. It is theoretically possible to download the raw image from the N900 itself, then pipe it through bzcat into dd to write it directly to the memory card, but I wimped out and did the card-preparation step from a desktop Linux machine instead.
With the newly-written memory card inserted into the phone, all that remains it to power it on. The uBoot loader will recognize the bootable volume on the card, and load it by default, booting the phone into MeeGo DE. To boot the phone into Maemo again, you simply reboot with the memory card removed, or type run noloboot
at the uBoot prompt at power-on.
Browsing around, I have to say I was quite impressed with MeeGo DE. There are a few areas where DE is a noticeable improvement over vanilla MeeGo Handset UX: the UI widgets are more consistent in appearance, the text is higher-contrast and more readable, and the UI navigation cues (such as the "return to home" button and the application grid's page indicator) easier to pick up on.
Loading applications is slow, although this is no doubt largely dependent on the speed of the memory card I used. Once launched, the interface runs smoothly, including the quick QML transitions. As for the application set itself, the dialer is (as all reports had indicated) a vast improvement over the stock Maemo dialer. It is easier to find contacts and enter numbers, and the on-screen buttons respond faster to finger-presses. There are similar usability improvements in the network and general configuration settings — Maemo's interface for connecting to a new WiFi access point or Bluetooth device borders on arduous. The camera seems faster to focus, and is much faster to adjust to lighting changes and to display the most recent shot.
On the other hand, there are pain points. I could not get the video player to work at all (the SF release ships with both Big Buck Bunny and a stalwart, YouTube-caliber kitty video in 240p); it alternated between displaying only a black screen and playing wildly stretched-out-of-proportion. The audio player has a nicer navigation structure than Maemo's (which relies on large, vertically-scrolling lists oddly displayed only in landscape format), but the playback buttons are tiny — about one-fourth the size of the application launcher buttons.
For some reason, MeeGo DE will sense the device orientation and rotate the display into three of the four possible directions, but not the fourth, upside-down-portrait. I don't have any need to use my phone in upside-down-portrait orientation, but surely it is more useful than upside-down-landscape, which is supported, even though it leaves you with an upside-down keyboard. Finally, I could not get the hang of the top status panel; I kept wanting (or expecting) it to open up a quick-settings menu, like it does in Maemo, for common tasks like enabling or disabling Bluetooth or the data connection.
The third-party applications are a mixed bag, as you might expect. I am a big fan of Firefox For Mobile, and Peregrine seems nice, but I was less impressed with the Kasvopus Facebook app. Some of the apps use their own widget styles, which can be awkward. That is certainly not MeeGo DE's fault, but it raises some questions about QML. One of Maemo's strong suits is that all of the applications use the same toolkit, so feature buttons, sliders, and notifications are easy to pick out. The more applications that write their own crazy QML interfaces, the more potential for user confusion there is.
On the whole, however, the SF release packs a good selection of applications. If you have purchased a phone recently, you no doubt remember that the first step is always removing the glut of sponsored apps and vendor-provided tools that only work with a single service. MeeGo DE doesn't go overboard in its service offerings, it just provides you with a flexible set of utilities: an IM client, not a GoogleTalk-only or Skype-only app; a real browser, not a Yahoo-only search tool.
All that said, MeeGo DE is not yet ready to serve as a full replacement for Maemo. The big blockers at the moment are mobile data and power management, but it will need improvements in SMS and MMS support, call notification, and a few other key usability areas. Eklund and the other team members are straightforward about the intended audience of the DE builds: they are a showcase for MeeGo on handsets, they demonstrate that the code can run comfortably well even on hardware several years old, and they allow the community to push the envelope where commercial phone-makers are not.
On all of those fronts, one must consider the MeeGo DE SF release a success. I experienced no crashes, and I both made and received phone calls without incident. Better yet, the UX layer (including both the interface and the application suite) is an improvement over the reference design. If the MeeGo steering group wants to keep the reference UXes in an unpolished, demo-only state, they still can. I personally feel like that is a mistake: no OEM is prevented from replacing them in order to differentiate its products, but the gadget-hungry public always sees a demo-quality design first. But MeeGo DE for the N900 shows that the project doesn't have to continue down that road, because the community is ready and willing to pitch in.
[ The author would like to thank the Linux Foundation for sponsoring his travel to the MeeGo Conference. ]
Index entries for this article | |
---|---|
GuestArticles | Willis, Nathan |
Conference | MeeGo Conference/2011 |
Posted Jun 3, 2011 9:21 UTC (Fri)
by jospoortvliet (guest, #33164)
[Link]
Will it receive (semi-regular) updates? Because if a few of the issues you mention get fixed I'm ready to jump on board...
Posted Jun 3, 2011 11:42 UTC (Fri)
by ras (subscriber, #33059)
[Link] (8 responses)
As it is I'm not even sure Nokia will be releasing Windows Phones in 3 years time. Geezz, what a mess those fins have managed to create.
Posted Jun 3, 2011 14:13 UTC (Fri)
by AndreE (guest, #60148)
[Link] (7 responses)
Posted Jun 3, 2011 16:56 UTC (Fri)
by n8willis (subscriber, #43041)
[Link] (6 responses)
Nate
Posted Jun 4, 2011 0:07 UTC (Sat)
by bronson (subscriber, #4806)
[Link] (5 responses)
Posted Jun 4, 2011 1:38 UTC (Sat)
by n8willis (subscriber, #43041)
[Link] (4 responses)
(B) You realize MeeGo isn't Maemo, right?
Nate
Posted Jun 4, 2011 3:07 UTC (Sat)
by ras (subscriber, #33059)
[Link] (3 responses)
The way Elop saw the world is explained here:
http://www.businessweek.com/magazine/content/11_24/b42320...
I gather from that Symbian had become unmaintainable. The usual metric for this is the number of bugs keep growing, despite strident efforts to fix them. As a long time Symbian user I can testify that was true. As a software engineer I can only guess what the reasons for that might be. I also gather from the link the great white hope was to replace Symbian with Linux (be that Maemo / MeeGo or whatever). So I was taking from that they were betting the companies smart phone future what was Maemo.
When the N900 was released it looked to me like that were going to pull that off. The incessant loud GUI arguments we seem to have about colours, button sizes and associated fluff were obviously still ongoing, but from a software engineering point of view the underlying libraries were working like a charm. On hardware that was more limited than the iPhone, the thing was crisp, the animations were smooth and all the normal functionality you expect to find on a phone was there.
Then two really odd things happened. If you are betting your company on an almost working platform, do you then: (a) move from a .deb distribution to a .rpm one, header by another company and (b) move from gtk to qt? Of those two, the gtk --> qt thing looks by far the worst, as all their gui has to be laboriously ported. At least there seems to be very good software engineering justifications for making that switch, even if the timing looked to be spectacularly poor. As it happens Nokia trolls swear they were ready for release by the due date - Q4 2010. Looking at the QT release dates - 4.7 released September 2010, I can't help but wonder if that view isn't distorted by a tiny amount of "it's my baby" bias, but it's hard to tell.
I can think of no software engineering reason for the Maemo --> MeeGo move, which was essentially a move from .deb to .rpm. But they are for all intents and purposes equivalent, so technically it wasn't a big move. If I had a Debian based system which I was working feverishly on to get the next release out, and was told in the middle of it I had to move it to RH/Suse/Whatever it would be done in a few man months, assuming I wasn't fired in the mean time for hurling abuse at upper management. The move isn't rocket science. If you take a scorched earth approach, you just use whatever packages are the same, port the rest, and package a appropriately configured kernel. There must be 1000's of engineers out there who could do this in their sleep.
Yet the Nokia trolls were quite emphatic on the Maemo --> MeeGo transition being the killer. Maybe the it wasn't the engineering, maybe trying to navigate the social aspect of going to a new distribution run by another company was like trying to swim in treacle. But regardless, technically it makes no sense. As bronson said was started 3 years before the iPhone, it was mature, and the technically the Maemo --> MeeGo should have been a minor bump in the road.
Someone who was there should write a "The Soul of a New Machine" book about it, so the rest of us can understand what happened.
Posted Jun 4, 2011 12:09 UTC (Sat)
by n8willis (subscriber, #43041)
[Link]
Definitely rewriting the toolkit stack is what kept Nokia from releasing a second Maemo phone, but your timing of events is mixed up. That started with the Harmattan cycle, in 2009, and well before MeeGo. For whatever reason, after the Trolltech purchase, someone decided that they had to dogfood Qt and Qt alone in all of their products, immediately, regardless of the costs.
The Deb-to-RPM transition came after the Maemo/Moblin->MeeGo merger, and isn't really related. Little more than a LSB-compliance move. So while Harmattan->MeeGo might could have been "a bump in the road" as you put it, Fremantle->Harmattan before it is what actually kept Nokia from expanding its offerings.
MeeGo is not simply "Maemo 6" or even "Maemo 7." In spite of Nokia's product-release problems, MeeGo has some significantly orthogonal goals, such as cross-UX-compatibility, and that's the really significant part. It may even be healthier for MeeGo that Nokia isn't pursuing it as hard, since that "Qt-only" emphasis (which was strategic- but not engineering-based) could prove to be thorny again (see Moblin's Clutter layer, for example).
Nate
Posted Jun 7, 2011 0:20 UTC (Tue)
by felipec (guest, #75494)
[Link]
Right now I don't think I can say much, just that IMO the issues were not technical.
Posted Jun 22, 2011 10:29 UTC (Wed)
by job (guest, #670)
[Link]
Posted Jun 3, 2011 18:22 UTC (Fri)
by Felix.Braun (guest, #3032)
[Link] (2 responses)
I have tried out the DE-Images on my N900 (also booting from a class 6 MMC). Unfortunately, the start-up performance of the applications is a true blocker bug for me. For example, starting the browser takes somewhere around 40 seconds. This is an order of magnitude off from being dogfoodable. This is true about all other applications too (see the wiki for details). So while these images might be ok as testbeds for development, not even an old-school linux enthusiast accustomed to rough edges and missing functionality would be able to bear using them as their primary phone OS.
I'm not sure, how much flashing the images on the built-in MMC would speed up the process. However, if I interpret the graphs from the wiki correctly, a class 6 external MMC should be a bit faster than the internal eMMC. If this is true, then the developpers still have a fair amount of work to get this UX into a dogfoodable state.
Posted Jun 4, 2011 9:10 UTC (Sat)
by tajyrink (subscriber, #2750)
[Link]
I agree that even coming from the Neo FreeRunner world (3+ years old hardware), 40s is a bit too much :)
Posted Jun 7, 2011 12:13 UTC (Tue)
by lamikr (guest, #2289)
[Link]
Current images includes btw also the gpe-mini-browser in addition of fennec.
MeeGo 1.2 on the N900
MeeGo 1.2 on the N900
MeeGo 1.2 on the N900
Android was released a full year before any devices shipped. It was closer to three years before it started making a significant dent in the percentages. I'd like to hear someone articulate why different standards ought to apply here. The truth is, expectations ≠ what's actually going to happen.
MeeGo 1.2 on the N900
MeeGo 1.2 on the N900
MeeGo 1.2 on the N900
MeeGo 1.2 on the N900
MeeGo 1.2 on the N900
MeeGo 1.2 on the N900
MeeGo 1.2 on the N900
MeeGo 1.2 on the N900
MeeGo 1.2 on the N900
MeeGo 1.2 on the N900
is the memory foot print. N900 has 256 mb of ram and at the moment it's basically the amount of mem we have already used once the device has booted up. (Which takes about 70 second atm.)
It's much lighter (about 10 sec startup) while still providing good rendering on pages I have visited.