 Here's Langdon. Thank you. Thank you. So I don't know. Can you guys hear me? So I'm Langdon, and as... Sorry. All right. Is that better? Okay. So I'm Langdon, and it's weird that I kind of plan to give this talk, or I just submitted this talk for OSCON, like last week. So I kind of expected to have a chance to prepare more for it, and now I can't get the slides to flip, because, you know, it's one of those days. So I'm a... used to be a platform evangelist for RHEL, and I'm a platform architect at Red Hat. I'm also the modularity objective lead in Fedora. As you probably know, we do a lot of their stuff in Fedora. I will point out though, the modularity objective lead part makes this a little biased, but I wanted to kind of give an overview of kind of what's been going on and what's interesting about distributions. So... we'll kind of continue. So the first thing is what's the problem? Okay. So the problem is that, you know, we have a little pendulum over there, because the, basically, software has been shifting towards the developers again. So developers are in charge, you know, so you can now deploy your application to, like, open shift or something in the public cloud, and then it starts generating revenue, and then the CEO says, yeah, but we're making a million dollars a week on it. Deploy it. I don't care, right? So developers are definitely getting a lot more power because they have a lot more self-service. So we've started to see that trend over the last 10 years. Development of software in general has changed quite a lot, right? So now we're literally building our software on top of a million lines of code, maybe more, that are produced by other people, you know, either in the open source or in the public cloud. You know, either in the open source world, especially in the open source world, somewhat in the proprietary world as well. So the software development style has very much changed, right? You can tear down an architecture and rebuild it in weeks, right, when it used to take a year. We also are noticing that, particularly in distributions, right, we have different life cycles of software. We have an operating system. We have, like, an individual application, like a web server, and we might have, like, a Firefox. They all have very different life cycles. And right now, when we think about distributions, they're all kind of tightly coupled. They're all released kind of at the same time. So that's a little bit of a challenge. Then on top of that, we have, I like this picture because it's really cool looking, but, you know, these software stacks, right, there's just piece after piece after piece after piece, and they're all good, but they all have bugs, you know, so they need to be updated and you need to be able to manage that thing as a unit, and it's a huge, like, risky activity. Then we have the different types of mutual funds here, which I realized later on, doesn't actually translate very well to Europe, but when you go and think about trying to do, like, retirement, if you're 20 years away from retirement, you're going to make different investment choices than if you're 40 years away from retirement, right? When you're 40 years away, you're going to do things much more aggressively. The same is true for software, right? So when we have Apache, sometimes what you want to do is actually develop Apache itself, right? Sometimes you want to do HTML on top of Apache, and sometimes you want a production deployment of Apache. But right now, in most of the distros, you just have one deployment, right? There's just one RPM, so you always get the production version. So one of the solutions that's been coming up lately, and I like this kind of containers better than the big, ugly containers, so we have flower pots, but we have Docker and Rocket and Snap and Flatpack and Cryo, all trying to solve the prior set of problems in slightly different ways, right? So Flatpack is mostly targeted at kind of graphical applications. Arguably Docker is kind of more targeted at server side applications. Docker still uses kind of the distro packaging methods, whereas Rocket tends not to. And then Cryo is kind of new on the scene, also heavily influenced by Red Hat, but another container technology, I should put the system dn spawn up there. There's a whole mess of them, right? So the problem is that when you get one of these things you have to seriously, seriously trust the provider, right? And you have some of this problem with distros, but it's much more open, right? There's much more metadata about what's going on. So you don't necessarily know what's actually inside this individual black box, right? You know what somebody told you was in there, and you don't want to use things like Docker Hub or even Flat Hub or any of that stuff, you kind of expect to just download it and consume it, but you don't really know what's in there. And that's kind of dangerous. You also don't know when was it updated? How recently has this been updated to have the latest patches? Does it have this particular patch versus that particular patch? Because a lot of that data is lost when you put it in the black box. The upside of the black box is it just works, right? So, yeah, so that's what I want to talk about with this part. So, what did distros do? Well, they have this community of packages, right, who are curating the software that is making it into the distribution, but it has all these problems, right? It doesn't, it's not as kind of consumable in some ways as, say, a Docker container, because you have to make sure all the pieces fit together, right? You know, they have to be, the distro has to be shipping the right version of Rails, you know, at that particular point in the distribution Fedora has a huge problem, right, is that it tends to be, not bleeding edge, but kind of ahead of many other distros. So, what does that mean for any random application? So, like, a friend's application or that he's packaging for Fedora is called review board, and it uses Django 1.6, and Django 2 is what's going to be in Fedora for the next release. Well, that means he either needs to figure out a way to get review board updated or he's going to have to drop it from the distribution. So, that's a problem. So, there's a lot of advantages to the distro model, but there's some serious downsides that are basically directly correlated to the fact that they're a distribution. So, what's happening? So, distributions are changing. See, the monoliths are on the side. Um, tough crowd. Come on, guys. Alright, so, we're starting to see some new and different models in the distributions. And, you know, these are pretty recent. I think Amazon extras is, like, months old and, uh, SUSE modules, I think is maybe a year old. Um, and then, uh, Gix and Nix have actually been around for quite some time, but they actually try to solve this problem, too. Um, and then Fedora modularity, which, like I said, I'm kind of biased towards, uh, we've been working on that for a couple of years now. So, what is Amazon extras? Okay, so, this is actually, technically, Amazon Linux 2 extras. Um, but so, what they did was they've delivered kind of a new repository of, uh, I think it's RPM. Um, and given a little bit of command line tooling that lets you enable topics, they call them. And so, that extra repository has, uh, say, more recent, only thing I've seen so far is more recent versions of software. It could theoretically have older versions of software, too. Um, but what you do is you install a topic and then you can have access to some content that doesn't normally ship with that distribution. So, that's interesting, right? They're doing something kind of slightly different. Um, and what it does is kind of overrides what's in the actual distributed, uh, OS that you have. Um, so that's kind of cool. Then, SUSE modules, um, this is interesting, um, and I'll tell you, the word module is the worst thing to use for anything. So, it's currently, to the best of my knowledge, it's only available for the paid subscription of SUSE. Um, but they make kind of what they call these modules available. There are extra repos with, like, a focus on some particular thing. So, I probably shouldn't use a legacy as an example, but, you know, legacy is one and it has a bunch of stuff, but web and scripting languages is another one. Um, and then there's, like, um, uh, there's, there's like six or seven more. But the way these works is they're just extra repositories that make, uh, you know, kind of different versions of things available to kind of keep their core of their, uh, distribution small and tight. They've kind of pushed this stuff off to the side. It can have different life cycles, et cetera. Um, so that's how they're, they're trying to shift how they deliver things. Then, you have these guys, um, which I can never say, it's Gix, I think, I can never say it. Um, yeah. So, uh, I think this is really cool and like, um, in some ways for the fedora modularity stuff, if we can kind of just burn everything to the ground, um, I might be able to go down this path. But what's interesting here is they actually solve the problem of parallel installability. So you can actually say, okay, this application is going to use this set of libraries and that set of libraries, whereas this application over here is going to use this completely different set of libraries. Um, so you end up with a lot of redundancy on disk, but most of us, you know, we're starting to care a lot less about how much disk space takes. Um, but you, uh, my biggest problem with it, I think, is kind of sysadmin muscle memory. Uh, so sysadmins at three in the morning want to know where the OpenSSL library is, right? They want their fingers to just type it, and it's just there. Um, so that's a little bit of the challenge with this kind of model is that they push everything up into, uh, kind of a non-standard location and then they sim link around to get to the, uh, you know, this stuff for the individual application. So it's really cool, but it's really, uh, like, you have to kind of go whole hog into it and, like I said, kind of burn everything that you know to the ground, um, and uh, you know, kind of start over. So that's, that's my challenge with that. Then we go, talk about, uh, this is fedora modularity. Um, so the idea here is that we wanted to be able to articulate a box that we call a module terribly enough, um, that is kind of a set of a function. So, like, um, I need to serve webpages, right? Or I need to, um, you know, host a database or whatever. So it's bigger than an RPM or a DEB. The idea is it's a complete application. You also can manage, then, the relationship to different things within the module so that you can say, um, you know, I want this exact version of this library or that version of the library. Um, and so you kind of define these at a slightly higher level. We also integrated, um, what we call install profiles so that you can do the different use cases that I was talking about before for, like, a web server. Um, and what we can do then is now we can make these things parallel available, not necessarily parallel and installable. So this means that the distro kind of has a base. It's just, just an OS. And then there's these squishy library bits. And then there's the kind of the applications that sit on top. So with the modules, what you can do is you can have a well-articulated component, um, and then you can kind of say, okay, I can have this module and I can have that module, but I can't have them at the same time. So this is also very useful in kind of the container scenario because you can kind of say, okay, I'm going to put this module and this container and that module and that one. And then I can have them running on the same machine. Right? Now I've just separated their user spaces so it's, it simplifies that problem. Um, the other thing that is nice about them is that now we can make whatever we want to support available to the users. Right? So whatever, we still have to convince, you know, somebody to maintain this stuff, but you know, if we want to have the Django 1.6 also available for review board, well, so it might fall to the guy who's now doing review board to have to maintain the Django 1.6, but at least he can distribute it. Right? So that's kind of the idea with the modularity stuff. Um, so, you know, we kind of talk about it, we have, uh, sources over here and then we kind of talk about it with modules and then inside the modules are, are PMs still. Um, and then you kind of have multiple channels for how you can distribute it. Um, either building it as, you know, a container or into the distro or whatever. Um, and we've also got this idea of defaults and stuff so that basically your muscle memory of using a distro that has modularity enabled is exactly the same as it is today unless you kind of want to walk into, you know, you need a new version or a different version of something. So then you have to kind of do something uncharacteristic. Um, so kind of the point I think of, of the talk really is that we have seen this huge growth of, uh, these attempts at these solutions to a, to a set of problems that have been around for maybe 10 or 15 years. There's, there, but they've really ramped up in the last four or five as, as being really difficult. And we're seeing distributions actually start to innovate. Um, and so this is my, I love distributions and hate distributions picture at the same time. Um, so, and we're starting to see a lot of that innovation take place where we don't necessarily need to, you know, kind of do completely different models of like, you know, containers which are black boxes or, you know, everything's a binary now or we, you know, we may be able to do, you know, some kind of shared, uh, you know, do shared libraries and still have them share in RAM, right? Because you start to have the problems with like singletons and things like that when you're going across containers. So hopefully we'll start to see, um, kind of almost like the, uh, you know, the container goals, whichever container tech, you know, happens to implement it start to actually come directly into Linux. Um, and I think it'll be really neat. Uh, I think it'll be much, much better as we go forward. There's another example actually this that I should have put in which is, um, uh, what they're calling system containers, which is where you want to run like bind. So you put bind in a container, but then you expose, uh, basically all its configuration files, et cetera, uh, through to the, uh, the actual OS itself, um, in the places they normally go, uh, so that you can distribute it, it's still, like I said, that muscle memory still works, but it is actually living in a container, so it is namespaced away from the rest of the system, so you can do non-standard things. And, uh, I like this picture. So, you know, the idea is it's, it's, uh, you know, we're trying to simplify, right? We're trying to make it so that, um, the things that we know still work, um, and, but we want to be able to introduce all these, all these kind of different models. Uh, so, I think that's all my whole talk. Um, oh, yeah. Do we have, uh, questions? Um, I just- Yeah, thank you.