 All right, I think I'm ready to start. I get the amazing spot of talking just before lunch. And I know how everybody's getting hungry, so I'm going to make this quick. I got 10 minutes. So first of all, my name is Mark Minier. I work for ARM in ecosystem development. So I sit on top of the actual team that builds the IP and work with software companies like those that are in this room here today to advance new concepts and projects into the market. So I'm happy to be here to talk to you all. So when we think about the Kubernetes deployments and everything that we've talked about earlier today, one of the goals that we're aiming to achieve here is the ability to create portable code. Like everything that we're talking about here relies on this principle for multiple reasons. One, the ability to accelerate your development, right? Creating your applications in the cloud and then being able to move that to your edge devices. But also in the cases where you need to consider migrating your applications from one device to another. We've heard a lot of talks this morning about different verticals that are picking up Kubernetes. You can imagine that a lot of those applications are similar and they're moving across the different verticals. And of course, the hardware that you're going to be presented with will look very different in these different verticals. So it's important to create portable code. It's also important to secure your code. Make sure that everything that you develop is secure. And that poses its own challenge. Of course, when you move Kubernetes applications to the edge, the surface of attack is much greater. So you do need to consider maybe putting a little bit more diligence on the security design of your system. And of course, you want to protect your IP. A lot of the discussions this morning talked about AI and ML. And when you think about the models that are created to draw that value from the data that's collected, you want to protect that, those models. So again, security plays a key role in these deployments. But of course, there are challenges when you think about these two goals that we're trying to achieve. Diversity of hardware is a big one. And that's seen on many fronts. The diversity of CPUs, the fact that the firmware could be different, the OSs can be different, and that can slow down development. And of course, when you're thinking about a Kubernetes deployment, these constructs sit below your deployment, but they're quite important. So I'm gonna talk a little bit about what ARM is doing to help bridge those gaps and the tools that we're putting into the market that help the developers overcome these challenges at the edge. The project is called Project Cassini. That's our umbrella project that centers on bringing tools to the market that solve problems around cloud native development at the edge. And this Cassini umbrella project has numerous programs below it. Here we're highlighting a few. ARM System Ready is the first one I'll talk about. It deals with, you know, in a nutshell, making sure that you can run an OS, a standard OS on any hardware. So the goal here is we work with our silicon manufacturers. We work with ODMs and OEMs. We give them recipes and guides to develop their devices, and then we test them in a certification lab to make sure that standard operating systems can just boot. And there's different bands of this program for different types of devices. You may have devices that use a device tree to identify the peripherals that are in the device, or it may rely on UCP, UEFI. These create different bands in this System Ready program. And it allows for flexibility, but it also ensures that the set OSs that you'll be expected to see in these devices are just gonna boot. Moving to the other side around security. PSA certified is the foundation. When you see a device that's PSA certified, you can be assured that it's following the best practices around security, that there's a hardware root of trust being used in the system. And that helps accelerate industry-specific certification work. If you're dealing with NIST or any other certification body, chances are they're familiar with the PSA certification program, and that can help accelerate your steps into those certification bodies. I'm not gonna jump over PowerSec. I've got a slide specifically on that one, but to wrap up this slide here, when we think about these programs that are created, we drive these into the market through proof of concepts, through blueprints that we do with the community. So these projects are there to serve the community, and we work with you guys to try to solve specific problems leveraging these tools. Now, as I mentioned, PowerSec is one that I skipped on the security side. What PowerSec does, I think, is a little bit more applicable to the folks here. It exposes a standard set of APIs in various languages that connect down to the root of trust in your system. So the idea here is we're creating an extraction layer that allows you to connect into various hardware roots of trust that use different APIs to accomplish security functions that you need as a cloud native developer. Now, we're not aiming to expose every feature in these different roots of trust. What we do with this program is we focus on the security functions that you need as a cloud developer, and we only expose that set of functions in a way that is easily consumable. So when you look at the front-end client for PowerSec in Java, it's going to expose the security function in a way that Java developers would wanna see them, how they would use them. And that greatly simplifies the complexity around dealing with hardware roots of trust. Now, another advantage of PowerSec is if your application, your security functions, need to be ported from one device to another, you can change the back-end and never have a change, no impact to your software above PowerSec. So PowerSec truly abstracts the interface to the hardware root of trust in your system. This program's been in development for two and a half years, it's ready. There's a lot of these back-end primitives that are supported today that are up and running, and there's a number of languages above PowerSec that community members have created and validated. Now, how do you take advantage of these programs? Well, for one, when you think about system-ready and PSA, you'll wanna look for those programs. You'll wanna work with your suppliers and make sure that they're following those best practices and that the systems that you're looking to deploy on have these badges. That will just simplify your process to stand your applications on top of. You should accelerate your development, should make sure that your systems are secure. When you think about PowerSec, look for those interfaces. It comes pre-loaded in a few distros. We're working with distro companies today to integrate further. In the meantime, there's an easy script you can run to install PowerSec, and then it's just a matter of configuring it to the root of trust in the system and then exposing the client interface that you want. This is something that I think you will likely be experiencing in your deployments at the edge. And then the final point is, come and see us. We're on Slack and CNCF. We've got the code for PowerSec and GitHub, and of course, these projects are part of the CNCF, so they're all open, they're multi-architecture. They're available for you to use. We'd love to hear some of your use cases and see some of these deployments out in the field. And that concludes my talk, so very quick. I promised I would deliver in 10 minutes, and here we are at 1209. Thank you. Great questions before launch.