“This version of XScreenSaver is very old. Please upgrade” • Hacker News Board

Re: “This version of XScreenSaver is very old. Please upgrade”

#71

Post by zanny » Sat, Apr 02, 2016, 9:18 PM UTC

digi_owl wrote: post #39

zanny wrote: post #31

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 th…

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 oth…

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.

Re: “This version of XScreenSaver is very old. Please upgrade”

#72

Post by _delirium » Sat, Apr 02, 2016, 11:05 PM UTC

zanny wrote: post #61

_delirium wrote: post #35

Earlier quoted context omitted.

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.

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 th…

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.

Re: “This version of XScreenSaver is very old. Please upgrade”

#73

Post by binarycrusader » Sun, Apr 03, 2016, 12:12 AM UTC

gens wrote: post #69

binarycrusader wrote: post #52

Earlier quoted context omitted.

Because statically linking everything has several negative consequences: * increased storage space * increased memory usage * increased downtime for updates (since more files have to be updated) * increased bandwidth usage (total size of download for update) * potentially increased security risks In short, trading off all of the above to simply avoid proper release engineering and simplified dependency management is…

statically linking to properly(!) made libraries will only maybe increase storage space it will decrease memory usage (as most loaders load the whole library, even when just one function is used) more things to upgrade, yes more bandwidth, yes (not much if one uses binary diffs) potentially increased security risks, yes. although shared libraries are bigger security risks i made an acc just to reply to this. why do p…

statically linking to properly(!) made libraries will only maybe increase storage space it will decrease memory usage (as most loaders load the whole library, even when just one function is used)

Most OS linkers already do efficient loading of only the relevant portions of a shared library since they typically mmap the library file.

In aggregate, static linking the same dependency for multiple programs will increase memory usage as well despite your assertions to the contrary since the pages will not generally be shared (yes, I'm aware some OS have page dedup or compression, etc., but I'm talking about the general case here).

more things to upgrade, yes more bandwidth, yes (not much if one uses binary diffs)

A binary diff of 100 programs all linking to the same library will still be larger than the diffs for a single library.

In addition, updating 100 binaries, even with diffs still takes longer than uprating a single library, which means increased downtime during system updates.

potentially increased security risks, yes. although shared libraries are bigger security risks

Code is code; how is shared linking a greater risk? Have any data to back that up?

i made an acc just to reply to this. why do people never understand static linking ?

I understand static linking quite well, since my day job is part of a commercial OS team that coincidentally pioneered dynamic linking technology in UNIX.

So let's not base our arguments on assumptions about knowledge just because we disagree.

Re: “This version of XScreenSaver is very old. Please upgrade”

#74

Post by clevernickname » Sun, Apr 03, 2016, 12:22 AM UTC

binarycrusader wrote: post #52

haddr wrote: post #34

Earlier quoted context omitted.

Spot on. I was always puzzled why some software just can't come statically compiled. I suppose not all apps can be distributed like that, but most of them can. I can't even remember how many hours I wasted on trying to compile a new version of some program, just to learn the infinite tree of dependencies, newer versions of existing libraries required, build prefixes tweaking etc... Most of that time could have been s…

Because statically linking everything has several negative consequences: * increased storage space * increased memory usage * increased downtime for updates (since more files have to be updated) * increased bandwidth usage (total size of download for update) * potentially increased security risks In short, trading off all of the above to simply avoid proper release engineering and simplified dependency management is…

A tradeoff that few consider is that dynamic linking can lessen the motivation of library developers to reduce code bloat and complex dependency trees. Who cares about 20 megs here or there if there is only one shared library instance? Who cares about bringing in a tree of 50 dependencies for this console program if the user probably has them installed already? And thus we end up with the modern Linux desktop, where nearly everything depends on a gigabyte or more of dependencies.

Whereas with static linking, you can directly see the effect that any library you use has on the binary size. This encourages library and application devs alike to be more judicious with their dependencies.

Re: “This version of XScreenSaver is very old. Please upgrade”

#75

Post by ferrari8608 » Sun, Apr 03, 2016, 1:08 AM UTC

tinco wrote: post #26

castratikron wrote: post #19

Earlier quoted context omitted.

Not a chance! Debian is the only sane Linux distro. Xubuntu would by alright if they ever decide to switch to systemd.

Fair enough, I only use insane distros. I quit Debian because I wanted to dev in Ruby and it wouldn't let me. Then I used Archlinux for a while, but having to use rescue mode everytime I did 'pacman -Syu' got a little old so I switched to a sane OS for a while. Seriously, aren't both Ubuntu and CentOS not much saner than Debian? Anyway, my sane period ended a while ago, it's full on NixOS now, why are people still us…

Having to rescue your system after every upgrade is either an exaggeration or you do weird things with your system. If the latter, quit that.

I had my Arch system running for over a year, upgraded at least once a week. Only once did I need the rescue disk, and that was my own fault (some um... "clever" pacman command I dreamed up ended up uninstalling some pretty important things like all of base).

Re: “This version of XScreenSaver is very old. Please upgrade”

#76

Post by binarycrusader » Sun, Apr 03, 2016, 1:56 AM UTC

clevernickname wrote: post #74

binarycrusader wrote: post #52

Earlier quoted context omitted.

Because statically linking everything has several negative consequences: * increased storage space * increased memory usage * increased downtime for updates (since more files have to be updated) * increased bandwidth usage (total size of download for update) * potentially increased security risks In short, trading off all of the above to simply avoid proper release engineering and simplified dependency management is…

A tradeoff that few consider is that dynamic linking can lessen the motivation of library developers to reduce code bloat and complex dependency trees. Who cares about 20 megs here or there if there is only one shared library instance? Who cares about bringing in a tree of 50 dependencies for this console program if the user probably has them installed already? And thus we end up with the modern Linux desktop, where…

