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.