Red Hat Enterprise Linux (RHEL) Reviews

We use the product for application hosting, availability, and CI/CD pipelines.

The solution has good availability and is easy to use. It saves money and resources like support staff.

The product should provide a portal to manage licenses.

I have been using the solution for more than five years.

The solution’s stability is fine.

The product’s scalability is fine.

The support is good.

Neutral

We have seen an ROI on maintenance. As long as our servers run, our company makes money.

We evaluated SLES and Windows.

We purchased the solution via a cloud provider. We use AWS, Google, and Azure. The resiliency of the product is the same as other products. 

The solution helped us reduce costs. We use SLES and Windows alongside Red Hat Enterprise Linux. Application support and vendor support for Red Hat Enterprise Linux are better than other products. 

Overall, I rate the product an eight out of ten.

I use the solution to build web applications.

The tool provides more support, resources, and documentation than other products.

The product is super easy to use.

The default settings are confusing. I often change these settings to avoid problems.

I have been using the solution for a couple of years.

The stability of the product is very good.

I did not have issues finding configurations and changing settings as needed. I haven't had any issues like bugs or downtime while using Red Hat Enterprise Linux. Overall, it was a good experience. Overall, I rate the solution an eight out of ten.

For applications, we are the OS support. We build servers and deliver applications.

RHELs overall effect on our organization's management and efficiency has been good. It's easy to support and involves no downtime. It is simple to handle, apply patches and maintain.

The most valuable feature of this solution is how easy it is to use.

When there is down time from a system admin perspective, this solution could improve how they communicate why this down time is happening. 

I have been using this solution for seven years. 

This is a stable solution. Our machines reside on vSphere and when a server goes down, we have to find out the root cause. This requires pulling information from the vSphere. 

I would rate the support for this solution an eight out of ten. 

Positive

We previously used Solaris. We moved to Red Hat because it is easier to manage and more cost-effective. It is also easier to manage patches and security using Red Hat. 

I was only involved in testing this solution during the deployment process. During testing, it was easy to make changes to configurations which also support our decision to use Red Hat. 

This is a cost-effective solution.

I would recommend this solution to others. It is easy to use, manage and handle with very little downtime. 

I would rate this solution an eight out of ten. 

The primary purpose of any operating system is to run all sorts of applications and databases on servers. We use RHEL to run applications and host containers but not much else. We don't use it for databases, and none of our clients use Red Hat virtualization, so no KBM. We install them onto VMware and use them like Red Hat virtual machines.

I primarily work for banks that tend to have a proper on-premise cloud because the data can't leave the premises. We also work for insurance companies, government, and law enforcement organizations. Most of them use it on a virtualized platform like VMware. Some are hardware installations, and other clients are experimenting with cloud infrastructure. One of the banks we work for has started to build its own cloud to get experience and move specific applications to the cloud.

One client has RHEL deployed across two data centers, which is usually a mirrored setup. In other words, two hardware servers are doing the same thing. It can be active-active or active-passive. The VMs also stretch across two data centers, but it's a Metro cluster, so it's in the same city. I've been working with my current client for a couple of years. Our three-person team manages 250 hardware services and about 400 VMs.

We are still migrating a couple of solutions to Red Hat, so the user base is getting bigger. 

We decided to use Red Hat Linux instead of Solaris or something else because it's widely used and accessible. It's easier to find people who know RHEL. It has also made the automation through Satellite and Puppet easier, which are built into Enterprise Linux. 

RHEL is stable, mature, and relatively easy to handle. I'm pretty confident in it. We haven't had to raise a serious support ticket for any server in I don't know how many years. It has built-in high availability solutions for VMware on top of the hardware.  

Red Hat Linux is also useful for keeping applications from misbehaving. I like the fact that it has firewall controls.

Red Hat can be tricky at times, but all operating systems are. The moves to systemd and NetworkManager haven't made the product more user-friendly. The network management they had before was easier and somewhat more reliable than NetworkManager, which Red Hat forces us to use now.

