Hacker News Reader

Comment by notheguyouthink | Hacker News Reader

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.

View on HN

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.

> 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.

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

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.

> 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.

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.

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.

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.

Though there are a couple more declarative ways to handle user package installs.

e.g. https://github.com/gabesoft/nix-conf/blob/master/.nixpkgs/co...

Reply on news.ycombinator.com