I recently re-installed my laptop, which in itself doesn’t deserve fanfare and isn’t of any particular note. At one time or another this machine has had Windows, FreeBSD, and various Linux distributions on it (even Ubuntu when I was writing the Linux Administration Cookbook.) What makes it particularly interesting this time is the fact it’s RHEL 8 that I’ve chosen to install.
RHEL 8, the latest offering from the company newly acquired by Big Blue (IBM,) is touted as both a rock-solid server OS, and also something more than capable of handling the daily tasks of any good developer.
It’s of a slight annoyance to me that RHEL 8 was released when it was (May 7, 2019,) as my book on Linux Administration has only been out a few months, but thankfully it also wasn’t the titanic shift that we saw from RHEL 6 to RHEL 7.
As a bit of background, Red Hat now offer a free installation (including access to their repositories) with a developer account. Simply go to their site, sign up, and you can enable a subscription for your machine easily enough.
Why install RHEL, when CentOS is a thing?
The answer here is mostly, “to give it a go,” but I can expand on it a little more:
- CentOS, while equivalent to Red Hat in terms of compiled software, lacks some features which are RHEL specific, such as the Subscription Manager. If I have an issue with one of these, or want to know more, it’s nice to know the software is already at my fingertips.
- Increasingly I’m working in environments that have Red Hat agreements, and because of that I like to know that the machine I’m working on has the exact same solutions (and problems) as the server OSes I’m touching.
- Solutions to problems frequently come from Red Hat, and are then adopted by other distributions. While this isn’t true for everything, Red Hat being a commercial outfit, means they have customers to please. In the real world this means that RHEL usually has fixes for the latest round of Intel execution bugs before a lot of other offerings, along with detailed ‘issue’ pages surrounding the exploits.
- It’s solid, arguably more so than any other distribution. That isn’t to say there aren’t stable operating systems out there, but Red Hat’s ability to mostly leave things in a stable and consistent state for months, or even years, means I can rely on this laptop no matter which end of the UK I happen to be in.
Of course, these reasons are as full of holes as the front of the latest Mac Pro, but I needed to justify this project to myself, because the last question I wanted to answer was simple…
Can I do my work on RHEL 8?
This was the question I really wanted to know the answer to, because in theory, there’s nothing standing in my way except a bit of patience, and a need to keep things “polished.”
When I say polished I mean that yes, I can install CentOS and then realise I need a more recent kernel, so install one from ELRepo; or I can decide I really want that version of Node.js, so install it from upstream; but soon you start to get surrounded with hacks and fixes that make your OS feel like a clumsy mess.
I have thoughts on keeping your installations ‘clumsy-fix-free,’ and they’re well documented in the book subtly linked above.
I don’t want to install things using Pip, or get additional Gems. I don’t want to have third party repos cluttering my yum.repos.d directory, and I don’t want to compile anything from source (except stuff I’m actively writing or working on!)
Now this is a bit of a problem in the real world, which sadly we live in. I’ll still likely have to concede that installing the latest binary directly from the Hashicorp website is the best way to get Packer or Terraform, and I’m going to resort to Flatpak for some stuff, as you’ll see later, but these are sacrifices that I don’t want to make too many of, and RHEL might be able to do that.
But who knows, maybe even this will get too much for me and I’ll skip happily back into Arch Linux land, confident in the knowledge that everyone who gave me a funny look for installing RHEL on my workstation was wholeheartedly correct.
What these posts are for.
I don’t really expect them to be relevant to many people, not least because I suspect the number of people running Red Hat on their workstation machines is close to the hundreds, rather than the thousands, but I like to document problems and solutions I address when working, and this seems like as good a way as any.
So I suppose, these blog posts are mostly a reference for me, and maybe a couple more oddballs out there who get distracted by red fedoras.