You must log in or register to comment.
I don’t understand what this has that any other package manager, yum, apt etc doesn’t.
dependencies stored in their own unique directory
Yeah so?
it’s replicable and “atomic”, which for a well-designed modern package manager shouldn’t be that noticable of a difference, but when it’s applied to an operating system a la nixos, you can (at least in theory) copy your centralized exact configuration to another computer and get an OS that behaves exactly the same and has all the same packages. And backup the system state with only a few dozen kilobytes of config files instead of having to backup the entire hard drive (well, assuming the online infrastructure needed to build it in the first place continues to work as expected), and probably rollback a bad change much easier
you can (at least in theory) copy your centralized exact configuration to another computer and get an OS that behaves exactly the same and has all the same packages.
As can you with grepping your history of apt commands? And back up that to a file of a few dozen kilobytes too.
Am I stupid?
assuming you have never used anything except apt commands to change the state of your system. (and are fine with doings superfluous changes eg. apt install foo && apt remove foo)
Maybe that’s what I’m missing then. So with NIX, I need to make all config changes through it? I can’t change any config files myself? Or start a program with a certain flag?
with nixos, the states of all the config files are collected into the nix configuration which you can modify manually. And if there’s something that can’t be handled through that, I think the common solution is to isolate the “dirty” environment into a vm or some other sort of container that I think comes with nixos
(and there’s always going to be “data” which isn’t part of the “configuration” … which can just be used as a configuration for individual applications)
with nixos, the states of all the config files are collected into the nix configuration which you can modify manually.
Okay now that’s cool. Now I’m getting it.
I guess that happens even if you install nix in another OS?
with another OS nix is not going to be “in control” so it’s probably more limited. I’m not sure how common using nix is outside of nixos.
also I’ll point out that many other linux distros I think recommend doing a full system backup even immediately after installation, the “grep history” thing is not very stable as eg. apt installing a package today will default to the newest version, which didn’t exist 1 year ago when you last executed that same command.
Sort of, but e.g. in case of MacOS you’ll have some apps that can’t be installed as Nix packages and some things that can’t be configured in OS
Also was not mentioned, since every dependency is unique you should have no trouble discerning versions that look the same, but in fact configured different or depending themselves on different versions of things, and introducing breakages that way. If you find that some specific configuration of dependency is causing you trouble, you can switch to a different one even if another package depends on this troublesome version.
Fireship is consistently one of the best tutors on YouTube
Each package and its dependencies are stored in their own unique folder
If all those electron / web app haters could read, they’d be very upset right now.
?
This is completely different from electron. Nix dependencies will be shared if they share the same hash. Electron just blindly copies everything over every time.
Electron just copies over the browser engine required to run it, from a package management standpoint, assuming you’re using nom or yarn, it functions the same as nix.
