We use the product for application hosting, availability, and CI/CD pipelines.

The solution has good availability and is easy to use. It saves money and resources like support staff.

The product should provide a portal to manage licenses.

I have been using the solution for more than five years.

The solution’s stability is fine.

The product’s scalability is fine.

The support is good.

Neutral

We have seen an ROI on maintenance. As long as our servers run, our company makes money.

We evaluated SLES and Windows.

We purchased the solution via a cloud provider. We use AWS, Google, and Azure. The resiliency of the product is the same as other products. 

The solution helped us reduce costs. We use SLES and Windows alongside Red Hat Enterprise Linux. Application support and vendor support for Red Hat Enterprise Linux are better than other products. 

Overall, I rate the product an eight out of ten.

I work in the financial industry in Brazil and my first job was to use Linux.

We deploy Red Hat Enterprise Linux on-prem and in the cloud. Our cloud provider is AWS. 

We use Red Hat Enterprise Linux for web applications, including the JBoss data bridge. We also have some applications for prevention and risk. Red Hat Enterprise Linux is used for most of our applications in Brazil, so it is used for almost everything.

We run our workloads and applications on AWS.

There are many Linux-based operating systems. We wanted an operating system that was mature and reliable, and Red Hat Enterprise Linux was the best choice for us.

Red Hat Enterprise Linux is a highly resilient operating system. It has a strong XFS file system, kernel, and package build.

Migrating workloads between the cloud and our data center is easy. There are no problems.

The knowledge base offered by Red Hat Enterprise Linux helps a lot. It is very useful and has helped me to resolve the issue by looking at the documentation.

The integrity of our operational systems is very stable. Red Hat Enterprise Linux has a good file system type and good kernels. It does not crash for any reason. This makes it a very stable platform for me. It is the best solution for our needs.

There was a reduction in the amount of detail provided in backlog messages between Red Hat Enterprise Linux versions six and seven, compared to versions eight and nine. This makes it more difficult to troubleshoot errors in versions eight and nine, as users must dig deeper into the operating system to find the source of the problem. Versions six and seven provided more detailed error messages, which made it easier to identify and fix problems. Deploying applications using Red Hat Enterprise Linux versions six and seven was seamless. However, there is a chance that something could be broken when deploying with versions eight and nine, and we may not know it.

I have been using Red Hat Enterprise Linux since versions four and five.

Red Hat Enterprise Linux is extremely stable.

One of the reasons we adopted the Red Hat Enterprise Linux ecosystem is because of its ability to scale.

I have not had a good experience with Red Hat engineers. When we have an issue, it is very difficult to have it resolved in the first call. They always have to escalate the issue and involve multiple people. At a minimum, we have to escalate an issue three or four times before it is resolved. The support team in Brazil has helped me a lot because they work with me to resolve the problem, but if I have to open a ticket and follow the steps I never get proper service.

I give the technical support of Red Hat a zero out of ten.

Negative

The initial deployment is easy. I can deploy Red Hat Enterprise Linux myself using a base image within a few minutes both on-prem and in the cloud.

The implementation is completed in-house.

We purchased our license from Red Hat.

I give Red Hat Enterprise Linux an eight out of ten.

Cloud vendor lock-in is inevitable when we adopt the cloud. This is because once we adopt a cloud service, such as DynamoDB or AWS, we become dependent on that provider for support and maintenance. It is very difficult to work with multiple clouds 100 percent of the time, as this can lead to problems with failover and other issues in multiple cloud environments because the risk is high.

The Red Hat Enterprise Linux ecosystem is more attractive because we are not just buying an operating system. We are buying an ecosystem that helps, supports, and secures our platform. I believe this is the better option.

Applying patches in the new versions of Red Hat Enterprise Linux is more time-consuming than in Oracle Linux because Oracle Linux does not require legacy environments to be patched or changed through applications.

For someone looking for an open source cloud-based Linux OS instead of Red Hat Enterprise Linux, I recommend AWS Linux. It is a very stable version of Linux and does not require a subscription.

I use the solution to build web applications.

The tool provides more support, resources, and documentation than other products.

The product is super easy to use.

The default settings are confusing. I often change these settings to avoid problems.

I have been using the solution for a couple of years.

The stability of the product is very good.

