CentOS 8.0 Released As Community Version Of Red Hat Enterprise Linux 8

[torsionbar28]

I tried it, it is not any different from Fedora 29 in terms of reliability, and you are stuck with Gnome.
No matter what they say about what EPEL is going to offer in terms of alternative DEs, the only really
solid distribution that currently offers lightweight environments is Debian, which also offers all that is
needed on a common desktop, and all of that lives in the official repos. CentOS + EPEL + nux + ? ..
..aren't ready yet.

Nonsense, plenty of distros offer lightweight DE editions. See Fedora Spins for example: https://spins.fedoraproject.org/FWIW, I've been using Fedora MATE for years now, since F24 or so, and it's been rock solid. It's nice being able to install Fedora and have MATE desktop by default out of the box, without having to touch that nasty GNOME3 stuff.

[hughesjr]

To the people calling CentOS Stream a Rawhide .. it is not. You seem to think it is beta quality .. it really isn't. Here is why.

What it will be is rhel source code + 0.1 .. so if the released RHEL version is say 8.1 .. then at the release point of RHEL 8.1, the Red Hat Engineering team will start rolling in changes they are going to make for RHEL 8.2. One package at a time as they actually do the work.

What i think you guys are not really thinking about is this .. for a normal CentOS point release (lets just take 7.6.1810 to 7.7.1908 as an example) .. there were 423 packages updated .. there are 3160 packages in CentOS 7.7.1908. What that means is (3160-423)/3160 = 86.6% of the new 7.7.1908 was already existing code in 7.6.1810. So only 13.3% of the source packages changed.

If you had been getting those packages .. 423 total .. over the 10 months .. you would have gotten an average of 42 packages per month or 1.4 packages per day.

If those 423 packages .. MOST of them were either a security update or a bugfix update of an existing package .. they were not a major new version of software. They will have gone through the normal QA process and they will have been staged internally to get rolled into the next version of RHEL .. in this case it would have been 7.7.

So in reality .. is that beta code? Not really. It is just things ready to roll into RHEL 7.7. It is almost complete code to fix a problem in 7.6 or fix a minor security issue they are not releasing before 7.7. But instead, you can get that QA checked code right now as it is tested .. not 10 months from now.

So, instead of waiting for a month for CentOS to build those 423 packages .. you can get them 1 or 2 at a time over a 10 month period. You can fix any issues you might have in small chunks .. literally one package at a time. You will not be rolling in 423 srpms worth of updates at the same time.. having 20, 30, or 40 issues that need fixing.

Also, when 7.7 would been released .. instead of waiting 1 month on centos to now build it .. you will be already running it .. RIGHT NOW. A couple of days before RHEL 7.7 was released.

So unless you are talking about a 'dot zero point release', you are not dealing with true beta code. If you are doing, say the stream for RHEL 9.0 .. before 9.0 is released, yes .. in that one particular instance .. it will be beta quality code. As explained by Matthew Miller in the Fedora Magizine link: https://fedoramagazine.org/fedora-and-centos-stream/

But i believe that you will find in all other instances, what you are getting instead is 'good enough to use', in as much as you are already using CentOS Linux for something right now. I absolutely recommend you try it and see.

Of course .. this is not being done CentOS Linux 6 or 7 .. only from 8.0.1905 and moving forward, so the 7.7 numbers were just used as an illustration of what the process would look like. But i don't think you are looking at the big picture if you are thinking this is an unusable software set.

[GdeR]

Nonsense, plenty of distros offer lightweight DE editions. See Fedora Spins for example [...]

Did I say there are not? I was specifically talking about STABLE distributions.

[torsionbar28]

lol, releasing OS that doesn't support the most expected CPUs of the year. But hey- maybe in 2 years it will start supporting it.

Using Centos on any newish hardware (and i'm not talking about these new zens only) is asking for troubles.

RHEL targets server and workstation hardware. I.e. Xeon, Opteron, EPYC. If you're running desktop peecee hardware, use a desktop peecee distro like Fedora. That said, it doesn't mean it won't work. EPYC and Ryzen are both Zen architecture. If EPYC is supported, Ryzen will work just fine. It's just that they don't commercially support it in their support contracts. RHEL is not really used by consumers, and is more of a business/enterprise distro, so focusing on server chips makes sense here. SLES is the same.

Neither are intel brand desktop peecee cpu's supported in RHEL. No i7 or Core2 or anything besides Xeon. Yet all intel desktop CPU's run RHEL just fine, for reasons already mentioned.

https://access.redhat.com/support/policy/intel

As for "newish" hardware, that's also nonsense. Red Hat back ports drivers and hardware enablement support. Notice in the support matrix linked by whitecat that even RHEL 7 which runs the 3.10 Linux kernel supports the latest EPYC Rome processors. Vanilla kernel 3.10 was released in 2013, long before EPYC, but Red Hat back ported the support, as they do with pretty much all new server hardware. We have RHEL 7 kernel 3.10 running on brand new 2019 Dell and HP servers, officially supported by both Dell and Red Hat, so clearly it works great on the very newest hardware.

Do you have active RHEL support contracts? I suspect not, likely you're just blowing smoke vs voicing a real customer concern. We have hundreds of active RHEL licenses here, so I can speak from experience on this.

[hughesjr]

Fedora works great as a workstation OS, but CentOS works great as well. 3.28 GNOME, Libre Office 6.0.6.1, Firefox 68.0.1 ESR, Thunderbird 60.0.9 ESR, pidgin 2.13.0, EPEL packages.

If you want newer things than that, by all means Fedora is also fine.

When new devices are added to 5.x Linux Kernel.. Red Hat backports things they want to support. So device support, as already pointed out, is much newer than 4.18.0.

Also, if you want more hardware support, use elrepo's hardware drivers here:

https://elrepo.org/tiki/FAQ

Elrepo also has 5.x kernels that will boot on CentOS 8 if you would rather have that.

This isn't your daddy's centos 2.1.

[hubick]

I've been running RHEL 8 on my workstation for some weeks now.

My primary issues have been:
- Gnome 2.28 crashes (caused by DashToPanel extension, fixed upstream in 2.30).
- Old TLS removal (Firefox won't connect to old https websites, impacting me at work).
- Missing gvfs-nfs (can't mount NFS from my NAS in Nautilus).
- Getting ffmpeg for video codecs in Firefox (needed libSDL2 from el7).
- Missing 'openconnect' and 'NetworkManager-openconnect' for my VPN (had to do a lot of hacking w el7/gnutls packages).

I've got a thread on twitter here with more details if anyone is curious.

[anarki2]

To add to what Rahul said, that upgrade path is also only for RHEL. There is no tooling rebuilt by the CentOS team as it just wouldn’t work. The upgrade patch for CentOS is backup and reprovision.

Cheers,
Mike

Fair enough, same as with the 6->7 switch then. Thanks.