Really the message should say something like, "Warning: This version is out of date. Bug reports for out of date version will be ignored. Please advise your distro maintainer to update their packaged version." And when people do submit bug reports for older version, just auto closes them with a copy past message of, "This version is out of date. please update to latest, and resubmit if problem persists." Are people still going to have an issue with it? yes. but it gives the software maintainer a clean way to say not my problem, without getting into the shit chucking.
Yeah no, We're talking about Linux Users here. They'll bitch and belly-ache about their bug being auto closed, make new bug-reports without the information to auto-close it. Then five replies deep tell that it's a super out of date version, and get told off; marked and closed waist even more time and maybe maybe sulk off.
Auto-close is generally a garbage idea. I have had to keep reopening over a dozen of bug reports due to automatic closing because the bug report has not had any replies for a while but the issue is still in the very latest version of the thing. There has to be a check against version or something before auto-closing. Stalebot is one of the worst offenders to getting bugs fixed. I honestly hate it.
It's like getting food poisoning from food bought at your local supermarket, and in response demanding that they remove the "best before" date from the products they sell
It's like a stranger who gives you eggs, saying "These eggs are a gift- yours to do with as you please!" and then, once you make a birthday cake with their eggs, knocks on your door and generously allows you to decorate your cake however you want, provided it *also* says "THIS CAKE IS SEVEN YEARS OLD SO IT PROBABLY TASTES BAD. BTW SUPPORT YOUR LOCAL EGG VENDOR."
Some of the debian maintainers have suggested filing bugs upstream and I've always taken the stance that debian should manage the duplicate bugs in the upstream repo.
Arch, Gentoo, even PopOS users sometimes should be filing upstream as they're often on the latest versions but in the case of Debian, Ubuntu and others who are intentionally out of date, users should always be in the distro issue tracker and the distro maintainers should file upstream in cases where it's relevant
@@BrodieRobertson There is also the issue of when devs patch something they don't have any way to communicate how critical that patch is... When bugs are fixed it's only if there is a security issue that debian is informed, it would be better if bug fixes were flagged from distributors also.
haha its so funny. hey hey let's build all software from source LOL. haha so funny. look at me I am a neurotic zoomer LOL. building packages for no f ing reason is so nice YEAH! woohooo
"who understands that stable and ancient are not the same". I feel it so well. That's why I moved away from Debian(and ubuntu LTS). They shipped so old packages, I literally couldn't compile some stuff because important libraries(like SDL) were too old. I literally couldn't compile source code of programs because they were relying on functions from the "new" versions of libraries released several years ago but not shipped in the distro.
Exactly my experience. If you need software that's not included in the repo, Debian and its derivatives are an awful experience. My system quickly became a mess of PPAs and manually installed libraries. Much happier with Fedora.
@@Myname-l3h I don't remember exactly as it was years ago. Language was C, when looking for the solutions I've found that VVVVVV also had the issue with old SDL in ubuntu. Other was related to FOSS FPGA tools, most like one of symbiyosys dependencies(it can use a lot of tools). I remember it not just failed compilation, README specifically mentioned that some system lib is too old
@@orbatos It's not upstream's responsibility to deal with 18 month old long-fixed bugs. Debian is dry and dusty old shit unless you're running Debian Sid, but at that point just run Arch, it's easier to deal with, and pacman is more robust than apt anyways.
@@orangejuche Good way to show you don't know what your talking about and didn't read what I posted. Nobody is saying devs are responsible for old version indefinitely. Upstream responsibility doesn't include slipping in fake error messages, but it does include either maintaining packages or talking to maintainers to ensure issues like this don't happen. Maintainers are not representative of an entire distro or even repository as they tend to only maintain a limited portion of the package pool. If they are out of date, or there is a bug they should be the ones reported to, but devs often discourage this interaction, then complain that older packages still exist, despite dependency issues.
@@orbatos Did debian maintainers backport fixes or reach out for author to help with backporting? I guess no. And it's not really author's job to reach out for every distro maintainer neither to help with backporting. Especially unpaid.
This is an absolute classic. See also the war between deb-multimedia and debian where it got so petty that devs tried using higher version numbers to stop users from switching away from their outdated libraries (users caught on and just pinned deb-multimedia higher). This was a situation where someone actually did provide an alternative update. And then there's the whole cdrecord debacle...
This is one of the main reasons why I'm glad that Flatpak exists: it makes these kind of complaints occur less often (at least for "normal" desktop apps, though maybe not for lock-screen apps like this one). If you're running Debian Stable or some other non-rolling-release distro, and you want to run the current version of a certain desktop app, then Flatpak makes it fairly easy to do that *even if* the distro ships an outdated version of that app or doesn't ship it at all.
Since this is such a common issue, a better bug reporting system would be a good idea. Something to make it so that you have to select your distro from a list, or type in the software version you have installed. Then, when you select something like debian or type in an out of date version it automatically notifies you that your software is out of date and rejects the report. Basically, just idiot proof the bug tracker.
@@snowwsquire Hence, we need a standardized portal to submit bugs - a program which automatically fills in the version number of the software and the OS brand and version, along with any necessary dependency versions, and sends the report to a specified tracker with any additional details as inputted by the user where the maintainer, if they choose, can automate rejection based on the version being out of date. This wouldn't help for old software which doesn't already support this reporting feature, but it would for any new software. This would ensure the details of the problem are sent in full without obfuscation by the user in a way that can be reliably and repeatedly parsed.
hm.. that kind of creates the problem of what do you do with the idiots that find a way to break the idiot-proof bug tracker? who is bug-tracking the newly bugged bug-tracker? How can one out idiot the idiots?! It's never ending I tell you! 🤣
2:10 The bottles problem isn't just an out-of-date package in Fedora (that could have been fixed by packaging a newer version). The core issue is that bottles requires newer libraries than what all the other Fedora packages used. This is a major pain point for traditional distros. The proper solution is to let different apps use different versions of various libraries. Either via static linking, via namespaces (Flatpak) or by using to the Nix model (different builds live in different prefixes - you don't put everything into /usr).
If I was maintaining a project like this I would put a "This package is out-of-date. Complain about it here:" and then just post the problematic distros issue tracker there.
@@yozul1 I think it's not worth it, just have distributions patch in their URL. If you want to make it easy for downstreams, add a configure option which allows the bug tracker URL to be set by packagers at compile time. Edit: on a second thought, not even that is needed. All credible distributions report a "BUG_REPORT_URL" and "SUPPORT_URL" in their /etc/os-release, which applications could reference.
Sometimes, you actually *need* outdated stuff. For example, I do my job work with a software written in Java, which has gconf as an implicit dependency. If it's not installed, the software will hang on start. However, this package is so outdated, it was even removed from mainline Gnome. Edit: And yeah, I think it even needs xscreensaver.
It would be a whole lot simpler to add a check box that tells xscreensaver to not show the popup again. Like almost every software out there that has a pop up for whatever reason...
If I find a bug, I assume it's something I broke and then start to look for a solution. I think I've only every filed a single report, and that was after checking on the forums (CentOS 6 or 7) and the local gurus said to post a bug report. That said, I'm a barely functioning Linux user, so finding real bugs that I didn't cause are rare for me.
Oh I know this one. Xscreensaver included a time bomb. You could be using the latest upstream release, but if it was more than 60 days (checked the source) since an epoch included in the compilation it would complain, ie. if you compiled it from source it would complain _too_, even if there isn't a new upstream available, like it happened with 6.06 released 2022-12-11 with 6.07 released 2023-08-29. Yes, the warning would appear even if you are on the latest version (!). Other software's actually check if there's a newest version and print a reminder like Legendary which checks their API (they deliver configuration fixes that way too) to inform the update is available. You can disable this too!
Using an API call to check for the latest version of the package behind user's back is even worse as it introduces another moving part that can be potentially exploited in an out-of-date package.
This was a problem for some developers of emulators, who did not want an old version of the emulator core distributed in RetroArch. That's the reason why Swanstation existed as an alternative to Duckstation or still LRPS2 as a renamed and fork of PCSX2. There was literally toxic fights and comments all over the place. But rebranding is a way to handle this. But updating the RetroArch cores is very complex and involved and not like a simple package update on a distribution. So its understandable they rebranded an older version instead updating it (non trivial task). So my suggestion to all those distributions is then (if they don't want to update to newest version), to rebrand and fork as a new project and maintain that one.
Yeah that's immediately what came to mind when i watched this. Like just make a fork and rename it and then *you* maintain it. Maybe other projects that want to use an older version can just use that fork instead, with how infrequent i would imagine the updates would be.
In fairness, there's a LOT of reasons for RetroArch drama. Most of them, whatever the surface-level explanation, can be traced back to "the project lead is abrasive, manipulative, and just kind of an asshole".
@@CptJistuce I don't agree, but that's not the point here. I was specifically talking about the versioning of older versions. Or for any other reason the developer and package maintainer could not agree. Rebranding and forking the project is a way to solve it for both sides. Regardless of the the reason.
That's why many projects (including mine LOL) will require you to specify the version of the software you're running at the very top of the report with a big warning that if it's not the latest one the bug will be automatically closed. This is IMO the best solution, users can still report bugs upstream but they will have to test it on the latest stable and/or dev version before reporting.
Latest stable would be good, not necessarily the very latest version. And if you use Stalebot or similar tool to autoclose an issue only because it hasn't had any new replies for a while, then your not doing things right. I have had to reopen dozens of issues that were still present in the latest versions of various things simply because the bot is effectively hiding old but still present issues.
@@TheExileFox on one side, I agree with not closing issues if they are relevant, but the question is, are they really relevant? If a single user reports something very specific to his use case and it hasn't been fixed for years then most likely even the original person reporting is no longer interested because they probably found an alternative in the meantime. You can always just reply with "still relevant" and the issue will re-open and also let maintainers know that there is at least one person actually waiting for this. It gets rid of all of the fluff and lets devs focus on the things that are actually relevant. Also a note about the dev/latest stable thing. I won't ever require a dev version test, but if somebody is going to compile one themselves it doesn't really matter if they grab a stable tar ball or one from master. I would simply prefer the one from master if possible, not require.
@@nezu_cc That's not for a bot to decide. Yes, a fringe report can be closed or archived and marked as wontfix, stale, feedbackRequired, etc. or whatever, but doing so automatically just because no one has replied for some time is simply disrespectful. You shouldn't have a public issue tracker if you don't want people reporting their issues.
Just change the warning message "Warning: This version is out of date. Ask your Distro to update the package " and then point that link to the Distro so Users are more likely to report bugs there instead of upstream. A more sinister version would send the bug reports to /dev/null for all out of date version. Or maybe have a bug tracker tat ask for the installed version first, and asks you to upgrade.
Or what if the user ignores the message because it doesn't impede functionality. That's the point I've gotten to. I'd always run into issues where everybody tells me to do something different; use official packages so you don't break debian, compile from source because your distro is stupid, etc... I'm tired of it. I use stock themes and default settings nowadays. No more frivolous tinkering. If it works, let it work. Suppressing the OCD is the only cure. No more headaches.
I vividly remember this situation and the chaos it caused at the company I worked for. Suddenly this message was showing on screens of CUSTOMERS' media players. It caused panic among the execs and had me sweating bullets until I found this bug report. This is a great example of how FOSS developers can sometimes get too wrapped up in how a situation affects them and forget about the ripple effect their decisions can have.
When I encounter a bug, I usually check if in the changelogs between my version and the most recent upstream version is a related bugfix mentioned. If not, I report upstream. If yes, I don't report at all.
In the specific case of xscreensaver good luck figuring out what "minor bug fixes" means. Yes, it has a minor bug fixes entry. Also, you can't check easily a diff between versions. Upstream doesn't have a patch repository, so you have to figure out which of all those changes probably affected your issue.
I mean like I don't want a huge TEXT telling me I'm out of date when I unlock my system. It should probably be somewhere else. Also yes I get that the massively out-of-date distros that think just because Enterprise wants Ancient software means everyone should have Ancient software, will tell us use our bug-reporting trackers. They just don't understand that most users go well I don't have a Distro bug, I have a Software bug; so I much report it to the Software's Bug-Tracker.
Extra annoying when the software makes it hard to find out what version you are running. If you can easily find the version information: you may get a clue how out of date it is, if you find the upstream website instead of your distro's website.
I’m with Brodie here: This is acceptable if the application has been abandoned or is in maintenance mode. But I would add a clause here: Only if it is a business application that is responsible for a large amount of the income of said business.
Debian backports security fixes and the idea of a stable distribution, like Debian is that the packages are extensively tested before release. Since testing takes time, the release always contains old versions, however, those old version are more likely to be stable. Once software is released, it is used and tested by a lot of people who discover and report bugs, the devs fix them (hopefully). I want to run the old version with its bugs fixed and not the latest version with new features and new undiscovered bugs.
If they update the package to remove the nag, they should rename the package as it no longer functions as the developer intended. eg. call it XDebianSaver - so XScreenSaver isn't mentioned, and Debian gets all the reported bugs.
Debian on a server: Really stable, hassle-free, long lifecycle. Debian on a workstation: WTF are you doing, Linux 3-5 years ago is a terrible UX. My first experience with Linux was, as for many, Ubuntu (aka Debian unstable) LTS. It sounded like the right choice, but it sucked. Everything you interact with was extremely out of date and buggy. After a while my system was a broken mess of PPAs, because I needed newer versions of so many tools. I don't want to deal with rolling release breakages, but one step behind (Fedora) has been really good so far.
Not really. Older system doesn't mean that UX is terrible, it is just not changed for while. Changes how things works causes a lot of time wasting so it is better that there is no changes. It also affects solving issues because there is documentation on web how things are solved on some OS release.
@@gruntaxeman3740 even current day Linux hardly works for your average PC user. Rolling back 3+ years worth of bug fixes, features, and usability improvements does _not_ help with that. If a problem is common enough that information on how to work around it is readily available, it's probably already been fixed upstream. LTS works for servers, because they have a well-defined scope of tasks, and all the important bits (like the kernel, openssl, ...) update slowly and provide LTS branches that _are_ pulled in by distros.
@@jfolz Most of the features were good 17+ years ago for average PC user when using Ubuntu in desktop computer. Windows XP was also good enough something like 20 years ago for average PC user except maintenance was hard. Laptop and 3D-acceleration however was good enough in Ubuntu about 15 years ago and maintenance issues in Windows gradually disappeared soon after that. There was not much hazzle in Windows 7 when browser was able to show PDF files and Flash player was kicked off, and browser updates went more simple. Software quality is steadily improved about everywhere. Software is not really that buggy or feature limited. People are still using Windows 7, that is something like 14 year old LTS. Also for problem solving, LTS releases are good because when about every one is using same releases, there is a lot of knowledge how things are handled. Also it is very nice for average PC user when features are not changing twice a year, especially if using something else than browser.
Usually I go to the upstream big tracker. But knowing that I use a stable distro, I check completed/closed bug reports for my problem as I'm usually not running the bleeding edge version of software (and if I am then it's because I installed that software specifically and I'm usually following the development of it via email notifications). If there is a fix for my bug than I try updating the software. Very rarely do I feel the need to actually file an upstream report, and once I've even filed a distro specific bug on the distro bug tracker.
For true scorch earth I would adjust the way the message is done, so that there upstream patch no longer works (and also should make it obnoxious to remove). Although then again, it would take 1.5years at minimum, more likely 4, for this trap to snap, and upstream maintainers to be confused why this problem is back
I *love* that Debian Stable gives me 3 years at a time. I build my own 'ubdist' dist/OS in the cloud, Debian Stable with just a very few Nix packages, because all my many programs, WSL supporting scripts, LiveISO/BIOS/UEFI, etc, all will require as little maintenance as possible for 3 years. I do an automatic analysis of what binaries, kernel modules, etc, are installed in each cloud build, and it rarely if ever changes at all. When it does, so far it's something minor. So I can focus on usability, security, and out-of-box usability of the LiveISO.
Pretending to be nice is mostly a problem when the developer can't take anymore user stupidity and snaps. There's only so many incoherent bug reports demanding fixes a developer can take while biting their tongue.
Some people complain Sourcehut's email patchset and mailing list issues discourage contributions. Now I'm thinking this might have been by design. Maybe for some projects, getting one competent patch/issue in years seems better than tens of barely coherent ones.
It's the expectation of some corporate/large project users - a) to think in not 2 but 10+ year timeframes (there is a market for 10 years LTS distros as you know), b) that the distro exactly protect users from "developers wishes" (one could interpret it the way - not entirely wrongly even - that these users expect the distro to do the work of fing over the developer and putting them in their place for them). Often comes from project structures where software choice is at the beginning of a multi year effort, and there is the expectation that software is chosen, tested, specified and frozen right at the start. 2 years could be just a temporary funding gap, after which everyone expects to be able to pick up just where they left. In that world there is a mindset of "ideally, k*ll the developer as soon as they are finished, certainly keep their runny noses far away from it now adults are running it". So... alright, they don't want Gordon Ramsay running a mess hall. Now the simple and very open source friendly solution to this situation just wasn't mentioned anywhere - since what the distro is doing is creating a fork, *call it a fork*, name it xscreensaver-debian or something, and that way make it clear that the package is the distro maintainers responsibility, not that of the upstream author. (to make it clear, jwz is someone I highly respect, though I suspect I would get suggestions to use that sanctimony in interesting ways for stating that in that discussion :) ).
Tbh it depends how annoying is this message (if I am not wrong you didn't showed it in the video). If it is small annotation or better: can be disabled by clicking that you really read the message then it is ok. But if there are people who for some reason are running old version and know that, then I don't think that you should annoy them by big splash screen every time (agin: I don't know how this message was displayed in this application).
I've switched from Arch to Debian stable like a year ago and I am happy with it. I did have to compile a few packages when I needed a newer version, but this was like 4 or 5 packages in a year. For me that's an acceptable tradeoff when I know I can turn on the computer and it'll always be working and stay out of my way to focus on doing things. But I do stay away from packages that are changing too much and that's fine for me. For example I am using Sway instead of Hyprland. I'll use Hyprland when it becomes a bit more stable, because I could't be bothered with things changing every week.
Qubes-OS really is a special case, since it is actually catered towards security and stability over usability. As a Qubes user I will always first check if an issue is caused by Qubes instead of the software, since I know that the system packages are very old. That is different for other distributions. Unfortunately, Qubes also does not support Ubuntu, so I'm actually kind of stuck with Debian for the application VMs as well. Those are newer than the system distribution, but it's still Debian...
@@JessicaFEREM that is not an issue in Qubes, since the host system is completely isolated. It has no access to internet and no userdata is handled there. Also, critical security issues are fixed even in older distributions.
@@tlpthxit's still an issue because there are some bugs that can be exploited through physical access, for example I remember a bug in Linux mint I believe, where you could unlock the computer by mashing the keyboard fast enough
@@lunlunnnnn It's not an issue because (most likely) even if the old version is used, it's usually patched. That's how Ubuntu 16.04 works for example, they don't update anything, instead just apply security patches.
You may check the situation with the OneDrive package... Usualy, distros like Debian / Ubuntu ships old versions that not able to connect to the OneDrive... So they ship unusable package and you can only build it from source time-to-time.
Updating xscreensaver is not a solution. You would still be on Debian, where being 15 versions behind is a feature not a bug. You would just get the same bug later, after abandoning your entire philosophy for one angry dev. Why is Zawinski in the bug mailing list of a distro he not only despises and does not support, but despises the very philosophy behind it? Also, hating Debian seems stupid. It is successful at what it does, more so than any other distro, and why should every distro have to be bleeding edge? It also seems a little weird. Debian is stable (the reason they package this version of XS is because it works with the other out of date software they ship). Its users know all their software is multiple version out of date. Their is no way debian produces loads of bug reports for JWZ. Their is a difference between a ill maintained distro with old software that the devs dont have time to update, and Debian, a distro designed to be out of date.
2 years old is pretty recent, honestly. If the SW is doing its job and does not contain relevant bugs, there is nothing wrong about using "out-of-date" stuff. In our company there are products that are still being sold and developed and run on Debian squeeze. Yes, in 2024. Debian squeeze. The company is Japanese.
I go to whoever packaged it, if it's included in the distro repos, then I go to the distro, if it's in the AUR, or PPA, or (insert third party repo for your distro here) I go to the package maintainer. The only time I go upstream is if I got the package directly from upstream. I understand that upstream has no control over what version or what additional patches are part of the package I received from whatever unrelated party built the package and made it available for my use.
I figure if there's a bug in a package, it's up to the package maintainer to resolve it, and if it's a bug in upstream, the package maintainer should be the one to either update to a fixed version, or report the bug to upstream. Less duplicated bug reports, and happier devs that can spend more of their extremely valuable time putting in the work I extremely appreciate fixing actual bugs with their software, rather than having to waste time telling users that their junk is already fixed in a newer version that the distro failed to update to.
They talk a lot about respecting the author's wishes, but when the author treats approximately everyone as subhuman, how can they possibly expect anyone to care what they want?
11:17 My God, i just hate when people miss the point SO FUCKING MUCH. Yes you CAN do with software what you want, just like software maintainer CAN ask you nicely to limit usage to one that makes their paidless and thankless job easier, And considering you're beneficiary of their good will i thinks it reasonable to ("in return so to speak") fulfill such request. You don't have to, legally at least and perhaps even morally. but it would be nice. Yes he acted a bit asshollish. but honestly when your paidless job is made more difficult and time consuming by the very people benefit from it.... who wouldn't, and i'm not saying it's justified, just it's understandable.
I just use Debian testing for desktop use and haven't really had any issues since 2005 Xscreensaver is still on 6.06 from Dec 2022 even on sid (latest is currently 6.08), but most of the updates since then are for macOS, and I don't use it anyway.
when I have a bug, I look at changelogs to see if it's been fixed, then commits, then I try to fix it, and then I submit a bug report with some investigation
It's a screensaver. Who cares if it's out of date if it works? And if it doesn't work, that should be fixed by the distro either backporting or updating.
@@BrodieRobertsonWas watching with a background script on kiwi web broswer on android while doing the dish, lol, so phone display was off in the pocket. I was expecting it to be more recent until you said "Jessie and Wheezy" and being like "??? WTF ?", like 2021 era or something.
He could rename the package every year, like XAScreensaver, XBScreensaver... The page for old versions just says "this version is not supported anymore". But somehow that feels more stupidly complicated than it should be 😅
If i go directly to a bug tracker it's usually upstream for the package itself, but I'm usually just throwing the error message, and my distro + version into Duck Duck Go and see what it turns up. After this video I should probably think about that a bit more, probably best to check the distro first. Then check if there are upstream fixes if I've still got problems.
Whoever you end up reporting the bug to will certainly appreciate that you did your due diligence first. Someone else posted it here, but being a FOSS dev can feel a lot like working retail -- except devs are not paid to be nice to the users.
I was using Debian 12 (since release) until a couple of weeks ago. I was impressed with the polish compared to the past releases (everything working out of the box without any manual configuration). I recently installed OpenSuse Tumbleweed, because I need newer versions of specific software, and I'm not looking back. I appreciate everything Debian does, but I've realized I'm not their target audience (which is fine, btw).
I'm on Debian Stable because I don't like rolling releases and I expect to not upgrade my system in less than at least a year and a half. I also use Flatpaks and Homebrews because I like just enough stuff to be up-to-date (mainly neovim and Firefox).
This was always the strangest thing to me as a new linux user. Everything is so woefully out of date, once it passes muster it gets enshrined and stays that way until it breaks down or vulnerabilities are found.
I mainly use linux as servers and im used to things being out of date. Honestly though, when eventually i find bugs, i tend to find some obscure forum or bug report discussing that issue, so i eather: work-around the bug,find a different app, or update the whole system. Compile from source or waste the developer's time are not an option unless i've exhausted all possible solutions.
just because you run a server that does not mean that the software should be out of date. The security patches that are being released are for protecting against vulnerabilities. The logic of having a system vulnerable because that means stable is antiquated. If you cannot have a secure environment with proper functionality then don't provide the service.
@@hikkamoriiOnce again, if your has 1.1, 1.2,13,1.4,1.5 you are on 1,3 and there are 2 more security patches then guess what, you are not patched. the person above did not said anything about doing security patches and not doing feature patches. read the OPs comment
I feel like this should not be such a big issue. If the package is from a distro's repo, report bugs to the distro. It is the package maintainer's job to report it upstream if necessary. If the package is from any other repository, report to the package maintainer for that repository. Some users will always jump this process (simply because they may be new to all this or don't know the dev's perspective) and go to the upstream dev anyway. These users might seem very large in number to the dev. But, the dev can simply require some details from the user before investigating the reported issue - minimally, the version number of the software and its dependencies. Regarding xscreensaver, I think Debian did the right thing. Sometimes, programs grow larger than its creator and respecting the wishes of the creator, means denying a great piece of software to a lot of users. Also, for a stable distro like Debian, updating something like xscreensaver to the latest version may not be feasible. Because, such an update might require updating its dependencies to the latest version. This might cause a trickle down effect that will break the stability of the system. After all, Debian is stable only because those specific versions of software that it ships is stable. But then again, I am not a package maintainer or a dev. I use debian btw. ;)
Darned if you do, darned if you don't. But this phenomenon might explain why a big provider (like Microsoft Windows) would ignore years' worth of reports of a persistent bug -- because fixing the bug the right way would upset more important applecarts on their system.
I use Arch and I typically hit the upstream first, although with an aur package, I'll go to the aur page for it first. But before I report a bug, I search the issues list first to see if my question is already answered.
Same thing happens with neovim. A lot of configurations (especially tree-sitter) just won't work on older versions but apt just doesn't have the latest so you have to do sillyness that package managers were made to circumvent like downloading directly, compiling from source and adding to path. Maybe at the very least having some flag that specifies ""unstable"" for packages like this would go along way. I actually don't even know why they don't do this.
You just reminded me that there is still no reasonable way to get a screensaver on wayland. Devs seem to consider a screensaver without a lock screen an invalid use case. Which, I mean, I get it, but people still want it.
Tbh stuff like this makes me think a licence with super strict copyright protection will be a good idea. Something that'll actually prevent downstream packages from using the project name. Which, tbh? Sucks. A lot. It's very clearly an antithesis to the foss spirit but hey! Devs are busy enough without having to deal with this bs. And the way distros act it doesn't look like they're leaving ppl much of a choice As for Brodie's question: I tend to use upstream packages whenever possible, one of the first things I do on a fresh install is nuking my browser and libreoffice installs and going to download the upstream ver lol. If I can't I look to see if the app version is up to date, if yes, I go Upstream.
Copyright is not the same as a trademark (copyright covers the actual code, while trademark the name), copyright protections in foss are only meant to prevent someone from turning a foss project proprietary ("copyleft") which would be possible if everything was public domain, if you want strong trademark protection mozilla public license already does that, from my understanding there's nothing stopping devs from just stating "issues should be first reported downstream and only then escalated upstream", and making packagers replace the support link if it's a super old release.
@@thelakeman2538 right. Didn't think of the terminology lol. As for the mpl, yeah. It's one of my favourite licenses exactly because of the trademark protection. But afaik it doesn't prevent you using the name of you simply repackage without modifying the code(maybe if you use a different version but I'm not sure) and that's what will need to happen in a case of a licence looking to combat this behaviour. As for disabling links and all. Yeah, that's the bottles approach. And unfortunately it got them a bunch of flack.
How .... how did the dev get that message to print? Like, how does an old package "know" it's old? Just a if ( today date - package build date ) > 1 year? I'm just curious lol
@@Braiam Hshaha. I'm sure the dev adding something like that has a cron job if (today - last commit) > 55 days make an empty commit. Dev be like I'm 4 universes ahead of you
like 99 times out of 100 when i encounter a bug, i go search for it, then ask my distro's users, then probably just give up and use something else. so this "YOU DISTRO SUCKS, GO USE SOMETHINGS ESLE" would bug the fuck out of me. in case with debian, its whole idea is to not get major feature updates, so i understand why they never updated the package
I run Debian. I don't agree that 2 years is out of date. I do think sending a bug report for old versions of software is brain dead. I agree with Peter Nowee saying the warning should be removed if its allowed by the license.
As someone forced to use RHEL at work, I'd never considered Debian to be "ancient". It's definitely not arch or even Fedora, but ancient? I suppose it's all relative. I think Debian should have updated the package and placed it in backports, but after Jamie's comments, I probably would've deleted the warning just for spite. I get his position, but being an asshole is a great way to ensure I'll act in kind.
on arch, if it's a -git package (most of the manually installed packages I use) and it's not a pkgbuild problem, I'll usually go to the upstream. Otherwise I'll go to the arch forums.
A better solution could be having a setting to override the check (something like a "do not show this again" option) and allowing distro maintainers to default it to enabled for these "stable" distros. Current Github, and I hope most of the Application Lifecycle Management/bug tracker software, allows to set a template or a disclaimer every time a user submit a bug report and there you should ask for the version and hopefully inform the user how to tell the running version of your software
I'm gonna install Xcreensaver from source, but remove the message and make an AUR package that's always up to date while i'm using nobara under wayland
Recently, I tried to reinstall Fedora 40. the installation did not go properly multiple times. I thought it was my laptop's mistake or mine. After installing fedora with a lot of patience, I have logged in. Then running the dnf upgrade command, solved my problem. Until then the fedora on my laptop was a mess.
i am not going to lie ... I like this developer .. I totally get it ... I also think people who say are running Debian STABLE ... know that some of this may happen. I'd (JUST CURIOUS) be curious if say it was out of date in Stable but somewhat up to date in Testing or Sid.
Sid is basically rolling-release bleeding edge, so it would be running the most up-to-date version of xScreensaver, but being rolling-release means you should probably be somewhat technically savvy in order to deal with the inevitable issues that pop up. I run a rolling release distro (arch btw) but i also understand it is very not for everyone. I wouldn't want grandma and her cat videos to be wiped out by an update to gnome that wipes out her DE because somehow she messed up part of the update process.
If I run into a bug on my Debian-based main system, I usually first confirm it in the newest or at least a rather new version of the project. I have dedicated Arch and Fedora computers for that purpose of testing. Then I report it upstream right to the developer. That's the way it should be done everytime in my opinion and has yielded very fast fixes from the devs almost everytime. I work in software development and 2nd/3rd level support myself, so that probably helps :)
I just checked Linux Mint's package of XScreensaver, it's at version 5.45 while the current version is 6.08 No surprise there, Mint's version of ScummVM is just about that old too.
Damn that is old. I am on Debian 12 and the xscreenserver version is 6.06 (11-Dec-2022). Seems to be a problam when the distro is based on a disto that is based on a distro.
How insane is it that we have people so insistent on running old, out of date, buggy versions of a piece of software that they would remove a developer's warning instead of just updating the fuckin' package?
Here's an idea put in the license that redistributors must either keep the package up to date or rebrand it. That way users with an outdated version looking for where to file a bug report would not find the upstream project, because they would be looking for it under a different name.
I don't think that would work for everything. Redhat maintains the versions that they ship with for the entire history of that release. They don't do "upgrades" to the latest version but backport security fixes in order to give enterprises a stable server platform. You wouldn't want your bank constantly upgrading to the latest and greatest and risking software or code just randomly breaking all the time would you?
@@meomniplex yeah, you're right, thats why i dont ser using fedora and debian/Ubuntu in personal space with good eyes, rhel and debian derived distros shoud be used only in Server and corporative scenarios.
@@meomniplex Fair point. Instead of completely changing the name ... perhaps appending _[Distro Acronym]-[Release]f to the end of the package indicating that it has been forked (and by whom) to be an acceptable compromise? (Ie Package_[RHEL8]-[LTS]f)
Can't belive that people are even still using screen savers. Just have the display turn itself off. Screen savers was someting that was made way back in the day to avoid burn-in on CRT's, when they came with a mechanical off switch and no standby feature.
debian is genuinely insane. KDE 5.27.5 is the current version available in Debian yet KDE 5.27.10 which contains basically only bugfixes is out. Debian will never update even though the release can be built using the same build system they already use and just fixes bugs. Debian is not stable, Debian is stale.
@@卛 kernel-wide, there are no "system packages", period. There's an executable, it can execute it. Everything else is not kernel. The package manager is and will forever be responsible for this.
The reason is that most upstream maintainers mix bug fixes with new features. Debian has a policy of bug fixes only on stable releases. The issue is upstream does not want to stand by their old software releases.
I don't know if the new version of XScreensaver has dependencies with versions that aren't yet in Debian Stable or Debian testing or if it can work with the current Kernel's version. So I get the maintainer's point.
So... which are the distros that don't do that? I friend is going to ask me what distro to install since Steam has died in win7 and would be nice to know a good one.
Unrelated to the video itself: I'm a huge fan of Xscreensaver since I switched to Linux in 2010 and I just now read about it's creator Jamie Zawinski. I must say when I was indifferent on which side I stand on this topic, now I'd say Jamie is my man. Defenitely a character but a huge name and contributor to the FOSS world. Check him out! He has a Wikipedia entry and a personal website. Edit: Also he hates Windows with a passion for personal reasons. I support his stance to the fullest :).
@@joshix833 yeah you get that almost inevitably when you keep having the same arguments repeatedly, being an arsehole I mean there's no excuse for MacOS.
I consider this code, intended to explode into the face of those who work to create a nice stable distro, a "timebomb" and it makes the upstream untrustworthy.
I run arch, so going straight to upstream is usually fine. I do of course search first, I don't want to be that guy that makes a duplicate bug, especially if old.
Now with xscreensaver the developer may get away with it. But if you are running a "stable" distro for whatever reason, updating an application that may be "Out of date" is very risky business, if you go down the dependency chain, you risk having to update a lot of the components and that can break other stuff. As the distro maintainer may only have certified that specific version of the entire chain. If I am then served a warning like this, and get a snarky reply from the developer and told to update said application and dependencies. I think my response is to grab the source for that specific version that runs on the same dependencies that my distro ships, edit it to strip the warning, compile and run, take a screenshot where the warning is missing and send it to the developer as a reply and then close it. In the Linux ecosystem, you can't expect everyone and every distro to always package the latest version, so if they report a bug, on an old version. The PROPER developer response should be "Oh, your distro has version X, this bug was fixed in version Y. So either your distro needs to update their version, or you need to switch to a newer version. But be advised that dependencies changed at version Z, so an earlier version before this change should work in place." Then run that copy pasta, or link to where that answer is in your bug tracker, unreasonable users will always be unreasonable, but reasonable people are given a choice, either take the version before dependency changes, live with the bug or try your luck at library dependency bingo in the worst case.
@@formbi The developer does not provide a .deb package of xscreensaver AFAIK, so there is no real way for users to get it them. Yes, some could compile from source, but not everyone and especially if the latest version depends on something that the current system does not have.
The proper developer response is "go tell the person who gave this software to you". They don't tell you to update, they don't tell you not to update, they don't tell you to compile from source and they don't give you a package. Then you go to the person you should have gone to in the first place: the maintainer who gave you the package. The maintainer can deal with it, and if it's something upstream needs to know about, they report it to upstream themselves.
The actual proper response is "here are the patch for A bug, B bug and C bug, identify which of those your users are complaining about and backport it". Guess what this specific upstream doesn't do. Heck, Postfix is a saint compared to what upstream does here.
what happens if someone uninstalls the package on their own computer, downloads latest source, build and install it in debian or ubuntu? is it easy to do that?
What happens is that it may initially appear to work: then break when you try to update the system. You need to build you own local package for it to work properly.
Project to see the current version vs. what the distro shipped. I'll then do the distro route and bug them and if they can't fix then I'll go to the dev project and just grab src. I don't fear compiling from src since it's all I did from '95 - '05 :D
And this is why no one is amazed when someone says they are a software developer. The normies automatically think you are an social inept a-hole that thinks their terrible documentation is perfect because they think the normies should have the same level of programming skill as they do.
If you want users to use the latest version - provide the packages yourself. Wine does that for example, I can go and install the latest version instead o the one that came with Ubuntu or Debian. Debian has a release schedule that results in older versions being shipped - that is a good thing IMO and it is one of the reasons I use Debian for my servers (and it is usually one version behind the latest, at least for important stuff). If they made an exception for xscreensaver, then soon they would have to make exceptions for other packages (what if the latest version of xscreensaver depends on the latest version of some library etc?) and Debian will just turn into Ubuntu. The idea of a stable distribution is that it is, well, stable, not chasing the latest versions and the latest features. The same is with Debian and with RHEL (or at least it was with CentOS while that was still a thing - usually CentOS using even older versions than Debian). If I want a newer version of some package, I can try to get it from the developer (like Wine) or from backports (like zfs), though I really try to avoid compiling it.
Ubuntu's LTS model makes a lot of sense though. One version (LTS) is stable and the other is potentially less stable but with the benefit of newer software. I can't think of a better way to do it.
"If they made an exception for xscreensaver," They do make exceptions already though - for instance, the current version of firefox available in Buster, Bullseye and Bookworm is 115.6.0-ESR - which was released on December 19th. Similarly, Bullseye and Bookworm both provide the latest version of Chromium. Debian doesn't ship a 2+ year old browser and it would be utterly insane if it did. I don't see any reason why xscreensaver would need to be held back in a "stable" distro, nor any reason why it would be beneficial to do so. In the event of current versions depending on a new version of a library, then sure - hold it back (I assume that's why Chromium in Buster is only on version 90 and not 120 while firefox has been updated to the latest ESR). But that's not happening here.
@@masaufuku1735 However, at the same time there is no need to have the latest xscreensaver version. Having the latest browser version may be important for security. Screen saver? Probably not so much. Debian updates the packages when it is important, for example firefox. Updating xscreensaver just because of the nag message probably is not important. If there was a security issue with the version in debian, I am sure it would either be patched or a newer version would be packaged. I do not think that the reason that the dev has thing against old software (really, the website for xscreensaver gives a 403 if it detects an older browser version - it's "botnet protection", because, you know, botnets cannot change the user agent string, right?) is valid enough.
So the dev has to build packages for all distros? Yeah, right... Have you thought at least twice what does that mean? Also as others said, check your beloved stable inmutable distro, see the versions of chrome ,firefox,openssh.... Oh, strange... 6 months old? 1month old?
![fellow fellow - พรุ่งนี้ไม่มีใครรู้ feat. INK WARUNTORN [OFFICIAL MV]](http://i.ytimg.com/vi/QP6JyjYx_W0/mqdefault.jpg)
Really the message should say something like,
"Warning: This version is out of date.
Bug reports for out of date version will be ignored.
Please advise your distro maintainer to update their packaged version."
And when people do submit bug reports for older version, just auto closes them with a copy past message of,
"This version is out of date. please update to latest, and resubmit if problem persists."
Are people still going to have an issue with it? yes. but it gives the software maintainer a clean way to say not my problem, without getting into the shit chucking.
I read the thread, that's exactly what some people were asking in the 2016 debian bugtracker.
Yeah no, We're talking about Linux Users here. They'll bitch and belly-ache about their bug being auto closed, make new bug-reports without the information to auto-close it. Then five replies deep tell that it's a super out of date version, and get told off; marked and closed waist even more time and maybe maybe sulk off.
I agree, this would be understandable message and not aggressive, but informative only. Much better.
Auto-close is generally a garbage idea. I have had to keep reopening over a dozen of bug reports due to automatic closing because the bug report has not had any replies for a while but the issue is still in the very latest version of the thing.
There has to be a check against version or something before auto-closing. Stalebot is one of the worst offenders to getting bugs fixed. I honestly hate it.
@@TheExileFox Isn't auto-close configurable? Man how can they not have this configurable?
It's like getting food poisoning from food bought at your local supermarket, and in response demanding that they remove the "best before" date from the products they sell
It's like a stranger who gives you eggs, saying "These eggs are a gift- yours to do with as you please!" and then, once you make a birthday cake with their eggs, knocks on your door and generously allows you to decorate your cake however you want, provided it *also* says "THIS CAKE IS SEVEN YEARS OLD SO IT PROBABLY TASTES BAD. BTW SUPPORT YOUR LOCAL EGG VENDOR."
Some of the debian maintainers have suggested filing bugs upstream and I've always taken the stance that debian should manage the duplicate bugs in the upstream repo.
Arch, Gentoo, even PopOS users sometimes should be filing upstream as they're often on the latest versions but in the case of Debian, Ubuntu and others who are intentionally out of date, users should always be in the distro issue tracker and the distro maintainers should file upstream in cases where it's relevant
@@BrodieRobertson There is also the issue of when devs patch something they don't have any way to communicate how critical that patch is... When bugs are fixed it's only if there is a security issue that debian is informed, it would be better if bug fixes were flagged from distributors also.
@@BrodieRobertson Pop!OS has the same software base as Ubuntu LTS. They’re little to no different in that regard.
@@urlhnd PopOS is partially rolling, that's part of why it's so popular for gaming
@@BrodieRobertson isn’t it only for stuff like drivers and the kernel though?
The funny thing about 14:40 is that if the user know how to apply a patch they probably know how to just compile a new version from source.
From the wording, I'm not entirely convinced that they know what a patch is
haha its so funny. hey hey let's build all software from source LOL. haha so funny. look at me I am a neurotic zoomer LOL. building packages for no f ing reason is so nice YEAH! woohooo
@@user-ro1cc8tz6d
Ever heard of Gentoo?
@@user-ro1cc8tz6ddon't post on the internet while intoxicated
@@user-ro1cc8tz6dyou must hate Gentoo huh
The most surprising thing in this is a FOSS developer that actually understands what the license they've applied to their own software means.
"who understands that stable and ancient are not the same". I feel it so well.
That's why I moved away from Debian(and ubuntu LTS). They shipped so old packages, I literally couldn't compile some stuff because important libraries(like SDL) were too old. I literally couldn't compile source code of programs because they were relying on functions from the "new" versions of libraries released several years ago but not shipped in the distro.
Exactly my experience. If you need software that's not included in the repo, Debian and its derivatives are an awful experience. My system quickly became a mess of PPAs and manually installed libraries. Much happier with Fedora.
What was the program, language you were writing for?
@@Myname-l3h I don't remember exactly as it was years ago. Language was C, when looking for the solutions I've found that VVVVVV also had the issue with old SDL in ubuntu.
Other was related to FOSS FPGA tools, most like one of symbiyosys dependencies(it can use a lot of tools). I remember it not just failed compilation, README specifically mentioned that some system lib is too old
Well, you are probably a programmer. An average user doesn't compile software on their PC. For them, LTS is still the best, because it's much stable.
@@matyasmarkkovacs8336 LTS is great, you get to enjoy the same bugs for many years!
Thank you for reminding me to update my system, had about 7.5GB of updates that needed to be installed lmao
I haven't used a screensaver in so long I don't even know when the last time I used one was lol
This thread is one of the actual reasons it started to decline. The dev could easily ensure packages were up to date, but they aren't.
@@orbatos It's not upstream's responsibility to deal with 18 month old long-fixed bugs. Debian is dry and dusty old shit unless you're running Debian Sid, but at that point just run Arch, it's easier to deal with, and pacman is more robust than apt anyways.
Yep. Screensavers are totally pointless now unless you are an idiot and you are using an OLED monitor for your PC.
@@orangejuche Good way to show you don't know what your talking about and didn't read what I posted. Nobody is saying devs are responsible for old version indefinitely.
Upstream responsibility doesn't include slipping in fake error messages, but it does include either maintaining packages or talking to maintainers to ensure issues like this don't happen.
Maintainers are not representative of an entire distro or even repository as they tend to only maintain a limited portion of the package pool. If they are out of date, or there is a bug they should be the ones reported to, but devs often discourage this interaction, then complain that older packages still exist, despite dependency issues.
@@orbatos Did debian maintainers backport fixes or reach out for author to help with backporting? I guess no. And it's not really author's job to reach out for every distro maintainer neither to help with backporting. Especially unpaid.
This is an absolute classic. See also the war between deb-multimedia and debian where it got so petty that devs tried using higher version numbers to stop users from switching away from their outdated libraries (users caught on and just pinned deb-multimedia higher). This was a situation where someone actually did provide an alternative update. And then there's the whole cdrecord debacle...
Links?
This is one of the main reasons why I'm glad that Flatpak exists: it makes these kind of complaints occur less often (at least for "normal" desktop apps, though maybe not for lock-screen apps like this one). If you're running Debian Stable or some other non-rolling-release distro, and you want to run the current version of a certain desktop app, then Flatpak makes it fairly easy to do that *even if* the distro ships an outdated version of that app or doesn't ship it at all.
Since this is such a common issue, a better bug reporting system would be a good idea. Something to make it so that you have to select your distro from a list, or type in the software version you have installed. Then, when you select something like debian or type in an out of date version it automatically notifies you that your software is out of date and rejects the report.
Basically, just idiot proof the bug tracker.
A standardized portal for bug tracking
people will just lie and fill the report anywwyss
@@snowwsquire Hence, we need a standardized portal to submit bugs - a program which automatically fills in the version number of the software and the OS brand and version, along with any necessary dependency versions, and sends the report to a specified tracker with any additional details as inputted by the user where the maintainer, if they choose, can automate rejection based on the version being out of date. This wouldn't help for old software which doesn't already support this reporting feature, but it would for any new software. This would ensure the details of the problem are sent in full without obfuscation by the user in a way that can be reliably and repeatedly parsed.
@@mckendrick7672 people would call it a privacy violation for gathering all this info about your computer
hm.. that kind of creates the problem of what do you do with the idiots that find a way to break the idiot-proof bug tracker? who is bug-tracking the newly bugged bug-tracker? How can one out idiot the idiots?! It's never ending I tell you! 🤣
2:10 The bottles problem isn't just an out-of-date package in Fedora (that could have been fixed by packaging a newer version). The core issue is that bottles requires newer libraries than what all the other Fedora packages used. This is a major pain point for traditional distros.
The proper solution is to let different apps use different versions of various libraries. Either via static linking, via namespaces (Flatpak) or by using to the Nix model (different builds live in different prefixes - you don't put everything into /usr).
and then some software uses patched libraries
meaning libraries which are SLIGHTLY incompatible with the normal ones
If I was maintaining a project like this I would put a "This package is out-of-date. Complain about it here:" and then just post the problematic distros issue tracker there.
Yeah, changing the warning is my solution here, there is no reason it needs to be that problematic.
how about "This package is out-of-date. Reports upstream will be ignored, ask downstream to fix(update) the package."
@@yozul1 I think it's not worth it, just have distributions patch in their URL. If you want to make it easy for downstreams, add a configure option which allows the bug tracker URL to be set by packagers at compile time.
Edit: on a second thought, not even that is needed. All credible distributions report a "BUG_REPORT_URL" and "SUPPORT_URL" in their /etc/os-release, which applications could reference.
By default reportbug will report to Debian first. Downstream rarely redirects issues upstream, unless it's upstream that has to deal with it.
@@yozul1 reading the os version should be as simple as getting from etc/os-release though
Sometimes, you actually *need* outdated stuff. For example, I do my job work with a software written in Java, which has gconf as an implicit dependency. If it's not installed, the software will hang on start. However, this package is so outdated, it was even removed from mainline Gnome.
Edit: And yeah, I think it even needs xscreensaver.
It would be a whole lot simpler to add a check box that tells xscreensaver to not show the popup again. Like almost every software out there that has a pop up for whatever reason...
If I find a bug, I assume it's something I broke and then start to look for a solution. I think I've only every filed a single report, and that was after checking on the forums (CentOS 6 or 7) and the local gurus said to post a bug report. That said, I'm a barely functioning Linux user, so finding real bugs that I didn't cause are rare for me.
Oh I know this one. Xscreensaver included a time bomb. You could be using the latest upstream release, but if it was more than 60 days (checked the source) since an epoch included in the compilation it would complain, ie. if you compiled it from source it would complain _too_, even if there isn't a new upstream available, like it happened with 6.06 released 2022-12-11 with 6.07 released 2023-08-29. Yes, the warning would appear even if you are on the latest version (!). Other software's actually check if there's a newest version and print a reminder like Legendary which checks their API (they deliver configuration fixes that way too) to inform the update is available. You can disable this too!
Using an API call to check for the latest version of the package behind user's back is even worse as it introduces another moving part that can be potentially exploited in an out-of-date package.
checking for a new version normally includes a network call which is something Linux users on average are EVEN MORE angry about
This was a problem for some developers of emulators, who did not want an old version of the emulator core distributed in RetroArch. That's the reason why Swanstation existed as an alternative to Duckstation or still LRPS2 as a renamed and fork of PCSX2. There was literally toxic fights and comments all over the place. But rebranding is a way to handle this. But updating the RetroArch cores is very complex and involved and not like a simple package update on a distribution. So its understandable they rebranded an older version instead updating it (non trivial task).
So my suggestion to all those distributions is then (if they don't want to update to newest version), to rebrand and fork as a new project and maintain that one.
Yeah that's immediately what came to mind when i watched this. Like just make a fork and rename it and then *you* maintain it. Maybe other projects that want to use an older version can just use that fork instead, with how infrequent i would imagine the updates would be.
In fairness, there's a LOT of reasons for RetroArch drama. Most of them, whatever the surface-level explanation, can be traced back to "the project lead is abrasive, manipulative, and just kind of an asshole".
@@CptJistuce I don't agree, but that's not the point here. I was specifically talking about the versioning of older versions. Or for any other reason the developer and package maintainer could not agree. Rebranding and forking the project is a way to solve it for both sides. Regardless of the the reason.
@@CptJistuce Can confirm, happened recently to me with PCSX2.
>tfw ownership ego of the zoomer linux users is so ınfiltered they go after other projects that dare to host older versions of other software
I'm one of those herp derp paste eaters, so when I come across a bug I ask Reddit about it because I don't know where else I would go.
That's why many projects (including mine LOL) will require you to specify the version of the software you're running at the very top of the report with a big warning that if it's not the latest one the bug will be automatically closed. This is IMO the best solution, users can still report bugs upstream but they will have to test it on the latest stable and/or dev version before reporting.
might be a bit much to ask users to test it on dev. Latest stable probably makes more sense.
Latest stable would be good, not necessarily the very latest version. And if you use Stalebot or similar tool to autoclose an issue only because it hasn't had any new replies for a while, then your not doing things right. I have had to reopen dozens of issues that were still present in the latest versions of various things simply because the bot is effectively hiding old but still present issues.
@@TheExileFox on one side, I agree with not closing issues if they are relevant, but the question is, are they really relevant? If a single user reports something very specific to his use case and it hasn't been fixed for years then most likely even the original person reporting is no longer interested because they probably found an alternative in the meantime. You can always just reply with "still relevant" and the issue will re-open and also let maintainers know that there is at least one person actually waiting for this. It gets rid of all of the fluff and lets devs focus on the things that are actually relevant.
Also a note about the dev/latest stable thing. I won't ever require a dev version test, but if somebody is going to compile one themselves it doesn't really matter if they grab a stable tar ball or one from master. I would simply prefer the one from master if possible, not require.
@@nezu_cc That's not for a bot to decide. Yes, a fringe report can be closed or archived and marked as wontfix, stale, feedbackRequired, etc. or whatever, but doing so automatically just because no one has replied for some time is simply disrespectful. You shouldn't have a public issue tracker if you don't want people reporting their issues.
Users should not have to test anything. Not using the software is very often a good solution.
Just change the warning message "Warning: This version is out of date. Ask your Distro to update the package " and then point that link to the Distro so Users are more likely to report bugs there instead of upstream. A more sinister version would send the bug reports to /dev/null for all out of date version. Or maybe have a bug tracker tat ask for the installed version first, and asks you to upgrade.
Or what if the user ignores the message because it doesn't impede functionality.
That's the point I've gotten to. I'd always run into issues where everybody tells me to do something different; use official packages so you don't break debian, compile from source because your distro is stupid, etc... I'm tired of it. I use stock themes and default settings nowadays. No more frivolous tinkering. If it works, let it work. Suppressing the OCD is the only cure. No more headaches.
I vividly remember this situation and the chaos it caused at the company I worked for. Suddenly this message was showing on screens of CUSTOMERS' media players. It caused panic among the execs and had me sweating bullets until I found this bug report. This is a great example of how FOSS developers can sometimes get too wrapped up in how a situation affects them and forget about the ripple effect their decisions can have.
When I encounter a bug, I usually check if in the changelogs between my version and the most recent upstream version is a related bugfix mentioned. If not, I report upstream. If yes, I don't report at all.
In the specific case of xscreensaver good luck figuring out what "minor bug fixes" means. Yes, it has a minor bug fixes entry. Also, you can't check easily a diff between versions. Upstream doesn't have a patch repository, so you have to figure out which of all those changes probably affected your issue.
The bug may originated fron the distro's own patches, where your method will not properly identify.
I mean like I don't want a huge TEXT telling me I'm out of date when I unlock my system. It should probably be somewhere else. Also yes I get that the massively out-of-date distros that think just because Enterprise wants Ancient software means everyone should have Ancient software, will tell us use our bug-reporting trackers. They just don't understand that most users go well I don't have a Distro bug, I have a Software bug; so I much report it to the Software's Bug-Tracker.
Extra annoying when the software makes it hard to find out what version you are running. If you can easily find the version information: you may get a clue how out of date it is, if you find the upstream website instead of your distro's website.
Ah yes Windows 7 users of the linux world
I’m with Brodie here: This is acceptable if the application has been abandoned or is in maintenance mode. But I would add a clause here: Only if it is a business application that is responsible for a large amount of the income of said business.
Not really since Debian backports security fixes afaik.
Debian backports security fixes and the idea of a stable distribution, like Debian is that the packages are extensively tested before release. Since testing takes time, the release always contains old versions, however, those old version are more likely to be stable.
Once software is released, it is used and tested by a lot of people who discover and report bugs, the devs fix them (hopefully). I want to run the old version with its bugs fixed and not the latest version with new features and new undiscovered bugs.
How can you compare Debian to Windows 7? Debian receives security updates, Windows 7 doesn't.
you don't understand the stable release concept, do you...
If they update the package to remove the nag, they should rename the package as it no longer functions as the developer intended.
eg. call it XDebianSaver - so XScreenSaver isn't mentioned, and Debian gets all the reported bugs.
Exactly! Just fork it!
Debian on a server: Really stable, hassle-free, long lifecycle.
Debian on a workstation: WTF are you doing, Linux 3-5 years ago is a terrible UX.
My first experience with Linux was, as for many, Ubuntu (aka Debian unstable) LTS. It sounded like the right choice, but it sucked. Everything you interact with was extremely out of date and buggy. After a while my system was a broken mess of PPAs, because I needed newer versions of so many tools.
I don't want to deal with rolling release breakages, but one step behind (Fedora) has been really good so far.
Not really. Older system doesn't mean that UX is terrible, it is just not changed for while. Changes how things works causes a lot of time wasting so it is better that there is no changes. It also affects solving issues because there is documentation on web how things are solved on some OS release.
@@gruntaxeman3740 even current day Linux hardly works for your average PC user. Rolling back 3+ years worth of bug fixes, features, and usability improvements does _not_ help with that. If a problem is common enough that information on how to work around it is readily available, it's probably already been fixed upstream.
LTS works for servers, because they have a well-defined scope of tasks, and all the important bits (like the kernel, openssl, ...) update slowly and provide LTS branches that _are_ pulled in by distros.
@@jfolz
Most of the features were good 17+ years ago for average PC user when using Ubuntu in desktop computer. Windows XP was also good enough something like 20 years ago for average PC user except maintenance was hard.
Laptop and 3D-acceleration however was good enough in Ubuntu about 15 years ago and maintenance issues in Windows gradually disappeared soon after that. There was not much hazzle in Windows 7 when browser was able to show PDF files and Flash player was kicked off, and browser updates went more simple.
Software quality is steadily improved about everywhere. Software is not really that buggy or feature limited.
People are still using Windows 7, that is something like 14 year old LTS.
Also for problem solving, LTS releases are good because when about every one is using same releases, there is a lot of knowledge how things are handled. Also it is very nice for average PC user when features are not changing twice a year, especially if using something else than browser.
what happened to the "and......i'm out!" ???????
Usually I go to the upstream big tracker. But knowing that I use a stable distro, I check completed/closed bug reports for my problem as I'm usually not running the bleeding edge version of software (and if I am then it's because I installed that software specifically and I'm usually following the development of it via email notifications).
If there is a fix for my bug than I try updating the software.
Very rarely do I feel the need to actually file an upstream report, and once I've even filed a distro specific bug on the distro bug tracker.
For true scorch earth I would adjust the way the message is done, so that there upstream patch no longer works (and also should make it obnoxious to remove).
Although then again, it would take 1.5years at minimum, more likely 4, for this trap to snap, and upstream maintainers to be confused why this problem is back
I *love* that Debian Stable gives me 3 years at a time. I build my own 'ubdist' dist/OS in the cloud, Debian Stable with just a very few Nix packages, because all my many programs, WSL supporting scripts, LiveISO/BIOS/UEFI, etc, all will require as little maintenance as possible for 3 years.
I do an automatic analysis of what binaries, kernel modules, etc, are installed in each cloud build, and it rarely if ever changes at all. When it does, so far it's something minor.
So I can focus on usability, security, and out-of-box usability of the LiveISO.
Pretending to be nice is mostly a problem when the developer can't take anymore user stupidity and snaps. There's only so many incoherent bug reports demanding fixes a developer can take while biting their tongue.
This "pretending to be nice" phrase is glorifying misdirected abuse. You become your habits.
Some people complain Sourcehut's email patchset and mailing list issues discourage contributions. Now I'm thinking this might have been by design. Maybe for some projects, getting one competent patch/issue in years seems better than tens of barely coherent ones.
It's the expectation of some corporate/large project users - a) to think in not 2 but 10+ year timeframes (there is a market for 10 years LTS distros as you know), b) that the distro exactly protect users from "developers wishes" (one could interpret it the way - not entirely wrongly even - that these users expect the distro to do the work of fing over the developer and putting them in their place for them). Often comes from project structures where software choice is at the beginning of a multi year effort, and there is the expectation that software is chosen, tested, specified and frozen right at the start. 2 years could be just a temporary funding gap, after which everyone expects to be able to pick up just where they left. In that world there is a mindset of "ideally, k*ll the developer as soon as they are finished, certainly keep their runny noses far away from it now adults are running it".
So... alright, they don't want Gordon Ramsay running a mess hall.
Now the simple and very open source friendly solution to this situation just wasn't mentioned anywhere - since what the distro is doing is creating a fork, *call it a fork*, name it xscreensaver-debian or something, and that way make it clear that the package is the distro maintainers responsibility, not that of the upstream author.
(to make it clear, jwz is someone I highly respect, though I suspect I would get suggestions to use that sanctimony in interesting ways for stating that in that discussion :) ).
Tbh it depends how annoying is this message (if I am not wrong you didn't showed it in the video). If it is small annotation or better: can be disabled by clicking that you really read the message then it is ok. But if there are people who for some reason are running old version and know that, then I don't think that you should annoy them by big splash screen every time (agin: I don't know how this message was displayed in this application).
been there, googled that report. dont hurt my Debian!
I've switched from Arch to Debian stable like a year ago and I am happy with it. I did have to compile a few packages when I needed a newer version, but this was like 4 or 5 packages in a year. For me that's an acceptable tradeoff when I know I can turn on the computer and it'll always be working and stay out of my way to focus on doing things. But I do stay away from packages that are changing too much and that's fine for me. For example I am using Sway instead of Hyprland. I'll use Hyprland when it becomes a bit more stable, because I could't be bothered with things changing every week.
"Stable doesn't mean ancient." That's damn right.
Qubes-OS really is a special case, since it is actually catered towards security and stability over usability. As a Qubes user I will always first check if an issue is caused by Qubes instead of the software, since I know that the system packages are very old.
That is different for other distributions. Unfortunately, Qubes also does not support Ubuntu, so I'm actually kind of stuck with Debian for the application VMs as well. Those are newer than the system distribution, but it's still Debian...
it's still very bad to have a potentially insecure version of xscreensaver
@@JessicaFEREM that is not an issue in Qubes, since the host system is completely isolated. It has no access to internet and no userdata is handled there. Also, critical security issues are fixed even in older distributions.
@@tlpthxit's still an issue because there are some bugs that can be exploited through physical access, for example I remember a bug in Linux mint I believe, where you could unlock the computer by mashing the keyboard fast enough
@@lunlunnnnn It's not an issue because (most likely) even if the old version is used, it's usually patched. That's how Ubuntu 16.04 works for example, they don't update anything, instead just apply security patches.
You may check the situation with the OneDrive package... Usualy, distros like Debian / Ubuntu ships old versions that not able to connect to the OneDrive... So they ship unusable package and you can only build it from source time-to-time.
Updating xscreensaver is not a solution. You would still be on Debian, where being 15 versions behind is a feature not a bug. You would just get the same bug later, after abandoning your entire philosophy for one angry dev.
Why is Zawinski in the bug mailing list of a distro he not only despises and does not support, but despises the very philosophy behind it?
Also, hating Debian seems stupid. It is successful at what it does, more so than any other distro, and why should every distro have to be bleeding edge?
It also seems a little weird. Debian is stable (the reason they package this version of XS is because it works with the other out of date software they ship). Its users know all their software is multiple version out of date. Their is no way debian produces loads of bug reports for JWZ. Their is a difference between a ill maintained distro with old software that the devs dont have time to update, and Debian, a distro designed to be out of date.
JWZ was very vocal about lots of bug reports about bug fixed years ago. I'm pretty sure his opinion worth more than your gut feeling.
2 years old is pretty recent, honestly. If the SW is doing its job and does not contain relevant bugs, there is nothing wrong about using "out-of-date" stuff.
In our company there are products that are still being sold and developed and run on Debian squeeze. Yes, in 2024. Debian squeeze.
The company is Japanese.
I go to whoever packaged it, if it's included in the distro repos, then I go to the distro, if it's in the AUR, or PPA, or (insert third party repo for your distro here) I go to the package maintainer. The only time I go upstream is if I got the package directly from upstream. I understand that upstream has no control over what version or what additional patches are part of the package I received from whatever unrelated party built the package and made it available for my use.
I figure if there's a bug in a package, it's up to the package maintainer to resolve it, and if it's a bug in upstream, the package maintainer should be the one to either update to a fixed version, or report the bug to upstream. Less duplicated bug reports, and happier devs that can spend more of their extremely valuable time putting in the work I extremely appreciate fixing actual bugs with their software, rather than having to waste time telling users that their junk is already fixed in a newer version that the distro failed to update to.
They talk a lot about respecting the author's wishes, but when the author treats approximately everyone as subhuman, how can they possibly expect anyone to care what they want?
It's even funnier when the author talks about toxicity and yet he is so unbelievably toxic. 🤣
11:17 My God, i just hate when people miss the point SO FUCKING MUCH.
Yes you CAN do with software what you want, just like software maintainer CAN ask you nicely to limit usage to one that makes their paidless and thankless job easier,
And considering you're beneficiary of their good will i thinks it reasonable to ("in return so to speak") fulfill such request.
You don't have to, legally at least and perhaps even morally. but it would be nice.
Yes he acted a bit asshollish. but honestly when your paidless job is made more difficult and time consuming by the very people benefit from it.... who wouldn't, and i'm not saying it's justified, just it's understandable.
I just use Debian testing for desktop use and haven't really had any issues since 2005
Xscreensaver is still on 6.06 from Dec 2022 even on sid (latest is currently 6.08), but most of the updates since then are for macOS, and I don't use it anyway.
when I have a bug, I look at changelogs to see if it's been fixed, then commits, then I try to fix it, and then I submit a bug report with some investigation
It's a screensaver. Who cares if it's out of date if it works?
And if it doesn't work, that should be fixed by the distro either backporting or updating.
Debian Jessie and Wheezy... Me being like "WTF, in 2023", look at screen... 2016... Ah, historical context video, lol.
I did start the video by saying it was an old bug lol
@@BrodieRobertsonWas watching with a background script on kiwi web broswer on android while doing the dish, lol, so phone display was off in the pocket. I was expecting it to be more recent until you said "Jessie and Wheezy" and being like "??? WTF ?", like 2021 era or something.
He could rename the package every year, like XAScreensaver, XBScreensaver... The page for old versions just says "this version is not supported anymore".
But somehow that feels more stupidly complicated than it should be 😅
Well, there is calender versioning
Rename it to XOscreensver (for eXtra Old)
If i go directly to a bug tracker it's usually upstream for the package itself, but I'm usually just throwing the error message, and my distro + version into Duck Duck Go and see what it turns up.
After this video I should probably think about that a bit more, probably best to check the distro first. Then check if there are upstream fixes if I've still got problems.
Whoever you end up reporting the bug to will certainly appreciate that you did your due diligence first. Someone else posted it here, but being a FOSS dev can feel a lot like working retail -- except devs are not paid to be nice to the users.
I was using Debian 12 (since release) until a couple of weeks ago. I was impressed with the polish compared to the past releases (everything working out of the box without any manual configuration).
I recently installed OpenSuse Tumbleweed, because I need newer versions of specific software, and I'm not looking back.
I appreciate everything Debian does, but I've realized I'm not their target audience (which is fine, btw).
I'm on Debian Stable because I don't like rolling releases and I expect to not upgrade my system in less than at least a year and a half.
I also use Flatpaks and Homebrews because I like just enough stuff to be up-to-date (mainly neovim and Firefox).
Same users still running xp on their family computer 😅
This was always the strangest thing to me as a new linux user. Everything is so woefully out of date, once it passes muster it gets enshrined and stays that way until it breaks down or vulnerabilities are found.
yeah that's the reason I stopped using Debain, I often found myself using the debian-testing repo to get somewhat recent version
I mainly use linux as servers and im used to things being out of date.
Honestly though, when eventually i find bugs, i tend to find some obscure forum or bug report discussing that issue, so i eather: work-around the bug,find a different app, or update the whole system.
Compile from source or waste the developer's time are not an option unless i've exhausted all possible solutions.
just because you run a server that does not mean that the software should be out of date.
The security patches that are being released are for protecting against vulnerabilities.
The logic of having a system vulnerable because that means stable is antiquated. If you cannot have a secure environment with proper functionality then don't provide the service.
@@John7No Most LTS distros patch old software. Just because they use older version, doesn't mean it's not patched.
@@hikkamoriiOnce again, if your has 1.1, 1.2,13,1.4,1.5
you are on 1,3 and there are 2 more security patches then guess what, you are not patched.
the person above did not said anything about doing security patches and not doing feature patches. read the OPs comment
@@John7No backports are a thing
@@jacksoncremean1664 yes, although then the question comes , is it still stable?
I feel like this should not be such a big issue. If the package is from a distro's repo, report bugs to the distro. It is the package maintainer's job to report it upstream if necessary. If the package is from any other repository, report to the package maintainer for that repository.
Some users will always jump this process (simply because they may be new to all this or don't know the dev's perspective) and go to the upstream dev anyway. These users might seem very large in number to the dev. But, the dev can simply require some details from the user before investigating the reported issue - minimally, the version number of the software and its dependencies.
Regarding xscreensaver, I think Debian did the right thing. Sometimes, programs grow larger than its creator and respecting the wishes of the creator, means denying a great piece of software to a lot of users.
Also, for a stable distro like Debian, updating something like xscreensaver to the latest version may not be feasible. Because, such an update might require updating its dependencies to the latest version. This might cause a trickle down effect that will break the stability of the system. After all, Debian is stable only because those specific versions of software that it ships is stable.
But then again, I am not a package maintainer or a dev.
I use debian btw. ;)
Darned if you do, darned if you don't. But this phenomenon might explain why a big provider (like Microsoft Windows) would ignore years' worth of reports of a persistent bug -- because fixing the bug the right way would upset more important applecarts on their system.
I use Arch and I typically hit the upstream first, although with an aur package, I'll go to the aur page for it first. But before I report a bug, I search the issues list first to see if my question is already answered.
debian is restricted too much for those times? in debian sid there is still gnome 44 for example. I know we can use experimental but ..
Same thing happens with neovim. A lot of configurations (especially tree-sitter) just won't work on older versions but apt just doesn't have the latest so you have to do sillyness that package managers were made to circumvent like downloading directly, compiling from source and adding to path. Maybe at the very least having some flag that specifies ""unstable"" for packages like this would go along way. I actually don't even know why they don't do this.
You just reminded me that there is still no reasonable way to get a screensaver on wayland. Devs seem to consider a screensaver without a lock screen an invalid use case. Which, I mean, I get it, but people still want it.
Tbh stuff like this makes me think a licence with super strict copyright protection will be a good idea. Something that'll actually prevent downstream packages from using the project name. Which, tbh? Sucks. A lot. It's very clearly an antithesis to the foss spirit but hey! Devs are busy enough without having to deal with this bs. And the way distros act it doesn't look like they're leaving ppl much of a choice
As for Brodie's question: I tend to use upstream packages whenever possible, one of the first things I do on a fresh install is nuking my browser and libreoffice installs and going to download the upstream ver lol. If I can't I look to see if the app version is up to date, if yes, I go Upstream.
Copyright is not the same as a trademark (copyright covers the actual code, while trademark the name), copyright protections in foss are only meant to prevent someone from turning a foss project proprietary ("copyleft") which would be possible if everything was public domain, if you want strong trademark protection mozilla public license already does that, from my understanding there's nothing stopping devs from just stating "issues should be first reported downstream and only then escalated upstream", and making packagers replace the support link if it's a super old release.
@@thelakeman2538 right. Didn't think of the terminology lol. As for the mpl, yeah. It's one of my favourite licenses exactly because of the trademark protection. But afaik it doesn't prevent you using the name of you simply repackage without modifying the code(maybe if you use a different version but I'm not sure) and that's what will need to happen in a case of a licence looking to combat this behaviour.
As for disabling links and all. Yeah, that's the bottles approach. And unfortunately it got them a bunch of flack.
How .... how did the dev get that message to print? Like, how does an old package "know" it's old?
Just a if ( today date - package build date ) > 1 year?
I'm just curious lol
What you said, but 60 days. Also, good luck if upstream releases a version every 60 days. I don't think any downstream has the message enabled.
@@Braiam Hshaha. I'm sure the dev adding something like that has a cron job if (today - last commit) > 55 days make an empty commit.
Dev be like I'm 4 universes ahead of you
like 99 times out of 100 when i encounter a bug, i go search for it, then ask my distro's users, then probably just give up and use something else. so this "YOU DISTRO SUCKS, GO USE SOMETHINGS ESLE" would bug the fuck out of me. in case with debian, its whole idea is to not get major feature updates, so i understand why they never updated the package
Surprised they didn't propose the 'MIT F You' license, preventing any distro from modifying the source code to remove the warning.
I run Debian. I don't agree that 2 years is out of date. I do think sending a bug report for old versions of software is brain dead. I agree with Peter Nowee saying the warning should be removed if its allowed by the license.
As someone forced to use RHEL at work, I'd never considered Debian to be "ancient". It's definitely not arch or even Fedora, but ancient? I suppose it's all relative. I think Debian should have updated the package and placed it in backports, but after Jamie's comments, I probably would've deleted the warning just for spite. I get his position, but being an asshole is a great way to ensure I'll act in kind.
I am going to go send this guy an old bug report
on arch, if it's a -git package (most of the manually installed packages I use) and it's not a pkgbuild problem, I'll usually go to the upstream. Otherwise I'll go to the arch forums.
A better solution could be having a setting to override the check (something like a "do not show this again" option) and allowing distro maintainers to default it to enabled for these "stable" distros.
Current Github, and I hope most of the Application Lifecycle Management/bug tracker software, allows to set a template or a disclaimer every time a user submit a bug report and there you should ask for the version and hopefully inform the user how to tell the running version of your software
I'm gonna install Xcreensaver from source, but remove the message and make an AUR package that's always up to date while i'm using nobara under wayland
Recently, I tried to reinstall Fedora 40. the installation did not go properly multiple times. I thought it was my laptop's mistake or mine. After installing fedora with a lot of patience, I have logged in. Then running the dnf upgrade command, solved my problem. Until then the fedora on my laptop was a mess.
i hate the fact that Arch to this day ships LLVM toolchain of version 16, when version 18 is already out or is being worked on.
i am not going to lie ... I like this developer .. I totally get it ... I also think people who say are running Debian STABLE ... know that some of this may happen. I'd (JUST CURIOUS) be curious if say it was out of date in Stable but somewhat up to date in Testing or Sid.
Sid is basically rolling-release bleeding edge, so it would be running the most up-to-date version of xScreensaver, but being rolling-release means you should probably be somewhat technically savvy in order to deal with the inevitable issues that pop up. I run a rolling release distro (arch btw) but i also understand it is very not for everyone. I wouldn't want grandma and her cat videos to be wiped out by an update to gnome that wipes out her DE because somehow she messed up part of the update process.
If I run into a bug on my Debian-based main system, I usually first confirm it in the newest or at least a rather new version of the project. I have dedicated Arch and Fedora computers for that purpose of testing. Then I report it upstream right to the developer. That's the way it should be done everytime in my opinion and has yielded very fast fixes from the devs almost everytime.
I work in software development and 2nd/3rd level support myself, so that probably helps :)
I just checked Linux Mint's package of XScreensaver, it's at version 5.45 while the current version is 6.08
No surprise there, Mint's version of ScummVM is just about that old too.
Linux Mint is based on Ubuntu, All packages (except some packages like FireFox from Mint's repo) you see is on Ubuntu's repo.
Damn that is old. I am on Debian 12 and the xscreenserver version is 6.06 (11-Dec-2022). Seems to be a problam when the distro is based on a disto that is based on a distro.
How insane is it that we have people so insistent on running old, out of date, buggy versions of a piece of software that they would remove a developer's warning instead of just updating the fuckin' package?
Here's an idea put in the license that redistributors must either keep the package up to date or rebrand it. That way users with an outdated version looking for where to file a bug report would not find the upstream project, because they would be looking for it under a different name.
I don't think that would work for everything. Redhat maintains the versions that they ship with for the entire history of that release. They don't do "upgrades" to the latest version but backport security fixes in order to give enterprises a stable server platform. You wouldn't want your bank constantly upgrading to the latest and greatest and risking software or code just randomly breaking all the time would you?
@@meomniplex yeah, you're right, thats why i dont ser using fedora and debian/Ubuntu in personal space with good eyes, rhel and debian derived distros shoud be used only in Server and corporative scenarios.
I wonder if that would work and if the software could even be called "GPL and compatible" anymore.
@@meomniplex Fair point. Instead of completely changing the name ... perhaps appending _[Distro Acronym]-[Release]f to the end of the package indicating that it has been forked (and by whom) to be an acceptable compromise? (Ie Package_[RHEL8]-[LTS]f)
That sounds like a variant of the Hot Potato license, which Brodie talked about a while ago, and which I really like for this use-case.
Can't belive that people are even still using screen savers. Just have the display turn itself off. Screen savers was someting that was made way back in the day to avoid burn-in on CRT's, when they came with a mechanical off switch and no standby feature.
damn dude, how did you read that without cracking up?
"Dispense with the horse shit"
I'm no longer among the living.
debian is genuinely insane.
KDE 5.27.5 is the current version available in Debian yet KDE 5.27.10 which contains basically only bugfixes is out.
Debian will never update even though the release can be built using the same build system they already use and just fixes bugs.
Debian is not stable, Debian is stale.
Linux should have a notion of "system packages" and "apps"/"user packages".
Not shoehorned in, but kernelwide.
@@卛 kernel-wide, there are no "system packages", period. There's an executable, it can execute it. Everything else is not kernel. The package manager is and will forever be responsible for this.
debian even ignore hotfix versions often. they are really dumb
The reason is that most upstream maintainers mix bug fixes with new features. Debian has a policy of bug fixes only on stable releases.
The issue is upstream does not want to stand by their old software releases.
@@qlx-i userspace then.
I don't know if the new version of XScreensaver has dependencies with versions that aren't yet in Debian Stable or Debian testing or if it can work with the current Kernel's version. So I get the maintainer's point.
So... which are the distros that don't do that? I friend is going to ask me what distro to install since Steam has died in win7 and would be nice to know a good one.
Unrelated to the video itself: I'm a huge fan of Xscreensaver since I switched to Linux in 2010 and I just now read about it's creator Jamie Zawinski. I must say when I was indifferent on which side I stand on this topic, now I'd say Jamie is my man. Defenitely a character but a huge name and contributor to the FOSS world. Check him out! He has a Wikipedia entry and a personal website.
Edit: Also he hates Windows with a passion for personal reasons. I support his stance to the fullest :).
He uses mac os and is a bit of an asshole (sometimes)
@@joshix833You said the same thing twice.
@@joshix833 yeah you get that almost inevitably when you keep having the same arguments repeatedly, being an arsehole I mean there's no excuse for MacOS.
The only advantage of closed source is that all the bitching it’s going behind closed doors.
I consider this code, intended to explode into the face of those who work to create a nice stable distro, a "timebomb" and it makes the upstream untrustworthy.
Maybe Debian’s maintainers should stop packaging out of date packages and blaming upstream for not supporting their specific use case.
Upgrade to Arch?
Open Source devs are saints, I could never deal with this shit and would just abandon the project.
I run arch, so going straight to upstream is usually fine.
I do of course search first, I don't want to be that guy that makes a duplicate bug, especially if old.
they compiled the thing with the warning removed ?
could they have not compiled the most recent version then ?
Feature freeze distros don't ship recent upstream versions after the distro freeze date and only backporting the fixes, that's their policy.
Issue Templates + disclaimer to not report issues from old versions. Ignore issues that don't follow the template? ;-;
Now with xscreensaver the developer may get away with it.
But if you are running a "stable" distro for whatever reason, updating an application that may be "Out of date" is very risky business, if you go down the dependency chain, you risk having to update a lot of the components and that can break other stuff.
As the distro maintainer may only have certified that specific version of the entire chain.
If I am then served a warning like this, and get a snarky reply from the developer and told to update said application and dependencies.
I think my response is to grab the source for that specific version that runs on the same dependencies that my distro ships, edit it to strip the warning, compile and run, take a screenshot where the warning is missing and send it to the developer as a reply and then close it.
In the Linux ecosystem, you can't expect everyone and every distro to always package the latest version, so if they report a bug, on an old version.
The PROPER developer response should be "Oh, your distro has version X, this bug was fixed in version Y. So either your distro needs to update their version, or you need to switch to a newer version. But be advised that dependencies changed at version Z, so an earlier version before this change should work in place."
Then run that copy pasta, or link to where that answer is in your bug tracker, unreasonable users will always be unreasonable, but reasonable people are given a choice, either take the version before dependency changes, live with the bug or try your luck at library dependency bingo in the worst case.
or they can just remove the package
@@formbi The developer does not provide a .deb package of xscreensaver AFAIK, so there is no real way for users to get it them. Yes, some could compile from source, but not everyone and especially if the latest version depends on something that the current system does not have.
The proper developer response is "go tell the person who gave this software to you". They don't tell you to update, they don't tell you not to update, they don't tell you to compile from source and they don't give you a package. Then you go to the person you should have gone to in the first place: the maintainer who gave you the package.
The maintainer can deal with it, and if it's something upstream needs to know about, they report it to upstream themselves.
The actual proper response is "here are the patch for A bug, B bug and C bug, identify which of those your users are complaining about and backport it". Guess what this specific upstream doesn't do. Heck, Postfix is a saint compared to what upstream does here.
What about fedora? Are the packages recent enough there?
what happens if someone uninstalls the package on their own computer, downloads latest source, build and install it in debian or ubuntu? is it easy to do that?
What happens is that they then run up to date software. Building instructions are in the readme that is included when you download the source.
@@AbteilungsleiterinBeiAntifaEV yeah, and most of the time you'd just need to do 'make' and then 'make install'
What happens is that it may initially appear to work: then break when you try to update the system.
You need to build you own local package for it to work properly.
Project to see the current version vs. what the distro shipped. I'll then do the distro route and bug them and if they can't fix then I'll go to the dev project and just grab src. I don't fear compiling from src since it's all I did from '95 - '05 :D
I don't use Debian but you can edit the apt configuration to pull from unstable whatever package you want.
Praising people being assholes, it's one of many things wrong with this community.
Being an ass is never a good thing
I'd rather people be an ass if they're an ass than pretend to be nice only to stab you in the back later
@@BrodieRobertson Or just don't be an ass or at the very least don't praise people for being "honest assholes"
And this is why no one is amazed when someone says they are a software developer. The normies automatically think you are an social inept a-hole that thinks their terrible documentation is perfect because they think the normies should have the same level of programming skill as they do.
If you want users to use the latest version - provide the packages yourself. Wine does that for example, I can go and install the latest version instead o the one that came with Ubuntu or Debian.
Debian has a release schedule that results in older versions being shipped - that is a good thing IMO and it is one of the reasons I use Debian for my servers (and it is usually one version behind the latest, at least for important stuff). If they made an exception for xscreensaver, then soon they would have to make exceptions for other packages (what if the latest version of xscreensaver depends on the latest version of some library etc?) and Debian will just turn into Ubuntu.
The idea of a stable distribution is that it is, well, stable, not chasing the latest versions and the latest features. The same is with Debian and with RHEL (or at least it was with CentOS while that was still a thing - usually CentOS using even older versions than Debian). If I want a newer version of some package, I can try to get it from the developer (like Wine) or from backports (like zfs), though I really try to avoid compiling it.
Ubuntu's LTS model makes a lot of sense though. One version (LTS) is stable and the other is potentially less stable but with the benefit of newer software. I can't think of a better way to do it.
@@SprocketWatchclockFor that there's debian unstable. That's what ubuntu mirrors.
"If they made an exception for xscreensaver,"
They do make exceptions already though - for instance, the current version of firefox available in Buster, Bullseye and Bookworm is 115.6.0-ESR - which was released on December 19th. Similarly, Bullseye and Bookworm both provide the latest version of Chromium. Debian doesn't ship a 2+ year old browser and it would be utterly insane if it did.
I don't see any reason why xscreensaver would need to be held back in a "stable" distro, nor any reason why it would be beneficial to do so. In the event of current versions depending on a new version of a library, then sure - hold it back (I assume that's why Chromium in Buster is only on version 90 and not 120 while firefox has been updated to the latest ESR). But that's not happening here.
@@masaufuku1735 However, at the same time there is no need to have the latest xscreensaver version. Having the latest browser version may be important for security. Screen saver? Probably not so much.
Debian updates the packages when it is important, for example firefox. Updating xscreensaver just because of the nag message probably is not important. If there was a security issue with the version in debian, I am sure it would either be patched or a newer version would be packaged. I do not think that the reason that the dev has thing against old software (really, the website for xscreensaver gives a 403 if it detects an older browser version - it's "botnet protection", because, you know, botnets cannot change the user agent string, right?) is valid enough.
So the dev has to build packages for all distros? Yeah, right... Have you thought at least twice what does that mean? Also as others said, check your beloved stable inmutable distro, see the versions of chrome ,firefox,openssh.... Oh, strange... 6 months old? 1month old?