Re: RockyEL list archives appear to be behind a paywall

[Yasha Karant]

I believe you may have misunderstood what I wrote.  Oliver Heaviside had 
NO formal academic diplomata, but was fully professional with the 
necessary credentials as demonstrated by knowledge, understanding, and 
skills -- including making fundamental contributions to mathematics, 
engineering, physics, etc.  I explicitly am not discussing either 
legitimate academic diplomata nor vendor-based credentials/certificates. 
 You evidently have the sort of credentials that I was discussing. 
However, this is not meant to denigrate a legitimate earned academic 
diploma -- a diploma may (*MAY*) be sufficient, but is not necessary -- 
except for those entities that require such diplomata or certificates 
for a person to be allowed to work.  Thus, in the USA, a medical doctor 
has to have a diploma to get a license to practice medicine; at my 
university, unfortunately, today a person such as Heaviside could not be 
allowed to join the Faculty, and definitely not the tenure-stream 
Faculty.  My university looks at the bar-code, as it were, not the 
actual contents.


On 12/31/20 4:42 PM, Nico Kadel-Garcia wrote:

On Thu, Dec 31, 2020 at 2:19 PM Yasha Karant  wrote:


I fully agree concerning an engineering background.

However, any good practitioner (with, like Heaviside, credentials
equivalent to both academic intellectual education and practical field
experience, irrespective of formal diplomata -- today, the diploma seems
the most important and a Heaviside probably would be impossible) should
have the requisite software engineering techniques and skills.  My


*Hah*. I studied bio-electrical engineering, computer courses were a
requirement but not the focus of my interest. A dozen years in the
field supporting lab systems gave enough expertise to provide
some. expertise, enough to nearly double my income when I shifted
to private industry. There is a great deal of skilled engineering and
medicine that I'd much rather be performed by a less credentialed
person with more practical experience.

Re: RockyEL list archives appear to be behind a paywall

[Nico Kadel-Garcia]

On Thu, Dec 31, 2020 at 2:19 PM Yasha Karant  wrote:
>
> I fully agree concerning an engineering background.
>
> However, any good practitioner (with, like Heaviside, credentials
> equivalent to both academic intellectual education and practical field
> experience, irrespective of formal diplomata -- today, the diploma seems
> the most important and a Heaviside probably would be impossible) should
> have the requisite software engineering techniques and skills.  My

*Hah*. I studied bio-electrical engineering, computer courses were a
requirement but not the focus of my interest. A dozen years in the
field supporting lab systems gave enough expertise to provide
some. expertise, enough to nearly double my income when I shifted
to private industry. There is a great deal of skilled engineering and
medicine that I'd much rather be performed by a less credentialed
person with more practical experience.

Re: RockyEL list archives appear to be behind a paywall

[Yasha Karant]

I respectfully disagree.  Some users can take a "wait and see attitude" 
-- let us see how distro X (for any X) that is "new" or "developing" 
evolves. It may, or may not, meet our needs.  Others, of which the HEP 
community (as with Fermilab and CERN) are prime examples, have to plan 
ahead and cannot wait and see -- if distro X that appears that it will 
meet needs in fact does not, there will be insufficient time to choose 
another course.  One way to look into the "crystal ball" as it were is 
to observe current developments to limit the "hindsight is 20/20" 
result.  I have commented upon current developments that I have read 
about and attempted to bring these to developments to the attention of 
the SL community -- much of which reads this list.  For the enthusiast 
or amateur, a failure of Fedora or Ubuntu non-LTS, etc., may only mean 
inconvenience -- just as the MS Win "blue screen of death" seems to mean 
to many.  For those who need a stable "secure" environment or platform, 
and who must plan ahead, such "inconveniences" may be much more 
consequential.  It also is possible that mention of such developments 
here may cause changes in distro X.  The IBM acquisition of RH and the 
end of CentOS as a no-fee executable installable EL shows that such 
concerns do not always influence a distro, just as the HEP community no 
longer had the disposable resources to produce SL 8, etc.  (In the USA, 
fundamental science that does not have a clear path to for-profit 
private sector eventual deliverables continues to suffer; thus, the 
Arecibo observatory is gone.)


On the contrary, I have had a number of correspondents express great 
confidence that Rocky EL (or whatever name the distro ultimately is 
titled) will be a fully reliable replica of production supported RHEL. 
I hope they are correct; but if not, those who "gambled" upon it will 
have to face the same situation as is now before the SL community -- how 
to proceed. Hopefully, ELrepo and EPEL, etc., will continue to support 
porting needed drivers and utilities to EL 8, 9, ... , and thus Rocky EL.


