Live data from Hacker News

Nix – Death by a Thousand Cuts

dgt.is

151–160 of 336 posts

Re: Nix – Death by a Thousand Cuts

#151
Whenever I see "declarative" these days, I get suspicious.

See what people are promising when they say "declarative" is a dream. You just tell the computer the final state you want, and the language does what it needs to do to get there.

The problem here, is that in order for that to work, the language has to know how to get where you want it to go, and give you vocabulary to tell it that. That "how to get there" and "vocabulary" has to be written in a (gasp!) general-purpose language.

So now, you come across a situation where you need the declarative language to do something it doesn't know how to do. So now you're forced into the position of helping create the declarative language. And as it turns out, creating a declarative language in a general-purpose language is a lot harder than just using a general-purpose language to tell the computer how to go where you need it to go in the first place, because you have to delve into an existing codebase which is inevitably giant.

I've begun to refer to this anti-pattern as "Configuration-Oriented Programming" (COP).

I'm being a little facetious here--I've not looked into Nix enough to have any educated opinions on it. But it sounds like my outsider impression that Nix is a COP might not have been too far off.

Re: Nix – Death by a Thousand Cuts

#152

Have my server infrastructure on NixOS. Huge boost in productivity and stability, would never go back to standard linux. But man if something breaks it's a nuke going off. Sry for the long post, but thought I share my experience: Mass storage on a big encrypted RaidZ array of spinning rust, no issues. Bootloader, /boot, Encrypted Root and Databases on Mirrored NVME Drives. And man is that a nailbiter on each update.…

I replied to your issue at https://github.com/openzfs/openzfs-docs/issues/531. Not sure if it will be any help, but that's how I'm doing my mirrored zpool EFI boot partitions.

Re: Nix – Death by a Thousand Cuts

#153

I've been on the fence about Nix. I've wanted to love it (and do love the concept), but between the Waiting-for-Godot situation for flakes, the weird language, and the occasional political infighting I've seen pop up about the community, I still haven't switched. I'm no language expert, but I genuinely don't understand why it wouldn't have been better to build some equivalent DSL in Haskell to do this given the simil…

I'm using Universal Blue now (Aurora, i.e. KDE flavour) and I'm very happy with it. With its large amount of pre-installed packages and drivers (including proprietary ones), I still didn't need to install any custom package (rpm-ostree) or otherwise modify the OS config (except for turning off SELinux in /etc/sysconfig/selinux). It's the most pragmatic distro I've used so far. SaveDesktop[0] (saves flatpak apps and D…

Docker and flatpak suck so much if you want to customize anything

Re: Nix – Death by a Thousand Cuts

#154
post #63

I've been on the fence about Nix. I've wanted to love it (and do love the concept), but between the Waiting-for-Godot situation for flakes, the weird language, and the occasional political infighting I've seen pop up about the community, I still haven't switched. I'm no language expert, but I genuinely don't understand why it wouldn't have been better to build some equivalent DSL in Haskell to do this given the simil…

I switched away from Nix OS and eventually landed on GNU Guix, which I have stayed on for about 4 years now. One of the main reasons I switched away from Nix was because of the language, and how underdocumented it all felt. GNU Guix was a breath of fresh air, using a language with decades of academic backing outside of the context of Guix (SICP was awesome for getting into it) and the whole system is very well docume…

Guix has stripped away the biggest plus from NixOS: the module system and replaced it with a half assed system

Re: Nix – Death by a Thousand Cuts

#155

I use NixOS as my daily driver. I concur. I wouldn't recommend it for most people (even for me, when I decided to give it a try). I'd probably just go Arch if I were to do it over again. The concept behind Nix/NixOS is amazing, but it needs to be polished. Flakes are the future, but they are languishing in this experimental status. Even simple things like installing packages from stable and unstable channels are too…

My experience has been in complete agreement with yours: I love the theory, but the practice is so, so painful. And yes, I also had to settle for your NVIDIA fix. I suspect I would have had a marginally better time on Arch as there are more people beating their heads against it and documenting how they made it work. NixOS documentation is piss-poor in comparison.

Most people don't realize that you can read the arch wiki and put the same settings into the nixos options. Where is the point in replicating that all again?

Re: Nix – Death by a Thousand Cuts

