171–180 of 186 posts
Earlier quoted context omitted.
fwiw nixpkgs has significantly more packages than arch (including the aur), and those packages are also significantly more up to date. No other repo comes close to nixpkgs in this regard. This has been the case for quite some years now. https://repology.org/
How many of these are duplicates or just multiple versions though?
I still fail to understand the naming conventions behind Nix. I don't know what a "flake" or "derivation" is without double checking, the naming sucks.
> without double checking It's fine, Nix things are conceptually different from anything before. You could say flakes are like Rakefile, but that would be a lie. You could say they're like Gemfile and Gemfile.lock, but that would be a lie too. You could say that derivations are like packages, but that would be a lie, you could say they're like container images but that would be a lie too. Now, you can try to understa…
The docs are much better at describing this as "a derivation is a build task." I don't care that it's the return value of a function call, I don't care that because the language is purely functional it may be called lazy and memoized and so on. They are interesting technologically, but the abstraction is bad if it is so leaky you need to understand the internals to use it.
> You could say that derivations are like packages, but that would be a lie,
> a flake is a central definition of a number of target derivations in the context of a specific source state of dependencies.
It's a package. More specifically, a package definition or description. People understand that the result of package installation depends on the total resolution of dependencies and this may be fairly fine grained or a difficult to parse graph (they just trust that the package manager does the "right" thing). Most modern package managers do this and it's not confusing to call it a package (although, it's in good company because every package manager likes to call their packages something cute and different).
Earlier quoted context omitted.
This is already solved by Docker. I know Docker has a bunch of issues and Nix is clearly a more elegant design, but in practice Docker works fine (at least for my use case).
It's really not. Docker is a tool for binary distribution. Docker images are those binaries. Dockerfiles used to create Docker images don't have any mechanism to ensure reproducibility whatsoever. Unlike Nix, you can't take a Dockerfile and expect builds to succeed. Furthermore, Docker images are monoliths that's isolated from the system. Instead of system administrators choosing the isolation boundaries that best fi…
> Dockerfiles used to create Docker images don't have any mechanism to ensure reproducibility whatsoever
simply generate it once and keep it as an immutable artefact
Earlier quoted context omitted.
> Do you get anything when not using NixOS to manage everything? Sure, I think the biggest benefit is being able to get a temporary environment for a project. You can have all of your dependencies pinned, even for languages that don't have package managers, and for mixed-language projects. You can get easily get a shell that contains the exact compiler versions, libraries, etc. from a single config file, and it's iso…
It's no lighter than a process running in docker, on a Linux machine at least. With docker you have a whole root filesystem packaged up and a process inside it is executed on your system with certain kernel namespacing to set its root filesystem, users, network access, limits on memory and CPU usage, etc. With nix instead of a tarball being the root filesystem it's a bunch of symlinks to stuff in the nix store direct…
Earlier quoted context omitted.
I'm familiar with home manager (or as I like to call it, a hammer looking for a nail, that solves no problem). I don't think home manager has any relationship with flakes. Also, nix solves actual real problems, home manager doesn't. There are better dotfile managers. In fact, vim understands the syntaxes of a lot of dotfiles, with home manager, you even lose that.
So very package should be a system package, available to every user?
To date I've paid no attention to Flakes because whenever I look at them, they appear to require me to manually list all target architectures in the Flakes file, which is ridiculous. I'm not going to make the code I publish needlessly dependent on specific architectures. This problem seems to be solved commonly in two ways: - People thoughtlessly and senselessly listing only x86; - People using the popular flake util…
> they appear to require me to manually list all target architectures in the Flakes file, which is ridiculous Well, we're talking about evaluating a pure function (literally the entire philosophy of Nix is treating a build like a pure function). Those things are variable state as an input which affects the output, and therefore must be specified as inputs. I don't see the problem here (if you have already accepted th…
Nothing is ultimately pure since you're running on top of a kernel which can affect computation. It's unclear to me what practical gain you get from trying to obsessively get "maximum purity", which is in any case illusory because you're still running on a kernel from outside the closure.
Making it impossible to write portable code isn't a good design.
Earlier quoted context omitted.
As a counter-anecdote, as someone who used to be a newcomer to Nix, it took until I encountered flakes before I went "aha, this is how it was always meant to be".
Do you have much development experience? I've been wondering lately whether the helpfulness or difficulty associated with flakes depends on familiarity with Nixlang and readiness to approach Nix code as code .
Earlier quoted context omitted.
Do you have much development experience? I've been wondering lately whether the helpfulness or difficulty associated with flakes depends on familiarity with Nixlang and readiness to approach Nix code as code .
Lots and lots, yes, but only really in strongly- statically-typed languages; I have hated Nixlang since the moment I first set eyes on it.
FWIW I like Nixlang, but I agree that static typing would improve it. Maybe Nickel some day, blah blah blah :)
Earlier quoted context omitted.
Loading in the whole container though does increase the necessary RAM — with nix, two versions of the same executable can link to the same hash, but it is unlikely to be the case with Docker.
Your kernel is fine at managing the container root filesystem and paging in and out parts as necessary. It's not just loading gigabytes of root fs into memory and calling it good.
Earlier quoted context omitted.
Loading in the whole container though does increase the necessary RAM — with nix, two versions of the same executable can link to the same hash, but it is unlikely to be the case with Docker.
Your kernel is fine at managing the container root filesystem and paging in and out parts as necessary. It's not just loading gigabytes of root fs into memory and calling it good.