Red Hat Enterprise Linux (RHEL) Reviews

There are numerous use cases for Red Hat Enterprise Linux (RHEL). As a UNIX professional, my first priority is creating infrastructure and upgrading the OS. The third priority is ensuring that services run continuously on the server without issues. When issues arise, I address them daily, whether they involve memory or kernel problems. My role includes ensuring customer satisfaction with Red Hat Enterprise Linux (RHEL) and our infrastructure. The main part of my job involves developing automation scripts that manage services, check server monitors, assess server performance, and monitor load. Additionally, night jobs run through scripts as part of my day-to-day activities.

The deployment process using Red Hat Enterprise Linux (RHEL) is straightforward and simple. We use Puppet automation where Puppet agents run on our Red Hat Enterprise Linux (RHEL) servers. The deployment can be completed with a one-line statement and does not require much time.

Regarding Red Hat Enterprise Linux (RHEL) features, I appreciate the MCP server, Ansible automation, and Sovrin AI. I am also interested in Kubernetes. These four features can help us solve customer issues and save significant money.

I use Identity Management, Lightspeed, and Satellite in Red Hat Enterprise Linux (RHEL) to navigate security risks. Currently, with Red Hat Enterprise Linux (RHEL) 8, we use Identity Management. As we transition to Red Hat Enterprise Linux (RHEL) 9, possibly mid-year or end-of-year, I can suggest upgrading to version 9.6 where we can use Satellite and Lightspeed. For Red Hat Enterprise Linux (RHEL) 10, we have Goose, which can help us automatically identify issues when they arise.

We use Red Hat Enterprise Linux (RHEL) image builders. Currently, whenever we need to upgrade anything, we use image builders.

Red Hat Enterprise Linux (RHEL) image builders are very helpful. We are integrating this with our Puppet, where it performs an automated run. When executed, it automatically calls the image builder and attempts automatic installation. This integration is particularly helpful for us.

When considering improvements to Red Hat Enterprise Linux (RHEL), I see one primary area. Within your portal, if you provided more study material along with demonstrations similar to the sessions we are attending, which feature a user-friendly guide, you could incorporate this into your Red Hat console. When I want to install an agent or something else, typing in the console should provide me with clear step-by-step instructions. Throughout the years, installation steps have been available, but regarding AI agents or Ansible automation, I need to verify whether clear information exists. Including this information would be beneficial. Additionally, if you add the sessions that have occurred to your portal or another location, this would help us review them multiple times to gain better understanding. Time is limited, and many sessions occur simultaneously, making it impossible to attend everything. Making these sessions available on your website would be very helpful.

I have more than fifteen years of experience using Red Hat Enterprise Linux (RHEL).

I assess the stability and reliability of Red Hat Enterprise Linux (RHEL) as excellent. The only time we experience downtime is when the cloud provider has downtime. I have never encountered or witnessed Red Hat Enterprise Linux (RHEL) having actual downtime.

Regarding scalability with Red Hat Enterprise Linux (RHEL), there is no need to worry about scaling or availability. Red Hat Enterprise Linux (RHEL) consistently performs at the top level. You can scale up without any issues.

I rate the customer service and technical support provided by Red Hat Enterprise Linux (RHEL) as ten out of ten. It is the best. Red Hat support is the best for us. We work with others such as Puppet, Microsoft, and AWS, but Red Hat Enterprise Linux (RHEL) is always at the top.

My company was using Windows as well as Linux before Red Hat Enterprise Linux (RHEL), but Windows comprises a very small portion of our infrastructure compared to Linux. Linux has been used for a long time. Previously, we may have used UNIX, though I am not entirely certain. We have used Linux for an extended period.

My company has not considered working with solutions other than Red Hat Enterprise Linux (RHEL).

From my perspective, the biggest return on investment when using Red Hat Enterprise Linux (RHEL) is security. Once we install anything, we can be confident without worrying about potential hacking or compliance issues. Red Hat Enterprise Linux (RHEL) provides excellent security. With AI capabilities emerging, we can implement extensive automation. This can help us reduce our workload, eliminating the need to focus on day-to-day tasks and allowing us to concentrate on enhancements. This is a significant advantage of Red Hat Enterprise Linux (RHEL).

My experience with pricing, setup costs, and licensing for Red Hat Enterprise Linux (RHEL) is that our company is large, so although we face some pricing challenges, we would always be happy if pricing decreased. However, compared to other solutions, we do not perceive significant pricing challenges. From my company's sales perspective, reduced pricing would be beneficial. If not, that is acceptable because we receive better output from what we pay. I do not believe pricing is a significant concern for us regarding Red Hat Enterprise Linux (RHEL). I have no complaints about pricing.

The business value of Red Hat Enterprise Linux (RHEL) compared to Microsoft is significant. Red Hat Enterprise Linux (RHEL) is our major platform. We have approximately fourteen thousand servers running Red Hat Enterprise Linux (RHEL), whereas Windows runs on hardly two hundred to three hundred servers, with a maximum of five hundred servers.

Regarding pain points, whenever a customer contacts us, we must spend time with them, log into the server, and provide the information they need. Although we have scripts, even to run the scripts, I as the administrator must log into our servers using root and execute the script. This is time-consuming because customers contact us even for minor issues, requiring me to spend time resolving their problems. This pain point was a primary reason I attended this summit. I came here to explore whether we can implement an agent or AI agent that can address these minor issues.

My main reason for attending this summit was to understand how I can use AI in the near future with Red Hat Enterprise Linux (RHEL). Red Hat Enterprise Linux (RHEL) 8 does not have this feature. In version 9, we can use it. However, MCP is supported in version 8 as well. After learning this, I will return to install MCP on my sandbox and develop a proof of concept to assess how it can help resolve most of my issues.

Red Hat Enterprise Linux (RHEL) plays a significant role in our company's implementation of the zero-trust model. Our environment and most of our infrastructure consists of approximately fourteen thousand servers, all running Red Hat Enterprise Linux (RHEL) 8. Red Hat Enterprise Linux (RHEL) is what we use daily. We do not support much Windows because I come from a UNIX background where Linux is my daily focus. With approximately fourteen thousand servers, you can imagine the scope. We have approximately ten thousand servers in the cloud and approximately four thousand servers on-premises. This involves substantial daily work.

I have completed a major version upgrade with Red Hat Enterprise Linux (RHEL) and Ansible Automation Platform. We are currently using Ansible. As part of my migration plan, we are currently transitioning to version 8 using an Ansible script. Regarding versions 9 and 10 and the AI they are currently using, I believe I need to implement this starting with a proof of concept. That is my next target.

My overall experience with Ansible Automation Platform has been positive. As I have learned many things, I must proceed with implementing them to determine how best I can use it to make things better and faster. I will observe how it performs.

Regarding managing regulatory compliance with Red Hat Enterprise Linux (RHEL), we have a separate risk management team that checks for vulnerabilities daily. We update patches every weekend. Regarding compliance, we have zero tolerance. Because our company is a financial investment organization, we cannot accept any vulnerabilities or security risks. We check daily whether new upgrades or vulnerabilities require updating. Sometimes, we must address these overnight, so we open a change request and complete the work overnight.

