RHEL Based vs Debian Based - Benefits

SlowCoder

Gold Member
Gold Supporter
Joined
May 2, 2022
Messages
455
Reaction score
316
Credits
3,611
This is NOT a question about your favorite desktop environment.

This is my question: If you wanted to talk me into using one family or the other, what would you tell me? I'm looking for deep details, like benefits of DNF and APT. Security. Ease of maintenance.
 


In my experience... RPMs have been a round a while longer, more mature.
I still (very rarely I admit) run into dependency inconsistencies in deb/apt.
I also believe rpm commands are more consistent, dnf install or dnf remove.
With apt, it's sometimes dpkg, or sometimes apt-get, or sometimes just apt, and I never know
when to run one vs the other.

I believe security to about equal between the two.
Ease of maintenance. I don't have a lot of experience with custom local apt repo's
But with dnf and rpm, we have reposync, createrepo, and commands to simply mirroring
and creating custom repos. dnf supports "group" installs.
apt, does have something similar, but typically it's the name of a specific package rather
a "group" of rpms, for example... apt-get install build-essential vs dnf group install 'C Development Tools'

I will also say building an rpm package is generally easier than building a deb package.
Partly because I'm more familiar with it, but partly because it handles more of the back-end
automatically for me.
 
Th
This is NOT a question about your favorite desktop environment.

This has very little to do with your question, (dnf/rpm vs apt/deb)
But I think for the desktop, Deb/Ubuntu/Mint has more options, in some ways is easier.
Has a few more packages, has more games available natively, and is more friendly for newer users.

But for the server market, there is no equivalent for things like NIC teaming, bonding,
built-in cman clustering, anaconda/kickstart, grub-fallback, things that make Linux a reliable
server environment with built-in redundancy, things like awx/ansible are available for Ubuntu
but they are developed on redhat/fedora systems. Ubuntu may have more games and utilities,
but Fedora/Redhat typically lead in development, kernel extensions and modules, drivers
new technologies. (examples, first with UEFI support, first with Wayland support, first with systemd,
first with NetworkManager, docker, podman, first distro with 64 bit support, etc...) which isn't always
appreciated or wanted by many users, but usually other distro's follow.

I do a lot with kickstart. It would be nice if there was a deb/dpkg equivalent.
 
Last edited:
This has very little to do with your question, (dnf/rpm vs apt/deb)
But I think for the desktop, Deb/Ubuntu/Mint has more options, in some ways is easier.
Has a few more packages, has more games available natively, and is more friendly for newer users.
Yeah, I was trying to shake off the posts from people who think desktop = distro.
But for the server market, there is no equivalent for things like NIC teaming, bonding,
built-in cman clustering, anaconda/kickstart, grub-fallback, things that make Linux a reliable
server environment with built-in redundancy, things like awx/ansible are available for Ubuntu
but they are developed on redhat/fedora systems. Ubuntu may have more games and utilities,
but Fedora/Redhat typically lead in development, kernel extensions and modules, drivers
new technologies. (examples, first with UEFI support, first with Wayland support, first with systemd,
first with NetworkManager, docker, podman, first distro with 64 bit support, etc...) which isn't always
appreciated or wanted by many users, but usually other distro's follow.
All of this is good info. I'm not a PC gamer. I play with development, and am interested in server technologies. The fact that one team developed something first, is somewhat irrelevant once matured and adopted into other systems. But it also means that I would be likely to see new technologies sooner from certain teams.
 
They just have different package names and different configuration directory and file setups. I find rpm/yum easier because I use that more because on my personal vpses I run Rocky Linux(and at work Rhel), the exception on my hypervisor where I run Proxmox.

I do a lot with kickstart. It would be nice if there was a deb/dpkg equivalent.
Do you use it standalone or icw Satellite?
Ubuntu may have more games and utilities.
Ubuntu is currently in the lead but Arch and Arch based are catching up quickly because with gaming on Linux you are going to have a better time with the latest and greatest libraries and software.
 
Do you use it standalone or icw Satellite?

We do have some "real" Redhat systems we use with Satellite, but the "clone" OS's we typically use standalone.
I know we could set up repo'sync and keep things up to date... but we have a vetting/testing period, so usually
it's easier for us to do it after the fact (after the OS has been installed for a while).
Also we have a lot of custom (in house) RPMs, so we set up a second repo anyway, just to keep
things separated from the OS repos.

