Hello, thank you all for coming. We're going to talk about from the desktop to production building applications everywhere. Hi, my name is Matt, Matt Farina, and this is Ray. We work at SUSE on some fun tools that you might all want to use. The first thing I want to talk about here is that development happens on the desktop. The advent of so many different kinds of technologies, you just see that developers are able to get on their workstations and code away. Same thing with DevOps and just different technologies like this. This slide shows you some results from the Stack Overflow Survey, the most recent version. You're going to see I zoomed in on professional folks and just everybody to look at it. You can see IDEs are everywhere, text editors are everywhere. I'm still shocked at the number of people who use VS Code, but you can just see there's a long list. If you add up the percentages, it's well more than 100% because people use multiple tools. But you can see the desktop is a place where a lot of stuff happens. And you can even see with the new computers coming out, the amount of power in them, what you used to not be able to do on your local desktop environment because you didn't have the resources, you get more of that now with the latest systems, whether you're on a Mac or even in Intel chips and AMD chips with the latest processors and the ability there. And yes, there are online editors. This editor here is a snapshot of what you get on GitHub. If you're logged into GitHub, you can just hit the period and get right into an editor or go in and you get an online editor. And there's a number of these out there where you can code online. You can even use an iPad with a keyboard and do certain things there. But the reality is, is still most of the work happens on desktop machines, even with the power you're getting here. And as there's more power in the desktop, it's easier to do that and cheaper than ever. In addition to editors, you also see things like what tools people are using. And here I went back to the survey and I said, okay, what other tools are they using in addition to their editors and other stuff? And right at the top, you see Docker. And this is just Docker itself, whether you're getting into containers with Container D and Nerdy Control or you're using Podman. There's this huge swath of people working with containers now. And you also see Kubernetes fits in the top 10 too. And there's a lot of people using Kubernetes. And a lot of the people who are using Kubernetes don't interact directly with it because they've got some kind of platform built on top of it where they don't need to think about Kubernetes. And so you see this containerization mixed with your desktop environment, but also needing to be in the cloud. It's everywhere. So developers are using containers. And this shouldn't be a surprise if I go back to 2016, right? Over seven years ago, you had Docker desktop show up. And this is the earliest screenshot I could find of their website, the earliest thing, using the way back machine to go back in time. And back in the summer of 2016, Docker desktop came up with a native Mac app and a native Windows app. And developers were able to start doing things right in their native environments at that point in time. And you had it for Linux. You were using the terminal, things like this. But this introduced it to areas where you didn't natively have Linux in the desktop environments that are out there. And so it's been around for a while. But it's not just containers that have been around for a while. Desktop applications have been around for a while that lets you do Kubernetes. And here I picked one that has been around. It was around for a while back in the day. And it's not around anymore. It's CubeSolo. And CubeSolo was a Mac desktop application that brought Kubernetes to your desktop. And people use that for a while, and it was well loved. In fact, they even had a counterpart where CubeSolo was a single Kubernetes cluster. There was one that let you have more than one Kubernetes cluster in your desktop. So you could test out these multi-cluster architecture tools that we're going to deal with this. And that was popular for a while, but it ended up being deprecated. And they sent you to other tools to use, other things to use. And that desktop application, right? In your desktop world, people like desktop applications a lot. And so we see that. And so we entered this phase in Kubernetes desktop history, where we went to the terminal applications. And people worked in terminals a whole lot. And we'll explore that in a minute, but we kind of backed off the desktop application that developers like. And if you remember from a few slides ago, you had VS Code at the top, right? I'm sorry to say it wasn't Vim or Emacs or Pico or something like that. People like those desktop editors, right? And Visual Studio was right behind that. And you get things like Sublime Text and Atom. Those visual editors are the kinds of desktop applications people like. And so we went into the terminal-based app.  Minicube is a Kubernetes sub-project. And it has been actively developed for a long time, right? And the primary way it works is by using Docker under the hood, right? It expects a Docker socket. It works with a Docker socket. It can use other tools, right? On Mac, it can use Hyperkit to create a virtual machine. But that even gets into some shaky grounds these days because Hyperkit hasn't been developed in a while, and it hasn't had a commit in well over a year. And that's the interface on Mac OS to create those virtual machines. And on Windows, if you're going to use it there, you have to have some outside tooling in order to get that virtual machine things up, right? Like something like VirtualBox. Or you have to be using Windows Pro and have its built-in capabilities with VMs in order for it to work. And so there's all these outside expectations in order to even get up and running with it, which is where I need to sidebar on Windows for a minute. And I'm curious, does anybody in this room use Windows as a development tool, all right? I don't see a lot of hands here, but the reality is a lot of developers use Windows. It's still the majority, and you can see that here. And they're not even using the Windows subsystem for Linux when they do that. So when we go out and we want to create local development environments for developers, we can't just think about, you know, Linux desktop or Mac OS environments. You have to think about Windows as well, especially in companies where maybe you have a mixed environment. Some companies are letting people choose between Windows, Mac, and Linux as their desktop. And how do they all develop together? And then there's tools like Kind came out, right? And people in here may be using Kind as their development environment, but it was actually designed to test Kubernetes, and it requires Docker again, right? And if you're using Docker desktop these days, you know about the licensing and things like that. It's not free and open source software. And of course there's something like K3S and K3D. Again, more terminal tools. Again, requires a Docker socket in order to work in any of your environments. To have that Docker socket, you have to have a Linux VM setup. If you're on Mac or Windows, you've got to have all those things. So what about a Kubernetes desktop app, right?  And most people probably know Docker desktop. I hope you all know Docker desktop, but this is an older screenshot from their blog. And one of the things you're gonna see is, it's very basic in what you can do for Kubernetes. It gives you Kubernetes, it gives you the latest version of Kubernetes, usually around the latest version of Kubernetes, and you get to run with their selected version of it. And you get a few kind of settings around that, but it does provide a Kubernetes environment where you can work. Of course, it also has licensing things where if you're at a company, there's stuff like that. But if I think about it with Kubernetes, you're not using the latest version probably, right? If I look at the public cloud providers, usually the latest stable version is probably the oldest community supported version. Companies are usually behind in versions of minor versions of Kubernetes that they use. This is a screenshot from the Kubernetes blog a few years ago, and that highlights the versions from back there. And at the time, you can see two minor versions back was peak usage, and this isn't unusual. And so you take a Kubernetes desktop application, and if it's on Docker desktop, then the latest version of Kubernetes and you're using an older version, you may run into differences. In fact, I've actually run into bugs that showed up in my Kubernetes version that was in production that I didn't experience in my desktop environment. And so everything worked great in dev, and then you moved it to production and something broke because of a bug or an API addition, something like that that had happened that I was using I didn't know about. And so this is where you can kind of run into some issues, right? You want to match your development environment. You want to match your QA environment with production. And a lot of this is what led us to create Rancher Desktop. And this is one of those things a few years ago that I started. Rancher Desktop, the idea is to be able to have a Kubernetes native experience, right? If you're gonna work with Kubernetes, develop for Kubernetes, do container work, things like that. In fact, it started as, start with Kubernetes. And so it's got container management capabilities we're gonna touch on in a minute, but it started with the Kubernetes part of it more than anything else. And here you can see on the screen you can pick your version of Kubernetes and you can choose any version of K3S that's pretty much out there and switch between them. And so you can match that development environment with your production or wherever you're gonna go environment because creating that native experience is one of those primary things that I wanted to have as a developer so I could get past those bumps in the road. Now the way it works is you've got a desktop application that runs on Mac, Linux, and Windows. And the way it works is on Mac and Linux it's using the Lima project which uses QEMU under the hood although they're starting to work with some of the native Mac virtualization and you've got either container D or Docker D and Docker D is provided by the Moby project and then you've got Kubernetes K3S layered in on top and K3S is the version of it you wanna work with. And then on Windows, it's actually instead of wrapped in a VM it uses the Windows subsystem for Linux which Windows kind of manages the VM for you and you can get in there, tinker around, things like that. But it also means you don't have to have a version of Windows that has extra virtual machine management on it. You can use it on Windows Home. You can use it in the basic environments. You can use it anywhere. And then we bring in K3S and we provide a handful of tools and other things that I'm gonna show off here in just a moment. So let's do some demo stuff because I like live demos and let's see how this goes. So we have Rancher desktop here running and there's a handful of things you can do. You can see containers. You can do port forwarding images. You can take snapshots of your environment to restore from.  But let's have a little bit of fun here and tie things together. So I've got a demo code base here and I'm gonna open it in VS code. And let's see, can you see that? And one of the thing that prompts me is if I wanna reopen it in a container and that's because you have something called dev containers in VS code. And dev containers let you work inside of a containerized environment. And this is one of those things that I find really helpful because as I work on teams where I'm jumping between Windows, Mac, Linux and you wanna have the same development tools, same development environment, you can containerize that and you can work inside of a container. You can supply those tools. It doesn't need to muddy up your system. If you've got a specific version of Node.js or Python and you wanna tie to that, it lets you couple those things together and then share that environment. So let's go ahead and fire this up and see what happens. And so I go ahead and this is a Go application so I'm gonna run it. And it detects, hey, there is, it's opened up a socket. Do I wanna open this in a browser? And I can, hello world. What it does is piped out and it just works and ties in with the local system. And here we're using, it uses a Docker socket because I set Rancher Desktop up to use DockerD provided by Moby with the Docker CLI so it's the same tools you're used to. But you can do those things. Now I can come back here and make a change, save it and run it again and refresh. And it changes right here. So I get a local environment where I can develop, I can see things using my native desktop tools, tie these things together but it's a containerized environment running in there and everything's tied together. And this is useful when you wanna do this because if I take the same environment over to a Windows machine and pull it up, I'll have the same tool set, same everything, right? And this is powered by containers. Now with dev containers, I can go ahead and a dev container, in this case, I specified it with a Docker file. You can have a container image you wanna share. And for the Docker file, I am using the Slee BCI, the base container images that we use at SUSE. And I just tell it to install a few tools and then everything else just works. And so this is a slim, small base container image and it can create that environment. Now let's go take this and take it over to Kubernetes. So I have a Helm chart here and I've got that Kubernetes cluster running, right? And so I've got a Kubernetes cluster running in the background through Rancher Desktop and I can install this. First, I'm actually gonna go build this into a container image, sorry. In this case, so I'm gonna go ahead and build a container image here and this is taking a base container image, it's building it, it's done because I downloaded the images and so it built my thing into an application here. And so I've got a Helm chart here for my application that I've been working on, right? And I haven't pushed this container image anywhere but I wanna work with this in the local environment. So I'm gonna go ahead and install this and I'm telling you to use the latest image tag which is how I just built it to be. So this is gonna install Helm as a demo and it's going to be over here. Now I wanna go ahead and work with that. So what I can do is I can come to port forwarding and I see my applications here, right? And I can go to port forwarding that application I just started is here and I can forward it. It'll give me a port, I can select myself or I can just go with it and then I can take that port and I can work with this. Now since this is all in the local environment, right? If I go make changes to that and I kill the pod and it refreshes, it'll actually grab the latest container image. So I can do my development, I can kill it, I can refresh and everything's right there and it's all tied together in my local environment and this works this way on Windows, Mac and Linux. Now I don't just have to do this, right? I can go ahead and do some other things that are really useful. Like one of the things is with Kubernetes I always want to test, right? How does that, my application handle the Kubernetes upgrade, right? When I change versions, what's going on? With Rancher Desktop, I'm running one version. Let's go to another version and see what happens with my application. So if I change the version and I get newer version of Kubernetes, it'll upgrade it because Kubernetes can upgrade. You can't go backwards because of it. So let me go ahead and do this. Now what this is gonna do is it's going to, sorry, this is warning me that VS Code can't connect to the Docker daemon right now. And so it's thinking we'll give it just a minute, well this is restarting. So it shuts down Kubernetes, it goes ahead and upgrades it. Now we don't ship every version of Kubernetes with Rancher Desktop. What it'll do is on the fly, if it doesn't have it cached locally, it'll download it. It'll be pretty quick here because I didn't want to do this over a conference wifi and so I pre-cached it, but any of those versions are available because it downloads it. So here, it's starting up the virtual machine, it's going to bring up the new version of Kubernetes and those same applications are going to be right there on top of it so you can see what that environment is like. And so it's starting the backend up and that's where it'll bring up something like DockerD. Now while it's doing this, I'll actually show you around some of the settings here. So you've got things like Kubernetes, you can also set your container image between containerD and DockerD provided by Moby. DockerD lets you use things that require the Docker socket like VS Code and those other things and the Docker CLI. If you're using containerD, you have to use nerdy control as the CLI to pull off those same kinds of things. You can also change things like in Windows and Mac or sorry, Mac and Linux, you can set your resources and other stuff so you can configure what resources you need for memory and CPU count based on your system. On Windows, that's actually handled for you and you can do things like specify your volumes and networking and other characteristics here. So while the out of the box works well for this and of course you can come here and you can actually see the containers that you have running and you can do actions on those. You can see exited ones, you can see the containers that are here and you can stop them, you can remove them, you can do stuff like that. So if you don't wanna jump into the Docker CLI, some of these tools are there for you. So everything is back up now and we can come back to port forwarding. Now when you restart, you lose port forwarding. We'll go ahead and bring that up and I can go see what my application looks like on the other side and everything came up and this is one of those things that you can test yourself those upgrades and upgrading Kubernetes underneath whether it's a minor version or even a patch release of Kubernetes to see how your environment handles that setup and one of the other things I touched on here was changing the application and then seeing it with Kubernetes. So let's go take a look at that and here we'll just retry and it can connect back to that container environment. We'll say this back to, we didn't like to change so we'll go back to this and then I'll come build it and it builds and then we'll come in here and we'll go to the containers. Actually, you know what? I'll do it right in Kubernetes. So we'll delete this pod and so the pod deleted, we'll see a new pod came right up. Oh, yeah, so I build it and so the pod came up and so I can come over here and that same port forward, I can just refresh it and because it restarted the image was locally. Now if I'm happy with everything, I can use Docker push, all of those things to push it to the registry but it lets me have that local development environment around my application and containers and there's a lot of neat ways you can do that. Now one of the things that I touched on here was container images, right? What do you use for your base container image and where does that go? Because I think base container images make a huge difference. I mean some of them are riddled with hundreds or more CVEs, there's problems with them from a security aspect. In this case, one of them that I want to touch on here is what you'll see here, I've got a go and another BCI called, a base container image called micro and I think your base container image makes a difference in your experience of doing things, whether you're creating a secure environment with the tools that you're gonna have in those kinds of things. So let me come back to the presentation and dig a little bit into base container images and so a base container image here, I grabbed it from the Docker glossary, right? It's the image that has no parent image, it's that foundation on what you're going to use for your images. It's from scratch, so to speak. And there's various types of base container images you can use. There's scratch which has nothing in it and that's great for some applications. If you're building something in Go and you don't need to have another tool in there, that's a great way to have it. There's distrilis which just has kind of an operating system not tied to a distro with certain things in it. You find a lot of the distril ones have security vulnerabilities and things like that. And then there's ones based on an operating system minus the kernel and you'll see a lot of those. You might see Debian ones or Ubuntu ones. So we have something that we use called the SleeBCI and it's a terrible, it's acronym suit. It's the SUSE Linux enterprise and the base container images and they're the ones we use as the foundation for things and they're based on SLEZ 15, 15.5 now. And what's really unique about these is the build system that's used to build them. It's designed to deal with common criteria, ELA4+, and if you deal with stuff in Europe, you know that that is a crazy requirement system as far as build security and keeping CVEs out and that kind of thing. It's the only Linux distro that has this capability for secure supply chain and that meant doing things like salsa level three was just, it just works. In fact, under the old system with salsa level four, it also just worked for anything that was build system related because it has to go so far beyond and CVEs are fixed like that because you need to have that in these kind of environments and so I run this thing against trivia all the time and see no CVEs show up even though trivia knows how to look at them. And so we have a bunch of base container images and this shows a little bit about their size and what's in them because we've got different ones and so I'll use things like BusyBox or Micro because it takes things out that I don't need but I don't need things like a shell and some of the other stuff but these are the base container images we use as the foundation for what we're using and anybody can use them. You don't have to be a SUSE person, these are open for anybody on the internet to use as their foundation and they're secure. And we don't just have base images, we also have images for the different programming languages and they come out anytime a CVE is fixed in any of these things, anytime the base images, everything's there and so we can build our Node.js stuff or use it as a runtime we can build in Rust and go which we do and our foundation is always CVE free and built with a secure supply chain and it's the same thing you all can do too. And you can get this stuff over at registry.susa.com but I think that that base image is part of the developer experience and having one that is by default secure and by default handles these things is a really useful tool when you wanna have whether a development environment or for build or for anything else. And so with that, I'm gonna pass it over to Ray. Hello everyone, I'm here to talk about platform as a service with Apinio but before we talk about Apinio, I want to set the stage.  They might want to scale their pods so they might control the rate of upgrades or scaling so they might have to add a deployment. They might have to want to reach their application from outside of the cluster so they wanna add a service or also add an ingress so you get that URL that will route to the service, that will route to the pod that will route to the container, that pod. Or if your application is persistent you need that persistent resources. If you're using a CNI driver or a plugin you need a storage class, they'll create the PVC, you have to create the PVC, they'll then have to create that persistent volume. The whole point of this Kubernetes is hard. It's so hard that the Linux Foundation actually has a certification called the Certified Kubernetes Application Developer. If you were at this morning's keynote, one of the panelists actually said the reason they're key to success for developers to go to, for their experience, was they did not have to know about the infrastructure. They just, they knew that it worked. So we bring it and there's, here's a few tweets about paths on Kubernetes from Kelsey Hightower. One is the, I'm convinced that most people want to just have a path but the only requirement is that they have to create it. The other one is Kubernetes is a platform for building platforms. So it's a better place to start but not an end game. So we have this open source project called Epinio and the goal of Epinio is to simplify application development. So we want to make it easier for developers to push their source code to a Kubernetes cluster and it just works. So we say that from code to URL in one push. We'll go into details of Epinio in the next few slides here. The reason is because Epinio adds needed attractions and tools so that will actually allow developers to use Kubernetes as a pass. So a little bit more about Epinio. It's an application platform on Kubernetes. It's a single step push and we'll go into great detail of that single step push. It also adds in some self-service provisioning as well if you want additional services. There's a CLI which you install on your developer's machine that CLI is used to help deploy the application. There's also an Epinio server that you deploy on Kubernetes. There's also UI to help manage those applications that you deploy onto the Kubernetes server. With Epinio, we say it's batteries included. So it has all the necessary tools that's required to just do a single step push from your source code to the Kubernetes cluster. There are some prereqs. First is cert manager. Cert manager is used for TLS certs for a variety of ingresses. Helm, so we use Helm to install Epinio on the Kubernetes cluster. The first tool that comes with Epinio is QBD. QBD is a config sinker. It's used to sync config maps and secrets across namespaces, also across clusters. Epinio is using QBD to sync secrets for the container registry that we'll talk about in a little bit that Epinio will install. Minio, so Epinio will need an object store, so Epinio will take your application, create a tarball or an archive of it and store it in your Kubernetes cluster. You could use Minio or you could also use any object store you want to S3 Gateway. So if you are using a project called Longhorn, Longhorn is an object store, you could use S3 Gateway as well. Next, with Epinio, it actually comes with a container registry to store your images that Epinio will create. So this is after the staging phase we'll talk about that will create that container image and store it within that internal registry within the cluster. Next is DEX, so you could actually integrate with an OpenIDC Connect provider with DEX. And Epinio leverages build packs. So build backs is how it takes a source code and defines the dependencies that's required of your source code and creates and builds container images. So behind all you need to do for a developer is actually do Epinio push and give it an app name. But behind the Epinio push, there's actually lots of steps that is required or that Epinio does. First step is that Epinio creates an archive of your source code, TAR, ZIP, there's other formats as well. It'll send it to the Epinio server running on Kubernetes. Then it will copy that and store it into S3 or Minio. Then we'll go through a staging phase. That staging phase is actually three phases. First, I'll fetch that archive from Minio from S3, then I'll unpack it, then I'll send it off to and use Pequetto build packs. So build packs will help you, will create that find those dependencies of your source code and also create that container image. Epinio will then push that container image to its internal registry. And from there, Epinio will deploy the necessary Kubernetes resources. So it will create that deployment. Within that deployment, the pod that runs your container, it will create the service, it'll create the ingress, and Epinio will actually give you a URL where to access your application. So here's a little demo of Epinio here. It's running. Okay, so I'm just showing off, this is a sample React application going through the JS files here. On the right side, it's a little obfuscated, is Epinio running on a Kubernetes cluster. Then here we will create, do Epinio push. So this is a process where it will create and also create an archive, a tar ball, of your source code, and then we'll go, we'll watch the staging process of the entire, what is behind Epinio push. They'll create the necessary resources and they'll send it to Pequetto build packs and create that container image. Then it'll store it in the container registry. Then Kubernetes will deploy the required resources to deploy your application onto the cluster. And at the end of this demo here, this will take a few minutes here. It will give you a simple URL where you could access your application. Then as this is staging here, then you could go into the UI of Epinio as well and you could manipulate Epinio as much as you want. You could scale it up or down. If you want as well, I could add an additional services here. So I've just been more, we have three minutes left. We're gonna let this demo run here, but in the meantime, are there any questions for us that we could answer while the demo is running? Yeah, I can also say everything we've shown so far is free and open source software. You can just get it, you can contribute to it. It's all up on GitHub. You have a question? Yes, all the slides will be up on schedule. Sorry about that. Yeah, demo's still going, still running the build pack, the staging process. So we're still generating that container image then. Well, at the end of this, we'll get a nice URL that we could take a look at our application. This for Epinio, it's a, so Paqueta build packs is under the cover. So they support the set number of languages that builds those container images. So we would support what Paqueta build pack supports. Are there any other questions? Yeah, that's a great question. What a lot of this comes down to is your resources in your local environment. Some of the Kubernetes distributions will take four, six, eight gigs of memory even running on a local machine. And a lot of developers don't have that. I mean, if you've got a machine with 16 gigs of RAM and Kubernetes by itself is taking up six gigs and then you've got Slack and a browser open, you don't have much for your own applications there or environments. And so the Kubernetes API is gonna be the same. The controllers will be the same. It's some of the things that usually don't affect the application itself that are different. If that makes sense, if you really get into some of those things, then you might even be worried about the host operating system and kernel modules. And if you need something like that, you're gonna have to go a step beyond with your environment. But that's why K3S, because it fits in a tiny environment. But it still is the exact same controllers and other things that affect your app. Any other questions? I'm showing off here. You could take a look at your application, how it's deployed using the Pinio CLI. You could take a look at logs as well for your application through Pinio. You could also check out the logs through the staging process as well. And the last step is deleting the application from the cluster. And it will end the check on the Pinio CLI to make sure that the application is deleted. I wanna thank everyone very much. Looks like we are at the end of our session. And if you have any other questions, feel free to stop by the SUSE booth and ask about any of these technologies. And somebody there can answer more questions or maybe even show you a demo, that kind of thing. And go further. Thank you.


