Maemo Unification Proposal
 

My thread is too long for this forum. Please view:

http://pastebin.com/H9UH5Ty6

Downloadable via:
http://pastebin.com/download.php?i=H9UH5Ty6

Would Love to have feedback on this!

Thus far, there is 1 community approach to this. I figured a "vote" for the baseline was in order and a good place to begin. As people respond, I will update THIS original post accordingly. I've attached the original for people to follow. Once I get replies, I will update THIS post with the newest CSV.

The CSV has been updated with user supplied input! Thanks!

Re: Maemo Unification Proposal
 

Very good idea.

Simplifying,
Clean,
Minimalist,
Unifying,
I universal procedure,

I'm all for it.

Part I -- Firmware selection
 

Okay,

So it would seem, this idea is slowly gaining traction. The first choice in my mind would be the "Base Operating System". When it comes to the n900 there are two files we have to worry about. Nokia no longer hosts these and thus you have to search around a bit. There's good information out there, but a lack of documentation imho.

Currently on my system, I have the two following files:
RX-51_2009SE_10.2010.13-2.VANILLA_PR_EMMC_MR0_ARM.bin
RX-51_2009SE_20.2010.36-2_PR_COMBINED_MR0_ARM.bin

Doing some further research tonight to make sure I had the most up to date stuff, turns out, I didn't. Somewhere between 2012 and now, there was a newfile pushed out (either that or I missed it when I originally grabbed my flash files). The newest file out there for my purposes is:
RX-51_2009SE_21.2011.38-1_PR_COMBINED_MR0_ARM.bin

Google has revealed that this would be PR1.3.1, whereas I had PR1.3. This further leads to more questions:
infobot when doing ~emmc gives and option, followed by ~emmc2, ~emmc3 all the way to emmc4. The results seem like Language Packs for the underlying base OS.

So, here are my questions that can help me guide this decision making process.

PR1.3 -vs- PR1.3.1:
- Are there huge differences?
- Which one should we go with? Is 1.3.1 seriously tested and considered as stable or more stable than 1.3?

When it comes to picking the different eMMC varieties, what actually changes?

Re: Maemo Unification Proposal
 

personally I never bothered with 1.3.1 ...
I've noticed many new people feel the need for it [primarily from the belief it is more recent...therefore...ergo...it must be better ..more improved in ~nth ways than 1.3.....the reality is it isn't really a necessity...the language packs? ..perhaps...I can see it as a necessity or desired by some...so that would be good reason enough for some maemoans...]...

Part II -- Package Agreement
 

Ladies/Gents,

This is one of the first steps towards unification, choosing what gets purged for the "baseline".

Attached is the package-vote.csv file. If you want to contribute to it, add yourself to a column and then re-upload. Please pay attention to the header as it will help to keep this csv uniform with regards to the vote process.

Re: Maemo Unification Proposal
 

cssu takes care of pr1.3.1

Re: Maemo Unification Proposal
 

Yup, learned that in chat tonight!

Thank you for responding =)

Re: Maemo Unification Proposal
 

Yep, the consensus thus far is 1.3 == 1.3.1 when CSSU is applied. Thus, it doesn't matter, 1.3 or 1.3.1 for these purposes!

I am curious though, with regards to the different language packs, "What difference does it make"

thoughts?

Re: Maemo Unification Proposal
 

Check out the mentioned CSV and apply your thoughts accordingly =)

Re: Maemo Unification Proposal
 

cool and actually sane concept

this can solve much of the problems like optification and bloat which is really needed for a responsive n900 in the end
as mentioned avove i got that part good enough as i bricked my n900 countless times then reconfiguring it is a pain
currently my n900 and microb is really more usable i.e flashed a couple of weeks back
i dont know much but i thought myself and followed other peoples posts wikis google creepy sites etc
in the end i ended up purging non essential things configuring tracker properly disabling camera cover etc and stuff like that
all good i.e i did what i could
so whats the problem then?
well same as before i.e if you need to reflash every thing is gone you start with non functional bloatware again and for people like me its an acrane mess i.e figuring things out again and setting it up all in all a nightmare
most intresting thing is things go ugly if you are just a little misinformed about stuff and it should not be the case because the computer is working for me not the other way round

