Sounds like it has similar goals to bcache (not bcachefs) and LVM caching, except that it operates in userspace instead of at the kernel level. Can you explain what the benefits are of keeping this out of the kernel?

I host a CalDAV server (specifically Nextcloud’s Calendar app, though plenty of others exist, like Radicale) and all my devices sync with it.

AsteroidOS mostly supports watches that come stock with Wear OS, which is a modified version of Android, which, guess what, runs a Linux kernel. These watches are on the more powerful end of the computing spectrum. As you say, there are a lot of smart watches that use pretty lean MCUs, but those aren’t running AsteroidOS or Wear OS, as noted in this FAQ entry.

Downvotes are to show that the content does not contribute to discussion. This comment is not related to the top-level post, and looks to be low-effort trolling, so it is not contributing to discussion, and deserves downvotes.

Follow the link and go down to the third point:

Isn’t this just ReactOS?

ReactOS tries to reimplement the Windows NT kernel, and that has always been its Achilles heel, holding it back from a hardware compatibility and stability standpoint. The loss32 concept is to achieve a similar-feeling end result to ReactOS, but built on a more usable foundation, using components known to work well (the Linux kernel, WINE, everything that glues those together, and a sprinkling of ReactOS userland niceties). As a bonus, the OS would still technically be a Linux distro, so it would be possible to run Linux software when necessary, something ReactOS can’t do.

deleted by creator

Actually, it’s more the opposite. Sorry, I don’t think I explained too well. The watch works just fine on its own without a smartphone. For functions that require phone and watch working together, Gadgetbridge lets them communicate (e.g. when you receive a text message on your phone, Gadgetbridge will let you read the text on your watch).

The apps on the watch will work with or without a smartphone. However, installing apps from the Bangle app loader requires the watch have a Bluetooth connection to a phone or computer. After apps are installed, they will run even without the Bluetooth connection.

Finally, note that the Bangle does not have an internet connection on its own; it has no cellular or wi-fi radios on board. So any apps that require a network connection (e.g. weather) will only work when paired to a phone with Gadgetbridge. I think there are other watches with wi-fi, but I’m not familiar with them.

I have been using a BangleJS 2 for the last year, and have quite liked it. There is a companion app, Gadgetbridge, to install on your phone, which is available through F-Droid (there is a Bangle-specific version of it, or a generic version that supports a bunch of other smart watches). There is also an app store (all free software) for apps that run on the Bangle itself. It includes a heart monitor, but no music streaming.

I’ve also been watching rePebble as they start making new Pebble smartwatches. I’ve never owned one, but a lot of people swear by them. They are now fully open source and have an app store. No idea if they can stream music.

That sounds like an issue with the underlying OpenStreetMap data that is used by Organic Maps (and CoMaps, and OsmAnd, and others). Map quality depends on where you are in the world and who is contributing to the maps there. If data is incomplete around you, you could contribute to it (but easier said than done, I know).

I can’t say why the route would be hours longer than Google maps, but I’ve noticed OsmAnd~ tends to overestimate drive time for me (I think it overestimates delay from traffic lights). Or it could just be that calculating routes on your phone doesn’t always give results as good as calculating routes on Google’s servers.

I used to have scripts like that, but eventually switched to ssh aliases. You can set up an alias for each machine in ~/.ssh/config with lines like this:

Host p1
    HostName 192.168.1.123
    Port 22
    User pi

Then access with ssh p1. Slightly more typing, but avoids adding more commands to your $PATH. Also has the benefit of letting you use the same alias with other ssh-related commands like sftp.

I feel like you may have misunderstood the article. It’s talking about how support is increasing for dedicated Copy keys, and that programmable keyboards make it easy to use dedicated Copy keys. The article does not mention changing the behaviour of Ctrl-C.

Technologically, I2P handles large data transfers much more efficiently than TOR. That makes I2P useful for torrenting large files like Linux ISOs.