 So, hi, this is what does Red Hat want at Fedora Nes 2021? I'm Brian Exelbeard. Let's start with a quick disclaimer. I work for Red Hat, and sometimes I talk on behalf of Red Hat, like I am doing right now, but I can't speak for every view that Red Hat has. Two examples. We give our employees a lot of freedom when they participate in open source projects. We actually have something we've published called the open source participation guidelines, and they basically say our employees can go into open source projects and do the things that are important to the project and that are important to them. They're not expected to necessarily carry a specific Red Hat goal or message with every action that they take. And a second example is that at Red Hat, we have a lot of different groups and teams. So, many of you know Marine Ord and the Fcake. She and I both work for Red Hat, but we're on very different teams. She works for the open source programs office, and they have a very broad mandate. Whereas I work for the REL BU and we have a much more focused mandate. So this talk, it doesn't include all of those groups and teams. Also, this talk is based on public information. Fancy titled people at Red Hat, they have a lot of plans. Sometimes they even tell me about their plans. But if those plans aren't public, I can't tell you, so they're not included. And so this is what does Red Hat want as seen from my perch in the REL BU. So the REL BU, what is it? Well, the BU and REL BU stands for business unit and the REL and REL BU stands for, shockingly, Red Hat Enterprise Linux. And what we do is we define what REL is and importantly what REL is not. And then we share this definition with our friends in engineering and they make our dreams a reality. We also develop materials to describe REL to customers and partners. We define how it's sold. We use something horrible called a SKU, which makes a lot of people cry and we won't talk about it. And frankly, none of what I'm saying right now is really new. What is new is that one of those fancy titled people that I mentioned, they had an idea and it resulted in a reorganization at Red Hat. And so something called the Platforms Business Group was formed. And Stephanie Cherish, who you used to know as the Vice President of REL, is now leading this platform business group. And the Platforms Business Group, it's like a supergroup of Red Hat. It's like all your favorite bands in one band. But in this case, we've brought together a bunch of products like OpenShift, OpenStack and REL and more of them. And we've moved them into a single structure. Now this may sound pretty boring and like corporate musical chairs. But if you follow the sport professionally, you can see how big this change was. Because to use an analogy, when two of our products wanted to work together in the past, they each had their own goals. And so getting them to work together was kind of like getting two countries to work together. You'd find some translators, you'd charter a steamship and you'd send your best negotiators over and see what you could get done. But now, because of this Platforms Business Group, we're all sitting at the same table. We're like a family. We're at dinner and we can just talk. And so we still have our own dreams and our own goals and our own aspirations. But we also have this unified set of goals and visions that we can work through. And so now when we want to work together, we just lean across the dinner table. Now, if we can't figure it out, we can always look to the head of the table and ask mom, that's Stephanie in this story, to settle our differences. But we also all know that asking mom to settle your differences, not a smart plan. So we're also super motivated to get everything worked out together. And this reorganization is another reason why it's tough to definitively say, what does Red Hat want? Because our sister BU's, they may have some new ideas that we haven't had a chance to discuss over the dinner table yet. Because this reorganization, it happened not too long ago. So, who is this guy? And what happened to his beard? And why is he not Mike McGrath? So that's me before I cut my beard. And the reason that I'm here and not Mike McGrath here dates back to late 2019. And as far as I know, no one gave this talk in 2020. So this is the next time it's happened. In late 2019, I moved out of the role of Fcake in the Fedora project and into a newly created role in the REL BU. And that role has a really confusing name. It's the community business owner. And it sounds like an anachronism, but I promise it's not. So to take this apart, a business owner is someone who thinks about a market segment or a group of people, and they figure out what the problems that those folks have are that they're experiencing. And then they decide if any of those are problems that Red Hat should try to solve. And it's important to note, we just should we even try to solve this, like the business owner isn't trying to come up with what the solution is, they're just trying to say should we invest in a solution for these folks. And we present that case to a council inside of the BU, and the ones that get a green light that are accepted, they're passed on to product managers, and those folks define the solution. But again, because this is thinking about what does Red Hat want from Fedora, that solution is still different from what you might think. Very rarely does a product manager go, the solution to this problem is to ship Python to create. That just doesn't really happen. It happens occasionally. It's not terribly interesting when it does, but it doesn't really happen. The solution that they define is usually things like, we know that our customers are hiring more and more X window system administrators. Those system administrators are used to graphical interfaces when they are managing this kind of a problem with an operating system. We should have a graphical way for this to be managed. And that's all we're going to include it in rel or whatever. Engineering takes that and figures out how to actually do this. They work with UX designers, but more importantly, they go to projects like Fedora and they propose changes. They will integrate new code. They'll submit PRs. They'll open conversation. And this is the Red Hat development model at work, our open source development model, which leads to a fantastic wrong answer. By the way, this slide is deliberately blank. A fantastic wrong answer for what does Red Hat want. And what Red Hat wants is not every single thing that a Red Hat employee proposes to a project. Some of what someone with a Red Hat dot com email address is proposing is just them noodling around or scratching their own itch. Remember those open source participation guidelines. Sometimes it's them saying, hey, this is something that would advance the project. So they're going to suggest that. And sometimes those are actually things that the rel BU wants. But we don't really know which ones are which because the exact features that we're going to ship in a future rel. Well, we don't announce those until we start our launch activities. So you can read those PRs and all those communications, but it's like reading tea leaves or lifelines. Good luck trying to define specifically what Red Hat wants from those. So we need to be somehow be more meta, more broad in our thinking about this. And so that brings back the community business owner role, because the community business and community business owner is about how rel and by extension red hat wants to work with our upstream operating system projects. This is where I focus. So, like those product managers, I'm not focused on specific software versions or specific bug zillas or anything like that. I do work on some of those things, mostly as a liaison between my fellow business owners or our product managers and others. But those are details that someone in the rel engineering organization or UX designer or someone like that is going to propose as a change. So my focus, my thinking is at the metal level, you know, what are the problems that rel upstreams and the ecosystem as a whole is facing, and then which of those problems should we try to solve. Now, this is an amazing graphic, by the way, if you want to use this graphic in your presentation, I know people and you can absolutely do that. This graphic is that ecosystem. This graphic is showing you how code is flowing through the various distributions that make up the rel ecosystem. And you can see, and I'm turning to look at the graphic that the upstream distribute that fedora and fedora Linux captures all of these upstream projects and integrates them into an operating system. And then we pull code from fedora Linux into sent off stream, and then that becomes rel. And so this shows you how all of these communities and all of these community projects here alive. And so I want to emphasize here that when I think about ecosystem and I think about the rel upstream and all of those things. I am thinking specifically about the fedora project and the sent us project and red hat. I'm not thinking about our rel partners, for example, our ISV is our hardware partners. They're just contributors like everybody listening to this talk. The other thing that I think is important with this graphic is you'll see how critical fedora is to the rel process. It's there in the line. In fact, its position has remained unchanged because of its importance to where it is and the success that it's had. I want to talk a bit about sent off stream for a while here, not because I'm at a fedora talk or because sent off stream is the most important thing that I'm done, but I want to talk about it because a lot of people are nervous about sent off stream. They see sent off stream here and they go wait a minute for door it just got pushed further away from rel. And that's not true for doors position and importance is unchanged. It's super critical. What sent off stream does is it build a gap that has always been there. So let's talk a little about why sent off stream exists. So sent off stream came about because we were trying to solve some problems related to fedora excuse me to rel minor releases. We designed sent off stream to solve very specific problems around influencing future rel minor releases and then helping people get ready for those minor releases. If you look at sent off stream, that's the red hat goal set there. That doesn't mean that's all sent off stream can do or even does, but it indicates where red hats interests are and what red hat wants it to do. So let's break that down and then connect that back to fedora. So the first thing we want to do is to provide a path to influence future rel minor releases. And there's some keywords here influence, meaning to provide suggestions or guidance. This means you talk we listen. We may not take your advice though. And rel minor release. This is the why and x dot why the five and eight dot five. And I know that sounds basic, but that's important because this is an area where fedora is traditionally not had a lot of impact and focus and where sent off stream is highly focused. Sent off stream is filling a gap here and sent off stream solves this overall problem by having a contribution system in place on top of the rel source. Now I'm speaking, you know, conceptually here I'm not talking about get branches and mirroring and build infrastructure and those things, but conceptually it's a contribution system on top of the rel source and contributions in this project. This project, they're reviewed like in any other open source project, just like in Fedora Linux, people comment on them, other contributors will comment on them, maintainers will weigh in. And ultimately, the code that is committed is decided on by a maintainer or group of maintainers. But a key difference as well here between sent off stream and for door Linux is that all of the committers and sent off stream are rel engineers. And this is because sent off stream is what we're going to get a grow out of it is what will become rel. And so the only path to maintainers ship and sent off stream is through a red hat work contract. This is very unlike Fedora Linux. The other big problem we were trying to solve was to create a place for people to get ready for the next real release. And there's a couple of things here again. It's the next real minor release and I won't repeat that again. But getting ready in this case is to prepare to do something. And specifically, it's to roll out rel underneath an app or workload. Again, very different from what Fedora does. And this is done by testing that app or workload against sent off stream. And in order for that to be successful, we have to have something that looks like rel. So all those commits have to be targeted for rel. And it has to be as bug free as software can be. So we have those two pieces coming in from the commit process where all of the maintainers are rel engineers. And then the CPE team who also works with Fedora produces a bunch of build artifacts so that people can actually test their app or workload on top of sent off stream. And that's enough about sent off stream. And let's connect that back to Fedora. So first, you can see that there are things here that Fedora doesn't do. And frankly, that Fedora should never do because that Fedora does what it does really well. So what does that mean? What does Red Hat want from Fedora? That's what you came to this talk for. The rel BU sees Fedora as a place to integrate new code and new ideas. It's a place where we can start a Fedora team to test a whole new theory in the operating system. It's where we see ELN living. That's what helps us get ready for the next major rel release. That's the X and X dot Y. It's also where Apple lives. Apple is extremely important to lots and lots of people. And we want to increase our support for it some way. So we're looking at that right now. How can we help Fedora with Apple? And we're looking very carefully at Apple as a part of that. Like what problems does it solve well? What problems is it simply the least worse solution for? But the key thing is I've just named like four or five things, but Fedora can be and is a lot more. Those specific actions may not be Red Hat goals. And that's okay. Because one of our goals is that it can be more than our goals. So keep doing those things. Have fun with that. I want to take this apart a little bit though, because it's kind of abstract and give you a real world example. Fedora workstation. So Fedora workstation is a desktop focused operating system that is designed to run on a large variety of hardware. Rel workstation is our product. And our product is designed to run on a very restricted set of hardware that does specialize things like high end animation. It's confusing because they basically have the same name, but they have very different goals and purposes. And so how does this intersect with what Red Hat wants from Fedora? Well, we are very interested in desktop technology. We use it in rel workstation. So we want to support that. That's things like Danone. We are also very interested in there being a Linux desktop for developers who want to use it. We want it to be in our ecosystem. That's the three projects that I mentioned. And we want it to be useful for people targeting Linux, especially rel. But we're not interested in telling you like Fedora workstation should do or be something specific. We think Fedora does a better job at that and doesn't need our advice there per se. Now, the desktop engineering team may have a ton of ideas in this space. Those may reflect the individual engineer, the group as a whole's view of technology, their view from say the GNOME upstream looking at Fedora, or even BU priorities. They're specific contributions against tea leaves. So the emphasis here is that we're interested in seeing that desktop exists. We're interested in seeing that technology function. And I'm interested in advancing the slide. There we go. So I would wrap it up by saying before Q&A, what does Red Hat want? We want Fedora to build a solid community of contributors. Fedora users, they tend to be contributors too. I am not excluding them. They often file solid BZs. They participate in forums. Matthew was citing some amazing statistics yesterday. So we want a solid community of contributors. We'd like you to keep doing cool things, even when they don't directly interest us, because we learn things from you that way. We would like you to continue to integrate code and be a positive influence on upstream projects. Every three years, help us create the new realm by being a solid upstream percentile stream. And when my colleagues at Red Hat show up with contributions and ideas, treat them like you would any community member. They may be acting on a BU priority, or they may just be doing something for themselves. It doesn't matter. Measure their contributions on their own merits and how it can help Fedora solve Fedora's problems for Fedora's users and contributors. I mean, obviously at Red Hat, we think a lot about enterprises and partners and various kinds of vendors. Those things aren't necessarily bad for home labs or laptops or any other Fedora use case that may exist. So help us work together on the merits of the contribution. There is a lot of room here, a whole lot of room. There's room to do great things with the open source program office and other groups at Red Hat. There's room to convince me to prioritize problems that Fedora is facing as things that Red Hat should try to solve. So let's all work together and have fun and I will try and switch over to the Q&A tab. Q&A. There are no questions. It was amazing. Everybody loved it. I think the people from Boston University have figured it out. I see no questions. I am amazed. Oh wait, there's a question. Are there other secret things Red Hat wants that you aren't telling us? That is an interesting question because I said that this talk was based on public information. My answer would be this. There are always going to be further business plans that Red Hat is making. The way that most of those will impact Fedora is going to come in the form of starting as a problem we want to solve, moving into the definition of solution, and then ultimately a UX person or an engineer somewhere going, we need version X or this kind of code or this feature. So yes, those things technically might exist, but I wouldn't sweat those details because that's just another contributor showing up to make Fedora Linux better. So I would absolutely not be worried about super secret stuff. And since Matthew asked the IBM question, IBM has expressed no opinions and does not as far as I know want anything. Red Hat operates very independently of thought from what IBM wants. And in fact, if you look at some of our recent announcements that I've worked on, you've angered them too. If a community member has input on the business problems that Fedora should solve or not solve, how should they bring those up? So I'm going to take the question in two directions. If somebody wants to change the problems that Fedora itself is solving, take those to the council or the appropriate Fedora team to work on. If somebody believes that there is a challenge that Fedora could help Red Hat solve or that there's a problem that Red Hat should help Fedora solve, you can bring that to me because I'm a great entrance point into the various groups at Red Hat that would be able to be motivated around that. The exception to that would be like if you go, hey, Koji bug number, blah, blah, blah, blah, blah. Like take that straight to an engineering team that works on build infrastructure because I'm not at the level of like we should fix this cynical and make it a comma. Does Red Hat want Red Hat family mind share to grow via Fedora? Absolutely. Yes, please. The rel ecosystem, if you will, all of the RPM distributions, the Fedora project, the centos project and the work that we do with product at Red Hat are all one thing from a mind share perspective. So yes, we absolutely want to see Fedora grow because it also helps us grow. What do you think of the Fedora ELN project? Personally, I think it's awesome. I haven't looked at it in great detail. From a Red Hat perspective, ELN is an important way for us to start thinking about future minor releases. One thing to keep in mind about it though is that ELN, because it's thinking about the next major release, not minor releases, because ELN is thinking about major releases, it's further away. And so it occasionally will look like it's not getting the importance or attention that it needs. And that's literally because we are trying to ship software today and sometimes ELN is thinking through years from today. So it is important, but its ability to get attention at great detail is going to wax and wane throughout the life cycle. I don't understand the major minor thing. How does the workstation OS move from Fedora to rel and back to centos in a major minor cycle? Okay, a couple of things in this question that I want to take apart. Code, let's see if I can switch back to this graphic because it will help us. Code flows from upstream projects into Fedora Linux into centos stream and then into rel. Things don't ever swim upstream. I believe that your reference of back to centos is back to centos Linux. Centos Linux isn't in this picture because it's not in the rel development model. It's not in the chain of things that become rel. And I brought up Fedora workstation because Fedora workstation and rel workstation sound like they should be upstream downstream of each other, but they're not really. Because Fedora workstation has a very broad mandate of things that it's trying to do, whereas rel workstation is highly focused. They share a lot of the same technical parts, but they're not actually upstream downstream from an outputs perspective. Is the BU willing to help Fedora invest more in non-engineering areas to help bell that mind share in the unpaid Linux market? Yes, there is some ability to do that and we are already working on it. Right now it's coming in the form of things like this graphic, which will be part of other campaigns that can be run by everybody. But we are looking at other ways to try and marshal non-engineering support for our projects. A lot of that is going to come down to understanding what the return on investment is, if you will. It's not like we will go and do this thing and you will get this many dollars. It's much as understanding, like if we put marketing support in, what is going to be marketed? How does Fedora know it was a success? What is your goal in your targets? And then aligning those with Red Hat's interests. And to be very clear, the BU's investment opportunities are based on its narrow focus around REL, whereas other groups, for example, the open source program office, which provides a lot of the program funding for Fedora now, is a much broader mandate set. So there's lots of pools of money and talent that you can tap at Red Hat. What does Red Hat think about Fedora Linux being nominated as a UN digital public good? That is an interesting question that I am unprepared to answer today. I know that there is a group within Red Hat that has been talking to Matthew. I believe I connected them successfully. And if I am not, I am sure that I will get an email from Matthew right after this. That would be the group that would respond to that. And that would be our public affairs legal folks, not the REL BU. Personally, I think it's awesome. And I am super, super happy. And I want Fedora to be a UN digital public good. But I look to my betters to determine if there's a gotcha in there that we need to know about. I was given 30 minutes and there's four left. You should take advantage of it. See lots of conversations around Centaur Stream. Centaur Stream is fascinating. I hope everybody has given it a whirl. If for no other reason, I would encourage Fedorans to give it a boot so you can see how much influence you've had over the next release of REL. And then you might find it interesting to keep booting it periodically just to see how far Fedora Lennox and Centaur Stream do diverge. Well, the schedule that I got said I had a half hour, Mr. Cotton. So I'm, I caught my presentation to fit this time, but I am super happy to continue Q&A. I thought you said Fedora Influences were all major, whereas Centaur Stream Influences minor. I did. So every three years we branch effectively branch Fedora Lennox into something that will become the next REL major release. We do that by starting a new code base in the Centaur project for Centaur Stream. So like we're working now on something called Centaur Stream 9 that will be the REL 9 major release. At that point, the REL code base or the Centaur Stream code base and the Fedora Lennox code base start to diverge. In the first couple of years, especially because of the six month release cycle in Fedora, the divergence isn't huge. But over the course of the 10 year lifecycle of REL, that divergence becomes amazingly large. And so what Centaur Stream does is it tracks ahead of those REL minor releases and it is the contribution point for that code base as the divergence gets bigger. It is not a way to get things in around upstreams. It is not a way to even get things in around Fedora. Everything needs to be contributed as far upstream as possible. But one thing that will happen, for example, during the REL lifecycle is that the version of the software that is shipping in REL has been back ported with fixes and new features and other things. But the actual upstream to that code, they're not interested in those back ports and those fixes. They have already deprecated that release. So we continue to make that really stronger and better as part of REL, but there is no upstream further to contribute to. Or a bug that we find doesn't actually affect Fedora Lennox because it has moved on to another version. And so that's why there's the two different points. Fedora influencing the majors and Centaur Stream influencing the minors. What if anything does Red Hat want from Fedora that we're not doing right now? I saw almost all of Matthew's remarks yesterday, so I don't want to mischaracterize them. But I also remember from my time at Fcake, the contributor stats have typically been somewhat flat in Fedora. They've not been hockey sticking up, for example. And so I would say the biggest thing that we would like from Fedora that we're not really getting a lot of right now is growing a stronger larger community and more mind share. And I know that some of that is because of challenges Fedora has had just being a project and, you know, all of the things that come with that in a world where the operating system is of interest, but not necessarily the hottest thing on the planet. I also know that some of that is, you know, occasionally Fedora has said, hey, can we do acts and Red Hat has either not answered or mumbled or failed to show up with good resourcing. And so one of the things that I've been trying to work on is like, if we're going to say no, say no so that everybody can move on to plan B. And if we're going to say yes, show up and do what we said we were going to do. And I know that there are some sticking point issues out there and we continue to work through them. But that would I say the biggest thing that Red Hat wants from Fedora that we're not seeing today is that mind share and growing community. Is Red Hat willing to leverage its relationships to help further the reach of Fedora and mind share and market share in areas that are generally considered out of scope for rel. Yes, with an asterisk, which is we need to look into exactly where you're talking about a lot of red hats relationships that it would want to leverage are in areas that are in scope for rel. And there is not to displace rel product to be very candid about it, but absolutely if there are areas that we can look at trying to expand Fedora's access or knowledge or just connecting the right people we're certainly very happy to do that. What does Red Hat do when Fedora does something Red Hat doesn't want the pizzas we didn't order problem. Typically we pizza and we try and pick the pineapple off. You know, candidly one of the challenges that you could argue exists in the Fedora model of development, which by the way internally we call this whole model the Fedora model that's how important Fedora is. And that is that you occasionally get a pizza you didn't want. There are a lot of ways to solve this problem and the easiest would be to show up in Fedora and go hi, we're from red hat and we are telling you you're not allowed to do that. That would be a terrible solution and we don't want to do that. We understand that occasionally we're going to get things we didn't ask for or not get things we wanted and we work around it, and we try to continue to get those things in where we can. And sometimes we don't get what we want because what we wanted turned out to be a great idea and a bad implementation and we're able to work together and figure that out. And sometimes we don't get what we want because we don't know why you did that and we'd really like to understand and it's confusing and hard. But in general, we just work around it and we pick the pineapple off the pizza and suggest that maybe there should be laws against pineapple on pizza. So you are wrong. And to be very clear for those on the recording I was telling Neil he is wrong that pineapple on pizza is amazing. There is a graphic naked jet of me. I was doing this symbol and Moises added laser beam shooting out of my eyes from one of the dev comps that I had the privilege to help with. Nick has created a poll about pineapples on pizza. Answering it. Yes, would be something red hat does not want. I'm going to check. No. Let's see here. What about the progress of cooperation with NVIDIA. The other day I reported a serious bug to Justin Forbes regarding kernel boot issues with the 470 drivers. I'm going to have to put aside the second half of the question, Christian, mostly because I know who Justin is. I know what a kernel is. I don't know what the 470 drivers are. But I will talk about cooperation with NVIDIA. NVIDIA has, as I understand it, a very interesting model when it comes to working with open source and providing their drivers. Fedora, as you know, is very challenged with NVIDIA drivers because you can't recompile them so DKMS and other things can have problems. We continue to suggest to NVIDIA other ways that they could do their business and they continue to tell us that it's none of our business. So we will continue to work with them as much as we can. And this may be one of those areas that over time we can all have greater influence as one of the earlier questions came in about leveraging relationships. Right now, the Balsen NVIDIA's court. And I'm sure that there are people who could talk much more authoritatively about the technical challenges involved than I can. I have a feeling that after this, I'm going to get a call from Paul Cormier asking me about a very large pizza order. Does Red Hat want butter FS? That is a difficult question to answer in a direct sense because it is a specific technology. My understanding is it is not currently slated to ship and rel. And so it would be easy for me to say no. I would simply say this though, much more broadly. Fedora playing with butter FS is a useful exercise and I encourage Fedora to decide if Fedora wants butter FS and to use it. As far as what a red hat will ever ship it, that's a product decision and we'll make that when it's appropriate based on the problems that we solve for people in various markets. Is there communication between Red Hat and Fedora when Red Hat is about to drop support for a particular product? I think I remember seeing something about Red Hat dropping Rev over in 2026. I would want to put this question directly to Matthew because a lot of that drop of support would typically come from the non-rel be used and from the real be used. And I don't know whether he gets any advance notice on that. But again, this is one of those situations where a Red Hat business decision to change the life cycle of a particular product is something that we would announce publicly all at once. And we would not typically give a lot of privileged advanced access to that. And it has nothing to do with whether it's Fedora or not. It's just that's how you manage a business in a proper sense. One of the things that people came to me about in like 2019 that they were concerned about, in which I don't have a good answer for yet, but which is a problem I continue to think about is occasionally Red Hat will no longer wish to support a particular technology. And Fedora has that technology embedded in Fedora Linux. And so what do we do about that? How do we help Fedora Linux become either fully community supported where maybe, let me rephrase that, get more community support. Where maybe a Red Hat engineer who had been acting in the community is stepping back. Or how do we work with Fedora Linux to deprecate that technology out of their stack? And I don't know the answer to that problem yet. I don't have a solution. But it's something I continue to think about whether Red Hat needs to be part of that solution. Or Fedora Linux through the Fedora project can actually solve its own problems with its own community. Why does so many distros like Ubuntu support NVIDIA but rel and Fedora do not support some NVIDIA cards? Again, this feels like a very technical question about the way NVIDIA does its drivers. And I don't want to speak out of school on Ubuntu, so you would need to ask someone at Canonical or in the Ubuntu community about how they are able to provide greater support. I do know that we are committed to supporting things that are open source where it's appropriate. At least I believe that is the current pitch of the Fedora project. Does Red Hat want butter on pizza? Yes. If especially if the other option is pineapple. Now that Fedora uses ButterFS by default, what does Red Hat think about ButterFS? So it's the same answer that I gave before. It is an interesting technology. We will continue to keep an eye on it. And if we choose to ship it in one of our products, there will be an appropriate product announcement about it. Now I'm thinking about butter on pizza. Can said butter on pizza have garlic in it because then it would essentially be garlic sauce. What does Red Hat want from Apple? Well, Mr. McGrath. What Red Hat wants from Apple I think can be summed up as following. One, we would like Apple to be an amazing source of software that you can't get from other places for the enterprise Linux systems. Two, we'd like Apple to be ready. It would be awesome if Apple was ready whenever we shipped a new release. Now there's a lot wrapped up in that and a lot that's hard in that and a lot that we may not want to make a reality. I'm speaking very conceptually. But we know that Apple is extremely important to consumers with enterprise Linux. Whether they are consuming CentOS Stream or they are consuming REL or they are consuming any of the other enterprise Linux that exist. And we would like to see Apple be able to be there to support those folks. And Fedora powers Apple. A lot of the software actually according to the Apple contribution guidelines I believe every piece of software in Apple must also be in Fedora. So Fedora's growth as a software platform directly impacts everything that comes after it. And I believe Mr. Abu Dhabu may even be in this conversation or in this talk right now I haven't looked at the people list but he is from all millennics and I think that all millennics should have an opinion on Apple as well. Will Red Hat ever have something similar to silver blue in the REL space? Maybe keep an eye on our product announcements. Maybe not. But that's not public information right now Paul. Did the relationship between Red Hat and Fedora change since IBM bought Red Hat? No, the relationship between Fedora and Red Hat has not changed as a result of Red Hat's acquisition by IBM. In fact speaking candidly and personally I would say that most Red Hat employees would find it difficult to point in much that did change after that acquisition. Do you think the new arrangement with Stream might help with the traditional delay in the release of Apple and Timeliness, especially with new major releases? I certainly hope so. I know that there have been a couple of papers moving around that I've had the privilege of seeing where people are posing different kinds of solutions for both how Apple should be prepared when thinking about something like REL 9. But also how do you deal with Apple when you've also got CentOS Stream that needs to consume it and Stream may have a difference from REL at points in time before they reconverge it minor releases. I know there's a lot of really creative ideas here and I would actually encourage you to talk to folks like Troy Dawson. This is definitely silly but regardless, does Red Hat at any time think about discussing ZFS state with Oracle? I would like to know the price tag on relicensing from Oracle. I am not aware of any discussions that have resulted in a price tag that would let alone anything else that is public that I could share. But I would say that ZFS much like ButterFS is something that we keep an eye on and if we choose to make an agreement that results in it being in product, we'll know. That way we've got something different to look at right now. And my magical bonus half hour. For those of you joining late, I was told my talk went 30 minutes and then Ben told me it went 60. Yes, Matthew, you are correct and I apologize in advance to the design team for doing horrible things to their graphics. Red Hat would like a lot of people to please go vote no on the poll. Thank you. Well, the question seemed to have slowed down. I still discourage the use of pineapple on pizzas. And thank you all very much. I hope everyone will take this bonus 15 minutes and go play around in the Fedora Museum or otherwise interact with folks. I'm happy to talk to people offline. Unfortunately, I won't be able to be at nest tomorrow. I have some personal issues that have come up, but my email is always open. And as Neil Gamper will tell you it's relatively easy to schedule a call. So thank you very much.