7 ms·

“Storage is cheap” goes the saying. Other people’s storage has a cost of zero, so why not just fill it up with 100 copies of the same dependency. These package

“Storage is cheap” goes the saying. Other people’s storage has a cost of zero, so why not just fill it up with 100 copies of the same dependency. These package formats (I’m looking at you snap as well) are disrespectful of users’ computers to the point of creating a problem where due to size, things take so long and bog the computer down so much, that the resource being used is no longer storage, but time (system and human time). And THAT is not cheap at all. Don’t believe me, install a few dozen snaps, turn the computer off for a week, and watch in amazement as you turn it back on and see it brought to its knees as your computer and network are taxed to the max downloading and applying updates.

m4rtink 1y ago
Snaps do zero deduplication and bundle everything AFAIK - flatpak at least does some deduplication on file level and has shared runtimes.
- brlin2021 1y ago
  This statement is false as snaps also have shared runtimes known as "content snaps". A common example is the ones with the gnome- prefix and the ones that end with -themes suffix.
  - loloquwowndueo 1y ago
    Wherein snaps found themselves reinventing shared libraries - at which point, what’s really the point.
    - Seattle3503 1y ago
      I think the point is that maintainers and developers now have a choice of whether they want to share libraries or not. Before the only choice was to share dependencies.
      - hedora 1y ago
        There has been a choice between shared and static linking since before the Linux kernel existed. What system are you talking about?
        patrakov 1y ago
        Any modern distro. Static libraries are simply not built anymore, so you have nothing to link with, unless you rebuild the whole subsystem yourself.
        hedora 1y ago
        If that's true, it'll be the second thing I check after making sure a distro I'm considering isn't using systemd. Anyway, you had me worried for a minute, but: https://packages.debian.org/source/bookworm/libs/ https://packages.debian.org/source/bookworm/libs/ Click on a C library. Click on the *-dev package. There's a 1:1 mapping of .so to .a in the packages I spot checked. Now I'll go back to enjoying Devuan.
