I'm glad to hear that's finally fixed. That was my only pain point with GrapheneOS, but it got so bad I bought an iPhone when the 17's came out.
If the deal with Motorola helps GrapheneOS get better integration with the carriers, get a heads up about RCS changes ahead of time, get help fixing it, I'd happily switch back. I loved using GrapheneOS and iOS frustrates me daily.
I really like the NAS use case because I can build the ZFS kmods for that specific version of Fedora CoreOS in CI/CD. If there's any compatibility failure, then my NAS doesn't get an update and I get the CI/CD failed email. No downtime because of some kernel incompatibility.
For the laptop though, I feel like there's a better way that I haven't found. Some way not to require CI/CD, to build the next image and switch to it all locally. I haven't gone down that path yet, but it looks kinda like that Option 2 the author described. Maybe it's really just that easy.
I've really been enjoying this space.
Separately, I love the idea of the `geomys/sandboxed-step` action, but I've got such an aversion to use anyone else's actions, besides the first-party `actions/*` ones. I'll give sandboxed-step a look, sounds like it would be a nice thing to keep in my toolbox.
What tools are the best to do the equivalent but for squash-merged branches detections?
Note: this problem is harder than it seems to do safely, because e.g. I can have a branch `foo` locally that was squash-merged on remote, but before it happened, I might have added a few more commits locally and forgot to push. So naively deleting `foo` locally may make me lose data.
# ~/.gitconfig
[alias]
gone = ! "git fetch -p && git for-each-ref --format '%(refname:short) %(upstream:track)' | awk '$2 == \"[gone]\" {print $1}' | xargs -r git branch -D"
Then you just `git gone` every once in a while, when you're between features.Android phones can't use iMessage because Apple never opened it up, contrary to what Steve Jobs was hinting at back when it was released.
Nowadays I believe you can get a blue bubble when chatting from an Android with an iPhone user by using RCS / JOYN.
The predictability and drop in toil is so nice.
https://blog.gripdev.xyz/2024/03/16/in-search-of-a-zero-toil...
I found working with normal `dnf` and normal config files much easier than dealing with Ignition and Butane. Plus, working with your image in CI/CD instead of locally fixed my ZFS instability. When Fedora kernel updates, but ZFS doesn't support that version yet, now it fails in GitHub Actions and the container is never built, so there's no botched update that my NAS mistakenly picks up.
I do not know whether the 8-core version (H4 Ultra) also enables in-band ECC, as for that CPU Intel does not specify embedded uses, so they may disable the ECC support in the factory.
See e.g.:
https://www.cnx-software.com/2024/05/26/odroid-h4-plus-revie...
However, looking right now at:
https://forum.odroid.com/viewtopic.php?f=171&t=48377
I see that someone has enabled successfully in-band ECC on the 8-core ODROID H4 Ultra and has run benchmarks with ECC disabled/enabled. Therefore it appears that in-band ECC support exists on all models.
The results of benchmarks with in-band ECC disabled/enabled may be not representative for real workloads. In-band ECC relies on caching the ECC bits in a dedicated ECC cache, in order to avoid excessive memory accesses. The effectiveness of the ECC cache can be very different for the benchmark and for the real workload, leading to misleading results. Usually for the real workload it is likely that the cache hit-rate will be higher, so the performance drop with in-band ECC enabled will be less conspicuous.
Not many others addressed it directly. The vibe I got from offhand remarks was that people felt it was a thing being forced upon them that they are resistant to use.