I did not have issues finding configurations and changing settings as needed. I haven't had any issues like bugs or downtime while using Red Hat Enterprise Linux. Overall, it was a good experience. Overall, I rate the solution an eight out of ten.

I work in the energy sector, so we use Red Hat Enterprise Linux for a variety of purposes. These include high-performance computing, running applications like SAP, geospatial applications, and Oracle. We rely on Red Hat Enterprise Linux for a wide range of applications, including those that require running Oracle databases.

It is important to our organization to have a solution that avoids cloud vendor lock-in. We just don't want to be locked into just one side or the other. We want to have the flexibility and availability to explore other options.

One of the main reasons we chose Red Hat Enterprise Linux was its reliability and stability. Compared to the Microsoft Windows environment, the Linux environment provided much greater stability. Therefore, we decided to use Red Hat Enterprise Linux for all our critical applications at that time, as they required a Linux-only environment.

We use Red Hat Image Builder as well. The golden images created by Image Builder are okay. In our organization, we prefer to create our own images because we need to incorporate our own security measures and harden the images accordingly.

Red Hat Enterprise Linux could do better in live patching. In this day and age, vulnerabilities are constantly emerging, I feel that Red Hat Enterprise Linux has fallen backward in terms of live patching, particularly live kernel patching. There are other products available that can perform this function, and they often follow their direction. 

Currently, my company has a live patch solution where we can patch the kernel without rebooting. This is essential because certain applications cannot tolerate downtime for reboots. However, there is a security concern when the patching process is delayed, as it exposes the system to high vulnerabilities and risks. So, when critical applications go down due to rebooting, it has a significant impact on both the financial and operational aspects. It requires a lot of money and manpower to schedule and execute the reboots, and during that time, the application downtime results in losing money. I believe this is an area that Red Hat Enterprise Linux should focus on to address this challenge.

I have been using the Red Hat Enterprise Linux operating system for around 20 years. We transferred our existing subscriptions to the cloud version. We are actually exploring hybrid solutions and availability options. As we transition to Azure, we are bringing our own subscription.

The scalability is good. We are able to scale efficiently. In our high-performance computing department, they handle a lot of scaling, and it's going well. Red Hat Enterprise Linux scales well.

I'm not particularly fond of the support. For example, when we have a server that's down, we raise a ticket indicating the severity of the issue. Then we receive another email suggesting things we can try to resolve the problem. I miss the days when we could directly speak to someone because sometimes, depending on the maintenance contracts and SLAs, it can take a lot of time without actually making any progress. Whereas speaking with a support representative could significantly reduce the downtime. So, I'm not really crazy about it.

The knowledge base is good. I would rate it a nine out of ten. 

Neutral

One of Red Hat Enterprise Linux's pros is that it has been around the longest. When working in a large corporate environment, reliability is crucial. In case something breaks, you want to have the assurance that there is a reliable support system to address the issues. Red Hat Enterprise Linux provides that level of support. 

However, it's important to note that even with a solid distribution like in Red Hat Enterprise Linux, the effectiveness may vary depending on the specific customer or scenario. It's about assessing how well the distribution handles issues when the next customer raises a complaint. So, we need to carefully consider the pros and cons based on our requirements. For certain workloads and development tasks, we might consider freestyle options that don't require paid subscriptions. In my company, we have a development program that greatly supports our decision to go with Red Hat Enterprise Linux.

Personally, I find the deployment process straightforward, but I've been doing it for quite some time. I can't speak for someone who is new to it. However, from my experience, it's relatively straightforward. I've been in this role for a while, so I'm familiar with the process.

Currently, we use Azure AVS, which allows us to migrate existing physical machines to the cloud until we can fully modernize them. It's much easier than it was a couple of years ago, but there is still some work to be done. Overall, it's manageable for us to move workloads between the cloud and on-premises or data center environment using Red Hat Enterprise Linux.

We have streamlined our deployment process within our guidelines. I can build a server in just three minutes. The time required depends on the type of server we need. If it's a more specialized server, it may take longer. However, it's nothing like the old days when it used to take several days. Especially in the cloud environment, it's quite fast. On-premises is a different story because we need to consider hardware availability, which can take longer. But once we have the hardware, the deployment itself typically takes less than an hour, especially when we leverage tools like Satellite for automation.

