 So this is more like a video thing, but I have to be able to talk, but nevertheless I would like to show you basically how our current users look like that use everyday at new depths. So this system is called SculptOS, and maybe if you like you can download it from outside, so it's there. 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 really a 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 fabricated. And the idea was that this is so tiny that you 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. Maybe 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-Node world. So you see it goes up pretty quickly. You passed it in logo, logo. So at this point, when you see the first lifeline of G-Node, there are already about 60 components running. So in contrast to your Gouda Look system, you have one big program with everything built-in. But here we have these tiny cut-sures to send boxes. And each tiny functionality, like the USB driver, the PS2 driver, all the different parts of the system, they are each send box in a dedicated component. The system has some kind of mini-modistic user interface 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 Light-Central, 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 this light overview of how the system is constructed. So this is just boring, but this one is interesting. So what we have in the USB stick is basically the system, the Gouda Micro-Colonel, about 10,000 Ln code. We are using the kernel of this gentleman over there. It's with NOVA hypervisor. And the static system comes with a small static system, Gouda, on top of the tunnel. 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 subsystem. Then we have the Light-Central. This is basically the user interface to interact with the system. And then we have the place yield for the user, the actual useful stuff happens. Like the programs that I want to execute. And what you see in this graph in the middle is basically the current state of the runtime. So on the right part of the system. And you see when I started this computer, there were quite a few components that I already started. And for example, I can switch between the Light-Central and the real desktop using F12. So when you 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 built. And you can at any point in time, begin control of our system, recorders of what happens in 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 you know, this is to tell me the virtual machine requires some kind of networking. So I say, okay, 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 the SneakRouter is basically something like a NAT device. It 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 to connect to this. And so we have in the background our virtual machine, pull it up. So you see it here. This is just a Linux VM. And the virtual machine module is basically a port of VirtualBox OGNode. So it is able to execute all the guests that can be running in VirtualBox. 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. Sorry. OK. 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 GNode 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 file systems. So these are basically RAM file systems. A bit like 10.x or Linux. They are just empty at the startup. And in this case of the configuration file system, there is some initial content fetched from the USB stick. And this is put in there. It's part of the image. And the purpose of these two file systems 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 centrale, we can basically access those files 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 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 mount attributes for those files. 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 to 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. So 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, you 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 Intel graphics driver is detecting, we can say, OK, let's look at the driver subsystem. And there we have a dynamic part where the Intel driver is running. And then the Intel 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 guessed it, I guess, modify the configuration of us, 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 by the size of the fonts. And the bottom line is that there is only one interface for these configuration problems. 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. 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-central. So let's use this as a mouse pointer. Like we can do the same here. And now we have the light-central 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? It's always amazing. OK. Thanks a lot. OK. Maybe another unique point about the sculpture system is that we of course 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 who provides this 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 update process that has ultimate power over the whole system. So if you install something on the devian, with upget or something like that, you can basically cause any kind of damage. So like, for example, when Microsoft distributes devian packages, it can happen that bin SH is disappearing, things like that. Like, yeah, OK. And on some of those distributions, sometimes things happen like a 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 uses SSL and so on. So there's a software stack of hundreds of thousand 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-Note. And the idea is basically to have to cut this, to break this software installation problem down into individual problems and address each individual problem by a dedicated G-Note system and then very quickly change this G-Note 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 you notice, 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. 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 G-Note 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 pork ferry 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 the 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 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, with G-Node, we can, with the scriptless, we can install peerless 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, okay, now enough talk. Maybe I can, 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 there is no, it's not installed yet. This program I have clicked on. And now here you see that it now fetches the content from, for this QT application. And, hmm? Yeah, yeah, that's, don't worry. But it's working. Ah, we were, no, we were at the point of slow micro-convex 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, would you want to tell something about Hedermas, right? No, maybe I... Yeah, 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, this 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. Okay, 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.org site. Yeah, that's it. Thanks. That looks more unmuted. Okay, hello. This is me again today. I'm Jakub from Current Concept, but this time I am stepping in for a friend who was originally supposed to deliver this much longer talk about Hellenos and the evolution of its file system layer. Unfortunately, he fell ill. So I would like to take this opportunity and only give a short Hellenos update in the remaining eight or so minutes. So for those of you who don't know how Hellenos looks like and what it is, I can show you a short demo right from the beginning. So I've just started off Hellenos. That's interesting. So this is Hellenos running on AMD64, but we also support some other architectures like Spark64, Itanium, ARM32. Today, the microcranel in the room had a visitor who is no longer here, I guess, Petr Pavlu, and who suddenly appeared from nowhere and wrote a message to our mailing list saying, by the way, here is a port of Hellenos to 64-bit ARM and I've been working on it for four years. So you can, of course, control Hellenos the usual way. Just don't get confused or don't get mistaken. This is not a Linux distribution even though some of the commands might give you that impression. But everything that I am running right now so this was the audio stack. Everything I'm running by now was written by us or some students that we were supervising. Hellenos is probably one of the very few microcranel projects that actually writes its device drivers and file systems and networking stacks itself. So to contrast this with L4RE that I spoke about previously where the way would be to take some existing component, maybe a whole VM which runs the networking stack or provides some device drivers, we would write them ourselves. And especially this is true for the gentleman who was supposed to deliver this talk in the first place. So we can do also some fancier stuff in our agree but I don't think we have that much time to play with that. Just ping the local host. We can't ping a local host. We can ping a non-local host like on QMU. It's a different number. It's like 10 or 15. Is it 15? Never mind. This is supposed to work. But in general, you can ping something out of the, something which is listening on the network interface but because there is no kind of link to the local host you can't ping local host. That's like a small variance. So enough with the demo itself. Let's just see what we have done since last was done. So there was a release in July. Hellenos 07.2 was released. Some of the highlights are a rewrite of the USB stack. So we had a group of students who wrote a new USB 3.0 stack by adding the XHCI controller and basically rewriting the stack from the most part. We did some device drivers like VertiOnet. Another student worked on adding C++14 support for C++14. And we finally did something about our Lipsy compliance because when we started like many years ago we were, I think Norman describes that as a cowboy attitude. We were like, yeah, we can do everything. We won't be compatible with anything. So that changed a little bit. So nowadays we tend to draw the line at the standard C library and try to be compatible on that level and throw all the other legacy away. I did some capability work for which I would refer you to my talk from last FOSDEM. Jirka, the original presenter of this, he worked on automatic volume mounting. So whenever Helen knows spots, file system which has a volume, it automates it. So that's kind of like when you have a flash disk and plug it into your Linux or Windows computer, it automatically gets mounted. So this is something like that. Then in another release which happened in December, we switched to our custom GCC target which already managed to slightly backfire. But other than that, it's a pretty good idea because now we have the whole thing that builds when it's under our control and there are no surprises in terms of what the compiler can do if we squat on the Linux target that we were using previously. We had some improvements in the kernel. Basically, there is a new red-black tree-based data structure which replaced the existing AVL and B-plus trees and is heavily used in memory management. The new data structure has just slightly better API which is more favorable to memory management because it does not allocate anything on its own. You have to pass it memory. Then we threw out a couple of things like the complete RCU and concurrent hash table implementation because we were not using it actively and there were some bugs and the thing was not maintained. And in the spirit of this new phenomenon, was it Marie Conde? Is her name? So it didn't spark joy, so we completely removed RCU and CHD. So then the work on the volume manager and the volume layer continued. Now the system is trying to preserve slash W as something which is always mounted with the file system on which Linux was installed. Then there were some fixes. Also, the capability work continued. Some new packages. So now you can install a package which is a ZX Spectrum emulator and there is another one which is not a package yet but rather a branch of Hellenos on GitHub which is a NES emulator. So if you happen to own some of the ROMs, you can even play some retro games on Hellenos right now. And as for what new features were added to Hellenos after the release. So unlike before, when we only supported Dynamic Linking on IA32, Irka, the guy who should have been here, he also added Nd64 ARM32 power PC and Spark 64 Dynamic Linking and I believe that he is working on the remaining architectures right now. I show you the PCI utility at the beginning. So that's just a utility which allows you to see what PCI devices were discovered by the device driver framework. And I already told you about the pending ARM64 port of Hellenos. As for the plans, Finish Dynamic Linking support. Martin is working on RISC-5 support that would nicely complement our collection of supported architectures. Of course, there is still a lot of work to be done on the capability front. As for this file system management, I think that translates to changes that are related to this file system work and volume management to make the system more user-friendly. That's one of Irka's goals. And also in the same vein and the same category, work and persistent and work configuration, I am also suspecting he wants to rewrite the graphical user interface that I showed you at the beginning. We revived our Doxigen documentation, which was non-existent for a long time. And probably the last thing, yes, the last thing I would like to mention is there is going to be a new Vertioblock driver because we realized that by having one, we would actually allow some more exotic architectures like Spark64 and PowerPC and probably also some ARM ones to have an actual block driver, which they don't have right now. And we are constantly struggling with making the boot image small so that it fits and can be booted from. Having a block device driver is one of the things that we need to switch to a fully supported scheme like we have on X86 where we can boot from an installed system. So Vertioblock driver is coming and thank you for your attention. Hello? Okay. Okay. Okay. Okay. Okay.