Egos ruining Open Source projects, distros vs software conflicts - Linux Weekly News

[00:00:00]I think I found the ultimate hack to get my hair back. I just stand further from the camera. Nope. Nope. Nope. Still not there. Terrible. Anyway, in this Linux and open source news show, we have Egos ruining some open source projects again.

[00:00:12]Apparently, this time it is flatub. We also have the usual conflict of distributions versus software.

[00:00:18]Basically, stable or LTS distros are really struggling to catch up with updates. And this seems to create issues not only with CVEs in the Linux kernel, but also for graphical applications.

[00:00:29]We'll talk about this. You'll get the TLDDR of the video I made earlier this week. And we also have plenty of cool updates to software. Some uh terrible things happening and some good things happening, including uh this segue to our sponsor. This video is sponsored by Proton Mail. You all know what they do.

[00:00:45]They are your end to end and zero access encrypted solution for email. They can't read your emails. They don't know the contents of it. No one can apart from you. And they are also giving you all the tools that you need to stay safe from fishing attempts, from spam. They remove trackers inside of your emails.

[00:01:01]And you've got all the organizational features that you might need to make sure that your email stays in your own control, including email aliases and all of that stuff. And on top of that, when you create your free account for Proton Mail, you also get access to their entire suite of services, including a VPN, a password manager, some storage space online, a Google Docs, and a Google Sheets alternative as well. and plenty of other stuff. And if you want to go further, get more storage space, get more features, they of course have paid plans. I personally do use Proton Mail for all my personal email. I also use their VPN and plenty of their other services. I really enjoy what they're doing. They've been a sponsor of the channel for a long while. And as usual, if you want to give them a shot, the link is down in the description. Let's begin with the usual dispute of application as developed versus distributions, modify our UI, ship all the versions of apps. This debate is back again. I made a dedicated video on that. So, if you watched it, just skip to the next topics. But if you didn't and you want the TLDDR, here it is. This time, it's Gnome Calendar specifically versus Linux Mint. But, of course, this is symptomatic of a bigger problem. One of the main developers of Gnome Calendar accused Linux Mint of shipping outdated and modified versions of their software while using the Gnome Calendar branding and support links. Which obviously means users of Mint that encounter an issue will turn to the Gnome calendar developers for support and bug reports where these issues might not exist anymore in the app or might not even have ever existed in the app because they might have been introduced by Linux Mint itself. Mint tends to be very conservative with their software versions and the version of calendar that they ship is not supported by the upstream developers nowadays. It's like more than two years old at that point.

[00:02:44]So the Gnome calendar developers asked Mint to replace the support links with their own and to change the icon and branding of the app so users don't confuse what Mint ships with the actual application in its supported form.

[00:02:55]Mint's founder Claymore Lefer said that Mint bases their work on the Ubuntu and Debian packages for this and if they remove their own version of the app, users would still rely on the older unsupported versions that Debian or Ubuntu ship. Lev then closed the GitLab issue that was created for the problem, saying that Upstream wants title control over how their software is distributed and that it is up to Gnome calendar to switch licenses if they want that. And as usual, the conversation devolved into not my problem, not mine either, which is highly unproductive. I already made my point in the dedicated video. You might want to go check it out on the channel if you haven't watched it. But the gist of the issue is distributions misrepresent the work of actual developers when they ship versions that are fully out ofd the name of the app when you're using Gnome Calendar 46. But that's also true of 2.10, which is in the same repos or an old version of Libre Office. users don't necessarily know that they use an old version of that application and so they might report bugs, spend their own time trying to help and get told by the developers you're using a fully outdated version so we can't really help you there which is frustrating for the person spending time writing the bug report and frustrating for the developer who is answering the same question for the 20th time. I fully think that distributions if they want to keep old software in their repos that is unsupported end of life because yes graphical apps just like Linux kernels have end of life dates they should rename those applications and make a fork of it or at least patch in some kind of warning in the about page or in the support links to warn users that this version is no longer supported by the application developers. Just because the license allows you to package a very old version of something doesn't mean you should do it. Yes, it is allowed.