wtarreau 1y ago
Not to mention the catastrophic security that comes with these systems. On a local ubuntu, I've had exactly 4 different versions of the sudo binary. One in the host OS and 3 in different snaps (some were the same but there were a total of 4 different). If they had a reason to be different, it's likely for bug fixes, but not all of them were updated, meaning that even after my main OS was updated, there were still 3 bogus binaries exposed to users and waiting for an exploit to happen. I find that this is the most shocking aspect of these systems (and I'm really not happy with the disrespect of my storage, like you mention).
- yjftsjthsd-h 1y ago
  Why do snaps have sudo at all?
- brlin2021 1y ago
  The sudo binaries in the snaps are likely to have their SUID bit stripped, so they won't cause any trouble even if they have known vulnerabilities.
zdragnar 1y ago
It would be fantastic if there was a way for these to declare what libraries they needed bundled, and a manager that would install the necessary dependencies into a shared location, so that only what wasn't already installed got downloaded. Oh wait...
- gjsman-1000 1y ago
  Sure, but we’ve tried that technique for about 20 years. We learned that most app developers hate it; to the point they don’t even bother supporting the platform unless they are FOSS diehards. Those that do screech about not using the packaged version on almost all of their developer forums, most often because they are out of date and users blame them for bugs that were already fixed. This actually is infuriating - imagine fixing a bug, but 2 years later, the distribution isn’t shipping your update, and users are blaming you and still opening bug reports. The distribution also will not be persuaded, because it’s the “stable” branch for the next 3 years. Basically, Linux sucks terribly, either way, with app distribution. Linux distributions have nobody to blame but themselves for being ineffectual here.
  - rlpb 1y ago
    > The distribution also will not be persuaded, because it’s the “stable” branch for the next 3 years. This is exactly what users want, though. Eg. if they want to receive updates more frequently on Ubuntu then they can use the six monthly releases, but most Ubuntu users deliberately choose the LTS over that option because they don't want everything updated.
    - gjsman-1000 1y ago
      But if you’re a developer, that doesn’t change that many users do not understand, will not understand, and will open bug reports regularly. When that happens, guess what you do? You trademark your software’s name and use the law to force distributions to not package unless concessions are granted. We’re beginning to see this with OBS, but Firefox also did this for a while. As Fedora quickly found, when trademark law gets involved, any hope of forcing developers to allow packaging through a policy or opinion vote becomes hilariously, comically ineffectual. The other alternative is to just not support Linux. Almost all major software has been happily taking that path, and the whole packaging mess gives no incentive to change.
dheera 1y ago
To be fair, shared libraries have been problematic since the beginning of time. In the Python world, something wants numpy>=2.5.13, another wants numpy<=2.5.12, yet Python has still not come up with a way to just do "import numpy==2.5.13" and have it pluck exactly that version and import it. In the C++ world, I've seen code that spits out syntax errors if you use a newer version of gcc, others that spit out syntax errors if you use an older version of gcc, apt-get overwrites the shared library you depended on with a newer version, lots of other issues. Install CUDA 11.2, it tries to uninstall CUDA 11.1, never mind that you had something linked to it, and that everything else in that ecosystem disobeys semantics and doesn't work with later minor revisions. It's such a shitshow that it fully makes sense to bundle all your dependencies if you want to ship something that "just works". For your customer, storage is cheaper than employee time wasted getting something to work.
- loloquwowndueo 1y ago
  Right but snaps don’t solve dependency hell (see content snaps which are shared library bundles).
- o11c 1y ago
  That's what everybody uses `venv` for. Or `virtualenv` if you're stuck on old Python. But as a rule, `<=` dependencies mean there's either a disastrous fault with the library, or else the caller is blatantly passing all the "do not enter" signs. `!=` dependencies by contrast are meaningful just to avoid a particular bug.
  - int_19h 1y ago
    Virtual environments don't solve the problem of two dependencies that you need having conflicting requirements.
    - o11c 1y ago
      That subproblem is fundamentally unfixable unless you're willing to allow incompatible objects to be passed around, which is a really bad idea. If your code does: o = foo_v1.get_obj() foo_v2.use_obj(o) then this is almost always undefined behavior, since the authors of `foo` will almost certainly not write their APIs to accept instances with different internals.
neuroelectron 1y ago
For a long time, storage was getting cheaper all the time but we've hit scaling walls in both CPUs and drives. I remember when I was a kid and bought Mechwarrior 2 a game that could use up to 500mb! The guy working the video game locker warned me "are you sure you have enough hard drive space?" after having just bought a 2gb drive for like $60, or something, I don't remember exactly. A concern that would have been valid maybe a year earlier.
2OEH8eoCRo0 1y ago
Devil's advocate- We have hundreds of stupid distros making choices and the less I need to deal with their builds the better.
- api 1y ago
  Containerization is and always was the ultimate “fuck it” answer to these problems. “Fuck it, just distribute software in the form of tarballs of the entire OS.”
- delusional 1y ago
  Yeah, I only trust the random developers that are probably running windows to package my Linux software. The people making those "stupid distros" are (most likely by number) volunteers working hard to give us an integrated experience, and they deserve better than to be called "stupid".
  - codedokode 1y ago
    Yes but they are working in the wrong direction. Instead of trying to make ports for existing software they should just provide a standard environment for third-party apps.
    - delusional 1y ago
      How would you provide a "standard" environment when the third party apps all depend on other third party apps. What would the "standard" environment be for streamlink when it itself is part of the "standard" environment of streamlink-twitch-gui? How about curl, mpv, ffmpeg, libc? How do you evolve such a "standard" environment without the assistance of the third parties (because many of them will never help you). Debian puts in a massive effort to be a long term stable "standard" system. I've found that effort to be wasteful. I'd much rather just take the occasional (although surprisingly rare) breakage than live with the limitations of old packages. That's a matter of taste though, and greatly depends on the effort of the upstream developers.
api 1y ago
There are things like content defined chunking and content based lookup. Evidently that’s too hard.
- XorNot 1y ago
  The problem on Linux is that hard links are exactly what you don't want. If hard links from the get go were copy on write, then I suspect content defined storage would've become the standard because it would be easy. Instead we have this construct which makes it hard and dangerous (hard links hide data dependencies) on most Linux filesystems and no good answers (even ZFS can't easily handle a cp --reflink operation, and the problem is it's not the default anyway).
  - api 1y ago
    Use either symbolic links (which is fine in most cases) or overlay filesystems. I agree that hard links are usually not what you want.
throwaway314155 1y ago
> watch in amazement as you turn it back on and see it brought to its knees as your computer and network are taxed to the max downloading and applying updates. A touch overly dramatic...
- loloquwowndueo 1y ago
  If you think it’s dramatic it’s because you have never seen it happen - I have. My description is accurate :)
