SCIENTIFIC-LINUX-USERS Archives

February 2020

SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Nico Kadel-Garcia <[log in to unmask]>
Reply To:
Nico Kadel-Garcia <[log in to unmask]>
Date:
Sat, 1 Feb 2020 11:12:22 -0500
Content-Type:
text/plain
Parts/Attachments:
text/plain (48 lines)
On Thu, Jan 30, 2020 at 8:58 PM Yasha Karant <[log in to unmask]> wrote:
>
> At this point in terms of application support for EL 7 (including SL 7)
> from external entities (such as Calibre -- there are others), I am going
> soon to be forced to go to another Linux.  The options appear to be drop
> EL entirely and go to Ubuntu  LTS ("stable") current, or to stay with EL
> and use Springdale (Princeton) EL8 when (if?) it is available, or Oracle
> 8 EL.  Thus far, everyone I have contacted who did a clean install of

*No one* calls it "Oracle 8". It's still RHEL 8. Oracle now owns and
can still use the Red Hat trademarks.

Since CERN is collaborating with or switching to CentOS, and since Red
Hat upstream hired the core CentOS maintainers as employers, I'd urge
you to move this philosophical and business plan discussion to the
CentOS mailing lists.

> Oracle 8 (and then copied back files, directory trees, etc., from the
> non-systems areas of an EL 7 working system) have had no issues.
> However, I am very concerned about support for Oracle 8 other than
> purchasing support from Oracle.  Do the various professional
> repositories for SL 7 (and EL 7 in general) such as EPEL have an EL 8
> version that work seamlessly with Oracle 8 (or Springdale for that matter)?

*Nothing* works seamlessly with RHEL 8. It was a major OS upgrade,
with a shift to Python 3 as the primary python, a set of unwelcome and
unnecessary divisions of standard components into multiple channels,
and the activation of "module" based RPMs that overlap and conflict
with standard system components, especially for Perl and Python.

> In the best of all possible worlds, I or my students would have time to
> build applications from source -- but there are too many and not enough
> time, forcing the use of repositories with pre-built RPMs (or DEBs if we
> switch to Ubuntu).  Note that we run the same base OS on servers
> (including HPC compute servers with Nvidia CUDA GPUs) as well as desktop
> and laptop machines, all presently X86-64 based (this may change for at
> least some of the servers).

If your students build or need to build packages,I'll urge them to get
their work back into the community, usually through EPEL. If the
packages upgrade or feature modify components included upstream, well,
you or they have decisions to make about whether to publish binaries,
or source, and where to publish. I publish at Github.

> Any advice would be appreciated.
>
> Yasha Karant

ATOM RSS1 RSS2