They don't directly embrace open source, but their more advanced watches that don't require the connect app for certain features like sleep (such as the fenix series) are nearly completely supported by https://gadgetbridge.org/ - the only thing I can think of that doesn't work is the weather map. You can even update the firmware and maps over wifi directly on the watch or use the PC software.
I use it all the time to connect to my boxes at home when I'm out and about, and I chat with friends on an IRC server running on there.
Development is pretty active, and the latest release just improved the routing algorithm by having it favour hops with the lowest latency which had a noticeable improvement.
If you're looking for a big community hub within the network you might be disappointed (you could always try to set one up!), but there are a lot of people using it for their own purposes and the protect is far from abandoned.
Isn't mpv a more modern and maintained mplayer fork? Mplayer was my go-to for many many years, starting in the early 2000s, but I switched at one point and can't remember why. What do you prefer about mplayer?
If I recall correctly, for a brief time mplayer disappeared from Debian. At the time I evaluated various alternatives and mpv was one of them, but I switched back to mplayer as soon as it made its way back to the distribution. For me, mplayer is the standard media player. I guess I just don't see any reason to switch to mpv or to any other player.
I see no reason to cling to mplayer/mplayer2, mpv has pushed things forward from there.
mplayer is what I used to use ages ago, can't think of a single thing I miss that it did which mpv doesn't. Like you, I was introduced to mpv through the debian disappearance, and it's been fine. Forks can be necessary to keep development active; it's one of the core features of FOSS.
Google sent a copyright violation notice for each .DS_Store anyone at my company uploaded to Drive for nearly a year (yes, many support tickets were filed).
It wasn't Apple's fault, but it still would have been nice if there was a way to turn them off.
For sure! I made sure to have an open ticket with them until it was resolved so I'd have someone to call if some other automated system decided to shut down our services for it.
1. Pirates uploaded a folder full of copyrighted files to Google Drive, accidentally including some DS_Store files along with the actual media.
2. The copyright owner filed a DMCA takedown on the whole folder, accidentally claiming ownership of a bunch of generic DS_Store files.
3. The above two steps have likely happened many times, not just once.
4. Google's takedown system now automatically flags DS_Store files as having multiple copyright violations.
5. A Google employee might be able to whitelist a user's individual DS_Store files to temporarily suppress the violation on their account, but since they can appear in different folders with different data and are constantly receiving new copyright claims, their system likely errs on the side of caution and continues to flag them as copyright violations so that Google doesn't accidentally lose its safe harbor protections.
In theory, a Google engineer could code in a special case to avoid this problem, but good luck finding and talking to one who's authorized to do so; Google is notorious for having one of the lowest employee;revenue ratios in the world and writing useless FAQs instead of having a proper support channel for when things go wrong.
That's a good question. I get the impression the system is fairly opaque even to the people working there. I was told it was "resolved" and had my ticket closed a bunch of times, only to have another 30+ copyright violation emails the next time someone uploaded a batch of files from MacOS.
If the person who finally managed to figure it out ends to reading this, thanks for the resolution :)
Since not everyone will click the link and read to the end of the post, it seemed worth pointing out that the vulnerability being commented on here was fixed: https://schollz.com/blog/croc9/
