What needs improvement with Red Hat Enterprise Linux (RHEL)?

I would rate customer service or tech support with Red Hat Enterprise Linux (RHEL) a seven, no more. I give it a seven because of the time it takes for responding to problems; it takes too long. For management, it is medium; it is not easy, it is a medium level. I see a medium ROI with Red Hat Enterprise Linux (RHEL) because it has a high price. OpenShift may provide better ROI, but OpenShift is very high. The initial setup of Red Hat Enterprise Linux (RHEL) is complex. On a scale of one to ten, I rate it a five—medium complex. A very expensive time is needed for deploying clouds with Red Hat Enterprise Linux (RHEL). It takes a lot of time. In many cases, Red Hat Enterprise Linux (RHEL) does not help me save time because the principal problem is that in AWS, Red Hat Linux is not the natural Linux for deployment; the default deployment in Amazon is Amazon Linux, not Red Hat Linux. In many cases, it does not depend on direct Red Hat support for saving time. My thoughts on the knowledge base with Red Hat Enterprise Linux (RHEL) are that it is good but it does not have it all because I have the medium and plus; it needs more knowledge base.

Red Hat Enterprise Linux (RHEL) could be improved by including a better app stream module experience or simply phasing out modules in favor of straightforward version repos. Red Hat could also integrate more common tools directly or integrate EPEL more seamlessly. Additionally, enabling AI-based operational tuning for kernel parameters, file system parameters, and network stack optimization could enhance the experience. Regarding needed improvements, simplifying the subscription and licensing would help reduce complexity in subscription management. Clear visibility of consumption and unused subscriptions and compliance is also important.

I think the support for Red Hat Enterprise Linux (RHEL) can be much better; when it comes to something such as SUSE Linux, I feel those providers are doing a much better job in terms of support than what Red Hat provides. One area where Red Hat Enterprise Linux (RHEL) stability could be improved is with Ksplice; Ksplice is used for online patching. The problem I have seen with it is that it applies patches at the user level, but not at the kernel level. That was a problem in terms of our security architecture because it doesn't recognize that the patch has been installed. I evaluate the customer service or tech support for Red Hat Enterprise Linux (RHEL) as needing improvement; addressing the tickets takes a little longer and there has been a lack of consistency. Not every engineer who handles a case handles it correctly. Everybody has a different way of handling the tickets. So, the support needs to be a little bit more streamlined.

The challenges that we've had with different servers that don't have access to the internet require an installation, and keeping track of all the different versions on the different deployments is a challenge. I would love a feature that could manage the agent versions. On the Ansible side, from what I've seen, there are certain templates and playbooks that can be used for specific use cases that I'd like to see in the next release.

For now, Red Hat Enterprise Linux (RHEL) works fine for me. When I used it in the past, I don't see what I can improve now because it works the way I want it. There aren't any additional features that I think should be included in the future since you have AI now, and I think you are up to date.

Red Hat Enterprise Linux (RHEL) could be improved with frequent updates.I think frequent upgrades should be included in the next release of Red Hat Enterprise Linux (RHEL).

In terms of additional features for the next release, I saw it comes with AI integration, but we don't know the architecture yet. We want to see it first, then we can say. AI will be important for us.

I don't have specific feedback on what works well and what Red Hat Enterprise Linux (RHEL) needs to improve on. I cannot think of any additional features that should be included in the next release.

Red Hat Enterprise Linux (RHEL) could be improved by providing end-to-end support for customers because we are seeing that it is more distributed. For all the Red Hat services, we use Satellite, but other services are on the cloud, and some things are hybrid cloud. This means we have multiple platforms to monitor each time. Another area for improvement is the false positives. We have the Red Hat alarm system, and it is good, but it just fires and reports, sending an email every night for us to check our duties. This is really unpleasant for us.

I don't believe there are any additional features that should be included in the next release.

The implementation had challenges like whenever we bring out new products, there's always one issue: Red Hat Enterprise Linux (RHEL)'s documentation is not complete. I have to really have an enterprise account because I get access to their support, which sorts me out since every environment is unique. It's not a cookie cutter; I would deploy RHEL 8 in a way different compared to a retail store. So when it gets to those niche deployments, they don't have anything documented. I really have to get hold of the support, saying, "Hey, I'm trying to do this. It's not working," and then they will give me a solution, but I would expect that a document would have solved that issue without raising a ticket. That's my only complaint. The area for improvement in Red Hat Enterprise Linux (RHEL) is documentation. I don't have any other suggestions. I think it's just the documentation that needs improvement. Otherwise, technically, I don't have anything to suggest.