Red Hat Enterprise Linux (RHEL) has helped mitigate downtime and lower risk. Regarding downtime, our infrastructure includes disaster recovery and on-premises primary servers. We maintain both disaster recovery servers with the same configuration and data. Red Hat Enterprise Linux (RHEL) helps ensure this synchronization. Synchronization and load balancer performance are stable. There is no chance of delays in data or request processing. Everything performs well. This is why our company has used Red Hat Enterprise Linux (RHEL) for the last twenty-five years. I have been here for four years, but Red Hat Enterprise Linux (RHEL) has been used for an extended period.

Red Hat Enterprise Linux (RHEL) offers an ocean of knowledge. You learn as much as needed. After seeing this summit, I now understand my current position and realize I must learn many things. The knowledge base is vast. We still have many studies and enhancements occurring, and we continue receiving new versions. We must wait for new version releases and explore and implement them. However, this is always a learning stage. You continue learning and implementing new steps and new things.

My overall rating for this review is ten out of ten.

My main use cases for Red Hat Enterprise Linux (RHEL) involve operating a number of data centers across the United States where we primarily use Linux for our SCADA platform and for telemetry collection of the data center components.

We also use RHEL for day-to-day infrastructure needs such as email, DHCP, DNS, and normal network infrastructure operations. We have also started deploying Kubernetes, but we are not doing that within the scope of OpenShift at this time; it is really just bare metal Kubernetes.

Red Hat Enterprise Linux (RHEL) solves my most significant pain points with its enterprise tooling, particularly Satellite for effective management of patching and Ansible tooling, especially for configuration management at scale. That is really where I spend most of my time, working with Ansible.

My favorite features of Red Hat Enterprise Linux (RHEL) are the RHEL-specific features, particularly the development of the bootc image process and container file process for deployment. That is really interesting and coming along. However, it is mostly the tight integration with Ansible Automation Platform and Satellite that stands out.

The feature of having a single pane of glass administration point for all systems improves my company's efficiency significantly as my scope of responsibility includes maintaining systems at about 40 data centers across the United States plus internationally. We have migrated to a place where I rarely have to touch servers individually for configuring them; I can do orchestration at scale from one place. Instead of updating 400 servers individually, I can execute one command and update them all. That is really what it is about—maximum efficiency in the time I can spend.

Red Hat Enterprise Linux (RHEL)'s winning factor for me is the support and tooling, including Ansible Automation Platform, Satellite, and decent integration with ITSM platforms such as ServiceNow right out of the box without needing to hand-code those things from scratch. It is really the interoperability that stands out.

I have tried both Red Hat Enterprise Linux (RHEL) Image Builder and System Roles, but I do not use System Roles as extensively as I would prefer because of the nature of our business, where we have acquired other companies that are not standardized on RHEL across the board. Red Hat Enterprise Linux (RHEL) System Roles cannot always be applied to non-Red Hat Enterprise Linux distributions. I am trying to incorporate that more, but I believe the bootc and the image move and image builder tools are the direction I am attempting to push us towards.

Red Hat Enterprise Linux (RHEL) System Roles have been extremely helpful, speeding my time to development of my Ansible configuration management deployment, which is a huge time saver for me. However, regarding bootc and image mode, I cannot yet comment because we are still in the testing and development stage, so it remains to be seen.

Red Hat Enterprise Linux (RHEL) has limited relevance for my AI workloads due to strict governance, though our developers are involved in that world; it is outside my scope.

I have not done a major version upgrade with Red Hat Enterprise Linux (RHEL) and Ansible Automation Platform, but we have done upgrades from RHEL 8 to RHEL 9, and that experience was positive, as we were using Leapp tools to do that prior to having AAP in the environment.

I do not have any strong recommendations for improving Red Hat Enterprise Linux (RHEL) because what matters to my organization is more about stability and consistency. New features for the sake of new features are not what I need, but if I had anything, it would be more tooling to help me respond to CVEs faster. For instance, the recent copyfile CVE has sparked discussions about adding a kill switch with certain kernel modules, which might be an interesting idea, but I worry that it could become an attack vector of its own. My primary need is not new features; it is stability while keeping things as lightweight as possible.

Red Hat Enterprise Linux (RHEL) has not been the direct cause of any downtime issues; those tend to be more related to connectivity, such as a fiber cut. It is less about mitigating downtime and more about having good stability, as generally uptime is good. Red Hat Enterprise Linux (RHEL) specifically does not get us there when downtime occurs.

Regarding the stability and reliability of Red Hat Enterprise Linux (RHEL), there is really nothing to add; it is the most stable platform we have, provided you do not let the developers get in there and make changes. The operating system and the kernel itself is never the problem.

I would rate customer service and technical support quite high, perhaps a nine or 10. On a daily basis, I rarely need to interact with technical support, but when I do, they respond very quickly. The knowledge base usually has the answers I need, unless we encounter some very unique and specific situation, which is pretty rare.

I find the knowledge base offered by Red Hat Enterprise Linux (RHEL) to be very good, highly rated, and a very useful resource. Overall, I have a positive view.

Before using Red Hat Enterprise Linux (RHEL), my company underwent multiple acquisitions, resulting in an amalgamation of different Linux distributions and Windows servers. There has been a lot of Rocky Linux, CentOS, Ubuntu, Debian, SUSE in the past; I even found an AlmaLinux box recently. We are in the process of trying to standardize on Red Hat Enterprise Linux (RHEL) as quickly as possible amidst a data center race, which involves building new facilities and acquiring smaller companies, as we deal with their existing systems until we can migrate them over.

I would describe the deployment process of Red Hat Enterprise Linux (RHEL) as very straightforward, especially with the changes we are experiencing with image mode deployments. This new approach makes it almost more straightforward because I am not having to deal with RPM packaging, and I do not necessarily have to package my own RPMs for custom deployment. I am looking forward to these changes, though deploying image mode from a registry can affect network bandwidth as it involves pulling the entire operating system rather than a small update, which could make time to deployment smaller while providing more consistency across the board.

The biggest return on investment when using Red Hat Enterprise Linux (RHEL) comes from the reduction in time spent on manual labor associated with a fractured infrastructure. By standardizing on Red Hat Enterprise Linux (RHEL) as much as possible, my day goes faster and I can use my time more effectively. This also allows us to operate with a reduced head count because we do not need to add more personnel to solve problems as things are more standardized; that is really the biggest factor for me.

It is difficult to compare the business value of Red Hat Enterprise Linux (RHEL) to other Linux distributions I have used, as I do not handle the licensing aspect. For me, the value lies in the consistency and tight integration with all the platforms, but it is hard to put a dollar amount on that.

Red Hat Enterprise Linux (RHEL) plays a role in my company's implementation of adhering to the zero trust model primarily through devices and network aspects. Most of our IAM components are still handled through Windows Active Directory, so all of our systems are domain-joined, but it is Active Directory domains as opposed to RHEL IAM, which pains me. Most day-to-day users, when you have non-engineers, are still going to be using Windows and Windows applications, so that is outside my purview.

