Tech Over Tea - Solving Wayland's Multi Window Problem | Matthias Klumpp

Episode Date: January 12, 2024

I've spoken quite a bit about multi window apps on Wayland and today we have the Matthias Klumpp the man himself who is trying to solve exactly this problem to discuss the journey he's taken to get here. =========Guest Links========== Github: https://github.com/ximion Twitter: https://twitter.com/matxpp Mastodon: https://mastodon.social/@matk Blog: https://blog.tenstral.net/ ==========Support The Show========== ► Patreon: https://www.patreon.com/brodierobertson ► Paypal: https://www.paypal.me/BrodieRobertsonVideo ► Amazon USA: https://amzn.to/3d5gykF ► Other Methods: https://cointr.ee/brodierobertson =========Video Platforms========== 🎥 YouTube: https://www.youtube.com/channel/UCBq5p-xOla8xhnrbhu8AIAg =========Audio Release========= 🎵 RSS: https://anchor.fm/s/149fd51c/podcast/rss 🎵 Apple Podcast:https://podcasts.apple.com/us/podcast/tech-over-tea/id1501727953 🎵 Spotify: https://open.spotify.com/show/3IfFpfzlLo7OPsEnl4gbdM 🎵 Google Podcast: https://www.google.com/podcasts?feed=aHR0cHM6Ly9hbmNob3IuZm0vcy8xNDlmZDUxYy9wb2RjYXN0L3Jzcw== 🎵 Anchor: https://anchor.fm/tech-over-tea ==========Social Media========== 🎤 Discord:https://discord.gg/PkMRVn9 🐦 Twitter: https://twitter.com/TechOverTeaShow 📷 Instagram: https://www.instagram.com/techovertea/ 🌐 Mastodon:https://mastodon.social/web/accounts/1093345 ==========Credits========== 🎨 Channel Art: All my art has was created by Supercozman https://twitter.com/Supercozman https://www.instagram.com/supercozman_draws/ DISCLOSURE: Wherever possible I use referral links, which means if you click one of the links in this video or description and make a purchase we may receive a small commission or other compensation.

Good morning, good day, and good evening. I believe this is episode 201, I want to say. I might be wrong. Could be 202. This will be sometime in January when you guys are seeing this, but it's the start of December, like middle of December for us. Welcome to the show, Matthias Klump. How you doing? Hi, I'm doing well. It's Christmas time, so a bit too much sweets, but not too many sweets, but and lots of research stuff, but the holidays are happening soon, so I'm doing well.

Well, I'm sure it's going to be a bit quieter than it seems like it's been for you as of late like just trying to schedule this has been kind of kind of a chore yeah it's uh sorry for that there's a um there was a lot of stuff happening in the past weeks. I was at a scientific conference and had to prepare a talk for that. I had to write a paper. I had a lot of other things and trouble. And so, yeah, apologies. Also, apologies for the time.

I didn't know. It's fine. It's fine. This is a totally normal time. Anyone who's seen previous episodes are going to know, yes, it is 1.30 a.m. again. I will complain about this when it is the end of the podcast and it is 3.30 a.m. and I'm really tired, but it's fine.

As long as I don't do it for two hours. Why are we doing this? Who are you and what are you doing? Why specifically am I talking to you right now? I think why you are talking to me is because I wrote a Wayland protocol for absolute positioning of windows. If it was one, that would be fine. It's not one, that's the problem. the problem. Well, yeah. I've in the past I'm the current maintainer of AppStream, which is a horrible name to speak. It's AppStream with an A, not a U. It's a metadata format which is kind of foundational for every software center that we have on Linux. I am the involuntary maintainer of package kit, I think, at this point, together with Neil.

And, yeah, I'm a Debian developer for a really long time. At some point, I wrote my own Linux distribution. And I think I'm the first person to have ever been a GNOME Foundation member and KDEV member. So I think the second might actually be Neil. I need to ask him. I think he is now. Has been for a few years. So, yeah, I've done a lot of stuff over the years.

And yeah, I'm also that's maybe also important to say. I'm working for Purism on their PureOS operating system and I've developed it. I know about most of those. I didn't know about that one. Yeah, it's an interesting story. We'll have to get into that one a bit later, but I do want to just mention as a side

thing, this is not intentional, but every, like, other episode, Neil is brought up as a topic. I'm not surprised, actually. Like, no matter what I talk about, it's like, oh, Neil did something here. Like,

every single project, like, if it's at all involved in, like, KDE, desktop stuff, like, you're going to see Neil somewhere. And, like, even, like, the backend stuff, like, outside of that, anything that's, like, cross-desktop, he's gonna show up somewhere. Neil is insane, but in a very good way. It's, like, the most positive i um but it's still insane uh especially since he's like also he has like the strive to improve linux as a whole so he sometimes

also just gets involved with things where he doesn't actually have any stakes in it so it's just like hey let's make it better and i have an opinion about it and it's usually valuable so um yeah i think i think he just i don't know i don't know how he manages his time but he's involved in a lot of stuff i'm not surprised at all that he gets mentioned a lot so before we get sidetracked talking about how great neil is and how how much work he does i'll save that for when i bring him back on the podcast, and then he can talk about whatever nonsense he's been working on since the last time. I bet it's worthwhile.

Let's talk about these protocols first. So before we get into the individual protocols, what is the specific problem that you're trying to solve? And what about the current situation doesn't work as you would like it to? So that's a twofold issue. But yeah, so in science, we have a lot of applications which are designed to be put on different monitors, which are basically a bunch of separate windows which you just arrange on screen. And these applications usually have a pretty good idea where to place those windows initially,

and they currently can't do that on Wayline. So if you have an application which has can't do that on Wayland. So if you have an application which has maybe like 10 windows, they get currently get all stacked on top of each other or the compositor does some weird tiling and doesn't really know where to place things. While the application does and the application could actually tell the compositor, hey this is how it should look like and the compositor could then do the right thing. But currently there's just no way to communicate that. And the second thing is if you have arranged your stuff, it doesn't get saved. You just relaunch your session and stuff just reappears at random positions.

And that's actually worse. There's a separate protocol for this, but it has been basically stuck in development hell for a discussion hell actually for about five years now. I think it's i was is it five now three years on the uh on the pull request but it has been on the mailing list before and i don't know why it's not merged because it's such an important feature for anyone curious that is the xdg session management protocol yes and I thought, yeah, okay. I get the Wayland concept of, like,

let's do it properly, completely from the start. And everything has to be ported. I don't like it necessarily. But it's definitely a valid route to go. And so, it's like, okay, then we just port the apps and, like, ideally, maybe rewrite the GUI and make them, like, okay, then we just port the apps and like ideally maybe rewrite the GUI and make them like work with this new concept. And then I started to actually develop my own scientific application and found that I wanted to make an application where there's one main window

and the smaller windows were placed inside and you could dock them out. But what I realized was that the current concept of like these split window applications actually works best for these particular applications which are like um like spaceship dashboards where i have the buttons upon buttons and like everything visible at the same time they are not user friendly but they're also not for normal users who are just intuitively should be able to grasp what these apps do, but some of them require training and knowledge of what you're doing, what lasers to adjust and stuff like that.

And for those, especially if you have multiple monitors, it's actually the best UI concept, at least that I found and established. So at that point I was like, okay, we actually might need this for new applications. And then I went into, okay, what exists in this space? And what applications do we actually use? And how do we port this stuff to Wayland? Especially because these vendors, they are stretched in any way. And if there is Linux support, it is usually the exception. Most of that stuff is Windows.

And if I come to one of those vendors and say okay please put the wayland that's the future it should run on wayland and but you need to rewrite your whole entire ui to actually work on wayland they would be like no this is like way too much work for like a tiny fraction of our user base and And it's just like way too expensive for us since there's not a ton of money in academic research. So unless there's like a huge company which invests all the money into it, and it's like, yes, we need this on Wayland,

then they might do it. But if like academic labs do it, they are happy if it works somehow. So, and of course you could say, well, this stuff could run on X-Wayland forever, but I don't think that should be the goal. We should be able to move everything to Wayland to also reap the benefits of it. Because believe it or not, we want HDR support for especially microscope images and stuff like that. And Wayland actually has a lot of benefits that we could actually use in science so that's

the science part but of course there's also things like the old gimp ui uh the mpv example that you've mentioned where um mpv might want to place its window in a certain position and all of these like things that used to work which stop working on wayland and where you basically tell people stop working on Wayland and where you basically tell people, well, screw you. It's like, if you want to do this, you can't anymore. And there's no real reason that security base why this shouldn't work. It's just like there's no protocol

and you can't use this UI anymore. And that's a bit frustrating if you're an application developer and then I want to motivate you to port and tell you, yeah, but please rewrite everything so The argument Security wise is often made is regarding

Windows could place themselves on top of other windows and sort of mimic that You know what that is and then try to you you know, mimic a password prompt, for example. Do you feel like that's a reasonable concern? Or do you think that's sort of Wayland Devs running away with a theoretical example that, you know, wouldn't realistically be implementable? I think it's a latter. I did, initially, I was like, oh, yeah, that makes sense. And then I thought about it a bit more. And the reason why I don't think that should work like this on Wayland is no application can grab the screen. So no application can, like, without permission at least.

So the application has, first of all, no idea where that password prompt even would be to place its window on top of it. So since it doesn't know, it can maybe guess to place it there. But then this window, even if it's borderless, will have a shadow. And for the user, it would look absolutely weird. And then I don't think it's a realistic example. It has been brought up before. then I don't think it's a realistic example. It has been brought up before, but I don't think it's a strong case for it.

And the interesting thing is I thought that would have been one of the primary reasons for people to reject the protocol proposal, because I've had some fights with people about this before who raised this point. And so I put a lot of work into the proposal to refute this like from the get-go and it's like no this is not a point you can make and nobody made that point i am like in the in the discussion nobody actually ever raised

this that there was a security concern which was kind of nice because i don't think there is so i didn't have to argue i i think part of it is the that you preempted it maybe it's that they just don't feel like that's a discussion worth having and the other problems they had with it were more important um but it is definitely something i i have heard discussed before. Before we get into the specifics of this protocol, though, if you wanted to write one of these applications for Windows, for Mac OS 4, X11, what would be different about that experience compared to what is available on Wayland now?

