Time for an open maemo fork?
 

Maemo is very nice.
But what about the future if Nokia goes WP7?

Can the community buy the maemo platform from Nokia?

Or is it time to build an open version of maemo that saves all open source efforts that have been done by the community?

Re: Time for an open maemo fork?
 

Oh dear do you never look on this forum to see what is going on ????.

http://talk.maemo.org/showthread.php?t=67905&page=177

Re: Time for an open maemo fork?
 

Caramel Popcorn ( Troll Edition ) time! w00t.

Re: Time for an open maemo fork?
 

Also look up Cordia. It's a project to mash up hildon with meego...

Searching is a virtue

Re: Time for an open maemo fork?
 

Yeah! It's about time Maemo went open-source! :)

Re: Time for an open maemo fork?
 

No, it's not for sale.

Like Mer?

Re: Time for an open maemo fork?
 

It wouldn't help you. MeeGo doesn't exist.

Nokia and open source – a trial by fire is a great summary of the situation (other than the author's own "Plan B" in the last few sentences which is somewhat insane).

Andrew Waafa and others who worked with MeeGo on the open-source end reveal things like "Wafaa summarises the problems that developers experienced with Meego as, 'closed-ness, weirdo licensing around trademark and name, and a closed decision making process between Intel and Nokia. Not even partners could get access to decision making. In consequence they did dumb stuff like re-writing the whole networking stack, duplicating as they went. So instead of re-using NetworkManager and improving it, and getting to market fast – they re-wrote, got something that still doesn't work well, failed to push Linux forward, and failed. Repeat that for every technology pick and you get the idea.' "
"ConMan, the replacement for NetworkManager, still lacks many of the basics that users take for granted, such as proper encryption support, Adhoc networking and a usable VPN interface.
"The cynical interpretation among developers was that there was an attitude of: 'Nokia and Intel will always be number one so we have plenty of time – lets get the non-user visible stuff 'perfect'', where the definition of 'perfect' changes every six months.'"

This is what you guys were pinning your hopes on and crying that Elop should just keep plugging away at... "To further confuse the issues, the MeeGo code was a strange amalgamation of Debian, Fedora and openSUSE sources with a melange of unrelated dependencies. 'Because it was such a cluster, with a confusion of old and new libraries, trying to package it was a dependency nightmare,' says Wafaa. 'and some aspects just wouldn't work.'" The article goes on to describe infighting between the Symbian, Maemo, MeeGo, Moblin and Qt camps and how that led to Maemo/MeeGo pretty much starting over every six months with a politically-motivated rewrite. The article makes crystal clear why Elop has zero confidence in Nokia being capable of developing an OS internally anymore. It's also pretty apparent the code is a mess and a design by ever-changing committee. You'd probably better off starting over around another ARM-based Linux port.

Re: Time for an open maemo fork?
 

You think that description only fits Nokia/MeeGo? That's pretty much the default state of any project with unclear ownership. LibreOffice, anyone? And "weirdo licensing around trademark and name" - IceWeasel, right? I am sure even Microsoft had some internal conflicts before ending up dumping Windows Mobile, Kin, and instead concentrating on their copy-and-paste free OS based on an media player firmware. (That's a New And Better type of Free software, invented by iPplejobs. )

Yet, MeeGo does exist. What it is usable for today, and where it will be in half a year, are quite different problems.

Re: Time for an open maemo fork?
 

Actually, that's pulling meaning of from that article that just isn't there. Yes MeeGo wasn't developed well enough and Nokia was internally conflicted; no MeeGo doesn't "not exist", and I'm too lazy to make a long post for once so I'll leave it at that.

As for "fork" - a fork implies splitting off of something. There's no actively developed project to "fork". Maemo development has basically stopped, ignoring the N950 which is technically Maemo 6 rebranded to MeeGo.