I cannot describe my company's process for managing regulatory compliance, as it is not part of my job. There is a whole GRC team handling that. Generally, during the testing process, we ideally adhere to certain CIS benchmarks, but due to our unique requirements, those are not exactly what we need. We are sort of in the middle of CIS 1 and CIS 2 benchmarks, and I would like to be able to deploy Red Hat Enterprise Linux (RHEL) and simply apply benchmark two and have it done, but we have to build that by hand.

I would rate Red Hat Enterprise Linux (RHEL) overall as a nine. The main advice I would give others considering Red Hat Enterprise Linux (RHEL) is that your primary gains will come from standardization and having a specific plan. The problems we faced in the past arose from smaller organizations deploying a particular version of Linux based on individual preference because an engineer wanted to try something new, rather than due to stringent controls being put in place.

My main use cases revolve around managing my application, so I want to ensure there is an operating system on which I can keep it. Linux is one of the best options where I can keep my application, either containerized or running as a JBoss application or whatever else is needed. Therefore, I started with Red Hat Enterprise Linux (RHEL) 6 and have progressed to RHEL 7, RHEL 8, and RHEL 9 as of today. One of my main use cases is to ensure I run my application on an operating system, and RHEL provides the best security patches and quick fixes, and it supports a lot.

RHEL helps solve my pain points by providing patching. Security is one of the big pain points for me, especially as I work for a financial company, making it important that security is a critical thing, and RHEL solves that.

The features of RHEL that I appreciate the most include its various packages, which allow me to ensure that I can customize whatever I need and keep it in the operating system. I can discard the rest of the things that are not needed. It provides various ways, and whatever the package manager it provides and the connection to Satellite, it is a seamless process. I do not need to spend much time on that.

I think RHEL could improve by considering backward compatibility when making changes from version to version. For example, we were using OpenLDAP in RHEL 7, but when we went to RHEL 8, it was not available. I had to bring in some new systems because OpenLDAP is not a feature in RHEL 8, requiring a lot of re-engineering because of whatever new tools arise that are not backward compatible.

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

We have experienced some downtime, performance issues, or crashes with RHEL, but these are not critical impacts. Our system is designed to minimize issues. We have seen out-of-memory errors, which we monitor through kernel logs such as dmesg. We were able to tune the system effectively. Issues arise, but they are solvable. It depends on the requirements, such as what application is running on it. Fine-tuning the operating system is essential to maintain reliability, especially for containerized applications. The base image requires fine-tuning, and similarly, RHEL does.

RHEL scales well with the growing needs of my company. We used to have three hundred virtual machines, and now we have over seven thousand five hundred virtual machines in our environment across RHEL 8, RHEL 9, and RHEL 7.

I would rate customer service and technical support eight out of ten. It depends on the issue I raise. Good support is provided for Sev 1 issues, but for those of lesser severity, the response decreases. This rating also relates to the type of subscription I believe we have; with a premium subscription, we tend to receive a good response.

I do not remember using another solution prior to RHEL at my company. It has been a long time, and I do not think we were using anything else before.

The deployment process of RHEL is pretty straightforward. We have multiple strategies, including SaltStack, and we used to have Puppet; now, we utilize Ansible. We have control and manage the deployment, or we go to VMware, create the machine, and install the operating system. Everything is automated, and we have transitioned from SaltStack to Ansible, making it straightforward.

I have not done a major version upgrade with RHEL and Ansible Automation Platform, but my team has. Recently, we migrated from RHEL 7 to RHEL 8 using Ansible.

That experience was pretty straightforward. We tested it end-to-end, and then we just migrated.

From my perspective, the biggest return on investment when using RHEL is security. As a financial company, I cannot opt for an open-source operating system. I invest effort and money in RHEL 8, expecting the system to be secure and reliable when serving my clients. RHEL is definitely helpful in that regard.

I do not deal much with the pricing, setup costs, or licensing of RHEL. Most recently, I was involved in those conversations, and it seemed pretty reasonable. I do not think it is a significant issue for us.

I have not evaluated other solutions while using RHEL. We recently migrated to OpenShift. If the application is containerized, we are moving to OpenShift, so it is not that we are actually looking for any RHEL alternatives.

My thoughts on Red Hat Satellite are that it provides an easy way to pull the patches, and it has all the versions, allowing me to create the repo and just pull from Satellite to get the packages I need.

We use Amazon Web Services as our cloud provider.

I do use Red Hat Satellite.

RHEL helps solve my pain points by providing patching. Security is one of the big pain points for me, especially as I work for a financial company, making it important that security is a critical thing, and RHEL solves that.

To navigate my security risks, I use a security tool such as Wiz running on the system, which identifies if there are any CVEs associated with the systems. Whatever the CVE it had, I can get the latest. We always go back to the CVE report and see if Red Hat provided that patch or not. If it is there, we just do monthly patching.

I am not certain what role RHEL plays in my company's implementation of the zero trust model.

My company's process for managing regulatory compliance involves tying up with different companies for auditing. They ask for screenshots, versions, patching details, version numbers, and a lot of details. We take all the screenshots, document them, and send them. RHEL plays a key role in this process; without an operating system, it would not make sense to provide the audit team any compliance information.

Whether RHEL helps mitigate downtime and lower risk depends on how I configure it. I make sure I have high availability. I have high availability running on my systems and migrate the traffic as needed, especially to keep my application up and running and reliable. Keeping high availability is essential, and RHEL supports me with the versions or at least the keepalived or whatever packages it provides; we use them.

I am not completely certain which RHEL capabilities helped to mitigate downtime and lower risk at my company. An example would help me correlate. Satellite provides patches, and it helps with downtime. My system depends on Satellite. Ultimately, my packages depend upon Satellite, and it does assist us with high availability and downtime.

The knowledge base offered by RHEL is straightforward. It has been there for a while, and every version we go through its documentation, especially while doing upgrades. The support team is always there and helpful if needed. I can raise a Red Hat case if required, just a Sev 4 or Sev 5 ticket. I might get a response in a day or two, depending on the severity or the bug's nature. While documentation helps mostly, we reach out for additional support as necessary.

I would rate Red Hat Enterprise Linux (RHEL) nine out of ten overall. My advice to other companies considering RHEL is to definitely look at the support that Red Hat provides, especially regarding security patching, version upgrades, and how Red Hat listens to our needs. When I have an issue, I expect that while they cannot resolve it the same day, they will address it in the months to come. I always have faith that I will receive assistance; it just takes time. My suggestion to other customers is to trust Red Hat; they always listen to their users and take care of issues.

We use Red Hat Enterprise Linux to host web applications written in the Java programming language, along with an Apache server. We deploy applications using Red Hat Enterprise Linux for both internal and external customers. Additionally, we utilize Red Hat Linux to host our Oracle database.

It provides us with long-term stability, meaning we often don't have to reboot servers for months. This contrasts with Windows, where we typically have to reboot every week. Red Hat Enterprise Linux offers long-term stability and security, allowing for prolonged periods without reboots. Moreover, the Linux operating system is regularly patched, ensuring a secure environment. We receive timely updates from Red Hat whenever there is a new patch available.

