Gentoo Linux Cancels Distribution:
Instead, Gentoo developers said they are pushing a new model for their distribution — one that eschews the conventional release wisdom used by Red Hat, Novell, Debian and others. Instead of fixed releases, Gentoo is promoting its vision of a live, continuously updating distribution. In practice, that effort revolves around its weekly minimal images, which are then supplemented with customized installed packages.
Continuous OS releases are an interesting idea. One of the annoying aspects of OSes is that every few years you have to go through a big upgrade cycle, as a vendor stops support for version X and forces you to version X+2. For my organization these upgrades haven’t been a problem because you can do the OS upgrades with the normal hardware replacement cycle, every three years or so as leases run out, etc. Now that virtualization is taking over we won’t have the same chance to replace the OS, though. Being able to upgrade the OS more easily and often sounds like a great idea.
The problems with continuous OS releases, though, are numerous. First, application developers are going to hate this. They don’t want the underlying OS to change, ever, and to have it changing constantly means a lot of trouble to them. Time spent testing against new OS releases is time not spent making their software better. That goes double for vendors who have to support things running on these OSes. How do they test & certify their software, hardware, and/or procedures against a constantly changing OS? It would be hard, especially since open source projects already have a terrible time with compatibility issues & QA. Last, all these issues apply to system administrators, too. Instead of having two or three operating environments to track you have the possibility of an infinite number of them. Admins will need to superimpose the old system of releases on top of these continuous release models in order to get any testing done, just like we do now with patch management.
Instead of continuous releases, perhaps a better solution is to make the upgrade process between releases much easier, cleaner, and seamless. It would also help some vendors to do more frequent releases (five years between Windows releases is a long time, for example). Red Hat releases new Enterprise Linux versions every two years or so, and supports them for seven years. Two years is a nice interval, and offers a controlled, regular opportunity to add new technology. If they’d make the upgrade from RHEL 5 to 6 (or 7, or 8) seamless we would get all the benefits of continuous OS releases without all the support problems.
That’s the sort of upgrade feature I’m hoping for, something as easy as a “svn sw” command for my OS.
Comments on this entry are closed.
Conectiva (brazil RPM linux), in the years before they were picked up by Mandrake, appeared to put a lot of effort into testing their OS upgrades. The goal, as I remember, was to enable upgrades over major releases with the same mechanism – apt-get upgrade – that they used to update the regular RPMs on the box.
From the little I tested it, while doing my unitedlinux work, I thought it worked perfectly. I enjoyed the idea that I could go from 3.0 to 3.1 or even 4.0, withint he bounds of a standard package upgrade.
Since you mentioned SVN, you may want to check out another Linux distro I fell over the other day. Conary linux uses a SCM-like approach to package/software management, and it looks pretty slick. Don’t know if it crosses major rels well, but it certainly brings a versatile interface along for those of us used to checkouts and merges.
– b..
Debian and Ubuntu Linux both support ‘apt-get dist-upgrade’ after changing your target release in /etc/apt/sources.list. Ubuntu automates even that with the ‘do-release-upgrade’ command and an automatically-generated motd that advises of patch and upgrade-release availability.
Continuous release has been the BSD way for a long time now, with quite a few users mirroring the -CURRENT tree with CVS or another SCMS and compiling world locally. Continuous releases are the new state of the art for the Chrome browser and many mobile apps as well.
To adapt, developers need to adopt continuous integration — for their apps in maintenance mode at least, even if the teams aren’t fully agile yet. The second part is automated regression testing in QA. Lastly, devs and ops still need to know the target API/ABIs, which usually means target platforms. Because current releases of RHEL-family and Debian/Ubuntu-family Linux ship Tomcat6 and OpenJDK 1.6.x, for instance, that is the preferred target programming environment even though Tomcat7 is available in ‘production-quality’ releases.
Trying to freeze a platform in place is a strategic mistake at this juncture. That’s how we end up with ‘critical’ production apps running on seven or ten year old OSes that went out of support years ago and aren’t getting patches for security, bugfixes, or hardware.