F-Droid at 36c3(f-droid.org)
f-droid.org
F-Droid at 36c3
https://f-droid.org/de/2020/01/09/f-droid-at-36c3.html
8 comments
Same here in western Europe though, the screenshots take forever (they often never load) and icon caching would be welcome as well.
Personally I just look for apps elsewhere and install them through F-Droid when available (like Telegram, Firefox (fennec), piggybudget, OsmAnd, reddit reader, Öffi, K-9 mail, Newpipe, ssh connectbot, wifi analyzer, simple file manager & gallery, QR code scanner, muPDF viewer, etc. I all have through f-droid instead of the google ecosystem). The only exception is the "new" section that opens by default when you launch the F-Droid app: there I browse when there is new stuff.
Personally I just look for apps elsewhere and install them through F-Droid when available (like Telegram, Firefox (fennec), piggybudget, OsmAnd, reddit reader, Öffi, K-9 mail, Newpipe, ssh connectbot, wifi analyzer, simple file manager & gallery, QR code scanner, muPDF viewer, etc. I all have through f-droid instead of the google ecosystem). The only exception is the "new" section that opens by default when you launch the F-Droid app: there I browse when there is new stuff.
Aurora Droid and Aurora Store are sleek alternatives for the F-Droid and Google Play clients. They use the same sources for content, but the apps feel much snappier and look pleasant.
[1] https://f-droid.org/en/packages/com.aurora.adroid/
[2] https://f-droid.org/en/packages/com.aurora.store/
[1] https://f-droid.org/en/packages/com.aurora.adroid/
[2] https://f-droid.org/en/packages/com.aurora.store/
Not sure about Aurora Droid but the Aurora store wont have the same build guarantees that come with using fdroid. Something to note.
Installing malware through a proxy is still installing malware.
Aurora Droid comes with a customizable list of package repositories, including an F-Droid repository mirror.
Aurora Store fetches packages from the same source as the Google Play client. There's a legitimate benefit to having access to the Google Play catalog without depending on Google Play Services or owning a Google account, and not all apps on Google Play are malware.
Aurora Store fetches packages from the same source as the Google Play client. There's a legitimate benefit to having access to the Google Play catalog without depending on Google Play Services or owning a Google account, and not all apps on Google Play are malware.
> There's a legitimate benefit to having access to the Google Play catalog without depending on Google Play Services or owning a Google account
Definitely agree, use store personally, have done all that is possible to degoogle my phone but the reality is that certain play store apps are essential for modern living. Yalp was once good but find it unusable now. Aurora store has good UI and seems to handle the proxy accounts better, or at least they are not being banned so quick.
Definitely agree, use store personally, have done all that is possible to degoogle my phone but the reality is that certain play store apps are essential for modern living. Yalp was once good but find it unusable now. Aurora store has good UI and seems to handle the proxy accounts better, or at least they are not being banned so quick.
Are you using some Stallmanesque definition of malware ? Because otherwise, it's not clear what you are trying to say. Aurora droid/store are frontends to f-droid/gplay. They are open source themselves and don't do anything in the malware dept.
Other than the speed, I have problems with the interface. Search is virtually useless (sometimes returns nothing, sometimes too many results in a somewhat random order), and the information for every app is usually lacking. No reviews or rating system either so you just have to install things first to check out if it's really for you or not. There is not even a popularity indicator...
All in all, it's far cry from what a "best in class" app store could be.
All in all, it's far cry from what a "best in class" app store could be.
>whatever CDN they use
They don't use one AFAIK. They have mirrors, but the way stuff works is that their main server is still the bottleneck. This has been raised before (https://forum.f-droid.org/t/why-is-fdroid-down-all-the-time/... and a few other threads on the forum) without a satisfactory resolution. As an outsider, to me it appears that f-droid's user base is mostly European, and it works well enough for people in Europe.
They don't use one AFAIK. They have mirrors, but the way stuff works is that their main server is still the bottleneck. This has been raised before (https://forum.f-droid.org/t/why-is-fdroid-down-all-the-time/... and a few other threads on the forum) without a satisfactory resolution. As an outsider, to me it appears that f-droid's user base is mostly European, and it works well enough for people in Europe.
Central European here: the browsing experience in the app is absolutely miserable here too. I don't remember the last time I saw an app icon in the official client.
F-Droid makes its metadata human-readable: https://f-droid.org/en/2019/09/11/yaml-metadata.html
To help find apps here is a 3-line script to produce a tab-separated list of apks with one line descriptions
Then when I know what I want I download the source or .apk file from the website. It's a slow website but it's a good project otherwise. Appears they are funded by same organization that wrote libldns, nsd, unbound, drill, etc.
To help find apps here is a 3-line script to produce a tab-separated list of apks with one line descriptions
curl -4o name https://gitlab.com/fdroid/fdroiddata/raw/master/stats/known_apks.txt
curl https://gitlab.com/fdroid/fdroiddata/-/archive/master/fdroiddata-master.tar.bz2?path=metadata| bzip2 -dc|tar xOf - --wildcards *en-US/summary.txt|sed '/^In the list of classes/d' > desc
paste name desc|cut -d / -f3,5|less
curl https://gitlab.com/fdroid/fdroiddata/-/archive/master/fdroiddata-master.tar.bz2?path=metadata| bzip2 -dc|tar xOf - --wildcards *.yml|sed -n '/AutoName:/p;/./{/Description:/,/versionCode:/{/^ /p;#thats 3 spaces;};}'|less
curl https://gitlab.com/fdroid/fdroiddata/blob/master/stats/latestapps.txt
Then when I know what I want I download the source or .apk file from the website. It's a slow website but it's a good project otherwise. Appears they are funded by same organization that wrote libldns, nsd, unbound, drill, etc.
If you look at the older versions of FDroid before they made it "modern", it is much better at categorizing and being able to find apps.
versions after 0.102.3 were just terrible and i reverted immediately. Of course a lot of folks don't seem to mind the modern view but I find itv extremely unusable.
Supposedly a clone called GDroid shows ratings and such as well.
versions after 0.102.3 were just terrible and i reverted immediately. Of course a lot of folks don't seem to mind the modern view but I find itv extremely unusable.
Supposedly a clone called GDroid shows ratings and such as well.
If you're not getting icons and screenshots, that most likely because your data/wifi settings are set to not download them. For example, if you never/rarely use WiFi, and your data/wifi settings are set to only allow downloading over WiFi, it won't download the icons or screenshots. Originally, we had same defaults for everyone, then we updated it so that if you started F-Droid without WiFi on, then it would always allow downloads over data.
That said, yes, the official client could be improved, and we welcome contributions. The security side of F-Droid is quite solid, that's the problem with the various forks. They focus on UX, without the careful attention needed for security. The ideal world would be that the core of the official F-Droid client would be a standalone library, so that the forks can have the same solid base. We welcome contributions there.
That said, yes, the official client could be improved, and we welcome contributions. The security side of F-Droid is quite solid, that's the problem with the various forks. They focus on UX, without the careful attention needed for security. The ideal world would be that the core of the official F-Droid client would be a standalone library, so that the forks can have the same solid base. We welcome contributions there.
I haven't investigated too much but it might be/have been an issue with the app itself, alternative clients such as G-Droid[0] don't have this issue at all and I've experienced this issue inconsistency.
Looking at their bug reports the issue may have been fixed, and anecdotally I haven't had any issues recently.
[0]: https://f-droid.org/en/packages/org.gdroid.gdroid/ [1]: https://gitlab.com/fdroid/fdroidclient/issues?scope=all&utf8...
Looking at their bug reports the issue may have been fixed, and anecdotally I haven't had any issues recently.
[0]: https://f-droid.org/en/packages/org.gdroid.gdroid/ [1]: https://gitlab.com/fdroid/fdroidclient/issues?scope=all&utf8...
I used to have the issue with icons refusing to load at all, but now they are loading, it is just very slow.
What's your experience with the third party clients that you've been linked? It may be worth submitting another bug report if they don't have these issues.
[deleted]
Same in Canada... It just does not work well.
Ditto. Seems less of a location problem at this point.
> I know it is open source and I should not complain.
Nah, you should complain. Open source is not an excuse for broken functionality.
Nah, you should complain. Open source is not an excuse for broken functionality.
It's an opportunity to actually improve it.
I use it from India and it works smoothly.
Same in the US.
Wait, there are screenshots?
The note on Timeless at the end is very exciting.
https://repeatr.io/welcome/what-is-timeless/ explains timeless as a set of tooling for reproducible builds with a broader and more hash-based mandate than what's out there currently. While early, it seems like it's a reasonable path towards getting a reproducible system that won't fall apart as fast over time, by vendoring the dependency system in the same way modern language-specific package managers do, but at a language-agnostic/distribution level.
https://repeatr.io/welcome/what-is-timeless/ explains timeless as a set of tooling for reproducible builds with a broader and more hash-based mandate than what's out there currently. While early, it seems like it's a reasonable path towards getting a reproducible system that won't fall apart as fast over time, by vendoring the dependency system in the same way modern language-specific package managers do, but at a language-agnostic/distribution level.
Looks like there's some overlap with nixOS, Guix and https://reproducible-builds.org/. I'm pretty glad that there's been a lot of work in this space, especially https://guix.gnu.org/blog/2019/guix-reduces-bootstrap-seed-b...
Is there any particular difference with https://nixos.org/nix/ which is backed by academia and has years of experience? Never heard about Timeless though.
FWIW, I'm using Nix to package Android app builds in a reproducible way (for React Native apps).
FWIW, I'm using Nix to package Android app builds in a reproducible way (for React Native apps).
I've gone through their website and I think I have a reasonable grasp of the difference. Unlike NixOS and Guix which enforce a store, all builds are performed in a container[0] and produce a self contained executable[1].
I speculate that the container approach will make porting slightly easier as dependancies can be placed where they are expected, thus no patches are required for project build systems. On the other hand producing a self contained executable seems more difficult, and I wonder if they'll go with an AppImage like approach to minimise patches required.
Overall the vision has overlap but the end result is very different from that of NixOS and Guix.
[0]:
> Typically, we use an executor which uses “linux containers”. However, for the most part, we try to consider that an implementation detail. Executors might also be simple chroots; or virtual machines; or other interesting kinds of sandboxing. Nor are executors strictly limited to the Linux operating system; it's simply the most common place to work. https://repeatr.io/design/executors/
[1]:
> Radix “Packages” are similar to packages from other linux distributions… however, we're aiming to do something not like linux distributions: our vision for Radix Packages is that they go anywhere, with or without the rest of a distro associated with them. https://repeatr.io/welcome/what-is-radix/
I speculate that the container approach will make porting slightly easier as dependancies can be placed where they are expected, thus no patches are required for project build systems. On the other hand producing a self contained executable seems more difficult, and I wonder if they'll go with an AppImage like approach to minimise patches required.
Overall the vision has overlap but the end result is very different from that of NixOS and Guix.
[0]:
> Typically, we use an executor which uses “linux containers”. However, for the most part, we try to consider that an implementation detail. Executors might also be simple chroots; or virtual machines; or other interesting kinds of sandboxing. Nor are executors strictly limited to the Linux operating system; it's simply the most common place to work. https://repeatr.io/design/executors/
[1]:
> Radix “Packages” are similar to packages from other linux distributions… however, we're aiming to do something not like linux distributions: our vision for Radix Packages is that they go anywhere, with or without the rest of a distro associated with them. https://repeatr.io/welcome/what-is-radix/
I saw the meetup in the schedule but didn't end up going because I wasn't sure what it would be about. Looks like some interesting topics were discussed! And indeed, the congress app updates were on time this year, that was very nice.
I like the idea of f-droid but when I used it felt like searching GitHub while expecting more of an app store experience.
Now maybe that makes sense for what for what f-droid is but often I couldn't tell what some apps even did... if they would work on my phone (a surprising number did not)...
Now maybe that makes sense for what for what f-droid is but often I couldn't tell what some apps even did... if they would work on my phone (a surprising number did not)...
Link should point to /en/ rather than /de/
Almost every android app I use is from the f-droid store, due to being on a unrootable phone so no ROMing for me. I love it, but it isn't perfect so it's nice to see work still being done on it.
aaron695(2)
> @Bubu distributed almost 5000 F-Droid stickers, through the congress sticker exchange boxes and by giving them to interested assemblies (Matrix, Nextcloud, FSFE).
Stickers, really? Is it major thing needed to include in 36c3 report?
Stickers, really? Is it major thing needed to include in 36c3 report?
Sticker swap is important to a significant sub-subculture of hackers. https://twitter.com/tvidas/status/1162771218715557889
https://twitter.com/spacerog/status/1197613616171749376 & https://twitter.com/spacerog/status/1204056842999156736
https://twitter.com/spacerog/status/1197613616171749376 & https://twitter.com/spacerog/status/1204056842999156736
I know what does stickers mean for hackers, and I also has stickers on my laptop.
But... I mean, that, as its significant sub-subculture, it should be placed as last line in this article; not at the core list.
Maybe I'm not sub-subhacker. Yet.
But... I mean, that, as its significant sub-subculture, it should be placed as last line in this article; not at the core list.
Maybe I'm not sub-subhacker. Yet.
Help me out here....are those just the usual coding product type stickers or.... some sort of individual stickers an individual made... about, themselves?
Given the long queues at the sticker boxes and their general popularity: yes.
Same with screen shots, it can take 15+ seconds for screenshot thumbnails or full screen shots to load. It is like being on dial up.
I know it is open source and I should not complain.