A lot of industries are semi-forced into it. Let me give you an example I know of first-hand. Modern SAP stacks support 3 operating systems. Windows Server, RHEL, and SuSE.
You’re probably thinking to yourself: “but rhel is just regular linux, surely you can install it on anything if you have the appropriate dependencies, I’ll bet it even just works on rhel-compatibles like rocky, alma, or centos stream!”
And you would be ~sort of~ right, but wrong in the most dystopian way possible. The installer itself does hardcoded checks for “compatible” operating systems, using /etc/os-release and a few other common system files. Spoofing those to rhel 8.5 or whatever is easy enough, but the one that really gets you is a dependency for compat-glibc-X.Y-ZZZZ.x86_64. This “glibc compatibility library” is conveniently only accessible via a super special redhat repository granted by a super special sap license (which is like ~$2,000/year/cpu). Looking at the redhat sources it is actually just a bog-standard semi-modern glibc compile with nothing special. The only other thing you get with this license as far as I can tell is another metapackage that installs dependencies, and makes a few kernel tweaks recommended by SAP.
So you can install it on alma/rocky by impersonating rhel in /etc/os-release, and then compiling a version of glibc and linking it in a special hardcoded location, but SAP/Redhat put as many roadblocks in your way as possible to do this. It took me weeks of reverse-engineering the installer to get our farm off of the ~100k/yr that redhat wanted to charge us for essentially:
./configure--enable-bootstrap--enable-languages=c,c++,lto --prefix=/usr--mandir=/usr/share/man--infodir=/usr/share/info--with-bugurl=http://bugzilla.redhat.com/bugzilla--enable-shared--enable-threads=posix--enable-checking=release--enable-multilib--with-system-zlib--enable-__cxa_atexit--disable-libunwind-exceptions--enable-gnu-unique-object--enable-linker-build-id--with-gcc-major-version-only--enable-plugin--with-linker-hash-style=gnu--enable-initfini-array--disable-libquadmath--disable-libsanitizer--disable-libvtv--disable-libgomp--disable-libitm--disable-libssp--disable-libatomic--disable-libcilkrts--without-isl--disable-libmpx--enable-gnu-indirect-function--with-tune=generic--with-arch_32=i686--build=x86_64-redhat-linux
Thread model: posix
gcc version 9.1.1 20190605 (Red Hat 9.1.1-2)(GCC)
definitely worth $100,000/yr… much capitalism, many line go up
I assumed that you could just run fedora and spoof RHEL. The fact that you need to use a specific GCC is insane. They must share their source code right? Or, are they no longer sharing it as they are legally required to?
The source to this compat library is in their sources last I checked, but because it’s not part of their standard repos it doesn’t technically have to be. I suspect this is eventually the end-goal.
But, like, is for support and stuff, no?
A lot of industries are semi-forced into it. Let me give you an example I know of first-hand. Modern SAP stacks support 3 operating systems. Windows Server, RHEL, and SuSE.
You’re probably thinking to yourself: “but rhel is just regular linux, surely you can install it on anything if you have the appropriate dependencies, I’ll bet it even just works on rhel-compatibles like rocky, alma, or centos stream!”
And you would be ~sort of~ right, but wrong in the most dystopian way possible. The installer itself does hardcoded checks for “compatible” operating systems, using /etc/os-release and a few other common system files. Spoofing those to rhel 8.5 or whatever is easy enough, but the one that really gets you is a dependency for compat-glibc-X.Y-ZZZZ.x86_64. This “glibc compatibility library” is conveniently only accessible via a super special redhat repository granted by a super special sap license (which is like ~$2,000/year/cpu). Looking at the redhat sources it is actually just a bog-standard semi-modern glibc compile with nothing special. The only other thing you get with this license as far as I can tell is another metapackage that installs dependencies, and makes a few kernel tweaks recommended by SAP.
So you can install it on alma/rocky by impersonating rhel in /etc/os-release, and then compiling a version of glibc and linking it in a special hardcoded location, but SAP/Redhat put as many roadblocks in your way as possible to do this. It took me weeks of reverse-engineering the installer to get our farm off of the ~100k/yr that redhat wanted to charge us for essentially:
./configure --enable-bootstrap --enable-languages=c,c++,lto --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared --enable-threads=posix --enable-checking=release --enable-multilib --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-gcc-major-version-only --enable-plugin --with-linker-hash-style=gnu --enable-initfini-array --disable-libquadmath --disable-libsanitizer --disable-libvtv --disable-libgomp --disable-libitm --disable-libssp --disable-libatomic --disable-libcilkrts --without-isl --disable-libmpx --enable-gnu-indirect-function --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux Thread model: posix gcc version 9.1.1 20190605 (Red Hat 9.1.1-2) (GCC)definitely worth $100,000/yr… much capitalism, many line go up
I assumed that you could just run fedora and spoof RHEL. The fact that you need to use a specific GCC is insane. They must share their source code right? Or, are they no longer sharing it as they are legally required to?
Anyways, RHEL is deep suck.
The source to this compat library is in their sources last I checked, but because it’s not part of their standard repos it doesn’t technically have to be. I suspect this is eventually the end-goal.
Finally… I found it… Evil Linux…
RHEL is subscription based. Not just support anymore. Also for product.
Don’t know what to think about it… 😬