my current setup looks cool and fastest i could configure my n900 but i fear things wont be same next day as i would be installing android and kali tonight if i manage to break again i ll just have to use my backup phone for rest of the week as i simply wont have enough time and internet to set it up quick in a day or so also i aint smart enough yet to automate stuff yet

so why not a proper tarball or better refer to first post
its a very sane idea if it takes off

Re: Maemo Unification Proposal
 

I went by the list and my votes are included in the attachment. Dunno which would be the best way to share these votes? Some external service or manually editing files which seems bit involved?

Anyway here are few highlights and my comments regarding them:

1. adobe-flashplayer - PURGE - Do we really need this for anything?
2. docpurge - PURGE - Is this necessary?
3. Various games - PURGE - they can be included in separate metapackage (Games) like discussed earlier.
4. Mediaplayer - REMOVE - Installable later if the user needs it by separate metapackage (Multimedia/Media Playing). Dunno how the depends go so needs to be checked first. Do we have a .deb for this purpose?
5. Nokia Maps - Remove - This could be included in a metapackage (Maps & Navigation). Do we have a .deb for this purpose?

What do you think of the above? Was there something I missed or is there something that cannot be removed so "widely"?

Re: Maemo Unification Proposal
 

Your updates have been added to 1st post. I figure that's the easiest place for people to follow along.

I'm a big fan of removing stuff, and re-adding it to other meta-packages.

Re: Part I -- Firmware selection
 

Yes, PR1.3.1 contains only security fixes for certifiate management. Specially blacklisting certificates and blacklist database of comodo CA certs...

Of course PR1.3.1!

Part III -- Filesytem layouts Bindmounts -vs- FHS
 

This is the part of the thread where I will bring up de-optification and movement towards a more "universal" linux style filesystem. Currently, the way I do things, I use a bindmount technique. After purging unwanted .debs and upgrading to the kernel that I use, I perform my bindmount tricks. Now, You might ask, why not do the bindmount tricks after a full upgrade? Because it WILL fill /, and that's not cool. The point is to free / and make it have the least amount of crap on it. Also, this is where a Universal Argument is going to take place. "Stryngs, your bindmount techniques, they're not FHS!" I'll touch on that argument, after I describe what I do.

I would love to have bindmounted the whole FS, but, I don't know the "guts and boot processes" of the n900 like some of you smarter folks; so, I chose directories which I figured "safe" to do, and went with it. Luck worked out in my favor and my n900 boots correctly. I've always wondered, what happens if we bindmount /etc, /bin, etc.. etc.. etc.. So the story goes, when it comes to boot, some stuff is going to have to be "visible" to the bootstrapping process (wrong word?), while I've managed to hack together a solution for my purposes, I don't know if the bindmount technique would allow the Operating System to work if I went 100% bindmounted. I'd love to hear it from some of the smarter folks, and let me know what's up. Okay, Enough blabbing, here we go:

mkdir -p /home/rootfs_bind/var/lib
cp -ar /usr /home/rootfs_bind
cp -ar /sbin /home/rootfs_bind
cp -ar /lib /home/rootfs_bind
cp -ar /root /home/rootfs_bind
cp -ar /var/lib/dpkg /home/rootfs_bind/var/lib

After copying over the files, I modify /etc/event.d/rcS-late with the following changes:
mount --rbind /home/rootfs_bind/usr /usr
mount --rbind /home/rootfs_bind/sbin /sbin
mount --rbind /home/rootfs_bind/lib /lib
mount --rbind /home/rootfs_bind/root /root
mount --rbind /home/rootfs_bind/var/lib/dpkg /var/lib/dpkg

Reboot and p00f! Now, with the combination of the above, and my naked pymaemo-optify concept, installing a .deb works as the author of the .deb had intended, the files, in the / of the .deb, they actually go WHERE they were intended to go, not some /opt voodoo black magic. Also, as a side benefit (An intended one I might add...) You can grab ANY armel or all based .deb, and simply dpkg -i it. No having to worry about, "Oh noes, is this going to fill /?" Now, I'm not hating on optification; I just think the concept can be done smarter.