We have indeed realized a return on our investment. If we hadn't, we wouldn't still be using Red Hat Enterprise Linux. However, we are always striving to improve our return on investment. That's why we continually conduct due diligence and explore other operating systems to ensure that we're not blindly sticking with a particular company. We want to find the best solution that can potentially save us more money while delivering an equal or better return on investment.

Red Hat Enterprise Linux is starting to realize some other companies are gaining some footing in the industry. Red Hat's pricing still needs to get a little bit better. When you look at what you pay for a subscription compared to what you can pay with some of these other companies that do offer a lot of technical backing behind them, it starts turning heads.

Red Hat should focus on making enhancements and providing better support in that arena.

Before choosing Red Hat Enterprise Linux, we did evaluate other Linux-based solutions. When we initially chose Red Hat Enterprise Linux, we had options like Solaris and SGI. However, even recently, we have continued to evaluate other distributions because the Linux landscape is constantly evolving. There are new solutions emerging, so we have to perform our due diligence and assess what they can offer.

For customers looking for alternatives to Red Hat Enterprise Linux, my advice would be to choose something that aligns with your requirements and that you are happy with. Don't just pick something because it's cheap. You gotta look at the long term. Also, know what is needed for your project. For example, if you have issues, can you get those issues resolved in a timely manner? If you run into an issue, you're stuck, and they can't help you out, this means your project will be delayed. You will need to weigh that out.

We use the product to use the virtual servers.

Compared to Windows, the solution is much simpler. The product is easy to use.

The solution should provide demos so that users can learn to use it and improve their environments.

I have been using the solution for three to four years.

I have no complaints about the stability. It is good.

I have no complaints about the scalability.

We use the on-premises solution because we work for the government. We cannot use the cloud version because we have to maintain confidentiality. We are using versions six, seven, and eight. We also use Windows in our organization. Overall, I rate the solution a ten out of ten.

I am a Federal Contractor. Red Hat Enterprise Linux is one of the FedRAMP-approved operating systems, so the government is comfortable with using it. That is why we use it, even though it is a bit outdated. Most of our software runs on Red Hat Enterprise Linux because we work in Identity Access Management. For example, Oracle Identity Stack runs on Linux, so we have to use Red Hat Enterprise Linux. We follow very strict security protocols, and we use Ansible to enforce them. Red Hat Enterprise Linux is the easiest way for us to do this.

Red Hat Enterprise Linux is a trustworthy and highly scalable operating system. The federal government needs an operating system that they can rely on, with enterprise support and long-term service. As well as being stable and well-known within the community.

I have not yet experienced a disaster recovery scenario, but resiliency is important, and risk is very reliable. The auto logs are very clear. Additionally, with those support communities, it is straightforward enough to understand what we are looking for and to eventually resolve the issue.

I actually like the in-place upgrade that Red Hat Enterprise Linux offers. It has made our upgrade process from Red Hat Enterprise Linux 7 to Red Hat Enterprise Linux 8 much easier than we originally thought. 

I know that many people prefer in-house support, but I personally prefer Red Hat's support. It is easy to get in contact with their support team.

Even though it is not directly related, the fact that Red Hat Enterprise Linux and Ansible are closely related makes it easier for us to move forward.

The package management, repository, and satellite repository are easy to use.

I am a bit biased because my client is air-gapped. This means that we cannot connect to the internet, so all of our operations are disconnected. I would like to see better support for disconnected operations. For example, the in-place upgrade from Red Hat Enterprise Linux 7 to Red Hat Enterprise Linux 8 initially relies on a lot of online resources. This makes sense, but it would be nice for a consumer or integrator like me to be able to say, "Hey, we need an offline solution so we can upgrade our government clients on-premises." Red Hat does provide instructions on how to create a repository, but the instructions are not very clear. This leaves us scrambling to figure out why we are missing a repository in our satellite image. Red Hat should provide a way to mirror repositories or at least provide a solution for us to bubble up packages throughout the entire process.

I have been using Red Hat Enterprise Linux for four years. We started with Red Hat Enterprise Linux 6, and we upgraded to Red Hat Enterprise Linux 7 in an airgap environment. We are currently in the process of upgrading to Red Hat Enterprise Linux 8.

Red Hat Enterprise Linux is stable.

Red Hat Enterprise Linux is scalable. It is deployed in a 10,000-plus enterprise company.