A tradeoff that few consider is that dynamic linking can lessen the motivation of library developers to reduce code bloat and complex dependency trees.

Architecting an operating system and its packages as a psychological forcing function to improve software development is not a worthwhile tradeoff for the efficiency, security, or reliability of a system.

Who cares about 20 megs here or there if there is only one shared library instance? Who cares about bringing in a tree of 50 dependencies for this console program if the user probably has them installed already? And thus we end up with the modern Linux desktop, where nearly everything depends on a gigabyte or more of dependencies.

I find it amusing that someone is arguing for static linking as a way to make it obvious how bloated programs are, since usually the counter-argument to dynamic linking from many is "who cares about disk space!".

There are plenty of programs that are distributed essentially statically-linked today, that still have 50 dependencies or more -- there is no data that I am aware of to support the idea that dynamic vs. static linking would encourage developers to reduce their dependencies.

Whereas with static linking, you can directly see the effect that any library you use has on the binary size. This encourages library and application devs alike to be more judicious with their dependencies.

This is a dubious argument at best; you can still easily see the size of your program today even if it's dynamically linked simply by looking at top, or by using the appropriate developer tools.

I can empathize with the frustrations that some feel in dealing with some operating systems and applications, but it is not due to a technological issue -- it is due to cultural and process issues present not only in the development of the software they rely on but in the distributions that provide the software themselves.

"papering over" those issues by static linking only makes the problem worse -- not better. This a cultural and process issue that cannot be addressed solely through technological means.

Also, I want to be clear that I am not linking against static linking completely; I'm arguing for dynamic linking (or more generally, shared objects) for those dependencies shared between a sufficient number of components that have sufficiently stable interfaces to share them.

By all means, if there is a component with a sufficiently unstable interface, then by definition, it is not appropriate for sharing between components, and at that point whether you statically or dynamically-link the dependency is moot, since you can have private dynamically-linked dependencies just as easily statically-linking them into binaries.

Re: “This version of XScreenSaver is very old. Please upgrade”

#77

Post by tinco » Sun, Apr 03, 2016, 2:10 AM UTC

ferrari8608 wrote: post #75

tinco wrote: post #26

Earlier quoted context omitted.

Fair enough, I only use insane distros. I quit Debian because I wanted to dev in Ruby and it wouldn't let me. Then I used Archlinux for a while, but having to use rescue mode everytime I did 'pacman -Syu' got a little old so I switched to a sane OS for a while. Seriously, aren't both Ubuntu and CentOS not much saner than Debian? Anyway, my sane period ended a while ago, it's full on NixOS now, why are people still us…

Having to rescue your system after every upgrade is either an exaggeration or you do weird things with your system. If the latter, quit that. I had my Arch system running for over a year, upgraded at least once a week. Only once did I need the rescue disk, and that was my own fault (some um... "clever" pacman command I dreamed up ended up uninstalling some pretty important things like all of base).

It's a joke about how Archlinux works. If you do a "pacman -Syu" without reading the changelogs there is a good chance your system won't boot. You just can't be negligent. They might change the location of libc, they might switch to systemd, they change whatever they need to to be the coolest operating system on the block, and that's why I love them. But if you weren't hip to it, your system won't boot.

Re: “This version of XScreenSaver is very old. Please upgrade”

#78

Post by zanny » Sun, Apr 03, 2016, 3:07 AM UTC

_delirium wrote: post #72

zanny wrote: post #61

Earlier quoted context omitted.

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 th…

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 m…

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.

Re: “This version of XScreenSaver is very old. Please upgrade”

#79

Post by _delirium » Sun, Apr 03, 2016, 4:33 AM UTC

zanny wrote: post #78

_delirium wrote: post #72

Earlier quoted context omitted.

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 m…

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.

Well if upstream doesn't want Debian to ship broken software in a stable version, there's a solution: upstream should improve their quality control and not ship broken software in the first place. ;)

But I mean, there's no actual obligation to update software. Lots of redistributors don't update to the latest version for many reasons. Apple ships old GNU utilities because they don't like GPLv3. FreeBSD ships an old version of OpenBSD's pf firewall because their patched version is hard to forward-port. OpenBSD ships a truly ancient gcc for a mixture of technical and license reasons. And Debian updates software on a fixed stable-release cycle. I suppose it's fair that upstream can complain about this: GNU and jwz don't have to be happy that people are shipping old versions of their software. But people are also probably not going to stop doing it.

Re: “This version of XScreenSaver is very old. Please upgrade”

#80

Post by ferrari8608 » Sun, Apr 03, 2016, 6:15 AM UTC

tinco wrote: post #77

ferrari8608 wrote: post #75

Earlier quoted context omitted.

Having to rescue your system after every upgrade is either an exaggeration or you do weird things with your system. If the latter, quit that. I had my Arch system running for over a year, upgraded at least once a week. Only once did I need the rescue disk, and that was my own fault (some um... "clever" pacman command I dreamed up ended up uninstalling some pretty important things like all of base).

It's a joke about how Archlinux works. If you do a "pacman -Syu" without reading the changelogs there is a good chance your system won't boot. You just can't be negligent. They might change the location of libc, they might switch to systemd, they change whatever they need to to be the coolest operating system on the block, and that's why I love them. But if you weren't hip to it, your system won't boot.

Arch isn't a distro for people who take issue to reading up on what they're actually doing to their system with upgrades, package installations, and configuration. That's why they have one of the most amazing wikis around. It's expected that you read all of the things.

I still don't agree with the unbootable bit though. That hasn't happened on any of my systems (two Arch machines, two Arch-based Antergos machines) in over a year without it being my own fault tinkering with something. I don't know man, maybe we're running completely different hardware or something.