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.

My main use cases for Red Hat Enterprise Linux (RHEL) are primarily for IT services, as well as supporting Army programs. We use the OpenSCAP project in Red Hat Enterprise Linux (RHEL) because we have a lot of security compliance requirements that we must address with STIG compliance.

Increased security posture through running minimal base images for critical services. Scalability through automated OS deployments.

Red Hat Enterprise Linux (RHEL) helps us solve the challenges that you potentially have with the Windows operating system being a much larger attack surface with services running which often are not needed. RHEL is a security-focused operating system.

I appreciate Red Hat Enterprise Linux (RHEL)'s feature of supporting minimal installs because for a lot of our use cases, we do not need a full operating system with office productivity tools, which makes it much easier to provide just the minimal installation.

The compliance tools in Red Hat Enterprise Linux (RHEL) help our company because they are a mandated requirement, allowing us to use those tools to remediate the system and provide quantifiable percentages and scores to show that we are compliant.

Red Hat Enterprise Linux (RHEL) plays a huge role in my organizations implementation of the zero-trust model, as we always end up with requirements that force us to use Windows. Traditionally, we use Active Directory for identity management, and Red Hat Enterprise Linux (RHEL) has been a staple for all of our server infrastructure. For anything that needs to have a long uptime or anything that provides a service, we always gravitate to Red Hat Enterprise Linux (RHEL) as opposed to Windows, which is primarily for office productivity-type purposes.

My organization's process for managing regulatory compliance involves working with the cyber team to provide a checklist and show that we are compliant with all the controls or at least document why we are not or tailor them out. Red Hat Enterprise Linux (RHEL) has helped us with that because out of the box, it is in pretty good shape, so there is only minimal work we have to do on top of it.

The biggest struggle we have with Red Hat Enterprise Linux (RHEL) is the cost and the fact that a lot of our user base wants to gravitate to the free upstream offerings. I believe more competitive pricing would be my primary feedback.

My insights on the pricing model for Red Hat Enterprise Linux (RHEL) go back to the annual recurring cost. At the end of the day, anything Red Hat can do to lower that to make it more competitive would help push people to a more stable enterprise product and not be so tempted to use the upstream free alternatives.

I have been using Red Hat Enterprise Linux (RHEL) since RHEL 5 or around 15yrs.

Red Hat Enterprise Linux (RHEL) has helped us with the mitigation of downtime and lowering risks because it is a stable operating system, and we are able to keep the uptime on our servers, with everything working great. We could not be happier with it.

Red Hat Enterprise Linux (RHEL) is very scalable. We have systems where we have 2,000 users logging into it, and we have environments that are both online and on closed, restricted networks, so it is a very easy-to-scale product with everything where it needs to be.

I would rate the customer service and technical support for Red Hat Enterprise Linux (RHEL) as a nine. Everything is solid there, and I am happy with it. There is always room for improvement.

Every company starts off with Windows, and that is where we were at. There was a lot of use of CentOS for a while, but I definitely got involved with Red Hat Enterprise Linux (RHEL) pretty much early in my career and have been with it through the evolution of the product.

The deployment process of Red Hat Enterprise Linux (RHEL) is straightforward. We are able to do it at scale, having used Kickstarts for doing bare-metal installs and virtual machines, and now with containers using Ansible to roll things out. The automation built-in makes it very easy.

We have used Ansible extensively and use it a lot. We also use the Automation Platform in Red Hat Enterprise Linux (RHEL), which is part of our build pipelines and what IT does for patching.

From my point of view, the biggest return on investment when using Red Hat Enterprise Linux (RHEL) is definitely the relationship that we have with our account management team. I would say that is something we do not have with a lot of other vendors, so that is probably one of the big advantages we get with this product versus others.

My insights on the pricing model for Red Hat Enterprise Linux (RHEL) go back to the annual recurring cost. At the end of the day, anything Red Hat can do to lower that to make it more competitive would help push people to a more stable enterprise product and not be so tempted to use the upstream free alternatives.

