The base OS I don't find more stable, but the reliability of yum for Scientific Linux has been better in my experience. I've had real problems with the "yum-rhn-plugin" based yum access. For licensed systems, I inevitably set up an internal yum mirror with "reposync" running on one of the licensed servers and connected licensed servers to that as a local yum repository, tearing yum-rhn-plugin out on all the other servers. I also generally play some games to make some of the Scientific Linux packages available to the RHEL systems, especially the "yum-conf" packages that help provide EPEL or Repoforge access.
I look forward to when SL can provide a 7 beta or 7 release, so I can work with just that sort of open source add-on to the commercial environment. I evaluated spacewalk for a department at the BBC some years back, and looked at it again. So much of the work of configuring it and hand-tuning it to resolve package dependencies, or parallel instlaled packages like Java that are sensite to which major version you install first, that I reaslly saw no point to it. A simply audit tool, such as a nightly "rpm-cron" or "yum check update" report or Nagios alert, more than satisfied such needs with far less overhead, and with far more ability to script the operations. > The real 700 pound gorilla is systemd Yeah, it's going to be a bear rewriting init tools for the software my clients use. Systemd's most critical feature, the more robust daemon management, was accomplished more than years ago with the lightweight "daemontools" by Dan Bernstein. Unfortunately, the funky layout and the pecular licensing of daemontools prevented its inclusion as a default in any Linux or UNIX release. By the time Dan loosened the licensing, it was too late. It's a shame, really: it was a small tool done well, instead of the 700 pound gorilla you've mentioned.
