Red Hat Enterprise Linux (RHEL) Reviews

I am primarily doing developer enablement for users of Red Hat-based software stacks. Most of my experience for the last five years will be in the context of AWS and Azure. As my customers are primarily cloud-based, they are primarily using the Red Hat repositories hosted with Amazon and Azure.

My customers are primarily DoD, so they are using EL7. We are trying to get them to move in the direction of EL8, but it is a slog.

As an industry recognized platform, and the fact that Red Hat goes to great lengths to get their stuff security accredited, it makes it a lot easier for me to get applications put into production since I can point my customer security people at the work that Red Hat has done upstream. Then, all I have to do is account for the deltas associated with the specific deployment in their environment. It greatly reduces the workload when you can get it down to just deltas.

Automation is the most valuable feature. I don't like having to solve a problem more than once. If I can just whip up some code to take care of deploying something, responding to something, etc., then that is what I prefer. It is a lot easier out-of-the-box to do than it is with Windows. With Windows, there is always the process of bootstrapping into being able to have the automation framework available, then making the automation framework work.

In the AWS space, the cloud network is packaged. Tools, such as Ansible, Puppet, and SaltStack, are all easily found and installed. That is quite helpful.

The integrated solution approach makes it a lot easier to deliver things on an infrastructure as code basis. So, if customers need something deployed, I can just do a set of automation for them. This gives them an easy button to take care of the rest of their solution, whether that be deployment or lifecycle maintenance of a deployment.

I use their tracing and monitoring tools on an as needed basis.

It is great for the stuff that Red Hat either owns outright or is the lead on the upstream product. When it comes to third-party tools, it can be a little iffy. Some of the database solutions and data governance solutions that I have had to implement on Red Hat have not been fun.

I would mostly like to see improvement around corporate messaging. When Red Hat 8 came out, and Red Hat decided to change, it inverted the relationship between Red Hat and CentOS. This caused my customers who had a CentOS to RHEL development to production workflow quite a bit of heartburn that several of them are still working out. A lot of that probably could have been avoided through better messaging. 

I have been using it for a couple of decades.

This is a double-edged sword. From a stability standpoint, it is great. From a facilitating development, at least up through Red Hat 7, it was problematic. If you wanted the latest and greatest version of Python, Java, or any given development language that your developer community wanted to use, then your choices were package it yourself or use SCL. Packaging it yourself was flexible, but then it caused auditability problems for your information assurance folks. Going the SCL route was good, but activating it in a way that developers were comfortable with was problematic. It looks like the AppStream capability in EL8 will ease some of that. However, I haven't had enough customers using EL8 yet to verify whether what seems more usable to me will be more usable for them.

So far, I haven't found anything that inhibits scalability. The only thing that I run into is probably more a side effect of how my customers use things than Red Hat itself, in so much as my customers tend to prefer to implement things in a way where it is a bit of a heavier weight than they absolutely need. This slows down the speed at which one can deploy. However, this is more of a customer issue than a Red Hat issue.

RHEL is the basis of all my customers' cloud and container solutions. 

I have worked with Red Hat technical support minimally. Most of my customers operate in the DoD and the intelligence community. Much of their stuff isn't really able to be supported because you can't export logs or anything like that. At best, things are indirect. The things that I tend to seek assistance for are fairly edge case problems. Then, it is a case of needing to work through the process to get to the backline engineers. Every time I do that, it is not a quick process.

When I get to the part of the support system that I actually need to be at, then I would probably rate support as 10 out of 10. Getting to that point in the support resources is about five out of 10. Overall, I would rate it as six or seven out of 10.

Neutral

I automate everything. I write the automation that creates the VM templates. Once my automation is done, there is really nothing to set up.

Operating in the cloud space, we typically point our customers to pay-as-you-go licensing, which comes through the various cloud providers repository services.

I have experience with probably two dozen different Unix-type operating systems. However, 2010 would have been the last time I touched something other than Linux and 90% of that would be Red Hat.

For anyone who is doing physical or on-premises virtual, I would probably point them at Satellite, and if they can afford it, as an enterprise license. This is just so that they don't have to deal with picky unit licensing concerns. However, for people who are fully cloudy, I would tend to push them more towards using the RHEL solution.

