Its installation on a RAID or cluster system is something difficult. There are specific teams working on that. The GRUB configuration is also a little different from the other Linux distributions. 

In terms of additional features, as technology keeps evolving, the product will also have to evolve. For example, Microsoft Windows has come a long way. In Windows 11, there are so many features that are fundamentally the same as the oldest version, but there are other aspects or processes that have improved. macOS has also evolved over time. Similarly, in the Red Hat Enterprise Linux that I used in 2003 and the one that I am using now, some things are the same and some things have changed. Red Hat can continue to engage clients, understand the use cases, and update them.

Although the price is reasonable, there is room for improvement in order to stand out from other open source solutions.

I would like to see improvements made to the subscriptions and management of them.

It works fine for me, and it does what I need already. It does everything I needed to do, and it has for so many years. The only change that stumped me was the networking in version 9. I preferred the ifconfig way of doing things, but the system changes of it have grown on me. I preferred the ifconfig way because of familiarity. I knew how to manipulate things. I knew how to get things running and stay running and script ways to keep them running and notify me if the thing went wrong. My only gripe has been the networking change and the inability to use ifconfig anymore. I talked to some people, and they did point out that it's good if you're moving from one environment to another environment—like a laptop, but for servers, I don't need that. I just put my config file where I can find it and make the changes that I need.

I suggest that Red Hat move to a continuous delivery model instead of major releases. I know that this is a trend for many middleware products. We do not have a major release network. We only have monthly or quarterly roll-on releases on our continuous delivery model, which reduces the impact of a major version. This would probably be the easiest change to make.

The technical support has room for improvement.

From the administration perspective, I do not have any issues with Red Hat Enterprise Linux. For me, it is more convenient than Microsoft Windows.

It is a bit on the pricier side. However, due to the stability and support that they provide to my management and me, we really don't see a reason to choose another way to go. Red Hat offers excellent support in a sphere where it is difficult to find good support.

AIX will be out of support in the next few years, so that is a problem because a lot of the clinical apps use AIX. 

It would be great to have an overview of how various Red Hat products work together. They can show how to tie all those pieces together and how to have the products that we work together for our day-to-day processes.

The only issue we have had with it is around the SELinux configuration because the way Ansible installs, it sticks the platform passwords in a flat file. We want that locked down more strongly than what is there currently with SELinux. 

Continuous improvement is essential to enhance user experiences and address evolving needs.

Red Hat Enterprise Linux is secure but the security always has room for improvement.

Scaling can be complicated and has room for improvement.

The price has room for improvement.

I'm really excited about some of the developments happening in the workstations and the Fedora Silverblue space. There are advancements like rpm-ostree and the OCI container format, which enable deploying RHEL in new ways.

As we have numerous developer workstations, being able to deploy them in an image-based format is highly desirable. This would allow us to use the "toolbox" concept, where developers can choose any desired operating system within the toolbox. Some of our developers also work with Ubuntu and Oracle Linux. Having a consistent developer platform with full pseudo permissions and zero permissions within that container or toolbox would be beneficial.

Additionally, having an image that includes all the necessary software and provisioning it so that subsequent updates provide the updated image, would significantly enhance the developer experience. It would be great if teams could make modifications and changes to the image, like rebasing. I think it would be an awesome feature.

Let me provide an example of why this would be valuable for Red Hat Enterprise Linux Workstation. We recently switched from one security software application to another similar application on our workstations. We had to manually remove the unwanted software and install the new one. It was manageable for servers or edge devices, but for remote devices that are not always on the network or VPN, it became a cumbersome task to reach out to each device and remove and install the software. If we could update an image with the old software removed and the new software installed, and then allow users to update their image, it would simplify the process for everyone. Currently, it's possible with Red Hat Enterprise Linux for Edge, but it would be fantastic if this capability could be extended to Red Hat Enterprise Linux Workstation as well. That's what would be really cool.

The biggest thing that is crushing RHEL is documentation. Their documentation is haphazard at best. The man pages that you can use locally are pretty good, they've been fleshed out pretty well, but the documentation from Red Hat itself really needs somebody to go through it and review it.

The only real negative that I have with Red Hat is that you can tell that when you look at the documentation, they cut and paste documentation from the previous version. Because they update it that way, what happens is that there's nobody doing Q&A. For example, in Red Hat 7 and Red Hat 8, they changed the way they do deployments. Instead of using YUM, you use DNF but when you read the documentation for Red Hat 8, they intermix the two. This means that if you're a new Linux user, it's very difficult to distinguish between the two commands. The fact of the matter is that one is built on top of the other. DNF is backward compatible on top of YUM, and that can cause confusion with users and system administrators. However, it wouldn't be an issue if there was good documentation.

My job is pretty easy, but the documentation would really help me be able to communicate the things that I do to the rest of my team. They're all Windows people and when I go to the Red Hat documentation and tell them that we're migrating to this and we're using this tool, but the documentation is horrible, I get laughed at.

By comparison, Microsoft has its own problems with documentation, but it's a little bit more organized and it's definitely fleshed out a lot better. I commend Microsoft for its documentation. Red Hat may be the better product for the things that we do in our environment, but Microsoft has better documentation.

Network virtualization resources could be better. When you have any kind of trouble with network virtualization, such as with OVS, which is like a switch in a virtual environment, it takes many hours to find what is happening. Other vendors, such as VMware, and even other Linux implementations for network virtualization have better resources. It is much easier to escalate, and there is better documentation.

