Live data from Hacker News

New F-Droid repository format for faster and smaller updates

f-droid.org

91–100 of 146 posts

Re: New F-Droid repository format for faster and smaller updates

#91
post #8

I 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%…

Did you file any bugs?

Re: New F-Droid repository format for faster and smaller updates

#92
post #85

Congratulations team. I was involved in the project for quite some time years ago. Indeed I ported the original “Read the full index.xml into Java memory using a giant DB class” with the first “Stream entries from XML into the database, and make use of ContentProviders” because they seemed like the “Android way to do things” at the time. I also worked on the migration from XML to JSON metadata. At the time this was d…

What is (or was) the benefit of using ContentProviders compared to accessing the database directly? They seem useful for exchanging data between apps, but I can't figure out what their role is when they're internal to the app (not exported). Is it just that they're required for using CursorLoader, so that you can easily load things in the background without having to create a custom Loader implementation? And they're…

When faced with the previous system [0] - where full table scans were the norm and filtering/sorting was done in Java afterwards - we certainly could have gone to proper database queries. I think it is mostly the first thing - that we wanted to move into the background instead of full table scans on the UI thread, and indeed CursorLoaders were an agreed upon way to do that with the (then, relatively new) RecyclerView.

But yes, you are correct that they are indeed an inconvenient database abstraction.

The only thing I will say is that despite the crummy abstraction, we did put the effort in to have good test coverage of each ContentProvider. It took a while to get the infrastructure up and running so that we even could test them, but once the plumbing was added, it became simple to add new tests to ensure they worked as expected.

This is important when you need to take into account things like "Get me all the apps, but filter on category, and then also limit those Apps to ones for which they have at least one Apk which is installable on my hardware, meets my AntiFeatures requirements, and then also pull back data about whether there is a version that can be upgraded to or not based on currently installed apps. I fell in love with the SQLite explain output. I found it really good at explaining what was going on with these mildly complex joins - much easier than the MySQL explain output I was familiar with.

[0] - https://gitlab.com/fdroid/fdroidclient/-/blob/b3773a156121cf...

Re: New F-Droid repository format for faster and smaller updates

#93

Earlier quoted context omitted.

"...It's been years since the UI update and it's always been amazingly buggy" Being buggy is only one aspect, the other was the annoying change of UI that presents apps in rows of large, gawky icons instead of the previous efficient rows of title text each headed by a small icon (as say in Windows 'List' mode). Unfortunately, this leaves me stuck on ancient version F-Droid 0.102.3. When looking for an app this new la…

if you prefer old f-droid interface, you can try foxy droid https://f-droid.org/en/packages/nya.kitsunyan.foxydroid/

Even better...

https://f-droid.org/en/packages/eu.bubu1.fdroidclassic/

Re: New F-Droid repository format for faster and smaller updates

#94

> 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.

It isn't common to encrypt or sign the full content using asymmetric encryption.

For encryption you usually pick a large random key for symmetric encryption, encrypt the body with a strong symmetric cypher and that key, and encrypt the symmetric key with your asymmetric method and the intended recipient's public key.

For signing, you use a suitable secure hash function to produce a digest of the content, when sign the digest using your private key. Choice of digest function is as important as your choice in encryption method as an exploitable issue that allows you to generate the same digest for different content means that the signature, while secure in itself, is worthless because what has been signed is no longer effectively deterministic.

tl;dr: So when they say “digest algorithm for repository signing” they don't mean that they are using the SHA256 result as a signature, but that they use SHA256 to generate the digest that is then signed.

Re: New F-Droid repository format for faster and smaller updates

#95
post #62
post #8

I 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 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…

This! And I thought I'm just too stupid to use this search, ha! Search is hard, for sure, but come on. But you actually reminded me to just use Google Dorks for that with inurl:https://f-droid.org/packages/.

Re: New F-Droid repository format for faster and smaller updates

#96
post #23
post #14

Earlier quoted context omitted.

I recommend NeoStore [1], which is an alternative frontend for F-droid. I can't say it never crashes, but I prefer it to the F-droid app. [1] https://www.f-droid.org/en/packages/com.machiav3lli.fdroid/

From what I was reading recently, NeoStore is also the F-Droid client which supports automatic upgrades on Android 12, without root.

The lack of automatic updates/upgrades in F-Droid is what keeps putting me off. I completely understand people who want more control over when and which apps get the updates, but this is not a good policy for the general case: I trust the developers of the apps I install from F-Droid to provide me with security, stability and performance updates much more than I distrust them to pull the rug from under my feet.

I also don't think an alternative-to-the-alternative is the right solution. I didn't even know NeoStore or Aurora existed before now, and frankly I don't want to know the difference. F-Droid is already extremely niche, compared to the Play Store. It needs to play every strong card it has available at hand, rather than proliferate the fracturing.

Re: New F-Droid repository format for faster and smaller updates

#97
post #88

Earlier quoted context omitted.

It would be nice to use some kind of delta compression to only download latest changes. There could be a version-stamp on your local data, the client would send the timestamp to the server, and it would send a delta from your version to current version of db (easy to cache). Integrity checks would be important I think.

That's essentially what they're announcing, isn't it?

Woops, yes. I didn't read the article, and thought it was referring to apk diffs, my apologies.

That said, apk diffs seem important as well, some updates are significantly large (more than 100MB) and see frequent updates. Although in that case it might need to cache apks which requires space as well (I would opt in, though!).

Re: New F-Droid repository format for faster and smaller updates

#98

Earlier quoted context omitted.

Just worked for me without issue on the first try. On both my phone and my tablet.

"Works on my machine" is not really a helpful response to someone sharing an issue they have. Are you implying that the parent is lying? If not, what constructive purpose does this comment have? (I write this as someone who has experienced nearly every bug mentioned in this thread.)

It's a helpful response, in that it indicates that it's not a universal problem, i.e. not a totally botched release, and may be worth debugging or submitting a report for.

Re: New F-Droid repository format for faster and smaller updates

#99
post #70

It shouldn't need to download the whole repo index for a mobile app store. It's a flawed assumption to begin with.

I don't won't to be tethered 24/7 to the internet to use my mobile phone. Data exchange isn't free, both in money and in environmental impact. That's a flawed assumption to begin with.

You're talking about an app store here though - by definition it needs to retrieve the app itself and assets related to each entry (e.g. screenshots), so it's not like you're achieving anything useful by downloading the database offline.

This isn't something like a news reader.

Post reply on HN