I’ve create a Red Hat developer account for myself ( https://developers.redhat.com/ ) and downloaded my free (as in beer) RHEL 9.2 ISO for eventual installation later. I’ve done this primarily because of the (lack of) security in the repository chains that open source depends upon. A bit of cursory investigation shows that Red Hat may be big and corporate but I’ve come to believe they’re more trustworthy when it comes to the quality of the Linux product they deliver as well as support. That support costs, but it’s the kind of corporate support that corporate users demand.

To give you an idea as to what corporations are transitioning away from CentOS to RHEL, there’s the example of Salesforce, who’ve announced they’re migrating some 200,000 server-class machines from CentOS 7 to RHEL 9 (see link below). And that’s just one example. If you can believe the statistics, more than 90% of the Fortune 500 that use Linux use RHEL. I have no idea what the other 10% use, but it might just be Ubuntu primarily.

I have downloaded the RHEL Desktop 9.2 ISO, and I will spin up a small VM under Virtual Machine Manager and begin the process of determining how to migrate from Linux Mint to RHEL. I want to, in particular, determine if I can continue my Espressif/Arduino/Micropython development with external boards. Espressif has stated on their Github page that they support Ubuntu/Debian and CentOS 7/8. I’m assuming that this hasn’t been updated in a while due to the versions of CentOS the documentation calls out, but since CentOS was supposed to be bug-for-bug, feature-for-feature exact, then I see no reason why the Espressif tool chain won’t work on RHEL 9.x.

Once this is done my daily driver system will be Red Hat. I’ll only use other distributions if that’s what is supplied with hardware, such as, for example, Raspbian (Debian) for Raspberry Pi 4 and 5, or Ubuntu for the nVidia development boards.

Links

moving away from red hat to debian

Automation at Scale: Migrating 200,000 Machines from CentOS 7 to RHEL 9 — https://engineering.salesforce.com/automation-at-scale-migrating-200000-machines-from-centos-7-to-rhel-9/

Espressif Standard Toolchain Setup for Linux and macOS — https://docs.espressif.com/projects/esp-idf/en/latest/esp32/get-started/linux-macos-setup.html

Linux Mint 30.2 is derived from Ubuntu 20.04 LTS, Focal Fossa. That’s not a bad thing per se, but the kernel and tool versions are from two years ago. That may or may not cause issues. As an example pre-installed Python is at version 3.8.10. A check on python.org shows version 3.8 is at 3.8.13. Minor point releases are usually bug fixes, which might include security fixes as well. I’ve yet to dig in and find out. In any event if I were to go with Linux Mint I’d build my own latest version and install it in parallel with the default version, as I have done countless times before. Followed by creating a virtual Python work environment.

It has been many years since I worked with Linux Mint, so I slowed down and took some time to explore and become reacquainted with this distribution. It’s a pleasant experience with interesting little touches. For example I was able to quickly find a theme I liked and installed it. And that’s when I noticed a problem with every Gnome-based distribution; wasted space on the window chrome. The top window bar in particular is huge, giving every window the digital equivalent of a high forehead. And that’s without a menu. Windows and macOS have much thinner upper window borders, and the controls and text that are a part of those borders are better designed and integrated. It’s all about efficient use of screen real estate; Gnome is not efficient.

In a way, because it’s based on Ubuntu 20.04 LTS it’s a bit like stepping back in time. And a reminder of what I left behind, both good and bad. And a reminder that perhaps the bad wasn’t all that bad after all. I even like how I was able to find another decent wallpaper, at least to me:

It’s called Red Waves and is part of the Una image collection in Backgrounds. And one more nice little touch:

Right mouse click on the Mint desktop, go down to the very bottom of the pop-up menu where it displays Customize and click to bring up this dialog. See the slider on the far right and the one at the very bottom? Those are used to tweak the horizontal and vertical distances between the desktop icons, independently of each other (i.e. you can just change the vertical distancing if you’re fine with the horizontal distancing.) As I wrote earlier, a number of nice little touches.

As for my pain points:

• There is no brltty.
• Parallels Tools installed just fine, which allows me to share a folder on my Mac with all my other VMs and the native Mac environment.
• The Mint desktop is Xorg and works just fine in a Parallels virtual machine on a macOS desktop.

I don’t know yet if I’ll replace Pop!_OS with Mint, but it’s a serious contender. A very serious contender.

And what about Alma Linux, you ask? Alma Linux advertises it’s a clone of CentOS, which is a clone of Red Hat, and brother, are they right about that. RedHat is Corporate Linux all the way, as are the derivatives CentOS and AlmaLinux. And I’m here to tell the world I have no use for Corporate Linux. I’m glad that RedHat is here for the corporate types as it keeps them away from me. I am concerned that Ubuntu is evolving into another Corporate Linux, which I find disturbing.

AlmaLinux ( https://almalinux.org/ ) might be one of those alternatives. Originally created by CloudLinux Inc ( https://www.cloudlinux.com/ ) as a fork of their Linux distribution CloudLinux OS, Alma Linux is “an open-source, community-driven project that intends to fill the gap left by the demise of the CentOS stable release. AlmaLinux OS is a 1:1 binary compatible fork of RHEL® 8 guided and built by the community. As a standalone, completely free OS, AlmaLinux OS enjoys $1M in annual sponsorship from CloudLinux Inc and support from other sponsors. Ongoing development efforts are governed by the members of the community.” To help allay any fears that Alma/Cloud isn’t mature enough, CloudLinux OS “is a RHEL fork that has been in place for over ten years.”

I’ve downloaded the AlmaLinux ISO and created a VM under Parallels Desktop, and so far it behaves just like CentOS, at least for me. What AlmaLinux lacked was an up-to-date version of Python, so I set about building an alternative installation of Python 3.9.5, the current (as of this posting date) Python release.

Setup

Like every other RHEL 8 and its clones, the base OS isn’t set up to successfully build all of Python, including many of its modules. So the first thing you have to do is install all the various support libraries and several applications that Python needs to build.

Let’s start by installing the following list of libraries. These match what I’ve documented in the past for Ubuntu, except that the package names are different for RHEL/AlmaLinux.

sudo dnf install zlib-devel ncurses-devel gdbm-devel nss-devel openssl-devel readline-devel libffi-devel sqlite-devel bzip2-devel

Next install Tk. This will also pick up Tcl, the dependency.

sudo dnf install tk tk-devel

Install these last bits for some obscure libraries.

sudo dnf install lzma xz-devel

Because I’m also working with PyQt6, I need to install the full Qt tool set. This won’t stop Python from building, but after installing Python 3.9.5 and installing PyQt6, any PyQt code you write won’t run. You need this package for the PyQt6 runtime.

sudo dnf install qt qt5-qtbase-devel

Build

Download the Python source and untar it into some area on your system. In the same folder where you untarred the source, create a build directory, such as build-3.9.5, and change directory (cd) into it. Then run the following to configure the build environment.

../Python-3.9.5/configure --enable-optimizations

When finished, run make, then make altinstall where your new Python will be located in /usr/local/bin.

Install and Test

You’ll need to add /usr/local/bin to your path in your .bashrc. Bring up a new shell, or source ~/.bashrc in your current shell, and you should be able to test Python, python3.9 --version.

References

Red Hat resets CentOS Linux and users are angry – https://www.zdnet.com/article/red-hat-resets-centos-linux-and-users-are-angry/

But no more after the end of 2021.

RedHat decreed this week that regular CentOS would be replaced by CentOS Stream, a rolling distribution of RHEL. That has lit a fire under a whole lot of folk who were depending on CentOS 8 to have a 10-year run, up to the end of 2029, instead of the end of 2021. So anybody who built or is building an important part of their business on top of CentOS has been blown out of the water.

So why did this happen? Here are my personal theories based on the current circumstances. Remember that RedHat is owned by IBM. IBM closed that deal back in July 2019 and paid a princely $34 Billion dollars. Even for IBM that’s a lot of cash, and IBM is going to want a decent ROI, with ‘decent’ defined by IBM. IBM is not going to look kindly on a distribution supported essentially by RedHat, based on RHEL, that nobody pays for. Remember that before IBM acquired RedHat, RedHat started “sponsoring” CentOS and obtained the CentOS trademarks. RedHat essentially purchased CentOS, naming it the CentOS Project. This added to Fedora Linux, RHEL’s upstream development distro. When IBM came along and made its acquisition it gained control of all three.

So what does all this mean?

• IBM spent $34 Billion to acquire RedHat, which includes RHEL, CentOS, and Fedora Linux. The majority of the money will come from RHEL, meaning paying customers. IBM’s attitude is if you want the stability that RHEL provides, then you need to pay for it. A lot of money has gone into making it stable, even more in marketing it and convincing major Linux users to use RHEL and to pay for RedHat support and services. IBM does not look kindly on those who get a free pass with CentOS.
• IBM’s attitude is if you want to not pay directly for RHEL, then you can help by being a beta tester. Make no mistake, CentOS Stream is upstream and beta to RHEL. You get to try out all the new and exciting features and report any problems. Sigh me up!
• Finally, you now have an opportunity to have your GitHub pull request more ‘seriously’ considered, which means you can volunteer to fix issues and be a part of the Open Source Software unpaid legions. Sign me up!

You can talk about RHEL all you want, more out of inertia than any other reason, but at the end of the day it’s all IBM and will remain all IBM until IBM either completely subsumes RedHat et. el., or it sells it on again after stripping out all the good bits.

As for a replacement to CentOS, you might want to look at Oracle Linux. Oracle sees this change to CentOS as a golden opportunity and has thus opened up its distribution. I personally was able to download Oracle Linux 8.3 and spin up a VM using Parallels on my MBP. It was very easy to install and get running, more so than CentOS. And that was no typo. Oracle Linux 8.3 is tracking RHEL, which is also 8.3, a lot faster than CentOS. CentOS didn’t step up to 8.3 until sometime this week (I know this because I ran dnf to update, and pulled down nearly 600 packages. When dnf was finished my CentOS VM was at 8.3.2011).

There is one very good reason to use Oracle Linux, and that’s the version of the kernel it’s using. Right now heavy Linux kernel development is with the 5.x version kernels. Everything earlier than that, such as the 4.x version kernels, are essentially in sustainment. RedHat, and thus CentOS, are using a 4.18 kernel. If you query Oracle Linux, this is what it shows:

[oracle8@oracle8 ~]$ uname -saLinux oracle8 5.4.17-2036.100.6.1.el8uek.x86_64 #2 SMP Thu Oct 29 17:06:00 PDT 2020 x86_64 x86_64 x86_64 GNU/Linux[oracle8@oracle8 ~]$

It’s certainly not the latest 5.x kernel, but it’s both current and stable. The other tools aren’t up to date (for example, Python is version 3.6.8), but I can work around those issues far more easily than swapping out an older kernel for a more up-to-date kernel.

My only qualm with Oracle is that it’s Oracle I’m dealing with, and with great suspicion. I suppose I shouldn’t look a gift horse in the mouth, but I don’t trust Oracle all that much these days because of the way Java has been blown up by them.

There will more than likely be other CentOS replacement distributions if the rage on the various fora are to be believed, and I’m sure there’ll be a number of noble efforts. Unfortunately the Linux road is littered with the rotting carcasses of distributions that were all hailed as Great Ideas, but nothing came of them after a time because of the inertia over keeping with the established players. My advice is if you’re unhappy with CentOS then consider either Ubuntu or Suse. For me the choice is between Ubuntu and Oracle Linux.

Link: https://arstechnica.com/gadgets/2020/12/centos-shifts-from-red-hat-unbranded-to-red-hat-beta/

Several posts back I commented on running RHEL 8, and one of the really nice features of RHEL 8, Cockpit. Cockpit is a web-based set of dashboards for managing an instance of Red Hat/CentOS linux. It’s provided and maintained by the Cockpit Project.

I installed an instance on a CentOS 7.6.1810 VM I’ve got running on my MBP under VirtualBox. I’ve had this instance for some time now, having exported it out as an appliance (primarily as a backup) and imported it again a number of times. It now has PowerShell 7 Preview installed as well as Visual Studio Code. And now it has Cockpit. Installation and enablement are on the Cockpit Project website, and it’s extremely easy to get going. What follows are a few extra screenshots showing just a small aspect of Cockpit’s capabilities on CentOS 7.

There’s not much more to say except if you’ve ever had to remotely manage a Windows Server instance with RDP, then remotely managing a Linux instance (besides logging in via ssh) is like paradise compared to RDP. The Cockpit dashboards are more than just adequate, and for this instances where you really need a shell/command line, the web interface will provide that as well. The only actions you can’t do are starting a GUI application. Otherwise it’s just really nice to open multiple web browser tabs for multiple Linux VMs.

If you haven’t looked into Cockpit, then you should. I believe it’ll be worth your time and effort.

Here’s my personal review of Red Hat’s latest, RHEL 8. It’s not much, so if you’re looking for something far more in depth, then you won’t find it here. Instead I look at it from the perspective of an end user who’s used older versions, and try to determine if I should use this latest version.

RHEL 8 was formally released 7 May 2019, a little less than a month ago from the date of this post. It’d been out in beta form before that, as I noted by a number of comments in various fora around the end of 2018. But I stayed away from checking this latest RHEL release, due in no small part to my less than happy experiences using RHEL 7 and its unpaid version CentOS 7.

From what I’ve seen so far it appears that RHEL 8 may actually deserve its primary version increase. The upgrades across the board are substantial enough. If I wanted a RHEL-like distribution with up-to-date tools, why not use Fedora? Because I DO NOT want to deal with Fedora’s peculiarities and periodic ‘bleeding edge’ breaking changes within Fedora releases just to keep up with the latest packages. All I ask of my Linux distributions is that they are reasonably up to date in the core tools and will work without special handling in just about any environment. There are a lot of distros that can do this, but Fedora isn’t one of them. I haven’t used Fedora since its late teen releases, and I don’t expect I ever will again. But it would appear that RHEL 8 now falls within that categorization of easily up-to-date and easy-to-install. Thank you Red Hat.

It looks like there might be just a tinge of desperation at Red Hat Central. I say this in large part noting how RHEL 8 is being launched. In the past, when I went to download and install a developer version of RHEL 7, I jumped through a fair number of hoops to get an ISO. After installation I was reminded periodically that my ability to install updates was time limited. RHEL 8 on the other hand is noticeably different. Everywhere I look and read there are articles about RHEL 8 as a development platform. When I went and logged recently into Red Hat  Developer, I was immediately led to the download section where I easily found and downloaded my ISO copy. After installation as a VM in Oracle’s VirtualBox (6.0.8 as of this writing) on macOS 10.14.5, and after registering with my developer credentials to keep my installation up-to-date, I was not greeted with any kind of time limitation warning. It still annoys me I have to register to get the updates, which is one big reason I prefer CentOS; CentOS updates are just a simple yum away.

I think that desperation might be rooted in the observation that Red Hat might not be relevant to a lot of developers these days. Red Hat’s biggest competitor I believe to be Ubuntu. I’ve read a number of stories where developers, especially AI developers, are now buying machines with Ubuntu desktop pre-installed. And I’ve watched Ubuntu pushing out not just into the server side but into cloud containers as well IoT images. Yes, I know all about Red Hat’s push with Kubernetes. But that’s countered in part that Red Hat is now owned by IBM, and I can assure you that I at least am not happy about IBM in the mix. That’s another reason I’ll get my images from CentOS and go elsewhere for my cloud needs.

RHEL 8 is actually using a fairly recent Linux kernel, 4.18, as apposed to RHEL 7 and RHEL 6, which stuck with a version 3 kernel, heavily patched. And the tools supplied in RHEL 8 are also fairly up-to-date; gcc is at version 8.2.1, git is at 2.18.1, and Python (or python3) is at version 3.6.8 (python2 isn’t even installed). So the quality of the tools in RHEL 8 is, in my not-so-humble-opinion, a big step up over RHEL 7, and about time. All of this is out-of-the-box.

There were some additions and tweaks. For example I added gnome-tweaks to get the Tweak Tool and enable dark mode via Adwaita-dark. I also enabled all the control buttons on the right corner of each window and enabled having the application’s control menu on the application’s left side. That last “feature” really bothers me. This is yet another attempt to copy an Apple macOS feature. That feature looks great on macOS, but it’s always looked bad on the Linux desktop. Seriously, if you want that look and feel then buy a Mac. And finally, for running RHEL 8 as a VM in VirtualBox 6.0.8 on macOS Mojave 10.14.5, you need to select running the VM’s desktop as a standard Xorg X windows system, rather than using Wayland. Wayland does not play well with VirtualBox and it hasn’t since Wayland was first officially released with RHEL, going back to VirtualBox 5.x. You pick that at the login screen (see the little gear on the lower right beneath where you type in your password). If you don’t do that you’ll see nothing but constant tearing and flashing of the virtual display.

My installation was bare-bones, just enough for the tools (compiler tool chain primarily) without any games or social media or office software. As pure as possible to just a desktop and basic developer tools. To that I added htop, Amazon’s Corretto Linux release (Java 8 212), Microsoft’s Visual Studio Code editor and IDE, and Microsoft’s PowerShell Core 7 Preview 1. The following three show htop, Visual Studio Code, and PowerShell respectively.

There’s a reason for these specific applications. The same applications run on macOS and Windows 10. That means that given the same languages (Python and Java, for example) or advanced C++ compilers that support the latest C++ standards (gcc 8.2 and Microsoft’s Visual Studio, for example) as well as the same CM tool (Git), then there is no longer any reason to remain committed to a single platform. Commit all your work up on Github, and then move from platform to platform as the need may be to get your job done. And I very much like the idea of PowerShell being common across all the platforms.

I believe RHEL 8 is going to be a very solid release, the best in a few years. The only issue is with other distributions, the biggest competitor being Ubuntu. I run a mod of Ubuntu from System 76 called Pop!_OS. It too has Corretto Linux, Visual Studio Code and PowerShell. I like Pop!_OS primarily because of its very excellent looking desktop out-of-the-box. For all practical purposes RHEL 8 has achieved parity with the latest Ubuntu release and derivatives.

Update January 2020

I deleted the Pop!_OS VM some number of months back because it seemed to have corrupted itself. I’ve only had one other Linux distribution do that, and it was Arch Linux.

On RHEL 8 I’ve replaced Amazon’s Corretto Java with AdoptOpenJDK (https://adoptopenjdk.net). PowerShell 7 is now up to Release Candidate 1.

This is probably one of the lamest posts I’ve ever written. I leave it here as example of how far into the weeds I tend to get. If you want to use macOS (as it’s now known) to support Raspberry Pi development, and in particular to program Linux images onto micro SDHC cards, then download balena Etcher from https://www.balena.io/etcher/ and install it. Etcher is extremely easy to use, walking you through the three steps necessary to create a bootable image on a card. Don’t do what I did below; that’s just an absolute waste of time.

Original Post

You’re viewing CentOS 7 running in VirtualBox 5.0.16, with a micro SDHC card mounted and in turn viewing the Arch Linux ARM ext4 native Linux filesystem I created for my RP3. When I originally created the RP3 micro SDHC card I used my Ubuntu 15.10 notebook as the workbench. But I’ve been wanting to do similar work using my MBP as the primary tool bench, with an eye towards retiring the native Ubuntu notebook with the MBP due to the Ubuntu notebook’s age, rather than attempting to replace the Ubuntu notebook as I’ve written I originally wanted to do. The biggest hurdle to using the MBP was just reading the native ext4 file system on the MBP, as Max OS X has no native provisions to read Linux file systems. This post is about getting to that point. As time goes along I’ll be doing more than just reading the microSDHC, but reading (and then writing) is the foundational requirement, else this is all a waste of time and resources.

Before I go much farther let me properly attribute this from another post, “Mount SD card in VirtualBox from Mac OS X Host,” written by Brady Holt on 21 July 2014. Please note this was done nearly two years ago. This is an update to his post using contemporary software and with my observations.

Software and hardware I’ll be using:

• OS X El Capitan, version 10.11.3 running on a MacBook Pro (Retina, 15-inch, Mid 2015)
• VirtualBox 5.0.16 with Oracle_VM_VirtualBox_Extension_Pack-5.0.16
• CentOS 7 with all updates as of the date of this post with VBoxGuestAdditions_5.0.16 running as a VM

I’m going to create a Linux VM with VirtualBox and use that to mount and at least read the micro SDHC card with the Arch Linux ARM ext4 file system. I had originally looked for a Mac OS X utility to do this, but eventually gave up as the utilities that claimed they could do that had allegedly stopped working with the release of El Capitan because of System Integrity Protection, or rootless, mode. Far be it from me to disable in El Capitan what is supposed to add additional security to OS X. I’m somewhat surprised that I could get this to work, but I suppose that if, at some point in the future, Apple releases a Mac OS X update that breaks what I’ve built here that I’ll be back to using a separate Linux machine.

The first step is to install VirtualBox and then to install CentOS 7 within a VirtualBox VM. I won’t cover that here, as there are plenty of existing how-tos for that. Just make sure that the Virtual Box Extension Pack is installed and that you’ve downloaded and installed the VBoxGuesAdditions and have built it within the VM. That gets everything prepared both on the OS X host side as well as within the VM.

The next step is to get the overall system prepared to mount the RP3 micro SDHC card within the CentOS 7 VM.

1. Plug in the microSDHC card into the MBP using the microSDHC adapter. I’m using a Samsung 32GB Evo Plus device. Note that it’s named “NO NAME” on the desktop. This is the MSDOS 100MB boot partition on the microSDHC card.
2. Go to Launchpad and search for diskutil. Launch diskutil. Select “NO NAME.”

3. Click the Info button at the top right. Note the device associated with “NO NAME.” It’s the third line down from the top, called “BSD device node.” In my case it’s disk2s1. The device associated with this partition is /dev/disk2. We’ll use this later.

4. At the top of the utility click the ‘Unmount’ button with your mouse. The button text will then change to ‘Mount.’ Please note you don’t want to eject the device, just unmount.

5. Now we need to create a VirtualBox VMDK file to point to this device. That’s how we’ll get it to mount inside the Linux VM. Open a terminal and type sudo VBoxManage internalcommands createrawvmdk -filename sd-card.vmdk -rawdisk /dev/disk2 at the prompt. The file will be created where ever you run it, so my advice is to change directory to a location where you want this (or preface the file name with a full path) to create the file. Just remember where you left it.
6. Change permissions on the microSDHC device and the VMDK file to 777. At the prompt type chmod 777 sd-card.vmdk /dev/disk2. This opens up permissions for the file and card to be used later by the VM
7. Add sd-card.vmdk to the VM’s storage devices. In VirtualBox, under the CentOS VM, select the Storage dialog, and in the Storage Tree under Controller: SATA click the add device button. You will be prompted to either create a new device or add an existing device. Choose to add existing and add sd-card.vmdk.
8. Check diskutil one more time and make sure that the microSDHC card is still unmounted. OS X has automount and can silently remount the drive. If it does then you will fail to start the Linux VM.
9. Once the VM is started bring up Nautilus and note two new ejectable entries for the card, a 103MB entry and a 32GB entry. Click on the 32GB volume. You’ll be prompted by Nautilus to enter root’s password for that VM to view that volume. Once that’s done Nautilus opens into the 32GB volume. You can drag and drop files into and out of the midroSDHC’s 32GB volume. I do this to add content as well as pull log files while developing.

One caveat. If you shut down the VM and then want to bring it back up, you’ll need to unmount the microSDHC card like before and execute chmod 777 /dev/disk# again, or the VM will fail to start due to lack of permissions on the raw device.

There are a number of key differences between CentOS 7 and Ubuntu 14.04. One that’s important to me is support for RPM (Redhat Package Management) install files as opposed to Ubuntu’s DEB (DEBian) files, and all the tools built around those formats. Truth be told I prefer rpm and yum to deb and apt-get, although when you compare them dispassionately there’s really very little difference between them. Those folks that claim there is are the “fan boys (and girls)” of their distribution. I’ll be honest enough to say that long years of experience make me more comfortable using rpm, but that doesn’t make it overwhelmingly better.

One language I use and develop with is Java, choosing to use the official Oracle releases, which are pushed out either as ZIP, TGZ, or RPM files. No DEB files. It’s far easier to install via RPM on RPM supporting operating systems, such as RHEL/CentOS, Fedora, and openSUSE. If I want to use Oracle Java on Ubuntu then I have to go through some additional gyrations unpacking the TGZ file, as I’ve documented in previous Ubuntu posts.

In order to use Oracle Java I have to completely uninstall the Open Java/Iced Tea variants that just about every distribution wants to install. I dislike all those variants because they’re incomplete, don’t operate as correctly as the official Oracle release, and are always a few releases behind. And every time I uninstall Open Java I’m also forced to uninstall Libre Office due to insane dependencies of Libre Office on Open Java built-in to the distro.

CentOS 7 was no different, but it was straight forward and fast, unlike openSUSE 13.1. After removing Open Java and Libre Office, I installed Oracle Java 8 update 20, then downloaded the latest Libre Office (version 4.3.2.2). Sometimes you need to bypass the repos due to version rot not only for the latest Java, but the latest Libre Office as well. The CentOS versions of Libre Office are at 4.1.4.2 as of the date of this post. The primary driver is that Microsoft Office compatibility in Libre Office 4.3 is much better than in version 4.1.

I just mentioned openSUSE 13.1. That’s because I tried out OpenSUSE 13.1 KDE before settling on CentOS 7. While openSUSE installed fairly well, it had enough oddball quirks to it that I eventually installed CentOS 7 over it. Biggest problem with openSUSE is KDE itself; it’s changed to the point where I don’t like it at all any more. That’s a shock from my early days of 2007, when I fell in love with KDE 3. OpenSUSE is now completely off my radar.

One thing I will say about the latest Linux distributions, and that’s how they all effortlessly handle hardware. With all distributions both screen and network were easily detected and used. The wireless chip set on the R580 was the most surprising success; in all cases the chip set was detected and enabled. All I had to do was pick my home network and give it the password. After that it just ran.

Another big surprise is how all the distributions have current browsers, and how the current browsers handle multimedia. You’re looking at Firefox 31.1 above running a YouTube cat video using HTML 5 (no flash here!), complete with audio. When something as conservatively hidebound as CentOS 7 can run YouTube cat videos without flash, without turning to running arcane post-install command-line tools or installing additional “non-free” software from “non-free” repos, then you know the apocalypse has truly arrived.

Once installed it ran smoothly and without any incidents. I installed Oracle Java as well as the latest Libre Office. I also installed a few tools, such as gcc and g++, and then forked and built the latest node.js off of Github. It all built cleanly, and ran as well as it has on every other OS I’ve dropped it on. I tried some other hackery and it all worked as expected. From a software development perspective, CentOS 7 is like Mary Poppins, practically perfect in every way.

As good as CentOS 7 might be operationally and internally, I do have a number of complaints about CentOS 7. The first is how it looks.

CentOS 7’s desktop, which is their version of Gnome 3, looks like a poorly implemented copy of Mac OS X 10.5 (see above). If I’d wanted that look I’d have bought myself a Mac. Back in 2008 or so. The shadowing looks better on Mac OS X, while CentOS 7’s desktop decorations seem to take up too much space, especially between widgets.

Other annoyances include the desire of the Gnome developers to remove features, such as Nautilus’ ability to show previews (it once did), or the Gnome terminal’s loss of transparency in Gnome 3 (in Gnome 2 it was really very nice), or the inability to select gedit’s color theme (I always go in and select cobalt). Thankfully, they’re features that are still available in the same tools under Ubuntu 14.04. These are the kind of operational issues that tend make people like me cranky.

It’s been interesting playing with CentOS 7 this weekend, and I’ve certainly learned a lot. There’s certainly much to appreciate in CentOS 7. But as much as CentOS 7 has improved over all other versions of CentOS, I think I’ll stick with Ubuntu for the time being. In the mean time the CentOS 7 drive goes into storage until such time as I might have need of it.