To the best of my understanding, both Fedora and the coming CentOS are
beta (development/testing) environments, not stable production
environments, as is non-LTS Ubuntu. I know of many people who use Fedora
-- and more than once had bad experiences because of a software defect.
This is much less so on a proper production environment (EL or LTS).
There are for-profit proprietary vendors who have marketed what really
is beta as production, but the discussion here is for open source, not
proprietary closed source, software. As for the difference in supported
life-cycle between DEB and EL, this is more of a political/social (or
business/profit) decision than an underlying necessity for a stable
supported production environment. The biggest issue is that many of the
needed applications, including "systems" applications, require library
versions that do not exist for the older environments -- the amount of
"backporting" thereby required without introducing defects, including
security and integrity defects, may be prohibitive.
As for the RH and DEB designs having different update and upgrade (minor
and major new releases) philosophies for production releases, there is
no reason that a major upgrade should require a full reformat of, say, a
hard drive. For a concrete example, suppose one has an fsA partition
filesystem (I am using "partition" here in the generic concept of
segmentation, just as FAT generically means file allocation table, not a
specific proprietary Microsoft filesystem) and one wishes to move to an
fsB filesystem. Assuming adequate storage space exists, one
("superuser") may tar the fsA filesystem contents (including "dot" and
protected files) and then "un"tar into a fsB filesystem. Everything
should work unless fsB lacks a vital and used feature of fsA, say, "soft
links" or "too short file names". (Here fsA means file system of type A
-- such as EXT2.)
As for the difference in ISAs within a processor "family", if the later
ISA processor is backward compatible with the earlier ISA (e.g., an
X86-64 can "natively" execute IA-32 instructions, although an IA-64
cannot -- but Itanium (IA-64) essentially is a defunct architecture
today), then in principle, executables and libraries for each ISA (say,
64 bit and 32 bit) can coexist within the same operating environment.
Thus, a platform that is 64 bit should be able correctly to execute 32
bit instructions in a 64 bit monolithic Linux kernel (in a microkernel
system, the conceptualization of the matter is more direct), and 32 bit
software applications should coexist with 64 bit applications -- with
the (super)user determining when a 64 bit release of an application
should be deployed (assuming that the application is available for the
64 bit environment).
Assuming adequate storage (disk) space exists, an upgrade should proceed
in place unless the system (platform) has a catastrophic failure (e.g.,
no electrical power) during the upgrade. Thus, there is no intrinsic
reason to demand a full reformatting of a drive -- assuming that the
platform architecture maintains backward compatibility.
On 12/22/20 2:49 PM, Jon Pruente wrote:
On Tue, Dec 22, 2020 at 4:45 PM Dave Dykstra <d...@fnal.gov
<mailto:d...@fnal.gov>> wrote:
Fedora releases are much shorter life and I've heard there's a tool
there to upgrade between releases more seamlessly, although I haven't
used it myself.
Release upgrades of Fedora are fairly painless. I've got one server that
I inherited from a co-worker. It started life at Fedora 18, and it's
been iterated up to current Fedora 33. There were some config changes
over the years, but nothing that completely broke the whole system.
