Waiting for a MeeGo: Intel and Nokia to Open Repository
Following the announcement in February, the subsequent weeks were pretty quiet around the MeeGo mobile platform. The reason why: no code.
If it were up to Intel and Nokia, we'd be seeing the first devices with the new platform around the end of year. MeeGo is a merge of Maemo and Moblin. However, there's been a general silence about it since the announcement mid-February, with no nice screenshots or source code publicly available.
One reason for the silence is the particularities of the merger. While Intel meant its Moblin platform primarily for netbooks and smartphones based on its Atom processor, Nokia's Maemo and its related devices are based specifically on the ARM platform. Many Maemo fans thus fear that Maemo will get short shrift in relation to Moblin. That this is not the case was raised rather vehemently by Valtteri Halla, coleader of the MeeGo technical steering group, in a blog the beginning of March. According to Halla, Nokia's N900 will serve as a reference design next to Intel's Atom motherboards for MeeGo development. Work is supposedly being done at a high pitch to get the first MeeGo release out by the end of March.
While ARM and x86 are being developed in parallel, the merger required three commonalities, which Hallas describes as the "big ticket items":
- Qt should be implemented as the widget set (which is no surprise after Nokia's takeover of Trolltech). Maemo was originally based on the Gtk widget set, but a transition to Qt was already planned for MeeGo from the start.
- The package manager should transition from apt-get to RPM (or yum), which Intel had been advocating, a decision with a direct bearing on the third big ticket item:
- The build environment. For this, the three partners, Intel, Nokia and the hosting Linux Foundation, settled on the OpenSUSE Build Service. Intel had already integrated Moblin into the build service with some success.
Before code can be released, a common code basis and repository are needed. Recently the MeeGo team requested from the steering group to form a repository working group that would be responsible for managing the public repository.
Then there are a number of smaller ticket items to discuss. As Hallas writes, some agreement prevails as to using X.org as the X server, Connman as the network manager, Gstreamer, D-Bus and the commonly developed Ofono telephony solution. Another item under discussion is the browser. While some developers are already working on Firefox Fennec for MeeGo, Arjan van de Ven, on the MeeGo developer list, is advocating Webkit or Chrome for better performance reasons:
"I would be seriously concerned about using either Firefox or Fennec on a mobile device. Looking at the current ecosystem, it's very clear that webkit is winning on the small side of the hardware world, and on the big side, it's making big strides as well with Chrome. While I don't want to discourage discussion, I think taking one step back and wondering if Fennec is the right choice in the first place would be very appropriate...."
A compromise solution being considered is using Webkit to access the Web, then Fennec or some other as the standard browser. Once these details are cleared up and the source packages are ready, we can count on a first test version. If this can occur by end of March is questionable based on the ongoing discussion, so we'll likely hear more about it in April.
Powerful man-in-the-middle attack is now targeting online shopping.
Another high-profile coder says the kernel team needs a kinder, gentler culture.
Bug database has a bug of its own that could allow an intruder to create an unauthorized account.
Report focuses federal resources on achieving universal Internet access.
Leading browser makers say “no” to porous encryption algorithm
Report from the X-Force group says attackers are using TOR to hide their crimes
Future Firefox extensions will be compatible with Chrome.
Better read this if you bought your computer before 2011
Users should upgrade to the new version as soon as possible
Xen project announces a privilege escalation problem for Qemu host systems