I maintain more than a fair number of Gentoo machines.
Not because we care for childish funroll-loops speed tuning. What we care about is the flexibility of installing precisely what we want, not every package feature and dependency that a contributor thinks we might one day want. We are perfectly comfortable with how Linux, compiling and libraries work. We don't want everything to be abstracted away from us into a black box.
You should choose to use what you feel most comfortable with. Here are some details that may help to allay your fears of Gentoo specifically.
Build times are relatively negligible on modern hardware. Even more so if your machines are of N+1 redundancy.
You can be picky about how portage behaves, such as placing MAKEOPTS="-l 1.0"
in your make.conf to ensure that new builds backoff when the load average is creeping uncomfortably high.
You can use binary packages from Portage if you'd prefer. The mirrors provide a number of common packages or you can roll your own with --buildpkgonly
.
If you have a large number of machines then you can benefit from having a nominated build host or distributed compiling.
The latest stable versions of Portage that are now in use are much more unlikely to leave you high and dry when performing upgrades. Tales of conflicts and blocks are pretty much a thing of the past.
If you are looking after so many machines that upgrades become painful then you should be looking at Puppet/BCFG/cfengine anyway ;)
Update in response to question edit:
Whilst I empathise with the situation you describe, it is not something that is symptomatic of source-based distributions or indeed prevented by using a package-based distribution. It is the result of:
- Your own natural unfamilalirity, and
- Your predecessor's poor internal documentation
Truth be told, I haven't extensively used any other Linux distros for quite some time now. For this reason, if you were to place a Debian machine (for example) onto my lap and tell me that OpenLDAP wasn't working after a reboot, then I too might spend 15 minutes or an hour to resolve the issue. Not because I don't have a good understanding of Linux or that Debian isn't a good OS, but primarily because I don't recall the intimate details of Debian's RC scripts or package system. This is why internal documentation is essential within an organisation. It should serve to jump-start the unfamiliar and to fill in the gaps of everyone else. Even if they do know everything.
Just a quick note specifically about Gentoo. Portage's USE flags are incredibly useful and "minimal" is something that I use frequently. I don't for instance want the server binaries of a package to be installed on a machine that will only ever be a client during it's lifetime. Having them unnecessarily present may increase complexity or even be a security concern. It's never an issue of space. You can see what USE flags and dependencies a package is going to adopt (and which it isn't) before it starts compiling by using the -av
arguments. So you shouldn't get an surprises.
GNUix> Sorry, snap!
Yes. The content is in the content database and will continue to be there. Basically, you won't have easy access to it.
You could try migrating some of the lists and libraries, including wiki pages for supported page layouts, not Enterprise Wikis. The best way to do that is probably with a 3rd party tool, however. And, if you're not spending money on licensing SharePoint, you probably don't want to pay for a migration tool, either.
Best Answer
You didn't say what you want to see when time passes and new versions appear. Suppose that a new version of the ~amd64 package appears - do you want to upgrade it (i.e. follow the new development) or just sit on what you already have (i.e., work around a bug in stable)?
If you want to upgrade your ~amd64 packages automatically to the latest unstable version, please add a line to your package.keywords file:
Otherwise, just mask all old versions using package.mask
The second approach will create warnings about unavailable packages, but will not attempt to downgrade anything.