Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Curse of NixOS

blog.wesleyac.com

Post reply on HN
Print view View original

111–120 of 361 posts

Re: The Curse of NixOS

#111

Post by mindslight »

kstenerud wrote: post #87
ghostwriter wrote: post #28

Earlier quoted context omitted.

> My real gripe with Nix is the lack of a complete, easy to find, documentation of its "standard library". Nix Pills & a few wiki pages are far from enough. How hard have you tried? It's literally two clicks and one scroll away from the official home page: https://nixos.org/ -> click "Learn" -> Scroll down -> click "Full Nix Manual": https://nixos.org/manual/nix/stable/expressions/builtins.htm...

The other problem is the condescending replies from the higher tier nix folks while everyone else struggles. I almost think they garner a sadistic pleasure in watching everyone fail. After months of "It's obviously this" and "you're not even trying" and "have you even looked?" and "there are plenty of examples out there already" and "you should start out by reading the introduction docs" and "you obviously don't know…

I think the impedance mismatch is because some things are really simple, but are not documented in a way that is discoverable by someone who doesn't know, and is searching in the paradigm they do know.

I was trying to figure out how to install new machines from a central build host. Neither the straightforward install CD process, nor system.build.qcow2 made sense. I popped into the IRC channel to ask, and it turns out a 'nix build' 'nix copy', 'nix-env --store --set' and 'switch-to-configuration boot' did the trick. That's an extreme amount of power and simplicity that just kind of obviates a whole set of heavyweight processes (eg Debian automated-install). But if you are searching around for the usual type of automated install process, you just come up empty handed looking for it.

Re: The Curse of NixOS

#112

Post by nh2 »

AshamedCaptain wrote: post #26
Throwaway194902 wrote: post #22

Earlier quoted context omitted.

NixOS and Guix do _not_ require static linking. They go even one step further and allow many versions of a dynamic object to exist at the same time and each software on your system chooses, which version of the object to link against.

You cannot change the version used by a given binary unless you rebuilt that binary, effectively making it similar to static linking (you still get sharing of DSO files & pages, though). i.e. even if I have two versions of some low-level library installed, depending installed packages still hardcode which one of the two low-level libraries to use, and if I want to switch the system from one to the other, I have to re…

It is correct to say that dynamic linking with rebuild-on-input-dependency-change (like NixOS does) is similar to static linking when it comes to rebuild behaviour.

