Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

bugs.debian.org

Post reply on HN
Print view View original

61–70 of 105 posts

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

#61

Post by zanny »

_delirium wrote: post #35
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…

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 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.

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

#62

Post by icebraining »

Ologn wrote: post #44
jarcane wrote: post #23

Frankly, this is a very good example why I inevitably give up on using Debian. It is not the software writers' fault that your distro can't be arsed to keep its package system up-to-date. Even the unstable branch is routinely multiple versions behind on software. The idea of linking end-user software versioning to the operating system version itself was always a dumb idea, but has become even more absurd over time. N…

> It is not the software writers' fault that your distro can't be arsed to keep its package system up-to-date. That's it. Ubuntu releases every six months, it's not upstream's problem that an up-to-date version of your stable distro is using the program released in September 2014 (17 months ago). As XScreenSaver 5.32 was released in November 2014 and Debian stable was released in April 2015, you have to wonder why in…

if Debian channeled all of that energy and effort into a shorter, saner release cycle, it would be much more beneficial to everyone.

The whole point of Stable is that it doesn't change often. As a Debian user, I don't want to upgrade my servers every six months. I'm fine with stale packages (with backported security patches). There's a reason why Ubuntu, despite its standard release cycle, also maintains LTS releases for both servers and desktops for five years; but adopting that approach that requires much more effort than just switching the cycle as you're suggesting.

Also, another advantage of longer cycles is that Testing has more time to mature, which is why a Stable release is - in my experience - much more stable than an Ubuntu release.

So, yeah, I'm fine with having to compile XScreensaver myself. But I choose Debian because it's not like Ubuntu or Fedora.

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

#63

Post by feld »

qplex wrote: post #32
jarcane wrote: post #23

Frankly, this is a very good example why I inevitably give up on using Debian. It is not the software writers' fault that your distro can't be arsed to keep its package system up-to-date. Even the unstable branch is routinely multiple versions behind on software. The idea of linking end-user software versioning to the operating system version itself was always a dumb idea, but has become even more absurd over time. N…

It's called 'unstable' for a reason. New stuff breaks. Often.

This is the worst attitude to have about software

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

#64

Post by icebraining »

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…

> 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.

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

#65

Post by binarycrusader »

sanbor wrote: post #60
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…

Thank you for enumerating those downsides. Clearly I'd avoid statically linked software if I would have the option to use `apt-get install` to get that software. But in the situation that a new version of the software is released, and I think it would benefit me right now, I'd trade all those downsides for being able to use that software right now than waiting to be included in my distro (like it happened to me with…

But in the situation that a new version of the software is released, and I think it would benefit me right now, I'd trade all those downsides for being able to use that software right now than waiting to be included in my distro (like it happened to me with Gimp some years ago).

I don't understand what static linking vs. dynamic linking has to do with waiting for gimp to be included in your distro?

I'm plenty of memory, storage and bandwidth but not so much of time to compile it by hand.

No one is suggesting you have to do that, but someone will have to do that, and it does require resources (time, people, hardware, etc.).

I have to admit that this is just a workaround while we find a better software release and dependency management system.

If by system, you're referring to technology, then I disagree.

In other words, the technological constraints of today's package management systems are not the primary issue, rather it is how the software itself is being developed and managed and the available resources to do so.

Ultimately though, most of this all comes about because the underlying systems that applications depend upon in a typical Linux distribution are not properly release engineered. They don't properly version the shared libraries, they don't carefully avoid incompatible changes in interfaces, and they don't have sufficient regression testing.

So to me, the right answer is to fix the root of the problem, not paper over it by pretending there isn't one by essentially embedding copies of every dependency into an application.

In short, start encouraging developers to reduce their dependency chains, properly release manage their software, ensure that core system components offer stable interfaces, and provide timely updates.

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

#67

Post by rkeene2 »

haddr wrote: post #34
sanbor wrote: post #30

Earlier quoted context omitted.

Maybe distros like Debian are more stability/security oriented than feature oriented. New version of software often contain new features that it may introduce new bugs. Debian guarantees that when you install their distro things are going to work and are kind of secure. The tradeoff of having all the software in the distro being checked by people that have tested and checked that everything works well and smooth it's…

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…

AppFS ( http://appfs.rkeene.org/ ) aims to solve the packaging problem in a way that is very similar to this line of thinking.

Software is just files on disk, rather than statically linking (and this duplicating) to libraries we can use references to the libraries (dynamic linking), the issue is the user has to install the software and its dependencies then.

AppFS solves this by not having an install step. All files in all AppFS packages in all the world show up in the filesystem if you look for them. They are then cached to disk if you try to use them.

So if you had a package X that depended on library Y you simply run the binary you want from X and any libraries from Y will get used.

Since AppFS is a global namespace using HTTP, it has very similar semantics to the WWW, just with symlinks or ELF NEEDED entries instead of hyperlinks.

So you, as a developer can publish software that depends on the software another developer publishes, and the user can fetch the software directly from you without there ever being an install step.

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

#68

Post by cyphax »

jhkaghjkga wrote: post #48

And at least OpenSuSE and Slackware just patched the warning out already -- probably after getting hit by it in the past. See for example the patch in Slackware: https://slackbuilds.org/mirror/slackware/slackware-current/s...

Oh wow, I didn't expect that from Slackware... I hadn't noticed that the message is gone, I guess. I can't help but to think it is kind of rude to keep using xscreensaver but not honor the request of its author. It's purely the principle of the thing because I agree that the message is ugly. That's not in true Slackware spirit imho (in the sense that this is a less-than-necessary patch). I am a little bit disappointed. :(

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

#69

Post by gens »

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…

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 people never understand static linking ?

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

#70

Post by digi_owl »

castratikron wrote: post #19
tinco wrote: post #15

Earlier quoted context omitted.

... to another distro that actually ships up to date software?

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

If distrowatch can be trusted, they have so as of 15.4...
Post reply on HN