Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
PostgreSQL 9.3 beta: Federated databases and more
LWN.net Weekly Edition for May 9, 2013
(Nearly) full tickless operation in 3.10
I doubt anyone would argue that. Nokia never lost, they simply gave up right after they started.
Android, forking, and control: Communication
Posted Jun 7, 2011 16:39 UTC (Tue) by boudewijn (subscriber, #14185)
If you define "right after they started" as a period of over five or six years, yeah, then they gave up right after they started. They gave the GTK/Gnome world a long enough chance to produce something decent that a whole ecosystem of small Gnome/GTK-based companies sprouted. The same happened after they had to decide that Gnome/GTK was never going to work across Maemo and Symbian and they had to look for something better, which is Qt.
From my own experience with Nokia, with their involvement with first KOffice and then Calligra, a project that started in 2009, they really did everything right, and did do everything the way the community said it wanted -- if you budget for the fact that there was a learning curve for both the community and the company, which is only fair.
All the work on the KOffice/Calligra engine was done in the open, they took two dozen students as interns in an attempt to grow the community, joined sprints and conferences, used the project bugzilla and the project reviewboard. There's nothing for which they can be blamed and a lot for which they can be praised.
At the MWC in Barcelona, many people felt that Nokia had given working the open source way a fair try twice, and failed hard twice, while Apple with their "grab and don't give anything" mentality are a success and Google with their "grab and dump" mentality are a success, so open source is guaranteed failure.
In the end, though I am convinced that MeeGo didn't work for Nokia not because they worked with open source communities the wrong way or the right way: they failed because of internal problems and because of problems in their partnership with Intel. But nobody in the industry will see it that way.
Posted Jun 7, 2011 16:43 UTC (Tue) by bronson (subscriber, #4806)
By the time the N900 finally came around, a device that Joe Q. Public might buy, the race was already over.
Posted Jun 7, 2011 16:57 UTC (Tue) by karim (subscriber, #114)
I don't think this is a development philosophy issue as much as it's a lack of market understanding, a failed go-to-market strategy and a breach of trust with an established community. Then again, I might be completely beside the track.
Posted Jun 9, 2011 4:09 UTC (Thu) by tytso (subscriber, #9993)
Sometimes, you need to know when it's a better path to take on a little technical debt. Too much will of course sink you, but playing things too conservatively can also be a path to losing.
Posted Jun 9, 2011 14:27 UTC (Thu) by corbet (editor, #1)
What am I missing?
Posted Jun 9, 2011 14:52 UTC (Thu) by spaetz (subscriber, #32870)
Actually, interviewing the head of Maemo, I learned that they tried to internally fork first, and that didn't play out so well. So I doubt that more "technical debt" would have helped here.
Posted Jun 9, 2011 15:34 UTC (Thu) by PaulMcKenney (subscriber, #9624)
Posted Jun 9, 2011 16:06 UTC (Thu) by mjg59 (subscriber, #23239)
So while there's engineering cost involved in reworking some portions of userspace, there's also a measurable engineering benefit in doing so even if you have wakelocks. The market hasn't really been given an opportunity to decide whether or not that's important yet.
(There's technical mechanisms to force userspace to behave without wakelocks, as long as you can assume a userspace that isn't actually pathological. The engineering involved is probably still fairly minimal. They're also undemonstrated, which is more of a problem. I should really get round to trying to prototype that)
Looking forward to seeing your prototype!
Posted Jun 10, 2011 0:00 UTC (Fri) by PaulMcKenney (subscriber, #9624)
Also, when you say that an Android app taking a wakelock pretty much halves your battery life, you are thinking of an Android app that holds a wakelock indefinitely, as opposed to (for example) acquiring it an then immediately releasing it, correct? If the battery lifetime is halved by an Android app holding the wakelock indefinitely, then the Android folks might reasonably argue that this is evidence that wakelocks doubles battery lifetime.
Posted Jun 10, 2011 0:28 UTC (Fri) by mjg59 (subscriber, #23239)
I honestly haven't investigated Meego's full power management implementation, but the easiest way to implement management of this would be to use the new cgroup timer slack mechanism. You'd still require some sort of userspace-level wakelock implementation, but when no userspace locks are held you extend the timer slack for all untrusted applications out to infinity (or as close as possible). Events will still be implemented in a timely manner, but once a task's finished handling it and hits a select or timer it won't be scheduled again until another event hits.
This ought to handle the case that wakelocks are designed to handle, which is that an aggressive suspend implementation leaves you open to races between your suspend policy and event delivery. It also avoids the problem of using a freezer cgroup, where not all events are delivered through a framework so you still have races.
The main difference between wakelocks and this is that truly pathological applications still hurt you (if something's in a tight loop it'll still be scheduled), but also you have to trust your underlying layers to be correct (ie, never to wake up unless event delivery occurs). Running the current Android implementation in such an environment would result in a measurable decrease in battery life. But if your framework's been designed with this in mind, it means you get the benefits of aggressive suspend without the overhead of maintaining semi-fragile kernel modifications (some of which certainly stand no chance of going upstream).
There's no fundamental reason to think that the Android approach involved less engineering effort than Nokia's, and the long-term outcome should have been pretty similar in terms of ideal-case battery life. My experience is that it's not difficult to ensure that your core code is event driven provided that that's a design goal from the outset. So I don't think this distinction is what led to Nokia ending up so far behind schedule. There's probably more straightforward reasons for that.
Nokia, Android, and Approach to Open Source
Posted Jun 13, 2011 15:23 UTC (Mon) by PaulMcKenney (subscriber, #9624)
Then again, there is a good chance that Nokia's current experience will become a prominent business-school case study. In which case, few will pay attention to what either you or I think about the matter. ;-)
Posted Jun 13, 2011 15:40 UTC (Mon) by mjg59 (subscriber, #23239)
It's interesting to compare to Palm. Their kernel was pretty much stock (there's some additional drivers), and while they didn't take the effort to attempt to upstream stuff they'd probably have had little trouble in doing so. They ended up shipping a sufficiently attractive mobile OS that it achieved their goal of turning a failed company into an acquisition target. Which model were they closer to?
Posted Jun 17, 2011 21:21 UTC (Fri) by oak (subscriber, #2786)
I might be confusing what's in public MeeGo and "Nokia MeeGo", but if you look at the stuff in the public gitorious repos, you notice that it wasn't just "rebasing everything on top of Qt", but first writing a completely new widget toolkit on top of the Qt GraphicsView (which toolkit seems have appeared first under different name, so maybe even that was partially rewritten). One assumes that apps were started before this new toolkit was at the maturity level of e.g. (over decade old) Qt or Gtk which "can" affect how much time went to writing the apps.
And at some point QML came into picture and now there seems to be yet-another widget toolkit, this time done on top of QML...
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds