# /usr/local/src is advisable as a practice. It's not mandatory! Most installations have recommended it. Eg: http://meadvillelibrary.org/os/filtering/squidGuard-install.html
# mkdir /usr/local/src would ask you to get to super user mode. That's obvious. You may refer to one of my last posts, for that matter. I hope my readers are advancing from beginner to intermediate level and have good retention power! (pun intended)
# I guess the previous one answers this as well! I haven't yet talked about a lot of things Linux has and does - chmod, is one of them!
# Heh, yeah the -C switch directly extracts the tar ball to a specified directory. But I didn't consider explaining switches in this very article. I guess you just mentioned - this article is for newbies!
# You're absolutely correct on that. But these methods still work! Thanks for sharing the latest syntaxes with our readers.
# I did miss out on automake, README and INSTALL thing. Thanks for pointing it out. This article and the future ones shall however share the "generic" ways quite proudly!
# I guess I clearly mentioned the disadvantages of a complete command line installation. However, packages like checkinstall help you to to build the required deb. But may be I'll get on to it some other time. GNU stow and other perl based tools are definitely not to be mentioned in such *newbie* stream articles. I remember how we struggled hard to learn to code on a notepad window before knowing what a NetBeans IDE was! I hope you got my point.

I thank you for your beautiful words and suggestions. Keep rolling in. I'll drop in here, once in a while and shout back! Cheers.

# /usr/local/src is advisable as a practice. It's not mandatory! Most installations have recommended it. Eg: http://meadvillelibrary.org/os/filtering/squidGuard-install.html
# mkdir /usr/local/src would ask you to get to super user mode. That's obvious. You may refer to one of my last posts, for that matter. I hope my readers are advancing from beginner to intermediate level and have good retention power! (pun intended)
# I guess the previous one answers this as well! I haven't yet talked about a lot of things Linux has and does - chmod, is one of them!
# Heh, yeah the -C switch directly extracts the tar ball to a specified directory. But I didn't consider explaining switches in this very article. I guess you just mentioned - this article is for newbies!
# You're absolutely correct on that. But these methods still work! Thanks for sharing the latest syntaxes with our readers.
# I did miss out on automake, README and INSTALL thing. Thanks for pointing it out. This article and the future ones shall however share the "generic" ways quite proudly!
# I guess I clearly mentioned the disadvantages of a complete command line installation. However, packages like checkinstall help you to to build the required deb. But may be I'll get on to it some other time. GNU stow and other perl based tools are definitely not to be mentioned in such *newbie* stream articles. I remember how we struggled hard to learn to code on a notepad window before knowing what a NetBeans IDE was! I hope you got my point.

I thank you for your beautiful words and suggestions. Keep rolling in. I'll drop in here, once in a while and shout back! Cheers.

# "It is advisable to to move it to the directory @/usr/local/src@" - Cite a source. Very few people keep their source tars in reality, exception being the linux source which people choose to keep in @/usr/src@ or similar.
# @mkdir /usr/local/src@ will rarely work as @/usr/local@ is usually owned by root. Therefore, superuser privileges are required to create this directory.
# "One, simply right-click on the package and select Extract Here." will rarely work as @/usr/local/src@ will be owned by root even if created as in the previous step. Either a chown, chmod or superuser privileges are required.
# @cd /usr/local/src/@ -- Why? Ever heard of the -C switch in tar?
# @tar -zxvf@ and @tar -jxvf@ are deprecated. The new version of tar simply reads the file header and auto extracts it. @tar xf@ is sufficient.
# "./configure", "make" etc - Very generic instructions for packages that use @autoconf/ automake@. There are tons of packages that opt to differ today. A better instruction would be to read the README/ INSTALL file which is almost always provided with every package. Another flaw is is that while the sources are in @/usr/local@, your program is really installed in @/usr@. Ever heard of the @--prefix@ switch?
# "make uninstall" - What if this option isn't available? You're taking the reader down a path where s/he can't uninstall the software. Use a package management system to install the software- Create a source/binary deb/rpm out of the source tarball and install that or simply use something like GNU Stow (my favorite)

# "It is advisable to to move it to the directory @/usr/local/src@" - Cite a source. Very few people keep their source tars in reality, exception being the linux source which people choose to keep in @/usr/src@ or similar.
# @mkdir /usr/local/src@ will rarely work as @/usr/local@ is usually owned by root. Therefore, superuser privileges are required to create this directory.
# "One, simply right-click on the package and select Extract Here." will rarely work as @/usr/local/src@ will be owned by root even if created as in the previous step. Either a chown, chmod or superuser privileges are required.
# @cd /usr/local/src/@ -- Why? Ever heard of the -C switch in tar?
# @tar -zxvf@ and @tar -jxvf@ are deprecated. The new version of tar simply reads the file header and auto extracts it. @tar xf@ is sufficient.
# "./configure", "make" etc - Very generic instructions for packages that use @autoconf/ automake@. There are tons of packages that opt to differ today. A better instruction would be to read the README/ INSTALL file which is almost always provided with every package. Another flaw is is that while the sources are in @/usr/local@, your program is really installed in @/usr@. Ever heard of the @--prefix@ switch?
# "make uninstall" - What if this option isn't available? You're taking the reader down a path where s/he can't uninstall the software. Use a package management system to install the software- Create a source/binary deb/rpm out of the source tarball and install that or simply use something like GNU Stow (my favorite)