Red Hat Enterprise Linux (RHEL) Reviews

Our primary use case is that we use it for transaction servers.

We have it on-premises, mostly virtualized.

RHEL helps speed up our deployments. We don't use things like Kickstart and Satellite for deployments, because we usually just clone systems. But the ability to script customizations during deployments is particularly useful for us. It enables us to tailor each machine the way it needs to be.

We use RHEL to run multiple versions of the same application or database on a specific operating system and its features for managing them, things like Satellite and Insights, make management of multiple versions of an application server much simpler.

We use Red Hat Insights to monitor the systems and it is a godsend. It's like having an extra person on staff. Insights is a constantly updated database of CVEs and configuration best practices. It checks everything in the environment to make sure that it is patched, up-to-date, configured properly, and using industry best practices. When you look at the Insights control panel, you know either that everything is good or, if you have an issue, you know exactly where to look and how to fix it. Nine times out of ten, it even gives you an automation script to fix it automatically.

Other than Satellite, we also use Red Hat Ansible, but not Ansible Tower. They integrate very well with RHEL. They're tooled for integrating with it and they do that well. That integrated approach makes my life much easier. The primary function we use Satellite for is patching. Having something that's built to manage application environments and make sure that everything is patched correctly to use Ansible, plugs into everything else, including Satellite. You can use it to manage RHEL, Satellite, and other things, such as Windows and networking equipment. The tightest integration is with Red Hat.

RHEL enables us to deploy applications and emerging workloads across bare-metal and virtualized environments and I find those workloads to be extremely reliable. The reliability is so good that I rarely find myself calling Red Hat support any longer. Support is the first benefit of using RHEL, but the second thing is that the platform is so stable that the need to use support is negligible.

There is potential for improvement when it comes to ease of use. It has become easier to use over the years but could be better still. Linux, in general, has never been a simple solution. It's usually a more complex solution than something like Windows. If there is a downside, it's that it is more complex than some of the other solutions.

I've been using Red Hat Enterprise Linux (RHEL) for about 10 years.

One of its most valuable features is its stability and reliability.

We have applications that we've scaled quite significantly, with over a dozen servers running the same application, load-balanced, and RHEL scales quite well.

We have an installation of about 200 servers and about another 800 servers in our SaaS environment. We're looking to grow the environment where it makes sense. I like to take the approach of considering the appropriate tool for the job. We are primarily a Windows shop, but often the right tool for the job is Red Hat. That's where we would grow our environment, where it's appropriate and the right tool for the job.

Our engagements with RHEL support are usually good. It's been a while since I've had to contact them, but they're good even when it's a significant issue that takes time. They don't even have any problems moving issues around through time zones and having support work on them around the world.

Positive

The initial setup of RHEL is very straightforward. It's all menu-driven and most of the time there are only a few answers that need to be given during the setup procedure to get a system up and fully running in a few minutes.

We can get a system up and running in about 15 or 20 minutes if we need to. We can do a custom build and use the full build process, or sometimes we do virtual cloning and then just run scripts to individualize the machines.

RHEL's single subscription and install repository for all types of systems may be a bit of a stumbling point. It seems that the descriptions of the subscriptions change every year or two and it gets a little complicated. And the naming conventions they use in the subscriptions can be a little complicated.

As for maintenance and administration of RHEL, there are just two people in our organization who handle that, me and another engineer.

The prices are comparable, and good for what is being provided.

RHEL is certainly more difficult to use than Windows, but it requires fewer hardware resources than Windows and, in my experience, it has also been more robust.

The fact that RHEL is an open-source solution isn't a concern, directly. Where it might be a factor would be when we're looking at using a tool for a particular need and we're looking for the best platform for it. That's the biggest factor.

Make sure that you have well-trained engineers who are familiar with RHEL. If you are looking for a solution that runs in a mission-critical environment, you always want a supported solution. If you're looking for Linux, I don't think that there's a better-supported solution than RHEL.

In our particular scenario, our underlying infrastructure is either VMware virtualized or bare metal, although the latter was mostly in the past. Rolling out to a virtualized solution or rolling out to bare metal with RHEL—with the exception of the bits that are unique to those platforms—the operating system installation and the like are going to be very similar.

