A modest proposal for a direction for maemo.org activities
 

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?

Re: A modest proposal for a direction for maemo.org activities
 

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

Re: A modest proposal for a direction for maemo.org activities
 

Cordia will require GLESv2, so will communityedition, so no-go for N8x0.

Re: A modest proposal for a direction for maemo.org activities
 

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?

Re: A modest proposal for a direction for maemo.org activities
 

I am personally only interested in Qt and MeeGo stuff, for N8x0 I would probably suggest a MeeGo IVI or something based codebase.

Re: A modest proposal for a direction for maemo.org activities
 

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.

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.

I'm not sure what you're saying, maemo.org should ditch Maemo?!

Re: A modest proposal for a direction for maemo.org activities
 

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.

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.)

Re: A modest proposal for a direction for maemo.org activities
 

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.

Re: A modest proposal for a direction for maemo.org activities
 

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

Re: A modest proposal for a direction for maemo.org activities
 

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...
good luck!

Re: A modest proposal for a direction for maemo.org activities
 

meego adaptation for N900 is a great idea ,though maemo wouldnt be lagging behind as it is core of N900 and many people are concerned about it.i too believe that we have not got stuck in the past ,we are going ahead day by day ( nitdroid port ,cssu ,portrait mode adaptation etc ) .And we have to be very certain about everything we have about meego before N900 adapts to meego cuz maemo is already very set and stable here .

Re: A modest proposal for a direction for maemo.org activities
 

Why trash Hildon? The UI concepts are still miles ahead of anything else we see everywhere else.

At this point in time, the community should have one, single, focused effort to make the "old" system "new" again. That means getting MeeGo CE to be a good core OS to start work upon (moving from RPM to DEB, polishing the open Hildon Desktop code and moving to GTK3, making it easier to make new mainline+patches kernels work on the N900, writing open versions of closed source applications to complete the experience, using GNU Coreutils instead of busybox, making a theme as professional and polished as Alpha, etc.)

Re: A modest proposal for a direction for maemo.org activities
 

Since there is no open hardware standard in this space (just yet?), and that hardware seem to be our common denominator for being here in the first place, then I have to ask the obvious question: what is our likely target platform in the future?

Re: A modest proposal for a direction for maemo.org activities
 

In short term that may be cordiatab.

Or any tablet/phone that becomes open enough.

Re: A modest proposal for a direction for maemo.org activities
 

I would suggest to make the GTK+3 switch already. Kernel stuff is taken care of already. MeeGo uses coreutils.

Re: A modest proposal for a direction for maemo.org activities
 

I've just read the Meego 1.1 Compliance Specification.
Chapter 1.4.1:

CPU architectures are approved by the MeeGo Technical Steering Group and may change over time. As
of this version of the specification, supported architectures are:

• Intel® AtomTM (Core2TM/Atom instruction set (SSSE3)), represented as RPM architecture i586
• ARM v7‐A (ARM EABI, VFPv3 support, softfp float ABI), represented as RPM architecture armv7l

This basically means we can not use their infrastructure for building of packages, we have to rebuild everything by ourselves.

I've failed to find memory requirements.
OpenGL is stated as a must.

Re: A modest proposal for a direction for maemo.org activities
 

The fact is that the real situation is that Meego in the N900 is useless (even behind Nitdroid). And there are almost no applications for Meego that can be run in the N900.

On the other side, Maemo is working fine. CSSU brings a lot of improvements to the UX (Hildon is better than never) and basic packages, Cordia project can share also some improvements to the UX, Kernel power is progressing nicely and there are thousands of applications for Maemo ready to use. You can even use closed source applications from OVI or WebOS games.

So there is no point in moving from Maemo 5 to Meego from a N900 user's perspective. Maybe in the future, but at this pace, most of N900 devices will be broken when Meego could be ready to be used.

I'd simply prefer to base efforts on what we have working right now.

Re: A modest proposal for a direction for maemo.org activities
 

Unless we merge with debian armel port there will be no future
for all this maemo related projects. The base system should be plain debian.
Debian also includes parts of the hildon desktop:

