 Fedora IAT and Fedora 34. Fedora 34 was an interesting release for IAT. We didn't appear to deliver much. The main feature that we were planning on delivering had issues with REL IAT and was not backed by Fesco as a result. It certainly meant for some interesting discussions. We will probably try and revisit that in Fedora 35 depending on how the team feels about that. Interestingly, I was thinking earlier today about external contributions to Fedora. We've had contributions from third-party companies, probably the biggest we've seen in the IAT releases. I'm sure some of that's interest from it becoming an addition. We've had contributions from NVIDIA, Xilinx, NXP and a number of other big silicon companies that you may or may not have heard of. That's certainly interesting getting them involved. We're working with other vendors to get actively involved. Some smaller vendors have also been involved that you may or may not have heard of companies such as CompuLab, Arrow and Solidron. From that perspective, it's quite interesting because in terms of device enablement and technology enablement around wireless and SoCs and FPGAs and other such technologies, we're seeing more and more contributions from the community and not individual contributors but relatively large companies. To answer the AMD question, the deal hasn't closed yet. It is progressing, is my understanding. But yes, so anyway, that has certainly been an interesting insight getting areas, companies and things like that involved in Fedora that have never actively been involved. We've also been working on system-ready, IOD-ready, which is one of their new standards. Fedora is being actively used in the testing of that. We've certainly had some interest around that and working with ARM to drive industry standardization. In Fedora 35, we should also hopefully start to see new install and provisioning and onboarding options. So we have a very basic onboarding tool called Zazeri. So hopefully we should get some more cycles to work on that. The IOT, my team inside Red Hat, has been busy and focused on various bits and pieces and we're hoping to see a bunch of that stuff land into Fedora 35 for IOT and help drive a bunch of bits and pieces around there. And the team is slowly expanding in size, so we'll have some more bandwidth to work on Fedora as a whole. So yeah, so what else was I going to discuss? Apologies, my head is a little bit all over the place. Yeah, so where are we going? So as I mentioned, the IMA signing functionality wasn't accepted for Fedora 34. And one of the reasons that was pushed back was that oh, it's the ability to lock down Fedora, which is completely rubbish. Fedora is and always will be under the control of the user. But the thing with IOT is if that device is on a light pole or a pump out in the middle of nowhere, the owner of that device wants to keep ownership of it and keep control of it. And so IMA serves a number of purposes, and one is that you can verify at runtime without any external connectivity that binaries haven't changed and they were as intended from the moment they left the Fedora build system, which gives an X level of sort of authorization and authentication as so that the user knows what they're running, what is expected, and what was produced by Fedora. So it gives the ability to do end-to-end verification and set policies of what to do when those things change. And from a security perspective in things like IOT, that's very important because it's not about locking down a system and stopping users from being able to do what they want to do. It's about being able to secure systems to ensure that unwanted users can't do what the actual owner of the system actually wants to be able to do. So there's work being done there so that users themselves can set policies as to how their system will operate and how their system will react when it doesn't appear to be operating in the way that the users expected it. And I think that's overall important. It helps improve the reliability of Fedora as a whole and the ability for users to be able to verify what their systems are doing as a whole. And with a lot of the hacks and things in the IOT space, that's very, very important. But it's generally useful for all other areas of Fedora as well. The ability to know that that binary hasn't changed since it was built on the Fedora infrastructure could be years later, be able to verify and could be years later, gone through numerous mirrors and numerous systems later and the user can still verify that they're running what they expect to be running. And so while some people don't seem to see that point of view, I feel it's a very useful and important security feature that certainly with people I speak to has had a lot of excitement because securing Linux systems or system any sort of system to the level of security that people expect in a data center when it's out in the street or out in a field or out anywhere generally accessible is a really hard task to do. And I'm sure many of you have heard the terms around security is like an onion with multiple layers to achieve the thing. And things like I'm assigning and I'm a policies is one of the layers of that onion to enable us to secure that. And like we've done a lot of work around TPMs and other security related things. We've been doing work around 5G wireless and other wireless technologies. We're working with on our at the moment to improve Bluetooth support in the Linux community as a whole. And we should start to see, you know, some of the fruits of that partnership and work sort of land hopefully in the Fedora 35 time it may be later in the Fedora 36 time frame depending on how long it takes to get all that work done upstreamed and filtered down into Fedora releases. And, you know, working with partner companies or like companies that are working with Fedora IOT, not necessarily partners, but, you know, NXP and Xilinx are working with Fedora IOT off their own back through no, you know, direct work that I'm doing, you know, in some cases I'm literally just receiving bug reports or patch with patches attached or, you know, patches and that that's just fantastic. So, yeah, I think that's mostly what I have. Does anyone have any questions? It feels very one sided here like I'm talking to myself. Raspberry Pi in what context, Matthew? It should work. I know people have tested it. In the context of IOT where we don't support graphical output, it should all work fine and we've done quite a bit of testing. I actually have a, you can't actually see most of my desk here, but so that's an 8GB Raspberry Pi, which I literally about an hour ago flashed with Fedora IOT 34. I haven't yet actually plugged it in and powered it up. But like, I'm not sure I want to show people my desk actually, but like, it's, this is Fedora testing and that's a very small proportion of Fedora testing. I currently have no less than 31, 32 devices running various components of Fedora 34 from IOT to minimal to workstation, XFCE and so on and so forth. So there has been quite a lot of testing. I have quite a lot of partial blog posts written around Fedora in general for Fedora 34 that I have to finish and publish. And in terms of Raspberry Pi 4 with something like workstation, it sort of works now, but there's no accelerated graphics. I was hoping that the graphics pieces would land upstream into 5.13. They don't look like they have landed yet, so I will have to look further. The Jetson Nano is working on traditional Fedora very well. I have a patch set that I have to finish up. Matthew has been explicitly asking me about it. I'm hoping to get that done over the weekend to fully support Fedora IOT. And yeah, so that was almost working, but I didn't feel like being, I was, I had enough Fedora 34 blockers and was pulled into other blockers like SHIM blockers to assist in the lead-up to the release. And so I decided I would sleep and not file any more blockers that would ultimately land on my plate to fix. I mean, one of the nice things with IOT is we do a release every two to four weeks and that's a full compose release. So we can add features like on a monthly candidates for all intents and purposes. And so like I fully expect that we will have another release in a week or so which should add nano support and various other bits and pieces. So yeah, that's one of the nice things about being more agile than a traditional Fedora release. And people did wonder why we have a different release process and that's part of the reason is so that we can be more agile and rather than doing like two releases a year, we do like, you know, between 12 and 20 releases a year depending on what's going on. The status of libgpiod is there and it works. And like the various upstream projects are getting more and more support for it. I personally haven't had a lot of time to play with it just simply because I have so much other stuff that's on my plate. I would greatly welcome assistance in that process, whether it's documentation or various other bits and pieces. There's been quite a few discussions on the list about it and there are certainly reports of it working well for people. I would like to see better integration upstream with projects like Node-RED and stuff like that. But you know, that's a work in progress and I've been working with a couple of vendors around libgpiod. But again, in a lot of cases, it's on their backlogs and it's on that we will get to at least. And yeah, some of those vendors have things like BSB kernels that are based on ancient, ancient things prior to the 4.8 release which got the first version of GPIOD. So it's sort of in progress, but I would certainly welcome anyone that could assist me in the documentation of it. So the Raspberry Pi 400 does run Fedora 34 with all the caveats of the accelerated graphics. And one of the problems we have with the Raspberry Pi 400 is it actually uses the same Wi-Fi module that is on the Pinebook Pro. And that is a corporate head fuck between four different companies that now own various pieces of the Broadcom or BRCM FMAC Wi-Fi modules from Broadcom. I have contacts with two of those companies and they actively are now engaging with us to ship new Wi-Fi firmwares. I am working with those two companies also to ship matching Bluetooth firmwares which should improve like Fedora as a whole. So it must have been January, we shipped new versions of the Wi-Fi firmware. In some cases we upgraded Wi-Fi firmware from releases in 2013 to releases that were cut in 2020. So like new firmware for devices that are six or seven years old and with God knows how many countless CVEs and what have you. And so you know that that's some of the side effects. That was almost to get those releases done. That was almost a year of my time with emails and meetings and phone calls and those teams engaged with legal teams and obviously you know small things like COVID had impacts on that as well. We were supposed to get the Bluetooth firmware in March. It hasn't arrived yet but we're working on it. But the problem with the Wi-Fi on both the Raspberry Pi 400 and the Pinebook Pro is that is now in a company that was sold off from Broadcom and is a completely different company with completely different contacts which we don't actually have yet. So I'm digging through contacts and people that I know that have dealt with or are dealing with you know those companies to try and get appropriate contacts to get appropriate firmware is released for the Raspberry Pi 400. And it's a very popular 8011ac wireless module in a number of devices. So it will be really good to get that firmware because you know ultimately that will make a lot of devices just pop to life. But you know sometimes dealing with corporate teams over some of this stuff is a very deep rabbit hole that involves legal teams and God knows what else. So we're getting there. We certainly have improved Wi-Fi over Fedora 33 in terms of stuff like that and that will continue to improve. So a lot of the other distros that support a lot of like devices use downstream kernels. So major forks often of kernels that have been like just dumped over the fence and don't get security updates. And so Fedora has a policy around you know the support has to be upstream and like we first supported the Raspberry Pi 3 in Fedora 25, Fedora 26 and we worked with the Raspberry Pi Foundation and Broadcom over their open source drivers for three years before they got enough of that upstream that we could enable it and things like that worked. And you know if you look at a lot of those you know releases like they'll have like 30 or 40 or 50 different kernels and 30 or 40 or 50 different images for different devices. And one of the things that I've always been very proud of in Fedora is that we can take a single workstation image and we can run on nearly 200 different devices with accelerated graphics and various other bits and pieces using one kernel and one image to support all those devices. You know a lot of the other distros don't have upstream policies and they like any shit will do. And there was a situation with some of the all winner BSP kernels where there was literally a back door where you could get in and full route access. And the distros that shipped those BSP kernels had to panic and at the time media reached out to me and was like well when is you know Fedora going to patch these and it's like well we're not vulnerable we don't need to patch them because we're using upstream. I work very closely with the Pine 64 team. I have already sitting on my desk one of the court 64 things and in my all my abundant spare time have been working with some of the other people in the community that are working on upstream support. The first generation of the dev board that I have has some hardware issues. So there's actually a little hardware startup in London just north of me in the Olympic Park and I've been working with them on some of like giving feedback to the Pine 64 team about how they can improve the hardware and things like that. And so like you know I think where we should have the first lot of support for the court 64 in Fedora 35. I'm actually hoping to have a remix image out you know in a month or two for that for which should be well and truly in time for when the actual devices start shipping. So I hope that answers the question around the other distros. The person asking about drivers in the Fedora repo or RPM fusion repo what do you mean. My first review of the Beagle risk five or the Beagle V is that it's still sitting in a box on my desk. I got as far as downloading the Fedora remix image for it. It has a stonking great heat spreader and fan on top of it. And what like my intention around that is to work with I'm not doing another architecture bootstrap in Fedora. I've done more than my fair share of those. But my intention is around you know getting support to be able to use like cross compile initially Fedora kernel like as in a stock Fedora kernel to be able to boot on the device. Work out how the low level bootstrap works which is actually unsurprisingly quite similar to 64. And there's a few other people in the Fedora ecosystem that I'll be working on on that so that we can get UEFI and grub and you know working in the standard Fedora way that a lot of people expect. But like a bit of that will be how much time I have and various other bits and pieces. But I've worked with the Beagle community going all the way back to the original Beagle bone white which was released God knows how long ago. So yes the Raspberry Pi 400 is a BRCM FMAC but it's from a company called Synaptix. And there was let me see if I can find a link to. So Broadcom about three years ago sold off their wireless IoT division to Cyprus. Cyprus has since been bought by Infineon and then somehow Broadcom managed to sell off their wireless IoT biz again three years later to Synaptix. That actually gives a good overview of the absolute complete and utter brain fuck that is the company's. Oh are we over Murray? Okay well I'll be hanging around in the general area. I'm sure we have somewhere. Yeah like I'll hang around for other questions if people have it. I'm sure Murray can point me to the location where I need to go. I'm sorry I literally logged in about a minute before all of this started. Excellent thank you Murray. Bye everyone. I hope this has been useful.