We use Red Hat Enterprise Linux (RHEL) at the enterprise level to host various applications. RHEL is our enterprise strategy for the Linux operating system, and it helps us host most of our mission-critical applications.

The feature of Red Hat Enterprise Linux (RHEL) that I appreciate the most is the security features. The security features of RHEL protect our environment. By having strong security hygiene with RHEL, we are able to provide business value back to our stakeholders.

I have been involved in Red Hat Enterprise Linux (RHEL) migrations and upgrades. I would describe the experience of RHEL migrations as challenging since it's not an easy task to migrate thousands of machines in one major release window. RHEL has helped to mitigate downtime and lower risks, as we keep RHEL current with patching.

The image model that is currently being deployed with RHEL 10 is going to be a way of improving RHEL. I'm using CICD pipelines to manage the OS, just as we do applications. We don't have specific metrics on how much less risk has been lowered or how much downtime has been mitigated, howrever, we do keep our systems patched within 30 days of CVE being released, so our risk exposure is quite low.

To make Red Hat Enterprise Linux (RHEL) a ten out of ten, addressing the enterprise management tools, such as SELinux policy management and firewalls, would bring it much more in line, especially regarding security features and overall operations management.

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

The stability and reliability of the platform are excellent.

We have scaled both in the data center as well as in the edge with over 15,000 devices.

We have a very good relationship with Red Hat for support and customer service. We have a TAM service, so from a support perspective, our cases are handled very efficiently.

I considered other solutions while choosing Red Hat Enterprise Linux (RHEL), and we have a combination of RHEL and open-source free versions of RHEL. The biggest difference between RHEL and those open-source versions is support; at the end of the day, it's the partnership for support from Red Hat versus the binaries where it's self-managed and self-maintained.

Currently, we deploy Red Hat Enterprise Linux (RHEL) on-premises and we use open-source technologies to provision and deploy both bare metal and virtual.

The biggest return on investment when using Red Hat Enterprise Linux (RHEL) is the whole ecosystem and partnership with Red Hat.

We have enterprise contracts with Red Hat, and regarding pricing, we have a good deal. On a scale of one to ten, I rate Red Hat Enterprise Linux (RHEL) an eight.

I used Red Hat Enterprise Linux (RHEL) for my past job where it was used for VMware. It was always on VMware, JBoss, or WebLogic for web-based apps and similar applications. In my current job, we use it as a base OS for AAP or for VSOS, for a Docker host, a pod host, or various applications.

Red Hat Enterprise Linux (RHEL) is valuable for us since it's stable and reliable.

Some of the new features they're adding to it, such as RHEL 10 and the AI, sound really helpful. The federal security features are also beneficial. Especially the AI feature sounds useful.

Red Hat Enterprise Linux (RHEL) helps simplify processes and having support is super helpful. When I have an issue and try to track it down without success, I can submit a ticket and get support. They're usually able to troubleshoot the issue, so having support is beneficial for me.

Our upgrade or migration plans to stay current involve using Red Hat Enterprise Linux (RHEL) 8 for much of our infrastructure, while also deploying RHEL 9 for the past six months. Once RHEL 8 is deprecated, we'll probably start looking to migrate to RHEL 10 and building net new servers.

Red Hat Enterprise Linux (RHEL) definitely helps to mitigate downtime and lower risks through access to AAP. I've also heard you can do an in-place update for the kernel, which is something I'm curious to try but haven't had the chance yet.

Improving Red Hat Enterprise Linux (RHEL) requires good documentation and having a way to onboard people for new technology they're introducing. The AI will be helpful for that since they have that now. The SE policy is not very clear on how it's supposed to be implemented, which they can improve upon, or perhaps I don't know where to look for that information.

I have been using Red Hat Enterprise Linux (RHEL) in my job for probably ten years or more.

Red Hat Enterprise Linux (RHEL) has been pretty reliable from my experiences so far, with no major issues.

Customer service and technical support from Red Hat Enterprise Linux (RHEL) has been pretty good overall. It has been fairly responsive, although I have had times when it was somewhat slow to respond to tickets and requests. I've had coworkers who have experienced that as well, so that could be improved. The response and quality of their responses could be better in some cases. In other cases, it's adequate for what we need.

My experience of deploying Red Hat Enterprise Linux (RHEL) in general has been pretty good so far. I use Image Builder, which is developed by Red Hat. I use that to create the image, and then satellite servers actually deploy it. For the most part, it's seamless and reliable.

