Introducing YippieMove '09. Easy email transfers. Now open for all destinations.

Over the last year I have run a server using the Linux flavor Gentoo. While most of the servers I deal with these days run FreeBSD (WireLoad’s servers included), I was curious about what speed I could get out of old hardware with Gentoo. Gentoo is a system built to make it easy to compile every little piece of software in the system with the biggest and baddest gcc flags imaginable for your particular hardware. In theory this should lead to a faster system.

The experience has been a bit of a mixed bag. There are things I really like about Gentoo: the package management, USE flags and the sophisticated dependencies system. But unfortunately the drawbacks are severe for a server setting.

The Good

The system is better than most Linux systems I have seen when it comes to general package management and installation. The emerge command is excellent. It makes it easy to update and install software together with the necessary dependencies. A well thought out system called USE flags complement this system well. Rather than having to tinker around with every program you compile, you can set some global USE flags. Most packages will take note and your system will be made into one harmonious whole of software agreeing with each other about what should be used and what should not.

The easiest way to describe the benefits of this is by comparison to a normal FreeBSD server and the installation process. Assume that you don’t have X11 and that you don’t want it. Now, you are installing PHP and you want to have support for graphical operations (image conversion, CAPTCHA generation, etc). So you find the make flags to do this and you add them to your make.conf. You hit ‘make install’. During the build process the ports system goes out to build the dependencies of your graphics library. The graphics library requires fonts. The fonts want a font manager. The font manager is by default configured for X11. Wait, X11? Suddenly, X11 becomes a dependency and you find yourself hitting Ctrl-C rapidly!

In Gentoo on the other hand you would have -x11 in your USE flags and everything would be cool. It’s a slick system.

An OS X Term window showing Gentoo executing 'emerge -pv screen' with colored output.
Colorful Gentoo.

Gentoo also has an active community. As we have mentioned in this blog before, there is an excellent forum for Gentoo users. There are also little touches like how Gentoo uses colors by default, to improve clarity and to go easier on the eyes.

Disadvantages Expressed in Time

All of these things make it a pleasure to use Gentoo. I would love to use it for a desktop some day, should my Apple OS X machine fail me. But I really don’t see myself using Gentoo in a server setup again. Here’s why:

1. Gentoo is Time Consuming to Install
At least when I installed Gentoo there wasn’t really any installer. The documentation is excellent and describes exactly what you need to do, but it takes a while. In fact, it took me several hours to set up my first Gentoo system. And that was just the beginning.

2. Gentoo is Even More Time Consuming to Install
The strength of Gentoo is the compile everything mentality – at least that seems to be the main selling point. Unfortunately on my low-end test server it took about three days to compile even the base system with Apache, MySQL, Python and some other important software. My machine was working non stop compiling things during this time.

I understand that the latest recommendation is to not perform a so called ‘stage-1′ installation anymore. I would recommend following this suggestion. But then what happens to the compile everything advantage?

3. Gentoo’s Stability Strategy: Update Everything
Since it takes a long time to compile a program, you usually don’t want to have to do it too often. Unfortunately Gentoo encourages you to update software on a frequent basis, just for the sake of updating.

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. From the Gentoo handbook:

From the beginning, Gentoo was designed around the concept of fast, incremental updates.

If all you’re concerned with is keeping your web server up, what you usually want to do is to set up a stable system and then forget about it. You install security updates as needed but that’s it. With Gentoo, this isn’t really feasible because there is no ‘stable’ Gentoo release.

What’s worse, there will on occasion be a sort of ‘system update’. This is called a new ‘profile’. The Gentoo documentation and the handbook will at this time encourage you to update to this new profile. A profile update will try to replace your basic system. If you are a system administrator, rather than a desktop user, this should be enough to scare the living daylights out of you!

A profile update will touch a very large number of configuration files, and it may even alter your startup process. Obviously this is not something you want to do to any server. It would be very difficult to verify that everything works as it used to afterwards, and you’d be fairly likely to end up with broken configuration files that may stop working the next time you reboot. This is in fact exactly what happened to me, despite a substantial time spent updating /etc files. The end result: the machine had to be resuscitated on-site with associated downtime.