That may just be my personal preference because I've been working on Red Hat for so long. It's something new that doesn't do exactly what it used to do, so it's probably more of an old person's complaint.

The firewall controls can also be somewhat challenging in terms of automation. An application may use a different setup, so you need to consider that if you want to automate installations. 

You can't easily port an application to another operating system unless it's CentOS or Fedora. It's not portable if you want to port it to something like Windows except for Java and containers. Unless it's another Red Hat, CentOS, or Fedora, the application itself isn't portable if it's installed on a thick virtual or physical machine even. It's not easily portable because you must recompile the application or make changes.

I have been using Red Hat for more than 15 years.

There are bugs, but you can usually find a workaround quickly. When somebody discovers a bug, it's fixed pretty quickly in the next release.

The services run well, and it can handle pretty much anything provided you have enough hardware resources. That's something you always have to watch out for.

RHEL is so stable in the environments I've been working on that I have never had to call Red Hat. Any issues we've had were either hardware or application problems. It's never an issue with the operating system. 

The community resources are helpful. You can find answers to most questions you have in terms of setup or troubleshooting. There are issues now and again, but you can go to the website or a discussion board to find the solution, and it works. When I say we've never had a problem, it's not exactly true. Sometimes it doesn't do what you expect, but you can usually find the solution, so we have never had to call support to ask.

A lot of my clients used to use Oracle Solaris, but many of them switched to Red Hat due to hardware costs. Oracle hardware is expensive, but it is good stuff. We had systems that ran for three years without any issues, but it gets expensive if something breaks or you need to replace hardware due to the lifecycle. 

You can install RHEL on any x86 hardware and deploy it on several Dell servers, which is much cheaper than a single Oracle server. For example, we needed to replace a system because the hardware got sold. We were quoted a price for Solaris running on an Oracle T5. It was four times the price of replacing it with HP hardware. So that's the main reason many clients have shifted to RHEL. 

It's a vicious cycle. As more companies switch, other clients say, "Oh, but there's not much user base left. How long will this run? Let's follow the mainstream trend." That said, I love Solaris. It's unbelievably stable and easy to use, but just the hardware underneath it is too expensive.

I've been involved in deployment, but it depends on the client. I've done everything from architectural design to installation and administration for specific clients. Setting up RHEL is pretty straightforward if you know what you need to know. Of course, you have to do your homework before. For example, if you are deploying it on a VM, you need to see the size you need and what else you have to install. 

When someone orders a server, we typically tell them the deployment will take half a day, but the installation takes around an hour. You may need to install other things, but the out-of-the-box operating system takes about an hour.

We're just one team who manages the infrastructure for one department. It's highly specific. There's a specialized market team that does stock exchanges and financial services. The demands for hardware and availability are particular to that segment. We have three people responsible for installation, maintenance, and administration.

RHEL is stable and relatively cheap, so you get much more out of it than other Linux flavors. I mostly work as a consulting system engineer and am usually not involved in any of this financial stuff.

I can suggest how many subscriptions they need and how much it will cost, but I can't say if it's worth it to the client. I don't know, but we have never had any complaints. People never say, "Oh, but this is expensive, and it doesn't fit into what we had planned."

RHEL has a decent pricing model. It's a subscription, which makes sense. The OS itself is free, but you pay for the support. I have never heard any complaints about the pricing.

You can also purchase a virtual data center license that allows you to set up a hundred virtual servers. You can also add a Satellite license subscription to your standard server. There are several different add-ons that will increase the price of the subscription, depending on the functionality you need.

It's hard for me to compare Red Hat with other open-source solutions because we only have clients who work with Red Hat Linux. Of course, there are entirely free ones you could use. Fedora is the most extensive free version of Red Hat. You could use Ubuntu or any other Linux flavor, which is mostly free. However, I have no idea what additional cost you'd pay if you want to support.

I rate Red Hat Enterprise Linux nine out of ten. I would recommend it, but I need to qualify that by pointing out that I don't have enough experience with other Linux flavors to say that it's better than the others. I've mostly used RHEL because it's so ubiquitous.

