61–70 of 227 posts
I wish guides like these contained screenshots. Do people use Nix for desktop OSes? As a VM they SSH into? A collection of config scripts that they don't directly issue commands to? I certainly can't tell from a quick glance of this guide
Earlier quoted context omitted.
It may not be a fad, but there's a lot of rose-colored hype that masks a world of tedium. New prospective users should be prepared for a lot of uphill grind with respect to configuring packages or defining their own packages. Every time I try to do seemingly simple tasks in Nix, I end up spending hours on the Nix discord channel trying to work out a solution with seasoned users (who invariably struggle to work out a…
> MacOS is still a second-class citizen in the Nix world and a fair amount of stuff doesn't work properly In my experience: With fewer nix users on macOS, it's more likely you'll run into software which isn't in the binary cache, & so will compile from source. (brew also does this). With fewer nix users on macOS, it's may take longer for packages broken on macOS to be fixed. It's a bit more of a hurdle to use .app pr…
I just use brew for .apps (and only for .apps) when I'm on macOS.
Nix flakes has indeed made it all quite a bit easier. But, sadly, in the interim, there are lots of things in an in-between state.
Earlier quoted context omitted.
For me, the "borking" issue is largely resolved by running Btrfs. Just make a snapshot shortly before updating, and then I can revert to it if needed.
My problem is i don't know what gets borked immediately after updating unless it's catastrophic. Ie i've gone a fair bit of time before i realized some specific functionality of some program no longer works due to some unrelated change in an underlying dependency that i was unaware of. Oof. Granted Btrfs sounds great though, i've not used that. It would certainly help.
I just take occasional snapshots before I do things that I'm concerned may be catastrophic. But it definitely won't catch everything. It helps that I run Arch, and I update packages once a day, which only leaves me with under 40 (small) packages usually. So a quick cursory glance at which ones are updating usually tells me what to be cautious of. Display driver update, kernel update, etc.
If I'm not sure what went wrong, but I at least have a working snapshot, then I can get done what I need to get done, and then go back to troubleshooting. Rather than just having a broken system regardless.
> echo "Hello Nix" | nix run "nixpkgs#ponysay" why on earth would you make # any kind of a special character in commands. who thought of that
$ echo a#b
a#bEarlier quoted context omitted.
Is this more deterministic than pointing Nixpkgs at a specific commit/tarball in the configuration? I have often done this to make reproducible builds in other Nix settings and it has worked well.
Yes, because it also makes your Nixpkgs config explicit (doesn't read ~/.config/nixpkgs/config.nix unless you source it in-repo) and doesn't rely on env vars (e.g., NIX_PATH) which are not given explicitly in the flake. But pinning Nixpkgs alone does get you much of the way there (and for many use cases— those where the only referent on it is 'nixpkgs' or 'nixos'— does make NIX_PATH redundant anyway).
What is missing compared to using flakes? The only `NIX_PATH` components I normally use is `nixpkgs` which hooks into the whole channel system (which is bad), but by settings my `pkgs` variable to a specific commit/tarball, I can ignore `NIX_PATH` entirely, right?
Earlier quoted context omitted.
Is this more deterministic than pointing Nixpkgs at a specific commit/tarball in the configuration? I have often done this to make reproducible builds in other Nix settings and it has worked well.
It is: using Flakes you're thrusted into a more pure evaluation mode by default, and it creates a (standard) artifact of the revision you're on: the flake.lock. You can get almost all the benefits Flakes brings without Flakes using alternatives like niv.
Can you name a specific example of the kind of nondeterminism/nonreproducibility I risk by simply pinning Nixpkgs itself (or to be more principled, using Niv)?
I wish guides like these contained screenshots. Do people use Nix for desktop OSes? As a VM they SSH into? A collection of config scripts that they don't directly issue commands to? I certainly can't tell from a quick glance of this guide
What problem does this solve?
- dependency conflicts
- build reproducibility
- configuration management
- configuration drift
- package management on restricted systems (i.e., installing stuff when you're not root)
- shared library duplication
- inconsistent state/broken system after a botched upgrade
(A lot of people also enjoy using it for their dotfiles, since it works on macOS as well as across all Linuxes. I personally love it on desktops and development workstations as well.)
Is Nix good at dealing with cuda dependencies? I am always frustrated trying to deploy cuda-based environments onto machines with different sorts of GPUs.