The support team is always direct and easy to find. Their answers are so helpful that I have not yet had to call them. I also appreciate how they approach troubleshooting. They don't assume that you're doing anything wrong. Instead, they try to educate you on how to fix the problem. In my experience, the support team has always been very positive.

Positive

I have experience with most Linux operating systems, including distributions like Apache, Debian, CentOS, Fedora, and others. From my perspective, Red Hat Enterprise Linux is not necessarily the top standout product, but I know that it is a product that I can rely on. It is the standard image that enterprise users in the community will use. We can rely to a degree on the standardization of how packets are used to support it. However, it does not stand out to us as much as the other products. Nevertheless, I know that it will have a positive partnership with us. Red Hat Enterprise Linux is a more suitable operating system for enterprise environments in terms of stability and reliability.

We are currently in the process of reviewing our initial solution for upgrading from Red Hat Enterprise Linux 7 to Red Hat Enterprise Linux 8. The in-place upgrade for the airgap environment is an area where we are still struggling to understand the documentation. However, Red Hat has been very supportive and has offered us pathways to move forward. We do not have much to say at this time, as we are still in the middle of the process.

When we upgraded Red Hat Enterprise Linux 6 to Red Hat Enterprise Linux 7, it took us around six months due to external factors not related to Red Hat Enterprise Linux.

Our client has a direct subscription to Red Hat.

I give Red Hat Enterprise Linux an eight out of ten. I am not a firm believer that everything is perfect right out of the gate. Everything can be improved. I am a little biased. I wish there was better support for offline environments. I understand that I am in the minority in this case, as everyone is connected to the internet now. However, as a federal contractor and integrator, we have requirements that we must meet. It is not fun having to download binaries offline and then figure out how to set up our own repository. These are not straightforward tasks like Red Hat telling me what to do. We just wish it was easier to do things like patch management. Perhaps there could be more support for air gap environments. These are not environments where we can temporarily connect to the internet. They have never seen the internet.

Depending on our customer's environment, sometimes they have GovCloud, but we still use Red Hat Enterprise Linux images there. Sometimes the customer can't use that so we use the offering from CentOS. But we still try to match it with CentOS.

The reason why some clients don't use Red Hat Enterprise Linux on the cloud is not because of security concerns. I think it's more about cost and their current contract situation. They need a low-cost, open source alternative, and our recommendation would be CentOS. However, many clients are not ready to pay for the enterprise edition of Red Hat Enterprise Linux, so they may choose to scale back their plans.

I have not used the Red Hat Enterprise Linux knowledge base strictly. I have only used the Red Hat Enterprise Linux support.

Clients who use Red Hat Enterprise Linux on the cloud, typically use AWS GovCloud. As a government integrator, we strive to design our solutions in a way that does not lock our clients into any specific cloud provider. This is why we chose Linux, as it can be run on any cloud platform. This flexibility is important to our clients from a price contract perspective. For example, Amazon provides Kubernetes services, among other things. We try to figure out open source solutions or at least architecturally determine them and provide them to our clients. For example, we can tell them that they can move all of their GovCloud data to Azure or Google Cloud. Government agencies really like Amazon right now because it is FedRAMP. However, for other classes that are not government or commercial, we try to introduce them to the CentOS perspective so that they can get a taste of the upstream.

We do not use the image builder tool provided by Red Hat. Instead, we use the one provided by Amazon. We take a base image, coordinate it with Ansible, and provide it to any environments that have used the cloud. For on-premises solutions, we strictly use manual processes.

I don't have a perspective on the golden image, which is at least with our client. The parts that we use are always evolving, so we don't really maintain the golden image. We do have a relative backup of what we deployed to, but we don't necessarily have a strict golden image.

Migrating workloads between the cloud and the data center using Red Hat Enterprise Linux is not entirely applicable to us. We did migrate from on-premises to the cloud at one point, but migrating from Red Hat Enterprise Linux on-premises to Red Hat Enterprise Linux in the cloud was not a concern for us. We knew it would be stable and fine. The main concern was migrating our customer data from our enterprise to the cloud.

If someone is looking for an open source cloud-based operating system for Linux instead of Red Hat Enterprise Linux, I would like to eventually drive them over to Red Hat Enterprise Linux, but I would recommend starting with CentOS. CentOS is a good gateway OS because it is very similar to Red Hat Enterprise Linux, and the knowledge transfer between the two is very straightforward. This makes it a good choice for users who are new to Linux, or who are looking for an OS that is compatible with Red Hat Enterprise Linux.