[00:04:44]But it is also a very bad practice in terms of security, in terms of bugs, and in terms of representing the actual work that went in there. And if you're thinking, "Oh, it's just a calendar.

[00:04:54]It's from the Gnome devs. They're annoying." Whatever. It is the same problem with the with Libri Office, with Linux kernels, with any other part of a distribution that is not kept up to date properly. it is not representing the actual state of the current application while still using the name of said apps. It is not just a Gnome calendar problem. Go check out the video I made if you want to learn more about this. And still on that same issue, we've got the Linux kernel team who published 432 CVEEs in the span of two days. This is an insane number of issues being published and disclosed and obviously fixed as well by the Linux kernel security team which means it makes it extremely difficult to handle all of those CVEes for distributions because if you follow the release schedule of the Linux kernel and you update to a supported version or you were already using a supported version then you'll get all of these fixes immediately but if you use an end of life Linux kernel that you backport fixes to how are you going to triage 400 132 CVEes to backport into your kernel.

[00:05:58]This will obviously be very complicated and this raised questions about the utility of the CVE system to triage and prioritize these vulnerabilities. How to review these problems? Of course, this flood comes from mostly AI generated bug reports. Not all of them are major problems that absolutely require a patch immediately for every system. And as Greg Koha Hartman said, at the level the kernel operates at, any bug that can affect the running system could be classified as a vulnerability. Now, of course, this creates an issue for kernel developers and maintainers because they have to patch these issues. But it also points a very big workload at distributions that don't use a supported version of the kernel and will have to sift through all those 432 CVEes, decide which patches they will give to their users and which ones they will not. And obviously this will result in worse outcomes for the users of set distros because they don't get all the patches because no DRO is going to backport every single one of them in a suitable time frame. Now in the end the number of CVEes uh is a good thing. It means we have fewer security holes in the Linux kernel. They've all been fixed as far as I could tell. So that's an enormous amount of work done to patch all these issues and to distribute fixes. The main problem here is once again distributions that do not ship supported versions of software, they basically decided to give themselves a lot of extra work. They seem to do it mostly for the Linux kernel. They seem to not do it mostly for graphical applications, which is sort of not an equal treatment of software. I would say in the end though it will result in worse outcomes for users of set dros because you will probably not get all the patches for all these things in all the old LTS distro stable dros that use an endof life kernel in there and I think this really seems to indicate that distros should at least move to the latest supported version of software doesn't mean they should use the very latest update that just released that might be buggy but an old version that is still supported that is one year old. I think you can safely move to that and I think distros should absolutely do it instead of creating extra workloads for them and generating user bug reports that are no longer valid because the issue has actually been fixed already. They're just using an old version and didn't know about it.

[00:08:20]Now let's talk about egos in open source. And I will always be amazed at the capacity of open source projects to draw in people with delusions of grandeur or massive egos. And this time it looks like it's about flatub. One reviewer will leave their position as a FlatHub reviewer after 5 years helping and contributing to FlatHub and another reviewer is apparently pondering the same move after 10 years of involvement.

[00:08:44]So what happened is an application was banned from FlatHub after the developer made some rude remarks to the reviewers.

[00:08:50]But apparently they appealed and that application was then unblocked by someone called Bart who apparently can override the decision that the maintainers are making. This led to the application developer then resubmitting their application for inclusion. But apparently there was zero communication to inform the actual reviewers that the application had been unbanned. So it got banned again. And then the person called Bart then told the reviewer to take a walk that he had no energy to babysit him and another reviewer which was not even involved in this topic at all. So that person asked Bart to go easy on their tone and to stay polite. and they were told that apparently someone had sent a complaint about them which no one seemed to be informed of. The reviewer in question told Bart that he was not the dictator of FlatHub and he should tone it down and in response he apparently got a veiled threat and Bart told them that they kind of were the dictator of Flat Hub. Anyway, this devolved quickly after that and this led to this reviewer leaving and Hub the person who originally banned the application apparently expressing their intention to leave too. This was apparently the culmination of many other problems. This Bart person apparently overrode decisions without any discussion, no formal structure is in place for app reviews combined with issues with free desktop SDK maintainers, weird requests for removals and AI slop pull requests mounting. And this all culminated in these people planning to leave FlatHub entirely. And I don't know any of the persons involved. Uh I have just heard that the person who announced that they're leaving was apparently very helpful for other people to try and get them to build flatback apps and getting onto FlatHub. That's about it. So I have no stake or no specific site to take. But it does look like the usual uh person with a massive ego deciding that since there's a hole in terms of governance, they're going to fill it and they're going to make decisions based on their own personal preferences instead of actually conforming to a guideline.

