[00:00.000 --> 00:17.600] Hi, everyone. I'm Razvan. We are now a part of the microchannel component-based OS Devroom. [00:17.600 --> 00:21.880] It's a pleasure to have you all here. We're going to start right away, so we have, I think, [00:21.880 --> 00:27.560] 10 talks. We're going to delve into microchannel, unical, and component-based OS topics. We're [00:27.560 --> 00:31.680] going to start with Martin with his talk on the state of the microchannel environment. So, [00:31.680 --> 00:38.520] Martin, please go ahead. Thank you. Good morning. Thanks for coming. Welcome. It's my pleasure and [00:38.520 --> 00:47.200] honor to open this Devroom today. And it's also a great pleasure that we can continue this tradition [00:47.200 --> 00:53.840] of this Devroom since 2012. I would like to thank Razvan for organizing the Devroom this year, and [00:53.840 --> 01:02.960] let's go to it. So, my talk will be about the currently developed microchannels that I'm aware [01:02.960 --> 01:10.120] of. Maybe I'm missing some, but this should be like an overview. If you might be interested in [01:10.120 --> 01:17.760] seriously using a microchannel or just trying it out, what you can expect. This first slide is about [01:17.760 --> 01:25.640] me. I won't go into it. Let me just say that I have been working with microchannels and contributing [01:25.640 --> 01:35.240] to microchannels for almost 20 years now, half of my lifetime. I assume that most people here do [01:35.240 --> 01:42.720] know what a microchannel is, or at least most people have some kind of idea. But I will still [01:42.720 --> 01:51.240] try to very briefly introduce the microchannels to you. Maybe I will save a few minutes for the [01:51.240 --> 01:59.080] follow-up speakers. So, a microchannel-based operating system is a fundamental way how to achieve [01:59.080 --> 02:07.200] operating system reliability and dependability by the means of having purpose of the architecture, [02:07.200 --> 02:14.520] especially driven by specific design principles. Now, every microchannel has their own design [02:14.520 --> 02:20.400] principles. This is where the different implementations differ, obviously, but I think there are [02:20.400 --> 02:27.960] like three common universal design principles, the separation of concerns, the split of mechanism [02:27.960 --> 02:36.480] and policy, and the principle of least privilege. So, this generally results in a system that is [02:36.480 --> 02:45.840] modular, customizable, and verifiable, potentially formally verifiable. By the way, some microchannels [02:45.840 --> 02:53.280] do have a minimality as explicit design principle, but many microchannels actually don't. So, [02:53.280 --> 02:58.680] the micro part in the microchannel and the whole microchannel term is a little bit of a [02:58.680 --> 03:04.920] misnomer, at least as I see it, because I think the microchannel as small as possible is not [03:04.920 --> 03:10.240] necessary. The a priori goal is just the result of the other design principles, and I really [03:10.240 --> 03:15.720] think that there is no point in comparing whether one microchannel might have 20,000 lines of [03:15.720 --> 03:23.200] code and they are 130,000. It's really comparing apples to oranges. These design principles also [03:23.200 --> 03:29.000] don't affect just the kernel design, but potentially also the user space design. So, [03:29.000 --> 03:35.840] therefore, you might see descriptions like microchannel multiserver operating system with [03:35.840 --> 03:42.400] fine-grained components. This means that not only the kernel is non-monolithic, maybe that [03:42.400 --> 03:49.840] would be a better term, but we are stuck with the microchannel term, but also this might suggest [03:49.840 --> 03:57.520] that in many of these systems also there are no monoliths in the user space. I have some [03:57.520 --> 04:01.720] slides about the history, but I will skip them. You can go to the slides if you are interested. [04:01.720 --> 04:11.080] Just one note. The idea of micro kernels has been around almost as long as the idea of operating [04:11.080 --> 04:20.480] systems. So, if some people say that micro kernels are strange, are this strange over-engineered [04:20.480 --> 04:27.280] idea that proper operating systems should be monolithic because this was the way how [04:27.280 --> 04:35.040] they started and etc., I don't think those are very valid arguments. So, let's go to [04:35.040 --> 04:42.160] the core of my talk. There is a website, microkernel.info, which is basically a condensed [04:42.160 --> 04:51.280] version of this. So, this is a very simple site that lists the current state-of-the-art [04:51.280 --> 04:58.760] open source micro kernels. So, if you are interested or if you are looking around going [04:58.760 --> 05:04.280] to this site, it's probably a good idea. By the way, this site was started by Jakub Mirmas, [05:04.280 --> 05:09.920] my colleague, and I'm maintaining it right now. Of course, if you are a microkernel developer [05:09.920 --> 05:17.440] and you don't see your project on this site, just send us a pull request. It's so simple. [05:17.440 --> 05:25.960] Okay, let's start with the overview. I should say that there is surprisingly, there are [05:25.960 --> 05:35.240] surprisingly many projects, active projects that are microkernel-based, and for microkernel [05:35.240 --> 05:43.800] developer this is really exciting times, I would say. So, genode by genolabs is perhaps [05:43.800 --> 05:52.040] the most versatile example of a microkernel-based operating system, but I mind you. It's actually [05:52.040 --> 05:58.000] not an operating system in the common sense, like what you would consider Windows or a [05:58.000 --> 06:04.400] GNU Linux distribution. It's actually an operating system construction kit. So, it's a way how [06:04.400 --> 06:12.000] to pick and match different operating system components, including different micro kernels [06:12.000 --> 06:22.480] or kernels in general, with some user space components and how to build a bespoke operating [06:22.480 --> 06:27.920] system for your specific needs. So, what is really interesting about genode that you can [06:27.920 --> 06:34.880] really use all these different microkernels like SCL4, Fiasco OC, microhypervisors like [06:34.880 --> 06:42.440] NOVA, and you can even use their own custom microkernel, which is called base HW. You [06:42.440 --> 06:50.520] can even run this infrastructure on top of Linux for development purposes, maybe. There [06:50.520 --> 06:59.240] is strong focus on resource accounting and management in genode. You can read the genode [06:59.240 --> 07:07.680] book for the details. Genode is driven by a commercial company. So, they have customers. [07:07.680 --> 07:13.160] Somebody is paying them to do that. They don't state their references publicly, as far as [07:13.160 --> 07:18.960] I know. I might note some, but I'm not in the liberty to name them. And there is also [07:18.960 --> 07:26.240] this thing called SCALP OS, which is like a pre-built distribution of genode. So, if [07:26.240 --> 07:33.080] you would like to try something that is, that you don't have to pre-configure in advance [07:33.080 --> 07:43.200] for your specific needs, you can go for that. This is a picture from Norman Feske, one of [07:43.200 --> 07:51.120] the co-authors of genode from, I think, FOSDOM 2017. So, maybe the image is a little bit [07:51.120 --> 07:57.160] outdated, but I still think it gives you the big picture. So, you have all these components [07:57.160 --> 08:04.040] like the different kernels, different user space, runtime environments, if I can say, [08:04.040 --> 08:11.960] so this one is, for example, Unix-like runtime environment, drivers and UI components and [08:11.960 --> 08:19.760] stuff like that, and you mix and match them. And then, this is a screenshot of the SCALP [08:19.760 --> 08:30.760] OS, so, like, this one instantiation of genode, and you see that it's actually a nice desktop-oriented [08:30.760 --> 08:42.720] operating system. As some final closing remarks to genode, I really like base HW, as I spoke, [08:42.720 --> 08:49.600] microkernel for genode, because it's really nicely integrated with the rest of the system. [08:49.600 --> 08:55.480] For some reason that I don't know, I don't understand, but there are genode guys here, [08:55.480 --> 09:02.600] you can ask them. I don't see complete feature parity of base HW with the other microkernels [09:02.600 --> 09:09.240] they support, so, as far as I know, there is no support for hardware virtualization. [09:09.240 --> 09:17.240] And this is not a criticism, this is just a comment. If you start playing with genode, [09:17.240 --> 09:23.560] you need to read some documentation. There is very nice documentation available, no [09:23.560 --> 09:28.240] doubt about it, but, really, it's not so simple by just downloading an image and running it [09:28.240 --> 09:37.080] and expecting a fully blown desktop environment, at least not from, you know, just by booting [09:37.080 --> 09:43.160] it, you have to do something. But I think it's definitely worth it, so there are some [09:43.160 --> 09:47.760] links you can follow. It's an open source project, by the way. [09:47.760 --> 09:56.760] Okay, now, let me talk about L4E, which is something slightly similar in some aspects [09:56.760 --> 10:03.840] different by my current employer, current concept. So, this is also a production grade [10:03.840 --> 10:09.000] microkernel-based environment, a little bit more integrated, I would say, because we basically [10:09.000 --> 10:17.240] support just the one kernel, which we called L4E microkernel, but you all know it by the [10:17.240 --> 10:25.120] name Fiasco. We use this name currently because Fiasco is a very poor name, trust me. So, [10:25.120 --> 10:32.040] we strongly focus on virtualization, we strongly focus on safety and security certification [10:32.040 --> 10:39.800] currently, and we also have customers, because we are a company that pays us and et cetera. [10:39.800 --> 10:46.600] I'm, again, not in the liberty to name them, but I can say that if you're going to buy [10:46.600 --> 10:53.000] a new car from a German car manufacturer, there is a high chance you will be running [10:53.000 --> 11:02.880] L4E. There will be L4E code running in the software stack of that car. [11:02.880 --> 11:10.600] To be honest, the code base is not the most verbosely commented that I have seen, especially [11:10.600 --> 11:18.320] the kernel itself. So, again, the learning curve is a little bit steep, but at least [11:18.320 --> 11:24.800] there are some scenarios you can just build or download and pre-build image, and this [11:24.800 --> 11:31.360] will show you the potential to a certain degree. And here are some links. Again, it's an open [11:31.360 --> 11:41.240] source project. Now, let's talk about Helen OS, which is to compare with the previous [11:41.240 --> 11:45.920] two is a slightly different breed. So, this is like an integrated operating system. So, [11:45.920 --> 11:52.800] the purpose is to build it or download an image, boot it, and be presented with a desktop [11:52.800 --> 11:59.800] environment with a shell and some mostly familiar commands, which you can use to explore the [11:59.800 --> 12:05.720] system. So, it's not about compile time or deployment time configuration. It's really [12:05.720 --> 12:13.400] about configuring the system at runtime as you go. What do you expect from a desktop-oriented [12:13.400 --> 12:19.560] OS? And, of course, I'm a little bit biased because this is my project, but I would argue [12:19.560 --> 12:31.000] that if you want to understand how a microkernel-based system works inside, this is the one to pick [12:31.000 --> 12:39.840] because of the OS entry barrier. The code base is portable, self-contained, well-structured, [12:39.840 --> 12:46.720] so, for example, we know how to use directories and not only a single level of them. So, this [12:46.720 --> 12:52.600] is how we structure the system to be more understandable. The code is well-commented [12:52.600 --> 12:57.920] and this is not just my observation. If you run a tool that will analyze the sources, [12:57.920 --> 13:06.720] you will get a number around 30-35% of commands, which is not bad. And believe me, I have seen [13:06.720 --> 13:13.280] many microkernel code bases. I have seen the code of many operating systems in general [13:13.280 --> 13:21.160] and I can tell the difference. So, I would compare LNOS to something like the Solaris [13:21.160 --> 13:29.120] kernel in terms of the structure and commands and stuff like that. And we also prefer to [13:29.120 --> 13:35.720] use our native components, so, no ported components or components that might use some [13:35.720 --> 13:47.360] unique kernel layers to really make the system feel coherent. Let's put it that way. So, [13:47.360 --> 13:53.560] this is how it looks like when you boot the image which you can compile or download. So, [13:53.560 --> 14:00.600] you have a user interface, a shell, et cetera. And we have some interesting features that [14:00.600 --> 14:06.280] are not presented in the other microkernels. So, we are portable not only in theory but [14:06.280 --> 14:16.000] also in real life. So, we support eight different architectures, including strange bits like [14:16.000 --> 14:25.200] itanium. And yes, the RISC-5 port is still not finished and that goes to me. We are using [14:25.200 --> 14:32.920] asynchronous IPC which transparently uses shared memory for performance. We have interrupt [14:32.920 --> 14:39.160] controller drivers in user space compared to some other microkernels. We have a fully [14:39.160 --> 14:47.080] decomponentized TCP IP stack. We support USB 3.0 and we have a sound stack, so, just [14:47.080 --> 14:55.200] a few highlights. I will go quickly through these slides. We don't have the time to go [14:55.200 --> 15:02.080] to the details but the microkernel, while being quite small, still has a structure. So, [15:02.080 --> 15:09.040] we have a well-defined hardware abstraction layer in the kernel. This is how the user [15:09.040 --> 15:14.800] space or how the entire architecture of the system looks like. So, you might see some [15:14.800 --> 15:20.760] similarities with the genode image but the difference is that all of this is potentially [15:20.760 --> 15:26.320] running in the system for all the time, I mean, depending on the actual configuration [15:26.320 --> 15:32.120] of your machine. And there are some device drivers which are, again, somehow structured [15:32.120 --> 15:38.600] in a tree, starting with some platform drivers, et cetera. If you want the details, please [15:38.600 --> 15:48.120] come to me. Yeah, it's a community-driven effort currently. So, yeah, we are not so [15:48.120 --> 15:54.560] fast regarding the development but we still do semi-regular releases and, sadly, we don't [15:54.560 --> 15:59.880] support some of the new hardware features. If you'd like to contribute, you are more [15:59.880 --> 16:10.440] than welcome. Fuchsia by Google is a relatively new kit on the block. It's a microkernel-based [16:10.440 --> 16:19.720] system that is strongly focusing on Internet of Things. Specifically, their target is to [16:19.720 --> 16:26.720] support maintenance, remote management, and remote upgrading of a fleet of devices. So, [16:26.720 --> 16:34.080] imagine, for example, the Google Nest Hub, which is the device where Fuchsia is being [16:34.080 --> 16:43.200] shipped currently with, and they even managed to do a remote update of all those, you know, [16:43.200 --> 16:51.000] Nest Hubs from the previous Linux-based OS to Fuchsia over the air without the users [16:51.000 --> 16:59.360] even noticing. So, I think this is quite impressive. The microkernel is called Zircon and it's [16:59.360 --> 17:04.400] capability-based message-passing microkernel. And I have spoken to the developers why they [17:04.400 --> 17:11.240] don't actually stress that it's microkernel. And it's their deliberate choice to somehow [17:11.240 --> 17:18.240] underplay, understate that it's a microkernel because of some bad press of the term. So, [17:18.240 --> 17:24.000] they don't call it microkernel explicitly unless you ask them, but it is a microkernel, [17:24.000 --> 17:33.520] for sure. Yeah, this is how it looks like on the Nest Hub, or this is the way how you [17:33.520 --> 17:41.520] can tell whether your device is still running Linux or is running Fuchsia. And, yeah, the [17:41.520 --> 17:47.680] learning curve, again, somewhat steep because this is not a desktop-oriented system or server-oriented [17:47.680 --> 17:55.680] system that would be Unix-like. You have to install a non-trivial toolchain and a custom [17:55.680 --> 18:02.080] emulator sort of like when you do Android development and other things. But, again, [18:02.080 --> 18:08.560] what would I believe is very nice about Fuchsia that they are only using their own native [18:08.560 --> 18:15.760] core components, not ported components. And it's an open-source project. [18:15.760 --> 18:23.360] Panagarm, again, a relatively younger operating system, which is microkernel-based, at least [18:23.360 --> 18:32.320] compared to the first three. One of the key features, a fully asynchronous kernel design, [18:32.320 --> 18:40.280] which tries to somehow mitigate some performance problems by implementing some features in the [18:40.280 --> 18:48.400] kernel, which might not be considered pure by microkernel purists like the PageCache. [18:48.400 --> 18:56.920] And Managarm tries to be compatible with Linux, so they already support the Wayline [18:56.920 --> 19:05.320] protocol in Western and some other applications. They even have some accelerated GPU drivers, [19:05.320 --> 19:11.760] so at least one. And it's an open-source project, and this is how it looks like. Of course, [19:11.760 --> 19:18.160] you can run more than just a clock there, but, yeah, you get the idea. [19:18.160 --> 19:25.560] Redux, another interesting microkernel-based operating system that tries to be Unix-like, [19:25.560 --> 19:34.280] but this one has this primary feature of being implemented almost completely in Rust. Also, [19:34.280 --> 19:40.680] the core user-based components are written in Rust, like the Lib-C, so they have actually [19:40.680 --> 19:50.400] a C library written in Rust. Interesting. What to say, again, POSIX compatibility layer, [19:50.400 --> 20:00.280] they already support some interesting end-user applications and libraries, and it's an open-source [20:00.280 --> 20:06.560] project, again. And this is how it looks like when you boot it. So, again, you can run a [20:06.560 --> 20:16.120] terminal with a bash in this case and just explore the system. [20:16.120 --> 20:21.760] A little bit aside, there are also other, let's say, currently non-open-source microkernels [20:21.760 --> 20:28.240] being around. I just tried to mention them here very quickly. I know we are at FOS them, [20:28.240 --> 20:37.160] but just to complete the picture. So, Huawei is working on something which they call Humong. [20:37.160 --> 20:45.720] It's actually quite buried under this HarmonyOS brand, and it's a little bit confusing because [20:45.720 --> 20:52.160] you might have heard rumors, the original ones were that HarmonyOS will be a microkernel-based [20:52.160 --> 20:58.960] system, then Huawei released something that was clearly Linux-based. So, yeah, this did [20:58.960 --> 21:05.840] not resonate well with our technical folks, but the point is that this is just a marketing [21:05.840 --> 21:12.400] confusion. So, the HarmonyOS is a common brand for different operating systems. One of them [21:12.400 --> 21:18.360] is Linux-based, one of them is LiteOS-based, which is a real-time kernel by Huawei, and [21:18.360 --> 21:29.600] the most progressive one unreleased so far is the microkernel-based. The microkernel [21:29.600 --> 21:36.760] was originally inspired by best practices and state-of-the-art in other microkernels, [21:36.760 --> 21:45.680] but it's a clean slate implementation and design. For example, they have capability-based [21:45.680 --> 21:50.760] physical memory management in user space, so the kernel does not manage the physical [21:50.760 --> 21:58.280] memory. It's sort of similar, the design is sort of similar to SCL4, but it's slightly [21:58.280 --> 22:05.160] more practical in my personal opinion. Sorry that I can't go into the details, and they [22:05.160 --> 22:12.160] also target safety and security certification, and actually this is also running in the wild [22:12.160 --> 22:20.080] as trusted execution environment in several Huawei smartphones. Then there is this R&D [22:20.080 --> 22:28.880] project called DAQ, which is primarily being driven by my former colleagues at the Dresden [22:28.880 --> 22:37.920] Research Center, which tries to be, again, a completely clean slate design and implementation. [22:37.920 --> 22:44.080] The primary goal was really to use state-of-the-art best practices and software engineering to [22:44.080 --> 22:49.160] achieve really the highest code quality and maintainability. For example, one of the goals [22:49.160 --> 22:56.800] was to be fully MISRACI compliant. Another goals were high-level safety and security [22:56.800 --> 23:05.640] certification and other interesting features. It's an R&D project, and honestly, I don't [23:05.640 --> 23:10.840] know what's the current state, maybe you can informally ask some of the Huawei guys here, [23:10.840 --> 23:18.480] but it's good to know that this is there. Okay, very quickly, some other systems. [23:18.480 --> 23:27.640] GNU Horde, for 30 years, the intended replacement of Linux in the GNU Linux equation, still [23:27.640 --> 23:33.920] alive, still kicking, still with semi-regular releases, and yeah, I mean, you can actually [23:33.920 --> 23:40.080] run 70% of the BN packages on top of it, which is not bad, I mean, honestly. Yes, it's limited [23:40.080 --> 23:53.000] to 32-bit x86, but as I always say, if they would get 1, 3, 1, 1, 4 of the Linux contributors, [23:53.000 --> 24:01.840] they would finish it in a few months. ARS, which is a microkernel-based operating system [24:01.840 --> 24:10.720] based on the Helios microkernel, which is supposedly inspired by SCL4. There will be [24:10.720 --> 24:21.040] a talk later today from the author, so I skip the details for now. Composite, another microkernel-based [24:21.040 --> 24:28.360] project that is focusing on predictability and component composition. The kernel itself [24:28.360 --> 24:39.080] is designed as lockless, and it has user space scheduling, and it uses thread migration IPC, [24:39.080 --> 24:48.000] so if you remember vaguely the idea from Mach 3.0 from Ford at all, this is the continuation [24:48.000 --> 24:58.080] of that. Then there is UXRT, which is like a user space part built on top of SCL4. This [24:58.080 --> 25:07.320] is still an ongoing project in early stages of the development. Let's see how it goes. [25:07.320 --> 25:13.360] And finally, let's mention a few standard microkernels, so these are not entire operating [25:13.360 --> 25:22.080] systems, these are just the kernel building blocks. NOVA, microhypervisor by Udo, is again [25:22.080 --> 25:29.120] alive and kicking. It has been used by bedrock systems as their primary product, as I believe. [25:29.120 --> 25:34.520] So this is one of the projects that sort of went into limbo for many years, and now they [25:34.520 --> 25:42.160] are alive again. By the way, G-Note, I believe, is maintaining their fork of NOVA, or maybe [25:42.160 --> 25:50.360] NOVA with their own patches, but there is also Hadron, which is an official fork of NOVA [25:50.360 --> 25:57.840] from Cybers, and they are also using it as their commercial product. Again, I think there [25:57.840 --> 26:06.320] might be Julian somewhere here who might tell you more. SCL4, of course, the microkernel [26:06.320 --> 26:12.680] with the most, I would say, the most visible formal verification story, we need to mention [26:12.680 --> 26:27.640] it. We also need to say that Google has adopted SCL4 recently as their foundation for secure [26:27.640 --> 26:35.920] firmware, sort of something like that. I'm not really sure what are the targets of this [26:35.920 --> 26:44.360] can trip OS, also SCATA OS, but it's a static configuration mostly, so it's not a dynamic [26:44.360 --> 26:50.800] system, it's a really static configuration system. And in that same area, I would mention [26:50.800 --> 26:57.720] also the Muen separation kernel, which again is a separation kernel, so its primary goal [26:57.720 --> 27:07.480] is to do static partitioning, but I think it belongs to the family. And sadly, there [27:07.480 --> 27:13.480] are some microkernels that are interesting, worth looking into for inspiration, but are [27:13.480 --> 27:21.360] currently in limbo, like Escape, M3, Minix 3, Herbigalia, and Redleaf. I hope they will [27:21.360 --> 27:28.120] be resurrected. And of course, I might continue with a list of other microkernels that are [27:28.120 --> 27:34.240] certifiably dead, and of course, those could be resurrected as well, and it's always good [27:34.240 --> 27:41.480] to know the history, right? Yeah, but I would stop here. Thank you, and if there are any [27:41.480 --> 27:46.040] questions, I would be happy to answer them. Right, thank you so much, Marty. If there are, [27:46.040 --> 27:57.400] please. Thank you. We have time. Yeah, two questions, three questions. Hello, congratulations [27:57.400 --> 28:05.240] for your excellent talk. Thank you. Among all those that you studied, which one do you [28:05.240 --> 28:12.520] think would be more compatible to the Linux end user base, like for a person to use Minix [28:12.520 --> 28:21.400] or... I mean, that is a good question. Thank you. So the question is, which of those systems [28:21.400 --> 28:27.760] would be most Linux compatible? Most of them, actually, most of the systems that I've presented [28:27.760 --> 28:35.400] do have some POSIX compatibility layers. So I would not make this as the only criterion. [28:35.400 --> 28:40.840] I understand it might be important for you, but I would look also into other aspects of [28:40.840 --> 28:48.840] that, because most of the systems do provide some kind of Linux compatibility. But if you [28:48.840 --> 28:55.080] would be looking for something that is really Linux compatible by design, or that makes [28:55.080 --> 29:01.080] it as one of its primary goals, then I would probably go for Managarm. But again, this [29:01.080 --> 29:10.720] is just a first idea, first suggestion. I would not rule out the others. [29:10.720 --> 29:21.320] Thank you. Any questions? Alex. Hi. Thank you for the talk. So what trends do you think [29:21.320 --> 29:26.480] you'll see in the next few years with the microcodes? That's a tricky question, but thanks [29:26.480 --> 29:36.400] for that. So the question was about the trends. So I think there will be this kind of retargeting [29:36.400 --> 29:44.520] of the systems to very specific use cases like Fuchsia is doing, so really implementing [29:44.520 --> 29:53.040] custom operating, microcode-based operating systems that really do fulfill the specific [29:53.040 --> 29:58.760] needs of those areas. That's one thing. The other thing that I would like to see, I'm [29:58.760 --> 30:04.000] not sure if it's going to happen soon, but I would like to see, I would like to see more [30:04.000 --> 30:11.280] hardware software code design. So basically, the Achilles heel of microcodes is the fact [30:11.280 --> 30:18.600] that most current CPUs don't really provide hardware features that would help the microcodes, [30:18.600 --> 30:24.080] especially in the terms of performance. And we see this vicious cycle. The microcodes [30:24.080 --> 30:30.000] are not performing greatly on the current hardware, so nobody is, nobody quote unquote [30:30.000 --> 30:39.520] is using them. So the hardware vendors don't see a need for changing the CPUs to provide [30:39.520 --> 30:45.360] features that would help the microcodes. But I think with RISC-5 and the possibility, or [30:45.360 --> 30:50.680] the democratization of the hardware design, I think this might change hopefully quite [30:50.680 --> 30:57.880] soon. And the third trend that I definitely see, which was probably also seen on the slides, [30:57.880 --> 31:03.960] is really the certifications in terms of safety, security, and hopefully more formal verification, [31:03.960 --> 31:10.560] because this is where microcodes really excel. So why not go for it? [31:10.560 --> 31:30.520] Okay. Thank you so much, Martin. Thank you.