this post was submitted on 05 May 2024
680 points (93.8% liked)
linuxmemes
21251 readers
1492 users here now
Hint: :q!
Sister communities:
- LemmyMemes: Memes
- LemmyShitpost: Anything and everything goes.
- RISA: Star Trek memes and shitposts
Community rules (click to expand)
1. Follow the site-wide rules
- Instance-wide TOS: https://legal.lemmy.world/tos/
- Lemmy code of conduct: https://join-lemmy.org/docs/code_of_conduct.html
2. Be civil
- Understand the difference between a joke and an insult.
- Do not harrass or attack members of the community for any reason.
- Leave remarks of "peasantry" to the PCMR community. If you dislike an OS/service/application, attack the thing you dislike, not the individuals who use it. Some people may not have a choice.
- Bigotry will not be tolerated.
- These rules are somewhat loosened when the subject is a public figure. Still, do not attack their person or incite harrassment.
3. Post Linux-related content
- Including Unix and BSD.
- Non-Linux content is acceptable as long as it makes a reference to Linux. For example, the poorly made mockery of
sudoin Windows. - No porn. Even if you watch it on a Linux machine.
4. No recent reposts
- Everybody uses Arch btw, can't quit Vim, and wants to interject for a moment. You can stop now.
Please report posts and comments that break these rules!
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
I am learning flatpak. Can someone explain why is like that???
Well, one part of it is that Flatpak pulls data over the network, and sometimes data sent over a network doesn't arrive in the exact same shape as when it left the original system, which results in that same data being sent in multiple copies - until one manages to arrive correctly.
I think this is actually very unlikely, flatpak is most likely using some TCP based protocol and TCP would take care of this transparently, flatpak wouldn't know if any packets had to be retransmitted.
But it's unlikely those would look like this. Flatpak would only see packets in series, so the only effect a failure could have would be the need for resuming the download - at worst you could receive a couple of bytes again due to alignment, but not this much.
Could also be that the HTTP server lied about the content length.
It's a protocol violation to do that, not least because it precludes connection reuse
Hence why Fedora Linux actually recently removed delta updates for DNF. Turns out it used more data in retries than just downloading a whole package again.
Interesting, didnt know that! That sounds like a fixable issue though...
I think they have moved from trying to fix it in DNF, to using the capabilities found in BTRFS for Copy on write. Can't quite remember exactly.
?????? Retransmitted packets don't get counted towards downloaded file size
something something ostree and how complicated the stuff it does actually is
I mean ostree is just git for binaries, isnt it?
But it will likely be the issue here.
Shoddy implementation they can't be arsed to fix. They do all kinds of shenanigans like show the size of all locales but only download one, or the other way around, it does not count dependencies and then realizes it has to download something extra etc. It's all over the place and I've given up on it making any sense. I've just made sure it's on a drive with plenty of space and hope for the best.