Red Hat Enterprise Linux (RHEL) Reviews

We are a Linux shop, so a lot of our engineers are familiar with Linux. We try to push Red Hat Enterprise Linux instead of Windows. The reason for it in the beginning was licensing. Some of it was because of the way the contract was set up. It was cheaper, but we do use it now just for the ease of it. I do not know if it is because of Ansible, which we use for a lot of our day-to-day operations, that we tend to lean more toward Red Hat.

Red Hat Enterprise Linux has affected our system's uptime or security. I know Microsoft publishes zero-day vulnerabilities for Windows as fast as Red Hat, but we noticed that in terms of problems or alerts that we get for attacks or viruses, there is not anything on the Red Hat side. That is why we feel that it is more secure. It might be just the nature of Red Hat where all services and ports are off. It is not like Windows where everything is on, and you have to turn it on. I was having a conversation with one of the gentlemen who is also attending the Red Hat conference, and I got to know that there are built-in NIST features with Red Hat that we could turn on, so we do not have to try to figure out how to harden our system.

The testing of the updates or the packages of the kernel is valuable because I used to be a part of the Fedora project. I know it is all vetted out before it gets to production, but a majority of it is the support and the relationships I have with the Red Hat employees assigned to our account.

As they move over to newer versions, certain things change, which is expected as the technology matures or new things come out, but what really surprises me are the features that are there in the cloud, such as Red Hat Insights. They are not there on-prem. There are a lot of things on the cloud portal that I did not notice before, and I was surprised because we were unaware of them. Red Hat is doing a lot of investment in that sense.

The knowledge base offered by Red Hat Enterprise Linux is good. It is easy to parse through all of the knowledge base. I do not know if Windows does it because I have not looked at it, but in Red Hat's knowledge base, there are a lot of things. They fast-track a lot of things in their knowledge base, even when they are not yet official. Especially with the tie-in with Bugzilla, even though it is not a true KB, we can see and follow if other people in the world are hitting a certain problem or something similar to what we are experiencing. I like that.

It would be great to have an overview of how various Red Hat products work together. They can show how to tie all those pieces together and how to have the products that we work together for our day-to-day processes.

I started with the company around 2012, and they have been using it even before then. At that time, it was Red Hat Enterprise Linux 5, and now, we are up to Red Hat Enterprise Linux 9.

In 10 or 11 years of using Red Hat solutions, I have opened only one or two support tickets. It probably was something during a patch and during Satellite 5 to Satellite 6 migration. I would rate them a 10 out of 10.

Positive

In Linux, there are so many different flavors, but I am partial to Red Hat because I have been a part of the Fedora project. At our place, we have only two operating systems: Microsoft Windows and Red Hat Enterprise Linux. I know CentOS, but that is usually because the appliance from the vendor was set up using that. That is why we had a few instances of CentOS in the past, but nowadays, I do not see any other flavors of Linux.

For the majority of our use cases for Red Hat, we have on-prem deployments. There are some things that they are trying to spin up on AWS. I do not know if they are cloud-native apps or not, but I know our developers are now moving on to it.

I have been involved in the initial setup, upgrades, and migration of Red Hat Enterprise Linux. I did not have any problems while going from major OS versions. I always push new upgrades or homogeneous migrations, such as from version 6 to version 7 to version 8. There is probably an option to upgrade in place. Overall, with Red Hat OS, I have not seen many problems. A long time ago, when they went from Python 2 to Python 3, there were certain things we had to change in the script.

I know that Red Hat is moving to Wayland from X11, but I do not see any problems there. From Satellite 5 to 6, it was a bit hard in the beginning, but now, it is pretty self-explanatory. Overall, everything about which we had questions was very well documented.

In terms of our upgrade and/or migration plans to stay current, first, we look at the EOL and the roadmap of Red Hat because of security. We used to offer every single version before the said EOL happened, but now, we just do an n-minus-one. We try to maintain the newest and one level below version. SAP users are the biggest Red Hat Enterprise Linux users in our environment. They have a particular PAM and upgrade path that they have to do with Red Hat. We also wait to be certified to certain versions, but our main strategy is the newest and one major version down. We try to get everybody off the other versions.

Our provisioning is all done using VMware products. We have a vRealize automation, now called the Aria automation, to spin it up. Patching is done through Satellite. I do not do it, but when I watch them doing it, it seems it is just using remote SSH commands against the list of non-prod and prod servers. It is something simple. We do not seem to be doing anything complicated. I am wondering if there is a better way to do versioning control or patching and whatnot, but currently, it is very simple.

I am satisfied with the management experience not only in terms of patching but also the day zero to day one or day two stuff. We are interested in utilizing Ansible to eliminate human error and whatnot. During provisioning, we have Pearl scripts that we have to manually trigger. I know we can use Ansible for that, but it comes down to the cost of entry which is still very high. 

A lot of people are moving into the core count for licensing. We still have a few with one-to-one standard server licensing, but we are utilizing the virtualization host licensing. We license it based on the host, not based on VMs, which is cool. I was very happy that there was certain licensing with SAP to have access to SAP repos. Its cost was the same as the regular one, so I was happy about that.

The only pricing that bugs me right now is the Ansible pricing. We wanted to take a look at Ansible, but the biggest thing a year back with Ansible was that the management did not want to spend half a million on Ansible Tower. They wanted to see first if we would use it and not waste money. I do not know if things have changed now, but Ansible is probably still expensive. That is one of the routes that we want to go to. We will see if we can utilize Ansible Tower, so pricing-wise, that is the only thing that pops up. It is too expensive. The cost of entry seems quite high.

Overall, I do not see any issues with what we have spent on Red Hat. We also have learning subscriptions that we pay to Red Hat for the training, and I do not feel we have wasted any money.

Red Hat Enterprise Linux has built-in features, but we do not use them. It is one of the things about which I need to talk to our account manager. There are so many different ways to skin a cat. My department has so much money, so they bought everything, but a lot of the security features, such as SELinux, are disabled for us. We handle the firewall rules, access lists, and other things at another location rather than on the actual VM itself. It does not hurt to do it at multiple places, but operations-wise, it would be a nightmare, so we try not to do it. I know there are a lot of cool new things built in Red Hat, and that is something we should circle back and take a look at.