Ubuntu is still used a lot but I've found their distributions while more upstream, boated, and move likely to be impacted by CVE.

We have not used any AI workloads with Red Hat Enterprise Linux (RHEL). We are just beginning in the world of AI, and I saw the keynotes that looked promising. We have provided some OpenAI chatbot-type solutions, so I need to look at pricing for that and see how we can potentially shift some of the things that we have done on Red Hat Enterprise Linux (RHEL) to more of an enterprise offering such as Red Hat AI.

My thoughts on the efficiency of Red Hat Enterprise Linux (RHEL) are that it is a great product. We could not live without it, and I do not see it going away anytime soon, so I believe it is a staple of the offerings.

The knowledge base offered by Red Hat Enterprise Linux (RHEL) is solid, and it is what we always go to first before we open tickets. Red Hat is doing a great job of keeping that up to date and current, making it definitely a good resource.

I would rate this review a nine overall.

My main use cases for Red Hat Enterprise Linux (RHEL) include everything from apps to web servers to HPC.

Red Hat Enterprise Linux (RHEL) helps me solve pain points primarily because the ecosystem has already been approved for use with our customers. That's probably the main thing. It's a single, trusted source to get everything from. That's really our main thing.

Red Hat Enterprise Linux (RHEL) has helped to mitigate downtime and lower risk using Satellite because I rarely have any outages on my RHEL boxes. They're pretty solid.

Satellite helps reduce and mitigate risk through the quality of the packages that get put out and the dependencies that are already validated.

I've never really thought about how Red Hat Enterprise Linux (RHEL) could be improved, but the only thing I wish they had that I've asked Red Hat for so far is something resembling managed service accounts. Since we have to integrate with a lot of Active Directory, that would be beneficial.

I have been using Red Hat Enterprise Linux (RHEL) since RHEL 4.

I would assess the stability and reliability of Red Hat Enterprise Linux (RHEL) as excellent because I've not had anything serious that couldn't be figured out.

Regarding scalability, I've never had a problem there. We run HPC on it, and it's pretty rock solid.

I don't really have an answer for the customer service and the technical support of Red Hat Enterprise Linux (RHEL) because we have to handle most things in-house.

Before adopting Red Hat Enterprise Linux (RHEL), my company was using a lot of Solaris, other flavors of Unix, and other options, but I think we've pretty much standardized on RHEL.

I think the deployment process for Red Hat Enterprise Linux (RHEL) is straightforward.

If you're doing a network install, it's easy. It's easier than the Windows side.

I'm brand new to Ansible Automation Platform. We're just rolling it out.

From my point of view, the biggest return on investment when using Red Hat Enterprise Linux (RHEL) is the fact that it's well-curated and it's a one-stop shop for most everything you need.

My experience with the pricing, the setup cost, and the licensing of Red Hat Enterprise Linux (RHEL) has been pretty good. I have no complaints.

Though there have been talks of going to other distros while using Red Hat Enterprise Linux (RHEL), that's a big ask to switch everybody over.

The features I prefer most about Red Hat Enterprise Linux (RHEL) relate to my broader appreciation for Linux given all the history behind it and open source for all that it represents.

For navigating security risks, I use Red Hat Enterprise Linux (RHEL) Satellite for patch management and deployment. We don't use Insights. That's probably the main one we use.

Regarding the role Red Hat Enterprise Linux (RHEL) plays in my company's implementation of the zero-trust model, it's pretty new to us, so I can't really answer that yet. We're still in the learning process.

In terms of managing regulatory compliance, we do use Nessus and other tools for auditing in our applications. That's probably about it.

You can usually find a good answer on the knowledge base offered by Red Hat Enterprise Linux (RHEL).

I've always been happy with Red Hat ecosystem, using it since before RHEL, and I just appreciate the flavor of it. I've tried other Linux distros and I just keep coming back because I'm so familiar with it. It's so helpful, and it's hard to beat. I would rate Red Hat Enterprise Linux (RHEL) a nine out of ten.

