There's a debate in the Linux world that's half truth and half legend. And it can really interfere with a beginner that has just decided to learn about Linux system administration. The legend says that if one wants to learn a Linux-based operating system, one should learn Red Hat Enterprise Linux, or RHEL for short.
"RHEL is the only serious operating system for servers. Ubuntu is just for hobbyists. If you want a real job at a real company, then you have to learn RHEL. Learning anything else is just a waste of time if you want a career in this domain."
Now, of course, all of this is NOT TRUE.
Some people make this claim because many years ago, the operating system from Red Hat was incredibly popular on servers. Almost every company used it. It was hard to find an alternative that had the same high level of quality, polish, and compatibility with server hardware and software.
Why Companies Fell In Love with Red Hat
So why was Red Hat so popular back in the day? And why is it still popular today, even if not as popular as it once was? Four words: Certified, stable, support, and longevity. Let's look at each of them:
The operating system from Red Hat was certified to work with certain hardware. That is, if you bought certain server models, Red Hat guaranteed that their software would work very well with them. And just in case some problem appeared, they guaranteed to fix it.
Red Hat Linux, or Red Hat Commercial Linux, as it was called initially, was very stable. You don't want your server to crash unexpectedly. You don't want to reboot it while thousands of people are using it. You want it to work for days and days without a hiccup. And Red Hat achieved that.
It was also stable because it did not change the operating system too much. No feature update after feature update. Any update they offered brought in as minimal changes as possible. The programs on the system would remain almost the same for many years.
The priority was to fix security bugs. But new features weren't a high priority. Although there were some exceptions, for example, if the new feature was very important and required by many companies that used the Red Hat OS.
Now, this might seem weird for a home user. We usually want all the new stuff we can get our hands on when it comes to software. But some companies don't like change so much.
Imagine a bank building some application on top of the Red Hat operating system. They spend some time making sure it works well. They remove any bugs in the software. Finally, after six months of development, their application is perfect and works without a hitch.
If the operating system remains almost the same for 5, 6, or 7 years, this means that their banking application should also work well for 5, 6, or 7 years. The app does not change, and the operating system does not change much either, so things should work the same way for a long time.
For a bank, this is a very good thing. They want this kind of stability; they like things to remain as constant as possible. This way, they can expect things to remain reliable for a longer time. They don't need all the newest stuff that appears every day. We'll see how this contrasts with Ubuntu which prefers to push new features to its users as often as possible.
Red Hat also offered professional support for companies that needed it. If you paid the fee, you could pick up the phone at any time and get direct help from Red Hat experts. And that's a big advantage for a big company. They want access to professionals that can fix their problems fast.
Another kind of support that Red Hat offers is long-time support for the operating system. That is, even after the OS "expired," Red Hat still took care of that old OS.
Imagine a company installing some OS, version 5.0, from Red Hat. A few years go by. They get small updates from time to time. After a few years, they end up with version 5.9 after making those small, incremental updates to the OS.
But now a new version appears, 6.0, the new OS from Red Hat. And version 6 is very different from version 5. Most companies would not want to update too soon. Their services still work well with version 5.9. It's hard to update thousands of servers. And what if, on version 6.0, they encounter some problems they didn't have on version 5? That would require effort to fix stuff and make their apps compatible with the new OS.
So why change something that is still doing the job?
The simple answer: you don't want to end up with an operating system that no longer receives updates, for example, updates that fix security holes. To cater to those who don't like change, Red Hat offered support for old operating systems for a few more years.
Companies were guaranteed that even if they used an old OS, they would still receive important security updates and fixes for 3-4-5 more years. Even today, Red Hat offers support for a very long time. If a new OS appears in 2023, you could probably use it on a server until 2033 at least, or even longer sometimes.
The Best Way to Learn and Test Your RHEL Skills
Enroll in our Linux Foundation Certified System Administrator course. In this course, you will learn the following:
- Essential commands
- Operation of running systems
- User and group management
- Service configuration
- Storage management
Once you enroll in the course, you will get access to our community of teachers and learners on Slack, where we discuss important topics and new updates.
Why Red Hat Is not the Only Big Player Anymore
RHEL is still insanely popular. It's used on a lot of servers. But it's not like if you apply for a job at 100 companies, 90 of them will require you to know RHEL and only RHEL.
So what changed? Why isn't Red Hat as big as it once was? Well, a lot of good alternatives popped up. For example, Debian is a good solution nowadays too. It's not that popular, but it is still used on a very large number of servers. It works well, it's very stable, and it's well-supported for many years.
The biggest competitor for Red Hat is probably the Canonical company, the one that makes the Ubuntu OS. And Canonical mirrors some things that Red Hat did. For example, Canonical also offers support for companies. And Ubuntu is also certified for some hardware, is stable enough, and offers long-term support, even after a new OS appears.
Why Companies Fell in Love with Ubuntu
But something else made Ubuntu special and desirable. Canonical also innovates a lot and adds a lot of tools to Ubuntu that are really useful for modern companies.
In fact, that's the biggest edge that Ubuntu probably has: it innovates often, it evolves fast, and it adapts to the present day. Ubuntu is not afraid to shake things up. If something is new, it's cool, and people like it, Ubuntu will try to implement it into the operating system as fast as possible.
"Stable" Companies vs. "Move Fast" Companies
Remember the example with the bank? They liked the Red Hat OS because it kept things stable, that is, as constant as possible. The bank didn't need access to the latest things that popped up in the tech world. They valued stability as it reduced the risks associated with using ultra-new stuff that wasn't tested for a long time.
Some companies don't value stability that much. Especially today, there's usually a greater focus on moving fast. For example, Facebook had the motto:
Move fast and break things
The CEO actually encouraged employees to write code faster and implement new stuff aggressively, even if that broke things occasionally. The CEO was more interested in evolving fast and creating new features for Facebook, rather than having the most stable and error-free platform possible. But that makes sense for companies like Meta.
Imagine some Facebook employee implementing a cool new feature for photos. But there is a bug in the code. Now when I want to upload a photo, I get an error. This is not a big deal, neither for me nor for the company. It's just a temporary hiccup that will get fixed rather fast anyway. I don't lose anything important. I certainly don't lose any money. They don't lose money either. So this kind of error has minimal impact.
For a bank, such an error could mean a 1 billion dollar transaction goes to the wrong place or isn't received. Or 20000 clients can't do transactions for a few hours. That's bad. Clients will be angry. The bank exposes itself to financial risks.
Companies that need stability, and need to keep things constant, are inclined to use RHEL. Companies that innovate a lot, implement a lot of new features, and want to always keep up with the times are inclined to use Ubuntu or similar operating systems that focus more on adopting as many new features as possible.
Of course, that's not the only reason. There could be other factors. But that's usually why companies lean on one side or the other. For example, small companies might choose Ubuntu simply because it is free and they don't have enough money to pay for an OS they need to use on hundreds of servers. Remember that RHEL is not free.
Ubuntu vs. Redhat (RHEL): Which one to learn?
In the previous sections, we've explained why companies choose Ubuntu or RHEL. But, what if you, as a student wants to become a system admin, how do you decide which OS to study?
Well, first of all, don't worry too much. Once you learn one OS, if you really understand how it works, it's very easy to adapt to another Linux-based OS. Of course, if you don't know the big differences between RHEL and Ubuntu, you can't know what you would prefer. So we'll mention some differences, later on, to help you decide.
Here are some useful tips to help you decide:
Look at Job Listings
Filter out jobs related to managing servers, system administration, sysadmin, and stuff like that. And then read the job descriptions. They should mention what operating system you should know. See how many require RHEL and how many require Ubuntu.
Furthermore, you could also try to filter based on company type. For example, if you wouldn't like to work at a certain type of company, like a bank, where things might be boring and constant, simply ignore those job listings. And if you have a preferred company you'd want to join, try to see which OS they use.
Install Ubuntu and RHEL on Virtual Machines
Nothing beats hands-on experience. Don't know which one "is for you?". Then install Ubuntu in one virtual machine, and RHEL in another, and see what makes more sense for you. At this time, RHEL is free to test for 60 days.
No idea what to do in that virtual machine? Below is a course that might give you some ideas about exercises you could tackle on RHEL. Then you can try to see if you can figure out how to do the same things on Ubuntu.
Ubuntu vs. Rhel
Ubuntu and RHEL are both Linux-based operating systems. That is, they are based on a kernel called Linux. A kernel is the heart of the operating system. It is basically the software that sits closest to the hardware.
For instance, when a program needs some memory, it is the kernel that actually gives it access to the physical memory on your computer. And Linux-based operating systems usually follow very similar principles. They might use different commands here and there, different configuration files, and different applications, but they are almost the same for the most part.
Small Differences, Easy to Adjust to
Here's one example of a difference that actually "doesn't make much difference:" the package manager. A package manager lets you install and remove the software. For example, to install Nginx on Ubuntu, you would type:
apt install nginx
To install Nginx on RHEL, you would type:
dnf install nginx
We can see that the commands are almost the same. But Ubuntu uses the "apt" utility to manage software, so the command mentions "apt". And RHEL uses the "dnf" utility to manage software, so the command mentions "dnf". But the principle remains the same. We use the package manager to install programs, remove programs, upgrade them, and so on. So you can imagine that if you learn how to use a package manager on RHEL, it will be easy to adjust to Ubuntu later on.
Other differences in this category of "small and easy to adjust to" are file and directory locations. Some configuration files will be in some places on RHEL and in other places on Ubuntu. But you can imagine this is easy to figure out.
Let's say you're used to finding a config file at
/etc/apache2/sites-available/ on Ubuntu. Then you switch to RHEL, and when you try to open a file there, it says the location is not found. So the difference is immediately signaled to you, and you can then search for the correct location.
Hidden Differences, Harder to Catch
Adapting to differences is easy when the OS immediately makes you aware something is wrong. But some things won't be so obvious. For example, on Ubuntu, if you need to update all your software, you need to use two commands:
The first one, "apt update," tells the package manager to synchronize with some servers on the Internet. Basically, that command tells your computer to ask those servers: "Hey, do you have any new software available? I'm getting ready to update all of my programs." After your computer finds out what the newest software available is, it can then upgrade all programs with the next "apt upgrade" command.
However, on RHEL, you only need one command:
That's because the DNF package manager automatically asks the servers on the Internet what is the newest available software. If you don't know about the "apt update" command, you might be wondering why your Nginx isn't updated to the latest available with the "apt upgrade" command. These are some tricky, non-obvious differences you will have to adapt to, but there aren't many.
RHEL vs. Ubuntu: Security
Linux has some security mechanisms included by default. For example, we can adjust file permissions to make sure only authorized people can access certain files. Linux also doesn't allow anyone to make administrative changes to the system.
For example, if someone wants to install programs, they need to prove to the system that they are allowed to perform such actions. They could prove this by typing a password, and only the correct one would allow them to change things on the system. But the fact is, this baked-in security is not enough. With millions of Linux servers hacked over the years, it proved something more was needed.
Both RHEL and Ubuntu include this "something more." RHEL uses SELinux (Security-Enhanced Linux). Ubuntu uses AppArmor. SELinux is much more advanced, allowing administrators to really fine-tune certain security aspects. But it's also harder to learn SELinux than it is to learn AppArmor. However, the effort is sometimes worth the security benefits you get.
It's worth noting that these are the defaults that the two operating systems use. You are free to use whatever you want. So, if you desire, you can disable AppArmor on Ubuntu and install SELinux instead.
RHEL vs. Ubuntu: Ease of Use
You'll hear people often saying Ubuntu is more user-friendly. Let's see one example of this friendliness, so we can discuss why RHEL and Ubuntu have different philosophies on what friendship is.
If we want to install Nginx on Ubuntu, we type:
apt install nginx
And just like that, we actually get a web server running. If we open up our web browser and visit the IP address of our server, we will see a web page. And all we did was run one command.
On RHEL, we need to type three commands:
dnf install nginx
systemctl start nginx
systemctl enable nginx
Why is that? Well,
apt install nginx and
dnf install nginx do just one thing: they install the Nginx application. That's all. But the Nginx application can't just start on its own. We have to send it an instruction to do that. So we start Nginx with
systemctl start nginx.
Next, we need to think that the server will sometimes be shut down or restarted. What happens when the server restarts? Nginx won't run anymore. So we need to send another instruction and tell our system: "Hey, when the server boots up, please automatically start Nginx." And we do that with the
systemctl enable nginx command.
So how come on Ubuntu, we just installed Nginx, and then Nginx was already running? Well, because Ubuntu assumed that if we installed that, we probably also want to start it. So instead of making us type another command, it just did that for us automatically. In a way, Ubuntu ran the
systemctl start nginx command on its own. And it also ran
systemctl enable nginx to make sure Nginx automatically starts up every time the server boots up.
RHEL, on the other hand, does not make such assumptions. It believes the system administrators might have different ideas. Maybe they don't want to start Nginx immediately. Maybe they want to modify the Nginx configuration before starting it and opening it up to the Internet. So RHEL is a bit more hands-on, but Ubuntu tries to help when it can.
But see how Ubuntu trying to help us can also be a problem? If we're total beginners and install Nginx a few times, we might believe that installing software on Linux automatically starts it up. There's nothing else we need to do. So we might not even find out about the
systemctl start command.
This means we actually learn less about Linux because Ubuntu does some extra things for us. But once we know everything that happens under the hood, then Ubuntu helping us is not a bad thing anymore. There is nothing wrong with saving some time and typing fewer commands as long as we understand what is actually going on behind the scenes.
We could even say we found a better reason to learn RHEL first. Whenever someone tells us:
Learn RHEL; it is used on way more servers than Ubuntu.
We could answer the following:
No, I'm actually going to learn RHEL first because it teaches me more about Linux.
It can be useful to start out with RHEL because we have to do more on that operating system. It does no "hand holding" as Ubuntu does. So by forcing us to do more things, we also learn more about what steps we need to go through to achieve a certain task.
The Easiest Way to Learn How to Use RHEL (Red Hat Enterprise Linux)
Learning Linux, in the beginning, at least, is hard and confusing. There are thousands of things to learn about. It's hard to know where to start and how to continue. But in this course, we made everything easy for you. We organized the theory in a way that makes sense.
You start out with the essentials, and then you learn about the real-world tasks of a system administrator. If you learn everything in that course, with that knowledge, you'll be able to continue in any direction you want in your Linux career. It serves as a foundation for anything you want to do in the future as a Linux system administrator.
How to get started with RHEL
Start with the Linux basics. This will make the process of learning RHEL seamless. At KodeKloud, we have a top-rated Linux basics course.
There are no prerequisites for this course. You only need a laptop with a browser to work on the labs. In this course, you will learn the following:
- Overview of Linux and its history
- Key commands and utilities for beginners
- Understanding Linux kernels and file types
- Package management in Linux distributions
- Navigating and working with the Linux shell
- Basic networking concepts and tools in Linux
- Creating and managing user accounts
- Building a system service
- Managing storage in Linux systems
Once you enroll in the course, you will get access to our community of teachers and learners on Slack, where we discuss important topics.
The Easiest Way to Pass the RHCSA (EX200) Exam
In some parts of the world, employers are looking specifically for people that are certified RHEL users. And the LFCS certification is somewhat more generic. It basically says, "This person knows important stuff about Linux-based operating systems." If you want a certification that says, "This person knows how to use RHEL," we have another course for you. Check out this course:
More on Linux: