Red Hat Enterprise Linux (RHEL) Reviews

I set up Red Hat Enterprise Linux (RHEL) for my customers. The customers either install some middleware on top of it or manage it directly from my company, or the customer will manage the application on top of the server directly.

The most valuable feature is the support. The support from Red Hat is definitely valuable. Having a Technical Account Manager facilitates getting to the core of the issue and eventually tries to correct the behavior of the operating system in case something is not fitting what I expect.

The knowledge base offered by Red Hat Enterprise Linux (RHEL) is definitely good. Most of the simple issues can be fixed by going through it, including sometimes third-party issues that happen. I can mention a couple of incidents that occurred, one with CrowdStrike and one with Qualys Cloud Agent. In both cases, the knowledge base was informative about the existing issues. If I was a customer of those partners, then I would have been affected by problems that came from third-party products. Generally speaking, the knowledge base is absolutely good for problems that come from Red Hat itself.

The most important security feature in Red Hat Enterprise Linux (RHEL) is the readability and detail of the security report. From a security perspective itself, it is not a game-changer, but when it comes to communicating to the customer that something is not an issue, this is beneficial because I can reference an article that is easily readable by the customer.

Red Hat Insights is definitely helpful, providing information that I would not spot otherwise. However, there is room for improvement. Red Hat Insights needs to be able to manage in a detached environment, which is on the roadmap as far as I know, because we are working with big banks, and therefore, we cannot have too much direct connection, especially from the cloud to the server. Another open point is that from Red Hat Insights, I cannot make use of my own Ansible Automation Platform, unless I'm mistaken. 

Red Hat Enterprise Linux (RHEL) is derived from Fedora. Sometimes, we encounter features in a server environment that are more suitable for desktops, leading to unexpected complications. For instance, networking on a desktop is typically designed with different priorities compared to a server. We often find ourselves forced to use features originally intended for desktop use, even when simpler alternatives would be more effective and manageable. This complexity can be unnecessary, as it adds layers of functionality that do not provide any real value. Ultimately, users should be able to manage their connections without being overwhelmed by features that are irrelevant to their needs.

A downside is that it is sometimes difficult to agree on product modifications. For instance, one issue we encountered was that certain commands were not responding as we expected. Another example, which might be easier to understand, is during upgrades when certain directories are reverted to their original permission settings. This contradicts some hardening recommendations and makes it more difficult to advocate for a change to practices that have been in place for a decade, even when there are valid reasons for the change. It’s important to note that the resistance to change can be attributed to their collaboration with upstream developers, but that’s just our perspective.

I have been working with Red Hat Enterprise Linux (RHEL) for more than 12 years.

It is definitely a stable product. As I shared previously, my main concern is about desktop components that are coming into the newest release. If RHEL 6 was definitely a 10 out of 10, now with RHEL 9, I would rate it a 7 out of 10 because it no longer allows me to have a clear understanding of what is going on and a clear configuration that speaks for itself. The shift towards configuration as code has some drawbacks in this case.

With a Technical Account Manager, we have a very individual approach. I would rate the technical support from Red Hat a ten out of ten.

The support has had a positive impact. I was able to go through a huge incident that required getting to the core of the problem, such as what happened with CrowdStrike. It involved an issue perceived on the LDAP server caused by a change performed in the code of Red Hat. My feedback is that the support is always great when addressing complex analysis, and that's the most important value-added aspect I will mention.

I used different solutions before Red Hat Enterprise Linux (RHEL), but not from an enterprise perspective, so without support. I used Debian and Slackware and other similar solutions. I decided to switch mainly because of the support. 

When I switched from my previous job to my current job, they were already using Red Hat Enterprise Linux (RHEL). I am working with banks, which are highly regulated, and I need backend support from the vendor in order to work with the bank.

We have seen a return on investment from Red Hat Enterprise Linux (RHEL) so far. I don't have any specific metrics, but the penalty we would have faced if Red Hat had not helped us in identifying the problem would have been millions of euros.

