-> That because you manage only one computer. Think about poor sysadmins who -> maintain dozens servers on a site - they just don't have enough time to -> untar and compile all that crap... It's much more than just ease of installation. If "./configure, make, make install" did the valuable things RPM did for me, I wouldn't use RPM. RPM is system-wide version control. 'Pristine' sources. A safe upgrade path. An established method for handling dependencies. A way to verify that the files have not been tampered with. A quick way to see what is or is not installed on a particular system. A way to identify the purpose of any little file on your hard drive. A way to CLEANLY uninstall something. Depending on "make uninstall" is dangerous; it assumes that the admin knows (a) all packages on a particular system, and (b) all dependencies between those packages. Not exactly a good idea for a production environment. (It also requires you to keep a turd of a build directory lying around, but that's just an annoyance.) Also, having a C compiler on a production server is dangerous, as it gives script kiddies the ability to run the shell script they downloaded and wind up with a rootkit on your system. RPMs avoid that vulnerability. (Not that it can't be worked around... I'm referring to unskilled punks.) Operating Systems come with package management systems for a reason. It's one thing for me to futz around on my workstation, but in a production environment -- where you don't know who is using which systems for what purposes -- RPM (or DEB, or to a much lesser degree pkginstall or the 'ports' system) is an invaluable tool. --Derek