The headers under /usr/include/linux
and under /usr/include/asm*
are distributed with the Linux kernel. The other headers (/usr/include/sys/*.h
, /usr/include/bits/*.h
, and many more) are distributed with the C library (the GNU C library, also known as glibc, on all non-embedded Linux systems). There's a little explanation in the glibc manual.
Note that /usr/include/linux
and /usr/include/asm
should contain the headers that were used when compiling the C library, not the headers from the running kernel. Otherwise, if some constants or data structures changed, there will be an inconsistency between the compiled program and the C library, which is likely to result in a crash or worse. (If the headers match the C library but the C library doesn't match the kernel, what actually happens is that the kernel is designed to keep a stable ABI and must detect that it's called under a different ABI and interpret syscall arguments accordingly. The kernel must do this for statically compiled programs anyway.)
I remember a heated debate between Debian and Red Hat a while (a decade?) ago on the /usr/include/linux
issue; apparently each side is sticking to its position. (As far as I understand it, Debian is right, as explained above.) Debian currently distributes /usr/include/linux
and friends in the linux-libc-dev
package, which is compiled from kernel sources but not upgraded with the kernel. Kernel headers are in version-specific packages providing the linux-headers-2.6
metapackage; this is what you need to compile a module for a particular kernel version.
The package you're looking for is the C library headers. I don't know what it's called, but you can find out with yum provides /usr/include/sys/types.h
.
While both are designed to contain files not belonging to the operating system, /opt
and /usr/local
are not intended to contain the same set of files.
/usr/local
is a place to install files built by the administrator, typically by using the make
command (e.g., ./configure; make; make install
). The idea is to avoid clashes with files that are part of the operating system, which would either be overwritten or overwrite the local ones otherwise (e.g., /usr/bin/foo
is part of the OS while /usr/local/bin/foo
is a local alternative).
All files under /usr
are shareable between OS instances, although this is rarely done with Linux. This is a part where the FHS is slightly self-contradictory, as /usr
is defined to be read-only, but /usr/local/bin
needs to be read-write for local installation of software to succeed. The SVR4 file system standard, which was the FHS' main source of inspiration, is recommending to avoid /usr/local
and use /opt/local
instead to overcome this issue.
/usr/local
is a legacy from the original BSD. At that time, the source code of /usr/bin
OS commands were in /usr/src/bin
and /usr/src/usr.bin
, while the source of locally developed commands was in /usr/local/src
, and their binaries in /usr/local/bin
. There was no notion of packaging (outside tarballs).
On the other hand, /opt
is a directory for installing unbundled packages (i.e. packages not part of the Operating System distribution, but provided by an independent source), each one in its own subdirectory. They are already built whole packages provided by an independent third party software distributor. Unlike /usr/local
stuff, these packages follow the directory conventions (or at least they should). For example, someapp
would be installed in /opt/someapp
, with one of its command being /opt/someapp/bin/foo
, its configuration file would be in /etc/opt/someapp/foo.conf
, and its log files in /var/opt/someapp/logs/foo.access
.
Best Answer
What? no
/bin/
is not a symlink to/usr/bin
on any FHS compliant system. Note that there are still popular Unices and Linuxes that ignore this - for example,/bin
and/sbin
are symlinked to/usr/bin
on Arch Linux (the reasoning being that you don't need/bin
for rescue/single-user-mode, since you'd just boot a live CD)./bin
/usr/bin/
essentially,
/bin
contains executables which are required by the system for emergency repairs, booting, and single user mode./usr/bin
contains any binaries that aren't required.I will note, that they can be on separate disks/partitions,
/bin
must be on the same disk as/
./usr/bin
can be on another disk - although note that this configuration has been kind of broken for a while (this is why e.g. systemd warns about this configuration on boot).For full correctness, some unices may ignore FHS, as I believe it is only a Linux Standard, I'm not aware that it has yet been included in SUS, Posix or any other UNIX standard, though it should be IMHO. It is a part of the LSB standard though.