- Feb 2021
-
toraritte.github.io toraritte.github.io
-
A derivation from a Nix language view point is simply a set, with some attributes. Therefore you can pass the derivation around with variables like anything else.
-
the single repository technique. The natural implementation in Nix is to create a top-level Nix expression, and one expression for each package. The top-level expression imports and combines all expressions in a giant attribute set with name -> package pairs. But isn't that heavy? It isn't, because Nix is a lazy language, it evaluates only what's needed! And that's why nixpkgs is able to maintain such a big software repository in a giant attribute set.
This is the gist of how Nixpkgs works (and how it is organized).
-
17.3. Fixed point
QUESTION: What is a fixed-point of a function?
ANSWER: See this video) at least, and the Fixed-point (mathematics)) wikipedia article:
In mathematics, a fixed point (sometimes shortened to fixpoint, also known as an invariant point) of a function is an element of the function's domain that is mapped to itself by the function. That is to say, c is a fixed point of the function
f
iff(c) = c
. This meansf(f(...f(c)...)) = f n(c) = c
an important terminating consideration when recursively computing f. A set of fixed points is sometimes called a fixed set.
For example, if f is defined on the real numbers by
f(x)=x^{2}-3x+4,}
, then 2 is a fixed point off
, becausef(2) = 2
.There is also the wiki article fixed-point combinator that actually plays a role here, but read through the articles in this order.
Then dissect the Stackoverflow thread What is a Y combinator?, and pay attention to the comments! For example:
According to Mike Vanier's description, your definition for Y is actually not a combinator because it's recursive. Under "Eliminating (most) explicit recursion (lazy version)" he has the lazy scheme equivalent of your C# code but explains in point 2: "It is not a combinator, because the Y in the body of the definition is a free variable which is only bound once the definition is complete..." I think the cool thing about Y-combinators is that they produce recursion by evaluating the fixed-point of a function. In this way, they don't need explicit recursion. – GrantJ Jul 18 '11 at 0:02
(wut?)
Other resources in no particular order:
- google search for "fixpoint evaluation fixed point combinator explained"
- Cornell's CS 6110 S17 Lecture 5
- google search for "fixed-point of a function"
- Fixed-point theorem (wikipedia)
- How can I find the fixed points of a function? (math stackexchange)
- The Y Combinator (Slight Return) (see the "Fixpoint of functions" section)
- Clear, intuitive derivation of the fixed-point combinator (Y combinator)? (computer science stackexchange)
- Fixed-Point Combinators (stackoverflow)
- Fixed-point combinator (HandWiki)
QUESTION: How the hell did they come up with the idea of using this with Nix and package management? (..and who? I remember a video saved somewhere, but maybe that was about overlays)
QUESTION: ... and how does it work in this context?
ANSWER: Well, not an answer yet, but this may be something in the right direction:
http://blog.tpleyer.de/posts/2020-01-29-Nix-overlay-evaluation-example.html
-
there's no ldconfig cache either. So where does bash find libc?
QUESTION: What is
ldconfig
cache?QUESTION: What is
libc
and why does Bash need it? -
Derivations/packages are stored in the Nix store as follows: /nix/store/hash-name, where the hash uniquely identifies the derivation (this isn't quite true, it's a little more complex), and the name is the name of the derivation.
QUESTION: So the Nix store houses derivations and not the built packages?
QUESTION: Are the hashes in the Nix store not unique?
-
In Nix there is the notion of a derivation rather than a package. The difference can be subtle at the beginning, so I will often use the words interchangeably.
Doesn't really say anything but thought it important to highlight this first mention of derivations in the Nix Pills.
-
From an administrator's point of view: you can use containers. The typical solution nowadays is to create a container per service, especially when different versions are needed. That somewhat solves the problem, but at a different level and with other drawbacks. For example, needing orchestration tools, setting up a shared cache of packages, and new machines to monitor rather than simple services.
This is a very good pointer; I guess it refers to systemd services when it mentions "simple services".
-