The biggest return on investment when using Red Hat Enterprise Linux (RHEL), from my point of view, is having the integration between all of the various platforms, whether it's AAP, or satellite, and IDM. We use satellite, AAP, and IDM, and the integration between all of these has been super helpful.

We haven't had a need for other solutions while using Red Hat Enterprise Linux (RHEL) currently, but if something came up, we would probably consider it.

I have been involved with upgrading from Red Hat Enterprise Linux (RHEL) 8 to RHEL 9, and from RHEL 7 to RHEL 8 because RHEL 7 has been sunsetted. In these cases, we build net new rather than doing in-place upgrades.

For upgrades, we use satellite to deploy, and AAP for our host provisioning and whatever we need to layer on top of the infrastructure. For managing Red Hat Enterprise Linux (RHEL) systems regarding provisioning and patching, we use AAP. We have a written playbook that reaches out to the host and takes a snapshot of the host in VMware. Then it runs the patching and reports back if it succeeded or failed.

I rate Red Hat Enterprise Linux (RHEL) an eight out of ten.

My main use case for Red Hat Enterprise Linux (RHEL) is hosting applications.

My company benefits from using Red Hat Enterprise Linux (RHEL) by having more secure workstations and inviting more beginner users.

The feature of Red Hat Enterprise Linux (RHEL) that I appreciate the most is the new Boot C that's coming out. That's been pretty interesting.

RHEL helps me solve the pain point of feeling disconnected from the community. I've been feeling more involved and considered. Previously, a lot of documentation was for connected instances, and I work for an air-gapped network. Now I appreciate seeing that the documentation actually has disconnected settings. It's neat to be included in there.

I appreciate the documentation. The knowledge bases are pretty good. Usually, when I have an issue and find a Red Hat knowledge base, it addresses the issue.

Red Hat Enterprise Linux (RHEL)'s built-in security features are really well designed for simplifying risk reduction and maintaining compliance. I see many new technologies coming out are geared toward security or enhancing security. It's neat that it's continuing to evolve.

My upgrade or migration plans to stay current with Red Hat Enterprise Linux (RHEL) involve leaning on our unclassified environment before we can upgrade, as I'm in a disconnected network. As soon as we're able to, I'm trying to upgrade as often as we can. It's because I want to utilize all the new tools coming out in 9.6 and now 10. We just got to RHEL 8, and I'm already ready to leap RHEL 8 to get the newest features.

Improving Red Hat Enterprise Linux (RHEL) can be tough, however, a significant area is collaboration tools. We have many Windows users that use Outlook and Skype or Teams to collaborate on our network. They want Linux desktops due to the fact that they want to use containers. Their biggest complaint is, 'I need two workstations to do my container work and one to collaborate.' If somehow RHEL can start introducing or collaborating with Teams and Outlook so their users can work with their Windows peers, that would be great. But I don't think that's available yet.

Regarding pricing, setup costs, and licensing, there needs to be more of an education piece to it. For instance, when purchasing 10 or 100 node licenses, they could suggest, 'We also offer this 1,000 node license instead, and it'll save you specific amounts.' Just more education on their offerings would be helpful, because usually, we're coming out with the requirements, and then they just provide it to us. They could inform us about saving by bundling it differently or using alternative approaches.

I've been using Red Hat Enterprise Linux (RHEL) since 2012, which is 13 years now.

The stability and reliability of Red Hat Enterprise Linux (RHEL) have been pretty good. We haven't had any issues, major crashes, or anything similar.

The scalability of the Red Hat Enterprise Linux (RHEL) platform has been able to meet my company needs for servers. The workstations are a little difficult, but overall it meets our requirements.

Regarding customer service and technical support of Red Hat Enterprise Linux (RHEL), I really enjoy it.

With many other vendors, I have problems with support and back and forth, getting escalated, routed all over the place. Usually, when a case gets assigned to someone from Red Hat, it's handled in a timely fashion, and it's precise. There's no guessing or reading from scripts. It's direct to the point.

I would rate the customer service and technical support of Red Hat Enterprise Linux (RHEL) an eight and a half to nine. The only reason for not giving a perfect score is that there could be more knowledge base articles or documents. There's not always a Red Hat instance for what I'm looking for, however, when there is one, it's always accurate.

Before implementing Red Hat Enterprise Linux (RHEL), I used CentOS and Fedora. The main difference between Red Hat Enterprise Linux (RHEL) and those prior solutions is the support.

