 Welcome, folks. I think you all know me. I'm pretty sure you all know Paul as well. I'm Peter Robinson, the lead of Fedora IoT. Paul previously Fedora QE, now part of the Relfar Edge team along with me. Paul is moving over to lead more of the Fedora IoT in the community space because I just don't have enough time, so we just load balance it out. So I'll let Paul give himself a quick introduction and then we'll kick it off. All right. So as Peter said, Paul Whelan was the QE lead for ARM and AR64 and Fedora for a number of years, also taking over IoT. And now I've moved over to the Edge team and given the reins to the QE proper to do the testing for Fedora ARM and AR64 as well as IoT. All right. So what is Fedora IoT for those that are new? Most of you have hopefully used Fedora IoT, but we're focused on small edge devices. We currently support x86, AR64 and RMV7. Sadly, RMV7 is end of life in Fedora 36. So it's an RPM OS tree based minimal operating system with no graphical user interface. If you're looking for graphics, then you probably want to use silver, blue or canote. I think that's how you pronounce it. It's a container folk. We focus on using containers for your applications. You can layer your packages, of course, as with any RPM OS tree based installation, but we do prefer to use containers and encourage you to do so. We're also very focused on security. That's why we put it there twice. That's very important to us. The current distorted hardware. So UEFI is the requirement. We do also recommend that you have a TPM2 and a hardware watchdog. For AR64, we support a variety of server-ready classes of devices as well as edge server and IoT for NVIDIA. We support the Jetson Xavier and Xavier NX. Of course, we have to support the Raspberry Pi 3. The Raspberry Pi 4 is more supported in IoT because we don't need graphics there. Graphics is the big missing part in vanilla Fedora. We also support the Pine 64 and the solid run Heimann board M, which is an IMX-based system. For X86, we support the FITLIT2, the Compulab FITLIT2. It's got a TPM2 on there, so it's a good device to have, as well as the Upsquared. Basically, any X86 system that's going to have UEFI should run IoT pretty well. We support numerous hardware platforms. These are the ones we actively test. There'll be some more interesting ones coming along as part of Fedora 37. But pretty much anything that's supported in Fedora should work as long as it's UEFI-based. We've always been UEFI-focused. It enables us to deal with security better, and it's a more modern platform. All right. What is featured in Fedora 36 for IoT? As I mentioned previously, it's the last supported release for ARM v7. ARM v7 is deprecated largely due to a lack of ARH64 hardware that supports ARH32, so we're running out of options for the build system. We've also got Podman 4.0, and they've had a complete rewrite of their networking stack, as well as various other improvements. New complimentary network stack, which we've included in IoT. It's great for IoT deployments. Parsec 1.0, so platform abstraction for security, basically an abstraction layer for security hardware. It allows you to use devices like such as TPM and HSMs, and various improvements to GreenBoot. GreenBoot's got some more health checks added to it by default. What is GreenBoot? Sorry. GreenBoot is a health check framework for SystemD on RPM OSG-based installation. When you boot up your system, it runs a variety of health checks to ensure the system's in functioning properly. If not, it'll roll back to the last known good configuration. Users can easily add their own scripts, just a small batch script to personalize health checks. If you have a host that your remote device needs to reach, you can easily create a small batch script that'll do that on boot. Of course, if you can't reach that host, it'll roll back to the last configuration that it could. Work is ongoing to enhance GreenBoot for Fedora 37. We're trying to make things easier, so we don't ask users to write a batch script, so looking forward to that. Since Fedora IoT started as an R&D project back in 2016, we had a bit of a long road through objective and spins and eventually to addition. When the work that myself and others had done as part of that was approved to go to product, that was early 2020 and with various different bits and pieces like COVID and lack of travel and all sorts of other things, we ended up having to focus on roll for edge, first and foremost. Fedora IoT as a result of that, some people may have noticed has slowed down its development somewhat. With Fedora 37, that's now changing. Worked closely with Matthew, FIFA and the CPE team to get Image Builder as a service into place. That should be going live. Now we're out of freeze for Fedora 36 this coming week, so we can start to move a lot of the pieces that we have been working on in roll for edge back upstream into Fedora 37 to enable the development to happen there. The plan is for the edge team to make Fedora be the upstream again like the full upstream where all the innovation happens. Things will happen first in Fedora. We've got a bunch of major improvements and changes from roll for edge that will be back upstreaming for Fedora 37. We have three changes approved so far. I need to finish writing up the rest of the changes with the team so that we can submit them. They'll be coming along in the next few weeks. So 37 is going to be a pretty major shift for Fedora IoT. A bunch of fun and interesting innovations. We've been working closely on things like the FIDO device onboarding standard with the upstream organization working as we have in the past with ARM on things like system ready project Cassini and Pasek as Paul mentioned previously and with internal teams like the image builder team. So we've got numerous enhancements there that will be initially going into Fedora IoT but they'll be definitely relevant also for things like the mobility project with Fedora on various different open phones and stuff like that. That's something that myself and the team are really excited about because it's something that we've felt has been lacking for some time but like everything, priorities and resources available and availability of team members to work on things has been a bit of a struggle. So that I think is very exciting for both the team and for Fedora IoT as a whole. So look forward to seeing some more changes come out there and we're all looking forward to working on them over the summer as we get things back upstream. So some of the technologies that are coming along. There's IMA, the proposal which I think we introduced first in Fedora 33 for signing of RPMs has been approved for Fedora 37 and that should be turned on hopefully this coming week again with the infrastructure unfreezing. It gives us the ability to do runtime verification on files based on what the build system was produced. So the ability to be able to control a system to allow it to do what the owner wants it to do as opposed to something that an attacker or someone else may want it to do is very important for IoT devices. IoT and Edge is quite different from a lot of use cases where devices in a data center have four walls and an access control list which provide large amounts of the ability to secure a device. When you go and put a device out in the field on a light pole in other different use cases in robotics, various other bits and pieces, you may not have that sort of direct physical access control. So it's one of the many layers of security and a lot of people refer to a security like an onion needs multiple layers. So it's purely there so that the owners of the system can verify at a runtime that they're running the binaries that Fedora shipped from the build system. This could be an isolated system that is fairly bolted down that has limited network connectivity but it can still verify that the binary is exactly what Fedora produced years earlier potentially at runtime. So I feel it's going to be fairly important and a bunch of other people across the Linux industry feel it's a fairly important means of verifying IoT platforms. So the base functionality is accepted in Fedora 37. There's numerous enhancements coming in that will be available in releases going forward and there's still a lot of work to do. Ima's been around for some time in the Linux kernel but it's been never really used and deployed as part of a general purpose Linux distro. So there's been a lot of work done there. There's been probably best part of two years of work from my team and wider teams across the ecosystem from IBM, Intel and others to get things fixed and improved and enhanced to make it best deployable for general purpose distros and Fedora and REL9 are the first that will be doing that for a general purpose distro but there's certainly lots of interest in there across the industry as one of the many components used to secure a device. I mentioned FIDO device onboarding. It's an open spec that came out of Intel. It was called secure device onboarding there. The spec was improved and enhanced as part of that. It became part of the FIDO organization which some people may know for web auth and various authentication tokens and things like that. So part of the same organization but running under the IoT working group is part of that. Red Hat is a member of the FIDO IoT working group and we're actively working to evolve the standard. My team did a clean implementation in Rust from the upstream standard. It's had interrupt testing with the other open standard. We felt Rust was the better way to go with this platform. The other open spec is written in a combination of C and Java. We felt for IoT and Edge devices that Rust was probably the better language to do that in. So we did a clean implementation from the ground up. The first version of that that we're actively deploying will be in Fedora 4, Fedora 37. That's kind of exciting. I think Fedora and REL9 will be the first Linux distros, I think, generally to support this new standard. It came out as a 1.0 May last year, 1.1 I think is out now and the spec that we implement is based on 1.1. I think that's exciting and certainly one of the firsts. I think the industry as a whole is moving towards this. It needs hardware manufacturers and various other involvement because of things like root of trusts and chain of trust. When a company manufactures a device, it will generate a device credential and then as it goes to a wholesaler and then onto a reseller and then to the final owner, that chain of trust gets extended so that when you onboard a device, you can verify who the owner is and who that device belongs to. So you can plug it in. It brings itself up on the network. Because of that chain of trust, there's a rendezvous server that will redirect the device to who the management platform belongs to and you can basically onboard a device with zero touch. So it's a very cool technology and really looking forward to be able to get this into Fedora and demo it. As Paul mentioned, we're moving a bunch of the component like the artifact generation over to OS build. We'll be implementing some new artifacts for Fedora 37 as well. One of the advantages of this is the old way we do things is in Koji, using Pungie, various other bits and pieces. It's not easy as it stands at the moment to recreate and modify Fedora AOT for your own use cases and your own deployment methods and things like that. Bringing OS build in here allows users to be able to install OS build on their own build system and take the Fedora input configurations and be able to generate and modify Fedora AOT to suit their own things much easier. So while we'll have the sort of vanilla generic Fedora AOT official images, it'll make it much, much easier for users to do their own customized platforms if they're happy to deal with the output and generating updates themselves and various other bits and pieces. So this is the first move to bring artifacts built on OS build into Fedora. So Fedora AOT is leading that initiative. I'm hoping that there'll be many more artifacts over time generated. The nice thing about OS build or image builder is that there is a team like a full team at Red Hat that is actively maintaining and improving this constantly. That team is very excited that Fedora AOT is moving to this in Fedora infrastructure for the official builds, looking forward to moving over other artifacts for in time as the bits and pieces fall into place. But yeah, it's nice to have like a fully maintained sort of platform for producing these sort of artifacts. Simplified provisioning will be a new feature. I haven't done this feature change yet. But this is anaconda when you like the traditional Fedora installer will install a system like every single time. And it should be the same, but like it's a little bit like calligraphy of old like in the old days, if you wanted a book, you would hire a calligrapher or a group of calligraphers to write books and they would mostly be the same. But you know, it's writing down the bits every single time and you may get some slight nuances. Basically, if the hardware slightly different or it detects hardware slightly differently, or the slightly different versions of firmware, you might get, you know, things that are slightly different. Simplified provisioning, we generate an image with OS build where we explicitly specify what we want. You can deploy it with network, USB, disk, factory provisioning. And so that image is identical. So it's more like feeding a piece of paper into a photocopier and getting a thousand identical deployments or a million or however many. It has some nifty new features that we've worked on recently. So we can do things like pre-encrypted or set up the image fully for pre-encryption. And then when you like provision it onto a system such as, you know, an edge gateway or something like that, it generates a new encryption key and rolls that into the TPM and then sets off re-encryption running so the disk is completely re-encrypted. And that's all with a single disk image. So there's some fairly cool and fun things there. I feel those sort of technologies will be very useful for things like the mobility project where we can generate an image, have people want their phone encrypted, you know, they encrypt it and set the re-encryption running. And again, so we can produce like generic images that are sort of null encrypted and the encryption tech basically will re-encrypted on the phone for like a device specific encryption. So things like that are very cool. And looking forward to seeing them used in other areas of Fedora as well. How are we doing all this? This year the Relford Edge team has a bunch of new team members. So I think we're sitting around seven now. Hopefully a couple more coming on later on in the year. You know, with Fedora IoT becoming a full upstream to Relford Edge again that allows us to drive the innovation there. We're mentoring an outreaching intern for the summer to improve and rewrite Zaziri which will be based on top of the FDO stack. So that'll be like new provisioning tech within Fedora. I'm not sure that that will necessarily be ready for Fedora 37. It might be. But you know, looking forward to getting involved, the team's looking forward to getting involved in the outreaching program. So I think, you know, that'll be fun and certainly help us improve more things in Fedora. And of course, you know, contributing the usual way, IRC, matrix, meetings, mailing lists, documentation, etc. So I think that's it. Perfect. Very, very good there. It's getting a little worried, but that worked out. We've got time for a few questions here. The first one is, will these slides be available online somewhere? I think that's probably the... Okay, well, and we'll figure out how to get that information to people. The next one is about... I'll probably just put them on my blog as a quick post. All right, that's awesome. Will OS build run in Mock and Koji, or does it go around that, like the current image build? So in Fedora infrastructure, we are using the Red Hat Image Builder as a service. So it runs through Koji and then calls out to the API to run the builds for us. It currently supports x86 and arm64, and power and Z will be coming later on in the summer, I believe. And then you can run it at home on Fedora or CentOS Stream or RHEL, just on native architectures. I think being able to run it yourself with this very same configuration easily without having to set up the whole thing is pretty powerful. Yeah, that's one of the big advantages, why I want to move to it, because we can document how people can make their own. So next one is, given that some of this stuff is implemented in Rust, will there be more official and slash Red Hat support and help with Rust packaging in Fedora? I'm editorializing with the slash Red Hat there, but I think that's the implication. This is for someone who I know does a lot of the Rust work, who would very much like some more help, I think. Yeah, so I don't know the answer to that question, is he? I'll put out another thing. Anybody interested in IoT and Rust and listening to this, we could use some more help with the Rust ecosystem in Fedora. So yeah, let's get in touch with Decathorpe about that, I guess. And then, I guess the last one here that got, well, I'm going to skip that one about Image Builder because it's off topic. Let's go straight to which IoT device has the best hardware support out of the box right now and what would you recommend to beginners? Oh, that's an interesting one, because it all depends on what you want to do with it. The Raspberry Pi 4 for the headless support that we do is pretty good. Part of the problem with that at the moment is it is very unattainable. I love the word unattainable. And I managed to get a compute module for. I've only been on the waiting list for one of these from suppliers since October last year. And the supply that I'd signed up for, numerous suppliers I'd signed up for gave me a notification in an email. I bought one instantaneously and 15 minutes later, I was sold out. You know, general purpose, like semi-modern Intel platform, the UpSquared runs things pretty well. I have one of those on my desk, but it's not sort of reachable. And there should be some more interesting hardware coming along over the summer. We're doing some interesting stuff with Nvidia. So we support the basics there. I'm hoping we'll see more from them in coming months around their AIML stack for Jetson. But, you know, third party vendors are sometimes fun to deal with. Yeah. So it depends a lot on your use case. There's a couple of interesting networking devices that I've seen sort of announced recently. So looking at some interesting bits and pieces there. Yeah. There are so many different IoT and edge use cases. Why? It very much depends on what you want to do with it. So unfortunately, not a really simple answer yet. But hopefully, we'll get there eventually. So I think we're at time here. Thank you very much, Paul and Peter.