On May 10, 2016, at 4:12 PM, Valeri Galtsev <galtsev at kicp.uchicago.edu> wrote: > > On Tue, May 10, 2016 3:57 pm, Liam O'Toole wrote: >> On 2016-05-10, Valeri Galtsev >> <galtsev at kicp.uchicago.edu> wrote: >>> >>> 1. Debian (and clones): you keep the components of the system pretty >>> much on the level of latest release of each of components. Therefore >>> "upgrade" to new release of the system is pretty close to just a >>> regular routine update. >> >> You are describing Debian sid/unstable, which is contunuously updated, >> and where there are no releases in the usual sense of the word. Debian >> stable releases are a different matter, and correspond very closely to >> major releases of RHEL/CentOS. There is always an upgrade path between >> consecutive releases of Debian stable. > > Yes, LTS, thanks Liam. Only LTS has life cycle of mere 2 years, whereas > RHEL (hence CentOS) is what, 10 years? “LTS” is an Ubuntu term, not a Debian term. Debian and Ubuntu are very much not the same thing. I point this out not to be pedantic but instead because there are *two* OSes here that both manage to have straightforward automatic upgrades between major releases. And in fact, more than two. This isn’t just about RHEL vs Debian and derivatives of same. Several major non-Linux OSes also manage to do automatic upgrades between major releases: Windows, OS X, FreeBSD... Take FreeBSD for example. Its freebsd-update tool will do this, and it’s mostly automatic, even in the face of changes to core OS files. (e.g. /etc/services) It can even merge changes to a core OS configuration file with your local version in certain cases. Or, it can just open both versions in a text editor and wait for you to merge them manually. Why can’t there be a rhel-update tool that does the same? Your point about the 10 year support cycle for RHEL is also invalid. The time spacing between major releases is only about every 3 years, and that is the period that matters here. That is to say, I would not expect an automatic major upgrade tool for RHEL to let me jump straight from version 5 to version 7 just because RHEL 5 is still receiving security updates. The tool only has to be able to upgrade from the prior major release. This is a solvable problem. Red Hat just doesn’t want to solve it. Why? The upgrade doesn’t have to be perfect. It could break everything except the filesystem and SSH and still allow manual recovery. Even in that extreme, you’re still no worse off than today, where you have to migrate everything by hand. It is actually an uncommonly good time to make such a tool, with the shift to systemd behind us. Unit files are far less likely to cause problems in an automatic upgrade than Bourne shell scripts that source piles of other Bourne shell scripts. An automatic upgrade from RHEL 7 to RHEL 8 should be much safer than RHEL 5 to RHEL 6. Another big shift also plays into this: VMs everywhere. In the past, an automatic major OS version upgrade wasn’t as useful because by the time you wanted to do a major OS upgrade, the hardware was ready to be replaced, too. RHEL’s policy of keeping the past two major versions under support helped, a lot: if the hardware is still doing what you need it to, you could skip a major version, after which the hardware is probably about ready to fall over, if only because the CPU fan is about to seize up. In that world, you could do the OS upgrade and the hardware upgrade together, since you need to migrate the data and services over manually anyway. VMs are changing that. The longer that shift continues, the bigger a problem this missing feature will cause for EL shops. And that probably takes us to the real reason Red Hat doesn’t want to solve this problem: the requirement to support automatic major version migration wouldn’t have allowed them to throw Xen into RHEL 6 and then pull it right back out for RHEL 7. I think Red Hat *wants* the freedom to break core OS facilities between major versions.