musicnarcoman 1y ago
"Storage is cheap" if you do not have to pay for it. It is not so cheap when you are the one paying for the organizations storage.
- CoolCold 1y ago
  You have savings from not using Windows in such a org - likely your Linux will be free or cheaper one
peter-m80 1y ago
Flatpack deduplicates dependencies and shares runtimes between apps
codedokode 1y ago
Snap/flatpak style application packaging is absolutely necessary. Please let me explain this. Every platform needs a way to distribute and install third-party applications. It is unlikely that the authors of the platform wrote all existing software so you need some way to install applications not included into an OS. On Windows, there is such a mechanism - pack your application into a large installer exe. It is awful and not secure but at least it has been working for ages. For comparison, on Linux there is no such mechanism at all. Typical Linux distribution traditionally has only two supported ways to install software: a) install more components from OS repository b) write and compile the software yourself While there is lot of third-party software for Linux, there is no universal distribution mechanism. Typically software developer only supports the release they are using. There may be ports - by other developers or by the distribution maintainers - but they are often broken and don't even start (for example, port of waydroid in Fedora). Some port installation methods are outright dangerous, for example: running a curled script through sudo or adding a third-party repository to your package manager. That is a sure method to get a broken system, and it will be totally your fault because your distribution doesn't support such installation method so you got the result that was expected. In my experience, Fedora, Ubuntu and Debian are especially bad for supporting applications other than Gimp or Libreoffice: the ports for these distributions are often broken, buggy, crash or even do not exist. For example: waydroid, carla, ardour. The reason is that there are hundreds of releases of different distributions and nobody is going to port, test and maintain all applications for all of them. So the obvious solution is to choose a standard platform and write applications against this platform. I see no other solution. If I am writing some GUI application I am not interested in learning how Linux distributions are different from each other. I would rather ship an Alpine virtual machine image and not waste my time. Flatpak/snap might become such platform but why they are so buggy? As I remember, Steam in flatpak is broken and cannot properly use GPU, VS Code is broken etc.
- loloquwowndueo 1y ago
  No, this is an orthogonal concern. Bundling all the dependencies and killing users hard disks is not a solution to the “Every platform needs a way to distribute and install third-party applications” problem. If anything the proliferation of packaging formats and useless quibbles between snap and flatpak move us farther from the solution as there are now several competing dependency-bundling installers which require installing a package handler anyway. In that respect flatpak is better because it’s more universally available than the Ubuntu-specific snaps (attempts at making snap cross-distro are laughable and failed) but it still introduces a bunch of tangential issues which are too much of a bother for the average user versus just doing “apt install” and moving on with their lives. PPAs cover this acceptably if suboptimally for Deb packages.

m4rtink 1y ago

Snaps do zero deduplication and bundle everything AFAIK - flatpak at least does some deduplication on file level and has shared runtimes.

brlin2021 1y ago
This statement is false as snaps also have shared runtimes known as "content snaps". A common example is the ones with the gnome- prefix and the ones that end with -themes suffix.
- loloquwowndueo 1y ago
  Wherein snaps found themselves reinventing shared libraries - at which point, what’s really the point.
  - Seattle3503 1y ago
    I think the point is that maintainers and developers now have a choice of whether they want to share libraries or not. Before the only choice was to share dependencies.
    - hedora 1y ago
      There has been a choice between shared and static linking since before the Linux kernel existed. What system are you talking about?
      - patrakov 1y ago
        Any modern distro. Static libraries are simply not built anymore, so you have nothing to link with, unless you rebuild the whole subsystem yourself.
        hedora 1y ago
        If that's true, it'll be the second thing I check after making sure a distro I'm considering isn't using systemd. Anyway, you had me worried for a minute, but: https://packages.debian.org/source/bookworm/libs/ https://packages.debian.org/source/bookworm/libs/ Click on a C library. Click on the *-dev package. There's a 1:1 mapping of .so to .a in the packages I spot checked. Now I'll go back to enjoying Devuan.

wtarreau 1y ago

