 Hello! Time-appropriate greetings. Thank you all for joining us today. My name is Eric, the IT guy, Hendricks, and this is REL Presents Episode Number 24. Today, we've got an awesome show for you. I am going to be bringing on a few of my co-workers here, and we are going to mute my confidence monitor. But we've got an awesome show for you today because just this morning, Red Hat announced the release of Red Hat Enterprise Linux 8.5 for beta, I'm sorry, the REL 9.0 beta was just announced and released. So with that in mind, I want to go ahead and bring on my co-workers. First off, you all know him and we were all excited to drag him back on for this episode. Let's say hello to Scott McBrien. Hello, everyone. Good to see you again. Welcome back. It's been a couple of months. Yeah, been busy. How was life on the level up hour? Well, we've got these cool jackets. We don't have that in REL Presents. Maybe I should just get a patch and just put it right here. It'll be one of a kind. There you go. It's been good. We talked about insights this morning and we spent a lot of time talking about REL with insights, but also some of the cool stuff you can do with OpenShift with insights and some of the beta features they're lending for that. That's awesome. Yeah, so if you haven't been following Scott, go join him on the level up hour, a part of Red Hat Live Streaming. Also would like to mention that I believe Scott, myself, a few others are all hanging out on the Red Hat Live Streaming Discord server. So if you want to be a part of the conversation when the show is live and even when it's not, come and hang out with us there. The link will be in the show notes below. But before we get started, I want to introduce one other person to you, and that would be Matthew Yee. He is a technical marketing manager with us here at Red Hat. He's a co-worker of Scott and mine. He is the guru of all things, satellites, system roles, Ansible, all kinds of stuff. So Matt, you want to say hello? Hi, everybody. Hey, right to the point. I love it. All right. So we do have one other technical marketing manager, but he had a thing with Microsoft. So he'll be joining us here in a few minutes. We'll get him introduced once he jumps over from that. Don's a really popular guy today. So I guess Microsoft, we can let him use that excuse. All right. So let's dive right in. Rel 8.5, general availability is coming up here in just a couple of, and actually I'm not sure of the time, but it should be here very soon. We've got a lot of the beta bits in place, and rel 9.0 just went beta availability this morning, so you can go and download those bits. So we've got a lot to talk about. There's rel 8.5. There's rel 9.0 beta. So here's a lot going on. So I didn't want to have to, I didn't want to cover everything. So I brought on Scott and Matt and Don to help me kind of talk through things. And Edward, I'll get, I'll find out what's going on with the Discord link here in just a second. While I'm looking at that, Scott, I want to single you out. And why would we want to upgrade? Why not keep what's working? In rel 8.4, is that what you're talking about, or compared to something like 6 or 7? Yes. Excellent. No pressure. I mean, the biggest thing right now, yes, all the things. The biggest thing right now is, you know, with Red Hat Enterprise Linux 8, we announced that we were going to be keeping a predictable release cadence. So every six months, we come up with a new minor release of Red Hat Enterprise Linux 8 since it was released in May 2019. Now with each minor release, we get some new features, some improvements, and it's going to continue like that for the next couple of years while we finish out the full support life cycle of rel 8. And we're going to talk today about some of those new features and enhancements that are coming in 8.5, which to the 8th doctor's comment soon, it's the answer that all the people love about when something will be done soon. I think more importantly, especially in light of the 9.0 beta release that we had this morning, with this predictable release cadence, we also said new majors over three years. So if May 2019 was rel 8, then mid 2022 is rel 9. You could see that we're on track for meeting that. And as an administrator or architect or team manager or app developer, this gives you a lot of information that previously you didn't really have with Red Hat. There used to be that we would release a new version of rel when we had enough features to make it technically compelling we thought to be released. And that meant that maybe some things that might have been technically compelling to some customers like new Node.js being available was not necessarily technically compelling for everyone, and so it didn't cause a new release. And we fixed some of that kind of stuff with application streams. But with three year majors, we're going to pick up a lot more of that. And so today, if you were planning on doing a new project, you could have a serious discussion with your stakeholders of whether you should target rel 8 for being the basis of that project, knowing that it has about two and a half years of full lifecycle left fall by another five years of maintenance, or if you should start work on your project on rel 9 beta, expecting that it's going to GA in mid 2022, and then have 10 years, five years of full support, five years of maintenance support after that. And that's a really drastic change from what we used to have. So I don't think we're really realizing that until now with rel 9 coming out. That didn't really answer the question that Eric. No, I think I think you hit on a couple of really important points. I mean, we all know that Linus Torvalds likes to change kernel major versions or minor versions at kind of random intervals, you know, he was he was quoted as running out of fingers and toes to count on. So it was time for a new major version of the kernel. And while that's, well, that's kind of something that the community and kernel developers look forward to it's some whimsy and in an otherwise very regulated space. That's not what I'd want to do as a systems administrator. I've been in that role. I know what it's like to try and think, okay, we've got hardware refresh coming up. We've got operating systems that need updates. So what do I really, how do I plan? Is it this year? Is it next year? Is it going to be a seven year lifecycle? Is it going to be a 15 year lifecycle? Which I think rel six was, was quite a long time. Now all those questions have, have been taken away. I don't have to worry about, I don't have to worry about when do I need to plan on the next major release? When do I run out of support on this thing that two people use that I can't seem to get rid of? Now I've got a, I've got a definitive date or at least, at least down to a quarter, if not a month where I can say that, look, this thing, we're going to lose support. It's going away. It's not going to get any, any security bugs, any fixes, nothing past this date. So even if the two of you still use this, this one random database, it's, we've got to move. We've got to update. We've got to move to something else, somewhere else heck nowadays, let's just put that database in a container and, and address the underlying operating system at least. Well, and it also like, not only can you have those discussions, but like, and know that those dates are coming. You also know that you should start planning for it. And if you're going to be replacing an application, you can also start budgeting for it or asking for budget to be allocated to it. If it's really mission critical for your organization, I saw a couple of questions from the eighth doctor there. So why aren't application streams released or updated out of band for rel eight dot, whatever minor releases. So I mean, we're releasing minor releases every six months. So how often is new stable, no jazz being released? How often is new Python being released? So I think that we're probably hitting about the right stride on, on that. Let's say that just the world lines up just right and new no jazz stable comes out a day after rel eight dot five comes out. Well, you know what eight dot six is only six months away and you'll see it there. So, you know, is it down to the day or the hour or the second of release? No, but, you know, we also do a lot of testing and right and other things. So we're still pretty bound to the release schedule and cadence. And that's how we organize all of our engineering work. But I think that ultimately, like for most customers, it's, it's probably the right amount. And then for 15 years, like I could tell you some stories that will cover your hair if you don't already have curly hair. So. Well, and, and the the UBI process does have built into it. The ability to release, say there's a critical vulnerability found within a particular container. There is the ability to release out of band. But I'm with Scott is depending on the release cadence of some of these different development tools or languages or language frameworks, six months seems to kind of hit everybody. And the worst case is if there's a feature in the next version of of a. If there's if there's a feature in the next version, you there are ways to play with that version without without the official supported package. But the good news is that, you know, that at most a new feature is only going to be six months away. And speaking of development frameworks and languages, as if on cue, we thought of his name enough times that I'd like to bring on the fourth member of our team. And that would be Mr. Don Pinto. Don, welcome aboard. Thank you, Eric. This is great. And it's great to be live on this live streaming show for the first time, I guess. Yeah, welcome. You and you and man are first timers. And I mean, we kick Scott off because, you know, Scott, so. But why don't you tell us a bit about yourself and what you do? And then I think this would be a perfect time to weigh in on containers and development frameworks, that kind of thing. Sure. Yeah. So since you talked about development, I'd like to use that to kind of introduce a little bit of what I do. So I'm on the rail technical marketing team here. So really happy to be here on this live streaming again. And one of the different aspects, if you will, of rel that I, you know, look at or focus on from the developer angle would be definitely things like, you know, app streams. I'll talk a little bit on, you know, maybe some of the cool stuff, which is coming in eight dot five, maybe not everything, but I'll touch upon a few things. And the other aspect is workload. So Eric, you also mentioned, you know, databases. And so that caught my attention. And definitely if there's time, we'll definitely show a demo to the audience here of how we can use rel to run, you know, SQL server. But starting with data development, just really wanted to touch up on two things very quickly. One of them is around open JDK support. So we, for rel, we have a huge ecosystem. And if you look at like developers, they love Java and they love.net. These are among the other languages, right? So these are really popular languages. And so I want to talk about a little bit on the open JDK 17, which has been announced as a part of rel eight or five, right? So some of the cool things, you know, I don't count me here for being a guru of everything of Java, but some of the highlights, if you will, are things like a new random number generator, some of the stuff, you know, some of the work which has been gone down around like floating point consistencies, just so that you can build apps which are numerically, you know, sensitive. So suppose you're building like an app which requires precision of numerics, right? So then you would, you know, there were some benefits you can definitely get from this Java, new Java version. You also touched a little bit on my UBI Eric. So I want to talk a little bit on yet all of this stuff that you, if you're not, you know, you don't want to download the open JDK, you're still using an old version of Java development kit. You can try open JDK 17 in a rel UBI container. So that is another option for you to go and experience if you just don't want to install it natively. Moving along, maybe .NET, just wanted to talk for the .NET fans on the stream here. So there's .NET Core 6, which is part of, again, rel 8.5. And some of the cool things you could get out of .NET 6 are support for WebSockets. So I know a lot of like people who are building chat kind of applications who, you know, where WebSockets are an important part of that application stack would maybe benefit from something like, or the improvements that are put into .NET 6.4. And plenty others. I mean, I only touched on two languages. I mean, Scott touched upon like all the, you know, whether it's Python, whether it's Node, you name it, right? Go. I think that's, there's a lot of things in AppStreams that people should try out. So Matt, the only thing I took away from what Don was saying was that Don is the Java expert to talk to. Is that what you heard? Absolutely. I would ask him anything programming related. So actually, Don, I did want to highlight one thing about Developer. If there were maybe a resource that would dive into any of these languages, the Red Hat sponsors that you'd like to promote? Yeah, absolutely. So there is the website. I can just put it in the chat. And for those who are developers on the call, check out developers.redhat.com. So if you check out developers.redhat.com, you can click on, you know, we have a huge product set there, you know, in terms of the portfolio, click on Linux, because, you know, we since we're talking about ReLU, I highly recommend you to check some of the cool stuff we have, you know, we have documented on that page, whether it's tutorials, whether it's cheat sheets, whether it's listening to videos, and these assets can go deep in a particular topic. So if you're a Java developer, you could find, you know, way more than I can, you know, at least, you know, kind of say this on the call, right? Everything, you know, I feel for me, it's a daily resource, you know, I feel for developers to go and check out some of the most innovative stuff Red Hat has been doing in terms of development on that site. So again, developers.redhat.com, and, you know, use that site to also get access to the beta bits, we also launched ReL9 beta. So for folks who want to stay on the cutting edge and want to try it out and give ReL9 beta a spin, that is the page. Perfect. So I did see a question in the chat about ReL9 beta and about the beta program. We'll touch on that here in just a second. But before we do, I have to give props to Matt. He jumped on to the stream long before I did, and he's been waiting very patiently. So Matt, why don't you tell us a bit about what you've been working on with the new release and what folks should be looking for with Nino and with A5GA coming up here soon? So I primarily look after system roles and satellite. And with system roles, at least, is everybody... I'm going to assume that not a lot of people are familiar with Red Hat Enterprise Linux system roles, but I'll give a brief exposition. I think a lot of us out there already know a lot about Ansible and specifically Ansible roles. System roles are kind of an extension of that. They are pre-canned rules created and supported by Red Hat that allow you to configure your Red Hat Enterprise Linux hosts to conform to specific configurations or preparation for the installation of specific applications like SAP. And they are... I guess the main message I would like everyone to take away here is that they are supported by Red Hat. With specific to satellite, we released the beta for satellite 6.10 a little while ago, and the satellite 6.10 should go GA by next week. So we're very excited for that. The two main important things that we'd like people to know about satellite 6.10 is we've revamped the content management system in satellite, which means that a lot of the underlying plumbing has been modernized. We've collapsed the database from MongoDB and PostgreSQL into a single PostgreSQL database, and we've added better support for the disconnected satellite use case, which means that you can now more easily synchronize content to disconnected sites, which have satellite installed. So if you're not familiar with satellite, and if anything that Matt just said just went right over your head, then I want to go ahead and tease it, Matt. Episode 25 in two weeks is going to be about satellite. We're going to do an introduction to satellite. I think we've got some demo content ready to go. So it'll be about how to register systems, how satellite can help you produce some of that content or manage some of your content, not from a video perspective, but from a packaging perspective, life cycle management. So if satellite is something new to you, if it's something that you're interested in, if you're familiar with, say, Forman or Spacewalk and are curious to see how Red Hat utilizes those particular upstream projects, definitely tune in in two weeks. Episode 25, Matt will be joining me again live on air on YouTube and Twitch. So feel free to join us here in a couple weeks and we'll talk a little bit more about satellite. And just one more thing. I realize it's very confusing when we say content, so I'll just clarify. It's based, you can look at satellite as being a way to make your packages, your RPM packages and subscriptions more importantly available locally on premises, assuming that you don't like having all of your hosts talking directly to the internet. Yeah, that's good clarification. So shifting gears a little bit. We mentioned the beta program. And in the chat, and I'll repost it here in a second, there is a link to the new beta experience. So I've been asked a few times, yeah, it's great. You've got the new bits available as part of the beta process, but how do I get a hold of those? Do I need a subscription? So with the 9.0 beta release and with the 8.5 beta, you can now, you don't need to have a subscription, you don't need to pay for any licensing, you can just go on to access.redhat.com, make sure you have an account created, and you can download the beta bits and you can try them out. Beta may not be the best branding, because I think it kind of gives us all an idea. Think of these as more of release candidates, because we're making changes to the beta program. We changed the life cycle in RHEL 8, and so now with RHEL 9, we're paying more attention to the beta. How do I get things in the hands of users a little bit earlier? And so one of the things that we're sort of piloting right now is more of a release candidate view to where you can just install it, try out the new bits and see if it works, but there's no road back into the GA release. So if you install the 8.5 beta, you're going to have to do a reinstall for 8.5 GA. So we're hoping to make changes as we move forward to make that easier. So if you weren't aware, Fedora is actually the upstream to Red Hat Enterprise Linux. So the upgrade process in Fedora, which shout out to the Fedora team, version 35 just came out yesterday. I actually have plans probably tomorrow to reinstall Fedora on my laptop. I'm really excited about Fedora 35, but if you're curious where RHEL is going, Fedora, the upstream Fedora and the CentOS Stream, great places to get information and see what's coming in RHEL. So the upgrade and beta processes for RHEL are going to start to look more and more and more like that of Fedora. So for a number of releases, I've been able to upgrade my workstation here from Fedora, I think 29 up to 34. And I've not had any problems. And so now RHEL is going to be easier than ever to do that. So RHEL 7 to RHEL 8, there's the leap tool for in-place upgrades. RHEL 8 to 9, we expect that process to be even more seamless, even easier. So check out the what's new in the beta program link in the show notes and in the chat. Guys, did I leave anything out as far as the beta program? Sounds good. Are we getting into 8.5 now? All right. So we've talked for like 25 minutes, and I know the guys are just itching to get hands on keyboard. And I know that's why you all tune in not to hear me speak, but to see if we can actually break things live on air, which I've proven to have a really great success rate at breaking things. Not sure if that's the goal, but that's usually what happens. So let me check. Who wants to go first? Either that or I'll make you draw straws live on air. I can go first. I got my terminal loaded and everything. Perfect. Let's do it. So I'm here to demo system rules. And can I share my screen? Yes, please do. I feel like I didn't give a very good intro to system rules just now, but you're probably asking yourself, why do I care and why would I want to install system rules? System rules, as I mentioned before, they're for configuring your host automatically. You can, it's based on Ansible. It's, that means it's, you can run the system rules playbook multiple times and get the same result. It's useful because as I think many of us already know on the stream here, if you're managing tens, hundreds, thousands of hosts, configuring all of them with the, as the number of hosts increases becomes an impossible task. So we use, we are preferred choices to have people use system rules to configure their hosts. And these hosts are, sorry, these, these system rules that we ship with rel, they're, for those of you who are, who are familiar with Ansible, you're probably asking yourself, what, why is this special? Like, why do I care about these system rules? The first part of that answer is, first of all, they come with your rel subscription. Second of all, these are not simple playbooks. These are actually pretty complex. We can configure things like network bound disk encryption, we can configure cockpit with Grafana exports. These sorts of things are hundreds of lines of code in order to give you this capability. So, I mean, with that, I'll just dive right in here. Like, so assuming that you are working with a fresh rel installation, and you've done nothing else to it, you've added the subscription, the first thing you want to do is enable the Ansible repo. And once that's done, you're going to want to install Ansible. Oops, you're going to want to install system rules with Ansible. What's our, what's our recommendation on running Fedora 21 in this day and age? Are we going to do that? So Fedora releases, Fedora releases have about a nine month life cycle, I think. So it, it, it passed on long time ago. Just don't do your online banking on that box. It's doctor. I think what AIDS doctor was talking about was doing in place upgrades on the same system since, since 21, from 21 up to 35. So yes, you're there for a minute. If you are running Fedora 21, I highly encourage you to just do a clean install. But if you're on 33 or 34, yeah, go ahead do in place upgrades. Okay, for a matter of heart attack. In case anyone's wondering where, what this is, this is a platform we're using called Instruct. You can get to it by typing in play.instruqt.com at forward slash R-H-E-L. Yeah, thank you. Okay, so that's what I'm here for. Ansible and system rules are installed. We're going to move to the next challenge. So Instruct, if you're, if you're not totally familiar is a competitor to Catacota. And we actually, the four of us have been spending a lot of time building out new labs, and we're going to be releasing them soon to, to keep with the theme. But so keep an eye on lab.redhat.com for more, more labs and contents, just like what Matt's showing today. What I've got here is a small playbook called soe.yml that stands for standard operating environment. What I have in there is a hypothetical playbook containing two system rules. So if you feel like you have to play around with your kernel settings and you want to change the swappiness of a VM, you can do it with system rules. And let's skip down here. So what's, what's our swappiness setup right now? So for anyone who doesn't know what this kernel parameter does, 30, as you see on the screen here, means 30%. It means that start doing a bunch of swapping after your memory reaches 30% capacity. That means take like your inactive processes and swap them out to disk. I mean, systems have so much RAM these days, I don't know why anyone cares. So I am going to apply this system role with this setting value 20 for 20% instead of 30. So we're going to change that. Oh, it's not percent. Okay. So Scott, if I recall correctly, 100 means it's the most aggressive at swapping. That's correct. And so like, basically you're setting the aggressiveness, right? How much should your kernel try to swap? There's also things that the kernel is not able to swap like private memory pages, for example. So it's only applied to those things that are eligible for swapping. And then it's just like an affinity. So even at a swappiness of zero, your kernel can still potentially swap. It's just going to try really, really hard not to. So I'm going to pause here and give some commentary. I think intuitively, I think this really shows how useful system roles can be for a particular system because in that SOE playbook that I have right here, you can see that you can stack multiple system roles on top of each other. So that you can make as many configuration changes as you want. And then you can apply these at scale to multiple hosts. So I think that's all I wanted to show. If you want to see more about this demo on how to use system roles, please go on struct and give it a try. Definitely. Thank you for giving the kind of doing an overview of system roles because it really ties in a lot to what we're trying to accomplish with newer versions of RHEL both in the 8.x and the 9.x line. So we've kind of talked all around it and we've talked over it, I think. But why don't we talk a little bit about the specifics of 8.5? What maybe we'll go around the horn here and see what features should we be excited about? What should we be playing with? What should we be looking forward to? Scott, you want to go first? Sure. So we're making some changes to kernel live patching or Kpatch. One of the things is we're going to be adding Kpatch support into web console. So just so you know what that looks like, if I can find a copy of the image grab I did, maybe. This is what it looks like. On 8.5 beta, you actually won't see this. It shows up in the software updates parameter in web console, but if you have a kernel patch available, it'll show it as an update. Also, if you have any kernel patches applied to your running kernel, notice under the status, it tells you that there is one already applied and active. So that's one thing is we're making kernel live patching easier to use because we're adding it into the software updates component of web console. The other really big kind of exciting change is we're going to be producing kernel live patches for all minor releases of Red Hat Enterprise Linux 8. So previous to 8.5 we only produced Kpatches for what we call extended update support or EUS releases, which was 8.1, 8.2, 8.4. But those odd numbered releases, we didn't produce Kpatches for their kernels and that's going to change with 8.5. So with 8.5 you will get Kpatches for the duration of 8.5 and then when we transition to 8.6 you'll get it for 8.6 plus 8.6 extended update support. You'll also get it for 8.7, 8.8, and so on and so forth. So we backport critical security Arata into live kernel patches, which will allow you to apply updates to the kernel without the need for a reboot. And we have a six-month look back on all of those. So as you get new ones, they are a roll-up of all of the ones up to that point for the last six months. So that's a pretty exciting change for kernel live patching. The other thing that we've done in WebCultural is we in 8.4 we created a metrics page and I think I have that on my other box one second. So if you went to the, oops, live demo, what could possibly go wrong? So when you went to the homepage there was this usage details in history that allows you to look at performance co-pilot data in a more graphical fashion. So on this system I've already enabled it. So down here a little bit further on the page you have these nice little histogram graphics of what's been going on in this box. But with 8.5 and also into 9, you can also configure PMProxy through the Web Console. So if I go to metrics settings here, you can export to network which allows you to send your performance co-pilot data to another system on the network. And the reason you would want to do that is to collect all of your population information on a single host who then uses something like Grafana or another data visualization service to then show you important things that are going on across your population. So that's a little bit on what we're doing with performance co-pilot. Sorry to interrupt, Scott. Just one quick thing. If you need to configure this like performance co-pilot across multiple hosts, you can do it with a system rule. Also true, it's called the metrics system rule. And Brian Smith has a good blog entry on our site talking about how to set this up. In fact, a whole series of blog posts. And I'll see if I can grab the URL for that here in just a second. But Don, I think you had, I think you wanted to jump in on the performance enhancements for 8.5 as well. Yeah, I think Scott and Matthew covered quite a bit of it. Want to focus on one aspect of PCP, which is the scale aspect. So although the setup is easy, as Matthew said, with using the system rules, Scott showed how you can use the web UI or web console for a lot of the observation of all this metrics data. But when it comes to scaling PCP, PCP is a solution that people typically deploy on a cluster. And that cluster can be quite large. So we have done some internal testing to basically be able to deploy PCP on up to 1,000 nodes. So that is kind of the scale factor in terms of testing for PCP. Just gives you an aspect of, again, these tests are internal, but that is going to be kind of codified in our best practice in terms of when customers are running, like yourself, are running PCP in production. And a lot of times we get the question is like, how large can this cluster be or how large can the system be? 1,000 nodes is going to be the best practice because that is sort of measured and tested in the lab. And we hope to get feedback on that as well. And kind of sticking along with the web interface that's built off of cockpit upstream. One of the other big improvements we've seen with 8.5 is Image Builder. So if you're unfamiliar with Image Builder, it is the ability to create a golden image. You can predefine users, SSH keys, have packages installed ahead of time and create be it QCao2 files or AWS images. Image Builder actually gives you the ability to set a lot of different parts of your operating system ahead of time. And it's a very heavy area of focus. And so we've made two major enhancements to 8.5 for Image Builder. The first is bare metal support. So beforehand, it was really cloud-focused, very virtual machine-focused. There's VMware support, there's QCao2 files, which supports libvert and OpenStack images. But now, as of 8.5, you'll be able to do a bare metal install. And it takes the Image Builder process and instead spits out an ISO with a prewritten Kickstart file. Love having to pull these names out of my head as I'm talking live on here. It's great fun. But the second enhancement that I'm really excited about, it's been very heavily requested and our engineering team's been working really hard on, is customized file system layouts. So now, if you had a 20-gig Image Builder image, it would only have the slash or the root file system. Very important differentiation there. But now you can actually specify that layout. My 8.5 system wouldn't actually complete the demo for today's event. But here very soon, you'll be able to try that out for yourself on RHEL 8.5 GA. But bare metal and custom file system layouts, huge enhancements to Image Builder. And there's more coming out with every version. Image Builder is going to be very heavy focus for RHEL and RHEL distribution going forward. And then I might hit on one other thing and then turn it over to Scott to talk about containers. But I also wanted to mention that we featured this on the show just a few episodes ago. But the convert to RHEL utility. One of the limitations we had beforehand was it only supported the older grub boots options. But now with 8.5, so here just very soon, you'll actually be able to do convert to RHEL on CentOS and OEL systems, Oracle Enterprise Linux systems that have UEFI. So if you have a newer piece of hardware or a lot of cloud providers or virtual machines, all lean on UEFI for boot. So convert to RHEL will now support those systems as of 8.5. So Scott, we kind of talked a little bit around UBI. Is there anything specific in 8.5 we want to talk about with containers or Podman? I mean, I've been there and clearly got the t-shirt. Literally. So with UBI, like nothing major, we're still going to continue to ship our four versions of UBI. Micro, which is really small. Minimal, which is pretty small, but not as small as Micro. Standard and init or multi-service image that comes with full-on system de-implementation. So we'll be packaging those and shipping them with 8.5 as well. You can download them and redistribute them for free from the Red Hat Container Catalog or Docker Hub, if you would like. The changes in 8.5 are more around the container tools. So we made overlay file systems usable by rootless containers. So if you're not familiar with rootless containers, it lets regular people, non-privileged users, run containers. Depending on how you have the system set up, you can bind to different ports on the machine. So you can forward traffic to a higher numbered port, or you can actually tweak the system a little bit and also let them access traditionally privileged ports with some administrator changes to the box. But overlay file systems is one of those that has been difficult with rootless because of the non-privileged nature of rootless people. So with 8.5, we're improving that so that you can natively use overlay file systems and get some speed improvements with them for rootlessly running containers. We previously, I think 8.3, we released containerized Podman. So if you're using a different container runtime on another operating system, let's say, you could now run a container that includes Podman to allow you to build Podman-based images and access the REL container tools. And we're going to fully support that with REL 8.5 containerized Podman. And then, let's see, I don't think there's anything else crazy there. Oh, C Group 2 is now fully supported. So if you are using C Group 2, that's cool with containers now. We had been working with it, but now it's fully integrated and that's excellent. And then one feature that is landing in 8.5, but we should see additional additional work on in future releases as well is container verification. So now when you download a container for a registry, it'll actually compare the signature on that container once downloaded into your local registry with the signature on that container in your repository that you downloaded it from. So you can see that the container is valid all the way through from where you got it to your local file system. And so right now, it'll warn you if that signature is a mismatch. And in the future, we're looking at making that more enforceable, but it's not there in 8.5 yet. That'll really help, especially with all the focus on open source supply chains. Well, not just open source, but any supply chain. So moving forward, it'll become easier and easier to make sure that the image that you're getting is actually from Red Hat and signed by Red Hat instead of just maybe Red HT or something. Some weird misspelling of Red Hat that looks kind of like it, but is in fact someone just trying to mine cryptocurrency using your server infrastructure. So let's see, what else do we have coming out in 8.5? So, Don, you mentioned a couple of security features. Do you want to expand on some of the security changes in 8.5? Yeah, so I mean, just compliance is definitely one with every point release. We kind of make sure that we are keeping that with compliance, whether it's regulations. So that is one thing I love to call out with, again, because it's a significant mature point release later in the cycle, 0.5, right? So we are up to date in terms of like, want to be up to date in terms of all the compliance regulations. But also in terms of, when I look in terms of security, especially when I look at things like insights, the rule database of insights, which is the service, which is having a lot of those intelligences, whether it's, you know, vulnerability intelligence, or whether it is also just improving operationally the system, the rules associated with that, they get improved with every release. It's not really tied to the operating system release, but essentially, there are certain rules that basically check the operating system version as well. So the rule database could get updated out of band, but that is also consistently moving forward. So just wanted to call that out. So what that really means for a customer is, you know, you may not know that your system is vulnerable, but now that with insights, you can really go there in the dashboard, not just see one system, but see your entire fleet of servers and be able to remediate issues right from the insights dashboard. And I'm sure Matt, you can talk more about like, you know, combining that with things like satellite and so forth. So it's funny you mentioned insights, because on episode 23, I had John Spinks on. So the episode right before this one, and we talked about insights and vulnerabilities. So then insights and rel continue to work closer and closer together. So lots of great, lots of great advancements coming with 8.5. And we'd be remiss if we didn't mention the 9.0 beta. In a feature by feature comparison, 8.5 and 9.0 beta are very, very similar to each other. But I need to stop reading the chat when I'm in the middle of a sentence. But feature to feature 8.5 and 9.0 beta are going to be very similar. I think the big takeaway is to see how this upgrade process, how this migration path is going to look moving forward. So while the actual bits may be similar, 9.0 is kind of the first major release since we've made all these life cycle changes. CentOS stream is now upstream of Red Hat Enterprise Linux. We're more tightly integrated with Fedora with CentOS than with REL. We're on a standardized release cadence. So the major version, REL9 is kind of a celebration of that. And we'll talk more about REL9 in the spring. So feature by feature, it's very, very similar. But the beta is out. It is freely available. So you can definitely see how things are going to go. Once REL8 hits its maintenance phase, I think we'll start to see that feature set diverge quite a bit, because REL8 won't get any of the hardware enablement or any of the new features moving forwards. And then that development will shift completely to REL9. So if you're on REL6, REL7, and you haven't started talking about upgrading to REL8, maybe it's worth taking a look at REL9. That gives you another six to seven months to prepare. And if you're on REL8, it's going to be an easy shift from REL8 to REL9. So as we kind of wrap up our time, I wanted to highlight the chat, please, if you have any questions. Now is the time. Go ahead. I was going to highlight a couple of things that I've noticed thus far in the REL9 beta. So one of the things that we intend to do is we're going to use DNF as our package management utility in REL9. It was actually there in eight. You just didn't notice it because we created the sim link for yum. And we'll continue to do that in nine. But for all of our documentation and other things, we're now going to be using DNF as our preferred command line utility. One of the other changes is modularity. So Don's probably encountered this some with his work with application streams. So I think with REL8, we may have overrotated a bit on modules and packaging all of our stuff as modules. It turns out modules is really hard. So in REL9, we're going to do less modules and more meta-RPMs. Meta-RPMs are a way of creating an RPM that references other RPMs as components. And so I think we'll see that more prevalent way of handling application streams there. Let me ask you a quick question for the group or for folks listening. How are these meta-RPMs going to be different than say like a group install? So a group install works off of a XML file as a definition that pretty much identifies the package name that should be included in the group. A meta-RPM is similar except the RPM itself is what identifies what components are required as dependencies by the meta. And so one of the ones that we've been talking about recently internally has been container tools. So container tools is Podman, Builda, Scopio, and a few others. And so if you install container tools today, you get that all those component applications as modules. But in REL9, you will get the container tools RPM. And if you looked at the container tools RPM, what you'd see is it had a dependency on Podman equal or greater some number and Builda equal or greater some number or Scopio equal or greater some number. And so when you install the container tools RPM, it slurps in those others as dependencies. Whereas today when you install container tools, it goes, ah, you want the container tools module? These are the other modules that are part of this module or other packages that are part of this module. And then when you do like an upgrade with modularity, that's really hard. With meta-RPMs, though, if you do an upgrade of your current container tools, the new container tools meta-package will say, I need a newer Podman. I need a newer Builda. I need a newer Scopio. And then it'll fetch and install those as part of that package transaction, which is a really well understood method of managing software on REL distros. So it's an easier and cleaner way to set up dependencies between packages? Uh, I don't know about easier and cleaner. Let's let's call it different. And it behaves in a much different fashion. So we had things with much authority where like, if you tried to upgrade, it could potentially leave artifacts on the system that you didn't intend. Whereas a RPM upgrade is a very atomic process, right? It like takes care of handling all the file meta stuff that's out there for for the package that it's upgrading. And that was not as well understood or practiced for modules, which is why our recommended practice was to erase the module and then install the newer module. So meta-RPMs will make that less difficult. Perfect. Great, great answer. I appreciate the clarification. And we'll talk more about all of this in the spring as we get closer to REL9's GA. So let's start with Matt. Any closing thoughts? We've got just a few minutes left. I encourage everyone to give the system roles, instruct a try. And please, we've got a really great blog series on system roles. So if you have to configure anything, and especially if you have to configure things at scale, please consider using system roles. Awesome. Yeah, and we'll have Matt on again in two weeks to talk about satellite. And then I think after the first of the year, I believe Don, you and I are talking about a system roles episode, and we're going to focus on SQL server. Also, you want to tease that out a little bit, Don? And same question. Any closing thoughts? Yeah, so stay tuned for the SQL session. I think what we're going to cover there is just motivation on why you should run a database like SQL on REL. I mean, we'll cover like top three reasons. So if you are database fans here, want to run it on figuring out your database like SQL to run on an operating system, you should attend that session definitely to learn more. I'll also touch a little bit upon automation, right? So I think Matthew said the stage value to kind of say why, you know, when you're deploying it in on a fleet of servers, this stuff, especially using Ansible, the REL system roles powered by Ansible is really handy. So I'll kind of show that in the context of SQL as well in the live demo. So hopefully you all can attend and we can do some hands on keyboard work. But yeah, closing thoughts, I think for 8.5, really recommend everybody to try the bits, give us the feedback. Your input is crucial for us to understand how we can move the needle in terms of the product forward for future releases. Awesome. Thank you, Don. Mr. Scott, how about you? I think insert incredibly inspirational quote here. I don't know about you guys, but I feel greatly inspired right now. Also, if you have questions after the fact, please put them in the comments with this video and feel free to like and share. Yes, please like, share, subscribe, all the good things, push that little up arrow. It really helps us know whether this content is resonating with you or not. Join our Discord, check out some of the other episodes and much like REL itself, REL presents is kind of changing and growing. If you've noticed, we've started implementing graphics. We've got a new streaming platform we're using. We're kind of changing up the contents a little bit. We're trying to bring more of the experts on to talk and answer your questions, whether it's 101 or 401 level stuff. We definitely want to keep the feel of the show the same. We all love the kind of laid-back conversation with a demo because what's a livestream without the chance of breaking something, right? I appreciate you all's patience. I've gotten some great feedback over the last few episodes. It's been a lot of changes in a very short period of time. We changed co-hosts, then we changed hosts, and then we changed streaming platforms. It's been a lot. Stick with us. We're doing a lot of planning behind the scenes, a lot of infrastructure-focused changes like the Red Hat Enterprise Linux YouTube channel. We've got some tech tip style videos that we've started to publish, including a couple for Convert to RHEL. Episode 25 in two weeks, 2 p.m. Eastern. Be here, Twitch, YouTube. We'll continue streaming on OpenShift and RHEL for the time being. We'll have Matt on to talk about satellite. Then looking at the end of the year, we've got a cool episode on Podman containers and running a game server at home. Then to wrap up the year. We haven't quite fleshed it out yet, but towards the end of the year, we're looking at doing some kind of a fireside chat where... This may change, so don't quote me, but I'm looking at sending out an invite to this event to just about anybody in the RHEL organization here at Red Hat, have them come on the show, see who shows up, see who shows up in the chat, ask different questions, have different conversations, and just kind of a nice, lighthearted Q&A session to kind of wrap up the year. In that episode, I also hope to announce some ongoing changes for RHEL live streams, RHEL presents. Stay tuned, and until then, thank you guys for joining us. Matt, Don, Scott, thank you guys for helping me out on the show today, and look forward to seeing you all again live in two weeks.