I have seen Red Hat Insights. I clicked on it one time when our account manager was showing us something. They have so many features in the cloud that we do not know we can use. Maybe it is wrong to assume, but the reason I do not look at Red Hat Insights is that a part of our patching is already included. We are not that strict about what we patch in terms of the versions. It is useful, but Red Hat emails us anyway. They tell about the severity of an issue. We do not look at Red Hat Insights. We see those emails and we see CVEs. If a package is installed and applicable to our VMs, we just use Satellite and patch that particular vulnerability. 

I have also tried the web console once. It looked interesting, but we do not have much use for it because a lot of our customers or application owners are server admins. About 99% of our Red Hat installs are all minimal installs. We do not have a GUI. There is just a terminal screen. Even though they could console in and do whatnot, it is all done via SSH.

Overall, I would rate Red Hat Enterprise Linux a 10 out of 10.

We run web apps. We run databases. We run a high-compute platform on Red Hat Enterprise Linux variants.

All of our customers run Red Hat Enterprise Linux. We run Red Hat Enterprise Linux for mesh nodes. For anything Linux, if we can use Red Hat Enterprise Linux because it is supported, we put it on Red Hat Enterprise Linux. Probably 60% to 80% of our infrastructure is Red Hat.

Having a stable Linux platform means I am not spending my time rebuilding Linux systems, constantly patching, and doing things like that. It helps to have an approved and supported platform. I know they have tested everything and when I patch my system, it is not going to blow up. It just does not happen. The other thing is that we have had catastrophic failures, and they have helped us out of these catastrophic failures. The support for Red Hat Enterprise Linux has always been good, and the community around Red Hat Enterprise Linux has been fantastic.

We were also CentOS users, so we have committed to AppStream as well. Being a part of the community has been a huge benefit for us. Community adoption means it is easy for people to find information. It helps new people get on boarded into Linux.

We mostly have an on-prem environment. VMware is a significant chunk. We do have some Red Hat clusters. We do have clustered applications, both physical and virtual, running on the cluster. We do have some cloud. We have our own internal cloud with VMware running behind the scenes. Having a consistent image means things always look the same. It is boring, but it is cookie-cutter. That is what we like. We like everything to come out the same. We have consistency and the ability to patch across our entire environment. We are also a Satellite user, so we are able to patch everything and maintain everything in a single pane of glass. It means I can have fewer admins administering many more machines. If you have a reduction in failure and an improvement in automation, things just work.

We have created what we call creator nodes. We have built a platform on Red Hat with Podman so that they can connect with Visual Studio code and do development or Ansible development. We now have our mainframe people developing automation with Linux with all of the plugins right there. It is a consistent environment for them, and that has been awesome. That has been fantastic. We have a few hiccups with Podman. They are working on the permissions to be able to have multiple people run Podman. They are working on the UID and GID problem that we had earlier. Right now, we are running Docker, but I am planning on moving to Podman once they fix that. We have also automated the build process for those nodes. If we need to scale up, we build a couple more VMs, and we are done.

We use Red Hat Enterprise Linux for containerization projects. We are containerizing applications. We are pulling the Windows container that we have and converting it to the Red Hat Enterprise Linux container. At the Red Hat Summit, the keynote about image RHEL with systemd blew my mind. It is a change from what we have been doing, but it should make a lot of things more reachable for us. It is cool because now my container image looks like my VM image. You cannot make it simpler for people to develop in a container. It looks the same. There is no difference. That is going to drive heavy adoption with us because if there is no difference, people are not going to have that fear of something new. It has 100% impacted our projects in a positive way. We have started to migrate all of our workloads to OpenShift now that we have got it in the door. It makes a lot of sense. I can redeploy. I can patch. I can do all this with code. I do not have to maintain a VM and a container. It makes life simple.

We have seen a drop in TCO because we ended up buying more than building. When you build something, there is the hidden cost of support, training, and the precarious position you get in if you deploy something you do not fully understand. We were there. We had five instances and a bunch of complexity. We reduced that down to one. We were able to simplify our complex nature. That is what Red Hat has allowed us to do. We have been able to roll out and we have been consistent. I have got machines out there that have been running for two or three years with no problems. They just patch them in the background. It just works.

I love systemd. They have made some significant improvements with the firewalld console. I do not use it that much, but I know it makes Linux reachable for people who are not normally Linux admins.

I just love the command line configuration. It makes that easy for me. Another thing is that when you combine that with Ansible, your life is simple. You can do a lot of your jobs without having to touch the system. That is my ideal.

I appreciate everything they have done. The systems are just bulletproof. We do not have problems with it. Support for file system differences and migrations has been solid.

There have been a few things that I have run into. They have significantly improved DNF and YUM, but there can be better communication around what is going on. A lot of it is related to communication. They are building solid products, and quite often, people do not find out about them until two or three years have passed. We still have not discovered everything in Red Hat Enterprise Linux 9. A lot of it is because we have not had the time, but it would be helpful to have a little bit more communication around it. Maybe that is on us to make sure that we stay updated with the community.

I have been using it since Red Hat Enterprise Linux 2.5. It has been around 20 years. I love Red Hat Enterprise Linux.

I would rate it a nine out of ten for stability. It is stable. It is fairly bulletproof. There are a lot more things that they are adding to make it better.

I have had no problems scaling up or scaling horizontally. I have had some very large Red Hat Enterprise Linux nodes with 254 gigs of memory and a big chunky Oracle database system. We have had no problems with them. We have not had any problems with running with multiple memory cluster nodes. We have had 100 gigs network, and we had no problems. We had a high-end SAN and a high-end network, and we had no issues.

They have good integrations, and they have not had too many problems with external SAN providers. They have been fairly consistent with keeping up with everybody else and keeping their drivers good.