I'm using Red Hat as an OI solution with some Oracle databases and an FTB server on top of it. I am not using containers in Red Hat. It's solely serving as an OS with direct applications installed on it. We have a few thousand users benefiting from Red Hat indirectly, but only 10 to 20 people work directly with it. I only use Red Hat in one location right now. Previously, I had it deployed in a cluster. 

The most important thing for any organization is stability and uptime for the application and the environment. Red Hat provides us with stability and uptime, and it gives us all the tools we need to integrate with our other solutions. 

It's also a suitable environment for applying security certificates. You can perform all the requirements on Red Hat. For example, you can do everything you need to comply with BCI, ISO, or any other certificate. 

The most valuable thing about Red Hat is its stability, uptime, and support for various hardware vendors. Linux servers, in general, are relatively secure and they are more secure than Windows and other products. 

Red Hat provides additional tools to customize your environment and harden your OS. For example, you can apply security patches and use benchmarks. You can do everything in Red Hat, so you can always have a highly secure environment. The interface is pretty good. Our engineers like the PLI interface.

I've been using Red Hat for around 10 years. 

Red Hat is as stable as you want it to be. We periodically have some bugs, but we can resolve these issues quickly. 

Red Hat can be scalable, especially if you are using it for virtualization. For example, KVM is easy to implement and scale up. You only need to add more nodes to scale as much as you want.

I rate Red Hat support nine out of ten. It's nearly perfect. Red Hat support has one of the best teams I've dealt with. 

Positive

I've used some open-source environments like CentOS and some other solutions like Solaris and HBOX. We switched to Red Hat because it's easier to deploy and manage.

Setting up Red Hat is straightforward if you're doing a basic installation. They have a beautiful installer that handles everything. For a more advanced deployment, you may need to go through some more complicated steps to customize it for everyone's best practices. 

You only need one person to handle the installation, which takes anywhere from a few minutes to an hour, depending on the installation. If you install Red Hat correctly based on your requirements, you don't need to perform any maintenance. You might need to patch, upgrade, add resources or harden the OS. When discussing security, you always need to follow up on patching and security hardening.

The cost could be lower. Red Hat is considered a costly solution. It can be expensive if you want all the features in the license. A cheaper license would make Red Hat more accessible to a broader range of users. It's reasonable given the features and performance, but a lower price would encourage more people to adopt it.

We looked at HBOX servers, but they are far more expensive than Red Hat. Red Hat is more optimal in terms of cost versus performance and stability than other solutions like Solaris and HBOX.

I rate Red Hat Enterprise Linux nine out of ten. It's an excellent solution. Go for Red Hat If you want stability at a reasonable cost. It's the best.

We use RHEL for database servers, a few of them run Oracle servers, and we are also using it for some of the network and infrastructure services.

The best operating system I've ever used is Red Hat, in terms of its ability and consistency of the operating system. Other than that, the vast majority of applications that I had, I could deploy those on Red Hat without much effort as it supported a vast majority of applications. I never faced any major issues with the OS, the support is also very good.

The most valuable features are:

• The stability and reliability of the OS itself
• Being open-source and leading the open-source market trends/ technologies
  
• The wide variety of applications we can deploy on Red Hat
• Their support 

I am a big fan of the OS and the user experience. They're very good. The OS is very stable and very good in performance as well.

RHEL enables us to deploy current applications and emerging workloads across all virtualized hybrid cloud and multi-cloud environments. It is one of the most stable OS that are available. 

We use RHEL to run multiple versions of the same applications and databases on a specific operating system. We have several deployments of database and a few of them are running on a bit older versions of Red Hat and some of them are running on newer versions. We are running different versions on different platforms. The management aspect is also very good, especially when we need updates on the different packages from the RH support network, management is easy.

We also use the tracing and monitoring tools to monitor OS as well as applications running on RHEL platform. The OpenShift is also a big plus through which you can manage and deploy enterprise-ready containerized workloads.

