Readit NewsThe 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).
BTW, for others who just want to try it out without having to install anything on your system, there are docker containers you can use as a sandbox: docker run -it nixos/nix bash
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?
There are far too many out-of-the-box bugs and glitches to consider this a usable product. For example, the convergence dock will not display on a monitor. Firefox browser displays too wide for the phone screen, so unusable. A dozen other issues on first day.
Even a development board should work better than this, have documentation of the known problems, and have some support mechanism that works.
I don't think better/more expensive hardware is the problem. It's software, caused by lack of users, lack of investment, and too many "competing" distributions of Linux.
However, I've heard, but can't confirm so don't quote me that it is impossible to appreciate Go and Rust at the same time.
As with a lot of comments about Nixlang, the tooling there seems lackluster at best. In this case i'd want tooling to easily know and change package versions, not sweeping changes to your entire package ecosystem. Nix might give me that, but resolving derivations manually is not a great UX, imo.
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.
sudo port install py-pync
I spent quite a bit of time trying to figure this out and was unsuccessful. I'd love to know what Nix's answer to use cases like this is.
A healthy response to news of another compiler for your new language is, "Wonderful! People are demonstrating their belief in the future of our language with a big time investment! Another compiler will help us validate our language specification, which will be badly needed when we go to ISO to ask for a Rust standard Working Group."
It is just possible that a second compiler could be twice or (as happened with Pascal and C++!) 100 times faster. Faster builds would mean thousands of hours saved for users of the language—even, potentially, for people working on the old compiler!
A second implementation of the standard library could offer similar benefits.
More implementations is an absolute prerequisite to language maturity. All languages not doomed get them. It will be a net good for Rust not to be doomed.
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.
As much as i love the feeling of NixOS, i really want something like a Lockfile as seen in Rust (and other languages).
Ie if i could define a `Cargo.toml`, which includes versions of packages or `*` if i don't care - and then it gets built into a `Cargo.lock`, i'd be in heaven. Combine that with a great language backing the distro and i'd switch immediately.
As it stands, I hate nixlang, and while flakes is amazing i still dislike the single primary input approach to NixOS _(ie all the packages bundled together)_.
As an example of why i dislike that, i'm stuck on an old version of NixOS currently because when i tried to update the repo date - lots of packages changed in difficult to manage ways. X was crazy slow, Firefox was being wonky, XFCE was janky, etc. All my flakes.lock told me was that the hash of the repo was different.. yay.. hundreds of dependencies were different i'm sure, but no clue which ones, and no easy way to isolate the problems and just incrementally update.
Luckily flakes allowed me to rollback perfectly. Well, i still had some userland state from the newer applications that i needed to nuke, but i'm ignoring that for now.
Being able to more easily incrementally update specific dependencies would be amazing for me. As it stands i have no clue when or how i'll update my NixOS input version. Which is not a promising sign for my continued usage of NixOS.