Hmm. Like, if I would write for Wayland now, I wouldn't make a multi-window application, because I know it doesn't work, so why should I try? On Windows, I would just go with it. If they are designers, which usually in science there aren't, but maybe in this example they are, they could come up with anything, any kind of style of UI that they want.

And I could say, okay, I can make this happen. On Wayland, a lot of it is semantics. So if the protocols don't support, like put something right, left, top, bottom to someone else, something else, some UI GUI element, if there's like no protocol support for it, it's just an impossible task. So on Wayland you're more confined by what the compositors and what the protocol supports as opposed to on Windows where you can make literally whatever. So I think that would be the primary difference that on Wayland

you currently at least would need to design around the protocol, while on Windows, you would need to design around your idea and your concept that you've come up with for how that GUI should look like. I guess it's the one odd one out on Windows, on Mac OS and on X11, you could just, you know, make these multi-window apps with no issue. Yeah. I think the worst thing, okay. And like, worse, not in like, oh God, but in like, not great. Is that usually like, if you are an app developer, you don't write for Wayland, you write for a toolkit. So, for example, if I want to do cross-platform stuff, I would use Qt as toolkit. And Qt has a lot of functions which wrap neatly around Mac OS and Windows API and X11 API, but not at all around Wayland API. For example, the placement falls apart in certain situations, which is another thing

where this protocol might actually be useful for actually placing other elements on top. And it's also generally, if the API of the toolkit doesn't actually match, what should the toolkit do in that case? Should it just say, oh, error, I can't do this this on wayland in which case you would need to adjust your application to work or should it like try to emulate it somehow so uh to like make it work in most cases but not all cases which is also frustrating for the app developer and then the app developer is like oh

the toolkit is broken on this platform and we we complain about it of the toolkit developers. And they are like, oh, we can't do it because Wayland doesn't give us the capability to actually implement this. So, yeah, I think I don't want to be a toolkit developer. Like, especially not Qt. I think it's easier for GDK because that's like GNOME centric or Linux centric so they can be way less but Qt is like has always been multi-platform and I think that would be or actually I know that this is an issue for Qt developers so yeah it's not no idea. Because like with something like Qt you'd want it to work, obviously

you want to have the ability to write platform-specific code, but you don't want to have everything be platform-specific, and when you have something like, like, so when you have something like Wayland there that's going to be like, okay, well, it works, we can just use the generic code on macOS and on Windows, but then this Wayland thing, which also, you know, being on Linux has a much smaller user base, like, having that be the thing we have to write something specific for it, I could see that being, you know, an area where it just gets left by the wayside, and even if there is an option to do it in this weird way, it's likely going to be ignored unless it is like a specific purpose of that project to be available

under wayland yeah also like some things on wayland are semantics so where you're like have needing context information on what the intent is for example for placement which you don't have from the toolkit so where you would need to basically add it somehow to the toolkit, but what does it do on Windows then if you have like a hint for that for just Wayland? So that's another thing. At the moment, if Qt has a, for Windows has a move to method

where you can just move a window to a position and that currently in the documentation has just the information, works everywhere except wayland so um and i believe on mac os it does have i think it does have a specific thing for mac os where mac os flips the coordinate system yeah i might be thinking about something else but where it has that in the docs, but I know that... No, it's MPV. MPV's geometry option. It says this works everywhere except Weyland.

macOS, for some reason, flips the geometry, so you've got to, like... Yeah, I don't know why. Yes. But... You would think that MPV guys would just correct for that on macOS, it's like if macOS just invert your coordinate system. Yeah, you would think that, but that involves an extra if statement.

So someone's going to- Maybe it's not. Sorry, what was that? So maybe it's not that easy, like it's always nice if you get into a project and say, oh yeah, it's so easy to implement and the people there are like, no, it's not that easy. It's always nice if you get into a project and say, oh, yeah, it's so easy to implement. And the people there are like, no, it's actually not. Yeah, you've experienced that quite a bit. Yeah.

So someone's obviously going to say, well, why not just get rid of... Because it's not a common way to make an application. Why not just stop making these multi-window apps and just make a big window that has a bunch of applets in it like you would see with the modern GIMP UI or a video editor or OBS or anything else like that? Why even bother with the multi-window stuff? Because it works really well for a multi-monitor applications so if you want to have your for example in case of a microscope you might want to have all of your controls on a small monitor and then you want to move your main um uh your main display

to a really good monitor that's larger to the side and you can basically divvy up your ui between your your different monitors and between your workspace so you can basically divvy up your UI between your different monitors and between your workspace. So you can, for example, have a file manager below it and it's very flexible if you have like a ton of controls and a ton of like windows and stuff to show and swing. Well, when you have one window, you can maybe like drag it over multiple monitors. You can maybe undock stuff stuff but then you even need to position those dock windows so same problem kind of um so yeah i think for for this kind of

application it's useful same for uh for stuff like uh the gimp where you might want to move your drawing canvas to a different monitor and then draw on it like if you have a tablet maybe um and have your controls on a different space, or like some diagnostic window in a different space where you can look at the colors of your, or color distribution of your drawing or something like that. So there's like a lot of use cases where this pattern makes sense. I would prefer if applications had an option to have one window mode and split window mode, like GIMP does but um yeah lots of apps are designed that way in the scientific space now someone's also gonna ask about

tilers because tiling window manager I I don't know why it was even brought up as a as a topic in any of the discussion tilers and multi-window apps, just what do you have to say on that matter? Because my opinion on it is tilers, they don't matter. Nothing works properly on a tiler. So just don't even consider it. I use a tiler for the record.

I run awesome WM, but nothing works properly on a tiler. For that I would say, so if you want to use this app you have a computer for it on a in a science lab and you don't use a tiler in that case like or if you want to use gimp and multi window mode you also use a stacking window manager and you don't use the tiling with dimension if you use a tiling window manager you will like either switch stuff to single window mode if they support it or use a different app that fits your style better.

I don't think it has to work everywhere in order to be useful. I think it's fine. Like if you use a tiler, you know what you're getting into. So, and I think you can expect from a user to be prepared for these apps to not work like as intended and i think the apps should also probably be fine with it like the user experience isn't won't be amazing but it's the user's choice the apps will work well on like

most linux most stock linux distributions because I don't know any normal Linux distribution that is actually using a tiling window manager by default. Probably, but... None of the major ones. Ubuntu's GNOME, Fedora's GNOME, Manjaro's KDE, Red Hat's GNOME, most other things are Gnome. Yeah, and if it's not Gnome or KDE it's probably XFC or Cinnamon which are both stacking as well. Yeah, Cinnamon and Cosmic, which is Gnome right now. Oh, one exception. Right now Pop os yeah cosmic so pop os with uh

with their gnome pop shell thing that's that's pretty much the only one yeah i think it might be if you ship an app so if you ship an app to linux um then you can expect a stacking window manager unless the user did something. And I think that's for, especially for commercial vendors, that's kind of what counts. Yeah. Like, you don't want an application to just straight up not work on a tile. Like, I've had some weird Java applications where they just don't even know what to do with, like, resizing a window.

Like, that's a problem in and of itself um that's a bug i would say well no that's them just not designing applications to be at all um like dynamic so it's like it has a set window size it will do nothing else besides that and it'll either just fill the space with nothing or just yeah there there are some there are some applications that don't know what to do with resizing them um but everything else everything else is fine it it will function well enough um so let's actually get into these protocols. So, the very first one, that was 247. So, add EXT placement protocol for output relative window placement preferences. I'll just open it.

Okay. This is a refresher. So, I know what I wrote. So what was your original plan before you found out what Wayland protocol devs are like? So there's a bit of history here, actually. I knew this was a problem for years, and I knew this was going to be a problem.

So, but I'm not, I'm really not a compositor developer and I'm not a, like if I can avoid touching anything that draws a button on screen, I'm really happy. And so I was like, yeah, no, let someone else deal with it. And for sure they will need to deal with it eventually because there is applications which need this and i also thought that um red hot uh since they have customers um which might pay for that would just be like hey we need this like and talk to their representative and just make it happen somehow um this didn't

happen or at least at some point I realized, okay, apparently it doesn't seem to happen. So I've actually talked to some Wayland developers at conferences like FOSDEM and people who are involved. And it's like, hey, why isn't this happening? Like, is there a reason for it? And then the security thing was raised. And I had one like super hot debate

with one compositor and Wayland dev in front of a bar in Brussels and it went on for way too long. And he was like, yeah, there should be a Dbus protocol in the portal where we can just make a Dbus call and then send a window to a position and then send a window to a position so we can basically put permission control on it. And I think, maybe, and then later thought about it and there's a race condition between window creation and window movement, it would be terrible. But yeah, at some point it kind of dawned on me

that this is not gonna happen, even though a lot of people want it and apparently someone needs to like write the protocol and since it's known to be controversial the person who writes the protocol will get like into that discussion and i know i know why people don't want that um so i actually reached out to some friends at KDE and was like, so hey, if I write this, is there actually interest to implement this? Because I can write this protocol and then compositor developers would be like, yeah, no, thanks. We don't need this actually. We don't actually want to implement it. And the response was basically, oh, yes, please. So

basically, oh, yes, please. So not from everybody. But there's not like none of those organizations and free software are monoliths. So you will always have different opinions and also different opinions in the same project like Quinn. Not everybody in Quinn is probably that excited about it. But overall, it was positive feedback. And I've also talked to a few others.

Not GNOME because I kind of knew. But then I was like, okay, it's probably a worthwhile effort to at least make this protocol and see what the response would be. Because so far all of the discussion has been kind of academic. I said, like, what if a protocol existed that did y or x and there wasn't a protocol to actually discuss and I always find it easier to just have something and then chip away on it and improve it and make it into something that is agreeable than to like just discuss in mid-air and it's like oh, if this existed, what would happen?

And nobody knows, and there's no concrete proposal. So that's why I created this. And also, that's why the initial proposal was so incredibly extensive with so many examples, because I knew that it would be controversial. So I was like, OK, if I'm going to do it, I want to make it so that basically all opposition of all the points that I know about are immediately addressed.

And we are not spending all the time to reiterate the same points that have been raised before and that I already know about, which I then have to discuss again and regurgitate that in front of bar discussion again. discuss again and regurgitate that like uh in front of bar discussion again so what you didn't realize is there was a lot of points that you didn't include that were gonna be regurgitated a lot i i actually like it would have been insane if there would have been no discussion and no like new stuff raised yeah for sure yeah i. I've read enough Weyland issue trackers to know that nobody, even the most basic things, nobody can agree on anything. Yeah.