Overall, RHEL is a very solid solution.

It's the operating system for different applications we have that are related to telecommunications such as VoIP, DNS, and many others including identity management.

We are using it based on virtualization, including VMware, Red Hat Virtualization, and we have some OpenShift Virtualization.

RHEL has improved things a lot when it comes to automation. Creating a virtual machine was not an issue, but when it comes to the post-configuration of the workload, the solution has made life way easier. For instance, we created an automation chain that creates a virtual machine from scratch right through until the post-configuration is done. We managed to group different applications in this one chain.

In terms of speeding deployment, we have playbooks that are supported by Red Hat, where we can automate deployment and configuration. That helps a lot, making things much faster. It has accelerated our deployment of cloud-based workloads because of the availability of the modules that help us to create playbooks for post-configuration. It's not only creating a VM but, after that, we still have to do the post-configuration manually; rather that's all automated now. Where post-configuration used to take one or two days, it now takes a couple of hours.

In addition, so far the applications are consistent, regardless of the infrastructure. That's especially true when you automate it. Even if you have an issue, the consistency of deployment helps a lot.

In addition to Red Hat Virtualization and Red Hat OpenShift, we use Red Hat Satellite. We decided to base our entire stack on Red Hat because most of the vendors we use want us to have our applications on the Red Hat operating system. With our whole stack on Red Hat, it makes communication easier because we aren't ping-ponged between different vendors. In addition, there is a good knowledge base for different Red Hat products. The integrated approach among Red Hat products has helped us in that when it comes to identity management, for instance, because we don't need to wonder if Microsoft will support this or not. It has also helped to automate patching as well.

The most valuable feature is the Identity Management. You pay almost the same subscription cost for normal RHEL and you get the central Identity Management. You would need to pay much more if you were using other applications or products like Active Directory from Microsoft.

It also enables you to deploy current applications and emerging workloads across bare-metal and private cloud, which are the only environments we have. The applications are very reliable, across these environments, with RHEL.

In addition, we use the solution for monitoring using the features like PCP and that is helpful indeed.

An area for improvement in RHEL has to do with security policies. I know they are doing something about this in RHEL 9, but I haven't worked with that version yet. When it comes to security policies in RHEL 8, it is a bit behind. It would be better if we could just enforce a certain security policy such as CIS Level 1. That was not available, out-of-the-box, in RHEL 8.

We have been using Red Hat Enterprise Linux (RHEL) since mid-2010.

If it works the first time, usually it will work forever. It's only when you patch that you need to do some regression testing to make sure that it's working.

We haven't had any issues with scalability at the OS level for years.

I'm very satisfied with the technical support for RHEL. They are helpful and knowledgeable. I don't have any complaints.

Positive

I used to have Ubuntu, but I didn't like it. The beauty of RHEL is that you can easily find support, unlike Ubuntu. While Ubuntu has free subscriptions, unlike RHEL, you cannot get support for Ubuntu easily.

With Ubuntu, when I had an issue, I would have to go to Stack Overflow and check the internet. With RHEL, I like that I can go to IRC and post my question and they answer me.

We are using Satellite, which is considered to be a subscription manager, in a way. In the beginning, it was complicated. Now, they have created something called Simple Content Access  (SCA). We buy a subscription for audit purposes and for legality to have a legitimate copy. On the other hand, Satellite itself issues subscriptions once you have a new OS system. That has made things way easier.

We used professional services back in 2009 or 2010. But once we found that every vendor was looking for Red Hat Enterprise Linux, we added that skill in our department and now we are doing everything ourselves.

Because it's a very stable solution, if you have the knowledge in-house, go for a regular subscription. Otherwise, buy the Premium Support.

We had some AppStream versions for different OSs, such as CentOS, but we decided to go for RHEL because it would make life easier in terms of lifecycle management. If we had RHEL and CentOS, it would make patching more complicated.

The biggest lesson I have learned with RHEL is don't complicate your design. You can always find an easier way to do things. Sometimes you'll think, "Oh, we can do this," and you start thinking about very complicated processes. It's better to think and start simple.

