I wasn't necessarily referring to security updates. I was referring to core service subsystems, like webservers, caches, databases, Java VMs and the like. Most large, mature companies I've worked with (who were all core web properties) maintained their own versions because they had enterprise needs that required specific functionality beyond what the basic packages could provide. Sometimes they tune the code itself with custom patches to fix bugs or improve scalability.
If you're betting your business on this software and are operating at scale significantly larger than the typical Web service, odds are you're not going to live on the distro-provided packages for very long.
Re:Linux 3.7 released
by sliverstorm on Tuesday December 11, 2012 @08:42PM
(#4908137)
It can work out O.K. if you stick to patching srpms of the official releases. For example, in the past I've needed to patch performance fixes for RAID cards into the kernel. When set up carefully, this is easy, repeatable, and has minimal impact.
If you care about taking advantage of prompt security updates from your distro provider, you will do this as little as you possibly can. Otherwise you need to pick up that burden yourself, and since most of us aren't security pros, it is a weight that should be assumed with great reluctance. You're no doubt familiar with the dilemma: Are you going to attempt to maintain stability (which isn't at all guaranteed) by backporting patches, or annoying your ops people by forcing version upgrades?
To a certain extent, how bad this gets is a function of how out-of-date your distro is. This is where having packages that are 4 years old can bite you -- you end up rolling your own far more often than you really should. Overuse of tools like virtualenv leads to the same problem.