First of all, I'm sorry for you for reading all of this protocol. It's amazing to have someone read it and have it summarized. But yeah, the problem with Wayland, as opposed to a project like GNOME or KDE or something like other, or Debian. Although Debian is actually maybe later about that. But on Debian, for example, we work on like one operating system

and there's like a common ground for it. While on Wayland, there's people from all projects with like completely different UI concepts and also completely different ideas on how to write software even, and how to like develop Wayland and how to, like, develop Wayland, and what is needed and what isn't. So there's such an incredible clash of ideas that everything just takes forever

because you need to find, like, some common ground. Yeah, I brought this up before. Like, if you are a KDE dev, for example, like, everybody is going to agree, we're writing interfaces with Qt. We're writing with C++. You have these fundamentals that you all agree on that nobody's going to argue

like, oh, should KDE stop using Qt? No, no, that's what we do here. Like, this is just part of the project, but when you're a project like Wayland Protocols, you know, the only thing people agree on is we're making protocols, which is a good thing to agree on, but there's a lot of other details there that needs to be worked

on. I think the common ground is we are much better than X11. Yeah, that's a good point. Which, yeah, definitely, for sure. At some point I thought, okay, how bad is it actually? And yeah, it's pretty bad. X11 is a miracle that it even works and that it works this well. But... 30 years of incremental improvements. Oh yeah. Over many, many decades by people. The thing on the Wayland protocols is like what I liked about this

particular one on the placement is that the discussion was actually fairly nice. I've seen much worse. And there was even a somewhat conclusion reached. So Pekka kind of knocked it. And so which is much better. Like my expectation was I'll put this there and it will sit there for three years and nothing will really happen. And I didn't expect it to actually

reach some kind of conclusion, which in this case is not as a core protocol in the XTG namespace, but maybe as an extension for willing compositors. And that would be fine. I think it would become a de facto requirement for anything that's not a tiling window manager. But yeah, I think that is a fine conclusion.

And I think that is a pretty good path forward. I have a different proposal, actually I have two different proposals, but I actually like the newest one. We'll get into those, but we didn't actually touch on how this first one worked. Like what were you, what was the goal? Yeah, how did this protocol achieve the goal you wanted to achieve?

We're already starting to forget words. Okay, this is a good start. Oh, it's really simple. You have your screen and then you just, so an application knows which output is on and it knows the geometry of the output and it can get the scaling factor of it. There's a separate protocol for XTG outputs

which like makes it even easier, which gives you logical pixels and the, so which are like basically scaling aware pixels and the protocol knows like basically piggybacks on top of the XTG output and allows a client to basically send a set position request to a window or with the window and just give it a coordinate on this particular screen.

It's like this output, that position, please. And then the compositor can accept it or reject the request or modify it. So the application doesn't have like absolute control. It's always the compositor which has that last word, but it can basically decide to give a hint on where to place the window. And then the compositor can either follow it or not. So this would be the most straightforward way to port, it would just be a matter of updating to a version of the toolkit that supports the protocol and then basically just using the

same functions you're already using? Yes, there would be no, like every application that works on X11 today would work just fine with this. Because it is actually better than X11 in some ways, because it's like the scaling awareness is better. But in other regards, it's pretty much what X11 already allows you, pretty much the same thing. much what x11 already allows you pretty much the same thing and that was one of the major concerns that was brought up in regards to this protocol it's just what x11 is doing and it seemed like a lot of people were bringing up the fact that we don't want to just do what X11 was doing, maybe there's something better. Maybe there's something different... I don't know if it was better in all cases, it seemed like a lot of it was just, we don't want to do what X11 was doing, let's think of something different.

Yeah, the thing that was brought up a lot was like hypothetical compositors. One argument that I dislike specifically was like, well, what if the screen isn't square? It's like, if the screen isn't square, you have a lot of other problems. So, meh. I do know someone who works on a VR whaling compositor, which that was a concern for them. Yes. But... I think there was like a lot of specialty and hypothetical compositors, like an infinitely scrolling compositor, which on its output, it doesn't have a like length or width, it's just like

basically an infinite space. So the application would get the monitor information and then we'll say like place there. But since it's an infinitely scoring compositor, it's coordinates would be nonsensical with this like outputs attached protocol. Which yeah, I think that's actually a valid concern. If you have like compositors like this

and think they are common or they should be supported and then you have this protocol it wouldn't work with them at all. It would be a pretty big issue. I do have a possi- maybe someone can correct me if this would not work but my idea there is the compositor could use that as more of a placement hint. So rather than having it as the explicit position that it's going to be placed on, take the position as like a relative difference between the windows. So you want to have a window at this coordinate, this coordinate, this coordinate, and instead of taking the exact position it wants to be in shift it to wherever

like that group to wherever makes sense in the context of that scrolling composite if that makes sense what i was saying yeah uh it could do that like it could basically fake screens for every such application um and like give them like mock coordinate systems yeah which is basically what my last protocol does, but way more explicitly, which even might work with tiling window managers. So the last protocol is kind of accommodating for the scrolling compositor case,

and I think it might be better than even what X11 offers today. But yeah, I think even the first one could probably have been made to work with these compositors, but I don't want to devalue the argument that was brought up. It's definitely, I think, one of the strongest arguments against it if you care about the use case of having such a compositor, which I think is also valid. So yeah, for that, like, there's also compositors which don't have a global coordinate system. So

I think those were the strongest arguments. And those also make kind of sense to make Havadeth an X protocol instead of an XTG protocol. Yeah, I was having discussion with the and set up an XTG protocol. Yeah, I was having discussion with the Hyperland dev the other day. Let's see if we can find the comment from him. I brought up your newest protocol and we had a fun back and forth about him complaining about the existence

of global coordinate systems. So what he said was, he gets it just take everything he says with the a grain of salt he says everything in a super sarcastic way um from a so this is in regard to the third one for a uh user perspective it might seem like idiotic hoops but it's just a terrible idea of letting apps position themselves has become ingrained in people's mind and we as wayland devs do not care about what is traditional we want to make shit actually better yeah i would disagree with that um but well not not completely though like making Like making stuff better, pretty good plan. But if making better means breaking all backwards compatibility,

I'm not actually making things better. That's pretty much my point. One thing we didn't bring up with the backwards compatibility is the applications that are not currently being supported. Because it's one thing to say the new applications are going to switch to this model, start making use of this protocol. But if you have an application that is built on an older toolkit, that is never going to be updated to something newer, that is maybe- maybe it still works perfectly fine, but it hasn't been updated in like five years that's the sort of applications that's going to be a real problem for yes uh but then i could see people who are like whenever we make things better on that camp uh and

we like down with the old no backwards compatibility sure uh though people would for sure argue that you could could and should just use X Wayland in that case and I think yeah probably fair I have to remind people every time I talk about anything happening with Wayland, X Wayland is not

going anywhere like when we talk about Xorg going away we're specifically talking about Xorg there are no no one has any when we talk about XOR going away, we're specifically talking about XOR. There are no, no one has any, no one even is even thinking about dropping XWord at this point. Like you have build options to disable in most desktops,

but you don't want to, because you're going to have like some, some random application that needs X11. So like Firefox, for example, has only just recently started enabling Wayland by default. Like this is a really, really new thing. You're going to have random things that still need it.

I know of some people who can't wait to get dropped. I am sure they exist. But in my case, for example, I'm waiting for the Wine team to finish their 50-part series to get um the wayland uh the wayland support built it's it's getting there at some point but like it's not there right now if you want to play a game on on wayland you're playing it through x wayland yeah i'm i wonder how long wine will actually take um because that's not a trivial problem because so if you you have a toolkit like Qt or if you have any Linux toolkit and any actual porting, you can say, okay, we accommodate Wayland by adding extra functions and Windows can add extra hints for Wayland and they could use the Wayland protocol directly.

Wine can't do that. Wine has to basically do exactly what the Windows the windows api says like to the letter and if the protocol doesn't allow it so you have no choice yeah okay i i do not feel for i i don't want to be in that position that's what i'll say i i am glad i am not a wine developer trying to deal with deal with that mess especially as things are evolving. Because it'd be one thing, you know, if we were 30 years into Whalen, everything was all sorted out. No.

No. We're in the middle of things being dealt with. One of the first conferences I went to was the Desktop Summit in 2011. And back then, back then, Quinn maintainer, Martin Gressman, now Martin Flöser, basically told us, we'll be on Wayland in a year. That prediction was so far off.

Matthias also like, don't break the desktop. We should like basically basically ensure everything still works. And he had a really good compatibility plan. But back then, there was a lot more optimism to actually be able to port to Wayland quickly and to get rid of X. And then it kind of became a very, very slow and painful exercise. Yeah, but hey, you know, it's gonna happen, whether people like it or not, because Red Hats, you know, they're like, hey, let's just get rid of this Xorg thing. Now there's a timer.

Now 2025, RHEL's going to completely drop it from the new version. 2032, they completely pull out of Xorg. You know, that... And I can't imagine any of the RHEL devs that are paid to do any sort of maintenance on that are still going to be working on

any little amount that was still being done. Oh hell no. You don't work on X because you love it. You work on it either because you have a specific problem that you really really need to address and you're like oh no I need to like get this fixed somehow or because you're paid. It is not fun. My hope from this is um in when when we had announced that they were doing this they

did say that they think by 2025 this is once again going back to the we'll be on wayland in a year thing they think by 2025 all of the problems are going to be resolved so hopefully um there are some real customers who are very big on the multi-window stuff who start bothering Red Hat, like, hey, we need this problem to be fixed by 2025, please. And maybe, you know. That would be a surefire way, I think, to actually get this moving. The problem there is, I think, first people need to know that this is actually a problem.

So they need to be on Wayland. Yeah, that's true. And they need to experience, oh, no, it's broken. And then they need to go to RHEL and say, please fix it. So I think they first kind of need to be a version that's Wayland only, which has this problem for people to notice. Because not everybody will be up to date on what Wayland is and how it works and stuff like that. And then there also needs to be some pressure which xWayland removes because if a company

