 All right, we are now recording. This is a sandbox discussion vote to come later. Yes. Hi. Today is December 13. Thank God it's not a Friday yet. So let's start with Merbridge. Merbridge. Does anybody have notes on Merbridge that they would like to share? Yeah, I have gone through this, gone through it and have some notes. So this project makes traffic intersection at the socket level and the leverages eBPF to directly forward packets from one socket to another socket instead of going through the existing Linux kernels, IP table, right, which so it speeds up the data pass in the service match, which I think it's a great improvement. And also the industry is moving out towards that direction. So I think it's a very good project. It helps the performance. Yeah. Yeah. One thing that I had was this is, is your specific? So I was going to ask if they should talk to your folks or not. That is the only other thing that I had. I don't think it is. In my notes, I have that they integrate like an eBPF accelerator for any service mesh and they mentioned both Linkardy and Istio. Yeah, that's what I had in my notes too. They are only useful for those that are not doing eBPF yet, but still it's super interesting. But like things like Ethereum service mesh offering or say Istio starts doing eBPF then the value is less, but for now, this is very nice. Okay. Agreed. Yeah, I just want to add that, you know, there are other, I see other presentations, you know, the TCP IP bypass, IP table bypass, which address, you know, the same problem, you know, using this eBPF. So maybe they can try to expect that incorporate more contributors or maintainers from other components. Yeah. That's what I think. Okay, sounds good. So we are not voting right now, right? But, you know. Broad agreement is. Broad agreement. Yes. Anyone dissenting here who's on the call today right now? Going once, going twice. Okay. I will add this to the vote. Moving on. Yeah. Okay. Dev space. Dev space is interesting. This is from the loft folks as well. And the thing that I liked here was this architecture flow diagram where you start with one, is it a YAML file or a JSON file? And then essentially bootstrap a work area for yourself and to build and push and run on Kubernetes. And then, so this is similar to the, you know, tilt stuff from loft as well. So in general, I think we need to pay more attention to developer oriented tools. And this one seems like it's in a good space for that. Yeah. I think with the right level of visibility and community support that this could, this could really take off within the community and the ecosystem. I didn't see anything within the project that gave me any pause for consideration. Yeah. I agree with that. I agree with that. Yeah. It seems like the deployment workflow has a very good roadmap. And I think it's a very useful project to enhance developer velocity. Should we have a developer tag? I think once we have enough set of people that care about this developer tooling stuff, I think we should definitely do that. The delivery has been doing a bunch of the developer stuff, because it comes closest to that. And that's where those things have tended to fall today. Yeah. That's what I was going to say. We might have to carve out some stuff from the artillery folks to bootstrap this. And we already have some things. Like telepresence we've had for a long time. We've got a number of projects that already fit into this dev space that we could probably justify today. But that's a separate thing. This project has been around since 2018. It's got over 3,000 stars. They've shown they know how to be an open source project. Yeah. So any dissension here? So we can go faster. Okay. So let's go to the next one. Next one is the OPCR. OPCR, we talked about it once. We sent them to talk to the OPA folks. They came back with some feedback. And the feedback is summarized here. I'm a little confused on how this plays out for other sandbox projects, because originally we had sent them back to be considered potentially as a sub-project underneath OPA. OPA doesn't necessarily feel like they're a good fit because they want to see broader adoption, which the sandbox provides a place for vendor-neutral collaboration, increasing adoption. But it is not designed necessarily to be the adoption kind of producer for projects. That really happens when they reach a higher level of maturity and better stability. So if this is accepted as a sandbox project, and we start seeing widespread adoption, they get 10,000 users as a milestone, which is interesting. Does OPA suddenly come in and say, we want you as a sub-project and now we remove them from the sandbox? How does that work? And how do other people feel about that potentially playing? I think it can go either way. So starting off by itself and then the OPA project saying, yes, come join us, I think that is good. So we've done both ways. So Helm was part of Kubernetes and then we split out. And then we have, for example, there was one more project in container D space that came back into container D as a sub-project that was outside. Do you remember which one, Justin? No, I don't remember now. But yeah, I think we've had a few to do that. Right, I got it. Run Wasi was not sandbox and they still came to, if we can bring outside projects into existing graduated projects, I think it should be fine to get sandbox projects into... And you sandboxed that path. Yeah. Okay. Yeah. One question I have. They've got a registry there running, apcr.io, a free hosted registry around the policies, which is, so are we going to pay the cost of running this for a sandbox project that we don't normally provide resources for? Mike, I would push them towards asking for support from Artifact Hub to kind of at least do the indexing, but we generally won't post full-blown registries or for folks at the sandbox level. Yeah, Artifact Hub is only metadata. It doesn't actually host any resources. So there still has to be a registry host in the resources. Point. Yeah. It's not clear to me why that it necessarily is useful to have a separate registry hosting rather than just metadata for this project in the long run anyway, because why do you want a different registry for your policies if it's just an ACI registry? Maybe I'm wrong. I think, looking at the submission, it seems to be only for the CLI, not for the registry part. Well, in that case, but then if the registry is prioritized as the default location for the CLI, and that's not in CF, that's also a problem. Yeah, we can talk to them about that, right? Justin, we can tell them that you can't have your own thing as a default. We tell them many projects anyway, the same thing. Like we told Cubescape too, and they came back to us and said, it's okay. We'll not throw in a default, which points to our own vendor stuff. But I don't think it's vendor stuff, because it's got the same name as the project, it's abcr.io. So I don't think it is a vendor. So I think it's more of an issue that. Yeah. So the caveat here, we should probably tell them as, hey, you will need to do whatever you want to do with the service itself, rename it, you know, call it something else, and it should not be the default. If it's just container, if there's stuff in container images, go ahead. Sorry. I was just going to say that the project and their service can't have the same name. We got to make that, we made that clear before I thought. Yeah, exactly. Okay. So other than policies are stored as container images, it should be like they should be able to use any container industry and just be configurable. Only then it will be useful to everybody. It says they can, but it's just the default is abcr.io. Okay. Yeah, we'll tell them to rename that. Okay. Okay. Any other, you know, observations, suggestions? I had one. I had a note here. I can't find the link right now, but I don't know. They had some discussion about integrating this with OPA and there was some pushback. All right. Yeah. So they didn't, the OPA folks didn't want them to be as a project of OPA. You know, I think there was some statement like OPCR is not open source or something like that. There was some aggressive statement there. There may be some politics in play, but I think, you know, you could argue OPCR is early stage. It's super early stage, right? So I could be OPA wanting to not, you know, not take a risk until the project's a little bit more mature. If we reach out, maybe we asked them, I'll clarify that part. And it could be they're talking about that separation between the hosted registry and the CLI, which is what we're getting into. They're named the same thing. Right. So what we're going to tell them is we would welcome the CLI and the library part of it. We don't want the service. You should rename the service and it cannot be the default, right? That covers all angles going once. Do we want them to reapply or do we want them to vote? Do we want to vote on this now? If you're not voting as such, but the consensus is we are going to throw in caveat that they cannot bring the service in. We are not interested in the service. They should have some alignment with the artifact hub for sure. And the default can't be their service. Because I'm opening a vote for all of the discussions, do you want to add them in or do you want to have them reapply? Let's add them in in a second bucket, please. First bucket is like, you know, there are no objections. So we add them in with the caveat. If they don't accept the caveat, then they don't come in. Exactly. Yeah. Thank you. Moving on. Okay. Goblet. I kind of like this one. Did anybody get a chance to look at this one? Yeah. I took a quick look at it. I like the project. I think it's useful. However, I had some concerns that it seems like it's GCP heavy. But I also am not sure what the potential adoption is going to look like for this project. Like, I'm not sure that I can see this actually going fully fledged and reaching all the way out and becoming a graduated, highly mature project adopted across the ecosystem with the way that it's currently set up with just GCP only. Yeah. I also went through this project. It is especially for Google Cloud Run and it's for Google serverless offering. And also, it's for, it's Python runtime. So Python language. So I think that the scope is very narrow as of today. Yeah. So I kind of agree with that. Yeah. So they were saying that the equivalent for this on the AWS space is, the chalice stuff. Like, I don't know. Is Chalice in the CNCF? No, right? No, it's not. So I don't think I had that objection. The objection that I had is I think it was low number of people contributing. It seemed... Well, that too. Yeah. Yeah. Yeah. I like where it's going. And I like the developer space. What I don't like is obviously the low number of contributors, but the single vendor, right? We talked before just about, you know, not favoring a single vendor. And this is all targeted at GCP at the moment. Yeah. And it's not a multi-vendor project. It's kind of a very useful project, but one that I think needs to grow into being more multi-vendor before it fits within the CNCF. Yeah. Yeah. I agree with that. And I think we've not accepted projects before that will only run on proprietary services with no open source backend it runs on. Yep. Or at least it should run on multiple of them, right? I think we've been quite... I don't think we've ever accepted something that only runs on proprietary services. Maybe there's a couple of exceptions, but... Exactly. Yeah. The custodian is probably doing that now. Yeah. I think that might be the closest thing we've got. But some of those secure container stuff also, right? We didn't accept them in the end, partly for that reason. Okay. So anyway, for Goblet, I think we can say that please expand where people can run this and build a little bit more of a community where there are additional contributors and reapply. Is that okay with everyone then? Yeah. I think I would also like to add that. Expand it with more languages, right? Just pay some solace. You can have many different languages. You can have Java. We can't force that, Cathy. I mean, we should let them do it by themselves. The name of the project starts with Go as well, right? So... Okay. I think we can give them suggestions. The scope is too narrow. It's not very... If just pay some, right? The use is narrow but will be limited. Yeah. It's one person doing it, right? So we can't really drive hard on that side. Yes, when the community expands, I'm sure they'll get asked about other languages. I'm sure people are asking the person already for other languages. Maybe that is part of the reason they are coming here because, we can build a community here in the sandbox, but then we do have this other restriction of, hey, you need to be... I hate to do this in the spirit of time. Can we move on? Yes, please. We can tell them to reapply here, Amy. Yep. I have put language into the chat. Yeah. So, Vine NAS, this seemed like a fork of Ganesha FS, NFS... Way too early. It's only got 40 commits. It's like... And one person, yep. Way too early. Okay. So come back when you build a little bit more of a community and you have some other open-sourced things on your... Right? Okay. Okay. Worf. Did anybody get a chance to look at Worf? I thought it was cool, but I had no opinions. Kathy? Yes. Yeah, I did. So let me look at my nails. So it's... My app has a list of issues to be worked on. It looks like it grows in a Git, Docker, Kubernetes, Helm, with any CI system to provide software delivery to Kubernetes. But I do not see a description that shows very strong technical merit or what is... Yeah, the technical merit that they will provide. And it was mostly from Russian-speaking countries. So I think the reason they want to apply is they want to be more international. And also it said we are not sure whether moving this party to CNCF is relevant, but we are happy to discuss it. So I think that part is a little bit confusing to me. Yeah, the one red flag I had was... I think they mentioned they had a fork of Helm. So Matt, did you see that? No, I did not. Let me... Yeah, see, it's right here. Why would they fork it? That's the interesting... It's embedded into the deployment process. They maintain their own fork of Helm to extend some features that are not included in the upstream. I also have their own tough implementation, which I had not come... I mean, one of the things that's kind of... About this project is that I've never heard of it before, before it came to Sandbox. I mean, I think they're bringing it into the ecosystem and having some more relationship with Helm and the other things might be quite positive for them. Because I think the impression I get is they're quite... They've been quite isolated. You know, it's obviously got a bunch of users, it's got 3,000 stars, but they're not part of the community. And I mean, the men is probably better than not doing that. Yeah, I would say the same thing too. And I think it's a consultancyflant.com that is doing this. Yeah, my concern is with forking, especially with things like Helm and maintaining a fork, is keeping things up to date for security. And just a brief look, I think they're using their fork version of Helm has known CVEs in it. And so they need to close the security. Gonna fork the projects and you need to keep up to date for security, I think. Yeah, so it is better to bring them in so they can work with the rest of the community here is what I'm leaning towards at this point. Does that feel okay, Matt? I think from the tough side, Justin also indicated the same. Yeah, the tough thing they're using again is not applying as part of this, which is also kind of... Once they come to the table, we can open up that. They said they're open to talking about it, right? Yeah. I think it would be something that it would be worth having. That means they're having security together. Yeah. Okay, so I think consensus seems to be positive. So moving to the next one. Capsule, has anybody got a look at Capsule? I want to reiterate, so it solves the problem when the Kubernetes tenant needs more than one namespace. So basically it groups a set of namespace resources into a new abstraction and assign it to a tenant. I think this technology is useful because sometimes a tenant needs more than one namespace. The tenant spans multiple clusters, the same namespace in the multiple clusters, I guess, and they have a way to synchronize things between the multiple clusters, right? Yeah, I also took that note. I think they have the notion of a tenant instead of an namespace in a single cluster, but then they also spawn multi-cluster. So it sounds really, really interesting. I didn't dig very... I didn't go very deep, but the concept is very interesting. Yeah, I think it's useful, this project. I think this is worthwhile bringing in because of the amount of multi-tenancy issues that it keeps showing up with projects, and this might be a great way for them to tap into that. Yeah, I think also it would be interesting. I don't know how far we got with hierarchical namespaces, probably not very far yet. So this is also interesting to have a different separation. Yeah, okay. So they're using everything to stitch things together. So multi-tenancy is definitely plus one for me to do stuff around multi-tenancy. Okay, I don't see any other red flags moving on to the next one. Okay, Devbox. Did anybody get a chance to look at Devbox? This seems very unclear why they think it's cloud native. I mean, it's using Next to make development shells is kind of hard to see where, how you would... Yeah, it's like trial and error. Get your container working and then you... Well, it's not for containers necessarily. It's for developers directly. I mean, it's for a shell, not a container. Right. No, you can create a container at the end once you're happy with it is what they said. This is Docker file. Yeah, okay. And essentially, they use Knicks under the covers and you end up creating the devbox.json for each project. So you know exactly. Yeah, it's something like Python, Beals, that kind of stuff, right? I don't see... Can you check the form submission? I think they were missing a bit of the information that we asked. Or I don't know about this, like overlap and alignment with other projects. Do they have it there? Yeah, I'll scroll through. I'm reading and it says when ready, turn it into a container that can be deployed to the cloud. So that is the attachment that they have with us. Okay. But they didn't fill in the section on alignment with the CNCF projects. Yeah, I think it would be interesting to listen, to get them to provide a bit more information there. What are we looking for? This one, right? An explanation of alignment in your lab existing? Okay. So Amy, can you please make a note? We are asking them to reapply with additional information on overlap with CNCF projects. Yeah, take a look at what I put in the chat. All right. I have a quick question. Sure. If they can't fill that in, is that going to really sway our decision? Like I'm reading through that. Probably not. Explain how it aligns with the cloud native computing ecosystem and the justification that they provide is first, it's easy to declare a development environment. And oh, by the way, it turns into a container. And then the second one is really that it's powered by Nix and that they're rapidly going to overtake Nix. Based off of like the things that I'm saying here about the project, I think the project is cool. Don't get me wrong. But I don't know necessarily that any additional information they provide about alignment and overlap with existing projects at this point in time would persuade us one way or another. Right. And they're also asking, how do we integrate Devbox with other cloud native projects? So they are redirecting it back to us. And we're going to ask them the same question and they are pointing back at us. Does anybody see how to turn it into a container? I remember seeing that there was a command line in a shell configuration. Because they said you can turn it into a container. I'm not seeing the easy method to do that. It's almost missing that part of it. Let's see. Which is the part that links it into the cloud native ecosystem? It's the thing I don't see in their docs. Yeah. So here I can get this one. I think Devbox build. I don't see it here in the reference. What happened to it? I can't see the cash one. Devbox build. I mean, it may just be the features that are inherited from Nix for building containers from Nix. And that's on the command line. In the interest of time and moving forward, I would recommend that either they actually really put the containerization of Devbox first and foremost of the project because that moves it closer to cloud native. But that doesn't necessarily guarantee that we would accept them because we've been down this path before about packaging things into containers doesn't automatically make it cloud native. Yes. Agreed. Okay. So for now, no. But they are welcome to reapply after figuring out some of the things that we talked about here. Okay. Let's go to Zot. Anybody take a look at Zot, Justin, perhaps? Yeah. I mean, it's been around for a while. It's kind of, I mean, one of the questions I have is why, you know, what kind of is the difference with distribution and why not add features to distribution and upstream rather than building something a new... I have a feeling that they got it in an acquisition or something. This is from Cisco folks. That would explain it because if you start digging into the contributor, some of their profiles list of non-Sysco companies. Yeah. So it might be, but I think they're OCI only and not traditional Docker. Yeah. Yeah. They said that very clearly. And they also said it's a single binary. So it makes it easy to run compared to the others. So I think I would like them to clarify the functionality difference with other image registry projects. I do not see that. And also they are code of conduct. And just says, you know, it follows CSF code of conduct. That's fine. Yeah. I think where Zot said it's different is they are an OCI spec only registry where the other registry implementations OCI and traditional Docker and their differences with Docker than OCI. That's kind of, I mean, they say they intend to be the reference implementation of the OCI distribution specification, but the distribution itself is, in fact, the reference implementation of the OCI distribution specification. And it always has been. The fact that, I mean, you know, the reality is that everyone implements some of the historical Docker pieces for compatibility reasons. But like that, it doesn't, it's just kind of weird to declare yourself to be the reference implementation of something that already has a reference implementation in CSF. Did they say reference? It does. That's what it says. Okay. Okay. But like, we've already got one. They do say that. I read it. Yeah. Hey, aspirations is not bad. I mean, it says the focus Docker distribution and go Harbor is the legacy Docker format, which is absolutely just not true. Literally, literally is the reference implementation that everyone's using. And it's where all the work on new features is prototyped. I think so. I just don't actually, you know, think that, I mean, then there's an opportunity for all these solutions to incorporate as well as a library or back in process. But none of them have, I mean, it just seems kind of, I don't know, just doesn't ring very. I'm not against it as a project, but it just, I don't understand it's where it's coming from. How many registries do we have already? We have the Harbor, like in CNCF. Do we have something else? We have distribution. Yeah. Is Dragonfly is doing that distribution called Harbor? Yeah. Yeah. Dragonfly. Yeah. Is that that CNCF too? Dragonfly? Yes. Okay. But Harbor is using distribution as well. Yeah, Harbor is distribution. Distribution is the upstream reference implementation. It's not a product. Harbor is more of a product and Dragonfly is an extension to support specific use cases. On a technical side, I don't see any reasons for not accepting, right? Like, yes, some of the aspirational pieces kind of definitely rubs the wrong way. And hoping that they'll play nice after they join. That is, if they have a well-diversified community, then that could be of use, useful. That could be useful. So in the interest of time, where are we going with this? Okay. I'm going to say on a technical side, there is no issues that we can see right now. So I think we should go for it, but they should probably tone down some of the things that they are saying here. Yeah, but that's not a caveat or anything. So I'm up for going forward with this. Any objections? Okay. We can move on. Okay. Parallels. Anybody got Parallels? No, it's on Parallels, please. I had that this was the open source portion of the RFA0, I'm probably pronouncing it wrong, Zero Trust Access Solution by the same company, and it seems super early for that project. So the thing that I remember from this one is they kind of help the people who are the platform teams from like letting different people access all the clusters that they have, which is a problem that we haven't really dealt with before in CNCF. So that was attractive to me, Emily. I saw a nice, did anybody else take a look at it? Yeah, this one. Yeah, I took a brief look. They've been around for what about a year. They've got about 500 stars. They seem to have a bunch of things already in order around code of conduct, governance, and all of that stuff in place for a project. So as far as operating as a project, but they have a low number of issues. What is it? 44 total issues. So they've had a low amount of traction there. They're only at like 60-some total poll requests. And although they have lots of commits, which makes me think either now or early on, they were just pushing the master. Right. I mean... So if we have to ask them to do something, what would that be? So I think part of the problem with the project is that they don't have a wide community base to actually open a bunch of issues, increase PRs. They're not going through their contributing guide and trying to look up whatever information I cut about the project. They don't have meetings to discuss the project and some of the roadmap planning to come up. So I think the project is valuable. I think there's more community development activities that could be going on. We can have excellent governance and documentation, but if there's nobody there to actually apply it or enforce it, we don't know how effective it is and running and managing those communities. So I can see this kind of going a little bit either way. Either they're too early and we need to see more contributions to the repository, more community development activities, or we bring them in to get them that. Yeah. I think this part of the problem is this kind of solutions would be like top-down driven right when the CEXOs want to make sure that their production systems are doing okay, then they put solutions like this on top of that to make sure that people who can only access, they lack, they can access only the things that they should be accessing. So that's probably some of the reason why they don't have a big footprint in the community already. Yeah. And I think they're also, are they developed out of India? So they're not developed out of... Yes, Rafi. They're not developed out of an area where we are much louder and more vocal with what we're building. Yeah. Yeah. It's a startup. I think it's based out of Silicon Valley for sure. And even if I look at the past three months, they've had six people contribute in the last three months, which is more than a lot of our other sandbox projects. Yeah. So you can see India and US, Karnataka, a lot of people from my home state back home. So that might be... We need to... I think if you bring them in, they'll do better. India traditionally open source is not like the open source we do here. Is there a reason not to? I don't see a reason not to. They are all when... They are running on all the clouds and... Sorry, Emily. I was going to say, like the only thing would be around the community, but they can get that through bringing them in. Right. Lots of things that we bring in don't have regular meetings to begin with. And being here nudging them. That's true. Yeah. Okay. I think I'm okay with them. Yeah. Okay. So let's... Going once, going twice, going three times. Let's go to number 12, Kepler. Who here is a Kepler fan? Kathy, did you look at it? Yes. Yes. I went through it. So it is used to improve energy footprint. It collects performance data, related data based on EBPF programs, and then aggregates this data with other stats. It pours those to promise this matrix. And then it uses the promise theorem, promise this matrix to train the machine learning models to estimate energy consumption by each part. So it said it's lightweight and it's little overhead. And it also integrate with the Kubernetes scheduler and the autoscaler to take the power resource, to take the power resource into consideration to support better performance and the resource utilization rate. So I think it's a very good project. So, sorry to be clear, which parts of this are applying to be in the CNCF because the the repo that they list is just the Kepler one, which is just the EBPF probes and not the rest of it with the ML models and the scheduler and those things. Or is it all of it? I'm just confused. That is something that maybe we can ask them. If they haven't listed it here, let me go look on the right. I mean, it just seems to be that just the Prometheus exporter and not the rest of it that's being that's listed here in the description and the repo and not the ML models or the scheduler or any of the other pieces which are under the same under the org. But I'm not sure because they're also called Kepler hyphen things as well. So it may just be that they're confused by our phone unless you put one repo. Yeah, I had that same question too, like the ML model is part of the what is coming in. So one data here is like the core repository is just the Kepler repository here. Okay, I think we can speed them up next time and let them answer that question like we want the whole thing and not just the EVP of probe, right? Yeah, so I took a quick look at this and I was assuming it was the whole thing. I think the same sustainability and it's good work. It's cross company. So we have more than one of our vendors already working on it. And I think it's a lack of clarity of what they're donating is the only issue here. And we want the whole darn thing, not just their exporter, which is what it looks like. So let's tell them that I've got language check for you, Dems. Yeah. Okay. Moving on to slime. Sorry. Moving on to slime. A slime, okay. So, okay, let's slime. Did anybody get a chance to look at slime? There are road map links to a problem. It's a 404. Okay. And going through the repo, it doesn't appear that they use inclusive language and their update cadence with Kubernetes is off. So this project, it seems a good project. It's a smart service mesh manager built on top of current service mesh to extend their core functionalities in a non-intrusive way. But I cannot see other links, you know, those in other each of the column, the links. Somehow I do not see those links. I don't know whether it's my own problem or not. Scroll down and see what I'm doing here. Oh, I see. Okay. One of the cells are is very big. Did I read it right that it's Istio only? It looks like it's Istio only. So they've got a bunch of dead links for us to evaluate and it's Istio only. Can I suggest they should come reapply with working links? And in the meantime, go see what the Istio project has to say about it, because it's Istio only. Subproject of Istio, just for due diligence. I would agree with that, but I would also add that they need to have a better update cadence with the Kubernetes project, because I believe the version that they're on is like towards the tail end of support. What, 122? I think so. Okay. It was over a month since I looked at this, so. Okay. Yeah, so let's not deal with them right now. We can move to the next one. Karina. Karina is a cloud-native storage system, CSS spec. It's an ops-free CSI, battle-tested kernel modules. Do they have an assessment from text storage saying they should be taken in sandbox? I think I have it in my notes. I don't see anything from... Excuse me. James, I muted you for a second. I'll mute whenever you're available again. Other conversations around Karina. Their website wasn't working for me. Am I the only one who saw it wasn't working? I can look after when I get home, but I'm pretty sure there was a reference to some text storage assessment that they had. Yeah, it's not working now. Okay. That website is supposed to be frozen, or maybe in a redirect loop. Yeah, Amy, so we don't have enough information to do this. We apply. We apply, and talk to text storage. But they already did reapply, and they did talk to text storage. It's not clear what they said in here, though. But it's in the minutes of text storage as well. If you check their minutes, there's a reference to Karina. They say it's there. They say they have a recommendation to be included in sandbox. However, you can find it in a minute of text storage. I think I checked at the time, but I can double check. Okay, so working links and come back, right? I'm not sure the website is that vital. Okay. It's only the website. I mean, no one ever gets an open source project website. So read me then. I think if we find the reference from text storage that says they should be taken, I'll see you then. That part is actually at the top. It does say comments and discussions have been addressed. Should we get recommendation from text storage to be included in sandbox? Okay. Then I think we should just go for it. We did get an okay from text storage. We don't worry about the website itself. Other than that, everything else seems okay. Okay, let's go to the next one. KO. So who loves KO here? Justin? I mean, I've not used it, but it's widely used. It's not something I've used myself, but it's definitely widely used, well-known, well-supported. It comes from the Canadian community. That's where it originated. Do I understand it right? That it basically takes, go program, builds it and sticks it on top of distrelis to create container images? Yes. I think it's quite popular. I've seen it in several places. Right. Now, one thing that came to mind for me about this was it uses distrelis, so it's single vendor in that way. What do you mean single vendor? The distro uses. It builds and puts it on top of distrelis to stick it in. I think it's originally released from Google, right? Well, yeah, yeah. It's a single vendor, yeah. Yeah, no, that's the only reason, the thing that I noticed was the single vendor distrelis, although I didn't look into, can you configure it to use other images? Here's your base. I believe that you can, but I'm trying to look for where. Advanced migration. Windows images, Star GZ support, OpenShift internal registry. Is that a blocker? Yeah, there is a link there about. Setting the base image. I see it. You're.ko.yaml file default base image. Okay, yeah, okay. So we are good there. Let's say any other objections or we can just go for it. Okay, let's go for it. So we already dealt with Cubescape. So the last item, thanks for everybody. We did not deal with Cubescape. I mean, we need to actually discuss like on the record here. Okay, fine. Cubescape, Armo, we got a response back from the folks who submitted the project and they clarified the questions that we asked. They are okay with renaming their service and doing all the other things that we had asked them to do in our previous discussion. And they just didn't want to do it ahead of time in case we still say no, then it would be effort that didn't get any results as such. But other than that, they're okay with the rest of the things. They, I think we were also talking about like switching the default of the CLI from their service. We were also talking about, hey, can folks run, set up a service by themselves and then use the CLI and they were open to all that as well. No issues there. Okay. I'll mark about being able to have, because we've done this before, around being able to make sure that the service and the product are slightly separate. Right, yeah. So their service should not be called Cubescape and Cubescape should just be a what is in the community or if they want to pick on the need. However they want to do that, but regardless, as long as it's two different things, yeah. All right, I will add that to our conditional. We can move on. Okay. I think we are all good here. So the last item on the list, Talos Linux. Who wants to talk about this first? Has anybody used Talos Linux? So I didn't, but the one thing which is kind of confusing at the bottom of the website, they are saying they are a member of CNCO, which it's weirdly undefined. They might be talking about the side arrow labs. They are saying it on the Talos website, not on the company's website. Here. If you go down to the bottom. Yeah. Yeah. Like I read it as the labs, but if they're claiming that, I don't know if they are being member or. So either the project is a member, which isn't the case, and then it's wrong, or they take the statement for their own company or from their own company, which would point towards being not really a mighty vendor. That smells weird, and that's the one thing which stood out to me. Got it. Anything other than that? I went through it, so it's a Linux distribution. Go ahead, Cathy. Oh yeah. It is a Linux distribution built for Kubernetes. There seems, I'm not sure whether, there seems no other similar part. But the thing is, do they have, I did not see a roadmap and their application, I do not see much information. Let me see if they have, I don't. Let me search for roadmap. So the. Go ahead. Sorry, they say there's currently no other projects like it, which I think I mean, there's no projects like it in the CNCF, but there are projects that are trying to do similar things. Yeah, so the company is a CNCF member, and I think that's what they're doing, because they're currently saying the project and company, it's coupled. They'd have to remove that when they decouple it. But the reason for it is, if you look at the reason on the screen there, they want to get the community to standardize on Taylor's Linux. And I don't think that's going to happen. Their motivation for being in the CNCF, I think is. I mean, that's very much outside our remit. Yeah, it's outside of our arena, and I'll be shocked if all of these vendors who do Linux distros are going to switch to this one. Again, this is aspirational. I'm like the way Matt. Yeah, it is. Yeah. I think I needed more information here, and it's just one liners. That, you know, definitely one sentence is rather every every cell is just one. Yeah, I mean, the documentation is very sparse about like the internals of how it works and what it's built from as well, which is kind of, I mean, it's kind of kind of light on what the principles and what it's built from are. I like how do you change if you want to add something? How would you do it? Right. Just says, okay, hardened by design. So is does it essentially mean don't touch just use? And like, I don't know if it's got some documentation on how to make some kinds of customization to it. Okay. But it's not clear, it's not entirely clear what the kind of extensibility principles are. Sorry. I think in their description, we really need some details about what are the enhancement or technology they actually introduce is to make it, you know, the idea always for Kubernetes. This is something we can really find it easily in the whole application. That is my rates from their documentation right now. Right. Yeah. I can't even see if traditional like CV scanners will work with this. Yeah, it's really hard to fail. What are the innovation points or what are the key, you know, change they actually did? It's kind of like just a single sentence description over there. I've got some wording in chat. I'm happy to be like convinced that I should do something different in chat. Looking, you know, yeah. And the way I was thinking about it is it sounds like what they applied with was more high level marketing one liners and we want some more technical meat. Clarification. That's fine. Yeah, I added one, one, a few more questions to me. Yeah, there's not enough information for us to make a make a determination at this point. So come back to us. Yeah. Yeah, I share the same view. I think it's limited to information for us to evaluate. Okay. Congratulations. I'm going to drop this over into private TOC as well for decisions that we have made today. Yeah. So we go there and do a plus one. Do a plus one over into private TOC in slacks that I have this like, you know, kind of like all put together and we will send this one out. Okay. Sounds good. It's the last time we have to do this. Yes. Richie, Harry, please don't forget. Okay. So thanks a lot, everyone. You know, we are closing the year, right, Amy? We are done. Yes. We are done. All right. Go have fun with your family. Enjoy the holidays and we'll come back refreshed and we'll get started again. Yeah.