Re: CentOS 8 future
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
I think that Centos, being that close to RHEL, should have had a
licensing scheme for personal use, small business use, just to make
things 'fair'.
It should be fine to use Centos as a "Community Enterprise OS", as a
stepping stone, but once it starts taking off, like it did with some big
enterprises, there should have been an obligation to switch to Redhat,
and pay up.
Centos/RHEL, pretty much being done/over, means that startups are
confronted with a competitive problem, AND also, upcoming sys
people/talent not having the opportunity to get into "that world" is a
problem. I think it is detrimental to the further use of anything RHEL.
The only thing RHEL can 'bank on' in the near future is that there is
nothing else around yet. (but problems like these never lasted long in
the past)
'Rocky Linux' guy might actually be on to something (although I'd pick
another distro name), if he can pull that off (which is not even that
far fetched), he can expect 6/7 figure development checks from
organizations that used the model as it is now, or used to be,
organizations that use the OS at scale (think multiple 8 figure price
tag machinery).
I don't think their (IBM/RHEL) course is going to change though, redhat
going "commercial" has been going on for a decade and a half or so, and
it looks like initial investors have a desire cashing/selling out at
this point.
Centos is kind of equivalent to RHEL, as you mentioned, heck, I have
RHEL support because of countless licenses where I work AND I can use
the knowledge databases and support for 'anything remotely' work
related. I even was explicitly told I can use it for anything at home if
I wish.
I am not too worried though, there will be something new, it will just
not be Centos, nor RHEL, and that just happens every or two decade or
so, that is just history repeating itself.
Ron
On 12/15/20 1:17 AM, Patrick Bégou wrote:
I'm also using CentOS for a while and I'm deploying a CentOS8 cluster
for some months.... because it was supported until 2029! Bad idea.
For me, using debian has 2 important drawbacks
- some of proprietary software we are using is certified RHEL and SLES.
Deploying on CentOS is out-of-thebox. Deploying on debian (we have also
debian servers) is often a nightmare and some functionalities still
doesn't work (and support reply "debian is not supported"). We have no
alternative for these softwares.
- hardware support for servers rely also on some certifications and they
are mainly for RHEL or SLES (or Unbutu but for laptops, not servers) and
in case of trouble the support has yet answered "please use a certified
os". Centos is considered as RHEL by the support. Not sure that with
stream it will be the same.
Patrick
Le 14/12/2020 à 17:57, Lamar Owen a écrit :
On 12/12/20 10:34 PM, Konstantin Boyandin via CentOS wrote:
My only concern ATM is whether RH can change its CentOS 7 maintenance
plans as well, all of a sudden.
This is what bothers me, too, but in a slightly different way. Even
for the GPL software, Red Hat actually doesn't have to provide public
access to the source code; the only thing required by GPL is that
those who receive binaries must be able to get sources. So, even
though it has been said that the source will be available, well, it
was also said that C8 would be supported to 2029. There are enough
packages in RHEL with non-GPL licenses where it would be very
difficult to rebuild the whole distribution without them, and RH is
not required by those licenses (MIT, BSD, and others) to redistribute
those modified sources even to people who have been distributed
binaries. So, while I want to believe that the sources will remain
available, that belief relies on trust, which unfortunately is less
abundant these days.
So while using another rebuild seems to be a good stopgap solution, I
do wonder if it will prove to be sustainable post-2021. I'm
personally looking at which of the four (that we know about) to
possibly go to; I just really doubt I am going to use Oracle; Rocky
isn't really there yet and is very young; Springdale is available,
mature, and academically supported (nothing wrong with that, just a
statement); CloudLinux OS Project Lenix isn't yet released. Out of
the bunch, Springdale would be my first choice right now because it's
been around a very long time and is available now. C8 is supposed to
be around until end of 2021, so there is some time for the dust to
settle and the way to become more clear, though. But CentOS 8 Stream
is only an option for me if the hardware driver KABI synchronization
issue is solved and stays solved. RHEL? Under the current
subscription models we just can't afford it. (Cost also keeps SLES out
of the running.)
But I'm now seriously considering just simply going to something that
is both older than Red Hat, fully and totally open, extremely
well-supported by a diverse developer community, and used by a whole
lot of people. Yes, that's Debian; until I realized where the name
came from (Deb and Ian) it read to me like a play on 'deviant.' The
'stable' period is shorter, for sure. The tradeoffs are pretty
simple: guaranteed openness versus less change for ten years.
So, let's look at that last piece. CentOS 6's support just ended;
what have the last nine years and three months of actual C6 support
looked like? I supported several C6 machines, and there were distinct
challenges early on, at least for the first four years or so. Since
then, on the server, it's been very stable, but really old; key pieces
of infrastructure software we use slowly became unusable on C6 due to
the old versions of specific packages, and either a third-party repo
with newer packages or a newer CentOS was needed.
Third-party repos have improved over the years, but some of the
earlier C6 machines I installed had packages from Linuxtech, Dag,
ATrpms, City-Fan (one particular DVD burner that just had to have the
non-wodim cdrtools for some reason; yes, I know all the warnings about
that repo), and others. Having EPEL and Dag both package a few things
that I needed, but package them differently, introduced me to package
pinning and repo priorities.... I don't miss those days. Seriously
stable in the core repos means very little when you need much less
stable third-party repos to get actual work done. That's also why
Fedora isn't really an option, just too much package churn; been
there, done that, a few years ago.
So I've started re-evaluating just why I use CentOS anyway; the answer
really boils down to the fact that I started out with Red Hat Linux in
1997 (I live in North Carolina, and I've always liked supporting local
companies) and I just really don't want to change; it feels like I've
wasted so much effort if I change now (that was the reason I stuck
with it through the Fedora-RHEL split years ago, too, and went with a
RHEL rebuild, first WBEL then CentOS). But the reality is not nearly
so stark; a vast majority of the information and skills I've picked up
in these years are portable to other distributions; so it's not wasted
effort. Well, other than RPM packaging skills; those are a bit less
portable. Whenever I've built from source I've tried to either build
my own RPM for it or rebuild the Fedora RPM for it, and so I have a
local repo of those packages, making reinstall much easier. So it
becomes a tossup: small change to another rebuild now, possibility of
major change later, or bite the bullet and go ahead and get the major
change over with and only have small changes later.
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos
[Index of Archives]
[CentOS]
[CentOS Announce]
[CentOS Development]
[CentOS ARM Devel]
[CentOS Docs]
[CentOS Virtualization]
[Carrier Grade Linux]
[Linux Media]
[Asterisk]
[DCCP]
[Netdev]
[Xorg]
[Linux USB]
|