I don't use Ceph, which is their software-defined storage, because they don't have the best price. It doesn't make sense when you compare it in terms of the hardware cost, better performance, and better capabilities. That's my main complaint at any meeting with Red Hat. I want to use Red Hat Ceph, but it costs so much money.

All resources should be available on the website.

The vendor keeps rolling out many packets, which complicates our job. We keep patching our servers. CVEs come out all the time. However, having a solid and secure OS will make our life much easier.

The labor required to maintain the on-premises storage systems has room for improvement.

Red Hat Enterprise Linux can benefit from more promotions and demos.

We are using the features that are available with Red Hat Enterprise Linux and Ansible. As such, there are no specific features that we are looking for. 

We have frequent meetings with them. We have had some issues on the application side and the OS side for which we opened cases and discussed those concerns and questions in the meetings offered by Red Hat.

The first area for improvement is documentation, and I consider it since I have been working in IT for more than twenty-five years. For twenty years, I have been working with open source, and I see that the documentation is lacking, so it needs to do more work on its documentation part. Most open source and upstreams from Red Hat products work from the open source solution and have better documentation than in the actual Red Hat products.

New products need better documentation. The websites also have a single sign-on to get you from one side to the other. As a partner, I had a problem finding out how I needed to connect and to which side of the solution. I consider myself an expert user of the internet and websites, but going from one side to the other, was quite problematic.

There needs to be a broader understanding of the RHEL suite's nuances like how the versioning works and implementing it on various kinds of infrastructure in use across the development landscape. There needs to be more training and education. It's difficult when you have a roadmap to deal with, but it is possible. 

Large application vendors may not have certified RHEL, or they have certified an older version. Most of the large application vendors are unfamiliar with the versioning that RHEL introduced, which I strongly support. They will support a given sub-version up to a point, not realizing that the sub-versions are essentially additive. 

This can be a real frustration when you try to deploy modern infrastructure. It allows tremendous flexibility because we can try things out across the cloud, virtual, and physical, but that's not always where the issue is. It's a matter of educating the engineers and developers on our side or enterprise vendors on the other. 

The licensing could also be simplified. While it makes sense from a theoretical perspective, it's a challenge to explain to the procurement team. Those with some technical expertise can understand how our licensing model works. However, it's still tricky because Red Hat is so different from traditional operating systems. It's another barrier when I'm trying to deploy it in an enterprise environment.

In terms of feature requests, I would point out that our company tends not to operate on the bleeding edge for obvious reasons. We look at what has already been released to define our roadmaps. There's nothing in particular that I would say needs to be included. However, I would like to see Arm playing a more prominent role in the cloud infrastructure and enterprise physical data center spaces. Red Hat supports this, but I haven't seen a clear roadmap for how that support should evolve within the Red Hat operating system environment. 

I'd like to see more of NCurses type menu systems in some instances. We're dealing with SUSE Enterprise Linux, they have an NCurses menu system. It's a menu system. Even some of the higher-end Unix systems like AIX have some inner menu system where all the configuration tools are right there so your administrator doesn't have to jump through multiple directories to configure files if needed. I like the simplicity of Red Hat because it's pretty easy but having an NCurses menu when you have to get something done quickly would be nice.

Red Hat Enterprise Linux should be available in a free version that developers could try on their own machines before deciding to implement the enterprise edition. It would be nice to have a community version available with all the features so developers can become more familiar with Red Hat Enterprise Linux. 

The integration with the apps and support could be better.

A colleague was talking about having some recommendations for the Ansible Cloud on the console and having some way of identifying your dev or prod path and whether you've got read or execute access to a playbook. There were different things like that, and they made a lot of sense, especially if you're in a dev or prod environment because mistakenly running something in prod would be a huge issue. There could be something that Red Hat configures, or there could be a text field where organizations can add labels to a part of the console to distinguish that for themselves. Those would be things that would be useful. I can't imagine it's hard to implement but being able to know which environment you're in matters a ton.

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.

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.

Windows operating system is used everywhere. You will find it everywhere, and every user is able to use Windows. If a user is using an operating system from the start, it becomes easier for them to use it when they come to a professional environment. That's an area in which I believe they need to put in extra effort, especially for the students. Currently, for their final projects, most students use Windows, and this is an area where Red Hat needs to put in an effort. They need to give some training to the students so that when they come to the professional environment, they're already used to it. It would then become easier for them to use it in a professional environment.

I'm also using IBM AIX, which supports a tool called Smitty. You just put Smitty, and you can do anything. At the backend, the command will run automatically. It is not exactly like a GUI, but you just give the input and it will give you the output. That is something that Red Hat should work on. That would be an added advantage with Red Hat.

The cost could be lowered. We don't use RHEL in the cloud because Ubuntu is cheaper. Ubuntu factors support costs into the license when you're running it in the cloud, and it's a fraction of the cost of what RHEL is. I'm also not sure if RHEL supports open-source products. If they do, they don't advertise it. Adding stuff like Apache and other open-source tools like Tomcat to their support portfolio would help.

Recently, whenever we have applied a Red Hat patch, we have encountered errors requiring additional work. Unfortunately, the release notes for these patches are not always updated accurately, creating further challenges during troubleshooting. Specifically, the notes often fail to mention dependent packages that are also updated alongside the main package.

