Slashdot Mirror
Build From Source vs. Packages?
mod_critical asks: "I am a student at the University of Minnesota and I work with a professor performing research and managing more than ten Linux based servers. When it comes to installing services on these machines I am a die-hard build-from-source fanatic, while the professor I work with prefers to install and maintain everything from packages. I want to know what Slashdot readers tend to think is the best way to do things. How you feel about the ease and simplicity of installing and maintaining packaged programs versus the optimization and control that can be achieved by building from source? What are your experiences?"
Gentoo! (Combines the best of both worlds)
is that compiling from source can sometimes even be slower executing depending on your compiler.
Also, better to install from packages because:
1. They WILL work
2. They install fast
3. They are easilly de-installed
4. They are painless
5. Dependencies are installed automatically sometimes, and other times packages are the only way to resolve a dependency loop
6. Most other OSes since the dawn of the home computer use pre-compiled binaries, and nobody has complained
7. It is surely the developers job to make sure it compiles properly and do all the compiler error headache solving
Packages are just so much nicer. A lot of the time, I can get pentium-optimised versions of the ones I want, and if I can't then 386 optimised versions are OK by me. The difference in speed one sees is pretty much only for the anally retentive, it is so minimal.
- emerge -k (packagename)
This must be pointed out before the normal Gentoo FUD starts getting thrown around. Also, before anyone slams Gentoo, they should read and learn: Dispelling the myths of Gentoo Linux, an honest reviewCvswdsf
free ipod and free gmail!
Most package systems allow you to "roll your own" packages from the software you build from source. I use Slackware myself, so I first install my apps into a "staging" directory and build my package from there using the makepkg command.
It takes an extra minute of your time when you're installing software but it really helps to keepi track of what software is installed on the system, what files belong to it, keeping track of versions etc.
Personally, I use both binary packages and source. Basically, if my distribution has binary packages, and they fit my needs (recent enough version, etc, etc), I'll just use the packages. Why not? However, if I do decide I need to build something from source, I like to use GNU Stow to manage my software. Basically, Stow allows you to install your from-source packages in a nice, sane hierarchy (eg: /usr/local/packages/this-program-1.0, /usr/local/pacakges/other-program-2.4), and then Stow does the job of setting up symlinks into the traditional Unix filesystem (typically /usr/local). So, by using Stow, you get the easy management features of packages (minus dependency resolution) for your from-source build software. It's definitely saved my life... and it's especially useful in an NFS environment, as you can export your packages directory and then use stow on the workstations to install individual packages as you see fit. Quite handy. :)
I have a dual processor Athlon MP machine; I use this machine for my Desktop at home every day. I use gentoo because I want the latest and greatest bleeding edge and I want it to runs as fast as possible on my set-up.
Some distro's (mentioning no names) still build for 386 and I've come across distros that only utilise one processor at kernel level let alone build individual packages for multiprocessor support. I prefer to know that im using my hardware to the best of its ability.
However if im installing a server; I'd probably choose a tried and tested distro Red-Hat for a colocated machine which i may never even get to see with my own eyes; Reason being a colo shop will have in house support staff able to fix any run of the mill problems that occur.
For an in house server I might choose Mandrake or SuSe (more likely Suse) and maintain packages that way (last thing you want is to spend several days at work getting a gentoo box up and running!);however, stuff like apache / php etc i often like to compile fresh and configure how i need them. plus it makes patching that little bit easier if you have a specific set up.
Generally speaking anything mission critical I'd try to use packages that have had a fair crack at being tested well after build.
Anything personal you might not care too much about uber-stability like a desktop / research/hacking machine its generally fun to hack about with stuff and compile your own from source.
Electronic Music Made Using Linux http://soundcloud.com/polyp
Which is why Portage is so handy. It builds from source and takes care of package removal. It also offers config file protection so a new version of a package doesn't stomp all over your carefully configured system.
There was Cowboy Neal at the wheel of a bus to never-ever land.
For quite a while I used RedHat and did enjoy the ease that package management gave to a system. For a workstation equivilant, I still agree with this solution in general. However having run through Linux From Scratch (www.linuxfromscratch.org) I see that on a server-class machine, there is a TON of unnecessary bloat. Why should it take a GIG of space , or more, to host just a Web server with MySQL and FTP access? With LFS I can build a specific purpose system and get that footprint down to around 350 to 425mb and that's including the kernel sources being left for recompile and a full compile environment. I've been told that some people can get the same functions stripped down to less than 200mb (this is all of course NOT counting your SQL databases).
At this point there needs to be a big fork somewhere to divource the Linux Desktop from the Linux Server. Linux will do both, but one should not cause issues for the other. If a desktop user wants to run a FTP server, they should be able to. If the server admin wants to have a mail client (pine) or an IRC client (BitchX) installed for accessing information, he should be able to. But these features should be implemented with that specifically in mind. Not installing half a million libs because *maybe* the server admin wants to install addon XYZ for pine and it needs this lib while pine itself doesn't...
Stow lets you install each package in its own directory (i.e., /opt/pkg-x.y.z), then symlinks them into a unified /usr/local tree. Stow -D pkg-a.b.c removes the symlinks for just that package, letting you do a single package uninstall. You can manage the files on a per-package basis, while users can ignore all the details, as it looks like everything is installed in /usr/local/bin to them. Stow provides a simple solution for building packages from source on any UNIX.
You can have the best of both worlds with Gentoo. I began using it about a year ago, and I am sold.
Building from source using Portage is almost as easy as installing a Red Hat package. The community is extremely proactive. (I have only had problems installing or updating a couple of times in the last year, and the problems were remedied within a day or two and the portage trees updated after I submitted a bug report.) And you don't give up variety. The number of ebuilds available in the Portage tree is simply astounding.
I am even using it on my laptop these days and am extremely pleased that it seems to work well as both a server and desktop distribution.
Hope this helps
-- My choice of computing platform is a symbol of my individuality and belief in personal freedom.
It's not really harder, I would argue it is in fact easier in Gentoo. To reproduce a Gentoo system, you need the list of installed packages (either from the 'world' file, or from 'qpkg -i'), and the global make.conf. You can easily emerge any version of any package, so if you don't want the latest tested code, you can request earlier versions of the packages...
icc, btw, is free for non-commercial use on Linux.
The Raven
"But the installer has a *long* way to go"
What installer? Gentoo's only official "installer" is the install documentation.
In my opinion if Gentoo wants to gain a larger user base it needs one. But I definately learned a lot from installing it without a pretty gui installer.
which is why you should always save the output of "make install" somewhere. I keep mine in /usr/local/install_logs
Sure, like any distro, an install will blow here and there due to dependencies, but, for the most part, I find it rarely happens with Gentoo....and makes the whole process so easy to do.
Light travels faster than sound. This is why some people appear bright until you hear them speak.........
I build the mission critical programs from source code, and just let the rest be installed as binary packages. I build from source even if I don't need to just to be sure I won't have extra unexpected issues should I ever need to actually make modifications to source and rebuild. I really don't have very many local modifications, but I'm prepared just in case.
Additionally, I do this all on one master machine (with a backup of it kept live on another machine), build binary packages of my own from my source builds, and install those packages on the actual servers. That way I have even more consistency, though at the cost of ultimate optimization. But I think it is better to be able to quickly reinstall a machine, as well as use checksum verifications that there are no trojans.
I use Slackware, but this could be done with most systems, including FreeBSD, Linux (most distributions, including Debian and the RPM based ones), NetBSD, OpenBSD, and even Solaris.
now we need to go OSS in diesel cars
It's generally more expensive to build hardware than to buy it. I work for DoD and buy about a zillion computers a year. My organization has ~2000 employees and PCs are on a four-year replacement cycle. In order to build machines in-house I'd need at least one additional full-time employee (cost about $70K including benefits) and the space to build the machines.
Right now I'm *buying* computers from a major manufacturer - 3.2GHz, Intel, 768mb RAM, 40G hard drives - perfect corporate machines - for $907 each. The major manufacturer guarantees hardware compatibility for 36 months so my existing sysprep loads will work, provides 36 month onsite warranty support and will inflict my image on these PCs for free. You can't build 'em that cheap.
I just bought a bit more than 500 machines this year - the full-time employee alone would add at least $140 to the price of each PC you built and I'm a bit skeptical that you could build and support those machines with only one person.
In short, you can't build the same PC, guarantee hardware compatability, inflict a standard load on them and provide worldwide onsite warranty support for anywhere near the $907 for each unit I just bought.
we see things not as as they are, but as we are.
-- anais nin
...unless you're referring to the limitted selection on the gentoo cd's, then no, you can't use binary packages unless you've pre-built them yourself.
l ?part=2&chap=2#doc_chap3 :
/usr/portage/packages/All directory, while the source code of the packages is placed in /usr/portage/distfiles. If you have finished installing a package you can remove the package or source code from the respective directory. However, you might want to keep the package/source code of the latest version, just in case you want to reinstall the package (so you don't have to redownload it). ...
/usr/portage/packages/All if the package and the version of the application you want to install match.
/etc/make.conf.
1) if your mirror doesn't have binaries, add one that does to PORTAGE_BINHOST (check with #gentoo or gentoo forums for urls)
2) emerge -k foo that'll emerge the binary package of foo.
more info from Gentoo's FAQ http://www.gentoo.org/doc/en/handbook/handbook.xm
2.c. Maintaining Software
Building or Prebuilt?
Gentoo provides ebuilds, the Gentoo packages if you like. But when you want to install such an ebuild, you can choose between building the package and using a prebuilt package. But what are the advantages/disadvantages of both approaches, and can they be used next to each other?
As you probably have guessed, building packages takes a lot of time (especially if you have little resources or want to build big packages, such as KDE, OpenOffice.org, etc.). By building the package, you can use the USE setting to tweak the package to your system. Of course, you can also define high optimization options (in the CFLAGS and CXXFLAGS variables) to compile the package with.
Using prebuilt packages improves the installation time (as no more compilation is needed), but you will lose the advantages of the USE setting and the CFLAGS & CXXFLAGS variables.
As previously stated, prebuilt packages are stored in the
Installing Prebuilt Packages
When you want to install a prebuilt package, you should use the --usepkg option (-k in short). This will use the binary package available in
Code Listing 18: Installing a prebuilt package for gnumeric
# emerge --usepkg gnumeric
If you want to use the binary package, even if the versions don't match, use --usepkgonly (-K in short).
Code Listing 19: Installing the prebuilt package for gnumeric
# emerge --usepkgonly gnumeric
If you don't have the prebuilt package on your system yet, you can have emerge download it from a mirror, defined in the PORTAGE_BINHOST variable declared in
To download the binary package in case this package doesn't exist on your system already, use --getbinpkg (-g in short):
Code Listing 20: Downloading and installing a prebuilt package for gnumeric
# emerge --getbinpkg gnumeric
This will download the package and the package-related information for you and install it on your system, together with the dependencies.
CB
free ipod and free gmail!
I prefer to install everything from packages when I can. For stuff that I have to upgrade frequently -- usually server processes that need security patches -- I do it from source, partly because I prefer not to wait for a package to become available, but mostly because it saves me from the tangle of dependencies that come with packages. (The difference between RPM hell and DLL hell, as far as I'm concerned, is only that you don't have to pay for the privilege of RPM hell.)
In general, I haven't found that there is any real optimization benefit in compiling from source in most cases -- the kernel itself and Apache being the primary exceptions. I'm sure it's there, but it's small enough to be unnoticeable in most cases, and therefore not worth my hourly wage to futz with when I could be doing something that actually generates revenues.
Mind you, this is at work. At home, I tend to prefer compilation, but that's just because I like screwing around with the source.
Proud member of the Weirdo-American community.
I've been building from source since the late 80s. What has happened is, I've gotten old, and tired of the same ol' repetition and screwups. These days, I always try the Deb package first. 95 times out of 100, that works fine. Even if it doesn't, the infrastructure to build is typically installable as Deb packages.
It's not even the compile time that's so significant. It's the pain of figuring out somebody's config/build system, and the even greater pain of configuring the thing once its installed. Deb packages make these problems mostly go away.
Go ahead and build from source if you like. Someday you'll get old too.