Security requirements were significant consideration in choosing Red Hat Enterprise Linux. As a bank, security and performance are our top two priorities. We are promptly notified by Red Hat whenever any zero-day security vulnerabilities or loopholes are discovered. This allows us to quickly inform our team and make decisions on whether to apply patches immediately or to wait. We prefer not to experience any downtime during the week, so we typically wait until Saturday to perform any necessary shutdowns for patching. For some patches, Red Hat offers hot patching, which means we don't have to shut down our servers. This allows us to apply patches while the servers are still running, minimizing downtime.

Multithreaded environment is a standout feature. It enables Java to execute multiple workloads simultaneously, which speeds up processes. Instead of executing tasks sequentially, we can handle them in parallel. It allows us to deliver more code execution in the same period through parallel execution, providing real-time benefits. We can monitor our progress in real time.

Red Hat Enterprise Linux (RHEL) can be improved, particularly in the documentation side. 

I would also suggest improving performance and allowing the OS to be run on Intel and optimized for Intel as well as AMD CPUs. Improving compatibility with hardware is also important so that we can run on any hardware. 

Additionally, we would appreciate Red Hat offering a built-in monitoring solution so that we don't have to depend on third-party tools such as Dynatrace and others. Better integration with built-in solutions would increase reliability on Red Hat.

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

Red Hat Enterprise Linux has indeed helped us mitigate downtime and lower risks. We can run for months without needing to reboot, which contributes to its stability.

Red Hat Enterprise Linux (RHEL) scales efficiently with the growing needs of our company because we have a recovery time objective. We have Red Hat Enterprise Linux (RHEL) installed in our primary data center as well as in the disaster recovery data center. When we do a failover and fail back, it meets the timing that we specify.

If we run into issues, such as OS-level issues, we raise Internet tickets with the Red Hat team. We have a dedicated account manager who helps track the ticket status to ensure it is resolved within a timely manner.

I would rate them an eight out of ten because sometimes we get very experienced people. They resolve issues quickly, but sometimes we get a junior person, so there is a different level of response. They can offer a consistent level of service. Rather than mix junior and senior engineers in the same team, and just give us more senior engineers.

Positive

Our overall experience deploying Red Hat Enterprise Linux (RHEL) has been positive. However, we sometimes encounter challenges with documentation, as it may not always be up-to-date. There are occasions when our OS version is ahead of the corresponding documentation. We patch our OS, and that version may be newer than what the documentation reflects. This can lead to inconsistencies, so we often request that they refresh their documentation to ensure it is in sync with the OS. On the plus side, another benefit is that there are many online discussion forums available due to its wide usage, where we can seek answers if we encounter issues.

We operate on-premises due to regulations and compliance requirements, as we are a bank. We handle many personally identifiable sensitive information, which we cannot deploy to the cloud, so everything is hosted on our servers.

We host Red Hat Enterprise Linux (RHEL) on our servers and use VMware to virtualize them. On a single physical server, we can run three or four virtual servers. This approach enhances server utilization and allows us to manage more workloads on the same hardware.

I've participated in upgrades from version 6 to 7, 7 to 8, and 8 to 9. The only issues we encountered were related to the Samba file-sharing system, where we had to uninstall and reinstall it instead of migrating directly. This was frustrating because we expected everything to be backwards compatible. Additionally, we faced challenges when upgrading from version 6; we couldn't jump directly to version 9 and had to go through intermediate versions, which was a pain point for us. We wish we could upgrade from version 6 to 9 directly instead of having to go from 6 to 7, then 7 to 8, and finally 8 to 9.

Regarding our upgrade or migration plans, we recently migrated to version 9, which is a long-term service version. We plan to stick with version 9 for the next year or so.

The biggest return on investment when using Red Hat Enterprise Linux (RHEL) is that it's a very stable overall operating system and is really optimized for running Java-based workloads, meaning we can get more workloads done. This stability gives us a consistent performance which translates into a strong SLA service level agreement.

We receive volume licensing as part of our IBM relationship. We use many IBM servers, so we get a volume discount. We tend to go through a value-added reseller to secure that volume discount.

In India, we prefer Red Hat because it offers the industry-leading container platform, Open Shift. As a result, we are gradually transitioning away from VMware and exploring other options to better meet our needs.

I would recommend Red Hat Enterprise Linux (RHEL) if you're looking for a very stable operating system and if you happen to run Java-based workloads and you want high performance, high stability, and high availability. Red Hat Enterprise Linux (RHEL) has been around for more than 20 years, and you're looking for an excellent track record. If a bank can trust Red Hat Enterprise Linux (RHEL), I'm sure that all other industries can trust it because we require the most stable, secure platforms. 

I would rate this solution a nine out of ten.

My main use cases for Red Hat Enterprise Linux (RHEL) are desktops for scientists and for development.

The main reason that we use Red Hat Enterprise Linux (RHEL) is the fact that it is stable and thoroughly tested, so we do not experience a lot of bugs and lockups. This enables our developers to work on a more consistent basis.

The feature I appreciate the most in Red Hat Enterprise Linux (RHEL) is using NFS for network file shares, as it makes collaboration easier. This feature improves my company because we can create data shares where multiple scientists and users can collaborate and share data in one space without having to retrieve something separately, as it is already available for us.

Everything can be improved in Red Hat Enterprise Linux (RHEL). The only thing that comes to mind is perhaps the speed in which newer packages are deployed. However, that is because everything has to be thoroughly tested to maintain uptime. That is a tradeoff that you must accept. Otherwise, I have truly enjoyed using Red Hat Enterprise Linux (RHEL). Even before I used Red Hat Enterprise Linux (RHEL), I used CentOS, and I have always enjoyed it.

I have been using Red Hat Enterprise Linux (RHEL) for 23 years.

Red Hat Enterprise Linux (RHEL) has helped us mitigate downtime and lower risks because we do use Satellite.

Satellite has helped us mitigate downtime absolutely. Even with people who are using Fedora, which is more advanced and more buggy, being able to patch at will has helped us tremendously.

I have worked with everything from desktops and local desktop computers to clustered servers in terms of the scalability of the platform, and I have not had any issues. I have even run the workstation versions on server-level hardware and it has worked flawlessly.

The customer service and technical support for Red Hat Enterprise Linux (RHEL) have been phenomenal. We had one dedicated person, and he has retired, and I miss him. His name was Rick Ring, and he worked with us consistently, so he was on-site all the time. That was very helpful.

I considered Ubuntu while using Red Hat Enterprise Linux (RHEL) because we had some scientists who wanted Ubuntu because of the newer packages. However, the support for it is not as strong. Red Hat's biggest strength is their support. With Ubuntu, it is open-source community support, and you do not have someone dedicated to help you fix something. That has been the significant differentiator for us.

My experience has been that building images for us has been more of a base image then using Ansible Playbooks to configure it. Being able to build a completely configured image with the Image Builder would save us some time. That is not my decision, but I will be able to go back and tell people about it.

