4 ms·

Correct me if I'm wrong but isn't the better solution to this containerization? The application will in a literal sense own the system. You also get inherent s

Correct me if I'm wrong but isn't the better solution to this containerization? The application will in a literal sense own the system. You also get inherent security (unless someone figures out how to escape their vm). I member someone had a website talking about this. The use of a file system with revision tracking, containerization for security, and sending files between VMs to make things work.

seagreen 10y ago
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?
dezgeg 10y ago
Containers don't handle the case where two different versions (or otherwise conflicting variants) occur in the whole dependency tree. For instance, consider program A with direct dependencies B and C, where B needs version X of /usr/bin/D but C needs version Y of /usr/bin/D.
- gravypod 10y ago
  I just remembered that the thing I was talking about was SubUser [0]. You can read their manifesto since it better describes everything that they are looking for. Their solution is to keep file revisions so if you need an older version of a file it is still there. [0] - http://subuser.org/ http://subuser.org/
angrygoat 10y ago
Containers solve a related, but different problem. They help you black box some application so that you can split out the application state (on volumes) from the application itself – and you don't have to worry about things trampling on each other. Nix gets you a reproducible environment – which is just as applicable to building containers. Most containers on docker hub would be very hard to exactly reproduce, if you build them with nix you don't have that issue.
davexunit 10y ago
Containers are but one type of virtualization. What manages the host machine running the container? Nix (and Guix, the project I work on) can be used for everything: bare metal, virtual machine, container. Furthermore, the packaging strategy also allows for granular virtualization of environments. Sometimes all you need is to set a few environment variables ($PATH and such) to point at a specific set of software, and this is made easy because Nix doesn't use a global /usr directory and has a notion of "profiles" that allow you to pick and choose the software you'd like for any given project. If all you have is containers, everything looks like a crate.

seagreen 10y ago

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?

dezgeg 10y ago

Containers don't handle the case where two different versions (or otherwise conflicting variants) occur in the whole dependency tree. For instance, consider program A with direct dependencies B and C, where B needs version X of /usr/bin/D but C needs version Y of /usr/bin/D.

gravypod 10y ago
I just remembered that the thing I was talking about was SubUser [0]. You can read their manifesto since it better describes everything that they are looking for. Their solution is to keep file revisions so if you need an older version of a file it is still there. [0] - http://subuser.org/ http://subuser.org/

angrygoat 10y ago

Containers solve a related, but different problem. They help you black box some application so that you can split out the application state (on volumes) from the application itself – and you don't have to worry about things trampling on each other. Nix gets you a reproducible environment – which is just as applicable to building containers. Most containers on docker hub would be very hard to exactly reproduce, if you build them with nix you don't have that issue.

davexunit 10y ago

Containers are but one type of virtualization. What manages the host machine running the container? Nix (and Guix, the project I work on) can be used for everything: bare metal, virtual machine, container. Furthermore, the packaging strategy also allows for granular virtualization of environments. Sometimes all you need is to set a few environment variables ($PATH and such) to point at a specific set of software, and this is made easy because Nix doesn't use a global /usr directory and has a notion of "profiles" that allow you to pick and choose the software you'd like for any given project. If all you have is containers, everything looks like a crate.