They are probably one of the better ones in the industry. I can get a real answer, and I do not feel like people are breathing down my neck and saying, "I am going to close your ticket. I have not heard from you in 15 minutes." It has been a very positive experience. They have always helped us out when we have completely gone sideways.

They are very patient with the level of experience that a lot of people have. We have a significant number of junior admins who put in tickets that probably should not have been put in. They have been very patient. Overall, it has been a good and positive experience.

Positive

Before Red Hat Enterprise Linux, I was strictly using Solaris and AIX. I never used Ubuntu. It was just straight, big-frame Unix before I went to Linux. I did not change too many platforms.

We use Ansible to deploy Red Hat Enterprise Linux machines on VMware. That is 80% to 90% of our workload. For everything else, I have done PXE boot and kickstarts.

We are using a hybrid cloud. Our cloud providers are Azure and AWS. We work with both. The deployment on Azure and AWS was simple. We built Elasticsearch inside of Azure. It was a click-button deployment. We use TerraForm to deploy most of it, and then we have Ansible to do the rest.

I wanted to try to do more infrastructure as code, but it is hard to get traditional admins into that mindset, so it is always a mix. I deploy these servers for them with TerraForm, and then I pretend I never did, and they can do whatever with them. It then goes back into traditional life cycle management. Sometimes they delete them, and sometimes they forget about them. Satellite has helped us keep track of where everything is. It has helped us track our life cycles. It has been helpful for us.

We have used Red Hat consultants multiple times. They helped us set a few things up and clean up our pipelines. We have been very happy with our Red Hat consultants and our last deployment of OpenShift AAP. We loved their consultants. They were fantastic.

The biggest ROI that we have seen by using Red Hat Enterprise Linux is accessibility to information for frontline support people, midline support people, and developers. There is a ton of information, and there is a ton of community support.

For us, Red Hat Enterprise Linux is a consistent platform because if we are on a customer's Rocky machine, we already know Red Hat Enterprise Linux. We can deal with that. It is a skill set that is very broad across multiple platforms. That means we can apply what we have learned and what we have been trained in. While working with the Red Hat Enterprise Linux team, we have learned best practices, and we can apply those across the board. That partnership has helped us better our internal practices whether it is Red Hat Enterprise Linux or not. That is a positive. Satellite has also been a real positive for us because we can now manage all of our systems from a single pane of glass. That is what my frontline people have been asking for. They wanted one place to patch the systems, and now they can.

Our experience was incredibly positive because we started working with OpenShift before we were fully licensed. They knew we were going in that direction. The same thing happened with Red Hat Enterprise Linux. They knew we would buy tons of Red Hat Enterprise Linux, so they were a little bit more relaxed. We wanted a thousand licenses, and we could pick those up. We true up. Our license experience has been positive with the exception of having to deal with all of the broken-up accounts, which is as much our fault as anybody's.

My biggest complaint is that we have eight or ten different contracts. It is hard to keep track of what is on what and where we are getting the most value-add out of our benefits.

They are helping us solve that problem. We have reached out to our account executives. They will help us solve that problem. That is a huge step because that has been a problem for 15 years. It will help us consolidate and understand what we are spending across the board instead of seeing what we are spending in chunks.

OpenShift has come close to paying for itself in the first year and a half. That is an easy business case to make if you have the direct ability to show cost savings. We are getting cost savings, and we have the ability to show those cost savings. These are the two major benefits we have seen with AAP and Red Hat Enterprise Linux bits. That has been a positive for us. Red Hat Enterprise Linux AI and some of the other things they are starting to do are probably going to enable a lot of our developers to start taking advantage of them. Red Hat Enterprise Linux AI changes the belief that AI is out of reach for a normal developer.

We considered the idea of building this entire platform on Rocky as a free solution. It just was not cost-effective. There are hidden costs of patching and maintaining. They require care and feeding. We wanted cattle, not pets. We had a bunch of pets. Red Hat Enterprise Linux enabled us to get into that cattle methodology and mindset. Our mesh nodes are built on Red Hat Enterprise Linux 9. If my mesh node goes sideways, I do not care. I just delete the VM, redeploy it, and run my playbook. In 15 minutes, I am back up and running again. Why would I troubleshoot it? It takes time. I do not care about troubleshooting. It enables us to rinse and repeat a lot of our processes.

People turn off too many of the tools way too often. We have a lot of room for improvement as an organization to embrace SELinux. We are still working on that. That has a significant amount of value. We want to embrace the GPG sign code in AAP. I do not want anything but approved containers and code running on our platform and our customer's platform. They have enabled us to be incredibly secure, and we are yet to fully take advantage of those offerings. It is a goal, and we are going to get there.

To a colleague who is looking at open-source, cloud-based operating systems for Linux instead of Red Hat Enterprise Linux, I would say that Red Hat Enterprise Linux-based variants are the best in my opinion. If I have a choice, I will always go for CentOS, Fedora, Rocky, or something else that is Red Hat Enterprise Linux-based. If they were not going to go with Red Hat, I would probably tell them to go with CentOS but stay behind a little bit because they do not want to be at the bleeding edge of CentOS. That relationship kind of changed when they took it to AppStream instead of a more supportive platform.

I would rate Red Hat Enterprise Linux a nine out of ten. They keep doing well, and they keep getting better. As long as they stay on the same path, I do not see us not using Red Hat Enterprise Linux in the future. It has been consistent. Why would we change?

We use Red Hat Enterprise Linux as the operating system to host various applications developed by our application group. It has our test tools, web servers, and Java applications. We install it based on the requirements of the applications.

It is a good product. All Linux solutions are pretty solid. It carries a different business model than a lot of them, which fits more into our business model. That is where it excels. We do not prefer unsupported ones or buying third-party support.

The most valuable feature of Red Hat Enterprise Linux is its support. I primarily use the product because it offers a phone number for support when needed. 

It integrates well with our existing systems like SaltStack for patching and provisioning. However, its primary value is in having support when issues arise.

There is room for improvement in terms of pricing and its knowledge base. 

I consider the cost high. The knowledge base is extensive and deep but can be confusing due to outdated or non-applicable information that you have to sift through to find relevant answers.

