 Okay. The next talk is going to talk, it's more like an extended demo session, given by Norman Fester and he's going to demo the Scout for us. Yeah. Thanks for the intro. Yeah. I always try to make it a point to present running system during the talks and this time is no different. When I submitted the talk in the first place, I thought, well, I will show my day-to-day OS that I'm working and just think around and give you an impression. But after I submitted the talk, I had some pretty different ideas how Sculpt OS should be heading, and so I got captured by these new ideas and thought, well, when now showing the system, I would really like to show the new system that I have in mind. That's what I'm going to do now. So it's not the current version of Sculpt but it's the new version of Sculpt. The problem is it did not exist at this new version, so I had to build it first. So some parts that you see had been literally built in the train to foster them. So please be with me if there are any trouble, but I think it's still more worthwhile as a message for you to have this talk this way. So first, I don't know who of you knows G-Node. I will give just give, there's one hand. Okay. I will give a brief intro. So from over a decade, we have been building this kind of component-based system. So we started with an idea of a new architecture as a clean slate operating system, and we continued evolving this over literally a decade. So you see here in this picture, this idea that the system is built out of these basic building blocks. In the middle you see, I can also use the mouse. You see there's kernels here. So G-Node supports a number of different kernels and the kernel developers are several kernel developers are sitting in this room, like the SCL4 kernel is supported. Hello G-Node. The Nova kernel is supported as well. Hello, Udo. So there are even some kind of nostalgic kernels supported. So he supports the Fiasco kernel from 12 years ago, just as a matter of kind of nostalgic reasons, and it also supports the Linux kernel. On top of that, there are plenty of components like these building blocks. The color for the stacks, the device drivers, multiplexers for physical resources, so lots of these components. While doing this, this is of course exciting work to do, but people always want to, what the heck? What are you doing? So nobody could make any sense of this. It did not fit into a well-established category. It was not an operating system, it was not an application, it was a library, so what is it? So it's basically similar to the concept of Lego. If you present the kit the first time a bunch of Lego bricks without giving any instructions, the kids doesn't get excited really, if they haven't seen this before. They maybe tinker around a bit, but if you supply also a brochure to teach the kid how to build a nice ambulance car out of these bricks, then the kids will follow this brochure, get an example, and their imagination gets started. And we figured out that in order to carry out in the message what G-Node is, we need to have an example. And we thought ambulance cars probably not the best example, what would be a cool example? And we found that a general purpose operating system would be a cool example. And this is what script OS is all about. So this is running on this machine right now. So I just put it into this machine, into this system here from the USB stick, and I can switch on and off the slides here with the F11 key. And yeah, the system that I just booted contains a microcunnel, in this case the Nova microcunnel. It boots then a static system, which is very simple actually. So containing only a few components, I will go into a bit more detail in a minute. And then on top of the static system, there are three dynamic systems, one for doing some basic drivers, like the graphics driver that I need to interact with the system. One system that I use to control the machine, that's the light-centrale, a kind of sophisticated controlling panel. And then there's this green part where the user can basically do whatever the user wants. That's the basic idea behind the system. So let's look at this strange user interface again that you have just seen. So what is this? This is the system right after booting. So you see here in the middle a graph of the stuff that is hosted inside this runtime part, inside this green part. And you see here that there is some kind of storage node and USB node, hardware config. These are basically hardware resources. And there's one little component sitting here that's just a small RAM phy system. But there's more behind the curtain. So the other things that are in the static system, there are some more concepts involved. And the static system basically contains this graphics server that you have just seen. Then it implements some global policy. For example, by pressing F11, I switch the slides on and off. And there are two pseudo phy systems. One pseudo phy system is called a report phy system. It basically aggregates states from the components. So components running on top. They can basically post information. And these information are basically captured in this memory phy system here. And then there's a counterpart that's called config phy system. This contains configurations for the basic system. So these are the only concepts to administer the system. And yeah, let's have a look inside this kind of phy system. So we have here this phy step. So these are the phy systems that are present on the system right now. And we can now, for example, look into this report phy system over here. We find that R, some driver, has reported something. So there are these drivers item here. Is it big enough to read? No, not really. Maybe I can, I try to make it a bit larger. Okay, so there are some drivers have reported something. So let's look inside. Okay, there are some things like PCI devices. So we have a report of the PCI driver and this delivered the number of PCI devices. So this is basically similar to LSPCI. Or we have the number of USB devices. We can look at what the USB driver has reported. And so we see this information here. Then there are some dynamic drivers. So for example, there is this Intel frame buffer driver that was dynamically started. And let's see what the Intel driver has reported. Ah, number of connectors. So we see here that we have this HDMI connector with the supported resolutions. So this report was generated by the Intel driver. And this all comes together in this report file system. So you can basically look into these interesting pieces of information inside this file system. The other part is this configuration file system. This is this one. And this contains all kinds of system configurations. For example, also things like the screen resolution. So for example, look inside this frame buffer driver here. This is really the configuration for the Intel frame buffer driver. So there's nothing in between the frame buffer driver and our text that I have here. And I can even change these things. So I can type in something like this. I want to force a size of the display to a certain size. And the driver really consumes the new configuration and applies it. So I have now just reconfigured this driver here. So let's revert it because this gets too tiny. So now the driver has reestablished this. And for example, also the GUI server that is on the bottom of the system, I can reconfigure this. So for example, you see the slides over here. If I want to say, OK, the slides, I want to use the slides as a mouse pointer, I can do this by telling the nitpicker GUI server that the origin of the coordinate system of the slides domain is the pointer. And so when trying to go, oh, it's not working, really? Let me see. So that's one of the parts that I implement on the train. Let's try it again. Oh, yeah. Thanks again. Thanks you. So now the slides are used as a mouse pointer. OK, so that's just silly, but you see the basic idea that you can even change these really basic fundamental parts of the system interactively. OK, so that's pretty nice to play with, but it's still quite useless. So in order to use the system, we need some more. So let me go to the next topic. We want to use and download and install some software. That's some basic functionality of an operating system. So OK, what do we need for software installation? We need a place where to put the software. So in this case, we have conveniently this RAM file system over here. So I can just say, I want to use this one. So now you see something has happened here. There's a new component popping up. It's called DPO. This is basically a kind of change root component that exposes only a part of the file system to be used as a storage for new software. And let's have a look how this DPO looks right now. So when you look into this RAM file system, you have the stop directory DPO here. And inside the DPO, we have prepopulated some sub-directories, one sub-directory for each software source. So these are the genome developers, basically. So if you look into nFesca, this is my one, you see two files. So there's this download file. So this is the location where software can be downloaded from, just a web server. And then there's my public key. So this is the PGP key that can be used to verify downloads. So all downloads that I'm offering are signed, digitally signed, and this key is used to validate the integrity. OK, so this is basically, we now have a place where to store software. That's fine. So the next thing is we need network connectivity. So I tried to connect to the network. So there is this kind of crossing fingers. OK, first and foremost, that sounds nice. Let's see. So it's associated to the network. Let's see if we get an IP address. It can take a while sometimes. Ah, so OK, that looks not bad. So now it's this kind of nice widget here appears, this plus sign. And this one is basically the entrance to the world of software offered by the genome developers. So here you see plenty of and disconnected. Oh, that's that. Maybe we have to wait a bit. This happens sometimes. It's not a genus problem, you see. OK. Should we just try it again? Or ah, now it's ML solution. OK, so maybe I would still try to continue this. I think, let's still try. So the idea is that you have this menu here, plus sign, is to add a new component. That's the idea behind the plus. So when adding a new component, you can choose from a menu of predefined menus. So you can, as a user, can also change this menu. But the interesting things happen here, and it's depot dot dot dot. So this is basically the software by the genome developers. And here the depot is empty, but we can make a selection. So here I select the developer I want to use software from. Yeah. So by clicking on Enfascade, for example, you see that now I downloaded a kind of catalog of software that I'm providing. But I can also click on, for example, my colleague Alex. And then now I also have the catalog of software that my colleague Alex is providing. So you can basically subscribe to different authors similar to subscribing to an RSS feed, basically. So now I go back in this menu here. You see now there are these new entries. And when going into this Enfascade entry, you see that there is a menu that I provided. I offer you some software. And so, for example, I can go into this GUI menu and there is this backdrop application. And when I click on it, I can basically install it. And now you see it over there. It fetches the packages, the dependencies. And all this stuff will be downloaded into this depot slash Enfascade. And this is a completely sandboxed over there. So I don't need to trust the people I don't download the software from. It's all sandboxed. And now once this program is downloaded, you are presented with a dialogue that asks you how to integrate this software into your system. So in this case, it asked me to connect the GUI to some basic services. And we want to plug the desktop background to the components. So we set up this one. And here we have our desktop background just downloaded from as a package. I give you another walkthrough. So maybe just to get an idea. There is, for example, a window manager we can download. So I install it here. You see on demand, the download starts over here. And the window manager requires some more information. So it wants to control the keyboard focus. So I allow this. It needs the basic GUI service to display windows and declines. So I connected to the system GUI server. It wants to report shape reports for mouse shapes. So I connect this pointer shape to the global system shapes. I connect the access to the clipboard and also for the different directions. And then adding this component. Now this window manager exists over here. You can see this. And there's still nothing shown, because we have not started a client. So let's add a client to this. So let's add a client to it. For example, there is a small demo over here. OK. And so this client, we can now connect to this CWM. You see it here. So this is something new. We just added the service to the system. And now it's offered as a menu item over here. So I can add this component. And you can see over here, I can switch with F12. So please remember F12, really important, to switch between the light centrale and the normal user interface. So now you see this program here running inside the window. That's basically served by the window manager. And let's do a slightly more sophisticated example. So we can say, OK, we want to have some small unique system. So there's this tiny unique system that I described in a recent series of articles on the genodians block. And so let's try to install it. And you see here that it was in things like co-util spash and so on, co-util spash Wim. So there are a lot of things that you need for having a small unique system. And there are some sort of dependencies over here. And now I am asked to integrate it. And this one is really a sandbox kind of environment. So I only need to connect it to a user interface. The CMWM. And by connecting it, you can see now a new window appearing here. And this is basically I can enter a room and do some unix-like verb. Maybe I can make the window a bit hard to get this. And you see here, if you look at around, you see a very basic unique system running inside this window. So it's pretty easy to deploy things like that just by using the mouse. OK, in this graph, now things become more interesting. So for example, we can now see, OK, we have this unique system here. What is the trusted computing base of this unique system? The unique system is not connected to the network or to anything important. So it's only connected to the window manager. So it needs to trust the CMWM. Or this one is the same. But for example, this one, the NIC router, which is basically the access to the network, it's routed through the Wi-Fi driver. And it also uses some configuration obtained from the information node over here. So this graph here does not only show you the number of components, but also the relationship of between the components. And when you select one component, you see basically the trusted computing base of this component. OK, so let's make the whole thing a bit more interesting from the kind of complexity perspective. OK, that's it. So this window manager was just a one single component. But the strength of GNOT is really that you can put or cut these components into small pieces and turn them into so-called multi-component applications. And the window manager is a prime example of this. So I know it looks a bit frightening here, this picture. But the idea is that there is this nitpicker GUI server, which is the basic systems GUI server. And then there's a window manager here that basically intercepts the communication of an application to the nitpicker GUI server. So this one basically adds the notion of window decorations to the views of the application. And it does not do this all on its own. So the window manager itself is a fairly small component on about 5,000 lines of C plus plus code with no dependencies to see whatsoever, bare metal C plus plus code. And then it basically connects other components to do the duty work. So for example, there is this decorator here. And the decorator component is a component that touches pixels, that renders pixels. And it can have typical problems. Dealing with pixels, graphics libraries is complex. So there may be bugs in there. So we basically host this sandbox version of this decorator to do the duty work of rendering the window decorations. And then there is another potentially complex component, which is the window layouter. And this one defines what happens when you click on a window title bar and move the mouse. These policies, basically, the policy of the user input. And to connect those together, there are some kind of reports and wrongs used. So for example, the window manager supplies the decorator with a window layout, which is a data model of the window layout. And in return, the decorator returns the currently hovered position where the mouse is highlighted with the mouse. And so this is basically the idea. You can use different components. Each have a clear cut purpose. And you can basically connect them together. And this is what I will show you next. So for a second, I will basically, let me see. So I will basically remove those components again. And also the window manager. And now let's start the more interesting window measure. So I go again into the depot. And there is this WM package, which is this kind of kernel of the window management. So you see it's really small. Here I see it's downloaded like in a second. And here I have to connect this to the basic GUI server, the nitpicker GUI server, this is this one. Oh no, this was for the focus, right? So I have to connect this here. Then I have to connect this to the basic GUI server. And in the other example, the pointer shapes connected to here and the clipboard as well. So now the WM node is running already. So next thing is I have to add a decorator. So I take this seam decorator here. And here I connect everything to the WM, to the window management manner. So I set these routes here and add this component. So finally, we also need a decorator. So I connect this layout. I install this one. And so here we also direct everything to the window manager. So basically this way we sandbox these components under the regime of the window manager. Oh no, I forgot to start this actually. I wanted to start this component first. This is basically a component for remembering window positions. Now I notice I mistake in my script. So I have to step a bit back. What I wanted to do before I'm doing this here, I wanted to basically switch from the RAMFS to something persistent like the USB stick. So let me just do this. So let's basically unused the RAMFI system. So now the system is gone. And now let's basically use these USB sticks instead. So let's use this one. And now you see that now the same configuration is still in the configFS. So we get it back here. We are using it. We have just swapped out the underlying storage. So now let's do this step with adding the layout. So as before I connect this here to the window manager. You see this is a bit tiresome work. But you will see later that this must be only done at integration time, only once. So this one. So now we have this all connected to the window manager. And now let's add an example client. So for example, a more interesting Unix kind of system where I say, OK, I want to display this in the window manager. And I want to grant access to the config file system. So this is dangerous because this is basically allowing this component to also change the configuration. I also want to do this here deliberately. Then also we want to watch reports here. We want to connect it to a file system. We are another thing I missed. We need some other component, a font file system component. This is basically a component that provides font information for other components. So now I can go forward and install this NUC system. Let's do this here, the config file system and the reports. And the file system over here. The font file system, now it's there. And some women configuration. And for the clipboard, we go through the WM. So when doing this here, you see now this window coming up. And this is a lot more powerful than the last one. So here I have actually access to the config file system and the report file system. So for example, I can take a look here and you see all the configurations that you could see also in the GUI before. And we can also edit this configuration. So for example, I can change this input filter configuration. You see here, there's some key repeat rate here. And this input filter basically controls the input handling. I can change this value here, write the file, and you see now the rate is much slower. So through this interface, through this file-based configuration interface, we can control everything. So let's add another component of a friend of mine, Alexander. So this is a small tool for observing what's happening in the system. So we also redirect it to the window manager. Then we grant a right to use tracing to observe the global system and also to use the fonts. So now you see here a small window coming up. This is basically like a load display that I can use to explore what's happening in the system. So you can see at this list of components, you see the granularity of the system. We have like 93 components running here. So what's in the runtime is one thing, but some of these nodes actually consist of multiple components. And also underneath, there are many more components. So there are really, really many fine-grained components involved. OK. There are also some graphical applications. So for example, I can start some QT application of my colleague, Christian. So let's look here. And I think here. I think it's better to take this one. And again, I can choose what the application can see. So for example, if I don't trust this application, I can say, OK, I direct this to this, like, for example, the font FS. It's probably a bit silly, but... And then we connect it to a window manager and we say, OK, shape and flip what also goes to the window manager. And we see now a QT application coming up here. So basically, I'm just starting this application to show that this is not just limited to some text command-based things, but you can actually run like more sophisticated applications like complex user interfaces. Yeah. And I advertised this nice window manager concept, right? One cool thing I want to show is that this window layout that I'm using is actually quite special. It stores the state of the window layout on the file system. So I use this recall FS to basically tell this layout to get this information from the file system. And so now I can go into this file system here. Oh, no. This is the genot partition. And then we have this recall directory over here. And the window layout has a sub-directory that was created automatically. And in here we have these rules of the window layout. So this is basically what's currently the state of the window layout. So for example, say I want to move the Q2 text editor program to full-screen. I can say something like, or maximized. I can say something like maximized equals yes. And I can basically save the file and you can see that the state changes. And the same, of course, for other things like if I want to change the position of this terminal to something else, I can basically do this. And you can see that this is all a state that's captured. That's important for the window positioning. That's nothing more than that. And we can even do things like splitting the screen into two parts, like adding some columns there for the ideas to have some kind of tiling window management in the future. So we can add something like a column here, left. And another column. And then we can say, let's move the text editor to this column, to the left column. Oh, do I have something wrong? Hmm, did not respond. Let me try this again with the other one here. Stop looking for some reason. I don't know what I have done wrong. Oh, OK, I won't debug this right now. OK. But basically, you get the idea that you can basically have the state captured here and the system will remember this on disk. OK. OK. So now next topic. So our device drivers. So the nice thing about microkernel-based systems is that device drivers live in the user space. And with Genote, we want to really leverage this concept. So in Genote or in script OS, device drivers are just managed like regular components. So you can deploy them and install them as regular components. And the user has to explicitly run access to the hardware. The user is always in control. The drivers are sandboxed with an IOMMU and drivers can even mix match of different providers. And this goes really, really far. So I give you an example that we can do this for ACPI services even. So there is, for example, Alex, who is our expert for DPC architecture. And he provides a system menu with ACPI support for old sync pads. So I'm using this. And there are two versions. One is equipped with a nice graphic user interface. So I will basically deploy now this ACPI driver from Alex here and will display the user interface as a small battery applet in the window manager. So let's connect via this app. And now it becomes scary. So we have to say as a user, oh, direct memory. Oh, aye, aye, that's what we want. Do we want this? We can safely do this because we have had an IOMMU. So in worst case, the driver will only shoot itself in the food. So let's do this. But here, this is more of a problem because port IO can be used to everything, to completely reset the machine. So, OK, let's grant this access. Also interrupt, OK. Then for devices, we basically say, OK, we only want to present the ACPI driver with an MTPCI bus. So we select this ACPI profile here. Then we also want to expose the low-level kernel information. And we want this driver to watch system status from the configuration. So this is what I'm selecting here. And it should report interesting things to the system reports over here. So this is really a risky. So I should only do this with software from people I trust. But in this case, I trust Alex. And you see here now this battery applet here showing the battery state. And I can observe this. And this can only be requested using ACPI. And another example is audio drivers. So in this case, my colleague Joseph comes to rescue. So he has some experimental port of the VST audio driver. And here we say, OK, we expose the audio hardware to the driver and add this component. So here you see this one. So now I need a program that uses audio. Let's see what Joseph has in his menu. I think this one should work. Connect this to the audio driver. Display it in the WM. And of course, let's do some network connectivity. And now it's basically, let me see. There's some window. Ah, it's hiding. OK. But here it is. And can you hear it? Maybe I should take you. So maybe you can't hear it because the speakers are too silent. But there is actually audio coming out of this laptop here. OK. So this is actually also working. So removing this again. And I can just walk out the audio driver if I don't need it anymore. OK. So next topic is when using Sculpt as a day-to-day OS. We of course don't want to start the day with wiring up all these components. Of course, this can be like meditation, but that's not a productive way of working. So we have to basically have a way to make these configurations permanent. And the idea is we already have all the configurations in this config file system, right? So if you have also a place on the USB stick or on a boot device that also has the same layout, we can just copy over the stuff from the boot device to the config.fs and we are done. And so for fixing the configuration that I currently have, I basically only have to move this configuration to the USB stick. So let's do this using this shell here that I already have. So if I go here, remember we have this config.fs here, accessible, and we have this access to this genot storage over here. And so we can just add a new directory. It's called config and then the version of script. In this case, this is the script version. And then we can copy interesting things that we want to save. So like for example, I want to copy the current situation of the component state, the current deployment. So this is all captured in one file. So I can copy this file into this config.fs. This is the one. Maybe I also want to capture the Wi-Fi password. OK, let's do this. So I can copy this config Wi-Fi that I just selected and put it also on the USB stick. And maybe we can also tell the system to automatically connect to Wi-Fi instead of leaving the network undefined. So we basically route the NIC traffic to the Wi-Fi. So these are the things that I have customized basically. And now the next time the system boots up, it should get this information copied from the USB stick into the config.fs. And it should become active. So what do you think? Should I try this out? That's your question. Are those text files? Or is this finally? Yeah, it's all text. So if you look into the deployment here, you see that this is the right one. I mean the one that was created by the managed. Did I just copy it? Yeah. This is just a text file here. And this basically contains all the wiring also. OK, what do you think? Should we try to try this out? OK, so here we do another nice feature of the ACTI driver that we have running here. So I remember I said that this watch has a special config node. So I can open this here in this config.fs. There's the system here. And I can basically here define the system state I want to have. And there is a commune system state that's called reset that's right this to the file and see how. So now crossing fingers again. System state reset. Yeah, you can always take a bare, fresh USB stick. And in this light centrally, you can basically modify the content of the USB stick. It's all text files and you can fix things this way. Yeah. And now we see, OK, it has detected the USB stick. OK, it finds out what's required here. And the USB stick, the light is blinking. So it's fetching some information. And here it already looks quite good. Yeah, here we are. OK, so for as a last small demo, maybe I can just swap out the USB stick with the hard disk. Time's up. No, 10 minutes. OK, so I will just unused the USB stick. So now we are basically back where we started. And I can select this, my hard disk over here. And can say, OK, I want to use this. And now this is basically what's happening normally when I enter my office and start a machine. It opens a system that looks a bit like this. But it also spawns a new virtual machine. So this virtual box over here that's running in the background. You can also see here how this is now wired up in the system. So the trust computing base of the virtual machine is, of course, much more interesting. But you can see it has access to this shared folder over here. It has access to a special sub-directory where the VDI image is located, but not access to the global file system. It only has these kind of change-rooted access. It is connected to the network. You can see it here. And it is connected to the window manager. You can see it here. If you have a user, you have very good control over the way of how the software interacts with the platform and the other system. And so this is my normal regular Linux system that I'm using for development work. And when I log in, I can basically do some productive work. And maybe there are some other slides, since we still have some minutes left. This is basically the copy and paste topic. So we have some special kind of idea of how copy and paste should work, also inspired by discussions with you guys. So the idea of the copy-paste mechanism in G-Notice that there is a clipboard at the bottom of the system here. And this correlates user input with clipboard activity. So for example, if the user presses Control-C or presses a copy operation in the menu, then this clipboard will know, ah, this input event came from the application and now it will be open for clipboard interactions. Otherwise, an application is not allowed to obtain clipboard content or post-clipboard content. And so we drastically reduce possible information leakage between applications. And maybe I can give you a small example. So if I start a program here and do some output, some string over here, I can basically select some text here, copy this, and now I have this nukes. This is this minimal Unix environment and I can paste it over here. So you can also basically integrate the different components at a user level. Okay, so that's basically my content I wanted to present. And to wrap up the talk, the story will continue, of course. So in this year, I want to further improve the usability of the system. Like keyboard navigation and light central would be really nice, especially for selecting these routes and also improving this kind of interactive file management. So my plan is to completely remove all kinds of traces of Unix from the BAR system. Yeah, and then further, I think it would be nice to also offer some kind of on-screen documentation so that as a user knows what to connect and what are the implications. And another project is a block device encryption and another thing is that you want to, of course, move away from virtual machines but use native components. Okay, thank you. By the way, one last word. I have made this image, this experimental image available on the Internet. So if you are venture-some enough to try it out, you can go to the first website here and there you can download an image and put it on a USB stick with DD and play around, give feedback. Yeah, okay, thank you. Are there any questions? Yeah, please. Just a question. It seems like that Geno is using XML as a format for configuration. It's very rational behind this and the second question is couldn't you have, like, a DSL to have a programming language for your configurations and you can do, like, control through instruction in your configuration file and do some incredible stuff? Yeah, so the question was we are seeing some XML here in this demo and Geno relies on XML throughout the whole system and was this a deliberate decision and then the second question was is there some kind of meta way of producing this XML? And so the first question is at the beginning of the project, 12 years ago, it was obviously to use XML because it captured all our requirements to have these kind of nested nodes with these attributes so we can express everything in XML. We don't need to encode all the complexities of XML here. So this is just a subset. So you cannot, for example, have kind of including others and things like that. No, it's really simple. It's just this syntax looks like XML and so it's tailored to the needs of Geno. And so, of course, you could say JSON or S-expressions or whatever is nicer but it comes down to the matter of taste and XML does everything we need and there are made mature tooling like validation tools like this XML and so I think it was a good decision to go this way even if it's not trendy, some people want to configure differently and then, of course, there are people like Emery who are not satisfied with XML yet try to improve the situation by introducing some meta way of totally using these configurations but here you, this is really there's nothing between XML and the application here. So this is really a tight interfacing and so you can, of course, add another in direction always but you have to settle on one basic mechanism and here I think the great contribution here is that you use it consistently throughout the whole system. There is not a bunch of different syntaxes found around but this thing is coherent, yeah? Okay. Ah, please. Excuse me? Ah, that's a runtime. That's a custom runtime, yes. But this is something that we want to get rid of. We have a much nicer way of running Unix software and you don't know but this is another talk maybe. It's now it's possible to use JASLip C to implement this. So, ah, okay, please. You have a manual distribution of capability, I mean, that's so it's became obsolete with the time and it's very uncomfortable to adjust all these things. I don't see it here but how you manage all this distribution of capability sizes between So this is not done, ah, yeah, okay. Thanks. So I should repeat the question. So normally if you look at other systems that wire up capabilities, you see this kind of explicit step of creating these capabilities and then passing them around, relegating them. And in our system you don't see this, right? And that's because the user doesn't care. The user does care about relationships between components. And here we have an abstraction over this capability concept. This is called a session concept. So it's described in more detail in the book, in the Genote Foundation's book, this one here. So if you want to talk about how Genote works and how the concepts of Genote are backed by this underlying capability techniques, you may look into this third chapter of this book. There is a thorough description there. Okay. I think definitely, because everything is virtualized here. You have basically nested sandboxing. I should repeat the question. Is it possible to use a system like this for establishing the notion of user sessions to have different user profiles on the system, like a public facing computer, but as a special user can also have a different kind of profile. The underlying technology, of course, it can do this. It is not supported, but you can see how this is just another interaction. So adding a kind of user identity in the form of a component that might be the most straightforward way to do it. Okay, are there still times up? Okay, again. How hard is it to port software to Genote? That's a very good question. Thanks for bringing this up. It's actually how hard is it to port software to Genote? So that's a very good question because I think Alex has talked in his talk about the porting of the Android runtime to Genote, and this is quite feasible, but it's still quite a manual labor. And especially today there are many different build systems like CMake and so on. And Genote has an own build system, of course, and the traditional way was to basically port the supported software into the Genote build system. But this does a scale, of course. And so there's a new tool that I'm developing. It's a Degora tool. It's called, you can find it on the GenoDian side. And this tries to streamline the workflow with porting support the software to Genote. So basically the dream is to have just a recompile and then the software, you can deploy the software directly on Scoop. That is the idea. But we are not there yet. Yeah. First you? Yeah. Okay, I should repeat the question. So I was asked to give other use cases of Genote besides this desktop computing. And so the use cases are basically there are these embedded use cases where Genote is used in network appliances, for example, where you want to split the control plane of network from the data plane and this component-based system is quite natural to do such a thing. So there are people also building products in this direction. Then there is also the embedded space as well like the upcoming IoT kind of hype where you connect devices to the network all the time. And so here adding components like component-based trusted wrappers to filter protocols it fits so well together