With RHEL, we have patching in place, automation in place, and we already know the support. We are very satisfied. We have done a lot of work on it and now it's easy to deploy VMs immediately. We are not looking to implement any other version of Linux.

We mainly use RPM-based systems to give our developers virtual machines.

The most valuable features of using RHEL for us are the standard way to run Linux and tools like NetworkManager. They make things easier for us.

I prefer a product that offers everything in a yearly subscription, like VMware, and I think RHEL should consider offering it as well.

I have been using RHEL for 15 years.

The scalability of the solution is good.

We use RHEL deployed in different zones, only on-premise, not in the cloud. Deploying RHEL depends on the end user, but migrations aren't usually a problem due to site forwards. The hardest part is dealing with end-user applications on the machines. We use Ansible for scripting, especially with Oracle. Sometimes, meeting the end of life for RHEL versions is tough, and we have had to buy extended support for RHE because some applications reached the end of life within a year. I appreciate the extended support option, though I prefer not to use it.

RHEL's pricing and licensing are quite expensive. For a big company, paying these fees might be manageable, but as a government organization, spending tax money on such expensive solutions is challenging, even though we do have the funds.

I see benefits in using RHEL because it offers stability and long-term support. Although we use both RHEL and Ubuntu, I have noticed that updates in Ubuntu can change things unexpectedly within a main release, which I don't like. That is why I focus on RHEL for its consistent and reliable updates.

RHEL's built-in security features are very good for risk reduction, business continuity, and maintaining compliance. We apply security guidelines in Linux using RHEL, which provides all the necessary baselines. We can choose and apply what we need directly to our RHEL systems.

I would say that open-source cloud-based operating systems like Debian are stable and have been around for a long time. There is a whole community supporting it, making it a strong alternative to RHEL with fewer licensing costs.

Overall, I would rate RHEL as a nine out of ten.

We are using Red Hat Enterprise Linux for running solutions, such as database solutions, and enterprise, web, and network applications.

One of the fundamental reasons Red Hat 7 has benefited our organization is that it is fully certified. It has certifications on the DISA STG and other cybersecurity frameworks like Zero Trust. This is what the Department of Defense mandates to be used and it is feasible to receive these specifications and automate the implementation for continuous improvement. By implementing the technical guides, we can receive immediate results and protect environments according to our expectations. There are a group of technical procedures that are shared and that you can implement, if you follow the industry best practices.

The most valuable features are the specification and technical guides, they are most important for cyber security assurance

The accessibility to the resources could be more widespread. The registration of the license information is complicated and this product registration process should be easier for customers to access.

In an upcoming release, they could improve by having more focused security.

I have been using Red Hat Enterprise Linux for more than 15 years.

The solution is highly stable.

Red Hat Enterprise Linux is perfectly scalable. You have some resource limits depending on how you're using the technologies. According to those usage patterns, the system is going to be able to give more or less. However, this depends more on the user side than on the system side.

We have approximately 10,000 enterprise users using the systems. They sporadically log into the applications and make use of the database systems and extract information. 

There is a division between the paid support and the support that is included by the website of Red Hat. I have only used the website support and there is a lot of documentation available.

Positive

I have used other Linux products, such as AWS Linux, Debian Linux, and Ubuntu.

The initial setup is straightforward for our use case. As long as you understand what you're doing, the technologies that are involved, the proper way to style, secure, and prepare them, everything will be fine.

After you have the guide, the printed procedure, the deployment is straightforward. The operating system can be deployed in less than an hour.

Okay, and how long did the deployment take?

The solution requires maintenance, and it is a shared responsibility. They take different maintenance actions or tasks, and sometimes it's the operating system, database system, or application front band that needs maintenance.

The number one advice would be to keep the division between testing and production.

There's one system that you need to set up for testing purposes only, and this testing system can be obtained free of license. There's an evaluation license that can be easily applied. When developing the application on the Red Hat 7 system, stay using the evaluation version until the requirements are fully met, only then should you migrate them to a paid supported version.

The biggest lesson that you learn by using this solution is, you easily reach a point where a single person or a single team can no longer respond to the complexities and challenges of the security or the different versions of the applications. At that moment you need to rely on a serious fused team, that team that is backing the effort.

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

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 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.

