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.
But that's exactly what jwz asked!
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.
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.
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.
GUI heavy application like chrome, firefox or openoffice run on all districts without any hiccup!
what am i missing ?
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.
If you need local development/production environment version parity, use container images or package locking files available in most programming language ecosystems.
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.
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.
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.
Debian is almost there, but it's stopped almost there for a long time already.
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.
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.
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.
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.
If more people are like me, then that wouldn't help solve the problem at all.
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.
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.
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 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)
3. ...
4. Profit?
Yeah, that's all that really needs to be said about that. And people wonder why the Year of the Linux Desktop never arrived.
Because every time it did, people moved the goalposts.
I, for one, am grateful that things like FlatPak and AppImage are finally gaining traction and I hope the trend continues.
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.
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…
C.f. Iceweasel