For a more sensitive server than my test system, you’ll want to simply retire the system whenever a new profile comes out. Just start over fresh with a new Gentoo installation on an alternate machine and go through the setup process. This way you can be fairly sure it’ll work even after a reboot. Once you’ve verified that everything works, switch to the new system.

4. Gentoo’s Security Strategy: Update Everything
As you might be aware, FreeBSD has a nice little program called portaudit. This utility will alert you if you have any software installed with known security holes. Then you can go ahead and update that software with a simple ‘portupgrade‘ command. There’s rarely any problem with this process.

Now, Gentoo also has something like portupgrade. What it doesn’t have is portaudit.

In all fairness, Gentoo has an experimental command called ‘glsa-check’. This command automatically examines whether your system is affected by vulnerabilities described in Gentoo issued security advisories. It also knows what steps need to be taken to fix a given security issue. I really like this development, but I understand that this command is not considered production ready. The Gentoo manual page about it is filled with warnings that this is a tool under development.

In the meantime, Gentoo rather encourages you to update the whole system. And of course a system wide update tends to cause just the amount of havoc you would expect from it.

Gentoo too Time Consuming and too Risky for Servers

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 doubtlessly need to update configuration files. You will need to fix things that break in the upgrade process. This is exactly what happened to me with Gentoo during its test year. I had nearly no idea of what I was updating as I ran the dreaded but most needed “emerge world” update. And once I was done I still no idea. I spent a long time working my way through updates in the /etc folder, using the built in ‘etc-update’ command. I tried to read the enormous emerge log file and take appropriate actions. And still things broke.

The best way to keep a system stable is to get it working and then not changing anything. This is hard with Gentoo. Gentoo wants you to change a lot of stuff. It wants to be bleeding edge.

And hence my conclusion. Gentoo is fun to play with, but oh is it time consuming. I guess that’s the cost of living with a hardcore compile everything attitude – you’ll be on the bleeding edge and you better make sure you can balance on such a thin edge. For a desktop system, Gentoo seems fabulous. Fun to work with, colorful, a beautiful ports like system for software. USE flags.

But for a server, especially a production server, Gentoo just isn’t time effective. It’s both the time it takes to put in security updates, and the time possible reinstalls will take. I believe there were three profile updates for Gentoo in 2006, and very little support for older profiles. If you’re like me you’d probably much rather not reinstall your servers three times a year!

In closing I want to quote something Gentoo told me recently:

* An update to portage is available. It is _highly_ recommended
* that you update portage now, before any other packages are updated.
* Please run ‘emerge portage’ and then update ALL of your
* configuration files.

Call me stressed out but I really can’t fit too many ‘update ALL of your configuration files’ into my schedule. :)