My main use case for Red Hat Enterprise Linux (RHEL) is using it as an operating system for all of our Linux VMs, converting all of them from 42 different operating systems and versions over to Red Hat.

One pain point that Red Hat Enterprise Linux (RHEL) helps me solve is patch management, as we previously used a giant Ansible playbook that would run updates across our infrastructure with so many conditionals in it, but now we can simplify it down to essentially just one. It was previously one playbook, but it simplifies the workload to approximately half of what it was.

The features of Red Hat Enterprise Linux (RHEL) that I like the most include the cohesion among all of our VMs, so I do not have to remember that if I am SSHing into this server, it is apt update, and this one it is DNF update, and that one it is yum update; it is all going to be the same, DNF or yum update for all of them.

For navigating security risks in Red Hat Enterprise Linux (RHEL), Satellite is a big feature for us, as in the last couple of weeks, we just had two critical security vulnerabilities come out for Linux, and we use Satellite to find all of the vulnerable servers and then Ansible to patch them as soon as Red Hat releases a kernel update.

I have used System Roles quite heavily, so I want to use Image Builder, but I have not used it yet. All of our Ansible playbooks and roles focus on using System Roles first so that future iterations and updates to Red Hat Enterprise Linux (RHEL) 10 or Red Hat Enterprise Linux (RHEL) 11 will work going forward.

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

Regarding the stability and reliability of Red Hat Enterprise Linux (RHEL), I have experienced no downtime, crashes, or performance issues; it has been flawless. We have had no issues with it, and the only waiting period we experienced was for the two recent security issues because someone jumped the gun and published the exploits too early, but that is nothing Red Hat Enterprise Linux (RHEL) can control.

In terms of scalability, Red Hat Enterprise Linux (RHEL) scales wonderfully; we have about 400 VMs, and as I mentioned, we are converting all of our existing VMs over, whether that is a straight conversion using convert to Red Hat Enterprise Linux (RHEL) scripts or a rebuild. I have had both five Red Hat Enterprise Linux (RHEL) VMs and also had 200 Red Hat Enterprise Linux (RHEL) VMs, and honestly, it has been no different; when running reports, it just takes maybe a minute longer to grab everything.

My experience with customer service and technical support has been phenomenal; I have submitted multiple cases for various issues, and technical support has also been fantastic to work with. The longest I had to wait for a solution was about two days, and what they suggested fixed the issue for us long-term.

The factors that led me to consider a change to Red Hat Enterprise Linux (RHEL) included running an audit across all of our Linux servers and discovering that there were 42 different versions of operating system or operating system versions; we could maintain that with a bunch of Ansible playbooks, but we did not want to. Another product released by SUSE is similar to Satellite in that it provides an upstream RPM provider, but it did not work very well; it was adequate, but Satellite is by far the best. Standardizing everything has been a huge advantage for us.

I would describe the deployment process of Red Hat Enterprise Linux (RHEL) as straightforward, as I can go into Satellite and spin up a new VM; I have a fully functional VM within 10 to 15 minutes. This is provisioning VMs from nothing essentially, as we are not cloning a template. We initially tried cloning templates, and it only took minutes to have a new VM up and running.

We have not considered any other solutions in the time that we have been using Red Hat Enterprise Linux (RHEL), as we just purchased Red Hat Enterprise Linux (RHEL) three years ago. However, around that time, we contemplated Ubuntu's enterprise-level agreement, which includes support and extended release for updates; these were the two contenders we really compared, and Red Hat Enterprise Linux (RHEL) beat them by a significant margin.

While I have not used Red Hat Enterprise Linux (RHEL) in a traditional sense with AI workloads, we have a Red Hat Enterprise Linux (RHEL) VM that one of our Ames Technology Hub members logs into and runs AI workloads, though I do not know what they are using, and I doubt they are using Red Hat Enterprise Linux (RHEL) AI.

In our company implementation of the zero-trust model, Red Hat Enterprise Linux (RHEL) plays a role by using SE Linux and firewall D to configure everything and set it all up, although we have a different tool for managing Windows and micro-segmentation, and we have not implemented that on Linux since Linux is such a small portion of our company's business.