While the OS hardening feature is helpful, it could benefit from additional automation. A one-click package for hardening all files would significantly improve efficiency compared to the current manual process, especially considering the hundreds of files we've processed over the years.

The support has room for improvement.

The response could be better for urgent issues. If there's an issue with live services, they need to be faster. 

It would be nice to have antivirus services.

There should be more upgrades to the security features. 

Red Hat Enterprise Linux has affected our HA systems in a negative way. We're working through some of those issues.

Red Hat Enterprise Linux 8 came up with a new feature that's like a MOM API in our cluster. It goes out into the AWS side and it needs to be adjusted. It does a retry that causes a cluster to failover pretty quickly, so we turned that feature off. That's something that could be improved. 

Ever since Red Hat acquired CentOS, the connection between the new CentOS Upstream and Red Hat Enterprise Linux has become unstable and requires improvement.

Red Hat Enterprise Linux's ability to run containerized applications is not optimized and has room for improvement.

The Modules feature is awesome but it could be even better.

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.

A completely new setup should not be required when upgrading to a new version of the solution. For example, moving from RHEL 7.7 to RHEL 9 requires us to go through every minor version upgrade as well as RHEL 8. We do not have the ability to patch as quickly as we would like, but there are pathways. We got on 6.8 this year and migrated to 6.11 where we are trying to work on the automation portions of deployment. Before, we had variations of versions 7.2, 7.3, and 7.5 in our environment. We have not yet been able to use the supported versions that we are accustomed to with our applications. We are now on 7.9.1 and are trying to implement the minor upgrade versions in our environment. We have not yet experienced a healthy environment or the joy of using RHEL because we keep encountering issues and problems.

There are issues when upgrading or integrating with previous applications or systems such as Satellite, vRA, SaaS, or OpenShift. This is extremely, extremely important because a lot of our infrastructure is on RHEL. We need to have someone onsite to adjudicate our infrastructure's most important applications, when we would rather be able to patch them in a timely manner without having the whole world assist us. 

The solution should be more user-friendly so we better understand how to scale. It is not that we shun professional services, but there is a major knowledge gap in our understanding of the solution. 

The operating system might not be able to handle big scientific problems which require a highly parallel system and symmetric multi-processor to run logic streams simultaneously. 

I would like to use OSCAP profiles without the dependency on Red Hat Insights. If you install the OSCAP profiles from Red Hat Insights, I'm not sure if it is currently available in the cloud console. Most of the time, we manage compliance from Red Hat Satellite, but this feature could also be built into the console. Maybe it's not an issue price-wise most of the time, but it would be easier if we could use the same console and test-level capabilities.

I also want the co-pilot to provide more granular control and more features in the GUI, so we can have one configuration from the GUI itself. It would be helpful to have a feature similar to the one in Windows where we can manage all the net flows from one console in a single pane of glass and install it on-premises like an admin center. It would be great if Red Hat had some kind of admin center to manage all the Red Hat Enterprise Linux boxes without using an additional product like Satellite or something, we could use the co-pilot on all the systems to monitor the dashboard.

A feature that I would like to see in the image builder is the ability to open the image in live mode and access a command line interface. This would allow me to immediately apply the necessary security settings required by the STIG. By doing so, I can deploy the image with the confidence that vulnerabilities present in the live network cloud service are closed before deployment, rather than applying the settings afterward as suggested in the example by Red Hat.

Ideally, I would prefer to deploy an operating system that already has all the necessary configurations in place. This would involve accessing a command line interface, adjusting configuration files as needed, setting up banners, and establishing user accounts. After making these changes, I would create an image and deploy it. I've noticed that the current image builder is primarily designed for commercial use, but as a DoD user, I have different requirements. Therefore, having an emulator or virtual terminal that allows me to interact with the kernel and make live changes, which can then be saved to create a customized ISO, would be an excellent feature to have. It would be great if Red Hat Enterprise Linux had a similar capability. Interestingly, Ubuntu Linux does offer this functionality with its "Custom Ubuntu Basic ISO Creator" (CUBIC).

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.

The graphical user interface should be more user-friendly. It's a concern because the command line is perfectly fine.

The solution is moving away from CentOS and there are growing pains from the customer's perspective. It was purchased by IBM and they are for profit which everyone understands. There is a huge shake up right now because customers who run CentOS do not know what to do with all their systems. One of the reasons CentOS is used for government offices is its security feature that does not change because it occurs after route. The solution placed CentOS in the middle so government customers do not trust it. The way the rollout occurred caused a lot of mistrust with Red Hat. 

The SELinux is great but the Amazon security features cause issues. For example, we run RHEL and CentOS on AWS but they control the cloud and do not give us access to security features. We have to go through multiple layers to deploy an instance. Something that could be controlled with a firewall or blocking ports is now controlled by security groups inside AWS that we cannot access. 

I don't see anything that needs improvement with RHEL itself, but there is room for improvement of the support infrastructure for it. The management and updates to Satellite, which is the support update, have been cumbersome at best, including releases and changes to a release. Communication on how that will work going forward has not been great.

I have seen that the upgrade from RHEL 7 to RHEL 8 can be a bit problematic since I have seen some issues during the upgrade of libraries, along with some conflicts with the other libraries in the tool. The aforementioned area can be considered for improvement in the product. Presently, I am not trying to upgrade from RHEL 8 to RHEL 9.