can run it on xWayland and it works the the same there's less of a pressure to like even move to wayland if the application is fine and they can save on money on like porting it so um I wonder if this will happen but I think if it would if it happened it would definitely work work as customer interest. So like yeah well, RHEL is freaking expensive but from people who are subscribers and like larger institutions it seems to be that the feedback is actually pretty good and the support seems to be fairly good. I guess people like commenting on it would probably find counter examples but like from from the people I've spoken to they were all pretty happy so they were not like they're like oh we are paying a lot but actually the support's fine

um so I think that would be a way but I I think if it happens, it will happen really late. Yeah. Yeah, it's... Yeah, no, I think you're right there. No matter what happens, there are other problems that are more, like, quickly evident. Like any NVIDIA driver issues, for example, with NVIDIA being such a big thing with compute. for example with nvidia being such a big thing on like with compute um that things like that are going to be a lot more quickly noticeable than than that for sure um and hopefully red hat can put some pressure on a video that would be that would be nice i would expect that to be the first

thing actually that happens uh because the ai space is huge. And unfortunately the Windows subsystem for Linux is like removing a lot of the pressure to actually give developers Linux machines, which I hate, but there's still enough, I think that. And like, if you're doing AI, you are basically running NvidiaVIDIA hardware right now. And I think there is a huge leverage of both, unfortunately of both RATAT and NVIDIA,

but it looks like NVIDIA is actually putting in work to address these problems. And I think until 2025, yeah, maybe, maybe it will be a really smooth experience. That would be nice. Yeah, we have, in our lab, we have an MI100 card from AMD for AI acceleration, which is fine.

It actually works really well and it's really fast. But the Rockham ecosystem is still behind the parts of the office. And there's this huge, basically awesome mind share of lots of tools being written for CUDA. And it's just a lot more work to basically develop for

AMD right now instead of NVIDIA. So, if you want the painless experience, then go for NVIDIA, which we also have. But the instinct accelerator is actually pretty good for anything that uses PyTorch because that just works flawlessly. I just looked at how much an MI100 is, and then I'm gonna go away from that page now. And that is the cheapest one that you can get right now. Yeah, okay. Which is actually the reason why we have it, because it's not that expensive.

So, let's go to your second protocol, the one that you've closed. 249, that is. So, add XTG alignment protocol for window placement control. So, this is the last one that I've personally talked about on my channel. This one... What were you doing differently with this one? This one was basically to address the no global coordinate system argument. So, for this window, you are setting all your coordinates relative to another window.

So you are saying take this as a reference window and then put that other window from the origin of that reference window at the top left, put that at coordinate x, y, like 400, 200 or something to the bottom left or something like that. And that was like for placement, like if there is already a window and for initial window placement, it had a relative system where you could say, please place my initial window

or like place this particular window at the top of the screen left right bottom center and so uh so you have for example for gimp you could say place my initial two bar window at the top uh center of the screen and then you could put position all your other windows in relation to that existing window which i would imagine would require quite a bit of porting effort because that's not the way that applications typically sort of think to work. Yes, it also like kind of enforces a construction order for Windows so you need to make sure that one shows up first, which surprisingly is an issue actually. And it's also way less flexible.

So I was playing a bit with potentially seeing how an implementation would look like and looking at Quinn's code for that because I'm mostly familiar with C++ and have seen Quinn's code before. And like WL roots and sway looked a bit more incredible. It's also, it's not a stacking window manager. And so the problem with that protocol is you still break all backwards compatibility and you still cannot actually

implement all of those cases that the existing applications are able to do. Like for example, with a case of having that scientific app you can't tell it like put it on the second monitor at that position, it just doesn't work like that. You also can't like, okay, that's more a point for the session management protocol, but you can't like save positions and restore positions and put stuff in relation to that. It's basically restricting the ability of the window of the application to position as Windows artificially, breaking backwards compatibility, and kind of solving no issues, really.

It's just basically adding issues and importing issues while not addressing all of the problems. So that is pretty much why I closed it. Because while implementing it, I found that there are so many edge cases where applications wouldn't work and where there would be so much more effort involved to, like not just port it, but to even like make UI concepts continue to work

that had been existing before. So that's why ultimately I don't think that's a great solution. I might go, like, also still breaks tiling window managers. So it doesn't even benefit the tilers. So it's, you basically have a ton of effort for very little gain. So yeah. I did.

Go on. Yeah. I tried an implementation and yeah. I did... Go on. Yeah, I tried an implementation, and yeah, meh. Not fun. I'm not sure if it was from this one or the previous one, but someone brought up the idea of being able to, like, group Windows together and then moving the entire thing as a group, as, like, another idea of how, you know,

applications could be interacted with that a protocol like this could possibly deal with yeah that's the newest protocol kind of um well it was it might be supported in the newest one but it was mentioned by someone in one of the older merge requests which i i would imagine is sort of part of why that was brought up in the new one. I actually like that idea. I don't know what I would use it for, but I'm sure people will find a way. Yeah, I'm sure it would be like a composite, like just having that as like an option in the compositor. You want to like move an entire, you know, you have something set up on one monitor.

You want to move that entire group to another monitor for example like that? I could see that being completely reasonable. Yeah, I could see that to be like actually super useful Like also to move not just between window man windows, but also between work spaces Virtual desktops you can just move a whole cluster of windows from one to another that would be cool. Yeah, I That's one thing actually that would work on a tyler i find myself i i am very heavy on workspace use i don't like having that many things on each workspace so being able to like move you know a group of things somewhere else would certainly be nice but this yeah i am yeah i'm not a piling window manager user but i'm

a really heavy workspace user um that is essential i don't i don't i think i need them but i like to use them because i like to have less stuff on like one screen and then i just switch between yeah yep yep and then you just forget which workspace you have things on and yeah you're like oh i have three web browsers open how did that happen yeah for that i think i only ever have one i say while currently having two open so yeah um i have i have an excuse to have two open i have one open for the jitsy window one open for the things i'm showing on the screen but sometimes it gets a lot worse but like my file manager for example like i'll open a file manager on one workspace check something there and then i forget to close it and i go somewhere else i need a file manager

again i'm like okay open another one then i just have to get it open again. By the end of the day, I don't know how I have so many file managers open. I just forget where all of the other ones were. But, you know. That's a problem I know. And it's especially jarring because Dolphin, the KDE file manager, remembers your last tab configuration. So everything that was open, it restores. Yeah. But of course, we have like multiple windows, it remembers the last window configuration. So everything that was open, it restores. Yeah. But of course, we have multiple windows. It remembers the last window. So whatever I close last, which usually

is a window with some random system directory, it opens the next time. And usually, that's not what I want. I want my previous open projects or something like that. So I have this weird routine now where i make sure to like have one of the my actual configuration that i want to save open last which is uh yeah um probably there's a much easier way to do it like something in kde where you can probably save that session or something. If there's not, I know there's some KDE people that watch this. That sounds like a useful thing. Yeah.

Yeah. But then I would need to have an extra click to save. Yeah, that's true. And I'm so lazy. I don't know if I would actually do it. And KDE has a ton of buttons. So, I'm not sure about this one That's fair Overall, KDE is great. Compared to when I started I've been saying this before but I'm probably gonna be on Plasma when plasma 6 comes out

The devs don't want to use it on plasma 6 because they want it to wait for like an update or two just to iron out any problems because there's going to be some. But I'm probably going to start using Plasma when 6 comes out or a little bit after that if not right at the start. So it's going to say you're going to be an early back reporter.

I'm not doing the... No shot on my touch in the alpha. That's for someone else to do. I'll wait till the full release when most of the problems are dealt with yeah it's uh i expect it to be fairly smooth i've tried the alpha in a vm and it's pretty okay but as soon as you start to actually use it daily all the problems will show up like from experience that's always how it is so yeah it's um but it's no not at all like kde4 situation so i think it's fairly safe to use so besides what we've mentioned were there any other concerns with the protocols

that just mainly this does a lot of things and makes things a lot more complex without really solving anything? Yeah, that was my concern. That was basically me bashing my own protocol. But from the other people, it was basically, okay, what if I want to do X? What if I want to do x what if i want to do y um so um and then but also then like for example xava um replied at some point that there's still problems he sees with it so basically it doesn't even solve problems for the people who saw problems with the old protocol and at that point oh okay like even

even if even those people aren't actually happy with it, why should I make it, like, worse for everybody? Right, right. That was the thinking process involved with this one. Mm-hmm. So. Sorry. Go on, go on.

Sometimes in, like, development of specifications, you're basically, and I know that from upstream, so the, like, metadata thing, at some point you're starting to go down a path where you are developing for hypothetical cases, which don't have any reality backing and create this huge and complex solution, which addresses everything and the kitchen sink. But it doesn't actually address the problem that people had initially and it also doesn't address the concern properly so you end up with a compromise solution which makes literally everybody unhappy and everybody's like oh yeah i really really don't

like it but if that's the compromise yeah sure and those solutions um work, but from my experience so far, they are usually not the best to have. Because if it half addresses everybody's case, nobody's really happy with it. And eventually it actually won't get used. So you end up with a useless feature because it doesn't fully address the concerns of anybody so yeah that's like a lesson learned uh for from like similar situations in the past mm-hmm so hopefully then that means your third approach takes what you learned from the second one and gets us somewhere hopefully more useful, maybe? Maybe. So the plan is basically I want this to be universal.

I want it to be as universal as possible so that as many compositors as possible can implement it. Because on Wayland, like if it's in the Wayland protocols repository, it should be as universally applicable as possible and I also want it to be as good as possible. So I wouldn't want to push for the ext placement protocol like right away just because it would solve the problem because I think I still have the like ideal

to maybe make it better than X11 and maybe find something that we can actually agree on and find a solution that works for everybody. And that people can at least say like, okay, there's like a nopped words in the agreement where like composite developers can say, I have no opinion on it. So at least to get to that state where like maybe people say, yeah, meh, if you want to implement it, but we won't like disagree and like flat out reject it.

But of course, if that doesn't work, I see no reason not to push the EXT placement protocol. So if this is basically the, like, I try this, if it doesn't work, there's other options now. There's, like, down to the option of, like, just not having it in Waynham protocols, which I would personally hate. That would be a failure. But yeah, the other protocol would still be an option if this one also doesn't work out and people still don't like it.

