Sure, but one is much more likely to have some ARM(64) SBC / smartphone / tablet / IoT device laying around than a SPARC box. Those are much more likely to have Linux than NetBSD drivers. Support for ancient architectures doesn't matter nearly as much as that.
Does anything like the Antithesis hypervisor exist as open source?
The closest I've seen is Qemu record/replay, but that's very slow (no KVM acceleration, no multicore), and broken in current Qemu versions (replayed system just gets stuck).
There's languages that support time travel debugging, like RR for GDB, or smalltalk, but no open source system wide thing like Antithesis that I know of yet.
rr can record process trees; i.e. basically any part/descendant of a process you spawn will be recorded and can be replayed (userspace CPU & memory, that is); won't record the entire OS though.
My experience with RR is that the chance of it working without hitting a missing syscall or desync is only about 50%, which is why I want a different solution that doesn't rely on the fragile syscall recording approach.
Huh. In my experience it works nearly flawlessly, certainly far above 50%. And even when there are spurious failures in replaying it's easy enough to just re-replay (though I do wish there was some way to export the current position & checkpoints with instruction-level precision to import in a fresh replay). I suppose it depends massively on the recorded program (most of mine are simple C programs, but also a decent bit of Java for JIT inspection or FFI, and I've also recorded an Electron app a couple times, and for fun Factorio)
Same, I haven't had it have too many problems but it's not perfect & missing support for io_uring is a problem (they'll add it eventually I suspect once someone ponies up the money for it).
For vscode, I like the `arrterian.nix-env-selector` extension.
Can IntelliJ be configured to simply use whatever JDK belongs to the `javac` in PATH? If so, it should suffice to simply start it in a `nix-shell`. If not, maybe setting `JAVA_HOME` in your `.envrc` could help?
VSCode and IntelliJ also both have direnv plugins for importing env vars from direnv after the fact. You can use that alongside direnv's Nix integration to load those variables without relaunching your editor/IDE!
Why do you want to move off Android? Depending on the reason, your needs would probably be better met with an alternative Android distribution on Android hardware.
Not OP, but I'd assume everyone with the goal of dropping iOS and Android is doing so for philosophical reasons. I still have my BlackBerry KeyOne. Battery life is still measured in days, but GApps bloat has pushed me to Open Street Maps. Literally every single aspect of the KeyOne is better, from battery life to performance to app availability and polish - but opting out of all tracking may be more meaningful to some.
I never liked Android, having owned a few. The hardware is quickly obsolete, interface has this clunky feeling, apps don’t work properly, often because devs don’t see the same rewards as their iOS brethren. And however you spin it, it’s all proprietary sponsored.
A linux phone might have the same problems, but at least its far more closer to the Open Source side of things.
Unfortunately I think AOSP distributions are a long-term dead-end. Unless maybe if there was a hard fork. Or else it's just a scramble to keep up with whatever changes google is making, dealing with unsupported hardware and hoping that whoever maintains the build for you device knows what they're doing, and re-implementing gapps to try to get some mostly broken compatibility.
Oh, it's absolutely possible as long as your brain is flexible enough to appreciate both minimalist and maximalist language design. Same goes for C and Rust.
For languages with relatively uniform package ecosystems (like Rust and Go) there are tools that can generate Nix code for you from lockfiles with exact versions. In practice this usually suffices, because these ecosystems also have to remain compatible with other environments where OS-provided dependencies like C compilers and libs have wildly differing versions.
For most C ecosystem stuff you can try overriding the version, but you'll quickly notice why this is a hard problem: Different software versions want to be built in different ways! Someone would have to therefore maintain the quirks of each package version's build process for each package for all eternity, an insanely huge endeavor.
Also, even if it were possible this would break the Nix binary cache model, because suddenly you'd have an insane combinatorial explosion of not just package versions, but also versions of their dependencies. In order to preserve purity and reproducibility, a change in dependency version means that all dependents have to be rebuilt, taking up insane amounts of CPU and storage on the build farm.
I don't think that your request is unreasonable (I'd love to have this feature!), but it's probably not fully possible in any software distribution ecosystem.
