10 ms·

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

84 points by ashitlerferad 11y ago

digi_owl 11y ago
Heh, looks like its another popcorn moment. BTW: i guess this is an argument for having feature release and bugfix only releases. Or at the very lease make it easy for distros to backport bugfixes (though i guess most will argue to give distros the middle finger and pull everything from git or equivalent).
- odinduty 11y ago
  > For the record, the timebomb for 5.34 will go off on 2017-04-01, ie, shortly after stretch's expected release date. Debian always providing with fun...
deleted 11y ago
[deleted]
bithush 11y ago
Google Cache as the Debian tracker is getting hit hard https://webcache.googleusercontent.com/search?q=cache:UoVCY4x_2HMJ:https://bugs.debian.org/cgi-bin/bugreport.cgi%3Fbug%3D819703#84+&cd=1&hl=en&ct=clnk&gl=uk https://webcache.googleusercontent.com/search?q=cache:UoVCY4... Original link is to post #84 in the conversation.
deleted 11y ago
[deleted]
kuschku 11y ago
I’ve seen similar issues with several (!) Debian packages again and again. Upstream has fixed lots of bugs, critical crashes, and CVEs, and Debian stable takes weeks or months to backport them, and even then only the CVEs. Not even fixing major usability bugs. I’ve seen users on versions so old where nothing is able it interoperate with them anymore, and the users unable to compile from source themselves. Currently, the solution I’ve seen from several such upstream sources was to offer a ppa or custom apt repository, and to let users install that. The usability of debian – especially stable and oldstable – is severely hurt by maintainers not backporting these things, and it adds a lot of work for upstream. Especially for fast moving things – like compilers, programming languages, networking software – this is a severe issue, and Debian is just ignoring it away, and patching the warnings upstream might have added away as well. ________________________ If Debian wishes to remove the warnings from Upstream, they should actually backport all bugfixes themselves – as they claim they do. ________________________ Btw, I won’t be able to answer to comments on this for another hour, as I’ve exhausted my hourly limit on HN comments – as always.
- Elhana 11y ago
  Here is another example: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=811273 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=811273 https://bugs.launchpad.net/ubuntu/+source/nethogs/+bug/1543303 https://bugs.launchpad.net/ubuntu/+source/nethogs/+bug/15433... It doesn't work at all and bug is fixed upstream, but fix only goes to unstable.
- ashitlerferad 11y ago
  If you want a specific bug fixed in stable, there are avenues to doing that: https://www.debian.org/doc/manuals/developers-reference/pkgs.html#upload-stable https://www.debian.org/doc/manuals/developers-reference/pkgs...
hartator 11y ago
Cached: https://webcache.googleusercontent.com/search?q=cache:UoVCY4x_2HMJ:https://bugs.debian.org/cgi-bin/bugreport.cgi%3Fbug%3D819703+&cd=1&hl=en&ct=clnk&gl=us https://webcache.googleusercontent.com/search?q=cache:UoVCY4...
captainmuon 11y ago
After skimming the thread, I'm tempted to say: tell jwz "tough luck" and keep xscreensaver, with the message patched out, just out of spite. After all, he put it under a permissive license, so he should not be surprised that people actually use that license to do whatever they want.
- sp332 11y ago
  He admits as much in the post, so you don't really have any cause for spite. Respecting his request would improve everyone's experience.
  - deleted 11y ago
    [deleted]
  - ashitlerferad 11y ago
    Respecting his request would mean removing xscreensaver which would be bad for users.
    - sp332 11y ago
      I don't see why a package maintainer would patch out the warning instead of just packaging the new version. But if it comes to that, it's better for the users to get xscreensaver from a more reliable source than that maintainer.
