 So Josh, thanks a lot for coming, for our interview with the car, right? It's kind of been wild. So we wanted to talk to you a little bit about, let's start with the, what's it called, contributors. Contributors, yeah. Yeah, so one of the events that always happens at the beginning of KubeCon is the Kubernetes Contributors Summit. Right. This is run by my CIG, my committee in Kubernetes called CIG Contributor Experience, in order to have a place for Kubernetes contributors, in this case about, it was 150, 200 Kubernetes contributors to get together and discuss what they're working on, in also two different ways. So we had discussions about the process of proposing major changes and discussions about, you know, whether or not we should change the platform that we used to publish the docs. Okay. And a big discussion in one of my personal favorite areas, which is the stateful application of the Kubernetes. Gotcha. Because it's always been a bit of a challenge. Although frankly it's been a bit of a challenge because stateful applications are always a bit of a challenge. Right, right. Yeah, the whole reason for that HTTP thing was to try to avoid that. So, yeah, so everybody gets together and we have all these different discussions throughout the day about, you know, and honestly for a lot of people it's just a chance to meet face to face because, you know, you're on Zoom calls in chat with somebody for like a year straight. Right, totally. And it's really super helpful for seeing people face to face. See, some of the university actually did a study and this was around, I think they covered the Linux and MySQL and PostgreSQL communities because it was back in the Outs. And they showed that the number of arguments on mailing lists decreased dramatically for like three, four months after an in-person event. No way, really? Yeah. Oh, that's so interesting. I still remember, like, and this is, you know, but I still remember a guy who worked on a remote team, team was all fully remote and this was like 20 years ago. So like, it was really unusual to have a remote team, but it was at Oracle and on a quarterly basis part of their commitment to, like, because they wanted this team to exist and be remote was that on a quarterly basis they put them all together in the same place for, you know, like a week, I would say. And I think it makes a huge difference just to, you know, get some of that in-person thing, especially if you've never physically met. It's even harder. Yeah. I mean, part of it is honestly it's just easier to trust other people if you've met them once face to face. Yeah. Yeah. No, I totally get that. It is, and I think that's one of the things that we're really experiencing, you know, with the pandemic and everything else. We're starting at the hang of. Well, that's cool. So tell me some more about stateful applications. So. I mean, aside from our opinion of the bot. Yeah. Well, this is a pain about the. So we were actually discussing this in the session, that sort of thing, talking about things that we still wanted to do in Kubernetes for stateful applications because we had sort of a couple of first cuts, which is stateful sets and CRDs and operators, but nobody is really satisfied with that because there's a whole bunch of problems with real life stateful applications that it doesn't leave solved, right? Because, I mean, first of all, they're all different kinds of stateful applications, right? Databases get a lot of press, right? But file storage, caches, information stores, authentication stores, there are a whole bunch of other stateful kinds of stateful applications that have different needs from databases and databases have different needs from each other, right? So you need this whole, this huge amount of customization, which led us to things like CRDs and operators, but the problem with an operator is that you are basically writing your own infrastructure software, right, or using something written for somebody else to attach that to Kubernetes, and Kubernetes is not really providing you with a framework except a place to attach that plug in. And so as a result, we have this whole marketplace of database operators and other stateful applications operators that are in what we call the operator framework level one, phase one, right, which is it's a sort of initial cut that is usable in production, but it's missing a lot of instrumentation and maturity and life cycle management and that sort of thing. And so the feeling really is that we should come up with a way within Kubernetes for Kubernetes itself to supply more of a framework for those other things. Right, right. We should be more involved with the infrastructure for operation in a sense, yeah. Yeah, and so one of the things I was thinking about is somebody who is a long-time stateful applications person with a long history in databases is that part of the problem here was, goes, proceeds Kubernetes, right, because if you look at before Kubernetes existed, before Docker existed, the stateless applications were already being fully automated through configuration management. And so in a lot of ways, moving those applications to Kubernetes was just a matter of porting the existing patterns we had in configuration management into the new world of container orchestration. Right, right. The stateful applications were not being automated by configuration management as a rule. And so there was no previous implementation to port. This is why you had so many database administrators who were really specialized in a particular database and everything else, yeah. And it was a harder problem, right? It was the reason why it hadn't been done yet was people were like, let's solve the easy problems first, which is exactly the right thing to do. Right. They just hadn't gotten to the really hard problems yet. Yeah, totally. And so you think that, so how or do you have any ideas about where that might land, like how would Kubernetes get more involved in kind of those stateful components without losing its own flexibility? Yeah. I mean, there's a lot of sort of separate areas to address. One of the ones that I personally worked on is resource management, which where I'm working with the people who are in runtimes, right, because now we have C Groups v2. We have more control over resource management on the individual machines, but at the same time, and this is another meeting at the Contributor Summit, right, the runtime people all met up, and by runtime I mean like Cryo, Container D, et cetera. They all met up to discuss future direction of runtime, and part of that was where should resource management live because a lot of how Kubernetes interacts with the container runtimes was built around Docker, and a lot of that was some really ugly workarounds because Docker was not designed to be controlled by an orchestration system. Now that Docker is no longer supported, they can get rid of those workarounds, and so the runtime people were discussing, okay, if we're getting rid of these workarounds, what should we be doing instead? Right, what does right look like? Yes. Yeah. So, I mean, it's funny because people outside Kubernetes look at it and they're saying, okay, Kubernetes is being used in production a whole bunch of places. You can use it to run a cluster with thousands of nodes, et cetera. Most of the big problems are solved. People are moving on to doing platform engineering and developing stuff on a stack above Kubernetes, right? So Kubernetes should be in maintenance mode now, and it's really not true, right? Because no, now we're going to do the stage of it's time to refactor all the things that we tried three years ago that turned out to be bad decisions. Right, right. Or kind of to your earlier point, right, also get to some of the hard stuff, right? You know, you made decisions early on to like, well, let's avoid this problem for later. Yeah. And now it's probably a good idea to actually address the problem. I think that's one of the things that I think is like, I appreciate about the Kubernetes project and is one of those problems that you see in a lot of mature projects is like, okay, when you're mature, do you recognize the fact that that doesn't have anything to do with being done or do you kind of just, you know, like keep making your mature thing faster, right? Like, I appreciate that. I think Kubernetes in a lot of ways is saying, okay, we've got a certain level of maturity. Now let's go back and address the next problem. Not how do we just refine the thing that we have? Yeah. Which is, you know, I think a much preferred route, at least for me. Yeah. Well, and I mean, I like Kubernetes' approach, right? And it's honestly one of the reasons why Kubernetes kind of won out over MISOs was that MISOs immediately went for the hard problems. The difficulty, the problem with that was you had to be a computer scientist with a PhD almost. To contribute at all. In order to use MISOs even for simple tasks, right, right out of the gate. Because it was addressing the really high-end use case. There wasn't a, gee, I have five nodes and I just want to run containers across those five nodes. Right? It was, with MISOs you were instantly going for the thousand node cluster. Right. Oddly I thought with MISOs actually is that, and it felt like they were targeting the individual developer in their early stage like, you know, here's how to get started or whatever. And I was always very much that in the sense of I feel like I'm doing a really heavy lift to get my stupid thing to run. Yeah. You know, and I just always thought that was kind of interesting. But yeah, so Kubernetes has been doing some interesting stuff there. That was, we were going to talk about, well, we were going to talk about history of Kubernetes a little bit. Yeah. Which I think would be kind of interesting. Because now, right, we're kind of saying, okay, here's the next, almost like the next stage of Kubernetes. Yeah. But if we talk a little bit about what happened before, you know, we're, at least I was joking around about, I've been doing container stuff since like 2012. And I think it's funny that you don't recognize that you need orchestration until you've like shot yourself in the foot a bunch of times with containers already. And then you're like, oh, now I get it. You know, so what, how do you feel about what's your, what's your interesting stories about the history of Kubernetes? Well, the, I mean, so one of the things for a lot of people listening to this who got into Kubernetes later on is that, like, if you look at it in retrospect, it was obvious that Kubernetes was going to win and become a default. Right. It certainly wasn't at the time. Right. It definitely wasn't at the time. I really thought Swarm was, was really going to take it for a while there. And well, so here's one of the things, because it was one of the goofy things, right? Is that you had Swarm, which was making a developer friendly play, right? Because that's what Docker was good at. Right. Right. Exactly. And you had, and you had Mizo's who was coming in from the high end, right, is we're going to run all the workloads, including the hardest thing we're going to replace Singularity, which was an orchestration system specifically for HPC, and that sort of thing. Oh, yeah, yeah, yeah. Yeah. Yeah. I've never worked with that. I think I've heard of it. And Kubernetes was in the middle. Mm-hmm. And the thing is, if you're in the middle, you never know if it's the, you only history tells you is that the happy medium, or the undesirable middle, right? Right. Right. Right. If you look at it a different way, like for example, if you compare this to my history of databases, right, when the new non-relational databases emerged on the scene, like MongoDB, et cetera, it put MySQL in a bad position when there were kind of sandwiched between MongoDB and PostgreSQL in terms of their market and being, and losing users from both sides. Right. Right. And that could have been Kubernetes, right? Mm-hmm. But it turns out that Kubernetes was the happy medium. Right. Right. It turns out that in fact, Kubernetes was giving people just enough orchestration to solve the problems that they had in 2016. The, and Mezos was too hard and too complicated, and Swarm was too limited. Right. Right. And, you know, and things could have gone a very different way. I think if DCOS had come out much earlier than it did, that might be what we're using now. Huh. The, because that was actually pretty nice. They solved a lot of the sort of UX problems that Mezos had by providing, in implementation of Mezos that satisfied a very common use case. Right. Right. Which one of these, actually I've talked about it in a bunch of these interviews. It's like one of the challenges I think that people who are deep, dark inside of like building, you know, Kubernetes or whatever is that it's so difficult to wrap your head around when you're talking, when you're building distributed systems, not having a visualization is very, very difficult. Because you, the kind of the goal is that you don't really know how the whole thing works. And sometimes as an engineer, you kind of need to get a tighter picture than that. And, but generating that from a bunch of ammo files is very difficult to do conceptually. Yeah. And, and I don't know the solution to that because the problem is that the visualizations in the abstractions are, are helpful, but they're also damaging if you follow me. Right. Right. Because the problem is I think people look at them as almost like reliable when they're, when they're not really, they're more like a hint about what's going on, not necessarily what's going on. Right. And it's like Schrodinger's box. Yeah. Well, and we have this problem all the time with relational databases, right, is that people would use entity diagrams, right, you know, or other ORM tools as their way into the database. And that was nice, but that's not how the data is actually being stored. Right. Right. And that's the gap between your representation and how it's actually happening. And particularly, particularly there's a tendency of abstractions to reduce distributed computing to sequential, to procedural logic. Right. Which it really isn't, it very specifically isn't. Or if it is, you're doing it wrong. Yeah. And, and this actually goes back to one of the hard things to teach people, which is, you know, how do you teach people to really understand concurrent execution? Right. Yeah. Because that was always, it was in the database world that was a battle for us, because all the time people would be saying, oh, we're trying to debug it and this transaction is doing this and this other transaction is doing that, next. And I'm like, no, no, there is no next. Right. Right. You have 16 cores in this machine, those are happening at the same time. Right. Right. And you can never actually determine the order in which they happen in any reliable way. Right. So, the, and then when you throw that across all which computers like we do for Kubernetes, that's really true, right? Right. Because you don't even have, unless you have a very expensive setup, you don't even have clocks that you can rely on for with any level of precision. Yeah. Right. The, you know, the, you know, if you're really looking down at the microsecond level, you don't know what order things happened in and that really needs to not matter, but it's, it's hard for people to wrap their hands around. And this is the funniest thing I find about this too, is that people also have a really hard time getting their head wrapped or an event driven architecture, yet event driven architecture actually simplifies most of this conversation. Right. Because you know the thing, the order of things because it's by when the event occurred. So you don't necessarily know whether this event occurred before that event, but you know that when this event fired, this thing happened. And then when that event fired that thing, you know, like, so I don't know. I find it easier to wrap my head around a distributed system when you think about it in terms of events rather than a series of like services that call each other. Yeah. Well, at least up until you need to debug something. Well, right. It's particularly something involving a lock. Right. Right. Yeah. Exactly. Yeah. I remember those nasty things in databases as well. It's, it is, it is the hardest thing because, you know, I fixed a number of bugs in post-president involving lock handling. Mm-hmm. And the, you know, the narrowing down the, the actually having to figure out the simultaneity of it. Right. In order to figure out what was going wrong. Well, and or, or like what's the cheapest lock you can get away with. Right. You know, that's the other big part of it. Looks like there's a race happening over there. Yeah, there is. We did go buy a soccer game. Yeah. Earlier, which I appreciate it. This is awesome. Yeah. This is really nice. Yeah. So thank you for taking me on this drive because that line was kind of my list for Detroit. Yeah. And I did not get over here on Saturday. Well, here you go. So, so yeah. So that's it. And that becomes a hard thing right for, because that is honestly right. There's a lot of, you know, sort of UI complexity for Kubernetes, right? Mm-hmm. Because honestly we're just getting away from the whole stage of developers writing YAML files. Mm-hmm. Right. Which is really not where we should be in terms of developer interface, right? Right. And we should be writing stuff in their own languages, and the YAML file should be produced by a tool. Right. Right. The, and we're getting that, right? Because we now have all kinds of UIs and code ready and we have now people are getting into serverless stuff. Mm-hmm. And, you know, which provides a more developer-friendly layer there, right? Right. But that doesn't take away from a developer particularly right if they're now getting into K-Native and serverless and event-driven programming, needing to wean themselves off of sequential thinking. Right. Right. Yeah. Yeah. I still remember like a guy I've worked with. It's funny. He's worked for me. I've worked for him. We've been peers, you know. It's kind of weird how that, I don't know about you, but I never expected that kind of thing to happen in my career. You know, but it's like I've had all of these relationships with this one person, but I still remember him like giving me a super hard time because of I had a racing thread problem in some code I had written. And it was like, and he was like, what, why, you know, why did you do this whenever I was like, yeah, and I'm looking at it and I'm like, you know, and past me was apparently an idiot because I looked at it. I'm like, yeah, there's obviously a race condition right here. And it's just always like wrapping your head around actual stuff that is, you know, truly multi-threaded or simultaneously executing or whatever is it's super hard and it's just so prone to error. And it's also very difficult to test, you know. So I think that's also part of the challenge. So you're enjoying the allow. Yeah. Did you notice? Oh, yeah. So there's a lake in the middle of the island, which I think is weird. He's like, if you think of an island, I expect there to maybe be a pond, but I don't know, a lake seems too big to be in the middle of the island. No, no, no. Because really, if you think about it, we think of like land and water as being separate and that's like a bathtub. But really what we're seeing there is the exposed water table. If I dug a hole underneath this road that went down by four feet, it would fill up with water. Totally. Yeah. It's actually the other way around. It's the land poking up, not the water filling in. Yeah. All right. So talking about KubeCon, so you did the contributors summit. Yeah. That was yesterday, right? Yeah. I don't know what day it is. The day before that, I did a little event called Cloud Native Rejects. Okay. It's a fun little event where talks are not accepted for the main KubeCon. Got it. Can apply to go there and they pick a sort of curated group of talks. Nice. And we go see them. And for somebody who's very involved in running KubeCon as a show, I really enjoy Reject simply because I don't get a chance to attend a lot of sessions at KubeCon. Yeah. That's right. Totally. Because I'm just way too busy with so many other events. Yeah. And meetings. Things and booth stuff and a bunch of other stuff. So plus, Rejects can have things that maybe don't have as broad appeal. Right. But as somebody who's involved in Cloud Native Development are much more interesting to me personally. Right? Yeah. Yeah, it's funny. As the more I get into something, I start to be much more interested in the more esoteric stuff. I think because it's like, that's the stuff I haven't even thought about yet. You know? I don't know. It's cool. I completely agree. I gotta check this out. I don't think I knew about that. Yeah. They'll be having ones before Amsterdam and before wherever we are next year in North America. Yeah. Cool. So... So that was what? Sunday? Yeah, it was Sunday. Gotcha. And before that Saturday I went to the Van Gogh exhibit. Oh, nice. The Detroit Institute of Art. It was awesome. Yeah, I really wanted to go. It was really amazing. Yeah. I've heard very good things about that art museum in general. The... Yeah, it's a really excellent art museum in general. And this exhibit was... I think it's the biggest exhibit of Van Gogh's work that has ever toured the U.S. Yeah, it's touring. I think it was either in Boston or it's coming to Boston. Yeah. Well, I think the museums are getting it are the ones that actually have artworks that are part of the... Oh, collection. Gotcha. So... Yeah. So they'll loan them out. Yeah, so it would not have... It's not coming to Portland, for example. Right, okay. So this was my one chance to see it. Yeah, so it was cool. Yeah, that's awesome. The... Yeah, and so then today is other sort of co-located events, etc. For me it was a whole day of meetings. The... And one interview in a car. And one interview in a car, right? And then I'm going to be going to the reception for a bunch of comments. Yeah, I think we're both going to that. Yeah. So I guess are we kind of answering questions or are we just kind of saying this is the table for this thing or... Yeah, no, it's for discussions. It's for discussions, right? There's a lot of people there who are implementing things. Right. And they'll have questions, right? And maybe someone will have questions about stateful applications in Kubernetes. Right? Exactly. So, yeah. And then the rest of the week is kind of being Kubernetes. So... Or being KubeCon. Right. Which is huge. I am not this year. Which I am just chuffed about. Yeah. Because... I can't... Like when I run the little conference I run the desktop, I can't imagine trying to give a talk of that thing. Yeah, no, but I had a lot of fun. I coached four or five different speakers for the KubeCon. Nice. Of whom three are brand new speakers. Oh, cool. And I really enjoy doing that. And I really enjoy us, you know, having new speakers, right? And not just the same people. Right. Giving talks all the time. Yeah. No, I definitely agree with that. It's... You know, it kind of goes back to... You know, I was talking to somebody earlier, Savita, maybe, about, you know, it's like, I think inclusion is important and a really good thing and it provides a lot of new perspectives. But in some ways it's also kind of selfish because, like, I want all of those new perspectives because it helps me. Yeah. Right? And, you know, you talk about like a new speaker when you have a brand new speaker, whenever they're coming with a new perspective that I may not have thought of before when they present, you know, some content that maybe I understand the content, but they're coming at it from a different lens, you know, and it just doesn't, you know, so I really like that. And it gets really important when we're entering whatever we're on right now, year seven, something like that, of Kubernetes, where... Like, we know that there were a bunch of assumptions built into Kubernetes originally that were based, that were circumstantial, right? Mm-hmm. And, you know, we had talks and contributor summits and stuff about, you know, ripping some of those out. Mm-hmm. But we're so used to them, we're not going to recognize all of them. Right, for sure. And having a new person show up saying, you know, hey, we could just do this thing instead. Right. And we're like, well, you know, hey, wait a minute. Oh, yeah. Yeah. Right, right. Yeah, oh, this thing is dumb. It's like that race convention, right? Yeah, yeah. It's like, you know, even if it's past me versus future me's perspective, it's still a different perspective. Yeah. But, yeah, when you have, I mean, so, you know, the beauty of open source, right, is the, you know, the many eyes thing. You know, but you've got to, there's a little bit more to it saying, you know, many eyes, you know, you actually have to make it possible, you know, for them to do it. And, you know, and the problem with big, you know, industry conferences, right, is they want to draw a crowd, you know, whether they're making a profit or not, it's still like, you know, a business, right? You want to have, when you run a conference, you want to have a group of people who want to come, right? And the way you get that is by having big name speakers. So it can be really difficult to also include, you know, brand new speakers, but otherwise you never get any more big name speakers. Yeah. Well, and one of the things I've liked about KubeCon is even as much as it becomes sort of a large commercial conference and stuff, they have stayed dedicated to inclusion and trying to attract new speakers and everything else. Right. Because like, two of the new speakers I was coaching are actually going to be giving keynotes. Oh, wow. Cool. Nice. Yeah. So the, and, you know, and that's not taken for granted, right? I remember back when I was working with some of the old IDG conferences and stuff. Oh, yeah, yeah. We had to fight them tooth and nail to get them to include anybody new. Right. Right. The, and so I really appreciate that as sort of a tenet of the sort of spirit of KubeCon, right, is that, you know, we are going to have change and we are going to have new people. Right. Well, it's, you know, it's like how do you get the next, you know, big name speaker if you don't give it any opportunities to new people. Right. Yeah. It's a, that's one thing I think KubeCon is really interesting for, I mean, you know, you even see it in the CFP process of like, you know, hey, you know, they ask you a lot of kind of relatively detailed questions about how, you know, how is this going to widen the Kubernetes community, essentially before they're going to choose your stock, your stock at all. Yeah. Which I think is pretty cool. One of the, the other sort of interesting things in the horizon that you'll see happening in the KubeCon program and stuff is, is wasm, of course. Oh, right. Yeah. Totally. The colors. Yeah. Really interesting. Yeah. That's one of those things where, like, do you remember when aspect programming first started coming in? Yeah. Yeah. You know, it's, you see it, it's mostly in Java these days, but it's the same kind of concept with wasm or can be. One of the, that's one of the models, right? Like Envoy uses. Yeah. It's basically they're essentially doing aspect programming except using a wasm to deliver it kind of along the wire, but kind of wasm being everywhere has some really interesting possibilities and characteristics. Like outside of the Kubernetes world as well, you know, just like, you know, your browser being running, you know, running like on the fly compiled language is interesting, you know. But so, yeah. So is there anything specific coming up with wasm that you want? Well, because right now, because we're talking about, because obviously for this this conference and that sort of thing, one of the part of the concern, you know, thinking about this is like, hey, you know, what about server-side wasm? Right? You know, WASI and that sort of thing. And then how do we run that on Kubernetes? Because we just had this whole like discussion with somebody at Rejects who's working on one of the wasm based platforms. Okay. And, and, you know, and they were talking about some of the problems that they're trying to solve for server-side. And I'm like, you know, Knative actually already does all of that. It kind of feels like we just need a way for Knative to run wasm. Yes. Yeah. To run your wasm because, because then you can just make use of their code to do all that management. Right. Right. The. Yeah. That seems very plausible. Mm-hmm. So, I mean, because ultimately, I mean, obviously, Kubernetes is designed to run containers. Mm-hmm. But, not exclusively containers. Well, right. I mean, people are, you know, the people are running VMs in it, right? Right. Yeah. So. Containers are the abstraction that we have. Right. And, and there's a lot of trying to reuse it to something that looks like a container. Yeah. But, but that's one of those things that you reevaluate all the time, right? Well, how much does it have to look like a container? Right. The, and, you know, and can we make other things that look sufficiently like containers? Right. That they can. Particularly, and, and not make it like bespoke, right? Right. Not make it something that has to be hand configured. Right. The, and up until now, there's been a lot of focused on doing that with VMs. Mm-hmm. Right. From the other end, because there's times that, you know, you want to use a VM rather than, a container. Right. You know, not just, I mean, a lot of folks have been in the legacy use case. Right. You know, where you have applications that are already optimized for VMs. But there's also other use cases where. If you want vertical scaling. You know, among other things, right, you, or do you have, yeah, you want vertical scaling. You have very rigorous information security requirements. Yeah. Where you need to have something that doesn't have side effects. Right. So I really like NRX. Have you seen the NRX product? Yeah. Yeah. Yeah. And the, yeah, and for that matter, right, if you want to link into CP level encryption. Right. You know, all of these sorts of other things. But there's no reason that we can't do this at the other end, right? Mm-hmm. And look at things like WASM and stuff and say, okay, well, on the one hand we can go sort of heavier weight than containers and have VMs that Kubernetes treats like containers. Right. It tends to treat the VMs more like pods. But what about taking, you know, basically a binary executable which ultimately a container isn't executable. Right. And... Well, especially with the more modern runtimes, right? Yeah, yeah. You know, it really is just another process. Right. And, you know, have Kubernetes orchestrate that as well, right? Mm-hmm. Because ultimately the Gordo Kubernetes is an API and a scheduler for a cluster. Right. And a lot of ways you can think of it as, hey, we're replacing the Linux CPU scheduler. Mm-hmm. And we're just doing it across a cluster of machines. Right. Right. I will say that's one thing that I am, at least that I'm aware of, right? There could always be lots of stuff that I'm not. But I don't know of a lot of people who are working on kind of new interesting schedulers for Kubernetes. You know, taking into account what came up earlier actually if, you know, like everybody starts their day at 9 a.m. so we want to do some sort of predictive modeling so that we spin up a bunch of engines before that so that we don't have a slow down during logging time. Yeah. People are waiting for some stuff to merge. You think? Yeah. There's been a ton of work on what's called the scheduler framework. Okay. Because previously, in order to do your own custom scheduler, you were writing, you were forking the main Kubernetes scheduler and writing your own in go. Right. And the scheduler, you know, SIG Scheduling said, you know, people need enough of this that we really want to make it possible to do this by basically plugging into a bunch of algorithms and changing waiting on things and changing configuration and that sort of thing to make it more possible to modify the scheduler in small ways and hence the schedule framework. Getting back to that bespoke problem, right? Yeah. The same thing that the operator is having, right? Yeah. But it's a natural transition, right? Right. Which is you start out with a bespoke thing that involves writing a bunch of go code, right? Right. And by people doing the bespoke thing, you figure out what it was you needed to implement. Right. Right. Exactly. And then you have a new generation and in that new generation I people do, you know, we make it a little bit more systematic and a little bit more reproducible. So, yeah, I totally hear it. Well, thanks so much for being on the show and taking the ride around to show it to me. Oh, it was very enjoyable. Thank you for showing me Bill Isle. Yeah. That was stuff.