Alright, I said there was going to be an argument, so let's discuss it. FHS, also know as the Filesystem Hierarchy Standard. Standards, that what this whole concept is anyways, so it's a darn fine point to talk about. I've heard in chat over the past couple days about moving /usr to eMMC. Also, as has been brought up, if a .deb was built AS IT SHOULD HAVE BEEN, it too will follow the FHS, and thus, / will never overflow. So... The FHS argument trumps my bindmount technique 100%. The problem? I've yet to find a written and documented solution. Folks speak of it, but, in this instance, we need pixels on screens to form a coherent set of processes that We, the Community, can follow; otherwise it's just some homebrew technique, and one of the many reasons I cry out for the Unification of our community. SO... if you are one of those who possess the knowledge of how to move /usr over to eMMC, safely and efficiently, PLEASE... respond to this and layout the steps, from start to finish.

Lastly for this topic, there exists in my mind, some concerns with what I currently use. I'm not a kernel developer, I'm a hacker; I go with what I know and what I'm willing to try; however, the n900 can be delicate. As well, it's old and no longer in production; if I flash flash flash flash flash... Eventually, I might wear out my hardware, and then I no longer have my n900... Yes, I can buy another one, but why experiment if we don't have to. So here is my question; specifically I direct this question towards Pali. Based on what I've done, with my bindmount hack, How does this affect when you next release a new kernel? Since, at some point in the boot process, I'm guessing that /home/rootfs_bind/usr is NOT /usr, and /usr is really /usr, then the changes and updates, that have occured since original bindmount inception won't show during the bootprocess, at least not until rcS-late kicks in and mounts things. In other words, based upon what I've done, do I need to, in order to "properly and safely" upgrade the kernel, unmount my bindmounts, perform the kernel upgrades, copy the appropriate NEW files to their bindmount location and then re-bindmount?

Okay, hopefully I've confused everybody at this point. Heck, I confuse myself thinking about bindmounting sometimes. So.... Thoughts?

Re: Maemo Unification Proposal
 

p.s. When I update the CSV next, I will respond to your additions and such. I like them!

Re: Maemo Unification Proposal
 

someone is saying to remove Nokia Maps? Gawd!

Re: Maemo Unification Proposal
 

yes, from the base-install. So, a lean 'n mean, more standard Linux minimal install, with meta-packages for different areas of function, such as "Navigation".

Re: Maemo Unification Proposal
 

I tried removing Nokia Maps in the past. There were no surprising dependencies so it went pretty well. The only problem was that removing Maps did not remove the Contacts integration so tapping on an address in Contacts still tried to open Maps on that address. I suspect removing Nokia Maps properly may involve more effort than anyone is prepared to invest.

Re: Maemo Unification Proposal
 

Agreed pichlo...
there will be some ugly spots I'm sure.
On the whole the idea of what the op proposes is sound and sane.
Having meta-packages somewhat similar to say [roughly] Bodhi ...
works well for it...
may work very well for us.
a single streamlining...
easy to implement and use..
universal one-stop shop does make sense ...
especially now with all the flavours...
and the need to be canny about what you are doing and how to do it.
I think cutting the Nokian [Gordian] knot is a good idea.
But as pichlo does sanely mention...
some things it might be better to just leave alone [ie- maps] and work around them [no harm in it] ...
making the work on this more ...um...expedient.. time-wise in effort...
to bring this to the community in a timely fashion.

Re: Maemo Unification Proposal
 

anyone have link for PR 1.3.1 firmware ?? i want to download it.

Re: Maemo Unification Proposal
 

Well, it's sick to have / on a 256M disk. But it's still not a good idea to move vital parts of the system to a slower partition. And they reside in /usr (see libstdc++6)

I'd suggest moving / to /dev/mmcblk0. Altogether - we get rid of the problem of small rootfs. And we take the opposite of optification - we do nandification - move the vital parts of the system (libc6, libstdc++, glib, hildon) to NAND.

Beautiful, isn't it? We still get the blazing fast performance for vital components and we don't have any problems with full rootfs.

The only issue may be the boot process, but I don't know how big it will be. Generally, the boot components are usually vital.

Re: Maemo Unification Proposal
 

Hi panjgoori,

I found this post; but do not know whether it is recommended or not... be careful!

jm

Re: Maemo Unification Proposal
 

Have you looked backwards in this very thread?

Re: Maemo Unification Proposal
 

It's not a bug, it's a feature :D
We should leave the contacts entry. Then developers - add support for it (so that clicking the address may open modRana, mapper, etc.). If no app is found, a pop-up should be shown that no compatible application has been found.

Re: Maemo Unification Proposal
 

yes, of course; I just doesn't know the source where the image is available from...