We use RHEL for database servers, a few of them run Oracle servers, and we are also using it for some of the network and infrastructure services.

The best operating system I've ever used is Red Hat, in terms of its ability and consistency of the operating system. Other than that, the vast majority of applications that I had, I could deploy those on Red Hat without much effort as it supported a vast majority of applications. I never faced any major issues with the OS, the support is also very good.

The most valuable features are:

• The stability and reliability of the OS itself
• Being open-source and leading the open-source market trends/ technologies
  
• The wide variety of applications we can deploy on Red Hat
• Their support 

I am a big fan of the OS and the user experience. They're very good. The OS is very stable and very good in performance as well.

RHEL enables us to deploy current applications and emerging workloads across all virtualized hybrid cloud and multi-cloud environments. It is one of the most stable OS that are available. 

We use RHEL to run multiple versions of the same applications and databases on a specific operating system. We have several deployments of database and a few of them are running on a bit older versions of Red Hat and some of them are running on newer versions. We are running different versions on different platforms. The management aspect is also very good, especially when we need updates on the different packages from the RH support network, management is easy.

We also use the tracing and monitoring tools to monitor OS as well as applications running on RHEL platform. The OpenShift is also a big plus through which you can manage and deploy enterprise-ready containerized workloads.

Being an advocate of open source technologies I always wished that Red Hat subscription/ support should be offered free of cost. Having said that, I understand the economics involved in running large enterprise like Red Hat; support cost is one area that can be improved. They should offer it at reduced prices.

I have been using RHEL since the start of my technical career, which was around the mid of 2003. So it's been almost 18+ years. I started using RH when it was version 7.

Stability has always been a plus for RHEL. 

Scalability is excellent. With the introduction of hybrid and multi-cloud support, one can scale up as well as scale out his workloads pretty easily. We usually scale up our traditional workloads when we need more resources i.e., during peak seasons. 

Four people in my team are responsible for deployment and support of Linux based workloads. 

We have around 300 virtual machines (VMs) and roughly 20% of them are running on Linux environment.

Whenever I open a case, I believe the support team will be able to solve my problem. They are very good at it. The documentation RHEL provides is also very good. Almost all the time, I get a solution to my problem. :)

We are using other flavors of Linux OSes, that include Oracle Enterprise Linux (OEL) and CentOS, both of which are binary compatible with RHEL. We are also using a couple of other Linux flavors like Ubuntu and OpenSUSE.

RHEL provides features that help speed our deployment. Installing on a physical server takes more time than installing it onto a virtual machine (VM).

Because of absence of local support in our part of the region, we did find some difficulties in the initial deployments with hardware vendors/ partners when we started in 2003. The local partners didn't have much knowledge of Linux environments at that time, and the support for hardware was also a bit tricky. The deployment took a couple of days until we got support from the hardware manufacturer.

Nowadays, it's very good. I managed to get good support from the hardware vendors after that incident.

We have our own deployment plans for the operating systems that include some baseline configurations and security checklists.

We usually deploy in-house as we have a trained team. Occasionally, little help is sought from the vendor teams, some of them have skilled professionals.

RHEL offers an efficient, cost-effective and reliable OS environment for enterprise-level environments. Similarly cost of running operations and the scalability factors make RHEL a good choice for providing a better ROI. The feature set it offers, support for a variety of applications, ease of deployment, and an excellent level of support all result in a good ROI. 

I believe for an enterprise-level operating system and the feature set RHEL offers, it's like any other enterprise platform cost. The introduction of OpenShift is also a big plus in terms of deployment and management of container based workloads. Red Hat as mentioned earlier can improve a bit on support/ subscription costs.

We had been using a couple of Red Hat variants for some scientific experiments that included Scientific Linux CERN (SLC) and Scientific Linux (SL), which were a confidence booster for choosing and deploying RHEL for production workloads.

Since I started with version RH 7, I believe the GUI is quite close to any other GUI operating system. There have always been a variety of tools and features that attract a non-Linux user.  As already mentioned, RHEL has been a pioneer in open-source technologies; it continued to evolve with changing market needs, that has been a big success for them.

