6 ms·

I’m very sorry. But for a person that tries to get into Nix this reads like pure gaslighting. I haven’t even found an official description of what Nix vs NixOS

I’m very sorry. But for a person that tries to get into Nix this reads like pure gaslighting. I haven’t even found an official description of what Nix vs NixOS vs nixpkgs tries to achieve vs what they do not want to achieve. There is a near infinite collection of blog posts what people use Nix for. All full of Nix-internal jargon derisively critiquing alternative (that do in fact actually work) without ever coming out and laying the groundwork for what the underlying problem is _and what the solution to that is_. I think that I would end up liking Nix in principle. I really did enjoy the Spack package management system and I do think Nix is doing things reasonably similarly (everything is Nix, all inputs are securely provided, reusing things as much as possible).y current problem is taking a homelab server into “production” and all I really want is a way to write down a state I want the services on it to be in, have that in a git repo and be able to regenerate this server after loosing it (in a first step without any data backup). I’m still, after 2 months (wall clock, call it maybe 3 days actually getting into this project), not sure if that’s a thing Nix tries to cover! (I think it does, but..)

flurie 1y ago
A lot of work about packaging specifics reads like inside baseball because it is. Most people manage to avoid getting into the specifics of packaging because it’s stuff that mostly gets in the way of the problem they’re trying to solve. But for blessed few packaging is either critical to the problem or is the problem itself. If you never had to learn the inside baseball terminology, it is likely that packaging is not critical to problems that you solve, and I say that without judgment. If you need to get into Nix, you will. There are lots of reasonable ways to manage personal infrastructure that don’t involve Nix. For the problem you describe, I’m not even sure Nix is a preferable solution unless you already use it. That said, I agree with the original comment. I’m willing to believe that they had these problems and that moving away from Nix was the right decision, but there is little detail in the explanation. They’ve been pretty closed users of Nix to my knowledge, building proprietary tools on top of it without contributing back significantly, and it feels like orgs such as repl.it are contributing back more actively, but this may be a marketing difference as well.
- hnaccount_rng 1y ago
  I spend significant parts of my PhD maintaining the packaging and deployment infrastructure of our group. But yes, I have close to no computer science and reasonably little intrinsic interest in the problem space (though I have a deep appreciation). Still I think I have a better than average understanding of the packaging space..
jchw 1y ago
I think you may be overthinking things. In brief; Nix is two things: a functional programming language called Nix, and a package manager written in C++ that compiles and installs packages written with Nix expressions. Nix the language itself, and it's implementation. Nixpkgs is a repository of Nix packages. It also contains NixOS, which is also just a bunch of Nix. NixOS is a Linux-based operating system built on Nix. It is configured using NixOS modules, a configuration system of sorts built on top of the Nix programming language. A NixOS system is literally a single big Nix package built from NixOS modules that depends on a bunch of other packages. If this still seems too complicated it would probably be better to just dive in and mess with it so you can physically see what's going on. > current problem is taking a homelab server into “production” and all I really want is a way to write down a state I want the services on it to be in, have that in a git repo and be able to regenerate this server after loosing it (in a first step without any data backup). I’m still, after 2 months (wall clock, call it maybe 3 days actually getting into this project), not sure if that’s a thing Nix tries to cover! (I think it does, but..) Yes that does sound like something NixOS can cover. Obviously, you will still need backups for your mutable data (databases, files, etc.), but if you are able to encapsulate the entire setup of a server into a NixOS config you can indeed throw a machine out the window and have a new one set up and booting the exact same services in minutes. This is pretty much the original thing that drew me into NixOS, especially because at the time I was highly interested in qemu GPU passthrough setups and I really liked how with Nix all of the complicated setup bits could be expressed in a single file, with about 20 lines of Nix, all accounted for and version controlled. A lot better than just hoping you remember to keep things documented. I won't lie, learning NixOS and using it for a real machine setup was very painful for me at first. I struggled with many things over time. Still, I really think because the scope of things these projects do is huge it's really easy to overcomplicate things. All of the explosive scope of Nix comes from relatively simple primitives applied in large systems. I really don't want to encourage people to suffer with Nix if they feel like it's just too convoluted and hard to work with. I am not trying to convey that Nix is simple or easy on the whole. I was only ever trying to explain why I felt the issues raised by this post were confusing to me, not trying to tell people that Nix is generally easy. I think a lot of replies genuinely continue to misunderstand this, but the point of saying that it's easy to do that in Nixpkgs is not to dunk on people who struggle with Nix, it's to say that it's not clear why Nixpacks would struggle with these particular issues. You can literally just split the /nix/store paths into separate OCI layers. There is no obvious reason why this strategy can't be used, and the blog post doesn't go into the background behind it. I bet there actually is background, it's just left unsaid.