I have used chef/cobbler/ansible to "simulate" some of these things on non-rhel/fedora systems, but it's
a PITB.
 
Both can achieve what ever be needed for home users.
Stability and compatibility with hardware keeps me
with Debian, I had so many issues in the past with RHEL
based installs, that could be all changed now, but I stick
with what works for me, and the many Debian devs that
have worked on solving issues in the past keeps me there,
big corporations did not help my situation with Linux, it was
all the hard work from the various distro creators that made
it possible for me to keep on keeping on.
There are advantages and disadvantages to both,
use what is most suitable to your needs.
 
Last edited by a moderator:
Scientists that study the various human ethnic groups will tell you that statistically speaking, the variations WITHIN a race of humans is measurably far greater than the differences in the mean values for any two major race categories. It is much the same situation in Linux. The differences in the Debian variants (e.g. Debian, Neptune, Sparky, Q4OS, Kali, etc.) or the differences in the RedHat variants (RedHat, Fedora, Centos, Rocky, Alma, Mandrake etc.) are more significant than the difference between the mean distribution for .DEB versus .RPM For example, you can find rolling release distributions and annual/semi-annual fixed distributions among both major categories (.DEB/.RPM). And don't even get me started on all the variations among the display environment offerings (Gnome, KDE Plasma, Xfce, Mate, etc.). Your selection should depend on what you are trying to achieve with your particular platform. In my case, I run Rocky (RHEL variant) on both servers and in some cases on tablet hybrids, Debian on Windows WSL2, and on rare occasions, Kali (Debian variant) on a laptop. For me, the common thread is, if I'm running a GUI display environment, I use KDE Plasma 5 everywhere.
 
With apt, it's sometimes dpkg, or sometimes apt-get, or sometimes just apt, and I never know
when to run one vs the other.

dpkg when it tells you to.
apt-get when used in a script.
apt otherwise.

There are people who will tell you to use dpkg on a local .deb and then use apt-get with the -f flag to fix dependencies, but you can just 'apt install package.deb' and deal with that all in one go. There's no reason to do that. So, dpkg is only useful when something is broken - and it tells you when to use it. The apt isn't stable, so use apt-get which is stable in scripts. Otherwise, just use apt.
 
dpkg when it tells you to.
apt-get when used in a script.
apt otherwise.
I find the search results of "apt-cache search" better formatted and easier to search through than the results of "apt search".
 
I suppose that's a matter of preference. I prefer the more condensed one, to the point that I just aliased it.
 
I find the search results of "apt-cache search" better formatted and easier to search through than the results of "apt search".
Me too. I think @KGIII ’s quote can be expanded a little.
E.G.:
dpkg when it tells you to
apt-get when used in a script.
apt otherwise.

To this:
dpkg - when it tells you to.
apt-get - when used in a script.
apt otherwise.

apt search - for quick/basic searches in the terminal.
apt-cache search - for more complex searches in the terminal, or in scripts. Because it has better/more consistent formatting and can be processed more easily.
 
Hmm...

When I do an apt search, I already know what I'm looking for and what I'm looking at. Which might explain why I prefer the condensed version. I also have a preference for high data-density. Fit as much usable information on the screen as can be reasonably processed.

Anyhow, that probably explains it. I know what I'm looking for when I search - I'm just looking for things like to ensure it exists and that I spell it properly.
 
Hmm...

When I do an apt search, I already know what I'm looking for and what I'm looking at. Which might explain why I prefer the condensed version. I also have a preference for high data-density. Fit as much usable information on the screen as can be reasonably processed.

Anyhow, that probably explains it. I know what I'm looking for when I search - I'm just looking for things like to ensure it exists and that I spell it properly.
That's fair enough.
When scripting, or making more complex searches, that require a lot of filtering - I always use apt-cache search because the output for each package is on a single line - containing the package name and the package description. So it works better with the other standard UNIX tools (grep, awk, sed etc.).

Whereas apt search splits the output over two lines.
The first line is the name of the package, the version number and the install status (if installed).
And the second line is the description.
But if you use apt search for more complex searches, using grep to filter the results - some of your results will be names of packages but with no description. And other results will be the description, but no package name.