Being an advocate of open source technologies I always wished that Red Hat subscription/ support should be offered free of cost. Having said that, I understand the economics involved in running large enterprise like Red Hat; support cost is one area that can be improved. They should offer it at reduced prices.

I have been using RHEL since the start of my technical career, which was around the mid of 2003. So it's been almost 18+ years. I started using RH when it was version 7.

Stability has always been a plus for RHEL. 

Scalability is excellent. With the introduction of hybrid and multi-cloud support, one can scale up as well as scale out his workloads pretty easily. We usually scale up our traditional workloads when we need more resources i.e., during peak seasons. 

Four people in my team are responsible for deployment and support of Linux based workloads. 

We have around 300 virtual machines (VMs) and roughly 20% of them are running on Linux environment.

Whenever I open a case, I believe the support team will be able to solve my problem. They are very good at it. The documentation RHEL provides is also very good. Almost all the time, I get a solution to my problem. :)

We are using other flavors of Linux OSes, that include Oracle Enterprise Linux (OEL) and CentOS, both of which are binary compatible with RHEL. We are also using a couple of other Linux flavors like Ubuntu and OpenSUSE.

RHEL provides features that help speed our deployment. Installing on a physical server takes more time than installing it onto a virtual machine (VM).

Because of absence of local support in our part of the region, we did find some difficulties in the initial deployments with hardware vendors/ partners when we started in 2003. The local partners didn't have much knowledge of Linux environments at that time, and the support for hardware was also a bit tricky. The deployment took a couple of days until we got support from the hardware manufacturer.

Nowadays, it's very good. I managed to get good support from the hardware vendors after that incident.

We have our own deployment plans for the operating systems that include some baseline configurations and security checklists.

We usually deploy in-house as we have a trained team. Occasionally, little help is sought from the vendor teams, some of them have skilled professionals.

RHEL offers an efficient, cost-effective and reliable OS environment for enterprise-level environments. Similarly cost of running operations and the scalability factors make RHEL a good choice for providing a better ROI. The feature set it offers, support for a variety of applications, ease of deployment, and an excellent level of support all result in a good ROI. 

I believe for an enterprise-level operating system and the feature set RHEL offers, it's like any other enterprise platform cost. The introduction of OpenShift is also a big plus in terms of deployment and management of container based workloads. Red Hat as mentioned earlier can improve a bit on support/ subscription costs.

We had been using a couple of Red Hat variants for some scientific experiments that included Scientific Linux CERN (SLC) and Scientific Linux (SL), which were a confidence booster for choosing and deploying RHEL for production workloads.

Since I started with version RH 7, I believe the GUI is quite close to any other GUI operating system. There have always been a variety of tools and features that attract a non-Linux user.  As already mentioned, RHEL has been a pioneer in open-source technologies; it continued to evolve with changing market needs, that has been a big success for them.

I would definitely advise choosing RHEL if you need stability, scalability, and reliability of the OS platform. I would be a big advocate for the use of Red Hat to any new person who wants to deploy his production workloads, on-prem or on cloud on a Linux environment.

I would rate it a nine out of ten. It's near perfect. 

It started mostly with websites and open source environments overall for development. Now, we are moving into business applications as we are migrating our ERP, which is a cp -r tree, to Linux. We are also migrating the database of SAP to SAP HANA on Red Hat Enterprise Linux. 

We use RHEL versions 7 and 8. There is a bit of version 6 still lying around, but we are working on eradicating that. It is mostly RHEL Standard subscriptions, but there are a few Premium subscriptions, depending on how critical the applications are.

It has fulfilled all the promises or goals of different projects, not just because our internal team is strong, but also because our external partner is strong.

Satellite is an optional system which provides for extensive deployment and patch management. That is quite valuable.

We use Red Hat Enterprise Linux's tracing and monitoring tools. You don't leave them on all the time, as far as tracing is concerned. When you are sick and go to the doctor, that is when you use it, e.g., when an application is sick or things are really unexplainable. It gives you a good wealth of information. In regards to monitoring, we are using them to a point. We are using Insights and Insight Sender as well as the Performance Co-Pilot (PCP), which is more something we look at once in a while. 

