casept

Most cheap watches are microcontroller-only. AsteroidOS is a Linux distro and therefore needs a chip capable of running some Linux variant.

If you want desktop Integration, try distrobox.

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.

I've always had good experiences with TP-Link, just not their stock firmware. They're cheap and reliable OpenWRT devices.

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.

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).

Only if you use their SDK. Quite a few parts of the chip lack actual register-level documentation, not so on the 2040.

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?

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.

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.

GCC-RS will never have the same level of investment as rustc, which means that either it'll rot or the entire ecosystem will rot due being tied down waiting for it to catch up.

Also, the Rust community at large is not at all enthusiastic about handing the language over to ISO. The design-by-comitee-based, incrementalist, waterfall throw-it-over-the-wall-every-3-years approach is pretty much the exact opposite of the continuous delivery-based way Rust is developed, and arguably one of the main reasons why C++ sucks.

The central government doesn't even want that pipe all that badly anymore, it's mostly the clowns governing the federal state of Mecklenburg-Prepommerania who want to continue.