Red Hat Enterprise Linux (RHEL) Reviews

I use the solution for research purposes. 

The solution provides more detailed control. 

The product's built-in security features when it comes to simplifying risk reduction and maintaining compliance can be a tedious topic. It varies from user to user, however, it offers a lot of rapid releases. It helps us to simplify risk reduction and maintain compliance.

The portability of applications and containers built on the product when it comes to keeping your organization agile is good. It's easy to use.

It enhances our security. It helps us comply with company regulations.

When it comes to ensuring availability across physical virtual and cloud infrastructure, it's been okay so far.

It helped us to avoid emergencies due to security issues.

I consider the solution to be sufficient. I do not use it too much and therefore do not see any underlying problems with the solution. 

It's sufficient and it doesn't need new features. However, as new technologies enter the market, I hope they will keep up with the changing market.

From a product point of view, it's very efficient for servers. However, the solution is complex in terms of its architecture. It could be simplified. I'd like to see them introduce PDFs or documents to better explain technicalities to new users. 

Memorizing commands can be a bit tedious.

I've been using the solution for two years. 

The product has been stable so far. 

The solution is deployed to the data center, which is managed only by a few teams. 

About 150 people are using the solution. We also have 45 to 50 administrators as they are managing different areas.

The solution is scalable. However, I'm not sure if we plan to scale further in the future.

I have not interacted with support very much. 

I was involved in the deployment. The initial setup was very straightforward.

The deployment is fast and the process is efficient. 

I did a lot of the implementation myself. 

I did not evaluate other options. 

I'd rate the solution an eight out of ten. 

I'd advise new users to learn from someone who has done everything before. It's much easier than trying to learn by yourself from scratch. They should also have their own environment for testing. 

We prefer Red Hat Enterprise Linux as our operating system due to its excellent support. If a business wants something, we deliver it and we prefer a Red Hat Enterprise Linux-based system because of the support. It can be a simple application to a big system. It doesn't have pre-defined roles. It's a go-to operating system. 

Our use cases for it vary from plain operating system management to handling specific tasks such as running Oracle databases or other similar applications. They include quite a broad spectrum of requirements. Also, they are not limited to predefined roles but encompass the entire operating system infrastructure.

The solution's SELinux feature is a gold standard for security. It also has the best ecosystem. 

In addition, its automation platform, ITM, is a good product and works well for us.

Some of the solution's features need to be automated. We encounter the hassle of registering the system and attaching a subscription. Our company has development teams, and we have to develop subscriptions for them. Here, having the solution up and running on the developers' machines is a bit of a hurdle. Although we can run it on platforms like Red Hat Connect but, it needs to be somewhat more accessible so developers can just download it and start with the work.

I have been using the solution for 10-15 years.

The solution is stable.

The solution is scalable when combined with automation features. I rate its scalability a nine.

The solution's customer service is good.

Positive

I have used Ubuntu, Fedora, CentOS, and macOS. Initially, I worked as a Red Hat Certified Administrator in RHEL 5. Later, I began to work for its partner company. That is how I switched to the solution. It was not a conscious choice. It just evolved that way.

The solution's initial setup process is straightforward. You have to follow the steps, copy the template and multiply it.

The solution's price is reasonable. If you have a license for the support, they provide excellent services. The support team is always available for help in case of errors or system downtime issues.

RHEL’s built-in security features for simplifying risk reduction and maintaining compliance are good. If you keep SELinux on, it is all good. If you have a system with SELinux off for a long time, it could get you in trouble. The system will make many changes, like restoring files could break your application later. In case you resolve the problems simultaneously, it is fine. 

The troubleshooting feature of Red Hat is excellent. It can solve many issues on the machine right away. In addition, if you have an external scene, then Red Hat Insights is on. I sometimes go to this feature to see its status and what is happening. 

I don't do this on a daily basis and only check it every two weeks, but it's nice to have. I mainly oversee the high-level view of all the systems. This way, I know if the clients' machines need a patch system. 

There are some missing modules for SELinux in Ansible, like the playbook. It becomes a genuine hurdle to manipulate SELinux at the moment. I have to go to the machine, take a file to the repository, and deploy it.

I rate the solution a nine out of ten.

We use the product to host operating systems, applications, or infrastructure for our customers. Our customers use the product as a long-term solution that they don't have to upgrade every other year. They can get people that know the solution from the get-go.

