Strip out some things, new intro for PDT

README.md

@@ -1,35 +1,8 @@
-# My Nix Roadmap
+# Content-addressed derivations -> Dynamic Derivations Nix roadmap
 
-> [!WARNING]
+We at Obsidian were very pleased with the reception of [Sandstone](https://github.com/obsidiansystems/sandstone) ([slides](https://github.com/obsidiansystems/sandstone/blob/slides/planet-nix-2025.pdf)) at [Planet Nix](https://planetnix.com/).
-> This is my own personal set of priorities and plan to get there.
+As the end of the talk says, it's time to bring these experiments to a close --- we want to use these things!
-> It should be assumed the rest of the Nix Team, or Nix Steering Committee, either agrees or disagrees.
+The rest of this document is a deep dive --- almost brain dump! --- into what is left, at various scales of granularity.
-
-For at least the first version, I am doing a pretty raw "brain dump".
-There are probably tons of things which lack explanation, and will make little sense to many people.
-That will be fixed over time; ideally in may cases by properly documenting things (that aren't changing) in the Nix reference manual, so I can merely link those references here.
-There may also be things I change my mind on.
-That's an unavoidable chicken-and-egg problem:
-Ideally this kicks off conversations that I wouldn't have otherwise, and its through those conversations that this road-map gets better and better.
-
-### Background and basic objectives
-
-One of the core planks of my [steering committee candidacy](https://github.com/NixOS/SC-election-2024/blob/main/candidates/Ericson2314.md) was that
-
-- Nix should be properly usable as an incremental build system, not just "package manager"
-
-  - That means we need "early cut-off" (content-addressing derivations)
-  - That means we need some form of dynamic dependencies (dynamic derivations)
-
-<!--
-- Nix must be able to run everywhere
-
-  - That means running on Windows too
-
-  - An working better for users that have limited perms
--->
-
-There are some other general goals around separating concerns in the code, modularity, and extensibility, but I describe them in less detail so far.
-I also want to talk about Windows support, but that will have to wait for a later version of this document.
 
 ## Roadmap
 
@@ -195,26 +168,6 @@ There are some usability improvements such as
 But I don't think either of these will be too much work.
 Dynamic derivations is a relatively "cheap" extension to content-addressing derivations.
 
-### Modularity, extensibility (and also the new CLI)
-
-One of my least favorite things with the new (and old CLI) is that there are way too many flags on commands, many of which seemingly are unrelated to the command in question.
-There is a reason for this, however, which is that the current design of Nix actually makes it really hard to know what settings affect what operations, because the settings are stored in big globals that *any* code is able to peek at.
-So to make the UI better, we need to get rid of those globals.
-
-Of course, this is also table stakes for making the Nix code a good library too: callers need to be in control, with no pointless external state.
-This enables many novel use-cases, via projects build around Nix extending it in various ways.
-Experience shows that many organisations using Nix often have special needs, e.g. special scheduling requirements.
-A good library foundation allows organisations to serve their needs by themselves, without being blocked on upstream.
-
-For the longest time, I was stumped on how to begin this very large untangling, but in recent months I found a way.
-Tackling the main configuration system head-on is just too hard: it is too entertwined with many other things.
-The store settings, however, is relatively more self contained.
-And as a bonus many settings should move to being store settings anyways.
-[Nix#11139] successfully reworks the store settings, solving a number of problems in one big patch.
-[Nix#10761] on top of that tackles the rest of the store settings.
-That second PR is still very WIP, and I suspect may well end up becoming multiple PRs.
-But, it is in much better shape than earlier attempts because it gets to reuse new infrastructure which is independently created and proven fit-for-use in the previous store settings overhaul.
-
 [Nix#5025]: https://github.com/NixOS/nix/issues/5025
 [Nix#8602]: https://github.com/NixOS/nix/issues/8602
 [Nix#11895]: https://github.com/NixOS/nix/issues/11895
@@ -232,5 +185,3 @@ But, it is in much better shape than earlier attempts because it gets to reuse n
 [Nix#12662]: https://github.com/NixOS/nix/pull/12662
 [Nix#12591]: https://github.com/NixOS/nix/pull/12591
 [Nix#12558]: https://github.com/NixOS/nix/pull/12558
-[Nix#11139]: https://github.com/NixOS/nix/pull/11139
-[Nix#10761]: https://github.com/NixOS/nix/pull/10761