Of course many distros will just tell the upstream to pound sand, and more power to them. When I'm perfectly happy running the version that shipped with my OS, I DON'T want your updates. Just leave me alone.
He wanted to be left alone by the army-of-people-who-are-not-you that kept reporting long-fixed bugs because they didn't know they were living in an ancient version of Debian.
For a distro that blithely patched the entropy out of OpenSSL (in order to quiet a valgrind warning), you'd think they could figure out how to write a script that substitutes an Debian maintainer's email addy for the author's.
It is the same old problem and what's interesting to me is that I never see it articulated very well. I suppose it's because people disagree about what the problem is.
To me it's this, Linux and it's distribution mechanism is skewed towards servers, and IT since that's where most of it's installed base is.
That's great. The distro/repo system is great, and works well. In addition to it, we need another system that serves workstations better. They don't have the same requirements in general. In particular there's a big divergence in availability, and security requirements. I really doubt there's enough economic inventive to serve this second use-case, but it's too bad, because I think we could have the best of both worlds.
> To me it's this, Linux and it's distribution mechanism is skewed towards servers, and IT since that's where most of it's installed base is.
It's not just servers—not having a very capable, standard, base set of packages to rely on for a workstation-targeting release (say, of GUI programs) is a huge problem. Instead, distros differ wildly on what they provide, users may have different versions of packages or even entirely different programs or libraries (the entire window server may differ!) serving similar purposes, some libs may simply be absent, et c. This is kinda OK if you stick to running software your distro bundles and only at the official version for your release of the distro, but quickly becomes hell (for the people packaging your programs, if not for you) as soon as you step outside that.
This is why you see a lot of companies that support Linux for their commercial software being very specific about supporting e.g. only one or two distros, at some very limited set of versions. It's very hard to support "Linux" in general, especially for desktop-targeting software, because the Linux GUI and multimedia stacks are... well, they're a shitshow, frankly.
There are a ton more ways that very basic APIs and services can present to the user and to their programs, meaning far more ways for things to break. Way more possible combinations of not just version, but even which library or program is providing some capability.
The closest thing to a solution is picking one of the two big desktop environments and targeting that to give you some amount of consistency and stability, but it's not like people will only run your program in that DE (again, possibly not even in the same window server you developed on) so you may end up with bugs when e.g. your QT/KDE program runs under Enlightenment, plus a ton of basic stuff can still vary a lot even if you restrict support to one DE (think: audio daemon) which may affect all kinds of things in unexpected ways.
> GUI heavy application like chrome, firefox or openoffice run on all districts without any hiccup!
Ever seen a thread full of people exchanging advice on how to get these programs not to exhibit certain widespread glitches on Linux, many of which have been a problem for years? Thinking especially of things like tearing, or multimedia playback problems. They even crop up here on HN from time to time.
Even for servers, debian-style package management is increasingly inadequate. Linux package management was designed for the C era of a small number of large libraries with infrequent releases. Distribution maintainers are unable or unwilling to adapt their processes to support the model that most modern software ecosystems are converging on: large numbers of small libraries with frequent releases. (Frankly, they're often hostile to the idea that they should support it, despite this model being preferred by both developers and users). Yet they're also hostile to the idea of getting out of the way and letting ecosystem-specific package managers handle ecosystems that need more frequent releases.
In the era of servers that were hand-tended by a BOFH who upgraded only rarely (and screw the users who want to use something newer), the distro/repo system worked. But even servers are not generally maintained that way anymore. I honestly think we're going to see that model fade away in the next decade or so.
Just because parts of the ecosystem are constantly cranking out small changes doesn’t mean my employer wants my team to spend time alpha testing all of them at the risk of downtime.
I’m fine with an author saying “I no longer want bug reports from that version,” and I’d like someone with the distro to act on those instead.
Most effective employers I've worked for have found that staying close to upstream's rolling releases saved more time and effort in the long run compared to leaving a bigger gap between upgrades (which, sure, saves time if nothing breaks, but the worst case becomes a lot worse).
Well, run something rolling such as Arch Linux or Debian Unstable on desktop, and an LTS distribution such as Ubuntu LTS or Debian Stable on servers. If you're not a complete beginner, there are many benefits to run a distribution that tracks upstream closely so you can contribute and get fixes almost immediately.
If you need local development/production environment version parity, use container images or package locking files available in most programming language ecosystems.
Indeed, agree. I'm on a rolling distro (Manjaro) and I'm pretty happy. I see a lot of discontent in Linux land around this conflict though, so I though I would try to lay it out. Example a lot of people don't like the practice of curl'ing shell scripts on to their boxes, that many developer tools like Rust and Deno use for installing their tooling. The more server oriented folks see it as border-line crazy, while many developers are totally fine with it. Clearly to me they're coming at the issue from different points of view and it would be nice to fully support both communities.
> In particular there's a big divergence in availability, and security requirements.
I strongly disagree about the difference in security requirements. I don't want anybody to pwn my banks servers, not less or more than pwning my home desktop or mobile phone.
That's totally understandable. I did not mean to imply that workstations have no security requirements, just different. I feel pretty much the same about the host OS on my workstation, but I also spin up lots of temporary environments that I need to abuse badly. They are thrown away again, usually within hours or days.
I guess it's a reminder that most distros still don't have some way to report a bug for their package maintainers that is easier than reporting it upstream.
Debian is almost there, but it's stopped almost there for a long time already.
I have reported maybe 20 bugs to distros, I don’t remember a single one receiving any attention before they auto close for being old. Reporting to upstream almost always gets some kind of response and usually a resolution. Fedora was packaging a 5 year old version of LMMS because for some reason upstream decided to label the last 5 years of updates as RC versions despite them being vastly more stable and feature filled than the last "stable". I reported a few of the bugs found in this old LMMS on the redhat bug tracker and no one responded. Upstream had fixed these long ago.
These days I think distros should ship only the core OS components and let tools like flatpak give you user level apps direct from the source. I largely don't care about having the absolute latest version of Gnome or systemd. But I very much do care that all of my applications, especially internet connected ones are. I stopped using distro packaged telegram binaries because it would take a month before they got updated and in that time I'd have to use my phone to view all the unsupported messages sent.
I had used Silverblue for a little over a year and I think it’s certainly the future of Linux distros. I had a fair bit of difficulty but none of it was intrinsic to the tech and more just 3rd party packages that didn’t quite work properly. I really loved “toolbox” though.
I wonder if the issue could be solved by upstream. Spin up a new email address for each release -- xscreensaver-1.0@some_domain.org, then once they've moved on to version 1.1, set up an auto response and stop checking the email address.
I mean... for the most part, these are issues that the upstream maintainers should be fixing. For example, the font rendering in Bottles broke when they updated to GTK4. Instead of fixing this in the actual GTK4 codebase, the GNOME foundation recommended that everyone start using Flatpak, where they could apply a very specific system patch that works around this issue.
This is the problem with encouraging this "use our kitchen sink" behavior. It encourages poor development practices, and it ends with developers grovelling and asking users to switch their packaging systems. Imagine if you tried installing an app on Windows or MacOS, and they demanded that you install a separate package manager along with it. It's an unacceptable demand to make of anyone, and certainly shouldn't be the behavior we encourage if we want to live in a world of high-quality Free Software.
> Imagine if you tried installing an app on Windows or MacOS, and they demanded that you install a separate package manager along with it
This is basically how Windows works. There's no package manager, so effectively anyone shipping larger software ships their own auto updater, their own dependencies and either embeds or downloads extra installers for the MS redistributables at install time. They don't ask you, just effectively do it anyway.
Windows did get a package manager with dependency support, it’s just that many developers are still shipping custom installer programs that ignore it and almost all the users are still willing to run those installers.
Winget? That only started existing recently. Systems that are still supported don't include it. I'd wait a couple years before devs even start seriously considering it.
I'm thinking of Windows Installer (the MSI engine and database). I haven’t been in that world for a while, but it looks like winget is a frontend to a repo of MSIs or custom installers or whatever the store uses.
MSI doesn't do dependencies though, does it? You can launch one installer from another, for example if you want to install a .net framework with the app, but they're completely unrelated afterwards. There's no built in mechanism for updating them either.
If the upstream maintainers should fix, the distro maintainer is quite capable of forwarding the bug there.
The upstream developers here are complaining because they get the bug reports, but can't fix the issue (at least the way they want to).
That's independent on those few large groups that poped-up on the FOSS community that push a lot of badly maintained software. Yes, those are a problem too, just a different one.
Yes. In the past users did start by reporting bugs to their distro, and the distro package maintainer then forwarded it to upstream if necessary. But lately users have become more savvy about talking to upstream directly. Probably because upstream source control has become more standardized and well-known (GitHub, etc) and easier to work with (don't have to futz with mailing lists and etiquette, just click the "New Issue" button).
It's not even specific to Bottles or Flatpaks or whatever; it happens with regular Linux software too. In the systemd tracker you'll find people complaining about issues that have been fixed in systemd's git repo, but because the people are running distros with older versions they think the issue hasn't been fixed yet.
It's no wonder people have started to report problems upstreams because downstream bug reports rarely ever get picked up on. If they do, it's with 10 comments of "okay, try it with this" which don't work and then nothing until a bot closes the bug because a new major version came out and therefore all bugs are now no longer relevant.
Most error messages I've googled have led me to unresolved Linux bugs in various distros. Fedora users seem especially good at reporting bugs to their distro maintainers, though this does not always result in any kind of solution.
In my opinion, every distro should be allowed to ship their version of a package, but the moment packages get frozen (i.e. for LTS distros) or custom patches get added (i.e. Debian) all contact links to upstream developers should be removed immediately and replaced with the email address of the maintainer of the package. This should hopefully prevent the jwz problem while at the same time bringing the users of these distros the stable release cycle they want.
That's also fine if you specify your distro name and use your distro specific bug tracker to report your issues, unless you're pulling in the official distribution of upstream software through something like Flatpak that bypasses your system.
Even then I've found that many Flatpaks are broken on Ubuntu that work fine on Manjaro. Weird distro configurations really are a terrible burden on developers, this stuff makes me never want to publish software that gets absorbed into distros.
Mozilla was right to force Debian to rename their modified version of their browser. More packages should use such policies in my opinion, especially if they're complex to set up right like this piece of software.
Uh, wouldn't you, as the user, rather have the power to determine for yourself which version you'd like to stop upgrading at? That certainly sounds a lot better than letting a bunch of unpaid third party volunteers determine that for you, which is how the distro/repo model works.
> Uh, wouldn't you, as the user, rather have the power to determine for yourself which version you'd like to stop upgrading at?
Given that I'm not using Linux From Scratch, I'd say no: part of the reason I'm choosing a distribution is because I want to make somebody else deal with tracking updates (including security). I recognize that this comes with downsides (e.g. sometimes new versions have new bugs).
I kind of miss the pre-internet times when shipped software is, well, shipped and static, and typically bundled all of its dependencies outside the OS (which was just listed on the box). On the other hand, I'm typing this on a smartphone that couldn't exist in that model…
You do have the power. You can compile from source to any version you want. The caveat is that it breaks the primary reason most people use distributions—to get a set of packages that are consistent with each other.
Consistency is a non-issue for me. Reason I don't do it is because neither the update nor the uninstall experience are standardized and good.
I guess what I would really want is a) manually built packages install into opt and use a mechanism like update-alternatives to get things into PATH or wherever they need to be. b) Possibility to track an https endpoint for information about new releases. Could be something as simple as a text file of all versions with url of tarball and a flag for whether the version has known security issues.
No, that is not a relevant reason. There are people who have pinned their Windows versions, there are people who bypass Steam's autoupdates to run old versions of games, this is a general computing problem not a Linux problem. If you want to be particular about the version of something you're running you're not going to be able to rely on systems which were designed to remove that consideration from you, period. Nobody has ever promised that Linux or any other OS would just make all versions of everything work together all the time and you have the total freedom to pick anything with no consequences.
This is the opposite of a YotLD problem, it's because Linux users do not usually participate in automatic updates that they consider this a problem. Windows and macOS and Android and iOS are all automatically updated and nudge users into updating more frequently than automatically.
No, the point is that distro/repo model has a terrible user experience for installing applications. Sure, it works fine for the very narrow case of only wanting to install exactly what is in the repo, but the second you step outside of that everything gets needlessly complicated.
I, for one, am grateful that things like FlatPak and AppImage are finally gaining traction and I hope the trend continues.
I struggle with this question as well but a small nit here is the folks at Fedora or Debian are not third party. They are a trusted source for me.
I don't know what would be a good solution. Being available on flathub is a good start but I'd argue it is not enough. I'm going to say the proper solution is the same that I advocate Google Play and Apple App Store to follow:
1. require developers to submit source code and machine readable build instructions
2. the store should build the application (fat binaries, differential small updates, whatever, the app store is in charge)
In general, I trust the folks running the distro more than the folks writing the software in the first place. If nothing else, they provide/enforce a second pair of eyes to sanity check things before they get shipped.
The distro also gets to choose a graph of known-good non-conflicting dependencies each time they cut a stable release. If the original author is catering to users who don’t use package databases, he won’t know what they may have available.
License is not the same as trademark, and most licenses do not grant trademark. You can distribute but you have to do it under a different name or brand (should upstream choose to enforce). All the people downvoting need to take a class on how IP laws work.
> This software is not mature yet. Beta testers are highly welcomed, but neither users nor developers get value from people running a beta release that is over a year old.
Which is a perfectly reasonable position for a software project to be in. And if they want to continue to treat their project as Beta software indefinitely that's fine too, but I will treat it as such.
Why would you read it as that? It's clearly not "mature" as in "doesn't need to change much", but it seems like they're seriously committed to quality assurance and testing and stuff you generally don't associate with beta software.
You don't get to write off all software that's not super compatible with some distros' packaging models as "beta software".
Actually, I don't even understand why this discussion of stability is at all relevant. Let's imagine the software was mature to the point where it literally never needed to change again; every last bug is squashed, every desired feature is implemented, the final version of the software is released. What exactly changes? TFA isn't primarily complaining that distros are packaging old versions, after all, but complaining that distros aren't doing enough QA. What would prevent a distro from linking a perfectly mature Bottles against an old version of GTK which has a bug which breaks Bottles?
So even if you have a personal definition of "beta" which categorises this software as "beta"... that's not even remotely related to the contents of the article.
the article doesn't go into detail about what the problems are. basically only these two sentences hint at the issue:
many of these unofficial packages behave abnormally due to the nature of distribution models
Bottles is a complex software that receives frequent updates and requires several dependencies at a minimum specific version to properly work
but yes, you are right, arguing that bottles is beta seems besides the point. the problem appears to be that distribution packagers seem to think that linking bottles to old libraries is better than not having those bottles at all. if that is really the issue then i agree that this is not always a good idea.
unfortunately the article is not clear about that. they could have said:
do not package bottles unless your distribution can satisfy the exact version requirements that the bottles need.
on the other hand, it is not true that old libraries are always a problem. which brings us to lack of QA to test if those backports actually work. again, the article just hints at the issue without spelling out the problem in detail.
Our invitation is addressed to all those who are packaging Bottles incorrectly and/or do not provide adequate tests
was added later.
in summary though their request is reasonable. they do invite the packagers to work together and are not bitter or spiteful. let's hope that the packagers will listen.
Where the hell are you getting your definitions from? You're claiming a piece of software is in beta because in your opinion the releases are too frequent? I suppose you think Google Chrome is in beta too, because it also isn't "mature" enough to be "stable"?
Beta is the last step before release. Nowhere in the definition of "release" is there a requirement that there will be years until the next release, or whatever you think "stable" means in this context. And frankly, release frequency isn't even the topic of the post; a lack of distros doing QA of their packages is the topic. Which hardly falls on Bottles for being "unstable".
stable means that i can use it for a year without needing updates. frequent releases are nice to add new features. but if i don't need the features then i should be able to continue using the old version.
if frequent releases are caused by bugs that need to be fixed then that's not stable.
In my opinion, the issue is mainly that Bottles is still very much beta.
It really needs those frequent updates, which makes it a bad candidate for distro packaging. The correct decision, in my opinion, would have been to break it up into a stable GUI / configuration system and a daily updated "core engine", similar to how antivirus software updates its detection lists. Distros then package the stable parts and the core engine is updated on-demand.
But instead they insist on merging everything and all dependencies into one huge (and in my opinion very bloated) flatpak image which you, the user, then re-download for every tiny update. 10kb code change? re-download all dependencies and all assets!
You may disagree with how they develop it, but I am very much a happy user of Bottles (other than how needlessly hard it is to search). It has made configuring wine and friends so much easier than before. Previously, I would just give up on about the second random forum post indicating this was the magic configuration required to run program X.
I will eat the disk space and heavy updates if it means I have an easier time of running windows applications.
>then re-download for every tiny update. 10kb code change? re-download all dependencies and all assets!
I have never experienced this with flatpak. The updates have always been very small unless they require a new platform version, but these platforms are shared between packages as well.
Having custom updaters in every package to fetch a new "core" sounds like the worst of all situations leading to something like windows where every time you open an app it prompts you to download the new version.
> The correct decision, in my opinion, would have been to break it up into a stable GUI / configuration system and a daily updated "core engine", similar to how antivirus software updates its detection lists.
The effort required to implement this in practice is pretty sizable, and antivirus software ships out signature updates at a much higher frequency than Bottles would be.
> 10kb code change? re-download all dependencies and all assets!
There are rolling distros, with weaker guarantees about whether anything still works from day to day. IMHO Bottles should fork one and make a distro, because they have strong opinions about ownership of update decisions.
I have no clue how you came to this conclusion when nothing in the article complains that distros aren't releasing new versions fast enough. Which exact part of TFA would stop being a problem if Bottles was released less frequently?
Could someone here clarify exactly what the problem is? I don't know what Bottles is, or what it means to be "shipped in distribution repositories". What does it mean to be "unofficial"?
Bottles helps run Windows apps (especially games) on Linux. They have their own installers and updates channel. Generally when using Linux, you will usually install software from the Linux distribution's (like operating system flavor) software repository. It makes dependency management simpler, you get updates only after they're tested, etc. Those repositories are officially supported by the Linux distribution team (which could be employees for a company like Canonical, or volunteers) but not officially supported by the Bottles team.
Bottles is asking the various Linux distributions to stop offering Bottles through the distribution repositories. The Bottles team wants to own the relationship with the end-user under their own terms: only recent versions, only installers that were tested by them personally, and they will support the community issues. Today distros often deliver older versions and modified installers, while still sending the community to get support from the Bottles team.
Anki does something similar by telling Linux users to not use the version from their distro's repo and to instead install from the Anki site, citing misconfiguration on the part of distros.
The problem with this is that all they have available on their site for Linux users is source tarballs which the user is then expected to build themselves, which leads to some of the same problems that come up with distro builds.
I think it's legitimate for projects to not want to be included in distro repos to avoid problems with misconfiguration and the like (though I think it's probably better to design the project such that this kind of failure isn't possible), but doing that should go hand in hand with providing officially supported binaries in some way, whether that be via flatpak, AUR, custom PPA's, etc so there's always an option that is known to be built correctly.
How do other software creators deal with this problem? I can see how getting reports for issues could be frustrating if they weren't easy to replicate due to the distribution having a different version of that software.
I think it's a complicated question to answer because there are so many possible combinations.
1. Simpler software doesn't usually have issues with broken installers.
2. A lot of software doesn't get frequent-enough updates that old versions would matter.
3. High-profile projects usually have personal connections with the major distributions' packaging team (or even a "personal union", where it's actually the same people).
And there are other cases. I think Bottles got stuck in a spot where their software is _very_ complicated to install correctly, updates often (young project + interactions with 3rd party software such as games), and they're a small team that doesn't have a way to work efficiently with the distributions.
Bottles is a software package that makes it easier to run Windows software in Linux-based operating systems (using WINE as the compatibility layer, hence the name).
A Linux distribution (often just "distribution" or "distro") is an operating system that combines an assortment of software packages together; typically a kernel (some version of Linux), core system utilities (coreutils, an init system / service manager), a package manager (program to install software from specified sources; this will become important in a moment), and frequently some sort of graphical system (Desktop Environment). The name is because it distributes a collection of software together.
The thing is, the vast majority of software shipped in/by a distribution isn't written by the distro; a distro is at some level simply a collection of scripts to download sources, compile it into package files, and then bundle those into a usable system. While there are exceptions, most distros have official repositories of software that's been packaged for that distro.
What's happened here is that Bottles is a software package that explicitly doesn't want distros to ship it. Bottles views the packages built/shipped by Linux distros as "unofficial" because they weren't created by the Bottles project.
Bottles is a wine UI and encapsulation layer, similar to the separate previously existing project Bottles, which is is a wine UI and encapsulation layer.
This new Bottles project is appealing to the community to change their behaviour as they are doing something the new Bottles finds undesirable.
Why would you ever use one of these random "Bottles" wrappers instead of the actual Codeweavers Crossover (the company behind many of the salaries of actual Wine developers) is over me.
CodeWeavers also made the original Bottles. From a decade ago:
> The Manage Bottles
functionality lets you manage the Windows software you have under CrossOver, and displays information regarding the bottles they are placed in. You can think of a bottle as a selfcontained Windows environment. Bottles can come in several different flavors—Win98, Win2K, WinXP, etc.
Maybe it's time for more free software projects to take advantage of the the "may require derived works to carry a different name" clause in the Debian Free Software Guidelines and the Open Source Definition.
I think I'd be happiest in a world where distributions make their own decisions about what to package, but in a way that doesn't lead to their users filing unhelpful issues in the upstream bugtracker.
> but in a way that doesn't lead to their users filing unhelpful issues in the upstream bugtracker.
AFAIK most distros also view that as a bug, actually; every time I've seen it discussed was in the context of telling people to file bugs against the distro's bug tracker, both because distros can and do have local bugs that don't even make sense to upstream, and because distro maintainers are generally much better placed to triage and sometimes debug issues.
I have filed a lot of bugs against user level apps on distro bug trackers. Not a single one received even a comment or tag from a maintainer. Unless its a core system app that affects servers, they don't care or have time.
Then you should be perfectly happy with this ask! The article ends with this addendum:
> Our invitation is addressed to all those who are packaging Bottles incorrectly and/or do not provide adequate tests, thus invalidating the user experience. We are happy to help anyone who would like to keep their package, adapting to our quality standards (i.e. making the application work as it intended).
If your system package manager and the people who package Bottles for your system are both very competent (i.e they don't break the software they package and don't introduce problems), Bottles isn't asking your system's packagers to stop packaging the software.
I had basically the same thought: as a user, flatpak means I'll need to install an extra daemon for something that doesn't need to run all the time, and therefore it's right out. AppImage is better in that it doesn't need that, but it has other limitations for the packaged software. I've also used software that just plopped files into /opt/… not great, but at least it's mostly contained.
If you're not going to support some users, don't be surprised that somebody else ends up doing it I guess?
The solution to this is to change the license to forbid redistribution, not to write an open letter.
I think something that is worth discussing is the model of the Linux distribution that leads to poor user experience like this, the distribution issues they are having would be worth discussing in a longer and more technical blog post. It's come up many times among criticisms of Linux ecosystems and distributing user software, but it doesn't seem like the message lands well.
It's remarkable how much easier it is to write software on Linux yet equally remarkable how much more annoying it is to reliably distribute it, compared to say MacOS .apps, the iOS/Android app stores, and to a lesser extent Windows. I don't think there has to be a tradeoff here between Freedom and UX.
> The solution to this is to change the license to forbid redistribution, not to write an open letter.
That depends on goals and what they're willing to do to accomplish those goals; it's quite reasonable to not want to stop being open source over this and to try asking nicely.
> I think something that is worth discussing is the model of the Linux distribution that leads to poor user experience like this[...]. It's come up many times among criticisms of Linux ecosystems and distributing user software, but it doesn't seem like the message lands well.
Because it's not universally viewed as a bug. Plenty of folks explicitly want to download software from their distro's official repos, get something that's specifically tested (and if need be, patched) to play nice with the system, and stay on a known stable version. Because the flip side of this complaint is distro maintainers pointing out that if you downloaded random 3rd party software and added it to your system, they're no longer capable of assuring you that the result will work.
> It's remarkable how much easier it is to write software on Linux yet equally remarkable how much more annoying it is to reliably distribute it, compared to say MacOS .apps, the iOS/Android app stores, and to a lesser extent Windows. I don't think there has to be a tradeoff here between Freedom and UX.
Some folks would argue that it's harder because you shouldn't be doing it; https://drewdevault.com/2021/09/27/Let-distros-do-their-job.... . But if you want to go that way, there's always flatpak/docker/snaps to go around the distro and ship directly to end users.
I think this is a much more productive line of discussion than just asking not to distribute software.
For example, distros don't provide the guarantees you're talking about - they arbitrarily introduce fragility (for example, by requiring shared dependencies that may have conflicting versions) and don't keep up to date with the upstream software that has bug fixes. That's precisely why software authors prefer to release as flatpaks - regardless what distro teams claim, bugs and crashes manifest as problems in the distributed software (not the OS) and are reported to the upstream authors whose users demand fixes.
In short, distros can't provide assurances that software will work. They can't fix it if it's broken, either.
I disagree that it isn't the software authors' job to distribute their software and fix bugs for their users when using it. The only folks who seem to insist that this is The Way Software Should Be Installed are distro authors and a tiny minority of users who are ok with broken code shipped by their OS authors instead of working code by the original authors.
Imagine if an app crashes on Windows or MacOS, a user reports the app crashed, and the author replies: "Sorry it's Microsoft/Apple's fault for shipping broken software on their end, complain to them instead." Because that's the same quality of user experience when a distro ships older versions of software or try and link against invalid dependency versions.
> don't keep up to date with the upstream software that has bug fixes
It is a very rare occurrence that my distro's packages are more than a week out of date from upstream releases
> That's precisely why software authors prefer to release as flatpaks
This implies that "software authors" do "prefer" releasing flatpaks, a plainly false statement for the vast majority of software.
> distros can't provide assurances that software will work
based on interpretation, either plainly false or a misrepresentation. They can't guarantee that software will always work because they operate in the realm of reality, but their raison d'etre is to package software together so they interoperate.
> They can't fix it if it's broken
In fact, distros regularly patch software so they're not broken before (if ever) those patches are merged upstream
> a tiny minority of users
A "tiny minority" of users prefer using their system's package manager? Implying that the vast majority would prefer all their software be packaged and flatpaks and appimages and docker containers? I don't know where you're pulling these numbers from but I bet it smell crazy in there
Not necessarily, unregistered trademarks exist in the United States at least.
And regardless, I'd expect expect someone asked to stop using a given name & logo to be more willing to cooperate than someone told to stop packaging it entirely.
Or just keep the permissive free license, but commit to only supporting Bottles installed via Flatpak and no other way.
Then put that support policy front-and-center on their website and in the LICENSE.txt file so that anyone seeking support knows that the Bottles team only supports Flatpak installs.
GNOME is in a position where any of their sponsored apps switching off of GPL could threaten their FSF endorsement. Creating a redistribution-hostile license forcing users to install Flatpaks instead of native packaging would definitely be an infraction of the FSF values, and it would certainly earn the ire of a non-insignificant number of users who have never touched Flatpak before or have no intentions of using it.
> For a long time, we have included workarounds in the codebase to disable features or change their behavior when dependencies are missing or incorrect.
I don't get this part. Why can't they enforce their constraints at build / start-up time instead?
NixOS Developer here which keeps the bottles package up to date on the side. Updates are usually in master within a day and on the unstable channel within a week or two. Also our distribution model allows us to use the latest and shiniest for bottles or something a little bit older if it isn't working. GTK4 and libadwaita aren't a problem either and are already available to use.
PS: many problems with packages on NixOS are on NixOS. If something is not working always try first to discet it yourself and seek help on Matrix if you are stuck, need help or just have general questions. If you can find a fix, PRs are always welcome. If not that's okay. Maybe you created interest on matrix and someone is going to jump on the fix train. Also you can always creame an issue with all the information you already gathered and logs.
Instead of asking distros to drop your package, just state that the only supported channel of distribution is flatpak. Mercilessly close any issue opened by a user of an unofficial package. Simple as that.
Why can't they just include a visible warning in the software if it is not up to date? Many applications already do that. (I get it might take a little while to get the changes downstream).
It's amazing how far up their own butt people can get with this stuff. Sure the intended audience for this blog would know what all this stuff is, but it's comical how little sense it makes when all the names of things sound like English, but clearly are overloaded. Bottles, FlatPak, Flathub, distribution repositories, etc.. This is especially confusing coming from HackerNews since there's a bunch of stories about shipping containers recently (as it the 40' long steel boxes that go on large cargo vessels across oceans).
I realize that not everything can be written for any random person on the internet to stumble upon and have it make sense, but since any random person can end up on a blog page, some context would be helpful.
It's always baffling to me the web sites for newspapers or restaurants which assume that I know what city/state/country they are in, just because I've landed on a page. Perhaps putting that somewhere in the header/footer just to help ground people would be ok?
As time goes by I miss old school distro distribution model more and more, while I used to hate it long time ago. It took to long for new versions to arrive.
Now I'm leaning toward Debian and alike, as mainteners do a lot of work I value while developers of many modern products don't. I remind myself about it each time I have to fight with npm issues, for instance.
Of course many distros will just tell the upstream to pound sand, and more power to them. When I'm perfectly happy running the version that shipped with my OS, I DON'T want your updates. Just leave me alone.