The nixos module and their tests make it very discoverable how to run many services. Where in arch I actually have to read where programs put there configuration, in NixOS I can already start configuring. Also github search is very value just put the nixos option + lang:nix and you find tons of examples.
Because forking is also expensive and people would need to discover the new domain. Otherwise I would already have done it. We already have the issue of having too many different sources of documentation. And hacking the wiki is the last thing I want to do... I don't want get visits from the police from $someone.
Eelco likes `nix-env` and its new equivalent, but not many other people in the community share this opinion... That's why its in the nix documentation but everyone else uses something else.
Yep. Second this. I also stopped contributing to rust-nix for the same reason. CI took forever. They wanted changelogs for everything but as soon as another PR was merged it would result in a merge conflict. Whenever I need a libc function not available in rust-nix I just add the abstraction to the project itself - this way I also don't have to care about someone else breaking my code by changing types.
I still prefer github's UI and PR style over those ugly kernel mailinglists, where there is no merge status and no good CI integration and no good search unless you force yourself into using some complex mail setup.
So everyone is not getting a more secure/safe system because a small minority wants to run Linux on old computers?
That does not sound fair to me. Why can't they not use old versions of Linux as well.
They way rust is used in the kernel is a lot more constrained in scope and APIs compared to normal userland rust and hence easier to learn. A lot of added rust API are also just high-level abstraction of already existing concepts/code used in the kernel.
You can install nix. Does not give you sandboxes like flatpak unless combined with other tools like firejail or nixos-shell, but at least nixpkgs-unstable is one of the most up-to-date package managers out there.
I run [nix-update](https://github.com/Mic92/nix-update/) to update stuff. If you want to package something new, first identify the programming language/buildsystem the project is using and than look for a similar project in nixpkgs.
Within a release there are no version bumps, only if you live on unstable or switch to a new release you would get them.
The problem of an actual snapshot of your entire system is that you don't really now what should be in there and it collects a lot of cruft/state. With NixOS you can write little modules for services and move those between VM/Machines, whatever floats your boat. IMHO this type of config management sucks less than ansible/chef etc because you are not fighting against the package manager. The configuration holds the ground truth on what is installed on the system.
It is faster because socat creates additional copies/context switches when forwarding data. This tool changes the bind syscall so it becomes a unix socket in the first place.
crate2nix is better maintained alternative to carnix: https://github.com/kolloch/crate2nix
The cache is still useful though if you think about CI builds or having a common project in a team.