[Nix-dev] [Nix-commits] SVN commit: nix - r30127 - in nixos/trunk/modules: config installer/cd-dvd installer/generations-dir installer/tools installer/tools/nixos-deploy-network misc security services/misc services/monito...

Marc Weber marco-oweber at gmx.de
Wed Nov 2 04:34:14 CET 2011


Some points:
- nix-collect-garbage will collect garbage of the builtins /nix/store
  path, right?
- you're case 2 (recovery) could be replaced by introducing a salt 
  such as passing a dummy var to a derivation everything depends on.
  I agree that there are use cases which this doesn't catch such as
  other databases (eg change from filesystem based to sqlite) or
  eventually even debug filesystem issues. Its trivial to mount
  /dev/X to /nix-test/{var,store}

- testing is only important if there are use cases? And several people
  have used nixpkgs in their $HOME directory in the past so it does
  matter

  Question: Would user mode linux be an option instead?
  I mean if you use user mode linux you can reuse hydra binaries.
  Using user mode linux you can run most test cases on virtualized
  hardware. The current qemu/kvm based test cases require a dedicated
  machine.
   
- About breaking: Yes it will break - but its also easy to fix in most
  cases. And most cases can be caught by a simple grep command.
  So we could even create a pro-commit hook or check.
  
> 5. Having multiple stores on a single system, each with paths built 
> using NixOS. Applications of multiple stores might include private 
> stores for sensitive configurations, having different stores with 
> different levels of trust (e.g. one store that only contains 
> locally-built packages that takes precedence in $PATH and such, but 
> another that uses substitutors so you can get stuff done while you're 
> waiting for your local build to finish), allowing non-privileged users 
> to use their own substitutors, etc.
Can you provide more details? I still don't understand.

I mean do you want to use
/nix/root-store/*  which may contain passwords and which root may only access?

/nix/store/* for the rest of the users?

What happens if you start any service which changes user id and tries to
access its libraries?

So which kind of data do you want to protect? Looks like we should find
a solution.


> 6. Branding. Not a big concern right now, I know, but if NixOS gets big 
> (fingers crossed!) and others want to rebrand it, why not let them use a 
> custom-branded store path?
What do you mean?

/nix/marc-store/
/nix/shea-store/

? I think the strength about nix is sharing. You can share.
The *branding* is what other distros have to do (duplicate everything
within a chroot).

Do you have this is mind or is it just a "could be done idea nobody will
ever actually use?"

It doesn't matter. I'm for the feature because it doesn't hurt much and
recovery might be a valid point in very rare cases - and then you're
glad that it exists even though I agree that the common use case does
not require it.

Marc Weber


More information about the nix-dev mailing list