For the most part, everything looks fine. Everything is going smoothly. 

Right now, we need to get memory and CPU via the console. If it was available in the console so that we could adjust these two things, that would be ideal. 

The high cost of Red Hat Enterprise Linux has room for improvement. The high cost in terms of a platform is problematic.

There is room for improvement in integration with different cloud platforms. There should be better integration because right now, a lot of cloud platforms have their own versions of Linux, which runs better on them, and they have better integration with the services. RHEL is great, but RHEL is more of a generic form of what Red Hat provides.

The product should be made more accessible to someone who isn't experienced with Linux.

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.

Red Hat Enterprise Linux analytics are cryptic. While it is user-friendly, it is also very picky about who it takes for a user. It is rock solid, but it can be difficult to find things in there. Google is probably the best way to find information, but solving a problem can be difficult if we don't know what flags or permissions we need. We need more transparency or ease of use.

It is challenging to use the knowledge base and the deployment documentation. Some of it is all over the place, and it's challenging to piece them together.

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.

Their support service can be improved. They are able to help us, but in some cases, there is a delay in getting a root cause analysis from their side for Severity One cases.

The vulnerability assessment part should also be improved. We do a lot of patching regularly. They try to fix an issue very quickly, and we also end up facing bugs that are not properly documented. When releasing the general availability for a particular solution, they need to do a lot more work on their side.

The tool is very, very close. It makes some things difficult. On the other hand, that is what makes the product so stable. The product lags a bit behind in the market. The things we are running are pretty old. Yet again, that is why it is stable. The solution doesn’t switch with every new thing there is. The solution does not need to change that because that's what makes it good.

The product could run more recent tools and packages in the repositories. However, it might bring instability because they are new and less tested. I looked at CentOS, which was close to Red Hat. It had a system working, but a few months later, it didn't work again because the packages and contracts had changed. We couldn’t communicate anymore. It’s not desirable with Red Hat Enterprise Linux. We want stability. The price we pay for it is that we run on some older features.

If you download Oracle Linux, it is very easy. And when it comes to updating Oracle Linux, it does not require subscribing to the repo to do the update. When you install Oracle Linux, the repo directory contains all the files needed to run a DNS or VM update. Whereas with Red Hat, if you download the ISO and do the installation, once you finish, they force you to subscribe to their environment to do VM updates.

I understand that Red Hat would like statistics on how many people are implementing certain kinds of servers, so they force them to create an account. I agree that, when first downloading it, it makes sense that I have to provide my information. But when I want to update, it shouldn't be necessary.

Sometimes, I'm just doing a proof of concept and once I'm finished, the server is gone. In that situation, Oracle Linux doesn't ask me to subscribe for that server, because they don't need to know. The server may only be there for a second and, once I finish, I delete it. If Red Hat would remove that requirement, that would be great. If I want to download the OS, I understand that they need to know who I am, but they don't need to know that information when I'm building a server, unless it is a production server. If it's not a production server, they shouldn't force people to register.

Also, it can be difficult to find the RPMs I'm looking for. For example, if you want to recognize a Windows file system in Red Hat, you have to download a package outside of Red Hat. I searched on Google and found the RPM, but I struggled to find it. Once I put it in, everything worked fine. When Red Hat doesn't have something, and others develop it as open source, they should include that RPM in Red Hat's repo so it's not a struggle to find it.

I would like Insight to include some features from OpenSCAP, which they offer for compliance services. I played with it a little bit, but haven't gotten the updated setup to get that. It creates excellent documentation.

RHEL's feature for managing multiple versions of packages is getting better. In earlier versions, when I think about the Red Hat software collections, it was sometimes pretty hard to set them up and use them on a daily basis. With AppStreams, it got easier. What could still be improved is the lifecycle information about AppStream versions. Usually, when doing a major release, I have 10 years of support divided in different support phases, but a lot of applications from the AppStream repository have a completely different lifecycle so you need to check it separately. For example, a certain node.js version will be at the end of support in 10 months. I must make a note to update to a new version before it reaches the end of support. It would be awesome if the end of support date of the application streams would follow a stricter lifecycle with aligning end dates.

The Authselect tool needs improvement. This tool is used to connect your system to an identity provider or directory service, e.g., openLDAP. There is documentation and descriptions. While there are a few use cases and examples described, it is sometimes hard to use these tools to set up the configuration that we need for our specific environment. I would like it if there was more general information about the tool, not just describing a use case. For example, here is how to do it and how to connect to some kind of openLDAP service as well as more information about when you need to configure certificate services and mutual authentication. There is room for improvement, but it is more room for improvement in the documentation area than the RHEL system itself.

In the past and with older versions, you couldn't expand the root file system without rebooting the server or restarting the operating system. That is something that they have actually corrected now, which is great. They corrected that issue somewhere around RHEL 7. 

For my work, the solution is not missing any features. We;re only using the command line and that is enough for us. 

Maybe they need to make it easier to apply patches from different resources. That said, at my level of usage, I never have to apply patches. 

I like it the way it is. 

It's getting easier for the community to use it free of charge. If you have an account, you get to use it. It would be better if the community could use it on their own for lab projects.

Some of the repositories and some of the DNS versions are very old. I just deployed something using Ruby and the DNS stable repository was sufficiently old that the Ruby project I was using didn't work. 

