 Ladies and gentlemen, next talk, please. Hi, I'm Nia. I'm giving this talk from an experimental displace of running in Wayland on NetBSD. So at least having video output makes it a success to me. So first of all, I have to start out being a bit sad because we have a load of cool, original, fairly unique APIs in NetBSD that have been developed over the years, but not a whole lot of software uses them. And yeah, it's kind of understandable because working with people is absolutely the worst part of open source. I've been given a lot of reasons for why pull requests haven't been accepted and things like that. And there's an increasing attitude that even supporting things like BSD is just too much of a burden and it's holding open source development back. I really don't agree with that for obvious reasons. It's just something that's been coming from a particular camp of people, though. And yeah, and we don't want to write everything ourselves. We don't want to completely reinvent WebKit and NGINX and everything else. Maybe we can make some progress, though, if we talk to the right people and work on the right things. Yeah, hopefully this talk helps. So NetBSD has its own audio API that was originally developed at Sun Microsystems, like a lot of technology that people are excited about these days. They seem to just, a lot of things that the tech community is excited about now seems to be things that were invented at Sun in the late 90s and early 2000s. It's got quite a lot of support in older software, but adoption in your software since Sun died has not been too great. It's a really intuitive, simple API. I had no idea how to read audio code. I read a man page and now I know how to write audio code. Just man for audio if you want to have a look at that. And yeah, you just really need to use either standard file operations because like a lot of the APIs I'll be talking about today, everything is a file. And really, you just use one iOctol to set the parameters of the audio format in a struct and pass it to the kernel. And then the kernel interprets the audio data or gives you back the audio data in the correct format. So yeah, I read a mixer after learning to write audio code. I can probably show it to you if I turn off caps lock. So yeah, this is AOI mixer. You can install that from package source today. It's really available to the binary package as well now, I think. And it has quite a lot of functionality, actually. If you look at the upper classes and everything and there's various different controls because you don't just have standard volume control anymore. Your laptop has a headphone port. It has speakers. If you have a desktop, it has lots of different ports and you need to be able to control them independently if you want to be doing anything but basic tasks. So that allows you to do that. And there was nothing really that existed that met those needs that I had at the time. And this work then led me to Firefox because audio in Firefox was a complete mess. Let's put it that way. It was a complete mess on all of the BSDs really until SoundIO came along. There's an unofficial OSS backend that was using NetBSD's emulation of OSS, which is the old sound system that Linux used to use. Like in the early 2000s, before ALSA was invented, then Pulse Audio was invented and I'm sure someone at Red Hat is working on reinventing Pulse Audio currently. And yeah, it's been deleted from 3BSD already because it was full of bugs. We've deleted it now too. Nobody likes writing or using emulation lasers or shims. I really do not want to spend my life making sure we are bug for bug compatible with Linux. I cannot stress that enough. Yeah, and Pulse Audio was the option promoted by Mozilla for it to meet everyone's needs, but it's kind of controversial. A lot of our users don't really like it for various reasons. It works, but you don't really need it. We do audio mixing in the kernel, yeah. And Neurotech just necessitated that we do this because I wanted to be able to attend work meetings on my NetBSD machine. And to do that, I needed WebRTC and we had no way to record from microphones using the OSS back end. So now we have full device selection and a working OSS, sorry, a working son audio driver for Firefox. Yeah, and it's a lot more advanced than the OSS back end and supports various of these features, like allowing for higher quality audio or allowing for surround sound, allowing you to use USB microphones and things like that because, well, I had a USB microphone, I wanted to use it. And yeah, the Mozilla's media team was really nice and helpful. They were less nice and helpful. Well, the team of Mozilla that was less nice and helpful was their legal team, who threatened to sue me for wanting to call our builds Firefox. And yeah, all of this was done in C because the Mozilla Audio Library is maintained separately from Firefox. It's maintained on GitHub. The maintainers were really nice to me and yeah, I don't know Rust. I don't see the point of writing this in Rust because it's just talking to a C kernel API really. And that brought me another thing I have been kind of obsessing over recently is randomness and security and random number generation. And all of the BSDs had this API for many, many years called Kern A-Rand that you ask for access through to CTL. It has all the advantages that the newer APIs have. You don't need to open a file descriptor like dev random so it can be done at low level. It's just an endless stream of highly secure random data that never blocks. And there's only a couple of disadvantages just because of historical reasons we just can't read more than 256 bytes per system call. I think that's fine. That's enough to seed a random number generator. And it's not fashionable anymore because the Linux people decided to invent much fancier random number Cisco, Cisco's after there was some drama. And but I was just amazed that this API has been around for so long but so little software used it. Like all of the BSDs had this they've had it since the early 2000s but it only really open SSL was using this nothing else was really. And GnuTLS and LibuV use it now and they accepted accepted my patches and they were very nice and it was very easy to get that done. So thank you very much. It's just results in much simpler less error prone code I think. I think this Cisco has kind of gone out of fashion because people think it's a bit complicated. But this is the entire code in LibuV for getting random number generation on NetBSD. I think it's simple enough. I don't think it's too complicated with all the fits in a slide. And then on ISE there was some drama because Red Hat had just announced that they're deprecating Xorg in Red Hat Enterprise Linux and that kind of had a lot of people in RISC channel panicking. We kind of depend on X11. It's there's not really any alternative on NetBSD or at least there wasn't. And that brought me to how can I fix this? Because most well-encoded is written exclusively for Linux. It's non-modular. It's non-portable. It's just a big blob of Linux kernel API usage. And FreeBSD's solution to this has basically been we're going to implement the Linux kernel APIs. We're going to have a shim around E-Pol. We're going to link this against everything that uses vaguely Linux E-code. I think I've already stated as much that I do not want to spend my life chasing bug-for-bug compatibility with Linux. It's really not something we should be spending on time on because there's so many more important things to be doing. And it kind of feels like it's holding us back just having to constantly chase whatever they're doing, particularly if they're just deciding that, okay, you'd have is deprecated. You have to use dev dev now. Yeah, it's not a fun situation to be in, basically. And it's more of an opportunity than a setback because it allows us to truly differentiate ourselves on all sorts of use cases because if you have a X11 set up with KDA org name, like the guy in the previous talk mentioned, you might as well run Linux because it's just exactly the same. I wanted to develop a complete BSD-specific display server. I haven't really got too far with that yet, but early stages we have this. So because we didn't have support for Linux's input API where I just decided, let's make this use our input API. So again, this is a very old API that's been in the NetBSD kernel for since the late 90s, I think. And it also works around that everything is a file concept. Your keyboard and mouse are just files that the software opens and it reads and interprets the scan codes from the keyboard. And all of the input devices are multiplexed. So if you have multiple keyboards plugged in, they'll all be available through one standard device. But there are additional devices. So if you want your laptop's keyboard to not be usable anymore because it annoys you or something, you have an external one plugged in, you can just sim link the external keyboard to the main keyboard device. And I think that's quite cool to be honest. And most, most well and stuff and even XOrgana is using this library called LibInputs which is developed by the free desktop people. It doesn't understand our input API at all. It seems kind of focused on providing support for the Linux input API. And we were kind of in a tight situation because this locks us out of being able to use a lot of software. I have to shout out for Michael Forney here because he's been very helpful. He developed a library called Simple Wayland Compositor or SWC and I took a knife to it. I ripped out all of the input code. I made and added support for NetBSD's input API. It works. It's fairly well integrated with the system. So it just gets the same keyboard layout and mouse settings as the, as the text console. That previously was not a thing with X. With X you had to set the keyboard layout separately and that was just infinitely annoying. And it fits the security promises that Wayland promotes. The access to the input devices is provided through a privileged process. That privileged process is the only thing that has permission to access those devices. Once the privileged process is created it spawns the actual display server which then spawns the window manager and all of those are running unprivileged. I'm quite happy with this. It's cute. This has taken so much debugging. I've just run into bugs and bugs and bugs. There are still bugs. If I right click right now while giving this talk the display server will crash. I've been kind of worried about that. That's been my main worry. But it works well enough. I have working OpenGL. I have working web browser. This is kind of usable. It's kind of like DWM if any of you have used DWM. And yet you can go ahead and install this and use it on that PSD right now. If you're running nine. Which I don't think has been formally released yet but a lot of us are running it like it has been formally released yet because it's basically completely stable. Yeah. It's still quite buggy and unstable but it meets basic needs which for most people who are developers and running weird operating systems you probably want a few terminals. You probably want a web browser. You want something to play videos with. That's all available. And there's like say if you want to play some games. This works. I'm pretty nervous about closing that because in my experience when I close things sometimes it decides to crash. Sometimes it doesn't. And you just need a supported Intel GPU really and that's up to KB Lake in nine which isn't that great. We could be moving things forward from that. I've experimented with running this on my Rodeon desktop. It worked for a few seconds. But that drive is kind of deprecated and we need to be moving forward with AMD GPU. But again we're relying on porting code from the Linux kernel and this is just hell. Nobody wants to be doing this. You have to take months off work to do this. But you know this laptop's fine. So we have basically a full set of applications working. WebKit GTK. So if you like if you like web browsers like Midori that they run fine. A lot of net BSD people are weird and like things like NetSurf and Vimby and those all work too. And most of XFCE works but obviously not the full thing because XFCE relies on X11 for a lot of the a lot of its window management functions and so on. So and Qt5. I haven't tried much of KDE because we don't have much of KDE. I've been working on getting us up to scratch with some known free stuff but it's not really what I want to spend my life doing. I don't care about no. And SDL2 which is the most important thing for me because it means you can play Dungeon Crawl Stone Soup. I mean, what else do you need a computer for, right? And what doesn't work is a lot of things. Any X11 application is kind of stuck right now because we need the Glamour Xorg driver system. We kind of don't. I've kind of been hoping someone else will do that so I don't have to. I'm looking at someone specific in the audience. And screen locking and screen brightness through Xorg, you've generally handled this with a program like S-Loc or X-Loc or anything else that you might like to like a screensaver program but with Wayland, it's not really a standardised part of the protocol I believe so it'll have to be integrated into the display server. I do not agree with a lot of these design decisions that involve a lot of things being integrated into the display server. I think it means that we're gonna have to end up redoing lots of work. Maybe it'll be worth it in the end, I don't know. But this is the general model that people have decided to go down. We're kind of moving away from modularity and integrating things into the server more. And screen brightness, this is actually a problem with my ThinkPad that I've been working on. We need to centralise way to manage screen brightness because usually you rely on X-Rander for that. And if you're running Wayland, obviously you don't have X-Rander. And again, NPSD people are weird and they like to do things like run a web browser in the frame buffer or run ML term in the frame buffer. So if you wanna run frame buffer applications, we should be able to do that with them too. And Firefox is a whole can of worms because it's using a lot of weird APIs and functionality and I can try to run it and give an example of that and since apparently I have tons of time. Okay, so that's one problem, I believe. Okay, let's look at my own documentation. I'm sure I've written about how to do this. The environment for real? Yeah. Marks 21? Yeah, well that sounds about right. Yeah, pretty much. Pretty much. I'm not using ZFS. I don't think hardware acceleration even works in Firefox. I don't think I have to worry about it being turned on. Yeah, pretty much I wasn't expecting to finish this quickly. Okay, does anyone have any questions? Anyone wants a DPI? High DPI support. Technically, this laptop is kind of, everything's a bit small, but I have some documentation that I can bring up. Say, I have a repository on GitHub called Package Source Wayland if you want to have a look at that and it describes a lot of settings that you can tweak. Yeah, see, I've documented how to run Firefox here and I've probably forgotten how to do it. If you have a high DPI screen you can just use these environment variables and that will scale individual QT and GTK applications. That's currently not how we're supposed to be doing it, I think, there's some kind of protocol by which you negotiate a high DPI display but it has to be handled by the display server and I have honestly no idea how that works. It's something I need to investigate. I'm just kind of sitting here. Debugging Greatland Protocol code is hell. I would not want anyone to be put through this. I spent months just inserting printfs into random parts of the networking code that's doing this awful shared memory stuff, crashing constantly and just generally not working, but I found that the best way to debug Greatland code is just to fucking rewrite it. Any other questions? Yeah? I'm not part of the Illumos people over in Berlin, so... I'm not part of the Illumos people, I just think they're really cool. I am. Yeah, okay, yeah. You're really cool. Yeah. They suffer from... Yeah. Have you checked with the open Indiana people? I talked to some Illumos people at PackageSourceCon about a year ago and we were just discussing the Solaris Audio APIs since it came up and we have a lot of extensions to the Solaris API and we were discussing getting them merged in to Illumos just so that more functionality is available, like proper device selection with easily principle names. That would be really nice to have across everything that is still sharing this API, I think. I haven't discussed with them much other stuff because whenever I talk to them about desktop support, they're like, yeah, I might know a guy who has a laptop but he needs three other laptops because half of the hardware's unsupported. Well, you should try and find them. Yeah. Yeah. I mean, I care about these things for entirely selfish reasons. I have a laptop. I wanted to run an MPSD. I wanted to run an MPSD well. Yeah. But I've been putting in effort to make sure if I write code that is using an API that is shared with Solaris, I make an effort to read the Illumos documentation and just kind of hope that it works. I can't test it myself. I just hope that it works. Can you repeat the question? Sorry. Oh, yeah, I'm sorry. So you said, is there any MPSD specific? Yeah, can you use any NETDIs? I don't know honestly. As far as I know, WS-Cons originated at MPSD and that's the only documentation I've been consulting. If people want to port things that I've been working on, I would advise them to do it the way I've done and just create a new file write your code, try to integrate it with the existing system, try to make it modular. Just this is, there's good and bad ways to do portability. And I think part of the problem why people are so put off supporting MPSD is they just think, oh, I'm going to have to add a load of if def crap to my code base. And that shouldn't be the case. You should be able to have modular support for things like this and keep it nice and clean and keep it nice and separate. Anything else? Sir Van? Yeah. Screen savers. So screen savers, if you actually want to deny inputs to the rest of the system, an individual Wayland application cannot do that. It cannot get complete sole control over whether inputs or input is passed to other applications because that was like a conscious security decision they made. But they also haven't developed a real protocol for handling this, I don't believe. So you can have a screen saver, but all it will do is stop your CRT from burning in. It won't provide any kind of security from people taking your laptop and posting silly messages on ISE, which I'm sure never happened to me. Like that's my main use for screen locking, personally. Okay. So basically the idea is that everything is becoming increasingly platformized. You might have got that hint from the previous talk. Goanmen KDE have gone in a direction where everything is becoming increasingly integrated and part of the whole system. That's not really something that interests me as someone who likes lightweight window managers and things like that. And yeah, I don't want to deal with that mess. Hey. It's related to the talk itself, but this is the first thing I heard about deprecation of XOR within Red Hat Enterprise or Red Hat in general. Yeah. I also like DWM or smaller ones, particularly X-Mona, but there are all of these which aren't going to be able to be ported to Wayland. Isn't that also a problem they'll have on the Linux side? I mean, yeah, it's something that people are mad about. It shouldn't affect you unless you use Red Hat, really. Most of the XOR maintenance is actually done these days by Alan Coopersmith, who works at Oracle on Solaris. I imagine he'll keep doing that for the time being, at least until Oracle discovers where he's hiding in the basement. And... Please don't forget to repeat the question for the people who are streaming that may have no idea. Yeah. Sorry. That's just about the fate of lightweight when the manager is if XOR is being deprecated. I... A lot of, for example, X-Mona that I know about, DWM is probably small enough to just be rewritten. Well, no, because you have to do a lot more to write a Wayland compositor. You have to implement a lot... You do more... Wayland compositors do a lot more than just manage windows. I'm kind of going into the next person's talk, who they're going to talk about for a bit, and I don't really want to tread on... So, it's not so simple as you can just re-write a simple lightweight window manager to use Wayland. You're going to have to figure out how it's going to manage the screens, manage all the accelerated windows, and manage a blitzing and things like that, and input, output. It's going to need to support multiple OSs. You're going to need to figure out how you're going to do that. The solution that people... that is increasingly emerging is there's libraries like SWC that allow you to do less work, but we're still going to have to improve those if we want to keep this kind of system usable with moving forward. Yeah, anything else? Small present from the staff room. It's good news. Oh, yeah. Thanks to all the shock people and the girls who showed up to listen to my talk for emotional support. I appreciate it very much.