5 ms·

This is a general Linux distro problem, which is entirely self-inflicted. The distro should only carry the software for the OS itself and any applications for t

by Asooka 2y ago

This is a general Linux distro problem, which is entirely self-inflicted. The distro should only carry the software for the OS itself and any applications for the user should come with all their dependencies, like on Windows. Yes, it kind of sucks that I have 3 copies of Chrome (Electron) and 7 copies of Qt on my Windows system, but that sure works a hell of a lot better than trying to synchronise the dependencies of a dozen applications. The precise split between OS service and user application can be argued endlessly, but that's for the maintainers to decide. The OS should not be a vehicle for delivering enduser applications. Yes, some applications should remain as a nice courtesy (e.g. GNU chess), but the rest should be dropped. Basically the split should be "does this project want to commit to working with major distros to keep its dependencies reasonable". I really hope we can move most Linux software to flatpak and have it updated and maintained separately from the OS. After decades of running both Linux and Windows, the Windows model of an application coming with all its dependencies in a single folder really is a lot better.

yjftsjthsd-h 2y ago
> Yes, it kind of sucks that I have 3 copies of Chrome (Electron) and 7 copies of Qt on my Windows system, but that sure works a hell of a lot better than trying to synchronise the dependencies of a dozen applications. Does it? Even if 2 of those chromiums and all of the QTs have actively exploited vulnerabilities and it's anyone's guess if/when the application authors might bother updating?
- Xylakant 2y ago
  A common downside is that the distribution picks the lowest common denominator of some dependency and all apps that require a newer version are held behind. That version may well be out of support and not receive fixes at all any more, which leaves the burden of maintenance on the distribution. Depending on the package maintainer, results may vary. (We sysadmins still remember debians effort to backport a fix to OpenSSL and breaking key generation.) This is clearly a tradeoff with no easy win for either side.
  - vbezhenar 2y ago
    Another downside might be that developer just does not test his software with OS-supplied library versions. So it can cause all the kinds of bugs. There's a reason why containers won in server-side development.
    - yjftsjthsd-h 2y ago
      That's why distros (at least of the kind that Debian is) aim to do everything themselves; they mirror upstream code ( https://sources.debian.org/ https://sources.debian.org/ ), they write their own packaging scripts, they test the whole thing together, and then they handle problems in-house ( https://www.debian.org/Bugs/Reporting https://www.debian.org/Bugs/Reporting ). The upstream developer shouldn't need to have done any of this themselves.
  - Arnavion 2y ago
    That is a problem for LTS distributions. Rolling distributions do not have this problem.
    - yjftsjthsd-h 2y ago
      I don't think that's true? If packages foo and bar both need libbaz, and foo always uses the latest version of libbaz but bar doesn't, you're going to have a conflict no matter whether you're rolling or not. If anything, a slow-moving release-based distro could have an easier time if they can fudge versions to get an older version of foo that overlaps dependencies with bar.
      - Arnavion 2y ago
        When the situation you describe happens, the easiest thing for the distro to do is to make the two versions of libbaz coinstallable via different package names, different sonames, etc. This is how every distro, LTS or rolling, handled openssl 1.0 vs 1.1 vs 3 for example. Regardless, the original point was: >>That version may well be out of support and not receive fixes at all any more, which leaves the burden of maintenance on the distribution. ... and my response that this is only a problem for LTS distros stands. A rolling release distro will not get in the business of maintaining packages after upstream dropped support. It is only done by LTS distros, because the whole point of LTS distros is that their packages must be kept maintained and usable for N years even as upstreams lose interest and the world perishes in nuclear fire and zombies walk the Earth feasting on the brains of anyone still using outdated software. --- Now, to play devil's advocate, here's an OpenSUSE TW (rolling distro) bug that I helped investigate: https://bugzilla.opensuse.org/show_bug.cgi?id=1214003 https://bugzilla.opensuse.org/show_bug.cgi?id=1214003 . The tl;dr is that: - Chromium upstream vendors all its dependencies, but OpenSUSE forces it to compile against distribution packages. - Chromium version X compiles against vendored library version A. OpenSUSE updates its Chromium package to version X and also has library version A in its repos, so the Chromium compiled against distro library works fine. - Chromium upstream updates the vendored library to version B, and makes that change as part of Chromium version Y. OpenSUSE hasn't updated yet. - OpenSUSE updates the library package to version B. Chromium version X's package is automatically rebuilt against the new library, and it compiles fine because the API is the same. - Disaster! The semantics of the library did change between versions A and B even though the API didn't, so OpenSUSE's Chromium now segfaults due to nullptr deref. Chromium version Y contains Chromium changes to account for this difference, but the OpenSUSE build of Chromium X of course doesn't have them. You will note that this is caused by a distro compiling a package against a newer version of a dependency than upstream tested it against, not an older one, but you are otherwise welcome to draw parallels from it. In this case it was fixed by backporting the Chromium version Y change to work with library version B, and eventually the Chromium package was updated to version Y and the patch was dropped. In a hypothetical scenario where Chromium could not be updated nor patched (say the patch was too risky), it could have worked for the distro to make the library coinstallable and then have Chromium use library version A while everything else uses version B.