johnchristopher 11y ago
I can't find it on his website at the moment but he has an excellent explanation of why gnome-screensaver is inherently insecure. If I remember correctly it boils down to something like: `nobody can guarantee that gnome-screensaver is secure because it relies on GTK which nobody can prove or guarantee that it's 100% secure because there's too much code to check.`. edit: found it: I am as close to certain as I can be that there is no action a user can take on their input devices that will cause the current Xlib-based lock dialog in xscreensaver to unlock. That's because it's a small amount of code that I have stared at and tested for a very long time. It is a small enough piece of code that I (believe I) know every possible path through it. Introduce N layers of widget library, general text field handling, compose processing, input methods, I18N... and all bets are off. Who knows what bugs wait lurking in there; who knows which particular combinations of which libraries are a security-bug timebomb. Let me put that another way: The GTK and GNOME libraries have never been security-audited to the extent that their maintainers would be willing to make the claim, "under no circumstances will this library ever crash." One can, within a reasonable doubt, make that claim about libc, or even about Xlib, but not about anything the size of GTK. It's just too big to be sure. This is not a criticism of GTK or GNOME or their authors: it's simply a truth about any piece of software of that size.
- digi_owl 11y ago
  Then again he got egg on his face recently because the xscreensaver lock screen would crash if the display output was switched (or some such).
  - odinduty 11y ago
    Was that a security issue or just a crash?
    - digi_owl 11y ago
      It would lead to the screen becoming unlocked, iirc. Edit: Just to add a bit more detail. xscreensaver locks the screen by putting a window across it that grabs ownership of input devices. Thus if it crashes, the window goes away and the inputs released.
castratikron 11y ago
Huh. Ran into this behavior yesterday, coincidentally. I also think there's another bug with xscreensaver where it will capture and "hang on" to your keyboard after you've unlocked the machine. Maybe it's time to switch...
- tinco 11y ago
  ... to another distro that actually ships up to date software?
  - castratikron 11y ago
    Not a chance! Debian is the only sane Linux distro. Xubuntu would by alright if they ever decide to switch to systemd.
    - tinco 11y ago
      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 using OS'es that are not the future?.
      - digi_owl 11y ago
        Keep in mind that Ubuntu and offshots are based on Debian Unstable, not Stable. And the problem that the bugreport is about is that Stable would not get bugfix updates, resulting in JWZ getting emails for long fixed bugs. Thus he put in the "obsolete version" warning to get Stable users to pester Debian maintainers.
      - ferrari8608 11y ago
        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).
protomyth 11y ago
I'm more on the BSD-side, so can someone give an explanation on why bug fixes are not being back ported? I understand long term stable, but I thought that was more an API thing.
- wazoox 11y ago
  The Debian policy states that all software in stable stay at the same version, with patches backported from upstream. I'm not sure it really makes sense as a general policy; at least I'm pretty sure there could be exceptions for some packages with little dependancies, such as xscreensaver. Slackware 14.0 which is way older than Jessie and even older than Wheezy, comes with the latest, 5.34 xscreensaver in its update stream.
- _delirium 11y ago
  There's no policy against backporting bugfixes, it just doesn't always happen due to lack of developers. If upstream doesn't provide backported bugfixes, it requires someone else to volunteer the time/resources to do it. For some packages, companies sponsor long-term maintenance branches, or particularly interested volunteers take it upon themselves to do it. For other packages, nobody steps up to do the work, so it doesn't happen. I've found BSD ports pretty similar (mainly pkgsrc is the one I use). Some are very actively maintained, and others are much less actively maintained. Resources are limited, so pkgsrc maintenance happens only to the extent that someone makes it happen.
  - protomyth 11y ago
    Oh yeah, depending on which one, its a bit slow on the BSD side also. I was just looking at why you wouldn't back port bug fixes as a matter of policy, but I'll take your comment as truth although it seems the conversation in the thread is a bit odd on that point. Thanks.
sanbor 11y ago
Here in Argentina it's common to find people that works dealing with customers or in the street that are very rude and kind of sociopaths. For what I have read in threads like this one, software developers that have to deal with many users/developers like Linus Torvalds, Theo de Raadt, and Jamie Zawinski end up suffering the same symptom.
- digi_owl 11y ago
  It is also a classic help desk issue.
jarcane 11y ago
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. No other operating system but Linux (and possibly some BSDs) does this to the extent that the distro model does. I'm not limited to awkward work-around manual install methods just because the version of Notepad++ linked to Windows 8.1 hasn't been updated since it was released. The whole scenario is absurd. Yes, package repos are nice, but not when it means I'm perpetually multiple versions behind on common software just because a handful of nerds are trying to do the job of Github and Sourceforge combined, instead of just building an easier method of installing and updating third-party software.
- sanbor 11y ago
  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 going delay updating the packages. But the idea of having a distro it's something that offers you that. That someone took the work of packaging and testing, so you can install things and everything works. I think that if more software would be offered statically compiled with all the libraries (like many apps in OSX), then we would be able to try the latest release of Gimp when it's released, instead of having to waste time trying to compile from source or waiting for being included in the next release of the distro.
  - haddr 11y ago
    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 saved.