Not to mention the catastrophic security that comes with these systems. On a local ubuntu, I've had exactly 4 different versions of the sudo binary. One in the host OS and 3 in different snaps (some were the same but there were a total of 4 different). If they had a reason to be different, it's likely for bug fixes, but not all of them were updated, meaning that even after my main OS was updated, there were still 3 bogus binaries exposed to users and waiting for an exploit to happen. I find that this is the most shocking aspect of these systems (and I'm really not happy with the disrespect of my storage, like you mention).

yjftsjthsd-h 1y ago
Why do snaps have sudo at all?
brlin2021 1y ago
The sudo binaries in the snaps are likely to have their SUID bit stripped, so they won't cause any trouble even if they have known vulnerabilities.

zdragnar 1y ago

It would be fantastic if there was a way for these to declare what libraries they needed bundled, and a manager that would install the necessary dependencies into a shared location, so that only what wasn't already installed got downloaded. Oh wait...

gjsman-1000 1y ago
Sure, but we’ve tried that technique for about 20 years. We learned that most app developers hate it; to the point they don’t even bother supporting the platform unless they are FOSS diehards. Those that do screech about not using the packaged version on almost all of their developer forums, most often because they are out of date and users blame them for bugs that were already fixed. This actually is infuriating - imagine fixing a bug, but 2 years later, the distribution isn’t shipping your update, and users are blaming you and still opening bug reports. The distribution also will not be persuaded, because it’s the “stable” branch for the next 3 years. Basically, Linux sucks terribly, either way, with app distribution. Linux distributions have nobody to blame but themselves for being ineffectual here.
- rlpb 1y ago
  > The distribution also will not be persuaded, because it’s the “stable” branch for the next 3 years. This is exactly what users want, though. Eg. if they want to receive updates more frequently on Ubuntu then they can use the six monthly releases, but most Ubuntu users deliberately choose the LTS over that option because they don't want everything updated.
  - gjsman-1000 1y ago
    But if you’re a developer, that doesn’t change that many users do not understand, will not understand, and will open bug reports regularly. When that happens, guess what you do? You trademark your software’s name and use the law to force distributions to not package unless concessions are granted. We’re beginning to see this with OBS, but Firefox also did this for a while. As Fedora quickly found, when trademark law gets involved, any hope of forcing developers to allow packaging through a policy or opinion vote becomes hilariously, comically ineffectual. The other alternative is to just not support Linux. Almost all major software has been happily taking that path, and the whole packaging mess gives no incentive to change.

dheera 1y ago

To be fair, shared libraries have been problematic since the beginning of time. In the Python world, something wants numpy>=2.5.13, another wants numpy<=2.5.12, yet Python has still not come up with a way to just do "import numpy==2.5.13" and have it pluck exactly that version and import it. In the C++ world, I've seen code that spits out syntax errors if you use a newer version of gcc, others that spit out syntax errors if you use an older version of gcc, apt-get overwrites the shared library you depended on with a newer version, lots of other issues. Install CUDA 11.2, it tries to uninstall CUDA 11.1, never mind that you had something linked to it, and that everything else in that ecosystem disobeys semantics and doesn't work with later minor revisions. It's such a shitshow that it fully makes sense to bundle all your dependencies if you want to ship something that "just works". For your customer, storage is cheaper than employee time wasted getting something to work.

loloquwowndueo 1y ago
Right but snaps don’t solve dependency hell (see content snaps which are shared library bundles).
o11c 1y ago
That's what everybody uses `venv` for. Or `virtualenv` if you're stuck on old Python. But as a rule, `<=` dependencies mean there's either a disastrous fault with the library, or else the caller is blatantly passing all the "do not enter" signs. `!=` dependencies by contrast are meaningful just to avoid a particular bug.
- int_19h 1y ago
  Virtual environments don't solve the problem of two dependencies that you need having conflicting requirements.
  - o11c 1y ago
    That subproblem is fundamentally unfixable unless you're willing to allow incompatible objects to be passed around, which is a really bad idea. If your code does: o = foo_v1.get_obj() foo_v2.use_obj(o) then this is almost always undefined behavior, since the authors of `foo` will almost certainly not write their APIs to accept instances with different internals.

neuroelectron 1y ago

For a long time, storage was getting cheaper all the time but we've hit scaling walls in both CPUs and drives. I remember when I was a kid and bought Mechwarrior 2 a game that could use up to 500mb! The guy working the video game locker warned me "are you sure you have enough hard drive space?" after having just bought a 2gb drive for like $60, or something, I don't remember exactly. A concern that would have been valid maybe a year earlier.

2OEH8eoCRo0 1y ago

Devil's advocate- We have hundreds of stupid distros making choices and the less I need to deal with their builds the better.

api 1y ago
Containerization is and always was the ultimate “fuck it” answer to these problems. “Fuck it, just distribute software in the form of tarballs of the entire OS.”
delusional 1y ago
Yeah, I only trust the random developers that are probably running windows to package my Linux software. The people making those "stupid distros" are (most likely by number) volunteers working hard to give us an integrated experience, and they deserve better than to be called "stupid".
- codedokode 1y ago
  Yes but they are working in the wrong direction. Instead of trying to make ports for existing software they should just provide a standard environment for third-party apps.
  - delusional 1y ago
    How would you provide a "standard" environment when the third party apps all depend on other third party apps. What would the "standard" environment be for streamlink when it itself is part of the "standard" environment of streamlink-twitch-gui? How about curl, mpv, ffmpeg, libc? How do you evolve such a "standard" environment without the assistance of the third parties (because many of them will never help you). Debian puts in a massive effort to be a long term stable "standard" system. I've found that effort to be wasteful. I'd much rather just take the occasional (although surprisingly rare) breakage than live with the limitations of old packages. That's a matter of taste though, and greatly depends on the effort of the upstream developers.

api 1y ago

There are things like content defined chunking and content based lookup. Evidently that’s too hard.

XorNot 1y ago
The problem on Linux is that hard links are exactly what you don't want. If hard links from the get go were copy on write, then I suspect content defined storage would've become the standard because it would be easy. Instead we have this construct which makes it hard and dangerous (hard links hide data dependencies) on most Linux filesystems and no good answers (even ZFS can't easily handle a cp --reflink operation, and the problem is it's not the default anyway).
- api 1y ago
  Use either symbolic links (which is fine in most cases) or overlay filesystems. I agree that hard links are usually not what you want.

throwaway314155 1y ago

> watch in amazement as you turn it back on and see it brought to its knees as your computer and network are taxed to the max downloading and applying updates. A touch overly dramatic...

loloquwowndueo 1y ago
If you think it’s dramatic it’s because you have never seen it happen - I have. My description is accurate :)

