 I'll just sit down there, slowly, quickly. You guys are ready? Oh, sure, yeah. Yeah, we're gonna pass it around. All right, sort. Shall we get started? Jirko, I haven't given up yet. I'll sit down there, but I won't break it. I just want to make sure I don't leave behind a drink of water. All right, that's it. Hey, everyone. Can everyone hear me well? And this is for the rooms that are downstairs more. Soundcheck, perfect. So, welcome on DEF CONF, day 2nd Saturday. I'm glad to see that many people here. That means that the party wasn't dead hard last night. That's perfect. Let's just make a real quick few announcements. First thing, the party starts tonight at 7.30 p.m. There are instructions on the website, and also in the main lobby how to get there, what trend to take. If you didn't get the ticket, unfortunately all the tickets are gone. So, as I suggested yesterday, there are a couple of good places around this venue, so grab some friends and do your own party. Unfortunately, we can't squeeze more people in there. One thing that I forget to announce yesterday. Last year, at the very last session of the conference, we did a very popular pop quiz, as some of you might remember. Just a quick announcement. It's going to happen again. On the very last session of the conference, it's already in the schedule. We will do a very special game, and you might be able to win some interesting prizes. We're also trying to force you to stay here most of Sunday as well, because all the talks are really interesting till the very last one. So, stay around, I know it's tough, but there's going to be a nice surprise at the end. One quick operational announcement. There is a room change for Judcon. We realized yesterday that the Judcon room is too small for the audience that are getting. So, the Judcon is moving to one of the e-rooms, and the workshops that we're supposed to be in the e-room are moving to the e-room. So, it's announced on the schedule, the schedules that are out there are all updated, and there's also a room change announced on the room where Judcon was happening yesterday. And another thing, lost and found, we have some stuff that might have been forgotten here yesterday. It's at the cloakroom, so you might want to stop there at some point, or if you find something during the day, please hand it over there. That's the right place. And food trucks will be here again, so if you haven't found them yesterday, because some people had troubles finding them, it's actually over in that small parking lot behind the e-building. You use that tunnel over here to get there. They'll be opening very soon, so grab some food there again. That's it for the operational announcements, and as I promised yesterday, our keynotes are somehow special this year. We have a lot of people doing the keynote together. I hope you enjoyed the keynote yesterday, and we will be having a similar type of a keynote this time, or right now. So with that, I would like to welcome Adam Miller, Denise, Matt, KB, Karambir Singh, and Honza Horak, representing Fedora, Rel, Fedora, Santos. Santos, Rel and Fedora at the same time. And with that, it's all yours. Thank you. Yeah, as you can see, it's all about collaboration, right? So, Rel, Santos, Fedora, all of us, better together. We got a theme going on here, and if I can make this move, or you can make that move. A story of three distros. So once upon a time, there was a distro. It was a Red Hat Linux distro. It was many years ago. And then it needed an upstream, and there became Fedora. And Santos evolved as well. And these three major Linux distros are part of the Red Hat family now, all together. Fedora, Red Hat Enterprise Linux, and CentOS. In the early days, it was easy to talk about a distro as a thing, right? It was a big collection of packages built, especially the important part, built with a common tool chain, built because people couldn't deal with dependency hell. That's changing. The lines are blurring, and now the operating system is just the beginning of the places where we want the collaboration to happen. And so this morning, we're going to walk you through what some of the evolution of those changes has been, what the communities and the distros are up to, and where we're going in the future. At least what it looks like today, right? Next year we'll come back and do this again, I hope. So the distros are evolving, and the stereotypes and misconceptions of the past are... Well, they're past. This Escher waterfall, if you look at it, it was the best picture we could think of. It was the best picture we could think of to describe the way things are working today. Any of you who work in Fedora or Centerville, which is probably everybody in this room, right, understands why this is appropriate. Upstream, downstream, it's about more than the platform. It's about being the platform on top of which additional collaboration can happen. Fedora is always going to be the leading edge. Matt says I have to say it's not bleeding edge. It's not bleeding. There's no blood. But it's a huge collection of packages. Today it's, what, 17,000? 17,000. And it's the upstream and upstream for RHEL. RHEL is Red Hat's Enterprise Linux distro. For those of you who have managed to avoid that knowledge at this conference, it's hardened, it's fully certified, it provides stability and long-term support to Red Hat's customers who pay for that support because they need to be able to pick up the phone at 3 o'clock in the morning. And you guys, you know, if you work for Red Hat, some of you know what it means to answer the phone at 3 o'clock in the morning. CentOS takes a similar platform and it makes that platform available for communities to innovate on top of because that's what enables more communities and brings them to the Red Hat family because it's all about family, right? So the once bright lines between the three distros, they're fading and there are new technical challenges that are heading our way containers. And so we're already doing a lot more than you might think collaborating between, especially in the infrastructure spaces, right? Fedora and CentOS and RHEL, there's a lot of collaboration going on today. We're going to be doing more of that but now we're going to talk a little bit more about what makes us better together. So I'm going to turn this over to Matthew Miller, the Fedora project leader, followed by KB Singh, the CentOS project leader, followed by Adam Miller. Adam, what are you now? You're everything, right? You're Mr. Container. Yeah. And Hansa, Hansa Horak, who is Mr. Software Collections, and they'll be talking more about some of the cross-disfro efforts. So Matthew, take it away. You've got your own mic. I got my mic. They trusted you with one. I know, right? But they didn't trust you with a water bottle. They shouldn't. Okay, so I know this isn't collaboration, this is just bragging. I wanted to start off with this. We had a really great Fedora release, this last release, it had an amazing reception in the press and a lot of the people in this room are responsible for it, so I wanted to say thank you to everybody. Can't see my notes, so we'll just make stuff up. That's awesome. Yeah, so this is a very well-received release and I often do this talk at DevCon where I go through a whole bunch of statistics here and so I wanted to sneak some into this as well. This is basically, I can go into the details of it later if you want to know where these numbers come from. The important thing is don't try and read anything really significant into the absolute values on the side here. These are check-ins into our mirror network for updates and there's a lot of reasons that doesn't represent the number of systems we have, but the overall trend is probably something you can get something for. So basically Fedora 21, 22, 23, 24, almost all going up, 24 goes down a little bit, but that's only because Fedora 25 came out very quickly and so people started shifting over to that and I think we're on really good track for Fedora 25 to easily be the most popular Fedora we've ever had, so again, thank you to everybody who's worked on it and congratulations. That is a really nice achievement and I think it really shows that a lot of the things we've been doing recently are really well received by the world, so again, that makes it feel like it's nice to be working on something that people like. Are there people who are not familiar with these values here? Is this new to anybody? Awesome, everybody in the room knows this. These are the foundations of Fedora here and kind of puts it almost 10 years ago, kind of put together this idea of like, what's Fedora built on? What do we really care about in Fedora? What makes Fedora Fedora? And all these things still hold true today are incredibly important. The one I want to focus on really here is the Friends Foundation because first is important, we're talking about CentOS and Aurel and everything, obviously things happen first in Fedora that flows into those other distributions in a lot of ways. One of the things we're changing a little bit is kind of an innovation going into CentOS on the layers kind of around the base operating system, so that's kind of a new thing. Fedora doesn't have that monopoly on first, which is a good thing. And we also don't have a monopoly on freedom. All three of these are free software distributions, so that's awesome. And we obviously also don't have a monopoly on Friends, but one of the things that is important, let me just step forward to this, Fedora, about 3,000 people contribute to Fedora every year for the last couple years and that is an amazing number. And I made a list of all of the groups that I could think of here. I hope I haven't skipped anything important because I'm sure I did. There are so many different things that people do in Fedora. A lot of people may think that we often get new people coming to Fedora and they're like, okay, what can I program on? That's kind of their idea of what making Fedora is, but a lot of this stuff requires a whole diverse skill set of different things of people working together and there's just so much that goes into it that is very amazing to me. So about 3,000 people do some level of contribution and of those, in all these different areas, I kind of looked at some of the different activity levels of different things and I discovered that as a general rule across all of these, about the top 10% of each activity area kind of is about two thirds of the work, which I think is actually a really good ratio for a community project. A lot of times you have something where one person is doing 90% or the top 10% or doing 99% of the work in the project. So in Fedora, we've got kind of a long curve, which is pretty cool. And this is a slide I've shown. This came from a DevCon. Oh my goodness, okay, yeah. This aspect ratio is really bugging me, I don't know. Imagine that's a circle. So yeah, this is something I made last year and actually I went and looked again and the numbers are basically still the same here. So of those, that top 10%, about 300 people who do most of the work in Fedora, although a solid majority, but not all of the work. But of those people, I went and looked and I actually went and looked by hand to make sure the people that I could identify as red hat addresses were easy. That's the chunk there, about a quarter of people are using red hat addresses. And then there are another little bit that are red hatters but are using their own email addresses at other locations. That's, I said sneaky in my chart, but that's actually often because they're people who come from the community hired by red hat and they have me, for example, I have all these filters set up in my account and I didn't want to change my email address because all my filters would have broken. So I went through my hand to make sure I counted everybody that I could find that was in that state as well. So it comes down to those core people, about a third of them are red hatters and other two thirds are people from everywhere else in the community, from other companies or individual contributors and that it's not like these people are just doing fringe things. There are very core parts of the operating system and core parts of Fedora leadership that are people outside of red hats. So I think that's an incredibly valuable thing we have in Fedora and it's something that we bring to this ecosystem that I don't think we would get in any other sort of way. So I think that's a neat thing about Fedora. But that said, this graph is kind of an interrelationship graph. So Fedora makes an operating system, obviously, and we make different versions of it, different editions, the Fedora server, Fedora workstation, this kind of things. And we also have this big collection of packages that people work on. And so this blue line here, which it looks very flat on the scale, but if you look at the last couple of years, there's actually a very nice rise there and the peak is quite high above the highest that it ever was before. So that's the same statistics as before, Fedora-Mir network connections. But this red line is enterprise packages, extra packages for enterprise Linux, Apple, which is the same Fedora packages built to run on rel and CentOS. And you can see that is incredibly popular. Everybody loves Apple and it continues to just skyrocket there and I expect it to be further and further off the charts in the future. So this is an important part of Fedora that is often somewhat overlooked, but really one of our most popular things and most valuable in the world, people really depend on this. And it's actually something that is in a lot of ways a cross-distro collaborative kind of thing. And so in the future, I'm getting into the future part, I would like to build on that collaboration more and do things where we're actually working more directly with CentOS on Apple and trying to get people who are using CentOS and depending on Apple to feed back into the Fedora community and try and think of themselves as Fedora community members rather than just consumers. And that's kind of a hard bridge to build so I would like to work on making that happen as much as possible and make people feel like I'm a CentOS OS user but I'm also a Fedora user and have a joint loyalty rather than just saying I'm a CentOS user, that's Fedora people doing their thing up there, which we see sometimes and we don't want to try and bring change to that. Also, as we get into the containerized future, so we do a lot of work here which is basically recompiling the same thing to run on a different platform for that's the only way to do it back in, you know, up until now pretty much. Containers have come along and we have the ability to just say rather than rebuilding it, why not just run these Fedora packages in a container? I expect that this Apple 7, I don't have these broken down by versions here, but to be the last really big version of Apple, I think that in the future as we have future releases, it will be just a matter of mixing and matching Fedora modules, Fedora containers that can run on top of these enterprise distributions. If you want the leading edge version of something or if you want, you know, even to go to Rawhide and actually choose the bleeding edge, you can get those things and run those on top of a stable base or if you want to have a fast-moving kernel and SystemD and have fast-moving base, you can get that and then run CentOS or, Braille, I don't know, on top of a Fedora base. I think that's a lot of exciting opportunity and I think that we can only really get to that if we start collaborating more and start trusting each other more as a project. Right now there's a lot of this rebuilding like people doing stuff in CentOS, take packages from Fedora and, you know, compile them just because rather than using the Apple packages, so we've got trust both ways to build up. And, yeah, there's a lot of other exciting things we can do for collaboration. One of the other big things that I did not have a slide for, Copper is a service that basically lets you host your own little repository very easily and that is something that, again, targets both, you know, Fedora as a base OS or CentOS or Rel as a base OS. And so that's a neat existing collaboration thing and one of the things I'd really love to see is a connection between that and the container pipeline that KB has built so that you could click something and instead of just coming out as a set of RPMs, you get a container that comes out of it and maybe run through CI and everything. There are a whole bunch of ideas like that and I'm really hoping that when we stand up here next year, yeah, right? When we stand up here next year, we can say, you know those things I said were some good ideas? We can talk about how we did them all. So I encourage all of you guys to help us do that over the course of the next year. Okay. Thanks, Matt. So basically what Matt is saying is get your editors ready and submit a patch. Right? Oh, that's fine. I don't need this. So how many presenters does it take to change a slide? Right? Not enough. So hi, guys. So before I go into my little bit, I just want to say thanks to Radick for actually inviting us all here and I think it's a privilege to be here with these people and to be able to talk to you about our perspective on the CentOS project and what we're doing and where we've been and things like that. How's that? Okay. So if you look back, right, Red Hat Enterprise Linux came up and it came up to execute against a very specific mandate. There was a very specific requirement. There was a gap. Linux was becoming a thing. The idea of open, the idea of there being a complete solution that could go and execute in commercial spaces and yet be open and yet be inclusive and yet be built in a sort of community kind of fashion was still maturing at that point. And then move forward a little bit and the CentOS came up as a downstream. We were taking the sources. We were trying to deliver a similar user experience with no obedience, no SLAs. If it breaks, you should know how to fix that kind of thing. And then at the same time, there was this big void that came through that the community at large, the Linux groups, the people who are contributing code, not specifically Linux, but people who are writing code, didn't really have a single place to come together to be able to innovate together, to be able to use a common format in a common way, to be able to succeed independently. If I write a piece of code, I don't really, like the example you were talking about earlier, was I'm trying to create a better font for X11, right? I didn't want to need to know how to compile my bootloader as well. I was kind of hoping somebody else had solved that problem at the time and which is sort of the genesis of where Fedora came from and the bootstrapped up and he fast-forwarded through 14 years ago, right? So this is 14 years ago. He fast-forwarded through to where we are today, 2015, 16, 17. And a lot of the mechanics around what we do, how we do it, why we do it have changed. They've evolved. Adam put it in really well that we've delivered, right? We've delivered. And how we've delivered it is in a collaborative fashion that everybody's included. And what that really means is, I think the easy way to explain that is I'll give you an example. I was involved with the London Linux user group for many years and I'm old like that. In 2003, 2004, 2005, you could fill an auditorium like this. You could fill a room with 150 people every Saturday. And you'd talk about how to rebuild your kernel to support the PCI bus, right? So that you could get this new graphics card that you just bought and you could get 800 by 600 resolution in more than 16 colors, right? Well, we've all been there, right? At least the old ones have. The youngsters probably don't know what the VGS pack was and how the SVGS pack made the whole world look so much prettier. But then, so coming forward, right? So 2009, I remember going for, I fell out. So 2005, 2006, I stopped going to the meetings. I had other things going on. So 2009, I thought, you know, let's see what the situation is. I went back and it was this five guys whom I used to hang out with back in 2003 who came together at a pub to talk about the good old days. And this was the London Linux user group. So you're trying to figure out what happened and what's really happened is that people now trust Linux. Linux is a niche enough, right? We won. The whole argument of whether open is even a question no longer exists, right? The big guy in the big house in Seattle now talks about open. So I think that conversation is over. But we move forward. And what we've really got in here is we've got confidence. Like if I go and talk to a bunch of people that, hey, what do you do? I do Linux. Like, okay, tell me something new. I'm running Linux on my phone. So it's like, it's no longer a thing, right? But what does that actually mean? It means that you have a product that you got from somebody. And that name comes with confidence, right? But in a community space, how do you deliver that confidence? Like if I ship a PHP package from CentOS.org, a lot of people who've used it in the past will have past experience. They'll be like, yeah, you know, well, CentOS hasn't broken my PHP in the past. You know, I spoke to this guy who knows somebody, who knows somebody whose uncle said that, you know, PHP from CentOS is kind of okay. But from our perspective, what happens is that it's a huge risk. Now, if it did break something, then we're breaking a promise. And the way to circumvent that is that, hey, I think my PHP packages work because I ran these four tests, and they said that it's good to go. And if you want, here you go, these are the four tests, you run them yourself. And if you've got a corner case, as in, you know, you do something with MB String or with MySQL or whatever, write a test, send it to us, and we just won't ship a PHP that breaks a test, right? It's a simple thing like that, but it's a huge change in mind space, right? And what we're really trying to do is figure out that over the last 14 years, we are where we are, largely successful. We've made some mistakes, we've done some good stuff. But over the next five to eight years, what is going to be the challenge, right? What is the typical user, not the Linux user, not the crazy geek, you know, sitting in the back of the room, but a typical user consuming information technology, right? Where are they going to be in 2022? Where are they going to be in 2019? And what is it that we can do to enable communities to be able to succeed in the areas that they care about, right? If you're in the business writing bootloaders, perhaps your consumer base is reducing. Not everybody is going to be submitting patches to you. But if you're in the browser business, there's a lot of interest towards what you're doing, right? So how do we create an environment that allows those communities to come together and succeed? So towards that, we're investing quite heavily in CI. I don't know how many people here are actually using it at the moment, but we have a CentOS CI setup where we test the infrastructure, we test the distro itself, and then we make this infrastructure available to any project who wants to come along and consume this infrastructure. There's no cost associated to it. There's no CLAs, any of that kind of stuff, right? We want it to be open. It should be distributable so that it can be public, and then you're welcome to come along and consume this stuff. And you can then consume this stuff in a way that you can integrate with other people consuming the same stuff. So there's a classic example, something that actually happens over there, is that we're testing the kernel on a nightly basis, which doesn't actually change in CentOS on a nightly basis, but we're also testing QEMU on that kernel changing nightly. The QEMU, of course, doesn't change nightly as well, but we do get a few patches come through sort of every week. We then check LIBORT running on top of that QEMU, running on top of that kernel on a nightly basis, which then is used by the audio guys to test NOVA against that LIBORT running on that QEMU, running against that kernel. And then suddenly out of nowhere, these crazy guys called the Gluster team come along, and then they are now a part of the project as well. And then the SEF guys come along, or the SEF guys didn't come along, it was the OpenStack guys who brought SEF along. So if you work on the SEF project, you should come along. And SEF comes in, so suddenly you can now have an OpenStack RDO setup, which is integrating on a nightly basis across the platform, across all of those guys, right? And then you take that a step further. We're now doing deployments for Atomic Host, we're now deploying OpenShift Origin on a nightly basis. I think, I believe from the 15th of February, we'll be going per commit. So per commit to OpenShift Origin, we'll be deploying the entire stack, and you'll be validating that against a set of applications that exist, and then we know, like, we can communicate that back to different people and stuff. But the main promise here, the main promise over here is that as a consumer, as a part of a community, you have a way to integrate not only your own code, but with other people as well, and build that confidence, extend the confidence that people already have in a platform, in a name, extend it and make it tangible. Make it like, hey, I know this works because this is a test I ran, right? I think the example I was giving Hansa was like, you know, you buy a BMW, you probably drive out to the showroom, get onto the Autobahn, you know, drive across Europe. I built a car in my garage. I'm going to do a lot of testing before I get onto the Autobahn, right? I don't want to be, like, sitting on my bum, right, where the wheels have fallen off somewhere, half of the car has fallen off somewhere, the engine's gone off, right? I want to know. A lot of people perceive open source communities to be an ad hoc collection like this, right? But if you come together, if you can integrate together, we can build a better car as it were, right? So that is one part of what we're doing in the CentOS piece. We're trying to bring everybody together. We're trying to bring everybody into a place where we can deliver that confidence. But what we're also trying to do is that we're trying to take the REL source experience, right, the REL platform, and take it beyond what REL does. Like, for example, a lot of work that Jim has been doing with Peter as well, on the arm server side of things. You know, it's like this huge collaborative effort from REL engineering, from the partners who are involved in this space. And we've actually got an ecosystem that has evolved to a point where nine out of ten places where you buy an arm server today, you will probably get CentOS as a pre-installed default. And what that means is that the kernel on there perhaps has a winter salt on it. It's possible that the installer on it and it doesn't really, you know, sort of smell like, it doesn't taste like CentOS as such. But the user land under it is CentOS, which means if you're building stuff for that, you have some level of confidence that it will actually work across the base. But the big win over here is that a lot of people who only do Intel code at the moment, who are only x8664 optimized, they can now standardize their APIs, APIs on x8664, and they have an easy way to kind of go across to ARM as well, right? And I say this with full credit, but the fact that we're doing this now, Fedora's already stabilized this releases ago. But the difference being that a lot of the people who are new to architecture world need that slow-moving lethargic platform that doesn't keep changing on them every six months to even year, year and a half so that they can take their time, right, getting into that place. Like for example, we have the open power guys working with us on getting the power eight and then the power nine stuff sorted out. And I know the overt guys are very keen on it, the cluster guys are very keen on getting the power and it's all based on the fact that they've already got their pipelines in place, they've got the bills, the CIs, et cetera, and they can now go and do this work for the other architectures as well. And it's combined, right? So we feed off Fedora and then we feed into REL and the partners come along as well for that. And so what we're really trying to get to is the fact that communities should be able to integrate with communities and help each other succeed. So it's not Red Hat storage working with the Red Hat's OpenStack product, it's a video, right, working with Overt and not Rev. So the promise there being that the work that they are doing targets an existing REL base and therefore they can consume CentOS. But also the infrastructure that comes up around it is such that they can go do this in a way that they can independently succeed. Like Gluster.org should succeed as a project of its own, regardless of what happens when the product dies downstream. Therefore it's important for them to stay with Fedora because they need to make sure that they can integrate with the stuff that's innovating. Like SystemD happens. You want to basically be right in there, right? You want to be, I don't know about you guys, but if something like that changes on me, the first thing that I'm going to do is I'm going to write some integration tests and I'm going to make sure that my integration tests are included in their CI just to make sure that they don't change shape on me or they don't change my code or they don't do something in an API or an ABI that's going to break my stuff, right? And the place to do that, right, and this is not just for the Red Hat family, but for all of the other venues that have the same attributes to open source today, the center of the world for that funnel is Fedora, right? You cannot actually get out of that, but if you're building a product stream or an infrastructure stream that targets a rail-base or that needs that slow-moving lethargic platform, then CentOS is a great place to come and work with. And the stuff that we're doing together, I think Matt kind of went into a lot more specifics about specific things, like, you know, the different tool chains, the tasks, et cetera, hoping that that basically makes this collaborative effort completely frictionless for the user. The user experience from the Fedora perspective versus the user experience from the Centros perspective should basically be invisible. And the on ramps from that should be further invisible. And just to wind up, the one example is that I had a short chat with Paguir. Paguir? Paguir. Paguire. Thank you. And what we're trying to do is that we have a CI manifest that is in the upstream repos. And what would be really good to get to? I don't know if we can. There's confidence that we can get to that point is that any Fedora repository hosted in Paguir will have a checkbox that they can tick. And all that that does is that enable CI and CI feedback for them automatically through the Centros infrastructure. And this is software that could run on Centros 5, 6, and 7, or on any Fedora version that Matt thinks we should have. So basically everything from Fedora core 14 onwards, I guess. So I'm going to head off to Adam, who's going to talk to you about some really cool stuff about where we are actually collaborating. Thank you. So I'm going to be discussing the container ecosystem and where that has bridged gaps between the distribution communities and things we've been working on that space to try to come together around common solutions, around common technologies so we're not continuously reinventing a solution for the same problems between our projects. Because at the end of the day, a lot of different components of what we're doing on the back end as technologies, as tool chains to create and produce content and software that our end users consume is very similar. We have very similar patterns. We have very similar workflows. And with the relationship of upstream to downstream, we share a lot of technology. So the container ecosystem and how it's kind of brought us together. When containers first showed up, it was kind of a wild culture shock. You have a lot going on. You kind of have to figure out, kind of fill your way through it. And we could have done that in silos. We could have done it in very different paces and we could have just kind of had a very similar scenario to what we used to have 10 years ago in the way that the different distributions adapted to different technology challenges and the paces at which we do that. But we didn't. We went ahead and started to discuss things across distributions. We discussed things across community. We tried to collaborate on those. And we've done a lot. I'm going to talk a little bit about what we've done and then also where we want to go with it. So first off, I want to kind of frame the idea that the container ecosystem has allowed us to decouple application run times and our software stacks from our base operating system run time, the core platform. And that becomes very interesting because it gives us the ability to, again, have some mix and match of components and have the ability to run things that would have traditionally needed to be recompiled for a different platform on that platform by way of sharing content through the container images and run times and those kinds of things. So Project Tomic, for most who know, is an upstream. And it focuses around both this container platform and optimizing that as well as container technology as a whole in ways to distribute them, in ways to consume them, in ways to execute and run them in a reliable fashion, secure, harden, those sorts of things. And these container technologies and Project Atomic itself has actually been a place where our distributions, our cross communities, have collaborated. We've come together under the umbrella of this upstream project and we consume, we collectively consume their work in similar ways and we're sharing back-end tools to build and produce this content and we're collaborating with one another to try and solve problems in the same way. We're trying to solve problems together instead of, again, inventing a solution for that same problem. And I think a very interesting way to look at this is if you look at how distributions were built, how the content was created 10 years ago for each distribution, it was wildly different. The release engineering for Fedora, the release engineering for RHEL, and the release engineering for CentOS were extremely different processes, very, very different tool chains, very little shared code. And now in an upstream fashion, we are attempting, and we have so far, we've made a lot of work towards it and we're continuing to do that, find ways to share code bases where it makes sense or at least a common upstream and we provide plugins for the things that are specific to our scenarios, but we're doing that heavily in the Project Atomic space for the way that we're producing these images and similarly for containers. So container build tooling, this is actually something that we've worked across team on since very shortly after its inception. There is a container build system, it's a layered image build system, it's known as OSBS. OSBS stands for OpenShift Build Service, so it is OpenShift on the back end. But this had a very early inception inside of Red Hat in common Red Hat fashion, it was made upstream very shortly after it was to become upstream. The three communities we got together and we actually worked on that collectively to define requirements and work on improvements in terms of development to try and satisfy our different needs and use cases so we can reliably, in a very similar way, to produce. Okay, and then beyond that, so the container runtime technologies, again under the umbrella of Project Atomic, we are working together to try and deliver a consistent user experience using these different technologies because this continues to evolve, this space is constantly evolving, so those familiar with the OCI, we are trying to align cross-team and we have in the past, we'll continue to do that in the future for those kinds of things. And then distribution of content, so OS trees, OCI container images, we are right now in the planning phases of actually having a shared content registry for OCI images and we are working on similar tooling with one another to satisfy the requirement of having mirrored content for OS trees, for delivery and mechanism, those kinds of things, so the container ecosystem has made a lot of cross-collaboration happen and we are actively working towards even more of that in the future and that's something that has been very interesting as a journey and we're just kind of looking forward to it, but something to note is that with all of this container technology and all this ability to decouple our run times from our operating system, we need a way to have our application stacks be maintained cross-distribution in a way that can be collaborative as opposed to constantly having to maintain different software stacks for each one, which is where we kind of transition into the topic of software collections. I'm gonna hand off to Hansa to discuss that. Yeah, since we are almost out of time, I will be very, very quick, but so this episode is about you, developers. Right, yeah, so imagine you are a developer in a small company, you develop your awesome software in a startup way, you use all these new technologies, you use your federal, you are happy. Then your boss comes and says, okay, we need some enterprise level stability support and we need rel on our server, so now what? Fortunately, you remember that you heard about software collections last year on DevCon. So you know that the software collections allow you to use all these new versions of the new software on the enterprise level and on the enterprise system because it installs things into alternative path, which is really great. So what you can do is to use all this and have the same experience in the federal and enterprise Linux as well. But then your coworker who uses CentOS comes and says, okay, but I'm using CentOS and I like it, so what now? Okay, fortunately there is also a possibility to use these collections on CentOS because the SIG group, one of the special interest groups is focusing on building this RHSCL content on CentOS. But this group also works more as an upstream because we not only have already some collections available from the community, but we also expect that you guys will come and help us build new software collections that will be usable for others and also bring much more content. So in the end, we will have the same experience not only on federal, but also on CentOS. So yeah, the collaboration doesn't work only that way, like the software will come from Fedora to REL to CentOS, but now it already works from the Fedora to CentOS to REL. So are you wondering what is the last missing piece of the puzzle? Well, it was about you, so it's you developers, really. So since we know that you have containers, and that's also the reason why we need something nice in the containers, so we put these software collections into containers. We hide the fact that they are installed in the alternative path, and you are free and happy to use and have the same experience in all these distributions in the containerized way. And of course, you can use these technologies also in an open shift, which is what is really great. So at this point, I wanted to ask an issue of how many packages we already provide in the software collections. I wanted to print them on paper and I realized that it would be 80 pages of font 10 and 60 packages per page. So I saved like three trees, not doing it. This is just numbers. We have 45 hundreds of packages now available on top of what is an enterprise level, enterprise system. Sorry. If you want to know more, grab me on the hallway. We don't have a specific talk about software collections this year. There was something last year, so you can check YouTube or check the softwarecollections.org. And with that, I can hand over back to Denise. Thank you, Hansa. Okay, well, a shift. We are just about out of time, but I wanted to remind you that we collaborate with REL too, really. So, how many of you know that there is a free, oh, I'm sorry, a no-cost subscription available for REL? Yes, right? Developers with an s.redhat.com, get your free subscription. Don't be the last on your block. Collaboration in and for the future. It's here today and it's only gonna get better. So come back next year and we'll be able to tell you more about what we've done. Thank you very much for joining us.