The biggest feature is the longevity of the distribution. Compared to any other product, Red Hat Enterprise Linux provides a stable backported solution for a long time. It is important because we have moved a lot of software containers. We want to update it but don't want to unless we have to. So it's great to have something stable for a long time.

The biggest thing that the solution could introduce is an even slimmer version of Red Hat Enterprise Linux. We are moving to containers, but we also have a lot of void loads that don't go into containers. It would be nice to have an even thinner operating system. Even if you choose minimally, you still get a lot of useless stuff you don't need.

I have been using the solution for 20 years.

I rate the product’s stability a nine out of ten.

I rate the solution’s scalability a seven out of ten.

It's really difficult to get to someone that knows something. When you get to the right people, support is really good. But there are a lot of people that can only answer first-level questions.

Neutral

We're using a lot of different OSs. We use Red Hat Enterprise Linux because we are a partner.

It's pretty simple to install the product. However, some tools required to install it are missing.

The pricing is great for virtual systems. The pricing for physical systems is way too high.

The overall costs depend on the project and the company.

We continuously evaluate other options. The main difference between Red Hat Enterprise Linux and other solutions is the complete ecosystem's longevity and possibility. Other products may present something similar, but they don't have the ecosystem around them.

We probably purchased the solution from a cloud provider. We are using versions 5 to 9 currently.

The solution’s built-in security features are pretty good, but it's not something that I would take as a major selling point. The portability is good because we have a stable baseline for applications and containers. Red Hat Enterprise Linux’s security posture is pretty good. I don’t know if it's the strongest selling point, but it's up there.

In some ways, Red Hat Enterprise Linux enables us to centralize development. However, that's not mostly what we focus on. The primary output from Red Hat Insights is targeted guidance. Targeted guidance has not affected our uptime much.

It makes sense to go with a stable distribution compared to others. Overall, I rate the product an eight out of ten.

We installed the product at a very large hospital as their underlying operating system for Kubernetes, but it is not OpenShift. We use it for one-off servers and lab machines.

Copious documentation is probably the best feature of the solution. If you have a lot of high-quality documentation in one location, it is easier to search and get exactly what you need. It's more efficient when I get stuck on a problem or need help configuring something. It saves us time searching through Google or looking through GitHub Issues to solve the problems. It is a top-notch solution.

If the solution were easier to use and understand, it would not get disabled as often as it does. The solution should be made more secure. The changes made to CentOS make it hard for somebody to spin up and test it without having a preexisting relationship and license. 

If somebody wants to get something going quickly and is trying to settle on Red Hat, they don't have a free version to go to. Ubuntu and SUSE provide such platforms to the users. It is one Achilles heel in Red Hat at the moment. 

Even if Red Hat would enable a full version trial for people to test it, it would be less than what others are doing. Others are giving it away for free until you actually need support, and then you can choose if you need to buy it. With SUSE you can install it with SUSE Leap. It's pretty much the same thing. When you want support, you must enable support, and it becomes SLES.

There's nothing in Red Hat where I can run along on the free version for as long as I need to, and then when I want support, activate support on the same product. I have to reinstall it if I want Red Hat. Even with CentOS, it still wasn't possible to just activate it for Red Hat and make it become Red Hat Enterprise Linux. That's been something that's long been lacking in the product.

I have been using the solution since 1996 or 1997.

I have no complaints at all about the stability of the product.

As time goes on, the solution gets better. It adopts new features. I would say that it does a pretty good job.

The few times that I've encountered support, it was great. I don't really go through support channels. However, when I reach out and ask a question to the people I know in support, I get answers pretty quickly. I find that they have a good deal of product knowledge.

Positive

When I first started using the product in the 90s, it was just Red Hat. So I used Red Hat, and I used IBM Slack. I've used quite a number of different Linux distributions. Red Hat Enterprise Linux has been around longer than Ubuntu. I still use other solutions along with Red Hat Enterprise Linux.

Typically, the initial setup is pretty straightforward. If it's virtualization, it is really easy because we have an image already, or we can create one. We can use Kickstart. I used to run a 5000-node HPC cluster in the early 2000s based on Red Hat Enterprise Linux. We used a combination of SystemImager and Kickstart for it.

