 Veliko v FEDERALISTE Partij. We tried to do a slightly different model this time. Basically, FEDERALISTE 36, this time is a track in DEVCORN Mini. So as always I will have an opening talk about what's new in federal workstation, kaj je default desktop edisyšnja Fedora, in pravda je to, da je najbolj zelo. Tako, ne zelo. Tako, zelo. Zelo, da bomo, da bomo, da bomo, da bomo, da bomo, da bomo, da bomo, da bomo, da bomo, da bomo, da bomo, da bomo, da bomo, da bomo. Zelo, da bomo. Zelo, da bomo. Zelo, da bomo. Zelo, da bomo. Zelo, da bomo. Zelo, da bomo. Zelo, da bomo. Zelo, da bomo. Zelo, da bomo, da bomo. Zelo, da bomo. Zelo, da bomo. Zelo, da bomo, da bomo. Zelo, da bomo. Zelo, da bomo. Zelo, da bomo. Zelo, da bomo. nadala, da j Nosovaj njega, da darstvite in skupaj. Ten traž vozor, ko je ne v nožjo, ker srani AdVita Dark je vzal, lahko spotravila, czekaj pomečo ta vsev, ki je srani AdVita Dark in še... tako zelo. This is a slightly different approach, so instead of basically enforcing some theme for all applications, which is, this is not even possible a little bit, but by they basically just have an API that lets other applications know that the user prefers dark mode, and the application itself decides, okay, I actually support dark mode, so I will switch to it. Or I don't support it, I only support light mode or one specific theme, so I will just ignore it. I mean, this way it basically avoids the problems I described before, that, you know, for example, applying the dark mode would basically ruin or would break the application interface. So it's on the developer and the application to decide if they want to adhere to this setting or not. And it's actually not an invention of GNOME, it was originally developed by elementary OS people, and GNOME just used that, and I think KD joined the code as well, so it's, I think it's becoming de facto Linux standard, this API for switching between light and dark mode. As I mentioned in GTK4, and Libarvaita has a slightly different theming than GTK3, and in Fedora 36, definitely not all applications are ported to GTK4 than Libarvaita. Even, for example, the default file browser in Autilus is still GTK3, and you could notice that the theming is not too different, but it's still different. So the consistency, as we are used to from GNOME, is not really on that level at the moment, until most, like all applications are ported to GTK4. On the other hand, there is a way around it. Like the designers decided they don't want to backport the Libarvaita theme to GTK3, because there would be, it would not be 100% good or successful, so they decided to keep the old GTK3 Advaita there, and then they introduced a new theme for GTK4 and Libarvaita. On the other hand, there is a Linux community, and there is one guy who started working on, we actually wrote an article on myfedora.cz about it, so the name of the theme is Basic Advaita GTK3. You can download it, you can install it, and then you can switch to it. There is, you can do it, for example, so this, this is switching, so this switches to all GTK3 applications to a theme that is really similar or almost identical to GTK4. So then you can get the same consistency with some minor glitches, but it's not really noticeable, and then you basically get the same level of consistency like before. All GNOME applications look alike. And then you can always switch, switch back. So that's the theming. Another thing, when I'm already in settings, is change in screen sharing. Allow screen sharing. So basically, until this release, GNOME was using VNC protocol for screen sharing. With this release, it switched to RDP. RDP is definitely more advanced protocol than VNC. It has better performance, more features, et cetera. So it has a completely new interface. It's slightly, for example, the others, et cetera, it's slightly different, so it adherses the RDP protocol. Sadly, it doesn't work that reliably at the moment. I think there's still quite a lot of work to do there. So the VNC one that was before was more reliable. RDP one will hopefully be in the future with all the advanced features there as well. Okay. The change is from in apps. So Fedora 36 Workstation change did the default text editor. So it used to have g-edit, but GNOME, and then because Fedora usually follows the decisions in upstains, the GNOME decided to adopt the GNOME text editor like a very simple name instead of g-edit. The main reason behind it is that the g-edit developers were not really interested in porting g-edit to g-tk4 in libadvajta. So there was a bit of difference in opinions. So other developers in GNOME developed a new text editor. Basically it uses g-tk source view and all the libraries behind it like g-edit. It's written in g-tk4 in libadvajta and it has all the new features like it. You can also change the themes here. It should also follow the preference of theme as I mentioned here. Or you can overload that by some application color scheme here. It looks pretty nice. It's faster than g-edit because it uses OpenGL for rendering. It has autosave, et cetera. It's not extremely advanced text editor. If you are used to something like VIM, it probably won't satisfy you. On the other hand, it's just a default text editor. So if you just want to edit some text and it opens from now till soon days, then it's fine. Another application that was introduced with GNOME 42 was GNOME console that should replace GNOME terminal in the future. Basically the problem there is the same. GNOME terminal developers are not really keen for switching to GTK4, et cetera. Other developers introduced GNOME console. That should be the default terminal in the future. And again, both applications will live under GNOME. I guess the GNOME terminal will be for more advanced users. GNOME console will be more simpler to use and probably more like better looking, et cetera. So the users can decide what to use. Currently, Fedora 36 is still using GNOME terminal because we don't feel that... Or we don't think the GNOME console is there yet. Actually, Fedora Workstation may switch to it as well. Then the default video player totem also had some changes. It no longer depends on clutter and it uses OpenGL widgets. So the cupcakes are here. I will finish soon and we can have a short break for cupcakes. Totem uses OpenGL widgets. I must say it's much faster the video playback. Before, on less powerful computers totem always felt slower and then, for example, VLC or mPlayer, et cetera, now it seems to be on the same level. So definitely an improvement. Then in evolution... It's not the default email client, but it's still under GNOME underla. You can find it in Fedora repositories. This feature is that you can now use Markdown for writing emails. So if you are familiar with Markdown or it's the language you like for formatting, then there is a difference with this nice feature. In boxes, the desktop virtualization, this dialogue, this whole, were completely redesigned as if to follow the GNOME user interface guidelines. So that's for the applications. Just a last couple of things. Fedora 36 Workstation also uses Terker 3.3. Terker is basically an indexer. And it carries a database of metadata about files and documents you have on your disk. With the third generation of Terker, there were completely changed architecture so that it's much more privacy oriented. For example, applications now cannot see all the Terker indexes, but only the ones that they have created or they have access to. On the other hand, it was at the expense of the performance. So since the switch, the developers have been working on improving the performance. Especially with this release, it improved a lot. The indexing is faster. Memory consumption is down by 50%. And the startup of indexers is two-thirds lower than it was before. So the whole indexing should be... Basically, it's a thing that you shouldn't even be bothered by. It just runs on the background and it should take as least resources as possible. Another thing, another change is that there is much faster input devices. So that's another thing that they've been trying to improve in GNOME in general for a long time. So one of the things they change in this release is that the input events are now much less processed by the high-level javascript code in GNOME shell and it's left on the low-level parts which are usually in C and much faster. Another thing they change is that the input devices now can set their own frequency. So if, for example, some gaming mouse uses 1,000 Hz frequency, then it's basically now possible in GNOME as well. So especially for gamers now, the input devices should be much snappier and faster. I think when they did some benchmarking, they got the latency of input devices as low as 2 milliseconds. And that's basically it for me. So it's about time. So I wonder if you have any questions to this talk or if we can switch to the panel discussion or to cupcake eating. So any questions? I have questions about switching through light to dark. Does it have some schedule, for example, to switch in the evening to the dark theme and to switch to the... Not yet. It doesn't have at the moment in this version, but it's something that is being discussed. It's a pretty frequent request because I think at least in macOS it has some scheduling. So I guess they will eventually introduce it because, for example, for nightlight it actually has a scheduler. So if they have it for nightlight, I suppose that at some point they will introduce it for... for theme switching as well. We wanna follow with the panel discussion, basically ask anything about Fedora or can just discuss different topics about Fedora, like open floor. So basically it's me, I work for the desktop team in our head and I've been a long time Fedora contributor basically for over a decade. I'm Francis Zloka and I'm working as Fedora quality engineer for a few years and I've been Fedora contributor for a few more before that. And my name is Lukas Ruzička and I work with Franta at Fedora QE. Basically I do release validation and open QA testing. Any questions, any topics? We've got really cool microphone to throw at you. Does it work? So I would like to ask whether there is something like GNOME vision, like in which direction we can and should expect the GNOME desktop to develop. And maybe if it's possible to put the changes that you are presenting in the past half an hour in the context of such vision. That's a tough question. I mean definitely, I don't think there is some official vision like a document, ok, we are gonna do this in next 5-10 years. On the other hand, the community is definitely trying to work on something like that. I know that for example Alan Day, basically the main GNOME designer, if you follow his blog, I think it's just like a year or two he basically published a set of articles about what they wanna achieve with GNOME in the future. And a lot of those changes that basically landed in the last that is where they are mentioned. Of course, one thing is the vision, the other thing is the reality. The designers, they have lots of ideas, but the developer services are always limited. So I know that a lot of features that they have for GNOME shell et cetera that have been postponed and postponed for years, because there are no developers to work on that or not enough. And basically the approach of GNOME generally is that instead of doing more with less quality, it's better to do less with some quality. So that could, for example, be like a distinguishing thing from KDE, where they are more into advanced features that the cost that the code base is huge and it's really hard to maintain it and it's not always with the best quality. But the advanced users are fine with that. So GNOME is rather for... I mean, GNOME is often criticized for game moving features or not having enough features. But it's not like the community wouldn't like to have more features, but it's really the mindset is we just want to do just what we can do in certain quality. If we can't do it in that quality, then we don't do it. So if GNOME would have twice as many developers, then they would introduce definitely more features. And for the vision, there is also some direction set by the GNOME foundation. So for example, one of the visions they now have is sort of like cloudless computing. Because these days all the user data are in the cloud. And if you want to have, for example, synchronization between computers, it's usually like you have to use some service like Google, et cetera. And one of the fresh visions of GNOME is that they would like to give users some way to actually achieve the same features, but without relying on cloud providers. So I'm still wondering how they want... I mean, it's mostly like some peer-to-peer syncing, et cetera. But they want to really do... Your data should stay in your computer and, for example, sync to another machine, et cetera. Do a backup to a device you or disk you choose, but not to like 100% rely with these features on cloud provider. So that's one of the fresh visions GNOME has. But it's still not really reflected in the feature set currently, because it was introduced just sometime ago. But if you want to know about the visions, then today his blog is definitely worth following. Then GNOME wiki page with the section for the design team or the ideas are there waiting for implementation, so you want to see what the designers are thinking about and what could potentially be implemented in the future is there as well. And then probably following implementation, they also have some official releases of this. Those are like, I would say, test sources for the vision. Probably don't have any comments. OK. Any other question? Fedora is related for change. Thanks. I'm interested about the different desktop environments, specifically cinnamon. Do you have any updates here? Anything interesting going on here? I personally don't. I mean, the thing is that like Red Hat itself and for example the desktop team in Red Hat is really involved in the GNOME because we work on GNOME and then we've got in Red Hat we have one person working on Groot and KDE, and that's basically it. So all our expertise is invested in GNOME because that's what we also use in other enterprise linux, et cetera. And all the other desktop environments are basically community-based. So there is a SIG which is a special interest group related to cinnamon or all the other desktop environments that's basically on them what plans they have. I mean, Red Hat has no say, no control over that, so they get to decide what version of the environment they wanna switch to what default theme default applications they wanna use and also they are in charge of the quality. So we as Red Hat because Fedora QA and guys like František and Lukas, as Red Hat we can have some control or assurances about the quality of the default editions, like workstations server, what's the third one? IoT. And cloud. So that's where Red Hat and the head supported teams are doing the testing of all the other desktop environments that's relies solely on the community people. Just from QE perspective we aren't doing any validation testing. We have pretty large test matrices that all needs to pass for Fedora to be released and we don't care as far as I know about other desktops. If somebody reports bug we can ping developers but we won't release because of second class desktops. I will talk about this in my talk in an hour I suppose how we do validation testing and Cinnamon for example is currently not part of that validation testing because we don't have resources to do so but it's community driven and if somebody we have mechanisms how the community could drop in and help us test it for example so if you would be interested in testing Cinnamon it's not a problem and we have the tools and we have the mechanisms so yeah. It's also an opportunity for people from the community because you can actually be in charge of that edition or version of Fedora so it's if there is someone interested in Cinnamon can go contribute to that and as always in open source the people who are doing the work are the ones that decide about it and it works and in this case so I can't really say much about the other desktop environments because we have no control or no insight in their planning it's really up to those sub communities in Fedora. I would like to ask Franta about like bugzillas and how does it look like from the birds perspective whether you are attached to fix majority of them or if you have an idea can you repeat the second part of the question like how are the numbers if more of them are coming and what is the ratio of successful resolution if you have just general feeling I know that you are not prepared for this I don't have exact numbers in my head but I don't know about all the components but for example many parts of GNOME the developers or maintainers don't pay attention to bugzillas and they care about issues reported on GitLab which is also problem for our processes because for example if we have some we have decided something is blocking issue in Fedora we need to create two entries one in GitLab so GNOME developers notice and one in bugzillas so we can process it through our mechanisms but I don't have any trends or numbers in my head sorry to steal the question but from my point of view I sometimes feel that that lots of those bugzillas remain unanswered or unless it's a big problem that might slow down Fedora releases in that case it's pretty much fixed very soon but if it's like a minor issue then the responsiveness is not so high and there are bugs between releases for example that get reported for one release say 34 and then they get moved to 35 and 36 and they still are not answered we have quite a number of those two put some perspective from a team that works on it upstream and that's basically through at least in our case mostly one of the reasons is basically we have for example one in fact one maintainer for most in Fedora so basically we have quite a few people working on those components upstream and they do care about Fedora but they are not really directly involved in the downstream processes so usually it works the way that we fix bugs and implement features upstream and then the actual packaging is done in mass by a single person on the team and that person is supposed to be the interface between Fedora and the rest of the team on the other hand it's simply not possible for a single person so that's why people usually prefer having those conversations in the upstream bugzilla because I mean it's from the perspective of the upstream developer it's also the duplication of places like you have to look for bugs there and there and those people usually work on RL as well so they also have to look into bugzilla for several RL releases and believe me the developers are definitely overwhelmed by the number of bugzillas some of them even work on several upstream projects so it's like github, githlab bugzilla so I mean ideally and I feel the pain of the users that for example reported back in bugzilla and they it's not answered on the other hand like I also see it from the point of the upstream developer so I have one more remark also the upstream projects that are not specifically related to Fedora and they have those issues on githlab or github for example so they work maybe better in fixing those bugs or responding to them because they are also visited by people from other distros so if the distros share something like pipe wire for example is now part of different distributions so those bug trackers get visited much more often and by much more much more people than the redhead bugzilla so it's also really useful to do it upstream perhaps if you have a bug that you need to fix then do it in redhead bugzilla because that would be just Fedora related over time just last remark another aspect that plays role here is also that for example githlab or githlab more pleasant to use than bugzilla that's simply when GNOME switched from bugzilla to githlab the number of interactions between developers and users and even number of contributors just increased because it's more bugzilla, I know that there are people who are used to it and they like it on the other hand most people just don't because it's interface from 90s and people are used to these days to different features etc in githlab you can upload screenshots directly in the comments and it's just much more pleasant and that's another reason why for example developers tend to stick to upstream githlab for example or githab instead of having those conversations with people in bugzilla so I hope that in the future Federa will also make the decision and switch to something that is newer than bugzilla just one last small remark one of the reasons why some developers don't pay that much of an attention to bugzilla might be abrt which is useful tool but for some components it generates so much number of bugreports that aren't repressible and people just get overwhelmed by hundreds of emails a day but they never really don't switch abrt yeah definitely I mean it's not so useful for bugreporting it's useful for bug prioritization and we definitely use it on the desktop team we look through the statistics and we see there is a cashier that has 100,000 occupancies then we know that we should focus on that and if there is a single user who reports that backtrace etc then it helps us to solve a problem that actually impacts like thousands of users because otherwise there are too many bugs to solve and this is like really nice guidance to what to pay attention ok, so thanks for your yeah, it does is there some popularity of installed packages sort of available in fedora like Debian popularity contest or something similar do we know what packages are popular and are used often what are used almost never or something like we don't have that so far fedora has been trying to collect as little information about user installations as possible I know there are some talks that if it's approved by the user that we would collect some metadata about the installations for example we already have a count in that basically it helps us count how many installations of which version of fedora are there and there are some talks about to extend it to for example a list of packages the users are having that would be incredibly useful for us because otherwise it's really difficult to see what's popular among people and what's not because all the polls etc. it doesn't really give you the picture of the reality because only a small portion of people usually not the correct sample of the whole user base participate on the other hand it's also a sensitive thing because people usually don't like information being collected from their system and uploaded somewhere even though it's anonymized etc so currently we don't take it and there is no concrete plan to do it there is some discussion so it may happen in the future but nothing concrete it's not exact way but you can kind of guess how much popularity from reports on the retrace server if something has many different issues it's probably used by more people than something that doesn't have any issues recorded yeah but that is mattering of how much it is broken there could be some correlation what is it you actually need I understood from what you said that there are a lot of bugs in us that we responded to and I got a feeling that you somehow assume the upstream developers would take a look at them on the other hand on the other hand you can for example just try to reproduce them and defer to upstream and just close the bugs in the upstream issues and help both the users and the number of bugs in that way yeah this is something that community members could do like watch their favorite projects and their bugs and report those issues if you could reproduce them to upstream because we don't have many hours for that we just care about issues and projects we test and support officially that should be the duty of the maintainer of the package that should be the middleman between the upstream developer and the user for example for my packages if I see a problem I report it I know it's most likely upstream bug I just go and report it upstream with all the data but yeah the thing is many people are not like the maintainers are not doing it it's the reality I know people who have dozens, even their community people like that for example they have one hour for federal everyday and they have dozens or hundreds of packages so it's not happening I mean it's not happening generally but it's early package from package there are maintainers who are beautiful and who do it, there's point users report bugs but federal has 30,000 packages or something like that it is also possible to set a custom text as a default text that is visible in bug 11 you create a new issue I did it for my packages I know it is possible so you should place the links to the upstream bug trackers to the bugzilla and somehow tell the people that they are much more likely their issues to be taken look at if they go directly to upstream Are you sure it's possible with redhead bugzilla which works for federal bugs is a bit different and there is some complicated setup that nobody understands properly I can ask somebody from infrastructure team about that but I barely think I've heard somebody saying that it's not possible for our case it might be supported by upstream bugzilla but I'm not sure if it's possible I'm talking about the bugzilla redhead.com I did a setup of that for the MariaDB and MySQL packages in the default message I ask users for example give me a result of that command to show me what packages you have installed so I have much better results because I know what I need to see from these Ok, so I was completely wrong wrong here maybe this is something that could be communicated somehow to package maintainers if they want to better guide users towards better bug reports Automatically they apply to I wonder if there could be one for all packages it's probably still on the maintainers if they want to do it or not but there could be some guidance about it it's not a bad idea in general I think it's better to tell the users the truth what is the status what manpower we have what they can expect than the bugzillas answered for even decades sometimes Well I also think that the package maintainers and developers or upstream developers are one group of people it's one part and also there is another part and it's the users who do not report bugs as frequently as we might want because sometimes we find bugs late in the process and they probably they were found before somebody probably arrived into them but they are not reported so I think it would also help if Fedora users would just report bugs for applications they like and they use daily and if it doesn't work so they would report the bug anywhere if it's in bugzilla if it's upstream it will be eventually found and forwarded but if it's not there then we don't know about it it is generally really hard to debug desktop application for user who don't know anything about that do you have for example of good ideas how to create minimal reproducers or something like that for desktop applications or a set of information that you would like to know most what is important for you to know to be able to debug that or at least to reproduce we have something on our federaviki on our QA pages but those weren't touched for a long time as far as I know and this is also something that interests me personally but of course it's a time problem but I am a supporter of report anything if you find a problem just tell us there is a problem and then someone else could debug it and maybe I know there is the ABRT tool in Fedora maybe it would be nice if there was a bug reporting tool that would easily enable users just to report a bug somewhere it could perhaps collect something from some information from the system automatically and send it so that we know about it this is quite a good idea or maybe pick up the pick up the or collect the information that are on the wiki page because the wiki page of Fedora QA is quite overwhelmed with various info and there was a landing page is it still so we were working on something called a landing page and I think that this is a good candidate to be placed on the landing page so what's the status it's pending deployment currently it's been put on hold because of lack of resources many my resources because I'm handling infrastructure stuff for our QA team it's been put on and we can ask our colleague Lukas about that idea about bug report at one note it's also a lot about timing you wanna really help with quality of Fedora and with bug reporting the most relevant time is early I think somewhere around alpha between alpha and beta and it's also the time when usually at least we are actually looking for users feedback once it's the Fedora is out and there is a bug you can bet all your money on the fact that it's gonna be reported and the developer will know about it because then it will be thousands of users impacted by that but if you really want to make a defense then please between alpha and beta and that's really the best time and usually that's when you also get the time from the developer because and it helps us as well a lot because that's actually a problem because the Fedora QA team they do the verification but for example for desktop applications very close to the final release and then until then no one nearly tests that from the community and then suddenly we get tons of there is blocking bugs that have to be solved in a week or two and there is like early little time so we would really appreciate if you know some community feedback earlier on for example around alpha and that's also when there is the highest chance to get those bugs really quickly I totally agree with that and I would say or add that there is no need to be running Rohide because this is something what people usually don't want to do on their production machines but it's I would say it's quite okay if you switch to the next release when it's branched so there is a date where from Rohide Fedora 30 something gets released or gets branched and if you wait a couple of days before the repositories settle down and then you switch to it it will mostly work and you will be able to find all the bugs there and report them on time and this really helps I am doing it but I am QA but I am doing it and it works this process works and I don't end up with a broken computer mostly just if you switch to branch the release right after branching blocker bugs and command bugs after the release because sometimes there are occurrences that something broken gets pushed to branched and it gets fixed by a next update but not for people who already installed the broken package we had to such occurrences that people running on branched had to manually intervene to have final behavior Thanks for your attention that you came here in the next talk