From reading the Magic Earth FAQ, I believe the user data actually isn’t used for traffic at all (at least the manually reported events certainly aren’t).
Edit: never mind I missed a later part in the FAQ:
Do you share data with third parties?
We send position data to our traffic provider to generate real-time traffic information. The data is anonymized on the phone, using a changing key (so it’s not linked to you), and it is deleted after 5 minutes.
The first quote is taken out of context:
Not only are privacy and data protection founding principles for both Mobifree and F-Droid, the use of tracking-based in-app advertising poses a moral dilemma as well. If someone wants to gain access to an app, but does not have the financial means to purchase it, they can use it at a different kind of price - their user data.
For me this reads as them explaining and condemning that dilemma, instead of considering it as an option for F-Droid.
If the main battery isn’t “meant to be replaced”, it will often act as the CMOS battery (e.g. MacBooks have been doing this since roughly 2008).
Yesss fcast looks incredibly promising. Sadly the only app implementing it seems to be GrayJay, I really hope it will catch on more.
TVHeadend is the way, I’ve been running it with a USB satellite tuner for 5+ years. Setting it up can be a little confusing, but once it’s running you pretty much never have to touch it again.
As for clients, there’s a Jellyfin plugin, however it seems to not work for me right now.
My client of choice is Kodi with the TVHeadend plugin, and that works great. If you still want Jellyfin integration, you could just add your recordings folder as a library in Jellyfin.
Could I purchase two different brand drives and use them with btrfs?
I don’t quite remember the source for this, but I believe I read some time ago that it’s actually a good thing to have separate drives. The reasoning is, if you buy two identical drives (at the same time), the likelyhood of both drives failing around the same time is severely higher.
This is then amplified by the fact that rebuilding a RAID puts a lot of strain on the non-dead drive, so if ie. drive 1 dies and drive 2 is about to die, the strain you put on drive 2 in order to rebuild your RAID onto drive 3 might kill drive 2 before you even finish rebuilding your RAID.
Again, this is just from my memory, it might be worth doing some more research on.
The Pixel 8 and onwards technically support DP alt mode again. I’m not sure about stock, but I believe I read about some people having it just work in Graphene OS.
Incase you’re still searching, chech my other comment here.
Slightly old post, but hopefully still helpful to someone:
I managed to read out my analog water meter using the following ESP32 image: https://github.com/jomjol/AI-on-the-edge-device
It uses an ESP32-CAM module that actively reads your meter, using machine vision. The data is then published via MQTT. There are even some stl files for cases/mounts for common energy meters.
Once setup properly (with a 3D printed case from the provided stl files), I found it to work quite well. I have a pretty clean standard German water meter though.
I significantly prefer it for car navigation, it seems to always pick ‘more sensible’ routes than Organic Maps. Also the live traffic is very nice to have.
I prefer Organic Maps when I’m on foot, ie. walking through the city or hiking. Imo it feels less cluttered when you just want to look at a map.
Edit: Another big plus for Magic Earth is transit support. It’s not as good as Google Maps, but it’s certainly better than nothing.
While not FOSS, the closest thing we have to a drop-in replacement would be Magic Earth. It uses openstreetmap data, supports fully offline usage, has satellite images (only online though) and best of all, no tracking or telemetry.
You could use OBS to setup a virtual webcam, which would then show your receipts.
Only if you’re logged in as an Administrator though. A “standard” user account can’t access WiFi passwords on Windows.
I’m not too knowledgeable on that topic, but doesn’t Linux store WiFi or smb-share passwords in some keychain?
Edit: missread your comment a little, I’m guessing you meant that there are multiple different keychains on Linux
I just read the full article, and I’m not even that concerned about storing the key in plaintext. I find the possibility of copying the files, and then being able to run the same session simultaneously a lot scarier.
As the article states, currently all processes are able to read the file which contains the key. Instead, you could store the key in the macOS Keychain (and Linux/Windows equivalents), which AFAIK is a list of all sorts of sensitive data (think WiFi passwords etc.), encrypted with your user password. I believe the Keychain also only let’s certain processes see certain entries, so the Signal Desktop App could see only its own encryption key, whereas for example iMessage would only see the iMessage encryption key.
I believe Blurays are still a very good medium for long term data storage, like a cold offsite backup.
https://github.com/Akylas/OSS-DocumentScanner
I use this app for scanning documents, I just tried sharing a picture to the app and running OCR on that picture, which also worked fine, so it should also fit your usecase.
Damn even though you explained the abbreviation I still read it as Wife Approval Factor for a second and was very confused
i use miracast where I can (my TV and Samsung phone support it natively), as it pretty much just works and is a decent protocol. Sadly every phone manufacturer that isn’t Samsung seems to have abandoned it right now, but it is still widely supported in TVs. On Linux, there is the app gnome-network-displays (yes it also works on KDE) to cast your screen over miracast.
Miracast is an actual local streaming protocol (closely related to WiFi Direct). For content streaming the only FOSS standard I am aware of is FCast, but sofar it only is implemented in the GrayJay Android app.
Edit: There is also Deskreen for casting a PC screen.
For casting mobile to PC there is also scrcpy.
This isn’t really casting, but I often find that an HDMI cable (often paired with a USB-C to HDMI dongle) is the simplest and most reliable way to display a phone screen on another monitor (as long as the phone supports DP altmode).