Felix Windt wrote:
> That is most unfortunate as the server distributions in particular often
> ship software several versions out of date for security or stability
> reasons, which can result in feature loss or unfixed bugs - RHEL 4.5, for
> example, still has Ruby 1.8.1:
> 
> # ruby -v 
> ruby 1.8.1 (2003-12-25) [x86_64-linux-gnu]
> # cat /etc/redhat-release
> Red Hat Enterprise Linux ES release 4 (Nahant Update 5)
> #

Feature loss? Maybe. Unfixed bugs are rare in an enterprise OS like RHEL
4 or its rebuild, CentOS 4. Keeping an enterprise server bug-free and
secure, at least for known bugs and vulnerabilities with known fixes, is
as simple as firing up a command line or one of the GUI package update
tools and saying, "Do it!"

Well, on Red Hat, you have to buy the service. :)
> 
> Depending on your environment, this may be impossible to circumvent - in
> shared server environments, you may not have the necessary permissions/tools
> available, at work policies or SLA requirements may prohibit any custom
> installations. At my job, we only use Ruby interally to the engineering
> group, so we can get away with customization. If it were used in production,
> we'd be using whatever the official channels provide as our SLA states
> having to stay 100% within vendor supported options.
You've just described the fundamentals of IT anywhere. Just about
everyone knows this stuff. It's when developers forget that their
audience is looking for stability that bad things happen. Fortunately,
test-driven developers can get new functionality out faster in the long
run, which is a win for both IT and the developers.