So for example, if I want to find out the names of any python library packages that can deal with LaTex.
If I use the following apt search command:
Bash:
apt search python --names-only | \grep -i latex
NOTE: I'm using \grep above in order to "escape" any aliases that have been set for grep.
On my system grep is aliased to 'grep --color=auto -n', which colourises output AND includes line-number information. We don't want the line-number information to be included, so using \grep will bypass the alias and will just run plain grep using only the parameters that are specified.
In this case -i, for a case-insensitive search.
Anyway, using that query - I get the following results:
WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

python-latexcodec-doc/stable 2.0.1-1 all
LaTeX lexer and codec library for Python (docs)
LaTeX document processing framework in Python - documentation
python3-flatlatex/stable 0.8-1.1 all
Python3 LaTeX math converter to unicode text - library
Module to embed LaTeX equations in HTML files
python3-latexcodec/stable 2.0.1-1 all
LaTeX lexer and codec library for Python3
LaTeX document processing framework in Python - modules
Embed Sage code and plots into LaTeX -- Python 3
sphinx extensions for working with LaTeX math - Python
In the above, we can see that we have a couple of package names with their descriptions.
But we also have some package descriptions with no names. So the results aren't particularly useful.

Also of note, there is the warning at the top of the output - "WARNING: apt does not have a stable CLI interface. Use with caution in scripts."

Whereas with apt-cache search.
e.g.
Bash:
apt-cache search  python --names-only | \grep -i latex

We get some much more useful output:
python3-flatlatex - Python3 LaTeX math converter to unicode text - library
python3-gleetex - Module to embed LaTeX equations in HTML files
python-plastex-doc - LaTeX document processing framework in Python - documentation
python3-plastex - LaTeX document processing framework in Python - modules
python-latexcodec-doc - LaTeX lexer and codec library for Python (docs)
python3-latexcodec - LaTeX lexer and codec library for Python3
python3-sagetex - Embed Sage code and plots into LaTeX -- Python 3
python3-texext - sphinx extensions for working with LaTeX math - Python

With the above output - I could easily process the results further - by piping to sed, or awk to yield only the package names.

So by using apt-cache search - you can see that I could easily create a bash one-liner, or a script that could identify all packages that meet certain criteria, compile a list of package names and then install all of those packages in one go.

Or if I wanted to, I could create a more complicated script that would compile a list of packages and will allow me to mark/choose which packages I wanted to install (if any).

But generally speaking though, I usually just pipe the output of apt-cache search through grep one or two times to refine my searches and then pipe the final output to w3m, or a pager like less, so I can see exactly which packages are available. And then I'll manually install the ones that I want/need via apt.
 
Also, I note a lack of clarity in my post. What I have aliased is 'apt-cache search' to 'search', so I just 'search <name>' when I need it.
 
And after derailing the OP's thread a little - in answer to the OP's original question:
My personal preference is for Debian/APT based systems.
The last time I tried using a Red-hat/RPM based distro (which admittedly was a really, really long time ago, shortly after I first started using Linux) - I experienced constant dependency related problems when trying to simply install or update software from the repos. Which I found extremely frustrating. And that initial bad experience really put me off using Red-hat based systems ever again!

So I decided to switch to Debian which had absolutely rock solid dependency resolution abilities. And in all of my years using it - Debian has never failed me once!

Though, to be fair - in all of the years since then, Red-hat/RPM based systems have probably gotten a lot better at resolving dependencies. So at some point, I suppose I really aught to dig out a spare machine and give Fedora or Suse a fair go.
 
My highest familiarity is with dpkg/apt*, rpm/yum, rpm/dnf, rpm/urpmi & rpm/zypper, as my most used distros, in order, are openSUSE, Debian, Mageia, Fedora & a select few Debian derivatives. Zypper is the very clear winner for me, as it was obviously created by those familiar with the foibles of other package managers, and they built a lot of premium quality logic and convenience into a minimum of required typing, opposite to dnf's typing bloat. My most used sequences I put in a couple of dozen or so aliases & scripts. e.g.
Code:
zypper --no-refresh se -s $*  | egrep -v 'debug|devel|srcp|openSUSE-20' | egrep 'x86|noarch'| sort
is zypse, but I have special variants for special problems, such as zypsek for kernels' numerous variants bloating output results. I especially appreciate zypper's package locking mechanism that allows locks to be overridden on the fly without actually affecting lock status. If a lock includes a wildcard, it will not be affected when an override is selected. There's no need to have open another tab or window for managing a lock file whilst navigating special locking & unlocking package activity.
 

Members online


Top