On 12/31/20 7:21 AM, Jon Pruente wrote:
On Wed, Dec 30, 2020 at 11:06 PM Yasha Karant > wrote:


Beef:  Slang.       a complaint.
      an argument or dispute.

I do not have a complaint, argument, or dispute with Rocky EL or any
other distro, enthusiast, "enterprise", or supported for fee.  The
issues are suitability, currency, hardening, and support mechanisms.  I
can elaborate on any of these if there is interest.  It is difficult,
but not impossible, to have a distro that does not have computer
science
and engineering professionals (not in the sense of necessarily using
this as in the sense of a significant source of gainful employment, nor
in the sense of formal academic diplomata -- Heaviside had no such
diplomata, but in the sense of knowledge, understanding, and skills, of
which Heaviside had sufficient in all three of these areas) doing the
implementation that is suitable for "hardened" production use,
including
converting a distribution source into a functioning alternately badged
but otherwise identical "executable" distribution.


You do have a beef. You post item after item "exposing" how Rocky is not 
suitable for prime professional use, while ignoring that the project is 
still developing. You post complaint after complaint about how it's a 
volunteer run affair while you can only stomach using something that 
people are paid specifically to do. You have the take that volunteerism 
is bad for serious use, yet the whole CentOS debacle is rooted around 
paid Red Hat employees scuttling the distro. Stop being pedantic and 
just own up to the behavior we can see in your posts.

Re: RockyEL list archives appear to be behind a paywall

[Yasha Karant]

I fully agree concerning an engineering background.

However, any good practitioner (with, like Heaviside, credentials 
equivalent to both academic intellectual education and practical field 
experience, irrespective of formal diplomata -- today, the diploma seems 
the most important and a Heaviside probably would be impossible) should 
have the requisite software engineering techniques and skills.  My 
concerns are two-fold -- lack of such techniques and skills, and lack of 
sufficient work-fraction to do the work (e.g., for which the work is not 
gainful employment).  For some things, such as say, Calibre or 
TexStudio, it is less of a concern that these applications 
professionally are constructed or maintained (these actually are); 
however, systems software are of such a concern, including both 
reliability as well as "hardening" against compromise.


On 12/31/20 8:02 AM, Lamar Owen wrote:

On 12/31/20 12:05 AM, Yasha Karant wrote:
... It is difficult, but not impossible, to have a distro that does 
not have computer science and engineering professionals ... doing the 
implementation that is suitable for "hardened" production use, 
including converting a distribution source into a functioning 
alternately badged but otherwise identical "executable" distribution. 


In my opinion and for software that I will approve for use at $dayjob, 
developers doing "professional" release engineering and management for 
any software really should have solid software engineering backgrounds, 
not just computer science backgrounds. Since I do this sort of 
evaluation on a professional basis, I am using the ACM's definitions of 
those fields as defined in "Computing Curricula 2005: The Overview 
Report" as well as the individual, updated, curricula as found on the 
ACM's page at 
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.acm.org_education_curricula-2Drecommendations=DwIFAw=gRgGjJ3BkIsb5y6s49QqsA=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A=J_y_RQ_m1wBDNa6puHIKs0qD-PVYaEuxw9yvER0cVXo=9h8AR-p_2yNK1ZunKeU1c78tSEzoHsVXrIyUejk4EVc=  
. I do this sort of research for any high-value software, whether 
commercial or not, especially if there is a budget line item associated 
with it or if it is core infrastructure such as the primary server OS to 
run.


One reason I was so very comfortable with CentOS is that I've done my 
homework on the developers' professional backgrounds, which passed 
muster for my purposes; I was equally comfortable with Scientific Linux 
even before it was called that, but the larger base behind CentOS made 
the decision for me between those two, which I annually reviewed.  It 
helps a great deal that I've been acquainted with many of these folks 
(both CentOS and SL) for over 20 years, and have seen their track 
records.  And track records trump degrees and titles for my purposes.


Track records makes it all the more difficult for me to choose a CentOS 
Linux replacement today; even just counting the RHEL rebuilds, there is 
quite a bit of choice, between Oracle, Springdale, CloudLinux Project 
Lenix, Rocky, and even CentOS Stream.  The evaluation rubric is much 
larger now than it was when PUIAS, WhiteBox, and CentOS started.