#156
I will say I really love the outcome of a Nix development environment. Especially with nix-direnv having a reproducible build environment by doing git clone on any machine is amazing. NixOS has also saved my ass a couple times doing kernel updates on an old laptop, rollbacks are nice. Having consistent commands "nix build"/"nix run" is great. It's a universal build system that works across different technology stacks. Pain to setup, but bliss when it's working.

The bad part is the impenetrable errors and obscure configuration. Although, with the rise of LLMs I find it's not as bad. Getting a non-trivial flake.nix setup is much easier now. Could never remember the override system before, but can manage with Chat GPT haha.

Re: Nix – Death by a Thousand Cuts

#157

I use NixOS as my daily driver. I concur. I wouldn't recommend it for most people (even for me, when I decided to give it a try). I'd probably just go Arch if I were to do it over again. The concept behind Nix/NixOS is amazing, but it needs to be polished. Flakes are the future, but they are languishing in this experimental status. Even simple things like installing packages from stable and unstable channels are too…

Installing packages from different channels is still far easier than on any other distro. Try getting a Debian 10 package to work on Debian 13. You can't. GUI programs are hard because how GUIs work on Linux. You cannot make them easily pure, they always rely on the booted system through drivers and a bunch of impure things all over the place.

If the software you are using has race conditions in its build system then there is only so much you can do to fix that. You could for example run nothing in parallel with only one core but then everything would be painfully slow. Also the occasional network hickup breaks things. Lately also io_uring in combination with nodejs has been a great source for kernel bugs. You can only bang the software so much from the outside.

Nvidia is bad because Nvidia is bad but at least switching between different driver versions and variants is possible without leaving a trace of old things behind on your system like on literally any other distro.

Re: Nix – Death by a Thousand Cuts

#158
post #68

I love NixOS, it's my daily driver on my personal laptop, but it definitely has given me more than its fair share of headaches. If everything you're going to do is in Nixpkgs, great! Nix will mostly "Just Work" and you'll get all the nice declarative goodness that you want. Since Nixpkgs is constantly getting updated, this isn't that weird of a thing. The thing that's been most annoying to me is when I try and run ge…

You can just use nix-ld to run anything that is somewhat closely resembled.

Re: Nix – Death by a Thousand Cuts

#159
post #106
post #68

I love NixOS, it's my daily driver on my personal laptop, but it definitely has given me more than its fair share of headaches. If everything you're going to do is in Nixpkgs, great! Nix will mostly "Just Work" and you'll get all the nice declarative goodness that you want. Since Nixpkgs is constantly getting updated, this isn't that weird of a thing. The thing that's been most annoying to me is when I try and run ge…

Love NixOS and Nix in general (just not the language). I've started using `steam-run` to run things I'm too smooth brain to port.

That will likely soon stop working because steam-run is no longer a grab bag for literally every library out there.

Re: Nix – Death by a Thousand Cuts

#160
post #131
post #77

Earlier quoted context omitted.

As a heavy container user myself - I've been using containers since I needed to build my own 3.x kernel to test them - docker doesn't solve the reproducibility problem nix solves - IE, I can make a Dockerfile that does `RUN curl foo.com/install.sh` and who knows if that'll work ever again. Nix on the other hand doesn't allow you to do IO during builds[^0] only describe the effect of doing the IO. [0]: Though apparent…

You can just store the actual container though. Which will reproduce the environment exactly, it's just not a guidebook on how it was built. The value of most reproducibility at the Dockerfile is that we're actually agnostic to getting a byte-exact reproduction: what we want is the ability to record what was important and effect upgrades.

I'm not talking about a bit perfect reproduction though, just being able to understand dependencies. Take for example a simple Dockerfile like

``` FROM python:latest ADD . RUN pip install foo ```

If I run this today, and I run this a year from now, I'm going to different versions of `python` and `foo` and there is no way (with just the Dockerfile) to know which version of `foo` and `python` were intended.

Nix on the other hand, forces me to use a git sha[^0] of my dependency; there is no concept of a mutable input. So to your point it's hard to 'upgrade' from version a -> b in a controlled fashion if you don't know what `a` even was.

[0]: or the sha256 of the depedency which yes, I understand that's not easy for humans to use.

Post reply on HN