It's the default posture of a lot of the third-party vendors that you should just disable and leave them off. With containerization being prevalent everywhere, portability is across the board. Red Hat Enterprise Linux adopted Podman as opposed to Docker. Podman is a good tool, and I like it. Red Hat Enterprise Linux is the standard on which many others have based their platforms.

Using SELinux is largely misunderstood. If used properly, it provides a great platform for us. Red Hat is a big corporation, and we have people we can reach out and talk to. The same goes for SUSE. For Ubuntu, I have always gone straight to NVIDIA for support. I personally don't know of any great differentiators between all the products. I know Red Hat. It's been around longer, and I've had a long history that makes me comfortable. 

I wouldn’t recommend one over the other. It would come down to the use case. If someone wants Kubernetes on-prem, I would probably guide them toward OpenShift. I do have customers that don't run OpenShift on-prem. I often find that the customers already have a preference because they already have a license. So it's never really a decision that falls on me.

Red Hat Enterprise Linux uses firewalls, so configuring a firewall is easy. I have deployed the solution in multiple places. Overall, I rate the product an eight out of ten.

We use it to host applications, services, and backend databases. We aren't using it on the cloud. Most of my customers are DoD or some type of government agency. If it's not classified, it's siloed in some way. We don't get to use a lot of the functionality that makes Red Hat cool. It's all disconnected.

In terms of version, currently, mostly everything is on versions 7 and 8. I've started pulling up some of the things from version 9, but that won't go into production for a while.

We use it because it's stable. That's half the reason, and the other half is because the DoD standardizes on it because it has a support contract, so even though we're forced to use it, it's a very good product, and it's on-prem. We probably would use it anyway.

We needed to host applications, services, and backend databases. We have a lot of Java-based applications, and we wanted something that we could deploy in different places around the world and that everybody standardized. Windows didn't really work for us on that. Most of the time, we're not connected to the Internet. We find that Red Hat or Linux in general works a little bit better for us than macOS or Windows.

It's also across the board a little bit cheaper for what we're using it for. That's a benefit we're getting from it.

We get our compliance from DISA, which is the defense information service agency. They put out security technical implementation guides. There are specific ones for Red Hat Enterprise Linux 7 and 8. The reason we're not using Red Hat Enterprise Linux 9 is that there isn't one for it yet. In terms of how we harden the operating system we're using, it's whatever they tell us to do and then whatever extra we want to do. It's as good as any other Linux other than the fact that it's supported by the DoD. For example, SELinux helps us secure across the board with contacts across different directories and things like that. They tell us how standardized the SD-WAN layout should be. We're able to go a little bit deeper into that. Red Hat uses Podman, which has SELinux, and which by default helps us a lot. 

We run Satellite on a lot of these, so having a central repository that we can use for patch management and remote execution is huge. That's something that is very difficult in a Windows environment. We're very compliance driven, so to have that built into Red Hat is easy. We don't need an agent or anything like that to get a lot of work done, so Satellite and centralized automation are the most valuable features for us. We're dabbling into Ansible but not as much as we should be.

It's obviously a security-focused operating system versus some of the other operating systems that lay you down in the terminal as root. In Red Hat Enterprise Linux 9, you can't even root. It's disabled by default now. Overall, they are definitely more security conscious, and that's also because of their primary customer space.

I've been using it for ten years or so. I've been using the solution since version 6. 

The stability of what we have deployed is good. The only time it crashes is if we do something or we try to configure a control that one of the engineers doesn't fully understand, which then breaks it. A lot of it's just like us breaking it ourselves or a customer asking for something that wasn't initially planned. Just pure deployment is good.

Its scalability is good. It's what they excel at. If we have 10 machines or 100 machines, they have the platforms to scale that up.

Overall, the customer support is good. It's better than Microsoft support. They are above and beyond that. They are better than others in terms of response time, getting somebody who knows what they're talking about, and not spinning their wheel. Usually, within the first response or two, people figure out what we're trying to troubleshoot here. We're not going from one queue to another queue or anything like that.

I'd rate them a ten out of ten. I've never had an issue with it. 

Positive

We had CentOS systems. When they changed upstream, we had to pivot some systems. We pivot some systems to Oracle Enterprise Linux, but then those eventually got transitioned to Red Hat as well.

The main reason for the switch to Red Hat was for the government customer and having a support contract. You can do Oracle Enterprise Linux without a support contract, but if you're going to buy one, you might as well get Red Hat at that point for the added benefits.

