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)
I actually make my own gentoo ebuilds and build everything emerging them... so, both.
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.
Your installing a OS from a package, so why not applications? Old programmers moto "Don't re-invent the wheel".
Mod +5 Drunk
I tend to install from source when I don't have root access but package managers can make things nice and easy.
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 (gentoo.org) 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.
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.
R.
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.
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.
Time on your hands.
You are receiving this message because your browser supports Slashdot Sigs and you have Slashdot Sigs enabled.
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
Not everything will work "out of the box" or package in some cases depending on your config
||| I still can't believe Parkay's not butter.
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!
Trolling is a art,
In RPM's Distro, I always rebuild .src.rpm and install binary generated.
-- Hasbullah bin Pit (sebol)
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
./configure ; make ; sudo make install
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.
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 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.
Evolution or ID?
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.
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
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.
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.
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 :)
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.
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.
There's one major and obvious benefit of Binary Packages: they're quick to install.
./configure parameters)
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
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.
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
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
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!)
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.
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.
Allow you to tweak the parameters, optimize for your architecture and still easily remove and or upgrade the package.
I always do.
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.
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.
LilMikey.com... I'll stop doing it when you sto
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.
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.
Regards,
bt
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.
Aren't SRPMs, or source-RPMs, pretty much the best of both worlds?
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.
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!.
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 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.
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.
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.
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, 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.
I use both Gentoo and Red Hat Enterprise;
/etc/make.conf. I use gentoo on one machine only, my personal web server.
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
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.
----- Documentation is worth it just to be able to answer all your mail with 'RTFM' - Alan Cox.
TWW
"Encyclopedia" is to "Wikipedia" what "Library" is to "Some people at a bus stop"
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.
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.
...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
DNA in your Linux: DNALinux
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.
A year spent in artificial intelligence is enough to make one believe in God.
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.
...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, 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.
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.
Evolution or ID?
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.
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 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.
The owls are not what they seem
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...
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!
rd
You all are too stupid to live.
For my personal use, I prefer to build from source. Heck, I install only base and all sources, do a cvsup and go from there.
Profesionally, packages are just as good. Except when the ``park'' is big enough to warrant... a build server! Then I just build my own releases from the cvsupped cvs tree with matching packages to go with it.
Then again, me use teh FreeBSD.
(Also available in Net and Theo flavour.)
I nearly exclusively use packages because of the security implications of having a compiler installed on a production system. If I do build source I have one build box that I will build my own RPMs on, and then install them on the production system.
Doing it from source is far more 'geeky' than packages
But, i'll take packages over source any day of the week. Have tried building OpenOffice.Org of XFree86 from source lately?
Have a couple days to kill?
Personally, for me, the time it takes to build everything from source is not worth it when compared to the advantages of building it yourself.
I have code to work on, documentation to write, and my own programs to compile. What i don't have is a couple days to baby sit compiles before i can do my work.
I tend to do a lot of customization for daemons like a Apache, and some libraries like PHP. However, it's best to leave most libraries to your packaging system being as many other packages are likely to depend on them. It's a balance. Compile when you want/need to... but try to limit it to major apps like daemons that not many other packages depend on.
When I was in college and had time to be a really good sys admin, I always installed from the source. I felt things were cleaner and better that way. And if something went wrong and I needed to adjust a make package I had the time to work on it.
Now that I am out of school and have other responsibilites at work beside just the two machines I maintain, I have to be practical about the time I spend performing upgrades. I have found that packages save me quite a bit of time in the long run.
I think you can learn a lot from installing from source, and if you have the time then I would suggest doing it that way for at least one machine. But when speed is of the essence, packages come in very handy.
However, I usually go with rpms when dealing with something like red hat ES or AS systems, primarily for the support. It can avoid 'breaking' an sbin version by accidently pointing to something in usr/local for example.
What it really comes down to is using common sense instead of being a zealot.
"Can there be a Klein bottle that is an efficient and effective beer pitcher?"
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.
Seriously, use gentoo
It gives you the option of compiling from source or packages (emerge -k anyone?), manages all the dependencies, and will (generally, and as long as you set up your USE vars correctly) compile using the right options for your machine, the way you'd want it
I don't use Linux; I use FreeBSD. I build applications from source (ie, from the ports tree rather than packages) on my work machines, and my home machines.
The biggest reason is that I can have macros in the global Makefiles that control how the application gets built (ie, globally build everything without LDAP support), and for things like PHP I can compile in exactly what I need, and not have to link against libraries I don't want.
(S(SKK)(SKK))(S(SKK)(SKK))
I've been working as a Solaris/Linux sysadmin since '99 and I can definatly say that over the long haul, packages are way better. However, I tend to custom build, or at least tweak, my own packages and create a local repository to store them in. Then create a local blog about what is installed where and anything special you had to do.
Best of both worlds with documentation for the next admins.
Oh yeah, -Os often gives better performance on modern processors than -O2 (IME) because more of the loop fits in cache.
Why not build from source on machine 1. Then have machine 1 build a package to use on machines 2->n? Yahoo! Best of both worlds.
If it's something that I really don't want to screw with - such as X, I'm more than happy to let RedHat do that dirty work (come on, be honest, did YOU actually compile it from the ground up?) GCC also falls into that category.
Also, anything with way to many software tendrils is package fodder.
Apache, however, is one of those, I just gotta build it myself. And, of course the Kernel.
Packages give you all sorts of benefits - change control being #1 (and, as we geeks know, is a leader cause of software cancer) they're hard not to use.
Here's a comprimise: you build the software yourself, and then roll 'em into packages. (oh, don't forget to have decent change management structures in place) You'll both be happy, and sitting in a great position for when your tiny 10 node system turns into a 100, 1000, or 10000.
Yes, I know, it is a great distro (it is mine too), it compiles everything from scratch, let you optimize the produced code for your machine, and does it automatically and nearly flawlessly. But I don't think enterprises having to manage dozens of linux servers will ever be really excited about this. Why ? Because compiling simply takes *time*, and that is exactly what most serious system administrators are trying not to loose. However, I agree Gentoo is an excellent distro for geeks and advanced users, especially because of its BSD-like+compiling powerful packaging system. But it is ridiculous to stand up to say gentoo combines "the best of both binary and sources packages". It doesn't.
All and all I'm probably 50/50 on the whole deal. I use Slackware and for the basic setup packages do the trick, although I wish Patrick would get into the late 90's at least and Pentium optomize the packages. For the more advanced stuff like installing Apache/PHP/Mod_* I prefer a build your own approach instead of packages. I also do the same for FTP(Proftpd), and mail(Postfix). I also run alot of stuff there is no package for as well so that I have to build from source. I also am required due to the software I run for webmail (openwebmail) to build my PERL from source since it requires the suidperl, which Slackware doesn't build into the package (which is natural since its deprecated, the Openwebmail guys really need to address that issue since it will probably be removed from the perlsource entirely at some point)
Power Corrupts,Absolute Power Corrupts Absolutely, leaving one person(group)in charge is absolutely corrupt.
It really depends on the application. Typically I look for a package first, and if that isn't available I'll get the source and compile. However, having said that, you do need to think long term. Suppose you are the type that likes to upgrade as soon as new releases come out. Source will be your best bet. Another thing to consider is how easy is it to upgrade an app installed as a package with source? As an example, Nagios on SuSE 9 uses locations that make sense for its files, but it's pretty difficult to massage the configure command line to recreate that if you want to upgrade with source later on.
Source code also seems to get you more involved with the app so you might have a better understanding of how things work once you have things installed (YMMV).
Works for me, anyway.
Eschew Obfuscation
1.Get the source
2.build the package
3."unzip" the package
4.analize the source
5.goto 1
http://www.automatiq.se
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
has a great ports system which allows you to build software from the source automatically. I find with ports, you can get the latest software in a more timely fashion as a package is not always available and it can be built to use your machines entire potential. The package system is integrated into the ports system, however, so you can build your own package from the newest port then distribute it onto several machines. The other good thing about packages is for older machines with small hard drives and slow processors-you would probably run out of drive space (and patience) trying to build something like openoffice from source. That's just my experience using source and packages for a particular system.
Build your software from source and then create a package. Distribute and install the packages. It is a trivial matter if you use Slackware. Other distributuions are not too difficult if you use the checkinstall utility. You get the best of both worlds.
Alex, I'll take keybindings not used by Emacs for $400....
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
I install from packages whenever I can (assuming the package is up to date), but I roll my own when needed. Packages are just easier in most cases, not to mention faster.
Regardless of personal prefernce, though, we need to move towards more use of packages as opposed to compiling source. Compiling is something that scares the absolute hell out of nontechnical users. If you make it a more-or-less requirement in order to use Linux, you've just excluded those people. And don't think these people will somehow magically just want to learn to compile. They don't want to learn to compile, they want to do their jobs. Diddling with source code is neat, but most people get paid to perform job functions other than diddling with source code.
In the end they will lay their freedom at our feet and say to us, Make us your slaves, but feed us. - Fyodor Dostoyevsky
If you use a system like debian (maybe fedora too) you can easily use source packages.
You get the advantages of locally compiled software and the sanity and maintainability of a package system.
If your distro uses RPM, install from Source RPMs. This lets you compile from source and optimize for your system and still have all the benefits of packaging. Many optimizations and option selections can be done from the rpm command line.
The benefits of a binary package are:
A properly packaged Source RPM is just as easy to install as a binary RPM. The RPM lists build prerequisites. I imagine Source only distros like Gentoo automatically download build time prerequisites, just like RedCarpet automatically downloads binary RPM pre-requisites.
I prefer to compile most important programs from source.
/usr/local with everyone elses crap. If you're compiling it from source, it's important enough that it should be separated.
For example, if I'm running a web server, I'll install and configure apache, php, some database, etc. from source. But I really won't care if I have vim or cron or jabber or whatever installed from a package. If you do a base OS install with all basic/necessary components regardless of the application of the server, and then install important software from source, this will generally be the case.
The key to managing this is creating a separate directory for your crap. I.e. don't just shove your stuff in
Then, if someone else comes in you can say, "Everything is packaged, except for important software which is in this directory. All the source and configure files for that software are located in this directory, in case you need to figure something out."
Just my two cents.
01100111 01100101 01110100 00100000 01101111 01110101 01110100 00100000 01101101 01101111 01110010 01100101 00101110
..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()?
i worked at a university in virginia in the music technology lab, where we had two linux servers that did everything from serve web pages to run netatalk. my boss (also a professor) liked the RPMs too, simply because after i left there was no guarantee he'd get any help from the IT department, and he understood how to use RPM from the command line.
:) for a while i would recompile the kernel and he flipped out -- so i started using those crappy RPMs.
i guess in academia they are used to having funding for some things some of the time -- your professor probably wants to keep those machines running as long as he possibly can, because money has to be used for other things.
and besides, compiling programs is a hard thing for the "sorta unix geek" to get his head around
fortunatly, i think this will change when people realize there is an ample supply of knowledgeable folks out there who can do this stuff. it's easier to find a geek now than it was even 5 years ago!
When I started way back with SuSE 5.2, not everything was available as rpm or source rpm, so I got used to build stuff myself. This, of course, broke rpm package management, so I has to use --nodeps most of the time. All the package management tools suffer from the problem that you can't easily mix installed packages with software installed via 'make install', it will at least break automatic dependancy checks. So I thought about switching to gentoo, but as that required a lot of stuff to download (I'm stuck with dialup), so I decided to install Linux From Scratch. Haven't regretted it since.
...Another holy war. As if we didn't already have enough.
vi vs emacs
KDE vs GNOME
SCO vs everybody
and now
Source vs Precompiled.
Now to add something intelligent to this conversation, I personally am a Gentoo user who builds from source. Source and packages both have their pros and cons. Source is highly optimized if you know how to work the compiler flags and the downloads are smaller, but you have to wait hours for some pieces of software to install. Precompiled binaries on the other hand may be a little larger downloads and usually aren't very optimized so run a little slower, but have no compilation time so they install much quicker.
Personally I like source, but that's because I have the time to let my stuff compile and I like having the small performance increase, even though I barely notice it at all. I'd imagine that in a more business like setting where time is much shorter it would be beneficial to use packages simply because it's quicker to install allowing for more time to configure and make sure that it works.
i love building from source, but it's rather an emotional, than a rational thing. it's like washing your car by hand.
If you have an application that you need performance out of, spend time compiling that once and then packaging it once and installing it on your 10 machines.
When looking from the prof's view, it will be easier to get someone else up to speed after you have graduated if your machines stick closely to standard packages.
Use the time that you'd spend compiling/installing doing more CS related activities.
Most people (including myself) that have gone through the phase of wanting to compile everything get out of it as soon as they have some real problems to solve.
It has been my experience that packages don't always put things where they should. When building from source, you typically leave the "prefix=" option at it's default, which is what the software writer intended.
Qt is a good example
When installing Qt from source, you are told in the install doc where everything is going to go and you are asked to set the QTDIR environment variable by hand. This variable is nowhere to be found with a package. Without this variable it is difficult to find where Qt is installed if you want to do anything with it.
Also, I have found that installing packages that are dependencies of other packages does not always guarentee that it will be recognized by the depending package, where as it almost always is when building things from source.
my 2 cents
As an experienced SysAdmin, I'm kinda on the side of your prof. Packages give ease of installation of over many machines and (perhaps most importantly) proper tracking of files that are installed to prevent files from being overwritten, and to allow for uninstalls too. OTOH, building from sources gives you fine tuned control over what gets installed and where, and specific build options.
So, why not have the best of both worlds? Build your own packages! I use EPM to do it and it's a breeze. You can get EPM at:
http://www.easysw.com/epm/
I'm not religious about building everything from scratch, but I like being able to include my own default config files, as well as have control over what gets installed where (I mostly manage Solaris machines, but often build Linux packages too).
As a shameless self-plug here, I recently wrote an article for SysAdmin magazine on packaging with EPM. It's especially handy in multi-platform environments. If you want to see my article check out the Dec. 2003 issue of sysadmin mag:
http://www.samag.com/articles/2003/0312/
if you want to make it easy as possible use packages, you can distribute them to all the comps and install then and copy config files, quite simple. if you want performance adn speed and do not care how complex manegement is go with source, it will optimise it for the system you are on and its kernel (if you use custom kernel or cpu specific kernel, if u use generic packages are just as good) if you want a good combo of both create your own packages from source you compile on one machene (if all machenes are the same specs) and distribute that package, then you get the performace and speed w/ the ease of use. only compile once in other words.
But when a package doesnt exist for what you want, you are forced to head to the ports tree..
If you are loading servers though, i bet all is available as a package, saving TONS of time....
---- Booth was a patriot ----
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.
In the case of RPM's, you could always download the src.rpm and issue an 'rpmbuild --rebuild' of the file. That will produce brand-spankin' newly built RPM binaries, built on your system.
Trolls lurk everywhere. Mod them down.
I'm a build-from-source guy too. I used to install from packages, then continue upgrades and new installs via source, which quickly breaks all kinds of dependencies. I found it worth my while to learn how to roll my own packages.
.spec files to build RPMs, and most small projects are self-contained enough that writing your own .spec file isn't too difficult. That way you get a customized configuration that's easily (un)installed and tracked.
Most large projects include
It's worked well for me so far. The only upgrade I've made that I wasn't able to package was the new kernel (2.6.4 right now).
which is better, vi or emacs? ;-)
Schrodinger's cat is either dead or really pissed off...
If you have a sensible reason for building from source, (ie. not "just because") modify source packages and build them on demand or build your own packages.
Conformity is the jailer of freedom and enemy of growth. -JFK
I'm pretty comfortable working in a u*ix environment, but a niggling detail has thusfar escaped me...how do you compile a large application on one box, and distribute it to a bunch of other machines.
./configure; make; make install to compile and use it on the current box. But if I want a barebones little snort sensor that doesn't have a comiler on it, do I need to physically deconstruct the script for 'make install' or is there an easy packager (rpm?) I can use to take the compiled code and install it on a remote machine. (ignore actually GETTING the bits to the other computer...unless there's an easy way to do that other than scp/sftp)
Example:
I've downloaded the latest code for snort, I
"Draco dormiens nunquam titillandus."
If it's your browser, you can probably wait for the package. If it's your MTA, you had better be able to get it fixed ASAP.
I'm guessing it's a bit harder to rebuild and duplicate environments exactly. If I build 3 machines today, it's not easy to ensure I can rebuild the exact same machines 3 months from now, at least not with the standard 'gentoo' approach. At least, not as easy as saying 'pop this mdk10 in and install'. You at least know what base everything is starting from.
creation science book
Regardless of whether you choose packages or source, consistency accross servers is what is most important. You need to be able to go to any server and know that it has all the applications you need. This may be slightly altered in a distributed environment where certain servers are allocated for specific tasks, but you should still always know that all the database servers have the same MySQL install, or all the Web Servers have the same Apache configuration. This extends beyond configuration to software installs. All servers designated for a particular task need the same software, and the same versions of software on.
Whether you choose packages or source is up to you. The benefits of packages is that it's easier to install and easier to distribute accross many servers. However you may not be able to find the specific version of the package you require. You may find that the author of a piece of software doesn't release his code as an RPM or a DEB, etc. IMHO you are probably better off creating your own software from source, but having tarballs which you can copy accross servers to do a make install. this gives you ultimate control over where configuration files live, which versions of software you run, which options the software is compiled in with, and so on.
The Romans didn't find algebra very challenging, because X was always 10
(I don't know if someone else posted this. I haven't seen it yet. Forgive me if this is a dupe.)
For anyone who has gone through the headache of dependency hell using RPMs, I would like to point you to apt for rpm. It's the same type of package management system that Debian uses, except that it uses the rpm system for the backend.
This means that, when you want to install a package, apt figures out all the dependencies for you, downloads, and installs them. It will upgrade things for you on a regular basis if new ones are released. It knows how to do the dependency traversal to upgrade (or remove) packages if they become out of date. I have found it to be the best way of keeping my system happy. And I'm not chasing down dependencies manually any more. Bleah.
For those who also install things from source, there is an ability to ignore package dependencies and just install. Plus, you always have access to the rpm system itself, so you can do things manually if you desire. You can then use apt-get's --fix-broken and --fix-missing options to "clean" things up if need be.
Check it out!
Duck and cover, incoming Gentoo zealots :P
Personally, I install from packages (apt) wherever possible. If something is unpackaged and looks new and shiny, then I'll install from source. I really can't imagine managing a large number of applications without a package manger, even if it's something you've written yourself.
If installing everything from source is your thing, you're probably already using Gentoo with its package mangagment. So the question is moot.
"The number of Unix installations has grown to ten, with more expected." (Unix Programmer's Manual, 2nd ed.; june 1972)
I have a redhat 7.2 based system. It is not really 7.2 anymore because I have been doing LOTS of updates via source. I used to follow the strategy of upgrading the system to the latest distribution as they were released but found I was spending TONS of time trying to recover from each update.
Instead, I now just pull updates or new apps/kernels from the web in source form. I VERY rarely have problems with the "configure" script built into most of these. The install goes quite well in most cases. I *think* this has been a win for time spent to keep my system updated as opposed to updating the distribution. Packages for a distribution have so many dependencies that it becomes nearly impossible to install from packages after a distribution has been residing on a machine for more than 1 year.
Ciao,
luigi
Are you using the source that your distribution has available? If not, then I sure hope that you have subscribed to BugTraq. One of the nice abilities of binary packages is security/bug updates. Otherwise, you have to really keep a keen eye on what is affecting the software you compile security-wise. Some, if not most, software rarely announces updates on their site pertaining to security. This is mainly with user-space programs though, server software is usually pretty good with mentioning vulnerabilities. I would just compile the source from my distro, if I were you. Personally though, little is to gain from compiling from source, compared with what you lose (support, updates, etc). Food for thought at least.
Bored? Why not join a decent mess
Personally, I think a little of both is really the way to go for for ease of upgrade/removal/optimization, but I never compile and "make install". I run Debian unstable and maintain and upgrade most of the packages on the machine with aptitude. However, apt-build is a great tool for building processor optimized versions of those same packages. This way, all your software version tracking and removal is still handled by the Debian package system, but you can recompile for speed on important packages (in my case I compile my own x11 and kde packages). Best part, if it breaks or doesn't work, you can just apt-get the package and try again next release.
So far I've read a lot of ``only build from source if the packages don't suit.'' I agree with this entirely.
If, however, there is some major benefit to building from source (features, bugs, etc.) then you can still create a package of your compiled source. That way you still have the ease of maintenance.
The ports system on FreeBSD, for example, makes it very easy to install programs. However, just a couple of days ago actually, I had uninstalled something that some other installation required. FreeBSD would say that the port was installed, but it wasn't able to find the shared libraries. Even after I tried installing the same port, it wouldn't find the libs. I was able to fix it only after I installed the uninstalled program from source.
Building from packages is easier and it also provides a convenient way to keep track of everything you have installed. Also, you CAN have control over the installation process. In the FreeBSD ports system for example, you can pass flags to the make process. But building from source is sometimes necessary IMHO (like in the situation I ran into).
The other main advantage (at least with FreeBSD ports) is that FreeBSD automatically goes and fetches dependencies for you. If you are building from source, you either have to get all the dependencies beforehand or you will find out what you need while building.
Vivin Suresh Paliath
http://vivin.net
I like
I'm a lazy bastard, and I find that most packages don't need uber-performance (who's gonna notice if ls takes 10 ms to run instead of 15). I also think most packages won't get much mileage from compilation tweaks more complicated than gcc -O2, so for the most part I download precompiled packages.
I use Debian, and I understand other package-based distros do the same thing. For me, apt-get foo to fetch precompiled packages is good enough 99% of the time. If I'm debugging a package, or am curious, or think I might get better performance from rolling my own, it's as easy as apt-get -b source foo (automagically downloads original upstream source, diffs to make the Debian package, meta info; then uncompresses & patches the source tree; then builds a source package on the spot.) Heck, Debian has some tools specifically for building kernel debs, since the kernel is something many people want to build themselves (I hate distros' Christmas tree kernels.)
IOW, I don't have to pull a Gentoo and build from source all the time, because I don't find it necessary, but it's quite easy to build from source when I want.
Meldroc, Waster of Electrons
The hardware I use is the same across the board,Dell Poweredge 6650 boxes. I use the Distribulator to manage all 20 boxen. I do source compile on one box and then push the code up to the rest of the boxes with the distribulator.
This is all pretty much a non-issue. As long as you'll keep the average end user in the dark with all those source compiles and dependencies, Linux will never truly succeed on the desktop market.
Sure, you get plenty of control while compiling from source but can you seriously imagine yourself explaining it to Joe-sixpack when he ends up with a bunch of problems and a broken install when all he needs to do under Windows is to find a setup.exe or install.exe and everything works most of the time?
Packages are an improvement for usability, but you still have to get dependant libraries elsewhere most of the time. I think i speak for the average user when i say most people don't want to install 6 different packages only so they can install the new app they want to try.
Ease of use for the end user, people, ease of use! Sure, it all works fine for your mom when you install her a workstation with the things she needs at the moment but the second she needs something else and you're not around to install it for her, she's lost.
So you put Distcc on all your servers, compile times shrink. Actually I find managing gentoo servers much easier. I am very excited and we managed over a dozen machine at one place.
Binary packages make it a lot easier to keep track of which files are associated with which packages. Back in the old days, every time I compiled and installed a new piece of software, I installed it in /usr/local/ so that I could easily find (and, if necessary, remove) all of the files associated with it.
/usr/local/{foo,bar,baz}/{bin,lib,include} -i.e. separate bin, include, lib, etc. directories for each piece of software. You've got to make sure that you (and possibly everyone else) have all of those directories in your path, and that you specify the right -I options when you're compiling, the right -L options when you're linking, and so on. If there are shared libraries in there, you end up having to set LD_LIBRARY_PATH correctly in your shell rc files, your init scripts, your cron jobs, etc. or stuff won't run.
/usr/*). If I later remove the package, RPM will find all of the files that it installed and delete them. If I upgrade to a later version of the package, any obsolete files will get removed. On top of that, if there are any other packages that depend on what I'm deleting or upgrading, I'll know what else I need to recompile or upgrade to avoid having things break.
The problem with this is that you end up with
With RPM, I don't have to worry about this. Everything can just get installed in a single set of directories (most commonly,
When I first started using RPM, this was really frustrating, because I didn't really understand how the system worked or how to fix broken dependencies, but as I've become more familiar with the system, I've come to really like it.
Obviously, the other advantage of packages is that, if you're maintaining a large number of systems, you compile stuff once and install it N times. That way, you end up with the same configuration everywhere, which if done properly means less time debugging wierd problems on individual systems and more time doing things that have benefits across the board.
Are you really running an environment where an extra 1% is going to affect anything? Most of the time you're probbably not even going to get that much. Unless a package isn't provided in your distribution, don't bother compiling it yourself. While some people like the "tough guy macho factor" of compiling everything from source, there's usually little reason to do so.
Your time is better spent on properly configuring your server to be secure than screwing around optimizing everything to squeeze out a last 2% of performance out of a webserver. If you compile everything yourself you lose the ability for your package providers to maintain the packages. Do you really enjoy going and getting new kernel source, compiling it, and installing it every time there's a security patch?
Try to remember that you only have a finite amount of time. You sound like you already know how to compile apps, so it's not like you're learning much new. Time spent optimizing and controling is time lost that you could be doing something more productive.
AccountKiller
apt-build provides automatic source based package installation in debian. Not every package offers a source package, however. This is something I'd like to see expanded in debian.
Also note the aptly named, though apparently dead project www.debtoo.org (google cache) which is based on apt-build. Don't let this stop you though, 'apt-get install apt-build' and give it a try.
If I need a package right away, I would oftern prefer to build from package, but other then that, building from source is always better for me. It also depends on the hardware I have available what what's available that supports it.
Even for personal use, I used to be a die-hard source-level builder.
But then one day I had to upgrade Apache. My target system is so old that none of the RPM's work, so I *had* to do it by hand else upset the whole thing with a new distro install.
Well, building Apache is no big deal. But Apache out of the chute with its stock source build is *not* the Apache you know and love. I had to also build ModPerl, OpenSSL and all the other packages it needs *in the right order* because of some problem with the build script. Suffice it to say, I blew the better part of a day on it.
So really, in some cases you must resist the die-hard urge to do it yourself. Hard drive space is basically free. Rarely will you really notice the performance. Your time is expensive and better spent.
And most of all, you don't have to face the dreadful feeling that happens when you realize you have to do a painful install all over again and can't remember all the weird tricky hacks you had to do.
Does it hurt to hear them lying? Was this the only world you had?
Once you get critical with the applications you run, you'll find that most packages, although convenient, seldom have the configure options that you need.
These apps should be built from source so you have total control, but unfortunately they require lots of care and feeding.
Install everything else from packages, when and if you can live with the defaults, and minimal configuration on your part.
System administration takes time, and resourcefulness, but there no shortcuts when you're talking about custom applications such as proxies, web applications, and many others..
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.
On the other hand, my source-oriented gentoo systems at home are kind of haphazard. The software versions are variable, packages are variable, etc. On servers, you probably want everything to be the same. That's probably easier to do using a set of Red Hat CDs. Unless you're just anal, always a possibility.
:wq
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.
this is coming entirely from a *BSD perspective [especially FreeBSD], but the older and slower your hardware, the more you might depend upon packages, just because they take less time to install.
That said, I routinely build stuff from source on a Pentium Pro 200 MHz dual CPU machine at work. It's not our main server, so the performance hit is never noticed.
Portupgrade is a absolute must on this machine, as we have all kinds of software running on it. Without portupgrade, I'm sure it would be a nightmare.
In the end, it's whatever works best in your situation, and to have this as 'news' on slashdot seem really freakin' ridiculous.
Only reason I can think to build from source is for customizing the application. It is nice to be able to strip unwanted commands from an ftp service, or patch a bugfix quickly. Dependancies can be a pain, but usually only if you aren't doing it right. rpmdrake and gnorpm are maturing well making rpm installs less furcated.
boycott slashdot February 10th - 17th check out: altSlashdot.org
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...
Use to build from SRC all the time, heck I would even read it before compiling, now I'm too old to wait on a compile.
.o files and then just link with whatever packages are needed? That would be the best solution. (Of course there would be some src files that would have to be compiled but to compile everything is just overkill)
:)
;)
So unless someone wants to loan out their CRAY so 45meg compiles take 45sec, not 4hr45min I just don't have the time to wait. (I would imagine your prof. may be in the same boat)
But I love the fact that I can get the source if needed.
Package dependencies are a pain, there is no 2 ways about it. Can y'all figure out a way to package the
This may be the reason I switched to Java. No lib dependency issues, no need to compile for a target platform, or config for specific shared libraries. But I do miss the RAW power of a good 'C' app.
Oh well, there's more of my life gone.
-tx
I prefer building from source. And use ccache ( http://ccache.samba.org ) Together with distcc ( http://distcc.samba.org ) this rocks !
As a Linux "lite weight" I can honestly say that I have found installing from source not a bit more complex than packages, packages are just quicked for default installs. I prefer source because it's really not that hard, and I can play with the configuration. It seems to me to almost not even be a question.
"Who are in control, they are not in control of anything - they don't even control themselves!" - Glen Beck
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.
Gentoo's portage does indeed combine the advantages of compiling from source with the ease of installing a package (actually, it's *easier* IME). But if you're talking about maintaining multiple machines, time might be an issue. Portage doesn't do anything about the amount of time compiling form source takes. For home use: Portage is clearly the best choice. For business use: I would choose RPMs for the amount of time they save.
Nothing to see here. Move along.
If a working RPM is available I will normally download and install it. However, more often than not, if I want the latest version of software X it will not be available in RPM, so it's at that point I will compile and install. The gripe I have about that is I have to look at ./configure --help and make sure that I have all the options set up that I need. If it's tied to other source trees (OpenSSH seems to be a pretty popular one), this gets really complicated.
It's even better when you download the newer version and have to remember what options you used to compile originally and get scared of breaking your existing app.
Or still better, the programmer decided he wanted to use some obscure headers that can only downloaded from a server in Uzbekistan hosted on a staticy dial-up connection, so now it's up to you to track them down and load them in so the damned source will compile. But then after you do this you find out that your headers are outdated and the source is calling on functions that don't exist. Now THAT'S fun.
Is it any wonder why I tend towards binaries?
-R
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.
I use SuSE (formerly RH), so I'm "into" using RPM. OTOH, I usually only like RPM's that have been built by the distro's creator. (Noteable exception: PackMan RPM's for Xine.) Anything else, I usually compile from source and stick in /usr/local. Checkinstall is what you need here. After configure and make, you ``checkinstall -R'', and it makes an RPM of whatever would be installed with ``make install''. That way you can take it back out very easily.
Acts 17:28, "For in Him we live, and move, and have our being."
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.
If the professor has some sort of grant he may prefer a package because it is quicker to setup and save time so you can be more productive in other areas. If it is some sort of continuing income then you might as well try to incorage recompiling the source because you get more out of it educationally.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
Is that, like, 11 Linux-based servers?
Have fun: Join D.N.A. (National Dyslexics Association)
It seems like computer people tend to think about performance while business people think about reliability.
---------------
Create a WAP server
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. -
I use Gentoo. Does this tell you anything? :)
First I install via a package, if the service does exactly what I want (90% of the time) then thats the end of it. If there is some kind of tweaking that needs to be done, I un-install the package, download the source and compile it with the option I need/want.
But overall I go packages first. Also as a side note, I use Debian, and the apt-get package manager makes using packages real sweet, it auto solved dependencies. This is the #1 reason I started using packages. I got tired of having to track down odd libraries and such.
-Gnu
A man, a plan, a canal, panama
packages I build from source. Those that do not come prepackaged and kernels. I like to build my own kernel because I like to add a few of the grsecurity features into my kernels, but only some of them, and distros don't seem to incorporate some of the most logical ones (network protections).
Other than that, it is really a waste of time. KDE and Gnome are just too freakin' big these days to build from source. Anything else is like trying to squeeze one last drop of performance water from a turnip. Little gain for lots of pain.
In Bushworld, they struggle to keep church and state separate in Iraq as they increasingly merge the two in America.
That said - for a work machine, I prefer binary packages. I just want the damned thing to work, work well, and not futz with it.
For a hobby/play/research machine - I prefer source packages. I have found there are many compilers out there that will massively outperform GCC, especially when you turn on those crazy optimizations that most binary distributions won't (plus optimize for the EXACT processor I am running on, etc.)
I have mod points and I am not afraid to use them
Lest ye forget, he did say he was a student working for a professor.
His time is not worth a whole lot in this case!
On my work desktop and at home I run gentoo because I find it easy to maintain and I like the fact that it is optimized to my computer. However in my work experience I believe that it is more reliable to stay with packages epecially if you are running mission critical applications on redundent servers. Part of maintaining redundent servers is keeping them in sync. This allows you to take down one server in a production system to apply a patch or config change and test it to see if it work. If you then perform the same patch or config change on the rest of the server in a redundent cluster you can have high confidence that it will work. (Medium confidence if its windows). If I was to do this with compiling from source there would be more things to track and more red tape is needed to insure that the system comes out the same way. So overall packages, while clumsy, are simpiler and lead to more reliable systems.
With gentoo you can compile your packages from source. The -b flag will build and install the package, the -B flag will simply build the package as long as all dependencies are installed. You need only 1 build machine. You can roll your package(s) out to the other machines via a simple script. You can taylor your make.conf file to build the system you want.
Gentoo now has glsa-check, this command can be used to automatically update the system with security-related updates.
I hate dependency hell. With packages I had to install arts in order to install SDL. In order to install arts I had to install kde-libs. In order to install kde-libs I had to install qt. Is arts a requirement for SDL? No, this was decided by the package maintainer at compile time. This is one of the problems with one size fits all packages.
Get a free ipod.
This guy asked if he should use binary packages or build from source....not what distribution he should use. I guess gentoo folks think theirs is the only distribution that you can compile from source for *smirk*
./configure --with-my-options
The big problem I had with gentoo is the ports. Some of the packages are outdated by weeks...if not months. If I wanted outdated ports, I'd install FreeBSD. If I'm going to go through the trouble to compile something from source, I want shiny and new. I want an ebuild within a few days of the source being released. I DON'T want to sit there and try to write my own ebuild. If THAT is the case then I can use an RPM distribution and checkinstall EASIER.
make
checkinstall
wallah....my package, built from source, and installed.
So clearly this isn't an issue of whether he should use Redhat/Debian/Mandrake/whatever and slackware...oh, ummm...I mean Gentoo. This is an issue of just what he said: should he use binary packages on the distro he has at work, or should he use source packages.
I never build from source when I know that I have no need/interest in learning the inner workings of the code and I foresee no need in making custom modifications. The primary reason for that is testing: well-established Linux distibutions (Debian!) and BSD derivatives have more QA resources :)
Of course, when you have patches to apply or planning to contribute to development or the code does 99% percent of what you need and you know you can write this remaining percent yourself, you must build from source.
There is one exception: ageing systems. I have a Linux server that runs RedHat 6.2 (installed circa 2001 -- I was forced to use this one). RPMs are hard to find (especially with critical security fixes -- vendors tend to patch their current systems first). Over time I found this machine running almost no pre-packaged software (I threw away sendmail and bind first for the sake of qmail and djbdns).
How difficult is --prefix=/usr? Or, from the other standpoint, how difficult is adding /usr/local (to the PATH) and /usr/local/lib (to /etc/ld.so.conf)?
Gentoo compiles glibc, gcc, and kernels from source? I guess I'm not the only one watching compiler scroll for 14 hours at a time.
+++ATHZ 99:5:80
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.
The main reason is that found myself building many server applications from source on Debian and Redhat boxes what made install-speed difference from using binary-packages inexistant, because i simply didn't use them often. The reasons for self-building was often my special needs (like having exim with mysql and postgres support) or having bleeding edge software that rocks and helps productivity (subversion, i use it for over a year now). I always documented what i did when installing from source to be able to reproduce eventual problems and to remember the ./configure flags.
When i switched to gentoo i still document my installs but the documentation shrunk by at least 50%, because many steps are done for me by the very cool portage systems and its ebuild files. If i need exim with mysql an postgres support i simply run:
USE="mysql postgres" emerge eximAnd that's it, exim is installed with config and log files at nice locations and fully working without the need of doing anything by hand. When updating my servers i use the binary package feature of portage, i build the package on a lan-server where cpu-usage is no issue and then i install it from the binary package on the target machine w/o the need of compiling it (or waiting for the compile to finish, which can be a pain when many servers need the OpenSSL update for example).
I like the portage system because my systems software is fully customizeable with a minium of work involved. And if something doesn't work i simply fix it in the ebuild files, which are easy to understand and modify. When a newer release of some package is out, but the ebuild is missing, simply rename an older ebuild to the new version number and try to emerge it, it often works.
If an *OFFICIAL* package is available, then package.
If not, then make your own package from source.
So at the end of the day, all I have to manage are packages. Either official ones or my own.
I always use binaries, much easier to maintain. I also have the advantage, if you will, to know that I will be replaced within a short periode of time (1 year). To make the job of my replacement easier, I use standard .deb packages for everything. It will make my successor life much easier. I also like the speed at which you can deploy a brand new installation. Im sure building from source is greate if you need absolute control and have a lot of identical servers, but I don't. My users can't live with everything being down more than a few hours, and I don't have the speedy hardware which can build all the software in that short a periode of time.
What I think is needed i binary distributions of software is a clear understanding of what options this package have been compiled with. This, I believe is esspetially importants in server software.
As long as building from source is a "must" for some distros, there is no chance against Windows.
Although building from source will always be an option, Packages should be the standard whenever possible except for dev purposes or geek frenzy.
For maintaining an individual machine there may not be much difference in maintainability; the advantage of packages comes when you have several machines to keep in sync. You can easily query the installed packages, perform upgrades according to a centralized configuration, and verify that none of the installed files have been corrupted. With GPG package signing, you can have a reasonably secure mechanism for pushing out only software that you have approved (better than relying on NFS and file permissions).
If you build from source it is very unlikely that you'd build separately on each target machine. You'd build once and then push out the binaries. Package systems give you a few more tools to manage and automate this process.
As others have mentioned, you can make your own source packages and build those, giving the best of both worlds.
-- Ed Avis ed@membled.com
Real geeks compile from source. Only wimps use binary packages.
This is a test. This is a test of the emergency sig system. This has been only a test.
I've been debating this with a couple of friends myself, and there's no super-clear answer we've come up with that meets all of the goals. Those are:
.tar installations on package-based systems at developerWorks called Stow which was also discussed on Slashdot awhile back. Like so many other things, I'm interested but haven't looked into it...
o Ease of use/deployment (think server farm)
o Tracking (what was built where and when it was installed)
o Performance
o Reliability
o Maintainability
o Longevity
That last one is what bugs me. I came to Linux via RedHat 5.3, and I've learned how to set up a firewall, a LDAP server (for addresses mainly), Samba, Apache, etc. over the last few years. I'm no guru, but I can install the software and make it work pretty well. I like packaging like RPM except when the RPM database gets hosed, which has happened to me at least twice. No idea why, and it "sucked more than anything has ever sucked before" (okay, not THAT bad, but you know). That speaks directly to the "reliability" aspect. There was a lot of helpful info about rebuilding a RPM db at rpm.org that I found especially helpful then.
But what I run into with an older system such as my personal (behind firewall) mail & web server that's running Mandrake 8.1 is that keeping up-to-date with security fixes and upgrades is that the Mandrake spec files are full of Mandrake-specific stuff that doesn't apply to newer versions. I can usually get updated tarballs and do my own builds, but eventually the spec files need more major overhauls or newer glibc is needed or something of the sort. I haven't found a good solution for keeping the system up-to-date, and I don't want to re-install newer versions every year or so. But that's what I do...
That's an attraction of using the source-code build strategy, but my buddy is really against this in a server farm environment because of deployment issues (not to mention requirements of specific versions of Linux for many of our apps). It seems more suited to individual users than to that sort of environment, anyway.
I installed Gentoo one time, and I liked how much less bloat it seemed to have. I am not aware how well its ports collections are maintained; if a system I install today can be gracefully updated with stable versions of updated packages over a 2 to 3 year period, I'd be interested in trying it again. I do want to install from a CD, tho (did that the first time) as I want a baseline build so I don't have to download and build quite so much.
There was an interesting program used to manage
Also an article with tips for rebuilding from source code that was basic but still useful.
Anyway, kind of a ramble, but there is it just the same.
- Leo
You don't use science to show that you're right, you use science to become right.
Something that package management has largely REMOVED from the Open Source community: Peer Review.
When was the last time most of us actually scanned through the code we were about to install? I know I'm guilty of being rather lax on that, I've just been looking when I get compile errors...
Is this a Bad Thing(tm)? I'm inclined to believe it is, but what say the rest of you?
I always build from source. IMO, it's the only way to go. A smart admin does not trust anyone else's executables when the alternative exists of building your own code on your own system.
More importantly, when you build your own from source, you're often reminded of outdated dependencies that need to be upgraded. I recently compiled a new version of OpenSSH and found out that I had a vulnerable copy of zlib on my system. Had I installed a package, I might not have known.
Do both! Optimise the source package, rebuild and install.
Of couse it takes more time, but if you really want both optimisation AND ease of management (Dependencies, integrity checking...), that's the way to go...
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).
but he is the teacher and you are the student.
He is doing things in the way he did them before you arrived on the scene, and he will probably be maintaining those machines when you are out worrying about your student loan and wondering why no one will pay you a decent salary.
Don't overthink this. If he likes rpms, then I would be installing rpms and creating a kickstart file to install them over the network for a new box.
I used to be a die-hard Debian proponent, but lately, several packages have failed to install and operate properly. E-mails to the maintainers have gone unreplied and in the end, I had to go to the source to make problems go away.
... not all the files, especially those in cron directories are deleted)
... is it the package maintainer, the software, the configuration or the user. Also, I find that discussion of package related issues lacking. If I'm stuck, I need someone who understands both the application and the package, not just the application and not just the package.
Right now, I feel that debian package maintenance is lacking because
1) maintainers are overwhelmed with the complications of actually running an install and uninstall (example, try to uninstall exim or ppp
2) documentation lags (changes in man pages do not get updated with debian specific distribution issues)
3) updated features are extremely delayed (yeah, yeah, use testing if stable isn't up-to-date enough, but in a production environment, that isn't an option because you'll lose the stability you need for everything when you're trying to use the latest feature on one specific package. If I want up-to-date sendmail, it doesn't mean I want to sacrifice the stability of glibc).
4) troubleshooting difficulties. When I have a problem, I can't always determine
1) I really need or want something optimized for my hardware. Things like the kernel, obviously, or other hardware-intensive stuff (I don't do 3-D rendering but if I did it would fall into this category).
2) I'm concerned about the security of whatever I'm installing. This is things like SSH, bind, sendmail, etc. (Yes, I know nobody in their right mind uses bind or sendmail any more. Actually I use smail for mail, but if I did use sendmail still... And I'm trying to get djbdns running but I seem to be missing the part in the docs where it tells you what the "compile this so it runs by itself without requiring everything else djb ever wrote to be installed" flag is.)
3) I want features that aren't available in packaged stable- or testing-tree versions yet. This is why I ended up compiling AbiWord 2 from source, IIRC so I could get the mail-merge functionality. It's also why I compiled xchat from source last time I installed xchat, though I forget what features I was looking for there.
There are a few things I try not to compile from source if I can help it. Things like OpenOffice, XFree86, you know the drill. It just takes too damn long on a Celeron 433. (I know, I know. This summer I fully intend to build myself a nice almost-high-end Athlon system, before crowley turns 5 if possible.)
-- Old Man Kensey
First rule of optimization... profile before you optimize.
The best I can tell, the only advantage you'll gain wrt optimization is code build specificallly for your processor, but I believe this will give you an extremely small speedup for most application. The kernel will probably benefit significantly, but most distros have versions of the kernel built for every minor processor type anyway (eg. i386, i586, i686 rather than just i386)
Not selecting features you don't want will usually just result in smaller programs without any performance gain.
So is it worth the time you'll spend compiling stuff and configuring them manually to save... maybe one gigabyte given that storage costs $1/gb now?
OTOH there are other good reasons for compiling stuff from scratch... building a Linux From Scratch system is an EXCELLENT (albeit time-consuming) way to learn the system inside-out.
I personally don't really compile much from source, mostly because I don't have the time. My own P4 desktop machine runs stock Debian, which is compiled, as far as I know, for a 386. I compiled my own kernel, though, but everything else is basically unoptimized for my hardware. Regardless, my system seems pretty speedy; my box is decent, 2.6 ghz, 512 megs of ram. But would I see a significant advantage if I were to compile everything from source? Does it dramatically increase speed, or is the difference mostly imperceptible? I haven't used Gentoo (but am interested in maybe trying it), so is there an advantage to speed for using it?
don't know about build vs. packages but I do know about professors.
do it the professor's way!
It comes down to a choice of what you want to spend your time doing. Do you want to maintain the software on the machine and be 100% responsible if anything breaks or do you want to install software to fulfill the requirements placed on you and then move on to other things?
Building from source is deceptively simple -- it gives you the most flexibility from the start but, if you're like me, you'll spend more time later trying to remember how (or why!) you built a piece of software they way you did.
I think this also depends on who's installing the stuff. I'm not a linux nut. Perhaps a hobbyist wannabe, but a lot of things are still beyond my motivation to deal with. I've got a project going to build a MythTV box.
:/
:)
I stared trying to install Debian, as I understand MythTV's core developers use Debian. The OS installed OK, but I couldn't get X to run with my Radeon card well, only being able to get the generic VESA drivers to work with it. Not very good, and I eventually gave up.
My next try was Redhat. Probably in the 8.something time. The OS installed pretty good, and easily set up Radeon drivers for me. But I couldn't get Myth installed. And I gave up.
Now I'm trying Gentoo. Fought with it for some time, gave up on Radeon and gor an Nvidia based card. The OS installs OK, but I again had problems with graphics drivers, but a couple weeks ago somehow finally got things working with X nicely. I don't know what I did different, or what I did that I didn't do before, as I was going downthe install checklist printed from Gentoo's website. Seemed to be OK, so I went to ebuild mysql which MythTV requires. I can't figure this thing out, the ebuild "completes" with one error, which I can't find a reference to exactly what happened. I've started the mysql interface which appears to work, but some of the setup instructions fail on sql server not found problems, even though something from mysql is running a new command line interface. I have no clue what's up, or how to fix the ebuild error. So as I've done a couple other times with Gentoo, I'm now waiting for someone else to fix whatever is wrong. I'm not motivated to do it myself, I'm annoyed that some ebuild that should work doesn't.
I may try Redhat/Fedora again, or perhaps Mandrake as I haven't had a go with that one yet.
For you, always going from source might be OK. For certain things, always going from source is probably OK. For me, I'd probably have a working MythTV box if it wasn't such a mess. In my case, for me, precompiled stuff would probably be easier to install, as I wouldn't have to worry about compiler versions, compile times, etc. Might not be "optimized" for my exact hardware set, but should be usable.
If the ebuild stuff in Gentoo gets working more reliably I'll be happy to do that, but for now I'm about to give up on this Gentoo distro as well. I may give it one more go withthe newer 2004 CDs, as my current install used the 1.4 CDs and ebuild updated to 2004. Maybe something got left out of that update, I have no idea how to know. Don't much care, if a fresh 2004 install doesn't go then I'm done with Gentoo.
And I would never ask my mom to use Linux and install everything from source. If things reach the point where she could handle that, maybe source-only distribution of stuff would be great. For now, all it's done for me is give me headaches and pull my hair out.
My general idea is that if a pre-built binary is available, unless there's a good reason not to use it, I use it. The pre-built binaries are not always 100% cool, at least according to some people, but they tend to work for me in most of the cases.
I'm usually using prepackaged binaries if they're out there in a reasonably well-documented repository - that is, included in Debian, in some rare cases I might even consult apt-get.org.
For stuff that Debian doesn't yet have, or that absolutely insists that I build from CVS, there's always GNU Stow for easy management of stuff. I also build kernel from source using make-kpkg (because, once upon a time, it was a great Heresy to use the Pre-Packaged, Unoptimal Kernel, and building the kernel seemed to be everyone's baptism by fire so to speak).
The reason I'm often relying on pre-built binaries is that I'm a very patient person except when installing software (having had a share of installing proggies for friends and relatives tends to hurt one's very being), and I just prefer to have a quick and easy installation.
Building from source always seems to involve installing required development kits, and then million and one little bits and packages in semi-random order. There have been some pathological cases like mp1e / rte / whatever the hell it was that seemed so complex and convoluted that I needed a week's rest after that, or something like that.
Then there have been cases where I haven't been even able to build the things due to system constraints. Back in the early days of GNOME, it was hell to try to compile MICO on my Pentium 166MHz when I had meager 32 megs of physical memory, and trying to grab the last available bits of swap space from my 6 gigabyte disk... Oh, and this happens ocassionally even on recent times: I was unable to build Ardour on my current machine. Glad I found it from apt-get.org, and it's now in main Debian tree too.
I'm just secretly hoping that Debian goes i586 instead of i386 some time...
I tend to build all my important stuff from source. In other words, server daemons and things that I really want control over. But when I feel like installing pretty much any GUI software on a desktop box, I tend to use packages. I would do it all from source, but the sources for these types of software are huge and, as I see it, hardly manageable. Also, it tends to take forever to compile them, as each source files relies on about 50,000,000 others in GUI applications. Finally, desktop boxes aren't so important to me that I'd need any serious degree of control over the installed software that ports or packages don't provide.
However, when it comes to anything non-GUI, I strongly prefer to build it for the specific application from sources. I like the ability to apply security (and other) patches directly to the source, so that I am able to stay as far ahead of '1337 h4x0rz as I can. There are also many fine patches out there to add various functionality to various software, and I don't see how installing from packages allows you to take advantage of those things (unless there is a version of the package that includes certain patches). So there's my two cents.
I ran gentoo for a while (and still am on one machine), and while the amount of customization that is possible is wonderful, I just don't have the time to be constantly compiling things to keep my system up-to-date.
I've recently installed ArchLinux and I think it provides the best of both worlds. It is a primarily binary based distro, but makes it very easy to build those packages from source, if you need to tweak something.
The package builder is very straightforward. I've only been using Arch a few days and have already built a number of custom packages.
If there's a suitable package, I prefer that. When I want to upgrade it's a simple up2date/apt-get/upgradepkg. However, if I want something that either doesn't have a package, or has an outdated one, then I compile.
Slow down, cowboy! It has been 4 hours since you last posted. You must wait another few hours.
...that you need to do both. built it from source, then package it so you don't have to build it again. to help with the process of compiling and packaging you can use an app i wrote called autopkg.pl.
This is only somewhat related, but hey, this is Slashdot.
I was recently setting up a firewall/gateway machine for my parents and was annoyed to discover that the modem they were using had no free linux support. I had to buy a driver for it (for a reasonable price, mind you). I was then even more annoyed when it turned out that the driver installer needed gcc and kernel headers.
In retrospect, I guess it's understandable, and I'm not going to second-guess the people who decided they couldn't distribute a set of object files, but I still balked at having to install a compiler on a firewall.
My own gateway box, I'm glad to say, doesn't have gcc, binutils, and other such nonsense installed on it. It's as spare and as focused on its role as I can make it. Fewer packages, fewer security holes.
Accountability on the heads of the powerful.
Power in the hands of the accountable.
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.
I simply haven't changed it because I haven't thought of a better one.
Really it depends on the hardware and machine that you are running. If you are looking to stability and ease of maintainance then you will be installing older versions of software that most likely will have a nice package built somewhere.
/. peeps are good enough to deal with any difficulty) then you are probably less concerned about stability and want to hit up some bleeding edge software. In that case you will obviously want to build from source.
If you are running a personal desktop (I'm assuming that most
Besides availability there isn't much reason to decided between one or the other. Of course if you are trying to get beta software running and need to apply a patch, I think we all know which woul dbe easier, but with stable software in maintaince mode it really doesn't metter.
Required disclaimer: I use Gentoo. For me it was the easiest distro to get working and continue to maintain. I've been able to handle all of the major upgrades of the last year (2.6 kernel, KDE 3.2, tons of other stuff) without harming my existing system. I don't know many packaged based systems that can do that (though I admit I gave up on packages after only about a year). I looked at Debian, but with Gentoo I got KDE 3.2 the day it was released.
Ok, 3 days after it was released if you count compile time, but it was a nice excuse to go to the lake! And yes, you don't have to install from source if you don't want to, you can distribute the compilation across multiple machines and all the other statements I'm supposed to make.
Package implementations as of right now simply don't work well. Broken package trees should never be acceptable.
Source? Please... The optimizations achieved from compiling a program with -i486 versus -i686 is not worth forcing compile time replication on every machine. A much better way would be to have the developers cross compile to every platform themselves on release so end users don't have to waste their time.
In sumary both are wrong.
What, like eleven?
Patrick Doyle
I mod down every jackass who puts his moderation policy in his sig. Oh, wait a sec....
#portupgrade -a
or, if you prefer packages
#portupgrade -aP
Even Jesus hates listening to Creed.
This isn't an either-or situation.
.src.rpm files will use the ./configure provided with the package, which will generally figure out good defaults for your system, and you can further tweak this with your RPM macros.
One of the main design goals of the RPM system (the most common package format, used in RedHat/Fedora, SuSE, Mandrake, Conectiva, and others) is that you can reliably rebuild packages in an automated way.
The meta-data provided by a package system is essential when maintaining production servers -- you need the ability to easily figure out which package owns a given file and what will break if you change something. This is not nearly as critical for a home machine, or a system that will not be running for years, gradually upgraded over time.
If the binary package works for you, cool. If you want to rebuild with the latest libraries and better optimizations, or for a newer architechture (amd64 vs. x86 for example), then go for it.
Most
If there's no RPM for something you want to install, then create one! It will take you half a day to make a really good RPM the first time, but just an hour the second time, and you'll have it down to 5-10 minutes + the compile time after your first dozen.
And to get out of dependency hell, use yum or apt/synaptic.
When you use binary packages you are generally at the mercy of how the maintainer decided to build the package. Want mysql with --with-lo-mem? You're stuck either without it or stuck trying to find someone else's build. I understand the need for binary packages. How many people would need coreutils with a specific build option? OTOH, how many people need Apache built a certain way. If you're using a binary package with something like apache that probably needs to be built for your needs, you done missed the boat.
Fedora PERIOD is not a stable or production server. It's fine to play around with, but for serious tasks where stability is a necessary quality, Fedora ain't there. And, as an experimental Linux distro, it's not surprising packages are not up-to-date. Not a flame, just pointing out that Fedora is the playground distro, you get what you get.
"Who are in control, they are not in control of anything - they don't even control themselves!" - Glen Beck
Some of my targets aren't all that fast so cross-compile or use a binary.
Nothing in the world is more dangerous than sincere ignorance and conscientious stupidity.
If the program is available for my favorite distro (Debian) as a package I will use the package. But if there isn't a package available then I use will compile from source. But as most of the other posters have pointed out it also depends on the program and if I am testing it or if it is for a production system. If it is for testing then I take the package over the source if the package is available. But I, like many others here, will usually compile from source if I am going to us the program in a production environment so I can get the pest performance for my system.
"Really, I'm not out to destroy Microsoft. That will just be a completely unintentional side effect." Linus Torvalds
is to use the Click-N-Run warehouse from Lindows.com. They have all the coolest apps in there.
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.
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
90% of what gets installed when you use Fink has nothing to do with what you're installing.
I've given Fink a shot on a couple of occasions over the last two years, and every time I've invoked it, it's come up with false dependencies. X11 is not necessary to install, say, the Python interpreter, and there've been dependencies far more ridiculous than that.
I've had the same problem with the CPAN shell. RPMs, on the other hand, seemed to fail to install necessary things.
I build from source, then, simply because I don't trust the dependency handling from package managers. It's true that I have to pay more attention to such nonsense and would love to have it automated, but until I find a package manager that gets dependencies right, I'm going to have to do that anyway.
Tweet, tweet.
Hey, those are nothing. Wait till you emerge kde.
I preferably use packages from the distro I am using, as they have more support, security updates, and easier to manage (install, uninstall, update).
If I need some missing feature or package, I modify some existing package (preferably based on the original package from the distro I'm using), or create my own package. I think that controlling what is installed or not on your machine and a quick and easy way to upgrade, install or uninstall it, is essential.
God intended man to compile from source. It's the 11th commandment.
I admin 20 or so SUN v100s and a few SUN 280Rs. Our production servers dont have compilers on. why run the risk?
So i make my own solaris packages or use ones provided by sunfreeware or blastwave depending on what i want.
So for those apps which need compliling specially i can. then make a pakage and move them out to my identical machines
True Story.
/etc/fstab /boot/grub.conf /etc/X11/xdm/ stuff (cause he liked my login screen)
Me and another guy at work are handed Compaq Evo N800c's.
I decide to go the Gentoo route while he picks Debian. Nearly three days later I get finished and I have everything I want. Granted, I spend an extra day on tiny piddling shit. I always do a brand new custom xdm config with some sort of eyecandy, and I make a custom fluxbox theme based on the machine name. I name my machines after anti-heroes from popular media. This one is named Alucard for example. Either way, I had my menues customized and all the applications I prefer for each thing. I even had OpenGL configured for the ATI stuff and quake3 running reasonably well at 800 by 600. The Debian guy? He finished about the same time after he got sick of messing with things and borrowed:
My kernel config
My XF86Config
My
My
My
And this was a pretty bright guy who had been using Debian for in his words "Since the dawn of time". So I guess it's all how you look at it. No matter what distro I'm going to use, I'm going to customize all those little nit-picky things that drive me nuts exactly the way I like them. I could have rushed and done a stage 3 install and been done in a few hours, then spent another day getting all my apps straightened out and never been quite happy or felt as good about the install. When it's a machine that I'm going to be spending 10+ hours a day making my living, I want to be damn sure I'm going to love it and there aren't going to be any surprises.
For every annoying gentoo user, are three even more annoying anti-gentoo crybabies. Take Yosh from #Gimp for example.
Bill? Bill, is that you?
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
If you are a masochist, then going completely from source is the way to go. It's strange timing, but I'm trying to get squid & squidguard working together as a filtering proxy server, but lo & behold, it's all crap. Using Mandrake 10.0 (Community, of course), squid will install very nicely from source, as well as BerkeleyDB. SquidGuard, OTOH is a different beast entirely. I tried compiling it the first time, it said there was no BorkeleyDB installed (there was). I reinstalled DB, but SG still said it wasn't there. I even told it exactly where to find it (--with-db, --with-db-*) -- no dice, it still claims it's not there. So I decided to reinstall the OS... for some reason. Now, it found BerkeleyDB before it was even installed, but "make" dies when it tries to use db.h (something about wrong # of arguments). This is even more undocumented than the first error. I found three pages about the current error, 1 was in French, one was in German, 1 English -- all were message boards, none had answers.
Well, I used the squidGuard RPM, after bitching to an ignorant website owner who would not let anyone download the file if they changed the browser info string -- he said it was so Windows users couldn't get their hands on it. What a fucking moron, RPMs are useless for Windows users... Anyway, the cache buildng (squid -z) went fine, and I was able to add the redirect_children line, but the damned thing just starts up & shuts down without doing anything.
I opened the port (3128) during the second install in addition to ssh & ftp, but after it's done, all ports are shut down, there is no documentation to be found on how to open them up. Supposedly Shorewall should be the problem, but the ports are all open in it. At least I never had this problem in RedHat (but I certainly had others). Fuck you, Mandrake... Fuck you in your useless, nonfunctioning distro ass. And I had heard so many good things about Mandrake...
ANYWAY.... my point is this: compile from source only if you are able to build all of Linux from source (old slackware-style, no installer). If you can't do that, trying to install software from source is usually a waste of time -- it NEVER WORKS. I'm not saying that just because of this experience, but with experience from many different Intel/AMD PCs and 2 Sun SPARCs.
If you aren't already a fucking genius & can fix bugs in preexisting software, and aren't lucky as shit, use packages. It saves so much time, headache, and vocal cords since you won't be screaming obscenities at the poorly-designed compiler scripts.
Some packages are a bigger pain in the ass, though. If you decide to install any software by hand, you had better not rely on it in future package installs. As per my previous example, I had to install SG with the "--nodeps" option. If you hadn't installed the dependencies with the package installer, future installs will refuse to accept the possibility that the software might possibly already be installed (my only experience with this is RPMs, but this PITA hasn't changed since at least 1998).
Think Linux is really ready for the desktop? As soon as I can install any software like this without jumping through a million hoops and reading a dozen novels, it will be ready. Right now? Not. Fucking. Close.
I won't repeat what everybody else said, but here's an extra point: Since Gentoo builds everything from source already, it naturally makes building from source very easy!
./configure && make && make install really trivial, and contains some helper scripts for making the installation of things like Perl modules much easier as well (automatic downloading from CPAN for instance)
The good thing about that is that if you happen to need a program that's not in Gentoo, it should be trivial to make an ebuild for it, if it's not made in some horribly unstandard way. And most likely all the development files and tools will be already installed.
Gentoo's got a great system that makes making packages that can be installed with
so expecting it to turn FP math code directly into SSE/2 code isn't going to happen unless the programmer coded it that way.
As I understand it, yes...glibc, gcc and all ARE compiled from source. I think it does this during the boostrapping process.
And no big deal...when I'm compiling on machine, I just hop on one of my other boxes. You can pick up extra boxes for almost nothing these days. Right now, I'm playing with Sun Ultra2's with Genoo...got a dual 300 mhz processor, 1G memory for just over $200....and it is pretty zippy so far....so, just get another couple boxes..just install/upgrade one at a time...
Light travels faster than sound. This is why some people appear bright until you hear them speak.........
I find the biggest problem is that when I try
./autogen.sh --prefix=/usr/local;make;make install;
:)
to build something from source it usually
requires tones and tones of dependancy's
Debian is great in this regard because I can
almost always find the needed dependancys in
apt and then go ahead and compile the CVS code.
I just did this with gimp2.0 the other day,
it required tones of devel package dependancys
all of which I was able to quickly and easily
install with apt, then it was a simple matter
of opening the gimp source and doing:
Voila! Gimp2 on Debian Sarge
Applications - build from source.
/usr/src in case you want to recompile later with different options or uninstall the application.
Things applications depend on - install packages.
Libraries and things of that sort tend to have complex dependency relationships with other libraries and applications. I tend to let my distro worry about that sort of thing.
By compiling the application from source, things tend to go a lot smoother (surprising, I know) and you usually get a more recent version of the application. Just keep a copy of the source under
who are those slashdot people? they swept over like Mongol-Tartars.
Just the fact that you are discussing this shows that you people are idiots. Installing crap on linux takes forever and it never works the first time and usually not the second. There needs to be an install icon like on real computers that run windows.
Many others have stated already that a combination is most likely best. I switched to source based distros for this reason:
Package systems (at least the ones I tried) are great, until they break. Or until you run some hardware that needs the latest version of an application. Then you have the choice of either wait for your disrtibution to catch up providing a package the newest version, or download the source from the apps website and compile it yourself - and hope it still works.
Unfortunately my experience is that when you compile some applications from the original source and mix it with dependancies installed as packages, things can break. This is really frustrating because you either have a choice of not using your new hardware for a while *or* spend hours trying to figure out why that dependancy broke, only to arrive at the conclusion that the distro vendor heavily patched some lib and now it doesnt play well with others anymore.
After years of using Linux exclusively, I have arrived at one single requirement my distro has to provide:
It has to allow me to download any application source from its original website, compile it and have it not break anything dramatically.
What works for me in that regard is Gentoo. Your mileage may vary.
Cheers,
Andre
bah! 14 hours for glibc, gcc, and kernels from source?!!?!?!
I run gentoo on a PIII 733 and the bootstrap "only" took 4 hours and kernel compiles literally only take 10-12 minutes.
A fresh stage-1 install may take me a weekend, but that's mainly due to the comp sitting there waiting for my next command, as I don't hang out every minute and watch source compile. (it is fun to do though!)
I admit that compiling everything can be a pain in the butt sometimes, but I have no problem letting my computer start compiling the big meaty packages before I goto bed and let them have fun all day while I'm at work.
Still though, I use some of the bin packages for gentoo. OpenOffice would take 30+ hours to compile on my computer so I use the bin. But xfree only takes about 2 hours...and that's not so bad. Small price to pay for improved performance.
>of "known good" binaries if you have a
>suspected intrusion problem.
A rather dangerous assumption to my mind, this one. I've heard of Red Hat releases in particular making it to the shelves while still having at least the odd security flaw. Of course you're not going to have time to go over it with a fine-toothed comb, but if you know how to read code I'd give at least really critical apps a cursory once over. It's better than your system going down or being invaded by some anarchistic 14 year old, anywayz IMHO.
As well as the security/stability issue, one of my main reasons for changing to Linux has been the level of customisability. I suppose we can let overworked corporate sysadmins off the hook for wanting to use predigested distros, particularly if they have to deploy to a lot of machines, (even the most broken distro release is likely to be infintely more secure than the IE+OE knock-out punch ;-)) but I'm not sure anyone else wanting to call themselves a respectable Linux user has an excuse.
To me, compiling from source is one of the main reasons for using Linux. The ability to compile exactly for your CPU and particular environment, coupled with the security of knowing that what you're getting is exactly what you think it is, and not something that's going to turn your system into a script kiddie gang's next 0-day ircd.
If you need something that can be deployed on a lot of machines, buy standard hardware that you know Linux supports, (avoid exotic Winmodems, onboard cards etc) prototype from source on one machine, and then mirror it to the rest. To me, a secure, stable, well-configured system is something that cannot and should not be attained in five minutes, and any corporate sysadmin who thinks it should be possible, ought to look for a career change. Just as it's true that in the rest of life there is no such thing as a free lunch, when it comes to security, the emphasis should NOT be on short cuts.
I would really like to know what are you saying here. Every package from the Debian project has its corresponding source package. What packages are you talking about?
BTW, if I need a modified package, I like the sequence:
>That just means that you'll have to store the dependancy databases in your head. ./configure has told me. Red Hat is dependency hell. They take single packages like Xfree86 and break them up. So you may think you have Xfree86 installed, but you may not have the particular library a package needs. When I compile XFree86, I compile XFree86. Not some stripped down version that's going to cause problems later. Maintaining packages you compiled yourself is not difficult or dangerous and many would like you to believe. If I download gaim and build it with ./configure, make, make install, that's how the original progammers meant it to be built. When you get an rpm, you are getting it through the grapevine with red hat patches and modifications the original authors never intended.
Many people who use binary packages make this argument, but it's simply not true. The gnu build system (despite what many people say) is VERY good at finding deps. I've used linux from scratch for a lot of speciality servers for a long time. Anytime my libs have been out of date,
I'm running Slackware 9.1 on my laptop, when ever I need to install a package I first look for a slack pack. If none are available I then download the source, ./configure && make && checkinstall. Checkinstall then spits out a nice slack pack for me to install or uninstall without any hassle. The benifit of this is that I can configure the build how ever I want but still have a nice package to install and uninstall when ever I need.
Checkinstall can also make .debs and .rpm.
Do what your professor wants. Why you ask? Because its your damn professor. He will be happier with a package management system that he feels comfortable with. This will make him happier with you. Do not trifle with the grey beards, they have powers you do not yet comprehend.
I, myself, am working with a professor on a momentum problem generator in Perl (we're physics people) and I was given a nice equation solving library that he wrote for another issue. I've showed it to a number a people with years (1 or 2 near a decade) of experience with Perl and they said that it was some of the worst code they had ever seen. I thought the way I had to interact with it was stupid and klunky. One giant kludge. I fought it in my own head but tried not to let my emotions about it out in front of him. So I worked at it again and again and you know what a few months later he, a peer of mine and I will be doing a seminar for our deptartment on it this April. The code wasn't as awful to work with as I thought (though to this day I wish it wasn't so klunky) and it worked. I just had to suck up my pride and get it done.
Don't argue with them. Make their lives easier and you get to see the grey beards happy side. May you have many publications in your future.
Most of the time, optimizations don't buy very much unless the server is really busy. The primary reason to use source is when you need features or compile options that aren't available in regular package.
In those cases, the right thing is to grab the source package, customize to taste, and then build the binary package to install.
This is especially important if you use the packaging system AT ALL. For example, if you use apt to fetch security updates, you really want it to know about everything that might depend on a given version of a library. Otherwise, things will break with little warning. On a server, that's a real problem. So is never doing security updates out of fear that something will break.
Having the modified source package also means that you have an exact record of how the source was configured, built, and installed. That's helpful when you need to upgrade since the patch and such may apply without issues. If not, at least you can look at the .rej files to see exactly what you need to do the get things the way you like them.
The only exception would be for software that you KNOW you will never need to install anywhere else and will never need to upgrade or re-install for any reason. There's not much of that.
Once you get used to the packaging system, it really doesn't take much longer than installing by hand, and if you have more than one machine to install, you'll come out ahead.
But the best part about Gentoo is the Forums, it has an incredible friendly userbase with a lot of knowledgable people who are willing to help you out with anything, even questions about other distros and Windows. How many other Linux user forums do that?
If you mod me down, I *will* introduce you to my sister!
I do packages when available and use whatever package management system available be it apt, fink, darwinports or whatever and I use whatever format for the packages that the management system needs if there is one. I have used rpm, darwinports,deb and llp(AIX). Packages with a management system allow you to easily install and uninstall items when you need to. They also ease upgrades.
Gorkman
All that "optimization and control" that you mention can be perfectly achieved through packages. /usr/lib/libBlah.so.1.2.3? No problem, just do a "rpm -qf /usr/lib/libBlah.so.1.2.3".
I make my own packages, and i can customize them as much as a pure-source install.
Custom gcc flags? No problem, just edit ~/.rpmrc then rebuild the package. I build most of my multimedia packages with "-march=athlon-xp -mcpu=athlon-xp" (and some other flags as well, depending on the package).
Custom package layout? No problem, just modify the spec file.
Wanna know which software owns the file
Etc, etc.
As a bonus, because everything is installed from packages, uninstall/upgrade operations are guaranteed to be clean. And you are certain you can revert the system to any given state, should you have to, with just a set of simple and standard commands (no custom scripts required).
Everything you do straight from source, you can do with packages, with the added benefits of uniformity and easy automatization.
I used to install from source myself. I've found, later on, that the package approach is actually the cleaner and the more controlled one. Now i install pretty much everything (like, 99%) from packages. Many of those packages i build myself.
I used to maintain 100+ distinct servers with packages built from source. It was a full time job taking at least 50 hours a week.
Now I use apt-get and build rpm packages from source for distribution to all those machines. I get paid the same and only spend about 5 hours a week maintaining packages.
I'm using my free time to create a chocolate dessert recipe book. YMMV
The original poster has obviously never dealt with any number of machines. Building from source (with or without a package/ports system) is great fun for a single user systm. Once you get to multiple multi-user systems, it's just not worth the trouble to optimize one program by 5% when nobody ever cares about speed, just that they deleted an important email they've had sitting on the server for the last 18mo and never bothered reading.
For some things, building from source is unescapable, but with a large number of systems what you want is something that can easily be done itendically to any number of systems with little to no effort.
Right now, at work, we're trying to transition over to a system that uses Debian with FAI to do roll-outs/reimages and Cfengine to handle updates & other administrative changes (all the while, putting config files in CVS). About the only thing that's going to be custom compiled is going to be our kernel and we're only doing that 'cuz we like some custom patches applied to it.
my sig's at the bottom of the page.
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 &
Hey, you get the best of both worlds... easy install, maintenance, uninstall; plus everything is optimized and you still get to say that you build from source "just because you can".
We'll make a Debian package maintainer out of you yet!
That said, perhaps you two can come to a sort of compromise. You didn't say what distro you're using some I'm going to assume you're using Redhat. You could use RH's source RPM functionality to both compile packages the way you want them compiled and yet make it easy to distibute them to other machine and update them with little overhead. It's not too terribly hard to do. Frankly I won't ever do it this way but I can understand if someone does. I currently maintain an identical directory structure on all machines of tarballs (NFS shared of course) and host-specific source files (exploded tarballs in an organized fashion of course). I can quickly copy and paste the previous ./configure options from the older release (after reading the Changelog and docs) and get that package compiled and installed within minutes. A few minutes per host doesn't hurt me any.
Personally I'm looking into switching to Gentoo. It sounds like it matches my style of administration better than RH (anything's better than RH). You might consider trying it out as well. portage is supposed to be excellent.
The Whole point of a package system is a self documenting database.
Whether you choose to delude yourself into thinking you can do it all or not is the entire point.
Simply asking the question answers it.
Simply you don't know how to use a package manager. To debate it is irrational until you know at least one and fully understand why they are useful.
I think you will find once you actually use one, the question becomes irrelevant.
Put simply, there is an easier way, and your not using it.. so your choosing to to use what skills you have rather than exploring others.
Tips and tricks, and hints and clicks will only get your so far.. sooner or later you'll come to understand "why" package managers exist and "why" they are so often debated.
As for the package manager debate.. my opinion is the jury has come back in.. and RPM currently reigns over dpkg.. though there are easier interfaces to use it.. and YaST seems about to eclipse most.
The build process for RPM is far from well documented.. regardless of the virtual trees sacrificed in its name.
Once better tools emerge for using RPM.. perhaps even as an add-on to the Eclipse project.. it will just generally be accepted like rc scripts and tarballs.
see subject line.
what?
You ignore the handy-dandy source package management systems of many *nixes. Gentoo, Lunar Linux, and many more have excellent ways of watching where packages, tracking dependencies and versioning control. Obviously, if distro is not a choice than we have a problem.
When I compile a package against lib-whatever-3.1.17, the rpm will not work unless you have lib-whatever-3.1.17 EXACTLY. This is annoying as hell, because I may have lib-whatever-3.1.18, but it won't work. Yay, fun with symlinking time. With rpms you need the EXACT lib, down to the minor version. With the Gnu build system, you almost never need the same minor version, and in many cases (e.g. Gtk) you don't even have to have the same major version.
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.
What configure options were passed? What was the env like (CFLAGS, LD_LIBRARY_PATH, etc) during the compilation? What does the program depend on, or can i safely upgrade/delete any other lib's on the system? Sure you can troubleshoot these issues (most but not all packages make some issues nicer, like having a config.log, some record other info like phpinfo(), and really good admins may have run script beforehand, recording their steps), but when dealing with a lot of machines, it's nicer not to have to.
A good packaging system allows you to not have to troubleshoot those issues, plus it gives you the luxury of going to a mailing list and saying "i installed rpm version X.Y.Z of ABC package and am getting this error. what's up?" as opposed to "I compiled ABC v. X.Y.Z with the options --really-obscure-shit and now it's not working, what's up?" Generally more ppl will understand and be able to help with the rpm than with some uniquely compiled package.
Well for my production systems, both Solaris and Linux systems I use packages for most everything. Unless I need something very special and specific. or if I don't feel like screwing around with building something from source.
For test/development and personal machines I tend to use src more often.
I started playing around with Gentoo and I find that I am quite fond of the whole system, it's package system is quite elegant compared to RPM.
From what I can see, it seems to have the best of both Debian package system and FreeBSD's ports
As with everything, everyone's mileage may vary.
"Everybody who is incapable of learning has taken up teaching." - Oscar Wilde
My personal experience is that installing packages has several advantages: it's quick and simple, it provides an index of what's installed, and the dependency graph of software is more sound than what I keep tucked away in my own brain. There is nothing wrong with packages, and you're not apt to loose out on much performance by using standard packages.
However, there is the rare occasion where a tweak is absolutely necessary -- such as to apply a specific patch. In that case, I generally download the source package, edit the package specfile and build a new binary (which I then install). I advocate this because it keeps the package management uniform and still lets you audit what's installed. Moreover, I can then move the package to a repository whereby other machines will see it as a new package in their software management tools.
In a few cases, I've needed things not included in my distributions (yesterday, for example, I needed the OCI8 module for PHP -- which Mandrake doesn't provide for MDK10). So, what did I need to do? I downloaded the SPEC file for php-gd from the Mandrake web-site, changed all references of 'gd' to 'oci8', and modified the PHP configure options. In all of 5 minutes I had a binary package for the extension module and had it up and running.
I even find that I make simple SPEC files for commercial apps that don't do RPM just so that I can easily reinstall them elsewhere and audit what I've got installed on each machine. This is especially true for things like ffmpeg-cvs and such (where no distribution tracks the package).
Compiling completely de novo from source without any mind towards packaging is relatively rare for me these days.
With one of the largest Linux installs on the University of Minnesota campus I end up using packages to deal managing the machines. For optimized kernels I have some detetction to make sure SMP/non-SMP is installed. Otherwise, everything is compiled for i386.
If I were to want 'optimized' packages, it would have to be for PPro or better, nothing higher. Too many variants would be a nightmare to manage. Alternatively, only provide optimized versions of libraries or binarys that choose themseves at runtime when it matters. IE: don't worry about ls, worry about media players, computational applications, etc.
-- dieman - Scott Dier
I tend to compile on machines that are older. Primarily because I'm trying to get as much out of it as I can. Another one of the deciding factors is availability. If the machine needs all of it's cpu all of the time it'll be hard to find time to compile.
So that's how I decide what I'm going to do on a given box. One thing to keep in mind is to see if you can choose different distro's depending on that decision. Like using Red Hat on a box you're going to use packages on and Gentoo on a box you're going to compile on. Gentoo makes it really easy to manage compiled applications while rpm is a good package system. That can make all the difference so long as the staff has the expertise to use multiple distros.
"Let him go, Ralph. He knows what he's doing." --Otto Mann (simpsons)
While I agree, I think half the people using Gentoo have no business using it. Most people don't understand gcc optimization flags, don't make their own ebuild files, don't set up their own esync server, etc. etc. They might as well be using GRP packages, yet they compile their whole OS with default flags.
Are you talking about non-CAEN (computer aided engineering network) comps? When I was at Camp CAEN last summer, we did our work in Pierpont. The machines dualbooted XP and a customized (but still RH based) version of linux called BlueHat - definitely not LFS-based.
I forget what the library computers were like, but I don't think they dual booted at all, so that's what's making me wonder.
the OP should be modded -5 flamebait?
I admin close to a hundred Sun and Linux boxes... mostly Sun. They all get packages... Not only does this save time, but it also makes documenting everything for the boss/legal dpt. easy.
I do use source on my personal computers however
is really the source that is compiled on a machine that will be using it optimized enough to warrant the administrator's time and effort in compiling code every time a small package change has to be introduced in the system? not in my experience, i used compilations for a period of time before moving onto rpm based distributions, the dependency thing is annoying at times, but in short, it makes sure (almost!) that my system won't break down after applying the package. the optimization in compiled packages either is nothing to write home about except when the system is so optimized that there is nothing else except this that can make the difference, which i am sure most of us will agree here, our systems need a lot more of housekeeping and time and effort to upgrade them to this status!
i live on an alternate planet
Based on the article yesterday about too many choices, and based on my own frustrations with figuring out how to install stuff in linux, I think that Windows has Linux beat hands down in the installation department. All I need to do is download the setup program, run it, and it'll put the program into a new folder in Program Files. Sometimes it asks if I want shortcuts on the desktop. That's it. I don't have to worry about optimization features, I don't have to worry about it not compiling. I don't even have to worry about putting the program in a weird place. It does it the same way every time. Now tell me Linux will let you do that with any program you want to download and install. Grandma doesn't know how to use a console, and she's certainly not going to know all the commands you need in order to install the program.
I run a slackware machine. What I like to do is download the source files. Then I will make a package depending on what options I set. The source files I create go into /usr/local/src while when the done finished package goes into /usr/local/tgz.
:)
This way, its easy to install and unistall programs I dont need with 100% customization
Yep. If you want RedHat but don't want to pay the price, look at WhiteBox Linux
as a side note, this feature is about to be finalized in lunar-linux : http://lunar-linux.org/.
Go check it out... there's much more than *just* ghettoo. Some of these:
http://distrowatch.org/source.php
are even better than ghettoo!!!
Hi, Richard. Will you marry me?
One reason I like to install from source that I don't think gets talked about much is dependencies. Usually this is given as a reason to use pre-compiled binary packages. But I think it is the major flaw in binary packages. When you have, say, an RPM the person who built it and declared its dependencies is usually one more person removed from the package's author or the person who writes the "configure.in" file for the souce configure script. This leaves a lot of room for the dependencies to get screwed up - your rpm installs but really needs something that's not there or it won't install because of something you do have but was written into the spec file incorrectly. However, running the configure script yourself is a much safer way to resolve dependency issues, even if it is much more time-consuming. And if the configure script is incorrect, compiling almost always lets you know right then that you need something else. As long as the program doesn't load things with libdl itself, you're ok. And in that case, the programmer is probably checking for plug-ins - which by definition don't need to be there. Generally you can be more sure that something will work correctly if you can build it yourself.
http://lunar-linux.org/
the installer is maybe not friendly enough for you, but maybe it is.
One thing I always wonder about that's not quite addressed here is the issue of multiple networked workstations. Suppose I run a small college lan of 20 boxes. I want them to be identically configured. Now if I install gcc on all of them thats 20*install_size_of_gcc bytes of wasted HD space. So its better to install gcc once on a nfs mounted /usr/local. BUT most packages don't support installing to admin-specified locations. So ... hm ... build from source?
So if you like compiling you would like FreeBSD Unix and/or Slackware Linux. Your teacher, as he loves binary packages, he/she would like Debian GNU/Linux. I recommend you FreeBSD, as IMHO is faster than any Linux distro (even Slack) and tends to be more stable as well. Thanks to the FreeBSD ports you can install anything you want from source. They have the largest collection of open source software (larger than Debian's). www.freebsd.org ;)
OK, I am as far from an expert as you're likely to find, but why put all your time in building?
If you're not doing rocket science, if not every little bit of optimisation is needed, spare yourself and your colleagues major head-aches and make a nice, decent, easy to install package.
In general, lack of decent, simple stupid installers are what keeps a lot of OSS from the average user's computer.
I think, therefore I am...I think.
http://distrowatch.org/source.php
there's *much* more than just gentoo out there people!
other source distros (there's much more than gentoo!!!) are often even much faster than gentoo, like lunar for instance. to compare: http://distrowatch.org/source.php
...but what about Debian? With Debian, the focus is on managed packages, but you still have the option of compiling from source, whereas Gentoo seems to be the opposite (compilation, with an option for packages). In fact, apt-build is far easier to use, in my opinion, than RedHat's system for compiling source RPMs.
Packages were invented to ease your workload, automatically handle dependencies for you, and allow for easier, faster, and standard deployments of software. If you absolutely have to compile from source (which, to be honest, is not that often), then at least have the sense to create a package for your specific build, such as apt-build does for you. There is no reason nowadays to avoid the use of packages, even when compiling from source.
Packages make your life easier, plain and simple.
No comment.
I'd go with a source-based distribution myself. It's been my experience that the support at places like Gentoo is, in general, a healthy cut above any of the binary distributions. Why? Source-based distributions attract, on average, a substantially brighter, more experienced crowd.
(-: Well, of course it's me. But maybe not to a 100% in this case. :-)
Karma: Excellent (My Karma? I wish...:-( )
You truly do not gain anything from a source installation. You think it does and it makes you feel good, but the performance gains will be minimum to zero. Does anyone has such specialized requires and hardware that the sourcecode needs to be optimized at the source level? No. And if it did, the research project would not be running on 'off-the-shelf' i386 hardware. Almost nobody on Slashdot appears to have a clue about actual system administration work outside of their little dorm room computers, so let's have a dose of the world outside of undergraduate school. Precompiled package's can be many things:
1) Installed over and over with the exact same options
2) Centrally archived
3) Always installed in the same way and in the same place on each and every computer
4) All files are cataloged in the RPM so you can pin-point file locations by simply querying the RPM instead of wasting time searching through source-make-install scripts or the filesystem itself
5) Installation dependancy(s) can easily be automated (urpmi, etc.) to update entire installations without spending all day and night searching and installing and linking these files yourself
6) And a ton more I don't have time to list
Someone who is doing research, such as the research I also work on, is not interested in f*cking around with computer installations. Yes, it is fun. And yes, I use Linux, because aside from OSX, it is the best OS to use and the hardware is cheap. But I am interested in research. I am interested in results.
If the person absolutely needs to compile from source, for whatever reason, then at least use a SOURCE RPM. That way, the source will be compiled, files will be located properly for the distribution you using, and you gain all of the benefits of package management.
I think an important point about installing from source is the security. When building the program you can specify which things you will be using and which you won't. That way you can disable many 'open doors' you won't need, and minimize the footprint (attack surface) of the programs you run on your servers.
;)
And about the performance difference... it CAN be considerable, many times it won't, but a few times a program will be really faster when compiled from source with the right options. So I believe you should ask yourself how often do you install new software on the servers, and how much time do you have to do so. Usually, the time it takes to compile a program in a server is pretty short, so I don't see a real reason for not doing it if you use some automated system like Gentoo's portage.
The traditional way is not always the safer, nor the best. Every sysadmin should be conscious enough to find the better way, and let go RH
than just gentoo, try lunar (lunar-linux.org) or sourcemage or even rock linux... compare them at:
http://distrowatch.org/source.php
on what you want to do. In all my production servers, I only use packages from the specific distro in use (most are debian) I haven't come to the point of the need to tweak something really weird, so no need of sources. Im my workstaion I run FreeBSD, I could just fetch all the packages for everything I need, but just for fun I periodicaly update my ports tree and upgrade everything from the source, there is not really a reason for using sources besides I like watching all the stuff getting compiled, again, is something I don't really need, but I like
I have been using Linux for 2 years now. I consider myself a Linux newb. I am not as familiar with the os as I am with Windoz. I maitain via packages.
I have this to offer.
Those that can, compile!
I am Bennett Haselton! I am Bennett Haselton!
I installed Mandrake 10.0 on a box, and went to install GAIM from source. It barfed at me about GTK, even though it is apparently installed. So I downloaded the latest GTK, but when I try to ./configure it I get /lib/cpp failed sanity check.
Now I installed all the "development" packages, and checked to make sure GCC was there, and it is, so I have no clue why I'm getting this error. From my understanding ./configure shouldn't even be trying to use cpp instead of GCC. What's going on?
"To confine our attention to terrestrial matters would be to limit the human spirit." -Stephen Hawking
I'd say, packages.
Let's some up:
1. Packages have better integration with the system (dependencies, upgrades, uninstall, etc.)
Objection: you can build your own packages, or let ports, source debs, SRPMS, emerge, checkinstall, etc. etc. do it for you.
2. Sources allow optimization, leading to better performance.
Objection: Results of optimization are virtually unnoticable for most software; differences are usually a few percent tops.
3. Sources allow customization.
This is very true if you don't have a good packager. For example, if they only provide a package that depends on GNOME, but you could build it from source withoit GNOME. or you want esd support, but there is only a package without it. Debian, however, does a good job of providing different packages, tailored to the needs of different people.
4. Binary packages save you time
Obviously, you don't have to compile, so you save time. Sometimes you might not even be able to compile, e.g. the openh323 library needs so much memory to compile that my machine can't do it. On the other hand, sources tend to be smaller than binaries (especially in compressed form), so if your download speed is really low, sources might save you time.
So, the conclusion is that building from sources is sometimes useful, but usually a waste of time and energy. Also beware that most software you build and install from source will not keep track of what files it puts where, which is a maintenance nightmare. Always put everything together in one directory, or build a package and let the package manager take care of it.
Please correct me if I got my facts wrong.
Don't want development tools on production servers for security reasons. So build from source on another box and test, once okay build a package and install. That will also help insure all your boxes are built the same.
For the number of machines you're talking about, I dunno if source is the best way to go. Personally, I've never understood the hate some have for those of us who build from source instead of using packages. If I was going to do something for a production machine though, It would probably be a package distro like Fedora or SuSE. Maybe Debian, but I've never been that impressed by it. For my own personal use, it will always be from source like Gentoo. I just prefer it.
*Fortitudo, aequitas, fidelitas.*
In short, Support? Who needs it? Not me. Do you?
Both, of course. With debian. I use "apt-build install foo" to compile and install the packages I want to be optimized, most of the time XFree86, libc, and some graphic libraries. And yes, it makes a difference (see http://www.terra.es/personal/diegocg/benchs/x11per f)
/usr/lib/gaim/libmsn.so . d if I want to get rid of XFree fb support, I delete An/usr/X11R6/lib/modules/libfb.a . I don't need to recompile with USE="fb". _Good_ software allows you to choose what you want at _RUN_ time not at compile time, and if it needs it it's just broken. There're very very few cases where you really need it (ej: a graphic app with a gtk/qt backend) and for those you make two different packages. No need to waste time & bandwith in sources more than neccesary.
For the rest, it doesn't has any sense. Yes, I'd like that debian would switch to i586 code by default, but at the end, in the x86 world, nothing has changed. The success of x86 is _that_, being the same across several version. Yes there're some multimedia extensions (SSE, etc). That's whay I compile some _multimedia_ packages (which may use or not optimization) like Xfree and the gnome libraries.
And it works. I don't see a reason to do what ej: gentoo or BSDs are doing. THe "configurability" reason is stupid: I do not need to recompile gaim to get rid of msn support, I'd just delete
i usually do the stage3 gentoo install, building the rest from source. it takes a day or two before everything's built and ready. but after that, the system is pretty simple to maintain, and if you update regularly, the updates dont take very long. i guess my point is -- ive had a history of using packages when they're easier, but if building from source is as simple as "emerge kde" or what have you, i'd prefer to wait a little longer to install, and get better performance in the long term.
flame-retardent: i know gentoo wasn't the first to have this type of system. it's simply the one i've got the most familiarity with.
-m
I'm not even going to pretend I've read all of the many responses already made to this, but I will put in my two cents...
Build once from source, and package for like machines to cut-down on the time costs of replicating work. You just can't beat the optimization benefits of compiling from source using proper build flags (e.g. Gentoo Linux), but you also cannot rationalize the time cost of repetitive actions on identical (or near identical) hardware.
Of course, there are always those packages where build optimizations are of minimal benefit. Best bet: know your apps, know your hardware, and manage your time effectively to maximize the usefulness of both.
if this does not give the aplha geeks something to do for the next millenia i dont know what will, alltho we do have the old standbys:
what is best of (select from below)?
vi and emacs
microkernel or monolithic
net/open/free-bsd and linux
"does like the turtle, ducks and covers!"
comment first, facts later. http://chem.tufts.edu/AnswersInScience/RelativityofWrong.htm
What Is suppose a cygwin user can do with a .deb or .rpm file???... I (cyg user) build everything from source, else... some prebuild stuff.
-Woof woof woof!
When I can't get a binary install then I try for an rpm install, using an rpm made for the version of the distro I am running. I used urpmi when I was running Mandrake and now that I am running SUSE I use YaST2. Even then there is a chance I will run into missing dependencies or version conflicts, sometimes so severe that installation of the app is impossible without breaking my system.
I have began avoiding the tars because even though the
One thing for sure... Linux will never replace Windows on the desktop as long as developers keep requiring users to do the stepsWhile it may be easy distribution method for the lazy or inexperienced coder, which is probably why it is used so often, its reliability is suffering because of the traits those programmers exhibit.
Running with Linux for over 20 years!
8.6 - Should I use Ports or Packages?
In general, you are HIGHLY advised to use packages over building an application from ports. The OpenBSD ports team considers packages to be the goal of their porting work, not the ports themselves.
Building a complex application from source is not trivial. Not only must the application be compiled, but the tools used to build it must be built. Unfortunately, OpenBSD, the tools, and the application are all evolving, and often, getting all the pieces working together is a challenge. Once everything works, a revision in any of the pieces the next day could render it broken. Every six months, as a new release of OpenBSD is made, an effort is made to test the building of every port on every platform, but during the development cycle it is likely that some ports will break.
In addition to having all the pieces work together, there is just the matter of time and resources required to compile some applications from source. A common example is CVSup, a tool commonly used to track the OpenBSD source tree. To install CVSup on a moderately fast system with a good Internet connection may take only about ten seconds -- the time required to download and unpack a single 511kB package file. In contrast, building CVSup on the same machine from source is a huge task, requiring many tools and bootstrapping a compiler, takes almost half an hour on the same machine. Other applications, such as Mozilla or KDE may take hours and huge amounts of disk space and RAM/swap to build. Why go through this much time and effort, when the programs are already compiled and sitting on your CD-ROM or FTP mirror, waiting to be used?
Of course, there are a few good reasons to use ports over packages in some cases:
- Distribution rules prohibit OpenBSD from distributing a package.
- You wish to modify or debug the application or study its source code.
- You need a FLAVOR of a port that is not built by the OpenBSD ports
team.
- You wish to alter the directory layout (i.e., modifying PREFIX or
SYSCONFDIR)
However, for most people and most applications, using packages is a far easier, and is the recommended way of adding applications to OpenBSD.I have SRPMS setup with customization options (--with this feature, --without that feature). And as I have a VMware system with an identicle software setup as the server except with compilers, and I build the packages there the way I want them and test them as well, then have the real servers pull them via my APT repository once I they are tested enough.
The usual response..."that depends"...
IF packages are available, then that is what I use. The logic is, that a package install is repeatable. If you compile, there are subtle differences in the machines that will evolve as you add pieces that may give you trouble if you need to recover from a catastrophic failure.
This is particularly important in business application areas...building a reliable, repeatable process is key to success.
If you can't get a package, or have to highly customize, then compiling is certainly an option. The caviat here, is the three worst fears of a system administrator: DOCUMENT! DOCUMENT! DOCUMENT!
Either way, be very careful to maintain libraries of your installed versions. Again, as you might expect, subtle differences can and will bite you...or worse yet, a required dependency may become hard to find if not impossible.
Hope that helps...
Ah, to have the energy of a student once again. Eventually you get tired---I got tired of it at some point and decided that having stuff work today was more important than having stuff work optimally, to my unique exacting specifications, or whatever.
You make the same calculation with money, believe me, and nobody's cheaper than I am. At some point you get frustrated enough that stuff doesn't work and you snap, nevermore to roll your own when you can just buy your way out.
This is why eventually we'll all give in to time, fatigue, the realization that life is passing by... and we'll all switch to OSX.
I tend to do the first install using whatever the distribution uses. Cureently I'm using slackware 9.0.
After the install, I update things as needed using source. By doing this, I can set the compile options I want and have the executables set for my cpu and what I want.
I've also found that in most cases, my compiled executeables are smaller and tend to run a bit faster. For me, since I'm only using a 4 gig drive for linux, saving space where I can helps.
is compiling better? sometimes. are packages better? sometimes. anybody who's 'diehard' anything is usually closeminded.
diehard linux? there's things that windows does better, hate to break it to ya.
diehard windows? well, anyway...
diehard C,C++,Assembler,Perl,PHP,Python.... who gives a crap?
ok fine, 'C' is objectively the best, but that's another story ;)
ask yourself this: am I doing ______ in order to get the job done better? or am I doing _____ for my self?
selfish motivations include:
1) doing it the hard way so you understand every detail. a commendable method no doubt, but do you need to know every detail of Apache to use it? Not if apache is any good, which it is. If understanding apache is not your job description, which it's not you are WASTING TIME AND MONEY.
2) going to extensive efforts to improve efficiency. again 99% chance you will never recoup the hours you spend benchmarking and compiling in CPU cycles. once again you're probably wasting time and money.
3) using 1 method because you HATE XXXX corp. possibly dumb if XXX corp happens to have a product that does what you need better.
4) using 1 method becuase you got burned doing it a different way before. understandable, but things change & maybe you're work around is no longer necessary & again a waste of time. argh, i don't know, i guess i'm done. ok i'm done :)
The only time I don't use a package is when there isn't one available, for example, if you want to run Exim on RedHat.
Typically, I prefer to use Debian. If you use the packages, apt-get update && apt-get upgrade will upgrade them all when bugs are found (particularly important with security on an Internet server). If you're doing everything from source, it's quite a bit of hassle manually compiling new versions of things that have vulnerabilities.
Generally, go with the packages (or at least a BSD-style ports system).
Oolite: Elite-like game. For Mac, Linux and Windows
source for the code that has a lot of security
issues - you need the latest. Code like
BIND or sendmail or DHCP Server, etc.
http://www.greenfly.org/mes.html
Seriously, Gentoo is not suitable for servers at all, especially not for production machines. Apart from the CPU cycles spend compiling, Gentoo doesn't have the quality control that some other distros have.
Now, I don't hate Gentoo, but it's not ment for servers.
Actually, you are right for basic "compiling from sources". But I use nALFS, and while I spent a lot of time creating more than a thousand XML install description files (one for each package I use), I now have all the benefits of packages you noted, and all the benefits of compiling from source.
I have all of these, and I have a complete control of my box. When a security update is out, I need only the time to modify the software version in one XML file, then I launch nALFS, and I update.
Updating Gnome or KDE is a breeze, well, after I updated all version numbers of packages. Security updates are a breeze too.
The point is not just a petty performance tweak, the point is to have a powerful and durable system. It worked beautifully.
My install system can even recreate a boot CD (in 5 hours, zero human intervention) or/and a boot DVD. It's really powerful, really.
And as I am in control, I have none of the problems of distributions, like no more support for old versions (I am always up to date if I really want to, I can lag behind if I want to, that is a change of version in a XML file away), or everything that changes between versions.
My trusty amd800 runs only software it compiled. ;-)
Sure, everyone said it, and were right:
source code takes longer to install, doesn't always work and is generally a pain in the neck.
But still - it's fun
I love burekas in the morning
I'd rather use source all the time, but when you are using a really slow machine that could take forever... thats where packages make things a bit easier...
.02
However, the problem I've run into very recently, with mandrake 10, are that even though certain programs like apache, and php, can support a lot of things (i.e. can be compiled to support things), the binaries distributed with mdk 10 dont include all of things I needed...
Specifically, when installing Mambo on a webserver here I found that zlib support and xml support were both missing, even though apache and php were both installed. The only solution I could find is to install zlib (from source), and then recompile php and apache. I still havent quite figured out why xml support is missing, but I digress;)
Using packages and source together can also be extra work because a lot of the stuff you need to compile programs are in "devel" packages that arent installed by default (That doesn't happen at all with LFS.)
It's a tough call but the way I see it, try packages and if you don't run into problems, then fine... otherwise just don't forget that open souce is... well open source? =)
Sorry if all this was said already but I had to give my
Chaos is Divine *
...the programmers in days of yore who didn't mind submitting their programs as punched cards and coming back a week later to find that the room-sized computer* had failed on the 2nd card.
*So expensive that only the 5 richest kings of Europe could afford them.
Thanks for pointing me at Lunar. I might give it a spin someday, but for now I am very very happy with Debian. Honestly, I think Debian is so hard to beat that we shouldn't even try, and instead focus on improving it.
The other thing is that my mind is slowly moving away from Linux. It is much too monolithic for my taste, and there are some other issues as well. I would like to experiment with event-driven I/O, database-like filesystems, unification of shell and programming (imagine having the full capabilities of the system available via the shell, full-fledged access control on functions instead of e.g. needing to be root to bind port 80), and more such things.
I'll still use Linux for times to come, because it works better for me than any other OS, but I'll be looking out for and/or working on more revolutionary things.
Please correct me if I got my facts wrong.
Why must it always be a binary, black-or-white choice? Gnome or KDE, source or package distribution, AMD or Intel ... it's as bad as religion sometimes!
A smart person learns the advanatages and disadvantages of different tools; it really doesn't take that much effort, especially for anyone who calls themselves a "professional."
I just bought a dual Opteron workstation, and it had Gentoo-amd64 installed, built from source. Why? I wanted a pure 64-bit environment, and I wanted the machine tightly tuned.
Would I recommend this to a non-expert? No.
What does my wife's laptop run? Windows 2000, because she needs to be compatible with co-workers.
What do I use on my Pentium 4 workstation? Debian 'sid', installed from packages.
My dual P3 server? Debian stable, from packages.
Only proselytizers, trolls, and pundits think that one size fits all.
All about me
As there are over 500 comments I'm assuming I'm being "-1 Redundant" but I'm also assuming moderators probably won't get this far ... come to think of it neither will readers! Oh well. Anywho I've always been a build-from-source kind of guy but that's due (at least in part) to my FreeBSD background. In FreeBSD I had the best of both worlds, the port list which made it very easy to install a software package, and the fact that the port list downloaded source and installed! Nowadays I use Suse and as such I can use RPM's, however I usually find myself building from source whenever possible. One of those, "just because I can doesn't mean I should" type of things. I think that until there is a universally accepted and implemented package type that simply works in all linuxes I'll stick to source, not packaged.
Kleedrac
Sure we wang, can.
We use a mix of both. We run Gentoo on most of our SMP production servers (and unlike a previous post have never had any 'quality control' issues). Compile time on a good machine is minimal. A complete kernel build and building all programs necessary for a virtualhost mailserver takes under an hour for a Dual 2.4 Ghz Xeon with 2 GB RAM.
However for machines which need minimal clue level (i.e. for customer maintined machines we install into a customer network) we usually use Debian or RedHat unless there is a performance issue. The performance boost we see when comparing optimized source builds vs. generic architecture package builds (.deb,.rpm) is substantial.
We generally sit down internally and make a decision on which is going to provide the best performance:maintainence ratio.
I know there is temptation to make things a little bit better, but support after you're gone is the issue.
The genius who designs a system that only (s)he can maintain is a poor engineer.
Find out what your customer's (the prof sounds like the customer in this context) requirements truly are. Is good enough good enough for the prof? If you give him what he wants and he finds out next week that it could have all been optimized to perform
Meet those requirements with the minimum customization.
Document the system. This may be a nightmare if the system has already been "tweaked" by the previous maintainers. If that's the case, it's even MORE important to simplify and document.
Provide recovery tools--as simple as a set of drive backup images, or as complex as a set of scripts that rebuild the system from source. At a minimum, supply a system administrator's manual.
Building a system for a customer to use is a completely different endeavor from elaborately tweaking your own box so it is just exactly the way you like it.
"Reality is that which, when you stop believing in it, it doesn't go away." - Philip K. Dick
I've got several RH8 production servers. I compile the major applications we use from source: mysql, apache, php, perl, and qmail. I have always had minor problems getting things to compile right on RedHat. Recently, they have taken to compiling everything including the kitchen sink into every package. I had to uninstall half my system in order to remove RedHat's perl. I was up all night compiling ImageMagic. Shudder. I still don't have freetype and Ghostscript support working right. Qmail and supporting programs need dozens of patches, especially now that RedHat uses Glibc 2.3.2.
- None can love freedom heartily, but good men; the rest love not freedom, but license. -- John Milton
Install from source, automatically with nice package tree management and dependency tracking. If you feel the need to custom compile a package or two in such a way that precludes using their automated build system, you can do it manually and then "inject" the package into your installed base, so that dependencies work for the manually added package.
11*43+456^2
If you should need to recompile your Red Hat kernel do not try to install the raw kernel source from kernel.org. Red Hat and other distributions require that they use their versions of kernels specifically taylored to their distribution. For Red Hat, install the kernel-.src.rpm (note that this is different from the kernel-source package) and look at the file /usr/src/redhat/SPECS/kernel-2.4.spec. At the top of this file you will see something like the following:
Summary: The Linux kernel (the core of the Linux operating system)
# What parts do we want to build? We must build at least one kernel.
# These are the kernels that are built IF the architecture allows and
# no contrary --with/--without arguments are given on the command line.
%define buildup 1
%define buildsmp 0
%define buildBOOT 0
%define buildenterprise 0
%define builddebug 0
%define buildjensen 0
%define buildtape 0
%define buildBOOTtape 0
Change all of the 1's to 0's leaving a 1 for only the kernel version you wish to build. The above listing shows the modified spec file for building the uni-processor kernel. Now build with an appropriate target option like:
# rpm -bb --target i686 SPECS/kernel-2.4.spec
If you do not do this, RPM will attempt to build multiple kernel versions. Usually it is only necessary to build one kernel specifically targeted for your machine. Building all of the kernels defined in the default kernel.spec will take many hours even on a fast machine. When the build is complete there should be an RPM in the RPMS/i686 directory (or the directory for the specified target) that can be installed with:
# rpm -Uvh RPMS/i686/kernel-2.4.20-28.7.i686.rpm
Now can someone explain how to run make xconfig beforehand?
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.
I definitely prefer prebuilt packages. I run Arch and Slack on two machines and will only use source installs as a last ditch (because the author only provides source). I don't mind the idea of compiling, but only if it's quick. I refuse to spend 2 days building my system when I can download it in 5 hours with packages.
When I have a machine quick enough to build a system (linux, KDE, Gnome, Mozilla, several other packages) in two hours then I will build from source. So maybe 5 years?
I don't think either matter, the gains from optimization are nothing if the person who built the package knew what they were doing, maybe a small gain by using some new instructions on your CPU.
``Except, if those files (or their sources) required patching in order to make a dependent program work, then having a random version of those files won't make that program work''
.so files. If your program needs libfoo.so.2.1, than it should list that as a dependency, rather than just libfoo.so, which might actually be a link to libfoo.so.1.0 (without some bugfix or feature).
This is why we have version numbers on
Binaries usually don't have those version suffixes, but there's no reason they couldn't or shouldn't have. Debian, for example, provides gcc-3.3 and php4, so programs that need some specific version of a binary can get it.
If you need to distribute software with some specific feature, try first to get it included in the main version of that software. If that won't work, you'll have to distribute a custom version _and name it distinctively_ so that your feature can be detected, and the standard version of the software can coexist with your custom version.
Please correct me if I got my facts wrong.
Sure, like any distro, an install will blow here and there due to dependencies, but, for the most part, I find it rarely happens with Gentoo....and makes the whole process so easy to do.
You have clearly never worked with mod_php. It likes to install a fresh copy over the old one, install both mod_php and CLI php whether you wanted CLI or not, and then warn you... "Due to previous bloopers with PHP and slotting, you may have multiple instances installed..." They're not too previous if the same thing still happens constantly!
Granted it's a worst case, but it is pretty awful (and repeatable, and persistent). Maybe nobody's fixed it because they all commit suicide after looking at the tangle of PHP ebuilds?
__CmdrTHAC0__
In Soviet Russia, Spanish Inquisition doesn't expect YOU!!
I am currently migrating to FreeBSD from Debian. The main reason is the easy of installing and maintaining software. With FreeBSD Ports system, installing is easy.
I get the latest stable software. I don't have to worry about crazy dependancies (I don't want MySQL dammit, I use Postgres). The software is in a standard place. It's easy to tweak things.
I also find that FreeBSD is much faster than my Linux system... Especially RedHat.
The above is not worth reading.
So I'm happy that the most interesting stuff is available as source. (That is the stuff that I'm interested in. YMMV.) When you don't expect to work out anything from the source(not even pngs and config files) you are better off with rpms.
I'm still trying to figure out what people mean by 'social skills' here.
TELL TRINITY I SAID HI.
I compiled Linux from scratch, I don't mean gentoo or any distribution, I literally mean creating a
chrooted build environment, compiling a compiler, glibc etc.. then using the build environment to build a working linux system, all from scratch.
http://www.linuxfromscratch.org/
The procedure took about a month, and was a lot of work.
Right away I knew I'd need a log of how I compiled everything, (so I knew what I did to get xyz working) I wrote a tool to do the job. It lives on sourceforge (http://buildog.sourceforge.net)
Keeping a log of the commands, notes, etc.. has been invaluable when it's time to recompile with different options. Storing this "documentation" as a shell script allows me to alter the options and recompile.
Keeping a build tool as minimal as possible (no spec files, dependancies or rigid syntax) means that I'm more likely to actually use it. The fact that the documentation is also the shell script means that things actually do get documented, at least in a minimal sort of way. (the script is designed to operate within a controller type of environment, to keep most of the ugly shell details out of the actual build script)
I would say that for a LAMP system, source is the way to go. Particularly because you'll know exactly what and why things are installed. But it's important to keep notes so you can refer to them later, the notes have to be centralized because you'll need to actually find them, keeping a bunch of text files scattered here and there won't work. (been there, done that..)
I would say that a source based setup is actually easier to maintain because it tends to be minimal.
With a package system you've got dozens of conf files, package data, etc.. and can never really be sure what a given package did, or if something will go behind your back and modify a conf file that you've already edited.
For other systems, such as a desktop machine I wouldn't even attempt it. It's simply too much work.
If you've got a server farm or need to do several machines, source-based installation may not be such a great idea (unless you have some way of distributing the binaries on all the servers)
I suppose in the case of a professor or other authority that demands a package based system, packages are the way to go just to keep him or her happy.
With open source software you have so much fscking possibilitys to build your software so every binary package lose when you want to use it under a "special" environment when you have to inlcude some exotic things or something like that.
With the FreeBSD ports for example you have the possibility to change the Makefile for compiling options. So you have you OWN package which going to be included as a package into your system and it is simple to use.
When a "port" needs another "port" to be builded, freebsd automaticaly download the source, compile it and install it unlike an RPM where only the dependencies are printed when you don't use YaST or some other dummy-administrator software.
:ast time I looked, RH9 was still there for download, as is RH Enterprise. For FREE. What are you talking about paying for?
"Who are in control, they are not in control of anything - they don't even control themselves!" - Glen Beck
Build packages from source, install packages.
Building and installing directly from sources is okay for temporary use but, in practice, it will eventually leads to a cluttered, unmanageable system since there's no formal file management/control system.
I started using gentoo a few months ago and I love it! Yah, it's sometimes a pain waiting for something to finish compiling but it is definetly worth it. Upgrading is so easy, just a simple "emerge sync && emerge world" Gentoo is linux at its best.
Well a bit late to post here perhaps but one thing I've found important when building from source is to keep your packages separate. That is run ./configure --prefix=/sw/\${PACKAGE_NAME}/\${PACKAGE_VERSION} (note you'll probably have to fill it out manually). Then you use a script to set up your PATH, LIBRARY_PATH and CPATH etc...
It saves a lot of headache, and gcc will still find all includes and libraries.
Debian is your friend in this situation.
The Policy Manual is very specific about how and where your packages behave and install, respectively.
S
The Gentoo installation method IS finished! It is exactly the way it is supposed to be.
To introduce some push-a-button-and-go installer would cause Gentoo to cease to be Gentoo. Gentoo is [for/by] people who WANT to be the one to do all those things to construct the system and install manually. It's for people who want total, explicit, unfettered top-to-bottom control of every cotton-picking thing in their box. I think if you really want to learn Linux, install Gentoo (or Slackware). If you want an easier/faster install process, there's always Mandrake or Fedora.
Dif'rent strokes for dif'rent folks.
My server is a LinuxFromScratch 4.0 system and as with all 'FromScratch' systems it is completely source based.
/opt/[packagename-version] Now all files that this application installs is under this directory branch. Update /etc/ld.so.conf to indicate the new lib folder /opt/[packagename]/lib and run ldconfig. I then use symbolic links to setup init scripts and to link the man pages to the man directories. Want to move to a new version? Install new version to another /opt/ directory.
How do you deal with the clutter of libraries, includes, man pages, logfiles, config files, etc that each new application needs to install?
Good question: When compiling running the Configure script ( or by Editing the Makefile if there is no Configure script ) I select a --prefix=
Side benefit! You can have multiple copies of the same applications installed and running independantly of each other! I have samba 2.8.1 and 3.x as well as Apache 1.3.x and 2.x running at the same time! You can test the new version without interferring with the older version. ( With network applications as those listed you will need to create virtual adapters ie. eth0:1 and explicitely bind them to that application in their config. Samab is interfaces=eth0:1 or interfaces=10.10.10.1 )
But use a package when source-envy is not a problem.
From emerge(5): /.
ENVIRONMENT OPTIONS
ROOT = [path]
Use ROOT to specify the target root filesystem to be used for
merging packages or ebuilds. Defaults to
This may have been added recently, since I've never looked for it before, but it's definitely there in portage 2.0.50.
__CmdrTHAC0__
In Soviet Russia, Spanish Inquisition doesn't expect YOU!!
If you have the time to compile from source, and have slackware, debian, or use RPMs, you can use checkinstall (found here: http://asic-linux.com.mx/~izto/checkinstall/ ) to make packages from source. Works great under slackware in tandem with pkgtool, as it gives you the optimizations that you need along with the benefits of packages.
You can lead a horse to water, but you can't make it dissolve.
If you want to install Gentoo by the easy way go get the anaconda-gentoo-installer based on anaconda from RedHat here is the link: http://gentoo.vidalinux.com/?q=node/view/35
If you are look for the benefits of a package and you use Slackware, try checkinstall.
Just configure the sources, make them and before installing use this programa, it will make a good slackware packages, and you will get the benefit of remove or update packages in a clean way!
Then you get to build from source, but can manage packages on those 10 linux servers much more easily.
See my article at http://obfuscated.net/archives/000080.php
Darthtuttle
Thought Architect
... why not build a package?
Not to hard.
If rpm, just grab the source rpm from the same program and modify it to your needs, if there is none, start your own.
slackware packages are very simple.
Though I am clueless about debs and gentoo's packages, but you could get example packages and follow them to build your own custom made one.
errera hunamum ets
If you want to install gentoo by the easy way go to the following link: http://gentoo.vidalinux.com/?q=node/view/35
Prof. Joe Weizenbaum used to tell this joke to his intro programming students.
Question: There's a cabin in the woods, a table in the middle of the cabin, a bucket of water on a table, a fire burning in the fireplace, and it's raining outside. How do you boil the water?
Answer: Take the bucket off the table and put it in the fireplace.
Question: There's a cabin in the woods, a table in the middle of the cabin, a bucket of water on the floor, a fire burning in the fireplace, and it's raining outside. How do you boil the water?
Answer: Put the bucket of water on the table, thus reducing it to a problem already solved.
"Optimization" should not be misplaced, because then it is no longer optimal.
If your time is not worth anything, convenience does not add value.
If you require internal certification of the security of a package, then source is your only option.
-I like my women like I like my tea: green-
MOD PARENT AS FLAMEBAIT...yes I DO mean the original article.
your forgetting though... my system != your system
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.
This thread wasn't chosen by editors to create a Debian/Gentoo flamewar. Nope. Not at all.
When I went to the GNU ftp sites, to my horror, the TAR program was TAR'd. After much gnashing of teeth, I get the thing uncompressed, and follow the 20 steps to install. Of course, I have to tweak some of the scripts because of some libc incompatibilities. And so it goes.
I can't imagine how wonderful it would be to admin a slew of boxes on which every update had to go through this process. That's 5 hours, 12 minutes...just for KDE...just for one machine. No thanks. If it was my own machine...maybe. If it was for work where downtime means down profits...no way. That's a lot of wasted time when you can throw a few bucks at the problem (or in some cases just keep your money) and have pre-compiled, ready-to-install packages that will install in a handful of minutes.
I like RPM and up2date in RedHat ES 3.0. However, some things I still install from source, like Apache and PHP. Others, like MySQL, I do from packages.
I prefer to maintain the system via packages because they are easier to add/remove/upgrade and maintain but I like the optimization and control you get over the finished product when you build it from source. All of the packaging systems are fairly well documented so I choose to build my software from source and build packages myself. This way I can maintain a large number of machines and keep them identical quite easily.
- Autotools -- autoconf, automake
- pkgsrc
- cfengine
'nuf said.Assuming you are a postgrad student and not actually being paid to administer the system, you really should be spending your time doing your study/research instead of tweaking the last 10% out of your applications. It really isn't worth the bother. And it is hardly an achievement to add to your cv ("I know how to type ./configure;make;make install"). As someone who had to do this for a Solaris network in the days before packages, I can tell you what I would be doing given a second chance...
1 Server, 1 Admin - Build from source
5 Servers, 1 Admin - Build Packages and install
1 Server, 5 Admins - Use Standard Packages
5 Servers, 5 Admins - Build Packages with custom names/versions and install
Seriously, I have 7 Admins managing a mix of 160 Servers.
The simplest way I've found to have the best of both worlds, is to D/L the source RPM (SRPM), customize to taste, modify name slightly, rebuild, and distribute.
For instance,
Needed customized apache to support a couple of things we're doing.
D/L apache SRPM
Modify config files with our own patch
modify configure line in SPEC file to suit
modify package name (!Important!)
rebuild
uninstall old packages
install our packages
WA-LA
Advantages
- still get to run up2date/autorpm/fav-update-package with no worries of breaking your own custom stuff
- Know which packages you've mod-ed by running rpm -q -a | grep "myinitials" or whatever.
Disadvantage
- Auto Update doesn't fix the stuff you're behind on...gotta keep up!
The really great thing is how well it wears.
I've been using Gentoo as my only OS on my only computer for about a year now. I was crazy about portage at first, but at least two different times the build process has gone horribly wrong and hosed my system.
The most recent was about two weeks ago when during a seemingly innocuous emerge, GCC was apparently unmerged or otherwise incapacitated. somehow it deleted certain symbolic links to glibc, which meant I couldn't even start any programs linked against it... which is basically every program ever. I managed to fix the links but the compiler itself is still MIA.
If it were a binary distro, I could just download a new GCC package and be done with it. But no, it's source-based, so to reinstall it I have to compile it... with what? I could get a GRP package, but there isn't one for GCC because it's included in the stage tarball.
I got tired of messing with it, so I now have a Gentoo system with no compiler, which means I can never upgrade until I get it fixed. Portage is great, but in my experience I think it might still have a few kinks left to work out.
Slashdotters love to make fun of IIS, when meanwhile, from GLSA:
.uue, .uu, .b64, .bhx, .hqx, and .xxe extensions) may cause UUDeview to crash or execute arbitrary code.
Multiple security vulnerabilities in Apache 2
A memory leak in mod_ssl allows a remote denial of service attack against an SSL-enabled server via plain HTTP requests. Another flaw was found when arbitrary client-supplied strings can be written to the error log, allowing the exploit of certain terminal emulators. A third flaw exists with the mod_disk_cache module.
For more information, please see the GLSA Announcement
UUDeview MIME Buffer Overflow
A specially-crafted MIME file (.mim,
For more information, please see the GLSA Announcement
Multiple remote buffer overflow vulnerabilities in Courier
Remote buffer overflow vulnerabilites have been found in Courier-IMAP and Courier MTA. These exploits may allow the execution of abritrary code, allowing unauthorized access to a vulnerable system.
For more information, please see the GLSA Announcement
Multiple remote overflows and vulnerabilities in Ethereal
Mulitple overflows and vulnerabilities exist in Ethereal which may allow an attacker to crash the program or run arbitrary code.
For more information, please see the GLSA Announcement
oftpd DoS vulnerability
A remotely-exploitable overflow exists in oftpd, allowing an attacker to crash the oftpd daemon.
For more information, please see the GLSA Announcement
Buffer overflow in Midnight Commander
A remotely-exploitable buffer overflow in Midnight Commander allows arbitrary code to be run on a user's computer
For more information, please see the GLSA Announcement
Slashdotters pretend OSS is flawless and "M$" is all evil, when meanwhile according to GLSA, even a MIME header can execute arbritrary code on Apache! Look at all these buffer overflows just announced:
.uue, .uu, .b64, .bhx, .hqx, and .xxe extensions) may cause UUDeview to crash or execute arbitrary code.
Multiple security vulnerabilities in Apache 2
A memory leak in mod_ssl allows a remote denial of service attack against an SSL-enabled server via plain HTTP requests. Another flaw was found when arbitrary client-supplied strings can be written to the error log, allowing the exploit of certain terminal emulators. A third flaw exists with the mod_disk_cache module.
For more information, please see the GLSA Announcement
UUDeview MIME Buffer Overflow
A specially-crafted MIME file (.mim,
For more information, please see the GLSA Announcement
Multiple remote buffer overflow vulnerabilities in Courier
Remote buffer overflow vulnerabilites have been found in Courier-IMAP and Courier MTA. These exploits may allow the execution of abritrary code, allowing unauthorized access to a vulnerable system.
For more information, please see the GLSA Announcement
Multiple remote overflows and vulnerabilities in Ethereal
Mulitple overflows and vulnerabilities exist in Ethereal which may allow an attacker to crash the program or run arbitrary code.
For more information, please see the GLSA Announcement
oftpd DoS vulnerability
A remotely-exploitable overflow exists in oftpd, allowing an attacker to crash the oftpd daemon.
For more information, please see the GLSA Announcement
Buffer overflow in Midnight Commander
A remotely-exploitable buffer overflow in Midnight Commander allows arbitrary code to be run on a user's computer
For more information, please see the GLSA Announcement
Exactly why developers shouldn't be systems admins. all too often source tar balls put things in the most f-ed up places. Atleast when I install a pre packaged debian supplyed .deb that it will fit to the system layout. conf files, documentation, binaries, and libs will all be in the expected places and not where the programmer thought about putting them. Some programmers would rather just run everything out of your home directory.
Paying taxes to buy civilization is like paying a hooker to buy love.
MOC.
If you're concerned about time... USE THE BLOODY BINARIES!!!
Nobody ever said you *have* to compile every package. Ever heard of GRP?
Karma: It's all a bunch of tree-huggin' hippy crap!
Remember, the whole point of packages is to: A) save time in the future B) reduce nuances for future administrators C) keep similarity with other machines Packages help on all of those fronts. At some point, when you're no longer an undergrad, time will be your biggest limiter. When a system is package based, it may be a few days (or if you're sticking to stable packages, longer) behind the times, but the chances of you mucking up the system are much lower. Also, if somebody else takes over the system and it's all package based, there aren't any gotchas. In a corporate setting, packages should ALWAYS be used unless absolutely necessary not to (which it never is because you can make your own binary or source packages). Academics, it doesn't matter so much, but it's like any skill. Start with proper and then allow yourself the privilege of breaking the rules.
Initially, doing this work may seem like fun and not take too much time but please consider your options carefully. Think about it and choose the way of least resistance and requiring the smallest amount of work... not good systems maintenance practice but definitely good for your studies. Try to also involve as many other student as possible, otherwise you will end up running the system on your own.
If you are a PhD student and are thinking of doing a lot on maintaining your lab's system, DON'T. You will regret it once you find yourself in a position of wasting time to maintain computers and other irrelevant work and no time for research after your quals.
If you're good (or even crap to mediocre like me) at using computers, people will take advantage. Your work as a technician will expand to random coding and scripting as well because people will no longer bother to learn and your professor will likely just make you do it because it takes the least time.
That's all for this rant :)
But of course, in the corporate environment I'd want everyone running known versions of everything so I knew what behavior to expect. Meanwhile if you need something, let me know and I'll build you an executable, test it, and then send you a binary package.
Of course I work in a windows shop now so this is all irrelevant there.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
For me, pre-compiled packages have two big advantages:
- They fit well in the overall architecture of the system. All config files are where the distribution expects them to be, and the stuff works well with the rest of the system.
- The system is easy to upgrade, when ever there is serious need to do so. If a security vulnerability is found, it gets patched, and automagic updates make sure my system is not so vulnerable.
On the other hand, manually compiling stuff has the advantage (and problem) of getting the latest features. Occasionally we need them. The drawback is that when (not if) the thing needs upgrading, it will have to be a manual one. That is fine for a system or three, but a pain if you have a dozen of them. If you have hundreds, you probably have (and need) your own repackaging system...
So it all boils down to how many machines you need to manage, and on what level.
p.s. I run Debian/Stable for the servers where I can get away with it, but Gentoo for my home workstation.
How do you uninstall stuff installed from source, when the original build files aren't available?
Isn't that the #1 reason to use packages instead?
Sivaram Velauthapillai
Sivaram Velauthapillai
Seeking the meaning of life... @slashdot of all places
I personally like to build the software I use on my Linux boxes. However, nowadays I tend to compile it only once, create my own packages to use on a later installation or to spread the software on other workstations/servers which have the same hardware configuration as mine. That speeds my workflow and I still have the confidence on the software I compiled. Anyway, I think it is all a matter of "taste".
For those lucky enough to have a pre-built package repository then the tool may not be as useful. But for those of us that don't have the option of downloading a pre-built binary, this is a great tool. Some might say, that there is a binary for just about everything. Well, here is one: Provide me a binary for fetchmail 6.2.x for Solaris 2.8.
(Standard Disclaimer: This is NOT a flame/flame-bait or troll; I PROMISE!!!)
The first distro I tried in my early days of using Linux, was Slackware, (Slackware 3.1 to be exact), I played around with it a bunch, and I was very impressed with it. After about a weeks use, I started playing with Debian (1.2.1 I believe, can't exactly remember, same time as Slackware 3.1) and I found the install to be difficult, and I didn't like the style of scripts that I had already become accustom to in Slackware (yes, I became accustomed to scripts after just over a week of use), and I trashed the Debian install. I then installed Red Hat (Red Hat 4.2 I believe was the version) and I ran into the same sort of things that I didn't like about Debian. So I once again trashed my distro, and installed Slackware again; ever since, I've been a pretty diehard Slackware junky.
That being said, I have gotten into several discussions with people about Slackware (and its supposed lack of a package management system); many people out there believe that Slackware doesn't even have a package management system, but it does pkgtool is a very capable package management tool. While it doesn't dive too deep into your system, looking into and tracking dependencies and what not; it does get the job done if you should have any problems with souce. All-in-all, I am a compile from source kind of guy, I like to build every single one of my packages from hand, track all the dependencies by hand, and install/compile in different modules or options into each one of the programs I compile. No, I am not managing 400 linux systems, but I am managing 4, and I have no problems on time constraints, and maybe, maybe, if I one day have/get to manage 400 linux systems, I will look more in depth to a distro with a more powerful package management utility.
YOU'RE WINNER !
Another lame blog
I saw this line and immediately su'ed and tried to run "genlop". Nope, not there.
emerge -p genlop
Waiting... Yup, there is such a package!
So I emerged it. Actually, it's building right now while my KDE build is going on in the bg. (Still going after 9 hours) Okay, genlop is finished building, only took like a minute or two.
I know that kdelibs is done so I'm curious how long it took...
Maybe that old box I've got taking up space in the basement would be a good distcc box after all...
but make your own packages. This way, you get the ease of install / uninstall / upgrade / query that the package manager gives you, but you get the full optimisation and feature control that you get with installing from source.
... but you do because it was installed via source last week. It's horrible, and I've been trying to fix it for the past couple months (RPM spec files suck).
Or, switch to an OS that uses the same methods for building packages as installing from source (like the ports trees in OpenBSD and FreeBSD, or the pkgsrc system from NetBSD).
Either use the package manager for everything, or only install from source. If you try to do both, you will run into all kinds of problems. We have 30+ RedHat servers running with a mix of RPMs and source installs, and it's a royal mess to install anything. Try to use the RPM and it complains that you don't have libX version Y
"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."
That's right. The most important keyword here is the maintenancability itself. I can assure you sonny that as soon as you will get out of your cave and do some real work in the real world, your naive "fanatism" will instantly vanish in the day (or rather in the month) when you will have to clone a five years old multipurpose server and move it to a new remote colocation farm with barebones systems installed. You will want to kill that stupid joker who installed everything there from sources. You will literally want to kill him. Do you really think your professor is stupid? Kids...
Sincerely,
Pan Tarhei Hosé, PhD.
"Homo sum et cogito ergo odi profanum vulgus et libido."
Packages in a distribution like Debian update and uninstall cleanly, you can build every one from source if you want to, and someone else has worried about (1) testing the binary and (2) getting all the dependencies right.
Build from source if you need the software and no package exists, or if you really, really need a processor-specific version. But for most applications, go with the pre-packaged version: as a system manager, there are a lot more useful things you can do than recompile "ls" on a dozen machines.
my favorite example is that you have to link the correct timezone files by hand, instead of choosing your timezone out of a list.
I'll bet you my next month's salary i can type
ln -sf
on my Gentoo box before you can use whatever gui list tool you use with your mouse.
Besides that what do you think `ls
I can only guess that you either
a) don't know your own timezone or
b) think making a simple link is hard work.
Please, go back to Mandrake or whatever you use. Leave Gentoo to those of us who actually want to be more than an ordinary Linux user.
All you anti-Gentoo people really piss me off with all your whining. If you don't like Gentoo then don't use it..
Oh yeah and Gentoo is not a little distro at all, it has over 6500 packages available for emerge.
Y'know, I've recently started liking Debian for apt-get. Sometimes when I'm feeling lazy, it's nice to just be able to *have* something.
... /usr/local/bin, or /bin? /usr/local/etc, or /etc? ...Etc. :-)
On the other hand, there are definitely times you need to compile from source, especially when you need to hack something. And you never know quite where those files are going to *go*
Assume I was drunk when I posted this.
I recently "built world" on a FreeBSD system, and I was somehow under the impression that, for instance, if I was on dial-up, it would have been easier to download the source, and that the binary code that resulted from my building the FreeBSD base files that I downloaded was larger. I actually have broadband, so it doesn't matter for me so much, but I was just thinking that if I were somewhere else and only had access to dial-up, downloading source would be easier.
.deb files and the corresponding source points out that the binaries are about half the size of the source. This might be significant for those with dial-up.
Now, as I was surfing a couple sites (Open Office, Mozilla, etc..) just now to test my theory, I realize that I am wrong in this. The source, for instance, of Open Office is 180 megs, whereas the binary is like 60. And that's probably because there is support for many different platforms in that source. The binaries I was just looking into seem to be smaller, because you have already chosen your platform, your CPU, etc., but the source has everything you need for any situation.
So, for those with dial-up, binaries _may_ be an easier way to go. I thought it was the other way around, that source code was smaller, but maybe I have been wrong thinking that. My very un-broad, un-scientific comparison of several
Just one example -
A debian kernel-image 2.4.19 for a sun4u smp (.deb file) is 3846K
A debian kernel-source (.deb file) for the same version 2.4.19 source is 25285K
This may be an extreme example, but generally speaking, since the binary is already specialized for your hardware, it's going to be smaller. Am I missing something or is this correct? I thought it was the other way around, but now after looking into it, it appears that binaries are more bandwidth-friendly.
http://gentoo.org
Satisfy both your needs.
---------
Launch all sig
I mostly use source distributions for a very different reason-- most automake packages are a bit more tolerant of dependency issues than RPM, etc. Furthermore, once you install the source of one program, the rpm db is out of sync and you have to try with --no-deps and hope for the best.
Gaim is easier to install as an RPM if you want MSN connectivity, however, so I do use RPM for that.
LedgerSMB: Open source Accounting/ERP
When I build a machine for Linux, I will typically download and install the latest stable build of the Linux distribution which is going to land on the machine. From there, what I do varies. Anything that could affect security or efficient operation of the machine (starting with the OS here -- I always prefer to build my own kernel locally, you never *really* know what is included in a pre-built kernel) I build from source packages. Anything trivial included in default packages from Linux distribution (for example, games) I download as a package -- but with that comment, keep in mind that no package is ever *truly* trivial: if you are building a server that must be secure, you need to know what is in the package you are loading.
But I believe (and from a cursory view at the headlines to the responses here, I think most probably agree), that you have to draw the line somewhere. If you are running a top-secret government laboratory, you ought to compile from source, and not even start from a Linux distribution. If you are setting up a machine for your kids to play games and won't connect it to the internet, would it be worth it to compile from source?
Somewhere in between, there is a line you must draw.
The two cases I presented above are the two absolute extremes. Discounting the trivial game box, I think one should always compile their own kernel for that specific machine (and possibly for the kids' game box, possibly not); if you are building a server, or a machine which needs to have high performance or will see extreme usage, then there are obviously certain things which need to be compiled from source.
But do you need to build (trying to think of a fairly trivial example) more/less/most from source in most cases? Why?
Check the security sources -- are there any security holes reported for that particular package? Do you suspect any may be possible (it is possible to build a trivial game that includes a security hole, but how important is it to you to check the game's source for possible security holes?).
I will not say that it is wrong to compile *everything* from source, that is certainly admirable. But compile a to-do list with all the compiles and all the other stuff you have to do during the day/week/month, and then order all the tasks according to importance.
Now, think about the question about compiling a trivial package from source once again: how important is that to you?
Some instances of compiling from source are going to end up high on your list no matter how you order it, others near the bottom.
Fairfax
Both the poster and his friend seem to have missed a very important point: building from source should result in packages, and it it doesn't, you're not doing it properly.
RPM has macros that make it possible to package anything using GNU autoconf (configure; make; make install) in about five minutes. I bet dpkg would too. Anything else is generally pretty simple too (cpan2rpm for perl modules, make and archive and don't bother filling out the %build section for binary onmly apps, etc).
You probably won't ever see this because of how late I'm posting... However:
Building from source is great if you want to tweak a system and get it running exactly how you imagine. Be prepared for configuration and all the various issues associated with source builds. I'm assuming that even if you build from source that you are using some sort of package/file management system to alert you of dependencies and file modifications. This is easy to do with binary packages, not so easy managing sources. I regularly rebuild *on my test machines* all manner of software from source, including the kernel, KDE, glibc and a bunch of other libraries.
Now for the problems with source builds:
1) You need a development machine. I.e., you need the compiler tools and libraries. For a regular workstation this is no problem, but you DO NOT want these tools accessible on a server even if they're 'chmod 700' or otherwise locked away. This means you'll build on another machine and create a binary package and... well, you're back where you started except you lost some time.
2) There's no easy way to create snapshots of packages. Differences in libraries and config files can make or break software. The best errors are those that prevent the software from compiling. The worst are those that compile, but errors or weirdness doesn't show up until a month later. Now RPM is much maligned, but it does allow you to keep the build instructions, dependency information, etc.. inside the package. You get lots of control, once you've learned RPM, on where things get installed.
3) Backouts are not as easy. You can often do a 'make uninstall' but this requires the sources be kept around in some cases. Tools like checkinstall can ease the burden, however.
4) Duplication of effort. Source builds are good for customizing, as I mentioned. It's a myth, however, that rebuilding from source will dramatically improve performance except in a few, somewhat rare cases. E.g., rebuilding a 2.4 kernel with a pre-emptible patch can make your desktop faster. Rebuilding a stock 2.4 from kernel.org or your distro's sources will likely not be noticeable.
You must not run any systems that -need- to be up, or you're not paying for any good hardware support.
First, I do agree with you on the software support issue.
I don't think anybody is talking about component level repair, rather, replacement is the issue here. I can call a vendor and have them onsite within an hour for a 6-7 year old system. These are Intel compaq servers. Yes, you pay a lot for this type of support, but when a system -has- to be up, it's really not a lot of money compared to the cost of downtime. Drop in the bucket really.
Oh yeah, and I forgot to say I run Slackware since the first time I got in touch with the marvelous world of Open Source. What else...? Oh, I now use 'checkinstall' to create my own slackware packages (.tgz) and yes, slackware has a pretty good 'package managing system'. As already said it is called 'pkgtool'. To sum with it we have the slackpkg tool which makes our lives a bit more easier.
Building and installing from FreeBSD ports is just as easy and sometimes more reliable than installing a packaged binary. You might not get "instant satisfaction" from it, but I normally just do long compiles in the background while I work on other stuff in X. portupgrade makes it a snap, and you can get the lastest versions of ports before the binary package is updated back at FreeBSD.org. I can upgrade the java development kit or my entire OS while I'm sleeping. Also, since I follow -CURRENT and they've made a number of software-breaking changes, builds are clearly the way to go. The sort of programs I hate using are the ones that the company was nice enough to port to FreeBSD a few millenia ago but can't be bothered to upgrade, fix bugs, or even recompile. I didn't quite realize how clever and powerful this novel concept of portability and the ability to make your very own copy of an application was until I learned to use ports. Packaged software is crap.
Hey, why not switch to BSD and use the ports system, it keeps everything standardized and with tools like portupgrade, its just about as simple as a package install.
Hey, in the case of some programmers, their software should run everything out of your home directory. :)
Building from source once, and packaging it yourself is useful. But if you insist on building on all servers, you're downright mad, and I'd look at replacing you with someone more interested in effeciency.
Brian Seppanen
Minister of Information and Propaganda
Area 54 The Secret Government Disco Labs Provo
I probably didn't spell out my thoughts on hardware very well. I do carry support contracts on all my critical pieces of hardware. All of our new Dell servers have next day replacement. It's worth paying for HW support because it's not something the average guru can repair unlike software which is almost always able to be fixed. As a netadm we had maintenance on all our campus network switches. It's just a good way to go. Does that make more sense? Yes for HW. No for open source SW.
Hi, I am a gentoo user. I love it. but as I read the comments on this story I now understand why other linux users are annoyed with us. Even *I* am a little annoyed after reading this preachy stuff. Gentoo is great. If you don't like it... don't use it. If I run across someone that needs some help with it... By all means, I am happy to help. but PLEASE stop trying to convert everyone. I don't want to be part of the jehova's witness group of the linux world.
Obama is a twitter sock puppet
Package systems suck. /opt/package-name or similar.
/server directory (e.g. /server/samba, /server/openldap). This this distribution is really great for servers. It is very beautyful. No X Server. No stupid tools that do strange things without telling you. It boots in about 10 seconds on a Duron 1600 computer.
Source installs rock.
IMHO, the best way to install packages is to compile them and install them on a dedicated directory, like
Package installers suck. For example, I was using an RPM based distribution that had OpenSSL 0.9.6. I wanted to update to 0.9.7, but there was no RPM for that distribution. I couldn't delete 0.9.6 because other packages depended on it.
A similar program happened to me with the Postfix MTA. With that one, I removed the package and installed the source version and I always get an error saying I need to install postfix.
So I have on that server a mix of packages and source installs on some of my servers.
I am testing a distribution called Server Opimtized Linux that uses my philosophy. They install almost all packages in the
Highly recommended.
My heart is pure, but make no mistake, it's pure evil
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.
/var because that's What You Want.
Distros patch their apps to use the FHS. Sorry developer, you have no right to rape my system and put binaries in
Having this fixed is yet another reason to use packages. Hopefully the developer gets the idea and fixes his program.
While looking for a better source/package managment system than those recommended by linuxfromscratch.org, I found this: srcpkg
Works with both compiled-from-source and packages. Supports uninstall. Very easy to use.
What software have you installed that puts binaries in /var? I mean, I could whip one up right now I guess, but for anything I've installed it's cool.
Distros patch their apps and move stuff around for a lot more reasons the a standard filesystem hierarchy.
But hey, it doesn't matter. To each his own, that's what I like about Linux.
- It's not the Macs I hate. It's Digg users. -
there are plenty of installer projects
i'm personally involved in one at school.
http://pen2.sclab.clarkson.edu
(may be down right now...)
during a seemingly innocuous emerge, GCC was apparently unmerged or otherwise incapacitated.
Damn if you don't sound like one of my customers. "I didn't do ANYTHING! It just BROKE!" then you find out they renamed something, were in there typing a bunch of stuff they shouldn't have been, or generally doing shit they had no business doing because they are retarded. There was NO EMERGE BUG EFFECTING GCC. You DID SOMETHING TO FUCK UP YOUR BOX. It's not GENTOO'S FAULT YOU ARE A FUCKING MORON.
There is no shortcut. You need daemontools because it relies on "service" for monitoring, logging, and rudimentary host based access control where applicable. Just READ THIS and follow the instructions. Take the time to understand what the difference is between dns-cache and tinydns. Do yourself a favor and install axfrdns if you install tinydns. If you are going to do authoritative nameserving, read up on all the goodness HERE. I've taken the time to install the VegaDNS administration front end and it's pretty neat. The most useful patches so far that I've used for tinydns are the round-robin dns patch, the errno patch (to get the bastard to rpmbuild on ES 3.0 but I think debian is still using fred flintstone's glibc so you should be cool) and the patch for the new zone transfer method that BIND 9 uses. If you aren't needing to mess with authoritative domain hosting, you probably only need DNScache. It's awesome stuff. Good Luck!
For every annoying gentoo user, are three even more annoying anti-gentoo crybabies. Take Yosh from #Gimp for example.
not sure if this is mentioned already & too lazy to check > 600 comments :)
... oh, too excited. sorry.
take a source, compile it and create package. this way you will have less problems with upgrading, rogue files left from older versions and installing the same software on different machines.
as i use slackware i stick to checkinstall, it also supports rpm & deb and i believe that other distros should have something similar.
i used to have problems with all kind of software that i built from sources (and i always do this at least for apache/php/mysql) with old files, unability to uninstall them correctly utt - until i started to use checkinstall !
I'm continually surprised that Linux users don't take the approach taken by Solaris admins - if you build it from source, you might as well build a package for it and keep it in your package repository for future installs. It also makes upgrading/uninstalling much easier, and allows you to easily integrate it into custom installs.
I work as a systems administrator on several hundred servers worldwide. I have made sure that all of the processor / os version and gcc etc versions are identical on these servers. i then have a separate system for what i call staging (im sure others do also)...
From this I build the source and make packages so that I can easily install the software and manage it on the other servers. The real benefit of packages is that its easily removed and installed.You can always see whats on your system in one go. And being able to md5 all the files on the staging system allows you to run checks on breakins etc more efficiently.
I compile everything from scratch. I'm a Slackware devotee for reasons of habit and, well, always just been a CLI guy. A mouse for an install? Gag me with a.. umm.. mouse?
What would I prefer? A perfect world where I know exactly what dependencies (and their respective versions) are required for every single piece of software that I install. Hell, I just had that struggle this morning trying to compile some stuff on servers that didn't have a single X11 library installed.
What we really need is something as cool as CPAN, that notifies you of library/module version dependencies when you install something, and actually PROMPTS you to install a new dependency module.
In the 10 years I've been using Linux, I've probably used RPM or something like it about 5 times. But after tooling around with Cygwin on my Windows boxes, and getting an X server, the latest Perl and Python running in 8 minutes -- I think I may just have to check out what this Gentoo hype is all about.
see subject. ;-)
I do both, depends on the time I have on my hands and the package (source or binary) I can find. Usually build from scratch on my desktop, as it is Gentoo and it gets me the latest version.
My server has to get binaries, because there is no C compiler installed there, or even the make tools. Because of security reasons. So what happens is I build it from source on my desktop, make a package and install that on my server.
-- The Internet is a too slow way of doing things, you'd never do without it.
I am not a Debian developer, but I play one on TV:
maintainers are overwhelmed with the complications of actually running an install and uninstall
They should be using file tracking tools to help them. Scold them.
documentation lags
Yes, this is a common problem; but it's also an easy thing to submit bug reports on. Chances are, if it's in the bugs DB, it'll get updated by the next pkg release.
updated features are extremely delayed
apt-get --target-release unstable install foo (this will also update all the dependencies -- if you can't handle the instability that comes from doing that, there's still a good chance you can build the unstable package against stable build-deps)
troubleshooting difficulties. When I have a problem, I can't always determine
Yeah, this is a bitch. I've taken to trying upstream first, although every Debian developer I've ever submitted a bug to has been nice about submitting it to upstream if I misattribute the bug. It would be nice if the Debian bug database were more integrated with other bug databases (even with links to the appropriate sites as they're sometimes non-trivial to find).
As the numbers of machines you manage increases, you will find the meaning of the word "control" changes. We only manage a couple of hundred, but the pressure to standardise, as far as is practicable, is a strong one.
Look at the people running clusters, and you can see where that gets to in the end.
The reason we (primarily) use Debian is that the potential architectures for distributing change, and for customisation-with-binary-releases seems to be much greater.
I do ./configure --prefix=/usr/local/pkg_name plus whatever other options, then make. When make finishes, I mkdir/usr/local/pkg_name-version, and ln -s /usr/local/pkg_name to that, then make install.
/usr/local (gnu utils like groff, less, stuff like that) only things like gimp, gcc, TeX, python etc get their own directory. This keeps the PATH sensible.
/var/log/app_name, and tablespaces. I always try to keep /usr/local as static as possible.
I get all my applications in their own directory, and it's only a matter of changing a link to roll back a version or two. It's also easy to copy an app to another host.
Some discretion is necessary here: I just dump a lot of small stuff into
My main OS is Solaris, but I employ this technique on HP-UX, Linux, BSD, whatever I'm working on at the time. Keeps things simple for me, and it's easy to tell someone else just where things are.
The only time I go outside the app dir is for things like logs, which always live in
As for maintining consistency across a network - NFS?
When I first started using Linux, I used the rpms. However after several disasters where the dependencies wouldn't work out or the binaries just wouldn't work, I started doing source only.
Reciently I've started using rpms again. Mainly b/c if it works, it's easier to upgrade, uninstall, etc. They seem to be a lot better now than they were a few years ago.
I only use source now when something doesn't work right or I want some special configuration.
Packages are convenient, but sometimes one really should consider using source. For instance, some tools like lsof (great tool btw Vic!) have so many server-specific hooks that installing a generic package likely causes some amount of feature neutering. I try to stick with source when I have the time available to install it, or when a product "should" be customized for a particular system. On the other hand, how many times can one stand to Config and compile only to have cc blow up or waste an afternoon debugging why make install fails... Then there's the "well I finally got the bzip2 source, but I gotta build gcc before I can build bzip2 so I can unbzip the lsof source..." :P
(Yes, it's my Yahoo id)
I wrote a lengthy reply to this on my journal. Sean
That is simply not true. I have personally fired few people for doing just that. Actually, I have fired them mostly because of buying Microsoft software installed on IBM boxen, but I have fired them nonetheless. So please stop spreading that myth.
Could you please explain that supposed proof? I honestly fail to follow your reasoning.
Sincerely,
Pan Tarhei Hosé, PhD.
"Homo sum et cogito ergo odi profanum vulgus et libido."