 Well, let's get started. Hi, I'm Peter Robinson. I'm here to talk about IOT on Fedora, where we are, where we're going. When I originally proposed this talk a couple of months ago, the intention was to actually have a shiny demo, but the Fedora gods haven't been on my side and everything's a little bit up in flames, along pretty much with some of F27. So not quite where I want it to be, but you know, so it's useful to have a sort of general discussion about where we're going anyway, get some questions, some ideas. Feel free to sort of ask questions as we go along and I'll do my best to answer them as best as possible. So this is roughly what I'm going to go through. As I mentioned, not quite where I'd like to be. I think I'm using atomic on multiarch. Again, we're not quite where we need to be there and various network and software stacks and things like that, that I've been working towards and testing. So the general idea is three architectures, x86, 64 and 32, with a few proposed sort of demo platforms. It won't be hard to these devices that will run on Fedora or any of the Fedora stuff and potentially even VMs and Docker and various other images as well. But originally I was planning on using a slightly different x86 dev platform with Intel's changes around their IOT architecture platforms. We've had to adjust that slightly. Did I mention we weren't quite where I wanted to be? So Raspberry Pi, some 96 boards, hopefully in the next few months we should have some cool announcements with the 96 board guys about some platforms there as well. Pi64 and you know, various other Fedora devices. Network hardware stacks, Bluetooth LE, Bluetooth mesh was just announced and all the bits are just going into the kernel and various user space utilities at the moment. So before too long, we'll be able to use that as well. Adobe 215.4 and potentially different software stacks that sit on top of that like Thread, RS4485 and Modbus, which has been some interesting use cases that have come up recently for a fantastic technology from the 1970s. CAD and then others like Z-Wave, Industrial IO directly on the Linux device and various other bits and pieces. From a software stack point of view, nothing major yet actually in Fedora. A lot of these stacks are moving quite fast and have all sorts of vast arrays of dependencies. Node-RED literally thousands of dependencies. So there's been various discussions how we would package that up and consume it because some of the lower level packages, it's taken me months to get a few reviews here and there. Node-RED we would literally have to do thousands. So did we just do that in one big bundled RPM or did we just use NPM and consume it directly into a docker container? So there's sort of discussions around content sets and various other bits and pieces that the distribution is having as a whole at the moment. So with things like modularity and those sort of components being discussed on sort of holding off packaging some of that until some of the discussions around content sets and various other bits and pieces have some sort of direct decisions. And there's been a number of different discussions with different interested people about how things like machine learning and AI interacts with IoT. So TensorFlow, there's an open source microp, a stack called microp which is similar to Google Home, Amazon Echo-style things and various other sort of intelligent bits and pieces that can interact with IoT in different ways. So there's lots of interest about lots of different things but I've been over the last few months more about getting the low layer core bits and pieces into place to build these stacks on top of it. And of course from a home, like from an industrial point of view, there was a recent announcement around product out of Dell called Edge X which has a lot of corporate interest in it but it's a little bit like open stack that when it was first released it was a massive big code dump and I personally think it's probably going to be a couple of years away before that goes from a sort of code dump out of a company to a usable sort of software stack community sort of thing that's sort of, and then from a home point of view which is not so much by focus but I know a lot of people are interested in, there's things like Home Assistant and stuff like that and again I've not tested that on Fedora and I don't believe stuff like that's packaged in Fedora and similarly probably has vast chunks of dependencies around it and so similarly I think it will be useful to look at how we can consume that and make sure the IoT stuff in Fedora will run that stuff from a container point of view or similar to that but not necessarily packaged directly into Fedora because of the vast amount of work around it and the fact that it's changing and moving fairly quickly. So timeframes, plan on having something to keep the ties in the F27 timeframe, there's a bunch of components and dependencies that have already landed into Fedora 26, things like ARM64 bit, SVCs, so running on 96 boards and Raspberry Pi and Python64 and stuff like that is already, and similarly I was hoping to, I should hopefully be able to demo that tomorrow in my ARM talk where we're going in that sort of direction so if you're interested in that side of things come to my talk tomorrow and then once we get the initial sort of atomic multi-arch release in place as part of Fedora Playgrounds we'll sort of start doing a similar to the atomic two week release but we'll probably do it more monthly release so that we can roll up patches and fixes and features and what have you that we've landed in and then hopefully as the Fedora CI platform starts to stabilize and get more functionality in place we'll be able to use some of that as part of CI, CD pipeline interacting with some of our sort of ported platforms or in VMs and Docker containers to be able to run automated as much of the testing as possible. So where is the conversation sort of happening? Well it's a little bit quiet at the moment I have a Fedora IoT channel on FreeNode and an IoT list and just generally some bunch of different other standard Fedora locations and has anyone got any questions? Yes? That is very good. So I'm getting into place a lot of things like atomic compose and stuff like that and we've had some dependency issues there around multi-arch and some of the multi-arch team has helped out and we've fixed some of that so I'm hoping that should almost be there. It depends a little bit on what you're interested in. I should probably actually put up a wiki page with a this is what we're doing and this is what needs to be done so that I can consolidate that in my own head so that people can better help out. So the question is am I interested in other architectures like Raspberry Pi? Raspberry Pi is an ARM architecture and it was will be one of the because they're very popular it's one of the proposed platforms. Well it so the proposed platform is one of the more like reference architectures is probably the best so these are the ones that will be testing and integrating into CI and things like that so it's not to say that something like a Banana Pi or some other ARM based devices or any of the ARM based devices such as a Beagle Bone or what have you won't work perfectly fine it's just that we won't necessarily be doing all the testing on those. Correct. Yeah so proposed platform is probably better off reference architecture. I'm jet lagged and I only did the slides not that long ago. So these are more reference architectures as opposed to IoT things like sensors and stuff like that. What sort of sensors and things like that are I'll say best supported? So this is some of the stuff that I've been getting into place in Fedora 26 so things like device overlays to support something like say the Raspberry Pi sense hat which has a bunch of sensors on board. The industrial IO drivers have like literally hundreds or even thousands of drivers in there. Some of the interfaces so a lot of the like generic libraries that go between the software and like the sensors are well dreadful basically. There's like 20 different libraries to do it and in a lot of cases like I mean one of the most promising ones is like MRAA slash UPM which is two libraries sort of stacks from Intel but the UPM stuff recreates a whole bunch of the drivers for sensors and user space where they already have kernel space drivers in place. So a bunch and then there's a couple of libraries like LibIO which is relative but I mean for example the kernel has a temperature industrial IO thing where they have a unified interface where you can query any of the sensors that may be available and get temperature back in a standard arts format. So why there's not a library with Python bindings and other such things that just say give me a list of the temperature centers and what they're recording I'm not sure and that's and like you know the industrial IO has temperature analog to digital conversion like hundreds and hundreds of different sensor types in there but there's just at the moment the vast majority of the there's like dozens of different libraries to interface with them and most of them are terrible. And like similarly like with Bluetooth our lead for example there's a standardised GAT server standard that is part of the Bluetooth spec and there's a whole bunch of stuff around that so temperature you know human body stuff so like fitness bands and things like that so and it has like dictionaries about read this thing and you will get this data if it's available. Yet there's about 20 different Python bindings for it and most of them pretty much just wrap this like the Bluetooth command line interface where and yeah just dreadful so that kind of space is yeah interesting and I've been so I did a bunch of clean up and enablement around some of the kernel stuff but like as in the Fedora kernel config for the IIO stuff to standardise some of our sensors there in F26 there probably needs to be more done but like in the case of the Raspberry Pi sense hat three out of the four sensors need patches that I haven't that I've started to write to get them to work and this ends up going down rabbit hole so it's that space is quite interesting there's a lot of stuff there and it's improving quickly but you know there's also still a lot of work to be done. Can you talk a little bit more about atomic and how you see it working out in the IOT space and what some of the benefits and challenges are there? So it's one of the nice things about atomic is that it's read only or primarily read only file system you can upgrade it in a single snapshot if that upgrade doesn't work you can roll it back. So in theory so recently there was a lock company that managed to break a whole bunch of locks by shipping out the wrong firmware and basically the option people have there is to ship back part of the lock to get the firmware fixed so you shouldn't be able to get into that situation and you know so the plan is there basically to have similar to what the in Fedora 26 the atomic guys are now just moving from F26 to F27 to F28 and it all just becomes one stable release channel and so basically that was always my plan in that regard we do basically monthly releases and it's like you know 7801, 7802, 7803 and it just rolls from F26 to F27 to F28 so the devices out there that are running it can just keep moving forward and the intention with the base IOT OS image is to have just enough so there's not like something like a server and store or a workstation so which has thousands and thousands of packages there that potentially it's a much smaller package set so you know things like glibc and things like that are a lot more stable so it's not the upgrade pain to jump from a release that may be say the known stuff where they quite often change APIs and things like that regularly. What are some of the challenges you've run into there and why haven't we seen more out of atomic and IOT? Probably my biggest challenge there is time so as part of my role this is part of my role but other parts of my role include evangelize so speaking conferences, speaking internally, speaking with customers and partners and bits and pieces so the biggest challenges I've found to date of time and also we don't quite have all the multi art stuff in place yet so it's been working to get a bunch of that in place so that we can compose a single release across multiple architectures but again that's almost there. So the question is about FPGAs and yes there is definitely interest in there similarly there's a bunch of interest around so OpenCL sort of GPU sort of stuff so TensorFlow that sort of thing so yeah I've had a number of conversations where FPGA, GPGPU and that style of compute is certainly of interest because I think one of the classic examples around that sort of space is like image recognition so there's you know whether it's identifying a vehicle versus a bird or an animal at a gate versus I don't know detecting trains at a crossing or a number of plates and things like that the ability to do like a certain level of AI at the device so that they can independently make decisions about stuff without having to go up into the cloud or just simply because of speed and time and stuff like that so like in a self driving car the latency of going back to make a decision and going what do I do now and then coming back to the car well there could well have been an accident sort of thing so there's certainly for certain workloads especially sort of more in I suppose the industrial space but as opposed to like the home space there's certainly a lot of interest in all sorts of like offload and acceleration whether it be FPGA or GPGPU sort of stuff. Any more questions? That's the path. This is the first 15 minutes. Can you just do it again? There's a video recording it. Okay, I'll take the video. Thank you. Any more questions? Thank you.