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.