Red Hat Enterprise Linux (RHEL)

I think it's best suited for all the monolithic application where you just need a VM and you on top of that VM you need to install a compatible product. So it's best suited for those. Where's not suited. As I said, maybe I've seen in my organization mostly our internal application teams, they go for a different operating system for appliances or network maybe it might be due to the product compatibility, not with Red Hat Enterprise Linux (RHEL), but that's something maybe you should have a look or probably it's not a improvement anywhere.

So anyone that's running an application that runs on a Linux distribution, Red Hat Enterprise Linux (RHEL)'s a great option for that. Things that aren't going to work well with it. A lot of times vendors provide their own custom build operating system. So you can't use Red Hat Enterprise Linux (RHEL) in that instance.

More suited for business or professional use. For smaller use like a laptop or pet project id recommend another OS. Especially because certain repos have more support for smaller stuff like that like in Debian. Though professionally it is definitely second to none id much rather recommend Red Hat Enterprise Linux (RHEL) than something like Ubuntu.

I would say for enterprise server management for just essentially servers that don't require GUI or that you want to run in a kind of secure, standalone fashion. I think it does become difficult with integrating with different identity providers. So that can be a pain point as far as integration with active directory or any kind of ldap. But I would say as far as just being able to provide confidence that you're deploying a secure product from the outset and that it serves the needs of the different infrastructure as far as compatibility with a lot of software that's built on the platform. So I think it's really helpful for serving that server software in the cloud or on virtual machines wherever.

After a Nessus scan, there are many changes that need to be made manually. Following the instructions, most of these scenarios can be easily resolved, but there are a few that require a lot of work to solve. It would be nice to have a pre-hardened version that can be installed directly.

Some things require windows systems. Which is weird. But other than that Red Hat Enterprise Linux (RHEL) all the ways.

I would use RHEL for some applications, I would not use it as an authentication source.

As a workstation there are still some that do not think it is ready. I have used the workstation part but not much. The server side has been the main product that I rely on for mission critical applications. While nothing is perfect I can not think of any thing that I have specifically been disappointed with

I've been an administrator for Red Hat Enterprise Linux (RHEL) for more than 10 years now. I can't really imagine using another OS. Nothing else has the same combination of features, security, and power.

It’s very used the Red Hat Enterprise Linux (RHEL) in the business because it’s secure and easy to work.
the coworker feels comfortable with Red Hat Enterprise Linux (RHEL).
when the system is emergency mode it’s very easy , come back to o.s. It’s no difficult and the apps works very well.
in the other the vulnerability it’s very quickly and de deployment with Ansible

Being Linux kernel it is accessible, and very adaptable. This allows for integration with other systems that we use as a company

Red Hat Enterprise Linux is well suited for virtualization; Verizon runs its internal private cloud on it.

RHEL is the Unix of choice

stable production environment

Red Hat Enterprise Linux is great for enterprise business solutions where a lot of different machines needs to be managed. RedHat provides a lot of different platform to help you gain control. On the other hand. RedHat should support more development based solutions where you can install the system and start development. Currently a lot of configuration is required before you can start to develop

I have an over all good experience with RHEL during a work environment. I have also used it in a lab environment at home where I would install additional applications on RHEL 6 7 and even RHEL 8. I can't think of anything scenarios where it would not be appropriate

Suited for easy lift and shift

I guess to give it more context, my first job in the Linux ecosystem was in web hosting. And that was basically a Cintas shop and it was all run extremely lean and very bootstrappy do it on your own. You don't get any support. And for that environment, it was kind of just the way it is. It's very cutthroat. You have to move super fast. Once I moved over to the corporate side, every company I've worked with has been on rail. And the thing that really kind of makes it the best choice compared to using another operating system, another flavor of Linux and just kind of figuring out your own is the amount of support that Red Hat gives rail as far as extra tools like Satellite Insights and what's coming up now with Ansible and especially Ansible. Lightspeed, but also SLAs and stuff like that. Because yeah, I mean it was good learning in that first environment because there were no tickets, there was no support. It was figured out. But nowadays it's just nice to have an SLA agreement. I can just open a ticket. I say that that's something that does really well, but I also want to see it expanded, just more like vendor support at an enterprise level. I'm not sure yet what that would mean. I just have that every time we come up for renewal, I look at the price tag and it's like, what else can we do here? I like what Red Hat is doing just more.

Where it's very well suited is just if you're rolling out systems quickly, web front ends, and so forth. I think it's really well suited for that. Even backend operations. It does a good job. However, I do think that it's not as industrial-proven as other operating systems out there. Like say the banking industry, they love AIX, cause it's IBM, it's been around forever and it's rock solid. And to try to get that much computing power in an intel box is difficult. So RHEL is limited in what it can do versus some of the P series and I series stuff that IBM does.

Like I said before, with the automation environment RHEL is well suited to run the Ansible Navigator and the Ansible execution environment builder. So we can create our execution environment on RHEL natively instead of having to figure out how we do it as Ubuntu or other platforms.

It's well suited for installing pretty much anywhere and it's usually the documentation is very good and there's a lot of support from the documentation and training to make good use of the product. It's not as good as a workstation, it's better as a server product. It's not necessarily good in kind of other situations as well because of some of the licensing constraints.

I mentioned it provides a consistent base for our developers, for our applications. In an institution or enterprise where you want security, you want a specific type of setup to your system. Red Hat excels at that. It's not really geared toward that side of things, but we have users, I'm a power user who likes to use Linux on my daily commuter laptop and I prefer to use a Fedora or a Debian than a Red Hat just for the difficulty of configuring a specific use case like an end user would be.

Critical production environments are the best for RHEL case as the product ensures the security, stability and it is backed by the world class support that the most of the companies (and their shareholders) would appreciate.
It might not be too suitable for the startups or even some Dev teams within large enterprises, depending on their internal culture and practices. Though things definitely improved over the last few years and there is no strong case for the teams not to use RHEL nowadays.

In my opinion RHEL is extremely capable for most all work done. Maybe not as easy for some office type applications but still very capable.

Development environment for developing microservices based solutions. The orchestration to carry new applications from development to production deployment.