CentOS 8.0-1905CentOS is a community-run project which builds its distribution from the source code of Red Hat Enterprise Linux. The project's goal is to provide a binary compatible, nearly identical experience to Enterprise Linux, but without the commercial support provided by Red Hat. This makes CentOS an attractive option for people who want to have a distribution with long-term support and the same technology Red Hat provides, but feel they do not need vendor support.I reviewed Red Hat Enterprise Linux 8 (RHEL 8), briefly covering the distribution's installer, software and settings management, several of its Workstation features, and a few of its server technologies, such as Cockpit. I ran into several issues during that experience - some of them relating to documentation, some dealing with permission problems, some due to missing applications in the official repositories - and I was curious to see if CentOS would provide the same experience, problems and all. One could assume so given CentOS uses the same source code, but CentOS has its own website and repositories so I thought it would be worth giving it a test run and seeing what differences, if any, I could spot. In particular, I planned to focus on the strengths and weaknesses I observed in the conclusion of my RHEL 8 review.
Before I get to my experiences with CentOS 8.0.1905, I feel it is worth mentioning that CentOS is now available in two branches: CentOS Linux, the traditional, fixed release operating system based on RHEL; and CentOS Stream. The new Stream branch is described as a rolling release platform which will fit in somewhere between Fedora and RHEL. The idea appears to be that software and concepts will get their initial testing in Fedora. Then Red Hat will fork a version of Fedora to be the basis of a future RHEL release. Changes and improvements that would normally be made internally within Red Hat prior to the next RHEL will become available for the public to try and comment on in CentOS Stream. Ideally, the plan here seems to be that this will give a larger portion of the community a chance to try new ideas and report issues, giving Red Hat more feedback and a chance to polish their commercial offering.
Both CentOS Linux and CentOS Stream are available in two editions, the DVD edition and a net-install edition called Boot. CentOS Linux's DVD is 6.7GB (about the same size as RHEL 8) and the Boot edition is 534MB. CentOS Stream's DVD is larger, 8GB, but the net-install disc is 533MB.
CentOS's release notes include a section dedicated to known issues. One of these warns against installing the "Server with GUI" package set in VirtualBox: "If you are planning to install CentOS-8 in a VirtualBox guest, you should not select "Server with a GUI" (default) during the installation." The release notes link to a Red Hat article which confirms this warning, but without a reason as to why this would be a problem. Since "Server with GUI" is the default role selected in the installer we need to remember change the role if we are using VirtualBox.
Installing CentOS was, as far as I could tell, identical to installing RHEL, at least during the initial configuration. When packages have finished copying to the hard drive and we reboot, the first-run wizard asks us to accept a license. With CentOS this license agreement is just a disclaimer and a notice that CentOS uses the GNU General Public License. This is less legal material to go through than what RHEL provides. The license activation step used by RHEL is not present in CentOS, we are not required to register our installation with anyone.
CentOS offers the same desktop options: GNOME Shell and GNOME Classic, both available through X.Org and Wayland sessions. RAM usage and performance appears to be virtually identical in all of the session options when compared next to their RHEL counterparts. The menus and software selection also appear to be the same, along with the default settings.
CentOS ran smoothly on my workstation and detected all of my hardware. The desktop, audio, and wireless networking all worked properly. Like RHEL, CentOS worked well on my physical hardware. Trying to run CentOS in a VirtualBox instance was another matter. Like RHEL, CentOS does not provide VirtualBox guest modules and cannot integrate with VirtualBox or use the host computer's screen resolution. To complicate matters, neither distribution provides a VirtualBox module in their repositories.
When I was testing RHEL 8, I tried to build the generic VirtualBox module and it failed, at first, due to a missing package: elfutils-libelf-devel. Once this package had been installed, I was able to build the add-on module and install it without further problems. I tried this on CentOS, installing elfutils-libelf-devel and then building the VirtualBox guest module. This appeared to work and the process reported the module had installed successfully. But it was soon clear the module was not working.
I investigated and found that, despite the build process reporting success, the module had not been installed anywhere on my system. I then went down through the list of dependencies VirtualBox has and discovered that while the compiler, build tools and header files were all available, Perl was missing. For some reason the build process reports success (and silently fails) when Perl is not installed. I installed Perl and had no further problems. I'm not sure why this happened on CentOS and not RHEL (perhaps there are different default packages in the install) but I eventually got it sorted out and the distribution running smoothly in the virtual environment.
Working with software packages was the area where I saw the biggest differences between RHEL and CentOS. There were some similarities as both use the DNF command line package manager (most documentation refers to the package manager as YUM, but YUM is just a symbolic link to DNF). Both distributions use GNOME Software as the graphical front-end for installing new packages and downloading updates. Where things differ is mostly with regards to permission/configuration issues.
For instance, when I was running RHEL there were no available applications listed in GNOME Software. CentOS is able to show installed software in GNOME Software, and a few Featured Items. However, beyond these few items there are virtually no applications listed. Searching for almost any application turns up no results, even when looking for packages I knew existed in the repositories. For example, searching for "thunderbird" on the command line works, but the same search does not work in GNOME Software. Searching for "gimp" in either tool presents us with the GNU Image Manipulation Program.
CentOS 8.0.1905 -- Comparing searches between GNOME Software and DNF (full image size: 76kB, resolution: 1280x1024 pixels)
Another difference was I could perform searches for packages on the command line without using sudo on CentOS. When I was running RHEL any package manager searches performed without sudo (or root) permissions would fail.
CentOS, like RHEL, has a small subset of software compared to the Fedora repositories. While many core and server-related software bundles are available, most workstation software I tried to find was not. I could find GIMP and Thunderbird, but little else. There was no VLC, no MPlayer, Clementine, AbiWord, K3b, Audacity, Chromium web browser, or media codecs. I had hoped to fix this by enabling third-party repositories such as RPMFusion, ELrepo, and Fedora's EPEL repository. Exploring these repositories I was able to find the VLC media player, and some codecs, but the other packages remained unavailable.
Some software I found would not install. CentOS, like its parent, makes MP3 codecs available, but is missing video codecs for most popular formats. When trying to play a video file, GNOME Software would offer to find the missing codecs. The software manager did successfully find multiple codec packages I could download and most of these worked. However, not all of the codec packages would install successfully and no error message was produced to explain why. I suspect there is a conflict between the repositories/packages available, but GNOME Software will not explain why it refused to install a package.
When I was running RHEL any time I made a typo on the command line, such as typing "sl" instead of "ls", the shell would lock up for several seconds and then display an error message relating to a failed package search. This does not happen on CentOS. Making a typo such as "sl" immediately produces a suggestion asking if I meant to type "ls". Likewise, typing "ttop" suggests using "top". There is no delay or error on CentOS, just the helpful tip.
I believe Flatpak, which is installed by default, deserves a mention. Many users, finding that CentOS and third-party repositories are missing many popular applications, will probably consider turning to Flatpak to fill in the gaps. This could prove difficult in practise. To start with, there are no repositories enabled by default on CentOS. I went to Flathub and the instructions for enabling the repository on RHEL/CentOS say to simply download a file and install it. Which sounds simple, but CentOS does not recognize the file type, meaning we can't install or launch it automatically - we need to work with it from the command line manually. I then tried to enable the repository manually using the file, but its digital signature was reportedly not trusted. I eventually enabled the Flatpak repository manually using the command line.
CentOS 8.0.1905 -- Playing music in Rhythmbox (full image size: 146kB, resolution: 1280x1024 pixels)
When I was running RHEL I was unable to install any Firefox extensions. I tried several, after updating my copy of Firefox, but none worked. Each of the Firefox extensions I downloaded using CentOS worked flawlessly.
CentOS, like RHEL, allows remote root logins by default, even in the Workstation role. This is convenient for people doing remote setups, but also a security hole that most other distributions have closed. On the other hand, CentOS enforces RHEL's complex password rules - requiring accounts have either long, complex passwords or no password at all when they are created.
CentOS ships with the Cockpit web-based, remote administration software installed, though not enabled. This mirrors my experience with RHEL. I really like Cockpit and how it gives easy access to several administrative functions. Using Cockpit I was able to manage services, check resource usage, and view logs.
When I was running RHEL I was unable to install updates or new applications through Cockpit. While running CentOS, I could check for (and install) package updates. However, Cockpit under CentOS, was unable to find any applications for me to install.
The experience I had with CentOS is very similar to my experience with RHEL, as is to be expected. Both distributions are using the same source code and the same versions of utilities. There are little differences though, most of them in the field of software management and the initial setup.
While CentOS's install process is virtually the same as Red Hat's, the process of getting the install media is entirely different. With CentOS one can just go to the project's website and click the appropriate download link. Red Hat requires registration (even for the free developer version), browsing through product versions, and picking the right edition. Then we need to accept on-line registration the first time we run the distribution.
Package management on both distributions makes use of the same tools, but the experience was night and day. On RHEL GNOME Software didn't work for finding and installing software at all. On CentOS it worked a little, though with a limited selection and with some packages quietly refusing to install. DNF worked much better on CentOS and didn't require administrative access to perform simple searches. I don't know if the difference lies in a configuration change, or bug fixes that have been applied and trickled down to CentOS over the past few months.
One of the biggest differences though is just a matter of timing. When I tried RHEL 8, third-party repositories had not had time to populate yet. By the time CentOS 8 came along, third-party package sources were up and running, providing some (though still not nearly enough, in my opinion) packages to fill in the gaps.
Otherwise the two distributions, in their default software, desktops, performance, and hardware support appear to be identical. CentOS is a more accessible, free version of RHEL, and will probably appeal to most people who do need enterprise-grade software, but do not need commercial support.
* * * * *
CentOS/RHEL on the desktop
I would like to add a few comments about using Red Hat Enterprise Linux and CentOS on a desktop machine. After my review of RHEL 8 came out, several people raised questions as to the value of testing RHEL on a workstation or laptop. Red Hat's operating system is mostly used on servers, the argument went, so why discuss how RHEL runs in a desktop environment? Why talk about GNOME Software, GNOME, and Wayland on an operating system that is often run headless?
It's a fair point, Red Hat products (and CentOS) are typically seen on servers. Which is why I talked about command line package management and server tools such as Cockpit more than usual. However, I think there are at least three reasons why also talking about these distributions running on workstations is important:
The default role CentOS's installer selects is "Server with GUI". CentOS and RHEL may be used mostly on servers, but their default setting is to install graphical tools. I think it's reasonable to test software that is likely to be installed by default. Several of the alternative roles also install desktop software.
Red Hat's release notes specifically talk about desktop features like Wayland. I suspect they wouldn't advise users of these features unless they expected people to use them. On a similar note, while RHEL is famous for running on servers, many professionals run these distributions on their workstations, particularly at work.
Earlier this year Red Hat published an article called Why You Should Be Developing On Red Hat Enterprise Linux. The article lays out suggestions as to why developers should be using RHEL on their workstations. The professional desktop user is a market Red Hat is actively targeting. If Red Hat wants developers, like me, to run RHEL on our workstations and laptops I think it is reasonable to take them up on the suggestion.
* * * * *
Hardware used in this review
My physical test equipment for this review was a desktop HP Pavilon p6 Series with the following specifications: