This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
The great thing about standards is that there are so many to choose from. (Daniel McCracken, I think).
There's 3, no 4, primary places programs end up. It's largely personal preference, but I have some guidelines I use. For whatever it's worth, here there are:
For a complete self-contained vendor environment, there's /opt. /opt is sometimes subdivided by product within vendor, as for example IBM and Websphere.
For a traditional approach, there's the /usr/local tree. A lot of Unix-style packages would build and install their packages into a subdirectory named for the package under /usr/local. I often put Tomcat and Ant there.
For really pervasive stuff, you can install directly into the /usr/bin and related directories. This is best done via the system's package manager (rpm, debian package manager, Solaris dpkg, etc.).
There's also the blended approach, where you install everything in one directory (/opt or /usr/local) and then softlink to present its system characteristics in their familiar locations; config stuff in /etc, logs in /var/log, workfiles in /var/lib and so forth.
The fourth approach is seen for applications that have a particular runtime environment such as Python or Perl. In this case, the packages normally install into a /usr/lib/<language> directory, such as /usr/lib/perl/site_perl.
CAUTION: according to the strict definition of the FHS, /usr should be read-only. Packages that have volatile storage requirements such as work directories, session info, etc. should assign those items elsewhere (normally under /var/lib).
Customer surveys are for companies who didn't pay proper attention to begin with.
I don't know about which Unix variant you're talking, but if it's Linux: Most Linux distributions have a package management system. The two most used systems are RPM (Red Hat Package Manager) and DEB (from Debian). The package manager takes care of installing, keeping track of, and removing software on your system. You download an .rpm or a .deb file and use the package manager to install it. The package manager will put all the necessary files in the right place for the program to work. If you later remove a package, it will clean up everything neatly.
Most programs installed via the package manager will put files in /usr/bin, /usr/lib, /etc and other places.
Sometimes you want to download the source code of a program which is not in an RPM or DEB package. Most of these things come with a makefile, and you use the program "make" to compile and link the program from source code. GNU software uses a certain convention for makefiles, and so the makefile of GNU programs and many other pieces of software comes with a standard set of make targets. You can usually build these programs with the following commands:
If the program is built successfully, you can usually install it with:
(you must run this last command as the root user, or with sudo if your Linux distribution uses sudo). This will normally install the program into /usr/local.
On my Ubuntu system, I always put manually installed programs in /usr/local.
I highly recommend packages. However, some of the best apps were designed for other times or other Unices (such as BSD), so occasionally you'll end up with the old "configure/make/make install" process or one of its kindred. Mostly these install to /usr/local, although some of the specialized ones such as "perl Makefile.pl/make" go to other places, as I mentioned above.
I’ve looked at a lot of different solutions, and in my humble opinion Aspose is the way to go. Here’s the link: http://aspose.com