Our great sponsors
-
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
-
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
nixos-infect
[GPLv3+] install nixos over the existing OS in a DigitalOcean droplet (and others with minor modifications)
> Flakes copy the entire directory into the nix store. This is terrible for mono-repos - and especially if it contains any large files. There is an issue about making the copying of the entire directory into /nix/store lazy - though this doesn't really address the problem. It just treats some common symptoms.
Could you not just do a sparse checkout for monorepos?
https://github.com/NixOS/nixpkgs/pull/135881
fwiw nixpkgs has significantly more packages than arch (including the aur), and those packages are also significantly more up to date. No other repo comes close to nixpkgs in this regard. This has been the case for quite some years now.
https://repology.org/
> I can speak new instances of my environment into existence
You're not kidding. I used nixos-anywhere [1] for the first time the other day. You can point it to any linux host and it will partition, format, and supplant the target's existing OS with your nixOS config, all with a single command. Incredible.
[1] https://github.com/numtide/nixos-anywhere
I also really like flakes. I know they are still experimental today - though hopefully that'll improve with this RFC - but they make it trivial to have an out of tree package. For example I just recently created a flake for a vendor OpenOCD fork [0] - and now I can reference that in my home-manager config or from some other project.
[0] - https://github.com/benpye/openocd/blob/mrs-2023-08-07/defaul...
Those Linode instructions are about installing an OS from an installation ISO from Linode's rescue mode. -- I'd consider that more a 'plus' to Linode that you get to be able to install whatever unsupported Linux on Linode's VMs. But, of course it's not as smooth as the officially supported images.
Sibling comment mentions that NixOS provides ways to build VM images (e.g. https://github.com/nix-community/nixos-generators has a generator specifically for Linode).
Another option is to use nixos-infect, which will replace a Linux distribution with a NixOS distribution. https://github.com/elitak/nixos-infect
> At that point, I feel like all of the repeatability gains are gone. If I want to spin up a fresh server, I have to read a guide and set stuff up by hand?
Just as with ansible, "git pull to deploy". You'd keep a copy of your NixOS configuration.nix somewhere else, and would be able to apply it later.
> it really does let me just get a new VPS and deploy to it very fast
Using a tool you're familiar with to get the job done is going to be faster than learning to use a tool you're unfamiliar with.
I believe much of the use of NixOS is for hobby stuff, and for personal machines. (c.f. "In what environments do you use Nix", Development (1242) vs Home Server (845) vs Production (386) https://discourse.nixos.org/t/2022-nix-survey-results/18983).
Those Linode instructions are about installing an OS from an installation ISO from Linode's rescue mode. -- I'd consider that more a 'plus' to Linode that you get to be able to install whatever unsupported Linux on Linode's VMs. But, of course it's not as smooth as the officially supported images.
Sibling comment mentions that NixOS provides ways to build VM images (e.g. https://github.com/nix-community/nixos-generators has a generator specifically for Linode).
Another option is to use nixos-infect, which will replace a Linux distribution with a NixOS distribution. https://github.com/elitak/nixos-infect
> At that point, I feel like all of the repeatability gains are gone. If I want to spin up a fresh server, I have to read a guide and set stuff up by hand?
Just as with ansible, "git pull to deploy". You'd keep a copy of your NixOS configuration.nix somewhere else, and would be able to apply it later.
> it really does let me just get a new VPS and deploy to it very fast
Using a tool you're familiar with to get the job done is going to be faster than learning to use a tool you're unfamiliar with.
I believe much of the use of NixOS is for hobby stuff, and for personal machines. (c.f. "In what environments do you use Nix", Development (1242) vs Home Server (845) vs Production (386) https://discourse.nixos.org/t/2022-nix-survey-results/18983).
Yes, to get Nixpkgs it's much faster to use `fetchTarball`.
You're right that `builtins.fetchTarball` is faster than `builtins.fetchGit` (due to the ridiculous amount of commits in the Nixpkgs repo). I like to keep such definitions in a single, company-wide/project-agnostic git repo (what the Nix Pills series calls the "repository pattern"), and have individual projects import them via `builtins.fetchGit`.
Many years ago we didn't have `builtins.fetchGit`, so had to use the 'fetchgit' function from Nixpkgs instead. That created a chicken-and-egg situation if we wanted to take the Nixpkgs version from some other git repo; hence needing to "bootstrap" via `(import { config = {}; }).fetchgit`, and cross our fingers that `NIX_PATH` wasn't set to some crazy value (which, of course, I would inevitably do... https://github.com/Warbo/haskell-te/blob/24475a229908caa3447... )
Note that we need `config = {};` when importing Nixpkgs to avoid an impurity which tries to read files in $HOME. More recent versions of Nixpkgs also need `overlays = [];` to avoid another impurity (looks like this changed at Nixpkgs 17.03, according to https://github.com/Warbo/nix-helpers/blob/master/nixpkgs.nix )
Yes, to get Nixpkgs it's much faster to use `fetchTarball`.
You're right that `builtins.fetchTarball` is faster than `builtins.fetchGit` (due to the ridiculous amount of commits in the Nixpkgs repo). I like to keep such definitions in a single, company-wide/project-agnostic git repo (what the Nix Pills series calls the "repository pattern"), and have individual projects import them via `builtins.fetchGit`.
Many years ago we didn't have `builtins.fetchGit`, so had to use the 'fetchgit' function from Nixpkgs instead. That created a chicken-and-egg situation if we wanted to take the Nixpkgs version from some other git repo; hence needing to "bootstrap" via `(import { config = {}; }).fetchgit`, and cross our fingers that `NIX_PATH` wasn't set to some crazy value (which, of course, I would inevitably do... https://github.com/Warbo/haskell-te/blob/24475a229908caa3447... )
Note that we need `config = {};` when importing Nixpkgs to avoid an impurity which tries to read files in $HOME. More recent versions of Nixpkgs also need `overlays = [];` to avoid another impurity (looks like this changed at Nixpkgs 17.03, according to https://github.com/Warbo/nix-helpers/blob/master/nixpkgs.nix )