 Today, we'll be talking about Sway, Sway's being said share, various things about the topic. So, first of all, when I've been in the Linux space for quite some time, Minfedora contributor since 2013, and then since 2016, Sway, Packager, and well, user as well. So let's start from the very basic, what's Sway, why we're talking about this. It's a drop-in replacement of I3WM. Drop-in is the definition of the project that does not mean that it's actually a drop-in. Nowadays, it's way closer to that idea, at least, but it's not like perfectly a drop-in in some very edge cases. Why have it at all? Because it's for Wayland. So I3 did not want to migrate from X11 to Wayland. I'm not entirely sure if they changed their mind in between, but back in 2016, they were like, nope, we are X11, we are targeting that platform, we have a lot of code specific for X11, therefore, we don't care about this new thing that hopefully will change everything, but maybe it will not. It's based on WL routes, so effectively, the Sway developers wrote also a Wayland compositor. At the time, there was, I don't remember the name of the genome one, but they did not want to use that one because they believed that it was bloated and not up to the level that they were expecting. So they wrote one from scratch with the idea of creating a very small implementation, which at the moment, I think it's around 60,000 lines, which is not that much to be a Wayland compositor, but to be fully compliant with all the extension that Wayland has and had at the time. The first commit was in August 2015, so we are at the eight-year mark from Sway now. And interestingly enough, we have it packaged since February 2016 in Fedora, and the first release they had upstream was in March 2016. So effectively, we can say that Fedora was probably the distribution that has been had in Sway for the longest period of time, and I have to say that I have been using Sway for quite some time because I packaged it a couple of weeks after I moved to Sway. So it was not very stable. At the time, I used to also have I3 installed because it tended to crash, version 0.0, but still it grew very well, and over time it became very, very stable. Now the history between Fedora and Sway has, I would say, three big parts. The first one is what happened before Fedora 38, then 38, and then 39 in the future. So before 38, there were multiple people that had their own spins or remixes based on the specific versions. I had mine as well. I think I published officially, so I had it mined based on classic Fedora since 2016. Then in 2017, probably I moved it to our PMOS 3. I published it on a Git repo but never commented too much about it because it was basically my version of Fedora. And then a couple of years ago, I published it also with the blog post and telling a little bit to many people what actually I was trying to do and that kind of things. And in the same way, other people had tried to solve the same issue. So in May 2022, we decided in a bunch of people to create an official spin for Fedora 37, for Sway. That was the initial idea, but it did not happen. It did not happen because we were not very clear with ourselves on what exactly we wanted to put in that spin, if it should have been a very basic spin or a more complete spin, who was our target user and so on. So we used a little bit more time than the Fedora 37 really cycle allowed us to do. So we ended up with Fedora 38. So in Fedora 38, we proposed the Fedora Sway spin change. That's also a link. It does not feel like one, but you can then find the slides in SCADA, I'll upload them there and you can click a lot of things in the slides. And this change was about two artifacts. The first one was the creation of the Fedora Sway spin. And to be specific, the biggest change between Fedora World Station and the Sway spin is around the packages. So the packages we ended up with are obviously the Sway packages. So Sway, SwayBG, IDOL and LOC, which are the very basic Sway packages that you can have, Dunst for Notification Demon, Food for the Terminal, and that was kind of a long discussion because we have a lot of different terminals, but well, in the end you only have to pick one. So Slurp and Grim to do screenshots. So the first one allows you to select an area on Weyland and the second one to screenshot an area on Weyland. IMV for the viewing images, Kanshi for dynamic output configurator, MPV for media player, tuner for file manager, and STDM and STDM-X11 for the login manager. Now we'll be talking a little bit more about the last one. But as you can see from the list, we opted for a fairly complete version of the distribution in the sense that we are providing the majority of tools that a person might be using. There is also Firefox. It's not in the list, but it's there as well. And all of them, or all of them except the last one, are Weyland specific. So for instance, Food, it's a Weyland terminal emulator, IMV, same thing. So whatever we could choose between the next 11 native program and a Weyland native program, we opted for the Weyland one. The other thing that we proposed in the same change was Fedora Serichea. Now a couple of comments on this. First of all, the name, the pronunciation, I've seen that many people struggle with it is either Serikea or Serichea based on the kind of latin you want to use. Classic latin would be Serikea, ecclesiastic latin would be Serichea. I use the latter because I'm Italian. In Italian schools you study ecclesiastic latin, not classic latin, but either would be correct. The reason is that Fedora Serikea or Serichea comes from Terminalia Serichea, which is a plant, and plant's names are pronounced in latin. So why Terminalia Serichea? First of all, because Serichea started with S in the same way that Swaida's, and so it was like a nice thing. The second aspect is that Terminalia Serichea is a tree, West Tree is a tree. So we found that similarity as well. Also it's the common name would be Silverleaf, which was also one of the options of what then became Silverblue. So it was also a nice reference there. And if you look at Terminalia Serichea, you will find a lot of similarities with the Swae logo. The first one is the Swae logo, and the second one is the Wikipedia image of a Terminalia Serichea, just mirrored because they photographed it on the other side. As you can see, there are a lot of similarities. So we thought that that was a good thing, and therefore we opted for this name. Also speaking about logos, we also got a logo, and this is thanks to Emma Kinney, which is part of the Fedora design team. And she was very patient with us with all of the changes that we asked her multiple times. And so we also have a logo that is also very similar to the previous two images that we have seen, but obviously in the Fedora way. Now, we also worked a little bit on website things in the Fedora 38 time frame. So first of all, we managed to create the spin page. It's a little bit weird because until Fedora 38, effectively, well, until Fedora 37, all spins had a page on spins.fedoraproject.org. In Fedora 38, some spin moved, or the new spins started to have pages on the new website. So we moved, we went directly in that path. And then I think that now every spin will move there as well. So we tried to already be on the new website just to avoid the double creation of pages. Then we also had Fedora 38 page on the website as well. I'm not sure how many derivatives or additions have the page or had the page at the time, but for the same reason as before, we tried to already adopt the new standard because it was obviously easier for us. And also we created some documentation around this. There are still a lot of things to document, mostly because Serichea and Sway specifically are Wayland only, which means that, for instance, if you have an NVIDIA card, things might be a little bit more complex. Now hopefully in the next few releases, everything will become smoother and even NVIDIA drivers will work perfectly. I really hope that. But in the meantime, it's, you know, can be a little bit rougher there. So for Fedora 39, we proposed one change and then we inherited one, which is always good. The change that we proposed got approved and implemented and I think is real since three or four days ago, a row height build, so it should work. I've not yet tried on my laptop because I did not want it to break two days before Flock. But still, it's Serichea XOR glass. The idea here is that looking at our three of dependencies, we are still importing XOR, which is not very good for Sway that, you know, in theory should be XOR glass. And the reason for that is that we are using STDM X11, or we used to. And by moving to STDM Wayland's way, we can actually drop completely the XOR dependency. So this is what we have done. And now we have the builds without XOR, which is always also better because there were a bunch of weird bugs in the logging page due to some not perfect configuration of XOR, which we didn't really care about because all the rest worked without XOR. So we also fixed a little bit the user experience there as well. The other change that we got, but we did not develop, so it's always nice because, you know, you get it for free, is the OS3 native container change, which is, I think, driven by Colin Walter and other Fedoras people. So now you can actually download Fedora Serichea directly from a Docker repository or image repository. Now for Fedora 40, we start to have some ideas. Those are not like written in stone kind of ideas. It's more like, yeah, we have thought about those kind of things. I've discussed it with a couple of people, but nothing is written in stones there. And the first one is the unified core mode. So I think in Fedora 39, Silver, Blue, and Kinoid are going to move to this unified core mode, which basically is the new suggested way to create RPM OS3 images. The classic way is now deprecated. We are still using the classic way. So it would make sense to actually move to the non-deprecated way sooner than later. And it should not be a huge change, mostly because due to the fact that in Fedora 39, Silver, Blue, and Kinoid are already doing it. If they are going to be successful, and I really hope that they are, we will just have to copy whatever they have done in the previous release. So it should be something reasonably easy to do. And the other thing that we have been discussing, even though there is no clear consensus on anything exactly around us, is more flock bugs. And this is more on the Serechea side than this Weiss bin. And the reason is that, for instance, I'm not very happy about having Firefox in the base image. I don't like it to be there, also because on how Firefox depends on FFMPEG, and a very specific version of FFMPEG, which has some limits, and how the RPM OS3 behaves with FFMPEG's substitution of packages, which makes everything a little bit more complex. So I hope personally to be able to move to maybe Firefox and other applications in flatbacks. I think it would make more sense, but I also understand that at the moment is not something that is going to happen for Fedora 40. Maybe it will happen later, but still add something I'm thinking about. And even here, I would expect Silverblue to be the first one to move to flatbacks many applications before we actually do the thing. We are a very small group of people doing this, and also we are active in other parts of Fedora, and we have other daily jobs as well. So in the end, we tend to be a little bit trailing on changes. It's like, oh, we are seeing a very interesting change in Silverblue. Let's see how they are going to implement, how it's going for them. If it's going to be successful for them, then we are also going to do the same thing so that we have a little bit less burden there. So are there questions? I was just wondering what would you say was your biggest challenge in bringing up a new spin? So the change proposal part, I suppose, is kind of planning and sorting out what needs to be done, but then actually implementing it. Were there any big challenges that you faced? Yeah, well, first of all, the change itself. I would say it's mostly three things. One is comms, so effectively groups of things. One is the kickstart for the Swicebin, and the third one is the RPMOS3 part of the build. Of the three, the most problematic one has been the RPMOS3 part. And the reason is that at the moment, we don't have that many RPMOS3 editions of Fedora, so the process is not really very documented. It's also not very straightforward. I think that we did changes on three or four different Git repos to actually get those images properly built and tagged and shipped, as you would imagine them to be. Well, for instance, Kickstarter, it was just one reference to that file, but in the same repo, and that's it. So effectively, that part was a little bit more complex, also because at the moment, I think there are five artifacts that are delivered as RPMOS3. Some of them are built in a certain way. Others are built in a different way. So it was not that easy to just say, oh, let's speak how IoT is done and then do the same because actually IoT is slightly different. So we ended up picking, I think, Kinoit copying what they were doing and then trying a couple of times to make things working properly. Cool. Maybe just a slightly simpler question. I have used Swaya on Fedora, but it wasn't from the spin. Does it ship them with some basic key mappings to pull up different applications, or is it just the default ones? It's just the default ones. In the sense that we have thought about doing also the configurations, Swaya configuration, Waybar configurations, is very, very close to the upstream ones. We have thought about changing them much, and then we decided not to, mostly because we did not have good ideas on how to improve them. So it was like, well, if we get someone from the Fedora UI UX team that tells us, oh, you should do this and that, OK, we can do that. But we are engineers, so not the best kind of people to make those decisions. And also, I think that the reality is that 99. something percent of Swaya users will have their own configurations. That was going to be my follow-up. I think most people just pull that in, because it's highly personal to each developer. Yeah, and that is also the reason why we're, at the beginning, thinking about providing a version, mostly in the Serychia part, the PMOS 3 part, without any application, or very close to it. Because the idea was, since everyone wanted a different term, a different image viewer and so on, why should we make a choice? Can't we just ship something that the base part works for everyone and then everyone can build on top of it? Then we decided to be a little bit more user-friendly than that. But still, it's very easy to put your own applications. And for instance, for me it was a new thing, IMV. I used to use FEI. But in reality, they are so similar that I moved to IMV fairly quickly. Okay. Thank you, Fabio. There are also a bunch of links here, and I will upload the slides on SCAD so that you can click stuff.