5 ms·

I don't (ever) link my own psychotic blog rants on HN (not because I value anything close to a reputation, but because I don't want to inflict my stupid on othe

by zanny 11y ago

I don't (ever) link my own psychotic blog rants on HN (not because I value anything close to a reputation, but because I don't want to inflict my stupid on others) but I wasted an hour last evening on an exceedingly long tirade fairly congruent with this debacle.[1] On topic though, nobody wants to develop the way distributions want you to - basically maintain branches of every release you make for the lifetime of the distros where you backport bug fixes but not feature additions. Very little software, even libraries, is ever developed like that, and it is part of the reason why Linux desktops are a Mess™. And practically, you often cannot even do this. Your feature additions will optimize code that your bug fixes interact with, and trying to keep them separate is an exercise in masochism. The TLDR answer is the sooner we can get a community software repo with open signups that developers push new releases to that supports appstream / xdg-app infrastructure the better. Distributions can still freeze the world and maintain all the stability they want, but we need to also let developers take responsibility for their own software on desktop releases. https://zannyland.wordpress.com/2016/04/02/software-rants-23-build-a-better-distro-neon-problems/ https://zannyland.wordpress.com/2016/04/02/software-rants-23...

_delirium 11y ago
jwz here seems to be arguing that distros shouldn't be allowed to freeze his software, even if they do it themselves and maintain the branch themselves. He wants only current versions of his software shipped, and old versions disabled once they reach a certain age. I don't think this is an entirely reasonable demand, at least for open-source software.
- maxerickson 11y ago
  More charitably, he thinks the distro choice to freeze something should result in 0 headaches for him. The idea that the freeze should be done without carefully taking responsibility for it is probably a pretty stupid norm, so I can understand the lack of patience.
- zanny 11y ago
  It should be perfectly reasonable, it is just that within the infrastructure of projects like Debian and RHEL there are no mechanisms for a developer to assume responsibility for their own software. The disconnect of both behavior and authority in pushing new releases vs distributing new releases is a problem, particularly for user facing applications and collections like KDE or VLC. Debian can, and should, freeze their software and provide support for what they package. But the developer should both be able to ask Debian to remove it, and to provide it themselves. But not in the traditional insanely bad and broken Windows "search the Internet for random binaries and use those" method. We have the capability, fairly easily, to provide a community repository that crosses distros and lets developers directly ship and update their own software, we just need to provide the capacity. Tech like appstream is how you enable it.
  - _delirium 11y ago
    As a Debian user, that isn't really what I'm looking for. I like Debian's release management. For a stable Debian release, I don't want upstream being allowed to either: 1) push major feature and API changes, or 2) remove the software entirely. Then I'd have to deal with every random upstream's release model, whereas today I understand and trust Debian's synchronized release model. I think it's fine if this doesn't meet the wishes of how upstream wants to manage releases. Part of the point of free software is that we have a right to adapt software to serve our own needs, without needing permission of the original authors. Rolling-style releases, which get updated whenever upstream wants to push an update, are a nice option to have. But a Debian-style stable release model is also a nice option to have. So I'd like both to exist, and wouldn't want upstream package authors to be able to veto the existence of stable releases.
    - zanny 11y ago
      Its not about vetoing, it is about Debian shipping broken software that is never updated and it drives developers mad to constantly get the same bug report for the same broken feature that was fixed years ago upstream. I personally hope none of my software ends up in Debian Stable, because if it did anything broken in it at the point of freeze would haunt me for half a decade.
digi_owl 11y ago
Having used Gobolinux for some years now, i find the xdg-app thinking a case of shooting twee twee birds with AA guns. *nix already have a mechanism called soname in place that allow versioned libs to live side by side. Gobolinux makes good use of it, along with symlinking, to allow multiple versions to be installed side by side. You find similar, tho more elaborate, systems in place in NixOS/Guix. xdg-app on the other hand comes out of the RPM/DEB camp, where there can only be one canonical version of every package installed at any one time. So to get around that they device a system where you basically build a new system for each and every "package". What that effectively does is replacing dependency "hell" for dll hell (hello Windows).
- zanny 11y ago
  Different versions of the same libraries for different applications is still the same problem. Fundamentally developers are writing software that distributors and integrators do not want to actually ship. There are two independent circumstances to that, though. Either the developer does not deserve downstream trust because they abuse their users by breaking their APIs, ABIs, or UX's without due notice or process. This is how things were in the early 90s when Debian first started and the original crop of distributions emerged - the mindset was, of course as a distributor I have to assume responsibility for packaging and integrating all the software I ship, and thus of course I cannot track the individual releases of everything I include while making sure everything still works. That is insane, and no software distributor in the world does that. The other circumstance is when developers do deserve trust but are not given it, as is the case in Debian, or why KDE needed the Neon project. Or when they want to assume the responsibility on their own, which no Linux distro provides adequate means to directly support users.
  - digi_owl 11y ago
    From where i sit, what seems to block most distributors from upgrading is the rigidity of their tradition package managers when dealing with multiple versions. Thus they are reluctant to adopt new version of something, because the dependency chain may force a update of a large part of a installed system. A package manager that can handle multiple version frees them from this worry, without the admin of a system having to trawl every "container" if a lib is found to be vulnerable (a very real possibility with the likes of xdg-app, and somewhat akin to Windows "dll hell").
