Slashdot Mirror
Should You Pre-Compile Binaries or Roll Your Own?
Jane Walker writes "The completion of pre-compiled packages and maximizing machine performance are two powerful incentives for Windows admins to use Linux and compile an OSS package." TechTarget has an article taking a look at some of the "why" behind rolling your own. What preferences have other Slashdot users developed, and why?
I feel that Gentoo Linux offers the best of both worlds, with their ebuilds. :-)
Was I the only one who found that this article didn't really shed too much light on whether or not you should compile your software from source?
By the way, I know the benefits of compiling from source, but how this made slashdot, I don't know.
What the hell's a "gewie?"
I have a feeling that this will turn into a general debian vs gentoo style debate, and we all have our preferences.
The big benefits of precompiling are that you don't need to support 1500 different sets of libraries in your development environments, and that the package will generally work right with minimum fuss.
The big benefits of source-based distros are the ability to tailor packages to each install (ie the ability to compile certain features in or out), to choose optimizations on each package (do you want -Os, -O2, -03, or are you really daring -> -ffast-math?).
There are some things that cut both ways - often a given package can be compiled using one or more different dependencies and if you want this flexibility then source-based might work better. On the other hand, it also means that if you have 500 different users of your distor you have 495 different configurations and bugs that are hard to reproduce.
As for me - I like source-based. However, if I had to build a linux email/browser box for a relative I'd probably use Debian stale...er...stable. The right tool for the right job.
Conversely, if programmers sufficiently document their binaries, that's not as much of a problem. URLs for other binaries, or instructions for checking/compiling dependencies, can speed up that process.
Of course, binaries are a huge advantage to non-experts and beginners, who just want a program to be there. They don't care about maximizing efficiency, they care about getting their work/fun done.
So really, it entirely depends on the application. For programs that are typically for the hardcore programmer/user crowd, source-only makes sense -- those people who use the program are going to know how to compile and check everything already. But for programs like, say, a CD burning program? I definitely think both should be provided, and installation for both should be well documented. Given how easy it is to provide a binary, even if it's "fat," there's no reason why a more popular program can't provide both versions.
Recompiling software gets you almost nothing. Maybe 10% more performance, at the very maximum.
There are special cases like when you want to use dynamic libraries instead of static (to save memory), or when there's a major architecture change (PPC -> x86 for Apple). In those cases you'll gain something.
Another case is rewriting your program to use CPU-specific instructions, like Altivec or SSE3. That, in certain circumstances, will speed up your program.
But if you're compiling OO.org or Mozilla because you think your 686 version will be 100% faster than the 386 version, you're wrong.
My other car is first.
If the time required to compile (plus trouble) is less than the time/trouble saved through performance gains (assuming you actually compile it correctly to get said gains), then compile. Else download and install.
But then again, if you just have a lot of time on your hands, it doesn't really matter what you do.
The difference between spam and poop is that you don't have to dig through septic tanks looking for real food. -- Me
I used to that when I first got into Linux so many years ago when a lot of hardware wasn't supported or you need to add some special parameters. These days, with the latest distributions, I don't have to do anything special since everything is recognized and supported. In fact, I don't remember how to compile the source anymore. At 36, I must be getting old.
In my field, ten percent is everything. If I could increase performance by ten percent, I'd get a 100% bonus for the year. My servers need to handle so much data and are always backlogged (and adding more on is exensive!) Don't trivialize ten percent.
Rank my idea: http://www.sinceslicedbread.com/node/531
On my FreeBSD I compile almost everything from ports. That way you have maximum control about the options and CFLAGS with wich your app is compiled.
It's as easy as 'cd /usr/ports/category/portdir; make install clean'.
If you have a number of identical machines, you could compile and build packages on one machine, and then install them on all the others.
On Linux I think that Gentoo's portage comes closest.
Never ascribe to malice that which is adequately explained by incompetence.
Can we please avoid the "Gentoo and LFS" vs. "Everyone else" flamewar that will ensue?
Just in case, though, I'm getting my asbestos suit...
It's true that gcc can generate P4-specific code, for instance, but in most cases and with generic compilation flags this will barely make a difference. I am personally not aware of a single mainstream linux app that does 5% better when optimized for P4 as opposed to generic 386 (I'm not including here apps that have hand-crafted assembly for a couple of instruction-set architectures, like, say, mplayer). I guess things might change slightly with gcc 4.* which has automatic vectorization, but in my experience automatically-vectorizable C code is very rare, unless written specifically that way.
The Raven
I think the headline should say "use pre-compiled binaries". Otherwise the proposed decision is to basically precompile or compile.
"Should You Pre-Compile Binaries or Roll Your Own?"
How much time do you have, versus what do you gain in that time? Beyound bragging rights that is.
Up until this past year I've been a big fan of using a very stripped down Redhat (then later Fedora) distro and doing my own custom compilations of things like OpenSSL, Apache, OpenSSH, DHCPD, BIND, Courier, MySQL, PHP, XFree86 and X.org, and of course the Kernel itself. The main reason? It "just works". When I originally started using Linux and used RPMs I was very annoyed with them. I think RPM sucks. I also think BSD ports suck too. I don't like using stuff on my machine that I didn't massage first. That's just the way I am.
A co-worker introduced me to Gentoo late last year and I have to say I am very impressed. It's much faster than the optimizations I was using. Of course I didn't compile everything in RedHat or Fedora by hand. That's why Gentoo really rocks. You CAN hand compile everything from the ground up! I also used to use Linux From Scratch. And YES, I do use this stuff on production machines. You just can't get any better performance or security by doing it all yourself. The only reason to use package managers is if you are new to Linux or just don't want to learn much. But if you don't dig in, then you're at risk of thinking that something in your installation is broken, when it's not. I've seen many people throw up their hands saying, "I have to re-install my Linux box dammit!" when all they really needed to do was fix a symlink, edit a config file or downgrade something for compatibility reasons.
For example, on a laptop at home I decided I wanted to use the Xdmx server from X.org, so I hand compiled X.org. After that, I kept having this problem where the acpid (tracks the laptop's battery life among other things) daemon wasn't starting and would produce an error message whenever I logged into Gnome. I dug around on the net for quite a while and finally found out that the version of X.org (a devel version, not a stable version) grabs ACPI if you are using the RedHat graphical boot screen. The fix? Stop the RHGB from running by removing the RHGB kernel option. I think a lot of people would have assumed they hosed their installation and reinstalled if that problem really bothered them. It's not hard to find solutions to most problems in Linux no matter how obscure. That's why only knowing how to use pre-compiled binaries is a detriment if you're serious about using Linux.
-"...bad old ideas look confusingly fresh when they are packaged as technology" - Jaron Lanier (Digital Maoism on Edge.o
Unless you're running on special hardware (like a VIA chipset, for example), it's incredibly unlikely that compiling your own binaries will get you any particular performance advantage.
./configure (typically). It's pretty handy to have control over this stuff, and it DOES get to be a bit wasteful if every binary you have installed has every possible option linked in.
./configure --help | less
There is a very good reason for compiling your own, though: you can control all kinds of things via
N00bs obviously find the compilation process a little daunting, but it's a good exercise in figuring out how things work and fit together:
Do these guys even know what deplpoyment means?
They are not only wrong in their conclusion, but the article barely scratches the surface of the question.
Put simply, compiling software on your own is fine for a one off, or your desktop, or your hobby machine.ou.. or if you either a) need the latest wizbang features (and maybe can put up with the latest gobang bugs) or b) need really specific version control or c) can't find a precompiled package with the right ompile time options set.
Other than that, you should pretty much always use pre-built.
Sure, you can build your entire system from scratch if you like, libc on up. Why? The performance increase will be so minor that you will have to run benchmarks if you even want to be able to tell there was a change. You will then have to recompile everything you ever decide to update.
This strategy is a nightmare as the systems get more diverse and complex.
it also has nothing to do with deployment. Deployment is what you do after you have decided what you want and made it work once. Deployment is when you go and put it on some number of machines to do real work.
I would love to see them talk more about the differences in deployment. With precompiled packages from the os vendor, ala debian or redhat, its easy. You use apt-get or rpm and off you go. Maybe you even have a redhat network satalite or a local apt repository to give yourself more control. Then you can easily inject local packages or control the stream (no, sorry, I am NOT ready to upgrade to the new release)
but should you compile "most of the time"? hell no!
It is, in fact, the vast minority of software where you really need the latest features and or special compile options. Its the vast minority of the time where the performance increase will even be perceptable.
Why waste the time and cpu cycles? Takes over a day to get a full gentoo desktop going, and for what? I can have ubuntu installed and ready to go with a full desktop in maybe 2 hours.
Lets take the common scenario.... new openssl remote root exploit comes out. The email you read just basically said, in no uncertain terms, that half your network is now just waiting to be rooted by the next script kiddie who notices. Thats lets say... 50 machines.
Now your job is to deploy a new openssl to all these machines.
You could notice that the vulnerability came out in such a time frame that they allowed the OS vendors like debian to release fixes (often happens, if not they are usually out within a very reasonable time frame)... so you hit apt-get update && apt-get upgrade
or maybe you just promote the packgae into your repository, and let the automated updates deploy it for you. You go home, have a coffee, and be ready to log in remotly if anything goes tits up.
Now if you are hand compiling what do you do? Compile, test. And then um.... ahh... scp the dir to 49 machines and ssh in and do a make install on each?
How is this better than using a package manager again? Now you ahve dirs sitting around, you have to hope that your compile box is sufficiently similar to the other boxes that you didn't just add a library requirement (say because configure found that yoru dev box has libfuckmyshit.so installed and this neat new bits of openssl can make use of it)
How about when a box crashes and burns and you now need to take your lovingly handcrafted box, and rebuild it, and put all that lovingly compiles software back on it.
Fuck all that... give me a good binary distro any day of the week. I will hand compile when I HAVE to... and not before.
-Steve
"I opened my eyes, and everything went dark again"
If you're compiling your own for performance reasons, don't bother. There's a few packages that can benefit from being compiled for specific hardware, the kernel and libc, for example, and things like math libraries that can use special instructions when compiled for specific hardware. For the most part, though, your apps aren't going to be limited by the instruction set, they'll be limited by things like graphics and disk I/O performance and available memory. IMHO if you're trying to squeeze the last 1% of performance out of a system, you probably should look at whether you need to just throw more hardware horsepower at the problem.
The big benefits and drawbacks of custom-compiled vs. pre-built packages is in the dependencies. Pre-built packages don't require you to install development packages, compilers and all the cruft that goes along with a development environment. You can slap those packages in and go with a lot less installation, and you can be sure they're built with a reasonable selection of features. On the other hand, those pre-built packages come with dependencies. When you install a pre-built package you pretty much have to have the versions of all the libraries and other software it depends on. By contrast, when you compile your own packages they'll build against the versions of other software you already have, using all the same compiler options, and they'll probably auto-configure to not use stuff you don't have installed. This leads to a more consistent set of binaries, fewer situations where you need multiple versions of other packages installed (eg. having to install Python 2.3 for package X alongside Python 2.4 for package Y) and overall a cleaner package tree.
Where the cut-off is depends on your situation. If there's only a few instances of dependency cruft, it may not be an issue. If you have a lot of dueling dependencies, it may be worth while to recompile to reduce the number of different versions of stuff you need. If you've got externally-dictated constraints (eg. only one version of OpenSSL is approved for your systems and everything must use it or not use SSL at all) then you may have no choice but to compile your own if you can't find a pre-built package that was built against the appropriate versions of libraries.
Most software has at least one mutaly exclusive option, if even just libray version numbers. If it can't be set while it's running your only choice it to compile it yourself leading it to be something to know. I personaly haven't seen a real performace boost worth the time it takes to leave the beaten path of precompiled binaries. I'm sure it's there but i don't belive it realy worth the trouble. Both Amd and Intel design their architetures to preform well with backwards compatiablity. Licensing problems with distribution is can be gotten around with source only distribution since gpl allows you to do about anything if you not redistributing such as linux multi-media apps are plagued by patents. I'd know how to do it, but leave it as a last option
I think I just cashed out all my cool points.
sorry about that, screwed up the second link (I'm trying to make tea and post to /. at the same time)
Another missed point is it's usually easier for the developers and hardware vendors. Easier to distribute source code than maintain dozens of binaries. Just another advantage of open source. Many projects have a few binaries for the most popular platforms, and source code for those who want to use something less common.
Latest version and leading edge. I've been trying Gentoo. In most cases the extra performance isn't much, and isn't worth the hassle. And Gentoo defeats one of the attractions of roll your own: the leading edge. There is always a lag between when a project releases a new version, and a distributor can get around to turning the new version into a new package. Article didn't mention that aspect either. If your distro is slow, you can bypass them and go straight to the source, or, if available, the source's binaries. Ubuntu Linux 5.10, for instance, is still stuck on Firefox 1.0.7. I'm not talking about checking out the very latest CVS source tree, just the latest release.
Intellectual Property is a monopolistic, selfish, and defective concept. It is "tyranny over the mind of man"
After doing the LFS hard labor and basking in the wam smug glow of knowing my system was 100% built by hand I really got to appreciate the from source route as a security feature (as in I actually *HAD* read through every line in the system - at least a quick glance) But it doesn't scale well. What did I have? Basically a kernel, uClib and busybox, great for an embedded system, but not quite a desktop. It took me a futher week to get some semblence of X running and it never quite worked out. The best part though was learning to config packages by hand, and also realising that I could build static binaries without any dependencies at all. In fact there is an optimal scale of system, probably something about as complex as a kiosk application, where this tradeoff between building one-off statics vs a huge library of .so works out best. For a full blown desktop though forget it. Having said all that though I have to admit I've never built a Gentoo.
I like building things from source because I may want to have as few things built as possible, and because certain options set by default may break a system. I also like compiling because it offers the user a chance to support anything from a Pentium 4 to an AMD K6 (or lower), along with MMX, MMX2, SSE, SSE2, and 3DNow!.
Another advantage in my eyes is that it is possible to get the newest features without a long time before passing into a stable environment intended for a server on my home PC. I use X11R7 and the CVS version of Gaim on Gentoo, for example. Even SourceMage, with its far fewer patches and the slightest older software options, has met my needs.
The last plus is that as long as the originally installed version from the CD (or otherwise) is new enough, it'll be able to be updated to the newest, as Gentoo, NetBSD, FreeBSD, and SourceMage show -- though NetBSD and FreeBSD have their system sources located outside of their Ports and Pkgsrc systems, respectively. This contrasts from when I was using Red Hat Linux 8; it fell out of support for a while, and the structure of the system was dated enough (compared to now) that upgrading was a hassle.
Unless they don't work, are incompatible, are unavailable, or are for some other reason unsuitable. Then you compile your own.
I don't know but I am pretty addicted to yum by now.
However, I don't consider performance to be a particularly big benefit. Once you've got gcc doing it's basic -O3 or whatever, anything else is marginal at best.
There are, however, two things I get out of it which are useful to me. These should not be ignored:
Of course, there are drawbacks:
I guess it's just a case of "know the tool you're using".
tfa mentions some of the reasons for compiling packages, but it's rather incomplete. in my case, in order of frequency:
imho it's not always an optional decision if rolling your own would be better, in some cases you don't have a choice. but i do not want to have gcc (/similar) installed on production systems.
An unforgivable mistake in the sphere of commercial software is to test a DEBUG build and release an OPTIMIZED build. The binary you are releasing is different from the one you tested -- in effect, you are releasing untested code! This is one of the problems with a debugging scheme centered around conditional compilation. The very presence of the debugging code can affect the behavior and appearance of the bug.
Look, when I download a piece of software, I want to click "install", and start using it. I don't want to have to finish writing it before it will be useable on my computer.
/must/ be compiled to run, I shouldn't know anything about it happening - the compiler and the act of compilation should happen transparently to me.
/that/ running before I can get to compiling the program I really want to run, I won't be interested.
I don't know what the state of the art is for compiling code these days, but I know that when I download a program to use on my computer, I don't want to make a Computer Science project out of actually getting it to RUN on my computer. So if it
If I have to go out and download a compiler and who knows what else and get all of
Steve
A work that expires before its copyright never enters the public domain and thus enjoys eternal copyright protection.
Well for the desktop i really do not care, just apt-get all the crap, and it is a slow machine running X, mozilla and terminals. No reason to compile.
Now on the serversm when there is an advantage to be taken, I would compile apps, but not everything. Like mysql and apache (that accounts for 90% for processor time) I would compile if there is heavy load, but for others i really do not care.
Now BSD is a different devil, there you must compile it when using ports, so I guess that is the way to go.
I got less than double the performance with that same test, so it sounds like you are full of it. And of course, simply using -O2 and -mcpu=i686 which is the defaults in most binary distros gives you almost identical performance to -O3 -march=pentium4, without the broken binaries that randomly segfault.
And last but not least, if you think you can handle 3 times more SSL connections because openssl speed is faster, then you are nuts. Openssl speed is notoriously broken, giving wildly varying results. And even if actual ssl speed were 3 times better, there are still lots of delays in the course of an ssl http request that will take away alot of that 3x performance gain.
...is that you get the benefit of the optimization that can only occur when compiling for a specific machine without actually needing to do the work yourself.
.NET and Java the IL/byte code is JIT'ed before execution and can have these machine-specific optimizations inserted.
:)
In platforms like
No need to break out gcc or try and resolve dependencies. Ahh... I loved the managed world.
precompiled binaries? isn't that what windows users use because they don't have a compiler?
(this is offended to the end of comments you post, 120 chars)
I have a small, older (450 PII 256M, 10G) computer that my grandparents gave to me since they figured I could do something with it. I run gentoo on it for a few reasons (and yes, the initial install sucked, A LOT) but, it all fits very well on a small HD. I just recently installed CentOS for a friend to do some testing with on my system, I didn't even install all the software I have on my 450 and it took about 9G for the install. As cool as that is, for my older system, which I definately don't want to invest any money in, I'm not sure I could get everything I want on it with a 10G HD. I mainly use it as a development machine with LAMP, INTEL FORTRAN, and a few other odds and ends (yes, X is installed with KDE) and it fits well in about 6G of space because it doesn't have all the random things I don't use (see CUPS) My point in that while binary distrobutions are very nice to get a system up and running, they don't always fit the mold of what you need/want. There are too many other factors.
I don't have time to make a sig
By the way, the hands on approach is possible in other ways. I use Slackware and sometimes fuck with stuff too, but I get to be more intrepid than you because I've got less to lose, because when my system stops booting, it's back to normal after about an hour and a half of reinstallation.
Sorry, I couldn't resist it:
"in Soviet Russia, Binaries pre-compile you!"
(don't know what that means, though)
Alex.
One true religion post. Yes, I understand that getting people riled up gets more adviews and generates more revenue, but I still wish Slashdot would have grown up and moved on from these kinds of topics.
On topic:
I think it's obvious that circumstances dictate the answer, like:
Do you have the time to keep the binary up-to-date yourself?
What's your goal here- Performance, custom feature sets, or just using the product?
Stay true to your roots and just hope your intelligence gets above a 10. Home-rolled binaries give that extra kick. Please make it a little harder!
From a maintenance standpoint, vanilla is better.
From an optimization/customization standpoint, rolling your own is better.
So, for the items that should be vanilla from company to company (DHCP / DNS / File serving / etc), I recommend using as vanilla a system as possible.
In theory, there should be something that differentiates your company from all of the others. If this is an app or database or other computer related item, then it should be fully customized and fully documented. You want to squeeze every last ounce of power and functionality out of this.
This way, the infrastructure will take up very little of your time so you can focus on the items that make the money for your company.
In my long Linux usage time I used serval distros. One of them was Gentoo and at that time I thought compiling all from source is the answer to all the RPM dependency hell questions.
Well, sorry, no, never. Compiling all makes absolutly NO sense at all, except for some special packages, where you have to do a special setup.
You waste so much time with compiling (eg in Gentoo) and at the end you have more troubles with libraries, etc. I run Debian/testing on my workstation and on most of my servers and I only had _one_ issue and that was when I upgraded mysql from 4 to 5 and I had to convert some tables by hand. And I would have had the same issue with compile from source.
So the only time I compile something is, when I need very special settings in a software. For example apache with php. Mostly I need some special things in PHP that might not be in the default binary package.
And thats it. Compiling from source (especially in Linux where you have awesome binary distributions) is a PURE waste of time. I used Gentoo for one year and now I have Debian for more than a year and Debian one in everything, hands down.
"Freiheit ist immer auch die Freiheit des Andersdenkenden" - Rosa Luxemburg, 1871 - 1919
Specifically, if the default configuration is all you need, then go with the default. It'll make maintenance a lot easier and won't take up time doing customization that will never be utilized.
If you need something fairly standard - or at least uniformly weird - and an installer is available, then Gentoo is an excellent halfway house. Because package interactions can be seriously complex, Gentoo cannot possibly deal with all situations well. It's only really viable if manual intervention to customize the specifics is fairly minimal.
Finally, if you need something non-standard - a platform Linux will run on but no distribution exists for it, or you're doing high-end work and the exact package configurations necessary are outside of the norm, or if you HAVE to use a non-standard compiler (Pathscale, Intel, Green Hills, whatever) - then you definitely want to roll your own. You have no choice. None. Zero. Zilch. It doesn't matter what anybody says about difficulty, you'll just have to live with it.
Well, almost. If you've a cluster, you only have to live with it once. You then use BitTorrent or a mirroring tool to duplicate your master image across the cluster. If you're using hardware RAID set to mirror between drives, simply pull out one drive and plug it into another machine and let the RAID controller copy the disk for you. You could even have your master machine run as a repository for APT or YUM, install a bootable core system on the other machines, and let the repository upgrade the other machines.
(ROCKS uses BitTorrent to install itself over a cluster, which is neat and demonstrates how clusters need not be a problem for sysadmins.)
There are so many variables and so many ways of fine-tuning each answer that the ONLY sensible answer is "it depends". Anything beyond that pre-supposes far too much.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
In desperation, because the developer was an idiot, I took a look at the code. By adding one word: making a variable representing the UID static, the app went from O(n!) to O(n). Of course, this was a college, so I didn't get a bonus. But the point is that simple optimizations often yield HUGE results. I'm tempted to say that complex optimizations are rarely as effective as simple ones.
"He who would learn astronomy, and other recondite arts, let him go elsewhere. " -- John Calvin, commenting on Genesis 1
Quo usque tandem abutere, Nimbus, patientia nostra?
I found that using Os with gcc results in binaries that perform faster on my servers than O2. This doesn't happen 100% of the time, but it happens enough to make it worthwhile for me to recompile daemons like Apache2 and its modules using Os.
I suspect that with smaller binaries, there is reduced disk I/O, reduced page faults, and reduced RAM usage which is more worthwhile than the extra optimizations in O2.
I've used both Debian and Gentoo. I am now (mostly) using Gentoo and not Debian. I hope you might find my perspective helpful. (But it should also be stated I also use ports on FreeBSD, and I have come to the conclusion that source-based distros are easier for me to use.)
How I'd love to have so much dead CPU time! If your computer's not doing anything for you, why bother having one? Truth be told, one can reap performance gains in more definitive ways than trying to have your compiler make different binaries. As you indicated, running few processes helps. As can swapping in a custom kernel and/or using a faster filesystem (both of which you can do on Deb fairly easily).
I don't usually see a huge advantage, but it does depend on the app. For desktop users, app launchtime is often significant. I do think using '-Os' to make smaller binaries (which get into memory faster) does usually create a noticeable benefit. And for workstation/server apps, every few percent for "faster" apps could be helpful to some people (but I agree that it is typically only a few percent). But just leaving apps open is often "good enough" for load time & perhaps there aren't many who really need the extra few percent.
Yes. Absolutely. Particularly when you have relatively common needs across all apps. Perhaps you want to run an X-less server? Or perhaps you want to have apps with only KDE/QT or only Gnome/GTK+ or what not. USE comes to the rescue.
You are typically correct. But the thing is that foo more often than not will have optional support for some feature. But some gentoo ebuilds do, indeed, have USE flags that aren't just ./configure flags for some applications. For example, you can install xpdf with the 'nodrm' use flag, which applies a patch to cause xpdf to ignore drm restrictions. Indeed, for making custom ebuilds, USE flags prove to be quite useful: you can use them to test multiple patches without the need to apply a given patch to all installations & can easily check which features a certain app has (by checking which flags it was emerged with).
Gentoo's approach gives the user more choice. It preserves your old files by default. You can choose to replace the old config with a newer config or, more useful, merge (typically using sdiff) in changes between the old and new config. It doesn't choose what is best for you.
Debian's defaults are normally sane. But not always.
Machines are so fast today, that for personal use I don't see any difference between custom compiled code optimized for my cpu and precompiled. Bear in mind that most precompiled binaries are already available for the major cpu's (P4, AMD, AMD64, etc).
When I started using Linux I started with an old Slackware, some time later I started to compile everything myself and test different gcc options, and even patched some programs to use a devfs only system. About two years ago I decided that I have nor the time neither the will to keep doing it, I switched to debian unstable, as I was used to be always on the edge. Now I run debian stable in every machine, the server, the desktop and the notebook. I have compiled, adjusting by hand every option, some packages like wine and mencoder, but just because I use both to heavy filter and encode The Simpsons from DVB-T everyday and it take about 10 hours to complete the job, so every little percent is important. Everything else doesn't need such hard tuning.
Just compile speed-critical programs yourself and get everything else from a stable distribution.
I [may] disapprove of what you say, but I will defend to the death your right to say it.
Really lame. I'd pen a post lamenting what Slashdot has come to these days, but that would only serve to convey an expectation of something greater, which, frankly, is just sad...
:|
So SM posts this for shits and giggles. Fair enough. It brings the Gentoo Ricer crowd out, which is entertaining for the rest of us and generates page views ergo ad revenue. I can almost see a four steps to profit cliché here, but I'll leave that to someone else.
Seriously though, what a load of bollocks. I certainly can't claim to have the vintage of some of the 20+ years sysadmins on here, but I've been a Linux user for 7-8 years now and that is evidently long enough to come to understand the merits of package management. Yes, when you're fat and fifteen and still living in your parent['s|s'] basement with nothing better to do all day than stick it out watching makefile lines scroll by, Gentoo seems like a good idea. If you're really fucking sad, you might even notice a perceptible difference.
But fuck, please stop trolling like a bunch of Mac/Ogg/etc zealots telling the rest of us about it - we don't fucking care. We have jobs to do, partners to go home to, lives to get on with. If I did still care for Linux on my main machine, Ubuntu would have me up and running in an hour or so - I couldn't have my computer out of action for a day because it's...er...compiling.
Now don't get me wrong - I understand the mentality. I know the mentality. It's the same mentality that led me to reinstall Windows anything as frequently as once a week for a period in an attempt to get it running tip top. It's about the struggle, the fun of getting there, the war, the conflict, the strife - that's the fun part. I am of a computing generation that cut its teeth editing CONFIG.SYS and AUTOEXEC.BAT files with elaborate startup menu configurations to optimise memory availability for specific applications (remember expanded memory, anyone?).* And it was great - we loved it, well, some of us did - until we actually had to get some work done.
Now I have to get work done, so I use a Mac. And countless Linux sysadmins out there will say the same thing - in the real world, you have to deliver results. Real, actual results. Dependability. Not downing the server every evening for a recompile. Reliability. Actual rather than theoretical uptime. We simply don't have time to be sitting round waiting for X to build so we can just sling some graphics on the screen.
And if y'all were doing something useful with your lives, neither would you...
iqu
(* Kudos to John Gruber for reminding me (through quoting someone else) of the glory days of MS-DOS - choice quote: "As a PC user, enduring the grotesqueries of that experience is something that we are actually proud of.")
You can install source dpkgs and binary ebuilds too. (I also use FreeBSD, but think that portage has smoothed out installation from source & that dpkg is fine for installation from binaries.)
On whether I have the 45 spare minutes required to compile my OS and applications from scratch ?
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
I like the middle ground of having a range of pre-built binaries that are optimised for common machine types, allowing the user to install the one most appropriate. This allows benefits in performance, as well as reducing the permutations of the software that need supporting.
m oox.ws/tech/mozilla.
The Moox builds (http://www.moox.ws/ of Firefox did exactly this, and gave a noticable performance increase over the 'regular' mozilla.com pre-built binaries for Win32. Before the site went down, there were also benchmarks of his builds showing the performance increase - the PDF is still in the Wayback machine linked from the following page: http://web.archive.org/web/20050216043112/http://
-- Mike
I don't care only about some 10%. Compiling from source, means that you learn to know which packages are sometimes a pain in th *ss to compile. There are a lot of practices where all the benefits of rolling your own binaries is total a waist of precious time. But in some conditions people want to use open source code, want to compile them and hate to be dependant on some company or organisation which does all the compilation for you. Ofcourse you can always compile the stuff you want, but for the sake of clarity and control it can be a good thing to have some source packaging system like BSD ports or portage (gentoo). For Developpers this is a great thing. trying to get your granny to learn OpenBSD will definately earn you geekpoints, but if she is not a developer she wouldn't probably need it. Other people want to investigate what stuff is new in general and they want to do it in some managed way. The source based gentoo was the first linux to boot on macintel hardware. Having knowledge of your system (including code) and gives maximum control to hack. For the linux distributing organisations it can be less trouble to distribute source, it relieves you of the wait of time to compile every piece of source to some specific platform and use the valuable time to to more important things, bug fixes or porting. Source is especially useful when there is only source available and no binary. If you are a security expert and you have written some revolutionary malloc (fuzzy stuff to prevent happy heap hacking) you can easily try to spot the new bugs. Research and knowledge sharing is a valid reason to compile from source. Source code is also great for amateurs who want to learn about all about *nuxes and accompanied freedoms in theory and also in practice. And there are lot of other uses to which compiling is a great thing to do. But if you only like things out of the box, you're completely waisting your time, then go binary. It's nice to know there is some open source to see and have the proof of compiling it, if no one would care about compiling from source we all would not care about binaries also and everyone would be using probably Windows. "Use the source Luke"
I wondered this when I heard about Gentoo.
Let's see, all cpus have a CPUID string, the memory is reported by the BIOS, and I would think the chipsets should be able to get worked out also. In other words, isn't all the hardware able to get probed during boot up and if so, then let the OS set the flags properly and take 1.5 hrs to install instead of 0.5 hours (if I so choose).
If I want other packages installed, just be sure to check a config file created by the OS during install and set the proper flags and go to town.
Gentoo is based on the user knowing the ins and outs of their system but isn't this something that can be automated? Why can't the OS figure out what the best flags are to set? Oh well, call me K-RAY-Z!
I've used gentoo a lot at home and debian a lot at work.
Debian really does demonstrate the problems inherent in letting someone else make decisions about what options and dependencies should exist for a piece of software.
To see what I mean, you have a freshly installed debian box you want to monitor with nagios.
So, you want to install the nagios nrpe server on this machine.
The Debian package for this is in two parts:
1. nagios-nrpe-plugin
This is the plugins that are actually used by an nrpe server. If you install this, the nagios monitoring server cannot connect to your freshly build server to monitor things under nrpe.
2. nagios-nrpe-server
This is the actual nrpe server component; the part that listens on the network for the nagios monitoring server to connect and to get it to run the various plugins.
Ok so on your freshly installed, lean mean serving machine (well as lean and mean as a default Debian install can be with the c compilers, ppp et.al.) do;
# apt-get install nagios-nrpe-plugin nagios-nrpe-server
and be prepared for a shock at what else it wants to bring in.
Its a database server? No webserver required?
TOUGH SHIT!
The Debian package maintainer *decided* that if you want the nagios nrpe server component you also MUST have the nagios server component itself, and this requires a webserver. And thats just one example.
With gentoo I get to set my USE flags according to what *I* want support for.
However I would never consider using gentoo in a production environment. Never. Thats after two years of using it at home.
In the free world the media isn't government run; the government is media run.
is the way to go.
...' to remkove the packages that I INSIST be compiled from scratch, which are usually Network/Server related.
I don't mean, compile the ENTIRE OS from source, that will take hours, if not days (or even weeks).
Slackware is a great distro. Debian is also very nice. Redhat, Suse, Fedora, and Ubuntu are just not for me.
I like slackware because you can install ALL of the applications that come with it, and then easily 'removepkg
Desktop applications I could careless about, I'll install a package for say, jedit, but not for Apache.
It's nice to be able to write your own shell scripts that perform all the required installation commands, and then easily replicate the hell out of a server farm with no hassle, but that can be done with any distro really.
the only permanence in existence, is the impermanence of existence.
Always use pre-compiled binaries. It's a no-brainer. Source code is only for modifing something that the developers forgot or refused to do. And it's only for professionals with a lot of time on their hands. It is never cost or time-efficient to do your own compiling.
Any good reason for having the users of a program compile their own binaries is a good reason not to consider using Linux at all for anything serious. Because if there is any good reason to compile binaries then it means that the program is not stable or finished or even well-planned. And these kind of programs are ones that you don't want to mess around with unless you're getting paid for it or have some unusual emotional attachment to the application.
It's just common sense.
Fine the subject doesn't make complete sense.. BUT... doesn't compiling code with Intel's cc result in significantly better binaries than any flag you can throw at gcc?? From http://www.intel.com/cd/ids/developer/asmo-na/eng/ 219902.htm, MySQL claims 20 percent performance improvement over gcc.
I'm not saying we all have access to icc, but if someone wants to make a binary available, I'm more liable to use that than compiling from source. Call me crazy. And I know someone will.
CommentBot 0.7a running with args "-module irritate,disagree -target random"
I thought bytecode was supposed to solve the problem? Specifically, with .Net, you can run a program that caches a compiled version of a .Net assembly. In theory, it could compile it to run optimally on your specific chip.
No, I will not work for your startup
(Full disclosure, I've been using Debian since 1996. I'm backporting packages to stable as I write this, so I'm definitely not coming from a "one size fits all" perspective.)
If there is one thing that appeals to me about Gentoo (as I understand it), it's the concept of meta-configuration at build time. Unfortunately, lots of options in packages get configured at BUILD TIME, so either the binary packages have those options on, or they don't. When this is the case, if the distro doesn't provide multiple binary packages with all of the useful configurations, then you end up having to build from source. (IMO, building from source means compiling from source packages whenever possible.)
So I like the concept of saying in one place, "build for KDE", "build with ssl support", "build with ldap support", etc. Maybe someday everything will be runtime configurable, but until that day, I'll be wishing for that meta-level of configuration...
Having said all of that, check out apt-source, apt-build, and their ilk if you're interested in "Debian from source". Debian binary packages solve about 97% of my problems so I'm not usually looking for "make world" kind of functionality.
Enough rambling for now.
I'm most partial to my Commie64 Linux distribution solely for the Commodore 64. I have to recompile just about every linux package known to man, only 1 out 1000 OSS projects actually work, and the hardware is rather limiting, but MAN am I COOL!
Horns are really just a broken halo.
Since I got my Intel mac, I always install source packages with Darwin Ports since almost no prebuilt packages are Intel native.
The thing wasn't so much that you were stunningly clever; it seems to be that the developer was so, so, so boneheaded. But the sorts of optimizations being talked about aren't about correcting insanely stupid errors so much as they're about making subtle, marginal changes. I doubt there's that much paper-bag optimization to be done in mysql, for instance...
Laws do not persuade just because they threaten. --Seneca
A vast number of regularly updated packages. Put simply, I can emerge almost anything, whereas every other distribution I've used, sooner or later I come across a package I need which doesn't have an RPM or what have you, and I have to build my own complete with the dependency hell that can entail.
More than that, almost half the time you can install an updated package not yet in Portage by renaming the most recent ebuild to match the new version number.
If that fails, you can invest a few hours and learn how to write your own ebuilds... It's insane how easy it really can be to get any bleating edge bit of software running.
What does this button d$#%* NO CARRIER
...when I realized that I could get a better speedup by working at minimum wage for every minute that would go to compilation, then using the money for faster computers. :P
TBH, none of those reasons are the deciding factors for why I use Gentoo over Debian.
Now before I continue and get flamed to death, I'll be the first to admint that Debian is one of the best distros out there. But it is only my second favorite.
I use gentoo simply because I like how it does the configurations. Its a bit hard for me to explain, but I find it consistent and logical. That may seem like a small/unimportant reason to choose a distro, but it is the deciding factor for me when I have to choose between debian and gentoo.
Now what I would really like to see (but won't happen) is have gentoo also be able to use debian packages. I love how packages install fast on debian, as well as the selection. But I love allot of things about gentoo. Ofc, I imagine this would lead an array of problems dealing with libs. Heck, I sometimes have problems porting my gentoo program to debian due to different lib names.
All in all, it comes down to the user and what they prefer. I value certain things that other people value differently. This is why there are so many distros to begin with. So plz stop saying one distro is waaay better then another, unless ofc, it truelly does suck (dead project, poorly implemented project, etc). Ya that sounds contradictory, but there are distros out there with next to no redeeming values except for that fact someone used it as a learning tool (which is a good thing).
Boss: Jack, I want this new webserver machine to be up and running as soon as possible
Jack, the Gentoo Admin: Yes, sure chief! It will take just a couple of days to compile everything...
What do you think is gonna happen next?
I really like Gentoo's portage package system, but I hate waiting for the thing to compile everything. While there are some binary items in portage, there's way way more source-only things.
In my experience, it is often necessary to recompile from source simply to have more than one version of the same package available at once! Too many pre-built binaries assume they are the only version in the universe you could want in /usr/local/bin.
/opt/pkgname/1.0), and at the same time they should assume their dependencies can also be found there. The /usr/local hierarchy would remain, but as a hierarchy of references to specific versions of things. The /usr/local hierarchy would contain selected default versions, it would be used for efficient runtime linking (have "ld" search one "lib", not 20 different packages), and it would be targeted for dependencies that truly don't care about the version that is used.
For some packages a recompile is merely annoying, having to download and reconfigure with a new prefix and rebuild; but for others, it can be a horrible web of configuration options to find numerous dependencies in special locations. This complexity can be really frustrating if all you want to do is relocate the tool so two different versions can be installed.
Pre-built binaries should assume by default that they'll go into a version-specific directory (say
There are other details, of course...for example, it may matter what compiler you use, you may want 32-bit and 64-bit, etc. But the basic principle is still simple: have a standard package version tree on all Unix-like systems so you can "just download" binaries without conflicts, once and for all.
"Microsoft killed my company, I hold a personal grudge. I don't use Microsoft products and neither should you."-JWZ
I build SysV Solaris packages all the time for my company. Places like Blastwave (for Sun Packages), or RPMs for LINUX Distro's always tend to throw dependences you don't want. I like controling the software install I make. I usually find it easier to build my own package, do a checkinstall, preinstall, postinstall, request, and depend script and tah-dah! Deployment package in the macking totally customized for the intended purpose. Which can be cookie cutted. Depending on your needs, you may not mind installing EVERY fscking RPM for a dependency, but I prefer controlling every aspect. Not ot mention building specific optmization for our Opteron / SPARC servers.
Precompiled binaries suite most situations. IMO, it's silly (and time consuming) to compile everything from source all the time. However, if you need a newer version of a program or some specific settings comiling from source is the way to go. Arch linux approaches this well. They offer optimized, often completely up-to-date, precompiled binaries in pacman, but allow you to build from source with the Arch Build System if neccissary.
Basic software production rule: first get it to work at all. Then optimize it.
--
make install -not war
How on Earth is this man's comment a troll? The moderator is way off-base.
This is my two cents, but I still use Fedora, but there are a number of high quality distributions out there that may be the best fit for you.
I know that Debian and others have very good methods to ensure that packages are signed, but for me, Redhat's rpm is one of the best ways to validate a package. The signature is included with the package, and assuming I have a valid public key from the maker of the package, I can obtain rpm packages from any source, and with a rpm --checksig, check for tampering before the packages are installed. Of course, packages have a MD5 hash, which easily determines if the package was accidently corrupted.
With RedHat, Fedora, and other rpm based distributions, I can check if files have been tampered with with a single command. Its not as thorough as Tripwire, but its another way to check integrity of a system's files and permissions as originally installed. Its not perfect, as you will get lots of false positives (especially if lock down all but vital SUID files and use wrappers), but its a good guide. Checking files agains rpm's database is not secure against a hacker or program that edits the rpm database, but it provides some help should I suspect binary corruption.
Of course, I'm forgoing the fine-tuning of binaries that one gains with Gentoo or a source-based distribution, but for what I use Linux for, Fedora is fine.
After you get the "238 files in /etc need updating" thing, issue "etc-update". It will lead to a menu-based program where you can view the diff between the old and new files and choose either to use the old, use the new or merge manually.
/etc somewhere it might throw you in $EDITOR to edit that file out of mild ignorance. Perhaps a check must be done on file types. I've never run into this myself; must not have any binaries in my /etc tree.
I suppose if you had a binary in
From the other perspective, if Microsoft has for years gotten away with providing the same binaries to all users and its popularity has not decreased because of it, I cannot see why precompiled binaries on any platform would make a difference to the end-user. Yes, they do make a difference to the developer, administrator, etc. but if it makes a difference for one developer and no difference to 100 end-users, why not just keep it precompiled. I know ... speed, feature bloat, security, etc. but from the end-user perspective it means jack-sh**.
.. packages compile YOU!
So I was curious about the author...
http://www.edtittel.com/etbio.htm
This is the shorter version...
Ed started out with an academic career in Anthropology. He then realized that digging up old bones had no future, so he got into computers in 1981.
Since then, Ed has been utilizing his anthropology experience in the computer field, by digging up old computing techniques and trying to do things the hard way, just like back when he started in 1981. That's why he advocates for you to compile your own version of every package rather than just accepting the defaults, like we did in the old days. Ed also advocates recompiling because it allows you to pick options, being completely unaware of new modern technologies such as dynamic link libraries(otherwise known as DLLs) which incorporate optional components at runtime instead of needing to be linked in at compile time.
Ed spends an awful lot of time writing books and articles instead of having to get real work done like most of us in the business, which is why he's so concerned with a stupid question like compiling packages from scratch.
In short... this is by far the stupidest article I've read this month on slashdot, and Zonk posts a lot of really dumb articles so that's really hitting the bottom of the barrel.
As an Ubuntu user, I've found apt-get gives me pretty much all I need, and it's in deb form. If I do compile from source, I'll use sudo checkinstall rather than sudo make install, as then I get a deb at the end that I can remove just as easily as I installed it.
Not only had I built every package from source (using ports), I also took the trouble to rebuild the base system and kernel with a custom configuration and options.
The benefits to some of this were obvious; the FreeBSD GENERIC kernel at the time seemed (to my eyes) to suffer a massive performance loss from its configuration. Anyone running FreeBSD *must* build at least a custom kernel, even if they use the binary distribution of everything else.
It was a lot of effort. What did I get out of it? It was by the end one of the speediest systems I had ever used since the days of DOS. Most programs loaded faster than their binary equivalents (on older machines the differences were more glaringly obvious, such as the time it took to initialize X).
One time I clocked my old machine, running a custom built FreeBSD installation, against the other computers in the house from power-on to a full desktop (after login).
On my machine, the entire affair (BIOS, bootloader, bootstrapping, system loading, X, login, desktop environment (WindowMaker in this case)) cost a mere 45 seconds. My father's machine, which was in all respects a faster computer, loaded Windows 2000 in the course of perhaps two minutes. Also, I stopped timing after the desktop came up, but Windows does continue to load and fidget about for a good while after that. The extra time taken for it to settle down would have cost it another minute, but only because of all the crap my dad had set to load, which I don't blame Windows for.
The kitchen computer also ran Windows 2000, but had a slimmer configuration, so it loaded shortly over a minute. FreeBSD, however, still beat them both badly.
In light of my own experience, compiling from source can get you some rather wonderful results. However, I noticed that not all systems were created equal. While FreeBSD GENERIC was as slow as molasses, I find in linux that the binary kernels that come with my distributions seem to load and operate just as fast, if not faster than my custom build of FreeBSD. In linux I have used only binary packages, and the system overall "feels" just as fast, though some operations are a little slower (like loading emacs ;)).
I appreciate the arguments presented by both camps, but I feel the need to point out that some are too quick to downplay the possible performance gains offered by custom builds, because they certainly exist. Sometimes they can be noticeably significant.
Why should self-compilation give you ANY performance at all? Compilation is nothing but the automated translation of source code into binary machine code (put simply).
Now assuming that most people use the same recent version of a given software, and the same recent version of a compiler (like GCC), and a few reasonable optimization flags, why should the resulting compiled binary differ AT ALL across different systems? What difference is there between compiling yourself, or having someone else compile it FOR THE SAME SYSTEM (say, Debian, NetBSD, or Gentoo), and having you install a binary BIT-FOR-BIT copy of that binary?
Sorry, but are you guys on drugs?
Vrooom vroooooom! CFLAGS just kicked in, yo!
If you are a small/medium company:
If you are a domestic lazy bastard like I am:
If you are a purist unlike me:
I hadn't the slightest objection to his spending his time planning massacres for the bourgeoisie... (P.G. Wodehouse)
Once upon a time I used to compile my own binaries; now days I have better things to do with my time.
The only time I compile my own binaries now is when the standard binary package doesn't have a feature enabled that I want, the most common example of that is Exim. In those cases it's just a case of doing an apt-get source, modifying the appropiate files and then doing dpkg-buildpackage. Voila, nice binary packages built the way I want them.
Yeah, I had a sig once; I got bored of it.
First of all, -O2 or -O3 might not be the best choice - for each given piece of code, there is almost always some arcane combination of switches that produces faster (10 per cent or more) executables than -O2 or -O3. There is an open-source tool (acovea) to find the best combination of switches for a given program. See the benchmarks posted there.
Second, if you compile yourself, you can use icc (the Intel compiler), which usually (but not always) produces faster executables than gcc (see the benchmarks).
"Rolling your own"? Good God people. Don't get me wrong, I like Linux as much as the next non-conformist tech guy, but must we have this euphemism? I swear, if the penguin gets replaced with a cartoon Che Guevara, I'm quitting the internet.
is lab machines.
Hint: the vast majority of companies do not have any labs. So you might ask yourself, pinky, "is my experience in any way representative of the vast majority of corporate computer usage?"
I've worked in research (corporate, defense, & academia) as well as in industrial production, financial services, and medical records. Any place with labs is completely different from the corporate mainstream. So I think the answer would be No.
Compilation for the source is sometimes a bad idea if certification concerns are an issue for your business.
/usr/local/bin, /usr/local/sbin, and /usr/local/lib for software and libraries you have compiled. Don't install software that loads kernel modules, unless you can be sure it is a certified binary. Ensure that you can install proprietary binaries under /opt.
In the enterprise environment, IT departments can typically have service contracts with software vendors and support consultants. These contracts typically require an "un-tainted" kernel at a minimum, defined as the vendor packaged binary distribution.
For our Oracle support contract, we must have a specific formula of one binary distro OS (untainted kernel and libraries) to match a specific Oracle DB binary, etc. As soon as the support company (oracle) finds evidence that you "rolled your own", you just threw your support contract funds out the window.
On the other hand, binary distribution of software is not always safe either. For instance, with RedHat support contracts, if you load a kernel module that isn't certified by RedHat for your binary kernel (for instance to support a filesystem that Redhat doesn't support by default, or a proprietary hardware driver), your kernel is flagged as "tainted" and your contract on that machine is void until you can standardize back to certified binaries.
At least in this scenario, an administrator should practice care when deciding to compile any binary. If you want to be on the safe side, follow common Unix conventions of installing under
Never install a recompiled binary overtop of a file that in registered with a package management database if you intend to use the package management system in the future. It will cause a lot of needless headache when bugs start happening.
Cheers!
w2^7me out.
Its called an "experiment". This is the idea:
Troll 1 says: "My computer runs so much faster with compiled binaries!"
Troll 2 says: "Balderdash! Precompiled binaries are just as good!"
Mr. Scientist says: "This sounds like a testable hypothesis! Let's get two identical computers and compare the speed of different programs! We'll get a guy with a stopwatch to measure how fast it takes to do simple tasks, like booting up. Troll 1 and Troll 2 -- you guys can't be the guy with the stopwatch; in fact, I think you guys should stay 10 miles away from the lab."
Troll 1: "But I just know that Mozilla boots 10 seconds faster if I've compiled it..."
Scientist: "SILENCE! Anecdotes are not data. Especially when they come from a biased jerk like yourself."
Troll 2: "See, these crazy gentoo guys... [mwrfff!]"
Scientist: "[Stuffing sock in Troll 2's mouth] The SOB may be right, but you'll look at the data that proves him correct and never accept it."
[Scientist lets out a deep sigh.]
Scientist: "Ok. The computers will be exactly IDENTICAL except for the different versions of the program. We will have stopwatch guy measure the speeds of each program at least 10, probably more than 40 times. Stopwatch guy will be a grad student who is more interested in girls than Linux -- wait, we will make sure that he has no idea what Linux is. We won't tell him which computer is running which version, just in case. We'll just pay him $10 an hour to do these boring ass tests."
Troll 1: "But what about the USE flags that we compile the binary with?"
Scientist: "We will do a trial for each possible USE flag. We will toggle every single variable and compare it to a control. The grad student will spend a lot of time doing this sort of thing, (but grad students are made for slave labor...)"
Troll 1: "I'm sorry, what were you talking about? We were busy writing more posts to this slashdot thread thoroughly trashing each other."
Troll 2: "Yeah, I'm pointing out to this jerk that I've been a sysadmin for my basement Beowulf cluster of NetBSD equipped toasters for over a decade, and my extensive experience says that it takes forever to compile anything on a Toaster, so the net time I would lose through compiling would outweigh any runtime advantages until I've toasted 4 gigaloafs... only at that point would I begin to save time."
Troll 1: "And I'm pointing out how I installed Gentoo on the aerofoil of my car and the friction on my wheels is up over 0.1%, effectively overclocking my car's engine by over 5 horsepower -- never mind that my 57 horsepower engine never gets up to speeds large enough to experience any significant gain..."
Troll 2: "You installed Gentoo on your car? How do you compile using a car? Do you lift it off the ground and spin your wheels in the air for three weekends..."
Troll 1: "You're so old. I've even managed to compile Gentoo on my girlfriend..."
Troll 2: "No doubt a RealDoll equipped with the vibration pack from a Nintendo 64-"
Troll 1: "-I wrote my own vibrate driver and installed it in the RealDol-"
Troll 2: "-Man, that is nothing compared to the driver I wrote that toasts a devil shape into the toast-"
Scientist: "-excuse me-"
Troll 1: "-when I'm overclocking my girlfriend sometimes I have to cool her off with liquid nitrogen-"
Scientist: "-sweet lord! I can't take this crap anymore! It's like watching a debate between Flat Earthers and Intelligent Designers! I only did this to get my own IgNobel, but it just isn't worth it anymore. Get the hell out of my office, and stop using my wireless, you pathetic losers!."
That gentoo admin isn't very good, then.
He should have prepared a stage3 tarball from a similar server. In a redundant environment, this should be easy, since he'd just dupe it all from the existing box. Heck, if the systems have identical hardware, then you'd just clone the entire install, change the hostname, and walk away. At worst, that's a couple of hours, though if you've got a small base install, a fast disk array, and GigE (hell, pick two of the three,) you can wrap it up in half that time.
Even if this isn't an option, why isn't he bootstrapping with distcc, using Catalyst, or otherwise distributing/pre-building for the setup?
At any rate, a halfway decent workstation can go from stage1 to GUI with OO.org and all the crap in between in about 24 hours, if you know what you're doing, and that's with one CPU. Sure, that's a long wait, but that's what a home user might expect. For production use, it should never take that long. The hardware is simply far too unlikely to be that slow.
Raptor
"Procrastination is great. It gives me a lot more time to do things that I'm never going to do."
In a lot of ways I've found FreeBSD a lot like coming home. My first introduction to *nix was a Tandy 6000 running Xenix, which had at least something of a BSD heritage. I've really come to appreciate it. I know it's not as *cutting edge* as Linux, but at the same time I really am very impressed with its packaging system.
The world's burning. Moped Jesus spotted on I50. Details at 11.
Ah, but you're assuming an Ignorant Zealot type of Gentoo Admin. I've deployed Gentoo production before, and your hypothetical would have run one of two ways:
Boss: Proteus, I want this new webserver machine up and running ASAP.
Proteus: Ok, Boss, let me just boot from this deployment CD and clone the standard Gentoo set. I should have us ready to go in a couple of hours.
OR
Boss: Proteus, I want this new webserver machine up and running ASAP.
Proteus: Ok, Boss, I'll build it with a stage-3 Gentoo and use only binary ebuilds; it'll be up in a couple of hours, and I'll schedule the rebuild-from-source during maintenance windows.
Obviously, I preferred the former, but the latter worked fine.
All things considered, though, I much prefer Debian for corporate production installs.
We may not imagine how our lives could be more frustrating and complex—but Congress can. – Cullen Hightower
What about disk space? The disk space taken up by a build tree can be a lot.
In any case, extra disk space, RAM, and CPU power are almost always cheaper than having your staff spend time on set-up and maintenance.
http://outcampaign.org/