Some of my customers use OpenShift, many of my customers use Ansible, and a lot of them use a local Docker and Podman. The ones that actually run within Red Hat integrate just fine. The ones that Red Hat runs on top of, those are a little more difficult to speak to. Running Docker inside of RHEL is easy. It is much better on EL8 than it is on EL7.

I like it enough that I use it as my own operating system for my personal web and mail server. So, I would rate it as eight or nine out of 10. The primary hits against it are that if you want to do anything bleeding edge, the pursuit of stability works counter to that.

We use it for core infrastructure services, like package mirrors, configuration management hosts, and proxy requests going to the Internet or as reverse proxies in front of our applications. Our campus management software is delivered via RHEL and applications like Wikis learning platforms.

Almost all machines are running on virtualization. Only a few bare-metal systems exist today. Currently, we are not engaged in any kind of public or hybrid cloud environment.

One of the most important features is the package manager. It provides the ability to very easily roll back transactions when something has gone wrong. It is an easy-to-use tool that helps me in situations where something unexpected has happened. I found that this was one of the solution's major advantages over other distributions.

Another point that I really like is the ecosystem around RHEL. Red Hat provides security and bug-fix Erratas for every single update out there. Thus, I have a lot of pretty sophisticated information so I can inform myself about what an update is for, what could happen when I install it, or what would happen if I don't install it. The value added by the information Red Hat provides for its distribution is pretty good.

RHEL provides features that help speed deployment. We use Ansible in our environment, which is the free version that is usable with a RHEL subscription. It is pretty easy to set up a baseline configuration for each system as well as deploying our applications and configuring them.

Ansible and RHEL integrate pretty well. You see pretty quickly that Red Hat has a huge engagement in RHEL as well as in Ansible. They work very well together. This integrated approach decreases the time that we need to set up configuration jobs. It helps us to have faster deployments as well as make configuration changes faster and more secure. It is a tool for everyday use.

We use the solutions AppStream repository at some points. Compared to earlier versions of RHEL, we like that it is now easier to use the newer versions of run times, e.g., Python. 

We use RHEL to run multiple versions of the same application or database on a specific operating system. For example, we run several versions of the MediaWiki platform on the same system. We usually have one version of a database management system per host. If we need another version, we deploy it on another host.

RHEL's feature for managing multiple versions of packages is getting better. In earlier versions, when I think about the Red Hat software collections, it was sometimes pretty hard to set them up and use them on a daily basis. With AppStreams, it got easier. What could still be improved is the lifecycle information about AppStream versions. Usually, when doing a major release, I have 10 years of support divided in different support phases, but a lot of applications from the AppStream repository have a completely different lifecycle so you need to check it separately. For example, a certain node.js version will be at the end of support in 10 months. I must make a note to update to a new version before it reaches the end of support. It would be awesome if the end of support date of the application streams would follow a stricter lifecycle with aligning end dates.

The Authselect tool needs improvement. This tool is used to connect your system to an identity provider or directory service, e.g., openLDAP. There is documentation and descriptions. While there are a few use cases and examples described, it is sometimes hard to use these tools to set up the configuration that we need for our specific environment. I would like it if there was more general information about the tool, not just describing a use case. For example, here is how to do it and how to connect to some kind of openLDAP service as well as more information about when you need to configure certificate services and mutual authentication. There is room for improvement, but it is more room for improvement in the documentation area than the RHEL system itself.

We have been using RHEL since 2016. 

The stability is awesome because we have had only a few issues in operations. Once it is set up, tested, and ready for production, it just runs. For the usual maintenance tasks, like updating the system and making configuration changes, there are almost no disruptions or issues in our environment.

The availability is great. We usually don't have big issues in our day-to-day operations.

When it comes to increasing memory, CPU count, or deploying more RHEL instances, the scalability is good. We don't have any issues. However, I would guess it would be the same with another distribution.

I would rate Red Hat's technical support for RHEL very differently. It depends on the area that you are looking for support. For example, when I have an issue with a RHEL core platform, there are a lot of good support engineers available to help with my issue. There have been phases where one could get the idea that they are short on staff with Ansible experience, but it is now getting better again. However, the average experience and response times are good. Their responses are also good. When you have a difficult case, they are able to escalate it quickly. Therefore, you get an engineer with the appropriate background to help solve your issue. I would rate the technical support as a solid eight out of 10.

Positive

