 Oh, hi, everybody, a little spicy there. All right, welcome to Zephyr onboarding in 30 seconds, methods and experiments during Zephyr training. I will prompt you all right now, it's not actually 30 seconds, it's a little bit longer. It was like, there's like a minute long video where I show it working. But today's talk is actually about training. So some of the things we're gonna talk about, what are some of the things involved in training? You might be interested in this for your own needs and maybe internally, you're trying to push Zephyr at your company, you're trying to get it a little bit broader, maybe you're looking to start a training business, maybe you're just looking to help others and bring others into the fold on Zephyr, all the good things. Today we're gonna go over some of the challenges, some of the things went right, some of the things that definitely went wrong and we'll talk about that. What actually it takes to have a good training experience overall, a case study, what's been going well for us and then some alternatives and some things to look at in the future and I'd love to chat about those afterwards. Little about me, I didn't know how to use Zephyr at first. Training is something I wish I would've had a little bit more of when I got started in Zephyr and I've learned a lot from my coworkers, I work at Goliath as a developer relations lead and I've been doing hardware for a long time, been trying to get better at firmware and with Zephyr I think I have been. I also put a, I'm a reluctant DevOps trainee, you'll see that a little bit later because we're gonna talk about some tools that actually you might wanna deploy to make this all a little bit easier. Little bit about Goliath, we're an IoT cloud company. This is why I'm doing training kind of on a daily, weekly, monthly basis. I use Zephyr all the time for reference designs and you can see some of those later if you're interested. So really good for trying out not only the training but also being able to use Zephyr all the time. Little bit about why training is hard and we should do it anyways. One thing is just that it's expensive, right? So if you wanted to do a training, the best training would be one-on-one but that would be really, really expensive to look over someone's shoulder and spend four hours with them getting up and started with Zephyr. So you're trying to basically optimize and trying to get one person that can train 10 people, that sort of thing. Another thing is that Zephyr has a learning curve. We should just admit that Zephyr has a learning curve, you have to get people up that curve and you're trying to do it as efficiently as possible and that's another reason we're doing training, of course. Another reason that I'm doing training is because we're trying to get people connecting hardware to the internet, right? So Zephyr is fantastic for having a wide, wide range of connected hardware and so we wanna do Zephyr so that we can get as many different hardware platforms connected as we can. And I think another thing to admit is that as much as it's growing, this is a very good-sized audience here, there's still a ton of people in the world that are not yet trying out Zephyr and there's a lot of hardware informer engineers that are future Zephyr users and so that's another thing we should look at. All right, let's start with the fun stuff. What went poorly? So we've done two trainings that went kind of poorly. The first one was a corporate training we did on site and we had eight trainees and again, this is, it was a relatively small group, we had three people that were training and we thought everybody was using Linux and it turns out, no, actually a lot of the people out in the world use Windows, right? Especially embedded developers coming from the hardware and embedded space, there's a lot of Windows users. There's chocolatey instructions that were around at that point but we didn't have a good handle on those. We were kind of developing those as they came up and so kind of just acknowledging, yes, people are coming in with lots of different OSs and that sort of thing but other things that are just more logistical, right? You're in a corporate environment, there's firewalls in place, you're trying to download different packages. At the end of the day, a lot of the trainees ended up being like, oh, we know how to fix this and they pulled out their phones and they tethered to their phone and then they were downloading Zephyr packages over cellular and it's like, okay, well, that's a way around it but not a great thing for training. So permissions issues, you know, like having admin on a Windows computer, all of these things are things you have to kind of think about. The other, I'm gonna say failure, was actually last year. At ZDS, we did training, we did, I think it was about 25 people at ZDS last year in San Francisco and people came in with, you know, as you do, you come in with all different types of hardware, right, or different types of computers, right? Linux, Mac, Windows, all these different things. We learned a little bit from the previous training and so we brought a Wi-Fi router, we plugged a USB mass storage in and we were like, oh, we can like serve the files off of that. We have the files all ready to go, we have the tool chain, everything ready to go but even that kind of got congested. So another thing is just that you have a lot of people in a room, you're gonna have network congestion and you have to kind of deal with that. Other things that were problematic, it was Zephyr training, or sorry, there was a Zephyr summit, so people were looking to get better but they probably had already tried Zephyr, so they had some form of Zephyr on the computer and maybe their path permissions were kind of messed up or they had different versions of Python and just dealing with everybody's different thing is another thing you have to think about. You have to think about how people are coming into a training with a computer. Things we haven't tried, so we, so Mike and I, Mike's dish, my coworker at Developer Relations, we know a lot of people have done training before and we've seen other things that have worked, one of which is image laptops, right? So this is people who show up, one of our friends, Joe Fitz, he shows up at every training in person with 24 laptops, usually Chromebooks, that are imaged the night before. So he does R-Sync on 24 laptops, that's always doing the night before and he's rolling in with Pelican cases for the laptops and that's one thing that's great about it because you have USB access, you know as you ask him what's on there, the user does whatever they want to that laptop and then at the end of the time you're just wiping them out. Downside is that you can't do remote training like that, right? You can't roll it into everybody's house or ship on the different corners of the globe and we are very interested in doing remote training as well as you might be. Another option is USB sticks. As the graphic shows, I don't plug just random ass USB sticks into my computer on about you but from a security perspective, please don't. If you talk to your security friends, they will say please fill your USB ports with cement, that is the safest thing you can do for your computer and it doesn't work for remote training but you could do a virtual machine, I've talked to some trainers who've done this sort of thing, they might run VMware on a USB stick and try and do that sort of thing. That gets you to kind of a unified environment, that's not bad but it's not optimal again, you can't do it remotely. And then finally the thing that I always hear, well why don't you ask your users to pre-install the software and to that I say do you live in the real world because I have never gone to a training where you have 20 people show up and they're all like oh yeah I spent all night installing this tool chain and everything went smoothie. They usually say oh what room are we in again and we're training Zephyr to say okay, then they kind of get into it. So I think you really just, you have to plan on if people aren't gonna do this training then you're gonna have basically two groups, the ones who kind of did the homework and they already are set to go and the ones who are spending a good chunk of time installing tools. Like I said last year at ZDS it didn't go like we wanted it to and about 30 to 40 minutes in we only had a portion of the users that were like ready and into exercises. So you wanna kind of figure that stuff out. So let's talk about some truisms about training in general, right? So we wanna start by assuming nothing, right? You basically say I don't know what a user's gonna show up with. You don't know, you're gonna learn about Linux distributions you've never heard of before. We actually had one user at a training I'll talk about later, he showed up with a laptop that had broken the night before and he's like hey I have a steam deck with me and my laptop's broken, can I do this on a steam deck? And I was like oh my gosh. So if you don't know that's a handheld gaming console, so like a nine inch screen or something. So people are gonna show up with all kinds of hardware, assume nothing about it other than they probably can access a webpage maybe. It's just you're gonna have to start from that. The perfect number of things to install on a computer is zero, right? So that is, again it's a truism but it's not always realistic. So you kind of like what is the closest you can approximate this sort of thing? You know, again if I could ask people to show up with a clean install of an OS I would but that is not realistic. So what is the most we can do to approximate this? And finally it's that downloads take time. So this is kind of like we had a US, best case scenario we had a USB stick with us plugged into a router, it's set up as a mass storage device on a network device. We should be able to download it but we have to assume that it still takes time. So you can't assume anything about the network either. So this is really painting a negative picture overall of computing in an age of gigabit downloads and very, very fast computers. I'm assuming an EEPC and a DSL connection rather but you kind of have to just kind of assume a worst case scenario. All right, so let's talk about a little bit about what we're doing currently because this is probably what you actually care about. We use something called chasm and so chasm is, it's a desktop as a service solution. Basically it's the easy way to think about it is a full Ubuntu machine that lives inside a browser. And I know that this seems like overkill and I'm going to try and argue my point here but the thing that I really like about it is that I pre-install the Zephyr tool chain, a project and kind of a bunch of helper tools in there via code, plugins, all the things that you might wanna have on a machine and you have the standardized environment and I know it's not necessarily the thing you might wanna do but I think it is the best case scenario is here. So basically you log into a browser, you have a log in there and then you get connected to an EC2 machine that is off somewhere in Amazon's massive infrastructure and you have access to a bunch of RAM and a couple processors. But really you can go from zero to compiled in about 30 seconds to a minute. Another thing you have to do though is you still need to have localized debugging and programming tools and so we switched over to Nordic Development Kits recently. They're very well supported in the Zephyr tree and they also have Jlink on board. You could approximate this with a lot of other tools as well. I think having a programmer on board is important, especially if you wanted to be doing, sorry, a debugger on board is important if you wanna step debug and do that sort of thing in the future. We also like that there is kind of this infrastructure of tools that are tested on multiple OSs. So this is again Nordic's solution here. They already tested for Linux Maco and Windows and that standardizes the programmer and the zero interface. We do not actually have a direct connection. So again, we're somewhere in the cloud. We have a compiler that's happening and running and creating a binary. Currently we don't have any way to connect to that from a debugger and that is still something we're interested in. We'd love to talk about that after the fact. But that is not currently possible so we actually download the binaries and I'll talk about that a little bit more later. Another thing I think is important that we do is we actually don't deliver the training. I don't stand up here and talk to you about now we're going to do this, now we're gonna do this. We actually write everything out and we have it as a standard walkthrough guide. So if you have access to this chasm machine, you could do that just about at any time. But I think it's really important because you don't wanna assume that your users, how fast they are, you don't wanna lose people. One of the toughest experiences is just the difference in speed when you're training people. Some people are gonna race through stuff, excuse me, they're gonna race through stuff and be done in 30 minutes. Some people are gonna take the full three or four hours that you allot to them and you wanna make sure that they can kind of go back and review and that sort of thing. Written instructions also just generally help you decouple from all this stuff. And it gives you kind of a reference point later. This is training.goliath.io if you ever wanna check that out. That's available to the public. Another thing that we do is we wanna have some kind of like personalized, so when you're doing a remote training, you wanna be able to personalize your advice and recommendation much like you'd walk up to someone at training and look over their shoulder and maybe guide them. You wanna be able to do that same thing. So we use something called gather.town or gather.town and this basically allows us to, the little avatar walks up to someone, your video pops up. It looks like Legend of Zelda basically on the Nintendo and then you can have these kind of privatized conversations so you can go and help someone and that's really important here. Again, I think it's really, some people are a little maybe camera shy, but I think it's really important to be able to have the video and screen sharing capability so that you can really help someone, again, like you would at an in-person training. I'm trying to optimize for remote. I think that's really important in our post COVID era. It travels still really expensive and getting places and you wanna be able to enable people wherever they are. All right, let's see if video will work. So this is just showing it kind of in action here. So this is us logging into the CASM machine here. I click over just to the training to show you some of the commands that I'm gonna go and copy there. Now I'm in the machine here. You can see that I'm making the machine full screen. So again, this is just, now I'm actually within the Ubuntu environment within a browser here. Able to load up VS Code. I can drag and drop the locally installed project, so this is just a Git project that's available to the public. Drop this here. You see that we have our repository. You have to, you know, VS Code, you have to trust the authors here. But then we're opening a terminal and pasting the command here, which is just a West build for this board and we're off to the races. So that was a little bit, that was about a minute there, getting all the way from clicking a button, getting into an environment and getting a build started. And I would challenge people to do that on a locally installed machine with nothing else installed. I think that would be, that's a tough thing, right? You just because of download speeds and the various repositories you're doing there, even if you have the most minimalized setup, I think it just takes a little while because of all the tools that you need to make Zephyr go. And I think we, yeah, we stopped. I don't show the whole build here. Again, at the end is building a binary. You then do have to download the binary off this remote machine on your local machine and then you can load that binary onto your device. So, and you know, you could do the same for a .ELF. You'd have to have a different set of tools, maybe like an Ozone debugger or something. You could run a debugger on your local machine as well, but it's not going to be able to use like West Flash and West Debug, which is one of the big downsides because that's like in my daily driving, I just, I use West Flash all the time and you don't get that here. But from a training perspective, I think it's really, really important. Okay, let's talk about some of the things that went right here. So we started running this thing. We started using CASM. We started trying this out. We were some friendly folks that we had. We were using the MagTag board from Adafruit, which is great, uses the ESP32 S2. It has an E-Ink screen on it, bunch of sensors and stuff like that. Didn't have USB CDC, which is not great for debugging. We don't have a serial output, but we were able to get people kind of through the training. They were at least able to, you know, ping the servers, blink some LEDs, that sort of thing. This was still a little too Linuxy, right? So this was still like, hey, everybody's going to use text-based editing. Again, another thing you shouldn't assume. People want to use VS Code. They want to use the various editors. You want to let them kind of install the tools they want and or use the tools they want. We then tried this with a larger training. We got up to 30 people. And this started to really strain our ability to give individualized attention to people. And so you still want to do that. So you want to kind of one to five, you know, like one trainer to five people is a kind of a best-case scenario. I think one to 10 is really kind of straining it. And any more than that, you're probably not serving the people that need help. Because again, it depends on what their experience level is. If they are doing a little bit of, if they've already done a little bit of Zephyr and you're trying to kind of move them up to intermediate level, you might be okay with that, but that's a little tougher. We tried an in-person training. This was great where we had, we did this at Hackaday SuperCon last year. We were again, we were using, we were all in person, but we were using the Chasm server. We had hardware in front of them, so they had that connection. This is where the Steam Deck person showed up. He actually was successful with it, which was, I thought was really, really great. He was able to use this Chasm server. He, you know, it was really scaled down, but he was able to build the firmware pulled to his Steam Deck program, the device. So that's really great. We were still using Python because of the ESP tool.py. And so that was still a little bit difficult there because you're, again, you're kind of depending on what people have on their local machine. They might have various versions of Python or might not be that familiar with it. So it's, again, just kind of assuming that people, you don't assume anything about the people really, you know, you just try and make it friendlier tools. We just did a recent training in June. I'd say this was probably our most successful yet. This is where we switched to the Nordic tool. So again, we had kind of this kinder interface, you know, kind of a more gooey focus sort of thing. We also changed some of our training too so that it was more focused on the RTOS kind of lower level stuff. So, you know, what are threads? How do I do device tree? You know, just more focused on a lot of the getting started content there. Just a little bit too short. So we actually are doing another training here. So there is a QR code over at our booth. If you want to sign up for this, there's still a bunch of room in this. We're going to do a three hour training. So this is coming up on July 12th. So, you know, we don't actually know if people are going to show up with any embedded experience where we had pre-qualified people in the past to be like, hey, you've at least done some embedded stuff before. People might show up at this one and be like, hey, I haven't blinked an LED in Arduino even. So that's going to be a potential risk of this but we'll see how it goes. All right, let's talk about some things that can go better. One thing that is kind of rough with this chasm and various things like gather town is the inception effect, right? You have a lot of windows, there's just a lot of window management. So one thing that we tell people is to take the chasm window, I kind of showed it where you take the chasm window by itself in a tab, you make that the full screen it kind of acts as a background. So if you're all tabbing over it, you can still get to other windows but it's still a little bit messy. You know, it's best if you have multiple screens but you can't ask that people have multiple screens especially in person. So that's kind of tough there. Network still matters, this is not surprising, right? So you're streaming a remote container over a custom VN CETO browser, like yeah, your network's gonna matter, right? If you have to put 30 people in a room, you might start to strain the wifi. So that is another thing you have to worry about there. The way that this works, right? Again, how this training works with downloading binaries like this, this isn't how we do Zephyr, right? This isn't, at least every day, Mike and I don't do Zephyr like this, we're using Westflash, we're using built-in J-Link tools and things like that. So that part is kind of outside of the normal flow and all I can say is this is just to get people up and started, right? So just kind of keeping that in mind that we're just trying to get people up the curve enough so that they're like, yeah, I'm willing to go and spend the time and invest in my local tool chain and learn this stuff because a lot of it is about getting that first dopamine hit. And again, if you're thinking about doing this for your company too, you're trying to basically get buy-in on an idea which is using Zephyr, training with Zephyr, trying all these different things, just trying to get people interested in it enough to spend the time later and so this might be a reason to do this sort of thing. And again, the last thing is the downside is that you don't end up with the tools on your machine, right? So you'd think you want people to walk out of a workshop and be able to like go and recompile later or try stuff later. All I have on this data point is that we offer that people can log in after the training using the chasm server even though we don't have additional machines spun up because we spin up like 30 EC2 instances for 30 trainees. Well, we can still host two or three people after the training and I've yet to see anyone log in after the training. So if that's a measure, I think that that kind of discounts this one, right? People will come back to the training on their own time when they want to do it. So don't expect them the next day. And again, we're just trying to get them enough dopamine that they're like, yeah, Zephyr's the answer, right? That's what we want people to do just so that they put in the time later. All right, some future experiments because I know I'm running a little bit short on time, I think, yeah, I'm okay. Let's talk about other things that are out there. So things like code spaces and GitPon, so GitHub code spaces, is basically you ship a file up to your repository that says, here's my development environment and here's how my container is defined. And then you click on a button and it launches a VS Code window in the browser. So kind of similar experience there. You're within VS Code and then you're usually able to build on top of that tool chain that is in a container from your VS Code environment, right? So it's kind of like, it's just a containerized version of Zephyr, which you can also get off the Zephyr, a lot of the Zephyr maintainers also use containerized versions to maintain the tool chain. GitPon's another one that does that sort of thing. Downside is, you still don't get that local hardware connection. So you might be able to develop and have some standardization within your company but you won't still be able to do West Flash, West Debug. As far as I know, again, if anyone knows, after this talk, I want to talk to you. So come on up afterwards. Another thing that's tough about this for my example is that I'm trying to train people outside of my org, right? So if I want someone to use my Gitpod or my GitHub code spaces, I need them to either sign up for GitHub if they don't already have it or I need them to use my computing resources, right? In what I'm talking about with CASM, I pay for all those EC2 instances to be spooled up and ready to go in this case, it's like you're kind of like depending on people's free credits, that sort of thing. One thing that we are looking at doing is, so Nordic has some VS Code tools. I think VS Code generally is kind of the unifier in a lot of this stuff. Like it or not, I think that VS Code has kind of become in the new ad hoc standard on a lot of people's machines and tooling environments. I know a lot of the chip vendors are standardizing on it. And I think it is closer to this. You'd still run into a lot of the same problems, right? So you still have to download a lot of stuff. You still need to have your toolchain set up. There's still things that could go wrong. But I think it would then be about the thing that would change would be how much you try and optimize your build so that you're using things like manifest files to really make your project very, very small. So you're only pulling in the ARM GCC EABI. Basically, you're only doing the ARM GCC stuff that you're targeting or whatever your local toolchain needs to be. And your project is really cut down as well. Another thing that we've talked about is getting all remote. So Walkway actually has some experiments using Zephyr. If you don't know Walkway, it's a really cool virtualized hardware platform. Kind of started with Arduino, but allows you to bring in sensors and other things like that. There's a bunch of ESP32 support in there. We've actually done some experiments where we have compiled a binary in Zephyr for the ESP32. And then you can actually program it onto this emulated device, and then it actually talks to an emulated WiFi gateway and it actually talks out to the internet. So again, we're trying to emulate connected hardware here. That's a good experiment here. So if you wanted to train people a little bit more about not just device tree, how do you make an LED connect to a certain pin, but also how do you actually interact with a virtualized potentiometer or some kind of more in-depth hardware simulation. That would be the kind of the way to do it. And then I know people are gonna ask about just like dev containers, Docker, that sort of thing. A very realistic request here. Personally, I think that unless there was some super, super simple way of doing things, I know that Docker works in VS Code and stuff like that. I just personally don't feel like this is the way for me. And then how do we troubleshoot things, right? So again, we're kind of always thinking about how you're gonna troubleshoot the things that go wrong. And I feel like localized Docker might not be it for me. There is a great talk about dev containers. I'm not sure how this is gonna come through. Oh, there's a V on top of that hexagon there, but these slides are available online as well. So you should go and watch that talk. Yes, so if you'd like to come and see a bunch of the hardware that we build, we're in booth 41. Like I said, we do reference designs. We build Zephyr-based hardware just about every day. We write about Zephyr all the time on our blog. And that's also where you can sign up for training as well if you're interested in that July 12th training. And yeah, I love brainstorming about this stuff. I'd love to hear about your personalized experiences. I'd love to take your questions. And I hope to see you all at training sometime. So thank you. We have a mic for questions. I'll want you so we can get on the recording and we have some virtual questions too. Is anyone planning on doing training internally or externally, like hosting training for other people? One, all right. Two, three, four, five. OK, great. How are you planning on doing it? Straight. OK. OK, so one person in front was saying that already having the environment installed, so maybe your company already has a good path for doing installation and that sort of thing. That works. OK, great. Yeah, having standardized tooling. I think within a company, actually, it helps, right? You're already working and trying to have standardized tooling within a company. You might have a kind of a similar context there. I think that really helps a lot. You might have an IT group that helps you with that sort of thing too. Join a training or put someone to join this training, even if it's locally, it should work the same. Yeah, right. All right. Benjamin's going to tell us how he's doing his effort training for the rest of the world here. Totally not. Quick question, the cost of running something like CASM, like per participant, per day, per hour, like what are we looking at? Yeah, so CASM has a per license cost, which is, I think, $10 per seat per month sort of thing. But in terms of the actual server cost, it's 80 a month just to host a EC2 large, t3.large. That's the host machine. So again, CASM, you have a host machine, and that can host a couple of people in there. But then it also has all user administration, that sort of thing. But to spin up, so for a four-hour training, if I go and spin up 30 EC2 t3.mediums, I think it's $1 per instance. So if you think about four-hour chunk of just spinning up hardware like this, it's very, very affordable. I think the real cost is paying for something like CASM or developing yourself, and then hosting that kind of like always-on thing. Yeah. You didn't offer more information about the training on 12th July if it's hybrid, if it's online or something like that. Yeah, that's the one on the 12th is all remote. You have to buy your own hardware, but the training's free. It's all remote. It starts at noon Eastern Standard Time. We have some questions slash comments. Well, actually. So Sam said, some browsers now support WebUSB. Might be something to explore for connecting to users local JTAG debug probes, question mark. Followed with, also some JTAG probes have ethernet interfaces like JChase Pro, which, given use permission as well, can be accessed from JavaScript on the browser. Yes, that's great. I would love to try that. Have you tried using WebUSB or similar technologies? We haven't tried that yet. Yeah, I think that's reaching the limits of my capabilities personally. And I think in terms of exposing it through a container to the local browser, I'm not sure how to do that. I'm sure there's something out there. I haven't found it yet. Also ethernet? Also ethernet. We have a blog post about that. Yeah, I don't know which friend you're talking about, We've done some experiments with JTAG over ethernet. JTAG over ethernet, that's cool. I think it's also about, again, for the stuff that we do, we're trying to do it so it's readily available hardware, which is tough. You're basically like, what is something that's affordable that is available across the world? We have people that are buying hardware, shipping it to India, shipping it to Brazil, shipping it to all these different places. So it's like, is it available? Is it relatively inexpensive? Is it deliverable within a week or two? Like all of these things are important. Again, that's for like a public training like that. If you have a company, you might already have standardized hardware, that sort of thing. So, one on the back. So first of all, thanks for this very inspiring talk. I have a question regarding the hardware because you said you're using those Nordic connect, those Nordic SDKs, the Nordic development kits. That's right. Do you actually expect the participants to already order them by themselves or do you ship them to the participants? Good question, yeah. So we expect, so the training that we do is free, but yeah, the user has to buy and ship it because, you know, customs, VAT, all of the stuff that you wanna make sure the, we don't know where they live, what all the restrictions are. Export limitations as well. So, we basically lean on Digikey, Mauser, all of the different distributors, some local distributors have them as well. So yeah, we wanna make sure that, so one of the things that went wrong in the last training that we did is that I waited too long. I said basically, I had sent out acceptance notices like 10 days before the training thinking, oh, like I can order a board within, you know, two days shipping is relatively affordable from like Digikey to my house, but someone who's, you know, in India, they're like said, I can't get it within two weeks. So that's a restriction there. Okay, another question. Have you considered doing a flipped classroom? That is the presentations are recorded and students watch at their leisure. You spend class time helping hands on. I taught community college full time for over a decade and I found it pretty successful. Yeah, that's a great idea. I think that's kind of what we approximate with the written training in terms, we don't have any video stuff kind of embedded there, but with the follow along at your own pace, it really is the flipped classroom is that we're kind of going around this virtual classroom and just trying to help people, you know, unblock them. So we've had some feedback though like, hey, I expected there would be a little bit more presentation here, but yeah, you can find a lot of videos online of us talking. Hello, I'd like to talk about your customers, your potential customers. Are they very experienced programmers? Are they students? I mean, what type of customers are you looking for? A lot of the people that kind of come in, I would say like the typical person that is taking training that might be a customer, don't know, would be a hardware developer, maybe a beginning firmware developer who has done some stuff before. I've heard a lot of people like, oh, yeah, I've used my vendor tools before in an Eclipse IDE and on Windows and it just kind of worked. And now it's like coming to Zephyr, there's kind of Linux forward ideas there, so that might be a little scary and trying to learn about device tree and things like that. I might also be projecting since that's where I came from. Okay, thank you. Run, John, run. Yeah, have you tried just a regular virtual machine because you mentioned the dockers, but how about virtual or regular machines? I'm asking because I've lately attended the training with regular virtual machine in the back end and visual studio code with remote SSH connected to this virtual machine and it worked really well. Okay, that's great. So that was like talking to actual hardware as well? Yes, yes, yes, because the USB is transferred to virtual machine and in visual studio you just feel like you are working on your host but in fact this isn't virtual. Yeah, no, I'd love to chat more about that afterwards actually. Was that like a, when you say virtual machine as well, you mean like a VMware or like a virtual box? Yeah, or a virtual box. This was the only prerequisite and yeah, this is challenging because everyone had to download those two gigabytes as a prerequisite and some Apple users also had some problems with I think M1. Yeah, so that's another thing we ran into recently as well, like a lot of the tooling around the new Apple chips as well has, you know, usually there's, I think a lot of that has been started to shake out a little bit, but even just like some of the install and like the Nordic tools had some alternative instructions, right, so you just kind of point people with that. That's another thing to think about is new era of chips with Apple's dominance. All right, well, if you want to demos later, I could show you TriDoc Live that I always kind of our chasm server. I can show you that on my machine that you're interested in seeing that sort of thing. If you want to check out all the training materials, if you want to like follow along, I should have put this up here. I didn't put it up here. Training.galite.io is actually where all those instructions are. Training.galite.io. And so like this is how we teach people how to use Zephyr. So, oh, wrong window. Thank you, John. So, you know, we use DocuSource, really great open source project from Facebook that's markdown based. And so, you know, just kind of follow along and do this sort of thing. There's an associated repo as well. So, if you already have Zephyr tools installed, easy way to start. But I love brainstorming around training. I'd love to, you know, expand the training capabilities to bring more people into the fold and check out Zephyr some more. So, thanks so much for coming today.