For real… My 2009 Dell Studio was a great Linux machine after Windows decided that 4Gi of RAM was not enough. My 2015 Dell XPS is still perfectly usable, even for moderately large software Dev tasks
open food/beauty facts: both have a long way to go IMO. The ui is very janky and lots of things don't work. Open food facts seems to be a bit better but not much
loop habit tracker: fantastic app, I use it every day, never saw a bug
gadgetbridge: the ui seems rudimentary, but it has everything you need and it works really well. YMMV depending on which gadget you have though
openscale: only used it for manual tracking. It's very very basic but somehow I didn't find a better alternative
[…], from that point the app will be built by f-droid with their own digital signature.
This part of your comment is not quite true. One of the advantages of reproducible builds is that the app can be signed by the developer but fdroid can still verify that it has been built from the correct source code. You can check out the documentation here: https://f-droid.org/docs/Reproducible_Builds/
Isn't one hurdle to integrate gtfs data into osm based apps the fact that there is no reliable way to link osm nodes with gtfs nodes? How did they get around that?
Does this mean that access to real time arrival data is on the horizon for osm based apps?
Edit: It appears that a lot has happened since I last checked, how cool!
Kagi supports this since a while. You can end your query with a question mark to request a "quick answer" generated using an llm, complete with sources and citations. It's surprisingly accurate and useful!
BinaryEye is another really good one: https://github.com/markusfisch/binaryeye
You can export the dashboard as JSON and then add it to your own grafana
For real… My 2009 Dell Studio was a great Linux machine after Windows decided that 4Gi of RAM was not enough. My 2015 Dell XPS is still perfectly usable, even for moderately large software Dev tasks
Klassiker! Das Weihnachtswunder… Gute Besserung!
I have some experience with some of these apps:
3 Tage geheizt und jetzt ist die Therme kaputt, na oida 🙄
There has actually been some progress on integrating GTFS data into OSM: https://wiki.openstreetmap.org/wiki/GTFS
I haven't yet seen much use of it in the wild though…
Wer weiß, vielleicht ist blau/schwarz ja besser als schwarz/blau 🥲
If an app doesn't support reproducible builds, the version you can download from F-Droid was built and signed by F-Droid, not by the dev
This part of your comment is not quite true. One of the advantages of reproducible builds is that the app can be signed by the developer but fdroid can still verify that it has been built from the correct source code. You can check out the documentation here: https://f-droid.org/docs/Reproducible_Builds/
Cool but seems very unrelated?
I dislike Google as much as the next guy, but this seems to be an issue with the manufacturer (onn), not Google
Happy Fairphone 4 user here! 🙂
Though I've heared mixed things about the FP5...
https://en.m.wikipedia.org/wiki/Schiederweiher
Isn't one hurdle to integrate gtfs data into osm based apps the fact that there is no reliable way to link osm nodes with gtfs nodes? How did they get around that?
Does this mean that access to real time arrival data is on the horizon for osm based apps?
Edit: It appears that a lot has happened since I last checked, how cool!
Reference: https://wiki.openstreetmap.org/wiki/GTFS
I use ntfy and have no problems. It's very reliable. No idea about graphene though
Kagi supports this since a while. You can end your query with a question mark to request a "quick answer" generated using an llm, complete with sources and citations. It's surprisingly accurate and useful!
You're probably experiencing the "59 second bug", which has been around for a couple of weeks. Restarting the app usually helps, at least for me.
You can! It's quite easy: https://newpipe.net/donate/
Man I'm really tired of these headlines. In not more interested in reading your article of you try to make it sound like a wrestling match!