 Thank you everyone for being here. And I hope you had a great conference. I hope that this will cap your day nicely. So my name is Frédéric Devien, I'm Fred. I'm the program manager for IoT and Edge Computing at the Eclipse Foundation. Now let's do a show of hands. Who among you knew that Eclipse is much more than the Eclipse IDE? Raise your hand. Yeah, that's what I thought just a few ones. So now your mission, those who didn't raise your hand, your mission is to tell your friends that the Eclipse is much more than the Eclipse IDE. You are free to wait it, you know, the IDE, no problem. There are 400 plus of your projects at the Foundation for you, and a bunch of them are in the IoT and Edge space. And it's my job to make them known to the world. So I hope next time I show up, next year, you know, plenty of hands will raise up. I hope. All right, so now this is my grand moment to our toss or not our toss. That is the question. Of course, this is a dumb Shakespeare reference. And I wasn't able to find the free, royalty-free image, you know, with a guy with the actual skull, you know, doing Hamlet and that kind of stuff. So here you have a nice skeleton, you know. And in a way, this skeleton symbolizes what this talk is about. This is about you getting the tools to think about what you're trying to do and pick the right solution. So I'm not there to tell you there's the best way to do anything. I'm there to give you knowledge. And then, you know, you're the thinking skeleton and you make the right choice for your project, all right? So let's get started. So there are three steps in our little process today. So we'll think a bit about, you know, what OSs bring to the plate and why we would need them or not. And after that, I will present three specific open source real-time OSs and then have a look at a few alternatives for bare-metal approaches, so to speak, so without an OS. And, well, ultimately after that, you go in the market and build great solutions using whatever makes sense for you. Okay, so do we need RT OSs? Well, it depends, you know, I was, as I was preparing this presentation, I was trying to find a good metaphor, you know, for the ultimate answer to that question. And my ultimate answer is this. So this is, okay, well, I'm dating a bit myself. If you don't know what that is, that's fine. That's an early 80s computer. The first one I use in my life, 64K of memory, you know, two megahertz processor or something like that, you know? So, you know, in a way, that was a pretty reliable machine. I never patched it, I couldn't, right? You know, everything is in ROM, you go straight to the basic interpreter, you write a program. So if your use case is literally that, you know, I think a bunch of sensors just sending that to the cloud or to an edge node or something like that, maybe you know, you don't need, you know, the full blown might of an operating system or anything like that. Or maybe you need, depending on what you're trying to do on your constraint device, what you're trying to do at the edge and that kind of stuff, okay? But ultimately, you know, there are many types of situations where you don't necessarily need it. Now, this was the ultimate option. I mean, if you ever need an evil Commodore 64 backer or something like that, be careful, you know? I'm a good guy because I use that kind of machine. All right, not true. All right, the power of nostalgia. So, before we answer the question of whether we need an OS, we need to take a step back and figure out what an OS provides to us. Essentially, there's a bunch of, well, potentially very useful things. The first one, of course, is APIs. Stable APIs like the ones provided by the Linux kernel. Sometimes they are more generic than that, like POSIX or whatever. Anyway, APIs are very useful, but depending on what you're trying to achieve, they are not necessarily necessary. Okay, then there is the full dimension of hardware support, drivers, essentially. And a good or bad driver may make or break your day, right? So, this is really an important dimension. Depending on the hardware that you want to leverage, you may need to use drivers that are appropriate for that. And if they are not, you may need to write one yourself. I don't recommend that necessarily, unless you are a much better developer than I am. Well, given the potential crowd is, given the potential crowd here, I'm quite sure there are quite a few people that are better developers than me, in any case. Hardware support is a very, very important dimension there. Then there's the whole universe of memory management. If you have a very tiny application running, the only one on a very tiny microcontroller, well, you don't multitask, you don't need so much memory management, so your needs were very basic. But as you are trying to implement more complex stuff, then of course you will need robust memory management and you can't necessarily count on whatever the hardware will provide you. You will need an OS to support you in that as well. The same for multitasking. And then there are the full blown real-time requirements that we typically find in real-time operating systems. And this is not easy. I mean, if you are trying to automate a nuclear reactor or an industrial process, or even the ABS brakes in your car, okay, you have very precise requirements for latency. You don't want things to be laid because of or an interrupt switch or something like that, or swapping the context. No, you don't have time for that. You are literally in a situation of life and death in most cases. Real-time is often associated with mission-critical requirements, right? So if you have real-time requirements, then yes, of course you can write everything from the ground up, don't do that. I mean, even people that are very knowledgeable about real-time are having trouble implementing it in real systems. And this is why they are barely starting merging the real-time patches in the mainline kernel for Linux at this point, right? And it will be a multi-year process or multi-month at least. I'm not following that very closely, but in any case, it's not obvious. And then there's the whole dimension of shared services, so printing services, music playing services, whatever, of course, depending on the level of granularity of your use case or application. And all of that, well, OSes are things that provide one or many of those things depending what the functional scope is. So, and of course there's the whole dimension of time-sharing versus real-time operating systems, right? Where time-sharing like Windows and Linux and all of that desktop or server class are there to maximize hardware utilization and virtualization on the top of that with Kubernetes or virtual machines, whatever. Real-time OSes are pretty much focused on a guaranteed latency. We don't care how, we don't care. But we are there to ensure that when we do a system call, it will return in a very previsible amount of time. And this is, once again, very important in situations where you literally have situations of life and death. Now using an RTOS on its own is not necessarily enough because if your own code is idling or not as fast as it should, even if you are using an RTOS, if you take too much time to process the daytime, make a decision, maybe your breaking will be two seconds late and then everyone's dead, right? So using an RTOS is a good step, but it's certainly not enough to guarantee that you won't kill anyone. So please be aware of that if you build those types of applications. So how would you decide between using an OS or real-time OS versus the bare metal approach for IoT and edge types of applications? And really this comes down to the three things I put on the screen. There are, you know, I'm a bit simplistic there. We could go in greater detail and have several slides of that. But essentially I felt that the three things I put on the slide were good enough. You know, as rules of thumb. First, the kind of hardware that you have. Some hardware is, you know, very low-powered, 8-bit, 16-bit microcontroller. Then of course, you can save space. You can be more efficient maybe by bar foregoing the real-time OS. But then if you do that, you use a bare metal approach, you don't necessarily have the real-time guarantees that a real-time OS would give you. So you need to weigh down, you know, what you're trying to achieve. So for ABS brakes, that would be a bad call, you know, because you want real-time guarantees. If you're doing just, oh, this is a weather station in my backyard, you know, sampling things every five minutes, I can't skip a reading. We won't kill anyone. Then of course, it's much easier to make the call that I don't need a real-time OS. Then of course, what are your functional and non-functional requirements for the software you're writing on the top of the platform, whether it's a bare metal platform or a real-time OS? And that's really important, you know, that's what I was alluded into when I said that, you know, if you code your algorithm wrong and you break two seconds too late, okay? This is really key. You have to think in advance to what you're trying to build and not just blindly pick a platform, it's the best. Then deliver something that won't deliver for your customer. And ultimately, you need to take into account the read. You know, this is related to hardware, but specifically the types of peripherals and buses you're trying to leverage, because once again, if you leverage buses and things like that and your bare metal environment doesn't support that, then you need to write some code and some code which is equivalent to a driver, but that driver would have been for free, so to speak, in a real-time OS, for example. So you're reinventing the wheel. You don't want to do that. So it's really important to figure out what you're trying to achieve exactly and where you are at it. So, three options for real-time OSes presented in alphabetical order, okay? So I don't have necessarily a favorite in there, just showing you three open source approaches and the variety that there's in there because they really don't have necessarily the same philosophy and the same orientation. So the first option is embedded OS by ARM. So this is open source. You can find that on GitHub. And essentially, the way they describe it is that they have layers of partner supply components. Typically, this will be code you will get from the specific board maker that you are dealing with or that kind of stuff, or maybe the maker of the system of a chip if you're on that kind of scenario. So that's the layer that you see there, you know. And that can be open source or maybe not. That's already one strike against it in the sense that the OS itself is open source but not every component that you may deal with will be. And to me, of course, something that's closed is well, not necessarily optimal, especially when we think about the type of things we're trying to build. Another interesting thing here is what they call CMSIS core and that kind of stuff and the driver model. So there's an abstraction layer in there. So the great thing about this is that, let's say you are using a very specific type of core or system of a chip, and then you will use a variation of it with slightly different built-in peripherals, let's say. You won't necessarily have to rewrite your application from the ground up because the hardware abstraction layer in embed will take care of things. Mostly for you. Okay, mostly. Then you see there is RTAS there. So you can use embed as a plain operating system, but there are all the real-time operating system primitives if you want to deploy them and then the equivalent to CMSIS in there. And then the full-blown functional scope of it. So you have drivers for take into account storage. You even have their own little file system that you can leverage, which is optimized for use on flash storage, removal of things and things like that. So that's good. And then you have built-in support for MQTT and Co-App, which are popular protocols in the IoT space. You have a full-blown TCP IP stack. You have full-blown support for TLS and even more advanced cryptography, et cetera, et cetera. So you see, the functional scope is quite large. The good thing about it is that it's modular, so you only pick the pieces that you need and then, okay, you can slim down a bit your firmware that you will deploy on the actual device because of that. But then, of course, it's certainly a larger footprint than some other alternatives. So ultimately, do you want to embed or not embed? Well, the pros are, of course, it's extensive, an extensive feature set that's good, right? You don't need to rewrite things. It's modular, there's an abstraction layer, and of course, it's got fantastic support for hardware because that's all it does, okay? The metacryptography in it is good. And in my diagram on the previous slide, I even removed part of this diagram in the ARM documentation. There's a section describing what they do for trusted computing, that kind of stuff. So to keep things simple, I cut off that, but certainly it's a mature and fully-featured option. Of course, there are cons there, the first one being single-vendor governance. You know, single-vendor governance, people, you know, not all open source is the same. And that's literally the difference between Golang, where Google can say no to the community and not implement the features people want in the language versus Kubernetes, where it's community-driven and there, you know, there is an actual community dynamic there, okay? So it's the same with Enbed. It's a single-vendor project. So yes, you may push PRs and things like that and pray that they maybe integrate your patch or something, but there's no guarantee, okay? And then it's ARM only. So no risk five, no more exotic architectures. You're stuck with ARM. Okay, it's a good option now. Five years, 10 years from now, what will the universe will be? I don't know. So you have to think strategically there and keep your options open maybe or not. Maybe you're fine with, you know, going all in with ARM. And then the ecosystem for it is a bit smaller than other alternatives, okay? It's well enough supported. You will find articles, you will find tutorials and things like that. But yeah, that's not necessarily the largest community around. But it's a good option for sure. You know, I wouldn't talk about bad options here, not to you. All right. Fuertas now. So Fuertas is, well, the 800 pound and plus gorilla in the room, the sense that that's probably the most widely-adopted option for RTOSs, at least in the open source space, right? So it's everywhere. And the architecture is, as you can see, a bit simpler, right? So you've got a bunch of drivers that are typically provided by hardware vendors. You have the core kernel libraries and then little things that implement Wi-Fi or Bluetooth support or TCP. So overall, yeah, the base feature set is maybe less comprehensive than what we saw with Embed. But you know, the core stuff is there. One thing to highlight is that you've got libraries to implement some advanced forms of security, device defender, you've got device shadow with a kind of digital twin for your device over the air updates. So those things are open source, at least for the client library, but where are they connecting on the other end on AWS? So that may be a problem or may not be a problem for you, but certainly you have to keep into account that especially since the project became owned in one way by Amazon, they have making decisions like that that are nudging you towards use of their ecosystem. Okay, you scan still, of course, use the kernel and everything else and do whatever you want with them. And of course, you could write your own server platform that would handle the client libraries. But still, for me as an open source advocate, I'm demutative, let's say, to stay polite in front of that particular strategy, but it's up to you anyway. So for us, as I said, certainly got lots of adoption and overall, you will find probably everything that you need for wide variety of hardware from a wide variety of vendors. The only thing, if you look at the repos, most of the stuff is in a single repo, but they don't all have the same maintenance guarantees. Some of the stuff is maintained by the core team, that's good. Some of them are maintained by the vendors themselves and not necessarily aligned with what the core team does. Okay, and then some things that you may find from other vendors or over the public internet don't necessarily follow the latest release cycles from the core team. So it's a bit of a mix and match thing and you have to assume the risk that comes with that. In the sense that at some point, maybe your driver will be mysteriously broke and then you are for a three-day debugging session. I don't particularly recommend that or I hope if you're going that route, that will not happen to you. But if you stick, I guess, to mainstream hardware and that kind of stuff, you won't have necessarily any problems. Anyway, so pros and cons of free RTOS. So of course, one of the main draws for free RTOS is that it's very, very small. It can fit on nearly anything really and it's very mature. It's been around for quite a while now. Broad hardware support and a vast ecosystem. You will find many people with tutorials to help you out and that kind of stuff. And there's plenty of information on the main project website as well. It's a bit on the messy side, but you can ultimately find whatever you need. However, well, single vendor governance once again. I mean, Amazon is making the calls at least for whatever is accepted as maintained by the core team, okay, which is fine, I guess. But once again, this is not a community approach, okay? And there's the support burden, the fact that you will mix and match things in order to have a complete platform to support your application. There's a level of risk involved there. And certainly the growing ties to the AWS cloud in my perspective are not necessarily good. I mean, we all heard recently about an IoT platform by a mega vendor that has been discontinued, will be next year. So you never know when those things happen to you. So anyway, and then, well, some of the features in there like the dynamic memory allocation, okay, you will find five distinct ways of doing that in triartos, but they are all shipped as samples. So no guarantee that ultimately they will deliver on your mission critical case. So be careful with that. Once again, maybe you're a better developer than me, but if I am to embark on a multimod project to deliver a mission critical device, I want to focus on the actual app and not necessarily on the subtleties of memory management. Anyway, finally, there's the fear, the fear being a project of the Linux Foundation there. And once again, you can see a fairly extensive tool set there starting with the power management, the kernel services, support for wide variety of buses, I2C, SPI, UR, GPIO, et cetera. You've got FI system, databases, cryptography, et cetera. And of course, in terms of higher level stuff, you've got a device management API, you've got support for a wide variety of wireless protocols, and then built-in support for lightweight M2M, MQTT, HTTP, co-app, and finally your applications on the top. So in terms of being fully featured, well, this is quite, quite good. And you will see that there are good examples in the documentation for most of those features. So if you're looking at getting started, I think the way they've done it is really well-structured and predictable. So that's certainly a plus. Zephyr is modular as well, so you see the big diagram there, but of course you can, whenever you compile your firmware for deployment to flash your board, then you will only get the runtime footprint will just reflect whatever features you are actually using. So that's a good point there. All right, now, so in terms of pros, the fact that it's so modular is very good. It's mature, okay, in the sense that before being at the Linux Foundation, it was open-sourced by its owners, and it goes back to, I think, 2012 or 14, something like that. So this is not necessarily brand new code, and I think it's even more ancient than that. I did the research and I forgot the date, but anyway, this is not something that has been written yesterday. And the ecosystem is really growing. You look at the commits, you look at the stats for the project, the level of committers, the number of committers growing, it's really on the rise. It's a bit heavier than FreeRTas because FreeRTas is very lightweight in nature. It's more of a real-time scheduler than a full blown OS. This is why you need to mix and match all your libraries to complement. And for the time being, hardware support is maybe a bit more limited, but this is growing all the time. So we come back next year, we come back in two years. At some point it will overtook, I think, FreeRTas and the other more popular commercial options in the market, at least in my perspective. And you see the nice thing about Zephyr is that this is vendor-neutral governance. This is an actual vendor-neutral project where you can be a part of it, whatever the size of your organization. And then you have a voice around the table and maybe not all of your PRs will be merged, but at least you have a better chance than trying to face Google or ARM, praying them some random product manager that you will accept your new feature in there, okay? Now, bare metal. Okay, so we spent a lot of time on real-time OSes, but there are ways to build applications, sometimes small, sometimes complex, and without requiring or using a real-time operating system. So let's have a look at three of those. First, there's a whole bunch of microcontrollers on the market and the Arduino family is just the most famous example of that. That you can use, okay, without an operating system. So typically they will use 8-bit, 16-bit microcontrollers. They are fairly cheap. You can, you know, most of them come with a bootloader, so you can plug that USB on your laptop and redeploy very fast while you are developing the application. But you can even, in some cases, squash a bootloader if you need the storage place that it's taking at runtime or even in storage, okay? And this is possible with Arduino at least. And of course, that being an OSless microcontroller, your programs execute directly on them. So for a small project, just gathering sensor data, sending that over MQTT or some other protocol, you could do it. And some of them I picked, you know, the Arduino or Ethernet as the photo in the sense that some of them have more advanced connectivity options. So you can get Wi-Fi, you can get Bluetooth, you can get Ethernet to integrate that easily in your infrastructure. So that's good. So in the case of Arduino, you know, they call their programs sketches. So this is a simplified version of C++, but it comes with an extensive libraries, you know, built by Arduino or the community. And in most cases, you will get support for, you know, the most widely adopted technologies. Once again, you need to determine if you find a board that fits your application and if it supports the protocol that you want to use. And worst case, you could maybe write your own library if it doesn't have support. So what are the pros and cons of that approach? Well, of course, this is a very simple approach, right? Okay, for applications, maybe similar to my little 10Z color computer in the beginning, you know, that would be certainly a good fit. Very small footprint, the devices are affordable, but you don't get multitasking, no real-time guarantees. The code is platform-specific in the sense that if I write, you know, an extensive set of apps using Arduino sketches, this is a simplified version of C++. So there's some level of portability, but if I want to move to a different thing, I'm not necessarily, I will need probably to rewrite some of the code. So take that into account depending on what you're trying to build. Then another example of a good approach would be the IoT development framework from Expressif. So this is really focused on their ESP32MCU, okay? So that specific little chip you see there. You know, it's a nice one. You know, it's got two 32-bit processor cores, Wi-Fi, Bluetooth, fairly affordable. And the development framework itself, you know, has built-in HTTP and MQTT clients and even support for ModBus if you need to integrate with industrial devices, for example. So that's good. However, you can even use FreeRTas as a kind of scheduler for it. Okay, it's a bit funky, but ultimately it's a version of FreeRTas that has been forked and patched for SMP since the MCU there has two processor cores and that kind of stuff. Anyway, so it's an interesting one, but of course, this is very specific to that particular microcontroller for that particular company. I picked it because it's a well-supported and very popular platform. But once again, you have to think about the risks of single sourcing, so to speak. So do you pick that or not? Well, it's simple. It supports multitasking. Real time is a possibility. You have primitives for that in the development framework and the devices are fairly affordable as well. But this is single vendor. Once again, it's open source, yes, but once again you have this mighty corporation that is holding all the reins and the extensa cores are risk cores, but they are not risk five, they are not armed. So if you're into low-level stuff, you know, this is a different architecture and you will need to learn it. So be careful with that. I'm not saying it's a bad one, it's just, it's a less common one and once again, there's a level of risk involved in that. And in this case, the MCU is 32-bit. Maybe this is overkill for your application, so you may want to take that into account. Finally, Droga IoT. So this is the two-minute introduction to Droga IoT if you want to really learn about this. Okay, there's a session Thursday morning by my friend Ulf from Red Hat. You know, he's from the development team. Are you there, Ulf? No? I was hoping. You know, he's not my friend anymore. Anyway, he's a great guy and there are two great guys in the team. Anyway, so this is a project from Red Hat, all built in Rust. There are three components, Droga device. So to write the firmware for your constraint device, Droga Cloud, a cloud management platform all in Rust and Droga Jure, which is brand new, which covers software updates. So this is great. And Droga device itself is based on MBC, which is an asynchronous programming framework in Rust. Okay, that contains a hardware abstraction layer and Rust itself, the runtime, they have people working on embedded Rust directly as well. So they take this kind of application in the Rust community fairly seriously, I would say. So do you want Droga IoT or not? Well, it's Rust. Well, I'm not writing commercial applications in Rust on a daily basis, so my opinion doesn't count. Yours count, okay? I don't have the pain of it. I play around with it and I don't have enough time, so please contact my manager to give me more time to do exciting technical stuff. It covers devices, cloud and software updates, so very comprehensive as far as platforms go. Real time is a possibility. You can do synchronous or asynchronous programming. So depending on your use case and your level of comfort with one approach over the other, well, both are possible, so that's great. For the time being, it's single vendor governance. However, if anyone from Red Hat is listening, I think Eclipse, Droga IoT, sounds really well. Anyway, hardware support could be a bit better, but this is growing once again. And the community is small for now, so go to Ulf's talk on Thursday morning and learn more about it. It's certainly a very, very strong option in my case, and if you are in Europe and we're thinking about coming to EclipseCon, the Eclipse Foundation's Developer Conference in Ludwigsburg, Germany in October, then we'll have a kind of hacker day where part of the components will be built with that, so this should be exciting. So if you want to see it in action, well, come see us in Germany. There's even a one day ticket just to participate to the hacker day, so fairly cheap and fun. And at the minimum, you will get good German beer. That's always a plus. All right, so about Eclipse. So I told you about many, many things that are tangentially related to what we do in Eclipse IoT. So this is just a two-minute overview of what we're doing. And if you look at this kind of generic IoT architecture that I put on the screen, okay? The next slide just illustrates the 20 plus-ish, most popular and well-maintained components we have in our toolkit. So when I told you that Eclipse is much more than the IDE, you have to believe me, it's there. Look at those logos, man, it's incredible. Anyway, so plenty of good stuff there. So if you're not sure, if there's something for you, come to me. It's my job helping you find out which could be useful to you in that large stack, okay? We also do with a sister organization, open source hardware. So there's something called the open hardware group. And what they are doing is literally developing open source risk five cores on GitHub. So you go there, you take the system virilog, you run that on an FPGA, you can modify the chip and that kind of stuff. Really cool. But you can go to global foundries and get 20 million of them if you want. Well, good luck with that. I don't think they have the capacity to serve you. Anyway, I love that to say that this is pure open source, you know, community driven once again. And what we do at Eclipse is really we provide them IDEs and of course the server side platforms that go with that to really form together a comprehensive open source IoT risk five base stack. So this is really fantastic. And I certainly invite you to have a look at what open hardware group is doing. They are not there this week, I think, but in any case, they will be in embedded word in Germany, in Nuremberg next year. They were already this year, but if you miss them, you know, please plan a visit to the conference and I should be around as well. So one last thing to remind you is that the Eclipse Foundation, this is something that some people still don't know, but we moved to Europe. So essentially we were originally US based nonprofit. We are now a Belgian based nonprofit and well already have close to half of our staff was in Europe. Okay, so for us that was a move that was really important. So some people may announce at some point that they open offices, you know, in Europe and in our case, half of our staff is already there in Germany, France, Spain, Italy, Sweden, and maybe more of the time forgetting and we speak our, your language, hablo en poco espanol. Ich spreke klein Deutsch, ich bin ein Anfiger. Eh bien sûr, ich parle français. Bon, so all of that to say that we take Europe seriously at the Eclipse Foundation and this is why we are there today. So thank you so much for listening to me. If you want to learn more, you can reach out to me on Twitter. I'm Blueberry Corder. There's a story behind the name. So if you make me drink a few more, too many drinks, maybe you will learn the story. And we have websites for our IoT, Edge Native and Sparklog working groups that are the ones I'm taking care of at the foundation. So if you're curious, please have a look. So thank you so much. And if there's time for questions or any questions, maybe we can take them or not. I'm not sure. So gentlemen there. Oh yeah, we need the microphone runner and I would need to put that in, I guess. Hi. Yeah, yeah, I heard you. It works. Okay, so how would you describe the landscape when it comes to programming paradigms? Like you can have preempty, non-preempty, voluntary scheduling, you can have even driven or synchronous or message passing invocations. You know, do these RTOSs are similar in that regard or are there any substantial differences? Yeah, there are certainly differences. I mean, if you take the case, for example, of free RTOS, it's a simple scheduler written in C, basically. So of course what you see there is what you get. Then if you take something like drug IoT and specifically the drug device that is the firmware part, then you can have synchronous or asynchronous, there's even an actor framework which is optional which you can leverage, right? So you need to pay attention to that because if you have a preferred programming style, something that fits well, not just your preference, but that fits better your use case, then of course you need to explore possibilities a bit. And this is something I maybe should have made explicit so eventually if I do a second take of this presentation I will try to update it with those kind of details but trying to remember all of that from memory at this point I would make mistakes so I would abstain for now. Any other questions? Yeah. I don't see anything. I mean, there's other OSs like Rust-based and RTOSs too. Oh, of course. Do you have any opinions on that? Yeah, well, a good example of a European-based open source real-time OS is Riot OS. I didn't cover it because I'm less familiar with it, okay? But it's also one option you could consider, for example. There are other Rust frameworks as well. You could use MBC directly. You could use even the plain support for embedded systems in Rust and build something with that as well. Ultimately, it all goes down to do I find the right balance of features and productivity in what I would use? So once again, I'm not pretending this is a comprehensive presentation. They didn't want to give me the three-hour time slot I wanted so this is what you get. Thank you for the question. Are two questions? Well, thank you very much for the questions and thank you for being here. Really appreciate it.