I have not done a major version upgrade with Ansible Automation Platform because we do not have it yet, but I have done major version upgrades from seven to eight and eight to nine with Satellite using the Leapp package provider. I have not done any nine to 10 upgrades because no applications really support it.

The transition from previous versions to Red Hat Enterprise Linux (RHEL) was smooth; we tried converting all of our existing VMs over to Red Hat, and that was hit or miss on whether it would work. This is through no fault of Red Hat's, as Oracle Linux does not migrate over to Red Hat smoothly, but the major version upgrades have been flawless and have worked every single time.

Our company's process for managing regulatory compliance does not involve Red Hat Enterprise Linux (RHEL) playing a role, as we are not a publicly traded company, and we also do not house any PII or credit card information, so we are not under any regulatory compliance. However, our auditing team checks what users have root access to these servers or super user privileges, and at the moment, we just run an active directory audit since they are all joined to our active directory. In the future, I am hoping to set up Red Hat Identity Manager to manage SSH keys and user access into Linux servers.

Overall, I have loved the experience with Red Hat Enterprise Linux (RHEL), as I have used Ansible for six years of the seven years I have been doing this professionally. We just hired a new Linux admin, and one of the first questions I asked was about their experience with Ansible. They had worked with it, so I asked about their experience in writing playbooks or roles, and they have written them extensively. I would rate this product a 9.5 out of 10.

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) include day-to-day operations and a lot of production systems. That is mainly what we do.

When it comes to pain points, Red Hat Enterprise Linux (RHEL) helps us solve various issues. A lot of our systems are proprietary, so we develop on the Red Hat Enterprise Linux (RHEL) system, making it hard to answer what Red Hat Enterprise Linux (RHEL) does that we couldn't do without it, because we build on top of it, and if we can't find a solution, we reach out to support for help.

I do appreciate the OpenShift product in Red Hat Enterprise Linux (RHEL), and I am interested in the new feature, the MCP, which I found fascinating after seeing it yesterday.

We definitely use the Identity Management features in Red Hat Enterprise Linux (RHEL) a lot, especially the rollback features and primarily the RBAC features, which are the brains of the system right now, even though the projects I work on are locked down significantly, so we cannot use all the tools in the toolbox.

In my company's implementation of the zero-trust model, Red Hat Enterprise Linux (RHEL) plays a role mainly in the identification process, along with other tools we embed with it, focusing on identification and scaling, including a lot of tokens.

I love the knowledge base offered by Red Hat Enterprise Linux (RHEL), which I use all the time because there is always something in there that can serve as a reference, guiding me or providing solutions to solve my problems. I often encounter the same solutions for issues I have seen before.

I have not tried either Red Hat Enterprise Linux (RHEL) Image Builder or System Roles, but I plan on working with Image Builder as I think I signed up for it, though I am not certain if that is today or tomorrow.

I have not tried to work with AI workloads using Red Hat Enterprise Linux (RHEL), but I recently attended a talk about that with the Agent AI, which was new to me, and I took snapshots and pictures, planning to introduce it to the team sometime this week.

Mitigating downtime with Red Hat Enterprise Linux (RHEL) is tough to assess because of patching, which is inconsistent sometimes. Other systems installed on top can sometimes break systems, but we resolve those issues as they arise.

I do not know how Red Hat Enterprise Linux (RHEL) can be improved because I have not played with Red Hat Enterprise Linux (RHEL) 10 yet. I am still learning as I go, having downloaded it and staged it, but I have not really tinkered with it yet.

I do not want any improvements in my workflow because new features are always coming out, which I appreciate. Each new release brings along something new that we work on implementing into our current pipeline.

I have been using Red Hat Enterprise Linux (RHEL) for at least 15 years.

I have not experienced downtime, crashes, or performance issues with Red Hat Enterprise Linux (RHEL). If there were any, they would likely be due to some type of tool installed on top that was not compatible with updated patches, but overall, out of the box, there are no problems.

