Chatting with some of my friends the other day, we were lamenting the fact that there really isn't a 10-year Linux. Red Hat will sell you long term support for almost any version you're willing to pay for, but for the most part, when it comes to long term support for a Linux kernel and distribution release, you're looking at 2 to 5 years of support, max. And, yes, this is the sort of thing I talk about with my friends over soda pop. We're nerds.

Couple that with the fact that the release cycles themselves factor heavily into your decisions, and you've got a recipe for a rather small pool of possible Linuxes to use. You can't use Debian, because their release cycle is glacial. You can't use Ubuntu because their release cycle is break-neck. Is there room for a Linux that is released once a year, but each year's release has all security patches and bug fixes ported to previous versions?

And the short answer, we decided, is no. But this isn't because the market is moving away, or has already decided to stick with Red Hat, Suse, or Oracle. It's because we're all doing it wrong.

In 2003, you didn't want to touch the OS layer. Your app worked on a single instance of an OS, and it ran on a specific version, due to some requirement, or compatibility issue. But today, that whole paradigm of sticking with an old system to avoid change is rather wrong headed. When it comes down to it, if you're building a Web application, you really don't need to worry about the OS layer too much. Certainly, realtime and high availability systems still need to be concerned with this issue. But for the vast majority of applications, I'm convinced that the long-term problem is going away.

The days of a Linux kernel patch breaking your application should really be behind you. When it comes right down to it, it's the items in your stack over which you should be executing version control. The right versions of the right libraries and components are still essential, and likely will be for years to come.

But the actual OS you're using should be getting more and more irrelevant. The OS is just the container for your application, and considering how stable modern operating systems are, you should be able to contain that application indefinitely, barrring any unforeseen bugs or glitches in the OS layer.

Of course, things aren't playing out like this quite yet. Obviously, moving to a new release of Linux the day it comes out is always going to be a bad idea. But as our applications become more and more modular and transportable, thanks to platform as a service and other cloudy innovations, the OS they run on should become less and less relevant.

So, we're now drawing a line in the sand. If you're worried about upgrading an OS that's below a Web or mobile application, you're doing it wrong. Realtime, embedded and other complex and high performant system designers, you're still doing it right. We'll check back in in a few years to see if, in fact, this is a trend.

And, of course, the inverse of this whole blog entry seems also to be true: as the OS layer becomes less relevant, there's less reason to upgrade it, ever. If it works, you might as well keep that virtual machine and disk image in its present state forever. Unless, of course, you have to update something.