I would like more transparency and better options other than using something like Ruby Version Manager. I'd rather be able to get modern, up-to-date versions from the base repositories.

The cockpit server doesn't work and is useless. I don't like the images shown in GCP. I prefer the ones in AWS. It seems like the solution is in tune with what we deploy on the private cloud. 

In the area we are using it, we are satisfied.

Maybe in OpenShift, which is our next step, there can be more improvements with integration with Kubernetes. We're not experts there yet. 

Maybe it could have a better user experience and less coding. Reducing the effort for the end user or administrator would be ideal to make daily operation and maintenance easier. 

If they can make the integration with Ansible easier, that would be ideal.

They should offer more in terms of learning materials to make learning easier. 

They need to make things more affordable or accessible. 

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.

The solution could provide more APIs and GUI interfaces. The current options are kind of low-level and not as visual as Windows. 

I would like to see additional features, including automation and the introduction of AI/ML-based tools within Red Hat to handle manual tasks that humans are required to do. 

Also, sometimes updates are very frequent, meaning the day after one, you get another. It can be quite annoying when you're trying to do your job.

It is great for the stuff that Red Hat either owns outright or is the lead on the upstream product. When it comes to third-party tools, it can be a little iffy. Some of the database solutions and data governance solutions that I have had to implement on Red Hat have not been fun.

I would mostly like to see improvement around corporate messaging. When Red Hat 8 came out, and Red Hat decided to change, it inverted the relationship between Red Hat and CentOS. This caused my customers who had a CentOS to RHEL development to production workflow quite a bit of heartburn that several of them are still working out. A lot of that probably could have been avoided through better messaging. 

I would like training to be added to the subscription. It would be useful for when you have to train yourself or get a certification. There are many things that we are not using because we don't know how to use them. Having training included in the subscription would help us in learning more things and utilizing the full power of the solution.

Red Hat Enterprise Linux is a little expensive for some customers who don't have the budget. It depends on the client. They can save money by not purchasing some of the added packages and services.  If the client has a budget of $10 million, we can go for the whole bundle. 

We finally started doing Red Hat Enterprise Linux for Edge. That one definitely is an improvement. One piece that is missing is that we are required to use moby-engine, but currently, Red Hat Enterprise Linux for Edge forces Podman, so we have to work around it.

Red Hat Enterprise Linux should modernize its UI to make navigating the screens easier.

Network management can be easier. It is getting more complex. They can also give more customization for the CLI.

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. 

The UI is not user-friendly and has room for improvement.

My biggest issue right now is Red Hat Consulting and trying to use some of their services to help get us going. Technically, they're good, but we seem to have issues with scheduling.

Also, we initially deployed it with Red Hat Satellite. We're now moving more to automation using Terraform within VMware, to automate the clone and then follow up with Ansible to configure. Red Hat's standard deployment is with Satellite and Kickstart, but we're looking at other options to help speed it along. We do have a mix of bare metal and virtualized servers and it's easier to spin up in the virtualized world versus bare metal. That's why we're looking at some options outside of Red Hat, for the bare metal. We'd like something that we can use to build a server a lot faster, as well as address network latency issues.

The patching process with Red Hat is disruptive and not very cost-effective. This is why I would like to switch to Oracle Linux, which allows for security patching on a running system. This is a significant advantage of Oracle Linux over Red Hat. With Red Hat, we have to shut down all of our machines at least four times a year for large patches. Oracle acquired the technology for applying these online patches from MIT, and this technology is integrated into Oracle Linux. This allows for systems to be patched without disrupting the work of employees and their organization, which is a major improvement over Red Hat's patching process.

The upgrade procedures are a little bit cumbersome. It would be nice if they are not because every three or four years we have to update, and I find that to be a bit on the cumbersome side. We have been able to automate most of it, but we still run into things where the job does not finish. There are things that require additional steps. There are things that need to be removed and that always require manual intervention. I do not know how they can get rid of that, but it is cumbersome in an environment where you have hundreds or thousands of servers.

The operating system configuration and function selection could be improved. Configuring the operating system and selection of options takes a lot of expertise. I'm now going to retire, and I've been doing this for many years. Trying to train people to make those choices is proving to be difficult. However, to get applications to run efficiently in those environments, those selections are absolutely crucial.

Red Hat Enterprise Linux should include simpler storage management.

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.

We have had issues with the identification of new volumes when you add new disks or storage. You need the remove the machine, which can cause problems when you have high availability. If they can resolve the problem of detection of new volumes, it would be good for system administrators.

This solution could be improved if it was easier to set up and run in cloud environments. It can also be costly to manage a large OpenShift environment.

Red Hat can be tricky at times, but all operating systems are. The moves to systemd and NetworkManager haven't made the product more user-friendly. The network management they had before was easier and somewhat more reliable than NetworkManager, which Red Hat forces us to use now.

That may just be my personal preference because I've been working on Red Hat for so long. It's something new that doesn't do exactly what it used to do, so it's probably more of an old person's complaint.

The firewall controls can also be somewhat challenging in terms of automation. An application may use a different setup, so you need to consider that if you want to automate installations. 

You can't easily port an application to another operating system unless it's CentOS or Fedora. It's not portable if you want to port it to something like Windows except for Java and containers. Unless it's another Red Hat, CentOS, or Fedora, the application itself isn't portable if it's installed on a thick virtual or physical machine even. It's not easily portable because you must recompile the application or make changes.