In my over fifteen years experience here, primarily with CS interns, I 
have found that much of the time a computer science background alone is 
not enough; proper release engineering and management requires 
sub-disciplines that aren't necessarily found in the typical CS 
curriculum (learning such out-of-major disciplines is one goal of a good 
internship, in my opinion; the discipline of effectively and 
consistently using things like source code revision control, for 
instance).  Now, information systems or information technology 
backgrounds (again, using the ACM's definitions) can be highly useful 
toa project, mostly for process management and business alignment (on 
the IS side) or infrastructure management (on the IT side), but the core 
discipline needed for release management is SE.


My observation about the paywall was simply that public archived 
discussions are needed to trace back both proper attribution (even if 
not for-fee property) as well as to verify the current state of any 
particular implementation. 
In my opinion, requiring a login of any kind to access archives means 
the discussion isn't public by definition, even if anyone can join; many 
mailing lists even have a 'members-only' archive policy. I too have a 
bit of a problem with certain communications channels that seem to be 
very popular these days, but at the same time, in open source projects 
at least, the people who do the work should be able to choose the tools 
they use to do that work.  But, one of the side effects of this 
Instagram/SnapChat/Discord/Tiktok world is that the value of archives 
seems to not be fully appreciated (I won't elaborate here on how well I 
know this in terms of astronomy in general and radio astronomy in 
particular).

--
They 

Re: RockyEL list archives appear to be behind a paywall

[Jon Pruente]

RE: "paywall"

This is part of the Rocky team itself and their infrastructure being
literally in development. They know and understand these issues and are
working to overcome them. They are a team that is growing and overcoming
early mistakes and limitations, and admitting to them. That is admirable
for such a young project. From that "paywall"ed slack this morning:

> Rayzonic Today at 8:26 AM
> May I ask, any advantages on Mattermost over Slack? just curious. Thanks
in advance.

> neil  3 hours ago
> @Rayzonic Essentially slack is very expensive and not very well aligned
with our values about being open.
> Right now we're losing lots of messages because of the limit of 10,000 on
free plans.
> Something we didn't take into consideration, but should have, was the
accessibility of the platform we choose - but it looks like mattermost does
have good accessibility options. I'm looking forward to hearing your
thoughts on it when we get there!
> Have you used mattermost before?

> gmk  2 hours ago
> The 10k message limit means at our current churn rate messages are lost
in a matter of days not even weeks. Also, their sales team keeps talking to
me, and even though they apparently use CentOS, and seem to be planning on
using Rocky (from an internal unreliable source), they won’t help us with a
properly sponsored account. Mattermost on the other hand is very helpful to
us and open source.

Re: RockyEL list archives appear to be behind a paywall

[Lamar Owen]

On 12/31/20 12:05 AM, Yasha Karant wrote:
... It is difficult, but not impossible, to have a distro that does 
not have computer science and engineering professionals ... doing the 
implementation that is suitable for "hardened" production use, 
including converting a distribution source into a functioning 
alternately badged but otherwise identical "executable" distribution. 


In my opinion and for software that I will approve for use at $dayjob, 
developers doing "professional" release engineering and management for 
any software really should have solid software engineering backgrounds, 
not just computer science backgrounds. Since I do this sort of 
evaluation on a professional basis, I am using the ACM's definitions of 
those fields as defined in "Computing Curricula 2005: The Overview 
Report" as well as the individual, updated, curricula as found on the 
ACM's page at https://urldefense.proofpoint.com/v2/url?u=https-3A__www.acm.org_education_curricula-2Drecommendations=DwIFAw=gRgGjJ3BkIsb5y6s49QqsA=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A=J_y_RQ_m1wBDNa6puHIKs0qD-PVYaEuxw9yvER0cVXo=9h8AR-p_2yNK1ZunKeU1c78tSEzoHsVXrIyUejk4EVc=  .  
I do this sort of research for any high-value software, whether 
commercial or not, especially if there is a budget line item associated 
with it or if it is core infrastructure such as the primary server OS to 
run.


One reason I was so very comfortable with CentOS is that I've done my 
homework on the developers' professional backgrounds, which passed 
muster for my purposes; I was equally comfortable with Scientific Linux 
even before it was called that, but the larger base behind CentOS made 
the decision for me between those two, which I annually reviewed.  It 
helps a great deal that I've been acquainted with many of these folks 
(both CentOS and SL) for over 20 years, and have seen their track 
records.  And track records trump degrees and titles for my purposes.


Track records makes it all the more difficult for me to choose a CentOS 
Linux replacement today; even just counting the RHEL rebuilds, there is 
quite a bit of choice, between Oracle, Springdale, CloudLinux Project 
Lenix, Rocky, and even CentOS Stream.  The evaluation rubric is much 
larger now than it was when PUIAS, WhiteBox, and CentOS started.


In my over fifteen years experience here, primarily with CS interns, I 
have found that much of the time a computer science background alone is 
not enough; proper release engineering and management requires 
sub-disciplines that aren't necessarily found in the typical CS 
curriculum (learning such out-of-major disciplines is one goal of a good 
internship, in my opinion; the discipline of effectively and 
consistently using things like source code revision control, for 
instance).  Now, information systems or information technology 
backgrounds (again, using the ACM's definitions) can be highly useful 
toa project, mostly for process management and business alignment (on 
the IS side) or infrastructure management (on the IT side), but the core 
discipline needed for release management is SE.


My observation about the paywall was simply that public archived 
discussions are needed to trace back both proper attribution (even if 
not for-fee property) as well as to verify the current state of any 
particular implementation. 
In my opinion, requiring a login of any kind to access archives means 
the discussion isn't public by definition, even if anyone can join; many 
mailing lists even have a 'members-only' archive policy. I too have a 
bit of a problem with certain communications channels that seem to be 
very popular these days, but at the same time, in open source projects 
at least, the people who do the work should be able to choose the tools 
they use to do that work.  But, one of the side effects of this 
Instagram/SnapChat/Discord/Tiktok world is that the value of archives 
seems to not be fully appreciated (I won't elaborate here on how well I 
know this in terms of astronomy in general and radio astronomy in 
particular).

--
They say hindsight is 20/20;
I'm looking forward to 2020 becoming hindsight.

Re: RockyEL list archives appear to be behind a paywall

[Jon Pruente]

On Wed, Dec 30, 2020 at 11:06 PM Yasha Karant  wrote:

> Beef:  Slang.   a complaint.
>  an argument or dispute.
>
> I do not have a complaint, argument, or dispute with Rocky EL or any
> other distro, enthusiast, "enterprise", or supported for fee.  The
> issues are suitability, currency, hardening, and support mechanisms.  I
> can elaborate on any of these if there is interest.  It is difficult,
> but not impossible, to have a distro that does not have computer science
> and engineering professionals (not in the sense of necessarily using
> this as in the sense of a significant source of gainful employment, nor
> in the sense of formal academic diplomata -- Heaviside had no such
> diplomata, but in the sense of knowledge, understanding, and skills, of
> which Heaviside had sufficient in all three of these areas) doing the
> implementation that is suitable for "hardened" production use, including
> converting a distribution source into a functioning alternately badged
> but otherwise identical "executable" distribution.
>

You do have a beef. You post item after item "exposing" how Rocky is not
suitable for prime professional use, while ignoring that the project is
still developing. You post complaint after complaint about how it's a
volunteer run affair while you can only stomach using something that people
are paid specifically to do. You have the take that volunteerism is bad for
serious use, yet the whole CentOS debacle is rooted around paid Red Hat
employees scuttling the distro. Stop being pedantic and just own up to the
behavior we can see in your posts.

Re: RockyEL list archives appear to be behind a paywall

[Yasha Karant]

Beef:  Slang.   a complaint.
an argument or dispute.

https://urldefense.proofpoint.com/v2/url?u=https-3A__www.dictionary.com_browse_beef=DwIDaQ=gRgGjJ3BkIsb5y6s49QqsA=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A=udqqjMTgzCb4e7B4bSZsQSucKrJdBsUWfh-ZCVVf41k=Mx2aCWnuP6ZizsericAqpby4d9Jgaj5RSZycrHVivqo= 


as I could not find a definition of "beef" in Merriam-Webster on-line.

The only reason that I am posting a "definition" of the term you used is 
so that I can address your accusation.


I do not have a complaint, argument, or dispute with Rocky EL or any 
other distro, enthusiast, "enterprise", or supported for fee.  The 
issues are suitability, currency, hardening, and support mechanisms.  I 
can elaborate on any of these if there is interest.  It is difficult, 
but not impossible, to have a distro that does not have computer science 
and engineering professionals (not in the sense of necessarily using 
this as in the sense of a significant source of gainful employment, nor 
in the sense of formal academic diplomata -- Heaviside had no such 
diplomata, but in the sense of knowledge, understanding, and skills, of 
which Heaviside had sufficient in all three of these areas) doing the 
implementation that is suitable for "hardened" production use, including 
converting a distribution source into a functioning alternately badged 
but otherwise identical "executable" distribution.


My observation about the paywall was simply that public archived 
discussions are needed to trace back both proper attribution (even if 
not for-fee property) as well as to verify the current state of any 
particular implementation.  (I am not going debate how one terms a 
practice -- if access requires a fee or the equivalent -- make a 
contribution of any sort-- such fee-controlled access has the same 
effect as a paywall -- do not supply the fee, no access.)


A discussion of the actual or to-be-implemented suitability, currency, 
hardening, and support mechanisms of any distro (or other engineering 
artifact for that matter) is not a complaint, but simply proper 
engineering.  Actual binary executables are constructed through 
engineering and technology.


On 12/30/20 8:08 AM, Jon Pruente wrote:
On Tue, Dec 29, 2020 at 6:51 PM Yasha Karant > wrote:



Thus, unlike either the Ubuntu (including LTS) Ask Ubuntu or this SL
list that are available without any fee with full archive access, it
appears that to get to the RockyEL "list" much older than one calendar
week, one must subscribe for a fee.  Such a system makes archival
information not generally available.  If other RockyEL (e.g., #rocky )
readers do not see the paywall message and are not paying a fee (or
have
an institutional "subscription"), please comment as to how to get the
"archives".


It's not a paywall for users. It's a limit of using a free Slack 
instance vs paid. The Rocky Linux team is already in the process of 
moving to a longer term system. The slack was never meant to be 
permanent, as it was initially used for gmk's HPC company. It was the 
easiest and most expedient place to send people at the sudden change 
from Red Hat. You seem to have quite a beef against Rocky in principle, 
and choose to ignore that the project is literally brand new and was 
started without any advance plans.

Re: RockyEL list archives appear to be behind a paywall

[Jon Pruente]

On Tue, Dec 29, 2020 at 6:51 PM Yasha Karant  wrote:

>
> Thus, unlike either the Ubuntu (including LTS) Ask Ubuntu or this SL
> list that are available without any fee with full archive access, it
> appears that to get to the RockyEL "list" much older than one calendar
> week, one must subscribe for a fee.  Such a system makes archival
> information not generally available.  If other RockyEL (e.g., #rocky )
> readers do not see the paywall message and are not paying a fee (or have
> an institutional "subscription"), please comment as to how to get the
> "archives".
>

It's not a paywall for users. It's a limit of using a free Slack instance
vs paid. The Rocky Linux team is already in the process of moving to a
longer term system. The slack was never meant to be permanent, as it was
initially used for gmk's HPC company. It was the easiest and most expedient
place to send people at the sudden change from Red Hat. You seem to have
quite a beef against Rocky in principle, and choose to ignore that the
project is literally brand new and was started without any advance plans.

Re: RockyEL list archives appear to be behind a paywall

[Dave Dykstra]

Hi Yasha,

That's a general Slack policy.  With the amount of traffic generated on
the rocky slack channels, messages on the unpaid hpcng Slack are limited
to about 4 days.  This is why in the last community update that I posted
here it was announced that rocky will be switching to Mattermost. 
https://forums.rockylinux.org/t/community-update-december-2020/1157
It just hasn't happened yet, mostly because of the holidays.

Dave

On Tue, Dec 29, 2020 at 04:50:57PM -0800, Yasha Karant wrote:
> Unlock messages prior to December 20th in The Next Generation of High
> Performance Computing Community
> To view and search all the messages in your workspace's history, rather
> than just the 10,000 most recent, upgrade to one of our paid plans.
> 
> The above is the message upon reading the current RockyEL "list"
> 
> Start Slack excerpt
> 
> #rocky
> 
> https://blog.centos.org/2020/12/future-is-centos-stream/#comment-183642 Some
> other channels are #rockylinux and #rockylinux-devel on Freenode
> 
> End excerpt.
> 
> Thus, unlike either the Ubuntu (including LTS) Ask Ubuntu or this SL list
> that are available without any fee with full archive access, it appears that
> to get to the RockyEL "list" much older than one calendar week, one must
> subscribe for a fee.  Such a system makes archival information not generally
> available.  If other RockyEL (e.g., #rocky ) readers do not see the paywall
> message and are not paying a fee (or have an institutional "subscription"),
> please comment as to how to get the "archives".
>