Other Red Hat products integrate with Red Hat Enterprise Linux very well. In fact, they integrate with pretty much everything around the universe. We are doing API calls without even knowing what an API is, i.e., towards VMware vCenter as well as Centreon. There are certain individuals who use it for free without subscription and support for Ansible in our Telco group with great success.

Linux overall needs improvement. They cannot go much beyond what Linus Torvalds's kernel implementation can do. I come from AIX, and there were very cool things in AIX that I am missing dearly, e.g., being able to support not only adding, but also reducing memory and number of processors. That is not supported on Linux right now, and it is the same for the mainstream file systems supported by Red Hat. There is no way of reducing a file system or logical volume. Whereas, in AIX, it was a shoo-in. These are the little things where we can say, "Ah, we are missing AIX for that."

We are not loving our servers anymore. If we need them, we create them. When we don't need them, we delete them. That is what they are. They are just commodities. They are just a transient product.

I have been using it for nine years, since 2012.

The stability has been very good. However, there is a learning curve. We were running huge in-memory databases, about 2.5 terabytes of RAM, which is SAP HANA. Then, we were getting really weird problems, so we asked the app guys 20,000 times to open a ticket because we were seeing all kinds of weird timeouts and things like that on the OS side. We were saying, "It's the app. It takes forever." Finally, they said, "Oh yeah, we use a back-level thing that is buggy and creates a problem." It took us six months and four people to get that from the app guys. We were ready to kill them. That was not good. Whatever you put on Linux, make sure that you have somebody supporting it who is not dumb, or on any platform for that matter.

The scalability is six terabytes. That is what we're doing. We are printing HANA servers on that scale, which are more in the 2.5 terabyte range. However, we had to create one for the migration initiative on the VMware, which was six terabytes with 112 cores. It worked, and that was it. It also works with bare-metal, but you have to be aware there are challenges in regards to drivers and things.

RHEL provides features that help our speed deployment. For example, for SAP HANA, they have full-fledged support for failover clustering using Red Hat HA, which is a solution to create a vintage approach of failover clustering. They do provide extensive support for value-adds for ERP solutions.

They also provide value left, right, and center. Whenever we have a problem, they are always there. We have used both their professional services as well as their Technical Account Manager (TAM) services, which is a premium service to manage the different challenges that we have had within our business. They have always come through for us, and it is a great organization overall.

Their support is wonderful. They will go beyond what is supposed to be supported. For example, we had a ransomware attack. They went 20 times above what we were expecting of them, using software provided by them on a pro bono basis, meaning take it and do whatever you want with it, but it was not ours. That was a nice surprise. So, whenever we have needed them, they did not come with a bill. They came with support, listening, and solutions. That is what we expect of a partner, and that is what they are: a partner.

I, for one, was managing AIX, which is a legacy Unix, as my core competency. I still do because we haven't completed the migration. 

RHEL is a value-add right now. As we are migrating more payloads to containers, we are putting less Linux forethought into these container-hosting servers. You just shove your containers on top of them with your orchestrations. This may reduce our need to manage RHEL like a bunch of containers. That changes the business. 

We were paying for premium SUSE support for an initial pilot of SAP HANA on the IBM POWER platform. We were stuck between an IBM organization telling us, "Go to SUSE for your support," and the SUSE organization saying, "Go to IBM for your support." So, we told them both to go away. 

We are so glad that we haven't mixed the Red Hat and IBM more, because SUSE and IBM don't mix, and we were mixing them. That was prior to the merger with Red Hat. In regards to IBM's ownership of Red Hat, we are a bit wary, but we think that IBM will have the wisdom not to mess it up, but we will see. There is a risk.

The initial setup is as straightforward as it can get for anyone who knows what they are talking about. It does require technical knowledge, because that's what it is: a technical solution. It is not something that I would give to my mother. Contrary to other people's perception of, "My mom had a problem with her Windows. Oh, put her on Linux." Yeah, no thanks. Give her a tablet, please. Tablets are pretty cool for non-techies, and even for techies to a certain extent. 

