The main use cases with Red Hat Enterprise Linux (RHEL) for me are hosting Oracle databases, Oracle server database, and MariaDB. When we need to install Oracle, we put it on Linux, and it usually was Santos in the past. Then we moved to Oracle Enterprise Linux or Red Hat, and when Oracle released the Linux distro, we moved to Oracle because the devices are really open source.

Some of the best features of Red Hat Enterprise Linux (RHEL) include stability; it doesn't break. Stability, along with management tools and users for management tools that they add to the Linux distro, are important. The main reason is stability. In the server area, we don't want change. That's why we're trying to move back to Debian, because Debian is stable—old, but stable. 

Red Hat Enterprise Linux (RHEL) does help save time because the setup and general installation experience is very optimized and well-established. I made tests installing and setting up radioactive environments for virtual machines, and it was a very good experience, fast.

Red Hat Enterprise Linux (RHEL) is for on-premises only; we try to avoid the clouds as much as we can. In Brazil, we are seeing an interesting movement with small cloud providers because Amazon, Google, and Microsoft are too expensive. I am noticing the rise of many small companies that build small data centers and offer cloud services to small companies. They prosper with a better price and a simpler solution—not a fancy data center with sophisticated security. Just a small space with a decent Internet connection and a stable energy source, and they are good to go. People are prospering with this model of small cloud providers.

The main difference between Red Hat Enterprise Linux (RHEL) and some of the others that I'm evaluating now is that Red Hat tries to use more recent packages. The problem with Debian and some of the stable distributions is that they are too conservative, and they keep the version progress very slow. I sometimes develop and create things that need more recent packages and libraries, and with Debian, I usually struggle with that. Red Hat usually provides the new ones—stable, but new. That's one of the best features of using Red Hat. Ubuntu also upgrades some important libraries from Debian.

I have used Red Hat Enterprise Linux (RHEL) for more than fifteen years, because we have some infrastructure on it.

I assess the knowledge base offered by Red Hat Enterprise Linux (RHEL) as excellent; they have a great technology base on their website, but it requires a subscription. You might think you get free access, but I really don't prefer it. I usually find other sources. I know they have a very good knowledge base with excellent documentation, but I usually don't get access to it. I have not reached out to their support, so I do not have any personal experience with Red Hat support. The support that we really use from time to time is Oracle. My clients use the Oracle database, and they all pay for support. We use it because my partner, who is an Oracle database administrator, frequently deals with problems with Oracle and uses their support, and it works very effectively.

Positive

My thoughts on the deployment with Red Hat Enterprise Linux (RHEL) are that it's easy, there are no problems at all. It's very easy, including in the cloud; they offer many partners, and it's really easy to move your loads to the cloud with Red Hat. I believe it's easier than with Microsoft. However, my clients usually do not get involved with this; most of them are Microsoft-based.

The ROI with Red Hat Enterprise Linux (RHEL) is useful if the company requires accountability or a formal contract, because they usually need someone involved in some kind of accountability process when lawyers get involved. Only in that situation does it make sense to pay that price. Usually, companies that are required by law to have licensed products, such as banks and insurance companies, have obligations by law. This is especially true in Brazil, where the insurance market is very regulated. It makes sense for these companies to have a license contract, particularly in the case of security leaks and similar issues.

My experience with the pricing or licensing for Red Hat Enterprise Linux (RHEL) indicates that our clients never chose to purchase a license. I watched the prices a few months ago while considering buying one for myself, and they were expensive; it's not a reasonable price, especially for small companies. The business value of Red Hat Enterprise Linux (RHEL) is compatible and on the same level as other Linux distributions I have used. They all charge the same for their products. I usually don't see much difference. When I compare the price of Red Hat Enterprise Linux (RHEL) to that of Windows, they are basically the same price, just a little cheaper, a small fraction. All of these big corporations try to squeeze the clients as much as they can. The only exception is Broadcom, which seems to try to charge an absurd amount for their products.

My clients all have their own firewall solutions and network security solutions that they purchase. We usually don't deal with that. We just keep the built-in firewall running, and that's all. That's the main feature that we use on Red Hat and other distros, the built-in firewall. 

