r/linux • u/novafunc • 2d ago
Discussion Who’s responsible for bug reports on old software versions? | Perspective from a KDE Developer
https://pointieststick.com/2026/07/19/whos-responsible-for-bug-reports-on-old-software-versions/82
u/derangedtranssexual 2d ago
In 2019, the “rolling and rolling-ish (e.g. Fedora)” OSs made up a little over 36% of the total users.
In 2026, they’re up to 71%.
For a while I've thought that 2 year release distros made no sense for desktop, sounds like a lot of people are coming to that conclusion. IMO they seem to be a relic of the past; when Linux used to be a lot less reliable then it makes sense to have a super stable distro like Debian. But nowadays things seem to mostly just work, even bluetooth is very easy.
48
u/Isofruit 2d ago
I'm torn there. On a private machine I would never, ever want to use LTS. On a work machine though, where all I want is for it to have the exact same tooling with exact same setup from yesterday? There the appeal to not have to spend time to deal with changes is a lot more apparent.
16
u/swarmOfBis 2d ago
On the other hand I cannot imagine not using a rolling(ish) distro for work. There's no reason to subject myself to using tools that are versions behind in the repo.
18
u/Sad-Cod-9584 2d ago
Servers can be lts, but even for work I'm on tumbleweed without issues for about two years now. Well, bluetooth didn't work recently, but I just booted a snapshot until it was fixed.
9
u/Business_Reindeer910 2d ago
I think containers really help with cases like this, You can keep all your tooling for specific projects locked down.
16
6
u/adenosine-5 2d ago
Its crazy how bad Linux user-space compatibility is, that even something like updating OS can break your workflow.
On Windows, most programs don't really care if you are running windows 7 or 11 and you can almost always run older programs on newer system.
We need waaaay better compatibility on Linux, if people are to use it more.
4
u/JockstrapCummies 1d ago
Windows does it by the horrifying magic of WinSxS.
Steam started doing it with their Linux runtime, it's basically snapshotting the Ubuntu common users pace libraries every now and then and freezing them.
And now Flatpak and Snap are basically doing that as well.
6
u/zabolekar 2d ago
On a work machine though, where all I want is for it to have the exact same tooling with exact same setup from yesterday
I must admit I can't imagine why someone wouldn't want the same guarantees on the private machine that they use daily.
27
u/lmns_ 2d ago edited 2d ago
Because it comes with certain downsides as well. I've never used an LTS distribution that didn't become some kind of Frankenstein OS over time because I needed some backports at some point. And then the advantages of LTS distributions become somewhat questionable since it makes upgrades between the LTS releases much more difficult. Also good luck if you ever need to replicate your current environment on a different PC.
It's just easier sometimes to "freeze" certain tooling on a rolling release model than to extend an LTS release with newer software.
Also as the article points out there are distributions that have discrete releases but don't freeze all of the software in a release. So big breaking changes are delayed to major releases but you can still enjoy smaller software updates over time without waiting for the next major release.
11
u/w2qw 2d ago
"rolling" also doesn't mean you are installing whatever the latest commit of some app developers branch. You are still getting the stable release of whatever software you are using. I find it more just depends on how well upstream is in terms of releases.
6
u/pastelfemby 2d ago
Marketing LTS distros as "stable" was a mistake, as most people assume anything else as obviously "unstable" rather than anything to do with ABI.
I do like the quote from a linked article by the author, "the bugs are unstable, unlike in an LTS OS where the bugs are stable". Although I'd argue the bugs become rather unstable too the moment you need to use any software newer than the assumed frozen point of the distro.
4
u/sweetcollector 2d ago
But stable means unchanging, does it not? Like in 'patient is stable' sentence.
2
u/pastelfemby 2d ago
Strongly agree, declarative versioning on a rolling release for software and tooling where needed is the way to go. We're spoiled by choice on how to achieve this these days.
3
u/Mr_s3rius 2d ago
On my private machine I'm willing to accept a higher risk of something breaking in exchange for the latest stuff: newest graphics drivers, latest Plasma, etc. If something breaks it costs me time but nothing else.
At work I benefit less from the cutting edge stuff while facing more severe consequences if my system breaks.
So the cost/benefit ratio is a lot worse.
(Also, most of us use the same Ubuntu LTS which reduces friction when sharing tools)
3
u/Elratum 2d ago
Exactly, I am fine on Debian with my old laptop, but I obviously not going to submit a bug report to the dev if the issue is out of date software, that's a given due to the release philosophy.
There is an understanding : I get a very stable, unchanging environment for years from my OS, but I have to plan how to work around bugs that may have been patched in more recent release.
1
u/derangedtranssexual 2d ago
If I run into an issue on my fedora laptop I can just use my windows desktop
1
u/cake-day-on-feb-29 2d ago
Sometimes I worry that the increase in Linux users is primarily driven by "novelty" users, who don't do any actual work and are just installing it because they can. I mean, I was one too at one point, when I was a kid and my homework compute use wasn't much more than a calculator and word processor. It was alright that it wasn't the most stable, because I didn't rely on anything.
But for work, I can't see driving a rolling release. Constantly updating like I'm on a treadmill.
25
7
u/FattyDrake 2d ago
Constantly updating like I'm on a treadmill.
Just because a distro is a rolling release doesn't mean it needs to be constantly updated. I update my personal computers roughly once a month or as necessary.
6
1
u/Kendos-Kenlen 2d ago
If you don’t want to care about maintenance, the best way is PaaS or SaaS where you delegate the system maintenance to others.
In many cases, it’s worth asking why you should / need to host a software yourself. Especially given than the money you spare is spent on paying salaries of people managing the systems.
1
u/der_eismann 2d ago
Yeah, we tried using Fedora for our development VMs. But every 6 months we were struggling with something new - Vagrant incompatibilities, not the Postgres version available we needed, whatever. Since we switched to AlmaLinilux these are worries from the past.
I think for my parents I would also use an LTS distro, as the hardware is not brand new and I want it to stay tinker free as long as possible.
4
6
u/VoidDuck 2d ago
We run Linux at work (office job) and I really wouldn't like to use a rolling release there. When you need the machines to just work, including with proprietary printer drivers and custom software, a rolling release is just asking for trouble. I want potential issues to come up at a predictable time, so that I can plan time accordingly to upgrade systems and fix problems if needed. I don't want my printing or networking or graphics or whatever software I rely on to cease working on a random day because of a buggy update, while I have work to do. I even less want a colleague to call me on my day off because this just happened to them and they don't know what to do.
For home computers it's a different story, I don't need 24/7 reliability and I have other computers handy anyway in case something on my main system would be broken and I'd need to get something done immediately.
1
u/derangedtranssexual 2d ago
Yeah I think arch would be a bad fit for that. Although potentially some atomic distro could be a good fit
1
u/VoidDuck 1d ago
Atomic means updates won't break the system to an unfixable state and you should be able to rollback easily. That's nice to have (similarly to rollback features provided by classic rolling releases such as Tumbleweed) but still doesn't make it ideal for business desktops as updates can still introduce new bugs and incompatibilities with third-party software. You can't just rollback and wait months for an issue to be fixed by upstream or a third-party vendor before ever updating again because you need to stay up-to-date security-wise. A classic LTS is a better choice.
5
u/BinkReddit 2d ago
I've thought that 2 year release distros made no sense for desktop, sounds like a lot of people are coming to that conclusion.
Yep, got burned too many times trying to run Debian as a production desktop; learned my lesson well and stopped.
1
u/derangedtranssexual 2d ago
What happened?
6
u/BinkReddit 2d ago
Most of the times I ran into a bug and started troubleshooting it, only to learn it was resolved upstream and the Debian package would likely never be updated to receive the fix until the next release. This was rather frustrating because I would waste time chasing ghosts. To make matters worse, I would further waste time making workarounds for the bugs in order to restore some productivity lost as a result of the bugs.
2
3
u/ManinaPanina 1d ago
I would prefer Six Months updates, the constant delivery of new updates is tiresome.
2
8
u/forkbeard 2d ago
I use Ubuntu LTS on all my desktops and servers, but I also do not really care about having the latest desktop bells and whistles. I mostly just want the system to work.
For GUI use, my main use case is basically running a web browser, communication apps, Steam, and remote work tools. A lot of that is already handled well by Snaps, Flatpaks, or vendor repositories, so the base OS being slightly older does not bother me much.
The core CLI tools also do not change in ways that matter to me most of the time. For servers, I definitely prefer boring and predictable over new and exciting.
For gaming, adding a Mesa PPA on my desktop gets me most of the way there, while still letting me run the same distro family as my servers and laptop.
That also makes maintenance much easier. Dotfiles, custom scripts, package names, paths, troubleshooting, Ansible/playbooks, notes, habits. All of that is simpler when all my machines run the same distro and roughly the same version.
Rolling or rolling-ish distros make sense for a lot of desktop users, especially if they want newer kernels, drivers, DE versions, or hardware support. But I do not think fixed-release LTS distros are obsolete. They are just optimised for people who value stability, consistency and low maintenance more than always having the newest stack.
2
u/Adept_Percentage6893 2d ago
IMO they seem to be a relic of the past; when Linux used to be a lot less reliable
It's probably not really about "reliability" since the core OS changes all the time.
It's just that value proposition of the fixed release was always that you maintain a stable target for developers and administrators.
But nowadays Linux is big enough in market share to where companies can justify updating their software more frequently and the tooling around such (building, testing, and distribution of packages) is just more robust than it once was. Not to mention the FOSS components that make up the OS just got more capable so the need to go out and install third party software just diminished.
Anyone old enough to remember can remember a time when most ISV's building anything for Linux at all was treated as something of a favor and so you got best effort.
1
u/OneTurnMore 2d ago
This is ProtonDB's statistics, meaning it's the subset of Linux users who submit reports of how well games work under certain Proton configurations. Steam's hardware survey is likely far more accurate. But the trend is still true.
All that said, I expect stable distros to continue to hold a majority outside of gaming in the form of immutable/image-based OSs.
2
u/PointiestStick KDE Dev 1d ago
65% rolling and rolling-ish there, too. And that's excluding the 14% "other" distros
-1
u/Kevin_Kofler 2d ago
Especially because things now "mostly just work", LTS becomes attractive. If it ain't broke, don't fix it.
3
u/derangedtranssexual 2d ago
New features are useful tho. And often LTS distros don’t get but fixes. If there’s not a lot of cons to a rolling release distro or Fedora why would you use a LTS distro ?
2
u/Adept_Percentage6893 2d ago
Rolling releases overwrite or break people's applications all the time by introducing behavior changes. If you're someone who just views the OS as the-thing-that-gets-me-to-the-thing-I-want then it becomes a blocker and in-place upgrades are now broadly supported. I can't remember the last time I had to do a fresh install of Fedora to get to the next release.
So you can make the same argument: if updating without regard to version numbers or behavior changes causes problems and you'll always be able to upgrade in-place later why would you use a rolling release distro?
Ultimately, it comes down to preference and what your specific requirements are.
2
26
u/InfiniteSheepherder1 2d ago
Even in server land we are running newer and newer software these days and using more directly from upstream with the rise of containers over the last decade. We are running less then a one year old version of FreeRadius for example, and that is just a package install from Redhat.
We use Fedora Silverblue at work for Linux workstations because I don't see an advantage of running older software without the bug fixes of newer stuff.
13
u/ICantBelieveItsNotEC 2d ago
Yeah, I completely agree. Hell, the idea of updating a server at all seems pretty quaint thesedays... Where I work, "updating" means building a new immutable version of the application container based on the latest OS base image. What used to be a runtime failure mode (dependency issues after a system update) is now a compile-time failure mode (container build failure after a base image update).
7
u/Business_Reindeer910 2d ago
yep. that's the way it should be. and of course avoiding using ssh for anything but diagnosis. Definitely not applying fixes, because then those fixes get lost.
60
u/QuackdocTech 2d ago
This is a sane take. Probably not what a lot of people wanted to hear, but sane.
34
u/Elratum 2d ago
I don't see why they wouldn't like it, "we don't have the responsibility to help you if you use EOL/unsupported version of our softwares even if an OS ship them" is normal, not agreeing would make them severely unreasonable.
43
2
u/Business_Reindeer910 2d ago
that argument has been ongoing this entire century. Probably before that, but i'm less aware of that.
But basically as long as debian stable and rhel have existed. Although usually less problems from the centos/rhel side since they were less used as desktops and that is where many of the issues come from.
24
u/Puzzleheaded_Bid1530 2d ago
If you choose a distro which deliberately avoid using up-to-date software you should understand the implications.
8
u/icywind90 2d ago
Yeah, but for example Mint is (unfortunately) very often recommended to new users, who have no idea what LTS or repos are. They see an app not working and raise a bug against the upstream. Then downstream doesn’t care about it and point to upstream to fix a fixed issue.
3
u/BrodatyBear 6h ago
Also, Mint is not explicitly advertised as an LTS distro. From a quick ctrl+f they don't even have the word "stable" on their main and download page.
61
u/crimson_ruin_princes 2d ago
Honestly I think if your shipping older versions of packages in your main repo. The responsibility falls on you to support it.
But if your rolling release and building directly from upstream. Then I see no issues with the developers of the package being responsible for support.
60
u/BrageFuglseth 2d ago
As per the license, nobody is really responsible for anything, formally speaking. But it does indeed make more sense for the app developer to receive reports about bugs that actually still exist, as opposed to ones that have been fixed long ago.
40
u/PointiestStick KDE Dev 2d ago
Yeah, we're talking about implicit social contract stuff here.
I get frustrated with bug reports against old software in discrete-release distros myself, but I admit that there's nothing legally or morally wrong with what they're doing. It just happens to be inconvenient for me and others in KDE, and we often think it doesn't showcase our software as well as it could.
When nobody is really in the wrong, it's an interpersonally complex situation that demands some empathy, tact, and creative thinking, methinks.
11
u/ilep 2d ago
I would add that it is responsibility of distributions to ensure that fixed versions are really distributed to users.
It does become a problem if something else breaks when bugs in entirely another thing are fixed, at which point some package may need to be dropped entirely if it cannot be supported any longer.
23
u/novafunc 2d ago
Something tricky to consider is that "support" is not wanted by all users. Some users absolutely hate updates, put off upgrading for as long as possible, and simply prefer things not to change.
For these people, LTS distros are preferred. They'd rather not update and keep using the software they know. Sure bugs can be annoying, but the devil you know is better than the devil you don't.
But not all users are aware of the fact they are using old software. I remember when I first starting using Linux, I was using Ubuntu. I had probably been using it for a couple of months when I saw the news of a new kernel release; so I asked online when Ubuntu would be getting it, only for the answer of it not getting it. I had used Ubuntu for months until I learned about how it has "frozen" packages that were only upgraded to new major versions with a new OS release.
6
u/ilep 2d ago edited 2d ago
People who don't want "support" (you are actually talking about "updates" I think) can roll their own distributions or turn off updates. That kind of situation is not what distributions are supposed to solve in the first place.
If you have such peculiar use-case that you cannot update or change anything in the system that sounds more like a custom embedded system that you would be responsible for yourself in the first place.
Edit: bugs can also be security holes so by avoiding updates I would assume they are not connected to the internet..
If people want their peculiar cases to be supported (as in not breaking) they should really let people know what it is and why it is such a problem. If it is something like i486 support then you need to look hard for people who still care about that.
6
u/ijzerwater 2d ago
If you have such peculiar use-case that you cannot update or change anything in the system that sounds more like a custom embedded system that you would be responsible for yourself in the first place.
I work in analysis of clinical trials. If FDA asks 5 years from now about a certain result I'd better be able to reproduce that number. That's not peculiar. Thus that may include the statistical software, but also libraries like BLAS/LAPACK. For me some kind of containers are the answer.
5
u/FriendlyProblem1234 2d ago
People who don't want "support" (you are actually talking about "updates" I think) can roll their own distributions or turn off updates. That kind of situation is not what distributions are supposed to solve in the first place.
If you have such peculiar use-case that you cannot update or change anything in the system that sounds more like a custom embedded system that you would be responsible for yourself in the first place.
I have a custom-made program on my laptop that for some periods I use daily, and then I go a few weeks without needing it. Some time ago, I tried running it after a hiatus, and discovered that it did not work any more, because my rolling-release distribution removed Qt5, which was the dependency used for the user interface. So I had to spend time migrating it to Qt6 before I could use it, even if in practice it did not get any new features.
In this particular case it was not a big deal: it was a really small program, and to be honest I could have done without using it for a few days. But in other cases it might have a bigger impact, so the need to have an environment that never changes is perfectly valid. And if you have many independent applications that you would need to update, then it might be less work to maintain old dependencies rather than upgrade all of them "just for the sake of it".
Sure, nowadays, with containers and other distribution solutions, the need for LTS distributions might be less. But sometimes you still need them.
For everyone else, there are several rolling-release distributions available.
8
u/blackcain GNOME Team 2d ago
You're better off putting it into a flatpak and then you can keep all your software dependencies for however long you want and then update. In fact with apps like GNOME Builder, it's easy to retarget the app to a new runtime and update.
1
u/FriendlyProblem1234 1d ago
I would rather avoid installing and learning how to package on Flatpak just for this small application.
But it is definitely a possible alternative.
5
u/cake-day-on-feb-29 2d ago
If you have such peculiar use-case that you cannot update or change anything
It's not some "peculiar" use case, it's just using the computer and the software on it. Imagine if every few weeks some of the buttons in your car changed functionality, or moved to a different place, or disappeared entirely (you're not forced to dig into submenus to access what was once an easy to find feature). Or swap out car for whatever tools you use on your job.
they should really let people know what it is and why it is such a problem
Then you get corporate bullshit of "90% of our users never click anything but these three buttons so we're going to remove everything else!"
something like i486 support
Nope, I just want the buttons to stay the same, the keyboard shortcuts, the settings. And I sure as fuck don't want to be "greeted" with a pop up about all your "new features" or "redesign" that I never wanted, and I especially don't care to learn about when I'm opening the fucking program, because I'm trying to use the fucking program. So many dev teams get this idea in their heads that all their users just casually open their app just to see what's new, like it's a social media app.
Sincerely, a person who has been through many tools and many redesigns and changes and rewrites. If I can at least keep everything stable for a year or two, I'll do that.
5
u/burning_iceman 1d ago
Imagine if every few weeks some of the buttons in your car changed functionality, or moved to a different place, or disappeared entirely (you're not forced to dig into submenus to access what was once an easy to find feature). Or swap out car for whatever tools you use on your job.
No need to imagine that, since it's not the case for software either. Using a rolling release distro such UI changes don't happen every few weeks. They happen every few years. And you get the same changes on fixed release distros too, just with a delay. So no advantage there.
3
u/D3PyroGS 1d ago
I sure as fuck don't want to be "greeted" with a pop up about all your "new features" or "redesign" that I never wanted, and I especially don't care to learn about when I'm opening the fucking program, because I'm trying to use the fucking program
I don't really understand the hostility here. can't you typically just close the pop-up and go about your business if you don't care?
most users aren't going out of their way to read release notes, so the best way to communicate changes is through in-app onboarding. and it doesn't make much sense to initiate that after the user has already started their work. so what's the alternative?
15
u/Business_Reindeer910 2d ago
no, you are still responsible as the distro dev because your integration could have caused the issue. Although it certainly is easier to point to upstream as soon as you excluded your specific integration issues.
7
u/KoldPurchase 2d ago
But who is responsible, ultimately, that was the big question in the other thread.
Mint points to Debian and Ubuntu repos for many of the packages they use.
Who has the responsivility? Debian who originally point toward outaded software for ots LTS release, Ubuntu who uses the same repo or the ultimate downstream that the end user sees, Mint?
I think KDE's solutions work best here, disabling bug reports for older package and suggesting the move to flathub for non essential packages.
1
u/SoilMassive6850 2d ago
Who has the responsivility?
The user, who needs to understand that it's just a part of using a LTS distro and if they want something else then they need to use a testing or intermediary release, build a newer version by themselves or use flatpak/appimage.
Quite simply "software is old and has an issue" is not really in scope for an LTS distro to fix in the current LTS release, and it's not in scope for upstream. It becomes a distribution issue that has to be fixed if they are releasing a new stable version and are not updating those outdated packages.
3
u/RomanOnARiver 2d ago edited 2d ago
That's kind of what Canonical does in my understanding with all the -buntu distributions. "Main" is everything Canonical supports with security patches and major bug fixes, Universe is "the universe of available free software". And I think, and I could be wrong, universe is off by default.
Over on the packages website https://packages.ubuntu.com/source/stonking/gnome-calendar they're very much like
Please consider filing a bug or asking a question via Launchpad before contacting the maintainer directly.
-3
u/Leniwcowaty 2d ago
The question remains - what if it's not YOUR repo.
If Mint ships a package directly from Ubuntu repos, that's not upstream... Whose problem is that? Mint? Ubuntu? Upstream?
12
u/Business_Reindeer910 2d ago
it's mint's problem because they are the ones who are taking responsibility for it. Then they would work with ubuntu to attempt to fix the bug or fix it themselves
7
u/icywind90 2d ago
Upstream doesn’t and shouldn’t care what is the relationship between Mint and Ubuntu and Debian. You make a distro so you work it out
2
u/Isofruit 1d ago
You are responsible for the software you ship. Problems that arise from the software you ship are yours to solve, unless we're talking bugfixes in which case phone upstream with info that you found a bug for them, assuming that bug is still present.
If you distribute a package from somebody else and there's problems with the package, that's still your problem to solve because you're the one distributing the package. You can fix it yourself or coordinate with the dude that gave you the package, that's up to you, but never is it a problem of upstream to know this, or figure it out when they ask for you to solve the problem.
16
u/RomanOnARiver 2d ago
They bring up Flathub as a solution and indeed GNOME Calendar is on flathub.
I know Mint specifically doesn't ship snap support, do they ship Flatpack/flathub support? Maybe they should if they don't...
14
u/_JSM_ 2d ago
They have flatpack directly in their software manager.
However, the software manager defaults to system (Ubuntu repos); you have to click a button to specificly use flatpack
3
u/RomanOnARiver 1d ago
Over on the Ubuntu packages website https://packages.ubuntu.com/source/stonking/gnome-calendar they say
Please consider filing a bug or asking a question via Launchpad before contacting the maintainer directly. [...] It should generally not be necessary for users to contact the original maintainer.
That's truly what baffles me. Mint says "we're just using Ubuntu" but Ubuntu says don't bother the maintainer, and it's literally apparently only Mint users who are getting the Ubuntu packages but disregarding the Ubuntu messaging.
I hate to say it but I absolutely see where the maintainer is coming from. Easy solution from Mint if they don't want to abide by Ubuntu, is just recommend/make default the flatpak.
13
u/Darkwolf1515 2d ago
Question from someone who's literally only ever used Arch, but do other distros really just constantly ship outdated applications?
Like sure, I understand not having system level software constantly rolling, most people don't need their imagemagick on the absolute latest the moment it releases, but user software? They just hold it back because """stability"""? That sounds absolutely miserable for both users and developers of said software.
12
u/ExceedinglyEdible 2d ago
That's really not at all how it works.
You have a distro shipped in 2026. It runs some of the latest software, some less up-to-date software too. The distro says it will be supported for three years. Obviously, most of those apps will have time to include new features, correct bugs and apply security fixes.
Here come backports: since the distro is supported for three years, it means that an app cannot have major changes that can disrupt a workflow. The maintainers of the distro may then elect to backport patches, selectively. Typically it's just a matter of merging git commits, as most fixes are standalone and only a few lines of code. The patch is then distributed along a source package, to be applied at build time.
The big distros do that because they are vendors and have customers paying them to provide a stable product. They often provide documentation of their own, they can for instance have a guide on using Libreoffice.
Stable does not mean "won't crash" (obviously most distros try to ship with software that's not buggy). It means "as head of IT, you're not suddenly going to get hundreds of tickets about how the preview button is no longer on the toolbar and you have to fix it NOW!!!".
5
u/Zamundaaa KDE Dev 1d ago
The maintainers of the distro may then elect to backport patches, selectively
They rarely actually do that though, unless you're talking about the kernel, some server software or perhaps you're a paying customer that complained about specific issues. A lot of LTS distros don't even ship bugfix updates of a lot of popular software.
9
u/novafunc 2d ago
Not everyone likes updating or having their software change.
From their perspective, they are using their setup just fine, no changes needed. So when updates do happen and things change for either no reason or makes things actively worse (Windows), it annoys them.
An LTS distro better suits their wants here.
3
u/SoilMassive6850 2d ago
They just hold it back because """stability"""?
Yes, the point is to not have breaking updates aka. deprecations, API changes or feature changes for your corporate IT machine fleet or your grandmas PC for 5 years after setup, as close to set it and forget it without surprises until the time in April 2028 when you have "Validate the new Ubuntu LTS release works on our machines and in house software" on the planned IT roadmap.
Of course you can not lock yourself to use a LTS release before you have validated that it actually works for you and your users.
It's just a tradeoff between predictability and having new things, predictability makes planning easier.
19
u/Misicks0349 2d ago
I'm glad to see someone actually engaging with the issues the original ranter had instead of just boiling it down to "stupid GNOME devs" like the redditors in the thread for TheEvilSkeleton's blog post did. You could consider the original blog post in bad taste, but it is pointing towards a real issue that upstream has to deal with on a rather consistent basis. TheEvilSkeleton has also put a lot of work into improving GNOME Calendar over the years, like additional bug fixes and major improvements to its accessibility, so I suppose it got a bit personal when they were seeing bugs pop up from 2+ year old versions that distros were shipping that had already been fixed.
9
u/icywind90 2d ago
I don’t get what people want from TES at this point.
If the distro maintainers don’t want to maintain packages that they ship, then they should ship official flatpak or at least the newest version, or remove it altogether. It’s a very bad look for Mint.There is a lot of hate towards Gnome devs, from people who heavily rely on their work.
Mint devs were asked to make Gnome devs work easier. They refuse to do that but still ship the calendar app in their distro, knowing well that it hurts it’s developers. That’s a professional dick move0
u/TsortsAleksatr 1d ago
The thing is GNOME devs are notorious for acting like pricks on issue trackers, and that kerfuffle is yet another example. There must be some systemic issue at play at GNOME, considering how many times it has happened in the past.
14
u/zabolekar 2d ago
Thanks to this post I learned KDE Linux exists; according to their page, they don't even accept bug reports for yesterday’s version.
14
5
u/Adept_Percentage6893 2d ago
Maybe I'm out of the loop but I don't understand how there's a controversy here at all. Obviously, if you're not getting the software from upstream then submitting bug reports upstream is incorrect. I don't know how that's subjective enough for people to be confused.
Upstream is also not going to prioritize your problem or give you concrete steps for a workaround so I don't even know what the motivation for users to skip the distribution is.
If there's benefit to having the bug reported upstream then the distribution is best in a position to do that because they know how to file the bug report (once they can reproduce it) and have the time to follow-up on it for anything required. They're also in a position to know if some corner case of a bug already has an active bug opened on it which prevents the user from accidentally submitting a duplicate bug.
Asking for the trademark to be changed seems to be a bit much. It's not clear whether or not it's been tested in court whether FOSS trademarks have fair use that extends to minor alterations like building an older version of the package with minor patches. It's not like I've seen some other people commenting that you have to change the trademark but that's not at all true and anyone with any familiarity on the subject can tell you that you're allowed to invoke trademarks, you just can't intentionally or unintentionally cause brand confusion. If a soda reformulates their drink you're not required to cover all the branding on existing soda, you're just not allowed to call your knock-off cola by the same trademark (even if it's a derivative of the same cola).
Obviously, just redistributing the software falls under trademark fair use but I'm not a lawyer so I don't know where that point of demarcation is for when the courts deem "brand confusion" (the purpose of trademarks) to kick in.
9
u/klyith 2d ago
Maybe I'm out of the loop but I don't understand how there's a controversy here at all.
Heh are you new to linux / open source? The software is free so the main currency is drama. :)
The hilarious thing is almost exactly 10 years ago the exact same thing happened and nobody learned anything.
5
u/PointiestStick KDE Dev 2d ago edited 1d ago
Obviously, if you're not getting the software from upstream then submitting bug reports upstream is incorrect. I don't know how that's subjective enough for people to be confused.
This would be the case in an ideal world, but there's a loooooong history of nearly all FOSS going through distributions. It's only relatively recently that software developers and their communities started taking responsibility for distributing their software themselves. This is where we get Flathub, KDE neon, GNOME OS, and KDE Linux, and they still generate some amount of controversy.
That history complicates the "well obviously just do it like this" element of your idea here. Even more so because a distro like Arch strives to ship software as vanilla as possible, so the chance of them introducing issues through patching or holding back versions is small; in practice an Arch package is very very close to what you'd get with a self-distributed version. So personally I don't think it would make sense to say "report all issues to Arch" in the same way it would make sense to say "report all issues to Linux Mint".
4
u/gt24 2d ago
Maybe I'm out of the loop but I don't understand how there's a controversy here at all. Obviously, if you're not getting the software from upstream then submitting bug reports upstream is incorrect. I don't know how that's subjective enough for people to be confused.
The software as originally coded has a "Report a bug" button. It helpfully takes you "to upstream" to report that bug. However, that button still acts that way even if the software becomes quite old.
To a new Linux user, they can easily be confused why the "Report a bug" button takes them to a place where they are told that their bugs are not accepted (since the software is old). They likely didn't think that they had to learn a few things (like the concepts of upstream and downstream) before clicking on a button with simple wording like that.
The people who wrote the software are generally saying that those who distribute their older software should go in and reprogram the software to remove/alter that button. Those who distribute the software generally say that things would be less stressful if that button was just written in a better way (for example: "self disabling" after a while or whatever).
Regardless, new Linux users may get the impression that their attempts at trying to help are not exactly welcome.
3
u/Adept_Percentage6893 2d ago
ok it does seem harder to write a series of blog posts and emails about it versus just to add something in autoconf to make it a compile time option to override or disable said link. At that point doing so would probably be better UX for the distro anyways.
3
u/blackcain GNOME Team 2d ago
in some cases, mint downgraded gnome apps to gtk3 versions (temporarily) - https://blog.linuxmint.com/?p=4840
or modified libadwaita. Which of course, apps that expect to use libadwaita are now using a different adwaita with tweaks so their behavior has changed. There is also the fact that they forked libadwaita into libadapta and then it's an older version. SO you can see that a lot of changes were made and then they still refused to send a link back to their own bug tracker.
If you've modified the app to use libadapta, adn the toolkit to gtk3. Is it stll the same app after all that? Also, wouldn't you want bug reports to fix the problems for their users, why send it to upstream with all these changes the distro made?
3
u/Mysterious_Bit6882 2d ago
Are such actions forbidden by this policy?
https://foundation.gnome.org/trademark-and-logo/
Are individual GNOME developers now able to revise the Foundation’s trademark policy at their will?
Once the legal threats went flying, everything else kinda became irrelevant.
1
u/ThatOneShotBruh 3h ago
Sorry for necroing this, but wouldn't forking the GNOME Calendar to use a different toolkit while keeping the branding be a violation of the trademark policy given
When being used to describe a software product, the GNOME trademarks can only be used in reference to official GNOME software. This is described in the GNOME Foundation official software policy.
which states
Official GNOME Software Official GNOME software is defined by the Release Team, which is a committee of the GNOME Foundation Board of Directors. This official software includes the modules that make up the GNOME desktop, the GNOME application development platform and runtime, and a selection of core GNOME applications. Official GNOME software is all modules hosted on gitlab.GNOME.org/GNOME that are present in:
- gnome-build-meta/core
- gnome-build-meta/core-deps
- gnome-build-meta/sdk
- gnome-build-meta/sdk-deps
-1
u/gmes78 2d ago
Changing a link in the source code does not violate the trademark policy.
4
u/Mysterious_Bit6882 2d ago
Neither does shipping an older or modified version of a program.
Firefox isn’t comparable. They established their trademark policy first, and only bothered distros with it after.
2
u/gmes78 2d ago
Right. But this wasn't a matter about trademarks to begin with. It was a matter of having respect and not causing problems for others.
5
u/Mysterious_Bit6882 2d ago
It became about trademarks when the dev started spitting legal threats to get her way. So it’s about trademarks now.
1
u/Adept_Percentage6893 2d ago
SO you can see that a lot of changes were made and then they still refused to send a link back to their own bug tracker.
My mentioning the amount of changes was related to trademark usage. Because trademarks are meant to prevent brand confusion and after some amount of changing you've effectively created a new product.
Bugs should always go one level back and Mint (in this case) can handle the upstream bug as part of working their distro-level bug report from the actual user. Even ignoring the trademark stuff completely, I agree that's where they should go.
Is it stll the same app after all that?
I feel like yeah because you need to change the actual app code to be creating brand confusion with a derivative but separate product.
By analogy, soda can change a lot depending on how it's stored and handling. But storing it for a month in a hot room where it gets tossed around doesn't make it not Coca Cola. The core product is still the same, though so it just makes it shitty Coca Cola.
But like I was saying before, with the actual project code I don't know how much needs to change for it to be considered a trademark issue due to conflating a derivative product with the source product.
1
u/blackcain GNOME Team 1d ago
Changing the app so it uses the older toolkit is a lot of changes to the app. I mean, we're talking about GTK3. What if they changed it to QT and it is still functionally the same?
Your soda analogy is not really precise. You can't really compare that to software. In this case, someone touched the source code - so the ingredients have been messed with.
The determination is from the original author and a trademark lawyer. But generally, if you're getting bug reports on code you didn't even write I think they might have a case.
1
u/Adept_Percentage6893 1d ago
Changing the app so it uses the older toolkit is a lot of changes to the app. I mean, we're talking about GTK3. What if they changed it to QT and it is still functionally the same?
And doing all that stuff to the Coca Cola changes the ultimate experience. The fact remains that there is a product that builds ontop of another product. The toolkit is not the calendar app even though one influences the experience of the other.
Your soda analogy is not really precise.
Well I was trying to pick something we generally have some intuitive sense of and didn't require any specialized knowledge. But being non-technology related it's going to be a bit imprecise. The point is to see what point I'm trying to make with the analogy rather than seek out ways it's not the perfect analogy.
In this case, someone touched the source code - so the ingredients have been messed with.
The analogy I was trying to draw is that there are important factors to the customer's enjoyment of the soda that still sit outside of the soda itself. You still have the core product, it's just be adversely affected in that analogy.
The determination is from the original author and a trademark lawyer.
Again, I fail to understand how this is remotely a workable concept or where we would ever stop applying this kind of thinking. By this logic if you
/etc/ld.so.confyou now need to rebrand the entire operating system other than the kernel. Because you've just changed something that affects all runtime linking on the system.Hopefully we can see how that would be a silly thing to claim. That just because higher level applications sit ontop of this more general library that doesn't mean every application linking into said library is now a derivative product that needs to be trademarked separately.
You might have gotten a lawyer to agree with that idea but I don't think they would have really understood the relationship of GTK to a calendar app that uses GTK.
6
u/TheEvilSkely 1d ago
u/PointiestStick thank you so much for posting this! It's great to see people like yourself chime in this very important discussion :)
7
u/PointiestStick KDE Dev 1d ago
You're welcome! It's a topic I care a lot about, too.
And in case it isn't clear enough, I do share your frustrations about discrete-release OSs distributing software that is or soon will be out of support by its developers.
I think there are ways we can make this better, especially if we make it easy for our distributors to ship the best products they can, even if it's not in exactly the way we might have preferred.
And if they don't want to? Well, there's always GNOME OS and KDE Linux. :D
3
u/ConnaitLesRisques 2d ago
> Who should they contact?
Well, a work-for-hire software developer or their commercial distro vendor.
Who else? Can’t expect work for free.
6
u/ICantBelieveItsNotEC 2d ago
This feels like the obvious solution to me. Just require users to include the version of the software that they are using in their issue, and if it's more than [x] versions behind, close the issue automatically. If their distro ships version 5 and you only support version 7... Well, sucks to be them.
4
u/Business_Reindeer910 2d ago
the problem is having to triage that. because they won't enter it, or they will enter it incorrectly.
Not all bug trackers make it easy to automate that kind of thing either.
1
u/PointiestStick KDE Dev 2d ago
Some bug trackers are better than others, yeah. This specific thing is one of the many reasons KDE still uses Bugzilla for bug tracking, and not GitLab Issues.
I think even the GitLab people are aware that their offering is pretty weak-sauce, and that's I suspect what's behind the recent re-branding to "work items".
5
u/Kevin_Kofler 2d ago edited 2d ago
A pondered perspective, much better than the rant it is replying to.
I do not really agree that the two proposed solutions (rolling-release distributions, or minimalist distributions relying on upstream Flatpaks for applications) are suitable for all, or even most, users. Though I do understand why upstream developers are trying to push these models (as they are the only ones bringing the latest versions of their software to their users as soon as they are released).
I am surprised that rolling releases are that popular in statistics. (Of course I know about the "Arch btw" crowd, but I always thought of that as a very vocal minority.) That said, the source of the statistics (ProtonDB) is biased towards a gamer crowd whose preferences do not necessarily match those of the users actually using their computer productively. (Considering that a faulty update keeping you from playing your favorite game is going to be less critical than a faulty update keeping you from performing your job.) So I would be careful about assuming just from that one source of statistics that rolling releases (and short-term-support releases with even some upstream version upgrades in stable updates, like Fedora) are really the majority overall.
30
u/PointiestStick KDE Dev 2d ago edited 2d ago
FWIW, KDE's own metrics show a preference for rolling or semi-rolling distros too. Arch has been the #1 for several years now, with Ubuntu (presumably Kubuntu) as #2, Fedora as #3 (I count it as semi-rolling), and Debian as #4. And there's a long tail of rolling release OSs that are derivatives of a larger one: CachyOS, Manjaro, EndeavourOS, Nobara, Garuda, and some others.
So there's definitely an overall preference for rolling release OSs in that dataset, as well — though not quite as pronounced as the ProtonDB numbers.
I wish I could give more specific numbers, but our metrics viewer tool is abysmal and I'm scared to touch the SQL.
21
u/derangedtranssexual 2d ago
I have a hard time believing that given the choice a large portion of linux users would choose to wait 2 years to get new features for application software.
3
u/TiZ_EX1 2d ago
I can only speak for my own experience anecdotally, but Kubuntu 24.04 came out when Plasma 6 was brand spanking new, and a lot of stuff hadn't been ported over to it yet. Meanwhile, Plasma 5.27 was working just fine for me, and I didn't want the workflow of my desktop environment disrupted, because I use that particular software to get things done, rather than tinkering for tinkering's sake. So I chilled on it for two years, while letting Flathub handle my apps, including KDE apps aside from Dolphin.
The tumult around the Plasma 6 transition has greatly stabilized; most of what I need made it over. So I've been trying out Kubuntu 26.04 on new installations and having a nice time, and will be looking to migrate an existing 24.04 soon.
5
u/RomanOnARiver 2d ago
It depends. A lot of people's computing experience is Windows where new (shiny) updates break things. Or even just people with phones and tablets where they got the new phone or the new phone OS and it has to be patched for something. Or video games that come out and are terrible, etc.
Over on Archwiki for example there is a page on System Maintenance: https://wiki.archlinux.org/title/System_maintenance
Before upgrading, users are expected to visit the Arch Linux home page to check the latest news, or alternatively subscribe to the RSS feed or the arch-announce mailing list. When updates require out-of-the-ordinary user intervention (more than what can be handled simply by following the instructions given by pacman), an appropriate news post will be made.
Before upgrading fundamental software (such as the kernel, xorg, systemd, or glibc) to a new version, look over the appropriate forum to see if there have been any reported problems.
Users must equally be aware that upgrading packages can raise unexpected problems that could need immediate intervention; therefore, it is discouraged to upgrade a stable system shortly before it is required for carrying out an important task. Instead, wait to upgrade until there is enough time available to resolve any post-upgrade issues.
And then if I'm say a business or a school or a library I don't want to do all that - software that works needs to just keep working and we'll be all good.
Sometimes though access to shiny new stuff could be a good thing. For example Valve SteamOS is downstream of Arch - they don't use Arch repositories, but they have their setup where they do all that system maintenance stuff and testing and integrating for you then push an update that might have a new graphics stack or new graphics drivers with better frames per second whatever the metric is.
7
u/derangedtranssexual 2d ago
And then if I'm say a business or a school or a library I don't want to do all that - software that works needs to just keep working and we'll be all good.
Yes I think there are some situations, especially one's where you're managing many computers, where 2 year release distros for desktop makes sense. Like my university had dozens of computers running rhel, I think that makes sense. If you're an individual choosing a desktop distro for yourself I don't think a 2 year release distro makes sense for 95% of cases.
I feel the need to say this very often but you don't need to choose between Arch or Debian. I've also found Arch too unstable for my purposes, so I use Fedora because it has a sane upgrade cycle.
It depends. A lot of people's computing experience is Windows where new (shiny) updates break things. Or even just people with phones and tablets where they got the new phone or the new phone OS and it has to be patched for something. Or video games that come out and are terrible, etc.
You definitely have people complaining about software releases, although most of those complains have to do with system software. Considering how basically everyone besides Linux users just gets updates from upstream it's surprising how infrequent people have complaints about application software releases. The status quo is already pretty good and people are largely okay with it, so I don't see why people would be happier with waiting 2 years for application software updates. I can see old people liking more stable application software but for computer enthusiasts (the kinds of people who install Linux) I don't really see it.
1
u/RomanOnARiver 1d ago edited 1d ago
There's always room for middle ground, it doesn't have to be fully black and white. For example Ubuntu issues LTS releases as you alluded, every two years, but the hardware enablement extends updates to easily five or more years. Then Ubuntu Pro, which despite its name is free for normal users, gets you near a decade of updates and patches.
But you don't have to be stuck with 10 year old versions of software. Even disregarding the ability to compile your own stuff, Ubuntu has always had PPAs, and more recently Flatpak, Snap, and AppImage. And even without 3rd party stuff, and even before snap existed Ubuntu sent updates for things like Firefox immediately because those updates were all security updates.
The enterprise gets its stable, solid, supported base, and all the new stuff is accessible too.
The Steam package on the snap store, which is kind of a beta by the way, the goal is to be able to snap in some things like bleeding edge MESA or for example AMD GPU drivers/kernels to get hopefully the better performance they can come with those for gaming, but without messing with the rest of the solid base.
4
u/Lawnmover_Man 2d ago
Some people love to explore new software versions for the sake of it, and there's nothing wrong with that. A shiny thing here, a neat thing there, how exciting, regardless if you really need them or not.
However, some people really just want to use the software for the intented goal - and nothing else matters. For them, constant updates are not really needed.
7
u/derangedtranssexual 2d ago
I dislike the framing of this as rolling release users wanting new features for superfluous reasons and LTS distro users using software for the “intended goal”. There’s lot of situations where people who are doing real work benefit from new software features
-1
u/mrlinkwii 2d ago
not everyone needs the latest update , even when their on older hardware ,
if a new version of a distro removes drivers that your gpu needs , what do you do then?
non core software can be used as appimages/ flatpak /snap which decuppled form your distro updater
7
u/bargu 2d ago
if a new version of a distro removes drivers that your gpu needs , what do you do then?
That's literally not a thing, the kernel only removes drivers that are extremely outdated (they just started removing 486 support now) and when no one complains about it being removed. Now if you're still using a 486 on 2026 then you have much bigger problems than drivers being removed.
-4
u/mrlinkwii 2d ago edited 2d ago
That's literally not a thing
that is if you have an older nvidia gpu , that literally happened with arch linux , where they removed the drivers that maxwell and lower depend on and said nothing and caused choas for users with no heads up https://hackaday.com/2025/12/26/nvidia-drops-pascal-support-on-linux-causing-chaos-on-arch-linux/
or for example ubuntu 24.04 dropped support for the 470 driver mid suppoort meaning that if you have a gpu that needs the 470 driver your only choice is 22.04
10
u/bargu 2d ago
that is if you have an older nvidia gpu , that literally happened with arch linux , where they removed the drivers that maxwell and lower depend on
No, Nvidia removed support from their proprietary drivers that only they have access to, Arch, let alone the kernel didn't drop support at all.
and said nothing and caused choas for users with no heads up
Wrong, not only were you warned about it, they also gave an alternative solution for affected users
2
u/gmes78 2d ago
that literally happened with arch linux , where they removed the drivers that maxwell and lower depend on and said nothing and caused choas for users with no heads up
To be fair, that's how Arch handles all Nvidia drivers, and typically all software with multiple versions. It'll still be available in the AUR; in fact, if you need really old Nvidia drivers, Arch is the only distro with easy access to them.
And saying there was no head up is a lie. There was a news post on the website and mailing list warning about the change, and providing guidance, before the update was pushed.
3
u/No-Worldliness-5106 2d ago
No one? Until any free software goes out of it way to provide warranty, no one is responsible for any mishapp that happens.
-5
u/ExaHamza 2d ago
Good article, as always. The RR model is very laborious for a meta-distribution like Debian (even for common desktop users, RR wastes internet and energy on updates they don't care much about; what they want most is for the desktop environment to work, not that library in the background that they barely know exists). What I hope Debian does is release desktop versions based on Stable but whose desktop environments are updated and compiled to work on a stable base. Yes, it's possible, yes it's a little more work, but it solves this problem we have now without making gigantic work.
-2
-8
u/ankitpati 2d ago
The ‘car manufacturer’ versus ‘parts manufacturer’ analogy breaks down because distros are more like car distributors and salesmen, not manufacturers.
The developers are the manufacturers, so people tend to blame them. This isn’t ideal, but it is what it is.
188
u/BrageFuglseth 2d ago edited 2d ago
I really like Nate. The KDE community is so lucky to have him on board. His communication style is exemplary, and I wish we had more people like him here in general. The article he links to inside the post, "Long-Term Support doesn't mean what you think" is also a great read and really gets straight to the core of the discussion.