Author: Tags: ,


  1. Why Gentoo Shouldn’t be on Your Server « Tuxicity’s source
  2. » Blog Archive » How server management works (the short version)
  3. gentoo linux non va bene per i server… :-O » Schiaccianoci’s WeBlog
  4. Josh’s Blog » Blog Archive » Why Gentoo is a Great Server Distribution (a Rebuttal)
  5. Mindless Techie
  6. DriftBlog » Blog Archive » Gentoo-much
  7. The Gentoo Debate Continues : Mindless Techie
  8. zero-blog » Gentoo On The Server
  9. gomez’s blog » Blog Archive » Gentoo is not about choice
  10. Mass Install/Upgrade WordPress with Gentoo+Webapp_config |
  11. Gentoo | rakhesh, deblogged


  1. bLUEbYTE says:

    Sorry to post third time, this is the last I promise.
    In above, I said “If in the future you want to update an installed package or install a recent package, just sync portage and if that package requires newer versions of libs installed in your system, well what would you expect? They would be updated as well.”

    But I missed the key part; ONLY the dependencies that the newer version of your application REQUIRES will be updated. That is the key here. In a binary distro, you would be stuck because that would break everything in your system that depends on that dependency lib; but with Gentoo, you only need to do a revdep-rebuild. The update that your are avoiding (which you are right), i.e the system-wide update, is not forced to you — it is only performed only if you do a WORLD update.

    Best Regards

  2. Dear bLUEbYTE,

    A situation where you update very little is precisely what I desired. As you will see here in this comment thread and elsewhere though, avoiding updates is easier said than done in Gentoo though, at least in my experience.

    Profiles become deprecated within a year, and if you don’t update on a regular basis, base dependencies start to become unsupported and eventually you won’t be able to do the necessary security updates without packages breaking or requiring extensive related updates.

  3. bLUEbYTE says:

    Hi again,
    Maybe this was already mentioned in one of those comments, but I would like to add about the closing part:
    Gentoo includes several semi-automatic config-file merging utilities; for instance the utility ‘etc-update’ will auto merge about %70 of the configuration files in a typical system, for others (the ones that you modified or could not be trivially merged in previous stage) it asks you whether overwrite them or not; it is just a matter of answering y or n.

    My personal experience, as an example has been (honestly): It once told me ~40 files needed update. I ran etc-update, then after automatically merging most of the files, it began prompting me to answer y or n for about 13-14 files. At the end I was left with three unmerged files (all of which was already edited by me, so I didn’t tell it to overwrite them). The whole process took about three minutes.

  4. anon says:

    It comes down to this…

    With any operating system you use, if you do NOT update things WILL EVENTUALLY become deprecated and obsolete. This is an unavoidable fact of software systems. Things move on.

    Even the mighty windows suffers from this syndrome, can you imagine running a Windows 95 server today? Would you even be able to install the latest Exchange or IIS packages? This is simply the way it is…

    So maybe Gentoo moves a little faster than most operating systems, and maybe it prompts you to update more often, but you don’t have to. You can simply let your server decay until its so old there is nothing to do but suffer a major reinstallation and migration.

    I, for one, would much rather bear the maintenance of a relatively up-to-date server than let it rot and suffer updating once a year or however long you want to be lazy for.

    Thanks! :)

  5. gentoo user says:

    IIRC there are more configuration updating utilities mentioned in the handbook or in docs (etc-update, dispatch-conf, cfg-update (very good)). Using the last two you can see what would be changed (and even choose what to change) and so prevent some catastropy to happen. Simple as that.

    You can use ccache for compiler cache and this way insalls and especialy updates become much, much, much faster. (mentioned in the docs, too)

    If emerge seems slow, you can use alternatives that are faster. Paludis for example — fast as hell, but it’s currently still in ~arch so this might not be for a production server, YET. And there are some others, too.

    You can mount /var/tmp/ or just /var/tmp/portage (or /var/tmp/paludis if you use paludis) to tmpfs and see the compilations faster stil. If you dont have a few gigs of ram you can stil do this, if you have big enough swap (swap is fast – in my experiences faster than a filsystem)

    You can do updates in a chroot jail, test it and then update your main installation. So your server keeps running happily, while you test what will be done, and then update the main one (using bin pkgs, so you don’t compile twice).

    If compiling takes too much of processor power you can always use nice and the users will not feel that you’re doing an upgrade.

    There is more and much more to comment…

    I must say you didn’t realy prepare yourself for this test in the first place.

  6. James Watt says:


    run an update once a week, you’ll only have a few to fix.

  7. Lewis says:

    The most valid point that is made, whether directly or indirectly by the author or otherwise, is that Gentoo profiles (/usr/portage/profiles/..) have a shorter life cycle then what you would expect for a production server.

    For a production server, you would want a particular “profile” (think RedHat Release 3, Release 4, etc.) to be supported and maintained for 2 to 3 years at the least.

    Although it is true that you can “freeze” your server’s build for a year or whatever…with the expiration of the profile your server was originally built upon, you may find that you will no longer be able to update certain necessary security fixes, etc., because of package masks, profile masks, and so on and so forth.

    Once you’ve reached the limit of a particular profile’s life cycle – you would need to upgrade to a new profile – and this is part of what has been mentioned as being a major headache and at times a crisis.

    The caveat is that because of the flexibility of Gentoo – if you know your way around USE flags, the make.conf file, package.mask, package.keywords, and such – you can manually “intervene” (so to speak) and maintain the profile you built your server on. You would essentially be backporting a newer profile’s packages.

    Now, if you do not see the life cycle of the profiles as being an issue – dig out a Gentoo 2005.x CD and build a system from that. Then, try and keep that system updated with security and bug fixes only. You’ll find that you have to do some manipulation of portages resources, and it can be done – but it’s not easy. And it’s time consuming.

    Initially, I thought the author was just another no brain hack – but regardless of what he can or cannot do – the simple fact is that the short life cycle of Gentoo profiles is a limiting factor for a production server.

    Perhaps it’s not a fair comparison, but would you want to buy a car that in a year would no longer have parts readily available, would be redesigned (maybe not fundamentally, but enough mechanically), and would require you to either scour junk and salvage yards or buy new parts and then have them custom modified to fit your car?

    It’s an extreme analogy – for techies – I realize, and overly simplified. But that is what goes through the mind of a CTO/CIO, or other member of executive management. Bottom line, the execs want something they know can and will be supported for some duration of time – even if they have to pay for that (and not get robbed at the same time).

    I have been a loyal user of Gentoo since 2000 and have deployed it on production servers, workstations, and development systems. So I’m not a Gentoo nay-sayer. But I am trying to be a realist. If you can convince your management that you can maintain the profile/release of your Gentoo based server for an extended period of time (and this means the ability to easily pass it on to someone else should you leave the company), then by all means – more power to you and to Gentoo.

    In closing, I’d like to comment on the Author’s last words about Portage…

    * An update to portage is available. It is _highly_ recommended that you update portage now, before any other packages are updated.
    * Please run

  8. Lewis says:

    ps…. to bluebyte….

    “…You don’t have to perform installation and maintenance tasks at this system. You can very well chroot from another faster machine to your Gentoo partition (even possibly over NFS), and do the installation/maintenance with that fast system…”

    It doesn’t matter where anything is built – the point the author is making is that building a system from source takes longer then installing from, say, a DVD or series of CD’s.

    “…YOU DON’T HAVE TO UPDATE. If in the future you want to update an installed package or install a recent package, just sync portage and if that package requires newer versions of libs installed in your system, well what would you expect? They would be updated as well. If you don’t want this to happen, NEVER SYNC and nothing in your base system will ever be updated; since in that frozen portage ’snapshot’, the version of your required app. can only depend on those versions of libraries…”

    You’re missing the point. The author wants to be able to sync portage, determine what needs to be update, and update only what is essential. Just because a dependency in portage exist does not necessarily mean that the security fix in Apache requires an update of PHP. If the security fix specifically entails a change that will impact PHP, then yes, update it as well – but not just because portage things it’s necessary.

    “…And don’t think that switching profile from, say, 2006.1/server to 2007.0/server will not result in sooo dramatical effects on your system, and everything would be broken. As I said above, you want to sync, update profiles (optional) ONLY IF you want the most recent version of an application…”

    I’m guessing you never started with Gentoo 1.0, 1.2, or 1.4, or 2004.0 and upgraded from one release to the next.

    By the way, back in the day, it was called Enoch.

  9. Dear Lewis,

    Since most of your comments have been covered by me or other people in this thread already, I will just focus on your last remark where you write that the Gentoo update message should be put into context.

    What context are you talking about specifically here? As far as I can tell, it’s a message and it says what it says. Of course you need to update packages, or your security will suffer. So thus you must update portage. Fair enough. But update ‘ALL’ your config files? If I upgrade sshd I have to update my apache config files? This is clearly absurd.

    A lot of people have vehemently claimed that updating is purely an optional thing for Gentoo. Yet not only the Gentoo documentation but even hardcoded portage messages strongly urge you to perform updates. Perhaps these commenters know something the Gentoo developers do not. More likely, they’ve just been lucky. Take a look at a couple of the comments here and some over at the Gentoo post about this article for examples of people who ended up with catastrophically broken systems by not running routine all encompassing updates.

  10. Lewis says:


    I take it you didn’t read my response carefully. I did NOT say you would not end up with catastrophic problems either way – given the intracacies of portage and just the inherent dependencies of building shared libraries and apps from source code.

    What I did say was that there are ways around it. By the use of the package.mask, package.keywords, USE flags, make.conf, and other such configuration options you can sustain your system in a semi-permanent state.

    Note that I said semi-permanent. As I did also support your statement about profiles aging far too quickly for a production environment.

    And as for “context…” Did you entirely miss the logic involved?

    Those are IF/THEN statements which imply that there is a choice. In that little bit of text it may not go into detail as to how you can overcome the necessity of upgrading – but it still remains that this option is there.

    As I mentioned, you can use various portage custom config files and ultimately, you can tweak your own ebuilds. Not something for a production server – but it is possibly…meaning, you don’t HAVE to upgrade simply for the sake of upgrading.

    You do know how to modify an ebuild to satisfy your dependencies, don’t you?

    Commenters probably do know something that the Gentoo developers have forgotten… As Albert Einstein said, “only two things are infinite, the universe and human stupidity – and I’m not so sure about the former.”

    If you do not want to know Gentoo inside and out, that’s one thing. But you cannot claim that it cannot do something simply because you haven’t learned how to do that – or simply because you won’t take the time to learn it.

    And if you just cannot dedicate the time – it’s just not available – then be honest and say you don’t know everything there is to know about Gentoo. And based on what you do know, sure, with that limited view – I suppose you do always have to update your system.

    Suffice it to say, if you’ve ever built *.deb, *.rpm, packages from scratch – having to write your own *.spec files – you would be familiar with how you can manipulate and customize the dependencies within *.ebuilds as it follows the same vain.

    The dependencies for a piece of code can come from several places:

    1) The requirements set out by the developers of the source code, i.e., maintainers of KDE, not the Gentoo KDE package maintainers

    2) Influences what dependencies the Gentoo package maintainers/developers absolutely should have

    3) But also the system you are building the code upon is also significant

    4) As it is influenced by the profile/release from which you start building your code upon

    5) Which in turn is influenced by what the Gentoo package maintainers/developers wanted to pull in along with the required dependencies

    6) And/or is influenced by what the Gentoo package maintainers/developers had to pull in to obtain a stable ebuild

    And those are just some of the more obvious things. Like I said, if you’ve ever sat down and built a system from source – whether it be a Debian, RedHat, SuSE, or other system from source – you’ll find some dependencies that are required by the original coders, and some that are inherent because of the particular distro.

    Frankly, you do not strike me as someone with enough experience with Gentoo to qualitately make any statements about whether or not you have to – or don’t have to update a package, profile, or system.

    Your last statement directs me to take a look at a couple of the comments here and at the Gentoo forums… Well, what exactly is that supposed to tell me?

    That ALL people who do not run “routine all encompassing updates” end up with “catastrophically broken systems?”

    Or is the truth closer to being that some percentage, some fraction of Gentoo users that did not run “routine all encompassing updates” had issues? And that because they had problems they reached out to the Gentoo forum or dug and google’d around to find other people who had the same problem?

    Just because you can’t do it – and these people can’t do it, doesn’t mean it cannot be done.

    In closing, though it is true that some of the things I have said, others have already said – you miss the point that I actually support some of your statements and do some explaining as to why I do. And I also support some of the other statements and again, explain why I do.

    You are correct in saying that Gentoo has a short life cycle that does not lend it well to production server usage.

    But you are dead wrong in making any statements as to what it can, or cannot do, as you are simply not qualified in this area.

    I make no statements about your abilities with other distro’s or with the BSD’s – simply about Gentoo.

  11. Lewis says:

    By the way, Hosh’s experiences with having to build things from source (source deb’s, source RPM’s, etc.) on various flavors of RedHat, Debian, and Ubuntu underscores what I am talking about with the dependencies.

    It’s hell all around – but Gentoo offers the most flexibility in running the newest (or older) software and in working out the dependencies based on your needs.

  12. Lewis says:


    One last thing – good luck with the company. Just took a quick look. No hard feelings.

  13. Dear Lewis,

    Thanks for your support of our company.

    I’ll be the first one to admit that I don’t have a lot of time to read comments, and I apologize if I glanced through your comment too quickly and missed any important details. None the less I think my answer was relevant, and I’ll try to let you know why.

    First of all, I think you might be approaching my article from the wrong perspective. In many parts of your comments you allude that because I don’t know everything about Gentoo, I’m not qualified to write about it. But like the introduction says, the article is written from the point of view of a FreeBSD user who gave Gentoo a first spin. The article is relevant for people who contemplate using Gentoo for the first time in a server environment and, conversely, this article is not meant for people who already are Gentoo experts.

    For example, you write,

    “Just because you can’t do it – and these people can’t do it, doesn’t mean it cannot be done.”

    I would propose that, despite your assertion that I have no brain, the intended audience of this article is no more likely to know these things than I am.

    You also write,

    “And as for “context…” Did you entirely miss the logic involved? … Those are IF/THEN statements which imply that there is a choice. In that little bit of text it may not go into detail as to how you can overcome the necessity of upgrading – but it still remains that this option is there.”

    I did address your if/then statement by saying the ‘if’ will occur by necessity. I then described why your ‘don’t upgrade option’ is in fact not an option for the average user. Thus I argue that this ‘if’ can be disregarded in the general case. You will always want to update other packages frequently, and many here and elsewhere support this point. Thus your statement can be rewritten as,

    “[Since] you want to update other packages, then…”

    Therefore we can look at the ‘then’ in isolation. Ultimately your ‘then’ is this:

    “IF … THEN be sure to update your configuration files. All of them? Yes, that only makes sense, doesn’t it?”

    And we’re thus back to the point in my original article. Is this a desirable situation? I say it is not for a server. Your updates should be limited to what you change.

    You say you can limit the amount of change you have to make if you’re an expert. That’s fabulous, but if you’re a Gentoo expert, why’re you reading an article about using Gentoo for the first time? Again, you’re not the intended audience.

  14. Lewis says:


    Nope, you’re right. For the intended audience – “new gentoo converts” so to speak – your stance on using Gentoo for a production server has merit.

    And I don’t remember saying that you did not have a brain – just that you did not know Gentoo.

    Lastly, you’re still missing the fact that I actually have maintained support for your premise that Gentoo is not a good distro to go with on production servers.

    I just wanted to make clear to anybody that was reading along, that the things you say cannot be done – can, in fact, be done – IF one wants to learn how to do it and has the time.

    Otherwise, push button distro’s have the shortest learning curve.

  15. Bob says:

    I’ve been using Gentoo since LiveCD 1.4 (2003). I’ve been running it on workstations and servers. It does what I want. It does it reliably. It’s as bleeding edge as you want it to be.

    As for whether or not it should “be on your server”, I guess the question is, “What are you serving?” If you’re serving LAMP, it’s fantastic. If you’re trying to serve some vertical application certified for RHEL 3, then YMMV.

    Typically, I’m running my servers as virtual machines in VMware or Parallels. So, my servers tend to be single function. If you’re trying to be an “everything to everyone” kind of server, then a push-button distro might be better.

    As for reinstalling your server, why? Gentoo continuously upgrades. Just change your profile. Yes, moving from 2.4 to 2.6 was a little tough. But that would have been pretty scary from a push-button standpoint, too.

  16. ChaosRequiem says:

    Of course another thing to consider (at least from my unconventional setup) is the bandwidth. 56k and constant updates are not pretty. I’m currently using Slackware 11 on everything. (Ironic, same OS for both network backbone/security, and graphics work.)

    Hopefully if our connection gets upgraded next week due to shifting service areas… it still begs the question. Bandwidth spent updating servers is bandwidth not spent doing what they are supposed to be doing, no matter what OS/Distribution.
    Touchy hardware aside. My current internal server at our little start up qualified as a toy in 2002… Good enough for dialup and internal DNS.

  17. JD says:

    Sadly, i sort of have to agree with the autohr on the base of the article, but i have a different point to bring up…There’s one big reason Gentoo wouldn’t be good for a server and that’s the fact that essential packages constantly updating (there’s never a “stable”) and if anything happens to bork the system, your server is down and most servers can’t afford that much downtime of having to find and fix the problem.

  18. John Ward says:

    hmm.. i have 13 production servers running everything from jbos to mysql and backup admin stuff. All running on Gentoo.
    At worst, i’d say it takes me 2 hours (in between meetings) to get a raid server going.
    It takes a full 20 minutes to install a fresh machine off tape ;) i really do think a bit of RTFM is required ;)

  19. Crustybum says:

    Wow, this article shows up on google when searching for various Gentoo-related things.

    Unfortunately, the article smacks of ignorance and lack of forethought.

    First, nobody in their right mind should be installing a source-based, compile-everything OS on old hardware. If you really need to run old hardware that is lacking in the power to be any kind of compile platform, then don’t run Gentoo, Sourcemage, or anything else that requires considerable compile time. You’re just setting yourself up for frustration, and that’s not the distribution’s fault.

    Second, Gentoo has a nasty perception of being a ricer distro, but that perception doesn’t continue to need to be propogated. The Gentoo documentation doesn’t encourage people to setup psychotic compile optimizations, so anybody coming in new and just following the docs shouldn’t be attempting to do so.

    Last, in any production environment, if you’re really serious about providing 100% service uptime to people, not only do you setup redundancy so that a problematic system update doesn’t actually disable service, but you also test each and every software update you do before rolling it out on a production machine – binary distro or not. If you don’t, you’re playing with fire whether you trust the OS or not. FreeBSD, RedHat, Windows, whatever, you don’t just blindly hope your updates don’t take out services.

    You may want to seriously reconsider re-doing this article. There’s a lot of mistakes in your methods that lead you to come to your conclusions.

  20. I think you misunderstand what I was trying to do here. I was trying Gentoo out. For me it makes more sense to use old hardware for that, rather than taking out hardware I actually need for anything.

    A lot of people have said that redundancy is the answer. This is true to some extent, but I would much rather have a system less prone to breakage with or without redundancy. Even if you have a staging server for setting things up, you’ll be much better off if things work more often than not. What’s worse, even with a staging server, you’re ‘playing with fire’ as you put it. You plain may not notice breakage the latest updates introduce before you move them from the staging server to the production server. As any software developer will tell you, you can never debug anything to a hundred percent.

    If you think Gentoo requires two servers for a production environment, you would still be better off using two RedHat Entreprise servers or two FreeBSD servers. If your redundancy halves your risk, or even brings it down to a tenth, you’ll still be better off with less base risk.

    This article has had several people agree and several people disagree. Therefore, even if the opinions expressed in the article were the complete opposite, there’d be people asking me to rewrite it. You’ll understand if I’ll just let it stand as is and let people draw their own conclusions based on the data presented.

  21. anonymous says:

    [Deleted due to language.]

  22. kRAkEn/gORe says:

    i’ve run redhat, suse, and gentoo servers and i can assure you that updating a profile is much less error prone than update some packages in a redhat server. i’ve had more problems with redhat system failure after a global system update than gentoo.
    yeah gentoo is time consuming, and it requires you to be careful. not for all the push-button servers lovers :)

  23. required says:

    i can understand your points, but i don’t think they are necessarily deal breakers to use gentoo. i feel you have a bit more control of what you are doing with gentoo, and end up with a very minimal installation of what you need.

    if you do not want an upgrade, you can mask that version. granted the install may take a while, depending on your hardware. i think since 2004.0, gentoo has come a long way, and is definitely a contender.

    you have a lot more control with gentoo than you are giving credit to. i think it might take sometime to know, but in the end, its very slick.

    maybe it comes down to a choice.

    i don’t think gentoo is an update everything. you can be mindful of what by adding ur pv flags to see what versions would change if they do.

    i don’t think gentoo is necessarily bleeding edge. you could choose that route, and possibly have a broken machine. the community is rather large, and you have a dedicated group of testers, who will put up to the head arch dev/tester to add to the particular stable flag.

    i’ve been a gentoo user for a very long time, and i have my gripes, but i don’t think i would choose anything else over it.

    its not as broken and cumbersome as ur original article has stated it to be so.

  24. riaan nolan says:

    On the contrary, I only use Gentoo for servers. It’s the most secure, stable server OS that I have ever worked with. Yes updates can brake things, but that’s why you have a development server to see what changes first .. at least you should have such a strategy in my opinion.

    Gentoo Rules!
    star@flyer star $ uptime
    11:28:14 up 739 days, 22:30, 1 user, load average: 0.00, 0.00, 0.00

© 2006-2009 WireLoad, LLC.
Logo photo by William Picard. Theme based on BlueMod © 2005 - 2009, based on blueblog_DE by Oliver Wunder.