Security Enhanced Linux (SELinux) is something we do not engage with. Last week, I tried to install a new version of Oracle Enterprise Linux from Red Hat on an old HP server, Gen 5, but it did not work; I needed to go back to Ubuntu. Ubuntu, even in the new version, uses a kernel that works on old hardware, so we have to deal with this situation. If you have old hardware and need to repurpose an old server, you can't use these new distros. Even Oracle does not work with very old equipment, more than ten years old. 

I would rate Red Hat Enterprise Linux (RHEL) as a seven or eight out of ten.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

As an end user and a trained engineer working on field development, I am required to use a Linux-based system for all aspects of our work. This includes everything from logical design to design verification, and physical design, all the way to integrating data into the silicon database at the foundry. Since all of this occurs in a Linux environment, I must ensure we have the right platform in place. The performance we achieve with the tools we use can vary significantly across different platforms. Additionally, the support provided by these platforms is crucial. In the field of silicon design, we rely heavily on electronic design automation (EDA) tools, which are continuously being enhanced. As this area evolves, it’s essential for our operating systems to keep pace with the migration of the latest tool versions. If I become stuck with an outdated version of the OS, it can adversely affect my productivity and the quality of my designs. Therefore, I need to be reasonably familiar with various operating system providers and understand the pros and cons of each. This includes comparisons between Red Hat, SUSE, and Ubuntu, which is essential for meeting my requirements.

Since it is widely used, I believe the knowledge base is fairly good. In my own organization, which has three vertical companies, two others were already using Red Hat Enterprise Linux (RHEL) for production. They were asking me to go with Red Hat Enterprise Linux (RHEL) unless I had a compelling reason to go to SUSE or Ubuntu. This indicates that the IT team within my company preferred Red Hat Enterprise Linux (RHEL) for support and documentation purposes. The company has been around for more than a decade, so familiarity might be one reason, or resistance to change may have been another reason to stick with Red Hat Enterprise Linux (RHEL). In my role as the design manager, I have not heard anything negative about Red Hat Enterprise Linux (RHEL).

My decision to go with Red Hat Enterprise Linux (RHEL) was influenced by three main factors:

1. The IT team’s familiarity with Red Hat due to its previous deployment in other units.

2. Competitive pricing, which was 25 to 30 percent lower than other options.

3. The perception that Red Hat offered long-term service pack support for an additional fee; something that other providers like SUSE may not have offered.

Ultimately, the first two reasons were strong enough for me to lean towards Red Hat.

To some extent, I am speculating, but at the end of the day, the main thing we care about is how the resources are getting scheduled and utilized. Without an external load-sharing application, the number of cores in our servers and the memory should all be utilized effectively. If they can do very good dynamic resource allocation, maximizing the number of cores and the memory without external applications, that would be beneficial

Additionally, this is not just for Red Hat Enterprise Linux (RHEL), but for any OS - I would really love to make sure that their security features are robust and getting updated regularly. I believe at a given point of time, they may be very good, but hackers are also improving their techniques. I would definitely expect Red Hat Enterprise Linux (RHEL) or any OS provider to constantly monitor, understand if there are any new vulnerabilities in their OS, and provide patches or fixes so that we are always guarded from any security threat because what we are developing consists of very important IPs that have to be protected from malware attacks.

The most important thing is that it has to be stable. If it is not stable and we have to reboot it because of something, that would be problematic. The kind of tools it provides natively is important. For example, if I am doing development, I want to have a checkout process. If they have well-developed documentation and the ability to work with the code itself, along with good support for developing, then the performance of the OS would improve. If I see that one of my runs for any workload is taking five days, I immediately question why it is not completing within a day. If the load sharing is not happening correctly, there might be switches or features that the OS provides that can help use more memory or similar resources. Being developer-friendly would be beneficial. One thing managers hate is nasty surprises, so even if something is not working in the OS, it should provide some ability for IT to observe potential issues three or four weeks in advance.

I have only been using Red Hat Enterprise Linux (RHEL) for a short duration of time, about six to eight months because the migration happened very recently.