Red Hat helps to mitigate downtime and lower risks through support, engaging them at the right time to promptly resolve issues. Red Hat Insights also assists in this regard.

I'm the one who's managing that. I find the pricing of Red Hat Enterprise Linux (RHEL) affordable, but the subscription model is something that the business units of Red Hat need to revisit and fix.

I participated in a review to eventually switch to SUSE and to Oracle Linux as well. Oracle Linux is a definitive no, mainly because of the support. The support from Oracle's side is awful. I don't want to ever have a case with them because it's terrible. For SUSE, it was mainly a matter of cost-benefit since we didn't have the chance to go into depth on that because the cost was not a game-changer, and we would have had to reinstall the whole 7,000 servers, so it was too much to get the benefit from the reduced cost.

I would rate Red Hat Enterprise Linux (RHEL) a nine out of ten.

Red Hat Enterprise Linux (RHEL) serves multiple purposes in our enterprise environment. It's used for running containerized workloads, third-party software, and tons of automation. RHEL predominately runs critical production systems because its versatility makes it suitable for various enterprise workloads.

One feature of Red Hat Enterprise Linux (RHEL) that is most valuable is its sophisticated update strategy. The system allows for staged updates rather than requiring all changes to be implemented simultaneously. This approach is crucial for maintaining system stability, ensuring that packages remain compatible during upgrades, and preventing software failures during operating system updates.

The security benefits RHEL provides are particularly significant to most customers. There's a reassuring confidence that comes with Red Hat's support and commitment to system security. What sets RHEL apart is Red Hat's proactive approach to handling vulnerabilities - they not only identify security issues but also provide clear solutions and upgrade paths. This level of support and accountability is unique compared to other operating systems, where such comprehensive security guidance isn't always available. Additionally, RHEL's robust security architecture results in fewer vulnerabilities overall, making it a more reliable choice.

From a technical standpoint, Red Hat Enterprise Linux (RHEL) performs exceptionally well - it's reliable, straightforward, and functions as intended. The only significant concern isn't about the product itself but rather its pricing structure. Red Hat's recent changes to their pricing model have prompted some customers to question the cost and explore potential alternatives. While I can't speak to the business aspects, the feedback I've received consistently indicates that cost is the only notable concern. The product itself meets or exceeds expectations; it's purely the financial aspect that has raised discussion among users.

Red Hat Enterprise Linux (RHEL) is the industry standard operating system for businesses. Based on my experience across multiple companies, RHEL is widely adopted because of its long-standing reputation for stability, security, and reliability. Most choose RHEL specifically for those three reasons.

What can I say? Red Hat Enterprise Linux (RHEL) just works. The system consistently performs as expected, and on the rare occasions when issues arise, Red Hat's response is swift and effective in both identifying and resolving problems. This reliability stands in stark contrast to other operating systems like Windows, which has experienced high-profile failures - such as airport system outages - due to problematic updates. RHEL's track record of stable performance and minimal disruption makes it a trustworthy platform for critical operations.

Red Hat Enterprise Linux (RHEL)'s scalability is effectively enhanced by the cloud infrastructure running it rather than RHEL itself, but the operating system works seamlessly in the cloud. When additional capacity is needed, new RHEL instances can be automatically provisioned to meet demand. The combination of RHEL's reliability and regular updates, along with cloud platform flexibility, ensures customers can confidently scale their operations as needed.

I would evaluate the customer service and technical support of Red Hat Enterprise Linux (RHEL) as great. I am a former Red Hatter, so I might be a little skewed. But when I talk with customers, they love it. That is never a concern. 

Security requirements were a primary consideration when choosing Red Hat Enterprise Linux (RHEL) for the cloud. We have Amazon Linux as. Red Hat is often the requirement, so we have to follow this path.

