 So, I'm here to talk about the Yog2 project, extensible SDK and how it can make life easier for application developers. Nice to see a full room, so thank you to my pitch man, Tim Orling. And let's see if, okay, so we'll start off with what we'll be covering. First of all, why do we need an extensible SDK and to kind of help guide me through the talk. What will be interesting is can I have a show of hands for anyone who's used a Yog2 SDK or application development toolkit, as it used to be called. Thank you. How about those of you who have worked with extensible SDK, the later version of that. That is so good and bad, bad that no one's used it, but good I'm here to show you what it's about and how it can help. So we'll talk about how application developers are going to use it and why we thought it was worthwhile developing. So once we've covered that to show how it's going to make their life easier, we're also going to talk about what you have to do as a distro maintainer, a little bit more you have to do to configure, we'll see how it affects their lives. And then we'll have a show how it sort of pulls together the lives of the distro maintainer and application developers and kind of show you an end to end workflow. And just as a heads up before I start, this will not be a DevTool deep dive. DevTool is a tool delivered by the extensible SDK. Tim Olin gave an excellent talk yesterday where he covered all the details of that. So I'll be skimming over DevTool and if you're not aware of it, if you missed Tim's talk, you'll find it on the slides, but I'm afraid I don't have time to go into detail. So we'll start by saying, you know, what is extensible SDK? Why did it come into fruition? We'll start by reference. I talked about the standard SDK. Sounds like quite a lot of you have used it. So as you'll know, that is designed to develop code to run on a target, a target machine standard cross development approach. It was delivered as a shell script installer. So you would get all the host tool chain, all the libraries, symbols and stuff that would be built and deployed on the target, and also an environment set up script. So once you run that script, it would set up all the environment and technicals. So it would invoke the correct compiler, linker, and those tools. So that's been around for a few years. I should have done my homework in an exactly how long, but I'm five plus years. That guy's been around. So during that time, we've learned a few things. First of all, as I mentioned, it's delivered as a shell script installer. If you've got a fairly complex target, large number of libraries on it, a few applications, that installer can quickly approach a gigabyte and get larger. So if that SDK is under maintenance, libraries are being fixed, the regular continuous integration, you'll be getting updates, so you're dealing with pulling down a gigabyte installer every so often, reinstalling it, having to move over to a new workspace, it's all a little bit of a pain. So how could we improve that? How could we make it extensible? Same as updatable, really, but rather than fixing things that are there, you're adding new things. So your platform had, say, an ambient light sensor. No one had written a library for it. Now you do have a library. It's now been extended. How can you use that? So standard SDK also was all about building binaries that would run on your platform. But as you know, to incorporate that into a Yorkter build, you have to convert the source code that's going to generate your binary into a recipe. So the distro maintainer can take that on board, make a package, add that to the build. But you're just generating binaries. How can you get to recipes? So we want to help you out and automate that process so you don't have to bring a recipe expert down into your world as the app developer. Also be great if you could build not just binaries, but how about the whole image plus your binary? Because what you'll do, you'll have your hardware, target hardware with the image. They're going to add your new application, push your application on there, make sure it all runs. How about you want to share that between a few co-workers? You have to go and repeat that step up. Wouldn't it be easier if you could somehow build an image? Just give them that image. New pool, all the things I've talked about, all these improvements, if they were all there, teamwork and developer flow, that would be a lot easier. So we thought about this and came up with the concept of the extensible SDK. So it's a major design change over the standard SDK. You're not simply getting a tool chain in libraries. Now essentially you're getting a shrink wrap full scale developer distro developer environment. So this will also come as a compact installer. Because we thought people were not very happy about having to deal with gigabyte installers plus the fact they might be working on a small part. If you've got a complex system, you're just working as one sensor. Why should you have to install gigabytes of tic-tac? If you're only going to be using a very small part of that. So you can configure it to have a small installer, smaller 35 megabytes. The way that works is a whole system is updatable and extensible through lazy install. So in other words, the tools and libraries are pulled down when you need them. This will also simplify the teamwork, as I mentioned on the previous slide. Now extensible SDK sort of code for it first appeared in Jethro, although it was in Krogoth really that it delivered its full power. And we're investing in that and it's getting improvements in every release. So now let's talk about using it. If you're an application developer, how do you use this thing? So first of all, obviously, you need to install it. Installer that's created by the distro maintainer. As for the standard SDK, comes in a shell script installer, although now it can be a lot smaller. It's completely self-contained, so should have no dependencies on your build, your build host. Also it can be installed to an arbitrary location, so a relocatable installer. So I'll just show you a quick example of how you might install it. First of all, your distro developer will give you an installer. It'll have a name a bit like this that will involve the distro name. In this case, it's just pocky, the default. And in here is targeting an i586 based target. So you download that, make sure it's executable, and then you run it. Note the minus D option. This will put it to a location of your choice. If you don't use this, it'll default to somewhere in slash opt. And that means you need administrative privileges to do any further downloads or updates, it can be a bit of a pain. So I would advise putting it somewhere local where you have full permissions. So then you just simply run the installer and it'll tell you what it's going to do, what version it is, where it's going to install it. It'll run through, do its install. You'll see there's a bit of bit-bake here happening, but it doesn't take all that long to install. This is actually a small, a minimal installer. So it took 17 seconds, this was a fairly old four core i7 machine. Then it's done, and after it's done, it shows this is the environment set up script I've been talking about. So at this point, you want to make a note of this. You don't really need to remember the whole name, because this will be the only environment set up script that exists in this folder. Okay, so let's look at a very simple example. So this assumes that the ESTK installer contains a tool chain. We'll talk about that later, what I'm really meaning there. But in this case, we run the environment script. I've just talked about, and then we just do a very simple compilation. And we just run a hello program pushed out all to the target. So no change here, really, over the standard SDK. So it's just showing that the extensible SDK, although we've added features, is backward compatible with the standard ST SDK. Allows the clips into integration as you've had in the past. But also, it's updatable, unlike the standard SDK. And I'll talk a bit more how that happens. So the key thing is it's got access to new tools. Now, when I say new, these are not new to Yachter Project, but they're new to SDK users. Essentially, you're going to get access to most of the distro tools. The main one you have access to is DevTool. Because this will certainly give you an easy to use gateway into the key tools. But also, you've got access to the recipe tool. If you know how to use that, want to do some real customization of some recipes from source code, access to work. If you want to do image configuration, a lot of the tools. Also, run QMU. So if you have a target that says QMU, you can actually run QMU from your SDK, which is pretty cool. So you can have an instant target. So if we'll do an example DevTool workflow, so as I mentioned, this is the key tool delivered by the extensible SDK. And again, I'm just going to touch on this. Tim covered this in detail. So again, we start off by running the environment step-up script. But now we're going to get a lot more than just a compiler. So now we've got DevTool, and we're going to do DevTool add. So what's happening here? You point it to a repo, it's got a project in it. In this case, a simple auto-tools project. A lot of you might know the venerable BB example. So it's going to pull that down and generate a recipe. You can have a quick look at the recipe here, look what it's done, check everything's right. Then you just do a build. And then you just deploy it to your target, assuming you have a network connection. Then you do your run fix repeat until you're happy with what you've got. And then you do DevTool finish. So what this will do is it'll publish the recipe to add any patches caused by your changes. And we'll publish all that to a layer. In this case, it's just assumed that you've made a fork of the layer that the distro maintainer will be adding to his build. And once you've published there, you've issued a pull request. Let the distro maintainer know. So he can then pull that and then publish an E SDK with your work in it. So now everybody else in your team has got access to the enhanced BB example. So we talked about the big deal about the extensible SDK is that you can now update it. So one of the big commands here is using DevTool. DevTool again is SDK update. So what's gonna happen here when you run this and you should run this on a regular basis. Usually you'll get a heads up from your distro maintainer. There's a change to be aware of, but it runs very quickly. And the reason for that is it doesn't pull down all the changes that have been made. It's just aware of the changes to the metadata that has been published. So in other words, it's now aware of any package version updates, new tools, et cetera, et cetera. So if you want to extend your SDK, so now you want to pull something down and play with it. You can use DevTool to search for what applications and libraries you might be able to have access to. And if you find what you want, you can use the SDK install. So the minus S, there's some brackets there, that says you can pull down the source code if your distro maintainer has not already built it. And then you can build it yourself locally. So we'll talk about later how we can also leverage some of the pre-built artifacts that your distro maintainer has created. So I have an example here of let's say you have the small installer, the 35 megabyte one. You can just use SDK install to pull down the tool chain. And now you'll be in a situation that's quite similar to the standard SDK if you want to follow that development model. You can also do everything that I've talked about in a container. Hopefully you attended Randy Witt's talk earlier today when he was talking about containers. If you did, you would have heard him talk about one of the containers that was available is for the extensible SDK. What the container does there, and I'll not go into details here because that's all covered in his talk, but essentially you start up the container and point it to the installer. It then pulls everything down into a workspace and that means that you can then run on Linux but also Mac OS and Windows. And the big deal about this is that quite often application developers are more comfortable working in those environments. Particularly now we've added support for Node.js projects into DevTool. Quite a few Node.js developers might prefer to be working in Windows. Hopefully that's giving you an overview of what life is like as an application developer for the extensible SDK. So now we're going to look at it from a different viewpoint. What work needs to be done by your distro maintainer to enable these improved tools? So obviously the first thing the distro maintainer needs to do is just to build this. So he or she will be building a recipe, the image recipe here, and just use minus C, populate SDK, EXT. It's as simple as that to get a default extensible SDK. Now when I say default, that means it includes everything, a bit like the standard SDK does. All the tools, all the host tools, the native tools I should say, the required to build the image plus all the libraries and applications that are in it. Stolar will end up in TMP deploy SDK and you need to make that installer available to your developers. And that's the installer that I showed you being used earlier on in the presentation. So now we're going to talk about how do we customize it? So by default I mentioned you get the full installer. So that'll be the gigabytes of data. Say you want to access the small installer. You give your app developers the small installer I was talking about. In this case in your local.com for however you're choosing to configure, you just set the SDK, EXT type to minimal and now you will have a small installer. And we'll talk about updating later how you can configure that. You can also if you want to add a tool chain to the installer. So obviously it can make it quite a lot larger than your 35 megabytes. But if you want, you can add that in again just a simple one liner in your local.conf SDK, SDK include tool chain. Another tip is to add all the package info. So what this is doing is doing an equivalent sort of like making you do a bit big world. So in other words, it is generating the package info but not doing the full packaging for all the packages and all the layers. So obviously as a distra maintainer, this is going to take you quite a long time to build. But it's quite a nice thing to do because then your application developers will have access to all the packages you could possibly build not just the ones that you think they should have. And then if you want to customize further, you can add specific tools or libraries. You can use SDK extra tools. Now an example would be here is that say the venerable core image minimal or even I think core image base. They're mainly auto tools projects. But let's say you're giving a base SDK and somebody wants to add an application that's got C making it. Wouldn't it be good if you made C make available to that person, that developer? You can just add it in here as native SDK C make. You can also add specific libraries if you want to by using the tool chain host task variable. Yes. So what it has is that's a good question. So it has a dev tool in it and enough of the metadata so that when you would run dev tool for the first time like earlier on I said, dev tool add BB example. So dev tool will say, ah, that's an auto tools project. I need the tool chain for that. So it's gonna pull the tool chain down. Everything that's required to build that project. So now you're gonna have a lot more than 35 megabytes in it, but the reason for that is that you might not be doing any auto tools work. You might be a Python guy. So if you're a Python guy, why do you wanna install all the tool chain? But I take your point, and so the point of this slide, thank you for the question, the point of this slide is to showing you how you can put as much or as little as you want into the installer. You probably know your application developer target so you can say, well, I think all these guys need a tool chain, so let's add it. It's really up to you as a distro developer. So I've talked a lot about the updater. How does all this stuff work? So the first thing you need to do, shoot, okay. So the question was that if you prepare an SDK installer, it's got more than just the minimal amount in it, can the person installing it pick and choose what's in the SDK? And the answer is no, they can't. You ask the distro maintainer, we'll build an installer, and whatever is in that is installed, which is kind of quite a nice segue to say that that's the attraction of the minimal installer, because then you're only gonna get what you need. The problem is that when you do the BB example thing, the first time you do the DevTool add, there'll be a bit of a pause whilst it goes out to network and pulls everything down. And I'll shortly talk about why it doesn't need to build stuff add tools-wise. Okay, so now we're talking about the updater. So what happens here, you need to define a URL. Your application developers don't need to be aware of this unless you're having multiple versions. So I think it's safer. Let's just say for this example, you can just specify the URL. By default, when they call their update, they're gonna use the URL embedded in the installer, so they don't need to remember any magic address. So you just set that URL in your configuration, again, sort of local.conf here. So SDK update URL. You go and do your build, a bit minus C, populate SDK ext. After you've done, here comes the extra step. So you run the command OE publish SDK. You point it to your installer, but you also have to specify an output path. So this is where it puts all the published artifacts. And all these artifacts have to then be put onto the web server, so they're served up at the location defined by your update URL. So this means now, when you're actually using it, the dev tool SDK update, it will automatically now go to this URL, and by looking at the metadata, it's got locally available. The metadata on the server is gonna see, are there any differences? Is there any metadata updates I want to do? And I stress, when you run the SDK update, it will not actually pull any packages down, it will just sync the metadata. Think aptget update. Okay, so once you've made all these changes, you've published, you can let your app developers know. But really, they should also be in the paradigm, the wrong word, they should be in the habit of doing regular SDK updates. Because all it's doing is syncing metadata, you're not gonna lose much time, so do that every morning, every hour, how often you want. So we talked about download of stuff on demand here. So the BB example, you've got your 35 megabyte installer, you do dev tool ad, BB example. So it says auto tools projects, I need the tool chain, so let's download the tool chain. So it's not gonna download all of that and build it because that would take ages. So it'll download the pre-built tool chain. Now what's useful here is the concept of shared state where there's pre-built objects. Now, those of you who've lived so of a distro maintainer will be well aware of shared state. Those of you in the app developer, land will not be so familiar. But all this really means is this is the output of all the build that has been going on, that has been executed by the distro developer. There's a signature checking system that makes sure that it's gonna match the object that you actually need. So it means that when you come to build and link stuff, everything has been built already, it's just there available for you. And the only delay is the network time taken to download that. So you can see an example here, let's say you're building a QMU x86 target for a core image of an animal, my pretty vanilla development machine for core i7 takes about 35 minutes with estate. All it's doing is taking down all those objects and assembling them, it takes about a minute. So it shows you how it's gonna accelerate your time. So as a distro developer, obviously you need to make this estate mirror available. And again, your app developer doesn't need to know any of your URLs, it's all baked into the installer. So again, you set this, you choose a URL. This time you have to use a bit of a special configuration file because you don't want to clash it with any estate that you may be using yourself as a distro developer. So it goes into a different file, stkextra.conf and then do your build, then build the stk minus cpopulate stkext. After that, make sure the estate cache is served up at the location that you've defined. So now let's try and pull everything together. So this is gonna sort of show a workflow of a distro maintainer and a number of developers who are dependent on each other's components. So we have a number of actors in this scenario. So we have Bubba, who's a distro engineer, the distro maintainer I've been talking about. You have Joe, he is developing a C library, let's say it's a sensor library. You've got Laurie, who's a Python app developer and then you've got a third party JavaScript developer here. For this flow, we've assumed all the app developers have already done the initial install of the estk. So now they're in the update and build cycle. So we start off with Bubba makes a estk, bit, bit minus c, populate stkext, and he's published that up to the estk server. Joe does his stk update, so now he knows he's got the latest version of the estk. So he uses their DevTool add points to his sensor library, so he then generates a recipe, builds and debugs using the DevTool workflow I touched on earlier, and then when the library is ready, he uses DevTool Finish, which finalizes the recipe and touches, and then he sends the recipe to Bubba. However, he's agreed to do that via pull request or whatever. So then Bubba does his builds. Let's say Joe's been a good boy, has provided tests, they all passed, everything is looking good. So then Bubba publishes the revised estk. Now he's got Joe's library in it. So Laurie and Betsy can now update their estk case. So they've now got Joe's access to Joe's library. They use DevTool add to generate the recipes, and they then build their apps, which are now using Joe's library. Here we go, the build and debugs cycle, and then when the apps are done, they do their own DevTool finish. They work with Bubba, send it up to him, and he turns the crank and ships the product image, and as you know, it's all that easy. So that was a joke. Okay, so let's wrap up. How am I doing for time? So just recap over the benefits of the extensible estk. Hopefully that workflow slides showed you how it gives you a shared development environment. Also gives you access to the power of DevTool. Much better environment than there's simple tool chain. We've seen how improve the workflow, how everything happens quickly through using shared state, and also through the container, we can now run on a range of host operating system. Okay, so wrapping up, I'd like to give a thanks to Paul Eggleton. He's the maintainer and current owner of the extensible estk. Randy Witt, who did a lot of the early work on the estk and helped me out with a lot of the technical details. I'm more of a user of this stuff and actually a core developer of it. And I don't know if Randy's in the audience, but we might need to call him Francis. Brian Avery, who helped me tell the story here, and Doug Martin who helped me with those wonderful build slides. So the call to action is simply you move over to using the extensible estk. I saw in the audience at the start, not many of you have played with this. I encourage you to give it a shot. You see what they can do for you beyond the simple tool chain and they can run using the same environment on Windows and Mac. So there's a QR code here, which will take you to this sort of landing page on our wiki, where I've tried to summarize a number of articles, the right appropriate parts of the Yocto project manual, the SDK manual is the best place to go for this. Some tips and tricks and also a pointer back to this slideshow that's not yet available on the ELC website. And with that, I'm done and would like to take any questions, Chef. So I noticed that with your Joe example, that you had a big wall with a third party JS part of it. How does the estk help me when our team develop source code, but we have a third party vendor who can't necessarily see all of the source code, but they need all the binaries. Right, okay, so that would work out in that instance there, I would have to say I'm not quite, I think you can set things up so when you do the SDK install, I'll need to check on this, but you saw the minus S option in there, you want to be disabling that. I want to ask the distro maintainer, I want to find out if that can be disabled. And so that means all they can do is install the binaries so they cannot install the source. If you can capture that question and get back to me, I'd love to make sure, because that's a really good request, really good solid feature request right there. I'm not sure if we can support or not. Yes. Yeah, so what is the limitation of the update ability? I mean, I guess you cannot like jump from like one version to the next using update or can you do that? What are the limitations there? Oh, do you mean running from say you're on Yachto 2.1 and you moved to 2.2? For instance. That is a good question. I would doubt you can do an update. I have not tried that. I'm just thinking that you're in a build environment and you're just improving things from a middleware aspect, a middleware and driver aspect. Okay, so maybe distro features would be okay still? I believe distro features ought to be okay, yes. Okay, good, thanks. Hello, one of the things you mentioned was that the shared state cache for this should not be shared with the main one. Is there a particular reason for that? Yeah, so the question was that when you're preparing the installer the way you configure the shared state cache that will be used by the ESTK users is differentiated from the SDMirror that you as the distro developer are using. Well, in theory I guess they could be the same. I'm just showing how you could keep a partition if you wanted, but I believe they could be the same. Just a question. Is there a mechanism to maybe go to a fixed point in time of the state of the extensible SDK to be able to reproduce a build? Okay, so the question here was can you go back to a fixed state in time and reproduce a build? So I guess a solution to that would be that each time you produce the installer, you're an option to generate a URL. So when you do an update, you do, you know, your kind of update is rev one, rev two, rev three, rev four. And I think the only way you could do it is get somebody to, because you can't roll back with the installer just now. So they probably would have to blow away their environment and then install rev x and then they'd be back to a known place. So that's the good we have discussed internally is running rollback mechanism. You know, I mean, that's a very good, that's another feature request I need to make a note of, hopefully. Thank you. So one of the reasons why there actually was the third party wall was because of work we've done together. And so one of the ideas there is actually Bubba is just gonna build two different URLs for the SDK, right? One of them is with sources for the internal people and the other one's only binaries. Okay, those were some great, great, great questions. So as I mentioned, we wanna make this usable for people. We wanna encourage people to use it. I think the big strength, as I mentioned, is hopefully you saw the build out slides towards the end. It's just creating a shrink-wrapped distro environment, distro developer environment that app developers can use. And even if you want people to help you modify or upgrade recipes, you can, not even from an app developer perspective, but if your time is too short, as the distro maintainer, you want to farm out of work, just generate an ESDK. And that's the easiest, fastest way to replicate the exact environment you're working in. I think another point that Henry brought up that's really important is this minimal SDK, extensible SDK, because it gets to be small, right? Because anybody who's looked at the Yachtel project produced extensible SDKs, they're 2.1 gigs and so on, right? Because there's a lot of stuff in there. And so that led to an impression that extensible SDK is therefore very large, right? That's not true. The reality is it's easier with a server, webhook type of situation where you're actually gonna get the data from an update server. So that's really the mechanism you should be thinking about internally in your teams is providing that. And it's as easy as Python-m simple HTTP server 8080 or whatever in the right directory and it serves it up for you. So you can do this pretty quickly without having to set up Apache. One more question about that is in Randy's example, when he did the extensible SDK in the container, he pointed out the installers generated by the Yachtel order builders. There's a bug open because they're not yet generating minimal installers. So the only one you'll find out for the Morty builds, I believe it's still building only a full installer. But hopefully in a few weeks time that should be resolved. One quick question. I've got a team that's a bit spread out. They're not all in one location. Is there a straightforward way of doing authentication credentials in this or is that to be released at some future point or is that a great idea for a pull request or? Right, that is a great idea for a pull request. Okay. And thank you for offering. What do you mean? What do you mean by that? The question was, what does an SDK build for Windows look like? I should have clarified the question before repeating it. If you generate an SDK with cross-compilers that could actually run on Windows, Shell Script's not gonna work to install those. Oh, well, so currently our approach, the current approach we have is to run within the container so we don't do that. So we're going, the Windows support and Mac support is going away from MetaMingew, away from MetaDarwin. So we're just taking the Linux tool chain and running it in the container. Does that make sense? So we're not running, it's not running natively on Windows. I don't know if natively is the right word to use here, but it's not running on Windows. Yeah, exactly. Sorry, that was a bad option. So yeah, so we're running everything in the container just because we're not having to spread ourselves so thin in terms of maintaining the MetaMingew, which would always fall into disrepair. I know that because I tried to use it a few times, MetaDarwin, I don't know if that guy works or not. But anyway, this is the way forward through the containers. And I would believe those layers will be not be getting so much love from the Intel Yocto team as we focus on the container solution. M-Sys2 actually lets you run some Shell Scripts and things like that, and you'll think, oh, that'll just work, right? But the reality is then it's gonna get into file system problems because the native file system doesn't support it. And so that's the Windows side of it. And on the Mac side of it, with MetaDarwin, you've got Apple as not open source. And so we don't know what they're doing, and so we're guessing, and therefore we get into things that we can't control anymore. And so those two situations just keep churning and burning our developers, and we need to be having them focus on other things, and yet we still wanna support the users that do wanna use Windows and Mac. And so we've actually been working on the Windows and Mac solution with containers for a while now, but what Randy presented today is actually the simplest solution. It actually works the best compared to some other things we did try that we even presented last year. So that's a really recommended way to go, and I think all of us can tell you that we've been doing it natively on those OSs as part of our development workflow. So I just have a Xeon box in the closet that's running my estate mirror, and I'm doing my actual development on my Mac, because that's my actual day-to-day work. Actually, I'd like to ask a question, if you don't mind, when I asked for the hands up, who used the SDK, standard SDK, a lot of hands went up. So when you guys had done your work, and then you needed to create a recipe to add whatever you'd done into the image, did you learn how to use, create a big recipe, or did you just point your distro maintainer body at your source code and tell him to figure it out, or what generally solution do people have before dev to add? So what we did in our organization was we actually, I want to say we, I mean, I did this, created a Debian installer, so we would take the SDK installers without working in dizzy. Take the SDK installers, install those on a platform, and then minimize and scrape that and package it into a Debian package, put that in a Debian repository and notify our developers, okay, if you're using this version of the OS, because we tagged the OS for the particular version, then you need to use this SDK, so they would have to install that in their workstation. Okay, okay. Yep, so when, hopefully, hopefully DevTool, I see as a key part of the SDK and hopefully that's gonna smooth the road between application developers doing their thing and then how does the magic that they've added, the differentiator of the product, how does that get back into the image? And that's what we're all about trying to help. Make use here. Did anybody else have another approach? Okay. So my team lead would like to know how many of you want to be using an IDE like Eclipse? Specifically, how many of you want to be using the IDE called Eclipse? Ooh. Let's clarify that. How many of us would use it and how many of us would use it? Okay. That is actually the question I'm asking. Thank you for, so, rewarding. How many of you have teams, have users who want to be using Eclipse that you need to be supporting? Okay. Thank you. Thank you. That was a much better question. So what about like VS Code or something like that? Is there interest in that area? Okay. Well, I'm asking for, we're trying to get a feel for what actual IDEs are in the wild and what people are actually trying to support because we've poured a lot of resources into Eclipse at times over the past few years and it's really, really hard to continue to maintain it and we're not sure if people are using it. One of the problems with an open source project where you've just got a website and people can pull stuff down, you don't actually know how many users you have and how they're using it. And so we come to these things and we do get some feedback from people but we don't always know if anybody's actually using it because sometimes people don't want to send questions to the mailing list or whatever and so we just don't know and so we spend time working on something and then we don't know if that was valuable time or not. So that, we did get a good enough feel though because it's probably about 40% of the audience here was, okay, and the key creator, so. Okay, that's a pretty good number. That's about 20%. So VS Code, I saw only some shaking heads, so not there yet. What about, what's PyCharm based on? C-Lion and, okay, it's a couple folks. Idea J is what I was thinking of, I think it's what it's called, yeah. Oh yeah, Vi, okay, Vi. And yes, and my technical lead would not let me leave the room without asking for Emacs. Okay, okay, so, thank you guys. Okay, thank you.