Since an acquaintance showed me https://roadmap.sh a couple of weeks ago, I have been brewing on the idea of building different roadmaps with different angles for learning Nix. When I read the Nix Ecosystem Mind Map thread and @hugosenari provided an actual roadmap to their Nix learning some time last year, it prompted me to share this idea.
I see two purposes for making Nix roadmaps:
To improve the process of documenting Nix: to structure learning material, get an overview of common dependencies, so that they can be provided, and so that dependencies are more clearly mapped out. For example, a lot of services depend on secrets, and secrets management isn’t particularly easy.
To make it easier to learn Nix: Roadmaps are made for learners and educators alike. They’re not really meant as a documenter’s working tool, but rather a learner’s overview with which you can interactively track your progress. I’m not necessarily talking specifically about https://roadmap.sh, which is a SaaS, but the general idea of Skill Trees as described in the article Structuring Competency-Based Courses Through Skill Trees by Hildo Bijl.
Roadmaps can reference existing learning material; so it’s a way to structure the wealth of scattered and/or overlooked material. (Had I just known how valuable nix.dev is before I started, and sunk a fair amount of hours into it early on, I would’ve been smarter sooner.)
But if this Discourse thread is a lower barrier to entry, feel free to just write here.
I’m interested in…
your Nix roadmaps, if you made any
your feedback for some first roadmaps: both titles and content
your contributions to shared roadmaps of which there currently are none
I will structure them using https://roadmap.sh to begin with, but am interested in providing them in a more open format. Having a particularly good, coherent roadmap may serve as the basis for improving the currently disabled Nix Exercism track. Before that project is revived, it’d be nice to have an overview, and a roadmap can provide that, since it resembles the way modern Exercism tracks are modelled.
On a semi-related note: I’ve been entertaining the thought of compiling
possible development trajectories for Nixpkgs architecture (or for Nix)
into a similar format. Think a world of warcraft-style character
development tree, but the “skills” you unlock are “late binding in
python3Packages”, “checkPhase derivation”, or “immutable src”, “load
graphics drivers via libcapsule”, “$ORIGIN-relative DT_RUNPATHs”, etc. -
or , for (S)Nix, “FUSE /nix/store” followed by “Lazy input realization”,
or “CDC” followed by either of N variants of “castore GC”, etc. Resp.,
the “modifiers” you get from “skills” can be “# rebuilds reduced by
50%”, or “gdb can now find sources”, or “Run OpenGL apps from a
newer-than-system Nixpkgs revision”, or “Nixpkgs GUI apps work on
Ubuntu”, or “reduce cache.nixos.org size by 70%”
Obviously had no time to even move a finger to make this happen so far…
I have not abandoned making Nix roadmaps. I think that learning Nix is entirely non-linear, so making good roadmaps is difficult and would benefit from a lot of conversation. I’ll see if others are interested in the upcoming documentation team office hours (not yet announced).
“FN” and “FP” for false-negative and -positive respectively.
“Corrupted references” referring to the risk of screwing things up when e.g. rewriting the outputs (for grafting, cadrvs, et c.), or when computing how many "../"s you need in a relative path.
“Relocatability” here is an in “relocating to a different prefix” (sounds silly, but yup, university clusters, namespaces are only recently becoming a thing and still not widespread…).
“Multitenancy” as in “two libcs in the system”, rather than as in ca derivations.
There’s a hypothetical space to put other stuff like vcpkg, conan, easybuild there.
I’m still not familiar enough to decide what stats Spack is supposed to get. “Frugal” here is a placeholder for how Spack and Guix handle reference rewriting, which I just need to dig into that to know for sure…
A branch for snix-style FUSE/virtiofs store, a branch for “late realization”.
Branches for “late(r) binding” like in pyproject-nix, halving the FPs again; a branch for “sink test derivations down to the leaves” (github search for “amjoseph” and “ninja” iirc).
A tree for dynamism, a tree for different sandboxing, for build scheduling, for resource awareness, for eval memoization…
Amazing,
I’m the kind board writer who you’d think I was writing while in plane in turbulence. So you have impressive writing board skills from my perspective.
I would just add the legend (FP: False Positive Cache, FN: False Negative Cache) to board.
Thanks for your contribution, would be cool tho create a topic about your board and discuss this its content.