We have a private banking client who initially started to use Red Hat Enterprise Linux for approximately 30 nodes. They found that Red Hat Enterprise Linux was the perfect operating system for implementing Ansible automation and managing their infrastructure efficiently. They also deployed Red Hat Ansible Tower for centralized management. Due to the stringent security and compliance requirements in the banking industry, they chose Red Hat Enterprise Linux as their preferred operating system to ensure security and governance across their infrastructure.

In terms of clustering, Red Hat Enterprise Linux provides robustness and scalability compared to non-Red Hat Enterprise Linux operating systems. Clustering is not as straightforward with non-Red Hat Enterprise Linux systems. Red Hat Enterprise Linux's scalability is particularly important for us. We utilize Red Hat Enterprise Linux as the operating system to achieve scalability in our operations.

Moreover, Red Hat Enterprise Linux's strong security posture and its ability to scale applications on emerging technologies across the hybrid cloud is next-generation. I believe that's what people are seeking in Red Hat Enterprise Linux. It is built with a strong focus on security, ensuring effective governance and managing security aspects well. We have high hopes that Red Hat will continue to invest more efforts in enhancing security. When it comes to container-based applications and microservices, Red Hat Enterprise Linux plays a crucial role in the hybrid cloud environment.

One challenge we've faced is with databases. Configuring and implementing DBs is much easier in non-Red Hat Enterprise Linux systems, especially in Microsoft. However, as a partner, we faced some challenges with Red Hat Enterprise Linux, particularly when it comes to enterprise applications, especially on the IBM side since it's an IBM core company. There are still several IBM products that need to mature on Red Hat Enterprise Linux. Additionally, we require more comprehensive documentation. We face difficulties with the limited availability of documentation for Red Hat Enterprise Linux. It's a different community compared to the Microsoft market, so we need the right documentation to encourage end users to use Red Hat Enterprise Linux.

We've been using Red Hat Enterprise Linux for the past seven years. As a business partner, we use the application deployed for our clients, providing consulting services. The clients run their workloads on both Red Hat Enterprise Linux and non-Red Hat Enterprise Linux systems. They have two options for cloud providers, hybrid deployments on IBM Cloud and AWS.

The benefit of using a hybrid approach is often discussed when it comes to migrating workloads to the cloud. Due to the OpenShift community, Red Hat Enterprise Linux has become the preferred operating system as it provides stability and frequent patches and fixes. Maintaining the total cost of ownership is also more manageable on the cloud.

It's excellent; in fact, it's the most stable. The presence of kernels is the key factor contributing to this stability. When it comes to security, scalability, and robustness, Red Hat Enterprise Linux (RHEL) excels in all aspects. That's why we rely on this operating system. Personally, during my time as a technical assistant from 2015 to 2016, I installed a couple of IBM applications. I found that everything ran smoothly on Red Hat Enterprise Linux without any failures.

So the stability in Red Hat Enterprise Linux is remarkably good.

The scalability is nice. Red Hat Enterprise Linux doesn't encounter any issues as a supporting core. It can scale effortlessly.

I have personally used Solaris. However, we eventually switched from those operating systems, but Red Hat Enterprise Linux has been there since version 4.2, a long time ago. I have worked with versions 7 and 9, and I believe the latest one is version 11, although I'm not certain. I have been immersed in technology for the past couple of years.

One of the most important factors is the community. The Red Hat community is different from others, and it is more active and responsive. If you have Red Hat Enterprise Linux and you want to move your production environment from development or testing, it is easy to switch by simply managing the licensing and purchasing the system. You don't need to make extensive changes at the underlying system level. Your system is ready, and you can deploy it in the production environment. It's up and running. If you want to mitigate risks and ensure security in your production environment, you can simply subscribe to RHEL and use it. On the other hand, migrating from other operating systems can be quite cumbersome and challenging. As a client and partner, I always recommend starting with Red Hat Enterprise Linux in the development and testing environments before moving to production. It makes the journey to production much easier.

Regarding centralization, we have a combination of on-premises and cloud environments where development activities take place. Currently, I don't see a specific use case for centralized development and operations, but Red Hat Enterprise Linux is being widely used both in on-premises and cloud setups. As for hybrid deployments, I haven't personally come across many instances of it. There may be a few customers who are utilizing it but not with us thus far.