Red Hat Enterprise Linux (RHEL) scales well with the growing needs of my company. We have upgraded from version 7 to 9 without problems, and the migration has been straightforward, although I think version 10 might have some features that are not compatible, but I am not completely certain.

My experience with Red Hat Enterprise Linux (RHEL)'s customer service and technical support has been excellent. I love them and have no complaints.

From my point of view, the biggest return on investment when using Red Hat Enterprise Linux (RHEL) is the support. I love the support because when I put in a ticket or reach out, it is always excellent, and they never leave me waiting for days, providing feedback promptly.

Before choosing Red Hat Enterprise Linux (RHEL), I think my company was using another solution, possibly something like AIX or another Unix flavor, but I am not entirely certain what it was.

I do not know why they migrated to Red Hat Enterprise Linux (RHEL), as that was before I started. I just know there are still some legacy systems out there.

The deployment experience with Red Hat Enterprise Linux (RHEL) depends on your knowledge or experience. We do a lot of kickstarts, making deployment easy, but if something needs to be done manually, it might take a while. However, so far, it has been pretty much streamlined, so we are happy.

From my point of view, the biggest return on investment when using Red Hat Enterprise Linux (RHEL) is the support. I love the support because when I put in a ticket or reach out, it is always excellent, and they never leave me waiting for days, providing feedback promptly.

We have considered other solutions like Ubuntu, but right now, we are still using Red Hat Enterprise Linux (RHEL).

Red Hat Enterprise Linux (RHEL) wins because currently, everybody is familiar with it and they are happy with it. We prefer not to fix what is not broken, so we are content and happy with what we have.

I have not done a major version upgrade with Red Hat Enterprise Linux (RHEL) and Ansible Automation Platform, but that is in the pipeline, likely next quarter.

My experience using Ansible overall is good so far. I am used to doing it the old way, but now that we finally have an Ansible platform, it is better than when I was running playbooks manually from my workstation.

I have been using Red Hat Enterprise Linux (RHEL) since version 4, having used it for a long time with my current baseline systems ranging from version 7 to 9, as we try to migrate over to version 10.

I have used Ansible as well.

I know OpenShift is expensive and while I just put in requests, if they fill their budget, I am happy because that is above me.

My overall review rating for Red Hat Enterprise Linux (RHEL) is 9 out of 10.

My main use cases for Red Hat Enterprise Linux (RHEL) today include developing applications and managing server environments efficiently. I use Red Hat Satellite and Red Hat Lightspeed overall, which streamline our operations significantly.

RHEL helps me solve various pain points, such as ensuring system stability and security across our infrastructure. I particularly appreciate the advanced security features of RHEL the most, as they enhance our overall protection.

RHEL plays a crucial role in my company's implementation of the zero trust model by ensuring secure identity and authentication measures. Using Ansible Automation Platform has been a smooth experience overall, enabling better automation in our workflows.

I use features in RHEL such as identity management and Satellite, which help my company maintain compliance and security. The stability and scalability of the platform are commendable, ensuring our systems can handle growth efficiently.

Regarding improvements, I think RHEL could benefit from better user interface enhancements for future releases.

I have been working in my current field for several years now and have gained valuable experience during this time.

RHEL helps mitigate downtime and lower risks thanks to its robust design.

On a scale of one to ten, I would rate the customer service and technical support as an eight, as they are responsive, but there is always room for improvement.

I would describe the deployment process of RHEL as mostly straightforward, although some challenges may arise.

From my perspective, I have seen a return on investment using RHEL, primarily through improved efficiency and system reliability.

My company is still working on artificial intelligence workloads, as we are in the early stages of exploring this technology. I would not say that RHEL has directly helped those customers yet, as we are still gathering data on effectiveness.

Regarding the knowledge base offered by RHEL, I find it very useful and assess it highly due to its comprehensive information. I do not specifically handle insights on pricing, setup costs, or licensing, as that is managed by another department in my company.

On a scale of one to ten, I would rate RHEL overall as a nine. I advise other companies to thoroughly assess their needs before implementation.