I am working for a startup company. We used to use open source SUSE because that was kind of easy to use and we did not have to spend many dollars. When we reached the point where we had to go to production, we needed to ensure we were using something more reliable because open source is open source. When I go to a newer version or a production version of the OS, some of the designs we are developing will be around because our startup is focusing on accelerators for the cloud. Some of these can be around for seven years, 10 years, and beyond. Hypothetically, even after 10 years, somebody who is using our silicon can find a bug, and we are obligated to fix it through software or other means. If we do not have the OS support at that point in time, because 10 years is a long time, it becomes problematic. When we go towards production, the kind of analysis that I do involves determining how many years this OS is supported and whether they will support it for an extended period, provided I pay them extension money. I am an end user, and I try to look at the facets of the OS based on my current business needs.

When we were using Ubuntu, I initially found it sufficient for my EDA tools under the evaluation licenses I had. However, as I progressed into silicon design and needed to purchase production licenses, I realized that the older version of Ubuntu wasn’t adequate. The question arose: if we were to upgrade to a paid version of the operating system, which one should we choose? I conducted some research comparing Ubuntu and Red Hat, and ultimately decided to go with Red Hat. Once I made that decision, I simply needed to explain my reasoning to my IT team, stating that I wanted to upgrade the twenty or so servers I was using to Red Hat 9.1, or whatever the current version was at that time. They took over from there.

We experienced some initial challenges when we moved to Red Hat, mainly due to the tools' versions. At first, we struggled to navigate these issues, but once I contacted support, they were able to resolve them quickly.

The maintenance is handled by the IT team.

Most of the studies that I did were between Ubuntu and Red Hat Enterprise Linux (RHEL). I did not check extensively on SUSE Enterprise.

I was inclined to choose Red Hat for a couple of reasons. First, the IT team’s familiarity with Red Hat was crucial since it had already been deployed in other areas of the organization. This existing knowledge made the transition smoother.

Additionally, I did not inquire about pricing immediately because, ultimately, my business unit would be responsible for the costs. I recall that the price for Red Hat Enterprise Linux was less than one lakh rupees per license per year. The annual cost might be around 1.2 lakh or slightly more, but it was certainly under that threshold. Furthermore, I believe that if we were to negotiate for a larger number of licenses, we might have received a better rate. Regarding the initial pricing I received, I remember it being about twenty-five percent lower per license per year compared to other options. 

For my use case with EDA tools, Synopsys EDA tools' local AE team said that support in India is better for Red Hat Enterprise Linux (RHEL). Additionally, Ubuntu and SUSE support for 10 years, whereas Red Hat Enterprise Linux (RHEL) supports for 10 years plus an extended two to four year period for a cost. Since our chips will be in the cloud market for at least a decade or more, this long-term support influenced my decision.

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

The main use cases were certifying our product with this OS platform, installing our product on this platform, and identifying the challenges we face, such as memory leak issues or OS-level issues, such as some libraries not being supportive, permission-related issues, or glitches due to different folder structures because the paths vary from Windows. Developers mostly keep Windows in mind as they have Windows laptops for the development environment.

Most of the time, we only certify our product with this OS. We perform most of the operations related to that only, leaving very little chance to explore features. However, as I read the news and newsletter from the Red Hat side, there are a good number of features, such as server editions, that can be really helpful.

System roles are helpful because we can achieve security through them. This is a good feature, as we can restrict permissions and policies with their help. 

When interacting with terminals, most of the errors can be a bit complicated for humans to read. If they used more user-friendly error messages, it would help people understand quickly. 

There are also a few changes needed at the library level. Some libraries supported by others, such as Oracle, are not supported by Red Hat Enterprise Linux (RHEL). Especially in terms of Java, as now Java is with Oracle, if the Red Hat Enterprise Linux (RHEL) system could align with those libraries, it would be helpful for end-users, eliminating the need to figure out which library is causing issues.

I have been working with Linux solutions for four to five years.

It is stable.

We create a ticket when we contact Red Hat support, but most of the time, we are able to find solutions through the community. The support is good from both Oracle and Red Hat. I would rate their support an eight out of ten.

I have tried Oracle Linux and SUSE Linux, and we've explored different versions. It depends on the customer's requirement and whatever platform the customer is comfortable with; we have to certify our product with that.

There are multiple factors that led to our decision to move to Linux: pricing is one of the biggest factors, then security because Linux is more secure than Windows. Performance is another reason since malware programs do not run directly on Linux. Additionally, the command prompt is always faster than GUI mode.