- vlovich123 2y ago
  MacOS and Windows both seem to do quite well actually on this front. You should have OS-level defense mechanisms rather than trying to keep every single application secure. For example, qBitTorrent didn’t verify HTTPS certs for something like a decade. It’s really difficult to keep everything patched when it’s your full time job. When it’s arbitrary users with a mix of technical abilities and understandings of the issue it’s a much worse problem.
  - yjftsjthsd-h 2y ago
    Isn't that an argument that macOS/Windows aren't doing so well? On Debian, I can run `apt upgrade` and patch every single program. On Windows, I have to have a bunch of updater background processes and that still doesn't cover everything.
    - vlovich123 2y ago
      If you think that that gets you the latest patches to all possible software you may have installed, you may want to avoid people offering to sell you bridges. It’s an illusion - you’re relying on the best effort of volunteers “maintaining” an insane amount of software packages (both from bugs and security and often ignoring upstream or even having upstream treat them as outsourced support). I would point you to qBitTorrent having a 10 year bug where they didn’t verify SSL certs as an example of the kinds of bugs that you need broader in depth security mechanisms to keep you safe.
  - LtWorf 2y ago
    Possibly the not trying to keep applications secure explains why those systems get hacked all the time?
    - vlovich123 2y ago
      Far more reasonable explanation is that the addressable market for Windows and iOS is much larger and more lucrative - iOS exploits go for six figures whereas Linux exploits don’t generally go for as much. And exploits for Chrome and Safari go for a lot for similar reasons. No piece of software is likely to really be safe from a super determined and well funded adversary, and that’s why you need ways of structuring things (eg VMs, containers, peer ssl etc) to make things safer. If Linux had anywhere near the market share of those OSes you would see much more publicly the problems of how Debian and other distros choose to maintain those OSes.
