SCIENTIFIC-LINUX-USERS Archives

December 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:
Yasha Karant <[log in to unmask]>
Reply To:
Yasha Karant <[log in to unmask]>
Date:
Thu, 10 Dec 2020 14:47:55 -0800
Content-Type:
text/plain
Parts/Attachments:
text/plain (118 lines)
I have been reading this thread and post some of my observations and 
comments on the matters.

Much, if not all, experimental/hardware science and engineering systems 
applications (e.g., special drivers, modified interfaces and bus 
control, etc.) are targeted towards EL or the SuSE equivalent.  There 
will not be a CentOS 9, although there had better be a RHEL9 unless IBM 
decides upon yet another path (because of for-profit business 
parameters, as well explained by another correspondent to this list who 
used very candid and honest language).

For example, at one time we put SuSE SLES (SuSE EL equivalent, just as 
Ubuntu LTS is aimed at the same sector) on a HPC compute engine that had 
a SAN and other infrastructure as well.  SuSE was dismal because we 
bought the least expensive support level (not cradle-to-grave full 
handholding).  We then switched to SL for RHEL, and at least one of the 
for-profit HPC vendors we used -- that was a subcontractor to US 
Government primary contractors -- also used SL.  SL worked, and the 
hardware support software we needed (including modified drivers, etc.) 
was available, tested, and installable -- from this vendor.  No games, 
no special support contracts, we did all of the software maintenance and 
verification such that things worked on our systems.

Again, as with SuSE, SL, and Ubuntu LTS, this was professionally ported 
and, in terms of bug fixes and sample configuration, etc., files, 
professionally supported by the vendor -- not amateur volunteers.

Cloud Linux looks -- again, looks -- as though it will be a SL type 
support, and presumably there there will be CL9 if RH is required to 
release the full source of RHEL9.  CL 8 (and upon RHEL9, CL9) should 
(should -- not will) be compatible with all of the 
scientific/engineering hardware specific ("experiment-use") drivers, 
etc., to which correspondents have referred.

Springdale (Princeton EL) is a possibility, but it is unclear how long 
Springdale will have real professional support depending upon how 
Princeton internally allocates fiscal (and hence personnel) resources, 
and how much Springdale, like Fermilab and thus SL, depends upon 
discretionary support from the USA Federal government.

I have signed up for the Rocky EL list to keep abreast of the situation, 
but it appears Rocky EL will not have the paid professional support of 
SL (not cradle to grave hand holding) but rather volunteer developers, 
porters, testers, etc.

CentOS Stream, as with Fedora, and Ubuntu non-LTS is completely 
unsuitable for my uses.  These can be not only "unstable", but have too 
many software defects (bugs) to of safe use.  Moreover, continual 
professional support is necessary to mitigate threats (the various 
compromises that are in the wild) -- keep things up to date against the 
latest attacks.

There has been a discussion of the shorter life-cycle of Ubuntu LTS 
versus EL.  In the case of CentOS 8, the life-cycle is much shorter than 
what seemed to be promised.  However, the issue arises as to against 
which system (and application) libraries (typically, .so) a scientific 
application is built, and against which Linux kernel (and kernel 
"features").  EL 7 (SL, CentOS, etc.) may have a longer supported 
lifecycle, but if a vendor does not back-port a vital application 
(including a driver) to a "supported" environment that has been 
"obsolete" for many years, than the support will be meaningless.  I 
recall once that we were required by a vendor of scientific equipment to 
support versions of the kernel and libraries that were not available for 
the "stable supported" Linux release we were using, and we were *FORCED* 
to migrate.  Thus, the shorter time interval of LTS versus EL supported 
environments may not always be of real significance.  However, the fact 
that some applications (including drivers) may not be available for 
Ubuntu (and in .deb from) but only for some variant of EL (in .rpm form) 
is of greater concern.  Cloud Linux may be the answer here -- if the 
vendor really  meets their promised time line.

Again, my own needs are such that it is unacceptable to have a volunteer 
(and in many cases, amateur) developer/support arrangement for "mission 
critical" systems and applications software.

Yasha Karant

On 12/10/20 8:47 AM, Vinícius Ferrão wrote:
> I’ve done this mistake in the past.
> 
> The major issue with Debian is its lifecycle, even LTS is 5 years only. Same for Ubuntu. It’s just too little. If you need to install it near the end of the 2yr lifecycle you’ll get effectively something like 3yrs of support.
> 
> The other issue is that the vast majority of academic and scientific software is targeted for Enterprise Linux. As an HPC engineer we always needs to use RHEL/derivatives or SLES/Leap. OpenHPC is only available to those flavors. Mellanox OFED? Ok there’s Ubuntu support nowadays, but the default branches are still for EL/SLE.
> 
> That’s how things work in our environment. I think the vast majority of people here works on Academia or with science/research/etc.
> 
> And finally I don’t want to adapt everything to Debian. The FHS is different, scripts will break, etc.
> 
> Best regards,
> Vinícius Ferrão
> 
> Sent from my iPhone
> 
>> On 10 Dec 2020, at 13:38, Maarten <[log in to unmask]> wrote:
>>
>> I might also consider switching to Debian since it will be hard to tell if any other still existing rhel clones will continue and Debian has been around for quite some time.
>>
>>> On 12/10/20 8:34 AM, Maarten wrote:
>>> I will probably be more like to go for Springdale Linux since they've been around since before CentOS, I find it hard to put trust in a project that's just getting started unless of course CERN changes their decision about discontinuing Scientific Linux since they were migrating to CentOS.
>>>
>>>> On 12/10/20 5:17 AM, ~Stack~ wrote:
>>>>> On 12/9/20 9:16 PM, Yasha Karant wrote:
>>>>
>>>>> One thing does concern me:  having left CentOS (it was all "volunteer" effort at that epoch as I recall) for SL, a primary motivator was that SL had professional (employed, not volunteer) persons doing the distros, and this SL list amounting to support.
>>>>>
>>>>> If Rocky is to be all volunteer, how reliable and professional will it be?  This is not a minor issue, as very few enthusiasts or other non-professionals provide a truly reliable deliverable.
>>>>
>>>> I would say, give it time. It wouldn't be the first time Kurtzer started an open source project and turned into a company. :-)
>>>>
>>>>
>>>>> For my use, is EL going to continue to be workstation friendly (e.g., laptop in which one cannot pick and choose to integrate only Linux traditionally supported controllers with appropriate drivers, such as sound "cards", but is stuck with whatever the laptop vendor has used -- typically MS Win "supported") or is it primarily a server distro? Ubuntu LTS still seems to be laptop friendly.
>>>>
>>>> They are aiming for complete RHEL reproducibility. If the goal is to be as-true-as-possible-RHEL variant then the answer would be in how you use RHEL.
>>>>
>>>> But do give it sometime. It's only been two days and the announcement I just saw said that there are now 750 people actively participating in the various forms to communication and they have direction, a plan, and leaders making it happen. And there's thousands of people who have noticed and are talking about it on /. , reddit, lwn, ect. That's pretty impressive and it speaks volumes about the number of people who really do want a true-to-RHEL variant.
>>>>
>>>> ~Stack~

ATOM RSS1 RSS2