When it comes to learning, it's all about perception because most people carry their perceptions from their college days. If someone is new or a fresher joining the industry, they have their own perceptions in mind. They often feel comfortable with Windows because most colleges provide Windows machines, but once they get hands-on experience with Linux systems, they start preferring Linux over Windows.

I haven't seen many complications with the initial setup of Red Hat Enterprise Linux (RHEL) because whenever we provide a build or our product, we have a readme file with all the steps included. It's usually not that difficult. It's a couple of hours of work, and if any difficulties arise, it doesn't take long because we have a good community online to find solutions.

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

Our use cases for Red Hat OpenShift revolve around telco environments, where we deploy telco applications using container microservices architectures. We have around 32 to 35 OpenShift clusters, with multiple worker and master nodes running on them, totaling more than 500 nodes across pre-production, test, and various production environments. We onboard different applications onto these OpenShift clusters, which primarily operate in private data centers on bare metal rather than in VMs, since the motive of this client project is to align the telco environment with a cloud-native approach.

It enables customers to deploy any type of application. A lot of enterprises are moving to the Linux environment from the Windows environment.

When it comes to development, it saves time because, unlike Windows, you don't require a lot of different things and licenses.

I appreciate the features of OpenShift, particularly its built-in capabilities such as operators and integration with multiple identity providers. Operators eliminate the need for creating helm charts, and considering Kubernetes, which Red Hat OpenShift is built on, the enhancements make OpenShift a preferred choice for many enterprise customers.

The documentation and knowledge base for Red Hat Enterprise Linux (RHEL) are quite good, allowing for effective searches, though I would prefer something more interactive.

I have tried the Insight features in Red Hat Enterprise Linux (RHEL), which provide a good overview of clusters, but most customers at the OpenShift level do not opt for the Insights feature for two reasons. Firstly, Insights is specific to individual clusters and does not offer a single pane of glass for multi-cluster environments. Having a centralized Insights feature for multiple clusters would be more appealing, especially for customers managing a fleet of 50 or more clusters.

There is one feature that could significantly enhance our time to market: enabling AI capabilities. For instance, if you have a fleet of Red Hat Enterprise Linux (RHEL) servers, potentially thousands running, they can incorporate a built-in agent that monitors key metrics. This agent would allow us to easily query and track the CPU and memory status of all clusters. Instead of generating traditional reports through Insights, we could leverage AI to curate this information directly. If such features could be included in Red Hat Enterprise Linux (RHEL), it would be a game-changer. There would be no need for external AI solutions; just an integrated AI agent would suffice. This enhancement could help minimize operational costs. From a customer perspective, while capital expenditures (CapEx) are already being handled through Red Hat solutions, we need to focus on reducing operational expenditures (OpEx), especially related to reporting. Even when Insights are generated, someone still needs to analyze them. By incorporating this advanced capability into Red Hat Enterprise Linux (RHEL), they can streamline processes and deliver valuable insights more efficiently.

We are using Red Hat Enterprise Linux (RHEL) for our customers. We have been using it at the infrastructure level for more than 10 years. However, we have been using Red Hat OpenShift only for the last two to three years as our container platform.

It helps reduce downtime. Overall, it's stable, but it also depends on the type of workload you are running. 

It is scalable. For example, creating logical volumes and extending disks is straightforward. This process is quite easy.

Red Hat's support is generally good, but sometimes they take a long time, which can be frustrating for customers, particularly when dealing with products still in development, such as new versions of Red Hat OpenShift. When bugs arise that lack solutions, both customers and Red Hat are searching for answers, leading to delays until new releases are issued.

Positive

I have used Ubuntu and CentOS. I find Red Hat Enterprise Linux (RHEL) better than Ubuntu and CentOS.

Its deployment is easy. The number of people required and duration depend on how many servers you're deploying.

We utilize a hybrid environment with some of our customers operating in the public cloud, allowing us to manage both on-premises and cloud infrastructures.

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

Our use cases for Red Hat Enterprise Linux (RHEL) are diverse; it powers our servers, runs desktops for our development network, as well as some of our production hosts, and we'll see if it expands further.