In the meantime, the CSSU is already psuhing small open source replacements for closed source stuff out into the system. At this point, there's really no need for a fork I'd say. Every open source replacement for a closed source blob can be pushed into the CSSU, but either way, someone has to write them first, and once they do, the CSSU is effectively a "fork", or rather an addition, to the currently available Maemo 5.

Re: Time for an open maemo fork?
 

Exactly how far are we from getting a normal linux with all the necessary functionalities done right and working on the N900?

Re: Time for an open maemo fork?
 

What's normal? Normal for what use-case? It has a terminal, and can run whatever command-line tool you stick into it that's compiled for armel Debian- that's "normal" for some use-cases. Normal as in works like your average desktop distro, with GNOME/KDE and their respective suites of software pre-included? Specify, in other words.

Re: Time for an open maemo fork?
 

What I and others have been asking of those who continue to say that MeeGo was "almost done" or "two months away" and (insert conspiracy here) is... show us MeeGo. Then we gets lots of huffing and puffing. My original statement was a bit of hyperbole and should probably be "MeeGo does not exist in an end-user useable state".

The question is if one wanted a fully open source community ARM-based OS whether it would be quicker/worth it to "fork" MeeGo given its state and its legal strings or develop on top of an already-existing Linux ARM port. Wafaa's description seems to paint a picture that trying to work with MeeGo right now is more trouble than it's worth. I know he's given up on Smeegol.

Re: Time for an open maemo fork?
 

Somthing without all the errors and jerryrigging Nokia did with Maemo

Re: Time for an open maemo fork?
 

I agree it is about time, we need a truly open Mobile RISC Linux distro who fate isn't determined by some big corporation who could give two shits about opensource. The Linux Action show agrees http://www.youtube.com/watch?v=-XMICchtBdA
Anyways I have a few names what about thinux or noonix. Would anyone be willing to chat with me about it?
Edit: My name is nooblet.1 on skype

Re: Time for an open maemo fork?
 

Tinux is also a good name or noBLIX (Non Nokia mobile linux)

Re: Time for an open maemo fork?
 

Untill the N900 becomes COMPLETELY open source and that means ALL components then we will never have Maemo or MeeGo in a complete stage as it will only ever be a makeshift based on what people can do with what is already open source.

This is why the Maemo and MeeGo projects are far far from complete and will never reach completion in any way or form untill Nokia open source everything to us.

Sad but true so we may well have to go on to the next Nokia so called flagship.

Re: Time for an open maemo fork?
 

I've said what I think about that article in the thread on this forum related to it (horrible piece of journalism with a lot of misconceptions and very few facts that were surrounded in manure and bias). Wafaa stopped working on it because he was simply re-packaging the Netbook UX on top of OpenSUSE and there wasn't any contributions back to MeeGo or additional features. And MeeGo netbook didn't really have any additional feature work being done for it for 1.2 (focusing on Core and Handset), so he stopped his work.

Re: Time for an open maemo fork?
 

I am really happy to see alcalde back on FUD duty again.

I said DUTY :DDDDD

Re: Time for an open maemo fork?
 

So the question comes back around again, then: When will N8x0 and N900 users see a workable, finished, released MeeGo product that can be used day-to-day? That is--not in alpha, not in beta but maybe maaaaybe at least in RC?

Re: Time for an open maemo fork?
 

N8x0 I can't comment on. It's still on my list to do something about it. I hate having devices without big use in my house. I have a hunch QML apps might work slightly better than MTF.

N900: Only thing expected is the "MeeGo DE" stuff, see the thread for it. That's something at least I would use on day-to-day basis. Even if it has only few, working features at first. And it'd be on a open platform and open applications that anyone can customize. And improve upon too. Perhaps you would be good with this too?

I can't recommend anyone to do a Maemo fork, we all know how that went last time anyone was insane enough to do that ;)

Re: Time for an open maemo fork?
 

Yeah--I also hate being told we would have backports and community SSU from Fremantle as answers to FIXED IN FREMANTLE and WONTFIXes, too. So much for unsubstantiated promises and claims of open-source in Maemo. So much for the MeeGo promises too, I suppose.