I am interested in migrating to the cloud platform, so we are trying to implement that in the organization.

From a business perspective, Red Hat Enterprise Linux (RHEL) is high in price, which has made our management less interested recently, not because of instability. However, sometimes we try to adapt some open-source alternatives such as Rocky Linux.

A key area for improvement is the ability to apply patches without requiring a full server reboot. This would minimize downtime for mission-critical applications. I’m actively evaluating Red Hat’s live kernel patching solutions and advocating for their adoption to further enhance our uptime and operational efficiency.

Red Hat Enterprise Linux (RHEL) can be improved by adopting a feature similar to YaST from a big European competitor, which would significantly enhance Red Hat technologies.

Red Hat Enterprise Linux (RHEL) could be improved with more shared storage capabilities. For example, I have multiple RHEL instances, and enhanced storage sharing would be helpful for transferring data between servers.

RHEL is a pretty polished product, however, if it becomes more mainstream compared to other Linux distributions and if more people adapt it, it would be used as a much more universal product. This would make it easier for people to adapt to RHEL.

The pain points that Red Hat Enterprise Linux (RHEL) helps me solve include the transition from a Microsoft background, where I had a habit of everything with a GUI. I see very few GUI elements in Red Hat Enterprise Linux (RHEL) and many command lines. I'm not proficient in that, which makes me struggle sometimes. Overall, we have the tools, however, there should be drag-and-drop, window-type functionality.

One of the pain points we have found is that for Windows systems, it is pretty easy to domain join those in a federated model. It seems we have to either have a third-party product or it is not quite as straightforward to domain join Linux OSs. This would be something that could potentially be smoother in the future. The knowledge base would be more helpful if it was more easily searchable. There might be opportunities to leverage AI for being able to search the knowledge base and articles more effectively.

I would suggest focusing more on the cloud-native aspect. Kubernetes and microservices are built in natively; however, it would help to bring the service mesh and service mesh handling. That would be one of the improvement areas. Most importantly, since we deal with mostly Fortune 500 clients who are global in nature, as the data is siloed from multiple sources and has to be pulled in, it's very important that the data is secure and all the security guardrails are in place. Since Red Hat Enterprise Linux (RHEL) 10 was recently launched, there were some bugs that needed to be fixed and performance issues. If those are cleared, then it would be a good fit for everyone.

I don't have much to say about how Red Hat Enterprise Linux (RHEL) can be improved.

Regarding security requirements from my side, Red Hat Enterprise Linux (RHEL) is somewhat satisfactory, but in most organizations, they are asking for more enterprise solutions for security. If Red Hat Enterprise Linux (RHEL) can invest in monitoring, it would be great. For example, Instana is an IBM product, and since IBM owns Red Hat Enterprise Linux (RHEL), if they invest in Instana, it will be a great improvement.

From a technical standpoint, Red Hat Enterprise Linux (RHEL) performs exceptionally well - it's reliable, straightforward, and functions as intended. The only significant concern isn't about the product itself but rather its pricing structure. Red Hat's recent changes to their pricing model have prompted some customers to question the cost and explore potential alternatives. While I can't speak to the business aspects, the feedback I've received consistently indicates that cost is the only notable concern. The product itself meets or exceeds expectations; it's purely the financial aspect that has raised discussion among users.

All major Linux distributions should have common commands, which would make it easier for users to understand and remember. Each flavor has their own native tools and features, which can be confusing when managing multiple flavors in a single environment. Documentation is comprehensive and available in one place on the Red Hat Enterprise Linux (RHEL) portal, but connection and integration could be better with more out-of-the-box connectors. Recently, I came across something interesting regarding the management of multiple environments. SUSE offers more flexibility in managing multiple environments, as their product can manage Ubuntu and Red Hat Enterprise Linux (RHEL). However, Red Hat Enterprise Linux (RHEL) Satellite server can only patch Red Hat and CentOS, not Ubuntu or SUSE. Cross platform support should be implemented in their product.

The solution has high pricing.

For telecom products and technical platforms that support RAN engineering, we expect more features to be added to satellite, as it is currently quite complicated.

