 Hello everybody. I am Vladimir Serbinenko and here is Maria and Daniel. And we would like to have a short presentation about Grubb. It will be mostly in the foremost news bulletin, what happened recently, what is our outlook and a couple of other things. So first thing is that for quite some time, I was the only active maintainer of Grubb. At first it was kind of okay because I was a student, took quite a lot of free time. But then when I started working, first my thesis then started working and it was difficult time management for a long time. We couldn't find anybody else who would want to become maintainer and simultaneous to have the skills for it. And now fortunately we have three people. So three additional people. First is Andrei, he couldn't come. Then we have Daniel. And we have Alex Bulmashev, who also couldn't come. Second thing, we have a 202 release going on now. We have already released the 202 to release candidate one. So now we accept only critical patches. We have a separate branch for new features. It's branch called Next, but it's really not a priority at this point to review new features. So if you send a patch for a new feature right now and we don't respond timely, it's not because we ignore you. It's because we prioritize getting the release done. And we expect to have the release at the end of February. And we are not aware of any release critical bugs in release candidate one. But we are all humans, so most likely there are bugs there. Most likely there are release critical bugs and we need help from you all to find them. So fire up your favorite machine, your favorite problematic machine and run it and report the bugs. And the 202 release candidate one is available as a turbo on that address. And additionally it's also available as a git tag in our repository. What we have new, we have now new supported platforms, especially ARM. For ARM in the last release we had nothing. Now we have three flavors. We have U-boot flavor, ARM EFI, 32-bit EFI. We have 64-bit EFI. There is work in progress for ARM core boot, it's not part of the release. It's a separate branch which probably will be merged not far from now but after the release. And we have sent Paravitualized guests, which is great from security point of view because this way file system parsing and kernel parsing, everything happens in unprivileged domain rather than doing it in privileged domain or trying to get the kernel somehow from unprivileged domain to privileged domain. Then we have new multi-boot two features. Daniel can speak more about them. Yeah, it's quite difficult because it's quite a long story and difficult. So I was working on Zen at the beginning and when EFI appeared on the scene on many machines YoungBuelic added EFI support for Zen but it was simply a simple P-application and configuration for Zen was passed in a special separate TXT file. So it means that it was quite difficult for developers to change configuration during boot and grab to allows you to edit configuration, just changes in the menu or something like that. So many, many people asked for support, direct support to have a chance load Zen from grab to. So I started working on that and I quickly realized that we need a new protocol which is currently called multi-boot two. Yeah, I know it happens. So I took a look at it. It was in grab available but unfortunately there were two important features missing. One thing was that multi-boot two was prepared for BIOS platforms. So it doesn't knew anything about EFI and also it wasn't able to pass EFI information EFI boot services function to operating system. So we needed to add special options to pass this information from EFI directly to the OS. Another thing which we met is related to allocation of memory on EFI platforms. Many platforms use low memory, very low memory regions to store runtime services, boot services and it means we cannot load, for example, Zen image in a given region because in Zen this region is strictly specified in the header. So we found out how to do that. We added support for self-rocketable images. Unfortunately we haven't time to add support for ELF relux yet but the framework which is there, ALOSAT. So currently the working example of this feature is available on ZenDevail MyLink list and I suppose that whole working solution will be available in ZenUpstream. So that's it. Thank you. And of course we have added plenty of fixes. And then a couple of future plans and ideas. We have already tested framework for GRUB that we use for every release but the problems that some of the tests require are root. They are basically FS tests. They create a file system using Linux and then try to read it using GRUB. We would like to make it work without root. Then we want to need to have some kind of automatic system which would regularly check GRUB3 so we can find bugs quicker. We work in kernel verification which will be the next slide. And of course it's community project. So it's driven by the contributors and this includes all of you, everybody who wants to participate. For kernel verification there is now a lot of push to have some kind of ways to verify that the kernel is what you expect it to be. There are different ways of doing it. They are all back by different political groups. They have different purposes and so on. And the problem that we have at least three different incompatible patch set already available. GPG signatures, TPM, and EFI Secure Boot via Shim. So the first one is already upstreamed but the second and the third one are just a patch on mailing list and they are not compatible between each other as far as I were. So the idea is that after the release at least I have a separate branch which adds a framework for verifiers and allows all the verifiers to peacefully coexist. And now Maria will speak more about group mascot. Hello everyone. I would like to introduce a new better version of group mascot. When I started to contribute to the project I realized that this well-known project has two logos already but no one knows it. And I discussed this with the maintainers and they agreed that we need something new and is noticable. So we decided to make some nice looking mascot. In my personal opinion animal mascots are the best solution because they are really noticable and eye catching. Of course everyone here I suppose knows the Linux Tux Penguin and he was a kind of inspiration for me. After the discussion with the maintainers we decided that the crab would be nice and I started drawing with this hand drawing. The main idea was the crab running, launching the balloon like operation system. There were some versions then we made it better in 2D then we tried to do it in 3D and that's the final version right now. But it's now in a better tasting stage. We found already a bug because many people suppose that's a grub OS and I see that we should do something with that. That's not a grub OS, it's a pure grub. I am a software engineer, I'm not a designer by my primary education. So if you have some suggestions or would like to add something feel free to contact me I'm not pretty sure should we do it in the developer grab developer mailing list or separately. So now just please send me a personal message. I would really appreciate your help and waiting for your suggestions. Also I would like to inform you that we are going to have a face-to-face meeting with maintainers. Today at 8 p.m. in Gem Hotel rooftop bar it's not totally about drinking it's more about discussing new features about grub development and so on. So if you would like to ask some questions say something about the grub, about the mask and so on feel free to join us. Of course everyone pays for himself or herself if no one will come there we will live at 9 p.m. And if you need some further information you can ask me as well. You can see here my email and you can ping me in handouts using this email. If you want to join just take a photo of it and we are waiting for you. Thanks a lot for your attention and we are waiting for questions. The question was how we support NVMe. This depends on the platform. First of all if you use EFI or BIOS and either of them already supports NVMe then grub will just use them. Grub does not currently have its own NVMe drivers. First we have some own ATA and SATA drivers but they are not used by default because they would conflict with BIOS or EFI. They are used by default on Corboot and on BIOS you can use your own drivers for grub but currently there is nothing for NVMe but it's basically patches are welcome and my experience shows that drivers for grub are actually much easier to ride than drivers for fully-fledged operating system. So right now we support it only if NVMe supports it. For touch screen it's not currently supported but we have all the underlined things that we need. We have USB support. We have the support for graphical menu. From there it would actually be pretty easy to write touch screen support. So if somebody wants to write it just drop me an email and I can give some guidance. Thank you very much Vladimir, Maria and David. Daniel.