New F-Droid repository format for faster and smaller updates
71–80 of 146 posts
Re: New F-Droid repository format for faster and smaller updates
#72Because of perf/size issues they switched to JSON..? What were they using before?
Re: New F-Droid repository format for faster and smaller updates
#73Earlier quoted context omitted.
Ah yes, the user in the free/oss ecosystem for which all software works perfectly. :) I'm not sure if F-Droid is the buggiest app, but aside from the above 100% percent bug, had all the other issues the previous user mentioned.
Interesting that you and gp both are not seeing Fdroid update itself. Sounds kind you must both be using a custom repository that excludes updates to the F-droid app, since you've both had that same experience.
Re: New F-Droid repository format for faster and smaller updates
#74It shouldn't need to download the whole repo index for a mobile app store. It's a flawed assumption to begin with.
It's not strictly necessary, but if the entire repo can fit inside 8MiB of compressed data I can understand why they chose this rather than server-side search. That's "three clicks on Twitter" in terms of data, not exactly the end of the world, though less is always better. F-Droid's main servers are always overloaded anyway, so just sending a nice and cacheable compressed archive seems like a fine trade-off to me.
Re: New F-Droid repository format for faster and smaller updates
#75I didn't realize the app was still being worked on. It's been years since the UI update and it's always been amazingly buggy (across 3 different phone). I'm always impressed by how broken it is - especially if you have a slow connection. Downloads will randomly go into a weird frozen state where they can't be stopped. The download status will change when you change tabs/sections. Sometimes download will go past 100%…
(Edit to add:) maybe the problem is that you're not keeping it updated? As per many replies I don't recognise the buggy mess you describe.
Re: New F-Droid repository format for faster and smaller updates
#76I didn't realize the app was still being worked on. It's been years since the UI update and it's always been amazingly buggy (across 3 different phone). I'm always impressed by how broken it is - especially if you have a slow connection. Downloads will randomly go into a weird frozen state where they can't be stopped. The download status will change when you change tabs/sections. Sometimes download will go past 100%…
>I almost exclusively use FDroid, it's an amazing project. But I've never seen an app with so many issues I've used Fdroid for years, downloaded and updated apps hundreds of times across multiple devices and never encountered a single thing you described. Death, taxes, and people confidently generalizing from one-off cases of highly unusual experiences. >I didn't realize the app was still being worked on. By my count…
Re: New F-Droid repository format for faster and smaller updates
#77Earlier quoted context omitted.
I hear you on the bugs, but my main problem with it is that the search just never seems to return what I need. I don't know if it's me but I usually end up searching the internet for 'best foss android ' or so. Let's see: search for ssh (with the intent of finding an ssh client, that's not too far fetched?), these are the top matches: HACS Hackspace Access Control System, KOReader Ebook reader, AVNC VNC client, FTPCl…
Have to agree that the search function is pretty dire; it only seems to work (mostly) if you already know the name of the application for which you are searching, which defeats its purpose.
Re: New F-Droid repository format for faster and smaller updates
#78It shouldn't need to download the whole repo index for a mobile app store. It's a flawed assumption to begin with.
Your assumption on how it works is flawed to begin with. Check the comment from one of the original authors https://news.ycombinator.com/item?id=35003844
Re: New F-Droid repository format for faster and smaller updates
#79> stronger digest algorithm for repository signing: We now use SHA256 instead of SHA1 for the index signature Neither SHA-1 nor SHA-256 are signing constructs, they are hash functions. They provide integrity, not authenticity. For this kind of thing (a central authority signing and public clients verifying), you'd need a public key signature scheme, like ECDSA or EdDSA.
Well that's why they said "stronger digest algorithm". As far as I understand, the repository index is hashed (now using SHA-256 instead of SHA-1) and this hash is then signed as usual, using whatever public key signature scheme they are using.