They should be more generous in providing documentation in a friendlier way. The Red Hat Enterprise Linux (RHEL) documentation is good, yet not as good as other products such as IBM. Oracle, on the other hand, is the worst; they are very limited in sharing their documentation with engineers. The Asian support could use improvement.

The main concern is the price.

I believe they need to improve in terms of compatibility between services. I know that it's difficult to follow the different versions and maintain compatibility. For example, in OpenShift, they have several internal tools that are not completely compatible with the product, and that's an area they need to work on. Supporting different versions and ensuring compatibility between these versions is necessary for us to continue putting effort into this.

The performance of Red Hat Enterprise Linux ( /categories/operating-systems-os-for-business ) (RHEL) could be improved, especially under high load scenarios or when running applications involving AI. Providing support for AI in the knowledge base could be beneficial.

I am not sure what needs improvement as our customers haven't shared any specific feedback. Perhaps some minor enhancements like a more user-friendly knowledge base and faster technical support could be beneficial.

RHEL has experienced a change in approach after being acquired by IBM, and the company has shifted away from open-source principles. The knowledge base is now outdated and lacks documentation for features in RHEL 9, relying instead on old documentation from RHEL 7. The introduction of unstable and undocumented products also detracts from the product's reliability.

The price for Red Hat Enterprise Linux is more expensive than other operating systems, especially when compared to other cloud versions. The cost of a license for cloud deployment is cheaper than the on-premises license.

I don't know where Red Hat Enterprise Linux (RHEL) can improve; I just know that I don't use the cloud version, but I know the price, and I think it has many similar features to use JBoss with old features. In the last years, we have tried to quote a project using JBoss, but the license on cloud was cheaper than the on-premise license.

Red Hat has several areas ripe for improvement. In the Asia Pacific region, where cost-optimization is highly valued, Red Hat's support and subscription costs are perceived as high and could be reduced. While their security documentation is comprehensive, some solutions lack open-source availability or training resources, unlike platforms such as Ubuntu. Furthermore, the quality of documentation and training sessions, particularly for OpenShift, could be enhanced. Addressing these issues would strengthen Red Hat's offerings and better serve its customers.

Live patching should be improved.

Recently, Red Hat did a strange thing where they took over the CentOS project and changed several things in their pipeline. I don't believe that I, or the vast majority of Linux systems engineers out there, are fans of their development process for the operating system. The way that Red Hat used to work was that they had a free version. It was the community version called CentOS. Everything that Red Hat developed, they backported to the CentOS community. About four or five years ago, they took over the CentOS community and they killed off CentOS. They were pushing the Red Hat Enterprise Linux stream variant, which was supposed to be the replacement. I wish they would just go back to the way it was before. I do not like the new development process and the new hierarchy. The vast majority of people in the Red Hat open-source community also do not care for it much.

Integrating certificates from third-party clients into Red Hat Enterprise Linux can be challenging due to the operating system's stringent security policies.

There is room for improvement in terms of pricing and its knowledge base. I consider the cost high. The knowledge base is extensive and deep but can be confusing due to outdated or non-applicable information that you have to sift through to find relevant answers.

Red Hat should improve its support services, specifically the responsiveness and expertise of its India-based team. Response times need to be faster, and support staff should have access to more detailed procedures to address customer cases effectively.

The cost of Red Hat Enterprise Linux is a bit high. Red Hat Enterprise Linux's support could be improved by offering human support in addition to their documentation. While their documentation is helpful, it can be frustrating to be referred to it instead of receiving direct assistance from a support representative.

The implementation and limitations of SELinux should be re-evaluated. Its current configuration presents numerous challenges and restricts certain functionalities, hindering the overall usability of Red Hat Enterprise Linux. Addressing these limitations would significantly enhance the operating system's flexibility and efficiency.

I'm seeking a streamlined method for migrating from an OpenShift environment to a VMware virtualization platform utilizing Red Hat Enterprise Linux. The price of Red Hat Enterprise Linux always has room for improvement.

There are performance issues with the response time when accessing the console, but I'm unsure if that's Red Hat Enterprise Linux's fault or if it's due to the lack of CPU or memory on our machines. The enterprise interface could be improved. I can only use the keyboard to transfer files from one system to another. I want to use my mouse on the interface, not just scroll up and down. I would also like my logs archived as an RAR and sent to me.

