One issue I've found is support for old releases. Ubuntu only has a 5 year support life cycle, where as CentOS / RHEL have a 10 year support life cycle. For most people this isn't an issue, but in the enterprise it definitely is.
I recently had to move a bunch of Ruby 1.8 applications (where it didn't make financial sense to upgrade them) to new servers. They wouldn't even run on Ubuntu 10.04, where as CentOS 5.5 is still receiving security updates.
But Ruby 1.8 is EOL. I also got some customers running Rails 3.0 with 1.8.7. I told them they have to rely on good luck not to be hacked and they also made the financial decision not to upgrade so they are running an unsupported language version on maybe an unsupported OS (can't remember which OS they're using).
Software Collections aren't "supported" in the same fashion that core RedHat packages are (i.e timely security fixes, backported if needs be, for the lifetime of the OS release).
From the ruby193 SCL page you linked to:
"Community Project: Maintained by upstream communities of developers. The software is cared for, but the developers make no commitments to update the repositories in a timely manner."
Yeah, if they are in CentOS land it will be a bit touch and go (as usual).
But if you have a redhat subscription they are fully supported. I should have pointed that out in my first comment though, thanks for bringing it up :)
"All Red Hat Software Collections components are fully supported under Red Hat Enterprise Linux subscription terms of service. Components are functionally complete and intended for production use. " [0]
If you really, really must have the latest and greatest of some package, you can always use the IUS Community's RPM repos for RHEL/CentOS (it's run my Rackspace for their servers).[1]
But, we're talking about enterprise here, no young hip startups. Enterprise wants stability over everything else, young hip startups want the new shiny.
There are huge amount of Java 1.3, 1.4, and 1.5 applications still running in Enterprise all around the world with zero issues. Most of the time it doesn't make financial sense to re-build or spend time debugging an upgrade just to have the latest runtime.
I understand to run Java 1.5, or better Java 1.6 but not 1.3 and 1.4 that's aweful. But I know that's a fact since I've used Apache Fop and they try to have a compatibility up to Java 1.3.
For me I've writing all my software with the latest Java, but I don't care which os (even RHEL 5/6 would work, if they could get java 8 to run)
Supporting everything down needs have so many more Lines of Code and is rareley harder to maintain / code. Especially Option Types and Java 9 + Java 10 brings your Java Code to a further level, I also don't get it why somebody would code a new project via J2EE if there are so many great servers like wildfly and netty.
Well, a Java 1.3 application isn't going to be a new application - usually a legacy application which has a lot of custom libraries built specifically for that version of Java, and would require significant effort to bring the codebase up to date in terms of running on a modern platform. At my company, one of our most used internal applications runs on 1.3 - it's an application which allows user-made plugins, however we don't have the source for the main application, which means we're stuck maintaining a 1.3 system.
As an aside, J2EE is quite good and very prevalent in enterprise, JBoss, GlassFish, Tomcat, etc...
Yes, it's not the best situation but is a lot better than it was before. Originally there were about 10 Rails 1 / 2 applications on a pair of machines running Ubuntu 6 and Ruby 1.8.4, with most services open to the world. These machines were being retired so the apps need to be moved off - a few apps were shutdown as they were no longer used, and the remaining each got their own VMs.
The apps were upgraded where possible but most of them had dependencies that would only run on Ruby 1.8 and have long since been abandoned. We considered rewriting them, but they are only used internally and are most likely going to be shutdown in the next year or so. At least the OS doesn't have any known security issues and is now properly behind a firewall, so that's something.
One of the issues with Ruby 1.8 is that it only compiles against OpenSSL 0.9.x. To compile it from scratch means you need to downgrade that (and a few other deps), which is about as painful as you can imagine. CentOS 5.5 still comes with that and is supported until 2017, where as you would need Ubuntu 8 or lower. I was thinking of creating a LTS version of Ruby 1.8 (a la Rails LTS), but I don't think the need is really there. Businesses who are running Ruby 1.8 have either weighed the risks or simply don't care :/
Yup, but RedHat commit to backporting security fixes for the duration of the release (so 30/11/2020 for RHEL6)... Not sure that this is the case for software available via any of the collections.
"All Red Hat Software Collections components are fully supported under Red Hat Enterprise Linux subscription terms of service. Components are functionally complete and intended for production use. " [0]
I can understand why enterprises need 10 year support for their server OS, but I would assume many of the third-party software running on that OS will not have a 10 year support period. This is not ideal from a security perspective.
Yep, I've still got plenty of RHEL 5 and 6 boxes running production public-facing services. I'll upgrade them probably within the next six months or so but it's simply not a priority at this point (even for the 5.x machines).
I recently had to move a bunch of Ruby 1.8 applications (where it didn't make financial sense to upgrade them) to new servers. They wouldn't even run on Ubuntu 10.04, where as CentOS 5.5 is still receiving security updates.