Red Hat is giving that level of enterprise support helps us build a Linux ecosystem that makes sense for business.

Red Hat Enterprise Linux (RHEL) helps us solve pain points by providing tremendous support from our Red Hat representatives. 

The flexibility that we get through Red Hat Enterprise Linux (RHEL) and the ability for people to build their own tools as they're working without having to deal with something like PowerShell or hack it through backwards ways in Windows is a real relief. 

Interactive Brokers is powered by our workforce, and we have really brilliant engineers, top to bottom, especially our developers. The flexibility that we get through Red Hat Enterprise Linux (RHEL) and the ability for people to build their own tools as they're working without having to deal with something like PowerShell or hack it through backwards ways in Windows is a real relief and something that we couldn't operate without.

We deploy Red Hat Enterprise Linux (RHEL) in both cloud and on-premise environments in a hybrid environment. Currently, our management of Red Hat Enterprise Linux (RHEL) systems when it comes to provisioning and patching has gone through many changes throughout the years. We are currently using KVM. We're exploring OpenShift and some other options, and I am satisfied with that management experience.

Security requirements were considered before choosing Red Hat Enterprise Linux (RHEL). We've been primarily with Red Hat for a very long time, and security concerns have kept us with RHEL throughout the years as we have not been comfortable with anything else.

Red Hat Enterprise Linux (RHEL) supports our hybrid cloud strategy effectively, and many of the options I've seen at the conference will make spreading out into the cloud without compromising our on-premise systems more convenient than it might be with another distro. I assess the knowledge base offered by Red Hat Enterprise Linux (RHEL) as very strong; the customer relations management, support, and the fact that it's an open-source platform gives you huge clarity versus Microsoft or some other type of closed environment.

Red Hat Enterprise Linux (RHEL) can be improved by providing more support for on-prem. As you go by industry by industry, the more regulation and control you need over your data, the more precious data sovereignty becomes, and being able to work in a hybrid environment with a push in that direction would be better.

I have been using Red Hat Enterprise Linux (RHEL) for 11 years now, and our company has been using it for maybe close to 20 years at this point.

The stability and reliability of Red Hat Enterprise Linux (RHEL) are very good. It's not throwing out mystery patches that break things constantly, as certain other server solutions do, so that stability has been strong because we can say we don't need that patch now, and review them on their own merits. We are looking forward to RHEL 10.

Red Hat Enterprise Linux (RHEL) scales to the growing needs of our company excellently, and the scalability is a big draw.

The customer service and technical support of Red Hat Enterprise Linux (RHEL) has been wonderful so far. The community is a never-ending well of support, and my personal experiences with our customer relations manager have just been top notch.

I would rate the customer service for Red Hat Enterprise Linux (RHEL) as a solid ten out of ten. I have less experience needing their support for technical issues. Just as a partner, it has been very strong.

Positive

We have considered other solutions in our Red Hat Enterprise Linux (RHEL) journey. There have been arguments this way or that, however, they've never been enough to dislodge us. We do run Windows and other things. That said, our whole program base and everything we do back and front relies on having an enterprise Linux solution.

The biggest return on investment when using Red Hat Enterprise Linux (RHEL) is the appreciation of being a Linux shop with enterprise-level support, enabling us to keep it up. Trying to imagine running a worldwide company purely on free open-source software would be wholly unsustainable and require unfathomable levels of worker hours, so having the power and flexibility of a Linux ecosystem with that level of enterprise support makes it all work.

On a scale of one to ten, I rate Red Hat Enterprise Linux (RHEL) an eight out of ten.

My main use case for Red Hat Enterprise Linux (RHEL) is server administration, so we provide a group that delivers server software from RHEL, including Ansible and Satellite.

The features of Red Hat Enterprise Linux (RHEL) that I appreciate most are the standard ease of use through Satellite and Ansible, which help us keep up with our demands. The benefits of those features for my company include managing compliance issues or demands we face for the business, so we need to keep up with patching on a regular basis, which is important.

Red Hat Enterprise Linux (RHEL) could be improved, and it appears 10 is a good way forward. Having been in this industry for so long, I don't have much on my mind, however, there is generally a barrier to getting used to it. The Lightspeed is improving it to help newcomers, so it seems a good idea.

