Reply
Thread Tools
Posts: 60 | Thanked: 198 times | Joined on Aug 2011 @ Radical Realistic Open Source with JFDI instead of Bikeshedding
#1
I have seen quite a lot of discussion about direction of maemo.org and I thought I would pitch in.

My proposal is simple:

* Make a task force to submit and maintain OBS support for Diablo and Fremantle. That would then be contributed to apps.formeego.org, providing a direction for Extras and autobuilder. If Harmattan support already exists, D and F support cant be difficult
* Make a task force for maintaining a modern kernel for N8x0 devices. 770 is a lost cause due to binary wifi driver
** This enables all sorts of opportunities for these devices. If asked, I am convinced builds for let's say MeeGo of closed source binaries can happen.
* Stop caring about a codebase (Maemo) that is ancient, unmaintained and too heavy to upkeep legally, hosting wise, etc and ridden with nonredistributable closed source. This includes Hildon stack which is really difficult to recreate (see failure of Mer) and even those who got 50k EUR from Nokia to do something about Hildon does not provide a path for applications to rebuild on, making it useless for maemo.org.
* Propose people to base efforts for N900 on the MeeGo hardware adaptation. UI can be the CommunityEdition one or one made by maemo.org community. The hw adaptation team is maintaining the device near parts and not going away. If we dont call our product MeeGo we can do whatever we want with it. We can even be seperate from the MeeGo project if we so desire. But the code base is fine and well functioning for our devices, and open source.

The maemo.org spirit is to do exciting things with our devices. Let us innovate, not get stuck in the past.

Your thoughts on my tangible proposal?

Last edited by tekki; 2011-08-12 at 07:09.
 

The Following 22 Users Say Thank You to tekki For This Useful Post:
Posts: 673 | Thanked: 856 times | Joined on Mar 2006
#2
Originally Posted by tekki View Post
I have seen quite a lot of discussion about direction of maemo.org and I thought I would pitch in.

My proposal is simple:

* Make a task force to submit and maintain OBS support for Diablo and Fremantle. That would then be contributed to apps.formeego.org, providing a direction for Extras and autobuilder. If Harmattan support already exists, D and F support cant be difficult
* Make a task force for maintaining a modern kernel for N8x0 devices. 770 is a lost cause due to binary wifi driver
** This enables all sorts of opportunities for these devices. If asked, I am convinced builds for let's say MeeGo of closed source binaries can happen.
* Stop caring about a codebase (Maemo) that is ancient, unmaintained and too heavy to upkeep legally, hosting wise, etc and ridden with nonredistributable closed source. This includes Hildon stack which is really difficult to recreate (see failure of Mer) and even those who got 50k EUR from Nokia to do something about Hildon does not provide a path for applications to rebuild on, making it useless for maemo.org.
* Propose people to base efforts for N900 on the MeeGo hardware adaptation. UI can be the CommunityEdition one or one made by maemo.org community. The hw adaptation team is maintaining the device near parts and not going away. If we dont call our product MeeGo we can do whatever we want with it. We can even be seperate from the MeeGo project if we so desire. But the code base is fine and well functioning for our devices, and open source.

The maemo.org spirit is to do exciting things with our devices. Let us innovate, not get stuck in the past.

Your thoughts on my tangible proposal?
It seems that http://cordiahd.org/ shares the basic principles you've stated above, except they don't mention N810/Diablo. I think we should try to somehow coordinate with them and ask for N800/N810 inclusion.

If system base will work equally good. The problem remains with GUI (Nokia has claimed that freemantle was just ot heavy on resources), and possible web browser, since N810 has only 128M of RAM.

Maybe we can think about creating a really lightweighted GUI, on order to save as much memory for applications as possible.

See: http://cordiahd.org/os/about

Last edited by momcilo; 2011-08-12 at 07:24.
 

The Following User Says Thank You to momcilo For This Useful Post:
Posts: 60 | Thanked: 198 times | Joined on Aug 2011 @ Radical Realistic Open Source with JFDI instead of Bikeshedding
#3
Originally Posted by momcilo View Post
It seems that http://cordiahd.org/ shares the basic principles you've stated above, except they don't mention N810/Diablo. I think we should try to somehow coordinate with them and ask for N800/N810 inclusion.

If system base will work equally good. The problem remains with GUI (Nokia has claimed that freemantle was just ot heavy on resources), and possible web browser, since N810 has only 128M of RAM.

Maybe we can think about creating a really lightweighted GUI, on order to save as much memory for applications as possible.

See: http://cordiahd.org/os/about
Cordia will require GLESv2, so will communityedition, so no-go for N8x0.
 

The Following 2 Users Say Thank You to tekki For This Useful Post:
Posts: 673 | Thanked: 856 times | Joined on Mar 2006
#4
Originally Posted by tekki View Post
Cordia will require GLESv2, so will communityedition, so no-go for N8x0.
What about running slim-down 2D interface on top of the same meego base?

The question is how much the applications are dependant on GLESv2.

BTW: I am willing in joining the effort (C/C++ + some experience with embedded platforms development (arm7, arm9) + usual linux stuff). Are you willing on joining as well?

Last edited by momcilo; 2011-08-12 at 07:33.
 

The Following 2 Users Say Thank You to momcilo For This Useful Post:
Posts: 60 | Thanked: 198 times | Joined on Aug 2011 @ Radical Realistic Open Source with JFDI instead of Bikeshedding
#5
Originally Posted by momcilo View Post
What about running slim-down 2D interface on top of the same meego base?

The question is how much the applications are dependant on GLESv2.