dates-hildon - a calendar optimised for embedded devices - Hildon flavour
dates - a calendar optimised for embedded devices
hildon-desktop-dbg - Debug symbols for Hildon Desktop
hildon-desktop-dev - Development files for the Hildon Desktop
hildon-desktop - Desktop environment for embedded devices
libhildondesktop-dev - Hildon Desktop library development files
libhildondesktop0-doc - Documentation for Hildon Desktop library
libhildondesktop0 - Hildon Desktop shared library
libhildonwm-dev - Hildon window manager development files
libhildonwm0 - Hildon window manager shared library
hildon-icons - Default Hildon icon theme for maemo's SDK
hildon-theme-layout-4 - A layout file for making themes for the maemo 4 platform
hildon-theme-plankton - Plankton Hildon theme
hildon-theme-tools - Tools for developing Hildon themes
hildon-thumbnail - Hildon thumbnail library related programs
libhildonthumbnail-dev - Hildon thumbnail library - development files
libhildonthumbnail0-dbg - Hildon thumbnail library - debug symbols
libhildonthumbnail0 - Hildon thumbnail library - runtime files
libhildon-1-0-dbg - Hildon libraries - detached debug symbols
libhildon-1-0 - Hildon libraries - shared libraries
libhildon-1-dev - Hildon libraries - development files
libhildon-1-doc - Hildon libraries - API documentation
libhildonhelp-dev - Hildon Help library -- development files
libhildonhelp0-dbg - Hildon Help library -- debug symbols
libhildonhelp0 - Hildon Help library -- runtime library
hildon-update-category-database - Hildon desktop MIME type hander - mapping tool
libhildonmime-dev - Hildon desktop MIME type hander - development files
libhildonmime0-dbg - Hildon desktop MIME type hander - debugging symbols
libhildonmime0 - Hildon desktop MIME type hander - runtime library
osso-af-settings - pkg-config based registry for maemo directories
tasks-hildon - a simple to do manager - Hildon flavour
tasks - a simple to do manager

The hildon closed source bits have to be substituted with alternative
open source packages.
This would allow the volunteers of the maemo community to manage only
the missing hildon packages (that could be pushed upstream later)), some
adaptations on the debian base system for the N900, and the community developed kernel (that already exists).

Re: A modest proposal for a direction for maemo.org activities
 

I agree with lma (as most of the times, I admit). Sorry misterc - i preffer "chippng about technical details" than useless trash-talk about "ideals" without baclground of technical knowledge, to even know what is do-able. People like lma are - unlike most of us, including me - coding/doing all related stuff for real, instead of just chit-chatting. They answer with meritocratic-based arguments, real things that we have now, and what is do-able (or at least what we need to get, if we want it to be doable). Without such technical details, we would never get out from twitting hapilly to doing stuff.

So, I think attacking them (people, not technical details... But those also ;) ) - even not directly - is *very*bad idea, not to mention that it's just plain rude.

---

As for idea themselves - I second opinion that using great (and proved most effective) Hildon UI on modern Meego OS is way to go. Sorry folks, Meego community edition UI is jut a template, and basing any real coding/porting on it is PITA. I'm not attacking concept of that UI - it's just mean as template/tech demo, not Your everyday UI.

Re: A modest proposal for a direction for maemo.org activities
 

I wouldn't call it useless but yeah the UX layer needs work and luckily there's several working (YMMV) alternatives already available.

True. But are you saying new development is bad? The aim is to be future proof and the effort is not just about the n900. I know MeeGo on N900 isn't end user ready but that is where the development effort should IMO go. Feel free to disagree :)

I'd rather base on something that is actually being developed, maintained, is more open and has a future also outside of the n900 sandbox.

Edit: For the N900 end users there's the CSSU effort going on that already takes the Maemo OS forward.

Re: A modest proposal for a direction for maemo.org activities
 

talking endlessly (as is seen on many "direction threads", even without "trolls") about technical features isn't going to get you anywhere neither.
talking about chit-chatting ¦-)

except for what is getting done, quietly, by ppl like pali, tymoph and many (?) more.
this is the de facto technocratic meritocracy which by nature is missing a unified direction other then the one given by technological constraints (such as device or architecture).
which doesn't in any way reduce the value of their efforts.

simply in a time of changes like now (for NOKIA's maemo's products) it means ppl are working on different solutions for an aspect.
is usually very nice (provides more choice) but when resources are scarce it can be an issue.

you can of course call me troll because i bring up a non-technical issue :rolleyes:

Re: A modest proposal for a direction for maemo.org activities
 

i really hate the idea of this thread ,why one wont stay with maemo as it is still in WIP stage ? that means no body is sticking in the past at all ,whoever is in love with meego ,wait for N9/n950 and grade it as if it is good for u or not or work for maemo and for its applications .We probably will have a lot of time for sucha developmental ideology unless nokia does not release an other OS .So be good with maemo cuz thats all we have .You probably dont want to open an other war for immature meego when there is an incomplete maemo.Work for its completion first .you will have your time LATER.

Re: A modest proposal for a direction for maemo.org activities
 

Having though about this a few minutes more I think that most of the things that people are after is already happening in a form or another. One can always argue about the little things but that's beside the point.

1. CSSU - For people who want to see Maemo 5 getting fixes, etc
2. MeeGo N9x0 Community Edition - For people who want to move on
3. Cordia - For people between the first two.

And on top of those are the application developers, hackers, users, etc.

I don't see a point in deciding one direction for the whole community (which by the definition in the intro page is a developer community [1]). Open source and coding in one's free time is almost always about scratching your own itch so I'd say just contribute/support the effort that suites your needs.

