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.

The (idiomatic) answer is based on the fact that your global environment doesn't need pync, weechat needs pync. Therefore, you override weechat's dependencies and inject the package into it's private environment like so: https://nixos.org/manual/nixpkgs/stable/#sec-weechat

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.

Given that you already have flakeified everything, it's not that hard to pull in a different version of nixpkgs and cherry-pick packages from it. I have a (somewhat complex) setup utilizing this: https://github.com/casept/nixos-config

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.

Very unlikely, the Android driver infrastructure is quite different from Linux.

So you have a Google server running in your PC? Copyleft only requires disclosure for source code that's actually shipped (which definetly applies to Intel).

That may be true for peripherals, but all a compiler has to care about is the core ISA. The board zoo is very much not relevant.

CI builds should be locked to exact versions anyways, for the sake of reproducibility.

Well, if the protocol is fundamentally broken there's no way to go but an incompatible rewrite.

The screensharing can be worked around by building a somewhat hacky solution (recording the desktop to an XWayland window and sharing that, for example by using https://gitlab.com/lelgenio/dotfiles/-/blob/master/dotfiles/...).

It's possible to have a locked bootloader (so no unsigned OS), but still have vulnerabilities in the vendor OS image that allow rooting (on devices that are 4 years out of date this is pretty likely).

Go is sufficiently trivial that anyone who dares call themselves a programmer can learn it in two weeks if they already have experience in some even remotely-related language.

Put LineageOS on it.

When was the democratic party ever truly "left"?

My impression of them is that they were arguably mildly SocDem in the past, and then turned into (neo)liberals in the 90's. Liberals are not leftists.

IMO fixing the unsafety is impossible, because doing so would mean re-evaluating the very core idea of C++ that C is a suitable substrate for building a safe, expressive language on. We know from years of experience that C has plenty of footguns of it's own, and fixing them is not possible without a fundamental redesign of the language. Therefore, the foundation of C++ is already rotten.

If that foundation were to be redesigned one'd have to get rid of the current near-100% compatibility with C, making the interop no longer an argument for using C++. Add the fact that most real-world C++ code will also be incompatible, and the strongest argument for using C++ is gone (namely, the impressive ecosystem size and maturity).

At that point there'd be no more justification for the existence of C++ over Rust (or another language that takes Rust's good ideas and supersedes it).

Just because there's a tool in a niche doesn't mean it's the best one. I could do all those things you listed in Rust with much less headache.

Many banks allow you to request a physical device to generate the tokens, so a smartphone isn't required.

Because the belarussian government doesn't have enough power over Telegram to force them to disclose messages, meaning that transport encryption is absolutely good enough for the protester's threat model.

They should be using Nix or similar then. The typical Dockerfile is not reproducible.