The biggest return on investment when using Red Hat Enterprise Linux (RHEL), from my point of view, is the stability and uptime. You are not having to spend man-hours troubleshooting or configuring something as much because the work has been put in on the back end before it was released to make sure everything is working. This has always helped us.

I have just a very little bit of experience with the pricing, the setup cost, and the licensing. A few years ago when they went to a multi-core processing model, it threw us off a little bit. However, we as a site have site licenses, so the amount of systems we have is not really an issue. The government comes up with a bunch of money up front and pays for it.

Since I am in government, we do not use any features in Red Hat Enterprise Linux (RHEL) to navigate our security risks. We have independent security standards called STIGs, which we use OpenSCAP to harden our services based on what the Department of Energy wants.

I have not tried using either Red Hat Enterprise Linux (RHEL) Image Builder or System Roles, but I was recently in the Red Hat Enterprise Linux (RHEL) 10 lab and got to experiment with it. It is very interesting.

I have not implemented Red Hat Enterprise Linux (RHEL) for AI workloads, but there are other people in my lab who are working with it. We have an entire AI department that is working on that kind of project right now. From what I have heard, the outcome of using Red Hat Enterprise Linux (RHEL) for our AI service is that it works, though I do not know much about the internals of it.

The role that Red Hat Enterprise Linux (RHEL) plays in my company's implementation of the Zero Trust model is that we actually use Active Directory, so we use SSSD in Red Hat Enterprise Linux (RHEL). We do not really use Red Hat Enterprise Linux (RHEL)'s internal identification system.

I have not done a major version upgrade with Red Hat Enterprise Linux (RHEL) and Ansible, but I have used Leapp to go from 7 to 8 and 8 to 9. That has worked very well.

My company's process for managing regulatory compliance involves getting our security stipulations down from the Feds, and Red Hat works closely with us. They have a government sector dedicated to the Department of Energy strictly to work with us and are on-site constantly. If we come up with a bug or find something new, we use something called FIPS, which is very important. When FIPS has broken something, they have put in new packages and we get a hold of them, and they come up with a fix for it, usually the next day. That has been really beneficial.

I feel that the knowledge base offered by Red Hat is helpful because I have gone on their support website for questions, such as how to resubscribe to a Satellite dish, and it is usually fairly easy to find answers on the website.

The deployment experience with Red Hat Enterprise Linux (RHEL) has been better. From version 7, which I started with way back at version 3, to versions 8 and 9 has been much easier with our Ansible Playbooks. Hopefully, I will be able to get on version 10 soon and I will try the images with that. The experience has been very positive.

My main use cases for Red Hat Enterprise Linux (RHEL) today are running application workloads, anything that we do not want in a container yet or perhaps the vendor provides a pre-built image for you, not a container image, but a pre-built application. We deploy those to our RHEL workloads or our VMs.

We use Satellite, and in Satellite, what is really cool is you can use the Insights Advisor to see which host a CVE is applicable to. We have used that in the past where a couple of zero-day, CVE level 10s have come through. We have seen what hosts those are applicable to, and it helps with the reporting and auditing.

We are using on-premise. I have a RHEL host that I actually have downloaded the image builder tools to, and then I run a shell script that runs through the pipeline because we only need one or two VMs right now. If we were to scale that, we would be using Ansible to plug in a lot more variables and output more ISO files, but that is where we stand.

I am not aware of specific pain points that we have had with other systems that RHEL specifically has helped us solve, but I can talk about tooling that we use with RHEL, such as Puppet and Ansible and how that works. Red Hat Satellite is worth mentioning because all of our RHEL systems are plugged into Red Hat Satellite, which allows us to see a lot of things from a thousand-foot overview. We can see all the systems, their compliance states, and what Puppet hosts are erroring on the Puppet runs. Satellite is our Puppet controller, so all of our hosts are registered to Satellite that way, managing our subscriptions and all of our content. We really appreciate Satellite in that regard.

The new image builder tool has been great. The main thing is being able to spit out a digest that you can say, "This is the hash of our image at this build time." You can look at a specific Git commit to see what code is all going into building this image. It is using more of the container-based workflows that have existed with Docker and container files and Podman, but it is applying those to Red Hat Enterprise Linux (RHEL) itself, which I really appreciate.

From a technical point of view, the biggest return on investment when using Red Hat Enterprise Linux (RHEL) is the integration with Satellite, along with the different integrations with automation tooling that you can do. You can plug in Puppet, you can plug in Ansible, and Satellite takes care of our package management. It has all these integrations with external systems, allowing you to manage a fleet of systems rather than one system at a time.

I wish we were using more AI. We are kind of cautious in that regard. We have one solution approved, and it is just the ChatGPT web UI, which means I cannot even use ChatGPT CodeX in my VS Code as an extension, but we are hoping to integrate more AI workloads in the future. It will help the two main Linux administrators, allowing us to get a lot more work done, and then we can focus on bigger architectural issues rather than smaller maintenance items.

I do not have a better answer for how Red Hat Enterprise Linux (RHEL) can be improved, but being so young in the industry, I am not as familiar with the long-term pain points that we might be dealing with. I am excited about the AI Insights or the RHEL Lightspeed integrations with Red Hat Enterprise Linux (RHEL) and OpenShift because I think it will help us be more efficient in remediating vulnerabilities, working through bugs, and those types of things.

I have been in my field for about five years, but that includes internship experience, and I am two years full-time employed.

We have not experienced any downtime or performance issues due to Red Hat Enterprise Linux (RHEL) itself. The only issues we have had are from the applications that are running on it or configurations that perhaps developers have implemented that are not correct.

Regarding scalability, we do not have very intensive compute Red Hat Enterprise Linux (RHEL) units. We have a lot of hosts, but they are all pretty small hosts, thinking about two CPUs and four to eight gigabytes of RAM.

I have opened a couple of support cases, and the support experts at Red Hat are extremely knowledgeable. There has not been a case that I have opened that was unable to be solved. I would rate them ten out of ten.

I have been using Red Hat Enterprise Linux (RHEL) for two years, and before that, I have been using Ubuntu and other Linux-based systems for another two years.

We have done major version upgrades from RHEL 6 to 7, 7 to 8, 8 to 9, and soon 9 to 10, all with the Leapp tool, which is sometimes a pain in the butt. It is nice because it shows you and spits out the output of everything that needs to be resolved, but sometimes resolving those things across 800 hosts is a lot of work. I have a project right now to POC Ansible Automation Platform, hoping to bring it into the organization depending on licensing costs, but those decisions are above my pay grade. Attending talks here, I have learned a lot about bootc and the RHEL image mode and how that should make upgrades a lot less painful, as instead of upgrading a host and dealing with things that can change across versions, you are just writing a new container file and updating the container image.

We do not do anything crazy as far as architecting things, and our Red Hat Enterprise Linux (RHEL) usage is pretty basic. A lot of the more complex things we do in OpenShift, and we have had RHEL for a lot longer than we have had OpenShift. Our RHEL usage is actually going down as we migrate more things to OpenShift.

