Linux on Douglas Domingos :: CompSci@UFCG

My First Thoughts on Fedora Linux

Sat, 04 Jan 2025 00:32:27 -0300

Introduction

Since my first contact using Linux back in 2020, I’ve tried out many distributions, such as Ubuntu, Linux Mint, Kubuntu, and most recently Pop!_OS. But, as you may already known, these are all Debian-based distributions, so aside from graphical interfaces, they function in the exact same way.

Having expanded my knowledge in Linux throughout the last year, I now feel confortable enough to tweak with more cutting-edge systems. My first idea was to try Manjaro KDE, as Arch-based distributions seemed quite interesting. Yet, after playing around with Fedora through LiveUSB, I’ve decided to stick around with it for now.

The opinions shared in this post are based on the following use cases:

Software Development, mainly in Java, JavaScript and Python environments
Casual tasks and applications (e.g. music and video streaming, web browsing, etc.)
Gaming (i.e. lightweight games via SteamOS and Proton)

I’ve also considered the opinions of other users posted on the Reddit community r/Fedora, which I recommend you to follow for troubleshooting and customizing configurations.

The first contact

Something noticeable even before installing Fedora is that it’s very lightweight - it’s shipped only with Firefox, LibreOffice Suite, and basic applications/utilities. This also applies for GNOME Shell, the graphical interface of Fedora Workstation, which offers a pure, vanilla experience. Sure, finding and testing GNOME extensions for basic funcionalities (e.g. adding app shortcuts to the desktop) is quite annoying, but it’s a classic “install and forget” type of job.

The real deal-maker for me was the package repositories: many of the softwares I use are avaliable in DNF with more recent versions than those in APT-based distributions. Also, Fedora comes with Flatpak pre-installed, only requiring you to add the FlatHub repositories before installing software.

However, not everything is perfect: Fedora’s preference for open-source software means that you may need to manually install proprietary drivers, such as those for Nvidia GPUs, and media codecs like H.264. Fortunately, most of these can be found in RPMFusion - Fedora’s third-party repository. So far, I only had to install a few video codecs for VLC, without any struggles with hardware compatibility. Therefore, your experience with Fedora may vary, depending on your hardware specifications and which programs you use.

Software compatibility

One of my biggest concerns when moving away from Pop!_OS was that some applications I use wouldn’t be compatible, without any satisfactory alternatives. Thankfully, this was not the case, as Fedora’s repositories provided pretty much all the packages I needed. But again, for third-party packages and proprietary software, you may have to reach out for RPMFusion, which is very easy to setup and use.

On the rare ocasions where the softwares you need is not within Fedora’s repositories nor RPMFusion, you can also use Flatpak - a package manager that allows you to install and execute containerized applications, keeping their dependencies separate from the system. I personally prefer flatpaks over native packages, though I’ve seen many users recommend the opposite.

The only cases I believe you may have to opt for alternatives are for packages and applications distributed only through Snap or PPAs. For Snap, however, it’s probable that you’ll find your software within Flatpak or RPM repositories, which was my case for Hugo SSG - the framework used in this website, distributed in Fedora through DNF.

Support and resources

It’s important to highlight that Fedora has far less online resources when compared to Ubuntu/Debian distributions, which means that you may have difficulties finding solutions for technical problems, specially if you have little experience with Linux.

Despite that, I’ve found Fedora to be very similar in usability with Ubuntu distributions so far. The most noticeable difference between the platforms are the package repositories, as Fedora (and RedHat Linux distributions) enphatizes the adoption of Open-Source software, and thus requires add some overhead configuration to allow proprietary packages - which are easily set with only two commands in your terminal.

Although Fedora has proved to be stable and easy to use up until now, I’d still recommend Debian-based distributions for those who have no experience in Linux, or simply have no time to spare on debugging configurations.

TL;DR

With my current experience, Fedora stands out on the following:

Offers a true vanilla GNOME experience, leaving all customizations for the users
Allows users to choose whether to install proprietary software (through RPMFusion) or not
Packages within RPM repositories are offered in more recent versions than in APT

However, I see some possible drawbacks of this migration:

Being a cutting-edge distribution, Fedora may be less stable than Ubuntu
Specific applications may not be available for Fedora
Potential reduced compatibility with older hardware (based on some reports from other users)

Some of this aspects may change as my experience with Fedora evolves, so expect updates in the future.

Installing software in Linux, the "hard" way

Sun, 15 Sep 2024 13:34:18 -0300

Introduction

Picture this: you’re setting up the packages and tools to develop your brand new application. Everything is going smooth, until you found out that one of the softwares you need is only avaliable as package of executable binaries, without any installers and nowhere to be found in your package managers. Seems like quite the overhead, right?

Well, not to worry! Because today we’re out to get our hands dirty and learn how to install ANY PACKAGE in a Linux system ‒ and you might just learn a few new tricks about Linux along the way.

I. Housing the package

The first step to solve our problem is to define where the package will be stored in our system. In practice, you may use any directory you’d like, but to keep things organized, let’s use the /opt directory.

The /opt directory is reserved for installing software and packages that are not part of the system’s core components, i.e, not necessary for your system to function properly.

When installing your package, you should create a new directory (preferably with the package name, like /opt/<package_name>) to avoid mixing up files of different packages.

You may have noticed that inside your package, there’s a /bin directory that contains some executable files. At this point, we can run these files, but we’ll have to specify the full path of the file every time.

II. Make your package avaliable with `$PATH`

