Rail service is funded at the federal level, so there's less arguing about who pays for what. Bus service, however, is managed by regional transport associations funded by the provinces. This creates disincentives for cross-province bus routes because no single province wants to pay more than its 'fair' share for a service that primarily benefits voters in another province.

Similar dynamics play out at the city/province level. Take Linz, the provincial capital of Upper Austria: the city has had a social democratic (SPÖ) mayor continuously since 1945, while the province has had a conservative (ÖVP) governor for exactly the same period of 80 years. This disincentivizes the province government from helping to fund public transport within or into the city, because it's a win for social democratic city voters, while the more conservative rural voters would rather take the car anyway since they often can't do the whole trip by public transport.

Arguably the reason for the excellent public transport in the city of Vienna is that they are also their own province. Their mayor/governor, who has been a social democrat as well for the last 80 years, always controls both levels of funding.

If you purpose-build these tools to work with Nix, in the big picture view how these functional units of composition can affect each other is much more constrained. At the same time within one unit of composition, you can iterate over a whole imperative multi-step process in one go, because you're always rerunning the whole step in a fresh sandbox.

LLMs and Nix work together really well in that way.

I also agree with you when it comes to the task of auditing every line of Nix code that factors into a given system. Nix doesn't really make things easier there.

The benefit I'm seeing really comes from composition making it easier to share and direct auditing effort.

All of the tricky code that's hard to audit should be relied on and audited by lots of people, while as a result the actual recipe to put together some specific package or service should be easier to audit.

Additionally, I think looking at diffs that represent changes to the system vs reasoning about the effects of changes made through imperative commands that can affect arbitrary parts of the system has similar efficiency gains.

Defenders should not have to engage in an costly and error-prone search of truth about what's actually deployed.

Systems should be composed from building blocks, the security of which can be audited largely independently, verifiably linking all of the source code, patches etc to some form of hardware attestation of the running system.

I think having an accurate, auditable and updatable description of systems in the field like that would be a significant and necessary improvement for defenders.

I'm working on automating software packaging with Nix as one missing piece of the puzzle to make that approach more accessible: https://github.com/mschwaig/vibenix

(I'm also looking for ways to get paid for working on that puzzle.)

It's keeping flake-specific data locally, to guarantee that it matches how the user ended up with the data, not how the builder produced it. I think otherwise from the user POV such data could again look misleading.

It's kind of crazy how much there is to know about Nix. I wish there was a bit less surface area to the language. On the other hand it's really interesting how much specialized knowledge there is in the community around various topics. Some people package things, some people write library code, some write glue code that wraps other build tools, some write VM-based tests, some write generators that transform store paths into things like container images, some just manage their dot files, some are experts for how we deal with some specific proprietary ecosystem like cuda, some write infra code or tools around the Nix code, some work on one of the Nix implementations.

It saves you from escaping stuff inside of multiline-strings by using meaningful whitespace.

What I did not like about CCL so much that it leaves a bunch of stuff underspecified. You can make lists and comments with it, but YOU have to decide how.

It very much builds on the hash-based cache lookup mechanism this paper calls constructive traces (in contrast to what they call deep constructive traces) to eliminate transitive trust relationships.

https://dl.acm.org/doi/10.1145/3689944.3696169

My idea for financing this is finding a few companies who pay a retainer fee to not only get direct easy access to my expertise when they need it, but are also interested in the results of the kind of work I'm doing when they don't need anything specific from me.

I work on supply chain security with systems like Nix, and recently put up a first version of a website: https://groundry.org/

What works better is keep track of those hashes as part of the signatures, which is already happening. There's a lot of interesting things that can be done with that kind of information, I'm one of the people working on that kind of stuff.

Basically I have a paper out about how verifiable and reproducible can come together like that in Nix:

https://dl.acm.org/doi/10.1145/3689944.3696169

That stuff is useful to humans, but it is also really useful for cold hard automated logical reasoning about dependency trees.

What you should be able to do in the future with a system like nix plus a few changes is use nix as a common underlying mechanism for precisely describing build steps, and then use whatever policy you like to determine who you trust.

One policy can be about having an attestation for every build step, another one can be about two different builders being in agreement about the output of a specific build step.

That way you can construct a policy that expresses reproducibility, and reproducibility strengthens any other verification mechanism you have, because it makes it so that you can aggregate evidence from different sources. and then have different build hosts

https://news.ycombinator.com/item?id=43030046

The intensional store makes the store shareable without also sharing trust relationships ('kind of trustless' in that sense), but only because it moves trust relationships out of the store, not because it gets rid of them. You still need to trust signatures which map an hash of inputs to a hash of the output, just like in the extensional model. You can however get really powerful properties for supply chain security from the intensional store model (and a few extra things). You can read about that in this recent paper of mine: https://dl.acm.org/doi/10.1145/3689944.3696169. I'm still working on this stuff and trying to find ways to get that work funded (see https://groundry.org/).

I think they want their project to be smart enough to just 'figure out what to do' on behalf of the user.

That appeals to a lot of people, but I think them stuffing all backends into one binary and auto-detecting at runtime which to use and is actually a step too far towards simplicity.

What they did to support both CUDA and ROCm using the same binary looked quite cursed last time I checked (because they needed to link or invoke two different builds of llama.cpp of course).

I have only glanced at that PR, but I'm guessing that this plays a role in how many backends they can reasonably try to support.

In nixpkgs it's a huge pain that we configure quite deliberately what we want Ollama to do at build time, and then Ollama runs off and does whatever anyways, and users have to look at log output and performance regressions to know what it's actually doing, every time they update their heuristics for detecting ROCm. It's brittle as hell.