We have not used the image builder inside of Satellite, but I have tried both the new and the old image builder, which is using bootc for image mode. I actually have a project that is currently focused on using that for building an image that is PCI compliant just at the boot and kickstart time. I appreciate that the image is immutable, or most directories of the image are immutable.

Red Hat Enterprise Linux (RHEL) plays pretty close to no role in our company's implementation of the zero-trust model. We do not do a lot of zero trust from the RHEL-specific side, but I could speak to a little bit more about Okta zero trust, although this is not an Okta conference; it is a RHEL conference.

I assess the knowledge base that is offered by Red Hat Enterprise Linux (RHEL) as extremely good. I extensively use the Red Hat Knowledge Base, looking through articles and documentation, and I reference it every single day. If I am not referencing something very specifically, I am asking ChatGPT to point me to the Red Hat article that I need.

I would rate Red Hat Enterprise Linux (RHEL) overall as ten out of ten. It is not about evaluating Red Hat Enterprise Linux (RHEL) itself, but about evaluating Red Hat as a company, and Red Hat as a company is very, very helpful. I can speak to our account executives and the technical professionals that are assigned to our company, and they are very willing to help all the time. They want you to succeed because if you are succeeding, then Red Hat is succeeding. It is a mutually beneficial relationship. My overall review rating for Red Hat Enterprise Linux (RHEL) is ten out of ten.

My main use case for Red Hat Enterprise Linux (RHEL) is as a server for our database servers, our middleware servers, and the application servers. Everything besides SAP falls into this category. SAP is currently running on SUSE Linux.

Red Hat Enterprise Linux (RHEL) helps me solve pain points by being a quite integrated system. Working together with Ansible and the Ansible Automation Platform, we did a lot to have a standardized platform, including consistent hardening and everything in a very good managed way.

The features of Red Hat Enterprise Linux (RHEL) I like the most are its central management, which is really good to have, including some connections to our CMDB to see what is in our inventory, what is used and so on. That is quite beneficial.

Red Hat Enterprise Linux (RHEL) can be improved by enhancing its central tools side. We use a lot of automated discovery for CMDB topics through Satellite and the facts. It would be really interesting to have a more consistent inventory already in place that we can access to pull into a CMDB because we have a highly automated approach there, and there is some room for improvement.

I have been working in this field for twenty years.

Regarding the reliability and stability of the platform, I have not experienced any downtime or crashes on Red Hat Enterprise Linux (RHEL) side. We are quite stable and do not have major issues with that.

The scalability of Red Hat Enterprise Linux (RHEL) is more based on our hypervisor level; we mainly use VMware, so the scalability is essentially at this level. We do not have any issues at the OS level itself.

The customer service and technical support of Red Hat Enterprise Linux (RHEL) is quite good. We also did some projects with the consulting of Red Hat directly to bring in the OpenShift features, and we are very happy with how they manage that. I would rate the customer service and technical support a nine out of ten.

Prior to Red Hat Enterprise Linux (RHEL), we used AIX, which was replaced. We also used HPUX, which was replaced. We still have SUSE in place for our SAP systems, which we maintain as well.

The difference between those products and Red Hat Enterprise Linux (RHEL) is that I think Red Hat Enterprise Linux (RHEL) is one of the biggest players. I am trying to find a reliable player in the market for the future. We obviously tried to pull out these niche products. AIX is now a niche product. HPUX is dying, and all those products are from the past. We had to maintain them to a certain point as the applications were there, but now we have migrated most of them to the modern platforms, which helps with reducing costs as we do not have to maintain many platforms.

The deployment process for us is straightforward; we now have a fully automated process, so that is quite easy for us.

The biggest return on investment for me when using Red Hat Enterprise Linux (RHEL), from my point of view, relates to standardization, allowing us to have fewer operating systems. We are currently using just two OS providers on Linux, which makes maintainability easier.

My experience with the pricing, setup cost, and licensing for Red Hat Enterprise Linux (RHEL) is that the pricing is acceptable for us. As a big company, I would say it is fair pricing right now. We have to observe that a lot of companies are increasing their prices significantly over the last decades, like VMware and so on. We keep a close look at that, but currently, it is acceptable pricing.

I have not considered switching from Red Hat Enterprise Linux (RHEL) at any time since purchasing it.

We use Red Hat Enterprise Linux (RHEL) on-premises.

We also use Lightspeed.

Red Hat Enterprise Linux (RHEL) has not yet helped our AI workloads. We do not have many AI workloads right now. We are having a couple of pilot projects in AWS on AWS native workloads, but it is just in a starting phase. Therefore, there is not a high demand right now in our company.

Red Hat Enterprise Linux (RHEL) plays a role in our company's implementation of the zero-trust model mainly on the workload side since we have a couple of other products around regarding network and other areas. We are using mainly server functionality from Red Hat in our current setup and not the on-top products.

We have done a major version upgrade with Red Hat Enterprise Linux (RHEL) and the Ansible Automation Platform. We have a quite good life cycle, so we are running through the life cycles each year to the new versions.

The experience has been good. We have not had any major issues. This year, we are also doing in-place upgrades. Before that, we did replacements with new machines and migrations, but since this year we are running in-place upgrades, which is quite good and causes less trouble than expected.

Our company's process for managing regulatory compliance is more related to the auditing we obviously have with NIS2 and all this in the EU. Each year, we have a couple of audits ongoing. However, the audits themselves do not really look into the Red Hat Enterprise Linux (RHEL) implementation; it is more on a higher level. We are obviously pulling reports for the audit of the hardening compliance and so on of our systems to prove that the things are implemented.

My overall experience using the Ansible Automation Platform has been quite good. We come from an infrastructure where we had a lot of managed service providers using their own automations. About five years ago, we decided to stop that and build our own automation platform. All our managed service providers have to use that. We developed that, set it up, and it is a really good success story as we now have all our automations internal. We have full responsibility for it, which works out quite well, allowing us not to change anything if we have to change a provider in the backend.

Red Hat Enterprise Linux (RHEL) has helped to mitigate downtime and lower risks at my company mainly through controlling planned downtime. This means if we are doing patching and so on, we have a good setup with our CMDB to maintain controlled patching cycles and reboot cycles over our whole environment in the agreed timeframes and windows. It does not really help to mitigate downtimes, but it makes the planning of downtimes better.

The knowledge base offered by Red Hat Enterprise Linux (RHEL) is quite good and has improved a lot. We can quickly find what we need. My team uses it a lot.

My advice to other companies considering Red Hat Enterprise Linux (RHEL) is to focus from the start on having automation in place. Do not wait too long, as it makes things much easier if we implement everything through automation from the beginning rather than doing it manually. My overall rating for this review is nine out of ten.

I am a RHCE certified and RHCSA certified professional. I use Red Hat Enterprise Linux (RHEL) to deploy the OS for node provisioning across any make of clusters. I work with the HPC cluster team and receive clusters on RHEL-based systems. Over the last seven years, I have been working with RHEL 7, RHEL 8, RHEL 9, and currently RHEL 10. I primarily work with HPC clusters.

Since creating HPC clusters is not part of my responsibilities, I focus mainly on installation, node provisioning, password management, SSH proxies, and NGINX and web server configuration.

