Since some people don't follow talk.maemo.org, this is to let them know I wrote a quite interesting piece to help calm some of the worries people have been having about N900 future with Maemo6 and MeeGo based on my previous experiences both as community member and as maemo.org distmaster.
You can read it at http://talk.maemo.org/showthread.php?t=45213 and it is very well received so far and covers four questions we should be asking instead of panicking.
Saturday, February 20, 2010
Friday, February 19, 2010
The Mer Project - just a bunch of redshirts?
Recently, big news arrived: The MeeGo project. But let me start with some history. In May 2009 some key members of the Mer project met up for the first time 'in real life' at the Mozilla Maemo Danish Weekend. At this event, we got some very characteristic t-shirts - very very red ones, which we since have worn proudly when we were meeting up again at various events and countries, as we could recognise each other.
While we were introduced as Maemo 5 community edition for the Nokia N810/N800/770 Internet Tablets we were far more ambitious - we loved the principle of Maemo so much that we wanted to reconstruct it, in order to make it better, more suitable for the future - because we thought the platform would not survive otherwise.
We wanted to get away from the notion that a tablet was an embedded system - Tablets are not under-powered embedded systems, they are powerful, power-efficient, economical handheld computers. We wanted to make Maemo a general platform for tablet devices. We wanted to Make it more developer-friendly. More hackable. Align with standard Linux distributions. This was to be done by separating the device and platform code - have open development of the Maemo platform - the device-specific and vendor-specific differentiation
development can be closed and many other things.
The goal was for the core Mer system is fully open source and cross-platform, open for anyone to adapt to their devices. We got far, we have something that works, but it isn't ready for users yet - Mer was a research project to try and help Maemo towards our goals.
A comment (as I recall it) from Maemo Summit 2009, where we Mer members met up again, performed several presentations - again, wearing our red shirts - "We're just a bunch of redshirts.", ambitious ensigns in red shirts - did this come true?
Some background, as it might be a bit geeky. Quoting wikipedia:
Redshirt is a slang term for a minor stock character of an adventure drama who dies violently soon after being introduced in order to dramatize the dangerous situation experienced by the main characters. The term originated with fans of the science fiction television series Star Trek, from the red shirts worn by Starfleet security officers and engineers, who frequently meet their demise during the episodes.
Fast-forwarding to this week, when the MeeGo announcement broke. Reading the pages, many things seemed familiar:
From Quim Gil: MeeGo is just like you would expect a free Linux OS to be: based on the standard Linux and Free Desktop technologies and developed publicly in a project open to all contributors
From architecture page of MeeGo:
The MeeGo OS Base layer contains the Linux kernel and core services along with the Hardware Adaptation Software required to adapt MeeGo to support various hardware architectures.
The MeeGo OS Middleware layer provides a hardware and usage model independent API for building both native applications and web run time applications.
From governance:
We showed it was possible to develop for your mobile device just as easily as developing for your desktop PC. That we didn't need Scratchbox: We began every interesting experiments with OBS (Open Build Service), where our build guy - David Greaves (lbt) made some extremely nice experiments, showing that cross-compilation could work without hassle, even for packages normally requiring native compilation. He's BTW, having a day job working with MeeGo and OBS now - helping to bring the Mer development experience into MeeGo.
Power saving and distribution alignment
Showing that it was possible to retain power saving while making porting easy by having easy access to Debian (or any distro's) huge library collection.
That the community was capable of organising OS development too
That multiple device communities could work together on a common base that would benefit them all.
That we were able to help create policy, identify problems
Some of the things coming out of Mer:
The vendor social contract - a social contract for vendors to commit to, in order to have community spending time on them and not waste their time and end up with locked devices with a open system.
Token based access restriction - a way to deal with closed sourced binaries in a open system in a way that is liveable both technically and legally.
Why an upstream basis shouldn't be a goal, but a policy alignment on mobile devices
Immediate involvement of contributors interested, that any contribution is valuable and the list goes on..
So, are we out of the plot now that the main characters have stepped in? No. My experience has been that this is a new house for us to paint and move into. A fresh start - it would first have happened in many years at the pace we were going.
The developers I've met from the Moblin side has been very open, willing to discuss - and even spoken with one of the two top guys in MeeGo. Us redshirts fit in the MeeGo project because we have experience enough now to discuss and argue on equal footing and to help to shape the future - and to create it. Like we always wanted.
For those wanting to pursue the dream (and reality now) of a open mobile Maemo platform - MeeGo is the place and that's where I (and hopefully my fellow redshirts) will go to contribute to the future of mobile Linux.
So, what will happen to Mer? We'll still be a subsection of the MeeGo community arguing for our positions, our ideas, our hopes and helping out where we can. Best way to shape the future is by participating.
Mer as a system will live on in Mer^2. A quick summary is it is a Debian 5.0 system building inside OBS with tricks making it feel like a Scratchbox for the packages, which makes most of the Fremantle platform build on it. It will work on X86 and on N8x0. Mer 0.17 will be imaged up soon and published - those who want to continue with that can. The goal is not to make a fully open source system - it will serve purpose to be a foundation on which to build a backport of Fremantle for N8x0. The hope is to be able to build most of closed things for Fremantle for N8x0 using this.
Thanks for reading. This is a bit of post-mortem for the ambitious part of Mer. Which keeps on living in the MeeGo project. This blog will be mostly devoted to Mer^2 discussions and maemo.org distmaster related issues. A role which I am yet to figure out how fits in the MeeGo community - but I'm hopeful.
While we were introduced as Maemo 5 community edition for the Nokia N810/N800/770 Internet Tablets we were far more ambitious - we loved the principle of Maemo so much that we wanted to reconstruct it, in order to make it better, more suitable for the future - because we thought the platform would not survive otherwise.
We wanted to get away from the notion that a tablet was an embedded system - Tablets are not under-powered embedded systems, they are powerful, power-efficient, economical handheld computers. We wanted to make Maemo a general platform for tablet devices. We wanted to Make it more developer-friendly. More hackable. Align with standard Linux distributions. This was to be done by separating the device and platform code - have open development of the Maemo platform - the device-specific and vendor-specific differentiation
development can be closed and many other things.
The goal was for the core Mer system is fully open source and cross-platform, open for anyone to adapt to their devices. We got far, we have something that works, but it isn't ready for users yet - Mer was a research project to try and help Maemo towards our goals.
A comment (as I recall it) from Maemo Summit 2009, where we Mer members met up again, performed several presentations - again, wearing our red shirts - "We're just a bunch of redshirts.", ambitious ensigns in red shirts - did this come true?
Some background, as it might be a bit geeky. Quoting wikipedia:
Redshirt is a slang term for a minor stock character of an adventure drama who dies violently soon after being introduced in order to dramatize the dangerous situation experienced by the main characters. The term originated with fans of the science fiction television series Star Trek, from the red shirts worn by Starfleet security officers and engineers, who frequently meet their demise during the episodes.
Fast-forwarding to this week, when the MeeGo announcement broke. Reading the pages, many things seemed familiar:
From Quim Gil: MeeGo is just like you would expect a free Linux OS to be: based on the standard Linux and Free Desktop technologies and developed publicly in a project open to all contributors
From architecture page of MeeGo:
The MeeGo OS Base layer contains the Linux kernel and core services along with the Hardware Adaptation Software required to adapt MeeGo to support various hardware architectures.
The MeeGo OS Middleware layer provides a hardware and usage model independent API for building both native applications and web run time applications.
From governance:
There is no admission process or membership fee for MeeGo; just your desire to join the project and contribute.
Any individual or organization can join and get involved in software development. We also welcome other ways of contributing to the success of the project, including writing documentation, testing, and marketing.
And so on - it was like someone had listened to our ideas and wishes..
Basically, MeeGo was what we hoped to achieve with Mer, and it's silly to continue separately instead of collaborating. Now, with the announcement - is the Mer project members then just a bunch of redshirts who helped move the plot along but in the end, is out of the game when the main characters continue with the plot?
No. I don't think so. In Mer, we managed to accomplish many interesting things:
Easy development for mobile devicesWe showed it was possible to develop for your mobile device just as easily as developing for your desktop PC. That we didn't need Scratchbox: We began every interesting experiments with OBS (Open Build Service), where our build guy - David Greaves (lbt) made some extremely nice experiments, showing that cross-compilation could work without hassle, even for packages normally requiring native compilation. He's BTW, having a day job working with MeeGo and OBS now - helping to bring the Mer development experience into MeeGo.
Power saving and distribution alignment
Showing that it was possible to retain power saving while making porting easy by having easy access to Debian (or any distro's) huge library collection.
That the community was capable of organising OS development too
That multiple device communities could work together on a common base that would benefit them all.
That we were able to help create policy, identify problems
Some of the things coming out of Mer:
The vendor social contract - a social contract for vendors to commit to, in order to have community spending time on them and not waste their time and end up with locked devices with a open system.
Token based access restriction - a way to deal with closed sourced binaries in a open system in a way that is liveable both technically and legally.
Why an upstream basis shouldn't be a goal, but a policy alignment on mobile devices
Immediate involvement of contributors interested, that any contribution is valuable and the list goes on..
So, are we out of the plot now that the main characters have stepped in? No. My experience has been that this is a new house for us to paint and move into. A fresh start - it would first have happened in many years at the pace we were going.
The developers I've met from the Moblin side has been very open, willing to discuss - and even spoken with one of the two top guys in MeeGo. Us redshirts fit in the MeeGo project because we have experience enough now to discuss and argue on equal footing and to help to shape the future - and to create it. Like we always wanted.
For those wanting to pursue the dream (and reality now) of a open mobile Maemo platform - MeeGo is the place and that's where I (and hopefully my fellow redshirts) will go to contribute to the future of mobile Linux.
So, what will happen to Mer? We'll still be a subsection of the MeeGo community arguing for our positions, our ideas, our hopes and helping out where we can. Best way to shape the future is by participating.
Mer as a system will live on in Mer^2. A quick summary is it is a Debian 5.0 system building inside OBS with tricks making it feel like a Scratchbox for the packages, which makes most of the Fremantle platform build on it. It will work on X86 and on N8x0. Mer 0.17 will be imaged up soon and published - those who want to continue with that can. The goal is not to make a fully open source system - it will serve purpose to be a foundation on which to build a backport of Fremantle for N8x0. The hope is to be able to build most of closed things for Fremantle for N8x0 using this.
Thanks for reading. This is a bit of post-mortem for the ambitious part of Mer. Which keeps on living in the MeeGo project. This blog will be mostly devoted to Mer^2 discussions and maemo.org distmaster related issues. A role which I am yet to figure out how fits in the MeeGo community - but I'm hopeful.
Wednesday, February 17, 2010
MBX/3D drivers out for N8x0 (and other OMAP2)
In other news, the drivers was uploaded to TI extranet yesterday - this is something people have waited for, for a long time. And you need to create a TI (my.ti.com) account for this. For those who want to have access the SDK need to send a mail to gamingonomap@list.ti.com stating your need for the SDK mentioned below.
You need to then click "Extranets" on my.ti.com and then WTBU-OMAP Gaming SDK and then OpenGL®ES Graphics SDK for OMAP2420 Nokia N800 OpenGL ES v1.1 and OpenVG 1.0 SDK based on Linux kernel 2.6.21
A fair warning: These drivers are not for the weak at heart. You need to flash a new kernel. You may need to fix up some build scripts and run some mysterious commands. They will not work that easily out of box.
While I kinda assume this will be drowned out in Meego announcements and discussion, well, I got the mail last night
Thanks to qwerty12, javispedro, lardman, the TI guys (Girish, Ameet) and the Nokians helping out to make this reality and others.
You need to then click "Extranets" on my.ti.com and then WTBU-OMAP Gaming SDK and then OpenGL®ES Graphics SDK for OMAP2420 Nokia N800 OpenGL ES v1.1 and OpenVG 1.0 SDK based on Linux kernel 2.6.21
A fair warning: These drivers are not for the weak at heart. You need to flash a new kernel. You may need to fix up some build scripts and run some mysterious commands. They will not work that easily out of box.
While I kinda assume this will be drowned out in Meego announcements and discussion, well, I got the mail last night
Thanks to qwerty12, javispedro, lardman, the TI guys (Girish, Ameet) and the Nokians helping out to make this reality and others.
Wednesday, February 10, 2010
Mapping openness of Maemo 5.0 PR1.1 and Maemo 4.1.2 - we're moving in the right direction!
One of the tasks I've been doing in the last couple of months has been to try and refresh the openness data for Fremantle. This has actually been quite a challenge as I've had to retrieve a lot of different sources to make a proper description of what is actually open and what is not.
The openness reports
For Fremantle PR1.1, you can find the openness report here - this is for a PR1.1 image actually installed on a device.
As per request and for comparison, I've also generated one for Maemo 4.1.2 (Diablo)
It has been difficult finding categorisation for Diablo so a lot of it is in 'Other' as I used the package categorisation from Fremantle in this.
This is supposed to be raw data for further discussion and as such there'll be subsequent analysis on top of this, explaining some of the areas and why things are as they are. Please read through this blog post for further explanation of what the data represents and how it is represented.
This openness report has the purpose of:
The purpose is not:
Classification of packages
So, to start describing what these openness reports contain. I have chosen to classify source packages into seven levels - this will also explain the headers of the table.
L1: Developed openly, no closed source dependancies
This means that the source package is developed either in garage.maemo.org, maemo.gitorious.org or some other place. This means that you can follow development and contribute patches to it, without having to wait for new releases
L2: Source published in SDK, no closed source dependancies
This means the source package is published in SDK releases. This means that you usually have to wait for a new SDK release to get updates to this package and there's no clear way to submit patches beyond bugtracker
L3: Developed openly, closed source dependancies
This means that the source package is developed either in garage.maemo.org, maemo.gitorious.org or some other place. This means that you can follow development and contribute patches to it, without having to wait for new releases
However, this is usually important for system integrators and porters of Maemo, this package depends on a closed source package to build or run. Which means it is difficult to take the package and use it outside Maemo.
L4: Source published in SDK, closed source dependancies
This means the source package is published in SDK releases. This means that you usually have to wait for a new SDK release to get updates to this package and there's no clear way to submit patches beyond bugtracker
However, this is usually important for system integrators and porters of Maemo, this package depends on a closed source package to build or run. Which means it is difficult to take the package and use it outside Maemo.
Total L1-L4:
This is the percentage that is open source in this particular component. It is red if it's below 80%
L5: Binary-only package published in SDK. Source may exist but may be non-free
This means the package is published in SDK, but may be non-free and hence not possible to use outside Maemo.
L6: Package published under EULA in nokia-binaries
This means the package is published as binary-only in nokia-binaries, which you can get under EULA at http://tablets-dev.nokia.com/eula
L7: Not published except on device and SSU repositories
This package is only published in SSU repositories and as such you cannot get to it without a device.
In each component area, for each level, there is a percentage and a number. This is percentage of components in this area that is in this level and how many source packages. If you click it, you will see the packages from that component area in that level.
If you click this, you will see information about the package, it's level, where it is openly developed if so, where you can retrieve it, etc.
Key numbers
Along with the openness report, there's a few key numbers, which are completely unweighed regarding lines of code, importance, etc.
Total L1+L3 compared to L1-L4:
This is how many % of the open source packages of Maemo that is actually developed openly on maemo.gitorious.org, garage, etc.
Total L1-L4:
This is how many % source packages of the image which is open source
Total L5-L7
This is how many % source packages of the image which is closed source
Total L1-L4 compared to L1-L6
This is how many % of the published source packages that are open source.
The future of openness reports
The idea is to publish these openness reports quite often, as to keep a understanding on the direction we're going in. I plan to do one every PR release for Fremantle and when Harmattan SDKs starts appearing, doing the same. I plan to shine up the CSS a bit as well as it's not the prettiest currently.
I will very soon start maintaining a open sourcing queue and the hope is to release as many L3-L4 packages as possible to become L1 and L2 packages. And L4 and L2 packages turning into L1 and L3 packages.
Please comment any changes or ideas for future improvements, or questions. If there's components that are openly developed that are not represented, let me know as well. I'm 'Stskeeps' on #maemo and feel free to come and discuss with me there.
The openness reports
For Fremantle PR1.1, you can find the openness report here - this is for a PR1.1 image actually installed on a device.
As per request and for comparison, I've also generated one for Maemo 4.1.2 (Diablo)
It has been difficult finding categorisation for Diablo so a lot of it is in 'Other' as I used the package categorisation from Fremantle in this.
This is supposed to be raw data for further discussion and as such there'll be subsequent analysis on top of this, explaining some of the areas and why things are as they are. Please read through this blog post for further explanation of what the data represents and how it is represented.
This openness report has the purpose of:
- Giving exact information of what is open, what is not, if it's openly developed
- Help prioritise what should be opened and in which order
- Help giving arguments towards why things should be opened
- Help new developers find out where components are developed
- Help making Maemo more open
- To aid open sourcing discussion where we go to the technical heart of a problem, not the ideological one and save all of us precious time that could be used to open source things.
- Get information about what components may not be so interesting as to open source and what is kept closed source in those component areas and help to give an understanding of why it is so.
The purpose is not:
- To be a fight over numbers and percentages of openness
- To be a discussion over open sourcing policies (what Nokia chooses to open source and what not)
Classification of packages
So, to start describing what these openness reports contain. I have chosen to classify source packages into seven levels - this will also explain the headers of the table.
L1: Developed openly, no closed source dependancies
This means that the source package is developed either in garage.maemo.org, maemo.gitorious.org or some other place. This means that you can follow development and contribute patches to it, without having to wait for new releases
L2: Source published in SDK, no closed source dependancies
This means the source package is published in SDK releases. This means that you usually have to wait for a new SDK release to get updates to this package and there's no clear way to submit patches beyond bugtracker
L3: Developed openly, closed source dependancies
This means that the source package is developed either in garage.maemo.org, maemo.gitorious.org or some other place. This means that you can follow development and contribute patches to it, without having to wait for new releases
However, this is usually important for system integrators and porters of Maemo, this package depends on a closed source package to build or run. Which means it is difficult to take the package and use it outside Maemo.
L4: Source published in SDK, closed source dependancies
This means the source package is published in SDK releases. This means that you usually have to wait for a new SDK release to get updates to this package and there's no clear way to submit patches beyond bugtracker
However, this is usually important for system integrators and porters of Maemo, this package depends on a closed source package to build or run. Which means it is difficult to take the package and use it outside Maemo.
Total L1-L4:
This is the percentage that is open source in this particular component. It is red if it's below 80%
L5: Binary-only package published in SDK. Source may exist but may be non-free
This means the package is published in SDK, but may be non-free and hence not possible to use outside Maemo.
L6: Package published under EULA in nokia-binaries
This means the package is published as binary-only in nokia-binaries, which you can get under EULA at http://tablets-dev.nokia.com/eula
L7: Not published except on device and SSU repositories
This package is only published in SSU repositories and as such you cannot get to it without a device.
In each component area, for each level, there is a percentage and a number. This is percentage of components in this area that is in this level and how many source packages. If you click it, you will see the packages from that component area in that level.
If you click this, you will see information about the package, it's level, where it is openly developed if so, where you can retrieve it, etc.
Key numbers
Along with the openness report, there's a few key numbers, which are completely unweighed regarding lines of code, importance, etc.
Total L1+L3 compared to L1-L4:
This is how many % of the open source packages of Maemo that is actually developed openly on maemo.gitorious.org, garage, etc.
Total L1-L4:
This is how many % source packages of the image which is open source
Total L5-L7
This is how many % source packages of the image which is closed source
Total L1-L4 compared to L1-L6
This is how many % of the published source packages that are open source.
The future of openness reports
The idea is to publish these openness reports quite often, as to keep a understanding on the direction we're going in. I plan to do one every PR release for Fremantle and when Harmattan SDKs starts appearing, doing the same. I plan to shine up the CSS a bit as well as it's not the prettiest currently.
I will very soon start maintaining a open sourcing queue and the hope is to release as many L3-L4 packages as possible to become L1 and L2 packages. And L4 and L2 packages turning into L1 and L3 packages.
Please comment any changes or ideas for future improvements, or questions. If there's components that are openly developed that are not represented, let me know as well. I'm 'Stskeeps' on #maemo and feel free to come and discuss with me there.
Subscribe to:
Posts (Atom)