[00:10:43]Please open source projects. I know it's annoying. Put in some formal structure.

[00:10:47]It's project management 101. When there's more than one person involved, you need guidelines. You need to say this is how we discuss those things.

[00:10:55]This is how we vote on those things.

[00:10:56]This is how the decisions are made. This is who gets to override them. This is how we communicate. This is the process.

[00:11:03]Once you have the process, then you start the work. Without process, you don't work at all. You need a formal structure when you have more than one person. This is just normal. Please implement those things and it will solve most of those conflicts. Not all of them, but a lot of them. Now, still on flatub, it looks like their decision to ban vibecoded software was indeed the right one. There were discussions around this that pointed out that this was basically prevent every new app from coming onto flatub because AI is so widely used for app development now. But apparently threearters of the applications that were rejected are already dead, having lived for a few months at most. The developer looked at 120 repos that requested to be included on FlatHub and were rejected because of their heavy AI use. 88 out of those 120 apps are no longer actively developed.

[00:11:54]Some have even deleted the entire source code and 32 still live right now. That is 73% of these applications that just do not exist anymore and would be basically zombie apps on FlatHub. So accepting these applications would have swamped reviewers for months just to have this software never get a single update, bug fix or security fix. Now there is another angle to this. Uh maybe these applications were abandoned because their developers realized they would never be able to distribute them uh in any place that matters because getting into a distros repo is pretty difficult. Getting onto a contributed user software like the AUR is no recipe for success either. And getting onto Flat Hub was for a long while the main way you had to distribute your apps to a lot of people. If that door is closed forever for you because you are never going to not use AI to write your app, then you might as well just give up on it or realize, you know what, I made it for my own use. Might as well just keep the code for myself and I'm not even going to try to publish it. So maybe closing the door on these apps also made them just peter out and die after all.

[00:12:59]Who knows? But the fact of the matter is these applications were abandoned after a while. So it also still probably means that they were never intended to be actual projects that kept on as time went on. Now Kolabora announced a preview of Holo Core, which is the operating system that they're building for Valve to run the upcoming Steam frame. This is very interesting work. Uh it is a straight port of Arch Linux for ARM 64, something that Arch apparently doesn't do themselves right now. All Arch packages are not rebuilt yet for ARM. The goal is first to have all the necessary packages to build and run software on the Steam frame, but that is still many thousands of packages to handle and a full CI system to test things. There were apparently many technical challenges involved in that, like figuring out the order in which to rebuild the packages and their entire dependency chain, dodging packages that could not work on ARM 64 at all, and the ones that needed more stuff to be built correctly, those needed to be fixed, and there are other things of that ilk.

[00:14:02]Basically, the dependency hell, but in developer form. They say that their port is mature enough to be experimented with right now and that they will work with Arch directly to help them port the DRO to ARM 64. Apparently, the end goal is not just to build Steam OS for ARM. It is to have a full ARM build for Arch that they will base their work on, which should help many other people, not just Steam OS users. It is really cool stuff.

[00:14:27]Although since this is still experimental, I would wager that the Steam frame is pretty far away because I don't see Valve shipping it with a fully experimental, not fully tested, not fully finished operating system. Who knows, maybe they will. Uh, but judging from the state this OS is being described as. I don't think it is ready to be shipped in an actual product. But of course, I didn't try it out, so you'll correct me if I'm wrong. As you know, we'll be changing how they're handling vulnerabilities. They're going from a 90-day disclosure window, which is the standard almost everywhere, to a 30-day one. They say 90 days doesn't work well for Gnome specifically because almost all maintainers either fix the issue in one to three weeks or they will not fix the issue at all in the allotted time after which the vulnerability will be disclosed and then it's a little bit too late. They say that they will not differentiate either between AI generated reports and human-made reports because apparently reports that aren't AI generated are becoming more and more rare anyway. So it doesn't make sense to try and optimize for these reports specifically. Another change is that Gnome will no longer forward security reports at all to projects that prohibit the use of AI because most reports are AI generated. Most reports do not disclose the use of AI, and it would violate the project's policy to send them these reports anyway if you had not detected they were written with AI.