There are several valuable features I appreciate. I can obtain any versions, software, or RPM packages easily through the subscription manager or without it. Red Hat Enterprise Linux (RHEL) is very hands-on for me and runs smoothly. It even runs on just 1 GB of RAM, which is excellent for my needs. The installation process is very easy compared to other distributions. Since I work with clusters, this simplicity is invaluable.

When comparing the installation process of Red Hat Enterprise Linux (RHEL) to other distributions, I find that a non-technical person can easily follow the prompts. The installation guides are clear and documented step-by-step. For example, the first prompt asks for language, keyboard, and installation preferences, and each step is straightforward. In contrast, Ubuntu and other distributions require creating disks and involve more complex UI elements that are not as user-friendly. Red Hat Enterprise Linux (RHEL) has a clean interface that allows even non-technical people to install the OS easily.

I have only studied from the direct books provided by Red Hat for RHCSA and RHCE certification, and every detail is available in their documentation and website. I appreciate the clean and detailed information provided in their resources.

I encounter pain points when trying to add patches for certain versions I need for RHEL purposes. While creating HPC clusters on RHEL 9, I sometimes need EPEL repositories for RHEL 7 or 8. Adding patches from these repositories is very painful because Red Hat Enterprise Linux (RHEL) 9 does not easily support these older package versions. This is a recurring problem I always face.

I have been using Red Hat Enterprise Linux (RHEL) since I started my career, which is 6.7 years.

I have not experienced stability issues. I have used multiple OEMs including HP, Dell, Exatron, and NVIDIA servers. I always prefer recommending Red Hat Enterprise Linux (RHEL) to my customers because it is very stable. I have only experienced one server crash in all my years, and that was due to an OEM issue, not Red Hat Enterprise Linux (RHEL) itself. I have never encountered data problems or server crashes from Red Hat Enterprise Linux (RHEL).

Scalability is not an issue. I can easily add more nodes to clusters. The installation is very fast, which allows me to scale quickly. I use Ansible and PXE servers to facilitate this process, and I can scale to many servers very quickly with Red Hat Enterprise Linux (RHEL).

When I was working for a customer and faced an issue while installing a package, I requested Red Hat support and they helped me resolve it.

I have raised requests in the morning around 11:00 AM and received responses within one to two hours. They ask for logs and version information, and then provide a response within approximately 30 minutes. I give Red Hat support a nine out of 10 rating. I would give a full 10 if they could push their support to be slightly faster. When someone is on-site conducting installations and encounters an issue, that person needs to wait at least one or two hours for a response. Red Hat could improve by responding a bit more quickly.

Positive

Regarding the pricing of Red Hat Enterprise Linux (RHEL) subscription, I believe the pricing is fair. The support that Red Hat provides is very good. Whenever I encounter issues, Red Hat always provides fast resolution. The pricing is justified given the quality of support offered.

I have used Ubuntu as an alternative distribution. However, I always choose Red Hat Enterprise Linux (RHEL) over every other distribution. I started my career learning from Red Hat Enterprise Linux (RHEL), which is the main reason I prefer it. Additionally, Ubuntu and other distributions have many dependencies that require adding different packages and configurations. When troubleshooting on Red Hat Enterprise Linux (RHEL), I find solutions easily. With Ubuntu, troubleshooting requires digging much deeper.

I have been working with Red Hat Enterprise Linux (RHEL) for approximately seven years.

Regarding updates and maintenance, I only need maintenance time when upgrading the OS. When upgrading the kernel version or transitioning from RHEL 8 to RHEL 9, I only need to install the RPMs and reboot the server once. Maintenance primarily involves patching and the subsequent reboot requirement.

Every time a cluster issue occurs, Red Hat never requests high downtime or suggests data loss scenarios. They maintain very low risk and require very low downtime. 

I have been using Red Hat Enterprise Linux (RHEL) regularly in my current role since 2021, and I leverage RHEL for our daily Linux administrator administration tasks, orchestration tasks, patching, monitoring, and self-healing, while ensuring compliance with all security standards. From a product perspective, RHEL's robustness allows us to use Ansible, Jenkins, and ArgoCD to optimize our CI/CD processes, and we manage more than 50 clusters across five regions: Amer, Paris, Hong Kong, North Singapore, ensuring all deployments are secure. It is reliable and offers enterprise support, making it suitable for scaling workloads in both on-prem and cloud environments.

I have been using Red Hat Enterprise Linux (RHEL) on a daily basis as a foundation for my DevOps and Kubernetes infrastructure tasks, where it stands out as a primary tool for managing clusters. I regularly monitor system administration tasks such as patching, performing OS level troubleshooting on RHEL servers, and executing kernel updates on a monthly cycle, all while leveraging automation using Ansible. For monitoring, we utilize Prometheus, Grafana, and Kibana to visualize performance metrics, health checks, and set up alerts for CPU, memory, and disk usage on RHEL nodes. Regarding container orchestration on Kubernetes, we are responsible for deploying and maintaining workload shifts on OpenShift and Kubernetes clusters, which are built on RHEL nodes to ensure stability and scalability. Thus, RHEL is a core VM for both Kubernetes and OpenShift, with OpenShift being the main focus to ensure our infrastructure is stable and ready for daily use.

The best features I have seen in Red Hat Enterprise Linux (RHEL) include its scalability, enterprise-grade security, and stability. It incorporates features such as SELinux, kernel live patching, and RBAC systems, making it very reliable for production environment workloads, allowing for automated cycle processes akin to Kubernetes, which can manage itself over long-term stability, demonstrating good, consistent performance along with integrated Linux support via Ansible and OpenShift. Thus, RHEL is a trustworthy platform.

Compared to other operating systems, Red Hat Enterprise Linux (RHEL) is specifically designed for production environments. It integrates tightly with OpenShift, Ansible, and other tools that others cannot deeply support. RHEL seamlessly works in hybrid cloud and container platforms, and in comparison to Windows, RHEL provides greater flexibility for containerization and DevOps-related tools, making it a more reliable option.

In Societe Generale, Red Hat Enterprise Linux (RHEL) has helped us maintain a secure environment across our container platforms through SELinux and kernel patching, which has directly lowered the risk of downtime and improved trust in the system. Notably, the ability to automate server patching and manage cluster upgrades has eliminated the need for manual intervention, significantly reducing errors and saving several hours of work. As a result, our team can focus on more innovative topics rather than repetitive tasks, leading to improved deployment times and increased reliability by around 20 to 25%. Overall, RHEL has made scaling applications in hybrid cloud environments much smoother, positively impacting my organization by providing a stable and secure platform.

By using Red Hat Enterprise Linux (RHEL), our team saves approximately 10 hours per week on routine patching and monitoring housekeeping tasks, which allows us to focus more on innovation topics. The time saved has led to improved knowledge among the team on how to create pipelines and better support application teams, thereby positively influencing delivery timelines and productivity.

Red Hat Enterprise Linux (RHEL) is stable and secure, but I think one area for improvement is that licensing should be automatically updated, particularly in multiple environments. Additionally, a faster GUI experience would save time, which would enhance usability.

