KDE on FreeBSD
Groot, Adriaan de
The state of KDE (the Plasma desktop and applications) on FreeBSD, what works, what needs better support lower in the stack. How do we get rid of HAL?
 I really appreciate that everyone's here. Hi, I'm Adrian. 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 KDE that give you useful desktop integration, useful extensions to KDE. 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, but glimpse. 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, but sorry? 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'm 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, Raphael, 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 at 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, but 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++ metab 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? 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. That's where our shared stack comes in. 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. Hi. The sharks are over there. 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. KDE is a very popular platform. 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. 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. There really is no difference. 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 whole list, or 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. 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. User management doesn't quite work, but how many of us actually do user management from a graphical user interface? Ooh, ooh. Okay, so you're our test user next time. If you don't use KDE, you can be GNOME's test user. Oh, 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, for BSDISCs, comes back in, and ejecting CDs. 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? 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. 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 codebase, 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. That's why we have a package message saying, turn on HAL. You can, of course, just use the eject command. That's what I do. I switch the terminal, type in eject. I suppose we could. You can do a lot of stupid things in.desktop files. 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. Yes, it works. It also feels a bit cludgy. That's why ejecting a CD from the desktop still needs HAL, and we're going to fix that. We're going to fix that together with GNOME because GNOME also has some remaining HAL dependencies. BSDISKS 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. We can use the Linux code, unmodified, and deal with the API it provides. 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. That means that we have shared efforts in getting stuff done. We need to fix up BSDISKS 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 free BSD 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. Happiness is in the future. As always, the last 5% of the talk takes 5 minutes. The last little bits always take the longest. We've got to find work, find function in KDE desktop plus all the KDE applications, but getting this polishing done takes a long time. It takes a lot of coordination. Just finding it, 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. I like the way you think. 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. 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? More comments. I just want to show my appreciation for you, using Glimpse instead of new image initiation program, because my friends are the maintainers. So more of a question than a question, you should be eaten by monsters for commenting instead of questioning. Thank you for using Glimpse. 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 is just fine. I run two quad HD displays off of that, and it's fine. Do you use watching videos, Netflix, that's all proprietary? 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. No more questions than we're done. 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 that 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. We've got four minutes to the next one.
 I really appreciate that everyone's here. Hi, I'm Adrian. 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  KDE that give you useful desktop integration, useful extensions to KDE. 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,  but glimpse. 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, but sorry? 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'm 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, Raphael,  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 at 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, but 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++ metab 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? 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.  That's where our shared stack comes in. 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. Hi. The sharks are over there. 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. KDE is a  very popular platform. 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. 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. There really is  no difference. 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 whole list, or 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. 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. User management doesn't quite  work, but how many of us actually do user management from a graphical user interface?  Ooh, ooh. Okay, so you're our test user next time. If you don't use KDE, you can be GNOME's  test user. Oh, 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, for BSDISCs, comes back in, and ejecting CDs. 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? 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. 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 codebase, 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. That's why we have a package message saying, turn  on HAL. You can, of course, just use the eject command. That's what I do.  I switch the terminal, type in eject. I suppose we could. You can do a lot of stupid things  in.desktop files. 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. Yes, it works.  It also feels a bit cludgy. That's why ejecting a CD from the desktop still needs HAL, and  we're going to fix that. We're going to fix that together with GNOME because GNOME also  has some remaining HAL dependencies. BSDISKS 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. We can use the Linux code, unmodified, and deal with the API it  provides. 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. That means that we have shared efforts  in getting stuff done. We need to fix up BSDISKS 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 free BSD 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. Happiness is in the future. As always, the last 5% of the talk  takes 5 minutes. The last little bits always take the longest. We've got to find work,  find function in KDE desktop plus all the KDE applications, but getting this polishing  done takes a long time. It takes a lot of coordination. Just finding it, 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. I like the way you think. 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. 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?  More comments. I just want to show my appreciation for you, using Glimpse instead of new image  initiation program, because my friends are the maintainers.  So more of a question than a question, you should be eaten by monsters for commenting  instead of questioning. Thank you for using Glimpse. 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 is just fine. I run two quad HD displays off  of that, and it's fine.  Do you use watching videos, Netflix, that's all proprietary?  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.  No more questions than we're done.  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 that 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.  We've got four minutes to the next one.
kde_on_freebsd_0_155.png kde_on_freebsd_156_311.png kde_on_freebsd_312_2675.png kde_on_freebsd_2676_5651.png kde_on_freebsd_5652_11627.png kde_on_freebsd_11628_12047.png kde_on_freebsd_12048_12407.png kde_on_freebsd_12408_12707.png kde_on_freebsd_12708_19607.png kde_on_freebsd_19608_19691.png kde_on_freebsd_19692_20075.png kde_on_freebsd_20076_21671.png kde_on_freebsd_21672_21911.png kde_on_freebsd_21912_22271.png kde_on_freebsd_22272_22955.png kde_on_freebsd_22956_23003.png kde_on_freebsd_23004_23051.png kde_on_freebsd_23052_23111.png kde_on_freebsd_23112_23234.png
I really appreciate that everyone's here. Hi, I'm Adrian. 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 KDE that give you useful desktop integration, useful extensions to KDE. 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, but glimpse. 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, but sorry? 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'm 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, Raphael, 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 at 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, but 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++ metab 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? 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. That's where our shared stack comes in. 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. Hi. The sharks are over there. 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. KDE is a very popular platform. 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. 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. There really is no difference. 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 whole list, or 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. 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. User management doesn't quite work, but how many of us actually do user management from a graphical user interface? Ooh, ooh. Okay, so you're our test user next time. If you don't use KDE, you can be GNOME's test user. Oh, 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, for BSDISCs, comes back in, and ejecting CDs. 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? 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. 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 codebase, 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. That's why we have a package message saying, turn on HAL. You can, of course, just use the eject command. That's what I do. I switch the terminal, type in eject. I suppose we could. You can do a lot of stupid things in.desktop files. 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. Yes, it works. It also feels a bit cludgy. That's why ejecting a CD from the desktop still needs HAL, and we're going to fix that. We're going to fix that together with GNOME because GNOME also has some remaining HAL dependencies. BSDISKS 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. We can use the Linux code, unmodified, and deal with the API it provides. 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. That means that we have shared efforts in getting stuff done. We need to fix up BSDISKS 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 free BSD 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. Happiness is in the future. As always, the last 5% of the talk takes 5 minutes. The last little bits always take the longest. We've got to find work, find function in KDE desktop plus all the KDE applications, but getting this polishing done takes a long time. It takes a lot of coordination. Just finding it, 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. I like the way you think. 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. 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? More comments. I just want to show my appreciation for you, using Glimpse instead of new image initiation program, because my friends are the maintainers. So more of a question than a question, you should be eaten by monsters for commenting instead of questioning. Thank you for using Glimpse. 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 is just fine. I run two quad HD displays off of that, and it's fine. Do you use watching videos, Netflix, that's all proprietary? 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. No more questions than we're done. 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 that 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. We've got four minutes to the next one.
applications. The applications range from the how we do KDE on the desktop, but sorry? Oh, FreeBSD team maintains the KDE FreeBSD stack, in the case of freeBSD, you get CFS snapshots and