To avoid having to pass the full path of the executables each time we run the software, we’ll make use of the $PATH environmental variable to specify the path of our installation.

The $PATH variable is a special shell variable that defines a list of directories where executable files are located. Each directory is delimited by a colon (:)

You may specify new directories in $PATH by exporting the variable with the new value (export PATH=/new/dir/path:$PATH).

Now, there are two ways of adding a executable to $PATH:

Adding a Symlink to the executables

Symlinks are (roughly) files that “point” to other file paths or directories. This allows us to access files accross the file system (and even other file systems), without specifying the full path.

You can create new symlinks using the command ln -s TARGET LINK_NAME, where:

TARGET is the path of the file which the symlink will point to
LINK_NAME is the path where the symlink will be created

To make it avaliable in $PATH, we may create a symlink inside a directory that is already in $PATH. In this case, let’s use the /usr/local/bin directory to store our symlink.

To create our symlink, simply run the following comman:

# Replace the placeholders with the proper names of your directories/files
ln -s /opt/<package_name>/bin/<filename> /usr/local/bin/<filename>

Once created, the executable will be avaliable in your shell. Try it out by typing the name of the symlink in your terminal.

Trade-offs of using symlinks

This approach is pretty straightforward and easy to setup. We don’t need to edit the value of $PATH, thus avoiding possible configuration errors. Also, by placing the symlink inside /usr/local/bin, we make it avaliable for all users of the system.

Unfortunately, there are also drawbacks. If you need to add multiple executables, you’ll need do create one symlink per executable. You may create a symlink to the /bin directory of the package, but you’ll still need to specify the name of the executable.

Links in Linux
Links are a powerful tool in Linux, allowing you to create shortcuts between files and directories, organizing your files easily, and much more. I recommend reading this RedHat post about linking in Linux.

Adding the package directory to `$PATH`

If you want a more robust solution, you may effectivelly edit the $PATH variable to include your package directory. For that, we’ll need to create a configuration file to export our updated $PATH.

The /etc/ directory contains configuration files of system applications, e.g. service management, network, SSH, and many more. Be careful when making changes to files here.

Similar to /opt, Linux also has a directory for storing system-wide configuration files: the /etc directory. Actually, there’s the /etc/opt directory, which is intended to store configuration files for applications installed in /opt.

To create the configuration file, head to /etc/opt and create a new file, named as <package_name>rc. Inside it, paste the following code and replace the placeholders with the correspondent paths:

# Replace "PACKAGE_HOME" with the name of your package
export PACKAGE_HOME=/opt/<package_dir>
export PATH=$PACKAGE_HOME/bin:$PATH

To load the settings into your shell session, run source /etc/opt/<config_file> and check your $PATH variable with echo $PATH. If the directory of your package is there, your configuration file is working.

Now, you might have noticed that the configurations aren’t loaded automatically when you open a new terminal. To address this, simply add this configuration to one of the following files:

# This loads "PACKAGE" into $PATH
[ -f /etc/opt/<config_file> ] && source /etc/opt/<config_file>

For only one user, append the load configuration at the end of ~/.bashrc
For all users, create a shell script (with the .sh suffix) in /etc/profile.d/ with the load configuration

Trade-offs of using `$PATH`

One advantage of this approach is that every executable inside the /bin directory will be avaliable in your shell. Also, you may choose to make it avaliable for only one user or for all users, by simply placing the load configuration in a different file.

However, tweaking with the $PATH variable may break your shell configuration if you’re not careful enough. The same goes for editing files inside /etc/profile.d; it’s best to create a new file rather than edit an existing one.

If you’re installing an application with a graphical interface (not CLI-based), you’ll likely want to add it to your desktop menu for easier access. In this case, we’ll need to take an extra step.

The entries in your desktop menu are located in the /usr/share/applications directory. Each application has a .desktop entry file, containing settings for how it is displayed in the menu.

To add a desktop entry file for your application:

Create a new .desktop entry file with the name of your application

Open the file and add the following configuration, replacing the placeholders with the correct settings:

[Desktop Entry]
Version=1.0
Type=Application
Name=<APP_NAME>
Icon=/opt/<PACKAGE_NAME>/<ICON_FILE>
Exec="/opt/<PACKAGE_NAME>/<EXEC_FILE>" %f
Comment=<APP_DESCRIPTION>
Categories=<KEYWORD1;KEYWORD2;>

Save the file and run sudo update-desktop-database

Now, the application is avaliable in your app menu, without the need to start it through the terminal.

Summary

Install your package in the /opt directory
Use symlinks or edit your $PATH variable to include the package executables for an user or all the system
If the package is not CLI-based, add a .desktop entry file at /usr/share/applications to add the package to your desktop menu

Conclusion

Although application support for Linux platforms is pretty decent today, you’ll eventually come across a situation like the one we’ve discussed here. Also, you can automate this process by creating shell scripts to setup the files for you.

Well, that’s it. Until next time! 👋

Linux on Douglas Domingos :: CompSci@UFCG

My First Thoughts on Fedora Linux

Introduction

The first contact

Software compatibility

Support and resources

TL;DR

Installing software in Linux, the "hard" way

Introduction

I. Housing the package

II. Make your package avaliable with $PATH

Adding a Symlink to the executables

Trade-offs of using symlinks

Adding the package directory to $PATH

Trade-offs of using $PATH

III. Updating the desktop menu (BONUS)

Summary

Conclusion

II. Make your package avaliable with `$PATH`

Adding the package directory to `$PATH`

Trade-offs of using `$PATH`