That doesn't seem very day-to-day for the typical user coming from Maemo/Android/Blackberry/iSplat (i*)/etc. Isn't it still only just kind of, sort of, pre-beta still? It doesn't seem quite settled and baked yet, or did I miss some major milestone?

Agreed. Nokia's blue-headed step-child, the one they never showed loved.

Re: Time for an open maemo fork?
 

I asked for specifics. I'm not sure what jerryrigging you're talking about. I am not a mind reader and I don't know the nuances of your psychological workings and experiences with the N900 to know which hacks/tweaks/modifications you're considering jerry-rigging - and which of those you actually consider bad. As for the errors, yes, **** happens, some of which Nokia won't fix and some of which they would be able to do something about but don't because either their decision making process sucks, or corporate patent bs regarding software ownership sucks.

But it still says nothing about what you mean about full Linux. I have bugs in Debian. Granted it's in Virtual Box, but it should effect the basics such as whether or not vi works correctly. Does that mean Debian is suddenly not a full Linux system? If I strip the desktop environment, and just set up the linux kernel, with some minimal drivers and the X window system running, does that make it less full?

Re: Time for an open maemo fork?
 

The Open Maemo Ballpoint Pork.

http://img.photobucket.com/albums/v4...nk-cutlery.jpg

But TBH it's a good effort by the community with the CSSU, but I thought the idea was to do a better job than Nokia did.
But having said that, that's not possible if all the WONTFIXes are in the closed components.

Rather than making it all open Nokia could enlist a few trusted community members to carry on where they left off with access rights to the closed components. This would give us [the community] what we want, regular updates with all the WONTFIXes fixed while still protecting Nokia's intellectual property.:confused:

Re: Time for an open maemo fork?
 

Of course, but go read up a bit about what the intention is with "DE". It's quite simple. Establish a few basic use cases that "just works", have it be usable by a 'developer' or 'hacker' on a daily basis. And at same time, make it extensible.

Even hackers are turned off if basic functionality doesn't work (power management - I don't want a really hot handset near my crotch, buggy UI). As an example, I wanted to throw out my Neo Freerunner out the window from 9th floor after an hour of use and I'm not usually picky about my UI experiences, having used command line UNIX since I was 8.

If we have that basis in short term, we have something really nice to build on top of for additional features. As well as totally customizable applications. Even QML makes it really easy, provided the hardware adaptation is there for things.

Re: Time for an open maemo fork?
 

I for one support rewriting NetworkManager. It has existed for, what, half a decade now, and still fails to support many basic use cases that "just worked" out of the box even on Nokia N800. Add to that its heavy memory footprint and you really start to wonder if you want it on a small device...

On the other hand, NetworkManager's habbit of doing just about nothing by itself, and needing distributions to add lots of glue to even give you a config file, it sounds a bit like it'd be at home with MeeGo core's policy of being a base for distributions/integrators ;-)

Re: Time for an open maemo fork?
 

I think what Cordia and the CSSU guys are doing is still the way forward at the moment. We have the CSSU slowly replacing the closed source components with open QT replacements. As they are QT the interfaces can easily be carried over to Cordia when the functionality required by them is implemented.

I seem to remember reading over the last few weeks something about Nokia wanting to make Meego so that it takes the burden of maintaining/building the OS off Nokia and hand it over to the community. As most of us probably understand, there are certain binary blobs they wish to keep closed source. Drivers and a few libraries specific to each device which would probably be the hardware adaption teams focus. Once the OS is up and running and Cordia is in a position where it is usable for day to day tasks, the only thing Nokia would have to do is update the small binary blobs here and there. Much better for them.

One thing I did wonder is how much work would be involved to remove GTK from Fremantle. If Meego and what remains of Symbian is going to go over to supporting QT, the CSSU are reimplementing applets in QT and Cordia is QT?, what is the point of loading a GTK desktop to run QT apps? Could we not replace hildon-desktop and friends and implement Cordia's UI?

