This is distribution dependent. I have CentOS (a clone of RedHat advanced server) and i have this file.
When you start your machine, the init process looks at a bunch of scripts to see what to start. One may be httpd (you can configure apache to start or not with chkconfig). If you look at your /etc/init.d/httpd script, you can see that it checks for /etc/sysconfig/httpd and if so sources it (as if it was a part of the current script). So now any variable definitions in /etc/sysconfig/httpd get applied for the rest of the script.
The examples you see in the file are to set HTTPD, which is a variable set to the executable name. In my distro, by default you use the old prefork module, but you can set to use the multithreaded /usr/sbin/httpd.worker here if you like. You can also set OPTIONS, which are command line options given to httpd (a.k.a. $HTTPD). There really isn't anything else you can set (you can ignore HTTPD_LANG, if you don't know if you need it, you don't need it)
So, if you want the multithreaded server, set HTTPD=/usr/sbin/httpd.worker. This probably won't break anything in the default apache, though some add-ons that you add may (but unlikely) break under multithreaded apache.
1. Directory structure
This should be covered in the Filesystem Hierarchy Standard
(2.3 PDF)
/bin/ Essential command binaries that need to be available in single user mode;
for all users, e.g., cat, ls, cp
/sbin/ Essential system binaries, e.g., init, ip, mount.
/usr/bin/ Non-essential command binaries (not needed in single user mode);
for all users
/usr/sbin/ Non-essential system binaries, e.g. daemons for various network-services.
/usr/local/ Tertiary hierarchy for local data, specific to this host.
Typically has further subdirectories, e.g., bin/, lib/, share/
2. Installation
I use a package manager wherever possible (e.g. yum or apt-get). This is possible for a very large number of applications, in a few cases you may have to add a repository. My second choice would be lower level packages such as RPMs and compiling from source would be my last resort (but some people prefer this)
Some package managers can install from RPMs (e.g. yum install oddity.rpm)
If you are compiling from source, its probably not a huge step to create your own package so that the system installer knows what you've done.
Then your problem reduces to e.g. yum remove packagename
The alternative is to keep good documentation about all sysadmin activities undertaken (I keep a journal in a text file anyway)
Best Answer
Some tool you used to create the account (adduser?) added them. The tool in question sees the comment / real name field in the passwd file as a GECOS field:
http://en.wikipedia.org/wiki/Gecos_field
The field values are
However, I cannot think of an applicaton which uses them. I believe these fields are close to useless. Use a different tool for adding users (useradd?) or explicitely give a value for the GECOS field if possible.