We use Kali for a couple of other use cases, and we probably won't replace it with Red Hat.

We've used a lot of flavors of Linux. One thing that sticks out for me, even in just the home lab environment or deploying at work, is that if there's some backward thing that we weren't planning on going into, if I look for a solution, nine out of ten times, I'm going to find an article on Red Hat's website where somebody has either a verified solution or somebody is talking about it and there are comments that are relevant. I hate going on ServerStack, Ubuntu Stack, or something like that, where somebody has the exact problem that you have, but there are no comments and no answers. I find that to be less true with the Red Hat platform.

The initial setup is pretty straightforward but can be tedious at times because of the compliance things that we have to implement. 

I just sat in on the training or the demo for the deployment platform, and we're already planning on setting up the Ansible automation platform where we also want to look into setting up this deployment tool because we do a lot of ISOs. We do a lot of kickstarts. We don't do any of the cloud tenants. We probably will switch to using the on-premise disconnected deployment capability because we can preconfigure everything and then run Ansible after the fact to get it all compliant.

We're the integrators or implementors of the solution.

We're forced to buy the licensing, but it's also good. I and a couple of other staff members are all Red Hat certified engineers, and then we all have our own specialties, so we don't call them a lot, but when we submit tickets, it's definitely worth it.

The ROI is mainly in terms of needing to recover from any system downtime. If we don't have an engineer on a computer doing a certain piece of research, then we're wasting money or just not generating a product, so to have the support that we can call and then reach out to us in enough turnaround time holds value for us.

The pricing is fair. The workstation licensing cost is fair. If you're running enterprise-level deployments, depending on what you're using, the volume licensing is good. I personally am worried that if they get so successful, they can increase the price, and then it won't matter because we'll be stuck on them. Hopefully, their open source mentality keeps that from happening. Where it's right now is good.

In terms of the portability of applications and containers built on Red Hat Enterprise Linux, I don't know how much that applies to us. In our case, someone develops an application in a Podman container, and we ingest that and run it, but we're not doing much more than that. So, all of the Java-based applications that we run, are run within a couple of different containers, and that's about it.

I personally use Red Hat Insights in my home lab. We can't dial out for that for a lot of customer-based work, but I personally use it. It hasn't helped avoid any emergencies because it's super low risk for what I'm using it for, but I can see the benefit of it. In a more enterprise setup, such as health care where I used to work, things probably would have been interconnected, and we would have been using Insights, but we're not using it currently.

Overall, I'd rate Red Hat Enterprise Linux a 10 out of 10. 

We run various application servers. We have application servers for Java and Python. We also run Postgres and different applications. We have Kubernetes, Docker, Docker Swarm, etc. We have a wide variety. 

We weren't trying to solve a particular problem by implementing Red Hat Enterprise Linux. We've used Red Hat Enterprise Linux for so long. We used to modify the Kernel in the early versions of Red Hat, but that's not needed anymore. We are currently using versions 7, 8, and 9. 

Red Hat Enterprise Linux has enabled us to centralize development in our hybrid cloud environment because the containers can be migrated from Red Hat Enterprise Linux to AWS. It's not an issue. There is also a Red Hat-supported programming tool called Skupper, which is a layer seven service. It's an open source product. It's supported by Red Hat, so we could use that to migrate our containers back and forth on the cloud and on-prem, which is very much needed.

Red Hat is pretty good at containing risks. We have a firewall, but we also use iptables and SELinux. SELinux has proved to be very valuable. We have certain tools where when somebody tries to break SELinux, we immediately get alerts.

We don't have a problem with compliance. We also use Red Hat Satellite. Our Red Hat Satellite server is helpful in terms of meeting compliance requirements.

We're able to modify and migrate containers and redeploy containers very easily. We do that on the Red Hat platform. We do it with other tools such as VMware. Red Hat API works very well with other vendors, so that's definitely a plus. In terms of changes, for instance, if we want to connect to ServiceNow to create a ticket in Ansible, we're able to do that without any problems whatsoever. We can create a ticket in ServiceNow. We can remediate it, and we can close the ticket on ServiceNow from Ansible. Ansible is a big part of Red Hat.

It's a rock-solid operating system. We don't need anything fancy from the operating system itself. What we need is something that doesn't crash, stays up to date, and provides the security features that we need to keep external players out.