[00:15:51]Instead, Gnome will close the report entirely and inform the maintainer that this report exists and the maintainer will decide if they want to view that closed report and if they want to handle it or not. Of course, that only applies to projects who decided they will not accept any AI generated report. Other projects will still receive all the reports. On top of that, the person handling the security report tracking, Michael Katanzaro, will leave that position on November 2026, and they're looking for someone to take over that position. Our systems and trackers for vulnerabilities will absolutely need to evolve. We've seen this with the Linux kernel earlier in this episode, but this is also the case for big projects like Gnome, like KD, and others. It will need to be fixed. Uh, I know KD implemented some form of automated uh, system to close bug reports that are made for older versions. Maybe they also have something to detect AI generated reports that are blatantly AI, but that's not entirely sure. And at some point, I think most reports will be generated through AI anyway. So, this will need an evolution to handle all of that work. Uh this is something unique to open source specifically because you can view the code, you can run an LLM and you can point it at the developers and say hey just send them everything that you find which obviously generates a lot of volume and we were already strapped for time to review all the humanmade reports. So with that added extra workload there needs to be an adjustment on how those things are handled. I have no clue how this will be solved but we are going to have to find a solution for this. Firefox 153 was released as the last monthly update before Firefox moves to their faster schedule. This one comes with containers which lets you separate tabs in their own little common sandboxes. So cookies are fully separated between containers which can help with testing websites and web apps or just limit tracking between websites.

[00:17:44]So you can for example have all your personal tabs in a container, all your work rellated tabs in another. There are four preconfigured ones, but of course, you can manage them, remove them, and create new ones. You can also now share a website by generating a QR code straight from Firefox. The PDF editor now lets you drag and drop another document on top of the one already opened to merge them, and then reorder pages, delete pages, and save that as a new document, whatever you need. It worked previously by just importing a document manually, but now you can just drag and drop it. Firefox also now supports rounded corners on Gnome. It was possible to enable it manually, but now it's on by default. You can now type labs or experiment in the URL bar and go in action to get to the Firefox Labs page. You can type pick to get a color picker action as well. If a website tracks your location, you will see a relevant red icon in the URL bar, too, so you know that they're currently using your location. Their AI mode smart window now lets you pick your preferred AI model from the assistant itself instead of having to go to the settings.

[00:18:46]And they added the URL bar back to the new tab page in the AI smart window mode, too. Nothing incredible that you couldn't already do with extensions, but it's still some good stuff that I'm sure will be useful to some people. The PDF editor in Firefox is actually one of the best PDF managers that we have on Linux because you can read documents, you can annotate them, you can reorder pages, you can delete pages, you can merge PDFs, and you can export that. That's more than a lot of PDF editors on Linux right now. You generally have to use multiple apps to do the same thing here.

[00:19:18]Now, Libri Office keeps hammering at the Microsoft document formats in a new blog post explaining how these are the tools that Microsoft uses to lock people in.

[00:19:28]Not necessarily the Office suite, but the file formats. So, you all know the usual. This file format is crucial.

[00:19:35]Proprietary formats create a dependency on software by linking the software you need to use to open the file that you created. Opening these formats in another app will generally result in broken documents. Of course, Microsoft formats are not proprietary. They're actually considered a standard, but Libri Office further explains that this isn't the reality. First, OOXML, which is the file format Microsoft uses, was ruled to be a standard after irregularities in the voting process.

[00:20:04]And the specification of that standard doesn't really conform to what you would expect. It is unusually complex, apparently thousands of pages, and it doesn't describe a format that is interoperable. It describes how Microsoft Office functions to write the format itself, including undocumented features, legacy features, and things that are specific to Microsoft source codes that are not really documented.

