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

271–280 of 336 posts

Re: Nix – Death by a Thousand Cuts

#271

Post by SuperSandro2000 »

micahcc wrote: post #9
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

steam-run seems to be able to run everything. It uses bubble wrap to keep the OS isolated and add /usr/bin stuff most exes want.

*it won't be in the future because it is no longer the grabbag for everything.

Also linking things to /usr/bin is done by the fhs which uses bubblewrap, not steam-run.

Re: Nix – Death by a Thousand Cuts

#272

Post by tomn »

microtonal wrote: post #260
tomn wrote: post #218

Earlier quoted context omitted.

> Evaluation is completely pure (at least with flakes, which disallows querying environment variables, etc.). Evaluation of derivations will result in .drv files in the store, but that does not add impurity to the language itself. Building the .drv is a separate step (instantiation). If import-from-derivation is enabled (it normally is, it's a very useful feature, and the foundation of flakes), then some derivations…

If import-from-derivation is enabled I have never looked at the implementation of IFD, but I assume that the evaluation and instantiation are still separated (and Nix will do multiple passes). Even then functions like "readFile" are considered to be pure in nix, but not in haskell. I am pretty sure that, unless you use --impure , all files that are read are required to be in the store. Since the store is read-only, i…

> I am pretty sure that, unless you use --impure, all files that are read are required to be in the store. Since the store is read-only, it does not break purity.

Right, but even then the logical type for readFile would be something like "string -> string" (because from nix's perspective it is pure), but in haskell it would have to be "string -> IO string" (because from haskell's perspective it is not).

Maybe this is fine, i just suspect it would make things messier than expected.

Alternatively this could be worked around using unsafePerformIO or the FFI, but that feels a bit far away from the idea of just making a DSL? Unclear...

> But I don't know why one would want to.

Same, I just think it's an interesting discussion.

Re: Nix – Death by a Thousand Cuts

#273

Post by [deleted] »

pkkm wrote: post #95
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".

Your veiled implication that Nix and NixOS aren't about "getting things done" is, I think, more than a little unfair. I'm using multiple programming languages at work. Each one of them has its own dependency manager that does basically the same job as the other ones. In Python it's Poetry, in Ruby it's Bundler, in JavaScript it's npm/yarn, in PHP it's Composer, etc. A lot of projects require extra setup steps outside…

[deleted]

Re: Nix – Death by a Thousand Cuts

#274

Post by eddd-ddde »

SuperSandro2000 wrote: post #253
eacapeisfutuile wrote: post #101

Earlier quoted context omitted.

That is not why neither Bazel or Buck was created.

Bazel is the bane of my existence. I have never seen such an anti distro tool that is so hostile against your system libraries.

That's the whole point, you can't rely on systems for hermetic builds.

Re: Nix – Death by a Thousand Cuts

#275

Post by tombert »

ajb wrote: post #192
tombert wrote: post #178

Earlier quoted context omitted.

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 :-)

Heh, probably not, though my homemade router is actually based on NixOS with the ephemeral tmpfs root, so kind of the same idea as OpenWRT.

Re: Nix – Death by a Thousand Cuts

#276

Post by 0x457 »

sshine wrote: post #182
nixosbestos wrote: post #114

Earlier quoted context omitted.

Yeah, I am flabbergasted that anyone can claim flakes don't solve problems. And yet, every SINGLE WEEK some newcomer gets tripped up on channels, managing them, realizing the root's channels are different than users, realizing their channels are out of sync on their multiple machines, no posting their channel revision when they solicit help. Not to mention pure eval. Not to mention transitive dependency overriding.

> I am flabbergasted that anyone can claim flakes don't solve problems Yes, that would be an outrageous claim! That is, of course, not what I said. Arguing that channels lead to more problems than flakes is a good argument in favour of adoption of flakes. But you can also abandon channels without adopting flakes. Which is what I said: flakes don’t solve any problems that can’t be solved without flakes.

I mean, nix isn't solving any problems that can't be solved without. This can be said about nearly anything in your universe.

The point is: flakes are solving issues now in nix, and nothing else _right now_ can solve them in nix. I'm using flakes because they are currently the best path forward. Provide an alternative path that is better, and I will switch.

Re: Nix – Death by a Thousand Cuts

#277

Post by 0x457 »

jmholla wrote: post #116
0x457 wrote: post #108

Earlier quoted context omitted.

> My take is: flakes don’t align with centralised nixpkgs and ultimately don’t solve any problems that can’t be solved without flakes. I've turned to flakes to specifically solve some problems, and flaked solved them. To this day, flakes are still the only way to solve them. Flakes aren't default due to political reasons.

> I've turned to flakes to specifically solve some problems, and flaked solved them. To this day, flakes are still the only way to solve them. Can you share some examples of such problems?

1) Channels are hard to maintain (that's why overlays were introduced...)

2) Overlays only solve issue of adding your own packages to an existing channel

3) System channels and user channels are two different things.

4) Many times I've updated my home-manager profile and forgot to update system profile and it borked due to channels being out of sync (user error, but flakes remove that foot gun)

5) Very easy to have portable dev-env. If a system has nix installed, just typing `nix develop` in my repo would put you in the exactly same dev environment as me. In most cases it would byte for byte identical. I'm not going to tell you to install 100 of dependencies, not going to bother you with what application is written in, all you have to do to build it locally is to type `nix build .#`. I'm not even going to bother you how to run test because `nix check` will run them.

6) Flakes provide some schema, you know here nixos or home-manager modules would be.

7) Flakes are easy to compose together

8) I can have identical env on CI, production and my local machine without any extra overhead - flake.lock takes care of this.

All of this is extremely predictable: I got a new laptop, using nix-anywhere I've installed nixos on it, that had pretty much identical look and feel of my desktop. It all boils down to - channels suck and hard to use.

Re: Nix – Death by a Thousand Cuts

#278

Post by rekado »

SuperSandro2000 wrote: post #154
Zambyte wrote: post #63

Earlier quoted context omitted.

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

In all those years working on and playing with free software, I still cannot understand the incessant need for badmouthing other projects and calling things "half-assed". What a destructive habit!

Re: Nix – Death by a Thousand Cuts

#279

Post by lloeki »

theo0833 wrote: post #199
denkmoon wrote: post #186

Earlier quoted context omitted.

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 .

Or https://mynixos.com/ which is hierarchically navigable. I usually search for a package or setting name and browse around.

Re: Nix – Death by a Thousand Cuts

#280

Post by cge »

edude03 wrote: post #77
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.

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…

>who knows if that'll work ever again

Unless you restrict your nix files to specific channel revisions, which when I had to deal with it was poorly documented, and involved searching through specific channel commit hashes in a particularly opaque way, you also can't know that your nix derivations will ever work again.

A number of people on my field used nix as a way to make their research code repositories reproducible, and everything broke within around three years.

Post reply on HN