 So awesome. We are an open culture that is really, really, really important for you to get out to work. Everybody has something that they can tell you. On top of the Red Hat portfolio. Good morning, good afternoon, good evening. As the case may be, wherever you are, you are joining us for the level up hour where we consider all things containers. Kubernetes and OpenShift. Glad to have you here today. Please like and subscribe and share. Let everybody know that we are on the air talking about containers to Kubernetes and OpenShift. So I'm Randy Russell, the director of certification. Shout out to all the Red Hat certified professionals out there. And I am joined by Stabby Nick, Scott McBrien, the evil winged minion. Scott, how are you doing today? Doing great. Happy to be here to talk about some open source stuff. Open source stuff. Talking about that at Red Hat, who would have known, right? Well, so question, Scott, are you an attorney? I am not an attorney, nor do I play one on live streams. I am not an attorney either. And I don't play one on live streams. And we even have a banner pointing out that we are not attorneys. We are not giving legal advice. However, we have a very interesting topic today. And that is about the GPL and container images, how they get built, and about compliance. Now, there's a lot there. So set us up here, Scott, and help us to understand why this might be a thing. Well, I think before we can get into why it might be a thing, and especially for the container ecosystem that we're starting to see crop up all around, we probably should first talk about what is the GPL and what does that mean if you're using GPL software? So I know that you are also familiar with this, because we've worked at Red Hat for a minute. But the GPL is the good new public license. Most of the software that we ship with things like Red Hat Enterprise Linux are covered under the GPL version too, but not everything. There are a variety of other open source licenses as well. And those occasionally are also shipped with Red Hat products. But the big thing with open source licensing is that you are obligated to provide the source code for any binary stuff that you ship. So for example, I work on the Red Hat Enterprise Linux team. And there's a lot of open source software in the Red Hat Enterprise Linux distribution. So in addition to providing the binary install media and RPMs through media, the customer portal, a whole bunch of places, we also publish the source code for all of that software that ends up making its way to the CentOS GitHub. And so what that means is that people can inspect or modify that software as they see fit. Right. Well, and it's always informative to actually take a look and see what's in there. If nothing else, because you start to see what the value is that Red Hat adds, I think there is sometimes the impression that TARD archive out there of source code is what just automatically goes into one piece of technology or another. And it couldn't be further from the truth if you think about something like the Linux kernel, for example, we're probably into the, I don't know, hundreds, maybe thousands of patches at this point that get applied to that kernel to make it work effectively for our users. So having access to the source is at the very core of open source. It's that you get to see the entire story start to finish, how it works, and anything that's been done to modify it. And you have this commitment, as Scott says, to share it to others so that they have the same advantage that you did. That's sort of the philosophical point, is that the GPL, unlike some other software licenses, does have this part that says, if you share a binary, you have to share the source. And it has to include the things that you might have changed, right? Absolutely. And I would say that Red Hat goes above and beyond the requirements of the GPL. GPL basically says that you have to provide the source, but doesn't necessarily dictate the terms on how that's done. We provide our source as source RPMs, generally, for a lot of our products. And that makes doing things like rebuilds pretty darn easy, which may not be the case for other open source purveyors. Right. So is there an analogy that we could draw here, he said, looking at his notes? So we used to describe it with something we called the cake analogy, right? Which is if you went to a bakery and you bought a cake, if it was an open source cake, the baker would also have to provide the recipe for that cake upon request, right? So you pay for the cake, but you get the recipe that you can then buy the ingredients and bake at home. You could even make adjustments to it, adding nuts or something like that. But as you mentioned, the open source license also covers changes. So if you brought that cake to your friend's house that had the nuts in it, and your friend says, hey, this is a really great cake, and add the recipe, you're obliged to give it with the addition of the nuts that you added to that recipe. So that's kind of how open source works, right? The binary is the cake, right? Took all the effort, the compilation, and the energy of the finished product. Actually doing the baking, right. But the recipe is the instructions on how to make that thing. Right, right. Well, so just one other thought on this is that the GPL is the creation of the free software foundation. And it is something that is voluntary in the sense that if somebody creates an open source software project, that's a choice that they make to share it under the GPL. And of course, we've all benefited greatly by all the many projects out there that have adopted this as a coherent, insane way to develop software and make it widely available and extend it, right? But I guess the thing that I would ask is, let's say somebody is not compliant with the GPL. Let's say that you fail to share the nuts along with the cake recipe. Or you neglect to share the cake recipe at all. What are some of the consequences that follow that? So again, this is a place where we are not lawyers. We can only look at some historical things of how it's been handled in the past. So there have been vendors that have not, through accident or intentionality, I don't know which, not provided the source code. And oftentimes what will happen is, first, there will be repeated requests for it. And when those aren't met, there's probably some public shaming that happens, right? People go out on the Twitter and grouse about how this company isn't complying with the needs of the license. And then ultimately, people can pursue legal action because the open source license agreement is a contract. And so it is covered under the same legal rights and privileges as other contracts. Right, right. So there's a couple of things there. There's sort of reputational risk. And of course, all organizations and companies are highly sensitive to this now in the social media age. That is the thing that you don't want is to be trending negatively. Everybody's saying that you failed to honor the GPL or whatever it is that they might be saying about you, right? That's one part. And reputational risk is actually very highly valued at a very important risk. But then the other is that there are potential legal actions that can also follow. So this is all kind of scary stuff. But historically, there's been a pretty straightforward way of dealing with providing the source in Red Hat products. So let's kind of simplify and say we're talking about something like Red Hat Enterprise Linux. We have the binary RPMs, the unit of packaging that we use. And then we have source RPMs that there's a corresponding source RPM to every binary we have. And if you have access to the binaries, we also provide access to the source binaries. And that's a pretty straightforward model. But we're here on the level of our containers. How does the world of containers complicate things? So I think the world of containers complicates things, because instead of dealing with compiling stuff from source code, oftentimes we use images that we get from other places that contain open source software. And so let's say that we are a software company. And we pull a container image from a public registry. And we put our software in it. And then we send it on to our end customer. Well, all the open source software within that container image that you based your product on, that's all GPLed and is subject to the requirements of the GPL. So that end user customer could say, hey, give me the source code for this container that you just sent me. And you would be obligated to provide it. And I think that's where things get really interesting, crazy, and dangerous. Well, not really dangerous, but challenging. Let's say challenging, because you have to go back to the container image that you based that off of and figure out how to get the source code for all the open source software that's within it. And I do see that Carlos is asking us about Red Hat software developed by Red Hat this GPL. So there's a lot. There's, well, Red Hat typically will sponsor communities like the Fedora distribution. And that's where a lot of our development happens. But SystemD, for example, was initially started by Red Hat employed engineers through a community upstream with Fedora. But we also pulled in open source projects from other places, like Apache or Angular. Apache has its own. Right. And there are Red Hat engineers that work on that product and contribute code to that project. But we package it and ship it with our product. Yeah. So actually, I had seen Carlos's question, too. And I was like, oh, I'm going to have to pull up a terminal and make sure that my. So RPM, because I just mentioned RPM packaging. There is also the RPM tool. And in fact, it is licensed under GPL. And I think that's one of those things that, for all the real sysadmins out there, do your RPM QI. And you can see that's one of the pieces of information that's shared with every single package we distribute is what is the licensing that it's under? Again, illustrating the world that has been up to now sort of pre-containers where it's pretty straightforward. If I'm going to use this RPM, I can query the RPM and I can find out, oh, it's GPL or it's Apache license or free BSD license. It's whatever it is that it's licensed under. But now in this containers world, things are assembled differently, as Scott was saying. Right. And I think that the thing, just to kind of keep in mind the developer is, do you keep track of the components that you're using for your containerized application in such a way that you could provide someone those components and they could rebuild it themselves? If you're in that situation, I think you're in pretty good shape. Now, there are some nuances there, like you have to give them the exact version of source code that you used when providing them the binary and that can be sticky. So a lot of places where I talk to some folks and they're like, yeah, well, it includes NGINX. So I went out to the NGINX project website and I downloaded the same version that's not good enough. You need to distribute the exact source code that you used for making your thing that you gave to them. So if you took that NGINX base software and you made some changes or you patched some bug or security vulnerability or whatever, you have to provide that source code for that patch as well. You can't just grab the base archive from the open source project and send it on unless your software is indeed solely based on that base software from that project. Right. Well, so we're getting into that whole issue of providence and tracking. And so I guess the question becomes, are there some things that we can, that somebody who is working with containers can do to sort of make sure that they're on top of this and that they're not maybe finding themselves on the wrong side of this and facing some of that reputational risk and facing even potentially some legal action, right? And again, the purpose here is not to scare people away from using containers or open source software, it's to build awareness of what some of those risks are and help people to handle it. So are there some things that people can approach and do? Sure, so one of the things is just compile a list of all of the software contained in the container image that you're basing your software off on. You're building your own container images from scratch. This is probably a much more direct path than if you're pulling a image off of a software registry. A lot of the registries will provide some sort of providence to your container. And from that, like a version or a tag from the project, you could probably go back and cross-reference what was used to make that thing that you pulled. But it comes back to that problem that the requirement is it has to be what you actually used. And so where do you find that, right? Because it needs to pre-built image. And that's going to vary potentially based off of the image that you're using or who built the image that you're using or the infrastructure that was provided by the person who built the image that you're using, right? And release of the image that you're using. Right, and so providence is actually like a pretty big, big deal. So Red Hat in their kind of history of providing really transparent access to source code has made some decisions in their universal base image packaging that I think is like really awesome. And one of those things is that we actually supply what we call a source container, which is all the source code used to build the UBI image that you're looking at. And not only do we provide all of that, which you could like crawl the web and find, we actually provide it as a container. So you can use Scopeo, which is one of our container tools to pull down a copy of the source container for a specific flavor or version of a universal base image. And so if you're basing your software on that base image, and remember earlier, I said that if you pass that, that container as software off to someone, they can say, hey, give me the source code for this. We're already satisfying a very large swath of that requirement, right? So if you just use the container as provided, you can just pull down the source container and that's all the stuff we used for making it. And then you have to just kind of figure out how to manage the pieces that you added onto that container as part of your build process for your pieces software. Okay, so this is an interesting concept because it's the distribution of source via container. How we understand what would actually be in a source container? Because I understand what would be in a container that, okay, there's my container, there's whatever in libraries, whatever applications are needed, the minimal set needed to run this thing that says hello world, but what would be in a source container? What does it do and what are sort of the steps that I would go through would actually use something like that? All right, so we think of containers as like image that you download and then you execute binaries out of, right? And you create additional processes. So a source container is a little bit different because containers, just kind of stepping back a little bit, containers are really just an archive. They're an archive of stuff and it's archives of binaries and files and file system images and other things. And so a source container is really just leveraging that archive format that already exists for containers, but instead of putting binaries in there, because we're red hat, we put source code RPMs in there. So when you pull down the source container, you really just pull it down an archive file and then you need to kind of extract the archive out of it and that's how you get access to the source code. And it's probably a, I don't know, three or four command process to get down to the place where you can actually look at the source code that's in there. Because it's irritating to track versions and a variety of other things, I've written a small script to do it for me. That way I can just like pull a container whenever the script by itself pulls the latest UBI but you could put in as an argument a specific tag number or version number and it would go into the red hat archives and pull that one. But if you'd like, I can just pull one and we could take a look at it. Let's do that. This is almost feeling like a demo, Scott. I mean, it's live. It's live. You're gonna do stuff. I think I'm gonna call this a demo and what could possibly go wrong? What could possibly go wrong? All right, so I'm just sitting here on my personal laptop and I've made this script called RH container source download. You don't need to look at all the other stuff. Here we go. And so what it's gonna do is it's gonna make a call to Scopio and pull down a specific version of a UBI image. And I'll pull up the script in just a second and show you what it's really doing. So it pulls the source container and then it creates a directory and puts it over in temp and then it's gonna go into that and extract from that archive all the stuff in this subdirectory. So I did a bunch of like just shell stuff to track the versions and things like that to make it a little bit more seen for me to manage it. Well, while we wait on this, Scott, I'll ask, I mean, will you be sharing this script under the GPL, maybe? Oh, I mean, it's, I guess I'm actually working on a blog where I'm gonna provide a copy of this as well. Oh, cool. Yeah. You can use it at their leisure. We anxiously await your blog and your script and I don't know if you watch a script operate, does that obligate you to share the script and its source code if you watch it on the live stream? I mean, I think this is a question right now. So we're providing it as a service. So no. There you go. I didn't give anyone binaries, I'm just showing them something as a source code. Yeah, yeah. Man. Is it done yet? Long time. Are we there yet? Are we there yet? Broke it. Maybe I broke it. I might have to just go in there and like manually run all the steps and be really gross about it. Yeah, you know, I didn't like the whole manual and get in there and be gross about it because otherwise I'm just captivated watching your cursor blink. My blinking cursor? There we go. Yeah, yeah. All right, so let me show you what happened here in this output. Okay. So just first, I wanna make sure that I have the right tools. So I wanna make sure that Scopio is installed because Scopio is the tool that we use for pulling our container, our source containers. And then it knows kind of Scopio is included in... It is a container tool included in the Red Hat Container Tools packages. So the container tools are really a team. It's Podman, Builda, Scopio, and then a couple other like lesser known friends like CryU and the one I always forget, Uditsa. Okay. So these are just local tools that we can use for container management. All part of Red Hat Enterprise Linux, right? Yes, and we actually distribute containerized versions of them as well. So you can use them on other container runtimes. It's a whole meta thing. And obviously also available in OpenShift. Yeah. Yes. But OpenShift uses a different runtime. They use Cryo for doing their stuff. And so that's not Cryo as part of OpenShift. It is not part of the general container tools, right? We use Run C or C Run. There's actually both as our container runtime on RHEL. All right. So I installed Scopio or made sure Scopio was installed. And then I just set a couple of variables here for the version of the image that I was interested in. So if I was basing a piece of software on UBI-8 minimal, I want to track what version it was based on so that I can pull the right source container to go along with it. And this one's actually a little older. This is not the most recent UBI image. The most recent UBI image would be based on 8.5, which was released last week. So we also provide the source code for all historical UBI images we've produced and you can pull them out of the container catalog. Down here I do a Scopio inspect. And all that's doing is getting some information about the image that I'm wanting to pull. And then I make some directory structure so I can pull it down. And then this right here, this is the magic sauce. So I use Scopio to copy this container. And I tell it the registry modality from the name of the container and its version number. And then the magic sauce is I put in this back source to tell it that I want the source code container and not the actual binary container. And then over here is the directory where I want it to put that container archive that it's downloading. All right, and then I needed to go in and actually like extract the content to that source container. And so I just wrote this whole for loop here. Source container is a series of tar archives. So I'm just going in and looking for all the tar files in this archive and then untarring them. All right, so after we do all that over here in the directory that I made, this is all the blobs of metadata that we use for tracking the different pieces of software. And so that's really just noise. What you're really interested in is this guy, the RPM durr. And so when we did that extraction of all the archives, it actually allowed all the source code RPMs into the blobs directory and then created these symbolic links, right? So I don't want to cut simple points of the RPM directory, right? So the actual content of the container is totally complex, but then we create in the source container, this symbolic link structure so that we can do a one to one of here's the source code RPM that was used for the software used to make this container. And here's where it's stored in the container or providing ourselves developers. It's really kind of easy to read and look at. Okay, so this invites a couple of questions from yours truly. If I'm thinking about a container, I'm typically thinking about sort of that least possible set of things that I can put in to get the functionality that's needed, right? And so you have a container that is essentially built down to that level. So then you have a container, you have all of the source that went into that. If I'm thinking about all of this long list of source RPMs that you've listed, I'm going to assume that there's things that those source RPMs will build that are not actually put into the container. So is there any notion about somewhere between that source RPM and then what's in the blobs directories, sort of restricting it down to what's actually used? So this is what's actually used for this container. Okay, so it's not, okay, so this is actually whatever is the source that was used for the container as opposed. And the reason I say this is because some of these resemble packages that you might see in Red Hat Enterprise Linux, for example, it is not the same source RPM that you would find there, it is the pare down source. No. Maybe, no. So one of the nice things about Universal Base Image is that it is based off the same stuff as Red Hat Enterprise Linux. So these source RPMs do correspond with ones that you would find in Red Hat Enterprise Linux because we use the same content to make the Universal Base Image, which is freely redistributable and does not require a subscription. So I think the fact that we're seeing the same packages here as we see in Red Hat Enterprise Linux is very intentional because we want them to be identical. And so if we went out to the REL84 source code repository, we could find the exact same versions of this. But the big difference is REL is a very large distribution with thousands of packages, whereas this one is, let's look. Yeah, look at that, real-time scripting. Right. And here, let me pull down one other image. Let's make dynamic updates on the fly. What could possibly go wrong? All right, so instead of the minimal, let me pull micro. You may recall micro from a couple of shows ago. And it looks like it doesn't have the right, there's no version number that's right. Let me give me a second and I'll see if I can find a more accurate version number. Let me try this one. So I think I put the version numbers in before we start shipping micro or for some reason build a micro of the same version tag. But so I just went out to the Red Hat Container repository and we pulled up the page for UBI 8 Micro and then just grabbed the version information from that page, pull it down. All right, so a couple of shows ago, we talked about UBI Micro. And what was the special magicness of UBI Micro and why people cared about it? Uh-oh, is that a trick question? Or is it a statement? It's a question for you, Randy. That's your memory. Well, I do recall that Providence was a subject that came up there as well, as being able to know exactly what you've got in there and being able to track it down, but maybe I'm missing. So we shipped four images with UBI. We shipped UBI init, which is the multi-service image. It includes a full implementation at SystemD. We shipped the standard image, we shipped the minimal image, and we shipped the micro image. And each one of those has less software than the one before it, right? And we're done with the actual container really small. So when I showed you the source code of UBI 8 minimal, there were 91 packages. Okay. So now we're looking at the source code for UBI micro. Tiny. Yeah, a lot less software, right? And so when we were pulling the source containers, we're getting just those source RPMs that were used to build the container image that we shipped with that version number, right? So if you did a UBI 8 init image that has SystemD and there's like a ton of other libraries and software and stuff that goes in there, you're going to get more than 91 packages of minimal because there's actually a container image. You know, that's actually a really interesting list to look at there because that's about as cut down as I could imagine. Yeah, and we've actually been doing a whole bunch of work to make sure the packages don't pull in dependencies they don't absolutely critically need and instead building dependencies in other places like our install infrastructure. So it's like, if I'm installing this, I need to get that, but it doesn't necessarily have to be a dependency in the RPM itself. So, but yeah, like you get a bash shell with this one and that's probably the biggest piece of single software in here. And G-Lib-C is probably, maybe. Oh, that's true. I mean, overall compressed this thing is like I have the page up, I can look at it. Compressed it's 12.9 megabytes and uncompressed it's 35 megabytes. Okay, so that's amazing to me because, as a fossil who could remember years ago installing early Linux from two floppy disks if people even remember what those are, that's getting right back down to sort of the roots but it really sort of illustrates what are the benefits of containers and as God was saying, also sort of the UBI in that sense that you can really, really peer it down to that smallest set of what you need. And that is part of the advantage of being able to run things in containers is that it's only what you need. And that makes it a functionally better solution for an awful lot of things, right? Right, well, I don't know about functionally better. It has a variety of advantages. Well, for a certain use cases is what I'm saying, you know. You know, you can package all the stuff up for your app and send it on its way and you don't have to worry about like what version of Bash, for example, is on the host operating system because you don't care you don't write in your code. Well, you've provided everything you need but you've provided nothing that you don't need, which is also just in terms of being able to start up your app and run the app. It's just a different situation than saying let's for just to draw a parallel going to a VM, right? The VM is a full operating system. You're bringing along, you know, all of what you're having there, much of which you might not actually be using doesn't mean it's not useful somewhere for someone but for your particular application, it's not that useful. Whereas for the container, it is only the things that your application needs and nothing else. And you know, looking at sort of the smallest image with 15 packages, it really does illustrate in my mind just exactly what it means when you say that a container is only the stuff you need. Fair point. So to continue like talking about the actual source code and like how we represent that, I went ahead and installed one of these source RPMs and I chose to use the bash one. And so included in the source RPM name is the version that we're basing this version of bash off of. So this is a bash shell based on version 4.4.20 from the bash open source project. But then what's interesting is there's also this bash 2 EL8. So when you're packaging an RPM, there's several components of the version number. Some of them are from the open source project that you grabbed the source code for for compiling the software. And then there's an extra version number that's there for the RPM package or the person making the package. And what we're doing here with this dash 2 EL8 is the developers that maintain the bash package for Red Hat are keeping track of their changes and their versions of bash that's based on bash 4.4.20 from the upstream. Because remember that Red Hat does things like backporting where we may take a software patch from upstream from a newer version of bash and backport it into this version of bash to close a bug or resolve a security issue or remediate a security issue with the version of the software that we're shipping. And so that's what you're seeing here with this dash extra version number. I will caution you, don't try to read too much into the extra version numbers. Different software management teams at Red Hat use different methods for determining it. So for example, the kernel team has a really complex versioning scheme that they use in the extra version number whereas others are more simplistic. Some use the version of Enterprise Linux that it's tied to others don't. Like just know that if it's bigger, it's newer. All right, so let's see where this thing ended up. So I just did a RPM query so I can look at the contents of the source RPM. And I think what is most interesting is these guys. So while we based our bash RPM on 4.4.20 there's been a whole bunch of patches that have been applied to the software to do a bunch of things. And this is the thing that we were talking about earlier. And here's actually some stuff from upstream where we took code from bash five and backported into bash 4.4.20 to resolve a specific CDE common vulnerability exploit that was available in 4.4.20 that we were shipping. So if we just went out to the bash project page and pulled software 4.4.20 and sent it on its way we're not complying with the GPL because the GPL requires that we provide the exact source that we used when compiling this package. And so we have to provide all these extra patches and things to kind of make that happen. The other thing that we provide is the spec file. So a spec file is the specification for building binary RPMs. So with this source code archive and the spec file you can use the RPM build command to make replacement binary RPMs. So you can go into the source code and make changes and then build your own version of them based off of the source code that we provided. So this is kind of the culmination of our discussion I think. It's reached a crescendo, a fever pitch of source exploration. But this is all familiar looking stuff once you get it unpacked into the source form. I think the key piece here is to understand that you need to think through your images and the implications when you're using containers and what you might have to actually distribute if you are distributing your app as a container, right? Especially if you're doing so in some sort of commercial setting, right? Is that, and I think we see this more and more where that's going to be the preferred way to distribute an application is just say, well, look, here's your container. Go run it on your, you know, rel or OpenShift or however you want to run your containers. Well, okay, be mindful commercial vendor that you might need to think about what went into that and how you're distributing it because if you're using the GPL stuff and there's a lot of it, you do have this commitment to sharing these things and there's a really important benefit to the end consumer of this. It's okay, so let's say you have this application and you're having a problem with it. Well, being able to investigate it is one of the powers of open source. Is that you can, if you have the inclination and ability and resources, you can go and take a look and see, well, okay, maybe there's some patch that did get applied, for example, that is usually good for everybody, but there's something unique to your operating environment or your application or whatever that it's not good for you or it needs to be enhanced in some way. And this is also how things improve in the open source world. Is that ability to go in there and say, see the prior work and go, well, okay, here's an issue. Yeah, and I think one of the things that we take for granted in the container ecosystem is that container images are easy to come by. There's lots of different registries, but where did that image being offered by the registry come from? So there was recently someone in a container Linux that posted on Twitter that he was not interested in any problem reports from the WSL version of their container because that didn't actually come from their team, that they allowed someone else to build the container image for that container ecosystem. And I'm not saying that the person rebuilding it has done anything dastardly or anything like that, it's more just like, it has passed now through several different hands to find its way onto another container registry. And like, did they track all the same stuff? Did they make any changes to make it compliant for that container registry that have to be documented and shared? That's the cautionary kind of statement. That's something that we at Red Hat take really, really seriously, which is why we make sure that the source code for all of our stuff is easily available and readily apparent. And we try to make things like source containers, which is a technology that as far as I know, nobody else has picked up. No, I was just going to ask, I don't think really anybody else is solving the problem in quite this way. That's not to say that there might not be some other solutions to it, not sure if there are, but certainly this is sort of a very Red Hat take on how to solve this particular problem, right? Right, and I think it's born out of our long history of needing to solve this problem that we're like, okay, we know how to distribute RPMs, we know how to distribute source RPMs, let's just make sure that we have that one-to-one comparison, right? Compared with some of the more organic methods of managing open source of like, oh, I'll just download 47 TAR archives. That this is a little bit more structured and that is helpful. Yeah, so a couple of questions. First of all, we have a really important question. Where'd you get your shirt? Carlos Santana, love your stuff, man. Where did you get the 8-Bit shirt? So this is my favorite Red Hat shirt. I'm glad that you all like it too, because it's my favorite. It was a booth shirt given at AWS re-invent 2019 for people working the Red Hat booth. So like it's extremely limited availability. And I don't think we have, I don't think maybe it's where you can get at. Well, well, so it goes too bad. Okay, so another question. You mentioned the blog. Do you have any idea when that's gonna land? Sometimes the author of blogs lasts to know such things. Don't ask me how I know. So it is part of our RHEL 8.5 blog strategy. So it should land in the next couple of months. The person who's actually in charge of managing the publishing is also asking the same question because I haven't yet finished writing it. So yeah, it'll be out soon. How about that? It's a great Red Hat discussion. Soon, real soon now. Okay, well, so the other thing you can do is you can tell the person asking where your blog is. You can just point them to the recording of the level up hour and just say, there you go, done. There you go. All right, well, so anything else that you wanna sort of wrap up with or mention and of course, if there's any questions, folks, do let us know, Scott. Yeah, so certainly questions in the chat is good. I thought that there was one about Git somewhere. Oh, there was, yeah. Oh, can you provide the GitHub repository that contains the source for all UBI images? So the GitHub that we published source to for Red Hat or for RHEL is the CentOS GitHub. Oh, let me see if I can find that. And then, oh, and it also has Docker files and some other things there. So let me just copy and paste this so we can put it in the chat. Or actually, I could put it in the chat. How about that? You have the power. Boom. So this is where you can find all of the Red Hat source, at least for Red Hat Enterprise Linux. And then there's a variety of other projects that go there too. Cool. Not seeing it though, Scott. I pasted it into YouTube. Let me put it here in our chat, maybe it needs to go to other places. Let's see here. Paste it. See, we live to serve here at the level of power. You ask, we deliver. There we go. Now there's copious links to GitHub. All right. There you go. All right, so Scott, anything else you want to mention on this subject? Has any on lawyer, you know? So, I am not a lawyer, nor do I play one on the show. I think the biggest thing is, like I mentioned earlier, if you are working with open source software as a developer, one of the things that you should think about is if I were asked for my source code, how would I provide it? And if you know that you may be asked that question, you build processes around gearing up to be asked that question, when somebody actually asks you that question, you're ready to go. A lot of times you'll get those questions because somebody in your company's legal department is like, hey, this thing, open source, what's going on? And you have to trace it down. Randy, a long, long time ago, sorry, this is a story time with Uncle Stabby. A long, long time ago, I was working for a company that was becoming a Red Hat partner. And one of the questions from that company's legal team was how do we know that the source RPMs provided by Red Hat actually build the binary RPMs that are on the install media? And my resource... Reasonable question. It's Red Hat and it's their license and their product, so it kind of has to. And they went, yeah, not good enough. So I spent a week or so going through and compiling all of the RPMs from the source RPMs and then matching them all up because the source RPMs sometimes builds more than one binary RPM. Nope. You have to figure out like which ones go to which ones. So yeah, that was a fun exercise of spreadsheets and compilers. So... Yeah, and at the end of that journey, did they go, okay, we get it, we believe you now? Yes, it was like, here's my spreadsheet that shows the mappings of all the sources to all the binaries. And here's the list of binaries that come off of the install DVD and you can see that it's a one-for-one mapping. And they were like, okay, that's good enough. Yeah, yeah. Well, I remember, again, years and years ago undertaking the project at home that I was going to rebuild the entirety of RHEL from source. And I wrote a script, you wrote a script, I wrote a script and it was chugging along, working very nicely until I ran out of disk space and that was the end of that particular project. And it was also, this was over like a 56K mode or something. So it was like, it was a very long overnight build before it eventually just crashed out and a lack of disk space. Anyway, very, very informative stuff there, Mr. McBrien, you know, I don't... Oh, I do have one last thing. So... Do tell. I think it was two weeks ago now, we released Red Hat Enterprise Linux 9 beta and that is available to anyone with Red Hat subscription, including those with a costless developer subscription. In addition to the Red Hat Enterprise Linux 9 beta and making it available, we built all the UBI images for Red Hat Enterprise Linux 9. So the RHEL 9 UBI beta images are available in the Red Hat Container Catalog today. Wow. They've been there all week, but, you know, I'm... Well, that includes today. It does, yeah. It's not like it's not true that it's today. Well, that is big news. Obviously, Red Hat Enterprise Linux 9 is much awaited and sought after and this is an opportunity to get an early look at it and look to the whole point of the level up hour is the world of containers and Kubernetes is very much where we talk about here and it's exciting to know that part of that RHEL 9 beta program is that we're out in front of it with those UBI images that people can start using already and sort of bang on them and see how they work. So a great update. Anything else, sir? Because we switched Red Hat Enterprise Linux to the predictable release cadence where we release a new major every three years, we have beta out now for RHEL 9. We should expect that to land in mid 2022. Mid, mid. See, but I like that though. We're kind of going out on the limb there, but, you know, that's the lovely thing about the Red Hat Enterprise Linux team is they are nothing if not reliable in their release dates. So... You say that, but yeah. We will meet mid 2022. Oh, yeah, mid. I mean, mid, you know, properly understood could cover anything that isn't January or December. Right? Wow, it's still you working marketing. All right. So before I get myself in trouble here, I want to thank everybody for joining us again on the level up our please do like, subscribe and share. We are here most Wednesdays and look forward to having you tell your friends, you know, I'll let us know if there's some topics that you think we might, we should explore and discuss. We're always looking for new topics and things to explore. So, you know, let us know. Thank you for joining and have a great day or evening wherever you might be.