Red Hat Enterprise Linux's built-in security features in terms of ensuring application and container portability are not an easy task. Although it's not my personal experience, I've observed that in the industry, there is a lot of discussion about moving toward container-based applications. However, only a small number of clients, especially those in highly regulated industries like banking, government, and oil and gas, have actually embraced containerization. They are facing significant challenges when it comes to adopting container-based applications. Many of them still rely on legacy systems running on-premises, such as mainframes.

I have seen an ROI. The most important determinant is the security aspect. Because you rely on the security of Red Hat Enterprise Linux, that's something you are paying for.

When it comes to Red Hat Enterprise Linux pricing, I have a case to share. We recently sold Red Hat Enterprise Linux OS to one of our clients. Before that, I had another client who had concerns about the OS licensing and Red Hat Enterprise Linux's pricing model. The licensing model needs to be more flexible and dynamic because the cost of a single operating system license is relatively high. I'm not suggesting a reduction in cost but rather the introduction of a different model that allows clients to choose scalable options. For example, if a client has licenses for a few operating systems and wants to expand to 50, 100, or even 200, there should be a proposal that offers them flexibility. 

Currently, most clients tend to opt for a limited number of licenses and rely on the community for additional usage, which results in revenue leakage. Red Hat should consider adopting a more aggressive open license policy that encourages higher volume licensing with clients.

When you use Red Hat Enterprise Linux in production, it's worthwhile considering the cost. But even for non-production environments, the client will definitely calculate the expenses since it's a massive implementation for large clients with an operating system. You will open your laptop, and you just need an OS. So my suggestion is for Red Hat to create a business model that also targets the user level and desktop level, where Microsoft is widely used. Considering this eventuality and how many people are switching or still using Red Hat Enterprise Linux, we, as a partner, mandate that all our Red Hat team members use Red Hat Enterprise Linux. We don't allow them to use any Microsoft operating system or other operating systems. When engineers join the company and work in the Red Hat pillar, they have to use Red Hat Enterprise Linux.

Red Hat Enterprise Linux's built-in security features, in terms of simplifying risk reduction and maintaining compliance both maintaining compliance and security, are essential aspects. Compliance requirements vary across different industries, such as banking, with each industry having its specific rules. However, security is a common concern that applies universally. Therefore, we need to address both areas.

Red Hat Enterprise Linux provides various logs and event triggers that assist in monitoring the operating system's security. Since the operating system sits as the layer between the hardware and the application, it plays a crucial role in safeguarding against security breaches and penetration attacks. A secure application relies on robust application security, followed by a well-protected OS. By ensuring the OS's security, we can establish a strong foundation for the entire ecosystem. If the OS is secure, we can confidently state that the application is at least 80% secure.

Overall, I would rate the product an eight out of ten. 

We are in a closed environment, so submitting a ticket can be painstaking as only a few of us have access to do so. We primarily use Red Hat for its stability, and it's one of the few Linux operating systems that meet our security constraints.

I find the satellite feature the most valuable. It allows us to manage disconnected workstations, keeping their patching, software updates, and bug fixes up to date. We can collect all the necessary updates on a connected system and then transfer them to a disconnected system. Each client thinks it's connected to an external satellite infrastructure, making management very easy.

The Image Builder feature seems very helpful. We currently use Kickstart to build systems.

The support can be lackluster sometimes, especially in our disconnected space where we have specific requirements. Occasionally, we encounter support representatives who are not familiar with our setup. So, in that space, personalized and tailored support based on each use case could be better.

In additional features, I would have said being more on the bleeding edge, but RHEL 9 was released, which is a nice push forward. So right now, I don't think there's anything specific. I find the product stack to be pretty decent.

I have been using this solution for three years. We are using versions 7.9 and 8.7.

It's very stable, but that's also why it falls behind at times. For example, if you have newer hardware like systems A and B that were released within the last year, there might be potential sleep issues, specifically with S3 sleep, that require manual patching and intervention in the kernel. It's because they are trying to support newer systems on a much older framework.

I believe RHEL 9 is supposed to mitigate that a little bit. It aims to provide a balance between the latest stable release and the older version that is, like, five years old. They're trying to meet somewhere in the middle.

We have around 30 workstations and approximately 60 servers.