So, yes, sorry for the horrible title. I changed a little bit. I'm going to talk about reproducibility. And I'm mostly talking, actually, about the sociological aspect, because I think that's the most important aspect today. So I'm going to introduce briefly the issues in statistics and software. And then take two examples for presenting some solutions. I don't think there is yet a solution. And then indulge a little bit myself and say, you know, let's think that we are in 2050, and what will we be describing of the history of the field at that time? Statistics and methodological. So a couple of examples that are not specific to neuroscience, just like a scientific example. And the first one I want to show is this one that is exactly an example of one of the studies that started the field of imaging genetics. It's an interesting study in the sense that it had the reproducibility aspect. So these guys were looking at the bold effect in the amygdala when the subject is presented with fearful faces. And if you look at the bold effects, you have like an increase of the amygdala. And this increase is different for the short allele of the carrier, the short allele for the serotonin transporter than the carrier of the long allele. That's an amazing thing. And the interesting aspect to it is that you see that the court of that study where 14 subjects, two replicated ones. I can tell you it has not been very well replicated after this time. What's the problem? The problem is that you're looking at a short group size, and this is in this figure. You see looking at the group size is the size of the circle here. And the early studies show some high effect size, quite variable, but high effect size. And then as you look at the years, with the bigger cohort, you see that the effect size is shrinking. And that's for the distance for the link between the hippocouple volume and the BDNF allele. That is the problem. That's one problem, sorry. And that's been seen again and again. So first in this Justin Stein's science paper about the hippocouple volume, he was looking at the literature before and says, OK, I can actually not replicate any of the steps that have been found. And the problem is the power. Basically, the more the power problem, the most significant and powerful, the biggest effect size that you find in this field is the epiuree for Alzheimer's disease. And that power, that effect size in terms of coincidity is 0.2. And that's the problem. A very recent paper, it's not been published, but it's on archive already. We're looking at the median sample size of ephemerized studies. And you see that today where the medium sample size is about 25 subjects. And for 25 subjects, what is the size of the effect that we would have to detect it with a reasonable power? And that's about an effect size of one. I can tell you, and I can show you, the effect size in ephemerized studies is not one. The effect size, and that's the median in some various paradigm, motor, working memory, emotion, and so on. The median is actually around 0.5, 0.3, 0.4, 0.6 maybe. So basically, we're fundamentally underpowered. Very interesting, switching a little bit from the power aspect to how do you analyze data? So that's a very interesting study, because it's a serious study. In the sense that if you look at this paper, which is looking at how students can have some precognition of a future event, it's very well done. It's a group psychologist who are doing that. I can't remember, I think he's from Yale. So you're thinking, OK, that's not possible, right? This guy has done nine studies where he replicated a kind of a precognition effect. Nine studies. And it's very hard to find, you're thinking, OK, that's not possible. Well, there's a very good blog from an Italian colleague that says basically, why good researchers publishing good articles in good journals can still get it totally wrong? And it's difficult to find it. And there's a number of reasons why, you know, it's probably a peak hacking aspect. I don't know if you know peak hacking, but basically it's doing small methodological errors or repeating analysis so that you get a significant effect. And there's a number of things that were done in that paper are not obvious when you read the method section. It's not obvious why this paper is probably wrong. I'm not saying it's for sure wrong. I'm a scientist. I want to see the science of it. A little bit of a software aspect now. Who hasn't heard what Poti and Baggagli, have you all heard about the Poti and Baggagli study? No? No, you haven't? OK. So it's absolutely a must if you want to learn about reproducibility and the problem of like publishing in science and so on. It's a must study. You have to read about that. So what they did in the year 2006-2008, they chose cell lines that are most sensitive or most resistant to drug. They take the array profile of those cell lines, look at the genes that were most differently expressed, and then they, using those genes, they build a model that can actually predict whether a patient will be responding to the drug or not. So what happened is that there were so Baggagli income, so two biostatisticians, look at that study and try to replicate it. And the reason why they could is that the data was actually available. And basically, I'm making the thing short, there were many errors, many errors. And it's not clear now whether there are some errors where in attention or not. But let's say they were not intentional. That's a completely different problem. It's very good, meaning researchers trying to do the best they can. Well, they got a very poor documentation, irrepositability, even well-meaning investigator may argue for drugs that are contraindicated to some patients. Actually, there was a clinical trial going on. That clinical trial was actually giving the drug to the patient that shouldn't have gotten the drug, given the result, the actual result. We've had some effect on society, right?  And they actually look at those things. It's called the forensic analysis, because it was really hard. It's a painful paper to read. It's all the minus details of what happened. But what they say is that the most common errors are simple, for example, row or column upsets. And we see that over and over again. And the most simple errors are common as well. And how do we make sure that we don't do the simple errors and the common errors? Joffrey Chang, a very last example, maybe. Free science paper, one PNIS, one, and I know I'm any more, was a crystallographic looking at the structure of the protein. A homemade data analysis program that flipped two columns of data, iterated from another lab, and passed to other labs. And all those papers have retracted. And again, well intentional, this is fine. This is like researchers trying to do their best. And I have to put a figure on that paper. It's a very recent paper in PNIS. But the test of a cluster size in fMRI data, how do you detect an activated region in the brain? And basically, I put that in the method, because I think the method is actually not bad. The paper, I must say, in my opinion, is a little bit hyped. I mean, when I say a little bit, I think it's a. But basically, I think it's the problem there. So they show that there's a very large false positive error rate when you analyze data where they shouldn't be activation. And you find some significant clusters. That's what they show. In fact, what I want to say on that thing is that there is a software which had a very bad default in terms of how you set up that test. And everybody was using the software. And that was, to me, the main result of that paper. And I can talk more about that paper, because I've studied it extensively. So lesson learned. Software, please set the right threshold. That's a very simple thing, right? Train users so that they know what the tests are doing. An interesting comment on the Chang crystallographic problem. So Locker says, I think he was on immense pressure to get the first structure, the first structure. And that was made him push the limit of his data. He could have been more careful, but immense pressure of publishing in high-impact journals. Buggerly, forensic possible, because data, time, and expertise was there. Time was there. It was very interesting to see that Buggerly couldn't actually publish his stuff in a life science journal. He tried to publish in the Nature Medicine Journal that was publishing the particular papers. He couldn't. He had to go for a statistical journal. And they took it right away. Donoho, a little bit of a conclusion. Donoho is a professor on Stanford about computational statistics. Publication is the advertisement. The scholarship is in the code. That's my message from all these examples. So solutions. There's a lot of people trying to mend that problem. It's not an easy, menderable problem, not at all, because of the incentive structure that we have in research. So improve data and code sharing. That's one of the key aspects. And improve the culture such that data and code sharing is just a norm. That's what you do when you are a scientist. And I don't actually like the name share for the data, because most of our funding is coming from public agencies or governments. So that's not actually sharing. It's just doing the publishing that you should be doing. So let's talk about publishing data. And if you've got Nature and your scientific data, and many papers would actually accept data paper, because that's a fundamental block of science. You could have a quick look at the top principles for the publication as well. I think that's a good in terms of code and data publication. And I'm going to talk briefly about two projects that are trying to improve reproducibility in neuroimaging specifically. And then maybe a word on teaching, maybe a word on race awareness. So Repronim and CRM shows that they show that basically the funding agencies have started to acknowledge the problem and think about the problem. And they're starting to fund a group of researchers to do reproducible science in their domain. That's new. That's not a... I know that the United East Matrix Center, for instance, is already a couple of years old, right? And the Open Science Framework is already like a few years old and so on. But that's new for NIH, at least. Repronim is a decentralized, recent P41 grant, and basically trying to set up a set of tools that help researchers find data, launch analyses, and document results in a reproducible way. And CRM is also a Stanford-based and I've got the luck to participate to those two projects. And it has a clear vision of the incentive of it, which is basically give me your data, we'll do some analysis for you, and you'll get back some results. So there's something to buy in for you, right? So those two projects are based on two standards. And the development of standards is completely critical for the efficiency and the responsibility aspect of our science. So NIDM is the standard that is underlying the Repronim project. And it's based on the grant vision, I'll show you. And it's interesting because it is embedded in the most common software in your imaging. It's starting to be embedded, sorry, like it's work in progress, but it is now like an NFSL as an exporter, NSPM as a native thing to export the results. It's a work in progress with AFNI. So really, it's actually there. Bids is a very simple directory structure and layout on your disk, on your file system. And that thing is the basis of the Center for Repositional Neuroscience in Stanford. And also, those two things were actually seeded by NCF, which is interesting to think about it. That's not seeded by NIH, that's seeded by NCF, it's interesting. All right, so what is Repronim? That's the grand vision of it. You have your data, your workflow, and the result those things produce. And all those things can be encoded or written up on the disk or as files with a certain model that can interact between those things, that can make the interaction, the interoperability between those things. And once you have all those data on the disk that are coming from the description of the data, the expression of the experimental design, the expression of the workflow and so on, you can have apps or applications that are, okay, this is neuroblast trying to find and alert and query where are the data, where are the workflows and so on, where are things. This is another application that would say, okay, let me help with the design of that model, of that workflow. Let me validate that I'm refinding the same thing for different data. Let me test, if I've changed the software, let me rerun some of the tests on the data that I've run before to see whether I've found some similar results. NiceMan is the actual computation, how, which platform do you use? Do you use AWS, do you use your local cluster, do you use anything else? And so how do you do that in that context? And all those things and what's the information that you need to get from this computation to be able to reproduce or at least to document? I'm not saying that you may be possibly to take it all, take the Docker container and push it again and reproduce it, that's fine. But just documenting, at least documenting, sorry, this project is doing to do that as well, but documenting what has happened is completely critical. And the whole interaction is always on the same layer of communication, like computer communication based on linked data. CRN, the Stanford project, I mean, it's more than Stanford, but based in Stanford. Put your data in a very simple data structure, I'll show you the format of that quickly. Contrast some apps, so ask all the application in your imaging and construct an app that knows the format. It knows that this is how the data will be. And then use Docker actually singularity containers. Singularity is much better for the security aspect than for your cluster aspect. And then use some other platforms to relate with the data and the clusters and get something, get the results, get the thing that you want to publish. So what's 9DM going back to the format of 9DM? It's really based on that vision that you want to have a communication between the experimental data, the raw data, so the experiment itself, what is going to be done, the raw data, the analyst workflow, the derived data. So there's a lot of transformations. You're not going to have like just one raw data and then the result, right? There's a lot of steps in transformation. All those steps are deriving some data that could be used for another workflow and so on. And then the publication. How do I relate a fact, a finding that I have in my paper? How do I relate that to the whole process of finding this thing? And that's the key aspect and what the 9DM is trying to, and it's a provenance model. It tries to say, what did I do with the data? It's based on the linked data technologies and the probe specification, W3C specification, then it's built on the part of the core vocabulary that if you find the vocabulary somewhere, of course you'll be using the ontology that exists and that are solid, but that's a difficult thing to do, but if you have a term in Stato for the statistics aspect, first of all, you will be using that term because Stato is stable and you can use it and people will be able to know what is a t-test from Stato. And then it's trying to painfully and model all those words, what's the experiments, what's the workflow, what are the results and so on. And we did a lot of work first on the workflow and the reason why we did, on results, sorry, the reason why we worked on results mainly to start with is that most of the analysis that you find in literature are done either with SPM, FSL or AFNI and that's about 80% or maybe, so trying to solve for the 80% before trying to solve for the 100% is one of the thing that we need to try. And that model, it's a model, it's actually encoded and one see it's implemented and it's not treated, it's a triple store somewhere. And that model is valid for both, for all the SPM and FSL in AFNI. It has some friends and it's going to describe all the data using that model such that if you're doing a meta-analysis and you're trying to grab what are the voxel activated in the brain from SPM in that analysis and what are those activated from FSL and one those from AFNI, you're doing to do one query on the same model, on the same exported data. And that's critical for the efficiency aspect and that's also critical to basically standardize what is that you've done and what is that you get. Communication, somehow. That's a computer communication but that's also like our little neuroimaging society communication. So the meta-analysis aspect, we work with Tom and Camille Moumet in Warwick to work on how to do meta-analysis and meta-analysis is one of the aspect that is an answer to reproducibility. You're thinking, okay, if there is a lot of studies and some of those studies are not too well powered, maybe if I take all those studies that are talking about something, I will get a more solid answer. I can tell you that's not always the case. There are some meta-analysis of 30 less not well powered studies and they show effects that they shouldn't. But anyway, that's a little parenthesis. So we work on that model and now we have something that can work we can work for meta-analysis and that's what we're doing at the moment and Camille is doing at the moment. Now the experiment, it's a much more complex thing. So how do you encode all the experimental aspects? So the, and that's using again, using W3C Pro, so it has a specific language of how you do that. What's the project? What is the specific study for that project? What are the acquisitions? All those layers have to be encoded and that's a very long and painful process to do. But starting with some of the examples of big databases or that's a possible thing. And how do we engage, how do we make that successful? How do you engage all the community to work on those models and say, hey, okay, I want to also model my thing such that I can interoperate with you and find things and so on. And so we use these social tools, the GitHub of course, and also try to get some viewers. For instance, a viewer now can just look at the results that have been produced by either of those software and then load up those results and view those, right? And there's no specific viewer for one software on the other or the other. You could have version of that, different version of that viewer that is because people prefer one way or the other, but the underlying data will be the same. What is BID? So I'm switching from opening NIDM things to the CRN BID aspect. It's much simpler. So NIDM is kind of difficult and it's a linked data model and those people in the room that have worked on with that, it's not an easy sell. It's the Python libraries are not always there and so on, right? BIDs, it's very simple, very extremely simple. So I've got some Dicom data. I'm going to specify how they should look like on the disk and that's just a directory layout. And it uses fine-name forming rules. So you know that if you have a T1 image, it should be called like a sub dash, so key values sort of aspect to it and plus an add something and so on. So there's a rule for naming the files and there are a number of JSON files to describe what's going on if you need to something more than just a file name, which is always the case. And the experimental data themselves, the time series, not the time series, but the events recorded in the scanner on those things are TSV files. And very rapidly this spot, like we cover up with an ecosystem that is kind of a large ecosystem now. The major databases wanted to export in BIDs because that's simple or they can read in BIDs from BIDs because that's simple. So that's working progress for that. It's been extended very quickly to EG, MEG, PED data. BIDs are exported to the NDA, NDA is the NIMH data repository and you can easily export to NDA and some of the grants now are required that you push your data to NDA and so you can easily export to NDA with that and so on. There's a BID validator. So if I have a layout and some JSON files and so on, you add those thing BIDs and you have like a little JavaScript validator that Chris Gorgreski have written to do that and Chris has been leading that very energetically and very successfully. There's a lot of BIDs apps now. We had like a week in Stanford where we have like 25 people working on making all those tools to analyze data compatible with BIDs such that you can have a little Docker container.  So that's going to happen. It is happening now. So what are the lesson learns? I mean I just don't want to find that but what are the lesson learns? So I think there's, I was trying, so I'm not talking about this other thing here, but lesson learned that 9DM is a long-term, very interesting, very principled way of doing things. It's going to, and the scope is very large. It's going to take some time. It's a long-term thing. It may not be fully successful because it's a long-term thing and we know that research is never too much but long-term. It's for the next grant, right? It's for the next paper. BIDs is extremely successful very rapidly. How much long-term would that be? It's questionable in a sense because you can't put every information in a principled way in a JSON file in a BID directory. It's hard. It's going to be harder and harder the more information you're trying to encode. So those things are trying to think about those projects as what is the first minimal product that you can get with it? How is the adoption going to happen? The adoption with BIDs is going to be very easy. The adoption with NIDI is always going to be very hard. I'm not saying it shouldn't be done. It's just like a fact. And if you embark on those kind of a neuroinformatic project, you just have to think very clearly about those things. Is that, you know, have enough chance of success? Anyway, okay, that's my lesson for those two things. Do two standards that are actually the basis of two reproducibility projects. I think that's interesting to think about that. And there are some first success already. Like there's already from the repro-name an analysis that goes from a data set that was selected through a query that's run with a workflow that has a provenance written up and the results are written up as well with the same provenance model. It's like a toy example, but it already is happening. That's interesting. With BIDs, there's a great number of data set, the adoption is very fast. So, you know, both will make it easy to record what has happened. Both will make it easy to actually redo exactly what you've done before.  We just want to participate in the other project that is doing the right thing. And I think that's the case. I mean, you know, we both think it like a, both project out trying to do the best to coordinate. And that's also an interesting aspect in terms of sociology of the science that we're doing. So, let me talk very briefly about the teaching and statistics and method aspects of a rapid disability because I think that's one of the key things that we have to change the culture as well. And I wanted to, I don't want to, you know, do long things. I don't have the time for that. But I just want to remind you maybe some of you code and some of you have read the code complete. It's a, it's a very good book. It says, I just, you know, and the science, the science and for the scientists, and I think that's, that's absolutely true. It was, it was true for the programmers what he said on the slide. It's now true for the scientists, for many scientists still. In the years of programming, a programmer was guarded as a private property of the programmer and so on. It was basically a love letter from the programmer to the hardware, right. And I think, you know, and the, and the conclusion of that is that such programs are unintelligible to those outside the partnership. You actually don't want to look at the love letter of someone else, right, you just don't, right.    You know, I won't tell you what the most, the most common name for a variable in FSL is because Steve Smith has chosen a very funny name.  But today, I think things are changing. We're not writing code for ourselves and for our little project or our little science. We're writing code to communicate, right. We're not writing to, you know, our hardware. We're writing to other scientists. So, there's a lot of code review and publishing code, things that are happening. I'm just, you know, laying a few of those here. I think the, I mean, I know that GigaScience, for instance, is doing some code review and things like that. There's the natural neuroscience that I think we'll be doing code review. And so, things are happening on that side as well. The code is not really your code. The code is just to publishing code. I mean, it's your work. Training scientists, completely critical. There's no magic bullet. There's absolutely no magic bullet. There's a training to be done in terms of the NTP hacking, anti-file drawer aspect of things. That's, that should be really like the key aspect of the training. There should be some training obviously of the software script, you know, how do you write provenance and how do you test your things? Our testing is so critical. How do you minimize the, you know, Excel, click and new things? And that's not an easy sell for biologists. It's a difficult thing for neuroscientists. It's absolutely urgent that we talk to our funding agencies, to our politicians who say, hey, just we have to raise the awareness that if we want to do proper science, we have to take the time to do it. We have to move the culture to be a more open science culture.  That's part of our job. So let me conclude and finish with like a, what will be the time of the years 2020 will look like if we were in 2050? Like, okay. At that time, you know, in the 2020s, you know, the funding agency implemented the fair for data. That was the thing that, you know, they did that, right? The battle for that actually was basically won. Okay, you know, people got in the culture. That was the time where the culture changed. It was, you know, it was prompted many by the sort of a pushback by and often by the clinical societies. That actually, there's very specific culture in the clinical societies. That was the time where the tools started to be reusable. So the output of a grant or the output of research was not the paper anymore. It was the tool. It was the code. It was the data. And that was the output. It was also the time where biologists couldn't major without serious methodical training in stats. And they all knew GIT perfectly. They knew the model of GIT, right? Bioinformatics just became neuroscience because that's just neuroscience. So the informatics effect was still embedded in the biology. Bioinformatics just became biology. It was the time where the publication aspect, when it just slowed down, you know, publishing with more less money, you know, things got more open, but things got more replicated and on several data sets and the generalizability of a research finding was actually possible to test on other data sets with other methods and so on. Publishing of scientific data collapsed. You know, basically new models of online publishing happened. The automatic publication processes started. So, you know, once you've designed the whole experiment and the whole analysis and so on, you had reports. It was a human readable report, but that was entirely automatically generated. And that was the first time it happened, 2020s, right? The OneLab research almost disappeared. Again, it was not funded anymore. OneLab was not funded anymore. It was always projects across the community. Collaborative web tools became standards. And I'm just going to show two quick example of historical example of that. How it is this, for instance, tagging with metadata and the, you know, PDF also website and so on, such that you can re-find things that are tagged with ontologies. That's one thing that happened in the 2020s, actually, you know, 2016s. Collaborative segmentation. People started to collaboratively hack on the same segmentation of the specific part of the brain. And that was entirely on the web, entirely completely distributed across many labs. So that's what happened at that time. And I would like to acknowledge many colleagues and good friends that have worked with, and I was privileged to work with along the past years. And thank you Alain for the invitation and for the organic entity. And thank you for your attention as well. Thank you. Questions for, JB, I have a concern about the whole BIDs initiative. You recall where we were with Nifty and Nifty One? Yeah. This was adopted as a fast, lowest common denominator that everybody could get into quickly. And then the reality is emerged over time that we needed something more complex to take account of the metadata. What, aren't we doing the same thing with BIDs? I think we are doing the same thing with BIDs. But I can, yes. I think, I was actually specifically saying that, right? It's a little bit more of a short term. But during those years of Nifty, I'd say waiting for something else maybe to take over and how that is going to happen. So the question is, are we going to be stuck in a local minima? Yes. And how much energy do we will need to get out of that local minima? I don't have an answer to that. I think you're right. There's a little bit of that problem happening, possibly. But it's going to be so as a step, so useful. Like Nifty was hopefully a step, right? But it's been extremely useful because people could take different software and use the same image format and play with that. But yes, I think there's a danger of a local minima and the only way that can be overcome is by getting the funding agencies to think more in the long term. That's a hard thing to do. And so the advocacy of the, you know, on those things is just like a critical thing. We just have to, and the social aspect, how do you get the social aspect going such that we can be more long term as a community? That's the key problem.  So thanks for our very nice presentation. There is obviously a lot to digest and to think about. Maybe one question about the preprints. Could you summarize or explain a bit better why preprints are important and how pre-producibility? I think they don't help with pre-producibility directly. They help the open science and they help the psychology of a researcher. That you're putting your research out before, you know, as it is, before it's actually reviewed, and you're sort of breaking the fear of being scooped. So that's the psychology of it. Actually, some people think, we're actually putting a stamp stamp. We were the first to do that as well. I think it can work both ways. The preprint is important in a sense that we need to get away from the power of large publishing companies. And I think that's one way, because they have vested interest in the statu quo of how we do science at the moment, because they make a lot of money from it. So that's also another aspect of it. And there's more to discuss, but yeah. I'm totally aware of that. One more question, I'm afraid, Steven. It's been on Nithyan did the... I wanted to put a positive spin on Nithyan did. So during the Nithyan one process, there was an attempt to move to Nithyan two, and it was clear the field was not ready because the major app developers basically said, you can do it, but we won't touch it. And I would say, Bids is the direct successor of Nithyan two. And it's just, it's a nice example of the sociology has taken, well, 10, maybe 12 years to get, I don't know if you see it that way or not. I do. I'm not saying, when I'm saying we stuck in local minima with Nithyan a little bit, I don't, I think it was, it is still very useful. I mean, I don't know how to do better, right away. It's just like a, so if I put a negative spin, I really, I want to remove it. I mean, it's just a fact that it can't do anything that we need. It just, we'll have to beat the last one. And the question is, how do we get out of it? And that's a difficulty, but it's positive. I'm afraid we're gonna have to move on in a busy schedule. So thank you very much, Jean-Baptiste. You're welcome. Fabulous talk, as always. Thank you.


