Follow

Doing a garbage collection broke my OCaml setup, this package manager is way too complex to be wielded by humans.

@otini By breaking, you mean you had to rebuild everything or it just stopped working altogether?

If it's the later case, it might worth at least to open an issue and try to figure out a minimal repro.

@Ninjatrappeur I'm honestly not sure, some problem showed with the Opam-installed Merlin unable to find a configuration file for findlib. Probably a stray root, yes.

cc @pureevil

@otini if something called a gc has effects observable inside the system it's broken imo. if you can't detect all real roots you must be conservative

@migratory Probably something that I compiled inside a Nix shell. Since Nix shells don't create GC roots, the things we create in them can end up missing dependencies after a GC.

This is a very frustrating thing with Nix: anything that is not perfectly integrated into the package system risks to become unusable at any moment.

cc @amiloradovsky

@otini @migratory You're supposed to only operate with the paths coming from / relative to the inputs. Not find(1) the files in the whole Nix store etc. That's only reserved for debugging.

I guess sandboxing should help with catching the undeclared dependencies:

- nixos.org/nix/manual/#conf-san

- nixos.org/nix/manual/#conf-san

My own stance on Nix is like that on Git — hard to navigate and could be better, but still worth using, in place of the conventional approaches anyway.

@amiloradovsky @otini "you're holding it wrong" is the redoubt of leaky abstractions. the OS shouldn't be a leaky abstraction.

I've always felt Nix should have implemented its path magic kernelside so it could be robust. the kernel would read tags on executables indicating which deps they have access to, then it would direct their fs accesses to corresponding versions of dependencies (and disallow other access to /usr and /lib). it would disallow single programs depending on multiple versions of dependencies, but the upside in being able to run software that wasn't compiled for NixOS once you tag it with dependency versions would be huge. and you couldn't "accidentally" reach into the store and break the whole abstraction

@migratory @otini Nix is essentially a quick and dirty implementation of an ideas described in a thesis. Safety and security has never been it's primary goal. It uses symlinks for it's data-structures and everything is visible to everyone. People voiced the opinion that it should provide better isolation, but e.g. Qubes OS in comparison doesn't let the access to GPU etc.

To recap: Nix is a trade-off, this is not "fool-proof". Sure you can hurt yourself with it, if not careful enough.

@otini It is! This + emacs-direnv let's you load the right env directly in emacs like a breeze.

There's one major downside so far: it works *really* poorly with IFD. So if your workflow is haskell.nix-based, the integration will sucks.

@otini WRT the GC breaking stuff, you must have forgotten to declare a dependencies.
WRT Nix's complexity, you must have not used Guix…

Sign in to participate in the conversation
Functional Café

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!