grhmc

Hey y'all, I'm Graham the CEO of DetSys. Determinate Secure Packages has been a huge effort we've made to help customers in the national security, medical, aerospace, etc. industries more comfortable using Nix in their workflows.

In pretty much every Nix consulting gig I’ve ever had, I’ve been asked something like "well, what about security patching?" This has been a high priority goal since I started Determinate Systems. We just had to build a lot of infrastructure and maturity as a company to make it feasible :).

Anyway, if you have any questions I'd be glad to answer. Thanks!

Yikes! This is exactly the kind of invariant I'd expect Aurora to maintain on my behalf. It is why I pay them so much...

Hey folks, CEO of Determinate here. We've been working on this for ages, and am thrilled to finally have it rolling out to real users. Let me know if you have questions!

Yeah! It also skips a lot of IO and other complicated bits, which hopefully pans out to being more reliable and performant!

DetSys CEO here. We've been working on this for months, and I am so excited for this to be out. This is the third time I've been part of a Linux remote builder on macOS, and we got it right this time. It is magical. The VM just comes and goes on demand. There's no SSH keys, IPs, remote store copying, it is almost completely transparent. Let me know if you have questions :)

Hey folks, Graham - CEO of Determinate Systems here. Happy to answer any questions!

CEO of Determinate here again, happy to answer questions!

Hey folks, Determinate Systems CEO here. I'm really happy about this release, and what it means for our ability to get features like parallel evaluation, lazy trees, and other work into customer hands and ultimately -- ideally -- merged upstream with a higher degree of confidence.

I'll be available to for questions and whatnot!

(DetSys Cofounder here) I've had Raspberry Pi's give up their last ghostly breath evaluating NixOS.

Even as someone who does think Flakes are better than the prior solutions, I'm increasingly of the opinion that Flakes would be better moved to a layer outside the core Nix project - advancing them within core Nix at this stage seems pretty impossible with many within the project opposed to their existence. I think if Flakes were an alternative project at the same level as something like Niv, a lot of the holy warring would get out of the way.

I posted some information and metrics about that on Discourse:

https://discourse.nixos.org/t/announcing-determinate-nix/547...

Of course :).

I mean, it sort of is, on the heals of two other announcements earlier this week:

* https://determinate.systems/posts/announcing-determinate-nix...

* https://determinate.systems/posts/flakehub-cache-and-private...

My man.

I love your project, Jon! I think the Nix ecosystem will be improved by having more, smaller things, where the boundaries are clear.

Hell yeah. Speaking my language! I don't know, but we need that!

I think those are fair perceptions and concerns.

Regarding experimental features like flakes: the reality is they're incredibly stable. I've written about this before: https://determinate.systems/posts/experimental-does-not-mean.... They haven't realistically changed in years, because they work so well. The experimental label is practically FUD at this point.

If the Nix team were to change flakes in a breaking way, it would be stunning neglect for the vast, vast percentage of the ecosystem that has already adopted them. Our data shows that of all the (OSS) repositories created every day, almost 90% of them start with a flake.nix. Of all of those projects, less than 20% use the legacy file formats, and most of those are using the flake-compat library.

On documentation and interfaces, I agree, and we and the greater community are working hard to on that problem. I'll take time, but it is decidedly better than it was a few short years ago.

And on community fragmentation, I just don't see it becoming a problem. The core Nix ecosystem is so large and diverse, I don't see meaningful fragmentation coming out of this.

Back in the day, adopting Git was also clumsy and hard to implement. It was buoyed significantly by the investments GitHub made into its usability.

I agree Nix is going to have to evolve to gain wider adoption. It's part of the work we're seeing in the ecosystem, and also work we're already doing :).

They're great! But also still miss fundamental pieces that Nix gets right. Especially the way the build and dependency graph goes right to the root of every package, and comes together to completely describe the system you're running today.

I feel that. This is one place where the "nix is everything, everything is nix" mentality hurts the project. NixOS modules are where the abstract config option sauce lives. It isn't an inherent part of Nix.

As Nix (and NixOS) becomes more widely used, this is one place where we'll have to find a way to let users do what they know how, and stop getting in the way.

Hear hear. It takes continuous effort not just on documenting, but also reducing the need for documentation by cutting interfaces and accidental complexity.

Hi Steve!

Well. The future isn't evenly distributed yet :). There is work in flight to make Nix support Windows. Also, and I know this doesn't count, but it works great in WSL today.

A FlakeHub organization with private flakes and cache is $20/user/month, plus at-cost storage and bandwidth. Members of that organization get automatic access to the private flakes and read access to the cache. In the future, we'll be opening up the policy engine to make it more flexible.

Whew. "Everything" is a tough one, today.

1. I know there is an upcoming book, NixOS in Production. There is a lot of great info in there!

2. Have you seen https://zero-to-nix.com/?

Eelco's typical online handle is "niksnut", which obviously means "nix nut" but also "good for nothing" :).

Hey folks CEO of Determinate Systems, and the author of the blog post. I'd be glad to answer questions about the post and what we're doing!

Yes!

1. Enable systemd: https://devblogs.microsoft.com/commandline/systemd-support-i...

2. Install as normal:

curl --proto '=https' --tlsv1.2 -sSf -L https://install.determinate.systems/nix | sh -s -- install --determinate

3. https://zero-to-nix.com/ :)

I believe a lot of this comes from Nix being largely "low policy", meaning you can do anything, any way you want, you just have to figure out how. Our goal is to make a more high-policy version that has more workflow and "rails" out of the box to make a good experience.

We won't break our customers.

Indeed, part of the motivation for our downstream distribution is to be able to ship some of our patches faster than upstream wants to. However, these patches are generally about usability improvements that are not incompatible.

If the upstream project evolves in a different direction, it will be on us to move with them too.

lol. We have two closed source projects that are meaningful in any way: FlakeHub, and determinate-nixd.

Everything else we have is, and all of our improvements to Nix are, open source and permissively licensed. That includes Determinate Nix Installer and zero-to-nix, both of which are permissively licensed with the hope and intention of the upstream project adopting or integrating the material as they saw fit.

Thank you, we will! =). I think there is a lot of opportunity here around a cohesive workflow around Nix. That is a big part about what I was consulting on for so many years.

Maybe check out our demo on our home page: https://determinate.systems/ -- you might like it.