It is not very easy to manage because it has a command line interface, and it can be a little bit confusing from one version to another. For example, the administration of Red Hat Enterprise Linux 8 is a bit different than Red Hat Enterprise Linux 9. It is a little bit hard but not that much. The GUI experience can be better. They can make it easier to access files and copy them. We should be able to do that without the command line. For example, if you compare it with Windows, Windows is easier to use. They can just simplify the user experience.

Using Red Hat Enterprise Linux on the cloud can become costly over the long term.

When moving workloads between different clouds or data centers, it's not that simple. There are a lot of things that you need to consider, including prerequisites and things like hardware, network, operating systems, et cetera. Once you get the hang of it, it becomes easier. However, in the beginning, it was very, very challenging. Coming from a development background, I found it easier to use command lines. I've hit some snags doing updates or changing things for clients. It would be nice if they improved vulnerability management. They could add more security tools and tools for provisioning.

After installation, the initial setup can be simplified or improved a little bit for new users coming from a distribution like Ubuntu or Windows. For example, for Arch, the user guide is very good. If a user does not have any experience, he or she can refer to the guide and install it successfully, whereas, for Red Hat Enterprise Linux, the user needs to have some understanding of Linux.

Any form of technology always has areas for improvement, and Red Hat is no exception. They continually strive to enhance their products, evident in the frequent releases of new versions and updates to their operating system. Given that there is no perfect operating system, further development will always be needed. To facilitate this process, Red Hat provides support and encourages community involvement to identify and implement solutions that enhance its operating system's overall functionality, effectiveness, and user experience.

While Red Hat offers essential starting and security documentation, I would like to see it officially recognize the more detailed and customized documents available in the community and make them accessible on its website.

There are not a lot of areas to improve because the majority of the time, Red Hat is constantly improving it. The only area would be in regards to being capable of running on other architectures like ARM. They are about to release a new version that is available to be executed on ARM architecture.

Red Hat Enterprise Linux could improve its AI features, which we look forward to. We have been a bit disappointed with the documentation, finding it hard to locate the information we need. Better automation and easier sourcing of information would be beneficial, especially in the context of Red Hat Enterprise Linux AI.

I am not too sure how it could be better. I have not yet used Red Hat Enterprise Linux 9, so I cannot say if there have been any changes or improvements. Honestly, I cannot see it getting any better. I like the way the operating system works now, and I do not really see any bad functionality with it. The only thing I would say is getting rid of some aspects. That is the one part that a lot of admins probably get annoyed with. For example, we are now going to DNF from using YUM. At some point, YUM will be taken away completely, but right now, you can use both. There are those minor tweaks, and you just have to roll with the punches. Maybe it is just a better version of what was there prior. DNF is probably used at a simpler level, and it probably does not take up as much configuration and space as YUM. I am not sure exactly why they make those changes, but that is probably the only thing that is kind of annoying.

The bootup time for Red Hat Enterprise Linux running on physical hardware in the data center can be improved. We have seen cloud-based Red Hat Enterprise Linux, and it is instantaneous. You wait for a few seconds, and the operating system is up and running. It is a lot faster, whereas it takes a very long time when running Red Hat Enterprise Linux on physical hardware. We used Red Hat Insights, but we are more focused on compliance, patching of operating systems, and things like that. In the past, when we looked at Red Hat Insights, it was its own platform, and then it migrated to Satellite. Companies are struggling to be compliant from the security side. Everyone is focused on how to patch the systems, what the environment looks like, whether they are under 90-day CVE, how their environment is compliant, and where they can see it as a dashboard. I wish Red Hat Insights was focused on that. From the Red Hat perspective, I am not seeing any sessions. I do not see anyone talking about that, which is a huge deal for us. I would like Red Hat Insights to go to the next level where it is focused on patching and compliance. I do not have any other areas of improvement. It has been stable for us. There is a lot we do in terms of automation and integration. I know Red Hat 8 now has Podman for containers. Cockpit has a UI, so that is good now. That helps with certain things.

