5 ms·

Agreed. I ran Nix for a while.. I love the concept of it, but I ended up bailing for a similar reason. I desired Nix because I wanted simplicity that immutabili

Agreed. I ran Nix for a while.. I love the concept of it, but I ended up bailing for a similar reason. I desired Nix because I wanted simplicity that immutability (conceptually) brings. Yet, the OS and especially dealing with non-immutable packages/etc were just way too much of a headache. I left Nix hoping that in a few years it would be far friendlier. It really feels like the future.

nextos 9y ago
I use NixOS daily, and the rough areas now are mostly lack of really thorough documentation and dealing with software that is not packaged for Nix and has an unclean way of getting built. It's surprising how many pieces of software have hardcoded paths to e.g. Python binaries. My temporary fix for the latter is using a Docker with Arch for quick and dirty one-time things.
- AnIdiotOnTheNet 9y ago
  > the rough areas now are mostly lack of really thorough documentation and dealing with software that is not packaged for Nix So basically the same problems as every other Linux distribution? Only AppImage doesn't work out of the box either. The more things change the more they stay the same.
  - deleted 9y ago
    [deleted]
- pxc 9y ago
  Did you know Flatpak support is on the way? I'm hoping that it can help fill the void for applications which haven't made it into Nixpkgs yet. (And maybe for things we can't build from source, as much as I try to stay away from those.) https://github.com/NixOS/nixpkgs/pull/33371 https://github.com/NixOS/nixpkgs/pull/33371
  - nextos 9y ago
    Yes, my use-case is more complex sadly. It's more about installing some scientific binaries which are generally really dirty to build, in a quick and easy way. I need them to reproduce other papers so I cannot stay away, sadly. I think a better FHS or Steam.Env would help me more.
amelius 9y ago
> and especially dealing with non-immutable packages Are you saying that NixOS allows packages to cheat? That seems like a serious flaw. If there's one thing worse than a non-purely-functional system, then it must be a system that claims to be purely-functional but turns out to be non-functional.
- roblabla 9y ago
  The packages themselves can't mutate, the nix store is read-only (except during installation). But some packages needs a global, mutable state (think databases), which is fine. What isn't fine is that some packages expect that mutable space to be in certain paths, and things get messy. Gitlab comes to mind as a service that's been extremely painful to get working under nixos because it expects its install path to be mutable.
- infinisil 9y ago
  There are ways to get around the immutability, but they are very highly discouraged and I haven't seen anybody use them other than newcomers. Think of it like `unsafePerformIO :: IO a -> a` in Haskell. Namely there is: - Making the Nix store writable. Normally it's mounted read-only, and only the Nix daemon can write finished deterministic builds there. Often wanted by users who haven't learned how to handle Nix packages, as they just want to change some file in the store. - Disabling the sandbox. Usually all builds are done in a sandbox which doesn't have network access, read access only to the Nix store and write access only to only the destination directory in the Nix store (with some exceptions), which gives strong reproducability guarantees.
- tadfisher 9y ago
  I suspect the parent is referring to imperative package installs, i.e. nix-env -i firefox This does create an immutable copy of Firefox in the Nix store, but it's not reproducible in the sense that the profile state isn't captured in a Nix expression.
  - pseudonom- 9y ago
    Though there are a couple more declarative ways to handle user package installs.

nextos 9y ago

I use NixOS daily, and the rough areas now are mostly lack of really thorough documentation and dealing with software that is not packaged for Nix and has an unclean way of getting built. It's surprising how many pieces of software have hardcoded paths to e.g. Python binaries. My temporary fix for the latter is using a Docker with Arch for quick and dirty one-time things.

AnIdiotOnTheNet 9y ago
> the rough areas now are mostly lack of really thorough documentation and dealing with software that is not packaged for Nix So basically the same problems as every other Linux distribution? Only AppImage doesn't work out of the box either. The more things change the more they stay the same.
- deleted 9y ago
  [deleted]
pxc 9y ago
Did you know Flatpak support is on the way? I'm hoping that it can help fill the void for applications which haven't made it into Nixpkgs yet. (And maybe for things we can't build from source, as much as I try to stay away from those.) https://github.com/NixOS/nixpkgs/pull/33371 https://github.com/NixOS/nixpkgs/pull/33371
- nextos 9y ago
  Yes, my use-case is more complex sadly. It's more about installing some scientific binaries which are generally really dirty to build, in a quick and easy way. I need them to reproduce other papers so I cannot stay away, sadly. I think a better FHS or Steam.Env would help me more.

amelius 9y ago

> and especially dealing with non-immutable packages Are you saying that NixOS allows packages to cheat? That seems like a serious flaw. If there's one thing worse than a non-purely-functional system, then it must be a system that claims to be purely-functional but turns out to be non-functional.

roblabla 9y ago
The packages themselves can't mutate, the nix store is read-only (except during installation). But some packages needs a global, mutable state (think databases), which is fine. What isn't fine is that some packages expect that mutable space to be in certain paths, and things get messy. Gitlab comes to mind as a service that's been extremely painful to get working under nixos because it expects its install path to be mutable.
infinisil 9y ago
There are ways to get around the immutability, but they are very highly discouraged and I haven't seen anybody use them other than newcomers. Think of it like `unsafePerformIO :: IO a -> a` in Haskell. Namely there is: - Making the Nix store writable. Normally it's mounted read-only, and only the Nix daemon can write finished deterministic builds there. Often wanted by users who haven't learned how to handle Nix packages, as they just want to change some file in the store. - Disabling the sandbox. Usually all builds are done in a sandbox which doesn't have network access, read access only to the Nix store and write access only to only the destination directory in the Nix store (with some exceptions), which gives strong reproducability guarantees.
tadfisher 9y ago
I suspect the parent is referring to imperative package installs, i.e. nix-env -i firefox This does create an immutable copy of Firefox in the Nix store, but it's not reproducible in the sense that the profile state isn't captured in a Nix expression.
- pseudonom- 9y ago
  Though there are a couple more declarative ways to handle user package installs.