bpchaps 11y ago
Man, it's really weird to see this after just installing Debian after using arch for about a year. And sure enough, that message popped up, I tried to update it and the repos were outdated. Brother.. My worst experience with their repos was with logstash having a bug where it would annoyingly install logstash-web with an auto-start. But..... the package had a typo in its startup script and caused the JVM to restart over and over and over. This was at an HFT shop, so sure enough.. I got a call the next morning that all trading was stopped until it was fixed. I don't understand how these sorts of things issues happen for so long on such a popular distro... *arch is nice and all, but holy crap does AUR need some better standards with what's acceptable. After spending an asinine amount of time trying to figure out why every 5th package won't build where devs closing bug reports with, "Did you try $BASICTROUBLESHOOTING".. I'm pretty much done.
- maxerickson 11y ago
  I've only been using Arch for a few months, but my mental model of AUR is that I shouldn't expect anything to work. (this isn't out of frustration, I read early on that it was for sharing preliminary packages and discarded all expectations)
- dfc 11y ago
  Debian does not have a logstash or logstash-web package. When complaining about "their repos" did you mean elastic.co's repos?
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.
cstrahan 11y ago
I would recommend looking at NixOS. We're not perfect either, but we generally do a much better job at keeping our shit up to date: https://github.com/NixOS/nixpkgs/blob/master/pkgs/misc/screensavers/xscreensaver/default.nix https://github.com/NixOS/nixpkgs/blob/master/pkgs/misc/scree... If there's something you need that's outdated, a fix is as trivial as opening an issue on GitHub, or sending a Pull Request with the revision and SHA256 bumped.
jhkaghjkga 11y ago
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/source/xap/xscreensaver/xscreensaver.no.expiration.date.diff.gz https://slackbuilds.org/mirror/slackware/slackware-current/s...
- cyphax 11y ago
  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. :(
  - morb 11y ago
    Yes, the nag text was removed, but at least xscreensaver gets updates, which was the whole point. > patches/packages/xscreensaver-5.34-i486-1_slack14.1.txz: Upgraded. I promised jwz that I'd keep this updated in -stable when I removed (against his wishes) the nag screen that complains if a year has passed since that version was released. So, here's the latest one. Personally I don't get the point of screesavers at all, since we have monitors that can be sent sleep/standby mode when they're not used.
    - basch 11y ago
      it is a lock screen that prompts for password on wake https://www.jwz.org/xscreensaver/toolkits.html https://www.jwz.org/xscreensaver/toolkits.html
B1FF_PSUVM 11y ago
The current version of Zawinski is very old.
deleted 11y ago
[deleted]
ashitlerferad 11y ago
Another response to this issue: https://mjg59.dreamwidth.org/41085.html https://mjg59.dreamwidth.org/41085.html
hackerb9 11y ago
This is a good example of why I do use Debian. Debian has never had the goal of being the latest shiny thing on the block. And that's why people people keep coming back to it. Sure, over the years I've dabbled with RedHat, Ubuntu, Mint, and so on, but then repeatedly I rediscover, that, oh yeah, security and stability actually matter. Debian Stable cuts the right balance for me by incorporating the latest security patches but not the latest features/bugs. This is a heck of a lot more work for the Debian maintainers than simply rubber stamping whatever the upstream software developers release, but it's proven worth it. My only disappointment in Debian here is that they didn't catch this time bomb and disarm it preemptively.
daveloyall 11y ago
I'm glad I read the bug discussion before this discussion. 1. jwz is sorta famous and cool, I think. I've heard of him before this (and I'm not exactly hip!). 2. Debian is well known, too! /understatement 3. jwz put a timebomb in xscreensaver. 4. The timebomb displays a message if current date > source code date + 18 months. 5. The timebomb has been there for at least three years. See https://github.com/Zygo/xscreensaver/blame/88cfe534a698a0562e81345957a50714af1453bc/driver/prefs.c#L1663 https://github.com/Zygo/xscreensaver/blame/88cfe534a698a0562... (Unofficial repo) 6. I'm with Debian on this one. Sorry, jwz. 7. I really, really, really like xscreensavers and want it to stay in Debian! :(

84 points by ashitlerferad 11y ago

Heh, looks like its another popcorn moment. BTW: i guess this is an argument for having feature release and bugfix only releases. Or at the very lease make it easy for distros to backport bugfixes (though i guess most will argue to give distros the middle finger and pull everything from git or equivalent).

odinduty 11y ago
> For the record, the timebomb for 5.34 will go off on 2017-04-01, ie, shortly after stretch's expected release date. Debian always providing with fun...

deleted 11y ago

[deleted]

bithush 11y ago

Google Cache as the Debian tracker is getting hit hard https://webcache.googleusercontent.com/search?q=cache:UoVCY4x_2HMJ:https://bugs.debian.org/cgi-bin/bugreport.cgi%3Fbug%3D819703#84+&cd=1&hl=en&ct=clnk&gl=uk https://webcache.googleusercontent.com/search?q=cache:UoVCY4... Original link is to post #84 in the conversation.

deleted 11y ago

[deleted]

kuschku 11y ago

I’ve seen similar issues with several (!) Debian packages again and again. Upstream has fixed lots of bugs, critical crashes, and CVEs, and Debian stable takes weeks or months to backport them, and even then only the CVEs. Not even fixing major usability bugs. I’ve seen users on versions so old where nothing is able it interoperate with them anymore, and the users unable to compile from source themselves. Currently, the solution I’ve seen from several such upstream sources was to offer a ppa or custom apt repository, and to let users install that. The usability of debian – especially stable and oldstable – is severely hurt by maintainers not backporting these things, and it adds a lot of work for upstream. Especially for fast moving things – like compilers, programming languages, networking software – this is a severe issue, and Debian is just ignoring it away, and patching the warnings upstream might have added away as well. ________________________ If Debian wishes to remove the warnings from Upstream, they should actually backport all bugfixes themselves – as they claim they do. ________________________ Btw, I won’t be able to answer to comments on this for another hour, as I’ve exhausted my hourly limit on HN comments – as always.

Elhana 11y ago
Here is another example: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=811273 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=811273 https://bugs.launchpad.net/ubuntu/+source/nethogs/+bug/1543303 https://bugs.launchpad.net/ubuntu/+source/nethogs/+bug/15433... It doesn't work at all and bug is fixed upstream, but fix only goes to unstable.
ashitlerferad 11y ago
If you want a specific bug fixed in stable, there are avenues to doing that: https://www.debian.org/doc/manuals/developers-reference/pkgs.html#upload-stable https://www.debian.org/doc/manuals/developers-reference/pkgs...

hartator 11y ago

Cached: https://webcache.googleusercontent.com/search?q=cache:UoVCY4x_2HMJ:https://bugs.debian.org/cgi-bin/bugreport.cgi%3Fbug%3D819703+&cd=1&hl=en&ct=clnk&gl=us https://webcache.googleusercontent.com/search?q=cache:UoVCY4...

captainmuon 11y ago

After skimming the thread, I'm tempted to say: tell jwz "tough luck" and keep xscreensaver, with the message patched out, just out of spite. After all, he put it under a permissive license, so he should not be surprised that people actually use that license to do whatever they want.

sp332 11y ago
He admits as much in the post, so you don't really have any cause for spite. Respecting his request would improve everyone's experience.
- deleted 11y ago
  [deleted]
- ashitlerferad 11y ago
  Respecting his request would mean removing xscreensaver which would be bad for users.
  - sp332 11y ago
    I don't see why a package maintainer would patch out the warning instead of just packaging the new version. But if it comes to that, it's better for the users to get xscreensaver from a more reliable source than that maintainer.

johnchristopher 11y ago

I can't find it on his website at the moment but he has an excellent explanation of why gnome-screensaver is inherently insecure. If I remember correctly it boils down to something like: `nobody can guarantee that gnome-screensaver is secure because it relies on GTK which nobody can prove or guarantee that it's 100% secure because there's too much code to check.`. edit: found it: I am as close to certain as I can be that there is no action a user can take on their input devices that will cause the current Xlib-based lock dialog in xscreensaver to unlock. That's because it's a small amount of code that I have stared at and tested for a very long time. It is a small enough piece of code that I (believe I) know every possible path through it. Introduce N layers of widget library, general text field handling, compose processing, input methods, I18N... and all bets are off. Who knows what bugs wait lurking in there; who knows which particular combinations of which libraries are a security-bug timebomb. Let me put that another way: The GTK and GNOME libraries have never been security-audited to the extent that their maintainers would be willing to make the claim, "under no circumstances will this library ever crash." One can, within a reasonable doubt, make that claim about libc, or even about Xlib, but not about anything the size of GTK. It's just too big to be sure. This is not a criticism of GTK or GNOME or their authors: it's simply a truth about any piece of software of that size.

digi_owl 11y ago
Then again he got egg on his face recently because the xscreensaver lock screen would crash if the display output was switched (or some such).
- odinduty 11y ago
  Was that a security issue or just a crash?
  - digi_owl 11y ago
    It would lead to the screen becoming unlocked, iirc. Edit: Just to add a bit more detail. xscreensaver locks the screen by putting a window across it that grabs ownership of input devices. Thus if it crashes, the window goes away and the inputs released.

castratikron 11y ago

Huh. Ran into this behavior yesterday, coincidentally. I also think there's another bug with xscreensaver where it will capture and "hang on" to your keyboard after you've unlocked the machine. Maybe it's time to switch...

tinco 11y ago
... to another distro that actually ships up to date software?
- castratikron 11y ago
  Not a chance! Debian is the only sane Linux distro. Xubuntu would by alright if they ever decide to switch to systemd.
  - tinco 11y ago
    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 using OS'es that are not the future?.
    - digi_owl 11y ago
      Keep in mind that Ubuntu and offshots are based on Debian Unstable, not Stable. And the problem that the bugreport is about is that Stable would not get bugfix updates, resulting in JWZ getting emails for long fixed bugs. Thus he put in the "obsolete version" warning to get Stable users to pester Debian maintainers.
    - ferrari8608 11y ago
      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).

protomyth 11y ago

I'm more on the BSD-side, so can someone give an explanation on why bug fixes are not being back ported? I understand long term stable, but I thought that was more an API thing.

wazoox 11y ago
The Debian policy states that all software in stable stay at the same version, with patches backported from upstream. I'm not sure it really makes sense as a general policy; at least I'm pretty sure there could be exceptions for some packages with little dependancies, such as xscreensaver. Slackware 14.0 which is way older than Jessie and even older than Wheezy, comes with the latest, 5.34 xscreensaver in its update stream.
_delirium 11y ago
There's no policy against backporting bugfixes, it just doesn't always happen due to lack of developers. If upstream doesn't provide backported bugfixes, it requires someone else to volunteer the time/resources to do it. For some packages, companies sponsor long-term maintenance branches, or particularly interested volunteers take it upon themselves to do it. For other packages, nobody steps up to do the work, so it doesn't happen. I've found BSD ports pretty similar (mainly pkgsrc is the one I use). Some are very actively maintained, and others are much less actively maintained. Resources are limited, so pkgsrc maintenance happens only to the extent that someone makes it happen.
- protomyth 11y ago
  Oh yeah, depending on which one, its a bit slow on the BSD side also. I was just looking at why you wouldn't back port bug fixes as a matter of policy, but I'll take your comment as truth although it seems the conversation in the thread is a bit odd on that point. Thanks.

sanbor 11y ago

Here in Argentina it's common to find people that works dealing with customers or in the street that are very rude and kind of sociopaths. For what I have read in threads like this one, software developers that have to deal with many users/developers like Linus Torvalds, Theo de Raadt, and Jamie Zawinski end up suffering the same symptom.

digi_owl 11y ago
It is also a classic help desk issue.

jarcane 11y ago

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. No other operating system but Linux (and possibly some BSDs) does this to the extent that the distro model does. I'm not limited to awkward work-around manual install methods just because the version of Notepad++ linked to Windows 8.1 hasn't been updated since it was released. The whole scenario is absurd. Yes, package repos are nice, but not when it means I'm perpetually multiple versions behind on common software just because a handful of nerds are trying to do the job of Github and Sourceforge combined, instead of just building an easier method of installing and updating third-party software.

sanbor 11y ago
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 going delay updating the packages. But the idea of having a distro it's something that offers you that. That someone took the work of packaging and testing, so you can install things and everything works. I think that if more software would be offered statically compiled with all the libraries (like many apps in OSX), then we would be able to try the latest release of Gimp when it's released, instead of having to waste time trying to compile from source or waiting for being included in the next release of the distro.
- haddr 11y ago
  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 saved.

bpchaps 11y ago

Man, it's really weird to see this after just installing Debian after using arch for about a year. And sure enough, that message popped up, I tried to update it and the repos were outdated. Brother.. My worst experience with their repos was with logstash having a bug where it would annoyingly install logstash-web with an auto-start. But..... the package had a typo in its startup script and caused the JVM to restart over and over and over. This was at an HFT shop, so sure enough.. I got a call the next morning that all trading was stopped until it was fixed. I don't understand how these sorts of things issues happen for so long on such a popular distro... *arch is nice and all, but holy crap does AUR need some better standards with what's acceptable. After spending an asinine amount of time trying to figure out why every 5th package won't build where devs closing bug reports with, "Did you try $BASICTROUBLESHOOTING".. I'm pretty much done.

maxerickson 11y ago
I've only been using Arch for a few months, but my mental model of AUR is that I shouldn't expect anything to work. (this isn't out of frustration, I read early on that it was for sharing preliminary packages and discarded all expectations)
dfc 11y ago
Debian does not have a logstash or logstash-web package. When complaining about "their repos" did you mean elastic.co's repos?

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.

cstrahan 11y ago

I would recommend looking at NixOS. We're not perfect either, but we generally do a much better job at keeping our shit up to date: https://github.com/NixOS/nixpkgs/blob/master/pkgs/misc/screensavers/xscreensaver/default.nix https://github.com/NixOS/nixpkgs/blob/master/pkgs/misc/scree... If there's something you need that's outdated, a fix is as trivial as opening an issue on GitHub, or sending a Pull Request with the revision and SHA256 bumped.

jhkaghjkga 11y ago

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/source/xap/xscreensaver/xscreensaver.no.expiration.date.diff.gz https://slackbuilds.org/mirror/slackware/slackware-current/s...

cyphax 11y ago
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. :(
- morb 11y ago
  Yes, the nag text was removed, but at least xscreensaver gets updates, which was the whole point. > patches/packages/xscreensaver-5.34-i486-1_slack14.1.txz: Upgraded. I promised jwz that I'd keep this updated in -stable when I removed (against his wishes) the nag screen that complains if a year has passed since that version was released. So, here's the latest one. Personally I don't get the point of screesavers at all, since we have monitors that can be sent sleep/standby mode when they're not used.
  - basch 11y ago
    it is a lock screen that prompts for password on wake https://www.jwz.org/xscreensaver/toolkits.html https://www.jwz.org/xscreensaver/toolkits.html

B1FF_PSUVM 11y ago

The current version of Zawinski is very old.

deleted 11y ago

[deleted]

ashitlerferad 11y ago

Another response to this issue: https://mjg59.dreamwidth.org/41085.html https://mjg59.dreamwidth.org/41085.html

hackerb9 11y ago

This is a good example of why I do use Debian. Debian has never had the goal of being the latest shiny thing on the block. And that's why people people keep coming back to it. Sure, over the years I've dabbled with RedHat, Ubuntu, Mint, and so on, but then repeatedly I rediscover, that, oh yeah, security and stability actually matter. Debian Stable cuts the right balance for me by incorporating the latest security patches but not the latest features/bugs. This is a heck of a lot more work for the Debian maintainers than simply rubber stamping whatever the upstream software developers release, but it's proven worth it. My only disappointment in Debian here is that they didn't catch this time bomb and disarm it preemptively.

daveloyall 11y ago

I'm glad I read the bug discussion before this discussion. 1. jwz is sorta famous and cool, I think. I've heard of him before this (and I'm not exactly hip!). 2. Debian is well known, too! /understatement 3. jwz put a timebomb in xscreensaver. 4. The timebomb displays a message if current date > source code date + 18 months. 5. The timebomb has been there for at least three years. See https://github.com/Zygo/xscreensaver/blame/88cfe534a698a0562e81345957a50714af1453bc/driver/prefs.c#L1663 https://github.com/Zygo/xscreensaver/blame/88cfe534a698a0562... (Unofficial repo) 6. I'm with Debian on this one. Sorry, jwz. 7. I really, really, really like xscreensavers and want it to stay in Debian! :(