 All right, I think it's about that time, friends. So let's see about getting started. Hey, guys. Hey. Friends, are we ready to start? All right. All right. Thank you for coming to this talk. The title of this talk is befriending the elephant in the room. Just to clarify, for those who may not have heard this term before, the phrase elephant in the room refers to something that everyone is aware that is there, but nobody actually wants to talk about. So I'll explain this metaphor a little bit as we go on, but here's what we're going to cover today. We're going to be talking about the kernel and the way things are today. What exactly we want to see and change for the kernel, and then what changes we actually plan on making to make this all happen. Okay. So first, a little bit about us. My name is Laura Abbott. I'm one of the Fedora kernel maintainers. My full-time job is to deliver kernel releases for Fedora and fixed bugs and everything related to that. And Steph, do you want to introduce yourself? And I'm Steph. I've worked on many, many open source projects integrating them. I've worked on Cockpit, it's one of the folks who created Cockpit. And more recently, I've been working on CI, automation in Fedora, and in REL as well. And we both work for Red Hat, and we're both Fedora users and contributors, and yeah, we like Fedora a lot, so, okay. As a kernel maintainer, I spend a lot of time talking about the upstream kernel release process to various people. And I always like to start with this one, talking about kernel releases, just because a lot of how the upstream kernel works tends to drive how distributions work. So there's a new kernel release, major version bump, about every three months. You can see there's an address up there that will show you the schedule. It happens fairly regularly. For context, where we are right now, we just had RCA come out on last Sunday, and if everything goes well, we should get a 4.18 final this coming Sunday. And three months is actually pretty fast as far as things goes if you look at the velocity of how many things are coming in. This includes everything, new features, and which everyone always likes, but also some bugs, which people like less than you might expect. So for Fedora, what Fedora chooses to do for its kernel releases is to roughly track the latest stable release. So what this means is that Fedora 28, Fedora 27 are currently on the 4.17 stream and are picking up stable updates, which means just bug fixes. So that's what's coming in, which means that technically the set of features that are in for Fedora 28, Fedora 27 are fixed versus raw hide, which is on the RC release. And for the most part, this works pretty well. Let's people get the newer features they want for stable releases and generally keep things going. And part of our philosophy with Fedora is to really have a breadth of focus. We tend to focus on enabling as many drivers as possible and really giving the community a chance to tell us what they want. Generally if someone files a bugzilla and says, hey, can you turn this kernel feature on and it seems like it's reasonable, we'll turn it on. And assuming nothing breaks, that's how it happens. And we will also aggressively pick up bug fixes and patches that people find. And again, this is because people are finding problems. It's pretty easy for us as Fedora kernel maintainers to want to bring stuff in. And this is kind of our philosophy is that we want to try and stay as close as possible and use our freedom that we have as kernel maintainers to try and make the Fedora kernel as best as we can. And this is kind of in contrast to how the Red Hat Enterprise Linux kernel works. The way that kernel works is that they tend to pick a single kernel base and stay on that for the entire life cycle. So the current kernel base they have is 3.10, which is normally very old. But they make this work by taking a lot of very experienced kernel engineers and having them do all kinds of back ports. They will back ports bug fixes and features. So what you end up getting is you get possibly some set of features and bug fixes, but with a known level of stability. So there's a lot of validation. And part of this validation also includes a very long process to actually get anything in. So this means if you actually want to get a new feature into REL, you have to go through a lot of internal approval, blah, blah, blah, blah. And comparing the two, REL is obviously not Fedora, but that's okay. I'm not up here to make a value judgment about whether you should be using REL versus Fedora for kernel philosophy is just because they're targeting two very different things. And there are good reasons you might want to use one versus the other slow versus fast as you've kind of heard about other parts of the other people talk about. Okay, so like I said, this talk was called the elephant in the room. So as Josh already alluded to, Fedora is supposed to be the upstream of REL, but the elephant in the room is that this really isn't the case, is that the two have basically diverged completely. And as a result, testing and work that happens on Fedora does not have a direct impact on REL. What ends up happening is that REL developers put their work into the upstream kernel, which Fedora picks up indirectly. But again, there's no direct connection. And that's what we want to fix. I'll pass something up to Steph. Okay, well. So we're talking about an elephant in the room. So we need to say hi, we need to address it. We need to be explicit about previously what may have been implicit or assumed. Let's do that. So we've written up what we think REL and Red Hat want from an upstream in Fedora for the kernel. But keep in mind that most of the upstream development, by and large, almost 100% goes all the way to the Linux kernel development, the various mailing lists involved in it, the various maintainers there, and so on. So what we don't want is a place to do actual hacking on the code of the kernel. That's typically not something that happens in Fedora. So here's what we do want. Let's look at this together. We want a future REL kernel and its config to see validation via production usage of Fedora long before REL development and testing on that kernel begins. You all see this already for your laptops. This is very common, right? You'll see features coming into the upstream kernel and landing on your laptop, something not working quite right. It's awkward for us. But this really is something that's worthwhile for Red Hat. The various drivers, graphics drivers, and so on see validation from all of us. We want to expand that so that more broadly, that example will more broadly apply to server cases, to cluster cases, to many more places that production usage applies to. And secondly, we want a kernel developer, a Red Hat kernel developer or other developer or hardware partner, software vendor, or a Red Hat product team. Those products that were listed in the last talk, to be able to debug, test, and evaluate new features in the Fedora kernel with the confidence that their effort builds towards the next REL kernel. Currently that confidence doesn't exist. And that's why you see people evaluating CentOS or using CentOS or having nowhere to go, trying to find a place to do such testing and development. So, when Red Hat started working with Fedora, this is one of the reasons that the investment happened. Was we want, Red Hat wanted feature incubation and innovation to have a place to happen. Let's look at both of those things. So incubation is taking features that have been developed elsewhere, bringing them together, distributing them, and seeing if they stick. So a good example of this is new drivers that land in the upstream kernel. And like Laura said, Fedora kernel will enable as many of them as possible. So we can see if they're worthwhile, if they're stable, if they work. But there's many other places like this outside of the kernel. And you can think of all sorts of examples of things here. And then of course, a place to integrate all the different components together. Different pieces of the kernel require user line components. And there's various APIs exposed and so on, making sure that those work together. Getting some sense of whether something is stable and worth shipping in rel. Let's say a new firewall, a new way of the C group stuff is a good example, a new way of partitioning up a system. Innovation is about stuff that's actually developed in Fedora. So the way an operating system is put together. The way you boot the operating system. The whole grub to in at RD to the Linux kernel and all of that, those angles. These are places where we can actually do some work in Fedora itself, rather than just vetting features that are done elsewhere. We need to be very able, all of us, to try out new ideas. But also to fail at them, to say, hey, we tried that out, it was a bad idea. Let's replace it with something else. And instead of treating that as a failure, treat that as something that we want in Fedora, so those failures are literally one of the cool things about Fedora. The ability to back something out and change it a couple of versions later. And in rel, we can't do that. This is a place where we're handcuffed to something for ten years or more, right? So Fedora is the place where we want to be able to do that. And it's really cool that we have a place to do this. So here's some examples, and we'll talk more about these in depth later, but this is to get you thinking, right? So if the rel kernel and Fedora kernel have completely different config options set, especially for the core functionality, not necessarily drivers, but for the core aspects of the kernel, then it's not a useful place for kernel developers, hardware partners, software vendors, and users to evaluate the latest released kernel features. Do for patch sets, if they have completely different patch sets applied, or one is not a subset of the other. If the Fedora patch sets are not a subset of the kind of patches that are carried in rel, the same situation. But if we have consistent or plausibly consistent config options, packaging, patch sets, and so on, then we do start to achieve those goals that we had that you saw earlier. So Red Hat really wants to be a significant participant in the Fedora kernel. Be able to show, hey, here's the ways we want to use this. Here's how we can get other, more people involved. Here's how we can get hardware partners involved in the Fedora kernel, or different software vendors, or expand the community along those access. We've been focused on community participation in a certain way, but this is a way to even bring more people in and be a significant participant here. Okay, so we talked about how rel wants to be a participant in the Fedora kernel, but sometimes when people hear this, they think that means that Red Hat wants to come in and take over the Fedora project and dictate stuff. And this is not really true. And I want to talk a little bit about the upstream kernel again, just because if you've ever read a report from LWN or the Linux Foundation, you'll see that the fact of the matter is that the majority of contributors to the upstream Linux kernel project are people who are working for companies. So companies have put a lot of money behind engineers to actually get what they want. And I'm pointing this out just because the kernel project itself is still a community project, even though you have people who are working for engineers because ultimately the community trusts the individual engineers. What you'll find is that people in the kernel community may switch jobs, jump from company to company, and that trust goes with them. And this works because the engineers know that other members of the kernel community are not going to take their patches or want to work with them if they're pushing crap. So if you start trying to push, say, I need to get this in because my boss told me to, that's not going to fly and you're going to lose that trust. So I point this out to say that it's ultimately going to be in Red Hat's best interest when they want to work with the Fedora community to do the same thing, is that Red Hat needs to ultimately push things that are good for the community if it wants to actually be successful, otherwise nobody's actually going to want to do anything. So yeah. And again, what we really want to see is that Red Hat making and proposing changes as part of the Fedora community. I'd absolutely love to see more rail kernel engineers participating on the mailing list making changes on Bugzilla. This happens on an infrequent basis. I think I just saw a request from someone on Bugzilla just before I went to give this talk. So it does happen, but we'd like to see it be a bit more of a formal process, it'd be even more involved, and also continuing to give us some feedback on how things work. So again, it's really being part of the community. Okay, so we've talked about changes and maybe at an abstract level, but there are some specific things we are looking to do, at least as a first pass, to try and actually hopefully make Fedora a little bit more usable to rail. A big one is kernel configuration. So as Steph alluded to, there's the fact that the Fedora kernel and rail kernels use different kernel configurations means that people have a hard time saying that testing on Fedora will make any sense. And so what we're looking to do is to hopefully align the core configuration options. By core options, I mean things that are fundamentally part of the system as opposed to drivers. Rail is never going to care about some drivers like, say, all the infinite number of ARM64 modules or LED drivers out there. But to make sure core things that affect things like, say, the scheduler or power management are aligned, that can help people give confidence to know that if they're testing on Fedora, it's probably going to give similar results as if it were testing on rail. Another one is packaging. So this is one that people don't always think about in terms of actually being part of it. But it turns out that some of the features we do actually deliver for the kernel have a lot to do with packaging. A good example is secure boot. Currently the secure boot signing happens as specified in the spec file. So if that's specified incorrectly or different between Fedora and rail, that's another area of difference where you can't actually validate that. Yet another example is third-party modules, again, that requires changes to the develop, and that all happens in the spec. So again, it's just more places that things can differ. So carried patches is another one that's interesting. While I mentioned that Fedora tries to take the upstream kernel, we do end up carrying some subset of patches that are not yet applied to the upstream kernel. We try and keep this number as small as possible, but what we end up having is either very small fix-up patches that have been there forever or sometimes longer-lived features. A good example for this here is secure boot. Secure boot is a feature we've been working for a very long time to try and get accepted upstream. It's making slow progress. But as a result, both Fedora and rail have to carry some sort of patch to be able to support the secure boot feature. And again, if you're not carrying the same patch, the fact that you validate a secure boot on Fedora means you don't actually know if you'll validate things on rail. And again, the two will never actually be able to carry the same set of patches, but the focus is to be able to make the diff measurable and small enough that we'll be able to give people more confidence to know exactly what they're testing. And really, ultimately, the goal is to make both Fedora and rail better. And I do think that by trying to get rail more involved, it will provide a positive benefit for Fedora. One thing, at least, I'd like to see is to try and get more rail developers interested in Fedora directly. So currently, the flow ends up being right now is that someone reports a bug to the Fedora kernel maintainers and one of us takes a look and usually it ends up we go and look upstream, see if someone's reported. If not, we end up having to go try and report the bug upstream. And this is sometimes kind of a slow process. And instead, what we're hoping is that if more rail developers are testing, they will hopefully find the bug themselves, report it, and then just tell us to say, hey, pick up this patch because when people tell us to pick up patches because fix the bug, that makes our life a lot easier. It's much smoother. And there are only three full-time Fedora kernel developers. So getting more people to be able to look at bugs and do that again just make our lives a little bit easier. We're also looking to get broader validation. So Justin has done a fantastic job with the existing kernel tests. He gets a lot of credit from me and everyone for being able to support that. He hits a certain kind of testing. But there's other more focused testing that the rail side is interested in. So again, the goal is to find a different set of bugs that might affect people and get those validated from the rail side that we might have not been able to catch. So hopefully everyone else then has fewer bugs. So I want to talk about what I think is a good example of something we might try and fix, atomic. So it seems like every couple of months I get a message from Dusty saying, hey, atomic is broken and we think it's caused by something in the kernel. And usually when he does this, he's correct. And it's because there's something pretty fundamentally broken in somewhere in the stack that's broken containers. We've had container networking break broken somewhere times virtualization. The point is that these are pretty core issues. And then what ends up happening is, again, we have to go through a cycle of trying to report to upstream, get them to actually notice the bug, sometimes eventually get them to fix the bug, then backport. And this is a pretty long process. And it ultimately means that the atomic project is now having to deal with this entire bug while this debugging disaster is going on. And it's really hard to make this go faster the way things are now. So part of the goal here would be is that if rel developers are actively more interested in using this, they would find the bug sooner to hopefully be able to identify and even fix either themselves or reporting to upstream to get the bug faster. And they also have a motivation because we talk about atomic as being a Fedora project, but again, Red Hat is also interested in it long term as well. So the rel developers have an incentive to try and fix things now because they know they will eventually have to deal with it later. All right, so this is a summary about hopefully you got what we talked about. Today, the rel and Fedora kernels have very different bases, and this means that the two don't really get a lot of tests. Fedora doesn't really get a lot of testing from the rel side of things, and it kind of exists as its separate entity. And what we want to see is that rel is a place to incubate the latest features. And what we really want to see is that even more Fedora developers and contributors are available and using. And I think at least for our first steps, what we're looking to do is try and sync up on kernel configs, packaging and carried patches, and hopefully get more rel developers participating. Okay, so we've spent a lot of time talking about what we want to see, but we do also want your feedback here about things you want to see. Is that if more rel developers were to be involved, what kind of things community would want to see? So this is more than a question and answer, this is a discussion. Okay, so the things that were raised, how do we implement those? Are there any gaps? Are there things that you think are missing here that we need to do? And I would encourage, this is a discussion. If you have more than a question, you want to participate, come up, we can talk into the mic, we'll work this out together like this. I will talk into the mic. Good stuff. Yeah, then we'll repeat the question. Instead of like cutting your own patches, instead of like recording your question or 14, let's say, just keeping on for 14, 1, 2, 3, 4, 5, 4, 5. The question was about the Linux stable branch. So that's a good question and something we've thought about before. The real problem is that when the long-term Linux stable branches are released, does it not actually correspond well to a Fedora release cycle? So trying to sync those two up hasn't really worked in the past, so we've discovered it just turns out to be easier to go on to the latest version. But that's something we've considered in the past, and I think if they were more well-aligned, yeah. We've used it before, particularly like older releases right now. So I just did more now. Justin, I think you're not being recorded. Why don't you come up and be part of this? For those who don't know, this is Justin Forbes. He's one of the other kernel maintainers. So the long-term releases have been used before, and we have an issue now, like I just did the 4.17.12 kernel a little while ago, Friday, I think. And it's got 18 karma on Fedora 28, because people are testing and saying, yes, it's great. It's got two karma on Fedora 27. So what happens is it gets very difficult to push, and it gets very difficult to push rebases, particularly as you get close to the end of a lifecycle on a product. And there have been times where we've said, all right, well, since it's currently on a long-term stable, we're just going to leave it there, because there's not a point in pushing a rebase when there's three months left and nobody seems to care. There's two problems that we've run into with that, and that is sometimes we need to respond to things quicker than they go into the long-term stable upstream. So we ended up having to do backboarding, and that's more work. And the other one is people do seem to actually want features going forward. So from a Fedora 28 standpoint, people would be fairly annoyed if we're not releasing new kernels and not rebasing as they come across. From a 27 standpoint, those are the people that don't care, right? They're happy that they're running something that's working, and they don't necessarily care about the rebase. But then you've got two different kernels you're maintaining. Right. And to the elephant in the room, we need to walk a tightrope between keeping Fedora stable enough for usage, and also evaluating the new features as they come out, so that people can debug, test against them, fix them, can work on them. So that's an interesting balance. And in many cases, it feels like the stable branches are too stable, too slow for that second part. Very much so. We do use the stable, the current stable, so we're like right now, except we just did 4-17-12. We're going to skip 13 because 14 is going to be up tomorrow. Then the second question? The second question was like, you were speaking about configurations and packages before. Is it like single configuration, single package? What are the cases like server, test, and other stuff? Yes. Is it like different packages? Yes. The question is that what's the policy about kernels? Do you have multiple kernels for multiple targets, say kernel server, kernel cloud? The short answer is that right now we have a one kernel policy for Fedora, mostly because, again, there's only three of us, and it takes a lot of work to maintain multiple ones. And REL has a single kernel policy, although they may do some other stuff, but I'm not able to speak about that in detail. But as far as Fedora goes, we've sometimes thrown out the idea about having multiple kernels, but it's never really gone anywhere. On the other hand, there are things like App Stream, or Stream Branches now, which is, you know, a generic Fedora feature. So we haven't really looked at that from the kernel side, whether using something like that might make sense. I would say it's become more plausible as time has gone on for us to consider doing multiple kernels, but at this point in time we have a single kernel policy. One other thing to consider with the configs and the options, and one thing that I would like to see come out of this integration is, as Laura said, there's three of us right now in the Fedora kernel team. At times there have been only two of us, and we're basically generalists. So when a new kernel comes out and you go through the merge window, you have dozens of new config options, and we look at them and we make a best guess. I mean, we've got some experience doing this, so we can usually pick the option that is good or safe, but REL has several kernel engines, orders of magnitude kernel engineers more than we have, and it has specialists in every single area of the kernel. So we might make a best guess effort, and we push that out there in Rawhide, but if we get feedback from the REL developers saying, hey, actually, if you change this config option to this, it's better for this reason Fedora benefits hugely from that. Any other thoughts or questions? The question is, do we have a kernel SIG in Fedora? No, we don't. I would probably say that if you're interested in being more involved, you're welcome to post on the mailing list or talk to one of us. I think SIGs tend to be more for items that are across the entire distribution as opposed to a single package like the kernel. But we always welcome more involvement. We've tried to do our best to do this. Not really, no. So the suggestion was to have meetings. That's a great suggestion, and we'll certainly think about that. It would be awesome if it worked out, but we tried that, and it ended up being a lot of meaning prep. I always think that the SIG is a way to sort of organize effort. Okay, I'm just going to cut you off a little bit, Paul. So we're having a lot of discussion that's not being recorded, and this is all very good, and I'm actually going to propose this is something that's probably better off to handle afterwards and off-camera. Are there any further questions? I'd just like to just double down on that. Part of the intent here is to get more people involved in the Fedora kernel and set things up for that. So yeah, I agree that it didn't work out before, but we should imagine that it's going to be different going forward. Yes, absolutely. And I would say certainly is that it seemed like there were a lot of... If there were a reason to start forming a SIG or having regular kernel meetings, I would absolutely be off for it. I would be thrilled to discuss kernel development once or twice a week or a month, or however often people want. Yes? Right. So the question was about maybe concerns about dropping partially supported drivers because Red Hat wasn't interested them. And yes, I agree that it's absolutely a concern and that was part of the point of this talk was to talk about we want REL to participate as members of the community. And as Fedora kernel maintainers, ultimately we are responsible and held accountable by the Fedora community, which means we are thinking about what the Fedora kernel... the Fedora community wants, which may not be exactly what the REL community wants. And there's been a kind of question about... come up about, okay, what happens if two comes in conflict? And I think the answer is that if there's any other conflict in the Fedora community, there's the Fesco, there's the Fedora Council, and I would expect them to make the decision that is ultimately best for Fedora. And if something were to get escalated and they were to tell Fedora kernel maintainers, you made this change, you made an incorrect decision, you need to do something differently, you would absolutely have to go with that, because that's how the community wants. Fedora kernel exists to serve the Fedora community. Yes. And when we can have as much integration as we have, we want it, right? But if it makes sense... and one of the cases that I brought up when we were discussing some of this... Yeah. So one of the cases that I brought up when we were discussing some of this before, where you might have a conflict, you might have a conflict of use, and then say, well, it does. So there are areas where if a config option has two choices and one of them... excuse me, one of them is going to yield higher performance and one of them is going to yield better power usage. Sometimes Fedora is going to opt for the power usage, right? And so I think the idea is we converge where we can, and where we can't, hopefully, those are runtime configurable, right? So Fedora users also probably want the power side of it. So hopefully they're runtime configurable and if they're not, then maybe we should look at trying to make them so. But I think that the Fedora kernel should always be a superset of... because REL is not going to ship anything enabled that they're not going to support, right? They've got contracts and SLAs and all of those things around that. So they're not going to turn on a bunch of drivers that nobody has an interest in because then they have a legal obligation to have that. And so we should always be a superset as far as those drivers and things go. But for the core config, they've got a lot more testing. They've got a lot more hardware. There's a lot that we can leverage there that just makes Fedora better. So I think the question was about if there's a supported versus unsupported flag and I don't believe we are carrying a patch in Fedora. I believe there might be a similar patch in REL but that's actually a good example of the future. We need to possibly look at aligning just because there are often times little tweaks like that that the REL has that Fedora might actually want for one reason or another but we haven't. So that's a good example of one of the packaging changes that could help the two sync up. Yeah. Well, I mean, in one way everything is unsupported in Fedora in a way everything is supported in Fedora, right? We're going to do our best effort. We're going to do our best effort to support anything that we're shipping turned on but we're not going to... We don't have the resources to go and fix it all either. That's the same type of thing you're seeing right now with I686, right? We're not shutting it off as long as people are willing to do the work but we can't do the work on it either. If it gets to the point where the community can't do the work and it's not a supportable thing anymore then it has to get shut off. Sure. I looked at this before when I first joined the team there's kind of a long tail of minor tweaks and patches we've been carrying a good example of something like to not automatically load the floppy driver and maybe a bunch of other minor fix ups. I think the real thing is is that it's not actually that much of a problem to be carrying patches if they're not actually causing us any problems and the point is is to make the diff as small as possible. So it's mostly little weird quirks like that. We occasionally carry patches big features for the long term that are still making their way upstream. Another good example was UAFI's ACPI support for ARM64 that was one that took a very long time to get in and we were carrying that for a very long time. But more common than patches we're carrying long term are patches we carry for a single kernel version because they haven't quite made their way in yet. It's much more common to see patches come in for kernel cycle then drop out later when they actually show up. We also have a couple that silence warnings. Yeah, we silence a lot of warnings. Upstream it said that they find value in those warnings but it just there's no actual value to it for your users so there's a couple that just like that too. And do you think it makes sense to start forcing a bit more of a stable need policy like that? I mean we've tried to do that where we can. I have a lot of opinions on secure boot which you know are probably best discussed at the pub. And we have actually had this conversation with people before. We have said no to people when they asked us if we could carry carry something when it wasn't yet upstream. I think general our preferences is that if it seems like it stands a good chance of it being accepted we will take it into the kernel but we don't want to be carrying experimental patches that will take a long time to go through multiple reviews and have no chance of actually getting in so the closer they are to getting in the more like we are to take them especially if they're adding like a user ABI or things like that. We didn't take secure boot until after the kernel silence when everybody in the room agreed that it was good if we were sure that they're calling. There wasn't agreement there so it's still not done yet. A lot of pieces of it have made it a lot of them haven't and two pearls ago it was the last try to push a lot of it and there was actually some balance feedback out of that so there is it's probably a better conversation. Any other questions or were you going to say something? I was just going to ask why is the floppy drive going upstream is there a strong attachment to this latest floppy drive so the question was about the floppy driver I think it's honestly just from a lot of legacy things is that once upon a time how you booted Linux you probably know more than anything was you stuck in a floppy and that's how it got up there and I think a lot of distros no one has really saw a reason to not to change that so versus fedora so okay yep good question the biggest pain points between the core config differences this is actually something we're going to work on probably in the coming months I don't actually know I can speculate I would honestly suspect it's going to be in options that are just alluded to are likely to give rail better performance versus what fedora chose where fedora probably made a best educated guest to get something that certainly works but may not be optimized so I can't give a great answer but keep an eye out for the kernel listing of usual blogs and stuff as we find interesting things anything else okay we have time do we at least use the same pre-emptions of things in fedora maxcpus maxcpus I think actually may be one where it may have not been the same for a while but then I think we fixed it so that's one of those issues as well that's when you increase maxcpus you're increasing memory usage from that kernel out of the game so we didn't do it until someone came and said hey SGI is actually using fedora to test these massive systems it might have to be readdressed starting in two weeks you'll be able to buy a 64 or 64 thread cpu for a desktop cool alright thank you very much