 Hello. Welcome to the Embedded Linux Conference Europe. Thank you for attending my presentation. My name is Alejandro Hernandez. I will be talking today about the Octa project and how to use the Octa project on Windows. This is something that has been going on for a while. We as developers usually use a Linux machine to build the customized Linux distribution that it's coming from the Octa project, but sometimes Windows machines are more available. It's useful to know what's out there and how we can take advantage of it. In this presentation, I'm going to be talking a little bit about crops. I'll talk about the Windows subsystem for Linux and go through the user experience of both of those things. I'll extend a bit further on WSL and basically tell you how you can create your own distribution. I will talk a little bit about Docker and WSL at the same time, and I will do a performance comparison of these different variants of workflows. So first of all, crops. Crops stands for cross-platforms, and this has been in the Octa project for a few years now. What it does is that it leverages Docker containers to allow you to build or to get the Octa project environment, which is on an always agnostic sense. You can do it on Windows, you can do it on Mac, or you can do it on Linux if you want to. Interesting, the crops itself, it's a repository on GitHub. You can check it out there. I put the link there. Some interesting repositories there are the parking container and the extensible SDK container. So, go check them out, and yeah. I won't be diving in a lot into crops because there's a very good presentation that happened at ELC 2017 from Randy, and if you want to know the details about it, you can certainly go and look at it. It's still up to date. So, we can use crops to build the Octa project on Windows or other operating systems, but there's also the Windows subsystem for Linux now. So, first of all, what's the Windows subsystem for Linux? The Windows subsystem for Linux lets developers run a GNU Linux environment, including most command line utilities applications directly on Windows. There's no overhead, so it's basically the user experience is basically the same as running a container. You can just issue a command and you get into the VM. So, there are two different WSLs. The version one that came out a couple of years ago, and version two that just came out this year, I think, with the pandemic, I don't even know. But yeah, I think this year. So, there's a couple of primary differences between these two things, and the main one is that WSL version one uses a Cisco translation layer, which basically interprets the Cisco's or many of the Cisco's coming from Linux and allows them to work on a Windows NT kernel. So, there's that layer in between those things that allows them to communicate. The problem with that is that it's very challenging to implement all Cisco's. So, some apps might not work on WSL v1, but on WSL v2, there was a restructure in some way. So, this time, WSL v2 uses actually a built-in Linux kernel. So, there's no translation layer in between, and now it has full system call compatibility because of that. And you can get increased IO performance on most cases. So, I dare you to go ahead and try to clone something using it on WSL v1, and it's not gonna be very fast. But if you do it on WSL v2, it just goes very well. One thing to note is that if you're working on, if you're mostly working on files that are mounted from a Windows file system, WSL v1 has a better performance. In our case, we rely heavily on Git, for example. We rely heavily on IO, and all our files are located on a Linux file system. So, WSL v2, it's what we should be using. It's actually not, WSL v1, it's not supported by the Yachter project. So, the first thing's first. The Yachter project has very good documentation. So, I encourage you to go ahead and look at it. The first thing that, one second. The first thing that if you go to the documentation and look at what it says about WSL v2, you're gonna get this. I'm gonna go through the several steps they have to follow to get WSL working. So, the first step is make sure your Windows machine is capable of running WSL v2, right? There's certainly more information on Microsoft blocks and stuff like that. But at a very high level, you need to check what build you're running on Windows. And you need to make sure that that build number, it's later than 18.917. So, to do that, you just open a Windows command prompt and then you type VER, bear. So, after that, you get the Windows version that you're running and you can compare it to that. If you're running a compatible version, then we can go ahead. So, the next step is actually going in installing the Linux distribution that you wanna use. So, this is very simple. You open the Microsoft Store, you look for Linux and then you get several distributions there that are available. For example, here, I just posted a screenshot that shows several Ubuntu versions and a Debian and Susan. So, that's the next step. You pick the one that you wanna use. For example, let's say you picked Ubuntu 2004. So, all you have to do is click on get and it will automatically be downloaded and installed on your system. After that, you'll get a button that says launch and that's it. If you click on launch, you'll get a, you'll open a window and it'll make, the first time it'll make some installation and that's it. It'll open a window that contains access to your Linux system. So, number three, let's make sure that you are actually running WSLv2. So, to do that, again, you can open a PowerShell, for example, and then you type WSL-L-V, which stands for list and verbals. So, if you do that, you'll get a list of the distributions that are installed on your Windows machine. And in this example that I'm showing you there, you can see that I have several distributions there. I have Ubuntu, I have Debian, I have SUSE, and I have three others that are showing up there that are the Docker data and the DumpFill, which I'll be talking about later. But the important thing is that you need to check. For example, there, I got SUSE running on the version one. The column says version one. So, I cannot use SUSE in this case, but I can use Debian, I can use Ubuntu just fine. Okay, so step number four is go ahead and start developing, that's it. I already told you that if you click on launch, it will launch a window and you'll get access to your WSL distribution. You could also, from the PowerShell, you can just type WSL-D, which stands for distribution, in the example, for example, I am using Debian. So I call Debian and I'm inside the Debian distribution and I'm just showing you that I'm catting OS release, just so you can see that I'm running a Debian 10, for example. And another important thing is that I'm checking which kernel it's running. And that is because kernels are shared across the distributions from WSL. So in this case, I'm running for that 19 Microsoft standard. It's just something for you to know. All right, next step, it's start building. So one of the good things about this is that there's really not much difference between the usual flow. So once you get inside your Linux distribution, you can just do the same thing that you do on your native Linux. In this case, I'm just going into the Pocker repository. I'm sourcing the environment and I'm calling BitBake for a core image minimal. It's important to note that I'm building a dump or release 3.1.3, exactly at the tag, because I wanted to have a baseline and build the same thing on the several flows. So I didn't want that to change. It's also important to note that I have already built this and this is building from Estate. So I am going to give it a couple of seconds there. As you can see, there's 1159 tasks to run and all Estates are in 1156, we're already found. So I have a 99% match, so it'll be pretty fast. We can see all the sets in tasks executing and then after that it's actually doing the Budafest. So that's going to finish really soon, do image, and that's it. So I just built a customized Linux distribution using WSL, cool. Now, testing, testing, it's exactly the same as if you were using a Linux native Linux as well. The only thing I did is that I ran runKMU, I passed no graphic as an argument and there it is. It's just booting my Linux distribution that I just built. I get a login prompt, I log in as root because this is the reference distribution. And then lastly, I'm going to check what kernel I'm running. And if you can see there, I'm running 5.461, Yachto. So I got a distribution running, it's great, everything's working fine. So another thing that you can do is that you can test your distro that you just built using WSL itself. To do that, for example, in that example, I'm running WSL-L-V again. And as you can see, there's no dump file listed there. But after I do that command, which is importing the tar file that I just built for core image minimal, that's going to run again. So WSL, oops, sorry, it's going to actually go inside the distribution. But anyway, so you check what distros are available and then you call WSL-dash-import and you pass several arguments to it. First of all, you pass the path where your hard drive is going to be and you pass also the tar file that you want to import. In this case, that tar file is the one that I built using Yachto on WSL. So that's what I'm doing right there. And it's imported. Once it's imported, I can look at and list these things again and you can see that dump file 313 is there already. So I can just go ahead and run it in the same way I did with the others, WSL-d, dump file 313. And then I am inside the distribution that I just built. The one thing to note is that, for example, there I am looking at the kernel and this is actually using the shared kernel on WSL. So it wouldn't be as useful to try and test something with your kernel while using WSL. QMU might be a better option in that case. All right, so I just tested a distribution. I tested it on QMU. I built it, I tested on QMU and I tested on WSL as well. Now, let's say that there's a distribution that I just tested there, the dump file 313. Let's say that I wanted to extend there for some reason. Since I can run it on WSL, I can use it for a different purpose. So if I wanted to extend it, for example, initially it won't have GCC, right? So it's too, for my development flow, it's useless. So what I'm gonna do is that I'm gonna install the built-to-extended table, which is you can build from the other projects as well. And it will contain several tools that basically will allow me to build Pocky from Pocky. So what I'm doing there is that I'm installing the table. I am sourcing the environment as if it wasn't SDK, just like that. And then after that, I can actually run GCC again. So as you can see, I'm running GCC 9.3, which is the one built using the October project. So every development is different. You can use it for different things. In that case, I was just trying to test a way that I can have a Linux distribution that I just built custom. I can import it on WSL and I can use that same imported distribution to build another distribution and just have more use to it. Okay, so I can also talk a little bit about Docker. So again, crops leverages the Docker containers and there's way more information that you can look at on the GitHub repository. But Docker now contains an integration with WSL V2. So it just basically allows you to run Docker commands from WSL districts. So what I'm gonna, I'm gonna reset that. And what I'm doing there is I'm running a Ubuntu distribution from WSL and then after that, I am going inside the pocket container repository from crops. Once I'm there, I modified a single line to just, I'm gonna rebuild the container, but I want it to be based off on Ubuntu 20.04. So for example, I am just gonna rebuild it. And again, I am inside WSL Ubuntu at this point. And there you go, it starts rebuilding. It just integrated properly with WSL V2. So once that's done, once that's done, I can look at the Docker images for example, and I can see that I built a crops pocket 20.04 for example, and I can just run it. If you look at the instructions from the GitHub repository, you can see that the preferred workflow is that if you create a shared directory that you can share across with your container. In this case, I call the crops work there. And then I am just running that container and passing that directory to be shared. And I'm inside the container now, and I can start developing. That is exactly the same flow that you would use if you were running on Docker Duster for Windows or even on Docker from Linux. So it's now integrated. And then I can basically just clone the repository and I can get a working container that allows me to build a Occhi distribution. It contains all the dependencies already. You can see more information on the GitHub for crops by the way, performance. So I thought it'd be interesting to show. So I already showed you the user experiences and I think they're pretty similar. So there's not too much too complicated there. So I wanted to see, okay, what's the difference between performance? What if I wanted to use this on Windows or on Linux? So what I did is that I built, for example, Core Image Minimal. I used WSL, I used Docker and I used native Linux. I built it several times, but this is the average time it took to build. And on WSL it took 79 minutes on this specific system. And then using Docker, it took 82 minutes. So it's a three minutes difference. And I honestly couldn't pinpoint anything that was taking longer. I was actually expecting something to take longer and me going to have an evoc. What was the difference between WSL and Docker? But no, surprisingly it was very similar. So to me, I just looked at it there pretty much the same. And I built it on Linux and it took, actually it was actually a bit faster but by about 10 minutes for Core Image Minimal. So then I went ahead and built the same, it did the same thing for Core Image Saddle. For Core Image Saddle, I built the same thing on WSL, on Docker, on Linux. And this time, WSL took 108 minutes. Docker took 107 minutes. And Linux actually took 113 minutes. So it's only a five minute difference, but I think it's neglectable. I don't think there's a lot to it. It could have been anything. One thing to note is that I did, so this is not relying on the network. I had already downloaded everything, but this is not building from SD. It is building from scratch. It just has all the sources locally. So as you can see from these two things in the performance comparison, to be honest, it's a bit boring. It's surprisingly good. So I am very glad that there's no real difference in performance. And I think it comes to the fact that like when it comes to choosing which flow you're gonna be using, I think it's just preference. It's up to you. Maybe you have something on Docker already and then you can leverage it. Maybe you don't, maybe it's just easier to launch WSL. It's up to you. But performance-wise, I feel like they're pretty much the same. As you can see here in FirstSatO, Linux took even more time. So yeah, as a summary, we talked a little bit about crops. We talked about the Windows Assistant for Linux. The user experience on WSL and the user experience on crops as well extended what the functionality basically of WSL by creating your own disk or using the OctoProject and then modifying it. One thing that I didn't mention was that I installed the build tools to our wall. And I could use GCC for example, but I could simply install package management as well and use something like apt or OPKG or DNF to extend the functionality of the distribution that I'm using. I also talked a little bit about the Docker backend of WSLv2 and how you can use the same commands on WSLv2 as well. And we did a performance comparison. So that's it. Thank you very much for attending and let me know if you have questions. You can reach out to me at that email address by the way. Thank you.