There is a possibility, a non-zero possibility, that we end up being in a similar situation to DRM leasing, which is the issue with VR headsets on Gnome, where, yeah. So I talk about this fairly often, but the reason why VR headsets don't work on Gnome Wayland is because of a thing called DRM leasing that is missing. What it does doesn't really matter, but DRM leasing that is missing. What it does doesn't really matter, but DRM leasing needs to be implemented. Now, everybody except GNOME implements DRM leasing, and now there's

like this whole other discussion where they're like, let's do a portal instead, which leads to GNOME developers arguing with Valve developers over how to do VR, which is an argument that's going to be very productive. I did not know that. Yeah, no, Joshua Ashton was arguing with some GNOME devs over this. There's probably going to be a portal that happens at some point, but the point I'm getting at here is KDE is, you know, if, if nothing happens, I would not be surprised if KDE implements this original protocol, it would be a bit, I, I don't know what'll happen with WL Roots, because I don't know if Simon Sir was that in favor of it, but I've seen him come around

to other things that he was really against after, like, enough support behind it. Like, initially, he wasn't a big fan of the Terran control protocol, but after, like, a couple of years of discussion, he eventually came around to it. And I could see that happening there. I know Budgie was interested in it. I wouldn't be surprised if Cosmic does it as well. As we start seeing these other desktops moving over to Wayland, there's going to be more interested desktop parties to get involved in these discussions.

I think that's going to really change up the way that these discussions are had. Because right now, it's often KD wants to do this, Gnome wants to do this, WROOTS wants to do this and sometimes there's some agreement between KD and WROOTS but I'm curious to see what will happen when you know you have PopWes on there with Coz when you have Budgie on there when you have XFC jumping in there as well when you have Budgie on there, when you have XFC jumping in there as well, when you have Cinnamon jumping there. Obviously there are a lot smaller entities, but they add a lot more implementations to the discussion. So the standards body for Wayland Protocols that is this thing doesn't have a, like, you must be this big to enter things. So everybody has equal voting rights

as far as I understand the document. So if like Bungie says no, and that's pretty much the same as if GNOME says no. Bungie said hell yes though to the initial proposal. So I think they might be in favor. And for the DRMly situation, I find this really funny actually, because Valve on their

own, like how to use your headset on Linux page, basically recommends to install KDE at some point. I know the documentation you're talking about, via headset. That is, I think I found out by accident at some point and it was hilarious. Which is just like, yeah, that is the solution. I don't like it because for the user it's a bit crazy to swap out their desktop. The specific line is, notably Gnome Wayland, the default desktop environment for Ubuntu is not supported and does

not support drm leasing user using canone whalen will need to switch to an alternative window manager slash composer in order to use steam vr workarounds for ubuntu you can use kde plasma instead of gnome and they even do this they give you a command to? Yeah, they tell you how to install the desktop. Yeah. Best documentation ever. But of course, if you like GNOME, that's not what you want to hear. That's pretty bad. But if it becomes a DRM-ly situation, I would be fine with it. Because that would mean it's solved for everything

but like desktops which don't want to support it. And then we can refine the even better solution later and if it exists and it's actually better and projects adopted, we can maybe deprecate the old thing. But at least there is a solution going into the Wayland future. Because yeah, that's undeniable. We will end up on Wayland and that is the future.

As much as I've had plenty of people in my comments be like, no, I'm never going to use it. I'm going to use, you know, people talk about it in the same way as the protest distros for System D. It's like, look, if you... I've had people be like,

oh, you know, when Red Hat steps away, I'm going to step up and help maintain XSOG. Like, okay, please do. This is what I say about it. If you think XSOG is good and you want x org to stick around please step up and maintain it because the people doing it right now don't want to do so if you actually want to maintain it do it please but you're you're not going to because if you were you'd be doing it right now well that's open source if someone

wants to maintain x sure uh but i doubt it it's like it's not the code base you want to maintain so i think at some point someone wrote like it is basically as if an assembler developer discovered C and started to write it like that. And I thought, okay, that's a weird statement. What does that even mean? And at some point in the past, I actually looked into the code that makes basically GL work. And back in the day we had this whole compits and barrel

and where like XGL was bolted onto X, where you could have crazy hardware accelerated desktops and stuff like that. And that's basically added to X. And pooh. The people who are working on this were crazy. That this even works is beyond belief because it's such an old code base and it's such a hard to know what happens

if you change something that I'm amazed that there's people who actually understand it and can actually work with that code. And if those people leave, everybody who is new to it and hasn't touched it before basically needs to gain all that knowledge. And of course you can, but I don't think it's a really likely exercise. With the systemd stuff, were you around when we had the extremely fun discussion on Debian on whether we want to switch to systemd or not. No, I've not seen that discussion, no.

It is just about, ooh, a thousand pages long. I don't, I need to find that back. If you know where it is, please send it to me. I will, it's probably easy to find. Since there's multiple bug reports, there's one for like, let's switch the system

and there's another one for the technical committee at Debian. And I think that one might be even longer. And that was an insane discussion. I think that was pretty much... And when it started, people were telling me, yeah, you're not not you haven't been around when uh we had like some of the like uh most incredible discussions like

switching to python by default instead of pearl or something like that um those were worse uh but boy they didn't know what would happen in the following year and how incredible this would become. But yeah, the point I was going to make, incredibly long discussion, a grueling process, I think that brought Debian's processes to the absolute breaking point. Leonard Putchering was making fun of it, of course, because why not? And in the end, there was a compromise reached with a general resolution to basically switch to systemd by default. And it was actually won by quite a huge margin, I think. But also allow other init systems to exist and be also supported.

And there was a lot of concerns about systemd, which ultimately didn't turn out to matter or to be valid for most users. So currently, people are using systemd with Debian. There is no, and people who don't are on that one. And there are still, there's still an effort to support sys-5-finite scripts, which is for smaller edge cases, like containers, some use sys-5-finite, and there are some DevOne developers

who also actually do contribute back a bit. And of course those patches do get merged. I've got one for one of my packages where it just has a systemd service file, and someone was like, hey, would you accept this sure why not but like i think from like the popularity contest data 90 is on systemd and the discussion is completely evaporated it's there's no uh no fighting about that and there's no like no arguing and it's just good and i think we will get the same outcome with wayland there will be a lot of oh no doomsday and in the end people

will just be fine with it i think the reason why the discussion is is happening right now i don't know if if you have any of your own numbers that you've seen but i did a poll on my audience of like are you using wayland or x11 and 10 000 people responded 55 percent wayland that's why there is a lot of arguments happening right now like that's really close and there's a lot of people still using x11 impressive actually yeah i was using x11 for a really long time um simply because i had an nvidia graphics card um now i have a different system so now i can switch to um can switch to um wayland but i didn't have fractional scaling for a while, and my monitor requires that. So that's why I was...

4K monitor, I assume? Good question. Some LG thing. I think it should be 4K, yeah. And it has a 150% scaling factor. It's either outrageously large or super small. And yeah, that's one interesting thing. Like one case study in Wayland, of course, like from a design perspective,

integer scaling, way better. No aliasing, no blurring. Like it is like the perfect way to design a stream. So that is what you want. That's why only integer scaling exists. And Gnome devs are like, like yeah good uh we don't need to support anything more because every everything else is bad it's just a bad way to do things so now in reality though screens exist which require fractional scaling and you make like like really bad for

people who have one of those screens so um kdu is like, we need to support these people somehow. And they implemented some way to do it. And then there was a proposal. And basically the two ways of has to be perfect versus has to be practical just completely collided. And it took really long to get Fractional Scaling into Wayland. I was following that from the sidelines. And I was thinking, oh great, good that I don't have a protocol that I want to propose. So with this, we didn't get to, we got sidetracked again, with this third protocol,

how does this one work and what makes, why is this, at least from what you think right now, a good idea? Maybe people disagree, but why is this the third one you went with? So this protocol... So one huge problem with the old one was that there's an absolute coordinate system that is tied to the monitor. So if you have a following or tiling compositor you don't know where the start is and where you place your windows actually and it's uh it's a bit hard so um what this new protocol does is um the application or the client um requests a workspace or work area for it. And then the compositor replies with, hey, okay, I give you this space.

It's about this big. And you can place your windows in that space. And then the application can absolute place its windows in this rectangle. And then basically be done with it. So what this protocol allows you to do is to group Windows actually exactly into a plane that can move together because then you know which Windows belong together.

It's tied to a screen so you know like the scaling factors and everything and you can place stuff on a separate screen easily. You can share this workspace with sub processes so you can say i have like child processes which also want to place windows in my workspace so i just pass it a hand wall to the workspace and they are allowed to place absolutely in that space as well and it also allows the compositor to basically And it also allows the compositor to basically mark certain areas of the screen as out of limits. For example, if it has a panel at the top, it can just not give the application the full space,

but just give it the space that is unobstructed and where it knows that Windows can be theoretically placed. So that is basically the gist of this protocol. And the compositor can still reject placement requests. If something collides with some important shell element, the compositor can still say, no, I moved it somewhere else. And then the application knows that this window was moved and can correct it if it wants to, or just roll with it. So it's still not like the application

having absolute control, but it's basically a compromise between the fully absolute window-based placement and the like relative placement solutions. So correct me if I'm wrong, but a simple way to describe it would be to the application it looks like absolute positioning with dynamically sized monitors effectively yes exactly yeah so it i i love this i i i love this

as a uh as a solution because it's just global positioning with extra steps basically yeah one of the biggest drawbacks is that there's a bunch of added complexity. For example, so if your work area, so what I expect to happen is that most compositors will just match the work area to the monitor. So it would literally be the same thing. Unless you have a compositor which is a tiler, which might just give it a smaller space, or if you have one of those infinitely scrolling compositors it would just remember that particular area for um for that one application and allow it to place it

somewhere on its like infinite canvas so it would work for those two cases it would like probably work terribly for tylers but to be honest i it's better than before. And I don't think these applications will ever be great on a tiling window manager. So honestly, just if you need a multi-window application, just have the application be floating, most tilers have the option to do floating windows. Just do that. Exactly. Like hyperlens I've seen on the video, uh, of it, like actually supports this. So that would work.

Yeah. Also WM, for example, lets you set like a specific workspace to just be floating. So everything on there is just automatically floating. That would be awesome. That solves it kind of. But yeah, one complexity that this protocol has, if it doesn't match the window size and you have, for example, in the middle middle of your screen you have a smaller rectangle where your windows are placed and then the user moves that one window to the top left out of the range of that workspace um what do you do so then the uh the position of