[00:20:29]So, this resulted in that standard not being applicable by anyone other than Microsoft. Most projects tried anyway because they had to, but nothing is fully compatible. To make things worse, there are two standards. Oxml strict, which was apparently easier to work with and was supposed to be the format Microsoft implemented, and OXML transitional, which is the current format that was meant as a stop gap to keep some legacy features alive, except Microsoft never moved away from that. As Libra Office says, the issue isn't just visual, as in your document is a bit mangled. It might mean that documents aren't matching between a client and its contractor. It might mean incorrect printing of forms or bills. They of course conclude that ODF is the ISO standard that should be implemented by anyone and is fully open and transparent. And this post is a welcome change from the usual attacks of the document foundation against other projects than Libra Office. And also they're right. ODF is the format that should be implemented by every office suite. OXML is not a standard because it is not documented properly. It should never have been accepted as a standard in that state. Now we see Germany pushing ODF as the only document format that they will use for intergovernmental exchanges. Hopefully more countries jump on that bandwagon too because this will basically let anyone move away from Windows and move to stuff like Libri Office very easily. This will open the gates very widely uh for people to move to another operating system than Windows. We have bad news for Jellifin, the media center that is basically like Plex that you might know about, but it is free software. The project leader as well as a longtime contributor both left the project and that comes shortly after one of Jellyfin's original developers also left. They said that the transition is amicable. There is no big drama or anything around that. Apparently, it doesn't place Jellyfin at risk of becoming an abandoned project. The reason is mostly burnout. The lead said that he simply could not provide the effort in terms of mental load or time that was required to lead such a project and as such he says he didn't do a great job and he faced severe burnout. He does decided to step aside which is quite honorable in my opinion. He also said that initially he felt jellyfin would only attract a few hundreds or a few thousands of users, but now it is more like millions of people using it and it is just too much to handle. The other contributor is leaving due to personal changes that mean he must focus his attention on something else and he will stay on for as long as needed to handle the transition in the roles that he filled like managing the Jellyfin app store, public outreach, finances and other admin related things. Now we have another solution coming to try and improve support for older applications that do not support Wayland natively or generally just want to use X11 but on systems where X11 doesn't really exist anymore. This is called lib X11 compat and it's trying to reimplement the XLB client library on top of the SDL library. So X11 apps could run more broadly on a variety of systems including Wayland only without X Wayland Android or Mac OS. This could let app developers make sure that their applications can run on something that just does not have an X11 server at all or doesn't have quartz on Mac OS or even on a headless environment without users needing to install specific components on their systems that might just not be available at all. Apparently, the codebase already runs a variety of applications like XMMS, most cute 2 applications without any Xserver being present on the system. Now, it is a pretty cool project. It might at some point allow people to run X11 apps, let's call them legacy apps that were not ported to Wayand on systems where XW Wayland is no longer available because that will probably happen at some point in the future. But I see it as a more interesting way to run X11 apps on Mac OS where as far as I remember a quartz which was their X11 server has disappeared. You can't really install it that easily anymore. Or on Android where as far as I know there is no X11 server at all. On Linux we do have X wayand. I don't see it going away anytime soon. It does had a minimal amount of latency but not that much and it will probably remain a more solid solution. But in the future, if X Wayan fully disappears, then this is a way to have an application packaged with its own basically suite of libraries that lets it run even though it doesn't support Wayand or anything else. We have an interesting blog post on the impacts of AI on open source. It's written by Jerry Aishman, a name I probably just butchered. He's a developer working at Red Hat on Firefox, Libra Office, Chromium, Nautilus, and others. Although of course this blog post is his opinion not reflective of what Red Hat thinks as a company. So what they pointed out in the blog post is first project inflation with AI the number of projects being created is on the rise obviously because people vibe code projects much faster than writing them by hand. This of course does not translate into highquality projects automatically. And just because something is published to GitHub under an open source license doesn't mean it is an open-source project because this codebase could just have been published and will never be touched again by the developer because there was no real involvement in its creation. There's no real attachment to that code and it could also just have been developed as a one-off to solve an issue the developer has in their own use case and they just put it on GitHub because why not? This might push DRO repos to make a comeback according to the author though because those are curated sources that would potentially ignore all the crappy projects that are completely unmaintained or just really badly written and would just add in the actually maintained projects that have some history and support. This is also something that led to FlatHub's anti-LM policy, which means they're not going to let any stupid vibecoded app in because this would result in a terrible quality of software being available on FlatHub and they would prefer have a more curated collection of software that users can actually rely upon. So, I guess they're also dodging that bullet here, but some other repos might not.