For many customers, security requirements drive them to choose Red Hat Enterprise Linux (RHEL). For example, while Amazon Linux on AWS is an available option, security policies and third-party software often specifically require RHEL. This compliance requirement effectively determines the path, making RHEL the mandatory choice in some situations.

My management of Red Hat Enterprise Linux (RHEL) systems is streamlined through AWS Systems Manager, particularly for provisioning and patching operations. The cloud environment simplifies this process significantly, as I have access to pre-configured Amazon Machine Images (AMIs) and built-in management tools. The system's orchestration and automation capabilities handle most of the work automatically, reducing the manual intervention to mainly scheduling tasks. This cloud-based approach has greatly simplified what was traditionally a complex system administration process, making RHEL management more efficient and less labor-intensive.

The primary return on investment (ROI) from Red Hat Enterprise Linux (RHEL) comes from two key areas: robust security and reliable support. The platform's strong security features protect daily operations, while Red Hat's consistent and dependable support ensures expert assistance is available whenever needed. This combination of security and readily available support creates significant value for the investment, providing peace of mind and operational stability.

My experience with Red Hat Enterprise Linux (RHEL) has been largely positive, though there was a significant shift in their pricing structure last year. That change caused considerable discussion among customers. While I'm not familiar with all the specific details, this pricing change became a major talking point, particularly because it resulted in increased costs for many users. What's noteworthy is that customers' concerns were solely focused on the new pricing structure - never about the product's quality or performance. This pricing change led some customers to reevaluate their commitment to RHEL, purely for financial reasons rather than any technical considerations.

We only consider other solutions before or while using Red Hat Enterprise Linux (RHEL) if it is a requirement, for example, if they have to have Windows, then nothing we can do. If that is the requirement, but other than that, I think it is pretty much the default in most cases. There are other players, Amazon Linux, of course. It just depends on what the use case is and what the requirements are. That dictates which way to go. In most cases, we go with Red Hat because that is what is required.

Red Hat Enterprise Linux (RHEL) is the default operating system in many cases, but alternates are considered when requirements allow. For instance, if a system explicitly requires Windows, we have no choice but to use that instead. While other options exist, our operating system selection is primarily driven by specific use cases and requirements. Most frequently, customers implement RHEL because it's either mandated by their requirements or is the most suitable choice for their needs. Their decision-making process is straightforward: RHEL is the go-to solution unless project specifications or technical requirements specifically demand an alternative.

Regarding system updates, our approach has evolved away from traditional upgrades. Instead of updating existing instances, we follow a more modern deployment strategy: we create new instances with the desired specifications and simply decommission the old ones. This approach aligns with container methodology and works well with our automated infrastructure. The process is efficient and straightforward, eliminating the complexity of in-place upgrades.

As for rating Red Hat Enterprise Linux (RHEL), I would give it nearly a perfect 10. Its reliability is exceptional - once deployed, it runs consistently and dependably. RHEL has established itself as a trustworthy platform, similar to IBM's reputation in the mainframe world. Users can count on both the product's performance and Red Hat's ongoing support.

In my latest job, I was working with microservices where the decision was made to use Red Hat Enterprise Linux (RHEL) for its core functionalities. I played a role in setting up the OS and was responsible for the initial installation, defining pods, and network configurations.

Red Hat Enterprise Linux (RHEL) offered robust support and stability, providing full alignment with manufacturing hardware which ensured the drivers and other infrastructure were highly compatible.

The support and escalation process for Red Hat Enterprise Linux (RHEL) is excellent. It offers more stability compared to other distributions like SUSE. Red Hat's compatibility with manufacturing hardware ensures smooth operation. Their knowledge base is particularly useful for troubleshooting and training, and their built-in security and compliance features simplify risk reduction. It is a mature and improved platform for corporate functionalities.

The performance of Red Hat Enterprise Linux (RHEL) could be improved, especially under high load scenarios or when running applications involving AI. Providing support for AI in the knowledge base could be beneficial.

Red Hat Enterprise Linux (RHEL) is known for its decreased downtime and stable performance.

