 Hello and welcome to the session called Accelerating Prototype to Commercial Device with Snapdragon and Ubuntu Core. My name is Aksana Wilcox. I am the Manager of Product Planning for Qualcomm Technologies working on Qualcomm Snapdragon embedded processors. This presentation actually has three presenters. There's two colleagues of mine here from Canonical. I will transition to them after my section. They will talk more about the Ubuntu Core. We all know IoT industries, embedded computing industries, mass market, whatever the terms that you're most familiar with are all looking to create smart connected devices. And where do we best look for technologies that are already proven, have on parallel scale, have integrated capabilities, rapid development cycles other than mobile. So the smartphone technology is truly from digital signal processing, from the fast CPUs, from graphic processing units, integrated GPS, integrated connectivity from Wi-Fi to Bluetooth, optimized multimedia performances, power management, small memory size, and of course support for various operating systems other than in mobile space. Qualcomm Technologies obviously, as most of you know, is a semiconductor company that's been providing Snapdragon solutions to mobile OEMs and tablets for many, many years. So understanding the demands of the embedded computing industry, we wanted to capitalize on the investments that we've made in the mobile space and bring it to the computing and internet of things industries. Just a quick snapshot on what type of challenges we imagine there are in differences between mobile OEMs and embedded customers. And I won't go through every single thing on the list, but understanding that helps us select particular processors and understand what type of enablement that we need and would be required to bring this to the market. From the mobile OEMs and embedded customer's perspective, the relationships are very different from high-touch, one-on-one, dedicated FAEs and support to very low-touch and potentially web-only support from fulfilling directly to distribution, from requirement for minimum orders of millions of devices to tens of thousands, maybe hundreds of thousands, and dealing with sheer number of customers going from a handful of OEMs and OEMs to hundreds of thousands of customers that all in aggregate add up to a tremendous business opportunity for a company. So understanding all of that and all of those challenges allowed us to focus on selecting a particular Snapdragon embedded portfolio that we are now offering in mass market space that spans from low-end to mid-range to high-end devices, Snapdragon devices. From a lower-end, we introduced Snapdragon 410, which is an ARM A53, 32 and 63-bit capable device, 1.2 gigahertz per core, as well as Snapdragon 600, which is mid-tier from our perspective, 1.5 gigahertz per core, with Qualcomm proprietary CPU, quote, great. We introduced those devices most recently with what we call an E-SQ, which stands for extended life, that in our terminology means that these devices will be available through the year of 2025, which we believe is a key requirement for the embedded space. We're currently in the process of identifying a SKU for the premium tier, which at Qualcomm is called 800 series. Currently there are modules available based on Snapdragon 820, which is one of the premium tier devices. However, we're still working on the dedicated SKU that we'll put through the channel and make available to mass market, so please stay tuned, look on our site and they'll become available relatively soon. Again, kind of an eye-chart slide, you don't need to see this side-by-side and don't need me to speak to side-by-side in detail, but also tells you again about the breadth of portfolio that we are offering. If the types of devices that your end customers or you as an end customer look into launch don't require a lot of capacity, they don't require as high of a speed and potential performance of GPU, then you could select a device like 410, which has obvious benefits that include the cost factor as well. I won't speak to the cost specifically, but that's one of the reasons we have serious of low tier to mid tier devices. The Snapdragon 410 interesting factoid supports three different operating systems. Support Android, several distributions in Linux and Windows 10 IoT. We are currently working on adding that to 600, but it does support Linux and Android right now. Selecting processors and making them available in mass market through our partner. I've omitted to mention that on one of the first slides, our partner Aeroelectronics, which a lot of them probably have bought devices or electronics or parts from them. Selecting the devices and putting them through the channel was just the first challenge for us. Understanding what else is required, that the ecosystem that's required to actually enable your customer to not only take that device or take that board and prototype on it and actually launch it in the commercial product that customers would buy is a completely different story. The things that we understood and addressed were the need for community boards. We have, for each processor in the channel, we have developed a board called DragonBoard that's a Qualcomm trademark. We have a DragonBoard 410 C right now available. It's been launched for over years in a very successful development platform for software for us. We're working on developing and launching DragonBoard 600 C and then in the near future 820 C. So please stay tuned again. The best way to learn about what's coming is going to developer.qualcomm.com. It's our community site that if you sign up as a developer, then you'll get email information about the new products coming. So that solves for the hardware situation. And what do you do with the software? With the software, we work very closely with Linaro, 96boards.org, where Qualcomm is a member. As part of our membership, we have a dedicated team of engineers that helps develop on our platforms. So there are all three platforms that I just mentioned are currently being worked on to add additional features in Linux, Open Embedded and Linux Debian, as well as we have a group of folks who work with it, Canonical, that enable additional features through Ubuntu Core. I've mentioned Longevity. Again, all these chipsets come with a 10-year commitment from Qualcomm. We are continuing to work on making more and more publicly available documentation and tools, as well as I wanted to introduce the concept of what we call a Snapdragon technology partner. That is a group of companies that have early access to Qualcomm processors, a lot of expertise in working with Qualcomm source code, Qualcomm documentation and tools. They develop modules, whether it's SOMs or SBCs, a full on development kits based on Qualcomm processors. A lot of the time, way ahead of those processors becoming available in the marketplace, so customers could go to them, get access to those devices, prototype, by the time they make a decision that that is the right processor for them to actually do a chip down design or a custom module, they could come to Qualcomm or actually they could come to Air Electronics and buy the actual chip down discrete part at that point from Air Electronics. That just kind of gives you yet another view and a few names of customers like or partners like, again, Air Electronics, InfoChips, Enforced Computing, Intrinsic, VariSide, Canonical, even though you're all on the software side, but nonetheless you provide software integration services. So having taken care of the hardware, the documentation, the tools, the hardware partners, obviously software is key. We'll look at that from enabling the various high-level operating system support, middleware and integrating cloud providers. Currently, Snapdragon processors and of course the boards that have the processors in them, as I mentioned, support the three key operating systems, Android. For Linux, we support Debian, Open Embedded and Ubuntu Core distributions and then Windows 10 IoT Core. We have integrated with all join, IBM Watson IoT Platform and we have Robotics OS running on 410 and 600. For cloud partners, we'll partner with AT&T, AWS IoT, you could actually, if you go on Amazon, you could buy DragonBoard 410C AWS Kit that is integrated with their APIs in Brunslin, Exdebian. We have a recipe for IBM Bluemix, it's available either on Bluemix or on arrow.com and we are partners with Microsoft Azure. So hopefully rounding up a software ecosystem solution to get the developers what they need and have flexible options for them. Really quickly, I'll touch on the community board and I'll pass on to my colleagues, Kyle and Lowry here from Canonical to talk about the work that they're doing with Snapdragon and DragonBoard. Dragon 410C is a commercial product. It's a product by Aero-designed and initially designed by Qualcomm. Truly a prototyping platform for software development and also for prototype of actual commercial devices. If any of your customers or yourselves wanted to buy it, you go to Aero, you buy the product, you get a particular FE assigned to your organization to work with you to see if this is the right product for you, potentially modules, potentially actual chip down design for your product. But this is a great way to get experience with Snapdragon processors. We are very committed to open source distributions and upstreaming. For that reason, we're very involved with the NARO Foundation as well as 96 boards. So all the DragonBoards that we make to give access to Qualcomm processors, early stage Qualcomm, early stage access to existing Qualcomm processors, they're all 96 boards compliant. Which means that compliant to 96 board CE, open hardware specification. And the great thing about that, that any mezzanine board, any accessory that's built to that specification by other vendors, be it C, the linker or groove or anyone, they will work with our boards. As well as they will work with any other board that 96 boards is selling, just to not to undersell them. And that pretty much wraps up my portion, unless I think we'll probably take questions if we need to at the end. But at this point, I'd like to introduce Kyle Fazari and Lowry Snow from, actually, yes, from Canonical. I thank you guys. I'm really gonna let Kyle spend most of the time talking about how a developer or a company designing a device would choose to select components that would accelerate the time to market. But I wanted to highlight something very important. Because of the work that we've been doing with Qualcomm, and with Lenaro, Qualcomm and Canonical, along with some of the hardware partners that Qualcomm's working with, we have a unique value proposition for a device manufacturer or for a developer that's selecting which parts to build with to take a device to market. Fortunately for developers in the embedded space today, more than ever before with words like IoT and Internet of everything, there's a grand focus on providing tools and modules that allow a device manufacturer to quickly build something that can go from prototype to market very quickly. So the value prop for building with Snapdragon and Ubuntu Core is unlike what you might see with other hardware vendors and software distros. We provide an Ubuntu OS image that is a reference image that's supported for a five-year period of time with security maintenance updates, which is an LTS release. And that's because of the work that we've done with the Lenaro group and with Qualcomm. Along with that, that OS that can be used to take a device to market without any additional formal agreement with Canonical, we have an entire infrastructure and distribution mechanism that allows you to upload an app and have your app available on your device with over-the-air updates for free. We're offering that entire app delivery and update mechanism for any developer and device manufacturer. And that's the message that you get when you take a hardware reference design from Qualcomm and then this reference OS image that goes along with that. Most companies opt to do that work on their own. Most developers opt to do that work on their own. Oksana mentioned the software integration service that we provide. Along with this reference image that can be adapted for your use, we do offer consulting services and engineering services to further enable your device for market. I'm going to pass on now to Kyle, who's going to talk very specifically about something that was done to take a device to market and how easy it would be to build off of this concept to very quickly build a prototype and then take that prototype to market. So software engineer Kyle Fazzari. Hi everyone. My name is Kyle Fazzari and as Larry mentioned, I am very proudly a grunt software engineer. I work on this. Well, specifically I work on the packages called Snapcraft. I'll talk about that in a minute. But as Larry mentioned, what I want to talk about is how easy it is to go from a prototype you have to an image you can flash in the factory and ship using Ubuntu Core. And to do that, I'm going to give you a quick overview of what Ubuntu Core exactly is and then walk you through an example that is something you could actually buy today. So let's get started. So I'm going to cover each of these points. These aren't the right slides. Hold on, sorry. There we go. So I'll cover each of these in detail. But what is Ubuntu Core? Well, as you probably know, Ubuntu is based on Debian. Ubuntu Core is a distribution of Ubuntu that uses a different packaging format called Snaps, which gives it a couple of interesting properties. First of all, it gives it transactional updates, which means it's updated atomically. And if you lose power or the update goes bad, then you can roll back to a previous version. Snaps have confinement built into them. So you get confinement. That's a pretty easy story for additional security. The developer experience to actually create Snaps is really well thought through. Like I said, this is what I work on here. This is where I'm focused with a tool called Snapcraft. And then as Larry mentioned, there's the store that you get for free where you push an update and all your devices automatically get that update. And finally, there's the fact that Ubuntu Core nicely plugs into the trusted cadence that Ubuntu has long established. So let me go through each of these points. First of all, what are Snaps? At its most basic level, a Snap is simply a squash FS image with some metadata in it. Now that metadata, the spec for it, what makes this squash FSA Snap is determined by a governing body from a bunch of different distributions here. So we try to keep it as neutral as possible, which means that Snaps run on a number of different distributions, including regular old Ubuntu desktop and server, Debian Arch, among others. And then because of the store, it allows you to deliver your updates directly instead of having to go through the various package management mechanisms that all of those distros use. Now, another property of the fact that these are squash FS images is that they also bundle all their dependencies, which makes them this immutable blob that is your software, which gives us an interesting architecture here. So I want to compare and contrast classic Ubuntu here on the left, which is Deb-based with Ubuntu Core on the right. Now, Debs can include anything and put files anywhere, and they run hooks as root. They share libraries, right? You can easily get into this dependency hell that I'm sure many of you are familiar with. And there are security issues with being able to, when you install a Deb, it owns your system. It can do anything at once, right? Its hooks run as root. With Ubuntu Core, it's restructured a bit into these Snaps, where the kernel is a kernel snap. The OS part is a core snap, and then you have applications on top of that. It's a little less flexible, but it's really nice for IoT devices. So I've talked about the fact that the snaps are squash FS images, which by definition means they are read only. Applications are limited if they can't write data. So there are some specific areas where the snap is allowed to write, because of confinement, which I'll talk about in a second. But the point is where the snap is putting data is a known place, which gives us this nice property where you have a snap and you have its associated data that's tied to its revision. So when an update comes along, let's say the data that it's holding is a database. When an update comes along, the first thing it does is run some migration on that database. Let's say that migration goes bad. This database is now corrupted. Thankfully, as part of the update process, the original snap and the original data that was associated with that revision is kept. Let's see. Three are kept in total. Two old ones and a current one, which means if a failure occurs, then it can just roll back to the previous version and you're back up and running right before the upgrade, actually. So let's talk about confinement. There are a couple of different confinement technologies at play here. One is App Armor. The other one is Setcomp filters. And some other ones, too, but those are really the main ones, where snaps are limited in where they can write and their system-related capabilities. And the way that's split out is by something that we call interfaces. So you make your snap and you know, OK, I need to be able to talk to the internet. So in your snap metadata, you specify this snap needs the network interface. And that's some syscalls that are whitelisted for you and some App Armor access granted. And what that does, if you were in any of the security related talks earlier, you know that security is not perfect, right? Nothing's going to be perfect. But this isolates the damage attacker can do if they manage to break in, right? The only thing that's going to happen if they break into this one is that they gain that. They don't gain any of that. So let's talk about Snapcraft for a little bit. Since, as I mentioned, snaps bundle their dependencies, you end up having a lot of disparate pieces that make up this snap, each of which have their own build system, build technology, et cetera. Snapcraft is the tool that takes all of those disparate pieces and puts them into one cohesive unit called this snap. It can reuse dev packages. So if your component requires boost, you don't actually need to build boost from source. You can just say, hey, pull boost from the archives and stage that into the snap. And the way it supports all of these various build technologies is by a plug-in system, which new ones are being written all the time. And you can actually distribute your own in the source with the Snapcraft. It's all specified by YAML, the Snapcraft YAML, if you have sort of an interesting build process that you need to use. Tons of plug-ins are already out there in upstream Snapcraft. These are a couple of the examples. Oh, and snapcraft.io, if you're interested in learning more about this, how to make a snap, that's your starting point, snapcraft.io. Another thing I mentioned was the store. One of the biggest problems with IoT devices that are already out there is that they rely on the user to update, or they have no update mechanism whatsoever. This store, the whole Snap store, is already included in it. And so if you make an image that is based on Snaps and you ship it, if you push an updated Snap to the store, all these devices are already going to automatically update, just as a side effect of using Ubuntu Core. Now, in addition to that, there are some opportunities for new revenue, if you're interested in this. So if you've got Snaps on your device, there is another Snap that you can install called Snap Web. So let's say I buy a router that is Snap-based, and it comes maybe with Snap Web pre-installed. I can actually visit it and install new Snaps just by using that interface, which means you can sell add-ons that your users can install this way. And finally, the cadence, which many of you will be familiar with here. You've got Ubuntu 14.04 supported for five years. That's an LTS. You've got the three development releases between it and 16.04, which is an LTS. Then three more releases in 18.04, which will be an LTS. Ubuntu Core fits in on these LTS lines, starting with 16. And it's supported for five years, and then 18 for five years, just like Lowry mentioned. So that's sort of the high level overview. I actually want to walk you through some lower level details of how you might actually go from a prototype to production. And to do that, I'm going to use the next cloud box. Now, this is something you can actually buy today. I've got one with me. And it's based on Ubuntu Core. So I'm going to use this as the enabler to talk about, OK, well, this was, as you viewers will look, based on a Raspberry Pi 2. What if I wanted to make a new one based on a Dragon board? It's really easy. So let's pretend that your prototype is this next cloud snap. Every Ubuntu Core image is made up of at least three snaps. This gadget snap on the bottom, kernel snap, which sits on top of that, if you will, the core snap, and then whatever application snaps you put on top. And I want to talk through each one of those in a little more detail. So let's start with this gadget snap. So I'm remaking this device, but now it's based on a Dragon board. The gadget snap is what holds your bootloader. Any file system layout that you specify, some default configurations for services that are on there. And like Lowry was mentioning, the Dragon board is our ARM64 reference board, which means if you're using a Dragon board, this is already made for you. You don't need to worry about it. It's already provided and maintained. You can make your own if you want to, but you don't have to. The kernel snap, this one's pretty obvious. It's a 4.4 base kernel with the device drivers, et cetera. And again, since this is a reference device, this is something that's already provided as part of this LPS. So if you're using the Dragon board, you can use this default kernel, and you don't need to worry about any updates whatsoever. The core snap, this is the execution environment. This is a nice, thin OS, if you will, for application snaps. It includes the init system, basic services, basic files and libraries. So not all snaps actually bundle libc. They can use the one that's in the core snap. And again, if you're using a Dragon board, you don't need to worry about making this. It's already provided and maintained. Again, you can make your own if you want. Now, this is where you really come in, right? So Next Cloud is our example here. You use Snapcraft to create this application snap, right? What makes your device unique? So for an example of Next Cloud, I talked about how they bundle their dependencies and these disparate build systems, right? So Next Cloud bundles Apache, MySQL, PHP, Redis, a number of things that makes a web application, and that's it's snap. So if you put all these together, you end up with something that is nicely flashable to a board in factory production. But how do we get there? And I'm actually going to take you through that. And I'm actually going to go down to the CLI here. So don't worry. I won't type. I got them here. But there are a couple of things you need to do this. So every image, like I mentioned, is made of a kernel, or, excuse me, gadget kernel in core snap. And then whatever you want to add on top, so in our case, that's Next Cloud. And then the two extra pieces you need are a store account. I'll talk about that in a second. And Ubuntu Image, which is the tool to actually create a flashable image. So the first thing you do is create the store account. And the reason we do this is because Ubuntu Core is going to verify the image it's booting actually comes from you. In order for that to happen, you have to create a key and register it to your accounts so that it has something to figure out. So if you go to myapps.developer.ubuntu.com, create your free account, record your account ID. You're going to need that in a second. Now these slides, can we put them somewhere so that people can actually refer to that later? I assume? Yeah, OK, OK. Very good, very good. So the next step is to actually install Ubuntu Image and the related tools to make the image that you're going to flash. So snapcraft and snapd, those are needed to generate, register, and actually use the signing key. And the Ubuntu Image, as I mentioned, is the one that actually puts the image together. Now you're going to create a key. So in order to build the image, like I said, you need to be able to assert that this is your image with your key. So snapd has something to verify. So you use snapcraft create key to actually generate key. This is just GPG behind the scenes. There's nothing magic. And then you check that everything goes OK. Snapcraft list keys, make sure your key is listed there. And then finally, register it with your account. So snapcraft register key, by this time, let's see, I believe it will actually ask for your login info, snapcraft register key that is associated with your account. And then it registers it. And then at that point, you can use it to actually sign assertions. What is an assertion? I'll talk about that in a second. So we're going to create what defines our model. And in this case, our model is the device that we're going to ship. So what is the software that makes up this device? So it's JSON file. And it answers some pretty basic questions, like what's your model's name? And in my case, I just said Next Cloud Dragon. Which Ubuntu core series are you targeting? So there are only two, right? Well, there's snappy 15, but I wouldn't recommend it. It's based on some older stuff. So either 16 or 18. 18 isn't really out yet, so I wouldn't recommend that. So we're talking about 16 here. What architecture is this for? Well, this is the Dragonboard, so ARM64. What gadget snap is being used? So the one that Canonical provides is called Dragonboard. So I just used that here. If you were using your own, you would just specify a file path. Same with the kernel snap, Dragonboard Linux. That's the one from Canonical. Again, you could specify a file path here. Who's defining this model? So this authority ID, brand ID. These two fields is where your store account ID comes in, that thing that you recorded earlier. You paste that in here. And then when was this model defined? Just you get that from the date command, and then you can put it in there. And finally, that was all sort of boilerplate stuff. This is the interesting part. What extra snaps are included in this image? How is this different than just the, well, basically, if you erase required snaps here and put Canonical's authority and brand ID, you end up with the image that you could download from Ubuntu.com for the Dragonboard. The required snaps is really the interesting part where you customize it. Or you can replace the gadget kernel, et cetera. All right, so now this is where we turn the model definition into a model assertion by signing it. What you simply cat it out to snap sign. You see, you use the My Key name here and redirect it to dragon.model. It'll sign it, and then you end up with your dragon.model assertion. And if you actually look at it, it contains the exact same information as the JSON file plus the signature. And that's the file that we really needed to just hand it to Ubuntu Image so they can put the thing together. So you simply run sudo ubuntu image. The hyphen c option gives it the ability to pull snaps from different channels. I haven't really talked about that, but really quickly, every snap has a number of channels that it can be released in. The most unstable being edge, and then beta, candidate, and then stable. So that gives you the ability to roll out your software in stages instead of just immediately releasing a stable all the time. So in this case, I want every snap that is part of this image coming from the stable channel. So I give it there, a hyphen o, giving it the output image file. And finally, the model assertion that I want it to use to make this image. That's all it needs after a few minutes. You'll end up with the Dragon image. It's gonna pull down the core snap, the kernel snap, and the gadget snap that you specified, along with any extra applications that you requested, and actually put it into a flashable image. At that point, you can just flash it to an SD card, put it in the Dragon board and boot. So you can see that, hopefully, you can see that this is something that once you have this image, you hand it off to the factory and you can start rolling right away. So it's really pretty simple. Once you have your board, like the Dragon board, you develop your application snaps in a cool box, and that's about it. You can ship an image to your factory and start rolling on production. So if you're interested in this, there are a couple of ways to get involved with the community. If you need some help or have some questions. The first one is that snapcraft.io website that has general snapcraft documentation and walkthroughs tutorials. Tutorials.abuntu.com has some more snapcrafted Ubuntu core tutorials in a code labs format. It's actually pretty cool. It's relatively new. Good friend of mine put that together. And if the tutorials and documentation don't answer your question, ask one on askabuntu.com. There are a couple of tags there that many of us are subscribed to, the snap and ubuntu core tags in particular. And finally, we have a couple of different real-time chats that you're always welcome to join. The snappy room on FreeNode and a rocket chat instance, rocket.ubuntu.com, the snapcraft channel in there. I'm Kyrofa, if anyone wants to ping me directly. And that's all I have. So if anyone has any questions, yeah, either for me or for my colleagues here, please. The core snap you're talking about? Yes, that's correct. That's essentially a root of fs. It's... What kind of stuff is it? Like awk, right? Or libc, some really basic tools that various snaps will need to use so they don't have to bundle them themselves. Yes, yes, that's exactly what it is, yes. Please. Can you give us an idea of the size? If you're talking about... I don't know the exact sizes, but I know the minimum specs if that would answer your question. So the numbers that we have are 800 megahertz, 512 megs of storage, and a gig of RAM. And you don't actually need a gig, but if you add many applications, you probably will. That's where interfaces come in. So the diagram I had earlier, where they're each walled off, that's with complete confinement, right? But yeah, if you need to talk to the network, right, then you open a little hole in that sandbox with the network interface. There's actually an interface called content that allows two snaps to share content with each other. But that's limited to that single connection, right? Or you need a webcam, right? There's a camera interface to allow access to camera devices, that type of thing. So that's how snaps can communicate and cooperate. Actually, there is a Docker snap, yeah. So they can build on top of each other like that. As of right now, it doesn't work the other way around, but we're working on it. Please. Well, okay, so there are a couple of things here. And Larry will... So there is the base store, right? Which is accessible to everybody. When you push up a snap, you have a couple of options. You can keep it private, and thus install it all on the devices you have there, right? Or you can publish it for anyone to use if you want. But beyond that, there's also the idea of a branded store, which is something I'm not super up to speed on. So that's something... The fun line is, you snap on another device, you probably want to mark that snap right there. And then what you can do is write what's called assertions, that would then check which snaps can be installed. And because of the signing of the place in the factory, you would limit it to exactly which snaps you can be installed on that device. Or your device can connect to your own private store, and then you can make any snaps in that store to your device. Which is something that's awesome. So does Canonical make the store application, is that available as something that can be audited, or is the source available? Correct, it is open source, and there are instances already out there of people that have customers that on their own. They really want to go down that path and maintain an app store on their own. Most, I mean it kind of tends to most, the device manufacturers use universal store and upload their own private snaps to that store. Some, like a game provider that wants to invite third party developers to develop snaps for the device, they would create their own store and then limit which developers they might participate in their store. But it is open source, and you can take advantage of that and build your own app store from that. There's a pretty good YouTube video on that. So I'm searching. Sorry, another question back here? One more time, I'm sorry. Do you manage that? Oh. Okay, so the way this works is, let's say you did follow what I just walked through and you just added applications on top, right? Every snap is updated, so it's not one big image that you get all updates in, right? Every snap is updated on its own. But then, yeah, the gadget snap, core snap and kernel snap are things that we maintain. And then the store takes care of the updates. Your device would be built from the OS snap and the kernel snap, and the commitment is that we're maintaining those things with security maintenance updates for a five-year period, calling our LTS schedule. So those are getting updated as often as we deploy security updates. Usually every three weeks or so. So you get all that for free. Then, if you were to have your own snap at the store, it would get twisted devices off as you update your snap. So the only thing that you would have to maintain is your app's snap. And the rest would be maintained by canonicals that permit you to use the snap. So there would be no cost for that, unlike with the resin I know where they charge the current device. So you're managing the role of any updates of the devices that we do. Correct. That OTA infrastructure is available with the Emutant Core app. That's part of the store integration with snap, etc. I think that's less of management. It's more your device that has a build on it is querying the store to look for kernel updates, OS updates, and then app updates. When it seems that there's an update available, it will hold you updated. So it's a lot different than the resin I know of where they're charging. You say, they say, give us your Git and then we'll manage the deployment at a per device cost. There's no cost to take advantage of this platform. Any other questions? Oh, yeah. So you mentioned there were different channels for Edge and we don't have to do that. So each channel, if you push an update to each channel, if you have it stored that snap on it. Then it will update from that channel. Yes. From that channel. Yep, that's correct. And then a typical CI process was just, it would be to publish your dailies to Edge, right? And then you can, as you test them, you can promote them into more stable channels, etc. Yes, yeah, you can. Oh, yeah. From, boy, good question. From the snap web thing I was talking about. I'm not sure. That's a good question. I am not sure. I would assume so, but I've not tried. I typically do it from the CLI. So the way it works is, if that was the case, then you would effectively DDoS the store, right? So the way it actually works is every device, we'll check for updates four times a day, staggered. So it's randomly spaced. So no, it won't be like that. It will be at some point in the next couple of hours. Does that make sense? Yeah. Not at the moment, but I think the way that I would suggest doing that is by using channels. But I think they're planning on doing something like that store side at some point. Yeah, so the device is set. And the channel story is being fleshed out even further with the ability to create your own. So right now, we're working on some LTS channels and then the select version specific channels. And then you can actually, what I'm really waiting for is the ability to create one in CI. So every pull request can have a channel that's just created once so that people can test it. So we're working on that as well. Any other questions? Well, we're all around for at least the rest of the day, maybe a little bit tomorrow as well. So please catch us if you have any more questions. Oh, yes, thank you. Thank you very much.