I would describe the experience of deploying Red Hat Enterprise Linux (RHEL) as pretty simple and straightforward. The GUI is really interactive, and it's really easy to build from scratch.

The biggest return on investment when using Red Hat Enterprise Linux (RHEL), from a technical point of view, is that it reduces man-hours.

With Ansible, it definitely reduces man-hours in patching or being able to configure or manage systems across the country with hundreds of systems. The approximate reduction of man-hours that RHEL provides is in the hundreds. I couldn't imagine administering a couple of hundred servers one by one.

We have to implement quarterly security checks and remediations that come out in bunches of 30 at a time. Having to do that on each box would take forever. I could probably only do four or five a day with our few hundred servers.

We did not consider any other solutions while using RHEL.

I have been involved in migrations or upgrades of RHEL, and I just completed a leap upgrade from RHEL 7 to RHEL 8. We manage our Red Hat Enterprise Linux (RHEL) systems when it comes to provisioning and patching by using templates from VMware to deploy our RHEL boxes, and for patching, we use Red Hat Satellite to provide the patches. We also use Ansible platform to run the plays, to kick off the updates and the reboots.

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

Our main use cases for Red Hat Enterprise Linux (RHEL) are for our centralized O&M platform, while on the edge we use CoreOS.

My company benefits from RHEL features by avoiding drifts in our solution. If it gets out of engineering, we don't exactly know if the solution is going to drift if someone implemented manual configuration.

Red Hat Enterprise Linux (RHEL) helps me solve pain points such as security, upgrades, patching, and all that is related to long-term support.

The feature I appreciate the most in the newest version is the image mode and the upgrade in an immutable way.

Security requirements are a consideration when choosing Red Hat Enterprise Linux (RHEL). It's the platform that really allows for longer-term support in terms of security patches, which is also one of the requirements from our customers; this is why we are on Red Hat Enterprise Linux (RHEL) for those services.

When it comes to managing my Red Hat Enterprise Linux (RHEL) systems for provisioning and patching, I start from zero. We provide a golden image scenario, and we install based on that golden image while customizing the product through our software itself, providing new bundles and everything around there. Patching is very similar; we provide additional packages and everything around the upgrades, and I'm looking forward to the image mode so that we can provide steps and immutable AB upgrades.

They should try to converge all the different product lines, in both Red Hat Enterprise Linux (RHEL) and CoreOS and OCP based on CoreOS, to get to a single point where it would be easier to move from one to the other.

Sometimes we build products for one specific application or product, and it would be beneficial to move to CoreOS due to further requirements, however, it's not always straightforward. All the different teams working on the different Red Hat products are pretty much self-contained, which is understandable, but if there were more of a common baseline, it would be much easier to consider moving from one license to another, from one product to another.

In the company, I've been using Red Hat Enterprise Linux (RHEL) directly for three years. Before then, we have been partners and have also been using CentOS and Fedora for a longer time, approximately ten years.

The stability and reliability of the platform are top class.

Red Hat Enterprise Linux (RHEL) scales pretty transparently with the growing needs of my company. It scales effectively when we need to add additional resources or knowledge, and it's straightforward for people to gain those and for our structure to implement even more servers around these others. Both technically and knowledge-wise, Red Hat Enterprise Linux (RHEL) scales effectively.

The customer service and technical support are excellent, especially through the partner program. It's easier to get support over specific issues, and I have noticed when we had bigger issues that could have prevented market problems, there was a good escalation path towards the right people to get answers.

I have considered other solutions rather than Red Hat Enterprise Linux (RHEL).

When we were considering getting out of CentOS, we were evaluating everything, including other open solutions such as Rocky, as cutting-edge solutions such as Fedora.

I personally pushed for Red Hat Enterprise Linux (RHEL) since it was the best solution for us at that specific moment. I understand there are other solutions such as SUSE and Ubuntu that are all in the same market, however, with different approaches. I prefer the Red Hat Enterprise Linux (RHEL) approach.

The deployment is generally very easy.

The biggest return on investment while using Red Hat Enterprise Linux (RHEL) from my technical point of view is the continuous patching and security fixes that are constantly being added and the support around it. If we are having an issue, we can directly reach the right people for support.

I would rate Red Hat Enterprise Linux (RHEL) as a product today at a solid eight out of ten, considering improvements already in place for the roadmap. With the features coming in RHEL 10, I could provide it an overall nine out of ten.