It is not broken. Linux is Linux. It has been since Torvalds created the kernel back in version one of the kernel. We have added more features. More things have come to Linux and kernel. All the AI stuff is a bunch of buzzwords. In the keynote today at the Red Hat summit, Chris Wright talked about lightspeed coming to Red Hat Enterprise Linux. What do we need that for? What are we doing with AI? Just the stability of it is fine. If anything cool comes out, I will be the first to check it out. It is a stable platform. It is a workhorse, and that is how we use it. However, there should be training materials for new enterprises that do not cost an arm and a leg. Red Hat training is phenomenal, but it is expensive. There has to be a better way to onboard new engineers into Linux to really and truly compete with Microsoft. Microsoft is just easy. Everyone uses it. You have to use it in school, and you have to use it everywhere. From an onboarding perspective, we can improve and have an affordable training solution for someone who might not want to be an RHCE or an RHCA but still needs to do their job. It is not Linux's fault. It is what it is. It is a workhorse. It does its thing, but we can do better to enable customers to utilize Linux better.

Red Hat should keep doing what they have always done. They should continue to be a leader in the open-source space. They should keep innovating and keep creating great products. They can allow more access to their training and their products' testing. There are ways to do it now. You might have to get a certain type of account to test their products. It might be easier if you can just download the product and test it out.

I feel like it is going all over the place now. Sometimes it is hard to figure out what is going on. I would like more guidance. We definitely spend a lot of time developing on top of things, but I am not sure what on the Red Hat Enterprise Linux side can be better.

I have not used it on the cloud side. I have not heard much about how Red Hat is doing on the cloud side. In the market, AWS and Azure are very popular, and they have captured most of the market. If Red Hat can improve on the cloud side, they can retain their customer base. Their customers do not need to go out for other cloud resources, and they can use the Red Hat cloud. We are using it on-prem and in the virtual environment on VMware. We are using a cloud, but it is not a Red Hat cloud. We are using AWS in our organization. We have some EC2 instances deployed with Red Hat Enterprise Linux images, but I cannot say it is a Red Hat cloud. It is an AWS cloud, and we have instances. We are depending on a third-party cloud. If Red Hat provides that kind of service to our company, we can retain Red Hat. We do not need to go for a public cloud.

I am looking for training. I am a Windows guy who accidentally became a Linux guy. You volunteer a few times, and you are the guy. Right now, I am looking for training and ramping up to be able to support their products, so professional services are key. There are things like Lightspeed with IBM Watson. I do not know YAML very well, so it is going to be integral for me to create playbooks at the very beginning and be able to use the AI tools. If I say, "How do I open a port on this Cisco router?", the AI tools are going to give me the YAML code. In spite of not being a Linux guy or a great coder, I can use those tools to ramp up very quickly. Making Lightspeed a part of Red Hat deployment initiatives tremendously helps with customers' success. It gives them that extra tool. Right now, it is being sold separately as a subscription. If they could integrate that capability, people would not have to go use ChatGPT and other tools. They could use that as a part of it. It would just align things with Red Hat, so one area they can improve on is the approach to customer success for new deployments. Red Hat Insights are instrumental in identifying vulnerabilities. I am still learning, but my understanding is that it is not directly connected to your environment to deploy a patch or vulnerability fix. It is going to give a YAML playbook to do that. It does not actually execute it. On the Windows side, I have an approval process on the server where I can say, "Deploy this patch." I thought of Insights along the same lines where I can just approve things, and then based on some backend configuration, it will implement them using Ansible, Satellite, and on-premises Ansible. It seems disconnected right now. It might not be, but to me, there seems to be a gap there. I love Insights, and I want to fully automate that approval process. This could be a point for improvement if it does not already do that. Another area of improvement is Red Hat expressing a return on investment better. I do not know if they have determined a lot of that. I have always assumed that I could go with an open-source OS in a less expensive manner than Windows or something else. My impression is that there would be less cost, but I do not know that for certain. Red Hat building out some of that ROI on different products would be beneficial to their sales effort.

I would probably focus more on a rolling release schedule. Instead of a long-term operating support of ten years, I would just have one release and keep rolling it. In terms of security features, overall, it is lacking cohesion. There are a lot of different options, and it is hard to choose the ones that best fit our business needs without a lot of investigative work.

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.

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.

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.

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 high cost of Red Hat Enterprise Linux has room for improvement. The high cost in terms of a platform is problematic.

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.

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

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.

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.

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.

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

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.

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.

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

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

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.

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.

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

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.

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.

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.

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

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

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.

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.

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.

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

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.

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.

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.

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

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.

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.

The solution should improve its documentation.

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.

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

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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

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.

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.

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.

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.

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.

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

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.

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.

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

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.

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.

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.

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.

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.

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.

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 would like to see improvements made to the subscriptions and management of them.

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.

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

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

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

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.

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.

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

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.