The solution's licensing sometimes could be a little bit confusing for someone who's not a full-blown system admin and doesn't have a lot of experience with Red Hat Enterprise Linux. It took a while for me to understand the licensing.

The GUI has room for improvement. It needs to be managed by many administrators. It has basic command lines. They could improve it with better automation. We'd like to be able to create a script, and then have the ability to deploy it where we don't need to write everything manually. That part can be useful for automating. 

We'd like it so that a coder wouldn't need to go through it, read it, go to GUI, and then generate a script. If they want to modify it, they could modify it. If Red Hat Enterprise Linux is going to build something, the REST API can be helpful instead of writing their own, starting from scratch. That would make it easier.

For future releases, there could be more integration. Regarding security, we used a different tool for scanning, but having a tool within Red Hat could enhance it. 

Support is essential for open-source software. If they improve aspects like prevention against hacking, it would be beneficial. 

Before, with a surge in hacking incidents, companies lost data, and once lost, it remains lost forever. You never know when it might be used. Improving security, especially in terms of prevention, is crucial. I would like to see ongoing improvement in this aspect.

Upgrading between versions needs to be easier. For example, if we have Red Hat Seven running now and a Java exploit is found on Red Hat Seven, we need to be able to upgrade to Red Hat Nine online without any downtime in the environment. This is because it is not possible to reinstall the environment from Red Hat Seven to Red Hat Nine in production without causing downtime to the applications. Red Hat needs to have tools that ensure that we can upgrade from Red Hat Seven to Nine online without any issues.

I don't prefer Red Hat Enterprise Linux for desktop over other options. 

The solution's ecosystem is good but it would be better to create cohesive components in all of the development tools. 

A developers' hub feature would help. 

OpenShift already provides excellent visibility, but bridging the gap with Kubernetes would be key because Red Hat Enterprise Linux drives OpenShift.

As a software developer, documentation is very important to me. The solution should provide better documentation.

The solution lacks proper documentation. There have been times when I found a document that was supposed to fix an issue, but I realized it was wrong. Then, I would send it to support, and they would fix it.

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.

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.

Red Hat Enterprise Linux's patching process needs improvement, particularly in achieving consistency. Currently, when you patch, you might not have control over the timing, leading to different software packages ending up at different patch levels. This lack of consistency can make it challenging to manage and control the various components effectively. My background is in IBM AIX, so the patching is based on the technology level and the service pack level, so all the related patches stay at the same level.  

From a cloud perspective, I'm looking for more integrations with native cloud services. For example, the ability to use native Azure Key Vault instead of Ansible Key Vault or Red Hat Key Vault. 

Additionally, integrating image services from Red Hat into native image repositories such as Azure, Google, or third-party image repositories like JFrog is crucial. The key focus is on integration. 

Red Hat should not become Microsoft and lock down functionalities within Red Hat. 

It would have been nice if we had the ability to do updates without rebooting. If we can update certain parts internally without having to remove them from the entire server, that would be fantastic since, else, there will be downtime, and we will need to reboot. We have to schedule downtime. If we can do so, we will patch it and continue running. Even though the downtime is minuscule, having as little as possible downtime could be great.

Speaking about the downtime caused due to the lack of the aforementioned feature, we reboot about 40 servers every time there's a patch, and they're not staged all at once. The whole process will take an hour or so.

Red Hat Enterprise Linux's monitoring could be improved. I would like additional monitoring features, like a greater ability to monitor services and workloads running. Satellite can provide centralized monitoring of subscriptions and deployments. You can build a monitoring console, but there is no native monitoring. 

Sometimes the solution deletes our archives or other features that were useful to us. We would like users to be surveyed before items are removed or be provided with a better explanation as to why removals occur. 

For example, some file system patches were recently removed but replacement patches do not cover all features. 

Support for older versions of the operating system could be improved. If people can't afford to upgrade, or if they have servers that are outdated, they need to be able to provide back-field support for those.

I use Linux on Satellite with Ansible infrastructure. It would be great if there were a universal interface to control Red Hat Enterprise Linux's policy from Satellite. It could be a dashboard showing which policies were enabled on what system and allow you to apply them from the dashboard. 

I think Red Hat training could be cheaper. A company can move fast technologically with enough training. They will be stagnant without training and remain unable to fully leverage the technology. I have been encouraging the group to get a subscription to the training course for five years, but we haven't been able to take advantage of it because of the cost. They should make it cheaper for clients and offer big discounts at scale. 

When people lacked training for the technology we use, we migrated away from it. I worry that if we don't have enough training available to the client, they will eventually migrate away from Red Hat. More affordable training on key technologies like Satellite and Ansible automation will help us retain customers on those products. Downstream it will help them migrate to the latest and greatest Red Hat Enterprise Linux, as well. 

Overall, they are doing a good job. We're hoping that they continue to onboard open-source products into their operating system.

Some low-level aspects, such as the file system support, can be improved. There are a lot of file systems that are supported by other Linux distributions. Red Hat Enterprise Linux is a little behind those. For example, BTRFS is a file system that is not supported by Red Hat.

