 So, hello everyone, another talk, this time by Yoshua Powers about HLinux, AP's BBN-derivated a year later. So, welcome. Thank you. All right. So, thank you. Welcome. I really do appreciate being invited to talk here. You've probably heard, if you went to BDale's presentation, heard talks about different open source projects that HP's been working on, and one of them was HLinux, and last year we were at DevConf, kind of just an ad hoc presentation about HLinux, and wanted to come back and talk about where we were a year later. So, before I begin, I wanted to actually do a couple things. I wanted to do a quick survey, and just to put it from my own, and for those of us that work at HP, kind of see who's here, who's in attendance. So, if you're a DM or a DD, could you raise your hand? All right, awesome. If you work on what you would consider to be a blend, would you raise your hand? A few? All right, and then a few, a derivative? All right, and finally, do you work for HP? Okay. I was curious to see how many people were in the audience. All right, so, HLinux got started as a part of Helion, HP Helion. That was our enterprise cloud software product that got started back in 2014. Basically, the company said we're going to continue using OpenStack, we're already using it in our public cloud business, and we're going to expand into doing more than just public cloud, but doing private cloud and hybrid cloud environments. Along with that, we started, as BDL referenced, an open source strategy as part of our business. That strategy is part of working in open source, but how the whole entire company will be part of open source and using open source moving forward. As a part of that, we said, okay, let's also look at what Linux is going to be running this cloud, and said we should be doing our own, or using a debt Linux that is not just bound to a single corporation or one that maybe works with the community, and the obvious choice there is Debian, and I'll talk a little bit more about that in a second. At a high level, what HLinux is, is effectively Debian Jesse. It's always been Debian Jesse. We started using it when it was still in testing last year. We took snapshots along the way, produced those, used those as shipable products. It's a lot of testing and qualification on them. When Jesse was moved to stable, we moved with it a couple weeks later, and we're still there today consuming the minor revisions as well. We like that. We like where it's at. There's been talks about moving back to Debian testing to pick up some newer features and functionality, and to kind of have a faster cadence as well as being able to get our fixes in a lot faster and seeing them get rolled in faster. However, for now, we're very happy on Jesse. The thing that kind of sets us apart from Debian, apart from just using Debian, are what we call foreign packages. It's just an easy way for us to reference them internally. These foreign packages are things that are either in later versions of Debian. They're not even in Debian at all. They're proprietary stuff potentially, and it's kind of just a catch-all for that. Examples of these would be the kernel. We don't use the Debian kernel, and you see at the bottom there, we actually have been sticking to the long-term kernels produced by kernel.org, and that are maintained for a couple of years. We've been on the 3.14 kernel last year. We're still on the 3.14 kernel, so we're shipping with our products. We do have the 4.1 kernel being pulled in now, and looking to that for the newer features, newer drivers, things like that. Still on the foreign packages, though, there are other packages that are not even in Debian. One of these examples is like Percona. That's a minus-ql replacement, adds a lot of HA capability. There are portions of Percona in there. There are also other portions of it that are used by our teams that are not there. Their entire software suite isn't in there, but we do pull in that. Other examples were some of the Elk stack that has recently been put into Debian, and we've been able to grab some of it there as well, but they continue to produce new things. It's part of the Elk stack, and so we're still having to pull some in and combine it and packaging it up. The goal, however, is to get things into Debian wherever possible. The Elk stack stuff work that we did there with packaging around Elastic Search, that's an example of what we want to do. We want to get stuff back into Debian so that we're not having to carry these things as extra things. It's better for the community, it's better for the people packaging that stuff up in the first place, and it's better for us, we're not doing one-offs. That's one of the ways that we're trying to be involved. The downside to this is we have to move quickly, both to get it in time for shipping as well as just the amount of effort sometimes this takes. It's packaging work. It takes a lot sometimes. Let's talk about the kernel briefly. The other thing I want to talk about, why do we carry these longer-term kernels? We are doing enhancements, so we have partner programs where we're working directly with our hardware vendors, companies like Melanox and Emulex, where we're meeting with them and working to get their latest features that they have produced in hardware, make sure that we have the drivers that enable that hardware. We have a very close relationship, for example, with Melanox, and working with them to get latest virtualization features like VXLAN and other offload capabilities into our driver so that Helion can take advantage of it. If there's a lot of customization and patches that we're doing there, that we're driving that we don't feel is totally appropriate to be trying to get into Debian, at least initially. Nothing proprietary there, however, it's just we're trying to get it in faster. That's kind of a high-level overview of what Helion and HLinux are. So I said Debian was kind of the clear choice at the beginning of this, and it really was the fact that you have a strong community of people and you're not bound to a single company. It's very easy for us to work with the community and to be involved in that community if you want to see something get done and change. If you work with another corporation, we're kind of at their we're bound to them and what their business practices are and what their business decisions are. Instead, we can come, we can be here at DebConf, we can talk to people, we can work on the mailing list, we can go solve bugs that we see and actually see those things get fixed quickly. So in addition to that, it has a very strong and lengthy history of working with Debian, right? HP has the telco extensions, which are still live in a well and are still being run to this day. Although the number of customers is very small, it's still work that we're doing using Debian with different telco and carry great customers. So that's why we're here using Debian. When we started doing this work, there were just a few of us and we didn't know what HP Helion was going to be like entirely. There weren't a lot of firm requirements set out yet. We didn't know what the distribution model was going to be, how customers were going to get their hands on Helion, how they were going to update and even install Helion, what that process looked like. Today it uses something called triple O, it's an open stack project. And when we first started this, we didn't even know what it was going to be. That process is still evolving and we're still evolving with it. However, this led us to make a lot of assumptions and a lot of kind of decisions around, there's a lot of uncertainty. We don't want to mess anything up for Debian. If we're going to use Debian, we want to be good consumers of it. We don't want to give Debian a bad name. We don't want to break Debian. We don't want to harm Debian. We want to work with the community. And then the last thing we want to do is fall flat on our face and cause harm to come to Debian. So we have a very strong concern around how Debian is being used by both our eventual customers and through the products that we're creating such as Helion. So kind of an example of this is, and I'll talk about this in a second, it's something we did, we did something called rebranding. Where we were taking each of the Debian packages that we were using and we didn't want a customer to say, I've got this Debian package, it's broken. I'm going to go under the Debian's IRC and complain. Well, for them to know that it came from us, we were sticking in a tag effectively in the version string plus H Linux. And letting people know very clearly that you're getting this from H Linux, you're not getting this from Debian. And we were doing this packages, even those that we weren't changing because we didn't want anything coming back to Debian that was potentially bad or harmful. So that was one of the kind of decisions and I'll talk about how we've changed since then. Like I said, DevComp 14, we were there in Portland, Rocky Craig was there, got to do a quick ad hoc presentation on H Linux, talk about our kind of process, and we got great amount of feedback and enthusiasm to seeing HP back at DevComp. Feedback primarily was around getting involved, using existing tools. Why are you doing it like this? Go do this, it already exists. And it was a great education experience for us. When we first were getting this out, there were three of us that started in February and it was you will deliver something to us by the end of April. And so there was a lot of shortcuts taken and a lot of let's just get this done. Let's figure this out. Let's use a tool, try the tool. If after half a day we can't figure it out, let's move on to the next thing. And so since DevComp, we've been able to take a step back and kind of review what we're doing. This is tool makes sense. Should we be using this? Let's get rid of proprietary stuff because that proprietary stuff takes our time. It takes a lot of effort for us to maintain it and deal with it. And maybe we're not doing it entirely in a very Debian friendly way. There's a better way of doing it. And so after DevComp 14, we were kind of the paranoia and the fear of really hurting Debian kind of went away. And I was like, okay, let's get involved. Let's do things right. So as far as an involvement, I think the best way to sum it up over the last year is we've definitely fallen short. Our involvement has really just kind of ramped up in the last few months. For the help of Martin Mikkelmeyer and getting people involved, it was around the GCC5 effort. There were numerous patches submitted, not the defects reviewed and closed, including by a number of people in this room. And so overall, it was just a great learning experience and getting us into the project. Some people have worked with the project before. Some people, for example, we hired four new employees fresh out of college, no work experience, no Debian experience. And we got them involved and some of them were already submitting numerous patches. So it was a great kind of icebreaker to say, look, this is how you do it. Get into it. You know, we want this to be part of your day job, not just coming in here and doing what you need to do for HP because helping out Debian helps out HP in the long term. And so getting them involved in the community now is of the utmost importance to us. What else? So a number of bug fest that we had just kind of locally on our team. It was a great experience. It was fun to see a bunch of people just hacking away for a few hours and it left them kind of energized to keep doing the sort of thing. Especially the new employees kind of saw it and went, this is really cool. I want to keep doing this. So we want to keep doing that. In addition to that, Martin worked on rebuilding the entire R64 archive. HP has an ARM system, the M400 moonshot, able to take advantage of having that hardware on hand to be able to do some of this work. So that really is unfortunately the extent of the direct contributions that we've had with respect to fixing things in Debian. And we feel that this is probably too short of a list. In fact, it is too short of a list. Something that we want to get more involved in, whether it be packages that Helion's using and we want to make sure that they're being taken care of upstream. Other packages down the road that make sense for us and other initiatives like I'll talk to here in a little bit. So I do have some other ideas of areas where we can be involved in, areas that we like to target here in a few slides. So I mentioned rebranding already once. And this I want to be kind of an example of something that we took back from DevCon 14 and said, look, we cannot keep doing this. We have to do things the right way. Again, as I mentioned, it was round. The intent was hopefully good. We didn't want to bring bad things to Debian. We didn't want people to come to Debian and be harmed by the work that we were doing. I want them to come to us and say, look, this is broken. Fix it, especially if it was us that was doing it. So again, it was done by adding the plus H Linux to the version. Long story short is we started finding this was breaking things. All right, we were trying to do this in an automated fashion, but with the version strings being so drastically different between different packages, some having multiple pluses or different ways of having the tilde in there, all completely valid versions, it was causing, we were starting to break things. In an effort to not break things, we were in fact breaking things. And we were simply were too paranoid about not breaking Debian. We were actually causing harm. So we have removed that from unnecessary packages, packages that were not touching. So those packages that we don't touch are we'll have an MD5, some of them exactly what you get upstream. They are identical. The packages where we are making modifications and rebuilding them and still carrying them with changes, they will get an H Linux string. So it's a very clear that it's coming from HP and the H Linux team. However, stuff that we're not touching no longer will be messed with as it should be. Things that we learned out of this though was, like I said, the versions, there's some very crazy version strings out there. It's absolutely amazing to see, we got plenty of laugh after seeing some of the versions, 3.18 till the really 3.19 as well as some crazy other strings that were in there. And so, but all of them are valid. And there were many days where we would sit there and stare at the Debian policy manual and go, is this actually valid? Is this really how it's supposed to work? And yes, yes it is. And kind of out of that is all the wisdom that you need to work with Debian is really online. And if it isn't, you can go ask on the mailing list. You do have to stare at it sometimes. You do have to let it digest, especially if it's your first time seeing it, just due to the immense amount of history behind the Debian project. It's absolutely amazing. It's also a little daunting sometimes as being a newcomer and saying, it used to be this, then it was this, then it was this, then it was this. And having to trace that and understand, oh, that is a valid thing. So it's a challenge and it's a challenge that we're up to and we're enjoying it. So props to the community for having so much stuff online and having it updated and from the most part, being just an excellent source of knowledge. So one of the other things that we took away were the tooling. So we were using a lot of proprietary tooling and just by proprietary I mean we wrote, we went and wrote some stuff. Generally, this tooling was just wrappers around existing Debian toolings. So de-package, scan packages, scan sources. Instead of using pre-pro, we were doing our own thing. Kind of a cool thing is that we made it multi-threaded so that we could do, build an entire archive from scratch in like five or 10 minutes. But we don't need to be doing all this stuff ourselves. Let's use the existing tools out there. Let's use the existing tool chains that are out there. We've also looked at Apply to create smaller repos when we're doing some basic development and basic package development. But we're moving to these packages. Let's use them. If there's stuff that's missing, let's contribute it. Let's figure it out. Let's work with the maintainers. Let's get rid of our homegrown stuff as you just don't need it. We don't need to be spending our time there either. Packaging, so some of the work that we're doing around packaging primarily focuses around get build package. There's a wrapper for the get hook that will pass some information between get build package and sBuild. That has made packaging both for our team just significantly easier. We had one of the new employees come in. Well, I think I said back, I remember trying to do packaging last summer and going, okay, gotta do this, gotta do this, gotta do this. And never having any experience in it. Read lots of documentation, little overwhelmed, but you get there. The wrapper we have basically simplifies the process drastically. We've had a new employee come in and we said, look, we need you to build this. This is what we need you to do. Go to update the change log, run this script, did it, and you gotta dab an hour later and everything was good. So it's something that we've been talking about, how can we contribute this back up? Even though we're already using these tools that already exist, is this wrapper something that the community might be interested in seeing at least in our scenario? It's not too tailored to what we do. So getting into some more like meaty areas where we're interested in contributing, first off is QA. So my background is in QA, started at HP doing QA. And HP obviously has decades of experience doing operating system development, right? With HP OX, you have 20 or 30 years of QA knowledge and QA experience and tools that were developed and test cases that were developed to test an operating system. Many of the people that work in our organization have even come from the group that used to work on Red Hat in HP. HP being a big partner with Red Hat and selling lots of Red Hat servers. There's lots of testing that we did there that made Red Hat better, made HP OX better. And all those tools are still, many of them are still in existence. And what we wanted to do is say, look, if we want to build and contribute and work with Debian and produce a distribution that's been qualified and is solid, then let's use those same tools. They were there, they worked for a good reason. Let's get them back up and going. We have an internal storage tool that is proprietary, but will just destroy any storage that you throw at it and gives you an extreme amount of confidence about that storage. And it's something that we've wanted, that we're already using to qualify our distribution. And it's something that we want to see if we can apply it to Debian and there's no reason why we can't. Getting it open source, that's going to be a harder step, but at least being able to say, look, we've run it with this and we can explain how we ran it. At just one example, there are other tools out there that we have as well as the processes and the hardware that we have accessible to us, right? We do sell more DL3As in 360s than anything else, but we have the M400 RM64 cartridge. How about we use that? How about we do testing with the RM64 kernel in Debian and see what's going on there? If we can find out what tests people are interested in or features that people are interested in, what can we spend time on testing and qualifying there? We also have access to vast quantities of drivers, right? Do the different hardware that we have. We have I.O. from Melanox to Emulex to Broadcom to Q-Logic to Intel to Solar Flare, you know, vast quantities of networking drivers and storage drivers, as well as some weird ones around Fusion I.O. and things like that. Not all of it is open source, but some of it does have drivers for Debian. There's lots of enterprise customers interested in running Debian and still running some of the software, some of these hardware devices. Let's test it. Let's actually get it and make sure that it's working. The HP servers group actually does do some community testing today. With Debian being treated as a community operating system, it doesn't go through its full gamut of tests, but we would like to push more of those tests that they actually do have onto both Debian and the work that we're doing with HLinux. Finally around QA, we spent a lot of time using Debian testing, and one of the things that we found was not that things broke, but that there was a lot of churn and there was a lot of changes going on. And one of the things that our own internal partners required was some stability. And so I know there are efforts around talking about how can we make testing a little bit more stable, potentially. What work could we be doing there? We've had some experience with it. We kind of know how it works. We've seen how our release works. What help can we be doing now, not at the end of a release to help provide some of that stability there? HP servers has a whole series of manageability and other tools to interact with, say, ILO or the HP SmartArray driver or ChurnArray devices. These tools are readily available today and they're non-free software, but they are available without paying for them. I forget what it's called on the Linux software repository or the system software repository. But we want to start lumping that stuff into HLinux and being able to deliver that as well, be able to take advantage of the value add that HP provides. And finally, I've mentioned ARM64 a couple of times. We do have hardware that's out there. We have hardware on our team that's usable by our team members. But what about other people, maybe getting them access to it? But also, let's get ARM64 as a first-class experience. Everything that you expect on AMD64 is it working on ARM64? Do those packages work? Secureboot, UDIFI, which I'll talk about here in a second. Let's work on it. We have the hardware available to us. By the end of the month, we'll have about two dozen of these ARM64 servers or Moonshot cartridges available to us. So people on our team can start doing some work. Let's see what the community wants as well. Other areas of interest for us around virtualization QEMU containers. So today we carry our own version of QEMU. Again, it's just tied to the most stable release upstream. The individual is Andrew James, who is in the room, I thought. Where is he? Maybe he's not in the room. Well, Andrew James is here at the conference. I know he's been talking to some people about the work that Debbie has been doing around QEMU. He maintains it and watches it for us. He'll basically watch for critical CVs, get them to us within hours so that he can republish things. He also makes some tweaks and changes to prevent things like pulse audio from being compiled in. So there are some changes that we like to make to keep it free and also simpler for our customers. Obviously, there's lots of interest around containers, what that solution might be, using Docker, what about other software components that need to go on top of that. It's something that we're interested in working with the community to see what else is out there and how are people using it. How are customers actually using it? What does a typical solution look like? And where are there opportunities for us to help out, specifically around maybe manageability of all your containers? What does that look like? Security. So we do ongoing vulnerability scanning. We take advantage of a lot of the Debian tools that are already out there, as well as the security that we get from stable-security. There's also the work that we want to be doing around things like we have software in HP called Fortify, which allows for static code analysis. We have made numerous discussions with people inside around how do we take software that Helion is interested in and start scanning it and being able to contribute maybe those results back to the community in the form of patches or even just the report. It's a big tool and there's a lot you have to do to get it set up. So it's something that we're slowly moving on, but it's something that we would like to move on at some point. In addition to that, there's the... I have to forgive me. I don't know much about this yet. Just got an email from another person on the team around Oval or OVAL. There's two bugs that we've submitted around getting it updated. I guess it was a way of getting security information into Debian and for certifications. That seems to have died down and the package is no longer maintained. We actually, one of those bugs have a version of the package submitted, but none of us have the upload rights, right? So those are two of interest to us as well. Secure boot. So number of packages that we've had to make changes to to get secure boot enabled. With the recent announcement about the EFI team, we're heavily interested in getting involved in that. That's right. So Link Rosetto, who actually is here and I can actually see him, he's waving his hand. He's one driving a lot of that work for us and is interested in getting involved there. Again, HP has lots of servers that now are shipping with UEFI by default with the Gen 9 going forward, as well as on the RM64 side, we're interested there to see what work might need to happen there. And so some of the work that he's done and I'm sure he's happy to share his learning center. All right. So the last thing that I wanted to mention is there was talk during Neil's kind of state of the state of Debian talk around, you know, they're calling HP is calling things H Linux that they're getting all the credit for what they're doing. How's it going back to Debian? There's been talk this morning around the trademark discussion as well as the what is Debian discussion. And, you know, quite simply put, you know, we are one of the companies that's working with Neil or has talked to Neil and said, look, we are interested in a way of getting Debian somehow in the name. Right. We do not want to take credit for all this because it's just rude and it's not what we're doing. Right. We're working as part of the community. And so the community should be getting that credit as well. All right. We have no interest in forking. We have no interest in saying this is our thing and not your thing. And so, you know, whether it ends up being Debian by HP, H Linux powered by Debian, you know, whatever that might be, we would like to see that happen. We totally understand that, you know, we're not official Debian because we are making changes to it. We have our own kernel. We have our own foreign packages. And we even carry some non-free stuff around firmware and other things, like I said. So we feel that we're still close enough to Debian. Right. It's just Debian with some customizations, some additional packages. And so we would like people to know that it is, in fact, Debian that they're running. It's advantageous to us and to our customers so that they're not going, what is this H Linux thing? I've got Red Hat. I've got Debian. I've got this and I've got that. And now I have one more operating system I have to deal with. No, it's just Debian. Oh, I like Debian. You know, that's usually the response that we get. You know, we get on a phone call with a customer, they're all riled up. And it's like, yeah, it's just Debian. Oh, okay. Life's great. So, you know, at the same time, we're not completely changing everything, right? We're still based off of Debian, Jesse, for the majority of things that we have, the vast majority of things. And it's always our intention to just use Stock Debian plus maybe a few things that we need to that are special, like the kernel. So, you know, not only do we want to continue working together, we want to be able to help out with this and figure out a way that, you know, the community and HP can work towards something like this. So, I think with that, again, a big thank you for the warm welcome. And it was very nice during the job fair to hear a few people say, you know, it's nice to see you guys back here and really do appreciate it. The help that we've gotten on the mailing lists, as well as the, like, the Debian, excuse me, the Debian derivatives mailing list, I really appreciate it. And if you have questions or comments that we don't answer now, that's my IRC name, as well as my personal email address at HP. And it is HPE now, I should say. If you don't know, HP is splitting into two companies and the vast majority of us that are working on cloud are, all of a sudden, working on cloud are going into HP, or Hewlett Packard Enterprise. And so our email addresses are changing. So, that's why the E is up there. So, again, thank you. Are there any questions? It's all crystal clear. Can HP, probably not now, but would HP be willing and able to commit to contributing to a test suite of, basically, tests which determine, yes, this is a well at Debian, which can then be named, powered by Debian or whatever. We're definitely interested in helping out there and actually understanding what does that mean and what does that look like? You're totally behind that. As well as, you know, one of the things that we got brought up today was, you know, some sort of change log or being able to say what is different, we would like that. You know, we think it's in our best interest for our customers, as well as for you to understand what are we doing differently. More than just some simple bulletless, but some way of saying, yeah, this is what we're doing differently. So, yes. Will Hlinux be of help to get official HP support for Debian proper? For running Debian on HP hardware? So, I will tell you what Steve Geary said. So, Steve Geary is the director of this lab that's working on Hlinux. And from what he said, and I feel like I can quote him on this, is HP announced full support of Debian a number of years ago, and then I pulled it away. It made a big splash in the community. However, the number of people that were taking advantage of that support were apparently in the single digits. It just was not used by anybody. So, yeah, BDL could probably fill that in. Yeah, it was really quite interesting. When we did this, and what we did was, we offered Care Pack offerings, which is what the ProLiant server guys do for a certain level of support for Debian. And the number of people who purchased those were literally in the single digits. And what we discovered was that what people really wanted to know was, if I load Debian on this box, is it going to work or not? And their way of asking that question is, do you kind of buy support for you, from you, for Debian on this box? And then they didn't actually buy it. They didn't want to buy it. They just wanted to know that they could, and that meant we had done all of the testing and so forth required to ensure that everything worked. The problem for us is that for that organization to be willing to sell that offering, they were doing real work to test and verify and do installation tests and certifications and all that. We're to the point in history now where the things that are required to use those servers are almost entirely all part of upstream kernel source content. And so there aren't as many interesting questions as there used to be about is it going to work or not because it is just going to work. And along the way, somewhere we got the server organization to agree that there were no issues with hardware warranties or anything if you chose to run some Linux distribution that they hadn't heard of before. And so what sort of morphed is instead of having Debian as sort of the community distro that was sort of deeply supported, they ended up sort of agreeing to a broad but shallow set of assertions about we support community Linux distributions. And so if you go now to hp.com.go.debian, it will actually warp you to hp.com.go.communitylinux and there's a set of assertions there about HP works with community distros, blah, blah, blah. So what does all of that mean? Well, I think we need to figure out what the question is we would actually like to ask as a community. This is with my sort of Debian user and community and developer hat on. What is it actually important for a company like HP to be willing and able to say? And I think if we ended up in a situation where at some point in the future, the name of this H Linux thing has Debian in it somewhere and you can buy support for that from HP, which is likely to happen at some point for some set of machines, then this question might just go away. If any of you in the room have specific examples of somebody who would refuse to purchase HP's servers in order to run Debian on them because of a missing support offering, I'd like to know about that because if someone is actually willing to buy support, then convincing the people who provide that support, it's worth making investment could happen. The problem is the only data point they have is we spend a lot of money in what they thought is a lot of money to enable all of this and nobody actually really bought it. And so from a purely economic standpoint, continuing to tell them you have to do this, you have to do this when they got no money back for it just didn't make any sense. So this is the success and the failure, I guess, of Debian. We do such a good job of making sure things just work that once we cross the threshold of the device drivers for the hardware are all available in the kernel, there just wasn't any particular reason for people to want to spend money with HP to get Debian supported anymore. So that's my take on it. Having been there through most of that history, if there's something I'm missing or if there's opportunities out there for interestingly sized deals that would be enabled if HP somehow all of a sudden asserted more support for Debian again, please let me know because those are the kinds of things I could take back and talk to others in the executive community about. But right now, I don't really know how to make that argument to them. Are there any plans to commercialize H Linux separately from HP equipment in the same vein as RHEL? Other questions? Is there an HCL? Is there a what? Hardware compatibility list available. So yes, if you look at the Helion support matrix, there's a list of the hardware that we support today, both HP hardware and non-HP hardware. So how many of your people have you got working towards NM at the moment? Great question. The new guys who have started some main patches, they kind of know about the process. They're still getting their feet wet with it. What I hear from them initially is, but I'm not doing a whole lot of packaging, I'm just doing bug fixes, right? So how do I decide I just apply? Should I just go through the process anyway? What's the best process for them anyway? I think there are definitely some that would like to go that route. We've had to get a few people turned into at least members, and so we're trying to figure out what's the next step. So if you have advice. Yeah, so the best thing to do is, if there's packaging teams or various other teams in Debian that you guys are already doing work alongside or whatever, just join the teams. The teams are typically going to be very happy for more manpower, and join in, and NM should be a breeze. Talking to which, you know, I waved earlier, the new EFI team, please. I spoke to Lynn earlier, and I've already had some discussion about the changes that you guys have. Again, we're an open team. Please join in. With every any chances of getting Debian support from HP on non-HP hardware, like for instance, you can buy support for Ubuntu, non-Ubuntu hardware. To hear that one. The answer I would give is the one you already gave, which is that the existing HLenix portion of the Helion hardware compatibility list includes non-HP hardware. So that's the quick answer. If there's particular hardware you'd like to have supported that's not currently supported, have a conversation with one of us and we'll figure out what to do next. We actually currently have a third-party IHV testing program that we're pulling in and doing more and more testing. My understanding about your kernel is that it's stripped down to all the drivers you need and only these, right? So by removing some drivers, then will it make Helion not working on some hardware? So we have run across examples of that. The most of the time when we're referring to the drivers that we're pulling out, it's stuff like mobile devices and personal laptops and hardware devices that were used 30 years ago and aren't used anymore. So that's where we're focused in. If it's enterprise class or storage and networking drivers that are 10 gig or more or even one gig stuff, we generally keep those in. We're not going to pull everything out. We didn't go extreme and just say, oh, these are the very few HP things that we care about and that's all we're going to include. There's still a lot of general drivers still in there. So third-party support, we've had to add a few things in there because we said oops, we didn't mean to take that out or we didn't realize that actually is still used. But, you know, and that's part of this IHV program is to identify that as well. Other? So one of the challenges we have is we're trying to create a balance between minimizing the number of packages, really driving more security and a smaller footprint that we have to worry about security on and yet still providing the level of support across the hardware and IHVs as well as other feature and functionality. So this is a learning process for us to figure out what that right point is to keep us small and secure and yet still support what we need to support. Any more questions? Cool. Thank you very much. Thank you.