On 07/26/2011 01:32 PM, R P Herrold wrote:
> On Tue, 26 Jul 2011, Mike Burger wrote:
>
>> If IBM can make this happen for their OS, and Red Hat certainly supports
>> such a process in the Fedora line of releases (including the ability to
>> list additional repositories for remote installation as part of the
>> process), they could certainly make it a supportable option for the RHEL
>> line.
>
> The upstream supports nothing as to Fedora, and indeed,
> members of that project regularly (and seem to gleefully)
> break forward compatability
>
> But you are missing the point -- WHY spend the engineering
> effort on trying to support such Major 'upgradeany's? A new
> deployment takes mere minutes for a commercial shop, and by
> NOT supporting such explicitly, the upstream avoids much
> support and engineering load.
>
> [I say this having done an 'upgradeany' and run into a later
> 'nss' in C5 than the C6 initial media provides, that required
> some head scratching, and a nasty workaround, to solve over
> the weekend]
RPH is definitely right about "gleefully breaking forward compatibility".
It is easier to control compatibility backward and forward when you're
deploying a closed (or at least tightly controlled) system as opposed to
one that boils with change the way the Fedora upstream does.
Example: systemd
Find a way to make a transition from 6x to 7.0 seamless by way of a
simple "yum update" once SysV init goes away and all system services
must grow configuration files and drop init scripts. That's just one
subsystem, there are other huge changes as well (Gnome3...).
IBM and the tightly controlled (and decades long) OS/360 -> z/OS process
or their linear passes through AIX Ver.n -> Ver.n+i do not compare to
Red Hat's situation. Anyway, compatibility is often complex enough for
IBM to address by quietly including emulators for their previous systems
instead of shooting for base compatibility.
The key to Red Hat's success has been its hands-off approach to the
Fedora Project. If Red Hat ever desires to implement something they must
first present working implementations for acceptance by FESCo -- which
implies promising, working implementations. This forces a lot of unique
situations, but the primary effects are:
* Advances occur at a rate difficult to compare to other projects
* Entire subsystems can be marked "obsolete" if a working
implementation demonstrates superior function (systemd ousting the
venerated SysV init is an example of this "nothing sacred" attitude)
* Technical debate about anything/everything crosses company, private
and personal lines in ways difficult to interpret from a traditional
development perspective
* The chaos level is high (marked by the inability for any one person
to be an expert on everything at a given time -- by the time one thing
is thoroughly understood something else has changed)
* Absolute forward and backward compatibility requires too much
effort, so the concept of "compatibility" moves up two levels to the
data layer[1]
IBM, on the other hand, has a long-term compatibility program they
consider to be at the core of their business model (System/360 history
is interesting here). They plan their changes around a few subsystems
they consider to be sacred. If you want to change something sacred you
have to plan it out through the high priest in charge of that subsystem
-- and it is acceptable for major system changes to take several years.
The whole thought process is entirely different -- as are their target
markets. Red Hat is a good value for large- to huge-sized businesses,
and IBM is a better value (sometimes with a mix of Red Hat in some
areas/departments) for titanic- to ZOMG-sized businesses.
I apologize for the long message. I didn't have time to write a short one.
-Iwao
[1] I've been thinking about this a bit and I've come to think that
there are roughly three layers to compatibility -- so I'll define them
here since I referenced my own definition:
1- Absolute forward and backward compatibility. Code builds and runs in
exactly the same way on any system in the series.
This is the level IBM shoots for. System upgrades and downgrades are
clean, reliable and easy to recommend and support.
In Linux terms this would mean you could load, say, RHEL 3 and "yum
upgrade" to RHEL 6.1 -- whether that is through a yum-initiated upgrade
chain or a one-step upgrade is of no concern to the user.
2- Configuration compatibility. Implementations change in radical ways,
but the interpretation, format and semantics of configuration files is
absolutely respected between versions and often between competing
implementations of a single standard. OpenLDAP's move to cn=config while
retaining the ability for slapd.conf to be read and converted to a
cn=config loadable set of LDIFs is an example of this.
This is roughly what Microsoft used to aim for (somewhere on the road
between XP and 8 they seem to have totally quit the idea, though).
In Linux terms this would mean you can copy things like /etc, /var and
/home/~/.* and add the contents to whatever new is in the upgrade and
not endure any major shocks.
3- User data compatibility. Config files might change, because entire
subsystems might evaporate or be replaced. Converting between radically
different concepts (Gnome 2 to 3 with gconf to dconf, for example) means
that finding enough logical parallels to define a user/upgrade friendly
automatic conversion tool is at least as difficult as developing the
replacement system was in the first place -- and therefore an
unrewarding level of effort. User data, on the other hand -- being the
actual media, business files, whatever, are considered sacred, however,
and the system must be able to support loading the old media onto the
new system. Universal support for ODF, import support of database dumps
between PostgreSQL versions or MySQL to MariaDB, universal image
formats, JwCAD .jww export to .dxf and import to LibreCAD, mbox, etc.
are examples of this level.
This seems to be what Red Hat considers acceptable.
In Linux terms this means that you should be able to copy /home without
the dotfiles and a lot of /var (or /var-type things, depending on how
you're set up) and not be surprised by the result.
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
