I'm very aware of this thanks, however for training to run I went for convenience.
I like comparing with my friends in the app and using the training plans etc.
The fit to gpx converter is a good way to extract hiking data though!
Garmin Forerunner 55.
It's the most basic one in the running series, but it works well enough for what I need it to do.
It's the first real "closed ecosystem" device I own, as usually I go the open source route for everything, but Garmin has a good track record and the device has helped me train for a half marathon really well. I put a "casio"-style watch face on it, and I enjoy it a lot.
The fact that people were registering .ml domains for projects like this is mindboggling. There are many TLDs to pick from without infringing on the terms of use of a country-specific one.
It's completely valid for them to do so. Their Top Level Domain meant for their purposes.
Even though it's rarely enforced, many TLDs have specific purposes and conditions against abusing it for unrelated purposes.
There are many others to pick from.
https://friture.org/
I used to use this one when I was still mixing live music on analog gear.
I had a linux laptop running with jack2, on the headphone out of my soundcraft desk connected to my usb audio interface, visualing the input. (Which would be the single instrument I had selected or the entire desk output).
I'm sure it would work well for locally playing music as well.
I've been on XFCE for well over 15 years, maybe nearly 20.
In the beginning I ran Xubuntu because it was faster than Gnome 2 on my ancient laptop.
Nowadays, I just run it out of habit on top of Arch. I've had my stints on KDE and modern Gnome, but I like how "out of the way" XFCE is.
GSDE looks interesting, but I'm sure it will only appeal to the Elders that have used nextstep and similar UIs.
Honestly, I feel the 1:1 compatibility issue is overrated.
We want a stable distro that has ABI compatibility throughout the 5-10year support cycle, I don't really care if it's 1:1 compatible with RHEL.
For the niche or specific usecases where RHEL compatibility is needed, they offer their UBI container.
In the past I did care more about it, because we were using specific Puppet modules and other provisioning tools that were validated against specific RHEL versions, but in the age of containerization it's much less of an issue.
It might be an issue with certain ISO compliance, because we can't just blindly throw a RHEL 8 CIS security benchmark script at a base Alma image anymore and expect everything to work fine. But it's not a dealbreaker in my sector. We can reach compliance by making up our own benchmarks. The sectors that don't have this luxury are probably already on RHEL for different reasons.
With what Rocky tried to do to remain 1:1 compatible with RHEL (Pretty much leaking and stealing the rpm sources) I'll stay with Alma, even if they are no longer "bug compatible".
https://github.com/obsproject/obs-studio/pull/2868
This is a good example of this kind of evangelism for the hot new packaging standard gone wrong.
A pull request was made for a half-baked appImage version of OBS by appImage creators.
They refused to support it, and the OBS developers refused to merge it because they have no appImage knowledge.
Drama ensued.
I do like how nixOS is tackling this issue, but I don't really care enough to switch away from Arch.
It doesn't look like it has been mentioned here yet: https://www.amazon.com/Skeptics-Guide-Universe-Really-Increasingly/dp/1538760533
This book goes really deep into every different kind of logical fallacy.
If you want to know where a better place to post this was: the microblog part of this community.