Well, this episode, I'm hoping, my two friends, to cover two topics. We'll see what happens. I always hesitate to label the live streams what we'll be talking about because in my experience, that doesn't always happen. And, you know, we end up doing stuff. But there's some hoopla, it seems, going on in the open source world at the Linux level, a level that I have very little familiarity with. So I know because you, Ben, actually know how open source works. And you work on Linux. So you might actually, like, have some more knowledge here. And then, Ed, you are paid to follow this kind of thing. So you two might be more wise about what's going on than my dilettantism. I tried to use that word with my son the other day while we were biking to school. And I was like, I wonder if he's going to ask me what that means. As if I, too, am a child who gets excited when I know some fancy word. But he was not impressed at all. Just acted like nothing happened when I said dilettante. Just kept going on. Didn't care. So I don't know if you want to incorporate that into the next episode of The Wobbly Life, Ben. But that might be The Wobbly Life dilettante. Yeah, are you still watching? Are you subscribed? I'm definitely subscribed. I mean, you know. Thank you. That's very kind. I don't always watch. I'm watching, I know. But I do enjoy every now and then when I peek into it, I'm like, oh, let's listen to that cute voice. That's great. It's like, it's a lot different than what I overhear from my sons, like, you know, watching streaming gaming stuff where they seem serious. Oh, we've got a blinder coming up. We've got a really good episode where we unlock some extras. So, yeah. Oh, some secrets will be revealed. Secrets. Yeah, yeah. Big one. It was very excited to record this one. It was good. That's good. That's good. Well, so the first item.
2:00And this, like I was saying, I'm looking forward to making sure I understand the stuff. Because, you know, I like to, as you can see in my show notes, which I don't know if I'll publish in our show notes. But I like to very detailed go through this stuff. And I think I'm more interested in the kind of reverse engineering, I guess, the strategy, but then also like the operational consequences, if you will. And now, correct my summary where I'm wrong, but you got Red Hat Linux, otherwise known as RHEL. And what's going on there is basically if you want to get the source code for Red Hat Linux, this is a little more nuanced. So maybe one of you can go over the nuance of it. But if you want to get the source code for RHEL, you have to either pay for a license or be in their developer program. And I think this is a change from it used to be you could just get the source code whenever you wanted. So there's all these, as I'm sure you can list off, Ben. There's all these distros of RHEL that are just free distros of basically assembling the source. And now you don't have to pay to get the binaries for it. And so changing this over, obviously, it's a big change in the way things are done, has caused all sorts of, I think, as the kids say, drama and things like that. But is that, first of all, is that kind of a fair summary of like what the switchover is, the policy? Do I have that right? I think so. It's quite a complicated topic, isn't it? Because it also goes back a few years. And I think part of the vitriol that you've seen over the last week or so is related to past injuries, where other decisions around things like CoreOS, for example, have upset communities, you know, Linux communities. And then, you know, that pain has never really gone away. So every time sort of Red Hat moves the goalposts in some way, they seem to be met with, you know, initially, at least, an awful lot of sort of resistance and derision.
4:06But it is, yeah, it's a complex story. It's got more to it than just one decision. It goes back through sort of a history of decision making, I think. Right, right. Yeah. And, you know, in the broader, we don't talk about this stuff a lot here on the Tanzu Talk, but it comes up on my other podcast, Software Defined Talk, a lot. Like, I think over the past, well, I guess it's like five years now, there's been all sorts of, I think, largely driven by the, you could call it, it's not a loophole, but the unanticipated capabilities that public cloud companies have with open source software. There's been a lot of trying to redo the norms and the legal language of open source software to limit what public cloud companies can do, right? And so there's been a lot of like tweaking and experimenting because, you know, it seems like ultimately in the, not ultimately, but in the open source world, one of the expectations, given the open name, is that basically you can get the code and run it for free and not have anyone mess with you, except, you know, depending on the license regimen that you sign up for. And especially when it comes to modifying the code and then, you know, renaming it and selling it and things like that, that's where the public cloud companies can do all sorts of stuff. Because I guess there's no trigger of distributing the code if you're just running it, which often in the open, in open source licensing, it's like, especially in the, the GPL, once you distribute the code, that's when everything kicks in. But I guess at some point, someone decided that if you distribute it over a network, that's not distributing it. So therefore, you're cool, essentially. Although, I wonder if, I mean, this is a total side note, if I understand what the web assembly is, that's effectively distributing the code down to a browser, right? But maybe not. So that's an interesting, fun thing to think about. Like, if you downloaded all of the code into a web browser, and you could turn off access to the internet and run it, it's kind of the same as actually downloading some app, even though it runs in a browser.
6:12But maybe we'll let someone else think about that at some point. Yeah, I think, I think Wasm is compiled, though. So it's not like raw source code, like a web page or some JavaScript. I think it's actually been compiled. Right, right, right. Anyway, so, yeah, there's all that going on. I think for me, this goes back like 20 years. If you think back 20 years ago, if you were a vendor of some software, there was always a risk that a vendor would go bust, right? So you'd be an enterprise, you'd go and buy some vendor software, like, you know, a database or a web widget, whatever it is. There was always a risk that you were buying into this thing that you didn't really, you couldn't really tell what was going to happen with the company behind it. So there was some risk there. And open source just became more and more popular year after year because it took away that risk. It was like, okay, well, all of our source code's in the open. So if anything ever happens to us, then you can just go and pick it off yourself and reuse it and expand it and fix any bugs that are with it, blah, blah. And that's how it all kind of started in the enterprise world, right? But then you fast forward 20 years, you know, that's not really a risk with Red Hat. You know, so the source code being in the open for them, I suppose from their point of view, they're now sort of seeing a different scenario where that openness is, from their perspective, being abused by folks who are doing very little other than repackaging the code and sticking a different name on it. And then shipping it in order to get around the fact that, you know, you perhaps would otherwise be subscribing to a REL license. Right. So I can sort of understand it from both points of view, you know, from Red Hat's point of view.
8:13It's like, well, if you truly need the source code, that's not a problem. Your subscription covers you and you can have access to all the source code. And that takes away, that mitigates the risk of, well, if anything ever happens to Red Hat, what am I going to do? Well, there's all the source code. You were allowed to have it because you're a subscriber. But the other folks who aren't subscribers, who are just using it to, you know, repackage it, stick a different badge on it. Yeah, that's not so easy for us to then keep pouring investment into that particular product. Because every investment that we put in, we only necessarily see some of the reward from that. You know, some of the reward goes elsewhere. So I don't know. I'm not trying to defend anyone. I'm just saying I can see both sides of the argument and they both seem valid. And now here's the part of this that confuses me and not confuses me as far as intention and strategy, but the mechanics of it. And that is, all right, let's see. Let's see. This is the first time I'm going to run through this with maybe some educated people's reaction to it. It sounds like the main issue is, well, there's two issues from what you're just saying, Ben. One is like, I would like to run REL, but I don't want to pay for it. And that's what, that's, I think sort of, like that starts to become not such a big deal. Because one of the points of running REL is that you, not only that it works, but that you get support from Red Hat, as with any sort of open source thing, right? So a lot of the kind of enterprises and organizations we would talk with, they're like, well, yes, paying for stuff gets you something, right? Like it gets you support, so that's fine. And so I don't imagine there's a tremendous amount of people running like REL that don't pay for it. I don't know. I agree because Red Hat already bundled up other alternatives that are free, like Fedora.
10:17Yeah. And then so, so, so there's that group. Now there's another group of people who are, let's call them like the community. And the community are both like people, like, like I'm sure at VMware, we're part of it. We support REL and we probably like want to certify our stuff. This shows the ignorance of I have with the rest of the company, which is embarrassing. But, you know, we, we, I'm sure we support various versions of it. So you've got to test with and try it out. Like, you know, make sure that stuff works as you would with any piece of software. And then there's smaller independent people, not in stature, but an organization size who, you know, want to test against it. We were playing around with your camera settings earlier, Ben. Maybe that person is like, I want to make sure it works on desktop REL. I don't know if that's a thing, but you know, all sorts of testing that people might want to do. So there's those people who are basically, let's call them developers and they want to test and certify what they're doing. Uh, against that versus the users of it. And so I think their issue is like, well, now I can't get access to the, the, the code without paying for it. Or, uh, there's a, there's another option where you can get a developer license, which is free to sign up for. And then my understanding is you can run 16 simultaneous machines with REL on it. I don't know if those are virtual machines or physical machines, but let's just go with machines. I could assume that you could have a big beefy physical one and run 16 virtual machines in it, whatever, simultaneously. And so like that, that seems. And the only reason, well, not the only one reason that would be annoying is if you were using one of these other, uh, like built REL things, which is not REL, but you know, the alternatives we were talking about, you've probably built out your, your pipeline and your, your build environment, all this stuff to like work with that. And now you would have to spend time to convert over to this other method of doing it, which gets us to the, why would you have to do this? And this is where I, I think I know what I'm talking about, but like, so normally if, so the
12:23other thing that I think they said is, let me make sure I get this right. CentOS, not CentOS, not core OS, which is another thing. But, but, but with, with CentOS, I think what the policy is, that's, I always get confused about the streams. Does anyone ever talk about right and left streams or is it only up and down? Like, just don't cross them. That's all, that's all I can. So, so it sounds like the new policy is that, so CentOS is upstream, which is to say it's where future development for, for REL is done. So at some point, I think twice a year, because there's two major releases for REL every year, it looks like, from my understanding, at some point, the, whoever's in charge of this takes the current state of CentOS and says, this is our May version. This is our November version. This is the major version that we have for this year. And then at that moment, CentOS is synced with REL. So you, you actually have like a code base of what the major version is available in the open source version. So in theory, on that day, you could take that source code and be in the same state that, that you would be today. But then the problem is, if the policy is that they only, I think sync is the wrong word, but if they only sync the code between their upstream CentOS and then REL, that means that, that in between time, you can't get that code, including, I would assume like patches and security patches and things like that. So like, basically you will, at any point, unless you want to pay for, use this developer thing, you will be like, let's say 60 seconds to six months out of date with the current, like the, the REL that people could have. So you wouldn't be able to fully certify your applications if the people you wanted to certify were on the most recent major release, essentially. And, and then that, that seems to be where there's like some annoyance, uh, that, that comes
14:24in among other stuff. But does that, am I talking crazy or am I somewhere in the right area of, of the mechanics of the stuff? So one area of confusion for me, which you, you might've done the research to answer this question, does any of this affect distributed binaries like the ISO? So the ISO that you would use to build your virtual machine or whatever, is that affected or is this just about source code? Yeah, I don't know. I don't know the space in enough detail to have done more research. Cause if it's just about source code, then it affects people who are creating distributions. Right. Right. Cause they want to, you know, stick a badge on it and say, here's my distribution and maybe add a few extra packages or even remove some packages, you know, depending on what they, what they want to do with their distribution. But if you're, you know, if you'll say like, you know, your earlier example, you were talking about, maybe I have virtual machines that I build out with Red Hat Enterprise Linux, right? You'd be doing that from an ISO. You won't be doing that from source code. Right, right, right, right. So that wouldn't necessarily be affected if the ISO is not affected. So it's an important point, I think, because it perhaps, perhaps sort of shaves off a whole bunch of folks who don't need to worry about it. But you would already be paying to access those binaries, wouldn't you? I don't think the, the real binaries were freely available. I mean, you can, there's lots of trials and like I said, there's this developer method, whereas the source code was freely available. I think that's the difference. So yes, if you just use, if you just consume rel as a binary, you don't care. You'll still get it however you've got it, I suppose. Right. And that's, I would assume that's why, that's why these alternate builds, you can easily get a binary from them because they've made the binary that, that I don't know how each rel ISO or binary is built. But I assume that the whole point of these alternate builds is that the, the, the ISO you would
16:26get from a paid Red Hat subscription. And then the ISO that you would get from one of these alternate things, it varies only by like name. And it's essentially the, the, the same thing, like all the way down to like default configuration and, and all this kind of stuff. And, uh, and so therefore like going back to, to, to my thing, it seems like people could still make those alternate binaries, but now they don't have like, but now they have to wait six months to get like perfect parody with, uh, with, with what the official rel thing is because there's only, because while, while, I mean, the, the, the way that, uh, development works is like, if you're doing a software release every six months, uh, which is what's going on in the, the CentOS thing, right? Like they, that's where the upstream development for rel is, which is to say the future versions of rel are done in CentOS, which is all in public. You know, you might decide in month two to like, I don't know, I'm going to be crazy here to like, make a point to just like remove IP four, right? Just like, we're going to remove that. But then you might decide in month five, no, we should put that back. So like, you, you know, you're, you're kind of messing around with what the features are in there. So if someone goes and uses the upstream stuff to build their distribution, it's not necessarily going to be what actually is in the major release. I don't know. I'm kind of confusing myself here, but, but that's the whole thing in reading through it is what, it would be one thing if, if it was as simple as like, now you can't get the source code so that you can build stuff. But then there's this whole thing, you can't get the code exactly, but you can get the code that from the future that, that, that will be the actual code, which, which seems really, I don't quite know as I think it was in the register article. They, they said, uh, uh, a way of thinking about it is it's a, a beta version of it, right?
18:29It's what, it's what will be used for the next version of it. But, but that, that makes my mind hurt as I'm demonstrating just looking at distro watch, um, according to, according to that website, distributions based on red hat, uh, there are 11, so there's 11 distributions affected most, most recognizable names from that list. I, I think, uh, Alma Linux and Rocky Linux, uh, both mentioned quite a lot, but there's only 11 of them, right? There's not hundreds and hundreds of them. Yeah. You got to wonder like, okay, you know, is it, is the policy just to stop, you know, just to make life more awkward for 11 other distributions doesn't sound like, I don't know if it's worth it, right, I don't know, it's, it's more of a philosophical problem in a way, as in people like the idea of open source, you know, free as a puppy, but it's the idea that you can create something and then a whole ecosystem can get built around it. And it feels like red hat going against that, right? Actually, if it's only 11 distributions, for example, who are rebuilding rail and making it available in other forms, other ways, none of them are, you know, $34 billion companies that haven't taken huge amounts of revenue off red hat. Um, so the argument has always been, well, they're just helping red hat, right? There'll be more people learning how to use. It's not rail itself, but it's rail compatible stuff. Maybe it's building tools on them. Maybe it's experimenting in ways that benefits rail as an ecosystem. And by clamping down on it, you're saying, well, we want our stuff and we don't want anyone else to add value as those companies would see they're doing. Um, and red hat saying, we're just saying, we don't think it adds value anymore. We used to think having that community around and other people, maybe just gaining familiarity, maybe just boosting the name. We think that'll help. Actually, we don't think that helps us.
20:29So we're going to stop it. And everyone else is, I think, looking at it and going, well, hang on, open source always kind of works that way. Like you put out Kubernetes, right? A core. Everyone comes up with loads of great ideas, builds around it. It, you know, what is it? The, the rising tide lifts all boats and red hat are kind of saying, no, it doesn't. Right. Right. And that's, I mean, a lot of people like that idea and just red hat who are big and have a lot of influence saying, maybe not, is a bit of a kick in the teeth to open source as a concept. Yeah. And that's like, that's, I mean, you're, you're, you're bringing up the, the, the, the tricky part of, of open source. I don't even know. It's not so, well, I guess you could call it community management is like, it's really hard to change the norms of your community once they've been established, especially for decades. Right. And, and, and, and, you know, it's easier if you, well, easier, it seems like mentally easier if you have, uh, when in kind of smaller communities, but like for huge, big ones that have been around for a while, it's just like, no, no one likes their, uh, remember that old saying their cheese moved? No one likes cheese being moved around, which, uh, which is difficult, but you know, I'm always sympathetic. It's, it's hard, uh, doing open source businesses or, or can be difficult, uh, especially if you can't change things around, uh, very often, but I don't know, maybe, maybe I'll get, I'll get someone, I'll get some more clarity on the exact mechanics. I asked my other community about it. We'll, we'll see, we'll see what they say. Uh, maybe, uh, maybe as a final thing, I'm running Fedora, right? I'm running Fedora on my desktop. I'm talking to you through Fedora right now. Uh, Red Hat Enterprise Linux is based on the Fedora. So, you know, it's an upstream for that particular project. So, so maybe that's, that's a, that's a good point to close out because glossaries are often in the back is like, so what is, what's the difference between a Fedora and, and a CentOS? I think CentOS as well, also based on sort of Fedora and looking at, it's a bit of a, it's
22:31a bit of a spider web, but they, they both sort of share some stuff. Um, I think I view rel as what they, what they basically add to rel in my opinion is stability. So, so Fedora is quite fast moving and of course, you know, things can occasionally break. So they test stuff with the community in Fedora and in the sort of upstreams of, of rel. And then, you know, with the, with the idea being that rel then becomes more, um, stable as a result, but perhaps doesn't have the same sort of bleeding edge features. Uh, so for example, Fedora was first to get the, um, Wayland, uh, window manager is recently moved over, um, the sound stack over to pipe wire, I think. So, um, they're the first to try out big new projects and try and integrate them into the desktop in a, in a useful way. Occasionally stuff breaks that way, but I haven't experienced that, but you know, enterprises might, so enterprises want something that's more stable and more proven, but perhaps doesn't have the absolute cutting edge features. Right. It's, it's, it's the future, the, the, the, uh, the, uh, the upstream where experimental stuff can be put in and taken out and also can be buggy, which for an individual makes it exciting, essentially get new features, get to play around with stuff. But yeah, CentOS is perhaps an alternative, maybe the problem there, not a problem, but one, one caveat being, um, it's because it's a stream sort of release. It's going to change quite rapidly compared to something that's got a slower release cycle. So you would have to be prepared for upgrades and things over time more often than you would with something with more stable.
24:32Right, right, right. You, you, you know, you'd want stability as you're saying. Yeah. Well, that's for folks, for folks used to Ubuntu world, you know, in Ubuntu, they have the LTS releases every two years, and then they intersperse those every six months with slightly less stable, slightly more cutting edge, uh, releases. Um, Fedora is only doing those sort of six monthly release cycle. It doesn't have a two year LTS cycle, for example. Right. It's just a pain we're all going to go through then. Cause I've just seen, this is Tansy talk, right? I mean, we, and probably most of our customers are used to very rapid churn. Things do not stand still long in Kubernetes land, right? You went from what, four releases a year. We've gone back to three releases a year. Now there's some moves to do long-term support in Kubernetes land. Maybe we're going to hit this same issue again of actually they do want slower, but everyone should be used to the CentOS way of living stream, regular patching, regular updates. That does seem like a concept that comes up every, every 10 or so years. Now that was to confuse it more. That was sort of the philosophy of core OS a while ago. I remember when I was an analyst, I talked with him and I forget the name of the person, but they had people from the Chrome team. And I remember them when they were first a company, they were very excited about the idea that Chrome would auto update itself. And they were like, what if you could do that for operating systems? And I don't know if that kind of panned out for like what core OS actually ended up doing, but it was a, you know, it was an interesting idea. And I don't know. I mean, you sort of have that for your desktop machines. Yeah, you do have that. Susie has a tumbleweed, for example, which is a build that does exactly that. You know, there's no such thing as a release. You just sort of get an ISO, which they've prepared for you. And then you grow it over time. You just, you know, run the usual updates. And there is no sort of release cycle with that. So, yeah, it already exists. Absolutely. Isn't that Windows nowadays as well? Like Windows 11. Wasn't that meant to be the last big release?
26:32And then it would just be constantly iterated. I don't pay any attention to Windows anymore, but I'm pretty sure they've all gone that way as well. It's definitely kind of like that. But I still think there are some sort of big bundles every now and again of new stuff. I think they did like a Windows 11.1, didn't they? I don't think they called it that, but I think they did, which added some new sort of stuff in there. I don't know. I think you're mostly correct, Ed, to be honest. I think that's pretty accurate. Well, I think we have a lot new fodder for me trying to figure out this situation here. Maybe over the next couple of weeks. Because it is, you know, like all of us, having been part of and followed the open source world for so long, it's always fun to see little experiments and things happen, see what goes on there. But Kubernetes and open source things, I think at least one of us, and I think that's Ed, knows a little bit, has read a little bit about what Crossplane is. Now, I know we do some stuff there with them. And also, I remember at KubeCon EU, they were interesting to talk with. But I haven't actually looked in and see what it does and, like, I mean, you know, it configures and runs some Kubernetes stuff, as it all does. But what's your take on what Crossplane does, Ed? What's the point? I didn't go too much deeper than you, to be honest, and I did much the same of chatting with people at KubeCon. But my understanding of it, so where I came into it from was, right, this is another kind of infrastructure as code and cross-cloud kind of way of provisioning resources in AWS, GCP, whatever. But it's all done through a Kubernetes lens. As you said, everyone wants a bit more YAML, so let's have a few more of them. And obviously, it extends the whole, you know, CRDs, let's load a load of stuff, load essentially some sort of object models, right, into Kubernetes and say, this is how you understand an AWS S3 bucket or something. And I sort of thought, well, I think people have done that, I say historically, but, you know, they've done that pre-Kubernetes using things like Terraform.
28:38And you can just have various providers and you sort of, I can't remember what the Terraform terminology for that would be, whether it's modules and things, but you could, in Terraform, just say, I want to spin up something. I'm going to write my code and then I can apply it to whichever cloud I need. And therefore, that's how I'm going to do a lot of my multi-cloud provisioning. And Crossplane just came along and said, we'll do that in a Kubernetes native way. So actually, you still write your code, but now it's YAML instead of HashiCorp's configuration language. And we will apply the extension in Kubernetes or a native part of Kubernetes, so that's easy. Terraform had to kind of create that from scratch first time around. And a lot of the declarative nature, which is what Terraform was good for, and they were sort of early to that whole, let's do it. It's declaratively, not imperatively. Well, that, again, is going to Kubernetes. So, again, happy days. And Kubernetes is rapidly becoming that control plane of home once. They, you know, started off just being, this is how you run containers. And everyone said, actually, you can do a ton of stuff with it. How about we have it orchestrate all these as well? So it's just kind of slotting in. And, you know, it can work with Terraform. That was another one, which, you know, several people pointed out. There's a ton of blog posts out there that show how to do it. So because Terraform is all over the place, if you've already got a ton of scripts that do a provisioning for you, you can just kind of stick cross-plane above them almost and say, you know what, spin up all these. And you can use some of the Terraform codes to do the actual mechanics, but we act as the orchestrator, just as Kubernetes is as good as doing. So you can have a bit of both better together if you've already got a ton of Terraform expertise, skills, scripts. If you don't, maybe you just start off with cross-plane and do much the same kind of stuff. And it feels like cross-plane are doing a lot of what I think Terraform did, where it all started very infrastructure-centric. And now it's sort of building up to, can you compose things? So can you actually say, like a three-tier app? In my very legacy part of my brain, something said, VApp, VApp. It's the whole idea of I want not just a database VM. I want a database VM and a middleware and a web app.
30:38Well, I'll put three VMs, tie them together, give them a startup order, blah, blah, blah. You know, Terraform did that with modules, so you could string things together into higher-level abstractions. Cross-plane lets you do the same kind of thing. It's all more flexible. Things have moved on a long way from VMs. I think most of our listeners probably have no idea why they are. I don't remember them very well. So, yes, that was my cross-plane in a nutshell. You know, it seems like, I mean, I have a general theory of, like, whenever the infrastructure, layer changes, you have to, not that you have to, but it's a common occurrence that the stuff above it is rebuilt to kind of, as I think you're indicating, too, like, think like the underlying infrastructure. So, like, change in the way that you think about configuring and running infrastructure when you have Kubernetes in there versus virtualization ways of doing it. And so, perhaps the tools that you want to configure and deploy stuff on it, they also change to kind of fit with that way of thinking. And so, if you have the old infrastructure as code thing where you're writing out, this is the way that I want things to be, now go out and do it for me, then it would make sense with Kubernetes that you have a whole different system there that people are doing. But that's good. But that would make it easier for me to read a little booklet and figure out what's going on there. We'll see if I actually do that. I like this idea of future me that I have. Sounds like a very proactive, curious person. That'll be good. But, you know, there's, I'll put a link to it, but there's a couple of interesting in our space, like a Forrester Wave and a Gartner Magic Quadrant about, like, about DevOps platform things. Like, like the, it's, I don't think, tell me if you agree with this, Ed, but it's basically the notion of a platform that your developers use to, like, build their code and even kind of monitor it in production.
32:41But these two types of platforms that they define don't actually cover the runtime environment, right? It's only, like, the tooling around the actual platform. So something like a Kubernetes or even, like, an EC2 or wherever you're actually running the code is not included in these definitions that Gartner and Forrester have of your stack. Yeah, pretty much. They're, they definitely sort of cross, they do cross the streams, Ben, I think, as you said, very dangerous thing. But, but actually, they are, they are largely around anything to do with the sort of development into production side of things. So that's why I look at the DevOps. Right. They are beginning to cross into some of those reports kind of cover the tooling for when it's in that, what you do. So a bit of it is around either do you do monitoring, like you said. So it's not, it's not quite the throwout over the wall of here's how you get your stuff in and then you can forget about it. It's here's how you get stuff in. How do you also manage it a little bit in production? So it's kind of all encompassing everything. I mean, it can be in a, it can be what's in your IT stack top to bottom almost. Can you deploy to Kubernetes? Can you deploy to a cloud? Can you deploy to mobile platforms? And how do you monitor it once it's in to know your code's doing what you said it would do? Yeah. Yeah. Within some realm encompasses everything in IT. Yeah. It's quite an ambitious ask to rate those kind of. Yeah. Yeah. I mean, they're definitely, they're, they're interesting to read through because it is, I think, I think this whole, this whole, everything we just talked about there, like is kind of, we're trying to read, not, we're trying to figure out what it is now. Like, like what a cloud native stack for that is. And so there's these, these two analyst shops have kind of a go at it and then explanation of people who are up to it. So that's, that's fun to look at. But I think, I think that's, I don't know. I'm sure there's other interesting news things that have happened, but that's enough for us to go over this time, I think. And, and as always, if, if you want to check out the show notes, things we've referenced, you can go to tanzutalk.com and find this episode.
34:41I'll put links to it. If you, we, we live stream these on the VMware Tanzu channel. If you're interested in that kind of thing, you can go look at that and you know, we'll see everyone next time. Bye bye.