probably saved our department the equivalent cost of a shiny new sports car.

Or all cpu’s:
./check_sa.pl -i -C %user -C %nice -C %system -C %iowait -C %idle –sa-log-dir=/var/log/sa –sadf-options “-P ALL -u”

Etc.

The advantage of this is that you significantly increase the speed of the check. With just -u it is ‘real 0m0.088s’, and -u -P ALL it would be ‘real 0m0.191s’. With -A it is ‘real 0m0.356s’. When checking 3000+ servers every little bit helps .

On Linux, you can choose just how much you want to maintain yourself vs let the system maintain, which means you can minimize this type of pain.

Note that I have supported various commercial packages on Debian systems without a problem either. Debian doesn’t remove old sos on upgrade unless requested, so things don’t break, even across major upgrades, even when they have very odd binary dependencies. I have libc5 gcc 2.8-specific C++ x86 binaries that still work, no effort required.

Contraily, with a system like FreeBSD or Solaris, the pain is typically entirely upon the local administrator to deal with the most recent apache problem.

I can’t tell you how many times as a commercial software vendor I’ve had to drop everything to deal with some major incompatability introduced by a minor update from a proprietary unix vendor, even though they insist that they’re always ABI compatible. Typically these are situations where you can claim the external symbol signatures haven’t changed, even when the behavior, location, environment variables, or other aspects have.

As a proprietary software vendor it is easier to support Linux systems than any other unix. That includes all the flavors. Really.

If everything you run comes from a package that’s tested by the vendor, and you’re upgrading from one compatible package ecosystem to another, and your config file formats don’t change, your upgrade should work just fine (though results may vary in the wonderfully fragile world of Red Hat). That, however, has absolutely nothing to do with the argument, because that’s simply not the way that the world of proprietary software on commercial UNIX distributions works. The vendors don’t run in lock-step with your operating system, and they don’t provide special repositories so that the Etch version of their software is replaced with the Lenny version when you upgrade. (In fact, you’re remarkably lucky if they even support anything besides Red Hat or SUSE at all.)

As a Debian guy, you’re probably more used to the FOSS side of the spectrum, so let me just use a generic example from that arena. Say that for whatever reason, you’ve compiled a local version of PHP against OpenLDAP 2.3, and your distribution decides it wants to start using OpenLDAP 2.4′s ABI/soname-incompatible client libraries instead. You upgrade, and suddenly you’ve introduced a problem for yourself if you haven’t made a habit of specifically linking against a ton of your own manually-tracked dependencies, because your libldap2-3.so.0 happens to not exist anymore. You now need to hunt down and re-link all of your dependencies, some of which may not be apparent until certain edge cases during run-time are encountered and a handful of DSO’s are loaded on demand and your programs begin mysteriously crashing because they’re trying to call externs that don’t actually exist.

Thankfully, we haven’t had ABI changes the size of libc5->libc6 in many years, but it’s absolutely conceivable that an upgrade can break a great many things if you rely on the fact that system libraries are going to stay one particular ABI version between releases.

I’ve had Linux systems seemlessly upgraded across versions of Debian for over 7 years without service interruption. This includes production systems providing live services. People do not reformat instead of upgrade.

You need to be 100% confident that your HA features work. Otherwise, what’s the point of having them?