My thoughts on RHEL's built-in security features are that they might be better; we haven't really gotten security to be very smooth, so we're not using much of it, and we have other tools to ensure compliance. At the moment, there is nothing I really miss from RHEL's features.

I have been using Red Hat's products since 1990. I've been using Red Hat Enterprise Linux (RHEL) since 1996 or 1997; RHEL came in the 2000s.

Red Hat Enterprise Linux (RHEL) has helped to mitigate downtime and lower risks since we don't have much downtime when it comes to Red Hat systems; it's quite stable. The stability and reliability of the RHEL platform are good.

Regarding scalability, Red Hat Enterprise Linux (RHEL) has been able to scale to the needs of the company; we haven't met any limitations yet, and we mostly deploy it with scale-out and scale-up strategies, but we haven't managed to scale up fully yet.

My experience with customer service and technical support is that they respond, which is good. Sometimes, the bug fixes take a little while, especially on their supporting systems such as Satellite. From one to ten, I would give the customer service and technical support a seven or an eight.

Positive

While using Red Hat Enterprise Linux (RHEL), I considered other solutions such as Ubuntu for client-side use; tying it into Microsoft software, such as Microsoft Entra ID, which was not possible at the moment when we started looking into it, could work even more with connections or using external vendors.

The deployment is very easy. I've been doing it for a while too. Satellite helps a lot. AIP helps even more.

From my point of view, the biggest return on investment when using Red Hat Enterprise Linux (RHEL) is the stable environment it provides, along with the solutions going from A to B, from all the way from A to Z; we get the patches, it's updated, and it's alive.

The price is always an issue, and it depends on what you get; we have lots of development, yet I'm not economical and don't deal with finance, so it's not my area of expertise anymore. 

We haven't made any upgrade or migration plans to stay current with Red Hat Enterprise Linux (RHEL) 10 since that's just released; most of our systems are running 8 and 9 at the moment, so it depends on the applications running on them, their dependencies, and we have many systems that can't be upgraded, however, we want to stay on track for the most important systems.

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

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.

Neutral

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.

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.

Neutral

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.

My main use case for Red Hat Enterprise Linux (RHEL) is running virtual machines. That's probably the most important use case for us.

Red Hat Enterprise Linux (RHEL) helps us solve pain points related to security. We want security, so it is hardened, and just supports us. As a financial institution we take security very seriously.

The feature I appreciate the most from Red Hat Enterprise Linux (RHEL) is support and simplicity. 

The knowledge base is good; they have a lot of documentation. 

We manage our Red Hat Enterprise Linux systems when it comes to provisioning and patching through Ansible. Everything's straightforward and efficient.

Adding more relevant features to Red Hat Enterprise Linux (RHEL) would be great. I have seen some issues on GitHub where people are suggesting things, such as Ansible. There are many community issues that could be implemented into Red Hat.

We try to stay two versions below the latest one just to make sure that we have security checked there and to avoid running into any bugs or issues with the latest release. We just try to apply patches as much as we can.

The stability and reliability of Red Hat Enterprise Linux (RHEL) are smooth as we have not encountered any problems or issues.

Red Hat Enterprise Linux (RHEL) scales perfectly with the growing needs of my company. It's easy to scale up with the tools we have.

My experience with the customer service and technical support of Red Hat Enterprise Linux (RHEL) has been amazing; they are very helpful. We open up a ticket, and we get someone to help right away.

Positive

The deployment is a smooth process. Some of the issues we have are just related to multiple vulnerabilities, and that's on our side to fix, however, everything else is smooth. We have no complaints.

The biggest return on investment for me when using Red Hat Enterprise Linux (RHEL) is how they have their foundation set. They have everything organized, documentation's there, it's globally used everywhere, and it's good software with good tools.

I'm not in the pricing conversation. I can't speak to costs.

Red Hat Enterprise Linux (RHEL) has helped me mitigate downtime and lower risks. They specifically thrive on criticism, and they don't take it lightly. They mentioned earlier in the panel that they wanted to prioritize the big CVs and any vulnerability that's important. Although some don't get exploited, it's good to have fewer of those numbers. 

We try to stay two versions below the latest one.

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