4 ms·

The great things about NixOS is that you can describe the entire state of your system in configuration files, and then after running `rebuild` know that what's

The great things about NixOS is that you can describe the entire state of your system in configuration files, and then after running `rebuild` know that what's on your computer _exactly_ matches that configuration. Can you do that with containers? For instance, I'm on NixOS `16.09.git.20f009d (Flounder)`. Here's my configuration: https://github.com/seagreen/vivaine https://github.com/seagreen/vivaine. I know my machine exactly matches the combination of that NixOS version + those config files. My impression is that this is messier with containers because while you can make a snapshot and know the snapshot is frozen, as you modify snapshots over time they'll begin accumulating cruft due to things like installing programs, uninstalling them, snapshotting, but still having some leftovers from the install. I'd like to hear from someone with more container experience here though.

gravypod 10y ago
Is there any real advantage to that opposed to say running this on my arch machine... yaourt -Qe|grep -v "(base"|grep -v "(xorg"|grep -v "lib32"|cut -f 2 -d "/"|cut -f 1 -d " " > package_list.txt Then to reinstall... pacman -S package_list.txt And copy in my home directory. After a reboot everything should work the same way I have it setup (I keep every change I possibly can in my home directory. It's everything aside from two scripts that aren't actually needed) The difference is I generate my config via usage, not via definition. I don't actually know what I need to use my computer, I've just always used it. I can back everything up and create essentially the same machine (since my distro Manjaro is rolling) every time I need it. For me, this is a solution that is a bandaid fix for a completely different problem: the lack of rolling distributions and the lack of storing old versions. These are both package manager and os developer problems. Once we leave the space of OS revisions rather then having "The OS" and having it up to date or out of sync with the main os we will fix these problems. I don't know, am I seeing something wrong?
- aseipp 10y ago
  You don't get features like transactional rollback to prior revisions of your system definition, which is never an important feature (until it suddenly is). This also seamlessly allows non-privileged multi-user package management without duplication of programs or anything like that, so you don't need to poke your system admin or alternatively pollute $HOME (and in turn pollute your bash/zsh config for library paths, require fixing up include paths for anything you compile using $HOME stuff, etc). This feature is actually particularly important, because it allows you to set up individual, 'hermetic' (or 'pure') build environments for every project, using 'nix-shell', even on multi-user machines. If the project supports Nix, you can just go in and run 'nix-shell', and your machine is magically populated with the needed dependencies to build it (or using already existing ones), and you drop into a new `bash` with a cleaned environment and custom $PATH for that project. You can then leave that shell (after you submit your patch to an upstream project or whatever) and garbage collect the installed dependencies. The model also permits things like transparent, remote multi-system/architecture builds (why build the Linux kernel in my chosen configuration on my laptop when I have a 16 core server somewhere else, why SSH into my OSX machine to run a build when Nix can do it with the same description, etc,) -- and in the future when binary determinism is worked out, a single checkout of the Nixpkgs repository will (hopefully) be able to serve as completely-reproducible build chain, allowing anyone to produce identical binaries and identical Nix packages. (And since Nix works on any Linux system, you can run that build anywhere). NixOS of course supports general container technology as you mentioned in your first post, so you can also use that to your hearts desire. In practice NixOS is quite powerful but there are still many glitches and user-facing UX issues that are problematic. It is definitely not for everyone.
- seagreen 10y ago
  I don't think so, that looks like the setup I'd like to be using if I was on a more traditional distro. One issue might be the handling of dependencies: does `yaourt -Qe` list everything you have installed or only programs you've given a specific command to install?

gravypod 10y ago

Is there any real advantage to that opposed to say running this on my arch machine... yaourt -Qe|grep -v "(base"|grep -v "(xorg"|grep -v "lib32"|cut -f 2 -d "/"|cut -f 1 -d " " > package_list.txt Then to reinstall... pacman -S package_list.txt And copy in my home directory. After a reboot everything should work the same way I have it setup (I keep every change I possibly can in my home directory. It's everything aside from two scripts that aren't actually needed) The difference is I generate my config via usage, not via definition. I don't actually know what I need to use my computer, I've just always used it. I can back everything up and create essentially the same machine (since my distro Manjaro is rolling) every time I need it. For me, this is a solution that is a bandaid fix for a completely different problem: the lack of rolling distributions and the lack of storing old versions. These are both package manager and os developer problems. Once we leave the space of OS revisions rather then having "The OS" and having it up to date or out of sync with the main os we will fix these problems. I don't know, am I seeing something wrong?

aseipp 10y ago
You don't get features like transactional rollback to prior revisions of your system definition, which is never an important feature (until it suddenly is). This also seamlessly allows non-privileged multi-user package management without duplication of programs or anything like that, so you don't need to poke your system admin or alternatively pollute $HOME (and in turn pollute your bash/zsh config for library paths, require fixing up include paths for anything you compile using $HOME stuff, etc). This feature is actually particularly important, because it allows you to set up individual, 'hermetic' (or 'pure') build environments for every project, using 'nix-shell', even on multi-user machines. If the project supports Nix, you can just go in and run 'nix-shell', and your machine is magically populated with the needed dependencies to build it (or using already existing ones), and you drop into a new `bash` with a cleaned environment and custom $PATH for that project. You can then leave that shell (after you submit your patch to an upstream project or whatever) and garbage collect the installed dependencies. The model also permits things like transparent, remote multi-system/architecture builds (why build the Linux kernel in my chosen configuration on my laptop when I have a 16 core server somewhere else, why SSH into my OSX machine to run a build when Nix can do it with the same description, etc,) -- and in the future when binary determinism is worked out, a single checkout of the Nixpkgs repository will (hopefully) be able to serve as completely-reproducible build chain, allowing anyone to produce identical binaries and identical Nix packages. (And since Nix works on any Linux system, you can run that build anywhere). NixOS of course supports general container technology as you mentioned in your first post, so you can also use that to your hearts desire. In practice NixOS is quite powerful but there are still many glitches and user-facing UX issues that are problematic. It is definitely not for everyone.
seagreen 10y ago
I don't think so, that looks like the setup I'd like to be using if I was on a more traditional distro. One issue might be the handling of dependencies: does `yaourt -Qe` list everything you have installed or only programs you've given a specific command to install?