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

Nix – Death by a Thousand Cuts

dgt.is

Post reply on HN
Print view View original

191–200 of 336 posts

Re: Nix – Death by a Thousand Cuts

#191

Post by postcert »

soraminazuki wrote: post #47
VTimofeenko wrote: post #7

Earlier quoted context omitted.

For those pesky random executables there's a couple of escape hatches -- buildFHSenv and nix-ld. This is also predicated on good provenance of the executables in question. One should probably not even ldd sketchy binaries: https://jmmv.dev/2023/07/ldd-untrusted-binaries.html

Even proper packaging is far easier compared to other package managers. Typical distros push users away from packaging their own software, so users end up relying on ad-hoc solutions instead. Nix instead makes packaging easier by having proper tools to abstract away the nitty gritty details. For random binaries, autoPatchelfHook works miracles.

It wasn’t that bad creating some new derivations my first week with Nixos, I was so used to Arch where I had maybe a handful modified pkgbuilds over a decade.

For better or worse it was a positive experience, especially when you usually already have a pkgbuild to go off of.

Re: Nix – Death by a Thousand Cuts

#192

Post by ajb »

tombert wrote: post #178
SuperSandro2000 wrote: post #170

Earlier quoted context omitted.

I delete your entire system file system right now. How fucked are you? With NixOS: I don't care. You can recover from a half deleted root file system.

My root filesystem is actually just in-memory for NixOS using tmpfs [1]. If you were to trash my root filesystem, I just reboot and it's restored. I know of no other operating system that allows something like that. To quote a friend: "A new car smell on every reboot." [1] https://elis.nu/blog/2020/05/nixos-tmpfs-as-root/

Well OpenWRT does, but probably not what you want on your laptop :-)

Re: Nix – Death by a Thousand Cuts

#193

Post by ofrzeta »

edude03 wrote: post #160
XorNot wrote: post #131

Earlier quoted context omitted.

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…

Well, what about "FROM python:3.18" and using requirements.txt or something like that? I mean, running an arbitrary Python version will get you in trouble anyway.

Re: Nix – Death by a Thousand Cuts

#194

Post by ofrzeta »

azeirah wrote: post #139
rob_c wrote: post #72

Earlier quoted context omitted.

It's basically, I refuse to learn how to containerize. Just learn, use, promote best practices and stop forking the ecosystem _even_ further... There, I got that off my chest.

Huh? I use Nix to create containers. Nix is a programming language, a build tool, a package manager and an entire ecosystem of extremely powerful tools. The entire reason why I use Nix in the first place is because it allows me to containerize with _better_ reproducibility than docker itself. I do get where you're coming from though. It's not immediately clear that Nix can do all this stuff. Nix is a lot more than ju…

> Nix is a programming language, a build tool, a package manager and an entire ecosystem of extremely powerful tools

You have identified part of the problem.

Re: Nix – Death by a Thousand Cuts

#195

Post by ofrzeta »

stouset wrote: post #140
Baeocystin wrote: post #65

The older I get, the more I realize that so much of the divide in the tech field is simply between the two camps of "the tools are the interesting part" vs "getting things done with the tools is the interesting part".

I tend to agree. I also think both sides need to learn to better appreciate the other. Without people getting shit done with the tools we’ve built, there would be no demand for better tools and no need to write them. Without better tools, the things we can get done are limited. Better tooling is an exponent to our productivity. The things we can accomplish today would have been nearly unimaginable nearly thirty years…

> The things we can accomplish today would have been nearly unimaginable nearly thirty years ago.

Like what? Witing an entire operating like Linux or Windows NT from scratch?

Re: Nix – Death by a Thousand Cuts

#196

Post by whazor »

dingi wrote: post #190
whazor wrote: post #130

Earlier quoted context omitted.

Nix currently has the most packages of any distribution, see https://repology.org/ The model of having packages on Github with pull requests scales very well. Therefore, you could argue that people are getting things done with Nix.

