1

2 tools that make RHEL my dream Linux

 1 year ago
source link: https://www.redhat.com/sysadmin/rhel-tools-flatpak-toolbx
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

2 tools that make RHEL my dream Linux

Learn how Flatpak and Toolbx make Red Hat Enterprise Linux (RHEL) 8 and 9 both fun to use and capable of handling the serious stuff.

Posted: May 31, 2022 | by Seth Kenlon (Red Hat)

Image
How to set SELinux to enforcing mode

I run Red Hat Enterprise Linux (RHEL) 9 on my laptop, and I have a lot of fun with it. Because I run Slackware on my desktop, I'm used to stability, and that's what I appreciate in RHEL.

In my early days as a Linux user, it wasn't uncommon for me to install a different distro every month (not coincidentally aligned with the release of a new Linux Magazine with an exciting new disc on the front cover). It was a fun way to learn all the nuances of Linux, see the potential pitfalls of system migration, and experience the different ways an operating system can be built. But I'm not a new Linux user anymore. I'm an actual, real-life Linux user. I run Linux, I deploy Linux containers, and I manage Linux servers. To put it bluntly, I have stuff to get done.

When did RHEL get fun?

For a long time, I felt like RHEL was a very specific distribution. It seemed like a lot of effort went into RHEL for servers. Sure, there was a workstation ISO or install option, but those repositories weren't exactly overflowing with desktop applications apart from the obligatory developer and office apps.

The problem was that there was no clear path for "exceptions." What did you do when you suddenly needed libfoo.so.22 (presumably unstable because it's new) but all you could find in the RHEL (or even EPEL) repo was good old stable libfoo.so.19? What about when you needed a video-editing application, but according to the repo, none existed? And so on.

It seemed that any time I wanted to color outside the lines, I ended up borrowing source RPMs (SRPMs) from a Fedora repository from three years ago, do an rpmbuild --rebuild, and by the end of the day maybe I'd have a solution in place. But even that was never easy, because those borrowed RPMs often had dependencies that also weren't in the RHEL or EPEL repositories, and so I'd have to go assemble a meta package of a bunch of SRPMs that each needed to be rebuilt and then installed.

The good news is that I don't do that anymore, and you don't have to either.

You can have it all

New tech is emerging. Actually, new tech has emerged. It was in RHEL 8 and it's in RHEL 9, and it's resulting in my dream version of RHEL.

Those technolgies are Flatpak for graphical applications and Toolbx for the terminal.

[ Learn your options by downloading the guide to installing applications on Linux. ]

Flatpak

Flatpaks on RHEL have already changed the way I interact with the OS. I've produced music and videos and motion graphics, and lots more on RHEL because, regardless of what I'm looking to install, Flatpak makes it trivial to install everything I need. I've written an article about installing applications with Flatpaks if you're new to them, but suffice it to say that from the user's perspective, it feels very much the same as installing an RPM from an official repository.
Better still, it's user-centric, so you can install applications to your home directory even without sudo or administrative privileges.

If you're a developer, you can get a headstart in delivering your application as a Flatpak by reading my building Flatpaks article.

Toolbox

Flatpaks are intended for graphical applications, but there's also the Toolbx project for terminal commands and development. With Toolbx, you can create containerized environments where you can install development libraries, programming languages, and specialized commands independent of what you have installed on your system. The project is called Toolbx, with no "o" in "box," but the command is toolbox, so to create a "toolbox" environment:

$ toolbox create
$ toolbox enter

It's as easy as that. If you're a Python programmer, a Java Maven user, or a cloud-native developer, then having a virtual environment for isolated development probably feels pretty natural. You can develop in your toolbox environment for as long as you like. You can exit the environment and then restart it when you need it again. It provides you with a fresh start that encourages you to understand and plan your whole stack, and it protects you from accidentally developing for your own personal configuration to avoid the dreaded "it worked on my machine" problem.

Not only that, it also enables you to install different versions of commands, or commands that you need one week and then never again, or commands you've been meaning to try but haven't committed to yet. It's a sandbox environment that enables you to experiment and work with almost no regard for the underlying system, because ultimately it's disposable.

Of course, it's not just you who benefits. These technologies enable a safe and flexible "sandbox" for all users. You can install commands and applications, and they run in containers that never affect the base OS.

It's a dream come true.

Recommend RHEL

I use RHEL. It's an OS I can recommend to family and friends, whether they're casual users, power users, or developers. It doesn't matter what you do on your computer. RHEL readily provides for the everyday stuff while maintaining a safe environment for the serious stuff.


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK