 At the end, I'm also going to speak about what are we considering to do for the next major release, since we are practically feature-complete for network manager 1.2. We're essentially just ironing the wrinkles. So what's network manager? Why do we need it? When I asked my package manager what's in the network manager package, it says it configures some variety of network hardware on even virtual networks. It supports some server hardware, some desktop hardware, mobile hardware, connects to VPNs. That's nice, but actually why do we really need network manager? There already are APIs in kernel to configure the addressing and the routing. And most network hardware comes with some sort of user space utility to configure it. Well, there's WPA applicants to configure the access points. And there's a network model manager to configure the mobile broadband devices. And well, most of the VPN solution comes with some sort of utility to set up the tunnel for you. So why do we really need network manager when there's already tools to achieve all of this? And the thing is that there are APIs and utilities to do all this configuration management. We see that as part of a problem, not another solution when what the user actually wants is something like this. They don't really care about the details of the underlying or perhaps wants this where it gets complex. And they don't really want to care about the details like what model of a modem did they have or what particular protocol with what settings it's used by the VPN solution. So what we're doing is that we're wiring things up for the user so that they just care about this. So we provide a Diba service that provides a consistent access to whatever networking solutions that the user have. And we provide this Diba's API that other schools could build on, such as the desktop environments, the KDE known, they build on top of it. Also on servers, we do provide the client utility that called NMCLI that provides an interface to the functionality we offer. What we also do is that in our picture, the network configuration is really dynamic. It changes and we need to react to those changes. Say, when we get out of reach of a Wi-Fi access point, we might want to tear down the configuration for that particular network and move the route to another network connection, mobile broadband, that still works. Or we want to apply certain configuration when the user plugs in a network cable. So that's what we do. We sort of glue these things together. And apart from the Diba interface, we provide for the programmers to build on their thing on. We do provide something called the dispatcher interface where the user could just copy their shell scripts and they run when some network change happens. In a consistent way, you can have a dispatcher script that runs when you connect to a VPN to do some particular action or when you say disconnect from a Wi-Fi network, no matter what the actual hardware or the actual connection is to provide the consistent interface. So yeah, this is what it looks like when the desktop environment uses our API with seeds. It's sort of similar to the switches I've had in the previous slides. This is what the user typically wants to see when they manage their network on a desktop. So where do we stand now? With Network Manager 1.2, we are very close to the release. We haven't done a major release in over one year. We've done 10 minor releases in last year. And those minor releases were actually not that minor. We backported a lot of functionality into the stable branch. So most of the stuff we've worked on, it's already shipped to the user. But what we couldn't do in the stable branch is do any major refectorings, major changes. So we have them in the branch soon to be released. And as you see, the number of the commit is quite high. We got almost 3,000 commits waiting for release in the 1.2 branch. So what did we really change? What's new? This. The short answer is a lot. And the long answer is actually a lot. And this actually is the stuff that's not a complete change log. We omitted here the stuff that's already backported to 1.0. So let me just briefly talk about the highlights of this digit. So what we're serious about is cutting things away from our dependency chain, because people like to run network manager in networks, notably in many scenarios. And a lot of these scenarios involve doing as minimal installation as possible. That's when it comes to consumption of resources such as memory, but also the dependencies we drag in. We didn't actually improve the memory consumption significantly in 1.2. We have some things planned for 1.4, but we didn't manage to do that. But what we did is that we got rid of some of the dependencies. You can see that for link local addresses, we actually started to use the systemd networkd-based library so that we don't need to drag in an external tool. And for the hostname management, we also offloaded to systemd. So there's more of these to come, like the stuff that's taken well care of by systemd. We're just going to distribute away from network manager. We also, the D-Bus glib thing is notable that it was a huge refactoring, like those of you familiar with glib know that glib already provides a D-Bus client library for some time, G-D-Bus. Network manager predates this library by many years. So we weren't really able to use it, but now we did a complete refactor of all D-Bus-facing code to use it so we could get rid of this legacy dependency. It's quite nice because it implements some nice stuff D-Bus provides, such as the object manager that makes the network manager code simpler, more robust in the effect. Also more maintainable because that's the case when you're using more modern interfaces. We've done some improvements in the Wi-Fi area. Notably, we'll be enabling Wi-Fi power save by default. This is a feature contributed by Canonical, who actually does phones that the draw network manager does. Anyone here has a window phone. Those are essentially network manager phones. So improving Wi-Fi as well. WPS-applicant got a bit better lately in managing the Wi-Fi scan list. So instead of using our own custom code to track which networks are available, we just used what WPS-applicant provides now, which is, well, slimming again. The client utility we provide, NMCLI. We had some very nice improvements there. But there are no huge changes there. You probably noticed that we aren't really doing any huge changes in network manager overall because it's a major project. It's a sort of stable feature complete for most users. So we were doing incremental improvements, making the code more maintainable, slimming down, and adding small enhancements mostly. But the last one, the color output, is actually my favorite. It's really, really good. If you're using NMCLI often, then you'll get used to this really, really quickly. And if you're not using NMCLI quickly, then you probably should. It's a really, really nice tool, especially for the users who prefer command line. And I think there's a lot of developers here who are exactly in that crowd that would, when you're connecting to a Wi-Fi, here, you prefer to type it on a command line. It's really easy with NMCLI, which is to NMCLI device Wi-Fi, connect, and name of the network, and you're there. We're doing some improvements in the VPN area as well. You probably know the network manager integrates with virtually any VPN that's actually used. We have the plugin architecture. So we maintain a set of plugins for the most popular VPN, such as OpenVPN, the IPsec, IKE-based, IPsec tunnels. We do support Cisco-compatible and Juniper-compatible networks with OpenConnect. But there's also some community-maintained VPN plugins, such as tunneling through SSH or Iodine, which does VPN over a tunnel over DNS, in case you're in a particularly hostile environment to use that. But the VPN plugins, they are, first, they are standalone D-Bus services. And it used to be difficult to make that plugins connect to more than one VPN at the same time. We fixed this now. So you can run more instances of VPN connections at the same time, which is sort of nice. And there's a lot more. Not sure if I should read this, probably not. But the important points there are that we are... Oh, in the Wi-Fi slide, you probably noticed that we are now turning on the MAC address randomization. For now, it's for scanning for networks. So it protects you from tracking until you actually associate with the Wi-Fi than your actual MAC address is used. We're probably going to even further enhance this in network 1.4. Point is there that we cannot really, by default, use a completely random MAC address, because it would drive certain network operators like nuts. But it seems like there's a way to make sure that when you connect to the same network, your MAC address stays stable. And when you move into another one, that you actually use another randomized one, we're doing something like this already for the IPv6 addresses. You might know that traditionally, the host part of the IPv6 address is derived from your MAC address. And that worries the people who care about tracking. So for network manager 1.2, we implemented RFC 7212, which introduces a way to use a unique host part for each network, but change it when you move to another network. Essentially, it does a cryptographic hash of certain strings that identify the network, such as the subnet, the Wi-Fi SSID, or in the network manager, the identifier of the configuration of the network, and the secret key. So it's not predictable for anyone to predict which host part are you going to use. So it's impossible to track. We're thinking about doing something like this for the MAC addresses in Wi-Fi. So it's not possible to track you when you connect to different networks, but still maintain some stability. When you return to the network, you get the same address. And just pointing it out that we're mostly doing small improvements, but sometimes the small improvements really matter. For the users who care about the privacy, this is the things that we are serious about, that we are improving. Also, a notable feature is that we support creating many more types of creating and management of virtual devices, which is nice for the servers. For the servers, you might know that we already support all typical network devices that are used. We are able to do bridges and VLANs and bonds and teaming. And we are also able to stack it on top. So the network manager is sort of trivial to do VLANs on Ethernet and then bridge it and put it into a bond, if you like, probably. So yeah, this is a rainbow for Rashid who complained that slides seem like they come out of North Korea. It's colorful. With network manager 1.2, as I said, we're very close to the release. We've already done the first beta, which is feature complete API, ABI stable. So if you're building anything on top of network manager, you can and want to make use of the new features we've introduced with 1.2. It's already feature complete. It passes our test suite. And we do have a really, really good test suite. So once it passes, we are fairly confident that nothing really important would break. So you can already try it. You can already build on it. If there are any desktop developers here who might be interested in the features in network manager 1.2, you can try it. When you install Fedora Roheit for some time already, you get all the fairly latest code. So you're encouraged to give it a try and also Dbian experimental pick it up already. Dbian is doing a fairly good job at keeping their network manager up to date. As soon as we release a stable update, they quickly pick it into an unstable distribution. And they have some very rigorous testing in place where they are sort of popular for being good at this. So Dbian is a good distro to try out and up to date network manager as well. And we're doing a final release before Fedora 24. So in the next Fedora, you get a new network manager. What's next? And as for the next release of network manager, which we plan to deliver sometime this year as well, we don't plan to spend another year doing a major milestone. So we're doing some development process adjustments to make this possible. We'll be doing continuous integrations, which we don't have in place yet, so that we get more confidence in our code base. But there's a couple of features we already are considering for the next release. So when you see this list, you probably can add the question mark at the end of each of these entries, because we're not finally decided yet. For network manager 1.2, it's easy. We are feature-complete, but this also is my last slide. And after that, there will be a place for questions. But we are also very open to suggestions about what would you like to see in the next major release. So we'd like to hear from you. So what are our priorities is to make network manager more secure. I said more hardening. For 1.2, we've made use of some feature system deprives to limit the capability set of network manager. And we'd like to reconsider doing some architecture changes to make it more secure. With the P11 kit integration, we'd like to improve the experience when you're using a smart card with a certificate or even GNOME curing in your desktop, so that we could forward the Pkcs11 protocol to the demon and not actually copy the certificates over debas or in files, as we do today, which is going to improve for the users using certificates with Wi-Fi or VPN, so that's going to make life easier. And recently, a page from a community contributor appeared on our mailing list like two days ago with an early complete implementation of what we were considering for some time already, and that's the network namespace support. And it's probably cooler than it looks, because it means that we could actually separate the VPN connection from the actual network connection you have, and you could make sure that no traffic leaves your desktop aside from the VPN, even if the VPN crashes or anything, which is nice for the users who really care about privacy. Or you could do the reverse. Like, you could isolate the VPN tunnel into a separate namespace and maybe move your shell or web browser there, so that you could only use the VPN connection for your, I don't know, corporate traffic, and leave the rest of your desktop just to use your ordinary network connection. So this is, I think, probably the most important thing we could do for the next major release. We're excited about it, and that's where my talk ends. And if you have any question, please ask. There are a couple of more network manager developers in the room, so if I'm not able to ask the question, then they will help me with that. Thank you for your attention. Any questions? Hi, I'm Paolo Autos. I was wondering if you're going to do anything with a hotspot namespace where none of the applications are bothered by DNS lies that you get while you're on a hotspot, and after the hotspot authentication is finished, at only then all the network applications become aware that there is a network. Thank you for the question. So we were actually, there's a group of people that would like to get better DNS support in the Fedora 24, maybe 25, and the isolation of the hotspot, like the capture portal detection there, is really necessary for their machinery to work. So we, like the network manager core team, are actually not currently doing anything about it, but there is a group of people interested in implementing this, like separating the capture portal. The multiple VPNs being supported by network manager sounds awesome. The only thing I'm concerned about is how does network manager handle if you have conflicting IP space ranges? Well, in that case, one connection wins. OK, that's what I figured. I just was wondering if it passed my mom test, because I would love to get her set up on that, but I don't know that she would know what to do. Like, I guess I'm holding it too close or something. All I was just saying is I think if I tried to get this set up for my mom, she probably wouldn't be able to debug it, which is fine. But I probably will tell her not to do multiple VPNs if it's not something that would be represented at like an icon level, where she could see that there was a problem. But awesome. Well, we're actually pretty clever about conflicting routes in the connections. You obviously cannot have two routes to the same network with the same metric and to these different network interfaces, because the kernel would just remove the previous one if you had the new one. But we actually keep track of the routes that should be on the interface internally. So when you turn on two connections and both of them use the same routes, then the first one wins. And you activate the second one. And then you disable the first one. Then the second one gets the routes. It doesn't end up in a state where there would be no routes set up. So we'll probably as clever as we can be about this. Oh, yeah. So my question is for more of the next version. It was 1.4, I think. The namespace support sounds really interesting. So what's the plan, actually, for the user to specify which application should be in which namespace, which connection? Is there some plan for that, some GUI or something? Well, as for network manager 1.4, there's no real plan about anything yet. So we need to figure this out. Obviously, the first thing we'll do is to expose a D-Bus API to the connection we already exposed on a D-Bus API to add an information about the namespace. And then we would need to figure out how to do the desktop integration. Well, we'll probably need to have some API so that the application in the desktop could request some process to be moved to that interface, because it's a privileged operation. But we're not even yet at the drawing table there. So we will be considering this, like, no definite answer. Sounds good. Thanks. Hi. I got a question according to IPv6 sharing, planned in the next version of 1.4. And to the extent of that, is there some plan for having IPv6 addresses, while the host that will be sharing the connection will have only IPv4? So this kind of tunneling and vice versa if I got only IPv6 and then getting to IPv4, this kind of tunneling transition plans? So short answer, no. We're really not considering this. And as I've said, we have no definite plan for the next major release. But this is the sort of thing we'd like to hear. So after the presentation, I'm very likely to add this to a list of things we consider. Thank you for that. Thanks. Hey, what exactly does offloading to system debring to network manager? Like, earlier in network, and doesn't it mean a problem for non-system de-systems? Excuse me, I didn't. What exactly are benefits of offloading to system de some functionality, like system de-network? We do. Well, it makes network manager smaller. Well, the things that we do offload to system de now, obviously, is the hostname support, which really is not our business. We just traditionally do that. And as for other things system de-related, it's more like we are sharing code there. They are using because they actually are doing some pretty amazing things. Like, let's say the DHCP client we do currently use the DHCP client, but we would like to not to do it anymore because DHCP client, believe it or not, its memory footprint is about twice as big as network manager and the code base is of comparable size. And well, it's just the DHCP client. So network seems to have already fixed this by doing their own DHCP implementation, which is considerably less crazy and less historic stuff there. So where we benefit is that we don't really get the user to run this, like, old beast and have the same functionality with much less code, much less overhead. So if that answers your question. What happens if you are on non-system de-system? This doesn't actually depend on the system de-run time. It's a library that runs independently of system de. And for the hostname support, where we run on a system that doesn't have system de, poor souls, we do just do what we did previously for the system, write an ATC hostname and run the hostname command to change the runtime hostname. But we'd really prefer not to do. Any more questions there? So thank you for your attention. And enjoy the rest of the conference. Thank you.