Does the compiler settings difference mean even if the community back ports Maemo 5 to OMAP2 that Maemo 5/OMAP2 applications would need their own repository?

So we would end up with an application being compiled (potentially) for:
Maemo 5/OMAP3 (OS2009?)
Maemo 5/OMAP2 (OS2009HE?)
Maemo 4 (OS2008)
Maemo 3 (OS2007)
Maemo 2 (OS2006)

Frank

Actually, we will be supporting this community project. We don't just send an invite and then disappear.

We have various things that are being worked on right now to help the community such as defining license terms in a way that the community can build and use variants. We also made much more components open source than ever previously in order to support this activity. There might be still components that the project need in order to succeed and we will try to make them available too. What we can't do within the next months is put lots of people working on the kernel and lower layers to make the backport. That is too complex to be feasible without delaying the work on the lead device. But even that we don't want to influence the ongoing work for the lead device of Maemo 5, we did get help from the core development team to make this pre-alpha SDK happen. In this case, it was a fix needed to run the Maemo 4 UI on top of Maemo 5 software stack. Small but valuable things.

Short version: On-board, data-only HS*PA on the new Maemo/'NIT'.

Long version: This means, as sneak-peaked on the Maemo summit september 2008, that the device running Maemo 5 (as codename its usually called 'N900') might have cellular data connectivity on-board, without using a protocol to tether such as BlueTooth and without using an external device such as a phone.

We will be supporting on-board HSPA i.e. both HSDPA and HSUPA.

So, basically, reincarnated WiMAX and SIP (or something similar) will still be required to call others. Now, that you mentioned it, I remember a discussion about that back in Sept.

So there are a number of reasons for the break - greater processing capabilities of the OMAP3 platform (including support for hw acceleration of OpenGL, though this is something that might be possible for our OMAP2s with either some reverse engineering or some words in the right places, I am ever hopeful). This means that the new UI may be too much for our OMAP2 devices (though we should have a damn good try when it's finally released, closer to the device release date).

Next issue with supporting the OMAP2 platform is the addition of the hi def camera and always-connected HSPA. I imagine this will fundamentally change the applications that are provided and the way the device is used. I can understand Nokia not wanting to release a version for the OMAP2 devices which is hobbled and whose apps don't work as designed, etc.

We can still try to get a decent version working on the OMAP2, it won't be perfect (which is why Nokia aren't wanting to do it officially), but we should be able to get something pretty decent - either "Diablo on steroids" (current ui), or if we manage to make/steal a driver perhaps even the new UI. Many of the new apps probably won't work very well (crap camera, not always-on connectivity), but at the very least we should benefit from the back-end changes (library updates, messaging, etc.)

I should add here that Nokia are keen to support our efforts to do this, by the licensing changes that Peter mentioned, and by opening up components that we might need to get this working. They are behind this, but not for official releases.

So, let's get cracking and see if we can get a Fremantle (with Diablo-ui) running on the OMAP2 tablets and in the fullness of time, we can give the OpenGL version a try too!

oooooh yeah!

firstly, a big thank you to the guys within Nokia who have actually delivered on part one

As for backports or alternatives, I am with you all the way on that lardman, lets see where we can get to. We have seen marked improvements in many technical areas this year and the DSP ogl stuff sounds like an interesting bit of lateral thinking

one thing, even with always on hspa we cannot assume always connected
We wouldn't want our users to be up the creek without a paddle with no connection for normal apps. This is doubly so if we are considering a port to other non devices with lesser capabilities.

bring forth the hardware!!

well, i bought my tablet, because they promised they would make at least 2 proper OS releases.

btw - nokia do not sell hardware, they sell products.
as for services - who will buy service for abandoned product?

i hoped, that with n800/n810 still supported, they could provide lo-price product along with "powerfull" and probably pricier "n900".

...And do you now believe that they've lived up to that promise?

Something tells me the iPhone Linux project could get us a decent reverse-engineered PowerVR driver down the line, so I too am holding out hope. Major shame to see the N810 WE being forgotten, given that it released with Diablo so has seen none of the big upgrades. It's beyond me why Diablo would implement an on-device flashing utility if it's going to be unused. Good luck proving me wrong and surprising us all with a Fremantle backport that supports the N8*0!

Even if the UI stays the same (or gets simpler / lighter), I would be pleased with some of the new technologies being fit in like PulseAudio and a new version of Telepathy. (Speaking of which, will Fremantle finally package telepathy-butterfly? It has always been beyond my understanding why nobody has done so).