>Google Messages - for most of the last 8 months RCS was broken on GrapheneOS, but it's back now and Google messages is still the only option for messaging with family members on iOS.
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.
That's so frustrating with Claude. If I need to widely search the web or if I need it to read a specific URL I pasted, I always turn to ChatGPT. Claude seems to hit a lot more roadblocks while trying to navigate the web.
The issue is Reddit though. They're the ones blocking. They're very aggressive.
When sites are working in one chatbot and not another, there's a good chance that the latter is respecting the website rules. As an example with Reddit, you're probably blocked when using a VPN like Mullvad
Personally, I've really enjoyed using bootc for both my personal laptop and my NAS.
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.
This makes sense to me. I guess I'll start hunting for the equivalent of `govulncheck` for Rust/Cargo.
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.
I was actually working on this last week, funnily enough. I've been working on a capability analysis tool for Rust, and if you're already generating a call graph via static analysis, taking that and matching it against the function-level vulnerability data that exists in RustSec isn't that hard.
cargo-audit is not quite at an equivalent level yet, it is lacking the specific features discussed in the post that identify the vulnerable parts of the API surface of a library. cargo-audit is like dependabot and others here in that it only tells you that you're using a version that was vulnerable, not that you're using a specific API that was vulnerable.
Saddly, since it relies on a Cargo.lock to be correct it also is affected by bugs that place dependencies in the Cargo.lock, but are not compiled into the binary. e.g. weak features in Cargo currently cause unused dependencies to show up in the Cargo.lock.
Depends on your workflow, I guess. I don't need to handle that case you noted and we delete the branch on remote after it's merged. So, it's good enough for me to delete my local branch if the upstream branch is gone. This is the alias I use for that, which I picked up from HN.
Yeah, there's a myth spread on the internet after Apple announced rcs support in iMessage that it was the end of green bubbles for android users. But green bubbles still exist; they never meant the other party is just using sms, they meant the other party isn't using iMessage.
Yeah, this is closer to what I do, too. I was surprised not to see a Containerfile in the linked github repo in the article (https://github.com/lthms/tinkerbell)
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 can confirm that the Odroid H4 Plus also supports in-band ECC. If I remember right, Memtest86 showed different stats when I ran it with in-band ECC enabled/disabled though I didn't have a good way to test that an error was actually corrected.
Some systems allow forcing an ECC error, but assuming that's not available, if you can adjust memory voltages or timings, you can usually encourage errors that way and confirm memtest detects ECC corrections.
All CPUs with ECC support allow the forcing of ECC errors, but unfortunately in recent years the CPU vendors usually do not document how.
Only when they expose this feature in Linux EDAC drivers it becomes possible to do this. In the past Intel had maintained well its Linux EDAC drivers, but AMD had frequently great delays between the launch of a CPU and the update of the drivers. After the many lay-offs at Intel, it is unknown whether in the future their Linux support will remain as good as in the past.
I went to a b-sides yesterday (so: small, local, cybersecurity-focused) where someone described their feelings toward GenAI as "praying for Star Trek, but planning for Terminator." Someone else described AGI as a short term inevitability.
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.
