It's not as blanket as that.

Software in testing/devel could go to either one.. it's completely dependent on whether or not the developer has been arsed with optifying it yet or not.

Before it makes it to just extras, however, it should have been optified.

Send it back, my friend. Mine rebooted several times, 2 hours after i received it. I didn't have time to add any applications before it froze on the boot screen (5 white dots) and then eventually gave up altogether. Nokia Repair Centre couldn't flash it back into action so i had to have a new one.

Dont mess about with it- just send it back.

Overtop,
Just Flash the firmware not the eMMC. That way you retain some of your app and various setting such as contact, email, 2 desktop screens etc. Once you got your phone where you want it to be, do a backup and save a copy on your PC.

I believe someone mention that you should manually turn off your N900 BEFORE it do the random restart 17 or 27 times. (I believe 17 times) That way you won't get stuck at the loaded screen.

There is a temporary fix for the random reboot by changing some number from 0 to 1. Check the reboot thread for the quick guide to.

i see.

is there a way of telling where a programm is going to installed before actually installing it?

and if programs have been installed to /usr already - can you clean up /usr in a quick and easy way?

and if its a bad thing to install to /usr, why do developers choose this destination in the first place? why not install things to /opt by default (if the only difference is that stuff installed to /usr will screw up your system while installed to /opt it wont)?

Rather than reflash like others are saying, you might be able to use the enable rd mode flag; boot up then shutdown and disable the rd mode flag. This can fix a "broken" system.

Nathan

/opt is not a linux standard. (well.. actually nothing really is a "linux" standard ).

When you install any Linux system it actually will let you choose what partitions to create.. using something like /opt is only beneficial if you actually separate /opt from your root partition.

The idea behind /opt is that if you fill that up 100%, it won't affect your root partition (since it's a separate partition) and therefore your device will still boot, you just won't be able to install new packages. However, if you setup your system to just have a / partition.. then it doesn't matter if you install apps to /usr, /etc, /opt, /sfw, /somewhere/noone/cares/about ... they are all on the / partition and will still fill up the drive.

The vast majority of software available for maemo I believe is a "port" of a desktop Linux application where /opt is more or less not used. Some of the more common desktop linux layouts for hard drives are any combination of these 6:
/boot
/home
/var
/usr
/
swap

So on Desktop Linux.. installing to /usr could (if the user set it up that way) be just as efficient or system-friendly as installing to a /opt partition. The name is irrelevant, it's just whether it is a separate partition from the root (/). I would venture that the *most* common setup is simply a root (/) partition, with swap on a desktop. That's subjective though based on my readings of how-to's and tutorials.. and is the one I personally use because every time I try and break it up to one of the ones above I almost always wind up with too little space in one area, too much space in another.

Doing that, however, means I have to keep an eye on my disk usage as I could fill up my root with both my Home, and my software. So really.. this "/opt" thing is more for mobile or low space devices. In theory, it's great.. in practice - they probably caused more problems branching /opt from / than if they just left the whole 32GB available to /.

As far as your questions relating to identify non-optified apps see here and here.

That is in no way true. There are standards for UNIX like OS's of which Linux is one. As such even Linux has standards.

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

Is relevant in this case.

I have been a UNIX admin for 20 years and would NEVER just dump the entire disk into root(/) The root partition is intended to be strictly for OS requirements.

I've read and understand the FHS as well Bratag. I built my own linux off of it using that and the LFS documents.

However, almost no mainstream distribution actually follows the guide 100%.

Solaris and FreeBSD have different filesystem structures, Solaris using things /export, which is mostly non-existent in any other Unix-related operating system. It also isn't even in the "almighty" FHS.

TLDP also has a "standard": http://tldp.org/LDP/intro-linux/html/sect_03_01.html.. which is similar - but not identical to the FHS.

I think debian sums it up best:
http://www.debian.org/doc/debian-policy/ch-opersys.html
In short - with pretty much all linux:
We follow this Standard..... except when we don't.

LOL sad but true. The only "standard" is sticking with a given distribution over time (and even then things change..but at least they tend to be more evolutionary rather than right-angle turns that break EVERYTHING at once).

I agree... and it's blatantly obvious to anyone that moves from an RPM-based distro to a DEB-based one and tries to administer things via CLI and not GUI.

Config files change location, and sometimes formats, all the time. It's really a PITA. Plus, the two use completely different software to handle such things as network cards - you have /etc/sysconfig/network/ifcfg-eth0... vs /etc/network/interfaces. Granted, they both follow the "standard" in that configuration files are placed in /etc... but doesn't really help in this case. So now even where they *do* follow a standard.. it becomes more or less useless.

This is one of the reasons I liked Debian... if you administer a Debian system long enough.. *usually* you can find your way around a gentoo, and slackware distro as well. If you get used to an RPM distro though.. you pretty much get lost anytime you move to anything non-RPM based.