I was part of a working group who decided which major enterprise distributions we would introduce into our organization. Before 2016, we only used a very small number of Linux installations and different distributions. As an outcome of this working group, we decided to use RHEL and have used it since as the only distribution in our data center. We migrated from other distributions, such as SUSE Linux Enterprise or openSUSE, to RHEL.

While all distributions share a Linux kernel, there are differences in how to manage the distribution itself. A very important part is the package management. When you have to deal with tasks like updating packages, downgrading packages, and repairing damaged package databases, you want to have one package management tool that you know very well, not three different package managers where you only know the basics. To ease the management of multiple hosts, we decided to migrate to only one distribution. We hoped that we would have an advantage in consolidation. 

The complexity of the initial setup will depend on the requirements of your organization. Generally, I find it pretty straightforward. There is good documentation for it. The installer works great. I haven't had any issues.

There are special academic offerings for academic institutes, which is pretty good. We need these offerings. In my personal opinion, the prices are okay. However, for educational purposes, they could be lower. For example, in Germany, the budget in the education sector for IT is lower compared to the huge universities in the US.

When you are only using the RHEL subscription system, it is okay. It can get complicated very quickly when you need multiple different subscriptions with a lot of SKUs. 

When someone is going to look into RHEL, I suggest starting with an individual developer subscription, which everyone can get for free. With developer subscriptions, you won't be able to contact support, but you have almost all of the important applications and features of RHEL for free. You are not allowed to build your whole production on it, but you are able to develop applications, test configurations, test the platform, and try out almost everything.

In our IT environment, we were running Solaris and Microsoft Windows. It was decided that we wanted to move away from Solaris to some Linux distributions. In the process, we looked at distributions, like RHEL, Oracle Linux, Debian, SLES, and Ubuntu. We looked at all of these points: 

• What are the management tools? 
• How does it look in the ecosystem? 
• How many packages are available and the distribution repositories? 

We created huge metrics to score all these different points. There were over 200 points to score for the different distributions. In the end, RHEL was our winner.

Red Hat’s open-source approach was an important factor when choosing this solution. For example, let's say I won't use OpenStack from Red Hat anymore. There are other OpenStack distributors out there who know the application and can help us in the migration process. It is the same with the platform. At the core, the Linux distributions are pretty similar. We believe it would be easier to move to other solutions from other vendors compared to operating systems or software from proprietary vendors.

We have plans to increase usage. Every new application that supports running on Solaris or Linux is going to be deployed on RHEL these days. I hope it will be our major operating system in the data center. So, in the foreseeable future, there would only be two operating systems: RHEL and Microsoft Windows.

I would rate this solution as nine out of 10.

Our use case is mostly for application servers. We are not really using it for any of our file servers. We have a storage department who usually just deals with NAS and things like that. However, this solution is primarily for application servers.

The biggest benefit is from a security standpoint. As the product progresses and they come up with new versions, the new security features are addressing vulnerabilities. From that perspective, it has worked well.

We use Red Hat Satellite. The integration between Satellite and RHEL works well. Satellite is mostly used to manage the repositories from a secure standpoint. We also use IBM, which is for identity management and user access, and that also works well. From an operational standpoint, it works great. We are able to manage user access with IBM, and there has not been an issue. We make role and user groups as well as host groups so different groups have access to different servers, for whichever servers are in different host groups. For example, the database team may have a user group who has access to all the database servers listed in a host group. So, the access works well.

The best feature is its dependability. We have had some situations where some RHEL servers have been up and running for five years. So, it provides reliability and dependability. It stays up.

It provides flexibility for us to come up with solutions to speed up deployment, which is great. It allows us to use it in different environments and works well with different applications. For our virtualization platform, we will just probably deploy through VMware. We are able to script and code all of the hardening procedures. If we wanted certain applications installed for deploying images, it just gives us the flexibility.

The deployment and management interfaces for non-Linux users and Linux beginners are pretty robust. It works pretty well. I know the servers themselves have a UI that is a management front-end, where you can basically do everything using the UI rather than doing anything with the command line. That is definitely good for non-Linux users and Linux beginners.

The consistency of application and user experience, regardless of the underlying infrastructure, is great. It works well. The more that they add to make it a little simpler to work with the tools and applications that they provide, the better.

The solution enables me to deploy current applications and emerging workloads across bare-metal, virtualized, hybrid cloud, and multi-cloud environments. If it was a scale of one to 10, 10 being the best, I would say nine because there is always room for improvement. It is definitely up there as far as its reliability.

