Slashdot Mirror
Build From Source vs. Packages?
mod_critical asks: "I am a student at the University of Minnesota and I work with a professor performing research and managing more than ten Linux based servers. When it comes to installing services on these machines I am a die-hard build-from-source fanatic, while the professor I work with prefers to install and maintain everything from packages. I want to know what Slashdot readers tend to think is the best way to do things. How you feel about the ease and simplicity of installing and maintaining packaged programs versus the optimization and control that can be achieved by building from source? What are your experiences?"
Gentoo! (Combines the best of both worlds)
is that compiling from source can sometimes even be slower executing depending on your compiler.
Also, better to install from packages because:
1. They WILL work
2. They install fast
3. They are easilly de-installed
4. They are painless
5. Dependencies are installed automatically sometimes, and other times packages are the only way to resolve a dependency loop
6. Most other OSes since the dawn of the home computer use pre-compiled binaries, and nobody has complained
7. It is surely the developers job to make sure it compiles properly and do all the compiler error headache solving
Packages are just so much nicer. A lot of the time, I can get pentium-optimised versions of the ones I want, and if I can't then 386 optimised versions are OK by me. The difference in speed one sees is pretty much only for the anally retentive, it is so minimal.
- emerge -k (packagename)
This must be pointed out before the normal Gentoo FUD starts getting thrown around. Also, before anyone slams Gentoo, they should read and learn: Dispelling the myths of Gentoo Linux, an honest reviewCvswdsf
free ipod and free gmail!
Most package systems allow you to "roll your own" packages from the software you build from source. I use Slackware myself, so I first install my apps into a "staging" directory and build my package from there using the makepkg command.
It takes an extra minute of your time when you're installing software but it really helps to keepi track of what software is installed on the system, what files belong to it, keeping track of versions etc.
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
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 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.
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.
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....
To allow multiple versions of one package to be installed where such situations may arrise, Gentoo provides the SLOTS mechanism to avoid conflicts.
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
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/
This makes gobs of sense in some situation and very little in others.
I grant that when my coworker build the beowulf cluster, it made lots of sense to have everything optimised out the hilt. However when I watched him build his desktop, and it took him, on a very modern machine just a year ago, nearly 3 days to have a full working system with X etc... thats overkill.
I don't need an optimised ls and df... I can do just fine with them compiled for a 386. The vast overwhelming majority of binaries on my system will give no benefit whatsoever if compiled with all the optomisations to tweak it to the box.
I am a fan of this...
I use debian... I install everything from packages as a rule. However for those few, oh so very few, packages that really need customization, then I compile them myself.
At this point, I can't think of a single package that I do that with right now.
My basic view is this:
Compiling something that I don't NEED to compile is a waste of my time and CPU. I also like the idea of NOT having to have a compiler on every machine I run. A production server should never have a compiler on it, doesn't need it. Now I know the security argument is silly, any cracker worth his salt can put a compiler somewhere and use it... however....
Nobody should ever be compiling anything on a production server. If the machine is in production, then development should not ever be done on it. All that should be done elsewhere. SO why leave a compiler sitting there begging lazy admins to use it?
(OH yea and every rule can and should be broken at times, but its important to understand the rule so you know when those times are... thinking about where compilers are needed and where they arn't is a good exercise in developing those disciplines)
Overall, I think gentoo is neat... and on our solaris systems
we are considering stealing portage and hacking it a bit to build
solaris packages for us. Anyone else done this?
-Steve
"I opened my eyes, and everything went dark again"
For the record, the problem you describe actually is solveable within the Debian package system, although it comes under the heading of "advanced". You can build an actual package, of course, but short of that, you can make a "pseudo-package" that doesn't install anything, but has the required Debian package "provides" header. Then the apt package database will know about the capability, and will be able to install things which depend on the functionality you've put in by hand.
I mention Debian because I'm aware of it -- it may be that the RPM system has something similar, I don't know it as well.
2*3*3*3*3*11*251
Which is why Portage is so handy. It builds from source and takes care of package removal. It also offers config file protection so a new version of a package doesn't stomp all over your carefully configured system.
There was Cowboy Neal at the wheel of a bus to never-ever land.
You can just put the /usr/portage from your compile server on nfs and have all other machines export it, you know.
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.
With rpm, just write a .spec for your library or whatever it is you're installing, drop it in the source directory, and run rpmbuild to make an rpm.
.spec that describes what the package provides is easy. Just modify an existing .spec from another package.
Making a barebones
Hands in my pocket
For quite a while I used RedHat and did enjoy the ease that package management gave to a system. For a workstation equivilant, I still agree with this solution in general. However having run through Linux From Scratch (www.linuxfromscratch.org) I see that on a server-class machine, there is a TON of unnecessary bloat. Why should it take a GIG of space , or more, to host just a Web server with MySQL and FTP access? With LFS I can build a specific purpose system and get that footprint down to around 350 to 425mb and that's including the kernel sources being left for recompile and a full compile environment. I've been told that some people can get the same functions stripped down to less than 200mb (this is all of course NOT counting your SQL databases).
At this point there needs to be a big fork somewhere to divource the Linux Desktop from the Linux Server. Linux will do both, but one should not cause issues for the other. If a desktop user wants to run a FTP server, they should be able to. If the server admin wants to have a mail client (pine) or an IRC client (BitchX) installed for accessing information, he should be able to. But these features should be implemented with that specifically in mind. Not installing half a million libs because *maybe* the server admin wants to install addon XYZ for pine and it needs this lib while pine itself doesn't...
Stow lets you install each package in its own directory (i.e., /opt/pkg-x.y.z), then symlinks them into a unified /usr/local tree. Stow -D pkg-a.b.c removes the symlinks for just that package, letting you do a single package uninstall. You can manage the files on a per-package basis, while users can ignore all the details, as it looks like everything is installed in /usr/local/bin to them. Stow provides a simple solution for building packages from source on any UNIX.
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.
It's not really harder, I would argue it is in fact easier in Gentoo. To reproduce a Gentoo system, you need the list of installed packages (either from the 'world' file, or from 'qpkg -i'), and the global make.conf. You can easily emerge any version of any package, so if you don't want the latest tested code, you can request earlier versions of the packages...
icc, btw, is free for non-commercial use on Linux.
The Raven
My biggest grievance against packages is the dependacy fiasco.
Ah, thank you! Someone said it. I always thought only I had that problem, due to my preference for building most things myself.
I think, though, that this problem doesn't so much result from the whole RPM (or whatever package management tool a person uses), as a philosophy in programmers in general. I say this due to an observation at a recent job interview... They wanted someone who "knew" some (still) video processing techniques, and I rattled off some work I've done in that area. The next question really threw me - "What library/API do you use for that?". Well, none, of course - I wouldn't claim I know how to, for example write a JPEG, if my knowledge of that task extended only to calling libjpeg's jpeg_start_compress(), jpeg_write_scanlines(), and jpeg_finish_compress(). Sure, knowing that doesn't hurt, but it does't require any understanding about the structure of a JPEG in general.
In my own code, I try to produce as few dependancies as possible. If you have GCC installed and nothing else, my code will generally build and work as I intended it. I need to write a compressed bitmap? Okay, then I include code to do so. I need to read a wav file ripped from a CD? Yup, my own code. Calculate an MD5? Inspired heavily on the RFC reference code, but essentially my own. I think more programmers need to do similarly. Don't say you "know" how to do something, if you couldn't write it yourself. And with the exception of very large packages that count as critical for a given task (OpenGL as an example), try to avoid pulling in a library just to do some trivial task.
Now, as I mentioned, for some tasks, you really need to pull in a library. OpenGL, for example, where not only do you have a lot of code in there, but also a number of hardware optimizations that would take years to reimplement. But even then, when I say I "know" OpenGL, I mean that I could, if necessary, implement it from scatch (and have done so, for most of the primatives, just to prove to myself that I could do it).
Okay, I've gone off on a large tangent here. My point - Just that programmers need to stop depending so much on relatively minor libraries, and implement more in their own code. And when a program does depend on a non-ubiquitous library, at least for binary distributions, they should statically link against it. Perhaps "Bill's Custom C-Strings Library" offers some great features. But when a package links against it for the sake of using a single function that the programmer could have reproduced in under ten lines of code... Well, that just screams "laziness" to me. Yet, I see situations like that all too often.
I tend to agree, but I have found one case on Redhat where RPMs give me nothing but trouble: Perl.
I have always had problems with Perl when I go to install a new module from CPAN if Perl was installed with an RPM file or came with the system (i.e. installed when the system was installed). Perl itself works great, but some CPAN packages barf when I try to compile them. Tk is the worst offender. I have yet to get it to compile cleanly using an RPM'ed Perl. Some modules are very sensitive to the exact configuration under which Perl itself was compiled, and more likely than not the Perl RPM was created on a system different enough from mine to cause problems.
The same thing happened to me just a month ago when I got a brand new machine with RH9 preinstalled. Tk would not build properly with the preloaded Perl, so I downloaded and compiled my own from scratch and it worked perfectly after that.
Karma: Frotzed (mostly due to the Frobozz Magic Karma Company)
"But the installer has a *long* way to go"
What installer? Gentoo's only official "installer" is the install documentation.
In my opinion if Gentoo wants to gain a larger user base it needs one. But I definately learned a lot from installing it without a pretty gui installer.
which is why you should always save the output of "make install" somewhere. I keep mine in /usr/local/install_logs
My biggest grievance against packages is the dependacy fiasco. That's why you use apt or yum.
Each ebuild (package) specifies a SLOT variable, which is populated by the author of the ebuild. Roughly speaking, this variable tells Portage that the versions of the package are different enough that both versions need to be around, in order to satisfy the dependencies of other packages.
For example, I have both 1.3 and 1.4 versions of the Sun JDK on my box. The sun-jdk-1.3.1.10.ebuild file has the line SLOT="1.3", while the sun-jdk-1.4.2.04.ebuild file has the line SLOT="1.4". Now, if Sun has another release of JDK 1.3, the ebuild maintainer releases a new ebuild that has that same SLOT="1.3" line. Portage now knows it is safe to replace the old 1.3, but to keep the existing 1.4, as well.
#portupgrade -a
or, if you prefer packages
#portupgrade -aP
Even Jesus hates listening to Creed.
I agree. Except for the most simple minded of applications someone else has made decisions for you if you use rpms. Maybe those decisions are good enough, but maybe they aren't. The only way to be sure is to grab the source and build it for yourself. I'm building things to be used by 1-2 thousand concurrent users, so I do care about that extra 5% performance improvement.
As important, if not more important, is that building from source allows you to turn off features you're not using. This can improve security by offering fewer chances for buffer overflows and such. Also it may improve performance.
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.
My solutions for that problem:
$ cd
$ find . -type f >
Sure, like any distro, an install will blow here and there due to dependencies, but, for the most part, I find it rarely happens with Gentoo....and makes the whole process so easy to do.
Light travels faster than sound. This is why some people appear bright until you hear them speak.........
I build the mission critical programs from source code, and just let the rest be installed as binary packages. I build from source even if I don't need to just to be sure I won't have extra unexpected issues should I ever need to actually make modifications to source and rebuild. I really don't have very many local modifications, but I'm prepared just in case.
Additionally, I do this all on one master machine (with a backup of it kept live on another machine), build binary packages of my own from my source builds, and install those packages on the actual servers. That way I have even more consistency, though at the cost of ultimate optimization. But I think it is better to be able to quickly reinstall a machine, as well as use checksum verifications that there are no trojans.
I use Slackware, but this could be done with most systems, including FreeBSD, Linux (most distributions, including Debian and the RPM based ones), NetBSD, OpenBSD, and even Solaris.
now we need to go OSS in diesel cars
That's why rpm provides the ability to add an entry to the package database without actually installing the package from rpm.
It's generally more expensive to build hardware than to buy it. I work for DoD and buy about a zillion computers a year. My organization has ~2000 employees and PCs are on a four-year replacement cycle. In order to build machines in-house I'd need at least one additional full-time employee (cost about $70K including benefits) and the space to build the machines.
Right now I'm *buying* computers from a major manufacturer - 3.2GHz, Intel, 768mb RAM, 40G hard drives - perfect corporate machines - for $907 each. The major manufacturer guarantees hardware compatibility for 36 months so my existing sysprep loads will work, provides 36 month onsite warranty support and will inflict my image on these PCs for free. You can't build 'em that cheap.
I just bought a bit more than 500 machines this year - the full-time employee alone would add at least $140 to the price of each PC you built and I'm a bit skeptical that you could build and support those machines with only one person.
In short, you can't build the same PC, guarantee hardware compatability, inflict a standard load on them and provide worldwide onsite warranty support for anywhere near the $907 for each unit I just bought.
we see things not as as they are, but as we are.
-- anais nin
You can get Portage for Redhat. You can get it for any distro you like. Check out the gentoo.org forums.
I've been installing Gentoo for about 3 days now, so I've been reading a lot of junk on the forums, and have come across threads about how you can install Portage on other distros. It doesn't look all that complicated either. As I recall people have even written bash scripts to do it for you.
...unless you're referring to the limitted selection on the gentoo cd's, then no, you can't use binary packages unless you've pre-built them yourself.
l ?part=2&chap=2#doc_chap3 :
/usr/portage/packages/All directory, while the source code of the packages is placed in /usr/portage/distfiles. If you have finished installing a package you can remove the package or source code from the respective directory. However, you might want to keep the package/source code of the latest version, just in case you want to reinstall the package (so you don't have to redownload it). ...
/usr/portage/packages/All if the package and the version of the application you want to install match.
/etc/make.conf.
1) if your mirror doesn't have binaries, add one that does to PORTAGE_BINHOST (check with #gentoo or gentoo forums for urls)
2) emerge -k foo that'll emerge the binary package of foo.
more info from Gentoo's FAQ http://www.gentoo.org/doc/en/handbook/handbook.xm
2.c. Maintaining Software
Building or Prebuilt?
Gentoo provides ebuilds, the Gentoo packages if you like. But when you want to install such an ebuild, you can choose between building the package and using a prebuilt package. But what are the advantages/disadvantages of both approaches, and can they be used next to each other?
As you probably have guessed, building packages takes a lot of time (especially if you have little resources or want to build big packages, such as KDE, OpenOffice.org, etc.). By building the package, you can use the USE setting to tweak the package to your system. Of course, you can also define high optimization options (in the CFLAGS and CXXFLAGS variables) to compile the package with.
Using prebuilt packages improves the installation time (as no more compilation is needed), but you will lose the advantages of the USE setting and the CFLAGS & CXXFLAGS variables.
As previously stated, prebuilt packages are stored in the
Installing Prebuilt Packages
When you want to install a prebuilt package, you should use the --usepkg option (-k in short). This will use the binary package available in
Code Listing 18: Installing a prebuilt package for gnumeric
# emerge --usepkg gnumeric
If you want to use the binary package, even if the versions don't match, use --usepkgonly (-K in short).
Code Listing 19: Installing the prebuilt package for gnumeric
# emerge --usepkgonly gnumeric
If you don't have the prebuilt package on your system yet, you can have emerge download it from a mirror, defined in the PORTAGE_BINHOST variable declared in
To download the binary package in case this package doesn't exist on your system already, use --getbinpkg (-g in short):
Code Listing 20: Downloading and installing a prebuilt package for gnumeric
# emerge --getbinpkg gnumeric
This will download the package and the package-related information for you and install it on your system, together with the dependencies.
CB
free ipod and free gmail!
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.
>> I run Slackware. Most of the major stuff I need is avaliable as official packages from Pat, and quite a bit of other stuff is avaliable on LinuxPackages.net
Exactly!
and anything left that isn't at either of those two sources, compiles like a dream.
because slack uses un-altered source code from the original authors.
i see people beat themselves because they can't get package xyz to compile on redhat/fedora.
after hours of searching on google, they find out that the redhat tweaked dependency/kernel fubars other packages that depend upon them.
this happens in gentoo, debian, suse & mandrake as well.
slack is the purest linux, and the most unix like of them all.
my other OS is great too, but it's dying. (freebsd for you newcomers)
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.
Indeed. I find the greatest benefit of Gentoo is the USE flags. Because of them I have many more video and audio drivers available on my gentoo box than my debian machines. Just specify, for instance, "opengl" in the USE flags, and everything is automatically built for opengl. I've been surprised to find out how many apps have opengl support that I never knew about. Still, the fragility of portage and its tendency to leave cruft around keep me in the debian camp most of the time.
Give me Classic Slashdot or give me death!
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.
http://lunar-linux.org/
the installer is maybe not friendly enough for you, but maybe it is.
Surely, the logical extension of your argument is that you shouldn't abdicate responsibility by using whichever kernel some programmer decides to write, either. That's obviously ridiculous, and so is a blanket rejection of packaged software in favour of building from source. Installing pre-compilled packages isn't an abdication of responsibility, it's delegation - if you ascertain that a particular packager or distribution has standards you're prepared to trust, trusting them is no worse than trusting the power company to keep the electricity flowing to the machines.
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'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 *
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.
I use Apt for RPM to keep my RedHat boxes up to date. As a busy Sysadmin/Programmer, its easier to just get the stuff updated or a new machine up than it is to compile everything.
I know how to compile everything but when the PHB is screaming at you to get stuff done it becomes impractical.
Oh apt for RPM can be found at Freshrpms
The Anti-Blog
They already have one based off of Anaconda. I have no problem making things easier...I just don't think it should be their ultimate priority to try and become like Mandrake or something like that, and if they want to go that path, I'd hope they would keep the old way of installing.
Mark Loeser
SNMP-monitoring tools that can be compiled to pre-load MIBs often (usually?) default to "all". Setting it to "none" and feeding the MIBs in by OID only as you need them can show improvements of 1600%. I've done it myself.
Send your friends messages of love at fuck-you.org
I don't know if you still get to read this, but if you use unstable in your sources, try installing apt-build.
As long as there are Debian source packages available, it will build everything from source (including dependencies) with whatever flags you like, and put the built packages in a local repository. Just add that repository to your sources.list, and you can install locally built and optimised packages of just about everything.
It is not quite up to the standards of usability of Gentoo's portage or BSD's ports system, but it works quite nicely.
Mart"I know I will be modded down for this": where's the option '-1, Asking for it'?
That's easy. Get the source again and build with the same target options as previously. Then "make uninstall" as root.
Isn't that the #1 reason to use packages instead?No, it is not.
There you are, staring at me again.
That's matter of methodology. I always keep a source tree I have built from, for 1. uninstall ;-) and 2. just for case something went wrong so I can look at the source.
I always uninstall old version only if new version build succeeds. If it fails at runtime, no problem to roll back the old one. This is not so easy with packaged dependencies. With critical ware, I keep even multiple versions build tree around. A single dedicated 100GB drive holds me stuff for all platforms I use (i486, i686, arm), and I still have a 80G in reserve. A CD/RW is my friend, too. And you are right, broadband *is* essential, but even some distros are about 1G of packages updates monthly (Mandrake cooker).
For example, I don't want to waste time compilingNo need to waste your time. Did you try "nice -n 10 make"? I always run builds on lowered priority. Just now, I am building globulation somewhere on the background here...
There you are, staring at me again.
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