 Thanks very much for coming. You can go ahead and switch to the deck. We're done with Andy temporarily, but leave his mic on and then Andy, you mute. And if you feel like coming and jumping in, just on mute and start yelling, okay? Sure. Okay. Let's go. All right. So there's Andy frozen down there mid-speech. This was supposed to be a nice little thing, but I had to kind of do a little bit of a video dance. We're here to build a Linux just for WebAssembly, Wasm, right? My name is Ross Gulachi. I'm a program manager at, well, I say program manager. I'm now a product manager, which means absolutely nothing in terms of change at Azure Core Upstream along with Andy in slightly different Andy is, well, I'll let Andy introduce himself in a second. So let's try and do this here. Uh-oh. We did not share audio, I don't think. So we're going to have to, do you have audio picked up on this, on this machine? Uh-oh. One moment. Yeah. It's over there. Apologies. I didn't think about this because I am not that good. And we'll try it again. Here. I'm going to just go push play and see how it goes. Hey, Ralph. Great to see you. And hi folks. I'm Andy Randall. I'm a principal program manager at Microsoft. Apologies. I couldn't be with you in person as I'm in Berlin, Germany right now. But we'll see if we can make this virtual co-presenter thing work. Right, Ralph? Absolutely. So thanks, Andy, even though you're still there, which is great. We're here because in yesterday and today because WebAssembly is pretty cool. And we like that. I'm not even going to talk about why WebAssembly is pretty cool because hopefully you're learning or you already know and are looking to discover new things. But there are still, because it's a burgeoning area, there are still lots of things that it's hard to do for your average, either developer or even people who are professionals but don't know about all the other work being done in the ecosystem. And so the whole presentation here is to help people discover some of those things because you want to find the stuff. You want to run the stuff. But in fact, even there's so much stuff that it is actually hard to discover. So we're trying to centralize that a little bit. If you can do that, you can spend your time building fun things rather than worrying about how you get it. Is it in the right state? How do you upgrade it and things like that? So that's what we're here for, right? And of course, there are how to ploy fleets and things like this. I feel like we've seen these problems before. If I were to get in a time machine and go back a decade to the early days of containers, I think we'd see a very similar kind of situation. Yes, sir, in 2013, Docker took this existing. Concept containers and really made them accessible. Yes, sir, in 2013, Docker took this existing. I'm going to let him run. Andy, I'm going to let you run, really made them accessible to developers for the first time, enabling them to build, package and deploy applications using a simple command line. In the context of the existing DevOps movement at the time, this really kicked off the cloud native revolution, the creation of the, the, the, the, the, the, the, the creation of the CNCF and the Kubernetes project to make containers deployable in auto scaling multi-node clusters. The criticality of this technology to the whole industry, right? Sound familiar? Led to the establishment of industry standards with the open container initiative, which alongside the CNCF ensured a multi-vendor ecosystem to really flourish. But even with these advances, containers still had challenges. In fact, just the same kind of challenges that Ralph was just talking about with respect to Wazen and deploying Kubernetes at scale was a challenge. So how do you manage a large dynamic fleet of machines with frequent updates, essential security patches, and, and why bring all the baggage of thousands of packages in a general purpose limits distro when all you want to do is run containers? What does that mean practically? What is a container optimized limits? Well, firstly, it's, it's a distro, which just has a very minimal set of components bundled in everything you need to run containers out of the box, but really nothing more. This has a lot of advantages in terms of reducing dependencies, all the things you've got to manage and your attack surface area, which is really important for security. The second aspect was an immutable file system. And this seems kind of counter-attuitive at first, because after all, in a, in a dynamic world, you want to be able to update things quickly and apply new packages and, but in practice immutability, by which we mean the OS partition itself is read only. In fact, there's not even a package manager. It's got a ton of advantages. It increases security because there's a whole category of attacks which modify the underlying operating system files, which are just automatically blocked. And it really is what allows you to start thinking of nodes in your cluster as, you know, cattle not pets in the old terminology. And what this enables, or another way of thinking about this is it's a, the provisioning model is declarative. What you define what you want on the node in a declarative config file, which is applied at the first boot. And what that means is that you can, you know exactly what's running on each node and you can reason about your fleet at scale, because you know if this node is a version X with this config, here is exactly what's on it. And lastly, one of the most important pieces here is the automated update mechanism. So when you've got frequent new releases coming out, security patches, etc., you want the servers to be picking them up, just like your smartphone does. You know, you don't really even think about the updates to your smartphone, it just automatically, either automatically updates overnight or it tells you, hey, there's an update, do you want to take it? It happens automatically, it happens seamlessly. You download the update, a reboot switches from one partition, the A partition to the B partition. And if that update fails, then it's trivial just to switch back. And if that sounds familiar, it's because it's also how Chromebooks work. In fact, CoreOS was initially derived from and inspired by ChromiumOS, an exact same update mechanism. So this model really quickly emerged as the best practice for running containers at scale. And so much so that pretty much every Linux vendor and every major cloud provider ended up building a distro like this. In fact, Red Hat, like the model so much, it bought the company, acquiring CoreOS in 2018, merged it with its own atomic host project to create a new distro, which slightly confusingly is also named CoreOS, but Red Hat CoreOS. And Google created very early on its own container optimized OS for GKE, actually very much inspired by CoreOS and derived from Gen2 and Chromium. And Amazon did the same for EKS with Bottle Rocket. And at Microsoft, we now have Azure Linux, which is now generally available for EKS as well. There are a bunch of other similar projects from Coniql, Suzer, others. But I didn't want to get more on the slide, but the key point here you see is that this is a model that really has gotten traction. Now in the team I work in within the Azure Core Linux team, we also work on a community-driven project called Flatcar, which is today the only direct descendant of the original CoreOS. So I won't tell you more about that right now, you'll be hearing more about it very soon and there'll be a lot more on it from Ralph. But first, so having heard some of that history from the container world, Ralph, how would you compare where we're at today in the evolution of the WASM ecosystem? Well, so thank you, Andy, for such a smooth presentation. That's actually our video flicker fault with the deck. So I apologize to Andy and to you. But we're going to use the same schema that Andy was talking about in terms of the ecological evolution in WebAssembly, right? And we'll start with the full developer OX, UX. We started with very limited compiler support, limited language support and various other things. And we've moved quite a bit in this category toward something like a full native experience UX. And I have to point out that even in Container Land, for example, the act of actually building the container is still not considered really a developer UX. The developer UX really still stops at the native compilation and making sure that that's all running, doing the debugging, and so forth. And then you have the package. And so there's still this kind of, we don't have what was a fully fledged IDE experience. And debugging, I want to point out, is not quite there. So I do want to say that this is kind of an orange circle and checkbox. We're making tons of progress, but there are still huge gaps in a really smooth developer experience. But I do want to also say that individual projects and companies have much more smooth experiences. It's just not widely shared yet. And in terms of the kind of vendor-specific things, there used to be in-browser-only implementations, and we're now moving toward general-purpose runtime environment. I'm going to call this a green. I would have actually, I believe that there was a vote on Preview 2 and Components today that was accepted unanimously. And so I actually should go and make that a little greener. Because with those kinds of standards, more tools, more environments, more runtimes, more languages will all be able to understand each other and use the genius, the knowledge, the embedded knowledge that's in the code in those languages already. So I think this is actually even getting greener right now. There used to be, of course, just Mozilla sandbox, Google sandbox, vendor-specific kind of things. But we're actually, like I just mentioned, moving toward industry standards. And that's not just the ability to do things outside the browser environment. It's also inside the browser environment. We already have good plans and know how to run various standards across those environments. I would call it a yellow right now. There's more work that needs to be done, but we know how it needs to be done, and that's really great. Finally, though, we still use general-purpose Linux, or general-purpose Windows, if you happen to do that. And the real question here is, if in containers we went move toward an optimized distribution, maybe we need to actually do the same. And that's what I'm going to show you. One way we might be able to do that today, we are going to build a Linux just for WebAssembly using FlatCar. And Andy talked about that just a moment ago. But we're going to talk a little bit more about the details, right? Why base an OS on FlatCar? Well, it's actually a really good way to do it. You've heard about what FlatCar is, what its heritage is, and so forth. But it's also community-driven. It's in process submission to the CNCF. It's widely adopted across the industry. It may not be the high-level distros that people are familiar with on the desktops, but the people who run operations in environments that are under heavy use in production, they do know about this and use it. It has a modular build system with system extension layers. We're going to use that today. And let's be real, we know it. So that'll be the last reason. So how do we make this real, right? There's a couple of abstract steps, and we'll dig into the physical steps. First of all, layers are good things. And so the first step is you got to create a layer for the tool you want to be in your distro, immutably. And that layer can be one tool, and here I'm going to show you lots of individual tools, each one in its own layer. And that's very useful because you say you want like, I'm going to show you like 15 tools. You can actually pull in the three you want. So that's why they're broken up. But when you get to production, you can make a layer with the three tools you're using, for example, if you wish to. So the second step is you're going to take those layers and push into some storage account of some form that you have access to that could be public. In the case of this demo and repo here, I've got public layers for you to consume right out of the box with multiple versions of as many things as I could compile before I fell over of exhaustion on Friday night. So that gets pulled in on initial boot. How? You're going to create an ignition file, which is a format. You can think of it as a first boot configuration. And it's going to tell flat car on the initial boot which layers are going to be built into this image immutably so that rolling forward when you boot, you only get those things. And it never changes unless you take steps. And we're going to talk about those steps. When that's done and it boots, it's fixed or baked. Then that is now an immutable image. Now for debugging, for use, especially if we're going to have a developer environment, you get to deploy neatly with QEMU. There's a really cool script trick. Works really fast on native Linux because QEMU is used there. I'm on Windows, which means I'm using WSL, which can be really useful for people, but it means I'm doing nested virtualization and it's a little bit slower. But it works fine. So it's very flexible. Anywhere there's QEMU. And hopefully the last step is to have fun. Just a word about layers. So I'm going to refer to Docker and the container ecosystem. If this doesn't make a lot of sense to you, grab me after or I'll be glad to back up and talk about layers and Docker and how that works. But I'm going to use the metaphor. And in Dockers, you build layers all in one file. It's a Docker file and you use a tool to take that file. It just builds the whole thing, all the layers down. Here, layers don't have to be just for containers. It can be just a file system artifact and it can actually be used to build one individual binary into something that's ready for a layer, like flat car. So let's say we're going to layer only with Wasm time. This is one of the recipes. Like I said, I've got as many run times as I could find on short notice before the flight. We're going to say Wasm time. And so if you take a layer with Wasm time in it on first boot and move it right in, the resultant image, which then becomes immutable, now has Wasm time already in user bin. In flat car, other container losses, mutable losses, you only have one user. You're essentially running as root, more or less. And that means that whether it's in user bin or user local bin, it doesn't matter. There's no Ralph home. Doesn't exist. So if you want to follow along with what I'm doing, just really quick, or if you're watching this after it's released on YouTube or whatever, this is my repo at Scolacci sys-ext bakery. Now this is a fork of the upstream flat car layer bakery, which doesn't have like four or five recipes. I've got like 15 recipes. All of which are web assembly related tooling and so forth. So now let's get concrete. What are we going to do with these layers? What do we actually do? Well, you're going to bake the stuff you're going to eventually eat. You need to bake the bread that you're going to serve somebody. That really means you're going to clean and download your binaries. You're going to create your new binaries, make sure that the build environment has what you want. You're going to put them in the system extension directory. And in that system extension directory, you're going to create the user local bin or user bin as I said, it doesn't matter because there's not multiple users here, right? And you're going to put your binaries into it and you're going to clean up any mess and you're going to create your raw layer file. That is the layer you're going to use. Now what's interesting about this is if you're familiar with Docker files, notice that one through five are pretty much that's what your Docker file is. So the only thing missing here from the Docker experience is that you know the from statement at the top of a Docker file. Now that is really a reference to layers that already exist. And so when you bake, you bake everything at once. In this case, you're doing the same steps, but the base file system, the base layer collection, is actually the flat car image you're going to deploy. And so those things already exist and you're creating a collection of layers that on first boot will be laid on top of that, rebaked into the final menu you've selected and that becomes immutable. That mostly makes sense. And if it does, because I don't want anybody to say it doesn't, that would be bad for my timing, right? The next thing you're going to do is create your layer file or raw file, okay? This is, if you notice, pretty much what Docker build does. The only difference is it's a layer and not the entire collection of layers, right? So the next thing you're going to do is you're going to take your baked goods, your bread or whatever, you're going to put it in the distribution truck so that people can consume it. You're going to upload your files to some endpoint. Here I have Azure Blobs, but you could put them in a GitHub repo, you could have secured endpoints in a private network. Like a lot of ways you can distribute this to your specific images when you're loaded. Notice that this is essentially pretty much Docker push, right? So the metaphors of what we're doing are actually using similar technologies in the same steps. The only difference is instead of building the whole thing first and sitting it on top of a kernel, which is what Docker does, you're actually building all the important stuff and choosing an image to sit those layers on top of. And that gives us a lot of power. So here's my menu for you right now, right? I've tried to collect as many runtimes. So I was chatting with Ben earlier. He's got some other runtimes available. Other people do. I didn't get to them. I want everybody to submit PRs with recipes for their favorite WebAssembly tools. I don't care where they come from. I'll bake them and see if I can host them. And as we go forward, the ones that become really solid and are used, let's move those up into Flakkar's bakery repository. So I promise to make sure that that gets done. You can see a bunch of runtimes. You can see popular runtimes. You can see app hosts like Spin. You can see tools like Modsurfer and things like this. Okay. So now you're on the other side. How do I consume this? Well, you're gonna need to choose the baked goods, right? You always serve other people first. We talked about an ignition file. I'm gonna show you what that is now. Let's make sure we got plenty of time. We do. And that's the thing that is the list of items you're gonna choose from your menu and set the table. Now, these are the details for setting the table. I'm not gonna rest on this, but this will be available. So this recipe will be there. This recipe is also available upstream in the Flakkar recipe repository. So what does these ignition files look like? I'm gonna, here's a simple one. Essentially what this means is I had to go get the image for QEMU, the Flakkar image. That literally is all I'm doing here, right? So those things are in the repo. So this is a very simple ignition file. It's already compiled out to JSON. You can author these in YAML and then convert them. So for those of you who love YAML, I'm sure it's the entire room, YAML is your preferred language. But you can see that what I'm essentially doing here is just saying there's a lunatic layer and it doesn't have any versioning. That's gonna be important when we talk about updates. And it loads initially a layer from this menu that I have in the sky. Now, it's always best to eat locally. As I said, I'm gonna use Windows and WSL. Linux, Windows, WSL, it's all the same process. The script I'm gonna use just grabs QEMU, creates a new VM and begins the boot process in the normal Linux way. But flat car is gonna do one thing first. What it's gonna do is first finish setting the table and serve the food, right? Now, do we want live demos or do we want, do we wanna risk a live demo? All right, I figured as much. All right, okay. Now, we'll pop this up a little bit, I think. We need to switch, do I need to stop? We need to switch to the live thing. So, I'm gonna go ahead and stop the slideshow. Is that what I should do? Huh? Yeah, I wanna make sure that everybody, no, well, everybody needs to see it up there. Because we flipped to, we're gonna try a live demo. And if we can't flip the AV fast enough, we're not gonna try a live demo, but we will. How do I know? Because I can see my screen, my monitor here, but I can't see it there. My apologies for not letting you know, we might fork the way the presentation went. Yeah, I wanted to mirror. Oh, that's all you needed me to do. I could have done that, yeah, that's fine. Okay, great. All right, let's bump this up a little bit so everybody can see. Right, that big enough? Okay, this is the list of recipes that I'm gonna show you. Not all of these recipes work because for various reasons I didn't finish all of them. So for example, there's an experimental wave runtime here. That doesn't work. I'm hoping that those involved in the wave project will finish off the recipe and give me a PR. I'd love to build that. The WebAssembly, the Wasm Edge doesn't quite work. It deploys, but I was gonna work with Michael and the team to get that one updated. So I'm hoping I'm gonna ask them for a PR. But everything else works fine. So if we go and clear that, we're gonna step back out to the Wasm Flak cards and we're gonna go to the developer experience. And the developer experience is gonna work like this. There is an image already there, but I'm gonna deal with that later. You can see I've got a couple of recipes. I've got a Whammer and Wasm Time recipe. I've got a Lunatic recipe. I'm not gonna build the Wasm Festival. It takes a little while on WSL. But who votes for Lunatic? Who votes for what? Who votes for Lunatic? Okay, there's two votes, three votes. Fine, you experimental people. That means I'm gonna do Wasm Time Whammer. So the first thing I'm gonna do is copy in that version of the flat car image right here. Right? And so now I've got that. And then I'm gonna go ahead and use this script, which is from, it's the script from upstream flat car. I'm gonna pass it in an ignition file, which is Wasm Time Whammer. And I'm gonna say, hey, just wire up the console. Oh, I'm gonna have to pseudo. All right, let's see if my cell phone can actually support this. Here we go. Now this should take about, in the normal case, takes about 30 seconds on WSL. Takes about 15 seconds on a regular Linux machine. You've already jumped in through Grubb. Now we're booting flat car. Right now, it's going up on the first boot to grab the layers I told it to get from the Azure Storage. This is just a public storage blob. You can grab them, do everything here. Here's where we get into the loop. So if the network is flaky, this holds up a little bit at this point. If you're on a good network, it just comes streaming right in. So I will not wait for long, but there we go. Now you have the joy of watching the boot stream. At about six to eight seconds, you'll see that it's close to, there you got the BTRFS. When it hits the EXT4 file system and amounts the file system, and then the layers are already pulled. So now we built the image with the layers in and turned it immutable. And we're in. Now, we did what? We did wasm time and whammer in the end? Okay, so now I should say wasm time version. And I've got wasm time, okay? And what's whammer? Is it I wasm? I think it is. Yes, it is. Okay, great. So I wanna just sudo rmf user bin wasm time. And the answer is no, you can't do that. We're fixed here. We're immutable. By default, this does not even come up with SSH capabilities. Once it's in, it's running. It is an appliance distro. And this is fantastic for sharing. It's fantastic for updates. It's fantastic for all kinds of things. And if you're gonna do a shutdown, you just do sudo shutdown. Now, power off, right? And we're done. Great, fantastic, all right? But notice, I've got a wasm festival, in fact, I've got a wasm festival repository here. So let's see where I am in my deck, right? I'm gonna make this professional. Now, I'm gonna go back to the deck. So let's do this, okay? To make it professional, what we just showed you is, hey, one layer, two layers. I have a one layer recipe with lunatic. There is a wasm festival recipe in there. That recipe builds an image that has every single tool in there. And now, whoever needs to start using those tools can just grab the distro, they're good to go. And they can use that to test which version of which thing they want later on when they get professional. But when you get professional, you're gonna want things like updating it securely, right? How can I zero in on, say, spin or lunatic or wasm workers or something like that. And have only that or my runtime or my lab tests, my training, whatever it might be, you need that doing. To do that, you update, keep it updated with something called Nebraska. This is the open source, you might call it the update service that a flat car has. So you can update flat car nodes. It uses the Olmahawk protocol and the update mechanism from Chromiumos. It works both with the partitions, the core base image, if you will, and also with the system extension layers that we've been building. You can switch between A and B partitions, automate, update, roll back, even hot-swapping the base image out from under the applications, these layers, without actually the layers and applications really knowing about anything that happened. And you can do the reverse. You have fine-grained control over the fleet upgrade and you have monitoring and visibility. And this is all really, really cool, right? I like it. So, as we get toward the end of this, I wanna show you the more professional experience, right? And for that, I'm not gonna do this live. It's a little bit small, but I'm gonna go ahead and do the demo because I wanna make sure that we get our time taken care of here, right? For this one, let's see. I think I'm gonna copy this in. Oh, no, I've gotta skip this one because we wanna do back, back, Ralph, back. Nope, that's Dev Flatcar. Hey, I swapped out the wrong video. I like it. So we are gonna do it live. You ready? I'm gonna go back here. We're gonna go CD up to the product directory. Here, we don't have an image yet, so we can boot from scratch. Oh, yes. And better, yes? Okay. So we have, we're gonna use a recipe that only has wasm time, but what we're gonna do with this recipe, right, is we're gonna do this. Code wasm time. YAML. And so when we show this, what I'm gonna show you is, okay, that this recipe not only sets up a configuration for updating wasm time. It tells me where to find the updates, right here in the path, right? It also tells me what kind of formula to use to match updates both with a wild card for version and with a wild card for architecture. It goes ahead and downloads one initially, and it says that version initially is gonna be 10.0. And so the rest of this is going to be, this is the key part. It's going to update every single minute. So this is, I'm gonna go do this demo. We're gonna build one more time. This will be the last demo of the presentation, right? And to do that, we have to, let's make sure we got, yep. So we're gonna do cp, cp, bring in the production image. I think that's right. Yep, okay, great. I just forgot the dot. Okay, I got it because my naming is long, but my fonts are big, so forgive me. And we're gonna do the same thing. We're gonna do sudo, flat car, I, right there, wasm time, JSON, no graphic, and I don't know whether I did it. Yes, I did it. I couldn't even see me typing and I successfully filled it out. And so now we're booting a recipe that automatically updates every minute by hitting the repo and doing a match for architecture and version for wasm time. And this is where, this could be a secured endpoint. It can do any kind of authentication you wanna have. We're now testing out the cell phone network again. I hope it boots at the same speed. I do have a video that I could flip to and show you how it works, but I don't wanna crowd the next presentation if I can avoid it. So I'm gonna pray to the networking gods here for one more moment. Please make this happen. Hi, everybody. How are you? I'm gonna count 10 seconds before I flip to the actual. Ah, thank God. Phew, okay. And now the question is, how long does it take to bake the layers? Okay, it's hit the layers and is it going to take another 20 seconds? This is the joy of live demos. Now I gotta count for another 10 seconds. Okay, one, work last time. Four, five, six, seven, eight, nine, eight, 10, okay, fine. So what I'm gonna do is go ahead and find the video. Right, and let's see downloads. And there we go. And I'm gonna jump ahead, right? Ooh, that is the wrong one. I have failed you because I have made the wrong, whoa. Okay, thank you very much. I'd like some applause. That actually worked. Now watch what happens. If I do a was on time version, you start 10, okay? 10 is installed. Wait for system D, because system D, we're all one user, system D and me are both core. If update works, we should see system D go out, check the update spot and find it on this network, my cell phone. I really deserve this, don't you think? So what I'm gonna do is actually clear to waste time. It's still 1.0. And how many minutes are we willing to go over? Come, help me, help me networking gods. So I'm gonna finish this demo. Andy, are you there watching me be tortured? I am there, it's very entertaining, yes. Yes, oh, great, I'm so pleased. This is actually the last demo. We have a rampant. The rampant's you intended. Yeah, exactly, yeah. So this is actually the last demo. This is merely the network not hitting the thing. I'm happy to show you how it works. It'll probably work perfectly just after this, right? But this is the price of a live demo. Does anybody have any questions about how all this is supposed to work, right? If we, let me know if we get some console log streaming from DMessage, right? Cause that's really, that's what's going on here in theory. Any questions about Flakar? Andy, I have a question for you. So with an update mechanism that I'm attempting to demonstrate, the Nebraska process, is it possible to do all kinds of authentication solutions to reach that, not just in private networks, but like, can you do a pre-PKI dance and things like that? That is a good question. I don't think there's a whole load of different mechanisms for getting, for authenticating. Yes. Thank you. So the interesting thing here is that at very least this can all be in a secure private network, right, like, and this was HTTPS, so like you've got the server side authentication and so forth, that part is easy. And so I'll work with Andy and talk to the Flakar community to find out about all kinds of protocols that can be added and layered in on top of that. But the critical thing here is now I've automatically updated it. So this is a device now, immutable. This can be sitting anywhere, and if it's disconnected, it doesn't matter. It keeps running and nobody can change it accidentally. So there's no state drift here, which is critical. And then if it gets connected, it will on whatever you configure, reach out and bring in whatever the update is. So the update activity now belongs upstream in that repository, whatever the repository is that you're using, right? So that's the critical aspect. And I'm hoping, let's see if I can pop back up here. Nope, that's the wrong one, right? So I'm hoping, let's keep going. Nope, there we go. How to play with Flakar wasm. Clone the repositories. Please modify any of the recipes, right? Submit your own recipes. Do you have a question? Okay. Yes, that is exactly what happened. And even more interestingly, what it did is it came and dropped the layer in where the previous layer was. And since the actual binary name is simlinked, right? It then swaps the simlink to point at the version. You could SSH, you know, I'm like, that's my VM. So I can't even modify that simlink. It's the system itself that is modifying the simlink. From now on, if I boot with or without an ignition file, I'm just gonna get what I got last time. It doesn't even matter if you press a new ignition file. It will not reload anything. You get what you get, right? But you can do updates and rollbacks. That's possible. Yeah, in the corner. Yes, so raw files do have metadata in the normal layer fashion. I do wanna say this. Please push layers and recipes to my repository. I will bake them, test them, then everybody can use them for fun right now. And as they get more useful for people, I will submit the PRs back to the Flakart community and then you can jump into the Flakart community or you can submit them directly. Feel free to do whatever you like because it's purely open source and purely community driven. If you're researchers, if you're business people, if you're building POCs, your own recipes will work here. You don't need my stuff. Now, that was a good question about layers, like what's really going on. Let me show you what's really going on very quickly until the team kicks me out, right? Which is entirely possible. So if we look at Lunatic for the sake of discussion, right? You can see that this is pretty much a Docker file only in a bash form, right? And there is an algorithm, as I said, you're creating a, you're grabbing the binary you want. You're creating a system extension name, a directory. You're actually adding where you want. It's a deployment to end up being. And then you go ahead and after you, in this case I'm moving it right into that directory and then you clean up if you need to clean up and you call bake. You're baking an image. This is the script that bakes it, okay? So the answers to all your questions are in this script. If you look very carefully what you go down here aside from the configurations and architectures and stuff, this is the sweet spot right here, right? That's what's going on, all right? That's the sweet spot. And it's just a script. These are just standard Linux tools and you're building a layer that Flatcar knows how to deal with. But the metadata you're talking about is the magic is in the system extension directory. That has a actual configuration. So for example, the extension, the layer I'm talking about actually doesn't have versioning information or architecture information in it. The fact that the files do is something that I do. I actually copy that in there and that allows me to use the kind of regular expression type thing to grab a particular version and update it automatically. But the extension itself thinks it might be updateable. So it just, you build that as a generic name, wasm time, right? Lunatic, spin, anything else. And then you can host it and your file name is how you pull in the update in a SHA sums file. They're listed all there and the update checks that. Any other questions? So I'm gonna let Andy wait in here. Andy, do you wanna, do you want me to play your video or do you wanna wrap up yourself? No, I'll just wrap up myself because really all I wanted to say there is I think we've had a lot of fun. So Ralph and I have just been working on this along with the flat car team over the last couple of weeks putting this together and just kind of seeing how it's all come together. I think it's really exciting because it is, as Ralph said, it's community driven. We feel like there's a need there in the Wasm community for something like this. And the fact that we can build this on flat car is just kind of a testament to the architecture that's being built there. So really looking forward to, hopefully everyone in the room here going and trying it out and letting us know where they want it to go. So thank you very much for coming. I really appreciate patience. Thank you to the networking gods for finally kicking in. I hate Ivan for having chosen the live demo version instead of the video demo version, but I think it worked out fine. I'll be out there in the hallway. If you've got anything, I will build layers for this all the rest of the day and push them up. So if you got something you want me to build a layer for, just come, it takes five minutes to build a layer. It's really dead simple, right? So just meet me out there, love to do it. Thank you very much. I appreciate it.