[1] http://maemo.org/intro/

Re: A modest proposal for a direction for maemo.org activities
 

Cool, what about N800/N810?

Re: A modest proposal for a direction for maemo.org activities
 

I don't see lot happening around n8x0. from where I'm sitting those look obsolete. would be happy to be proven wrong though.

edit: meaning obsolete in context of new development while they are otherwise usable devices

Re: A modest proposal for a direction for maemo.org activities
 

You are right. Let us hope that we don't end up in a situation like the Freerunner situation, ie, thousands of distros but each not complete and working for proper usage.

Three paths are sane, especially when two share hardware adaptation and base system.

Let the results be what will eventually show what was the right path.

I cant help but feel that we need to think way beyond the current user experiences though, ie, not Cordia, not CE, not CSSU.

Try to see this video: http://www.youtube.com/watch?v=6Cf7IL_eZ38 (not rickrolling)


Your thoughts on such an approach for maemo.org?

Re: A modest proposal for a direction for maemo.org activities
 

Well the original vendor thinks that way as well. One of the basic ideas of the OSS is to be able to maintain your software when the vendor is not willing any more.

By excluding the N810, number of people working on a community "maemo" (since it needs to be redefined and renamed) will be reduced.

Re: A modest proposal for a direction for maemo.org activities
 

Let us all install chips inside our heads. :D
Seriously, people do things in life other than clicking, swiping, dragging, etc.

Re: A modest proposal for a direction for maemo.org activities
 

but this all runs on MeeGo with NFC / Near Field Communication, right?
;)

Re: A modest proposal for a direction for maemo.org activities
 

oh. sorry didn't mean like that. those are maemo devices no matter what. just pointed out that there's already work going into the things that most people here are after. but as said there's very little work going on for the older devices. my guess is that there just isn't enough interested people around to support those.

maemo.org has a lot of useful info about those devices and that's the level of support I currently see maemo.org offers for those devices.

of course anyone is free to start fixing things in the older sw, etc. it wouldn't be open source if we'd limit what people can work on. there might be some limitations but that's another thread if those can be worked around or not.

Re: A modest proposal for a direction for maemo.org activities
 

Interesting, there are armv8 packages in OBS as well.

Re: A modest proposal for a direction for maemo.org activities
 

that's the armv7hl (hard floating point) scheduler. a bit misleading name for it but iirc it was easier to setup by naming it armv8 because of the existing amv7l scheduler.

Re: A modest proposal for a direction for maemo.org activities
 

So basically, you can have non-compliant device support as well?

Re: A modest proposal for a direction for maemo.org activities
 

Yes, Stskeeps stated it took a week to rebuild MeeGo for armv6

Re: A modest proposal for a direction for maemo.org activities
 

It's compliant, the ARM arch switched to armv7hl in MeeGo 1.2.

Re: A modest proposal for a direction for maemo.org activities
 

Well said, I couldn't agree more! :-)

Re: A modest proposal for a direction for maemo.org activities
 

They have a CSSU, such as it is, and several independent projects (Diablo Turbo, Advanced System UI, Telescope etc) that improve things significantly. It'd be nice if we could pull everything together and make it easier for users to install though.

MeeGo on OMAP2 seems like a lost cause to me, but I wouldn't be upset if someone proved me wrong.

Re: A modest proposal for a direction for maemo.org activities
 

Very well put tekki, agree that we should concentrate our efforts.

Agree also with timoph that community "members" should be allowed to experiment and build whatever they want....

But we are speaking about overall direction of "community" itself here. Our council members, and we in general we should set a direction to focus our activities. This is important as
1. the N900 is nearing EOL
2. the community is decreasing in strength (with titans like qole etc. also spending time over N950/ meego, N900 related efforts have only part of their great brains)
3. Focusing on select critical areas per year helps focus our limited resources into doing something tangible (E.g. CSSU which has been remarkable)

As above I recommend three focus areas
1. CSSU, In parallel gather whatever code we can from Nokia.
2. Kernel/ Upstream improvements
3. Porting N9 compatible Qt applications to maemo. If Alien Dalvik is likely in N9, we should jump to snatch it.

The rest is plain applications building/ testing.

==================

Re: A modest proposal for a direction for maemo.org activities
 

want to make a poll?

Re: A modest proposal for a direction for maemo.org activities
 

Yes, the pole makes sense.
Actually more than one:

• device prevalence among user/developers, used to determine how many users have each device, and how many developers are willing to work on particular device.
• possible future developments, depending on above situation.

I own N810, and are naturally interested as both user and developer (provided that there are enough developers willing to work on it as well).

While meego is certainly possible path for that device, there are other possibilities, such as enlightenment (openmoko). If we want to have a choice we have to make sure we have a hardware platform that is open enough.