I have had experience with the basic and extensive use of Red Hat Enterprise Linux for about 15 years.

Customer service varies. I would rate their support a five out of ten, as it depends on the person at the other end. Sometimes the support is good, and sometimes it is not so good. It is like any other support organization.

Neutral

I did not switch from any previous solution. Red Hat Enterprise Linux has been in use since before my tenure.

I work in the casino gaming industry. Most of our servers are in Windows. We have about 30 Linux instances. We install it based on the implementation requirements of an application. There is a justification for putting an application into our environment. It goes through a process at our company, and then where we install it or what we install it on is usually up to the requirements of the application.

We have on-premises and cloud-based environments. Red Hat Enterprise Linux is running in one of those environments. It has adequate features for security in cloud environments. 

We use SaltStack, and we built the patching mechanism ourselves. We are pretty satisfied with it. If we were not satisfied, we would change it.

The upgrades with Leapp used to be painful. It used to not work at all for us. When we went to Red Hat Enterprise Linux 9, it did work, but it was a fairly painful process. The advantage is we do not have to reinstall the apps on top of the new image of Red Hat. It is an in-place upgrade. The problem is that you can install Red Hat Enterprise Linux in 50 different ways, and in the past, Leapp assumed you did it the default way. They have added some flexibility so that we can work around some of the stuff, but it makes you install it a certain way, which is not necessarily the way we would do it, mainly because of our security standards and performance needs.

We have not experienced a noticeable return on investment with Red Hat Enterprise Linux itself, as the operating system serves its intended function without bringing additional advantages.

Pricing depends on the model used, costing about $3,000 per virtual host in the virtual environment. It varies depending on whether you get high availability. There are modules that are upsold such as kernel patching, which we do not use due to cost considerations.

In the cloud, we use their licensing. For on-premise, we use the subscription, so we have two different licensing models.

I would rate Red Hat Enterprise Linux a seven out of ten.

In our environment, we primarily use Red Hat Enterprise Linux (RHEL) for managing customer environments and our own. The customer environments are mostly Apache web servers. Some customers have databases, like Postgres, running on Red Hat Enterprise Linux. Others run native Docker on it to manage application dependencies. 

We run containerization projects in the OpenShift environment based on Red Hat Enterprise Linux OS because that's more suitable for containerized workloads. You can do some machines on Red Hat Enterprise Linux, but not all of them. Your worker nodes need to be Red Hat CoreOS, but your master nodes can be Red Hat Enterprise Linux.

I was more experienced with other Linux distributions and Docker. It's open source, so you can fetch Docker and run it, but they don't have support if you have questions or if something isn't working as expected. Podman is similar to Docker. I don't primarily use Red Hat Enterprise Linux for containerization, but I set something up in Podman on Red Hat Enterprise Linux. It isn't used that much. Tinkering and development are the main reasons you would use Podman on a single centralized Red Hat Enterprise Linux machine. If you want to orchestrate on a larger scale, you use OpenShift.

Red Hat Enterprise Linux has made significant contributions to our business continuity and compliance efforts. If a critical vulnerability is spotted in the wild, Red Hat fixes it most of the time. It's usually within a day if it's a zero-day vulnerability. Log4J was a bit more difficult because it was not a single package, but it was mostly shipped with other products. It's hard to analyze which application is vulnerable and whatnot. The solution lets us centralize development. We use Ansible to orchestrate the tooling deployment or to fetch a lot of information. 

Red Hat always clearly describes the vulnerability on its security pages as a CVE score. You can fix errors by patching or mitigating them. If the patch hasn't been released, you can mitigate it to prevent the vulnerability from being exploited. Red Hat Enterprise Linux helps us guide the data and ensure it is correctly placed. I was monitoring it daily, but it was a bit too frequently. Now, we get vulnerability notifications weekly or monthly about a vulnerability or exploit that's been discovered. I also look on Reddit directly to see if there's a fix or a mitigation we can implement.

Sometimes, when upgrading or migrating systems, there are differences in the repositories of the versions that aren't one-to-one replaceable. For example, there are significant differences in the repositories from version 7 to 8. We needed to upgrade Red Hat Enterprise Linux from version 7 to 8 because it had reached the end of its life. A Postgres database was running on it that used a Red Hat Enterprise Linux 7 package, allowing some database or reporting features. When I upgraded to Red Hat Enterprise Linux 8, it was not in the repository. I needed to install it with some workaround. Of course, it was installed with some minor incompatible dependencies. 

I have mixed feelings about the built-in security features. SELinux must be configured correctly for the port and directory, or applications won't run, so we primarily disable it. Sometimes, we enable it and tinker with legacy systems deployed long before I joined the company. However, chances are it will break something if you enable it. 

We have been using RHEL for three years.

Red Hat Enterprise Linux has performed very well for our business-critical applications, with minimal downtime.

We don't need to dynamically scale our application because of our workloads, as we mostly use Red Hat Enterprise Linux for our internal tools. We don't have much demand to scale out.  Containerization lets you quickly scale out your application with some bots if your hardware supports it, and you have enough resources. 

In VMs, we didn't need to dynamically hot plug some service to compensate for the load. It would be vertical scaling by adding more resources. Sometimes, we need to do that for databases that consume a lot of memory, CPU, power, etc.

I rate Red Hat support eight out of 10. It depends on the priority of the requests. We had to launch several P1 requests because something wasn't working in our OpenShift environment, and we were stuck. The support response was quick.

However, we were annoyed that most of the support was based in India. Sometimes, they don't know what the problem is and need to escalate it to an expert in the US or or Germany. It prolongs the ticket resolution, but once it gets to the expert, they fix the problem instantly because they know more. 

Positive

We previously used other Linux distributions with Docker. We prefer Red Hat Enterprise Linux because of its enterprise support capabilities, which open-source distributions like Debian or Ubuntu lack.

I'm unsure what the standard Red Hat Enterprise Linux license costs for one machine. We pay for premium support that guarantees a response in two hours. 