Re: Time for an open maemo fork?
 

Stskeeps: So is having open applications in contrast to some of the Maemo 5 ones? Because the situation as I see it, for Maemo 5, is that I think there is another interest of hackers to want to customise things like the Calendar, but there isn't the source code. So open applications, and not merely the backend, will be a good thing in the MeeGo DE. I'm quite happy with the situation as announced so far, it's certainly an improvement of the doom and gloom I was feeling a while back.

Re: Time for an open maemo fork?
 

The thing I'm missing the most is that no standard way of making phone calls exists on linux.
We have interfaces for LEDs, NICs, usb pointing devices and all sorts of weird hardware. But making a phonecall is still a serial port with AT commands? and what about muxing gprs? 3G?
Everybody keeps re-inventing the wheel for "their" GUI.
We all need to agree on a lowest common denominator, some kind of dial-up daemon that can do muxing, set up and automatically knows what to do with incoming calls.

I know it can be done with loads and loads of scripts, but we need to agree upon something simpler; single executable, with simple config, something like dnsmasq for dhcp+dns.
It could have a simple shell program that initiates phonecalls.
All GUIs should use the shell program to make calls, and not talk to the daemon direct.
An incoming phonecall or phone status could be a fifo, /proc or /sys file, what ever is the most appropriate.
The config should already explain all sound routing.

This would be a good first step to making all ordinary linux distros part of the phone linux landscape, and therefor paving the way to having access to a proper phone distro.
Gentoo, Debian, OpenWRT etc.
We don't really need a special phone distro if all the programs needed, already exist in ordinary distros.

Re: Time for an open maemo fork?
 

You mean like FSO or ofono ?

Re: Time for an open maemo fork?
 

Those are fully open-sourced and GPL, right?

Re: Time for an open maemo fork?
 

First, why do you care if they're GPL, or more generally a "copyleft" license? As long as they're under a OSD-compliant or "free software" license, they should suit the mentioned purpose of standardizing across open-source OS distributions, and the fact that someone can make a proprietary derivative doesn't really seem to matter to that end.

Second, right on the front pages so conveniently linked by MartinK...
3 minutes of poking at the FSO site turned up nothing definitive (I'd guess license varies by package), but there is a Licensing proposal in the wiki.

Good thing someone happened by with a web browser and enough time to click through those links, or I guess you'd still be wondering... ;)

Re: Time for an open maemo fork?
 

The content on that page is a bit ancient (written back in 2007 and not updated since that day apart from general wiki gardening). See */COPYING under the cornucopia tree - summary: a mix of GPLv2 and LGPLv2.1.

Re: Time for an open maemo fork?
 

Benson, you poor fool. I'm not worried that someone takes open-source and makes a closed-source derivative in this particular case, especially since that would imply that there IS an open-source base they forked off of. No. I worry because there is open and free source like GPL, and then there's open but a little less freer CDDL, for example. It might be handy to know how tight the chains are held on their proprietary or not-so-proprietary code. We saw how wonderfully CDDL worked for the ZFS and the related lawsuits. I don't see how simply being OSD-compliant should be enough for me to prostrate myself at the alter of open-source software, especially with the likes of even Microsoft, Oracle and others buzzing around trying to find ways to cleverly call something open while slipping in a poison pill if you do your own thing in the open. Quite the opposite from the assumption you posed, in fact. :P With Nokia's track record so far and now with their new Microsoft marriage, I wouldn't put it past them to do something like that. I admit that it would be better than fully closed-source, but it's not much better.

Ah good. So at least ofono is GPLv2. I'd be paranoid about using something with an unclear license like FSO, then.

Indeed! I'm glad you decided to participate in the conversation instead of trying to deflect it elsewhere so it wouldn't be a talking point. Right?

Hey! Look at that! I guess my asking DID bring about some productive results--you learned something too, Benson. Hey! Everybody wins when questions are asked! ;)

Re: Time for an open maemo fork?
 

