I fully agree.  The security-against-compromise integrity of up-ported 
"SL7" using C++n, for some n > n(RHEL 7."latest or last" distro) 
requires "professional" re-evaluation, penetration testing, and 
monitoring.  Will this be done?  I too have run into the same issues 
with backporting, and for that reason switched to Ubuntu current LTS 
(for now).  As for IA-32 support, this will be a larger issue -- 
particularly as much basic research without the possibility of a 
profit-driven product (e.g., a vaccine because of public funds being 
expended for basic research into biology and medical science, both human 
and non-human) is heavily underfunded; hence, your reference to using 
hardware obsolete but fully adequate systems for which current release 
software is becoming increasingly scarce.

For the Apple Mac community:  as is known, Apple is leaving the X86-64 
platform for an ARM platform.  Will older applications be updated, or 
will new (and in some cases, newly licensed-for-fee) applications be 
required?

On 12/14/20 11:55 AM, Konstantin Olchanski wrote:
> On Mon, Dec 14, 2020 at 02:36:20PM -0500, Serguei Mokhov wrote:
>>>
>>> I have done this in the past with mixed success, typical problems
>>> include "cmake is too old", "autoconf/autotools are too old".
>>
>> Having run into this at a smaller scale for one of the projects I ended up using
>> devtoolset-6 (and -7 as appropriate) that ships all this stuff such as
>> newer GCC,
>> GLIBC, etc.
>>
> 
> Yes, devtoolset is the advertised solution. I bought into it myself,
> and then got burned after discovering that is it is missing one critical
> 32-bit shared library and it cannot be used to cross-compile 32-bit executables,
> a "must have" for a couple of experiments that use hardware
> with 600-1200 MHz Pentium-3 processors. (replacement hardware is in the USD$5000
> price ranges, quantity "to be upgraded" is around 10, none of this has
> been budgeted and 64-bit upgrade is not needed for the function
> they perform).
> 
> Anyhow, is there commitment to devtoolset updates to c++17, c++20, c++21, etc?
> 
> For our MIDAS Data Acquisition package, we just started using c++11 recently,
> and already we desire to use c++14 and c++17 features. (cannot, because of el7).
> 
> Then, there is the question whether SL7 "upgraded to latest versions of everything"
> is still SL7. ("grand father's axe", etc). For a purist, SL7 is something
> installed from an official installer image, adding packages from EPEL and ELREPO
> starts pushing it. SL7 with custom-built linux kernel, glibc, sshd, httpd, kde,
> php100 and python3000 is probably not SL7 anymore.
> 
> The label "SL7" is only useful if it refers to something well defined. If every
> instance of SL7 has a different linux kernel, different versions of devtoolset,
> different cmake, different python, etc, I would say SL7 no longer exists.
>