The CVEs that come out for the vulnerabilities are very fast. We try to do patching in different tiers. Our regular patching happens once every ninety days, and then we have special iterations that need to be done, and those are on demand, or if there's a high-security risk and it's absolutely immediate.

The other thing that we like about Red Hat is the support for open source. That for us is a slam dunk.

They should work more on container documentation. The only issue that we have is that Red Hat specifically promotes OpenStack, and we don't use OpenStack. It's good if you're using OpenStack, but if you're not using OpenStack, and you're using Docker or something else, it isn't that good. Having more support for non-OpenStack would be very helpful, but, of course, as part of their business, we don't expect it.

I've been working with Red Hat Enterprise Linux for many years.

It's very stable.

It scales very well. We have about a thousand servers, but we could scale to five thousand servers without a problem.

Their support is good overall. It's better than some of the other vendors. The staff is very friendly. The people I've met hear and discuss issues. We're very much interested in open source, so we use a lot of open source. The engineers have been extremely helpful. 

I'd rate them an eight out of ten. I'm not giving them a ten. Some of it has to do with the time cycle, and some of it has to do with different levels of quality with the support. You could get a junior support person, and obviously, that's going to be a very different experience.

The knowledge base offered by Red Hat is very good.

Positive

Our environment is hybrid. Most of our Red Hat Enterprise Linux is on-prem. For the cloud, AWS is the cloud provider, but we are using a different distro for AWS. We use AWS Linux for that. For on-prem servers, we're strictly using Red Hat Enterprise Linux. For desktops, we use Fedora.

The reason for using AWS Linux is that we only have AWS. If we use multi-cloud, for instance, if we use Azure and AWS clouds together, we would definitely need something other than AWS Linux. AWS Linux is very solid too, and our team likes it. We can download the AWS Linux version for on-premises too. I've done that. I tested it, but we're sticking with Red Hat Enterprise Linux.

In the server space, nothing comes close to Red Hat Enterprise Linux. I know that Ubuntu is making a big push, and some people have gone ahead and migrated to Ubuntu, but I think those are going to migrate back. There's just no comparability. They're different. They're like cousins. They're very similar in some ways, but they're very different things. You can install SELinux on Ubuntu, but why bother and why go through the whole configuration? Red Hat Enterprise Linux is more suitable for servers.

We use certain tools from HashiCorp, such as Packer, so deploying it is very simple. We have a script that runs every night, and it creates via the CI, goes up to GitLab, gets whatever it needs, such as parameters, and sends it to Packer. Packer grabs the ISO, and it creates a very specific, customized deployment. It's done with a couple of right clicks. That's it.

We've absolutely seen an ROI. It's in terms of reliability, stability, security, and usability. You name it. The use cases are out there.

The licensing structure is very convoluted. It's very confusing. We have a Satellite server, and we license it through the Satellite server, but if we didn't, we'd have to buy individual Red Hat licenses. That would be a nightmare to maintain in terms of renewing it every year and things like that. 

Overall, I'd rate Red Hat Enterprise Linux a nine out of ten.

Primarily, we use it for a couple of different servers. Some are doing data hosting, and some are doing network management-type functions.

We use it on-premises. We do not use it on the cloud. Because of government work, we're not cloud-based.

By implementing Red Hat Enterprise Linux, we were mainly looking for stability. By having a lot of open source solutions, we ran into problems where there were too many flavors and too many variables. We ran into issues with ISO and other things where this particular site was a one-off from this site, which was a one-off from this site, which was one-off from this site. That became a problem for making sure that we stick to a consistent level and patch to a consistent level across the board.

The portability of applications and containers built on Red Hat Enterprise Linux has been good. We do a lot of containerization and a lot of microservices. It has worked really well. It helped in keeping our organization agile. Our partners provided us with a lot of quick utilities and reuse of things. We can shut down a container and spin up a new container to introduce new capability quicker. 

The biggest feature that I have found valuable is stability. 

The way it lent itself to automation has been very invaluable for us. It makes the setups a lot more consistent and repeatable across the board. We're able to deploy the product quickly in a very consistent manner, which meets our timelines. A lot of what we do has very short spending dates, and they need a lot of product work.

It has been pretty good for us. I have no complaints as such. We just learned that we can get access to more support documents by going through the portal. I didn't know that. If it was something that was more known or advertised, that would have helped us to find out some of the information a little better.