However, also remember that changing dynamic libraries behind executables back is a concept that only makes sense in the presence of ABI compatibility. This is predominantly a C concept (or at least popular in the C world), and much less so for other linked programming languages like C++, Haskell, Go, and so on. Thus Nix being a general-purpose build system takes the general route here, and builds can also use their dependencies during the build step (e.g. a packaged program's autoconf suite might check the version or a symbol provided by a library), which requires full rebuilds for reproducibility.

(Nix is working on content-addressed instead of input-hash-haddressed builds, which might open the door for avoiding many rebuilds that do not affect build _output_.)

That said, it might still be quite easy to achieve what you want:

* If you want to iterate on a C library that's early in the dependency graph, in am ABI-compatible fashion, you coul duse LD_LIBRARY_PATH or LD_PRELOAD on it.

* If you want to override libc in an ABI-compatible way, you can use `patchelf` with its `--set-interpreter` and `--set-rpath` flags to replace the libc an executable is linked against after the fact. For example, you can make an `.override` of a nix derivation that just `cp -r`'s the existing files, and then calls `patchelf` on them.

I have used both these methods to work around glibc bugs that I patched out, avoiding even to have to recompile my own software at the top of the build dependency tree.

Some more relevant links about replacing glibc specifically:

* https://github.com/NixOS/nixpkgs/issues/50329

* https://github.com/NixOS/nixpkgs/issues/129595

If you want to replace things system-wide instead of for your own software, the `system.replaceRuntimeDependencies` mentioned by a sibling comment might be a good choice.

Re: The Curse of NixOS

#113

Post by mplanchard »

rgoulter wrote: post #96
mplanchard wrote: post #53

Earlier quoted context omitted.

The best way I’ve found around this is to always keep a local clone of nixpkgs so that I can grep for where functions are defined and hope like hell that there are some comments in the vicinity. Definitely not ideal.

If you're using Nix on your system, you can also find nixpkgs symlinked under ~/.nix-defexpr/channels/nixpkgs/pkgs/ or so.

Nice, I did not know this. Thanks!

Re: The Curse of NixOS

#114

Post by MayeulC »

AshamedCaptain wrote: post #26
Throwaway194902 wrote: post #22

Earlier quoted context omitted.

NixOS and Guix do _not_ require static linking. They go even one step further and allow many versions of a dynamic object to exist at the same time and each software on your system chooses, which version of the object to link against.

You cannot change the version used by a given binary unless you rebuilt that binary, effectively making it similar to static linking (you still get sharing of DSO files & pages, though). i.e. even if I have two versions of some low-level library installed, depending installed packages still hardcode which one of the two low-level libraries to use, and if I want to switch the system from one to the other, I have to re…

Guix has graft for something similar to this: https://guix.gnu.org/manual/devel/en/html_node/Security-Upda...

It's one of the points where it differs from Nix.

Re: The Curse of NixOS

#115

Post by jeofken »

Does anyone have some tips on how I can partition an EFI laptop for NixOS with full disk encryption? I’m struggling to install NixOS on my Librem 14 - and have resolved to Ubuntu as it does all that for me.

Re: The Curse of NixOS

#116

Post by bokchoi »

light_hue_1 wrote: post #83

Nix has two kinds of problems: the language and the interface. They can solve interface problems, but the Nix language is a tumor that won't be easily removed. The problem is that Nix the language is the worst of all worlds: - You can't print anything because the language is lazy. Forcing any values to print them can and will result in random operations happening on your store. You can never know which values are saf…

> The commandline experience is terrible. Nothing makes any sense. Not the names of the tools. Not their arguments. Why sometimes something is a binary and other times it's a mode of another tool, etc.

As a casual user of nix, this is the worst. I can never remember commands and it just increases barrier to entry. Git has a bad command line UI but nix is far worse even after their recent command line improvements.

Edit: that said, I do like using home-manager to manage configs across multiple machines even though it can be confusing.

Re: The Curse of NixOS

#117

Post by all2 »

kstenerud wrote: post #87
ghostwriter wrote: post #28

Earlier quoted context omitted.

> My real gripe with Nix is the lack of a complete, easy to find, documentation of its "standard library". Nix Pills & a few wiki pages are far from enough. How hard have you tried? It's literally two clicks and one scroll away from the official home page: https://nixos.org/ -> click "Learn" -> Scroll down -> click "Full Nix Manual": https://nixos.org/manual/nix/stable/expressions/builtins.htm...

The other problem is the condescending replies from the higher tier nix folks while everyone else struggles. I almost think they garner a sadistic pleasure in watching everyone fail. After months of "It's obviously this" and "you're not even trying" and "have you even looked?" and "there are plenty of examples out there already" and "you should start out by reading the introduction docs" and "you obviously don't know…

This right here is enough for me to not even bother tying this OS. I'm always interested in operating systems (and the adjacent config systems that live on top of the Linux kernel, Arch Linux is one of those, Gentoo is another). But I'm not so interested in adding vitriol to my life, no matter the technical excellence. I'd rather live with a mundane kludge than deal with knowledge elitism.

Re: The Curse of NixOS

#118

Post by qudat »

I didn't go all-in with nixos -- and I'm thankful I didn't.

I simply tried using it for local development. I thought that I could replace the various language version managers with nix. I spent weeks working with nix to understand the language, how to use it, and reading as much documentation/blogs as possible.

One really frustrating thing about nix I noticed early on is the lack of support for older language versions. For example, if you want to use something like ruby2.2 you'll get a notice saying that the package is insecure and it won't allow you to install it. They mention an environment variable you can set to get around it but even that didn't work properly. Is my use-case not relevant to nix? Even the simplest requests are met with unavoidable blockers. Frustrating.

Something simple like installing a specific `node` version, corresponding `yarn`, and have it work just as well as `nvm` proved to be a challenge.

I managed to get it working relatively well until I ran into weird issues with native bindings on a project that I have literally never seen before. Issues with `dlopen` and the ilk just made me frustrated enough to post this:

https://twitter.com/neurosnap/status/1485427740610375680?s=2...

I'm not even talking about the final stage of nix where all my npm packages are shasum'd and checked into nix, I'm simply installing two packages: node and yarn. Something this simple didn't work for every project I had. This is all not to mention that I have to add a `flake.nix` and `flake.lock` to every project or create some nix repo where I put all these files.

I love the idea of nix and nixos and really wanted to get it to work. Ultimately it's just not there yet and I'm not sure it ever will be.

Right now, the time you save by using nix is completely lost when you traverse down the rabbit hole of outdated documentation and never ending bugs with the actual system.

Re: The Curse of NixOS

#119

Post by nicoburns »

qudat wrote: post #118

I didn't go all-in with nixos -- and I'm thankful I didn't. I simply tried using it for local development. I thought that I could replace the various language version managers with nix. I spent weeks working with nix to understand the language, how to use it, and reading as much documentation/blogs as possible. One really frustrating thing about nix I noticed early on is the lack of support for older language version…

I've recently discovered `asdf` (https://github.com/asdf-vm/asdf). It's not as technically clever as nix, but it does allow you to manage version of most language toolchains with one tool.

Re: The Curse of NixOS

#120

Post by smasher164 »

For me, Nix is one of those systems where I just had to spend a long time with it to understand it. It wasn't something I could master within a few weeks. After about a year of continued use and struggle, I've finally gotten to the point that I'm comfortable going off the beaten path and even contributing to nixpkgs.
Post reply on HN