I did something similar, but less scientific, comparing ESP-IDF and esp-hal (Rust). Unfortunately I learned that the optimizations that are already in ESP-IDF (most of all automatic light sleep between BLE advertisments) are hard to replicate in Rust/esp-hal/embassy and so for battery powered devices you might want to stick to C++/ESP-IDF
It would be great if we could combine ReactOS with Good old Games to build a retro Windows games distribution. I could hand that out at LAN parties as USB boot stick.
Agreed. For this to work, though, I guess there needs to be:
- a listing of all games that work well on ReactOS, similar to
how WineHQ does.
Or perhaps a specialized variant of ReactOS with that focus in
mind. Do we have such a list? I assume many games also won't
work perfectly well; see WineHQ, that also had tons of issues
with some games.
"Or perhaps a specialized variant of ReactOS with that focus in mind."
Trouble is there's never been enough interest in ReactOS to get it to the point where it's stable let alone warrant fancy extras. (After three decades of trying to clone the basics and failing is proof enough.)
In short, developers see it as a dead end. Why there's so little interest I've never fully understood, but it's fact.
If it were actually stable and usable as a basic operating system it could be used for lots of offline stuff but it's not—even at this point. If it were useable I'd readily adopt it to use offline (I've tried many times and failed).
Another point, this lack of interest shows up on ReactOS's website; there's so little new news and info the site may as well be dead.
One thing I learned the hard way is the antenna must not lie on your PCB! Even if it's just board without copper. I didn't see this stated anywhere, but once you look, every devkit is doing that, the antenna sticks over the PCB. When I had it on the PCB I had very bad connectivity and very high power usage.
Oh, I got bitten by that! I have my work Linux installation on an USB stick so I can boot it on either my desktop or laptop and one day tailscale stopped working. I thought that might be a rare situation, but it looks like TPM based encryption failed for other reasons too.
I don't know much about ARM SoCs, is this something you would built a phone with? With all the talk about Google locking down Android, can Pine64 please go and make a Pinephone with this if that brings us closer to a Linux phone?
Does anyone know whether more than one device can connect to a Pebble watch at the same time? I'm thinking using it with your phone but also sending notifications from your laptop.
Pebble watches can use Bluetooth LE and Bluetooth Classic connection profiles simultaneously. It's possible to pair two phones this way, but that's considered an undocumented hack. Also there's no ready-made desktop OS support, I'd look into forwarding your laptop notifications to a phone via KDE Connect or something like that instead.
But I do want to dig into that, someday. There is an open source library in Kotlin multi-platform for building applications that interact with the watch (libpebble3) and, in theory, Bluetooth LE can connect to more than one device. But the PebbleOS probably restricts it.
My dream is to use the watch to authenticate to computers, websites and IoT devices.
Connecting to a laptop isn't supported AFAIK. Personally I don't have any important notifications on my computer that don't come to my phone already. What would you use it for?
I'm thinking of having Claude send me a notification when it needs my input. I already do that sometimes with desktop notifications and this way I could water the plants or hang the laundry while waiting.
Why does the Core 2 Duo not have a heart rate monitor (which I think my Pebble 2 had) and why does the Core Time 2 not have the barometer and compass?
It makes it really difficult for me to decide which to get.
Also, I have a small preference for the design of the original Pebble Time 2 over the Core Time 2 ...
Very much agree. I want to go take this on a hike in the wilderness. I want a compass and a heart rate monitor. Barometer would be nice but I could take or leave.
This would be nice, but for me I'd never go hiking without my iPhone (especially since they now have satellite-based messaging). I assume there was a tradeoff here, and even if it was just a bit more battery I probably would have to agree with ditching these bits.
That's a fair point. My phone has a compass, so I can always look at a compass there. Not having it on the watch is just an inconvenience. My phone isn't a heart monitor.
What I would really like is something like Docker to build images for my raspberry pis. Just a single file, shell commands, that's it. I feel that Yocto is already too complicated if you want a reproducable setup for you raspberry pi at home.
It's not a shell script, but it has makefile rules that make it relatively simple to build a Docker image for your architecture, export it and turn into a filesystem image, build a kernel, u-boot, etc
The referenced "example project" repo builds a basic Alpine image for the Raspberry Pi (https://github.com/makrocosm/example-project/tree/main/platf...) and others
It was motivated by frustrations with Yocto at a new job after 8 or so years working on firmware for network equipment using an offshoot of uClinux.
Hoping to convince new job to use Makrocosm before we settle on Yocto.