Red Hat Enterprise Linux (RHEL) allows for disaster recovery planning across different states to ensure synchronized performance.

Customer support for Red Hat Enterprise Linux (RHEL) is rated as a ten out of ten. From the beginning, their support has been excellent.

Positive

The setup was smoothly conducted. The feedback received indicated that the installation was seamless and without interruptions.

I was responsible for the initial configuration and setup of Red Hat Enterprise Linux (RHEL), working closely with other teams.

Though a bit expensive compared to competitors, Red Hat Enterprise Linux (RHEL) is still recommended because it works effectively and delivers value for its pricing.

The differences between Red Hat and SUSE, or Red Hat and Ubuntu, are that Red Hat is more mature and has better corporate-oriented functionalities.

I rate Red Hat Enterprise Linux (RHEL) overall as a ten since it provides the necessary resources and support.

We use Red Hat Enterprise Linux to host databases and Citrix desktops on our servers. This allows us to offer virtual desktops as a service to other companies.

We implemented Red Hat Enterprise Linux due to its widespread industry use and extensive resources for assistance. The platform's popularity ensures a seamless experience when installing applications and creating packages, as it's utilized by many and offers ample support.

Red Hat Enterprise Linux offers excellent documentation and resources, including those provided by Red Hat and the wider community. While I don't rely solely on Red Hat's websites for instructions or troubleshooting, experienced users like myself generally find ample support and clear guidance to resolve any issues.

Red Hat Enterprise Linux's widespread use in cloud and on-premises servers is its most significant benefit, providing access to various online resources and support. Furthermore, Red Hat's comprehensive collection of packages and built-in applications simplifies development, making it an easy and obvious choice for many users.

Our workflows have been seamless with our hybrid environment.

Before Red Hat support, we used CentOS without expert assistance. This meant our OS team spent significantly more time troubleshooting issues and installation failures. Implementing Red Hat has resulted in increased efficiency.

One of the most beneficial aspects of Red Hat Enterprise Linux is its performance, combined with the flexibility to install a wide range of available packages online.

Red Hat could enhance its user experience by incorporating built-in automation tools, eliminating users needing to install, set up, or configure external applications. By providing pre-installed, native automation tools within the operating system, Red Hat would streamline processes and improve user efficiency.

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

Red Hat Enterprise Linux is stable.

Red Hat Enterprise Linux is scalable.

Our organization transitioned from CentOS to Red Hat Enterprise Linux due to the enhanced security and support offered by Red Hat. The availability of online support for our OS team, combined with improved performance and rigorously tested patches, were key factors in our decision.

Upgrading Red Hat Enterprise Linux is a straightforward process that involves running a single command to update and patch all packages. However, syncing the repository to the new one is a manual step. Despite this, I haven't encountered any issues. To perform the upgrade, I synchronize our Red Hat repository with Red Hat Satellite, execute the upgrade command, and verify the package versions to confirm successful updates.

The required personnel for server upgrades depends primarily on the number of servers and the testing duration. Potential connection issues may also influence staffing needs. Based on previous patching experience, approximately five people are needed for the off-hours patching process, typically conducted between two AM and six AM.

The upgrades were done in-house. 

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

Our organization has approximately 3,000 users and operates five data centers in the United States that utilize Red Hat Enterprise Linux.

Red Hat Enterprise Linux maintenance is straightforward but necessary due to occasional unexpected spikes in CPU usage and storage capacity reaching its limit. This presents a challenge because storage and CPU load management are not fully automated, requiring manual intervention to address these issues effectively.

I recommend Red Hat Enterprise Linux to others, especially larger companies. Purchasing Red Hat support, while an added cost, saves valuable time and resources compared to extensive independent research.

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.

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?