I would definitely advise choosing RHEL if you need stability, scalability, and reliability of the OS platform. I would be a big advocate for the use of Red Hat to any new person who wants to deploy his production workloads, on-prem or on cloud on a Linux environment.

I would rate it a nine out of ten. It's near perfect. 

It started mostly with websites and open source environments overall for development. Now, we are moving into business applications as we are migrating our ERP, which is a cp -r tree, to Linux. We are also migrating the database of SAP to SAP HANA on Red Hat Enterprise Linux. 

We use RHEL versions 7 and 8. There is a bit of version 6 still lying around, but we are working on eradicating that. It is mostly RHEL Standard subscriptions, but there are a few Premium subscriptions, depending on how critical the applications are.

It has fulfilled all the promises or goals of different projects, not just because our internal team is strong, but also because our external partner is strong.

Satellite is an optional system which provides for extensive deployment and patch management. That is quite valuable.

We use Red Hat Enterprise Linux's tracing and monitoring tools. You don't leave them on all the time, as far as tracing is concerned. When you are sick and go to the doctor, that is when you use it, e.g., when an application is sick or things are really unexplainable. It gives you a good wealth of information. In regards to monitoring, we are using them to a point. We are using Insights and Insight Sender as well as the Performance Co-Pilot (PCP), which is more something we look at once in a while. 

Other Red Hat products integrate with Red Hat Enterprise Linux very well. In fact, they integrate with pretty much everything around the universe. We are doing API calls without even knowing what an API is, i.e., towards VMware vCenter as well as Centreon. There are certain individuals who use it for free without subscription and support for Ansible in our Telco group with great success.

Linux overall needs improvement. They cannot go much beyond what Linus Torvalds's kernel implementation can do. I come from AIX, and there were very cool things in AIX that I am missing dearly, e.g., being able to support not only adding, but also reducing memory and number of processors. That is not supported on Linux right now, and it is the same for the mainstream file systems supported by Red Hat. There is no way of reducing a file system or logical volume. Whereas, in AIX, it was a shoo-in. These are the little things where we can say, "Ah, we are missing AIX for that."

We are not loving our servers anymore. If we need them, we create them. When we don't need them, we delete them. That is what they are. They are just commodities. They are just a transient product.

I have been using it for nine years, since 2012.

The stability has been very good. However, there is a learning curve. We were running huge in-memory databases, about 2.5 terabytes of RAM, which is SAP HANA. Then, we were getting really weird problems, so we asked the app guys 20,000 times to open a ticket because we were seeing all kinds of weird timeouts and things like that on the OS side. We were saying, "It's the app. It takes forever." Finally, they said, "Oh yeah, we use a back-level thing that is buggy and creates a problem." It took us six months and four people to get that from the app guys. We were ready to kill them. That was not good. Whatever you put on Linux, make sure that you have somebody supporting it who is not dumb, or on any platform for that matter.

The scalability is six terabytes. That is what we're doing. We are printing HANA servers on that scale, which are more in the 2.5 terabyte range. However, we had to create one for the migration initiative on the VMware, which was six terabytes with 112 cores. It worked, and that was it. It also works with bare-metal, but you have to be aware there are challenges in regards to drivers and things.

RHEL provides features that help our speed deployment. For example, for SAP HANA, they have full-fledged support for failover clustering using Red Hat HA, which is a solution to create a vintage approach of failover clustering. They do provide extensive support for value-adds for ERP solutions.

They also provide value left, right, and center. Whenever we have a problem, they are always there. We have used both their professional services as well as their Technical Account Manager (TAM) services, which is a premium service to manage the different challenges that we have had within our business. They have always come through for us, and it is a great organization overall.

Their support is wonderful. They will go beyond what is supposed to be supported. For example, we had a ransomware attack. They went 20 times above what we were expecting of them, using software provided by them on a pro bono basis, meaning take it and do whatever you want with it, but it was not ours. That was a nice surprise. So, whenever we have needed them, they did not come with a bill. They came with support, listening, and solutions. That is what we expect of a partner, and that is what they are: a partner.

