 Hi, this is Robert Wolfe. We're here live at Lenaro Connect in Budapest right now. I'm here with Ogre from Canonical, and we're going to talk to you a little bit about the Ubuntu Core and how it's been working out on 96 boards platforms. So Ogre, yes. Yes, I know you've been working a lot with Ubuntu Core and in particular the Dragonboard 410c. In fact, we spoke recently on open hours, I think a week ago or two weeks ago. I wanted to ask you here with Charbackx, how has your work progressed and what kind of stuff are you actually doing with Ubuntu Core and the Dragonboard? Well, currently I'm focusing on getting all the interfaces on Ubuntu's snappy app, on Ubuntu Core app. If you know how snappy, you don't know how snappy works, I guess, at least you out there. So snappy is a system that, if you build an image, it consists of three parts. One is the root file system, which is the core SNAP, which gives Ubuntu Core the name. Then you have a kernel, which comes from the vendor and needs certain bits inside the kernel for security, like Seccomp and AppArmor to make sure the SNAPs run in their secure confined space. And then you have a gadget SNAP, which is the bootloader and the definition of the board. And in that gadget SNAP, you actually tell the SNAP packages what hardware is available in the board, and you make that hardware available. SNAPs use a thing called interfaces. So if you want to access a dev or GPIO1 on your board from a SNAP package, then the board needs to provide this interface unless, if this is not available, your SNAP can't do anything on that board with that device. So currently I'm working on bringing all these interfaces to the DragonBord to actually make sure if you build an IoT SNAP, it can control your solar system temperature sensors through the hardware on the board without being blocked by the security mechanisms that SNAP gives you. Beyond that, I'm working on getting our graphical bit called MIR up on the DragonBord. You currently can already run kiosk apps where a single app runs full screen on the board for presentation for digital signage. I have a Kodi SNAP, a very experimental one, where you can actually stream your TV stuff on the DragonBord already. That will be available within the next weeks or month. Great, yeah, no, so I know just recently, like I said, you were on open hours and everything. If you wanted to search for that, you can go to 96boards.org and look for the open hours, 96boards.org slash open hours. But is there a website that you might be able to tell the folks out there to go read more about Ubuntu Core on your end at Canonical? Oh yes, definitely. There is snapcraft.io where you can learn how to build a SNAP. SNAPs work in a way that they are, if you work on the application side, they are actually not very platform dependent. So you can actually use SNAPs on every Ubuntu install out there today if you use an LTS system. And you can develop your SNAP on your PC and then just port it over later to your hardware. In one of the 96boards open hours, I explain how to actually get a built environment on your DragonBord app to actually have a classic Ubuntu system. This is a DragonBord if you haven't seen it. It's a beautiful thing. Yeah, the best way to find that episode that he's talking about is you go to YouTube, you can search for 96boards. There's a playlist called Open Hours and it's episode 42. That's Ogre on that episode basically breaking down SNAPi. May I ask, so the SNAP and Ubuntu Core, when did that start, the idea? We started in the end of 2014. Actually in the middle or at the end of 2015 you could start buying Dell IoT gateways with SNAPi pre-installed with the early 1504 version. These devices are now all upgraded to the 16 version which is the one that will stay around at least until 2018 where we will move on with the 18 version. It evolved from the initial Ubuntu phone initiative where we found a lot of drawbacks using Debian packages and using the old setup that we had. If you want to use a phone, you want certain security mechanisms kicked in. You don't want your application to actually access all the hardware at the same time and track the user as the developer wants to. So we developed the click package former back then and we found, yeah, that brings us all the security we want but it's really awkward to maintain and we need to improve certain bits of it and we looked into actually finding the next generation packaging mechanism over depths and RPMs and whatever is out there at the table. There SNAP evolved out of nowhere and a SNAP is actually just a squash of his file system. It's a compressed file system so your application goes very, very small and it doesn't get unpacked, it gets just mounted on your device. You will never take more space than the actual SNAP file system takes in the compressed format. It hooks into kernel mechanisms as I said before, like AppArmor and Seccomp. So your kernel watches that the applications and binaries in there can't access more than the system allows them. So you can't just access the network without having the network interface enabled on the SNAP. But that gives you a certain amount of security where we offer interfaces that are auto-connecting so like a server should always be network aware and should be able to provide something on the network while if you want to access GPS you probably don't want that to auto-connect on something like a phone so users can't be tracked all the time and you want to pop up something for the user that tells him this application actually wants to track you so the user can then accept or deny that. So these mechanisms in the kernel are used in SNAPs as well. You can use them on IoT as well and you can use them on servers as well. So yeah, that's mainly the core of a SNAP system to actually make sure that you provide the biggest security mechanism ever and your webcam can't be hooked up to some botnet or anything from the outside. Well, I know that we're going to be talking with you later in the week on Thursday in open hours. We'll have you on the panel, either you or Jamie. Someone from Canonical will be there. So get some questions answered Thursday. I think it's 3 p.m. Budapest time. You even stream live, right? We'll be streaming it live. How many episodes do you have so far? This is going to be the 43rd episode, Erin. We have 42 now. That was the last episode we had with Ogre episode 42. 43 will be live here in Budapest. So how is SNAP and Ubuntu Core related to, let's say, a full Ubuntu that you run on a laptop, for example? Well, as I said, every Ubuntu install, if you use the LTS versions or from 14.04 on, has SNAP support. So you can actually install SNAP packages. There is a Chrome SNAP, for example, or certain desktop apps that are available as SNAPs, as well as a lot of IoT stuff. If you look around, if you have an Ubuntu desktop install, you can just run SNAP Find in the terminal, or you cannot search in the graphical software center because SNAPs just hook in there transparently. So you won't see that it's a SNAP. But there's a lot of applications in the software center as well that are SNAPs that will just transparently install behind the scenes as a SNAP if you click them in the software center. My experience with Ubuntu Core SNAP so far has been very fun. It's very intuitive. It kind of feels like you're working in a terminal-based tablet, almost. I mean, it's basically you're just running your commands. You're downloading what you would call SNAPs, but they're like applications and it just works. It's really nice. And the Ubuntu Core is just a light, very small version of Ubuntu? Right. The Ubuntu Core images that are available for ARM HF, ARM64 and AMD64 as well as i386, but I don't know if there's still much hardware to be playing i386. They are a very, very shrunk-down system. The root file system is actually only 60 megabytes big. If you run it, it eats around 100 megabytes of RAM, a little less, on the Dragonboard. If you run it as a 32-bit version, on the Dragonboard we actually run the 64-bit version, even though you could run the 32-bit version on that hardware. Again. If you run it in 32-bit, you get some advantages, like smaller memory footprint, simply because you use a lot smaller registers than the 64-bit version does. So I think on the 32-bit version we are like in the 40 to 60 meg RAM usage. If you just have it idling on your board, and yeah, well, it depends how big your kernel is, but usually you can get it under 150 megs of disk space. How much more optimization can you do, and what kind of optimization, what kind of work are you doing with Linaro around here? What am I doing with Linaro? When it comes to all this Ubuntu Core and Snap and all that stuff. Well, Canonical works with Linaro since a very, very long time. Our whole ARM compiler stack is coming from Linaro in a joint effort between Matthias Klose, who is actually the GCC maintainer in Debian and Ubuntu, and the Linaro guys, where the whole tool chain is optimized for ARM over years and years. So there Linaro comes in. Well, we've been working very closely together since day one. I know Linaro... Five years ago there was an event here. There was a joint UDS and Linaro Connect event, and I've been working with Linaro before Linaro was having a name, actually. There was a UDS event in Brussels, where Linaro was founded, where people ran around in very secret meetings all the time, and, oh, you can't talk about that, and they don't have a name yet. Do you have an idea for a name? That evolved into Linaro back then later, and there we... I remember we started with doing the first ARM server sessions at that UDS, and everybody said, you guys got crazy, ARM on servers, you can't do that. And I think System76 actually announced its first big ARM64 server last week or two weeks ago. And in terms of Ubuntu Core and Snap, I was at Mobile World Congress, there was a whole bunch of demos there. Like, is it really taking off? Like, lots of industry people are using this? Yeah, yeah, yeah. Because people get the security bits there. They understand, even after having millions of webcams suddenly sitting in a botnet, people actually get how important security is for IoT and for all the upcoming mobile gateway bits. Well, Ubuntu Core is surely too big to run on a sensor. You really don't want to run a fully-fledged Linux on a... So it's not for Core? Yeah, on a sensor node. But you want to run your gateways somehow. And these gateways connect to a cloud or these gateways collect information from these sensors. And there you need secure protocols. You need securely running apps. You need to collect the data and pre-process it for the cloud, perhaps. And all that stuff. That's where Ubuntu Core comes in. Yes, many, many companies are very interested in using Ubuntu Core in that area. So you're definitely taking care of security? Yes, yes. That's one of the main focuses of Ubuntu Core or even of Snap packages. If you look at the DAP, then security is a matter of trust. A DAP always has full root access to your system. That means you are trusting the archive and you are trusting the developer uploading to the archive with full root access to your system. If I'm uploading a package to the Ubuntu or Dabian archive, I can put a script in that just collects all your passwords or whatever because the Dabian package management system has full root access on the OS. In Snappy, you can put these scripts in there, but they are executed in an environment where they can't really access anything unless you allow them to. So while the snaps are installed as root, they don't have any hooks or anything that can run at install time. They only have the ability to execute stuff as root once they run. And if you then run as root, you are running in the confinement. It's not a container. People keep saying it's a container OS. It's not. It is running in context of your full root file system without rooting, without running anything out of context. It sees the whole system, but access to bits of the system is completely restricted. Even when you first set up your Ubuntu Core, at least on the Dragonboard 4.10.C. I haven't done anything else, just getting it linked with your single sign-on on Ubuntu. You go through a lot of measures. Maybe you could talk to a little bit about that, setting up the security measures that you have in place for putting it on your board. Right, so initially you don't really have... We used to start out in Ubuntu with little images back then where we had an Ubuntu user with an Ubuntu password. And this user had full pseudo access. That's definitely not what you want out there in a while. So nowadays you have a security measure that uses Ubuntu single sign-on to actually hook you up to the LaunchpadNet single sign-on service to then give you access through your SSH key that you put on that single sign-on service on the server. So you first have to create a single sign-on account there, put your SSH key in place, and then when you initially set it up, you have to give it credentials for the single sign-on. And you have to set up the network. That's the two steps you have to do when you initially install on the Dragon board and boot up for the first time. It asks you for a wireless setup and it asks you for a user setup to actually gain access to the board. And this user will then be able to access the board through SSH, and only this user and only with that key. So you don't even have password login enabled at all on the board, not even on console. If you need that, you can indeed set a password for the user after first time signing in through SSH. But you have to go in through SSH for the very first step to actually do that. And so how does it compare to, say, with Android or something else? Is this more friendly for mass production IoT devices? It compares to Android in a way that every board uses the same root file system. Like my Raspberry Pi images use the same root file system as his 96-board Dragon board images. So when I upgrade the root file system on the server, it rolls out to everybody at the same time. There is no... This application only runs on my Galaxy S6 and on the HTC whatever, but this application that I write and maintain will run on all these boards out there all the time. And this application will be immediately rolled out when I have a security fix uploaded to the application server, to the package server, however you want to call it. We call it store. So if something goes into the snappy store, it rolls out immediately to all the devices, which means security fixes come out at the minute. And it's very small updates. It's quick updates. It's very small updates. We recently started using Xdata 3 for the SquashFS updates, so you only get the changed bytes in the SquashFS delivered through the network. So it's the most efficient way to do IoT in the future. Yes, yes. I know you just mentioned the store, right? So this was something I found very interesting. You can build snaps and you can either offer them for free on the store or you can sell them, right? So people can actually profit from building snaps. Right. And building a snap? I don't know. Have you built snaps? I have not built one yet. You have to. I know, yes. We have a brilliant team that works on a tool called Snapcraft. And it's such a beautiful thing, because you can just take any tree, any source tree from GitHub, or anywhere. I personally still prefer Bazaar. I don't know why, but it feels so much more natural than Git. But if you just take any tree and craft a little file called snapcraft.yaml, you can immediately build a snap out of your project. It's super, super simple. You don't really have to learn Debian packaging. You don't really have to learn RPM packaging. You just build this or snapcraft.yaml file, tell it what dependencies it needs when building and how the applications should be called in your final snap. And then you call Snapcraft. And that's it. Out comes a Snap file. It's free service. It's free bandwidth. It's free everything. Oh, that's all on your desktop currently or on your server. Wherever you run Snapcraft, it just builds there. You can, with Snapcraft, you can sign on with your single sign on and have it automatically upload to the store as well if you want to. Or you can locally deploy your Snap into a VM or to your Dragon board and then test it out there. But, yeah, the whole build process is so, so easy that I haven't seen something like that in my whole life. It's really, these guys are more brilliant than I am or anybody around Snappy is because they managed to actually make the building of a package so easy that you just have to create the single file, call one command and out comes a snap. You can actually follow them on Twitter at Snapcraft.io. So, yeah, like he said, it's usually, it's Kyle that's on there that's usually doing a lot of stuff. Right, Kyle and Sergio are the... They do a lot of really cool stuff also on testing days and this is probably a show that maybe we should talk about. Ubuntu testing days, Ubuntu on air and every Friday they usually do little segments where they test out stuff like Snapcraft.io. You go on there, I know you talk every now and then, right? Yeah, so I hope you and your team are going to have a productive week here. Oh, yeah, we will. And not just this week, but what's going to happen in the future and lots of, I guess, in the industry, lots of demand for this. Lots of companies, like thousands of companies maybe, like considering how to use this. Well, I hope also community. Come to us in the Hash Snappy channel on Freedote and join us on rocketubuntu.com in the Snappy channels and ask questions if you have any. Try out Snapcraft, go to Snapcraft.io and build your first Snap there. There's a tutorial there where it's explained in very easy steps how to create your first Snapcraft YAML for your open source project or even your closed source project. Snappy doesn't make any difference whether you put pre-built binaries in there or you use something that's built directly from source. And when there's a trillion ARM devices out there, how many of those will run open to core? Oh, any that won't. I mean, porting... I will give it... Half the map. The left or the right half? Yeah, indeed, yeah. Porting to Snappy is so easy because you just have to build the two snaps to the kernel and the gadget snap. And the gadget snap is mostly a description on how the image should look like or what kind of partitions do you want, what kind of bootloader is there. And the kernel is your kernel with a bunch of patches, potentially a bunch of patches on top. If your stuff is upstream already and you can just use Linux mainline kernel, then it should be fairly easy to just get going with your existing device tree model and everything in there. So, porting is a snap. Yeah. And we'll end it with that, right? So thank you very much for taking the time and this is Oliver Gravert, well known as Ogre and Robert Wolfe. I look forward to talking to you again soon. Thanks for having me. Thank you.