The customer service and support team depends on the environment you are in. The support can be spotty. The support can be spotty; at least they've tried to be helpful. Sometimes they'll just point you to a documentation link, practically like Googling it for you, and it's like, "No, we've already looked at this. Can you please review the logs further?" And sometimes, I'll have to go and pinpoint specific areas to look at. And then it's like, "Oh, okay." 

It's not always very thorough. But it's hit or miss. So I think it's just a people thing. If you get somebody in support who really likes their job or enjoys fixing things, they're going to go out of their way, as opposed to someone who does the bare minimum.

Neutral

The initial setup is very straightforward. It's pretty easy to enable it. After weeks of setting up a Linux Kickstart, the whole system can be deployed. The whole bare-metal system can be deployed in around thirty minutes. So it's really fast, especially for a bare-metal image with a lot of packages installed.

When it comes to maintaining compliance, I think it's pretty good. However, for risk reduction, we have to rely on other software and tools. So I can't really say that Red Hat provides that specific functionality for us. But I think it's good for maintaining compliance is very easy, especially with satellite. It makes it easy for us to access package and vulnerability information, allowing us to identify and resolve any issues. Overall, it works quite well. If you use the right products, I believe you can have all the necessary components in one place.

The portability of applications and containers is pretty good, although there is one issue. With the transition to Red Hat 8, Docker was removed. As a result, there is an issue with using Podman, specifically related to certain types of authentication in a mixed Windows-Linux environment. Due to the way secrets and related functionalities work, Podman cannot be utilized in that scenario. Therefore, there are some challenges to address in this regard.

I believe Red Hat should have maintained compatibility with Docker or at least their own Red Hat Docker until they could bring their software up to speed.

We did the implementation ourselves. The documentation is pretty good.

I save at least a few hours weekly using Red Hat Enterprise Linux (RHEL). 

We got the license through a third party. They buy licenses in bulk for us. We pay them, and they handle the licensing.

Moreover, Red Hat's pricing and licensing structure seems fine. There's not a huge separation. The licenses can cover everything without worrying about the core count, socket count, or similar complexities like VMware and other big companies. It's simple enough to figure out which support contract you want based on the level of support you need.

It's an open source product.

Overall, I would rate the product an eight out of ten. The product is good, and the documentation is really comprehensive. The support is satisfactory as well. Based solely on the product itself, without considering support, we find it stable and capable of supporting various architectures. The documentation is particularly good and stands out. It provides valuable resources, including bug fixes, to people with developer accounts, which are free. Having all that information available is very helpful and resourceful, especially when troubleshooting Linux-related issues.

The documentation is very good, making it easier to troubleshoot any peculiar Linux-related problems.

We use Red Hat Enterprise Linux as the operating system for our databases and application servers. We also use Red Hat Enterprise Linux to create some of our applications, such as the Online Challenge system. I work for a telecommunications company, and we have a few other operating systems in use, such as Unix and AIX, but Red Hat Enterprise Linux is our primary operating system.

We deploy Red Hat Enterprise Linux on-premises and in the cloud. For the cloud, we use Azure and Huawei.

We work with virtual servers, so we have the image ready to deploy. It's great because the patch is always updated and we have no problems.

Red Hat Insights has helped us avoid emergencies in unpatched systems by identifying bugs so that we can fix them.

Red Hat Insights provides us with vulnerability alerts and targeted guidance, which helps prevent downtime and increases our uptime to 99 percent. 

The most valuable feature is the security insight and the internal firewall, which are common in all the machine tests that we use a lot. The terminal framework and security are all Linux.

I believe this is because we don't have access to package management software. As a developer, I would like to have access to this software so that I can install the tools that I need. Currently, we are restricted to installing software only with permission from the system administrator. This is time-consuming and inefficient, as we have to follow a process to request permission. I believe that having access to package management software would improve our productivity and efficiency.

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

Red Hat Enterprise Linux is extremely stable.

Red Hat Enterprise Linux's scalability is good because of virtualization. With virtualization, we can request more space or memory processing without having to make any changes to our system. This makes the process of scaling up or down very straightforward.

The technical support is great but nothing is perfect.

Positive

I previously used Ubuntu Linux and SUSE Linux Enterprise. I switched to Red Hat Enterprise Linux because it has better support. I haven't tried the others, but Red Hat looks like it has better support. However, Ubuntu is more compatible with desktop development, making it more user-friendly.

