On Tue, Nov 7, 2017 at 8:43 PM, ToddAndMargo <[log in to unmask]> wrote:
> On 11/07/2017 04:59 PM, David Sommerseth wrote:

> By the way, I do code in Perl 5 and 6.  EL Linux is
> a nightmare with all its outdated Perl.  Look
> at what I have to do to get a YUM update through:
>
> # yum --skip-broken --exclude perl-libs.otherarch  --exclude net-snmp-libs
> --exclude libsemanage upgrade
>
> Whenever I trip across a bug in Perl6 (and I find a lot of them),
> I tell the developers over on their chat line and in two weeks to a month,
> "dnf upgrade rakudo" (Fedora)
> fixes the issue.
>
> Same with Perl 5, although I find very few bugs in
> P5 as it is mature.

Perl has has a serious issue with modular dependency hell. You don't
run into it, or run into one update breaking other components, if you
stay within a stable distribution that does serious regression
testing. You also have options to access more recent base versions of
Perl, Python, and other dynamic, highly evolving, and less stable
toolkits by activating the software collections channels.

As you say: Perl 6 is not mature.Even Fedora does not consider it to
be mature for mainline use. If you're out there at that bleeding edge,
well, good luck with anything resembling stability. The CPAN modules,
in particualr, are likely to add new components that solve one
dependency and break previous releases of other modules. pip for
Python, gradle and ant and maven for Java, all share the same problem.
Testing, resolving, and backporting fixes to handle those dependencies
is one futz of a lot of work.

> I should NEVER expect this from EL Linux.  This is my fault.
> This is not what EL Linux is meant for.  Need a bug fixed,
> too bad.  This is frozen code.

Nonsense. A bug in an existing release is fixed for their paying
clients. The patch is also tested, and gets evaluated for
compatibility. That's what it takes to have a 10 year stable life span
for a release. If you want to be playing out there in Perl 6 land,
great. But be aware that your efforts cannot be backported slapdash
into a stable environment with paying customers, or people like us who
rely on it for sensitive medical, scientific, or financial work.

> I JUST TRULY adore that fact that some of my Perl code
> works in Fedora but not EL Linux.  <Editorial Comment
> AAAAHHHHHH !!!! </editorial comment>

Enjoy. Fedora is where the bugs get hashed out for publication in
RHEL, and get passed along to rebuilds like Scientific Linux and
CentOS.

> I have been turned down for help before as the issues
> in Perl I have tripped across ARE fixed, but not in
> EL Linux.  I have tried removing all of EL Linux's Perl code
> and install the good stuff manually, but I never manage
> to get rid of all the old, bad stuff successfully.  Again,
> my fault for not picking a Kaisen OS.

"Continual Improvement" also means "continual failure". Been there,
done that. Most businesses, and many home users, simply cannot afford
the cost of leading edge technologies.

> And you know the Cxxx series of chipsets have been around
> for a while now.  Just not long enough to be out of
> production at which point it will appear on Red Hat
> compatibility list.

Nonsense. Our friends over at Red Hat are continuously supporting
leading edge *server* hardware. laptop and many business class
chipsets evolve, and hae unannounced upgrades far too frequently, to
expect the same support.

> I just upgraded a CentOS 5 server.  It was over seven years
> old.  It just keeps running and running.  But its was time as things
> were going to start failing hardware wise.  So EL Linux did
> its thing as you described.  But, I need to point out, that
> Fedora would have too, if I had not upgraded.  The Ask Fedora
> folks still yield question on Fedora servers that are very old indeed.

Been there, done that, and it's not as certain as you depict. In
particular, the bleeding edge Fedora installers are quite resource
intensive. They basically don't work without a Gig of RAM, at least:
you might never have been able to install it.

> EL Linux is perfect for a set and forget installation that
> needs to be frozen in place for a lot of years, providing
> your stuff work to start with on it.
>
> Yes RH is a YUGE company and yes they have a lot of
> relationships with vendors.  How do you explain these
> remarks of theirs?

> Giving them Supermicro's phone number and who to talk to
> did not help.

Been there. Done that. Built blade servers for a while. Supermicro....
had a real problem with answering the phone, and a *horrible* problem
with refusing to answer questions about BIOS or hardware
configurations. And yes, I helped built the first 8-core blade server
on SuperMicro boards.

> What you describe is not what they practice.  Again,
> this is open source and I can not afford the consulting.
> This is my fault for choosing an Anti-Kaisen OS.

Please. They're hardly "Anti-Kaisen". They are "do not break working systems".

> It is my fault for expecting a Blue Car to have
> all four of its wheels attached and to expect it
> to drive on modern roads.  EL Linux was a really
> bad choice for me to standardized on.
>
> You are correct.  I am not using EL Linux as it is intended.

And please it is not "EL Linux". It is "Red Hat Enterprise Linux" Maye
if you wnat to shorten it to "Enterprise Linux", but the extra "Linux"
is confusing.

Look, if you don't appreciate the work done upstream, then raise it
with Red Hat. Let's take it off the Scientific Linux mailing lists,
where their rebundling of the commercial version has been very helpful
and useful to people who need shoestring cost software with the
stability of an enterprise OS.