 So this is more like a venues thing, because I had a real talk. But nevertheless, I would like to show you basically how our core users who look like that use everyday at GNU Devs. So this system is called Skooled OS. And maybe if you like, you can download it from our website. So it's here. And the basic idea is that it comes on a small USB storage device. The disk image is just about 25 megabytes in size. So it's a really tiny image. And on my laptop, I only have one big file system, only data on the laptop. And there's no OS installed, except for this tiny thing that I probably need. And the idea is that this is so tiny that we can, in principle, also put it into some kind of flash memory in the Windows. That would be pretty cool. So now I will just start the routine. And then I can turn it around so you can see that it's doing something until the screen goes up. So it takes a while to get the logo. And so now it's fetching data from the USB stick. And here we are in the G-note world. So you see it puts up pretty quickly once you pass the logo logo. So at this point, when you see the first life sign of G-note, there are already about 60 components running. So when you're in contrast with your G-note system and you start a kernel, you have one big program with everything but in. But here we have these tiny caches, these sandboxes. And each tiny functionality, like the USB driver, these two drivers, all the different parts of the system, they are each sandbox in a dedicated component. The system has some kind of, maybe you might just use it on the face that you see right now. And this allows you to basically be the boss of the system. So you as a user are the boss. And this interface here is called LightCentraler, which is a German term for a sophisticated control instrument, not for unsophisticated user, but for someone who knows what he's doing. Maybe I can give you a slide over view of how the system is constructed. So this is just boring. So what we have in the USB stick is basically the system, the booted microkernel, about 10,000 and a 4th. We are using the kernel of this gentleman over there. It's with NOVA hypervisor. And the static system comes with a smaller static system booted on top of the kernel. And then on top of this static system, three dynamic systems are established. So this is always the same. But what we have up there, this is becoming dynamic. So for example, the driver's system is dynamic. Because when we boot a USB stick, we don't know how the hardware looks like. Is there an intergraphics or is it not an intergraphics? So we have some kind of runtime decision. And this takes place in this driver's sub-system. Then we have the LightCentraler. This is basically the user that plays to interact with the system. And then we have the play skill for the user. The actual useful stuff happens, like the program step that I want to execute. And what you see in this graph in the middle is basically the current state of the runtime of the right part of the system. And we see that I started this computer. There are quite a few components that I already started. And for example, I can switch between the LightCentraler and the real desktop using F12. So when I press this button, you can see now you have this God mode basically. And now we have our desktop. And so we can also interact with these windows and do some, this is for example, a small Unix-like environment custom build. And you can at any point in time begin control over all the system, recorders of what happens in the runtime. You can always get back to this view. And yeah, this allows us, for example, also to add new components. So for example, I can, what I usually do when I'm working, I fire up a virtual machine. And this is to tell me the virtual machine requires some kind of networking. So I say, OK, let's try out the Wi-Fi. So I click on this button. What happens here is you see a new Wi-Fi driver enters the picture that's over here. And we have SneakRouter. So this SneakRouter is basically something like a NAT device that virtualizes our network. But it's all virtual on our system here. So you see, the Wi-Fi driver is actually running, has scanned the network, and we have this custom legacy and try trying to connect to this. And so we have in the background our virtual machine pulled up. So you see it here. It's just a Linux VM. And the virtual machine workforce is basically a port of virtual box for G-Node. So it is able to execute all the guests that can be run in virtual box. And this is basically how I spend most of my day really inside this virtual machine. So I have all the productive work. Oh, yes. Oh, sorry. How to do this? OK. Thank you. Thank you. So most of the development work still happens inside this VM. But we are now in a process to move the different things outside the VM into native G-Node components. To give you a big overview about how the system works under the hood, let me show the overview of the static system. Because I think that's quite elegant and quite a different approach compared to traditional operating systems. So the static system basically contains this GUI server. So the guy who multiplexes our display that you have seen already. And then there are basically two in-memory filesystems. So these are basically RAM filesystems, a bit like 10.js on Linux. They are just empty at the startup. And in this case of the configuration filesystem, there is some initial content fetched from the USB stick. And this is put in there. That's part of the image. And the purpose of these two filesystems is that on the one side, this report FS aggregates all the state of the components. So the different components, they talk sometimes interesting things. So for example, I'll give you an example. The wireless driver is running. And from time to time, the wireless driver just tells us what it finds. So in the Light Central, we can basically access those filesystems directly. You see over there the config FS. And it's a bit small, right? Maybe I should increase the font size a bit. So let's put the config FS to a good use now. So by default, the system tries to scale the fonts according to the screen size. But you can override it as a user. So I can, for example, say I want to have this managed font config as a basis for a manually managed configuration. So I copy this configuration file basically to this place. And now I can basically edit this configuration. And here you see basically a font configuration. The funniest thing is that those fonts are actually implemented as a file system. So we have a true type of file system. And the font rendering happens in the file system. And font sizes are basically just amount attributes for those filesystems. So what we have here, for example, for this monospace text, let's make this a bit bigger. I can say, OK, I want to have this one. And now we have changed the file system, the mounting attributes. The true type file system is remounted and picked up by the different components. Sounds a bit esoteric, but it's surprisingly useful. The cool thing is by putting this into a separate component in a separate file system kind of component, the actual application, like the terminal, doesn't even have to link against the font library. There is no need to link against this free type. All the complexity goes away. And we can just obtain the ready rendered glyphs from the file system. But OK, that's just the detail. Yeah, let's go back to the wireless topic. I explained that there is this report file system. And this contains all kinds of interesting information. So for example, we can take a look at what the Wi-Fi driver reported about the Wi-Fi access points. So you see here, these are the Wi-Fi access points that are reported. And what you have seen before here in this area is just a view on this report, nothing more. And another example, if you want to look what the inter-graphics driver is detecting, we can say, OK, let's look at the driver subsystem. And there we have a dynamic part where the inter-driver is running. And then the inter-driver has this report generated for us. And we can see which connectors there are. And conversely, if you want to modify the configuration of one of these components, we can, you guess it, I guess, modify the configuration of this, like the frame buffer file system here. So sometimes it's useful to basically enforce a different screen size for, let's say, giving a talk. So here I'm really reconfiguring the low-level graphics driver that normally also sits in the kernel. And what we see here, it works. And you can even see that the fonts are updated in the size of the fonts. And the bottom line is that there is only one interface for these configuration problems, where in a little system you have this x-runder interface for the graphics. And you have a completely different interface for the wireless or for the network configuration. Here everything is one coherent concept. And this goes really far. So for example, let's take a look into the configuration of the nitpicker GUI server. So this is under config nitpicker. This is basically the security policy of the low-level GUI server. And what you see here is basically there are a bunch of security domains. So for example, there is this mouse pointer. It's a dedicated security domain. And as a matter of fact, the program that draws the mouse pointer doesn't know where on screen the mouse pointer is located. We just say that this domain has a coordinate origin pointed at that is the pointer. So the program always draws at 0, 0, and we get the mouse pointer there. And we can do funny things. Like for example, I can say, ah, we have this domain light-centraler. So let's use this as a mouse pointer. Like you can do the same here. And now we have the light-centraler as a mouse pointer. So you get the idea that the whole system is very, you can model it on your fingertips. And that's also the reason why the whole thing is called Sculpt because you have like a sculpture. You start with a generic thing on the USB stick. And then you can model it or modify it and save the result on the USB stick again. And then you have your custom system. Maybe do I have some more minutes or? Oh, it's amazing. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. And the nice system is that we want to extend it. So we don't have all the software on this USB stick. We want to install new things. And we don't know where it is. We don't know who provides the thing. For example, I want to install a game developed by Emery. But I also want to maybe add some new software like a new version of Soul in the future provided by you. And so we need some way of deploying and installing software on Sculpt. And so last year, I already talked a bit about how this can be implemented. And let me just recapture the general idea. This was basically the idea. So just think about installing and updating software in our today's systems. You have usually some kind of package manager or updates process that has ultimate power over the whole system. So if you install something on the deviant with upget or something like that, you can basically cause any kind of damage. So like, for example, when Microsoft distributes deviant packages, it can happen that bin sh is disappearing, things like that. OK. And on some Linux distribution, sometimes things happen like an forged archive can basically touch any part of the file system. So you have a program of ultimate power. And this is basically connected to the network. And the program is also super complex, because it uses things like GPG for verifying the signatures. It has to extract the archive users, SSL, and so on. So there's a software stack of hundreds of thousands lines of code involved in these programs. So you have super high complexity. You have network connectivity. And you have ultimate power. What could possibly go wrong? And the idea was we could do better by basically leveraging the sandboxing features of G-Node. And the idea is basically to break this software installation problem down into individual problems, and address each individual problem by a dedicated G-Node system, and then very quickly change this G-Node systems on the fly. So basically, the problems are that we first want to find out what software is actually missing. What do we need to install? Then we have to find out where to get it, the software, and also how to verify it. Once we know this, we have to download it from this location. Then when the download is complete, we have to basically check the signatures. And if the integrity is intact, we can extract it. And then we have new content. And we can look again if there's something missing. So this is like going in iterations. And now for each of the steps, we can look how to accomplish this. You see that in the center of the whole thing, there's this download manager. So this is the component that orchestrates everything. And this is really critical. This must be protected by all means. And this download manager does not do any dirty work. It is even picky about touching files on the fly system. It won't do that. Instead, for example, to find out what's missing, it basically uses a companion genus subsystem and configures this one to spawn a kind of minion kind of component that does the dirty work for this guy. So the download manager just tells this one, please find out what's missing. And so this guy starts walking around, looking at this part of the fly system, and finds out, ah, I need this and this new content, this is missing. And reports this back to the download manager using this report interface. And next step, the debug query component is basically then commissioned to work to find out where to get this software from. And once this information is cleared, we know, OK, we want to have this content, and we can download it from this and this place. And now let's download it. And here, things get really dangerous, because now we have the network connectivity over here. And we have now a whole software stack for downloading the content. Like the TCPIP stack, ported from Linux, SSL, QL, and so on. And so this is hugely complex. That's a complex thing. It's connected to the network, so we assume it's compromised. So an attacker can go from here inside there, and it could also land in this kind of place of the fly system. So this is basically our assumption that this is already infected. So in the next step, we completely cut off the network connection, and replace this whole networking stack with another component, with this verify component. And this one only has access to this part of the fly system. And while doing the verification, no other component touches this area. So there could be no network application writings to it. But so we know that the result of the verification is basically integer. So in the end, we have this decision, good or bad. And we can basically then go on and extract it. And here it's another consideration. Let's say I download some software from a company I don't trust. I still want to use this software, like, for example, Adobe Flash Player or something like that. So I want to use the software, but I don't trust Adobe. So if the signature is right, I'm still not happy because, yeah, I don't trust them. So what I want to enforce is that everything that comes from Adobe gets placed in a dedicated area on my hard disk that is labeled Adobe. And I can wipe it off the hard disk at any time. And this can be accomplished by just having this change root component here. Basically, it intercepts this fly system session here. And the extraction program can extract content only to this particular part of the fly system. So that means that we can install with G-Node and with the scriptless, we can install fearless applications from untrusted parties. And we know that this is integer, but we can, of course, we check the signatures. But we can just do this. And once we deploy the applications, we still can decide what kind of resources to hand out to the application. So for example, if for some reason the Flash Player would like to access our config FS, we can still just route the session to an empty RAM FS and then virtualize everything. So OK, now enough talk. Maybe I am happy to show that it really works. Let's see if we have some component here. It's not yet installed. Let's, for example, click on this one. So now the system will probably find out that it's not installed yet, this program I have clicked on. And now here you see that it now fetches the content for this QT application. Yeah, that's, don't worry, but it's working. Ah, we were at the point of a slow micro-conveyor based systems, right? But I think it's not slow, really. You can use it, and it's practical for day-to-day work. Would you want to tell something about Hedermas, right? No, maybe I don't. If you let me speak, then I will just go on. That's right. So here we have this QT application. So you see here that now we have just installed and deployed this application. And so the system basically blows the line between deploying and installing. It's basically what's on the hard disk, the depot on the hard disk is basically just a cache. We can wipe it off, and we can click again on the item, and it will install what's needed on demand. OK, that's the point where I would like to wrap up. Thanks for the chance to present it here. And if you'd like to look at it, you can find it on our geno.oxide. And yeah, that's it. Thanks.