Every time I read the tips for installing an SDK, IDE, some extension and so on, it says, that I should unpack them in /opt folder. Why do I need to do that?
When I was installing Ubuntu, I read that I should set only 10-20 GiB for the / file system and remaining space set for /home. So should I extend the space for root folder, or leave all stuff at /home? Is there any difference?
First, understand that any directory that's not explicitly a mount point for a separate partition (or a subdirectory of such a mount point) is stored on the root (/) partition. Thus, if you've got root (/) and /home, and no other partitions, your /opt directory is simply a directory on root (/). Likewise for /tmp, /sbin, and anything else. Thus, the initial question is based on the false premise that you need separate partitions for every directory that leads off of root (/), and so can't be answered directly.
Second, /opt is used for third-party software, which in the context of Ubuntu, means precompiled software that is not distributed via Debian packages. Occasionally you'll see official program documentation that refers to /opt, but Debian packages are available that drop these files elsewhere. In such cases, you should ignore the official documentation, or at least ignore its file-location references, when you use the Debian package. Also, if you have a choice of using a precompiled package via a tarball or a Debian package, it's generally best to use the Debian package. All in all, use of /opt is pretty rare these days. If you still think you need to put files in /opt, you might do well to name the software, since people here may know whether a Debian package is available for that software.
Finally, combining the two previous points, it's very rare for Ubuntu installations to split /opt off into a separate partition because it's rare for significant amounts of data to be stored there. Most Ubuntu software goes in /usr and other locations. It was once common to split /usr into a separate partition, but that practice is pretty rare today. If you do happen to need to install lots of software in /opt, then creating a separate partition for it might make sense -- but in many cases this won't really be helpful. Separate partitions make sense if you need to handle security differently, if different filesystem features will be helpful, to share data across multiple OS installations in a multi-boot configuration, and for other reasons. Routine software installation is not likely to benefit from a separate partition; in fact, creating a separate partition for /opt could cause problems if the size consumed by software stored there changes, or if you get the size estimate wrong initially.
The fact is that you don't need to do it. Using /opt is a convention. I would recommend using it but it is not strictly necessary.
From Linux Filesystem Hierarchy: Chapter 1. Linux Filesystem Hierarchy:
1.13. /opt
This directory is reserved for all the software and add-on packages that are not part of the default installation. For example, StarOffice, Kylix, Netscape Communicator and WordPerfect packages are normally found here. To comply with the FSSTND, all third party applications should be installed in this directory. Any package to be installed here must locate its static files (ie. extra fonts, clipart, database files) must locate its static files in a separate /opt/'package' or /opt/'provider' directory tree (similar to the way in which Windows will install new software to its own directory tree C:\Windows\Progam Files\"Program Name"), where 'package' is a name that describes the software package and 'provider' is the provider's LANANA registered name.
Although most distributions neglect to create the directories /opt/bin, /opt/doc, /opt/include, /opt/info, /opt/lib, and /opt/man they are reserved for local system administrator use. Packages may provide "front-end" files intended to be placed in (by linking or copying) these reserved directories by the system administrator, but must function normally in the absence of these reserved directories. Programs to be invoked by users are located in the directory /opt/'package'/bin. If the package includes UNIX manual pages, they are located in /opt/'package'/man and the same substructure as /usr/share/man must be used. Package files that are variable must be installed in /var/opt. Host-specific configuration files are installed in /etc/opt.
Under no circumstances are other package files to exist outside the /opt, /var/opt, and /etc/opt hierarchies except for those package files that must reside in specific locations within the filesystem tree in order to function properly. For example, device lock files in /var/lock and devices in /dev. Distributions may install software in /opt, but must not modify or delete software installed by the local system administrator without the assent of the local system administrator.
The use of /opt for add-on software is a well-established practice in the UNIX community. The System V Application Binary Interface [AT&T 1990], based on the System V Interface Definition (Third Edition) and the Intel Binary Compatibility Standard v. 2 (iBCS2) provides for an /opt structure very similar to the one defined here.
Generally, all data required to support a package on a system must be present within /opt/'package', including files intended to be copied into /etc/opt/'package' and /var/opt/'package' as well as reserved directories in /opt. The minor restrictions on distributions using /opt are necessary because conflicts are possible between distribution installed and locally installed software, especially in the case of fixed pathnames found in some binary software.
The structure of the directories below /opt/'provider' is left up to the packager of the software, though it is recommended that packages are installed in /opt/'provider'/'package' and follow a similar structure to the guidelines for /opt/package. A valid reason for diverging from this structure is for support packages which may have files installed in /opt/ 'provider'/lib or /opt/'provider'/bin.
/opt was often a separate drive. It would be used to install proprietary software, which often had huge disk space requirements due to bundling of all required libraries and other resources. In modern times, drives are so big that it is feasible and easier to just use a single root on a single drive.
/opt is used for (sometimes proprietary) external applications that aren't considered part of the Linux distribution. These applications might have hard-coded paths and so will only run correctly when installed to /opt - but if there are no hard-coded paths then you could install them to any path. A program that is installed in /opt is supposed to be self-contained.
The main reason for using /opt is to provide a common standard path where external software can be installed without interfering with the rest of the installed system. /opt does not appear in standard compiler or linker paths (gcc -print-search-dirs or /etc/ld.so.conf etc.), so headers and libraries installed there are somewhat isolated from the main system and shouldn't interfere with already-installed programs.
The use of /opt is specified by the Filesystem Hierarchy Standard : /opt, which notes that /opt originally came from Unix.
/opt : Add-on application software packages
Purpose
/opt is reserved for the installation of add-on application software packages.
A package to be installed in /opt must locate its static files in a separate /opt/<package> or /opt/<provider> directory tree, where <package> is a name that describes the software package and <provider> is the provider's LANANA registered name.
Requirements
The directories /opt/bin, /opt/doc, /opt/include, /opt/info, /opt/lib, and /opt/man are reserved for local system administrator use. Packages may provide "front-end" files intended to be placed in (by linking or copying) these reserved directories by the local system administrator, but must function normally in the absence of these reserved directories.
Programs to be invoked by users must be located in the directory /opt/<package>/bin or under the /opt/<provider> hierarchy. If the package includes UNIX manual pages, they must be located in /opt/<package>/share/man or under the /opt/<provider> hierarchy, and the same substructure as /usr/share/man must be used.
Package files that are variable (change in normal operation) must be installed in /var/opt. See the section on /var/opt for more information.
Host-specific configuration files must be installed in /etc/opt. See the section on /etc for more information.
No other package files may exist outside the /opt, /var/opt, and /etc/opt hierarchies except for those package files that must reside in specific locations within the filesystem tree in order to function properly. For example, device lock files must be placed in /var/lock and devices must be located in /dev.
Distributions may install software in /opt, but must not modify or delete software installed by the local system administrator without the assent of the local system administrator.
Rationale
The use of /opt for add-on software is a well-established practice in the UNIX community. The System V Application Binary Interface [AT&T 1990], based on the System V Interface Definition (Third Edition), provides for an /opt structure very similar to the one defined here.
The Intel Binary Compatibility Standard v. 2 (iBCS2) also provides a similar structure for /opt.
Generally, all data required to support a package on a system must be present within /opt/<package>, including files intended to be copied into /etc/opt/<package> and /var/opt/<package> as well as reserved directories in /opt.
The minor restrictions on distributions using /opt are necessary because conflicts are possible between distribution-installed and locally-installed software, especially in the case of fixed pathnames found in some binary software.
The structure of the directories below /opt/<provider> is left up to the packager of the software, though it is recommended that packages are installed in /opt/<provider>/<package> and follow a similar structure to the guidelines for /opt/package. A valid reason for diverging from this structure is for support packages which may have files installed in /opt/<provider>/lib or /opt/<provider>/bin.
There is nothing sacred about /opt, it is just common practice to put precompiled software which should be accessible to all users of a system in this directory. If you are the sole user of the system, there is nothing wrong at all with extracting it in your home directory. And even if there are several users on the system which need access to this software but you want to use the space on your /home partition, there is nothing wrong with creating a publicly accessible /home/softwarename directory and extracting your software there (the only caveat is if you happen to have a user named softwarename, you won't be able to use it at the user's home directory).
The detailed answers are very good, but (aside from software that may have hard coded absolute paths in it - not the best programming practice), the main point is that non-system/non-distribution software should not be stored mixed in with the regular system files.
Putting things in /opt or /usr/local keeps things clean and safer.
In particular, your software search path ($PATH) determines the order in which locations are searched when looking for a program of a particular name to execute. Usually, places like /opt and /usr/local are toward the end of the list.
If you install a package that has a program named cp in it, the default search order that comes with your distro will find the normal one because the directory it is stored in is searched before places like /opt.
If it didn't work that way, who knows what might break or open a security hole if a program named cp that does something else gets run when you think you're just trying to copy some files.
If something like this does happen, it may take awhile before somebody thinks to run a command like type cp (which might not even be enough to show that something is wrong) to find out that what is being run isn't what you think it is. Until that point, you're stuck at "Everything is exactly the way it should be aside from the small detail that it doesn't work!"
It basically helps keep unexpected things from happening and also avoids situations where system updates might remove or replace some or all of your "custom" installed packages. Or, the reverse, some "custom" programs might overwrite system supplied programs that many other programs or scripts may rely on.
From an administrative point of view, mixing "system" and "optional" programs/files in the same locations places your system in an "undefined" or at least "ambiguous" state.
If you have a problem with your system or a program and need help, one of the first questions that gets asked is "What did you change?" and "Can we temporarily disable some of all of those changes so we know we're looking at the real problem and not just a symptom of something else."
With separate locations, these changes can be quickly identified and all you have to do (at least for the programs themselves) is temporarily remove their directories from the path.