that window is basically a negative space and um the application can't position stuff anymore because it can only put absolute position in the work area. So since this is the user's intent to have the window there, the protocol currently mandates the work area to be resized to always include all the windows that the application has. But that means that the top, the origin, the coordinate system origin changes to a different position, which means that every single window that is contained in the work area will suddenly have a new coordinate.

So that is something I kind of really dislike, but I also haven't found any actual problem with it because applications handle, could handle this. And yeah, it would also restore backwards compatibility with existing applications. So something like Wine would just acquire a workspace for an application, could position everything.

Everything would work as it does before. The compositor would have the additional semantic information of how individual windows should be related to each other. So it could compress them in overviews, for example, like, Tiles could theoretically do that. Or you could move all of the windows of the same application to, or the same work area to a different monitor, a different workspace.

So it allows a lot of like pretty nice things that X11 kind of also allows, but only with hacks. So that's why I like this protocol. It's fairly straightforward and it should make the, make the like infinite window manager enthusiasts and a bit happier. But of course it's absolute positioning and there's still the application like making a request to have a window somewhere and if you're like fundamentally opposed

to that you will not be happy with this protocol either. Yeah that's what I was going to get into. Have there been people that have brought up that concern? Because it is basically just absolute positioning with extra steps. Because it is basically just absolute positioning with extra steps. Yeah. There hasn't been several looks. Actually, someone has replied today on that protocol. I just skimmed it. But I haven't seen any.

I think everybody is at the moment either tired or doing other other things in the tunnel um except positive feedback so everybody who applied so far yeah uh yeah oh um uh has has been positive about it i just saw uh simon from uh not simon sir but um oh it's his last name from app AppImage replied to a 2. He is like, coincidentally, I don't know. Wrong word request. Sorry. I was going to say. I couldn't find it.

I was looking at the window icon thing. That's where he replied. JOHN MUELLER II, Ah, OK. MARTIN SPLITTMANN, Which makes sense, because he has some stuff going on as well. But yeah, no, there's no real fundamental opposition yet on the other one. There's been a bunch of remarks,

like some people were like, what happens if a window is between monitors? How is that handled? And should an application, for example, demand the workspace to be of a certain size? Or could it say, I expect all my windows when I place them to occupy this space. So could it give a hint to the compositor that might occupy the space? And I thought those were good ideas.

So they are in the work. Like a hint to take the entire monitor. Yeah, exactly. And just create a position again. So if you plus zero space get zero space per quest. That basically means I want as much space as you can give me. Exactly, yeah.

I don't... Look. I still think there's going to be people that have concerns with this. I already mentioned, when I brought this up before, this protocol is the one that the Hyperland dev specifically complained about. So I guarantee there's going to be some complaints,

but we're getting late into December, so people are doing other things right now. You're not going to get as much attention. I'm sure there's going to be some discussion on this as we go on, because it's only been out for a week so far. So give it some more time and i'm sure the complaints will definitely come in um yeah but i'm i'm not a person who gives up until i at least uh like at least know that i got my point across um so if if i think the other person understands

like the basically the problem and the proposed solution and serious agrees and it's like no because i think my point is just more important at that point there's no real reason to uh discuss more about it because then it's just a difference in opinions and you can't really argue about it. But if they say, okay, I don't like this, but I could imagine something else to work, then there is an opportunity to reach an agreement. And ultimately, I think either we do or we go for the EXT namespace and then have it there. Well, you also have another protocol, which is a hopefully less controversial one, the EXT window icon.

I'm sure it's going to be controversial. I think this might be just as bad. So what is the issue here and how are you trying to solve it? So on Wayland applications can't set their own window icon. So an application that you just launched from a binary on Linux will have no icon on Wayland and on X it can set one freely for every single window. And on Wayland, it can't. But you do have icons on Wayland.

So where are those coming from? Basically, your compositor pulls them from the environment from the respective desktop files. So you have a desktop entry, and there's an app ID associated with the application and it just matches those and finds the icon and loads it like that. And I think this is great, actually. I think this is how it should work. Because the XDG icon theme spec has a bunch of logic for finding scalable icons and for finding the right icon and your application will have the icon of your current theme if you're doing

icon themes and things like that. So I think this is good. So I didn't think this protocol was needed until I found that there's actually a point to have it since, again, in the scientific space you have Python virtual environments where there's just binaries launched and those VMs are not able to register a desktop file because they can't write to the respective directories and they really shouldn't. I don't want them to. So it's... and it would still be nice

for those to have an icon. And there's some applications which are like launched from the desktop file and then they launch like some separate binaries for some stuff and they might display icons. They currently also don't have an icon so they would need to install like a mock desktop file for them which is hidden by default.

And like use that to obtain an icon for the windows, which seems to be a bit much. Then there is like applications, which like the one I developed, which has a bunch of different modalities. Like I develop an application, which is designed to acquire images from a bunch of different cameras. I think the lab that's using the most is using eight cameras or something. And

it is displaying some electrophysiology, which is basically brainwave recording. And there's a bunch of these different windows, and they all currently on Wayland have the same icon. And it would be nice if they have separate ones. If you use a desktop environment which actually splits them up in a taskbar, you have different symbols for it. Or if you look at the window overview and it puts a small icon for the window in the corner, then you have like a different icon for them and not the same. So it's not like a thing that breaks anything, which is why I'm not extremely married to this proposal, this protocol, but I think it would be nice to have, to allow

applications to set the icon for some Windows. Like with the multi-Window stuff, there is actually a use case outside of the scientific apps um with say a progressive web app so you like you know most chromium browsers let you like save a you know twitter or something as like a thing you can just load as like a separate application if that was loaded from the like from the browser right now on Wayland, that would just use the icon of the browser rather than the icon for the service that you've loaded. Yes, I was just thinking whether the browser could basically pull a trick on the compositor and change its app ID for that.

But it's not per window, it's per process. So if there's one browser process, it would basically need to fork itself, create a new browser instance and new process. And then it would just need to change its app ID to whatever desktop file they created for the progressive web app and then get the icon, which would work.

So it could be made to made to work but it would be ah would not be amazing i think but like there like there are there are additional things like this might also be useful as you said before though it's not like super crucial like no you can live without it you can live without icons. You can live without icons. It's just, it would be nice, especially because, you know, most desktops have like task switches. So you'll see the icon there along with the window name and the icon might be an indicator for like the thing you want to swap to. Yeah. For that particularly, I've like, the reason which like pushed me over the edge to do it was,

so Matplotlib is a tool in Python which is plotting stuff, which you can use to plot graphs. And that's running through x-wayland for some reason. I don't know why, but probably because it uses tk as toolkit. Although I thought it should use Qt, but different subject. But it's, I've had a different tool which I was using,

which also spawned a bunch of windows, which was using Wayland. And suddenly I had a bunch of yellow Ws and I wanted to switch to one particular one. And I had like a window overview and it was really difficult. That's when I thought, okay, I actually see a pretty good use case right there for having this feature. I thought, yeah, there's a longstanding feature request on the Wayland Bug Tracker. I know because I wanted to file one

and then I was like, maybe there's already one and found this one. And as again, with the other protocols, I always find it better if there is a proposal. I've read through the original bug report and there was a bunch of security concerns launched. Like what if you launch an app and it changes its icon and then it's different for the user and the user might confuse it with their banking app or something.

And then someone said, but applications can already do that. And then someone said, yeah, but they can't do on Flatpak. And I think that's an okay argument. I don't think it's strong, but I think it is also not invalid. So what this current protocol does, it requires the app to first set one window as primary window, and that window must have the icon of the specific app ID.

And if a window is set by the application, it's only used as fallback. So if the compositor can't find an icon, it uses whatever the client has provided. But if it can't find one, that overrides it, at least for the primary window. But for the other windows, the application is free to choose whatever it wants to with the current protocol it's again a bit over complicated maybe but at least that's the uh the only way i found to actually address that particular concern because the alternative would be to just not allow it and or like you only allow fallback icons which would be nice to uh for applications which uh don't have a desktop file but want to set an icon but it wouldn't work for applications which have the same process but want to have different icons for

different windows so with this you're sort of just trying to, like, gauge interest over whether this is, like, some, like, just starting the discussion as opposed to, like, this is a set things that, like, I've got, like, I'm absolutely set on doing. It's more like, is this something that we actually even want to consider doing? Let's get something started

so we're not thinking about this five years from now and when someone brings it up again as like as an issue just like get this discussion going and if something comes from it then hopefully you know we can go from there yes um with the previous proposals i talked to people before whether there was interest and to like previous proposals, I talked to people before whether there was interest and to like, and I knew we needed this protocol, especially because it was breaking functionality. This one's just cosmetic. So except for the app image things. So I get why Simon wants it. But yeah, I want to know what speaks against doing it and how would your protocol look like that supports this and then maybe get it merged at some point or

reject it. And then in future we can, if someone is like, well, it doesn't support it, we can reference that and say like, because uh reasons so there's a like because before the document the discussion was more like on a what if and how could it look like um and now there's a proposal so and we can change the proposal and if there's no way to reach an agreement then then at least we know so you do a lot more than actually your main thing is not in like involved in whale you do a lot more outside of uh just doing these protocol discussions hopefully things are a lot more productive um so you mentioned briefly before app stream and package kit

these are things that obviously everybody makes use of in some way, but it's not something that most people probably recognize just as a project that exists. So can you briefly explain what both these projects are? Yeah, so PackageKit is a package management abstraction layer, which of course is a group name. In a deal explanation, everybody immediately knows what that means. So you have your distribution package manager, like app or DNF or zipper, and every distribution

basically has its own. And if you are developing a tool which is installing software, you basically would need to support all of those different package managers. However, what PackageKit does, it abstracts over it and allows applications a unified interface to interface with the package manager.

And it also adds additional features like queuing so you can queue a bunch of transactions which not all of the existing package manager support and um like a background interface that that is like managing the packages and it's like very convenient if you are developing a cross-platform GUI for managing software. It is, however, not intended to replace any of the package managers or any special software for it, like Synaptic on Debian, because package kit is very simple and basic. It's not a fully-fledged, we support every single feature kind of thing. It's more like we support most things

so that applications can request missing functionality. Like for example, installing a missing font or installing an application that is missing or something like that. And it was originally created by Richard Hughes. And I think it was one of the first projects that I was actually involved in even in open source. No, it wasn't.

