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?