On some systems, /usr is a mounted filesystem, so nothing in /usr/bin is around until the system gets far enough up to do mounts.
Other than that constraint, it's up in the air. I've seen systems where /bin has almost nothing, and others where /usr/bin is just a symlink to /bin.
On my Ubuntu box? Let's look.
$ ls /bin | wc -lThat's a lot. How about just the first 10%?
$ ls /bin | headThere's bash and ... a whole lot of bzip2 utilities?
The next three are also bzip2 utilities, so that's over 10%. What are they?
bzip2 is a compression algorithm that's (much) slower but (slightly) tighter than gzip. Why's it in /bin and what are all these related things?
$ bzexeA quick look at the man page says that bzexe produces compressed, but self-decompressing versions of executables. If you have a tiny disk, you can run bzexe on all your executables to compress them, but still use them as though they were uncompressed.
compress executables. original file foo is renamed to foo~
usage: bzexe [-d] files...
-d decompress the executables
Let's try it.
$ cp /bin/date .(bzexe leaves the original version in date~)
$ bzexe date ; ls -l
date: 1.993:1, 4.014 bits/byte, 49.82% saved, 45648 in, 22906 out.
$ ls -l date*
-rwxr-xr-x 1 jsh jsh 23561 2008-03-17 06:44 date
-rwxr-xr-x 1 jsh jsh 45648 2008-03-17 06:44 date~
And now, I'll show off the result.
$ ./dateOops. Sure enough, a quick peek inside the file shows it's invoking /usr/bin/bzip2 to unzip itself. Changing it to invoke /bin/bzip2, instead, fixes the problem.
./date: 22: /usr/bin/bzip2: not found
Cannot decompress ./date
Do any other bzip2-related utils have this problem? I won't bother to find out, I'll just file a bug report.
When someone tells me he's fixing bugs in my products, I'll look puzzled and say, "I thought all the bugs were fixed." It usually gets a laugh.