[mschwaig]

I think as AI gets smarter, defenders should start assembling systems how NixOS does it.

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.)

[XorNot]

Nix makes everything else so hard that I've seen problems with production configuration persist well beyond when they should because the cycle time on figuring out the fix due to evaluations was just too long.

In fact figuring out what any given Nix config is actually doing is just about impossible and then you've got to work out what the config it's deploying actually does.

[mschwaig]

Yes, the cycle times are bad and some ecosystems and tasks are a real pain still.

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.

[throwawayqqq11]

You are describing a propper dependency/code hierarchy.

The merging of attribute sets/modules into a full NixosConfiguration makes this easy. You have one company/product wide module with a bunch stuff in it and many specialized modules with small individual settings for e.g. customers.

Sure, building a complete binary/service/container/nixos can still take plenty of time but if this is your only target to test with, you'd have that effort with any naive build system. But nix isnt one of them.

I think that's the real issue here. Modularizing your software/systems and testing modules as independently as possible. You could write test nix modules with a bunch of assertions and have it evaluate at build time. You could build a foundation service and hot plug different configurations/data, build with nix, into it for testing. You could make test results nix derivations so they dont get rerun when nothing changed.

Nix is slow, yes. But only if you dont structure your code in a way to tame all that redundant work, it comes around and bites you. Consider how slow eg. make is and much its not a big issue for make.

[jacquesm]

I think for actual Nix adoption focusing on the cycle time first would bring the biggest benefit by far because then everything will speed up. It's a bit like the philosophy behind 'Go', if the cycle is a quick one you will iterate faster, keep focus and you'll be more productive. This is not quite like that but it is analogous.

That said, I fully agree with your basic tenet about how systems should be composed. First make it work, but make deployment conditional on verified security and only then start focusing on performance. That's the right order and right now we do things backward, we focus on the happy and performant path and security is - at best - an afterthought.

[xeonmc]

Sounds like it’s a gap that AI could fill to make Nix more usable.

[mschwaig]

If you make a conventional AI agent do packaging and configuration tasks, it has to do one imperative step after the other. While it can forget, it can't really undo the effects of what it already did.

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.

[cogogo]

From a security perspective I am far more worried about AI getting cheaper than smarter. Seems like a tool that will be used to make attacking any possible surface more efficient at scale.

[nradov]

Sure, but we can also use AI for cheap automated "red team" penetration tests. There are already several startups building those products. I don't think either side will gain a major advantage.

[landtuna]

This could be worse, too. With more machines being identical, the same security hole reliably shows up everywhere (albeit not necessarily at the same time). Sometimes the heterogeny impedes attackers.

[elnerd]

We soon will have to implement paradoxes in our infrastructure.

[quinnjh]

model based deception is being researched and implemented in high stakes OT environments, so not far from your suggestion!