 So I'm Langdon, and now hopefully you are in the right place. And I probably could have done a better job in this slide, but I was kind of trying to find a different joke than this one, and just had nothing. So I'm Langdon White, I'm a platform architect. I've been the modularity objective lead for quite a while now, and hopefully you know a little bit about modularity, but I was gonna talk a little bit about it to give you some introduction, and then we'll move on to the real part of the talk. So basically we've had a lot of changes over the last 20 years about how software development both is kind of done in practice and what we know about doing it. So I like to show off this slide of, we've had a pendulum swing basically in the late 90s towards sysadmins from developers where basically sysadmins are like, I'm not deploying your garbage anymore. And so in a lot of ways that's kind of led to the concept of the Linux distros where we're kind of like, hey, how about we only have one copy of this library? We have a good idea of where it came from, and we know it doesn't have any vulnerabilities. But then about maybe five or 10 years ago, more like five, we kind of had a pendulum swing back the other way towards developers, heavily encouraged by container usage. And so we are now seeing a lot more developers kind of deploying their own stuff directly into production. And that's been, it's had some good things and some bad things about it, but that's what we get a little, it's part of the genesis of where we're going here. The other big thing that we realized, and this is why I put this, this is like a retirement planning graph, is different like different times of your life how you should be doing your retirement is changes over time, and that's true for software as well, right? There's a different use case when you use a web server for development or use it for production, and they're not the same, but when we get them from packages from a distro, it's always the same package, right? Or we do monkey business to make it so that we have some special package that you can also install that will change its use case. Usually not very discoverable, so my classic example of this, although we know a guy in the room who can answer the question, is does anyone know what the RPM is that will turn HDBD into running public HTML out of your home directories rather than out of var, I can never remember it, why, because it's not very discoverable, but I bet Joe knows it. There you go. I think so, yeah. But the point of the story is just that you have to know it exists, right? To even look for it. So that's one of the problems. Also just how we do software development, right? We can now basically scrap most architectures and rebuild them in a couple of weeks versus when I started doing software development, it would take six months, a year, to build out an architecture. So that's kind of some of the impetus here, but I'm trying to do the short version. Then we also talk about, what is Fedora? What is a Fedora user? Well, we have this persona in mind, but no one's really sure and it's often wrong and this kind of goes back to the use case, is different things for different people at different times. You know, I talk about the desktop metaphor a lot as being like the worst idea of all time because you don't actually use a desk the way you use a user interface like the desktop metaphor. You actually have stacks of stuff that you take out the stack and you open it all up and then you put it back when you're done working on your taxes or your expenses or whatever. So kind of going back to that use case story. And then finally, this is what we see from users, right? We think they all look alike, but this is actually what they look like. I have my lovely Venn diagram that I drew over here. That's the Venn diagram of user needs in most Linux distros, right? No overlap at all. So that's kind of the genesis of where modularity came from and the idea of modularity is that you wanna kind of separate the life cycle of your operating system from the life cycle of the applications that are on top of it, as well as from each other, right? So that's what we're trying to do with modularity at the same time as we want to defend the user experience that people are really used to in Fedora unless they need to go outside and do a different use case. So that's been kind of the genesis. Let me just see. Yeah, so here's my, I'm not getting preview slides so I was like not sure what was next. So this is just kind of an example of that use case, right? So you have your Fedora 28 base and your Fedora 29 base and then you have your applications that you may not wanna upgrade them on the same timeline, for example, as the new release of Fedora, but at the same time, you also wanna collect any security updates or whatever that are in the operating system or in the firewall but you wanna leave Node.js alone. And I don't know why but Node.js has been our over and over example for many years now so we're gonna just keep hitting that dead horse. But, so Node.js is here and we have the obvious kinds of what we call streams and so a module is a application usually, right? Or like kind of it delivers some functionality and then we have different streams within that module. So in the really obvious answer, right? We have Node.js 6, we have Node.js 8, we have Node.js version 10, right? But then we can, but it's kind of free form, you know? So it depends on the software, what a stream means. So for example, there's a piece of software called Calc that I think is intuitively obvious that it is a little calculator that Matthew Miller maintains and there is weirdly an unstable branch that's out there and a stable. It's a calculator, I don't really understand but sometimes people might want both, right? So what we can do is we can have an unstable and we can have a stable and in the case of this particular piece of software, no one cares what the version is just whether they have the stable one or the unstable one. So that's another example of how you can do a stream where it's not versions per se as much as what kind of delivery it is. And then we have another concept called a profile which is where we get into that use case scenario. So for example, the Node.js profile might have a minimal that you might want to use in production whereas it also has a development profile which is what you use when you want to, you know, do development with Node.js. And so you can kind of choose directly off of the module which use case you want to be using it for. And on top of that, you get expert recommendation, right? So as a, even as a Node.js developer, I may not know the best model for the deployment of Node.js, right? So instead I can rely on, you know, like a Fedora package who's gonna get much deeper into knowing how that should be deployed for different use case, essentially giving me a recommendation using the profiles because I can always add more stuff to the profile, right? I can continue to install new things next to the Node.js profile but at least it gives me a starting point that looks like what I probably need. So I really like that part of it as well. So what we're talking about here is, you know, this Node.js application, I wrote a terrible application for the sake of this talk and I'll kind of show you what I did and how and the problems, maybe some of the problems I ran into and hopefully that will help you see how ridiculously easy it actually is to use and I was very worried when I thought this was an hour long talk because like it's just, it's not that hard. So we'll see how that goes and hopefully I don't have, you know, network requirements but we'll see. So let me just see if I can figure out how to exit this thing. So is that readable? Okay, cool. All right, so if you've done any Node.js development, this is, it's basically it's a React app pointing at, you know, a backend server API. So I was gonna start with kind of the beginning which in my mind is the server side first to some extent, although it's, I just, yeah. So the server, you know, it doesn't do very much basically. It essentially is just a wrapper around MongoDB and if you're familiar with, you know, document stores like Mongo, they don't have a lot of structure to them by default. So you can kind of just shove everything in there. So that's basically what this is doing. And, but it exposes this little API and the, oh sorry, the application is eventually going to be a way to basically help you and your friends in the office decide what's for lunch. Because I don't know about you all but every time you wanna go have lunch with people, they're like, everyone's like, oh, I don't wanna, you know, I'll go wherever. And no one ever says, no, let's actually go to this place. Right? So this would be a little generator that would tell you which restaurant you should go to this week. So, nothing really, alright. I thought it was, I think it's lovely. So what we do is we have, you know, a restaurant model that describes the restaurants and basically the only part we're gonna see is that you can kind of adding restaurants. So, but the point being is that you have this model and then you hook it up to your database, you know, using this super secret passwords, et cetera. And let me just get the window here. Oh, actually let me back up a little bit and do, I'm actually doing, oh, sorry. I'm actually doing all this in Vagrant. So let me back up and show you how I set up my Vagrant. So, the important part is kind of down here where I'm just doing Fedora 29, right? But then I just kind of install Node.js and NPM just like you would do right, you know, without using modularity at all. Because what I wanna do at this point in my development cycle is I just wanna use whatever's current, right? Because it's a new project, so I'm just gonna, you know, do whatever it is the default is. So I just install those things, you know, create React app as a generator, you know, Node Mod is a development monitoring for Node.js. And so the only important part here really is just that, you know, it launches all this stuff. But going back over to the actual Vagrant image, sorry, thought I did this earlier. So I have a little shell script here that will launch our database, but it does it using Docker. And I'm sorry, Dan, but until I have fully rootless containers, I didn't really wanna run all of it as root. But basically I run MongoDB, and then I run basically this little admin tool that shows you what's inside Mongo. And we can, can't get out of less even. So normally I would actually launch, you know, that way but I'm just gonna cheat. And so we already have it running so that we don't have to worry about Wi-Fi. All right, so now we have, in theory, you know, the Mongo and the admin Mongo. All right, so that's great. And then we, you know, then go on to kind of, so we've now kind of finished developing our server application, which is back here. So that's great. Okay, we have a little server application and, you know, we've got data in the database or whatever, but now we wanna stick that, say, in a container. And so what I wanna point out here is, you know, it's just kind of a normal container. You know, you do all the normal things that you would do with it is just, you know, I'm printing out the node version so that we could, so I can make sure it was working correctly, which you wouldn't normally do. But the key line here is line two, which we're gonna talk about in a minute, but that's where I'm changing defaults. And so that's just for a second later. But so I run the Docker container of my little server, which again, I'm going to cheat and we're just gonna say, and then we can see that, in theory. So we have the admin that will hopefully, oh, come on, really? Sorry, I thought I checked this beforehand. Cross your fingers. Okay, and so I obviously set this up a little bit beforehand and, you know, so I have a bunch of restaurants in there. And now I have my server side running, but I'm now gonna launch the client side so that I can hit, well, you know, the website so that I can hit it. And it is in here. I did not put this in a container because I didn't think it was really relevant, but now we have our awesome React application. And you can tell I'm definitely a UX guy. And so, you know, we pick our favorite restaurant. So OP for Bruno, lots of good beer. And then we can register the restaurant and then, assuming the demo gods favor us, it will show up over here. Hey, look at that, it worked. All right, so awesome, right? Brilliant application. But this is where it starts to get more interesting and we start talking about modules. Thank you. Is that we can now take our Docker file and the way the module is selected, right? So normally what I would do is I can actually say, you know, DNF install, you know, Node.js colon eight, right? And it'll give me, it will not only give me the Node.js eight binaries, but it'll also stick that stream, right? So it will not upgrade to 10 or 11 until I tell it to, which is kind of the cool idea. But in a Docker file, I don't want to do that, right? What I want to do is say, DNF install Node.js, right? I don't want to have to indicate what version it is, if what I want to do is test it against multiple versions. So instead what I can do is modify the defaults. So we can actually go create a file and we call it a YAML file that is just, you know, the Node.js and then what we do here is we say that the default stream is wrong, but whatever. So the default stream is 10. And so now anytime anybody asks for Node.js, they're actually gonna get the stream of 10. Or we do the same thing with this 11 file. And so now I have a fun little shell script because, you know, everything's better with shell scripts that does my build, right? And so based on the shell choice, I can say, let's make sure we're in the right directory. And then I can say build, you know, eight, right? And now if you notice right here, oh it's using the cache, it didn't run the Node.js version. But the point being is now I can just launch this guy instead, and if you see I have them all running already to make my life a little easier, but I can say Docker, stop with the Node.js of eight, which is five, three, D. And instead I can start the 10. Oh my God, let's take this along. And then I can basically run my tests against 10, right? And so you can easily see how I could put this into, oops, I could put this into like a CI system, right? Or I can do manual testing or whatever. But the point being is that now it continues to work because I use very simple Node.js, but now it's running against the 10 version and all the things still work. And that was basically what I wanted to show you guys. Let's see if this actually works, of course not. But it worked in prep, so I promise. So that's basically all there is to it, right? As a developer, I can just say, I can either choose to install something different, so let's say I'm working on an older application on a new vagrant image, or I can just insert new defaults, and I just wanted to show you like, you just have to kind of make sure you get the syntax correct, which I ran into a bunch. And then you can kind of say, hey, look, this is the default, and then I can inject that, and I can keep all the rest of my commands exactly the same, which is one of the things that stresses me out about things like shell scripts, et cetera, is that if I can't keep as much as possible the same, there's chances that I'm gonna introduce errors by just typo or whatever. So I think it's really important that you can just kind of inject it in there. So I think we're almost out of time, but anybody have any questions? Oh, sorry, I was totally looking over there. Go ahead, almost nothing. So the question was, what's the difference between a module and just another repository? Well, so on the face of it, nothing. In essence, though, because we can actually put them all in one repository, we can essentially have unlimited modules and streams, whereas if you have to have a repository per module or per stream, really, that just is gonna get really unwieldy very fast. So right now, I think Fedora has 20 streams or something, so that'd be 20 new repositories. And I think REL 8 has 20 or 30 as well. So the fact that we can virtualize them into one repository means it's simpler for maintenance, it's simpler for like CDNs, all that stuff. Go ahead, Gallagher. So Stephen Gallagher makes the point that it also makes it more discoverable if all of the arbitrary repos aren't in arbitrary repos. So if all the modules are in one repo, you can just do DNF search and it will find all the options that you have, right? Right, and so the other challenge that you might have that Stephen Tweedy says is that if it's all in one repository, then you don't have to worry about making sure dependency resolution happens across all the different module repositories, because in theory, you might have to have all 1000, all enabled, because there could be a dependency resolution across any of those. Did you have a question yourself? So the question is why did I change the defaults to modify what module stream I'm using, right? So, because I could very easily say DNF install, Node.js, actually, why don't we do this? So DNF install, Node.js, this is gonna take forever, right? And that's how I get a different stream. The reason is, is because I don't wanna modify my Docker file. So another way to do, another way to solve the same problem is by injecting what module stream is enabled. So let me see, this probably isn't worth seeing. So in other words, in here, I can actually go look and see that there should be a Node.js one. No, it's because Node.js also has, still has a non-modular version. That's why. So, sorry, but the demo failed there. But so Node.js actually ships a non-modular version right now in Fedora, as well as the modular versions. And so when I did on the vagrant image, just DNF install Node.js, I actually got a non-modular version. Otherwise, it would have a YAML file right here that said, Node.js, and inside it, it would say, this is the stream we're following. Yes, sir. Mr. Dan Walsh asks, when will Fedora drop the non-modular versions of software? The idea is that we would like to get a fully modular world at some point, but we don't wanna force people into it. So we need to continue to have good, we need to have good exciting opportunities for why people would wanna use modules and then have people bring them over, as well as until relatively recently, the work involved in creating a module is way higher than it needs to be. So it could be much simpler. And so once we get those tool chains in place, I think it'll also get a lot easier. Yes, sir. Okay, so for the specific case of Node.js itself, it's because the maintainer has not yet decided to drop the non-modular version. Who is that guy right there? So just to repeat the question for the videos, just specifically we don't have the infrastructure in place in Fedora to build non-modular things against modules. And so until we can do that, we don't wanna drop the non-modular version of Node.js. And I think that's time. Yes, sir. We are running out of time, yeah. Thank you very much, Lenin. Yeah.