Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
There is less than 24 hours left to vote in the 2015 LinuxQuestions.org Members Choice Awards. Click here to go to the polls. Vote now and make sure your voice is heard!
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
I'd like to clear up my misconception towards various types of installations. Is one better than the other? Do more senior people prefer compiling from source code? Hows does is compare to yum install or install from rpm?
For me, the preferred method is installing from binary packages (rpm files in the case of the distros that use rpm, deb packages in distros derived from debian, and other formats in distros that use other formats); it's easier, cleaner, and you're making sure the package you're installing is intended for your specific distro. Compiling may be necessary when some specific package is not on the repositories, or in the rare case when a package that is available in binary format in the repositories, was not compiled with a specific option you may need.
Compiling from source is more flexible than installing from binary. You can compile the minimum options which you want. yum is used when you have Internet connection, it connects to your repository and helps you solve the dependencies packages. rpm is used when you want to install some packages separately, it cannot solve the dependent problem. If A depends on B, and B depends on C, ... you must install in order: C --> B --> A. More detailed, you should read the man page.
All things being equal, I suspect most persons choose the easiest way, which would be installing from the repos.
I started with Slackware v. 10 (Slack is still my favorite). Most of the programs I installed for my first three years of Slacking, I compiled for sources, because, well, that's the Slackware way* (now there's Slackbuilds). Now, if I can find a program in the repos or, in the case of Slackware, on Slackbuilds, I'll go that route rather than compiling, simply because it's a lot quicker.
When I have a choice between sources and repos, I choose repos. But I'm quite happy compiling.
get a Scotch.
*There have been a few sites that offer Slackware packages, but they are not officially associated with the Slackware mothership.
i tend to leave the base/core of the OS installed ( rpm) fedora ,Cent, Suse, and xz for Arch
and build optional programs from source .Some programs i just build out of habit .
Programs like "The Gimp" i have been building from source for many many years ( since 2001) and just build it mostly out of habit .
But there are options that can be set at build that are not in a "one rpm fits all" OS install .
other programs like Celestia I build because I NEED some settings turned on ( S.P.I.C.E.)
and because i am using the QT4 interface and NOT the default GTK ( or kde3-qt3.5) interface
Then there are some programs that i used to build but do not any more
like Mplayer .I first started building mplayer on XP in MinGW then fedora 4 & 5 .Then stopped .
It is just way too much work , i will leave that to others to do .
I generally use a package manager: the path of least resistance.
There is one other aspect of package management that hasn't been touched on yet in this thread: configuration.
If you use a package management system, the program that handles package management usually has hooks to kick off post-install configuration scripts. (At least, my experience with Ubuntu and I think Red Hat)
The post-install scripts may not be needed by every application, but there are some where they are extremely useful. For instance, installing server applications. The post-install scripts add/change the system beyond basic installation. For instance, install mysql server, and it asks for you to setup a database-root password. Another: install postfix and the scripts create the user and group to run the server as unprivileged. Also, the post-install scripts could create symlinks or other filesystem tweaks to help the package run (e.g. if the distribution places binaries or other files in directories the application does not expect)
Some source-based applications do those things in the "make install" step. Some do not. You would need to perform all those steps manually if they are not automated. So, you need to read all the documentation provided in the tarball. Even then, the application developers make assumptions about your knowledge of a Linux system that may not be true. You could find yourself searching for an online reference to explain X just so you can continue from step #3 to step #4 of (post-)installation.
And lastly, using a package manager likely means you will get a default configuration file that is reasonable. The source tarball may provide some example configuration files to choose from, but it's more work. In other words, you may need to tweak the package maintainer's configuration by looking for specific parameters to change. Whereas you may need to review the entire sample configuration provided by the developers.
The more time you are willing to invest, the more customized your installation will be. You just have to do the cost-benefit analysis.