icebraining 11y ago
> On topic though, nobody wants to develop the way distributions want you to - basically maintain branches of every release you make for the lifetime of the distros where you backport bug fixes but not feature additions. I'm pretty sure that's not how Debian wants to handle software. The whole point of Stable is that packages won't get any new updates, with the single exception of security fixes. Regular bugs are not supposed to be fixed, because doing so introduces uncertainty - you might be introducing new bugs or changing expected behavior.

by zanny 11y ago

_delirium 11y ago

jwz here seems to be arguing that distros shouldn't be allowed to freeze his software, even if they do it themselves and maintain the branch themselves. He wants only current versions of his software shipped, and old versions disabled once they reach a certain age. I don't think this is an entirely reasonable demand, at least for open-source software.

maxerickson 11y ago
More charitably, he thinks the distro choice to freeze something should result in 0 headaches for him. The idea that the freeze should be done without carefully taking responsibility for it is probably a pretty stupid norm, so I can understand the lack of patience.
zanny 11y ago
It should be perfectly reasonable, it is just that within the infrastructure of projects like Debian and RHEL there are no mechanisms for a developer to assume responsibility for their own software. The disconnect of both behavior and authority in pushing new releases vs distributing new releases is a problem, particularly for user facing applications and collections like KDE or VLC. Debian can, and should, freeze their software and provide support for what they package. But the developer should both be able to ask Debian to remove it, and to provide it themselves. But not in the traditional insanely bad and broken Windows "search the Internet for random binaries and use those" method. We have the capability, fairly easily, to provide a community repository that crosses distros and lets developers directly ship and update their own software, we just need to provide the capacity. Tech like appstream is how you enable it.
- _delirium 11y ago
  As a Debian user, that isn't really what I'm looking for. I like Debian's release management. For a stable Debian release, I don't want upstream being allowed to either: 1) push major feature and API changes, or 2) remove the software entirely. Then I'd have to deal with every random upstream's release model, whereas today I understand and trust Debian's synchronized release model. I think it's fine if this doesn't meet the wishes of how upstream wants to manage releases. Part of the point of free software is that we have a right to adapt software to serve our own needs, without needing permission of the original authors. Rolling-style releases, which get updated whenever upstream wants to push an update, are a nice option to have. But a Debian-style stable release model is also a nice option to have. So I'd like both to exist, and wouldn't want upstream package authors to be able to veto the existence of stable releases.
  - zanny 11y ago
    Its not about vetoing, it is about Debian shipping broken software that is never updated and it drives developers mad to constantly get the same bug report for the same broken feature that was fixed years ago upstream. I personally hope none of my software ends up in Debian Stable, because if it did anything broken in it at the point of freeze would haunt me for half a decade.

digi_owl 11y ago

Having used Gobolinux for some years now, i find the xdg-app thinking a case of shooting twee twee birds with AA guns. *nix already have a mechanism called soname in place that allow versioned libs to live side by side. Gobolinux makes good use of it, along with symlinking, to allow multiple versions to be installed side by side. You find similar, tho more elaborate, systems in place in NixOS/Guix. xdg-app on the other hand comes out of the RPM/DEB camp, where there can only be one canonical version of every package installed at any one time. So to get around that they device a system where you basically build a new system for each and every "package". What that effectively does is replacing dependency "hell" for dll hell (hello Windows).

zanny 11y ago
Different versions of the same libraries for different applications is still the same problem. Fundamentally developers are writing software that distributors and integrators do not want to actually ship. There are two independent circumstances to that, though. Either the developer does not deserve downstream trust because they abuse their users by breaking their APIs, ABIs, or UX's without due notice or process. This is how things were in the early 90s when Debian first started and the original crop of distributions emerged - the mindset was, of course as a distributor I have to assume responsibility for packaging and integrating all the software I ship, and thus of course I cannot track the individual releases of everything I include while making sure everything still works. That is insane, and no software distributor in the world does that. The other circumstance is when developers do deserve trust but are not given it, as is the case in Debian, or why KDE needed the Neon project. Or when they want to assume the responsibility on their own, which no Linux distro provides adequate means to directly support users.
- digi_owl 11y ago
  From where i sit, what seems to block most distributors from upgrading is the rigidity of their tradition package managers when dealing with multiple versions. Thus they are reluctant to adopt new version of something, because the dependency chain may force a update of a large part of a installed system. A package manager that can handle multiple version frees them from this worry, without the admin of a system having to trawl every "container" if a lib is found to be vulnerable (a very real possibility with the likes of xdg-app, and somewhat akin to Windows "dll hell").

icebraining 11y ago

> On topic though, nobody wants to develop the way distributions want you to - basically maintain branches of every release you make for the lifetime of the distros where you backport bug fixes but not feature additions. I'm pretty sure that's not how Debian wants to handle software. The whole point of Stable is that packages won't get any new updates, with the single exception of security fixes. Regular bugs are not supposed to be fixed, because doing so introduces uncertainty - you might be introducing new bugs or changing expected behavior.