From the suggestions for improvements, I would advocate for simplifying license management and providing a more efficient web console that can run RHEL faster. Furthermore, built-in tools for monitoring and automation should be made easier to grasp, as we create many dashboards using Grafana, which are much needed.

I have been working in my current field for more than four years.

I have only used Red Hat Enterprise Linux (RHEL) and did not evaluate other options, as RHEL is very stable and designed according to its lifecycle. My consistent experience with RHEL underpins its foundation for OpenShift and Kubernetes clusters, supporting critical applications without unexpected failures, especially with Ansible handling our patching, which contributes to better stability.

From an organizational perspective, Red Hat Enterprise Linux (RHEL) pricing is justified for entry-level support, especially given the long lifecycle of kernel patching. Once deployed, RHEL demonstrates smooth operations that considerably reduce long-term operational costs. Utilizing RHEL with automation saves both time and money by preventing manual patching and minimizing downtime, allowing users to focus on more valuable tasks. Despite the initial setup effort, once implemented, RHEL significantly delivers savings in both money and time through automation, resulting in smoother daily operations.

Red Hat Enterprise Linux (RHEL) exhibits high scalability, as adding more CPU, memory, and storage to a single system is seamless within my organization, enabling applications to scale easily across on-premises clusters. I could rate its scalability between 8 to 10 on a scale, as it provides enterprise-grade stability and flexibility for workload scaling in various environments, whether they consist of a few servers or thousands. The primary area needing improvement is the speed of scaling operations.

My advice for others considering Red Hat Enterprise Linux (RHEL) is to take full advantage of its automation capabilities and how the system is set up. Utilizing tools such as Ansible can save considerable time across patching, upgrades, and other administrative tasks. I recommend focusing on RHEL's scaling capabilities compared to other operating systems and highlighting the efficiency of the monitoring tools available, such as Prometheus and Grafana. Thus, I believe RHEL is an excellent choice for facilitating organizational growth and enabling smooth scaling without issues. I rate this solution 9 out of 10.

My main use cases for Red Hat Enterprise Linux (RHEL) are almost exclusively for developmental VMs where I use it as a launch point for various other software programs that my team uses to develop in some pretty legacy programming languages, such as Ada from 1982. It has been pretty flexible in allowing me to actually utilize that. A lot of modern operating systems do not have that interoperability with something that is that old.

For the most part, Red Hat Enterprise Linux (RHEL) helps solve a lot of versioning control. Being a defense contractor, that is something we have to handle all the time. We cannot go too far ahead and we cannot lag too far behind. Versioning control is a pain point that Red Hat Enterprise Linux (RHEL) has helped a lot with, especially keeping their older repositories up to date for a lot longer than most operating systems, such as Windows does with theirs.

The features of Red Hat Enterprise Linux (RHEL) that I like the most are probably the more automated aspect of management with it. I like being able to use Ansible for a lot of our repository management, keeping our repos up to date, and keeping certain aspects where they are supposed to be, almost like baselining.

The features in Red Hat Enterprise Linux (RHEL) that I use to navigate my security risks include Satellite, which has kept patch management very easy to keep up with. In a traditional aspect, we have people patching manually and burning them to CDs. I have used Satellite to keep our patch baseline really up to date, managing CVEs, vulnerabilities, and things that come out almost on a daily basis, keeping those closed, patched, and up to date.

Honestly, I cannot really think of anything to improve in Red Hat Enterprise Linux (RHEL). I think at least from my point of view, how I am using it, it is in a very good state. Obviously with AI coming forward and in a place where we cannot really utilize AI, I would prefer to have a more traditional operating system. But from my standpoint, Red Hat Enterprise Linux (RHEL) is in a good spot right now. I cannot really think of anything that I would say should be different, should be changed, or added.

I have been working for about 12 years on and off between Unix and Linux.

I assess the stability and reliability of Red Hat Enterprise Linux (RHEL) as very high. I have not experienced any downtime, crashes, or performance issues. Obviously we have had hardware issues, but that is old hardware running new applications, and it does not always work together. But on the operating system side of things, definitely not. It has been a very stable operating system. I have not had performance issues or any sort of latency problems or anything with that.

I think Red Hat Enterprise Linux (RHEL) scales really well, at least to my current needs. Obviously I cannot speak 10 years in the future because I do not know how we are going to go in that direction, but now I would say it scales really well, especially if we can start using applications such as Ansible and Satellite. It would be infinitely easier to scale with it.

I would rate the customer service and technical support a 9 to 10. The level of expertise, the availability of information, and the ease it is to access it are significant.

Prior to adopting Red Hat Enterprise Linux (RHEL), I used solutions such as Solaris 5, which was a really old operating system. Obviously, I have worked with Windows here and there. The only other one that I have actually used was Ubuntu.

I would describe the experience of deploying Red Hat Enterprise Linux (RHEL) as straightforward and super smooth. I have not had an issue in the past five to six years. When I was first learning how to deploy it, there were growing pains. Everyone has those issues on their first time, but after that, I have not had any issues with deploying it, whether that would be online, offline, air-gapped, or internet-connected.

I would say the biggest return on investment when using Red Hat Enterprise Linux (RHEL) from a technical point of view is the portability and modularity of it. Being able to install a server OS and being able to add piecemeal applications that we need on an individual scale is essential because, obviously if we have a really minimal, small scale, lightweight VM, we cannot install a desktop with a GUI and implement every single repository available and everything in that repository. But being able to piecemeal it and put it together in that way has that modularity and that lightweightness to it.

I cannot really talk about my experience with the pricing, the setup cost, and the licensing of Red Hat Enterprise Linux (RHEL) because that is handled by our sales people. On my end it is, "I need a license," and they provide it.

I did not really evaluate other solutions while using Red Hat Enterprise Linux (RHEL). There were talks and questions about possibly reducing overhead costs by swapping to something that is free. But at the same time, with the enterprise support, are you going to end up spending more money on using a free, open-source OS versus Red Hat Enterprise Linux (RHEL) over getting support for it, or having to bring in someone specific that charges maybe $200 an hour or something versus having a support contract with Red Hat Enterprise Linux (RHEL)? I would say not really, just because the enterprise level support is something that is kind of key to our industry.

I assess the knowledge base offered by Red Hat Enterprise Linux (RHEL) as almost limitless. The knowledge base ranges everything from someone who worked on a very early version of Red Hat Enterprise Linux (RHEL) posting in the forum 10 years ago and it is still there versus Red Hat Enterprise Linux (RHEL) 10 coming out and there being people already talking about how to better optimize it to run on various hardware, how to utilize it better, or other optimization methods. It is almost limitless.

My advice to other companies is that with both the enterprise support, obviously a big thing, because there are companies that are substantially larger than mine that will use hundreds of thousands throughout the year. It is really easy and scalable, especially if you have the management capabilities with Satellite and Ansible, being able to manage mass amounts of applications all at once through automation. It would definitely benefit a lot of companies to go to Red Hat Enterprise Linux (RHEL), just because of how easy it is to manage once you do have those capabilities in place. I would rate this product an 8 overall.