Also: You're welcome. :)

Re: Time for an open maemo fork?
 

Not to sound like a whiner, but there are some small issues with both FSO and ofono, that make them less likely to become adopted as standard:

FSO tries to integrate too much, and has too many deps (vala for one).
Everyone has their idea about the "correct" way of storing data, contacts etc. Has there ever been a standard PIM of any sort?

Can someone tell me what purpose ofono has to depend on dbus?
dbus is big and bulky, which makes it a very high level lib.
String parsing interfaces are a big no-no on most embedded platforms since they waste memory and time, and how is it better than just using a shell interface?

Re: Time for an open maemo fork?
 

Vala is a build-time dependency (EDIT: You can also choose to ship the C files that it generates from the Vala files, too). Though, as a result of using Vala (with its default GLib profile), it does have a runtime dependency on GLib (part of the LSB Desktop standards, like QtCore IIRC) like all of the GTK+ applications on Maemo (including things such as the Phone application and even the non-GUI apps such as the location daemon which seems to be the program handling the AGPS stuff).

It helps external applications stay aware of events? CSD, the phone control daemon on your N900, seems to make extensive use of it; look at http://maemo.org/packages/view/csd-base/ and http://maemo.org/packages/view/csd-call/ for example.

In any case, D-Bus is a freedesktop.org standard.

I'm no programmer but, hell, what have I to lose by posting? :)

Re: Time for an open maemo fork?
 

Regarding contacts storing standard, do you see anything wrong with VCard files?

Re: Time for an open maemo fork?
 

It might be slower or less efficient but, at the very least, importing and exporting vcard should be pretty standard. (I mean individual contacts as well as multiple contacts or ALL contacts in one export/import.. shouldn't be too much to ask, I would think.)

Re: Time for an open maemo fork?
 

I'm not particularly fond of some parts of GTK+ & co since many of the libs and tools are too bloated for embedded use, and many of them depend on each other for no reason what so ever.
It may be fine for n900 and similar platforms with huge amounts of memory, (once we get rid of MMC and maybe have all that 32G as pure, directly accessible nand chips)
But, memory drives up cost of the appliance and sinks performance.

I believe the largest part of the phone market needs a root system measured in a few M not G.
Look at openWRT project, it's easy to configure, comes out tiny, and they developed it out of a need for a better router distro. Now every mfg and their mom is using it in at least a few of the higher end routers since it saves them money and users get a better product. The only real competition is from vxworks, (fits in 0.5M, openWRT needs like 2-4M) which might not last long since vxworks (on routers) is becoming infamous for some pretty major stability issues (although cred is due for such a small tcp stack)

Also, yeah, vcard is about the only standard that ever came out of the PIM world (ical doesn't count yet), and I don't believe there's anything wrong with using it as the main storage mechanism. A directory with all vcards, one contact per file should also work fine, since most people don't store more than a few thousand contacts anyway. (that's assuming a good filesystem, not a stupid one like fat32)
This is demonstrated quite well by rolo.
Git is also a good demonstration of how you can use filesystem features to ignore optimising your application data store, and often the end result is just as fast, more portable and still useful after many years. ie. if something does translate well to files, you should use files, since filesystems get better all the time.
Afaik people have also invented some ways of syncing vcards with other directories.
But... Vcard is extremely verbose, and, it's difficult handle all the extensions by other apps.

It'd be interesting to see what the consequences are of using something like unison to keep 2 Vcard directories in sync instead of parsing the files. I can't immediately see a problem with that if the application only touches the file when you actually edit the contact.
*If you've edited the same contact on both ends, there's never a straightforward way of solving the conflict anyways.

To summarise; I don't think we're done with PIM by a longshot, and it'd be interesting to see people experiment with the bottom layers of PIM instead of making fancy UIs that nobody will use after a year. Who knows, maybe, just maybe, we might get a standard out of it.

Re: Time for an open maemo fork?
 

Also the freedesktop.org people are bad people.
(don't tell them I said that :)