Some of our customers use the image builder tool to build the golden image to deploy to the cloud or to build a custom image to deploy on the cloud or on-prem. The golden image created by the image builder tool is good. It's the golden image. It works without any issues. However, the build process of image builder could be improved because it's not up to the standard or at par with other tools that build the golden image. However, it's quite useful and quite easy to use. It's not a big problem, but it could be improved. There is not a lot of information about how to use it. The process is not as well documented as the other parts of Red Hat Enterprise Linux.

The knowledge base offered by Red Hat is very good, but it could be improved and made much easier to search. Currently, the best way to find an article in the knowledge base is by using Google Search. By searching on Google, we can find the right knowledge base article, but it isn't easy to find information by using the search option within the knowledge base.

Writing SELinux policies is sometimes very hard if you want to deploy a new application on it.

Deploying clusters on Red Hat, as well as on Oracle Linux, is a bit involving. I'd like them to simplify the setup or at least give meaningful log files to be able to see what's happening at the cluster level. 

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.

We have not succeeded in creating an image from Red Hat Insights for Red Hat Enterprise Linux, including custom partitioning and custom scripts. This would have been helpful.

Red Hat Insights reporting can be enhanced by incorporating performance components, making it a central tool for vulnerability assessment, compliance monitoring, and much more. The performance component is available on Red Hat Enterprise Linux, but we need to maintain the dashboard on-premises, which requires us to switch between systems instead of performing all tasks from a single location.

Managing the destination for netting on the Netserver using Red Hat Enterprise Linux could be made more user-friendly.

I would like to have enhancements in the data files to help with deployments.

The licensing model is kind of a mess. It works, however, it could be streamlined. For example, just how they apply the licenses to servers and the solution seems like a mess, at least from my end of it.

I want Red Hat Enterprise Linux to stick to the open-source routes. As a company, we experience challenges in managing the budget. 

The package compatibility between different releases is a little confusing sometimes.

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.

Red Hat Enterprise Linux's documentation could be improved. Sometimes when you call up support to have that Red Hat answer, they send you back a Reddit or Google link. I can Google or go to Reddit, but I want an answer from Red Hat.

Personally, I like the terminal-based tool called Tusa for certain activities. Sometimes we just don't have a web interface available for repetitive tasks. It would be nice to have a web-based tool for Red Hat Enterprise Linux since we don't always have access to a web browser.

The room for improvement depends on how we use it. It's just a normal operating system. Considering an area where the solution lacks, I think we can look into a lot more automation and integrations with Red Hat Enterprise Linux and other products. However, I cannot say specifically where the improvement should be because it mostly depends on how we are using it. It just works the way it's supposed to work.

The solution should improve its documentation.

Its user interface could be better for people who want to use the GUI. They can provide a better user interface with more features. Storage works perfectly fine. Of course, continuous improvements should be made all the time, but it isn't at all lacking when it comes to storage and other features.

The technical support should be improved. I believe it would be beneficial to notify the customer in advance of any planned maintenance so that we can better coordinate and plan our customer interactions accordingly.

It has its own ups and downs. Most of the time, it's pretty stable, but sometimes, you'll find some weird bugs that could affect the availability of your running machine. Red Hat can improve its operating system by making it better from the quality assurance perspective. Users do find bugs, which they, of course, shouldn't encounter. A better QA would probably make the job a lot better. It would make the product a lot more stable than it's today.

The product should provide a portal to manage licenses.

Sometimes they don't have new versions for applications like Apache or PHP. I understand it's because they have to have support for them, so they can't have the latest version all the time, but that's the main thing I see that could be improved.

So when you use RHEL and you want to install, let's say, Apache or PHP, you do a "dnf install php" and you get a specific version that Red Hat releases. But that isn't the latest version that PHP has released, because Red Hat has to make sure that they can support it. The compatibility with the latest version of Apache or PHP lags because RHEL does not release updates of the latest versions.

It's the same with the kernel. Sometimes they are a bit behind in the kernel version. That's the same issue. They have to test it and support it for so many years so that's why they are a bit behind on the kernel as well.

We had issues migrating from the old to the new Red Hat Enterprise Linux version in the virtual environment. It forced us to spin up a new virtual environment to have the new Red Hat Enterprise Linux version. 

The product's availability is on the main cloud hyperscalers, like GCP, IBM Cloud, Azure, and AWS. The product should be made available on Oracle Cloud. 

I would like to see Ansible as a default in future releases.

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.

It would be very good if we can easily migrate from CentOS to Red Hat. We are about to move from CentOS to Red Hat. It would be great if they can give us a free version. Otherwise, we need to purchase licenses, which are quite expensive.

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.

The Cockpit interface needs improvement with more features. The information for implementing Red Hat Cluster could be also improved. And there could also be better performance monitoring.

I am not happy with Red Hat's support. It is difficult to find knowledgeable people. It's hard to troubleshoot. 

When we initially began working with containers, we encountered some challenges with compatibility. Red Hat provided an older and somewhat outdated version of Docker, which made the early stages of our container journey more challenging than I would have preferred.

We need to have more flexibility on the developed versions. Not everybody is ready to subscribe to enterprise versions. They would like to test the tool without subscriptions. 

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.

Red Hat Enterprise Linux could be improved in several ways, especially regarding transparency and communication of new features. Enhancements could include better documentation and quick reference materials for various user groups, including developers, system administrators, etc. 

