Another response to this issue:
“This version of XScreenSaver is very old. Please upgrade”
101–105 of 105 posts
Re: “This version of XScreenSaver is very old. Please upgrade”
#102Earlier quoted context omitted.
> 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. You sure you are running the latest version? That is the origins of this message. That Debian (and perhaps other distros) would fail to push xscreensavers in a timely manner, resulting in JWZ getting emails about issues he had long since fixed. This seems to stem from a policy t…
> only security issues ... will be processed That isn't actually the policy, for example: https://www.debian.org/News/2016/20160402
> This update mainly adds corrections for security problems to the stable release, along with a few adjustments for serious problems.
Re: “This version of XScreenSaver is very old. Please upgrade”
#103This 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.
Re: “This version of XScreenSaver is very old. Please upgrade”
#104Earlier quoted context omitted.
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…
>Most OS linkers already do efficient loading of only the relevant portions of a shared library since they typically mmap the library file.
a page is 4kB (on x86 at least). a function is typically, what, 60 bytes ? 120 maybe ? 240 ? some functions use other functions (fopen()->_open() in libc) so you can have more then two pages
maybe you are thinking about swapping (or not even lazy loading in the block layer) ? code has to be in RAM, everything else is insecure
>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).
not pages, functions (and/or variable objects). when you make a .la on unices you are making a ar(1) archive out of .o object files. when the linker is linking the final binary it opens that .la archive and pulls out the relevant .o objects
so "statically linking to properly(!) made libraries" will reduce overall memory usage, unless a lot of programs use that (small) library (rarely the case)
OSX linker does the right thing with their libc. in that out of the many optimized memcpy()'s it will only load the one that is fast on the particular cpu
GNU linker loads them all
>Code is code; how is shared linking a greater risk? Have any data to back that up?
data to back it up ? do you have any data to back up anything you said ?
LD_PRELOAD can be used to replace functions and the user/admin would not notice it. while the only security flaw with static linking is an administrative mistake
>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.
so go ask them about it
Re: “This version of XScreenSaver is very old. Please upgrade”
#105I'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/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! :(