Hello and welcome to this online training module dedicated to the advanced security features of the STM32WL5 Root Security Services, or RSS. RSS is used to load content in the secure or non-secure flash memory. The RSS provides runtime root security services used by the STM32 Secure Firmware Install Solution, or SFI. For more information on protected memories, please refer to the online training module STM32WL5 Security Memories Protection. The flash memory has an information block containing system memory from which the CPU1 or Cortex-M4 boots in system memory boot mode. This area is reserved and contains the bootloader used to reprogram the flash memory through one of the following interfaces, USART1, I2C1, or SPI. It is programmed by STMicroelectronics when the device is manufactured and protected against spurious write-erase operations. For further details, refer to the application note STM32Microcontroller System Memory Boot Mode, or AN2606. System memory from which the CPU2 Cortex-M0 plus boots in system memory boot mode. This area is reserved and contains the SFI RSS firmware used to authenticate and install the firmware in flash memory through one of the following interfaces, USART, I2C, or SPI. It is programmed by STMicroelectronics when the device is manufactured and protected against spurious write-erase operations. On the STM32WL5X microcontroller, the secure bootloader is stored in the internal flash memory or system memory and supports the following interfaces, USART, SPI, and JTAG. The STM32WL5X secure bootloader allows the execution of the SFI process several times after complete erase of the internal user flash memory if erasure is allowed by installed application. The embedded bootloader is used to program flash memory and runs on the CPU, Cortex-M4. It can be used to load content in non-secure memory areas. The embedded secure firmware install process as part of the root security services or SFI RSS allows the programming of the flash as the embedded bootloader. It runs on the CPU2 or Cortex-M0 plus and can be used to load content in both secure and non-secure memory areas. The secure bootloader is a standard ST bootloader with additional security features. During the SFI process, the secure bootloader never allows any other code to access the user flash memory or SRAM. Secure Firmware Install or SFI is a global solution for the STM32WL5 series of microcontrollers, allowing secure and counted installation of OEM firmware in untrusted production environment, such as OEM contract manufacturer. SFI is implemented using the secure RSS and the secure bootloader. OEM firmware protected by SFI can be stored in the device's embedded flash. The STM32WL5 SFI solution consists in having the whole OEM firmware and the option bytes encrypted with an AES secret key, thanks to STM32 Trusted Package Creator Tool. This is done during OEM firmware development. Confidentiality of this AES secret key is ensured using an STM32 device unique key pair with the private key readable only by the RSS. For more information, please refer to application note AN5511 for secure firmware install or SFI solutions. Only genuine ST microelectronics STM32WL5 microcontrollers can install the protected firmware via SFI. The number of STM32 devices on which the firmware has been installed can be counted inside the hardware security module or HSM associated with the SFI process. See next slide. OEM firmware and the option bytes are encrypted thanks to STM32 Trusted Package Creator Tool during OEM firmware development. OEM also uses this tool to program the hardware security module or HSM with its AES secret key, its nonce, and a maximum installation counter. The OEM contract manufacturer uses STM32 CUBE programmer and provisioned HSM to initiate SFI process and sends encrypted SFI image to the STM32WL5 device. Authenticity, integrity, and confidentiality of the OEM internal firmware and option bytes are checked before embedded flash is programmed with decrypted firmware and option bytes. Secure firmware install to internal flash memory goes as follows. Numerical steps are represented on the schematic. 1. OEM creates OEMFW or .SFI. 2. OEM provisions OEMFW key in HSM. 3. CUBE programmer gets certificate. 4. HSM creates the license. 5. STM32 gets the license. 6. STM32 gets the OEMFW or .SFI. 7. STM32 decrypts the OEMFW and OB. 8. STM32 programs the OEMFW and OB. Please refer to memory protection, flash, or boot training if you want to know more on those topics. Also, find a list of peripherals related to the RSS and the SFI. For more details, please refer to application note AN2606 about STM32 microcontroller system memory boot mode, application note AN4992 about overview of secure firmware install or SFI, and application note AN5511 about STM32 WL5X SFI tools, bootloader, and RSS interface. User manuals for STM32 CUBE programmer and STM32 trusted package creator are also available on the ST website.