In the past and with older versions, you couldn't expand the root file system without rebooting the server or restarting the operating system. That is something that they have actually corrected now, which is great. They corrected that issue somewhere around RHEL 7. 

Since 2005, I have worked at various companies who have used this solution.

My current company was using it even before I came.

Once it is up and running, it is solid and stable. It has a stable OS. I haven't had any issues with it.

Usually, if there is any particular issue and it gets to a point where we need to open a ticket, then we will open a ticket and just generate a dump file. We then upload it and wait for them to respond.

The technical support has been great and awesome. They have been able to assist, provide solutions, and root cause analysis for different issues. I would rate the technical support as nine out of 10. There is always room for improvement.

Positive

Before 2005, I worked as a Unix engineer for Solaris and Sun Microsystems. Once I left that company who was working with Solaris, that is when I started being more like an administrator for Red Hat Linux for different companies.

Most companies go with some sort of way to deploy an image. I have done standard, straight installs, installing the solution to laptops. That would be the equivalent of installing it to bare-metal.

It takes maybe 15 to 20 minutes to deploy a server. That is just with all the automation that we have added as well as having to deploy a base OS image, hardening, and adding all the software that we want. For a company-base installation, it takes about 20 minutes.

This solution is definitely one of the best versions of Linux out there to use, especially if you are looking to use Linux in an Enterprise fashion. This is mainly because it has the best support out there. It is also stable and dependable.

We use outside monitoring tools, not the ones that come with RHEL.

We are using other tools to deploy base images to our private cloud. So, we're not exactly using Red Hat tools for this use case.

They are a great company overall. It is hard to say where they could improve. They have user groups. They put out a lot of messaging and information. The solution is easy to learn and get to know their products and what they do. From a personal standpoint, I have everything that I need.

If I wanted to run multiple versions of Node.js, there are ways to do that without using AppStream. More recently, I have been working with different versions of Node.js, having it in different versions on one machine. It works well. Just the fact that I have the capability is great.

Among the other distributions of Linux out there, I would rate it as 10 out of 10. If I have to compare this solution against everything else out there, this solution is at the top of the list.

Our business is primarily focused on software development. We are doing development and deployment using containers. We are mainly using Docker, but we might also adopt Podman later.

Our business logic is mainly for our own software development. We mainly have Java applications, Java containers, Tomcat, and Java frameworks. These solutions cater primarily to our business-level operations.

We are using Red Hat Enterprise Linux on-premises.

Red Hat Enterprise Linux gives us a standardized way of handling various tasks. Everything is the same in our environment.

It gives a standard procedure to do everything. It also gives standard APIs and a stable environment.

It works very well for our business-critical applications because of its stability and support. We have some kind of support in terms of the life cycle of the operating system.

Its long lifecycles, updates, support, and documentation help with business continuity and compliance. With reference architectures, we can straightaway get working solutions.

We can rely on security features like SELinux and run several workloads for WordPress and so on. We can rely on Red Hat.

We have used Red Hat Insights for certain things, and it has been helpful.

Stability, support, and life cycle management are valuable. We get fixes quickly. We can rely on them for features and so on. We can rely on their support. In the case of an issue, we can get somebody on the phone.

Red Hat could offer a containerized version of the operating system, potentially moving towards a more containerized ecosystem. 

More flexible tools for dealing with complex things like SELinux would also be beneficial. Its built-in security features are good, but they are quite complex to manage at an atomic level.

I have been using Red Hat Enterprise Linux for 25 years. We are mainly using Red Hat Enterprise Linux 9, but we also have Red Hat Enterprise Linux 7 and 8.

Red Hat Enterprise Linux is very stable. However, sometimes, there might be some load balancing issues leading to performance issues, so we have to figure out all those. Usually, Red Hat tools are helpful for that.

With automation, we have been able to handle scaling efficiently. We are using an internal cloud, which suits our needs without relying on OpenShift or VMware.

The support from Red Hat is very good. We have collaborated with Red Hat remotely and have been satisfied with the assistance provided for our customers' cases.

Positive

The pricing is suitable for midsize to large companies, though small enterprises might struggle. It is comparable to Windows licensing.