I rate Red Hat Enterprise Linux eight out of 10. If applications and package installations work correctly, I would give it an 8.5. It's a pleasing OS to work with, especially Red Hat Enterprise Linux 8 and 9, which are more polished than Red Hat Enterprise Linux 7. I briefly interacted with Red Hat Enterprise Linux 6, I'm 27, so I know I'm very young, but I know colleagues who worked with Red Hat Enterprise Linux 4, 5, and 3. 

Other open-source Linux distributions might work if they have high levels of community involvement so the community can identify and fix vulnerabilities quickly. Alma and Rocky Linux are all upstream from Red Hat Enterprise Linux. If you want to go with an open-source distribution, I will point you to Alma and Rocky because they are the one-to-one replacements from CentOS. You don't need a subscription. 

We are a big company with many customers, so we prefer a stable platform with support. You can't open a ticket for open-source distributions like Debian or Ubuntu if you have a problem, ticket. With Red Hat, you can open a ticket if you discover a bug. That's included in your support subscription. You also get regular patches, so we can show our customers we are compliant, etcetera. It's a no-brainer to use an enterprise distribution with support instead of something open source where you don't have a support subscription.

When I worked for an MSP, we had a lot of requirements for Linux servers. Any customer services that were deemed to be on Linux were on Red Hat 6 or 7. In fact, a good forty percent of our estate was on Red Hat 6 or 7.

Red Hat Enterprise Linux's built-in security features simplify risk management. The operating system is very secure, and we used tools like Puppet to further limit and lock down access with configuration files from a central location. This made Red Hat Enterprise Linux both more secure and easier to configure. The fact that Red Hat Enterprise Linux is open source means that there are a wide variety of tools available to help with security, and the lack of a user interface for some of these tools makes them even more secure.

Maintaining compliance is easy. We used another tool called Spacewalk to deploy patches and update RPMs. It was very easy to connect to a repository. We didn't have any problems with that either.

The portability of applications and containers built on Red Hat Enterprise Linux is beneficial for keeping our organization agile. Red Hat Enterprise Linux is a lightweight operating system that can be deployed on a variety of hardware platforms, from small clusters to large industrial servers. This allows us to easily move applications and containers between different environments, which makes it easier to scale our infrastructure and respond to changing business needs.

Red Hat Enterprise Linux has helped improve our organization's efficiency by allowing employees to use a leave service to work remotely. One of the benefits of using Red Hat Enterprise Linux and other Linux distributions is that they are more stable and less likely to break than Windows. This makes it possible to automate many tasks, such as patching, which can save time and money. In contrast, Windows is more prone to errors and requires more manual intervention. As a result, Red Hat Enterprise Linux has been a valuable tool for our organization.

The time to value with Red Hat Enterprise Linux was quick. It took us only a few months to half a year to realize that we didn't have to do so much tweaking with it. We could just let it run and do its own thing, configuring it once at most, and then leave it alone.

Red Hat enables us to achieve security standards and certifications.

Red Hat Enterprise Linux helps us build with confidence and ensures availability across physical, virtual, and cloud infrastructures. We use PuTTY to connect to them. All of our SSH connectivity was locked down to be only from jump servers, so none of it was public-facing. This was a clustered approach, where users had to first connect to a Windows server and then use SSH or PuTTY to connect to the Red Hat Enterprise Linux server.

The ability to automate security configurations is very beneficial. Once we set it up, it can do its job very well without any further input from us. We found it easy to set up and configure, and it has made our lives a lot easier.

Red Hat Enterprise Linux helps to implement and manage security best practices with reduced overhead.

Red Hat Enterprise Linux has made our lives a lot easier. It is one of those tools like Terraform that takes a lot of the time constraints away from us. This is because we can leave it to do its own thing, and we know that it will do what it is meant to do properly. I think this is because Red Hat Enterprise Linux is lightweight and has a single purpose. As a result, it only needs to be concerned with that purpose. For example, we only have one role for that server, and we are happy and content knowing that it will perform that role.

Red Hat Enterprise Linux is lightweight and can be run on almost anything. It is a valuable product because it can do its job almost perfectly even with limited resources.

Although the price is reasonable, there is room for improvement in order to stand out from other open source solutions.

I am currently using Red Hat Enterprise Linux.

The stability of Red Hat Enterprise Linux is extremely good. Red Hat Enterprise Linux is lightweight, so it does not consume a lot of resources. It can handle a variety of workloads, and we have never had any problems with servers crashing or other issues. The software is also easy to set up and configure, and it runs smoothly once it is up and running.

The system's scalability is good. We deployed it across multiple locations, departments, and other areas. I give scalability a nine out of ten.

The support team is very helpful and knowledgeable about the product. They knew what they were doing and were able to resolve any issues I had very quickly.

Positive

We previously used CentOS. We still have Windows servers, and they can be a bit of a headache. However, we have since moved from CentOS to Route 6 and 7, and we found that this improved things a bit.

We switched because we had a better partnership with Red Hat themselves.

The initial setup is straightforward. We used Terraform to make it even simpler, but I don't think it was complex, to begin with. Deployment for one server takes a couple of hours. If we're just looking at a single server, or if we're building out a small cluster, deployment may take a day or two.

From a technical user perspective, we have seen a return on investment in terms of efficiency. This is because we can now set up a server and let it do what it needs to do without having to babysit it with patching, updates, and upgrades. This frees up time for engineers to work on other tasks, such as developing new features or fixing bugs.

The price is reasonable. I think it's a good value for what it is. It's not overpriced or extortionate. If it's something that's right for our environment, our infrastructure, and other factors, I think it's definitely worth considering. I don't think the price is a major concern.

I give Red Hat Enterprise Linux an eight out of ten.

I think open source software is generally cheaper than Red Hat. However, I don't think that cheaper software is always better. And I don't think that Red Hat is necessarily better than open source just because it costs more. It really depends on our specific needs. If we're comparing Red Hat to an open source equivalent, I would say that Red Hat would probably be a better fit for us. This is because Red Hat offers support, a back-end, and a team of experts who can help us if we need it. With open-source software, we're often on our own and have to figure issues out on our own. With Red Hat, we have the peace of mind of knowing that we can get help if we need it.

