Welcome back to Boston, Massachusetts. We're here at the seaport. You're watching theCUBE's coverage of Red Hat Summit 2022. My name is Dave Vellante and Paul Gillan is here. He's my co-host for the next day. We are going to dig in to the famous rel, Red Hat Enterprise Linux. Gunnar Helix in the series, the vice president and general manager of Red Hat Enterprise Linux. Gunnar, welcome to theCUBE. Good to see you. Thanks for having me. Nice to be here, Dave. Nine is, wow, nine. Holy cow. It's been a lot of iterations. That's the highest version of rel we've ever shipped. Yeah, and now we're talking edge. Yeah, that's right. So what's inside, tell us. So we've got three people we need to keep happy with a new rel release. The first is the hardware partners, right? Because they rely on rel to light up all their malicious hardware that they're making. And you got application developers and the ISVs who rely on rel to be that kind of stable platform for innovation. And then you've got the operators, the people who are actually using the operating system itself and trying to keep it running every day. And we got something for everybody, I think. So we've got on the, I'll start with the hardware side, which is something, as you know, rel's success. And I think you talked about this with Matt just in a few sessions earlier, that the success of rel is really hinges on our partnerships with the hardware partners. And in this case, we've got, let's see, in rel nine, we've got all the usual hardware suspects. And we've added, just recently in January, we added support for ARM servers as a general ARM server class hardware. And so that's something customers have been asking for. Delighted to be shipping that in rel nine. So now ARM is kind of a first class citizen, right? Alongside x86, power, Z, and all the other usual suspects. And then of course, working with our favorite public cloud providers. So making sure that rel nine's available in AWS and Azure and GCP and all of our other cloud friends, right? So we're seeing, you mentioned ARM, is we're seeing ARM in the enterprise. We're obviously seeing ARM at the edge. You guys have been working with ARM for a long time. You're working with Intel, you're working with NVIDIA, you've got some announcements this week. Gunnar, how do you keep Linux from becoming Franken OS with all these capabilities? Yeah, yeah, this is a great question. So first is, the most important thing is to be working closely with, the whole point of Linux and the reason why Linux works is because you have all these people working together to make the same thing, right? And so fighting that is a bad idea. Working together with everyone, leaning into that collaboration, that's an important part of making it work over time. The other one is having, just like in any good relationship, having healthy boundaries. And so making sure that we're clear about the things that we need to keep stable and the places where we're allowed to innovate and striking the right balance between those two things. That allows us to continue to ship kind of one coherent operating system while still keeping literally thousands of platforms happy.  Yeah, that's right. So the idea is that what we strive for is consistency across all the infrastructures and then allowing for kind of optimizations and we still let ourselves kind of take advantage of whatever indigenous feature might appear on the mustn't such an ARM chip or thus in such a cloud platform. But really we're trying to deliver a uniform platform experience to the application developers, right? Because they can't be having, like they can't be kind of one version of RHEL over here and another version of RHEL over here. The ecosystem wouldn't work. The whole point of Linux and the whole point of RHEL is to be the same so that everything else can be different. What incentives do you use to keep customers current? To keep customers current. Well, so the best thing to do, I found is to meet customers where they are. So a lot of people think we release RHEL 9 at the same time. We have Red Hat Enterprise Linux 8, we have Red Hat Enterprise Linux 7, all these are running at the same time and then we also have multiple minor release streams inside those. So at any given time we're running, let's say a dozen different versions of RHEL are being maintained and kept up to date and we do this precisely to make sure that we're not force marching people into the new version and they have a Red Hat Enterprise Linux subscription. They should just be able to sit there and enjoy the minor version that they like and we try and keep that going for as long as possible. You think it's 10 years out of date? Well, so 10 years, interesting you chose that number because that is the end of the life, right? And so 10 years is about as that's the natural life of a given major release. But again, inside that you have several 10 year life cycles kind of cascading on each other, right? So nine is kind of the start of the next 10 year cycle while we're still living inside the 10 year cycle of seven and eight. So lots of options for customers. How are you thinking about the Edge? How do you, that's not going to the definition but at a high level, like I've been at a conference last week, it was Dell Tech World, I'll just say they sort of, the Edge to them was a retail store, right? Lowes. Okay, cool, I guess that's kind of edgy, I guess. But I like, I think space is the Edge or a vehicle. How do you think about the Edge? All of the above or, but the exciting stuff to me is that Far Edge, but I wonder if you can comment. Yeah, so there's all kinds of taxonomies out there for the Edge. For me, I'm a simple country product manager at heart and so I try to keep it simple, right? And the way I think about the Edge is here's a use case in which somebody needs a small operating system that deploys on a probably a small piece of hardware, usually varying sizes, but it could be pretty small. That thing needs to be updated without any human touching it, right? And it needs to be reliably maintained without any human touching it. Usually in the Edge cases, actually touching the hardware is a very expensive proposition, so we try and be as hands-off as possible. No truck rolls. No truck rolls ever, right, exactly. And then now that I've got that stable base, I'm going to go take an application, I'll probably put it in a container for simplicity's sake and same thing, I want to be able to deploy that application and if something goes wrong, I need to be able to roll back to a new and good state and then I need a set of management tools that allow me to kind of touch things, make sure that everything is healthy, make sure that the updates roll out correctly, maybe do some A-B testing, things like that. So I think about that as that's the, when we talk about the Edge case for RHEL, that's the kind of the horizontal use case and then we can kind of do specializations inside particular verticals or particular industries, but at bottom, that's the use case we're talking about when we talk about the Edge. And then the assumption of connectivity at some point. Yeah, you don't have to always be on, right? Intermittent, latent, eventual connectivity. Yeah, that's right, yeah, that's right, that's right. Yeah, that was originally a one-track pony. I mean, RHEL was it and now you've got all of these other extensions and different markers that you expanded into. How do you, what's your role in coordinating what all those different functions are doing? Yeah, so what I find is that the, you look at all the innovations we've made, whether it's in storage, whether it's in open shifts and elsewhere, RHEL remains kind of the beating heart, right, it's the place where everything starts and so a lot of what my team does is we're trying, yes, we're trying to make all the partners happy, we're also trying to make our internal partners happy, right? So the open shift folks need stuff out of RHEL just like any other software vendor. And so I really think about RHEL as yes, we're a platform, yes, we're a product in our own right, but we're also kind of a service organization for all the other parts of the portfolio. And the reason for that is we need to make sure all this stuff works together, right? Part of the whole reasoning behind the Red Hat portfolio at large is that each of these pieces build on each other and complement each other, right? And so that's a, I think that's an important part of the Red Hat, the RHEL mission. There's an article in the journal yesterday about how the tech industry was sort of, you know, pounding the drum on H1B visas. There's a limit, I think it's been the same limit since 2005, 65,000 a year. We're facing, your customers are facing, you guys I'm sure as well, we are, you know, real skills shortage, so it's not a lack of talent. How are you seeing companies, you know, deal with that? What are you advising them? What are you guys doing yourselves? Yeah, yeah, yeah, so it's interesting, especially as we're going through, everybody went through some flavor of digital transformation during the pandemic and now everybody's going through some and kind of connected to that, everybody's making a move to the public cloud. Well, they're also like, they're making operating system choices when they're making those platform choices, right? And I think what's interesting is that what they're coming to is, well, I have a Linux skills shortage and for whatever, for a thousand reasons, the market has not provided enough kind of Linux admins. These are very lucrative positions, right? You would command a lot of money, you would expect their supply would eventually catch up, but for whatever reason, it's not catching up. So, okay, I can't solve this by throwing bodies at it, so I need to figure out a more efficient way of running my Linux operation. People are making a couple of choices. The first is, they're creating, ensuring that they have consistency in their operating system choices, whether it's on-premise or in the cloud or even out on the edge. If I have to juggle three, four different operating systems as I'm going through these three or four different infrastructures, that doesn't make any sense, because the one thing that is most precious to me is my Linux talent, right? And so I need to make sure that they're consistent, optimized, and efficient. The other thing they're doing is tooling and automation, especially through tools like Ansible, right? Being able to take advantage of as much automation as possible and much consistency as possible so that they can make the most of the Linux talent that they do have. And so with Red Hat Enterprise Linux 9, in particular, your CS make a big investment in things like more automation tools for things like SAP and SQL Server deployments. You'll see us make investments in things like basic stuff like with the web console, right? But we should now be able to go and point and click and do basic Linux administration tasks that lowers the barrier to entry and makes it easier to find people to actually administer the systems that you have. As you move out onto these new platforms, particularly on the edge, many of them will be much smaller, limited function, how do you make the decisions about what features you're going to keep or what you're going to keep in RHEL when you're running on a thermostat? Oh yeah, yeah, yeah. Okay, so let me be clear. I don't want RHEL to run on a thermostat. I can't handle the margins on something like that. But at the end. You're running on the GM. Yeah, no, that's right. And so the choice of the, the most important thing we can do is give customers the tools that they need to make the choice that's appropriate for their deployment. I have learned over several years in this business that if I start choosing what content a customer wants on their operating system, I will always guess it wrong, right? So my job is to make sure that I have a library of reliable, secure software options for them that they can use as ingredients into their solution. And they give them tools that allow them to kind of curate the operating system that they need. So that's the tool like Image Builder, which we just announced. The Image Builder service lets a customer go in and point and click and kind of compose the edge operating system that they need, hit a button, and now they have an atomic image that they can go deploy out on the edge reliably, right? Can you clarify the cadence of releases that you guys, the change that you made there, why that change occurred, and what's the standard today? Yeah, so back when we released REL 8, so we were just talking about hardware and its ARM and X86, all these different kinds of hardware. The hardware market is, internally, I tell everybody, the hardware market just got real weird, right? It's just got the schedules are crazy. We've got so many more entrants. Everything is kind of out of sync from where it used to be. Used to be there was a, there was a metronome, right? You mentioned Moore's Law earlier. It was like an 18 month metronome. Everybody could kind of set their watch to. That's, so that's gone. And so now we have so much hardware that we need to reconcile. The only way for us to provide the kind of stability and consistency that customers were looking for was to set our own clock. So we said three years for every major release, six months for every minor release. And that we will ship a new minor release every six months and a new major release every three years, whether we need it or not. And that has value all by itself. It means that customers can now plan ahead of time and know, okay, in 36 months, the next major release is going to come on. And now that's something I can plan my workload around this and think I can plan a data center migration around and things like that. So the consistency of this, and it was a terrifying promise to make three years ago, I am now delighted to announce that we actually made good on it three years later, right? And plan to again in three years from now. Is it, good, is it, I was just following up. Is it primarily the processor optionality and diversity? Or as I was talking to an architect, system architect the other day, and his premise was that we're moving from a processor centric world to a connect centric world, not just the processor, but the memories, the IO, the controllers, the NICs, and it's keeping that system in balance. Does that affect you or is it primarily the processor? Oh, it absolutely affects us, yeah. Yeah, so the operating system is the thing that everyone relies on to hide all that stuff from everybody else, right? And so if we cannot offer that abstraction from all of these hardware choices that people need to make, then we're not doing our job. And so that means we have to encompass all the hardware configurations and all the hardware use cases that we can in order to make an application successful. So if people want to go disaggregate all of their components, we have to let them do that. If they want to have a kind of more traditional, kind of boxed up OEM experience, they should be able to do that too. So yeah, this is what I mean is because it is relish of responsibility and our duty to make sure that people are insulated from all this chaos underneath, that is a good chunk of the job. The hardware in the OS used to be inseparable, right? Before let us hear about it, so that's the importance of hardware. Yeah, that's right. I'm curious how your job changes.  Not at all, so the only constant is change, right? And to be honest, a major release, that's a big event for our release teams, that's a big event for our engineering teams, it's a big event for our product management teams. But all these folks have moved on, and we're already planning, REL 9.1 and 9.2 and 8.7 and the rest of the releases. And so it's kind of like brief celebration and then right back to work. Yeah, yeah. So what can we look forward to? What's the future look like of REL? REL 10. Oh, yeah, more bigger, stronger, faster, more optimized for, doesn't such, and yeah. Longer, lower, wider. Yeah, yeah, that's right, yeah, that's right, yeah. I am curious about CentOS Stream, because there was some controversy around the end of life for CentOS and the move to CentOS Stream. A lot of people, including me, are not really clear on what Stream is and how it differs from CentOS. Can you clarify that? Absolutely, so when Red Hat Enterprise Linux was first created, this was back in the days of Red Hat Linux, right? And because we couldn't balance the needs of the hobbyist market from the needs of the enterprise market, we split into Red Hat Enterprise Linux and Fedora, okay? So then for 15 years, yeah, about 15 years, we had Fedora, which is where we took all of our risks. That was kind of our early program where we started integrating new components, new open source projects and all the rest of it. And then eventually we would take that innovation and then feed it into the next version of Red Hat Enterprise Linux. The trick with that is that the Red Hat Enterprise Linux work that we did was largely internal to Red Hat and it wasn't accessible to partners and we've just spent a lot of time talking about how much we need to be collaborating with partners. They really had, a lot of them had to wait until like the beta came out before they actually knew what was going to be in the box. Okay, well that was okay for a while but now that the market is the way it is, things are moving so quickly, we need a better way to allow partners to work together with us further upstream from the actual product development. So that's why we created CentOS Stream. So CentOS Stream is the place where we kind of host the party and people can watch the next version of Red Hat Enterprise Linux get developed in real time. Partners can come in and help, customers can come in and help and we've been really proud of the fact that Red Hat Enterprise Linux 9 is the first release that came completely out of CentOS Stream. Another way of putting that is that Red Hat Enterprise Linux 9 is the first version of RHEL that was actually built 80, 90% of it was built completely in the open. Okay, so that's the new playground. Yeah, that's right. You did get a lot of negative pushback when you made the announcement. Is that basically because the CentOS users didn't understand what you were doing? No, I think that the CentOS Linux, CentOS, when we brought CentOS Linux on, this was one of the things that we wanted to do is we wanted to create this space where we could start collaborating with people. Here's the lesson we learned. It is very difficult to collaborate when you are downstream of the product you're trying to improve because you've already shipped the product and so once you're for collaborating downstream, any changes you make have to go all the way up the water slide and go for it, they can head all the way back down. So this was the real pivot that we made was moving that partnership and that collaboration activity from the downstream of Red Hat Enterprise Linux to putting it right in the critical path of Red Hat Enterprise Linux development. Great, well thank you for that, all right, thanks for coming on theCUBE. It was great to see you. My pleasure. Have a great day tomorrow. Thanks. And we look forward to seeing you tomorrow. We start at 9 a.m. East Coast time. I think the keynotes will be here right after that to break that down ball, killing it myself. This is day one for theCUBE's coverage of Red Hat Summit 2022 from Boston. We'll see you tomorrow. Thanks for watching.