No, it was not. But it was the first project that I actually contributed majorly to. That for sure. with an A is a metadata standard and library for building blocks for software centers. So if you open GNOME software or elementaries, App Center or KDE Discover, you are using it. It's comprised of multiple parts, but the most important one is a XML specification where application authors can write metadata for the application that is useful for the user who might want to install it. For example, it contains the name, it contains a summary, it contains a long description, it contains keywords, it contains a donation URL, it contains a bunch of screenshot links that can be used. So it's basically what you see on these overview pages that's powered by that. And so that's like one aspect of it to like for like users, but it also is designed for

automated systems to query what is available in a software repository. So, for example, if you have firmware or if you have anything that the system might not have installed but might need to have installed depending on circumstances, it provides metadata for that. So, for example, when you plug in a new device which is missing a firmware package, for example, because it's when you plug in a new device, which is missing a former package, for example, because it's proprietary and wasn't installed by default, the system can basically seek in its repositories where can I find something that works for this and offer the user to install the respective package.

Or like for a more practical example, if you have a new file which you want to open, but you don't have an application to open it, it can be used to query for a catalog of apps that is able to open this particular new file that you found. So it's also used for that. And yeah, it contains, like AppStream itself contains a library which a bunch of utilities to build these software centers. So a bunch of implementation and glue and things to make it easier to write these apps. So that's basically what it is.

So how long has AppStream been around for? Difficult to say. So there was a meeting in 2011 where the name was created and where the original proposal was uh was drafted and um that was when i was still in high school and i was i'm really still sad that i couldn't go to that meeting because it was the final season and i was watching the meeting on a terrible laptop very interesting interesting memories because I was very involved with that at the time. And still am, obviously. But, yeah.

So, it kind of exists since then as a concept. But I started actually implementing it in late 2012, I think. So, it has been around for a while and it also has been morphed into different things. Initially it was specified as Sapien database to manage all the different information about apps. And it like basically encoded what Ubuntu did at the time with its system to have an application store.

Because that was one of the most ingenious things that Ubuntu ever did to create the software center for Ubuntu and to make PPAs integrate seamlessly. And so it was basically like, we want that on Linux everywhere. And how do we get to it? So it included a bunch of like concepts which later were dropped and the XML is different now.

And then Richard Hughes had his firmware updates on this and which is also using upstream and came with like more ideas or it morphed into something that is like not pretty, not the same as it was in 2012. I would say 2012, sorry for the long reply. No, no, it's all good. So I guess going back earlier than that then, how did you find yourself first getting involved in Linux, in this FOSS world? What initially drew you to it? Where did you first start?

I was actually thinking about that yesterday because I thought that might be a question that's interesting to ask. And it's not easy to say. I think the initial start was when I was about 12 and was interested in electronics and science in general. And I had an electronics kit where I was building blinking lights and things like that. And they had a chapter on computer logic where they basically were just teaching how to build and and or gates and saw gates and basically all of the logic gates.

But then they didn't actually go further. They didn't say, okay, this is how they make a computer from it. They didn't have me build an adder or something from it. So I was like, okay, cool. But how does this stuff make Age of Empires run on my computer when it's a game that back then was quite popular, but the one Age of Empires one version.

And I really wanted to know, so I, and at some point I found a, like, computer magazines were a huge thing. And I found one which was teaching, which had a small block to teach Delphi, which is a Pascal based programming language, or it's just like based on Pascal. And so I learned programming, and which was a pain initially. There was a book called Delphi for Kids, which I wished for my birthday, I think,

so to finally know how this programming thing works. And at some point, I grasped that. But then I was like, OK, I know how programming works and how object-oriented programming works. That was a huge achievement back then to finally at some point understand how the hell that works and why it's useful. That was actually the more difficult thing to understand.

So then I had like the, basically the programming. Then I was like, okay, cool. But how does the operating system work? And like, how does like this even like connect with the stuff that I see? And as it happened at that time, there was like some article in one of those magazines on I think on Linux in general where they introduced this whole like interesting new graphics possibilities. And I was like oh this looks really cool. And I was just like installing it to play

around with it. And back then it was I think SUSE Linux 9.2 or 3 or something. That must have been in 2004. That's definitely 9 point something. The original before it became renamed you know into open susan um and i used that basically because there was a cd and i um i was like uh the internet wasn't like was the thing where you were just uh basically like my father had a laptop and uh which was the only device that had an internet connection everything else was like i had no internet and every time i was doing like some research for school or something it was basically go into the internet as quickly as possible find the stuff as quickly as possible download every

page onto a floppy disk then go like disconnect because it is so expensive and then just watch and view the pages offline. That was my internet experience in the early days and it was even worse when phones came and they had a button where you just were connecting to the internet and it was using all your money in like five seconds. It's like, you press the button!

No! And yeah, I had a flip phone back then which fortunately you could just crash by flipping it and i don't know how many times i just uh like flipped it shut because i accidentally clicked the internet button and i think i didn't want my uh my prepaid car to be used but yeah that that aside so like downloading a linux iso no way. So basically I used SUSE because I got the CD for it. And then I really liked the fact that I could basically inspect the system and see how it worked and play with it. And of course I immediately tried to be able to program in Delphi on it, which was impossible,

because Delphi is very much, originally back then from Borland, it is a Windows thing. So then I went into, okay, I need a Pascal compiler. Pascal compiler had to be compiled itself. And so I kind of snowballed from that. And due to the internet issue, I had one major problem, which was no software on Linux. Because the package managers, of course, were a thing, but they required some kind of mirror. So I either had the choice to get a huge DVD

with the whole repo burnt on it, which I couldn't because I didn't have a DVD like drive. So, and it was freaking expensive. So it was either like multiple CDs or like some other install procedure. And I've, I hated it. Like, especially coming from Windows where I just put in a CD and just install it.

And then on Linux, I was like, I don't even know how to get software. And then I was compiling it and I thought, okay, what if my, I can't have anybody else use this because it is just so annoying. And so I thought, it would be cool to change that. And this is Linux, so I should be able to change that. And from that point, I wrote a small tool in Pascal

which was installing Linux apps, basically. It was like a, it almost feels like an insight, an early version of Flatpak, but not really, no. It was like a person's approach who didn't know much to this problem. But what it did was at some point I finally got, we finally got a faster internet connection, which wasn't that expensive.

And at some point, somehow I also finally managed to get my Wi-Fi working on that particular computer, which was incredibly hard on Linux back then. But from that point onward, I was reading online about this new thing called PackageKit. And I joined the IRC chat. And I was like, hey, you're doing this abstraction layer. Could we also abstract my system, And I was like, hey, you're doing this abstraction layer.

Could we also abstract my system which is able to install universal Linux packages? They want universal, but meh. And Richard Hughes was like, yeah, maybe. And there was a bunch of features I wanted from package kit. And he was like, please, you write them. And I was like, but I can't write them. I only know Pascal and have no idea how C works. So he was like, yeah, I figure you can do it.

So I was looking at C code and the main problem with C was that I've had some friends of my parents, so my parents are teachers. So no direct association with IT stuff. My father kind of dislikes it. But they were like, C is so hard. It's so difficult. And it's one of the most difficult languages.

And only masters can write C. And of course I was 13, 14 or something at that point. And I was so intimidated that I didn't try it. And then there was this guy that I've never seen on IRC, which my parents were very suspicious of, like me talking to like Linux people on the internet. And he was like, just look at it, just write it and then i wrote some things which uh were horrible and then he was reviewing my patches and sending it back and i was like oh cool i learned something and then it was like a back and forth and at some point uh i just learned C by absorbing it from patch reviews.

And now I think it's the main language that I write stuff in. So I kind of learned it by osmosis. And at that point, I also kind of lost my shyness from submitting stuff to open source projects. And it completely obliterated my, my like basically all from like, oh no, I can't touch this because it is so advanced. It's like, yep, it is very advanced. You probably won't understand it,

but you can have a look and maybe you will. And then I just love the way Linux allowed me to actually introspect the system and poke it and see what's going on. How do things work? What is happening to my data? How is stuff stored? Like how does the kernel even do things?

And it was so interesting for me back then. So the reason I was using Linux, so in the end was because it gave me answers that Windows didn't. And on Windows, I did get a product from Microsoft and there was documentation about it, but I didn't have the same amount of control and the same amount of insight into it.

And it also didn't have a person like Richard Hughes who was kind of dragging me into it. So yeah, that's pretty much the story how that happened. It was a really happy accident, but it also kind of informed me, like my belief in the value of the GPL license and Copyleft in general, because if you publish code and someone can make it proprietary again and basically deny you the right to look into that code, it's not possible for someone to grasp how the system works.

So, and I think this is a fair request to make if you get my code that you also basically have the same permission for like the kids or like even another company to support that product by viewing the code and seeing what exactly the code is that I wrote. So yeah, that was pretty much... Then the ideology came with the like into what i initially just thought was a cool thing and then i was done in with high school in 2011 and um then went to my first conference conference which was the desktop summit in berlin and that was the coolest thing ever, because for the first time,

people weren't just like strings of texts and numbers in an IRC chat, but actual humans who are sharing the same passion and the same interest. And I was like, I was going around with the PTV developers who were really wanting me to contribute to their video editor. And I really didn't want to, but it was still really fun. And I've met a ton of friends that I've previously interacted with from GNOME and KDE and headlamp

which it's used for the first time. So I think that absolutely cemented it i think from that point onward i just couldn't leave well you're clearly like really really passionate about this like just you talking about going through this this history like how you got involved like it's clear that this is something that you love to do and i i hope that other people can like you know take that energy and you know if you if there is a project that you feel like you know there's something about it that you would like to see improved get that first like foot in the Like, it might seem difficult initially,

but you've got to at least, like, try and, like, you know, make your way in there, because once you first, once you got something there, it's probably going to be a lot easier after that. Like, there's going to be difficult problems for sure, but you're going to realize that you actually can change this code yes and that is one of the coolest realizations to like to realize that but also one thing that Richard told me that his first experience was that he was like writing

this thing and publishing it like like, because why not? And then someone just had a random patch and he was so excited to get a contribution by someone because he was not expecting that at all. So I think it's a mutual thing where everybody is kind of happy about it. And of course there might be negative experiences. When talking about this, I just remembered a story when I must have been like 14 or 15 or something. I was writing on a forum about something or about one

