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?"
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.
Even if I knew that tomorrow the world would go to pieces, I would still plant my apple tree. -Martin Luther
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.
A feeling of having made the same mistake before: Deja Foobar
Gentoo! (Combines the best of both worlds)
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.
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.
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.
Many sources include the SPEC file required to build the package.
Achille Talon
Hop!
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?
-------
artlu.net
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..
___________________________________________
nothing.can.stop.me.now
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.
Slashdot Syndrome: the sudden, extreme urge to correct someone in order to validate one's self.
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.
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.
~.Evanrude
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.
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.
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.
Agent K: A *person* is smart. People are dumb, stupid, panicky animals, and you know it.
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.
"We can't solve problems by using the same kind of thinking we used when we created them." -- Albert Einstein
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!)
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'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.
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.
I used to run an ISP, built everything from source, but eventually it got to the point where it was un-manageable.
;-)
You end up with different versions, different compile options, upgrades are a mess, and it's hard to support.
Another problem is filesystem pollution. When you do your "make install", it's hard to track what files are installed, and when you upgrade to a new version, you can't be sure it's clean, since you might have configuration files or binaries anywhere on your system.
So, one day, I started to make RPM packages of stuff I needed, and modified existing RPMS, and sent all the patches to the community.
What happened is that Mandrake accepted all my packages, so all I had to do was to install the standard distro, and all I needed was there.
And eventually, I made so many packages that they hired me
But even if I wouldn't work for Mandrake, I'm still sold on RPMs. You have a clean SPEC file that contains the pristine source code, plus the patches, and basically all the instructions to build the stuff. You can specify the requirements, you can easily rebuild on another machine, uninstall the old stuff, or upgrade, with a single rpm command.
As a FreeBSD user, I build almost everything from source using ports. I never install from packages. My reasons for this are many and varied, but basically, I prefer to build software myself, with the precise options I need. When you use packages, you are at the mercy of the packager and their preference for options and optimizations. Several years ago when I used Linux, I often encountered problems of pre-built packages lacking a particular build option, and sometimes installing to odd places, or other strangeness.
And once you've started using packages and package management, it gets harder to introduce source-built software into the same environment without screwing up your dependency databases, or worse - breaking things. So if a package lacks a required option, you really have to build your own package with the option included in order to keep things orderly. That's a lot more work than just installing from source.
I'm not a Linux user anymore (several reasons) but if I were I to go back to Linux, I would use Gentoo, specifically for its Portage system.
So, in my opinion, building from source may be a little more time and CPU consuming, but it is the better option for a controlled, tailored environment.
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
I use fedora, and most often I get the *.src.rpm versions, then tweak the SPEC files as required, build my own binary rpms, and use those. Best of both worlds, IMO.
.nosig
..of time.
It's like the programmer who spends six hours hand-optimizing the inside of a loop that gets called once a day and already executes in 10ms... but ignores the fact that the program takes 20 times longer to run than it should because of an inefficient algorithm. This programmer doesn't know *why* his program is slow, he's guessing, and he will almost always guess badly. This is why profiling was invented.
Look at it this way. Installing from the packages you get the following benefits:
- You save time compiling (multiply this by the number of patches you have to add over the box's life time)
- You save time tracking down dependencies
- You have a standard platform you can re-deploy at will
- You have something that another administrator can work on without asking where you shoved shit.
- You have a package database you can query for version information, dependencies, etc.
- You have an easily available source of "known good" binaries if you have a suspected intrusion problem.
- Depending on the package system you use, you might be able to stay on top of security vulnerabilities with very little (or no) work.
Now, installing from source, you get the following benefits:
- You can pick where the files go (whoopie)
- You tune the performance for your platform
- You can select specific features
- You can de-select specific features to save disk space
The only one which gains you a lot 99% of the time is where you can select specific features which are turned off in the standard package. If you need those options, you build it from source. If you're doing ten machines, though, you build it from source on *one* machine, package it up, burn it, and install it from YOUR package on all ten machines.
Saving a few CPU cycles is never worth saving a man-hour. You can use the man hour more productively on the macro-optimization level. Similarly, you can take the dollars that you would be pay the man and buy a new CPU with it.
The same argument goes for saving a kilobyte of disk space. If found out that any of my guys spent *any* significant time trying to cut less than a gigabyte out of our application footprint, I would give him a footprint of my own, right in the middle of his colon. Disk is cheap. People are not.
If you have an application is which is CPU-bound and running too slow, find out why (profile the system or binary), and build from sources only what you need to make your application conform to the target specification. Or, if that will take too long, just buy more CPU.
Long story short -- tuning of ANY kind should not be done at the micro-level across the board, that's just a waste of time. Tuning should be done by profiling the system as a whole, identifying the constrants, and relieving them. If that requires micro-tuning of a few things, that's fine... but squeezing every last little bit of performance out of absolutely everything is either impossible or incredibly time-prohibitive. And, of course, if you were going to spend that kind of time, you could either buy new hardware with the money (remember Moore's law), OR you example the system more closely at the macro level and come up with a better way to do things.
Do daemons dream of electric sleep()?
For servers, go with something like Debian: good clean integrated system with timely and automatic security updates. Not bleeding edge, but if it's at all a serious server you really don't want it to be.
Desktops, Ports based system all the way. Why? Because with something like Gentoo, it might take several days to compile but you can be assured you're not going to dependency hell anytime soon when you want to try the latest and greatest. Headers and such are installed by default, so you can usually compile something by hand and it will Just Work whereas if you're using three different unofficial package streams and you need to do some upgrade of a simple library somewhere which has an anal retentive versioning and dependency specification, attempting to apt-get that new version will cause your entire house of cards to come crashing down. I lived with Debian on a desktop like that for god knows how many years until I decided "No more". Yeah I have to wait a while with Gentoo but at least I only have to do it once.
Now if you'll excuse me, I have to go reboot 100 systems.
My beliefs do not require that you agree with them.
which is better, vi or emacs? ;-)
Schrodinger's cat is either dead or really pissed off...
Sometimes the exact opposite is true, especially in terms of "community support". For instance, mod_perl, which for some reason Red Hat decided to ship a very early version. The typical response on the mailing lists for mod_perl or any other alpha/beta package RH included usually goes "try it from source, then email us" (that's after someone submits a reasonably complete bug report).
Let's not forget the GCC fiasco and probably dozens of other examples where RH decided to "lead the pack" in terms of version numbers but not stability.
Of course, then there's Debian woody, living in circa-2001 land.
Optimization? Control?
Man, what is this, Gentoo?
Any sane distributor these days builds binary package with reasonable optimizations that won't break across architecture submodels, and occasionally releases binaries targetting submodels (e.g. PentiumPro-specific packages). On many machines, for many workloads, however, the model-specific optimizations just aren't that helpful. Obvious exceptions are floating point math on most platforms (especially x86, where x87 math code is a dog and should be replaced with SSE code if possible) and - I'm told - really slow hardware. (I'll be able to test that once I get these Indys running GNU/Linux.) In my experience, Debian hasn't really felt any slower than my LFS systems for personal use.
So, I'll say this: if you have enough time to build everything you're using, do some careful speed comparisons between your self-built packages and the vendor's binaries. If there's really a significant speed increase, and you need that increase, source is the only way to go for the packages that need the speed increase. Otherwise, it's probably not worth your time.
Unless whatever you're doing is extremely security critical, you can probably deal with the fact that server app foo has features bar and baz installed that you won't use. If you can't, you're probably auditing the source of everything you use anyway, and that doesn't sound like the case, so "control" probably isn't a real issue here either. Control can be found in config files as well as in the configure script.
People say, "but package dependencies suck!" Well, yes, rpm (the program) isn't built to deal with dependencies that gracefully. If it annoys you that much, go install apt-rpm or something, or even Debian (gods forbid). Package management isn't rocket science.
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...
I've been a UNIX sys-admin for about a decade.
My advice is that for a workstation that is managed by an individual you can let the admin do whatever they want, but for any server that has to be stable and maintainable you want to stick with a well maintained package repository and try to avoid 3rd party packages and tarballs if possible.
You have to understand that there is a software stack in most services.
With the kernel and core libs (like glibc) and such at the bottom of the stack, and applications like Evolution at the top of the stack. In between you can have gdb and openssl and various perl modules (in AMAVIS for example) and you have sasl stuff which may be related to pam and openldap and cyrus or wu.... etc..
The thing is that even though all of those various pieces of the software stack may be linked against different libraries on the box, the maintainer of the library code may not have a QA group to co-ordinate regression testing and compatability testing before the latest CVS commit is enacted to fix a bug referenced in a CERT alert.
RedHat and Debian and SUSE and all the others have package repositories, the repository maintainers do an amazingly fantastic job of QA and testing to make sure that new patches don't break your software stack. As an individual you simply can't keep up with that.
For example the Development team that takes care of OpenSSL doesn't backport their bug fixes and security patches to old versions of the code. They just maintain the latest release version and the current CVS version. If you have an old server running IMAPs and HTTPs and SSH and SMTP/TLS and such, and CERT announces a bug in openssl vX.Y, then the OpenSSL development team will certainly release a patch for the latest version which may be version Z!
That might cause you to have to upgrade APACHE or wu-IMAP or OpenSSH or Postfix etc... Those things might then have divergent dependencies that would cause you to go and rebuild half a dozen other packages, and so on and so on. Also, do you remember all the magic flags you used for configure and make? Do you have the same environment variables set today that you did the last time you built PostFix? The possibilities for problems are endless. And if you do have a problem you are kind of on your own since your system will be a unique box. Whereas if there is a problem with a standard RedHat or Debian package, then you can always go to the general newsgroups and chances are there are a dozen other "me too" posts with answers already.
It is much easier to use apt or up2date.
So, unless you have a very good reason for using a tarball on a production server that requires reliability and security and high availability, then you should stick with packages.
If you want to build the packages from source, feel free! RedHat and Debian and SuSE make the SOURCE packages available so that you can dig in and read all about'em. I'm sure the Debian team could use a new package maintainer, if you are addicted to compiling and testing things, check them out.
It's still a smart move if you're building from source. Just package your source. Then you can build the sources under the control of a package manager (like RPM), and install the resulting packages. You get the full benefits of build-from-scratch and the full benefits of using packages.
This is exactly the approach I use. In fact, I'm a bit more strict about it: My policy is that I don't install any software that isn't packaged. If I need to install something that isn't packaged, I'll package it first. If I don't like the way a packager built an already existing package, I'll repackage it.
The bottom line is that creating your own packages (or fixing packages you don't like) is much easier than maintaining a from-scratch, unpackaged installation. Or ten of them.
To get you started, here a couple of RPM-building references:
Don't give up the benefits of source. Don't give up the benefits of packaging. Have them both.
Easy, automatic testing for Perl.
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
No way.
Usually when one builds from Source, they install it to wherever the original developer has it set to by default. Unless you did some heavy patching, the software will very likely be more "true" to the original software then many packages.
RPM's for distributions such as RedHat or Fedors often have to move configuration files all over the place to mesh with the OS properly.
You're more likely to be able to sit down at a strange Linux box and troubleshoot whatever program when it's compiled from source tarballs versus an RPM. Unless of course, you know the RPM, or the RPM doesn't do anything funky.
Considering the stuff is Open Source, and chances are the programs are not under a paid-for support contract, it's pretty safe to say that BOTH methods would have to be supported "In House." And if not, your support contract could very well support the source compiled versions anyways.
I choose the Gentoo way. Everything is compiled from source; it's just nice and automated. Almost never have I run into something where the program had to be modified to fit the distribution.
- It's not the Macs I hate. It's Digg users. -
Actually, you can 'emerge -buildpkg foo' and share packages between machines. if you are managing multiple machines, chances are that you will not have each one with an unique configuration, but only a few profiles.
My arguments on why to use a source-based distribution have been covered in other posts, so I won't repeat them here. I think Gentoo provides a solution that will satisfy both you and your professor: you can use a source-based, custom-built binary distribution.
.ebuild (the file that describes to the system where to find the source and how to build it) requires adding only a single flag to the package compile command, ebuild.
As you probably know, Gentoo is a source-based distribution, but it also allows binary packages. Many (such as Mozilla Firefox) are distributed by Gentoo as source and binary; you can choose to install either. The ability to build a binary package from a source
Additionally, since (if I read you correctly) you're probably using similar hardware for each of your machines, it would be trivial to set up a compile box which would produce binary packages for your other boxen. Packages compiled for your architecture would be faster than most binary-only distributions (many are still compiled for the i386 architecture), and writing a new ebuild is trivial compared to writing a new spec file. (Trust me; I spent a quarter writing a paper on the topic while I was in school, not to mention having had to do it myself in the Real World.)
Finally, Gentoo integrates and tests its packages. Ebuilds come with Gentoo-specific patches, so you don't have to spend the time to make each source package work with the rest. This is probably one reason why your professor likes binary distributions: they all work together, and enough people rely on them that if something breaks, it gets fixed. A package-based Gentoo distribution would allow you to leverage that, while keeping your machines unified in their versioning (as much as you want them to be, at least) and also provide all of the benefits of a source-based distribution.
Love justice; desire mercy.
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?
Humans do not scale well, they have very low bandwidth of information sharing, and have high latency (i.e. you can't get ahold of them). Humans are also expensive, wander off into different jobs, graduate or drop out of college, etc. So I tend to prefer the reducing human cost of the system administration complexity as a default position.
So my gut feeling is that unless there is a major time or dollar savings in the optimization by building from source (i.e. avoid buying 10+ new CPUs for the systems, or computation runs take a day less) go with the reducing administation complexity by using a package management systems so that you can concentrate on your actual goals (research, profit, or whatever).
What some people don't seem to understand about Gentoo or the BSD's is that not everyone is hell bent on world domination and market share. Some people want something specific, and Gentoo and the BSD's are there for them. It's not like they are ever going anywhere. BSD "despite the rumors" has never done anything but grow in usership with the steady, yet slow trickle of new users and the fiercly dedicated long time users. Gentoo is growing rather fast, but will no doubt plateau off and settle in the same way the BSD's have. But by all means, continue to have your OS flame wars and make your comparisons and talk about market share or other things that aren't important or even remotely interesting to the majority of most Gentoo and BSD users. It's very humorous. :) HAVE FUN STORMING THE CASTLE!!!
For every annoying gentoo user, are three even more annoying anti-gentoo crybabies. Take Yosh from #Gimp for example.
1) I am a newbie and have to use packages for *.
2) I know my way around. I like the level of control I get with compiling/know how to code/read far too much Slashdot. I compile by default.
3) I manage more than three boxes in my basement now. Having the ability to back out of system changes without a full OS reinstall is a necessity. I build my own packages from source that I've compiled.
4) I manage more than just three boxes in a department now. Now I have to deal with politics, ordering hardware, the freakin' network, and I generally have time for sysadmin. On top of all that I now have a family so spending two or three extra hours per day on my Unix hobby is no longer feasable. Precompiled packages work just fine.
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
Wow. There sure are a lot of posts about which is better, but I don't see any comments that deal with the underlying problem. And that is this: don't get into a pissing match with your professor. Seriously, what are you hoping to accomplish here?
If you were thinking that you'd get tons of pro-compiling comments, and then put that in front of the professor, stop right there. Coming to Slashdot for validation of your side of the argument is about as helpful as those wives who write to Dear Abby about their husbands. Because no husband on Earth is going to appreciate getting chastised by Dear Abby, and if Abby sides with him, he's going to gloat. It's lose-lose for the wife, just like it's lose-lose for you if you try to use Slashdot as leverage. Screw with the computers that the professor relies on, and he'll find a way to "thank" you for it. Don't sabotage yourself.
My Greasemonkey scripts for Digg &
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.
Usually when one builds from Source, they install it to wherever the original developer has it set to by default. Unless you did some heavy patching, the software will very likely be more "true" to the original software then many packages.
:-)
Correct me if I am wrong, but are you contridicting yourself here? Gentoo DOES use developer source, but they ALSO do what you call "heavy patching".
I interpret this "source vs package" debate to be something different: What is the NORM for your distribution, and are you using the OS in ways that were not tested by the vendor's SQA team
For example, ANY of these distros can get borked if you install Ximian on top of them and THEN go back to the vendor for updates. It wouldn't matter if you did it from source or packages.
Same with Alien packages on Debian, or "Redhat centric" rpms on Mandrake or SuSE.
Bottom line is don't mix oil and water.
I agree with your comments about what is good with Gentoo. I happen to like Gentoo and FreeBSD for the very reason that there's a BAZILLION source packages that all have cross-testing against each other. Same for Debian I suppose.
Best thing RedHat ever did for their desktop distro was set it free. They NEVER wanted to be in the business of supporting user-borked desktops when they install random stuff from the net, and they never wanted to manage and QA a large repository. Now it looks like there's a Fedora community (two actually) addressing the package distribution issue. Good for them.