- woodruffw 2y ago
  The problem here is ultimately visibility and actionability: half a dozen binaries with known vulnerabilities isn't much better than a single distribution one, if the distribution isn't (or can't) provide security updates. Or, as another framing: everything about user-side packaging cuts both ways: it's both a source of new dependency and vulnerability tracking woes, and it's a significant accelerant to the process of getting patched versions into place. Good and bad.
forrestthewoods 2y ago
You’re getting downvoted but you’re not wrong. The Linux Distro model of a single global shared library is a bad and wrong design in 2024. In fact it’s so bad and wrong that everyone is forced to use tools like Docker to work around the broken design.
- LtWorf 2y ago
  I guess you're running vulnerable software happily :)
LtWorf 2y ago
> any applications for the user should come with all their dependencies, like on Windows Because that works so well on windows right?
oneshtein 2y ago
> any applications for the user should come with all their dependencies, like on Windows s/dependencies/security holes/g
tuna74 2y ago
"The distro should only carry the software for the OS itself and any applications for the user should come with all their dependencies, like on Windows." You can run distros/OS that works as you like. Other people can run other OS that works like they want.

by Asooka 2y ago

yjftsjthsd-h 2y ago

> Yes, it kind of sucks that I have 3 copies of Chrome (Electron) and 7 copies of Qt on my Windows system, but that sure works a hell of a lot better than trying to synchronise the dependencies of a dozen applications. Does it? Even if 2 of those chromiums and all of the QTs have actively exploited vulnerabilities and it's anyone's guess if/when the application authors might bother updating?

Xylakant 2y ago
A common downside is that the distribution picks the lowest common denominator of some dependency and all apps that require a newer version are held behind. That version may well be out of support and not receive fixes at all any more, which leaves the burden of maintenance on the distribution. Depending on the package maintainer, results may vary. (We sysadmins still remember debians effort to backport a fix to OpenSSL and breaking key generation.) This is clearly a tradeoff with no easy win for either side.
- vbezhenar 2y ago
  Another downside might be that developer just does not test his software with OS-supplied library versions. So it can cause all the kinds of bugs. There's a reason why containers won in server-side development.
  - yjftsjthsd-h 2y ago
    That's why distros (at least of the kind that Debian is) aim to do everything themselves; they mirror upstream code ( https://sources.debian.org/ https://sources.debian.org/ ), they write their own packaging scripts, they test the whole thing together, and then they handle problems in-house ( https://www.debian.org/Bugs/Reporting https://www.debian.org/Bugs/Reporting ). The upstream developer shouldn't need to have done any of this themselves.
- Arnavion 2y ago
  That is a problem for LTS distributions. Rolling distributions do not have this problem.
  - yjftsjthsd-h 2y ago
    I don't think that's true? If packages foo and bar both need libbaz, and foo always uses the latest version of libbaz but bar doesn't, you're going to have a conflict no matter whether you're rolling or not. If anything, a slow-moving release-based distro could have an easier time if they can fudge versions to get an older version of foo that overlaps dependencies with bar.
    - Arnavion 2y ago
      When the situation you describe happens, the easiest thing for the distro to do is to make the two versions of libbaz coinstallable via different package names, different sonames, etc. This is how every distro, LTS or rolling, handled openssl 1.0 vs 1.1 vs 3 for example. Regardless, the original point was: >>That version may well be out of support and not receive fixes at all any more, which leaves the burden of maintenance on the distribution. ... and my response that this is only a problem for LTS distros stands. A rolling release distro will not get in the business of maintaining packages after upstream dropped support. It is only done by LTS distros, because the whole point of LTS distros is that their packages must be kept maintained and usable for N years even as upstreams lose interest and the world perishes in nuclear fire and zombies walk the Earth feasting on the brains of anyone still using outdated software. --- Now, to play devil's advocate, here's an OpenSUSE TW (rolling distro) bug that I helped investigate: https://bugzilla.opensuse.org/show_bug.cgi?id=1214003 https://bugzilla.opensuse.org/show_bug.cgi?id=1214003 . The tl;dr is that: - Chromium upstream vendors all its dependencies, but OpenSUSE forces it to compile against distribution packages. - Chromium version X compiles against vendored library version A. OpenSUSE updates its Chromium package to version X and also has library version A in its repos, so the Chromium compiled against distro library works fine. - Chromium upstream updates the vendored library to version B, and makes that change as part of Chromium version Y. OpenSUSE hasn't updated yet. - OpenSUSE updates the library package to version B. Chromium version X's package is automatically rebuilt against the new library, and it compiles fine because the API is the same. - Disaster! The semantics of the library did change between versions A and B even though the API didn't, so OpenSUSE's Chromium now segfaults due to nullptr deref. Chromium version Y contains Chromium changes to account for this difference, but the OpenSUSE build of Chromium X of course doesn't have them. You will note that this is caused by a distro compiling a package against a newer version of a dependency than upstream tested it against, not an older one, but you are otherwise welcome to draw parallels from it. In this case it was fixed by backporting the Chromium version Y change to work with library version B, and eventually the Chromium package was updated to version Y and the patch was dropped. In a hypothetical scenario where Chromium could not be updated nor patched (say the patch was too risky), it could have worked for the distro to make the library coinstallable and then have Chromium use library version A while everything else uses version B.
vlovich123 2y ago
MacOS and Windows both seem to do quite well actually on this front. You should have OS-level defense mechanisms rather than trying to keep every single application secure. For example, qBitTorrent didn’t verify HTTPS certs for something like a decade. It’s really difficult to keep everything patched when it’s your full time job. When it’s arbitrary users with a mix of technical abilities and understandings of the issue it’s a much worse problem.
- yjftsjthsd-h 2y ago
  Isn't that an argument that macOS/Windows aren't doing so well? On Debian, I can run `apt upgrade` and patch every single program. On Windows, I have to have a bunch of updater background processes and that still doesn't cover everything.
  - vlovich123 2y ago
    If you think that that gets you the latest patches to all possible software you may have installed, you may want to avoid people offering to sell you bridges. It’s an illusion - you’re relying on the best effort of volunteers “maintaining” an insane amount of software packages (both from bugs and security and often ignoring upstream or even having upstream treat them as outsourced support). I would point you to qBitTorrent having a 10 year bug where they didn’t verify SSL certs as an example of the kinds of bugs that you need broader in depth security mechanisms to keep you safe.
- LtWorf 2y ago
  Possibly the not trying to keep applications secure explains why those systems get hacked all the time?
  - vlovich123 2y ago
    Far more reasonable explanation is that the addressable market for Windows and iOS is much larger and more lucrative - iOS exploits go for six figures whereas Linux exploits don’t generally go for as much. And exploits for Chrome and Safari go for a lot for similar reasons. No piece of software is likely to really be safe from a super determined and well funded adversary, and that’s why you need ways of structuring things (eg VMs, containers, peer ssl etc) to make things safer. If Linux had anywhere near the market share of those OSes you would see much more publicly the problems of how Debian and other distros choose to maintain those OSes.
woodruffw 2y ago
The problem here is ultimately visibility and actionability: half a dozen binaries with known vulnerabilities isn't much better than a single distribution one, if the distribution isn't (or can't) provide security updates. Or, as another framing: everything about user-side packaging cuts both ways: it's both a source of new dependency and vulnerability tracking woes, and it's a significant accelerant to the process of getting patched versions into place. Good and bad.

forrestthewoods 2y ago

You’re getting downvoted but you’re not wrong. The Linux Distro model of a single global shared library is a bad and wrong design in 2024. In fact it’s so bad and wrong that everyone is forced to use tools like Docker to work around the broken design.

LtWorf 2y ago
I guess you're running vulnerable software happily :)

LtWorf 2y ago

> any applications for the user should come with all their dependencies, like on Windows Because that works so well on windows right?

oneshtein 2y ago

> any applications for the user should come with all their dependencies, like on Windows s/dependencies/security holes/g

tuna74 2y ago

"The distro should only carry the software for the OS itself and any applications for the user should come with all their dependencies, like on Windows." You can run distros/OS that works as you like. Other people can run other OS that works like they want.