It is very time consuming whenever we have to flash N900 and then removing un-needed apps and finally installing CSSU. It would be great if there is a CSSU fiasco image with useless programs already removed, and/or with some very usefull apps packed with the image. Then all we have to do is to take the cssu image and flash it as we usually do.

What do you guys think? Provide any other suggestions if you think they are good and necessary. Is this possible? Is anyone up for this?

Use backupmenu?

Quick reply...

The problem is, Nokia did not allow re-distribution of binary-closed-source bits inside of the image? So users can flash Nokia-prepared image, but they cannot (legally) create a different image, with closed-bits included?

When closed bits are either obsolete or reverse-engineered, it should become possible to supply CSSU image?

Best wishes. Thank you.

And I was wondering why something like that is not available. Thank you for clarifying me.

Isn't reverse engineering forbidden too?

Ssshh!

No cfw for n90
As there is backupmenu and one dosent need to flash to change or edit a file;

depends on country where you live...

Is it possible once all the proprietary elements are replaced by a FOSS version? Like OMP can replace Media Player (OMP's wiki also states that it is to be included in CSSU).

Before I go into a rant, here's a thought: Maybe we can provide a sort of 'sparce' fiasco image, or a giant diff/delta file passable to the patch command or some sort of other delta-applying utility (xdelta or Google's open implementations of better diff algorithms come to mind): then we can tell people to install the fiasco image, then immediately run a handful of commands, to apply all the differences to the stock image needed to generate the latest clean CSSU install?

Speaking of replacing closed stock software with libre alternatives, my understanding from back when CSSU was started was that things like OMP would become par of the course /replacements/ for non-libre blobs.

I to this day don't understand why, after the whole camera-ui replacement, a bunch of people felt the need to reverse that goal and complain just because the /testing/ version of CSSU did exactly what one of its original goals was, by replacing Nokia's closed camera-ui with a community-made libre camera-ui2.

