 All right, excellent. So we've got tenets, so I'm also going to try and go pretty quickly. My name's Paul Moore. Do SC Linux? We do this about once a year, so it seems appropriate that we talk about birthdays from the past year and the ones we've got coming up. SC Linux is turning 18 years old this December, so that's pretty cool, yeah? Almost, not till December, and it's what? It's 19 in Canada, right? I knew I liked Quebec. The good news is I think most of you know SC Linux. It's been around for quite a while, which is a good thing. Hopefully, we've shaked out the really bad bugs at this point. It's been part of Mainline Linux for 15 years now, actually over 15 years now. It's been shipping as part of the AirPrize Linux distributions for 13. We've heard a lot of Android talks the past few years. It's been part of Android for five years. Shipping on, well at least back in July, approximately 96% of all current Android devices have SC Linux in some shape or form, which I think we heard today in the billions, which is pretty impressive when you think about it. That's not including servers, laptops, computers, all the various other little network devices that may be out there, so it's pretty significant, I think. But as far as this past year went, Starved with the Kernel changes, relatively quiet. I think I say that every year, but I actually kind of consider that to be a good thing. We're rather fully featured at this point, but we did add access controls for EBPF. We also added proper SCTP access controls. We had basic SCTP socket controls before, but now we actually have proper controls that are specific to all the different SCTP operations and whatnot. We also added SO peersec support for sockets that you created with the socket pair system call. SO peersec is the underlying capability, socket option that's used by Git peercon, so that you can see the SC Linux label on the other end of the socket connection. As far as user space goes, we added tool chain support for SCTP and InfiniBand objects. InfiniBand, we actually added last year. We were just kind of a little slow to get the upstream user space support, but that's in there now. We've also got some smaller incremental changes elsewhere. Some of the bigger ones are changes to SE Manage and SE Module. SE Manage will allow you to see the home directory context now with F context. You can enable and disable multiple SC Linux policy modules at once using SE Manage. We've got Python 3 support for the SC Linux GUI command. I was just talking about this earlier today. I'm somewhat hesitant to say that everything's now Python 3 supported, but if it's not, we're getting awfully close. We slowly march away from Python 2 and get Python 3 support. As far as policy goes, I think probably the biggest thing is that the reference policy moved over to the SC Linux project on GitHub. This is kind of nice now because we have one central spot for all of our main SC Linux upstream work, sort of. The kernel development still happens on kernel.org. There were repositories hosted there, but I do maintain a mirror on the GitHub. That's nice. It allows us to use the issue tracking, Wiki, and all that stuff, so that's kind of a handy thing. Reference policy changes. The other nice thing is if you did any SC Linux policy development in the past, you know we used Git submodules, which were, I think seemed like a good idea at the time, but if you've done much with Git submodules, you've probably learned to hate them. I know I do. When we moved it over to the SC Linux project, we got rid of the submodule and just kind of folded it all in, so it's one Git module now, so that's good. Two reference policy releases this year. Lots of changes, way more than I can get into in the few minutes I've left, but most of it's centered around enablement of newer versions of the software and fixes. And I started doing this last year and I thought it was kind of interesting, so I did it again this year. These are basically all the kernel changes since September 1st, 2017, so hopefully the last year, a little less than that. In the kernel, we had 71 change sets that we merged. I mean, you can see the details. We added roughly 3,000 lines and took out 1,700, and you can kind of see the use of the top 10 SC Linux kernel developers over the past year based on lines changed. So Steven Smalley, I think you guys may know of him. This cheated a little bit, actually I was kind of surprised at this, but there was a state encapsulation patch, so a lot of this was just kind of some rote changes. But anyway, if you see your name on the list, why don't you go and stand up? Don't be shy. I'm looking at one guy right here. Come on, stand up. Come on, come on. Oh, he's not going to stand up. There we go. There we go. So anyway, thank you everybody. Some audit changes that actually lived in the SC Linux directory. So anyway, moving quickly, these are the user space changes. So the one thing that I thought was actually really kind of cool, there's more lines removed than were added, which I always like that, at least in the kernel. Whenever we have a patch that actually gets more code out than puts it in, that's always great. So I thought it was impressive over the year that user space actually shrunk a little bit while still adding features. So anyway, if you see your name on the list, stand up. Come on, come on. See he's doing it quicker now because he knows he's going to get some applause. See, we got some new people here. So round of applause. All right. And last but not least, policy. Where would we be without this? So this is skewed a little bit because what I told you with the submodule stuff, that's why you see Chris with well over 100,000 lines of code change. So I don't think Chris is here today. Is he? Yeah, okay. I was going to say, you can tell him we're calling him out. But anyway, so once again, if you see your name on the list, come on, stand up. Yes, there we go. You know, hey, he got more lines of code change than I did. So that's all right. So anyway, I'll just wrap it up by saying thank you to everyone. For those of you who want to get involved in SC Linux, here's some good places to go. I would recommend staring off in the GitHub. Like I said, everything is consolidated there that we've got the issue trackers for the user space, for the reference policy, the kernel. You can take a look. There's links to the two mailing lists that we have. The first one is just the general SC Linux developers mailing list. Then there's the reference policy mailing list below that. You know, you saw a couple of people stand up today. If you have any questions, I'm sure you can go talk to them and they would be more than happy to talk to you about it. If all else fails, if you're watching this on YouTube later, or if you're too shy, you don't want to come up and talk to anybody in person, there's my email address, there's a Twitter handle, I'm always more than happy to talk to you guys. So anyway, that's it. Unless anybody has any questions, you can try to answer. Yes, yep. The work was originally focused around RDMA, but yeah, there's Peaky restrictions, there's Endpoint restrictions. Those are the two ones that come to mind immediately, but the guy who did it, Daniel Juergens, I believe from Melanox, wrote a really nice description of everything. So if you actually look at the Git logs, it's in there. But anyway, I can always talk to you more about it later if you'd like. That's it. All right. Well, thanks a lot.