How to Obtain older distributions

[jcstarman]

I just been given a project to compile code to run under Red Hat Enterprise Desktop 5.3.

Does anyone know if Red Hat sells older versions of Red Hat Enterprise Desktop? RHEL 6 was just released last month. As I understand it, code compiled under RHEL 6 will probably not work under 5.3 due to difference in glibc.

Can I compile code using a Fedora distribution and run the code under Red Hat Enterprise Desktop 5.3 without recompiling the code? If so, does Fedora offer older versions of their distribution?

Thanks...

[Irithori]

from https://www.redhat.com/apps/store/desktop/

A Red Hat Enterprise Linux subscription is not version specific. Once a subscription has been purchased, customers have access to currently supported versions (4, 5, and 6) based on the Red Hat Enterprise Linux Life Cycle.

Also: Always develop in the same environment that the target offers. ie RedHat/CentOs 5.

On a sidenote:
Although rh5 is supported for the next years and thus a reinstall with rh6 is not neccessary, it might be good to update to 5.6.

[Rubberman]

This is where virtual machines are very useful - you can install an older/newer Linux distribution in a VM than your host is running. Then, you can run applications in one that won't in another, and by analyzing the errors/differences between versions of a program on the systems, you can start to understand the issues involved in designing and developing a program that is not only linux version-neutral, but that is properly cross-platform capable. I have been designing and developing software for multiple operating systems (and versions of operating systems) for many, many years. It isn't easy to do right, but software that I have designed can build and run identically on any processor, operating system, and OS version available, from Windows to Solaris to SunOS (pre-solaris) to QNX to Linux to HPUX to True64 Unix to AIX to SysV to BSD ... These are application systems and development frameworks (n-tier client-server peer-to-peer) that are comprised of 10+ million lines of C and C++ code.

So, yes you can build/run a block of code on most any system, but getting it to do so is difficult and takes a lot of planning and consideration for differences between the systems. One good example was that we needed a non-colliding string hash function that would operate identically on 32-bit, 64-bit, big-endian, and little-endian architectures. IE, the generated hash value had to be the same. Sounds simple? Not so. Depending upon whether the system was 32 vs 64 bit and big vs little endian meant that bit of code had to be appropriately conditionally compiled. When one of our teams was targeting a new architecture, this failed our system testing. They didn't add the appropriate conditional tests for the new system (I think it was True64 Unix running on a DEC Alpha 64-bit processor). Since the hash was used to generate a salt value for password encryption, none of the passwords so encrypted would succeed in authenticating database access. Oops.

Then there are API changes between significant OS version upgrades. Fortunately, most of the standard API's are not so fragile, but an application that has been built to use shared libraries on one system, may not work on a newer version of the same system. If you want an application to be somewhat more resiliant to this sort of issue, build your software to use static linkage instead of dynamic. That will often server to eliminate DLL versionitis, but it won't always mask kernel and ioctl differences.

So, back to your issue. As mentioned, you can still get RHEL 4.x and 5.x as well as 6. You can run them natively, or in virtual machines if you want to host on RHEL 6. That would be my recommendation. Then, you can build on one system statically (such as 4.x), and see if they can still run correctly on the newer versions. Personally, experience shows me that going from building on old versions to running on new versions works much better than building on new versions and trying to run on old versions. Backward compatibility is always easier than forward compatibility... or is it the other way around?