Il 2021-02-25 22:35 Stephen John Smoogen ha scritto:
Mainly because customers don't want to pay for that work which is
considerable. If Red Hat builds it, it is expected to have all kinds of
'promises' equivalent to its other products and that is expensive in
terms
of QA, engineering, documentation, various certifications, etc. Package
growth goes up quickly so if people are complaining about the cost of a
RHEL license for 4000 src rpms, then what would it be at 20,000 to
30,000.
It is easier to allow the community to choose to do the work it wants
and
then 'consumers' of said repository get what they can.
[Including Valeri] I doubt it. Price is mainly defined by offer and
demand (which is, in turn, driven by how much value the customer put
behind the product). While production/support cost can put a lower bound
on it, I don't think this is the case for Red Hat.
Anyway, Red Hat did not have to supporto EPEL packages the same as core
one - even a best effort support would be enough in many cases. The
point is that EPEL does not only contains nice-to-have packages, but
sometimes provide really important packages.
As an (outdated) example, a decade ago Cyrus with mysql backend was only
provided by EPEL. For a more up-to-date example, consider how difficult
is to run a "plain" CentOS 7 system - it misses monit, mbuffer, smem,
x2go, various Perl modules, etc.
You EPEL volunteers do an outstanding works - I would really than for
all you did (free of charge) for the CentOS community. Red Hat should
recognize and support your works.
I think the industry is entering another crux point where 'classical'
system administration will be in the same class as mainframe/miniframe
system administration were in the late 1980's and early 1990's with
Unix
systems and then Linux. Our wor will remain incredibly important to
various
industries but it will increasingly be a smaller amount of 'total
deployments'. Which is why so many of our conversations echo so much
of
the USEnet in the early-1990s, where mainframes/miniframes admins
wondered
why companies were not focusing on their industries anymore.
Well, in a sense, the new cloud frenzy is something similar to a "remote
mainframe" used with a new type of thin client (the browser). Yeah, I
know this is a very stretched analogy...
I should say that I saw so many services deployed "to the cloud" that
are plain broken/misbehaving that it sometime worries me. My (naive?)
impression is that we are switching from "few specific services which
correctly work unless something bad happen" to a
"mess-which-more-or-happens-to-works but nobody know what to do if it
does not" model.
I recently debugged an IPSec tunnel between an on-premise appliace and a
Azure VPN services. The on premise appliance has extensive log and
inspection tools, while on the Azure side we had litelly *nothing*. An
Azure consultant was taken on board to help with specifig Powershell
sniplet, to no avail. After 7+ days, a 3rd level Microsoft support
engineer change a *private* setting on that VPN gateway service and the
tunnel started working correctly.
On another case, a Win2008R2 machine stopped working in a AWS instance.
No console, no logs. After 2+ weeks of paid "gold/premium" support from
an Amazon enginer, my customer simply decided to detach the virtual disk
and to attach it to another machine, reinstallaing the server.
Are we sure this is the way to go?
Don't get me wrong - "the cloud" is the natural places for things as web
and mail server. A virtualized domain controller? Mmm... not so much.
But hey - I understand this is not going to change. The very same CentOS
switch was done to please the cloud vendors, which will have a more
"dynamic" base to rebuild. But I don't like how Red Hat does not simply
produce a different product or profile for the cloud needs, rather than
actively adding complexity at every layer.
Regards.
--
Danti Gionatan
Supporto Tecnico
Assyoma S.r.l. - www.assyoma.it
email: g.danti@xxxxxxxxxx - info@xxxxxxxxxx
GPG public key ID: FF5F32A8
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos
