3 ms·

Sure, but we’ve tried that technique for about 20 years. We learned that most app developers hate it; to the point they don’t even bother supporting the platfo

Sure, but we’ve tried that technique for about 20 years. We learned that most app developers hate it; to the point they don’t even bother supporting the platform unless they are FOSS diehards. Those that do screech about not using the packaged version on almost all of their developer forums, most often because they are out of date and users blame them for bugs that were already fixed. This actually is infuriating - imagine fixing a bug, but 2 years later, the distribution isn’t shipping your update, and users are blaming you and still opening bug reports. The distribution also will not be persuaded, because it’s the “stable” branch for the next 3 years. Basically, Linux sucks terribly, either way, with app distribution. Linux distributions have nobody to blame but themselves for being ineffectual here.

rlpb 1y ago
> The distribution also will not be persuaded, because it’s the “stable” branch for the next 3 years. This is exactly what users want, though. Eg. if they want to receive updates more frequently on Ubuntu then they can use the six monthly releases, but most Ubuntu users deliberately choose the LTS over that option because they don't want everything updated.
- gjsman-1000 1y ago
  But if you’re a developer, that doesn’t change that many users do not understand, will not understand, and will open bug reports regularly. When that happens, guess what you do? You trademark your software’s name and use the law to force distributions to not package unless concessions are granted. We’re beginning to see this with OBS, but Firefox also did this for a while. As Fedora quickly found, when trademark law gets involved, any hope of forcing developers to allow packaging through a policy or opinion vote becomes hilariously, comically ineffectual. The other alternative is to just not support Linux. Almost all major software has been happily taking that path, and the whole packaging mess gives no incentive to change.
  - mananaysiempre 1y ago
    > When that happens, guess what you do? Ban the user that did not read go to the distro’s maintainers first.
  - dredmorbius 1y ago
    What's the Fedora trademark issue?
    - mook 1y ago
      Fedora had their own OBS Flatpak that had known-buggy (but newer and "supported") dependencies. https://lwn.net/Articles/1011511/ https://lwn.net/Articles/1011511/
      - dredmorbius 1y ago
        Thanks!
  - rlpb 1y ago
    > You trademark your software’s name and use the law to force distributions to not package unless concessions are granted. It isn't clear if this behaviour is legally enforceable. Distributions typically try to avoid the conflict. But they could argue that "we modified Firefox to meet our standards and here is the result" is a legally permitted use of that trademark. To my knowledge, this has never been tested.
- martinald 1y ago
  At the end of the day the 'traditional' Linux packaging system in where distributions do it all for you is totally outdated. Tbh I can remember in the early/mid 2000s being extremely annoyed with this so I don't know if it was ever a good model. On SaaS/mobile apps you have often daily new versions of software coming out. That's what users/developers want. They do not want 3 year+ stale versions of their software being 'supported' by a third party distro. I put supported in comments as it only really applies to security and what not; not terrible bugs in the software that are fixed in later versions. Even on servers where it arguably makes more sense it has been entirely supplanted by Docker which ships the _entire OS_ more or less as the 'app'. And even more damingly, most/nearly all people will use a 3rd party Docker repo to manage the docker 'core' software updates itself. And the reason noone uses the six monthly releases is because the upgrade process is too painful and regresses too much. But - even if it was 100% bulletproof, noone wants to be running 6-12 month out of date software on that either. Chrom(ium) is updated monthly and has a lot of important new features in it. You don't really want to be running 6-9 months out of date on that.
  - HdS84 1y ago
    Exactly. In theory, the original windows 10 model is the one most users want: a perpetually up to date os which runs also up to date software. Yes, of there might be reasons the pin something to an older version, but it this pc is on a network, security alone tells you to update ASAP. Don't get me wrong, a working package manager is a very good addition to this model. But currently, most of the time setting up a ltm Linux system I spent on updating ancient git/docker whatever versions.
    - hedora 1y ago
      Which users want UIs to change (and often break) multiple times a month? Do you have any evidence to back that statement up?
dredmorbius 1y ago
...imagine fixing a bug, but 2 years later, the distribution isn’t shipping your update... This grossly misstates the concept of a stable distribution (e.g., Debian stable, with which I'm most familiar). Debian stable isn't "stable" in that packages don't change, to the point that updates aren't applied at all, it's stable in that functionality and interfaces are stable. The user experience (modulo bugs and security fixes) does not change. Stable does receive updates that address bugs and security issues. What Stable does not do is radically revise programs, applications, and libraries. Though it's more nuanced than that even: stable provides several options for tracking rapidly-evolving software, the most notorious and significant of which are Web browsers with the major contenders updating quite frequently (quarterly or monthly, for example, for Google Chrome "stable" and "dev" respectively). That's expanded further with Flatpack, k8s, and other options, in recent years. The catch is that updates require package maintainers to work on integrating and backporting fixes to code. More prominent and widely-used packages do this. The issue of old bugs being reported to upstream ... is a breakage of the system in several ways: distro's bug-tracking systems (BTSes) should catch (and be used by) their users, upstream BTSes arguably should reject tickets opened on older (and backported) versions. The solutions are neither purely technical nor social, which makes solutions challenging. But in reality we should admit that: - Upstream developers don't like dealing with the noise of stale bugs. - Users are going to rant to upstream regardless of distro-level alternatives. - Upstreams' BTSes should anticipate this and automate redirection of bugs to the appropriate channel with as little dev intervention as possible. Preferably none. - Distros should increase awareness and availability of their own BTS systems to address bugs specific to the context of that distro. - Distro maintainers should be diligent about being aware of and backporting fixes and only fixes. - Distros should increase awareness and availability of alternatives for running newer versions of software which aren't in the distro's own stable repos. Widespread distance technological education is a tough nut regardless, there will be failings. The key is that to the extent possible those shouldn't fall on upstream devs. Though part of that responsibility, and awareness of the overall problem, does fall on those upstream devs.
- dredmorbius 1y ago
  And just to provide some references so you don't have to take my word for it, from the Debian FAQ: "2.2. Are there package upgrades in "stable"?" Generally speaking, no new functionality is added to the stable release. Once a Debian version is released and tagged "stable" most packages will only get security updates.... there are some cases in which packages will be updated in stable ... When an urgent update is required to ensure the software continues working. The package is a data package and the data must be updated in a timely manner. The package needs to be current to useful to end user (e.g. some security software, such as anti-malware products).... And: Users that wish to run updated versions of the software in stable have the option to use "backports". Backports are recompiled packages from testing (mostly) and unstable (in a few cases only, e.g. security updates), so they will run without new libraries (wherever it is possible) on a stable Debian distribution. Debian is strict in interpreting security updates: Security updates serve one purpose: to supply a fix for a security vulnerability. They are not a method for sneaking additional changes into the stable release without going through normal point release procedure. <https://www.debian.org/doc/manuals/debian-faq/getting-debian.en.html#updatestable https://www.debian.org/doc/manuals/debian-faq/getting-debian...>

rlpb 1y ago

> The distribution also will not be persuaded, because it’s the “stable” branch for the next 3 years. This is exactly what users want, though. Eg. if they want to receive updates more frequently on Ubuntu then they can use the six monthly releases, but most Ubuntu users deliberately choose the LTS over that option because they don't want everything updated.

gjsman-1000 1y ago
But if you’re a developer, that doesn’t change that many users do not understand, will not understand, and will open bug reports regularly. When that happens, guess what you do? You trademark your software’s name and use the law to force distributions to not package unless concessions are granted. We’re beginning to see this with OBS, but Firefox also did this for a while. As Fedora quickly found, when trademark law gets involved, any hope of forcing developers to allow packaging through a policy or opinion vote becomes hilariously, comically ineffectual. The other alternative is to just not support Linux. Almost all major software has been happily taking that path, and the whole packaging mess gives no incentive to change.
- mananaysiempre 1y ago
  > When that happens, guess what you do? Ban the user that did not read go to the distro’s maintainers first.
- dredmorbius 1y ago
  What's the Fedora trademark issue?
  - mook 1y ago
    Fedora had their own OBS Flatpak that had known-buggy (but newer and "supported") dependencies. https://lwn.net/Articles/1011511/ https://lwn.net/Articles/1011511/
    - dredmorbius 1y ago
      Thanks!
- rlpb 1y ago
  > You trademark your software’s name and use the law to force distributions to not package unless concessions are granted. It isn't clear if this behaviour is legally enforceable. Distributions typically try to avoid the conflict. But they could argue that "we modified Firefox to meet our standards and here is the result" is a legally permitted use of that trademark. To my knowledge, this has never been tested.
martinald 1y ago
At the end of the day the 'traditional' Linux packaging system in where distributions do it all for you is totally outdated. Tbh I can remember in the early/mid 2000s being extremely annoyed with this so I don't know if it was ever a good model. On SaaS/mobile apps you have often daily new versions of software coming out. That's what users/developers want. They do not want 3 year+ stale versions of their software being 'supported' by a third party distro. I put supported in comments as it only really applies to security and what not; not terrible bugs in the software that are fixed in later versions. Even on servers where it arguably makes more sense it has been entirely supplanted by Docker which ships the _entire OS_ more or less as the 'app'. And even more damingly, most/nearly all people will use a 3rd party Docker repo to manage the docker 'core' software updates itself. And the reason noone uses the six monthly releases is because the upgrade process is too painful and regresses too much. But - even if it was 100% bulletproof, noone wants to be running 6-12 month out of date software on that either. Chrom(ium) is updated monthly and has a lot of important new features in it. You don't really want to be running 6-9 months out of date on that.
- HdS84 1y ago
  Exactly. In theory, the original windows 10 model is the one most users want: a perpetually up to date os which runs also up to date software. Yes, of there might be reasons the pin something to an older version, but it this pc is on a network, security alone tells you to update ASAP. Don't get me wrong, a working package manager is a very good addition to this model. But currently, most of the time setting up a ltm Linux system I spent on updating ancient git/docker whatever versions.
  - hedora 1y ago
    Which users want UIs to change (and often break) multiple times a month? Do you have any evidence to back that statement up?

dredmorbius 1y ago

...imagine fixing a bug, but 2 years later, the distribution isn’t shipping your update... This grossly misstates the concept of a stable distribution (e.g., Debian stable, with which I'm most familiar). Debian stable isn't "stable" in that packages don't change, to the point that updates aren't applied at all, it's stable in that functionality and interfaces are stable. The user experience (modulo bugs and security fixes) does not change. Stable does receive updates that address bugs and security issues. What Stable does not do is radically revise programs, applications, and libraries. Though it's more nuanced than that even: stable provides several options for tracking rapidly-evolving software, the most notorious and significant of which are Web browsers with the major contenders updating quite frequently (quarterly or monthly, for example, for Google Chrome "stable" and "dev" respectively). That's expanded further with Flatpack, k8s, and other options, in recent years. The catch is that updates require package maintainers to work on integrating and backporting fixes to code. More prominent and widely-used packages do this. The issue of old bugs being reported to upstream ... is a breakage of the system in several ways: distro's bug-tracking systems (BTSes) should catch (and be used by) their users, upstream BTSes arguably should reject tickets opened on older (and backported) versions. The solutions are neither purely technical nor social, which makes solutions challenging. But in reality we should admit that: - Upstream developers don't like dealing with the noise of stale bugs. - Users are going to rant to upstream regardless of distro-level alternatives. - Upstreams' BTSes should anticipate this and automate redirection of bugs to the appropriate channel with as little dev intervention as possible. Preferably none. - Distros should increase awareness and availability of their own BTS systems to address bugs specific to the context of that distro. - Distro maintainers should be diligent about being aware of and backporting fixes and only fixes. - Distros should increase awareness and availability of alternatives for running newer versions of software which aren't in the distro's own stable repos. Widespread distance technological education is a tough nut regardless, there will be failings. The key is that to the extent possible those shouldn't fall on upstream devs. Though part of that responsibility, and awareness of the overall problem, does fall on those upstream devs.

dredmorbius 1y ago
And just to provide some references so you don't have to take my word for it, from the Debian FAQ: "2.2. Are there package upgrades in "stable"?" Generally speaking, no new functionality is added to the stable release. Once a Debian version is released and tagged "stable" most packages will only get security updates.... there are some cases in which packages will be updated in stable ... When an urgent update is required to ensure the software continues working. The package is a data package and the data must be updated in a timely manner. The package needs to be current to useful to end user (e.g. some security software, such as anti-malware products).... And: Users that wish to run updated versions of the software in stable have the option to use "backports". Backports are recompiled packages from testing (mostly) and unstable (in a few cases only, e.g. security updates), so they will run without new libraries (wherever it is possible) on a stable Debian distribution. Debian is strict in interpreting security updates: Security updates serve one purpose: to supply a fix for a security vulnerability. They are not a method for sneaking additional changes into the stable release without going through normal point release procedure. <https://www.debian.org/doc/manuals/debian-faq/getting-debian.en.html#updatestable https://www.debian.org/doc/manuals/debian-faq/getting-debian...>