musicnarcoman 1y ago

"Storage is cheap" if you do not have to pay for it. It is not so cheap when you are the one paying for the organizations storage.

CoolCold 1y ago
You have savings from not using Windows in such a org - likely your Linux will be free or cheaper one

peter-m80 1y ago

Flatpack deduplicates dependencies and shares runtimes between apps

codedokode 1y ago

Snap/flatpak style application packaging is absolutely necessary. Please let me explain this. Every platform needs a way to distribute and install third-party applications. It is unlikely that the authors of the platform wrote all existing software so you need some way to install applications not included into an OS. On Windows, there is such a mechanism - pack your application into a large installer exe. It is awful and not secure but at least it has been working for ages. For comparison, on Linux there is no such mechanism at all. Typical Linux distribution traditionally has only two supported ways to install software: a) install more components from OS repository b) write and compile the software yourself While there is lot of third-party software for Linux, there is no universal distribution mechanism. Typically software developer only supports the release they are using. There may be ports - by other developers or by the distribution maintainers - but they are often broken and don't even start (for example, port of waydroid in Fedora). Some port installation methods are outright dangerous, for example: running a curled script through sudo or adding a third-party repository to your package manager. That is a sure method to get a broken system, and it will be totally your fault because your distribution doesn't support such installation method so you got the result that was expected. In my experience, Fedora, Ubuntu and Debian are especially bad for supporting applications other than Gimp or Libreoffice: the ports for these distributions are often broken, buggy, crash or even do not exist. For example: waydroid, carla, ardour. The reason is that there are hundreds of releases of different distributions and nobody is going to port, test and maintain all applications for all of them. So the obvious solution is to choose a standard platform and write applications against this platform. I see no other solution. If I am writing some GUI application I am not interested in learning how Linux distributions are different from each other. I would rather ship an Alpine virtual machine image and not waste my time. Flatpak/snap might become such platform but why they are so buggy? As I remember, Steam in flatpak is broken and cannot properly use GPU, VS Code is broken etc.

loloquwowndueo 1y ago
No, this is an orthogonal concern. Bundling all the dependencies and killing users hard disks is not a solution to the “Every platform needs a way to distribute and install third-party applications” problem. If anything the proliferation of packaging formats and useless quibbles between snap and flatpak move us farther from the solution as there are now several competing dependency-bundling installers which require installing a package handler anyway. In that respect flatpak is better because it’s more universally available than the Ubuntu-specific snaps (attempts at making snap cross-distro are laughable and failed) but it still introduces a bunch of tangential issues which are too much of a bother for the average user versus just doing “apt install” and moving on with their lives. PPAs cover this acceptably if suboptimally for Deb packages.