Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Build From Source vs. Packages?

Cliff posted more than 10 years ago | from the what-do-you-do dept.

Unix 863

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?"

Sorry! There are no comments related to the filter you selected.

Personally (4, Interesting)

jwthompson2 (749521) | more than 10 years ago | (#8715987)

I do a bit of both. I predominantly install items from packages, when available, for testing and review of something new that I am interested in. Once I establish whether what I have been playing with may be useful for some particular purpose I will research the source build options. If there are specific optimizations that can be made for my system's hardware or pre-installed software I will then look at installing from source in order to leverage those optimizations, but if there is no advantage to compiling the source due to lack of any worthy optimizations then I will install from packages any time I want that software.

That is my way of handling things, do what fits your needs best, that's why we have this option.

Re:Personally (2, Interesting)

LoveTheIRS (726310) | more than 10 years ago | (#8716131)

I run Fedora Core 2. The packages I have downloaded have not always been compiled to do everything that I need. Also, the packages sometimes are a couple revisions behind so in that case I tend to build from source. I am ambivalent to Gentoo because on one hand you can get code optomized only for your machine, but on the otherhand you have to wait for days for a working system. I'd say that the best for you would be to start your system out with the packages and then compile your own rpms(or whatever else you are using) (I have never been successful at doing so but it is supposed to be easy,) then you have the best of both worlds, compiled code with everything you need and all the files installed are managed by a rpm database. My 2 cents.

Re:Personally (5, Interesting)

allyourbasebelongtou (765748) | more than 10 years ago | (#8716163)

In short: I have to agree--I do a bit of both, too.

The main thing I encounter that keeps me from using them all the time is the need for specific add-ons that are available as part of packages but are available when rolling-my-own.

As an aside, there are certain bits that I just prefer to compile myself for any number of reasons

That said, there are other bits of software that are pretty generic items that the packages make *trivially* easy to work with, and where compiling those same things from scratch--particularly on older hardware--makes you get a bit long-in-the-tooth waiting for the compile to return.

To me, this is truly one of the ultimate beauties of open source: you're not stuck with pre-built, but you can leverage it when it makes sense.

Beyond personally - professionally (4, Insightful)

Roadkills-R-Us (122219) | more than 10 years ago | (#8716183)

I agree. What the professor wants is a readily supportable, production environment, and tat's what you should supply. That means packages wherever possible. IFF there is a clear need, build from source- a 5% speed optimization may not be worth it (that's the prof's call). A 50% speed improvement (unlikely, but possible) would probably be worth it (prof's call). Otherwise, I'd only build from source when there was not a trustworthy package available, or to add features, fix bugs, etc.

I've been in both your and the prof's position, and this is generally the best bet. It'll make the prof's life a lot easier when you're gone, too.

Support (5, Insightful)

ackthpt (218170) | more than 10 years ago | (#8715993)

After you've gone it will be easier for the prof to get support on a package than something custom. From experience, the less something you have resembles what tech support is expecting the more finger pointing and the less gets done.

As often as I've lamented how much employers spend on PC's, vs build them themselves from parts, they would rather not have to rely on someone in-house to support hardware.

One word for you... (4, Informative)

TwistedSquare (650445) | more than 10 years ago | (#8715995)

Gentoo! (Combines the best of both worlds)

Re:One word for you... (4, Informative)

Anonymous Coward | more than 10 years ago | (#8716009)

Which of course was copied from FreeBSD...

Re:One word for you... (5, Funny)

micromoog (206608) | more than 10 years ago | (#8716109)

. . . which of course is dying.

One thing you'd better have... (0)

pinkUZI (515787) | more than 10 years ago | (#8716037)

Time on your hands.

Re:One thing you'd better have... (1)

rbolkey (74093) | more than 10 years ago | (#8716121)

Only as far as needing to use large applications you're installing. It's not like you need to monitor the computer as it's emerging. And after that first emerge, it's really just a few ebuilds here and there if you update it every couple weeks.

Re:One thing you'd better have... (1)

jobeus (639434) | more than 10 years ago | (#8716218)

Or a fast computer... :)

Entire Gentoo System built from scratch with ~230 packages... ~9 hours on an Athlon64 3000+. ;)

Re:One word for you... (0, Troll)

TedCheshireAcad (311748) | more than 10 years ago | (#8716071)

But why would you ever use Gentoo in a production environment?


Re:One word for you... (1)

hkroger (666340) | more than 10 years ago | (#8716226)

Why not? It's a distribution like any other.

Both? (2, Interesting)

jjares (141954) | more than 10 years ago | (#8715997)

I actually make my own gentoo ebuilds and build everything emerging them... so, both.

Re:Both? (1)

revividus (643168) | more than 10 years ago | (#8716135)

I'd have to agree, though I haven't created an ebuild of my own yet.

I don't think I've installed more than one or two binary packages on my gentoo box -- but an ebuild is so nicely packaged that I don't feel typing "emerge -u foo" really qualifies as me building everything from source... Really, someone else did the "hard" stuff (working out dependencies and deciding which directories to save things in, for example) for me.

Re:Both? (1)

jjares (141954) | more than 10 years ago | (#8716209)

Actually, building gentoo packages is VERY easy, it's the thing I like most about it. Most often than not when I need a new package (for instance, pam_pgsql) I just get a similar one (pam_mysql) and change a few things where it is needed. Either that or check [] to see if someone already did the hard work. This [] is a really great reference.

test (-1, Offtopic)

Anonymous Coward | more than 10 years ago | (#8715998)


Gentoo is something of a middle ground. (5, Insightful)

Novanix (656269) | more than 10 years ago | (#8716000)

Gentoo [] is a great OS as instead of having binary packaged systems, it builds everything from source but can build it effeciently and automatically. In addition it can allow you to just use it to manage the source and you compile it yourself. If you were dealing with many systems you could setup your own gentoo sync server and distribute custom copies of various packages exactly to your specs and compiling details. In addition it can easily determine dependencies, and even install them for you if needed. Gentoo is kind of like a bare bones OS that simply makes it easy to install whatever you want and rather helps shortcut the process of dealing with installing things by compiling things for you.

Re:Gentoo is something of a middle ground. (5, Informative)

Chuck Bucket (142633) | more than 10 years ago | (#8716094)

Thanks for the very good points and explaination of Gentoo, but *please* remember, you CAN use binary packages with Gentoo as well:
  • 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 review []


Re:Gentoo is something of a middle ground. (1)

andrew_j_w (630799) | more than 10 years ago | (#8716133)

> instead of having binary packaged system

That's not quite true, while building from source is an important part of Gentoo, Portage has full support for binary packages. A stage 3 GRP install, which only uses pre-built packages, will get you installed very quickly.

Portage also has support for building a binary package when you compile from source. In a situation like this that would seem like the ideal solution - build from source once, and distribute the binary package to all servers (assuming they're similar)


Re:Gentoo is something of a middle ground. (1)

Brian Blessed (258910) | more than 10 years ago | (#8716208)

Something I've been wondering about Gentoo is: How does it cope with several source packages having different dependencies?

- Brian.

Who are these people? (5, Insightful)

bperkins (12056) | more than 10 years ago | (#8716004)

While building from source can be fun, and necessary sometimes, I don't think it makes sense. You spend far too much time tweaking minor issues, and lose sight of major problems.

One problem that I've noticed is the fact the build from source people tend to install things in a way that's completely different than anyone else. This means that anyone who tried to maintain the machine is hopelessly lost trying to figure out what the previous person did. OTOH, When (e.g.) RedHat does something weird, the explanation and fix is usually just a few google queries away.

Most (all?) package formats have source packages that can be modified and rebuild in case you need some really special feature.

Source and un-install (5, Insightful)

KenSeymour (81018) | more than 10 years ago | (#8716102)

I would have to agree about using packages. One gripe I have about building from source is
that most packages do not have "make uninstall".

With packages, you have a much better chance of removing all the files that were installed with the packages when you need to.

Re:Who are these people? (1)

eln (21727) | more than 10 years ago | (#8716110)

I used to build everything from source before I discovered the joy of Gnome. The documentation situation has probably improved since then, but back when I first tried it, it was a mess of downloading, running configure, downloading some dependency, running configure on the dependency, finding out the dependency had its own dependencies, and on and on.

Most projects aren't that severe, but packaging systems (good ones anyway) take care of all the dependencies for you, so it's painless. Unless you need some non-standard feature that isn't usually compiled in, use the packaging systems. If you do need something that isn't by default included, most distributions have source packages available.

It used to be that the popular packaging systems were pretty badly broken, missing dependencies, or installing dependencies that broke other programs, but they're a whole lot better now. I really see no particular reason not to use them, unless you just want to look "hardcore" by giving yourself a lot more work than necessary.

Re:Who are these people? (5, Interesting)

Anonymous Coward | more than 10 years ago | (#8716117)

Speaking of RedHat doing something weird... RedHat managed to _rename_ p_pptr to parent in task_struct in the kernel. How did they manage to get away with something like that? If there are custom kernel modules that happen to want to use p_pptr, then everything breaks!

OS is from a package (2, Insightful)

DR SoB (749180) | more than 10 years ago | (#8716007)

Your installing a OS from a package, so why not applications? Old programmers moto "Don't re-invent the wheel".

Re:OS is from a package (1)

Phekko (619272) | more than 10 years ago | (#8716113)

What, something like 'friends don't let friends bootstrap?'

I guess it's your sig that made me think about that. But the point is valid I think. You don't HAVE to install it from a package if you don't want to.

Re:OS is from a package (1)

happyfrogcow (708359) | more than 10 years ago | (#8716177)

don't reinvent the wheel, but make it better. Or: compile from source with optimizations to take advantage of your processors performance.

bla bla bla premature optimization. ok fine, compile without optimizations, see if it works, tweak later as desired.

Re:OS is from a package (-1, Offtopic)

Anonymous Coward | more than 10 years ago | (#8716202)

Your installing a OS from a package, . .


I can't believe the laziness and outright stupidity of people posting on this board. These are the same people who can't see why Joe Average isn't using Linux because "it's so much better" yet can't use proper English.

If this poster, and the others who use the same incorrect spelling, are any indication of the quality of IT personnel in this country it's no wonder the jobs are being moved overseas.

first post (-1, Offtopic)

Anonymous Coward | more than 10 years ago | (#8716008)

I am lame. haha.

Built from source is better (-1, Redundant)

Anonymous Coward | more than 10 years ago | (#8716015)

Wooho i'm first. Hi Jeff!

BOTH (0)

Anonymous Coward | more than 10 years ago | (#8716016)

I tend to install from source when I don't have root access but package managers can make things nice and easy.

Whatever get the job done (5, Interesting)

untermensch (227534) | more than 10 years ago | (#8716023)

If you are working for someone else, maintaining servers that are intended for peforming specific tasks, then I think the best solution is to do whatever is most efficient at performing those tasks. If you really don't need the peformance gains brought by compiling from source (and you probably don't) and it's going to take you a long time to do the compiling, time that could be better spend actually doing the research, then it's not worth your effort. If however the compiling doesn't affect the user's ability to be productive and that is what you as sysadmin are most comfortable with, then it seems reasonable that you should be able to maintain the boxes however you like.

Use Gentoo (1)

kanaka (9693) | more than 10 years ago | (#8716025)

Use Gentoo ( then you get the advantages
of both. Compiled from source the way you want,
and package management that is really simply with
automatic dependency resolution, etc.

yup (2, Insightful)

rendelven (687323) | more than 10 years ago | (#8716027)

I personally try to use the packages when I can. It makes it a bit easier for myself to keep track of everything.

It's all in what you need to do. If you need those optimizations or special build options that aren't in the package, go ahead, it's what it's there for.

Gentoo (1)

DarkBlackFox (643814) | more than 10 years ago | (#8716034)

Not to sound like a Zealot, but I'm enjoying the convenience and performance of both worlds through Gentoo's portage system. It manages dependancies as well or better than traditional packaging, and compiles from source ensuring optimization and performance.

Upgrades and multi-admin prefer packages (0)

Anonymous Coward | more than 10 years ago | (#8716036)

I have found that using a package manager helps with systems that are expected to last a long time and have multiple administrators. I can quickly find out what is installed, when, what has changed from the original files, etc.

Simply (5, Insightful)

AchilleTalon (540925) | more than 10 years ago | (#8716038)

build packages from source!

Many sources include the SPEC file required to build the package.

Re:Simply (1)

DaneelOlivaw (203330) | more than 10 years ago | (#8716170)

That's what I do. Works out rather well.

OSX (4, Interesting)

artlu (265391) | more than 10 years ago | (#8716041)

I used to be a huge debian fan because of apt-get and the direct install of packages, but I have migrated to OSX and find myself needing to build packages from scratch to work correctly. However, I will never hesitate to use Fink as much as possible. I think for 90% of what gets installed the packages should be fine, but if you know that there are certain optimizations that you can implement, why not build from scratch?

Well... (1)

Thaidog (235587) | more than 10 years ago | (#8716042)

Not everything will work "out of the box" or package in some cases depending on your config

Packages (-1, Offtopic)

Anonymous Coward | more than 10 years ago | (#8716043)

You don't know more than a professor.

Packages are best (1, Funny)

Anonymous Coward | more than 10 years ago | (#8716044)

Packages are the best to work with. There is too much room for error with build from source. Besides that's what you boss likes, so you better love it. Learn young man, learn. If the boss likes it, you love it. Packages!

Real Men.. (1)

grub (11606) | more than 10 years ago | (#8716045)

cat >> filename
chmod a+x filename

How about both? (1)

sebol (112743) | more than 10 years ago | (#8716046)

In RPM's Distro, I always rebuild .src.rpm and install binary generated.

My experience (3, Interesting)

Jediman1138 (680354) | more than 10 years ago | (#8716048)

Disclaimer: I'm only 15 and am a semi-newbie to Linux.

Anyways, I've found that by far the easiest and most simplistic and time-saving method is to use rpms or debs. But of any distro, Lindows has it down to one or two clicks...though, they're software database subscription is a serious money leech..

If it was up to me, source would always be an option to use, and the install process for rpms and debs would be one click and automatically update themselves into Menus and such..

Just a few thoughts..


Re:My experience (-1, Troll)

Anonymous Coward | more than 10 years ago | (#8716136)

You might try this program [] which will auotmate the process of adding new program entries into your gnome/kde/windowmaker menus.

Read the README to find out what you need to add to your to get this to work!

Five words (0)

Anonymous Coward | more than 10 years ago | (#8716050)

./configure ; make ; sudo make install

It isn't necessary these days, imho. (1)

RLiegh (247921) | more than 10 years ago | (#8716051)

The only real reason to roll your own before was for speed or to add components into your kernel. However, these days most OSs come with modules (or lkms or what have you) so compiling a kernel is unncessary, and machines are fast enough that any speed increase will be negligble (and will be offset by a potential lack of stability)

So, I just install packages and go.

--No-Deps (5, Insightful)

Doesn't_Comment_Code (692510) | more than 10 years ago | (#8716055)

My biggest grievance against packages is the dependacy fiasco. For instance, I have Red Hat at work. And the majority of the programs are .rpm's. Well there was a certain program that I could only get as source, so I compiled and installed it. It turns out that it was required as a basis for other packages I wanted to install. But when I tried to install those, it didn't recognize the prerequisite programs because they weren't installed via rpm.

I don't care for the dependancy model of packages, and I'd much rather install programs myself. That way I know I'm getting the program compiled most efficiently for my computer, and I don't have to worry about dependancy databases.

Re:--No-Deps (4, Insightful)

idontgno (624372) | more than 10 years ago | (#8716225)

I don't care for the dependancy model of packages, and I'd much rather install programs myself. That way I know I'm getting the program compiled most efficiently for my computer, and I don't have to worry about dependancy databases

That just means that you'll have to store the dependancy databases in your head. A release of a particular software package, whether it's a package or a tarball of source, depends on other software. Always. "config" goes a long ways towards working that out, but if it doesn't work automagically you're going to have to take it by the hand and lead it to wherever your copy of might happen to be.

I've just started using yum for RPM management and I'm already liking it a lot. At least dependency management seems a bit cleaner and more automatic.

My experience (5, Informative)

TwistedSpring (594284) | more than 10 years ago | (#8716057)

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.

Source for server apps... (1)

millahtime (710421) | more than 10 years ago | (#8716059)

I prefer to use source build for server apps and packages for OO, gimp, etc. I have found that for servers a source build will runn better under heavy use conditions. For desktop apps I have found little or no difference.

Run Debian (2, Insightful)

jchawk (127686) | more than 10 years ago | (#8716066)

Run debian, if you absolutely must install from source you can use APT to get grab the source that you need, compile and then build a deb for it so you're still using the debian tracking system. It really is the best of both worlds.

For most packages though there really isn't a big need to compile from source.

depends on the system (4, Insightful)

Evanrude (21624) | more than 10 years ago | (#8716076)

I used to be a die-hard build from source person myself back when I ran slackware.
Since that time I have gained more experience with production Linux systems.
When it comes to managing production servers, I use Debian and typically only install programs that are in the stable tree.
Every once in a while I have to build a deb from source, but only in rare circumstances.

Now, when it comes to my development systems I am more likely to compile from source rather than rely on the packages to supply me with the latest and greatest.

It really all just depends on what kind of stability vs. "new" features you need as well as ease of managment. Installing a package takes 30 seconds vs. compiling/installing from source can take longer and requires more hands on.

Re:depends on the system (1)

cangeceiro (712846) | more than 10 years ago | (#8716126)

I would have to say that all depends on the flavor of nix i am using, FreeBSD and gentoo make it relativly pain free to install from source, but if i am using a redhat box or some other rpm based distro i tend to try the package manager that is provided with the distro be it up2date, yast, or whatever, before i install from source. I quess ultimatly for me it just depends on my feelings towards the package manager provided with the distro

It's gotta be from source. (1, Insightful)

Hyperkinetic (142875) | more than 10 years ago | (#8716077)

The only thing I use prepackaged are the GNU tools. Everything else is built from source. There are too many compile time options, and building from source eliminates the problem of binarys being linked against a different lib than that is on the system. Plus auditing the configure and makefile before compilation ensure everything goes where *you* want it to.

Depends (5, Insightful)

Richard_at_work (517087) | more than 10 years ago | (#8716081)

I use OpenBSD, which like most of the BSDs has the ports tree, and also has packages. Most of the ports tree are built as packages and are available on the FTP sites, allowing you to either install 3rd party applications from source preprepared for the job, or install the package that has already been preproduced from that port. Best of both worlds, and indeed if you are after customisation and have a number of systems, you can make the changes on one system, and bingo - you have the package ready to roll out to the other systems.

As for what I use? I used to use solely ports, but now I usually grab all the packages when I do a fresh install, and only use ports for what isnt available as a package, as the packages give me no disadvantage.

Packages, definitely. (2, Interesting)

imbaczek (690596) | more than 10 years ago | (#8716082)

Whenever a binary package for Debian is availible, I prefer it to hand-compiled source. First, it has all the Debian patches it needs. Second, it propably installs without a hassle. Third, it's easy to get rid of it, and last but not the least, apt resolves dependency problems without human intervention in 99.9% of cases.

In other words, binary packages work for me :)

From another student... (2, Insightful)

FreakyControl (751781) | more than 10 years ago | (#8716092)

I can tell you as a grad student with 3 years experience working in an engineering lab, packages are the way to go. Not just in software, but generally in most situations. As others have mentioned, you have the ease of use, tech support, and the time savings. While you may eke out a little bit of performance, your time is of significant cost to the lab, with which you can be doing many other more valuable services. Also, as a student, you will likely only be there for a couple of years. When you leave, and something goes wrong, someone else has to sort through what you did to try and fix it.

From source, definitely. (5, Insightful)

mod_gurl (562617) | more than 10 years ago | (#8716095)

If you're responsible for the machines you run how can you abdicate that responsibility by using whatever some package maintainer decides to give you? At the University of Michigan we use Linux from Scratch to manage hundreds of machines that provide everything from web servers to IMAP servers to user Desktops & Laptops. The trick is leveraging the work used to administer one machine well out to hundreds of machines. The tool for this is radmind [] . Radmind doesn't require that you build your software from source, but it leverages the work you put into one machine to manage all of your machines. It also integrates a tripwire with your management software which means you can detect unwanted filesystem changes in addition to managing software.

Benefits of Source Based Packages (1)

Zach Garner (74342) | more than 10 years ago | (#8716096)

There's one major and obvious benefit of Binary Packages: they're quick to install.

You mention the optimization and control benfits that come from building from source. Have these benefits been quantified? Is the optimization it provides noticeable? Do you really need the extra control?

For most systems, a hybrid approach where you build from source only when needed works great. It doesn't have to be a "this way only or that way only" situation. Don't like the configuration of a certain binary package, then just grab the source package and build it yourself. Using a source package instead of "./configure; make install" also helps with maintenance (easier to upgrade and easier to keep track of ./configure parameters)

Optimising source is vastly overrated... (1)

rsidd (6328) | more than 10 years ago | (#8716097)

except for stuff like scientific simulations, complex graphics/video applications etc, which you can always install by hand when you want. I'd go with packages when available just because of the time saved in installing them. You won't even notice a difference between -O and -O2 compiler options: most programs spend their time waiting on I/O, not running (run top to see who's occupying your CPU right now).

A bigger issue is compatibility with various packages, whether binary or source. On FreeBSD for example you have the option of either a source-based install via the ports, or a binary package of the same port (via pkg_add -r) when available. The issue is not optimisation or "control": it's whether that package conflicts with the existing packages. Shortly before every release the FreeBSD ports team freezes the ports tree to be sure that there are no major problems; if you stick to that, or say to a release from Red Hat or SuSE, you'll have no issues, while if you're the type who keeps upgrading complex things like KDE to the latest and greatest version, you'll quickly run into conflicts.

The answer is .... (3, Insightful)

Archangel Michael (180766) | more than 10 years ago | (#8716100)

It depends.

If you are advanced enough to compile source code in such a way that it performs better or in a tighter controlled manner, which suits the purposes you need better than off the shelf builds (packages), then by all means, build it from source.

If on the other hand, you don't have a compelling reason to compile the source, then use the packaged product.

I don't know about you, but for most of my servers, the extra configuration options needed to squeeze an extra few percentage points of performance isn't enough to bother running my own compile.

Those that say they review ALL code before compiling for security (backdoors, holes etc) problems are probably lying. I am sure there are a couple people who do.

Basically if you do it just so you can be 1337, you are just vain, as I doubt that most people would see/feel the difference.

Depends what you use them for,... (1)

Creepy Crawler (680178) | more than 10 years ago | (#8716103)

If you want stable, albeit old, use the TESTED GOOD Debian Stable packages. They're old as the hills, and little problems to boot. They just work.

If tyou want something current, but more buggy (desktop or somesuch) go with source-compile like FreeBSD or Gentoo Linux. Looking at a Fedora system where things are kept current AND in working order (unlike unstable in Debian) would be a good idea too, but you risk going in Lib.hell

This is BSD vs Linux argument (3, Funny)

gtrubetskoy (734033) | more than 10 years ago | (#8716107)

Any BSD user will swear by "build-from-source" and talk about how the ports [] are so great (and indeed they are).

And any RedHat user won't really understand what the BSD user is talking about and will just keep on using binary rpms found from google or rpmfind [] . In a desparate moment one will use any rpm that seems to do the trick - nevermind security, PGP sigs, all that stuff...

Seriously speaking, building from source is the UNIX way in my opinion. There is just something very heart warming and satisfying about seeing all the compiler messages scroll every time you install a package. (And try installing the native Java from BSD ports - several hours of pure joy!)

BSD has Packages and Ports (1)

millahtime (710421) | more than 10 years ago | (#8716210)

FreeBSD actually gives you both ways. The ports if you want to install from source and they make it very very easy to do or from packages. It gives you the best of both worlds and makes the source way pretty easy.

Re:This is BSD vs Linux argument (1)

RLiegh (247921) | more than 10 years ago | (#8716224)

Ok, so you get a warm, fuzzy feeling from watching the compiler output of a './configure && make && make install' ... hell, that's about as unix as running the rain program and watching that output.

it's worth mentioning that the BSDs are excellent for pre-packaged packages. adding something like export PACKAGE_DIR=" " and then being able to run pkg_add gnome is IMHO much more the unix way (which is to use several small, simple components to do a larger job.)

Depends on the Distro (1)

McSpew (316871) | more than 10 years ago | (#8716112)

As a Debian user, I prefer to install from Debian packages whenever possible. Why? Because Debian's QC is virtually unmatched. Of course, there are times when Debian's constitution or the applications' licenses (or both) forbid packaging certain kinds of applications (official Sun Java, for instance). In those cases, I either have to go get an RPM or a tarball and work through getting the app up and running manually.

It's much easier when I can count on Debian's package to install the app and ask me the appropriate questions required to get the app up and running. There's no comparison to the ease of getting MRTG up and running on Debian via packages vs. installing from a tarball.

However, my experiences with RPM-based distributions haven't been as good, and I'd be more tempted to build from source in those cases.

Packages (1)

TyrelHaveman (159881) | more than 10 years ago | (#8716118)

Although there certainly may be some advantages to having compiled the source code specifically for your machine, I usually don't imagine a huge performance increase over pre-compiled packages. Obviously, packages are also a lot quicker to install than source code. I usually find this a major motivation. I don't think the majority of users will benefit highly from compiling the software. In some resource-critical situations, however, I can imagine I would be more prone to compile.

Source Packages (1)

Perl-Pusher (555592) | more than 10 years ago | (#8716119)

Allow you to tweak the parameters, optimize for your architecture and still easily remove and or upgrade the package.

Use the Source Luke (2, Funny)

mike collins (576863) | more than 10 years ago | (#8716123)

I always do.

a matter of time? (1)

M1FCJ (586251) | more than 10 years ago | (#8716124)

Do you want to be on the cutting edge of the software or is something labelled "stable" is good enough for you?

Basicly that's the only reason you would like to build from source. Otherwise, especially if you are dealing with a large number of packages, compiling from source becomes just a waste of time. Usually I download both binaries and source, install the binaries and compile the package for my own entertainment. Also this means if there is a bit the package builder screwed up or you want to change, it is a simple matter to patch the binaries.

Packages When Available (1)

LilMikey (615759) | more than 10 years ago | (#8716134)

I prefer packages when available for 2 reasons...

First, I'm lazy and package managers like apt, urpmi, and yum make installing software with multiple complicated dependencies easy. Finding the source for the bazillion requirements and building all of them in the correct order (taking care of their requirements as well) doesn't sound like a productive use of time to me.

Second, removing a package doesn't require keeping the sources around. It may be possible that in whatever version of the source you can find the removal doesn't quite work right with the older version you have installed. I've never run into this problem, but hey, it could happen.

Why choose when you can have both? (4, Informative)

Spacelord (27899) | more than 10 years ago | (#8716141)

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.

Source or Package? (2, Informative)

bogtrotter (19072) | more than 10 years ago | (#8716143)

There's one overriding detail that you should consider.
You're working for the professor. He's your customer. The customer makes the rules. The old saying "The customer is always right" is true. Most people don't know there's a second half to the saying. "The customer is always right, or he's no longer a customer", meaning if you don't do it his way, he could easily fire you, and rightfully so.

Staight forward answer actually... (0)

Anonymous Coward | more than 10 years ago | (#8716144)

Use packages as long as long as they meet your needs, and compile from source when they don't.

If you have time to burn, go ahead and compile from source every time. But for most people this is a tad too slow.

How about SRPMs? (0)

Anonymous Coward | more than 10 years ago | (#8716145)

Aren't SRPMs, or source-RPMs, pretty much the best of both worlds?

Build (0)

Anonymous Coward | more than 10 years ago | (#8716147)

I manage about 50 Linux boxes. Typically if there's something I need to have severe performance on, I'll build from source then make a package from our build. Then I can just replicate it to the other machines.

I do this especially with kernels, because frankly the RPM/DEB/TGZ/ETC ETC ETC builds suck.

do both (1)

oddpete (710031) | more than 10 years ago | (#8716149)

build your own packages from source. Ten servers are managable, but if you want to scale upwards, building from source for 20-50 servers becomes unruly. Just make your own packages using your favorite packaging tools, be it .deb, .pkg, .rpm, or whatever.

I highly recommend cfengine to manage your configuration files, though. Makes scaling up of servers very easy. Managing 10 servers is the same as managing 500.

I use oddpost [] because I am cool, and because it will soon have Mozilla support!.

Stow! (5, Informative)

Abcd1234 (188840) | more than 10 years ago | (#8716150)

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. :)

Source only, of course (1)

mehaiku (754091) | more than 10 years ago | (#8716151)

I install from source only, but then I use Gentoo. With binaries, you can never be sure you will get the app like you want it. Take Mplayer for instance. I am sure that Debian, Fedora, Mandrake, etc have this package in some form or another. But will that binary app be able to play all video formats, including windows media files, real player & quicktime files? Doubtful. If you install it from source though, you can be sure it will play ALL formats you choose.

Building from tarballs can be problematic (3, Interesting)

Theovon (109752) | more than 10 years ago | (#8716160)

I've often had a lot of trouble building programs from downloaded tarballs. Besides mysterious dependencies that I can't track down, sometimes things just don't compile, or they crash, or they produce errors of other sorts. But in many of those cases, I could download, say, an RPM of supposedly the same package, and it would install just fine.

On the other hand, I've never had any problems. Emerging new packages deals properly with all dependencies, and things always compile correctly. And there's like a review process where packages are first added to portage as "unstable" and then once they have passed everyone's criticism, they are added to "stable". So far, the only "unstable" package I've decided to emerge was Linux kernel 2.6.4, and that all worked out brilliantly.

Also, if you have a cluster of computers, you can do distributed compiles with, I think, distcc and/or some other package. Gentoo documents this VERY well. Plus, if your cluster is all identical machines, you can build binary packages once and then install them onto all other machines.

BTW, Gentoo isn't for everyone. The learning curve is STEEP. I had to start from scratch and do it all a second time before I got everything right. (Although I am a bit of a dolt.) Setting up is complex but VERY WELL documented. Only once you've finished building your base system does the extreme convenience of portage become evident.

Also, there are still a few minor unresolved issues that no one seems to have a clue about.

Dependancy issues (1)

jobeus (639434) | more than 10 years ago | (#8716171)

Building from source almost always results in less dependancy issues than using packages. If a certain package was build against a specific version of a library, and you've got a newer or older library installed, you could be hooped.

Building from source lets you link against the libs you have installed.

an advantage of packages on Debian (1)

mrmez (585359) | more than 10 years ago | (#8716172)

I really love being able to tell Debian "hey, please install this package" and having it reply "well, I can do that but only if I update another 150 packages in order to resolve various dependencies between them. Is that hunky dory?" with my being able to reply "have at it!" Of course, there are time when I have a reason to build from source, but that's rare; it's also ill-advised since my clients' in-house IT staff needs to be able to maintain and build boxes on their own when I'm not around. Another advantage is the saving of time - it's much speedier to type "apt-get install BBEdit" (and with my PowerBook out of commission I certainly wish that were possible) than to manually find, DL and install source.

Packages (1)

Aggrazel (13616) | more than 10 years ago | (#8716178)

Packages, production machines don't need compilers on them that way. The slimmer you can keep your production boxes, the more sane they are to manage, IMO.

Gentoo and Red Hat Enterprise (1)

anthonyclark (17109) | more than 10 years ago | (#8716180)

I use both Gentoo and Red Hat Enterprise;

Gentoo is great not because of the source compiling that (allegedly) squeezes a couple of extra 'horsepower' out of the machine. It's great because of the USE variable; I can for instance compile gcc with or without java (gcj) support by setting 'java' or '-java' in my /etc/make.conf. I use gentoo on one machine only, my personal web server.

Red Hat enterprise is great for creating a standard base install and using standard packages with very fast bugfix support. redhat's management website only works because all the packages are standardised. The recent OpenSSL DoS issues were fixed on all 12 of my servers by using a couple of clicks on redhat's website. I couldn't imagine compiling 12 source packages on different machines (we use a combo of x86 and opteron servers).

If you're going to be running one or two boxes, choose gentoo. Otherwise choose Red Hat.

Gentoo for both (1)

nagora (177841) | more than 10 years ago | (#8716181)

The portage system on Gentoo is worth using regardless of the question of source or pre-compiled and is the easiest system to maintain that I've found so far. I would suggest sharing the portage directory over nfs/samba etc, using one turbo-nutter-bastard machine to download and make pentium binaries and have all the slave machines just install those binaries, so: both really.


Multiple Machines, goody-good (1)

SoTuA (683507) | more than 10 years ago | (#8716189)

I think that the benefits of the source-based approach are best reaped from a setup of multiple machines, with not-too-different hardware.

At the University, the Sysadmins rolled out gentoo... basically they optimize, compile on the idle cycles of a big server, and roll out those binaries to the workstations. Great setup.

Packages are better... (1)

stm2 (141831) | more than 10 years ago | (#8716190)

...when it works :)
I tend to use first RPM (I have 2 boxes, a RH server and a Mandrake), but when I get to much dependencies issues, I go for sources.
I think that in an ideal world, RPM, Apt-get or whatever is the way to go. But I often find issues that makes me install from source (some programs, like academics one, are in source only format :(

yes, hybrid (2, Interesting)

CrudPuppy (33870) | more than 10 years ago | (#8716193)

build packages from source exactly how you want them , make a tarball of that, and then use ssh and key trusts to shoot them out everywhere (this coming from a person who maintains almost 1000 servers)

it works very well.

uh oh... (-1, Flamebait)

Anonymous Coward | more than 10 years ago | (#8716195) comes the flood of Gentoo (Geek E1337 Noobs Trying Orgaziming over Optimization) ... *duck*

Simpler is better (0)

GSPatton (453002) | more than 10 years ago | (#8716196)

I find that for the overwhelming majority of installations, installing from packages is FAR simpler. The drawbacks of "less optimization and control" is far outweighed by saved time. Just look at the popularity of RPM's! If we had to roll our own installs from source for everything...
Strive for efficiency and simplicity, you won't regret it.

Progress to Linux on the Desktop.... (1)

tamuct01 (726718) | more than 10 years ago | (#8716197)

...will require the ease of some form of package management. I can see the benefits and challenge of compiling from source, but joe user will not take the time to compile from source. just my $0.02

For most people (1)

jeffkjo1 (663413) | more than 10 years ago | (#8716207)

For most people, building from source is entirely not necessary. Most popular programs are available as binary packages for any given distribution (and 90% of the time binaries for another distribution will work.)

Building from source for most programs yields little to no optimization, and if you ever want to uninstall the program that was built from source, you have to save your build (or, as I have had to do in the past) build the program again only to uninstall it.

build your own packages (1)

pyros (61399) | more than 10 years ago | (#8716213)

Assuming you don't use Linux from Scratch, learn the packaging format of your chosen distro. If you're just building from source to optimize but you're not actually changing the default build options or anything, than the vendor-provided packages are likely as optimized or better than installing from source. They typically patch the source to play well with the rest of the system defaults and include scripts to integrate with the system admin/config philosophy. If you have specific patches you need to apply and want build options other than the defaults, then take the source package your vendor provides, patch it and change the build options, and build it into a binary package.

The benefit of packages is that it is far easier to audit the files on your system, remove or upgrade a package, and install the same thing on all your servers. The great thing about packages is you can customize them just as much as you can a source install.

Depends (1)

FooManChuYouMoo (183196) | more than 10 years ago | (#8716215)

If there's a lot of packages maintained often and well for whatever OS I'm using, I see no reason to go with source.

However, if there isn't a package available, or it's out of date, obviously I have to go with source.

If I were your prof (2, Insightful)

October_30th (531777) | more than 10 years ago | (#8716216)

If you'd make your case simply "It's the right thing to do" that would definitely not convince me - in fact, such argumentation would only aggravate me. It smells like an ideological argument.

If you could demonstrate that installing/upgrading from the source results in a quantifiable improvent in maintenance or performance over a pure binary distribution, I would consider it. If there are no existing reliable benchmarks, but you'd make a good case, perhaps I'd let you turn your own workstation into a demonstration system.

Anything else. No way. If it works, don't mess with it.

I run Gentoo at home and, while updating with "emerge" is kind of nice, I've yet to find any compelling reasons why it'd be better than up2date or apt-get. There really are no measurable performance or reliability advantages.

you have to decide (1)

pair-a-noyd (594371) | more than 10 years ago | (#8716217)

If I use packages, they are easy to uninstall (if need be), if I build from source and I have to uninstall them, it's not quite as easy but building from source gets me better performance..

Six of one, half a dozen of the other...

enterprise linux (1)

rapiddescent (572442) | more than 10 years ago | (#8716223)

whilst compiling from source is fun - it is an action that does not scale well as the enterprise grows. I have just managed to get RedHat [] 3.1 AS into my customer site (woohoo!) who was a staunch windows/solaris shop. The reason I use package management is that it reduces risk, reduces management time and install time for our vast array of HP prollie DL380 servers. Our servers are built the same way using kickstart scripts and are hardened the same way.

For me, it was important to demonstrate to management that linux builds were consistant and good quality as well as not increasing the system management cost. I think they would have not gone for linux had we said that we would be building each one from source code. You've got to remember that these guys read Gartner reports that say the Linux distros are "fragmented" and no matter how many times i explain it; they don't get Linux versioning. "So is SUSE 9.1 newer than RedHat 3.1? Which one is Linux 2.6?" ... arg!


Load More Comments
Slashdot Login

Need an Account?

Forgot your password?