523
Arch be Like (lemmy.ml)
submitted 11 months ago by to c/linuxmemes@lemmy.world
45 comments fedilink hide all child comments
 
A meme styled like the “I receive / you receive” Meme format. At the top, it says “Starting full system upgrade…”. On the left, under “I receive,” it says “Total Download Size: 5982.67 MiB” and “Total Installed Size: 22816.87 MiB.” On the right, under “You receive,” it says “Net Upgrade Size: –699.29 MiB,” making fun of the fact that Arch updates often reduce used space even though multiple gigabytes may be downloaded
you are viewing a single comment's thread
view the rest of the comments
[–] 13 points 11 months ago (17 children)

Download of 6GB is wild, is that re-downloading the entire package for each one that needs an update? Shouldn't it be more efficient to download only the changes and patch the existing files?

At this point it seems like my desktop Linux install needs as much space and bandwidth than windows does.

  • permalink
  • fedilink
  • source
  • hideshow 17 child comments
    •
  • [–] 16 points 11 months ago (10 children)

    Patching means rebuilding. And packagers don't really publish diffs. So it's use all your bandwidth instead!

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 10 child comments
    •
  • [–] 28 points 11 months ago (8 children)

    Which is WAY more economical.

    Rebuilding packages takes a lot of compute. Downloading mostly requires just flashing some very small lights very quickly.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 8 child comments
    •
  • [–] 6 points 11 months ago (1 child)

    If you have multiple computers, you can always set up a caching proxy so you only have to download the packages once.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 1 point 11 months ago

    That reminds me of Chaotic AUR, though it’s an online public repo. It automatically builds popular AUR packages and lets you download the binaries.

    It sometimes builds against outdated libraries/dependencies though, so for pre-release software I’ve sometimes had to download and compile it locally still. Also you can’t make any patches or move to an old commit, like you can with normal AUR packages.

    I’ve found it’s better to use Arch Linux’s official packages when I can, though, since they always publish binaries built with the same latest-release dependencies. I haven’t had dependency version issues with that, as long as I’ve avoided partial upgrades.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 3 points 11 months ago (5 children)

    Yeah, totally is. There's a reason nobody publishes diffs

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 5 child comments
    •
  • [–] 2 points 11 months ago (4 children)

    openSUSE Leap does have differential package updates. Pretty sure, I once saw it on one of the Red-Hat-likes, too.

    But yeah, it makes most sense on slow-moving, versioned releases with corporate backing.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] 2 points 11 months ago (3 children)

    Ooh, got any links on how Leap does this? My searching isn't yielding much

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [–] 2 points 11 months ago (2 children)

    Had to search for a bit, too, but finally found the relevant keyword: Delta RPMs
    (Which also explains why it's a Red Hat / SUSE thing. 😅)

    Here's a decent article, which links to some more in-depth explanations: https://www.certdepot.net/rhel7-get-started-delta-rpms/

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 5 points 11 months ago (3 children)

    This doesn't work too well for rolling releases, because users will quickly get several version jumps behind.

    For example, let's say libbanana is currently at version 1.2.1, but then releases 1.2.2, which you ship as a distro right away, but then a few days later, they've already released 1.2.3, which you ship, too.
    Now Agnes comes home at the weekend and runs package updates on her system, which is still on libbanana v1.2.1. At that point, she would need the diffs 1.2.1→1.2.2 and then 1.2.2→1.2.3 separately, which may have overlaps in which files changed.

    In principle, you could additionally provide the diff 1.2.1→1.2.3, but if Greg updates only every other weekend, and libbanana celebrates the 1.3.0 release by then, then you will also need the diffs 1.2.1→1.3.0, 1.2.2→1.3.0 and 1.2.3→1.3.0. So, this strategy quickly explodes with the number of different diffs you might need.

    At that point, just not bothering with diffs and making users always download the new package version in full is generally preferred.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [–] 2 points 11 months ago (2 children)

    Interesting, it wouldn't work like rsync where it compares the new files to the old ones and transfers the parts that have changed?

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 1 point 11 months ago (1 child)

    Hmm, good question. I know of one such implementation, which is Delta RPM, which works the way I described it.
    But I'm not sure, if they just designed it to fit into the current architecture, where all their mirrors and such were set up to deal with package files.

    I could imagine that doing it rsync-style would be really terrible for server load, since you can't really cache things at that point...

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 3 points 11 months ago

    Shouldn't it be more efficient to download only the changes and patch the existing files?

    As people mentioned, that becomes problematic with a distro like arch. You could easily be jumping 5-6 versions with an update, with some more busy packages and updating less frequently. This means you need to go through the diffs in order, and you need to actually keep those diffs available.

    This actually poses two issues, and the first one is that software usually isn't built for this kind of binary stability - anything compiled/autogenerated might change a lot with a small source change, and even just compressing data files will mess it up. Because of that, a diff/delta might end up not saving much space, and going through multiple of them could end up bigger than just a direct download of the files.

    And the second issue is, mirrors - mirrors need to store and provide a lot of data, and they're not controlled by the distribution. Presumably to save on space, they quickly remove older package versions - and when I say older, I mean potentially less than a week old. In order for diffs/deltas to work, you'd need the mirrors to not only store the full package files they already do (for any new installs), but now also store deltas for N days back, and they'd only be useful to people who update more often than every N days.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 1 point 11 months ago

    No, that's not how compiling works. And yes, 6GB is wild. If I don't patch in a month, the download might be 2GB and the net will still be smaller.

    I don't think I could get close to my Windows installation even if I installed literally every single package..

  • permalink
  • fedilink
  • source
  • parent