My main use cases for Red Hat Enterprise Linux (RHEL) are extensive, but mostly we utilize it for our clients as a base operating system.Red Hat Enterprise Linux (RHEL) solves pain points related to security patching and support.Security requirements for choosing Red Hat Enterprise Linux (RHEL) in the cloud depend heavily on the client's business. For some clients, we don't have any special regulation, but for domains such as oil and gas, there are very strict security requirements that we must meet. In most of the current products, we can find the appropriate and certified product for our clients.

The features of Red Hat Enterprise Linux (RHEL) I appreciate most are centralized account management and SSO. The integration of SSO features, particularly with Azure Active Directory, benefits our organization greatly because it is very easy to grant appropriate access to the operating system.Red Hat Enterprise Linux (RHEL) has helped to mitigate downtime and lower risk.

I don't believe there are any additional features that should be included in the next release.

I have been using Red Hat Enterprise Linux (RHEL) for more than ten years.

What works well for me is that it is pretty stable over the years, and I don't face many challenges with it.I have not experienced any downtime, crashes, or performance issues.

Red Hat Enterprise Linux (RHEL) scales well with the growing needs of my organization.

I evaluate customer service and technical support as brilliant.I regard that support as pretty good.

Positive

While I sometimes use other solutions, we are not limited to Red Hat Enterprise Linux (RHEL), and for some cases, we use Canonical products. A long time ago, we used SUSE, but not recently.

I would describe my experience with deploying Red Hat Enterprise Linux (RHEL) as easy.Managing Red Hat Enterprise Linux (RHEL) systems from a central management console is a form of centralized management.I am satisfied with that centralized management console.

I have seen ROI with Red Hat Enterprise Linux (RHEL).

When selecting Red Hat Enterprise Linux (RHEL), the other solution I considered was Canonical, which is direct competition at the operating system level. However, Red Hat provides a more complete integration between the operating system and platforms.What stood out to me in my evaluation process was how easy it is to integrate Red Hat Enterprise Linux (RHEL) into the existing IT processes of our clients, which is the main driver for us as cost concerns are not my focus. Maintaining security patching and support over the long term is also crucial for enterprise clients.

I have expanded usage of Red Hat Enterprise Linux (RHEL) for myself and my clients.My advice for other organizations considering Red Hat Enterprise Linux (RHEL) is that if you are talking about long-term solutions, you need to choose a base infrastructure that is supportable for a long time.I would rate Red Hat Enterprise Linux (RHEL) overall as a nine out of ten.

I have completed RHCSA and RHCE certifications. In my day-to-day work, I mainly use Red Hat Enterprise Linux (RHEL) for basic installation of Red Hat OS, configuration, MariaDB setup, Apache setup, and cluster management.

Regarding my main use case with Red Hat Enterprise Linux (RHEL), it is an open source OS which allows us to modify the system as per our requirements. It is also secure and user-friendly.

The system is user-friendly because we can use it through both CLI and GUI interfaces, which provides flexibility, and the ability to modify the OS helps me in my daily work.

Red Hat Enterprise Linux (RHEL) has positively impacted my organization because we can check for vulnerabilities, and when we have internet access, we can directly install packages. The system provides easy access to internet resources when needed.

Red Hat Enterprise Linux (RHEL) has potential for improvement, though currently all features are working well based on my experience. Different versions have increased security measures, which is beneficial.

Regarding needed improvements for Red Hat Enterprise Linux (RHEL), increasing its cloud capabilities would be beneficial. Additionally, it would be helpful if they provided direct RPM package downloads via the Red Hat site without requiring a Red Hat subscription.

I have been using Red Hat Enterprise Linux (RHEL) for more than five to six years.

I used a different solution before Red Hat Enterprise Linux (RHEL) when I was working at SBI, where they had a Galera cluster. Sometimes servers would unexpectedly remove themselves from the cluster, which caused major issues requiring troubleshooting and node verification.

My advice to others considering Red Hat Enterprise Linux (RHEL) is that compared to Windows and Mac, Red Hat is very comfortable to use.

I currently use both Red Hat Enterprise Linux (RHEL) and CentOS as tech products.