Sure it was buggy for some specific uses (which I and many other users didn't mind), but that was, I think, the expected occurance for the testing branch. Especially now that we have a -devel CSSU branch, I don't know why we don't do this more aggressively, unless, of course, it's just the fact that the inertia is to not do it (I mean, I know we replaced other blobs, like the battery status menu applet, since then, and that's a more featureful, not 1-to-1 replacement)... But somehow the climate shifted after that camera-ui thing and we became seemingly a lot more cautious about stripping out closed components and replacing them with the libre ones unless some criteria is met. I'm not sure what that criteria is, but it seems to me to be too conservative.

From my perception, OMP was "good-enough" for replacing the stock media player, at least in the testing version of CSSU, a good year or two ago.... Am I wrong? Are whatever bugs/issues that remain really worth the significant impediment this binary blob provides? I mean, sure, it's not the only impediment - maybe replacing it can wait simply because we still have other stuff we can't distribute anyway, so we might as well just hold off until everything has 'good-enough' replacements, maybe?

Still, I at least, would have long ago been happy to see my redundant Nokia Media Player disappear from my device, and my Open Media Player moved into its place (I would liked it if it coopted the name and icon of the Nokia one too, like open camera UI did, but by now I've seen the current one for years side by side with the stock one, so I no longer care).

P.S. Though personally, I long ago wanted to see something more user-choice-respecting from the CSSU - greater flexibility in software actually installed.

Just because Nokia created a 'massive' metapackage for the firmware that depends on thousands of things, doesn't mean we need to keep the same. We're not savages.

The initial technical hurdle was to install the CSSU and swap out that metapackage, allowing updates. I think now that that's basically set up as smoothly as it will get, one such 'update' could be to severely reduce the rigidness of dependencies. I don't see why we don't do more depending on metapackages representing 'features', which can in turn be provided-by various other packages, much as we have done with various kernels (for example, the debate about including the much more featureful busybox-power vs. just updating the existing busybox could've been solved by having both of them provide some metapackage(s) that would include the features on which the firmware actually depends, and allowing users to install either one).

Because the reality is, if I don't want a media player, I should be able to uninstall it without having the package manager fight me along the way (Nokia had a financial incentive, in the form of customer support overhead, to block users from easily doing so. We have no such corporate contrivances requiring us to limit user choice so). If I want updates for my media player, I don't technically need, or personally want, the firmware metapackage to be a pseudo-dependency for me to be able to update it. I don't have this problem with Debian. Why do I have it with my Debian-based Maemo 5? I don't see anything inherent to apt or dpkg, or even our specific apt or dpkg on the N900, that makes this a must. If the rigidity comes from some peculiarity in HAM because HAM does something unusual on top of apt, then I am not convinced that this is a good thing in HAM (unless it can be trivially disabled by the user in some persisted setting somewhere). If the rigidity comes from the ssu metapackages themselves, then I am really not convinced that this is design that makes real sense.

And even though we can't change any of the closed packages (so we can't add 'feature metapackages' to those packages), if we are really serious about not /forcing/ users to replace the closed source components with open ones, we can still empower the optional-dependency-on-one-or-the-other concept, as I understand it, but having the cssu metapackage list alternative dependencies: One alternative dependency would be the original official package, one would be the feature-representing metapackage which all libre alternatives can then use if they are compliant. Ta-da, then you can install one, uninstall the other.

And one more thing while I'm detailing how I think we can improve the way we have things packaged now that we control all of the the relevant infrastructure (including updates for those who use CSSU): In Debian, as I understand it, there's no segregation between 'system' packages and normal ones at nearly the same depth as in Maemo 5. I've repeatedly heard it mentioned that we cannot have stuff in the CSSU repos depend on packages in the main Maemo community repos. To be honest, this pains me, because I don't know of any such limitation in the Debian repositories. There is no such walls - even for packages in different repositories, I have never had issues satisfying one dependency with a similar one. I know of no such limitation inherent to dpkg or apt, unless perhaps it's merely a configurable one.

It seems to me that, now that we don't need Nokia's blessing/aid in setting up a special CSSU repo (like we did back when the CSSU project started), it ought not be hard to just fuse the repos, and that there's no good reason to keep this segregation up because it seems to make things harder more than it makes them better. I imagine a single CSSU update from the current CSSU repos can reconfigure our N900s to not segregate packages as it currently does, and that we can start moving packages over, so I think the technical limitations are also not the main hold-up here. It seems to me like the system-packages-are-special setup is again something that made sense for Nokia's needs/preferences as a corporation driving product, but which does not make sense for us as a community trying to grow our inherited kinda-libre phone/computer into a truly-libre phone/computer. Personally, I still view this community, and the CSSU project, as not just life support delaying the death of this phone, but as a genuine potential step for us, a community of users, to build another truly open phone. And from that perspective, I think what I'm suggesting here is in our longer-term interests.

So, I guess to TL;DR summarize this text wall:

1. Maybe we can provide a giant 'diff' file or something like it for the difference between a freshly flashed Nokia FIASCO image, and a freshly installed CSSU on top of that, and a set of commands to apply that diff-like file right after install to the system?

And indirectly related, but which I think may indirectly aid us in the long term to more easily provide a CSSU image without closed blobs:

2.I think ideally we ought to decouple truly optional packages like media player, image viewer, etc, from the main CSSU package entirely. The CSSU project can still manage them, I just think my fundamental firmware package should not force me to have a handful of user-friendly apps which the system itself doesn't really need.

3. Regardless of point 2, I think ideally we ought to decouple whatever dependencies we do have in the CSSU from specific version and specific packages as much as possible, and instead enable user choice in selecting alternative, equally working components.

4. I think we should merge the CSSU and main package repositories, and get rid of the system-packages-are-special setup that Maemo 5 came with.

5. I think points 2-4 make sense because the way things are done seems to have been inherited from Nokia's motivations as a company to control the firmware (thereby reducing tech support burden, etc). The way I am suggesting things is more in line with how other big distributions like Debian do thigns, and seems to ultimately enable/empower users with more choice and freedom.