[00:26:46]The second issue that they point out is the overwhelming number of reviews needed for most open source projects.

[00:26:51]Because of course AI generated bug reports, vulnerability reports are a problem. There's just so many of them.

[00:26:58]We talked about multiple instances of that in this video. But also there are AI generated pull requests that contain enormous amounts of code that has just been vioded without human involvement and will waste maintainers time because even if the maintainer audits the code, asks for some modifications, chances are the person who sent this doesn't know how to fix the code and will never even reply. Open source projects were already strapped for time before that and now it's just unmanageable entirely. And finally, there's the lower motivation to publish code as LLMs basically piller all the open source code. If you publish something as open source, it will invariably lead to that code being used to train an LLM which will then be used to spit out copies of your project with the open source license removed. So why bother creating an open source project?

[00:27:47]There's also a view emerging apparently that why would you bother even using an open-source project when you can just generate your own thing that works how you like. I think this is a very optimistic take on what AI can actually accomplish for a very simple audio player. Maybe for something like WordPress or the Linux kernel, I doubt that you would be able to AI generate something that works as well. And then there's the image problem that some people have with open source because some people seem to think that just because the open source code is visible and usable by anyone, it is easier to hack into. And as AI generated bug reports are now everywhere, it creates the feeling that open source applications and open source software is not secure when of course closed source projects likely have the exact same number of issues. They just don't disclose them because no one can read the code. Now the author concludes that it is probably a temporary phase. It is basically a craze. People are jumping onto AI tools trying to vibe code a bunch of stuff pushing it everywhere then abandoning it then trying to contribute to projects then never answering anything. But this will probably die down and in the end you'll just have competent developers using AI to streamline their work to do the busy work for them and still contribute some actual value and still create some actual valuable project. Some issues the author says will not be fixed by just time alone. But he is still relatively optimistic on how these things should go. And I do agree with that. I think we are in for three maybe four years of absolute nightmarish chaos due to AI and then people will realize it is just not capable of replacing actual skills entirely and that it is a compliment to those skills and the people who are improperly using those tools to create the craft and the crap and the slob will just stop doing it and the people who actually know how to use those tools to improve their existing skills, those are the people that will still use those tools. Speaking of tools, if you want a highly Linux compatible computer, do check out our sponsor, Tuxedo Computers.

[00:29:51]You all know about Tuxedo if you've listened to a single one of these episodes for the past like two years.

[00:29:55]They're a manufacturer that makes Linux hardware, laptops, desktops. They all ship with Linux pre-installed. And of course, the hardware inside is very, very Linux compatible. They contribute their drivers upstream. And they have their own repo if you want to install drivers on dros that might not have the latest version of the Linux kernel. for example, they have devices for virtually every use case and every price point.

[00:30:17]Whether you want a laptop, a desktop, something for office work, something for gaming, a workstation, whatever. You can pick the hardware inside. You can pick the keyboard layout. You can pick the logo you want engraved on it. And I personally only use Tuxedo Computers uh to do everything that you see or hear from me. I've been reliant on their devices for I think two or three years by now. They've been sponsoring the channel for a very, very long while. So, uh do check them out. The link as usual is down in the description. Anyway, this will conclude today's episode. As usual, you have all the YouTube buttons, comment section, whatever. It is extremely important that you do interact with those in today's day and age cuz that's how YouTube recommends the stuff and that's how this channel survives these days, basically. So, if you want, do click on those and you also have plenty of links down in the description to support the channel more directly.

[00:31:03]I'll let you take a look at that. Thank you all for watching and I guess you'll see me in the next one next week. Bye.

[00:31:23]Jack.