> Nix currently has the most packages of any distribution, see https://repology.org/ This is a meaningless point. Different distros split packages differently.

While I agree that it’s somewhat difficult to compare. Especially as node and python packages are separately packaged in Nix.

However it is clear that the Nix folks are quite productive with maintaining packages. So that statement is judgemental, as it implies that all those packages are not ‘the right things to get done’.

Re: Nix – Death by a Thousand Cuts

#197

Post by nothrabannosir »

tomn wrote: post #174
_huayra_ wrote: post #55

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 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 similar lazy nature of the language. My impression is that you can't really build nix as a DSL in haskell, because the core insight of nix is to introduce the "derivation" function into a pure programming language, whose behaviour is pure (the output is determined by…

I don’t understand—the language itself is completely contained and separate from the derivation. Evaluation could be done in any language and the derivation will remain the output. You can absolutely have a better language generate derivations, surely? Hell, you could use Python typescript or go if you wanted to. They’d even be completely compatible with the unholy mess of cursed bash that is stdenv.

What you can’t port over to another language as neatly are the modules. Good riddance, id say. Undebuggable spaghetti from hell.

> from the inside, there's not much of a desire to switch to something better, because the language isn't the thing that gives people trouble after the initial learning period (which would exist with any host language).

Unfortunately I have wasted enough of my life to call myself “on the inside” and IMHO the language itself is close to the number one threat to wider adoption of nix.

Re: Nix – Death by a Thousand Cuts

#198

Post by Cloudef »

Nix has been a godsend at dealing with different dev environments and (cross-)compiling complicated software stacks. When you write a proper nix derivation that runs inside a nix sandbox it does not matter where you run it, you'll have high guarantee it replicates the result for you anywhere.

Re: Nix – Death by a Thousand Cuts

#199

Post by theo0833 »

denkmoon wrote: post #186
SuperSandro2000 wrote: post #155

Earlier quoted context omitted.

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?

My one big question about nix is how the hell do I find out those options? Like cool, I know I need to set the config to some specific value based on arch wiki, but how do I read the nix package to find out what config "key" to use? I've never been able to work out where these are defined

try https://search.nixos.org/options .

Re: Nix – Death by a Thousand Cuts

#200

Post by lmm »

photonthug wrote: post #180
lmm wrote: post #166

Earlier quoted context omitted.

> Which will reproduce the environment exactly, it's just not a guidebook on how it was built. By that logic every binary artifact is a "reproducible build". The point of reproducibility isn't just to be able to reproduce the exact same artifact, it's to be able to make changes that have predictable effects. > The value of most reproducibility at the Dockerfile is that we're actually agnostic to getting a byte-exact…

I do get the theoretical annoyance of how it’s technically not reproducible, but in practice most containers are pulled and not built from scratch. If you’re really concerned about that apt-get then besides a container registry you’re going to host a private package repository too, or install a versioned tarball from a public URL, but check the hash of whatever you’re downloading and put that hash in the dockerfile.…

> If you’re really concerned about that apt-get then besides a container registry you’re going to host a private package repository too, or install a versioned tarball from a public URL, but check the hash of whatever you’re downloading and put that hash in the dockerfile.

Right, but if you're doing that then you probably don't need to bother with the docker part at all.

> you notice when you’re changing / extending the dockerfile.. which is the time and place where you’d expect to need to know

You notice, sure, but you can't see what it was. Like, sure, it's better than it failing when you come to deploy it, but you're still in the position of having to do software archaeology to figure out how it ever worked in the first place.

Like, for me the main use case for reproducible builds is "I need to make a small change to this component that was made by someone who left the company 3 years ago and has been quietly running since then", and you want to be able to just run the build and be confident it's going to work. You don't necessarily need to build something byte-for-byte identical to the thing that's currently running, but you do need to build something equivalent. The reproducibility isn't important per se but the declarativeness is, and with Docker you don't get that.

Post reply on HN