I don't think that I am in disagreement here.

It should be noted though, that very little goes on at this community that sticks within the stable extras rep. I didn't have to look very deep before people started talking about red and blue pills. Sticking within the packages is simply not normal usage for these devices. Yet.

I don't disagree with the message: "on your own risk". I disagree with it being pinned down as the user/developer/tester's fault and responsibility. It's a capacity fault at least as much as it is a developer guideline not being followed fault.

Then I think that this is more what needs addressing, rather than the blame or finger-pointing, and to my understanding with things like the QA check-list, addressing of it is in progress.

How does Maemo handle /var/log/ ? Is there some mechanism to prevent it from filling up? Or is it just expected from all applications to not fill the root partition with log files?

Devatingly good point about app design relative to the device. A concern though is does this mean significant rewrites of current apps, rather than the great and "quick" ports of current apps we were expecting?

A lot of great apps already on Maemo and Linux. Shame if this becomes an obstacle to proliferation of apps to Maemo 5.

I apologize again, I am sorry that I made such a large portion of this thread be about what boils down to semantics. Qgil have probably done a lot of hard work to improve on this situation in the months that have passed, he must be frustrated that people don't follow the guidelines * and I should not expect of him to hold the weight of the complete responsibilities of "Nokia". Sorry Qgil, all I mean to say is "you probably should not formulate things in a way that makes it look like you mean the (users/testers/developers) carry the full blame for a capacity issue".

Um no offense but perhaps you should read

http://www.pathname.com/fhs/pub/fhs-2.3.html

Before claiming I violate it. If you cant be bothered I will quote it here.

It's not a blatant FHS violation by any means. FHS allows for applications to be installed at /opt/<registered vendor id>/<package or whatever they want> or /opt/<package>:

http://www.pathname.com/fhs/pub/fhs-...FTWAREPACKAGES

How that software gets there isn't prescribed in the FHS AFAICT.

Anyone who thinks they've come up with a brilliant new idea is recommended to read the original thread on maemo-developers. The indepth technical discussion should not be repeated on tmo.

Short version: Mounting /usr on the eMMC would require both tooling and image changes which are difficult to QA at this point. The community can iterate and solve this problem faster. Also, the eMMC is slower than the 256MB flash.

No fingers pointed, just trying to share information and collaboration during a testing period. Remember that nobody has paid a cent for an N900 and anybody playing with one is conscious of his status of tester.

Hardware selections are made well in advance based on what is available, price, time of delivery, reliability. It's a complex business really far away from what most of us know and do.

So we have OMAP3430. And we are proposing a solution. The critique is that we could have shared the problem with the community before. Well, agreed. But we shared and discussed (read the maemo-developers archives) and what we have is what we have agreed to be the best solution available.

Now, when the first real N900 users pay for their device and go back home they will find:

- Easy access to software downloadable from Nokia repositores. Optification is enforced to all the software hosted there.

- maemo.org Extras pre-configured but not enabled by default. Users need to check the box if the repo hasn't been installed by other means.

- maemo.nokia.com/maemo-select updated including a selection of Extras applications that have gone through optify check and other quality criteria tested by Nokia.

And then there is the Internet, with maemo.org as a gateway thanks to the recommended links in the Maemo Nokia sites and the well earned Google juice.

If the user stays within the Nokia + maemo.org Extras selection they won't find this problem easily.

If they go deeper in Extras pure then it shouldn't be any problem either, if the community QA works and optification is pushed in the right way.

If all the links they find about extras-testing come with the corresponding warnings and explanations, the problems should be minimal as well, specially if developers know the optify lesson well and send their packages optimized already from extras-devel.

If links to extras-devel are to be seen only in developer / hardcore contexts and not just in any Talk forum answering newbies... and if the references to extras-devel come always with the right warnings and explanations, then there should be not much problems for pure end users either.

Hopefully this system will be sustainable and work. Freedom comes together with responsibility. Nokia alone won't make it and we are encouraging (and not blaming) community developers and community testers to help in this common goal.

(wow, this was long typing from the N900)

Beautiful. I am satisfied and then some.

Changed my post since it was too stupid. This one is not much better though....

If we are installing from the repository and the app adheres to the rules, how many apps can we expect to be able to install if the average app is ten megs? I know is is not a proportional issue, but about how many apps before we run out of memory? Considering some of the space is already used when you get the device.