 I really appreciate that everyone's here. Hi, I'm Adrienne. I'm going to talk about KDE on FreeBSD. And I would like to remind you beforehand that KDE is a community. People talk about it like it's software, but KDE is a community. And we make a bunch of software. Some of it is called KDE Frameworks. That's 80 some-odd libraries that build on top of Qt that give you useful desktop integration, useful extensions to Qt. It also builds KDE Plasma, which is the desktop part that everybody always thinks about. It also builds KDE Applications. The applications range from the simplistic color paint type applications to advanced video editors. But as a community, we build a whole lot of software and people call it KDE. There is no KDE 5 except in ports because it had to have a name. And the previous one was called KDE 4. And ports numbering is complicated, so that's why it's called this way. But the software we install is called KDE Frameworks, KDE Plasma, and KDE Applications. And then you run GNOME applications on top of that because some of them are really good, like Glimps. So KDE runs everywhere, right? It runs on laptops and desktops and phones and tablets and things. And even on other operating systems, and none of us care about this list, right? Because we really want to have FreeBSD on the desktop. At least until NetCraft confirms that FreeBSD is on the desktop. So I'm going to talk a little bit about how we do KDE on the desktop. Sorry? It's going off-screen. Oh, yeah. No, that's right. It's supposed to go off-screen. So the three main KDE on FreeBSD people doing the maintenance of the ports is Tobias, myself, and Kai Knobich. Tobias is more on the FreeBSD side. I am slightly more on the KDE side. And Kai is stuck doing Web Engine. And Web Engine is Chromium, and everyone knows that Chromium on FreeBSD is a horrible, horrible thing. Maybe not everyone knows that, but it's 600 patches where you're fighting upstream, and that's no fun at all. So we really appreciate that Kai deals with that. There's a shark over there. You may want to visit the shark. Go ahead. Aside from the main porting team, we've also got Gleb Popov, Loise, Rafael. They all incidentally do porting work or do supporting work. Gleb, ROD, is responsible for BS disks, which is very useful. I'll talk about that briefly later. We also work together with the desktop app group that's recently been founded to bring together all the FreeBSD on the desktop developers as one maintainer group. And about half of it is GNOME. That's why GNOME is at the bottom here. Half cut off. See? I thought about it. Because we work closely together with the GNOME ports maintainers because we have very similar needs. We're trying to produce a nice FreeBSD on the desktop. I'm sure one of them is more shiny than the other, and the other has a green tablecloth. So it doesn't really matter. It's better to work together. The KDE FreeBSD team maintains the KDE FreeBSD stack, which has CMake in there. CMake is a C++ meta build tool. It's used by about a little over 2,000 ports. A lot of C++ code uses CMake nowadays. We maintain that as part of the infrastructure. That means that every time that updates, which is every six weeks, we get to exprun it and deal with a whole lot of old, horrible C++ code that no longer works with the latest CMake. Anyone want to make snide C++ comment? I mean... Yeah, yeah. We maintain IGN, which is an algebra library. Ninja, everyone's favorite build tool, right? Because it's... Ninja in combination with CMake is fine. I wouldn't write that by hand. The reason we maintain Ninja is that we did experiments. Ninja builds KDE software about 10% faster than GNUmake or BSDmake, and we like those 10% because they're long compiles. We maintain Qt, which is the toolkit upon which KDE is founded. We maintain Poplar together with desktop, together with GNOME, because Poplar is a PDF viewing library, and that's used both by events and ocular the KDE application. So that's where our shared stack comes in. And of course, we do the actual KDE frameworks, plasma, and applications. Frameworks releases once a month, plasma every three months, and applications twice a year. The sharks are over there. So we have very regular release cycles. That means an awful lot of rebuilding and X-brunning, and I would like to take a moment to say thank you to Antoine for pushing the button all the time for us on those X-bruns. So KDE is a desktop. The curious thing is, once you get your desktop up and running, you can't see the difference. Actually, if you look real closely, here's an OpenSUSA logo. So that's what it looks like on OpenSUSA. And if I were to switch into FreeBSD and start my desktop, it would look like this, except the little K logo there. I mean, there really is no difference. And so that's the curious thing. In the end, if you're just a plain desktop user, the underlying OS doesn't really matter, except that in the case of FreeBSD, you get CFS snapshots and jails and all the other coolness that you can also run on your system. But from a desktop perspective, it doesn't really matter. Once you've got KDE up and running as a desktop, everything works almost. This is the list that I took from Tobias. User management is one of those things. There's a KDE system settings module where you can do user management, add users, remove users from the system. And of course, we call that user add. And on the Linux world, that's called add user. Or is it the other way around? I can never remember. Everything is horrible. So user management doesn't quite work. But how many of us actually do user management from a graphical user interface? Okay, so you're our test user next time. And if you don't use KDE, you can be GNOME's test user. Great. Power management is one of those things. We've got a long-standing PR about login.conf, the special resource limit configurations that FreeBSD has. Removable devices is a thing, that's where BS disks comes back in, and ejecting CDs. And I'm going to focus on ejecting CDs because I happen to have a CD drive in my workstation. I'm old school. This is an incredible corner case as far as I'm concerned, but it's also one of those things where if you happen to have one, it's important, right? And every person's bug is really important to them and stupid to the developers who don't have the same needs. How does CD ejecting work? Well, SOLID is one of the KDE frameworks, and it deals with hardware. It's an abstraction layer. KDE loves abstraction layers. We have abstraction layers on abstraction layers built on C++. You get the picture. And one of the backends it can use is HAL. HAL is, of course, the hardware abstraction layer, so that's where we get the abstractions upon abstractions thing. The HAL backend on the Linux side in the KDE codebase has been removed entirely, because nobody uses that anymore. They have better things, namely, Udev. Thank you. It's been almost entirely removed for the FreeBSD side except for one little bit, and that's ejecting the CD. So, and that's why we have a package message saying, turn on HAL. You can, of course, just use the eject command. I mean, that's what I do. I switch the terminal, type in eject. I suppose we could. We can do a lot of stupid things in .desktop files, so it would work out, but the actual code is trying to talk to solid, which is trying to talk to its own backend, and we'd have to special, we'd basically rip out HAL and replace it with a C library system, a user local bin eject. Some, yes, it works. It also feels a bit cludgy. So that's why ejecting a CD from .desktop still needs HAL, and we're going to fix that. And we're going to fix that together with GNOME, because GNOME also has some remaining HAL dependencies. So, BS disks is stuff that GLEB has created. It's basically a shim that provides the kind of interface that it provides a Udev type interface that applications can talk to. So we can use the Linux code unmodified and deal with the API it expects. This is a successful approach, because it means that we write code once to provide an API, translate the API to what we do natively, and then once we've got that, all the desktop environments that expect the Linux API can use it. So that means that we have shared efforts in getting stuff done. So we need to fix up BS disks to support ejecting the CD. Again, it's a terrible niche case, but it's got to be done. Once we've done that, we can drop HAL from the freeBSD side of KDE, and from there we can drop about 1,100 lines of code in KDE upstream, and that will make a bunch of people very happy that we no longer have to deal with HAL at all anywhere. So happiness is in the future. But as always, the last 5% of the talk takes 5 minutes. The last little bits are always take the longest. So we've got to find functioning KDE desktop plus all the KDE applications, but getting this polishing done takes a long time. It takes a lot of coordination, and just finding it. I mean, the only reason I'm complaining about CD ejecting is because I have one, and I use that to rip Rick Astley CDs. I kid you not. Yeah, yeah. I like the way you think. So we're connected to many different parts here. We're connected to GNOME where we work together on lots of the infrastructure. We now have desktop apps to unify some of these efforts. Wayland is coming in about 40 minutes, so Rachel will be telling you about Wayland and what's happening there. KDE is also eager to cooperate on that so that we can lift the whole thing into the modern world, and that's sort of the end of my bits. To sum up, KDE runs on free BSD just fine. There's bits and bobs that need work, and we're still cooperating with everyone to get that fixed. Wayland is coming, and we're happy about that. Any more questions? I show my appreciation for you. I refer using Glimps instead of new image maintainers. I see. So more of a question than a... No, more a comment than a question. You should be eaten by monsters for commenting instead of questioning. Thank you for using Glimps. My pleasure. Other questions? One here. Compositing video acceleration, how is that? Compositing video acceleration, how is that? Well, everything goes through OpenGL, and as long as you're using DRM Kmod for Intel, it's just fine. I run two quad HD displays off of that, and it's fine. Does it use watching videos, Netflix? Yeah. I've never tried watching Netflix on my BSD desktop, but DRM might be an issue. Or the NVIDIA proprietary drivers are fine as well. The one time I tried Radeon, things got ugly, but I don't know enough about that. We should talk to graphics people like Nicholas. One more question, then we're done. Last I heard, no one was starting to depend on LoginD. Is that a problem you're also encountering in KDE? The question is whether, depending on LoginD, is a problem. We've got basically the same shim approach as we do with the UDISCs. So we're looking to create the same D-Bus interface that talks to the actual, the real bits behind it. And once we've got that solved, it's solved for everyone. I'm not exactly sure what the state is of that. That was the last question. Thank you for attending. Thank you for paying attention. You've got four minutes to the next one.