Slashdot Mirror
Gentoo On Server Considered Harmful
Siker writes in to point out his blog post — Why Gentoo Shouldn't Be On Your Server — which seems to have stirred up a lot of discussion, including a thread on the Gentoo forums. From the post: "I firmly believe in updating server software only when you need to. If you don't need new features, and things are working, why change anything? If you update anything you will undoubtedly need to update configuration files. You will need to fix things that break in the upgrade process... This is hard with Gentoo. Gentoo wants you to change a lot of stuff. It wants to be bleeding edge."
At the same time, the "your system is always approaching the bleeding edge" way of doing things solves one problem that I've always been bothered by with running user servers for suso.org. Eventually, the OS on the server reaches the age where it is no longer supported and updates are no longer coming out for it. This isn't always X years where X is the number of years that a distribution claims to provide package updates for. Its usually X-1. This is because you'd be foolish to use the very latest hasn't been available for more than a day version of Linux. Usually you wait for 6-12 months for it to be mature and have special packages of whatever available for it. Then you spend another month or two setting up the machine and getting it ready for production. By that time, you've already burned over a year of support time. Then you get users onto it and now you only have X-1.5 years of support. On Fedora, this means practically no time is left. Upgrading such a system to the latest version of whatever distro means taking the server down for several hours to upgrade, hope to hell that special packages you've built and configurations aren't broken and in nightmare situations, roll back because something is broken and can't be fixed.
The promise of Gentoo for me is being able to continually upgrade and never get outside of that window of support.
I actually have a new shared user system that is running Gentoo that is kinda in beta right now. This article was very useful for me because it brings up those points about stability that concern me. Its kinda an experiment.
I think I may try Debian next.
Gentoo allows you to be on the cutting edge, just like all the other distributions. The primary difference is it makes it very easy for those who don't know what they are doing to be there. Most folks running SuSE, RH, or one of the other 'package' based distributions won't build their own RPM, etc. There is nothing stopping one of the 'normal' distributions from upgrading the kernel with each release. I certainly don't update everything on my Gentoo box because it is there, on my server.
I run Gentoo on a server. The server is stripped down beyond what a typical 'router' distro looks like - one of the reasons I went with Gentoo is I could really trim the system down for the job at hand. My server only gets updates for security, and once in a while a bug fix that impacts the applications running on the server. Not often. When I need to compile something big, the last place I'd do it on is the server itself - it has another task. I take one of my workstations with far more GCC horsepower and let distccd do the work for the poor little pizza box. Beyond the initial build, I doubt those boxes have ever compiled anything.
Since it is a source-based distro, I also am not trapped by RPM's or other packages no longer getting provided for my system. One of the applications I had was using RH9 (with paid support) only to have them drop maintenance on it and have the vender drag their feet moving to another platform (clue stick, they had issues with the 2.6 kernel, so would not 'support' any platform but RH 8 and later 9. The enterprise editions? Forget about it... You want to live in the suck, you try keeping one of those boxes alive and secure years after it EOL.
+++ UGUCAUCGUAUUUCU
"I firmly believe in updating server software only when you need to. If you don't need new features, and things are working, why change anything?"
I agree... so why does this preclude using Gentoo?
Just because you _can_ update all the time doesn't mean you should. I've used gentoo for various purposes (server, desktop, laptop). What I usually do is get it setup and install all the packages I need and then leave it for a _long_ time... only upgrading packages that I either need the new capability of or for security purposes.
Look... I personally don't think Gentoo is the best server OS out there... but I also don't think that just because the package system makes it really easy to tinker with the system that Gentoo is inherently unstable...
Friedmud
There is no 'stable' version of Gentoo. Gentoo is rather a moving target where emerge will forever cause your system to approach the cutting edge.
/etc/portage, you can have a stable system, but have one or more packages be unstable without having it a system-wide setting.
Yea. Not quite. This is what the "ACCEPT_KEYWORDS=" setting in make.conf is for. If you don't have it set, you get "stable" packages. If you do have it set, you get the unstable stuff.
Further, with the use of the files in
Haven't read the rest yet, but wanted to point that out.
bork bork bork!
I certainly wouldn't want a Gentoo on my servers. Sure, it wouldn't weigh much, but think of the poop you'd have to clean up!
Be relentless!
* MySQL DATADIR is /var/lib/mysql
* Previous datadir found, it's YOUR job to change
* ownership and have care of it
* Sorry, plain up/downgrade between different version of MySQL is (still)
* un-supported.
I vowed never to use Gentoo again, and promptly moved that machine to Debian. I use to run Gentoo on all my desktop machines in the pre-ubuntu days, because it had the most bleeding edge desktop packages and optimizations. After Ubuntu came on the seen, Gentoo had no advantage for me. Its still a great learning too though. I highly recommend for aspiring Linux geeks.
I have been a server admin for web/database for about 3 years now. I agree that bleeding edge is *not* where server admins want to be. There's a reason that Debian is widely considered the best server OS despite being rather far behind the bleeding edge. Tried and tested is better than the latest and greatest when you rely on the machine being up. It's also worth noting that the military doesn't use any COTS technology within 5 years of it being released.
I hate printers.
Gentoo is only good for ricers, Gentoo is bleeding edge and unstable, Gentoo is only good for X deployment
The truth about Gentoo is that it is not really a distribution. Gentoo Linux does not make "releases" and it does not aim to cover one area of the market alone.
In Gentoo's packaging system, called portage, the aim is not only to provide up-to-the-minute packages (which it does) but also to provide a wide variety of both tested and verified "stable" packages as well as more bleeding-edge, testing packages.
This, along with a properly configured make.conf and /etc/portage file system, allows you to pull down the packages you want that have been verified as stable (and are also under watch by the Gentoo security project) and keep track of their libraries with revdep-rebuild.
Stop branding Gentoo with stereotypes that label it as X distribution, the project even calls itself a "metadistribution" capable of dropping into multiple roles.
mattdev@server$ touch
cannot touch `/dev/genitals': Permission denied
Don't fix it if it ain't broke: up 292 days, 22:26 The reason for the short uptime, is PSU upgrades...
Excuse me, but please get off my Pennisetum Clandestinum, eh!
First of all, I find it interesting that FreeBSD never seems to get these complaints and hate about having to recompile packages with portupgrade all the time, and being able to tweak the flags, etc. In this respect, it's just like gentoo!!! Except without a lot of the fancy features like etc-update and slots and masking and multiple supported versions. Yes, the "base system" is more stable on FreeBSD (which is both a blessing and curse), but what is it about Gentoo that attracts so many haters/inexperienced admins, hmm??
Anyway, I run Gentoo on servers. (Also FreeBSD). I think it's great. I can't stand stuff like Red Hat, which makes it difficult to customize anything, so I'd always resort to installing stuff "by hand", which was a huge pain. Or creating a custom RPM, which was an even bigger pain (RPM is basically a huge clusterfuck in general).
Being able to set up ebuild "overlays" is great. Being able to set up custom profiles that contain all the software needed for a particular app is great. Writing ebuilds is a piece of cake. Turning on/off various features system-wide is very helpful. The mechanism for merging configs (etc-update or dispatch-conf) is nice. Being able to pin down specific versions with masking is good. Etc. For the record, I've never tweaked the CFLAGS in my life.. that's just not why I use Gentoo.
The author writes this:
I have no idea what happened to him. Updating your profile is basically moving a symlink, which changes some lists of base packages and other high-level build configuration. It doesn't "touch" anything in your system. Sure, you have to some upgrades afterwards, but you have to do that regularly anyway on Gentoo. Compare it to upgrading FreeBSD from 5.x to 6.x, which is much more involved.
I've been using glsa-check for a while now, it works great. It tells me what's got known holes and I just update those packages, and their dependencies. What problem did he have with it, besides the "experimental" status? Yeah it can "do stuff", but I don't use those options, I just use it to get a list of packages with known holes. Heck I could probably write a script to do the very same thing.
Suppose you need to patch one of your installed packages by the way.. it's very easy to create custom ebuilds on Gentoo. Sometimes I plug security holes that I've found on my own for instance.
I have a simple strategy with Gentoo servers: keep an identical test/staging server nearby and do your updates on that machine first. Run your application tests and then upgrade the production machine. If you want, build binary packages on the staging machine. I would do this even with Red Hat, Debian, etc.
Another point: I've NEVER run "emerge -u world". I always do the packages in small groups or chunks and then updated configs, restarted daemons, and run tests after each one. This seems like a much better strategy than what some people do.
Also, I gotta say, it's probably not a good idea to run Gentoo on a production server unless you've got at least 5 years of Linux admin under your built. You also need to FOLLOW the Gentoo newsletter, AT LEAST, so you can get a heads-up when config files change or files are moved around. It happens from time to time.
Really, the only valid point he makes that generalizes to servers other than his own is the following: Gentoo takes more time to keep running. But you have to weigh that against the flexibility you get, just like any "build vs. buy" decision.
The article makes it sound as if gentoo installs the ~unstable profile by default. The stable one's no more bleeding-edge than Ubuntu.
Gee!!! I thought that moving from Windows to any Linux-based anything would solve all the worlds's problems that Microsoft has caused!!!
Where, oh where, is the standard Slashdot drivel from you sanctimonious Slashdot twits?
There is NOTHING forcing you to "emerge world", "emerge system", and "emerge --sync" every single time Gentoo
updates portage... Emerge flags include "--pretend", "--ask" and "--fetchonly" among several others, learn to
use them.
Non sequitur: Your facts are uncoordinated.
i didn't read TF blog post, but since i saw a radical view and the word "server" in the same summary, i'll add my 2 yen here. Since we see the word "server", we assume we're talking competent system administrators here. A competent system administrator usually reads and understands the documentation of a software package before making a decision. Having read the documentation of gentoo, I can suggest at least the following ways to ensure a stable distribution:
- one can create a copy of the source files repository
- one can create a repository for self-compiled binary packages and install from there
- one can use the global repositories, and still get a stable version by restricting available packages by version
- finally, as others say, one can use the stable version.
Since the blogger seems to have missed these obvious ways, he hasn't read the documentation, and hence is not a competent administrator, hence his opinion is not very valuable.
(I posted this on the gentoo forums)
If someone is running a server room with many live production systems where downtime must be in seconds per year, they should ALWAYS have a test environment and a production environment. Gentoo makes it extremely easy to produce this setup. Imagine if you will, this setup:
1) Master rsync system (contains the portage sync used by all the systems)
2) Test boxes for each role needed (perhaps you have 3 different kinds of servers, WWW, Mail, DB)
3) Many production boxes
What you would end up doing is creating a fairly generic gentoo install (by generic, I mean hardware independent - like i686 or whatever you feel comfortable that will be supported for the lifecycle of the servers). All production servers are identical to the test boxes at the beginning of this example and have a simple backup of the whole test environments (perhaps a large tarball saved on a separate drive). A new update is necessary for apache so you do an emerge --sync on the master rsync system. Then you rsync all the test boxes so they have the same portage tree. You then run the necessary installs on the test systems to make sure that it works, if it doesn't, then you research why and figure out if its easier to fix after the update, or if the update needs to be done differently, if you need to, you can restore the test system from the backup and start over. After you have all the test boxes running well, you can then rsync the production boxes and reproduce the steps necessary to get them updated.
Once all this is said and done, the production boxes will all be updated successfully (and the updates were tested on the test boxes) and the test boxes will at this point have the same configuration as the production boxes. You would make a new backup of the test boxes and wait for the next time you have to do this cycle. As long as the boxes really are identical, you could even run konsole (or another xterm that allows you to send your input to multiple console windows) and perform the identical steps on all the same type of boxes (sending your update commands to 20 or even 50 servers at once).
I'm sorry, but in any real production environment, I see NO issues with this setup. It may be a bit time consuming if you have a lot of etc-updates to do, but still, the basic update should be painless to that point.
-Jason Pf.
For a true production server where downtime costs thousands or millions of dollars a minute, you need the insurance of having people to escalate to if you have a problem. If for no other reason than to CYA in a liability / management-political situation. That's the real reason not to run your production on Gentoo (though the technical problem mentioned is probably what's kept anyone serious from selling a support contract for it).
They say the mind is the first thing to
Servers are not the place for bleeding tech. Servers are the place for stability.
That is, unless you really dislike your customers that much, be they actual customers or other divisions in your business.
GLaDOS for President 2016! "Well here we are again. It's always such a pleasure." -- GLaDOS, 2011
You say Gentoo wants to change a lot of stuff?
Any binary distribution has two modes of updates. One is an updated package within the same release; the other is a mass-update from one release to another. Gentoo combines the two, since the distinction is artificial. What you call "changing a lot of stuff" is merely keeping packages reasonably current so that you never have to do a mass-update or complete reinstall.
Anyone who considers the Gentoo update process too difficult either hasn't used Gentoo (upgrades are easy, and there aren't that many of them if you stick to stable x86) or has never dealt with package conflicts in binary distributions. That is the real horror I want to avoid, and I avoid it nicely by running Gentoo.
Gentoo gives you 100% control over your system and how things are built.
It does NOT force you to do anything.
"You will need to fix things that break in the upgrade process..." Like what?
This past year there have been some major changes in the Linux world like:
glibc, gcc, xorg, apache(Gentoo went to the standard) and mysql are some the things I can think off of the top of my head.
Because of how Gentoo updates, big updates like these might break things if your not watching what your doing.
And if your blindly updating your system and overwriting confings when you do etc-update, its your own damm fault.
There comes a point in where a package is marked 'stable' for some distros, but if you look on the project site, its old and outdated.
http://gentoo-install.com/
...is currently uptime 242 days. Updating daily.
So, now when server issue has been explained exhaustingly, we can talk about my gentoo programer's desktop, gentoo electronics lab and drill machinery controller, gentoo adsl/wifi router and gentoo tv/multimedia nano-itx box.
From my point of view, Siker is just a moron and I mean it seriously.
There you are, staring at me again.
If you have more than one server, the best way to manage updates is to have one server (preferably non-production) on which you build and install binary package updates.
These binary updates can be pushed out to other machines and installed once any config file issues have been ironed out on your package-build machine. For extra kudos, all machines can be used as distcc-servers so that package compilation can be accelerated.
Finally, to reduce load on gentoo's servers and to help keep the machines in sync, the machine on which the packages are built should be the only machine that syncs to Gentoo's servers. All other machines should be configured to get their portage updates from your local build machine.
The real "Libtards" are the Libertarians!
It's been said before by many. I cannot say I disagree with the article. With more traditional distributions of Linux, you always have standardized packages with some amount of quality control. Bugs and security holes slip through to the end users all the time. Often your end users report these bugs to the upstream maintainer. Occasionally, the end user even submits fixes upstream.
Gentoo is so system dependent compared to other distros. The end result, instead of having 1 package for some function, you have 1^n packages for that same function. Given 'n' amount of users with differing hardware and compile time arguments. The Qaulity Assurance ends at the user, always. You ultimately have a quality control department that consists of one, the user.
Any system upgrade or maintenance procedures in production environments are usually limited to a few hours at most. It does not make sense to spend six hours compiling what could have been installed, configured, and tested in 6 minutes with a pre-compiled package. In the event of a hardware failure, I find it reassuring when a Linux distro can be loaded onto a spare box in 15 minutes. Then spend a few more minutes restoring configurations from a good backup.
But that's just my opinion. To each his own. If it works for you, then go with it. Otherwise, I'd say it is a fairly level-headed review.
/^([Ss]ame [Bb]at (time, |channel.)){2}$/
Gentoo on a server? No longer.
I used Gentoo for several years. I learned an awful lot about Linux from it. And I appreciate the work that goes into it. But my servers run Debian now, for one reason - quick, reliable updates. I support several small businesses, I don't have the resources to maintain test environnments to check the impact of upgrades. And not having multiple powerful systems at many sites means distcc is not an option. And the recompiles occasionally necessary for apache or samba or postfix or mysql put an unreasonable strain on servers that are typically not high powered and are supporting multiple users. So for quick, reliable system updating apt-get beats emerge every time.
I'm not knocking gentoo. It's a great system for testing stuff, and evaluating software. But in the 3 minutes it took me to type this post, I could update 5 servers that hadn't been updated in a week.
-- "Never underestimate the power of human stupidity." - R.A.H.
At risk of exposing my ignorance here (I'm a Debian person; the last time I did anything RedHat-based was before automatic package management), what is CentOS's automatic-update feature like? Does it have one?
I assume it uses yum, or something like it, being RedHat, but does it pull from RedHat's servers directly, or are there separate CentOS repositories? I assume it's the latter. In that case, how closely do the CentOS repos track the 'official' RHEL ones, in terms of patches and bugfixes? Not that you'd probably want to do it on a true 'production' system, but can you do the CentOS equivalent of 'apt-get upgrade' and be reasonably assured of not breaking things?
I've always been intrigued with CentOS, and it does seem to have a good reputation as far as stability is concerned, but after growing up with apt-get (and before that, nightmarish experiences with dependency hell on some very early RedHat systems), I've developed a certain perhaps-unwarranted negative bias of everything else.
"Ladies and gentlemen, my killbot features Lotus Notes and a machine gun. It is the finest available."
I'm a long-time Debian user, and I also think it's an ugly legacy UNIX thing. It's much better to have some sort of process supervisor that will restart crashed servers, and that will deal with dependencies in some sort of sane manner. The problem is that Debian is huge, and the amount of work required to switch to a new system would be almost equally as huge, but the benefits are comparatively small, so there's never been a push to change to something different.
The bright side of it is, like most of the advances Debian has made, when it finally does get replaced, it'll probably be replaced with something substantially better, because anything less would be unlikely to win the support of Debian's army of volunteers.
http://outcampaign.org/
Hello? Security anyone? Or maybe someone remember kernel 2.4.11? Don't wanna update that one either should you happen to have it installed back when it was considered stable?
I do agree that there are certain things you needn't update. A local server without a connection to any user you do not trust your data with (i.e. nobody but you, if you're smart) running on rock stable software that gets feature adds rather than bugfixes in new versions is a candidate for this. And for this server (singular, probably worldwide), the setup is ok.
Not updating a server connected to the internet is an invitation for hackers. No matter how "stable" or "solid" or "secure" a system is deemed to be at the moment of its compilation. Time and again there are bugs found in software that has been considered stable and safe for years. OpenSSH is hardly the most insecure application out there, and I would NOT want to see what happens to a server that does not update it.
And, last but not least, when you don't want to update Gentoo, you don't have to. It's fine and satisfied if you don't do an update sync. Actually, you reduce the workload of the servers if you don't.
So what the hell is this fuss about?
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
Call me a jerk, but I found a lot of what was said to be totally accurate. I tried to love Gentoo, off and on, for three years. While it's true that you can start on a fairly complete base system, and while it's true that there are tools available such as glsa-check now and revdep-rebuild (to say nothing of the joys of being able to unmask only what you want to have as totally bleeding-edge) it's true that it's it's a major time sink.
;-)
I'll be more than happy to let the folks at Canoical, Red Hat, Novell, or wherever be the ones to put in several hours of work; I simply can't, at home, put in the hours required to maintain a "stable" system. When I quit using Gentoo a couple of years ago, it was to the point where I'd search the forums before I'd ever install a piece of software. And you know what? That gets old. Real old. Especially if you're sitting in front of what should be a desktop machine and you're waiting for revdep-rebuild to rebuild a couple dozen packages because libpng applied a non-backwards-compatible patch that fixed a major security flaw.
Sorry, kids, but although I can deal with running a Gentoo system, I choose to run Kubuntu 6.10. Not because I'm too much of a wuss to run Gentoo, or because I'm too stupid to run anything other than Ubuntu, but because I'd rather spend the hour or so of computer time I have at home some days getting pix and video of my adorable girl (now at toddler age) ready for the grandparents. Not glamorous, and doesn't help push the state of the art, but it's much more gratifying than, say (I'm making this one up), trying to chase down the ruby package maintainer to get him to apply a patch so that you can use Getopt::Long without having to edit files by hand.
Stating on Slashdot that I like cheese since 1997.
Where I come from, deployments to production are first validated in a QA environment. OS stuff, application updates belong there too.
What happened to backups anyway?
http://stephan.sugarmotor.org
No offense to Daniel Robbins or any of the other Gentoo people, but to me personally, downstream water doesn't taste so good. ;-)
Daniel's original premise seems to have been (which I agree with) that there are some elements of FreeBSD which are highly desirable, which at the time, Linux didn't have. Ports, portaudit, portupgrade...they're all good things. Ubuntu has an equivalent of portaudit and portupgrade combined, and of course the Red Hat autoupdate was probably the first on Linux, but the difference between those and the two commands I mentioned is that the Ubuntu and Red Hat services both focus on binaries...portupgrade anywayz focuses on source, which is something that at least some of us want.
I don't advocate using source compilation all the time, or if I do, at least not during the day or when you're active...set something up to do it while you're asleep or while the system isn't being used...that way it won't bother you. To be honest also, the main reason why I advocate compiling from source is simply for the reason that if you stop doing a certain thing for long enough, the ability to do said thing when you *do* want to has a tendency to disappear. If you maintain the attitude of compiling from source when it doesn't matter, there'll still be enough people doing it that the option to do so will still be there when it *does*.
There are a lot of people out there who don't want to do anything that even vaguely resembles self-responsibility or proactivity, at least where using a computer is concerned. That's fine, but said people need to realise that the fascist nature of such things as Vista is merely the ultimate logical extension of them wanting multinational corporations to act as their wetnurse. It's been an eternal truth in politics and other areas as well as IT that freedom and proactivity genuinely go hand in hand...If you don't want one, you're not going to get the other.
To summarize:
Quote: "If you don't need new features, and things are working, why change anything?"
Translation: "Never change a working system."
Quote: "...I ran the dreaded but most needed "emerge world"..."
Translation: "My system worked but I updated everything"
Quote: "I had nearly no idea of what I was updating..."
Translation: "I didn't bother to check what was going to change"
Quote: "I tried to read the enormous emerge log file..."
Translation: "I didn't bother to read the log file about what had changed"
Quote: "...the machine had to be resuscitated..."
Translation: "I changed it, it doesn't work anymore and I can't be bother to read the documentation"
Basically, he made a bad choice for his environment. Horses for courses.
I've been using Gentoo on our database / web / email / many-other-goodies server since August 2003 ( I keep emerge --sync logs ). I'm running the stable branch on our server, and the unstable ( ~x86 ) branch on desktops. I certainly agree that updates on the unstable branch have to be done thoughtfully, but building binary packages when emerging helps a great deal with disaster recovery. It's nothing that can't be fixed with a little searching.
... stable ... it is ( coming from the ~x86 branch ). I keep a separate binary packages repository for the server ... just in case ... but haven't actually had to back-track to anything yet. I do updates outside of work hours, and revdep-rebuild when upgrading major parts. I haven't had any catastrophes yet. Actually I haven't even had any mishaps yet. What can I say? If you are confident enough to run Linux on a server, I say you can handle the stable branch of Gentoo.
But on the stable branch, I've actually been very surprised with how
As for the points the author raised against Gentoo:
1) Too long to do initial install.
This one gives it away from the start. You only install once. But this is at the top of the list. I can't remember how long it took me to install Gentoo on this server, but it was probably 2 days or something. Who cares? That's what time I take installing *any* server. You don't just whack it together and put it into production. You install, you read, you test, you frig around some more. What's wrong with that? The author is no server administrator.
2) Same as point one, just repeated
WTF? Seriously, this author has his head up his arse. On the one hand, he later says that you shouldn't update willy-nilly on servers, and yet then says that it takes ages to update everything. So what, exactly, is he trying to achieve? It takes me about 10 - 15 minutes to update MySQL, which is the most common package I update. What's wrong with that? I back things up, shut down MySQL, emerge the new MySQL package, test, and import form backups if required. No problem? Where is this guy's problem, seriously?
3) Don't like updates, even if they are to more stable packages
Nothing forces you to update packages. Also, no-one claims that packages updates *won't* break things ( though my experience is that in the stable branch, updates *don't* break things ). But if you don't want to update, don't. No problem. If you do want to update, the tools are there to update easily. Sure you should pay attention to what you're doing. It goes without saying.
4) Same as point 3, but with the update impetus being security instead of stablity
Doesn't deserve a response really.
I challenge this author to prove that he's actually used Gentoo Linux for more than 7 days without running crying back to Linspire.
That would have had around 900 days uptime if my reboot-happy Windows-only-admin coworkers wouldn't have reset it in a panic on multiple occasions to "troubleshoot" (no it was never a problem with my OpenBSD box) mail problems.
I don't know what the hell it is with Windows-only admins and rebooting. The kind of instability that required reboots all the time was reduced drastically with Win2k and win2k3, yet that insatiable urge to reboot first and ask questions later still plauges my Windows-only counterparts.
I don't always use unix-like operating systems; but when I do, I prefer FreeBSD.
Gentoo is great.
Gentoo is wonderful.
*IF* you're only administrating a small handful of servers.
When you have to look out for a few HUNDRED machines at a time, you **reaaaally** start to appreciate things like calendar based release cycles, binary packages, uniformity, hardware compatibility lists, repository mirroring, etc.
Gentoo is far too schizophrenic to be a reliable environment for n servers, especially in a "real" scenario.
Academically, Gentoo is a wonderful system.... but its one of those things that works "great on paper" but sucks a lot of ass in Real Life. Trust me, you have better things to do than worry about than whether or not upgrading one package for a minor security fix will drag along your system libs and userland utils with it. If this is the sort of thing you concern yourself with on a day to day basis, you're doing something WRONG.
Large environment management is a constant battle with entropy.
Hard drives die, switches fail, nics go bad, boards burn out, storage space fills up, and all this has to be dealt with. Using predictable, understandable, documented, tested and supported systems creates One Less Thing to worry about.
An entire IT staff should not have to be briefed on a daily basis about what the Gentoo Administrator decided to include in his(her?) build flags.
-s
The whole argument of "Gentoo 'wants' you to update a lot of things" is trivially debunked. Gentoo isn't a distro per se, it is a meta-distribution. I have worked in environments where Gentoo was used on servers, desktops, and what have you. The "solution" to Gentoo's frequent changes is simple: maintain your own portage tree mirror, which you keep frozen until you are good and ready to roll out the next major update (which of course you only do after extensive testing, like any Suse, Red Hat, or debian update). You define your own in-house releases, not Gentoo (and you graft security updates to your own tree as they come out--this isn't difficult, as each security update is announced by package).
This is trivial to do, and leads me to suspect the person putting forward the argument against using Gentoo (or any other well-engineered distribution) on servers either has an agenda, hasn't taken much time to ponder the issue, or doesn't understand the technology.
The Future of Human Evolution: Autonomy
Seriously the "if it ain't broke don't fix mentality" is what pays my bills.
... e.g. migrating from Apache 1.x to 2.x... and then there are bugs that haven't affected you yet but are still in the code base. Just because you haven't experienced any problems yet does not mean there aren't any underlying problems in the packages you're using.
There are two kinds of "broke", there are gaps in functionality
Case in point. The company I work for is in a mad dash to upgrade for the DST time change. And for those of you thinking "duh, you just upgrade your timezone files"... no it's not that easy. Some Sun systems require firmware upgrades, almost all of the systems prior to 2005 require binary updates because they can't handle a timezone that has two rulesets (e.g. they would apply the new 2007 rules to timestamps from 2005), most JVM's have to be patched or upgraded and some applications inexplicably do their own calculations and have to be update as well.
The majority of the company has the "if it ain't broke" mentality and were running everything from NT 4.0 on DEC Alpha's and Sun 2.4 to Windows 2003 64-bit and Solaris 10. Upgrading the older machines is an absolute nightmare because the vendor patches are built one, two even three years worth of patches that we haven't applied. What should be a relatively simple upgrade task has broken applications all over the place and has our QA and Engineering staff bleary eyed and ready for it all to just end.
The answer is controlled refresh. Twice a year you sync up your servers with a certain patchset. You don't go crazy... you just get vendor required patches and include them in your dev and qa cycles. And you DO NOT USE EOL OS' in an enterprise environment. Ever. This includes commercial and FOSS packages.
Full Disclosure : I run two gentoo boxes at my house my workstation and my mythtv box. I patch them about once a week because I like to tinker. My web/file/mysql server is running on a stripped down Debian system that only gets patched every few months or if there is an advisory that comes out.
Which is exactly the way I like my infrastructure. 3-6 months freeze with all bugs known, worked around or fixed in the meantime. Once I have gotten it to this point I build on top of that for the actual services which can run something very bleeding edge if necessary, but this is as I pointed out "your daily bread". For the stuff that is not, you need to be sure that it works and if you are a manager to be severely anal about it. So debian stable + 2-3 unavoidable backports and local builds is about right. This is also the reason corporations buy RedHat ES/AS/WS like hot bread. They finally see a model where the base has been frozen long enough to be relied on for building your own services.
Many itadmins and most developers have a problem with understanding of the "establish a platform and build on it" and "platform freeze before development" ideas. They think that everything is a fair game and the results (in man hours wasted on piecing everything together for release) are usually quite obvious.
Baker's Law: Misery no longer loves company. Nowadays it insists on it
http://www.sigsegv.cx/
Gentoo has long been considered a hobbyists flavor of linux, and as much as I enjoy Gentoo as a hobbyist, I've come to learn that a slim hardned version of Gentoo will have almost no trouble at all. A slim server that requires minimal amounts of packages requires minimal amounts of updates, and runs extremely well.
I also love that Gentoo has THEE quickest reaction time to security updates, leaving your competition vulnerable and you safe. I've got multiple computers running gentoo. One is my home desktop that I didn't use for probably 2 months. In that period of time there were 800 packages that had to be updated, I'm now down to about 200 that I still have to finish, and that is exactly what this article talks about. However, a server won't have that many packages to begin with because it won't have gnome, kde, beryl, nvidia, dvd support, mythtv and other optional programs, and games! However, my gentoo server, left alone for 2-3 years probably would require everything to be updated, it would flow much more smoothly than a desktop update.
Gentoo is great on serveres as long as you don't have everyting installed. Gentoo is great on desktops as long as you keep upgrading. Gentoo rox.
Support the source, Open Source! An entire site developed with OSS