flurie 1y ago

A lot of work about packaging specifics reads like inside baseball because it is. Most people manage to avoid getting into the specifics of packaging because it’s stuff that mostly gets in the way of the problem they’re trying to solve. But for blessed few packaging is either critical to the problem or is the problem itself. If you never had to learn the inside baseball terminology, it is likely that packaging is not critical to problems that you solve, and I say that without judgment. If you need to get into Nix, you will. There are lots of reasonable ways to manage personal infrastructure that don’t involve Nix. For the problem you describe, I’m not even sure Nix is a preferable solution unless you already use it. That said, I agree with the original comment. I’m willing to believe that they had these problems and that moving away from Nix was the right decision, but there is little detail in the explanation. They’ve been pretty closed users of Nix to my knowledge, building proprietary tools on top of it without contributing back significantly, and it feels like orgs such as repl.it are contributing back more actively, but this may be a marketing difference as well.

hnaccount_rng 1y ago
I spend significant parts of my PhD maintaining the packaging and deployment infrastructure of our group. But yes, I have close to no computer science and reasonably little intrinsic interest in the problem space (though I have a deep appreciation). Still I think I have a better than average understanding of the packaging space..

jchw 1y ago

I think you may be overthinking things. In brief; Nix is two things: a functional programming language called Nix, and a package manager written in C++ that compiles and installs packages written with Nix expressions. Nix the language itself, and it's implementation. Nixpkgs is a repository of Nix packages. It also contains NixOS, which is also just a bunch of Nix. NixOS is a Linux-based operating system built on Nix. It is configured using NixOS modules, a configuration system of sorts built on top of the Nix programming language. A NixOS system is literally a single big Nix package built from NixOS modules that depends on a bunch of other packages. If this still seems too complicated it would probably be better to just dive in and mess with it so you can physically see what's going on. > current problem is taking a homelab server into “production” and all I really want is a way to write down a state I want the services on it to be in, have that in a git repo and be able to regenerate this server after loosing it (in a first step without any data backup). I’m still, after 2 months (wall clock, call it maybe 3 days actually getting into this project), not sure if that’s a thing Nix tries to cover! (I think it does, but..) Yes that does sound like something NixOS can cover. Obviously, you will still need backups for your mutable data (databases, files, etc.), but if you are able to encapsulate the entire setup of a server into a NixOS config you can indeed throw a machine out the window and have a new one set up and booting the exact same services in minutes. This is pretty much the original thing that drew me into NixOS, especially because at the time I was highly interested in qemu GPU passthrough setups and I really liked how with Nix all of the complicated setup bits could be expressed in a single file, with about 20 lines of Nix, all accounted for and version controlled. A lot better than just hoping you remember to keep things documented. I won't lie, learning NixOS and using it for a real machine setup was very painful for me at first. I struggled with many things over time. Still, I really think because the scope of things these projects do is huge it's really easy to overcomplicate things. All of the explosive scope of Nix comes from relatively simple primitives applied in large systems. I really don't want to encourage people to suffer with Nix if they feel like it's just too convoluted and hard to work with. I am not trying to convey that Nix is simple or easy on the whole. I was only ever trying to explain why I felt the issues raised by this post were confusing to me, not trying to tell people that Nix is generally easy. I think a lot of replies genuinely continue to misunderstand this, but the point of saying that it's easy to do that in Nixpkgs is not to dunk on people who struggle with Nix, it's to say that it's not clear why Nixpacks would struggle with these particular issues. You can literally just split the /nix/store paths into separate OCI layers. There is no obvious reason why this strategy can't be used, and the blog post doesn't go into the background behind it. I bet there actually is background, it's just left unsaid.