We have Red Hat Enterprise Linux deployed across multiple contracts and multiple data centers. It was not on the cloud; it was all on-premises. However, we were able to deploy it across multiple data centers, multiple customers, and multiple departments. This flexibility was a major advantage.

We used Red Hat Enterprise Linux to patch and update the system, including drivers, the OS itself, and security updates. We also monitored disk space usage and swap usage, but this was not too time-consuming. We had a team of three or four people to rotate tasks, so no one person was stuck on the same thing all the time.

Red Hat Enterprise Linux is a good product. It has a good ecosystem and support. It is lightweight and does what we need it to do. It is a good alternative to Windows for lightweight containers or servers. It is also good for specific roles.

The operating system is a great way to learn about Linux. While some people will always choose Windows, it is not always the best answer. Red Hat Enterprise Linux is more stable and less resource-intensive than Windows, and it is also more trustworthy. This makes it a good choice for environments where reliability and security are important.

We use Red Hat Enterprise Linux as an infrastructure support operating system across both x86 and s390 platforms. Specifically, we are running it on x86 Intel and Linux s390 mainframe on Zynq.

Red Hat Enterprise Linux is a stable operating system. We recently upgraded the majority of our systems from Red Hat Enterprise Linux 7 to Red Hat Enterprise Linux 8. We were able to automate most of the upgrade process and did not encounter any major issues. As a result, we were able to bring our systems up to date quickly and easily. This is a major advantage of using Red Hat Enterprise Linux.

From an automation standpoint, we have been able to automate some of our patching workflows. This has definitely saved us time and money.

From a security and compliance standpoint, it is easy to maintain compliance. This is mostly accomplished by patching Red Hat Enterprise Linux on a frequent basis. The availability of security patches is also quick, which allows us to keep up with our client requirements quickly. Red Hat usually does a good job of making fixes available in a timely fashion, so we can remediate high-priority issues when they arise.

From a containerization standpoint, Docker and Podman now give us the ability to move workloads and structures around with little effort. It is very flexible and consistent, and the results also provide us with a stepping stone as we move towards an orchestration platform like OpenShift. Our ability to run Podman on servers and then migrate those Podman deployments to OpenShift is very beneficial.

The most valuable features are ease of support and the ability to run a read-only course on the operating system.

Red Hat Enterprise Linux is easy to maintain. We currently use Red Hat Enterprise Linux 7 with Docker for containerization. With Red Hat Enterprise Linux 8, we are moving to Podman, which is a native container runtime that is part of the operating system. 

I suggest that Red Hat move to a continuous delivery model instead of major releases. I know that this is a trend for many middleware products. We do not have a major release network. We only have monthly or quarterly roll-on releases on our continuous delivery model, which reduces the impact of a major version. This would probably be the easiest change to make.

The technical support has room for improvement.

I have been using Red Hat Enterprise Linux for two years.

Red Hat Enterprise Linux is stable.

Since we run a number of hypervisors for all of our real systems, I believe that a lot of the scalability comes from a level higher than the operating system. However, Red Hat Enterprise Linux can accommodate these tools.

Red Hat support could be improved, and they should have a better relationship with IBM and VMware. This is because a lot of what we do involves working with IBM, both from a hardware standpoint and from a hypervisor standpoint. We have a long history with IBM, and we are now starting to work more with Red Hat on OpenShift private cloud solutions and other tooling. However, Red Hat and IBM are not on the same page. They are still very different companies, and they don't always know what the other one is doing. This can lead to contradictory information, inaccurate information, and frustration for customers. I think there is a relationship between Red Hat and IBM that could be improved. If Red Hat and IBM could work together more effectively, it would put customers at ease and make them more confident that they could get the work done. It would also help IBM and Red Hat to better understand each other's products and services, which would lead to better customer support.

For example, we recently had an incident that started as a severity two on the scaling. A number of our account representatives called and emailed us, saying, "Hey, we wanted to let you know that you have an open case. We need some help with this." The incident was not a production outage, but it was preventing us from doing something, so there was an indirect production impact. After about ninety minutes of back-and-forth communication, we were told, "Okay, go ahead and bump it up to severity one. That should get traction." We did not hear from anyone for four hours. This does not happen every time, but in this case, it needed to be dealt with well before four hours. It made things more difficult than they needed to be. Sometimes the support is an eight out of ten, and sometimes it is a four.

The end result was still good because they acknowledged what happened and got everyone together to resolve it but it was not done in an efficient way.

Neutral

The initial setup of Red Hat Enterprise Linux is very straightforward. It is not much different from any other Linux operating system. Most of the things we need to consider when deploying Linux are relatively standard. Therefore, Red Hat Enterprise Linux is easy to deploy and maintain. If we know how to administer Linux operationally, then Red Hat Enterprise Linux should be easy to deploy.

I do not know enough to give a comprehensive answer, but other operating systems are in use at my company because they have more favorable licensing terms. This is a major factor in why we do not use Red Hat Enterprise Linux everywhere.

We evaluated SUSE Linux Enterprise and a few others. Depending on the computing platform, it is sometimes better and sometimes not. For some of our environments that are running on s390, SUSE Linux Enterprise gives us a better price point. However, for some of our other environments, such as x86 on VMware, it is more valuable. It is a better financial move for us in those cases. Therefore, the value of SUSE Linux Enterprise changes depending on the computing architecture.

I give Red Hat Enterprise Linux a ten out of ten.

We have a requirement to have a Linux operating system.

I'm not sure how our developers are building their images. I believe they use some desk start products.

We use SUSE Linux Enterprise for Linux on the mainframe. In a particular enclave, we have some government contracts where we use Red Hat Enterprise Linux for a number of reasons, including licensing for hosts. These hosts are hosted with OpenShift. We use Red Hat Enterprise Linux for all our Bastion hosts and OLS for our other hosts.

The Red Hat knowledge base is generally an eight or nine out of ten, but it can be difficult to get the information we need. The initial level of support is a six or seven, but it improves as we escalate the issue.