Additionally, there could be improved visibility for new and improved commands within Red Hat Enterprise Linux. Many users still rely on outdated commands when newer, more efficient alternatives are available. Providing frequent updates and maintenance for resources like the admin blog would help improve communication and transparency regarding Red Hat Enterprise Linux's capabilities and features.

A lot of improvement is required to get security compliance, especially with the privacy of the data, managing it, and storing it.

We would like to have a better understanding of what to expect when we move to a different version of Red Hat Enterprise Linux.

A latency always gets introduced when we move to newer Red Hat versions. I wish we wouldn't see that as often as we do nowadays. It would be nice to know the changes upfront rather than when we have to open a case, go through a couple of months, and then find a good resolution. We want a better understanding of what we will see when we update the kernel from seven to eight.

The model, specifically the consumption model, is an area that needs improvement in the solution.

We had a really big challenge striking a chart between on-premises and the public cloud. The approach is that you pay as you go in Red Hat Enterprise Linux. In general, you pay for whatever you use instead of preparing for a full year.

At times, language is a barrier when it comes to support. That's one of the aspects I would like to improve about the solution.

Since it's based off Fedora, I don't like the DNF package manager. 

Their support needs improvement. It should be faster for priority tickets.

Some of the tools can be improved and made user-friendly. The OpenStack and OpenShift tools can be better.

A targeted package tailored for small and medium-sized businesses can help increase business.

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.

We are trying to figure out how to enable encryption or just encryption. The last thing we want is to use locks, which are a hassle for encryption. We don't have the personnel to unlock the system every time it gets rebooted. I know there's a way, like on Windows, where they have TPM. I'm not sure how Red Hat Enterprise Linux’s TPM works. That's one of the issues we face—how to utilize TPM effectively.

I think in the future, if the company requires us to encrypt everything, it would be a time-consuming process. I'm not sure how long that would take or if it will happen. I just want to understand how Red Hat Enterprise Linux and TPM work or if there's an existing solution that works similarly where I don't necessarily have to be present every time my system reboots and enter a password. At least for Windows, we know that it works, but I'm not familiar with the equivalent functionality in Red Hat Enterprise Linux.

In future releases, I would prefer a Red Hat Enterprise Linux image that fits on a DVD. The Red Hat Enterprise Linux image keeps getting larger and larger. One of the biggest requirements for my company is that it has to fit on a DVD. Now, with Red Hat Enterprise Linux 9 approaching close to ten gigabytes, it won't fit on a DVD anymore. The last thing we want to resort to is using Blu-ray. I prefer not to use Blu-ray. So we need to keep the image size on a DVD smaller. That's one of the main issues. And we can't use USB sticks either, even though they're a new option. Everything needs to be burned on a DVD. So having a Red Hat Enterprise Linux image that fits on a DVD would be beneficial for any future versions or releases.

Improvements are necessary to stay in the market and face the competition. I really think that the upgrade policies between the major versions, like from from RHEL 5 to RHEL 6, should be much easier, similar to what is in place for upgrading from RHEL 6 to RHEL 6.8.

I don't like the UI changes that come with different versions. 

The adoption was slightly slow because the knowledge in the market is slightly less available. It's hard to find resources to actually support the product.

Some kind of training that can upskill the resource into this technology could certainly help.

The solution should be updated more with the releases of programming languages. They’re lagging a bit too much. We have a lot of developers complaining about having releases that are too old. For example, if they want Python 3.11, Red Hat Enterprise Linux supports only 3.9. So the product is lagging behind a bit more than our developers would like. 

It would be nice if all the features that are available on the cloud, like Image Builder and Insight, would be available on-prem.

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

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.

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.

There are some things that we've seen from RHEL that have given us a little bit of consternation. Their IdM product could be improved greatly. It would be great if they had some type of application built in that would let you do whitelisting for applications. On the government side, for zero trust, that's becoming very important. We're currently using a third-party solution, and it's tough to get it to match up because anytime the kernel changes, you have to match the software to the kernel. If we get a critical vulnerability on a kernel, we have to roll out the new kernel but then our third-party software isn't cooperating, and it starts breaking down the system. So, it would be great if Red Hat could integrate that type of functionality into the product so that when a new kernel comes out, it includes the updated software to do whitelisting and blacklisting of applications and processes.

Most of the complaints people have about this solution revolve around security. It's not easy to increase that. 

The cost of this solution could be improved. 

When there is down time from a system admin perspective, this solution could improve how they communicate why this down time is happening. 

Although the security features are good, I'd like to see more added in the security sphere.

It could be a bit more user-friendly. It could also be cheaper.

I would like to see the GNOME system monitor feature, which shows CPU usage and other aspects. It will help to save time. 

Their pricing and documentation can be improved. They need to have developer variance that's more developer-friendly and less costly. They have a free developer version, but that's very limited in terms of features from RHEL. They also need to build their own open source community.

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

The training documentation requires revision. The numerous links to different pages disrupt the flow of information and make it difficult to maintain focus.

The cost of this solution could be improved. 

Support.

It is mostly better than other solutions. However, it is sometimes difficult for disaster recovery, so we have to plan accordingly.

Workstations: More applications for graphics.

Servers: More applications for monitoring (e.g., nmon).

Oracle and SAP Environment and all HPC environments.

Many areas in version 5 are obsolete such as filesystem ext2, ext3, while the new versions (v.6, 7) support ext4, Btrfs, ZFS, etc.