BTW: I am willing in joining the effort (C/C++ + some experience with embedded platforms development (arm7, arm9) + usual linux stuff). Are you willing on joining as well?
I am personally only interested in Qt and MeeGo stuff, for N8x0 I would probably suggest a MeeGo IVI or something based codebase.
 
Posts: 2,802 | Thanked: 4,491 times | Joined on Nov 2007
#6
Originally Posted by tekki View Post
* Make a task force to submit and maintain OBS support for Diablo and Fremantle. That would then be contributed to apps.formeego.org, providing a direction for Extras and autobuilder. If Harmattan support already exists, D and F support cant be difficult
Fremantle is already being worked on. Diablo support isn't at the moment (but see this).

However I'm not convinced that OBS is the way to go, as it will certainly need a lot of work, possibly even on the package side, and we don't have enough volunteers to do it. The current autobuilder at least is a known quantity and works so we just need to transplant it to a new box somewhere and look after it from time to time.

* Make a task force for maintaining a modern kernel for N8x0 devices.
Lots of other projects do that. However a modern kernel is useless for running Maemo due to closed userland bits that rely on Nokia's interfaces.

* Stop caring about a codebase (Maemo) that is ancient, unmaintained and too heavy to upkeep legally, hosting wise, etc and ridden with nonredistributable closed source. This includes Hildon stack which is really difficult to recreate (see failure of Mer) and even those who got 50k EUR from Nokia to do something about Hildon does not provide a path for applications to rebuild on, making it useless for maemo.org.
I'm not sure what you're saying, maemo.org should ditch Maemo?!
 

The Following 2 Users Say Thank You to lma For This Useful Post:
Posts: 2,802 | Thanked: 4,491 times | Joined on Nov 2007
#7
Originally Posted by tekki View Post
I am personally only interested in Qt and MeeGo stuff
Please don't take this the wrong way, but for those I think your time and effort would be much more effective on the N9* CE project than anything maemo.org-related.

for N8x0 I would probably suggest a MeeGo IVI or something based codebase.
The N8x0s are never going to be MeeGo compliant for a variety of reasons (CPU architecture, GLES, amount of RAM available). IMHO if you are giving up MeeGo compatibility then it's the wrong upstream to base your work on as it's too encumbered by politically/commercially motivated policies that make no sense outside that context ("Borrowing" bits of code/packaging here and there is a different thing of course.)
 

The Following User Says Thank You to lma For This Useful Post:
Posts: 60 | Thanked: 198 times | Joined on Aug 2011 @ Radical Realistic Open Source with JFDI instead of Bikeshedding
#8
Originally Posted by lma View Post
I'm not sure what you're saying, maemo.org should ditch Maemo?!
Yes, that is exactly what I am saying. maemo.org has never been governing the Maemo OS and the OS is too encumbered with closed source that it is ungovernable by us and without significant rewrites not even possible to distribute images of

Give me some good points why we should at all care about the closed OS and how the 3-6-12-18 month timeline looks like for the effort. My opinion is that any Maemo based effort is not sustainable or worth it in the big picture. I would love to be convinced otherwise. Even SHR has a better outlook than Maemo.

Open platform is the way to go, IMHO. Best thing people can do is to gather together and build our own user experience.
 
Posts: 60 | Thanked: 198 times | Joined on Aug 2011 @ Radical Realistic Open Source with JFDI instead of Bikeshedding
#9
Originally Posted by lma View Post
The N8x0s are never going to be MeeGo compliant for a variety of reasons (CPU architecture, GLES, amount of RAM available). IMHO if you are giving up MeeGo compatibility then it's the wrong upstream to base your work on as it's too encumbered by politically/commercially motivated policies that make no sense outside that context ("Borrowing" bits of code/packaging here and there is a different thing of course.)
Reusing codebase is fine. We can take Debian if you care or SHR, just remember to keep a mobile mindset. Suggested MeeGo (as in code, not trademark) as it could span the spectrum of maemo.org.

Even cordia is meego based
 
misterc's Avatar
Posts: 1,625 | Thanked: 998 times | Joined on Aug 2010
#10
Originally Posted by tekki View Post
I have seen quite a lot of discussion about direction of maemo.org and I thought I would pitch in.[...]
tekki,

i'm afraid your proposal lacks one fundamental prerequisite...
a governing body.
you can see it for yourself with this thread you started with a clear proposal directed towards action (task forces...).
the outcome is some chipping on technical details, which may be interesting in themselves but are not addressing the issue at hand, the lack of direction, perspective, vision, call it whatever you want for maemo.org.

it has been repeated ad nauseam that the council is not a governing body.
before you can hope to get anywhere, you need to get a consensus as to where the community has to go.

i think NOKIA, the former governing body of sort for maemo has made a choice (moving on even though that doesn't mean they will not continue to support maemo.org for the sake of supporting customers who bought MIDs and are still using them). (having users begging for help with some trivial dpkg issues is not sending the right message here, btw...)

one option is to follow NOKIA and move on to the next thing which is probably going to accelerate maemo.org's demise.

another option would be look around.
debian...
found a paper that discusses debian's governance and its evolution over time...
Originally Posted by Scientific study about Debian Project governance and social organization
[...]
even in a community of open source programmers that espouses the value of technical contributions above all else, members’ conceptions of leadership change over time to increasingly value organization building contributions.

Democratic mechanisms enable the community’s governance system to adapt as members learn how to interpret leadership and authority in a community context. This suggests an evolving and context-dependent notion of meritocracy and that democratic mechanisms serve an important adaptive function. [...]

Phase II: Designing Governance (1997 – 1999).

The community drafted a Constitution to formalize leadership roles, rights and responsibilities. It was ratified using itself, as a test case.
[...]
good luck!
 
Reply

Thread Tools

 
Forum Jump


All times are GMT. The time now is 06:28.