I would advise considering the lifecycle and support that Red Hat offers. They provide long-term support and have best practices for addressing vulnerabilities and attack vectors.

I would rate Red Hat Enterprise Linux an eight out of ten.

We use Red Hat Enterprise Linux to provide a Platform as a Service for our customers in the cloud, upon which we have built additional software. This encompasses Red Hat and Synthos, including all Red Hat derivatives.

We also use it for our security-related applications primarily due to the robust enterprise support and comprehensive security features it offers.

Using Red Hat Enterprise Linux for containerized workloads has increased security, stability, and trust, ultimately simplifying our work.

Red Hat Enterprise Linux enhances the reliability and security of our hybrid cloud environment.

Red Hat Enterprise Linux performs well for our business critical applications.

We chose Red Hat Enterprise Linux for our environment due to its robust built-in security features, including proactive security fixes and an enterprise-class operating system with reliable support services that enhance security and reduce risk. Furthermore, the secure base OS Docker image strengthens our environment's overall security posture.

Red Hat Enterprise Linux helps reduce our total cost of ownership due to its security, stability, and enterprise support. The tightly integrated Red Hat portfolio simplifies working with their products and achieving the desired return on investment.

The most valuable aspects of Red Hat Enterprise Linux are the security and stability it provides.

I encountered an issue updating the time zone for one of my assigned countries due to a daylight-saving time change. Although we collaborated with Red Hat to build a package that addressed the issue, it wasn't delivered promptly, necessitating manual workarounds to resolve the problem.

I have been using Red Hat Enterprise Linux for almost 15 years.

Red Hat Enterprise Linux is exceptionally stable, minimizing the risk of outages or issues stemming from the operating system itself. This reliability allows it to run seamlessly in the background, freeing administrators from constantly addressing kernel bugs or faults in core system applications, ultimately saving significant time and manpower.

Red Hat Enterprise Linux offers flexibility to scale as required.

My experiences with Red Hat technical support have been mostly positive, though I've encountered some issues occasionally.

Positive

Red Hat Enterprise Linux is suitably priced with various support tiers to match organizational needs and environments.

I would rate Red Hat Enterprise Linux nine out of ten.

When considering a Linux operating system, the choice depends on the intended use. For enterprise environments requiring dedicated support, Red Hat Enterprise Linux is recommended. Smaller projects or testing environments may start with a similar option and transition to Red Hat as the business grows.

We primarily use RHEL for data analysis servers supporting our scientific researchers, who access the systems remotely.

The reliability and long support lifespan of RHEL are crucial for us. It lasts for ten years, meaning we don't need frequent changes. Updates are quick, simple, and reliable, automatically backing out if issues arise, saving us from patching headaches.

I'm eager to see how the AI features in RHEL can enhance our capabilities. We hope it will improve tasks we have found challenging in the past, like documentation searches. We are particularly interested in automation and easily finding information.

I have been using RHEL for 15 years.

RHEL is scalable. We have scaled our data analysis clusters with it quite well.

I would rate the customer support as a nine out of ten.

Positive

Deploying RHEL for the first time was simple. It was a long time ago, and we had documentation from previous admins which made it straightforward. We did the deployment on our own.

We have seen ROI with RHEL. Our biggest investment is in professional development through Red Hat Summit, online training, and a Red Hat Learning subscription, which we have used for courses.

Our experience with RHEL pricing and setup costs has been good. We will be purchasing an extended license for another year.

We have used RHEL since I joined my company about 15 years ago. We have looked at other options like Fedora and Ubuntu for more up-to-date libraries, but we keep coming back to RHEL for its reliability and long-term support.

Using RHEL for containers has simplified our processes. While we, as system managers, aren't heavily involved in development, we provide RHEL containers for our developers. Overall, it has improved support for container management within our organization.

We rely on Linux for our web and file servers to ensure file integrity and service verification. Additionally, we use the host firewall regularly on all our hosts for enhanced security.

We started agile development and containers help us by making it easier for developers to teardown and recreate environments. This allows for more frequent updates, improving our workflow.

Our Red Hat portfolio reduced our cost of ownership by using RHEL Workstation instead of full server licenses where possible, saving money. We use full RHEL only on our enterprise production servers.

I would advise a colleague to check out Red Hat for its long-term support and reliability compared to other open-source Linux-based operating systems.

Overall, I would rate RHEL as a nine out of ten.