of my patches. And then someone made a comment of like, oh my God, so like in a way of like, what an idiot. What are they teaching these people in computer science classes? They can't even grasp the most fundamental concepts and stuff like that. And I was devastated because I'm not a,

of course I'm not a high, I'm not a student in like any engineering classes. I'm like a 14 year old pupil at school. So he didn't know, but it still was really hurtful. And it's like, oh, I don't know if I want to even ever be in this forum again. But ultimately it was fine. But this was incredibly bad back then,

and now I laugh about it. If you frame it another way, you were conducting yourself in a way that they thought you were a bad computer science student. They didn't think you were just some high school kid who had no idea what he was doing. Yeah, I literally had no idea what I was doing, which is why I asked that stupid question in the first place.

So, yeah, but I hope now I know better what I'm doing and it's a learning exercise. And I think the open source, like onboarding process for new people and the way that contributions work is so much better now than it has been back then. At least I hope. But from the people I've spoken to who are new, it really feels like that. So I think it's easier, much easier now to start to get into it. And we are nice. Like there's like, of course there's like some people who might not always be, but generally it's a really, really nice community.

And I'm quite happy to be in it. When you mentioned finally getting to see people as more than just strings of text on a screen, like that's a big part of the reason why I like doing this. Because there is a lot of people out there who you just see in a repo. Like, you know, as you mentioned at the start, you see Neil. And you just see that Detective Conan picture everywhere. And it's really easy to forget that there is an actual person behind that account who is actually doing that work.

And that's why I like bringing people on for this show. Because, you know, how often do you get to hear just some random developer talk about, you know, their experience in various repos, their experience at these events, their experience, like, getting involved in Linux, you know, two hours, like, just a solid conversation. you know two hours like just a solid conversation like i i hope that by doing this it sort of it humanizes a lot of the people who you know you might not agree with every single thing they say but i hope you can at least understand like where they're coming from and why that is the position they hold. Yes. There's this huge debate on should we just have online conferences? And I'm very much a person who is absolutely not because the in-person conferences do so much

to see the other people you're interacting with as humans and also as friends. So like having a beer together in the evening is great. It does so much. And you can even do that with someone who you don't agree with. Because even though you might disagree on a technical thing, it's still a great person maybe. And you might still even be friends who disagree which is perfectly fine so um and i think that's one of the the best things of like an in-person that's easy on an in-person conference than on a backtracker where sometimes things get heated and

people say things that they shouldn't have said or like are like pissed because they didn't understand something right or where they just completely antagonize someone who is like basically just trying to achieve the same thing as they do make clinics better yeah well on that note i think we should be ending off the show we've just passed the two hour mark it was very technical i didn't expect to like through protocols. Well, you know, look, sometimes it happens. Sometimes I spend 40 minutes. Actually, I had someone on the other week. I brought him on to talk about his experience swapping back to Linux. He's mainly like a Windows and Mac OS guy.

And the first hour of the show we spent it talking about learning japanese so you know sometimes the show is productive and sometimes that happens if the conversation like flows in that direction why not yeah pretty much um it's not a tech over tea so we were right on point i had my team before though so i've been sifting on this the entire time um yeah so i guess if you want to direct people to any like your socials anything that you want if there's like a project you want you want to send people to to look at, let people know where they can find anything.

Yeah. So contribute to Upstream if you have interest in that on GitHub. It's always nice to have new contributors. But also I think the thing that makes sense to highlight most is don't be afraid of Debian. Go to and approach Debian. And if you want to get involved in Ubuntu packaging, but also in Debian packaging, just try it. Because that is a pretty harsh process to become a Debian developer, but you don't need to start with that. You can contribute to the project and then a Debian developer, but you don't need to start with that.

You can contribute to the project and then make Debian better, make Ubuntu better in the process and all the derivatives that are branched off of it. And I think that's a really cool way to get started for people who have an interest in that. But otherwise, just contribute to whatever you like and whatever you use and want to improve.

So yeah, I think that's the best advice. But yeah, if you want to follow me, I'm on Mastodon but I think I'm mattk at mastodon.social. And on Twitter, I think I'm MattXPP if you want to follow You don't use it that often though I use it next for science stuff Scientific Twitter is really

still really active Every single open source developer has kind of been driven away from it. I think it feels like the interactions on Mastodon are just so much more vibrant and there's so many more people and Twitter as far as open source stuff is concerned, it's a bit of a ghost town, but as far as neuroscientists is concerned,

stuff is still happening on Twitter, so it's still still on both this is great for me because it means i don't have to pay for dms that to just be able to talk to anyone because there's a bunch of people who don't follow me who i want to be able to dm i can't do that on twitter nope not gonna pay for that oh yeah it's part of premium now oh that means i was wondering because i all i get on twitter right now is spam yeah you can like open up your dms but they've got to like accept it as a message request it's it's yeah it's it's annoying yeah like hidden and in a separate town if you get a bunch of them you're never gonna see them yeah i i rarely look at i think i just discovered this by accident that it even exists like just half a year ago and um there were actually a few legitimate like queries in there

but like most of it was like i think 90 was spam yeah um but yeah i hope i haven't bored people to death so if you follow me it's's mostly about the mostly about like the occasional neuroscience stuff and open source releases and blog posts or something because oh yeah i have a blog which i very rarely write things on as blog.tempstorol.net which i probably should because i don't know if you can I should probably send 10 to the it's mostly about I was blogging a lot in the past but since I have such little time with like doing my PhD and and the open source stuff it I think the block was the thing that suffered the most um which uh yeah you got two this year the last one was 2021

yeah yeah i think the one when i was at the uh at the developer sprint in london is still on the front page which has been ages ago now i know it's not deprogramming it's on the second page now seven years ago yeah in 2016 yeah i'm not uh i was blogging more in the past about interesting things but uh but nowadays uh i spend most of the time like either like in purism work or in other work, and then I don't blog about it, and then people complain because they don't know. You need to do good things and talk about it is doubly true in open source, because you can do amazing stuff and then nobody's using it, which is frustrating. And the reason why nobody's using it

might just be because they don't know. So it needs to have some megaphone to say, hey, this stuff exists. And for that, actually, props to Neil. He is amazing at that. Because he has this thing where if you find something cool or some cool new thing, he is making noise about it and bringing it into distributions.

And I recently wrote a small tool called ButterFSD, which is a daemon for ButterFS, which is just basically monitoring it for errors and sending mails and system notifications if there is an error and it's performing scrub at regular intervals. And yeah, it attracted Neil and he's like, yeah, cool idea and now it's in a bunch of distributions

which is cool, yeah. So yeah, I think you need stuff like that and an Aura block to kind of advertise the changes. And yeah, I think that i think that richard does well with this linux vendor firmware update service so the firmware update stuff that he does is also amazing oh yeah that's also probably projects i can recommend far more update if you're in more into the hardware side of things and want to tinker with that probably uh but that's probably more for the advanced for the if this i don't think i would start with that because it's very like down to metal but it

is a really cool project i think it's it's really uh useful for the linux desktop to have uh devices actually being able to update firmware and having vendors like Dell being able to provide firmware and have it apply to your devices automatically. And this tool is so good that people are still using it on Windows even to update firmware, which is quite an achievement. That's awesome. So yeah, lots of cool stuff. I think every project deserves new contributors.

So. Well, we'll definitely have to do this again at some point, because you clearly got a lot more things that you want to talk about. And we, we barely even touched on Debian stuff. So we'll have to do this again at some point in the future. Talk about that.

I think I watched, uh, while I was mentioning Debian, I've watched one excerpt of an interview. Was it like one part of your talk? Yeah, like from, there was like an excerpt of Neil's interview where he was like, Debian is so difficult and there's ancient infrastructure. And I was like, hmm, yes, but. so difficult and there's ancient infrastructure and i think hmm yes but so you can uh so like if

you want to like debian actually has improved dramatically uh for its processes its community uh the way it works so i think it's uh it's a it's a good way to get started for people who want to contribute to it. But of course, I am biased as hell. I am very much a Debian developer. So I don't think this will change anymore. Every time, like when you start Linux, you have... I started with Susie, I started with SUSE, then you have this weird GENTU phase, then you, I think I tried Arch and didn't manage to get to install it. And then ultimately I ended up with Ubuntu, no, I ended up with Debian, then Ubuntu because they had a free CD for like, what was the release? No, the Gatsby Gibbon or something, 6.06, I think.

And that was the thing that made me switch to Linux completely. And then I switched back to Debian when they started Unity because I didn't like it that they were going away from GNOME and doing their own thing. I didn't want that because I didn't like it that they were going away from GNOME and doing their own thing. I didn't want that because I was very much for we need a unified Linux experience. We don't need to fragment it even more. So I was like, no.

And also getting things to get past canonical was becoming difficult at that time. Yeah. Completely different topic, sorry. It already was a rambling suggestion of new projects to try, and now I track it even more. I think that's not good. I'm going to stop asking you questions, because you're going to ramble for another 10 minutes if I do.

I'm going to do my outro, and we'll save any other conversation you want to have for another time that was the nicest shut up I've ever heard it's going on 4am here this is nice you're going to get from me thank you for having me

okay so for me the main channel is Brody Robertson I do Linux videos there six-ish days a week I don't know what'll be out probably something about Wayland. I don't know It'll be getting close to Katie's real Katie positive six release. So maybe there'll be some more news there I don't know cuz this will be out in like four weeks. So I have no idea what to be out by then If you want to see my gaming stuff, I do gaming streams twice a week over

on Broodio and Games on Twitch and YouTube. Right now, I should be playing through Neptunia Sisters vs. Sisters and Neo The World Ends With You, so check out the anime garbage. If you're listening to the audio version of this, you can find the video version on YouTube at

TechOverTea, and I should be can find the video version on YouTube at Tech Over Tea. And I should be experimenting with the video version on Spotify as well. I don't know how well that's going to go, but they gave me the option to do it, so I'll try it out. If you want to see the audio version, there is an RSS feed. You can find the podcast and all your favorite platforms. Search Tech Over Tea and you'll be good to go. Give me a final word that is preferably less than 10 minutes long. Final word?

Thank you for having me. I think that's all. And contribute to open source projects. Absolutely. And absolute pleasure to have you on the show as well. Thank you. Bye. See you guys later.