I, for one, was managing AIX, which is a legacy Unix, as my core competency. I still do because we haven't completed the migration. 

RHEL is a value-add right now. As we are migrating more payloads to containers, we are putting less Linux forethought into these container-hosting servers. You just shove your containers on top of them with your orchestrations. This may reduce our need to manage RHEL like a bunch of containers. That changes the business. 

We were paying for premium SUSE support for an initial pilot of SAP HANA on the IBM POWER platform. We were stuck between an IBM organization telling us, "Go to SUSE for your support," and the SUSE organization saying, "Go to IBM for your support." So, we told them both to go away. 

We are so glad that we haven't mixed the Red Hat and IBM more, because SUSE and IBM don't mix, and we were mixing them. That was prior to the merger with Red Hat. In regards to IBM's ownership of Red Hat, we are a bit wary, but we think that IBM will have the wisdom not to mess it up, but we will see. There is a risk.

The initial setup is as straightforward as it can get for anyone who knows what they are talking about. It does require technical knowledge, because that's what it is: a technical solution. It is not something that I would give to my mother. Contrary to other people's perception of, "My mom had a problem with her Windows. Oh, put her on Linux." Yeah, no thanks. Give her a tablet, please. Tablets are pretty cool for non-techies, and even for techies to a certain extent. 

For the migration from AIX, Ansible has been our savior. You do need somebody who knows Ansible, then it is more about printing your servers. So, you press on the print button, then you give it to the apps guys, but you do have to know what you are trying to aim for so the guy who is creating the Ansible Playbook codes exactly what is required with the right variables. After that, it is just a question of shoving that into production. It is pretty wonderful.

We do get a return on investment with this solution in regards to a comparative cost of ownership of going with the niche solution of IBM AIX systems and hardware. There is a tremendous difference in cost. It is about tenfold.

The integrated solution approach reduces our TCO tremendously because we are able to focus on innovation instead of operations.

RHEL is a great place to go. They have a great thing that is not very well-known, which is called the Learning Subscription, which is a one-year all-you-can-drink access to all of their online self-paced courses as well as their certifications. While it is a premium to have the certifications as well, it is very cool to have that because you end up as a Red Hat certified engineer in a hurry. It is good to have the training because then you are fully versed in doing the Red Hat approach to the equation, which is a no-nonsense approach.

Because it is a subscription, you can go elastic. This means you can buy a year, then you can skip a year. It is not like when you buy something. You don't buy it. You are paying for the support on something, and if you don't pay for the support on something, there is no shame because there are no upfront costs. It changes the equation. However, we have such growth right now on the Linux platform that we are reusing and scavenging these licenses. From a business standpoint, not having to buy, but just having to pay for maintenance, changes a lot of the calculations.

We tried SUSE on the IBM POWER platform, and it was a very lonely place to be in. That was for SAP HANA migration. We are glad that we decided to be mainstream with leveraging what we already had at Red Hat Linux (over a few dead bodies now). We also leveraged the Intel x86 platform, which is very mainstream. 

We are not using the Red Hat Virtualization product. We are using VMware just so we can conform to the corporate portfolio.

Our RHEL alerting and operation dashboard is not our route one right now. We have been using Centreon, which is derived from the Nagios approach, for about seven years.

With AIX, we couldn't get a single software open source to run. It was like a write-off, except for reducing a file system or logical volume in Linux.

We are a bunch of techies here. RHEL is not managed by end users. We don't really mind the GUIs, because the first thing that we do is stop using them. We are using Ansible, which is now part of RHEL, and that can automate the living heck out of everything. For now, we are not using the Power approach, but we may in the future. We are doing a business case for that, as it would be an easy sell for some communities and the use cases are not techie-to-techies.

There is a cloud, but we have very little infrastructure as a service in the cloud right now. 

It delivers to the targeted audiences. Could Red Hat Enterprise Linux be used in all types of other scenarios? Most likely. They have an embedded version for microcontrollers, i.e., things that you put into your jewelry or light switches. However, this is not what they're aiming for.

I would rate RHEL as a nine and a half (out of 10), but I will round that up to 10.