On Fri, Oct 16, 2020 at 3:48 PM Konstantin Olchanski <[log in to unmask]> wrote:
>
> >
> > ... you have locked licenses for expensive old CAD software?
> > ... vendor has failed to keep their software up to date with operating
> > system releases ...
> > ... not Scientific Linux's fault.
> >
>
> Ah... the sound of Linux walking away from old-time Linux users...
>
> To me it looks like "Linux people" play with python, wayland and systemd
> and ignore the needs of long time scientific and industrial linux users
> (places like TRIUMF live in both camps).
>
> In my part of the universe, we have Altera Cyclone-I FPGA boards,
> the FPGA compiler is Altera Quartus (expensive CAD software),
> for sure, latest Altera Quartus is all up to date to run on latest Linux,
> but the last Quartus to support Cyclone-I FPGAs is 5 years old out of date
> and it will not be updated. But we still need to run it (or throw
> all Cyclone-I FPGA hardware into the dumpster).

This is why most computer hardware has a (nominal) 3 year refresh
cycle. I sympathize, some of by old boxes hasted more than 10 years
and I helped migrate various operating sytems into virtualization to
handle old fiscal records in old, proprietary software.


> So, a problem. For solution, what do we hear from the Linux side?
>
> All these answers are not the same:
>
> "here is the fix",

Your original messages did not, in fact, specify the problem. It did
not list the CAD software nor the hardware you had to work with.

> "we will try to help you",

Now that you've specified more details, it may be feasible.

> "we tried to help, but failed, sorry",

Some of us did help. "Upgrade your environment to something
supportable" was unwelcome, but without a profound and expensive
investment of expert time in a quite small field, I don't see a lot of
other solutions for you. You've my sympathy: I've pulled data off of
NASA tapes when there were no tape drives left on the east coast
except one I'd found that could read it, and I've done the "oh, we
need to keep the same kernel, we can just backport anything we need
into the old kernel!!!" dance of obsolete software. It took me more
than a year to prove that the "kernel experts" had spent three years
doing white space changes and hadn't made a single significant psych,
collecting quite lot of money providing "secret sauce" to that kernel.

> "it's too hard" and
> "not our fault/problem".

> Is it "too hard" to provide a solution for the OP and for myself? How come
> RHEL/SL/CentOS-8 does not come preinstalled with a package
> to "boot an SL3/SL4/SL5/RHEL6/RHEL7 VM image now!". (Yes, we still have

What? It supports Xen, KVM, Virtualbox and docker containers that can
handle old operating system images. If you need kernel level
integraqtion with a proprietary add-0n, you'll have to specify a *lot*
more detail about the requirement. And that level of expertise is
*not* cheap. It costs time, money, or both.

> hardware that required an m68k crosscompiler that runs on SL4. We even have
> a physical machine for this, a dual 500 MHz Pentium-II tower).

Then it's time to shut down that physical machine. You've had *13
years* since the release of RHEL 5, and the end of even extended life
cycle support from RHEL was 3 years ago. It's not reasonable to rely
on Scientific Linux to support an operating system even the upstream
vendor abandoned years ago.