We use a combination of Red Hat and Oracle Linux in different parts of the organization. We have a cluster, where RHEL is running. The instances are both virtualized and real, depending on which part of the cluster you're utilizing. They are set up as either RAC or single instance, depending on what we are trying to achieve in terms of performance.

We have PeopleSoft systems that are all deployed on Red Hat. We also use it for deploying simple websites. PostgreSQL is running on the systems, along with a frontend that was created by the developers. We also use it for DNS fallback authentication.

We have quite a few Windows systems, as well, and some of the applications that we used to run on Linux have now been migrated to Windows.

We have a mixed environment, although, in the cluster, our deployment is primarily on-premises. There are some deployments into different cloud providers, depending on the service that we're looking for. However, when we head into the cloud, we tend to go to Product as a Service rather than Infrastructure as a Service or the like. This means that we're less concerned about the underlying operating system and we try to avoid interacting with it as much as possible. So, it is just virtualization in this case.

We rely on RHEL for stability, control, and reliable updates. There may be other Linux variants that work as well or better but we're quite happy with this solution.

We try very hard to ensure that everything is working irrespective of what it's running on, in terms of the operating system and middleware, including what database is running. RHEL helps maintain consistency of application and user experience, regardless of the underlying infrastructure, simply by not being part of the problem.

RHEL enables us to deploy applications across bare metal servers and virtualized environments, and it's an area where everything seems to be working okay. It is reliable and there is nothing that is causing us grief at the moment. The only ones causing us trouble are the applications that we're customizing, although that is nothing at the operating system level.

You can set up the security services quite quickly, which we found very useful in our context because we're a highly public organization and we need to ensure that we've got things patched as quickly as possible.

This is a very robust product that doesn't require a lot of handling. It just works. It doesn't really matter whether we've got Apache components on it or anything else. It'll run.

We have used RHEL's monitoring tools, albeit very rarely. The last time we used this feature, we were trying to track down a problem with one of our LDAP services and we were not getting any useful response back from support for that service. Ultimately, we were able to track the issue to a particular character in a user's surname.

There is nothing to work on in terms of speed and performance.

We started using Red Hat Linux approximately 15 years ago.

Overall, the stability is very good.

The most recent stuff that's been a little bit kinky was in the release of version 8. They were looking to change things around with how the product is built, so it just took us a while before we started using it.

I think we waited until version 8.1 was out and then we were fine. It was a case of us letting that version settle a little bit, as opposed to version 6 and version 7, which we went straight to once released.

Scalability-wise, it suits the needs of our organization and we haven't tried to do anything more than that. When we had multinode, Oracle RAC systems, we had a four-node RAC, each of them had four CPUs and 64 gigs of RAM, and they were all running one database. Performance was not an issue with the database.

This is one of those systems that people can use without knowing it, in a web context. Pretty much all of our research staff and students are using it, at least to a degree, even if it's just for storage management. From their perspective, if you ask them what they're using then it's just a Windows share, but in reality, it's RHEL. There are between 30,000 and 50,000 users in this category, and the majority of them wouldn't even know it was Red Hat.

We've got a fairly straightforward Red Hat implementation but the users do a variety of jobs. Some of the work that we do is implementation integration, so there are no specific users per see. It's just about migrating data and files, depending on what we need. The people that use it in this capacity are academic staff, finance staff, libraries, IT staff, students, and researchers. It is also used by systems engineers, senior systems engineers, the senior security person, my manager, and his boss. There is also a deputy director and the director.

We're probably not going to increase our usage by any level of significance. At the same time, we're probably not going to decrease in any great rush either. We're in a phase where we're looking at what can be put into cloud systems, and we are targeting Product as a Service in that space rather than infrastructure.

Essentially, we're looking to move away from managing operating systems when we put stuff in the cloud, but we still have hundreds of servers, just in one of our locations. The majority of them have no plans to move at this stage, so our installed base is fairly stable.

Primarily, we haven't had to use technical support and I can't recall the last time we actually had to log a call with them. It's a really good situation to be in.

It's an interesting situation because we use Oracle Enterprise Linux primarily. It is really not very different from RHEL because it's just recompiled and they resend it. We use RHEL on one of our clusters, which has about 300 nodes in it and is used in research. In short, we use both Oracle Linux and Red Hat Linux, but the reality is that nothing much is different between the two of them.

We initially implemented Red Hat and we consolidated everything to Oracle Linux because it was cheaper from a support standpoint. That was when Red Hat Enterprise Linux version 4 was out. I think that version 5 had only just been released and we switched to Oracle, which is the same thing anyway.

The last time the research cluster was updated, it switched from the IRIX operating system to Red Hat on HP. They weren't necessarily going to implement Red Hat but we had to make sure that everything was licensed correctly, and that's how it came into play. Since it is not using our Oracle license, but it's already bought and paid for, we have not consolidated it. We could consolidate again but it doesn't make a lot of difference in terms of what we do on a day-to-day basis. It runs the same and it operates the same.

We were running version 7 of Red Hat on the cluster and we have versions 4, 5, 6, 7, and 8 running in the Oracle Linux space. The applications running on version 4 will only run on that version, and there are only two of those left. We have three instances of version 5, about 30 running on version 6. We are trying to reduce this number and we had more than 60 running on version 6 a few months ago. The fact that this is going down is nice.

Versions 7 and 8 are still supported, so the specific version is not a concern.

Prior to using Linux, we used Digital's TruCluster. However, after Digital was bought by HP, they discontinued the product.

The initial setup was fairly straightforward. We put in the satellite server and then ran the config on each of the nodes to tell them where it was. After that, the updates were happening and there wasn't anything else to be done.

We did not use a formal approach for our implementation and deployment. It was probably more haphazard than structured.

We implemented it in-house.

We have four people that support it, although they do not work on it full-time. For example, the person who works on it most consistently also does work in the networking and firewall space, as well as identity management. We have more support staff for Windows within our environment.

