 Let's get into the big topic of open source, something that we actually have in front of us. This is so awesome. We are an open culture that is actually putting some space in that process that a developer, or let's say... How's the Kubernetes ecosystem really doing that? Welcome to In the Cloud. I am your host, Stu Miniman, and this is the May is the whole month. Yesterday was Star Wars Day, or May the Fourth be with you, and that, of course, makes today Revenge of the Fifth. So, needed to get all the Star Wars puns out of the way, because at Red Hat, yes, we do celebrate Star Wars Day. We all bring our whole selves there, and I've been wearing lots of Star Wars gear all week, but it is also a very special week this week at Red Hat, because it is Rail Week, which is Red Hat Enterprise Linux. I'm sure anybody watching this knows. Tomorrow, actually, is the 20th anniversary of Rails. So, to help us celebrate that and talk about all that's new and what's been going on with the development of Rail Nine, really happy to welcome to the program Gunnar Helixen, who's the Vice President and General Manager for Linux here at Red Hat. Gunnar, thanks so much for joining us, and Happy Rail Week. Hey, Happy Rail Week. It's like Christmas, Easter, all rolled into one. Yeah, so, boy, Gunnar, it's funny. So, you know, you haven't quite been at Red Hat for 20 years. I've only been at Red Hat for a year and a half, but I remember when, you know, it's funny. It was, you know, Raz 2.1 came out, which eventually turned into Rail 20 years ago. I was working for a large storage company. You know, we needed enterprise workloads in production, and oh my gosh, the Linux 2.4 kernel, what a mess. We had pages of patches that customers needed to use to be able to support it. We only had a very small team of engineers doing that testing. And when Red Hat kind of separated itself from the pack and said, here's an offering that can work, you know, I as, like, a product and program manager told our field, like, hey, this is the default for what you will use, and, you know, of course, you know, here we are 20 years later where Linux is. So, you know, take a second. Step back, you know, where we came from, and boy, you know, a lot has changed in 20 years. Yeah, it has. If you think about a, well, and it's not just relevance changed, right? It's the entire Linux landscape has changed. We went from being kind of rough up stars, right? Everybody recompiling their own 2.4 kernel. I know that's what I did, right? And now it is, Linux is like water. It is everywhere. It's powering everything. It's, and I'm looking at my desk here. It's in at least one, two, three, four, six devices on my desk. It is, it's been an amazing journey for the whole Linux community. And then, of course, for Red Hat Enterprise Linux as well. Yeah. Yeah, no, you're so right. You know, one of the things I used to say as an analyst, if it wasn't for Linux, we probably wouldn't have the cloud. And maybe people said, Stu, we probably wouldn't have the internet of today if it wasn't for Linux. We don't need to think about it when I do, you know, a search on, you know, the web, or if I buy a product on the web, I think about the fact that there's Linux underneath that. So let's, let's talk about RHEL itself though. So, you know, a lot has changed. You talk from the self-compiling kernel to, you know, how many people at Red Hat here have, you know, a shrink wrap box behind them to talk about the deployment that they did of, you know, RHEL and, you know, Red Hat Linux before that to today, the development of what you've been doing in RHEL 9, it's a little bit different than what we've seen in the past. Yeah, yeah, that's right. So, excuse me, RHEL 9 will be the first release that we have done using the CentOS stream mechanism. So actually, let me do, I should do a history lesson, right? That's how we started, okay. So you mentioned we split Red Hat, we split RHEL, or sorry, when we split Red Hat Linux into Fedora and Red Hat Enterprise Linux. We did that in order to basically keep kind of a separation of concerns. We needed a place to go do kind of disruptive, innovative, risk-taking, and then we needed a place or, you know, to do the, I think they call it, they like to call it the bleeding edge work, right? And then we needed a place where we could do the hardening and the stability and create something that somebody could use in, like, an permission-critical enterprise context. Okay, so now we've got Fedora over here and we've got Red Hat Enterprise Linux over here. This served us extremely well for a very long time. And so recently we made a change, though. We added an intermediate step, because what we found, especially with things moving so quickly, we needed a good way of better collaborating with our partners who they needed early access to what we were doing, but couldn't wait until we had fully productized it and so they needed something, they needed a middle step. And so that's why we introduced CentOS Stream. And so now the code kind of starts from the upstream communities. Tens of thousands of them flows into Fedora. From Fedora it flows into CentOS Stream. From CentOS Stream it flows into Red Hat Enterprise Linux. And so REL9 is the first release that was, has fully gone through that kind of, that cascading process. And it worked. And which I'm delighted about. This is kind of a risk for us and it certainly appears to have paid off. Yeah. So that development almost a little bit more in the open because it's always been open source and what's done, but that relationship with the community has changed a little. One of the other things gonna, I remember back, I believe it was three years ago when REL8 came out, one of the questions everybody always had is, what's a minor release? What's a major release? When do things come out? And we've reached a certain maturity level where there's a cadence going on. So tell us what that means when it comes to REL. So in, partially due to the process that I just talked about, when you release an operating system, you don't get to release it whenever you want because the hardware system has two jobs, right? Is to enable the hardware underneath and then you have to make sure that you're providing stability for the applications that live on top. So if you're shipping an operating system, you have to be thoughtful about when you're shipping it, especially when you have a lifecycle commitment like REL does. So when we ship, it's gonna be like that for the next 10, 13 years. And so often what we would do when we're trying to figure out when to ship the next version of REL is we would look at all hardware schedules and try and find exactly the right moment when it was just before this happened and just after this happened and get it right in the sweet spot there, and then that's how we chose the G8. That worked when the world of hardware was significantly more predictable than it is today. And so we realized with the release of REL 8 that if we were able to provide a certain amount of predictability, if people could plan ahead on when the next major version of REL was gonna happen, it would make planning your acquisitions, your upgrades, it would make that significantly easier. And so we made a promise with REL 8 that we were gonna ship a new major release every three years. And then the minor releases, the 8.1s, 8.2s, 8.3s, those would come out every six months. And so knock wood, we've been able to deliver on the promise so far. So like clockwork every six months, we come out with a new minor release. And then with nine, we are gonna fingers crossed. We're gonna be able to ship on time three years after the release of REL 8. Okay, cool. So if you saw right on screen there, we had a question of course when you talk about all that and says, you know, REL 9. So, you know, three years from when REL 8 is what I'm hearing. Yeah. Yeah. Just like we promised. Yeah. That's right. Okay. Awesome. Great. Thank you. And yeah. No, good to see people in the chat. Eric, the IT guy who does one of the red hat live streams is there. I know he's been doing a lot of the internal activity for row week this time. And I love what you talked about Gunnar. Cause when the kind of competing challenges that enterprises face and where red hats sits right in the middle is number one is there's that constant change. There's so much coming on. You know, I remember seeing it's like, you know, what's it, you know, a million lines of code change every month in the Linux piece. And on the other hand, the enterprise says like, Hey, I can't change this every month, every quarter. Sometimes I can't even change it every year. So how do you keep me up, get my security patches yet allow me to have longer life cycles. And of course that's what red hats been doing with all of our software product for a long time. That's what we do over in the open shift team following, you know, many of the things that the real team set the foundation for us. Talking about that, that, that complexity and what's out there. One of the driving factors in IT is, you know, we need things to be simpler. You know, I was joking to go to the cloud. The promise of the cloud is it's going to be cheap and simple. And when we actually get there, it's really neither of those things. So maybe tell us what's happening with the rail along this simplification axis. Yeah. So there, so if you think about, I'll answer it this way. I like to think about rail having kind of three different kinds of customers. Right. So the first set of customers is those hardware providers that I was that I was talking about. And they need to be able to have a, as you mentioned, like having, have a stable kernel that they can work against. And they need a stable kernel that they can write drivers for. Right. And so being able to, so, and I feel like that's a, we've done a pretty good job at that over the last 20 years. We made that pretty simple for folks. For people writing applications, that's the second kind of audience for the operating system. For people writing the applications we have, we provide a stability internally. We call it the ABI or the binary interface. Right. So we have a stable ABI and with rail we commit that when we do a new major version that major versions ABI will be stable throughout the lifetime. So if you've written an application for rail 8.1, it's going to continue working all the way through the eight, all the way through the eight cycle. So that's the threads. There's a third audience and I, and I think it's ironic that we only started talking about this third audience recently, but the third audience are the people who are actually using the operating system. We spend a lot of time thinking about the hardware folks, a lot of time thinking about the application folks, the developers. But I think only recently we've really spent a lot of time focusing, and this is in part due to, I think in part this is part of our own attention, but I think also this is a statement about the maturity of the Linux market in general. We're at the point now where we're doing things like shipping web consoles, GUIs, making things easier to use, making, first of all, people with mouse and keyboards, having, making GUIs easier to use, but also creating systems to make automation of Linux easier. Right. Because it's been a long time since we've touched a server with a mouse and a keyboard, right? People still do it, but the vast majority of servers out there are being managed not by people, but they're being managed by machines, right? It's automation systems like Ansible and so forth. And so when we talk about simplifying, a lot of what we're simplifying is we're simplifying the act of managing the system both for humans, through things like web consoles and GUIs and things like this, and also simplifying the management through these automation systems, and that's through investments so REL system roles are a, this is a fancy word for Ansible modules that we ship with REL, and these allow you to perform some like routine system tasks, both for REL and for some of our partner applications, so things like SQL server or SAP. If you use these system roles in order to manage your system, perform these routine tasks, you're insulated from a lot of the complexity of like, you know, so if we were to, for example, do something crazy, like change the time on REL, right, you don't have to go back and redo all of your automation because we changed the time system, if you're using a system role, the system role will take care of all those changes and insulate you from all those changes. And so anyway, that was a long answer, but I feel like simplicity in several dimensions is a good way to think about it, because the underlying system is not getting simpler, it's just always getting more complex, right? And so we have to kind of build more sophisticated systems to insulate these up, those underlying systems. So, you know, my background, I'm an infrastructure guy and I remember if you go back, you know, about 10 years ago, it was, oh, we're going to go all the white boxes, everything's going to be commoditized. The cloud should look at as this, you know, simple plane and I look at the cloud and I say if I wanted to play a server in the cloud, I think there's more complexity and options there than if I go to, you know, Dell, HP, Lenovo, choose your server of choice in my data center, there's more options there. I know a lot of work's gone on with ARM, there's there's new, you know, hardware architectures, so maybe speak a little bit to ARM and some of the other, you know, hardware diversity and what the operating systems had to do to make sure that, you know, Linux everywhere just works. Yeah, so I mean this is one of the core missions of RHEL, right, is to be available everywhere customers need us to be, right, and so we've always supported multiple micro architectures, so the X86 folks and Power and Z and so forth and just in January we announced that we made finally, made generally available RHEL for ARM so now ARM is a first class citizen just like all the other micro architectures and this was I mentioned before that the this kind of predictability of the hardware market, you know, it used to be you could set your clock, you know, every 18 months Moore's law, right, is okay, things are going to double every 18 months. They talk, they talk, right, that is no longer the case and that's due to lots of things, right, now we have new and exciting micro architectures like ARM and I know we have other up-and-comers coming, you know, so risk five people are starting to talk about meaningfully and we've got also the introduction of accelerators, right, so there's ASICS and FPGAs and GPUs and so as you, it's interesting watching the hardware market now because on the you have the public cloud providers who it's a commodity market, right, it's an economics center, it's a commodity market so they need to differentiate their offerings. The way they're going to differentiate their offerings is by having more and more exotic faster, more interesting hardware and then on the other side you have the folks shipping on-premise hardware and they have to do exactly the same thing because they have to be more they have to provide more interesting hardware than other hardware so now we've got this kind of self-licking, ice cream cone of differentiation right, it's everyone's kind of and what that ultimately is created is this very fragmented hardware market with like lots of overlapping interdependencies and lots of overlapping schedules which makes it a really interesting time to be an operating system because our whole, as I mentioned earlier, our whole job is to have to sit on top of all of that complexity and all those interlocking roadmaps and all those schedules and make sure that the customer still has the experience of being able to use RHEL, wherever you need to use RHEL regardless of whatever chaos is happening underneath so it's a very exciting moment. Gunnar, it's one of those, the customers expect it but they under-appreciate the amount of work that has to go into it. I had Mike Barrett who runs product management for OpenShift on two shows ago, so a month ago talking about OpenShift 4.10 and when it came to new support for Azure Stack Hub and the question I posed to him was, well, we've had RHEL and OpenShift running on Azure for years, isn't Azure Stack Hub just that Microsoft instantiation in customers data center? And Mike was like, well yeah it is but at the operating system level there are certain bits and configurations and settings that change and it's like, oh, it's where the marketing and the engineering reality works but the devil's in the detail we know and that's where Red Hat's experience working across all those environments and working closely with the ISV ecosystem. So I guess that sets up for the discussion of this hybrid multi-cloud world we talk about whatever term customers want to use. The reality is the diversity of applications and infrastructure that they're doing is even more diverse today and will continue to be more diverse in the future. So what does that mean? What's in RHEL 9 and what are the things that your team is looking at to live, thrive and enable our customers to innovate and take advantage of what's out there? Yeah, sure. So picking up on some of the breadcrumbs I just left behind certainly we're going to continue doing the things that all the RHEL needs to do, which is again insulate people from and let them I say insulate them from the complexity while still allowing them to take advantage of all of the interesting stuff that this hard work can do. That's kind of job number one and job number two is to number one create that stability that I talked about for the applications, but also you know it's interesting if you look at the RHEL something like 10,000 packages now. It's this conglomeration of like 10,000 upstream Opensworth projects. It's crazy the amount of software that it is, right? It's a no longer fits on a DVD, right? It's that big but if you look at what an actual like by the way for our younger audience a DVD with an optical disc that we use before we had streaming in the cloud and everything like that. Sorry, go ahead. That's right. I'm an old man. So if you look at these 10,000 packages only about 300 of them are kind of the operating system proper and then the question is why are we shipping the other 9,700 packages? Well, the reason we're shipping the other 9,700 packages is because over the last 20 years people have become accustomed to relying on Red Hat and RHEL to provide them with all of the interesting software that they need and they know that when we ship the software it's easier for them to get approval for their security or they know that basically they can trust us to be shipping the software and making sure that it's stable and that we're patching bugs and things like this. And so having taught people that they keep asking us to ship more stuff, right? And so the natural progression of RHEL is just to keep adding more packages and more packages. That's fine as far as it goes and it's work that we're happy to do but it's also true that with all of this change and with all of the options available you have some people who want to be using, say, Python 3 and some people who want to be using, say, Python 2 and they need to be able to do that on the same operating system. Well, one of the things that we provide in RHEL is something we call application streams and so this is the ability to basically pin yourself on a particular version of a particular runtime particular framework and so you can actually have Python 2 and Python 3 develop a kind of peacefully coexisting on the same operating system and in this way, again, simplification in this way we're able to let people take advantage of almost like RHEL as a supply chain and give people as many options as possible without sacrificing the stability that we've got. So if you want to go move more quickly with something like Ruby or Python or something like that you can go use those application streams if you want kind of a 10-year promise and a 13-year commitment on something that is super, super, super stable then you have that option as well and so, yeah, in this way we're RHEL is first an operating system but second it's also a library of dependencies that people can use in their own shop. Yeah, it's great. There's some good residents in the chat about the ARM processor, eighth doctor who was asking, I think he's looking for, you know, would love to have an inexpensive ARM platform to be able to do, I'm guessing, you know, test-dev, home lab type of environment. Anything you've been hearing from the team as to what ways to do that? Well, the unfortunately I don't sell ARM hardware but I can recommend though in order to make this make the whole operation less expensive is this is a good plug for the our developer program so with the Red Hat developer program developer for individuals we call it inside you can go and you can go sign up for the developer program we just expanded that so that you can, yes you can get everything for development purposes but it also gives you permission to go run RHEL in production on up to 16 systems and so this was designed specifically for people who have the same pathology I do and like to run their own email servers in their basement this subscription is designed for you so if you want to run your own home lab if you want to run your own mail server in a basement you can do that with the Red Hat developer subscription and with that it should give you access to you know you can use whatever ARM hardware you like now I should say though that the ARM hardware that we support right now is we're pretty focused on the server ready hardware can I take a digression on the weirdness of the ARM here we go okay so Intel AMD the x86 world super, super predictable right? you have one company that is basically making these things and all these other boards look the same unless the same and so relatively stable ARM super innovative moving quickly lots of different providers and so you have all different systems on ship you have all these different SOCs floating around each of them have to get enabled separately unlike the x86 ecosystem where if we've got one version of a chip we can kind of enable that and everything more or less works but each of these SOCs have to get enabled separately and so creating encouraging more consistency in the ARM ecosystem is something that's pretty important to us so the ARM folks have set up a program for this it's called the system ready program and so there are system server ready and so REL works on that hardware there are other classes of this program and I'm going to forget what the actual acronyms mean but it's basically for different classes of hardware they have different ways of describing the consistency so we're focused on the ARM server class hardware right now and especially as we start making investments in Edge we're going to be working our way down that list of programs again to make sure that we can take advantage of all the interesting stuff that the ARM Edge hardware is doing there's every reason to believe that REL can go enable those use cases as well I'm not sure if you can answer this but there's a question in the chat about CentOS 9 stream and it looks like they're looking for we've got it up on the screen there desktop packages to help them because right now they have to wait for the GA release so I think I'm going to read this sorry we're going to have to get the enterprise next time ecosystem vendor series desktop packages for CS9 before REL 9 oh yeah okay so yeah people can target CentOS stream people can certainly target CentOS stream 9 I think the this is a good opportunity to talk about Apple so enterprise packages for enterprise Linux I think is what it stands for Apple we just call it Apple so this is a kind of sidecar project that allows you to people can build packages that Red Hat won't ship you can build those separately and put them on Apple and if you subscribe your REL system to these Apple repositories you can go get those extra packages so it's a way for people to extend the REL ecosystem without waiting for Red Hat to ship software so if you think about how the development of REL works we started Fedora and then we move into CentOS stream and things cook in CentOS stream when you're looking at CentOS stream today you are looking at the development of REL and so if you are targeting a package if you're targeting an application for something like REL 9 you can follow the development of CentOS stream 9 and know that as we get closer and closer to GA you're getting closer and closer to what REL 9 is eventually going to ship and look like and so anyway just to say if now we have so the question is about how do we get ecosystem vendors to release desktop packages and CS9 before REL 9 this is exactly what we would like people to be doing so if you are building desktop applications for REL 9 and if you're an ISV I don't want to pick one out by name Firefox let's say just as an example if I'm building Firefox and I want to target it for REL 9 you should be able to build your Firefox against CentOS stream 9 and if you are following CentOS stream 9 through the lifetime by the time we get to REL 9 GA you'll be ready and the system was designed to enable so that you don't have to wait for REL 9 alpha or REL 9 beta before you can do your work you can just follow us the whole way through right one of the other topics we haven't touched on yet is security is there anything new in REL 9 when I think about the whole space the surface area of attack is so much larger you talk about the diversity of hardware I'm sure has challenges going to the public cloud going to the edge we all have unique issues we're spending lots of time on the secure supply chain is Red Hat as an overall I've got some people on my team working on that so yeah boil down all the security challenges and tell us what's happening there yeah so the good news is that with REL 9 we figured security we're done so there's nothing new on security in REL 9 I'm not going to let legal watch please go on yeah with every release we obviously take security very seriously it's one of the things customers expect from us so we made several investments and sometimes I can talk about new security features of which we have several but maybe one of the most important things we're doing is actually taking things out in order to make REL 9 more secure so for example you should see us being outdated cryptographic algorithms so there are some hashing algorithms which have been discouraged for years now and part of our job is to make sure that we're not accidentally using any of those discouraged hashing algorithms because we don't want people thinking that they're secure when they're not in fact secure because their cryptography is broken so we've taken some of the we've deprecated some additional cryptographic algorithms you'll see us rebuilding on OpenSSL 3 for example lots of individual security related packages have obviously been updated and re-based in order to for the REL 9 release one of my favorite projects before I was on the product side at REL I was in the public sector for Red Hat I was working with the federal government and state local governments and things like this and one of my favorite projects was a thing called SCAP the Secure Content Automation Protocol so this is a way of describing a security posture in ensuring that your system matches that security posture so in other words if you have a set of rules around the federal desktop computing standards for example you could put those rules in machine readable form and then run a program on your system and the system would self-report like yes I comply with this standard this is useful for both an individual server but also useful to be able to do across many systems at the same time if you've got a whole fleet of systems that need to be HIPAA compliant with PCI DSS or what have you and with REL we actually ship with guidance on things like HIPAA and PCI DSS that's built in so each of your REL systems can now reach your REL 9 systems they can self-report on their compliance with particular standards so I always enjoy stuff like that we've also changed several defaults because one of the most important things with security is making sensible choices from the outside and so with a major release of the operating system it's a chance to change default system behaviors without screwing people up too much and so we've used the opportunity of a major release to change some of the system defaults and some of the settings so that out of the box REL will be more secure and prevent things like that and so forth so this show is in the clouds how about what's happening in the public cloud how many years ago what was there the just enough operating system movement I'm not going to need to think about it heck Red Hat acquired CoreOS whose original business model was it's going to be just like Chrome automatic update I don't need to think about it what's the overall Linux in the cloud where REL fits how customers think about that type of solution yeah I think the especially for customers who already have an infrastructure what was true before clouds existed which is that especially when you're talking about an operating system consistency and we talked about simplicity at the top of the show simplicity and complexity and making sure that your operations are efficient and well audited and all these other things these are all still important and that's true whether you're managing multiple data centers or if you're managing data centers and the cloud and so but when I talk to customers what I find is that they are happiest when they have made a single operating system choice that they can then exercise on on all the different clouds and all the different infrastructures that they need to run and by the way nowadays it's not even just a data center and a public cloud it's also data center public cloud and deployments out to the edge and if you can have the same operating system that is able to host applications on all of those infrastructures then you've got a chance to you only have to train your operators once you only have to train your developers once everyone's kind of swimming in the same pool so that's that's kind of take away number one now that said public clouds are unique in the sense that they are elastic and you can spin things up and shut things down very quickly and so when we build for the public clouds we have to optimize for different things first of all the hardware is weirder like we talked about the hardware is unique and so we need to make sure we're optimizing for the novel hardware that's up there but we also need to optimize for things like boot time right in a data center you're not so much worried about boot time on the public cloud you are extremely worried about boot time because that affects the responsiveness and the response time of your applications I think you mentioned the just in fos there's a drive to also make things significantly smaller and I think there is and so minimization is certainly a theme that we're working on for for rel in general and specifically on rel 9 making it easier to make rel composable that is not just to the easiest thing should not be to go install all 10,000 packages of rel the easiest thing should be to use tools like image builder which is an online service that we've got and also an on premise application using tools like image builders let people compose an operating system that they need for that specific workload on that specific provider so I should be able to say I'm going to do xyz on my system I need doesn't such packages and it goes here on Amazon or goes here on azure and so integrating the deployment of an operating system or kind of a gold image into the cloud and just making that kind of a natural a natural thing that's that's pretty important to us now in a way that it wasn't before yeah I think so it's the cloud is on the surface it feels extremely different but it turns out that a lot of the optimizations and a lot of the things that we're doing to make the cloud easier easier to use perform better these are all these all have dividends for the on premise work as well it turns out that it's actually not so different after all yeah and Gunnar you teed up not only is it my data center maybe some hosted environments the public cloud but if the edge is part of my environment what's going to be running on the edge I'm sure thinking it's going to be Linux for like pretty much everything right yeah yeah yeah and so edge these edge deployments are really interesting use cases because they exercise all these themes that I've been talking about the hardware pretty unique hardware like it's a totally different kind of hardware situation the way that you build applications is often different because the way that you're managing the applications is different because you know if something goes wrong with your edge application you can't send somebody on a truck to go visit 10,000 installations to go fix it right that's good Gunnar my last episode we talked about running Kubernetes on the ISS so yeah having the sys admin while they'd love to be able to hop on the rocket and go on there and help out you know yeah and so but some of the things are the same right all that simplicity that consistency across the platforms that becomes really important the way that you manage the application becomes very different because like in the ISS if you're going to go to a system update it better work and if it doesn't work you better have a way of coming back and recovering that's true whether you're in a space station or you're on a telephone pole and so some of the investments that we're making on on the edges yes expanding the kind of hardware that we're going to support with RHEL but also giving people the tools they need in order to manage both their Linux hosts and the applications that are right on top and do so in a kind of a way that is natural for the edge deployments and so using technology that we got from CoreOS right which you mentioned earlier using methods like RPMOS tree so RPMOS tree allows you to create kind of one atomic image of your operating system deploy it into a place and then when you have an update to do it knows to go update the whole thing at once or roll it back and then you need to be able to do all of those updates in kind of low bandwidth kind of or highly latent networks so we have to make concessions for that again just like I talked about for public cloud all this stuff that I'm talking about doing for the edge I have every expectation that people are going to be able to take advantage of all this back in their own data centers and in the public cloud right because people care about bandwidth, people care about latency people care about atomic updates people care about being able to roll back so all the stuff that we do on the edge has dividends for the other platforms as well and so this just reinforces for me the importance of RHEL's kind of central role in creating a consistent technology and kind of operational experience across all of these topologies, right? There's a note that came in the chat that I'm sure you can speak to because it's not only in the public cloud but even in the data center often times the default is well there's a free option out there I know if I go build an AMI in Amazon that Amazon Linux looks good, Ubuntu is there I need to scroll down a little bit and say oh wait I need to pay for this RHEL so maybe it is more of an and story there's certain environments that yeah I can use free stuff and there's there so maybe you can speak to how customers see that and how they you know when are they like yeah no I know Red Hat I trust Red Hat we talked about the enterprise life cycle before so they're all things that pay into the free versus paid Free operating systems are great we have several of them inside Red Hat and there is no I don't see it as a tension between the free and the paid it is there are different use cases people need different stuff if you need to take an application deploy it on an extremely predictable environment and have it behave basically the same for like 13-15 years then you probably need a pay operating system if you have an operating system where you have an application you're constantly changing and constantly churning and you know you're not going to need help with anything and you don't particularly care about security and you don't particularly care about your ecosystem or hardware software partners cool you can go use a free operating system that's fine the free operating systems play an important role in the ecosystem and they're part of the success of Linux overall just like the paid operating the paid Linux is also available in the ecosystem and I would argue that one cannot exist without the other like all of us are we're competing in the market but in terms of the Linux project overall of making all of this technology as available as possible all of us are playing an important role in that awesome well said gunner alright so I got one fun question for you before we wrap Star Wars going on you a fan do you have a favorite movie favorite character anything like that I was funny I recently started watching I recently went back to rewatch them in anticipation of showing them to my son and who is now 8 years old and so he's probably more than ready to watch it what order do you show them in that that's a really important parenting for me for me he was going to experience in the same order I did so it's going to be new hope we started for I watched the first 10 minutes and I don't remember being that violent I was like Darth Vader throwing people all over the place I was like I don't remember this I saw this when I was 3 how could it be so it'll be a minute before he watches Star Wars I'm afraid yeah I do over a day and I did it the same way I watched it I had my kids we watched the original trilogy then the prequels and you know they were old enough to see the sequels and they came out awesome so hey tomorrow congratulations 20th anniversary of rel that's super exciting and we at Red Hat next week have summits so you and I will both be in Boston any quick shout out you want people to of course check out the rel session check out everything we're doing yeah so first of all the on stage the demos are always a fireworks event those are always I'm always I'm always delighted by those I'm doing a session on the future of the operating system and I'll go deeper on some of the things that we talked about today but really make yourself available for all the content I mean there's something like 30 sessions on rel and all this different flavors and aspects so please enjoy an avalanche of rel information next week yeah and for those that aren't coming to Boston which it is a pretty small event if you just go to redhat.com slash summit you can still sign up for the virtual lots of you know access to all the content it's free to register and you know please reach out to us if you any questions so all right I was just looking to see if there are any questions right Shantanu I understand you know maybe the sequels we shall not refer to them as there I was just seeing if there was any other specific questions yeah you know there's one here a question I'd have is how do you define the value of redhat subscriptions let me put it up on screen there for you you know is it relationship is it maintenance is it something else I guess a good final question to kind of you know why rel in 2022 yeah so this okay so let me see if this is my this is this should be rifle training for me and everybody that works for me so let's see how well I do okay so the ultimately the value of the value of rel is specifically a lot of people think about it as okay it's a it's a hardened set of bits and it's a phone number that you can call and that's true that is certainly that's kind of that may be the core of the subscription value one part of the subscription value though is is the extensive relationship we have with other partners other organizations in order to number one to make sure that security vulnerabilities are fixed promptly that requires if you are relying simply on the upstream communities to fix your security problems what you're doing is forcing yourself to upgrade to the latest version in order to follow a thing and that may come with new bugs and new features that you were not planning on and so what one of the things that you get with a rail subscription is the ability to separate these two things so you can have security fixes without being forced to to upgrade right so that's that's pretty important if you're interested in stability and not being surprised part of those relationships also is the relationships we have with the hardware and the software vendors to ensure that new hardware that's coming out can be supported alongside all the hardware that you've already got to ensure that your application it remains stable for a very long time that requires real work that doesn't happen by accident and it requires people to be on the phone with each other and to be in meetings with each other and trading roadmaps and working on bugs together so that's part of that that's part of the value as well increasingly you're going to see us adding services literally services online services that are part of the subscription so if you don't know about insights for example you should go take a look at insights coming up coming up soon you're going to see us adding things like malware detection you're going to see us adding things like cost management tools to help you kind of right size your your public cloud spending all these tools exist in console.redhat.com so when you have a subscription you have a red hat robot that's going to be there to tell you like hey you might have this thing misconfigured or hey you think you might have these vulnerabilities that you haven't looked at having those kinds of coaching or advisory opportunities I think is I mean that's that increasingly that's kind of a core part of the subscription experience I'll for time I'll stop there but this I could I have an entire hour talk on the value of subscription so I could go on forever but yeah I know now you got a really really good point absolutely looking forward to seeing you and many others in Boston thank you so much for joining congrats again on the 20 years and thanks so much to the audience for watching us we'll be back every two weeks here if you have topics guests that you think we should be watching feel free to reach out I'm just at stew on twitter I'm stew at redhat.com for the email gunner thanks so much for joining us and be sure to tune in next week for redhat summit you know live and virtually from Boston so until next time thank you for joining us on your journey in the clouds