As a developer, I find the initial setup to be easy. Deployment takes a few hours, but I understand the server, so it is not a problem. I do not actually do the deployment; the infrastructure team handles that. They made the process easier and faster, and on average, deployment now takes around four to six hours.

We purchased our license from ITM, our local provider.

I give Red Hat Enterprise Linux a nine out of ten.

I make the applications compatible with the cloud so we can migrate the data.

The knowledge base offered by Red Hat Enterprise Linux is good, but I don't use it much because the infrastructure team manages issues with the OS. I only check the documentation when an application is not working as expected. 

We've implemented OpenShift on top of OpenStack. It's a Red Hat OpenStack environment, which is the virtualization layer, and then OpenShift is for the cloud technologies.

It's currently on-prem on a private cloud. In the future, we might utilize a public cloud if the government approves that. Currently, the banking industry isn't allowed to go to the public cloud.

There is a big move towards digital banking. They prefer to have their solution up and running as soon as possible when the request comes in. They have to have the libraries and all the containers up and running. In a couple of minutes or seconds, they have their whole infrastructure up and running.

With regard to security, most companies are moving towards the black box approach and Red Hat. It's much more secure compared to the other vendors.

There's consistency, and it's resilient as well.

With regards to OpenShift, everything is related to cost. If you need a vanilla OS, you have to spend a lot on the licensing that is tagged. You have to spend on the infrastructure and the licensing on a core basis, and whatever is required on your containers, you just have to give minimum hardware specs.

Red Hat Enterprise Virtualization isn't up to the mark as compared to VMware and Hyper-V, but they're moving everything on OpenShift for containers and virtual machines, which is stable. If you go into the virtualization layer, they still need to improve a lot of things, but with regards to OpenShift, containers, Docker, and other things, they are doing well. 

We've been using it for three to four years.

Compared to Windows and other operating systems that I've used, it's stable. 

I'd rate it a nine out of ten in terms of scalability. We have plans to increase its usage in the future. Our infrastructure will be able to scale. We have a plan to grow it every three years.

Their support is very good. Most of the things are already listed in their knowledge base. Support cases are only raised when you end up with any critical situation. I'd rate their support a nine out of ten.

Positive

We've used Windows, Solaris, and AIX. The reason for switching to it was that everything is moving to the black box. People want everything to be secured. We got a lot of updates on Red Hat, and it was doing very well in the market.

It was very straightforward. When we did the proof of concept, we had everything ready within two or three days, and then the engineers who came to deploy it did it in a day's time once we had all the infrastructure up and running. This was just for the proof of concept.

With regard to the implementation, they had a timeline, and they did deliver before the timeline.

It has been deployed on Nutanix as well. They are present even in the marketplace for AWS. It's a straightforward installation. They have two categories: UPI and IPI, and the installations are very straightforward, but it requires a lot of expertise if you want to deploy it on a public cloud.

It was implemented by Red Hat. In terms of maintenance, it does require maintenance, but once it is highly available, it's easily done.

We've seen an ROI. It has had cost benefits. 

It has saved us money. We did a proof of concept with the VMware Cloud Foundation and OpenShift. We saw the feasibility and how fast it can be deployed. There were a lot of considerations. We evaluated it from all perspectives. Compared to the VMware Cloud Foundation, we noted that it was just 50% of the cost. If you go for VMware, they charge you on a core basis, and the licensing costs are huge. You'll have to spend on Microsoft licensing, and then you'll have to spend on the OS as well. Comparatively, it's much cheaper.

We purchased it directly from Red Hat. Compared to open source, it's very pricey, but you get the support, which makes it much better.

You have to deploy it and evaluate it. You can see that there's a lot of difference compared to other operating systems. It also depends on where exactly you're going. There are mainframes and other different places where you can deploy it. Even on the mainframe, it makes a lot of difference.

With Red Hat, there are a couple of things you need to consider while building your infrastructure. You need to have good hardware, and you need to have a compatibility matrix to be able to have a stable environment. It has to be tested in a proper way, rather than deploying it on any box.

In terms of the golden images created by the image builder tool, we have vendors who come with their solutions. They come with the containers, and they deploy them. Most of them are using GitHub, and we just provide the infrastructure. From a technical perspective, there's a solutions department that's into APIs. They handle everything, and we just provide the infrastructure.

Overall, I'd rate it an eight out of ten.