The most recent change we made is a flag that had to be set on the kernel for some of the machines. Setting the flag means that you can patch it without having to reboot. This wasn't particularly problematic, although we had to make sure that it was in place because we now have patching occurring on a monthly basis.

In general, there is not much to do in terms of maintenance. The biggest drama has come from organizing upgrades to the application side that sits on top, rather than the operating system itself.

We've had some done ROI analysis over the years and it's always interesting when you read them. When you consider the initial implementation and you couple that with what we did with Oracle, we saved about $500,000 USD on purchasing all of the different parts by going with Red Hat.

This is significant as well because we still had the same capability with the hardware.

We've had similar kinds of examples thrown at us over the years, but primarily that's when comparing HP-UX and other vendor-closed products.

The price is something that can be improved, as they are still being undercut.

We are an educational institution and as such, what we pay is less than the average company. There are no costs in addition to the standard licensing fees.

Red Hat's single subscription and install repository for all types of systems is something that we're quite interested in because it's simpler and easy to manage hundreds of virtual machines. However, from a pricing standpoint, it's part of the problem because it's what Red Hat utilizes to explain why they cost more.

The Oracle licensing of support for the same Red Hat product is cheaper, and it's cheaper to the level of significance that it makes it worthwhile. We have spoken with the salespeople at Red Hat about it, and they have said that there was nothing they could do.

It's starting to become a question mark over the patching with version eight. We might be changing, but we're unlikely to be changing from Red Hat. It's more a case of who's running our support, be it Oracle or Red Hat. However, we would need to look at the numbers next time we renew, which is not until next year.

Prior to choosing RHEL, we looked at a number of different things. We conducted a fairly large scan of product offerings and our analysis included cost, availability, and support. It took us about three months to go through the process and Red Hat was successful.

The fact that Red Hat is open-source was a consideration, but it wasn't necessarily a winning ticket at the time. We came from a closed source product that we were very happy with but when we were looking at the alternative closed source options, none of them were even close in terms of product offering. Also, they were actually more expensive. So, when looking at the open-source with support opportunity that we were presented with from Red Hat, it was very much a cheaper option that also brought with it a lot of reliability. That is why we chose it.

RHEL provides features that help to speed deployment, although we don't use their tools. We use tools from a third party.

My advice for anybody who is looking into implementing RHEL is to make sure that it is going to work for you. Ensure that it supports all of the products that you need it to support once you've actually assessed all of those things. It is a quality product, there's no doubt about that. Once you have made that assessment, I would say, "Great, go for it."

In summary, this is one of the products that works well and does what we need.

I would rate this solution a nine out of ten.

Most of the applications I work with, including our primary enterprise-level application, necessitate the robust capabilities of an enterprise-grade operating system. Therefore, we utilize Red Hat Enterprise Linux to ensure optimal performance and stability for these demanding applications.

Red Hat Enterprise Linux is praised for its exceptionally precise documentation, which greatly aids in the learning and implementation process. Troubleshooting is straightforward, and solutions to any arising issues are readily available through a simple Google search.

For provisioning Red Hat Enterprise Linux, tools like Terraform and Ansible are commonly used to automate the process on a base machine. While Terraform handles various provisioning tasks, Red Hat provides its software for patching, although OpenSCAP is also a strong alternative for effective patch management.

Our organization uses Red Hat Insights, leveraging its user-friendly single dashboard to monitor all aspects of our systems. This centralized platform has proven invaluable for maintaining an overview of our infrastructure and ensuring operational efficiency.

We often use the Red Hat Enterprise Linux web console for things like viewing system performance and logs, managing user accounts, and configuring network settings.

Red Hat Enterprise Linux is robust, stable, and well-documented compared to the open-source versions of Linux.

I find the most valuable aspect of Red Hat Enterprise Linux to be its ease of customization. The operating system allows for the simple addition of kernels, modules, and other applications, making it highly adaptable to various needs.

Red Hat has several areas ripe for improvement. In the Asia Pacific region, where cost-optimization is highly valued, Red Hat's support and subscription costs are perceived as high and could be reduced. While their security documentation is comprehensive, some solutions lack open-source availability or training resources, unlike platforms such as Ubuntu. Furthermore, the quality of documentation and training sessions, particularly for OpenShift, could be enhanced. Addressing these issues would strengthen Red Hat's offerings and better serve its customers.

I have been using Red Hat Enterprise Linux for about nine to ten years.

Red Hat Enterprise Linux is extremely stable.

When Red Hat is involved in virtualization or OpenStack, moving from one virtualization platform to another becomes easier. However, when scalability is needed, it depends on the underlying infrastructure security, which is part of Red Hat import.

Communication quality is very good. I find very helpful people in the support section, and the Red Hat portal is robust for main solutions and support. When I receive support, I often find very interesting solutions.

Positive

I previously used CentOS, Ubuntu, and Debian, among other Linux distributions. However, with the growing popularity of containerization technologies like Kubernetes and Docker, solutions like Red Hat OpenShift are becoming increasingly common, particularly in regions like Bangladesh, India, and the Asia Pacific. That is why we are using Enterprise Linux.

The initial deployment and migration of Red Hat Enterprise Linux are straightforward, particularly for cloud-based solutions. However, on-premises migrations present a slight challenge due to the complexities of CVS solutions and potential application compatibility issues. This can involve numerous parameters that require careful consideration. My lack of experience with Red Hat's migration tools may have also contributed to the perceived difficulty.

Red Hat could gain a competitive advantage in the Asia Pacific region by adjusting its pricing strategy. Lowering the cost of enterprise-level offerings could attract organizations seeking operating systems or Kubernetes solutions, as these tools are essential for many businesses in the region. This adjustment would make Red Hat a more appealing choice compared to competitors with potentially higher pricing.

I have not found another operating system that matches Red Hat Enterprise Linux; it receives a perfect score of ten out of ten.

The Red Hat Enterprise Linux upgrade process is generally smooth. However, patching occasionally causes issues, typically due to application incompatibility or bugs in the updated packages. This necessitates restoring from a backup to maintain functionality. While this is a recurring problem, the infrastructure itself remains stable throughout the process.