 So, hopefully you're here to hear somebody, namely me, talk about why the ACTO project for my IOT project. If you are not here for that talk, you're welcome to stick around. I don't want to bore you with something you don't care about. But if you're in the wrong room, this isn't like an airplane where you're stuck. You're welcome to get up and go to the right talk, but hopefully we're all here for talking about the same thing. I have a mic up here. I would encourage if you have questions as we're going, I'd much rather handle them as we go rather than waiting and batching them up at the end. So just do your best to get my attention. I got the mic up here. I know we're recording in the back, so we'll try to pass the mic around if there's any questions or discussion as we move through the presentation. So briefly, what the heck are we doing here? Why are we here? So I'm going to start just a little bit with some motivation about why IOT is interesting and that kind of thing. I suspect for most of us it'll probably be redundant, but it's always good to kind of start with that level of detail at the beginning. We'll dig a little bit into some of the challenges for just general embedded development, for Linux development in more particular and even deeper for IOT development. Again, probably a review for a lot of those in this room given the audience of this show, but still good to have it in there, especially since this will be captured for posterity somewhere. Then we're going to describe the basic IOT workflow, kind of getting started, you know, when you're getting started with an IOT design, what the heck do you have to do and what are the first five or six big questions you need to ask? Then we'll dig a little bit into an overview of Yachto, ultimately that is the meat of this presentation and talk about some of the benefits of both Linux and Yachto as it relates to IOT development. And with that I kind of wanted to kind of pull the audience here. How many in here are familiar with and have used Yachto in the past? So pretty much everybody. So the benefits of Yachto, I probably don't need to sell you guys on unless you're just starting with it. What about IOT development? So a little bit less than half it looks like. So a decent arrangement of folks. This isn't really intended to be a deep dive into Yachto or anything like that. I've got some links at the end for some other talks. There were quite a few other talks going on at this conference. So if you're really looking to get real deep into Yachto, this isn't the place for it. A little bit about me. My name is Drew Mosley. I currently work on a project called Mender.io. You might have seen our booth upstairs. It's an open-source project for deploying over-the-air updates to connected embedded Linux devices. I've been in the embedded Linux development space for about ten years, focused primarily on Yachto and then longer than that in general embedded software. My role lately is more about technical marketing, customer solutions architecture and that kind of thing. The Mender project is a completely open-source project. And if you have the need for some over-the-air updates for your connected devices, we sure would love to have you use in our product. So as I said, motivation, this is typically the business side of things and the links to things like Forbes in various places where they talk about dollars and things like that. I think it's pretty obvious to everyone in this room. Our embedded projects are increasingly using Linux. Again, this is the embedded Linux conference. Not hard to sell most of the folks here on that. The market opportunity, obviously, is pretty big. $267 billion by 2020. I think we would all like to have at least some portion of that. And Linux is an extremely big player in that market. Nodes and gateways are estimated at over 17 billion units by 2023. And that's driven by a lot of things, but the relative inexpensive hardware that's out there, relative ease with which you can gather them, things like Raspberry Pi, Beaglebone, I'm sure we're all familiar with. And then production hardware with manufacturers like Toradex, Verisite, Boundary Devices. And then the semiconductor manufacturers are also playing a big part in making this available and more widespread. So some challenges as embedded, in general, as embedded developers, as embedded Linux developers, and IoT developers that we face compared with typical enterprise or desktop style development. We deal with a wide variety of hardware. On any given day, we may have multiple chip sets on our desk. Our design may have a multi-core ARM where it's run in Linux. It might also have a single core MCU running on RTOS, that kind of thing. We'll deal with ARM one day, maybe x86, maybe MIPS, so we're kind of all over the place. We also have a much wider variety of storage media we have to deal with than is typical in the desktop application. Most of the boards we deal with in the prototyping space, they generally use SDMMC or just onboard EMMC. But more commonly these days, we're seeing raw flash devices. We're seeing SATA devices. There's quite a range of choices there. And each one of them has their own pluses and minuses and challenges with getting images deployed to them, longevity, and that kind of thing. When we're dealing with embedded Linux, the software we're using might not be maintained in the canonical upstream location. A lot of times we have kernels that are maintained by the chipset providers. Eventually the changes will make their way back upstream, but at any given time we might be working with different forks that are not necessarily the same from project to project. And of course we're generally speaking dealing with cross development. We do see some native development where you install just your standard desktop class distribution on your board and you actually run your compiler and things like that on the board. But that's generally a pretty painful approach given the performance of most of these devices. And if you haven't been in the embedded space for a while and you're not familiar with the workflows involved with cross development, that can typically be a pain point that we want to try to help ease for people coming into the space. And getting the initial images on the device and keeping them updated is a constant battle. Every device has its own mechanism. If it's an SD card, it's pretty simple. You usually pop the SD card out, you put it in your desktop. You're able to write the image. But if it's got onboard EMMC or raw flash, it's going to have its own mechanism, which is typically going to be unique to at least the board vendor. So you're going to have a different provisioning setup that you use for any given device at any given time. So you're getting started in embedded Linux and IoT development. The first thing you do is you go to the web and you say IoT Getting Started Guide. So that's what I'm trying to get at here with the next couple of slides. So the first step, buy and pick your hardware. Obviously, the picture here shows a number of Raspberry Pi devices. I think we've all seen those. There's all sorts of selection guides. The link at the bottom of the slide here from Make Magazine covers somewhere between 30 and 3000 boards, depending on the day you go look at it. The number of boards that are available is astounding. And they come in a wide variety of form factors. Certain different amounts of memory, different chip sets. So there's plenty of resources on the web for you to start digging into some of these things. But that's the first step, what kind of hardware are you looking at? How much power do you need? Do you need display capabilities? Do you need video input capabilities? That kind of thing. Second step is what is your connectivity? What I'm showing here, this is a Toradex Astor board. That's their base board, actually on the back side of it is their system on module. So that can be either be an IMX6, IMX7, IMX8. But typical connectivity, especially in early portions of the development, obviously you got your power in Ethernet, you may have USB. In this case, we have an LCD panel connected. So you look at the connectivity you need for the development side, where you're gonna need things like JTAG maybe, maybe serial consoles and things like that. And then also the connectivity for the end use of your application, whether it's gonna be Wi-Fi, whether it's gonna be ZigBee, whether it's gonna be any of these new protocols that are coming out. So all of these things, you wanna start thinking about early on when you're putting together your high level plans for your IoT design. Once you've got the hardware and you've got it connected somewhere in your lab, you need to install the operating system. And generally speaking, in the embedded space, in the embedded Linux space in particular, there's three main ways that you're gonna get a target operating system. One is you're gonna use a binary distribution. So this is very much like you do in your desktop laptop PC. You go to Ubuntu.org, you go to Debian.org, whatever you download, a binary image, you do a write of that using the DD utility or other utilities to your SD card and you boot it and you go from there. At that point, you've got a fully functioning system. You can run app, get update, get the latest updates, get the latest kernels, install whatever programming languages you need, that kind of thing. And with a binary distribution like this, it looks very much like you're working on your desktop operating system to begin with. One step or move from that is moving backwards to the build tools that are generally used by the distribution folks themselves. Things like DE Bootstrap or whatever the build tools are that are associated with your distribution of choice. That gives you a little bit more control and a little bit more flexibility as far as having a starting point that you can share from developer to developer. But it's not quite the equivalent of what we call a build system, which is where Yachto fits in. And the distinction really is with things like Yachto and Buildroot, there is no separation in the developer's mind, typically between the build environment and the run environment. They're all the same thing. Whereas with something like an OpenWRT or a Debian, most of your users are going to grab the binary and that's all they're going to work with. And then you have some set of core developers that will be working on the packaging and the build system. But with Yachto, it's all one and the same. And once you have a system up and running, next step, develop and test your application. A lot of details that I'm glossing over in these two bullet points. And that's not really the meat of this topic. So I figured I'd kind of put them together. We all know we have to do it. And once you have this base system up and running, you have numerous options. We'll touch on a few of them as we go through. And then we want to test the system. Do all the blinky lights come on when you expect them to? Are all the peripherals working the way you want? Is your application running? Do you have the proper network connectivity? Do you have, you've got an Internet of Things device. You might have a fleet of multiple devices. Are they communicating with each other as expected? Do you have your cloud infrastructure on the back end aggregating all the data? There's a lot of details, again, that go into that test. And some of that is related to Yachto and some of that's kind of peripheral to it. So we won't dig too deep into that. And finally, deploy the system. Again, glossing over a lot of details. You might have analytics. You might have logging. You might have fleet management. You'll have updates of your system over the life of your system. So there's a lot involved there. And the choices you've made all the way up till now will play very, very much into your ability to do this successfully with your IoT designs. And I kind of lied. There is a step eight, because ultimately this is why we're here. We want to make some money off of this. So step eight is obviously, once it's out there, end users, consumers love our products. And they rush to the stores to give us money for our products. So ultimately, that's our goal. So I ran briefly through what a build system is. But let's dig into that. What exactly is a build system in this context? It's a mechanism to specify and build the software, the system software, all the way up to the application stack that runs on your embedded device. It may include the bootloader. Typically, it will. But some designs, it's going to be different. It has a mechanism to define the hardware and the BSP. And it allows you to integrate your application, any additional libraries, any additional custom code that may be provided by your manufacturers or anything like that. The build system is going to give you a way to integrate that all in a well-defined workflow that allows you to easily bring those components in, mush them all together into a single distribution or a single binary that you're able to then deploy and provision to your devices. One important thing about a build system is it allows for easy reproducibility. This is one of the big differences between something like the OctoBuild system and starting with a Debian system where you log into the system and run app, get update, and pull everything down. When you run a build with the OctoBuild system, what you get at the end of the day is the fully functioning system. You don't then expect to log into the system and add extra packages in there. So you know that exactly what you have in your lab and your testing is what's going on in your end user devices. So that reproducibility is very important. Because of that, it allows you to support multiple developers. If you're dealing with a golden SD card image that some developer in your lab has installed everything on exactly as you need it, and then they back that card up and they hand that out to all the other developers, that adds a point where things slow down because there's one or two developers in charge of that golden image, and every time you have an update, then you've got to get that pushed out to all your other developers. With a build system like Octo, that's baked in to the workflow that is part of the build system. A couple nice to have, it should allow for parallel processing in your build. That's pretty straightforward. But generally speaking, the amount of code going in to build any one of these embedded Linux systems is staggering. It's just you're building a lot of packages. It takes a lot of time. And if you're trying to do it without running a lot of things in parallel, you're going to start your build, go away for the weekend, and come back in a couple of weeks, and you'll be fine. But the more cores you can throw at it, the better. If you can throw more memory at it, even better. If you can go into a cloud-based infrastructure, you can always go to the very biggest AMI instances that are out there and run it there. So that'll get you speed in your build. I mentioned cross-building early on as a typical workflow. The tool chains when you're talking about cross-building tend to be a pretty big pain point. If you've ever tried to build a tool chain and get all the libraries and all the components you need at the right versions and get them built and staged together in the right bootstrapping order, you understand how complicated that would be. Fortunately, these days, there are a lot of choices where you can go get pre-built tool chains. All the build systems have their mechanism for building the tool chain. So that takes that pain away from you as a system developer. You don't have to worry about, OK, do I have the right versions? Are they going to play nice together? That's all integrated into the build system, and you don't have to spend any more time worrying about it. And finally, for some designs, license management is a very important consideration. Some design is not so much some, but in some cases, you want to make sure there's no GPLv3. You want to make sure there's no proprietary code, whatever. The Yachto build system has a very good mechanism for keeping track of the licenses, letting you exclude certain licenses, having it throw errors if you pulled something in that pulled in a dependency you weren't expecting that may have maybe pulled in something that's questionable from a licensing standpoint. So that's all part of the build system. So what isn't a build system? The build system is not an IDE. Generally speaking, Yachto, you're not going to be developing your application in Yachto. Typically, you're going to build a base binary that you're running on your system, and then you use some kind of out-of-band mechanism, whether it's an Eclipse-based system with a connection to your board, or you're just running Python code or whatever. But typically, your actual day-to-day back and forth of typical application development, you don't do as part of Yachto. Yachto then acts as a packaging step once you have the base code, and you're ready to actually release it to the next step in your development pipeline. It's also not a distribution. Yachto focuses on mechanism-not-policy. So they have sensible defaults so that you don't have to specify every little detail of your system to begin with. But if you want to change from, say, SystemD to Sysvianet or vice versa, that's easy to do. Whereas typically with things like Debian or Ubuntu, they tend to apply a lot more policy on top. And if it doesn't fit with your design, then you might be in for some pain to get that addressed if you're using a system like that. It's also not a deployment and provisioning tool. And what I mean by that is once you have the images out of Yachto, typically it's a separate step to then get the images from your build system to the device, whether it's writing it to the SD card or using some kind of USB system where the board is mounted as a OTG device and you're actually writing it as if it were a block device on your system, those are typically going to be outside of the scope of Yachto. Although in a lot of cases, in the platform, the BSP repositories you're looking at, they'll have instructions showing you how to do that. But like I say, it's typically a post-processing step. And finally, it's not an out-of-the-box solution. You're not going to go download Yachto, press run and have a system doing everything you want it to do. The whole point of something like Yachto is the configurability it gives you and the ability to pick and choose protocols, application, development environments, languages, everything you might need. You will have to do some customization and designing of your system through the Yachto workflows. So we've kind of talked around a lot of these things. The quote you see here at the top of the screen is not an embedded Linux distribution. It creates a custom one for you. That's a tagline directly from the Yachto projects website. And that kind of goes back to what I was saying just a minute ago. It focuses on mechanism not policy. There are, actually in Yachto, there is the concept of a distribution that you can specify as part of your configuration. So if you want the angstrom distribution, that is a packaging step in Yachto that brings together a number of policies and gives you a certain level of functionality. If you don't want that, you can specify others. So it gives you the ability to pick and choose at the very highest level of functionality in your system. What the Yachto project really is at its core is a collection of recipes, metadata, dependencies and configuration. So recipes in this case refer to what are the steps needed to build any given package. Configure, make, make, install is the most basic, but there's all sorts of packages that use many different build and deploy methodologies. So that's all encoded in the Yachto recipes. Metadata is just a general term that you set metadata for some of the selections you make in terms of the policies you want to implement for your design. You set, it's the data that goes into the build system that actually controls everything that the Yachto build is gonna be doing for you. The dependencies amongst these packages get very hairy. And if you had to track that manually, you would, again, not be very happy about it. Fortunately, Yachto, the recipes specify automatically the dependencies that they have. So when you build a particular package, it knows whether it needs the C library or if it needs Python or a particular Python library. And the build system of Yachto called BitBake pulls all that information together and is able to build a dependency graph and know exactly what needs to be built first, second, third, and it's able to actually scale that out to as much parallelism as you can throw at it and make sure that you're not running into issues where I'm ready to link something but I don't have the library to link it with. So all that dependency tracking and scheduling is handled by the BitBake package manager that's built into Yachto. And then just general configuration. You have configuration files at the BSP layer that specify the chip set, the architecture, the instruction set for your board, you specify what boot load or what version, things like that. So the configuration in Yachto is extremely detailed and gives you very fine-grained control over the way your system is built. The primary output of a Yachto build is a package feed. And this is essentially a directory on your build system that contains a whole boatload of .rpm files or .deb files or .ipk files depending on which packaging choice you have made. It also has the configuration to allow you to install those packages into an existing system if you so choose. So from that perspective, the output of your Yachto build can look much like a system, your desktop system where you can just run app, get update and get new packages. That's great at development time, you probably want to turn that off before you deploy the thing. The secondary output of your Yachto build is the actual boot images. Now, in practice, for the level of work I do, I don't deal with the package feeds all that much. I use it mostly to get those boot images. That's typically gonna be your root file system, your kernel, your bootloader and any other subsequent images you need to actually get a fully functioning system running with the output of your build. It's important to note that everything in Yachto is built from source, that is the methodology. Now there are some things like firmware binary blobs obviously that aren't really built from source but ultimately if it's possible for the Yachto system to build something from source, that is the preferred mechanism to do it. And I mentioned mechanism, not policy but I want to mention it again because that's a very key portion of a system like this. And then again, the main products that root file system image, kernel bootloader, the tool chain is there, which is nice because then you can hand the tool chain off to your application developers and they're able to actually cross compile their code. So the Yachto project is organized into, it's got a very regimented layering structure and this is how we get a lot of good functionality. The base layers have the minimum necessary to bring a system up and running. If you go to and check out the base Yachto layers, the only platforms that exist in those layers are there's I think the Beaglebone black and then a couple of emulated platforms. So typically your platform support is going to be handled in a separate layer. There's a lot of functionality at higher levels. There's graphic stacks, there's things like QT. We'll get into some of the IOT specific stuff in a couple of slides. But the idea is to separate that functionality out into logical blocks that you can pull together based on the specific needs of your system. So you're going to start with a platform or a machine BSP of some kind. You're bringing the Yachto base layers and then you might, if you need QT you'll bring in those layers. If you need some of the IOT specific protocols you'll be pulling those things in. It allows these systems to progress at their own rate. Some of them have less developers. They may not be doing point releases at the same pace that the Yachto project is doing. So it allows each of these individual layers to proceed at their own pace. Additionally there's an SDK mechanism. I mentioned that the tool chain is an output of the build. In addition to that you can actually package up libraries, header files and everything needed for application developers so that you can give them a separate package that they're able to use and your application developers will not need to get involved with the full Yachto system level builds. That makes things a lot easier for them. You can, as the system developer, I can have a policy of I publish a new SDK every week, every month, whatever's appropriate. My application developers know that then they can come in and get the very latest in their building against something that has been at least tested to some level by me and then they don't have to deal with all the details of understanding how to do Yachto project builds. Some of the optimizations that are built in, parallel builds, I mentioned that, that's very important. Yachto also has a mechanism called shared state and this is basically caching the intermediate steps of each of the packages that you're building. All the tasks that go into building a particular package, the intermediate product at each point can be packaged off as a shared state and reused. So that means if I'm building Busybox, the first time I build it, yeah, it's gonna build it from source and then it's gonna save off the original source, it's gonna save off the patched source, it's gonna save off the output of the configure step and the make step and the make install step. So the next time I come back and build, if the configuration has not changed such that it would affect any of those pieces of output, then it can just reuse that cache data that it's already saved. And that's a great time saver. If you have a continuous integration system, you take the shared state output from your nightly CI builds and you export that over just a web URI and then all your individual developers can point at that so that if they're using the same exact thing, it cuts down their development time quite a bit. So if you haven't looked into the shared state and specifically the shared state mirrors with your YAKTO development, I highly encourage you to do so it will save a lot of time. So in general, getting started with YAKTO, I think based on the number of folks that have already worked with YAKTO, this is probably old hat, but these four commands are enough to check out the basic system from the YAKTO project, get repository and then run a build for an emulated x86 platform and invoke it. You're not gonna do a whole lot with this. It will launch a terminal window as you see here, but this set of statements is a copy and paste way of getting something up and running if you're unfamiliar with it and you wanna kinda get a feel for the workflow. So the emulator integration into YAKTO is very good and it's useful for a lot of things. So again, that's something else you might wanna look at if you haven't spent much time looking at that before. So we can kinda step back and talk about why Linux were embedded. So a little bit of the higher level, I think most of this should be reviewed for all of us. Obviously, Linux is everywhere. There's a lot of available software out there on your Linux system. You can run just about every network protocol ever conceived. There's a lot of Linux expertise as can be gathered from the number of folks at this conference. Plenty of training materials, that kind of thing. So if you're having a hard time convincing your management, that's kinda what these slides are for. Broad device support, again, Linux probably supports more chipsets and things like that than just about any system out there. And it gives you a very common system architecture on both your build host and your target, which is very useful. It speeds up your developer's times. They don't have to spend a whole lot of time learning new systems. And it's open source. If that's important for your design, obviously that's just one thing to keep in mind. Industry support, there's a lot of industry trade groups and that kind of thing. There's Genevieve and AGL in the automotive space. Obviously, there's the Linux foundation and things like that. So there's just a lot of activity in the Linux space. And like I say, these slides are generally for those that have a hard time convincing their management that this is something they wanna contend with. But I suspect we can kinda get past most of that here. So, specifically about Yachto and IoT, I just wanted to go for a few minutes now and kinda talk a little bit more about that. Generally speaking, Yachto is very well supported by most of the semiconductor vendors and the board manufacturers. So chances are if you're looking at a board for an IoT design, chances are your vendor already has some level of support for a Yachto layer for that board. It does have a very well-defined workflow. Once you get into Yachto, it's very similar from system to system. So once you know it for one system, you know the basics for what you need to do when you're ready to move on to the next design. Because of the reproducibility of these builds and the fact that you're not dealing with a single golden image that one person has the right to update, it does support large developer teams very well. I can add things in my local configuration when I'm ready. I push them up to my get repose and the other developers on my team can then sync with that, pull it down, they do the build. Now they have a matching image on their system. So it works very well for that. It does, there is very easy access to IoT specific protocols, and I've got a few examples of that in a minute, but basically the layering mechanism that I mentioned makes it very easy for these things to be packaged up and stored and accessed in any given design. And it does have very good connectivity and coexistence with the RTOS's. In the IoT space, a lot of times we're dealing with multi-node systems. We might be dealing, we might have Linux on some of the nodes and we might be running free RTOS or Zephyr or something on a smaller MCU-based design. So it's good to know that there's a lot of collaboration in those communities and that these things work very well together. And another very critical, important update, the thing to mention is that the upstream Yachto project has a very regimented release cycle. They do keep up to date with any of the critical vulnerabilities that are out there. So if you're using a Yachto stable branch, you get a lot of that in your design you're able to pull from without having to do a whole lot of extra work. So you get to reuse a lot of the work that the folks at the Yachto project are doing to maintain the stable branches over the lifetime of your project. So I mentioned IoT-specific protocols. I assume some of these on this list, many of you are familiar with things like MQTT. There's a package in one of the Yachto layers called Python PAHO MQTT, which is just the Python implementation. It's very easy to use, very easy to add to your system. That's actually in one of the core open embedded layers. MQP is implemented by RabbitMQ. I don't believe that's one of the core Yachto layers, but there is a thing called the Yachto Layer Index that pulls all this information together. And then other things that are used, co-app, zero MQ, GPS, Bluetooth, obviously is pretty widely used in the IoT space. So all of these kind of protocols are very well supported in the Yachto project. And it's usually just a few minor steps to get those things pulled into your design and into your configuration. Networking, there's quite a few choices for network management, obviously, keeping track of Wi-Fi, SSIDs and passwords is kind of, can be tricky. SystemD networking is a component of SystemD that's built in, that's fairly easy to use. If you want something more full-featured, then there's things like Conman, which is used pretty extensively in the automotive space, and the network manager, which I know is a part of my Ubuntu desktop, so that those kinds of things are also available. You can switch between one or the other depending on your specific needs. And finally, moving up the stack to your application developers, Python and Node.js seem to be the most commonly used application frameworks for IoT designs, and they are very well supported. They have layers with the base language support as well as many supplemental libraries and that kind of thing. So it's very easy to get the libraries and languages supported that are needed for your application developers as well. And this is a screenshot from the Yachto layer index that I mentioned. You probably can't read it very well. The source at the bottom of the screen is actually the direct link to the layer index. And all I did here was search for the term IoT and you see there's quite a few layers here that contain components related to IoT. Another interesting search was cloud. I found a number of components for accessing some of the commercial cloud providers like Azure or AWS or Google Cloud or some of those. There's a lot of integration with those providers already built in to the Yachto layers. So it really does give you a leg up in getting your system design up and running very quickly. So just to kind of sum up why Yachto for IoT designs, it's very widely supported. Chances are any board semiconductor that you're looking at already has some level of support in the Yachto project, has a very active developer community keeping track of security updates and that kind of thing which isolates you from a lot of extra activities. The layering mechanism, I can't overstate how important that is in Yachto. That is one of the key core components of any Yachto project design. Making it extremely customizable, extremely enhanceable, very easy to configure for your particular use case. It does rely on minimum native tooling which makes it very easy to run on a wide variety of desktop PC operating systems. I generally use Ubuntu but it typically, if Yachto needs a particular package as part of the build time, it's gonna build it itself. So you know that it all works very well together and it's very easy to deploy to whatever distribution your developers may like. And finally, I do want to mention one more time the ability to predict the exact software contents. If you have a system in the field where the end user is able to install new packages, it makes it very difficult to know exactly what's on the device, know that you've tested every possible combination. If you use something like Yachto, it gives you a very good starting point to know exactly that what I'm testing in my lab is exactly what's going out to the end user. There's no, I don't have to worry that a distribution provider may have pushed an update that my end users end up pulling, that is not good. So that's a very important thing. Couple of downsides, it has a pretty steep learning curve. Those of you that have already gone through the learning curve probably are familiar with that. It is a pretty unfamiliar environment to non-embedded developers, especially in the IoT space. We see a lot more folks with the web and UI UX experience coming into the IoT space, wanting to learn how to design these systems. And the whole idea of cross building and things like that, that's very foreign to them. So that's definitely one of the downsides. And it's very resource intensive. These builds take a long time. They're gonna require a lot of disk space. When you're starting from scratch, you're looking at, depending on the configuration, anywhere from an hour to six to eight hours, depending on the strength and power of your machine and possibly multiple gigabytes of space. So this is not something you're gonna run in a Chromebook in a half hour while you're at lunch. So I would encourage you to keep that in mind. So with that, I got a couple resources here and we definitely have time for some questions, I believe. So the first link here was a talk I gave last year that goes in a bit more depth on this topic, comparing Yachto to other build systems and giving you a little bit more comparison there. The second link is actually the article that I wrote that led to this talk. So it goes into a little bit more depth about this specific topic. And the last link there is kind of a next step up from that getting started page that I had that will actually walk you through in less than a half a dozen copy and paste steps, getting started doing a build of Yachto for a Raspberry Pi 3 and in a self-serving fashion, it also happens to be running the Mender Updater. So at that point then you actually are able to update your device over the air. So I would encourage you to take a look at those links, ways to get in touch with me, obviously down at the bottom. I'd love to hear from you if you have any questions. We'll certainly take them now. And if you have any thoughts or anything you'd like to share afterwards, there's plenty of ways to get in touch with me. Of course, all the way in the back corner is the first question every time, isn't it? Thank you. What is your opinion to use Yachto on a real server? In what sense? To actually generate the code for your server? No, to use Yachto as a distribution for on a real hardware server. So DNS server, NFS server, FTP server, all that? I assume all those things are supported is not something I've ever looked at doing. But with the amount of functionality that's available in the various community layers, I'd be very surprised if that wasn't feasible. But it hasn't been my focus because my focus is generally on the embedded client side of things. Yeah, I missed the talk earlier about comparing Yachto to build route, but could you elaborate just the bullet points from that perhaps, or if you could tell me if that link answered that question? Well, that link definitely will answer that question. That was the talk I gave at ELC Portland. But at a high level, they both solve the same problem. So ultimately, they're both very similar at the very highest level. It's really in the details. One thing that build route doesn't do is it doesn't have the concept of a package feed. So build route itself produces the binary that you run on your target. But there's no concept of now I have a package for something that I can install later on. So that's one of the big differences. Build route is focused on simplicity. It has a lower learning curve, generally speaking, than Yachto. Out of the box, the build configurations are gonna have just about everything turned off. Whereas in Yachto, they have more defaults that are turned on. In build route, generally, you're gonna start with a much more minimal system and then have to build up from there. But it's really an Emacs versus VI discussion. They both have their pluses and minuses and they both have plenty of people using them in active communities. I would encourage you to check out both of them for sure. Thanks. All right, anybody else? All right, thank you very much. Let's all go home. All right.