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.