We have almost thirteen servers. There are SaaS applications installed on this server. We leverage Java and the functionality during installation. We install it on the platform and configure it there. Some are custom applications. Our database is also in the Red Hat Linux environment. 

The solution offers users easy access. It's very simple to have and use, from an admin perspective. 

The offering provides me with all I need to serve the operation in terms of usage and capabilities. 

The general user commands are good. They are helpful for starting and stopping applications and restarting and editing files. The maintenance of user-level processes is easy. 

We're not using it in a graphical environment, we're only using command line mode. There may be a lot of features, however, I don't use everything since I don't need to. 

There are millions of commands you can use, although we use only five or ten.

Likely the solution has helped our organization save on costs. I'm not sure by how much, as I don't have visibility into that aspect.

It's very easy to use across physical, virtual, and cloud infrastructure. Specifically, on the cloud side, I have noted it's quite easy. Also, on a virtual machine, you can create a cloud version of your infrastructure in a minute. 

For my work, the solution is not missing any features. We;re only using the command line and that is enough for us. 

Maybe they need to make it easier to apply patches from different resources. That said, at my level of usage, I never have to apply patches. 

I've used the solution for almost ten years. 

It's a stable product.

While I'm maintaining 30 servers, there are hundreds of servers in use. 

The scalability is good. We are able to increase capacity and functionality based on our demands. 

I'm not sure if the company has plans to increase usage in the future.

I don't directly deal with technical support. I might send a ticket to my side, and if they have to, they would be the ones to reach out to Red Hat. 

We used Oracle Linux before we moved over to Red Hat Linux. We likely switched due to costs and licensing. We also use Windows extensively. Since we used the same architecture, we didn't need to use any third-party applications.

As an admin, I was not involved in the setup process. 

If there is any maintenance needed, we get support from the Red Hat team.  If anything comes up on the operating side, our team will take care of it. 

I'm only using this solution as an admin and, therefore, have no visibility on costs. 

We did not evaluate other options before choosing this solution.

I'm an end-user of the solution. I had admin-level access to the product.

Red Hat Enterprise Linux does not enable us to achieve security standard certification.

I'd rate the solution ten out of ten. 

My primary use case is for web applications and database applications. I've come across quite a few use cases at different companies.

The most valuable feature is the package management. It helps a lot. I also like the support. 

Red Hat is a Linux-supportive and well-managed offering. It helps a lot in terms of when we're working in production, it gives us the confidence that our packages are legitimate and genuine and we always have support available. It helps a lot. Red Hat Enterprise Linux gives peace of mind compared to other unsupported Linux distributions. 

I also like Red Hat Satellite. 

I haven't used Insights yet but it seems interesting. 

The ability to patch Red Hat Enterprise Linux through Satellite is a huge contributor to mitigating all of the compliance requirements.

Red Hat Enterprise Linux has absolutely affected our security's uptime. None of the other distributions are nearly close to what you can get with Red Hat Enterprise Linux. Red Hat Enterprise Linux is something that helps a lot in ensuring that your secure application is up all the time and that you're not getting hit by vulnerabilities. It is an easier way for you to mitigate vulnerabilities when they're around.

The knowledge base is very useful. The only thing is that you need to have an account to get access. In terms of the content, the relevance, and being able to use the knowledge base to address things I've needed to deal with, it's awesome. For example, I was trying to add proxy configuration to the package manager once and if it wasn't for the knowledge base, I wouldn't have been able to do it.

I like it the way it is. 

It's getting easier for the community to use it free of charge. If you have an account, you get to use it. It would be better if the community could use it on their own for lab projects.

I have been using Red Hat Enterprise Linux since 2011. It's been 12 years. 

On the few occasions I needed to reach out to support, I was very satisfied.  

Positive

I have used Linux distributions but when it comes to the work I'm doing at my company, we always use Red Hat Enterprise Linux. 

The biggest differences between Red Hat Enterprise Linux and the other OS' are the support, Satellite, Insights, and the fact that Ansible was acquired by Red Hat so you can use all its automation and toolings. The entire ecosystem works very well together.

Red Hat has not personally enabled me to achieve security standard certifications in the projects I've worked on but I could see how it would help. 

I would rate Red Hat Enterprise Linux a ten out of ten. I really like it. 

We do a lot of patching and upgrading with Ansible and we keep the host up to date all the time.