For the migration from AIX, Ansible has been our savior. You do need somebody who knows Ansible, then it is more about printing your servers. So, you press on the print button, then you give it to the apps guys, but you do have to know what you are trying to aim for so the guy who is creating the Ansible Playbook codes exactly what is required with the right variables. After that, it is just a question of shoving that into production. It is pretty wonderful.

We do get a return on investment with this solution in regards to a comparative cost of ownership of going with the niche solution of IBM AIX systems and hardware. There is a tremendous difference in cost. It is about tenfold.

The integrated solution approach reduces our TCO tremendously because we are able to focus on innovation instead of operations.

RHEL is a great place to go. They have a great thing that is not very well-known, which is called the Learning Subscription, which is a one-year all-you-can-drink access to all of their online self-paced courses as well as their certifications. While it is a premium to have the certifications as well, it is very cool to have that because you end up as a Red Hat certified engineer in a hurry. It is good to have the training because then you are fully versed in doing the Red Hat approach to the equation, which is a no-nonsense approach.

Because it is a subscription, you can go elastic. This means you can buy a year, then you can skip a year. It is not like when you buy something. You don't buy it. You are paying for the support on something, and if you don't pay for the support on something, there is no shame because there are no upfront costs. It changes the equation. However, we have such growth right now on the Linux platform that we are reusing and scavenging these licenses. From a business standpoint, not having to buy, but just having to pay for maintenance, changes a lot of the calculations.

We tried SUSE on the IBM POWER platform, and it was a very lonely place to be in. That was for SAP HANA migration. We are glad that we decided to be mainstream with leveraging what we already had at Red Hat Linux (over a few dead bodies now). We also leveraged the Intel x86 platform, which is very mainstream. 

We are not using the Red Hat Virtualization product. We are using VMware just so we can conform to the corporate portfolio.

Our RHEL alerting and operation dashboard is not our route one right now. We have been using Centreon, which is derived from the Nagios approach, for about seven years.

With AIX, we couldn't get a single software open source to run. It was like a write-off, except for reducing a file system or logical volume in Linux.

We are a bunch of techies here. RHEL is not managed by end users. We don't really mind the GUIs, because the first thing that we do is stop using them. We are using Ansible, which is now part of RHEL, and that can automate the living heck out of everything. For now, we are not using the Power approach, but we may in the future. We are doing a business case for that, as it would be an easy sell for some communities and the use cases are not techie-to-techies.

There is a cloud, but we have very little infrastructure as a service in the cloud right now. 

It delivers to the targeted audiences. Could Red Hat Enterprise Linux be used in all types of other scenarios? Most likely. They have an embedded version for microcontrollers, i.e., things that you put into your jewelry or light switches. However, this is not what they're aiming for.

I would rate RHEL as a nine and a half (out of 10), but I will round that up to 10.

We use containers to create RPM packages for graphics drivers.

The main reason to use Red Hat Enterprise Linux is to maintain support for creating images for various purposes, including what we use for gaming. We rely on a range of supported tools and resources, and this enables us to build images tailored for specific target devices.

The RPM manager is paramount for us, as we need to generate these packages for our customers, enabling them to install the packages on their systems at a later time. The knowledge base they offer has proven to be quite efficient and we haven't encountered any significant challenges.

The technical support should be improved. I believe it would be beneficial to notify the customer in advance of any planned maintenance so that we can better coordinate and plan our customer interactions accordingly.

We have been using it for six years.

Recently, we encountered issues when the Red Hat server was in maintenance mode, and we attempted to capture images directly from another server for our builds. Although I set up alerts for planned downtime on the Red Hat server, I didn't consistently receive these alerts. I would rate it seven out of ten.

Neutral

We follow a weekly patching schedule to fetch the latest updates. Our process involves applying these patches to the image and then generating containers, which we subsequently upload to our registry. We accomplish this using Ansible.

The only inconsistency we've noticed so far is with the server, which might be the only aspect we could potentially raise concerns about. Overall, I would rate it eight out of ten.