I have been using Red Hat Enterprise Linux for about a couple of years.

It's a 10 out of 10 in terms of stability.

It's a 10 out of 10 in terms of scalability.

The customer service is good. There is a lot of support documentation out there for anything you're looking for.

Positive

We tried quite a few flavors of different things, but nothing provided the consistency that we are getting with Red Hat Enterprise Linux. We tried everything such as Ubuntu, Mint, etc.

Red Hat Enterprise Linux stood out for its consistency and stability. We had several different problems with drivers on Mint. There were so many different flavors. We had one developer who built everything on one, and then another developer built on another, and none of that was coming together. It was not meshing, so we finally went to a common platform with stability and supportability. It was a lot better. It has allowed the developers to focus more on their code rather than having to worry about fighting the underlying things, such as drivers aren't on this one, and that one is not working.

It was very straightforward. We've pushed in further to make our own ISOs, so we're making sure that everything is getting the same applications and everything is deployed across the board, and we are able to virtualize in some cases. It has been good.

You definitely get what you're paying for. From what we've seen, it has been great. It has also allowed virtualization and making their own ISOs. We're able to package all that up, and it has worked consistently and repeatability. We've written our own Bash scripts so that we can automatically deploy that and stick it as part of the build. We're saving a lot of time and getting to a common platform repeatedly.

Overall, I'd rate it a nine out of 10. There's always room for a little bit of improvement.

There are multiple use cases, and I am mostly focused on information security. Before we promote an ACS policy to production, we should be able to test that build and see how that policy behaves for that build. We use Podman to build some test images and get them to our development box. Then we use commands that we scan against those images. That has been one of the major use cases. 

In the future, we'll move our automation program from an on-premises Windows server to a Linux server. Over a period of time, we want to move those applications to the cloud and OpenShift. Currently, we have many legacy applications that are still being run on Windows Server, and we use the title job scheduler for that. Once we mature and gain more confidence, we want to containerize those applications and move them to OpenShift and Linux.

Red Hat Enterprise Linux's most valuable features are the Podman and a lot of packages that come inbuilt as part of the regular package. Podman gives you the opportunity to build those images. Since it's a public registry, you cannot pull those images from a docker, and proxy blocks that. If we know how to recreate that scenario, we use Podman to recreate that image.

Red Hat Enterprise Linux should provide more training because many people are not very familiar with Linux's user interface. If it is made very similar to Windows and people can relate to it, they would be more comfortable.

I have been using Red Hat Enterprise Linux for seven to eight years.

Red Hat Enterprise Linux is a stable solution.

I have experience interacting with Red Hat support for ACS. The initial level of support is very minimal. They try to collect all the data, then go to developers or technical people, which usually takes time. So we don't get an immediate response. Hence, there is scope for improvement in Red Hat Enterprise Linux's customer support.

Raising a ticket and having somebody look into it takes time. I rate raising a ticket and addressing it a six to seven out of ten. However, we interact with a responsive relationship manager, who escalates and gets issues fixed. I rate this relationship manager an eight out of ten.

Neutral

Since we have the capability to test vulnerable images, we know much in advance what their impact will be. We can test ACS policies against those vulnerable images. That gives us early visibility instead of deploying that application and finding what is happening there. Using Red Hat Enterprise Linux and all associated components gives us that visibility into vulnerable images, and we can set policies based on whatever we see. So in terms of business impact, we avoid many vulnerabilities that get into the production.

We run some applications on the cloud, but they are not business-critical applications. We run all business-critical applications on-premises. We are not dependent on the cloud for business-critical applications. We are not locked with the vendor.

We use Qualys to scan the underlying node. We expect any critical vulnerabilities to be patched as early as possible. We have an enterprise policy wherein any business-critical vulnerabilities seen on business-critical applications or nodes need to be fixed within 30 days. If some running application is exposed to the internet, we want that to be prioritized. If vendors can prioritize a 30-day life cycle for critical vulnerabilities, that would really help many other organizations.

Red Hat Enterprise Linux is the only option we are currently looking at. We don't want to go with Windows. We already have this ecosystem where we use OpenShift, and it's already integrated with ACS. So we would not like to go with any other different OS. Red Hat Enterprise Linux will integrate easily with the entire ecosystem.

Overall, I rate Red Hat Enterprise Linux an eight out of ten.